web-dev-qa-db-ja.com

「fn_dblog」またはDBCC LOG（ 'DataBaseName'）をクエリして、トランザクションのクエリSQLテキストを出力する方法

過去24時間のある時点で、DBを使用する可能であればいくつかのアプリケーションのいずれかによって、お客様のSQLサーバー2008（v 9.0 SP4）にいくつかの変更が加えられました。

特に重要ではありませんが、期間に対応するSQLステートメントをダンプできれば、これらのアプリケーションがテーブルをどのように使用しているかについての有益な洞察が得られます。

私が関心を持っているテーブルはあまり頻繁に変更されないため、それらの特定のテーブルに適用されるトランザクションログは、行全体であまり大きくないはずです。

「fn_dblog」関数とDBCC LOG（ 'DataBaseName'）コマンドが表示され、かなりの関連情報があるようですが、次の手順を実行して実際の変更のレポートを作成する方法がわかりません。

このブログ投稿にはいくつかの詳細があります。 http://janiceclee.com/tag/fn_dump_dblog/

USE AdventureWorks
    GO
    SELECT [Transaction ID], count(*)
    FROM fn_dblog(DEFAULT, DEFAULT)
    where AllocUnitName LIKE '%Production.TransactionHistory%'--table name
    GROUP BY [Transaction ID]
    HAVING COUNT(*) >= 113443 --(estimated/actual) number of deleted records

ただし、そのような詳細はありません。テーブル名（および必要に応じて主キーを取得できます）だけです。

そして、テーブル名が付けられた同様のデータ例を使用している別のブログ投稿。 http://www.sqlskills.com/blogs/paul/post/Search-Engine-QA-6-Using-fn_dblog-to-tell-if-a-transaction-is-contained-in-a- backup.aspx

    USE AdventureWorks;

    GO

    SELECT [Current LSN], Operation, [Transaction ID], AllocUnitName FROM fn_dblog (NULL, NULL);

    GO

The log record at that LSN is:

    00000058:00001870:0001  LOP_MODIFY_ROW     0000:00001338  HumanResources.Employee.PK_Employee_EmployeeID

This is obviously in the middle of my contrived transaction - showing that it isn't all in the full backup. The end of the transaction isn't until way later in the log:

    0000005e:00000628:01b1  LOP_MODIFY_ROW     0000:00001338  HumanResources.Employee.PK_Employee_EmployeeID
    0000005e:00000628:01b2  LOP_COMMIT_XACT    0000:00001338  NULL
sql-serversql-server-2008dbcc
2
Tom H

トランザクションログにはステートメントが含まれず、データベースで発生した物理的な変更が含まれます。削除を示すログレコードが表示される場合は、これがDELETEステートメント、MERGEステートメント、またはワイド（分割）UPDATEステートメントのどれであるかを確認できません。 INSERTを示す操作が表示される場合、それがINSERT（...）VALUES（...）であるか、それともINSERT（...）SELECT（...）であるか、それともINSERT（。 ..）EXEC、またはMERGEか、ワイド（分割）UPDATEでした。などなど。具体的には、トランザクションログは監査トレースの代わりになることを意図していません。

転写複製エージェント T-SQL操作を再構築することを意味します発行された記事を変更したものと同じ効果公開情報ではありません。

データの変更を監視する場合は、 変更追跡 または 変更データキャプチャ を使用します。 T-SQLアクティビティを監視する場合は、 profiler traces を使用します。

7
Remus Rusanu

トランザクションログ自体からクエリを取得できないと思います。間違っている可能性もありますが、実行したことはありません。ただし、トランザクション中に変更されたデータは取得できます。

以下の記事は、変更されたデータをトランザクションログから読み取るストアドプロシージャを示しています。私自身はこれを使用していませんが、社内のいくつかの問題は、それが非常にうまく機能すると言っています。ただし、これは2005年以降でのみ機能することに注意してください。

http://raresql.com/2011/10/22/how-to-recover-deleted-data-from-sql-sever/

それはあなたが後についている洞察を提供するかもしれません-またはそうではない:-)

ところで、同様のことを行う商用ログリーダーアプリケーションがいくつかあります。ただし、十分な調査を行って自分でできることを実行する機能しか提供していないことを覚えておいてください。

すばらしい本であり、SQL Serverで起こっていることの多くを本当に理解するのに役立つ、Kalen DelaneyによるSQL Internalsを見てみることをお勧めします。

http://www.Microsoft.com/learning/en/us/book.aspx?id=12967&locale=en-us

これは過去のトランザクションには役立ちませんが、今後は、変更データキャプチャやSQLプロファイラなどを使用して、必要な情報をキャプチャすることをお勧めします。トランザクションログをトロールするよりもはるかに簡単です。 ;-)

これがお役に立てば幸いです。

3
Mr.Brownstone