SE の雑記

クロスプラットフォームに対応した PowerShell である、PowerShell Core 6.0 に一部対応した SQL Server 用のモジュール (SqlServer) の提供が開始されました。
SQL Server 向けの PowerShell については、SSMS 17.0 以降は、PowerShell ギャラリーからインストールを行う方法に代わっています。
SQL Server PowerShell モジュールのインストール
最新版の SQL Server PowerShell モジュールである version 21.0.17240 から、PowerShell 6 Support が含まれるようになりました。
Read the rest of this entry »

何年も前に書いた sys.dm_os_performance_counters の情報取得時の注意点 の補足になります。
なぜ、このタイミングで改めて書いたかというと、sys.dm_os_performance_counters は、SQL Server on Linux で SQL Server のパフォーマンスを確認する際に重要な DMV となるからです。
SQL Database で情報を確認する場合にもこの DMV は重要となりますので、値の成型方法は覚えておいて損はないかと。

詳細については、次の情報も併せて確認してください。

• Interpreting the counter values from sys.dm_os_performance_counters
• 2.2.4.2 _PERF_COUNTER_REG_INFO

取得用のクエリについては sys.dm_os_performance_counters の加工.sql で、私が作ったものを公開していますので、ご参考になれば。

上述の DMV から取得した情報ですが、cntr_type に応じて、次の 3 種類の利用方法があります。

• 値をそのまま利用
  • cntr_type = 65792
• 2 点で情報を取得し、その差分の値を取得間隔で除算する
  • cntr_type = 272696320 / 272696576
• 2 種類の項目を使用して、その値を除算することパーセントを算出する
  • cntr_type = 537003264 / 1073874176

cntr_type に応じた、値の利用方法は次のようになります。

cntr_type = 65792 については、取得した値がそのまま利用可能で、大体の項目についてはこれに該当しているかと。
代表的なものとしては、Memory Manager の項目などがあります。

この項目の場合「SQL Server のメモリ使用量」を示すものとなり、取得した値を利用そのまま利用することが可能です。
(Pages となっている項目が存在することもありますが、その場合は、値に 8KB をかけることでサイズに変換できます)

cntr_type = 272696320 / 272696576 については、2 点で情報を取得し、その差分を取得間隔で除算することで利用することが可能です。
代表的なものとしては、SQL Statistics の項目などがあります。

この項目の例としては、「Batch Requests/sec」がよく使用するものとなるかと。

この項目は、秒間の SQL のバッチ実行数を表すものであり、SQL Server のインスタンスに対して、どの程度クエリが実行されているかを把握するために使用するものになるのですが、この項目を DMV から取得する場合には、瞬間の値だけをとればよいのではなく、必ず 2 点で取得する必要があります。
2 点で取得した結果が A1 (1 回目の取得) : 50 / A2 (2 回目の取得) : 100 で A1 / A2 の取得間隔が 10 秒だった場合、「(100 – 50) / 10 = 5 Batch Request / sec」となります。

cntr_type = 537003264 / 1073874176 については、2 つの項目をペアとして使用して、その値で除算することで利用することが可能です。
代表的なものとしては、Buffer Manager の項目などがあります。

この項目の例としては「Buffer cache hit ratio」がよく使用するものになるかと。
この項目は、バッファーキャッシュのヒット状況を表すものになるのですが、この項目単体では利用することはできず、ペアとなる値と組み合わせて使用する必要があります。

「Buffer cache hit ratio」の場合、「Buffer cache hit ratio base」がペアとなる値となります。
Buffer cache hit ratio の場合「Buffer cache hit ratio / Buffer cache hit ratio base * 100」というような計算を行うことで、キャッシュヒット率 (%) を算出することができます。

これらの加工方法を知っておくと、様々なモニタリングの仕組みで有効に活用できるかと。

SQL Server on Linux の場合、パフォーマンスモニターを使用した、パフォーマンス情報の取得ができませんので、SQL ベースで情報の取得ができるようになっていると、問題解決の即応性にもつながりますので。

モニタリングのソフトでは、「SQL を実行できるプラグイン」が含まれていることが多く、このようなデータ加工方法を知っておくと性能情報の取得にも役に立てることができるのではないでしょうか。
(時系列 DB だと、一つ前のデータとの差分抽出も簡単にできるものが多いですので、2 点間の差分も容易に出せます)

