Discussion :

[vince2005]

Bonjour,

J'ai un petit problème technique sur ma base de données sql server 2008. Je viens de m'apercevoir que ma log était de 72Go (idf), alors que ma base de données ne fait que 82Mo (mdf).

Pour essayer de solutionner mon problème, j'ai d'abord fait un SHRINKFILE afin de réduire ma log à 100Mo, mais sans succès, je suis encore 68 Go.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
use toto
go
DBCC SHRINKFILE ( toto_Log,100 )
go

Comment puis je faire pour réduire la taille de ma log, car elle commence à devenir volumineuse sur mon disque.

Au niveau du paramétrage du fichier log, le paramétrage est le suivant : ou pièce jointe.

Comment puis je faire pour limiter la casse ? puis je faire un truncate only et comment ?

Merci pour votre aide.

[ATMorphine]

Bonsoir
Il y a de forte chance pour que ce "problème" vienne du mode de récupération (recovery model) de la base de données. Elle doit surement être en FULL, c'est à dire que toutes les transactions sont logué dans le fichier de log jusqu'à la réalisation d'un backup de log de cette base ce qui à pour conséquence de vider le journal de log de toutes les transactions commités (validés).

Dans votre cas :

• Soit vous n'avez pas de politique de backup de log et donc vous pouvez changer le mode de recovery de la base en SIMPLE par la commande suivante :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  ALTER DATABASE [Mabase] SET RECOVERY SIMPLE

  ce qui à pour conséquence, de logguer seulement les transactions en cours, nécessaire en cas de crash serveur lors du redémarrage.
• Soit, il faut instaurer une politique de backup de log (avec des backups FULL aussi )

Peu importe le choix que vous faites, il faudra réaliser au moins 1 fois le shrink du fichier de log. Ensuite, normalement le fichier de log prendra une taille au fil du temps qui variera très peu.

[vince2005]

en plus, j'ai lancé la sauvegarde de la LOG et cette dernière est interminable.
Je précise que j'ai arrêté l'agent sql server, afin qu'un plan de maintenance ne démarre pas en même temps que je réalise ma sauvegarde.
Ais je bien fait ? Comment arrêter le backup s'en mettre en péril la base. Le fichier toto.trn est toujours à 0.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
BACKUP LOG toto TO DISK = 'C:\Bakcup\toto.trn'
go

La solution idéale serait de mettre en place une politique de sauvegarde. Mais comment puis je m'y prendre ?

Merci pour vos réponses.

[ATMorphine]

Alors pour répondre à l'urgence, il est possible de passer la base en recovery simple, shrinker le fichier de log, remettre la base en full, faire un backup full et laisser la stratégie de backup full et de backup log reprendre leurs vies.

Pour définir une politique de sauvegarde, il faut savoir répondre à :

• Quelle est la taille de chacune des bases de données
• Quel est le volume des modifications de données
• Combien de temps la base de données peut-elle rester indisponible
• La perte de modifications est-elle cruciale
• Est-il facile de recréer les données perdues
• Qu'elles sont les périodes importantes d'utilisation de la base de données
• La base subit-elle des surcharges de travail ponctuelles pendant lesquelles il n'est pas envisageable de lancer une sauvegarde
• Les sauvegardes sont-elles conservées de façon cyclique (la nouvelle => suppression ancienne)
• Le serveur SQL est-il dans un environnement multiserveur avec une administration centralisée
• La rétention que l'on souhaite (ex : avoir une version de base de données d'il y a une 2 semaine, il faudra un backup full d'il y a 2 semaines ou plus),
• Le temps qu'on a pour faire les backups, car il est quand même préférable de faire ça en période de faible activité,

[vince2005]

Ma sauvegarde s'est bien terminé, bien qu'elle est pris un peu de temps.

J'ai d'ailleurs regarder l'espace utilisé pour chacune des bases :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 
dbcc sqlperf(logspace)
go
 
Database Name	Log Size (MB)	Log Space Used (%)	Status
master	1,242188	37,73585	0
tempdb	4,554688	51,80103	0
model	82,42969	98,67311	0
msdb	16,17969	39,06326	0
FRP_COMMON_toto	56,30469	91,24549	0
FRP_COMMUNICATION_toto	68134,99	0,6876593	0
FRP_TRESORERIE_toto	407,7422	3,782501	0

On voit que le model est presque à 100%.

D'autre part, bien que FRP_COMMUNICATION_toto ne prenne que 1% de l'espace utilisé, mon fichier FRP_COMMUNICATION_tot. idf est toujours à 66Go. Comment puis je faire pour le diminuer.

Voici les réponses à la politique de sauvegarde :

•Quelle est la taille de chacune des bases de données :
FRP_COMMON_toto 51Mo de DATA + 57 Mo de LOG
FRP_COMMUNICATION_toto 83 Mo de DATA + 66Go de LOG
FRP_TRESORERIE_toto 20 Mo de DATA + 408 Mo de LOG

•Quel est le volume des modifications de données : ca n'a pas l'air très volumineux

•Combien de temps la base de données peut-elle rester indisponible : Elle peut rester indisponible jusqu'à une demi journée, voir une journée.
•La perte de modifications est-elle cruciale : oui
•Est-il facile de recréer les données perdues : un peu compliqué, mais possible.
•Qu'elles sont les périodes importantes d'utilisation de la base de données : entre 08h00 et 17h00 - jours ouvrés
•La base subit-elle des surcharges de travail ponctuelles pendant lesquelles il n'est pas envisageable de lancer une sauvegarde : non
•Les sauvegardes sont-elles conservées de façon cyclique (la nouvelle => suppression ancienne) : oui, on sauvegarde tous les soirs et toutes les sauvegardes glissantes sur 5 semaines.
•Le serveur SQL est-il dans un environnement multiserveur avec une administration centralisée : centralisé
•La rétention que l'on souhaite (ex : avoir une version de base de données d'il y a une 2 semaine, il faudra un backup full d'il y a 2 semaines ou plus),
•Le temps qu'on a pour faire les backups, car il est quand même préférable de faire ça en période de faible activité : entre 18h00 et 08h00 du matin.

Merci pour votre aide.

En attendant à part de passer en base simple, comment puis je faire pour diminuer la taille du fichier idf. S'il n'y a un autre moyen, quelq'un peut il me donner les étapes, pour passer en mode simple, puis revenir de nouveau en version actuelle. Comment paramétrer la croissance automatique ?

[SQLpro]

1) tant que votre base est en mode de récupération (RECOVERY MODEL) FULL ou BULK LOGGED (complet ou journalisé en bloc) alors le fichier de sauvegarde empile les transactions, même si elles sont achevées depuis longtemps
ATTENTION : Le journal va donc grossir éternellement durant toute la vie de la base.
2) pour purger le journal de transaction vous devez impérativement faire une sauvegarde régulière dudit journal. Au moins une fois par jour, mais une stratégie plus intelligente consiste à la faire à une cadence plus rapide, par exemple toutes les heures, les dix minutes...
ATTENTION : une purge ne réduite pas la taille des fichiers. par exemple si vous purgez votre radiateur celui-ci ne se dégonfle pas !
3) pour réduire la taille d'un fichier (opération à ne faire que de manière très exceptionnelle !) il faut utiliser la commande DBCC SHRINKFILE...

A +