• Artículo

Sesión de preguntas y respuestas sobre SQL Comprobaciones de coherencia inesperadas, solución de problemas sobre uso de memoria y más

Paul S. Randal

Phe notado algo raro sucede ya ha movido algunas de nuestras bases de datos a SQL Server 2005. Cuando se inicia el servidor de, veo mensajes en el registro de error que indica que SQL Server se ejecuta comprobaciones de coherencia en la base de datos como parte del proceso de inicio. Esto realiza para algunas bases de datos, pero no para las bases de datos del sistema. Las comprobaciones parecen ejecutar muy rápidamente independientemente de cómo grande es la base de datos y ocurre cada vez que se inicia SQL Server. ¿Puede explicar lo que sucede?

R Numerosas ocasiones un muy pocas personas han solicitado sobre esto en varios foros en línea. Éste es un ejemplo de uno de los mensajes de registro de error en cuestión:

2009-06-16 18:12:16.85 spid5s
CHECKDB for database 'master' finished without errors
on 2009-05-12 16:07:15.647 (local time).
This is an informational message only; 
no user action is required.

Ciertamente parezca DBCC CHECKDB (que realiza comprobaciones de coherencia de toda la base de datos) se ejecutó en "master"base de datos, pero en realidad no era. Este mensaje simplemente informa de una estadística acerca de la base de datos denominado el "buena conocida último"hora.

Desde en adelante en SQL Server 2005, siempre que DBCC CHECKDB finaliza la coherencia de la comprobación de una base de datos sin encontrar errores de coherencia (es decir, la base de datos es libre de daños), el tiempo que DBCC CHECKDB completado se indica en la página de inicio de la base de datos (una única página en la base de datos que almacena metadatos crítico acerca de él).

Cada vez que una base de datos se inicia (en base de datos o de inicio de instancia adjuntar), se comprueba la página de inicio para ver si hay una almacenados "última buena conocida"tiempo, y si es así, se notifica en el registro de errores. Lamentablemente, hay ninguna forma documentada para consultar este valor, pero puede utilizar un número de comandos no documentados para encontrarlo. Sankar Reddy, un MVP, tipo blogged recientemente una secuencia de comandos que informan de.

La lógica de almacenar el "buena conocida último"tiempo es que puede ser muy útil en una situación de recuperación de desastres para saber cuánto (potencialmente) una base de datos puede haber sido dañado.

Pme gustaría poder determinar la cantidad de memoria de SQL Server está utilizando cada base de datos. Observé que una instancia de SQL Server 2005 repentinamente con casi toda la memoria disponible en el servidor y estoy le preocupa que hay de un problema en algún lugar. ¿Es posible averiguar donde esta memoria se utiliza desde dentro de SQL Server?

Rla buena noticia es que esto no es probable que sea un problema. SQL Server 2005 utilizará tanta memoria como es capaz cuando sea necesario, pero responderá a solicitudes de presión de memoria del sistema operativo para liberar memoria. El uso de memoria repentino que está viendo es probablemente el grupo de búferes expandir para permitir más de la base de datos que se almacena en memoria.

El grupo de búferes (a veces llamado caché del búfer) forma parte de la capa de motor de almacenamiento de SQL Server y es responsable de administrar copias en memoria de las partes de los archivos de datos en las diversas bases de datos en la instancia de SQL Server. Si se inicia una consulta que requiere leer mucho de las páginas de la base de datos en la memoria (por ejemplo, para una exploración de tabla de gran tamaño o una combinación), el grupo de búferes puede tomar más memoria del servidor desde el sistema operativo, de manera que puede ampliar. Esto le permite dar cabida a las imágenes de página adicional en la memoria sin tener necesariamente descartar copias en memoria de otras páginas de base de datos que se utilizan para otras consultas.

Como una de las ventajas de agregar más memoria para SQL Server para que utilice es que el grupo de búferes puede ser mayor. Esto significa que más datos pueden ser en la memoria en cualquier momento determinado, provocando potencialmente E/s reducido y mejor rendimiento de carga de trabajo.

Hay otras causas posibles de SQL Server utilizando una gran cantidad de memoria, para la instancia, si se se almacenan en caché un gran número de planes de consulta diferentes en otra área de memoria denominada la caché de planes, pero mi estimación es que es más probable que sea el grupo de búferes que he descrito anteriormente.

En SQL Server 2005, puede determinar qué proporción del grupo de búferes se utiliza para cada base de datos mediante la vista de administración dinámica sys.dm_os_buffer_descriptors. Esta consulta sencilla le indicará cuántas páginas de 8 KB están en el grupo de búferes para cada base de datos:

