SQL Server 2019 CTP 3.1 のデータベースエンジンの新機能として「OPTIMIZE_FOR_SEQUENTIAL_KEY」というインデックスのオプションが追加されました。
このオプションは、インデックスへの挿入を行う際に発生する Last page insert によるページラッチの競合を改善する効果のあるオプションとなっています。
詳細については、CREATE INDEX のヘルプの Sequential Keys に記載されています。
Read the rest of this entry »
Author Archive
SQL Server 2019 CTP 3.1 で追加された OPTIMIZE_FOR_SEQUENTIAL_KEY の効果を確認してみる
SQL Server 2019 CTP 3.1 のリリースノートが公開されました
投稿を書いている時点ではモジュールはまだ公開されていないようですが、SQL Server 2019 CTP 3.1 のリリースノートが公開されていました。
追記
公式アナウンスありました。
SQL Server 2019 community technology preview 3.1 is now availabl
- SQL Server 2019 preview release notes (CTP 3.1)
- What’s new in SQL Server 2019 preview (CTP 3.1 June 2019)
- Release notes for big data clusters on SQL Server (CTP 3.1 (June))
データベースエンジンとしては、次のような機能が追加されているようです。
データベースエンジン
- 暗号化列にインデックスを付与
- Always Encrypted with Secure Enclaves でランダム暗号化した列に対して、非クラスター化インデックスを作成することができるようになり検索の効率が向上しているようです。
- Indexes on Enclave-enabled Columns using Randomized Encryption
- セットアップ時に最大 / 最小メモリを設定可能
- 従来までの SQL Server では、セットアップ後に最大 / 最小メモリを設定していましたが、今回からセットアップ時に設定ができるようになったようです。
MAXDOP についても設定ができるようになったようです。 - tempdb のように推奨オプションが指定される形で手動変更も可能という設定となったようですね。
- Setting the memory options manually
- グラフテーブルの最短パス用の関数の追加
- グラフテーブルで任意のノード間の最短パスを見つけるための関数 (SHORTEST_PATH) が追加されたようです。
- Public Preview of Shortest Path on SQL Server 2019
- グラフテーブルのパーティションテーブル / インデックスのサポート
- グラフテーブルでパーティショニングが使用できるようになったようです。
- 最終ページ挿入を改善するための新しいインデックスオプション
- インデックスに OPTIMIZE_FOR_SEQUENTIAL_KEY オプションが新しく追加されました。
- ID や現在の日付時刻が設定されている場合、複数スレッドによる最終ページのへの INSERT によって、PAGELATCH_EX の競合が発生することがあります。
この競合を解消することができるオプションとして OPTIMIZE_FOR_SEQUENTIAL_KEY オプションが追加されたようです。 - SQL Server on Linux の tempdb の自動的な分割
- 2017 の SQL Server on Linux では、tempdb の自動的な分割は行われなかったのですが、2019 CTP 3.1 から分割されるようです。
Big Data Cluster
ビッグデータクラスター周りは例のごとく、かなり変更が加わっています。
- mssqlctl コマンドの変更
- 新しい CTP のリリースごとにコマンド体系が変わる mssqlctl ですが、今回も変わりました。
- mssqlctl cluster → mssqlctl bdc に変更
- クラスターのステータスを確認するためのコマンドとして mssqlctl bdc status が追加されているようです。
- これに伴いまさかの管理ポータルの廃止が…。
- Kibana / Grafana のダッシュボードは個別にエンドポイントがあるようなので、そこから状況は確認できるようですが。
- Spark コンピューティングプール
- 今までの Big Data Cluster は、ストレージプールの HDFS は Spark と相乗りだったのですが、Spark 部分を切り離して、個別にスケールできるようになったようです。
- Configure storage without spark
- MSSQL Spark コネクタ
- データプールの外部テーブルに読み取りだけでなく、書き込みもできるようになったようです。
- MLeap を使用した機械学習
- Spark の MLeap と SQL Server の Java 拡張を使用した機械学習の仕組みの実装ができるようです。
- Create, export, and score Spark machine learning models on SQL Server big data clusters
メモリ最適化 tempdb メタデータについて (CTP 3.0 時点の動作)
SQL Server 2019 CTP 3.0 から、tempdb のメタデータをメモリ最適化テーブルを使用することができるようになりました。
- データベース エンジン
- メモリ最適化 tempdb メタデータ (In-Memory Database)
- メモリ最適化 tempdb メタデータ (tempdb)
Hekatonized Tempdb と呼んでいる方もいるようですね。
Read the rest of this entry »
vPMEM についてのメモ
Azure VM をデプロイしようとしたところ、次のような表示になっていて気づきました。
Gen2 VM については、「vPMEM」という表示があり、情報としては去年から出ていたようなのですが、Hyper-V の最新の仮想マシンでは、Persistent Memory を仮想マシン上で使用するための vPMEM という機能があるのですね。
Windows Server バージョン 1709 の新機能 ですでに公開されていたようなのですが、全くキャッチアップできていませんでした。
有効にするための方法については HYPER-V Vm の永続的なメモリ デバイスを構成するためのコマンドレット で記載されています。
PMEM 上に「vhdpmem」という拡張子のファイルを作成し、仮想マシンに追加した PMEM のコントローラーにそのファイルをディスクとして追加することで、仮想マシン上で PMEM の利用を可能とするというようなアプローチのようです。
(通常のディスク上にも vhdpmem ファイルを作成することはできますが、残念ながら通常のディスク上に作成しても、接続した仮想マシンを起動することはできませんでした)
VMWare にも vPMEM の考え方があるようで、各社仮想マシンで PMEM を利用するアプローチが進められているようですね。
Hyper-V の PMEM 対応については、Windows Support for PM – SNIA が詳しそうです。
去年、GCP が PMEM 対応のアナウンスを行っていたことは記憶にあったのですが、Gen2 VM に表示があるということは、Azure でもそのうち PMEM が利用できる VM が提供されるのかもしれないですね。
SQL Database の更新情報 (2019/6/13 版)
6/12 にいくつかの更新が発表されていましたのでまとめて確認しておこうかと。
Advanced Data Security available for SQL Server on Azure Virtual Machines
SQL Server on Azure VM で高度なデータセキュリティ機能が利用可能になりました。
SQL Database では以前から実装されていますが、この技術が IaaS の SQL Server でも使用できるようですね。
機能としては、次の 2 種類が使用できるようになるようです。
- 脆弱性評価
- 高度な脅威検知
次のような情報も併せて公開されていますね。
- Advanced data security for SQL Server is coming to Azure Virtual Machines
- IaaS の SQL サーバー向け Advanced Data Security
脅威検知については、現状は、通常とは異なるアクセスについての検知が利用できるようですが、SQL インジェクションのようなクエリ実行に対しての検知の提供も準備されているようですね。
Azure SQL Database Managed Instance でリージョンのリソース制限のサポートが拡大されました
Managed Instance はサブスクリプション内にデプロイできる数がかなり少なく制限されていたのですが、この制限が緩和されたようです。
以前はこのような制約でしたが、結構緩和されていますね。
最新のリソース制限については こちら を確認していただければ。
General availability: 4 vCore Azure SQL Database managed instances on Gen5 hardware
Gen5 については 4 コアモデルの提供が開始されました。
価格の情報 と リソース制限 の情報も更新されています。
4 コアモデルであれば、今までと比べるとかなりやすく使用できますね。
デモがやりやすくなりうれしい限りです。
Dev/test pricing option for individual Visual Studio subscribers is now available for Azure SQL Database managed instance
こちらもうれしい情報なのですが、Visual Studio サブスクリプションについている Azure サブスクリプションで、Managed Insance が利用できるようになりました。
さらに「開発テスト用従量課金プラン」と同様に 55% ディスカウントされた金額で利用できますので、検証時の費用は結構抑えられそうです。
Azure SQL Database default configuration changing soon
新しいデータベースを作成した際のデフォルトの構成が汎用目的 / 2 vCore / Gen5 のモデルとなりました。
オプションを何も設定せずに CREATE DATABASE すると次のような DB で作成されます。
Datadog を使用して SQL Server のメトリクスを取得する際の覚書
Datadog のエージェントには、標準で SQL Server のメトリクスを取得するための、Integration が含まれています。
- Collect SQL Server Custom Metrics
- SQL Server
- Key metrics for SQL Server monitoring
- Custom SQL Server metrics for detailed monitoring
- Monitor SQL Server performance with Datadog
軽く触ってみた際の覚書を。
Read the rest of this entry »
SQL Database のディスクを使用した処理の最小応答時間を取得してみる
de:code 2019 の? DP06 Deep-dive in Azure Cosmos DB: Advanced topics on partitioning, data distribution and indexing で実施されていた Cosmos DB のグローバル分散のデモ で面白いなと思ったものの一つとして、リージョンが違うことによるレイテンシーの違いというものがありました。
この見せ方、面白いなと思って、SQL Database でも簡単なものを試してみました。
DTU モデルの場合は公開されていないのですが、vCore モデルの場合は、デプロイ時に次のような記載があります。
データファイル / ログファイルのような物理ファイルにアクセスする場合の想定待機時間が記載されていますね。
詳細については、仮想コアベースの購入モデルを使用した単一データベースに対するリソース制限 でまとめられているのですが、基本的な考え方としては次のようになります。
- リモートストレージへのアクセス
- 書き込み時 : 5 ~ 7 ミリ秒程度の I/O 待機時間
- 読み込み時 : 5~10 ミリ秒程度の I/O 待機時間
- ローカルストレージへのアクセス :
- 書き込み時 : 1~2 ミリ秒程度の I/O 待機時間
- 読み込み時 : 1~2 ミリ秒程度の I/O 待機時間
SQL Database はサービスレベルに応じて、使用するストレージ (接続方式) が異なります。
DTU モデルの「Basic」「Standard」と、vCore モデルの「汎用目的」については、「リモートストレージ」が使用されており、データベースは Azure Premium Storage 上に格納されています。
DTU モデルの「Premium」と、vCore モデルの「ビジネスクリティカル」については、「ローカルストレージ」が使用されており、リモートストレージと比較して、高速にアクセスができるようになっています。
データベースの処理時間を考える際には、以下の 2 点を考慮する必要があるか思います。
- アプリケーションからのアクセスを考慮した応答時間
- データベース単体の応答時間
今回はこれらを考慮した情報の取得を行ってみたいと思います。
Read the rest of this entry »
de:code 2019 の DP01 Big Data Cluster 入門の資料を公開しております
先日、登壇させていただいた de:code 2019 の SQL Server 2019 Big Data Cluster 入門の資料を Github で公開させていただきました。
https://github.com/MasayukiOzawa/decode-2019
こちらにスライドの PDF も公開してあります。
今回のデモは Azure Data Studio の Notebook を使用して実施しましたので、Github 上のデモ用コンテンツも実行済みの Notebook の形でアップロードしてあります。
どんなことができるか、どんな動作になるかはそのまま確認していただけるかと。
SQL Database Hyperscale の構成や特徴を学習する
最終更新日 : 2019/12/20
SQL Database の Hyperscale が Build 2019 で GA され、SLA 付きで使用できるようになりました。
現在公開されている情報を見ながら学習してみました。
公式のドキュメントは次の情報となります。
- 最大 100 TB の Hyperscale サービス レベル
- Azure SQL ハイパースケール データベースに関する FAQ
- ハイパースケール サービス レベル
- SQL Hyperscale のパフォーマンスのトラブルシューティング診断
より詳しい情報については、次のドキュメントから確認できます。
- Socrates: The New SQL Server in the Cloud
- Develop data application on a no-limits SQL data platform
- Introducing Azure SQL Database Hyperscale
こちらは、私が以前登壇した際の資料となります。
これらの情報を把握することで、FAQ に記載されている内容が「なぜそうなるのか?」ということを理解することができ、構成の把握を進める上で役に立つかと思います。
SQL Server の「高速挿入」についての覚書
最近、SQL Server の Bulk Insert について、調査することが何回かあり、その中で「高速挿入」(Fast Inserts / Fast Load Context) の動作をどこまで見れるか、考えたことがあったので、その覚書を。
詳細な情報としては次の内容を参照してください。