Waarom duurt die database restore zo lang?

Bij maken van plannen voor disaster recovery is het een goed idee om te kijken hoe snel een full backup terug gezet kan worden. Onlangs duurde het terugzetten van één van de backups waar ik mee werkte zo’n 17 uur en dat is natuurlijk vrij fors. We gaan er uiteraard dan wél vanuit dat er geen parallelle processen op de machine draaien die de performance negatief beïnvloeden. Microsoft SQL Server biedt mogelijkheden om te kijken waar de restore precies zijn tijd aan kwijt is. Hiervoor worden trace flags gebruikt. Mijn tip is om de volgende trace flags te gebruiken:

– 3004; deze geeft inzicht in elke stap van de restore
– 3213; deze geeft inzicht in de restore configuratie zoals buffer en maxtransfersize
– 3605; schrijft de resultaten van de trace flags hierboven weg naar de SQL Server errorlog

Vergeet de trace flags na de restore niet uit te zetten, omdat de trace flags zelf ook de performance van de machine beïnvloeden!

Een aantal aandachtspunten onder het trage terug zetten van de database:

  • Controleer of in de SQL Server Logs de volgende melding voorkomt: SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete etc. Dit betekent vrijwel zeker dat de storage waaronder de SQL Server draait niet snel genoeg id.

  • Paul Randall heeft via deze pagina een script gedeeld waarmee de I/O latency van een SQL Server over een periode van tijd is vast te leggen. Met de cijfers kan het team dat verantwoordelijk is voor hardware kijken wat er nodig is.

  • Een derde probleem is wat in het engels ‘Zeroing’ wordt genoemd. Dit is de tijd die nodig is om het logbestand van de database door te nemen en alle verwerkte transactielogs te verwerken. Het is niet aan te raden, maar als het logbestand significant via SHRINKLOGFILE kan worden verkleind, komt dit de snelheid waarmee de backup kan worden teruggezet ten goede

Succes!