SELECT   
  (CASE WHEN ([is_modified] = 1) THEN 'Dirty'
ELSE 'Clean' END) AS 'Page State',
  (CASE WHEN ([database_id] = 32767) THEN 'Resource Database'
ELSE DB_NAME (database_id) END) AS 'Database Name',
   COUNT (*) AS 'Page Count'FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id], [is_modified]
   ORDER BY [database_id], [is_modified];GO

Se explica esto un poco más en la entrada de blog "en el motor de almacenamiento: Novedades en el fondo de búfer?. "

Las otras secciones de memoria que utiliza SQL Server, puede utilizar el comando DBCC MEMORYSTATUS para supervisar la cantidad de memoria la instancia de SQL Server como con un todo, pero no permite el uso de memoria para dividirse por base de datos. Eche un vistazo artículo 907877, que describe "cómo utilizar el comando DBCC MEMORYSTATUS para supervisar el uso de memoria en SQL Server 2005."

Pcada tan a menudo, una de las bases de datos de nuestra instancia de SQL Server 2005 se convertirá en "sospechoso". Nos no puede tener acceso a la base de datos y su estado es SUSPECT. En ocasiones el estado muestra RECOVERY_PENDING. ¿Sé que esto está causado por los daños de algún tipo, sino que puede explicar lo que significa en realidad y cómo recuperar? Se suele acabar tener que restaurar desde copias de seguridad antiguos y perder los datos, que no es ideales.

Res la media de estados de mucha confusión sobre lo que estos dos base de datos, pero está corregir que está causados por algún tipo de daños. Ambos indican que algo ha salido malo de recuperación de errores.

Si una base de datos no se limpia cierra (en otras palabras, si hay transacciones no confirmadas cuando se cierra la base de datos), cuando la base de datos se inicia nuevo, debe ir a través de recuperación de errores. Recuperación de errores es el proceso de garantizar que todas las transacciones que se confirmaron en el momento de la base de datos apagado correctamente se reflejan en la base de datos y todas las transacciones que estaban sin confirmar en el momento del cierre desplegable no se reflejan en cualquier forma en la base de datos.

Para obtener una mucho más profunda explicación de cómo funciona la recuperación, consulte mi artículo en "Descripción registro y recuperación en SQL Server"del problema de febrero de 2009.

Una base de datos sabe si estaba apagado claridad presionada o no, esta información se almacena en la página de inicio de base de datos, que describe en la respuesta a la primera pregunta. Si es necesaria la recuperación de errores, a continuación, el registro de transacciones debe ser accesible, que almacena todos los detalles de los cuales deban ser reemplazados transacciones (confirmadas) y se deben deshacer las transacciones que (sin confirmar). Si el registro de transacciones no está disponible (porque se ha eliminado, por ejemplo), no puede iniciar la recuperación de bloqueo y el estado de la base de datos se convierte en RECOVERY_PENDING. El estado RECOVERY_PENDING significa que no se pudo iniciar la recuperación.

Si el registro de transacciones está disponible, recuperación de errores comienza a ejecutarse. Si no puede finalizar por cualquier motivo, la base de datos es transaccionalmente incoherente y el estado se convierte en SUSPECT. El estado de SOSPECHOSO significa recuperación iniciado pero no se pudo completar.

Hay dos razones que no se puede completar la recuperación. El primero es daños en el registro de transacciones, lo que un registro de transacciones no se puede procesar por SQL Server. La segunda es daños en los archivos de datos encontrado mientras se está tratando el sistema de recuperación para aplicar un registro de transacción a una página de base de datos, o para invertir los efectos de un registro de transacción en una página de base de datos.

Otro problema puede insertar una base de datos en el estado de SOSPECHOSO. Si una transacción es cancelada por un usuario o una aplicación y la base de datos encuentra daños al deshacer los efectos de la transacción, a continuación, no puede completar la volver y la base de datos es transaccionalmente incoherente. En este caso, se automáticamente desconecta la base de datos y el estado se establece en SUSPECT.

Hay dos formas comunes para recuperar en esta situación. El primero es restaurar copias de seguridad actualizadas. Si las copias de seguridad son antiguas, probablemente pierde trabajo y los datos y debe volver a evaluar la estrategia de copia de seguridad con el objetivo de copia de seguridad más frecuentemente para permitir la recuperación sin perder una gran cantidad de datos. Consulte mi artículo "de descripción copias de seguridad SQL Server"en el número de julio de 2009 de de la TechNet Magazine para algunas sugerencias para planear una estrategia de copia de seguridad. Si va a tomar la ruta de restauración, debe intentar siempre una copia de seguridad del registro cola, como se explica en el artículo, puesto que esto permitirá recuperar derecha hasta alcanzar el punto del problema que realiza la base de datos SUSPECT.