SQL Database でもこの方法は使用することができますので、「SQL Database の性能情報は DTU だけだとブラックボックス」と思っている方は、DMV から情報をブレークダウンすることに挑戦してみてはいかがでしょう。リソースの使用状況について、かなりの情報を取得することが可能です。

SQL Server on Linux の高可用性ソリューションとしては Pacemaker がドキュメントに記載されているものとなりますが、OSS のため、ベンダーサポートが必要となる環境では利用が難しいケースがあるかもしれません。
(Pacemaker で使用する SQL Server 向けのエージェントについては mssql-server-ha でソースが公開されています)

パートナーから提供されている SQL Server on Linux のソリューションについては、SQL Server の高可用性とディザスター リカバリーのパートナー で公開されており、RHEL / SUSE で使用することができる HPE Serviceguard の各種情報が公開されていました。
Serviceguard は、共有ディスク型の AlwaysOn フェールオーバークラスター と AlwaysOn 可用性グループの両方に対応したソリューションとなっているようです。
実際の動作については、デモ動画が公開されています。

• HPE Serviceguard solutions for SQL Server on Linux ? AOFI
• HPE Serviceguard solutions for SQL Server on Linux ? AOAI

デモだけでなく、ドキュメントも公開されています。

• HPE Serviceguard for Linux Certification Matrix
• HPE Serviceguard Solutions for Microsoft SQL Server for Linux User Guide

ベンダーサポートが必要となった場合の可用性のソリューションとして覚えておくとよさそうですね。
パッと見た感じ、トライアルが見当たらなかったのですが、トライアルライセンスとかないですかね…。
あれば、どのような動作になるか検証して情報発信したいなと思ったのですが。

Azure における VM バックアップ インフラストラクチャの計画を立てる に書かれている内容となりますが備忘録として。

Azure Backup で Azure 上の仮想マシンのバックアップを取得した場合、VSS と連動して取得が行われます。

Windows VM のスナップショットを取るとき、Backup サービスは Volume Shadow Copy Service (VSS) と連携して仮想マシンのディスクの一貫したスナップショットを取得します。

Windows に SQL Server をインストールすると「SQL Server VSS Writer」がインストールされ、この Writer が VSS と連動して、SQL Server としてのアプリケーション整合性を保持しながらバックアップの取得を行うことができるようになります。
ここで 1 点、注意しておきたいのが、

Azure Backup は、Windows VM 上で VSS 完全バックアップを行います ( VSS 完全バックアップの詳細をご覧ください)。

の記載です。
Read the rest of this entry »

先日、SQL Server Management Studio 17.5 がリリースされました。
Download SQL Server Management Studio (SSMS)
私が使いそうなもので、追加された機能としては、

• SQL Data Warehouse の EXPLAIN のグラフィカルな取得
• SQL Server 向けの「データ検出と分類」の機能追加

の 2 点でしょうか。
詳細については New in this Release に記載されていますのでそちらを参照してください。
Read the rest of this entry »

SQL Server はバージョンアップによって、Azure ストレージを使用して DB の領域として使用することができる機能が増えています。

• SQL Server 2012 SP1 CU2 以降 : バックアップの取得先として利用可能 (ブロック BLOB)
• SQL Server 2014 以降 : データベースのファイル格納先として利用可能
• SQL Server 2016 以降 : ページ BLOB を使用してバックアップを取得可能
• SQL Server 2017 以降 : メモリ最適化グループ用のファイルグループとして利用可能

Azure のストレージも、

• 汎用ストレージ v1
• 汎用ストレージ v2
• BLOB ストレージ

と様々なものがあります。
SQL Server のデータベースとしてどのようなものが使うことができるか一度整理してみました。
Read the rest of this entry »

まだ、作成途中ではありますが、SQL Server 2017 / SQL Database v12 向けのモニタリングクエリを https://github.com/MasayukiOzawa/MonitorDB で公開しています。

