Compartir por

Aspectos básicos de E/S de SQL Server

  • Artigo

Se aplica a:SQL ServerAzure SQL Managed InstanceSQL Server en Azure VM

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 (E/S de afinidad) 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. Esto ayuda al administrador del sistema a distinguir entre problemas de SQL Server y 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 E/S larga puede ser de lectura o de escritura; no se indica actualmente en el mensaje. 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 se notifican para ayudar a los administradores del sistema a encontrar la causa de los tiempos de respuesta largos de SQL Server con mayor rapidez y a 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 larga puede indicar que una E/S está permanente bloqueada y que nunca se completará (lo que también se conoce como E/S perdida), o bien que simplemente todavía no se ha completado. No es posible saber con el mensaje de qué escenario se trata, aunque una E/S perdida suele provocar 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.

Las E/S largas se pueden deber a un componente de la ruta de acceso de E/S (por ejemplo, un controlador o el firmware) que posponga de forma continua el servicio para una solicitud de E/S antigua en favor de solicitudes más recientes. Esto puede ocurrir en entornos interconectados, como redes iSCSI y de canal de fibra (ya sea debido a un error de configuración o una ruta de acceso incorrecta). Esto puede resultar difícil de corroborar con la herramienta Monitor de rendimiento porque a la mayor parte de las E/S se proporcionan de manera inmediata. Las solicitudes de E/S largas pueden agravarse con cargas de trabajo que realicen un gran número de operaciones de E/S secuenciales, como copias de seguridad y restauración, recorridos de tabla, ordenaciones, creación de índices, cargas masivas y puestas a cero de archivos.

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 se puede deber a consultas que no se escriben de forma eficaz o que no se ajustan correctamente 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 sobre la E/S de 15 segundos es más común con componentes de hardware, una latencia de E/S más pequeña se observa con más frecuencia con consultas no optimizadas o programas antivirus mal configurados.

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 se realizan sin el uso de una caché pueden ser significativamente más largas en unidades mecánicas, debido a las velocidades de giro del disco duro, el tiempo mecánico necesario para mover los cabezales de las unidades y otros factores de limitación. Las instalaciones de SQL Server están destinadas a 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é.

Nota:

Algunos proveedores de almacenamiento usan memoria persistente (PMEM) como almacenamiento en lugar de una caché, lo que puede mejorar el rendimiento general. Para más información, vea Configuración de la memoria persistente (PMEM) para SQL Server en Windows y Configuración de la memoria persistente (PMEM) para SQL Server en Linux.

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 almacenamiento en 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 administración de bases de datos transaccional (DBMS) crítico para los 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 esto no suele ser suficiente, ya que se pueden producir modos de error que no están relacionados con la alimentación.

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 los incorporan son seguras. Pero debe comprobar 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 sistema de administración de bases de datos relacionales (RDBMS) transaccional crítico para los datos.

Registro de escritura previa

