Requisitos del subsistema de E/S de Microsoft SQL Server para la base de datos tempdb

Resumen

Microsoft SQL Server requiere que el subsistema de E/S que se utiliza para almacenar las bases de datos de sistema y de usuario totalmente respetan los requisitos de registro de escritura anticipada (WAL) a través de entidades específicas de i/OS. Estos requisitos son necesarios para respetar las propiedades ACID de transacciones: atómico, coherente, aislado y duradero. Se proporcionan detalles acerca de los requisitos de conformidad del subsistema de E/S en las siguientes referencias:La lista siguiente es un breve resumen de los requisitos:
  • Debe mantenerse el orden de escritura.
  • Se debe mantener la consistencia de escritura dependiente.
  • Siempre deben protegerse los escribe en medios estables.
  • Debe producirse rasgada prevención de i/OS.
Mantenimiento de durabilidad sigue siendo fundamental para todas las demás bases de datos pero puede ser relajada para la base de datos tempdb . En la siguiente tabla se resume algunos de los requerimientos críticos de i/OS para bases de datos de SQL Server.
Requisito de i/OSBreve descripciónSistema o usuariotempdb
Escriba pedidos

Consistencia de escritura dependiente
La capacidad del subsistema para mantener el orden correcto de las operaciones de escritura. Esto puede ser especialmente importante para el reflejo soluciones, requerimientos de consistencia de grupo y uso de protocolo de SQL Server WAL.ObligatorioRecomienda
Lectura después de escrituraLa capacidad del subsistema de servicio de solicitudes con la imagen de los datos más reciente de lectura cuando la lectura se emite después de cualquier escritura se complete correctamente.ObligatorioObligatorio
Supervivencia a través de la interrupciónLa posibilidad de que los datos permanezcan totalmente intacta (duradero) a través de una interrupción, como un sistema de reinicio.ObligatorioNo aplicable
Prevención de entrada-salida rasgadoLa capacidad del sistema para evitar la división de las solicitudes de E/S individuales.ObligatorioRecomienda
Sector de reescrituraEl sector sólo pueden escribirse en su totalidad y no puede reescribirse debido a una solicitud de escritura en un sector cercano.* No recomienda, sólo se permite si transaccional* No recomienda, sólo se permite si transaccional
Datos reforzadosLa expectativa de que cuando una solicitud de escritura o una operación FlushFileBuffers se completa correctamente, se ha guardado datos a medios estables.ObligatorioNo aplicable
Tamaño y alineación de los sectores físicosSQL Server interroga las ubicaciones de almacenamiento de archivos de datos y de registro. Todos los dispositivos son necesarios para admitir atributos del sector que permite a SQL Server para realizar escrituras en límites físicos sectores alineados y en múltiplos del tamaño del sector.ObligatorioObligatorio
* Transaccional sector reescribe implica operaciones de registro completo por parte del subsistema que permita un sector totalmente mover, reemplazar, o vuelve a la imagen original. Normalmente se desaconseja estos reescribe debido a la sobrecarga necesaria para realizar acciones adicionales. Un ejemplo de esto sería una utilidad de desfragmentación que está moviendo los datos del archivo. No se puede reemplazar el sector original en el archivo con la nueva ubicación del sector hasta que el nuevo sector y los datos están protegidos completamente. La reasignación del sector debe producirse de forma transaccional para que cualquier error, incluido un corte de alimentación, hace que el restablecimiento de los datos originales. Asegúrese de que tiene mecanismos de bloqueo durante este tipo de proceso para impedir el acceso de datos no válidos, con lo que respetar a los otros inquilinos de E/S de SQL Server.

Supervivencia a través de la interrupción

La base de datos tempdb es un área de borrador para SQL Server y se reconstruye en cada inicio del sistema de SQL Server. La inicialización reemplaza a cualquier necesidad de datos sobrevivir a un reinicio.

Operaciones de reescritura de sector transaccional

Para garantizar el éxito de los procesos de recuperación, como recuperación de rollback y el bloqueo, los registros deben almacenarse correctamente en medios estables antes de la página de datos se almacena y no puede reescribirse sin respetar propiedades transaccionales. Esto requiere que el subsistema y de SQL Server para mantener atributos específicos, como el orden de escritura, sector alineado y tamaño escrituras y otros tales atributos de seguridad de E/S descritos en los documentos anteriormente mencionados. La base de datos tempdb , la recuperación de errores es necesario porque la base de datos siempre se inicializa durante el inicio de SQL Server. Sin embargo, la base de datos tempdb aún requiere capacidades de restauración. Por lo tanto, algunos atributos del protocolo WAL pueden hacerse más flexible.

