Introdução

Um artigo anterior do developerWorks falava sobre como alavancar suas qualificações para o MS SQL Server 2000 para aprender sobre o DB2. Sua base é no Oracle em vez de no SQL Server? Se for, leia adiante. Neste artigo, mostraremos como usar seu conhecimento atual do Oracle 11g para se situar rapidamente com o DB2 9.7

O DB2 9.7 foi entregue com novos recursos para ajudar a gerenciar custos e simplificar desenvolvimento de aplicativos. Há aprimoramentos em diversas áreas, como compactação, pureXML, gerenciamento e desempenho. Este artigo foca uma comparação dos conceitos fundamentais do DB2 e do Oracle, juntamente com a introdução de novos recursos disponíveis no DB2 9.7

Nota: Para o restante deste artigo, vamos usar o termo "Oracle" para referência ao Oracle 11g e "DB2" para referência ao DB2 9.7 para Linux, UNIX e Windows.

Voltar para parte superior

Visão geral de estruturas do sistema

Para iniciar, precisamos entender a arquitetura usada pelo Oracle e como se compara ao DB2. Figura 1 mostra a estrutura de sistema do Oracle. Compare-a à Figura 2, que mostra a estrutura de sistema do DB2. Consulte essas figuras novamente para entendimento à medida que ler o artigo.

Voltar para parte superior

Instâncias

O conceito de uma instância é semelhante no Oracle e no DB2. Em ambos os casos, uma instância é uma combinação de processos de segundo plano e memória compartilhada. A principal diferença entre as duas é que no Oracle pode haver somente um banco de dados por instância, enquanto que no DB2 diversos bancos de dados podem compartilhar uma instância.

Como há uma correspondência de um para um entre o banco de dados e a instância, no Oracle, você cria uma instância implicitamente criando um banco de dados com o comando CREATE DATABASE. Como alternativa, para criar uma instância do Oracle em sua máquina, é possível usar o Database Configuration Assistant ou é possível usar o utilitário ORADIM, disponível com o Oracle 9i com a opção NEW. Você também deve fornecer determinadas informações, inclusive um Identificador do Sistema (SID) ou um nome de serviço, senha da instância, número máximo de usuários, modo de inicialização, etc. De forma semelhante, para excluir a instância, o utilitário ORADIM pode ser usado com a opção DELETE. Seria necessário passar o SID ou o nome do serviço. Não há nenhuma instância padrão criada com uma instalação nova do Oracle, a menos que seja criado um novo banco de dados durante o processo de instalação.

No DB2, após instalar o produto na plataforma Windows, a instância "DB2" é criada por padrão. No Linux e UNIX, o nome da instância padrão é "db2inst1". Para criar outra instância na mesma máquina, você simplesmente executa o comando db2icrt <nome da instância>.

Figura 3 mostra uma instância chamada DB2_01 criada com o comando db2icrt a partir da GUI do DB2 Control Center.

Para fazer referência a uma determinada instância do DB2 a partir da interface da linha de comandos, use a variável de ambiente DB2INSTANCE. Essa variável permite especificar a instância ativa atual à qual todos os comandos se aplicariam. Por exemplo, se DB2INSTANCE for configurada para PROD e você emitir então o comando create database MYDB1, será criado um banco de dados associado à instância PROD. Se quisesse criar esse banco de dados na instância DB2, então seria necessário primeiro alterar o valor da variável DB2INSTANCE para DB2. Isso é semelhante ao ORACLE_SID (Identificador do Sistema), que também é usado quando usuários querem alternar entre instâncias.

Outra maneira fácil de identificar a instância com a qual deseja trabalhar é usando a GUI do DB2 Control Center, conforme mostrado na Figura 3. Para ver uma entrada para a nova instância nesta ferramenta, pode ser necessário incluir a instância na GUI, clicando com o botão direito do mouse em Instances e escolhendo Add. Para eliminar uma instância no DB2, é possível executar o comando db2idrop <nome da instância>.

Em suma, no Oracle, o Database Configuration Assistant pode ser usado para criar, modificar, iniciar, parar e excluir a instância, enquanto que no DB2, a GUI do Control Center pode ser usada para um propósito semelhante. Além disso, uma instância do Oracle pode ter somente um relacionamento de um para um com um banco de dados, enquanto que no DB2 esse não é o caso. Diversos bancos de dados podem existir e ser usados simultaneamente em uma instância do DB2.

Voltar para parte superior

Bancos de dados

No Oracle, um banco de dados pode ser criado manualmente usando o comando CREATE DATABASE ou usando o Database Configuration Assistant. Criar o banco de dados manualmente requer que uma série de etapas seja seguida, inclusive a configuração das variáveis do S.O., a preparação do arquivo de parâmetro e a criação de um arquivo de senha antes do comando CREATE DATABASE poder ser executado.

As informações de metadados são armazenadas e gerenciadas pelo Data Dictionary, que é composto por tabelas base e visualizações correspondentes. As tabelas base são criadas automaticamente durante a criação do banco de dados e as visualizações são construídas por meio da execução dos scripts catalog.sql e catproc.sql.

O banco de dados Oracle é, portanto, visto como uma coleção de três tipos de arquivos:

• Arquivo de Dados: Contém dados reais, implementação física do banco de dados. (Semelhante a Contêineres no DB2)
• Arquivo de Recuperação: É equivalente a Logs de Transações no DB2.
• Arquivo de Controle: Contém informações para manter e verificar a integridade do banco de dados.

No DB2, uma instância pode conter diversos bancos de dados, conforme mostrado na Figura 2. Cada banco de dados é uma unidade verdadeiramente fechada e independente. Cada banco de dados tem seu próprio espaço de tabela de catálogo, espaço de tabela temporário e espaço de tabela de usuário, que são criados por padrão na criação bem-sucedida do banco de dados. O DB2 contém um arquivo binário conhecido como o diretório de banco de dados do sistema que contém entradas de todos os bancos de dados que é possível conectar a partir de sua máquina com o DB2. Esse diretório é mantido no nível da instância.

Quando uma instância é criada, nenhum banco de dados é criado por padrão. É necessário criar explicitamente um banco de dados usando o comando de criação de banco de dados. Também é possível criar um banco de dados usando o Control Center, conforme mostrado nas Figuras 4 e 5.

Na Figura 5, também é possível ver o que acontece quando você clica em Show Command. Todas as telas da GUI do DB2 Control Center permitem que você veja a instrução SQL ou comando que realmente é executado em segundo plano. Esses comandos podem ser salvos em scripts para execução posterior ou podem ser copiados e executados a partir da ferramenta Command Line Processor (CLP) ou da ferramenta de GUI Command Center. Essas ferramentas são equivalentes a SQL*Plus e iSQL *Plus do Oracle, respectivamente.

Um banco de dados DB2 pode ser descartado usando-se o comando 'DROP DATABASE' ou a partir da GUI do DB2 Control Center. No Oracle, esse comando não existe; um banco de dados é excluído ao apagar todos os arquivos de dados associados.

Os bancos de dados dentro de uma instância normalmente não interagem uns com os outros. No entanto, se seu aplicativo precisar interagir com mais de um banco de dados, esse requisito pode ser suportado ativando-se o suporte a federação . Consulte a seção recursos para obter um artigo sobre federação.

Voltar para parte superior

Contêineres, espaços de tabela, buffer pools e páginas

