SE の雑記

先日、Private Link がプレビューで公開されました。

• Announcing Azure Private Link Preview
• Announcing Azure 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 セカンダリサーバーが追いつけなくなると性能調整が行われるようになりました。

• New Active geo-replication optimization is coming to production soon in Azure SQL DB
• セカンダリ データベースの構成
• HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO

この調整が発生すると、どのような 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 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」というヒント句があります。

基本的な動作については ヒント (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 »

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 »

SQL Database / SQL Server 2019 では、Accelerated Database Recovery (ADR : 高速データベース復旧) という機能が追加されています。

• 復元と復旧の概要 (SQL Server)
• 高速データベース復旧

この機能は、予測可能な一定時間でのデータベースの回復 (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 の新しい 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
  • Microsoft SQL Server 2019 Reporting Services Preview
  • Microsoft® Report Builder
• SQL Server 2019 release candidate refresh with Big Data Clusters

ドキュメントはこちらから

• What’s new in SQL Server 2019
• SQL Server 2019 preview release notes

2019/8/29 に Big Data Cluster も RC1 がリリースされました。

• Release notes for big data clusters on SQL Server

Read the rest of this entry »

SQL Database の Single Database では、SQL Database バックアップとは に記載されているタイミングでトランザクションログのバックアップが取得され、ログの切り捨てが行われます。

Hyperscale の各種メトリクスを取得して分析すると気づくのですが、Hyperscale については、定期的な間隔ではなく、使用サイズによってトランザクションログの切り捨てが行われるような動作となっているように見えます。

このサイズが何によって決まっているのかを調べてみました。

Read the rest of this entry »