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ê!
fonte
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.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áginaVmWare replicationque aremote host. O que notei até lhe escrever uma resposta é que não podemos destruir o espelho da maneira normal. O arquivo estava bloqueado e precisamosstop SQL servicemover os arquivos db para outro diretório. A partir desse momento está tudo bem (eu verifico os logs usandosys.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 sobreVmWare).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.Respostas:
Encontramos o problema. É um erro no SQL Server. Quando configuramos
READ_WRITEo comando não é transferido corretamente para omirrorbanco de dados. Quando o script inicia a alteraçãopartitionsno servidor espelho, ocorreu um erro. Depois disso, a sincronização é arruinada e o banco de dados no espelho é bloqueado (nosuspendedestado).Corrigimos o problema atualizando o SQL Server para a versão mais recente (nossa versão inicial era sem SP).
fonte