【完全ガイド】ORA-01034: ORACLE not available の原因と解決方法｜DB 未起動・ORACLE_SID・ORA-27101・FRA フル 徹底解説

Oracle DBA・開発者が本番緊急事態で真っ先に遭遇する致命的エラー:

ERROR:
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory

「Oracle が使えない」というシンプルなメッセージ。しかし、これは本番システムの完全停止を意味します:

• 全てのアプリからの DB アクセス不可
• 開発者もログインできない
• DBA が緊急対応を強いられる
• 業務停止の危機
• 監視アラート大量発生

このエラーの本質は、Oracle インスタンスへの接続不可:

1. DB インスタンス自体が起動していない、または
2. クライアントが正しいインスタンスに接続できない

現場で最も典型的なのは、以下 3 パターン:

• DB が完全停止（クラッシュ / メンテナンス）
• ORACLE_SID が間違っている（インスタンス名不一致）
• ORACLE_HOME の設定違い（バージョン混在）

さらに、伴発する ORA-27101 (shared memory realm does not exist) が原因特定の重要な手がかり:

ORA-01034: ORACLE not available          ← 一般的な「使えない」
ORA-27101: shared memory realm does not exist  ← 共有メモリ realm 不在

ORA-27101 は「指定されたインスタンス名の共有メモリセグメントが存在しない」を意味し、インスタンス未起動またはSID 不一致が原因。

現場では:

• Windows Server のサービス停止（電源断後）
• Linux での pmon プロセス不在
• ORACLE_SID の大文字小文字ミス（Unix は case-sensitive）
• FRA (Fast Recovery Area) フルによる自動シャットダウン
• アーカイブログ満杯
• DB クラッシュ（内部エラー ORA-00600 等）
• RAC ノードの1つだけ停止
• パラメータファイル破損
• ライセンス期限切れ
• ストレージフル

多くの日本語記事が「STARTUP せよ」で終わりますが、実務では:

• ORA-27101 の付随情報の重要性
• ORACLE_SID / ORACLE_HOME の正しい設定
• pmon プロセス確認による起動状態判定
• lsnrctl status の見方
• alert log での原因特定
• FRA フル（db_recovery_file_dest_size 超過）対応
• SHUTDOWN ABORT vs SHUTDOWN IMMEDIATE
• Rails / Java / Python アプリでの適切な対応
• 監視・アラート設計
• DR (Disaster Recovery) シナリオ

本記事では、ORA-01034: ORACLE not available の完全な原因と解決方法を、リファレンスとして実用的に整理します。10大発生パターン、ORA-27101 との併発、6つの解決策、緊急対応手順、Rails/Java/Python 対応、実践シナリオ、FAQまで完全網羅。この1本で ORA-01034 に冷静に的確に対処できるようになります。

結論：DB 未起動 or 接続先間違い

時間がない方向けに、最速の対処を先に示します。

エラーメッセージの読み方

ORA-01034: ORACLE not available
                    ↑
              Oracle インスタンスが使えない

+ 併発するエラーで原因特定
ORA-27101: shared memory realm does not exist  ← インスタンス不在/SID 不一致
ORA-01031: insufficient privileges              ← 権限問題

最速の緊急対応

# STEP 1: OS プロセス確認
ps -ef | grep pmon
# ora_pmon_ORCL があれば DB 起動中

# STEP 2: ORACLE_SID 確認
echo $ORACLE_SID
# 正しいインスタンス名か

# STEP 3: リスナー確認
lsnrctl status

# STEP 4: SYSDBA 接続試行
sqlplus / as sysdba
SQL> SELECT status FROM v$instance;

# STEP 5: 起動されていなければ STARTUP
SQL> STARTUP

6つの解決策

主要なエラーコード

併発するエラーで原因特定。

詳細は以下で解説します。

Oracle インスタンス構造

インスタンスとデータベース

Oracle Instance = メモリ (SGA) + プロセス
Oracle Database = ファイル群 (データファイル/制御ファイル/REDO)

インスタンスがデータベースをマウント/オープンして「使える」状態

状態遷移

SHUTDOWN
   ↓ STARTUP NOMOUNT
NOMOUNT（インスタンスのみ、DB 未マウント）
   ↓ ALTER DATABASE MOUNT
