SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Archive for the ‘SQL Database’ tag

SQL Database に対して Private Link で接続をしてみる

leave a comment

先日、Private Link がプレビューで公開されました。

現時点で対応しているサービスとしては次のようなものがあります。

During public preview, Private Link supports Azure Storage, Azure Data Lake Storage Gen 2, Azure SQL Database, Azure SQL Data Warehouse, and customer-owned services.

 

Azure プライベート リンク の価格 に料金も出ていますが、時間と容量の課金がありますので、どの程度のコストがかかるかを把握しておくのもお忘れなく。

Read the rest of this entry »

Written by masayuki.ozawa

9月 19th, 2019 at 7:33 pm

Posted in SQL Database

Tagged with ,

SELECT を NOLOCK で実行しても発生する待ち事象について

leave a comment

先日投稿した SQL Server の「NOLOCK」ヒントは単純なロックを取得しないという動作ではありません の内容に近いものですが。

NOLOCK ロックヒントを設定しても発生する待ち事象について少し書いておきたいと思います。

先日書いた投稿は NOLOCK ロックヒントを使用すると整合性のあるデータへのアクセスが保証されないため、COUNT(*) を実行すると、データの総数が変わっていないが、データの件数が一定しないというものでした。

今回の投稿は「PAGELATCH」による待ちが発生するというものです。

Read the rest of this entry »

Written by masayuki.ozawa

9月 15th, 2019 at 10:32 pm

HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO によるトランザクションログの書き込み性能の低下について

leave a comment

2019/6 に SQL Database の変更が入り、Geo レプリケーションが有効な環境で異なるサービスレベルを使用している場合に、プライマリサーバーの更新に Geo セカンダリサーバーが追いつけなくなると性能調整が行われるようになりました。

この調整が発生すると、どのような I/O 傾向になるのかを把握しておくことは重要です。

Geo レプリケーションのセカンダリが下に構成されているときに発生しますプライマリよりもサイズ (低い SLO) を計算します。 プライマリ データベースは、遅延のログの使用量のため、セカンダリで調整されます。 これは、セカンダリ データベースの変更率が、プライマリ データベースの遅れが不足しているコンピューティング容量を持つことが原因です。

となっているので、ドキュメント上は、プライマリと Geo セカンダリの性能を変えている (Geo セカンダリの方の性能を下に設定している) 場合に、調整が行われる可能性が出てきます。

本投稿では、調整が発生することで、どのような I/O 性能の低下を招くかを見てみたいと思います。

今回、検証で使用したスクリプトについては https://gist.github.com/MasayukiOzawa/e3a2ff81628d074eacf4664e36d5ecfb に残してありますので、興味のある方はカスタマイズして試していただければ。

Read the rest of this entry »

Written by masayuki.ozawa

9月 15th, 2019 at 5:03 pm

Azure SQL Database のメトリックの収集方法の基本 (2019/9 版)

leave a comment

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

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

Read the rest of this entry »

Written by masayuki.ozawa

9月 14th, 2019 at 10:30 pm

Posted in SQL Database

Tagged with

Hyperscale のトランザクションログの切り捨てタイミングについて

leave a comment

SQL Database の Single Database では、SQL Database バックアップとは に記載されているタイミングでトランザクションログのバックアップが取得され、ログの切り捨てが行われます。

Hyperscale の各種メトリクスを取得して分析すると気づくのですが、Hyperscale については、定期的な間隔ではなく、使用サイズによってトランザクションログの切り捨てが行われるような動作となっているように見えます。

このサイズが何によって決まっているのかを調べてみました。

Read the rest of this entry »

Written by masayuki.ozawa

8月 19th, 2019 at 12:36 am

Posted in SQL Database

Tagged with ,

SQL Data Warehouse のテーブルのデータの偏りによる性能影響

leave a comment

SQL Data Warehouse (SQL DW) は、60 のデータベースに分散してデータを格納した分散テーブルを使用して、透過的にデータを検索することで、効率よくデータを分析することができるアーキテクチャとなっています。

データの分散を適切に実施することがが性能を出す際の重要なポイントとなります。

「分散の方式を誤り、一つのデータベースにデータが極端に集中した場合、どのような性能的なデメリットが出るか」を数値的に取得したことがなかったため、確認をしてみました。

Read the rest of this entry »

Written by masayuki.ozawa

8月 17th, 2019 at 5:31 pm

Azure SQL Database の最新情報 (2019/7/13 版)

leave a comment

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

Read the rest of this entry »

Written by masayuki.ozawa

7月 14th, 2019 at 1:30 pm

Posted in SQL Database

Tagged with

SQL Database Hyperscale におけるセカンダリレプリカ上のデータ参照についての考慮点

leave a comment

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

SQL Database Hyperscale では、セカンダリレプリカの台数を 0 ~ 4 台まで指定することができます。

image

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

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

また、セカンダリの接続ですが、読み取りワークロードのインテリジェントな負荷分散がシステムで行われるか では「ランダムに接続される」ことになっており、複数台のセカンダリレプリカをデプロイしている場合、どのレプリカに接続されるかはランダムとなるようです。
(Build 2019 の内容では、ラウンドロビンとなっていたのですが、私が検証したときにはランダムのような動作となっていました)

今回の本題はそこではなく、「プライマリレプリカで更新 / 追加されたデータがセカンダリレプリカでどのように認識されるか」という点です、

Read the rest of this entry »

Written by masayuki.ozawa

7月 7th, 2019 at 11:54 pm

Posted in SQL Database

Tagged with ,

SQL Database Serverless の自動停止の最小時間が 1 時間に短縮されました (2019/7/6 版)

leave a comment

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

image

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

Azure SQL Database serverless (preview)

image

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

Written by masayuki.ozawa

7月 6th, 2019 at 7:47 pm

Posted in SQL Database

Tagged with ,

SQL Database の更新情報 (2019/6/13 版)

leave a comment

6/12 にいくつかの更新が発表されていましたのでまとめて確認しておこうかと。

Advanced Data Security available for SQL Server on Azure Virtual Machines

SQL Server on Azure VM で高度なデータセキュリティ機能が利用可能になりました。
SQL Database では以前から実装されていますが、この技術が IaaS の SQL Server でも使用できるようですね。

機能としては、次の 2 種類が使用できるようになるようです。

  • 脆弱性評価
  • 高度な脅威検知

次のような情報も併せて公開されていますね。

脅威検知については、現状は、通常とは異なるアクセスについての検知が利用できるようですが、SQL インジェクションのようなクエリ実行に対しての検知の提供も準備されているようですね。

 

Azure SQL Database Managed Instance でリージョンのリソース制限のサポートが拡大されました

Managed Instance はサブスクリプション内にデプロイできる数がかなり少なく制限されていたのですが、この制限が緩和されたようです。

image

以前はこのような制約でしたが、結構緩和されていますね。

image

最新のリソース制限については こちら を確認していただければ。

 

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

Written by masayuki.ozawa

6月 13th, 2019 at 11:26 pm