Compartir a través de

Los errores del sistema operativo 665 y 1450 se notifican para los archivos de SQL Server

  • Artículo

Este artículo le ayuda a resolver el problema en el que se notifican los errores del sistema operativo 1450 y 665 para los archivos de base de datos al ejecutar DBCC CHECKDB, crear una instantánea de base de datos o un crecimiento de archivos.

Versión del producto original: SQL Server
Número de KB original: 2002606

Síntomas

Supongamos que realiza una de las siguientes acciones en un equipo que ejecuta SQL Server:

  • Cree una instantánea de base de datos en una base de datos grande. A continuación, realizará numerosas operaciones de modificación o mantenimiento de datos en la base de datos de origen.
  • Cree una instantánea de base de datos en una base de datos reflejada.
  • Ejecute la DBCC CHECKDB familia de comandos para comprobar la coherencia de una base de datos grande y también realice un gran número de cambios de datos en esa base de datos.

Nota:

SQL Server usa archivos dispersos para estas operaciones: instantánea de base de datos y DBCC CHECKDB.

  • Copia de seguridad o restauración de bases de datos.
  • La copia masiva se realiza a través de BCP en varios archivos mediante ejecuciones de BCP paralelas y escritura en el mismo volumen.

Como resultado de estas operaciones, es posible que observe uno o varios de estos errores notificados en el registro de errores de SQL Server en función del entorno en el que se ejecuta SQL Server.

The operating system returned error 665(The requested operation could not be completed due to a file system limitation) to SQL Server during a write at offset 0x00002a3ef96000 in file 'Sam.mdf:MSSQL_DBCC18'

