Aspectos básicos de E/S de SQL Server

Se aplica a:SQL ServerAzure SQL Instancia AdministradaSQL Server en Máquinas Virtuales de Azure

El propósito principal de una base de datos de SQL Server es almacenar y recuperar datos, por lo que una entrada y salida (E/S) de disco intensiva es una característica principal del motor de base de datos. Dado que las operaciones de E/S de disco pueden consumir muchos recursos y tardar bastante tiempo en completarse, SQL Server se centra en hacer la E/S muy eficaz.

Los subsistemas de almacenamiento para SQL Server se proporcionan en varios factores de forma, incluidas las unidades mecánicas y el almacenamiento de estado sólido. En este artículo se proporcionan detalles sobre cómo usar los principios de almacenamiento en caché de unidades para mejorar la E/S del motor de base de datos.

En SQL Server es necesario que los sistemas admitan la entrega garantizada a medios estables, como se describe en Requisitos del programa de confiabilidad de E/S de SQL Server. Para más información sobre los requisitos de entrada y salida para el motor de base de datos de SQL Server, vea Requisitos de entrada y salida (E/S) de disco del motor de base de datos de SQL Server.

E/S de disco

El administrador de búfer solo realiza tareas de lectura y escritura en la base de datos. Las otras operaciones con archivos, como la apertura, el cierre, la extensión y la reducción, las realizan el administrador de base de datos y los componentes del administrador de archivos.

Las operaciones de E/S de disco que realiza el administrador de búfer tienen las siguientes características:

• La E/S se realiza de forma asincrónica, lo que permite que el subproceso de llamada siga con el procesamiento mientras la operación de E/S se realiza en segundo plano. En algunas circunstancias (por ejemplo, E/S de registro desalineada), se puede producirse E/S sincrónica.

• Todas las operaciones de E/S se emiten en los subprocesos de llamada a menos que la opción affinity I/O esté en uso. La opción affinity I/O mask enlaza la E/S del disco de SQL Server a un subconjunto específico de CPU. En entornos de procesamiento de transacciones en línea (OLTP) de SQL Server de grandes prestaciones, esta extensión puede mejorar el rendimiento de los subprocesos de SQL Server que emiten E/S.

• Las operaciones de E/S de múltiples páginas se logran con E/S por dispersión y recopilación, que permite transferir datos a áreas no contiguas de memoria, o desde ellas. Esto significa que SQL Server puede llenar o vaciar rápidamente la caché del búfer y, a la vez, evitar múltiples solicitudes de E/S física.

Solicitudes de E/S largas

El administrador de búfer notifica cualquier solicitud de E/S que haya quedado pendiente durante al menos 15 segundos. Este proceso ayuda al administrador del sistema a distinguir entre los problemas de SQL Server y los problemas del subsistema de E/S. El mensaje de error MSSQLSERVER_833 se notifica y aparece en el registro de errores de SQL Server de la siguiente forma:

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

Una operación larga de E/S puede ser de lectura o de escritura; el mensaje no indica actualmente cuál es. Los mensajes de E/S larga son advertencias, no errores. No indican problemas con SQL Server, sino con el sistema de E/S subyacente. Los mensajes ayudan al administrador del sistema a encontrar la causa de tiempos de respuesta deficientes de SQL Server más rápidamente y distinguir problemas que están fuera del control de SQL Server. Por eso, no es necesario tomar ninguna acción, pero el administrador del sistema debe investigar por qué la solicitud de E/S tardó tanto tiempo y si ese tiempo es justificable.

Causas de solicitudes de E/S largas

Un mensaje de E/S largo puede indicar que una E/S está bloqueada permanentemente y nunca se completará (conocida como E/S perdida), o simplemente que aún no está completa. No se puede indicar desde el mensaje qué escenario es el caso, aunque una E/S perdida suele dar lugar a un tiempo de espera de bloqueo temporal.

Las E/S largas suelen indicar una carga de trabajo de SQL Server demasiado intensa para el subsistema de disco. Es posible que se indique un subsistema de disco inadecuado cuando:

• Aparecen múltiples mensajes de E/S largas en el registro de errores durante una carga de trabajo intensa de SQL Server.
• Los contadores del monitor de rendimiento muestran latencias de disco prolongadas, colas de disco largas o no muestran el tiempo de inactividad de disco.

