ベストプラクティスガイド： Microsoft SQL Server...

ベストプラクティスガイド：

Microsoft SQL ServerのためのNimble

Storageベストプラクティス

N I M B L E S T O R A G E ベストプラクティスガイド：M I C R O S O F T S Q L S E R V E R 2

まとめ

Microsoft SQL Serverデータベースは、ミッションクリティカルなアプリケーションにデータ

の格納場所を提供します。したがって、これらのアプリケーションを保護し、トランザクシ

ョン処理におけるデータの整合性と可用性を確保することが重要です。Nimble Storageは、

I/O最適化機能およびデータ保護機能を提供し、SQL Serverの実装に大きなメリットをもたら

します。

まず、SQL Serverがデータをディスクに保存するときの内部I/O処理を理解することが重要で

す。この基礎知識をもとに、データベースストレージ設計の準備にベストプラクティスを適

用することができ、性能を最適化したりデータベースバックアップウィンドウを除去するこ

とができます。また、これらのベストプラクティスを使うことで、ユーザーエラーやシステ

ム障害が発生した後、フルデータベースだけでなく個々のデータベースオブジェクトおよび

データの目標回復時間（ＲＴＯ）を飛躍的に短くします。

SQL Serverのディスクへのデータ書き込み方法

データベースの基本

データベースは、主に行に格納されたデータのテーブルから成ります。各列は、行内の特定

のフィールドを表します。各行は、テーブルの設計に基づき、テーブル内の1つのレコード

を表します。例えば、顧客テーブルの基本設計には、顧客の氏名と顧客IDなどの固有のイン

デックスが含まれ、同じ名前（John

Smithなど）の顧客を区別します。列は、

顧客ID、名、氏となり、各行は単一の顧

客を表します。

データベースは、一般的に数十から数百

のテーブルで構成されおり、それぞれの

テーブルには顧客、製品、注文など特定

の情報が保存されています。データをテーブルに追加するにつれ、データベースは徐々に大

きくなっていきます。エンドユーザーに最速のレスポンスタイムを提供し、データ資産の損

失を防ぐためには、データベースの計画およびモニタリングを行うことが大切です。

ログ先行書き込み（WAL:Write-Ahead Loging）

データ損失のリスクを低減するために、Microsoft SQL Serverは、主要なデータベースプラッ

トフォームで一般的であるログ先行書き込み（WAL）アルゴリズムを使用して、データをデ

ィスクに書き込みます。このアルゴリズムは、フェイルセーフ処理として設計されています。

この処理では、相互に関連するデータベースの変更が、どこか一か所の変更に失敗した場合

には取り消すことができる一連の更新動作として、一貫性を持って書き込まれるようにしま

す。WALは、トランザクションログファイルを書き込み処理に使用し、実行されるデータベ

ース更新の証拠として機能します。また、保護層を使用してデータが信頼性を確認するため

にデータベースファイルとログファイルの2つのファイルのデータが一致することを確認し

ます。

顧客テーブル

顧客 ID 名氏

89437392 John Smith

27485839 Diane Jones

75839544 Ellen Davis

33258837 John Smith

61382475 Roger Williams


例えば、顧客の口座残高を含む銀行データベ

ースがあると仮定します。顧客のうち二人の

口座に$100があり、その顧客の一人が$50を

他の顧客に送金したいとします。SQL Server

は、2つのステップを含むデータベーストラ

ンザクションログファイルにエントリを作成

します。1つ目のステップは最初の顧客から

の$50の引き落としで、2つ目のステップは他

の顧客への$50の振り込みとなります。SQL Serverがオペレーティングシステムにそのトラン

ザクションを書き込むように指示するとき、ハードウェアがメモリにその書き込みをキャッ

シュしないようにし、ディスクに直接書き込まれるようにします。トランザクションログの

書き込みが完了した後、SQL Serverは、データベースファイルをアップデートし、最初の顧

