Este documento resume os resultados de testes realizados em um banco de dados DB2 Express-C 9.5, incluindo: controle de transações, isolamento, bloqueios, processamento de consultas, replicação de dados e suporte a XML. Dois testes de controle de transações validaram que transações incompletas não alteram dados. Testes de concorrência mostraram que atualizações simultâneas em registros diferentes ocorreram sem problemas.

1. Trabalho de Sistemas de Bancos de Dados
Centro Universitário UNIVATES
DB2 Express-C 9.5
Bruno Dadalt Zambiazi
Lajeado, 10 de julho de 2010.

2. Sumário
Sumário............................................................................................................................. 2
Introdução......................................................................................................................... 3
DB2................................................................................................................................... 4
DB2 Express-C 9.5 ....................................................................................................... 4
Controle e Recuperação de Transações ............................................................................ 5
Teste 1 .......................................................................................................................... 5
Teste 2 .......................................................................................................................... 5
Teste 3 .......................................................................................................................... 6
Controle de Concorrência................................................................................................. 6
Níveis de Isolamento .................................................................................................... 6
→ Uncommited Read ............................................................................................ 6
→ Cursor Stability................................................................................................. 7
→ Read Stability ................................................................................................... 7
→ Repeatable Read ............................................................................................... 7
Bloqueio ....................................................................................................................... 8
→ Shared Locks .................................................................................................... 9
→ Exclusive Locks................................................................................................ 9
Testes ............................................................................................................................ 9
Caso 1 ....................................................................................................................... 9
Caso 2 ....................................................................................................................... 9
Processamento e Otimização de Consultas .................................................................... 10
Consulta 1 ................................................................................................................... 10
Consulta 2 ................................................................................................................... 12
Consulta 3 ................................................................................................................... 14
Consulta 4 ................................................................................................................... 14
Consulta 5 ................................................................................................................... 15
Consulta 6 ................................................................................................................... 16
Replicação de Dados ...................................................................................................... 17
Bidirecional com um Mestre ...................................................................................... 18
Bidirecional sem um Mestre....................................................................................... 18
Suporte e Recursos a XML............................................................................................. 19
XML – Enabled .......................................................................................................... 19
→ Modelo Clob/Varchar ..................................................................................... 20
→ Modelo Shredding .......................................................................................... 20
PureXML.................................................................................................................... 20
Exemplos .................................................................................................................... 21
Conclusões...................................................................................................................... 23
2

3. Introdução
O presente documento visa apresentar uma visão geral acerca do Sistema
Gerenciador de Bancos de Dados DB2, além dos resultados obtidos em todas as etapas
de testes propostas pelo trabalho solicitado. Os testes envolvem os seguintes conceitos:
controle de transações, controle de concorrência, otimização e processamento de
consultas, replicação de dados e suporte a XML.
Para o desenvolvimento do trabalho, foi utilizada a versão gratuita mais recente
do DB2, a Express-C 9.5. Todos os testes que envolviam operações de
inserção/alteração/exclusão de registros, foram feitos através de programas Java que se
conectavam ao banco de dados através de uma conexão JDBC.
Todos os relatórios e arquivos de log contêm o prefixo [Anexo] e foram
anexados ao documento PDF através da ferramenta Foxit Reader. Caso o leitor de PDF
com o qual esteja visualizando este documento não permita tal funcionalidade, o
software pode ser baixado no seguinte endereço:
http://www.foxitsoftware.com/downloads/.
3

4. DB2
Em 1983, a IBM, International Business Machine, anunciou o lançamento do
Sistema Gerenciador de Bancos de Dados DB2. Inicialmente projetado para rodar
apenas nos mainframes da própria IBM, o projeto começou no ano de 1978 e foi
nomeado de System R, nome que permaneceu até a data do lançamento oficial.
No início da década de 1990, a IBM anunciou o lançamento de versões do DB2
para outras plataformas de servidores, como UNIX e Windows. Atualmente, o DB2
suporta a instalação, também, em ambientes Linux e em PDA’s. É considerado um dos
SGBD’s mais poderosos do mercado, sendo recomendado para aplicações que
necessitam de grande quantidade de armazenamento de dados e alto desempenho em
consultas.
Duas características interessantes do DB2 são o suporte nativo a XML e a
possibilidade de criação de stored procedures em diversas linguagens de programação,
tais quais SQL PL, C/C++, Java, COBOL, entre outras.
A IBM oferece quatro diferentes edições para o DB2: Express-C, Express
Edition, Workgroup Edition e Enterprise Edition. Enquanto as três últimas são pagas, a
primeira é livre e foi utilizada para o desenvolvimento deste trabalho. A imagem a
seguir dá uma ideia da diferença de funcionalidades encontradas nas diferentes edições
do DB2:
DB2 Express-C 9.5
Em 2006, após o anúncio do lançamento das edições gratuitas dos SGBD’s da
Oracle e da Microsoft, seus maiores concorrentes, a IBM resolveu adotar a mesma
4

