Azure の IaaS (仮想マシン) に SQL Server をインストールした場合、AlwaysOn 可用性グループで可用性を向上させることが多いかと思います。
IaaS の SLA は Virtual Machines の SLA に記載されており、可用性セットや Premium SSD を使用することで稼働率を上昇させることは可能です。
AlwaysOn 可用性グループを使用した場合は、可用性セットによる稼働率の向上を行いますが、IaaS の可用性セットでは、可用性セット内のいずれかのインスタンスへの接続を保証することになるため、クラスター内のいずれかのサーバーが停止した時間が発生するということになります。
クラスターの標準の設定であれば、数秒程度の停止であればフェールオバーを発生させることなくシステムを稼働させることはできますが、メンテナンスで数 10 秒停止するようなケースでは、フェールオーバーが発生することになります。
メンテナンスが発生した場合に、できるだけフェールオーバーを発生させないようにするための情報については、いくつかの情報が公開されていますので、本投稿ではその情報をまとめておきたいと思います。
Read the rest of this entry »
Archive for the ‘SQL Server’ tag
IaaS の SQL Server で AlwaysOn を構築した際に考慮しておきたい設定について
SQL Server へのクエリ実行の「コマンドタイムアウト」の情報取得について考えてみる
アプリケーションから 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 情報が不足している場合に、サーバー側観点だけでどのような情報取得の対応ができるか、考えてみました。
Read the rest of this entry »
tempdb のロギング最適化による最小のログ記録の動作を確認してみる
SQL Server の tempdb では、ロギング最適化という動作により、トランザクションログの書き込みを最小限にするようにされています。
最近は、「SQL Server を使いこなす」という観点での勉強を進めており、その中でトランザクションログの書き込み内容の解析も多少できるようになってきましたので、tempdb のロギング最適化による、最小のログ記録の動作についても、実際のトランザクションログの書き込み内容を元にしてみていきたいと思います。
(本投稿の最小のログ記録については、一括挿入を実行する際等の最小ログ記録とは別の動作です)
Read the rest of this entry »
INSERT を例にしたトランザクションログの内容の確認
SQL Server のトランザクションログの内容を確認する際のアプローチとして「DBCC LOG 」や「sys.fn_dblog」を利用して内容を確認するという方法があります。
これらの DBCC や関数はアンドキュメントとなっており、詳細な情報は公開されていません。
SQL Server 2017 on Linux で CU18 からレプリケーションがサポートされました
先日 SQL Server 2017 Cumulative Update 18 (CU : 累積修正プログラム) がリリースされました。
投稿を書いている時点では、アナウンスはあまり出ていなさそうではあるのですが、CU18 から SQL Server 2017 on Linux でもレプリケーションが使用可能となったようです。
(SQL Server 2019 on Linux では標準でサポートしています)
SQL Server 2019 on Linux と同様に、スナップショットレプリケーション / トランザクションレプリケーションが SQL Server 2017 on Linux でも CU18 を適用することで利用可能となります。
同様な、on Windows と on Linux の機能ギャップを解消するような改善については CU16 でも分散トランザクションサポートで実施されていました。
SQL Server 2014 以前のバージョンでは、SP や CU で機能自体が追加されるということはあまりなかった (SQL Server 2005 リリース時のデータベースミラーリングの正式サポートが割と例外的な形だったはずですが) のですが、SQL Server 2016 以降は、SP や CU に機能を向上させるための更新も入ってきています。
SQL Server 2017 については、サービスも出るが変更されており、SP はリリースされず、すべての更新は CU で実施されるというようになっていますので、CU の役割が従来とは変わってきているため、今回のレプリケーションサポートや分散トランザクション (MSDTC) のサポートが、CU 適用により追加されるということもあります。
CU の情報を確認する際には、Fix だけでなく、Improvement の情報にも注目すると、「次のバージョンで導入されている機能が下位バージョンでも使用できるようになる」にも気づくことができるのではないでしょうか。
CPU 使用率 / バッチ実行数との対比による Batch Resp Statistics の活用
SQL Server のパフォーマンスモニターとして、SQL Batch Resp Statistics という項目があります。
この項目は、SQL のクエリをバッチという単位で集計した際の次のような観点の情報を確認することができます。
- 特定の実行時間 (Elapsed Time) の範囲のバッチ実行回数とバッチ実行時間の合計
- 特定の CPU 使用時間 (CPU Time) の範囲のバッチ実行回数とバッチ実行時間の合計
この項目は「インスタンス内でどのような時間を消費しているクエリが実行されているか？」を把握するのに役に立つ情報となっており、単体でも便利なのですが、他の情報と組み合わせることでさらに活用の幅が広がります。
本投稿では、「CPU 使用時間の範囲のバッチ情報」を活用した方法についてまとめてみたいと思います。
Read the rest of this entry »
RaspberryPi 4B で Docker と IoT Edge ランタイムを起動するための準備
Azure SQL Database Edge は、x64 ならびに ARM64 のデバイス上で動作させることができる、コンテナーの SQL Server となります。
(SQL Server は、2016 以降は x86 は提供していないため、SQL Database Edge も x64 のみとなります)
SQL Database Edge を稼働させるための準備として、RaspberryPi 4B (ラズベリーパイ4 / ラズパイ4) を購入したので、下準備として Docker と IoT Edge ランタイムを動作させるまでの方法をメモとして残しておきたいと思います。
IoT 関連は全く触ってきておらず、ラズパイを使うのも初めてに近いので、そもそもとして間違っていることがあるかもしれません (
Perflog スクリプトによるパフォーマンスモニターのグラフ作成
オンプレミスや、IaaS のような OS の機能を使用できる環境で、SQL Server やその他のパフォーマンス情報を時系列で取得したい場合、Windows OS 標準の機能であるパフォーマンスモニターを使用することがあります。
SQL Serer に関してのパフォーマンスモニターのカウンターについては、SQL Server オブジェクトの使用 で解説がされており、SQL Server の状態を時系列で分析したい際には、これらの情報を組み合わせて使用することになります。
項目を分析する際には、いくつかの情報を組み合わせて確認を行い、基本的な分析パターンであれば、汎用的な組み合わせがあります。
Read the rest of this entry »
PASS Summit 2019 の Day1 キーノート
本日から PASS Summit 2019 のセッションが開始され、Day1 のキーノートが行われましたのでメモを。
PASS Summit は今年で 21 回目の開催となります。
キーノートは、Ignite の Azure Data: Unmatched price-performance and limitless capabilities wherever your data lives と似たようなタイトルですね。
今回は Ignite の数日後に PASS が開催されるという珍しいパターンです。
Read the rest of this entry »