Posts com Tag ‘Performance’

Ola pessoal, tudo bom?

Um assunto bastante requisitado pelos leitores do blog OBIEE Brasil já a algum tempo trata das questões de performance de execução de analises e dashboards no OBIEE 11g.

Começaremos hoje uma série de 4 posts que tratarão deste assunto, a ideia é dar dicas eficientes e simples para que vocês possam coloca-las em pratica no seu dia-a-dia.

Nesta primeira parte trataremos as questões relacionadas a instalação e parametrização de seu ambiente.

Quase que invariavelmente, quando sou chamado para realizar um atendimento relacionado a baixa performance do ambiente me deparo com problemas na instalação e parametrização do produto OBIEE.

Os binários de instalação do OBIEE, quando disponibilizados pela Oracle, seguem padrões de configuração para garantir que a aplicação funcionará com os mínimos recursos disponíveis.

É imprescindível que após esse processo de instalação, as customização, ou seja, as adaptações necessárias sejam efetivamente realizadas no OBIEE. Isso garante a melhor eficiência da ferramenta para o hardware e software disponibilizados.

DICA 1 – Matriz de Certificação

Garanta que seu ambiente esteja de acordo com a especificação da matriz de certificação do produto instalado.

No site da Oracle, no link abaixo, encontramos a matriz de certificação da última versão disponível do OBIEE 11g (11.1.1.7.0).

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

Como podem ver abaixo, lá temos diversas informações, desde as versões de S.O. homologadas pela fabricante, até as versões de browser que podemos utilizar para acessar nossas analises e dashbords.

matriz_certificacao

 

 

 

 

 

 

SEMPRE devemos seguir essas premissas no planejamento da construção de nossos ambientes, caso não seguirmos isso fielmente podemos ter diversos problemas, desde uma funcionalidade comprometida, até mesmo a não assistência por parte do Suporte Oracle por conta de um planejamento mal realizado, ou seja, um ambiente não homologado.

DICA 2 – Instalação do OBIEE

Após definirmos quais produtos serão utilizados e principalmente, quais versões serão adotadas, devemos preparar nosso S.O. para receber a aplicação. Em outras palavras, precisamos configurar/instalar as ferramentas que são pre-requisitos para o funcionamento do OBIEE.

No roadmap de instalação que pode ser acessado no link abaixo, temos o passo-a-passo que deverá ser seguido para a construção de um ambiente de OBIEE.

http://docs.oracle.com/cd/E28280_01/bi.1111/e10539/c1_overview.htm#BIEIG336

Qualquer um dos passos que deixarem de executar pode lhes trazer problemas, que neste caso vão desde a impossibilidade de conclusão da instalação do produto até um problema mais silenciosos e de difícil detecção.

Sempre busquem seguir as documentações oficiais da Oracle ou de seus colaboradores (blogs oficiais, blogs de ACE´s e etc)

Obs.: Se atente ao modo de instalação escolhido, cada modo tem uma finalidade especifica, por ex.: uma instalação simples é indicada para aprendizado e demonstração, não para ambientes corporativos.

DICA 3 – Parametrização e Tunning da Aplicação OBIEE

Por ultimo, após concluir sua instalação, garanta que a aplicação esteja utilizando todo o poder do software e hardware disponibilizados para tal finalidade.

Como o OBIEE 11g roda em cima do servidor de aplicação Weblogic (diferente da versão 10g que era implantado no Oracle Application Server ou OC4J), temos que prever neste passo de otimização de ambiente, além da otimização do OBIEE, também a otimização do Weblogic Server.

Sempre após a instalação de um ambiente, se certifique de aplicar as configurações de tunning descritas no tech note id: 1333049.1

https://blogs.oracle.com/proactivesupportEPM/entry/wp_obiee_tuning_guide

O whitepaper acima lhe trás parâmetros básicos para otimização de seu ambiente, digo básico, pois TUDO pode ser alterado de acordo com o que “você tiver em mãos”

Nesta “doc” podemos conferir as melhores práticas para:

– Otimização de suas JVM´s;

– Parametros de Tunning para o Weblogic Server;

– Parametros de Tunning para os componentes do OBIEE (OBIS, OBIPS, OBI Java Host e etc);

– Parametros de Tunning de SO e muito mais…

Até a próxima semana com a parte 2 desta série de posts.

Grande Abraços

Felipe Idalgo

 

 

Anúncios

Olá Pessoal,