客の新しい残高$50を反映してから、2番目の顧客のデータベースファイルを$150にアップデ

ートします。

これらのSQL Serverのデータベースの書き込み中にシステムがクラッシュした場合、データ

ベースエンジンは、トランザクションログを使用して、部分的な書き込みのすべてを取り消

し、トランザクションの書き込みを正常に完了させます。送金の例で説明すると次のように

なります。データベースが再起動すると、まず、トランザクションがデータベースファイル

に部分的に書き込まれているかどうか確認します。最初の顧客から$50が引き落とされてい

ますが、2番目の顧客に$50が振り込まれていないことが示されています。SQL Serverは、ロ

グに記録されたトランザクションを使用して、2番目の顧客の口座に$50を振り込み、送金を

完了します。データベースエンジンがこのアルゴリズムを使用しなければ、システムクラッ

シュによって、一人の顧客は$50を損失し、両方の顧客はお金がどこに消えたのか疑問に思

うことになります。したがって、ログ先行書き込みアルゴリズムは、データベースアプリケ

ーションのアプリケーション整合性を確保するための重要な機能を提供します。

SQL Serverファイル書き込み

SQL Serverがトランザクションログまたはデータベースファイルへの更新を書き込むとき、

システムの性能と柔軟性のバランスをとるために、データの固定長ブロックを使用します。

SQL Serverが使用する書き込みの最小単位は、

テーブルから1行以上を含むことができる

8KBサイズのページです。例えば、顧客のデ

ータベースに行を一つ追加すると、SQL

Serverは、まず、8KBページをトランザクシ

ョンログファイルに書き込み、その後、レ

イジーライターまたはチェックポイント処

理を使用して、その8KBの変更をデータベー

スファイルに書き込みます。バックアップ

またはMicrosoft VSSスナップショットが実行

されると、SQL Serverは保留中の変更の書き

込みを実行し、データページをディスクに退避します。これにより、バックアップまたはス

ナップショットが発生する前に、データベースをバックアップするのに安全な静止状態にし

ます。


ストレージレイアウトのベストプラクティス

Nimble Protection Manager（NPM）の使用

Nimble Protection Manager（NPM）は、Nimble StorageとWindowsオペレーティングシステムに

備わっているVSSインターフェース間のインターフェースを提供します。このインターフェ

ースは、アプリケーションデータをバックアップやリカバリに安全な整合性の取れた状態に

し、停電またはユーザーエラー後にデータベースを安全に起動してデータをリカバリすると

き、SQL Serverが読み込めて信頼できるデータのフォーマットを保証します。Nimble

Protection Managerは、Nimble Storageサポートウェブサイトからダウンロードできます。

サーバは、システムステータスとデータ更新をストレージデバイスに継続的に書き込みます。

後で行われるスナップショットへの復元で、アプリケーションが正常に動作し続けることが

できるように、スナップショットが取られるとき、保留中の書き込みがディスクに退避され

て、ボリュームが整合性の取れた状態で静止されていることが重要です。主な2つの整合状

態は、クラッシュの整合性（crash consistent）とアプリケーションの整合性（application

consistent）です。

クラッシュの整合性は、一般に、システムがクラッシュしたのちオペレーティングシ

ステムを起動し、システムのファイルと基本機能が問題なく読み込み可能な状態で立

ち上がる能力を意味します。

アプリケーションの整合性では、追加の手順をとりアプリケーションのデータの安全

を確保します。これは、Microsoft™ SQL Serverなどのデータベースアプリケーションに

ついて述べるときにトランザクションの整合性とも呼ばれています。

Nimble Storageでストレージを準備するとき、1つ以上のスナップショットなどのデータ保護

のスケジュールを選択し、ある時刻のデータが保護される間隔を指定します。スケジュール

された時間がくると、NimbleアレイはVSSを使用して、Nimble Protection Managerにデータベ

