Menu de navegação

[RoninParticipant]

Bom dia pessoal, temos um ambiente com aproximadamente 3.6TB de tamanho, maior tabela em torno de 800GB (TABLE E INDEX) E algumas outras..
O ambiente é um 11g r2 11.2.0.3 na edição Standard, cresce diariamente 7GB.
Nossa estratégia é rodar 2 x na semana a coleta de estatísticas, porém a mesma vem levando quase 2 dias de execução…
Utilizamos o pacote dbms_stats com parâmetro AUTO_SAMPLE_SIZE.
Efeitos: observamos que a coleta vem consumindo consideravelmente IO, no qual compete com o sistema ERP por recurso no banco.
Sabemos que não podemos utilizar COMPRESS e nem paralelismos uma vez que a edição não nos permite.
Alguém tem alguma dica..
Obrigado

[José Laurindo ChiappaModerator]

Tudo jóia ?? Então, respondendo na ordem inversa :

a. vc está Rigorosamente Enganado ao supor que não pode usar NENHUM tipo de Paralelismo num Standard Edition : não sei se vc a conhece, mas a package DBMS_PARALLEL foi INVENTADA PARA ISTO, ie, fazer paralelismo em SQLs longos em Editions onde não há Parallel SQL disponível, vide https://oracle-base.com/articles/11g/dbms_parallel_execute_11gR2 para alguns exemplos, E aqui no Forum mesmo eu já dei um exemplo com ela, vide https://www.profissionaloracle.com.br/forums/topic/oltp-na-pratica/ …. E o conceito aqui é QUASE O MESMO, ie, uma sessão vai ser a coordenadora, que bloqueia a tabela para não entrar mais dados enquanto rola o Paralelismo, cria n sessões escravas, divide a tabela grande (por ROWIDs, número de linhas ou seja qual opção for usada) E passa cada intervalo de dados a ser lido/recuperado por uma das sessões escravas, é bem similar ao que o Parallel SQL da Enterprise Edition faz, apenas (ÓBVIO) é VOCÊ que tem que fazer manualmente TODOS OS PROCEDIMENTOS e decisões….

b. não sei se vc Sabe mas o OBJETIVO de coletar estatísticas é descobrir QUANTAS linhas retornam pra determinadas condições/valores, para que o RDBMS Oracle possa avaliar condições do tipo :

SELECT colunas FROM TABELADENOTASFISCAIS
WHERE CLIENTE=1234;

Muito bem : meu primeiro ponto é, SE mais ou menos a Ordem de Grandeza na qtdade de linhas se mantém, vc NÂO PRECISA COLETAR a toda hora, sim sim ?? Por exemplo, se hoje na tabela TABELADENOTASFISCAIS o cliente 1234 tem, digamos, 542.345 linhas, aí semana que vem ele passou a ter, digamos, 602.432, estatisticamente falando a diferença é Muito Pequena, a Ordem de Grandeza é a mesma, então é CERTO que os planos de execução não devem mudar, okdoc ?? Aí neste caso NÂO FAZ SENTIDO vc coletar e recoletar e recoletar, TODA excruciante semana, DESPERDIÇANDO recursos de hardware cada vez mais e mais… Agora, se EFETIVAMENTE os dados mudam LARGAMENTE a cada dia (tipo, hoje entrou um cliente com 1000 notas, amanhã entra um outro com CEM mil notas – duas ordens de grandeza superiores), aí SIM não tem jeito, não tem como o RDBMS estimar, aí vc TEM que recoletar, MAS se isso não acontecer, vc simplesmente BLOQUEIA as estats, não faz sentido coletar o que vc sabe que não deve mudar…
O segundo ponto é : PODE ser que o comportamento de dados seja PREVISÍVEL, tipo : 99,99% das vezes, a quantidade de NFs pra um dado cliente é por volta de, sei lá, cem mil NFs – ok, às vezes um pouco mais, às vezes um pouco menos, mas sempre alguma coisa próxima… Num caso assim, NÂO FAZ SENTIDO vc fazer o RDBMS ralar pra caramba, desperdiçãr LOUCAMENTE recursos pra chegar num resultado muito muito MUITO próximo do que vc já sabia : ULULANTEMENTE ÓBVIO, num caso assimvc PODE já indicar pro RDBMS as informações estatísticas, no meu exemplo FORÇANDO o RDBMS a acreditar que cada cliente tem 100 mil linhas na tal tabela, via DBMS_STATS.SET_TABLE_STATS e SET_COLUMNS_STATS : veja a documentação em https://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_stats.htm#CIHBIEII , e https://mwidlake.wordpress.com/2010/06/21/dbms_stats-set_table_stats-defaults/ ou https://oraganism.wordpress.com/2011/03/21/dbms_stats-set_table_stats-and-statistic-staleness/ são alguns exemplos… REPITO, a idéia é vc EVITAR depois de muito esforço coletar o que vc JÁ SABE, okdoc ??

c. sim, é Óbvio que quanto mais uma tabela cresce, mais e mais recursos / processamento (não só I/O, mas espaço temporário, ciclos de CPU, etc, etc) vc vai gastar para analisar os dados dela, sim – isso é Inescapável….
CASO vc não cai em NENHUM dos casos do item b) acima (ie, vc não faz idéia da distribuição típica dos dados) E portanto vc TEM que coletar, o que vc VAI ter que fazer é primeiro DIMINUIR AO MÁXIMO a necessidade de ler dados que não mudaram e Otimizar o throughtput do seu I/O …

=> para Diminuir a qtdade de dados a serem lidos (E portanto diminuir consumo de I/Os), o PRINCIPAL MÉTODO é o Particionamento : não é à toa que muito fornecedor de ERP *** EXIGE *** Enterprise Edition, pra vc ter esse recurso…. No seu caso, já que vc está na Standard Edition vc Não tem particionamento automático, vc VAI TER que fazer algum particionamento MANUAL, tipo ter uma tabela com os dados de Janeiro, outra com os dados de Fevereiro, assim por diante…

=> para Otimizar recursos de hardware, DEPOIS de ter feito o possível no hardware (ie, usar os discos mais rápidos, agendar a coleta para o melhor horário de modo a evitar concorrência, etc) E também no Sistema Operacional e nas estruturas (ie, Assegurar que vc tem Asynchronous I/O e Direct I/O habilitado nos disk devices, NÂO TER as tabelas criadas com extents muito pequenos OU que não sejam múltiplos do teu I/O máximo, etc) , o que vc VAI fazer é dedicar o máximo de Recursos para a coleta : fatalmente isso PODE SIM passar por Paralelismo de algum tipo : PODE ser que vc tenha que via DBMS_PARALLEL ter JOBs que leiam em paralelo cada um uma parte da tabelona grande e depois vc FIXA os valores via DBMS_STATS.SET_xxx_STATS, PODE ser que simplesmente vc possa ter N sessões simultâneas, cada sessão coletando estatísticas de DIFERENTES tabelas, mais ou menos cfrme http://houseofbrick.com/gathering-statistics-in-parallel-oracle-standard-edition/ mostra….

OU SEJA : é SIM possível acelerar a coleta (ou como eu falei, de repente nem coletar o que vc sabe que não muda), mas no Standard Edition vc VAI TER QUE FAZER ISSO manualmente, por sua conta, okdoc ??

[]s

Chiappa

[Author]

Posts