En general, estaría pensando en ya sea una capa de vista o una capa de vista materializada para informar a los usuarios. Mi preferencia, a menos que haya problemas concretos de rendimiento, sería ir con vistas con el objetivo de crear vistas materializadas ocasionales que utilicen la reescritura de consultas para acelerar los informes seleccionados.
Si utiliza vistas materializadas, obviamente materializará los datos por segunda vez pero en un formato que resultará en un almacenamiento menos eficiente. Eso significa que la mayor parte del espacio en el sistema se asignará a las vistas materializadas desnormalizadas y sus índices. Eso puede generar una factura bastante considerable de parte de su proveedor de discos y puede crear contención para los recursos de SAN.
Las vistas materializadas también significan una mayor competencia por el espacio de caché entre OLTP y los usuarios que informan. Dado que están almacenados en diferentes objetos, los informes que están buscando actividad reciente no podrán beneficiarse de los bloques activos en la memoria caché de la actividad OLTP y viceversa. Puede mitigar este problema lanzando RAM hacia él o moviendo los informes a horas no pico, pero no es la solución más eficiente. Si tiene informes casi exclusivamente históricos, probablemente este no sea un gran problema, ya que de todos modos no habría intercambio porque los procesos están interesados en bloques completamente diferentes, pero si tiene muchos informes operativos, se vuelve significativo.
Las vistas materializadas también suelen ser menos flexibles. Si desea presentar los mismos datos de varias formas, se está materializando múltiples veces, aumenta los costos reales tanto en disco como en caché, así como también aumenta el tiempo requerido para realizar la actualización periódica de la capa de vista materializada. En la práctica, eso significa que los usuarios que informan obtienen una visión del mínimo común denominador de los datos y tienen que reinventar la rueda cuando recortan y recortan los datos porque TI no quiere crear una nueva vista materializada para ellos.
Como dije antes, mi preferencia sería una capa de vista normal. Eso evita el costo de almacenar los datos varias veces y permite compartir bloques en el caché entre OLTP y consultas de informes. También hace que sea relativamente fácil dar a los usuarios diferentes vistas de los datos y elimina la necesidad de mantener informados a los usuarios de negocios sobre qué tan obsoletos son los datos sobre los que informan. Si el rendimiento se convierte en un problema debido a que el modelo de datos OLTP no es compatible con el tipo de consultas que desea ejecutar, puede crear vistas materializadas segmentadas que actúen como índices a través del query rewrite. Eso significa que los usuarios pueden consultar vistas regulares y el DBA luego puede agregar una vista materializada que genera todo o parte del resultado y el optimizador puede cambiar el plan de consulta para usar esa nueva vista materializada en lugar de escanear la (s) tabla (s) y hacer cosas como agregar datos en tiempo de ejecución.
En algún momento, es probable que desee mover el tráfico de informes para llegar a un depósito de datos real con un modelo de datos más dimensional. Si encuentra que realmente necesita el rendimiento de una capa de vista materializada en lugar de una capa de vista normal, estaría pensando en ir a un almacén de datos real con hechos y dimensiones. Obtendrá algo que es mucho más flexible para informar con básicamente los mismos dolores de cabeza de ETL que probablemente obtendría con una capa de visualización materializada completa.
lo siento por no mencionar que es una edición empresarial 10g. – Sherry
@ Sherry: reescribió la publicación para empresas no expresas. –
gracias por publicar de nuevo con la edición empresarial, y señalar bien en cuestiones de almacenamiento y recursos de MV. – Sherry