No Oracle, dados são armazenados fisicamente em arquivos chamados Arquivos de Dados. Isso é semelhante a contêineres no DB2, onde dados são armazenados fisicamente. Cada banco de dados Oracle contém um espaço de tabela denominado SYSTEM, que o Oracle cria automaticamente quando o banco de dados é criado. Outros espaços de tabela para dados de usuário, temporários e de índice precisam ser criados após o banco de dados ter sido criado e um usuário precisa ser designado a esses espaços de tabela antes de poderem ser usados.

No DB2, um espaço de tabela é um objeto lógico usado como uma camada entre tabelas lógicas e contêineres físicos. Ao criar um espaço de tabela, é possível associá-lo a um buffer pool (cache de banco de dados) específico, assim como a contêineres específicos. Isso fornece flexibilidade no gerenciamento de desempenho. Por exemplo, se houver uma tabela "quente", é possível defini-la em seu próprio espaço de tabela com seu próprio buffer pool. Isso ajuda a assegurar que os dados dessa tabela sejam armazenados em cache de forma contínua na memória.

No DB2, três espaços de tabela padrão são criados automaticamente na criação do banco de dados ao usar valores padrão para o comando CREATE DATABASE. A Tabela 1 descreve os espaços de tabela do DB2:

Como bancos de dados no DB2 são unidades independentes, espaços de tabela não são compartilhados entre bancos de dados. Como eles são conhecidos somente dentro de um banco de dados, dois bancos de dados diferentes podem ter espaços de tabela com o mesmo nome. É possível ver isso na Figura 2 em que o banco de dados MYDB1 tem um espaço de tabela denominado MYTBLS e o banco de dados MYDB2 tem um espaço de tabela com o mesmo nome.

Os espaços de tabela do DB2 podem ser classificados como SMS (espaços gerenciados pelo sistema) ou DMS (espaços gerenciados pelo banco de dados). Os espaços de tabela SMS são gerenciados pelo sistema operacional e podem ser somente diretórios. Eles crescem automaticamente, conforme necessário; assim SMS fornece bom desempenho com um mínimo de administração. Os espaços de tabela DMS são gerenciados pelo DB2 e podem ser arquivos ou dispositivos brutos. Esse tipo de espaço de tabela permite melhor desempenho, mas alguma administração é necessária. Por exemplo, é necessário especificar antecipadamente a quantia de espaço que você deseja alocar para o espaço de tabela, pois o crescimento não é automático.

O Oracle não tem o conceito SMS para seu modelo de armazenamento, mas seus arquivos de dados são semelhantes aos espaços de tabela DMS do DB2. Ou seja, é possível aumentar o tamanho de um banco de dados incluindo um arquivo de dados no espaço de tabela, aumentando o tamanho do arquivo de dados, ou incluindo um novo espaço de tabela.

A Tabela 2 abaixo mostra como os bancos de dados ou espaços de tabela Oracle são mapeados para bancos de dados ou espaços de tabela DB2.

Conforme indicado anteriormente, o conceito de buffer de dados do Oracle é equivalente ao buffer pool do DB2; no entanto, o DB2 permite que diversos buffer pools existam. Não há nenhum número de buffer pools predefinidos que podem ser criados e eles podem ter qualquer nome.

O conceito de um bloco Oracle é mais semelhante à página do DB2. Uma página do DB2 pode ter um tamanho de 4 k, 8 k, 16 k ou 32 k. Uma linha de tabela deve se ajustar em somente uma página; não pode se estender para outras páginas como no Oracle.

Voltar para parte superior

Nomes de objetos

Um nome de objeto do Oracle tem a seguinte forma:

[Schema_name.]object_name[@database]

No DB2, objetos também têm uma estrutura em duas partes:

Schema_name.object_name

Como no Oracle, o nome do esquema do DB2 é usado para agrupar objetos de forma lógica. Uma diferença importante, no entanto, é que no DB2, um nome de esquema não precisa corresponder a um ID de usuário. Qualquer usuário com um privilégio chamado IMPLICIT_SCHEMA pode criar um objeto usando um esquema não existente. Por exemplo, suponhamos que "Peter" tenha o privilégio IMPLICIT_SCHEMA e execute este comando:

CREATE TABLE WORLD.TABLEA (lastname char(10))

Nesse caso, a tabela WORLD.TABLEA é criada, em que WORLD é o novo esquema criado. Se Peter não tiver indicado explicitamente o esquema, então a tabela PETER.TABLEA teria sido criada, pois o ID de conexão é usado por padrão.

No DB2, você sempre se conecta a um banco de dados antes de emitir comandos específicos do banco de dados; portanto, sob essa arquitetura nomes de objetos não precisam incluir o nome do banco de dados.

Voltar para parte superior

Tabelas, visualizações e índices

Tabelas, visualizações e índices são basicamente os mesmos no Oracle e no DB2.

O DB2 fornece um utilitário chamado Design Advisor que pode ser usado para recomendar índices para uma consulta ou carga de trabalho específica. É possível chamar o Design Advisor a partir do DB2 Control Center ou do DB2 CLP usando o comando db2advis. No DB2, índices são amarrados diretamente à definição de tabela. Por exemplo, ao usar os espaços de tabela DMS, é possível especificar em qual espaço de tabela os índices podem residir da seguinte forma:

CREATE TABLE mytable (col1 integer, col2 char(10)) in tbls1 index in tbls2

O exemplo acima mostra que os dados da tabela serão armazenados no espaço de tabela 'tbls1', enquanto que as páginas de índices serão armazenadas no espaço de tabela 'tbls2'. Isso é em contraste à sintaxe do Oracle, em que a instrução CREATE INDEX fornece uma opção para especificar em qual espaço de tabela o índice irá residir.

Além disso, quando um índice tiver sido criado no DB2, não é possível alterar nenhuma cláusula de definição de índice. Seria necessário eliminar o índice e criá-lo novamente para implementar as mudanças.

Como no Oracle, as tabelas, visualizações e índices do DB2 podem ter os mesmos nomes. Tabelas e visualizações dentro do mesmo banco de dados devem ter nomes distintos, mas criar um índice com o mesmo nome que uma tabela ou visualização existente é permitido.

Voltar para parte superior

Procedimentos armazenados, acionadores e funções definidas pelo usuário (UDFs)

Os procedimentos armazenados do DB2 podem ser escritos em qualquer linguagem suportada pelos pré-compiladores do DB2, incluindo Java, C, C++, REXX, Fortran e COBOL. No entanto, a linguagem recomendada a ser usada é SQL Procedural Language (SQL PL), que é bem semelhante a PL/SQL do Oracle. Os procedimentos armazenados de SQL PL são fáceis de criar e ter bom desempenho. O desenvolvimento de procedimento armazenado do DB2 também suporta SQLJ e Java usando drivers JDBC tipo 2 e 4. Tipo 3 foi descontinuado.

O desenvolvimento de acionadores e funções pode usar SQL/PL sequencial, um subconjunto de SQL PL. A ferramenta Data Studio pode ser usada para criar, desenvolver, depurar e implementar facilmente os procedimentos armazenados e as funções definidas pelo usuário do DB2.

Voltar para parte superior

Arquivos de configuração

