SQL Server trés lent

Version imprimable

17/10/2003, 09h30
arwen

[Résolu] SQL Server trés lent

Bonjour,

sur un XP Pro (portable), j'ai SQL Server 2000 installé.
Il y a quelques mois de ça il marchait trés bien et aprés j'ai pas utilisé le portable pendant un moment.
Aujourd'hui, SQL est trés trés lent. Il me prend au moins 2 à 3 min pour chaque action : ouvrir une base de données, ouvrir les tables ...

Des fois, j'ai l'impression qu'il plante mais non en fait, il est trés lent !! :(

Au niveau ressources, il n'y a pas de problèmes, il n'y a pas d'autres grosses applications qui tournent sur le portable.

Quelqu'un a t il une idée du problème ??

Merci !!
17/10/2003, 13h11
Fabien Celaia

As-tu laisse ta base en auto-agrandisement ? As-tu un segment de log distinct ? tronques-tu le log ?
17/10/2003, 13h46
arwen

Je crois que la base est en auto aggrandissement (c'est difficile à vérifier, il prend 20 ans pour afficher n'importe quoi que ce soit une table, les propriétés, les diagrammes et tout ...).

J'ai essayé de regarder dans le journal d'erreur, il y a une base qui démarre tout le temps (toutes les 20s) : est ce normal ?
17/10/2003, 17h17
WOLO Laurent

Peux-tu au moins connaître les noms de tes fichiers log et data de ta base sql ?
20/10/2003, 10h02
arwen

salut,

euh, ... c'est quoi connaitre pour toi ?
il y a bien un fichier log et Data dans Data du Program Files.
Le Log est beaucoup plus gros que le Data ! c'est normal ?
20/10/2003, 14h05
WOLO Laurent

Citation:

Envoyé par ARWEN

salut,
euh, ... c'est quoi connaitre pour toi ?
il y a bien un fichier log et Data dans Data du Program Files.
Le Log est beaucoup plus gros que le Data ! c'est normal ?

Normalement non !
il te faut tronquer le log file.
C'est pour celà que je t'ai demandé les nom de tes fichier data et log.
20/10/2003, 14h51
bono

fichier log

bonojour
je suis ce debat de près , je voudrais justement savoir comment trunquer un fichier LOG d'une BD

merci de votre réponse
20/10/2003, 15h04
arwen

Bonjour,

moi trés bête !! :fou:

Je ne sais absolument pas comment on tronque ce fichier là ! :piou:

Si tu pouvais me dire comment on fait ou bien où il faut chercher !

Merci !! :hola:

J'allais plutot dire qu'il faut compacter au lieu de tronquer.

Code:

1
2
3
4
5
 
DBCC SHRINKFILE  (MonLogFil_log,MaTaille)
--MonLogFil8log est le nom logique du fichier
--MaTaille est la taille du fichier en  mega.C'est un integer.
--La taille que vous désirez avoir.

21/10/2003, 14h19
arwen

bon, j'ai compacté ma base de données dont le fichier log était un peu gros et j'ai viré une autre base qui ne servait pas mais qui apparaissait dans le journal d'erreur tout le temps. Le serveur la relançait à chaque fois sans que je sache trop pourquoi.

ça a l'air mieux ! il est beaucoup plus rapide là !
Je le surveille 2 ou 3 jours et si ça reste comme ça c'est parfait.

Cela dit, quelqu'un sait pourquoi certains fichiers log sont bizarrement trés gros ?

Merci pour tout !! :D
21/10/2003, 15h50
WOLO Laurent

Citation:

Envoyé par arwen

bon, j'ai compacté ma base de données dont le fichier log était un peu gros et j'ai viré une autre base qui ne servait pas mais qui apparaissait dans le journal d'erreur tout le temps. Le serveur la relançait à chaque fois sans que je sache trop pourquoi.

ça a l'air mieux ! il est beaucoup plus rapide là !
Je le surveille 2 ou 3 jours et si ça reste comme ça c'est parfait.

Cela dit, quelqu'un sait pourquoi certains fichiers log sont bizarrement trés gros ?

Merci pour tout !! :D

L'une des grandes causes est du au faut que le fichier log est configuré en agrandissement automatique.
06/11/2003, 08h13
arwen

Bonjour,

j'ai presque le même problème et j'arrive pas à réduire les fichiers log car il me dit :

Code:

Impossible de réduire le fichier journal 2 (test_Log) car tous les fichiers journaux logiques sont utilisés.

j'ai essayé de sauvegarder le journal des transactions puis de l'effacer mais je peux pas.

C'est vrai que la base était en croissance automatique. J'ai enlevé ça mais je peux pas fixer de limites (c'est grisé).
Pourtant j'ai d'autres bases toujours en croissance automatique qui n'ont pas ces problèmes de fichier journal volumineux. Fut ce normal ?
Je comprends plus !!

Help ! :piou:
06/11/2003, 09h14
WOLO Laurent

Et ton espace disque restant ?
L'espace occupé par tes fichiers log et ldf, mdf sont -ils dans le rapport de 1/3 d'espace disponnible ?
06/11/2003, 11h28
arwen

Les fichiers mdf et ldf font respectivement 6720 Ko et 18688 Ko, sachant qu'il n'y a pas énormément de données dessus.
Et j'ai encore 3,08 Go sur le disque.
La taille du journal de transactions est limitée à 19 Mo. Quand je l'augmente et que je rééssaie de réduire avec DBCC SHRINKFILE, il repasse à 19 Mo et j'ai le même message.

Bonsoir,

J'ai eu ce problème il y a quelques jours.
Vas voir le sujet : ''MaBase_Log.ldf est trop volumineux'' dans le forum.
La procédure suivante réduit la taille physique du journal des transactions ie ton fameux fichier log :

Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Use Tabase Go dbcc shrinkfile(TaBase_log) // ton fichier journal transac. dbcc shrinkfile(TaBase_log) dbcc shrinkfile(TaBase_log) dbcc shrinkfile(TaBase_log) dbcc shrinkfile(TaBase_log) dbcc shrinkfile(TaBase_log) dbcc shrinkfile(TaBase_log) dbcc shrinkfile(TaBase_log) dbcc shrinkfile(TaBase_log) dbcc shrinkfile(TaBase_log) dbcc shrinkfile(TaBase_log) dbcc shrinkfile(TaBase_log) dbcc shrinkfile(TaBase_log) backup log Tabase with truncate_only Go

Je répète plus de 12 fois la même commande pour déplacer les journaux virtuels vers le début du fichier. (Remercierment à Thomad pour l'information :ccool: )

J'ai testé sur ma base de production, aucun soucis.

euh ... je suis peut-être bête mais ça a pas l'air de marcher !
le fichier log est toujours aussi gros (c'est bien lui qu'il faut regarder ?) !
J'ai suivi la procédure et lancé DBCC Shrinkfile 12 fois voire même 3 x 12 fois et j'ai toujours l'erreur
Code:

1 2 Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur du système. Impossible de réduire le fichier journal 2 (test_Log) car tous les fichiers journaux logiques sont utilisés.
je pourrais faire comme Fractal blue c'est-à-dire recréer la base, limiter la taille et importer les données mais est ce qu'il est possible d'importer aussi des diagrammes et des procédures stockées (ça je crois que oui) ?
C'est un peu fastidieux quand même !

07/11/2003, 08h53
TrollMaster

pour tronquer essaye avant DBCC shrink

CHECKPOINT

puis

BACKUP TRANSACTION <base> WITH NO_LOG

puis DBCC Shrink ...

pour plus d'explications reporte toi à la oc en ligne au niveau de la rubrique journal de transaction
07/11/2003, 11h27
arwen

OUI !

C'est bon ! Maitenant le fichier log fait plus qu' 1 Mo.

C'est au poil !

Merci !!! :D

ça fait quoi les deux instructions ?
07/11/2003, 14h45
TrollMaster

Je tiens à préciser que le fichier journal n'est pas un log classique mais enregistre toutes vos transactions sur la base et LA SEULE façon de vider un log de son contenu est de le sauvegarder.

Il faut absolument avoir au minimum une stratégie de sauvegarde des données qui resemble à celle-ci :

Effectuez une sauvegarde complète de votre base de données le matin dans une unité de sauvegarde de votre choix.

BACKUP DATABASE <BASE> TO <UNITE>

Puis après la sauvegarde, sauvegardez le journal de transaction dans une unité de sauvegarde en initialisant l'unitée de sauvegarde du journal
avec l'option WITH INIT ce qui l'initialise l'unité.

BACKUP TRANSACTION <BASE> TO <UNITE> WITH INIT

Toutes les 15 minutes vous sauvegardez votre journal de transaction dans une unité de sauvegarde du journal avec l'option WITH NO_INIT ce qui n'initialise pas l'unité et permet de stocker toutes les sauvegardes du log dans le même fichier.

BACKUP TRANSACTION <BASE> TO <UNITE> WITH NO_INIT

Le lendemain matin on recommence le cycle.

A QUOI CA SERT

Eh bien vous ne remplissez jamais votre log de transaction de façon excessive puisqu'il se vide seulement par l'opération de sauvegarde.

Mais le plus important n'est pas là. Si vous sauvegardez votre base le matin et par malheur votre base est HS à 16 h 00. Il faut restaurer. Eh bien avec cette stratégie il vous est possible de récupérer toutes les informations de la base à condition d'avoir séparé le fichier JOURNAL et DATA sur 2 disques différents et que les 2 disques ne tombent pas en panne en même temps. Sinon on ne pourra récupérer les données que jusqu'à la dernière sauvegarde du journal.

En effet, vous restaurez la sauvegarde complète tout en conservant l'option permettre de "rejouer des journaux de transaction" active. Puis il vous suffit d'aller rechercher dans l'unité de sauvegarde du journal toutes les sauvegardes du journal de transaction et les rejouer.

Vous allez me dire il manque les dernières transactions si il existe un décalage entre la dernière sauvegarde du journal et le plantage. Toutefois, si vos données sont plantées mais que le disque hébergeant votre journal est ok effectuez une sauvegarde des dernières transactions

BACKUP TRANSACTION <BASE> TO <UNITE>

et rejouez cette sauvegarde à la suite des autres.

LE JOURNAL DE TRANSACTION FAIT PARTIE INTEGRANTE DE LA STRATEGIE DE SAUVEGARDE SQLSERVER

Au même titre que les REDO LOG d'ORACLE.