Exchange Partition

Exchange Partition permite cargar en tablas particionadas datos en forma rápida y con muy poco impacto para los usuarios que se encuentran activos.
En resumen, lo que hace la sentencia Exchange Partition es modificar el diccionario de datos y simular que los datos que ya tenemos cargados en una tabla, corresponden a una partición determinada de otra tabla.

Veamos un ejemplo muy sencillo para entender mejor éste tema:

SQL_10gR2> CREATE TABLE datos_1 AS
  2  SELECT level id, timestamp'2000-11-02 09:00:00' fecha
  3  FROM dual
  4  CONNECT BY level <= 100000 ;

Table created.

Elapsed: 00:00:01.06

SQL_10gR2> CREATE TABLE datos_2 AS
  2  SELECT level id, timestamp'2001-09-10 13:00:00' fecha
  3  FROM dual
  4  CONNECT BY level <= 100000 ;

Table created.

Lo que hicimos fue crear 2 tablas con distintas fechas en cada una de ellas.

Ahora creamos solamente la estructura de la tabla particionada en donde vamos a cargar los datos:

SQL_10gR2> CREATE TABLE test
  2  ( id, fecha )
  3  PARTITION BY RANGE ( fecha )
  4  (
  5      PARTITION year_2000 VALUES LESS THAN ( timestamp'2000-12-02 00:00:00' ),
  6      PARTITION year_2001 VALUES LESS THAN ( timestamp'2001-10-10 00:00:00' )
  7  )
  8  AS
  9  SELECT 1, timestamp'2000-11-02 09:00:00'
 10  FROM dual
 11  WHERE 1 = 0 ;

Vamos a realizar un alter para modificar el diccionario de datos y relacionar cada una de las 2 tablas que creamos con la respectiva partición de la tabla TEST...

SQL_10gR2> ALTER TABLE test
  2  EXCHANGE PARTITION year_2000
  3  WITH table datos_1
  4  WITHOUT VALIDATION ;

Table altered.

Elapsed: 00:00:00.03

SQL_10gR2> ALTER TABLE test
  2  EXCHANGE PARTITION year_2001
  3  WITH table datos_2
  4  WITHOUT VALIDATION ;

Table altered.

Elapsed: 00:00:00.02

SQL_10gR2> SELECT count(*)
  2  FROM test ;

  COUNT(*)
----------
    200000

1 row selected.

SQL_10gR2> SELECT count(*)
  2  FROM datos_1 ;

  COUNT(*)
----------
         0

1 row selected.

SQL_10gR2> SELECT count(*)
  2  FROM datos_2 ;

  COUNT(*)
----------
         0

1 row selected.

Como podemos ver, con el Exchange Partition no tardamos casi nada en cargar los datos en la tabla particionada ya que en realidad no estamos cargando los datos, simplemente se modifica el diccionario de datos.

Pueden notar que agregué la sentencia WITHOUT VALIDATION. Que es ésto? WITHOUT VALIDATION suele ser una operación rápida porque sólo realiza modificaciones en el diccionario de datos. Si la tabla o tabla particionada que colocamos en el Exchange Partition tiene una primary key o unique constraint habilitado, entonces el Exchange Partition se realiza como WITH VALIDATION para mantener la integridad de las constraints.

Vamos a ejecutar nuevamente los 2 alter anteriores sin la sentencia WITHOUT VALIDATION...

SQL_10gR2> ALTER TABLE test
  2  EXCHANGE PARTITION year_2000
  3  WITH table datos_1 ;

Table altered.

Elapsed: 00:00:01.00

SQL_10gR2> ALTER TABLE test
  2  EXCHANGE PARTITION year_2001
  3  WITH table datos_2 ;

Table altered.

Elapsed: 00:00:01.05

Si hubiera ejecutado esos alter con un Trace, el reporte del Trace me mostraría, entre otras sentencias, las siguientes...

select 1
from
 "DATOS_1" where TBL$OR$IDX$PART$NUM("TEST", 0, 3,1048576,"FECHA") != :1

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          1          0           0
Fetch        1      0.04       0.04          0         65          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.04       0.04          0         66          0           0

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 81     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  TABLE ACCESS FULL DATOS_1 (cr=65 pr=0 pw=0 time=44582 us)


select 1
from
 "DATOS_2" where TBL$OR$IDX$PART$NUM("TEST", 0, 3,1048576,"FECHA") != :1

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          1          0           0
Fetch        1      0.04       0.04          0         65          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.04       0.04          0         66          0           0

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 81     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  TABLE ACCESS FULL DATOS_2 (cr=65 pr=0 pw=0 time=46957 us)

Antes que nada, notamos que los alter se ejecutaron en mayor tiempo, cierto? De las consultas que observamos del Trace, vemos que se está realizando un FULL SCAN de las tablas y que se está ejecutando una función en el WHERE de cada consulta. Imagínense si tenemos que realizar ésta clase de procesos en ambientes con gran volumen de datos y en donde el sistema se encuentra saturado por el I/O a disco.

Qué sucede si no tenemos los datos separados por año en distintas tablas, y en cambio, tenemos todos los datos en una misma tabla? Bueno, tomando como ejemplo la tabla TEST que acabamos de cargar, podríamos realizar lo siguiente...

SQL_10gR2> CREATE TABLE test_2
  2  ( id, fecha )
  3  PARTITION BY RANGE ( fecha )
  4  (
  5      PARTITION year_2000 VALUES LESS THAN ( timestamp'2000-12-02 00:00:00' ),
  6      PARTITION year_2001 VALUES LESS THAN ( timestamp'2001-10-10 00:00:00' )
  7  )
  8  AS
  9  SELECT *
 10  FROM test ;

Table created.

Elapsed: 00:00:05.04

SQL_10gR2> DROP TABLE test ;

Table dropped.

SQL_10gR2> ALTER TABLE test_2 RENAME TO test ;

Table altered.

SQL_10gR2> SELECT count(*)
  2  FROM test ;

  COUNT(*)
----------
    200000

1 row selected.