SE の雑記

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

Archive for the ‘SQL Database’ Category

「待ち事象」を起点とした SQL Server のボトルネックの調査の基本 その 1

leave a comment

先日、ZOZOTOWNで最大級のトラフィックを記録する福袋発売イベントで実施した負荷対策 という、ZOZOTOWN さんの負荷対策についての記事が公開されました。

はてブをみると、かなりの方がブックマークをされているようですね。

私も案件の中で、ボトルネック調査をすることがあるのですが、その際の基本的なアプローチをまとめる、良い機会かなと思って本投稿を書いてみました。

 

ボトルネックを調査する対象となる環境はどのようなものか?

ボトルネックの調査を行うための環境ですが、色々ケースがあるかと思います。

例えば、次のようなものがあるのではないでしょうか。

  • 自分が保守に携わっている本番環境で発生するパフォーマンス問題
  • 開発環境で発生するパフォーマンス問題
  • 特定のタイミング (例 : 夜間バッチ) 発生するパフォーマンス問題

ここ数年はフリーランスとして業務をしているため、保守 / 運用を通して「自分が恒常的に面倒を見ているシステムに対してのボトルネック解消」を受けるような機会はありません。
私がボトルネックの調査に携わる機会が多いのは、次のようなケースです。

  • 自分が開発 / 保守に携わっておらず、システムの中身が全くわからない環境で発生しているパフォーマンス問題

このようなケースのパフォーマンス問題に対しての調査の依頼というものは、毎年相談を受けます。

本投稿は、「自分が中身を知っているシステムではない環境」でパフォーマンスのボトルネックを調査する場合の、私が実際に行っているアプローチの一つとなります。

 

Read the rest of this entry »

Written by masayuki.ozawa

1月 3rd, 2019 at 11:24 pm

Azure SQL Database Hyperscale のデータアクセスの基本パターンを調べてみる

leave a comment

Azure SQL Database の新しいサービスレベルである、Hyperscale が現在、Preview のサービスですが提供されています。

現時点で公式に公開されている情報としては、次のような内容でしょうか。

概要については、これらの情報から確認できるのですが、実際にどのようなデータアクセスが行われるのかが公開されていなかったので、可能な範囲で調べてみました。

Read the rest of this entry »

Written by masayuki.ozawa

12月 9th, 2018 at 1:04 pm

Posted in SQL Database

Tagged with ,

SQL Database で軽量なクエリプロファイリングを使用し、「実行中のクエリの情報」を取得する

leave a comment

SQL Database の DB エンジンのバージョンですが、本投稿を書いている時点では、SQL Server 2019 CTP 2.0 相当のバージョンとなっています。

SQL Server 2019 では、SQL Server 2016 SP1 で導入が行われた、軽量なクエリプロファイリングがデフォルトで有効になっており、DB レベルの設定として、有効 / 無効の変更ができるようになります。

Lightweight query profiling infrastructure

SQL Database の DB エンジンが 2019 相当になったので、使用できるかどうか試してみました。
結論を書くと、使用できるようになっています。

Read the rest of this entry »

Written by masayuki.ozawa

11月 14th, 2018 at 10:14 pm

Posted in SQL Database

Tagged with

DMS の Managed Instance のオンライン移行が Preview 機能として使用できるようになりました

leave a comment

Ignite 2018 の前後で使えるようになった機能なのですが、Azure SQL Database Managed Instance に対して、Database Migration Services のオンライン移行 (Online Migration) の機能が使用できるようになりました。

MI については、SQL Server からのオンライン移行が可能となっています。
image

オンライン移行については「ビジネスクリティカル (Business Critical)」でのみ、使用できる機能となります。
Preview 開始当初は「オンライン移行機能」が使用できるリージョンは限定的なもので、日本ではオンライン移行を使うことができなかったのですが、使用可能なリージョンが拡充されて、今は使えるようになったみたいですね。
投稿を書くにあたり、東日本の DMS で試してみましたが正常に移行することができました。

DMS でオンライン移行が使えないリージョンからデータを移行したい場合は、DMS の仮想ネットワークと移行対象の SQL Server / MI を VPN 接続することで回避できますので、ネットワーク構成によって、移行元 / 移行先は柔軟に対応できるかと。

ドキュメントとしては DMS を使用して、SQL Server を Azure SQL Data で公開されているのですが、この情報では少し足りていない箇所がありますので、検証する際のポイントを補足しておきたいと思います。

Read the rest of this entry »

Written by masayuki.ozawa

10月 27th, 2018 at 3:40 pm

クエリ単位で互換性レベルを変更する

leave a comment

