Pratico di SQL Server Blog

Rompere il backup catena - REDUX (o mangiare Crow)

Anche se mi piace l'orgoglio di essere me stesso professionista abbastanza da ammettere quando sbaglio, si scopre che sono un po 'più superficiale di quanto mi piacerebbe essere.

Per esempio, io spesso dico ai miei clienti che io non so tutto su SQL Server (e che chi pretende di sapere tutto è qualcuno che deve fuggire da). Di conseguenza, non mi dispiace aver sbagliato quando ho 'indovinare' le cose con loro, come stiamo cercando di capire i vari problemi e le questioni insieme.

Ma, come ho scoperto in questi ultimi giorni, ammettendo che mi sbaglio è stato effettivamente un po 'un incubo - per due motivi:

In primo luogo perché ero sbagliato in un caso che davvero contava: ho offerto imperfetto consulenza professionale. E che, a sua volta significa che ho avuto modo di sentire contemporaneamente malati di offrire un cattivo consiglio, mentre anche sentirsi stupidi di fare così in 'davanti a tutti'.

In secondo luogo, questo è stato un incubo, perché questo è purtroppo un caso in cui mi sono sbagliato su un concetto chiave per tutto troppo lungo. Anni di fatto.

MI SONO SBAGLIATO

Dato che mi sono sbagliato, voglio fare due cose con questo post:

In primo luogo, voglio correggere la cattiva informazione che ho postato in precedenza. A tal fine, piuttosto che correggere il mio post precedente, ho intenzione di lasciarlo intatto e 'update' con avvertimenti circa le informazioni male - con un link a questo post.

In secondo luogo, voglio anche dare un'occhiata a come ho finito per essere così sbagliato perché penso che un post-mortem della mia mente-set può essere istruttivo e può aiutare gli altri si spera di evitare di cadere in trappole simili. (E se devo essere sincera, voglio anche la possibilità di, umm, mi difendo un po '.)

COME MI SBAGLIAVO

Nei precedenti due messaggi: backup di SQL Server - Quando più è meno e non utilizzati arma segreta - Backup COPY_ONLY , ho erroneamente collegato backup COPY_ONLY a fornire 'protezione' per il backup dei log delle transazioni. Non è corretto. I backup del log delle transazioni non sono sensibili ai problemi che ho descritto in termini di rompere la catena di backup. Solo backup differenziali sono.

Essere sbagliato che fa schifo. Ma è anche opportuno ricordare che anche se ero totalmente sbagliata circa la portata della bruttezza che non COPY_ONLY backup può causare, la realtà esiste ancora che i backup 'extra' o non COPY_ONLY può ancora causare disastri - ma non così aggressivo come ho erroneamente dichiarato (e creduto) in entrambe le cariche sopra elencate.

Quindi, ha dichiarato in modo diverso, se un backup completo viene eseguito nell'ambiente senza la clausola COPY_ONLY, può / comprometterà la catena di backup in quanto ripristina il LSN base differenziale di tutti i backup differenziali successivi. Meaning, a sua volta, che se non hanno (o mantenere) l'accesso a tale backup completo fatto senza l'opzione COPY_ONLY, non sarà in grado di recuperare i database utilizzando i backup differenziali successivi.

Potrete, comunque , essere in grado di utilizzare i backup dei log delle transazioni se li avete. Ed è qui che mi sbagliavo . Ho erroneamente assume che un backup completo (senza la clausola COPY_ONLY) avrebbe in qualche modo rompere i backup dei log delle transazioni pure. (Più su che in un secondo.)

Di conseguenza, le immagini ho fornito nel mio ultimo post per mostrare i negativi e positivi di backup COPY_ONLY dovrebbe apparire come segue - dove sto utilizzando i backup DIFF invece di backup TLOG come destinazione per queste immagini:

 

Figura 1: non COPY_ONLY backup spezzare la catena di log per i backup differenziali successivi.

 

Figura 2: backup COPY_ONLY preservare la catena di log per i backup differenziali.

E, giusto per assicurarsi che io sia perfettamente chiaro, questo è probabilmente una migliore immagine / visione delle implicazioni corretto di lavorare con la catena di backup:

 

Figura 3: Una migliore visione d'insieme della catena di log ei backup COPY_ONLY - che mostra come i backup COPY_ONLY non può rompere le catene backup differenziale, ma come backup del log delle transazioni può essere usato per recuperare, indipendentemente da considerazioni COPY_ONLY.

Quindi, ha dichiarato in modo diverso, un buon modo per proteggersi contro i non-COPY_ONLY backup è quello di avere sempre una catena ininterrotta di backup del log delle transazioni per il backup completo più recente. A questo punto è possibile tentare di utilizzare i backup DIFF come un modo per recuperare più rapidamente se avete bisogno di. Solo nei casi in cui questo avrebbe senso, che ci si a che fare con grandi basi di dati sufficiente che io sono abbastanza sicuro che ci si desidera controllare LSN applicabile prima di iniziare. E, se questo è qualcosa che ti interessa, allora ti consigliamo di controllare un grande post di Paul Randal dove ricopre query di esempio si potrebbe facilmente adattare al vostro scopo qui: backup con COPY_ONLY - Come evitare di rompere la catena di backup .

POST MORTEM (O COME MI È VENUTO PER ESSERE ERRATO)

