Recriando o banco de dados com backup no SQL Server 2000 – Parte 02

Resumo

Este artigo descreve uma situação onde é necessário recriar um banco de dados a partir de um arquivo que contém um backup de um banco de dados do SQL Server 2000. As instruções necessárias para verificar o conteúdo do backup assim como e as opções para a recriação completa do banco são explicadas passo a passo.

Verificando o backup

A primeira verificação que fiz foi através do uso da instrução RESTORE VERIFYONLY. Conectei-me ao SQL Server que estava sendo executado localmente na minha estação de trabalho, configurei o banco de dados Master para a conexão e enviei  a instrução apresentada na Listagem 1 para checar se o arquivo era um backup do SQL Server. O comando RESTORE VERIFYONLY além de verificar se o arquivo é um backup do SQL Server ainda checa a  consistência deste backup.

Listagem 1. Verificando a consistência do arquivo

Ao executar a instrução da Listagem 1 pude verificar que uma grande quantidade de informações estava sendo lida do disco rígido da minha estação de trabalho. Isto faz sentido pois o arquivo ocupava aproximadamente 6 GB. O SQL Server precisou fazer uma leitura e verificação dos bytes armazenados. Um fato curioso é que não houve um gasto excessivo de memória e nem de processamento durante a leitura do arquivo, que levou alguns minutos.

Após o término da execução da instrução da Listagem 1 o  SQL Server retornou a mensagem “The backup set is valid”  indicando que o arquivo continha ao menos um backup do SQL Server, confirmando a minha suspeita inicial a respeito do conteúdo do arquivo, e que este backup poderia ser restaurado.

Uma vez constatado que o arquivo continha ao menos um backup o próximo passo que tomei foi verificar quantos backups e quais tipos de backups estavam contidos dentro deste arquivo. Para efetuar esta operação utilizei a instrução RESTORE HEADERONLY indicando como parâmetro a localização do arquivo, como mostrado na Listagem 2.

Listagem 2. Obtendo informações sobre o backup.

A instrução da Listagem 2 foi executada rapidamente e o SQL Server retornou uma linha com várias colunas e informações importantes sobre o backup contido neste arquivo. A Tabela 1  mostra as principais colunas e valores retornados pela instrução RESTORE HEADERONLY e os valores destas colunas referentes ao backup contido no arquivo RJ_RELAT-02-10-2005.BAK.

Tabela 1. Descrição e valores das principais colunas retornadas pelo comando RESTORE HEADERONLY.

Analisando o resultado da instrução pude obter várias informações úteis. A primeira delas é que o backup não está protegido por senha e que existe apenas um backup neste arquivo, pois somente uma linha foi retornada.

Descobri ainda que o arquivo contém um backup completo do banco de dados RELAT com a Collation SQL_Latin1_General_CP1_CI_AS gerado no dia 02/10/2005 no servidor chamado SERVERSQL02 que possuía uma instalação do SQL Server 2000. Com estas informações já tinha quase tudo o que precisava para restaurar o banco de dados a partir deste backup.

As últimas informações que ainda precisava para poder restaurar o banco de dados contido neste backup dizem respeito aos arquivos de dados e transaction log deste banco RELAT. Para obter estas informações utilizei a instrução RESTORE FILELISTONLY como mostra a Listagem 3.

Listagem 3. Obtendo informações sobre os arquivos de dados e de transaction log do backup.

O resultado da execução da instrução apresentada na Listagem 3 é mostrado na Figura 1.

Figura 1. Resultado da execução da instrução RESTORE FILELISTONLY.

A instrução RESTORE FILELISTONLY retornou seis linhas indicando o nome dos arquivos lógicos na coluna LogicalName, a localização física dos arquivos no servidor que foi feito o backup na coluna PhysicalName, o tipo de cada arquivo na coluna Type (D indica arquivo de dados e L arquivo de transaction log), o  FileGroup na qual cada arquivo pertence na coluna FileGroupName, o tamanho em bytes dos arquivos no momento do backup na coluna Size e o tamanho máximo em bytes que os arquivos poderiam chegar na coluna MaxSize.

A partir dos dados pude notar que este banco de dados possuía três arquivos de dados, cujos nomes lógicos eram Relat, rELAT1 e Relat2, e três arquivos de transaction log, cujos nomes lógicos eram Relat_log, Relat_lo1 e Relat_lo2. Notem que não podemos identificar o tipo de arquivo somente pela sua extensão e que os arquivos de transaction log não pertencem a nenhum FileGroup.

Com os dados retornados pelas instruções RESTORE VERIFYONLY, RESTORE HEADERONLY, e RESTORE FILELISTONLY já tinha informações suficientes para restaurar o backup em um servidor que não possuía o banco de dados RELAT.