Particionamiento en Oracle: Guía Completa

El particionamiento es una técnica de gestión de datos fundamental en Oracle Database que consiste en dividir tablas e índices grandes en piezas más pequeñas y manejables, llamadas particiones. Desde la perspectiva del usuario, una tabla particionada es idéntica a una tabla no particionada, pero internamente, la base de datos gestiona cada partición como un segmento independiente. Esta capacidad de dividir objetos de base de datos ofrece importantes beneficios en términos de rendimiento, manejabilidad y disponibilidad, especialmente para aplicaciones que gestionan grandes volúmenes de datos.

La decisión de particionar una tabla o un índice se basa generalmente en la forma en que se accede o se gestiona la información. Al particionar, las operaciones que antes afectaban a toda la tabla ahora pueden dirigirse solo a las particiones relevantes, lo que reduce significativamente el volumen de datos procesados y mejora la eficiencia.

¿Qué es el Particionamiento en Oracle?

El particionamiento en Oracle Database permite descomponer un objeto de base de datos (como una tabla o un índice) en partes lógicas más pequeñas. Cada partición tiene su propio nombre y puede tener atributos de almacenamiento distintos. La forma en que se dividen los datos se define mediante una clave de partición, que consiste en una o más columnas de la tabla, y un método de particionamiento.

Los principales objetivos del particionamiento son mejorar:

• Rendimiento: Las consultas que acceden solo a una fracción de los datos pueden ser mucho más rápidas si solo necesitan escanear una o unas pocas particiones en lugar de toda la tabla. Las operaciones DML (INSERT, UPDATE, DELETE) y las operaciones de mantenimiento (como respaldos o reconstrucciones de índices) también pueden ser más rápidas y realizarse en paralelo a nivel de partición.
• Manejabilidad: Las operaciones de mantenimiento, como la carga de datos, la eliminación de datos antiguos, la reconstrucción de índices o la migración de datos, pueden realizarse a nivel de partición, lo que reduce el tiempo de inactividad y el impacto en el resto de la tabla. Por ejemplo, eliminar datos históricos puede ser tan simple como eliminar una partición.
• Disponibilidad: Las operaciones de mantenimiento a nivel de partición, como reconstruir un índice local, se pueden realizar mientras otras particiones del mismo índice permanecen disponibles.

Tipos de Particionamiento en Oracle

Oracle Database soporta varios métodos de particionamiento, cada uno adecuado para diferentes escenarios de uso:

Particionamiento por Rango (Range Partitioning)

El particionamiento por rango asigna filas a particiones basándose en rangos de valores de las columnas de la clave de partición. Este es uno de los métodos más comunes y es ideal para datos con un orden natural, como fechas o rangos numéricos.

Para definir particiones por rango, se especifica la cláusula PARTITION BY RANGE seguida de las columnas de la clave de partición y luego se definen las particiones individuales con la cláusula PARTITION, especificando VALUES LESS THAN (valores menores que) para cada partición. La base de datos coloca una fila en la primera partición cuyo límite superior es mayor que el valor de la clave de partición de la fila.

Ejemplo de creación de una tabla particionada por rango:

CREATE TABLE sales (
 prod_id NUMBER(6),
 cust_id NUMBER,
 time_id DATE,
 channel_id CHAR(1),
 promo_id NUMBER(6),
 quantity_sold NUMBER(3),
 amount_sold NUMBER(10,2)
)
PARTITION BY RANGE (time_id)
(
 PARTITION sales_q1_2006 VALUES LESS THAN (TO_DATE('01-APR-2006','dd-MON-yyyy')) TABLESPACE tsa,
 PARTITION sales_q2_2006 VALUES LESS THAN (TO_DATE('01-JUL-2006','dd-MON-yyyy')) TABLESPACE tsb,
 PARTITION sales_q3_2006 VALUES LESS THAN (TO_DATE('01-OCT-2006','dd-MON-yyyy')) TABLESPACE tsc,
 PARTITION sales_q4_2006 VALUES LESS THAN (TO_DATE('01-JAN-2007','dd-MON-yyyy')) TABLESPACE tsd
);

En este ejemplo, las ventas de cada trimestre de 2006 se almacenan en una partición separada.