ースの静止点を調整します。すべての書き込みが静止されたあと、アレイがスナップショッ

トを実行します。

別々のボリュームにデータベースとトランザ

クションログファイルを保存

Nimble Storageには冗長ハードウェアがあり、

設計により高可用性となっています。また、

Nimble Storageアレイには、I/Oの使用パターン

をアクティブに分析する高性能自動チューニ

ング機能が備わっています。Nimble Storageが

ファイル内にホットスポットを検出すると、

それらを最適化し、ソリッドステートディス

ク(SSD)を使用して読み込み負荷が高い位置の

データをキャッシュします。データベースと

トランザクションログは異なる動作特性を有しており、それぞれのチューニングが異なるの

で、別々のボリュームに分ける必要があります。例えば、トランザクションログは大量のシ

ーケンシャルな書き込み動作を含み、一方で、データベースファイルはランダムな読み込

み・書き込み動作を含みます。


SQL Serverパフォーマンスポリシーの使用

Nimble Storageには、それぞれの使用目的に

合わせて最適化した設定を新規ボリューム

へ設定する事前にインプリメントされたパ

フォーマンスパラメータプロファイルが含

まれています。例えば、SQL Serverパフォー

マンスポリシーは、最適なブロックサイズ

を使用して、SQL Serverのトランザクションログとデータベースボリュームにとって最適な

パフォーマンスを提供します。図で見られるように、SQL Serverパフォーマンスポリシーに

は、インライン圧縮と高性能キャッシュも含まれます。

データ保護（ＰＲＯＴＥＣＴＩＯＮ）テンプレートの使用

Nimble Storageは、スナップショット、レプ

リケーション、保管期間のポリシーを事前に

インプリメントしてあるスケジュールを含む

データ保護テンプレートを提供します。新規

のボリュームコレクション（ボリュームの集

合）を作成するとき、既存のビジネスルール

に基づいて、デフォルトのスケジュールの

データ保護テンプレートを選択することがで

きます。例えば、アプリケーションデータの

重要性に基づいてデータ保護テンプレートを

作成できます。ミドルウェアサーバなどの重要性の低いアプリケーションは、スナップショ

ットの間隔が長いスケジュール（4時間）と保管期間が短いスケジュール（10日）を使用で

きます。しかし、データが頻繁に変更されているデータベースなど、より重要なアプリケー

ションでは、通常、スナップショットの間隔が短いスケジュール（15分以下）と保管期間の

長いスケジュール（90日間）が必要となります。このような場合、スナップショットの間隔

が短いスケジュールと保管期間の長いスケジュールのデータ保護テンプレートを使用します。

データ保護テンプレートの使用は、ストレージボリュームを作成するのに必要な作業量を削

減し、類似したアプリケーションを管理する際に一貫性を提供します。

ボリュームコレクション（ボリュームの集合）の使用

ボリュームコレクションの定義の中で、スナップショ

ットの頻度、保管、および他のNimble Storageへのレプ

リケーションをスケジュールできます。ボリュームコ

レクションは、データベースのトランザクションログ

やデータベースファイルボリュームなど、別々のボリ

ューム間のデータ保護動作を同期させることができ、

アプリケーションの整合性を取った状態でデータベー

スがスナップショットできます。ボリュームコレクシ

ョンは、Microsoft VSSと統合され、SQL Serverで保留中


のデータベースの書き込みをディスクに退避させ、トランザクションログとデータベースフ

ァイルの書き込み動作を停止して一瞬静止状態にします。これは、ある時刻のスナップショ

ットバックアップのデータの整合性を確保します。

ボリュームコレクションの管理により、関連したすべてのボリュームのデータ保護スケジュ

ールを容易に変更できるようになります。例えば、eコマースアプリケーションに対応して

いるSQL Server上で、いくつかのデータベースにSQL Serverデータベース保護スケジュールを

作成したとします。データベースは、性能特性が異なる別々のデータファイルに配置される

