En memoria no es suficiente

Incluso SAP se ha dado cuenta ahora de que la idea original de mantener todos los datos permanentemente en la memoria, que parecía tan ingeniosamente sencilla, es en parte inviable y en parte insuficiente.

No es viable, por ejemplo, si una base de datos contiene una gran cantidad de datos históricos, cuya carga en memoria provocaría una explosión del coste de la memoria necesaria.

Además, no basta con mantener los datos permanentemente en la memoria, ya que toda base de datos debe garantizar la persistencia de los datos almacenados en ella.

Por lo tanto, es necesario utilizar medios de almacenamiento persistentes y tiene sentido pensar en cómo utilizar este almacenamiento de la forma más eficiente posible. En la base de datos Oracle, existen desde hace muchas versiones dos tecnologías que sirven para este uso eficiente:

Particionamiento y compresión. Y hay dos tecnologías porque la palabra "eficiente" puede tener dos significados distintos.

Lo que va junto: Partición

"Uso eficiente del espacio de memoria" - esto puede significar inicialmente: los datos deben almacenarse de tal forma que tengan que producirse el menor número posible de procesos de E/S al acceder a información que aún no está en la memoria.

"Optimización del almacenamiento de datos" significa entonces que los datos no se almacenan en orden aleatorio (como se hace por defecto), sino teniendo en cuenta qué grupos de datos volverán a necesitarse juntos más adelante.

Particionar una tabla significa dividirla en tales subgrupos. Una partición contiene, por ejemplo, todos los datos que se han insertado en un mes determinado o que están asignados a una rama determinada.

Para los clientes de SAP-on-Oracle, el particionamiento está activado por defecto para SAP BW, por lo que se benefician de él inmediatamente. Sin embargo, Oracle Partitioning está liberado y soportado para todas las aplicaciones SAP NetWeaver. Por tanto, también puede utilizarse en sistemas que no sean BW. El motor de particionamiento de SAP, por ejemplo, está entonces disponible para su implementación.

Compresión

Pero "uso eficiente del espacio de almacenamiento" también puede significar: los datos deben almacenarse de forma que ocupen el menor espacio posible y se pueda frenar el crecimiento gigantesco de las bases de datos.

Considerado a lo largo de varias versiones del software de base de datos, esto significa que la eficiencia del almacenamiento de datos debe aumentar permanentemente para que el mismo stock de datos requiera cada vez menos espacio de almacenamiento de una versión a otra.

Y un requisito adicional es que todo esto ocurra sin que el cliente tenga que pagar el precio de una degradación del rendimiento.

Oracle Database 11g ya se basaba en el concepto de no escribir valores que aparecen más de una vez. Esto se aplica tanto a tablas como a índices. La tasa de compresión que puede alcanzarse depende de las características de los datos y de la aplicación.

Normalmente, los datos de SAP BW (BI) pueden comprimirse más que los de SAP ERP (ECC), y SAP CRM permite un ahorro aún mayor. Por término medio, una base de datos totalmente comprimida con Oracle Database 11g requiere un 55% menos de espacio de almacenamiento en el entorno SAP que la correspondiente base de datos sin comprimir.

Depende de la temperatura

Una pregunta frecuente es: ¿por qué no se ha normalizado el almacenamiento comprimido de datos?

Parte de la respuesta se obtiene observando las tablas de SAP BW que se utilizan para cargar nuevos datos. A uno le gustaría comprimir esas tablas, pero eso retrasaría considerablemente el proceso de carga.

Aquí es donde entra en juego Oracle Database 12c, con la introducción de un nuevo parámetro. En la versión 11g, el usuario puede responder a la pregunta con respecto a cada tabla e índice si este objeto debe comprimirse.

Las respuestas posibles son "Sí" o "No". En la versión 12c, también se pregunta cuándo deben comprimirse los datos nuevos o modificados. Ahora son posibles respuestas del tipo: "Sí, pero sólo dentro de una semana".

Sólo con este nuevo parámetro pueden incluirse en la compresión las tablas necesarias para cargar los datos: Primero se cargan los datos sin comprimir (no se amplía el tiempo de ejecución), que sólo se comprimen después, es decir, en un momento adecuado (compresión diferida).

Esta solución se ha diseñado de forma tan general en Oracle Database 12c que puede utilizarse para implantar una gestión completa del ciclo de vida de la información (ILM). Se basa en dos nuevas características:

• El llamado mapa de calor controla automáticamente la intensidad de uso de los datos. Divide los datos en "datos calientes", que se utilizan con frecuencia para leer y escribir, "datos calientes", que sólo se utilizan para leer, y "datos fríos", que se utilizan muy poco o nada.
• La Optimización Automática de Datos (ADO) permite definir con mayor precisión qué debe entenderse por "caliente", "templado" y "frío" y especificar qué debe ocurrir cuando los datos pasan de calientes a templados o de templados a fríos.

Los datos pueden intercambiarse a otros sistemas de almacenamiento a medida que cambia su "temperatura", un proceso también conocido como "almacenamiento por niveles". Por ejemplo, los datos fríos pueden cambiarse a discos más lentos y, por tanto, más rentables.

Mediante la Optimización Automática de Datos, el administrador de la base de datos define reglas que describen los distintos "estados de temperatura", por ejemplo, que los datos que no se han modificado en 180 días se consideran "fríos".

El "escalonamiento de la compresión" decide además la intensidad de la compresión aplicada; aquí también puede influir el factor tiempo. Por ejemplo, si los datos no se han tocado durante más de 360 días, se aplicará la compresión más fuerte.

"Dentro" es mejor que "cerca".

Estos amplios conceptos y tecnologías de compresión para Oracle Database 12c ofrecen ventajas especialmente en comparación con las soluciones propias de SAP. Así, con Hana, la base de datos en continuo crecimiento también se convierte en un problema.

Para no entorpecer el funcionamiento productivo, SAP recurre al "almacenamiento near-line", que no significa otra cosa que sacar los datos de la base de datos productiva y almacenarlos por separado, aunque "cerca" de la base de datos. Con Oracle Database, los datos pueden mantenerse en la base de datos productiva durante mucho más tiempo, ya que pueden comprimirse considerablemente más.

Oracle Exadata

Quienes deseen llevar aún más lejos la base de datos Oracle están bien servidos por los sistemas de ingeniería de Oracle. El motor de base de datos Exadata, optimizado para el funcionamiento de bases de datos, domina aún más métodos de optimización y mejora de la eficiencia:

Con la compresión columnar híbrida, los sistemas Exadata ofrecen algoritmos de compresión adicionales y más potentes, de modo que es posible el escalonamiento de la compresión en numerosas etapas.

Además, un Exadata amplía la base de datos con "Smart Storage". Esto desplaza parte de los cálculos intensivos de datos del servidor de base de datos al servidor de almacenamiento. Por ejemplo, las tablas e índices que no son relevantes para las consultas pueden filtrarse a nivel de almacenamiento para reducir significativamente la E/S.

De este modo, Oracle Database ofrece un amplio abanico de posibilidades para optimizar y aumentar la eficiencia del almacenamiento de bases de datos. Quienes utilicen estas posibilidades para sus sistemas SAP podrán aprovechar mejor los recursos sin sacrificar el rendimiento de la base de datos.