Refresco de Materialized View con Delete

Hace poco me preguntaron como se podia realizar un refresco completo de una Vista Materializada (VM) sin usar Truncate por question de consistencia de lectura. No querian que los usuarios vean una tabla vacia cuando esta refrescando la VM.

Han hecho los deberes y  consultaron primero en la documentacion donde le indica, pasando TRUE al argumento del package  DBMS_MVIEW.REFRESH.ATOMIC_REFRESH usaria delete. Lo han probado una y otra vez sin exito.

El comando utilizado es:

exec dbms_mview.refresh(‘MV_T1′,’C’,ATOMIC_REFRESH=>TRUE)

El problema es que si no pasas una lista de  VM al package SIEMPRE usara TRUNCATE, si se usa esta llamada

exec dbms_mview.refresh(‘MV_T1,MV_T2′,’C’,ATOMIC_REFRESH=>TRUE)

Que engloba dos VM si se utilizaria DELETE.

En la documentacion indica esto:

“atomic_refresh
If this parameter is set to true, then the list of materialized views is refreshed in a single transaction. All of the refreshed materialized views are updated to a single point in time. If the refresh fails for any of the materialized views, none of the materialized views are updated.

If this parameter is set to false, then each of the materialized views is refreshed in a separate transaction. The number of job queue processes must be set to 1 or greater if this parameter is false.”

La confusion es que en ningun parrafo indica que tienes que pasar mas de una VM para que use DELETE, aunque si indica que tienes que pasar una lista.

7 thoughts on “Refresco de Materialized View con Delete

  1. carlosal

    Buenas.

    He leído tu artículo y siento curiosidad:

    ¿Qué pasa con el ‘rollback’? Utilizar un ‘DELETE FROM’ sobre la VM generará una cantidad de ‘rollback’ considerable (al menos para las VM’s a las que estoy acostumbrado).

    ¿No era posible utilizar un ‘FAST REFRESH’?

    Saludos.

    Carlos.

    Reply
  2. lscheng Post author

    Hola

    El DELETE genera bastante Undo. Se decidió usar DELETE por cuestiones de consistencia de lectura. El proceso de refresco duraba entre 1 a 3 minutos mas ó menos, si se hubiera utilizado truncate durante el intervalo de refresco no devolvería ningún dato.

    Fast Refresh no era necesario porque los datos no tenían que ser en tiempo real, con refresh completo se evita los overheads de Fast Refresh

    Salu2


    LSC

    Reply
  3. carlosal

    Buenas otra vez.

    Hay un par de cosillas con las que no estoy de acuerdo:

    >>”con refresh completo se evita los overheads de Fast Refresh”

    ¿A qué ‘overhead’ te refieres? Yo creo que reconstruir una MV desde cero cada vez (incluso con PARALLEL, NOLOGGING, APPEND, etc…), con sus índices asociados y toda la pesca… es bastante más ‘overhead’ que un FAST REFRESH de las filas que sufrieron modificaciones solamente (Por supuesto, siempre y cuando el porcentaje de modificadas esté dentro de lo razonable).

    >>”Fast Refresh no era necesario porque los datos no tenían que ser en tiempo real”

    FAST REFRESH no significa ON COMMIT.

    FAST REFRESH con un MATERIALIZED VIEW LOG utiliza DELETE, y a diferencia del COMPLETE sólo modifica las filas que han sufrido cambios según dicho MATERIALIZED VIEW LOG (siempre que no se haya utilizado DIRECT PATH / APPEND para incluir nuevas filas).

    Saludos.

    Carlos.

    Reply
  4. lscheng Post author

    Hola

    Depende de como lo veas los overheads. Esto es como todo, depende de la naturaleza de las tablas.

    Es que las tablas sufrían muicho DML entonces no tenia mucho sentido generar logs de MV para guardar esos cambios. Era menos costoso hacer un refresco completo cada X tiempo.

    Por ejemplo si la tabla sufre 50000 DMLs en un inetrvalo eso te guarda los 50000 cambios en los MV logs, muchas veces un mismo registro sufre varios cambios. Para refrescar con FAST tendria que aplicar todos esos cambios y eso costaba mas que un refresco completo.

    Salu2


    LSC

    Reply
  5. carlosal

    Buenas de nuevo.

    No es por tocar los cojones, pero decir que hay 50000 DML’s no es decir mucho si no dices el número de filas de las MV’s. En mi caso, te diré que estoy trabajando con MV’s de unos 35.000.000 de filas, con lo que 50.000 no parecen tantas (0,14%).

    Por otra parte, TRUNCATE va a hacer que todo lo que hubiera en el Buffer Pool de esa VM se vaya por el desagüe, forzando PHYSICAL IO’s cuando volvamos a comenzar a acceder a ella, al menos al principio. Por no hablar de los índices (que habría que reconstruir a no ser que queramos que el REFRESH tarde más…) etc, etc…

    Repito que no quiero tocar los cojones, esto es solo un cambio de impresiones ‘sin acritud’😉

    Saludos.

    Carlos.

    Reply
  6. lscheng Post author

    Hola

    Una de las MV si no recuerdo mal tenia unos 56000 registros (el que sufre mas o menos 50000 modificaciones).

    Y las otras MV no eran copia de las tablas, eran agrupaciones de las tablas (un select count(*), … …. .. from … group by), si una tabla tenia 2000000 de registro, la MV tendria unos 3000 registros (por las agrupaciones).

    Salu2


    LSC

    Reply
  7. Jose Luis

    Hola, estoy en un buen lio con las VM en la vida habia visto una VM particionada en 12 meses y con unos 40 millones de registros en cada mes… Esta vista materializada se compone de dos tablas que a su vez tienen MATERIALIZED VIEW LOG cada una. Estas dos tablas estan particionadas igualmente y solo reciben insert, ni update ni delete. El problema es cuando su correspondiente Job se pone a refrescar se tira mucho tiempo y cuando quiere terminar como esta dispuesto que refresque cada 7 minutos porque es necesario que este al dia siempre, no termina nunca de estar al corriente.
    He lanzado un exec dbms_mview.refresh(list=>’user.mv’,atomic_refresh=>FALSE); y tarda como hora y media cuando se pone al dia desde que se le manda el comando, si entra el job a continuación dbms.refresh.refresh borra lo recontruido anterior y no termina nunca de refrescar.
    Tengo dos preguntas, los dos sistemas son incompatibles entre si?, que debo hacer para que esto tenga un aspecto real y no haya que estar haciendo manualmente estos trabajos.
    Gracias.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s