問題タブ [transaction-log]

トランザクション ログに何が書き込まれているかを確認する方法はありますか?

過去 20 分間で 15 ギガ増加したログ ファイルがあります。これを引き起こしている原因を追跡する方法はありますか?

トランザクションログファイルのサイズがわずか1MBのクライアントSQLServer2000ボックスでデータベースを実行しています。これは非常に奇妙に思えます。

明示的に縮小しているデータベースメンテナンスプランまたは個々のSQLエージェントジョブが見つからないため、いつ発生したかを確認する方法がわかりません。

トランザクションログの最後の縮小操作がいつ実行されたかを確認するために使用できるシステムテーブルまたはビューはありますか？

データベースリカバリモデルがに構成されfullているSQLServer2008では、次のようなクエリがあります。

TableNameからcol1、col2、col3を選択します

トランザクションログファイルに記録されます。

つまり、トランザクションログのバックアップを使用して、特定の日にデータベースで実行されたクエリを特定できますか？

毎日非常に急速に増加するトランザクション ログを含む SQL Server 2008 データベースがあります。ログの大部分を構成するトランザクションをより詳細に分析するために使用できるツールを知っている人はいますか? これにより、どこに注意を向けるべきかがわかります。

どんな助けでも大歓迎です！

よろしくマーカス

私は巨大なテーブル (30 億行) を持っていますが、残念ながら期限切れのデータがほとんど含まれています。これらの期限切れの行をすべて削除し、残りを保持したいだけです。

次のようなステートメントを実行できます。

実行計画では、約 4 億行が削除されると推定されています。

実行すると、これは 1 時間経っても終了しないだけでなく、データベース トランザクション ログ ファイルも 6 GB から 90 GB に増加します。これが発生している間、データベースは一括ログ復旧モデルであったことに注意してください。これを行うためのより良い方法があるに違いないと確信しているため、最終的にこのクエリをキャンセルしました。

同様の操作を実行する必要があるテーブルがいくつかあります。これらの行を復元したくない場合に、これらの行を削除する最も速くてスペース効率の良い方法は何ですか?

Microsoft SQL Server 2005 を使用していることに注意してください。

SQL Serverのトランザクションログを読みましたが、それらの使用/管理方法に完全に満足しているわけではありません。トランザクションのロールバック、ミラーリング、レプリケーション、ログ配布などに重要であることがわかりました。

私には、それらはまだブラックボックスのように見え、私はそれらを使って何かをすることに完全に満足しているわけではありません。トランザクションログファイルを表示したり、それに関する情報を取得したりできるツールはありますか？トランザクションログの配布などが必要ない場合は、ログファイルを定期的に縮小または切り捨てても大丈夫ですか？特に、バックアップをテストインスタンスに復元する場合、スペースを占有する数ギガバイトのログファイルが本当に必要ですか？トランザクションログに特に依存していて、ログファイルを縮小/切り捨てた場合に機能しない、他にどのような機能に注意する必要がありますか？

15分ごとに実行されるバックアップジョブプランがすでにあります。トランザクションログ配布プロセスを作成しましたが、1つまたは2つの復元されたログの後、このジョブは機能しなくなります（エラー：一致するログが見つかりません）。明らかに、2つの個別のジョブによって作成されたログがあり、ログ配布プロセスでは、ログの一部のみがセカンダリデータベースにコピーされます（バックアップジョブプランによって作成されたログは除外されます）。これは、バックアップジョブプランをオフにする必要があることを意味しますか？

次の情報を含むデータベース[MyDB]があります
。SQLServer2008MDF
サイズ：30 GB
LDFサイズ：67 GB

ログファイルをできるだけ縮小したかったので、これを行う方法を見つけるために探求を始めました。警告：私はDBAではなく（またはDBAに近づいていません）、この探求を通して感じて進歩してきました。

まず、SSMS、DBプロパティ、ファイルに移動し、初期サイズ（MB）の値を10に編集しました。これにより、ログファイルが62 GBに減少しました（入力した10 MBとは異なります）。そこで、SQLプロファイラーをアタッチして、DBCCSHRINKFILEが呼び出されていることを確認しました。次に、そのコマンドをクエリエディタに入力しました。結果は次のとおりです。

そして、出力は次のとおりです。

それから私はそれについていくつかの調査をし、これを見つけました：

http://support.microsoft.com/kb/907511

これは、仮想ログファイルが解放され、シュリンクファイルがその仕事を実行できるように、シュリンクファイルの前にログファイルをバックアップする必要があることを示しています-それが何を意味するのかわかりません...私はここで言い換えています:)

したがって、ログファイルをバックアップしてからDBCC SHRINKFILEを実行しようと考えました（前のDBCC SHRINKFILEコマンドの出力で識別されたMinimumSizeであったため、新しいログファイルサイズを12800に変更しました）

結果は最初の周回と同じでした。ログファイルは62GBまでしか取得できません。

何が間違っているのか、次に何を試すべきかわかりません。

特にテーブルが大きくなったり、多くの行を更新する必要がある場合は、テーブルのセットベースの処理が常に RBAR よりも優先されるべきであるというのが従来の知恵です。

しかし、それは常に成り立ちますか？私はさまざまなハードウェアで、同じワークロードをより小さなチャンクに分割すると直線的に増加する一方で、セットベースの処理では時間消費が指数関数的に増加する状況をかなり多く経験しました。

完全に間違っていることが証明されるのは興味深いことだと思います-明らかな何かが欠けている場合-または、そうでない場合は、ワークロードを分割することがいつ努力する価値があるかを知ることは非常に良いでしょう. その後、どの指標を使用するかを決定するのに役立つ指標を特定します。個人的には、次のコンポーネントが興味深いと期待しています。

• ワークロードのサイズ
• ログファイルのサイズと増大
• RAMの量
• ディスクシステムの速度

他の？CPU/CPU コアの数?

例 1: 1,200 万行のテーブルがあり、各行の 1 つまたは 2 つのフィールドを別のテーブルのデータで更新する必要があります。これを 1 回の簡単な更新で行うと、テスト ボックスで 30 分ほどかかります。しかし、これを 12 個のチャンクに分割すると、約 24 分で完了します。

例 2: 実質的にすべての行に対していくつかの計算を行う必要がある 2 億行以上のテーブルです。フルセットをオールインワンで実行すると、私のボックスは 3 日間稼働し、それでも完了しません。まったく同じ SQL を実行する単純な C# を作成し、トランザクション サイズを一度に 10 万行に制限するために WHERE 句を追加すると、約 14 時間で完了します。

記録のために：私の結果は、同じデータベースからのもので、同じ物理ハードウェア上にあり、統計が更新され、インデックスに変更はなく、単純な復旧モデルなどがあります。

いいえ、「真の」RBAR を試したことはありませんが、実際にどれくらいの時間がかかるかを確認するためだけに試したほうがよいでしょう。

SQL Server のトランザクション ログについて話したいのですが、いろいろ調べたところ、Lumigent Log Explorer などの製品を見つけました。しかし、私はまだそれについて興味があります。

私が知っている方法: 1.物理ログ ファイルから直接読み取る 2.データベース コマンド/クエリ、DBCC LOG、または fn_dblog を使用する

問題点・難点： 1.ログファイルの構造がリバースエンジニアリングしにくい。2.多くの INSERT を実行すると、fn_dblog にすべてが含まれていません。たとえば、50000 レコードを INSERT すると、fn_dblog には 29616 の LOP_INSERT_ROWS レコードしかありません。これは、20384 レコードが切り捨てられたことを意味します。 fn_dblog について論理的ですが、誰か説明できますか?fn_dblog には制限がありますか?

SQL Server トランザクション ログに関するいくつかの調査を聞いてうれしく思います。