Tradicionalmente, o Oracle armazena todos os parâmetros relacionados à sessão e ao sistema em um arquivo de texto, normalmente referido como initSID.ora. No entanto, devido à natureza não persistente desse arquivo de texto, a partir do Oracle 9i, o Oracle apresentou Server Parameter File (SPFILE), que é um arquivo de parâmetro binário armazenado no servidor. Isso persiste durante encerramento e inicialização da instância. O arquivo initSID.ora ainda é usado; no entanto, quando um SPFILE não está disponível. Antes da introdução de SPFILE, quaisquer comandos ALTER SYSTEM e ALTER SESSION que tenham afetado parâmetros persistiriam somente durante essa instância ou essa sessão. O DBA teria de modificar manualmente o arquivo de texto initSID.ora toda vez que uma religação de uma instância de banco de dados fosse pretendida. As configurações de acesso à rede são geralmente armazenadas em listener.ora para o listener e em tnsnames.ora para acesso de cliente.

Com o DB2, os parâmetros de configuração são armazenados no nível da instância, conhecido como o arquivo de configuração do gerenciador de banco de dados, e no nível do banco de dados, conhecido como o arquivo de configuração do banco de dados. A maioria desses parâmetros pode ser alterada dinamicamente, ou seja, não há necessidade de parar e reiniciar a instância nem forçar todas as conexões de um banco de dados antes da alteração do valor do parâmetro ter efeito. Os arquivos nos quais o DB2 armazena suas informações de configuração não podem ser editados diretamente.

Se quiser alterar manualmente um parâmetro específico do gerenciador do banco de dados a partir do CLP, use o comando UPDATE DBM CFG USING <nome do parâmetro> <novo valor>.

Se quiser alterar manualmente um parâmetro específico do banco de dados a partir do CLP, use o comando UPDATE DB CFG FOR <nome do banco de dados> USING <nome do parâmetro> <novo valor>.

Esses comandos seriam os equivalentes de ALTER SYSTEM e ALTER SESSION do Oracle. Como alternativa, usando o Control Center, é possível revisar e alterar valores desses parâmetros; se você clicar com o botão direito do mouse em uma determinada instância e escolher Configure Parameters, verá a janela mostrada na Figura 6.

No nível do banco de dados, clicar com o botão direito do mouse em um determinado banco de dados e escolher Configure Parameters exibe a janela mostrada na Figura 7.

O DB2 fornece muitos parâmetros que podem ser usados para configurar seu sistema. No entanto, se você quiser uma maneira fácil de configurar o sistema automaticamente, use o comando autoconfigure (ou a GUI do Configuration Advisor) que configura os parâmetros de gerenciador do banco de dados e de configuração do banco de dados para valores otimizados com base em algumas informações fornecidas. Figura 8 mostra o Configuration Advisor.

Além dos arquivos de configuração, o DB2 também usa variáveis do DB2 Registry normalmente para configurações específicas da plataforma. Observe, as variáveis do DB2 Registry não têm nenhum relacionamento qualquer que seja com o registro do Windows. Use o comando db2set para revisar e alterar essas variáveis.

As informações de conectividade (acesso de rede) estão armazenadas no diretório de banco de dados do sistema, no diretório de banco de dados local e no diretório de nós. Esses são arquivos binários e podem ser modificados somente com os comandos CATALOG e UNCATALOG.

Voltar para parte superior

Arquitetura da memória, processos de segundo plano e encadeamentos

Em seguida, vamos dar uma olhada na arquitetura da memória, nos processos de segundo plano e nos encadeamentos e iremos comparar e contrastar como são usados no Oracle e no DB2.

A System Global Area (SGA) no Oracle é um grupo de áreas de memória compartilhada que armazena informações para a instância. Exemplos incluem cache de instruções, buffers de log de recuperação e cache de buffer de dados. As áreas de memória compartilhada Program Global Area (PGA) e User Global Area (UGA) contêm dados e informações de controle para processos do servidor e sessões de usuários.

O Oracle suporta diversas instâncias dentro da mesma máquina, mas processos de segundo plano não são compartilhados. Por exemplo, três instâncias em uma máquina irão requerer três conjuntos de processos de segundo plano. Portanto, geralmente é recomendado ter um banco de dados, uma instância e diversos esquemas dentro da mesma máquina.

O DB2 e o Oracle usam áreas de memória compartilhada, mas a arquitetura da memória do DB2 é implementada em uma maneira ligeiramente diferente da do Oracle. Como uma instância do DB2 pode conter mais de um banco de dados, existem dois níveis de configuração. Conforme mencionamos na seção anterior, a configuração do nível da instância pode ser realizada no arquivo DBM CFG enquanto que a configuração do nível do banco de dados é realizada no arquivo DB CFG. Os parâmetros de configuração em ambos os níveis podem ser ajustados para sintonizar o uso de memória. A seção abaixo fornece um pouco mais de detalhes sobre estruturas de memória e diferentes processos de segundo plano do DB2.

Diferentemente do Oracle, em que a memória é alocada para a instância e o banco de dados na inicialização, o DB2 aloca memória em diferentes níveis. Isso se deve principalmente devido ao fato de que uma instância do DB2 pode conter diversos bancos de dados. Há três estruturas de memória principais no DB2:

• Memória compartilhada da instância: Refere-se à memória compartilhada global do gerenciador do banco de dados, que é alocada quando a instância é iniciada usando o comando db2start , e permanece alocada até um comando db2stop ser emitido para parar a instância.
• Memória compartilhada do banco de dados: Refere-se à memória global do banco de dados, que é alocada quando o banco de dados é ativado ou conectado pela primeira vez. A memória alocada inclui buffer pools, lista de bloqueios, heap de banco de dados, heap do utilitário, cache de pacotes e cache de catálogo.
• Memória compartilhada do aplicativo: Refere-se à memória alocada quando um aplicativo conecta a um banco de dados e é usado por agentes que realizam o trabalho solicitado pelos clientes conectados. cada aplicativo conectado ao banco de dados tem memória alocada a ele; portanto, a configuração precisa dos parâmetros que afetam a memória compartilhada do aplicativo torna-se crucial.

O servidor de banco de dados DB2 deve executar muitas tarefas diferentes, como processar solicitações de aplicativos do banco de dados ou assegurando que registros de log sejam gravados no disco. Cada tarefa é geralmente executada por uma engine dispatchable unit (EDU) separada. No DB2 para Windows, Linux e UNIX , as atividades do servidor são realizadas na forma de encadeamentos. Encadeamentos e processos do DB2 operam nos níveis a seguir. Observe que esta e uma lista não exaurida, mas nós destacamos os encadeamentos e processos importantes:

• Nível da Instância: São processos e encadeamentos que são inicializados quando uma instância é iniciada:
  1. DB2 Daemon Spawner (db2gds): Processador de daemon global iniciado para cada instância (somente no UNIX)
  2. DB2 System Controller (db2sysc): Processo principal do DB2
  3. DB2 Watchdog (db2wdog): Processo pai para todos os outros processos
  4. DB2 Format Log (db2fmtlg): Semelhante ao processo ARCn no Oracle, pré-aloca arquivos de log no caminho de log
  5. Autonomic computing daemon (db2acd): Hospeda o monitor de funcionamento, utilitários de manutenção automática e o planejador de tarefas administrativo. Esse processo era conhecido formalmente como db2hmon.
  
  
• Nível do Banco de Dados: Esses são processos que são inicializados quando uma conexão é feita com um banco de dados.
  1. DB2 Log Reader (db2loggr): Semelhante ao subconjunto do processo PMON do Oracle. Esse processo lê arquivos de log durante o retrocesso, recuperação de reinicialização e avanço.
  2. DB2 Log Writer (db2loggw): Limpa log o buffer do log para os arquivos de log de transações no disco. Equivalente ao processo LGWR no Oracle.
  3. DB2 Page Cleaner (db2pclnr): Equivalente ao processo DBWR no Oracle, esse processo limpa o buffer pool antes de páginas do disco serem movidas para o BP.
  4. DB2 Prefetcher (db2pfchr): Recupera páginas do disco e coloca as mesmas no buffer pool antes de ser necessário.
  5. DB2 Deadlock Detector (db2dlock): Processo de detector de conflito.
  6. DB2 Self-Tuning Memory Manager (db2stmm): para o recurso automático de gerenciamento de memória de autoajuste.
  
  
• Nível do Aplicativo: Cada aplicativo que conecta ao banco de dados teria seu próprio compartilhamento de processos de segundo plano no nível do aplicativo associados a ele. São eles os seguintes:
  1. DB2 Communication Manager (db2ipccm): Processo de comunicação entre processos para cada cliente conectado localmente.
  2. DB2 TCP Manager (db2tcpcm): Processo de gerenciador de comunicações TCP para clientes remotos que conectam usando TCP/IP.
  3. DB2 Coordinating Agent (db2agent): Encadeamento que trata de todas as solicitações em nome de um aplicativo.
  4. DB2 Pooled Gateway Agent (db2agntgp e db2agntgp): Um agente armazenado em conjunto em um banco de dados remoto e banco de dados local, respectivamente.

Para obter uma explicação abrangente dos processos do DB2, consulte o artigo 'Everything you wanted to know about DB2 processes'.

Voltar para parte superior

Mecanismos de bloqueio

Bloqueio no Oracle pode ser manual ou automático. O Oracle Lock Manager pode bloquear os dados da tabela de forma implícita no nível da linha ou bloqueios padrão podem ser substituídos no nível da transação ou sessão usando as instruções SQL a seguir:
1. SET TRANSACTION ISOLATION LEVEL
2. LOCK TABLE
3. SELECT FOR UPDATE

O Oracle suporta um mecanismo chamado Multi-Version Read Consistency, que é implementado por dados undo nos segmentos undo.

O DB2 implementa níveis de Isolamento padrão ANSI, como Leitura Não Confirmada, Estabilidade do Cursor, Estabilidade de leitura e Leitura Repetida. Um usuário verá somente dados confirmados, a menos que o nível de isolamento Leitura Não Confirmada seja usado. Bloqueios de linha são adquiridos implicitamente de acordo com o nível de isolamento. Os objetos de banco de dados que podem ser bloqueados são espaços de tabela, tabelas e linhas; no entanto, somente tabelas e espaços de tabela podem ser explicitamente bloqueados. O comando LOCK TABLE pode ser usado para bloquear uma tabela em vez de usar o bloqueio de linha padrão.

Diferentemente do Oracle, no DB2, bloqueios são armazenados na memória e não nas páginas de dados. O parâmetro de configuração de banco de dados LOCKLIST pode ser usado para configurar a memória disponível para bloqueios, enquanto que o parâmetro de configuração MAXLOCKS define a quantia máxima de memória para bloqueios de um aplicativo específico.

No DB2 9.7, a geração de relatórios do evento de bloqueio foi aprimorada. O novo monitor de eventos de bloqueio coleta informações sobre tempos limite do bloqueio, conflitos e esperas de bloqueio que são mais do que uma duração especificada. Esses dados podem ser acessados a partir de um documento XML, de tabelas de banco de dados ou usando uma ferramenta baseada em Java (db2evmonfmt) para ler de um xml ou de um documento de texto.

Um novo parâmetro de configuração de banco de dados cur_commit foi introduzido e permite basicamente que somente dados confirmados sejam retornados, como era o caso anteriormente, mas agora leitores não esperam que gravadores liberem bloqueios de linhas. Em vez disso, os leitores retornam dados baseados na versão atualmente confirmada; ou seja, dados anteriores ao início da operação de gravação.

Voltar para parte superior

Segurança

O Oracle e o DB2 são bancos de dados seguros com recursos de segurança básicos e avançados. No Oracle, há 4 diferentes métodos de autenticação de usuário, da seguinte forma:

• Banco de dados: O banco de dados executa identificação e autenticação de usuários.
• Externo: O sistema operacional ou o serviço de rede executa autenticação
• Autenticação e autorização global: O usuário é autenticado globalmente por SSL
• Autenticação e autorização proxy: O servidor da camada intermediária executa autenticação.

O método de autenticação é especificado ao criar o usuário usando o comando CREATE USER . Há diversas visualizações Data Dictionary que contêm informações sobre esses usuários.

No DB2, usuários não existem dentro do banco de dados, mas são, em vez disso, gerenciados pelo sistema operacional. Nenhuma informação de login do banco de dados é mantida em nenhuma tabela de banco de dados. Qualquer usuário do sistema operacional pode potencialmente acessar o DB2; no entanto, a menos que tenham recebido uma determinada autoridade ou privilégio do DB2, não há muito que possam fazer. Concessão e revogação de autoridades e privilégios podem ser tratadas facilmente por meio da GUI do Control Center. Primeiro é preciso incluir um usuário ou grupo no Control Center a partir de usuários ou grupos disponíveis do sistema operacional.

Além disso, no DB2, o termo "funções" não é usado; em vez disso, o DB2 usa o termo "autoridades", que é semelhante às funções de banco de dados do Oracle, através das quais privilégios são concedidos a determinados grupos ou usuários. As autoridades suportadas com o DB2 são: SYSADM, SYSCTRL, SYSMAINT, SYSMON, SECADM, DBADM e LOAD.

As autoridades SYSADM, SYSCTRL e SYSMAINT não podem ser concedidas usando a instrução SQL GRANT. Essas autoridades especiais podem ser configuradas somente modificando os parâmetros de configuração específicos do gerenciador de banco de dados.

O DB2 também usa o termo "privilégio", que é semelhante aos privilégios de sistema e de objeto de esquema do Oracle. Existem privilégios do banco de dados (connect, createtab, etc.) e privilégios de objeto de banco de dados (schema, table, view, etc.). Figura 11 mostra informações de segurança do DB2 obtidas da GUI do Control Center. A maioria das guias mostradas na janela Change User corresponde aos privilégios suportados pelo DB2.

A autenticação no DB2 não envolve somente a criptografia de nomes de usuários e senhas, mas também permite a criptografia de dados à medida que viajam pela rede entre os clientes e o servidor. O local do processo de autenticação é determinado pelo valor do parâmetro de configuração do gerenciador de banco de dados AUTHENTICATION.

Seguem as opções válidas para ativar autenticação para o DB2:

