Taille du Transaction log

Le
bob123
Bonjour,

J'ai un SQL Server dont la taille du tansaction log est de 50GB
les bases sont en recovery model: full .
Comment faire pour qu'il reste vers 500MB-1GB
Merci d'avance
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Patrice
Le #20755761
Et le journal est déjà sauvé fréquemment ?

Voir par exemple :
http://msdn.microsoft.com/fr-fr/library/ms190217.aspx si nécessaire pour une
explication du mode "full".

--
Patrice

"bob123" news:4b23b3c8$0$11553$
Bonjour,

J'ai un SQL Server dont la taille du tansaction log est de 50GB
les bases sont en recovery model: full .
Comment faire pour qu'il reste vers 500MB-1GB
Merci d'avance





Fred BROUARD
Le #20761181
bob123 a écrit :
Bonjour,

J'ai un SQL Server dont la taille du tansaction log est de 50GB
les bases sont en recovery model: full .
Comment faire pour qu'il reste vers 500MB-1GB
Merci d'avance





Les seules chose qui "purgent" le journal des transactions sopnt :
1) en mode de journalisation FULL, de faire régulièrement une sauvegarde
du journal
2) de se placer en mode de journalisation SIMPLE

Pourquoi ?

La journalisation est un filet de sauvegarde en cas d'erreur
fonctionnelle. par exemple le DELETE accidentel de toutes les lignes
d'une table.
Dans ce cas de figure il est possible par le biais de la sauvegarde du
journal de revenir à l'état de la base à un moment précis par exemple
une minute avant le DELETE litigieux.
Si cette fonction là ne vous intéresse pas, alors placez vous dans le
mode de journalisation simple
Si cette fonction vous intéresse, alors vous devez impérativement
sauvegarder régulièrement le journal de transaction.

D'autres éléments sur le sujet :
http://sqlpro.developpez.com/cours/sqlserver/log/
http://blog.developpez.com/sqlpro/p7220/langage-sql-norme/sauvegardes-avec-sql-server/

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
bob123
Le #20769511
OK merci

Les seules chose qui "purgent" le journal des transactions sopnt :
1) en mode de journalisation FULL, de faire régulièrement une sauvegarde
du journal
2) de se placer en mode de journalisation SIMPLE

Pourquoi ?

La journalisation est un filet de sauvegarde en cas d'erreur
fonctionnelle. par exemple le DELETE accidentel de toutes les lignes d'une
table.
Dans ce cas de figure il est possible par le biais de la sauvegarde du
journal de revenir à l'état de la base à un moment précis par exemple une
minute avant le DELETE litigieux.
Si cette fonction là ne vous intéresse pas, alors placez vous dans le mode
de journalisation simple
Si cette fonction vous intéresse, alors vous devez impérativement
sauvegarder régulièrement le journal de transaction.

D'autres éléments sur le sujet :
http://sqlpro.developpez.com/cours/sqlserver/log/
http://blog.developpez.com/sqlpro/p7220/langage-sql-norme/sauvegardes-avec-sql-server/

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************


wpher56
Le #20786711
>> Les seules chose qui "purgent" le journal des transactions sopnt :
1) en mode de journalisation FULL, de faire régulièrement une sauvegarde
du journal
2) de se placer en mode de journalisation SIMPLE






Non, le seul fait de se mettre en mode Simple ne purge pas le journal ! J'ai
une base de 25 GB sur laquelle ont été effectuées plusieurs dizaines de
milliers de modifications dans les tables: le log atteint 10 GB, en mode
Simple. A l'occasion, je procède à un Shrink Database qui me réduit le log à
... 1 MB.

P.
Fred BROUARD
Le #20797611
wpher56 a écrit :

Les seules chose qui "purgent" le journal des transactions sopnt :
1) en mode de journalisation FULL, de faire régulièrement une
sauvegarde du journal
2) de se placer en mode de journalisation SIMPLE






Non, le seul fait de se mettre en mode Simple ne purge pas le journal !
J'ai une base de 25 GB sur laquelle ont été effectuées plusieurs
dizaines de milliers de modifications dans les tables: le log atteint 10
GB, en mode Simple. A l'occasion, je procède à un Shrink Database qui me
réduit le log à ... 1 MB.

P.



Cela dépend de ce que vous appelez purge. Une purge n'est pas une
diminution du volume du fichier, mais un recyclage de son contenu.
Purge et réduction sont deux choses différente.
Le fait de considérer les transactions achevées comme recyclable
constitue bien une purge mais ne diminue pas la taille du JT.

Diminuer la taille du JT est une généralement aberration, car s'il a
atteint cette taille c'est qu'il en avait besoin. Donc le réduire
provoquera probablement de nouvelles opérations de croissances un jour
ou l'autre et cela est catastrophique pour les performances !

Lisez les articles que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p5859/ms-sql-server/fragmentation-physique-des-fichiers-et-t/
http://sqlpro.developpez.com/cours/sqlserver/log/

A +




--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
wpher56
Le #20818691
>
Cela dépend de ce que vous appelez purge. Une purge n'est pas une
diminution du volume du fichier, mais un recyclage de son contenu.
Purge et réduction sont deux choses différente.
Le fait de considérer les transactions achevées comme recyclable constitue
bien une purge mais ne diminue pas la taille du JT.



Merci pour cette précision. En effet, on parle de réduire la taille du
fichier log, et on mélange allègrement purge et réduction !
Le posteur original pensait, semble-t-il, à trouver une taille "idéale" pour
son JT.


Diminuer la taille du JT est une généralement aberration, car s'il a
atteint cette taille c'est qu'il en avait besoin. Donc le réduire
provoquera probablement de nouvelles opérations de croissances un jour ou
l'autre et cela est catastrophique pour les performances !




Ce qu'il faut, c'est trouver la "bonne" taille, celle qui garantirait que le
fichier journal n'a pas besoin de croître.
Plusieurs experts conseillent de réduire le JT au minimum, puis d'observer
quelle limite il atteint, noter ce résultat, répéter l'opération plusieurs
fois jusqu'à se faire une idée aussi exacte que possible de la taille.
Ensuite ne procéder à une réduction que si la taille du JT dépasse largement
cette limite.
Ceci étant, est-ce que le jeu en vaut vraiment la chandelle ?

Pierrot
Fred BROUARD
Le #20823541
wpher56 a écrit :

Cela dépend de ce que vous appelez purge. Une purge n'est pas une
diminution du volume du fichier, mais un recyclage de son contenu.
Purge et réduction sont deux choses différente.
Le fait de considérer les transactions achevées comme recyclable
constitue bien une purge mais ne diminue pas la taille du JT.



Merci pour cette précision. En effet, on parle de réduire la taille du
fichier log, et on mélange allègrement purge et réduction !
Le posteur original pensait, semble-t-il, à trouver une taille "idéale"
pour son JT.


Diminuer la taille du JT est une généralement aberration, car s'il a
atteint cette taille c'est qu'il en avait besoin. Donc le réduire
provoquera probablement de nouvelles opérations de croissances un jour
ou l'autre et cela est catastrophique pour les performances !




Ce qu'il faut, c'est trouver la "bonne" taille, celle qui garantirait
que le fichier journal n'a pas besoin de croître.
Plusieurs experts conseillent de réduire le JT au minimum, puis
d'observer quelle limite il atteint, noter ce résultat, répéter
l'opération plusieurs fois jusqu'à se faire une idée aussi exacte que
possible de la taille. Ensuite ne procéder à une réduction que si la
taille du JT dépasse largement cette limite.
Ceci étant, est-ce que le jeu en vaut vraiment la chandelle ?



OUI ! Le fin du fin étant de prévoir à l'avance les opérations qui vont
saturer le journal et passer de manière transitoire en mode de
journalisation BULK LOGGED (qui n'enregistre pas les données des
transactions rejouable comme un CREATE INDEX), voir en mode simple s'il
n'y a pas de transaction cliente, mais après avoir sauvegardé ledit JT.

D'ailleurs en SQL 2008 la commande BACKUP LOG ... WITH TRUNCATE ONLY
n'est plus opérante ce qui signifie qu'en mode non simple, il faut
impérativement sauvegarder les JT, sinon rester en simple.

A +

Pierrot




--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
wpher56
Le #20823711
"Fred BROUARD" news:
wpher56 a écrit :

Cela dépend de ce que vous appelez purge. Une purge n'est pas une
diminution du volume du fichier, mais un recyclage de son contenu.
Purge et réduction sont deux choses différente.
Le fait de considérer les transactions achevées comme recyclable
constitue bien une purge mais ne diminue pas la taille du JT.



Merci pour cette précision. En effet, on parle de réduire la taille du
fichier log, et on mélange allègrement purge et réduction !
Le posteur original pensait, semble-t-il, à trouver une taille "idéale"
pour son JT.


Diminuer la taille du JT est une généralement aberration, car s'il a
atteint cette taille c'est qu'il en avait besoin. Donc le réduire
provoquera probablement de nouvelles opérations de croissances un jour
ou l'autre et cela est catastrophique pour les performances !




