¿Cómo evitar que el registro de transacciones se llene durante la reorganización del índice?

Tenemos varias máquinas en las que hemos asignado previamente el tamaño del registro de transacciones a 50 gb. El tamaño de la tabla que estoy tratando de reorganizar es de 55 a 60 gb, pero va a aumentar continuamente. La razón principal por la que quiero reorganizar es reclamar espacio y cualquier beneficio de rendimiento debido a eso es una ventaja adicional.

El nivel de fragmentación de la tabla es 30 - 35%. En algunas de estas máquinas recibo el error "registro de transacciones lleno" y la reorganización falla. El tamaño del registro de transacciones alcanza hasta 48 gb. ¿Cuál es una buena manera de contrarrestar esto? No tenemos activado el incremento automático y soy reacio a hacerlo.

Puedo aumentar el tamaño del registro a un valor mayor, pero a medida que aumenta el tamaño de la tabla en el futuro, el valor puede no ser suficiente. También anula el propósito de reorganizar para reclamar espacio si voy a aumentar el tamaño del registro por igual. ¿Alguna idea sobre cómo puedo contrarrestar esto de manera efectiva? Usar el modo masivo no es una opción ya que la pérdida de datos no es aceptable.

La mejor práctica es por REORGANIZEdebajo de alrededor del 30% de fragmentación y por REBUILDencima de esto. Simplemente, REBUILDhace una copia limpia, lo REORGANIZEhace in situ.

Verifique lo que realmente está haciendo: no tiene un plan de mantenimiento para hacer ambos, ¿verdad?

En tablas más grandes (la tabla de 50 GB está llegando allí) he visto REORGANIZEconsumir todo el espacio de registro de transacciones si sigues esta regla. No a menudo: solo un sistema con un cierto patrón de carga. El REORGANIZEcorrió solo hasta que el registro se expandió y se consume todo el espacio de disco.

En su REBUILDlugar, cambiamos sin más problemas, pero ignoramos la fragmentación por debajo del 25%. Esto funcionó mejor para nosotros: tendrá que ver si funciona para usted.

REBUILDpuede afectar el rendimiento más que REORGANIZEen la producción, pero esto a veces puede mitigarse con la ONLINEopción (se requiere Enterprise Edition).

REORGANIZAR (como en ALTER INDEX ... REORGANIZE) es una operación muy rápida (bueno, principalmente ...), que requiere una pequeña cantidad de registro, puede interrumpirse en cualquier momento y reanudarse más tarde, y funciona internamente en transacciones de lotes pequeños :

la desfragmentación se realiza como una serie de transacciones cortas, por lo que no es necesario un registro grande si las copias de seguridad del registro se realizan con frecuencia o si la configuración del modelo de recuperación es SIMPLE.

¿Estás seguro de que no estás hablando de una reconstrucción ? Un índice RECONSTRUCCIÓN es lento, costoso, consume una cantidad enorme de registros (si no está fuera de línea y no se puede registrar mínimamente , la reconstrucción en línea no se puede registrar mínimamente), es una transacción gigante única y no se puede interrumpir sin perder todo el trabajo.

Me parece que está haciendo una reconstrucción, que es una operación realmente excepcional que no debe hacer a menos que tenga una razón muy bien pensada. ¿Qué tipo de reclamo espacial estás esperando? ¿Algo que DBCC CLEANTABLEno pueda manejar? ¿Ha verificado la estructura física de la tabla, se ha desviado de la estructura lógica (consulte las columnas de la tabla de SQL Server debajo del capó para obtener más detalles)?

Si realmente tiene que reconstruir la tabla, me temo que no tiene más remedio que morder la bala y asignar el registro necesario. No dejes que crezca automáticamente, solo ralentizará el proceso. Precrezca hasta 2.5 veces el tamaño de la mesa.

Si la tabla está particionada, puede reconstruir sin conexión (y reorganizar) una partición a la vez. La reconstrucción en línea solo se puede realizar en todo el nivel de la tabla.

He tenido este problema antes.

• Tiene una gran base de datos y una pequeña unidad de registro. Desea reorganizarse (por una variedad de razones).
• Cuando intente esto en una tabla fragmentada grande, el registro se llenará hasta que la unidad de registro esté llena y luego el comando se cancele.
• Si está en modo simple, otras transacciones pueden fallar hasta que se borre el registro en el siguiente punto de control, y si está en modo completo, otras transacciones pueden fallar hasta la próxima copia de seguridad del registro. ¡Corte!
• Si está en modo completo, aumenta la frecuencia de la copia de seguridad del registro, pero no ayuda a evitar el problema porque la reorganización se realiza en una transacción implícita, el registro no se borra hasta que esa transacción finaliza o cancela o se detiene.
• Y REALMENTE desea que la reorganización se ejecute hasta su finalización.

Eso es un poco contra-intuitivo porque sabe que si cancela la reorganización, puede continuar desde donde se quedó, es solo que un aborto confirma la transacción en lugar de retroceder.

Esto es lo que haces. Es un poco largo pero sencillo.

• Precrezca su archivo de registro a un tamaño relativamente grande, pero no al máximo. Básicamente, desea dejar suficiente espacio para hacer un trabajo útil, además de algunos pequeños crecimientos si ocurren, para que las operaciones normales no se detengan.
• Cree un trabajo para ejecutar su índice de reorganización ('Reorganizar').

