Azure SQL Data Warehouse （プレビュー版）がレジストされたので、こちらのファーストガイドを参照しながら、環境構築をして触り始めました。Azure SQL Data Warehouse については、概要を一度紹介済みなのでそちらを見てください。

もしくは、MSエヴァの井上さんがスライドにまとめているので、そちらを参照しても良いと思います。

レジスト完了のメール通知

Azure SQL Data Warehouseの登録が完了すると、メールが届きます。
プレビュー版では、レジストする Azure SQL Database のサーバーを個別指定して、レジストしてもらう流れになっています。

Azure SQL Data Warehouse サービスのプロビジョニング

次にポータルから、SQL Data Warehouse を追加します。

個別レジストなので、使用できるAzure SQL Database サーバーも限定されています。

SQL Data Warehouse が作成できたら、次に先ほど指定した Azure SQL Database サーバーのファイアーウォールにIPを指定して、アクセスできるようにします。

SQL Data Warehouse への接続

Azure SQL Data Warehouse に接続するには、SQL Server Data Tools (SSDT)のバージョン12.0.50623移行が必要です。

Visual Studio のSQL Serverオブジェクトエクスプローラーから、Azure SQL Data Warehouseに接続します。

資格情報を入力すると、接続できます。

もしくは、Azure PortalのVisual Studioで開くから、簡単に接続することもできます。

サンプルデータのインポート

サンプルデータをインポートします。

ここからサンプルデータをダウンロードします。ダウンロードしたAdventureWorksPDW2012.zipファイルを解凍します。解凍したファイルの中にある「aw_create.bat」を修正し、資格情報を入力します。

バッチをダブルクリックして実行します。
1分ぐらいはコマンドウィンドウに何も表示されませんが、気にせず待っていてれば進行します。

バッチが終了したらクエリを実行して、データインポートが完了しているか確認します。

SELECT * FROM DimEmployee;

投稿Azure SQL Data Warehouse 最初の一歩（データロードまで）は蒼の王座の最初に登場しました。

Azure SQL Database を使用する場合の推奨事項に、リトライロジックを組み込み、クエリ発行に失敗しても複数回リトライをするというものがあります。

実装方法としては、Entity Framework のリトライ機構を使用するか、自分自身で実装する方法の2種類あります。

今回紹介するのは、Azure のドキュメントに掲載されたサンプルです。MSDNのサンプルは、そこで説明したいことが明確になることを目的としていることが多く、そのまま使用できないことが多いです。しかし、今回紹介するのは、そのまま利用しやすいようになっています。

（発行クエリの定義方法については書き換えないと使えませんが。）

投稿Azure SQL Database へのクエリ発行サンプルプログラムは蒼の王座の最初に登場しました。

Azure SQL Elastic Database Poolでは、性能の下限と上限を選択し、突発的な負荷にも対応できるように柔軟な性能を得ることができます。詳細については、「Azure SQL DB – Elastic Database Poolについて」で紹介しています。

T-SQLでデータベースを作成する際に、Elastic Poolを指定できるようになりましたので紹介します。

SQL Elastic Database Poolの作成

今のところ、Elastic Database Pool事態は、事前にPortalで作成しておく必要がありそうです。T-SQLで、Elastic Database Poolを作成する構文はなさそう。

データベースの作成

CREATE DATABASE database_name
{
   ( [, ...n])
}
 ::=
{
      MAXSIZE = { 100 MB | 500 MB | 1 | 5 | 10 | 20 | 30 … 150…500 } GB
    | EDITION = { 'web' | 'business' | 'basic' | 'standard' | 'premium' }
    | SERVICE_OBJECTIVE = { 'shared' | 'basic' | 'S0' | 'S1' | 'S2' | 'P1' | 'P2' | 'P3' | { ELASTIC_POOL(name = ) } }
}

Elastic Database Poolに新しいデータベースを作成するためには、SERVICE_OBJECTIVEで、ELASTIC_POOL でプール名を指定します。次の例では、hogeがプール名となっており、「’」で括らずに指定します。

データベースの設定変更

ALTER DATABASE database_name
{
    MODIFY NAME =new_database_name
  | MODIFY (  [, ... n] )
  | COLLATE collation_name
  | SET {  }
}
 ::=
{
      MAXSIZE = { 100 MB | 500 MB |1 | 5 | 10 | 20 | 30 … 150 … 500 } GB
    | EDITION = { 'web' | 'business' | 'basic' | 'standard' | 'Premium' }
    | SERVICE_OBJECTIVE = { 'shared' | 'basic' | 'S0' | 'S1' | 'S2' | 'P1' | 'P2' | 'P3' | { ELASTIC_POOL(name = ) } }
}

Elastic Poolリソースの確認

論理サーバー上にあるすべてのElastic Database Poolの私用統計情報を返します。Elastic Database Pool毎に、5分間のCPU、IO、Log、ストレージ、リクエスト数、レスポンス数を提示します。

SELECT * FROM sys.elastic_pool_resource_stats
ORDER BY end_time DESC;

参考サイト

https://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-pool-reference/#_transact-sql Elastic Databasesにプールを追加したり、削除することができます。

CREATE DATABASE (Azure SQL Database)

https://msdn.microsoft.com/en-us/library/dn268335.aspx T-SQLで、Elastic Databases Poolを指定してデータベースを作成する

sys.elastic_pool_resource_stats (Azure SQL Database)

https://msdn.microsoft.com/library/mt280062.aspx 論理サーバー上にあるすべてのElastic Database Poolの私用統計情報を返します。Elastic Database Pool毎に、5分間のCPU、IO、Log、ストレージ、リクエスト数、レスポンス数を提示します。

投稿Azure SQL Database Elastic Poolの管理をT-SQLでするは蒼の王座の最初に登場しました。

SQL Server Data Tools （SSDT）は、Visual Studioに統合されたデータベースの開発支援ツールです。SQL Server Data Toolsのプレビュー更新2015年8月版では、インストーラーの変更とBusiness Intelligence（BI）ツールをVisual Studioに統合する機能追加がされました。

ダウンロード

概要

インストーラーが変更されてます

データベースツールは、SQL Server 2015からSQL Server 2016、Azure SQL Databasesをサポートしています。Business Intelligenceツールについては、SQL Server 2016には限定的な対応となっていますが、RTM時には対応します。

DBとBIに対応するインストーラーは、Visual Studio 2015のみの提供です。Visual Studio 2013に両方インストールするには、別々のインストーラー（SSDTとSSDT-BI）を使用してください。

参考サイト

投稿SQL Server Data Tools Preview アップデート（2015年8月版）リリースは蒼の王座の最初に登場しました。

SQL Server をコマンドラインで操作するためのコマンドsqlcmdとデータのバルクインサートをするためのコマンドラインツールbcpをLinuxで使用するための手順について説明します。

前提条件

• コマンド操作元として、Ubuntu 14.04
• 接続先として、SQL ServerかAzure SQL Database

インストール手順

インストールスクリプトをダウンロードします。

wget https://gallery.technet.microsoft.com/scriptcenter/SQLCMD-and-BCP-for-Ubuntu-c88a28cc/file/142121/1/Ubuntu%2014.04%20MSFT%20ODBC%20Driver.sh

SQLCMDとBCP、Linux ODBCドライバーをインストールします。

sudo bash Ubuntu\ 14.04\ MSFT\ ODBC\ Driver.sh 

ライセンス確認があるので、「YES」とタイプしておしまい。

利用手順

普通に使います。

sqlcmd -S xxxxxx.database.windows.net -U xxx -P xxxxxxxxx

bcp も同じですね。

参考リンク

投稿Linux（Ubuntu） で SQL Server の SQLCMD と BCP コマンド を使用するは蒼の王座の最初に登場しました。

Azure SQL Database で、elastic database query でいくつかの改善が発表されました。
今回の改善により、Azure SQL Database の elastic database quey は、垂直分割も水平分割も同じコンセプトで、同一表面上で実現できるようになりました。

• データベースをまたがったクエリのサポート改善
• Elastic Query がStandardとPremiumパフォーマンス帯で提供開始
• リモートデータベースのテーブル名やスキーマ名にエイリアスを設定できるようになった
• リモートテーブル参照時に、T-SQLパラメーターを含んだクエリ性能が改善
• リモートテーブルから多くの行を参照するクエリの性能改善
• sp_execute_fanoutプロシージャーでのパラメーターサポート

複数データベースへのクエリ発行

ローカルのテーブルとリモートのテーブルを結合して参照するクエリに対応しています。

複数のデータベースを参照して、データを参照する次の図のような構成も可能になりました。

従来から、Elastic Query が対応していた水平パーティ初認具のサポートも継続しています。

リモートテーブルへのクエリ発行方法

リモートにあるテーブルを参照する方法として、外部データソースを経由して指定します。
イメージ的には、リンクテーブルと同じような感じですね。
外部データソースの作成にはDDLを使用し、一つのデータベースのみを指定します。

CREATE EXTERNAL DATA SOURCE RemoteReferenceData
WITH
(
    TYPE=RDBMS,
    LOCATION=’myserver.database.windows.net’,
    DATABASE_NAME=’ReferenceData’,
    CREDENTIAL= SqlUser
);

リモートテーブルは外部テーブルで定義します。外部テーブルの定義には、外部データソースを指定します。

CREATE EXTERNAL TABLE [dbo].[zipcode](
    [zc_id] int NOT NULL,
    [zc_cityname] nvarchar(256) NULL,
    [zc_zipcode] nvarchar(20) NOT NULL,
    [zc_country] nvarchar(5) NOT NULL
)
WITH
(
    DATA_SOURCE = RemoteReferenceData
);

外部テーブルは、すべての読み取り専用のクエリを発行することができます。

投稿Azure SQL Database で複数データベースにまたがるクエリ発行は蒼の王座の最初に登場しました。

Azure SQL Database に追加されてた機能一覧と追加日をまとめています。新機能の追加情報を追っていくうちにどのような機能があり、正式リリースされたのかプレビューなのかがわからなくなります。
それらを一覧にまとめたので、理解するのに役立てば幸いです。

Azure SQL Database の更新タイムライン

• 2015/10月中　Always Encryptedがパブリックプレビューで公開された。（予定）
• 2015/10月中　Threat Detectionがパブリックプレビューで公開された。（予定）
• 2015/10月中　動的データマスキングが正式リリースされた。（予定）
• 2015/10/15　Elastic Database Query（プレビュー版）が改善されました。
• 2015/10/14　透過的データ暗号化が正式リリースした。
• 2015/10/12　フルテキスト検索がV12サーバーに正式リリースされた。
• 2015/10/12　拡張イベントがパブリックプレビューで公開された。
• 2015/10/12　行レベルセキュリティ ブロック述語がパブリックプレビューで公開された。
• 2015/10/05　Query Performance Insightがプレビューで公開された。
• 2015/09/23　Elastic Database Poolsのサービス帯が見直され改善された。
• 2015/09/17　Azure AD認証による接続機能がパブリックプレビューで公開された。
• 2015/09/16　Elastic Database Client Libraryがオープンソース化がされた。
• 2015/09/12　Web/Businessエディションのサービス帯提供が終了した。
• 2015/08/27　Elastic Database Poolsに新しいサービス帯が追加された。
• 2015/08/27　SQL DatabaseにP4、P11のサービス帯が追加された。
• 2015/08/20　行レベルセキュリティ機能が正式リリースされた。
• 2015/07/02　SQL Database Elastic Database queryがプレビューで公開された。
• 2015/07/02　Index Advisorがプレビューで公開された。
• 2015/06/24　Elastic Database Poolsの最少eDTUが100に変更された。
• 2015/05/28　SQL Database Query Storeがプレビューで公開された。
• 2015/05/06　SQL Database Elastic Database Toolsが正式リリースした。
• 2015/04/30　フルテキスト検索がプレビューで公開された。
• 2015/04/29　Elastic Database Poolがプレビューで公開された。
• 2015/04/29　透過的データ暗号化がプレビューで公開された。
• 2015/03/09　SQL Elastic Scaleプレビュー版が更新した。
• 2015/02/24　アジアリージョンでV12サーバーが正式リリースした。
• 2015/02/24　SQL DatabaseにS3のサービス帯が追加された。
• 2015/02/24　災害復旧目標が改善され、データロスト時間減少、再開までの時間短縮。
• 2015/02/18　動的データマスキングがプレビューで公開された。
• 2015/01/29　行レベルセキュリティがプレビューで公開された。
• 2015/01/29　ヨーロッパリージョンでV12サーバーが正式リリースした。
• 2014/12/11　V12サーバーがパブリックプレビューで公開された。

機能一覧

• Index Advisor
• Elastic Database Pool
• Azure AD認証
• Elastic Database Client Library
• SQL Database Elastic Database query
• SQL Database Elastic Database Tools
• SQL Database Query Store
• Elastic Database Pool （複数DBにまたがるクエリ発行）
• 透過的データ暗号化
• フルテキスト検索
• 動的データマスキング
• 行レベルセキュリティ / Block predicates (ブロック述語)
• 拡張イベント
• Query Performance Insight
• Always Encrypted
• Threat Detection

まとめ

V12サーバー がリリースされて、SQL Server との互換性が大きく向上したことで、SQL Server 2016 で開発された新機能がシームレスに投入できるようになりました。
その為、数多くの機能が追加されるようになり、一時期の停滞が嘘のように、機能が追加れて使いやすくなっています。
少し前までは、クラウド専用でクラウド用にカスタマイズされていたので、使いずらい部分がありました。
今では、SQL Server と高い互換性があるので、安心して利用することができます。

また、性能によるサービス帯提供となったことで、クラウドだからスケールアウトしましょうから、必要に応じて、スケールアウトとスケールアップを選択してくださいと言えるようになったのは素敵。
また、SaaSベンダー用に、スケールアウトさせたときに料金が抑えられるように、 Elastic Database Pool が発表されたのも採用障壁が下がりましたね。

投稿Azure SQL Database の機能一覧と履歴は蒼の王座の最初に登場しました。

Azure SQL Data Warehouseサービスは、数秒以内でコンピュートリソース量を動的に設定することができます。アサインするDWU（Data Warehouse Units＝コンピュートパワー）量の設定は、Azure Portalを開いて、データベースブレードを表示することで表示できます。

SQL チームは、DWU設定情報にプログラム的にアクセスすることができる新しいDMV（sys.database_service_objectives）を紹介します。論理サーバーのmasterデータベースに接続し、次のクエリを発行します。

SELECT
db.name [Database],
ds.edition [Edition],
ds.service_objective [Service Objective]
FROM
sys.database_service_objectives ds
JOIN sys.databases db ON ds.database_id = db.database_id

このクエリは、論理サーバー上のすべてのデータベースとサービスオブジェクト（DWU設定を含む）を返します。

この例では、3つのData Warehouseと1つのAzure SQL Databaseがあります。

SELECT
 db.name [Database],
 ds.edition [Edition],
 ds.service_objective [Service Objective]
