Detalhe, enquanto o teste com parallel roda, NÂO DEIXE de verificar
que realmente está sendo feito processo em parallel conectando em
outra sessão como dba e executando query tipo :
select
decode(px.qcinst_id,NULL,username,
' - '||lower(substr(s.program,length(s.program)-
4,4) ) ) "Username",
decode(px.qcinst_id,NULL, 'QC', '(Slave)') "QC/Slave" ,
to_char( px.server_set) "Slave Set",
to_char(s.sid) "SID",
decode(px.qcinst_id, NULL ,to_char(s.sid) ,px.qcsid) "QC SID",
px.req_degree "Requested DOP",
px.degree "Actual DOP"
from
v$px_session px,
v$session s
where
px.sid=s.sid (+)
and
px.serial#=s.serial#
order by 5 , 1 desc;
e pra ver a geração de undo se diminui ou não, antes de cada execução
peça um :
select ss.sid, name, value
from v$sesstat ss, v$statname sn
where sn.statistic#=ss.statistic#
and ss.sid = siddasessãoondevcestátestando
and UPPER(name) like '%undo%';
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]>
escreveu
>
> Vamos por partes aí : PRIMEIRO DE TUDO, nem paralelismo nem
> diminuição de geração de logs são a solução pra todo e qquer caso
de
> performance : no caso do paralelismo, o que ele faz é disparar
vários
> programas slave simultâneos que vão ler dados ao mesmo tempo,
> consumindo portanto montões de I/O, CPU e RAM - SE vc não tiver
> disponíveis no momento esses recursos extras em quantidade (porque
> não os possui ou porque o banco está muito ativo, os recursos estão
> em uso por outras sessões) , o paralelismo só pode ** MESMO **
piorar
> a performance...
> Vamos então fazer um teste parcial então, começando com o NOLOG :
> crie só a estrutura da tabela com create table TAB1 tablespace
> nomedatablespaceLMTausar PCTFREE 1 PCTUSED 99 NOLOGGING as select *
> from [EMAIL PROTECTED] where 1=2;
> Depois insira os dados com INSERT /*+ APPEND */ TAB1 as select *
> from [EMAIL PROTECTED]; e veja quanto tempo leva.... Feito isso pra poder
> testar paralelismo :
>
> a) se ASSEGURE que os recursos necessários estão presentes e
livres
> (ie, tem o hardware, vc não tem outras sessões/outros programas
> queimando CPU e/o usando lotes de RAM e/ou fazendo montões de I/O
>
> e
>
> b) tenha CERTEZA que o paralelismo está corretamente configurado
> (ie, no mínimo vc tem o param de banco parallel_max_servers setado
> com valor não-zero E múltiplo da qtdade de CPUs - inicie-se com 2x
ou
> 3x a qtdade de CPUs, como mínimo, db_file_multiblock_read no
máximo,
> se bd 9i usando PGA automática passar pra manual na sessão e subir
> sort e hash sizes). Já que vc quer testar manualmente, tenha
CERTEZA
> que parallel_automatic_tuning está como FALSE.
>
> Agora sim vamos testar, faça um create table TAB3 tablespace
> nomedeOUTRAtablespaceLMTausar PCTFREE 1 PCTUSED 99 PARALLEL
NOLOGGING
> as select * from [EMAIL PROTECTED] where 1=2;
>
> e depois mande um : INSERT /*+ APPEND */ TAB3 as select /*+
PARALLEL
> (TAB2, n) */ from [EMAIL PROTECTED] ;
>
> veja que eu mandei paralelizar é APENAS O SELECT, que é quem
> é "grande" aqui, ok - *** não *** faz lá muito sentido vc
> paralelizar o INSERT em si (como vc fez em
>
> alter session enable parallel dml;
> insert /*+ PARALLEL (TAB1,12) */
> into TAB1
> select /*+ PARALLEL (TAB2,12) */
>
> ), já que vc SABE que a tabela estava vazia, é pequena portanto,
> sim ????? Paralelismo é pra objs GRANDES....
> No caso acima, pro degree n, faz um teste inicialmente com n
sendo
> 1/4 de parallel_max_servers, depois outro criando uma TAB4 e na
hora
> do parallel indicando n sendo 1/2, veja lá como se comporta. SE
> consistentemente usando paralelismo a performance piorou, é
indicação
> ** CLARA ** que o teu sub-sistema de I/O é muito fraco (ou está
> saturado), não está "suportando" o I/O em paralelo massivo que o
> parallel SQL faz, não use paralelismo aí então....
>
> []s
>
> Chiappa
>
>
> --- Em oracle_br@yahoogrupos.com.br, "Julio Bittencourt"
> <juliobit_dba@> escreveu
> >
> > Pessoal,
> >
> > Tenho que estimar o tempo que levará para copiar umas tabelas de
um
> banco
> > para outro. Para isso pretendo usar Create Table as Select com
> dblink.
> > Como algumas tabelas são bem grandes estou fazendo testes
utilizando
> > PARALLEL e NOLOGGING para tentar melhorar a performance.
> >
> > Acontece que nos testes a utilização de PARALLEL e NOLOGGING não
> está
> > melhorando a performance, pelo contrário está demorando muito
mais
> do que
> > quando não as utilizo.
> >
> > Por exemplo, fiz um teste com uma tabela com cerca de 500 mil
> linhas:
> >
> > create table TAB1 as select * from [EMAIL PROTECTED]
> > /
> > ===> Esse create simples levou 158 segundos
> >
> >
> > create table TAB1 PARALLEL NOLOGGING
> > as select * from <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]
> > /
> > ===> Esse create com parallel e nologging levou 317 segundos, o
> dobro do
> > tempo.
> >
> >
> > Tentei melhorar o comando com o que li num documento que
explicava
> o uso de
> > parallel e ele ficou assim:
> >
> > create table TAB1 PARALLEL NOLOGGING
> > as select * from <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] where 1=2
> > /
> > alter session enable parallel dml;
> > insert /*+ PARALLEL (TAB1,12) */
> > into TAB1
> > select /*+ PARALLEL (TAB2,12) */ * from <mailto:[EMAIL PROTECTED]>
> [EMAIL PROTECTED]
> > /
> > ===> Esse levou 266 segundos.
> >
> > As versões dos dois bancos é 8.1.7.4.
> > O servidor onde a tabela está sendo criada é Sun Solaris 8 com
dois
> > processadores (maquina de desenvolvimento).
> > O servidor de onde a tabela está sendo copiada também é Sun
Solaris
> e tem
> > vários processadores, mas nao sei dizer quantos.
> >
> > O que estou fazendo de errado?
> >
> > Desde já agradeço.
> >
> > Julio.
> >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
