Olá pessoal, concordo com o Fábio em gênero, número e grau. E coloco
alguns adendos: 1) não existe empresa que dê suporte 24x7 em Oracle a
não ser que seja a um preço exorbitante. Um suporte desse tipo custa, no
mínimo, uns R$20.000 por mês. Por R$20.000, vc contrata 2 DBAs c/
carteira assinada para trabalhar full-time.
Se tiver alguém aqui na lista que pague menos por isso, por favor, me avise que
eu contrato a empresa na hora!!!
2) Para micro e pequenas empresas, acho que essa necessidade de ter
suporte 24x7 é uma bobagem. Tanto o Oracle como o PostgreSQL são
estáveis o suficiente para não precisarem de pessoas tempo integral
monitorando ele. Se você tem um bom plano de crash recovery e um bom
DBA, vc não terá problemas. 3) Uma das grandes sacanagens da Oracle se
chama Metalink: mesmo comprando o Oracle, vc tem que comprar o suporte
do Metalink por fora (R$3.000 por ano). Ou seja, vc compra o produto mas
não tem suporte a ele, a não ser pago. Eu trabalho com Oracle a mais de
10 anos e sempre que precisei de suporte técnico, foi um parto. E, em
todas as vezes, eles não resolveram. Agora quando dá algum problema
sério, eu uso a receitinha: 1. Restauro o HD com a imagem do Sistema
Operacional, Oracle e toda tralha. 2. Restauro o backup 3. Restauro os
archive logs.
E o usuário continua trabalhando feliz.
Levo no máximo 1h para fazer isso e só precisei fazer isso 2 vezes em 5 anos.
É lógico que eu estou falando para uma base pequena de um pouco mais de
100Gb, que é o normal para uma PME, que parece ser a realidade aqui da
lista e das pessoas que utilizam software livre.
4) Por fim: Mão de obra - Quando preciso de trabalho especializado de um DBA, eu vou na lista de Oracle e contrato um DBA free-lancer ou uma pequena consultoria. Igualzinho ao que eu faço com o Postgre!!
Saudações, Josir Gomes Em 05/09/07, Bruno Almeida do
Lago<[EMAIL PROTECTED]> escreveu:
> Fábio,
>
> > SQLLoader é uma ferramenta para importação de grandes volumes de dados em
> > arquivos texto em diversos formatos. E uma ferramenta realmente robusta e
> > flexível que pode lhe ajudar a fazer ETL, migrar dados de plataformas
> > distintas, etc.
>
> Em alguns testes que realizei o COPY do PostgreSQL se comportou tão bem
> quanto o SQLLoader... Você enxerga alguma grande diferença a ponto de
> considerar o SQLLoader uma vantagem?
Sim, vide os comentários em
http://www.midstorm.org/~telles/2007/08/30/16-caracteristicas-do-oracle-que-fazem-falta-no-postgresql
>
> > Fine -Grained Access, é uma ferramenta do Oracle que permite o acesso a
> > determinadas linhas de uma tebela de acordo com o perfil do usuário
> > conectado. Este é um recurso interessante que em aplicações corporativas
> > podem ajudar um bocado.
>
> Um DBA consiente entende que um dia a aplicação está rodando em um SGBD e no
> outro dia em outro (preço, recursos, licenças). Por que não criar uma view e
> dar os grants necessários para o usuário em questão?
>
> Conheço uma porrada de empresa que começou a utilizar os recursos
> específicos de um gerenciador e hoje está passando por um verdadeiro
> inferno.
>
É verdade. Por um lado devemos evitar funcionalidades muito
mirabolantes, por outro lado, há momentos em que escolhemos um SGDB
exatamente por causa delas. Não vou defender muito o FGA aqui não. Não
acho que é algo tão importante, mas a idéia não deixa de ser
interessante. No entanto, em algumas situações, em aplicações
específicas poderia ser um diferencial.
> > O Jobs Scheduler é ferramentas do Oracle que permite o disparo de ações
> > específicas através do agendamento em horário específico, se repetindo ou
> > não em intervalos programados. Muitas pessoas resolvem esta ausência
> > utilizando o CRON do Linux, mas o Job Scheduler tem uma série de
> > funcionalidades interessantes, além de permitir tratar tudo via SQL.
>
> Gostaria de entender melhor as "funcionalidades interessantes", pq só me
> f*(@#&$ qdo uso o scheduler do Oracle. Quantas vezes esse cara já deixou de
> rodar um JOB e nem deu satisfação do motivo... Fora que a interface com ele
> (dbms.scheduler) é uma tranqueira, enquanto um VI no crontab é bem mais
> tranquilo...
>
Bom, eu particularmente gosto de trabalhar via SQL. Existem rotinas
que são mais complexas que uma simples linha no crontab. Existem casos
em que eu preciso verificar algumas condições em tabelas para decidir
o que fazer de madrugada. Em importações e exportações de dados
complexos, com validação, auditabilidade, etc, etc. Um pouco de PERL
poderia me resolver o problema no PostgreSQL, mas aí eu já estou
introduzindo a dependência de uma nova linguagem para o meu time de
DBAs. Particularmente eu gosto de trabalhar direto dentro do SGDB. Não
tive os problemas com o Scheduler que você mencionou, ele me parece
mais fácil de flexível que os Jobs da versão 9i. Não sei como está
isso no 11g, não tive tempo de testar ainda.
No entanto, realmente o Oracle começou a abusar dos seus packages. A
sintaxe começou a ficar um pouco chata mesmo. Acho que isso só tende a
piorar, uma vez que as novas funcionalidades do Oracle surgem cada vez
mais a partir dos Packages. Mas é melhor não cantar muita vitória. Eu
não me surpreenderia se isso começar a acontecer no PostgreSQL daqui a
alguns anos. É claro que eu confio no bom senso do time de
desenvolvedores do PostgreSQL, para não deixar a coisa degringolar
demais.
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