Segue o script de apoio a minha palestra sobre tunning do OBIEE 11g no CONABI 2014.

Lembrando que temos diversos parâmetros que podem ser alterados para uma melhor utilização do OBIEE nos diversos ambientes possíveis, cada ambiente tem sua particularidade e é importante sempre observarmos as diferenças entre eles.

Para fazer download do material basta clicar no link abaixo

Tunning_OBIEE11g_SOeOBIPS_CONABI

Abraços

Felipe Idalgo

Formação OBIEE 11g (online)

Formação OBIEE 11g (online)

Sabe aquele relatório que cisma em NÃO executar com uma performance compatível com o seu banco de dados? Seus dashoboards demoram um “zilhão” de anos para abrirem e a navegação entre as páginas é péssima? O OBIEE está inutilizável mesmo com um servidor “parrudo”? Saibam quais os principais erros ao se implementar o Oracle Business Intelligence EE 11g (OBIEE 11g) e como corrigi-los a tempo para salvar seu projeto.

Eu, Felipe Idalgo juntamente com o INBA, convidamos você a participar desta super palestra com muitas dicas, truques e macetes.

LOCAL: SALA ONLINE (Se inscreva, é gratuito) DATA: 20/Agosto Horário: das 16h as 17h

CONABI

O Oracle BI Server é um gerador de consultas SQL’s e o sucesso de um projeto de OBIEE depende muito do retorno destas consultas físicas executadas diretamente no banco.

A consulta SQL retorna o resultado corretamente e no menor tempo possível?

Os usuários finais não veem os SQL’s físicos, e nem devem ver, porem muitas vezes, os próprios desenvolvedores também não dão a devida atenção para elas tambem, acreditam não poder interferir, “o produto gera automaticamente estas SQL’s, não podem ser modificadas”. Isto não é verdade.

A qualidade destas SQL’s físicas é talvez, a questão mais importante de um projeto OBIEE, o desempenho deve ser sempre prioridade, mesmo que a apresentação seja prejudicada por isto.

Aceitar sacrifícios na apresentação da informação em prol ao desempenho durante o início do projeto é mais fácil do que depois, quando os gráficos e dashboards já estão sendo apresentados para o usuário e por causa de problemas de desempenho ser necessário alterá-los.

Os objetivos desde o início, devem ser a busca por resultados corretos, rápidos e fáceis de acessar.

Resultados corretos parecem óbvios, mas muitas vezes ignorados, usuários finais podem obter resultados errados por anos sem perceber nada. A análise das consultas SQL’s físicas podem identificar este tipo de problemas, como filtros ausentes, ou em excesso, tabelas indevidas incluídas nas análises, etc.

Resultados rápidos muitas vezes, não é o foco dos desenvolvedores no inicio do projeto. As expectativas dos usuários não são claras quanto ao desempenho, querem algo “aceitável”. A preocupação com desempenho só ocorre no final ou quando os problemas estão estourando em produção. É inútil ter um dashboard esteticamente bem apresentado se cada clique leva 2 minutos para retornar a informação.

Resultados fáceis ou facilidade na navegação e na construção das análises é o foco principal de todos no inicio do projeto (usuários e desenvolvedores) e é muitas vezes a principal causa dos problemas. O impacto sobre o desempenho deve ser sempre avaliado quando se discute com os usuários a apresentação das informações.

Vou demonstrar como visualizar a SQL física de uma determinada análise feita no OBIEE.

Vamos identificar a SQL Física da análise abaixo:

UNMyxx4GdIrycFHXVEO5P2ER_uR4nO1idE_WamCEROTt6csutbNdt9S-Y_wLQJRwgY8Rg2Pt3kuCDJOtJbd56DKWoY5NYVV6k9quj57dBr2wghZDuUk

Primeiramente capturamos a SQL Lógica, através da aba Avançado.

UIO4Zd3cp4E3FRVzEq-ifVVmVGLnWHtBjonG56dUST8QyxpD6sgUqpMw1aYeMAlF-r8UfSn5JjTTzMpG8-EAoSww0nr9zmfBJSwf9OC1yVeeIZTgR6Q

Cclick em Administração > Emitir SQL.

n2gdVsr7A9fvFykESssXMyNNsTiRv_tYGDbSZ67o9HzKxjeC3ZAg3TVvuxpdE967O2jntugFlFEpm1C83RmTlgijZU67n7IShjRte3YiobOnA-dP-xc

Cole a SQL Lógica aqui, desmarque a utilização de Cache e click em Emitir SQL.

