2015年8月に、SQL Server 2016の新しいストレッチデータベース機能を紹介する記事を書きました。その記事では、SQL Server 2016 Community Technology Preview 2(CTP2)でストレッチデータベースを使い始める方法について説明しました。 SQL Server 2016は2016年6月1日にリリースされ、製品には多数の更新がありました。 Stretch Databaseの設定方法と、一部の機能が少し変更されました。
SQL Server 2016以降、データベースの一部をAzureSQLデータベースに格納できるようになりました。データベースに対してStretchを有効にした以前のプレビューでは、テーブル全体を移行する必要がありました。SQLServer 2016のRTMリリースでは、テーブルの一部を選択できるようになりました。テーブルのストレッチを有効にすると、データがサイレントに移行されます。 Stretch Databaseに慣れていない場合は、Azureの処理能力を利用して、クエリを書き換えることにより、リモートデータに対してクエリを実行します。自分の側でクエリを書き直す必要はありません。これは、クエリプランの「リモートクエリ」演算子として表示されます。
Stretch対応の対象となるデータベースとテーブルを特定する簡単な方法は、SQL Server 2016 Upgrade Advisorをダウンロードして実行し、StretchDatabaseAdvisorを実行することです。 Aaron Bertrand(@AaronBertrand)は、しばらく前にこれについて書いています。アップグレードアドバイザーは、アーロンの投稿以降少し変更されていますが、プロセスはほとんど同じです:
- SQLServer2016ストレッチデータベースの候補テーブルを特定する
ストレッチデータベースの制限
すべてのテーブルがストレッチ対応の対象となるわけではありません。次のような特定のテーブルプロパティ、データと列のタイプ、制約、およびインデックスはサポートされていません。
- メモリ最適化および複製されたテーブル
- FILESTREAMデータを含むテーブルは、変更追跡または変更データキャプチャを使用します
- タイムスタンプ、sql_variant、XML、地理などのデータ型
- 制約を確認またはデフォルト設定
- テーブルを参照する外部キー制約
- XML、フルテキスト、空間、またはクラスター化された列ストアインデックス
- テーブルを参照するインデックス付きビュー
- ストレッチが有効なテーブルでUPDATEまたはDELETEステートメントを実行したり、CREATEINDEXまたはALTERINDEX操作を実行したりすることはできません
制限の完全なリストについては、StretchDatabaseの要件と制限を参照してください。
ストレッチデータベースの設定
RTMリリースの開始は、以前のプレビューとは少し異なります。 Azureアカウントが必要です。次に、ローカルインスタンスでStretchDatabaseを有効にする必要があります。
インスタンスでStretchDatabaseを有効にするには、次のコマンドを実行します。
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
このデモでは、STRETCHと呼ばれる作成したサンプルデータベースを使用します。まず、データベースを右クリックし、[タスク]、[ストレッチ]の順に選択してから、[有効にする]を選択しました。これはSQLServer2016ManagementStudioを使用していました。
次の画面には、ストレッチを有効にするテーブルが表示されます:
SALES2テーブルを選択しました。ウィザードのデフォルトは「テーブル全体」ですが、そのオプションを変更して行のサブセットを移行することもできます。
行で選択する場合は、条件の名前を選択する必要があります。次に、whereステートメントで使用する列、および条件と値を選択できます。このスクリーンショットでは、2016年より前に行を選択しました。テーブルの一部を選択できることは、テーブル全体を拡大することしかできなかった以前のプレビューよりも大幅に改善されています。簡単にするために、このデモではテーブル全体を移行するので、[キャンセル]、[次へ]の順にクリックしました。
テーブルと条件を選択したら、使用するAzureサブスクリプション、Azureリージョン、およびサーバー情報を選択する必要があります。
必要な情報を入力したら、[次へ]をクリックします。
新しい拡張機能は、データベースマスターキーを使用して、Azureに接続するためのAzureクレデンシャルを保護することです。マスターキーをまだお持ちでない場合は、作成するように求められます。マスターキーを既にお持ちの場合は、パスワードを入力する必要があります。 [次へ]をクリックします。
サーバーのファイアウォールルールを作成する必要があります。または、サブネットIP範囲を入力することもできます。選択して[次へ]をクリックします。
これは物事が本当に変わったところであり、私はこの機能の使用を再考するでしょう。 Microsoftは、データベースストレッチユニット(DSU)を作成しました。これにより、ストレッチデータに必要なパフォーマンスのレベルをスケールアップまたはスケールダウンできます。 2016年6月の時点で、現在の料金はコンピューティングとストレージの両方に対して請求されています。これは上の画像に示されています。移行された15MBのテーブルの場合、ストレージに月額$ 61 USDが請求され、最小DSUレベル(100)は月額$912.50になります。 DSUレベルの範囲は次のとおりです。
DSUレベル | 時間コスト | 最大月額費用 (31日で月) |
---|---|---|
100 | $ 1.25 | $ 930 |
200 | $ 2.50 | $ 1,860 |
300 | $ 3.75 | $ 2,790 |
400 | $ 5.00 | $ 3,720 |
500 | $ 6.25 | $ 4,650 |
600 | $ 7.50 | $ 5,580 |
1000 | $ 12.50 | $ 9,300 |
1200 | $ 15.00 | $ 11,160 |
1500 | $ 18.75 | $ 13,950 |
2000 | $ 25.00 | $ 18,600 |
6月の価格表に900ドル(または6月の残り日数に基づいて比例配分)と表示されているのに、ウィザードが912.50ドルしか表示しないのはなぜですか?あなたの推測は私のものと同じくらい良いです。私はいろいろな数学を試しましたが、空白になりました。価格設定モデルについて詳しくは、こちらをご覧ください:
- SQLServerストレッチデータベースの価格
DSUのこの新しい課金方法について学ぶ前に、Stretch Databaseを使用することは、コールドデータ(未使用データ)をクラウドに保存するための非常に費用効果の高い方法であると主張することができました。このデータをAzureに拡張することで、古いデータの大部分を移行できます。これにより、ローカルバックアップのサイズ(したがってコスト)が削減されます。データベースを復元する必要がある場合は、拡張されたデータのAzureへの接続を確立するだけでよいため、データベースを復元する必要がなくなります。ただし、ローエンドのDSUスケールの最小コストは月額1,000ドル近くであるため、多くの組織は、データセンター内のより安価なストレージ階層にデータを保持する方がはるかに安価であり、次のようなHAの他の方法を見つけることができます。ミラーリング、ログ配布、または可用性グループ。
[完了]をクリックして移行を開始します。
おめでとうございます。SALES2テーブルをAzureSQLデータベースに移行しました
ストレッチテーブルを無効にする
Stretch Databaseの初期のプレビューでは、Stretchテーブルを無効にする場合は、新しいテーブルを作成して、そのテーブルにストレッチデータを挿入する必要があります。すべてのデータがコピーされたら、テーブルの名前を変更して手動で切り替えるか、引き伸ばされたデータを手動で本番テーブルにマージする必要があります。 RTMリリースでも、手動で移行を処理したり、データをAzureに残すことを選択したり、Azureからデータを戻すオプションを選択したりできます。
データを戻すために使用する方法に関係なく、データ転送料金が発生します。
ストレッチデータベースのバックアップと復元
データをStretchデータベースに移行すると、AzureがStretchデータのバックアップを処理します。バックアップは8時間ごとにスナップショットを取得して実行され、スナップショットは7日間維持されます。これにより、過去7日間で最大21ポイントの時点で復元できます。
現在のローカルバックアップルーチンに変更を加える必要はありません。取得されるローカルバックアップには、まだ移行されていないすべてのローカルデータと適格なデータが含まれます。これはシャローバックアップと呼ばれ、Azureに既に移行されているデータは含まれていません。
DBCC CHECKDB
また、Azureに移行されたデータに対してCHECKDBを実行することはできません。
移行前にSTRETCHデータベースでDBCCCHECKDBを実行すると、SALES2テーブルに対して次の結果が得られました。
'SALES2'のDBCC結果。オブジェクト"SALES2"の1901ページには45860行あります。
移行後、SALES2テーブル(強調鉱山)について次の出力を受け取りました:
'SALES2'のDBCC結果。Azure SQLDatabaseに対してDBCCCHECKDBを実行できますが、拡張されたAzure SQLデータベースに直接接続できないため、現在、拡張されたデータに対してDBCCCHECKDBを手動で実行することはできません。 Azureがこれらのデータベースに対して整合性チェックを実行していることを示すドキュメントが見つかりません。
これは私の意見では重大なリスクをもたらします。
概要
データベースがサポートしている場合、StretchDatabaseはアーカイブデータをMicrosoftAzureに移行する簡単な方法です。現在、SQL Server 2016 RTMには、テーブル、データ、および列のプロパティ、データと列のタイプ、制約、およびインデックスに関する多くの制限があります。これらの制限に制限されていない場合、StretchDatabaseは履歴データをAzureSQL Databaseに移行する簡単な方法であり、ローカルストレージを解放し、費用に見合う価値がある場合はこれらのデータベースの復元時間を短縮します。また、少なくとも今のところ、移行されたデータに対してDBCCCHECKDBを実行できないことに慣れている必要があります。 SQL ServerデータベースとリモートAzureデータベース間の接続を復元する必要があるため、復元の管理も少し難しくなります。