Close Menu
Oracle

ORA-12547 — TNS:lost contact When Connecting with sqlplus

HenriqueBy 6 Mins Read

This post is also available in: Português (Portuguese (Brazil))

When attempting a local connection with sqlplus / as sysdba, Oracle drops the connection before authentication completes:

$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Sat Dec 2 01:54:17 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

ERROR:
ORA-12547: TNS:lost contact


Enter user-name: ^C

The impact is immediate: you lose local access to the database. Without a sysdba session, startup, shutdown, and any emergency administrative operation become unavailable.

Why It Happens

ORA-12547 on a local (/) connection means the Oracle process started — or tried to start — but the IPC communication (bequeath pipe) failed immediately. The most common causes are:

  • ORACLE_HOME pointing to an incorrect path (trailing slash, nonexistent directory, or stale environment variable)
  • Wrong permissions on the $ORACLE_HOME/bin/oracle binary

Oracle cannot locate or execute the binary properly, and TNS interprets that as “lost contact.”

Quick Diagnosis

Before applying any fix, identify the root cause by checking the ORACLE_HOME the running process is actually using and the binary permissions:

ps -ef | grep pmon
oracle   42456     1  0 Dec01 ?        00:00:01 asm_pmon_+ASM
oracle   51812     1  0 02:35 ?        00:00:00 ora_pmon_scprbr07
oracle   55320 43687  0 02:42 pts/0    00:00:00 grep --color=auto pmon

xargs -0 -L1 -a /proc/51812/environ | grep ORACLE_HOME
ORACLE_HOME=/u01/app/oracle/product/19.3.0.0/dbhome_1/
ls -l $ORACLE_HOME/bin/oracle
-rwxr-xr-x 1 oracle oinstall 441253104 Dec 2 02:03 oracle

If ORACLE_HOME ends with / or points to a nonexistent directory, go to Solution 1 or 2. If the binary permissions are not -rwsr-s--x, go to Solution 3.

Solution 1 — Trailing Slash in /etc/oratab

An extra / at the end of the ORACLE_HOME path in /etc/oratab causes oraenv to build the variable with a duplicated separator, breaking binary resolution.

Check:

cat /etc/oratab
+ASM:/u01/app/19.0.0.0/grid:N
scprbr07:/u01/app/oracle/product/19.3.0.0/dbhome_1/:N

Fix by removing the trailing /, reload the environment, and test:

. oraenv
ORACLE_SID = [scprbr07] ? scprbr07
The Oracle base remains unchanged with value /u01/app/oracle

sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Sat Dec 2 02:06:33 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

SQL>

If the database is registered with srvctl (RAC or Grid Infrastructure environments), srvctl maintains its own ORACLE_HOME record — fix it there as well:

srvctl config database -d scprbr07
Database unique name: scprbr07
Database name:
Oracle home: /u01/app/oracle/product/19.3.0.0/dbhome_1/
Oracle user: oracle
Spfile: +DATA/SCPRBR07/PARAMETERFILE/spfile.257.1145122115
Password file: +DATA/SCPRBR07/PASSWORD/pwdscprbr07.278.1088971723
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Disk Groups: DATA
Services: scprbr07_serv
OSDBA group:
OSOPER group:
Database instance: scprbr07
srvctl modify database -d scprbr07 -o /u01/app/oracle/product/19.3.0.0/dbhome_1

After updating srvctl, perform a stop/start of the database so it picks up the correct ORACLE_HOME.

Solution 2 — Stale ORACLE_HOME in Shell Environment

/etc/oratab may be correct, but ORACLE_HOME defined in .bash_profile or .bashrc might point to a directory that no longer exists — common after patches that relocate the Oracle Home.

Check:

echo $ORACLE_HOME
/u01/app/oracle/product/19.3.0.0/dbhome_NONEXISTENT

ls -d $ORACLE_HOME
ls: cannot access '/u01/app/oracle/product/19.3.0.0/dbhome_NONEXISTENT': No such file or directory

Fix .bash_profile with the correct Oracle Home path, or use oraenv to set it correctly:

. oraenv
ORACLE_SID = [scprbr07] ? scprbr07
The Oracle base remains unchanged with value /u01/app/oracle

Confirm the correct path by locating the installed Oracle binary:

find /u01 -name "oracle" -type f -perm /u+x 2>/dev/null
/u01/app/oracle/product/19.3.0.0/dbhome_1/bin/oracle

Solution 3 — Incorrect Permissions on the oracle Binary

⚠️ Warning: the command below changes permissions on a critical Oracle binary. Run it as root or with sudo. In RAC environments, apply on all nodes.

The $ORACLE_HOME/bin/oracle binary requires setuid and setgid bits (6751) so Oracle can escalate privileges internally. If those permissions were removed through OS hardening, a bad deployment, or reinstallation, local connections will fail with ORA-12547.

Check:

ls -l $ORACLE_HOME/bin/oracle
-rwxr-xr-x 1 oracle oinstall 441253104 Dec 2 02:03 oracle

Fix and confirm:

chmod 6751 $ORACLE_HOME/bin/oracle

ls -l $ORACLE_HOME/bin/oracle
-rwsr-s--x 1 oracle oinstall 441253104 Dec 2 02:03 oracle

Test the connection:

sqlplus / as sysdba

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

SQL>

Quick Checklist

ps -ef | grep pmon | grep -v grep
xargs -0 -L1 -a /proc/<PID>/environ | grep ORACLE_HOME

cat /etc/oratab | grep -v "^#"

ls -d $ORACLE_HOME

ls -l $ORACLE_HOME/bin/oracle

chmod 6751 $ORACLE_HOME/bin/oracle

. oraenv
sqlplus / as sysdba

Known Issues

ORA-12547 persists after fixing oratab in a RAC environment srvctl maintains its own ORACLE_HOME record. Fix it with srvctl modify database -d -o and perform a stop/start of the database.

chmod 6751 fails with “Operation not permitted” The command must be run as root. On systems with SELinux or OS hardening policies, additional adjustments may be required before changing setuid permissions.

References

Share.

Related Posts

Add A Comment
Leave A Reply