• SERVER_ENCRYPT - Esse valor especifica que a autenticação ocorre no servidor. O ID do usuário e a senha especificados durante a conexão são criptografados e enviados ao servidor onde são comparados ao usuário e senha do lado do servidor. Se a correspondência for bem-sucedida, o usuário tem permissão para acessar o banco de dados.
• KRB_SERVER_ENCRYPT - Especifica que o servidor aceita autenticação KERBEROS ou esquemas de autenticação SERVER criptografados.
• DATA_ENCRYPT - Essa configuração especifica que o servidor permite autenticação SERVER e também que os dados que viajam pela rede entre o cliente e o servidor estão criptografados.
• DATA_ENCRYPT_CMP - Especifica que o servidor aceita esquemas de autenticação SERVER criptografados e a criptografia de dados do usuário. Esse tipo de autenticação permite compatibilidade com produtos de nível inferior que não suportam o tipo de autenticação DATA_ENCRYPT.
• GSS_SERVER_ENCRYPT - Isso especifica que o servidor aceita autenticação de plug-in baseada em API de GSS ou esquemas de autenticação de servidor criptografados.

Para atualizar o parâmetro de instância AUTHENTICATION, por exemplo, para um valor igual a DATA_ENCRYPT, use os comandos mostrados abaixo:

                
UPDATE DBM CFG USING AUTHENTICATION DATA_ENCRYPT
db2stop
db2start 

O DB2 estende ainda mais a segurança, oferecendo um mecanismo Label Based Access Control (LBAC). O recurso LBAC fornece maior granularidade para controlar acesso de leitura e gravação a linhas individuais e colunas da tabela. Uma função de administrador de segurança (SECADM) foi fornecida no DB2 e é necessária para manipular objetos de LBAC. Os usuários que tentam acessar um objeto devem ter seu rótulo de segurança concedido a eles. Quando houver uma correspondência, o acesso é permitido; sem uma correspondência, o acesso é negado.

Há outros aspectos de segurança do banco de dados além de privilégios e autoridades. Resumidamente, seguem algumas das diferenças e semelhanças entre o Oracle e o DB2:

Autenticação e autorização do usuário

O Oracle usa uma senha criptografada armazenada no dicionário quando um usuário é criado. O DB2 suporta senhas para autenticação do usuário e usa o usuário operacional subjacente para autenticação. Tanto o Oracle como o DB2 suportam LDAP (Oracle Internet Directory e IBM Directory Server). Tanto o Oracle quanto o DB2 suportam conexão única (SSO).

Criptografia de dados

O Oracle suporta criptografia de dados, em que dados confidenciais, como números de cartões de crédito e alguns dados de negócios altamente confidenciais podem ser criptografados. Você tem as seguintes opções para criptografar dados do DB2 em armazenamento:

• É possível usar as funções integradas de criptografia e decriptografia ENCRYPT, DECRYPT_BIN, DECRYPT_CHAR e GETHINT para criptografar seus dados dentro das tabelas de banco de dados.
• É possível usar o IBM Database Encryption Expert para criptografar os dados subjacentes do sistema operacional e os arquivos de backup.
• Se estiver executando um sistema DB2 Enterprise Server Edition no sistema operacional AI e estiver interessado somente na criptografia no nível do arquivo, é possível usar o sistema de arquivos criptografado (EFS) para criptografar os dados de seu sistema operacional e arquivos de backup.

Criptografia de rede

O Oracle fornece criptografia de rede com Oracle Advanced Security. O Oracle usa as criptografias padrão de mercado DES, 3DES e RC4. Para criptografar dados em trânsito entre clientes e bancos de dados DB2, é possível usar o tipo de autenticação DATA_ENCRYPT ou o suporte do sistema de banco de dados DB2 de Secure Sockets Layer (SSL).

Trilha de auditoria

O Oracle permite realizar trilha de auditoria de usuários e objetos. O minerador de log também pode ser usado para investigar e analisar consultas suspeitas. O DB2 fornece um recurso de auditoria semelhante. O utilitário db2audit pode ser usado para esse propósito.

Voltar para parte superior

Suporte a XML

Esta seção compara o suporte a XML do Oracle ao do DB2. Enviado com o Oracle 9i Release 2, o recurso Oracle XML DB fornecia uma maneira de gerenciar armazenamento, recuperação e esquema XML definindo tabelas e colunas XMLTYPE que são armazenadas como CLOB ou retalhadas (decompostas) em pequenos pedaços em tabelas relacionais. O Oracle 10g veio com algumas melhorias para gerenciar documentos XML; por exemplo, mudanças no esquema podem ser refletidas dinamicamente pelo mapeamento de dados existentes sem a necessidade de reimportar. No Oracle 11G, um terceiro tipo de suporte a XML chamado XML binário foi apresentado. Portanto, agora o Oracle tem as seguintes maneiras para armazenar dados XML:

• Armazenamento não estruturado usando CLOBs (também conhecido como armazenamento sem esquema)
• Armazenamento estruturado que mapeia XML para
• Armazenamento XML binário relacional de objeto

A tecnologia pureXML do DB2 armazena documentos XML de forma nativa, ou seja, internamente no formato em árvore. Também permite o uso de SQL com extensões XML, Xquery e Xpath para acessar dados relacionais e XML. Armazenar documentos XML de forma nativa é uma melhor abordagem e a pesquisa da IBM indica que há um melhor desempenho para pesquisa e recuperação de documentos XML e redução nas linhas de código para determinados programas. Suporte para o tipo de dados XML do DB2 está disponível no DB2 Control Center, no processador de linha de comandos, no IBM Data Studio e no IBM Database Add-Ins for Microsoft Visual Studio.

Para usar o recurso pureXML em seu banco de dados, crie o banco de dados como UNICODE (por exemplo, usando o conjunto de código UTF-8). Falha em criar um banco de dados UNICODE antes da criação de uma tabela resultará em um erro, conforme mostrado abaixo:

SQL1239N  XML features can only be used in a Unicode database with a single database 
partition.  SQLSTATE=42997

O DB2 armazena dados relacionais como em versões anteriores. No entanto, dados XML são armazenados em formato hierárquico (como uma árvore usando o Modelo de Dados Xquery, XDM). Há uma forte integração entre XML e serviços relacionais. Para armazenar documentos XML, um usuário precisa criar uma tabela e especificar uma coluna para usar um novo tipo de dados, XML, conforme mostrado no exemplo abaixo.

                
CREATE TABLE T
  (ID INT PRIMARY KEY NOT NULL, COMMENT VARCHAR(1000) NOT NULL, DOCUMENT XML) 
  in ttspace compress yes@ 

À medida que documentos XML são armazenados em formato hierárquico analisado de forma nativa no Modelo de Dados XQuery (XDM), não há necessidade de conversão ou de mapeamento; o formato usado para armazenar documentos XML é o formato usado para processamento. Isso permite melhor desempenho.

Utilitários, como backup, restauração e importação se aplicam a tabelas com colunas XML da mesma maneira que em quaisquer outras tabelas. Dados XML podem ser inseridos na coluna XML usando a instrução INSERT ou usando o utilitário DB2 IMPORT. Antes de importar documentos XML recebidos de terceiros, é uma boa ideia validar esses documentos com relação a um esquema XML predefinido. Para registrar com relação a um esquema XML, DBAs precisam emitir o comando REGISTER XML SCHEMA, terminado com COMPLETE XML SCHEMA para concluir o processo de registro. O DB2 também suporta índices a serem criados em um subconjunto de um documento XML ou no documento inteiro. Um XPATH precisa ser especificado ao criar um índice que apontaria para esse elemento/atributo específico a ser indexado.

Com o DB2, agora você tem quatro maneiras para acessar dados relacionais e XML:

• SQL simples (nenhuma XQuery envolvida)
• SQL/XML, ou seja, XQuery embarcada em SQL
• XQuery como uma linguagem independente (nenhuma SQL envolvida)
• Xquery com SQL embarcada

No DB2 9.7, recursos XML adicionais foram incluídos, como suporte para o tipo XML em Funções Definidas pelo Usuário. Aprimoramentos importantes no DB2 9.7 são que o utilitário LOAD agora pode ser usado para carregar dados XML. Além disso, em tabelas particionadas, índices sobre dados XML criados com o DB2 V9.7 ou anterior não são particionados. A partir do DB2 Versão 9.7 Fix Pack 1, é possível criar um índice sobre dados XML em uma tabela particionada como particionado ou não particionado.

Há mais artigos do developerWorks sobre os recursos do IBM pureXML, como Consulte dados XML do DB2 com XQuery, Consulte dados XML do DB2 com SQL entre outros para discussões mais profundas.

Voltar para parte superior

Particionamento

O Particionamento do Oracle oferece diversas estratégias de particionamento que controlam como o banco de dados coloca dados em partições. As estratégias básicas são particionamento de intervalo, de lista e hash.

O particionamento de tabela do DB2 (também conhecido como Particionamento de intervalo) é semelhante ao particionamento do Oracle. Basicamente, permite que uma única tabela lógica seja dividida em diversos objetos de armazenamento físico em um ou mais espaços de tabela. Cada um dos objetos corresponderia a uma partição e permitiria que cada espaço e tabela contivesse um intervalo de dados que possa ser acessado muito facilmente.

No DB2, há diversas maneiras para particionar seus dados e é possível aplicar esses métodos simultaneamente aos mesmos dados. Para evitar confusão, segue uma explicação curta sobre as diferentes maneiras de fornecer esse particionamento:

• DATABASE PARTITIONING - distribuindo dados por meio de hash chave entre nós lógicos do banco de dados (DPF).
• RANGE/TABLE PARTITIONING (Disponível com o DB2 9) - dividindo dados por meio de intervalo chave entre diversos objetos físicos dentro de uma partição de banco de dados lógico.
• MULTI DIMENSIONAL CLUSTERING (MDC) - organizando dados na tabela (ou no intervalo de uma tabela) por meio de diversos valores chaves.

Na Versão 9.7, é possível ter índices que fazem referência a linhas de dados entre todas as partições em uma tabela particionada de dados (conhecidos como índices não particionados) ou o índice em si pode ser particionado, de forma que cada partição de dados tenha uma partição de índice associada. É possível ter índices não particionados e particionados para tabelas particionadas.

O exemplo a seguir cria um cliente de tabela no qual linhas com l_shipdate >= '01/01/2006' e l_shipdate <= '03/31/2006' são armazenadas no espaço de tabela ts1, linhas com l_shipdate >= '04/01/2006' e l_shipdate <= '06/30/2006' estão no espaço de tabela ts2, etc. Uma explicação mais extensa pode ser obtidas no artigo do developerWorks, Table partitioning in DB2 9.

                    
CREATE TABLE customer (l_shipdate, l_name CHAR(30)) 
IN ts1, ts2, ts3, ts4, ts5 
PARTITION BY RANGE(l_shipdate) 
   (STARTING FROM ('01/01/2006') 
    ENDING AT ('12/31/2006') 
    EVERY (3 MONTHS))
 

Uma comparação da terminologia de particionamento do Oracle e do DB2 pode ser localizada na Tabela 1 do artigo Migrate from Oracle or Sybase to DB2 in weeks.

Voltar para parte superior

Compactação

Há três recursos de compactação fornecidos pela Oracle: compactação no nível do índice, da tabela e da linha. O planejamento incorreto desses recursos pode ter um efeito adverso no desempenho.

O Oracle introduziu a compactação de índice desde a versão 8i. Índices que podem ser compactados são tabelas organizadas de bitmap, árvore B e índice. O uso da compactação de índice é direto; por exemplo, para criar um índice com o recurso de compactação, use:

                    
CREATE INDEX ord_customer_ix_demo 
ON orders (customer_id, sales_rep_id)
COMPRESS 1;
 

Para índices que não foram criados inicialmente com compactação, é possível levá-los à compactação alterando os mesmos. A Listagem 5 mostra um exemplo de como é possível alterar um índice para incluir compactação.

                    
alter index ord_customer_ix_demo rebuild compress

Atualmente, o Oracle não fornece nenhum orientador automatizado para indicar quais índices devem ser compactados. A maioria dos benefícios obtidos pela compactação de índice requer planejamento adequado por DBAs experientes que tenham conhecimento íntimo de Oracle CBO.

A compactação de tabela, por outro lado, foi apresentada no Oracle 9i release 2. Pode ser usada para compactar tabelas inteiras, partições de tabelas e visualizações materializadas. A compactação pode ser aplicada a todas as partições ou a algumas partições. Apesar de a compactação de tabela funcionar para uma tabela não particionada, seu uso para tabelas não particionadas em cargas de trabalho OLTP pode não ser desejado, já que o desempenho de inserção e atualização podem sofrer. Na compactação de tabela do Oracle, valores duplicados são removidos em um bloco do banco de dados e as informações são armazenadas para recriar os dados não compactados dentro do bloco.

O exemplo a seguir mostra como criar a tabela de partição com compactação.

                    
CREATE TABLE costs_demo (
   prod_id NUMBER(6), time_id DATE,
   unit_cost NUMBER(10,2), unit_price NUMBER(10,2))
PARTITION BY RANGE (time_id)
   (PARTITION costs_old
       VALUES LESS THAN (TO_DATE('01-JAN-2003', 'DD-MON-YYYY')) COMPRESS,
    PARTITION costs_q1_2003
       VALUES LESS THAN (TO_DATE('01-APR-2003', 'DD-MON-YYYY')),
    PARTITION costs_q2_2003
       VALUES LESS THAN (TO_DATE('01-JUN-2003', 'DD-MON-YYYY')),
    PARTITION costs_recent VALUES LESS THAN (MAXVALUE));
 

Para tornar uma tabela em uma tabela compactada, use alter table <nome da tabela> move compress. Uma tabela compactada, no entanto, não permite a inclusão ou eliminação de colunas.

No DB2 9.7, a compactação de linha, também referida como compactação profunda compacta linhas de dados substituindo padrões de valores que se repetem por linhas com cadeias de caracteres de símbolos mais curtas. Das várias técnicas de compactação de dados disponíveis no DB2 9.7, a compactação de linha oferece as maiores possibilidades para economias de armazenamento. A compactação de linha requer a criação de um dicionário que armazena um mapeamento entre padrões ou entradas repetitivos e chaves numéricas. O algoritmo de compressão é inteligente o suficiente para não compactar linhas que não irão realizar em qualquer economia de espaço em disco significativa.

A compactação de linha do DB2, diferentemente da compactação de chave do Oracle, não requer chaves para ser especificada.

A compactação é ativada no nível de tabela individual por meio dos comandos CREATE TABLE ou ALTER TABLE. Por exemplo:

CREATE TABLE Sales COMPRESS YES 
ALTER TABLE Sales COMPRESS YES 

Para obter o mesmo efeito usando o DB2 Control Center, durante a definição de coluna (segunda etapa no assistente de criação de tabela), assegure que a caixa de seleção Store table data in a compressed format selecionada na parte inferior do painel seja escolhida (como o diagrama a seguir mostra).

