Discussion :

[eric_033]

Bonjour à tous,
Je ne connais pas grand chose à SQL Server mais mon serveur est saturé.
La base de donnée fait 15 Go le fichier log 65 Go.
Il reste 5 Go sur le disque.
J'ai essayé de réduire la taille du log via les commandes sql classique :
BACKUP LOG toto WITH TRUNCATE_ONLY
DBCC SHRINKFILE
Rien n'a faire, pas de réduction.
Je n'ai plus la place de faire une sauvegarde en local sur les disques. J'ai donc tenté la chose suivante :
- J'ai arrêter l'intance SQL via cmd dos NET STOP MSSQLSERVER
- J'ai déplacé le fichier LOG vers la racine
- J'ai redémarrer l'instance SQL via cmd dos NET START MSSQLSERVER

et là j'ai eu l'erreur : A Connection could not be established to (local)
reason timeout expired

suite à cette erreur, j'ai re-arrêter l'instance
remis le fichier LOG à sa place
re-démarrer l'instance
Et maintenant, j'ai toujours ce message.

Bien sûr, la connection marchait trés bien avant ma manipulation.

Comment puisje récupérer ce problème ?

Merci pour votre aide.

[eric_033]

L'accès est revenu, après un quart d'heure sans que je ne fasse rien.
Il ne me reste plus qu'a diminuer ce fichier log.
Je vais retenter les commandes, je vous tiens au courant

[eric_033]

C'est bon, cette fois ça marche...
Je supose que le fait d'arrêter et de redémarrer l'instance y ai pour quelque chose.
J'ai récupérer 70 Go de disque

[ZERS]

C'est bon, cette fois ça marche...
Je supose que le fait d'arrêter et de redémarrer l'instance y ai pour quelque chose.
J'ai récupérer 70 Go de disque

un conseil : si tu veux vider les logs, avant la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dump transaction...

fait la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

checkpoint

c'est pour cela qu'après le shrink, tu n'avais rien gagné

[rudib]

Pas forcément. Le journal de transaction ne peut pas se vider si une transaction est toujours ouverte. Les transactions sont stockées dans le journal séquentiellement, et la partie du journal qui peut être supprimée est celle qui comporte des transactions terminées. Si une transaction court toujours, toute la partie du journal depuis le début de cette transaction doit être maintenue, ce qui est logique en termes de consistance de données.
On peut vérifier s'il y a une transaction active avec un DBCC OPENTRAN.

[ZERS]

Pas forcément. Le journal de transaction ne peut pas se vider si une transaction est toujours ouverte. Les transactions sont stockées dans le journal séquentiellement, et la partie du journal qui peut être supprimée est celle qui comporte des transactions terminées. Si une transaction court toujours, toute la partie du journal depuis le début de cette transaction doit être maintenue, ce qui est logique en termes de consistance de données.
On peut vérifier s'il y a une transaction active avec un DBCC OPENTRAN.

tout à fait maître
Mais autant faire ce peut, on fait ce genre de maniqulations d'administration lorsque la base est disponible pour cela, à savoir quand il n'y a pas d'activité théoriquement dessus.
Pas souvent simple d'ailleurs

[rudib]

C'est l'idéal, mais parfois ta base devient indisponible parce qu'il n'y a plus d'espace disque, ou que le fichier de log ne peut plus grandir et il y a une longue transaction qui court (import de données mal fait et interminable, client bloqué, etc.). C'est dans ces situations d'urgence (il y en a toujours), qu'il faut avoir les infos nécessaires pour réagir vite