Partições Transparentes

Os usuários que trabalham no cubo de destino não precisam saber onde os dados estão armazenados, porque eles os acessam como se fizessem parte do cubo local.

Figura 9-5 Partições Transparentes

Esta imagem ilustra como um usuário no destino de dados de partição transparente vê dados provenientes de três origens de dados.

Como os dados são recuperados diretamente da origem de dados, os usuários acessam a versão mais recente. Quando eles atualizam os dados, suas atualizações são gravadas de volta na origem de dados. Esse processo significa que outros usuários na origem de dados e no destino de dados têm acesso imediato a essas atualizações.

Com uma partição transparente, os usuários na origem de dados e no destino dos dados podem notar um desempenho mais lento à medida que mais usuários acessam os dados de origem.

Por exemplo, o DBA no TBC pode usar uma partição transparente para calcular cada membro da dimensão Scenario em um computador separado. Esse processo reduz o tempo decorrido para o cálculo, ao mesmo tempo em que fornece aos usuários a mesma visualização dos dados.

Use uma partição transparente para atingir os seguintes objetivos:

Mostrar aos usuários a versão mais recente dos dados
Permitir que usuários no destino de dados atualizem dados
Minimizar espaço em disco

Quando você cria uma partição transparente, a fatia de dados no cubo de destino é limpa para #MISSING, pois espera-se que os dados sejam armazenados no cubo de origem. Ele permanece limpo mesmo se você excluir a partição.

Regras para Partições Transparentes

As partições transparentes devem seguir estas regras:

Os dados são armazenados no cubo de origem. O cubo de destino não armazena nem gerencia dados, mas atua como um ponto de acesso. Se o acesso de gravação estiver ativado, os usuários que acessam o cubo de destino poderão atualizar dados no cubo de origem.
Quando a origem e o destino são cubos de armazenamento agregado (ASO), a mesclagem de dados do cubo de destino para o cubo de origem não é suportada.
As áreas transparentes compartilhadas dos contornos da origem de dados e do destino de dados não precisam ser idênticas, mas você deve ser capaz de mapear as dimensões neles. Você deve informar ao Essbase como cada dimensão e membro na origem de dados é mapeado para cada dimensão e membro no destino de dados.
Os contornos da origem de dados e do destino de dados para as áreas não compartilhadas não precisam ser mapeáveis, mas as associações de atributos devem ser idênticas. Caso contrário, os usuários poderão obter resultados incorretos para algumas recuperações. Por exemplo, se o produto 100-10-1010 estiver associado ao atributo Sabor de Uva na origem, mas o produto 100-10-1010 não estiver associado à Uva no destino, o total de vendas de todos os sabores de Uva em Nova York estará incorreto.
A definição de partição deve conter apenas membros armazenados. Não é possível usar dimensões de atributo ou membros para definir uma partição transparente. Por exemplo, a dimensão de atributo Tipo de Mercado, associada à dimensão Mercado, tem membros Urbanos, Suburbanos e Rurais. Não é possível definir uma partição em Urbano, Suburbano ou Rural.
Se uma célula for mapeada da origem de dados para um banco de dados de armazenamento agregado como destino, todos os dependentes da célula também deverão ser mapeados para a mesma definição de partição.
Você pode criar uma partição transparente sobre uma partição replicada. Em outras palavras, você pode criar um destino de partição transparente usando uma origem de partição replicada, conforme mostrado nesta ilustração:

Figura 9-6 Partição Transparente Válida
Como ilustrado abaixo, não é possível criar uma partição transparente sobre várias outras partições. Em outras palavras, não é possível criar um destino de partição transparente a partir de várias origens porque cada célula de um banco de dados deve ser recuperada de apenas um local — seja o disco local ou um disco remoto.

Figura 9-7 Partição Transparente Inválida
Considere cuidadosamente quaisquer fórmulas que você atribuir aos membros na origem de dados e no destino de dados.

Vantagens de Partições Transparentes

Partições transparentes podem resolver muitos problemas de banco de dados, mas partições transparentes nem sempre são o tipo de partição ideal.

Você precisa de menos espaço em disco porque está armazenando os dados em um banco de dados.

Os dados acessados no destino de dados são sempre a versão mais recente.

Quando o usuário atualiza os dados na origem de dados, o Essbase faz essas alterações no destino de dados.

Os bancos de dados individuais são menores, para que possam ser calculados mais rapidamente.

A distribuição dos dados é invisível ao usuário final e às ferramentas do usuário final.

Você pode carregar os dados da origem ou do destino dos dados.

Desvantagens de Partições Transparentes

Se as desvantagens a seguir forem muito graves, considere o uso de partições replicadas ou federadas.

Partições transparentes aumentam a atividade da rede, resultando em tempos de recuperação mais lentos para os usuários.

Como mais usuários estão acessando os dados de origem, o tempo de recuperação pode ser mais lento.

Se o cubo de origem falhar, os usuários na origem e no destino serão afetados. Portanto, a rede e o cubo de origem devem estar disponíveis sempre que os usuários conectados à origem ou ao destino precisarem deles.

Você só pode executar algumas operações administrativas em dados locais. Por exemplo, se você arquivar o cubo de destino, o Essbase arquivará somente o destino e não o cubo de origem. As seguintes operações administrativas só funcionam em dados locais em bancos de dados de armazenamento em blocos:

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

Quando você executa um cálculo em uma partição transparente, o Essbase executa o cálculo usando os valores atuais dos dados locais e dependentes transparentes. O Essbase não recalcula os dependentes transparentes, porque os contornos da origem e do destino podem ser tão diferentes que esse cálculo é impreciso. Para calcular todas as partições, emita um comando CALC ALL para cada partição individual e execute um comando CALC ALL no nível superior usando os novos valores para cada uma.

Considere um exemplo em que:

O outline do cubo de destino contém uma dimensão de Mercado com membros Leste, Oeste, Sul e Central
O esboço do cubo de origem contém uma dimensão Leste com membros de Nova York e Nova Jersey

Se você tentasse calcular o cubo de destino, assumiria que East era um membro de nível 0. No cubo de origem, no entanto, East é derivado pela adição de Nova York e Nova Jersey. Qualquer cálculo no alvo, no entanto, não saberia dessas informações e não poderia refletir as mudanças feitas em Nova York e Nova Jersey na fonte. Para realizar um cálculo preciso, calcule East na origem e, em seguida, calcule o destino.

As fórmulas atribuídas aos membros no cubo de origem podem produzir resultados calculados que são inconsistentes com fórmulas ou consolidações definidas no cubo de destino e vice-versa.

Considerações de Desempenho para Partições Transparentes

Para melhorar o desempenho de partições transparentes, considere as seguintes diretrizes ao criar a partição:

O particionamento ao longo de dimensões densas pode retardar muito o desempenho, porque dimensões densas são usadas para determinar a estrutura e o conteúdo dos blocos de dados.

Para melhorar o desempenho, considere a inclusão de uma ou mais dimensões esparsas na definição de área para que o número de blocos necessários seja limitado a combinações com os membros esparsos.
Basear partições transparentes nos valores de atributo de uma dimensão pode aumentar o tempo de recuperação, porque os atributos estão associados a dimensões esparsas. Nesses casos, o particionamento em um nível superior ao nível associado aos atributos melhora o tempo de recuperação. Por exemplo, na dimensão Produto do banco de dados Sample.Basic, se os filhos 100-10, 200-10 e 300-10 (nível 0) estiverem associados a atributos, particione os pais 100, 200 e 300 (nível 1) para obter melhor desempenho de recuperação.
O carregamento de dados no cubo de origem do cubo de destino pode reduzir bastante o desempenho. Se possível, carregue os dados na origem de dados localmente.
O tempo de recuperação é mais lento porque os usuários acessam os dados pela rede.
Quando uma partição transparente for o destino, considere o uso destas definições de configuração:
- Para solicitações enviadas de um cubo de origem para um cubo de destino de partição transparente, você pode registrar os tempos de resposta da transação usando a definição de configuração ENABLE_DIAG_TRANSPARENT_PARTITION. O registro dessas mensagens é útil ao solucionar problemas de tempos de resposta muito lentos.
- Quando o destino da partição transparente for um cubo de armazenamento agregado (ASO), você poderá especificar o tamanho máximo da grade de solicitação e da grade de resposta, usando as definições de configuração MAX_REQUEST_GRID_SIZE e MAX_RESPONSE_GRID_SIZE.
O particionamento de dimensões base pode reduzir bastante o desempenho.

Cálculo de Partições Transparentes

Ao calcular dados locais que dependem de dados remotos, o Essbase deve usar o cálculo ascendente. Certifique-se de usar um cache de calculadora otimizado no cubo de destino. Consulte Tamanho do Cache da Calculadora.

Quando você executa um cálculo em uma partição transparente, o Essbase executa o cálculo usando os valores atuais dos dados locais e dependentes transparentes. Ao calcular dados locais que dependem de dados remotos, o Essbase executa um cálculo de baixo para cima. O cálculo de baixo para cima só poderá ser feito se o cache da calculadora no banco de dados de destino for usado corretamente. Consulte Cálculo de Cima para Baixo e de Cima para Baixo.

