こんにちは
この記事では、SQLServerのデータベーススナップショットについて引き続き説明します。
この投稿の前に以前の記事を読んでください。
SQLServerデータベーススナップショット-1
SQLServerデータベーススナップショット-2
SQLServerデータベーススナップショット-3
このエラーは、本番データベースにとって非常に恐ろしく、経済的な損失です。
スナップショットデータベースを使用して、このエラーから戻ります。スナップショットデータベースのAWBuildVersionテーブルを使用して、AdventureWorksデータベースにAWBuildVersionテーブルを作成します。これには、Select*intoコマンドを使用します。スクリプト実行後のスクリーンショットは次のとおりです。赤い線で示されているように、ドロップされたテーブルはそのデータとともにソースデータベースに返されます。
より理解しやすいという点で、別の同様の例を実行してみましょう。テーブルのデータを削除して、Snapshotデータベースから再度返します。以下の画像1.1に概説されているように、ProductionWorksデータベースの下部にあるBillOfMaterialsテーブルがAdventureWorksデータベースから削除されています。同時に選択カウントを選択すると、下の画像に示すように0レコードが照会されます。
スナップショットデータベースを再度使用して、このエラーから戻ります。上記の2.1と同様に、Snapshotデータベースの同じスキーマとテーブルをソースデータベースの対応するテーブルに挿入しています。同様に、Select Countを照会したときに、画像2.2に示すように、同じ数の行レコードが挿入されます。
最後に、Snapshotデータベースから管理者エラーを作成します。今回は、Snaphotデータベースからソースデータベースを復元します。したがって、AdventureWorksデータベーススナップショットは初期状態に戻っています。 BillOfMaterialsテーブルのデータをProductionSchemaから削除すると同時に、SalesOrderDetailテーブルをSalesスキーマの下に削除しました。スクリーンショットは次のとおりです。 Production Schemaの下部にあるBillOfMaterialsテーブルのデータが削除されたため、SalesOrderDetailテーブルは削除されたため表示されません。
ソースデータベースに多くの変更を加えました。これらの変更は常にスパースファイルに書き込まれると言っています。次の画像は、スパースファイルの最終バージョンを示しています。元のサイズ1は変更されていませんが、元のスパースファイル番号2は増加しています。この理由は、私が言ったように、ソースデータベースで行われたすべての変更がここに書き込まれるためです。したがって、ユーザーが変更されたデータを読み取るときは、スパースファイルから読み取ります。ユーザーが変更されていないデータをクエリすると、ソースデータベースから読み取られます。
それでは、スナップショットに戻りましょう。
SQL Server 2017 Database Snaphot Restore coderestoredatabaseAdventureWorksfromdatabase_snapshot='AdventureWorksSnaphot'
上の画像に示すように、スナップショットを復元した後、削除および削除されたすべてのテーブルをクエリできます。