Sbagliare un simile 'core' concetto di SQL Server ancora mi ha avvolti. Soprattutto perché mi sono sbagliato su questo per tanto tempo. Ma, come ho detto, ho sentito che la condivisione di alcune delle sfondo dietro come ho fatto a sbagliare potrebbe essere utile un po 'un avvertimento per tutti coloro che sono abbastanza pazienti da leggere fino a qui. A tal fine, ciò che segue è un po 'di post-mortem.

Il più vicino io possa determinare, a circa 10 anni fa (se la memoria non mi tradisce) mi sono imbattuto in un problema di brutto con un non-mission-critical database in cui non ero in grado di ripristinare il log delle transazioni come previsto. Ero davvero solo iniziando a fare la mia incursione nel 'DBA-hood', al momento, e non ha mai fatto capire esattamente quale sia il problema specifico che aveva incontrato. Ma, quando SQL Server 2005 è stato rilasciato con l'idea di un backup COPY_ONLY, penso naturalmente per scontato che è stato progettato per proteggere me contro il tipo di problema che avevo incontrato con il log delle transazioni.(Oppure, cosa più importante, anche se non era il caso, in qualche modo erroneamente che i backup COPY_ONLY applicato il log delle transazioni.)

Nel corso degli anni, questo semplice e sbagliato, presupposto è rimasto. E siccome sono sempre stato troppo cauto potenzialmente rompere il (transazione) catena di log nella mia mente, non ho mai veramente mi metto in una posizione in cui ho 'sfidato' questa ipotesi. Invece, nella mia mente questo è stato più simile a un enorme lavandino buche che ho cercato di sterzare decisamente chiaro - e aiutare gli altri a evitare pure. Che, a sua volta, è stato aggravato da due errori:

In primo luogo, prima che io bloggato (nel mio post precedente) su come backup del log delle transazioni potrebbe essere usato contro di backup COPY_ONLY (e il backup 'sorgente') simultaneamente, sono andato avanti e ha fatto in modo di testare tutto fuori - solo per assicurarsi che non avessi ' t trascurato qualcosa.Purtroppo, i miei test sono stati focalizzati solo sulla metà dell'equazione: fare in modo che i file di log delle transazioni potrebbe funzionare dopo un backup COPY_ONLY è stata fatta. Che, ora che mi guardo indietro su di essa, era un test totalmente muto - come che è sempre sta per uscire positivo. Che cosa avrei dovuto testato è stato il caso opposto pure. Che, a sua volta, è per questo che sono sicuro che la comunità scientifica si è rivolta a test in doppio cieco - come mi fu vittima l'antica trappola della creazione di un test che ha confermato quello che io credevo di sapere, invece di garantire il contrario e passare da lì. Il mio male - e lezione (si spera) imparato.

In secondo luogo, nel corso degli anni ho versato sopra la documentazione nella documentazione in linea sia per la sezione Utilizzo dei backup del log delle transazioni (dove si parla di rompere la catena di log) e la sezione dove si parla di backup COPY_ONLY e in ogni caso è TOTALMENTE possibile (e, francamente, molto facile) di leggere entrambe le sezioni della documentazione con la mia ERONOUS mentalità e la fa convalidare più e più volte. O, in altre parole, posso ancora totalmente leggere entrambe le sezioni della documentazione con l'idea sbagliata nella mia testa sui backup del log delle transazioni e le operazioni COPY_ONLY e 'sentire' come se convalidare quello che ho in precedenza, e in modo errato, il pensiero. Per esempio, in 'intro' di backup COPY_ONLY nella documentazione in linea, dice: ". Di solito, fare un backup di modifica del database e influisce sul modo in backup successivi vengono ripristinati" Quando ho letto questo, ho pensato che stesse parlando TLOG backup - perché è quello che Avevo già 'preconcette' si stava parlando. Inoltre, COPY_ONLY backup può essere applicato a Log backup di file - sorta ulteriore di 'confermare' nella mia mente che questa sezione stava parlando di backup file di registro - anche se questo evidentemente non è il caso.

Allora, che cosa sto cercando di dire è che ho avuto una falsa nozione nella mia mente per anni e passa più attraverso la documentazione ANCORA lasciatemi 'confermare' l'idea sbagliata più e più volte a causa della mia PRECONCIEVED (e scorretta) nozioni di ciò che la documentazione è stata dicendo. Mi piacerebbe dire: "In caso di dubbio, prova" come una risposta a questo. Ma nel mio caso, non c'era dubbio - mi era saltata a una conclusione errata anni fa. Così, da qualche parte in là, c'è una grande lezione di vedere ciò che si vuole vedere.

UN'ALTRA VITTORIA PER LA COMUNITÀ DI SQL SERVER

Infine, sarei negligente se non ringraziare i tre amministratori di database che ha commentato il mio ultimo post sul blog . Perché tanto quanto puzzava di scoprire che mi sbagliavo, preferirei sapere che mi sbagliavo piuttosto che continuare a sguazzare nell'ignoranza. Che è solo un altro motivo per cui amo la Comunità di SQL Server . Perché io probabilmente non avrei mai capito mi sono sbagliato su questo aveva rxmoore non registrato una risposta dettagliata (o un insieme di risposte) ed è stato affiancato da altri due amministratori di database che ha confermato la sua comprensione dei concetti e convalidato le sue scoperte / test pure. Così, grazie ragazzi - e apprezzo molto i tuoi commenti. Spero di forma in futuro abbastanza da meritare la vostra attenzione continua. ;)

Corso SQL Server - Corso Hyper-V -Corso Windows Server –

 Certificazione Microsoft