5. estratégia e lançar uma edição gratuita do seu banco de dados, o qual ganhou o nome de
DB2 Express-C.
Utilizando a mesma funcionalidade principal e o mesmo código-fonte das
edições pagas, o DB2 Express-C pode ser utilizado em sistemas de 32 ou 64 bits e em
sistemas operacionais Linux, Solaris e Windows. Pode ser utilizado em servidores que
contenham, no máximo, 2 processadores e 2GB de memória RAM . Não possui limites
quanto à utilização em relação ao tamanho da base de dados, número de bancos de
dados ou número de usuários/conexões.
Controle e Recuperação de Transações
Neste capítulo, não será explicada nenhuma teoria. Haverá apenas a
apresentação dos testes realizados conforme solicitado.
Teste 1
Descrição: Executar uma rotina e, durante a mesma, parar o servidor. Iniciar
novamente o servidor, verificando se a transação funcionou corretamente;
Método: execução de uma rotina responsável pela inserção de 425 registros na tabela
retiradas;
Mensagem: Erro fatal: [jcc][t4][2055][11259][4.8.87] O gerenciador de banco de
dados não está apto a aceitar novos pedidos, todos os pedidos em progresso foram
terminados, ou este pedido específico foi terminado devido a condições de erro
inesperadas detectadas no sistema de destino. ERRORCODE=-4499,
SQLSTATE=58009;
Log: [Anexo] 1 – 7.1;
Número de registros na tabela antes de parar o servidor: 0 (zero);
Número de registros na tabela após parar o servidor: 0 (zero);
Conclusão: passou no teste, pois nenhum registro foi inserido ao ocorrer um erro
durante a transação.
Teste 2
Descrição: Executar duas rotinas de forma simultânea e, quando uma delas indicar que
terminou, parar o servidor. Iniciar novamente o servidor e verificar se a transação que
terminou teve os dados efetivados e se a outra teve as atualizações desfeitas;
Método: execução de uma rotina responsável pela inserção de 25 registros na tabela
exemplares, e outra pela inserção de 440 registros na tabela retiradas;
Mensagem: Erro fatal: [jcc][t4][2055][11259][4.8.87] O gerenciador de banco de
dados não está apto a aceitar novos pedidos, todos os pedidos em progresso foram
5

6. terminados, ou este pedido específico foi terminado devido a condições de erro
inesperadas detectadas no sistema de destino. ERRORCODE=-4499,
SQLSTATE=58009;
Log: [Anexo] 1 – 7.2;
Número de registros na tabela exemplares antes de parar o servidor: 500;
Número de registros na tabela retiradas antes de parar o servidor: 0 (zero);
Número de registros na tabela exemplares após de parar o servidor: 525;
Número de registros na tabela retiradas após de parar o servidor: 0 (zero);
Conclusão: passou no teste, pois a transação que estava aberta no momento em que o
servidor parou, não teve seus dados salvos.
Teste 3
Descrição: Executar uma rotina e, antes do término, finalizá-la. Verificar se as
atualizações aparecem na base de dados. Finalizar o servidor ou matar o processo da
conexão para verificar se os dados inseridos aparecem no banco;
Método: execução de um rotina responsável pela inserção de 400 registros na tabela
retiradas, realizando o seu cancelamento através da linha de comando;
Mensagem: nenhuma, pois a rotina foi cancelada pela linha de comando;
Log: [Anexo] 1 – 7.3 (o arquivo ficou vazio pois a rotina foi cancelada antes de gravar
os dados, que é a última parte do código da rotina);
Número de registros na tabela antes de parar o servidor: 0 (zero);
Número de registros na tabela após parar o servidor: 0 (zero);
Conclusão: passou no teste, pois nenhum registro foi inserido ao ocorrer um erro
durante a transação.
Controle de Concorrência
Pode-se definir a concorrência como o fato de diversas aplicações acessarem o
mesmo dado simultaneamente. Este acesso, no entanto, deve ser coordenado de forma
correta para que seja a atualização das informações seja transparente aos usuários.
No SGBD DB2, há quatro níveis de isolamento e dois níveis de bloqueio
permitidos para que o controle de concorrência ocorra de forma adequada.
Níveis de Isolamento
→ Uncommited Read
Uncommited Read, Leitura de Dados não Finalizado, é o menor nível de isolamento
e, consequentemente, oferece o maior nível de concorrência. Não ocorrem bloqueios de
linha quando são executadas operações de leitura, exceto quando existem operações de
6