MOUNT（制御ファイル読み込み済み）
   ↓ ALTER DATABASE OPEN
OPEN（通常利用可能）

ORA-01034 = インスタンスが SHUTDOWN or 到達不可。

主要プロセス

PMON: Process Monitor（プロセス監視）
SMON: System Monitor（システム監視）
DBWR: Database Writer（データ書き込み）
LGWR: Log Writer（ログ書き込み）
CKPT: Checkpoint（チェックポイント）
ARCH: Archiver（アーカイブ）

ps -ef | grep pmon で PMON プロセス確認 → DB 起動有無判定。

【原因①】DB インスタンス未起動（最頻出）

症状

sqlplus scott/tiger
# ERROR:
# ORA-01034: ORACLE not available
# ORA-27101: shared memory realm does not exist

診断

# PMON プロセス確認
ps -ef | grep pmon
# 何も表示されなければ未起動

# または
ps -ef | grep ora_

# Windows
tasklist | findstr oracle

解決

# 環境変数設定
export ORACLE_SID=ORCL
export ORACLE_HOME=/u01/app/oracle/product/19c/db_1

# 起動
sqlplus / as sysdba
SQL> STARTUP

Windows:

set ORACLE_SID=ORCL
sqlplus / as sysdba
SQL> STARTUP

【原因②】ORACLE_SID 誤設定

症状（超典型）

echo $ORACLE_SID
# testdb  ← 存在しない or 間違い

sqlplus / as sysdba
# ORA-01034 + ORA-27101

# 正しい SID 確認
ps -ef | grep pmon
# ora_pmon_ORCL   ← 実際の SID は ORCL

罠：大文字小文字（Unix）

Unix / Linux では case-sensitive:

export ORACLE_SID=orcl   # ❌ 小文字
export ORACLE_SID=ORCL   # ✅ 実際の SID と一致

解決

# 正しい SID に設定
export ORACLE_SID=ORCL   # PMON の名前に合わせる

# 確認
sqlplus / as sysdba
SQL> SELECT instance_name FROM v$instance;
-- ORCL

【原因③】ORACLE_HOME 設定違い

症状

複数の Oracle バージョンがインストール:

# Oracle 19c と 21c が同居
echo $ORACLE_HOME
# /u01/app/oracle/product/19c/db_1

# しかし DB は 21c で起動
# → ORA-01034

診断

# 起動している DB のバージョン
ps -ef | grep pmon
# ora_pmon_ORCL /u01/app/oracle/product/21c/db_1/...

解決

# ORACLE_HOME を正しいバージョンに
export ORACLE_HOME=/u01/app/oracle/product/21c/db_1
export PATH=$ORACLE_HOME/bin:$PATH

# 確認
which sqlplus

【原因④】リスナー未起動

症状（リモート接続）

sqlplus scott/tiger@//dbserver:1521/orcl
# ORA-12541: TNS:no listener  ← リスナー未起動
# または
# ORA-12514: TNS:listener does not currently know of service requested

診断

lsnrctl status

リスナー起動していない場合:

TNS-12541: TNS:no listener

解決

lsnrctl start
# LISTENER 起動

lsnrctl status
# READY 確認

リスナー関連は ORA-12541: TNS no listener の記事、ORA-12154: TNS could not resolve の記事も参照してください。

【原因⑤】FRA (Fast Recovery Area) フル

症状

DB 自動シャットダウン
alert log:
"ORA-19809: limit exceeded for recovery files"
"ORA-19804: cannot reclaim ... bytes disk space from ..."

診断

-- FRA 使用状況
SELECT * FROM v$recovery_file_dest;
-- SPACE_USED >= SPACE_LIMIT なら満杯

SELECT file_type, percent_space_used, percent_space_reclaimable
FROM v$flash_recovery_area_usage;

解決A: FRA サイズ拡張

# SYSDBA でマウントモード起動
sqlplus / as sysdba
SQL> STARTUP MOUNT

-- FRA サイズ拡張
ALTER SYSTEM SET db_recovery_file_dest_size = 250G;

-- または場所変更
ALTER SYSTEM SET db_recovery_file_dest = '/new/path';

