SE の雑記

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 の各種情報を集めてみる ? その 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 の Public Preview が始まりました の続きですが、ドキュメントもいろいろと出ていますので、情報を集めてみました。
数回に分けてまとめていきたいと思います。
Read the rest of this entry »

昨年から情報が出始めている、SQL Database の Instance 単位の PaaS のサービスである、SQL Database Managed Instance (MI) の Public Preview が開始されました。
「リソースの作成」から「Azure SQL Managed Instance」で作成の画面を開くことができるかと。

現時点では、承認制のプレビューとなっているため、すぐに使うことはできないのですが、ドキュメントが公開されていますので、まずは、こちらを追っていく感じでしょうか。

• What is an Azure SQL Database Managed Instance (preview)?
• Create an Azure SQL Database Managed Instance (preview) in the Azure portal
• Migrate your databases to a fully managed service with Azure SQL Database Managed Instance
• What is Azure SQL Database Managed Instance?

現在、利用可能なリージョンとしては、次のようになっており、日本の場合、「東日本」がサポートされていますね。

Available today in 20 Azure regions

At the time of this announcement, Managed Instance is initially available in 20 Azure regions: Canada Central, Canada East, Central US, East Asia, East US, East US 2, Japan East, Korea Central, Korea South, North Central US, North Europe, South Central US, South India, Southeast Asia, UK South, West Central US, West Europe, West India, West US, and West US 2. Managed Instance will be made available in more Azure regions through the course of preview.

 
DMS についても Managed Instance に対応したようですね。

• Azure Database Migration Service ? March Update

料金については、https://azure.microsoft.com/ja-jp/pricing/details/sql-database/managed/ で公開されています。
モデルとしては一般向けワークロードと、ビジネスクリティカル向けワークロードの 2 種類があるのですが、現在は一般向けワークロードでの公開となっているようですね。
下記の価格は、プレビュー価格なので 50% OFF ですが、GA 時には、一番低いレベルのインスタンスタイプでもそれなりなお値段ですね。

SQL Server の VM の価格は、https://azure.microsoft.com/ja-jp/pricing/details/virtual-machines/sql-server-enterprise/ で公開されていますが、同程度の CPU の場合は、Managed Instance のほうが安価ではありそうですね。
Read the rest of this entry »

SQL Database の Intelligent Insights を使用することで、Log Analytics に情報を収集することができますが、Log Analytics には、HTTP データコレクター API があり、カスタムデータをアップロードすることもできるようになっています。
詳細については、 HTTP データ コレクター API を使用した Log Analytics へのデータの送信 (パブリック プレビュー) に記載されていますが、この仕組みを使用して、SQL Database の任意の性能情報を Log Analytics に格納する仕組みを作ってみました。
性能情報については、SQL Database に対してクエリを実行して取得しているだけですので、SQL Server からも情報を取得可能です。
Read the rest of this entry »

SQL Database のパフォーマンス監視する方法として、メジャーなものとしては次のようなものがあるかと思います。

• DTU の情報を使用したリソース (CPU / ディスク / 接続) の使用状況の確認
• クエリストアの情報を使用した、クエリに特化した情報の確認 (DMV または、Query Performance Insight)

今の SQL Database には、これに加えて「Intelligent Insights」という機能が追加されています。
本投稿ではこの、Intelligent Insights についてまとめてみたいと思います。
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 »

先日、WSUS クリーンアップ ウィザードにてタイムアウトが発生する という記事が公開されましたが、クリーンアップタスクが失敗したときに追加で見ておきたいログの話を。 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 を使用することでも、各種情報を取得することが可能ですので、今後の情報取得の一助となれば幸いです。