間にいくつか投稿をはさんでしまいましたが仮想ログファイルの管理オーバーヘッドについてみていきたいと思います。
トランザクション ログのファイルサイズは同一にして、仮想ログファイル数を変更し、トランザクション ログのバックアップの時間の変化を確認してみます。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
間にいくつか投稿をはさんでしまいましたが仮想ログファイルの管理オーバーヘッドについてみていきたいと思います。
トランザクション ログのファイルサイズは同一にして、仮想ログファイル数を変更し、トランザクション ログのバックアップの時間の変化を確認してみます。
前回投稿した、SQL Server Sysprep の [イメージの完了] ですが、setup.exe で起動することで実行しているため、コマンドから開始することが可能です。
コマンドで実行できるのであれば Sysprep に簡単に組み込むことが可能ですので今回は VM Role のイメージに SQL Server Sysprep を組み込んで、VM Role 上で SQL Server 2008 R2 Express Edition を起動してみたいと思います。
SSRS につていては設定の詰めが甘いので、セキュリティ設定ができていないですが起動後に HTTP でアクセスはできる状態では起動します。
作業の流れとしては以下のようになります。
# VM Role のイメージは Sysprep を実行する直前までは完了している状態です。 ![]()
Sysprep 中にコマンドを実行するための方法は以下の技術情報が参考になります。
Sysprep 中に任意のコマンドを実行する方法について
本手順ですが、データベースのデータの永続化に関しては考慮をしていません。
そのため、SQL Server 内のデータに関しては非永続化された揮発性のデータとなります。
一週間ほど VM Role を使っていて感じたのは、このロールはアプリケーションの実行環境としての利用用途として考えた方が良いのではないかということです。
VPS のようなイメージで考えていると要件にマッチしないと思います。
永続化するようなデータは Web / Worker Role と同様に Windows Azure Storage を使う必要があると思いますので、Windows Azure の作法に乗っ取ったアプリケーションを実行するための環境を VM Role で作ることができるという感じかと。
# カスタマイズした VHD を使用することができるので汎用性が高いのかなと。
前からまとめようと思っていた SQL Server の仮想ログファイル (VLF : Virtual Log File) について少し書いてみたいと思います。
SQL Server の Books Online の [トランザクション ログの物理アーキテクチャ] には以下の記載があります。
SQL Server データベース エンジンにより、各物理ログ ファイルは内部的に多くの仮想ログ ファイルに分割されています。
仮想ログ ファイルのサイズは固定されておらず、1 つの物理ログ ファイルに対する仮想ログ ファイルの数も決まっていません。
仮想ログ ファイルのサイズは、ログ ファイルの作成時や拡張時にデータベース エンジンにより動的に選択されます。データベース エンジンでは、管理する仮想ファイルの数を少なく保とうとします。
ログ ファイルを拡張した後の仮想ファイルのサイズは、既存のログのサイズと増加した新しいファイルのサイズの合計になります。
管理者が仮想ログ ファイルのサイズや数を構成または設定することはできません。
この内容についてみていきたいと思います。
MCM の Readiness Videos では、[LogFiles] が本内容に該当します。
前回はローリング アップグレードということで、パッシブ ノードからパッチを適用していました。
アクティブ ノードからパッチを適用したらどうなるのだろうと思って試してみました。
TechNet フォーラムを見ていたところ SQL Server 2008 R2 のローリングア ップグレードを使用したパッチ適用についての投稿がありました。
そういえば、SQL Server 2008 以降のクラスタ環境ではローリング アップグレードのシナリオが追加されていたなということを思い出し、良い機会だったので試してみました。
# Tech・Ed 2009 のセッションでの話があったということをブログに書いていたのですが試していませんでした…。
技術情報としては以下の情報が参考になります。
# フォーラムに記載されていた技術情報になります。2008 R2 でも同じ手順になります。
SQL Server 2008 フェールオーバー クラスタにローリング更新プログラムおよび Service Pack を適用する方法
今回は使用しないのですが以下のような技術情報もあります。
FIX: Error message when you perform a rolling upgrade in a SQL Server 2008 cluster : "18401, Login failed for user SQLTESTAgentService. Reason: Server is in script upgrade mode. Only administrator can connect at this time.[SQLState 42000]"
SQL Server フェールオーバー クラスター インスタンスをアップグレードする方法 (セットアップ)
今回は [データベースの整合性確認の負荷] について振り返っていきたいと思います。
前回の振り返りでまとめていたデータベースの整合性確認 (DBCC CHECKDB) ですが、データベースの状態を確認するためには大事になる処理ですが、整合性を確認するためには負荷がかかります。
先日、SQL Server 2005 SP4 が提供されました。
Microsoft SQL Server 2005 Service Pack 4 RTM
Windows Server 2008 のクラスタ環境にインストールした SQL Server 2005 にサービスパックを適用する場合には注意点がありますのでまとめてみたいと思います。
# 2008 以外でも発生するかもしれません。(2003 では発生しなかった気もするのですが)
SQL Server 2005 のメインストリームサポート終了日が [2011/04/12] と半年を切っており最新のサービスパック適用の機会があるかもしれないので軽く書いておこうかと。
今回は SP4 を対象としてまとめていますが、SP1 ~ SP3 , Cumulative Update に関しても同様の手順が必要になります。
# CU に関しては、発生するかは更新内容によって変わると思うのですが。
クラスタ環境で SQL Server 2005 のサービスパックをインストールする場合は、SQL Server のリソースを保持しているノードでサービスパックのインストールを実行します。
SQL Server のリソースを保持していないノードでサービスパックのインストールを実行しても、[MSSQLSERVER] (SQL Server ノーサービスコンポーネント) は選択をすることができません。 ![]()
クラスタ環境の SQL Server 2005 でサービスパックをインストールすると [データベース サービス] のインストールで失敗する場合があります。 ![]()
インストールの失敗ですが以下の技術情報が該当します。
An error message is logged in the Summary.txt file when a SQL Server 2005 service pack, cumulative update or cluster hotfix installation fails: "The Transaction Manager is not available"
SQL Server 2005 のサービスパックのインストールログですが以下のディレクトリに出力されます。
[C:Program FilesMicrosoft SQL Server90Setup BootstrapLOGHotfix]
このディレクトリの中に、[Summary.txt] がありますので、このファイルの内容を確認してみます。
|
Product Installation Status |
データベース サービスで [正常に修正プログラムが適用されたパッシブ ノードはありません] のエラーが出力されています。
このログは [アクティブ ノード] (SQL Server のリソースを持っているノード) のログになりますので、パッシブ ノードでもログを確認してみたいと思います。
# ログはアクティブ ノードと同じディレクトリに出力されています。
|
Product Installation Status |
今回の現象ですが、パッシブ ノードで [データベース サービス] のサービスパック適用に失敗しているのではなく、[クライアント コンポーネント] に対してのサービスパック適用で失敗しています。
この現象ですが、[クラスタの MSDTC のリソースをクライアント コンポーネントの適用が実行されているノードが所有していない] と発生します。
DTC と SQL Server のリソースを [2008-CLS-01] というサーバーで所有させていました。
この状態でサービスパックを適用したため今回の現象が発生していました。
ここからが本題で適用するための手順になります。
[2008-CLS-01] でサービスパックのインストーラーを起動するため、SQL Server のリソースは [2008-CLS-01] に配置しています。
DTC のリソースは [2008-CLS-02] (SQL Server から見てパッシブ となっているノード) に配置しています。
この状態でサービスパックのインストーラーを実行します。
インストールをクリックするとパッシブ ノードのタスク スケジューラに [SqlNodeInstall] といタスクが作成され、パッシブ ノードでサービスパックのインストールが開始されます。 ![]()
このタスクを使用して、インストーラー実行時にパッシブノードの [C:UpdateTemp] にコピーされたサービスパックのプログラムが実行されます。 ![]()
パッシブ ノードのタスクマネージャーを確認すると [msiexec.exe] や [hotfix.exe] が起動されていることが確認できます。 ![]()
インストールを開始してしばらくしているとパッシブ ノードで以下のダイアログが表示されます。
# パッシブ ノードにサービスパックのインストール時に指定したアカウントでログオンしておく必要があります。 ![]()
Windows Server 2008 + SQL Server 2005 の場合、VS 2005 がプログラム互換性アシスタントの警告対象となります。
DTC をパッシブ ノードで実行している場合は、このダイアログが表示できるのですが、アクティブ ノードで DTC を実行している場合はこのダイアログが表示されません。
そのため、クライアント コンポーネントのアップデートができずにエラーとなってしまうようです。
クライアント コンポーネントはアクティブ / パッシブのノード両方でインストールする必要があります。
そのため、アクティブ ノードでクライアントコンポーネントのアップデートが実行される際には、DTC のリソースはアクティブ ノードで実行しておく必要があります。
上記のダイアログがパッシブ ノードで表示されたら、クラスターの管理コンソールを開き、リソースの配置を以下の用に変更しておきます。
# DTC のリソースを [2008-CLS-02] → [2008-CLS-01] に移動しました。 ![]()
DTC の配置が終わったら、[プログラムを実行する] をクリックします。
# アクティブ ノードでクライアントコンポーネントの適用が実行される前までに DTC のリソースを移動しておけば問題ありません。
パッシブ ノードでインストールが終了すると、アクティブ ノードでインストールがされます。
アクティブ ノードでも [クライアント コンポーネント] のインストールが実行されるタイミングで、プログラム互換性アシスタントのダイアログが表示されますので、[プログラムを実行する] をクリックします。
# アクティブ ノードで DTC のリソースが実行されていないと今度はアクティブ ノードでインストールが失敗します。
![]()
この手順でインストールをするとサービスパックの適用が正常に完了します。 ![]()
SQL Server 2005 のサービスパックをクラスタ環境に適用する場合はクラスタの DTC リソースの配置状況に注意する必要があります。
この現象ですが、[クライアント コンポーネント] の更新が入らない場合は発生しないので、CU の適用時にはクライアントコンポーネントが更新対象として含まれていなければ失敗はしないと思います。
今回は [データベースの整合性確認] について振り返っていきたいと思います。
[メンテナンス プラン ウィザード] では、 [データベースの整合性確認] のメンテナンス タスクを作成することが可能です。
このタスクを実行するとデータベースの整合性をチェックすることができます。
セミナーの中では、バックアップの取得前等に実行をすることでデータベースに問題が無いかを確認しバックアップを取得することが可能というようなお話がありました。
今回は、この整合性確認についてまとめていきたいと思います。
まずはデータベースの整合性確認のタスクで実行される内容について確認していきたいと思います。
作成したデータベースの整合性確認のタスクで実行される T-SQL を確認してみます。
![]()
データベースの整合性確認のタスクでは、実行対象として指定したデータベースに対して [DBCC CHECKDB] が実行されます。
# [インデックスを含める] を外すと [NOINDEX] オプションを指定して実行されます。
以下は、BOL の DBCC CHECKDB の記載内容の引用になります。
次の操作を実行し、指定したデータベース内のすべてのオブジェクトの論理的および物理的な整合性をチェックします。
- データベースに対して DBCC CHECKALLOC を実行。
- データベース内にあるすべてのテーブルとビューに対して DBCC CHECKTABLE を実行。
- データベースに対して DBCC CHECKCATALOG を実行。
- データベース内にあるすべてのインデックス付きビューの内容を検証。
- FILESTREAM を使用して varbinary(max) データをファイル システムに格納する場合のテーブルのメタデータとファイル システムのディレクトリおよびファイルの間のリンクレベルの一貫性を検証。
- データベースの Service Broker データを検証。
DBCC CHECKDB では、上記の処理を実行してデータベースの整合性が取れているかを確認する処理になります。
データベースの整合性確認を行う事でどのようなことが分かるか、簡単に試してみたいと思います。
今回は、バイナリエディタでデータファイル (mdf) を開き、一部のデータを書き換え、データの内容とページのチェックサムが一致しないようにしてみました。
データを書き換える前のテーブルの全件を取得した情報がこちらになります。 ![]()
SQL Server 2008 以降であれば、データがどのページに格納されているかは [sys.fn_PhysLocFormatter(%%physloc%%)] を使用することで確認することができます。
# この関数は、Undocument の関数です。
上のデータは、以下のクエリを実行して取得しています。
|
SELECT |
SQL Server のページにはチェックサムがあり、データの内容を元に計算したチェックサムとデータの内容が一致しているかを確認することで、ページが破損しているかを検出する機能がありますのでページに一貫性が無いとエラーとして検出することができます。
# データベースオプションで [CHECKSUM] / [TORN_PAGE_DETECTION] / [NONE] のいずれかを設定することが可能です。([TORN_PAGE_DETECTION] は下位互換となっていますが。)
今回はバイナリエディタでデータベースのファイルを開いて、 (1:114:0) のページを壊してみました。
ページを壊した後に、データを全件取得すると以下のデータまでは取得できるのですが、 (1:114:0) のデータを読み込もうとした際にエラーが発生します。 ![]()
|
メッセージ 824、レベル 24、状態 2、行 1 |
(1:114) という情報が表示されていますので、ファイル ID 1 (mdf ファイル) の 114 ページに一貫性のエラー (チェックサムとデータが不整合) が発生していることが確認できます。
今回、私が壊したページ番号と一致しますね。
破損ページの操作をした場合、イベント ビューアーのアプリケーションにも同様の情報が出力されますので、監視ソフト等でログ監視をしているのであれば、エラーを検知することもできます。 ![]()
今回はデータを全件読み込みしたので破損ページも読み込まれエラーが発生しましたが、破損したページにアクセスをしなければ正常にデータを読み込むことができます。
# Col = 4 のデータを読もうとするとエラーになってしまうので飛ばしています。(先行読み込みの可能性が) ![]()
破損したページを操作しないとエラーにはなりませんので、データベースに異常があるかは分かりません。
DBCC CHECKDB を定期的に実行することで障害により発生した潜在的に潜んでいるデータベースの異常をチェックすることが可能です。
[DBCC CHECKDB(N’TEST’)] を実行して、今回整合性のエラーが発生している [TEST] データベースでデータベースのチェックをしてみます。
|
‘TEST’ の DBCC 結果。 |
DBCC CHECKDB を実行することで、データベースの状態をチェックしてくれますので、破損している領域を操作しなくても異常があるかどうかの確認をしてくれます。
イベントビューアーと SQL Server のログにも結果の概要が出力されますので、後で結果を再確認することも可能です。
![]()
SQL Server のダンプのテキストも出力されています。 ![]()
[msdb..suspect_pages] を SELECT することで直近の情報を取得することもできます。 ![]()
DBCC CHECKDB をバックアップ実行前に実施する理由ですが、[障害が発生しているデータベースのバックアップは障害が発生した状態] となるからです。
障害が発生していない状態のデータベースのバックアップがないと破損している領域を修復することができません。
# SQL Server 2008 以降のデータベースミラーリングであれば、破損ページを読み込んだ際にミラー側から修復することも可能ですが。
そのため、バックアップを取得する前にデータベース自体に異常が無いかを確認して、その後にバックアップを取ることが推奨されます。
セミナーの中で質問 / 回答があったのですが、DBCC CHECKDB によるデータベースの整合性確認はデータベースのサイズが大きいとかなり負荷がかかります。
そのため、バックアップのたびに毎回実行するのが難しいかもしれませんね。
次の投稿では [データベースの整合性確認の負荷] についてまとめてみたいと思います。
今回は [バックアップポリシー] について振り返っていきたいと思います。
# 参加から 2 週間経過したのでテンポよくまとめていかないとだいぶ記憶が薄れてきました…。
セミナーでは以下のような図を元にバックアップポリシーについてのお話しがありました。
上の図は復旧モデルを [完全] または [一括ログ] にした場合のバックアップの基本的な設定になります。
# [単純] 復旧モデルの場合は、ログのバックアップが取れませんので、データベースのバックアップのみになります。
セミナーでは日に一度のデータベースバックアップと、一時間おきのログのバックアップで設定というような例でお話をされていたと思います。
SQL Server のバックアップは大きく分けて 3 種類あります。
# ファイル / ファイルグループでのバックアップも取得ができるのですが、今回は割愛しておきます。
完全 / トランザクションログは上の図で [データベース] [ログ] と書かれているバックアップになります。
[完全バックアップ] は、その時点 (バックアップを実行したタイミング) でのデータまで復元することが可能なバックアップとなります。
完全バックアップはそのバックアップ単体で戻すことが可能ですのでバックアップにはログも含まれています。
[差分バックアップ] は、前回の完全バックアップからの差分データのみを含んだバックアップになります。
完全バックアップを元にした差分になりますので、単体で戻すことはできず必ず前回の完全バックアップが必要となります。
また、差分バックアップは前回の完全バックアップからの差分データですので、完全バックアップを取得してからの期間が長くなり、全データが更新された状態になってしまうと、完全バックアップ相当のバックアップファイルのサイズとなります。
[トランザクションログバックアップ] は、ログレコードのバックアップになります。
復旧モデルのときにもお話しがあったのですが、復旧モデルを [完全] [一括ログ] にしている場合は必須になるバックアップとなります。
これらの復旧モデルに関しては、ログレコードは自動的に切り捨てはされず、バックアップを取得したタイミングで切り捨てが行われ、切り捨てられた個所が再利用可能となります。
そのため、ログのバックアップを取得しないとログがずっと蓄積された状態となり、ログ領域のディスクが枯渇することになります。
ログのバックアップは障害発生時に重要となるバックアップのため、できるだけ短い間隔で取得することが重要であるとセミナーではお話がありました。
# 1 時間おきのログのバックアップというお話はこのタイミングであった気がします。
データベースの完全バックアップを取得していない状態ではログバックアップは取得することはできません。 ![]()
バックアップについてですが、以下の資料がわかりやすいと思います。
SQL Server 2000 の資料ですが、それ以降のバージョンでも考え方は同じですので。
第 4 章 バックアップと復元
定期的なバックアップの設定方法として、[メンテナンスプランウィザード] によるバックアップの設定が紹介されていました。
ワンタイムのバックアップであれば、データベースを右クリックして、[タスク] → [バックアップ] からバックアップを取得することが可能です。 ![]()
このバックアップに関しては、ワンタイムになりますので定期的なバックアップの取得の設定はできません。
定期的なバックアップをウィザード形式で設定する場合は、セミナーで紹介のあった [メンテナンスプランウィザード] を使用する事で設定ができます。
メンテナンスプランウィザードは [管理] → [メンテナンス プラン] → [メンテナンス プラン ウィザード] から起動することができます。 ![]()
メンテナンス プラン ウィザードを使用することで、データベースのメンテナンスをする仕組みを数ステップで設定が可能となります。 ![]()
今回のセミナーでお話しのあったメンテナンスプランに似たものを実際に作ってみたいと思います。
以上でメンテナンスプランの作成は完了です。
今回は、[完全 バックアップ] の取得と、[トランザクションログ] のバックアップの取得を設定していますので二つのジョブが SQL Server エージェントに作成されています。
作成した 2 つのジョブを手動で実行して、バックアップの取得状況を確認してみたいと思います。
ジョブを手動実行する場合は、対象のジョブを右クリックして、[ステップでジョブを開始] をクリックします。 ![]()
今回は、H ドライブにアックアップを取得しているのですが、データベースのバックアップ (.bak) とトランザクションログのバックアップ (.trn) が取得されていることが確認できます。 ![]()
今回のメンテナンスプランですが、バックアップを取得するたびにタイムスタンプが設定されたバックアップファイルが蓄積されていきます。 ![]()
また、ログに関してもバックアップを実行するたびに蓄積されていきます。 ![]()
このバックアップとログの履歴 (世代) 管理ですが、[メンテナンス クリーンアップ タスク] を使用することで管理することができます。
先ほど作成したメンテナンスプランにこの履歴クリーンアップタスクを組み込んでみたいと思います。
作成したメンテナンスプランは、[管理] → [メンテナンス プラン] の下に作成がされますので、作成したプランをダブルクリックします。 ![]()
そうするとメンテナンスプランのデザインウィンドウが開きます。 ![]()
先ほど作成したプランが、[Subplan_1] [Subplan_2] として設定されています。
今回は [サブプランの追加] をクリックして、[Subplan_3] として[メンテナンス クリーンアップ タスク] を設定します。 ![]()
タスクをダブルクリックすると設定画面になります。
このタスクを使用することで、バックアップファイルとメンテナンスプランのレポートを削除することが可能です。
拡張子単位で指定はできるのですが、ワイルドカードは使えないので、[bak] [tran] 用のバックアップファイル削除タスクを用意します。 ![]()
![]()
テキストレポートのクリーンアップタスクとしては以下の内容を設定しました。 ![]()
今回はスケジュールも設定し、このような形でサブプランを設定してみました。 ![]()
今回は 4 週経過したファイルが対象になっていますので、以下の PowerShell を実行して、ファイルの更新日付を変更してみました。
# クリーンアップタスクでファイル操作をする際の日付はファイルの更新日付が検索対象となります。
| Get-Item "C:Program FilesMicrosoft SQL ServerMSSQL10_50.SQL2008R2MSSQLLogMaintenancePlan_Subplan_1_20101220221815.txt" | Set-ItemProperty -name LastWriteTime -Value (Get-Date).AddDays(-28) |
これで、メンテナンスレポートの日付が 28 日前 (4 週間前) になりました。 ![]()
それでは、作成したクリーンアップタスクんのジョブを実行してみます。
ジョブを実行したことで、先ほどファイルの更新日付を変更したメンテナンスレポートが削除されていることが確認できます。
バックアップ ファイルに関しても更新日付が条件に一致するのであれば削除されます。
![]()
メンテナンス プラン ウィザードを使用することでバックアップのメンテナンスプランを GUI のウィザードベースで柔軟に設定することが可能となります。
今回の投稿では設定をしなかったのですが、メンテナンスプランには [データベースの整合性確認] というメンテナンス タスクがあります。
セミナーの中ではこのタスクについてもお話がありました。
次の投稿では、データベースの整合性確認についてまとめてみたいと思います。
SQL Server のインストールですが、インストール時に [インスタンス ルート ディレクトリ] を設定します。 ![]()
インスタンス ルート ディレクトリは任意のディレクトリを指定できますので、デフォルトの [C:Program FilesMicrosoft SQL Server] から変更することが可能です。
このインスタンス ルート ディレクトリですが、変更した際に一点注意点があります。
今回は、C ドライブではなく E ドライブに設定をしてみました。 ![]()
インスタンス ルート ディレクトリ以外は C ドライブに設定しています。 ![]()
SQL Server をインストールすると以下のサービスがインストールされます。
インスタンス ルート ディレクトリに選択したディレクトリには、[SQL Server] [SQL Server Agent] のサービスのファイルが格納されます。
![]()
サービス用のプログラムが C ドライブ以外にあることは問題ないのですが、この状態では Windows Server バックアップで [システム状態] [ベアメタル 回復] のバックアップを取得する際に、SQL Server 用のサービスに必要なプログラムが格納されているドライブも取得対象となります。
# このあたりは、System Writer の VSS Writer が制御しているみたいですね。レジストリ (ImagePath の値) を直接修正して、サービスで使用するプログラムの場所を変更すればインスタンス ルート ディレクトリを取らなくすることもできますが。危険すぎてこの方法は使わないですよね…。
最初は [ベア メタル回復] のバックアップ取得を試してみます。 ![]()
ベア メタル回復を選択すると、自動的にベアメタル回復に必要なドライブが選択されるのですが、C ドライブだけでなく E ドライブも自動的に選択がされます。
E ドライブを外そうとしても以下のメッセージが表示され、ドライブ / ドライブ以下のフォルダを外すことができません。 ![]()
[システム状態] を選択すると、システム状態の回復に必要なものが取得されます。
# ドライブの選択状況は変わらず、内部でシステム状態の回復に必要なものが自動で取得されます。 ![]()
システム状態を選択した際に取得されるバックアップを確認してみます。
3 つの VHD ファイルが作成されています。 ![]()
これですが、[システムで予約済み] (通常にインストールをした際の先頭 100MB) [C ドライブ] [E ドライブ] のバックアップとなっています。
Windows Server 2008 R2 の場合はファイル単位でバックアップが取得できるようになているので、各ドライブのバックアップはシステム状態として必要最低限のファイルがバックアップされています。
# C ドライブであればユーザープロファイルのディレクトリは除外されています。
E ドライブのバックアップを確認してみるとサービスで使用している 2 つのファイルのみが取得されています。 ![]()
Windows Server 2008 R2 であれば、ファイル単位で取れるのでシステム状態を取得した時にインスタンス ルート ディレクトリを C ドライブ以外にしても最小限のファイルがバックアップされることになります。
Windows Server 2008 ではどうなるでしょう。
Win
dows Server 2008 では[システム回復を有効にする] がベアメタル回復相当のバックアップとなります。
このオプションを有効にすると、インスタンス ルート ディレクトリに指定したドライブも自動的に選択されます。 ![]()
この動きは、Windows Server 2008 R2 と同じですね。
それでは、システム状態のバックアップを取得するとどうなるでしょう。
Windows Server 2008 の場合は、[wbadmin start systemstate
backup] というコマンドラインを使用して、システム状態だけを取得することが可能です。
# [Start Backup] で取得する場合は、[-allCritical] というオプションを指定します。
システム状態を取得する場合に必要となるファイルが含まれているドライブを自動で判断する動きは Windows Server 2008 R2 と変わりません。 ![]()
Windows Server 2008 の場合は、デフォルトでは先頭の 100MB の領域は作成されないので、2 つの VHD ファイルが取得されます。 ![]()
Windows Server 2008 R2 と異なり、サービス以外のファイルも取得されています。
Windows Server 2008 の場合は、ボリューム単位でのバックアップしか取得ができないため、SQL Server のサービスで使用しているファイル以外のものも取得がされます。
そのため、インスタンス ルート ディレクトリのドライブに SQL Server のデータベースを格納していると、Windows Server 2008 ではシステム状態のバックアップでデータベースのファイルも取得がされてしまい、バックアップのファイルサイズが肥大化する可能性があります。
インスタンス ルート ディレクトリを変更することはあまりないかもしれませんが、変更する場合はバックアップの取得で影響がないようにデータベースのファイルを配置するような考慮が必要そうですね。