Listes de contrôle SQL Server

14

Dans le prolongement de mon autre question , je voudrais commencer à réfléchir à ce que je devrais examiner sur une base quotidienne / hebdomadaire / mensuelle en termes d'alertes. J'espère pouvoir voir les problèmes venir avant qu'ils ne surviennent (c'est le plan) ...

Jusqu'à présent, j'ai commencé à collecter des scripts pour les éléments suivants (sans ordre):

du quotidien

  • Vérifier la disponibilité du système (juste au cas où je devrais vérifier quoi que ce soit en tant que DBA)
  • Vérifier la dernière sauvegarde
  • Vérifiez les sauvegardes du journal des transactions
  • Vérifier l'état des travaux SQL
  • Vérifiez l'utilisation moyenne du processeur au cours des dernières 24 heures (ou 1140 minutes)

Hebdomadaire

  • Vérifier l'historique de sauvegarde MSDB
  • Vérifiez la dernière exécution de CheckDB
  • Vérifier la fragmentation de l'index
  • Vérifier les statistiques d'index (lectures vs écritures, etc.)
  • Vérifier les goulots d'étranglement d'E / S

Mensuel

  • Vérifier les index manquants
  • Vérifier les index qui ne sont plus utilisés

D'autres suggestions? (Je suis nouveau à DBA, donc toute aide / conseil est toujours le bienvenu)

sql-server-2008  sql-server-2005  maintenance 
— Stuart Blackler
source

Réponses:

3

  1. Sauvegardes

    • Vérifier les e-mails de sauvegarde
    • Combien de temps a duré la sauvegarde (durée de sauvegarde de la base de données)
    • Vérifiez que toutes les bases de données sont sauvegardées conformément à un plan de maintenance

  2. Espace libre sur le disque. Notez les variations importantes par rapport à la vérification précédente. Les fichiers journaux peuvent être considérablement affectés par les tâches mensuelles

  3. Échecs de travail. Filtrer l'activité des travaux pour les échecs

  4. Vérifications du système. Recherchez dans les journaux sql toute erreur critique.

    • Journaux d'application

  5. Performance

    • Vérifier les statistiques de performances sur tous les serveurs
    • Vérifiez que les compteurs sont dans la plage normale sur tous les serveurs de production

  6. Connectivité

    • Vérifier que l'application client peut obtenir des données de la base de données
    • Vérifier la vitesse acceptable des données d'accès

  7. Réplication. Vérifiez que chaque publication et distributeur est en cours d'exécution pour chaque abonnement

Liste de contrôle DBA SQL Server

Liste de contrôle Brad's Sure DBA

Liste de contrôle Oracle DBA (peut-être utile)

Liste de contrôle de gestion de la base de données DBA SQL Server

DBA Morning Check List

Liste de contrôle DBA MS SQL Server (plusieurs listes de contrôle)

Liste de contrôle DBA SQL Server

— garik
source
4

La seule variation que je suggérerais sur votre liste de contrôle est de remplacer le mot BACKUP par RESTORE. Vérifier que les sauvegardes sont terminées est un bon début, ce qui compte vraiment, c'est de savoir si vous pouvez restaurer à partir de celles-ci. Alerte en cas d'échec de sauvegarde, automatisez un échantillonnage aléatoire des restaurations afin de savoir que vos sauvegardes sont bonnes.

La prochaine étape à partir d'une liste de contrôle quotidienne / hebdomadaire / mensuelle est l'historique. Un contrôle sur les compteurs de performances x / y / z n'a aucun sens sans une base de référence à comparer aujourd'hui à hier. Sans comprendre aujourd'hui et hier, il est impossible de prédire le mois prochain.

— Mark Storey-Smith
source
2

AVERTISSEMENT: pas un DBA SQL Server

Si possible, vous souhaiterez peut-être vérifier mensuellement les index qui ne sont utilisés par aucune requête. Vous voudriez certainement le faire pour

  • très grandes tables
  • tables avec de nombreux index
  • index avec plusieurs colonnes (3 ou plus)
— RolandoMySQLDBA
source
4
Assurez-vous simplement que «non utilisé» reflète un cycle économique complet. J'ai entendu parler de plusieurs cas où le DBA a décidé de supprimer un index qui n'avait pas été utilisé depuis quelques mois, et le lendemain, le rapport trimestriel du CFO prend des heures au lieu de secondes ... vous ne pouvez pas compter sur index_usage_stats DMV, surtout si votre serveur est redémarré périodiquement, donc je ne ferais cela que si vous gardez vos propres statistiques d'utilisation au fil du temps ...
— Aaron Bertrand
2

Vérifiez fréquemment la longueur de la file d'attente d'E / S pour les goulots d'étranglement.

— Thomas Stringer
source
2

Quelque chose pour aider à l'accomplir ... Idera a mis à disposition un outil gratuit pour examiner les travaux SQL Server que j'ai utilisé plusieurs fois. C'est très bien pour avoir une bonne vue d'ensemble, bien qu'il ait quelques limitations car il est gratuit. À vérifier: http://www.idera.com/Products/Free-Tools/SQL-job-manager/

Quelque chose que j'ajouterais pour le côté sécurité de la maison ... Un fichier de trace spécifiquement pour capturer l'activité d'ouverture de session pour les comptes d'utilisateurs. Cela vous permettra de trouver facilement des comptes inactifs. Puis également un script qui surveille quand quelqu'un est ajouté à des rôles serveur / base de données fixes. Surtout administrateur système, si vous n'êtes pas le seul à gérer le serveur / l'instance.

Un fichier de trace est-il le meilleur moyen de procéder?
— Thomas Stringer
c'est le moyen le plus simple que je connaisse pour obtenir les informations. À moins que vous ne mettiez un déclencheur pour capturer les informations dans une table ou un journal, peut-être. Si vous utilisez SQL 2008, la gestion des stratégies peut être utilisée à cette fin.
Une trace peut être le meilleur moyen, @ShawnMelton. Il existe un moyen de modifier le registre ( sqlservercentral.com/articles/security/sqlserverauditingpart1/… ) afin que SQL Server audite toutes les connexions (réussies et échecs). Je ne sais pas quel est le meilleur moyen, mais je crains toujours de garder une trace indéfiniment. Tes pensées?
— Thomas Stringer
Je n'ai jamais eu de problème lors de l'exécution de fichiers de trace où ils affectaient autant les performances. Activer l'audit C2 bien que je l'ai, je n'aime pas l'activer. Les événements étendus offrent une alternative et sont censés être la méthode préférée à l'utilisation des fichiers de trace, plus de puissance avec eux. Vous pouvez vérifier dans ceux-ci pour voir s'il existe une option pour les événements de connexion, j'en suis sûr. D'après ce que je comprends d'eux, ils sont en quelque sorte exclus de causer un coup avec la performance.
agréable. Je suis enclin à être d'accord avec vous. Et oui, C2 est certainement l'une de ces situations à n'utiliser que si vous en avez besoin.
— Thomas Stringer
0
  • vérifier le journal des erreurs de SQL Server et de l'Agent SQL Server
  • vérifier l'état des serveurs en miroir (principal et miroir)
  • vérifier les changements de temps d'exécution des travaux
  • vérifier le nœud actif dans le serveur SQL en cluster
  • check ESPACE DISQUE
— Alex_L
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.