La ubicación de almacenamiento para la base de datos tempdb debe actuar en consonancia con los protocolos de la unidad de disco establecida. De todas formas, el dispositivo en el que se almacena la base de datos tempdb debe aparecer y actúan como un disco físico que proporciona lectura después de escritura capacidades. Las operaciones de reescritura de sector de transacciones pueden ser un requisito adicional de implementaciones específicas. Por ejemplo, SQL Server no admite modificaciones utilizando compresión del sistema de archivos NTFS porque la compresión NTFS puede volver a escribir sectores de registro que ya está escrita y considera reforzadas la base de datos. Un error durante este tipo de reescritura para hacer que la base de datos quede inutilizable, dañar datos que SQL Server ya se considera seguro.

Nota: SQL Server 2005 amplía el soporte o compresión para leer sólo las bases de datos y grupos de archivos. Consulte SQL Server 2005 Books Online para obtener información detallada.

Las operaciones de reescritura de sector transaccional son pertinentes para todas las bases de datos de SQL Server que incluyen la base de datos tempdb . Una creciente variedad de tecnologías de almacenamiento extendido utilice dispositivos y utilidades que pueden volver a escribir los datos de SQL Server se considera segura. Por ejemplo, algunas de las tecnologías emergentes realizan en caché o la compresión de datos. Para evitar daños graves de base de datos, cualquier sector de reescritura debe tener compatibilidad transaccional completo de tal manera que si ocurre una falla, los datos se vuelve a las imágenes de sector anterior. Esto garantiza que SQL Server nunca se expone a una interrupción inesperada o condición de daños de datos.

Puede colocar la base de datos tempdb en subsistemas de especialidad, como discos de RAM, memoria de estado sólido u otras implementaciones de alta velocidad que no se puede utilizar para otras bases de datos. Sin embargo, los factores clave presentados en la sección "Más información" deben considerarse al evaluar estas opciones.

Más información

Deben estudiarse cuidadosamente varios factores al evaluar la ubicación de almacenamiento de la base de datos tempdb . Por ejemplo, el uso de la base de datos tempdb implica, pero no se limita a la huella de memoria, plan de consulta y decisiones de i/OS. El ajuste adecuado y la implementación de la base de datos tempdb pueden mejorar la escalabilidad y la capacidad de respuesta de un sistema. Esta sección describe los factores clave para determinar las necesidades de almacenamiento de la base de datos tempdb .

Subsistemas de alta velocidad

Existen diversas implementaciones de subsistema de alta velocidad en el mercado que proporcionan el subsistema de E/S de SQL Server requisitos del protocolo pero que no proporcionan la durabilidad de los medios.

Importante: Siempre confirme con el fabricante del producto para garantizar el pleno cumplimiento de las necesidades de E/S de SQL Server.

Un disco RAM es un ejemplo común de dicha implementación. Discos RAM instalación los controladores necesarios y habilitar parte del disco RAM principal aparecen como y funcionan como cualquier unidad de disco está conectado al sistema. Todos los subsistemas de E/S deben proporcionar el pleno cumplimiento de los requisitos de E/S de SQL Server. Sin embargo, es obvio que un disco de RAM no es media duradera. Por lo tanto, una implementación como un disco RAM sólo puede utilizarse como la ubicación de la base de datos tempdb y no se puede utilizar para cualquier otra base de datos.

Claves para tener en cuenta antes de la instalación e implementación

Hay distintos puntos a tener en cuenta antes de la implementación de la base de datos tempdb en este tipo de subsistema. Esta sección utiliza un disco RAM como base para la discusión, pero se producen resultados similares en otras implementaciones de alta velocidad.

Seguridad de i/OS

Cumplimiento de normas de lectura después de escritura y escrituras de sector transaccional es un requisito indispensable. Nunca implementar SQL Server en cualquier sistema que no es totalmente compatible con los requisitos de E/S de SQL Server o corre el riesgo de daños y pérdida de los datos.

Páginas ya en la caché (caché de RAM doble)

Las tablas temporales son como todas las demás tablas en una base de datos. Son almacenados en caché por el grupo de búferes y controla las operaciones de escritura diferida. Almacenar páginas de la tabla temporal en un disco RAM hace RAM doble almacenamiento en caché, uno en el grupo de búferes y otro en el disco RAM. Esto lleva directamente fuera del tamaño posibles total del grupo de búferes y normalmente reduce el rendimiento de SQL Server.

