SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Archive for the ‘SQL Server’ tag

Windows Server 2019 を使用した Azure Files による SQL Server のログ配布の構成

leave a comment

先日投稿した、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 上に構築することがサポートされており、これについては 新機能 のマトリクスにも記載されています。

image

詳細な情報については、次の情報から確認することができます。

DR 環境については、次のように定義されています。

Disaster Recovery replica is defined as a passive replica setup as asynchronous replica with manual failover.

 

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 を待つとよいかと思います。

Read the rest of this entry »

Written by masayuki.ozawa

1月 26th, 2020 at 9:46 pm

Posted in SQL Server

Tagged with ,

Azure VM で AD を使用しない AlwaysOn 可用性グループを Windows Server 2019 と SQL Server 2019 で構築する

leave a comment

SQL Server 2019 では SA (ソフトウェア アシュアランス : Software Assurance) の特典として、DR 用のレプリカを Azure 上に構築することがライセンスとして許容されるようになります。

image

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 を組んだのですが、TP3 で Azure 上でワークグループクラスターを構築し、その上に CTP 2.4 のAlwaysOn を構築してみる で検証したときとは、ところどころ変わっているもんですね。

Azure 上で AG を構築する際には次のドキュメントを参照しておくと作業がスムーズに進むかと思います。

 

Read the rest of this entry »

Written by masayuki.ozawa

1月 25th, 2020 at 4:31 pm

Posted in SQL Server

Tagged with ,

IaaS の SQL Server で AlwaysOn を構築した際に考慮しておきたい設定について

leave a comment

Azure の IaaS (仮想マシン) に SQL Server をインストールした場合、AlwaysOn 可用性グループで可用性を向上させることが多いかと思います。

IaaS の SLA は Virtual Machines の SLA に記載されており、可用性セットや Premium SSD を使用することで稼働率を上昇させることは可能です。

AlwaysOn 可用性グループを使用した場合は、可用性セットによる稼働率の向上を行いますが、IaaS の可用性セットでは、可用性セット内のいずれかのインスタンスへの接続を保証することになるため、クラスター内のいずれかのサーバーが停止した時間が発生するということになります。

クラスターの標準の設定であれば、数秒程度の停止であればフェールオバーを発生させることなくシステムを稼働させることはできますが、メンテナンスで数 10 秒停止するようなケースでは、フェールオーバーが発生することになります。

メンテナンスが発生した場合に、できるだけフェールオーバーを発生させないようにするための情報については、いくつかの情報が公開されていますので、本投稿ではその情報をまとめておきたいと思います。

Read the rest of this entry »

Written by masayuki.ozawa

1月 18th, 2020 at 8:29 pm

Posted in SQL Server

Tagged with

SQL Server へのクエリ実行の「コマンドタイムアウト」の情報取得について考えてみる

leave a comment

アプリケーションから 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 »

Written by masayuki.ozawa

1月 16th, 2020 at 8:51 pm

SQL Server / Database アーキテクチャ ドキュメント

leave a comment

 

SQL Server

tempdb

設定

統計情報

セキュリティ

I/O

SQL Database

接続性

Azure Data

Microsoft Research

Written by masayuki.ozawa

1月 13th, 2020 at 11:36 pm

Posted in SQL Server

Tagged with

tempdb のロギング最適化による最小のログ記録の動作を確認してみる

leave a comment

SQL Server の tempdb では、ロギング最適化という動作により、トランザクションログの書き込みを最小限にするようにされています。

最近は、「SQL Server を使いこなす」という観点での勉強を進めており、その中でトランザクションログの書き込み内容の解析も多少できるようになってきましたので、tempdb のロギング最適化による、最小のログ記録の動作についても、実際のトランザクションログの書き込み内容を元にしてみていきたいと思います。
(本投稿の最小のログ記録については、一括挿入を実行する際等の最小ログ記録とは別の動作です)

Read the rest of this entry »

Written by masayuki.ozawa

1月 5th, 2020 at 4:47 pm

INSERT を例にしたトランザクションログの内容の確認

leave a comment

SQL Server のトランザクションログの内容を確認する際のアプローチとして「DBCC LOG 」や「sys.fn_dblog」を利用して内容を確認するという方法があります。

これらの DBCC や関数はアンドキュメントとなっており、詳細な情報は公開されていません。

Read the rest of this entry »

Written by masayuki.ozawa

12月 26th, 2019 at 12:02 am

SQL Server 2017 on Linux で CU18 からレプリケーションがサポートされました

leave a comment

先日 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 の情報にも注目すると、「次のバージョンで導入されている機能が下位バージョンでも使用できるようになる」にも気づくことができるのではないでしょうか。

Written by masayuki.ozawa

12月 12th, 2019 at 9:44 am

Posted in SQL Server

Tagged with ,

CPU 使用率 / バッチ実行数との対比による Batch Resp Statistics の活用

one comment

SQL Server のパフォーマンスモニターとして、SQL Batch Resp Statistics という項目があります。
この項目は、SQL のクエリをバッチという単位で集計した際の次のような観点の情報を確認することができます。

  • 特定の実行時間 (Elapsed Time) の範囲のバッチ実行回数とバッチ実行時間の合計
  • 特定の CPU 使用時間 (CPU Time) の範囲のバッチ実行回数とバッチ実行時間の合計

この項目は「インスタンス内でどのような時間を消費しているクエリが実行されているか?」を把握するのに役に立つ情報となっており、単体でも便利なのですが、他の情報と組み合わせることでさらに活用の幅が広がります。

本投稿では、「CPU 使用時間の範囲のバッチ情報」を活用した方法についてまとめてみたいと思います。

Read the rest of this entry »

Written by masayuki.ozawa

12月 8th, 2019 at 10:00 pm

Posted in SQL Server

Tagged with ,

RaspberryPi 4B で Docker と IoT Edge ランタイムを起動するための準備

one comment

Azure SQL Database Edge は、x64 ならびに ARM64 のデバイス上で動作させることができる、コンテナーの SQL Server となります。

SQL Database Edge を稼働させるための準備として、RaspberryPi 4B (ラズベリーパイ4 / ラズパイ4) を購入したので下準備として Docker と IoT Edge ランタイムを動作させるまでの方法をメモとして残しておきたいと思います。

IoT 関連は全く触ってきておらず、ラズパイを使うのも初めてに近いので、そもそもとして間違っていることがあるかもしれません (

Read the rest of this entry »

Written by masayuki.ozawa

12月 7th, 2019 at 12:40 am