Descripción de los algoritmos de registro y almacenamiento de datos que amplían la confiabilidad de los datos en SQL Server

Versión original del producto: SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005
Número de KB original: 230785

Resumen

En este artículo se describe cómo los algoritmos de datos y registro de Microsoft SQL Server amplían la confiabilidad y la integridad de los datos.

Para obtener más información sobre los conceptos subyacentes de los motores y sobre el algoritmo para la recuperación y la semántica de vulnerabilidad de aislamiento (ARIES), consulte el siguiente documento transacciones de ACM en sistemas de base de datos (en volumen 17, número 1, marzo de 1992):

Vínculo externo: ARIES: un método de recuperación de transacciones que admite bloqueos de granularidad fina y reversiones parciales mediante el registro de escritura anticipada

El documento aborda las técnicas de SQL Server para ampliar la confiabilidad y la integridad de los datos como relacionadas con los errores.

Se recomienda leer los siguientes artículos en Microsoft Knowledge Base para obtener más información sobre el almacenamiento en caché y las discusiones sobre el modo de error alternativo:

• Descripción de los controladores de disco de almacenamiento en caché en SQL Server

• Información sobre el uso de cachés de unidades de disco con SQL Server que todos los administradores de bases de datos deben conocer

Términos usados en este artículo

Antes de comenzar la explicación detallada, algunos de los términos que se usan en este artículo se definen en la tabla siguiente.

Término	Definición
Con respaldo de batería	Instalación de copia de seguridad de batería independiente y localizada directamente disponible y controlada por el mecanismo de almacenamiento en caché para evitar la pérdida de datos. No es una fuente de alimentación ininterrumpida (UPS). Un UPS no garantiza ninguna actividad de escritura y se puede desconectar del dispositivo de almacenamiento en caché.
instancias y claves	Mecanismo de almacenamiento intermedio usado para optimizar las operaciones de E/S físicas y mejorar el rendimiento.
Página desfasada	Página que contiene modificaciones de datos que todavía se van a vaciar en un almacenamiento estable. Para obtener más información sobre los búferes de páginas desfasadas, vea Escribir páginas en los Libros en pantalla de SQL Server. El contenido también se aplica a Microsoft SQL Server 2012 y versiones posteriores.
Error	Cualquier cosa que pueda provocar una interrupción inesperada del proceso de SQL Server. Algunos ejemplos son: interrupción de energía, restablecimiento del equipo, errores de memoria, otros problemas de hardware, sectores incorrectos, interrupciones de unidades, errores del sistema, etc.
Vaciar	Forzar un búfer de caché a un almacenamiento estable.
Bloquear temporalmente	Objeto de sincronización usado para proteger la coherencia física de un recurso.
Almacenamiento no volátil	Cualquier medio que permanezca disponible en todos los errores del sistema.
Página anclada	Página que permanece en la caché de datos y no se puede vaciar en almacenamiento estable hasta que todos los registros de registro asociados estén protegidos en una ubicación de almacenamiento estable.
Almacenamiento estable	Igual que el almacenamiento no volátil.
Almacenamiento volátil	Cualquier medio que no permanezca intacto en todos los errores.

Protocolo de registro de escritura previa (WAL)

El término protocolo es una excelente manera de describir WAL. Es un conjunto específico y definido de pasos de implementación necesarios para asegurarse de que los datos se almacenan e intercambian correctamente y se pueden recuperar en un estado conocido si se produce un error. Al igual que una red contiene un protocolo definido para intercambiar datos de forma coherente y protegida, también describe al protocolo WAL para proteger los datos.

El documento ARIES define el WAL de la siguiente manera:

El protocolo WAL afirma que los registros que representan cambios en algunos datos ya deben estar en almacenamiento estable antes de que los datos modificados puedan reemplazar la versión anterior de los datos en almacenamiento no volátil. Es decir, el sistema no puede escribir una página actualizada en la versión de almacenamiento no volátil de la página hasta que al menos las partes de deshacer de los registros de registro, que describen las actualizaciones de la página se han escrito en almacenamiento estable.

Para obtener más información sobre el registro de escritura anticipada, consulte el tema Registro de transacciones de escritura anticipada en los Libros en pantalla de SQL Server.

SQL Server y WAL

