Particiones transparentes

Los usuarios que trabajan en el cubo de destino no necesitan saber dónde se almacenan los datos, ya que acceden a ellos como si fueran parte de su cubo local.

Figura 9-5 Particiones Transparentes

Esta imagen ilustra cómo un usuario en el destino de datos de partición transparente ve los datos que provienen de tres orígenes de datos.

Debido a que los datos se recuperan directamente del origen de datos, los usuarios acceden a la última versión. Cuando actualizan los datos, sus actualizaciones se vuelven a escribir en el origen de datos. Este proceso significa que otros usuarios del origen de datos y el destino de datos tienen acceso inmediato a esas actualizaciones.

Con una partición transparente, los usuarios del origen de datos y del destino de datos pueden notar un rendimiento más lento a medida que más usuarios acceden a los datos de origen.

Por ejemplo, el DBA de TBC puede utilizar una partición transparente para calcular cada miembro de la dimensión Scenario en un equipo independiente. Este proceso reduce el tiempo transcurrido para el cálculo, al tiempo que proporciona a los usuarios la misma vista de los datos.

Utilice una partición transparente para lograr los siguientes objetivos:

Mostrar a los usuarios la última versión de los datos
Permitir a los usuarios del destino de datos actualizar los datos
Minimizar la huella de espacio en disco

Cuando se crea una partición transparente, el segmento de datos del cubo de destino se borra como #MISSING, ya que se espera que los datos se almacenen en el cubo de origen. Permanece borrado incluso si suprime la partición.

Reglas para Particiones Transparentes

Las particiones transparentes deben seguir estas reglas:

Los datos se almacenan en el cubo de origen. El cubo de destino no almacena ni gestiona ningún dato, sino que actúa como punto de acceso. Si se activa el acceso de escritura, los usuarios que acceden al cubo de destino pueden actualizar los datos del cubo de origen.
Cuando el origen y el destino son cubos de almacenamiento agregado (ASO), no se admite la fusión de datos del cubo de destino al cubo de origen.
Las áreas transparentes compartidas de los esquemas de origen y destino de datos no necesitan ser idénticas, pero debe poder asignar las dimensiones en ellas. Debe indicar a Essbase cómo se asigna cada dimensión y miembro del origen de datos a cada dimensión y miembro del destino de datos.
Los esquemas de origen de datos y destino de datos para las áreas no compartidas no tienen que ser asignables, pero las asociaciones de atributos deben ser idénticas. De lo contrario, los usuarios pueden obtener resultados incorrectos para algunas recuperaciones. Por ejemplo, si el producto 100-10-1010 está asociado al atributo Sabor de uva en el origen, pero el producto 100-10-1010 no está asociado a la uva en el destino, el total de ventas de todos los sabores de uva en Nueva York es incorrecto.
La definición de partición solo debe contener miembros almacenados. No puede utilizar dimensiones o miembros de atributos para definir una partición transparente. Por ejemplo, la dimensión de atributo Tipo de mercado, que está asociada a la dimensión Mercado, tiene miembros Urbanos, Suburbanos y Rurales. No se puede definir una partición en Urbano, Suburbano o Rural.
Si una celda se asigna desde el origen de datos a una base de datos de almacenamiento agregado como destino, todos los dependientes de la celda también se deben asignar a la misma definición de partición.
Puede crear una partición transparente sobre una partición replicada. En otras palabras, puede crear un destino de partición transparente utilizando un origen de partición replicado, como se muestra en esta ilustración:

Figura 9-6 Partición Transparente Válida
Como se muestra a continuación, no puede crear una partición transparente sobre varias otras particiones. En otras palabras, no puede crear un destino de partición transparente a partir de varios orígenes porque cada celda de una base de datos se debe recuperar de una sola ubicación, ya sea el disco local o un disco remoto.

Figura 9-7 Partición Transparente No Válida
Considere cuidadosamente cualquier fórmula que asigne a los miembros en el origen de datos y el destino de datos.

Ventajas de las Particiones Transparentes

Las particiones transparentes pueden resolver muchos problemas de la base de datos, pero las particiones transparentes no siempre son el tipo de partición ideal.

Necesita menos espacio en disco, porque está almacenando los datos en una base de datos.

Los datos a los que se accede desde el destino de datos siempre son la última versión.

Cuando el usuario actualiza los datos en el origen de datos, Essbase realiza esos cambios en el destino de datos.

Las bases de datos individuales son más pequeñas, por lo que se pueden calcular más rápidamente.

La distribución de los datos no es visible para el usuario final ni para las herramientas del usuario final.

Puede cargar los datos desde el origen o el destino de datos.

Desventajas de las particiones transparentes

Si las siguientes desventajas son demasiado graves, considere utilizar particiones replicadas o federadas en su lugar.

Las particiones transparentes aumentan la actividad de la red, lo que resulta en tiempos de recuperación más lentos para los usuarios.

