Estás trabajando sin conexión, espera a que vuelva la conexión a Internet

Un registro de transacciones crece inesperadamente o se completa en SQL Server

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 317375
Resumen
Si la opción de crecimiento automático se establece en Microsoft SQL Server 2005, SQL Server 2000 y SQL Server 7.0, pueden expandir automáticamente los archivos de registro de transacción.

Por lo general, el tamaño del archivo de registro de transacciones se estabiliza cuando puede contener el número máximo de transacciones que pueden transcurrir entre truncamientos de registro de transacción que activan los puntos de comprobación o copias de seguridad de registro de transacciones.

Sin embargo, en algunos casos que el registro de transacciones puede ser muy grande y ejecución queda sin espacio o punto de llenarse. Por lo general, recibirá el siguiente mensaje de error cuando un archivo de registro de transacciones estuviera agotando el espacio en disco disponible y no se puede expandir más tiempo:
Error: 9002 Gravedad: 17, estado: 2
El archivo de registro para la base de datos ' %. * ls' está lleno.
Si utiliza SQL Server 2005, recibirá un mensaje de error similar al siguiente:
Error: 9002, gravedad: 17, Estado: 2
El registro de transacciones de base de datos ' %. * ls' está lleno. Para conocer las razones espacio en el registro no se puede volver a utilizar, consulte la columna log_reuse_wait_desc de Sys.Databases
Además de este mensaje de error de SQL Server puede marcar las bases de datos como sospechosa debido a falta de espacio para expansión de registro de transacción. Para obtener más información acerca de cómo recuperarse de esta situación, vea el tema "Espacio en disco insuficiente" en los libros en pantalla de SQL Server.

Además, expansión de registro de transacciones puede producirse en las situaciones siguientes:
  • Un archivo de registro de transacciones de muy gran tamaño.
  • Las transacciones pueden producir un error y pueden empezar a restaurar.
  • Las transacciones pueden tardar mucho tiempo en completarse.
  • Puede experimentar problemas de rendimiento.
  • Se pueden producir bloqueos.
Más información
Expansión de registro de transacción puede producirse por cualquiera de las siguientes razones o escenarios.


Nota En SQL Server 2005, puede revisar la log_reuse_wait y log_reuse_wait_desccolumnas de la vista de catálogo sys.databases para determinar por qué no se reutiliza el espacio de registro de transacciones y por qué no se puede truncar el registro de transacciones.


Transacciones sin confirmar
Las transacciones explícitas aún no están asignadas, si no se ejecute un comando explícito se CONFIRMARÁN o DESHARÁN. Esto se produce más frecuentemente cuando una aplicación emite un CANCEL o en un comando KILL de Transact-SQL sin un comando de reversión correspondiente. Se produce la cancelación de transacción, pero no deshace. Por lo tanto, SQL Server no se puede truncar todas las transacciones que se produce después de esto porque la transacción anulada todavía está abierta. Puede utilizar la referencia de Transact-SQL de DBCC OPENTRAN para comprobar que es una transacción activa en una base de datos en un momento determinado.Para obtener más información acerca de esta situación particular, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:
295108Transacción incompleta puede contener gran número de bloqueos y bloqueo de mayúsculas
171224 Comprender cómo funciona el comando KILL de Transact-SQL
Además, vea el tema "DBCC OPENTRAN" en SQL Libros en pantalla Server.