FROM
 sys.database_service_objectives ds
 JOIN sys.databases db ON ds.database_id = db.database_id
WHERE
 ds.edition = 'DataWarehouse'

投稿SQL Data WarehouseのDWU設定をする方法は蒼の王座の最初に登場しました。

特徴

SQL Serverと100%に近い互換性があり、ネイティブでVNETに対応しています。
オンプレからクラウドへの移行を容易にします。
PaaSと同じインフラで、全てのPaaSの機能（自動バッチ、バージョンアップ、バックアップ、高可用性）を提供します。

・オンプレミスのSQL Server 2005から最新バージョンまで互換性があリます。
（バックポートして互換性を持たせたので、SQL Server 2005以降全てのバックアップファイルをリストアできます）
・通常のSQL Serverのリストアに対応
・SQL Agent
・SQL Profiler
・ログシッピング
・トランザクションレプリケーション
・データベースをまたぐクエリ
・Database Mail
・Service Brocker
・SQL CLR
・SSIS（もうまもなく）
・99.99% SLA
・自動バックアップ
・ポイントタイムリストア

細かい情報

Azure Database Migration Service(preview)

SQL Server からAzure SQL Database Managed Instanceに簡単に移行できるように設計されています。
DocuSignもこれを使って移行しました。

サービス帯

Public Preview中は、General Purposeが提供されます。
基本的な可用性、共通的なIOレイテンシーようです。

・基本的な性能要求と可用性
・Azure Premium Storage(8TB)
・１インスタンス100DB
・8/16/24 vCore
・ストレージは３２GB〜８TB
・500-7500IOPS/１データファイル
・１データベースのデータファイル数は複数
・ログファイルのデータファイルは１つ
・自動バックアップ
・可用性は、リモートストレージとAzure Service Fabric
・インスタンスとデータベースのモニタリングと計測
・自動パッチ
・監査ログ
・ポータル対応

メトリックス画面

監査ログと脅威分析

vCoreについて

vCore(Virtual Core)は、論理CPUで、２世代のハードウェアで提供されます。
・4世代：Intel E5-2673 v3 (Haswell) 2.4 GHz プロセッサー
・5世代：Intel E5-2673 v4 (Broadwell) 2.3 GHz プロセッサー

vCore、ストレージサイズのスケールアップダウンが必要に応じてできるようになっています。
(ポータルから設定できますが、ダウンタイムなどがあるのかは確認が必要ですねぇ)
データベースファルは全て分離されたPremiumストレージ上に配置されます。

オンプレミスとの違い

詳細な機能比較は、「こちら」

・可用性は組み込みで予め設定されています。Always On 可用性機能はSQL IaaS実装と同じ方法では公開されません。
・自動バックアップ、ポイントタイムリストア。バックアップチェインに影響与えない、コピー専用バックアップを出力できます。
・物理パスの指定ができません。Bulk insertはAzure Blobのみの対応です。
・Windows認証の代わりにAzure AD認証を提供します
・インメモリOLTPオブジェクトが含まれるXTPファイルグループとファイルは自動で管理します。

バックアップ

・Azure Blob認証

```
CREATE CREDENTIAL [https://myacc.blob.core.windows.net/testcontainer]
WITH IDENTITY='SHARED ACCESS SIGNATURE'
, SECRET = 'sv=2014-02-14&sr=c&sig=GV0T9y%2B9%2F9%2FLEIipmuVee3jvYj4WpvBblo%3D&se=2019-06-01T00%2A%3AZ&sp=rwdl';
```

・コピー専用バックアップ

```
BACKUP DATABASE tpcc2501
TO URL = 'https://myacc.blob.core.windows.net/testcontainer/tpcc2501.bak'
WITH COPY_ONLY
```

・ストライプバックアップ
Blobは２００GBのサイズ制限があります。次のようにしてファイルを分割してバックアップします。

```
BACKUP DATABASE tpcc2501
TO URL = 'https://myacc.blob.core.windows.net/testcontainer/tpcc2501-4-1.bak',
URL = 'https://myacc.blob.core.windows.net/testcontainer/tpcc2501-4-2.bak',
URL = 'https://myacc.blob.core.windows.net/testcontainer/tpcc2501-4-3.bak',
URL = 'https://myacc.blob.core.windows.net/testcontainer/tpcc2501-4-4.bak'
WITH COPY_ONLY
```

・MAXTRANSFERSIZE
大きなデータベースの時には、MAXTRANSFERSIZE=4194304を指定するといいでしょう。
１ファイルあたり、48GBを超えないようにする。
COMPRESSIONで圧縮して帯域を節約します。
CHECKSUM or STATS = で正しくバックアップできたか確認してもいいでしょう。

```
BACKUP DATABASE tpcc2501
TO URL = 'https://myacc.blob.core.windows.net/testcontainer/tpcc2501-4-1.bak',
URL = 'https://myacc.blob.core.windows.net/testcontainer/tpcc2501-4-2.bak',
URL = 'https://myacc.blob.core.windows.net/testcontainer/tpcc2501-4-3.bak',
URL = 'https://myacc.blob.core.windows.net/testcontainer/tpcc2501-4-4.bak'
WITH COPY_ONLY, MAXTRANSFERSIZE = 4194304, COMPRESSION
```

