fichiers de log [Résolu]

[ldiaz]

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

[dbaffaleuf]

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

[Oishiiii]

Bonjour dbaffaleuf,

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

[dbaffaleuf]

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

[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.

[Oishiiii]

Merci dbaffaleuf

[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.

[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

[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.

[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

[mikedavem]

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

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.

++