Si no hay copias de seguridad están disponibles, puede utilizar un mecanismo denominado EMERGENCY modo Reparar. Eche un vistazo a mi blog completa que describe esta característica, explica su uso y se muestra algunos ejemplos.

Ptenemos instalado con SQL Server 2005 un reflejo de base de datos sincrónico y se ha observado que a veces puede tardar bastante unos segundos para el reflejo de base de datos de conmutación por error cuando algo va mal con el servidor principal. Pensé que creación de reflejos de sincrónico bases de datos mediante un testigo debía para proporcionar la detección de errores instantánea. ¿Qué ocurre?

Rel uso de un servidor testigo con la creación de reflejos de base de datos simplemente permite al servidor espejo iniciar automáticamente la conmutación por error. El testigo acuerda (o no) con espejo si pueden "ver"el servidor principal. Si el testigo y el reflejo no pueden ver al principal, el reflejo inicia la conmutación por error y se convierte en el nuevo principal. La presencia de un servidor testigo en una base de datos de reflejo de configuración no tiene ninguna relación en cómo rápido un error es detectado o rápida de cómo se produce una conmutación por error.

Detección de error de instantánea es un concepto erróneo, rapidez se detecta un error depende del tipo de error. A continuación se describen algunos ejemplos:

  1. Se bloquea la instancia de SQL Server (que aloja la base de datos principal). Mientras Windows aún se está ejecutando y responde, el error debería detectarse en al menos un segundo. Cada un segundo, el testigo y espejo ping el principal. Si la instancia de SQL Server no está escuchando en el puerto TCP que se ha configurado, Windows sabe esto y puede responder inmediatamente que SQL Server no está allí.
  2. El servidor principal todo se bloquea. En este caso, Windows no es hay que decir que SQL Server no está escuchando en el puerto TCP definido, por lo que no hay nada decir existe es nada existe. En ese caso, no se detectarán el error hasta que transcurre el tiempo de espera asociado reflejo. Este es el número de pings de una vez por segundo debe no ser respondió a hasta que el reflejo declara un error por parte de la entidad principal. De forma predeterminada, este número se establece en 10 pings (y así 10 segundos), pero si se ha aumentado por cualquier motivo, la detección de error tardará más.
  3. Una unidad de registro de transacción falla en el principal. Inicialmente pasará nada excepto en que E/s empezará a poner en cola a la unidad de registro. Después de 20 segundos, SQL Server se imprimirá una advertencia en el registro de errores. Es no hasta que han transcurrido 40 segundos que SQL Server se declare la unidad del registro fuera de línea ­ y desconectar la base de datos así, desencadenar un error de creación de reflejos.
  4. Una página de base de datos resulta dañada. En este caso, si una consulta normal aciertos de los daños, en todo sucede nada al reflejo Sin embargo, si una transacción está deshaciendo y detecta los daños de página, la base de datos se convertirán en SUSPECT, como describí en la respuesta anterior, y que desencadenará un error de creación de reflejos inmediatamente.
  5. Si desconecta un archivo o grupo de archivos en la base de datos principal y no se ve afectado el grupo de archivos principal, a continuación, en Enterprise Edition, disponibilidad de la base de datos parcial se comenzar y un error no se producirá. En Standard Edition, sin embargo, un error se desencadenará.

Como puede ver, la velocidad con que se detecta un error de creación de reflejos depende realmente el tipo de error se produce y si se ha producido el reflejo tiempo de espera asociado.

Muchas gracias a l de Kimberly. Tripp de SQLskills.com para revisar técnicamente este mes es la columna.

Paul S.Randal es el director general de SQLskills.com, un director regional de Microsoft y MVP de SQL Server. Trabajó en el equipo de motor de almacenamiento de SQL Server de Microsoft de 1999 a 2007. Paul escribió DBCC CHECKDB/reparación para SQL Server 2005 y fue responsable del motor de almacenamiento del núcleo durante el desarrollo de SQL Server 2008. Randal es un experto en recuperación de desastres, en disponibilidad y mantenimiento de la base de datos y un regular moderador en congresos en todo el mundo. Él blogs en de SQLskills.com/blogs/paul y encontrará le en Twitter en de Twitter.com/PaulRandal.