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.

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

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

E no Errorlog temos o seguinte erro reportado.

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

1. Realizar Backup Nativo e restore deste mesmo backup.

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.

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

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.

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.

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

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

A instancia está no ar novamente.

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

Collation de uma outra instancia

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

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!

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.

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.

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

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.

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

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