Un componente de la ruta de acceso de E/S (por ejemplo, un controlador, una controladora o firmware) puede provocar operaciones de E/S prolongadas posponiendo continuamente la atención a una solicitud de E/S antigua, en favor de la atención a solicitudes más recientes. Este problema puede producirse en entornos interconectados, como redes iSCSI y canal de fibra (ya sea debido a un error de configuración o ruta de acceso incorrecta). La herramienta Monitor de Rendimiento puede hacer que este problema sea difícil de confirmar porque la mayoría de las E/S se están atendiendo rápidamente. Las cargas de trabajo que realizan grandes cantidades de I/O secuenciales, como copia de seguridad y restauración, escaneos de tabla, ordenación, creación de índices, cargas masivas y borrado de archivos, pueden exacerbar las peticiones de I/O prolongadas.

Las E/S largas aisladas que no parecen estar relacionadas con ninguna de las situaciones anteriores pueden deberse a un problema con el hardware o el controlador. Es posible que el registro de eventos del sistema contenga un evento relacionado que ayude a diagnosticar el problema.

Problemas de rendimiento de E/S causados por consultas ineficaces o controladores de filtro

La E/S lenta puede deberse a consultas que no se escriben de forma eficaz o no se ajustan adecuadamente con índices y estadísticas. Otro factor común en la latencia de E/S es la presencia de antivirus u otros programas de seguridad que examinan los archivos de base de datos. Este software de examen puede extenderse a la capa de red, lo que agrega latencia de red que, a su vez, afecta indirectamente a la latencia de la base de datos. Aunque el escenario descrito de unos 15 segundos de E/S es más común con componentes de hardware, los retrasos de E/S más cortos se observan con más frecuencia en consultas no optimizadas o en programas antivirus configurados incorrectamente.

Para obtener información detallada sobre cómo solucionar estos problemas, vea Solución de problemas de rendimiento lento de SQL Server causados por problemas de E/S.

Para obtener información sobre cómo configurar la protección antivirus en SQL Server, vea Configuración del software antivirus para que funcione con SQL Server.

Almacenamiento en caché de escritura en controladores de almacenamiento

Las transferencias de E/S que no usan caché pueden tardar mucho más en discos mecánicos debido a las velocidades de giro del disco duro, el tiempo mecánico necesario para mover los cabezales de la unidad y otros factores limitantes. Las instalaciones de SQL Server tienen como destino sistemas que proporcionan controladores de almacenamiento en caché. Estos controladores deshabilitan las cachés en disco y proporcionan cachés multimedia estables para satisfacer los requisitos de E/S de SQL Server. Evitan problemas de rendimiento relacionados con la búsqueda de almacenamiento y los tiempos de escritura mediante las distintas optimizaciones del controlador de almacenamiento en caché.

El uso de un controlador de almacenamiento en caché de escritura (también denominado almacenamiento en caché de reescritura) puede mejorar el rendimiento de SQL Server. Los controladores de caché de escritura y los subsistemas de almacenamiento son seguros para SQL Server, si están diseñados para su uso en un entorno de sistema de gestión de bases de datos transaccional (SGBD) crítico para datos. Estas características de diseño deben conservar los datos almacenados en caché si se produce un error del sistema. El uso de una fuente de alimentación externa ininterrumpida (UPS) para lograr esta protección no suele ser suficiente, ya que los modos de error que no están relacionados con la alimentación pueden producirse.

SQL Server puede usar los controladores de almacenamiento en caché y los subsistemas de almacenamiento. La mayoría de las nuevas plataformas de servidor creadas específicamente que incorporan estos controladores son seguras. Sin embargo, debe consultar con el proveedor de hardware para asegurarse de que el subsistema de almacenamiento se ha probado y aprobado para su uso en un entorno de administración de bases de datos relacionales transaccional (RDBMS) crítico para los datos.

Directrices de seguridad del subsistema de caché

Los controladores de almacenamiento en caché de reescritura pueden mejorar el rendimiento si cumplen requisitos de seguridad específicos:

• Incluya memoria caché con respaldo de batería o memoria no volátil, como NVDIMM o flash con respaldo super condensador.
• Esté certificado por el proveedor para entornos de base de datos OLTP críticos para los datos.
• Proporcionar protección que cubra todas las condiciones de error, no solo la pérdida de energía.

Registro de escritura previa

