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

Resumen

Este artículo describe cómo los algoritmos de registro y datos de Microsoft SQL Server extienden la integridad y la confiabilidad de los datos.

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

El escritor de la entrega de este documento es C. Mohan. El documento trata las técnicas de SQL Server para ampliar la confiabilidad de los datos y la integridad en relación a errores.

Le recomendamos que lea los siguientes artículos en Microsoft Knowledge Base para obtener más información sobre almacenamiento en caché y discusiones de modo alternativo de error:
86903 descripción del almacenamiento en caché de los controladores de disco en SQL Server
234656 información acerca del uso de las cachés de disco con SQL Server que debe saber todo administrador de base de datos

Más información

Antes de comenzar la discusión exhaustiva, algunos de los términos que se utilizan en este artículo se definen en la tabla siguiente.

TérminoDefinición
Con respaldo de bateríaBatería independiente y localizadas herramienta de respaldo directamente disponible y está controlada por el mecanismo de almacenamiento en caché para evitar la pérdida de datos.

Nota: No es una fuente de alimentación ininterrumpida (SAI). Un SAI no garantiza que las actividades de escritura y se puede desconectar el dispositivo de almacenamiento en caché.
Memoria cachéMecanismo de almacenamiento intermedio utilizado para optimizar las operaciones de E/S físicas y mejorar el rendimiento.
Página desfasadaPágina que contiene las modificaciones de datos que todavía no se vacían al almacenamiento estable. Para obtener más información acerca de los búferes de página desfasada, vea el tema "Escribir páginas" en libros en pantalla de SQL Server.
Nota: El contenido también se aplica a Microsoft SQL Server 2012 y versiones posteriores.
ErrorTodo lo que podría causar una interrupción inesperada del proceso de SQL Server. Algunos ejemplos son: alimentación interrupción, restablecimiento del equipo, errores de memoria, otros problemas de hardware, sectores defectuosos, las interrupciones de la unidad, errores del sistema y así sucesivamente.
VaciadoForzamiento de un búfer de caché al almacenamiento estable.
PestillosObjeto de sincronización que se utiliza para proteger la coherencia física de un recurso.
Almacenamiento no volátilCualquier medio que sigue estando disponible a través de errores del sistema.
Página ancladoPágina que permanece en datos almacenar en caché y no se vacían al almacenamiento estable hasta que se protegen todos los registros asociados en una ubicación de almacenamiento estable.
Almacenamiento estableIgual que el almacenamiento no volátil.
Almacenamiento volátilCualquier medio que no permanecen intacto a través de errores.

Protocolo de registro de escritura anticipada (WAL)

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

El documento ARIES define el WAL como sigue:
El protocolo WAL afirma que los registros que representan cambios a algunos datos ya deben estar en almacenamiento estable para que los datos cambiados se permiten reemplazar la versión anterior de los datos en almacenamiento no volátil. Es decir, el sistema no puede escribir una página actualizada a la versión de almacenamiento no volátil de la página hasta que al menos las partes de deshacer de los registros que describen las actualizaciones de la página se han escrito al almacenamiento estable.
Para obtener más información acerca del registro de escritura anticipada, consulte el tema de Registro de transacciones de escritura anticipada en libros en pantalla de SQL Server.

SQL Server y el WAL

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

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

Nota: Para este ejemplo, suponga que no hay ningún índice y que la página afectada es página 150.
BEGIN TRANSACTION   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
A continuación, desglosar la actividad en pasos de registro simplista, tal como se describe en la tabla siguiente.
InstrucciónAcciones realizadas
COMENZAR LA TRANSACCIÓNEscribe en el área de la caché de registro. Sin embargo, no es necesario que vacíe al almacenamiento estable porque el SQL Server no ha realizado ningún cambio físico.
INSERT INTO tblTest
  1. Página 150 de datos se recuperan en la memoria caché de datos de SQL Server, si no está ya disponible.
  2. La página está bloqueado, ancladay marcado como modificadoy se obtienen bloqueos adecuados.
  3. Un registro Insertar está construido y se agrega a la caché de registro.
  4. Se agrega una fila nueva a la página de datos.
  5. Se libera el pestillo.
  6. Las entradas del registro asociadas a la transacción o la página no tiene que vaciarse en este momento, ya que todos los cambios permanecerán en almacenamiento volátil.
CONFIRMAR TRANSACCIÓN
  1. Se forma un registro de confirmación de registro y las entradas del registro asociadas a la transacción deben escribirse al almacenamiento estable. La transacción no se considera confirmada hasta que los registros se asignan correctamente a almacenamiento estable.
  2. Datos página 150 permanecen en la caché de datos de SQL Server y no se vacían inmediatamente al almacenamiento estable. Cuando los registros se ha protegido correctamente, recuperación puede rehacer la operación, si es necesario.
  3. Se liberan los bloqueos de transacciones.
No se confunda con los términos "bloqueo" y "registro". Aunque importantes, bloqueo y registro son temas independientes al tratar con la WAL. En el ejemplo anterior, SQL Server generalmente contiene el pestillo en página 150 durante el tiempo necesario para realizar los cambios físicos de insertar en la página, no todo el tiempo de la transacción. Se establece el tipo de bloqueo apropiado para proteger la fila, rango, página o tabla según sea necesario. Consulte las secciones de bloqueo libros en pantalla de SQL Server para obtener más detalles acerca de los tipos de bloqueo.

Mira el ejemplo con más detalle, podría preguntar lo que sucede cuando se ejecutan los procesos de escritura diferida o CheckPoint. SQL Server emite todos los vaciados adecuados para el almacenamiento de registros de registro transaccional que están asociados con la página sucia y anclada estable. Esto garantiza que la página de datos del protocolo WAL nunca puede escribirse al almacenamiento estable hasta que se vacían los registros de transacciones asociados.

Almacenamiento de información de SQL Server y estable.

SQL Server mejora las operaciones de página de datos y de registro incluyendo el conocimiento de los tamaños de sector de disco (normalmente 512 o 4096 bytes).

Para mantener las propiedades ACID de una transacción, el SQL Server debe tener en cuenta para los puntos de error. Durante un corte en muchas especificaciones de unidad de disco sólo garantizan una cantidad limitada de sector de operaciones de escritura. La mayoría de las especificaciones garantizan la finalización de la escritura de un único sector cuando se produce un error.


SQL Server utiliza páginas de 8 KB de datos y el registro (si baja) en múltiplos del tamaño del sector. (La mayoría de las unidades de disco utilice 512 bytes como el tamaño de sector predeterminado.) En caso de error, SQL Server puede tener en cuenta las operaciones de escritura más de un sector empleando la paridad de registro y las técnicas de escritura rasgada.

Detección de página rasgada

Esta opción permite a SQL Server detectar operaciones de E/S incompletas causadas por cortes eléctricos u otros imprevistos del sistema. Cuando es true, hace que un bit que se va a voltear 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 disco. Si un bit es en un estado incorrecto cuando la página es posterior lectura por SQL Server, a continuación, la página se escribió correctamente; se detecta una página rasgada. Las páginas rasgadas suelen detectarse durante la recuperación porque es probable que se lean cualquier página que se ha escrito incorrectamente.


Aunque las páginas de base de datos de SQL Server son de 8 KB, discos realizan operaciones de E/S mediante un sector de 512 bytes. Por lo tanto, se escriben 16 sectores por cada página de base de datos. Una página puede rasgarse 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 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 de la falla, la página de base de datos en disco aparecerá como actualizada, aunque se puede no se ha ejecutado correctamente.

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

Nota: Detección de página rasgada no está habilitada de forma predeterminada en SQL Server. Para obtener más información, consulte el siguiente sitio Web MSDN:

Paridad de registro

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

Versiones de SQL Server anteriores a 7.0

Las versiones de SQL Server anteriores a 7.0 no proporcionó registro paridad o bits rasgada detección instalaciones. De hecho, esas versiones pueden escribir la misma página de registro varias veces hasta que los registros llenen la página de registro de 2 KB. Esto puede exponer las transacciones que se han comprometido con éxito. Si se va a reescribir la página de registro durante una falla, puede que un sector con la transacción confirmada no obtener reescrito correctamente.

Impactos en la performance

Todas las versiones de SQL Server abren los archivos de registro y de datos mediante la función CreateFile de Win32. El miembro dwFlagsAndAttributes incluye la opción de FILE_FLAG_WRITE_THROUGH cuando se abren por SQL Server.
FILE_FLAG_WRITE_THROUGH
Indica al sistema que escriba en una caché intermedia e ir directamente al disco. El sistema aún puede almacenar en caché las operaciones de escritura, pero no las puede vaciar de forma diferida.


La opción de FILE_FLAG_WRITE_THROUGH garantiza que, cuando una operación de escritura vuelve una finalización correcta, los datos se almacenan correctamente en un almacenamiento estable. Esto se alinea con el protocolo WAL que garantiza que los datos.
Muchas unidades de disco (SCSI e IDE) contienen memorias caché incorporadas de 512 KB, 1 MB o superior. Sin embargo, las cachés de unidad normalmente dependen de un condensador y no es una solución con respaldo de batería. Estos mecanismos de caché no pueden garantizar ciclo de escrituras a través de una potencia o punto de error similar. Sólo garantiza la realización de las operaciones de escritura del sector. Se trata específicamente por qué se construyeron la escritura rasgada y detección de paridad de registro en SQL Server 7.0 y versiones posteriores. Como las unidades continúan creciendo en tamaño, aumentan las cachés y grandes cantidades de datos que pueden exponer durante una falla.

Muchos proveedores de hardware ofrecen soluciones de controlador de disco con respaldo de batería. Estas cachés de controlador pueden mantener los datos en la caché durante varios días e incluso permitir el hardware de almacenamiento en caché para colocarse en un segundo equipo. Cuando la alimentación se restaura correctamente, los datos no se vacían completamente antes de permite el acceso a los datos adicional. Muchos de ellos permiten un porcentaje de lectura frente a la memoria caché de escritura para establecerse para un rendimiento óptimo. Algunos contienen áreas de almacenamiento de grandes cantidades de memoria. De hecho, para un segmento muy específico del mercado, algunos fabricantes de hardware proporcionan almacenamiento en caché de sistemas de controlador con 6 GB de memoria caché de discos high-end de batería. Estos pueden mejorar significativamente el rendimiento de la base de datos.

Avanzada de las implementaciones de almacenamiento en caché controlador el FILE_FLAG_WRITE_THROUGH solicitar no deshabilitar la caché de controlador porque pueden ofrecer true reescriba capacidades en caso de un reinicio del sistema, corte de suministro eléctrico u otro punto de error.


Transferencias de E/S sin el uso de una memoria caché pueden ser considerablemente más larga debido al tiempo mecánico que es necesario para mover los cabezales de la unidad, las tasas de giro y otros factores limitantes.

Ordenación del sector

Una técnica común utilizada para aumentar el rendimiento de E/S es sector pedidos. 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 caché puede contener varios registro y las solicitudes de escritura de datos al mismo tiempo. El protocolo WAL y la implementación de SQL Server del protocolo WAL requieren el vaciado del registro escribe en almacenamiento estable para poder emitir la escritura de la página. Sin embargo, uso de la caché podría devolver el éxito de una solicitud de escritura de registro sin los datos que se escriben en la unidad real (que es, escribir en almacenamiento estable). Esto puede conducir a SQL Server emite la solicitud de escritura de página de datos.


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

A efectos de discusión, se supone que todos los sectores de la página de datos están ordenados para escribir antes de los sectores de los registros coincidentes. Esto infringe inmediatamente el protocolo WAL. La caché está escribiendo una página de datos antes de las entradas del registro. A menos que la caché está plenamente respaldada por batería, un error puede causar resultados catastróficos.


Al evaluar los factores de rendimiento óptimo para un servidor de base de datos, hay muchos factores a tener en cuenta. Es el más importante, "permite mi sistema válidas capacidades FILE_FLAG_WRITE_THROUGH?"

Nota: Cualquier caché que utilizas debe soportar completamente una solución con respaldo de batería. Otros mecanismos de almacenamiento en caché son sospechosas a corrupción de datos y pérdida de datos. SQL Server hace todo lo posible para garantizar la WAL habilitando FILE_FLAG_WRITE_THROUGH.


Las pruebas han demostrado que muchas configuraciones de unidad de disco pueden contener la caché de escritura sin el respaldo de batería adecuada. Las unidades SCSI, IDE y EIDE aprovechar al máximo las memorias caché de escritura. Para obtener más información acerca del funcionan de SSDs junto con SQL Server, consulte el siguiente artículo del Blog de ingenieros de CSS SQL Server:


En muchas configuraciones, la única manera de deshabilitar la caché de escritura de una unidad IDE o EIDE correctamente es mediante una utilidad de un fabricante específico o mediante puentes ubicados en la misma 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.

Unidades SCSI también tienen cachés de escritura. Sin embargo, estas cachés normalmente pueden deshabilitarse por el sistema operativo. Si hay alguna duda, póngase en contacto con el fabricante de la unidad de utilidades adecuadas.

Escribir caché de apilamiento

Escribir que caché de apilamiento es similar a la ordenación del Sector. La definición siguiente está tomada directamente del sitio Web de un IDE unidad fabricante líder:
Normalmente, este modo está activo. Escribir el modo de caché acepta que el host escribe datos en el búfer hasta que el búfer está lleno o se ha completado la transferencia del host.

Una tarea de escritura de disco comienza a almacenar los datos de host al disco. Comandos de escritura de host siguen aceptarse y datos que se transfieren al búfer hasta que la pila del comando de escritura está lleno 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 de escritura automática (AWR)

Otra técnica común que se utiliza para proteger los datos es detectar los sectores defectuosos durante la manipulación de datos. La explicación siguiente procede de un líder IDE unidad sitio Web del fabricante:
Esta característica es parte de la memoria caché de escritura y reduce el riesgo de pérdida de datos durante las operaciones de escritura diferida. 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 complete.
Esto puede ser una característica muy eficaz si no se proporciona respaldo de batería para la caché. Esto proporciona la modificación correspondiente al reiniciar. Es preferible para detectar los errores de disco, pero la seguridad de los datos del protocolo WAL nuevo requeriría Esto se realice en tiempo real y no de una manera diferida. Dentro de los parámetros WAL, la técnica AWR no se cuenta una situación en la que se produce un error en una escritura de registro debido a un error de sector pero la unidad está llena. El motor de base de datos debe conocer inmediatamente sobre el error para que la transacción se puede anular correctamente, el administrador se le notificaría y corregir los pasos dados para proteger los datos y corregir la situación de falla de los medios de comunicación.

Seguridad de los datos

Hay varias precauciones que debe tomar un administrador de base de datos para garantizar la seguridad de los datos.
  • Siempre es una buena idea para asegurarse de que su estrategia de copia de seguridad es suficiente para recuperarse de un error catastrófico. Almacenamiento fuera del sitio y otras precauciones son apropiados.
  • Probar la operación de restauración de base de datos en un secundario o base de datos de prueba con frecuencia.
  • Asegúrese de que los dispositivos de almacenamiento en caché pueden controlar todas las situaciones de error (corte de suministro eléctrico, sectores defectuosos, mala unidades, interrupciones del sistema, bloqueos, pico de potencia etc.).
  • Asegúrese de que su dispositivo de almacenamiento en caché:
    • Ha integrado la batería de reserva
    • Puede reedición escribe sobre puesta en marcha
    • Puede deshabilitarse completamente si es necesario
    • Controla la reasignación del sector defectuoso en tiempo real
  • Habilitar rasgada detección de página. (Tiene muy poco efecto en el rendimiento).
  • Configurar unidades de RAID, lo que permite un intercambio en caliente de una unidad de disco, si es posible.
  • Utilice los controladores de almacenamiento en caché más recientes que permiten agregar más espacio en disco sin tener que reiniciar el sistema operativo. Esto puede ser una solución ideal.

Pruebas de unidades

Para proteger totalmente los datos, debe asegurarse de que todos los datos correctamente administra la caché. En muchas situaciones, debe deshabilitar la caché de escritura de la unidad de disco.

Nota: Asegúrese de que una alternativa al almacenamiento en caché mecanismo correctamente puede controlar varios tipos de error.

Microsoft ha realizado pruebas en varias unidades SCSI e IDE mediante la utilidad SQLIOSim . Esta herramienta simula actividad pesado de lectura y escritura asincrónicas a un dispositivo de datos simulados y dispositivo de registro. Estadísticas de rendimiento de la prueba muestran que las operaciones de escritura promedio por segundo entre 50 y 70 para una unidad con memoria caché de escritura deshabilitada y un rango RPM entre 5.200 y 7.200.


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

