TDEを設定した検証環境で、データベースの起動が startup の途中で止まり、「ORA-28365: ウォレットがオープンしていません」が返ってきました。
ウォレットが閉じていて読めなくなるのは、暗号化した表領域のデータだけ——データベース自体は起動も稼働もできる。
これは、ユーザー表領域だけを暗号化した一般的なTDE構成での話です。
暗号化の範囲を SYSTEM・SYSAUX・UNDO・TEMP まで広げると、ウォレットが開かないかぎり、データベースそのものが起動できなくなります。
この事象は、TDEの運用に慣れていない担当者には原因に気づきにくい障害です。
本記事では、この起動障害を再現し、原因の仕組みと復旧手順を、実機のログで解説します。
検証環境
- Oracle Database 19c (19.28) Enterprise Edition・非CDB構成
- OS: Oracle Linux 8
- TDE（透過的データ暗号化）設定済み・ソフトウェア・キーストア（ウォレット）運用
- 暗号化範囲: SYSTEM・SYSAUX・UNDO・TEMP＋機密データ用のユーザー表領域（TDE連載の第4回で構築した最終形）
1. 症状：startup が MOUNT で止まり ORA-28365
直前の停止は正常な shutdown immediate です。
クラッシュや障害が無くても、この事象は起きます。
データベースを起動すると、マウントまでは成功し、OPEN に進む段階でエラーになります。
SQL> startup
ORACLEインスタンスが起動しました。
Total System Global Area 1073739904 bytes
Fixed Size 8947840 bytes
Variable Size 637534208 bytes
Database Buffers 419430400 bytes
Redo Buffers 7827456 bytes
データベースがマウントされました。
ORA-28365: ウォレットがオープンしていません
インスタンスの状態を確認すると、MOUNT のまま残っています。
SQL> SELECT status FROM v$instance;
STATUS
------------
MOUNTED
インスタンス起動（NOMOUNT）と制御ファイルの読み込み（MOUNT）は正常に完了しています。
止まっているのは MOUNT → OPEN の遷移です。
startup が通る3段階を、それぞれ「何を読むか」で整理すると、止まった場所の意味が見えてきます。
| 段階 | 読むもの | 本環境での結果 |
|---|---|---|
| NOMOUNT | 初期化パラメータ（spfile）を読んでインスタンスを起動 | 成功 |
| MOUNT | 制御ファイルを読んでデータベースの構成を認識 | 成功 |
| OPEN | データファイルを開いてデータベースを利用可能に | ORA-28365 で失敗 |
TDE が暗号化しているのは、表領域のデータ——つまりデータファイルの中身です。
spfile と制御ファイルは暗号化の対象ではないため、NOMOUNT と MOUNT はウォレットが閉じていても通ります。
データファイルを読み始める OPEN で初めて復号が必要になり、そこで止まった、という形です。
この状態では当然、アプリケーションからの接続もできません。
単に「暗号化した表が読めない」のではなく、データベース全体が起動不能になっています。
2. 原因の仕組み
2-1. 何を暗号化しているかで、ウォレットが閉じているときの動作が変わる
まず切り分けの軸を整理します。
TDE環境でウォレット（キーストア）が閉じているときの動作は、何を暗号化しているかで変わります。
| ウォレットの状態 | ユーザー表領域のみ暗号化 | 起動処理が読み書きする表領域（SYSTEM等）も暗号化 |
|---|---|---|
| OPEN | 通常稼働 | 通常稼働 |
| CLOSED | DBはOPENできる。暗号化表領域へのアクセス時に ORA-28365 | startupが失敗する（本記事の事象） |
※ 左列は、正常停止後の起動だけでなく、クラッシュ後（未コミットの暗号化表更新を残した shutdown abort 後）の起動も実測しています。この検証ではクラッシュリカバリが最後まで実行され、OPEN まで進みました（よくある Q&A で触れます）。
ユーザー表領域のみ暗号化：ウォレットが閉じていても OPEN できる
通常のTDE（ユーザー表領域だけを暗号化した構成）では、ウォレットが閉じていてもデータベースは OPEN まで進みます。
エラーが出るのは、暗号化された表に SELECT 等でアクセスした瞬間です。
これも実機で確認しました。
比較用に、同じホストへユーザー表領域だけを暗号化したDB（19c 19.28・非CDB・ウォレットは手動で開くパスワード型のみ）をもう1つ用意し、本記事の障害と同じ条件（正常停止→ウォレットが閉じたまま起動）で startup します。
SQL> startup
ORACLEインスタンスが起動しました。
Total System Global Area 805305464 bytes
Fixed Size 8944760 bytes
Variable Size 218103808 bytes
Database Buffers 570425344 bytes
Redo Buffers 7831552 bytes
データベースがマウントされました。
データベースがオープンされました。
同じようにウォレットが閉じたままの起動でも、こちらは OPEN まで一気に進みました。
エラーが出るのは、暗号化した表を読んだ瞬間だけです。
SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE
------------------------------ --------------------
/u01/app/oracle/admin/orcl19t/wallet/tde/
CLOSED UNKNOWN
SQL> SELECT * FROM system.tde_test;
SELECT * FROM system.tde_test
*
行1でエラーが発生しました。:
ORA-28365: ウォレットがオープンしていません
起動処理が読み書きする表領域も暗号化：startup が失敗する
一方、SYSTEM・SYSAUX・UNDO のように、起動処理そのものが読み書きする領域が暗号化されていると、OPEN の途中でウォレットが必要になり、そこで失敗します。
本環境の暗号化状況です（障害の再現前・OPEN中に取得）。
SQL> SELECT t.name, e.encryptionalg FROM v$tablespace t JOIN v$encrypted_tablespaces e ON t.ts# = e.ts# ORDER BY t.name;
NAME ENCRYPT
------------------------------ -------
ENC256_TS AES256
ENC_TS AES256
NOENC_TS AES128
PLAIN_TS AES256
SYSAUX AES256
SYSTEM AES256
TEMP_ENC AES256
UNDOTBS1 AES256
8行が選択されました。
起動処理が読み書きする SYSTEM・SYSAUX・UNDO（UNDOTBS1）が、すべて暗号化されています。
本環境は、この節の最初に示した表の右列（startupが失敗する側）に該当します。
※ このビューには暗号化された表領域だけが出ます（暗号化していない USERS 等は表示されません）。NOENC_TS だけ AES128 なのは、ENCRYPTION 句なしで作成した表領域が ENCRYPT_NEW_TABLESPACES=ALWAYS により自動暗号化されたためです（アルゴリズムを指定しない場合の既定値が AES128）。
整理すると、ウォレットは何かを暗号化した時点から実質的に必須です。
何を暗号化しているかで変わるのは、ウォレットが閉じたときの失敗の現れ方——アプリケーションのエラーで済むか、起動障害になるか——です。
2-2. なぜ起動が失敗するのか：OPEN の入口で SYSTEM が読めない
OPEN 処理は、データディクショナリ（SYSTEM表領域の中にあります）を読みながら進みます。
その SYSTEM 自体が暗号化されていると、OPEN の入口で復号——つまりウォレット——が必要になります。
ウォレットが閉じたままだと、データディクショナリが読めない時点で先へ進めず、OPEN 開始直後に ORA-28365 で失敗します。
実際に alert.log でも、OPEN 開始から約2秒後に失敗し、その間の処理の記録が何も残っていないことを、この後の調査手順で確認します。
2-3. もう1つの前提：起動時にウォレットが開かれない
SYSTEM などの暗号化だけでは、この障害は起きません。
起動時にウォレットが開かれないことが重なって、初めて起動不能になります。
本環境のウォレットは、パスワードを入力して開くパスワード型（ewallet.p12）です。
パスワード型のウォレットは、誰かが手動で開かないかぎり閉じたままです。
そして、インスタンスを再起動すると、ウォレットは閉じた状態で始まります（『Oracle Database Advanced Securityガイド』「TDEウォレットのオープンについて」）。
つまりこの障害の構図は、次の3つの重なりです。
起動処理が読み書きする表領域（SYSTEM等）の暗号化 × パスワード型ウォレット（手動オープン） × インスタンス再起動
3. 調査手順
Step 1：alert.log で「どこで止まったか」を確認する
ORA-28365 で起動が失敗したら、まず alert.log で OPEN 処理がどこまで進んで何で中断したかを確認します。
alert.log は $ORACLE_BASE/diag/rdbms/{DB名}/{SID}/trace/alert_{SID}.log にあります。
Completed: ALTER DATABASE MOUNT
2026-07-25T17:28:33.273861+09:00
ALTER DATABASE OPEN
2026-07-25T17:28:35.344553+09:00
ORA-28365 signalled during: ALTER DATABASE OPEN...
読み取れることは2つです。
- MOUNT は正常に完了し、
ALTER DATABASE OPENの開始から約2秒後に ORA-28365 で失敗している - OPEN 開始と失敗の間に、処理の記録が何もない＝REDOの適用やUNDOの初期化といった工程に入る前、OPEN処理の入口で止まっている
startup の応答に出る「ORA-28365」の1行だけでは分からない中断箇所が、alert.log では追えます。
Step 2：ウォレットの構成と状態を確認する
ウォレットの状態は、MOUNT のままでも v$encryption_wallet で確認できます。
SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE
------------------------------ --------------------
/u01/app/oracle/admin/orcl19u/wallet/tde/
CLOSED UNKNOWN
※ ウォレットの場所を示す列は wrl_parameter です（wrl_directory という列は存在せず、ORA-00904 になります）。
STATUS=CLOSED。ウォレットが開いていません。
次に、ウォレット・ディレクトリの中身を確認します。
SQL> !ls -l /u01/app/oracle/admin/orcl19u/wallet/tde/
合計 8
-rw-------. 1 oracle oinstall 3993 6月 15 16:45 ewallet.p12
-rw-------. 1 oracle oinstall 2553 6月 15 16:45 ewallet_2026061507450808.p12
あるのは ewallet.p12（パスワード型キーストア）だけです。
この構成では、インスタンスを再起動するたびにウォレットは閉じた状態で始まり、誰かが手動で開くまで閉じたままです。
Step 3：SYSTEM が暗号化されていることを確認する（MOUNTのまま）
表領域の暗号化状態は通常 dba_tablespaces の ENCRYPTED 列で確認しますが、DBA系のビューは OPEN 前は参照できません。
一方、v$ ビューは MOUNT でも参照できます。
SQL> SELECT t.name, e.encryptionalg FROM v$tablespace t JOIN v$encrypted_tablespaces e ON t.ts# = e.ts# ORDER BY t.name;
NAME ENCRYPT
------------------------------ -------
SYSTEM AES256
本環境の実測では、MOUNT の時点で v$encrypted_tablespaces に出るのは SYSTEM の1行だけでした（OPEN 後は暗号化表領域の全量が出ます）。
それでも、OPEN の入口で読まれる SYSTEM が暗号化されていることはこの時点で特定でき、起動が失敗する説明がつきます。
ここまでで、原因の構図（SYSTEM などの暗号化 × 起動時にウォレットが開かれない）が実機で裏付けられました。
4. 復旧手順
原因が「ウォレットが開いていない」ことなので、復旧はウォレットを開いて OPEN に進めるだけです。
Step 1：MOUNTのままキーストアを開く
MOUNT 状態のまま、パスワードを指定してキーストアを開きます。
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "********";
キーストアが変更されました。
実際に踏んだ失敗：ここで startup を打ち直すと振り出しに戻る
キーストアが開いたので、あらためて startup で起動し直したくなります。
実際にやってみた結果がこれです。
SQL> startup
ORA-01081: すでに稼働中のOracleは起動できません - まずシャットダウンしてください
SQL> shutdown immediate
ORA-01109: データベースがオープンされていません。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SQL> startup
ORACLEインスタンスが起動しました。
Total System Global Area 1073739904 bytes
Fixed Size 8947840 bytes
Variable Size 637534208 bytes
Database Buffers 419430400 bytes
Redo Buffers 7827456 bytes
データベースがマウントされました。
ORA-28365: ウォレットがオープンしていません
MOUNT で止まっているだけで、インスタンス自体は稼働中です。
稼働中のインスタンスに startup は打てないので、ORA-01081 になります。ここまでは当然の動作です。
従ってしまいがちなのが、このエラーメッセージの「まずシャットダウンしてください」という指示です。
この文言どおりに shutdown → startup すると、パスワード型キーストアの OPEN 状態はインスタンス上に保持されているため、再起動で失われます。
つまり、せっかく開いたキーストアが閉じ直され、振り出しに戻ります。
alert.log でも、2回目の失敗が1回目と同じ形（ALTER DATABASE OPEN の約2秒後に signalled）で記録されていました。
必要なのは再起動ではなく、止まっている MOUNT → OPEN の遷移を進めることです。
その手順を次に示します。
Step 2：ALTER DATABASE OPEN で OPEN へ進める
キーストアを開き直してから、ALTER DATABASE OPEN で OPEN へ進めます。
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "********";
キーストアが変更されました。
SQL> ALTER DATABASE OPEN;
データベースが変更されました。
インスタンスとウォレットの状態を確認します。
SQL> SELECT status FROM v$instance;
STATUS
------------
OPEN
SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE
------------------------------ --------------------
/u01/app/oracle/admin/orcl19u/wallet/tde/
OPEN PASSWORD
alert.log 側でも、今回は OPEN 処理が最後まで実行されています。
2026-07-25T17:47:41.643471+09:00
KZTDE: Attempting TDE operation in PDB#=0: ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY *
2026-07-25T17:47:46.816801+09:00
ALTER DATABASE OPEN
（関連行のみ抜粋）
...
Completed: ALTER DATABASE OPEN
ただし、WALLET_TYPE は PASSWORD のままです。
手動でパスワードを入れて開いただけなので、次にインスタンスを再起動すれば、ウォレットはまた閉じた状態で始まります。
5. 恒久対応：自動ログイン・ウォレットを作成する
復旧はできましたが、WALLET_TYPE=PASSWORD＝手動でパスワードを入れて開いただけの状態です。
このままでは、次にインスタンスを再起動したとき、また同じ起動障害が起きます（キーストアを手動で開くまで OPEN できません）。
しかも、次に対応するのが TDE の設定経緯を知っている担当者だとは限りません。
この「毎回手動で開く」をなくす仕組みが、自動ログイン・ウォレットです。
パスワード型キーストア（ewallet.p12）から生成する cwallet.sso というファイルで、ウォレット・ディレクトリに置いてあると、起動時にパスワード入力なしでウォレットが自動的に開きます。
ウォレットが開いた状態で OPEN 処理に入れるため、この起動障害そのものが起きなくなります。
用語の注意: 「自動ログイン・ウォレット」は、ウォレット（キーストア）がDB起動時に自動で開く仕組みのことです。OS起動時にデータベース自体を自動起動する設定（
dbstart等の「自動起動」）とは別のものなので、区別してください。
作成時には LOCAL を付けるかどうかを選びます。
LOCAL を付けて作成した cwallet.sso は作成したホストでしか開けません。
一方、LOCAL なしで作成した cwallet.sso は、他のホストからでも開けます。
Oracle RAC のようにウォレットを複数ノードで共有する構成では、ノードごとにホスト名が異なるため LOCAL を付けずに作成しますが（『Oracle Database Advanced Securityガイド』）、本記事のような単一ホストの構成では LOCAL を付けます。
それでは作成します。
SQL> ADMINISTER KEY MANAGEMENT CREATE LOCAL AUTO_LOGIN KEYSTORE FROM KEYSTORE '/u01/app/oracle/admin/orcl19u/wallet/tde' IDENTIFIED BY "********";
キーストアが変更されました。
SQL> !ls -l /u01/app/oracle/admin/orcl19u/wallet/tde/
合計 12
-rw-------. 1 oracle oinstall 4038 7月 25 17:49 cwallet.sso
-rw-------. 1 oracle oinstall 3993 6月 15 16:45 ewallet.p12
-rw-------. 1 oracle oinstall 2553 6月 15 16:45 ewallet_2026061507450808.p12
cwallet.sso が作成されました。
再起動テスト：エラーなく OPEN まで進むことを確認
恒久対応の検証として、実際に再起動します。
SQL> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SQL> startup
ORACLEインスタンスが起動しました。
（中略・SGA表示）
データベースがマウントされました。
データベースがオープンされました。
SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE
------------------------------ --------------------
/u01/app/oracle/admin/orcl19u/wallet/tde/
OPEN LOCAL_AUTOLOGIN
startup 一発で OPEN まで進み、WALLET_TYPE が LOCAL_AUTOLOGIN になっています。
起動時にウォレットが自動で開く状態になり、再発は防止されました。
自動ログイン・ウォレットのトレードオフ
自動ログイン・ウォレットは、パスワード入力なしで開けるファイルです。
ただし LOCAL 付きで作成した cwallet.sso は作成したホストでしか開けません（『Oracle Database Advanced Securityガイド』）。
データファイルと一緒に持ち出されても、他ホストでは自動オープンできず、TDEが本来守る「媒体を持ち出されても読めない」は保たれます。
残るのは、そのホスト自体に侵入された場合です。
パスワード型なら、侵入者は ewallet.p12 を手に入れてもキーストアのパスワードがなければ開けません。自動ログインではその一手間が無くなります。
ただし、OSの oracle ユーザーを取られた時点で稼働中のDBには接続できてしまうため、ここはもともとTDEの守備範囲ではありません（TDEは保存された媒体に対する防御です）。
実務では、起動のたびに人手でキーストアを開ける運用が現実的でないかぎり、LOCAL AUTO_LOGIN を選ぶことになります。
そのうえで、cwallet.sso のファイル権限の管理と、ウォレットのバックアップをデータファイルとは別の場所に保管する運用をセットにしてください。
6. よくある Q&A
Q1. ウォレットが閉じていると、TDE環境のDBは必ず起動できないのですか？
いいえ。
ユーザー表領域だけを暗号化した通常の構成では、ウォレットが閉じていても OPEN まで進みます（エラーになるのは暗号化表領域へのアクセス時）。
起動が失敗するのは、SYSTEM・SYSAUX・UNDOのように OPEN処理そのものが読み書きする表領域が暗号化されている場合です（「原因の仕組み」の表を参照）。
クラッシュ後の起動も実測しました。
ユーザー表領域だけを暗号化した比較用DBで、暗号化表を更新してコミットしないまま shutdown abort し、ウォレットが閉じたまま起動しています。
Beginning crash recovery of 1 threads
parallel recovery started with 2 processes
Thread 1: Recovery starting at checkpoint rba (logseq 13 block 1359), scn 0
（関連行のみ抜粋）
...
Completed redo scan
read 1223 KB redo, 156 data blocks need recovery
...
Completed crash recovery at
Thread 1: RBA 13.3805.16, nab 3805, scn 0x0000000000236c0d
156 data blocks read, 156 data blocks written, 1223 redo k-bytes read
...
Completed: ALTER DATABASE OPEN
クラッシュリカバリはウォレットが閉じたまま最後まで実行され、OPEN まで進みました。
起動後、ウォレットが閉じたままでは暗号化表を読めず（ORA-28365）、キーストアを開くと、未コミットだった更新がロールバックされた状態の値を読めました。
なお、これは1つの条件（未コミット更新1件＋直後の shutdown abort）での実測です。
クラッシュの状況が違っても常に起動できる、とまでは言い切れません。
Q2. キーストアのパスワードは alert.log に残りませんか？
残りません。
alert.log では ADMINISTER KEY MANAGEMENT ... IDENTIFIED BY * と、パスワード部分が自動的にマスクされて記録されます（復旧手順の alert.log 抜粋で確認できます）。
Q3. 自動ログイン・ウォレットを使わず、パスワード型のまま運用する場合、どう起動すればいいですか？
STARTUP MOUNT で MOUNT まで起動し、キーストアを開いてから OPEN へ進めます。
STARTUP MOUNT
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "********";
ALTER DATABASE OPEN;
本記事の復旧手順と同じ流れを、エラーを踏まずに最初から計画的に行う形です。
（startup で起動して MOUNT で止まってからキーストアを開いても結果は同じですが、エラーを前提にした手順になるため、手動運用なら STARTUP MOUNT から入るのが素直です。）
Q4. 暗号化の範囲が狭い構成でも、挙動は同じですか？
「ウォレットが閉じている限り起動が失敗する」こと自体は、起動処理が読み書きする表領域（SYSTEM・SYSAUX・UNDO）のどれかが暗号化されていれば同じです。
ただし、失敗の箇所と形は変わります。
本環境の以前の構成（UNDOのみ暗号化）での実測では、正常停止後の起動は UNDO の初期化で失敗してインスタンスごと強制終了し（ORA-01092）、異常停止後の起動はクラッシュリカバリの REDO 復号で失敗して MOUNT に残りました（暗号化表領域に対する変更は REDO も暗号化されるため、復号にウォレットが必要です。『Oracle Database Advanced Securityガイド』「透過的データ暗号化表領域暗号化の動作」の注記）。
SYSTEM まで暗号化した本記事の構成では、停止経路によらず OPEN 開始直後に失敗して MOUNT に残ります。
復旧手順は共通です（インスタンスが終了している場合のみ、先に startup mount で MOUNT まで起動してから、キーストアを開いて ALTER DATABASE OPEN します）。
Q5. CDB構成（マルチテナント）でも同じですか？
本記事は非CDB構成での実測です。
CDB構成ではキーストアをCDB全体で共有する構成（United Mode）が基本になり、自動ログイン・ウォレットの置き場所や管理単位も変わります。
CDB環境でのTDE運用は、別記事で実機検証します。
7. まとめ
対応フローを整理します。
startup が失敗（ORA-28365・MOUNTで停止）
│
├─ alert.log … どこで中断したか（OPEN開始直後に signalled・中間記録なし）
├─ ウォレットの構成と状態 … cwallet.sso（自動ログイン）の有無・v$encryption_wallet
└─ v$encrypted_tablespaces … SYSTEM が暗号化されているか確認（MOUNTでも参照可）
↓
MOUNTのまま ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN
↓
ALTER DATABASE OPEN ※ startup 打ち直しは振り出しに戻る
↓
恒久対応: CREATE LOCAL AUTO_LOGIN KEYSTORE → 再起動テストで実証
ポイントは3つです。
- 切り分けの軸：ウォレットが閉じた状態で「OPENして表が読めない」なら通常のTDEの動作、「起動が失敗する」なら起動処理が読み書きする表領域（SYSTEM・SYSAUX・UNDO）の暗号化を疑う
- 復旧：MOUNTの状態でキーストアを開き、
ALTER DATABASE OPEN。startupの打ち直しはキーストアが閉じ直して振り出しに戻る - 予防：SYSTEM などの暗号化と自動ログイン・ウォレットの整備はセットで行う。片方だけだと、次の再起動が起動障害になる
TDEの導入手順・鍵管理・SYSTEM/SYSAUX暗号化の全体像は、TDE連載（設計と基本構築／守れる範囲・守れない範囲／鍵の管理／SYSTEM・SYSAUX・UNDO・TEMPの暗号化）で実機検証しています。
