SQL Server 2016 以降ではクエリプロファイリングにより、実行中のクエリの情報の分析容易性が向上しています。
この機能は、かなり強力であり、実行中のクエリに対して、様々なアプローチが可能となります。
活用の方法として「インデックスの再構築」と組み合わせた方法を紹介したいと思います。
今回は SQL Server 2017 を例としています。
Read the rest of this entry »
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
SQL Server 2016 以降ではクエリプロファイリングにより、実行中のクエリの情報の分析容易性が向上しています。
この機能は、かなり強力であり、実行中のクエリに対して、様々なアプローチが可能となります。
活用の方法として「インデックスの再構築」と組み合わせた方法を紹介したいと思います。
今回は SQL Server 2017 を例としています。
Read the rest of this entry »
SQL Server の sys.dm_exec_requests や、sys.dm_tran_locks 等の DMV では、どのオブジェクトに起因して待機が発生しているかというリソースの情報が出力されることがあります。
![]()
本投稿では、待機要因となっているリソースの見方について見ていきます。
英語の情報となりますが、Decoding Key and Page WaitResource for Deadlocks and Blocking が詳しいかと思います。
Read the rest of this entry »
この投稿が公開されたときには登壇中だと思いますが、セッションで使用した資料については、SlideShare で公開しています。
後日、db tech showcase のサイト でも資料と動画が公開される予定ですので、実施したデモなどに関しては後日公開の動画からご確認ください。
先日、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 »
先日投稿した SQL Server の「NOLOCK」ヒントは単純なロックを取得しないという動作ではありません の内容に近いものですが。
NOLOCK ロックヒントを設定しても発生する待ち事象について少し書いておきたいと思います。
先日書いた投稿は NOLOCK ロックヒントを使用すると整合性のあるデータへのアクセスが保証されないため、COUNT(*) を実行すると、データの総数が変わっていないが、データの件数が一定しないというものでした。
今回の投稿は「PAGELATCH」による待ちが発生するというものです。
Read the rest of this entry »
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 »
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 »