Particionamiento por Intervalo (Interval Partitioning)

El particionamiento por intervalo es una extensión del particionamiento por rango. Se define un punto de transición utilizando una partición por rango, y la base de datos crea automáticamente particiones de intervalo para los datos que superan ese punto. La clave de partición debe ser una sola columna de tipo NUMBER o DATE.

Se utiliza la cláusula INTERVAL para especificar el intervalo de tiempo o numérico para las particiones que se crearán automáticamente. Opcionalmente, se puede usar STORE IN para especificar tablespaces para estas particiones.

Ejemplo de creación de una tabla particionada por intervalo:

CREATE TABLE interval_sales (
 prod_id NUMBER(6),
 cust_id NUMBER,
 time_id DATE,
 channel_id CHAR(1),
 promo_id NUMBER(6),
 quantity_sold NUMBER(3),
 amount_sold NUMBER(10,2)
)
PARTITION BY RANGE (time_id) INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
(
 PARTITION p0 VALUES LESS THAN (TO_DATE('1-1-2007', 'DD-MM-YYYY')),
 PARTITION p1 VALUES LESS THAN (TO_DATE('1-1-2008', 'DD-MM-YYYY')),
 PARTITION p2 VALUES LESS THAN (TO_DATE('1-7-2009', 'DD-MM-YYYY')),
 PARTITION p3 VALUES LESS THAN (TO_DATE('1-1-2010', 'DD-MM-YYYY'))
);

Las particiones p0 a p3 son particiones de rango definidas explícitamente. A partir del 1 de enero de 2010 (el límite superior de p3), la base de datos creará automáticamente particiones mensuales a medida que se inserten datos.

Particionamiento por Hash (Hash Partitioning)

El particionamiento por hash distribuye las filas entre un número fijo de particiones basándose en un algoritmo hash aplicado a la clave de partición. Este método es útil para distribuir datos de manera uniforme cuando no hay un rango natural o cuando se desea evitar el sesgo de datos (data skew).

Se utiliza la cláusula PARTITION BY HASH. Se puede especificar el número de particiones con PARTITIONS o nombrarlas individualmente con PARTITION. Solo el tablespace puede variar entre las particiones hash; otros atributos de segmento se heredan del nivel de la tabla.

Ejemplo de creación de una tabla particionada por hash:

CREATE TABLE scubagear (id NUMBER, name VARCHAR2 (60))
PARTITION BY HASH (id)
PARTITIONS 4 STORE IN (gear1, gear2, gear3, gear4);

Aquí, las filas se distribuyen en 4 particiones basándose en el hash de la columna id, almacenadas en diferentes tablespaces.

Particionamiento por Lista (List Partitioning)

El particionamiento por lista asigna filas a particiones basándose en la coincidencia exacta de los valores de la clave de partición con una lista discreta de valores definidos para cada partición. Es útil cuando los datos se agrupan naturalmente por valores específicos (por ejemplo, códigos de región, tipos de producto).

Se utiliza la cláusula PARTITION BY LIST y se definen las particiones con PARTITION ... VALUES, proporcionando una lista de valores literales. Se puede definir una partición DEFAULT para manejar filas cuyos valores de clave de partición no coinciden con ninguna otra lista definida.

Ejemplo de creación de una tabla particionada por lista:

CREATE TABLE q1_sales_by_region (
 deptno number,
 deptname varchar2(20),
 quarterly_sales number(10, 2),
 state varchar2(2)
)
PARTITION BY LIST (state)
(
 PARTITION q1_northwest VALUES ('OR', 'WA'),
 PARTITION q1_southwest VALUES ('AZ', 'UT', 'NM'),
 PARTITION q1_northeast VALUES ('NY', 'VM', 'NJ'),
 PARTITION q1_southeast VALUES ('FL', 'GA'),
 PARTITION q1_northcentral VALUES ('SD', 'WI'),
 PARTITION q1_southcentral VALUES ('OK', 'TX')
);

Las filas se asignan a la partición correspondiente si el valor de la columna state coincide con uno de los valores en la lista de la partición.

Particionamiento por Referencia (Reference Partitioning)