Dado que hay más usuarios que acceden a los datos de origen, el tiempo de recuperación puede ser más lento.

Si el cubo de origen falla, los usuarios tanto del origen como del destino se ven afectados. Por lo tanto, la red y el cubo de origen deben estar disponibles siempre que los usuarios conectados al origen o al destino los necesiten.

Puede realizar algunas operaciones administrativas solo en datos locales. Por ejemplo, si archiva el cubo de destino, Essbase archiva sólo el cubo de destino y no el de origen. Las siguientes operaciones administrativas solo funcionan con datos locales en bases de datos de almacenamiento de bloques:

comando de cálculo CLEARDATA
comando de cálculo DATACOPY
comando EXPORT
comando VALIDATE
Comandos BEGINARCHIVE y ENDARCHIVE

Cuando se realiza un cálculo en una partición transparente, Essbase realiza el cálculo utilizando los valores actuales de los datos locales y los dependientes transparentes. Essbase no vuelve a calcular los dependientes transparentes, porque los esquemas para el origen y el destino pueden ser tan diferentes que dicho cálculo no es preciso. Para calcular todas las particiones, ejecute un comando CALC ALL para cada partición individual y, a continuación, ejecute un comando CALC ALL en el nivel superior utilizando los nuevos valores para cada una.

Considere un ejemplo en el que:

El esquema del cubo de destino contiene una dimensión de mercado con los miembros Este, Oeste, Sur y Central
El esquema del cubo de origen contiene una dimensión Este con los miembros de Nueva York y Nueva Jersey

Si ha intentado calcular el cubo de destino, supondría que East era un miembro de nivel 0. En el cubo de origen, sin embargo, East se deriva agregando Nueva York y Nueva Jersey. Sin embargo, cualquier cálculo en el destino no conocería esta información y no podría reflejar los cambios realizados en Nueva York y Nueva Jersey en la fuente. Para realizar un cálculo preciso, por lo tanto, calcule East en el origen y luego calcule el destino.

Las fórmulas asignadas a los miembros del cubo de origen pueden producir resultados calculados que no sean coherentes con las fórmulas o consolidaciones definidas en el cubo de destino, y viceversa.

Consideraciones de Rendimiento para Particiones Transparentes

Para mejorar el rendimiento de las particiones transparentes, tenga en cuenta las siguientes directrices al crear la partición:

La partición a lo largo de dimensiones densas puede ralentizar considerablemente el rendimiento, ya que las dimensiones densas se utilizan para determinar la estructura y el contenido de los bloques de datos.

Para mejorar el rendimiento, considere la posibilidad de incluir una o más dimensiones ligeras en la definición de área para que el número de bloques necesarios se limite a combinaciones con los miembros ligeros.
Basar particiones transparentes en los valores de atributo de una dimensión puede aumentar el tiempo de recuperación, ya que los atributos están asociados a dimensiones dispersas. En tales casos, la partición en un nivel superior al nivel asociado a los atributos mejora el tiempo de recuperación. Por ejemplo, en la dimensión Product de la base de datos Sample.Basic, si los secundarios 100-10, 200-10 y 300-10 (nivel 0) están asociados a atributos y, a continuación, particionan sus principales 100, 200 y 300 (nivel 1) para obtener un mejor rendimiento de recuperación.
La carga de datos en el cubo de origen desde el cubo de destino puede ralentizar considerablemente el rendimiento. Si es posible, cargue los datos en el origen de datos localmente.
El tiempo de recuperación es más lento porque los usuarios acceden a los datos a través de la red.
Cuando una partición transparente es el destino, considere el uso de estos valores de configuración:
- Para las solicitudes enviadas desde un cubo de origen a un cubo de destino de partición transparente, puede registrar los tiempos de respuesta de las transacciones mediante el valor de configuración ENABLE_DIAG_TRANSPARENT_PARTITION. El registro de estos mensajes es útil cuando se solucionan problemas de tiempos de respuesta demasiado lentos.
- Cuando el destino de partición transparente es un cubo de almacenamiento agregado (ASO), puede especificar el tamaño máximo de la cuadrícula de solicitud y la cuadrícula de respuesta mediante los valores de configuración MAX_REQUEST_GRID_SIZE y MAX_RESPONSE_GRID_SIZE.
Las dimensiones base de partición pueden ralentizar considerablemente el rendimiento.

Cálculo de Particiones Transparentes

Al calcular datos locales que dependen de datos remotos, Essbase debe utilizar el cálculo ascendente. Asegúrese de utilizar una caché de calculadora optimizada en el cubo de destino. Consulte Tamaño de Caché de la Calculadora.

Cuando se realiza un cálculo en una partición transparente, Essbase realiza el cálculo utilizando los valores actuales de los datos locales y los dependientes transparentes. Al calcular datos locales que dependen de datos remotos, Essbase realiza un cálculo ascendente. El cálculo ascendente solo se puede realizar si la caché de calculadora de la base de datos de destino se utiliza correctamente. Consulte Cálculo ascendente y descendente.

El aumento de la memoria asignada a la caché de calculadora mejora en gran medida el rendimiento del cálculo con particiones transparentes. Cuando se inicia un cálculo, un mensaje en el archivo log de la aplicación indica si la caché de calculadora está activada o desactivada en la base de datos de destino. El uso de la caché de calculadora en la base de datos de destino reduce el número de bloques que se solicitan del origen de datos durante el cálculo. Reducir los bloques solicitados, a su vez, reduce el tráfico de red que se genera mediante la transferencia de bloques a través de la red.

Rendimiento Transparente del Cálculo de Particiones

El cálculo de datos en el destino de una partición transparente puede ralentizar el rendimiento cuando Essbase debe recuperar bloques dependientes de la red del origen antes de calcular. Para optimizar los cálculos transparentes, utilice Cálculo dinámico, gestione la caché de calculadora, evite las fórmulas descendentes y evite las fórmulas complejas en los miembros que definen el área.

El rendimiento con cálculos transparentes también puede ralentizarse si Essbase debe realizar un cálculo descendente en cualquier parte del destino de datos que contenga fórmulas de miembros descendentes. Cuando el destino de datos no contiene fórmulas de miembros descendentes, Essbase puede realizar un cálculo ascendente en el destino de datos, que es mucho más rápido.

Cuando Essbase realiza el cálculo en el cubo de origen, siempre puede realizar un cálculo ascendente.

Considere utilizar estas alternativas de cálculo:

Si está absolutamente seguro de que una secuencia de comandos de cálculo de partición de destino no implica acceso a datos remotos, puede utilizar el comando de cálculo SET REMOTECALC OFF en la secuencia de comandos de cálculo para detener los esfuerzos de recuperación de la partición de origen.
Implemente los miembros de Cálculo dinámico como principales de los datos transparentes para que los datos se calculen sobre la marcha cuando se recuperen. Este proceso reduce el tiempo de proceso en batch. Essbase realiza el cálculo solo cuando los usuarios lo solicitan.
Implementar una capa replicada entre los datos transparentes de bajo nivel y los datos locales de alto nivel.

Considere estas estrategias de rendimiento:

Mantenga la partición completamente dentro del área de caché de calculadora, lo que significa que cualquier miembro disperso en la definición de partición debe estar contenido dentro de la caché de calculadora. Por ejemplo, en el cubo Básico de ejemplo, si una definición de partición incluye @IDESC(Este), todos los descendientes de Este deben estar dentro de la caché de calculadora.
Active la caché de calculadora y asígnele una cantidad suficiente de memoria.
No utilice fórmulas complejas en ningún miembro que defina la partición. Por ejemplo, en Sample Basic, la asignación de una fórmula compleja a Nueva York o Nueva Jersey (ambos hijos de East) obliga a Essbase a utilizar el método de cálculo descendente.

Particiones Transparentes y Fórmulas de Miembros

Si los esquemas de destino y origen de datos son idénticos, excepto en el caso de fórmulas de miembros diferentes, asegúrese de que la definición de partición genere los resultados de cálculo que desee.

Por ejemplo, supongamos que el origen de datos y los esquemas de destino de datos contienen una dimensión de mercado con miembros Norte y Sur, y secundarios de Norte y Sur. En el destino de datos, Market se calcula a partir de los datos de los miembros Norte y Sur (y sus hijos) en el origen de datos. Si alguno de estos miembros del origen de datos contiene fórmulas de miembros, se calculan estas fórmulas, lo que afecta al valor calculado de Market en el destino de datos. Estos resultados pueden ser diferentes de cómo se calculan los miembros del Mercado de los miembros Norte y Sur en el objetivo de datos, donde estas fórmulas pueden no existir.

Asegúrese de que las fórmulas que asigne a los miembros en el origen de datos y el destino de datos produzcan los resultados que desee.

Particiones Transparentes y Uso de Puertos

Un puerto se utiliza para cada combinación única de usuario y máquina. Si un usuario define varias particiones transparentes en un servidor, con el mismo nombre de usuario, solo se ocupa un puerto.

En una partición transparente, cuando un usuario (user1) aumenta el detalle en un área del destino que accede a los datos de origen, user1 utiliza el nombre de usuario declarado en la definición de partición (usuario de partición) para acceder a los datos de la base de datos de origen. Este acceso hace que se utilice un puerto adicional porque diferentes usuarios (usuario1 y usuario de partición) se están conectando a la aplicación.

Si un segundo usuario (user2) se conecta a la base de datos de destino y aumenta el detalle para acceder a los datos de origen, user2 también utiliza el nombre de usuario declarado en la definición de partición (usuario de partición). Puesto que el usuario de partición ya está conectado a la base de datos de origen, no se necesita un puerto adicional para el usuario de partición, siempre que user2 acceda a la misma base de datos de origen.