Discussion :

[StringBuilder]

Bonjour,

J'ai une question stupide...

J'ai une base de données configurée en Recovery Mode = Full.

Hier après-midi, j'ai lancé des traitements assez lourds. Ça a généré plusieurs centaines de Mo de logs (près de 1 Go).
Normal.

Ensuite, pendant la nuit, j'ai un script qui recalcul / rebuild les index pollués, et met à jour les statistiques des tables.
Et là, surprise, j'ai de nouveau des logs qui se sont générés, à peu de chose près la même taille (près de 1 Go).

Un rebuild d'index génère des logs de transaction ? Pour quelle raison ? Idem pour les statistiques.

[aieeeuuuuu]

Bonjour,

Les indexes, mêmes secondaires, sont des pages de données et font partie intégrante de la base de données. Lorsque qu'un index est reconstruit, ces pages de données sont modifiées, ce qui occupe effectivement de la place dans le journal des transactions, comme n'importe quelle commande modifiant l'état de la base.

Pour les statistiques en revanche, je ne sais pas qu'il est est, mais j'imagine que le fonctionnement reste le même, puisqu'elle font elles aussi partie de la BDD. cependant, le volume reste faible, donc l'impact ne doit pas être très important.

[StringBuilder]

Ok

Vu que le contenu d'un index ne change pas le contenu d'une table, je ne pensais pas que ces modifications étaient consignées dans le journal.

C'est les admins système qui vont être contents, je suis en train de leur pourrir le serveur de sauvegarde (1 log de 1 Go toutes les 10 minutes depuis ce matin gnark gnark gnark… sans oublier les index cette nuit… si ça refait comme hier soir la somme de tous les logs de la journée, ils vont pas être contents )

[aieeeuuuuu]

est-ce que le rebuild est fait en ligne ou hors ligne ?


Sinon, en spécifiant une reconstruction utilisant la tempDB (SORT_IN_TEMPDB = ON), cela réduira l'impact sur le TLog de la base utilisateur.

[StringBuilder]

En ligne.
Le script lance un simple REBUILD sans option complémentaire.

Pour la TEMPDB, vu qu'elle est partagée entre toutes les bases, et que le script lance le rebuild des index de toutes les bases en même temps... je suis pas certain que tous les faire bosser dans TEMPDB soit la meilleure solution

[SQLpro]

Pour les statistiques en revanche, je ne sais pas qu'il est est, mais j'imagine que le fonctionnement reste le même, puisqu'elle font elles aussi partie de la BDD. cependant, le volume reste faible, donc l'impact ne doit pas être très important.

Les stats sont incluses dans les pages d'index.... Donc journalisées de même !

A +

[SQLpro]

Vu que le contenu d'un index ne change pas le contenu d'une table, je ne pensais pas que ces modifications étaient consignées dans le journal.

SQL Server journalise TOUT ce qui change l'état de la base : structure comme données :
Commandes CREATE, ALTER, DROP, INSERT, UPDATE, DELETE, MERGE, TRUNCATE, GRANT, REVOKE....

Même une commande d'ajout de fichier à une base est journalisée.

En mode BULK LOADED ou SIMPLE, seules les opérations reproductibles ne sont pas journalisées ;

• CREATE / ALTER / REBUILD INDEX
• SELECT ... INTO ...
• BULK INSERT...

A +

[SQLpro]

est-ce que le rebuild est fait en ligne ou hors ligne ?


Sinon, en spécifiant une reconstruction utilisant la tempDB (SORT_IN_TEMPDB = ON), cela réduira l'impact sur le TLog de la base utilisateur.

Aucune influence sur la journalisation. C'est juste pour éviter d'utiliser trop de cache (donc on ne le fait qu'en pleine production sur un index de plusieurs Go).

A +