Las instrucciones de modificación de datos de SQL Server generan escrituras de página lógicas. Esta secuencia de escrituras se puede describir en dos lugares: el registro y la propia base de datos. Por motivos de rendimiento, SQL Server aplaza las escrituras a la base de datos mediante su propio sistema de búfer de caché. Las escrituras en el registro solo se aplazan momentáneamente hasta el momento de COMMIT. No se almacenan en caché de la misma manera que las escrituras de datos. Como las escrituras de registro de una página determinada siempre preceden a las escrituras de datos de la página, el registro se conoce a veces como registro de escritura previa (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 opción FILE_FLAG_WRITE_THROUGH garantiza que, cuando una operación de escritura devuelve una finalización correcta, los datos se almacenan correctamente en un almacenamiento estable. Esto se alinea con la especificación del protocolo de registro de escritura previa (WAL) para garantizar 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 se consideran unidades atómicas de trabajo que se aplican 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 reiniciaría, el software de red se cargaría e inicializaría, y SQL Server se reiniciaría. 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. Cada vez que se reinicien las estaciones de trabajo cliente, los usuarios verán que todos sus datos están presentes, hasta la última transacción que hayan especificado.

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 almacenamiento en caché de escritura no está diseñado correctamente para su uso en un entorno DBMS transaccional crítico para los datos, puede poner en peligro la capacidad de recuperación de SQL Server, por lo que se daña la base de datos. Esto puede ocurrir 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 de controlador, pero no conserva estas páginas escritas durante un error del sistema.

Escritura de controladores de almacenamiento en caché y de dispositivos de almacenamiento

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

Incluso si el servidor usa UPS, esto 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 ni 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é sucios, lo que se podría usar de forma segura en un servidor de bases de datos. Algunas de estas características de diseño incluirían la interceptación de la señal del bus RST para evitar el restablecimiento incontrolado del controlador de almacenamiento en caché, la copia de seguridad de la batería incorporada y la comprobación de errores y la corrección (ECC) de la memoria. 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. Esto se conoce a menudo como propiedades ACID (Atomicidad, Coherencia, Aislamiento y Durabilidad).

En esta sección se describen las implicaciones de las memorias caché de almacenamiento. Se recomienda leer los siguientes artículos en Microsoft Knowledge Base para más información sobre el almacenamiento en caché y opiniones alternativas sobre el modo de error:

También se recomiendan los siguientes documentos:

Estos dos documentos se aplican a todas las versiones de SQL Server admitidas actualmente.

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. En muchos casos se permite establecer el porcentaje de caché de lectura frente a caché de escritura para obtener un rendimiento óptimo. Algunas 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é. Esto puede mejorar considerablemente el rendimiento de la base de datos. El uso de soluciones de almacenamiento en caché respaldadas por batería proporciona la durabilidad y coherencia de los datos que SQL Server espera.

Implementaciones del subsistema de almacenamiento

Hay muchos tipos de implementaciones del subsistema. RAID (matriz redundante de discos independientes) y SAN (red de área de almacenamiento) son dos ejemplos de estos tipos de implementaciones de subsistema. Normalmente, estos sistemas se crean con unidades basadas en SCSI. Hay varias razones para ello. En la sección siguiente se describen consideraciones de almacenamiento de nivel general.

SCSI, SAS y NVMe

Dispositivos de almacenamiento SCSI, SAS y NVMe:

  • Normalmente se fabrican para un uso intensivo.
  • Normalmente se destinan a implementaciones multiusuario basadas en servidor.
  • Normalmente tienen mejores tasas de error 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 se fabrican para un nivel de uso ligero y medio.
  • Normalmente se destinan a aplicaciones basadas en un solo usuario.

Los controladores basados en escritorio que no son SCSI necesitan más ancho de banda del procesador principal (CPU) y suelen limitarse mediante un único comando activo. 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. Esto deja inactiva a una unidad mientras que la otra ofrece 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

Hay situaciones en las que una unidad o matriz basada en escritorio es una solución de bajo costo adecuada. Por ejemplo, si configura una base de datos de solo lectura para crear informes, no debería encontrar 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 alta capacidad y bajo costo pueden ser atractivas. Pero al configurar la unidad para SQL Server y sus necesidades de tiempo de respuesta empresarial, debe tener 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 SCSI conectado en serie (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.

El almacenamiento en caché de unidades se debe deshabilitar para poder usar la unidad con SQL Server. De manera predeterminada, la caché de unidades está habilitada. En Windows Server, use la pestaña Propiedades del disco>Hardware para acceder a la pestaña Propiedades >Directiva a fin de controlar la configuración de caché de unidades.

Nota:

Algunas unidades no respetan esta configuración. Estas unidades necesitan una utilidad del fabricante específica para deshabilitar la caché.

Los sistemas basados en IDE y ATA pueden posponer comandos de host cuando realizan actividades como un ajuste de bloques incorrectos. Esto podría dar lugar a períodos de actividad de E/S detenidos.

Entre las ventajas de SAS se incluyen puestas en cola avanzadas de hasta 256 niveles, y el encabezado de cola y cola fuera de orden. 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. El almacenamiento de estado sólido se conecta 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 energía se incluyen los siguientes:

  • Daños en los bits: los registros muestran errores de bits aleatorios.
  • Escrituras volátiles: los registros bien formados terminan en el lugar equivocado.
  • Escrituras de Shorn: las operaciones se realizan parcialmente en un nivel por debajo del tamaño esperado del sector.
  • Daños en los metadatos: los metadatos de 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 del almacenamiento de estado sólido notifica tamaños de sector de 512 bytes, pero se 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 contiene 1, lo que hace que una lectura sin procesar de un bloque borrado sea todo 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 que se ha usado en el pasado consistía en escribir un patrón conocido en toda la unidad. Después, a medida que se ejecuta la actividad de la base de datos en esa misma unidad, se puede detectar un comportamiento incorrecto (lectura obsoleta, escritura perdida, lectura de desplazamiento incorrecto, etc.) cuando el patrón aparece de manera inesperada.

Esta técnica no funciona bien en almacenamiento de estado sólido. La eliminación y las actividades de RMW para las escrituras destruyen el patrón. La actividad de recolección de elementos no utilizados (GC) del almacenamiento de estado sólido, el nivelado de desgaste, los bloques de lista proporcionales o de reserva, y otras optimizaciones tienden a provocar que las escrituras adquieran diferentes ubicaciones físicas, a diferencia de la reutilización de los sectores de los medios giratorios.

Firmware

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, la recolección de elementos no utilizados determina que un bloque ha permanecido en un estado de solo lectura durante un período de tiempo y debe moverse. Este movimiento suele ser un bloque con más desgaste, por lo que el bloque original se puede usar para escrituras. Esto ayuda a equilibrar el desgaste de la unidad, pero mueve los datos de solo lectura a una ubicación que tiene más desgaste y aumenta matemáticamente las posibilidades de error, aunque sea de forma mínima.

Otro efecto secundario de la nivelación del desgaste se puede producir 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 el 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 en paralelo. Esto significa que la desfragmentación de los 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.

Nota:

El almacenamiento de estado sólido se beneficia de la característica de recorte, un comando del nivel del sistema operativo (SO) que borra los bloques que se consideran que ya no están en uso. En Windows, use la herramienta Optimizar unidades a fin de establecer una programación semanal para optimizar las unidades.

Recomendaciones:

  • Use un controlador con respaldo de batería adecuado diseñado para optimizar las actividades de escritura. Esto puede mejorar el rendimiento, reducir el desgaste de la unidad y 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 los tamaños de crecimiento de archivos tienen el tamaño adecuado.

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 la intención de los medios estables, la compresión puede alargar su vida útil y podría afectar positivamente al rendimiento. Pero es posible que, en algunos casos, el firmware ya comprima los datos de forma invisible. Recuerde probar los 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.
  • Siga atentamente las instrucciones de los fabricantes del hardware.

Consideraciones sobre caché y SQLIOSim

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

Nota:

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

Microsoft ha realizado pruebas en varias unidades SCSI e IDE mediante la utilidad SQLIOSim. Esta utilidad simula una actividad de lectura y escritura asincrónica intensiva en un dispositivo de datos simulado y un dispositivo de registro. Para más información y detalles sobre SQLIOSim, vea 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. Pero las pruebas demuestran que este podría no ser siempre el caso, por lo que siempre debe probarlo completamente. 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 configuración adecuada de la utilidad o de los jumper para deshabilitar las operaciones de almacenamiento en caché de escritura.

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.

Contenido relacionado