Perché la replica san è causante corruzione casuale del database?

Question

Avere uno strano problema con una tecnologia di disaster recovery stiamo cercando di implementare. L'ambiente in entrambi i datacenter è lo stesso con VMware e Dell EqualLogic sans, che sono le stesse versioni.

Quando replichiamo da un datacenter a un altro, i database casuali vengono danneggiati in qualche modo e finiscono in modalità sospetto. Ogni volta che proviamo questo metodo, diversi database verranno danneggiati. È un comportamento in SQL che sta causando questo? È questo il software utilizzato nella SAN per replicare causando questi errori?

Sono stato in grado di modificare lo stato del database in modalità di emergenza ed eseguire DBCC CheckDB, ma è un problema e un database diverso ogni volta. Alcuni degli errori che ho trovato sono problemi di indice e problemi di disallineamento dei dati. Sono ancora in procinto di controllare altri database per vedere se riesco a trovare un modello. Se trova altre cose, sarò sicuro di pubblicare se ti aiuterà.

Ho sentito parlare di persone che implementano questa procedura con successo ed è l'ultima attività nel progetto da capire prima di poter chiudere la Carta del progetto.

Stavo davvero sperando che potremmo semplicemente usare le funzionalità integrate di SQL Server come il mirroring o AO-AGS.

Le versioni di SQL sono il 2008 R2 e 2012. Siamo in procinto di installare alcuni nuovi server SQL 2014. Inoltre, sono tutti standard, non aziendali.

Qualsiasi input o cose che potrei provare sarebbe di grande aiuto, grazie in anticipo !!

Modifica # 1 8/08/15 12:50 PM CST - Di seguito sono riportati alcuni dei messaggi di errore che ho trovato nel Viewer Event Windows, che è più o meno di ciò che ha prodotto DBCC CheckDB.

.

.
• EventID 605 - Tentativo di recuperare la pagina logica (1: 22620) nel database 26 non riuscita. Appartiene all'unità di allocazione 72057594239385600 non a 72057594249412608
• EventID 824 - SQL Server ha rilevato un errore I / O basato sulla coerenza logico: PAGED errato (atteso 1: 1230; 0: 0). Si è verificato durante una lettura di una pagina (1: 1230) in ID del database 58 su Offset 0x000000000099C000 in file 'D: \ mydatabase.mdf'. Ulteriori messaggi nel registro degli errori di SQL Server o nel registro eventi di sistema possono fornire maggiori dettagli. Questa è una grave condizione di errore che ha minacciato l'integrità del database e deve essere corretta immediatamente. Completa un controllo di coerenza completa del database (DBCC CHECKDB).
• EventID 7886 - Un'operazione di lettura su un oggetto di grandi dimensioni è fallito durante l'invio di dati al client. Una causa comune per questo è se l'applicazione è in esecuzione in Leggi il livello di isolamento non conquistato. Questa connessione sarà terminata.
• EventID 608 - Nessuna voce del catalogo trovata per ID partizione 72057594383564800 nel database 23. I metadati sono incoerenti. Eseguire DBCC CheckDB per verificare la presenza di una corruzione dei metadati.

Modifica n. 28/08/15 2:24 PM CST - Informazioni ricevute che ripristinare i file .bak dei database in modalità sospetto risolvono la questione.

Answer 1

In relazione al tuo commento, sospetto un problema relativo a OPS, invece di un problema del motore SQL Server. Questi dispositivi SAN di solito funzionano sullo strato di blocco e alcuni gestisci il file di registro di transazione / file di dati di sincronizzazione meglio di altri, così come altre aree.

È possibile mostrare il team OPS che No, SQL Server non corrompe casualmente i dati come questo. È possibile ripristinare i backup su un altro server, il mirroring di configurazione e tutto ciò accade senza corruzione. Nel momento in cui facciamo la replica di livello di san che succede. Se SQL Server ha causato la corruzione in questo modo non sarebbe in giro. SQL Server ha quasi milioni di linee di codice che si occupano di corruzione, fissando la corruzione e riducendo il potenziale della corruzione. Non ottieni questo problema in nessun altro ambiente e viene visualizzato solo la replica san, corretta?

Il firmware è spesso una causa principale di questi tipi di problemi. Ottieni il tuo supporto di supporto Dell sulla linea, avranno molte più informazioni e risoluzione dei problemi. Non accontentarti di un rappresentante pigro, i dati e il tempo della tua impresa sono sulla linea. Hanno un sacco di strumenti che controllano per vedere cosa sta causando questo sullo sfondo e altri strumenti come DPAC che potrebbe aiutare. Questo non è un problema del motore SQL Server, avremo bisogno del pieno supporto di OPS.

Modifica: Se il tuo firmware non è aggiornato o non corrispondente, ottieni una politica dal team OPS che gestisce il SAN che afferma che manterranno il firmware attraverso la pila delle macchine che gestiscono fino ad oggi. Se questo SLA non esiste, dovresti prendere nota dei tuoi manager perché sei esposto a molti altri problemi oltre a questo.

Suppongo che tu stia usando la replica di livello di blocco di san.

Potrebbe anche essere anche mancata corrispondenza nelle impostazioni. Forse diverse dimensioni di blocchi, ecc. Ma il San OS dovrebbe essere in grado di rilevare questi problemi di solito.