SE の雑記

Benefit from Resource Provider registration when self-installing SQL Server on Azure Virtual Machine でアナウンスがされていますが、Azure VM 上で SQL Server を実行する際に、運用の利便性を向上させることが可能な SQL Server IaaS Agent 拡張機能の構成に変更がありました。
これも 拡張セキュリティアップデート (ESU : Extended Security Updates) の対応の一環なのかなと。
(今回のアップデートにより、ライセンス切り替えの方法が柔軟に行えるようになります)
詳細は Automate management tasks on Azure Virtual Machines with the SQL Server IaaS Agent Extension / Register SQL Server virtual machine in Azure with the SQL VM resource provider から確認できます。
Read the rest of this entry »

先月、パブリック プレビュー:Azure Virtual Machines での SQL Server 2008 および 2008 R2 に対する Backup のサポート でアナウンスされましたが、SQL Server 2008 / R2 の Azure VM の AzureBackup による SQL Server のデータベースバックアップがプレビューでサポートされました。

SQL Server 2008 / R2 のサポートは本日 （2019/7/9) で終了となり、今後、拡張セキュリティアップデート (ESU : Extended Security Updates) の対応として、Azure の仮想マシンで SQL Server を動作させることもあるのかもしれません。

そのような場合に、バックアップとして Azure Backup の利用は検討した方が良いのではないでしょうか。
それでは、実際に試してみたいと思います。
関連するドキュメントとしては Give SQL sysadmin permissions for SQL 2008 and SQL 2008 R2 になります。
Read the rest of this entry »

SQL Server の T-SQL 経由で、MongoDB のデータを参照するための方法はいくつかあると思いますが、MongoDB 社が提供している MongoDB BI Connector 経由でアクセスする方法をまとめてみたいと思います。
MongoDB BI Connector がサポートしている MongoDB のバージョンが 3.2 以降となっていますので、対応バージョンは、このバージョン以降となります。

Note

The MongoDB Connector for BI and associated utilities are compatible only with MongoDB server version 3.2 or greater.

今回の MongoDB BI Connector では「BI ツールに MongoDB のデータを読み取りアクセスさせるために利用」することとなり、変更系のアクセスはできません
Read the rest of this entry »

SQL Server 2019 CTP 3.1 のデータベースエンジンの新機能として「OPTIMIZE_FOR_SEQUENTIAL_KEY」というインデックスのオプションが追加されました。

このオプションは、インデックスへの挿入を行う際に発生する Last page insert によるページラッチの競合を改善する効果のあるオプションとなっています。
詳細については、CREATE INDEX のヘルプの Sequential Keys に記載されています。
Read the rest of this entry »

投稿を書いている時点ではモジュールはまだ公開されていないようですが、SQL Server 2019 CTP 3.1 のリリースノートが公開されていました。
追記
公式アナウンスありました。
SQL Server 2019 community technology preview 3.1 is now availabl

• SQL Server 2019 preview release notes (CTP 3.1)
• What’s new in SQL Server 2019 preview (CTP 3.1 June 2019)
• Release notes for big data clusters on SQL Server (CTP 3.1 (June))

データベースエンジンとしては、次のような機能が追加されているようです。
データベースエンジン

• 暗号化列にインデックスを付与
  • Always Encrypted with Secure Enclaves でランダム暗号化した列に対して、非クラスター化インデックスを作成することができるようになり検索の効率が向上しているようです。
  • Indexes on Enclave-enabled Columns using Randomized Encryption
• セットアップ時に最大 / 最小メモリを設定可能
• 従来までの SQL Server では、セットアップ後に最大 / 最小メモリを設定していましたが、今回からセットアップ時に設定ができるようになったようです。
  MAXDOP についても設定ができるようになったようです。
