Duas instâncias do MS SQL, um arquivo de banco de dados

Question

É possível ter um arquivo de banco de dados anexado a duas instâncias diferentes de SQL?

Considere que o MDF está localizado em um NAS e eu quero uma instância primária e secundária do MS SQL em dois servidores diferentes (não considerando cluster nessa questão) e desejo que ambas as instâncias façam referência a esse mesmo MDF.

Somente uma instância pode ser anexada ao MDF por vez ou pode ambas. Existe um problema ao anexar a instância SQL 'A', desconectando e anexando a instância 'B' a este MDF?

Obrigado pela sua contribuição.

    

Answer 1

Fev 2018 : Essa resposta é muito antiga e bastante desatualizada. Por favor, não confie nele para instalações SQL modernas (2014 ou acima). Mantê-lo abaixo para fins históricos

A maneira correta de ter um servidor de espera a frio no MSSQL é Envio de logs do SQL . Isso envolve ter duas cópias do banco de dados em dois servidores, com A restaurando os arquivos de log para B em intervalos regulares.

A maneira correta de ter um servidor em espera quente no MSSQL 2008 R2 ou abaixo é Espelhamento do banco de dados SQL . No SQL Server 2012 está AlwaysOn . Isso envolve ter duas cópias do banco de dados em dois servidores em sintonia um com o outro.

A maneira correta de ter um servidor de espera ativo no MSSQL 2008 R2 ou abaixo é SQL Clustering (em 2012 isso também faz parte do AlwaysOn). Isso envolve uma única cópia do banco de dados em uma SAN (não um NAS, a menos que seu NAS possa expor volumes iSCSI que ofereçam suporte a custer; alguns o fazem), Windows Server 2008 R2 Enterprise (ou 2012 Datacenter), SQL Server Enterprise e um configurado corretamente Cluster de Failover do Windows.

Nenhuma versão do SQL Server permitirá seus arquivos MDF / LDF armazenados em um compartilhamento CIFS / NFS / SMB. Eles devem ser armazenados no armazenamento em block, que oferece a opção de discos locais ou volumes SAN (como volumes expostos ao iSCSI ou FC).

    

Answer 2

Com esse tipo de esquema, não há garantia de que o MDF não será corrompido quando o servidor A falhar. Ou o NAS falha.

O esquema ignora o arquivo LDF. É comum as pessoas pensarem que o LDF não é importante, mas esse não é o caso. O LDF funciona como um log write-ahead e as alterações são "reproduzidas" quando uma instância é reiniciada (ou a outra instância é iniciada, como em um cluster). Você precisa do LDF ou perderá dados.

Outra coisa a considerar é que os dispositivos NAS baseados em SMB geralmente têm um desempenho horrivelmente ruim. Se o dispositivo suportar iSCSI, a situação provavelmente não será tão ruim. Se você usar o SMB, usar uma unidade mapeada é um incômodo. Você terá que ajustar o SQL Server para armazenar arquivos em um compartilhamento de rede.

Se você quiser evitar o armazenamento em cluster, faça o que todo mundo faz e examine o espelhamento de banco de dados (que foi introduzido no SQL Server 2005) ou envio de log (que pode funcionar com praticamente qualquer versão do SQL Server, embora o suporte oficial não estreia até o SQL Server 2000).

Seguir a multidão geralmente é a coisa mais segura a fazer, embora possa não ser a coisa mais interessante a se fazer. Quando você está lidando com dados de um cliente, você quer "seguro", não "interessante".

Independentemente da tática usada, há outros detalhes com os quais se preocupar, como garantir que as tarefas, os logins, as senhas, os IDs dos usuários etc. sejam mantidos atualizados nas duas instâncias. Lembre-se de manter seus backups diretos. etc.

    

Answer 3

A partir da leitura que fiz, o MS SQL usa o bloqueio de nível de arquivo em arquivos MDF. Como resultado, você não pode ter duas instâncias do MS SQL usando o mesmo arquivo se elas estiverem em execução. No entanto, você pode ter duas instâncias do MS SQL usando o mesmo MDF se você tiver um mecanismo para garantir que apenas uma seja executada por vez.

    

Answer 4

Se você estiver procurando por um método no qual deseja que um servidor SQL de backup quase pronto esteja em execução, uma opção seria apenas ter um backup do banco de dados gerado no servidor primário periodicamente. Então você pode ter um processo que copia o backup para o seu servidor secundário. Então você acabou de criar um script para importar o backup para o servidor secundário sempre que precisar.

Isso também elimina o dispositivo NAS externo como sendo o único ponto de falha se cada servidor tiver seu próprio armazenamento. Essa técnica funciona bem para versões mais antigas do SQL Server. No entanto, se você tiver a versão mais recente, o SQL Server 2012 Standard Edition (e superior) oferece suporte a um método ainda mais robusto de espelhamento de banco de dados. Veja o link abaixo:

Espelhamento de banco de dados do SQL Server 2012