lenteur & fichier de log

[olivanto]

bonjour,

J'ai un SQLServer 8 sur du w2008, pour abriter notre comptabilité (Sage, pour ne pas le nommer).
Je précise que je ne connais RIEN à MSQLServer ; mais j'ai de bonnes bases d'Oracle cependant.

J'ai de grosses lenteur de traitement, et d'après l'éditeur de mon logiciel, cela peut venir du fichier de log. Soit.
Il parait qu'en sauvegardant la base, cela purge le dit-fichier ; j'ai dû rater une étape, car rien n'a changé après la sauvegarde, c'est toujours aussi long...

J'ai un fichier de base de données de 1.6 GO, et un fichier de log correspondant de 650Mo. (il est en "autoextend")
J'ai essayé Tâches, Réduire, Fichier, Fichier de log...et là j'ai trois options qui ne me parlent pas.
Que dois je faire pour vider complètement ce fichier ??

Par ailleurs, il existe des tables systèmes que je dois aussi purger ; il n'y a pas d'option via l'interface graphique, je vais donc faire un "delete*from" ; oui mais où se trouve la console SQL (ou ce qui en tient lieu !!)

merci,

[dbaffaleuf]

- Le pb de performance ne vient probablement pas de la taille ou de l'utilisation du journal, pas dans votre cas. Merci de poster le résultat de:

Code :

1
2
3
4
5
6
SELECT serverproperty('productversion')
GO
SELECT databasepropertyex('mabaseSAGE','recovery')
GO
dbcc sqlperf(logspace)
GO

Pour se connecter à l'instance, soit lancer Query Analyzer (si vous êtes bien en SQL Server 8, 8 = SQL Server 2000, démarrer -> executer -> isqlw). Mais n'êtes-vous pas plutôt en 2008 ? (auquel cas démarrer -> executer -> ssms).

- Ne pas toucher aux tables système. Elles ne sont pas faites pour être accédées directement en modification.

[olivanto]

oui, en effet, je suis en SQL server 2008, pardon !

alors, au risque de paraître idiot....ce code, où est la console pour l'executer ; car SSMS est une console graphique, et je ne vois nul endroit où je puisse executer du code ! (j'avais prévenu que j'y connaissais rien !)

[mikedavem]

Vous avez un bouton "Nouvelle requête" ou "New Query" en haut à gauche. Cf image jointe

++

[olivanto]

merci, je suis vraiment un boulet...

bon, les résultats...

Code :

1
2
3
4
5
6
7
8
 
 
version 10.0.1600.22
------
FULL
------
DATABASE NAME|Log Size (MB) | Log Space Used (%) | STATUS
maBaseSage       |1819.305       |92.02582                 |0

Il y a d'autres bases, pour lesquels le "log space" avoisine les 99%, mais sans problème de performance. Pour l'instant, je souhaiterai travailler sur ma base de comptabilité, quitte à ensuite appliquer ailleurs les améliorations apportées.

Que puis je faire ??

[Jinroh77]

Avez-vous un plan de maintenance concernant votre base de données ?
La réponse à la 2° instruction : "FULL" indique le mode de recovery de votre base.
Le mode FULL indique que les transactions de votre base sont enregistrées dans un journal (c'est le cas dans tous les modes) mais que en plus, ce journal accumulera toutes les transactions sans jamais se vider si on ne lui demande pas.

Le mode full, permet dans un plan de sauvegarde, d'effectuer une sauvegarde nocturne, complète et relativement longue de votre base puis d'effectuer pendant la journée, toutes les x heures, une sauvegarde de votre journal de transaction.
Ce second type de sauvegarde permettra de libérer votre journal de transactions et de conserver l'historique des transactions, que l'on pourra chercher à restaurer lors d'un crash ou d'une erreur par exemple.

A vous de voir si vous souhaitez prendre le temps de définir un véritable plan de maintenance qui s'occupera de :
- sauvegarde complète nocturne
- sauvegarde du journal de transaction en journée
- maintenance des index et statistiques
etc.

Ou si vous souhaitez simplement vider ce journal de transaction de la manière suivante :

Code :

1
2
ALTER DATABASE shrinkdemo SET RECOVERY SIMPLE
ALTER DATABASE shrinkdemo SET RECOVERY FULL

Cela passera votre base en mode de recovery SIMPLE qui consiste à ne sauvegarder que la dernière transaction, supprimant les autres donc.
Puis en repassant en mode full.

Par contre, attention, cette commande sera à executer pour ""nettoyer"" votre fichier de journal de transaction et n'est pas recommandée. Le plan de maintenance est bien meilleur.

[olivanto]

la base de données est sauvegardée tous les soirs. Rien d'autre.

Pour moi, la sécurité est plus importante que tout. Donc, je suppose que mon intérêt est de définir un plan de maintenance...

Mais du coup, j'ai des questions...

1. A quoi sert ce fichier de transaction ? Plus ou moins l'équivalent d'un Archivelogs sous Oracle ? Cela signifie que la sauvegarde doit prendre en compte les deux fichiers pour une future restauration ; comment sait-on si elle le fait ?

2. Si je décide de passer la base en SIMPLE...Le fichier log ne conserve qu'une seule transaction, donc, je suppose que le fichier de base de données est immédiatement modifiée par la mise à jour. Il n'y a donc qu'un seul fichier vraiment important à sauvegarder, ce doit être plus rapide ?

3. J'ai déja la sauvegarde de la base, en nocturne. Si j'ai bien compris, pour vider le journal de logs, il me faut faire un job pour le sauvegarder régulièrement aussi. Ais je quelque chose de particulier à faire pour cela ?

merci beaucoup de votre aide.

[Jinroh77]

Envoyé par olivanto

la base de données est sauvegardée tous les soirs. Rien d'autre.

Pour moi, la sécurité est plus importante que tout. Donc, je suppose que mon intérêt est de définir un plan de maintenance...

Mais du coup, j'ai des questions...

1. A quoi sert ce fichier de transaction ? Plus ou moins l'équivalent d'un Archivelogs sous Oracle ? Cela signifie que la sauvegarde doit prendre en compte les deux fichiers pour une future restauration ; comment sait-on si elle le fait ?

2. Si je décide de passer la base en SIMPLE...Le fichier log ne conserve qu'une seule transaction, donc, je suppose que le fichier de base de données est immédiatement modifiée par la mise à jour. Il n'y a donc qu'un seul fichier vraiment important à sauvegarder, ce doit être plus rapide ?

3. J'ai déja la sauvegarde de la base, en nocturne. Si j'ai bien compris, pour vider le journal de logs, il me faut faire un job pour le sauvegarder régulièrement aussi. Ais je quelque chose de particulier à faire pour cela ?

merci beaucoup de votre aide.

1. Oui, ce journal enregistre les transactions insert, delete, update et peut-être d'autres effectuées sur la base.
Pour restaurer à un instant précis il faut donc restaurer la sauvegarde full + toutes les sauvegardes des journaux jusqu'au moment souhaité.

2. Si vous passez en mode SIMPLE, le journal de transaction est donc vidé à chaque transaction, vous n'avez donc plus la possibilité de restaurer à un instant précis autre que celui des sauvegardes full.
Ca serrait donc une sauvegarde full toutes les x minutes, ce qui n'est pas vraiment imaginable.
la sauvegarde du journal de transactions étant beaucoup plus rapide que la complète. Il y a beaucoup moins de données dedans, surtout si vous la faites avec un intervalle limité.

3. Le plan de maintenance peut consister en quelque chose du genre :

A 1h du matin, pendant une inactivité maximale :
- maintenance des index : rebuild si il y en a peu ou re-organisation partielle ou complète
- mise à jour des statistiques (uniquement si vous faites seulement une re-organisation des index, le rebuild, mettant à jour les stats.

- DBCC CHECKDB de la base pour vérifier l'intégrité de la base (il est dommage de sauvegarde une base corrompue).

- sauvegarde complète de la base de données.

- nettoyage des sauvegardes du journal de transactions (.trn) de la journée.

Toutes les 2h par exemple :
- sauvegarde du journal de transactions.


Pour restaurer, il faut utiliser la sauvegarde complète de la nuit + les x sauvegardes du log de la journée.

[olivanto]

j'ai encore quelques questions ! (si vous voulez bien !)

1. Sur la sauvegarde ; ma sauvegarde de la nuit à 02h00 (sauvegarde dite "complete") ne me permet que de restaurer la base jusqu'à ce point ? Si je veux aller plus loin dans la journée, il faut avoir sauvegardé le fichier de transaction et le restaurer aussi ? C'est bien cela ?

2. Sauvegarde du fichier de transaction (vous dites, toutes les deux heures par exemple) ; puis je le faire n'importe quand, même s'il est en cours d'utilisation à cause de connexions clients ? Ce n'est pas bloquant ?

3. Qu'entendez vous par "nettoyage des sauvegardes du journal de transactions (.trn)" ; on parle du ficheir de log, ou bien est-ce un nouvel inconnu (pour moi) ?

merci beaucoup.

[Zabriskir]

Bonjour,

Votre machine est-elle virtuelle ?

@+

[olivanto]

non non. Un serveur dédié !

[Jinroh77]

Envoyé par olivanto

j'ai encore quelques questions ! (si vous voulez bien !)

1. Sur la sauvegarde ; ma sauvegarde de la nuit à 02h00 (sauvegarde dite "complete") ne me permet que de restaurer la base jusqu'à ce point ? Si je veux aller plus loin dans la journée, il faut avoir sauvegardé le fichier de transaction et le restaurer aussi ? C'est bien cela ?

2. Sauvegarde du fichier de transaction (vous dites, toutes les deux heures par exemple) ; puis je le faire n'importe quand, même s'il est en cours d'utilisation à cause de connexions clients ? Ce n'est pas bloquant ?

3. Qu'entendez vous par "nettoyage des sauvegardes du journal de transactions (.trn)" ; on parle du ficheir de log, ou bien est-ce un nouvel inconnu (pour moi) ?

merci beaucoup.

1. Oui, avec seulement cette sauvegarde complète, vous ne restaurez que ce qu'il y a dedans.
Si votre base est en mode SIMPLE : vous ne pouvez rien restaurer de ce qui se passe en journée après la complète.
Si vous êtes en FULL : Vous devez commencer par faire une sauvegarde du journal de transaction puis vous restaurez la complète de la nuit + celle du journal que vous venez de faire jusqu'à une date précise.

2. La sauvegarde du journal peut se faire n'importe quand. Elle nécessitera des ressources mais si elle est faites régulièrement, il y a peu de données à sauvegarder donc ne dure pas trop longtemps.
Si une transaction est en cours au moment du déclenchement de la sauvegarde, il commence à sauvegarder ce qu'il a déjà de fixe, puis dès que la transaction en cours se termine, il l'inclut dans la sauvegarde.

3. Le .trn est l'extension par défaut de la sauvegarde du fichier de journal de transactions.
Celui-ci n'étant valable que entre 2 sauvegardes complètes, il est inutile de conserver les .trn qui datent d'avant la sauvegarde complète que vous venez de faire.

[zinzineti]

Si mode = SIMPLE alors il est impossible de faire de BACKUP des journaux de transaction

[olivanto]

bon...j'ai du travail, moi

Je vous remercie tous beaucoup !!

[WOLO Laurent]

Voici pour la réduction du fichier log

Code :

1
2
3
4
backup log mabase WITH no_log
go
dbcc shrinkdatabase(mabase)
go

Merci de faire d'abord une sauvegarde complete de la base de données.