先日発表された、SQL Database の vCore モデルと従来型の DTU モデルの比較を。
内容としては次の情報の内容をベースとしています。
- アナウンス
- 料金
- ドキュメント
Author Archive
SQL Database の DTU と vCore をざっくり比較してみる
SQL Database で様々なアップデートが発表されています (2018/4/5)
実際の動作までは確認できていないのですが、SQL Database で様々なアップデートが発表されました。
- 長期的なバックアップ保有期間 (Preview) のアップデート
- 読み取りスケールアウトのサポート (Preview)
- 新しい利用モデル (vCore モデル) の追加
それぞれについて、ざっくりとみていきたいと思います。
Read the rest of this entry »
sys.dm_os_performance_counters でパフォーマンスモニターの情報を取得する際のポイント
何年も前に書いた sys.dm_os_performance_counters の情報取得時の注意点 の補足になります。
なぜ、このタイミングで改めて書いたかというと、sys.dm_os_performance_counters は、SQL Server on Linux で SQL Server のパフォーマンスを確認する際に重要な DMV となるからです。
SQL Database で情報を確認する場合にもこの DMV は重要となりますので、値の成型方法は覚えておいて損はないかと。
詳細については、次の情報も併せて確認してください。
取得用のクエリについては 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 | 16進値 | カウンターのタイプ | |
| 65792 | 0x00010100 | PERF_COUNTER_LARGE_RAWCOUNT | 瞬間的な値を示す 64 ビット値 (値をそのまま利用可能) |
| 272696320 | 0x10410400 | PERF_COUNTER_COUNTER | 1 秒あたりのイベント発生率を示す 32 ビット値
後続の値との差を取り、2つの値のタイムスタンプの秒数で除算する(A2 – A1) / (A2 Timstamp – A1 Timestamp) |
| 272696576 | 0x10410500 | PERF_COUNTER_BULK_COUNT | 1 秒あたりのイベント発生率を示す 64 ビット値
後続の値との差を取り、2つの値のタイムスタンプの秒数で除算する(A2 – A1) / (A2 Timstamp – A1 Timestamp) |
| 537003264 | 0x20020500 | PERF_LARGE_RAW_FRACTION | 比率をパーセントで表すことができる 64 ビット値Base Counter の値で除算することで、比率を算出できるRAW_FRACTION / RAW_BASE * 100 |
| 1073939712 | 0x40030500 | PERF_LARGE_RAW_BASE | PERF_LARGE_RAW_FRACTION との計算で使用される 64 ビット値 |
| 1073874176 | 0x40020500 | PERF_AVERAGE_BULK | 平均メトリックを示すために使用される 64 </ span>ビット値後続の値との差を取り、後続の Base Counter の差で除算する(A2 – A1) / (A2 Base – A1 Base) |
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 から情報をブレークダウンすることに挑戦してみてはいかがでしょう。リソースの使用状況について、かなりの情報を取得することが可能です。
Azure Virtual Machine のシリアルコンソール (Preview) を Windows で使用する際の覚書
Public preview: Virtual machine serial console でアナウンスがありましたが、Azure VM のシリアルコンソール接続が Public Preview となりました。
ドキュメントについては Virtual machine serial console (preview) から確認できます。
Read the rest of this entry »
SQL Server on Linux の商用の可用性ソリューション HPE Serviceguard の情報が公開されています
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
ベンダーサポートが必要となった場合の可用性のソリューションとして覚えておくとよさそうですね。
パッと見た感じ、トライアルが見当たらなかったのですが、トライアルライセンスとかないですかね…。
あれば、どのような動作になるか検証して情報発信したいなと思ったのですが。
次の LTSC のサーバー OS となる Windows Server 2019 の Preview 版が公開されました
2018/3 時点の LTSC (Long-Term Servicing Channel) の OS は、Windows Server 2016 ですが、次の LTSC のサーバー OS となる Windows Server 2019 の情報がひょっこり公開されました。
Introducing Windows Server 2019 ? now available in preview
Windows Insider Program からダウンロードすることができ、今回公開された Preview の時点で、日本語版も公開されていました。下の画像が winver の結果となりますが、現時点では Version 1803 なのですね。
今の Windows Server は、半期チャネル (Semi-Annual Channel) と、長期サービスチャネル (Long-Term Servicing Channel) の 2 種類のチャネルがあり、多くの企業では、デスクトップエクスペリエンスがついており、メインストリームサポートが 5 年間ある、LTSC を使うことになるではないでしょうか。
Windows Server 1709 の情報も全く追えていなかったので、Windows Server 2019 の公開情報を軽く整理しておこうかと。
といっても、冒頭に紹介したブログの記事の内容を自分で読み砕いただけですが。。。
Read the rest of this entry »
SQL Database のドキュメントで面白い更新がありました
SQL Database のドキュメントは日々更新されていますが、興味深い更新内容がありましたのでご紹介を。 Read the rest of this entry »
Azure Backup で SQL Server がインストールされている仮想マシンをバックアップする際に意識しておきたいこと
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 完全バックアップの詳細をご覧ください)。
SQL Database Managed Instance の各種情報を集めてみる – その 2 –
SQL Database Managed Instance の各種情報を集めてみる ? その 1 ? の続きです。
前回は、SQL Database Managed Instance (MI) の特徴をざっくりとまとめてみました。
従来から提供されている、SQL Database (SQL DB) は「Managed Database」となっています。
SQL Server のインスタンスではなく、各データベースをリソース制御の境界とした、「データベース利用」の PaaS のサービスとなり、各データベースは独立して管理されており、一つの論理サーバー配下に複数のデータベースを作成した場合、独立した環境となっているのが特徴でした。
MI は「Managed Instance」となっています。
SQL Server のインスタンスをリソース制御の境界とした、「インスタンス利用」の PaaS のサービスとなり、インスタンス全体を利用することができるため、一つのインスタンス配下に複数のデータベースを作成した場合、同一の管理境界内に配置され、相互に利用が可能となっていることが特徴でした。
RDS for SQL Server や、Azure Database for MySQL / Azure Database for PostgreSQL に近い管理モデルとなっている形ですね。
MI は、既存の SQL Server からの「Lift & Shift」(既存の環境を変更なくクラウドに移行) を強く意識された環境であるため、SQL DB よりサポートされている機能が多いのも特徴の一つです。
Feature comparison: Azure SQL Database versus SQL Server
それでは、前回はまとめられなかった点についてもまとめていきたいと思います。
Read the rest of this entry »
SQL Database Managed Instance の各種情報を集めてみる – その 2 –
SQL Database Managed Instance の各種情報を集めてみる – その 1 – の続きです。
前回は、SQL Database Managed Instance (MI) の特徴をざっくりとまとめてみました。
従来から提供されている、SQL Database (SQL DB) は「Managed Database」となっています。
SQL Server のインスタンスではなく、各データベースをリソース制御の境界とした、「データベース利用」の PaaS のサービスとなり、各データベースは独立して管理されており、一つの論理サーバー配下に複数のデータベースを作成した場合、独立した環境となっているのが特徴でした。
MI は「Managed Instance」となっています。
SQL Server のインスタンスをリソース制御の境界とした、「インスタンス利用」の PaaS のサービスとなり、インスタンス全体を利用することができるため、一つのインスタンス配下に複数のデータベースを作成した場合、同一の管理境界内に配置され、相互に利用が可能となっていることが特徴でした。
RDS for SQL Server や、Azure Database for MySQL / Azure Database for PostgreSQL に近い管理モデルとなっている形ですね。
MI は、既存の SQL Server からの「Lift & Shift」(既存の環境を変更なくクラウドに移行) を強く意識された環境であるため、SQL DB よりサポートされている機能が多いのも特徴の一つです。
Feature comparison: Azure SQL Database versus SQL Server
それでは、前回はまとめられなかった点についてもまとめていきたいと思います。