SE の雑記

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

Archive for the ‘SQL Server’ tag

SQL Server 2019 関連の書籍

leave a comment

SQL Server 2019 も RC1 が提供され、GA (一般提供) に向けて、着々と開発が進められているかと思います。
洋書にはなるのですが、SQL Server 2019 関連のものがいくつかリリース予定となっていますので、備忘録を兼ねて。

洋書はサブスクリプションモデルで閲覧できたり、$10 でセールをしている時があったりしますので、お得な購入方法がいろいろあるかと。
(Safari Books Online のサブスクリプションで見れる書籍の中にも入っていたかと)

Microsoft Press

Apress

PacktPub

Written by masayuki.ozawa

10月 14th, 2019 at 9:18 pm

Posted in SQL Server

Tagged with ,

SQL Server のクエリプロファイリングの活用

leave a comment

SQL Server 2016 以降ではクエリプロファイリングにより、実行中のクエリの情報の分析容易性が向上しています。

この機能は、かなり強力であり、実行中のクエリに対して、様々なアプローチが可能となります。
活用の方法として「インデックスの再構築」と組み合わせた方法を紹介したいと思います。

今回は SQL Server 2017 を例としています。

Read the rest of this entry »

Written by masayuki.ozawa

10月 6th, 2019 at 9:56 pm

SQL Server の Wait Resource から実オブジェクトを判断する

leave a comment

SQL Server の sys.dm_exec_requests や、sys.dm_tran_locks 等の DMV では、どのオブジェクトに起因して待機が発生しているかというリソースの情報が出力されることがあります。

image

本投稿では、待機要因となっているリソースの見方について見ていきます。

英語の情報となりますが、Decoding Key and Page WaitResource for Deadlocks and Blocking が詳しいかと思います。

Read the rest of this entry »

Written by masayuki.ozawa

10月 6th, 2019 at 4:57 pm

待ち事象の情報のカウントアップされるタイミング

leave a comment

SQL Server では、「待ち事象」の情報を確認することでボトルネックの解析の一助とすることができます。

image

クエリを実行し、処理を実行する際には、次の状態を推移しながら処理が進められます。
「待機状態」に入っている処理については、何らかの処理の実行を阻害する要因があり、実行効率が低下している状態となっていると考えられます。
(阻害する要因はハードウェアリソースの性能限界や、ロックの競合のような論理的な要因等、様々なものがあります)

SQL Server では、DMV やパフォーマンスモニターで待ち事象 (待機状態に入っていた状態) の情報を取得することができますが、それぞれの情報が「どのようなタイミングでカウントアップされるか」ということを意識しておくことは重要なポイントの一つとなります。

それでは、各情報の取得と、待ち事象がカウントアップされるタイミングについて見ていきたいと思います。

Read the rest of this entry »

Written by masayuki.ozawa

10月 5th, 2019 at 10:53 pm

Posted in SQL Server

Tagged with ,

db tech showcase 2019 に登壇しました

leave a comment

この投稿が公開されたときには登壇中だと思いますが、セッションで使用した資料については、SlideShare で公開しています。

後日、db tech showcase のサイト でも資料と動画が公開される予定ですので、実施したデモなどに関しては後日公開の動画からご確認ください。

Written by masayuki.ozawa

9月 25th, 2019 at 12:56 pm

SELECT を NOLOCK で実行しても発生する待ち事象について

leave a comment

先日投稿した SQL Server の「NOLOCK」ヒントは単純なロックを取得しないという動作ではありません の内容に近いものですが。

NOLOCK ロックヒントを設定しても発生する待ち事象について少し書いておきたいと思います。

先日書いた投稿は NOLOCK ロックヒントを使用すると整合性のあるデータへのアクセスが保証されないため、COUNT(*) を実行すると、データの総数が変わっていないが、データの件数が一定しないというものでした。

今回の投稿は「PAGELATCH」による待ちが発生するというものです。

Read the rest of this entry »

Written by masayuki.ozawa

9月 15th, 2019 at 10:32 pm

クエリを使用した SQL Server の CPU 使用率の取得

leave a comment

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 »

Written by masayuki.ozawa

9月 13th, 2019 at 8:00 am

Posted in SQL Server

Tagged with

SQL Server の「NOLOCK」ヒントは単純なロックを取得しないという動作ではありません

leave a comment

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」のロックが取得され、それ以外のロックについては取られないという動作となる記述がありますが、これ以外の動作として「ダーティーリードを許可する」という動作については意識をしておく必要があります。

これについては、次の記事でも触れられています。

単純なパターンであれば、「コミット前のデータが読み取られるがロック競合を防ぎながらデータにアクセスができる」という用途で使うケースがありますが、それ以外のダーティーページが読み取られる可能性についても考慮しておく必要があります。

Read the rest of this entry »

Written by masayuki.ozawa

9月 11th, 2019 at 11:33 pm

Posted in SQL Server

Tagged with

Agent 1433: remote attack on Microsoft SQL Server を読んでみる

leave a comment

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 »

Written by masayuki.ozawa

8月 25th, 2019 at 2:44 pm

Posted in SQL Server

Tagged with

Accelerated Database Recovery を実現するために使用されている Persistent Version Store について

leave a comment

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 »

Written by masayuki.ozawa

8月 24th, 2019 at 9:02 pm

Posted in SQL Server

Tagged with ,