質問

インターネット中を探し回っていますが、問題に対する納得のいく解決策が見つかりません。妥協のない解決策はあるのだろうかと疑問に思っています...

私は DBA ではありませんが、追加の組織のための追加の資金がない巨大な Web サイトで作業している 1 人のチームなので、できる限りの最善を尽くしています。

私たちのバックアップ計画は最悪で、改善するのに非常に苦労しています。現在、SQL Server 2005 を実行しているサーバーは 2 台あります。ミラーリングされたデータベース (目撃者なし) があり、うまく機能しているようです。私は正午と真夜中に完全バックアップを実行します。これらはサービス プロバイダーによって毎晩テープにバックアップされ、私は毎週バックアップ ファイルを DVD に書き込み、古い記録を手元に置いています。ミラーリングは監視サーバーなしでは意味がないようなので、最終的にはログ配布に切り替えたいと考えています。

問題は、トランザクション ログがノンストップで増加していることです。私が行った調査によると、ミラー化されたデータベースのログ ファイルを切り詰めることはできないようです。では、ファイルの増大を防ぐにはどうすればよいでしょうか?

に基づく このウェブページ, 、私はこれを試しました:

USE dbname
GO
CHECKPOINT
GO
BACKUP LOG dbname TO DISK='NULL' WITH NOFORMAT, INIT, NAME = N'dbnameLog Backup', SKIP, NOREWIND, NOUNLOAD
GO
DBCC SHRINKFILE('dbname_Log', 2048)
GO

しかし、それはうまくいきませんでした。私が見つけた他のものはすべて、バックアップログコマンドを機能させるためには、バックアップログコマンドを実行する前にミラーを無効にする必要があると述べています。

私の質問 (TL;DR)

ミラーを無効にせずにトランザクション ログ ファイルを圧縮するにはどうすればよいですか?

役に立ちましたか?

解決 3

忘れられていたので、実際にこの見方に答えるべきだと思いました。

ミラーリングを無効にしない限り、データベースがミラーリングされている場合、tログを縮小できません。 間違っている場合は修正してください。しかし、有効な解決策は見つかりませんでした!

サーバーが2台しかない場合は、ログ配布を使用します。ミラーリングは、監視サーバーなしではほとんど意味がありません。フェイルオーバーする唯一の方法はプリンシパルからであるためです...

この件に関する詳細情報や提案を共有したい場合は、お気軽にお問い合わせください。

他のヒント

技術的には、ミラー化された LOG を縮小することは可能です。問題は、truncate_only を使用してログをバックアップすることです。ミラーリングは受け付けません。したがって、1 つの方法は、ディスクへのバックアップ ログを実行することです。

use [DATABASE_NAME]
checkpoint
BACKUP LOG [DATABASE_NAME] TO DISK =  'C:\LOG_BACKUPS\DATABASE_NAME'
dbcc shrinkfile(DATABASE_NAME_Log,1)

これは現在のメンテナンス計画の一部であり、約 2 年間問題なく動作しています。

ミラーサーバーインスタンスがプリンシパルサーバーインスタンスより遅れると、アクティブなログ領域の量が増加します。この場合、データベースミラーリングを停止し、ログを切り捨てるログバックアップを作成し、そのログバックアップをミラーデータベースに適用して、期待していた答えではなくミラーリングを再開する必要があるかもしれません、私は=(

ファイルを圧縮するには、次のスクリプトを試すことができます:

exec sp_dboption DBName、 'trunc。ログオンchkpt。 '、true チェックポイント DBCC SHRINKFILE(DBNameFileName、500); exec sp_dboption DBName、 'trunc。ログオンchkpt。 '、false

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

ミラーのあるデータベースのトランザクションファイルを縮小することは可能です。アクティブな仮想ログファイルがあるため、バックアップを実行する必要があります。 http:/ /www.xoowiki.com/Article/SQL-Server/tronquer-journal-de-log-sur-base-en-miroir-499.aspx

  1. .. ALTER [DatabaseName] SET PARTNER OFF
  2. を使用して、ミラーパートナーをオフに設定します。
  3. プリンシパルでトランザクションログのバックアップを取得します。 BACKUP LOG [DatabaseName] TO DISK = 'Drive:\ DatabaseName_log_datetime.trn'
  4. この DatabaseName_log_datetime.trn をミラーサーバー上の任意の場所にコピーします。
  5. このトランザクションログを、ミラーデータベースの NoRecovery オプションで復元します。 RESTORE LOG [DatabaseName] FROM DISK = 'Drive:\ DatabaseName_log_datetime.trn'
  6. プリンシパルのログファイルを圧縮&ミラーサーバー。
  7. 再びプリンシパルでトランザクションログのバックアップを取得し、ミラーサーバー上のミラーデータベースで、このトランザクションログを復元オプションなしで復元します。
  8. ミラーリングセキュリティを構成します。

この投稿でいくつかの提案をテストしたところ、完全バックアップ、チェックポイントコマンド、およびトランザクションログバックアップの後、プリンシパルデータベースのトランザクションログサイズを縮小できることがわかりました。 ミラーデータベースのトランザクションログのサイズは、プリンシパルの縮小サイズと同期されます。

USE [DATABASE_NAME];
BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_FULL.bak' WITH FORMAT;
CHECKPOINT;
WAITFOR DELAY '00:00:02';
BACKUP LOG [DATABASE_NAME] TO DISK = 'E:\Backup\DATABASE_NAME_TL.trn';
WAITFOR DELAY '00:00:02';
DBCC SHRINKFILE('DATABASE_NAME_log', 500);

OSQLを使用すると、上記のSQLコマンドをDOSバッチで実行できます。バッチで実行する場合、WAITFOR DELAYは必須です。例:

C:\Program Files\Microsoft SQL Server\100\Tools\Binn\osql.exe -E -S "DATABASE_SERVER" -Q "USE [DATABASE_NAME]; BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_FULL.bak' WITH FORMAT;"

別のバックアップも機能するはずですが、テストしていません。以下のdiff backupコマンドは、上書きの代わりにデータを追加します。

BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_DIFF.bak' WITH DIFFERENTIAL;

唯一の方法: 1)ミラーリングを停止します 2)プリンシパルでファイルを圧縮する 3)プリンシパルのバックアップ完了、トランザクションjrnl 4)ミラーサーバーを停止し、mirrorDatabaseのmdfおよびldfを削除します 5)mirrorserを起動し、mirrorDatabaseを削除します 6)mirroServerで3)のリカバリバックアップなしで復元 7)ミラーリングを再インストールする Ouf!