7. DROP ou ALTER TABLE. As operações de UPDATE bloqueiam a linha até que a
transação termine.
Problemas que podem ocorrer:
Leitura de dados não finalizados;
Leitura de dados não repetidos;
Leitura fantasma.
Problemas que são evitados:
Perda na atualização.
→ Cursor Stability
Cursor Stability, Estabilidade do Cursor, é o nível de isolamento padrão do DB2 e
fornece o menor nível de bloqueio. Em operações de leitura, bloqueia a linha corrente
do cursor até que a mesma seja capturada (fetched); se for para atualiações, o bloqueio
das linhas é feito até o término da transação.
Problemas que podem ocorrer:
Leitura de dados não repetidos;
Leitura fantasma.
Problemas que são evitados:
Perda na atualização;
Leitura de dados não finalizados.
→ Read Stability
Read Stability, Estabilidade de Leitura, bloqueia todas as linhas que fazem parte da
operação solicitada, por qualquer cursor, até que a transação termine. Exemplo: numa
consulta que retorna 100 linhas de determinada tabela, sendo que a mesma possui 1000,
todas as 100 ficam bloqueadas até o término da operação.
Problemas que podem ocorrer:
Leitura fantasma.
Problemas que são evitados:
Perda na atualização;
Leitura de dados não finalizados;
Leitura de dados não repetidos.
→ Repeatable Read
Repeatable Read, Leitura Repetida, é o maior nível de isolamento pois provê o
maior grau de bloqueio e o menor nível de concorrência. O bloqueio é realizado em
todas as linhas processadas, ou seja, mesmo as linhas que não fazem parte do resultado
final são bloqueadas. Dessa forma, nenhuma transação poderá fazer algo com os dados
até que a requisição anterior termine.
Problemas que podem ocorrer:
Nenhum.
7

8. Problemas que são evitados:
Perda na atualização;
Leitura de dados não finalizados;
Leitura de dados não repetidos;
Leitura fantasma.
O nível de isolamento configurado como padrão no DB2 é o Cursor Stability.
Para modificá-lo, há três possibilidades: sessão, conexão ou instrução. A configuração à
nível de instrução é bastante simples, bastando adicionar a cláusula WITH XX, onde XX
pode ser UR, CS, RS, RR (as iniciais dos nomes), ao final de uma instrução SQL
normal.
Abaixo, uma imagem que exemplifica a diferença entre os quatro níveis de
bloqueio do DB2:
Bloqueio
O conceito de bloqueio é relacionado com o de concorrência, pois o objetivo
dele – o bloqueio – é parar temporariamente outras operações até que a primeira
operação termine. Quanto mais bloqueios houver, menor será a concorrência, enquanto
que com menos bloqueios a concorrência será maior.
Os bloqueios ocorrem de forma automática, de acordo com a necessidade de
garantir a segurança da transação e sempre há o desbloqueio ao término da mesma.
Podem acontecer à nível de tabela ou apenas de linhas de tabelas. Existem dois tipos de
bloqueio:
8

