• Artículo

SQL Q & A Coherencia de base de datos, las tablas temporales y mucho más

Paul S. Randal

QHa observado algún comportamiento extraño muy en uno de nuestros bases de datos de SQL Server 2005. Hemos ejecutado un DBCC CHECKDB en la base de datos como parte de nuestro mantenimiento de la noche base de datos y algunos noches la DBCC devuelve errores de daños en. Lo raro es que no vemos página sumas de comprobación de errores durante el día anterior y si manualmente ejecutar DBCC CHECKDB por la mañana después el error de trabajo de mantenimiento, han desaparecido los daños. ¿Puede explicar lo que sucede en? Esto se ha ocurre para aproximadamente un mes y que me preocupa que no se puede confiar DBCC CHECKDB.

AEs conveniente ver que haya DBCC CHECKDB como parte de su mantenimiento regular y que están habilitadas las sumas de comprobación de página. El comportamiento que describe puede ser muy desconcertante cuando se produce, casi parece DBCC CHECKDB se dar resultados incorrectos. Pero esta situación ocurre cada tan a menudo, no hay indicaciones de tiempo de ejecución de daños en, DBCC CHECKDB encuentra daños en y, a continuación, muchas horas más tarde los daños han desaparecido cuando DBCC CHECKDB se ejecute de nuevo. Echemos este paso a paso.

En primer lugar, es muy común de daños DBCC CHECKDB va a presentar que no se envió durante las operaciones normales de bases de datos. Aunque las sumas de comprobación de página son un método excelente de detectar daños causados por el subsistema de E/s, son eficaces sólo cuando se leen las páginas de datos por SQL Server después de producirse un daño.

Imagine que una página de datos tiene una suma de comprobación página aplicado y, a continuación, está dañado en algún momento posterior mediante el subsistema de E/s. Aunque la suma de comprobación de página detectarán el daño, es sólo cuando la página se lee en la memoria por SQL Server que se valida la suma de comprobación de página y se detecta el daño. Si nunca se lee esa página por SQL Server, nunca se descubrió el daño. Eso es fundamental para habilitar las sumas de comprobación de página y con frecuencia realizan comprobaciones de coherencia, comprobaciones de coherencia leen todas las páginas en la base de datos y validar sus sumas de comprobación de página y descubrir daños en tan pronto como sea posible.

En su caso, parece como si se han producido los daños en las páginas de datos que no se han leído como parte de las operaciones normales de base de datos y por lo que los daños no encontrados hasta DBCC CHECKDB leer las páginas dañadas. Aunque parece como si las sumas de comprobación páginas no detectó el daño que debe, no es el caso.

En segundo lugar, "desaparece" daños pueden producir bastante fácilmente entre sucesivas ejecuciones de DBCC CHECKDB, pero sólo en las bases de datos donde se producen cambios entre los dos segmentos DBCC. Supongamos que una página está realmente dañada y DBCC CHECKDB informa de está dañado. Ahora decir que la página es, a continuación, asignación de una tabla (por ejemplo, porque se convierte en blanco). Una posterior DBCC CHECKDB no se léalo este momento y, por tanto, no informará está dañado. Lecturas de DBCC CHECKDB sólo asignan páginas (páginas de significado que están en uso actualmente). En su caso, me adivinar que el resto del trabajo de mantenimiento por la noche incluye reconstrucciones de índice o reorganizar, los cuales pueden alterar drásticamente el conjunto de páginas que se asignan a un objeto en particular o el índice. Esto podría cuenta para el comportamiento que está viendo. Una reconstrucción de índices desasigna las páginas dañadas como efecto secundario y, a continuación, la siguiente DBCC CHECKDB incluye volver desde el principio.

Para detectar las páginas dañadas, modificar el trabajo de mantenimiento para que se detiene si el paso de DBCC CHECKDB se produce un error. De este modo, podrá manualmente comprobar los daños y tomar más acción.

QSe está planeando realizar la actualización de SQL Server 2000 directamente a SQL Server 2008, omitiendo de SQL server 2005. Pero soy preocupado tempdb. Esto ya causado problemas por nosotros en SQL Server 2000, que se tengan gran cantidad de corta duración tablas temporales. De lo que he entendido, tempdb se utiliza mucho más mucho ahora (en SQL Server 2005 y SQL Server 2008) y aprovisionamiento especial se pueden realizar para evitar la eliminación después de una actualización de rendimiento. Explique por qué es el caso y ¿qué debe hacer?

