2017-10-13 23 views
0

edit: Merci pour tous les conseils. Pendant ce temps, le problème s'est résolu. Je ne sais pas pourquoi mais ça marche maintenant. Bizarre ...Base de données MSSQL: Le journal n'a pas été effacé après COMMIT TRANSACTION

J'ai une base de données MSSQL qui est en mode de récupération simple et il y a cette procédure stockée:

BEGIN TRY 
    BEGIN TRANSACTION; 

    exec prcDownSyncOrganisationalUnit; 
    exec prcDownSyncOrganisationalUnitPeriod; 
    exec prcDownSyncPerson; 
    exec prcUpSyncPersonLogin; 
    exec prcDownSyncOrganisationalUnitPerson; 
    exec prcDownSyncAddress; 
    exec prcDownSyncLocation; 
    exec prcDownSyncLocationAddress; 
    exec prcDownSyncOrganisationalUnitLocation; 
    exec prcDownSyncTour; 
    exec prcDownSyncDisplayType; 
    exec prcDownSyncOperator; 
    exec prcDownSyncList; 
    exec prcDownSyncListEntry; 
    exec prcDownSyncQuestionnaire; 
    exec prcDownSyncOrganisationalUnitQuestionnaire; 
    exec prcDownSyncQuestionnaireGroup; 
    exec prcDownSyncQuestionnaireGroupQuestion; 
    exec prcDownSyncExpressionGroup; 
    exec prcDownSyncExpressionGroupMember; 
    exec prcDownSyncExpressionAssignment; 
    exec prcDownSyncQuestionnaireGroupQuestionExpression; 
    exec prcDownSyncQuestionnaireGroupQuestionMapping; 
    exec prcBiSyncAppointment; 
    exec prcBiSyncAppointmentStatus; 
    exec prcDownSyncAppointmentStatusEvent; 
    exec prcDownSyncAppointmentAssignment; 
    exec prcBiSyncAppointmentQuestionnaireResult; 
    exec prcBiSyncAppointmentQuestionnaireResultAnswer; 
    exec prcBiSyncAppointmentQuestionnaireResultAnswerHistory; 
    --exec prcBiSyncDocument; 
    exec prcDownSyncAppointmentXmlValue; 
    exec prcDownSyncPromoter; 
    --exec prcRemoveDeletedData; 

    COMMIT TRANSACTION; 
END TRY 
BEGIN CATCH 
    ROLLBACK TRANSACTION; 

    EXEC prcErrorRaise; 
    THROW; 

END CATCH 

Cette procédure toutes les 5 minutes et oblige le journal à croître 500MB par chaque exécution. Une fois la procédure terminée avec succès, le journal n'est pas effacé. Donc, après un certain temps, le journal est vraiment très grand et affecte la performance.

Des idées que je peux faire? Pourquoi le journal n'est-il pas effacé?

+0

Essayez et forcer une troncature du journal avec un point de contrôle – RegBes

+0

fichiers journaux ne se rétrécissent pas automatiquement. L'extension des fichiers journaux est une opération coûteuse. Si cela se produit de façon routinière, le fichier va juste se développer à nouveau, donc vous n'allez pas aider les choses en réduisant le fichier journal. Mais comment la taille du fichier journal affecte-t-elle les performances? –

+0

@SeanLange Parce qu'à chaque exécution, le fichier journal augmente de 500 Mo. Après un jour, le disque est plein et je pense que le disque complet a un impact sur le performace (j'aurais dû le mentionner au début). Il y a donc des données dans le journal qui ne sont jamais effacées. Mais en mode de récupération Simple cela devrait se produire après une transaction terminée. – OPunktSchmidt

Répondre

1

Je dirais que nous avons besoin de plus d'informations. Exécutez DBCC SQLPERF (logspace) pour afficher l'état actuel du journal. Exécutez (dans une transaction) chaque proc répertorié dans votre wrapper scénario. Valider ReRun DBCC SQLPERF (logspace)

La taille du fichier journal augmente-t-elle après l'un de ces appels? Si oui, il y a un sujet à aborder avec vos développeurs.

Cela peut être utile aussi: https://www.mssqltips.com/sqlservertip/1178/monitoring-sql-server-database-transaction-log-space/

+0

Merci pour l'indice. Mais le problème a maintenant résolu le week-end par lui-même. Bizarre ... .So taille du fichier journal ne change pas après l'appel de DBCC SQLPERF (logspace). – OPunktSchmidt