o-tUwd3iv4zd1HOuk5WdQpOcKW7y08Qf9RJOwT2RIUQXE5_0SXEDYY_lcmEX9qLt8rNqVXEirV3Ehg7ETR4DOw1Dxy5hcHF8smT0F-El-MUofKaq258

O resultado será uma lista com os dados resultantes da consulta e no final um botão para verificar o log.

Este log é apresentado a seguir.

Abs.

Alan Viegas

 

banner_treinamento

Ola pessoal, novamente estou aqui para falar de um recurso muito interessante do OBIEE.

O cache é um recurso importante para melhorar o tempo de resposta nas consultas do OBIEE, quando ativado, todas as consultas realizadas no banco são armazenadas no servidor do obiee em arquivos chamadas de entradas de cache, com os dados desta consulta. Quando a mesma consulta é feita novamente o OBIEE não acessa o banco novamente, ele utiliza as entradas de cachê para retornar o resultado.

Para ativar o cache é necessário realizar os seguintes passos:

Ativar o cache nas próprias tabelas da camada física, uma a uma.

bEXPLlAFQ3iAw1jLvFau6JxfJXDar53y90XoSTvKkMzKmI8tFpdIF0B2-CcGO8v6CNgkm7vWlN0rvcG_-A4VyGNJrMKlM89gB11vfK9Z-C_MmRy5l7g

Aqui temos as seguintes opções:

Cache nunca expira

Selecionando esta opção, as entradas de cache não expiram mais para esta tabela. É útil quando a tabela é importante para um grande número de consultas, por exemplo, uma tabela de CEP que seja muito utilizada,. Mantê-la em cache indefinidamente pode melhorar o desempenho destas consultas.

Porem esta escolha significa que o cache desta tabela permanecerá sempre válido, somente uma intervenção manual como alterações na sua estrutura na camada semântica ou o uso de uma tabela de Event Pooling (veremos mais a frente) pode invalidar as entradas deste cachê.

Cache persistente por tempo

Define quanto tempo às entradas de cache devem persistir, antes de expirar, em outras palavras, o cache é invalidado após um determinado tempo definido pelo usuário.

Esta definição é útil em tabelas que são atualizadas com muita frequência.

e8HicLNwjN0zNCRtey4ApdSOlzwgw7XGf4_rMHXIcxZoKfgT4V6Y7Bk-pX475XPoBDu3FDUFdPqCkfKQ0eGkO_vYROkEL8YOBriMlPTiJyyk5lyw35k

Alem disto é necessário ativar no Servidor o serviço responsável pelo gerenciamento deste cache. Isto é feito através do Enterprise Manager em Business Intelligence > coreapplication > Gerenciamento de Capacidade > Desempenho

9tO9WJnjb22Soc2fyiQHs4RwsJfvKf_0mUH58qgmynwEeOIGosiqy8EN6_uYL-91iaub7WpONwGx4W7hUWs0rHIow6fTJkyuW12Ul0FxSZcqD4Gb0sc

Click em Bloquear para Edição e ative o cache , aqui é possível definir o tamanho máximo deste cache, e a quantidade máxima de entradas.

Oj7nNZAl0RguwOD1LtJNWnNMSd7--NCb8H0xwcMc4PFVNVWybXG2WcP-eQ8K5_wUiisM6c_u_AKBtWi14VYSp6mRDAiMRWohoPA8DB6ocWmGkI4Qr5c

Ative as alterações e reinicialize os serviços para que o cache seja ativado. As entradas de cache são geradas no servidor do BIEE no diretório:

%ORACLE_HOME%/instances/instance1/bifoundation/OracleBIServerComponent/coreapplication_obis1/cache

O problema é que muitas vezes é necessário ter um controle maior sobre as atualizações destas entradas de cache, neste caso é necessário implementar o Event PollingTable.

O servidor do Oracle BI utiliza uma tabela de eventos como uma maneira de ser notificado que uma ou mais tabelas na camada física foram atualizadas. Ou seja, cada linha que é adicionada nesta tabela de eventos determina um evento único de atualização em uma determinada tabela da camada física.

O Oracle BI Server lê estas linhas, verifica que uma determinada tabela física foi atualizada recentemente e invalida todas as entradas de cache que fazem referencia a esta tabela.

Desta forma é possível incluir no final do seu processo de ETL, por exemplo, um procedimento de carga desta tabela de eventos, indicando quais tabelas da camada física foram atualizadas ou recarregadas.