Las instrucciones de modificación de datos de SQL Server generan escrituras de página lógicas. Puede imaginar esta secuencia de escrituras como yendo a dos lugares: el log y la propia base de datos. Por motivos de rendimiento, SQL Server aplaza las escrituras en la base de datos a través de su propio sistema de búfer de caché. El sistema solo aplaza momentáneamente las escrituras en el registro hasta COMMIT el momento. No almacena en caché estas escrituras como lo hace con las escrituras de datos. Dado que las escrituras en la bitácora de una página determinada siempre ocurren antes que las escrituras de datos de la página, la bitácora a veces se conoce como bitácora de escritura adelantada (WAL).

Protocolo de registro de escritura previa (WAL)

El término protocolo es una excelente manera de describir WAL. El WAL que se usa en SQL Server se conoce como ARIES (algoritmo para recuperación y aislamiento que aprovecha la semántica). Para más información, vea Administración de la recuperación de base de datos acelerada.

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 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, también describe al protocolo WAL para proteger los datos. 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 FILE_FLAG_WRITE_THROUGH cuando se abre en SQL Server.

FILE_FLAG_WRITE_THROUGH

SQL Server crea sus archivos de base de datos mediante la marca FILE_FLAG_WRITE_THROUGH. Esta opción indica al sistema que escriba mediante cualquier caché intermedia y vaya directamente al almacenamiento. El sistema todavía puede almacenar en caché las operaciones de escritura, pero no puede vaciarlas de forma diferida. Para más información, vea CreateFileA.

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 almacenamiento estable. Esta característica se alinea con la especificación del protocolo de registro de escritura anticipada (WAL) para garantizar la integridad de los datos. Muchos dispositivos de almacenamiento (NVMe, PCIe, SATA, ATA, SCSI y basados en IDE) contienen cachés de incorporación de 512 KB, 1 MB y más grandes. Las cachés de almacenamiento se suelen basar en un condensador y no en una solución respaldada por baterías. 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. A medida que los dispositivos de almacenamiento aumentan de tamaño, las memorias caché se vuelven más grandes y pueden exponer grandes cantidades de datos durante un error.

Para obtener más información sobre la compatibilidad de FUA con la distribución de Linux y su efecto en SQL Server, consulte: SQL Server en Linux: Funcionamiento interno del acceso de unidad forzada (FUA).

Integridad transaccional y recuperación de SQL Server

La integridad transaccional es uno de los conceptos fundamentales de un sistema de base de datos relacional. Las transacciones son unidades atómicas de trabajo que se aplican totalmente o se revierten totalmente. El registro de transacciones de escritura previa de SQL Server es un componente fundamental para implementar la integridad transaccional.

Cualquier sistema de base de datos relacional también debe abordar un concepto estrechamente relacionado con la integridad transaccional, que es la recuperación de errores del sistema no planeados. Este error se puede deber a varios efectos no ideales y reales. En muchos sistemas de administración de bases de datos, el error del sistema puede dar lugar a un largo proceso de recuperación manual dirigido por el usuario.

En cambio, el mecanismo de recuperación de SQL Server es automático y funciona sin intervención humana. Por ejemplo, SQL Server podría admitir una aplicación de producción crítica y experimentar un error del sistema debido a una fluctuación de energía momentánea. Tras la restauración de energía, el hardware del servidor se reinicia, el software de red carga e inicializa y SQL Server se reinicia. A medida que SQL Server se inicializa, ejecuta automáticamente su proceso de recuperación en función de los datos del registro de transacciones. Todo este proceso se produce sin intervención humana. Cuando se reinician las estaciones de trabajo cliente, los usuarios encuentran todos sus datos presentes, hasta la última transacción que especificaron.

La integridad transaccional y la recuperación automática en SQL Server constituyen una eficaz capacidad de ahorro de tiempo y mano de obra. Si un controlador de caché de escritura no está diseñado adecuadamente para su uso en un entorno DBMS transaccional crítico de datos, puede comprometer la capacidad de recuperación de SQL Server, lo que podría corromper la base de datos. Este problema puede producirse si el controlador intercepta las escrituras del registro de transacciones de SQL Server y las almacena en búfer en una caché de hardware en la placa del controlador, pero no conserva estas páginas escritas durante un error del sistema.

Riesgos de almacenamiento en caché de escritura en disco

La mayoría de los controladores de almacenamiento en caché de dispositivos de almacenamiento realizan el almacenamiento en caché de escritura. No siempre se puede deshabilitar la función de almacenamiento en caché de escritura.

