こんにちは。Azure SQL 仮想マシンでちょっとつまづいたことがあったので備忘のためメモを残しておきたいと思います。
Contents
問題
Azure SQL仮想マシンの設定がポータル上グレーアウトされていじれなくなった。
プロビジョニングの状態をみると、”Failed”になっている。
VMからSQL Serverへの接続もできない。
原因と解決方法
結論、2つの問題のダブルパンチだった。
- SQL Serverサービス起動ユーザのパスワードが古かった
- TempDBフォルダがなかった
以下、発見の経緯をまとめておきます。(キャプチャのsql server名がsql server-0だったり1だったりしますが、キャプチャ取得の問題で、実際には2つの同じ構成のサーバで同じ問題が起きていたのでキャプチャが混ざってしまっていますが気にせずみただけると・・)
まずVMからSQL Server構成マネージャを開いてSQL Serverサービスの起動状況をみてみると、Stoppedに。なるほど、サービスが立ち上がっていない。直接的にはこれが原因でプロビジョニングに失敗しているのかな。
これを手動で起動してみると、失敗した。
ここでログオンユーザのアカウント情報を確認してみると、そういえばこのユーザのパスワードが有効期限切れしていたので新しいものに変更していたことに気付く。これは凡ミス。。
最新の認証情報に更新して、もう一度起動。するとまた失敗。なぜだ。。
エラー文言に従って、エラーログをみてみることに。エラーログはデフォルトだと以下で確認できるよう。
エラーログをみてみると、エラーの詳細がでていた。
2022-07-30 04:42:23.79 spid10s Error: 5123, Severity: 16, State: 1.
2022-07-30 04:42:23.79 spid10s CREATE FILE encountered operating system error 3(The system cannot find the path specified.) while attempting to open or create the physical file 'D:\tempDb\DATA\tempdev.mdf'.
2022-07-30 04:42:23.81 spid10s Error: 17204, Severity: 16, State: 1.
2022-07-30 04:42:23.81 spid10s FCB::Open failed: Could not open file D:\tempDb\DATA\tempdev.mdf for file number 1. OS error: 3(The system cannot find the path specified.).
2022-07-30 04:42:23.81 spid10s Error: 5120, Severity: 16, State: 101.
2022-07-30 04:42:23.81 spid10s Unable to open the physical file "D:\tempDb\DATA\tempdev.mdf". Operating system error 3: "3(The system cannot find the path specified.)".
2022-07-30 04:42:23.81 spid10s Error: 1802, Severity: 16, State: 4.
2022-07-30 04:42:23.81 spid10s CREATE DATABASE failed. Some file names listed could not be created. Check related errors.
2022-07-30 04:42:23.81 spid10s Could not create tempdb. You may not have enough disk space available. Free additional disk space by deleting other files on the tempdb drive and then restart SQL Server. Check for additional errors in the operating system error log that may indicate why the tempdb files could not be initialized.
2022-07-30 04:42:23.81 spid10s SQL Trace was stopped due to server shutdown. Trace ID = '1'. This is an informational message only; no user action is required.
TempDBの作成に失敗している。これは権限だったり、ディスクスペース不足だったり、そもそもフォルダがなかったりいろいろな原因があるようだが、自分の環境でログに指定されているDドライブのパスをみてみると、確かにTempDB用のディレクトリがない。
とりあえず、試しにTempDBディレクトリと、その中にDataフォルダとLogフォルダを作成する。
んでもって、このTempDBディレクトリに対してSQL Serverサービスが読み書きが行えるよう、指定しているログオンユーザにFULL CONTROL権限を与えてみる。
そして再度手動でSQL Serverサービスを起動。すると今度は立ち上がった!
この段階でポータルをみると、まだプロビジョニング状態はFailed、構成ブレードはグレーアウトされた状態だったので、以下の通りIaaSエージェント拡張機能の修復を行ってみたら、復旧した。
(この修復過程でVMの再起動が行われてるっぽいので、もしかしたらその再起動起因で正しい状態が反映されるようになっただけかもしれない)
肝心のSQL Serverへの接続もできるようになった。
根本原因
さて、とりあえずTempDBディレクトリを作成しなおすことで復旧できたけど、なんでこんなことが起こったのか。
結論、謎だった・・・が本来自然には起こらない事象と思われる。
Azure VMのDドライブは、既定では一時ディスクとなっており、再デプロイや停止→起動をした場合など、VMをホストする物理マシンが変わったタイミングで揮発する。(標準の再起動だと、揮発はしないとある)
Azure Disk Storage の概要 – Azure Virtual Machines | Microsoft Docs
なるほど、今回の場合は確かにしばらくVMを停止していた後で起動したので、Dドライブが揮発してTempDBフォルダがなくなったのかな。
と疑ってみたけど、SQL仮想マシンの機能で、TempDBをDドライブに配置した場合でも、フォルダ再作成を行ってくれる機能があり、有効化されている。
念のため実験してみる。
改めてVMを停止→起動して、物理マシンを入れ替えて一時ディスクを揮発させる。
ただ、うまくいった。
サービスは立ち上がっているし、
TempDBディレクトリも確かに再作成されている。
ポータル上の表示も問題ない。
うーむ、今回はTempDB作成エラーが出てしまった理由はよくわからないけど、以前どんな作業をしていたか全く思い出せないのでここらで打ち切ろうと思います。
再起動後にディレクトリを手動で消してしまったりしたのかな・・?
根本的な原因は不明でしたが、同じ問題に直面されている方のヒントに少しでもなれば幸いです。
また、この記事が役立ったという方は、下のいいねボタンをポチっていただけると励みになります。
おしまい
コメントを残す