9. → Shared Locks
Os Shared Locks, ou Bloqueios Divididos, acontecem quando uma transação está
lendo os dados de uma tabela e impede que outras transações realizem operações de
alteração nas mesmas linhas.
→ Exclusive Locks
Os Exclusive Locks, ou Bloqueios Exclusivos, acontecem quando uma transação
quer realizar alterações (inserção, exclusão, alteração) em uma linha e impede que
outras transações façam a leitura destes dados.
Testes
Não foram executados testes com diferentes níveis de isolamento e/ou bloqueio.
Todos os testes realizados levaram em conta apenas as configurações default do SGBD
DB2.
Caso 1
Descrição: Executar duas rotinas simultâneas que alteram dados na tabela retiradas. A
primeira rotina deve efetuar consultas por períodos, ou seja, de 01 a 02 de março,
depois de 03 a 04 do mesmo mês e assim por diante. Após a consulta, os dados dos
registros devem ter a data alterada, adicionando um dia a ela. Devem ser executadas
diversas consultas em sequência durante um certo tempo. Já a segunda rotina deve
efetuar consultas por período, primeiro para o usuário 1, depois para o 2 e assim por
diante. Após a consulta, os dados dos registros devem ter a data alterada, subtraindo
um dia a ela. Em ambas as rotinas, cada consulta e alteração deve ser considerada
uma transação;
Método: a primeira rotina buscou as retiradas do mês 03/2010, de dois em dois dias,
adicionando um dia à data de retirada e atualizando o registro; a segunda rotina buscou
as retiradas de 20 usuários sorteados, subtraindo um dia à data de cada retirada;
Log: [Anexo] 2 – 2.1.1 - Período e [Anexo] 2 – 2.1.2 - Usuário;
Conclusão: baseando-se na retirada 29780, registro encontrado nos dois arquivos de
log, é possível concluir que não houve problemas de concorrência. No primeiro log (de
consultas por período), as datas antiga e nova dessa retirada são 01/03 e 02/03,
respectivamente, havendo o update no horário 09:48:32:609. Já no segundo log (de
consultas por usuário), a mesma retirada apareceu com as datas antiga e nova,
respectivamente, como 02/03 e 01/03, com a atualização no horário 09:48:33:484.
Caso 2
Descrição: três rotinas, uma lendo os exemplares de livros, uma alterando a data de
compra dos exemplares e outra inserindo novos exemplares. A rotina que lê os valores
deve executar repetidamente uma instrução SQL que conta os exemplares por livro;
9

10. Método: a primeira rotina realizou a contagem do número de exemplares para cada
produto por 500 vezes seguidas; a segunda rotina adicionou um dia à data de aquisição
de cada exemplar dos livros; a terceira rotina inseriu um exemplar para cada livro,
colocando como data 30 dias após a maior data de aquisição de um exemplar daquele
mesmo livro. Obs.: os produtos utilizados para as três rotinas foram: 10507, 11136,
9352, 9566, 11132, 8553, 8739, 9527, 10956, 10076, 9063, 9013, 8994, 10637, 9464,
8578, 10089, 10217, 11017, 10032, 8887, 11030, 9707, 9005, 10195, 10134, 9645,
8620, 8579, 9197, 9309, 10371, 9745, 9241, 10388, 10392, 8747, 9830, 9732, 10855,
8919, 8569, 10620, 9288, 11125, 11027, 9690, 10397, 9365, 9218, 9706, 11087, 9929,
9373, 9943, 10490, 11062, 10506, 9378, 9305, 9842, 8615, 9554, 9718, 9825, 9215,
10839, 10052, 8713, 9737, 9162, 8907, 9787, 9861, 11081, 10500, 9631, 9844, 9219,
9030, 10753, 9656, 9642, 9573, 9441, 9673, 8688, 10309, 9096, 9069, 9754, 9488,
10373, 10636, 9607, 9439, 9826, 9945, 9996, 8824, 11094, 9927, 10591, 11012, 9523,
9592, 9308, 8980, 10306, 10060, 10919, 10805, 8780, 9363, 10549, 11121, 10631,
9797, 10078, 9126, 9178, 9188, 10285, 9449, 8716;
Log: [Anexo] 2 – 2.2.1 – Contagem, [Anexo] 2 – 2.2.2 – Atualização e [Anexo] 2 –
2.2.3 - Inclusão;
Conclusão: baseando-se na contagem de exemplares do livro 8553, pode-se concluir
que não houve problema de concorrência. Segundo o primeiro arquivo de log (contagem
de exemplares), havia 5 exemplares desse livro até o horário 15:04:40:375, mas, a partir
do horário 15.04.40.390, passou a haver 6 exemplares pois, alguns milissegundos antes,
de acordo com o terceiro arquivo de log (inclusões de exemplares), houve a inserção de
um novo exemplar para o livro.
Processamento e Otimização de Consultas
Neste capítulo, não será explicada nenhuma teoria. Haverá apenas a
apresentação dos testes realizados conforme solicitado.
Todos os tempos de execução apresentados foram “capturados” pelo programa
Centro de Controle, no qual foram executadas as consultas. Todos os tempos são a
média de execução das consultas, todas realizadas três vezes.
Consulta 1
10