Incluso si el servidor usa un UPS, el dispositivo no garantiza la seguridad de las escrituras almacenadas en caché. Se pueden producir muchos tipos de errores del sistema que un UPS no soluciona. Por ejemplo, un error de paridad de memoria, una captura del sistema operativo (SO) o un error de hardware que provoca un restablecimiento del sistema puede producir una interrupción del sistema no controlada. Un error de memoria en la caché de escritura de hardware también puede provocar la pérdida de información vital del registro.

Otro posible problema relacionado con un controlador de almacenamiento en caché de escritura se puede producir al apagar el sistema. No es raro recorrer el sistema operativo o reiniciar el sistema durante los cambios de configuración. Incluso si un operador cuidadoso sigue la recomendación del sistema operativo de esperar hasta que se detenga toda la actividad de almacenamiento antes de reiniciar el sistema, las escrituras almacenadas en caché pueden estar presentes en el controlador. Cuando se presiona la combinación de teclas Ctrl+Alt+Del o se pulsa un botón de restablecimiento de hardware, se pueden descartar escrituras almacenadas en caché, lo que podría dañar la base de datos.

Es posible diseñar una caché de escritura de hardware que tenga en cuenta todas las causas posibles de descartar los datos de caché sucias, lo que hace que sea seguro para su uso por parte de un servidor de bases de datos. Algunas de estas características de diseño incluyen la interceptación de la señal del bus RST (restablecimiento) para evitar el restablecimiento no controlado del controlador de caché, la batería de respaldo a bordo y la memoria reflejada o de corrección y comprobación de errores (ECC). Consulte con el proveedor de hardware para asegurarse de que la caché de escritura incluye estas y otras características necesarias para evitar la pérdida de datos.

Uso de cachés de almacenamiento con SQL Server

Un sistema de base de datos es, en primer lugar, responsable del almacenamiento y la recuperación precisos de datos, incluso en caso de errores inesperados del sistema.

El sistema debe garantizar la atomicidad y la durabilidad de las transacciones, a la vez que tiene en cuenta la ejecución actual, varias transacciones y varios puntos de error. Esta propiedad se conoce a menudo como las propiedades ACID (Atomicidad, Coherencia, Aislamiento y Durabilidad).

En esta sección se describen las implicaciones de las memorias caché de almacenamiento. Para obtener más información sobre el almacenamiento en caché y los debates sobre el modo de error alternativo, consulte los siguientes artículos:

• 86903 SQL Server y controladores de disco de almacenamiento en caché
• Descripción de los algoritmos de registro y almacenamiento de datos que amplían la confiabilidad de los datos en SQL Server

Revise también el siguiente contenido archivado:

• Aspectos fundamentales de E/S de SQL Server 2000
• Aspectos básicos de la E/S de SQL Server, capítulo 2

Los conceptos de estos dos artículos siguen siendo ampliamente aplicables a las versiones actuales de SQL Server.

Soluciones de almacenamiento en caché con respaldo de batería

Los sistemas de controlador de almacenamiento en caché mejorados deshabilitan la caché en disco y proporcionan una solución funcional de almacenamiento en caché con respaldo de batería. Estas cachés pueden mantener los datos en la memoria caché durante varios días e incluso permitir que la tarjeta de almacenamiento en caché se coloque en un segundo equipo. Cuando la alimentación se restaura correctamente, los datos no escritos se vacían por completo antes de que se permita el acceso de datos adicionales. Muchos de estos sistemas permiten establecer un porcentaje de caché de lectura frente a caché de escritura para un rendimiento óptimo. Algunos sistemas contienen áreas de almacenamiento de memoria grandes. Algunos proveedores de hardware proporcionan sistemas de almacenamiento en caché de unidades con respaldo de batería de gama alta con varios gigabytes de caché. Estos sistemas pueden mejorar significativamente el rendimiento de la base de datos. Las soluciones de almacenamiento en caché respaldadas por batería proporcionan la durabilidad y la coherencia de los datos que SQL Server espera.

Implementaciones del subsistema de almacenamiento

Los subsistemas de almacenamiento existen en muchos tipos. Dos ejemplos comunes son RAID (matriz redundante de discos independientes) y SAN (red de área de almacenamiento). Estos sistemas suelen usar unidades basadas en SCSI. En la sección siguiente se describen las consideraciones de almacenamiento de alto nivel.

