Compartir a través de

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

  • Artículo

Este artículo le ayuda a resolver el problema por el que se notifican los errores del sistema operativo 1450 y 665 para los archivos de base de datos mientras se ejecuta DBCC CHECKDB, la creación de una instantánea de base de datos o el 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, se realizan 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.
  • Realice la copia masiva a través de BCP en varios archivos mediante ejecuciones BCP paralelas y escribiendo 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 ejecute 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, es posible que también observe 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 resultados notificados 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 al que ya realiza el seguimiento el sistema de archivos, los atributos se comprimen en una sola entrada. Sin embargo, si el espacio está fragmentado, se debe realizar un seguimiento de él con varios atributos. Por lo tanto, la fragmentación de archivos pesada puede provocar el agotamiento de atributos y el error 665 resultante. Este comportamiento se explica en el siguiente artículo de KB: Es posible que un archivo muy fragmentado en un volumen NTFS no crezca más allá de un tamaño determinado.

Los archivos normales y dispersos creados por SQL Server u otras aplicaciones pueden fragmentarse a 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 la base de datos en un conjunto de franjas de archivos ubicados en el mismo volumen o si va a copiar datos de forma masiva (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 escribe de 401 a 600, la tercera secuencia puede escribir de 601 a 800. Este proceso continúa también para otras secuencias. Esto dará lugar a la fragmentación de archivos en el mismo medio físico. 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 un fondo completo de cómo SQL Server Engine 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 del sistema de archivos resistente (ReFS), que no tiene los mismos ATTRIBUTE_LIST_ENTRY límites que 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 a otro lugar. El uso de ReFS es la mejor solución a largo plazo para abordar este problema.

    Nota:

    SQL Server 2012 y versiones anteriores usaban secuencias de archivos con nombre en lugar de archivos dispersos para crear CHECKDB instantáneas. ReFS no admite secuencias de archivos. La ejecución DBCC CHECKDB en SQL Server archivos de 2012 en ReFS puede dar lugar a errores. Para obtener más información, consulte la nota sobre 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 SQL Server archivos, consulte Precauciones al desfragmentar SQL Server unidades de base de datos 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 manera diferente en los 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 solución mejor. Para obtener 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: la realización de una copia del archivo puede permitir una mejor adquisición de espacio, ya que los bytes pueden estar estrechamente empaquetados juntos en el proceso. Copiar el archivo (o moverlo a otro volumen) puede reducir el uso de atributos y puede impedir el error 665 del sistema operativo. Copie uno o varios 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. Dar 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 mayor ATTRIBUTE_LIST_ENTRY . Es posible que esta opción no sea útil cuando se usa DBCC CHECKDB porque este último crea un archivo disperso para la instantánea de base de datos.

    Nota:

    Para 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 produzca agotamiento de atributos. Además, en el proceso de mover datos, los archivos se organizarán de forma compacta y se reduciría la fragmentación. Los siguientes son pasos de alto nivel, que describen el proceso:

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

  6. Configuración de crecimiento automático de la base de datos: ajuste la configuración de la base de datos de incremento automático para adquirir tamaños que propicien el rendimiento de producción y el empaquetado de atributos NTFS. Cuanto menos frecuentes sean las repeticiones de crecimiento automático y mayor sea el tamaño de incremento de crecimiento, menos probable será la posibilidad de fragmentación de archivos.

  7. Reduzca la duración de DBCC CHECK los comandos mediante las mejoras de 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 la 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, lo que generalmente se logra escribiendo los fragmentos de bytes más grandes juntos en un archivo. Puede considerar la posibilidad de quitar los archivos en varios volúmenes para un rendimiento más rápido y una reducción 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 BCP. Además, considere la posibilidad de escribir varias secuencias en distintos volúmenes para evitar la fragmentación o reducir el número de escrituras en paralelo.

  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 donde pueda ejecutar los DBCC CHECKDB comandos para descargar el trabajo y evitar que se produzcan problemas causados por la fragmentación pesada de archivos dispersos.

  11. Al ejecutar DBCC CHECKDB, si ejecuta el comando en un momento en que hay poca actividad en el servidor de base de datos, los archivos dispersos se rellenarán ligeramente. El menor número de escrituras en los archivos reducirá la probabilidad de que se agoten 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