Caro Leonardo;
Muito obrigado por responder. Seguem as minhas considerações:
a -
"porque a operações de escrita em lote costumam custar muito caro para os logs
daquela plataforma ..."
Você está falando de quais logs, dos arquives? É isso mesmo? Para quê importar
1 bilhão de registros com arquive? Neste caso, é só desabilitar os mesmos, ok?
Também já ví uma empresa erroneamente colocando datafiles e redo logs files
arquivados no mesmo disco ou utilizando a mesma I/O; aí vai ficar lerdo mesmo,
não tem jeito, os arquives TEM de ser colocados em um local separado.
Aproveitando: os redo log files funcionam de modo análogo ao WAL?
b -
"O tal do Bulk Collect (verdadeiramente muito recente - 10g)"
Isto não te nada de recente, você está equivocado. Tal existe desde a versão 8i
lançado em 1998, já completando mais de 10 anos. Também já fui programador em
PL/SQL (certificado), e trabalhava com o Oracle 7.3.
Para completar, tem um exemplo de utilização do bulk com a versão 8 em
http://www.oracle-base.com/articles/8i/BulkBinds8i.php.
c -
"Esse tipo de comportamento é muito comum de se encontrar em uma série de
aplicações crítica naquela plataforma fechada"
Não entendí; comum aonde? Você poderia me enviar alguns exemplos? Que tipo de
atividades são realizadas para que eu consiga simular os mesmos problemas? Você
tem alguma referêmcia na web explicando isto?
d -
"E por falar em milhares (hã?) .. isso mesmo apenas milhares de linhas
é necessário recorrer aos CTAS (create table as ...) porque a
operações de escrita em lote costumam custar muito caro para os logs
daquela plataforma ..."
Olha só; se você estiver com algum problema de espaço em disco, e quiser mover
alguma tabela para outro DISCO, você pode utilizar CRIATE TABLE AS a fim de
efetuar uma operação mais rápida, podendo inclusive paralelizar esta operação
(usar múltiplos processadores). Tal não tem NADA a ver com escritas em lote,
correto?
e -
"...o todo poderoso ADDM que "disfarça" todo o problema das suas SQLs."
O ADDM (Automatic Database Diagnostic Monitor) não disfarça nada, pelo
contrário, ele MOSTRA PROBLEMAS relacionados à consumo de CPU, uso de memória,
uso da I/O, queries, rotinas em PL/SQL, rotinas em Java, configurações do
banco, contenção de objetos e concorrência, e funciona da seguinte forma:
1 - o AWR tira uma fotografia ou "SNAPSHOT" do banco, de tempos em tempos, e
armazena as informações coletadas;
2 - o ADDM analisa os dados coletados e identifica problemas, inclusive
provendo as soluções, que podem ser visualizadas no Enterprise Manager.
Então, voltando ao seu exemplo das queries: se algum sistema executar uma
sentença SQL mal escrita, ou com baixa performance, o ADDM identifica a query e
propõe soluções, que variam desde a criação de índices até a reescrita da mesma.
g -
"Quanto ao TPC, tenta pelo menos o H."
Mas porquê? Vejamos, em
http://www.tpc.org/tpch/results/tpch_perf_results.asp, verificamos
publicações de testes com bancos que variam de 100 Gigas a 30 Teras,
onde o EXASOL marcou o primeiro lugar em 3, o Oracle em 2 e o DB2 em 1.
Aliás, no de 30 Teras só teve o Oracle; nem teve concorrência.
f -
"é que *problemas* de performance qualquer implementação de servidor de banco
de dados tem,
e graças a esse problemas é que a Júlia tem o pão e leite na mesa todo"
Com certeza, e eu concordo muito com isso, também tenho esposa e filho. Mas o
que eu vejo sempre é o seguinte: o fulano que mexe com a ferramenta A e só
conhece a mesma, ou melhor, depende da mesma (caso que eu citei aquí na lista
do Caché) sempre fala que esta é a melhor do mundo, é a mais rápida e etc e
tal. Paciência, o cara está vendendo o peixe dele e pronto, será aquela
discussão de time de futebol sem nenhum sentido e da qual não vale a pena
participar.
Olha só; uma empresa para a qual eu presto serviço onde o banco é PostgreSQL,
e todo o mundo reclamava da performance. Só que o culpado não era o mesmo; na
verdade escreveram uma aplicação bem porca, onde as entidades (cerca de 2000)
foram dezenhadas tentando manter sempre uma chave única, para "facilitar a
programação". E o "DBA" da época nem sequer criou índices para as chaves
estrangeiras, e não tinha estatística para nada.
Resolvidos estes problemas, algumas rotinas que levavam horas - isto mesmo,
horas - foram retiradas do código Java e incorporadas ao banco via funções e
views, passando a rodar em minutos.
Hoje, ninguém lá quer tirar o Postgres.
Atenciosamente,
Márcio de Figueiredo Moura e Castro
________________________________
De: Leonardo Cezar <lhce...@gmail.com>
Para: Comunidade PostgreSQL Brasileira <pgbr-geral@listas.postgresql.org.br>
Enviadas: Sexta-feira, 22 de Janeiro de 2010 19:05:28
Assunto: Re: [pgbr-geral] Res: Res: Res: Res: Digest pgbr-geral, volume 35,
assunto 94
2010/1/22 MARCIO CASTRO <marciomouracas...@yahoo.com.br>:
> Colega;
>
> Eu estava tratando com outro membro da lista, quando viestes com esta
> falta de educação. Se vossa senhoria não concorda com alguma coisa inerente
> à minha pessoa, então faça a gentileza de mandar em private, e não incomodar
> aos demais, ok?
Olá Srs, prazer eu sou um dos moderadores desta lista. Tudo jóia??
Sou elementar assim como um Gnomo e de vez em quando apareço para
apoia-los em seus desafetos.
> a -
> "Tuas colocações já foram argumentadas e contra argumentadas"
>
> Colega; o PostgreSQL é muito mais lerdo que o Oracle no quesito PL/SQL
> versus PG/plSQL; disso eu não tenho dúvida, e ninguém mandou seguer um
> exemplo que comprove o contrário.
Gostaria de contribuir um pouco com este tema.
Sou um ex-desenvolvedor PL/SQL e realmente lá no mundo proprietário
já tivemos alguns problemas de performance que precisamos utilizar
recursos do Or*cle (adorei essa!!) para "contornar" situações
inusitadas que surgiram com grande carga de dados – veja bem, não
estou falando de alguns milhões de registros.
O tal do Bulk Collect (verdadeiramente muito recente - 10g) foi criado
para contornar situações onde iterações sobre *dados* costumam ser
lentas, devido a deficiências na troca de contexto entre o motor SQL e
o motor PL/SQL. Esse tipo de comportamento é muito comum de se
encontrar em uma série de aplicações crítica naquela plataforma
fechada, Eu mesmo já vi e muito apesar de não ser DBA O**le.
E por falar em milhares (hã?) .. isso mesmo apenas milhares de linhas
é necessário recorrer aos CTAS (create table as ...) porque a
operações de escrita em lote costumam custar muito caro para os logs
daquela plataforma ...
Bom que você não precise se preocupar com problemas gerados pela /wait
classes interface/ porque se voce precisasse, de fato iria entender o
quanto que o processo de escrita de redo e escrita de buffers (LGWR e
DBWn respectivamente) atrasam as transações do resto do banco. Porque
voce não precisa?? Simples, seus problemas acabaram vcs tem o todo
poderoso ADDM que "disfarça" todo o problema das suas SQLs.
Finalizando e onde realmente eu queria chegar é que *problemas* de
performance qualquer implementação de servidor de banco de dados tem,
e graças a esse problemas é que a Júlia tem o pão e leite na mesa todo
dia, mas estamos aqui para solucionar todos esses problemas e os
outros que provavelmente deverão aparecer daqui pra frente ...
Quanto ao TPC, tenta pelo menos o H.
Preciso ir porque tão fechando aqui na empresa ... depois eu completo ;-)
Abraço!
-Leo
--
Leonardo Cezar
http://www.aslid.org.br
http://postgreslogia.wordpress.com
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