Aumentar a memória atribuída ao cache da calculadora melhora muito o desempenho do cálculo com partições transparentes. Quando um cálculo é iniciado, uma mensagem no arquivo de log do aplicativo indica se o cache da calculadora está ativado ou desativado no banco de dados de destino. O uso do cache da calculadora no banco de dados de destino reduz o número de blocos que são solicitados da origem de dados durante o cálculo. A redução dos blocos solicitados, por sua vez, reduz o tráfego de rede gerado pela transferência de blocos pela rede.

Desempenho do Cálculo da Partição Transparente

O cálculo de dados no destino de uma partição transparente pode diminuir o desempenho quando o Essbase deve recuperar blocos dependentes na rede da origem antes de calcular. Para otimizar cálculos transparentes, use Cálculo Dinâmico, gerencie o cache da calculadora, evite fórmulas de cima para baixo e evite fórmulas complexas em membros que definem áreas.

O desempenho com cálculos transparentes também poderá ficar lento se o Essbase tiver que executar um cálculo de cima para baixo em qualquer parte do destino de dados que contenha fórmulas de membros de cima para baixo. Quando o destino de dados não contém fórmulas de membros de cima para baixo, o Essbase pode executar um cálculo de baixo para cima no destino de dados, o que é muito mais rápido.

Quando o Essbase executa o cálculo no cubo de origem, ele sempre pode executar um cálculo de baixo para cima.

Considere usar estas alternativas de cálculo:

Se você tiver certeza absoluta de que um script de cálculo de partição de destino não envolve acesso a dados remotos, poderá usar o comando de cálculo SET REMOTECALC OFF no script de cálculo para interromper os esforços de recuperação da partição de origem.
Implemente os membros do Cálculo Dinâmico como pais dos dados transparentes para que os dados sejam calculados instantaneamente quando forem recuperados. Esse processo reduz o tempo de processamento em batch. O Essbase só executa o cálculo quando os usuários o solicitam.
Implemente uma camada replicada entre os dados transparentes de baixo nível e os dados locais de alto nível.

Considere estas estratégias de desempenho:

Mantenha a partição totalmente dentro da área de cache da calculadora, o que significa que qualquer membro esparso na definição da partição deve estar contido no cache da calculadora. Por exemplo, no cubo Sample Basic, se uma definição de partição incluir @IDESC(East), todos os descendentes de East deverão estar dentro do cache da calculadora.
Ative o cache da calculadora e atribua uma quantidade suficiente de memória a ela.
Não use fórmulas complexas em nenhum membro que defina a partição. Por exemplo, em Sample Basic, atribuir uma fórmula complexa a Nova York ou Nova Jersey (ambos filhos do Leste) força o Essbase a usar o método de cálculo de cima para baixo.

Partições Transparentes e Fórmulas de Membros

Se os contornos do destino de dados e da origem de dados forem idênticos, exceto para fórmulas de membros diferentes, certifique-se de que a definição de partição produza os resultados de cálculo desejados.

Por exemplo, suponha que os contornos da origem de dados e do destino de dados contenham uma dimensão de Mercado com membros Norte e Sul e filhos de Norte e Sul. No destino de dados, o Mercado é calculado a partir dos dados para os membros Norte e Sul (e seus filhos) na origem de dados. Se algum desses membros na origem de dados contiver fórmulas de membros, essas fórmulas serão calculadas, afetando o valor calculado de Mercado no destino de dados. Esses resultados podem ser diferentes de como o membro do Mercado é calculado a partir dos membros Norte e Sul no alvo de dados, onde essas fórmulas podem não existir.

Certifique-se de que todas as fórmulas atribuídas aos membros na origem de dados e no destino de dados produzam os resultados desejados.

Partições transparentes e uso de porta

Uma porta é usada para cada combinação exclusiva de usuário e máquina. Se um usuário definir várias partições transparentes em um servidor, usando o mesmo nome de usuário, somente uma porta será ocupada.

Em uma partição transparente, quando um usuário (user1) faz drill em uma área no destino que acessa dados de origem, user1 está usando o nome de usuário declarado na definição de partição (usuário da partição) para acessar os dados do banco de dados de origem. Esse acesso causa o uso de uma porta adicional porque diferentes usuários (usuário 1 e usuário da partição) estão se conectando ao aplicativo.

Se um segundo usuário (user2) se conectar ao banco de dados de destino e fizer drill-down para acessar os dados de origem, user2 também usará o nome de usuário declarado na definição da partição (usuário da partição). Como o usuário da partição já está conectado ao banco de dados de origem, uma porta adicional não é necessária para o usuário da partição, desde que user2 esteja acessando o mesmo banco de dados de origem.