ORA-01034: ORACLE not available – fix from quick to deep

Before you start – what ORA-01034 actually means

ORA-01034 means the Oracle instance you're trying to connect to is not currently running. It could be down for maintenance, never started after a reboot, or you're specifying the wrong SID. The error almost always looks like this:

ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist

If you see that second error, your listener might be up but the instance itself is dead. Let's work through this step by step. Stop when your connection works.

30-second fix – Check if the instance is just not started

This is the most common cause. You're connecting to a database that's installed but not started.

1. Open a command prompt or terminal as the Oracle user (typically oracle on Linux, or Administrator on Windows).
2. Set the environment variable ORACLE_SID to your database SID. On Linux:

export ORACLE_SID=ORCL

On Windows:

set ORACLE_SID=ORCL

Replace ORCL with your actual SID. If you don't know your SID, check the ORACLE_SID in the listener.ora file, or ask your DBA.

3. Connect as SYSDBA:

sqlplus / as sysdba

If that returns ORA-01034 again, move to the next step.

4. If you got a SQL prompt, check status:

SQL> select status from v$instance;

If status is STARTED or MOUNTED, the instance isn't open. Start it:

SQL> startup

That's it. Wait a few seconds, then try your connection again. This works for maybe 1 in 3 cases.

5-minute fix – Listener and SID mismatch

If startup worked but your client still gets ORA-01034, the listener probably isn't registered with the instance. Or the listener isn't running.

Step 1 – Check the listener

lsnrctl status

If it says No listener, start it:

lsnrctl start

On Linux, Oracle's listener usually starts via systemctl or a script. I've seen cases where the listener binary is there but the service is disabled after an OS patch. Check:

systemctl status listener  # or whatever your service is named

Step 2 – Verify the instance is registered

Run lsnrctl services. You should see your SID listed with a status like READY or BLOCKED. If you don't see it, the instance's LOCAL_LISTENER parameter might not point to the right listener. But the simpler fix: restart the instance with the listener already running. That forces registration.

SQL> shutdown immediate
SQL> startup

Step 3 – Check your connection string

If you're using a TNS alias, make sure the SID or SERVICE_NAME in tnsnames.ora matches the instance you started. A common mistake: the alias points to SID=ORCL but you started the instance under SID=ORCL1. Verify with:

SQL> select instance_name from v$instance;

Then edit your tnsnames.ora to match.

This fix covers another 30% of cases.

15+ minute fix – Deep diagnostics and recovery

If you're still stuck, something deeper is wrong. The instance might have crashed, the alert log may show corruption, or the parameter file is missing.

Step 1 – Read the alert log

The alert log tells you exactly why the instance died. On Linux, it's usually:

$ORACLE_BASE/diag/rdbms/{db_unique_name}/{SID}/trace/alert_{SID}.log

On Windows, same path inside ORACLE_BASE. Look for the last few lines before the crash. Common culprits:

• ORA-00600 – internal error, call Oracle support
• ORA-01157 – data file missing or corrupt
• ORA-00312 – online log file missing
• Out of memory – OS killed the instance (check dmesg on Linux)

Step 2 – Check the parameter file

If startup fails with ORA-01034 even with sqlplus / as sysdba, the instance can't find its spfile or init.ora. Try starting with a minimal init file:

SQL> startup pfile='/tmp/init.ora'

Create a simple init.ora with just:

db_name=ORCL

If that works, your original spfile is corrupt or missing. Rebuild it from the alert log's backup (see *.ora files in $ORACLE_HOME/dbs).

Step 3 – Memory and shared memory issues

On Linux, ORA-27101 alongside ORA-01034 often means the shared memory segments are gone. Check with ipcs -m. If you see segments owned by oracle, remove them:

ipcrm -m [shmid]

Then try startup again. On Windows, reboot the machine – yes, I'm serious. Oracle on Windows sometimes doesn't clean up shared memory properly.

Step 4 – ORACLE_HOME mismatch

If you have multiple Oracle homes, make sure ORACLE_HOME points to the installation that owns this database. Check with:

echo $ORACLE_HOME

Then confirm the database files are under that home. A mismatch causes startup to fail silently.

Step 5 – Last resort: rebuild from backup

If none of the above works, you're looking at a corrupted control file or missing datafiles. You'll need to restore from backup. That's beyond this article's scope, but the key thing: don't panic. Oracle keeps multiple copies of control files. Check your control_files parameter (if you can start in nomount mode) and see if any of those paths exist. If one is missing, copy another over it.

SQL> startup nomount
SQL> show parameter control_files

Then copy a surviving control file to replace the missing one.

Quick reference table

That's the full flow. Most of the time you'll be done in under a minute. If not, the logs are your friend. Don't guess – read them.