5
データベース（DDLおよびDML）への変更を検出する方法
クライアントのSQLサーバーには多くのデータベースがあります。これらのデータベースは開発中であるため、開発者は設計、リファクタリング、データ変更などを行うことができます。ほとんど変更されないデータベースがいくつかあります。私のクライアントは、それらすべてを安全に（バックアップして）保持し、環境の管理に時間を費やさなければなりません。（会社にはDB管理者の立場はありません。）長い議論の末、クライアントは復元が容易なため、毎日の完全バックアップ戦略を使用することにしました。 状況の概要は次のとおりです。 データベースの数は毎日異なります。 変更されたデータベース（データや構造が変更されたことを意味します）はバックアップされます。 変更されていないデータベースはバックアップされません。 ソリューションはデータベース構造に影響を与えません（要件に制限はありません） この「バックアップエンジン」は自動的に機能します。 主な問題：データベースが変更されたことを検出する方法。問題の最初の部分（DDLの変更）は、DDLトリガーを使用して解決できます。ただし、データの変更（DMLの変更）は問題です。DMLトリガーをすべてのデータベースのすべてのテーブルに適用して、変更（パフォーマンス、拡張オブジェクトの管理など）を追跡することはできません。バックアップエンジンは、すべての変更を追跡して、各データベースをバックアップ準備完了としてマークする必要があります。 変更データキャプチャはソリューションですが、重すぎるようです（SQL Server Enterprise Editionも必要です）。 別の方法は、データベースファイルの変更（サイズまたは最終変更時刻）を追跡することですが、正しく機能しません。データベースは、予約されたすべての空き領域を超えたときにサイズを変更でき、sp_spaceusedは解決策ではありません。 トレースは解決策ですが、パフォーマンスの問題を引き起こし、追加の管理が必要です。 他のデータベース管理オブジェクト（統計など）に影響を与えずに、実際のデータベース使用量を計算するソリューションはありますか？テーブルのサイズを変更しないテーブルのデータへの変更はトリガーされないことを認めました（私は思う）が、それは何もないよりはましです。本当にSQL Server 2008の直接または間接的なソリューションを探しています。 コメント、解決策、考えをお寄せいただきありがとうございます。 追加： ソリューションは次のとおりです（Marianに感謝）。 Select NextLSN = MAX(fn.[Current LSN]) ,Databasename = DB_NAME() from fn_dblog(NULL, NULL) fn LEFT JOIN sys.allocation_units au ON fn.AllocUnitId = au.allocation_unit_id LEFT JOIN sys.partitions p ON p.partition_id = au.container_id LEFT JOIN …