El particionamiento por referencia permite particionar una tabla basándose en una relación de clave foránea con otra tabla particionada (la tabla padre). La tabla hija hereda el esquema de particionamiento de la tabla padre a través de la restricción referencial.

Se utiliza la cláusula PARTITION BY REFERENCE especificando el nombre de la restricción de clave foránea. La restricción debe estar habilitada y activa. El número de particiones de la tabla hija debe coincidir con el número de particiones o subparticiones de la tabla padre. Las particiones hijas no especifican límites de rango/lista/hash; se alinean automáticamente con las particiones padre correspondientes.

Ejemplo de creación de una tabla particionada por referencia (asumiendo que orders ya existe y está particionada):

CREATE TABLE order_items (
 order_id NUMBER(12) NOT NULL,
 line_item_id NUMBER(3) NOT NULL,
 product_id NUMBER(6) NOT NULL,
 unit_price NUMBER(8,2),
 quantity NUMBER(8),
 CONSTRAINT order_items_fk FOREIGN KEY(order_id) REFERENCES orders(order_id)
)
PARTITION BY REFERENCE(order_items_fk);

La tabla order_items se particiona de la misma manera que la tabla orders, basándose en la columna order_id a través de la clave foránea.

Particionamiento Compuesto (Composite Partitioning)

El particionamiento compuesto combina dos métodos de particionamiento: un método de particionamiento de primer nivel (rango, intervalo o lista) y un método de subparticionamiento de segundo nivel (hash o lista). Esto permite una granularidad aún mayor en la división de los datos.

Se utiliza la cláusula PARTITION BY para el primer nivel y SUBPARTITION BY para el segundo nivel.

Ejemplo de particionamiento compuesto (rango-hash):

CREATE TABLE sales (
 prod_id NUMBER(6),
 cust_id NUMBER,
 time_id DATE,
 channel_id CHAR(1),
 promo_id NUMBER(6),
 quantity_sold NUMBER(3),
 amount_sold NUMBER(10,2)
)
PARTITION BY RANGE (time_id) SUBPARTITION BY HASH (cust_id)
(
 PARTITION sales_q1_2006 VALUES LESS THAN (TO_DATE('01-APR-2006','dd-MON-yyyy'))
 (SUBPARTITION sales_q1_2006_s1, SUBPARTITION sales_q1_2006_s2),
 PARTITION sales_q2_2006 VALUES LESS THAN (TO_DATE('01-JUL-2006','dd-MON-yyyy'))
 (SUBPARTITION sales_q2_2006_s1, SUBPARTITION sales_q2_2006_s2)
 ...
);

Las filas se particionan primero por rango según la fecha y luego cada partición de rango se subparticiona por hash según el ID del cliente.

Uso de Plantillas de Subpartición

Las plantillas de subpartición simplifican la definición de subparticiones en tablas compuestas al permitir definir la estructura de subpartición una sola vez. Esta plantilla se aplica a todas las particiones que no tienen una definición de subpartición explícita.

Se utiliza la cláusula SUBPARTITION TEMPLATE. Esto es especialmente útil y la única forma de definir subparticiones para particiones de intervalo en tablas compuestas de intervalo-*.

Ejemplo con plantilla de subpartición (rango-hash):

CREATE TABLE emp_sub_template (
 deptno NUMBER,
 empname VARCHAR(32),
 grade NUMBER
)
PARTITION BY RANGE(deptno) SUBPARTITION BY HASH(empname)
SUBPARTITION TEMPLATE (
 SUBPARTITION a TABLESPACE ts1,
 SUBPARTITION b TABLESPACE ts2,
 SUBPARTITION c TABLESPACE ts3,
 SUBPARTITION d TABLESPACE ts4
)
(
 PARTITION p1 VALUES LESS THAN (1000),
 PARTITION p2 VALUES LESS THAN (2000),
 PARTITION p3 VALUES LESS THAN (MAXVALUE)
);

Cada partición (p1, p2, p3) tendrá cuatro subparticiones (a, b, c, d) según lo define la plantilla, cada una en su tablespace especificado. Los nombres de subpartición se generan concatenando el nombre de la partición y el nombre de la subpartición de la plantilla (ej: P1_A, P1_B, etc.), excepto en particionamiento intervalo-* donde son generados por el sistema (SYS_SUBP n).

