Cosa posso aggiungere a un server per rendere più veloci i ripristini SQL?

Ho un database SQL da 2,8 TB (principalmente file di dati, circa 400 GB di file di registro) che attualmente richiede circa 9 ore per il ripristino. Questo database viene utilizzato a scopo di test e deve essere eliminato e ripristinato da un backup tra ogni esecuzione, per assicurarsi che iniziamo sempre dallo stesso punto.

La mia domanda è che il server ha attualmente 12 core e 92 GB di RAM, con un sottosistema di dischi RAID 5 su cui si trova il database. Quali aree di solito causano colli di bottiglia per i processi di ripristino di SQL? È il disco, la memoria o la CPU?

sql-server performance

— Sean Long
fonte

Da quale supporto di backup stai ripristinando? A proposito RAID 5 comporta una pesante penalità in scrittura rispetto alla maggior parte degli altri livelli RAID, quindi potrebbe non essere il migliore per i test delle prestazioni.

— Chris McKeown,

I .bak (8 di loro suddivisi) si trovano sullo stesso array RAID 5 in cui vengono ripristinati, il che mi fa capire che probabilmente potrò gestirli meglio in futuro. Non ho un altro array abbastanza grande da contenere tutti i .bak, ma potrei essere in grado di suddividerli su diverse unità collegate direttamente. Inoltre, è un aspetto positivo del RAID 5. Ne sono consapevole, ma non stiamo ancora effettuando prove di stress, quindi va bene se si tratta di un collo di bottiglia sull'unità disco in questo momento durante gli attuali test di carico. Una volta che avremo un po 'più avanti aumenteremo le prestazioni del disco tramite SAN, RAID 0 o RAID 1 + 0

— Sean Long

Certamente la tua sofferenza è indebitamente dovuta all'avere i backup sul disco che stai ripristinando. Quanti dischi nell'attuale RAID5?

— Mark Storey-Smith,

Quindi stai usando la compressione, suppongo. Quali altre opzioni di backup stai usando? Come vengono partizionati i tuoi dati? Sei in grado di distribuire in modo intelligente i dati tra gruppi di file (potresti semplicemente fare backup e ripristini dei gruppi di file sui dati modificati)?

— sweckeck,

Il problema è che i test toccano una percentuale molto grande del database, quindi dovremmo ripristinare su più gruppi di file (e i test cambieranno in base alle esigenze e allo sviluppo del carico di lavoro). Quindi, dovremmo esaminare costantemente il trucco del test e ripristinare i gruppi di file specifici. Sebbene sia un'opzione, non sono sicuro che ci farebbe guadagnare un sacco di tempo risparmiato.

— Sean Long,

Risposte:

Il tuo collo di bottiglia principale in un ripristino sarà l'IO del disco. Per risolvere il problema, in pratica sono necessari dischi più veloci o una configurazione diversa. Non so abbastanza su RAID o SAN per suggerire qualcosa lì. Potresti anche prendere in considerazione SSD. Sono incredibilmente veloci. Non vorrei usarli su qualcosa che non viene ricreato su base regolare (tempdb è sempre un buon candidato per questo) ma poiché lo ripristini frequentemente potrebbe essere ok. D'altra parte, probabilmente si desidera assicurarsi che il server di test sia il più vicino possibile al server di produzione se si eseguono test delle prestazioni.

Ci sono un paio di altre cose che puoi fare per aiutarti. Per prima cosa comprimi i tuoi backup se non lo sei già. Questo ovviamente presuppone SQL 2008 o versioni successive. Ridurrà non solo lo spazio su disco per l'archiviazione del backup, ma anche l'IO per la lettura. Vi è un costo della CPU, quindi attenzione. Inoltre, non eliminare il database, ripristinalo semplicemente. In questo modo i file sono già presenti e non ci sono spese generali per la loro creazione. È possibile attivare l'inizializzazione dei file istantanea (è un'autorizzazione a livello di server) per accelerare notevolmente la creazione / crescita dei file per il file di dati, ma non funzionerà per il file di registro.

— Kenneth Fisher
fonte

Buone informazioni, non mi ero reso conto che ripristinare sull'esistente fosse meglio che abbandonare / ripristinare da un backup. Stiamo già utilizzando la compressione e sto pianificando di verificare che l'inizializzazione del file istantanea sia abilitata per l'account che esegue il ripristino. Apprezzo molto la chiarezza della tua risposta, grazie!

— Sean Long,

Assicurarsi che l'inizializzazione dei file istantanea sia attivata anche sull'account che esegue SQL Server. Per un piccolo database probabilmente non è un grosso problema, ma per qualcosa che la dimensione che stai guardando potrebbe fare una grande differenza.

— Kenneth Fisher,

Ottima scelta. Inoltre, grazie per aver realizzato che i test delle prestazioni non significano sempre stress test (e che sono abbastanza limitato dal modo in cui la mia configurazione di produzione è attualmente impostata).

— Sean Long,

OT: "considera gli SSD ... non vorrei usarli su qualcosa che non viene ricreato su base regolare" ... perché?

— Martin,

Sarei ancora nervoso per il loro fallimento. Tutto ciò che ho letto ha detto di usarli per database come tempdb che vengono ricreati ogni volta che si avvia l'istanza, ma non di usarli per normali database di utenti. Anche se sono sicuro che sta cambiando nel tempo.

— Kenneth Fisher,

Non eseguire backup e ripristini; utilizzare le snapshot di SQL Server. Ci vuole molto spazio su disco per archiviare un file sparse delle stesse dimensioni dei file che hai acquisito, ma il rollback è centinaia di volte più veloce.

Sono disponibili nelle edizioni SQL Server Enterprise e SQL Server Developer.

— Mark Henderson
fonte

Questa è una buona idea e se questo fosse un server diverso da un server di test delle prestazioni, sembra un'ottima strada da percorrere. Tuttavia, sembra che le snapshot del DB non funzionino perché causeranno un sovraccarico aggiuntivo per il DB di origine, che non posso avere. Il test da eseguire è il test delle prestazioni (carico, stress, ecc.), Quindi dobbiamo evitare qualsiasi cosa esterna che possa causare stress.

Personalmente non ho notato differenze di prestazioni con l'istantanea, ma immagino che il copy-on-write abbia un certo sovraccarico; non conoscendo il tuo carico di lavoro, non posso giudicare.

— Mark Henderson,

Il suggerimento di @SeanLong Mark è probabilmente l'opzione migliore per il tuo scenario. Quello che penso che tu abbia frainteso è quando e di cosa fai l'istantanea. Il piano su un server di prova consisterebbe nel ripristinare il database di prova dal backup in tempo reale, quindi eseguire l'istantanea del database di prova, eseguire il ciclo di prova, quindi ripristinare l'istantanea, risciacquare e ripetere. Periodicamente è possibile tornare al passaggio 1 e ripristinare il backup live per eseguire nuovamente il test.

— Mark Storey-Smith,

Ah, capisco. Ho pensato che il mantenimento dell'istantanea richiedesse una quantità costante di overhead dal database di test, il che avrebbe influenzato i nostri test di carico (molto pesanti in scrittura / lettura). Non mi importa se il nostro carico di lavoro sta causando il collo di bottiglia sull'unità disco, non voglio solo un fattore esterno (che pensavo sarebbe stato lo snapshot di db) per causarlo.

— Sean Long,