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
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
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
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
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
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 *************************
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 *************************
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 *************************
>> 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
>> 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
>> 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
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.
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.
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 !
>
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 !
>
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 !
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
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
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
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.
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.
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.
"Fred BROUARD" wrote in message
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" <brouardf@club-internet.fr> wrote in message
news:e3MAqK7gKHA.5380@TK2MSFTNGP06.phx.gbl...
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" wrote in message
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