• tempdb のように推奨オプションが指定される形で手動変更も可能という設定となったようですね。
• Setting the memory options manually
• グラフテーブルの最短パス用の関数の追加
• グラフテーブルで任意のノード間の最短パスを見つけるための関数 (SHORTEST_PATH) が追加されたようです。
• Public Preview of Shortest Path on SQL Server 2019
• グラフテーブルのパーティションテーブル / インデックスのサポート
• グラフテーブルでパーティショニングが使用できるようになったようです。
• 最終ページ挿入を改善するための新しいインデックスオプション
• インデックスに OPTIMIZE_FOR_SEQUENTIAL_KEY オプションが新しく追加されました。
• ID や現在の日付時刻が設定されている場合、複数スレッドによる最終ページのへの INSERT によって、PAGELATCH_EX の競合が発生することがあります。
  この競合を解消することができるオプションとして OPTIMIZE_FOR_SEQUENTIAL_KEY オプションが追加されたようです。
• SQL Server on Linux の tempdb の自動的な分割
• 2017 の SQL Server on Linux では、tempdb の自動的な分割は行われなかったのですが、2019 CTP 3.1 から分割されるようです。

Big Data Cluster
ビッグデータクラスター周りは例のごとく、かなり変更が加わっています。

• mssqlctl コマンドの変更
  • 新しい CTP のリリースごとにコマンド体系が変わる mssqlctl ですが、今回も変わりました。
  • mssqlctl cluster → mssqlctl bdc に変更
    • クラスターのステータスを確認するためのコマンドとして mssqlctl bdc status が追加されているようです。
    • これに伴いまさかの管理ポータルの廃止が…。
      • Kibana / Grafana のダッシュボードは個別にエンドポイントがあるようなので、そこから状況は確認できるようですが。
• Spark コンピューティングプール
  • 今までの Big Data Cluster は、ストレージプールの HDFS は Spark と相乗りだったのですが、Spark 部分を切り離して、個別にスケールできるようになったようです。
  • Configure storage without spark
• MSSQL Spark コネクタ
  • データプールの外部テーブルに読み取りだけでなく、書き込みもできるようになったようです。
• MLeap を使用した機械学習
  • Spark の MLeap と SQL Server の Java 拡張を使用した機械学習の仕組みの実装ができるようです。
  • Create, export, and score Spark machine learning models on SQL Server big data clusters

SQL Server 2019 CTP 3.0 から、tempdb のメタデータをメモリ最適化テーブルを使用することができるようになりました。

• データベース エンジン
• メモリ最適化 tempdb メタデータ (In-Memory Database)
• メモリ最適化 tempdb メタデータ (tempdb)

Hekatonized Tempdb と呼んでいる方もいるようですね。
Read the rest of this entry »

Azure VM をデプロイしようとしたところ、次のような表示になっていて気づきました。

Gen2 VM については、「vPMEM」という表示があり、情報としては去年から出ていたようなのですが、Hyper-V の最新の仮想マシンでは、Persistent Memory を仮想マシン上で使用するための vPMEM という機能があるのですね。
Windows Server バージョン 1709 の新機能 ですでに公開されていたようなのですが、全くキャッチアップできていませんでした。
有効にするための方法については HYPER-V Vm の永続的なメモリ デバイスを構成するためのコマンドレット で記載されています。
PMEM 上に「vhdpmem」という拡張子のファイルを作成し、仮想マシンに追加した PMEM のコントローラーにそのファイルをディスクとして追加することで、仮想マシン上で PMEM の利用を可能とするというようなアプローチのようです。
(通常のディスク上にも vhdpmem ファイルを作成することはできますが、残念ながら通常のディスク上に作成しても、接続した仮想マシンを起動することはできませんでした)
VMWare にも vPMEM の考え方があるようで、各社仮想マシンで PMEM を利用するアプローチが進められているようですね。
Hyper-V の PMEM 対応については、Windows Support for PM – SNIA が詳しそうです。
去年、GCP が PMEM 対応のアナウンスを行っていたことは記憶にあったのですが、Gen2 VM に表示があるということは、Azure でもそのうち PMEM が利用できる VM が提供されるのかもしれないですね。

6/12 にいくつかの更新が発表されていましたのでまとめて確認しておこうかと。

Advanced Data Security available for SQL Server on Azure Virtual Machines
SQL Server on Azure VM で高度なデータセキュリティ機能が利用可能になりました。
SQL Database では以前から実装されていますが、この技術が IaaS の SQL Server でも使用できるようですね。
機能としては、次の 2 種類が使用できるようになるようです。