のが一般的です。初期のビジネス要件は、バックアップ用の1時間毎のスナップショットと、

ディザスタリカバリのための6時間毎のオフサイトレプリケーションに基づいた設定を必要

としていました。ビジネスが拡大するにつれ、データベースがより重要になってくるため、

管理者は、データ損失のリスクを低減するため、より頻繁なバックアップとレプリケーショ

ンが必要であると判断しました。ボリュームコレクションのプロパティを変更することによ

り、データベースの関連ファイルすべてのデータ保護スケジュールを同時に変更できます。

これにより、時間も節約して、リカバリの妨げになる設定エラーも排除できます。

ソフトウェアおよびSQL Serverスナップショットよりハードウェアスナップショットが適切

スナップショットは、それを元にしてある時刻のイメージを作成することができ、他のiSCSI

ボリュームのようにマウントしてアクセスできるストレージボリュームでありバックアップ

でもあります。仮想化アーキテクチャの異なる層（ゲストソフトウェア、ホストソフトウェ

ア、およびストレージハードウェアなど）でスナップショットを作成できます。データボリ

ュームをゲストＯＳに直接接続することにより、NPMが非効率的なソフトウェアベースのス

ナップショットではなく、Nimble Storageハードウェア機能によるスナップショットを実行で

きるようになります。

Nimble Storageは、Nimbleのインライン圧縮およびブロック単位差分管理の効率によって最適

化された非常に効率的なハードウェアスナップショット機能を提供します。これは、

Microsoft™ VSSなど、オペレーティングシステムに備わっているソフトウェアスナップショ

ットとは異なります。そのようなソフトウェアスナップショットはボリュームに効率的に保

存されません。ソフトウェアスナップショットは、Nimble Storageの最適化されたスナップシ

ョットバックアップ機能を活用していません。下記の図は、スナップショットが保存されて

いる異なる場所を示しています。柔軟性が極めて低いソフトウェアスナップショットを実行

するのではなく、性能、インライン圧縮、およびクローニング機能を利用したNimble Storage

で、ハードウェアベースのスナップショットを使用するのが好ましいです。


SQL Server 2005 Enterpriseから始まる、SQL ServerもSQLスクリプトスキルを必要とするスナッ

プショット機能を搭載しています。SQL Serverアプリケーションに備わっているスナップシ

ョットのこれらのタイプは、データベースファイル内に保存され、Nimble Storageのスナップ

ショットバックアップと比較して非常に効率の低いコピーオンライト方法を使用しています。

Nimble Storageを使用することにより、データベース管理者は、データベーススナップショッ

トをより詳細なリカバリポイントでの作成を実行できます。これらは、SQLに備わっている

スナップショットで使用可能なリカバリ方法と同じ方法が使えます。復旧、レポート、その

他の用途へのNimbleアレイスナップショットの使用については、「向上したSQL Serverの回復」

のセクションで説明しています。

向上したSQL Serverのバックアップ

SQL Serverデータベースは、システム障害からデータ保護するためにログ先行書き込みを使

用し、Nimble Storageはストレージ障害からデータ保護するためにハードウェアが冗長になっ

ています。しかし、データベースは、データの誤削除など理論障害から保護するために、

時々バックアップされる必要があります。SQL Serverは、バックアップのために機能をいく

つか提供していますので、サービスの停止を避けるために、強化されたスナップショットバ

ックアップにNimble Storageを活用できます。

下記のタイムラインとグラフは、異なるSQL Serverバックアップの相対的な影響とデータベ

ース障害後の復旧方法を示しています。これらは、データベースの完全なサービス復旧に関

するリカバリポイントと復旧時間です。これらのタイムラインは、ハードウェア、オペレー

ティングシステム、およびアプリケーションソフトウェアが停電によって影響されないもの

とし、また、論理障害（テーブルまたはファイルの誤削除など）が原因でデータベースに障