Renunciar a RAM

El disco RAM señala una parte de la memoria RAM principal como su nombre indica. Hay varias implementaciones de discos RAM y las cachés de archivos basada en RAM. Algunas permiten también respaldo de las operaciones de E/S física. El elemento clave de la caché de archivos basada en RAM es que tarda directamente fuera de la memoria física que puede ser utilizada por SQL Server. Siempre tienen pruebas sólidas de agregar una caché de archivo basada en RAM mejora el rendimiento de la aplicación y no disminuye el rendimiento otro consulta o aplicación.

Ajustar primero

Una aplicación debe ajustar para quitar ordenaciones innecesarios y no deseados y los valores de hash que podrían provocar que el uso de la base de datos tempdb . Muchas veces la adición de un índice puede quitar la necesidad de la ordenación o hash en el plan completo, conduce a un rendimiento óptimo, sin requerir el uso de la base de datos tempdb .

Puntos de posible beneficio

Las ventajas de poner la base de datos tempdb en un sistema de alta velocidad pueden determinarse sólo a través de rigurosas pruebas y mediciones de las cargas de trabajo de la aplicación. La carga de trabajo debe estudiarse cuidadosamente para las características que podrá acogerse a la base de datos tempdb y la seguridad de i/OS debe confirmarse antes de la implementación.

Las operaciones de ordenación y hash funcionan conjuntamente con los administradores de memoria de SQL Server para determinar el tamaño del área de borrador en memoria para cada operación de ordenación o de hash. Tan pronto como los datos de ordenación o hash exceden el área de borrador en la memoria asignado, los datos pueden escribirse en la base de datos tempdb . Este algoritmo se ha ampliado en SQL Server 2005, lo que reduce los requisitos de uso de base de datos tempdb respecto a las versiones anteriores de SQL Server. Por ejemplo, utilizando una ordenación forzada pura de una tabla, índices, orden descendente y la misma configuración de hardware, SQL Server 2005 no muestra notables mejoras respecto a SQL Server 2000.

Precaución SQL Server está diseñado para tener en cuenta los niveles de memoria y las actividades de consulta actuales al tomar decisiones de plan de consultas que implican el uso de operaciones de base de datos tempdb . Por lo tanto, las ganancias de rendimiento varían considerablemente en función de diseño de aplicaciones y cargas de trabajo. Se recomienda realizar pruebas con la solución preferida para determinar las posibles ganancias y evaluar los requisitos de seguridad de i/OS antes de una implementación.

SQL Server utiliza la base de datos tempdb para controlar diversas actividades que implican ordena, algoritmos hash, el almacén de versión de fila y temp tablas:
  • Las tablas temporales se mantienen las rutinas de grupo de búfer común para las páginas de datos y generalmente no presentan las ventajas de rendimiento de las implementaciones de subsistema de Especialidad.
  • La base de datos tempdb se utiliza como un área de borrador para algoritmos hash y ordenaciones. Reducir la latencia de E/S para estas operaciones puede ser beneficioso. Sin embargo, saber al agregar un índice para evitar un valor hash o un criterio de ordenación puede proporcionar una ventaja similar.
Ejecutar las líneas de base con y sin la base de datos tempdb almacenada en el subsistema de alta velocidad a comparar los beneficios. Parte de las pruebas debe incluir consultas contra la base de datos de usuario que implican ordena, hashes o tablas temporales y, a continuación, confirme que estas consultas no se vean alteradas. Al evaluar el sistema, los indicadores de rendimiento siguiente pueden ser útiles.
IndicadorDescription/usage
Escrituras y lecturas de páginaMejorar el rendimiento de tempdb i/OS de la base de datos puede cambiar la velocidad de página lecturas y escrituras para las bases de datos del usuario debido a la menor latencia asociada con la base de datos tempdb i/OS. Para páginas de base de datos de usuario, el número total no debe variar entre la misma carga de trabajo.
Física leer y escribir bytes en la base de datos tempdbSi mueve la base de datos tempdb a un dispositivo, como un disco RAM, aumenta la E/S real de la base de datos tempdb , indica que la toma el grupo de búferes de memoria es la causa que se produzca la actividad de la base de datos tempdb de mayor. Este modelo es un indicador que la esperanza de vida de la base de datos de páginas también puede verse afectado de forma negativa.
Esperanza de vidaUna disminución en la esperanza de vida puede indicar un aumento de los requisitos físicos de i/OS para una base de datos de usuario. La disminución de velocidad probablemente podría indicar que la toma el grupo de búferes de memoria está obligando a las páginas de base de datos finalice prematuramente el grupo de búferes. Combinar con los otros indicadores y prueba para comprender completamente los límites de parámetro.
Rendimiento general
Uso de la CPU
Escalabilidad
Tiempo de respuesta
El objetivo principal de un cambio de configuración de base de datos tempdb es aumentar el rendimiento general. Las pruebas deben incluir una mezcla de cargas de trabajo repetibles que pueden escalarse horizontalmente para determinar cómo se ve afectado el rendimiento.

