Optimización de Índices: De Reverse a B-Tree en Entornos Particionados
Mi nombre es Carla y me defino como una apasionada de conocer, compartir ideas, divertirme y aprender todo lo relacionado con Oracle.
Alegre y creativa, con un alto grado de autoexigencia, que busca, incluso sin querer, una forma diferente de ver un mismo problema o solución. Defensora del trabajo en equipo en todas las facetas de la vida y de disfrutar todo lo que haces, siempre con humildad.
Actualmente cuento con más de 15 años de experiencia como administradora de Oracle, habiendo ocupado previamente posiciones como desarrolladora en la rama de Inteligencia de Negocios. Fue en ese momento que me di cuenta de que no quería centrarme en el desarrollo, sino participar en todas las capas que involucraban los datos, desde el despliegue de la base de datos hasta su explotación final.
Siempre estoy dispuesta a ayudar y compartir conocimientos. Creo firmemente que con la tecnología hay que divertirse y no verla como una competencia. La persona con la que tienes que ser el mejor es contigo mismo.
En administración de bases de datos Oracle, no todos los índices se comportan igual ante un cambio de estructura. Recientemente me enfrenté a la necesidad de transformar un índice Reverse Key a un índice Normal (B-Tree).
El matiz: ¿Global o Local?
Si estuviéramos ante un índice Global, la solución sería inmediata y elegante: ALTER INDEX IDX_GLOBAL REBUILD ONLINE NOREVERSE;
Pero, ¿qué pasa si el índice es LOCAL y la tabla está particionada? Aquí la sintaxis de Oracle nos limita, y no podemos usar la cláusula NOREVERSE en un rebuild de este tipo. Por ello, debemos recurrir a una estrategia de reconstrucción completa.
La Estrategia: Creación online e Invisible
Para evitar el error ORA-01408 (columna ya indexada) y no degradar rendimiento, el flujo de trabajo ideal es el siguiente:
Preparación del terreno (TEMP y Monitorización)
Dado que moveremos grandes volúmenes de datos (en mi caso, más de 100 GB), es vital asegurar que el tablespace temporal aguante el "sort". SQL
-- Monitorización del consumo de TEMP durante la creación en entorno de prueba
SELECT ROUND(SUM(blocks)*8/1024, 2) MB_REAL FROM v$sort_usage;
Creación del nuevo índice "en la sombra"
Utilizamos las cláusulas ONLINE para no bloquear DML e INVISIBLE ya que si no nos encontraríamos el error: ORA-01408: such column list already indexed.
Oracle permite tener dos índices sobre las mismas columnas siempre y cuando solo uno de ellos sea visible para el optimizador y una estructura física distinta,
CREATE INDEX XXX.IDX_LOG_ENV_PERF
ON XXX.LOG_ENTREGAS (ID_DISPOSITIVO, FECHA_LOG)
LOCAL
ONLINE
INITRANS 50
PCTFREE 20
TABLESPACE TBS_INDEXES
PARALLEL 8 -- Aprovechamos la potencia del server
INVISIBLE;
ALTER INDEX XXX.IDX_LOG_ENV_PERF NOPARALLEL;
Compruebo que ambos conviven:
Nota importante sobre el rendimiento: Ten en cuenta que mientras ambos índices convivan (el antiguo Reverse y el nuevo Normal), cada operación de
INSERT,UPDATEoDELETEtendrá que actualizar ambos. Esto supone una penalización temporal en las operaciones DML, por lo que se recomienda realizar el cambio en horas de menor carga.
El Switch de Visibilidad
Una vez creado, el cambio es instantáneo a ojos de la aplicación. Pasamos el índice antiguo a modo invisible y activamos el nuevo. Esto nos da un plan de rollback inmediato: si algo falla, solo hay que revertir la visibilidad.
ALTER INDEX XXX.IDX_ORIGINAL_REVERSE INVISIBLE;
ALTER INDEX XXX.IDX_LOG_ENV_PERF VISIBLE;
Va todo bien? Liberamos espacio una vez validado el cambio .
DROP INDEX XXX.IDX_ORIGINAL_REVERSE;
Cuando trabajamos con índices locales, perdemos la facilidad del REBUILD NOREVERSE.
Utilizar índices invisibles y creación online es la forma más transparente de realizar este cambio en entornos críticos de 24/7.