害が起こったものと仮定しています。システム負荷評価基準は、バックアッププロセスに関

係するサービス実行システム全体から成り、CPU、メモリ、システムバス、ネットワーク、

およびストレージサブシステムなどが含まれます。サービス実行データベース処理は、バッ

クアッププロセスによって行われるシステム負荷と競合するため、トランザクション処理の

パフォーマンスを低下させます。

ディスクまたはテープへのSQL Serverバックアップ

Traditional Backup to Disk/Tapeタイムラインは、典型的な日次バックアップスケジュールを示

しています。ここでは、データベースの日次フルバックアップを実行したあと、1時間毎に

トランザクションログバックアップが行われています。全部のデータベースとトランザクシ

ョンログがバックアップディスクまたはテープデバイスにコピーされるフルバックアップ中


は、システム負荷が高くなるのがわかります。その後、1時間ごとにトランザクションログ

のバックアップをコピーするときにピークが起こります。最後に、トランザクションログは、

フルバックアップまたはトランザクションログのバックアップのいずれかの完了時に消去さ

れます。

データベースの復旧は、一番最近のフルバックアップの復旧から始まり、続いて各トランザ

クションログのバックアップの復旧が行われます。復旧時間は、すべてのデータベースオブ

ジェクト（テーブル、インデックス、セキュリティなど）がバックアップメディアからサー

バにコピーされる必要があるため、かなり長くなります。したがって、バックアップに5時

間かかる場合は、復旧にも少なくとも5時間かかります。トランザクションログは累積され

るので、前のログが復旧を完了するとすぐに次のログが復旧されます。

Nimble Storageを使用したSQL Serverバックアップ

Nimble Storageは、サービス実行システムへの影響を最小化して、データベーススナップショ

ットのフルバックアップを実行するように最適化されています。Nimbleは、Nimble Protection

Manager（NPM）を使用してMicrosoft VSSと統合し、データベースに保留中のデータベース書

き込みをディスクに退避するよう定期的に要求します。その後、アレイは最適化されたスナ

ップショットを作成します。Nimble Storageスナップショットを使用したデータベースの回復

は非常に速い処理で、この処理では管理者がスナップショットのクローンを作成し、それを

データ復旧のために直接マウントします。


SQL Serverデータベースリカバリモデル

SQL Serverデータベースリカバリモデルは、データベースの管理を簡素化するために作成さ

れました。リカバリモデルは、バックアップ処理に影響を与えるため、それらを理解するこ

とが重要です。フル（Full）、一括ログ（Bulk-Logged）、およびシンプル（Simple）という3

つのリカバリモデルが使用可能です。リカバリモデル間の主な違いは、トランザクションが

ログされるかどうかと、チェックポイントが発生したときにトランザクションログの切り捨

てをしているかどうかです。すべてのデータベースの変更がディスクに書き込まれた後、チ

ェックポイントがトランザクションログにマークされます。

シンプルリカバリモデルデータベースのNimbleスナップショットバックアップ

多くのSQL Serverのデータ保護シナリオの場合、シンプル

リカバリモデルは、管理の簡単さとデータ保護の最適な組

み合わせを提供します。シンプルリカバリモデルは、トラ

ンザクションをログし、それらをチェックポイントが発生

するまで保持します。その後、チェックポイントまでのト

ランザクションログを切り捨て、制御不能になるのを防ぎます。シンプルリカバリモデルは、

バックアップ間で発生したトランザクションの復旧ができないため、このリカバリモデルを

使用すると、一部のデータが損失されることがあります。Nimbleスナップショットバックア

ップは、ほぼ瞬時にデータベースのフルバックアップを行います。また、ログが定期的に切

り捨てられるため、メンテナンスフリーのSQL Serverデータベースバックアップを提供しま

す。SQL Serverシステムデータベース（マスター、モデル、MSDBなど）は、デフォルトでシ

ンプルリカバリモデルを使用するように設定されています。図は、15分間隔の全データベー

