¿DBA a quien le preocupa reorganizar o reconstruir índices puede causar la pérdida de datos?

Tenemos algunas bases de datos con fragmentación de índice que es> 95%. Lo mejor que puedo decir es que los índices nunca han sido reconstruidos y mucho menos reorganizados. En años.

(Para ser justos, estas tablas parecen tener estadísticas actualizadas automáticamente. También, para ser justos, es diligente con las copias de seguridad: registros diarios completos y trx por hora).

Cuando pregunté, el DBA dijo que era reacio a reconstruir o reorganizar los índices. Cuando le pregunté por qué, realmente no podía articularlo. Finalmente, dijo que estaba preocupado por la posible pérdida de datos. Por ejemplo, nuestra aplicación de contabilidad Great Plains Dynamics utiliza una de las bases de datos, y parecía muy ansioso por eso.

No soy un DBA, pero por lo que he leído, su ansiedad parece ... difícil de entender para mí.

No estoy seguro de qué hacer a continuación. ¿Sugerencias de cómo debo proceder?

sql-server maintenance Greg Hendershott
fuente

A menos que la base de datos se vea afectada las 24 horas del día, los 7 días de la semana, y el mundo llegue a su fin si se desconecta, no hay excusa para tal comportamiento. Escribo reorganizaciones y estadísticas todas las semanas en más de 12,000 bases de datos sin pensarlo dos veces. En 16 años solo he tenido uno corrupto debido a un mal controlador.

Brain2000 el

Respuestas:

La reconstrucción de un índice de base de datos no debería causar ninguna pérdida de datos. Sin embargo, probablemente causará una degradación sustancial del rendimiento ya que los índices que se están reconstruyendo normalmente no estarán disponibles para su uso hasta que finalice la reconstrucción. Por esa razón, debe hacerse fuera de horario cuando los sistemas afectados están inactivos.

La paranoia es algo bueno en un DBA: si están preocupados por la pérdida de datos, les pediría que realicen una prueba adecuada de las copias de seguridad (restaurarlas en un sistema separado y asegurarse de que todos los datos estén allí), y si están aún preocupado, realizar una copia de seguridad completa antes de reconstruir los índices sería una precaución razonable.

voretaq7
fuente

+1 para Paranoia es un buen rasgo de DBA

Joel Coel

Entiendo completamente y aprecio la paranoia saludable. Mida dos veces, corte una vez. ¿Dónde estoy desconcertado es esto parece al de la falta de comprensión en lugar de precaución. Y en lugar de "determinemos una forma de probarlo con cuidado", es "sí, no va a suceder". Podríamos (por ejemplo) poner en cola una instancia de EC2 de prueba con una copia de los datos, reorganizar los índices, cronometrar, delta las filas de la tabla de resultados para confirmar que no se dañaron los datos. Ese tipo de plan sería precaución ... en lugar de inacción?

Greg Hendershott

Solo un recordatorio de que la reorganización del índice siempre está en línea (todos los índices están disponibles durante la desfragmentación) y la reconstrucción del índice también se puede hacer en línea ( WITH (ONLINE=ON)siempre que el índice no contenga columnas BLOB.)

Remus Rusanu

@Greg Sí, la mentalidad de "No toquemos los índices que están tan fragmentados que probablemente DAÑAN el rendimiento" también me confunde muchísimo. El ocasional REINDEX"mantenimiento preventivo" en las tablas donde el contenido del índice cambia mucho es bastante común en mi experiencia (si el índice es mayormente estático, es menos importante)

voretaq7

Sugerencia de @Remus: esto disminuye el impacto en el rendimiento (todavía tendrá una alta E / S de disco, lo que lo ralentizará un poco, pero al menos las cosas que usarían un índice aún pueden usarlo en lugar de recurrir a escaneos secuenciales )

voretaq7

No hay riesgo de pérdida de datos por la reconstrucción o desfragmentación de índices.

mrdenny
fuente

A menos que ya tenga algún grado de corrupción de datos, o haya fallas en el hardware. ¡Pero en cualquiera de esos casos, la fragmentación del índice es la menor de sus preocupaciones!

db2

Pero eso no sería corrupción de una reconstrucción de índice, sino de algún otro problema.

mrdenny

La reorganización de los índices llevará menos tiempo y menos esfuerzo del servidor SQL, por lo que se pueden hacer en un tipo de instancias de la noche a la semana. Si lo que dice es cierto, incluso reorganizar los índices que nunca lo han sido, también puede causar un mayor impacto en el servidor. La reconstrucción de los índices requerirá una cantidad considerable de esfuerzo del servidor SQL, ya que se eliminan y reconstruyen. Hacer una reconstrucción en una noche de la semana no vale el riesgo de que el servidor esté ocupado con los índices y no sirva a las personas que lo usan.

Estoy de acuerdo con voretaq7, si está preocupado por trabajar con índices, pruébelo primero en el desarrollo o pruebe los servidores para ver cómo reaccionan.

Control de clasificación
fuente

Otro enfoque a tomar puede ser explícitamente DROP INDEXy volver a CREATE INDEX- No estoy seguro acerca de SQL Server, pero sé que PostgreSQL a veces funciona mejor eliminando un índice y comenzando desde cero en lugar de intentar reconstruirlo ( REINDEX).

voretaq7

Estoy bastante seguro de que es innecesario soltar y recrear en SQL Server.

Justin Dearing

@Justin Estoy bastante seguro que tienes razón (de hecho desde mis días de Sybase Recuerdo que un comportamiento de la indexación es efectivamente una gota / crear lo que no hay rareza índice de bloqueo como en Postgres)

voretaq7

Reorganizar los índices puede llevar menos tiempo. El que demore más dependerá de la cantidad de fragmentación del índice.

mrdenny