On Sat, 24 Aug 2002 11:34:27 -0300 (BRT) "Antonio S. Martins Jr." <[EMAIL PROTECTED]> wrote: > OK... tambem tenho DB2 no Linux e nunca me deu problema :) Ao > contrario > do Oracle que eh um parto para instalar :)
P�, aqui funciona de primeira. Tem certeza que vc est� usando uma distribui��o homologada? A instala��o do Oracle n�o podia ser mais f�cil: # mount /mnt/cdrom # cd /mnt/cdrom # ./runInstaller E seguir as instrucoes. Comigo funciona. > Nunca tivemos problemas de lock a nivel de registro, que faz lock em > tabelas eh o MySQL :) Indices? que BD nao tem indice... Vc. poderia me > explicar o que sao os sumarios e o MTTR? Sabe fabricante diferente > nome diferente para a mesma coisa :) Heh, eu nao falei dos indices em si, falei dos advisories, que tratam da situacao de indices, sum�rios, estimativas de MTTR, etc. � uma funcao de monitoracao. Sumarios s�o um nome gen�rico para Materialized Views, um recurso de performance do Oracle. Por alto, � como se ele simulasse opera��es custosas em background, como multiplos MERGES entre grandes quantidades de dados, JOINs e outras operacoes de agrega��o e armazena os resultados em uma tabela. Ent�o, o otimizador de queries reescreve a sua query para se poss�vel, bater com algum dos sum�rios j� armazenados. MTTR � Mean Time To Recover: tempo m�dio de recupera��o contra falhas: um c�lculo que vc faz ou � gerado pelo Oracle para avaliar o tempo m�ximo de recupera��o total ou parcial dos recursos do banco em caso de falha, que vai progredindo ou diminuindo conforme o tamanho/estrutura dos seus dados. > Instale o Control Center do DB2, voce tem o gerenciamento _total_ do > BD e nao precisa _comprar_ em separado! O Oracle eh um tal de adquirir > licenca disso, pacote para aquilo... O Enterprise Manager � a ferramenta de administra��o padr�o e n�o � preciso adquirir em separado. Vem com o banco e � coberta pela mesma licen�a. De fato, uma licen�a Standard � mais do que o suficiente para 95% das aplica��es que se v� por a�. Vc pagar� licen�as de componentes opcionais, como o Spatial, etc. > politica agora), se bem que ele quase nao tem updates (patchs) tem > upgrades (que sao vendidos)! Os patches do Oracle est�o dispon�veis gratuitamente na technet.oracle.com, e upgrade de vers�o s� acontece alguns anos de um release pro outro (qts anos foram do 8i pro 9i? 3, 4, 5? Nao lembro mais). N�o espalhe FUD. > Bem... a parte do mais rapido, voce tem que conferir os benchmarks no > site da IBM e da Oracle algumas vezes por mes... nao sei qual dos dois > eh o mais rapido esta semana :) N�o fiz benchmarks formais, mas eu fiz uma pequena base de 1GB nos dois bancos para uma aplica��o boba que fiz aqui no meu lab, e o Oracle foi sensivelmente mais r�pido. N�o calculei, apenas senti uma velocidade maior. Talvez pq n�o conhe�a bem o DB2, mas n�o fiz nenhuma otimiza�ao no Oracle tambem. O que ou�o das pessoas (que conhe�o, n�o benchmarks do fabricante) corrobora isso. Velocidade por velocidade, o Microsoft SQL Server � mais r�pido do que qualquer um dos dois (www.tpc.org). > Quanto a ter coisas que o DB2 nao tem, o Oracle nao suporta BD > distribuido, com os dados espalhados por varios servidores (podem ou > nao estar separados geograficamente). P.Ex. Varias filiais de uma > empresa tem em cada uma os seus dados armazenados localmente > dependendo do codigo da filial! O DB2 controla isto o Oracle nao... :) Shared-nothing � muito bonito na teoria mas na pr�tica nao funciona: vc ter� que lidar com lat�ncia de rede para fazer updates E dividir banda com requisicoes ao mesmo tempo, sem falar que se uma m�quina cair vc ter� incongru�ncias nos seus resultados pois os dados faltantes geralmente n�o sao atualizados ao mesmo tempo em todos os n�s. Para fazer a mesma coisa que o Oracle faz (shared-disk com transacoes centralizadas, e disponibilidade maior) o DB2 precisa de hardware propriet�rio (da IBM, claro) e sistema operacional dela. http://www.oracle.com/ip/index.html?rac_home.html > o trabalho de DBA nao eh uma ciencia exata... o Analista chega com a > definicao do sistema, e voce tenta adivinhar a partir das informacoes > dele <corta> no Oracle se voce > cria uma tablespace (ou uma tabela) muito pequena e ela cresce muito, > voce eh obrigado a recria-la para nao perder performance com os > overlays... Banco de dados antes de ser colocado em produ��o tem que ser normatizado. Consertar problemas de modelagem de dados com o banco em produ��o n�o � boa pr�tica, � chuncho. Eu particularmente nunca presenciei o problema q vc relatou, farei alguns testes para confirmar. > O backup tambem tem opcao de fazer o banco, tablespace, etc... etc... > assim como o export/import :) rman rules ;) > Serio, entao porque todo consultor Oracle que te vender alguma coisa > quando voce pede um gerenciador de backup? Pq existem consultores e consultores. Ano passado eu mesmo j� fui demitido por consultor de Oracle FDP. Em tudo quanto � canto rola m�fia. Mas � legal pq qt mais o tempo passa, mais vc fica esperto ;). Chega um dia em q vc manja quem � o profissional e quem � o pilantra. > Olha... a parte de Mainframe e AS/400, o banco eh outro :) Pois �. O Oracle � o mesmo banco. Em UNIX, mainframe, PC, e todas as 50+ plataformas para o qual foi portado. O conhecimento adquirido em um � utilizado no outro sem altera��es. A vida com DB2 � um constante aprendizado =]. No DB2, tenho que estudar o DB2/400, que � diferente do DB2 UDB, que � diferente do DB2 para zSeries, que � diferente do DB2 para <coloque sua m�quina IBM esdr�xula aqui>, que � diferente do DB2 para torradeira, que � diferente do... > ele vai gravar na fita :) Mas mesmo o DB2 controlando o hardware (se > voce quiser, pode pular o SO e deixa-lo gerenciar os discos onde estao > os dados, Vc est� confundindo o que eu disse. Eu falei que n�o era fun��o do banco controlar dispositivos de backup, como drives de fita. � fun��o do sistema operacional. Tamb�m n�o � fun��o do banco gerenciar a midia onde est�o os tablespaces, mas granted, o Oracle tamb�m faz isso e escreve em raw devices (direto no HD, sem filesystem). T� falando que a IBM � que te vende um pacote completo, em que o sistema operacional � grudado no banco que � grudado no hardware que � grudado no dispositivo de backup que � grudado nos consultores, todos cobrando por hora. E tudo, hardware, SO, DB, consultor, da IBM claro ;). Coitado de vc se tentar sair da gaiola =]. > Esse eh o problema, eu considero o Banco responsavel pelos dados, a > programacao deve ser externa! :) Temos vis�es diferentes ent�o. Eu acho que o modelo relacional segundo Chris Date se totalmente implementado inviabiliza muita coisa que est� acontecendo hoje no desenvolvimento com banco de dados, pois ter o banco como plataforma de desenvolvimento � uma vantagem FANT�STICA. Reduz muito o c�digo da aplica��o cliente e facilita a transposi��o para diversas formas de acesso. Exemplo: Suponha que eu tenha um programa cliente/servidor hipot�tico em plataforma Microsoft de X linhas de c�digo, onde (X - 50K) s�o referentes a l�gica de neg�cios. Se eu puder transpor esses (X - 50K) para linguagem procedural no banco (Oracle com PL/SQL claro), eu tenho apenas cinquenta mil linhas de c�digo de aplica��o, que basicamente s�o apenas rotinas de interface com o usu�rio. Quando uma fun��o necessitar de um dado no banco, mas n�o souber como trat�-lo, chama-se uma stored procedure mais o tipo da opera��o realizada mais o dado a ser tratado. O banco faz o resto e retorna a resposta j� mastigadinha. Ou seja, j� n�o preciso compilar/interpretar no meu cliente milhares de linhas de c�digo com declara��es SQL, express�es regulares que tratem os dados de retorno, mais testes condicionais para descobrir como montar outras declaracoes SQL, nem gastar CPU com [m|b]ilh�es de itera��es em outros testes e rotinas que analisem, tratem, enviem e recebam esses dados. O que al�m de ser custoso em termos de processamento/banda, � simplesmente design ruim. Beleza, voltemos � nossa aplica��o (escrita numa linguagem qualquer, C++ a t�tulo de exemplo). Das X linhas que eu tinha, onde X podem estar na casa das dezenas ou centenas de milhares de linhas, eu s� tenho agora 50.000 linhas que tratam apenas de interface de usu�rio e chamadas a stored procedures. Supondo que dez mil linhas seriam essas chamadas, eu s� preciso me preocupar agora com 40.000 linhas se quiser portar para uma interface web em Perl, ou PHP, ou Java, ou mesmo um programa escrito numa linguagem qualquer num Palm ou outro dispositivo port�til (onde os recursos de processamento s�o baixissimos). O c�digo referente � LN est� totalmente centralizado no banco e eu posso ter a liberdade de escolher a ferramenta que desejar para acessar esses dados. Isso � B�SICO em desenvolvimento separado entre Dados - L�gica de neg�cios - Interface, que est� presente em menor nivel na arquitetura MVC (Model-View-Controller) da maioria das plataformas de desenvolvimento/kits de interface com o usuario/sistemas de documentacao que est�o surgindo atualmente, e � invi�vel pensar em qualquer projeto novo sem analisar esta abordagem. LN misturado com a aplica��o � coisa de Clipper, Cobol e ERP da Microsiga ;) N�O estou dizendo q o DB2 n�o suporta stored procedures. � claro que suporta. Mas PL/SQL � definitivamente a melhor linguagem para esse tipo de fun��o (e s� para ela ;)), al�m de, se for do seu gosto, o Oracle suportar procedimentos armazenados em N linguagens, como Java, C, COBOL (ugh), etc etc etc. E n�o, n�o venha defender o modelo relacional te�rico, pois tanto o DB2 como o Oracle batem de frente com muita coisa de l�. =] Usar o banco como plataforma de desenvolvimento � uma p*ta vantagem. Se eu quisesse um DB s� para servir de buraco-negro para os dados, guardava tudo em texto num filesystem e usava sed e grep. > Soh testei o websphere, se nao gosta dele use Apache-TomCat, eh quase > a mesma coisa :) > Agora se ele nao fosse pelo menos usavel acho que > Itau, Bradesco, Unibanco entre outros nao estariam usando :) Ainda bem q vc falou quase, o Tomcat � s� um interpretador de servlets/jsp, o Websphere � um container EJB e plataforma de deployment. E da� que esses bancos est�o usando? Quem sabe l� quantos problemas eles tem? Aposto minha m�o direita que 90% dos bancos ainda usam sistemas em COBOL com bancos em texto. Vou endossar um neg�cio desses para um projeto novo? Quem indica esse tipo de tecnologia n�o s�o t�cnicos, s�o PHBs. A IBM vende qualquer coisa para qualquer um, ela consegue vender at� Notes, imagine. O Websphere � tudo, menos est�vel. EU n�o garanto estabilidade de nenhum software meu rodando em Websphere, diferente de outros containers tipo WebLogic/JBoss/Oracle AS. Apesar do c�digo ser rigorosamente o mesmo. Desculpe se pareci grosso. � que n�o gosto de "argumenta��o ZDNet". E o pior que isso � o que mais fazem por aqui. N�o � pq meia d�zia de peixe grande est� mordendo o anzol que eu vou morder tamb�m. > Sim, voce gosta de Oracle :) Mas sinceramente, acho que entre os dois, > qualquer um fara o servico a contento (se bem > configurado/administrado). No meu caso o DB2 teve a vantagem de chegar > primeiro, e do curso de DBA que eu fiz de DB2 ser bem melhor que o > curso de leitura dinamica de apostila que foi o de DBA Oracle que eu > fiz :) Eu n�o gosto de Oracle. Eu gosto � de praia, caipirinha, churrasco, reggae, etc. Oracle? Oracle � apenas uma coisa que eu fa�o. Se precisar, fa�o DB2 tamb�m. Tomara que n�o precise ;). Mas se chegar o dia, tem que meter as caras, u�. Pra qualquer coisa � assim. Eu tb tenho cursos de Oracle. T�, grandes coisas. N�o acredito que cursos, certificados e diplomas medem o conhecimento de ningu�m. Vc e eu sabemos que a maior parte dos pepinos que somos obrigados a resolver n�o foram vistos durante os cursos. Espero sinceramente que as pessoas entendam que banco de dados � coisa s�ria e tem que ser administrado por quem entenda do assunto. Se n�o souber, contrate algu�m que saiba. T� careca de ver banco de dados mal-normatizado em produ��o e gente com cara de ponto de interroga��o se perguntando o que fez de errado. Quando n�o p�e a culpa no software. � mais f�cil, ele n�o tem como se defender. ;) -- N�n o Chithaeglir lasto beth daer; Rimmon n�n Bruinen dan in Ulaer. Assinantes em 25/08/2002: 2242 Mensagens recebidas desde 07/01/1999: 180503 Historico e [des]cadastramento: http://linux-br.conectiva.com.br Assuntos administrativos e problemas com a lista: mailto:[EMAIL PROTECTED]