価格

Preview版のお値段については、「ここ」に記載があります。
目的別に2種類のサービス帯が提供さえる予定なのですが、現時点では一般的なワークロード用のGeneral Purposeのみが提供されています。

「BASE RATE PRICE WITH AZURE HYBRID BENEFIT (% SAVINGS)」は、SQL Serverのライセンスを持っていて有効なSA権を持っている場合に、ライセンスをクラウドに持ち込んだ場合の価格です。
ですので、通常は「LICENSE INCLUDED PREVIEW PRICE」を選ぶことになります。

２４vCoreを選択すると、東日本リージョンで375.44円/時間かかり、１日9,010円、1ヶ月279,327円かかります。
ストレージが最初の３２GBがvCore代金に含まれていて、以後月1GB毎に7.73円かかり、最大８TBまでいけます。1TBで月７９１５円。
バックアップデータは月1GB毎に5.6円かかるので、月3000円。
IO１００万毎に13.44円なので、50,000IOPSで、月58060円。

月間、高くても35万円あたりでしょうか。
プレビュー中はNW転送量に課金されません。

バックアップ費用の見積もり方

利用しているサーバーストレージサイズと同じ容量までは追加費用がかかりません。
それを超えると費用が加算されます。
１００GBのデータベースの場合、100GBのバックアップまでは無料、１１０GBの場合は１０GBが費用発生します。
2018/6/30まではバックアップ費用は発生しません。

提供されているリージョン

20リージョンで提供されています。
Canada Central
Canada East
Central US
East Asia
East US
East US 2
Japan East
Korea Central
Korea South
North Central US
North Europe
South Central US
South India
Southeast Asia
UK South
West Central US
West Europe
West India
West US
West US 2

投稿Azure SQL Database Managed Instance (Preview) のまとめは蒼の王座の最初に登場しました。

SQL Azure Database では、データ圧縮（行やPAGE圧縮）をすることができます。
この辺りは、ムッシュの「SQL Database で行/ページ圧縮が利用可能になったようです」で紹介されています。
今回紹介するのは地味につらいけど、あまりちゃんと説明されていない部分の注意点になります。

MSDNで「Data Compression」でツラツラ書かれている中で次のような注意事項があります。

行またはページの圧縮を有効または無効にするために必要なディスク空き容量は、インデックスを作成または再構築するために必要なディスク空き容量と同じです。

とてもしれっと、さりげなく書いていますが、とても重要なのです。
つまり、ストレージに十分な空き容量がないとデータ圧縮を有効にできません。

では十分な空き容量とはなんでしょうか？
対象となるのは、「デーベースファイル」と「トランザクションログファイル」の2つです。
それぞれで十分な空き容量が必要となります。

クラスタ化インデックスを作成するときに必要なディスク領域については、「インデックスのディスク領域の例」と「インデックス操作用のトランザクション ログのディスク領域」で解説されています。

オンラインでのクラスタ化インデックス作成（SORT_IN_TEMPDB=ONに設定されたオンラインインデックスの操作）だと、
元のテーブルが約363MBだとすると
作業中に必要な領域の合計サイズは1058MBで、
作成されたインデックスサイズは453MBになります。
作業途中では約2倍の空き領域が必要に（3倍じゃないのは1058MBにはもともとの容量が含まれているので）なりますね。
ただしTEMPDBが含まれているのでAzure SQL Databaseの場合には、
242MBが含まれるので810MBです。オリジナルの1.3倍ぐらいの追加空き容量があればOK。

さて、トランザクションログはというと「インデックス操作を確実にロールバックできるようにするには、インデックス操作が完了するまでトランザクション ログを切り捨てることができません。」や「SORT_IN_TEMPDB オプションを ON に設定することを検討します。この設定により、インデックス トランザクションが同時実行のユーザー トランザクションから分離されます。インデックス トランザクションは、tempdb データベースのトランザクション ログに格納され、」と書かれています。
SORT_IN_TEMPDBオプションは既定ではOFFなのでクエリで明示的に指定しなければOFFです。

ここがあまり理解できていないのですが、対象のデータベースでページ圧縮以外のトランザクションがなくてもトランザクションログは必要で、必要な容量はおそらくディスクデータ領域の数倍かと思われます。

どうやるのがベスト？

データ圧縮を有効にするには、データ容量とトランザクション容量の両方が必要になることを確認しました。

データ容量については、まぁ仕方ないので増やして対応しましょう。
しかし、トランザクションログだけは制限が入ってるので、対策をする必要があります。
Azure SQL Database の P15 でトランザクションログが1TB、P2でトランザクションログが340GBとなっています。そのため、100GBを超えるテーブルを圧縮するには確実に足りません。

そこで利用するのが、「再開可能なオンラインインデックス再構築」です。

再開可能なオンラインインデックス再構築のポイント