SCSI, SAS y NVMe

Dispositivos de almacenamiento SCSI, SAS y NVMe:

• Normalmente están diseñados para uso pesado.
• Normalmente se destinan a implementaciones multiusuario basadas en servidor.
• Normalmente tienen un mejor tiempo medio entre fallos que otras implementaciones.
• Contienen heurística sofisticada para ayudar a predecir errores inminentes.

No SCSI

Otras implementaciones de unidades, como IDE, ATA y SATA:

• Normalmente están diseñados para uso de intensidad ligera a media.
• Normalmente se destinan a aplicaciones de usuario único.

Los controladores no SCSI basados en escritorio requieren más recursos de procesamiento del CPU principal y están frecuentemente limitados por un único comando en ejecución. Por ejemplo, cuando una unidad que no es SCSI ajusta un bloque incorrecto, la unidad necesita que los comandos de host esperen. El bus ATA presenta otro ejemplo: el bus ATA admite dos dispositivos, pero solo se puede activar un único comando. Esta limitación deja inactiva una unidad mientras que la otra unidad atiende el comando pendiente. Los sistemas RAID basados en tecnologías de escritorio pueden experimentar estos síntomas y verse afectados en gran medida por el respondedor más lento. A menos que estos sistemas usen diseños avanzados, su rendimiento no es tan eficaz como el de los sistemas basados en SCSI.

Consideraciones sobre el almacenamiento

Una unidad o matriz basada en escritorio puede ser una solución de bajo costo para algunas situaciones. Por ejemplo, si configura una base de datos de solo lectura para informes, no encuentra muchos de los factores de rendimiento de una base de datos OLTP cuando se deshabilita el almacenamiento en caché de unidades.

Los tamaños de dispositivo de almacenamiento siguen aumentando. Las unidades de bajo costo y alta capacidad pueden ser atractivas. Pero al configurar la unidad para SQL Server y sus necesidades de tiempo de respuesta empresarial, tenga en cuenta detenidamente los siguientes problemas:

• Diseño de la ruta de acceso
• El requisito para deshabilitar la caché en disco

Unidades de disco duro mecánicas

Las unidades mecánicas usan platos magnéticos giratorios para almacenar los datos. Están disponibles en varias capacidades y factores de forma, como IDE, SATA, SCSI y Serial Attached SCSI (SAS). Algunas unidades SATA incluyen construcciones de predicción de errores. Las unidades SCSI están diseñadas para ciclos de trabajo más pesados y reducen las tasas de error.

Los sistemas basados en IDE y ATA pueden posponer comandos del host cuando realizan actividades como el ajuste de bloques defectuosos, lo que conduce a períodos de actividad de E/S detenidos.

Las ventajas de SAS incluyen colas avanzadas hasta 256 niveles, y gestión de cola en la cabecera y fuera de secuencia. El backplane SAS está diseñado de forma que permita el uso de unidades SAS y SATA dentro del mismo sistema.

La instalación de SQL Server depende de la capacidad del controlador de deshabilitar la caché en disco y proporcionar una caché de E/S estable. La escritura de datos fuera de orden en varias unidades no es un obstáculo para SQL Server, siempre que el controlador proporcione las funcionalidades de almacenamiento en caché de medios estables correctas. La complejidad del diseño del controlador aumenta con técnicas avanzadas de seguridad de datos, como la creación de reflejo.

Almacenamiento de estado sólido

El almacenamiento de estado sólido tiene ventajas sobre las unidades de disco duro mecánicas (giratorias), pero es susceptible a muchos de los mismos patrones de error que los medios giratorios. Puede conectar el almacenamiento de estado sólido al servidor mediante varias interfaces, como NVM Express (NVMe), PCI Express (PCIe) y SATA. Trate a los medios de estado sólido como haría con los medios giratorios y asegúrese de que las medidas de seguridad adecuadas están en vigor en caso de fallo de alimentación, como un controlador de almacenamiento en caché con respaldo de batería.

Entre los problemas comunes causados por un error de alimentación se incluyen:

• Corrupción de bits: Los registros muestran errores de bits aleatorios.
• Escrituras volátiles: los registros bien formados terminan en el lugar equivocado.
• Escrituras cortadas: las operaciones se realizan parcialmente en un nivel por debajo del tamaño esperado del sector.
• Daños en los metadatos: los metadatos de la capa de traducción flash (FTL) están dañados.
• Dispositivo que no responde: el dispositivo no funciona total o parcialmente.
• Imposibilidad de serialización: el estado final del almacenamiento no se produce por un orden de operación serializable.

