Discussion :

[cpofm]

Je suis en SQL2008R2 SP1 et la restauration d'une base de 1,8 Go prend 20 minutes.

Il se passe environ 45 secondes lorsque je choisis le fichier puis 45 secondes durant laquelle l'avancement de l'éxécution passe de 0 à 100%.
Ensuite le pourcentage reste à 100 % pendant 20 minutes avant d'afficher le message de réussite.

J'avais cru voir sur un forum que ce problème serait résolu avec le SP2.

Je viens de faire l'essai avec le SP2, c'est un peu moins long mais c'est encore trop long.

45 secondes pour la sélection
45 secondes pour passer de 0 à 100%
8 minutes après pour avoir le message de réussite

A quoi correspond ce temps ?

Y a t il une solution pour réduire ce temps ?

Merci d'avance

[mikedavem]

Hello,

1- Est-ce que tu peux nous mettre le contenu du journal des erreurs SQL pendant le moment de ta restauration ?

2- Est-ce que tu peux également nous fournir le résultat de la commande suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
USE <mabase>; 
GO
 
DBCC LOGINFO

++

[cpofm]

Le journal de log pendant la restauration


09/10/2013 09:42:22,,Inconnu,Database was restored: Database: BDCPO<c/> creation date(time): 2011/11/28(12:30:05)<c/> first LSN: 704829:165:42<c/> last LSN: 704829:183:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=DISK: {'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\BDCPO_backup_2013_09_10_090005_1331698.bak'}). Informational message. No user action required.,,,,,,,
09/10/2013 09:42:21,,Inconnu,Restore is complete on database 'BDCPO'. The database is now available.,,,,,,,
09/10/2013 09:42:21,spid53,Inconnu,CHECKDB for database 'BDCPO' finished without errors on 2013-09-10 00:00:05.637 (local time). This is an informational message only; no user action is required.,,,,,,,
09/10/2013 09:42:21,spid53,Inconnu,Database BDCPO has more than 1000 virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.,,,,,,,
09/10/2013 09:41:42,spid53,Inconnu,Starting up database 'BDCPO'.,,,,,,,
09/10/2013 09:41:42,spid53,Inconnu,Database BDCPO has more than 1000 virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.,,,,,,,
09/10/2013 09:37:14,spid53,Inconnu,The database 'BDCPO' is marked RESTORING and is in a state that does not allow recovery to be run.,,,,,,,


La commande loginfo donne 38829 enregistrements en réponse

voilà le début

2 253952 8192 704830 2 64 0
2 253952 262144 0 0 128 0
2 253952 516096 0 0 128 0
2 278528 770048 0 0 64 0
2 253952 1048576 0 0 128 450911000000030600364
2 253952 1302528 0 0 128 450911000000030600364
2 253952 1556480 0 0 128 450911000000030600364

Merci

[mikedavem]

Ta réponse est là :

Database BDCPO has more than 1000 virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.,,,,,,,

En principe le DBCC LOGINFO doit te donner visiblement plus de 1000 lignes qui correspond à un journal des transactions relativement fragmenté (certainement à cause des nombreuses expansions du fichier journal - autogrowth)

Ce que je te conseille c'est de réduire ton journal au maximum (pendant une période creuse d'activité et ensuite de le redimensionner à une taille raisonnable d'activité (à toi de le définir - disons au moins 2 à 4Go). Ceci te permettra d'avoir un nombre de VLF beaucoup mois élevé et du coup du temps de gagné pendant les phases de restauration ou de recovery des bases de données en cas d'arrêt de celles-ci.

Après avoir effectué les actions nécessaires tu peux tester ta vitesse de restauration en effectuant à nouveau un backup et une restauration de ta base.

++

[cpofm]

Ca marche, en reduisant le fichier de log, la restauration met 1 minute au lieu de 9 !

Merci à toi

[SQLpro]

D'où l'intérêt de bien tailler ses fichiers dès le départ...

A +