• Cree una alerta de agente WMI ('Reorganizar la válvula de alivio') en una condición de rendimiento.

  • Objeto: SQLServer: Bases de datos
  • Contador: Porcentaje de registro utilizado
  • Instancia: (el nombre de su gran base de datos)
  • Alerta si el contador sube por encima de: 80
  • Respuesta: Ejecutar trabajo ('Reorganizar verificación')

• Crear un trabajo ('Reorganizar verificación')

  • En el trabajo, compruebe msdb.dbo.sysjobactivity para ver si se está ejecutando el trabajo 'Reorganizar'. Y si es ...
  • Detenga el trabajo y realice una encuesta hasta que se detenga. Esto puede demorar unos segundos.
  • (Si está en modo completo) Inicie su trabajo de copia de seguridad de registro y confirme cuando finalice.
  • Vuelva a verificar los sys.dm_os_performance_counters que su contador de espacio libre de registro ha reducido por debajo de su umbral.
  • Inicie el trabajo 'Reorganizar'.

• Pruebe todo esto en algún lugar, incluso en un entorno limitado de desarrollo, para asegurarse de que funcione correctamente antes de pegarlo en su servidor de producción.

Lo que verá es que el trabajo 'Reorganizar' comienza y comienza a llenar el registro. Cuando el registro alcanza un porcentaje lleno, activa la alerta WMI (dentro de aproximadamente 30 segundos) que ejecuta su otro trabajo que ve que el trabajo 'Reorganizar' se está ejecutando y es muy probable que tenga la culpa. Luego detiene 'Reorganizar', realiza una copia de seguridad, confirma que el espacio libre de registro ha vuelto a un valor razonable, luego inicia nuevamente su trabajo 'Reorganizar' que continuará donde se quedó.

Entonces, como puede, la razón por la que cambia el tamaño de su registro a una cifra razonable en este escenario es para reducir el número de crecimiento / desencadenante / trabajo / detención / reinicio, para que pueda ser más eficiente y también mantener suficiente espacio para el crecimientos ocasionales que no son atrapados a tiempo.

Este es un tipo de escenario extraño. Estoy bastante seguro de que habría resuelto esto hace unos años y, obviamente, aquí hay problemas fundamentales subyacentes. Pero si se ocupa de cientos de servidores, surgirán algunos casos extremos como este que no pueden tratarse de ninguna manera, por cualquier razón comercial, excepto por MacGyver, una solución temporal que hace el trabajo.

Mientras sea seguro, lógico, probado y bien documentado, no debería haber ningún problema.

Esto es lo que solía hacer (también tengo algunas tablas con más de 80 GB cada una) para la reorganización del índice (porque la reorganización del índice se puede detener en cualquier momento sin perder el trabajo de reorganización anterior).

1. Durante la reorganización del índice, aumentaré la copia de seguridad de tlog de mi frecuencia normal de 30 minutos a cada frecuencia de 10 minutos
2. Tengo otra sesión haciendo la verificación de espacio libre de tlog cada 1 minuto, y si el espacio libre de tlog está por debajo de un umbral, detendré la sesión de reorganización de índice e iniciaré (o esperaré) la copia de seguridad de tlog. Luego reinicie el índice reorg.

En mi marco de mantenimiento de índice, clasifico los índices en dos grupos, uno es para la reconstrucción del índice y otro para la restauración del índice. Para la reconstrucción del índice, utilizaré un enfoque algo diferente porque no quiero detener una sesión de reconstrucción del índice (lo que provocará una reversión y perderá todo el trabajo anterior). Durante la reconstrucción del índice, si mi sesión de monitoreo nota un escenario de espacio libre usado en el archivo tlog, la sesión de monitoreo aumentará automáticamente el archivo tlog y, en el peor de los casos (es decir, el disco está lleno), mi sesión de monitoreo creará otro archivo de registro ( pero luego lo dejaré caer) en otra unidad (la unidad de respaldo)

Tuve el mismo problema que el autor de la pregunta y, mirando sus comentarios, puedo decir que tuve la misma configuración. Mientras intentaba hacer un REORGANIZE, el registro crece hasta el tope, independientemente del tamaño, incluso varias veces el tamaño de toda la tabla.

El problema fue causado por la replicación transaccional . Aparentemente, no se puede hacer una copia de seguridad del registro hasta que REORGANIZEfinalice la operación. Leí en alguna parte que era un problema conocido de Microsoft, pero no estoy seguro de dónde.

Una vez que desactivé la replicación transaccional, las copias de seguridad de registros funcionaron normalmente de nuevo, y hacer copias de seguridad de registros cada 30 segundos mientras la reorganización funcionó bien para mí.

Supongo que estás ejecutando algo en la línea de:

ALTERAR ÍNDICE SOBRE REORGANIZAR

Desafortunadamente, no hay forma de ejecutar una organización parcial (la forma en que puede reducir parcialmente un archivo de registro, por ejemplo). Las formas en que puedo pensar sobre estos problemas son:

1) configure la base de datos en modo de recuperación simple mientras ejecuta la reorganización, pero dijo que no es aceptable

2) particione el índice: si puede pensar en una forma de particionar el índice para obtener particiones de aproximadamente el mismo tamaño, podrá reorganizar (o reconstruir con la opción en línea) cada partición de forma independiente y, por lo tanto, limitar el crecimiento del archivo de registro

Estoy seguro de que está haciendo esto, pero si no lo está, es posible que desee iniciar una copia de seguridad del archivo de registro antes y después de hacer cualquier optimización de índice, lo que le permitirá recuperar el espacio utilizado.