512e

La mayoría de los dispositivos de almacenamiento de estado sólido notifican tamaños de sector de 512 bytes, pero usan páginas de 4 KB dentro de los bloques de borrado de 1 MB. El uso de sectores alineados de 512 bytes para el dispositivo de registro de SQL Server puede generar más actividades de lectura, modificación y escritura (RMW), lo que puede contribuir a un rendimiento más lento y a desgaste.

Recomendación: Asegúrese de que el controlador de almacenamiento en caché tenga en cuenta el tamaño de página correcto del dispositivo de almacenamiento y que puede alinear las escrituras físicas con la infraestructura de almacenamiento de estado sólido correctamente.

0xFFFFFFFF

Normalmente, una unidad recién formateada solo contiene ceros. Un bloque borrado de un dispositivo de estado sólido está compuesto completamente por 1, lo que hace que una lectura sin procesar del mismo contenga todos los caracteres 0xFF. Pero no es habitual que un usuario lea un bloque borrado durante las operaciones normales de E/S.

Sellado de patrones

Una técnica utilizada en el pasado es escribir un patrón conocido sobre toda la unidad. A continuación, a medida que se ejecuta la actividad de base de datos en esa misma unidad, se puede detectar un comportamiento incorrecto (lectura obsoleta, escritura perdida o lectura de desplazamiento incorrecto) cuando el patrón aparece inesperadamente.

Esta técnica no funciona bien en almacenamiento de estado sólido. Las actividades de borrado y RMW para escrituras destruyen el patrón. La actividad de recolección de basura (GC) de almacenamiento de estado sólido, la nivelación de desgaste, los bloques de lista proporcional o reservada, y otras optimizaciones tienden a hacer que las escrituras adquieran diferentes ubicaciones físicas, a diferencia de la reutilización del sector de los medios giratorios.

Microprograma

El firmware que se usa en el almacenamiento de estado sólido tiende a ser complejo en comparación con el homólogo de los medios giratorios. Muchas unidades usan varios núcleos de procesamiento para controlar las solicitudes entrantes y las actividades de recolección de elementos no utilizados. Asegúrese de mantener actualizado el firmware del dispositivo de estado sólido para evitar problemas conocidos.

Lectura de datos dañados y nivelación del desgaste

Un enfoque común de recolección de elementos no utilizados (GC) para el almacenamiento de estado sólido ayuda a evitar daños en los datos repetidos y leídos. Al leer repetidamente la misma celda, es posible que la actividad de los electrones se filtre y cause daño en las celdas vecinas. El almacenamiento de estado sólido protege los datos con varios niveles de código de corrección de errores (ECC) y otros mecanismos.

Uno de estos mecanismos se relaciona con el nivelado del desgaste. El almacenamiento de estado sólido realiza el seguimiento de la actividad de lectura y escritura en el dispositivo de almacenamiento. La recolección de elementos no utilizados puede determinar las zonas activas o las ubicaciones que se desgastan más rápidamente que otras ubicaciones. Por ejemplo, el GC determina que un bloque está en un estado de solo lectura y debe moverse. Este movimiento suele ser un bloque con más desgaste, por lo que el bloque original se puede usar para escrituras. Este proceso ayuda a equilibrar el desgaste en la unidad, pero mueve los datos de solo lectura a una ubicación que tiene más desgaste e incrementa de manera matemática el riesgo de fallo, aunque sea ligeramente.

Otro efecto secundario de la nivelación de desgaste puede producirse con SQL Server. Imagine que ejecuta DBCC CHECKDB y que notifica un error. Si lo ejecuta una segunda vez, existe una pequeña posibilidad de que DBCC CHECKDB notifique errores adicionales u otro patrón de errores, ya que la actividad de recolección de elementos no utilizados del almacenamiento de estado sólido podría realizar cambios entre las ejecuciones de DBCC CHECKDB.

Error 665 del sistema operativo y desfragmentación

Los medios giratorios deben mantener los bloques cercanos unos de otros para reducir el movimiento del cabezal de la unidad y aumentar el rendimiento. El almacenamiento de estado sólido no tiene un cabezal físico, lo que elimina el tiempo de búsqueda. Muchos dispositivos de estado sólido están diseñados para permitir operaciones paralelas en bloques diferentes. Por lo tanto, la desfragmentación de medios de estado sólido no es necesaria. Las actividades en serie son los mejores patrones de E/S para maximizar el rendimiento de E/S en dispositivos de almacenamiento de estado sólido.

