2

約 150 万件のレコードを含む SQL Server 2008 テーブルがあり、別のフィールドを追加して別のフィールドを編集したいと考えています。変更を保存すると、エラーが発生します。

'Member' table
- Unable to modify table.  
The transaction log for database 'storeboard' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

トランザクション ログを空にしても、同じエラーが発生します。この問題を回避し、テーブルに必要な変更を加えるにはどうすればよいですか?

4

3 に答える 3

1

「ニキータ」が示唆したように、リカバリ モデルをシンプルに変更して、変更がトランザクション ログで追跡されないようにすることもできます。 ???、別のサーバーに変更をレプリケートするためにトランザクション ログを使用する必要があります...その場合、トランザクション ログがいっぱいになる原因と、トランス ログを無効にせずにそれを修正する方法を理解する必要があります。 .

SSMS を使用して変更を行っているようですが、変更の性質上、SSMS は次のことを行う必要があります。

  1. 変更されたテーブルからすべての外部キー、インデックスなどを削除します
  2. テーブルのすべてのデータを #temp テーブルにコピーします
  3. 提案された変更を含む新しいテーブルを作成します
  4. #temp テーブルから新しく作成されたテーブルにすべてのデータをコピーします
  5. 古いテーブルをドロップ
  6. 新しいテーブルの名前を古いテーブルの名前に変更します
  7. すべてのインデックス、外部キーなどを再作成します。

SSMS スクリプトはスクリプト全体にBEGIN TRANSACTIONandを挿入COMMIT TRANSACTIONするため、何かが失敗した場合でも、テーブルとデータが台無しにならないようにします。GOただし、スクリプト全体にも挿入されるため、エラーが問題を引き起こす可能性があります。特に、最後の操作の 1 つで元のテーブルが削除され、新しく作成されたテーブルの名前が元のテーブル名に変更されるためです。

スクリプトの実行が完了する前に、トランザクション ログがいっぱいになるようです。運用データベースを単純な復旧モデルに変更できない場合 (たとえば、ログ配布が中断されるなどの理由で)、トランザクション ログがいっぱいにならないようにスクリプトを実行する必要があります。

私はお勧め：

  1. 最初に 150 万行を持たない開発/テスト サーバーでスクリプトをビルドしてテストし、スクリプトが意図したとおりに動作することを確認します。
  2. スクリプトを変更しCOMMIT、重要な場所に追加して、スクリプトの実行を継続するときにトランザクション ログのスペースを再利用できるようにします。
  3. #temp テーブルから一度に 100,000 レコードをコピーして、COMMIT各ブロック間に を使用して新しく作成されたテーブルに戻します。
  4. 本番環境で実行する前に、変更したスクリプトを開発/テスト サーバーで再度テストします。
  5. スクリプトを実行する前に、本番データベースをバックアップしてください...
于 2012-12-18T18:05:53.230 に答える
1

これを試してください：

USE master ;
ALTER DATABASE YourDBName SET RECOVERY SIMPLE ;
于 2012-12-18T17:40:41.157 に答える
0

データベースに SIMPLE 復旧モデルを使用している場合でも、SQL Server はすべてをトランザクション ログに書き込み続けます。

datetime8 バイトのストレージを必要とする列を追加するとします。テーブルに 1.5 Mio のレコードがあると仮定すると、SQL Server はトランザクションを完了するために文字どおり 8 * 1.5 バイト (+オーバーヘッド) を必要とします。すべてのビットがログに書き込まれ、停止する方法はありません。

シナリオ (および/またはポリシー) でポイント イン タイム リカバリが必要ない場合は、SIMPLE リカバリ モードが適している可能性があります。自動拡張を有効にし、最大ログ サイズの公正な制限を設定して、に切り替えるだけauto-shrinkですtrue。

それ以外の場合 (実稼働 DB、非常にビジネスに不可欠なアプリなど)、ログ バックアップを使用した完全復旧モデルに基づいて、適切な保守計画を立てることができます。それに関する多くのホワイトペーパーと記事があります。

于 2015-06-21T13:13:30.097 に答える