Escenarios que pueden dar lugar a las transacciones sin confirmar:
  • Diseño de una aplicación que se supone que todos los errores que versiones anteriores.
  • Diseño de una aplicación que no considere completamente el comportamiento de SQL Server cuando se deshacen las transacciones con nombre o especialmente anidar transacciones con nombre. Si intenta hacer roll back a una transacción con nombre interno, recibirá el mensaje de error siguiente:
    Servidor: Msg 6401, nivel 16, estado 1, línea 13 no puede revertir InnerTran. No se encontró transacción o punto de almacenamiento de ese nombre.
    Después de SQL Server genera el mensaje de error sigue a la siguiente instrucción. Esto es una característica diseño. Para obtener más información, vea "Transacciones anidadas" o "dentro de SQL Tema de servidor"en los libros en pantalla de SQL Server.

    Se recomienda lo siguiente cuando se diseña la aplicación:
    • unidad de sólo una transacción de la pluma (tenga en cuenta la posibilidad de que otro proceso puede llamar al suyo).
    • Compruebe @@TRANCOUNT antes de emitir una confirmación, una ROLLBACK, la devolución, o una similar comando o instrucción.
    • Escriba el código bajo el supuesto de que otro @@TRANCOUNT es posible que "anidar" suyo y el plan para el @@TRANCOUNT externo se mueva parte posterior cuando se produce un error.
    • Opciones de punto de almacenamiento y marca de revisión para las transacciones. (Éstas no liberar bloqueos!)
    • Realice una comprobación completa.
  • Una aplicación que permite la interacción del usuario dentro de las transacciones. Esto hace que la transacción puede permanecer abierta durante mucho tiempo y este bloqueo de las causas y registro de transacciones crecimiento debido a que no se puede truncar la transacción abierta y se agregan las nuevas transacciones en el registro después de la transacción abierta.
  • Una aplicación que no realiza una comprobación @@TRANCOUNT para comprobar que no existen transacciones abiertas.
  • Red u otros errores que cierran la aplicación de cliente conexión a SQL Server sin que le informa de él.
  • Agrupación de conexiones. Después de crear subprocesos de trabajo, SQL Server reutiliza si no está dando servicio a una conexión. Si una conexión de usuario inicia una transacción y se desconecta antes de confirmar o deshacer la transacción y una conexión de una vez vuelve a utilizar el mismo subproceso, la transacción anterior aún permanece abierta. Esta situación daría lugar a bloqueos que permanezcan abiertos de la transacción anterior e impide que el truncamiento de las transacciones confirmadas en el registro. Como resultado, los tamaños de archivo de registro de gran tamaño. Para obtener más información acerca de conexión la agrupación, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
    164221How to enable connection pooling en una aplicación ODBC


Transacciones muy grandes
Registros del registro en los archivos de registro de transacciones se truncan en una base de transacción por transacción. Si el ámbito de transacción es grande, que transacción las transacciones han iniciado y después de que no se quitan del registro de transacciones a menos que se complete. Esto puede producir en los archivos de registro de gran tamaño. Si la transacción es suficientemente grande, el archivo de registro es posible que utilice el espacio disponible en el disco y hacer que el tipo de "registro de transacciones completo" del mensaje de error, como Error 9002. Para obtener más información acerca de qué hacer cuando aparece este tipo de mensaje de error, consulte la sección "Más información" en este artículo. Además, que tarda mucho tiempo y gastos generales de SQL Server para deshacer las transacciones de gran tamaño.

Operaciones: DBCC DBREINDEX y crear el índice de
Debido a los cambios en el modelo de recuperación en SQL Server 2000, Cuando se utiliza el modo de recuperación completa y se ejecuta DBCC DBREINDEX, la transacción Registro puede aumentar significativamente más con respecto de SQL Server 7.0 en un modo de recuperación equivalente con el uso de SELECT INTO o copia masiva y con "Trunc." En chkpt. "cierre la sesión.

Aunque el tamaño de la transacción Después de esta operación DBREINDEX puede producirse un problema, este enfoque proporciona mejor rendimiento del registro de restauración.

Al restaurar desde copias de seguridad de registro de transacciones
Esto se describe en el siguiente Microsoft Knowledge Base artículo:
232196 Espacio de registro utilizado parece crecer después de restaurar desde copia de seguridad

Si configura SQL Server 2000 para utilizar el modo Bulk-Logged y ejecute una instrucción de copia masiva o SELECT INTO, medida de lo modificado se marca y, a continuación, copia de seguridad cuando se hace una copia del registro de transacciones. Aunque esto permite volver configurar los registros de transacciones y recuperación de errores incluso después de realizar operaciones masivas, esto aumentaría el tamaño de los registros de transacciones. SQL Server 7.0 no incluye esta característica. SQL Server 7.0 sólo registra qué extensiones se cambian, pero no registra las extensiones reales. Por lo tanto, el registro utiliza significativamente más espacio en SQL Server 2000 que en SQL Server 7.0 en modo de registro masivo, pero no tanto como lo hace en modo completo.

Las aplicaciones cliente no procesan todos los resultados
Si emite una consulta a SQL Server y no controla los resultados inmediatamente, puede que mantiene bloqueos y reducir la simultaneidad en el servidor.

Por ejemplo, suponga que emite una consulta que requiere las filas de dos páginas para llenar el conjunto de resultados. SQL Server analiza, compila y ejecuta la consulta. Esto significa que los bloqueos compartidos se agregan en las dos páginas que contienen las filas que debe tener para satisfacer su consulta. Además, suponga que no todas las filas que quepan en un paquete TDS de SQL Server (el método por el que el servidor se comunica con el cliente). Paquetes TDS se rellena y envía al cliente. Si todas las filas de la primera página caben en el paquete TDS, SQL Server libera el bloqueo compartido en esa página, pero deja un bloqueo compartido en la segunda página. SQL Server, a continuación, espera que el cliente solicitar más datos (puede hacerlo mediante DBNEXTROW/DBRESULTS, SQLNextRow/SQLResults o FetchLast/FetchFirst por ejemplo).

