¿Intenta conectarse internamente a Oracle, obteniendo una instancia inactiva?

Question

Así que tengo una instancia de Oracle, y sé que se está ejecutando en este sistema, le he preguntado al usuario de Oracle y estoy intentando conectar usando "/ como sysdba". Sin embargo, cuando me conecto, dice que la instancia está inactiva. Sé que la base de datos está abierta y abierta, porque mi aplicación está hablando con ella. Mis rutas (ORACLE_HOME, etc.) pueden ser incorrectas: ¿alguna idea de qué configuración incorrecta podría dar como resultado esto?

% sqlplus "/ as sysdba" 

SQL*Plus: Release 10.2.0.3.0 - Production on Mon Dec 8 09:23:22 2008 

Copyright (c) 1982, 2006, Oracle. All Rights Reserved. 

Connected to an idle instance. 

09:23:22 SQL> Disconnected 

% ps -ef | grep smon 
oracle 6961  1 0 Nov 05 ?   1:24 ora_smon_ORA003 
% 

Answer 1

eso significa que la instancia de la base de datos no está montada ni abierta. Ejecute el comando de inicio y vea si aparece algún error.

Answer 2

La base de datos no puede estar inactiva y en uso por su aplicación al mismo tiempo. Parece que la sesión sqlplus debe estar conectada a una instancia diferente de la aplicación. Trate de especificar el identificador de la conexión en el estado de conexión de la siguiente manera:

sqlplus "/@ConnectIdentifier as sysdba" 

Answer 3

asegurarse de que tiene la configuración de su ORACLE_HOME exactamente el mismo que cuando se inició el servidor, he visto este problema con Oracle en 9.2.0.5.0 Solaris,

ORACLE_HOME=/opt/oracle 
ORACLE_HOME=/opt/oracle/ 

es dos cosas diferentes, y dará lugar a problemas de conexión local.

Answer 4

El caso es significativo en los sistemas * nix, así que asegúrese de que su ORACLE_SID coincida exactamente con el nombre de la instancia. En este caso, ORA003 NO es lo mismo que ora003.

Answer 5

tratan de la consola de la máquina

export ORACLE_SID=your sid here 
sqlplus /nolog 
startup 

Sé que en las ventanas hay un comando para crear un servicio para iniciar una instancia para usted, oradmin -nuevo -sid% SID_ORACLE% -intpwd% oracle_pwd% -startmode A

Answer 6

gracias. de hecho fue esa barra frontal adicional al final en la variable ORACLE_HOME.

En mi caso, vea lo extraño: me conecté al servidor e intenté conectarme, pero obtuve el error anterior. Sabía que esa instancia había terminado y DB se abrió. Así que revisé ORACLE_HOME porque era más o menos consciente de esta posibilidad. Lo que vi fue que ORACLE_HOME estaba bien (es decir, sin barra frontal adicional al final). Luego, después de intentar mucho cuando leí este hilo, me llamó la atención. La base de datos se inició con ORACLE_HOME establecido con esa barra frontal adicional. Así DB se inició con ORACLE_HOME =/u01/app/oracle/product/10.2.0.3/ y todo el tiempo, yo estaba tratando con ORACLE_HOME =/u01/app/oracle/product/10.2.0.3 :(

Gracias de nuevo.

Answer 7

Ok esto es lo que he descubierto acerca ejemplo inactivo que tiene que ver con la spfile .. a veces su init.ora se encuentra en otro lugar

intenta buscar init.ora, una vez que se encontró la ubicación

intente con el código startup spfile="C:\location";

dirá que se inició la instancia.

bien que se trabajó para mí

Answer 8

que tenía el mismo problema. Al eliminar el extra "/" al final de ORACLE_HOME resuelto.

gracias por compartir - habría sido muy difícil de diagnosticar y resolver este problema, en ausencia de este blog.

Answer 9

El problema puede ser si la sesión no se pudo abrir la base de datos debido a extremally ocupado. en este caso, la conexión utilizando cualquier usuario, incluso un maniquí

sqlplus maniquí/maniquí

le daría un problema real, pero no inactivo ejemplo.

Answer 10

Probé sqlplus maniquí/maniquí y me dio el problema real (sin memoria). Hice memoria disponible y pude iniciar sesión sin ningún problema.

Answer 11

tuve misma edición, mientras que especificar SID mal (xe en lugar de XE). Si instala la base de datos con rpm, verifique todo el entorno en /etc/inid.d/oracle

Answer 12

Consulte el blog a continuación. Esencialmente, el problema es lo que una de las otras respuestas afirmó./root/path_to_home es correcto,/root/path_to_home/está incorrectamente analizado por alguna razón.

http://blog.dbvisit.com/whats-going-on-connected-to-an-idle-instance-but-database-is-running/