231619 cómo utilizar la utilidad SQLIOSim para simular la actividad de SQL Server en un subsistema de disco
Muchos fabricantes de equipos orden las unidades al tener deshabilitada la caché de escritura. Sin embargo, la prueba muestra que esto no siempre puede suceder. Por lo tanto, siempre Pruebe completamente.

Dispositivos de datos

En situaciones de todos, pero no registrada, SQL Server requerirá sólo los registros que se debe vaciar. Al realizar operaciones no registradas, también se deben vaciar las páginas de datos al almacenamiento estable; No hay ningún registro de registro individuales para regenerar las acciones en caso de error.


Las páginas de datos pueden permanecer en la caché hasta que el proceso de escritura diferida o CheckPoint vacía al almacenamiento estable. Con el protocolo WAL para asegurarse de que los registros se almacenan correctamente, se asegura de que la recuperación puede recuperar una página de datos a un estado conocido.

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

Aumento del rendimiento

La primera pregunta que podría suceder que es: "tengo una unidad IDE que fue de caché. Pero cuando deshabilitado, mi rendimiento llegó a ser considerablemente menor que el esperado. ¿Por qué?"

Muchas de las unidades IDE que están probadas por Microsoft se ejecuten en 5.200 RPM y las unidades SCSI a 7.200 RPM. Cuando se deshabilita la caché de escritura de la unidad IDE, el rendimiento mecánico puede convertirse en un factor.

Para resolver la diferencia de rendimiento, el método a seguir es muy claro: "Dirección de la tasa de transacción".

Muchos sistemas de transacciones en línea (OLTP) de procesamiento requieren una tasa de transacciones alta. Para estos sistemas, considere el uso de una controladora de caché que puede apropiada compatibilidad con una memoria caché de escritura y aumentan el rendimiento deseado sin dejar de garantizar la integridad de los datos.

Para observar los cambios de rendimiento significativos que se producen en SQL Server en una unidad de almacenamiento en caché, se incrementó el tipo de transacción con transacciones pequeñas.

Pruebas muestra que escribe alta actividad de búferes que es menor que 512 KB o mayor de 2 MB pueden provocar un rendimiento lento.
Considere el siguiente ejemplo:

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')

Los siguientes son los resultados de pruebas de ejemplo para SQL Server:

84 de SCSI(7200 rpm) segundos
SCSI(7200 rpm) 15 segundos (controlador de almacenamiento en caché)


14 de IDE(5200 rpm) segundos (unidad de caché habilitada)
160 IDE(5200 rpm) segundos

Se ejecuta el proceso de ajuste de toda la serie de operaciones de INSERCIÓN en una sola transacción en unos cuatro segundos en todas las configuraciones. Esto es debido al número de vaciados de registro que sean necesarios. Si no crea una única transacción, cada INSERCIÓN se procesa como una transacción independiente. Por lo tanto, se deben vaciar todos los registros del registro de la transacción. Cada descarga es de 512 bytes de tamaño. Esto requiere la intervención de accionamiento mecánico significativo.

Cuando se utiliza una única transacción, pueden integrar los registros del registro de la transacción y una escritura más grande, solo puede utilizarse para vaciar los registros recopilados. Esto reduce considerablemente la intervención mecánica.

Advertencia: Recomendamos que no aumentan el ámbito de la transacción. Transacciones de ejecución larga pueden causar el bloqueo excesivo y no deseados y mayor carga. Utilice los contadores de rendimiento de SQL Server: bases de datos de SQL Server para ver los contadores basados en registros de transacciones. En concreto, Flushed Bytes de registro/seg. puede indicar muchas transacciones pequeñas que pueden causar la actividad de disco elevada de mecánica.

Examine las instrucciones asociadas con el registro de RAS para determinar si se puede reducir el valor de Bytes de registro Flushed/seg . En el ejemplo anterior, se utilizó una sola transacción. Sin embargo, en muchos casos, esto puede provocar un comportamiento no deseado bloqueo. Examine el diseño de la transacción. Puede utilizar código similar al siguiente para ejecutar lotes para reducir la actividad de vaciado de registro frecuente y pequeñas:
BEGIN TRANGO

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 admiten "entrega garantizada en medios estables," como se describe en el documento de descarga de SQL Server requisitos revisión del programa de confiabilidad de i/OS . Para 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 ir al artículo de 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: 230785 - Última revisión: 8 ene. 2017 - Revisión: 1

Comentarios