Perché il mio mirror del database si interrompe dopo aver modificato le impostazioni del gruppo di file da RESTRICTED_USER a MULTI_USER?


9

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-ONLYbandiera del mio gruppo di file storici.

3. Ho impostato DB per MULTI_USERconsentire 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é!


Error: 823, Severity: 24sembra un problema hardware. Controlla i tuoi DISCHI per vedere se sono andati male. Esegui checkdb sui database per assicurarti che siano puliti.
Kin Shah,

Non sono sicuro @Kin. Abbiamo un nuovissimo storage IBM specializzato con collegamento ottico. Funziona da circa 3 mesi. E questa è stata l'unica volta che abbiamo ricevuto questo errore. In realtà ci sono circa 10 righe con quell'errore, ma sono avvenute tutte durante quel periodo di tempo. Distruggiamo lo specchio e lo creiamo di nuovo. Abbiamo problemi a rimuovere il mirror. Quindi lo rimuoviamo manualmente.
Bogdan Bogdanov,


Facciamo entrambi i tipi di backup, @Kin. Dobbiamo anche VmWare replicationa 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 servicee 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).
Bogdan Bogdanov,

We do both type of backupspotrebbe essere un problema. Le istantanee delle macchine virtuali non devono essere utilizzate in alternativa ai backup del server sql nativo.
Kin Shah,

Risposte:


0

Abbiamo riscontrato il problema. È un bug in SQL Server. Quando impostiamo READ_WRITEil comando non viene trasferito correttamente nel mirrorDB. All'avvio della modifica partitionsdello script sul server mirror si è verificato un errore. Successivamente la sincronizzazione viene rovinata e il DB sul mirror viene bloccato (nello suspendedstato).

Risolviamo il problema aggiornando SQL Server all'ultima versione (la nostra versione iniziale era senza SP).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.