問題タブ [transaction-log]

Need to generate some test data. This insert is 800,000 X 1,000. I know a lot but this is a real application where the random will be a calculated number.

How can I break this up so the transaction log does not fill up?

It will insert one docSVsys1.sID without filling up the transaction log.

ある種のストリーム リーダー オブジェクトを使用して SQL Server トランザクション ログ ファイルを開くことはできますか?

C# でさまざまな方法を試しましたが、データベースが明示的なロックで .ldf ファイルを開いているように見えます。ファイルを読みたいだけなのに、データベースの実行中はできません。

データベースが閉じているときにファイルを開くことは、私が探しているものではありません。トランザクションログをストリームで読み取ることができる必要があります。私はファイル レイアウトの大まかなスケッチを持っていますが、今は添付することさえできずに行き詰まっています。

設定オプションやその他の方法を知っている人はいますか?

ありがとう！-G

データベースサーバーのディスク容量が不足しています。トランザクションログは100GBを超えるスペースを使用しており、30GBの空きスペースしかありません。このため、一部のトランザクションの処理には無限の時間がかかり、9002エラーが発生します。

このトランザクションログを分割し、そのうちの1つを削除して空き領域を確保する方法はありますか？バックアップをとったり、別のディスクを追加してディスク容量を増やしたりする方法はありません。

トランザクションログを分割するよりも優れたソリューションがあれば、それは素晴らしいことです。

次の機能を備えたトランザクション ログ ライブラリが必要です。

• 最高性能。強制 (フラッシュ) なし。O/S が独自の裁量でバッファを書き込むようにします。メタデータの変更を最小限に抑えるために、ファイル サイズは大きなチャンクで増加します。いくつかの最後のレコードが失われてもかまいません。

  • レコードを逆順 (最新のものから順に) 読み取ります。

問題は、ログ ファイルを読み取るときに最後の有効なレコードを見つける方法です。どのような技術を使用できますか、または準備ができているオープンソース ライブラリはありますか?

トランザクションログ全体を復元する方法はありますが、1つのクエリを復元する方法はありますか？

たとえば、誤って実行したクエリの削除やクエリの更新はありますか？

原因私はそれが特定の時間に復元する可能性があることを知っていますが、邪悪なクエリが1つのテーブルにのみ影響し、他のテーブルの変更を失いたくない場合はどうなりますか？

重複の可能性：
最小限のログイン挿入

切り捨てがログに記録されないため、切り捨てるステージングテーブルがあります。挿入ステートメント（または代替ステートメント）に適用できるフラグがあり、それを補充してもMS SQL Serverに記録されませんか？

Excel スプレッドシートからの入力を処理し、ストアド プロシージャを呼び出してその DB のさまざまなテーブル内にレコードを作成する、トランザクション レプリケーションに関係する中規模のトラフィック データベースに新しいジョブを実装しました。

関連するフィールドの 1 つは、10k ～ 30k 文字のテキスト データ型です。ジョブ内では、カスタム SQL サーバー関数が大きな HTML 本文から URL を解析し、それをテーブルに書き込みます。

集中的な性質のため、またはプロセスのように思われるため、ジョブ実行ごとにスプレッドシートから 35 レコードまたは行のみを 30 分ごとに処理します。ログ リーダー エージェントがトランザクション ログ全体をスキャンし、レプリケーション用のレコードが 0 件しか見つからないため、トランザクション ログが驚くべき速さで増大し、パブリッシャーからサブスクライバーにかなりの遅延が生じていることがわかります。

概観すると、ログのサイズは約 30GB であり、ジョブを 5 ～ 6 回実行するとそのサイズを超えて大きくなるため、これ以上小さくすることはできません。ディストリビューション データベースのバックアップ (5 分ごと) とトランザクション ログのバックアップを 15 分ごとに頻繁に実行しています。

レイテンシを短縮するか、ログからの読み取り (I/O) の量を減らすことができるソリューションが切実に必要とされています。アプリ/ジョブ側で実行する必要がある作業がある可能性があることは認識していますが、この遅延とログからの無駄なスキャンを支援するために実行できるレプリケーション構成内に何かありますか?

どんな助けでも大歓迎です。ありがとうございました。

SQL Server 2008R2 互換性 90 の運用データベースと SQL Server 2005 開発データベースがある場合。

本番環境から開発環境にトランザクション ログを復元できますか? トランザクション ログは、SQL Server 2008 R2 互換性 90 から SQL Server 2005 に復元されますか?

チームのASP.NETアプリケーションのデータアクセス層で、.NET SQLClientを使用して、データベースに対してストアドプロシージャを実行します。データベースでの挿入操作を可能にする新しいコードを追加した後、コードをテストしたところ、次の例外が発生しました。

The transaction log for database 'DBName' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

MS SQL Server Management Studio内から挿入操作を試行したときに、同じメッセージが表示されることを確認しました。最近、データベースに3つの2つのトリガー2つを追加して、特定のテーブルへの挿入と更新に基づいてデータの挿入を実行し、無限ループまたはそのような性質が発生した可能性があると考えたため、心配しました。

ただし、オンラインでのこの問題の他のインスタンスに基づくと、トリガーまたは回転するクエリによって一般的に引き起こされる問題のようには見えません。log_reuse_waitと列に対してクエリを実行しlog_reuse_wait_desc、次を返しました。

2 | LOG_BACKUP

また、クエリは次を返します。SELECT [name], recovery_model_desc, log_reuse_wait_desc
FROM sys.databases

最初の列はlog_reuse_waitで、2番目の列はですlog_reuse_wait_desc。msdnのコードの定義に基づいて、ログのバックアップを実行する必要があります。そうすると、ログが自動的に切り捨てられ、データベースでさらに操作できるようになります。それは正しい仮定ですか？これは、トリガーが正しくコーディングされていないことが原因である可能性がありますか、それともデータベース上の多数のトランザクションによって発生する日常的なメンテナンスタスクである可能性がありますか？

編集：

クエリは次をselect type_desc, size, max_size from sys.database_files返します。