Discussion :

[janlouk]

Bonjour à tous,

Je ne me suis jamais retrouvé dans une telle situation, avoir 2 fichiers .ldf dans une DB. Ils se trouvent sur 2 disques différent.

Il y en a un qui fait 472 GB et lui "bouge", mais l'autre je n'ai pas l'impression car il fait 20 GB pil poil. L'autogrowth est unrestricted tous les deux.

Je sais que c'est le cas pour les fichiers data. Mais pour les LOG, si j'empêche un de grandir (le plus gros car le disque est full), est-ce que l'autre va être automatiquement utilisé?

Ce n'est qu'une situation temporaire, le temps d'avoir l'accord d'agrandir le disque, de l'agrandir... Je voudrais ne plus avoir les messages comme quoi le disque est full.

Merci
Jean-Luc

[SQLpro]

Il utilise successivement l'un puis l'autre. Si le premier est verrouillé à 20 Go il faut d'abord lui permettre de grandir :
1) voir le max_size
2) voir le FILEGROWTH
Ensuite, fixer le second.

M'est avis que 450 Go sur un JT c'est beaucoup... Trop sans doute !

Quelles est la taille des données de la base ?

Un tel fichier ne peut se concevoir que si la base est une VLDB d'au moins 1,4 To...

A +

[Invité]

Question subsidiaire : quelle est le mode de recouvrement de cette bd ?
Question bonus : Si c'est FULL, est-ce qu'une stratégie de sauvegarde régulière du JT est en place ?

[janlouk]

Question subsidiaire : quelle est le mode de recouvrement de cette bd ?
Question bonus : Si c'est FULL, est-ce qu'une stratégie de sauvegarde régulière du JT est en place ?

C'est du full avec un backup des log toutes les 2 heures.

Merci pour ces questions, c'est parfois par le plus simple qu'on ne pense pas. Je vais voir pour augmenter la fréquence des backup log, ça règlera déjà un soucis de l'espace.

[janlouk]

Bonjour Frédéric,

J'ai fait une petite erreur, le fichier de 472 Go est en illimité pour le MAX_SIZE. Le fichier de 20 GB est limité à 100 GB.
Pour la croissance, c'est par 1024 MB.

La taille de tous les fichiers DATA totalise 7.5 TB.

Je pencherais pour supprimer le fichier de 20 GB se trouvant sur un disque (où il y a des fichiers de data), augmenter le disque prévu que pour les LOG où se trouve le gros log de 472 GB.

Je fais bien?

PS : il n'y quand même aucun intérêt à créer plusieurs .LDF, si?

[SQLpro]

Bonjour Frédéric,

J'ai fait une petite erreur, le fichier de 472 Go est en illimité pour le MAX_SIZE. Le fichier de 20 GB est limité à 100 GB.
Pour la croissance, c'est par 1024 MB.

La taille de tous les fichiers DATA totalise 7.5 TB.

Je pencherais pour supprimer le fichier de 20 GB se trouvant sur un disque (où il y a des fichiers de data), augmenter le disque prévu que pour les LOG où se trouve le gros log de 472 GB.

Je fais bien?

PS : il n'y quand même aucun intérêt à créer plusieurs .LDF, si?

500 Go de JT pour 7,5 To, c'est très correct. Personnellement je donnerais même un peu de mou à ce journal en allant vers les 750 Go...
Un pas de croissance de 1 Go c'est quand même beaucoup... S'agit-il de disques SSD ?

Oui tu fais bien.

L'intérêt d'avoir plusieurs fichier est limité, mais peu servir en secours, justement quand un des disque est saturé !

A +

[janlouk]

Un pas de croissance de 1 Go c'est quand même beaucoup... S'agit-il de disques SSD ?

Je ne sais pas pour les disques, je devrais voir avec l'équipe Storage.

1 Go c'est beaucoup? Je pensais qu'il fallait minimiser le nombre de VLF, et donc le nombre de fois où le fichier augmente de taille. C'est pour ça que je mets 1 Go.

[SQLpro]

En principe l'autogrowth devrait être exceptionnel. Tu ne devrais jamais en avoir. Donc, le système va allouer des VLF en fonction de la taille dynamique du JT (nouveau depuis 2014)
https://www.sqlskills.com/blogs/paul...l-server-2014/

A +

[hmira]

Je ne sais pas pour les disques, je devrais voir avec l'équipe Storage.

1 Go c'est beaucoup? Je pensais qu'il fallait minimiser le nombre de VLF, et donc le nombre de fois où le fichier augmente de taille. C'est pour ça que je mets 1 Go.

Bonjour,
1 Go pour l'autogrow, me parait personnellement une valeur correcte.
Sachant que comme l'a rappelé SQLPro "autogrowth devrait être une opération exceptionnelle".
Cependant, la création initiale du fichier log doit être effectuée par pallier (généralement par pallier de 1 Go à 6 Go par grow, voire jusqu'à 8 Go par grow), et ce, pour éviter d'avoir des fichier VLF de très grandes tailles.
La taille des fichiers individuels VLF, lorsqu'elle est excessive, peut avoir un impact négatif sur les performances.
Personnellement, j'essaie, autant que possible, de faire en sorte que, lors d'un autogrow (ou d'un grow), la taille de chacun des fichiers individuels VLF créé, soit comprise entre 64 Mo et 512 Mo (maximum). J'essaie donc de ne jamais dépasser 512 Mo comme taille de chacun des fichiers individuels VLF créé après un autogrow (ou d'un grow).
Je me suis amusé à répertorier dans un tableau Excel (voir image ci-dessous) quelques exemple de valeurs d'autogrow (ou de grow) combinés à la taille individuelle des fichier VLF et du nombres de fichiers VLF générés.
Personnellement, (et cela n'engage que moi !), j'essaie de rester dans le vert foncé (entre 64 Mo et 256 Mo), à la limite, dans la zone vert clair (entre 256 Mo et 512 Mo), mais jamais au delà.



A+