SQL Server usa el protocolo WAL. Para asegurarse de que una transacción se confirma correctamente, todos los registros de registro asociados a la transacción deben protegerse en un almacenamiento estable.

Para aclarar esta situación, considere el siguiente ejemplo específico.

Nota:

En este ejemplo, supongamos que no hay ningún índice y que la página afectada es la página 150.

BEGIN TRANSACTION
 INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION

A continuación, divida la actividad en pasos de registro simplistas, como se describe en la tabla siguiente.

Instrucción	Acciones realizadas
BEGINTRANSACTION	Escrito en el área de caché de registros. Sin embargo, no es necesario vaciar el almacenamiento estable porque SQL Server no ha realizado ningún cambio físico.
INSERT INTO tblTest	1. La página de datos 150 se recupera en la caché de datos de SQL Server, si aún no está disponible. 2. La página está anclada, anclada y marcada como sucia, y se obtienen los bloqueos adecuados. 3. Se crea un registro de inserción y se agrega a la caché de registros. 4. Se agrega una nueva fila a la página de datos. 5. Se libera el bloqueo temporal. 6. Los registros de registro asociados a la transacción o página no tienen que vaciarse en este momento porque todos los cambios permanecen en el almacenamiento volátil.
COMMIT TRANSACTION	1. Se forma un registro de registro de confirmación y los registros asociados a la transacción deben escribirse en almacenamiento estable. La transacción no se considera confirmada hasta que los registros de registro se asignan correctamente al almacenamiento estable. 2. La página de datos 150 permanece en la caché de datos de SQL Server y no se vacía inmediatamente en el almacenamiento estable. Cuando los registros de registro están protegidos correctamente, la recuperación puede rehacer la operación, si es necesario. 3. Se liberan bloqueos transaccionales.

No se confunda por los términos "bloqueo" y "registro". Aunque importantes, el bloqueo y el registro son problemas independientes al tratar con el WAL. En el ejemplo anterior, SQL Server generalmente contiene el bloqueo temporal en la página 150 durante el tiempo necesario para realizar los cambios de inserción física en la página, no todo el tiempo de la transacción. El tipo de bloqueo adecuado se establece para proteger la fila, el intervalo, la página o la tabla según sea necesario. Consulte las secciones De bloqueo de libros en pantalla de SQL Server para obtener más detalles sobre los tipos de bloqueo.

Si examina el ejemplo con más detalle, puede preguntar qué ocurre cuando se ejecutan los procesos LazyWriter o CheckPoint. SQL Server emite todos los vaciados adecuados al almacenamiento estable para los registros de registro transaccionales asociados a la página desfasada y anclada. Esto garantiza que la página de datos del protocolo WAL nunca se pueda escribir en almacenamiento estable hasta que se hayan vaciado los registros de registro transaccionales asociados.

SQL Server y almacenamiento estable

SQL Server mejora las operaciones de página de datos y registro mediante la inclusión del conocimiento de tamaños de sector de disco (normalmente 4096 bytes o 512 bytes).

Para mantener las propiedades ACID de una transacción, SQL Server debe tener en cuenta los puntos de error. Durante un error, muchas especificaciones de unidad de disco solo garantizan un número limitado de operaciones de escritura del sector. La mayoría de las especificaciones garantizan la finalización de una sola escritura de sector cuando se produce un error.

SQL Server usa páginas de datos de 8 KB y el registro (si se vacía) en múltiplos del tamaño del sector. (La mayoría de las unidades de disco usan 512 bytes como tamaño de sector predeterminado). Si se produce un error, SQL Server puede tener en cuenta las operaciones de escritura mayores que un sector mediante el uso de técnicas de paridad de registros y escritura rasgadas.

Detección de páginas rasgadas

Esta opción permite a SQL Server detectar operaciones de E/S incompletas causadas por errores de energía u otras interrupciones del sistema. Cuando es true, hace que un poco se volte para cada sector de 512 bytes en una página de base de datos de 8 kilobytes (KB) cada vez que la página se escribe en el disco. Si un bit está en estado incorrecto cuando SQL Server lee la página posteriormente, la página se escribió incorrectamente; se detecta una página rasgada. Las páginas rasgadas se detectan durante la recuperación porque es probable que la recuperación lea cualquier página escrita incorrectamente.

