Discussion :

[teetee75]

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

[Boubou2020]

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

Code :

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

dbcc opentran

Code :

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

select name,log_reuse_wait_desc from sys.databases

[teetee75]

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.

[teetee75]

Bonjour, Merci de me répondre:

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

Code :

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

dbcc opentran

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

Code :

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

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é....

[SQLpro]

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.

...
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).

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é !

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 !

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 :

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

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 +