O Oracle BI Server irá verificar esta tabela de tempo em tempo (período determinado por você) se alguma tabela da camada física foi atualizada e invalida ou não o cache.

Vamos utilizar em nosso exemplo a tabela COUNTRIES do schema HR.

Com o cache ativado, todos os relatórios em cima desta tabela serão executados pelo menos uma vez acessando diretamente o banco de dados e depois, nas próximas execuções, o acesso será feito em cache, melhorando assim a desempenho.

Vamos manter esta tabela com o cache nunca expira.

dXxd7Yq3e6_hRMpoKBY9R7DnaqYfo8749NW2XobBEbzg6DSYBeGJI9nnTizVLv0nHABn8lllKcc6rwMXxOTru95Uk4tw_UDzx7i6Z8sUTe4mt7kMXFk

Para criar a tabela de evento vamos utilizar o script fornecido pela Oracle localizado no diretório do servidor de BI.

%ORACLE_HOME%/instances/instance1/bifoundation/OracleBIServerComponent/coreapplication_obis1/schema/ SAEPT.Oracle.sql

O conteúdo deste script é:

drop table S_NQ_EPT ;

create table S_NQ_EPT (

UPDATE_TYPE DECIMAL(10,0) DEFAULT 1 NOT NULL,

UPDATE_TS DATE DEFAULT SYSDATE NOT NULL,

DATABASE_NAME VARCHAR2(120) NULL,

CATALOG_NAME VARCHAR2(120) NULL,

SCHEMA_NAME VARCHAR2(120) NULL,

TABLE_NAME VARCHAR2(120) NOT NULL,

OTHER_RESERVED VARCHAR2(120) DEFAULT NULL NULL

) ;

kZfbME9fc33CV6xHr2OE3sEbHGTCxMZa4-RboahfpcffUHDGmnvmG7_Z8d2V06xMqn0HNSYh7btrXDDcT7AKtVmk-AED-oFpWAXWq_RJ930lGAV3OaU

Esta tabela deve ser mapeada na camada física do OBIEE.

2b_sXjXEK36q18PeBUbQ4DvvXdQq8pTNlBi3gdSqogcpYKUd2-J6TxGFVMx9KQLEBYR8Qs-lucBQu14nxvoRAlpE1IE_4IyB8DgZx_AfgIHpNexOPe0

Ativar evento de atualização de Cache no Administrator do BIEE

Em Tools > Utilities > Oracle BI Event Tables – Selecionar a tabela de eventos e vamos setar a frequência em intervalos de 10 minutos., ou seja de 10 em 10 minutos o Oracle BI Server verificará a tabela de eventos.

zEqtvz14OfueDcZoiMM7o9OcE4s7FhnDy_wSBD9MszgZiyfxfPA9qO1KUxSZFB4RlYmpXYjMocESxPB911fgioWkXHF0wDPGtcD_oz3MRmXkr3C7-C8

Confirme e salve as alterações.

O ícone da tabela muda, identificando que é uma tabela de eventos.

ttLIhbpkEm8q04dxoVzl66ze3PQzW_18DBkVCoLv3Kh6G9hmyIcG5xAl1ItI3cnsrvcEKU2GfDea7sGmKk6ZLpOtA5sJjKXL7HNK9RBSvA2lSgAN7bU

Vamos inserir uma linha nesta tabela, identificando que a tabela COUNTRIES foi atualizada.

UIGrpSsw_CzUitXz_EPDZMhKN0cxgfNkGr8JDr3hiOq-G5TA5fjLZojs4hTHfnzKVCLs1qHSQj4q7gQ1GvWjnFfNRYxL74VxxL7RvS-03iHvRxeV_yc

Após o próximo intervalo configurado o Oracle BI Server pesquisa a tabela de eventos e limpa as entradas de cache referente à tabela COUNTRIES.

É possível verificar isto no diretório abaixo:

%ORACLE_HOME%/instances/instance1/bifoundation/OracleBIServerComponent/coreapplication_obis1/cache

A entrada na tabela de eventos S_NQ_EPT também é truncada após o intervalo de pesquisa.

Usando uma tabela de eventos é a maneira mais precisa par a invalidar as entradas de cache obsoletos, provavelmente o método mais confiável. No entanto como existe um intervalo de pesquisa definido na configuração, existe o risco ainda de o cache não estar totalmente atualizado durante este intervalo, ocasionando o risco de dados obsoletos serem consultados.

Até a próxima..

Alan