Transaction log full en mode RECOVERY SIMPLE!

Bonjour,

Dans mon logiciel d'entreprise SAP FI avec BDD SQLServer, lors d'une opération (copie distante de mandant), j'obtiens dans la log une erreur:
The transaction log for database 'SID' is full due to 'ACTIVE_TRANSACTION'.

Or Je viens de vérifier par la console SQLServer. Il m’apparait que la base est en mode SIMPLE (résultat de la requête select DATABASEPROPERTYEX('SID','RECOVERY'))
Donc pour moi cette base n’utiliserait pas de fichier de transaction. Elle a pu être par le passé (2009) en mode FULL mais plus à présent.
Ces fichiers de logs sont sauvegardés chaque 20mn dans un répertoire et la dernière date de ce matin.
De plus au niveau de SQLServer, j’ai défini une alerte sur le fichier de logs*:avec un envoi de mél pour faire un shrink de la BDD si la taille du fichier de log excède 8500000.
Et sa dernière notification de dépassement de la taille du fichier remonte au 10/12/15.
Je ne sais plus trop quoi penser de cette erreur. Pouvez-vous m'aider svp?
Merci.

Titouan

Vérifier si vous avez des transactions qui sont toujours ouverts

Code:

---

dbcc opentran

---

Code:

---

select name,log_reuse_wait_desc from sys.databases

---

Bon finalement pas mal de conneries dans mon post précédent: il n'y a pas de sauvegarde des fichiers de journalisation (j'ai confondu avec la prod).
Sur http://blog.capdata.fr/index.php/how...ns-sur-disque/
Je lis que que dans le mode recovery SIMPLE: les transactions validées sont purgées du journal à intervalles réguliers par un processus d’arrière plan, le CHECKPOINT.
Est-ce un service windows, un job SQLServer svp?
Bref comment s'assurer qu'il "tourne"?
Merci.

Bonjour, Merci de me répondre:

Citation:

---

Envoyé par abdallah_mehdoini

Vérifier si vous avez des transactions qui sont toujours ouverts

Code:

---

dbcc opentran

---

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

Code:

---

select name,log_reuse_wait_desc from sys.databases

---

---

NOTHING

Je viens de lancer un checkpoint
GO
Mais mon fichier de log reste désespérément gros (8Go) et sa dernière date de modif est à octobre 2016.
Le checkpoint ne semble pas avoir marché....

Citation:

---

Envoyé par teetee75

Or Je viens de vérifier par la console SQLServer. Il m’apparait que la base est en mode SIMPLE (résultat de la requête select DATABASEPROPERTYEX('SID','RECOVERY'))
Donc pour moi cette base n’utiliserait pas de fichier de transaction.

---

Détrompez vous, une base utilise TOUJOURS un journal de transaction pour toutes les mises à jours, y compris BULK LOAD, TRUNCATE et commandes DDL. Le paramétrage de la journalisation en mode SIMPLE ne fait que minimiser certaines entrées et purger le journal des transactions validées qui ont fait l'objet d'un enregistrement des données.

Citation:

---

...
Ces fichiers de logs sont sauvegardés chaque 20mn dans un répertoire et la dernière date de ce matin.

---

Si vous êtes en mode de journalisation SIMPLE il est impossible de sauvegarder les journaus de transactions pudqisqu'ils sont auto purgés. La sauvegarde des JT ayant la particularité de purger le journal (en sus de faire la sauvegarde).

Citation:

---

De plus au niveau de SQLServer, j’ai défini une alerte sur le fichier de logs*:avec un envoi de mél pour faire un shrink de la BDD si la taille du fichier de log excède 8500000.

---

Faire un SHRINK ne sert à rien si le journal n'est pas purgé !

Citation:

---

Et sa dernière notification de dépassement de la taille du fichier remonte au 10/12/15.
Je ne sais plus trop quoi penser de cette erreur.

---

La première des chose serait de se former car là vous mélangez tout et n'importe quoi et bricolez le serveur sans comprendre ce que vous faites en tentant n'importe quelle manœuvre sans discernement !
Heureusement que SQL Server est un des SGBDR les plus robuste et les plus résilient !

Citation:

---

Pouvez-vous m'aider svp?

---

Commençons par le commenceent :
1) quelle version/édition de SQL Server
2) quelle est le nom de la base cible ?
3) lancez la requête suivante dans le contexte de la base master :

Code:

---

1 2	SELECT name, recovery_model_desc FROM sys.databases;

---

4) lancez la commande DBCC OPENTRAN das le contexte de la base cible
5) donnez nous le code de votre tâche planifiée qui sauvegarde les JT

A +