web-dev-qa-db-ja.com

メッセージ1833、ファイル 'ABC.ndf'は、次のBACKUP LOG操作の後まで再利用できません

データベースを持っています。私のデータベースのサイズは約4GBです（.mdfファイルのみ）。そのデータベースでは、データベースの最大のデータを持つテーブルはほとんどありません。それらの1つと最大のテーブルはTable1。これは巨大なテーブルであり、毎日約80000のデータが挿入され、同じではありません。削除されたレコードの。がある 30 days * 80000そのテーブルに存在するレコード。このテーブルは非常に頻繁に使用されます。そのため、大きなデータのクエリには時間がかかります。そのため、私の開発チームは同じテーブルのパーティションを作成することにしました。 Table11の主キーには4つの列があります。
主キー列：

  1. ChequeDateDate
  2. RunNoInt
  3. SorterNoInt
  4. SequenceNoInt

SequenceNo列に基づいてテーブルをパーティション分割することにしました。


同じテーブルにパーティション分割を再適用しようとすると、タイトルに記載されているエラーが発生します。私は manual solution を見つけました。

私の問題は、このプロセスがスクリプトのみから実行されることです。手作業は必要ありません。

問題はロールバックスクリプトにあると想定します。

ALTER TABLE [dbo].[Table1] DROP CONSTRAINT [PK_Table1] with (move to [primary]);
DROP PARTITION SCHEME Table1PartSch
DROP PARTITION FUNCTION Table1PartFunc

ALTER DATABASE [MyDataBase] REMOVE FILE Table125LData;
ALTER DATABASE [MyDataBase] REMOVE FILE Table117LData;
ALTER DATABASE [MyDataBase] REMOVE FILE Table17LData;
ALTER DATABASE [MyDataBase] REMOVE FILE Table12LData;
ALTER DATABASE [MyDataBase] REMOVE FILE Table1RestData;
GO
ALTER DATABASE [MyDataBase] REMOVE FILEGROUP Table125LFG;
ALTER DATABASE [MyDataBase] REMOVE FILEGROUP Table117LFG;
ALTER DATABASE [MyDataBase] REMOVE FILEGROUP Table17LFG;
ALTER DATABASE [MyDataBase] REMOVE FILEGROUP Table12LFG;
ALTER DATABASE [MyDataBase] REMOVE FILEGROUP Table1RestFG;
GO

パーティショニング以外の誰かがより良い解決策を持っているなら、この状況への歓迎です。

sql-serversql-server-2008partitioning
2
RJ1990

ファイル '％ls'は、次のBACKUP LOG操作が完了するまで再利用できません。

SQL Serverは、ファイルが再利用される前にバックアップが取られることを要求しています（== --- ==）災害時のデータベース回復を保証できます。

必要な最低限のバックアップはログバックアップですが、 ドキュメント は、データベースにファイルを追加または削除する操作の後、データベース全体のバックアップを推奨します。

Extract

ファイルを追加して削除し、再度追加しようとすると、この要件にぶつかります。

ファイルを追加および削除するための本来の必要性がある場合は、BACKUP DATABASEまたはBACKUP LOGステートメントをスクリプトに追加する必要があります。

このバックアップは回復チェーンの一部を形成するため、データベースを回復する必要がある場合に備えて、安全に保管することが重要です。

構文の詳細と詳細については、「 BACKUP（Transact-SQL） 」を参照してください。

4
Paul White 9

パウロが言っているのは、誰かがこのエラーから理解すべき主要な理解です。そうは言っても、OPが言及しているような開発環境にいて、ファイル/ファイルグループ作成スクリプトなどをテストしている場合、しない回復シナリオに注意してください。

復旧モデルをシンプルに変更し、データベースを再起動します。

あるいは、完全にサポートされていない代わりに、

トランザクションログをバックアップせずに切り捨てます。

モードをシンプルに変更すると、バックアップからの回復のみが可能になり、それ以降の変更は回復できなくなります。詳細については、 復旧モデル を参照してください。

ログを切り捨てることで、変更操作を削除します。したがって、それはしません バグ ファイルを再利用する前にバックアップを実行する必要があります。しかし、今日では、ログを切り捨てることはできませんバックアップせずにバックアップしますが、- Brent Ozarには適切なページがあります 彼が説明するところ実際にログをバックアップせずに切り捨てを実行するハック。

繰り返しになりますが、これらはどちらも、データを回復する必要があるかどうかを気にしていない場合です。ブレントには「自宅で見ようとしているものを試さないでください」という警告も含まれています。

その操作の構文は次のとおりです。

バックアップログ[DATABASE_NAME] TO DISK = 'NUL：'

1
John