Comment diminuer des logfile avec SQL Enterprise Manager
2 réponses
Bernard Jallas
Nous utilisons un logiciel du commerce qui s'appuie sur=20
une base SQL Server
Contrairement aux indications de la documentation du=20
logiciel, nous constatons que le fichiers LOG grossissent=20
de fa=E7on incontrolable : (400 fois les fichiers DATA)par=20
exemple pour une BD avec des DATA de 15 Mo le fichier LOG=20
associ=E9 va occuper 2 Go
A la c=E9ation nous avons autoris=E9 la croissance=20
automatique des fichiers sans limite (si ce n'est celle=20
du disque)
Le probl=E8me est le suivant :
- Comment r=E9duire la taille des fichiers LOG, sachant que=20
les commandes de troncature et de compression de BD de=20
SQL Enterprise Manager n'ont aucun effet (mauvaise=20
utilisation ou mauvaise proc=E9dure ?) ?
- Apr=E8s avoir r=E9duit la taille des fichiers, puis fix=E9=20
une taille maximale que se passe-t-il quand cette taille=20
est atteinte :
+ le plus ancien enregistrement est =E9cras=E9 par le=20
nouveau ?
+ il y a une erreur et la gestion de ce cas est du=20
ressort du cr=E9ateur du logiciel ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
bruno reiter [MVP]
Pour réduire la taille du journal de transaction, il faut réduire d'abord le contenu du fichier. La seule commande réduisant le contenu est la sauvegarde : BACKUP LOG mabase TO backupunit
On pourra ensuite peut-etre réduire la taille du fichier avec une instruction DBCC SHRINKDATABASE ou DBCC SHRINKFILE
Voir ci-dessous les liens dans la KB
version 7.0 http://support.microsoft.com/default.aspx?scid=kb;[LN];Q256650
version 2000 http://support.microsoft.com/default.aspx?scid=kb;en-us;q272318
br
"Bernard Jallas" wrote in message news:1a11701c44e00$db6cbe80$ Nous utilisons un logiciel du commerce qui s'appuie sur une base SQL Server
Contrairement aux indications de la documentation du logiciel, nous constatons que le fichiers LOG grossissent de façon incontrolable : (400 fois les fichiers DATA)par exemple pour une BD avec des DATA de 15 Mo le fichier LOG associé va occuper 2 Go
A la céation nous avons autorisé la croissance automatique des fichiers sans limite (si ce n'est celle du disque)
Le problème est le suivant :
- Comment réduire la taille des fichiers LOG, sachant que les commandes de troncature et de compression de BD de SQL Enterprise Manager n'ont aucun effet (mauvaise utilisation ou mauvaise procédure ?) ? - Après avoir réduit la taille des fichiers, puis fixé une taille maximale que se passe-t-il quand cette taille est atteinte : + le plus ancien enregistrement est écrasé par le nouveau ? + il y a une erreur et la gestion de ce cas est du ressort du créateur du logiciel ?
Merci pour les informations
Bernard jallas
Pour réduire la taille du journal de transaction,
il faut réduire d'abord le contenu du fichier.
La seule commande réduisant le contenu est la sauvegarde :
BACKUP LOG mabase TO backupunit
On pourra ensuite peut-etre réduire la taille du fichier
avec une instruction DBCC SHRINKDATABASE
ou DBCC SHRINKFILE
Voir ci-dessous les liens dans la KB
version 7.0
http://support.microsoft.com/default.aspx?scid=kb;[LN];Q256650
version 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;q272318
br
"Bernard Jallas" <anonymous@discussions.microsoft.com> wrote in message
news:1a11701c44e00$db6cbe80$a501280a@phx.gbl...
Nous utilisons un logiciel du commerce qui s'appuie sur
une base SQL Server
Contrairement aux indications de la documentation du
logiciel, nous constatons que le fichiers LOG grossissent
de façon incontrolable : (400 fois les fichiers DATA)par
exemple pour une BD avec des DATA de 15 Mo le fichier LOG
associé va occuper 2 Go
A la céation nous avons autorisé la croissance
automatique des fichiers sans limite (si ce n'est celle
du disque)
Le problème est le suivant :
- Comment réduire la taille des fichiers LOG, sachant que
les commandes de troncature et de compression de BD de
SQL Enterprise Manager n'ont aucun effet (mauvaise
utilisation ou mauvaise procédure ?) ?
- Après avoir réduit la taille des fichiers, puis fixé
une taille maximale que se passe-t-il quand cette taille
est atteinte :
+ le plus ancien enregistrement est écrasé par le
nouveau ?
+ il y a une erreur et la gestion de ce cas est du
ressort du créateur du logiciel ?
Pour réduire la taille du journal de transaction, il faut réduire d'abord le contenu du fichier. La seule commande réduisant le contenu est la sauvegarde : BACKUP LOG mabase TO backupunit
On pourra ensuite peut-etre réduire la taille du fichier avec une instruction DBCC SHRINKDATABASE ou DBCC SHRINKFILE
Voir ci-dessous les liens dans la KB
version 7.0 http://support.microsoft.com/default.aspx?scid=kb;[LN];Q256650
version 2000 http://support.microsoft.com/default.aspx?scid=kb;en-us;q272318
br
"Bernard Jallas" wrote in message news:1a11701c44e00$db6cbe80$ Nous utilisons un logiciel du commerce qui s'appuie sur une base SQL Server
Contrairement aux indications de la documentation du logiciel, nous constatons que le fichiers LOG grossissent de façon incontrolable : (400 fois les fichiers DATA)par exemple pour une BD avec des DATA de 15 Mo le fichier LOG associé va occuper 2 Go
A la céation nous avons autorisé la croissance automatique des fichiers sans limite (si ce n'est celle du disque)
Le problème est le suivant :
- Comment réduire la taille des fichiers LOG, sachant que les commandes de troncature et de compression de BD de SQL Enterprise Manager n'ont aucun effet (mauvaise utilisation ou mauvaise procédure ?) ? - Après avoir réduit la taille des fichiers, puis fixé une taille maximale que se passe-t-il quand cette taille est atteinte : + le plus ancien enregistrement est écrasé par le nouveau ? + il y a une erreur et la gestion de ce cas est du ressort du créateur du logiciel ?
Merci pour les informations
Bernard jallas
Fred BROUARD
Bonjour,
C'est une question plus que récurente puisque venant au moins 3 fois par moi.
Sans doute auriez vous perdu moins de temps en lisant le forum qu'en postant.
maintenant pourquoi ce comportement ? Tout simplement par sécurité.
En effet les différentes sauvegardes : data ou log permettent de récupérer une base corrompue. Tant que ces fichiers ne sont pas tronqués, la récupération est en principe toujours possible. C'est pourquoi tant que la sauvegarde data et log n'a pas eut lieu, il n'est pas possible de tronquer les fichiers.
La morale de cette histoire : formez vous à SQL server ! les formations "standard" MS compte 5 jours en dev et 5 jours en Admin. Il m'arrive de les donner assez fréquemment et même des cours spécifiques. Et bien sachez qu'en 5 jours, il est difficile de tout voir...
Ce n'est pas parce que SQL Server possède une belle interface graphique que ce n'est pas un outil puissant donc complexe.
Une formation est INDISPENSABLE et fait gagner BEAUCOUP de temps.
Pour ma part je me délecte à intervenir en audit, conseil et caetera sur des applis, souveent développées par des personnes mal formées. Après mon couteux passage, le refrain est toujours le même : "ha si on avait sût... ha si on nous avait dit..."
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Bernard Jallas a écrit:
Nous utilisons un logiciel du commerce qui s'appuie sur une base SQL Server
Contrairement aux indications de la documentation du logiciel, nous constatons que le fichiers LOG grossissent de façon incontrolable : (400 fois les fichiers DATA)par exemple pour une BD avec des DATA de 15 Mo le fichier LOG associé va occuper 2 Go
A la céation nous avons autorisé la croissance automatique des fichiers sans limite (si ce n'est celle du disque)
Le problème est le suivant :
- Comment réduire la taille des fichiers LOG, sachant que les commandes de troncature et de compression de BD de SQL Enterprise Manager n'ont aucun effet (mauvaise utilisation ou mauvaise procédure ?) ? - Après avoir réduit la taille des fichiers, puis fixé une taille maximale que se passe-t-il quand cette taille est atteinte : + le plus ancien enregistrement est écrasé par le nouveau ? + il y a une erreur et la gestion de ce cas est du ressort du créateur du logiciel ?
Merci pour les informations
Bernard jallas
Bonjour,
C'est une question plus que récurente puisque venant au moins 3 fois par moi.
Sans doute auriez vous perdu moins de temps en lisant le forum qu'en postant.
maintenant pourquoi ce comportement ?
Tout simplement par sécurité.
En effet les différentes sauvegardes : data ou log permettent de récupérer une base corrompue.
Tant que ces fichiers ne sont pas tronqués, la récupération est en principe toujours possible.
C'est pourquoi tant que la sauvegarde data et log n'a pas eut lieu, il n'est pas possible de tronquer les fichiers.
La morale de cette histoire : formez vous à SQL server !
les formations "standard" MS compte 5 jours en dev et 5 jours en Admin.
Il m'arrive de les donner assez fréquemment et même des cours spécifiques.
Et bien sachez qu'en 5 jours, il est difficile de tout voir...
Ce n'est pas parce que SQL Server possède une belle interface graphique que ce n'est pas un outil puissant donc complexe.
Une formation est INDISPENSABLE et fait gagner BEAUCOUP de temps.
Pour ma part je me délecte à intervenir en audit, conseil et caetera sur des applis, souveent développées par des
personnes mal formées.
Après mon couteux passage, le refrain est toujours le même : "ha si on avait sût... ha si on nous avait dit..."
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Bernard Jallas a écrit:
Nous utilisons un logiciel du commerce qui s'appuie sur
une base SQL Server
Contrairement aux indications de la documentation du
logiciel, nous constatons que le fichiers LOG grossissent
de façon incontrolable : (400 fois les fichiers DATA)par
exemple pour une BD avec des DATA de 15 Mo le fichier LOG
associé va occuper 2 Go
A la céation nous avons autorisé la croissance
automatique des fichiers sans limite (si ce n'est celle
du disque)
Le problème est le suivant :
- Comment réduire la taille des fichiers LOG, sachant que
les commandes de troncature et de compression de BD de
SQL Enterprise Manager n'ont aucun effet (mauvaise
utilisation ou mauvaise procédure ?) ?
- Après avoir réduit la taille des fichiers, puis fixé
une taille maximale que se passe-t-il quand cette taille
est atteinte :
+ le plus ancien enregistrement est écrasé par le
nouveau ?
+ il y a une erreur et la gestion de ce cas est du
ressort du créateur du logiciel ?
C'est une question plus que récurente puisque venant au moins 3 fois par moi.
Sans doute auriez vous perdu moins de temps en lisant le forum qu'en postant.
maintenant pourquoi ce comportement ? Tout simplement par sécurité.
En effet les différentes sauvegardes : data ou log permettent de récupérer une base corrompue. Tant que ces fichiers ne sont pas tronqués, la récupération est en principe toujours possible. C'est pourquoi tant que la sauvegarde data et log n'a pas eut lieu, il n'est pas possible de tronquer les fichiers.
La morale de cette histoire : formez vous à SQL server ! les formations "standard" MS compte 5 jours en dev et 5 jours en Admin. Il m'arrive de les donner assez fréquemment et même des cours spécifiques. Et bien sachez qu'en 5 jours, il est difficile de tout voir...
Ce n'est pas parce que SQL Server possède une belle interface graphique que ce n'est pas un outil puissant donc complexe.
Une formation est INDISPENSABLE et fait gagner BEAUCOUP de temps.
Pour ma part je me délecte à intervenir en audit, conseil et caetera sur des applis, souveent développées par des personnes mal formées. Après mon couteux passage, le refrain est toujours le même : "ha si on avait sût... ha si on nous avait dit..."
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Bernard Jallas a écrit:
Nous utilisons un logiciel du commerce qui s'appuie sur une base SQL Server
Contrairement aux indications de la documentation du logiciel, nous constatons que le fichiers LOG grossissent de façon incontrolable : (400 fois les fichiers DATA)par exemple pour une BD avec des DATA de 15 Mo le fichier LOG associé va occuper 2 Go
A la céation nous avons autorisé la croissance automatique des fichiers sans limite (si ce n'est celle du disque)
Le problème est le suivant :
- Comment réduire la taille des fichiers LOG, sachant que les commandes de troncature et de compression de BD de SQL Enterprise Manager n'ont aucun effet (mauvaise utilisation ou mauvaise procédure ?) ? - Après avoir réduit la taille des fichiers, puis fixé une taille maximale que se passe-t-il quand cette taille est atteinte : + le plus ancien enregistrement est écrasé par le nouveau ? + il y a une erreur et la gestion de ce cas est du ressort du créateur du logiciel ?