SQL Server 2017 on Windows については、データコレクションや、パフォーマンスモニターで各種情報を取得することができるのですが、現時点の SQL Server 2017 on Linux では、データコレクションが利用できず、パフォーマンスモニターに関しても Windows OS 側の機能なので利用することができません。
SQL Server のリソースの使用状況を確認する際に、パフォーマンスモニターの情報は有益であり、この情報を定期的に確認しないと、リソースの使用状況の把握が難しかったりもします。
sys.dm_os_performance_counters を使用することで、SQL Server のパフォーマンスモニターの情報を取得することが可能ですので、この情報を定期的にテーブルに取得することで、パフォーマンスモニターの代替としています。
SQL Server の場合は、次の手順で設定をしてください。

• 01.Create Database.sql を実行して DB を作成
• 02.Create Table.sql を実行して「MonitorDB」内に必要なテーブルを作成
• 01.Regular execution.sql を「MonitorDB」に対して実行して、定期的に情報を取得

SQL Server on Linux は Express でなければ、SQL Server Agent を使用することができるので、01.Regular execution.sql の内容を定期的に実行してもらえれば取得できるかと。
(Express の場合は、cron + sqlcmd で代替可能です)
SQL Database の場合は、02.Create Table.sql  を診断対象の DB に対して実行して、Azure Function のスケジュール実行等で、定期的に 01.Regular execution.sql を実行してください。
データを蓄積したままでは容量がかなり消費されますので、定期的に 02.Data Retention.sql を実行して削除もお忘れなく。
本来は、診断対象と同一 DB ではなく、別の DB に取得が推奨ですので、01 のクエリで取得したデータを BULK INSERT で診断用情報格納 DB で保持するのがいいので、スクリプトを作ったのですが、まだ公開できるように整備できていないので、現状は各自で実装していただければ。
RDB ではなく、時系列 DB に入れてしまってもよいかと。
領域の使用状況については、03.Data Usage Check.sql で確認することができますので、どれぐらい領域を使用しているかはこのクエリで確認していただければ。
数10秒間隔で取得すると、数時間でもそれなりなデータ量となりますので、取得間隔は適宜調整してください。
03.Search で、各種情報検索することが可能です。
ある程度のパターンを用意してありますので、必要に応じて類似のクエリで拡張していただければと。
投稿を書いている時点では、SQL Server / SQL Database 共通で使用することができるようにしています。
SQL Database は、リソースの使用状況を DTU で見ることが一般的かと思いますが、sys.dm_os_performance_counters を使用することでも、各種情報を取得することが可能ですので、今後の情報取得の一助となれば幸いです。

今まで、SQL Server のフィードバックサイトは connect を使用していました。
昨日までつながっていたので、気づいていなかったのですが、connect が廃止され新しいものに置き換わっています。

Microsoft Connect Has Been Retired

SQL Server (Connect Site ID 68)

Effective January 1, 2018, the community feedback feature of the Microsoft Connect site for SQL Server has been replicated in UserVoice for the convenience of the community. We have captured all current/active public feedback for SQL Server that was entered into Microsoft Connect and transferred it into the new forum to help customers find relevant and active matching suggestions.

SQL Server の新しいフィードバックサイトは feedback.azure.com の方に移行されていますので、今後はこちらを使うことになるようですね。

SQL Server 2017 と SQL Database で利用可能な方法ですが、これらのバージョンでは、クエリストアの情報として、待ち事象の情報が追加されています。
待機クエリの検索
クエリストア自体が強力な機能なのですが、最新のバージョンでは、この情報に sys.query_store_wait_stats システムビューが追加されています。
Read the rest of this entry »

OMS では標準機能として、syslog の連携機能を持っています
Log Analytics の Syslog データ ソース
上記のドキュメントに、次のように記載されているとおり、ファシリティ (Facility)と重要度 (Sevirity) で取得対象をフィルタすることができるようになっています。

OMS Agent for Linux は、構成で指定されているファシリティと重大度を持つイベントだけを収集します。 OMS ポータルを通じて、または Linux エージェントで構成ファイルを管理することによって、Syslog を構成できます。

Windows の場合、SQL Server 系のログがイベントログに出力されます。
Linux の場合は、syslog に出力されますので、syslog 経由でエラーの発生状況を監視することになるかと。
Read the rest of this entry »