• 脆弱性評価
• 高度な脅威検知

次のような情報も併せて公開されていますね。

• Advanced data security for SQL Server is coming to Azure Virtual Machines
• IaaS の SQL サーバー向け Advanced Data Security

脅威検知については、現状は、通常とは異なるアクセスについての検知が利用できるようですが、SQL インジェクションのようなクエリ実行に対しての検知の提供も準備されているようですね。
 
Azure SQL Database Managed Instance でリージョンのリソース制限のサポートが拡大されました
Managed Instance はサブスクリプション内にデプロイできる数がかなり少なく制限されていたのですが、この制限が緩和されたようです。

以前はこのような制約でしたが、結構緩和されていますね。

最新のリソース制限については こちら を確認していただければ。
 
General availability: 4 vCore Azure SQL Database managed instances on Gen5 hardware
Gen5 については 4 コアモデルの提供が開始されました。
価格の情報 と リソース制限 の情報も更新されています。
4 コアモデルであれば、今までと比べるとかなりやすく使用できますね。
デモがやりやすくなりうれしい限りです。
 
Dev/test pricing option for individual Visual Studio subscribers is now available for Azure SQL Database managed instance
こちらもうれしい情報なのですが、Visual Studio サブスクリプションについている Azure サブスクリプションで、Managed Insance が利用できるようになりました。
さらに「開発テスト用従量課金プラン」と同様に 55% ディスカウントされた金額で利用できますので、検証時の費用は結構抑えられそうです。
 
Azure SQL Database default configuration changing soon
新しいデータベースを作成した際のデフォルトの構成が汎用目的 / 2 vCore / Gen5 のモデルとなりました。
オプションを何も設定せずに CREATE DATABASE すると次のような DB で作成されます。

Datadog のエージェントには、標準で SQL Server のメトリクスを取得するための、Integration が含まれています。

• Collect SQL Server Custom Metrics
• SQL Server
• Key metrics for SQL Server monitoring
• Custom SQL Server metrics for detailed monitoring
• Monitor SQL Server performance with Datadog

軽く触ってみた際の覚書を。
Read the rest of this entry »

de:code 2019 の? DP06 Deep-dive in Azure Cosmos DB: Advanced topics on partitioning, data distribution and indexing で実施されていた Cosmos DB のグローバル分散のデモ で面白いなと思ったものの一つとして、リージョンが違うことによるレイテンシーの違いというものがありました。
この見せ方、面白いなと思って、SQL Database でも簡単なものを試してみました。
DTU モデルの場合は公開されていないのですが、vCore モデルの場合は、デプロイ時に次のような記載があります。

データファイル / ログファイルのような物理ファイルにアクセスする場合の想定待機時間が記載されていますね。
詳細については、仮想コアベースの購入モデルを使用した単一データベースに対するリソース制限 でまとめられているのですが、基本的な考え方としては次のようになります。

• リモートストレージへのアクセス
  • 書き込み時 : 5 ～ 7 ミリ秒程度の I/O 待機時間
  • 読み込み時 : ５～10 ミリ秒程度の I/O 待機時間
• ローカルストレージへのアクセス :
  • 書き込み時 : 1～2 ミリ秒程度の I/O 待機時間
  • 読み込み時 : 1～2 ミリ秒程度の I/O 待機時間

SQL Database はサービスレベルに応じて、使用するストレージ (接続方式) が異なります。
DTU モデルの「Basic」「Standard」と、vCore モデルの「汎用目的」については、「リモートストレージ」が使用されており、データベースは Azure Premium Storage 上に格納されています。

DTU モデルの「Premium」と、vCore モデルの「ビジネスクリティカル」については、「ローカルストレージ」が使用されており、リモートストレージと比較して、高速にアクセスができるようになっています。

データベースの処理時間を考える際には、以下の 2 点を考慮する必要があるか思います。

• アプリケーションからのアクセスを考慮した応答時間
• データベース単体の応答時間

今回はこれらを考慮した情報の取得を行ってみたいと思います。
Read the rest of this entry »