11. [Figura 1] Consulta 1 - consulta original
Tempos de execução:
Consulta original: 0:00:16:98
Consulta sem a cláusula ORDER BY: 0:00:07:22
Consulta original com índices: 0:00:14:19
Índices criados:
reti.id_livro
reti.nr_sequencia
reti.dt_retirada
Planos de execução:
[Figura 2] Consulta 1 - plano de execução da consulta original
11

12. [Figura 3] Consulta 1 - plano de execução da consulta sem a clásula ORDER BY
[Figura 4] Consulta 1 - plano de execução da consulta original com os índices
Consulta 2
[Figura 5] Consulta 2 - consulta
Tempos de execução:
12

13. Consulta: 0:00:05:81
Consulta com índices: 0:00:01:23
Índices criados:
reti.id_usuario
reti.id_atendente
usua.id_cidade
aten.id_cidade
Planos de execução:
[Figura 6] Consulta 2 – plano de execução da consulta original
[Figura 7] Consulta 2 - plano de execução da consulta com índices
13

14. Consulta 3
[Figura 8] Consulta 3 - consulta original (à esquerda) e alternativa (à direita)
Tempos de execução:
Consulta original: 0:00:48:06
Consulta alternativa: 0:00:21:88
Consulta original com índices: 0:00:11:91
Índices criados:
livr.nm_livro
Planos de execução:
[Figura 9] Consulta 3 – plano de execução da consulta original
Consulta 4
[Figura 10] Consulta 4 - consulta
14

15. Tempos de execução:
Consulta original: 0:00:12:32
Consulta sem a condição sobre a data: 0:00:11:94
Planos de execução:
[Figura 11] Consulta 4 - plano de execução da consulta original
Consulta 5
[Figura 12] Consulta 5 - consulta original (à esquerda) e utilizando junções (à direita)
Tempos de execução:
Consulta original: 0:00:10:78
Consulta utilizando junções: 0:00:09:36
Planos de execução (os planos das duas consultas ficaram iguais):
15

16. [Figura 13] Consulta 5 - plano de execução das consultas
Consulta 6
[Figura 14] Consulta 6 - consulta original (à esquerda) e alternativa (à direita)
Tempos de execução:
Consulta original: 0:00:10:39
Consulta utilizando junções: 0:00:06:57
Planos de execução:
16

17. [Figura 15] Consulta 6 - plano de execução da consulta original
Replicação de Dados
Este tópico foi o que gerou a maior dificuldade durante o trabalho, em virtude do
DB2 não dispor de nenhuma ferramenta gratuita para replicação de dados na edição
Express C.
No entanto, nas outras edições, a replicação de dados é sempre feita através da
captura das informações em determinado servidor e posterior aplicação das alterações
nos outros servidores de bancos de dados. Toda a estrutura de replicação do DB2
baseia-se em dois softwares: Capture e Apply.
O primeiro software, Capture, deve estar presente nos servidores que sofrerão
operações de alteração/exclusão/inserção de dados, por ser o responsável pela captura
das informações que estarão sendo manipuladas nele - servidor. Já o segundo, Apply,
deve estar presente nos servidores que sofrerão as atualizações pelo processo de
replicação, pois é o responsável por aplicar as alterações.
Além disso, o DB2 trabalha com as nomenclaturas Source e Target para designar
os servidores considerados mestre – Source – e escravos – Target.
Existem dois modelos de replicação: com um mestre e sem um mestre.
17

18. Bidirecional com um Mestre
É equivalente ao modelo tradicionalmente conhecido como Master-Slave, no
qual o servidor Mestre é o único a receber as alterações e fica responsável por repassá-
las aos servidores escravos.
No modelo do DB2, o servidor Source – Mestre – precisa conter o software
Capture rodando para capturar as alterações sofridas. A partir daí, a replicação é
aplicada nos servidores Target – Escravo – através do software Apply que precisa haver
nestes. A figura abaixo exemplifica o modelo:
Bidirecional sem um Mestre
É equivalente ao modelo tradicionalmente conhecido como Multi-Master, no
qual qualquer um dos servidores pode receber atualizações e fica responsável por
repassar as atualizações aos outros servidores. Dessa forma, todos passam a ser mestres
e escravos ao mesmo tempo.
No modelo do DB2, todos os servidores precisam conter tanto o software
Capture quando o Apply rodando para que consigam capturar as alterações e aplicá-las
em si quando necessário. O modelo Biderecional sem um Mestre do DB2 funciona
apenas de forma assíncrona.
A figura abaixo exemplifica o modelo:
18

