Dimensionamiento de la base de datos.

Toca crear una base de datos para un nuevo proyecto y llegan las ¡Vaya preguntas!  como por ejemplo: ¿Cuánto disco necesito para mi nueva base de datos Oracle? Suponemos que nuestra instalación no tiene ASM instalado, de ser esto cierto, no necesitas seguir leyendo mas este artículo, bueno tendrás que leer algo si quieres tener en cuenta los demás componentes de tu instalación.

ASM es un administrador de volúmenes y un sistema de archivos para bases de datos Oracle que admite configuraciones de base de datos Oracle de una sola instancia y Oracle Real Application Clusters (Oracle RAC). ASM es la solución de administración de almacenamiento recomendada de Oracle que proporciona una alternativa a los administradores de volúmenes convencionales, sistemas de archivos y dispositivos sin formato.

Pasemos a mi receta:

• 8-10 veces el volumen de datos en bruto para un sistema OLTP
• 2-4 veces el volumen de datos en bruto para un Almacén de datos.
• Cuanto más grande sea la base de datos, más cerca estará de los factores de multiplicación inferiores.

Aclaración: Por supuesto, esta es solo mi opinión, basada en alguna que otra experiencia. Si usas las cifras anteriores para un proyecto real y no obtienes el espacio total en disco que necesitas, no me eches las culpas ;P. Si lo haces y está bien, entonces por supuesto, ahora me debes una cerveza :)

Muchos de nosotros probablemente hemos tenido que calcular el tamaño esperado de una base de datos antes (bajo la atenta mirada del manager, en el momento de hacer el pliego de una oferta), pero la base de datos real es solo un componente de todo lo que necesita para ejecutar Oracle en tu sistema. También debe dimensionar los demás componentes:

• Registros de rehacer archivados (redo logs), 
• Área de preparación de copias de seguridad, 
• Área de transferencia de datos. 
• Archivos externos, si los hubiera. 
• El sistema operativo. 
• Espacio de intercambio (swap), 
• Espacio para los ficheros log, trace, dump
• Los "benditos" binarios de Oracle (que generalmente aumentan cada año) etc ...

En primer lugar, debe saber la cantidad de "datos sin procesar" que tiene. Con esto me refiero a lo que se convertirá en la tabla de datos. Ya a principios de este siglo, este podía ser el tamaño total de los archivos planos que usaba el sistema anterior, incluso el tamaño de los datos tal como estaba en las hojas de cálculo. Un archivo de exportación de Oracle del sistema también da una idea bastante buena del volumen de datos en bruto. Al carecer de todo esto, entonces necesitas un tamaño aproximado de tus datos brutos. Haz un cálculo esta manera:

• "numero_de_filas * Suma_de_columnas" para tus 10 tablas más grandes. Y no tengas la tentación de sobreestimar, mis multiplicadores te permiten el relleno.

Digamos que ya has hecho esto y son 60GB de datos sin formato para un sistema OLTP. Deja que los chicos de almacenamiento sepan que probablemente querrás 500GB de espacio. Luego mentalmente lo dejarán como "sin consecuencias", ya que probablemente tengan muchos terabytes de almacenamiento. Luego he de aclarar una cosa: No estoy considerando la redundancia en absoluto, en el espacio que se proporciona. 

Si obtienes 5TB de datos brutos para un sistema DW, necesitará alrededor de 12-15 TB de almacenamiento en disco.

Si obtienes más de un Terabyte de datos en bruto para un sistema OLTP o de 10 a 20 Terabytes para un DW, cuando le das cifras a los chicos de almacenamiento , entonces es posible que palidezcan y digan algo como " ¡tienes que estar bromeando!". Esto es parte de por qué el factor de multiplicación para Data Warehouses y sistemas más grandes en general es menor, ya que se lo fuerza a tener más cuidado con el espacio que asigna y cómo lo usa.

La sobrecarga del espacio total en el disco sobre los datos Raw se reduce a medida que la base de datos se agranda por varias razones:

• El tamaño de los binarios de Oracle y el sistema operativo no cambia a medida que la base de datos crece.
• El tamaño del espacio de intercambio no aumenta en línea con la base de datos ya que, en términos generales, si aumenta el tamaño de la base de datos de 100 GB a 1 TB, no puede darse el lujo de aumentar la memoria del sistema de su servidor. Probablemente se duplique.
• Las bases de datos muy grandes tienden a tener algo que las hace grandes, como imágenes o documentos incrustados, que no están indexados. Por lo tanto, la relación de segmentos de tabla a segmentos de índice aumenta.
• Si tienes una base de datos muy grande, empieza a eliminar índices (a menudo aquellos que soportan restricciones) para ayudar al rendimiento de la carga y administración de datos, nuevamente mejorando la proporción de segmentos de tabla a segmentos de índice.
• Las copias de seguridad se vuelven parciales o incrementales para reducir el tamaño y la duración de la copia de seguridad.
• Como se mencionó anteriormente, el tamaño del sistema es tal que se debe tener más cuidado al limpiar las áreas de trabajo, reducir las áreas archivadas de registro de rehacer (esos archivos se comprimen bien) y otras áreas.
• Si las cosas se vuelven extremas usted comienza a alterar PCTFREE y verificando el tamaño de las extensiones, aunque estos problemas de dimensionamiento desaparecen con Oracle ASM.