Primero para entender porque, como usarlas y sus opciones, vamos a arrancar con la definición de que es una vista materializada.

Que es una Vista Materializada (VM)

Una VM no es más que una vista, con la diferencia de que además de almacenarse su definición se almacenan los datos que retorna.

Esto es especialmente útil cuando la vista en cuestión se va a llamar constantemente y se necesita una buena performance.

La contra es que salvo que se defina como actualizable al hacer commit en las tablas referenciadas (poco común) una vez creada la VM los datos van a ser estáticos hasta su actualización, que puede ser tanto manual como automática.

Porque usar una VM si no voy a tener el contenido actualizado?

Hay muchos casos en que no hace falta tener el contenido actualizado, por ejemplo cuando se desean ver datos consolidados al día anterior (en algunos tipos de dashboard).

Es decir el negocio y la aplicación definirá si nos sirve utilizar una VM, en cuyo caso se va a ganar muchísimo a nivel performance.

Como alternativa esta utilizar una VM que se actualice a nivel datos con cada commit realizado a las tablas referenciadas, hay que tener cuidado en este caso que no genere un inconveniente en la operación cuando se dispara el refresh.

Como se actualizan los datos de una VM?

La VM puede ser actualizada de tres formas:

– En forma automática al realizar un commit a alguna de las tablas referenciadas

– En forma automática en un horario determinado

– En forma manual

En los dos primeros casos (especialmente el segundo) hay que tener mucho cuidado que dicha actualización no genere un cuello de botella, ya que hace una especie de bloqueo temporal de las tablas implicadas en la vista.

Es decir lo ideal sería o realizarlo en forma manual (por ejemplo como parte del proceso de consolidación de datos) o que se ejecute en forma automática en un horario en que no pueda afectar la operación (de noche, o de madrugada previo al inicio del día laboral).

Solo es recomendable realizar una actualización “on commit” (primer caso) si el flujo de datos actualizados es chico.

Tipos de actualizaciones de una VM

– Complete: la actualización complete implica que todos los datos de la VM van a ser borrados y luego creados (insert) nuevamente.

– Fast: a través de la creación de un log, la actualización de la VM va a ser incremental, es decir solo se va a modificar lo que cambio, y se van a insertar los datos nuevos.

El inconveniente con el método fast es que tiene muchas limitaciones en el tipo de consulta que se puede definir en la VM, por ende tiende a no ser posible utilizarlo.

– Force: la actualización se realizará en forma fast si es posible, en caso contrario en forma complete.

Porque la actualización complete demora tanto? Delete vs Truncate

Cuando realizamos una actualización de tipo complete, los datos se van a borrar y luego insertar nuevamente.

Para esto podemos definir la forma en que hará el borrado, es decir a través de un delete (atómico) o de un truncate.

En caso de no especificarlo va a realizar el método delete-insert.

En principio salvo que haya alguna limitación de por medio, por temas de performance siempre es más conveniente realizar el resfresh forzando el truncate de la VM.

Sintaxis y ejemplos

Crear una VM:

CREATE MATERIALIZED VIEW vista_materializada

[TABLESPACE nuestro_tablespace]

[BUILD {IMMEDIATE | DEFERRED}]

[REFRESH {ON COMMIT | ON DEMAND | [START WITH fecha_inicial] NEXT intervalo_tiempo } |

{COMPLETE | FAST | FORCE | NEVER} ]

[{ENABLE|DISABLE} QUERY REWRITE]

AS SELECT tabla1.campo_a, tabla2.campo_b

FROM tabla1 , tabla2

WHERE tabla1.campo_a = tabla2.campo_a...

En la creación de la vista es conveniente definir si se van a generar los datos al ejecutar la creación o si va a ser en forma posterior

(IMMEDIATE o DEFERRED), especificar cuando hacer el refresh (ON COMMIT | ON DEMAND | START WITH) y como (COMPLETE | FAST | FORCE | NEVER).

Un ejemplo de una VM que genere/almacene los datos al crearla, que haga el refresh a demanda, y en forma completa sería:

CREATE MATERIALIZED VIEW vista_materializada

   TABLESPACE ejemplo_tablespace

   PARALLEL 4

   BUILD IMMEDIATE

   REFRESH COMPLETE ON DEMAND

   AS SELECT tabla1.campo_a, tabla2.campo_b

    FROM tabla1 , tabla2

    WHERE tabla1.campo_a = tabla2.campo_a...

Y para invocar el refresh forzando el truncate usaríamos:

exec dbms_mview.refresh( 'vista_materializada', atomic_refresh=>false);

Alguna duda? en caso contrario, a aprovechar la mejora de performance de una buena implementación de vistas materializadas.

Dejá un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *