Recoverying Model Database

Recentemente tive algumas discussões a respeito de como proceder em caso a base de dados Model seja corrompida. A primeira coisa que escutei foi:

Nunca tivemos a base de dados model corrompida! É tão pequena que não teriamos problema

Bom, ai é que surge o problema! Se estamos pensando em um verdadeiro cenário de Disaster Recovery, nada pode passar despercebido por nós, nem mesmo aquela pequena base chamada de model. Se você quer saber um pouco mais sobre a mesma, indico a leitura do link abaixo.

https://msdn.microsoft.com/en-us/library/ms186388.aspx

Apenas para mostrar o comportamento do SQL Server com a model corrompida, você pode utilizar um hex editor qualquer, abrir o arquivo .mdf e editar o inicio do mesmo.

A figura abaixo mostra o model.mdf intacto.

image

Altere tudo para 00, salve e tente iniciar o SQL Server.

image

Ao tentar iniciar o serviço do SQL, via configuration manager, você recebe a seguinte mensagem.

image

E no Errorlog temos o seguinte erro reportado.

image

Vamos ilustrar então, algumas alternativas de recovery dessa base.

1. Realizar Backup Nativo e restore deste mesmo backup.

image

image

Iniciamos o SQL Server utilizando duas Trace Flags muito importantes.

T3608: Realiza o recovery somente da base master
T3609: Mantem o tempdb ja existente e não tenta criar um novo. Utiliza o ultimo checkpoint valido executado no tempdb logo antes do crash.

image

Realizado essa inicialização, precisamos abrir uma nova janela no CMD e utilizar o SQLCMD para se conectar na instancia e realizar o restore.

image

Basta agora encerrar o serviço iniciado pelo CMD, e iniciar o serviço do SQL via configuration manager e o serviço estará no ar novamente.

Como podemos ver, essa é a maneira mais rápida e comum que pode ser utilizada.

2. Mover os arquivos da model de outra instancia.

Essa parece ser uma solução interessante, vamos ver como o SQL Server se comporta.

Possuo duas instancias conforme imagem abaixo.

image

Basicamente, vou utilizar os arquivos da instancia SRVFRESQL14\SQL14 para restaurar a model da instancia default chamada SRVFRESQL14.

Vamos parar as duas instancias e realizar a movimentação de arquivos. Se você desejar, pode utilizar novamente o hex editor para corromper o arquivo.

image

image

Para fins de demonstração, estou utilizando o XCOPY, mas você pode utilizar a interface grafica para realizar a copia.

image

Pronto, substituição de arquivos feito, vamos iniciar o serviço do SQL.

A instancia está no ar novamente.

image

image

Antes de parar as instancias, criei uma tabela na instancia SQL14, para demonstrar que os objetos também são levados normalmente. Outro detalhe importante a ser lembrado é que a instancia SQL14 está em um build diferente por conta de um Cummulative Update que instalei. Então mesmo com CU’s diferentes, podemos realizar esse restore.

Vamos validar se instancias que possuem collations diferentes podem compartilhar a base model em um possível restore.

Collation Original

image

Collation de uma outra instancia

image

Agora, vamos realizar o mesmo procedimento de parada das duas instancias, e substituição dos arquivos.

image

Instancias iniciadas com sucesso, porem um detalhe na qual devemos nos atentar. Tanto o tempdb como as bases de usuário (caso utilize create database DatabaseName) utilizam como template de criação o banco de dados model, logo, a collation a ser utilizada é a da base model. Isso pode nos trazer diversos problemas como por exemplo: Bases de SharePoint que precisam de uma collation especifica, Joins entre tabelas físicas e tabelas temporárias, sorts realizado no tempdb, entre outros. Com isso, podemos ter um sério problema caso o mesmo ocorra. Portanto, tome muito cuidado!

image

Vamos tentar agora utilizar a base de dados model proveniente de uma versão anterior a necessaria. No meu caso, possuo uma instancia com a versão SQL Server 2014, e estarei utilizando os arquivos da model de uma instancia rodando SQL Server 2012 SP1.

image

Iniciamos o serviço do SQL, na qual o mesmo iniciou com sucesso. Como podemos ver na imagem abaixo a collation utilizada é a mesma da instancia rodando o SQL Server 2012.

image

image

Agora o ultimo teste antes de encerrar, vamos realizar o mesmo procedimento de copia de arquivos entre Service Packs diferentes.

image

image

Então o que vamos fazer é copiar os arquivos da model na instancia SQL12SP2 que se encontra com o Service Pack 2, para a instancia SRVFRESQL2012SP1. Como sempre, paramos ambos os serviços e realizamos as copias.

image

Arquivos copiados com sucesso, iniciamos o serviço do SQL Server e nenhum problema encontrado, a instancia esta rodando normalmente. Como podem ver, mesmo entre service packs diferentes, podemos realizar a cópia da model

image

3. E nossa ultima alternativa, seria criar em um outro disco a copia da base model e caso necessario, teriamos a mesma intacta para realizar o recovery.

É importante ressaltar que as õpções 2 e 3 são totalmente offlines, ou seja, você precisa parar o serviço do SQL para poder realizar o procedimento, tendo em vista que quanto menor a parada melhor, a opção 1 seria a melhor de todas.

Agora fica apenas a critério de escolha de cada um de vocês para o melhor cenario.

Espero que tenham gostado!

Marcos Freccia
SQL Server MVP

Sobre Marcos Freccia

MVP em SQL Server (Data Plataform) , especialista em SQL Server, e atualmente trabalhando com Microsoft Azure!

Publicado em março 24, 2015, em Administração, Dicas, SQL Server, VirtualPass e marcado como , , , , , . Adicione o link aos favoritos. 1 comentário.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: