626 Vistas

Consideraciones para optimizar espacio en base de datos Oracle para una solución de Datawarehousing (DWH)

Por Moisés Inestroza.

Al diseñar una solución de Datawarehousing puede ser de mucha utilidad tener presente algunas consideraciones al momento de crear los objetos o al volcar la información, lo que llevarán finalmente a optimizar la utilización del espacio de nuestras bases de datos. A continuación menciono algunas de las que vienen en mente y consideramos relevantes:

1- Al momento de crear la tabla, Oracle por defecto pone un valor al atributo PCTFREE como una reserva de espacio para las operaciones de updates; Por lo general o dependiendo de nuestra arquitectura (al menos en Kimball) no habría necesidad de efectuar updates a la información ya que deberíamos crear nuevas versiones de las transacciones o la tabla se trunca y se reescribe. Por ello es recomendable entonces dejar ese valor en cero (0).

2- Es recomendable hacer uso de la funcionalidad de compresión que Oracle provee, COMPRESS BASIC o COMPRESS FOR OLTP reduce significativamente el espacio ocupado por la información sin impacto al momento de recuperarla en una consulta select, es decir es totalmente transparente. Aplica para las tablas así como las particiones.

3- Si tenemos banderas YES/NO, SI/NO en alguna columna podemos hacer el cast a Y/N o 0/1 que es igual de interpretable para una capa superior de BI por ejemplo y ocupa menos espacio.

4- Para los campos tipo date se puede establecer una dimensión independiente con las fechas e información pre calculada de cada fecha (día de la semana, nombre del día, mes, quincena, etc) y almacenar en la tabla solo la llave foránea. Con ello tenemos una ganancia en términos procesamiento y espacio.

5- Definir tablespaces independientes para las tablas landing, temporales, staging y summarized para poder dar más libertades al momento de tomar decisiones de liberar espacio.

6- Si, producto de un análisis del comportamiento de la información resultara factible hacer cast de la información de un tipo de dato de mayor peso como varchar2 a un tipo int, podríamos ahorrar espacio importante en fuentes voluminosas.

7- Dependiendo de cada caso. La información staging, que es información a detalle que luego es empleada para alimentar las tablas de dimensiones y hechos, puede servir en caso de reconstrucciones de estas tablas sin necesidad de regresar al sistema legado a recuperarla; pero no debería mantenerse un  histórico tan amplio, puede ser recomendable contar con  una historia no mayor a 3 meses, con una lógica de auto limpieza en el etl, para que al momento de ejecutarse, limpie tres meses atrás de la fecha que está procesando.

8- No abreviar las descripciones en las tablas de dimensión con la intención de reducir espacio. En cuanto más legible sea el nombre del campo es mucho mejor, esta técnica no traerá ahorros significativos.

Si este artículo fue de su interés o si tiene algún comentario al respecto le agradecemos enviarnos sus sugerencias en el formulario de Contáctenos.

También, si su organización requiere apoyo en temas de inteligencia de negocios o datawarehouse, puede contactar a GO Consultores donde cualquiera de nuestro equipo de trabajo estará gustoso de exponerle nuestro servicio.

SOLICITE MÁS INFORMACIÓN ¡CONTÁCTENOS!

Categorías: