SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
tempdb
設定
統計情報
セキュリティ
I/O
接続性
先日、Azure Shared Disk の Preview についての情報が公開されました。
先日、SQL Server 2019 CU2 がリリースされました。
今回の CU では SQL Server 2019 でログ配布を設定した場合に、ログ配布の履歴用のジョブでエラーが発生した問題の解消 などが行われているのですが、それ以外にも PolyBase の外部テーブルの接続性に影響を与える改善が行われています。
設定を変更しながら、設定変更の効果がクエリにどのような影響を与えるかを調査するための、簡単なベンチマークを行うためのスクリプトを最近作成していました。
クエリのベンチマークを行う際には、「どのように設定前後の処理効率の変化を比較するか？」という点を考慮しなくてはいけません。
今回はスクリプトを作成する中でどのような方法で、設定前後のクエリの実行効率の変化を確認していったかをまとめてみたいと思います。
ちなみにスクリプトは PowerShell 7.0 RC2 で作成しています。
(ForEach-Object -Parallel を使用したかったため、PowerShell 7.0 を使用しています)
最近、SQL Server の基本動作をいろいろと再勉強しているのですが、その中で統計情報のドキュメントを一通り読み直していました。
TPC-H の LINEITEM を使用して、いくつかのパターンで統計情報のメンテナンスを手動で実施しながら動作の確認を行った際のメモを。
自宅の検証環境の VM と Azure 上の VM を VPN で接続して実施したい検証があり、「自宅の検証環境だと Site to Site 接続するの厳しいから、Point to Site 接続でやるか」と思って試した際のメモです。
先日投稿した、Azure VM で AD を使用しない AlwaysOn 可用性グループを Windows Server 2019 と SQL Server 2019 で構築する で、New high availability and disaster recovery benefits for SQL Server に触れました。
SQL Server 2019 では、SA の特典として、 DR 環境を Azure 上に構築することもサポートされており、これについては 新機能 のマトリクスにも記載されています。
(Failover servers for disaster recovery / Failover servers for disaster recovery in Azure が新しい特典となっていますので、Azure 以外でも DR 用のレプリカは得点を使用して作成できるはずです)
詳細な情報については、次の情報から確認することができます。
DR 環境については、次のように定義されています。
DR レプリカは、非同期レプリカのパッシブレプリカでありマニュアルフェールオーバーにより障害発生時に切り替えを行う環境であるとされています。
Disaster Recovery replica is defined as a passive replica setup as asynchronous replica with manual failover.
詳細については ライセンスガイド に記載されています。
A passive SQL Server replica is one that is not serving SQL Server data to clients or running active SQL Server workloads.
The passive failover instances can run on a separate server.
These may only be used to synchronize with the primary server and perform the following maintenance-related operations for the permitted passive fail-over Instances:
• Database consistency checks
• Log Back-ups
• Full Backups
• Monitoring resource usage data
Customer may also run primary and the corresponding disaster recovery replicas simultaneously for brief periods of disaster recovery testing every 90 days.
クライアントにアクティブなワークロードを提供することはできませんが、一部のメンテナンスに関連する作業については実施できる環境がパッシブレプリカとして定義されています。
DR レプリカを作成する際には、SQL Server の機能を用いて、データの複製を行うことになりますが、SQL Server のビジネス継続性を高めるための機能については ビジネス継続性とデータベースの復旧 – SQL Server で解説されているように、いくつかの機能を用いることが可能です。
同一ゾーン内の冗長構成については、同期レプリカで各レプリカが密結合となりますが、DR 用途のレプリカについては、遠隔地の DR 環境については疎結合で構築をしておいた方が、利便性が高いケースもあるのではないでしょうか。
そこで、今回は ログ配布 の構成を Azure Files を使用して実装したパターンをまとめてみたいと思います。
ログ配布は定期的にプライマリで取得されているバックアップを、セカンダリでリストアするという方式となり、AlwaysOn 可用性グループの同期レプリカと比較して、各環境には独立性があり疎結合なデータ同期環境として構築することができます。
今回の構成については、Windows Server 2019 の機能を使用していますので、使用可能な OS については限定されます。
なお、現時点で最新のバージョンである SQL Server 2019 では CU1 を適用しても、次のエラーが発生します。
セカンダリでログ配布のリストアは実施されるのですが、ファイルのコピーやリストア時に、メッセージの記録でエラーになり、次のようなエラーが出力されるという現象が発生します。
(エラーが発生することでメッセージが記録されなくなり、セカンダリ側の過去ファイルの削除が行われないという状況が発生します)
2020-01-26 19:39:15.16 ----- START OF TRANSACTION LOG RESTORE ----- 2020-01-26 19:39:15.23 Starting transaction log restore. Secondary ID: '119eefbf-d7ad-49db-9a9c-894358d89154' 2020-01-26 19:39:15.24 *** Error: Could not log history/error message.(Microsoft.SqlServer.Management.LogShipping) *** 2020-01-26 19:39:15.24 *** Error: パラメーター値を SqlGuid から String に変換できませんでした。(System.Data) *** 2020-01-26 19:39:15.24 *** Error: オブジェクトは IConvertible を実装しなければなりません。(mscorlib) *** 2020-01-26 19:39:15.24 Retrieving restore settings. Secondary ID: '119eefbf-d7ad-49db-9a9c-894358d89154'
設定の妥当性を検証するため、2017 RTM でも試したのですが、2017 RTM では発生しませんでした。
SQL Server 2019 でログ配布を使用する場合は、既知の問題のようですので、以降の CU を待つとよいかと思います。
この問題は SQL Server 2019 CU2 で修正されているようですので、ログ配布を使用する場合は、CU2 の適用をお勧めします。
SQL Server 2019 では SA (ソフトウェア アシュアランス : Software Assurance) の特典として、DR 用のレプリカを Azure 上に構築することがライセンスとして許容されるようになります。
(Failover servers for disaster recovery in Azure ではなく、Failover servers for disaster recovery というオンプレミスに DR を構築するパターンも新しい特典としてあります)
この SA 特典の詳細については、ライセンスガイド に詳細に記載されています。
従来まで、SA の特典として、プライマリのコアライセンスで、HA 用途の Passive Secondary を構築することができましたが、今回からは、新しくプライマリのコアライセンスで、DR 用途の Passive Secondary も構築ができるようになっています。
この特典ですが、「オンプレミスと Azure のどちらにも DR 環境を構築することができる」特典となっているようです。
次の図は、ライセンスガイドの P29 の図を引用したものとなりますが、プライマリのコアライセンスだけで、次のような構成も組むことが可能となるようです。
SQL Server の可用性機能としては AlwaysOn 可用性グループを構築するケースが多いですが、最新の OS (Windows Server 2019) と最新の SQL Server (SQL Server 2019) を使用した場合、どのような構成で SQL Server on Azure VM を構築することができるのか検証した一環の内容が本投稿になります。
Windows Server 2016 と SQL Server 2016 以降でも設定はできると思いますが検証はしていません。
久しぶりに Azure VM で AlwaysOn を組んだのですが、TP３ で Azure 上でワークグループクラスターを構築し、その上に CTP 2.4 のAlwaysOn を構築してみる で検証したときとは、ところどころ変わっているもんですね。
Azure 上で AG を構築する際には次のドキュメントを参照しておくと作業がスムーズに進むかと思います。
PowerShell でグラフの描画をしようとしたとき、Chart Control を使用してグラフを作成するという方法があります。
単純なグラフがこれ以外の方法で描画できないかなと思い探してみたところ、Graphical というモジュールが手軽に使えそうでしたので、少し試してみました。
Azure の IaaS (仮想マシン) に SQL Server をインストールした場合、AlwaysOn 可用性グループで可用性を向上させることが多いかと思います。
IaaS の SLA は Virtual Machines の SLA に記載されており、可用性セットや Premium SSD を使用することで稼働率を上昇させることは可能です。
AlwaysOn 可用性グループを使用した場合は、可用性セットによる稼働率の向上を行いますが、IaaS の可用性セットでは、可用性セット内のいずれかのインスタンスへの接続を保証することになるため、クラスター内のいずれかのサーバーが停止した時間が発生するということになります。
クラスターの標準の設定であれば、数秒程度の停止であればフェールオバーを発生させることなくシステムを稼働させることはできますが、メンテナンスで数 10 秒停止するようなケースでは、フェールオーバーが発生することになります。
メンテナンスが発生した場合に、できるだけフェールオーバーを発生させないようにするための情報については、いくつかの情報が公開されていますので、本投稿ではその情報をまとめておきたいと思います。
アプリケーションから SQL Server / SQL Database にコマンド (クエリ) を実行する際には、「コマンドタイムアウト」(クエリタイムアウト) について考慮をしておく必要があります。
ADO.NET の SQL Server 向けのドライバーではデフォルトでは 30 秒に設定されています。
コマンドタイムアウトの時間に達すると「Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.」「実行タイムアウトの期限が切れました。操作完了前にタイムアウト期間が過ぎたか、サーバーが応答していません。」のエラーが発生し、クエリの実行がキャンセルされます。
アプリケーション側で Exception をキャッチして、その時に実行されていたクエリなどをロギングするようになっていれば、「どのようなクエリによりタイムアウトが発生したか？」を確認することができますが、そのようなロギングの仕組みがない or 情報が不足している場合に、サーバー側観点だけでどのような情報取得の対応ができるか、考えてみました。
SQL Server の技術支援、現状調査、チューニング等をメインにしていますが、本ブログで情報発信している内容に関することでしたら対応できます。お仕事のご相談がありましたら
やブログのコメントでご連絡いただけると幸いです。
# ブログにコメント頂いた内容は私が承認しない限り表示されません。
2011年7月にMicrosoft MVP for SQL Server を受賞させていただきました。
Microsoft MVP for Data Platform (July 2011 – June 2019)
縄本発売中 http://amzn.to/16kWfV7
