A restauração de um banco de dados SQL a partir do backup reconstrói seus índices?

10

A restauração de um banco de dados SQL a partir do backup reconstrói suas tabelas e índices do zero? Ou mantém na mesma ordem física interna em que estava no momento do backup?

Estamos usando o SQL 2000 com o backup compactado do Quest Lightspeed, se isso faz alguma diferença.

sql-server restore

— BradC
fonte

16

A resposta é não, para qualquer software de backup que esteja sendo usado.

Um backup é uma operação física, não uma operação lógica. Ele lê todas as extensões que contêm páginas alocadas (ou seja, mesmo que apenas uma única página de uma extensão de 8 páginas esteja alocada, ele fará backup de toda a extensão de 64K) e faz isso em ordem física.

Uma restauração é uma operação física, não uma operação lógica. Estabelece as extensões em seus devidos lugares nos arquivos de dados.

A reconstrução de um índice (ou algo parecido) é uma operação lógica, que deve ser registrada. O backup e a restauração manipulam os arquivos de dados diretamente, sem passar pelo buffer pool, motivo pelo qual isso não pode ser feito. Outro motivo para isso não poder ser feito é que o backup e a restauração não compreendem o que está contido nos dados que estão sendo salvos em backup.

A principal razão pela qual isso não pode ser feito, no entanto, é que a movimentação de páginas durante uma operação de restauração quebraria os ponteiros da árvore b. Se a página A apontar para a página B, mas a página A for movida pelo processo de restauração, como a página B será atualizada para apontar para a página A? Se for atualizado imediatamente, poderá ser substituído pelo restante do processo de restauração. Se a atualização for adiada, e se o processo de restauração restaurou algum log de transações que removeu a página A ou a página B? Simplesmente não pode ser feito.

Bottom line - backup e restauração são operações físicas que nunca alteram os dados.

Espero que isto ajude!

PS Embora não aborde diretamente essa questão, consulte o artigo que escrevi para a TechNet Magazine de julho, que explica como os vários backups funcionam internamente: Entendendo os backups do SQL Server . A revista de setembro terá o próximo da série sobre o entendimento de restaurações.

— Paul Randal
fonte

2

Adoro o fato de você ter explicado que a indexação é uma operação lógica.

— 21138 Jim B

Ah, isso faz sentido. O backup captura extensões físicas completas de 64k, não páginas de dados de 8k.

— 28909 BradC

Isso não faz sentido. As operações de backup freqüentemente compactam os dados dos quais eles fazem backup, e esse é o tipo de "alteração" de que estamos falando: afinal, os índices podem ser recriados a partir das tabelas, eles são dados redundantes (desde que o backup do esquema seja feito) , claro). O verdadeiro motivo é a preguiça por parte dos desenvolvedores do banco de dados.

— John John

1

@ John O que você está dizendo é um absurdo? A compactação não é mencionada em nenhum lugar aqui - apenas a reconstrução dos índices, que não são de modo algum o mesmo que a compactação (que não altera as páginas ou sua localização no banco de dados durante uma restauração, enquanto a reconstrução o faz). A recriação de índices do zero durante uma restauração seria incrivelmente lenta em comparação com apenas restaurá-los como estão no backup. Eu acho que você está entendendo algo errado aqui.

— Paul Randal

Descartar e reconstruir índices é um tipo de compactação e a compactação pode mudar qualquer coisa, dependendo do tipo de compactação. A compactação com perdas no processamento de imagens ainda é chamada de compactação. Qualquer mecanismo que represente informações fornecidas em um espaço menor é uma forma de compactação e a remoção de índices é um exemplo trivial disso. O tempo de reconstrução lento pode realmente ser um argumento real, pelo menos contra a implementação ser um empreendimento que vale a pena.

— John

6

Um backup SQL nativo é apenas um despejo de página por página dos arquivos de backup; portanto, a resposta é "não". Um backup de velocidade da Quest provavelmente usa algum tipo de algoritmo de compactação de compactação, mas ainda não "reconstrói" os arquivos ou índices de dados, o que levaria uma quantidade enorme de tempo em um grande banco de dados.

— Aaron Alton
fonte

Sim, mas tem que gravar todas as páginas em disco de qualquer maneira. Por que não escrevê-los em sequência lógica, em vez de em uma ordem fragmentada? (Talvez este seja mais um de backup questão em vez de um restaurar pergunta: faz a gravação de backup as páginas em ordem física, ou em ordem lógica?)

— BradC

supondo que houvesse um produto que gravasse os dados em ordem de índice, em qual ordem você gostaria que a tabela fosse salva? Digamos que eu tenha uma tabela com 3 colunas product_id, productname e price. Qual é a coluna correta a ser classificada para salvar as páginas na ordem indexada? BTW, não há nada impedindo a indexação em toda a tabela (um índice em cluster) ou em cada uma das linhas (índice composto).

— 21719 Jim B

@ Jim B: Isso é fácil. As tabelas seriam salvas na ordem do índice em cluster. Os índices não agrupados seriam armazenados em ordem de chave. As pilhas seriam mantidas na ordem original (não classificada). (Aaron e Paul mencionaram razões válidas para que o backup / restauração não faça isso. Não conseguir descobrir a "ordem preferida" não é uma dessas razões. Ou então, fazer uma reconstrução completa do índice teria o mesmo problema. )

— BradC

Os dados são armazenados em backup exatamente na mesma ordem de página física em que são salvos nos arquivos do banco de dados. Quando os dados são restaurados, eles são restaurados na mesma ordem de página em que foram copiados. O SQL não move os dados por vários motivos. Incluindo que pode haver problemas com transações que restauram logs e problemas de encadeamento de páginas, sem mencionar a enorme quantidade de tempo extra necessário para embaralhar os dados em bancos de dados com várias TB.

— mrdenny

2

O backup é feito regularmente e com muita frequência (espero). Portanto, os designers garantiram que o backup seja o mais rápido possível. Qual é a E / S mais rápida? Sequencial. Você lê blocos de discos em ordem física exata, tem o melhor desempenho.

Por que na Terra o banco de dados deve executar operações de E / S aleatória complicada todas as noites , destruindo as cabeças dos discos por todo o lugar? A diferença seria em torno de duas ordens de magnitude. Não há ganho possível nisso.

— kubanczyk
fonte

Concordo com o seu argumento geral, mas, dependendo da configuração de armazenamento subjacente, a E / S aleatória pode não ter ordens de magnitude piores que a E / S sequencial (uma unidade SAN que está espalhada por dezenas de eixos, por exemplo). De fato, se o arquivo de dados estiver fragmentado no disco rígido, mesmo a E / S "sequencial" não será realmente sequencial. Mas pontos de Paulo substituir isso de qualquer maneira (o problema com a atualização de ponteiros, e que a desfragmentação deve ser uma operação registrada)

— BradC

0

Hummm. BradC, você já trabalhou com o Firebird / Interbase - onde o principal utilitário de backup / restauração / API é mais parecido com o "Copy Database ..." do SSMS / EM? Se sim, saiba que o MS SQL Server NÃO é desse tipo.

Um SQLServer Backup é mais um despejo de banco de dados que é restaurado "COMO ESTÁ" - portanto, é mais como um atalho on-line confortável para uma operação "desanexar-copiar-reconectar em outro local". O banco de dados restaurado é quase uma cópia exata do arquivo de banco de dados original (quase porque você pode alterar o posicionamento dos arquivos de banco de dados de um banco de dados restaurado) ...

— Fabricio Araujo
fonte