Mi entorno es el siguiente: VMWare 5.5 vitalized server MS Windows Server 2008R2 Enterprise domain y SQL Server 2008 R2 Enterprise . Almacenamiento centralizado con conexión de canal de fibra.
Tengo particiones en mi SQL Server DB. Tengo 2 file groups: uno con datos en vivo (FG1) , segundo con datos históricos (HDG) .
El segundo grupo de archivos es read-only. Cada mes hago movimiento en particiones: agrego datos nuevos (del mes anterior) a datos históricos. Este proceso es automático .
Movimos nuestra base de datos a un nuevo servidor. Inicialmente, tuve que hacer el proceso manualmente . Durante esta operación, mi espejo se rompe (después de la operación 3 - vea el flujo del proceso a continuación) con el siguiente error:
EN EL SERVIDOR PRINCIPAL:
FILA 0 en el REGISTRO:
Date 15.6.2015 20:54:11
Log SQL Server (Current - 16.6.2015 07:55:00)
Source spid84
Message
Setting database option MULTI_USER to ON for database MYDB.FILA 1 en REGISTRO:
Date 15.6.2015 20:54:11
Log SQL Server (Current - 16.6.2015 07:55:00)
Source spid18s
Message
Error: 1453, Severity: 16, State: 1.FILA 2 en el REGISTRO:
Date 15.6.2015 20:54:11
Log SQL Server (Current - 16.6.2015 07:55:00)
Source spid18s
Message
'TCP://10.201.27.154:5022', the remote mirroring partner for database 'MYDB', encountered error 823, status 3, severity 24. Database mirroring has been suspended. Resolve the error on the remote server and resume mirroring, or remove mirroring and re-establish the mirror server instance.OBSERVACIÓN: Ejecuté esta operación en el servidor antiguo muchas veces automáticamente y nunca experimento ese error.
EN EL SERVIDOR DE ESPEJO:
FILA 1 en REGISTRO:
Date 15.6.2015 20:54:11
Log SQL Server (Archive #3 - 15.6.2015 21:33:00)
Source spid17s
Message
Error: 823, Severity: 24, State: 3.FILA 2 en el REGISTRO:
Date 15.6.2015 20:54:11
Log SQL Server (Archive #3 - 15.6.2015 21:33:00)
Source spid17s
Message
The operating system returned error 5(Access is denied.) to SQL Server during a write at offset 0000000000000000 in file 'e:\Databases\MYDB_HISTRICAL.ndf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level 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.MI PROCESO SIGUE:
1. Realizo varias copias de seguridad de la base de datos (copias de seguridad completas, de grupo de archivos y TLog).
2. Configuré DB en RESTRICTED_USER(para permitir la eliminación de solo lectura del indicador de grupo de archivos histórico por script).
2a. Elimino la READ-ONLYbandera de mi grupo de archivos históricos.
3. Configuré DB en MULTI_USERpara permitir el funcionamiento normal de nuestro software.
4. Actualizo las particiones para que los datos se muevan al grupo de archivos históricos.
5. Repito los pasos 2 , 2a y 3 para poder configurar el grupo de archivos históricos READ ONLY nuevamente.
6. Hago copias de seguridad nuevamente.
¿Alguien tiene idea de por qué recibo ese error?
EDITAR: Recibimos el mismo problema durante la fase diferente del procedimiento. Esta es la única situación en la que el espejo se rompe, así que supongo que el problema está dentro del procedimiento, ¡pero no puedo entender por qué!
823 with sev 24es un problema de hardware. ¿Está haciendo copias de seguridad a nivel de archivo en lugar de copias de seguridad del servidor SQL nativo o se está ejecutando algún software antivirus en el servidor? Debe colocar alertas de agente sql para alertarlo cuando se produce el error 823; este script lo ayudará . Además, 823 es un error desagradable: dice que una operación de E / S falló en el nivel del sistema operativo y el subsistema de E / S está causando corrupción, el servidor sql no hizo cheques de página
VmWare replicationa remote host. Lo que noté hasta que le escribí una respuesta es que no podemos destruir el espejo de manera normal. El archivo estaba bloqueado y necesitamos stop SQL servicemover los archivos db a otro directorio. Desde ese momento todo está bien (verifico los registros usando sys.xp_readerrorlog). Otro pensamiento es si se produce una replicación de VmWare en ese mismo momento, pero no estoy seguro de cómo afectará esto al proceso (poco sé VmWare).
We do both type of backupsEso podría ser un problema. Las instantáneas de VM no deben usarse como una alternativa a las copias de seguridad del servidor SQL nativo.
Error: 823, Severity: 24Parece un problema de hardware. Verifique sus DISCOS para ver si se han estropeado. Ejecute checkdb en las bases de datos para asegurarse de que estén limpias.