Discussion :

[hmira]

Bonjour,

Comment faut-il procéder pour rétablir à l'identique, et de manière automatique, le nombre de VLF de la base tempdb après un redémarrage de l'instance SQL Server ?

Imaginons le scénario suivant :
Le fichier log de la base tempdb fait 16 Go, redimensionné manuellement par pallier de 4 Go, (exemple 64 Mo puis 4 Go d'accroissement à chaque étape), soit au total 68 VLF (68 VLF = 4 VLF + ( (16 Go/4) * 16 VLF ) ) (1)

(1) : il s'agit de l'algorithme applicable jusqu'à SQL Server 2012 inclus. Pour SQL Server 2014 et supérieur l'algorithme a changé, mais le problème soulevé reste le même !

Selon ce scénario, nous avons des fichiers VLF de taille moyenne chacun de 240 Mo. On est bien dans le domaine du raisonnable, c.à.d. dans la zone verte.

Au redémarrage de l'instance, la base tempdb est recréée avec seulement 16 VLF, (soit 16 fichiers VLF de taille moyenne chacun de 1024 Mo), et on perd le paramétrage préalablement défini ci-dessus, (soit 68 fichiers VLF d'une taille moyenne chacun de 240 Mo). En effet, SQL Server ne permet pas aux administrateurs de définir le nombre de VLF pour la base tempdb au démarrage de l'instance.

Remarque :
D'après mon analyse entre 512 Mo et jusqu'à 8 Go pour le fichier log, c'est moins problématique parce qu'après un redémarrage, même si on perd le paramétrage et on repart sur 16 fichiers VLF, on reste dans une zone verte c.à.d la taille du fichier VLF individuel variera entre 32 Mo et et 512 Mo. On est bien dans la zone raisonnable, ce que moi j'appelle la zone verte.

En revanche pour les gros fichiers log dont la taille peut excéder plusieurs centaines de Go, je pense que cela peut être problématique de repartir sur 16 VLF après redémarrage (?)
Imaginez par exemple un fichier de log de 400 Go doté de seulement 16 VLF soit des fichiers VLF de taille moyenne de 25 Go chacun ! Cette configuration ne deviendrait-elle pas problématique ? j'ai de sérieux doutes (?).

Donc je reviens à ma question initiale : "Comment faut-il procéder pour rétablir à l'identique, et de manière automatique, le nombre de VLF de la base tempdb, après un redémarrage de l'instance SQL Server ?"


Merci pour vos réponses éclairées.

A+

[rudib]

Bonjour,

A priori, je ne vois qu'un script. Par exemple, tu crées un script qui redimensionne plusieurs fois le log de tempdb, et tu le mets dans un travail de l'agent SQL planifié pour s'exécuter au démarrage (c'est une option de planification disponible).

Je ne pense pas que ça te donne une garantie de l'exact nombre de VLF, mais tu t'approches, et je ne verrais pas de raison de vouloir retrouver le nombre exact de VLF.

[hmira]

Bonjour Rudi Bruchez

Et Merci beaucoup pour cette réponse ingénieuse.

Oui, effectivement, tu as raison, le but premier n'est pas de retrouver l'exact nombre des VLF, mais du moins de s'en approcher le plus possible et de retrouver un paramétrage presque similaire au paramétrage initial.

Tu as raison aussi concernant cette option de planification, de viens de vérifier, il existe une option de "schedule type" qui permet de lancer une tâche planifiée au démarrage de l'Agent SQL Server, mais si j'ai bien compris d'après l'intitulé de cette option, il s'agit à priori du démarrage de l'Agent SQL Server et non pas du démarrage de l'instance SQL server (?). Bon il faut que je fasse des tests grandeur nature et je te dirais ce qu'il en est.

Merci.

A+

[rudib]

ça revient pratiquement au même, parce que redémarrer le service SQL Server entraîner le redémarrage du service de l'agent SQL

[hmira]

Oui, mais on peut redémarrer l'Agent sans redémarrer l'Instance.

Et, c'est bien ce que je craignais, je viens de faire le test et le script est exécuté à chaque démarrage ou redémarrage de l'Agent SQL Server, et ce, même si l'Instance ne redémarre pas, ce qui est bien conforme à l'intitulé et à la définition de cette option.

Même si je rajoute une technique permettant de détecter ou distinguer le redémarrage ou non récent de l'instance lors de démarrage de l'Agent SQL Server, cela me parait présenter de réels risques. En effet, redimensionner le fichier log de tempdb, est une affaire souvent délicate dès lors que le Serveur est fortement sollicité etc..

J'ai gardé ton idée ingénieuse mais en utilisant une procédure stockée topée pour être exécutée au démarrage de l'instance et uniquement au démarrage de l'instance. J'ai donc finalement regroupé le script dans une procédure stockée nommée dbo.RetablirVLF puis marqué la dite procédure pour être exécutée automatiquement au démarrage de l'instance.

Code SQL :

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

1
2
3
4
5
 
EXEC sp_procoption 
 @ProcName = 'dbo.RetablirVLF' 
 , @OptionName = 'startup' 
 , @OptionValue = 'on' ;

Merci Rudi Bruchez pour ton aide,

A+

[SQLpro]

Vous devriez mettre un temps de latence important dans cette procédure (au moins 5 secondes) car rien ne dit que la base tempdb sera opérationnelle et créée dès le démarrage de l'instance, les objets comme la tempdb se construisant au fur et à mesure et en particulier cela peut durer assez longtemps si vous avez dimensionné la tempdb de façon importante...
Regardez donc dans le journal d'événement de SQL Server a quel moment il voit la tempdb... (Starting up database 'tempdb'.)

A +