データベース エンジンの可用性に関する機能強化
Microsoft SQL Server 2005 データベースの可用性は、オンライン インデックス操作によって向上しています。データベース ミラーリングを使用すると、高速のフェールオーバーをサポートするホット スタンバイ サーバーを作成でき、コミット済みのトランザクションのデータが失われることはありません。
可用性に関する機能強化
インスタンスの可用性 : フェールオーバー クラスタリング
SQL Server 2005 データベース エンジンのインスタンスでは、32 ビットおよび 64 ビット バージョンの Enterprise、Developer、Enterprise Evaluation の各エディションで、オペレーティング システムでサポートされるのと同じ数までのノードによるフェールオーバー クラスタをサポートします。SQL Server 2005 Standard Edition では、2 ノードのフェールオーバー クラスタをサポートします。それより前のバージョンの SQL Server では、32 ビットの SQL Server インスタンスでは 4 ノード、SQL Server 2000 (64 ビット) では 8 ノードのクラスタをサポートしています。
詳細については、「フェールオーバー クラスタリング」を参照してください。
インスタンスの可用性 : 複数インスタンスのサポート
SQL Server 2005 Enterprise、Developer、Evaluation の各エディションは、データベース エンジンのインスタンスを 1 台のコンピュータで 50 個までサポートします。SQL Server 2005 の他のエディションは、データベース エンジンのインスタンスを 1 台のコンピュータで 16 個までサポートします。SQL Server 2000 のすべてのエディションでは、1 台のコンピュータでサポートされるインスタンスが 16 個に制限されています。
インスタンスの可用性 : 専用管理者接続
エラー状態によっては、データベース エンジンが新しい接続を受け入れられないことがあり、その場合、データベース管理者は問題を診断することができません。SQL Server 2005 データベース エンジンには、専用管理者接続 (DAC) という機能が追加され、sysadmin 固定サーバー ロールのメンバは、新しい sqlcmd ユーティリティと DAC を使用してデータベース エンジン インスタンスにアクセスし、診断を行えるようになりました。
詳細については、「専用管理者接続の使用」を参照してください。
インスタンスの可用性 : AWE メモリの動的管理
大容量のメモリをサポートする AWE メモリを使用した場合、SQL Server 2005 データベース エンジン インスタンスは、現在のワークロードに基づいて、使用するメモリの量を動的に調整します。旧バージョンの SQL Server インスタンスでは、AWE メモリを有効にした場合でも、インスタンスの起動時に静的な量のメモリを取得するだけで、ワークロードの変化に応じてメモリ使用量を調整することはできませんでした。
詳細については、「大規模データベースのメモリ管理」を参照してください。
インスタンスの可用性 : ホット アド メモリ
ホット アド メモリとは、実行中のコンピュータに追加された新しいメモリを SQL Server 2005 データベース エンジンで使用するための機能です。旧バージョンの SQL Server では、現在のワークロードに合わせてメモリ使用量を動的に調整できましたが、起動後のコンピュータに追加されたメモリを使用することはできませんでした。
詳細については、「ホット アド メモリ」を参照してください。
データベースの可用性 : データベース ミラーリング
データベース ミラーリングによって、データベースのホット スタンバイ サーバーを作成できます。データベース ミラーリングは、データベースの可用性を改善するためのフェールオーバー クラスタの代替機能であり、フェールオーバー クラスタよりも管理が容易です。データベース ミラーリングでは、1 つのデータベース (プリンシパル データベース) に対するすべての更新が、別個にあるそのデータベースの完全なコピー (ミラー データベース) に直ちにコピーされます。プリンシパル データベースとミラー データベースは、2 つの SQL Server データベース エンジン インスタンス上に存在します。これらのインスタンスは、別々のコンピュータ上で実行する必要があります。プリンシパル データベースが存在するサーバー インスタンスのことをプリンシパル サーバーと呼びます。ミラー データベースを現時点で管理しているサーバー インスタンスのことをミラー サーバーと呼びます。プリンシパル サーバーに障害が発生すると、ミラー サーバーがすぐにミラー データベースをプリンシパル データベースの役割に切り替えます。
詳細については、「データベース ミラーリング」を参照してください。
データベースの可用性 : データベース スナップショット
データベース スナップショットは、論理的一貫性のある既知の時点にまでデータベースを戻すための効率的な手段です。データベース スナップショットでは、すべてのアクティブなトランザクションがロールバックされたかのように、データベース内のデータの現在の状態を記録します。その後、スナップショットでは、その時点以降のすべてのデータ変更を記録していきます。大きなテーブルを誤って削除するなどのミスが起きた場合は、スナップショットを取った時点の状態にまでデータベースを戻すことができます。
詳細については、「データベース スナップショット」を参照してください。
データベースの可用性 : チェックサムによる I/O 検証と読み取り再試行
SQL Server 2005 には、データベース ページのためのチェックサムと読み取り再試行のロジックが組み込まれており、データの安定性が向上しています。チェックサムと読み取り再試行の概念は、Microsoft Exchange Server に大きなメリットをもたらし、物理的なデータ障害につながる I/O パスの問題の検出に役立っています。SQL Server 2005 では、チェックサムと読み取り再試行の機能がデータベース エンジンに組み込まれています。
ALTER DATABASE ステートメントの SET PAGE_VERIFY 句に CHECKSUM オプションを指定できるようになりました。CHECKSUM を指定すると、ページ全体の内容に基づくチェックサムが計算され、ページがディスクに書き込まれる時点でデータベース ページ ヘッダーにそのチェックサムが格納されます。ディスクからページを読み取るときには、チェックサムが再計算され、データベース ページ ヘッダーに格納されているチェックサム値と比較されます。2 つの値が一致しない場合は、I/O パスまたはメディアへのページの書き込みの時点か、格納中か、ページの読み取りの時点で、ページが物理的に損傷を受けたことを意味します。この障害については、データベース エンジンがアプリケーション、Windows のイベント ログ、データベース エンジンのエラー ログにエラーを返します。データベース ページのチェックサムは、バックアップ操作と復元操作の実行時にも検証されます。チェックサムによる検証が失敗した場合は、I/O パスに問題があるので、ハードウェア、ファームウェア ドライバ、BIOS、フィルタ ドライバ (ウイルス対策ソフトウェアなど)、その他の I/O パス コンポーネントを調べて、根本的な原因を判別する必要があります。
データベース エンジンは、失敗した I/O 操作を 4 回まで再試行して、I/O パスの問題が一時的なものかどうかを調べます。再試行が成功した場合でも、入出力の問題が解決されたとは限りませんが、読み取り再試行の機能を使用すれば、データの可用性を確保しながら、入出力の問題を十分に調査することが可能になります。
詳細については、「ALTER DATABASE (Transact-SQL)」の PAGE_VERIFY オプションの説明を参照してください。
データベースの可用性 : ミラー化されたバックアップ メディア
ミラー化されたバックアップ メディアに対してバックアップを実行すれば、いずれかのバックアップが失われた場合の影響を最小限に抑えることができます。1 つのバックアップ デバイスに障害が発生しても、ミラーの 1 つを使用してデータベースを復元できます。
詳細については、「ミラー化バックアップ メディア セットの使用」を参照してください。
データベースの可用性 : バックアップと復元のためのメディア チェック
TORN_PAGE_DETECTION または新しい CHECKSUM データベース オプションを設定すれば、BACKUP ステートメントや RESTORE ステートメントの新しいオプションによって、バックアップ操作と復元操作の実行時にデータ ページの整合性を検証できます。それらのオプションを指定して RESTORE VERIFYONLY を使用すれば、バックアップを使用してデータベースを復元する前に、そのバックアップを詳細に検証できます。
詳細については、「メディア エラーの検出と処置」を参照してください。
データベースの可用性 : クラッシュからの復旧時およびデータベース ミラーリングのフェールオーバー時の高速復旧
SQL Server 2005 Enterprise Edition のデータベース エンジンでは、クラッシュからの復旧時およびデータベース ミラーリングのフェールオーバー時の高速復旧が可能です。高速復旧が行われることで、元に戻すフェーズ中にデータベースを使用できるようになり、復元操作中、データベース ページのチェックサム処理中、およびバックアップ メディアのミラーリング中にデータベースを一部使用できるようになりました。SQL Server 2005 の他のエディションでは、復旧が完了するまでユーザーがデータベースにアクセスすることはできません。旧バージョンの SQL Server でも、元に戻す段階が完了するまでデータベースへのアクセスは不可能でした。復旧全般の詳細については、「SQL Server でのバックアップの復元と復旧の動作について」を参照してください。フェールオーバー後の復旧の詳細については、「役割の交代中に発生するサービスの中断時間の算出」を参照してください。
データベースの可用性 : バックアップと復元のエラー レポート
BACKUP ステートメントと RESTORE ステートメントで CONTINUE_AFTER_ERROR オプションを指定できます。このオプションを指定した場合、データベース エンジンは、エラーを受け取った後でも処理を続行します。複数の問題がある場合、データベース管理者は、このオプションを使用して問題のスコープを判別できます。
詳細については、「バックアップの破損による SQL Server 復元エラーの対応」を参照してください。
データベースの可用性 : オンライン復元
1 つのデータベース ファイルまたは 1 つのデータベース ページを対象にした部分的なデータベース復元操作の場合、ユーザーはその操作の実行中でもデータベースにアクセスできます。つまり、その対象の部分には復旧の完了までアクセスできませんが、その他のデータにはすべてアクセスできます。旧バージョンの SQL Server では、すべての復元操作の実行時にユーザーがデータベースにアクセスすることはできませんでした。
詳細については、「オンライン復元の実行」を参照してください。
データベースの可用性 : EMERGENCY オプション
復旧時にデータベースが問題ありと判断された場合に、そのデータベースを緊急モードにすることができるようになりました。このモードでは、sysadmin 固定サーバー ロールのメンバに対し、読み取り専用アクセスが許可されます。これにより、問題を診断したり、使用可能なデータを取得したりすることが可能になります。
詳細については、「バックアップの破損による SQL Server 復元エラーの対応」を参照してください。
データベースの可用性 : オンライン インデックス操作
インデックス操作をオンラインで実行できるようになりました。つまり、1 つのインデックスの作成や変更や削除の実行中に、そのテーブルのデータにアクセスすることや、そのテーブルの他のインデックスを使用することができます。
詳細については、「オンラインでのインデックス操作の実行」を参照してください。
データベースの可用性 : 並列インデックス操作
MAXDOP 句をインデックスのデータ定義言語 (DDL) ステートメントに指定できるようになりました。この句を指定すれば、ステートメントで使用する並列操作の数を制御できます。旧バージョンの SQL Server では、MAXDOP をインデックスの DDL ステートメントに指定することはできませんでした。そのため、大規模なインデックス操作によって、データベース エンジン インスタンスのパフォーマンスが悪影響を受けることもありました。
詳細については、「並列インデックス操作の構成」を参照してください。