O dicionário de tabela é criado somente quando REORG é executado, após o qual os dados da tabela podem ser compactados. O dicionário é atualizado para cada operação REORG subsequente. Os dados compactados são mantidos no disco e na memória e o DB2 também compacta dados do usuário armazenados em arquivos de log, reduzindo assim o tamanho do arquivo de log.

Observe que cada partição de uma tabela particionada pode ter dicionários de compactação diferentes e cada partição de uma tabela no DPF pode ter dicionários de compactação diferentes.

Além disso, compactação de linha de dados, além dos mecanismos de compactação oferecidos pelo DB2 9.7 incluem:

• NULL e Default Value Compression (V8 GA): Compactação para dados nulos de comprimento zero em colunas de comprimento variável e valor padrão do sistema.
• Multidimensional Clustering (V8 GA): Implementa uma forma de compactação de índice, usando índices de bloco, uma entrada de índice para milhares de registros.
• Database Backup Compression (V8 FP4): Compactação para resultar em imagens de backup menores.
• XML Parsing

Voltar para parte superior

Recursos Autônomos

Há algumas melhorias de ajuste fornecidas no Oracle 11g. O Oracle automatizou as seguintes áreas de ajuste:

• Redo Logfile Sizing Advisor - Esse recurso recomenda o tamanho otimizado de arquivos de log de recuperação para evitar E/S de disco excessivas devido a ponto de verificação frequente.
• Automatic Checkpoint Tuning - O Banco de Dados Oracle agora pode fazer autoajuste de ponto de verificação para obter bons tempos de recuperação com baixo impacto em rendimento normal. Não é mais necessário configurar quaisquer parâmetros relacionados a ponto de verificação.
• Automatic Shared Memory Tuning - Automatic Shared Memory Tuning automatiza a configuração de parâmetros relacionados a memória da System Global Area (SGA) (cache de buffer, conjunto compartilhado) por meio de algoritmos de autoajuste. Simplifica configuração de banco de dados, assegura utilização mais eficiente de memória disponível e melhora o desempenho.
• Transaction Rollback and Recovery Monitoring - Esse recurso permite que você faça uma estimativa de quanto tempo levará para reverter uma transação. Também é possível monitorar o progresso de transações que estão sendo recuperadas e estimar a velocidade média de recuperação de transação.
• SQL Tuning - O SQL Tuning Advisor ajusta automaticamente instruções SQL de alto custo.
• Automatic Storage manager - O automatic storage manager (ASM) simplifica o gerenciamento de arquivos relacionados ao Oracle.

O Oracle também fornece a alguns orientadores, como segment e undo advisors. O segment advisor é baseado no nível de fragmentação de espaço dentro de um objeto e, como resultado, fornece conselho sobre se um objeto é um bom candidato para a nova operação de redução on-line. Além disso, esse orientador fornece relatórios sobre a tendência de crescimento histórico de segmentos e provou ser especialmente informativo para planejamento de capacidade.

O Undo Advisor, por outro lado, ajuda os administradores a fazerem o julgamento correto no dimensionamento de espaço de tabela undo, tanto no recurso de flashback como no não de flashback. Ele aconselha os administradores a configurar UNDO_RETENTION de forma apropriada para evitar o velho problema 'captura instantânea muito antiga'.

O DB2 9.7 tem diversos recursos autônomos para ajudarem no gerenciamento de seu ambiente que são autoconfiguração, autorregeneração, auto-otimização e autoproteção. Sentindo e respondendo a situações que ocorrem, a computação autônoma desloca a dificuldade de gerenciar um ambiente de computação de administradores de banco de dados para tecnologia.

Ajuste de memória automática

O DB2 9.7 possui um recurso de memória de autoajuste chamado Tuning Memory Manager que simplifica a tarefa de configuração de memória configurando valores automaticamente para diversos parâmetros de configuração de memória. Quando ativado, o ajustador automático agindo como dispatcher descobrirá os recursos de memória disponíveis e distribuirá os mesmos para diversos consumidores de memória do banco de dados dinamicamente. A memória de autoajuste aplica-se somente a bancos de dados de partição única.

Configuração automática

Com o comando AUTOCONFIGURE, é possível calcular e exibir valores iniciais do tamanho do buffer pool, parâmetros de configuração do gerenciado de banco de dados e da configuração do banco de dados, com a opção de aplicar esses valores recomendados.

Gerenciamento de armazenamento automático

O armazenamento automático aumenta automaticamente o tamanho de seu banco de dados entre sistemas de disco e de arquivos e, como aumenta automaticamente o tamanho do banco de dados, ele remove a necessidade de gerenciar contêineres de armazenamento por DBAs. Ao criar banco de dados no DB2 9.7, o recurso de gerenciamento de armazenamento automático é ativado por padrão.

Manutenção Automática

O DB2 9.7 tem recursos de manutenção automática que são usados para executarem automaticamente funções de manutenção, como:

• Backups automáticos de banco de dados que fornecem a capacidade de um backup completo de banco de dados executado conforme necessário.
• Coleção automática de estatísticas. O DB2 determina quais estatísticas são necessárias e precisam ser atualizadas e, em seguida, executa automaticamente o utilitário RUNSTATS em segundo plano.
• Reorganização automática de tabela e índice. O DB2 determina uma reorganização de tabela ou índice por meio de verificação periódica de tabelas e índices que tiveram suas estatísticas atualizadas e planeja tais operações sempre que forem necessárias.

Voltar para parte superior

Ferramentas

Devemos dar uma olhada em ferramentas de diferentes áreas, como ferramentas de criação e manutenção, rede, GUI de administração, ajuste de desempenho, movimentação de dados e recuperação de backup. A Figura 13 mostra as ferramentas da GUI do DB2 9.7.

Vamos dar uma olhada como tarefas semelhantes são executadas no Oracle e no DB2 9.7.

Criação e Manutenção do Banco de Dados

O Oracle fornece o Database Configuration Assistant (dbca) como a ferramenta de GUI para criar bancos de dados. Para manutenção de banco de dados, o Oracle fornece o Oracle Enterprise Manager. Os bancos de dados DB2 podem ser criados e mantidos a partir do DB2 Control Center.

Rede

O Oracle fornece o Network Configuration Assistant (netca) para configuração de rede. Como alternativa, é possível usar o Oracle Network Manager para configurar nomenclatura de serviço, listener, perfil e servidores de nomes Oracle. O DB2 usa o comando CATALOG para catalogar nós e bancos de dados. A catalogação também pode ser feita usando a linha de comando do DB2 ou a GUI do DB2 Configuration Assistant.

Administração

O Oracle Enterprise Manager fornece uma ampla faixa de recursos administrativos para tarefas do dia a dia de administradores. O DB2 Control Center fornece funções semelhantes às do Oracle Enterprise Manager. Além do DB2 Control Center, também é possível usar o processador de linha de comando do DB2 para emitir instruções DDL e DML. Esse utilitário é semelhante ao utilitário SQLPLUS do Oracle. Figura 14 mostra o processador de linha de comando do DB2.

Comandos também podem ser emitidos a partir do Command Center, mostrado na Figura 15.

Ajuste de desempenho

