FORUM AUX QUESTIONS SQL Problèmes de checksum, choisir le modèle de récupération approprié et plus
Paul S. Randal
QJe suis un administrateur de SharePoint et j'ai découvert récemment qu'une de mes bases de données contenus est endommagée lorsque mon cohérence mensuelle vérifie a trouvé des erreurs. Nous le tracé revenir à un contrôleur RAID défectueux et, après avoir effectué quelques recherches, nous vous activés les totaux de contrôle sur les pages de base de données. Ma question est : comment savoir lorsqu'il y a un problème checksum sans attendre jusqu'à ce que le plan de maintenance mensuelles ?
AIl y a quelques choses que vous pouvez le faire. Tout d'abord, vous pouvez ajouter l'option avec total de contrôle à vos sauvegardes. Pour les sauvegardes complètes et différentielles, cette option va provoquer l'opération de sauvegarde tester une pagination il voit et échouent avec une erreur s'il trouve une corruption. (Je le décrites en détail dans l'article du mois dernier, «Présentation des sauvegardes SQL Server».)
Ensuite, pensez à exécuter vos vérifications de cohérence plus mensuel. Je recommande exécutant une forme de vérification de cohérence au moins chaque semaine, si c'est un DBCC CHECKDB sur la base de données ou peut-être sur copie de la base de données restaurée. Qui, bien sûr, va dépendent de votre niveau de confort avec votre sous-système d'e/S.
Troisièmement, ajouter des alertes de l'Agent SQL. Une alerte peut être définie pour déclencher sur une variété de facteurs, tels qu'un déclenchement par SQL Server, une erreur avec une gravité spécifique levée ou un compteur de performance qui traversent un seuil d'erreur particulier un numéro. Cette fonctionnalité fournit un mécanisme très puissant pour surveiller les problèmes de serveur.
Lorsqu'une alerte se déclenche, un message est envoyé à un "opérateur" prédéfini en utilisant une ou toutes ces options : un message par radiomessagerie, courrier électronique ou NET SEND. Vous pouvez utiliser la procédure stockée la procédure sp_add_notification pour définir un opérateur.
Concerne les problèmes de sous-système d'e/S, les erreurs que qui vous intéressent sont 823 824 et 825. Les deux premiers sont déclenchés lorsqu'un problème d'e/S se produit (en particulier, 824 est lorsqu'un contrôle de page s'avère pour être rompue, et 825 lorsque SQL Server a tenter une opération de lecture plusieurs fois avant qu'elle exécute). Ce sont tous les problèmes que vous souhaitez connaître sur dès que possible afin de limiter davantage les dommages à la base de données (et éventuellement la quantité de temps d'arrêt pour récupérer).
823 et 824 sont ces deux 24 erreurs au niveau de gravité mais 825 est uniquement un niveau de gravité 10 "Information" message (pour plus d'informations, consultez mon blog " Un signe peu connu de doom imminent : erreur 825.") Pour avertir de ces erreurs, vous devez définir une alerte pour toutes les erreurs de 24 au niveau de gravité et en particulier pour l'erreur 825 (en fait, il est préférable d'avoir une alerte pour chaque-niveau de gravité de 19 à 25).
Pour définir les alertes réelles, vous pouvez utiliser T-SQL ou Management Studio. Voici un exemple du code T-SQL pour ajouter une alerte de l'erreur 825.
USE msdb;
GO
EXEC msdb.dbo.sp_add_alert @name = N'825 - Read-Retry Required',
@message_id = 825,
@severity = 0,
@enabled = 1,
@delay_between_responses = 0,
@include_event_description_in = 1,
@category_name = N'IO Subsystem Error';
GO
Vous trouverez plus d'informations sur la définition et ajouter des alertes, y compris une procédure étape par étape sur l'ajout d'alertes de l'aide de Management Studio, dans mon blog de l'Agent SQL catégorie») SQL 2005 SP2 maintenance plan bogue masquage endommagé)."
QJe suis une développeur-DBA qui est responsable de la partie du code et de la base de données qu'il s'exécute dans. Vous avez été discuter avec certains autres développeurs de base de données comment faire obtenir une valeur unique pour identifier les lignes de table. Je souhaite utiliser un GUID comme clé d'index ordonné en clusters, mais les autres sont expliquer que cela peut entraîner des problèmes de performances avec des index. Est cette valeur de true et si tel est le cas, pouvez-vous expliquer pourquoi ?
UN Oui, c'est vrai, GUID font partie des causes à gauche de la fragmentation d'index dans les bases de données SQL Server.
Un GUID est un identificateur global unique. Dans SQL Server, ceci est une valeur de 16 octets qui est généré dans SQL Server ou un autre emplacement (par exemple via .NET dans le client ou mid-tier). GUID ont généralement une valeur aléatoire, sauf si généré avec la fonction NEWSEQUENTIALID introduite dans SQL Server 2005.
Cette fonction génère des plages de GUID, qui peut aider à résoudre certains des problèmes que je vais décrire ici. Mais elle nécessite générer un GUID côté serveur, ce qui ne fonctionne pas dans de nombreux environnements d'application, car l'identificateur unique doit être généré avant que les données ne soit envoyées vers le bas à la couche données.
Peu importe où le GUID non séquentiel est généré, ayant comme la clé à gauche dans un index signifie que la clé étant essentiellement aléatoire, l'insertion point d'un nouvel enregistrement dans l'index est également aléatoire — la valeur de clé d'un enregistrement détermine son sélection élective dans l'index. Cela signifie également que le GUID de 16 octets sera présent dans chaque ligne de chaque index non ordonné en clusters comme partie du lien qui permet de naviguer entre les enregistrements d'index non ordonné en clusters enregistrements d'index ordonné en clusters pour obtenir les colonnes les valeurs de la liste de sélection de requête qui ne figurent pas dans l'index non-cluster a été utilisé (également couramment appelé une recherche de signet) le moteur de stockage.
Nombre d'enregistrements est insérée dans l'index, les pages de stocker les enregistrements de remplissent. Si un enregistrement est inséré sur une page qui est déjà complète (n'oubliez pas que la valeur de clé détermine l'emplacement du nouvel enregistrement), puis la page doit fractionner, certains enregistrements de déplacement vers une page nouvellement allouée. Fractionnement de la page est une opération coûteuse à effectuer (une nouvelle page est allouée et liée à l'index et enregistrements sont déplacés vers la nouvelle page), et il entraîne la fragmentation.
Fractionnements de page provoquer la fragmentation logique dans l'index (qui affecte les performances d'analyse de plage) en ce qui entraîne physiques et logiques l'ordre des pages dans l'index soit différent. Elle entraîne également la densité de page faibles (où il est espace inutilisé dans les pages), qui conduit à l'espace gaspillé sur les pages et une mauvaise utilisation du disque, e/S et de la mémoire.
Pour plus d'informations sur la fragmentation d'index et explique comment détecter et supprimer, consultez mon article d'août 2008» Astuces pour une maintenance de base de données efficace." Une clé d'index ordonné en clusters bon d'enlèvement est abordée dans cet article, je laisse à ma femme, Kimberly l. Tripp, pour expliquer. Consultez son blog très sur ce sujet, qui passe également en plus de détails sur GUID et les structures d'index ordonné en clusters» ( GUID comme enregistrements primaire ou la clé de cluster.")
QNotre stratégie de haute disponibilité consiste à utiliser des journaux à quelques serveurs secondaires. Notre équipe de gestion est pressuring me certains utilisent les serveurs redondants pour enregistrer les dépenses de capital de. Mon idée est d'utiliser les serveurs secondaires pour permettre le rapport des requêtes à exécuter, ont également l'avantage de déchargement de la charge de rapport à partir du serveur principal. Quels problèmes peut vous exécuter dans cette opération ?
UN Ce type de scénario est beaucoup plus répandue dans le climat économique actuel, où sociétés ne convient pas pour que les serveurs assis autour qui semble être inactive (même s'ils vous fournissant une copie redondante de la base de données).
Comme vous probablement déjà le savez, lorsque vous configurez des journaux, vous pouvez définir comment les sauvegardes du journal des transactions sont restaurés sur un serveur secondaire, WITH NORECOVERY ou WITH STANDBY. La première n'est pas autoriser le tout accès à la base de données, alors que ce dernier autorise l'accès en lecture seule à la base de données. Il utilise un mode spécial où s'exécute de récupération et la base de données sont cohérentes, mais les opérations effectuées sont stockées dans un fichier annulation distinct afin que plus les sauvegardes du journal des transactions peuvent être restaurés (j'aborderai ceci plus en détail le mois prochain dans un article sur l'utilisation de RESTORE).
Pour autoriser les rapports sur le serveur secondaire, vous allez utiliser WITH STANDBY pour que les requêtes Création de rapports peuvent se connecter à la base de données. Une fois vous autorisez les connexions utilisateur, vous exécutez immédiatement à certains problèmes.
Tout d'abord, l'aide de l'option WITH STANDBY peut conduire à sauvegardes du journal des transactions seeming de prendre un certain temps pour restaurer sur un serveur secondaire, comme le contenu du fichier annulation doit être relu avant restauration de la sauvegarde suivante du journal des transactions. Cela peut poser un problème si le fichier d'annulation contient un grand nombre d'opérations.
Ensuite, la restauration d'une sauvegarde du journal des transactions n'est pas une opération en ligne. Aucun utilisateur ne peut être connecté à la base de données pour la durée de la restauration. Cela signifie que toutes les connexions votre serveur de rapports secondaire doivent être supprimées, puis reconnectées une fois la restauration terminée. Ici, vous avez un dilemme : lorsqu'il s'agit de restaurez la sauvegarde suivante du journal des transactions, vous arrêter les connexions utilisateur ou les autoriser à terminer leurs requêtes ? C'est complètement à vous.
Une question à garder à l'esprit si vous ne souhaitez pas mettre fin aux connexions : comment long interdire les requêtes continuer avant de les forcer arrêter ? Plus vous attendez, plus elle a été depuis la dernière sauvegarde du journal a été restaurée et obtient la principale base de données secondaire celui behind plu. Ce peut être un problème si vous avez puis basculer vers le serveur secondaire, car il peut être une file d'attente de sauvegardes du journal en attente d'être restauré pour mettre la base de données aussi bien à jour que possible, minimiser la perte de données.
Vous trouverez plus d'informations sur ces options, ainsi que sur Surveillance des problèmes tels que durée durée écoulée depuis la dernière restauration sauvegarde du journal sur le serveur secondaire, dans la rubrique documentation en ligne " Utilisation de serveurs secondaires pour le traitement de requêtes."
QComment pouvez choisir le modèle de récupération approprié ? À partir de ce que j'ai lu, il semble que je doit être à journalisé en bloc pour réduire mes taille du journal des transactions, mais il semble que mon taille journal conserve toujours augmente. Est-il possible d'utiliser un mode qui n'utilisent le journal des transactions du tout et éviter complètement le problème tout ?
UN ne les requêtes que j'ai entendu dire plusieurs fois est pour une base de données non-consignée, lorsque aucun enregistrement de journal de transaction n'est généré du tout, en particulier pour tempdb, qui personnes des vue comme une base de données montage car elle est recréée dans le démarrage du serveur.
Autant que je sais, cela arrivera jamais pour SQL Server. Le meilleur que vous obtiendrez est le mode BULK_LOGGED, qui considérablement coupe vers le bas la taille du journal des transactions générées pour certaines opérations (tels que reconstructions d'index et de charge). Toutes les bases de données, même tempdb, doivent avoir un niveau d'enregistrement pour permettre des transactions à restaurer (c'est-à-dire, pour annuler toutes les opérations qui faisaient partie de la transaction) dans le cas d'un utilisateur annule l'opération ou une erreur provoquant l'opération à échouer.
Plus important, des bases de données en dehors de tempdb, est que si une panne du système se produit, la base de données doit pouvoir récupérer sans laisser de façon transactionnelle des données incohérentes ou un point de vue structurel incohérentes (c'est-à-dire, endommager) base de données. Imaginez si ne comportait aucun enregistrement de ce qui avait été modification dans la base de données avant l'incident, comment SQL Server exécuterait récupération ? Vous pouvez obtenir des informations supplémentaires sur l'utilisation l'enregistrement et la récupération dans mon article de février 2009 " Enregistrement de comprendre et de récupération dans SQL Server."
Pour choisir un modèle de récupération, une question de substitution déterminera votre choix : vous voulez pouvoir faire "point-à-temps» ou «temps réel" récupération en cas d'incident ? Si tel est le cas, vous allez utiliser le modèle de récupération FULL (et éventuellement le modèle _LOGGED BULK) à l'occasion. Si vous n'êtes pas intéressé par cette opération, utilisez le modèle de récupération SIMPLE.
La raison de l'aide de SIMPLE au lieu de FULL si vous ne souhaitez pas pouvoir récupérer la base de données (sans perdre le travail depuis la dernière base de données ou sauvegarde différentielle) est qu'avec le modèle de récupération SIMPLE, vous ne devez prendre transaction sauvegardes du journal pour gérer la taille du journal des transactions.
Maintenant, peut avoir d'autres raisons pourquoi vous devez utiliser le modèle de récupération FULL — par exemple, si vous souhaitez utiliser de base de données (DBM prend uniquement en charge le modèle de récupération FULL) de mise en miroir ou envoi (journal prend en livraison charge des modèles récupération BULK_LOGGED et point) de journaux. Dans les deux cas, vous allez devez vous assurer que vous prenez transaction sauvegardes du journal afin que le journal n'est pas devenir trop volumineux (même si vous vous retrouverez en ignorant les).
J'ai mentionné peut parfois vouloir utiliser le modèle de récupération BULK_LOGGED, plutôt que constamment en ce mode. Il est, étant donné certaines limitations autour prise et la restauration de sauvegardes du journal lorsqu'une opération journalisée dans le modèle de récupération BULK_LOGGED depuis la dernière sauvegarde de journal de transaction a été. Les détails sont trop complexes pour expliquer dans cette colonne, mais vous trouverez plus d'informations sur ce et sur le choix en général, un modèle de récupération dans la rubrique documentation en ligne " Présentation de modèle de récupération."
Paul s. Randal est directeur de Général SQLskills.com, un directeur régional Microsoft et un MVP SQL Server. Il a travaillé sur le moteur de stockage de SQL Server chez Microsoft de 1999 à 2007. Paul a écrit DBCC CHECKDB/repair pour SQL Server 2005 et était responsable de Core Storage Engine pendant le développement de SQL Server 2008. Paul est un expert de récupération après incident, haute disponibilité et la maintenance de la base de données et un présentateur régulièrement à des conférences dans le monde entier. Blogs d'a à SQLskills.com/blogs/paul, et vous pouvez lui trouver sur Twitter à Twitter.com/PaulRandal.