Archivo de la etiqueta: system

Acceder como SYSDBA a SQLPLUS sin conocer el password

De entrada esta “pretensión” de querer entrar a sqlplus sin conocer el password del usuario “SYS” puede ser una pretensión un tanto ambiciosa, pero que como podréis comprobar es más necesario de lo habitual y no es tan difícil.

En ocasiones, si eres un DBA de esos a los que tu empresa te manda cada dos por tres a clientes diferentes donde han pasado diferentes DBA´s y te encuentras que cuando llegas al cliente, ni el mismo cliente conoce los passwords ni de SYS ni de SYSTEM. Pero almenos se tiene acceso al servidor con cuentas de usuario de sistema operativo, si es la de oracle, ya tenemos mucho ganado, sino con root nos bastaría, o incluso, simplemente con poder acceder a una cuenta de usuario que nos permita crear usuarios y asignarle el grupo que deseamos, ya tendríamos solucionado el problema de no conocer el password de SYS o SYSTEM.

Os pongo en situación:

No conocemos el password de SYS ni de SYSTEM. Pero tenemos que realizar tareas de administración.

Nos tenemos que plantear lo siguiente…

- ¿ Tenemos acceso al servidor con un usuario de sistema operativo ? ¿ cúal ?
- ¿ Tenemos acceso al servidor con el usuario de sistema operativo oracle ?
- ¿ Tenemos acceso al servidor con  el usuario root ?

Pues si tenemos acceso con “root” al sistema operativo es fácil. Si hacemos el “su” al usuario oracle ya podremos acceder al servidor de base de datos de dos maneras diferentes con perfil de DBA.

# su – oracle
$ whoami
oracle

– Ahora entramos a sqlplus: forma 1
$ sqlplus “/as sysdba”
$ show user
SQL> show user
USER is “SYS”
SQL>

– O  entramos a sqlplus: forma 2
$ sqlplus /nolog
$ show user
SQL> show user
USER is “”
SQL> connect /as sysdba
SQL> show user
USER is “SYS”

Si tenemos acceso con el usario “oracle”, pues simplemente ejecutar cualquiera de las formas anteriores del ejemplo.

Y sino tenemos acceso con “root” pero tenemos acceso con un usuario que tenga permisos para crear usuarios y cambiar el grupo. Lo que deberíamos hacer es crearnos un usuario con cualquier nombre y asignarlo al grupo “dba”, configuraríamos el .profile (.bash_profile) del usuario el entorno Oracle (Path, ORACLE_HOME, ORACLE_SID, etc…) y entraríamos posteriormente con ese usuario al S.O y luego a sqlplus como lo hemos hecho en cualquiera de los dos ejemplos anteriores.

Para hacer lo comentado anteriormente, primero crearemos el usuario:

# useradd usuario_dba -m -g dba
# passwd usuario_dba
Introduciremos el password.

Ahora configuraremos el entorno Oracle para este usuario. Para ello es necesario conocer algunas de las variables de entorno imprescindibles que tendremos en un “.profile” del usuario “oracle”. Este profile nos sirve de ejemplo y lo tendremos que adaptar al entorno que queremos administrar, es decir, cambiar el ORACLE_HOME y el ORACLE_SID  y adecuarlo al entorno que vamos a administrar.

Ejemplo de .bash_profile en Linux RedHat válido para el entorno Oracle:

#vi  .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

export PATH

ORACLE_HOME=/u/oracle/11.2.0/ORCL
export ORACLE_HOME

PATH=$PATH:$ORACLE_HOME/bin:$ORACLE_HOME/OPatch
export PATH

ORACLE_SID=ORCL
export ORACLE_SID

LD_LIBRARY_PATH=/usr/lib64:$ORACLE_HOME/lib
export LD_LIBRARY_PATH

ORACLE_UNQNAME=ORCL
export ORACLE_UNQNAME

Las líneas anteriores adaptadas al servidor en concreto que queramos administrar serán las que deberemos añadir en nuestro “profile” del usuario que hayamos creado.

