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

Administration SQL Server Discussion :

Plan de maintenance - Best practices


Sujet :

Administration SQL Server

  1. #1
    Futur Membre du Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Janvier 2015
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Janvier 2015
    Messages : 4
    Points : 5
    Points
    5
    Par défaut Plan de maintenance - Best practices
    Bonjour à tous,

    Je viens ici chercher un support technique chez les experts que vous êtes car je suis un noob en SQL server et je n'ai pas envie de faire n'importe quoi.

    Alors je dois mettre en place un plan de maintenance sur SQL server 2008 R2, mais quel ordre pour les différentes taches et à quelle fréquence ?
    Aujourd'hui j'ai un plan qui ressemble à ceci :
    -Backup Full chaque dimanche
    -Diff chaque jour
    (Après ces 2 backups le lance un réduction de la base + une reconstruction des index)
    -Backup journaux de transactions
    -nettoyage des .bak chaque 5 jrs, .trn chaque 2 jrs

    Est ce que c'est bon comme plan ? Concernant la vérification de l'intégrité de de la bdd, où est ce que je peux la placer ?
    J'attends vos réponses merci !

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 761
    Points : 52 547
    Points
    52 547
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par ZAZAZAKHO Voir le message
    Aujourd'hui j'ai un plan qui ressemble à ceci :
    -Backup Full chaque dimanche
    -Diff chaque jour
    (Après ces 2 backups le lance un réduction de la base + une reconstruction des index)
    -Backup journaux de transactions
    -nettoyage des .bak chaque 5 jrs, .trn chaque 2 jrs
    Votre plan est incohérent :
    1) vous nettoyez à 5 jours, si ça plante le samedi, vous avez déjà perdu la full de dimanche dernier !
    2) vous faites un réduction de la taille des fichiers ce qui est une parfaite imbécilité ! En effet, vous êtes dans la situation du gars qui détruit le béton de la place de parking chaque fois qu'une voiture s'en va et s'empresse de couler une nouvelle dalle chaque fois qu'un client arrive !
    3) les JT doivent être sauvegardés régulièrement par exemple toutes les 10 minutes
    4) la vérification des sauvegardes est-elle faites ?
    5) OUI il est impératif de faire la vérification de l'intégrité de de la bdd,
    6) il faut sauvegardes les bases master et MSDB !!!!
    7) il est bon de vérifier si vos sauvegardes sont lisible
    8) il serait intéressant de suivre un cours DBA, par exemple chez Orsys !
    9) À défaut, vous trouverez moults informations dans mon livre : http://www.amazon.fr/SQL-Server-2014.../dp/2212135920

    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/ * * * * *

  3. #3
    Futur Membre du Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Janvier 2015
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Janvier 2015
    Messages : 4
    Points : 5
    Points
    5
    Par défaut
    Bonjour,

    Dans un premier temps je voudrais vous remercier pour votre réponse. En effet, j'ai besoin de plus de connaissance dans ce domaine là, je prendrai le temps nécessaire pour me parfaire.

    Cependant, je dois mettre en place "urgemment" un plan de maintenance qui tient la route. j'ai pris en compte votre remarque concernant le cycle de nettoyage. Mais je n'ai pas tout compris pour la réduction de la taille des fichiers.
    Pour les JT je fais chaque heure.
    Pour la vérifications des sauvegardes, il faut programmer des tests restaurations?
    Que pensez-vous de la reconstruction de l'index et maj des stats ?

    Mes questions restent posées, quelle taches programmer (avoir le pourquoi serai merveilleux) et surtout dans quel ordre et fréquence (notamment pour la vérification de la BDD)?

  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
    21 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 761
    Points : 52 547
    Points
    52 547
    Billets dans le blog
    5
    Par défaut
    Tout dépend de votre stratégie de sauvegarde...
    Que faites vous et à quelle fréquence ? Sauvegardes Complètes ? Différentielles ? Transactionnelles ?

    Une stratégie est par exemple pour une organisation travaillant en semaine et avec des bases légères (moins de 100 Go en tout) et dans l'ordre chronologique, dans les heures creuses, par exemple à partir de 22h :
    1) sauvegarde complète chaque nuit (BACKUP DATABASE....) de toutes les bases de prod et master + msdb
    2) vérification des sauvegardes en 1 (RESTORE VERIFYONLY ...)
    3) vérification d'intégrité des toutes les bases de prod et master + msdb (DBCC CHECKDB)
    4) passage des bases de prod en mode de récupération BULK LOGGED (ALTER DATABASE ... SET RECOVERY ...)
    5) reconstruction des index des bases de prod ayant une fragmentation de plus de 30% et dotés de plus de 16 pages (ALTER INDEX ... REBUILD)
    6) réorganisation des index des bases de prod ayant une fragmentation de plus de 10% et dotés de plus de 16 pages (ALTER INDEX ... REORGANIZE)
    7) passage des bases de prod en mode de récupération FULL (ALTER DATABASE ... SET RECOVERY ...)
    8) sauvegarde du journal de transaction
    9) recalcul des statistiques obsolète

    Il faudrait aussi mettre en place une sauvegarde du journal des transaction régulière, par exemple toutes les 20 minutes, lors des heures pleines de la journée (8h 20h par exemple).

    Pour vous aider :

    1) détermination du taux de fragmentation des index de la base courante
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    SELECT object_id, index_id, avg_fragmentation_in_percent, page_count
    FROM   sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL)
    a joindre avec vues systèmes objects, schemas et index

    2) détermination de l'obsolescence des statistiques :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    SELECT s.name, s.object_id, s.stats_id, last_updated, rows, modification_counter
    FROM   sys.stats AS s
           OUTER APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id)
    a joindre avec vues systèmes objects, schemas et index

    Bref, le métier de DBA ne s'improvise pas. Formez vous, lisez mon bouquin... http://www.amazon.fr/dp/2212135920/

    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/ * * * * *

  5. #5
    Futur Membre du Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Janvier 2015
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Janvier 2015
    Messages : 4
    Points : 5
    Points
    5
    Par défaut
    Merci pour votre réponse.

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

Discussions similaires

  1. Impossible de mettre a jour les plans de maintenance
    Par sqlakf76 dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 27/11/2006, 18h06
  2. Pbs avec plans de maintenance sous l'agent SQL
    Par sheira dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 29/09/2005, 06h16
  3. Plan de maintenance
    Par simon76 dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 01/09/2005, 17h45
  4. [debutant]Plan de maintenance sous sql serveur 2000
    Par christophebmx dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 05/05/2005, 12h18

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