スのNimbleスナップショットバックアップを示します。定期的な短い間隔でのNimbleスナッ

プショットバックアップの使用は、扱いやすさと、可能な限り短い時間で非常に粒度の細か

いある時刻での復旧を良いバランスで提供します。お客様のデータベースが、Nimbleスナッ

プショットバックアップ間で発生した最新のトランザクションの損失を許容できない場合、

SQL Serverフルリカバリモデルを使用する必要があります。

すべてのトランザクシ

ョンがログされる。

ログはチェックポイン

トで切り捨てる。

N I M B L E S T O R A G E ベストプラクティスガイド：M I C R O S O F T S Q L S E R V E R 1 0

フルリカバリモデルデータベースの保護

最新のスナップショットのあとに発生したトランザク

ションの回復が必要な場合、フルリカバリモデルを使

用して、SQL Serverのツールで定期的にフルバックアッ

プとトランザクションログバックアップを実行します。

SQL Serverに備わっているバックアップツールは、SQL

Serverのツールによるフルバックアップとそれに続くトランザクションログバックアップ

（ログ末尾を含む）の回復を可能にしています。お客様のデータベースソフトウェアのバー

ジョンのMicrosoft SQL Serverのドキュメントを参照してください。SQL Server 2008 R2のドキ

ュメントは下記のリンクにあります。

（http://msdn.microsoft.com/en-us/library/ms190217.aspx）

SQL Serverのツールによるバックアップに加え、Nimbleスナップショットバックアップを使用

して、ディザスタリカバリのためのレプリケーション機能を提供します。

バルクログリカバリモデルデータベースのNimbleスナップショットバックアップ

バルクログリカバリモデルは、主に膨大なデータをデータベースにできるだけ速く挿入する

ために使用されます。このモデルは、データマートおよびデータウェアハウスの大規模デー

タベース（LDB）などのオブジェクトに使用されます。バルクログバックアップは、SELECT

INTO、CREATE INDEXなどのデータベース動作やテキストおよびイメージ動作のトランザクシ

ョンログ書き込みを避けることにより、速く実行でき

るようにもなります。バルクログ実行中に何らかの理

由でデータベースが破損した場合、作業をやり直す必

要があることがあります。この理由から、このモデル

は大規模データベースアプリケーション以外であまり

使用されません。バルクログ実行中のエラーの影響を最小限に抑えるため、いつもバルクロ

グリカバリモデルになっていない場合は、お客様のデータベースが使用しているリカバリモ

デルを使用して、必ずバックアップを実行する必要があります。

すべてのトランザクショ

ンがログされる。

チェックポイントでログ

を切り捨てない。

一部のトランザクション

がログされる

チェックポイントでログ

を切り捨てない

http://msdn.microsoft.com/en-us/library/ms190217.aspx


向上したSQL Serverのリカバリ

データの復旧でバックアップソリューションの真価が問われます。特に、どのくらい速くデ

ータを回復して、オンラインに戻せるかが大切です。「向上したデータベースバックアップ」

のセクションで示されているように、Nimble Storageは、短くて定期的な間隔でほぼ瞬間的に

データベースのフルバックアップを行うことができます。Nimbleアレイは、ゼロコピークロ

ーンを作成して、それをSQL Serverホストにマウントすることにより、データを回復できる

ようにします。ゼロコピークローンは、瞬時の極めてスペース効率の良いサービス実行デー

タベースの‘クローン’を提供します。これらのクローンは、オリジナルのデータベースの完

全に読み込み・書き込み可能なコピーですが、Nimbleの効率的なクローニング技術のおかげ

で、ストレージ容量をほとんど消費しません。Nimble Storage CSシリーズ管理者ガイドの

「Nimbleアレイスナップショットを使用してSQL Serverデータベースを回復する」のセクショ

ンで、復旧のためのクローンを作成する手順を説明しています。クローンの使用により、復

