fichiers de log

Version imprimable

27/06/2011, 09h57
ldiaz

fichiers de log

SQL server 2005

Bonjour a tous,

sur une de nos serveurs, nous avons 8 bases de données.
Il existe un job qui fait le backup full chaque jour.
Le probleme que nous avons c'est que le disque C:\ se rempli de fichiers .LDF
qui sont enormes, et que je ne peux pas effacer.
J'ai lu qu'il s'agit de log de transaction... Et que il fallait faire un backup log et un shrink... Mais je comprend pas le principe, j'ai lu la doc, mais j'arrive toujours pas a degager les fichiers et c: est rempli a 100%.
Que puis je faire?
Quel est la procedure?
D'avance merci

Lorsqu'on modifie des données dans une base SQL Server, cette modification est journalisée dans un fichier (le journal de transactions, le fichier LDF). Ça permet plusieurs choses, la première de fournir la possibilité d'annuler la modification en question, la seconde de pouvoir rejouer ces modifications lorsqu'un problème survient et qu'il faut remonter un jeu de sauvegardes.

Par défaut, toutes les informations journalisées restent dans le fichier LDF. La seule façon de les faire sortir est effectivement de les sauvegarder.

Maintenant, si ces fichiers journaux sont vraiment énormes, rien ne sert de sauvegarder des transactions qui sont vieilles de plusieurs mois. Donc la manoeuvre est la suivante pour chaque base. Sous SQL Server Management Studio, ouvrir une fenêtre d'exécution 'Nouvelle requête':
Code:

1 2 3 4 5 6 7 ALTER DATABASE <base1> SET RECOVERY SIMPLE GO SELECT NAME FROM base1.sys.database_files where type_desc='LOG' GO -- Pour chaque nom 'logname' renvoyé , normalement il ne devrait y en avoir qu'un seul par base mais ne sait-on jamais: DBCC SHRINKFILE('<logname>','TRUNCATEONLY') GO
Ensuite, il faut te poser la question suivante: combien de données je suis prêt à perdre pour chacune de ces bases ?
- 1 journée (ou plus) de modifications => laisser la base en mode SIMPLE, le recyclage des transactions se fera automatiquement. Cela suppose que tu aies un backup complet qui s'exécute au moins 1 fois par jour.
- 2 heures, 4 heures, ou je ne peux pas me permettre de perdre une seule minute de modifications dans ma base, alors il faut repasser en mode COMPLET:
Code:

1 2 ALTER DATABASE <base1> SET RECOVERY FULL GO
Et relancer une sauvegarde complète derrière, puis planifier ensuite des sauvegardes transactionnelles à intervalles réguliers pour recycler l'espace dans le journal et éviter qu'il ne se remplisse à nouveau.

Et un dernier truc: il vaut mieux ne pas laisser les fichiers de données et les journaux sur le C: . Il faut allouer un ou plusieurs disques dédiés à SQL Server et déplacer ces fichier dessus.

cf :
http://blog.capdata.fr/index.php/mod...ons-episode-1/
http://blog.capdata.fr/index.php/mod...ions-episode-2

27/06/2011, 11h51
Oishiiii

Bonjour dbaffaleuf,

Citation:

Envoyé par dbaffaleuf

Et un dernier truc: il vaut mieux ne pas laisser les fichiers de données et les journaux sur le C: . Il faut allouer un ou plusieurs disques dédiés à SQL Server et déplacer ces fichier dessus.

Quelle est la procédure pour déplacer ces fichiers ?

J'ai une base en production qui stocke ses fichiers (données + journal de transaction) sur le même disque.
Je souhaite déplacer le journal de transaction sur un autre disque.

Est-ce qu'il est possible de déplacer ce fichier sans interrompre l'activité ? Est-il nécessaire de détacher la base ?

Merci ;)

Une base ne peut pas être en ligne sans journal de transactions, donc oui il faudra passer les bases hors-ligne / en ligne les unes derrière les autres. Procédure pour une base base1, connecté avec un compte sysadmin. Pour obtenir le nom logique du journal par base, utiliser la requête précédente sur base1.sys.database_files. Il ne faut pas d'utilisateur connecté à la base pendant l'opération:
Code:

1 2 3 4 5 6 7 alter database base1 modify file (name='<nomlogiquelog', filename='nouveaulecteur:\nouveauchemin\nomfichierbase1.ldf') go alter database base1 set offline go -- -> déplacer le fichier LDF sous le nouveau chemin alter database base1 set online go

27/06/2011, 12h25
ldiaz

Salut a tous.
Ok je vois la procedure.
Apres ça je devrais plus avoir rien dans C:\ n'est ce pas?
Je veux, apres un autre backup (tous mes scripts pointent vers l'unité S:\)

Je vais essayer et faire l'update de ces post.
Merci a tous.
27/06/2011, 13h50
Oishiiii

Merci dbaffaleuf :ccool:
28/06/2011, 08h56
WOLO Laurent

Je vous rappelle qu'il faut marqué vos postes du tag [Résolu], cela évite que quelqu'un l'ouvre dans l'intention de le résoudre. ou que quelqu'un qui a un problème du même genre s'en serve dans le future.
28/06/2011, 09h14
ldiaz

Bonjour a tous,
upsss le post n'est pas encore fermé, c'est pour ça que j'avais pas cliqué sur "resolu".

Donc premier point, le workaround pour bouger les fichier LDF marche genial, merci !!!
Par contre hier j'ai eu un doute.
J'ai 8 bases au total.
Le test je l'ai fait sur une toute petite base (qui sert de test).
La pas de soucis.
Lorsque j'ai voulu le faire sur une base plus grande (4G) j'ai dû arreter car la commande OFFLINE tardait beaucoup. J'ai attendu 45 mn avant d'arreter la commande. La base etait inaccesible, mais le alter ne terminait pas.
Donc mon doute est: Est normal que ça tarde tellement?
Faut il faire autre chose avant pour que le OFFLINE soit plus rapide?

Si des users sont connectés la base ne se ferme pas?
D'avance merci
28/06/2011, 10h06
WOLO Laurent

La durée d'attente est dépendante du nombre de transaction encours. Il est recommandé de faire des travaux de maintenance en fin de journée.
28/06/2011, 10h11
ldiaz

ok
donc je vais arreter les services avant de faire l'alter.
Cette fois c'est ok, sachant que la procedure d'hier a bien marcher.
Merci a tous et bonne semaine !!!

Ciao
28/06/2011, 10h40
mikedavem
Citation:

Lorsque j'ai voulu le faire sur une base plus grande (4G) j'ai dû arreter car la commande OFFLINE tardait beaucoup. J'ai attendu 45 mn avant d'arreter la commande. La base etait inaccesible, mais le alter ne terminait pas.
Donc mon doute est: Est normal que ça tarde tellement?
Faut il faire autre chose avant pour que le OFFLINE soit plus rapide?

Si vous avez des utilisateurs connectés à votre base il faudra attendre que ceux-ci soient déconnectés et que les transactions en cours se terminent.

Vous pouvez forcer votre déconnexion en utilisation la commande :
Code:

1 2 ALTER DATABASE <maBase> SET OFFLINE WITH ROLLBACK IMMEDIATE
Citation:

donc je vais arreter les services avant de faire l'alter.

Procédure à effectuer qu'en cas d'extrême nécessité. L'arrêt brutal du serveur via les services ne vous garantira pas d'avoir une base de données intègre lorsque vous allez redémarrer votre instance par la suite. Utilisez plutôt les commandes à votre disposition pour effectuer cette opération.

++