Réduction de la taille du journal des transactions impossible

Bonjour à tous,

J'essaye depuis quelques jours maintenant de réduire la taille de mon fichier journal des transactions qui pèse plus de 20 Go et ne cesse de grossir au point d'avoir du le déplacer sur un autre disque dur de plus grosse capacités.

Mais le problème est toujours entier, et le fichier ne cesse de grandir.

Ma base de données s’appelle CHARACTER_01_DBF, je suis sous MSSQL 2005.

J'ai bien tenter les procédure suivantes :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

BACKUP LOG CHARACTER_01_DBF WITH TRUNCATE_ONLY   CHECKPOINT   BACKUP LOG CHARACTER_01_DBF WITH TRUNCATE_ONLY   DBCC SHRINKFILE (2)   -- Si echec on retente...   CHECKPOINT   BACKUP LOG CHARACTER_01_DBF WITH TRUNCATE_ONLY   DBCC SHRINKFILE (2)

---

Mais cela n'a rien changer.

Cette croissance impressionnante à fais suite à un problème sur la base de données donc j'ai du utiliser un mode de récupération pour la débloquer (Je n'ai plus le nom exacte en tête).

Merci d'avance à tout ceux qui pourrons m'aider.

Commencer par nous donner le résultat de la commande DBCC OPENTRAN dans le contexte de la base incriminée.

A +

Alors,

Après avoir exécuter la commande j'ai cette réponse :

Citation:

---

No active open transactions.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

---

Il n'y a donc pas de transaction ancienne qui végète et empêcherait de réduire le JT.

Exécutez une syntaxe plus claire de votre réduction. Exemple :

Code:

---

DBCC SHRINKFILE (NomFichierLogiqueJT, 1);

---

Si cela ne donne rien voyez s'il y a des transaction au niveau d'isolation SNAPSHOT.

Dans le pire des cas, vous faites sortir tout le monde sauf vous et ré-exécutez la commande.

Code:

---

1 2 3 4 5 6 7

USE ??? GO ALTER DATABASE ??? SET SINGLE USER WITH ROLLBACK IMMEDIATE; GO DBCC SHRINKFILE (NomFichierLogiqueJT, 1); GO

---

A +

Alors, je viens d'exécuter la première commande :

Citation:

---

Cannot shrink log file 2 (LOGGING_01_DBF_log) because all logical log files are in use.

(1*ligne(s) affectée(s))
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

---

Ensuite avec la seconde commande :

Citation:

---

Msg*156, Niveau*15, État*1, Ligne*2
Incorrect syntax near the keyword 'USER'.
Msg*319, Niveau*15, État*1, Ligne*2
Incorrect syntax near the keyword 'with'. If this statement is a common table expression or an xmlnamespaces clause, the previous statement must be terminated with a semicolon.
Msg*102, Niveau*15, État*1, Ligne*2
Incorrect syntax near 'IMMEDIATE'.
Cannot shrink log file 2 (LOGGING_01_DBF_log) because all logical log files are in use.

(1*ligne(s) affectée(s))
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

---

Code:

---

1 2 3 4 5 6

USE ??? GO ALTER DATABASE ??? SET SINGLE_USER WITH ROLLBACK IMMEDIATE; GO DBCC SHRINKFILE (NomFichierLogiqueJT, 1);

---

Après il faudra la mettre en multi user....

A +

Alors cette fois ci la commande donne :

Citation:

---

Nonqualified transactions are being rolled back. Estimated rollback completion: 100%.
Cannot shrink log file 2 (LOGGING_01_DBF_log) because all logical log files are in use.

(1*ligne(s) affectée(s))
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

---

Pour repasser la base de données j'exécute la commande :

Code:

---

1 2 3 4

USE LOGGING_01_DBF GO ALTER DATABASE LOGGING_01_DBF SET MULTI_USER WITH ROLLBACK IMMEDIATE;

---

Avec ce message en retour :

Citation:

---

Msg*924, Niveau*14, État*1, Ligne*1
Database 'LOGGING_01_DBF' is already open and can only have one user at a time.
Msg*1205, Niveau*13, État*68, Ligne*1
Transaction (Process ID 78) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
Msg*5069, Niveau*16, État*1, Ligne*1
ALTER DATABASE statement failed.

---

Code:

---

1 2 3 4

USE LOGGING_01_DBF GO ALTER DATABASE LOGGING_01_DBF SET MULTI_USER ;

---