Recommendations:

• Use un controlador con respaldo de batería adecuado diseñado para optimizar las actividades de escritura. Esta opción puede mejorar el rendimiento, disminuir el desgaste de la unidad y además reducir los niveles de fragmentación física.

• Considere la posibilidad de usar el sistema de archivos ReFS para evitar las limitaciones de atributos de NTFS.

• Asegúrese de que la configuración de crecimiento del archivo sea adecuada.

Para más información sobre la solución de problemas de errores 665 del sistema operativo en relación con la fragmentación, vea Errores 665 y 1450 del sistema operativo notificados para archivos de SQL Server.

Compresión

Siempre que la unidad mantenga el propósito de estabilidad en los medios, la compresión puede prolongar la vida útil de la unidad y podría mejorar el rendimiento. Pero es posible que, en algunos casos, el firmware ya comprima los datos de forma invisible. Recuerde probar nuevos escenarios de almacenamiento antes de implementarlos en el entorno de producción.

Resumen

• Mantenga los procedimientos y procesos de recuperación ante desastres y de copia de seguridad adecuados.
• Mantenga actualizado el firmware.
• Escuche detenidamente las instrucciones del fabricante de hardware.

Configuración de caché de discos

Para usar una unidad con SQL Server, deshabilite el almacenamiento en caché de unidades. De manera predeterminada, la caché de unidades está habilitada. En Windows Server, use la pestaña Propiedades de disco>, Hardware>, Directiva para deshabilitar el almacenamiento en caché de escritura a nivel del sistema operativo.

No confíe solo en la configuración de nivel de sistema operativo. Algunas unidades omiten la configuración de Windows y requieren utilidades específicas del fabricante o ajustes del firmware para deshabilitar el almacenamiento en caché de escritura. Confirme mediante las herramientas del proveedor que el almacenamiento en caché de escritura está realmente deshabilitado.

Consideraciones sobre caché y SQLIOSim

Para confirmar las garantías de durabilidad transaccional, valide el subsistema de E/S mediante SQLIOSim antes de pasar a producción. Esta utilidad simula una actividad de lectura y escritura asincrónica intensiva en un dispositivo de datos simulado y un dispositivo de registro. Para obtener más información, consulte Uso de la utilidad SQLIOSim para simular la actividad de SQL Server en un subsistema de disco.

Muchos fabricantes de PC piden las unidades con la caché de escritura deshabilitada. Sin embargo, las pruebas muestran que esta condición puede no ser siempre el caso, por lo que siempre debe probarla por completo. Si tiene alguna pregunta sobre el estado de almacenamiento en caché del dispositivo de almacenamiento, póngase en contacto con el fabricante y obtenga la utilidad adecuada para deshabilitar las operaciones de almacenamiento en caché de escritura. En los medios de almacenamiento más antiguos, es posible que también necesite configuración de jumper.

En SQL Server es necesario que los sistemas admitan la entrega garantizada a medios estables, como se describe en Requisitos del programa de confiabilidad de E/S de SQL Server. Para más información sobre los requisitos de entrada y salida para el motor de base de datos de SQL Server, vea Requisitos de entrada y salida (E/S) de disco del motor de base de datos de SQL Server.

Riesgos del almacenamiento en caché de escritura inapropiado

Al habilitar el almacenamiento en caché de escritura sin medidas de seguridad adecuadas, algunos subsistemas de almacenamiento reconocen las operaciones de escritura como completadas antes de que los datos se escriban de forma segura en medios duraderos. Si se produce una pérdida de energía o un error del sistema, esta condición puede dar lugar a:

• Pérdida de datos, donde las transacciones confirmadas nunca se conservan.
• Corrupción de la base de datos debido a garantías de orden de escritura rotas.

Contenido relacionado

• Guía de arquitectura de páginas y extensiones
• Guía de arquitectura de administración de memoria
• Storage: procedimientos recomendados de rendimiento para SQL Server en máquinas virtuales Azure
• SQL Server en Linux: aspectos internos del acceso a unidades forzadas (FUA)
• Aspectos básicos de la E/S de SQL Server, capítulo 2