Una vez hecho esto, ya podemos salir y volver a entrar con el usuario para cargar el profile y ejecutar sqlplus como en los primeros ejemplos. Finalmente, comentar que si quisíeramos cambiar una vez conectados a sqlplus, por ejemplo, el password del usuario SYSTEM, lo podríamos hacer sin ningún problema ejecutando:

SQL> alter user SYSTEM identified by “<nuevo password>”;

¿ No es tan complicado verdad ?

Restaurar datafile SYSTEM en base de datos ORACLE NOARCHIVELOG

Estando en un cliente me encontré con la siguiente situación:

En un sistema Unix HP-UX y una base datos Oracle 10g (10.2.0.4.0) el fichero system01.dbf se encuentra dañado. Al intentar arrancar la base de datos nos sale el siguiente error (ORA-01113):

Ante esta situación y sabiendo, según me informó el cliente de que la Base de datos estaba en modo NOARCHIVELOG, probablemente no me quedaría más remedio que tirar de Backup y asumir pérdida de datos. En resumen, me dicen que recupere esta base de datos, pero que no se sabe desde cuando tienen el último backup y que además, da el error anterior.

“Importante marronazo”, aunque hay que decir, que por suerte era un entorno Pre-productivo y que por tanto, tampoco pasaba nada si no se resolvía sin recurrir al backup.

Pero me ha parecido interesante abrir esta entrada de Blog, ya que gracias a esta incidencia prové una serie de cosas para intentar restaurar la Base de datos, hecho que conseguí despues de unos intentos fallidos que me hicieron descubrir en que estado se encontraba realmente la Base de datos.

 Volviendo con el tema. Me encuentro con el error mencionado y miro de restaurar teniendo en cuenta que la Base de datos estaba en modo NOARCHIVELOG (informado por el cliente). Como se trata del tablespace SYSTEM intento restaurar la Base de datos usando “backup controlfile until cancel” y como no tengo “archivers” en lugar de especificar la ruta del primer Archiver, especifico la ruta y el nombre de los logfiles.

Antes de todo me conecto como sysdba y arranco y monto la instancia:

$ sqlplus /nolog
SQL> connect /as sysdba

Para saber que logfiles tengo en la Base de datos ejecuto la siguiente consulta:

SQL> select member from v$logfile;

Con el resultado obtenido intento recuperar el datafile, pero ejecutando la siguiente sentencia que no es la que se usa para recuperar un datafile, sino que se usa para restaurarar el controlfile guardado en el último backup:

SQL> recover database using backup controlfile until cancel;

Y cuando nos solicita el fichero de recuperación de archiver, introducimos en su lugar el de logfile. En definitiva se hizo esto:

Según el mensaje parecía que todo había ido bien. Por tanto se intenta arrancar usando la opción “open resetlogs”.  ¿ Porqué usé Open Resetlogs ?

La opción “resetlogs” se suele usar cuando se dan estas dos situaciones:

O bien, en la recuperación se ha partido de un backup del controlfile y no del controlfile actual. Por tanto, el controlfile no tiene la última información sobre los archivelogs generados y la base de datos no puede saber hasta que archivelog se debe aplicar. O el segundo caso, no se ha recuperado hasta la última transacción, ya sea porque no hemos querido (RECOVER UNTIL) o bien porque faltaban archivelogs (hecho que se daba en este caso porque la base estaba en modo NOARCHIVELOG) y no se han podido recuperar hasta el final.

 ¿ Que implica abrir con resetlogs ?

A efectos de Backup podemos decir que la Base de datos es distinta, por tanto, se debería realizar un backup después de usar esta opción. Ya que técnicamente la ”nueva” base de datos está sin backup. Y si la base de datos estuviese en modo ARCHIVELOG, si se tuviese que restaurar no podríamos usar los backupsets de antes y después del resetlogs ya que tenemos una discontinuidad en el backup.

Después de ejecutar resetlogs, salta la alarma y me hace tomar otro camino. He aquí el error …

Este error se produce cuando Oracle realiza un seguimiento de la pila. Y nos advierte de que algún error producido anteriormente será probablemente la causa de este fallo. Cosa que me hace sospechar de que probablemente o bien la base de datos, no está realmente en modo NOARCHIVELOG o bien al restaurar con USING BACKUP CONTROLFILE el controlfile que existía en el backup estaba configurado en modo ARCHIVELOG.

Pues pasé a comprobarlo:

SQL> select  archiver from v$instance;
ARCHIVE
——-
STARTED

o  también

SQL> archive log list;
Modo log de la base de datos Modo de Archivado
Archivado automático Activado
Destino del archivo USE_DB_RECOVERY_FILE_DEST
Secuencia de log en línea más antigua 15
Secuencia de log actual 17

Efectivamente, la Base de datos estaba en modo ARCHIVELOG. Pues este hecho me hizo tomar otro camino en la recuperación y ejecuté las siguientes instrucciones para intentar recuperarla. (Hay que tener en cuenta, que cómo probablemente la base de datos estubo en algún momento configurada en modo archivelog, hecho que lo demuestra al restaurarla con using backup controlfile me hizo pensar, que probablemente se podría restaurar datafile a datafile y luego abriendo de manera normal).

 SOLUCIÓN:

Decido recuperarla datafile a datafile:

Pero para ello necesito saber que número corresponde a cada datafile:

$ sqlplus  /nolog
SQL> connect /as sysdba
SQL> shutdown immediate;
SQL> startup force mount;
SQL> desc v$datafile;

select name, file#, status, enabled from v$datafile
/

NAME
——————————————————————————–
FILE# STATUS  ENABLED
———- ——- ———-
/oracle/oradata/system01.dbf
1 SYSTEM  DISABLED
/oracle/oradata/undotbs01.dbf
2 ONLINE  DISABLED
/oracle/oradata/sysaux01.dbf
3 ONLINE  DISABLED

Empiezo con el de system que es el que estaba erróneo …

SQL> recover datafile 1;
Recuperación del medio físico terminada.

Intento abrir la Base de datos …
SQL> alter database open;
 alter database open
*
ERROR en línea 1:
ORA-01113: el archivo 2 necesita recuperación del medio físico
ORA-01110: archivo de datos 2: ‘/oracle/oradata/undotbs01.dbf’

Nos da error y nos pide que lo hagamos en más ficheros…. Pues procedo a hacerlo en todos los que nos solicita.

 SQL> recover datafile 2;
Recuperación del medio físico terminada.

SQL> alter database open;
Base de datos modificada.

Para la base de datos de manera abort para que no realice rollback de ninguna transacción pendiente.

SQL> shutdown abort;
Instancia ORACLE cerrada.

Intento arrancarla ..
SQL> startup
Instancia ORACLE iniciada.
Total System Global Area 2147483648 bytes
Fixed Size                  2070624 bytes
Variable Size             973080480 bytes
Database Buffers         1157627904 bytes
Redo Buffers               14704640 bytes

Base de datos montada.
ORA-16038: no se puede archivar el log 1 secuencia número 1
ORA-19809: se ha excedido el límite para los archivos de recuperación
ORA-00312: log online 1 thread 1: ‘/oracle/oradata/redo01a.log

Este error ya me gusta más, porque lo da en los ficheros redo y los podremos rehacer… Continuo con …
SQL> alter database open resetlogs;

Ahora cambio a modo NOARCHIVELOG ..

SQL> alter database noarchivelog;
Base de datos modificada.

SQL> alter database open;
Base de datos modificada.

SQL> archive log list;
Modo log de la base de datos              Modo de No Archivado
Archivado automático             Desactivado
Destino del archivo            USE_DB_RECOVERY_FILE_DEST
Secuencia de log en línea más antigua     2
Secuencia de log actual           4

SQL> alter system switch logfile;
Sistema modificado.

SQL> shutdown immediate;
Base de datos cerrada.
Base de datos desmontada.
Instancia ORACLE cerrada.

SQL> startup
Instancia ORACLE iniciada.
Total System Global Area 2147483648 bytes
Fixed Size                  2070624 bytes
Variable Size             973080480 bytes
Database Buffers         1157627904 bytes
Redo Buffers               14704640 bytes
Base de datos montada.
Base de datos abierta.
SQL>

Resultado: Base de datos recuperada. Pero con pérdida de datos. Pero no nos importa, porque era una Base de datos de pre-producción. Ahora se tendría que hacer un backup e importar datos de producción.