SQL> ALTER DATABASE OPEN;

解決B: アーカイブ削除

rman target /
RMAN> DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7';

【原因⑥】Windows サービス停止

症状

Windows Server の再起動後:

sqlplus / as sysdba
> ORA-01034

診断

sc query OracleServiceORCL
# STATE : STOPPED

解決

# サービス起動
net start OracleServiceORCL

# または services.msc から
# OracleService<SID> を右クリック → 開始

# 自動起動設定
sc config OracleServiceORCL start= auto

【原因⑦】DB クラッシュ

症状

alert log にエラー多数:
"ORA-00600: internal error"
"ORA-04031: unable to allocate ... memory"

診断

# alert log 確認
tail -100 $ORACLE_BASE/diag/rdbms/<sid>/<sid>/trace/alert_<sid>.log

# 最新のシャットダウン理由
grep -i "shutdown" alert_*.log | tail -20

解決

sqlplus / as sysdba

-- クラッシュリカバリで自動的に SMON が回復
SQL> STARTUP
-- ORA-01113 等出れば手動リカバリ必要

-- 必要なら
SQL> RECOVER DATABASE;
SQL> ALTER DATABASE OPEN;

内部エラーは ORA-00600: internal error の記事、メモリ関連は ORA-04031: shared memory の記事も参照してください。

【原因⑧】パラメータファイル問題

症状

SQL> STARTUP
LRM-00109: could not open parameter file '/init.ora'
ORA-01078: failure in processing system parameters

解決

-- SPFILE から起動
SQL> STARTUP SPFILE='/u01/app/oracle/spfileORCL.ora';

-- または PFILE 明示
SQL> STARTUP PFILE='/u01/app/oracle/initORCL.ora';

【原因⑨】ストレージフル

症状

alert log:
"ORA-19502: write error on file ..."
"OS Error: (Linux Error: 28: No space left on device)"

診断

df -h
# 満杯確認

解決

