Muito obrigado pelas respostas!!
Em 14 de janeiro de 2014 17:55, <jlchia...@yahoo.com.br> escreveu: > > > Bom, faz tempo que "milh€ ¢Ãµes de registros" deixou de ser algo extremo > am hardware de produ€ ¢Ã§Ã£o, enterprise-class, mas de qquer maneira, eu > penso nas coisas de sempre, ie : > > a) SE o teu servidor tiver capacidade sobrando (ie, mem€ ¢Ã³ria, banda de > I/O, CPU, etc) ainda n€ ¢Ã£o usada e dispon€ ¢Ãvel, vc pode fazer a query > em paralelo : isso implica que "sess€ ¢Ãµes escravas" ser€ ¢Ã£o abertas e > alocadas ao mesmo tempo, cada uma lendo um pedacinho da "tabelona" .... > Veja a Documenta€ ¢Ã§Ã£o do RDBMS (especialmente o manual de Concepts e o > DW Guide da tua vers€ ¢Ã£o) para conceitos, sintaxes e alguns exemplos, e > sites de refer€ ¢Ãªncia como http://oracledoug.com/px.html e > https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:39946845137685para > mais detalhes... > S€ ¢Ã³ REPITO : vc s€ ¢Ã³ pode pensar nisso ** SE ** realmente vc tem a > capacidade sobrando no servidor : caso hoje ele j€ ¢Ã¡ esteja no gargalo, > Muito Provavelmente n€ ¢Ã£o vai haver capacidade de I/O, poder de CPU e > mem€ ¢Ã³ria livre para fazer frente € ¢Ã n sess€ ¢Ãµes escravas "atacando" > ao mesmo tempo... > > b) se assegurar que o sistema operacional e o I/O est€ ¢Ã¡ setado para a > melhor performance poss€ ¢Ãvel : por exemplo, € ¢Ã© CR€ ¢Ã’TICO que o > ambiente permita I/O As€ ¢Ãncrono (Asynchronous I/O) e (via de regra) > Direct I/O : Asynch significa que haver€ ¢Ã¡ m€ ¢Ãºltiplos I/Os > simult€ ¢Ã¢noes, ie , os pr€ ¢Ã³ximos I/Os que sejam independentes daquele > em execu€ ¢Ã§Ã£o no momento N€ ¢Ã’£O PRECISAM ficar esperando que o atual > termine... Isso € ¢Ã© IMPRESCIND€ ¢Ã’VEL em opera€ ¢Ã§Ãµes de full table > scan que seja usado paralelismo, ajuda em muito via de regra paraque as > sess€ ¢Ãµes escravas n€ ¢Ã£o fiquem esperando umas pelas outras... > J€ ¢Ã¡ o Direct I/O significa que os dados lidos s€ ¢Ã£o enviados > diretamente para o RDBMS, que j€ ¢Ã¡ tem buffers e caches Pr€ ¢Ã³prios, > n€ ¢Ã£o se perdendo tempo em se fazer o Sistema Operacional copiar o que > foi lido para os buffers/caches de sistema operacional.... Via de regra > esse setting € ¢Ã© Positivo para a performance... > alguns ajustes do sub-sistema de I/O (como striping size, balanceamento > de discos, etc) podem tamb€ ¢Ã©m influenciar se vc est€ ¢Ã¡ usando um > storage de discos : isso € ¢Ã© algo a se alinhar com os sysadmins e time de > storage > > c) n€ ¢Ã£o com se assegurar que o armazenamento interno est€ ¢Ã¡ OK, e > que as configs de DB est€ ¢Ã£o apropriadas : por exemplo, o RDBMS ao fazer > um full-table scan l€ ¢Ãª uma por€ ¢Ã§Ã£o de blocos cont€ ¢Ãguos, o > chamado EXTENT : se a tabela tiver sido criada com extents muito > pequenos/consistentemente menores do que o m€ ¢Ã¡ximo de bytes que o > sistema operacional pode ler, OU se o tamanho do extent n€ ¢Ã£o for um > m€ ¢Ãºltiplo exato do tamanho m€ ¢Ã¡ximo de I/O do sistema operacional, ao > inv€ ¢Ã©s de um I/O ser€ ¢Ã£o necess€ ¢Ã¡rios dois para ler o mesmo > extent.... Outros pontos, ainda dentro do database : > - pode valer a pena (via ALTER SESSION) setar temporariamente o > par€ ¢Ã¢metro DB_FILE_MULTIBLOCK_READ_COUNT para um n€ ¢Ãºmero de blocos > que se equipare ao m€ ¢Ã¡ximo I/O do sistema operacional > - vc ** TEM ** que garantir que os dados da tal tabela est€ ¢Ã£o > gravados em extents com o ** m€ ¢Ãnimo poss€ ¢Ãvel ** de espa€ ¢Ã§o em > branco e/ou blocos alocados mas n€ ¢Ã£o usados - o objetivo aqui € ¢Ã©, > mais uma vez, diminuir ao m€ ¢Ã¡ximo a qtdade de blocos (e portanto a > qtdade de I/Os) necess€ ¢Ã¡ria para se recuperar a informa€ ¢Ã§Ã£o... > E que fique claro : blocos com espa€ ¢Ã§o em branco e/ou n€ ¢Ã£o > usados podem resultar tanto das op€ ¢Ã§Ãµes de controle de armazenamento da > tabela (exemplo, o porcentual de espa€ ¢Ã§o que o RDBMS reserva para > futuros UPDATEs) quanto de DMLs , como DELETEs que removeram os dados mas o > espa€ ¢Ã§o n€ ¢Ã£o foi reusado, ou de opera€ ¢Ã§Ãµes de APPEND de dados ... > > d) vc VAI se assegurar, dentro do poss€ ¢Ãvel, que a rotina ser€ ¢Ã¡ > agendada para uma data/hora em que n€ ¢Ã£o est€ ¢Ã£o sendo feitos grandes > DMLs na tal tabela grande : a quest€ ¢Ã£o € ¢Ã© que, para se assegurar que > n€ ¢Ã£o h€ ¢Ã¡ leitura suja, de dados n€ ¢Ã£o-comitados, durante DMLs a > informa€ ¢Ã§Ã£o consistente € ¢Ã© armazenada em undo blocks, que significam > mais I/Os extras > > []s > > Chiappa > > -- Att, Bruno N. Barboza