Aunque las páginas de base de datos de SQL Server son de 8 KB, los discos realizan operaciones de E/S mediante un sector de 512 bytes. Por lo tanto, se escriben 16 sectores por página de base de datos. Se puede producir una página rasgada si se produce un error en el sistema (por ejemplo, debido a un error de alimentación) entre el momento en que el sistema operativo escribe el primer sector de 512 bytes en el disco y la finalización de la operación de E/S de 8 KB. Si el primer sector de una página de base de datos se escribe correctamente antes del error, la página de la base de datos del disco aparecerá como actualizada, aunque es posible que no se haya realizado correctamente.

Mediante el uso de cachés de controladores de disco con respaldo de batería, puede asegurarse de que los datos se escriben correctamente en el disco o no se escriben en absoluto. En esta situación, no establezca la detección de página rasgada en "true" porque esto no es necesario.

Nota:

La detección de páginas rasgadas no está habilitada de forma predeterminada en SQL Server. Para más información, vea Opciones de ALTER DATABASE SET (Transact-SQL).

Paridad de registros

La comprobación de paridad de registros es similar a la detección de páginas rasgadas. Cada sector de 512 bytes contiene bits de paridad. Estos bits de paridad siempre se escriben con el registro y se evalúan cuando se recupera el registro. Al forzar las escrituras de registro en un límite de 512 bytes, SQL Server puede asegurarse de que las operaciones de confirmación se escriben en los sectores de disco físico.

Impactos en el rendimiento

Todas las versiones de SQL Server abren los archivos de registro y de datos mediante la función CreateFile win32. El miembro dwFlagsAndAttributes incluye la FILE_FLAG_WRITE_THROUGH opción cuando SQL Server los abre.

FILE_FLAG_WRITE_THROUGH indica al sistema que escriba a través de cualquier caché intermedia y vaya directamente al disco. El sistema todavía puede almacenar en caché las operaciones de escritura, pero no puede vaciarlas de forma diferida.

La FILE_FLAG_WRITE_THROUGH opción garantiza que cuando una operación de escritura devuelva una finalización correcta, los datos se almacenan correctamente en un almacenamiento estable. Esto se alinea con el protocolo WAL que garantiza los datos.

Muchas unidades de disco (SCSI e IDE) contienen cachés de incorporación de 512 KB, 1 MB o más. Sin embargo, las memorias caché de unidades suelen depender de un condensador y no de una solución respaldada por la batería. Estos mecanismos de almacenamiento en caché no pueden garantizar escrituras en un ciclo de energía o un punto de error similar. Solo garantizan la finalización de las operaciones de escritura del sector. Esto es específicamente por el que la detección de paridad de registros y escritura rasgadas se han integrado en SQL Server 7.0 y versiones posteriores. A medida que las unidades siguen creciendo de tamaño, las memorias caché se vuelven más grandes y pueden exponer grandes cantidades de datos durante un error.

Muchos proveedores de hardware proporcionan soluciones de controladora de disco con respaldo de batería. Estas memorias caché del controlador pueden mantener los datos en la memoria caché durante varios días e incluso permitir que el hardware de almacenamiento en caché se coloque en un segundo equipo. Cuando la alimentación se restaura correctamente, los datos no escritos se vacían antes de permitir el acceso adicional a los datos. Muchos de ellos permiten establecer un porcentaje de caché de lectura frente a caché de escritura para un rendimiento óptimo. Algunas contienen áreas de almacenamiento de memoria grandes. De hecho, para un segmento específico del mercado, algunos proveedores de hardware proporcionan sistemas de controlador de almacenamiento en caché de disco con respaldo de batería de gama alta con 6 GB de caché. Esto puede mejorar considerablemente el rendimiento de la base de datos.

Las implementaciones avanzadas de almacenamiento en caché controlarán la FILE_FLAG_WRITE_THROUGH solicitud sin deshabilitar la caché del controlador porque pueden proporcionar funcionalidades de reescritura verdaderas en caso de un restablecimiento del sistema, un error de energía u otro punto de error.

Las transferencias de E/S sin el uso de una caché pueden ser más largas debido al tiempo mecánico necesario para mover los cabezales de unidad, las velocidades de giro y otros factores de limitación.

Ordenación del sector