データベースログが大きくなりすぎると縮小できないことは事実です。その時点で、ミラーを解除し、縮小して再作成することが唯一の選択肢だと思います。さらに、たった2つのサーバーでミラーリングを使用するか するかどうかの問題にもかかわらず、定期的にトランザクションログをバックアップすると言うことができます。スペースが解放されるため、MSSQLはログファイル内のデッドスペースを再利用できます。これは何も縮小しませんが、成長を止めるという要件を満たします。

その後、ファイルバックアップを定期的に削除するだけです。たとえば、これを行うことができます:

USE your_database
GO
BACKUP LOG your_database TO DISK = 'x:\your_backup_filepath\your_database.tlog'
GO

可能であれば時間外にそれを行います。

これがなぜ機能するのかはわかりませんが、実際に機能するだけです。これをクエリウィンドウでブロックとして実行します。ご自身の判断で使用してください。マイクロソフトの方がコメントしてくれるといいですね。

use my_database
dbcc shrinkfile ( my_database_log, 1000 )
use my_database
dbcc shrinkfile ( my_database_log, 1000 )
alter database my_database
  modify file ( 
    name = my_database_log, 
    size = 1000MB
  )

ミラーリングされたデータベースは、プリンシパルデータベースでない限り、ミラーから取り出さない限り、実際には何もできません。

動作するのは、プリンシパルサーバー上のデータベースをバックアップし、その後縮小する場合です。つまり、メンテナンス計画には、SOM縮小ジョブを含める必要があります。これらの変更は、同期することでセカンダリ(ミラー)サーバーに自動的に反映されます。

トランザクションファイルのみを縮小する縮小を行う場合は、次のT-SQLを使用できます。

USE [your_db_name]
GO
DBCC SHRINKFILE (N'your_db_name_logfile' , 0, TRUNCATEONLY)
GO

その後、データベースごとにそのスニペットを使用し、バックアップの実行直後に実行します。

それにより、プリンシパルサーバー上、したがってセカンダリ/ミラーサーバー上のログファイルを小さく保つ必要があります。

これが役立つことを願っています。

ところで。ディスクにログファイル用のスペースがなくなるまでになった場合、唯一のオプションは、ミラーモードを解除し、データベースを単純復旧モードに設定し、ログファイルを縮小し、フルに設定することです。復旧モードを再度行い、ミラーを再度セットアップします(データベースogログファイルのバックアップを使用して、ミラーサーバーに復元します)。

さらに、ライセンスが問題の場合は、SQL Expressをミラーリング監視サーバーとして使用できます。あまり多くのリソースを必要としないので、これがWebアプリケーションであれば、Webサーバーを使用できます。ミラーリング監視サーバーのログファイルも忘れずに監視してください。

**ミラーリングでは圧縮を行うことができますが、ログは切り捨てることができません。ログはミラーサーバーに出荷され、プリンシパルは確認応答を待つためです。

この問題の解決策は、切り捨てなしでログをバックアップしてからログファイルを圧縮することです。圧縮を無視することもできます。それでもうまくいかない場合は、ログをバックアップする前にチェックポイントを試してください。これは動作するはずです...

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top