Il mio ambiente è il seguente: server vitalizzato VMWare 5.5 MS Windows Server 2008R2 Dominio Enterprise e SQL Server 2008 R2 Enterprise . Archiviazione centralizzata con connessione Fibre Channel.
Ho delle partizioni nel mio SQL Server DB
. Ne ho 2 file groups
: uno con dati live (FG1) , secondo con dati storici (HDG) .
Il secondo gruppo di file è read-only
. Ogni mese faccio movimento nelle partizioni - aggiungo nuovi dati (dal mese precedente) ai dati storici. Questo processo è automatico .
Abbiamo spostato il nostro database su un nuovo server. Inizialmente, ho dovuto eseguire il processo manualmente . Durante questa operazione il mio mirror si guasta (dopo l'operazione 3 - vedere il flusso di processo sotto) con il seguente errore:
SUL SERVER PRINCIPALE:
FILO 0 in 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.
ROW 1 in 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.
ROW 2 in 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.
NOTA: Ho eseguito questa operazione sul vecchio server molte volte automaticamente e non ho mai riscontrato questo errore.
SU SERVER SPECCHI:
ROW 1 in 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.
ROW 2 in 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.
IL MIO PROCESSO È SEGUENTE:
1. Eseguo diversi backup del database (backup completo, gruppo file e TLog).
2. Ho impostato DB su RESTRICTED_USER
(per consentire la rimozione di sola lettura del flag del gruppo di file storico tramite script).
2a. Rimuovo la READ-ONLY
bandiera del mio gruppo di file storici.
3. Ho impostato DB per MULTI_USER
consentire il normale funzionamento del nostro software.
4. Aggiornamento le partizioni in modo che i dati vengano spostati nel gruppo di file storici.
5. Ripeto i passaggi 2 , 2a e 3 in modo da poter impostare di nuovo SOLO il gruppo di file storici.
6. Eseguo nuovamente i backup.
Qualcuno ha idea del perché ricevo questo errore?
EDIT: riceviamo lo stesso problema durante la diversa fase della procedura. Questa è l'unica situazione in cui il mirror si rompe, quindi suppongo che il problema sia all'interno della procedura, ma non riesco a capire perché!
823 with sev 24
è un problema hardware. Stai eseguendo backup a livello di file anziché backup nativi del server sql o c'è qualche software antivirus in esecuzione sul server? Dovresti mettere avvisi di sql agent per avvisarti quando si verifica un errore 823 - questo script ti aiuterà . Inoltre, 823 è un brutto errore da ottenere - afferma che un'operazione di I / O non è riuscita a livello di sistema operativo e che il sottosistema di I / O sta causando la corruzione - Il server sql non ha eseguito il checsum di pagina
VmWare replication
a remote host
. La cosa che ho notato fino a quando non ti ho scritto una risposta è che non possiamo distruggere il mirror in modo normale. Il file era bloccato e dobbiamo stop SQL service
e per spostare i file db in un'altra directory. Da quel momento va tutto bene (controllo i log usando sys.xp_readerrorlog
). Un altro pensiero è se una replica di VmWare avvenga proprio in quel momento, ma non sono sicuro di come questo influenzerà il processo (lo so poco VmWare
).
We do both type of backups
potrebbe essere un problema. Le istantanee delle macchine virtuali non devono essere utilizzate in alternativa ai backup del server sql nativo.
Error: 823, Severity: 24
sembra un problema hardware. Controlla i tuoi DISCHI per vedere se sono andati male. Esegui checkdb sui database per assicurarti che siano puliti.