Comment interroger des fichiers journaux (.ldf) de Sql Server 2005 Express Edition?

Question

Je veux faire ça, parce que je voudrais savoir combien de fois une ligne particulière a été modifiée.

Est-ce possible?

Merci

Answer 1

La lecture du fichier journal prend soit un outil commercial, ou une quantité incroyable de connaissances SQL équipements internes pour atteindre. Vous pouvez voir une partie de la production brute en utilisant:     Select * from :: fn_DBlog (null, null)

En fait le décodage pour trouver le même enregistrement étant modifié et d'assurer une modification a été commis, etc. serait une tâche difficile de le mettre à la légère. Il est donc « possible » mais pas très « probable » que vous serez en mesure de le faire.

Si vous avez besoin de cette fonctionnalité dans une base de données, vous devriez regarder les déclencheurs / logique dans le code.

Answer 2

réponse tardive mais j'espère que ce sera utile pour les nouveaux lecteurs ...

Une autre fonction que vous pouvez essayer LOG DBCC mais malheureusement, c'est fonction non documentée même comme fn_dblog.

Problème journal des transactions dans SQL Server est qu'il n'a jamais été destiné à être utilisé pour cela, mais seulement pour permettre le point de récupération du temps et des propriétés transaction.

Il y a un lecture du journal de ApexSQL que vous pouvez essayer.

Voici aussi quelques messages similaires qui pourraient vous aider dans la bonne direction.

Lire le fichier journal (* LDF) dans sql serveur 2008

Transaction SQL Server Log Explorer / Analyseur

Answer 3

vous pouvez utiliser ce programme pour le faire   http://www.red-gate.com/products/SQL_Log_Rescue/index. htm

Answer 4

Envisagez d'utiliser SQL Server 2008.

Il y a une nouvelle fonctionnalité à SQL Server 2008 appelé Change Data Capture qui fait exactement ce dont vous avez besoin, qui est de suivre les modifications de données au fil du temps.

Vous cherchez à inspecter le fichier journal afin de suivre les changements ne sont pas une pratique sage. Cela vous donnera une histoire limitée, dont la portée serait également en fonction du modèle de récupération que vous utilisez pour votre base de données.

Vous pouvez « rouler votre propre » solution avec une petite quantité de développement, à l'aide d'une table de journal et de remplir à l'aide de triggers SQL Server. La pertinence d'une telle solution est bien sûr dépend de votre cas d'affaires.

Jetez un oeil à l'article TechNet suivant pour une lecture intéressante:

Suivi des modifications dans votre base de données de l'entreprise