Particionamiento Basado en Columnas Virtuales

Una columna virtual (una columna cuyo valor se calcula a partir de la expresión de otras columnas) también puede ser utilizada como clave de partición en Oracle. Todos los métodos de particionamiento (rango, intervalo, hash, lista, referencia) y sus combinaciones compuestas son compatibles con columnas virtuales, siempre que la expresión de la columna virtual no incluya llamadas a funciones PL/SQL.

Ejemplo con columna virtual:

CREATE TABLE sales (
 prod_id NUMBER(6) NOT NULL,
 cust_id NUMBER NOT NULL,
 time_id DATE NOT NULL,
 channel_id CHAR(1) NOT NULL,
 promo_id NUMBER(6) NOT NULL,
 quantity_sold NUMBER(3) NOT NULL,
 amount_sold NUMBER(10,2) NOT NULL,
 total_amount AS (quantity_sold * amount_sold)
)
PARTITION BY RANGE (time_id) INTERVAL (NUMTOYMINTERVAL(1,'MONTH'))
SUBPARTITION BY RANGE(total_amount)
SUBPARTITION TEMPLATE (
 SUBPARTITION p_small VALUES LESS THAN (1000),
 SUBPARTITION p_medium VALUES LESS THAN (5000),
 SUBPARTITION p_large VALUES LESS THAN (10000),
 SUBPARTITION p_extreme VALUES LESS THAN (MAXVALUE)
)
 (PARTITION sales_before_2007 VALUES LESS THAN (TO_DATE('01-JAN-2007','dd-MON-yyyy')))
ENABLE ROW MOVEMENT;

Aquí, la tabla se particiona por fecha (intervalo) y subparticiona por rango según el valor calculado de total_amount.

Cómo Crear una Tabla Particionada

La creación de una tabla particionada es muy similar a la de una tabla no particionada, pero se incluye una cláusula de particionamiento en la sentencia CREATE TABLE. La sintaxis exacta de la cláusula de particionamiento depende del tipo de particionamiento deseado, como se mostró en los ejemplos anteriores.

Además de la definición de particionamiento, es común especificar atributos como TABLESPACE para cada partición o subpartición, permitiendo distribuir los datos en diferentes ubicaciones de almacenamiento. Si no se especifica a nivel de partición, los atributos se heredan del nivel de la tabla.

Movimiento de Filas (ROW MOVEMENT)

Al crear o alterar una tabla particionada, se puede especificar la cláusula ENABLE ROW MOVEMENT o DISABLE ROW MOVEMENT. Esta cláusula controla si una fila puede migrar automáticamente a una nueva partición si una actualización de su clave de partición hace que ya no pertenezca a su partición actual. El valor predeterminado es DISABLE ROW MOVEMENT. Habilitar el movimiento de filas es necesario en escenarios donde las actualizaciones de la clave de partición podrían cambiar la partición de una fila, como en el particionamiento por intervalo o con columnas virtuales mutables.

Ejemplo con ROW MOVEMENT:

CREATE TABLE sales (
 prod_id NUMBER(6),
 cust_id NUMBER,
 time_id DATE,
 channel_id CHAR(1),
 promo_id NUMBER(6),
 quantity_sold NUMBER(3),
 amount_sold NUMBER(10,2)
)
STORAGE (INITIAL 100K NEXT 50K) LOGGING
PARTITION BY RANGE (time_id)
(
 PARTITION sales_q1_2006 VALUES LESS THAN (TO_DATE('01-APR-2006','dd-MON-yyyy')) TABLESPACE tsa STORAGE (INITIAL 20K NEXT 10K),
 PARTITION sales_q2_2006 VALUES LESS THAN (TO_DATE('01-JUL-2006','dd-MON-yyyy')) TABLESPACE tsb,
 PARTITION sales_q3_2006 VALUES LESS THAN (TO_DATE('01-OCT-2006','dd-MON-yyyy')) TABLESPACE tsc,
 PARTITION sales_q4_2006 VALUES LESS THAN (TO_DATE('01-JAN-2007','dd-MON-yyyy')) TABLESPACE tsd
)
ENABLE ROW MOVEMENT;