The operating system returned error 1450 (Insufficient system resources exist to complete the requested service.) to SQL Server during a write at offset 0x00002a3ef96000 in file with handle 0x0000000000000D5C. This is usually a temporary condition and the SQL Server will keep retrying the operation. If the condition persists, then immediate action must be taken to correct it.`

Además de estos errores, también puede observar los siguientes errores de tiempo de espera de bloqueo temporal:

Timeout occurred while waiting for latch: class *'DBCC_MULTIOBJECT_SCANNER'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.  

Timeout occurred while waiting for latch: class *'ACCESS_METHODS_HOBT_COUNT'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.

Además, también puede observar el bloqueo al ver varias vistas de administración dinámica (DMV), como sys.dm_exec_requests y sys.dm_os_waiting_tasks.

En raras ocasiones, puede observar un problema del programador que no produce el informe en el registro de errores de SQL Server y que SQL Server genera un volcado de memoria.

Causa

Este problema se produce si se necesita un gran número de ATTRIBUTE_LIST_ENTRY instancias para mantener un archivo muy fragmentado en NTFS. Si el espacio está junto a un clúster que ya realiza el seguimiento del sistema de archivos, los atributos se comprimen en una sola entrada. Sin embargo, si el espacio está fragmentado, se debe realizar un seguimiento con varios atributos. Por lo tanto, la fragmentación pesada de archivos puede provocar el agotamiento de atributos y el error 665 resultante. Este comportamiento se explica en el siguiente artículo de KB: un archivo muy fragmentado en un volumen NTFS puede no crecer más allá de un tamaño determinado.

Los archivos normales y dispersos creados por SQL Server u otras aplicaciones pueden fragmentarse en estos niveles cuando se producen grandes cantidades de modificaciones de datos durante la vida útil de estos archivos de instantáneas.

Si realiza copias de seguridad de base de datos en un conjunto de franjas de archivos ubicados en el mismo volumen, o si va a copiar datos en masa (BCP-ing) en varios archivos del mismo volumen, las escrituras pueden terminar en ubicaciones adyacentes pero que pertenecen a archivos diferentes. Por ejemplo, una secuencia escribe para desplazarse entre 201 y 400, la otra secuencia escribe de 401 a 600, la tercera secuencia puede escribir de 601 a 800. Este proceso continúa también para otras secuencias. Esto provocará la fragmentación de archivos en los mismos medios físicos. Cada uno de los archivos de copia de seguridad o flujos de salida BCP puede agotar el almacenamiento de atributos, ya que ninguno de ellos obtiene almacenamiento adyacente.

Para obtener información completa sobre cómo el motor de SQL Server usa archivos dispersos NTFS y flujos de datos alternativos, vea Más información.

Solución

Considere la posibilidad de usar una o varias de las siguientes opciones para resolver este problema:

  1. Coloque los archivos de base de datos en un volumen resistente del sistema de archivos (ReFS), que no tiene los mismos ATTRIBUTE_LIST_ENTRY límites que presenta NTFS . Si desea usar el volumen NTFS actual, debe volver a formatear con ReFS después de mover temporalmente los archivos de base de datos en otro lugar. El uso de ReFS es la mejor solución a largo plazo para tratar este problema.

    Nota:

    SQL Server 2012 y versiones anteriores usaron flujos de archivos con nombre en lugar de archivos dispersos para crear CHECKDB instantáneas. ReFS no admite flujos de archivos. La ejecución DBCC CHECKDB en archivos de SQL Server 2012 en ReFS podría producir errores. Para obtener más información, vea la nota de Cómo DBCC CHECKDB crea una base de datos de instantáneas interna a partir de SQL Server 2014.

  2. Des fragmente el volumen donde residen los archivos de base de datos. Asegúrese de que la utilidad de desfragmentación es transaccional. Para obtener más información sobre la desfragmentación de unidades donde residen los archivos de SQL Server, vea Precauciones al desfragmentar unidades de base de datos de SQL Server y recomendaciones. Debe apagar SQL Server para realizar esta operación en los archivos. Se recomienda crear copias de seguridad completas de la base de datos antes de desfragmentar los archivos como medida de seguridad. La desfragmentación funciona de forma diferente en medios de unidades de estado sólido (SSD) y normalmente no soluciona el problema. Copiar los archivos y permitir que el firmware ssd vuelva a empaquetar el almacenamiento físico suele ser una mejor solución. Para más información, consulte Error del sistema operativo (665: limitación del sistema de archivos) ya no solo para DBCC.

  3. Copia de archivos: realizar una copia del archivo puede permitir una mejor adquisición de espacio porque los bytes podrían estar estrechamente empaquetados en el proceso. Copiar el archivo (o moverlo a un volumen diferente) puede reducir el uso de atributos y puede impedir el error 665 del sistema operativo. Copie uno o varios de los archivos de base de datos en otra unidad. A continuación, puede dejar el archivo en el nuevo volumen o copiarlo de nuevo en el volumen original.

  4. Dé formato al volumen NTFS mediante la opción /L para obtener un FRS grande. Esta opción puede proporcionar alivio a este problema porque hace que sea ATTRIBUTE_LIST_ENTRY mayor. Esta opción puede no ser útil al usar DBCC CHECKDB porque este último crea un archivo disperso para la instantánea de base de datos.

    Nota:

    En el caso de los sistemas que ejecutan Windows Server 2008 R2 y Vista, primero debe aplicar la revisión del artículo de KB 967351 antes de usar la /L opción con el format comando .

  5. Divida una base de datos grande en archivos más pequeños. Por ejemplo, si tiene un archivo de datos de 8 TB, puede dividirlo en ocho archivos de datos de 1 TB. Esta opción podría ayudar porque se producirían menos modificaciones en archivos más pequeños, por lo que es menos probable que se introduzca el agotamiento de atributos. Además, en el proceso de mover datos alrededor, los archivos se organizarán de forma compacta y se reducirá la fragmentación. Estos son los pasos generales, que describen el proceso:

    1. Agregue los siete nuevos archivos de 1 TB al mismo grupo de archivos.
    2. Vuelva a generar los índices agrupados de las tablas existentes, que propagará automáticamente los datos de cada tabla entre los ocho archivos. Si una tabla no tiene un índice agrupado, cree uno y colóquelo para lograr lo mismo.
    3. Reduzca el archivo original de 8 TB, que ahora está lleno aproximadamente el 12 %.

  6. Configuración de crecimiento automático de la base de datos: ajuste la configuración de la base de datos de incremento de crecimiento automático para adquirir tamaños favorables al rendimiento de producción y el empaquetado de atributos NTFS. Cuanto menor sea la frecuencia con la que se produzca el crecimiento automático y cuanto mayor sea el tamaño del incremento de crecimiento, menos probable será la posibilidad de fragmentación de archivos.

  7. Reduzca la duración de los comandos mediante las mejoras de DBCC CHECK rendimiento y, por tanto, evite los errores 665: Las mejoras del comando DBCC CHECKDB pueden dar lugar a un rendimiento más rápido cuando se usa la opción PHYSICAL_ONLY. Tenga en cuenta que la ejecución DBCC CHECKDB con PHYSICAL_ONLY switch no proporciona una garantía de que evitará este error, pero reducirá la probabilidad en muchos casos.

  8. Si va a realizar copias de seguridad de base de datos en muchos archivos (conjunto de franjas), planee cuidadosamente el número de archivos MAXTRANSFERSIZE y BLOCKSIZE (consulte BACKUP). El objetivo es reducir los fragmentos en el sistema de archivos que generalmente se logra escribiendo los fragmentos de bytes más grandes juntos en un archivo. Es posible que considere la posibilidad de quitar los archivos en varios volúmenes para reducir el rendimiento y la reducción más rápidos de la fragmentación.

  9. Si usa BCP para escribir varios archivos simultáneamente, ajuste los tamaños de escritura de la utilidad, por ejemplo, aumente el tamaño del lote de BCP. Además, considere la posibilidad de escribir varias secuencias en diferentes volúmenes para evitar la fragmentación o reducir el número de escrituras paralelas.

  10. Para ejecutar DBCC CHECKDB, puede considerar la posibilidad de configurar un grupo de disponibilidad o un servidor de trasvase de registros o en espera. O bien, use un segundo servidor en el que pueda ejecutar los DBCC CHECKDB comandos para descargar el trabajo y evitar que se produzcan problemas causados por la fragmentación intensiva de archivos dispersos.

  11. Al ejecutar DBCC CHECKDB, si ejecuta el comando en un momento en que hay poca actividad en el servidor de bases de datos, los archivos dispersos se rellenarán ligeramente. Cuantos menos escrituras se escriban en los archivos, se reducirá la probabilidad de agotar los atributos en NTFS. Menos actividad es otra razón para ejecutarse DBCC CHECKDB en un segundo servidor de solo lectura, siempre que sea posible.

  12. Si ejecuta SQL Server 2014, actualice al Service Pack más reciente. Para obtener más información, vea FIX: Error 665 del sistema operativo al ejecutar el comando DBCC CHECKDB para la base de datos que contiene el índice de almacén de columnas en SQL Server 2014.

Más información