ADesde su pregunta, me adivinar que ha tenido que implementar la arquitectura de una archivo por procesador tempdb que se requiere normalmente cuando muchas tablas temporales efímeras se crean mediante varias conexiones a bases de datos. Y es posible que tengan incluso habilitar el seguimiento de 1118 marca (consulte" Mejoras de concurrencia para la base de datos tempdb"para obtener más información sobre esto).

Aunque hay la posibilidad de utilizar tempdb heavier en SQL Server 2005 onward, no verá este a menos que específicamente utilice características que se basan en tempdb. Tenga en cuenta que si toma una solución que experimentado problemas de rendimiento de tempdb con SQL Server 2000 y actualizarla a SQL Server 2008 en el mismo hardware, debe en muchos casos ver los problemas de rendimiento solucionará un poco a causa de algunos cambios específicos de tempdb en el motor de almacenamiento de SQL Server de SQL Server 2005.

Las características que uso elevado de tempdb en SQL Server 2005 y SQL Server 2008 son:

  • Las operaciones de índice en línea
  • Desencadenadores DML
  • Conjuntos de resultados activo múltiple (MARS)
  • Aislamiento de instantánea (nivel de transacción y nivel de instrucción)

Cuatro de estas características usar una tecnología subyacente denominada control de versiones para almacenar en un momento del tiempo distintas versiones de registros de datos. En pocas palabras, estas versiones de registro se almacenan en el almacén de versiones de tempdb, todos los bases de datos de usuario para compartir el mismo almacén de versiones de la única tempdb. El más utilizas estas características, el heavier el uso del almacén de versiones y, por tanto, será tempdb y la allí más posible serán para el impacto de rendimiento.

La clave para cualquier actualización correcta consiste en implementar una carga representativa de producción en un sistema de prueba con el nuevo esquema y medir el rendimiento para evitar sorpresas que puede darse si tuviera que vaya directamente de producción.

Por desgracia, esta discusión es forma fuera del alcance de esta columna para portada exhaustiva, pero hay algunos recursos excelente disponibles que se recomienda que desprotección:

QSe está implementar un plan de mantenimiento de base de datos por la noche que incluya mejorar el rendimiento del índice. He oído que la opción el factor de relleno" para los índices puede quitar por completo la necesidad de mantenimiento de los índices. ¿Es true? Parece que sufren algunos índices en nuestra base de datos de la fragmentación y algunos no. Debe establecemos un factor de relleno predeterminado para la base de datos que se aplicará a todos los índices y si es así, ¿qué valor debe usamos?

AEl valor de factor de relleno de hecho puede utilizarse para mitigar parcialmente la necesidad de mantenimiento de índices, pero rara vez pueden utilizarse para quitar completamente la necesidad. En pocas palabras, el valor de factor de relleno indica el motor de almacenamiento para dejar un determinado porcentaje de espacio libre en las páginas de índices agrupados y cuando se crea o volver a generar. (Observe que el valor de factor de relleno no se mantiene durante las operaciones normales de insertar o actualizar y eliminar). Un factor de relleno de 90, por ejemplo, deja un 10 % de espacio libre. Factores de relleno de 0 o 100 ambos no dejar espacio libre (esto ha sido la fuente de mucha confusión).

La idea es que espacio queda en las páginas, que permite registros en la página para expandir o nuevos registros a insertar en la página sin causar una operación costosa, provocando la fragmentación denominada una división de página. Especifica un porcentaje de espacio libre para las páginas pueden convertirse en fuertemente más completos hasta que se la siguiente operación de mantenimiento índice produzca, que restablece el factor de relleno de nuevo. El truco es elegir un porcentaje que minimiza las divisiones de página entre las operaciones de mantenimiento del índice.

Para una base de datos OLTP (procesamiento de transacciones en línea), no hay ninguna respuesta fácil excepto para elegir un factor de relleno para cada índice basado en trial y error. Para los almacenes de datos, que no cambian los índices, el factor de relleno debe ser 100 % (significado no queda espacio libre en las páginas). Es muy raro que se modifica el factor de relleno predeterminado para una base de datos no es el predeterminado de 100 %, ya que los factores de relleno mejores para varios índices son normalmente diferentes. Los libros en pantalla de SQL Server 2008 topic" Factor de relleno"tiene mucha más información sobre esto.