Ce qu'il faut, c'est trouver la "bonne" taille, celle qui garantirait que
le fichier journal n'a pas besoin de croître.
Plusieurs experts conseillent de réduire le JT au minimum, puis
d'observer quelle limite il atteint, noter ce résultat, répéter
l'opération plusieurs fois jusqu'à se faire une idée aussi exacte que
possible de la taille. Ensuite ne procéder à une réduction que si la
taille du JT dépasse largement cette limite.
Ceci étant, est-ce que le jeu en vaut vraiment la chandelle ?



OUI ! Le fin du fin étant de prévoir à l'avance les opérations qui vont
saturer le journal et passer de manière transitoire en mode de
journalisation BULK LOGGED (qui n'enregistre pas les données des
transactions rejouable comme un CREATE INDEX), voir en mode simple s'il
n'y a pas de transaction cliente, mais après avoir sauvegardé ledit JT.

D'ailleurs en SQL 2008 la commande BACKUP LOG ... WITH TRUNCATE ONLY n'est
plus opérante ce qui signifie qu'en mode non simple, il faut
impérativement sauvegarder les JT, sinon rester en simple.




Eh bien voilà le coeur du problème !
Ma base est en mode Simple, et mon utilisateur insère plusieurs millions
d'enregistrements lors d'une action unique.
Le JT passe d'un coup de quelques MB à 10 GB, et ensuite je dois faire un
Shrink Database pour le ramener à des valeurs plus décentes.
Est-ce qu'il vaut mieux alors mettre ma base en mode Bulk Logged ?

Pierrot
Fred BROUARD
Le #20825471
wpher56 a écrit :


"Fred BROUARD" news:
wpher56 a écrit :

Cela dépend de ce que vous appelez purge. Une purge n'est pas une
diminution du volume du fichier, mais un recyclage de son contenu.
Purge et réduction sont deux choses différente.
Le fait de considérer les transactions achevées comme recyclable
constitue bien une purge mais ne diminue pas la taille du JT.



Merci pour cette précision. En effet, on parle de réduire la taille
du fichier log, et on mélange allègrement purge et réduction !
Le posteur original pensait, semble-t-il, à trouver une taille
"idéale" pour son JT.


Diminuer la taille du JT est une généralement aberration, car s'il a
atteint cette taille c'est qu'il en avait besoin. Donc le réduire
provoquera probablement de nouvelles opérations de croissances un
jour ou l'autre et cela est catastrophique pour les performances !




Ce qu'il faut, c'est trouver la "bonne" taille, celle qui garantirait
que le fichier journal n'a pas besoin de croître.
Plusieurs experts conseillent de réduire le JT au minimum, puis
d'observer quelle limite il atteint, noter ce résultat, répéter
l'opération plusieurs fois jusqu'à se faire une idée aussi exacte que
possible de la taille. Ensuite ne procéder à une réduction que si la
taille du JT dépasse largement cette limite.
Ceci étant, est-ce que le jeu en vaut vraiment la chandelle ?



OUI ! Le fin du fin étant de prévoir à l'avance les opérations qui
vont saturer le journal et passer de manière transitoire en mode de
journalisation BULK LOGGED (qui n'enregistre pas les données des
transactions rejouable comme un CREATE INDEX), voir en mode simple
s'il n'y a pas de transaction cliente, mais après avoir sauvegardé
ledit JT.

D'ailleurs en SQL 2008 la commande BACKUP LOG ... WITH TRUNCATE ONLY
n'est plus opérante ce qui signifie qu'en mode non simple, il faut
impérativement sauvegarder les JT, sinon rester en simple.




Eh bien voilà le coeur du problème !
Ma base est en mode Simple, et mon utilisateur insère plusieurs millions
d'enregistrements lors d'une action unique.
Le JT passe d'un coup de quelques MB à 10 GB, et ensuite je dois faire
un Shrink Database pour le ramener à des valeurs plus décentes.
Est-ce qu'il vaut mieux alors mettre ma base en mode Bulk Logged ?

Pierrot



Cela ne résoudra rien. Mais je ne pense pas que faire une transaction
unique sur des millions de lignes soit réellement intelligent.
Il vaudrait mieux saucissonner l'insertion en plusieurs étapes et faire
un CHECKPOINT entre chaque étape. Le fin du fin est d'utiliser BULK
INSERT avec une taille de lot de 64 Ko par exemple.


A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Publicité
Poster une réponse
Anonyme