Una técnica común que se usa para aumentar el rendimiento de E/S es la ordenación del sector. Para evitar el movimiento mecánico de la cabeza, se ordenan las solicitudes de lectura y escritura, lo que permite un movimiento más coherente de la cabeza para recuperar o almacenar datos.

La memoria caché puede contener varias solicitudes de registro y escritura de datos al mismo tiempo. El protocolo WAL y la implementación de SQL Server del protocolo WAL requieren vaciado de las escrituras de registro en almacenamiento estable antes de que se pueda emitir la escritura de página. Sin embargo, el uso de la memoria caché podría devolver el éxito de una solicitud de escritura de registro sin que los datos se escriban en la unidad real (es decir, se escriben en almacenamiento estable). Esto puede provocar que SQL Server emita la solicitud de escritura de página de datos.

Con la participación de la memoria caché de escritura, los datos todavía se consideran en almacenamiento volátil. Sin embargo, desde la llamada WriteFile de la API win32, exactamente cómo SQL Server ve la actividad, se obtuvo un código de retorno correcto. SQL Server o cualquier proceso que use la llamada a la API WriteFile solo puede determinar que los datos han obtenido correctamente un almacenamiento estable.

Con fines de discusión, supongamos que todos los sectores de la página de datos se ordenan para escribir antes que los sectores de los registros de registro coincidentes. Esto infringe inmediatamente el protocolo WAL. La memoria caché está escribiendo una página de datos antes de los registros. A menos que la memoria caché esté totalmente respaldada por batería, un error puede provocar resultados catastróficos.

Al evaluar los factores de rendimiento óptimos para un servidor de bases de datos, hay muchos factores que se deben tener en cuenta. Lo más importante es: "¿Mi sistema permite funcionalidades válidas FILE_FLAG_WRITE_THROUGH ?"

Nota:

Cualquier caché que use debe admitir completamente una solución respaldada por batería. Todos los demás mecanismos de almacenamiento en caché son propensos a daños en los datos y a la pérdida de datos. SQL Server hace todo lo posible para garantizar que WAL habilite FILE_FLAG_WRITE_THROUGH.

Las pruebas han demostrado que muchas configuraciones de unidad de disco pueden contener almacenamiento en caché de escritura sin la copia de seguridad de batería adecuada. Las unidades SCSI, IDE y EIDE aprovechan al máximo las memorias caché de escritura. Para obtener más información sobre cómo funcionan los SSD junto con SQL Server, consulte el siguiente artículo de blog de ingenieros de SQL Server css:

NOTAS de aprendizaje de SQL Server y SSD: notas de aprendizaje de RDORR: parte 1

En muchas configuraciones, la única manera de deshabilitar correctamente el almacenamiento en caché de escritura de una unidad IDE o EIDE es mediante una utilidad de fabricante específica o mediante jumpers ubicados en la propia unidad. Para asegurarse de que la caché de escritura está deshabilitada para la propia unidad, póngase en contacto con el fabricante de la unidad.

Las unidades SCSI también tienen cachés de escritura. Sin embargo, normalmente el sistema operativo puede deshabilitar estas memorias caché. Si hay alguna pregunta, póngase en contacto con el fabricante de la unidad para obtener las utilidades adecuadas.

Apilamiento de caché de escritura

El apilamiento de caché de escritura es similar al orden de sector. La siguiente definición se tomó directamente desde el sitio web del fabricante de unidades IDE líder:

Normalmente, este modo está activo. El modo de caché de escritura acepta los datos de escritura del host en el búfer hasta que el búfer está lleno o la transferencia del host está completa.

Una tarea de escritura de disco comienza a almacenar los datos del host en el disco. Los comandos de escritura de host siguen siendo aceptados y los datos transferidos al búfer hasta que la pila de comandos de escritura esté llena o el búfer de datos esté lleno. La unidad puede reordenar los comandos de escritura para optimizar el rendimiento de la unidad.

Reasignación automática de escritura (AWR)

Otra técnica común que se usa para proteger los datos es detectar sectores incorrectos durante la manipulación de datos. La siguiente explicación procede de un sitio web líder del fabricante de unidades IDE:

Esta característica forma parte de la memoria caché de escritura y reduce el riesgo de pérdida de datos durante las operaciones de escritura diferidas. Si se produce un error de disco durante el proceso de escritura de disco, la tarea de disco se detiene y el sector sospechoso se reasigna a un grupo de sectores alternativos que se encuentran al final de la unidad. Después de la reasignación, la tarea de escritura de disco continúa hasta que se completa.

