SQL Database にはいくつかの診断情報の取得 / 可視化の方法がありますが、いろいろな方法があってよくわからなくなってきたのでまとめておこうかと。
同一のリソース名のマネージド ID が存在する場合の SQL DB のユーザー作成について – 暫定版 –
SQL Database の認証には、Azure のリソースのマネージド ID (MSI) を使用することができるようになっています。
-
チュートリアル:マネージド ID を使用した App Service からの Azure SQL Database 接続のセキュリティ保護
-
チュートリアル:Windows VM のシステム割り当てマネージド ID を使用して Azure SQL にアクセスする
マネージド ID をサポートしているサービスについては Azure リソースのマネージド ID をサポートするサービス に記載されていますが、これらのサービスが接続をする際にはマネージド ID による接続ができる可能性があります。
イベントハブに送信されている診断ログを SQL Database の DB で受信する
以前から、イベントハブに送信された Azure の診断ログを SQL Databae に取り込むということができていたかと思います。
昨年末ぐらいに、Azure SQL Database Stream Analytics 統合という機能がプレビューとして提供され、SQL Database のブレードからも Stream Analytics によるデータ取り込みの設定を行うことができるようになりました。
ブログのログをイベントハブに送信しながら、Stream Analytics から SQL Database のテーブルにデータ取り込みを実施してみたのでその時の覚書を。
今回はブログのフロントに配置している Front Door の診断ログ (アクセスログ) をイベントハブに送信し、それをテーブルに受け取るような設定を使っています。
(1 か月回していると、それなりの金額になりそうですので、今は BLOB に出力されている JSON を Data Factory 経由で取り込みを行うようにしています。)
SQL Server 2019 CU3 on Linux で Ubuntu 18.04 / SLES 12 SP5 をサポートしたようです
先日、SQL Server 2019 now available on Ubuntu 18.04, supported on SLES 12 SP5 というアナウンスがあり、SQL Server 2019 CU3 を使用することで、Ubuntu 18.04 / SELES 12 SP5 のサポートを開始したようです。
- SQL Server 2019 CU1 : RHEL8 のサポート
- SQL Server 2019 CU3 : Ubuntu 18.04 / SLES 12 SP5 をサポート
というように CU によってサポートされる OS が変わってくるのも SQL Server on Linux の特徴となりそうですね。
Release notes for SQL Server 2019 on Linux の記載も変更されています。
Azure Automation を使用して App Service のクォータ リミットに近い場合にスケールアップを行うことができるか試してみる
本ブログですが、今まではレンタルサーバー上で稼働させていたのですが、結構な頻度で 500 エラーが発生していたと思います。
ということで、ブログを Web Apps 上にお引越ししてみたところ、500 エラーの発生状況は改善したようでした。
(低いサービスレベルで動作させているからか、安定性がいまいちで、まだまだ対応が必要なことが多いですが…。)
左がレンタルサーバー上で実行していた時のステータスコードの比率なのですが、1 日のアクセス数の中で 18% 近くが 500 エラーとなっていたんですね…。
個人サイトですので、SLA は必要がないのでひとまず、F1 で動作させているのですが、Free や Standard というようなサービスプランでは、1 日の中で CPU が使用できる時間が決まっています。
次の画像は料金表の内容となります。
F1 で 60 分 / D1 で 240 分の CPU 時間を使用することができるのですが、私のサイトの場合、F1 では確実に CPU 時間が不足し、D1 では平日にいろいろと作業をした場合に CPU 時間が不足する可能性があるのですよね。
ということで Azure Automation を使用して、クォータのリミットに近づいているかを取得しながら、スケールアップをするスクリプトが組めるかどうかを試してみました。
今回の処理は実行時間が長いわけではないので、Azure Automation ではなく、Azure Functions で実行した方が手っ取り早いのですが、今の Automation がどのようになっているのかを知りたくて、Automation を使っています。
PowerShell で Azure REST API にアクセスする際の覚書
PowerShell で Azure の REST API を実行しようと思った際に、良く忘れてしまうのでメモとして。
トランザクションレプリケーションの動作を理解する – ディストリビューション編 –
トランザクションレプリケーションの動作を理解する ? ログリーダー編 ? の続きです。
前回の投稿では、「ログリーダー」の動作を確認しました。
ここまでの操作で「ディストリビューターに配信用のデータが格納された状態」となります。
これを「サブスクライバー」に適用させるのが「ディストリビューション エージェント」の動作となり、今回の投稿の対象となる範囲です。
今回の投稿では、データの配信方法は「プッシュサブスクリプション」を対象としています。
トランザクションレプリケーションの動作を理解する – ログリーダー編 –
SQL Server のテーブル単位でのデータ同期の仕組みとして「トランザクションレプリケーション」があります。
以前 トランザクションレプリケーションの基本的な仕組み という投稿をしたことがあるのですが、もう少し詳細なレベルでの知識が必要となったので、スキルアップデートをしようかと。
Read the rest of this entry »
Windows で Oracle から PostgreSQL への移行ツール [ora2pg] で移行を実施してみる
先日の投稿では、Windows で Oracle から PostgreSQL への移行ツール [ora2pg] をインストールしてみる ということで、ツールの実行環境を整えるところまでを実施してみました。
今回の投稿では、実際の移行を実施してみたいと思います。
Read the rest of this entry »
Windows Server 2019 で Windows Update のアクティビティ モニターの情報をスクリプトで取得してみる
Windows 10 や Windows Server 2019 は、「設定」の「更新とセキュリティ」の「配信の最適化」中に「アクティビティ モニター」という項目があります。 
ここから、Windows Update のダウンロードの状況を確認することができるようになっています。
Windows 10 であれば、配信の最適化によって Windows Update の更新プログラムが他の PC からダウンロードされている場合は、「ローカル ネットワーク上の PC から」の項目で確認ができるはずです。
Read the rest of this entry »