旧や、お客様の企業内でNimble Storageをその他の

用途で最大限に活用することもできます。

フルデータベース復旧を実行する予定がある場合、

復旧したい既存のデータベースをデタッチできます。

データベースとトランザクションログファイルをク

ローンされた復旧ボリュームからサービス実行ボリ

ュームにコピーし、既存のファイルを上書きします。

回復したデータベースをアタッチして作業を続けま

す。

より高度なデータベースオブジェクトレベルの復旧

機能の場合、サービス実行データベースをそのまま

に、リカバリデータベースをクローンされた復旧ボ

リュームから一時的にアタッチできます。SQL

Server Management Studioを開き、ツールバーのNew

Queryボタンをクリックします。その後、下記のSQL

Serverコマンドを使用して、サービス実行データベ

ースとは異なる名前（RecoveryDB）の付いたリカバ

リデータベースをアタッチします。

CREATE DATABASE RecoveryDB

ON

(NAME = RecoveryDB, FILENAME =

'E:\SQL Server\Databases\ProductionDB.mdf'),

(NAME = RecoveryDB_Log, FILENAME =

'M:\SQL Server\Transaction Logs\ProductionDB_log.ldf')

FOR ATTACH

データベースオブジェクトの復旧

このシナリオを使用して、テーブルの切り捨てや保存された手順の削除など、誤りのあるデ

ータベースオブジェクトから回復します。SQLクエリーを使用して、データベースオブジェ

クトをクローンされたリカバリデータベースからサービス実行データベースにコピーします。

例：

insert into ProductionDB.dbo.Catalog

select * from RecoveryDB.dbo.Catalog


データ復旧

これは、データベースオブジェクトの復旧と同様に機能しますが、ユーザーエラーによって

損失した特定のデータポイントを復旧するSQLクエリーを使用します（例えば、ERPまたは

CRMデータベース内でのオーダーの誤削除の最新のスナップショットバックアップからの回

復など）。

update ProductionDB.dbo.Customer

set LastName = (

select LastName

from RecoveryDB.dbo.LastName

where CustomerID = 8309485)

where CustomerID = 8309485

レポートサーバの負荷軽減

多くの企業では、データベースが徐々に増大す

るにつれ、レポート機能の必要性が、システム

の実際のサービス使用による処理やストレージ

リソースに悪影響を及ぼしています。定期的に

実行されたり、一時的に実行されるレポート機

能を他のサーバに分離して任せることは、シス

テムリソースをめぐる競争を減らし、サービス

実行システムの耐用年数を延長します。また、

エンドユーザーにより速いレスポンスタイムを

提供して生産性を高めます。サービス実行デー

タベースのボリュームクローンを作成して、レ

ポートサーバにアタッチします。この用途では、

NimbleのWAN最適化レプリケーション技術を使

用してオフサイトレポート機能も提供していま

す。このレプリケーション技術は、オフサイト

レプリケーションの総所有コスト（TCO）を飛躍的に削減します。

開発および品質保証試験

もう一つの人気の用途は、品質保証および開発試験にサービス実行データベースのクローン

を使用することです。このモデルは、Nimbleボリュームクローンが他のサーバにアタッチさ

れるというような、レポートサーバの負荷軽減と類似していますが、レポートサーバよりも

少ない頻度でリフレッシュされます。データベースは、サービス実行データベースと同一の

コピーで、サービス実行システムに悪影響を及ぼすことなく、より完全な試験を可能にしま

す。


Nimble Storage, Inc.

2645 Zanker Rd., San Jose, CA 95134

Tel:877-3NIMBLE (1-877-364-6253) | www.nimblestorage.com | [email protected]

© 2011 Nimble Storage

Translated by Toshiba corporation nmblbpg003(140310)

ベストプラクティスガイド： Microsoft SQL Server...

Documents

Transcript of ベストプラクティスガイド： Microsoft SQL Server...