Esto significa que es el bloqueo compartido almacena hasta que el cliente solicita el resto de los datos. Otros procesos que se pueden bloquear datos de la solicitud de la segunda página.

Consulta el tiempo de espera antes de que un registro de transacciones termine la expansión y recibe mensajes de error de "Registro lleno" falsos
En esta situación, aunque no hay suficiente espacio en disco, todavía recibirá un mensaje de error "insuficiente espacio".

Esta situación varía para SQL Server 7.0 y SQL Server 2000.

Una consulta puede hacer que el registro de transacciones se expanda automáticamente si el registro de transacciones está casi lleno. Esto puede tardar más tiempo y una consulta puede detenerse o puede exceder su período de tiempo de espera debido a esto. SQL Server 7.0 devuelve error 9002 en esta situación. Este problema no se aplica a SQL Server 2000.

En SQL Server 2000, si tiene la opción de reducción automática activada para una base de datos, hay muy pequeño tiempo durante el cual trata de un registro de transacciones se expanda automáticamente. Sin embargo, no se puede expandir porque se está ejecutando la función de reducción automática al mismo tiempo. Esto puede causar también falsas instancias de error 9002.

Por lo general, la expansión automática de archivos de registro de transacciones se produce rápidamente. Sin embargo, en las siguientes situaciones, puede tardar más de habitual:
  • Incremento de tamaño es demasiado pequeño.
  • El servidor es lento por diversas razones.
  • Las unidades de disco no son lo suficientemente rápidas.


Transacciones sin duplicar
Si está utilizando replicación, puede expandir el tamaño de registro de transacciones de la base de datos de publisher . Transacciones que afectan a los objetos que se han replicado están marcados como "For Replication". Estas transacciones, por ejemplo, las transacciones sin confirmar, no se eliminan después de punto de comprobación o después de realizar la copia del registro de transacciones hasta que la tarea de lector del registro copia las transacciones en la base de datos de distribución y quita la marca de ellos. Si un problema con la tarea de lector del registro que impide leer estas operaciones en la base de datos de publicador , el tamaño del registro de transacciones podrán ampliar como aumenta el número de transacciones que no son replicadas. Puede utilizar el DBCC Referencia de OPENTRAN Transact-SQL para identificar la más antigua que no sea replicado transacción.

Para obtener más información acerca de cómo solucionar problemas de las transacciones sin duplicar, vea los temas "sp_replcounters" y "sp_repldone" en los libros en pantalla de SQL Server.

Para obtener más información, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:
306769REVISIÓN: No se puede truncar registro de transacciones de base de datos publicada de instantánea
240039 REVISIÓN: DBCC OPENTRAN no generar ninguna información de replicación
198514 REVISIÓN: Restore a nuevo servidor, las transacciones permanecen en el registro
Información avanzada
El registro de transacciones para cualquier base de datos se administra como un conjunto de archivos de registro virtuales (VLF). SQL Server determina internamente en función del tamaño total del archivo de registro y el incremento de crecimiento que se utiliza cuando el registro se expande de tamaño de los archivos VLF. Un registro siempre se expande en las unidades de VLF completa y sólo podrá comprimir aquellos a un límite VLF. Un VLF puede estar en uno de estos tres estados: activo, recuperable y REUTILIZABLE.
  • Activo: la parte activa del registro comienza en el número de secuencia de mínimo del registro (LSN) que representa una transacción activa (sin confirmar). La parte activa del registro de termina en el LSN escritas por última vez. Se considera cualquier VLF que contengan cualquier parte del registro activo (el espacio no utilizado en el registro físico no es parte de cualquier VLF.) de active VLF.
  • Recuperable: la parte del registro que viene antes de la transacción activa más antigua es sólo necesaria para mantener una secuencia de copias de seguridad de registro para la recuperación.
  • REUTILIZABLE: si no mantiene copias de seguridad de registro de transacciones, o si usted ya se hizo backup el registro, SQL Server reutiliza VLF antes de la activa más antigua transacción.
