Gestion de gros serveur

Bonjour,

J'ai une question d'ordre générale concernant la gestion de gros serveurs. Je suis habitué à gérer des volumes de centaine de Gigas, mais pas de volume exprimé en Téra.

Comment faire pour gérer des Téras de données et assurer un fonctionnement optimal du serveur 24h/24 ?

Quelques exemples de situation :

Un DBCC CheckDB
Une réorganisation d'index (uniquement ceux qui sont défragmenté).
Un restore.

Scinder la base de données sur plusieurs fichiers est-il suffisant ou existe-t'il d'autres astuces à considérer ?

Comment mettre à jour un serveur (un service pack par exemple) tout en assurant un service 24/24 sans arrêt/redémarrage de serveur ?

Comment migrer un serveur SQL 2005 en SQL 2008 sans arrêt/redémarrage de serveur ?

D'avance, merci

Dommage que ce topic demeure sans réponse.

J'ai été contacté par un chasseur de tête pour occuper un poste de DBA dans une grande société. Cependant, le fait que je ne gère pas un serveur SQL ayant des téras de données dans mon poste actuel est considéré comme bloquant.

J'ai été amené à gérer un serveur avec une VLDB (> 2 To) avec 500 utilisateurs concurrents dans un environnement 24 /24 et 7J /7.

Un des problèmes majeurs est la maintenance des bases :

Pour ma part quand je suis arrivé les plans de maintenance duraient plus de 8H la plupart du temps. Dans un environnement 24 / 24 avec une obligation de performance des bases autant dire que cela posait problème.

De la vérification d'intégrité en passant pas la gestion des sauvegardes et la maintenance des index il faut tout prendre en compte.

Concernant la vérification d'intégrité dans le cadre des VLDB un article si cela vous intéresse : http://mikedavem.developpez.com/sqls...ntegrite_vldb/

Concernant les index : http://sqlpro.developpez.com/optimis...eIndexVLDB.pdf

La stratégie de sauvegarde doit être aussi adapté non seulement en fonction de l'architecture existante mais également en fonction des impératifs business .. autant dire que la sauvegarde complète tous les soirs est à proscrire. On peut essayer de diminuer les temps de backup en la scindant en plusieurs fichiers (parallélisation de la sauvegarde). Le robot utilisé pour copier les backups sur le datacenter mettait pratiquement la journée pour réaliser l'opération. En scindant les fichiers, on a également pu paralléliser la copie depuis le robot, ce qui a résolu le problème. Enfin on peut déporter les ressources monopolisés pour la vérification des sauvegardes sur un serveur déporté ...

Bref autant de techniques qui permettent d'optimiser tout cela. Personnellement nous avons ramené les temps de maintenance à moins de 2H30 dans le pire des cas.

La volumétr

Les statistiques sur les grosses tables :

Un des autres problèmes auquel j'ai été confronté est la mise à jour des statistiques sur les plus grosses tables et qui étaient très souvent sollicités. L'algorithme de mise à jour par défaut employé par SQL Server ne permettait pas d'obtenir un taux d'échantillonnage suffisant pour créer des plans d'exécutions satisfaisants. Nous avons dû changer la stratégie de mise à jour des statistiques sur certaines tables. Je pense que d'autres .. il se reconnaitront ont dû avoir le même pb :roll:

Les opérations d'insertion ou de suppression massives des données pour les tables volumineuses peuvent être problématiques également :

Il y a des techniques qui permettent d'aller plus vite, comme la désactivation des indexs, la pose de verrous sur la table et l'insertion en bloc, le passage en mode BULK LOGGED etc ....

Un article intéressant aussi : http://blog.developpez.com/sqlpro/p8...plexes-dans-l/

L'architecture physique des fichiers et le sous système disque :

Aspect important dans les VLDB .. Il peut être intéressant de répartir la charge IO sur les tables les plus sollicités (de grosse volumétrie) sur certaines axes physiques pour éviter une contention d'un seul axe

La mise à jour applicative :

Bien souvent sur des grosses volumétries, on se retrouve souvent confronté à des probèmes de performance de l'environnement de pré prod à l'environnement de production. En effet on a pas toujours le même espace disque pour les 2 environnement voir les mêmes machines. Du coup les tests s'en retrouvent biaisés car ils ne reflétent pas vraiment la réalité d'un contexte de production. La difficulté est de pouvoir prédire tout cela. Personnellement nous avions des tests en 2 phase : Première phase qui permettait de repérer les procédures / requêtes longues et de les faire corriger .. Dans une 2eme phase, on utilisait DTA ou les RML Utilities pour avoir une 2eme vue de ce qu'il y avait à optimiser.

J'en oublie certainement et le sujet est vaste ... D'autres certainement sur le forum pourront faire part de leur expérience.

++

la maintenance courante c'est de vérifier la base à intervalle régulier. Donc DBCC CHECKDB, mais généralement de manière plus fine (CHECK...TABLE, CATALOG....) mais aussi de faire des verifs en continue (détection des pages endommagées) voire de remonter des alertes par l'agent SQL
Pour la réindexation ne faire que le nécessaire voire partiellement
Lire : http://sqlpro.developpez.com/optimis...ntenanceIndex/

