Corrupción de datos entre máquinas virtuales con VMWare.

Por: Daniel Torres Garrido

Recién abordamos un incidente en el que se tenía una instalación con Dynamics CRM 2013 UR1 que utilizaba una instancia con SQL Server 2012. Las dos máquinas fueron construidas en servidores virtuales con VMWare con Windows Server 2012. En términos generales a través de la consola de Dynamics CRM podemos crear una nueva organización, solo hay que dar clic derecho y seleccionar la opción de New Organization.

Internamente Dynamics realiza varios procesos para crear una nueva organización, entre estos está la creación de la respectiva base de datos en la instancia de SQL Server. En nuestro caso una vez que creábamos la nueva organización pasaban un par de segundos y obteníamos el siguiente error:

Al revisar la instancia de SQL Server 2012 vimos que la respectiva base de datos, que podemos identificar por el nombre asignado al crear la nueva organización, estaba en estatus Recovery Pending. En los logs de SQL Server encontramos los siguientes mensajes de error:

Converting database 'crmX_MSCRM' from version 655 to the current version 706.

Database 'crm11_MSCRM' running the upgrade step from version 655 to version 668.

Could not continue scan with NOLOCK due to data movement.

2014-03-03 13:17:46.35 spid84      Error: 928, Severity: 20, State: 1.

2014-03-03 13:17:46.35 spid84      During upgrade, database raised exception 601, severity 12, state 3, address 000003FA2644C1FD. Use the exception number to determine the cause.

La primera línea llamó mi atención ya que SQL Server intenta convertir la base de datos de una versión 655 (SQL Server 2008) a la versión 706 (SQL Server 2012). Inicialmente no hacía sentido ya que por lo general las aplicaciones ejecutan un script para crear una base de datos desde cero. No hay forma de que en SQL generemos una base de datos a través del comando CREATE DATABASE en donde indiquemos la versión de la base de datos. Esto nos hizo sospechar que Dynamics utilizaba archivos MDF/LDF de una base de datos creada en 2008 como layout para generar el resto de las organizaciones.

Utilizando la herramienta Process Monitor confirmamos que Dynamics guarda un archivo MDF (sin LDF) localmente en el servidor de aplicación en la ruta: Program Files\Microsoft Dynamics CRM\LangPacks\1033\sql\6.0\mscrm6.mdf. Este archivo lo copia a la carpeta de datos que por defecto se configuró en la instancia de SQL y después ejecuta el comando: CREATE DATABASE crmX_MSCRM ON (FILENAME = [F:\Program Files\Microsoft SQL Server\MSSQL11.CONTOSO\DATA\mscrm6.mdf]) FOR ATTACH

Algo que generaba más incertidumbre es que de aproximadamente 10 intentos que hacíamos para crear una nueva organización llegaban a funcionar solo en 1 ocasión. Para validar el proceso lo que hicimos fue copiar manualmente el archivo mscrm6.mdf del servidor de Dynamics al de SQL Server y ejecutar el CREATE DATABASE FOR ATTACH. Para nuestra sorpresa de todos los intentos que hicimos al copiar manualmente y restaurar la base el 100% terminaron con éxito.

Dado que hasta este punto no teníamos una idea clara de la causa raíz regresamos al error original. El error 829 con la excepción 601 sugiere como tal corrupción. Existe un método para habilitar el trace flag 4135 para solventar el error 829. Después de hacerlo creamos una nueva organización. El error 829 y la excepción 601 desaparecieron pero obtuvimos una nueva excepción:

2014-03-03 13:41:17.960 spid64 Error: 824, Severity: 24, State: 2.

2014-03-03 13:41:17.960 spid64 SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x4f04323c; actual: 0xa093554f). It occurred during a read of page (1:1199) in database ID 16 at offset 0x0000000095e000 in file 'F:\Program Files\Microsoft SQL Server\MSSQL11.CONTOSO\DATA\crmX_MSCRM.mdf'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

El error 824 en SQL Server está asociado a corrupción en la base de datos como se indica en el siguiente KB:

How to troubleshoot Msg 824 in SQL Server

https://support.microsoft.com/kb/2015756/en-us

Hasta este punto lo que pudimos concluir es que el archivo MDF con el que se restauraba la base de datos estaba corrupto. La principal sospecha que tuvimos es que una vez que el archivo era copiado al servidor algún otro proceso lo tomaba para su uso mientras SQL Server lo restauraba y por consiguiente el archivo se corrompía. Utilizando de nuevo la herramienta Process Monitor tomamos un par de trazas en el servidor de SQL Server mientras se creaba la nueva organización sin embargo no identificamos ningún proceso accediendo al archivo MDF, lo mismo hicimos en el servidor de Dynamics y tampoco encontramos algo que nos diera luz.

Haciendo una búsqueda encontramos el siguiente Bug reportado por VMWare:

Possible data corruption after a Windows 2012 virtual machine network transfer (2058692) https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058692

Los síntomas del KB dicen lo siguiente:

On a Windows 2012 virtual machine using the default e1000e network adapter and running on an ESXi 5.0/5.1 host, you experience these symptoms:

• Data corruption may occur when copying data over the network.
• Data corruption may occur after a network file copy event.

Note: This issue occurs infrequently and only on very large data transfers between virtual machines.

En nuestro caso las máquinas virtuales utilizaban el adaptador de red por defecto e1000e que allí se menciona. Al aplicar la solución que se indica en el KB el problema se resolvió.

Ciertamente no he trabajado en muchos casos relacionados con este bug pero eventualmente hay varios escenarios en los que esto podría causar problemas al transferir archivos MDF/LDF de un servidor a otro que utilicen VMWare y cumplan con las condiciones del KB. Es importante considerar este KB cuando existan problemas de corrupción de bases de datos después de una migración.