IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MS SQL Server Discussion :

Gestion de gros serveur


Sujet :

MS SQL Server

  1. #1
    Membre actif
    Profil pro
    Inscrit en
    janvier 2008
    Messages
    240
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2008
    Messages : 240
    Points : 210
    Points
    210
    Par défaut 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

  2. #2
    Membre actif
    Profil pro
    Inscrit en
    janvier 2008
    Messages
    240
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2008
    Messages : 240
    Points : 210
    Points
    210
    Par défaut
    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.

  3. #3
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2005
    Messages
    5 431
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : août 2005
    Messages : 5 431
    Points : 12 786
    Points
    12 786
    Par défaut
    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

    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.

    ++

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 982
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 982
    Points : 49 805
    Points
    49 805
    Billets dans le blog
    1
    Par défaut
    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....
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  5. #5
    Membre actif
    Profil pro
    Inscrit en
    janvier 2008
    Messages
    240
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2008
    Messages : 240
    Points : 210
    Points
    210
    Par défaut
    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.

  6. #6
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2005
    Messages
    5 431
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : août 2005
    Messages : 5 431
    Points : 12 786
    Points
    12 786
    Par défaut
    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 ...)


    ++

  7. #7
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2005
    Messages : 5 826
    Points : 12 348
    Points
    12 348
    Par défaut
    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.

    @++

  8. #8
    Membre actif
    Profil pro
    Inscrit en
    janvier 2008
    Messages
    240
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2008
    Messages : 240
    Points : 210
    Points
    210
    Par défaut
    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.

  9. #9
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 982
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 982
    Points : 49 805
    Points
    49 805
    Billets dans le blog
    1
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  10. #10
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2005
    Messages : 5 826
    Points : 12 348
    Points
    12 348
    Par défaut
    Merci !

    Quid des service packs ?

    @++

  11. #11
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2005
    Messages
    5 431
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : août 2005
    Messages : 5 431
    Points : 12 786
    Points
    12 786
    Par défaut
    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 ..

    ++

  12. #12
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2005
    Messages : 5 826
    Points : 12 348
    Points
    12 348
    Par défaut
    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

    @++

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [PORT] gestion des ports serveur
    Par magnus2005 dans le forum Développement
    Réponses: 2
    Dernier message: 18/07/2007, 21h26
  2. Gestion erreur SQL Serveur dans un Script VBS
    Par jayan dans le forum VBScript
    Réponses: 3
    Dernier message: 08/02/2007, 15h06
  3. Gestion facilitée de serveurs DNS avec bind
    Par marcha dans le forum Réseau
    Réponses: 1
    Dernier message: 17/08/2006, 16h15
  4. [Composants texte] Gestion de gros fichiers
    Par sozie9372 dans le forum Interfaces Graphiques en Java
    Réponses: 8
    Dernier message: 22/05/2006, 12h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo