Thursday, January 05, 2006
Estatísticas, Quando Começar?
Marcio, boa tarde.
Dei uma olhada em seus textos e achei muito interessante, principalmente
os que falam sobre performance.
Gostaria de saber sua opinião em relação a qual momento devemos começar
a utilizar estatísticas, ou, se isso é muito relativo e depende muito de
cada aplicação.
Desde já agradeço.
O momento de começar a usar as estatísticas, em minha opinião, é na concepção do sistema. Quando voce estiver desenhando suas tabelas físicas já terá subsídio suficiente para decidir o size do histograma, particionamento, volumetria, índices, PK, FK, UK, constraints, not null, FBI, MV, etc. Toda essa gama de instrução é levada em consideração. Portanto quanto mais informação for passada ao Oracle em forma de regras de negócio (pk, fk, constraints, índices, etc), mais ele terá chance de decidir corretamente sobre como chegar aos dados.
Por outro lado e não menos importante, os fatores globais também influenciarão o otimizador no novo sistema como capacidade de leitura física, quanto do índice será reaproveitado em cache, qual o custo do uso do índice, quanto de espaço os agrupamentos e ordenações irão consumir, quantos usuários simultaneos haverão no sistema, qual disponibilidade de hardware (Disco, CPU e memória), quantas transações serão esperadas por minuto, qual será a estratégia de backup, etc. Para cada uma destas informações, há uma ou mais entradas correspondentes no spfile para compor as estatísticas que irão alimentar o otimizador. Por exemplo: Qual o melhor caminho para chegar ao Aeroporto de Congonhas? Depende! De que? Ora de onde é o ponto de partida. Vê: Tudo depende do quanto se conhece para traçar um plano.
Eu começo desde o desenho, caso haja necessidade de alguma exceção de size ou sample, eu trabalho isso nos defaults (agora podemos customizar os defaults no 10gr2 - pesquise sobre a dbms_stats). Quando o desvio é grande, eu volto para a "prancheta", porque, na maioria da vezes, estou me perdendo no projeto e algo está mal dimencionado ou desenhado. Tento manter tudo o mais simples possível. A partir do primeiro protótipo, pode ter certeza, as tabelas estarão atualizadas e haverá um job coletando estatísticas quando necessário.
Labels: Training
Comments:
<< Home
Marcio,
Concordo com sua opinião, acredito que a concepção do sistema é que vai garantir performance ao longo de sua vida útil.
Entretanto, acho também que isso fica um pouco difícil, pois acredito que nem todos que estão desenhando e programando tenha como requisito a performance, ou seja, preocupação constante nos conceitos e recursos disponíveis nos bancos de dados, existe a preocupação em resolver o processo do negócio, aquilo que o sistema foi proposto, mas nem sempre esta resolução ocorre da melhor maneira, pelo melhor caminho.
Digo isto, pois sinto na pele este problema. Como cultura da empresa não desenvolvemos nada internamente, sempre compramos pacotes fechados, em algumas exceções solicitamos desenvolvimento externo.
Para exemplificar o que estou dizendo, por volta de 8 meses atrás implantamos um sistema (OLTP), que hoje atende uma parte de nossas filiais, cerca de 300. Seu tamanho ainda é pequeno, algo em torno de 50Gb, rodando em equipamentos bem dimensionados. Após alguns meses de implantado começamos a enfrentar alguns problemas de performance, alguns processos chegavam a ter mais de 15 segundos em seu tempo de resposta.
O fornecedor sugeriu utilizarmos estatística, acabamos analisando os códigos PL/SQL e sugerimos alterações no mesmo. Estas alterações foram feitas e o resultado foi o esperado, ou seja, continuamos ainda sem utilizar estatística, e a cada problema procuramos analisar o código.
Este sistema hoje esta com algo em torno de 1.500 tabelas e 4.600 índices, utilizar estatísticas de forma correta demanda muito recurso humano e tecnológico para acompanhar todo o funcionamento do ambiente. Futuramente isto não terá como evitar, ativar estatística será obrigatório.
Aqui evitamos utilizar estatísticas e até agora os níveis de performances são satisfatórias, dentro daquilo que foi idealizado. Sistemas como SAP utilizamos estatística, por orientação do fornecedor.
Tenho a sensação de que estatística muitas vezes acaba sendo utlizada para "resolver" problemas de concepção e programação, quando na verdade este recurso deveria elevar os níveis de performance.
Por isso queria saber sua opinião, realmente este paradoxo me intriga.
Obrigado por sua resposta.
Concordo com sua opinião, acredito que a concepção do sistema é que vai garantir performance ao longo de sua vida útil.
Entretanto, acho também que isso fica um pouco difícil, pois acredito que nem todos que estão desenhando e programando tenha como requisito a performance, ou seja, preocupação constante nos conceitos e recursos disponíveis nos bancos de dados, existe a preocupação em resolver o processo do negócio, aquilo que o sistema foi proposto, mas nem sempre esta resolução ocorre da melhor maneira, pelo melhor caminho.
Digo isto, pois sinto na pele este problema. Como cultura da empresa não desenvolvemos nada internamente, sempre compramos pacotes fechados, em algumas exceções solicitamos desenvolvimento externo.
Para exemplificar o que estou dizendo, por volta de 8 meses atrás implantamos um sistema (OLTP), que hoje atende uma parte de nossas filiais, cerca de 300. Seu tamanho ainda é pequeno, algo em torno de 50Gb, rodando em equipamentos bem dimensionados. Após alguns meses de implantado começamos a enfrentar alguns problemas de performance, alguns processos chegavam a ter mais de 15 segundos em seu tempo de resposta.
O fornecedor sugeriu utilizarmos estatística, acabamos analisando os códigos PL/SQL e sugerimos alterações no mesmo. Estas alterações foram feitas e o resultado foi o esperado, ou seja, continuamos ainda sem utilizar estatística, e a cada problema procuramos analisar o código.
Este sistema hoje esta com algo em torno de 1.500 tabelas e 4.600 índices, utilizar estatísticas de forma correta demanda muito recurso humano e tecnológico para acompanhar todo o funcionamento do ambiente. Futuramente isto não terá como evitar, ativar estatística será obrigatório.
Aqui evitamos utilizar estatísticas e até agora os níveis de performances são satisfatórias, dentro daquilo que foi idealizado. Sistemas como SAP utilizamos estatística, por orientação do fornecedor.
Tenho a sensação de que estatística muitas vezes acaba sendo utlizada para "resolver" problemas de concepção e programação, quando na verdade este recurso deveria elevar os níveis de performance.
Por isso queria saber sua opinião, realmente este paradoxo me intriga.
Obrigado por sua resposta.
# posted by 
: 1:16 PM
: 1:16 PM
Acho que respondo um pouco sobre seu paradoxo de performance no artigo seguinte. A performance dever ser considerada desde o primeiro momento, porque o negócio requer isso.
As estatísticas são conseqüência para alcançarmos boa performance - eficiência e eficácia. O melhor dos mundos é ser eficaz de forma eficiente. Nas versões mais recentes, não usar o CBO, é (talvez) ser eficaz sem ser eficiente, sem usar o melhor que a ferramenta pode oferecer.
Não acho que esteja errado um sistema rodar sem estatística, estaria sendo hipócrita. Eu mesmo administro base onde é proíbido, pelo fornecedor, coletar estatísticas. Porém, é algo onde devemos trabalhar e conscientizar os fornecedores com benchmarking, provas, treinamento, tudo que estiver ao nosso alcance.
Muito obrigado pela leitura e por compartilhar sua experiência aqui.
Abraços,
Marcio Portes
Post a Comment
As estatísticas são conseqüência para alcançarmos boa performance - eficiência e eficácia. O melhor dos mundos é ser eficaz de forma eficiente. Nas versões mais recentes, não usar o CBO, é (talvez) ser eficaz sem ser eficiente, sem usar o melhor que a ferramenta pode oferecer.
Não acho que esteja errado um sistema rodar sem estatística, estaria sendo hipócrita. Eu mesmo administro base onde é proíbido, pelo fornecedor, coletar estatísticas. Porém, é algo onde devemos trabalhar e conscientizar os fornecedores com benchmarking, provas, treinamento, tudo que estiver ao nosso alcance.
Muito obrigado pela leitura e por compartilhar sua experiência aqui.
Abraços,
Marcio Portes
<< Home
