¿Oracle 10g no quiere iniciar?

¿Tenemos problemas?

El otro dia intentando iniciar mi base de datos de prueba, una base hecha en Oracle XE 10g, se me aparecio el siguiente problema:

sqlplus SYS/SYS@XE AS SYSDBA
ERROR:
ORA-12514: TNS:listener does not currently know of service requested in
connect descriptor

La búsqueda del error

Asi que supuse que había algun problema grave con la base de datos, ejecuto el paso siguiente:

sqlplus /nolog
SQL> conn sys/lemoss as sysdba
Connected to an idle instance.

Aparentemente la base de datos no inicio correctamente... vamos a probar levantarla:

SQL> startup
ORACLE instance started.
Total System Global Area  289406976 bytes
Fixed Size                  1248600 bytes
Variable Size              92275368 bytes
Database Buffers          192937984 bytes
Redo Buffers                2945024 bytes
ORA-00204: error in reading (block 3, # blocks 8 ) of control file
ORA-00202: control file: 'C:ORACLEPRODUCT10.2.0ORADATAXECONTROL01.CTL'
ORA-27091: unable to queue I/O
ORA-27070: async read/write failed
OSD-04006: ReadFile() failure, unable to read from file
O/S-Error: (OS 23) Data error (cyclic redundancy check).

Las siguientes pruebas nos confirman que no se pudo abrir la base de datos, presenten atención a la consulta de la tabla "dual":

SQL> SELECT * FROM dual;
ADDR           INDX    INST_ID D
-------- ---------- ---------- -
0366CD54          0          1 X
 
SQL> SELECT * FROM sys.v$parameter;
SELECT * FROM sys.v$parameter
ERROR AT line 1:
ORA-01219: database NOT OPEN: queries allowed ON fixed tables/views only

Posible solución:

Si este es su caso quiere decir que hay corrupcion de datos a nivel filesystem :-(. Lo mejor sería recuperar desde un backup anterior, pero como en este caso no tengo backup, porque se trata de mi PC de pruebas... intentamos renombrar el control file dañado con el siguiente control file:

cd C:ORACLEPRODUCT10.2.0ORADATAXE
rename CONTROL01.CTL CONTROL01.CTL.BAK
copy  CONTROL02.CTL CONTROL01.CTL
1 file(s) copied.

Ahora probamos levantar la base de datos a ver que pasa:

sqlplus /nolog
SQL> conn sys/lemoss AS SYSDBA
Connected.
SQL> ALTER database mount;
Database altered.
SQL> ALTER database OPEN;
Database altered.

Comprobación final:

Ahora volvemos a ejecutar las pruebas anteriores y vemos que resultaron exitosas:

SQL> SELECT * FROM dual;
D
-
X
SQL> SELECT name FROM sys.v$parameter;
NAME
--------------------------------------------------------------------------------
tracefile_identifie

Bueno, con eso deberia andarles para levantar la base de datos y revisar si hubo algun otro dańo de datos, pueden revisar el "alert_xe.log" en busca de más errores.

En mi caso no tuve mas errores así que ahora puedo seguir probando y desarrollando tranquilo! :)