En mi caso sucedió lo siguiente: por una migración de 9.2 a 11.2 de motor de base, se realizó una exportación/importación tradicional a nivel de esquemas. Estas herramientas incluyeron la metadata de las vistas materializadas. En el 9.2 tenía un db_domain configurado, mientras que la 11.2 estaba sin db_domain definido.
Para aquellas MV donde no tienen definido el tipo de refrescamiento (por defecto toma FORCE), o tienen explícitamente el tipo FORCE, la MV primero intenta hacer un FAST REFRESH y para ello se basa en el metadato almacenado en el campo dba_mviews.master_link, que como estamos hablando de una MV que viene migrada desde el 9.2 con db_domain, acarrea ese mismo valor. Como en la 11.2 quedaron los db_links con el dominio definido en NULL, al momento de hacer el refresh de la MV, esta intenta hacer un fast refresh utilizando el db_link informado en dba_mviews.master_link, en este caso no va a poder encontrar el mismo en la nueva base, y va a fallar por completo el refrescamiento. El problema de recrear por completo las MV, es principalmente el tiempo, por el volumen de datos que deben recuperar.
Una posible solución sería, eliminar la MV sin olvidar la cláusula PRESERVE TABLE. Esto hace que ante Oracle, la tabla contenedora de la vista, se vean como una tabla común y corriente ante el motor de la base. Luego, se volvería a contruír la MV con la cláusula ON PREBUILD TABLE, para que la tabla sea interpretada por el motor como una tabla contenedora de la nueva MV.
Las condiciones para poder efectuar satisfactoriamente esta maniobra, es que la MV sea exportada de un motor 9i en adelante, y que la nueva MV y la preexistente tabla tengan el mismo nombre y se encuentren en el mismo esquema.
TODO: debo probar qué pasa, si corrijo directamente la definición del db_link en el campo sys.snap$.mlink del diccionario de datos de la instancia, maniobra NO sugerida por metalink!
Languagesen>es GoogleDicCE
ninguno, imposible, prohibido, negativa, voto negativo, voto en contra, no
No hay comentarios:
Publicar un comentario