SE の雑記

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

SQL Server 2016 / 2017 の最新情報

leave a comment

■ドキュメント
– SQL Server 2016 –
SQL Server 2016
What’s New in SQL Server 2016
What’s New in Database Engine
SQL Server 2016 Release Notes 
SQL Server 2016 Service Pack 1release information
Features Supported by the Editions of SQL Server 2016

■モジュール
SQL Server Evaluations
Download SQL Server Management Studio
Download Latest SQL Server Data Tools
microsoft/mssql-server-windows
microsoft/mssql-server-linux

■動画
SQL Server Data Driven: Technical Deep Dive
Microsoft SQL Server 2016
Intelligent Apps & Data

Written by masayuki.ozawa

7月 26th, 2015 at 10:22 am

Posted in SQL Server

Tagged with ,

SQL Database に対して Private Link で接続をしてみる

leave a comment

先日、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 »

Written by masayuki.ozawa

9月 19th, 2019 at 7:33 pm

Posted in SQL Database

Tagged with ,

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

HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO によるトランザクションログの書き込み性能の低下について

leave a comment

2019/6 に SQL Database の変更が入り、Geo レプリケーションが有効な環境で異なるサービスレベルを使用している場合に、プライマリサーバーの更新に Geo セカンダリサーバーが追いつけなくなると性能調整が行われるようになりました。

この調整が発生すると、どのような I/O 傾向になるのかを把握しておくことは重要です。

Geo レプリケーションのセカンダリが下に構成されているときに発生しますプライマリよりもサイズ (低い SLO) を計算します。 プライマリ データベースは、遅延のログの使用量のため、セカンダリで調整されます。 これは、セカンダリ データベースの変更率が、プライマリ データベースの遅れが不足しているコンピューティング容量を持つことが原因です。

となっているので、ドキュメント上は、プライマリと Geo セカンダリの性能を変えている (Geo セカンダリの方の性能を下に設定している) 場合に、調整が行われる可能性が出てきます。

本投稿では、調整が発生することで、どのような I/O 性能の低下を招くかを見てみたいと思います。

今回、検証で使用したスクリプトについては https://gist.github.com/MasayukiOzawa/e3a2ff81628d074eacf4664e36d5ecfb に残してありますので、興味のある方はカスタマイズして試していただければ。

Read the rest of this entry »

Written by masayuki.ozawa

9月 15th, 2019 at 5:03 pm

Azure SQL Database のメトリックの収集方法の基本 (2019/9 版)

leave a comment

Azure SQL Database の各種メトリックを取得する方法ですがいくつかの方法が提供されており、簡単に使いだすことができます。

どのようなものがあり、どこから確認するかを忘れるときが結構ありますので、一度まとめておこうかと。

Read the rest of this entry »

Written by masayuki.ozawa

9月 14th, 2019 at 10:30 pm

Posted in SQL Database

Tagged with

クエリを使用した 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 ,

SQL Server 2019 RC1 が公開されました

leave a comment

月次で公開されている SQL Server 2019 の新しい Preview ですが、CTP (Community Technical Preview) から RC (Release Candidate : 製品候補版) に変わり、First RC となる RC1 が公開されました。

アナウンスはこちらから

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

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

Read the rest of this entry »

Written by masayuki.ozawa

8月 22nd, 2019 at 10:00 am

Posted in SQL Server

Tagged with ,

Hyperscale のトランザクションログの切り捨てタイミングについて

leave a comment

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

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

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

Read the rest of this entry »

Written by masayuki.ozawa

8月 19th, 2019 at 12:36 am

Posted in SQL Database

Tagged with ,