Srs, Essa lista tem poucos emails enviados por dia, por isso IMO é desnecessário utilizar o modo digest, além da maioria dos MUAs possuir recursos de filtragem de mensagens, etiquetagem, redirectionamentos, &ca.
Mesmo assim todo usuário tem o direito de escolher qual modo convém para recebimento de e-mails. Mas a quantidade de usuários respondendo mensagem DIGEST vem aumentando significativamente, o que é ruim para indexação e sobrecarga dos nossos servidores. Portanto, venho encarecidamente pedir a todos que _não_respondam_ mensagens em modo DIGEST. 2010/1/23 MARCIO CASTRO <[email protected]>: > a - > "porque a operações de escrita em lote costumam custar muito caro para os > logs > daquela plataforma ..." Márcio, a forma como voce "edita" as mensagens confude e as vezes altera completamente o contexto das frases. Fica até complicado de entender o que nós mesmo falamos em outras mensagens. Dê preferência de utilizar o modelo de respostas entre linhas (/inline replying/)[1]. > 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? Não estou falando de *arCHives* e nem falei de um bilhão de registros. Repare que em mnha mensagem original eu citei os processos DBW e LGW que são responsáveis pela atualização dos data files e REDO, mas não citei o nome do processo ARC. AFAIR, não é possível desabilitar os logs de transação de uma tabela para operações de exclusão, mas é possível criar uma tabela nova com operações de LOG reduzidas (cláusula NO LOGGING) e utilizar /hints/ para induzir o otimizador a utilizar /direct-path/ para inclusão de registros na tabela (CTAS). Note que utilizar a abordagem do CTAS sem LOG faz com que a fragmentação do segmento aumente, pois novos blocos serão criados acima da HWM – marca d'agua superior (tradução livre e tosca). Em seguida voce precisaria reorganizar (SHRINK) e isso gera ônus de performance de qualquer jeito. > Aproveitando: os redo log files funcionam de modo análogo ao WAL? Médio. O redo utiliza o protocolo de escrita prévia [2] e da mesma forma o WAL do postgres implementa o protocolo de mesmo nome, porém existem algumas diferenças: - A operação de atualização do REDO do Oracle é síncrona enquanto que no postgres podemos configurar isto. - No PostgreSQL não podemos definir tamanho de segmentos de log nem adicionar explicitamente novos logs (checkpoint+pg_switch_log não faz isto!), porém podemos aumentar na compilação o tamanho de todos segmentos. - O Or**le trabalha com grupos de arquivos de logs espelhados de forma que *todos* os arquivos de um grupo precisam ter sido gravados no disco (checkpoint) para ele criar um novo grupo. - O arquivo de controle (scn) do O**le pode ser multiplexado enquanto que pg_control do postgres não pode (eu já fiz e funciona, por que não pode??) - Cada segmento de log do postgres possue um nome diferente e o mesmo nome nunca será reaproveitado nem mesmo numa situação de recuperação, onde o timeline (se não me engano quinto digito do nome do arquivo) iria mudar. No Or*cle os segmentos pertencentes a um mesmo grupo são reciclados (ou arquivados) e reaproveitados após um checkpoint. Ah! Deve ter mais coisa aí, mas agora não lembro. > 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. Desculpe por isto, o que eu quis dizer foi utilizando índices sobre coleções, se não me engano INDEX OF da cláusula FORALL. Se este também existia no 8i é porque eu realmente tenho olhado muito pouco para o PL/SQL mesmo nos últimos anos. > 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? Referência de problemas com atualização em massa de dados? Sim é *bem* comum, vide discussões no asktom[3]. Busque por exclusão massiva, bulk load, forall .. > 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? É ... de fato o que você falou não tem NADA a ver com operações em lote. A questão do CTAS, como eu já expliquei nos parágrafos acima, tem a ver com a criação de uma tabela com suporte reduzido do REDO para redução de carga dos processos LGWR e WRN. Porém como explicado acima, existem efeitos colaterais nesta abordagem. Quanto a paralelização de consultas, se você está se referindo a /hints/ do tipo *PARALLEL, então eu realmente prefiro deixar para discutirmos o assunto numa lista específica de Oracle da qual eu não faço parte (in)felizmente ... > 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: > 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. Voce realmente já precisou utilizar, por exemplo, o conselheiro de SQL (SQL Advisor) do ADDM ou voce está falando baseado na literatura e/ou proposição da ferramenta? Eu realmente acho o conceito bem interessante e para "programetas" de fato deve ser funcional, mas na prática e com aplicações com centenas de packages a coisa ainda tá um pouco ineficaz. Por exemplo, cria um baseline com alguns snapshots (5 em 5 min) na execução de um package que possue algumas procedures com consultas lentas com o SQL Advisor e talvez entenda o que estou falando. > 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. Então podemos tirar por conclusão que o MySQL é mais rápido que o Oracle, DB2, Sybase com bases de dados para OLAP/DW, confere? Pelo menos é o que o teste TPC-H com 100GiB está nos falando. Refs.: 1) http://en.wikipedia.org/wiki/Posting_style 2) http://hssl.cs.jhu.edu/~randal/416/lectures/lec.recovery.pdf 3) asktom.or_ac_l_e.com* * Retirar o sublinhado. Abraço! -Leo -- Leonardo Cezar http://www.aslid.org.br http://postgreslogia.wordpress.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