Otra opción es cambiar el índice de modo que no se producen las divisiones de página. Esto podría implicar cambiar la clave de índice para que no sean aleatorio inserta (por ejemplo, mediante no una clave principal de GUID aleatoria) o impidiendo las operaciones que cambiar el tamaño de columnas de longitud variable.

QVamos a ser pasar a SQL Server 2008 tan pronto como Service Pack 1 incluye fuera y una de las características que buscas hacia delante a utilizar es FILESTREAM, tal como se elimina el límite de tamaño de 2 GB para los valores de columna. ¿Antes de que se comienza diseñando la próxima versión de nuestro esquema para utilizar el tipo de datos FILESTREAM, existen los inconvenientes o problemas se deben tener en cuenta que puede provocar problemas en producción?

AEs siempre una idea inteligente para determinar todas las características de una característica nueva antes de diseñar, en un nuevo esquema o la aplicación, especialmente uno que utiliza tecnologías fuera de SQL Server, como es el caso de FILESTREAM. La mayoría de la información que necesita está contenida en un documento escribimos para el equipo de SQL Server denominado" Almacenamiento FILESTREAM en SQL Server 2008." Recomienda que lea dicho documento para obtener una explicación completa, pero se resumen las principales áreas de preocupación aquí.

En primer lugar, los datos FILESTREAM se almacenan en el sistema de archivos NTFS en lugar de dentro de los archivos de datos de SQL Server. Hay varios pasos de configuración que se deben realizar para asegurarse de que NTFS funciona bien con un gran número de archivos en un directorio único, tales como activar desactivar 8.3 la generación de nombre, la configuración de NTFS clúster tamaño correctamente y, posiblemente, separando el FILESTREAM datos en separe los discos físicos de otros datos.

En segundo lugar, debe asegurarse de que el tamaño promedio de los datos almacenados mediante FILESTREAM será 1 MB o superior. Investigación ha demostrado para tamaños de datos de menos de 256KB; en ocasiones, entre 256 KB y 1 MB, un mejor rendimiento se puede obtener almacenar los datos directamente dentro de SQL Server en lugar de utilizar un mecanismo como FILESTREAM.

En tercer lugar, debe considerar las operaciones que se va realizar en los datos FILESTREAM. Las actualizaciones parciales no se admiten para los datos FILESTREAM, por lo que incluso actualizar un solo byte de un valor de datos de los 200 MB dará como resultado un valor de los 200 MB completamente nuevo que se va a crear. Aparte de ser una operación costosa, esto puede provocar la fragmentación de nivel de NTFS, que puede reducir aún más el rendimiento. Si las actualizaciones parciales son commonplace en la aplicación, algún tipo de procesamiento por lotes mecanismo puede ser necesario para evitar las actualizaciones de un único valor FILESTREAM repetidas.

Por último, debe considerar la compatibilidad de característica cruzados de FILESTREAM con las tecnologías de alta disponibilidad. FILESTREAM admite totalmente las operaciones de copia de seguridad y restauración (incluido en un momento del tiempo recuperación), trasvase de registros y la replicación. No, sin embargo, es compatible con la creación de reflejos de bases de datos de ninguna manera de SQL Server 2008. (Ha sido dijo que esto se resolverá en la próxima versión de SQL Server.)

Esto es sólo una idea de las cosas que tener en cuenta. Para la imagen completa, debe leer las notas del producto. Como con cualquier característica nueva, sin embargo, antes de diseñar una aplicación alrededor del mismo, asegúrese hacer algunas pruebas exhaustivas para ver si sus capacidades coincide con los requisitos. Dado que FILESTREAM también engloba el almacenamiento NTFS, también podría hacer preproducción rendimiento y recuperación de desastres de pruebas para asegurar que nada viajes hasta que vaya directo.

S. Paul Randal es el director de administración de SQLskills.comy un MVP de SQL Server. Trabajado en el equipo de motor de almacenamiento de SQL Server en Microsoft desde 1999 a 2007. Paul escribió DBCC CHECKDB y reparar para SQL Server 2005 y era responsable del motor de almacenamiento principal durante el desarrollo de SQL Server 2008. Paul es un experto en recuperación ante desastres, una alta disponibilidad y mantenimiento de la base de datos y es un moderador habitual en conferencias de todo el mundo. Blogs en SQLskills.com/blogs/paul.