¿Restaurar una base de datos SQL desde una copia de seguridad reconstruye sus índices?

10

¿Restaurar una base de datos SQL desde una copia de seguridad reconstruye sus tablas e índices desde cero? ¿O lo mantiene en el mismo orden físico interno que tenía en el momento de la copia de seguridad?

Estamos usando SQL 2000 con copia de seguridad comprimida Quest Lightspeed, si eso hace alguna diferencia.

sql-server restore

— BradC
fuente

16

La respuesta es no, para cualquier software de respaldo que se esté utilizando.

Una copia de seguridad es una operación física, no una operación lógica. Lee todas las extensiones que contienen páginas asignadas (es decir, aunque solo se asigna una sola página de una extensión de 8 páginas, realizará una copia de seguridad de toda la extensión de 64K), y lo hace en orden físico.

Una restauración es una operación física, no una operación lógica. Establece las extensiones en sus lugares legítimos en los archivos de datos.

Reconstruir un índice (o algo similar) es una operación lógica, que debe registrarse. La copia de seguridad y la restauración manipulan los archivos de datos directamente, sin pasar por el grupo de búferes, que es una de las razones por las que esto no se puede hacer. Otra razón por la que esto no se puede hacer es que la copia de seguridad y la restauración no comprenden qué contienen los datos que se están copiando.

Sin embargo, la razón principal por la que esto no se puede hacer es que mover páginas durante una operación de restauración rompería los punteros del árbol b. Si la página A apunta a la página B, pero el proceso de restauración mueve la página A, ¿cómo se actualiza la página B para que apunte a la página A? Si se actualiza de inmediato, el resto del proceso de restauración puede sobrescribirlo. Si se actualiza de forma diferida, ¿qué sucede si el proceso de restauración restableció algún registro de transacciones que eliminó la página A o la página B? Simplemente no se puede hacer.

En pocas palabras: la copia de seguridad y la restauración son operaciones físicas que nunca cambian los datos.

¡Espero que esto ayude!

PD Aunque no aborda directamente esta pregunta, consulte el artículo que escribí para la revista TechNet de julio que explica cómo funcionan internamente las diversas copias de seguridad: Comprender las copias de seguridad de SQL Server . La revista de septiembre tendrá el próximo de la serie sobre la comprensión de las restauraciones.

— Paul Randal
fuente

2

Me encanta el hecho de que explicaste que la indexación es una operación lógica.

— Jim B

Ah, eso tiene sentido. La copia de seguridad toma extensiones físicas completas de 64k, no páginas de datos de 8k.

— BradC

Esto no tiene sentido. Las operaciones de respaldo frecuentemente comprimen los datos que respaldan, y ese es el tipo de "cambio" del que estamos hablando: después de todo, los índices se pueden volver a crear a partir de las tablas, son datos redundantes (siempre que se haga una copia de respaldo del esquema , por supuesto). La verdadera razón es la pereza de los desarrolladores de bases de datos.

— John

1

@ John ¿Qué estás diciendo que no tiene sentido? La compresión no se menciona en ninguna parte aquí: solo reconstruir los índices, lo que no es lo mismo que la compresión (que no cambia las páginas o su ubicación en la base de datos durante una restauración, mientras que una reconstrucción sí). Volver a crear índices desde cero durante una restauración sería increíblemente lento en comparación con solo restaurarlos tal como están desde la copia de seguridad. Creo que estás malinterpretando algo aquí.

— Paul Randal

La eliminación y reconstrucción de índices es un tipo de compresión, y la compresión podría cambiar cualquier cosa, dependiendo del tipo de compresión. La compresión con pérdida en el procesamiento de imágenes todavía se llama compresión. Cualquier mecanismo que represente información dada en un espacio más pequeño es una forma de compresión, y la caída de índices es un ejemplo trivial de eso. Sin embargo, el tiempo de reconstrucción lento puede ser un argumento real, al menos en contra de que la implementación sea un esfuerzo valioso.

— John

6

