Version imprimable
bonjour amis
j'ai une application avec une base données sous sql server 2005 installé
sur une partition C DE 30 GO.
maintenant je remarque que le fichier log des transction a atteint 20 go
.donc réellement il me reste que quelque MO sur la partition C.
j'ai utilisé shink file de fichier mis sans résultats ni en ligne de commande ni en sql server manager.
aidez moi svp ?
cordialement
Je pense que votre log est plein, vous devez simplement effectuer une sauvegarde du log à l'aide de l'Enterprise Manager, ensuite la commande DBCC Shrinkfile devrait fonctionner.
resalut mon ami
peux tu etre plus explicite ?
sauvegarde pour ?
et comment ?
idem pour shrinkfile?
aidez moi
stp ?
je te remercie d'avance
j'ajoute ke je suis sur sql server 2005
et que je ve réduction au minum de la taille de fichier log ?
MERCI
Tu peux faire un back up log with truncate_only si tu n'as pas l'utilité de la sauvegarde du fichier de log.
BACKUP LOG { database_name | @database_name_var }
WITH { NO_LOG | TRUNCATE_ONLY }
reference : http://msdn.microsoft.com/en-us/library/ms186865.aspx
ensuite tu peux faire un DBCC SHRINKFILE
reference : http://technet.microsoft.com/en-us/l.../ms189493.aspx
merci
dans quel cas , je me permet de ne pas garder ce fichier ?
et pardon je suis nouveau dans l'admin d'un BD
merci pour ta collaboration .
c'est gentil de ta part
Il existe plusieurs type de sauvegarde, en principe, on effectue une sauvegarde full par jour et on sauvegarde par exemple le log tout les 3 H, ainsi si à minuit, tu sauvegarde full et qu'à 07H00, ton serveur crash, tu restaure le full plus le log de 3H00, plus le log de 6H00. tu ne perd qu'une heure! Voila à quoi sert un journal de transaction!
Par consequent, le journal de transaction contient des informations importantes qu'il faut sauvegarder pour récuperer ta base en cas de crash!
Pour repondre à ta question, si tu as effectue une sauvegarde complete aujourdhui, et que ta base est donc en securite, tu n'as pas besoin de conserver les données du journal, par consequent, tu fais un truncate_only pour dire de ne pas sauver le journal mais de le vider!
si tu preferes sauvegarder ton journal, tu fais un backup log simple comme expliquer dans le lien! Si tu sauvegarde le journal, alors il sera vider apres la sauvegarde...
pour reduire la taille du log, qui ne contient plus rien, mais qui a conserve sa taille maximal, dbcc shrinkfile
merci
j'avais dis que l'application utilise sql server 2005 comme sgbc.
cette application et cette BD est implantée sur un systéme windows 2003 server R .
je faisréguliérement la sauvegarde en utilisant la commande ntbackup ( démarrer /éxecuter ntbackup).
est ce que en éxécutant cette commande , j'ai fait implicitement la sauvergarde de toute les bases se trouvants sous sql server 2005 y compris le fichier log.
merci d'avance
NTBACKUP n'est pas une commande SQL Serveur. Par conséquent, vous devez mettre en place une sauvegarde au niveau sql serveur.
bonjour ami
je voudrais savoir si le fichier résultat de l'éxécution de la commande ntbackup (sauvegarde de toute le systéme sur lequel est installé le sql server 2005) ne contient pas une sauvegardes des base données contenus dans le le sql server 2005.
merci
Je ne connais pas la commande et j'imagine que tu dois sauvegarder les différents fichiers de tes DB (.mdf, .ndf, .ldf).
Il t'est ensuite possible de detacher ta base de donnée, recuperer ces fichiers de ton backup et ensuite réattacher ta base de donnée...
Il existe cependant la commande backup qui te permet de sauver une base de donnée précisément et ensuite la restaurer grace à la commande restore.
Pour plus d'information sur ces commande : l'aide qui est à portée de touche (F1)
salut ptit dje,
son problème, c'est qu'il est en mode de recouvrement complet et qu'il ne fait jamais de sauvegarde du log, je parle de sauvegarde sql serveur, pas de sauvegarde physique du fichier. Par consequent, son log grossit à l'infini, il n'est jamais vide!
Ah oui... En effet c'est un peu problematique.
La question est donc de savoir quelle quantité de donnée est il "acceptable" de perdre.
Si l'on peut perdre une journée, un full backup tous les soirs et un recovery model en simple convient tout à fait.
Sinon il faut mettre en place un log backup schedulé à la fréquence de "perte acceptable" (5 minutes ? 15 minutes ? 1h ? ...)