• 実行中は、更新系クエリに一桁パーセントのオバーヘッドがかかるかも。（参考）
• インデックス再構築の障害からの回復 (データベースのフェールオーバーやディスク領域の不足など)。（参考）
• インデックス再構築操作の間はトランザクション ログの切り捨てを有効にします (通常のオンライン インデックス操作に対してこの操作を実行することはできません)。
  • つまり、途中で止めてトランザクションログバックアップがされればトランザクションログが切り捨てされて幸せに！
  • 再開可能な再構築では実行時間の長いトランザクションを開いたままにする必要はなく、この操作の間のログの切り捨てと、より優れたログ領域管理が可能です。
  •  新しい設計では、必要なデータを、再開可能な操作を再開するために必要なすべての参照と共に、データベースに保持しています。
• 再構築中にReconfigurationが発生してもフェールオーバー後に途中から再開可能。
• 再構築中の進捗状況がクエリで取得可能。

テーブル圧縮とインデックス圧縮について

ALTER TABLEとALTER INDEXそれぞれでデータ圧縮ができますが、それぞれにどんな意味があって、挙動が違うのでしょうか。
それを知る手掛かりが、MSDNの「圧縮されたテーブルおよびインデックスの作成」で説明されています。

圧縮できる対象のデータベースオブジェクトが次のものです。

• ヒープとして格納されているテーブル全体。
• クラスター化インデックスとして格納されているテーブル全体。
• 非クラスター化インデックス全体。
• インデックス付きビュー全体。
• パーティション分割されているテーブルおよびインデックスの場合、パーティションごとに圧縮オプションを構成することができ、オブジェクトの各パーティションを同じ圧縮設定にする必要がありません。

つまり、ヒープテーブルへのALTER TABLEと、非ヒープテーブルのクラスター化インデックスへのALTER INDEXが同じ意味を持っていそうです。

Let's Try

ムッシュがすでに「SQL Database で再開可能なオンラインインデックス再構築が Public Preview で利用可能となりました」で紹介されています。

そこから学ぶと以下のクエリでよさそうですね。

-- 再開可能なオンラインインデックス再構築
ALTER INDEX [PK_T1] ON [dbo].[T1] REBUILD PARTITION = ALL
WITH (RESUMABLE = ON, ONLINE = ON, MAX_DURATION = 1, DATA_COMPRESSION = PAGE)

投稿データ圧縮を使用するときの注意点は蒼の王座の最初に登場しました。

SQL Azure Database で、巨大テーブルのユニーク数の概算を取得するのに役立つ関数「APPROX_COUNT_DISTINCT」の一般プレビューがリリースされました。（紹介Blog）

SELECT COUNT(DISTINCT())

使用例としては、一千万行ぐらいのテーブルで、ダッシュボード表示用にCOUNT(DISTINCT())する場合が考えられます。
このケースで重要なは正確な数字ではなく、データ取得までの応答速度です。

「APPROX_COUNT_DISTINCT」は、NULLではないユニークな数の概算を取得する関数です。

「APPROX_COUNT_DISTINCT」は、大きなデータで使用する前提で設計されていて、次のようなケースに最適化されています。

• 数百万行以上のデータにアクセスする場合
• 多数の異なる値を持つ列をカウントする場合

この関数は、通常の使用用途では2%以内の精度を維持しつつ、かつどんなに稀な使用例でも悪くても20%以内の精度を維持されるべきだと考えています。

設計ポイント

「APPROX_COUNT_DISTINCT」は、非常に少ないメモリ使用量で算出できるように設計されています。COUNT DISTINCTで、メモリ内にデータが収まりきらずTempDBを使用して算出するケースでは、優位になります。「APPROX_COUNT_DISTINCT」は、基本的にTempDBを使用して算出することはありません。

Q & A

• 「APPROX_COUNT_DISTINCT」でクエリは高速化しますか？
  • 対象データによります。メモリに最適化しているので、メモリ内に収まりきらない場合には、かなりの応答優位性を発揮します。
  • メモリ内で収まる場合には、あまり差がありません。
• 精度が2%に収まらない最悪のレアケースでは、どれぐらいの精度になりますか？
  • 20%以内に収まるべきと考えています。
• 実行プランへの影響は？
  • COUNT(DISTINCT)では、Hash MatchとSort操作がはいります。INDEX SCANは95%程度ですが、「APPROX_COUNT_DISTINCT」では、98%の時間がINDEX SCANです。

実装方法

実装に採用されているアルゴリズムについて教えてもらったので追記しておく。
OracleやRedis、Redshifにも同様の関数があって、それらは「HyperLoglog」が使用されているので、Azure SQL Databaseでも恐らくそれだろう。

オリジナル論文は、2007年に公開されている。
なんとなく理解をするのなら、「HyperLoglogでcount distinctを速くする」を参照するとなんとなく理解できたような気ができる。

投稿Azure SQL Database で Count Distinct の概算関数が一般プレビューは蒼の王座の最初に登場しました。

redash で、データソースにSQL Serverを選択し、Azure SQL Databaseに接続しようとすると以下のようなエラーが出ることがあります。

Cannot open server "1433D" requested by the login. The login failed.DB-Lib error message 20018, severity 20: General SQL Server error: Check messages
from the SQL Server DB-Lib error message 20002, severity 9: Adaptive Server connection failed (xxxxxxxxxxxxx.database.windows.net:1433)

これは、SQL Server とは違って、Azure SQL Databaseの実装上の違いによって生じています。SSMSであれば、明示的に指定しなくても自動的に裏側でしれくれるのですが、redashの場合には明示する必要があります。

接続先サーバー名が、xxxxServerName.database.windows.net と仮定すると、
Userには、「analysis@xxxxServerName」のように指定する必要があります。

もちろん、analysisの部分はあなたのDBのログインに置き換えてください。太字のように、@以下にサーバーのホスト名を指定します。

投稿redashでAzure SQL Databaseに接続する方法は蒼の王座の最初に登場しました。

ドキュメント読んだり、説明されればそりゃーそうだっと納得できるのですが、説明されるまでは勘違いしていたのでメモしておく。

詳細説明は「公式ドキュメント」でされているので、そちらを参照して欲しい。

セカンダリへの反映は一定量の変更をセカンダリにトランザクションログを用いてします。
反映対象は、トランザクションが完了したものになります。

アクティブ geo レプリケーションは SQL Server の Always On テクノロジーを活用し、スナップショット分離を使用してプライマリ データベース上のコミットされたトランザクションを非同期的にレプリケートします。

特定の時点におけるセカンダリ データベースは、プライマリ データベースよりもわずかに古い可能性がありますが、セカンダリ データには部分トランザクションが含まれないことが保証されます。

トランザクションが完了すれば反映対象となるので、順番が前後するとつらい操作はトランザクションにする必要があります。

例えば、メンテナンス作業で、インデックスの再構成をする場合には、統計情報の自動更新が重ならないようにしておいたほうがいいので、統計情報の自動更新を停止することがあります。

マスターで、自動更新の停止、インデックスの再構成、自動更新の再開をすると、セカンダリーにも、自動更新の停止、インデックスの再構成、自動更新の再開が適用されます。

ただし、インデックスの再構成の実行時間によっては、セカンダリでは、自動更新の停止、自動更新の再開、インデックスの再構成の順番で適用されることがあります。
これがまずい場合には、「自動更新の停止、インデックスの再構成、自動更新の再開」で一括りのトランザクションにしましょう。

投稿Azure SQL DatabaseのGeoレプリケーションのセカンダリへの反映ロジックは蒼の王座の最初に登場しました。

Azure SQL Databaseの監査ログを見るとき、知らないと面食らうというか上手く使えなくてしょんぼりすることがあります。
ちょっとしたポイントを知っておくと幸せになれます。

監査ログをAzure ポータルで参照しようと思うと最終的にはクエリエディターを起動することになります。クエリエディターのログインに使用するアカウントは管理アカウントになります。

クエリエディタが起動すると次のようなクエリが書かれています。

SELECT TOP 100 event_time, server_instance_name, database_name, server_principal_name, client_ip, statement, succeeded, action_id, class_type, additional_information
FROM sys.fn_get_audit_file('https://xxxxxxx.blob.core.windows.net/sqldbauditlogs/xxxxxxxxx/xxxxxxxx/SqlDbAuditing_Audit/2018-08-29/04_00_49_057_2108.xel', default, default)
WHERE (event_time <= '2018-08-29T04:00:51.022Z')
/* additional WHERE clause conditions/filters can be added here */
ORDER BY event_time DESC

Blobファイルを読み込んで検索していますね。
ファイルが細かく分かれているので、ほかのファイルも対象にしたくなります。

ドキュメント読んでワイルドカードとか試したのですが、あまりちゃんと動かず、結局たどり着いた結論は、「前方一致」したものが対象になるでした。

例えば、Blobファイルの指定を、「
https://xxxxxxx.blob.core.windows.net/sqldbauditlogs/xxxxxxxxx/xxxxxxxx/SqlDbAuditing_Audit/2018-08-29/ 」とすると、8/29のものがすべて。「
https://xxxxxxx.blob.core.windows.net/sqldbauditlogs/xxxxxxxxx/xxxxxxxx/SqlDbAuditing_Audit/2018-08-2」とすると、20日～29日が対象となります。（たぶんねｗ

データ量が多いと検索にえげつない時間かかります。
自分が試した環境だと10分程度でも結果出るのに1分とかかかりました。

つらいですね。
もう少し素敵な検索方法は、SQL Server Management Studioを使うことです。
ポータルでやるのはあきらめて、ここの真ん中あたりに記載がある「SQL Server Management Studio (SSMS 17 以降) で [監査ファイルの統合] を使用します。」の手順にのっとるのがいい。

これを実行すると、Blobストレージのアクセス権APIキーを設定した後、取り込みたい範囲を指定して、ローカルにダウンロードし、SSMSでフィルタリングとかをして調査をします。
めっちゃいい！と言い切れない部分もあるのですが、Azure Portalよりは断然ましです。