Particionamiento de Índices en Oracle

El particionamiento no se limita a las tablas; los índices también pueden ser particionados para mejorar el rendimiento y la manejabilidad.

Índices Locales vs. Globales

En una tabla particionada, los índices pueden ser:

• Índices Locales: Un índice local mantiene una relación uno a uno entre las particiones de la tabla y las particiones del índice. Cada partición del índice solo contiene las entradas correspondientes a las filas de la partición de tabla asociada. Son equiparticionados con la tabla. Son la opción preferida para mejorar la disponibilidad, ya que las operaciones de mantenimiento en una partición de tabla solo afectan a la partición de índice local correspondiente.
• Índices Globales: Un índice global puede particionarse (por rango o hash) o no particionarse. Un índice global puede contener entradas de filas de todas las particiones de la tabla subyacente. Las operaciones de mantenimiento en la tabla pueden invalidar (marcar como UNUSABLE o generar entradas huérfanas) partes o la totalidad de un índice global, requiriendo una reconstrucción o limpieza.

Índices Parciales y la Propiedad INDEXING

Oracle permite crear índices locales y globales en un subconjunto de las particiones de una tabla utilizando la propiedad INDEXING. Esta propiedad se puede especificar como ON o OFF para la tabla o a nivel de partición/subpartición. Se utiliza principalmente para índices parciales.

• Cuando un índice se crea como PARTIAL en una tabla:
• Índices Locales: Se crea una partición de índice usable si la propiedad INDEXING está ON para la partición de tabla correspondiente, y unusable si está OFF. Este comportamiento puede ser sobrescrito explícitamente.
• Índices Globales: Incluyen entradas solo de las particiones de tabla donde INDEXING está ON, excluyendo las otras.

Esta característica (índices parciales) no soporta índices únicos ni índices usados para aplicar restricciones únicas. El valor por defecto para un índice es FULL, lo que significa que el índice se crea sobre *todas* las particiones de la tabla, ignorando la propiedad INDEXING a nivel de partición.

Ejemplo de creación de índice global parcial:

CREATE INDEX ORDERS_ORDER_TOTAL_GIDX ON ORDERS (ORDER_TOTAL) GLOBAL INDEXING PARTIAL;

Este índice solo indexará las filas en las particiones de la tabla ORDERS que tengan la propiedad INDEXING ON.

Las vistas de diccionario como *_PART_TABLES, *_TAB_PARTITIONS, *_TAB_SUBPARTITIONS incluyen una columna INDEXING (ON/OFF). La vista USER_INDEXES incluye una columna INDEXING (FULL/PARTIAL). Además, USER_INDEXES y USER_IND_PARTITIONS tienen una columna ORPHANED_ENTRIES (YES/NO) para indicar si un índice global (o partición de índice) contiene entradas obsoletas debido al mantenimiento diferido de índices durante operaciones como DROP/TRUNCATE PARTITION o MODIFY PARTITION INDEXING OFF.

Consideraciones Adicionales

Compresión de Tablas y Particiones

En tablas organizadas por heap (regulares), se puede aplicar compresión a particiones específicas. La propiedad COMPRESS puede declararse a nivel de tablespace, tabla o partición, heredándose como otros atributos de almacenamiento. Esto ayuda a reducir el espacio en disco y mejorar el rendimiento de E/S al reducir la cantidad de datos a leer.

Ejemplo de tabla particionada por lista con una partición comprimida:

CREATE TABLE costs_demo (
 prod_id NUMBER(6),
 time_id DATE,
 unit_cost NUMBER(10,2),
 unit_price NUMBER(10,2)
)
PARTITION BY RANGE (time_id)
(
 PARTITION costs_old VALUES LESS THAN (TO_DATE('01-JAN-2003', 'DD-MON-YYYY')) COMPRESS,
 PARTITION costs_q1_2003 VALUES LESS THAN (TO_DATE('01-APR-2003', 'DD-MON-YYYY')),
 PARTITION costs_q2_2003 VALUES LESS THAN (TO_DATE('01-JUN-2003', 'DD-MON-YYYY')),
 PARTITION costs_recent VALUES LESS THAN (MAXVALUE)
);

Compresión de Claves en Índices Particionados

La compresión de claves se aplica a índices B-tree para eliminar ocurrencias repetidas de prefijos de columnas clave, ahorrando espacio y E/S. Puede aplicarse a particiones de índices.

Ejemplo de índice local particionado con compresión:

CREATE INDEX i_cost1 ON costs_demo (prod_id) COMPRESS LOCAL
(
 PARTITION costs_old,
 PARTITION costs_q1_2003,
 PARTITION costs_q2_2003,
 PARTITION costs_recent NOCOMPRESS
);

La compresión no se puede especificar explícitamente a nivel de subpartición de índice; se hereda de la partición padre. Para cambiar la compresión de una subpartición, se debe modificar la partición padre y reconstruir las subparticiones afectadas.

Tablas Organizadas por Índice (IOTs) Particionadas

Las IOTs también pueden ser particionadas usando los métodos de rango, lista o hash. La clave de partición de una IOT debe ser un subconjunto de las columnas de la clave primaria.

Al particionar una IOT, sus segmentos de índice primario y segmentos de desbordamiento (overflow) se equiparticionan. Cada partición de IOT tiene un segmento de índice y, si aplica, un segmento de desbordamiento.

Ejemplo de IOT particionada por rango:

CREATE TABLE sales(acct_no NUMBER(5), acct_name CHAR(30), amount_of_sale NUMBER(6), week_no INTEGER, sale_details VARCHAR2(1000), PRIMARY KEY (acct_no, acct_name, week_no))
ORGANIZATION INDEX INCLUDING week_no OVERFLOW TABLESPACE overflow_here
PARTITION BY RANGE (week_no)
(
 PARTITION VALUES LESS THAN (5) TABLESPACE ts1,
 PARTITION VALUES LESS THAN (9) TABLESPACE ts2 OVERFLOW TABLESPACE overflow_ts2,
 ...
 PARTITION VALUES LESS THAN (MAXVALUE) TABLESPACE ts13
);

Se recomienda usar ENABLE ROW MOVEMENT para IOTs particionadas por hash si se esperan actualizaciones en las columnas de la clave primaria, ya que esto podría mover la fila a una partición diferente.

Restricciones con Tamaños de Bloque Múltiples

Es importante tener precaución al usar tablas particionadas en bases de datos con tablespaces que tienen diferentes tamaños de bloque. Existe una restricción clave: todas las particiones de las siguientes entidades deben residir en tablespaces con el *mismo* tamaño de bloque:

• Tablas convencionales.
• Índices (globales o locales).
• Segmentos de índice primario de IOTs.
• Segmentos de desbordamiento de IOTs.
• Columnas LOB almacenadas fuera de línea.

Esto significa que, por ejemplo, todas las particiones de una tabla convencional deben estar en tablespaces del mismo tamaño de bloque. De manera similar, todas las particiones de un índice específico deben estar en tablespaces del mismo tamaño de bloque. Sin embargo, las particiones de la tabla y las particiones de un índice local sobre esa tabla *pueden* estar en tablespaces con diferentes tamaños de bloque entre sí, siempre que todas las particiones de la tabla compartan un tamaño de bloque, y todas las particiones del índice compartan otro (o el mismo) tamaño de bloque.

Tabla Comparativa de Tipos de Particionamiento

Aquí tienes un resumen de los métodos de particionamiento más comunes:

Preguntas Frecuentes sobre Particionamiento en Oracle

El particionamiento puede generar algunas dudas comunes. Aquí respondemos algunas basadas en la información proporcionada:

¿Puedo particionar cualquier tipo de tabla en Oracle?

Puedes particionar tablas organizadas por heap y tablas organizadas por índice (IOTs). No se soporta el particionamiento para tablas que contienen columnas LONG o LONG RAW.

¿Qué es un índice parcial en Oracle?

Un índice parcial es un índice local o global que solo indexa un subconjunto de las particiones de una tabla. Se basa en la propiedad INDEXING (ON/OFF) definida a nivel de tabla o partición. Esto permite excluir particiones de un índice, lo cual puede ser útil para datos históricos o inmutables donde el acceso por índice no es necesario.

