Descubrir que Query hace mas Rollback

La manera mas rápida para descubrir la query que está generando demasiado Rollback podría ser:

1.- Buscamos las sesiones que estan generando mucho Rollback, usa la siguiente query:

col sid format 9999999

select t.*,n.NAMEfrom v$sesstat t,V$STATNAME n
where t.STATISTIC# = 5 --Donde 5 corresponde al # de estadistica de los rollbacks
and t.STATISTIC# = n.STATISTIC#
and value > 50;

2.- Luego con el SID, se busca el HASH_VALUE, que es el identificador de cada Query dentro del motor de Oracle, para esto usar la siquiente Query:

select s.SQL_HASH_VALUE, s.*
from v$session s
where sid = &SID;

3.- Una vez que encontramos el HASH_VALUE ahora debemos encontrar la query y listo, para esto usamos la siguiente Query:

select *from v$sql s
where s.HASH_VALUE = &HASH_VALUE;

ORA-01092: ORACLE instance terminated. Disconnection forced

Hace poco tuve un inconveniente algo extraño con mi base de datos Oracle 10g. El error se presentó luego de poner a mi base de datos en modo ARCHIVELOG, al pasar del estado MOUNT al OPEN saltó el siguiente error:

ORA-01092 ORACLE instance terminated. Disconnection forced


Intenté quitarle el modo ARCHIVELOG e intentar volver a subir la base, pero esto no funcionó.

Cada que vez que la intentaba subir de cualquier forma me daba el mismo error. Revisando respecto a este error solo encontré que puede suceder por una bajada no limpia de la base (por ejemplo un SHUTDOWN ABORT) y que la solución es esperar un tiempo e intentar volver a subir la base, pero inclusive re-inicié el equipo donde reside la base y esto no funcionó. Al consultar el alert_log para tener algún tipo de información adicional encontré el siguiente error:

ORA-30012: undo tablespace ‘UNDOTBS1′ does not exist or of wrong type

Lo cual claramente me indica que existe algún tipo de problema con mi tablespace de UNDO. Entonces, partiendo de esto realicé los siguientes pasos para poder levantar mi base:


1) Subir a la base en estaus NO MOUNT:

SQL> startup nomount;


2) Cambiar el parámetro UNDO_TABLESPACE para que no apunte al TBS de undo con problemas y así permitir que la base sea abierta:

SQL> alter system set UNDO_TABLESPACE=”;

3) Subir a la base de datos:

SQL> alter database mount;SQL> alter database open;


4) Con la base abierta creamos un nuevo tablespace de UNDO:

SQL> create undo tablespace UNDOTBS2 datafile ‘/home/oracle/admin/oradata/db10g/datafiles /undotbs2.dbf’ size 200M autoextend on maxsize 1024M;


5)Modificamos nuevamente al parámetro UNDO_TABLESPACE para que apunte al nuevo tablespace de UNDO (luego de esto podemos borrar al tablespace que estaba dando problemas):

SQL> alter system set UNDO_TABLESPACE=’UNDOTBS2′;SQL> drop tablespace UNDOTBS1 including contents and datafiles;

6)Bajamos limpiamente la base y la volvemos a subir:

SQL> shutdown immediate;SQL> startup;

Y listo!! Con esto la base de datos se encuentra arriba nuevamente. Luego logré ponerla a trabajar en modo ARCHIVELOG sin problemas.

Cambio de password del usuario "oc4jadmin" del iasR3.

Para modificar las claves del usuario "oc4jadmin", hay que actualizar las lineas de los archivos system-jazn-data.xml de los contedores, antes hacer una copia de los viejos por las dudas.

El archivo "system-jazn-data.xml" se encuentra en el directorio config del contenedor correspondiente ($ORACLE_HOME/j2ee/home/config/system-jazn-data.xml).

Pasos:
1- Bajar los contenedores a modificar.

2- En las lineas del usuario "oc4jadmin" del archivo system-jazn-data.xml:
{903}z0jYUSxW3jZeOyMHUHr7whDJoPni2XXu
modificarlas, por:
!oc4jadmin_password.

Donde oc4jadmin_password es la nueva clave del usuario, en la versión IasR3 debe ser la misma para todas las instancias, si se utiliza oc4jadminpara adminstrar todas las instancias.

3- Subir el contenedor modificado. Y probar loguearse para encriptar el dato en el archivo.