SQL Database の拡張イベントを永続化する場合、Azure ストレージに保存することになりますが、Azure ストレージの保存したログに関しては直接クエリで確認することができます。
クエリの実行に、CPU を結構喰うので、ローカルにダウンロードしてからの方がよいかと思いますが。
詳細については SQL Database の拡張イベントのためのイベント ファイル ターゲット コード を読むとよいかと
Archive for the ‘SQL Database’ Category
SQL Database のリソース使用状況を DTU 以外の観点で取得してみる
SQL Database では、DTU の使用状況で、リソースの使用状況を確認することができますが、それ以外の方法でも取得することができそうだったので、軽くメモを。
SQL Database のクエリのトレース方法について
SQL Database は SQL Server プロファイラで接続をすることができないため、SQL Server で使用する機会の多い、プロファイラを用いたクエリのトレースを実施することができません。
データベースエンジンの SQL Server プロファイラを使用したトレースに関しては、今後廃止される予定の機能となっているため、SQL Database 向けに提供されることはないと思います。
SQL Database のクエリのトレース方法については、拡張イベントで実施するのが一般的な方法になるかと。
SQL Data Warehouse で照合順序のサポートが強化されていたようです
今日、Stretch Database を設定していて気付いたのですが、SQL Data Warehoues で照合順序のサポートが強化されたようです。
# Stretch Database も裏は SQL Data Warehouse ですので。
Database collation support for Azure SQL Data Warehouse
How can we improve Microsoft Azure SQL Data Warehouse ? から始まった感じなのですかね。
リリース当初は「SQL_Latin1_General_CP1_CI_AS 」のみがサポートされていたかと思いますが、今の SQL DWH では、データベースの作成時に照合順序を指定できるようになっています。 
作成時にのみ指定できる感じのようですね。
CREATE DATABASE (Azure SQL Data Warehouse)
GitHub のヘルプを見ていると、日本語版のヘルプについては、9/6 に照合順序の記載が行われたようですので、GA したタイミングあたりで変更が行われていたのかもしれないですね。
この変更で、SQL Server 2016 の Stretch Database が適用できるデータベースの照合順序の制約も緩和されましたので、利用がはかどるのではないかと。
SQL Database で In-Memory OLTP が GA しました
General availability: In-Memory OLTP in Azure SQL Database Premium でアナウンスされていますが、SQL Database の In-Memory OLTP が GA したようです。
これについては Microsoft Azure SQL Database provides unparalleled performance with In-Memory technologies でもアナウンスされています。
PASS でアナウンスされていたタイミングより、早い GA なんですかね。
これで、Hybrid Transactional and Analytical Processing (HTAP) が SQL Database でも正式サービスとして使用できます。
詳細については Optimize Performance using In-Memory Technologies in SQL Database で確認ができますが、SQL Server 2016 相当の Operational Analytics が、SQL Database の Premium で利用できるようになった形でしょうか。
GA になって Elastic Pool でも In-Memory OLTP が使えるようになったようですね。
SQL Database options and performance: Understand what’s available in each service tier
Max in-memory OLTP storage (GB) per pool となっており、In-Memory OLTP ストレージの最大がプール単位決まっていますので、サイジングがちょっと悩ましいですが。
SQL Database の長期保有バックアップについて
先日 Azure SQL Database: Now supporting up to 10 years of Backup Retention (Public Preview) でアナウンスがされたのですが、あまり調べられていなかったので軽くまとめてみたいと思います。
SQL Database v12 におけるロック競合の取得
気づいたら SQL Database v12 でも、blocked_process_report によるロック競合が発生したクエリの情報が取得できるようになっていました。
クエリストアによる、クエリタイムアウトしたクエリの取得
SQL Server 2016 / SQL Database v12 で使用できるクエリストアの機能では、正常終了したクエリだけでなく、異常終了したクエリについても情報が取得されています。
異常終了したクエリから、クエリタイムアウト (コマンドタイムアウト) したクエリの情報の取得について考えてみたいと思います。
クエリストアの情報については、かなり日本語化されたものが出てきていますので、クエリ ストアがデータを収集するしくみ を一読しておくとよいかと。
Read the rest of this entry »
クエリストアから特定のクエリの情報を取得する
Ignite のセッションを見ていたところ、クエリストアの活用方法がいろいろと紹介されていて、実践的な方法がかなり勉強になりました。
SQL Server 2016 にアップグレードした際に、
- クエリストアを有効にする
- アップブレード前の互換性レベルで、テスト用のワークロードを実行
- 互換性レベル 130 に変更
- 再度、テスト用のワークロードを実行
- 実行効率が低下したクエリを確認し、必要に応じて、プランの強制を実施
という手順を行い、アップグレード後のクエリの実行効率の低下を防止するという手法についてはなるほどと思いました。
クエリストアでは、実行効率が低下したクエリや、リソースの消費量の高いクエリについては、SSMS から取得することができます。
特定のクエリの状態を取得したい場合は「追跡したクエリ」を使用することになるかと思いますが、この取得では「クエリ ID」を指定して情報の取得を行う必要があります。
特定のクエリについての情報を見たい場合のクエリ ID の特定について、少し考えてみました。
Ignite 2016 の SQL Server のデータベースエンジン関連のセッション
Ignite 2016 のセッションですが、Microsoft Ignite On-Demand で動画が公開されてています。
とりあえず、SQL Server のデータベースエンジン関連のセッションを流し見しているのですが、エンジン回りで関連しそうなセッションの紹介を。
最近、英語が苦手なのが致命的に響いてきていて、ひさしになんとかしてもらわないと生きていくのがつらいです…。
スライドについても公開されていて、 Ignite 2016 Slidedeck and Video downloader で一括でダウンロードできるようです。