Pourquoi la réplication SAN provoque-t-elle une corruption de base de données aléatoire?

Question

Avoir un problème étrange avec une technologie de récupération après sinistre que nous essayons de mettre en œuvre. L'environnement dans les deux centres de données est la même ayant VMware et Dell Equallogic Sans, qui sont les mêmes versions.

Lorsque nous reproduisons d'un centre de données à une autre, des bases de données aléatoires sont corrompues d'une manière ou d'une autre en mode suspect. Chaque fois que nous essayons cette méthode, différentes bases de données seront corrompues. Est-ce un comportement en SQL qui cause cela? Est-ce le logiciel utilisé dans le SAN pour reproduire provoquant ces erreurs?

J'ai pu modifier l'état de la base de données en mode d'urgence et effectuer DBCC CheckdB, mais c'est un problème et une base de données différents à chaque fois. Certaines des erreurs que j'ai trouvées sont des problèmes d'index et des problèmes d'inadéquation de données. Je suis toujours en train de vérifier d'autres bases de données pour voir si je peux trouver un motif. Si vous trouvez d'autres choses, je serai sûr de poster si cela vous aidera.

J'ai entendu parler des personnes implémentant cette procédure avec succès et que la dernière tâche du projet de déterminer avant de pouvoir fermer la charte du projet.

J'espérais vraiment que nous pouvions simplement utiliser les fonctionnalités intégrées de SQL Server comme miroir ou AO-AGS.

Les versions de SQL sont de 2008 R2 et 2012. Nous sommes en train d'installer certains nouveaux serveurs SQL 2014. En outre, ils sont tous standard, pas l'entreprise.

Une entrée ou des choses que je pourrais essayer serait d'une grande aide, merci d'avance !!

edit # 1 8/11/15 12:50 CST - Voici quelques-uns des messages d'erreur que j'ai trouvés dans la visionneuse d'événements Windows, qui est plus ou moins ce que DBCC Checkdb a produit.

• EventID 605 - Tentative d'extraction de la page logique (1: 22620) dans la base de données 26 a échoué. Il appartient à une unité d'allocation 72057594239385600 à ne pas 72057594249412608
• EventId 824 - SQL Server a détecté une erreur d'E / S de cohérence logique: une pagination incorrecte (prévue 1: 1230; réel 0: 0). Il s'est produit lors d'une lecture d'une page (1: 1230) dans la base de données ID 58 à la décalage 0x0000000099C000 dans le fichier 'D: \ mydatabase.mdf'. Des messages supplémentaires dans le journal des erreurs SQL Server ou le journal des événements système peuvent fournir plus de détails. Il s'agit d'une sévère condition d'erreur qui menaçait l'intégrité de la base de données et doit être immédiatement correcte. Remplissez une vérification complète de la cohérence de la base de données (DBCC CheckdB).
• EventID 7886 - Une opération de lecture sur un objet important a échoué lors de l'envoi de données au client. Une cause commune pour cela est si l'application est en cours d'exécution dans un niveau d'isolation non engagé. Cette connexion sera terminée.
• EventID 608 - Aucune entrée de catalogue trouvé pour la partition ID 72057594383564800 dans la base de données 23. Les métadonnées sont incohérentes. Exécutez DBCC CheckdB pour rechercher une corruption de métadonnées.

edit # 2 8/16/15 14:24 PM CST - Info reçu qui restauré des fichiers .bak des bases de données dans le mode suspect fixe la matière.

Answer 1

En ce qui concerne votre commentaire, je soupçonne une question liée à OPS ici au lieu d'un problème de moteur SQL Server. Ces dispositifs SAN fonctionnent généralement sur la couche de blocs et certains gèrent la synchronisation du journal / de données de transaction mieux que d'autres, ainsi que d'autres zones.

Vous pouvez afficher l'équipe OPS que non, SQL Server ne corrompre pas de manière aléatoire des données comme celle-ci. Vous pouvez restaurer des sauvegardes sur un autre serveur, la mise en miroir de configuration et tout cela se produit sans corruption. La minute où nous faisons la réplication de niveau SAN, cela se produit. Si SQL Server a provoqué la corruption comme celle-ci, cela ne serait pas aléatoire. SQL Server a presque des millions de lignes de code traitant de la corruption, de la corruption de la corruption et de la réduction du potentiel de la corruption. Vous n'obtenez pas cette question dans aucun autre environnement et cela ne propose que la réplication SAN, correcte?

Le micrologiciel est souvent une cause majeure de ces types de problèmes. Obtenez votre représentant de support Dell sur la ligne, ils auront beaucoup plus d'informations et de dépannage. Ne vous contentez pas d'un représentant paresseux, les données et le temps de votre entreprise sont sur la ligne. Ils ont beaucoup d'outils qui vérifient ce qui le causent dans l'arrière-plan et d'autres outils tels que DPAC qui pourrait aider. Ce n'est pas un problème de moteur SQL Server, nous aurons besoin du support complet des OP.

Edit: Si votre firmware est obsolète ou incompatible, obtenez une politique de l'équipe OPS qui gère le SAN qui indique qu'il conservera le firmware sur la pile des machines qu'ils gèrent à jour. Si cette SLA n'existe pas, vous devez en prendre une note à vos responsables, car vous êtes exposé à beaucoup d'autres problèmes en dehors de celui-ci.

Je suppose que vous utilisez une réplication de niveau de bloc SAN.

Cela pourrait souvent aussi être une inadéquation dans les paramètres. Peut-être différentes tailles de blocs, etc. Mais le SAN OS devrait être capable de détecter ces problèmes habituellement.