O Oracle Enterprise Manager vem com o Change Management Pack, Tuning Pack e Diagnostic Pack. O DB2 fornece o Activity Monitor, o Event Analyzer, o Health Center, o Indoubt Transaction Manager e o Memory Visualizer como ferramentas de GUI para tarefas de ajuste de desempenho.

Movimentação de dados

O Oracle fornece o SQL Loader (sqlldr) para carregar dados em formato de texto delimitado. A importação (imp) e a exportação (exp) podem ser usadas para executarem importação e exportação lógicas. O DB2 fornece utilitários de importação, exportação e carregamento semelhantes. Para movimentação de dados entre plataformas, o DB2 fornece o utilitário db2move.

Backup e Recuperação

O Oracle fornece o Recovery Manager como uma opção para hot backup. O backup de bancos de dados no DB2 pode ser realizado usando o comando backup ou o DB2 Control Center.

O Oracle 11g Enteprise Manager vem com novos gráficos de visão geral de desempenho. A interface HTML aprimorada do Oracle Enterprise Manager fornece um ponto central de acesso a todas as estatísticas de banco de dados relacionadas a desempenho e facilita monitoramento e diagnóstico completo.

Além das interfaces que são enviadas com o DB2 9.7, há uma ferramenta de desenvolvimento de aplicativo gratuita, baseada na estrutura Eclipse chamada IBM Data Studio (Data Studio). O Data Studio é um centro de parada única para criar, editar, depurar, implementar e testar procedimentos armazenados e funções definidas pelo usuário do DB2. Também é possível usar o Data Studio para desenvolver aplicativos SQLJ e criar, editar e executar instruções SQL e consultas XML.

É possível fazer download do IBM Data Studio a partir do Web site do developerWorks.

Para obter detalhes adicionais sobre o IBM Data Studio, revise este tutorial no developerWorks. Para obter exemplos e recursos, consulte o artigo da página da Web IBM Data Studio Features and Benefits no developerWorks.

Voltar para parte superior

Resumo

Neste artigo, apresentamos o DB2 9.7 para Linux, UNIX e Windows, usando seu conhecimento atual do Oracle 11g como alavanca. Descrevemos de forma resumida a arquitetura, os processos de segundo plano, o modelo de memória, a segurança, as ferramentas, etc. do DB2. Há muitas semelhanças entre o Oracle e o DB2 9 e indicamos algumas das diferenças para que seja possível usar seu conhecimento atual para se tornar bem-sucedido com o DB2 9.7.

A Tabela 3 resume as diferenças e semelhanças entre o Oracle e o DB2 que discutimos.

Recursos

Aprender

• O artigo "Migrate from Oracle or Sybase to DB2 in weeks" (Data Management Magazine, outubro de 2010) contém algumas comparações úteis de terminologia e tecnologia do DB2 e do Oracle.
  
  
• O artigo " DB2 9.7: Execute aplicativos Oracle em DB2 9.7 para Linux, UNIX e Windows " (developerWorks, maio de 2010) descreve o suporte pronto para uso para os dialetos SQL e PL/SQL do Oracle no DB2 9.7.
  
  
• "IBM Data Movement Tool" (developerWorks, novembro de 2010): Mova dados de bancos de dados de origem para o DB2 facilmente.
  
  
• " An inside look at IBM DB2 Advanced Enterprise Servier Edition" (developerWorks, março de 2011): Aprenda sobre um pacote configurável do software que empacota o DB2 com ferramentas de otimização, desenvolvimento e gerenciamento.
  
  
• A publicação Redbooks® Oracle to DB2 Conversion Guide: Compatibility Made Easy é um guia de migração do Oracle para o DB2. Ele descreve os novos recursos compatibilidade dos bancos de dados DB2 e Oracle, nova tecnologia, melhores práticas para mover para o DB2 e como tratar de alguns cenários comuns.
  
  
• O artigo "Everything you wanted to know about DB2 processes" (developerWorks, abr 2003) descreve os processos que o DB2 usa em Linux, UNIX e Windows e detalha suas funções.
  
  
• A publicação IBM Redbooks Oracle to DB2 Conversion Guide for Linux, UNIX, and Windows é um guia passo a passo para migrar do Oracle para o DB2.
  
  
• Visite a página de recursos do developerWorks para o DB2 para Linux, UNIX e Windows para ler artigos e tutoriais e se conectar a outros recursos para expandir as suas qualificações no DB2.
  
  
• Saiba mais sobre os conceitos, o planejamento e a instalação do O DB2 Express-C, a versão gratuita do DB2 Express Edition para a comunidade.
  
  

Obter produtos e tecnologias

• Faça download de uma versão de teste gratuita do DB2 para Linux, UNIX e Windows.
  
  
• Agora é possível usar o DB2 gratuitamente. Faça o download de O DB2 Express-C, uma versão gratuita do DB2 Express Edition para a comunidade que oferece os mesmos recursos de dados principais que o DB2 Express Edition e fornece uma base sólida para desenvolver e implementar aplicativos.
  
  
• Faça o download de Versões de avaliação de produtos IBM e entre em contato com as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2, Lotus®, Rational®, Tivoli®e WebSphere®.
  
  

Discutir

• Participar do fórum de discussão.
  
  
• Confira blogs do developerWorks e participe da comunidade comunidade do developerWorks.
  
  

Sobre os autores

Suita Gupta faz parte da equipe de GTS Information Management Support baseada na IBM Farnborough, Reino Unido. Ela fornece suporte técnico para DB2 aos clientes. Em sua função anterior, Suita trabalhava como Consultora Técnica no IBM Innovation Center, em Kuala Lumpur, ajudando ISVs em iniciativas de migração do DB2. Suita pode ser contata pelo e-mail suitagup@uk.ibm.com.

Alian Tham trabalha com Suporte Técnico de Pré-venda do DB2 Content Manager para Parceiros de Negócios na IBM Malásia. Allan ajuda os parceiros de negócios a solucionarem uma ampla gama de problemas técnicos. Allan possui certificação para administração de DB2 Content Management. Antes de entrar na IBM, Allan trabalhava em um ambiente de usuário final onde foi DBA de Oracle por 3 anos.

Raul Chong é consultor de banco de dados do Laboratório de Toronto da IBM e trabalha principalmente com Parceiros de Negócios IBM. Raul trabalha há seis anos na IBM, três deles em Suporte Técnico para o DB2 9.1 e os outros três como consultor especializado em desenvolvimento de aplicativo de banco de dados e migrações de outros RDBMSs para o DB2 9.1.

Allan Tham trabalha com Suporte Técnico de Pré-venda do DB2 Content Manager para Parceiros de Negócios na IBM Malásia. Allan ajuda os parceiros de negócios a solucionarem uma ampla gama de problemas técnicos. Allan possui certificação para administração de DB2 Content Management. Antes de entrar na IBM, Allan trabalhava em um ambiente de usuário final onde foi DBA de Oracle por 3 anos.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Visão geral de estruturas do sistema
• Instâncias
• Bancos de dados
• Contêineres, espaços de tabela, buffer pools e páginas
• Nomes de objetos
• Tabelas, visualizações e índices
• Procedimentos armazenados, acionadores e funções definidas pelo usuário (UDFs)
• Arquivos de configuração
• Arquitetura da memória, processos de segundo plano e encadeamentos
• Mecanismos de bloqueio
• Segurança
• DB2 pureXML features
• Partitioning
• Row compression feature
• Autonomic features
• Ferramentas
• Resumo
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais