SE の雑記

Azure SQL Database の各種メトリックを取得する方法ですがいくつかの方法が提供されており、簡単に使いだすことができます。

どのようなものがあり、どこから確認するかを忘れるときが結構ありますので、一度まとめておこうかと。
Read the rest of this entry »

SQL Database の Single Database では、SQL Database バックアップとは に記載されているタイミングでトランザクションログのバックアップが取得され、ログの切り捨てが行われます。
Hyperscale の各種メトリクスを取得して分析すると気づくのですが、Hyperscale については、定期的な間隔ではなく、使用サイズによってトランザクションログの切り捨てが行われるような動作となっているように見えます。
このサイズが何によって決まっているのかを調べてみました。
Read the rest of this entry »

SQL Data Warehouse (SQL DW) は、60 のデータベースに分散してデータを格納した分散テーブルを使用して、透過的にデータを検索することで、効率よくデータを分析することができるアーキテクチャとなっています。
データの分散を適切に実施することがが性能を出す際の重要なポイントとなります。
「分散の方式を誤り、一つのデータベースにデータが極端に集中した場合、どのような性能的なデメリットが出るか」を数値的に取得したことがなかったため、確認をしてみました。
Read the rest of this entry »

SQL Database のアップデートがいろいろと発表されましたのでまとめておこうと思います。
Read the rest of this entry »

SQL Database Hyperscale については、SQL Database Hyperscale の構成や特徴を学習する で一度書きましたが、読み取りセカンダリについても追加で勉強した内容がありますので書いておこうかと。
SQL Database Hyperscale では、セカンダリレプリカの台数を 0 ～ 4 台まで指定することができます。

ハイパースケール データベースではどのような SLA が提供されるか に記載されていますが、セカンダリレプリカの台数に応じて、SLA が異なります。

• 1 台のセカンダリレプリカ : SLA 99.95%
• 2 台以上のセカンダリレプリカ : SLA 99.99%

また、セカンダリの接続ですが、読み取りワークロードのインテリジェントな負荷分散がシステムで行われるか では「ランダムに接続される」ことになっており、複数台のセカンダリレプリカをデプロイしている場合、どのレプリカに接続されるかはランダムとなるようです。
(Build 2019 の内容では、ラウンドロビンとなっていたのですが、私が検証したときにはランダムのような動作となっていました)
今回の本題はそこではなく、「プライマリレプリカで更新 / 追加されたデータがセカンダリレプリカでどのように認識されるか」という点です、
Read the rest of this entry »

SQL Database Serverless が提供された当初は、自動停止の期間が「6 時間」だったのですが、これが「1 時間」に変更となったようです。

日本語のドキュメントはまだ反映されていないようですが、英語版は記載が変更されています。
Azure SQL Database serverless (preview)

デフォルトも 1 時間に変更となったようですね。
できれば 10 数分の期間ぐらいでも設定したいですが、以前の 6 時間よりは使いやすくなったのではないでしょうか。

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 で作成されます。

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 待機時間
  • 読み込み時 : ５～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 »

最終更新日 : 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

こちらは、私が以前登壇した際の資料となります。

• db tech showcase 2019 : SQL Database Hyperscale 徹底分析 – 最新アーキテクチャの特徴を理解する

これらの情報を把握することで、FAQ に記載されている内容が「なぜそうなるのか？」ということを理解することができ、構成の把握を進める上で役に立つかと思います。

Read the rest of this entry »

Build 2019 で発表された Azure SQL Database serverless を少し触ってみました。
ドキュメントはこちらから。

• SQL Database serverless (preview)

基本的な考え方としては AWS の Aurora サーバーレス に通じるものがあるのかと。
(Azure SQL Database serverless は、現時点では最大 4 コアのモデルまでの小さなサイズでの提供となっていますので、スケール面での考え方は異なりますが)
Read the rest of this entry »