Azure SQL Database の各種メトリックを取得する方法ですがいくつかの方法が提供されており、簡単に使いだすことができます。
どのようなものがあり、どこから確認するかを忘れるときが結構ありますので、一度まとめておこうかと。
Read the rest of this entry »
Author Archive
Azure SQL Database のメトリックの収集方法の基本 (2019/9 版)
クエリを使用した SQL Server の CPU 使用率の取得
SQL Server の CPU 使用率を取得する場合、パフォーマンスモニターや Workload Group Stats の情報を使用して、情報の取得を行うことがあります。
パフォーマンスモニターについては、OS 周りの権限が付与されていない (RDS等) 場合は使用することができません。
Workload Group Stats については、Enterprise Edition であれば、Default Pool 等の Internal 以外の Pool の情報を取得することで活用することができますが、Standard Edition では、リソースガバナーが使用できないため、Pool 単位の情報を取得することができません。
また、上記の情報は「現在の値」を取得するため、事前にメトリクスの取得を設定しておかないと、確認できないという課題もあります。
Standard Edition や直近、数時間で構わないので、過去にさかのぼって CPU の使用率を取得する場合、リングバッファーの情報を活用するという方法を使用することができます。
SQL Database では、想定している情報が取得できないようですが、SQL Server であれば、2012 以降では動いていると思いますので、その方法を。
Read the rest of this entry »
SQL Server の「NOLOCK」ヒントは単純なロックを取得しないという動作ではありません
SQL Server には「NOLOCK」というヒント句があります。
基本的な動作については ヒント (Transact-SQL) – Table に記述があり、このドキュメントには次のように記載されています。
READUNCOMMITTED ヒントと NOLOCK ヒントはデータのロックにのみ適用されます。 READUNCOMMITTED ヒントおよび NOLOCK ヒントを含むクエリを含め、すべてのクエリは、コンパイル中と実行中にスキーマ安定度 (Sch-S) ロックを取得します。 このため、同時実行トランザクションがテーブルの Sch-M (スキーマ修正) ロックを保持している場合、クエリはブロックされます。 たとえば、データ定義言語 (DDL) 操作では、テーブルのスキーマ情報を変更する前にスキーマ修正 (Sch-M) ロックを取得します。 READUNCOMMITTED ヒントまたは NOLOCK ヒントを指定して実行しているクエリを含め、すべての同時実行クエリは、スキーマ安定度 (Sch-S) ロックを取得しようとするとブロックされます。 一方、スキーマ安定度 (Sch-S) ロックを保持するクエリによって、スキーマ修正 (Sch-M) ロックを取得しようとする同時実行トランザクションはブロックされます。
ロックについては「Sch-S」のロックが取得され、それ以外のロックについては取られないという動作となる記述がありますが、これ以外の動作として「ダーティーリードを許可する」という動作については意識をしておく必要があります。
これについては、次の記事でも触れられています。
- Previously committed rows might be missed if NOLOCK hint is used
- Using NOLOCK? Here’s How You’ll Get the Wrong Query Results.
- “But NOLOCK Is Okay When The Data Isn’t Changing, Right?”
単純なパターンであれば、「コミット前のデータが読み取られるがロック競合を防ぎながらデータにアクセスができる」という用途で使うケースがありますが、それ以外のダーティーページが読み取られる可能性についても考慮しておく必要があります。
Read the rest of this entry »
Agent 1433: remote attack on Microsoft SQL Server を読んでみる
Twitter の TL を眺めていたところ、Agent 1433: remote attack on Microsoft SQL Server が話題になっていましたので、どのような内容なのかを軽く確認してみました。
日本語は、マイナビニュースさんの 世界中で攻撃を受けるMicrosoft SQL Server、パスワードの見直しを で情報を公開されていたようです。
今回の攻撃ですが「直近の数日間で発生した攻撃」ではなく、Kaspersky Lab から公開された、「2019年1月～7月」の期間で、SQL Server の SQL Server Agent を利用した攻撃についての情報となるようです。
「この攻撃がどのような期間で猛威を振るっていたの / 現在も振るっているのか？」は、どのように情報を読むかによって変わってくるのではないでしょうか。
Read the rest of this entry »
Accelerated Database Recovery を実現するために使用されている Persistent Version Store について
SQL Database / SQL Server 2019 では、Accelerated Database Recovery (ADR : 高速データベース復旧) という機能が追加されています。
この機能は、予測可能な一定時間でのデータベースの回復 (Constant Time Recovery : CTR) を実現するために実装されたものであり、次のようなことを実現することができるようになります。
- 大量のトランザクションのロールバックの高速化
- SQL Server サービス起動時のデータベース復旧の高速化
- トランザクションログの積極的な切り捨て
ADR を実現するために、SQL Server では新しく次のような概念が入っています。
- Persistent Version Store (永続化バージョンボリュームストア) : PVS
- Secondary Log Stream : sLog
この中の PVS について、調べる機会がありましたので、調べた内容をまとめておきたいと思います。
ADR の詳細については、Accelerated Database Recovery in SQL Server 2019 か、Microsoft が公開している論文の Constant Time Recovery in Azure SQL Database で解説されています。
(論文の方はまだ半分ぐらいまでしか読めておらず…)
Read the rest of this entry »
SQL Server 2019 RC1 が公開されました
月次で公開されている SQL Server 2019 の新しい Preview ですが、CTP (Community Technical Preview) から RC (Release Candidate : 製品候補版) に変わり、First RC となる RC1 が公開されました。
アナウンスはこちらから
- SQL Server 2019 release candidate is now available
- What’s new for SQL Server 2019 Analysis Services RC1
- What’s new for SQL Server 2019 Reporting Services RC1
- SQL Server 2019 release candidate refresh with Big Data Clusters
ドキュメントはこちらから
2019/8/29 に Big Data Cluster も RC1 がリリースされました。
Hyperscale のトランザクションログの切り捨てタイミングについて
SQL Database の Single Database では、SQL Database バックアップとは に記載されているタイミングでトランザクションログのバックアップが取得され、ログの切り捨てが行われます。
Hyperscale の各種メトリクスを取得して分析すると気づくのですが、Hyperscale については、定期的な間隔ではなく、使用サイズによってトランザクションログの切り捨てが行われるような動作となっているように見えます。
このサイズが何によって決まっているのかを調べてみました。
Read the rest of this entry »
SQL Data Warehouse のテーブルのデータの偏りによる性能影響
SQL Data Warehouse (SQL DW) は、60 のデータベースに分散してデータを格納した分散テーブルを使用して、透過的にデータを検索することで、効率よくデータを分析することができるアーキテクチャとなっています。
データの分散を適切に実施することがが性能を出す際の重要なポイントとなります。
「分散の方式を誤り、一つのデータベースにデータが極端に集中した場合、どのような性能的なデメリットが出るか」を数値的に取得したことがなかったため、確認をしてみました。
Read the rest of this entry »
コンピューターのグループポリシーの情報をレジストリから取得する
グループポリシーの適用状況を確認する際に「gpresult /R」や「rsop.msc」を使って情報の確認をすることがあるかと思います。
リモートからグループポリシーの適用状況を確認しようとした場合、これら以外の方法で取得できないかを考えたところ、「コンピューターのグループポリシー」であれば、レジストリからも情報が取得することができるようです。
Read the rest of this entry »
リリースが終え、ひと段落しての感想
リリース作業が終えて、ひと段落してきましたので、リリースからの感想を。
本投稿は、技術的な要素はないので本当に雑記です。
何のリリースなのかは本文を読んでいるとわかるかもしれませんし、わからないかもしれません。
Read the rest of this entry »