Como desparticionar una tabla rápidamente

Si se quiere desparticionar una tabla muy grande, en donde sacar un export y volverlo a subir con la estructura de la tabla sin particiones se vuelve un método demasiado lento, podemos utilizar los siguientes pasos para que el proceso se haga mucho más rápido:

Paso 1.- Primero se debe hacer un merge de las particiones existentes en una sola, esto se logra con la siguiente sentencia:


sql> ALTER TABLE tabla_particionada MERGE PARTITIONS part1, (part2,part3) INTO ultima_particion;


Para saber el nombre de las particiones puede utilizar la sentencia que se detalla a continuación:


sql> SELECT PARTITION_NAME FROM USER_TAB_PARTITIONS WHERE TABLE_NAME=tabla_particionada;


Consultar el número de registros existentes actualmente en la tabla para una posterior comprobación. (select count(*) from tabla_particionada)


Paso 2.- Crear la tabla con un nombre temporal (tabla_desparticionada) y sin particiones.


Paso 3.- Pasar los datos de la tabla particionada a la nueva tabla creada sin particiones:


sql> ALTER TABLE tabla_particionada EXCHANGE PARTITION ultima_particion WITH TABLE tabla_desparticionada INCLUDING INDEXES WITHOUT VALIDATION;


Paso4.- Comprobar que la tabla creada sin particiones (tabla_desparticionada) tiene ahora el mismo número de registros que tenía antes la tabla particionada. Esta última debería tener ahora 0 registros como consecuencia de la migración. Si se migraron correctamente los registros, se deberá finalmente borrar la tabla particionada (verificar antes dependencias con otros objetos) y renombrar a la tabla sin particiones con el nombre original.


Paso 5.- Renombrar la tabla:
sql> ALTER TABLE tabla_desparticionada RENAME TO nuevo_nombre;

Cómo recrear un tablespace con datos

En algunas oportunidades nos podemos encontrar con la necesidad de recrear un talespace que ya contiene datos, como por ejemplo cuando queremos cambiar una opción del tablespace , la cual la sentencia “alter tablespace” no nos permite modificar. En estos casos podemos seguir los siguientes pasos para re-crear el tablespace sin perder los datos que contiene el mismo, de una forma sencilla:

Paso 1.- Primero confirmamos el espacio ocupado por el tablespace actualmente:
sql>select sum(bytes)/1024/1024 MB from user_segments where tablespace_name = 'tbsname';

Paso 2.- Exportar los datos existentes en el tablespace que se desea recrear:
# exp system/psswd tablespaces=tbsname compress=n direct=y file=nombre.dmp log=nombre.log;

Paso 3.- Borrar el tablespace, desde el Enterprise Manager o via comandos:
sql> drop tablesapce tbsname including contents and datafiles;

Paso 4.- Recrear el tablespace. En este caso, por ejemplo, se quería cambiar la clausula de “segment space management” de manual a auto. De igual forma se puede re-crear el TBS vía EM o por linea de comandos:
sql> create tablespace tbsname datafile '/…./…dbf' size 20M autoextend on next 2048K maxsize 4000M logging extent management local segment space management auto;

Paso 5.- Importar el tablespace:
# imp system/psswd full=y file=nombre.dmp log=nombre.log tablespaces=tbsname rows=y indexes=y constraints=y commit=y ignore=y grants=n buffer=500000
Y con eso ya tendríamos los datos.

Paso 6.- Finalmente deberíamos comprobar que existe la misma cantidad de información el TBS luego de realizar el import:
sql>select sum(bytes)/1024/1024 MB from user_segments where tablespace_name = 'tbsname';

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.