¿RECONSTRUIR un HEAP causa tiempo de inactividad?

Esta es una pregunta un poco embarazosa, y no puedo creer que me haya perdido esto durante tantos años.

Tengo una base de datos de terceros de proveedores que tiene 401 tablas de montón. Recientemente me puse a usar los scripts y la configuración de Brent Ozar sp_BlitzFirstpara ejecutar cada 15 minutos para recopilar estadísticas de espera, etc.

Lo que descubrió fue que cada vez que se encontraba en un período de 24 horas me decía que arreglara los Reenvíos . Lo que probablemente sorprenderá a algunos lectores es que realicé una consulta en los DMV y recuperé algunas tablas con más de 150,000 valores de registros reenviados.

Entiendo que solucionar esto es tener un índice agrupado en la tabla, o como una solución temporal para ejecutar ALTER TABLE [tablename] REBUILD.

Sin embargo, lo que no he podido encontrar es si esto desconecta la tabla y si hay otros problemas que debería tener en cuenta antes de ejecutar este comando.

Estoy usando la Enterprise Edition de 2008 R2, y me pregunto si ejecutarla de esta manera eliminará la necesidad de una interrupción.

ALTER TABLE [tablename] REBUILD WITH (ONLINE = ON);  

¿Alguien tiene alguna experiencia con esto?

Buenas noticias: 150,000 registros reenviados no son realmente tan malos, dependiendo de qué tipo de lapso de tiempo estamos hablando. Los registros reenviados se rastrean siempre que el servidor esté activo (con algunos errores relacionados con un error en compilaciones específicas de 2012/2014 ).

Incluso cuando funciona en línea, sus usuarios pueden notarlo dependiendo de su rendimiento de E / S, el tamaño de la tabla, el número de índices no agrupados y sus cargas de trabajo.

Así es como lo abordo:

• Enumere las tablas con las advertencias de registros reenviados del tamaño de tabla más pequeño a más grande (no el número de registros reenviados)
• Reconstruya esas tablas en orden, a mano, algunas a la vez. No automatice esto: desea tener una idea de cómo responde su sistema a la reconstrucción de tablas pequeñas. Aprenderá bastante rápido si su servidor puede mantener el ritmo.
• Vigile el uso de su registro de transacciones. Si su archivo de registro es de 10 GB y está intentando reconstruir un montón de 50 GB, puede tener problemas. Puede mitigar estos problemas aumentando el cierre de sesión antes de tiempo durante las ventanas de mantenimiento y haciendo copias de seguridad de registro frecuentes mientras lo hace, pero seré sincero, con 150k registros reenviados en el lapso de unos pocos días, no lo haría No te molestes en pasar por tanto trabajo.
• En el futuro, trabaje con el proveedor para poner una clave agrupada en esas tablas. Sí, hay ocasiones en que los montones son apropiados, pero si se encuentra con el problema de registro reenviado, probablemente no se encuentre en una de esas situaciones amistosas con el montón.