Una copia de seguridad SQL nativa es solo un volcado de página por página de los archivos de copia de seguridad, por lo que la respuesta es "no". Una copia de seguridad de Quest Lightspeed probablemente usa algún tipo de algoritmo de compresión de compresión, pero aún así no "reconstruirá" los archivos de datos o índices, lo que tomaría una cantidad de tiempo horrendamente grande en una gran base de datos.

— Aaron Alton
fuente

Sí, pero tiene que escribir cada página en el disco de todos modos. ¿Por qué no escribirlos en secuencia lógica, en lugar de en un orden fragmentado? (Tal vez esta sea más una pregunta de respaldo en lugar de una pregunta de restauración : ¿la copia de respaldo escribe las páginas en orden físico o en orden lógico?)

— BradC

suponiendo que hubiera un producto que escribiera los datos en orden de índice, ¿en qué orden le gustaría guardar la tabla? Digamos que tengo una tabla con 3 columnas product_id, productname y price. ¿Cuál es la columna correcta para ordenar para guardar las páginas en el orden indexado? Por cierto, no hay nada que lo detenga de indexar en toda la tabla (un índice agrupado) o en cada una de las filas (índice compuesto).

— Jim B

@ Jim B: Eso es fácil. Las tablas se guardarían en orden de índice agrupado. Los índices no agrupados se almacenarían en orden de clave. Los montones se mantendrían en orden original (no ordenado). (Aaron y Paul han mencionado razones válidas por las cuales la copia de seguridad / restauración no hace esto. No ser capaz de resolver el "orden preferido" no es una de estas razones. De lo contrario, hacer una reconstrucción completa del índice tendría el mismo problema. )

— BradC

Se realiza una copia de seguridad de los datos en el mismo orden de páginas físicas en el que se guardan en los archivos de la base de datos. Cuando se restauran los datos, se restauran en el mismo orden de páginas en el que se realizó la copia de seguridad. SQL no mueve los datos por varias razones. Incluyendo que podría haber problemas con las transacciones que restauran registros y problemas de encadenamiento de páginas, sin mencionar las enormes cantidades de tiempo extra que se necesitan para mezclar los datos en bases de datos de TB múltiple.

— mrdenny

2

La copia de seguridad se realiza regularmente y con mucha frecuencia (espero). Así que los diseñadores se aseguraron de que la copia de seguridad sea lo más rápida posible. ¿Cuál es la E / S más rápida? Secuencial. Usted lee los bloques de los discos en el orden físico exacto, tiene el mejor rendimiento.

¿Por qué en la Tierra la base de datos debe realizar operaciones engorrosas de E / S aleatorias todas las noches , destrozando las cabezas de los discos por todas partes? La diferencia estaría alrededor de dos órdenes de magnitud. No hay ganancia posible en esto.

— kubanczyk
fuente

Estoy de acuerdo con su punto general, pero dependiendo de la configuración de almacenamiento subyacente, las E / S aleatorias pueden no ser órdenes de magnitud peores que las E / S secuenciales (una unidad SAN que se distribuye en docenas de husillos, por ejemplo). De hecho, si el archivo de datos está fragmentado en el disco duro, incluso la E / S "secuencial" no es realmente secuencial. Pero los puntos de Paul anulan esto de todos modos (el problema con la actualización de los punteros, y que la desfragmentación debería ser una operación registrada)

— BradC

0

Hmmm BradC, ¿ha trabajado antes con Firebird / Interbase, donde la principal utilidad de copia de seguridad / restauración / API es más parecida a la "Copiar base de datos ..." del SSMS / EM? Si es así, sepa que MS SQL Server NO es así.

Una copia de seguridad de SQLServer es más un volcado de la base de datos que se restaura "TAL CUAL", por lo que es más como un cómodo acceso directo en línea para una operación de "separar-copiar-volver a colocar en otro lugar". La base de datos restaurada es casi una copia exacta del archivo de base de datos original (casi porque puede cambiar la ubicación de los archivos de la base de datos restaurada) ...

— Fabricio Araujo
fuente