Menu de navegação

[mpvargasParticipante]

Caros Amigos,
Li alguma coisa sobre esse parametro, mas fiquei com algumas duvidas…
Alguem poderia me passar um resumo com as principais caracteristicas desse parametro qdo configurado como FORCE, SIMILAR ou EXACT.

Aproveitando o topico, gostaria de saber se alguem já criou o banco como DW e qual a diferença que existe, digo na administração.

Obrigado

[PetersonParticipante]

Olha cara, se não estou enganado, esse parâmetro rege o aproveitamento de código no cache. Caso esteja definido como EXACT, o código solicitado deve ser exatamente igual ao que encontra-se em cache. Ex: Se você dá um (select codigo from tabela where codigo =1) e no cache já tem uma instrução (select codigo from tabela where codigo =2), o sistema não aproveitará o código contido no cache porque eles não são exatamente iguais. Mas se o parâmetro está definido como SIMILAR ele aproveita esse código.

Mas… vale a pena aprofundar o estudo, não tenho plena certeza que seja isso.
Se alguém tiver uma definição melhor também gostaria de saber.

att,

Peterson

[vjaquinoParticipante]

Olá mpvargas,

tem um post bem detalhado com exemplos:
http://oracle-online-help.blogspot.com/ … se-it.html

[ ]’s
Valter Aquino
Visite meu blog:
http://valteraquino.blogspot.com

[CleitonHanzenParticipante]

Opá…

Já trabalhei muito com esse parâmetro e vou te falar que não tive boas experiências (com ele diferente de EXACT)

A função básica do parâmetro (conforme o Vieri falou), é controlar a “forma” que o banco irá re-utilizar os SQL’s compilados em memória.

Os valores aceitos são EXACT, SIMILAR ou FORCE

Exact: Somente será reaproveitado se o SQL for 100% idêntico ao que está em memória, inclusive os literais
Exemplo: “select * from dual where x=1” é diferente de “select * from dual where x=2”

Similar: Permite que os valores literiais sejam diferentes, existe meio que uma “conversão interna” de valores literias para bind variáveis, no exemplo acima seria feito somente um “hard parse” da consulta.

Force: O Oracle “força” todas as consultas a utilizarem bind variáveis o que reduz bastante a quantidade de re-parses no banco, porém, o grande problema é que, as consultas ficam com planos de execução “estáticos”, ou seja, todas as consultas subsequentes executadas e que re-aproveitam o SQL em memória também irão usar o mesmo plano de execução.

A recomendação da Oracle é deixar este parâmetro como EXACT e você “forçar” os desenvolvedores a utilizar bind variáveis ( o que quase nunca acontece).

[mpvargasParticipante]

OK Galera
Muito Obrigado pela ajuda de todos

Com relação ao DW alguem pode me tirar uma duvida?
A forma de administrar é diferente ou funciona da mesma forma que um banco para fins gerais?
Obrigado

[VitorLeandroParticipante]

Fala Vargas,

A administração de um banco DW é muito diferente de um OLTP. A começar pelo “o quê” monitorar. Em Data Warehouse você precisa monitorar as cargas (ETL) e a geração de relatórios, cubos e manipulação ROLAP.

ETL (Extract Transform and LOAD): Retira os dados de uma origem (arquivos texto, OLTPs, Excel) e carrega na área de stage, onde ocorrerá diversos joins entre origens e dimensões cadastrais a fim de se desnormalizar os dados e carrega-los em uma arquitetura DW EX: Star Squema.
External Tables, sqlloader, Merge, sempre ajudam na tarefa.

Após a transformação, os dados são entregues em tabelas de Fato (Onde existem as métricas, valores, quantidades) e as dimensões (Cadastros, hierarquias, slow changes…)

Dica: O processo de carga normalmente decorre em dezenas de milhares de atualizações, inserções, deletes e em um curtíssimo espaço de tempo. Algumas tabelas com as Stage1 e outras não históricas, não precisam gerar logs (NOLOGGING). Também monitore o Logswitch dos seus redos nos momentos de carga, podem estar atrasando o processo por dimensionamento incorreto!

Após monitorar e otimizar o ETL, basta monitorar a extração do DW pelo cliente propriamente dito, seja a execução de um relatório, execução de cubo… Materialized Views sempre ajudam neste processo!

Em relação a disponibilidade, veja que se seu banco der problema hoje, você pode apenas restaurar o backup FULL de ontem e reprocessar a carga de hoje… Restore é bem flexível em DW.

Outra dica são os FULL Scans, não se assuste com eles! Algumas consultas vão realmente ter que percorrer os 100 milhões de registros da tabela. Neste caso, um conhecimento em modelagem DW, junto com Aggregation Tecniques, MViews e uma boa briga com os desenvolvedores de BI, serão uma mão na roda!

Se tiver alguma dúvida, poste aí que eu lhe ajudo!

Espero ter ajudado!

[mpvargasParticipante]

Vitor, Obrigado pela ajuda.
Minha dúvida tb é relacionada a administração do banco.
Criação de tablespaces, tabelas, views, etc.
Permissões, regras, acessos…
Funciona da mesma forma ou tem alguns detalhes proprios do DW?

[VitorLeandroParticipante]

Talves seja interessante você estudar algo sobre parallelismo, particionamento, compressao e db_cache_size. Poderá melhorar as full scans, performance e economia de espaço.

Do resto não muda muito, mas depende muito da arquitetura utilizada.

[Autor]

Posts