Por que meu espelho de banco de dados é interrompido após alterar as configurações do grupo de arquivos de RESTRICTED_USER para MULTI_USER?


9

Meu ambiente é o seguinte: VMWare 5.5 vitalized server Domínio do MS Windows Server 2008R2 Enterprise e SQL Server 2008 R2 Enterprise . Armazenamento centralizado com conexão Fibre Channel.

Eu tenho partições no meu SQL Server DB. Eu tenho 2 file groups: um com dados ao vivo (FG1) , segundo com dados históricos (HDG) .

O segundo grupo de arquivo é read-only. Todo mês eu faço movimento em partições - adiciono novos dados (do mês anterior) aos dados históricos. Este processo é automático .

Movemos nosso banco de dados para um novo servidor. Inicialmente, tive que fazer o processo manualmente . Durante esta operação, meu espelho quebra (após a operação 3 - veja o fluxo do processo abaixo) com o seguinte erro:

NO SERVIDOR PRINCIPAL:

ROW 0 no LOG:

Date        15.6.2015 20:54:11
Log     SQL Server (Current - 16.6.2015 07:55:00)

Source      spid84

Message
Setting database option MULTI_USER to ON for database MYDB.

LINHA 1 no LOG:

Date        15.6.2015 20:54:11
Log     SQL Server (Current - 16.6.2015 07:55:00)

Source      spid18s

Message
Error: 1453, Severity: 16, State: 1.

LINHA 2 no LOG:

Date        15.6.2015 20:54:11
Log     SQL Server (Current - 16.6.2015 07:55:00)

Source      spid18s

Message
'TCP://10.201.27.154:5022', the remote mirroring partner for database 'MYDB', encountered error 823, status 3, severity 24. Database mirroring has been suspended.  Resolve the error on the remote server and resume mirroring, or remove mirroring and re-establish the mirror server instance.

OBSERVAÇÃO: Eu executei esta operação no servidor antigo muitas vezes automaticamente e nunca tive esse erro.

NO SERVIDOR DE ESPELHO:

LINHA 1 no LOG:

Date        15.6.2015 20:54:11
Log     SQL Server (Archive #3 - 15.6.2015 21:33:00)

Source      spid17s

Message
Error: 823, Severity: 24, State: 3.

LINHA 2 no LOG:

Date        15.6.2015 20:54:11
Log     SQL Server (Archive #3 - 15.6.2015 21:33:00)

Source      spid17s

Message
The operating system returned error 5(Access is denied.) to SQL Server during a write at offset 0000000000000000 in file 'e:\Databases\MYDB_HISTRICAL.ndf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

MEU PROCESSO SEGUINTE:

1. Faço vários backups do banco de dados (backup completo, grupo de arquivos e TLog).

2. Defino DB como RESTRICTED_USER(para permitir remover somente leitura do sinalizador do grupo de arquivos históricos por script).

2a Eu removo o READ-ONLYsinalizador do meu grupo de arquivos históricos.

3. Configurei DB para MULTI_USERpermitir a operação normal do nosso software.

4. Atualizo as partições para que os dados sejam movidos para o grupo de arquivos históricos.

5. Repito as etapas 2 , 2a e 3 para que eu possa definir o grupo de arquivos históricos como READ ONLY novamente.

6. Faço backups novamente.

Alguém tem idéia de por que recebo esse erro?

EDIT: Recebemos o mesmo problema durante a fase diferente do procedimento. Esta é a única situação em que o espelho quebra, então suponho que o problema esteja dentro do procedimento, mas não consigo entender o porquê!


Error: 823, Severity: 24parece problema de hardware. Verifique seus discos para ver se eles estão com problemas. Execute o checkdb nos bancos de dados para garantir que eles fiquem limpos.
Kin Shah

Não tenho certeza @Kin. Temos um armazenamento IBM especializado em conexão óptica, totalmente novo. Ele opera a partir de cerca de 3 meses. E foi a única vez que recebemos esse erro. Na verdade, existem cerca de 10 linhas com esse erro, mas todas elas ocorreram durante esse período. Destruímos o espelho e o criamos novamente. Temos um problema para remover o espelho. Então, nós o removemos manualmente.
Bogdan Bogdanov

Erro 823 with sev 24é um problema de hardware. Você está fazendo backups em nível de arquivo em vez de backups nativos do servidor sql ou algum software antivírus está sendo executado no servidor? Você deve colocar alertas do agente sql para alertá-lo quando ocorrer um erro 823 - este script o ajudará . Além disso, 823 é um erro grave de obter - diz que uma operação de E / S falhou no nível do SO e o subsistema de E / S está causando corrupção - o servidor sql não fez checsum de página
Kin Shah

Fazemos os dois tipos de backup, @Kin. Nós também temos VmWare replicationque a remote host. O que notei até lhe escrever uma resposta é que não podemos destruir o espelho da maneira normal. O arquivo estava bloqueado e precisamos stop SQL servicemover os arquivos db para outro diretório. A partir desse momento está tudo bem (eu verifico os logs usando sys.xp_readerrorlog). Outro pensamento é se uma replicação do VmWare ocorrer nesse exato momento, mas não tenho certeza de como isso afetará o processo (pouco sei sobre VmWare).
Bogdan Bogdanov

We do both type of backupsAquilo pode ser um problema. Os instantâneos da VM não devem ser usados ​​como uma alternativa aos backups nativos do servidor sql.
Kin Shah

Respostas:


0

Encontramos o problema. É um erro no SQL Server. Quando configuramos READ_WRITEo comando não é transferido corretamente para o mirrorbanco de dados. Quando o script inicia a alteração partitionsno servidor espelho, ocorreu um erro. Depois disso, a sincronização é arruinada e o banco de dados no espelho é bloqueado (no suspendedestado).

Corrigimos o problema atualizando o SQL Server para a versão mais recente (nossa versão inicial era sem SP).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.