Discussion :

[ghilo]

Bonjour a tous;
J'ai une base de donnée qui est dans un PC et je voulais faire une copoie d'elle pour la sauvegarder vers un autre PC et quand je fait une sauvegarde j'ai eu un fichier .BAK qui pese environ 100 MO, j'ai pris ce fichier et je l'es réstaurer dans un autre mico, quand j'ai lancer la réstauration un msg m'appraitre et me dise que je n'est pas assi de l'éspace pour réstaurer ma base outre j'ai 2 GO comme espace libre dans mon lécteur!! Le problème c'est que le fichier .bak il réstaure un autre fichier de journal et ce dérnier éffectivement il pese a lui seul 2GO , comment je peut vider ce fichier LOG Aider moi SVP
bien a vous

[elsuket]

Bonjour,

Quelle instruction utilisez-vous pour restaurer votre base de données ?

Sinon c'est un peu barbare, mais vous pouvez tout simplement supprimer la base de données avant de la restaurer ...

@++

[ghilo]

Salut elsuket
j'ai deux PC dont le premier il ya une base de donnée que je veut la copier dans le deuxieme PC que je vient d'installer SQL SERVER, alors j'ai sauvegarder la base dans le premier PC et pour cela j'ai cliquer avec le boutton droit dans le nom de la base puis "Sauvegarder" une boite de dialogue s'ouvre alors et j'ai laisser tous par défault et j'ai eu un fichier .bak je l'ai pris et je lé mis dans le répertoire Backup du deuxieme PC apres j'ai créer une base vide et j'ai cliquer avec le boutton droit puis "tache" puis sur réstaurer la base, mais l'éspace disque qu'elle veut la réstauration est tres volumineuse 2go c'est trop non ??!!!
alors comment pourais-je vider le journale qui fait savegarde toutes les transactions
merci a vous

[pcaboche]

Quelle est la taille du journal des transactions sur la base d'origine ? Il y a-t-il beaucoup d'espace libre dans ce journal des transactions ? (auquel cas, penser à faire un shrink)

Sinon, quelques pistes pour le transfert de la base :
- faire un backup "Copy only"
- pour la base de destination, mettre le Recovery Model à "Simple" le temps de la restauration afin d'éviter la création de logs volumineux
- bien vérifier les options de backup/restauration

Sinon:
- copier le fichier .mdf sur le serveur de destination et faire un "Attach Database"

[ghilo]

Bonjour pcaboche;
la taille du journal des transactions sur la base d'origine est a 2GO
c'est quoi un shrink ?
Excuser moi mais j'ai pas compris comment faire un backup "Copy only"
voulez-vous m'éclaircir comment je doit procéder pour que je puisse vider le journal de transaction ?

Merci et bien a vous

[pcaboche]

la taille du journal des transactions sur la base d'origine est a 2GO

Avec un peu de chance, peut-être que seule une petite partie de ces 2 Go sont réellement utilisés.

À un moment la taille du journal des transactions a atteint 2 Go. Par la suite (ex: après un backup ou un checkpoint) de l'espace a peut-être été libéré dans le journal des transactions mais cet espace n'est pas restitué au système d'exploitation (SQL Server le garde pour réécrire dedans), d'où la nécessité de faire un "shrink".

c'est quoi un shrink ?

Ca permet de libérer l'espace non utilisé dans un fichier (data ou log).

Pour ce faire:
- Sur la base, faire un click droit
- Sélectionner Tasks > Shrink > Files
- Dans "File Type", sélectionner "Log"

Note: dans "Available free space", on voit l'espace non utilisé (mais réservé par SQL Server)

- Sélectionner "Reorganize pages before releasing unused space"
- Mettre "Shrink file to" à la valeur minimum
- Appuyer sur "OK"

Excuser moi mais j'ai pas compris comment faire un backup "Copy only"

Dans les options de backup, il faut sélectionner "Copy only Backup".

Un backup "Copy only" ne modifie pas la séquence de backup (c'est très important de comprendre ce que cela implique au niveau de la restoration si on est sur une base en production).

Plus de détails ici: Copy-Only Backups.

[elsuket]

de l'espace a peut-être été libéré dans le journal des transactions mais cet espace n'est pas restitué au système d'exploitation (SQL Server le garde pour réécrire dedans), d'où la nécessité de faire un "shrink".

La nécessité dans ce cas-là oui : il faut réserver les rétrécissements de bases de données aux manœuvres désespérées par manque d'espace disque.
En effet, l'allocation d'espace supplémentaire pour tout fichier de base de données est bien plus lent qu'une écriture en RAM.

Le journal de transactions est logiquement subdivisé en journaux virtuels qui sont utilisés tour à tour par le moteur de base de données, donc l'espace alloué au fichier du journal des transactions est constamment réutilisé.

En faisant donc rétrécir une base de données, vous demandez au moteur de base de données de restituer l'espace disque qu'il s'est échiné à se réserver, et qu'il reprendra tôt ou tard, surtout s'il s'agit du fichier du journal des transactions. A chaque fois qu'il devra reprendre de l'espace disque, le traitement en cours qui a provoqué l'agrandissement du fichier sera en attente, et bloquera probablement aussi d'autres tâches
Sachant que les écritures disque sont au moins mille fois moins rapides qu'une écriture en RAM, je vous laisse imaginer les dégâts que cela peut produire sur une base de production.

Il est donc primordial de bien tailler les fichiers de base de données à la création de cette dernière, et après avoir choisi le mode de restauration qui convient au métier, de choisir une stratégie de sauvegarde qui permettra de conserver une taille constante du fichier du journal des transactions tout au long de la vie de la base de données.

@++

[WOLO Laurent]

Bon pour te sortir de cette situation,
1-Détache ta base de donnée
2-Fait une copie de ta base de données sur le serveur de destination
3-Supprime le fichier journal
4-Rattache la nouvelle base de données

Retiends que le problème de grossissement du journal des transactions est lié à une mauvaise politique de sauvegarde !
Il faut y penser car c'est elle qui supprime la partie inactive du journal.