# 不要ファイル削除
rm /path/to/old_archive_logs/*

# または LVM 拡張、ディスク増設

Docker no space の詳細は Docker no space left on device の記事も参照してください。

【原因⑩】RAC ノード故障

症状

# クラスタ状態
crsctl stat res -t
# INST_1: OFFLINE

解決

srvctl start instance -d orcl -i orcl1
crsctl start crs

# 状態確認
srvctl status database -d orcl

診断ツール完全リファレンス

プロセス確認

# Linux/Unix
ps -ef | grep pmon
ps -ef | grep ora_

# Windows
tasklist | findstr oracle

インスタンス状態

sqlplus / as sysdba

-- 状態
SELECT status FROM v$instance;
-- OPEN / MOUNTED / STARTED

-- 詳細
SELECT instance_name, host_name, status, database_status, startup_time
FROM v$instance;

alert log

# alert log の場所
sqlplus / as sysdba <<EOF
SELECT value FROM v\$diag_info WHERE name = 'Diag Trace';
EOF

# 例: /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log

# 直近の内容
tail -200 alert_orcl.log

# エラー抽出
grep -i "ora-" alert_orcl.log | tail -50

リスナー

lsnrctl status
lsnrctl services

V$RECOVERY_FILE_DEST

SELECT space_used, space_limit, 
       space_used * 100 / space_limit AS pct
FROM v$recovery_file_dest;

6つの解決策 完全リファレンス

解決策① STARTUP

sqlplus / as sysdba

SQL> STARTUP
-- インスタンス起動 + マウント + オープン

-- 段階的に
SQL> STARTUP NOMOUNT;
SQL> ALTER DATABASE MOUNT;
SQL> ALTER DATABASE OPEN;

-- 制限モード（メンテナンス用）
SQL> STARTUP RESTRICT;

-- 復旧モード
SQL> STARTUP MOUNT;
SQL> RECOVER DATABASE;
SQL> ALTER DATABASE OPEN;

解決策② ORACLE_SID 設定

# 現在の SID
echo $ORACLE_SID

# 正しく設定
export ORACLE_SID=ORCL
# .bashrc に追加

# Windows
set ORACLE_SID=ORCL
# システム環境変数に追加

解決策③ リスナー起動

# 起動
lsnrctl start

# 特定リスナー
lsnrctl start LISTENER_XPT

# 停止
lsnrctl stop

# 再起動
lsnrctl stop && lsnrctl start

解決策④ FRA 拡張

-- サイズ拡張
ALTER SYSTEM SET db_recovery_file_dest_size = 500G;

-- または場所変更
ALTER SYSTEM SET db_recovery_file_dest = '/new/large/path';

解決策⑤ Windows サービス起動

net start OracleServiceORCL
net start OracleOraDB19Home1TNSListener

# 自動起動
sc config OracleServiceORCL start= auto

解決策⑥ alert log 確認

# 最新の状態
tail -f $ORACLE_BASE/diag/rdbms/<sid>/<sid>/trace/alert_<sid>.log

# エラー履歴
grep -B 2 -A 5 "ORA-" alert_orcl.log

Rails / Java / Python 対応

Rails ActiveRecord

エラーハンドリング:

begin
  User.first
rescue ActiveRecord::StatementInvalid => e
  if e.message.include?("ORA-01034") || e.message.include?("ORA-27101")
    Rails.logger.fatal "Oracle DB unavailable"
    # 監視アラート
    NotifyOps.send("Oracle DB Down")
    # 再接続試行
    ActiveRecord::Base.connection.reconnect!
  end
end

接続の自動リトライ:

# config/initializers/oracle_retry.rb
class ActiveRecord::Base
  class << self
    def connection_with_retry
      retries = 0
      begin
        connection_without_retry
      rescue => e
        if e.message.include?("ORA-01034") && retries < 3
          retries += 1
          sleep(2 ** retries)
          reconnect!
          retry
        end
        raise
      end
    end
  end
end

Rails 8 系の詳細は Rails 8 アップグレードガイドの記事、find/find_by/where の記事も参照してください。

Java (JDBC)

try {
    Connection conn = ds.getConnection();
} catch (SQLException e) {
    if (e.getErrorCode() == 1034 || e.getErrorCode() == 27101) {
        logger.fatal("Oracle DB unavailable: " + e.getMessage());
        // 監視ツールへ通知
        alertingService.notify("Oracle DB Down");
    }
}

Python (oracledb)

import oracledb

try:
    conn = oracledb.connect(user=user, password=pw, dsn=dsn)
except oracledb.DatabaseError as e:
    error_obj, = e.args
    if error_obj.code in (1034, 27101):
        print(f"Oracle DB unavailable: {error_obj.message}")
        # 監視通知

実践シナリオ

シナリオ1：本番緊急対応

# 1. アラート受信
# "ORA-01034: ORACLE not available"

# 2. サーバーへログイン
ssh dbserver

# 3. プロセス確認
ps -ef | grep pmon
# 何もない → DB 完全停止

# 4. alert log 確認
tail -100 $ORACLE_BASE/diag/rdbms/orcl/orcl/trace/alert_orcl.log

# 5. 停止原因判明
# 例: "ORA-19809: limit exceeded for recovery files"

# 6. FRA 拡張して起動
sqlplus / as sysdba
SQL> STARTUP MOUNT;
SQL> ALTER SYSTEM SET db_recovery_file_dest_size = 500G;
SQL> ALTER DATABASE OPEN;

# 7. 監視・報告

シナリオ2：ORACLE_SID 設定ミスの対処

# 症状確認
sqlplus / as sysdba
# ORA-01034 + ORA-27101

# 現在の SID
echo $ORACLE_SID
# testdb

# 実際の SID
ps -ef | grep pmon
# ora_pmon_PROD01

# 修正
export ORACLE_SID=PROD01
sqlplus / as sysdba
# OK

# .bashrc に永続化
echo 'export ORACLE_SID=PROD01' >> ~/.bashrc

シナリオ3：DB 起動シェルスクリプト

#!/bin/bash
# start_db.sh

export ORACLE_SID=ORCL
export ORACLE_HOME=/u01/app/oracle/product/19c/db_1
export PATH=$ORACLE_HOME/bin:$PATH

# リスナー起動
lsnrctl start

# DB 起動
sqlplus / as sysdba <<EOF
STARTUP;
EXIT;
EOF

# 状態確認
sqlplus / as sysdba <<EOF
SELECT status FROM v\$instance;
EOF

systemctl 関連は systemctl vs service の記事、シェルスクリプト運用は Linux でプロセスをバックグラウンド実行する方法の記事も参照してください。

シナリオ4：Docker Compose での DB 再起動

services:
  oracle-db:
    image: gvenzl/oracle-xe:21
    restart: always
    healthcheck:
      test: ["CMD", "healthcheck.sh"]
      interval: 30s
      timeout: 10s
      retries: 3

Docker 関連は docker daemon 接続エラーの記事、Docker no space left on device の記事も参照してください。

シナリオ5：Kamal デプロイでの対応

# デプロイ前に DB 状態確認
docker exec -it db-container sqlplus / as sysdba <<EOF
SELECT status FROM v\$instance;
EOF

# デプロイ
kamal deploy

# アプリからの接続確認
kamal app exec 'rails console'
User.count

Kamal 2 デプロイの詳細は Kamal 2 デプロイの記事を参照してください。

シナリオ6：Rails 起動時の DB 待機

# config/initializers/wait_for_db.rb
Rails.application.config.after_initialize do
  retries = 0
  begin
    ActiveRecord::Base.connection.execute("SELECT 1 FROM DUAL")
  rescue ActiveRecord::StatementInvalid => e
    if e.message.include?("ORA-01034") && retries < 30
      retries += 1
      Rails.logger.warn "Waiting for DB... attempt #{retries}"
      sleep(2)
      retry
    end
    raise
  end
end

シナリオ7：AWS RDS Oracle

RDS では OS レベルアクセス不可
→ Automated Backup, Point-in-time Recovery
→ Modify DB Instance で緊急対応

シナリオ8：Autonomous DB

Autonomous DB は自動起動/停止管理
→ ORA-01034 発生時はコンソールで状態確認
→ Start/Stop DB Instance ボタン

シナリオ9：Java Spring での起動待機

@Configuration
public class DatabaseInitializer {
    @Bean
    public ApplicationRunner waitForDatabase(DataSource ds) {
        return args -> {
            int retries = 0;
            while (retries < 30) {
                try (Connection conn = ds.getConnection()) {
                    logger.info("DB is ready");
                    return;
                } catch (SQLException e) {
                    if (e.getErrorCode() == 1034 || e.getErrorCode() == 27101) {
                        logger.warn("Waiting for DB...");
                        Thread.sleep(2000);
                        retries++;
                    } else {
                        throw e;
                    }
                }
            }
            throw new IllegalStateException("DB not available after 60s");
        };
    }
}

シナリオ10：定期監視スクリプト

#!/bin/bash
# monitor_db.sh

STATUS=$(sqlplus -s / as sysdba <<EOF
SET HEADING OFF FEEDBACK OFF PAGESIZE 0
SELECT status FROM v\$instance;
EXIT;
EOF
)

if [[ ! "$STATUS" =~ "OPEN" ]]; then
  # アラート送信
  echo "DB is not OPEN: $STATUS" | mail -s "DB Alert" ops@example.com
fi

crontab の詳細は crontab 使い方の記事も参照してください。

トラブルシューティング

STARTUP でエラー

ORA-01102: cannot mount database in EXCLUSIVE mode
→ 他のセッションが起動している

ORA-01113: file needs media recovery
→ RECOVER 必要

shared memory 不足

ORA-27102: out of memory
→ SGA を減らす、または OS memory 拡張

プロセスは動いているが接続できない

ps -ef | grep pmon    → プロセスあり
lsnrctl status        → リスナー OK

しかし ORA-01034
→ SGA が破損、DB を再起動

Windows サービス起動失敗

イベントビューア確認
ORA-01034: サービス起動失敗
→ ORACLE_HOME 設定確認

RAC 環境

crsctl stat res -t
# 特定ノードのみ OFFLINE

srvctl start instance -d orcl -i orcl2

アップグレード直後

Oracle 19c → 23ai アップグレード
→ 起動失敗、パラメータ互換性
→ MOS ドキュメント参照

よくある質問（FAQ）

Q1. ORA-01034 と ORA-27101 の違い

• ORA-01034: 一般的な「使えない」
• ORA-27101: 共有メモリ realm 不在（インスタンス未起動 or SID 不一致）

Q2. 最初にチェックすべき

ps -ef | grep pmon で DB プロセス確認。

Q3. ORACLE_SID の大文字小文字

Unix/Linux は case-sensitive、Windows は case-insensitive。

Q4. リスナーが必要か

リモート接続には必要、ローカル (BEQ/IPC) は不要。

Q5. FRA フル対処

サイズ拡張 or アーカイブ削除。

Q6. Rails での再接続

ActiveRecord::Base.connection.reconnect!

Q7. Java での監視

errorCode == 1034 で判定、監視ツールへ通知。

Q8. Python での対応

oracledb DatabaseError をキャッチ、code in (1034, 27101)。

Q9. Windows のサービス自動起動

sc config OracleServiceORCL start= auto

Q10. Autonomous DB

コンソールから Start/Stop、通常は自動管理。

Q11. パフォーマンスへの影響

DB 起動中は全停止、業務影響大。事前計画必須。

Q12. Docker 環境

restart: always + healthcheck で自動再起動。

参考リンク

Oracle 公式

• Oracle Database Error Messages: ORA-01034
• Oracle Database Error Messages: ORA-27101
• Oracle Database Administrator’s Guide: Starting Up a Database
• Oracle Database Reference: DB_RECOVERY_FILE_DEST_SIZE

まとめ

ORA-01034: ORACLE not available の要点を再整理します。

エラーの本質

Oracle インスタンスが使えない
→ 未起動 or 設定違い（SID/HOME）or アクセス経路問題
→ 本番停止のリスク
→ 緊急対応が必要

併発エラーで原因特定

緊急対応の5ステップ

# STEP 1: プロセス確認
ps -ef | grep pmon

# STEP 2: 環境変数確認
echo $ORACLE_SID
echo $ORACLE_HOME

# STEP 3: リスナー確認
lsnrctl status

# STEP 4: 起動試行
sqlplus / as sysdba
SQL> STARTUP

# STEP 5: alert log 確認（起動失敗時）
tail -100 alert_<sid>.log

10大原因

6つの解決策

-- ① STARTUP
SQL> STARTUP;

-- ② ORACLE_SID 設定
export ORACLE_SID=ORCL

-- ③ リスナー起動
lsnrctl start

-- ④ FRA 拡張
ALTER SYSTEM SET db_recovery_file_dest_size = 500G;

-- ⑤ Windows サービス起動
net start OracleServiceORCL

-- ⑥ alert log 確認
tail -100 alert_<sid>.log

診断コマンド Top 5

# ① プロセス確認
ps -ef | grep pmon

# ② インスタンス状態
sqlplus / as sysdba
SQL> SELECT status FROM v$instance;

# ③ リスナー状態
lsnrctl status

# ④ alert log
tail -f alert_<sid>.log

# ⑤ FRA 使用状況
SELECT * FROM v$recovery_file_dest;

Windows vs Linux

Linux:   ORACLE_SID 大文字小文字区別
         ps -ef | grep pmon
         systemctl / init.d

Windows: 大文字小文字区別なし
         tasklist | findstr oracle
         services.msc / net start

予防のポイント

1. 監視ツールで pmon プロセス監視
2. FRA 使用率 80% 超でアラート
3. alert log 定期チェック
4. 自動起動設定（systemd / services.msc）
5. RAC でノード冗長化
6. バックアップとリカバリテスト
7. アプリで再接続ロジック実装
8. Docker/Kubernetes で auto-restart
9. Rails/Java で健全性チェック
10. crontab で定期状態確認

これらの知識は、Oracle DBA の本番運用・障害対応・DR 計画・Rails / Java / Python アプリ運用・監視設計・Kamal デプロイ・E-Business Suite 管理・Autonomous DB 管理など、あらゆる場面で活用できます。本記事をブックマークしておけば、ORA-01034 に出会っても冷静に的確に対処できるようになります。

本記事は2026年6月時点の情報をもとに、Oracle Database 19c〜23ai での動作確認・公式ドキュメントに基づき作成しています。Oracle のバージョンにより挙動が異なる場合があるため、最新の情報は Oracle 公式ドキュメント（docs.oracle.com）もあわせてご確認ください。