19. Suporte e Recursos a XML
O DB2 é, notadamente, um dos SGBD’s que oferece melhor suporte e maior
nível de recursos a XML. Algumas características extraídas diretamente da
documentação oficial:
Técnicas exclusivas para armazenamento e gerenciamento eficiente de
estruturas hierárquicas de documentos XML;
Técnicas exclusivas de indexação para acelerar pesquisas em documentos
XML;
Suporte total às linguagens XQuery e XPath;
Suporte à validação de dados baseados em esquemas fornecidos por
usuários.
No DB2, existem dois tipos de bases de dados capazes de armazenar XML:
XML-Enabled e XML Nativo.
XML – Enabled
Utiliza o modelo relacional como núcleo do modelo de armazenamento, o que
torna necessário o armazenamento do XML em um campo grande (Modelo
Clob/Varchar) ou requer uma espécie de mapeamento entre o modelo hierárquico do
XML com o modelo de dados relacional tradicional (Modelo Shredding).
19

20. → Modelo Clob/Varchar
O documento XML é armazenado inteiramente dentro de um único campo de uma
tabela relacional, sendo o campo geralmente do tipo Clob ou Varchar. Neste modelo, o
documento acaba sendo inserido sem que seja feita uma análise sintática do seu
conteúdo, o que torna esta opção não muito flexível no momento da recuperação e
manipulação dos dados.
→ Modelo Shredding
Também conhecido como Fragmentação, este modelo faz a análise do documento
XML e fragmenta-o em pequenas partes que serão inseridas em diversas tabelas do
banco de dados, sendo o documento “forçado” a se tornar um modelo relacional.
Esse método também não possui muita flexibilidade devido à complexidade de
serem realizadas alterações na estrutura hierárquica do documento XML, além das
consultas se tornarem pesadas pela necessidade de utilizar diversas tabelas e junções
para formar o resultado final.
Abaixo, uma figura ilustrando o funcionamento dos dois modelos:
PureXML
As bases de dados que armazenam XML nativo, no DB2 conhecido como
pureXML, utilizam o modelo de dados hierárquico para armazenar e processar XML
internamente. A forma como o documento é armazenado é a mesma com que é
processado, sem necessitar de uma conversão para o modelo relacional e nem exigindo
que seja feita uma imagem do XML. Quando instruções XQuery e XPath são
executadas, estas não precisam ser convertidas para SQL pois são processadas de forma
nativa, diretamente no documento. Segundo a documentação oficial, o DB2 foi o
20

21. primeiro banco de dados a incorporar o XML nativo a sua implementação, o que
ocorreu na versão 9.
A figura abaixo ilustra a diferença no armazenamento de um dado relacional e
de um documento XML na mesma tabela de uma base de dados:
O DB2 permite que o acesso aos dados para tabelas que possuem tanto dados
relacionais quanto XML pode ser feito de quatro formas:
Utilização de SQL para buscar dados relacionais;
Utilização de SQL com extensões XML para acessar dados XML;
Uso de XQuery para buscar dados XML;
Uso de XQuery para acessar dados relacionais.
Em virtude de tanta flexibilidade, o DB2 pode ser considerado tanto um banco
de dados relacional de alto desempenho, quanto um repositório de documentos XML
bastante poderoso.
Exemplos
A tabela abaixo ilustra as principais funções que podem ser utilizadas para a
manipulação de dados XML através de SQL/X, a extensão XML para SQL:
21

22. Alguns exemplos de utilização de SQL/X:
22

23. Conclusões
Mesmo o pouco tempo de trabalho com o banco de dados DB2 deixa claro que o
ele é extremamente poderoso e caracterizado pelo alto desempenho na execução de
consultas, mesmo as mais complexas. Fora isso, a enorme gama de ferramentas que o
banco possui para administração dá a entender que ele não foi feito para aplicações de
pequeno porte.
Para utilizar o DB2 como SGBD, é necessário que a empresa possua um DBA
específico para conseguir retirar o máximo do poder deste banco. É fácil perceber que
ele se encaixa perfeitamente em ambientes de alta disponibilidade e que necessitam de
uma ferramenta de armazenamento rápida, confiável, robusta e flexível.
23