Algo así como una implementación basado en la compresión de disco de RAM puede funcionar bien con 10 usuarios. Sin embargo, con una mayor carga de trabajo, esto puede empujar niveles de CPU más allá de los niveles deseados y tienen efectos negativos sobre el tiempo de respuesta cuando las cargas de trabajo son altos. Se recomienda encarecidamente true pruebas de estrés y carga futura predicción.
Archivos de trabajo y las acciones de creación de tabla de trabajoSi mueve la base de datos tempdb a un dispositivo, como un disco RAM, cambia el plan de consulta al aumentar el número o el tamaño de los archivos de trabajo o mesas de trabajo, indica que la toma el grupo de búferes de memoria es la causa que se produzca la actividad de la base de datos tempdb de mayor. Este patrón es una indicación de que la esperanza de vida de páginas de base de datos también puede verse afectada de forma negativa.

Ejemplo de reescritura de sector transaccional

En el ejemplo siguiente, se describen la seguridad de los datos que es requerida por las bases de datos de SQL Server.

Suponga que un proveedor de disco RAM utiliza una implementación de compresión en la memoria. La implementación debe estar encapsulada correctamente proporcionando la apariencia física de la secuencia de archivo como si el sector se ha alineado y tamaño para hacer conscientes y correctamente protegidos de la implementación subyacente de SQL Server. Mire el ejemplo de compresión más cerca.
Acción
Sector 1 se escribe en el dispositivo y se comprime para ahorrar espacio.
Sector 2 se escriban en el dispositivo y se comprime con sector 1 para ahorrar espacio.
El dispositivo puede realizar las siguientes acciones para ayudar a proteger los datos del sector de 1 cuando se combina con datos de sector de 2.
Acción
Bloquear todas las escrituras en los sectores 1 y 2.
Descomprima el sector 1 en un área de borrador, salido el sector 1 actual como el activos que se obtengan datos.
Comprimir sectores 1 y 2 en un nuevo formato de almacenamiento de información.
Bloquear todas las lecturas y escrituras de sectores en 1 y 2.
Almacenamiento antiguo para sectores 1 y 2 con nuevo almacenamiento de información de Exchange.
Si el intento de exchange falla (rollback):
  • Restaurar el almacenamiento original para sectores 1 y 2.
  • Quitar los datos de 1 y 2 combina los sectores del área de borrador.
  • Un error en la operación de escritura del sector 2.
Desbloquear las lecturas y escrituras de sectores en 1 y 2.
La capacidad de proporcionar mecanismos de bloqueo alrededor de las modificaciones del sector y deshacer los cambios cuando se produce un error en el intento de cambio de sector se considera transitoriamente compatible. Para las implementaciones que utilizan almacenamiento físico para respaldo extendido, incluiría los aspectos de registro de transacción adecuados para ayudar a proteger y deshacer los cambios que se aplicaron a las estructuras en disco para mantener la integridad de los archivos de base de datos de SQL Server.

Cualquier dispositivo que permite la reescritura de sectores debe admitir la reescribe de forma transaccional para que SQL Server no está expuesto a la pérdida de datos.

Nota: La instancia de SQL Server se reinicia cuando se producen errores de reversión y E/S en línea en la base de datos tempdb .

Tenga cuidado al mover la base de datos tempdb

Tenga cuidado al mover la base de datos tempdb porque si no se puede crear la base de datos tempdb , SQL Server no se iniciará. Si no se puede crear la base de datos tempdb , inicie SQL Server mediante el (-f) parámetro de inicio y mover la base de datos tempdb a una ubicación válida.

Para cambiar la ubicación física de la base de datos tempdb , siga estos pasos:
  1. Utilice la instrucción ALTER DATABASE y la cláusula MODIFY FILE para cambiar los nombres de archivo físico de cada archivo en la base de datos tempdb para hacer referencia a la nueva ubicación física, como el nuevo disco.
    Alter database tempdb modify file (name = tempdev, filename = 'C:\MyPath\tempdb.mdf')

    Alter database tempdb modify file
    (name = templog, filename = 'C:\MyPath\templog.ldf')
  2. Detenga y reinicie SQL Server.