投稿Azure SQL Databaseの監査ログを参照するときのチップスは蒼の王座の最初に登場しました。

MSSQL Tiger Teamが投稿したBlogを基に整理した内容です。

可容性グループはSQL Server 2012で初めてリリースされました。
可容性グループセカンダリレプリカの各データベースではトランザクションログのredoは一つのredoスレッドで制御していました。
このredoモデルは、serial redoと呼ばれていました。

SQL Server 2016で、redoモデルが強化され、redo操作を分けるためにデータベース毎に複数の並列redoワーカースレッドになりました。さらに各データベースは、ダーティページディスクフラッシュIOを管理する新しいヘルパーワーカースレッドがあります。
この新しいredoモデルは、parallel redoと呼ばれます。

新しいparallel redoは、SQL Server 2016から既定の設定で、小さいトランザクションが並列に大量に実行されるケースではredo性能の改善ができました。データの暗号化、データ圧縮の有功などのCPU負荷の高いトランザクションredo操作は、serial redoと比較してparallel redoの方が高いスループット（Redone Bytes/sec）が得られます。
さらに、間接的チェックポイントがparallel redoがヘルパーワーカースレッドにディスクIOや遅いディク用のIO waitを委任し、メインのredoスレッドがセカンダリレプリカでログレコードをより受信できるようにします。redo性能を向上させます。

しかし、parallel redoはマルチスレッドモデルでコストが高いです。

• メインredoスレッドは、各トランザクションログredo操作の実行を停止しますが、各トランザクションログを列挙し、parallel redoワーカースレッドにディスパッチすることを担当します。テーブル（行数の小さい）の狭い範囲の行へのDMLトランザクションのredoのようなCPU負荷がかからないログredo操作のケースでは、それらのログをディスパッチするコストは非常に重いです。
• 新しいレコードを挿入するためにページを分割するシステムトランザクションは、parallel redoワーカースレッド間でPARALLEL_REDO_TRAN_TURN waitを利用します。頻繁にinsert操作をする場合、かなりparallel redo性能を遅くします
• 読み取りセカンダリレプリカでread-onlyクエリを実行すると、クエリスレッドはログredo操作を一時停止しようとし、DIRTY_PAGE_TABLE_LOCKでredoワーカースレッドと連携する必要があります。redoとクエリ性能が両方遅くなります。

性能研究に基づくと、次のトランザクションワークロードまたはSQL設定が既定のparallel redo モデルより良い結果となります。

• 多くの並列の小さいトランザクション
• 間接的なチェックポイントを伴う負荷のかかるログredo操作（データ暗号化またはデータ圧縮）
• 読み取りをしないセカンダリレプリカ、またはたまにread-onlyクエリを読み取りセカンダリレプリカで実行する場合

次の場合は、serial redoに切り替えた方がredoスループットがよくなります。

• 一般的なInsertや同時実効性が限られている長い時間実行するトランザクション：典型的な例は、大きなテーブルのクラスター化インデックスのオンラインIndex再構築
  • parallel redoモデルでの兆候
    • PARALLEL_REDO_TRAN_TURN waitがinsert処理量に比例して生成されます。多くのInsertが多くのpage splitを起こし、PARALLEL_REDO_TRAN_TURN waitを呼びます。
    • 性能カウンターで監視できます。（SQLServer:General Statistics、User Connections）または、プライマリレプリカのDMV（sys.dm_exec_connection、sys.dm_exec_sessions）
• 頻繁で、長時間のread-onlyクエリをセカンダリレプリカのデータベースに実行する必要がある場合
  • parallel redoでの兆候
    • 頻繁なDIRTY_PAGE_TABLE_LOCK wait
    • 性能カウンターで監視できます（SQLServer:Database Replica、Redone Bytes/sec）クエリを実行している時としてない時でredoスループットを比較します。
• 小さなデータセットのデータページにセカンダリレプリカでread-onlyクエリが高頻度でスキャンし、プライマリレプリカで頻繁に同じデータセットに変更を加える。クエリとredoスレッド両方に劇的な性能劣化を与えます
  • parallel redoでの兆候
    • 大量のDTP_ENTRY_LOCK wait
    • 最悪のケースでは、Latch timeoutによりSQL ErrorログにTimeout occurred while waiting for latchと記録されます。

新しいWaitの種類

いくつか紹介されていますが、個人的に興味があるものをピックアップ。

• DTP_ENTRY_LOCK
  • ユーザークエリスレッドから追いつくためのREDOがあるdirty page entryへのアクセスを制御するロックがある時に発生します。
  • parallel redoワーカースレッドとユーザークエリが同時に同じdirty page entryにredo処理をした時のみ発生します。

補足

SQL Serverの事例として紹介されていますが、Azure SQL Database のgeo replicationを使用してセカンダリデータベースを使用しているケースでも同様の問題が発生します。
P15を使っていると、ジオレプリケーションはparallel redoが採用されているので、ここで紹介されたことと同じ問題が発生するのです。

投稿SQL Server 2016/2017 可容性グループ セカンダリレプリカ redoモデルと性能は蒼の王座の最初に登場しました。