Vista materializada por meses muy Grandes

Como generar una vista materializada por meses correspondiente a dos tablas también particionadas con una capacidad de 40 millones de registros por mes. Estas tablas solo reciben ingresos de registros, nunca borrados ni modificaciones.
El problema es que no se como decirle a la V.M. Que actualice solo los últimos registros mediante la V.M.Log. Ya que cuando llega al mes de Julio... Como el caso tarda en refrescar como cuatro a cinco horas.
¿Hay otra forma de generar esta información?

1 Respuesta

Respuesta
1
Según lo que cuentas creo que la capacidad de movimiento de datos una vista materealizada no te serviría, bajo mi punto de vista. Lo que necesitarías seria una dataware house que aparte de mover esa cantidad de reguistros de una forma digamos que "agil" podrías llevar a cabo más cosas con este que una vista materializada.
Lo que podrías hace si sigues con la idea de la vista materializada es hacer varias para de esta forma franccionar la información hacer que el tiempo de carga o de transferencia sea menor. Cuatro horas en este volumen de datos no me parece excesivo, pero si mejorable.
En primer punto deberías tener claro que datos quieres almacenar en la vista para posteriormente cargarla. La 1 carga tardaras un montón de horas pero posteriormente tan solo necesitaras una par para las nuevas actualizaciones.
La segunda opción que et comentaba es recoger los datos por separado en diferentes vistas materializadas e irlas cargando una una en diferentes horas. Al tratarse de un volumen seguramente menos considerable de datos esta te tardara más.
Creo que con esto te puedes llegar ahacer una idea.
Hola Jac_bubu:
El problema reside en que hace poco me he hecho cargo de esta BD en la que como puedes comprender que cada vez que te cambias de trabajo te encuentras con problemas ya establecidos.
El caso es que ya existe la VM y tiene ya siete meses, con lo cual se ha vuelto muy pesada de refrescar. He conseguido hacer comprender a la dirección que esta fórmula no es buena y lo más que he conseguido es ir acortando los datos de refresco en 4 meses y así me voy a ver obligado ha hacerlo cada tres meses con la perdida de tiempo y esfuerzo sin mejorar la situación.
La fórmula de montar una dataware house seria una solución, pero como ya sabes las empresas privadas, priman los costes y nos dejan los problemas a los demás.
Mi pregunta es si existe una fórmula por la cual la VM no atienda a los DELETES y UPDATES que se hagan, ya que no van ha existir, tan solo habrá INSERT y siempre en cola y por fecha de ingreso.
Gracias por tu atención.
Yo tampoco creo en la efectividad de estas VM y sobre todo tan grandes. La situación es, hay una plataforma Web por la cual se hacen unas consultas TIPO por medio de unos formularios variables, estos van enviados a un sinónimo que este enlaza con la VM.
Estoy estudiando alguna fórmula por la cual crear una tabla nueva con la estructura de la VM, e ir cargándola de alguna manera a partir de las dos tablas originales. ¿El problema reside en saber donde me he quedado la última vez que hice la recarga para continuar desde ahí en adelante...? Para continuar así progresivamente.
Si tuvieras alguna solución a este problema o me dieras luz a otra fórmula. Te anticipo que la solución de una vista normal ya la he probado sobre las tablas matrices y es desesperante lo que tarda en dar la respuesta.
Gracias por tu interés y no me ha quedado muy claro lo que me apuntas sobre el trigger.
Yo no creo mucho en las VM pero bueno como tu dices te lo has encontrado echo y no puedes hacer nada más .
Te intentaré dar diferentes soluciones al problema y tu seleccionas la más usual.
Con respecto a la VM si la optimización es complicada . La idea de coger los datos de una tabla ponerlos en una VM y que tengas acceso mediante navegador (supongo que es tu caso) Debe relentizar una barbaridad. En la web de oracle podrás encontrar como hacer el tratamiento de estos updates, te lo comento por que es más sencillo que accedas allí y veas como te hacen llegar el códfgo que si yo te lo excribo. Esta en el apartado documentación/SQL syntax.
Yo intentaría abandonar al idea de esa VM que te has encontrado. Con ese volument de registro es un cuello sin botella, vamos que te quedaras sin espacio y cada vez tardaras más en esa transacción.
Para un futuro yo miraría el códifo y cada vez que hagas la insesción de datos mediante un trigger rediriiiria el insert a dos tablas y a partir de aquí mediante un vista normal daría acceso a los usuarios. Con esto te ahorraris una cantidad de tiempo increíble y no tendrías que estar moviendo datos de un lado para el otro.
No se si te sirve pero si no dime algo

Añade tu respuesta

Haz clic para o

Más respuestas relacionadas