¿Qué sucede con los índices locales cuando se realiza mantenimiento en una partición de tabla?

Una de las principales ventajas de los Índices Locales es que están equiparticionados con la tabla. Esto significa que las operaciones de mantenimiento en una partición de tabla (como eliminar o truncar una partición) solo afectan a la partición de índice local correspondiente. Las otras particiones del índice local permanecen usables, lo que mejora la disponibilidad.

¿Qué sucede con los índices globales durante el mantenimiento de particiones de tabla?

Las operaciones de mantenimiento en particiones de tabla (como DROP PARTITION o TRUNCATE PARTITION) pueden dejar entradas obsoletas (huérfanas) en los Índices Globales que cubren esas particiones. Estas entradas obsoletas requieren mantenimiento adicional para ser eliminadas (limpieza diferida o reconstrucción del índice global), lo que puede afectar la disponibilidad del índice.

¿Qué es la propiedad INDEXING y para qué sirve?

La propiedad INDEXING (ON/OFF), que se puede especificar a nivel de tabla o partición, controla si las filas de esa tabla o partición deben ser incluidas en los índices parciales. Cuando se crea un índice como PARTIAL, este respeta esta propiedad. Si la propiedad es ON para una partición, las filas de esa partición se incluyen en el índice parcial; si es OFF, se excluyen. Por defecto, los índices son FULL y no respetan esta propiedad.

¿Qué es ENABLE ROW MOVEMENT?

La cláusula ENABLE ROW MOVEMENT permite que una fila se mueva automáticamente de una partición a otra si una actualización de su clave de partición cambia el valor de tal manera que la fila ahora pertenece a una partición diferente. Por defecto, el movimiento de filas está deshabilitado (DISABLE ROW MOVEMENT), y si una actualización intenta mover una fila a otra partición, se producirá un error.

¿Puedo usar compresión en mis tablas particionadas?

Sí, puedes usar compresión de tablas en tablas organizadas por heap a nivel de partición. Puedes especificar la cláusula COMPRESS para particiones individuales, mientras que otras no están comprimidas o heredan el atributo de compresión de la tabla o tablespace.

¿Las IOTs particionadas tienen alguna restricción especial?

Sí, la clave de partición para una IOT particionada debe ser un subconjunto de las columnas de la clave primaria. Además, todos los segmentos de índice primario de las particiones deben residir en tablespaces con el mismo tamaño de bloque, y todos los segmentos de desbordamiento de las particiones deben residir también en tablespaces con el mismo tamaño de bloque (aunque el tamaño de bloque para los segmentos de índice puede ser diferente al de los segmentos de desbordamiento).

¿Puedo tener particiones de una tabla en tablespaces con diferentes tamaños de bloque?

No. Todas las particiones de una tabla convencional deben residir en tablespaces con el mismo tamaño de bloque. Lo mismo aplica para todas las particiones de un índice específico, todos los segmentos de índice primario de una IOT, y todos los segmentos de desbordamiento de una IOT. Esta es una restricción importante a considerar en entornos con múltiples tamaños de bloque.

Conclusión

El particionamiento en Oracle Database es una herramienta poderosa para gestionar y optimizar grandes conjuntos de datos. Al dividir tablas e índices en particiones más pequeñas y manejables, se pueden lograr mejoras significativas en el rendimiento de las consultas, la eficiencia de las operaciones de mantenimiento y la disponibilidad general del sistema. La elección del método de particionamiento adecuado (rango, intervalo, hash, lista, referencia, compuesto) depende de la naturaleza de los datos y los patrones de acceso. La comprensión de conceptos como Índices Locales vs. Índices Globales, la propiedad INDEXING para índices parciales y la cláusula ROW MOVEMENT es crucial para diseñar e implementar estrategias de particionamiento efectivas. Aunque existen algunas restricciones, como las relacionadas con tamaños de bloque múltiples, los beneficios del particionamiento lo convierten en una técnica indispensable para administrar bases de datos Oracle a gran escala.

Si quieres conocer otros artículos parecidos a Particionamiento en Oracle: Guía Completa puedes visitar la categoría Bases de datos.