Hola gente,
Uno de los nuevos features más interesantes que me he encontrado en 12c es el In-Database Archiving(IDA) que les voy a comentar en esta entrada del blog.
La idea del IDA es ayudarnos un poco con el tema del archiving haciendo más simple la administración de la data. Para esto la data es dividida o marcada en "archived" o "active".
Vamos más a fondo, si la data es marcada como "archived" se vuelve invisible para la aplicación y es comprimida.... así o mas genial!!!, si es marcada como "active" nada pasa, es data normal.
Por supuesto vamos al ejemplo:
En nuestra instancia 12C vamos a usar el schema HR para nuestra prueba.
Creamos una tabla a partir de alguna data:
CREATE TABLE hr.empleados_ida_test
AS
SELECT employee_id, first_name, last_name
FROM hr.employees
WHERE employee_id IN (100, 101, 102, 103, 104, 105,
106,107,108,109,110);
Luego por supuesto habilitamos el feature sobre nuestra nueva tabla:
Alter table hr.empleados_ida_test ROW ARCHIVAL;
Cuando habilitamos el feature sobre la tabla, se agregan algunas columnas ocultas que son utilizadas para indicar el estado del row o registro.
Noten que si le damos un describe a la tabla todo sigue normal:
Si vamos a crear la tabla desde cero podemos habilitar el feature desde el inicio:
CREATE TABLE SCHEMA.NOMBRE (COL1 VARCHAR2 (5))
TABLESPACE TBS_TEST
ROW ARCHIVAL;
Revisemos a fondo la tabla usando la vista USER_TAB_COLS o DBA_TAB_COLS:
SELECT TABLE_NAME,
COLUMN_NAME,
COLUMN_ID,
HIDDEN_COLUMN
FROM dba_tab_cols
WHERE OWNER = 'HR' AND table_name = 'EMPLEADOS_IDA_TEST'
ORDER BY 3;
Notamos que aparecen dos bellas columnas ocultas en nuestra tabla: ORA_ARCHIVE_STATE y SYS_NC00004$.
Ahora juguemos con la data:
Consultemos la tabla con un bello y simple:
SELECT * FROM HR.EMPLEADOS_IDA_TEST;
Vemos que nos retorna los 11 registros.
Ahora resulta que queremos ocultar algunos registros dado que no los vamos a considerar en nuestra app por algún tiempo o hasta nuevo aviso, para esto utilizamos el paquete DBMS_ILM.ARCHIVESTATENAME donde le indicamos con el parámetro 0 que el registro es visible o con 1 que es invisible.
UPDATE HR.EMPLEADOS_IDA_TEST
SET ORA_ARCHIVE_STATE = DBMS_ILM.ARCHIVESTATENAME (1)
WHERE EMPLOYEE_ID IN (100,
101,
102,
103);
COMMIT;
Importante considerar que el registro sigue existiendo, lógicamente las operaciones que involucren validaciones contra la primary key siguen realizándose. Simplemente la data esta comprimida y no es visible.
Hagamos de nuevo un query en la tabla:
SELECT * FROM HR.EMPLEADOS_IDA_TEST;
Vemos que nos retorna 7 registros y no 11.
Los 7 registros que nos retorna son aquellos donde la columna ORA_ARCHIVE_STATE es igual a cero (Visible).
Si quisiera ver toda la data puedo indicarle a mi session que use las "gafas de visión de cosas invisibles" de la siguiente manera:
ALTER SESSION SET ROW ARCHIVAL VISIBILITY=ALL;
Para volver a la "visión normal" y poder visualizar únicamente los registros en estado Active le hacemos un alter a la session:
ALTER SESSION SET ROW ARCHIVAL VISIBILITY=ACTIVE;
Recuerden que los registros simplemente se encuentran en un estado Archive, esto no quiere decir que no existan. Las validaciones se siguen realizando sobre los mismos.
Veamos un ejemplo considerando la Pk:
--Agrego un pk a mi tabla:
SQL> ALTER TABLE HR.EMPLEADOS_IDA_TEST
ADD PRIMARY KEY (EMPLOYEE_ID);
--Ingresamos un registro que considere un valor de pk de un registro existente y en estado Archive:
SQL> INSERT INTO HR.EMPLEADOS_IDA_TEST VALUES(101, 'MIGUEL','VEGA');
INSERT INTO HR.EMPLEADOS_IDA_TEST VALUES(101, 'MIGUEL','VEGA')
*
ERROR en linea 1:
ORA-00001: restriccion unica (HR.SYS_C0010036) violada
Y por supuesto la afectación a nivel de explain plan es mínima por no decir nula o casi imperceptible:
Explain plan del query mostrando 11 registros:
Explain plan del query mostrando 7 registros:
Saludos cordiales,
Miguel Vega