Cuando SQL Server llega al final del archivo de registro físico, lo hará volver a utilizar ese espacio en el archivo físico mediante la emisión de una operación que CIRCUNDA volver al principio de los archivos. De hecho, SQL Server recicla el espacio en el archivo de registro que ya no es necesario para fines de recuperación o copia de seguridad. Si se mantiene una secuencia de copia de seguridad de registro, la parte del registro antes de la mínima LSN no se puede sobrescribir hasta que hacer copia de seguridad o truncar esas entradas del registro. Después de realizar la copia de seguridad, puede rodear con círculos de SQL Server vuelve al principio del archivo. Después de que SQL Server círculos atrás para empezar a escribir entradas del registro anterior en el archivo de registro, la parte reutilizable del registro de es, a continuación, entre el final del registro lógico y la parte activa del registro.

Para obtener más información, vea el tema "Arquitectura física del registro de transacciones" en los libros en pantalla de SQL Server. Además, puede ver un diagrama y una explicación al respecto en la página 190 de "Inside SQL Server 7.0" (Soukup, Ron. Inside Microsoft SQL Server 7.0, Microsoft Press, 1999) y también en las páginas 182 a 186 del "Inside SQL Server 2000" (Delaney, Kalen. Inside Microsoft SQL Server 2000, Microsoft Press, 2000).Bases de datos SQL Server 2000 y SQL Server 7.0 tienen la posibilidad de crecimiento automático y autorreducción. Puede utilizar estas opciones para ayudar a reducir o ampliar el registro de transacciones.

Para obtener más información acerca de cómo estos Opciones de puede afectar al servidor, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
315512Consideraciones para la configuración de crecimiento automático y autorreducción en SQL Server
Truncamiento de archivo de registro de transacciones se diferencia de la compresión del archivo de registro de transacción. Cuando SQL Server trunca un archivo de registro de transacciones, esto significa que se elimina el contenido de ese archivo (por ejemplo, las transacciones confirmadas). Sin embargo, si está viendo el tamaño del archivo desde una perspectiva de espacio de disco (por ejemplo, en el Explorador de Windows o mediante el comando dir ), cambiará el tamaño. Sin embargo, ahora se puede reutilizar el espacio dentro del archivo .ldf por las nuevas transacciones. Sólo cuando SQL Server se reduce el tamaño del archivo de registro de transacciones ¿ve realmente un cambio en el tamaño físico del archivo de registro.

Para obtener más información acerca de cómo reducir registros de transacciones, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:
256650Cómo reducir el registro de transacciones de SQL Server 7.0
272318 Reducir el registro de transacciones en SQL Server 2000 con DBCC SHRINKFILE
Para obtener más información acerca de registro de transacciones de SQL Server 6.5 uso de, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
110139Causas SQL registro de transacciones se llene

Cómo buscar las consultas que consumen una gran cantidad de espacio de registro en SQL Server 2005

En SQL Server 2005, puede utilizar la vista de administración dinámica (DMV) de sys.dm_tran_database_transactions para localizar las consultas que consumen una gran cantidad de espacio en el registro. Las siguientes columnas de la sys.dm_tran_database_transactions DMV puede ser útil:
  • database_transaction_log_bytes_used
  • database_transaction_log_bytes_used_system
  • database_transaction_log_bytes_reserved
  • database_transaction_log_bytes_reserved_system
  • database_transaction_log_record_count
Puede consultar la columna sql_handle de la DMV para obtener el texto de la declaración real que consume mucha cantidad de espacio en el registro al sys.dm_exec_requests. Para ello, puede unirse a la sys.dm_tran_database_transactions DMV y el DMV sys.dm_tran_session_transactions en la columna de transaction_id y, a continuación, agregar una combinación adicional al sys.dm_exec_requests en la columna "session_ID".

Para obtener más información acerca de sys.dm_tran_database_transactions DMV, vaya a la Sys.dm_tran_database_transactions (Transact-SQL) Sitio Web de Microsoft Developer Network (MSDN).

Para obtener más información acerca de sys.dm_tran_session_transactions DMV, vaya a la Sys.dm_tran_session_transactions (Transact-SQL) Sitio Web de MSDN.

Para obtener más información acerca de la DMV al sys.dm_exec_requests, vaya a la al sys.dm_exec_requests (Transact-SQL) Sitio Web de MSDN.

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 317375 - Última revisión: 07/12/2013 08:54:00 - Revisión: 3.1

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition

  • kbsqlsetup kbinfo kbmt KB317375 KbMtes
Comentarios
ld(m); ipt">var guid = ("xxxxxxxx-xxxx-4xxx-Rxxx-xxxxxxxxxxxx".replace(/x/g, function () { return Math.floor(Math.random() * 16).toString(16); })).replace("R", (8 | Math.floor(Math.random() * 3)).toString(16)); var m = document.createElement("meta"); m.content = guid; m.name = "ms.dqid"; document.getElementsByTagName("head")[0].appendChild(m);