Oracle x Db2 comparativo

Pessoal, achei este material  legal ..  e resolvi compartilhar

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 IBM DB2 versão 9.7 já possui um compilador próprio para PL/SQL, sendo assim não precisa ficar ‘executando um de – para’ em toda a análise, já faz a compilação e grava da forma como o interpretador precisa. Para o TSQL (SQL Server e Sybase) que é bem parecido com SQL PL do DB2 existe esse de – para, passando pelo mesmo compilador gravando da forma que o interpretador precisa.

O interpretador nesse caso será o mesmo para as duas saídas, a figura abaixo mostra isso:

Para que esse interpretador funcione, essa opção precisa ser configurada DB2_COMPATIBILITY_VECTOR, abaixo quais as features que podem ser habilitadas, as com * precisam fazer o procedimento de parar e iniciar a instância. Para habilitar todas de uma vez utilizar palavra ORA:

Criando um database com todas as features habilitadas:

Obs.: O database tem que ser criado depois que é habilitada a compatibilidade ou não serão utilizadas, pois ficará um database nativo DB2.

Alguns tipos de dados e onde eram os maiores problemas nas migrações em versões anteriores, que agora podem não ser tão problemáticas:

Uma outra coisa que achei interessante (ou não, a prática daria essa resposta) é que pode ‘misturar’ o PL/SQL, TSQL e SQL PL no desenvolvimento dos mesmos objetos (function or procedures), poderia rolar pegar o que cada uma tem de melhor e fazer acontecer, agora, isso como mencionei somente o desenvolvimento do dia a dia daria a resposta, mas seria interessante avaliar.

Itens que no PL/SQL estão funcionais são alguns que utilizo diariamente e acabei listando abaixo sem ter certeza como era/é no DB2 (precisaria testar tudo para dar um veredito final e ai sim ter certeza):
– Os cursores, para retornos em procedures;
– Utilização normal de de Packages.Procedures e Packages.Funcitions;
– Os privilegios para outras roles (usuários) executar, normal;
– Utilização do %type para tabela.campo e %rowtype para tabela na declaração de variáveis;