Apparemment vous avez des verrous très bloquants !
Il serait bon d'y jeter un coup d’œil.... Je me demande aussi si vous n'avez pas un JT au taquet (plein ou qui ne peut plus s'étendre).

Quels sont les événements critiques du journal SQL Server ?

A +

J'ai réussit à passer la base de données en multi utilisateur en arrêtant complètement le serveur et en le redémarrant.

Pour ce qui est des évènements critiques je n'en vois pas ou alors je ne regarde pas au bon endroits :

->Mon Instance\Gestion\Journaux SQL Server

La seul le Moniteur d'activité est disponible, les Archives ne s'ouvre pas.
Le journal des transactions est définis comme suit :
Croissance automatique
Par 10% - croissance illimitée.

La taille initiale est définis à 22*141 Mo, et il n'est pas possible de la réduire.

http://img15.hostingpics.net/pics/270175Sanstitre.jpg

Vous ne pouvez pas réduire un JT en dessous de sa valeur fixe (en fait c'est possible en théorie, si ce fichier n'est pas le fichier principal).

Comme vous avez définit une taille de 22*141 Mo il n'est pas possible de descendre en dessous.

Le reste est de savoir si vous avez assez de place dedans pour vos transactions.

lancez la commande

Code:

---

DBCC SQLPERF (LOGSPACE)

---

cela vous permettra de vérifier le taux d'occupation
Si vous voulez récupérer de la place DANS le journal, il faut le sauvegarder.
Si vous n'avez plus assez de place dedans, il faut ajouter un nouveau fichier sur un autre disque si le disque actuel est saturé.

A +

Alors visiblement les journaux de transactions occupent au maximum 94 % de la taille maximale.

http://img15.hostingpics.net/pics/417469Sanstitre.jpg

Quel est votre mode de journalisation ? Simple, Full ?

De toute façon il va falloir rajouter du journal à votre base avant de pouvoir faire quoi que ce soit.

Avez vous de la place sur vos disques ?
Pouvez vous étendre la taille du JT actuel ?
Pouvez vous rajouter un second fichier de JT à la base ?

A +

Alors, toutes les bases sont en mode de récupération Simple

Sur le disque dur contenant les fichiers des bases de données il y à ~25 Go d'espace libre.

Je viens d'essayer de passer de 22*699 Mo à 22 700 Mo, la modification à bien été prise en compte.

Je peux ajouter un second fichiers de journal de transactions je l'ai nommer: LOGGING_01_DBF_log2 il fais une taille de 2 Mo.

Il est donc normal que vous ne puissiez pas sauvegarder les journaux de transaction. En mode simple ils sont en auto troncature.

Ce mode n'est d'ailleurs généralement pas bon pour une base de production, car en cas de problème vous ne pourrez pas récupérer 100% de vos données. En principe pour une base OLTP vous devriez être en mode FULL.

Chaque fois que vous augmentez la taille du JT, il sera impossible de revenir en arrière. En l'ayant taillé à 22 700 Mo soit 23 Go, il sera impossible de le réduire à une taille en dessous...

Je me demande ce que vous cherchez à faire !

Je pense qu'il est fortement souhaitable que vous assistiez à un cours d’administration de MS SQL Server... En effet, vos lacunes sont si importante que vous courrez au devant du danger... en faisant des manips auxquelles vous n'êtes visiblement pas formé et sans comprendre ce que vous faites, ni les enjeux futurs !

Soit vous faites intervenir un professionnel pour régler vos problèmes, soit vous vous formez sérieusement par le biais d'une formation professionnelle. On acquiert pas les compétences d'un DBA en lisant quelques bricoles à droite à gauche sur le net...
À lire : http://fr.wikipedia.org/wiki/Adminis...e_donn%C3%A9es
Formation admin SQL Server : http://www.orsys.fr/formation-sql-se...nistration.asp

A +

Il est vrai que je n'ai que très peu de connaissance ni même d'expérience dans l'administration des base de données, la base de données est utiliser pour stocker les informations d'un jeu en ligne.

Maintenant une dernière question, es qu'il est possible d'arrêter la base de données, créer un autre fichier de log, supprimer le premier fichier de log afin de le réinitialiser en quelque sorte.

Une fois les fichiers exécutable du jeu stopper, il n'y a plus d’interaction avec la base de données et elle est sauvegarder automatiquement tous les jours.

Merci pour les liens que vous m'avez communiquer je vais m'y intéresser de près pour ne plus avoir de problème par la suite.

Non, si vous faites cela vous allez flinguer votre base définitivement.

En effet, arrêter le service SQL Server comme le serveur est une opération d'urgence qui ne "finalise" pas les bases.
Lors du redémarrage, SQL Server relit le journal de transaction pour savoir ou il en est de ses transaction et effectue les dernières mises à jour qui ont été journalisées mais pas stockées.

En supprimant le journal vous flinguerirez toute la base.

Dans un SGBDR comme SQL Server ou Oracle, toute les opérations se font à chaud et à par des commandes interne au SGBDR, même en ce qui concerne la manipulation des fichiers....

Je me demande si vous ne seriez pas piraté par des connexions externes parasites, genre DOS, ce qui empêcherait effectivement certaines opérations de maintenance.
Avez-vous mis un mot de passe à tout vos compte de connexion ?

A +

Le serveur de jeu est effectivement très exposer aux attaques de type DOS car la population visée sont les 12 - 22 ans qui pour une raison ou une autre ne sont pas content et veulent bloquer l'accès au service.

Donc pour les comptes j'en ai que l'utilisateur "sa" d'actif et protéger par un mot de passe.

Citation:

---

Envoyé par Meutledaron

Le serveur de jeu est effectivement très exposer aux attaques de type DOS car la population visée sont les 12 - 22 ans qui pour une raison ou une autre ne sont pas content et veulent bloquer l'accès au service.

Donc pour les comptes j'en ai que l'utilisateur "sa" d'actif et protéger par un mot de passe.

---

Sa peut tout faire dans un serveur SQL y compris supprimer les bases... C'est consternant de voir encore l'utilisation systématique de sa comme seul moyen d'accès à un serveur...

Bref, commencez par vous former à l'admin, parce que là on en aurais pour plusieurs semaine de discussions avant d'écluser vos problèmes...

A +