La funcionalidad de materialized views permite replicar los cambios de una base de datos sobre otra a través de un dblink. Cuando se implementa se genera una tabla de log que contiene todos los cambios que se van produciendo en la base de datos de origen y que serán aplicados sobre el destino como si de archivers se tratara. Esa tabla (o tablas) de log se identifican por crearse en el esquema de origen, con el prefijo MLOG$. El contenido de estas tablas temporales se va borrando cuando los cambios se van aplicando sobre el dblink y se confirma que dicho cambio ha sido aplicado correctamente.

Si configuramos una replica de esta forma y el destino no está accesible o no se termina de configurar correctamente, la tabla de log va acumulando los cambios y no los libera. Eso puedo provocar que dichas tablas crezcan constantemente:

sql> select SEGMENT_NAME,SEGMENT_TYPE,TABLESPACE_NAME,BYTES from dba_segments WHERE TABLESPACE_NAME=’TBS1′ order by bytes desc;

TABLE_NAME           SEGMENT TYPE TBS  BYTES
MLOG$_REF_REFERENCES TABLE        TBS1 7.723.810.816
CTL_QUERY_LOG        TABLE        TBS1 2.885.681.152
MLOG$_PRO_PRODUCTS   TABLE        TBS1 2.818.572.288
SCT_PK               INDEX        TBS1 2.483.027.968
QCK_DETAIL           TABLE        TBS1 2.204.106.752

Si no vamos a usar los datos que hasta ahora teniamos replicados, haremos un drop de estas tablas temporales tal que:

SQL> drop materialized view log on ref_references;
Materialized view log dropped

SQL> drop materialized view log on pro_products;
Materialized view log dropped