SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Microsoft Copilot in Azure では、SQL Database 向けのスキルが組み込まれており、Azure ポータルから Copilot で、データベース向けの質問をチャットすることで、SQL Database に特化した回答を得ることができます。
大きなカテゴリとして、次の二つの機能があり、データベースの稼働状況の調査を行う場合には「1.」を活用することになります。
この機能を活用すると、次の画像のように実際のデータベースの稼働状況に応じた回答が生成されます。
この機能がどのようにして動作しているのかが気になったので少し調べてみました。
この機能については Microsoft Copilot in Azure と SQL Database で公開されている記事も参考となります。
SQL Server のトランザクションレプリケーションで、アーティクル (複製対象となるテーブル) を追加した後には、初期スナップショットの取得が必要となります。
初期スナップショットを取得する際には、パブリケーション内に含まれている全アーティクル (新規追加したアーティクル以外も含む) に対して瞬間的に「SCH_M」のロックが取得されています。
SCH_M のロックは強力なロックとなり、初期スナップショットを取得する際にパブリケーション内のアーティクルに対して実行時間が長いクエリが実行されている場合は、広範囲のブロッキングチェーンの発生の要因となる可能性があります。
本投稿では、初期スナップショットを取得する際の SCH_M のロックですがどのような処理により取得されているのかを確認していきたいと思います。
今回はレプリケーションの初期スナップショット取得を解析のターゲットとしていますが、この考え方については他のロック競合の情報を確認する際にも共通の内容となります。
2024-07-19 (JST) に発生した CrowdStirke のソフトウェアアップデートに伴う Windows OS の問題に対して、各社からのアナウンスが、一通り終わったのではないでしょうか。
これらの情報は、CrowdStrike だけでなく、起動しなくなった Windows OS ディスクのオフライン修復と Windbg を使用したダンプの解析でも有益な情報となり、この観点で知見を得たいときに便利な情報となりますので、どのような情報があったかをまとめておきたいと思います。
本ブログでは、Azure Stack HCI 23H2 プレビュー (25398.584) を展開する際のメモ などの検証を行う際には、NUC9VXQNX を使用して物理環境でシングルノードの Azure Stack HCI を構築していました。
以前は問題なく展開できていたのですが、直近で展開しようとすると以前は問題にならなかった箇所で、エラーとなるケースがありましたので、その際の情報をまとめておきたいと思います。
Azyre VM の構成情報には osProfile という設定があります。Windows の場合、osProfile 配下の windowsConfiguration にパッチの自動適用の設定が登録されています。
Azure VM のブレードでは JSON ビューというリンクがあります。
このリンクをクリックすると、osProfile の設定を確認することができ、Marketplace で登録されている標準の Windows イメージで展開した Azure VM であれば基本的にはこの設定が含まれている状態となっています。
しかし、enable for existing vms? #62655 のように、VM に対してパッチ関連の設定を変更しようとすると「Couldn't find 'windowsConfiguration' in 'osProfile'. 'osProfile' does not support further indexing.」が発生するケースがあります。
このエラーが発生する VM では、JSON を確認すると、上述の osProfile が存在しない状態となっています。
Microsoft Defender for Cloud (MDfC) で提供されている Microsoft Defender for Server (MDfS) について、本ブログでも何件か投稿を書いていました。
当時とは技術所方法のリンクや機能が変わっている箇所があり、いくつか再確認する必要のある内容がありましたので、今回のタイミングで確認をした内容をまとめておきたいと思います。
Defender for Endpoint 統合 については意識はしておらず、Microsoft Azure に閉じられた範囲での利用をターゲットとしています。
直近で Bicep を使用する機会があったのですが、その際に得られた知見についてまとめておきたいと思います。
Bicep と書いていますが、ARM でも共通する内容となるかと思います。
2024/07/29 追記
本投稿について X でコメントをいただいていたので、そちらを追記させていただきました。
素晴らしいbicepの記事を発見、いくつかコメントhttps://t.co/7ObOpZoRXb
— OMI Takekazu (@takekazuomi) July 28, 2024
miteta // Bicep の Tips (2024/07 版) at SE の雑記https://t.co/u1B3Yyp5lH
— guitarrapc_tech (@guitarrapc_tech) July 28, 2024
Azure ではリソースに対して 診断設定 を実施することで、リソースに対しての各種情報を指定した宛先に保存することができます。
取得する項目の取得については、カテゴリ グループとカテゴリを使用して選択することができるのですが、この設定について、いくつか理解度が低いところがあり、改めて情報を確認した内容についてまとめておきたいと思います。
SQL Server ベースの環境で実行プランのファイル (.sqlplan) の解析を行う際に SolarWinds Plan Explorer を使用することがあります。
SSMS でも実行プランの解析はできますが、複雑な実行プランになった場合は Plan Explorer を使用したほうが効率的に実行プランの解析を行うことができます。
Plan Explorer は実行プランのファイルだけでなく、デッドロックレポート (.xdl) についても解析を行うことができます。
Azure ストレージには静的な Web サイトの機能があり、静的コンテンツを Azure ストレージで公開する際に活用することができます。
この機能を Bicep で有効にしようとしたのですが、Bicep の定義として設定する機能が提供されていませんでした。
実施した対応としては Storage Account – Enable Static web site #10337 と同じですが、現状は deploymentSciprts で対応をする必要があるようですね。