PROGRAMA DE SQL Problemas de la suma de comprobación, elegir el modelo de recuperación correcta etc.
Paul S. Randal
QSoy un administrador de SharePoint y recientemente he descubierto que uno de mis bases de datos contenidos quedó dañado cuando mi coherencia mensual comprueba errores que encuentre. Se traza un volver a una controladora de RAID defectuosa y, después de realizar una investigación, nos está activados de sumas de comprobación en las páginas de base de datos. Mi pregunta es: ¿cómo puedo saber cuando no hay un problema de suma de comprobación sin esperar hasta que el plan de mantenimiento mensual?
AHay unas cuantas cosas que puede hacer. En primer lugar, puede agregar la opción WITH CHECKSUM a las copias de seguridad. Para copias de seguridad completas y diferenciales, esta opción hará que la operación de copia de seguridad para comprobar las sumas de comprobación página ve y producir un error si encuentra un daño. (Trata esto con más detalle de artículo del mes pasado, "Descripción de copias de SQL seguridad Server.")
En segundo lugar, considere ejecutar las comprobaciones de coherencia con más frecuencia que mensual. Se recomienda ejecutar algún tipo de comprobación de coherencia al menos semanalmente, ya que DBCC CHECKDB en la base de datos o quizás en una copia restaurada de la base de datos. Por supuesto, que se va a dependen de su nivel de comodidad con el subsistema de E/s.
En tercer lugar, agregue algunas alertas del Agente SQL. Puede establecer una alerta para desencadenar una variedad de factores, como un número de error concreto está provocado por SQL Server, un error con una gravedad determinada que se provoque o un contador de rendimiento cruce un umbral. Esta capacidad proporciona un mecanismo muy eficaz para supervisar problemas del servidor.
Cuando se desencadene una alerta, se envía un mensaje a "Operador" predefinido mediante una o todas estas opciones: un mensaje de localizador, correo electrónico o NET SEND. Puede utilizar sp_add_notification el procedimiento almacenado para definir un operador.
Lo que respecta problemas del subsistema de E/s son, los errores que le interesa son 823 y 824 de 825. Los dos primeros se provocan cuando se produce un problema de E/s (en concreto, 824 es cuando una comprobación de página se encuentra se rompa y 825 es cuando SQL Server tiene que intentar una operación de lectura varias veces antes de que finalice). Estos son todos los problemas que se desea conocer acerca de tan pronto como sea posible para limitar aún más el daño a la base de datos (y posiblemente el tiempo de inactividad para recuperar).
823 y 824 son ambos errores de nivel de gravedad 24 pero 825 es sólo un nivel de gravedad 10 "" mensaje informativo (para obtener más información, consulte mi blog " Un signo de poco conocida de inminente doom: error 825.") Para avisar de estos errores, debe definir una alerta para todos los errores de nivel de gravedad 24 y uno específicamente para el error 825 (de hecho, es una práctica recomendada tener una alerta para cada-nivel de gravedad de 19 a 25).
Para definir las alertas reales, puede utilizar T-SQL o Management Studio. A continuación es un ejemplo del código T-SQL para agregar una alerta para el error 825.
USE msdb;
GO
EXEC msdb.dbo.sp_add_alert @name = N'825 - Read-Retry Required',
@message_id = 825,
@severity = 0,
@enabled = 1,
@delay_between_responses = 0,
@include_event_description_in = 1,
@category_name = N'IO Subsystem Error';
GO
Puede encontrar más información cómo definir y agregar avisos, incluidos un tutorial paso a paso sobre cómo agregar alertas mediante Management Studio, en mi blog de Agente SQL ("categoría Error de plan de mantenimiento de SQL 2005 SP2 enmascaramiento daños)."
QSoy un desarrollador DBA quién es responsable de algún código y la base de datos que se ejecuta en. Ha sido acerca con algunos otros desarrolladores de base de datos acerca de cómo obtener un valor único para identificar las filas de la tabla. Me gustaría utilizar un GUID como clave de índice agrupado, pero los demás se acerca el que puede provocar problemas de rendimiento con índices. ¿Es este true y, si es así, puede explicar por qué?
UN Sí, es verdad: GUID son una de las causas principales de fragmentación del índice en las bases de datos de SQL Server.
Un GUID es un identificador único global. En SQL Server, éste es un valor de 16 bytes que es generado en SQL Server o en otro lugar (como a través de .NET en el cliente o mid-tier). GUID suele tienen un valor aleatorio a menos que genere con la función NEWSEQUENTIALID introducida en SQL Server 2005.
Esta función genera intervalos de GUID, que pueden ayudar a mitigar algunos de los problemas que describiré aquí. Pero se requiere generar un GUID de servidor, que no funciona en muchos entornos de aplicación porque debe generarse el identificador único que los datos se envían hacia abajo al nivel de datos.
Independientemente de donde se genera el GUID no secuencial, tenerlo como la clave a la izquierda en un índice significa que, puesto que la clave es esencialmente aleatoria, el punto de inserción de un registro nuevo en el índice está también aleatorio: el valor de clave de un registro determina su selección de ubicación en el índice. También significa que el GUID de 16 bytes estará presente en cada fila de cada índice no agrupado como parte del vínculo que permite que el motor de almacenamiento para desplazarse desde registros de índice no agrupado a registros de índice agrupado para obtener valores de columna para la lista de selección de consulta que no están en el índice no agrupado que se utilizó (normalmente también conocido como una búsqueda de marcador).
Como más registros se insertan en el índice, llenarán las páginas de almacenar los registros. Si se está insertando un registro en una página que ya esté completa (Recuerde que el valor de clave determina dónde va el nuevo registro), a continuación, debe dividir la página, con algunos registros mover a una página recién asignada. Una división de página es una operación costosa para llevar a cabo (una página nueva se asignado vinculada en el índice y registros se mueven a la nueva página), y hace que la fragmentación.
Divisiones de página provocar fragmentación lógica en el índice (que afecta al rendimiento de detección de intervalo) haciendo clic en el orden físico y lógico de páginas en el índice sea diferente. También hace que la densidad de página deficiente (donde no hay espacio en las páginas), que conduce a espacio desaprovechado en páginas y una mala utilización de disco, E/s y memoria.
Para obtener más información acerca de la fragmentación de índices y cómo detectar y quitar, consulte mi artículo de agosto de 2008 " Los mejores consejos para el mantenimiento de base de datos eficaz." Selección de una clave de índice agrupado buena es fuera del alcance de este artículo; podrá dejarlo a mi esposa, l. Kimberly Tripp para explicar. Consulte su blog excelente en el tema, que también se coloca en más detalles sobre los GUID y estructuras de índice agrupado "( GUID como KEYs PRIMARY o la clave de agrupación.")
QNuestra estrategia de alta disponibilidad es utilizar el trasvase de registros para un par de servidores secundarios. Nuestro equipo de administración es pressuring me hacen algunos uso de los servidores redundantes para guardar en gastos de capital. Mi idea es utilizar los servidores secundarios para permitir la notificación de consultas para ejecutar, también tendría la ventaja de descarga de la carga de informe desde el servidor principal. ¿Qué problemas podría ejecutar en hacerlo?
UN Este tipo de escenario es común mucho más en el clima económico actual, donde las compañías no desea tener servidores sentado alrededor parecen estar inactivo (incluso si va a proporcionar una copia redundante de la base de datos).
Como probablemente ya sabe, cuando haya configurado el trasvase de registros, puede definir cómo en que se restauran las copias de seguridad del registro de transacciones en un servidor secundario, ya sea WITH NORECOVERY o WITH STANDBY. El primero no permite cualquier acceso a la base de datos, mientras que el último permite acceso de sólo lectura a la base de datos. Utiliza un modo especial que se ejecuta de recuperación y la base de datos es transaccionalmente coherente, pero las operaciones realizadas se almacenan en un archivo deshacer independiente para que más se pueden restaurar las copias de seguridad del registro de transacciones (trataré esto más detalladamente mes siguiente en un artículo acerca de cómo utilizar RESTORE).
Para permitir realizar informes sobre el servidor secundario, va a utilizar WITH STANDBY para que las consultas informes puedan conectarse a la base de datos. Una vez permite conexiones de usuario, ejecutar inmediatamente frente a algunos problemas.
En primer lugar, con la opción WITH STANDBY puede conducir a copias de seguridad del registro transacción seeming de tardar mucho tiempo para restaurar en un servidor secundario, como el contenido del archivo deshacer debe reproducirse antes de que se puede restaurar la copia de seguridad siguiente del registro de transacciones. Esto puede ser un problema si el archivo para deshacer contiene un gran número de operaciones.
En segundo lugar, la restauración de una copia de seguridad del registro de transacciones no es una operación en línea. Nadie puede estar conectado a la base de datos para la duración de la restauración. Esto significa que todas las conexiones al servidor informe secundario deben se interrumpe, vuelven a conectar una vez finalizada la restauración. Aquí tiene un dilema: cuando ya es hora de restaurar la copia de seguridad siguiente del registro de transacciones, ¿terminar las conexiones de usuario o permitirle finalizar sus consultas? Eso completamente hasta.
¿Una cuestión a tener en cuenta si no decide terminar las conexiones: cómo largo permiten las consultas continuar antes de que se termina de forzosamente? Cuanto más tiempo espere, más transcurrieron desde la última copia de seguridad del registro se ha restaurado y obtiene de la base de datos secundario al principal del subyacente más. Esto podría ser un problema si a continuación, tiene que conmutar por error a secundario, porque podría haber una cola de copias de registro de seguridad espera restaurarse para poner la base de datos lo actualizada como sea posible, minimizar la pérdida de datos.
Puede encontrar más información acerca de estas opciones, así como sobre la supervisión problemas como período de tiempo desde la última restauración copia de seguridad del registro en el servidor secundario, en el tema de libros en pantalla" Uso de servidores secundarios para procesamiento de consultas."
Q¿Cómo se puede elegir el modelo de recuperación correcta? De lo que he leído, parece que deben utilizar masivo para reducir el tamaño de registro de transacciones, pero parece que el tamaño del registro aún mantiene crecimiento. ¿Es posible utilizar un modo que no utilizar el registro de transacciones en absoluto y evitar completamente el problema todo?
UN NA de las solicitudes que he oído varias veces es para una base de datos no iniciado, cuando no hay registros de transacciones se generan en absoluto, especialmente para tempdb, que personas vista como una base de datos borrador porque se vuelve a crear en el inicio del servidor.
Lo que yo sé, nunca sucederá para SQL Server. La mejor que obtendrá es el modo BULK_LOGGED, que drásticamente corta hacia abajo de la cantidad de registro de transacciones generados para determinadas operaciones (como índice vuelve a generar y cargas de forma masiva). Todas las bases de datos, incluso tempdb, deben tener algún nivel de registro para permitir transacciones revertir (es decir, para deshacer todas las operaciones que formaban parte de la transacción) en el caso de un usuario cancelar la operación o algún error causando la operación produzca un error.
Lo que es más importante para bases de datos aparte de tempdb, es que si se produce un error del sistema, la base de datos debe poder recuperar sin dejar datos transaccionalmente incoherentes o estructuralmente incoherente (es decir, dañar) base de datos. ¿Imagine si no hay ningún registro de qué ha tenido cambiar en la base de datos antes el bloqueo, cómo ejecutaría SQL Server recuperación? Puede leer más acerca del funcionan de registro y recuperación en mi artículo de febrero de 2009 " Registro de descripción y recuperación en SQL Server."
Para elegir un modelo de recuperación, una pregunta reemplaza determinará su elección: ¿confirma que desea poder hacer la recuperación de "punto-in-time" o "actualizada" en el caso de desastre? Si es así, se va a utilizar el modelo de recuperación FULL (y posiblemente el modelo _LOGGED BULK) en alguna ocasión. Si no está interesado en hacerlo, utilice el modelo recuperación SIMPLE.
La razón para utilizar SIMPLE en lugar de FULL si desea poder recuperar la base de datos (sin pérdida de trabajo desde la última base de datos o diferencial) es que con el modelo recuperación SIMPLE, no tendrá que realizar copias de seguridad del registro para administrar el tamaño del registro de transacciones de transacción.
Ahora, puede haber otros motivos por qué tiene que utilizar el modelo de recuperación FULL, por ejemplo, si desea utilizar el reflejo (DBM sólo admite el modelo de recuperación FULL) de base de datos o trasvase de registros (registro envío admite los modelos de recuperación BULK_LOGGED y FULL). En cualquier caso, vamos a tiene que asegurarse de que va a llevar transacción copias de seguridad del registro para que el registro no crezca demasiado grande (incluso si obtendrá descartar ellos).
He mencionado que puede a veces desea utilizar el modelo de recuperación BULK_LOGGED, en lugar de constantemente ejecutar en ese modo. Esto es porque hay algunas limitaciones alrededor tomar y restaurar desde copias de seguridad del registro cuando se ha producido una operación iniciado como mínimo en el modelo de recuperación BULK_LOGGED desde la última copia de registro de transacciones. Los detalles son demasiado complejas para explicar en esta columna, pero puede averiguar más sobre esto y sobre cómo elegir un modelo de recuperación en general, en el tema de libros en pantalla " Introducción al modelo de recuperación."
Paul S. Randal es el director de SQLskills.com, un director regional de Microsoft y un 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. Paul es un experto en recuperación ante desastres, alta disponibilidad y mantenimiento de la base de datos y es un regular moderador en congresos en todo el mundo. Blogs en SQLskills.com/blogs/paul, y puede encontrar le Twitter en Twitter.com/PaulRandal.