Obs.: O post teve algumas correções em 02/09/2011.
Fiz um bootcamp da IBM para profissionais Oracle, chamado DB2DB2 Workshop for Oracle Professionals, que foi realizado pelo instrutor Otavio Nunes da IBM Brasil de Campinas-SP na unidade da Unisul Ponte do Imaruim, no final de cada um dos dois dias foram realizadas duas provas de certificação.
Provas que foram realizadas:
M45: voltada mais para mostrar que conheceu o produto com intuíto comercial.
730: voltada para Profissionais que dá a certificação IBM Certified Database Associate.
Minha intenção com este post é colocar a minha visão GERAL do que chamou atenção colocando em ambos os RDBMS.
A instalação em Oracle: com root criamos os grupos, usuário Oracle e nele fizemos a instalação de binários, criação de instância e para RAC segue a mesma linha. Se precisamos de mais uma instância criaremos mais um usuário. Em DB2: pode ser instalado em um usuário normal o binário, mas é sugerido instalar o binário como root por ser mais seguro não apagar os binários erroneamente. Após isso cada usuário de SO pode criar a sua instância, seu(s) database(s).
Os usuários em Oracle: dentro da instância create user. Em DB2: é necessário que o usuário seja do SO.
As configurações realizadas em Oracle: do banco e da instância é tudo junto. Em DB2: existe do DB (banco de dados) é da DBM (instância) essas são separadas.
Os logs de alertas do banco em Oracle: Quem nos auxilia muito é ‘Alert.log’ além de possuirmos os trace files. Em DB2: tem um semelhante com o nome de db2diag.log (inclusive este db2diag.log possui uma ferramenta para filtro do db2diag.log chamada db2diag). O List History File (db2 list history …) armazena informacoes sobre backup, restore, criacao – alteracao – delecao de tablespaces, quando uma tabela sofre alguma alteracao ou reorganizacao etc (db2 list history …).
As tablespaces tem o mesmo príncípio mas em Oracle: Temos os Datafiles. Em DB2: Temos os Conteiners.
Comparações dos comandos entre os dois:
No Oracle temos o Automatic Storage Management (ASM) e no DB2 Automatic Storage Table Space que trabalha exclusivamente com Storage, diferente do ASM nesse ponto.
Também tem uma ferramenta semelhante (ou melhor) de SQL LOADER (sqlldr) que é DB2 Load Utility, esse teria que instalar e começar a rodar, mas parece melhor.
Outras ferramentas de exportação e importação tipo o DATA PUMP do Oracle, me parecem meio fracas, chamam DB2 Export Utility e DB2 Import Utility. Existe outras duas a DB2LOOK Utility que exporta todo o database em DDL e DB2MOVE Utility que copia ou move schemas entre databases, também executa as funções do Export Utility e Import Utility acima citado.
O Oracle RAC tem uOraclem concorrente forte (no meu ponto de vista nesse momento, sem testar é claro) chamado pureScale que parece realmente melhor que o RAC, pois vem de toda a expertise da IBM em trabalhar com processamento distribuído.
Também possui o particionamento de tabelas, pouco diferente, terei que executar testas para citar corretamente as diferenças.
As views materializadas do Oracle são chamados de MQT no DB2, a idéia é a mesma.
A compressão de dados do DB2, segundo o instrutor é bem melhor que do Oracle, no entando disse que quase nem é necessário executar rebuild de indices quando temos muitas exclusões, que esse processo de compactação se encarrega disso. Esse sim, merece um teste com um comparitivo forte entre eles, quero ver se faço isso, mas não deve ser em breve.
Uma visão geral dessa comparação:
O próximo post eu coloco algumas coisas de desenvolvimento, mas já vale deixar aqui que o DB2 9.7 já possui um próprio compilador PL/SQL. Ainda vou fazer um outro falando sobre formas de backups entre eles, pois não ficou claro (também por tempo) como são no DB2.
Para quem tiver interesse veja aonde está ocorrendo no site: Information Management Technical Bootcamps
Obs.: Imagens retiradas do material oficial do curso dado pela equipe IBM DB2 Brasil.
Att,
capin
Parabéns, gostei do artigo, dá um breve overview comparativo entre estes dois gigantes. Muito Bom!
Alexsandro, era bem essa a idéia, até para poder escrever mais teria mesmo que comprovar testando.
Espero conseguir uns testes logo.
Obrigado.
capin
Alexsandro, esse treinamento foi mesmo um Overview do produto. Nada no treinamento é aprofundado pensando em vc sair de la pronto para trabalhar com DB2. Alias esse treinamento foi alterado para 3 dias devido o pouco tempo de correria. Agora pretendemos aprofundar um pouco mais mas sempre na ideia do Overview. Caso queira participar nao existe custo algum e é sempre bom termos pessoas de Oracle para podermos debater as features e as diferencas. Se precisar de algo estou a disposicao.
Legal Otávio, vou ver se participo sim. No meu trabalho atual está surgindo a necessidade de trabalhar também com DB2, então estes treinamentos vem bem a calhar.
Obrigado!
Então, da compactação o cara não te contou a história toda. A compactação depende de um dicionário que é criado qd vc manda.
A compactação vai se basear neste dicionário. Se o balanceamento de informações repetidas da tabela se alterar demais, a compatação diminui proporcionalmente.
É como a compactação do 10gR1, que era para OLAP. A do 11gR2 é adaptável, aí é recomendada para OLTP.
Sobre pfile / spfile, ele poderia ter explicado melhor, que são configurações diferentes para o DBM e os DBs.
O cara não citou Particionamento de Databases, este sim era o RAC anterior ao pureScale, mas era um Shared Nothing Cluster: cada máquina fica com um pedaço.
Outra coisa é o TAF versus Automatic Client Reroute: o do DB2 precisa que o banco que caiu este ativo! Ou seja, é só para manutenção planejada.
Outra grande diferença é os Buffer Pools nomeados do DB2, que o Oracle não tem. Vc pode colocar o Cache só para uma parte do banco, por exemplo.
O alert log do DB2 tb é muito superior (muitas opções de filtros), além de informar tudo, e não só o que é crítico.
Se o cara não explicou essas coisas pra vc, não conhece muito não. As diferenças entre os dois bancos não são simples, e os dois tem vantagens e desvantagens. Por exemplo, Oracle é campeão em TPC-C em Cluster enquanto DB2 é campeão em Single Instance.
Portilho,
Muito obrigado pelo comentário e realmente tem muito caminho a ser trilhado, espero conseguir realizar testes em breve.
Forte abraço.
capin
A compressao de dados no DB2 é melhor pois comprimi tudo que existe no database, diferente do Oracle e tambem trabalha com o dicionario de dados que trabalha com patterns e faz com que o dado seja inserido fisicamente em disco onde os padroes (patterns) se encontram. Com a compressao, a reorganizacao de tabelas nao se faz mais necessario. Nem o de indice pois o indice excluido é removido fisicamente e retirado da pattern. Esse vale mesmo um teste. Ah a TPC também ja fez um destes testes. Caso queiram dar uma olhadinha….hehehee
Ah um ponto que misturei com a compressao de dados na resposta acima e que acabei juntando com a compressao de dados. Na compressao de indice nao usamos um dicionario e sim varios algoritmos para efetuar a compressao. Em indices o que é comprimido é o leaf page do dado para reduzir custo de I/O e CPU….
O DB2 ira determinar o melhor desses algoritmos baseados no layout de dados para comprimir o indice e assim economizar storage.
Apenas dados no DB2 utilizam o dicionario.
O leaf page nada mais é que o mais baixo nivel do indice onde vc tem todas as keys dos indices (RIDs – record indetifier – identificador das records)
Otavio,
Obrigado pelas respostas.
Abraços
capin
Capin,
Bacana o seu artigo! A IBM tá investindo pesado com estes Workshops para DBAs Oracle com intuito de divulgar e incentivar o uso do DB2 LUW – principalmente as versões 9.7 e 9.8. Acho que vale a pena uma olhada neste link que fala do command line plus(CLPPlus), o equivalente do sqlplus do oracle em interface DOS.
abs,
http://www.ibm.com/developerworks/data/library/techarticle/dm-1109clpplussql/index.html?ca=drs-
Alexandre, obrigado.
Verdade … esqueci desse cara aí … bem interessante sim.
Abraços
capin
Olá Capin!
Muito boa as comparações, realmente o DB2 não fica muito atras do Oracle, ambos estão no mesmo nível…
Sobre as provas de certificação, eu fiz a prova 730 pela prometric e consegui a certificação, não achei a prova difícil… tem bastante questões que cobram o conceito. Creio que as provas de certificação da Oracle devem ser mais difíceis.
Att,
Sakamoto
MyTraceLog – Registro de um DBA
http://mytracelog.blogspot.com
Opa, eu acho que estão próximos sim, preciso usar um pouco para ver as reais dificuldades.
Eu consegui passar também. Da Oracle quero fazer uma até o final do ano.
Abracos
capin
Muito bom! Vlw!
Obrigado Dr.
Abracos
capin
Olá Capin,
Show de bola este post e até mesmo porque não a iniciativa da IBM nesses workshops oferecendo uma comparação do Oracle sobre DB2, sem mencionar que DB2 em OS/400 executa sobre um hardware específico para o database. Show de bola.
Se tiver mais informações sobre eles, será muito bom divulgar-los.
Abraços,
Rodrigo Almeida
Ae Rodrigo, está certo … se eu tiver mais info repasso, claro.
Vou tentar acompanhar um pouco isso tudo.
Valeu e obrigado pela presença.
Abraços capin
E ai CapiN. (Editado por capin! ehehehhe)
Tudo blz!Cara muito bom o post.Desvenda aqui alguns passos que nós precisamos saber sobre outros bancos principalmente a parte de Arquitetura das Tablespaces.O Alexandre Torres inclusive ja me passou um material que estou dando uma olhada..
Parabéns!!
Emerson
DBA Jr.
Emerson,
blz velho? Obrigado pelo apoio.
Me permiti alterar o meu apelido no comentário! ahahah Capin com N … CapiNzal! 😀
Abraços e ótimos estudos para nós!
capin
Pessoal,
Eu sou um dos instrutores do Workshop de DB2 para Profissionais Oracle. Coloco-me a disposição para esclarecimento de dúvidas ou ajuda com algum tópico. Caso queiram participar de algum semelhante ao que o Fernando participou , basta acessar o link abaixo e fazer inscrição para o mais próximo da sua localidade ou onde desejarem.
http://www.ibm.com/developerworks/data/bootcamps
Pessoal todo que passou por aqui e deixou sua contribuição agradeço muito, estou preparando a parte 2 para falar um pouco de desenvolvimento via PL/SQL no DB2, espero que seja o mesmo sucesso.
Abraços a todos e até logo.
capin
Capin , bom dia, tudo certo?
Interessante o post, sou DBA Oracle, e sempre tive algumas curiosidades que ele me esclareceu, porem, acho que temos que tomar cuidado ao fazer comparações baseado apenas em Workshops providos pela empresa interessada, no caso IBM, poderia ser Oracle, Microsoft, etc, cada uma vai puxar para o seu lado.
Falo pois, quando vou em apresentações de produdos na Oracle tudo é uma maravilha, 1000% mais rápido que o concorrente e, infelizmente, vemos na prática que não funciona sempre assim. Por isto antes de dizer que isto funciona melhor que aquilo, gosto fazer testes e mais testes e mesmo assim acho dificil chegar a uma conclusão,pois, cada ambiente tem suas particularidas, certamente em muitos ambiente o Oracle RAC atende melhor que o IBM PureScale e vice-versa.
Tambem notei que tem alguns conceitos errados de Oracle, por exemplo, no Oracle conseguimos configurar tanto a instância como database, não necessáriamente tudo junto.
Críticas à parte, parabéns pelo post e pelo blog.
Abs.
Ae Régis,
Obrigado pelo comentário e criticas, são com elas que crescemos.
A ideia dos posts é mostrar sobre o Workshop em si (os bootcamps), o que ELES colocaram em comparação. Em relação a apresentação promovidos por eles, achas que alguém vai apontar as suas falhas e falar das coisas boas dos outros? Difícil, até podem fazer algum comentário sútil sobre algum ponto, mas isso é normal entre todas as apresentações, temos que ter isso em mente, e claro que vale ressaltar.
Como comentei em vários lugares dos dois posts, teria que testar sim e concordo plenamente que mesmo testando/comparando é difícil chegar a uma conclusão, cada um vai ter o seu melhor e são muitas variantes, mas podemos chegar próximo ao melhor de algum dos dois (DB2 e Oracle), para um ambiente específico, uma solução específica etc.
Quando ao erro do conceito, poderia explicar melhor? Eu particularmente não entendo como configurar eles separados!
Obrigado pela colaboração.
Att,
capin
“A compressao de dados no DB2 é melhor pois comprimi tudo que existe no database, diferente do Oracle…”
Retirado da documentação:
Oracle 11gR2 comprime dados, índices e LOBs (além de Backup e Log para Data Guard):
Oracle Advanced Compression provides comprehensive data compression capabilities to compress all types of data, backups, and network traffic in an application transparent manner. With Advanced Compression, Oracle includes table compression targeted at OLTP workloads, resulting in reduced storage consumption and improved query performance while incurring minimal write performance overhead. Advanced Compression can be used to compress any unstructured content using SecureFiles Compression.
DB2 LUW 9.7 comprime dados, índices, e parte dos LOBs (além de Backup):
Data stored in base table rows and log records is eligible for row compression. In addition, the data in XML storage objects is eligible for compression. LOB data that you place inline in a table row can be compressed; however storage objects for long data objects are not compressed.
——————–
“Com a compressao, a reorganizacao de tabelas nao se faz mais necessario.”
A reorganização (com a finalidade de habilitar a compressão) era necessária no DB2 LUW 9.1, para que se criasse um dicionário de dados estático com os dados existentes na tabela. Na versão 9.5, um dicionário é criado automaticamente quando uma tabela atinge 1MB de dados inseridos, e passa a comprimir os dados baseados neste dicionário. Mas pense que se seus dados mudarem muito, o dicionário de compressão continua o mesmo, ou seja, pode passar a nem comprimir mais.
Era desta forma (com dicionário estático) que a compressão no Oracle antes do 11gR2 funcionava: a chamada compressão OLAP, pois só comprimia o que vinha em uma carga de dados, como CTAS ou SQL*Loader. No 11gR2 passou a levar em conta apenas os dados de um block de dados, o que teoricamente deve comprimir menos por possuir menos dados para comparação, mas não tem o problema da alteração da proporção dos dados em relação ao dicionário.
Retirado da documentação:
DB2 LUW 9.7:
Row compression uses a static dictionary-based compression algorithm to compress data by row. The dictionary is used to map repeated byte patterns from table rows to much smaller symbols; these symbols then replace the longer byte patterns in the table rows. The compression dictionary is stored along with the table data rows in the data object portions of the table.
Oracle 11gR2:
You can store heap-organized tables in a compressed format that is transparent for any kind of application. Compressed data in a database block is self-contained, which means that all information needed to re-create the uncompressed data in a block is available within the block. A block is also compressed in the buffer cache. Table compression not only reduces the disk storage but also the memory usage, specifically the buffer cache requirements. Performance improvements are accomplished by reducing the amount of necessary I/O operations for accessing a table and by increasing the probability of buffer cache hits.
—–
DB2 tem outras vantagens muito boas. Por exemplo, a integração real com TSM (os Archives podem ser enviados diretamente para Fita) e AIX (você pode configurar o DB2 para utilizar automaticamente toda a memória que o DB2 tiver, sem utilizar Swap, e se beneficiar da compressão de RAM do SO no AIX 7.0). Ou a criação (e posterior eliminação) automática de Redo Logs secundários, o que minimiza o problema de lentidão no Oracle por falta de Redo Logs (o evento Checkpoint Not Complete).
O DB2 possui um BACKUP DATABASE real, enquanto no Oracle isto é uma coleção de DATAFILEs (você pode ter apenas meio backup de DATABASE na mão).
Já não encontrei comparação à OWI no Oracle, que possibilita Tuning sem Checklist no DB2.
Também faz falta no DB2 algo equiparável ai Rolling Upgrade com o Oracle Data Guard, ou sua flexibilidade (até 30 Standby, Cascaded Standby, Logical Standby, Snapshot Standby).
Fontes:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/9f8bfefa-2918-4bf1-aff4-8690d9a249de/entry/db2_deep_compression_compress_c3_a3o_profunda_no_db213?lang=en
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.dbobj.doc/doc/c0056481.html?resultof=%22%64%65%65%70%22%20%22%63%6f%6d%70%72%65%73%73%69%6f%6e%22%20
http://download.oracle.com/docs/cd/E11882_01/license.112/e10594/options.htm#DBLIC142
http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/build_db.htm#PFGRF94152
Para auxiliar mais na discussão da compressão de dados entre Oracle e DB2 segue dois links que foram enviados pelo Portilho, já agradecendo! 😀
http://database-diary.com/2009/08/11/why-db2-data-compression-is-better-than-oracle-database/
http://database-diary.com/category/db2-for-luw/deep-compression/
capin
Caraca Capin, muito boa aí a discussão. Pretendo participar futuramente de um desses bootcamps da IBM p/ conhecer um pouco o DB2.
Migrado para o Certificação BD em 08/05/2012 por Capin!
Olá
Estou fazendo uma pesquisa acadêmica sobre os principais SGBDs e gostaria de saber se voces sabem se tem diferenças significativas entre os métodos de Junção de tabelas entre Oracle e DB2, principalmente entre os métodos abaixo:
– Nested Loop Join
– Hash Join
– Full Table Scan (oracle) x Segmented Tablespace Scan (DB2)
Como o código desses SGBDs são fechados, fica dificil saber, mas acredito que quem trabalha na prática, nota alguma diferença nos métodos. Qualquer ajuda é bem vinda!
Wiliam