Certificaciones de producto de socio no son una garantía de compatibilidad o seguridad

Un producto de terceros o un proveedor en particular puede recibir una certificación del logotipo de Microsoft. Sin embargo, certificación de partner o un logotipo específico de Microsoft no certificar compatibilidad o idoneidad para un propósito particular en SQL Server.

Soporte técnico

Si se utiliza un subsistema con SQL Server que admite las garantías de E/S para el uso de bases de datos transaccionales, como se describe en este artículo, Microsoft proporcionará soporte técnico para aplicaciones basadas en SQL Server y SQL Server. Sin embargo, los problemas con, o causa, el subsistema hará referencia al fabricante.

Para problemas relacionados con la base de datos tempdb , servicios de soporte técnico de Microsoft le pedirá que reubicar la base de datos tempdb . Póngase en contacto con el fabricante del dispositivo para comprobar que ha implementado y configurado el dispositivo para uso de bases de datos transaccionales correctamente.

Microsoft no certifica ni valida que los productos de terceros funcionen correctamente con SQL Server. Además, Microsoft no proporciona ninguna garantía ni declaración sobre la idoneidad de ningún producto de terceros para su uso con SQL Server.

Referencias

Para obtener más información, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

826433 PRB: adicionales de SQL Server se agregaron diagnósticos para detectar problemas de E/S no notificados

828339 mensaje de error 823 puede indicar problemas de hardware o problemas del sistema en SQL Server

234656 utiliza el almacenamiento en caché de disco con SQL Server

304261 descripción de la compatibilidad con archivos de base de datos de red en SQL Server

913945 Microsoft no certifica que los productos de otros fabricantes funcionarán con Microsoft SQL Server

Requisitos de 910716 para SQL Server 2005 y SQL Server 2000 para admitir el espejado remoto de bases de datos de usuario

Factores clave de 917043 a tener en cuenta al evaluar los sistemas de memoria caché de archivo de terceros con SQL Server

Usar SSDs en máquinas virtuales de Azure para almacenar TempDB de SQL Server y las extensiones del grupo de búfer

Recomendaciones de rendimiento para SQL Server en máquinas virtuales de Azure

Optimización de la consulta de planes con el SQL Server Estimador de cardinalidad de 2014

Rendimiento de las consultas


La información contenida en este documento representa la visión actual de Microsoft Corporation sobre los temas tratados en la fecha de publicación. Dado que Microsoft debe responder a condiciones de mercado variables, no debe interpretarse como un compromiso por parte de Microsoft y Microsoft no puede garantizar la precisión de ninguna información presentada después de la fecha de publicación.

Este documento es meramente informativo. MICROSOFT NO OFRECE NINGUNA GARANTÍA, EXPRESA, IMPLÍCITA O LEGAL, SOBRE LA INFORMACIÓN CONTENIDA EN ESTE DOCUMENTO.

Cumplir todas las leyes de copyright aplicables es responsabilidad del usuario. Sin limitar los derechos protegidos bajo copyright, ninguna parte de este documento puede ser reproducida, almacenada en introducida en un sistema de recuperación o transmitida en ninguna forma o por ningún medio (electrónico, mecánico, fotocopia, grabación o no) o con ningún propósito, sin la previa autorización por escrito de Microsoft Corporation.

Microsoft puede tener patentes, solicitudes de patentes, marcas comerciales, derechos de autor o derechos de propiedad intelectual sobre los contenidos de este documento. Salvo lo dispuesto expresamente en cualquier acuerdo de licencia escrito de Microsoft, el suministro de este documento no le otorga ninguna licencia para estas patentes, marcas, derechos de autor y otros derechos de propiedad intelectual.

© 2006 Microsoft Corporation. Reservados todos los derechos.

Microsoft, Windows, Windows Server y SQL Server son marcas registradas o marcas comerciales de Microsoft Corporation en los Estados Unidos y otros países.
SQL Server requiere sistemas para admitir 'entrega garantizada a medios estables' tal como se indica en los Requisitos del programa de confiabilidad de SQL Server i/OSPara obtener más información acerca de los requisitos de entrada y salidos para el motor de base de datos de SQL Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

Requisitos de entrada y salida de motor de base de datos de 967576 de Microsoft SQL Server



Propiedades

Id. de artículo: 917047 - Última revisión: 14 ene. 2017 - Revisión: 1

Comentarios