Puede ser una característica eficaz si se proporciona la copia de seguridad de la batería para la memoria caché. Esto proporciona una modificación adecuada tras el reinicio. Es preferible detectar los errores de disco, pero la seguridad de los datos del protocolo WAL volvería a requerir que esto se realice en tiempo real y no de manera diferida. Dentro de los parámetros WAL, la técnica AWR no puede tener en cuenta una situación en la que se produce un error de escritura de registro debido a un error de sector, pero la unidad está llena. El motor de base de datos debe conocer inmediatamente el error para que la transacción se pueda anular correctamente, se puede alertar al administrador y realizar los pasos correctos para proteger los datos y corregir la situación de error multimedia.

Seguridad de los datos

Hay varias precauciones que debe tomar un administrador de bases de datos para garantizar la seguridad de los datos.

• Siempre es una buena idea asegurarse de que la estrategia de copia de seguridad es suficiente para recuperarse de un error catastrófico. El almacenamiento fuera del sitio y otras precauciones son adecuados.
• Pruebe la operación de restauración de la base de datos en una base de datos secundaria o de prueba con frecuencia.
• Asegúrese de que cualquier dispositivo de almacenamiento en caché pueda controlar todas las situaciones de error (interrupción de energía, sectores incorrectos, unidades incorrectas, interrupción del sistema, bloqueos, pico de energía, etc.).
• Asegúrese de que el dispositivo de almacenamiento en caché:
  • Tiene copia de seguridad de batería integrada
  • Puede volver a emitir escrituras en encendido
  • Se puede deshabilitar completamente si es necesario
  • Controla la reasignación de sectores incorrectos en tiempo real
• Habilite la detección de páginas rasgadas. (Esto tiene poco efecto en el rendimiento).
• Configure las unidades RAID que permiten un intercambio frecuente de una unidad de disco incorrecta, si es posible.
• Use controladores de almacenamiento en caché más recientes que le permiten agregar más espacio en disco sin reiniciar el sistema operativo. Esto puede ser una solución ideal.

Pruebas de unidades

Para proteger completamente los datos, debe asegurarse de que todo el almacenamiento en caché de datos se controle correctamente. En muchas situaciones, debe deshabilitar el almacenamiento en caché de escritura de la unidad de disco.

Nota:

Asegúrese de que un mecanismo de almacenamiento en caché alternativo puede controlar correctamente varios tipos de errores.

Microsoft ha realizado pruebas en varias unidades SCSI y IDE mediante la SQLIOSim utilidad . Esta utilidad simula una actividad de lectura y escritura asincrónica intensiva en un dispositivo de datos simulado y un dispositivo de registro. Las estadísticas de rendimiento de las pruebas muestran el promedio de operaciones de escritura por segundo entre 50 y 70 para una unidad con almacenamiento en caché de escritura deshabilitado y un intervalo de RPM entre 5 200 y 7 200.

Para obtener más información sobre la SQLIOSim utilidad, consulte el siguiente artículo de Microsoft Knowledge Base:

Uso de la utilidad SQLIOSim para simular la actividad de SQL Server en un subsistema de disco

Muchos fabricantes de equipos ordena las unidades al tener deshabilitada la memoria caché de escritura. Sin embargo, las pruebas muestran que esto puede no ser siempre el caso. Por lo tanto, siempre pruebe completamente.

Dispositivos de datos

En todas las situaciones, pero no registradas, SQL Server solo requerirá que se vacíe los registros de registro. Al realizar operaciones no registradas, las páginas de datos también deben vaciarse en almacenamiento estable; no hay registros de registro individuales para volver a generar las acciones en caso de error.

Las páginas de datos pueden permanecer en caché hasta que el proceso LazyWriter o CheckPoint los vacía en un almacenamiento estable. El uso del protocolo WAL para asegurarse de que los registros de registro se almacenan correctamente garantiza que la recuperación pueda recuperar una página de datos en un estado conocido.

