¿Por qué la replicación de SAN está causando corrupción de base de datos aleatoria?

Question

Tener un problema extraño con una tecnología de recuperación de desastres que estamos tratando de implementar. El medio ambiente en ambos centros de datos es el mismo que tiene VMware y Dell Equallogic SANS, que son las mismas versiones.

Cuando replicamos de un centro de datos a otro, las bases de datos aleatorias se corrompen de alguna manera y terminan en modo sospechoso. Cada vez que intentamos este método, diferentes bases de datos se corrompan. ¿Es este un comportamiento en SQL que está causando esto? ¿Es este el software utilizado en la SAN para replicar causando estos errores?

He podido cambiar el estado de la base de datos al modo de emergencia y realizar DBCC CheckDB, pero es un problema y una base de datos diferente cada vez. Algunos de los errores que he encontrado son problemas de índice y problemas de desajuste de datos. Todavía estoy en proceso de verificar otras bases de datos para ver si puedo encontrar un patrón. Si encuentra otras cosas, me aseguraré de publicar si te ayudará.

He oído hablar de las personas que implementan este procedimiento con éxito y es la última tarea en el proyecto averiguar antes de que podamos cerrar la carta del proyecto.

Realmente esperaba que pudiéramos usar las características incorporadas de SQL Server, como la duplicación o la AO-AGS.

Las versiones de SQL son 2008 R2 y 2012. Estamos en el proceso de instalar algunos servidores SQL 2014 nuevos. Además, son todos estándar, no empresariales.

Cualquier entrada o cosas que pueda intentar sería de gran ayuda, ¡gracias de antemano !!

Editar # 1 8/6/15 12:50 PM CST - Los siguientes son algunos de los mensajes de error que he encontrado en el Visor de eventos de Windows, que es más o menos lo que produce DBCC CheckDB.

• eventid 605 - intento de buscar la página lógica (1: 22620) en la base de datos 26 falló. Pertenece a la unidad de asignación 72057594239385600 NO al 72057594249412608
• EventID 824 - SQL Server detectó un error de E / S basado en la consistencia lógica: Paged incorrecto (esperado 1: 1230; real 0: 0). Ocurrió durante una lectura de una página (1: 1230) en la base de datos ID 58 en offset 0x0000000099C000 en el archivo 'D: \ MyDatabase.mdf'. Los mensajes adicionales en el registro de errores de SQL Server o el registro de eventos del sistema pueden proporcionar más detalles. Esta es una condición de error grave que amenazó la integridad de la base de datos y debe ser correcta de inmediato. Complete un cheque de consistencia de base de datos completa (DBCC CheckDB).
• EventID 7886: una operación de lectura en un objeto grande falló al enviar datos al cliente. Una causa común para esto es si la aplicación se está ejecutando en el nivel de aislamiento no comprometido. Esta conexión será terminada.
• EventID 608 - No se ha encontrado una entrada de catálogo para la partición ID 72057594383564800 en la base de datos 23. Los metadatos son inconsistentes. Ejecute DBCC CheckDB para verificar una corrupción de metadatos.

Editar # 2 8/6/15 2:24 PM CST - Información recibida que restaurando los archivos .bak de las bases de datos en modo sospechoso corrige el asunto.

Answer 1

En relación con su comentario, sospecho de un problema relacionado con la OPS aquí en lugar de un problema de motor de SQL Server. Estos dispositivos SAN generalmente trabajan en la capa de bloques y algunos administran el registro de transacciones / archivo de datos Sincroniza mejor que otras, así como otras áreas.

Puede mostrar el equipo de OPS que no, SQL Server no corrompe aleatoriamente los datos de esta manera. Puede restaurar las copias de seguridad a otro servidor, la creación de reflejo, y todo esto sucede sin corrupción. En el momento en que hacemos la replicación a nivel de San. Si SQL Server causó la corrupción como esta, no estaría cerca. SQL Server tiene casi millones de líneas de código que se ocupan de la corrupción, la fijación de la corrupción y la reducción del potencial de la corrupción. ¿No obtiene este problema en ningún otro entorno y solo se encuentra con la replicación de San, correcta?

El firmware es a menudo una causa importante de estos tipos de problemas. Obtenga su representante de soporte de Dell en la línea, tendrán mucha más información y solución de problemas. No se conforme con un representante perezoso, los datos y el tiempo de su empresa están en la línea. Tienen muchas herramientas que revisen qué está causando esto en el fondo y otras herramientas como DPAC que podría ayudar. Este no es un problema del motor de SQL Server, necesitaremos el soporte completo de OPS.

Editar: Si su firmware está desactualizado o no coincidente, obtenga una política del equipo de OPS que administra el SAN, que afirma que mantendrán el firmware a través de la pila de las máquinas que se administran. Si este SLA no existe, debe tomar una nota de la misma a sus gerentes porque está expuesto a muchos otros problemas además de este.

Supongo que está usando la replicación de nivel de bloques de San.

, a menudo, también podría ser desajuste en la configuración. Tal vez diferentes tamaños de bloques, etc. pero el SAN debe poder detectar esos problemas por lo general.