すっかり忘れていたのですが、SQL Server 2017 CU10 以降で QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n というヒントが追加されていたことを思い出したのでメモとして。

 

Read the rest of this entry »

Written by masayuki.ozawa

10月 19th, 2018 at 7:23 am

SQL Database の Hyperscale (プレビュー) がデプロイ可能になっています

leave a comment

Ignite 2018 でアナウンスのあった SQL Database の Hyperscale がデプロイ可能になりました。

image

使用できるリージョンは Hyperscale service tier available regions で公開されており、東日本も対象となっていました。

ざっと試してみたところ DTU と vCore モデルからの移行はサポートされているようでした。
ただし、当初アナウンスがあったとおり、Hyperscale に変更した後は、他のモデルに戻すことができませんので、そこは気を付けておいたほうが良いかと。
(検証の際は DB のコピーやレプリカを作ってから検証した方が良いです)

SQL Database 向けの CREATE DATABASE / ALTER DATABASE も Hyperscale に対応していますので SQL からも実行可能です。

Written by masayuki.ozawa

10月 4th, 2018 at 9:36 am

Posted in SQL Database

Tagged with ,

Ignite 2018 で発表された SQL Database の Hyperscale サービス層の情報

leave a comment

Ignite 2018 で SQL Database の新しいサービス層である Hyperscale が発表されました。
2018/10/1 の Public Preview の開始前にいろいろと情報が公開されていますので、メモとして。

Read the rest of this entry »

Written by masayuki.ozawa

9月 30th, 2018 at 2:57 pm

Posted in SQL Database

Tagged with ,

Ignite 2018 の SQL Database の Update

leave a comment

SQL Server 2019 だけでなく、Azure の SQL Server ベースについても様々なアナウンスがありました。

Read the rest of this entry »

Written by masayuki.ozawa

9月 25th, 2018 at 12:40 am

Posted in SQL Database

Tagged with

SQL Database で実装済みの Intelligent Query Processing について

leave a comment

SQL Server 2017 では、Adaptive Query Processing というクエリ実行の最適化が導入されました。
クエリを再コンパイルすことなく、一部の実行プランの操作を処理対象のデータに適応した形で実行する処理であり、互換性レベル 140 に設定することで、適用される機能となっています。

上記の画像は、ドキュメントから取得したものなのですが、適応対象となる処理は一部のもので、「バッチモード」が対象となっていました。
SQL Server 2017 では、バッチモードで実行されるのは、「列ストアインデックス」が使用される場合となっており、Adaptive Query Processing が適用されるのは、かなり限定的なものとなっていました。

初出は PASS Summit だとおもいますが、これの一歩進んだものが、SQL Database では「Intelligent Query Processing」として、プレビュー機能として提供が行われている、次代の互換性レベルである、互換性レベル「150」で使用することができるようになっています。

Intteligent Query Processin は Adaptive Query Processing を発展させたものであり、従来からの Adaptive Query Processing に加えて、対象が次のように増加しています。

image

新たに実装されたのは次の 3 種類となります。

  • Approximate Count Distinc
  • Row Mode Memory Grant Feedback
  • Table Variable Deferred Compilation

7 月の段階で細かな情報が公開されていますが、簡単に動作をまとめて置こうかと。

Read the rest of this entry »

Written by masayuki.ozawa

9月 17th, 2018 at 5:41 pm

Azure の DMS で SQL Server の主キー無しテーブルのオンライン データ マイグレーションを実行する際の注意点

leave a comment

Azure の Data Migration Service (DMS) では、オンライン データ マイグレーションが実行できるようになり、投稿を書いている時点では、SQL Server から SQL Database への移行と、MySQL から Azure Database for MySQL への移行に対応しています。

SQL Server のデータ移行については、「主キーが設定されていないテーブルを CDC (変更データキャプチャ) で移行することができる」という特徴があるのですが、この機能を利用する際の動作について、注意点がありますのでまとめておきたいと思います。

この内容については、SR で確認をしたのですが、DMS の内部的な動作の制限のようで、現状記載がされている箇所がないので、ドキュメントへの反映を検討してくださるとのことでした。

注意点の内容ですが「主キーが設定されていないテーブルを移行する際に、初期データの移行と増分データの移行のタイミングによっては、データが重複されてしまう」という動作についてです。

初期のデータ移行をオフラインで実行できる / 初期同期が高速に行えるデータ量, 処理性能であればたぶん発生しないですが、大量のデータの初期同期や、SQL Database の性能の設定によっては発生する確率は高いかと。

Read the rest of this entry »

Written by masayuki.ozawa

9月 9th, 2018 at 7:36 pm

Posted in SQL Database

Tagged with ,