Faire des sauvegarde en parrallèle et compressées pour les accélérées

etc, etc....

Merci pour toutes ces réponses.

Actuellement, je gère des bases dont les plus volumineuses est une centaine de Gigas. Mais les problèmes que cela gère en maintenance sont déjà perceptible.

Les travaux de nuits (CHECKDB, Défragmentation des index fragmenté, backup) dure environ 5 heures et le temps ne fera que s'accroitre avec la volumétrie.

La base de données la plus volumineuse a été segmentée en trois : une contenant les data + primary key, un autre contenant les index et la troisième étant le journal. Tout cela localisé sur différents RAID GROUP d'un SAN.

Nous comptons aller plus loin en scindant le fichier données en trois : un fichier pour les tables systèmes, un autre pour les tables de configurations dont le contenu change très peu et un troisième fichier pour les tables les plus sollicitées.

Au delà de ces aspects, nos impératifs exigeant la continuité 24 heure sur 24 rend difficile la mise à jour des Service Pack, voire la migration de 2005 vers 2008/2008R2 par exemple. Là, je ne vois pas comment faire sans arrêter le service SQL.

Il me reste à étudier les log-shipping, le mirroring et la mise en cluster.

Je n'ai jamais utilisé le le mode de journalisation BULK. J'utilise le mode de journalisation complet, mais la taille des log explose lors de la défragmentation des index.

Citation:

---

Au delà de ces aspects, nos impératifs exigeant la continuité 24 heure sur 24 rend difficile la mise à jour des Service Pack, voire la migration de 2005 vers 2008/2008R2 par exemple. Là, je ne vois pas comment faire sans arrêter le service SQL.

---

Il vous faudra une architecture qui supporte ces impératifs dans ce cas (Cluster, Mirroring ...)


++

Bonjour,

Pour ma part je gère pour un de nos clients une base de données de plus de 3TB, avec 5000 postes clients.
Le DBA principal n'a rien fait en terme de maintenance et je suis en train de mettre un terme à tout cela, et je ne vais pas tarder à faire une petite publication en ce qui concerne la gestion des index, mais l'idée de fond reste la même que celle de SQLPro.

Mikedavem a abordé tous les problèmes de maintenance générale.
Dans mon cas, le client utilise la compression des sauvegardes, ce qui lui permet de réaliser des sauvegardes complètes de la base de données en un peu moins de deux heures, mais il est clair que les disques n'y sont pas pour rien.

Autre point à ne pas négliger, mais c'est suivant l'utilisation que vous faites des bases de données : la base de données TempDB.
De nombreux articles existent sur celle-ci, notamment sur le nombre de fichiers par rapport au nombre de processeurs.
Chez ce client, 8 fichiers (1 par processeur) ont été moins performants que 4.

Pour les mises à jour, comme l'instance est clusterisée, la manœuvre est assez simple, mais je me demande comment procéder lorsque la base de données est en mirroir ...

Une autre "problème" auquel je suis en train de me heurter est l'audit de base de données en terme de recherche de requêtes contre-performantes.
Là-dessus je dois dire que les événements étendus introduits avec SQL Server 2008 sont d'une terrible efficacité.
Le souci est ensuite de trouver une manière simple d'exposer les requêtes contre-performantes pour les analyser et les corriger.

L'analyse du cache de procédures est également efficace mais plus longue à mettre en place, notamment à cause de l'utilisation de XQuery pour dépouiller les plans.

@++ ;)

Pour ce qui est de tempDB nous avons gardé un seul fichier, avec suffisamment d'espace, malgré que nous disposons de plusieurs processeurs. Le Tempdb est localisé seul sur un disque SSD.

Quand au problème de performance, j'ai mis en place un système d'alerte qui m'envoie un courriel lorsque des processus sont bloqués (avec texte de la requête et nom des applications).

Quand je détecte un processus bloqué, je corrige le code SQL et/ou je met les index nécessaire. Là où je ne sais pas résoudre un problème, c'est lorsque le modèle de données est en cause et à ce sujet, je n'ai rien à dire.

Pour passer de 2005 à 2008 sans discontinuité, vous pouvez utiliser le mirroring :
Mirroring de 2005 vers 2008, basculement sur serveur 2008, puis MAJ du serveur 2005 en 2008, Puis réalisation du mirroring inverse, puis basculement inverse !

A +

Merci !

Quid des service packs ?

@++ ;)

Dans le même esprit que SQLPro .. même chose pour les services packs

L'idée étant de mettre à jour la partie inactive ou de secours de l'architecture (noeud passif / le serveur em miroir etc ...) dans un premier temps , basculer et mettre à jour la seconde partie ..

++

En fait je suis complètement à la traîne sur la haute disponibilité, donc je ne savais pas que c'était possible.

Merci bien à vous deux ;)

@++ ;)