Esto no significa que sea aconsejable colocar archivos de datos en una unidad almacenada en caché. Cuando SQL Server vacía las páginas de datos en almacenamiento estable, los registros de registro se pueden truncar desde el registro de transacciones. Si las páginas de datos se almacenan en caché volátil, es posible truncar los registros de registro que se usarían para recuperar una página en caso de error. Asegúrese de que los dispositivos de datos y de registro se adapten correctamente al almacenamiento estable.

Aumento del rendimiento

La primera pregunta que puede ocurrir es: "Tengo una unidad IDE que estaba almacenando en caché. Pero cuando lo deshabilité, mi rendimiento se convirtió en menos de lo esperado. ¿Por qué?"

Muchas de las unidades IDE probadas por Microsoft se ejecutan a 5 200 RPM y las unidades SCSI a 7 200 RPM. Al deshabilitar el almacenamiento en caché de escritura de la unidad IDE, el rendimiento mecánico puede convertirse en un factor.

Para solucionar la diferencia de rendimiento, el método que se va a seguir es claro: "Direccione la tasa de transacciones".

Muchos sistemas de procesamiento de transacciones en línea (OLTP) requieren una alta tasa de transacciones. Para estos sistemas, considere la posibilidad de usar un controlador de almacenamiento en caché que pueda admitir una memoria caché de escritura y proporcionar el aumento del rendimiento deseado, a la vez que garantiza la integridad de los datos.

Para observar cambios de rendimiento significativos que se producen en SQL Server en una unidad de almacenamiento en caché, la tasa de transacciones se ha aumentado mediante transacciones pequeñas.

Las pruebas muestran que la actividad de escritura alta de los búferes que es inferior a 512 KB o superior a 2 MB puede provocar un rendimiento lento.

Considere el ejemplo siguiente:

CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
INSERT INTO tblTest VALUES ('Test')

A continuación se muestran los resultados de las pruebas de ejemplo para SQL Server:

SCSI(7200 RPM) 84 seconds
SCSI(7200 RPM) 15 seconds (Caching controller)

IDE(5200 RPM) 14 seconds (Drive cache enabled)
IDE(5200 RPM) 160 seconds

El proceso de encapsular toda la serie de INSERT operaciones en una sola transacción se ejecuta en aproximadamente cuatro segundos en todas las configuraciones. Esto se debe al número de vaciados de registro necesarios. Si no crea una sola transacción, cada INSERT se procesa como una transacción independiente. Por lo tanto, se deben vaciar todos los registros de registro de la transacción. Cada vaciado tiene un tamaño de 512 bytes. Esto requiere una intervención significativa de la unidad mecánica.

Cuando se usa una sola transacción, los registros de registro de la transacción se pueden agrupar y se puede usar una sola escritura más grande para vaciar los registros de registro recopilados. Esto reduce significativamente la intervención mecánica.

Advertencia

Se recomienda no aumentar el ámbito de la transacción. Las transacciones de larga duración pueden provocar bloqueos excesivos y no deseados y una mayor sobrecarga. Use los contadores de rendimiento de SQL Server:Databases de SQL Server para ver los contadores basados en el registro de transacciones. En concreto, los bytes de registro vaciados por segundo pueden indicar muchas transacciones pequeñas que pueden provocar una alta actividad mecánica del disco.

Examine las instrucciones asociadas al vaciado del registro para determinar si se puede reducir el valor De bytes de registro vaciado por segundo. En el ejemplo anterior, se usó una sola transacción. Sin embargo, en muchos escenarios, esto puede provocar un comportamiento de bloqueo no deseado. Examine el diseño de la transacción. Puede usar código similar al código siguiente para ejecutar lotes para reducir la actividad de vaciado frecuente y pequeño del registro:

BEGIN TRAN
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
    BEGIN
        INSERT INTO tblTest VALUES ('Test')
  
        if(0 = cast(@@IDENTITY as int) % 10)
        BEGIN
            PRINT 'Commit tran batch'
            COMMIT TRAN
            BEGIN TRAN
        END
    END
GO

COMMIT TRAN
GO

SQL Server requiere que los sistemas admitan la entrega garantizada a medios estables, tal como se describe en el documento de descarga requisitos de descarga del Programa de confiabilidad de E/S de SQL Server. Para obtener más información sobre los requisitos de entrada y salida para el motor de base de datos de SQL Server, consulte Motor de base de datos de Microsoft SQL Server Requisitos de entrada y salida.