SQL Server の tempdb では、ロギング最適化という動作により、トランザクションログの書き込みを最小限にするようにされています。
最近は、「SQL Server を使いこなす」という観点での勉強を進めており、その中でトランザクションログの書き込み内容の解析も多少できるようになってきましたので、tempdb のロギング最適化による、最小のログ記録の動作についても、実際のトランザクションログの書き込み内容を元にしてみていきたいと思います。
(本投稿の最小のログ記録については、一括挿入を実行する際等の最小ログ記録とは別の動作です)
Read the rest of this entry »
Archive for the ‘SQL Database’ tag
tempdb のロギング最適化による最小のログ記録の動作を確認してみる
SQL Database のリソース割り当てについてのドキュメントが公開されています
先日、SQL Database Hyperscale のパフォーマンスについては SQL Hyperscale のパフォーマンスのトラブルシューティング診断 で公開されていることを書きました。
通常の SQL Database についてもパフォーマンスの調査時に重要となるリソース割り当てについてのドキュメントが、いくつか公開されていたようです。
INSERT を例にしたトランザクションログの内容の確認
SQL Server のトランザクションログの内容を確認する際のアプローチとして「DBCC LOG 」や「sys.fn_dblog」を利用して内容を確認するという方法があります。
これらの DBCC や関数はアンドキュメントとなっており、詳細な情報は公開されていません。
CPU 使用率 / バッチ実行数との対比による Batch Resp Statistics の活用
SQL Server のパフォーマンスモニターとして、SQL Batch Resp Statistics という項目があります。
この項目は、SQL のクエリをバッチという単位で集計した際の次のような観点の情報を確認することができます。
- 特定の実行時間 (Elapsed Time) の範囲のバッチ実行回数とバッチ実行時間の合計
- 特定の CPU 使用時間 (CPU Time) の範囲のバッチ実行回数とバッチ実行時間の合計
この項目は「インスタンス内でどのような時間を消費しているクエリが実行されているか?」を把握するのに役に立つ情報となっており、単体でも便利なのですが、他の情報と組み合わせることでさらに活用の幅が広がります。
本投稿では、「CPU 使用時間の範囲のバッチ情報」を活用した方法についてまとめてみたいと思います。
Read the rest of this entry »
RaspberryPi 4B で Docker と IoT Edge ランタイムを起動するための準備
Azure SQL Database Edge は、x64 ならびに ARM64 のデバイス上で動作させることができる、コンテナーの SQL Server となります。
(SQL Server は、2016 以降は x86 は提供していないため、SQL Database Edge も x64 のみとなります)
SQL Database Edge を稼働させるための準備として、RaspberryPi 4B (ラズベリーパイ4 / ラズパイ4) を購入したので、下準備として Docker と IoT Edge ランタイムを動作させるまでの方法をメモとして残しておきたいと思います。
IoT 関連は全く触ってきておらず、ラズパイを使うのも初めてに近いので、そもそもとして間違っていることがあるかもしれません (
SQL Server のクエリプロファイリングの活用
SQL Server 2016 以降ではクエリプロファイリングにより、実行中のクエリの情報の分析容易性が向上しています。
この機能は、かなり強力であり、実行中のクエリに対して、様々なアプローチが可能となります。
活用の方法として「インデックスの再構築」と組み合わせた方法を紹介したいと思います。
今回は SQL Server 2017 を例としています。
Read the rest of this entry »
SQL Server の Wait Resource から実オブジェクトを判断する
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 »
待ち事象の情報のカウントアップされるタイミング
SQL Server では、「待ち事象」の情報を確認することでボトルネックの解析の一助とすることができます。
![]()
クエリを実行し、処理を実行する際には、次の状態を推移しながら処理が進められます。
「待機状態」に入っている処理については、何らかの処理の実行を阻害する要因があり、実行効率が低下している状態となっていると考えられます。
(阻害する要因はハードウェアリソースの性能限界や、ロックの競合のような論理的な要因等、様々なものがあります)
SQL Server では、DMV やパフォーマンスモニターで待ち事象 (待機状態に入っていた状態) の情報を取得することができますが、それぞれの情報が「どのようなタイミングでカウントアップされるか」ということを意識しておくことは重要なポイントの一つとなります。
それでは、各情報の取得と、待ち事象がカウントアップされるタイミングについて見ていきたいと思います。
Read the rest of this entry »
db tech showcase 2019 に登壇しました
この投稿が公開されたときには登壇中だと思いますが、セッションで使用した資料については、SlideShare で公開しています。
後日、db tech showcase のサイト でも資料と動画が公開される予定ですので、実施したデモなどに関しては後日公開の動画からご確認ください。
SQL Database に対して Private Link で接続をしてみる
先日、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 »