Backup del registro delle transazioni Seriale o parallelo?

Ci capita di usare SQL Server 2012 Standard Edition. Mi capita anche di usare gli script di Ola Hallengren per fornire un framework semplice e flessibile per eseguire backup e manutenzione.

Questa domanda non riguarda tanto gli script di Ola quanto quelli delle migliori pratiche. Mi rendo conto che la risposta definitiva è "dipende dalle esigenze della tua azienda". Ma sto cercando di chiedere il consiglio della comunità su come soddisfare al meglio ciò che comprendo delle esigenze della nostra azienda.

Desidero impostare i backup del registro delle transazioni per ogni 15 minuti. In questo modo speriamo di non perdere più di 15 minuti di dati. Devo impostare un lavoro che utilizza ALL_DATABASES? o è meglio impostare un lavoro per ciascun database e lanciarli tutti in parallelo? Chiedo, perché ho la sensazione basata sul modo in cui vedo il funzionamento dello script di Ola che i backup vengono avviati in serie. L'aspetto negativo di seriale sarebbe che ogni backup successivo attende fino al completamento dell'altro. Ciò potrebbe potenzialmente aumentare la quantità di tempo tra i backup (ovvero, superiore a 15 minuti). Inoltre, la mia preoccupazione sarebbe che un errore in un backup impedisse il verificarsi degli altri, e non vorrei che fosse così. Vorrei che gli altri continuassero a fare il backup.

Quindi è vero che gli script di Ola vengono eseguiti in serie e anche un errore arresta i backup successivi?

Ed è meglio avere un lavoro per ogni database? o un singolo lavoro che fa tutto? La mia inclinazione è verso lavori separati, ma desidero capire cosa tendono a fare in genere i DBA di SQL Server.

Devo impostare un lavoro che utilizza ALL_DATABASES? o è meglio impostare un lavoro per ciascun database e lanciarli tutti in parallelo?

Vorrei suggerire di impostare un lavoro che esegua il backup dei registri delle transazioni (in serie). Ciò assicurerebbe inoltre che il backup non utilizzi pesantemente l'I / O perché si esegue il backup per il database uno alla volta.

Quali potrebbero essere gli svantaggi possibili con l'esecuzione in parallelo

1. Supponiamo che tu abbia 50 database e pianifichi il backup del registro delle transazioni di tutti i database e che tutti inizino a funzionare in parallelo, questo utilizzerà sicuramente molto I / O. E se il disco su cui esegue il backup dei file dovesse avere altri file di dati, vedresti la lentezza. Ho visto il backup diventare lento quando una query scadente che richiede molti I / O viene eseguita insieme al processo di backup.

2. Supponiamo che tu abbia 50 database, non sarebbe difficile gestire 50 lavori nell'agente SQL Server e quale sarebbe la condizione se tu avessi 100-200 database, non mi piacerebbe quando apri l'agente SQL Server e vedi molto lavoro, mantienilo semplice. Sono sicuro che lo stesso caso sarebbe con te.

L'aspetto negativo di seriale sarebbe che ogni backup successivo attende fino al completamento dell'altro. Ciò potrebbe potenzialmente aumentare la quantità di tempo tra i backup (ovvero, superiore a 15 minuti).

I backup dei log delle transazioni sono per lo più piccoli e se si dispone di un database occupato che produce molti record di log, potrebbe essere necessario modificare la frequenza di backup. Principalmente ho visto il backup del registro delle transazioni completarsi correttamente quando la frequenza è di 15 minuti. Non credo che dovrebbe essere motivo di preoccupazione per te.

Inoltre, la mia preoccupazione sarebbe che un errore in un backup impedisse il verificarsi degli altri, e non vorrei che fosse così

Direi che non ti preoccupare. I backup del registro delle transazioni non possono fallire se non si commette un errore. Gli errori possono essere

1. Il proprietario che esegue il lavoro viene rimosso da AD

2. Qualcuno ha cambiato il modello di recupero del database.

3. Spazio sul disco insufficiente

A parte quanto sopra, non ho visto alcun motivo per il fallimento del backup del registro delle transazioni. È molto robusto su cui puoi fare affidamento.

In generale, eseguire sempre i backup di T-log in serie; molte delle mie istanze hanno un paio di dozzine di database e molte sono molto attive e i backup del registro delle transazioni richiedono solo pochi secondi in totale; fino a mezzo minuto circa quando è particolarmente occupato.

L'esecuzione di backup in parallelo sarebbe davvero utile se fossero vere tutte le seguenti condizioni:

• I database e i file di registro sono tutti su mandrini indipendenti unici (o su dischi a stato solido in qualsiasi combinazione)

  • Solo per i backup di T-log, solo i file di registro dovrebbero soddisfare questo requisito.

• Le destinazioni di backup per ciascun database sono su mandrini separati.

• Non stai utilizzando SAN HBA o iSCSI condiviso o altra larghezza di banda tra l'istanza di SQL Server e il supporto.

• ovvero gli IOPS dalla lettura del database A e dalla scrittura del backup A NON utilizzano gli stessi dischi della lettura del database B e dalla scrittura del backup B.

Se tutto ciò è vero, è possibile che un certo grado di parallelismo riduca la quantità di tempo totale del calendario. Se tutto ciò non è vero, molto probabilmente causerai il crash di uno o più set di dischi e i tuoi backup paralleli in realtà impiegheranno più tempo del calendario rispetto al seriale, ma potrebbero anche causare la frammentazione del filesystem del sistema operativo o del livello di archiviazione, perché stai scrivendo Backup A e Backup B contemporaneamente!

Non preoccuparti che un backup non vada a buon fine e che il resto vada a buon fine: in caso di errore, devi comunque controllare tutto e le uniche volte in cui ho visto i backup fallire sono dovuti a:

• Errore del disco

• Errore del software di compressione Hyperbac / Litespeed / di terze parti (se si dispone di software tra SQL e il disco che non funziona)

  • Come avvertimento, l'errore potrebbe assumere la forma di un processo di backup che non termina mai, pertanto è utile avere alcuni controlli per "processi che durano più a lungo del previsto" che inviano avvisi.

• Errore del prodotto di crittografia (se si dispone di software tra SQL e il disco che non funziona)

• Errore di rete (se i file del database, o più probabilmente i file di backup, si trovano sulla rete)

• permessi

  • più comune con installazioni nuove di zecca

  • o posizioni di backup nuovissime

  • modifica dell'utente del servizio SQL Server (che è ciò che richiede le autorizzazioni per i backup normali)

  • bloccare l'utente del servizio SQL Server perché è utilizzato da più di una sola istanza di SQL Server

• Errori di configurazione

• Mancanza di corrente

• Crash del sistema operativo

La maggior parte dei quali non influenzerà l'uno e non gli altri a meno che non siano soddisfatte anche le condizioni di cui sopra.

Solo per aggiungere, Ola progetta i suoi script in cui se un backup del database non riesce a eseguire il backup per qualsiasi motivo, vengono tentati i successivi. Come affermato in precedenza, è possibile impostare un avviso per informarti del fallimento del processo poiché il processo di backup continuerebbe a fallire, anche se un solo backup del database non è riuscito su tutti i database utente, supponendo che si stia eseguendo il backup di tutti i database (uno lavoro per tutti).