A veces queremos conectarnos a una instancia Oracle, y lo hacemos , como no, con el usuario más poderoso que existe, con SYS como SYSDBA, pero ni eso resulta y simplemente no podemos conectarnos 
Pues bien , para esos momentos de desdicha, podemos hacer dos cosas
O reiniciar la instancia
O buscar los porque..
Y como somos DBA de peso, queremos saber el por que, cierto?? 
Pues bien, para realizar esa gran tarea de análisis, ocupamos un comando no documentado de Sql*Plus llamado la conección preliminar, con lo cual no nos conectamos a la instancia Oracle, pero… tenemos acceso a muchas vistas del diccionario de datos 
, así tal cual , realizamos una conección pero sin conectarnos
Acá va el ejemplo de ello
Seteamos la opción oculta llamada “Conexión preliminar”
[oracle@oracle10g oracle]$ sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 – Production on Vie Ago 28 04:20:56 2009
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
SQL> set _prelim on
Posterior a eso, realizamos la conexión a la base de datos, pero esto en realidad no realizará la conexión , de hecho si tratará de hacerlo se quedaría pegada.
SQL> conn / as sysdba
Prelim connection established
Si quisieramos ejecutar alguna consulta , aparecería el siguiente mensaje
SQL> select file_name from dba_data_files;
select file_name from dba_data_files
*
ERROR at line 1:
ORA-01012: not logged on
SQL>
Y esto es porque en realidad, no hemos hecho la conexión, pero si podemos obtener información estadística, por ejemplo para hacer un trace de la sesión y así poder detectar el error.
Para realizar el comentado trace, podemos ocupar otro utilitario no documentado parece cuento , este utilitario es el oradebug , para ello ocupamos los siguientes comandos.
SQL>
SQL> oradebug setmypid
Statement processed.
SQL> oradebug unlimit
Statement processed.
SQL> oradebug hanganalyze 3
Hang Analysis in /u01/app/oracle/admin/orcl/udump/orcl_ora_5417.trc
Ahora viene la explicación de los comandos utilizados
oradebug setmypid : Es un debug para el actual proceso que ejecuto el comando
oradebug hanganalyze 3 : Este comando sirve para generar un trace por HANG de la base de datos, de acuerdo al nivel que se le ha otorgado
Este nivel puede ser :
1 y 2 : Sólo un análisis de HANG
3 : Nivel 2 más los procesos con HANG
4 : Nivel 3 más un vacíado de información de los bloqueadores
5 : Nivel 4 más un vacíado de todos los procesos involucrados en el HANG
10 : Un volcado de todos los procesos existentes (muy costoso)
Y claro , ahora viene la revisión del archivo de trace generado , la visualización del problema y el reinicio de la instancia Oracle 
El tamaño del archivo de trace esta dado por el parámetro MAX_DUMP_FILE_SIZE , pero si queremos un tamaño mayor , ejecutamos el comando
SQL> oradebug unlimit
Antes de hacer el debug del trace.
Según el ministro de Comunicaciones de Brasil, Hélio Costa, Argentina habría optado por la norma japonesa-brasileña (
