Caminhando pelo db2

Caminhando pelo DB2
CAMINHANDO PELO DB2

Caminhando pelo DB2
Sobre esta publicação
Se o leitor estiver pensando em conhecer o mundo DB2 aqui está uma ótima oportunidade de
começar, esta será uma viagem inesquecível, tenham uma boa leitura.
Procuramos descrever neste livro todas as informações importantes para o conhecimento do
ambiente DB2. Utilizamos além da linguagem técnica e o Inglês, que é a característica de toda a
publicação sobre Informática, a linguagem do dia-a-dia. Tomaremos a liberdade de utilizar
também a linguagem popular.
Focamos principalmente a plataforma OS/390 e z/OS, mas todos os tópicos desenvolvidos aqui
podem ser utilizados para outras plataformas.
Senhores leitores aqui é apenas o inicio, detalhes mais aprofundados devem ser obtidos através
das publicações técnicas fornecidades pela IBM®. Voces encontrarão uma lista destas
publicações no final desta edição.
Este livro está dividido em quatro partes:
 Parte 1 – Introdução ao DB2 UDB
o Capítulo 1 – Vamos conhecer a familia de produtos do DB2 UDB?
o Capítulo 2 – O ambiente DB2 OS/390 e z/OS.
o Capítulo 3 – Segurança todos pensam nisso.
 Parte 2 – Conversando com o DB2 (Conhecendo a linguagem SQL)
o Capítulo 4 – Somos os objetos DB2!
o Capítulo 5 – Fiquem a vontade, utilize-me, sou O SQL!
o Capítulo 6 – Sei que ainda é cedo, mas vamos falar de SQL avançado?
 Parte 3 – Mantendo a casa em ordem (Administração DB2 UDB)
o Capítulo 7 – Cuidando dos Dados.
o Capítulo 8 – Nem sempre acontece, mas Recuperar é importante.
o Capítulo 9 – Todos precisam de respostas rápidas!
o Capítulo 10 – Curiosidade mata! Um pouco de DATA SHARING!
 Parte 4 - A hora é agora, vamos programar com o DB2?
o Capítulo 11 – Primeiro um pouco de conceito.
o Capítulo 12 – Considerações importantes.
o Capítulo 13 – Já que todos querem, vamos às Funções Avançadas.
o Capítulo 14 – Cuidado voce não está sózinho!

Caminhando pelo DB2
Prazer em conhece-los!
Caros amigos, sou Bartolomeu Carlos Jans, muito conhecido por Barth ou Bartô.
Estou na vida profissional de informática à 30 anos, puxa quanto tempo! Agora é que me dei
conta de quanto tempo trabalho nesta área.
Sempre trabalhei com grandes organizações tais como Mercedes-Benz, Volkswagen, Cofap,
Banco Itaú, Banco Real, Banco Unibanco, C&A Modas. Em algumas destas empresas como
funcionário e outras como Consultor pela empresa MAFFEI Formação e Treinamento.
Como DBA (Administrador de Banco de Dados) atuo à mais de 15 anos, oferecendo suporte à
utlização e administração dos Gerenciadores de Banco de Dados Relacionais DB2 UDB e
ORACLE.
Na área educacional estou à 10 anos, onde desenvolvi planos de formação na área de
desenvolvimento de aplicativos e utilização de linguagens de programação (Lógica de
Programação, Linguagem COBOL, EASYTRIEVE). Ainda na área de treinamento desenvolvi
diversos cursos e publicações sobre DB2 UDB e ORACLE.
Espero que apreciem esta publicação, que desenvolvi com o objetivo de passar a todos o meu
conhecimento de forma clara e objetiva.
“O ser humano nasce, cresce, constitue uma familia, planta uma árvore e escreve um livro”

Caminhando pelo DB2
 Parte 1 – Introdução ao DB2 UDB
o Capítulo 1 – Vamos conhecer a familia de produtos do DB2 UDB?
o Capítulo 2 – O ambiente DB2 OS/390 e z/OS.
o Capítulo 3 – Segurança todos pensam nisso.

Caminhando pelo DB2
Capítulo 1 – Vamos conhecer a familia de produtos do DB2 UDB?
Neste capítulo voce irá conhecer um pouco sobre o DB2 Universal Database (DB2 UDB – vamos
sempre utilizar este termo!) e toda sua família de produtos, nas plataformas S/390, zSeries, Unix
e Intel.
Na figura abaixo temos uma idéia clara da coexistência de toda a familia DB2 UDB nas
diferentes plataformas.
Vamos conhecer um pouco sobre cada participante da familia DB2 UDB
DB2 Every Place
Ou ainda chamado de DB2 E ou DB2 EE, traz todo o poder de um gerenciador de banco de
dados relacional para a computação móvel “fingerprint” com tamanho de até 180kb. Pode ser
executado em dispositivos que usa tecnologia PALM®, Microsoft Windows CE/Pocket PC,
qualquer sistema operacional Microsoft Windows 32-bit, Symbian, QNX Neutrino, Java 2 Platform
Micro Edition (J2ME), e Linux (BlueCat Linux).
Voce poderá considerar o uso desta plataforma em situações ocasionais de conexão com
laptops somente se as aplicações não utilizarem “TRIGGERS”, que não são implementadas
nesta arquitetura.

Caminhando pelo DB2
DB2 Personal Edition
DB2 PE desenvolvido para permitir todas as funções do gerenciador DB2 UDB, para um único
usuário. Traz a vantagem de executar em plataformas de baixo custo tais como Windows 98,
Windows ME, Windows NT (SP6 ou maior), Windows 2000 (SP2 recomendado), Windows XP, e
Linux. Window 2003 será suportado após liberação da Microsoft.
DB2 PE tem todas as funções do DB2 Workgroup Server Edition, com uma exceção “Clientes
Remotos não podem ser conectar aos Databases executados sob o DB2 PE”. Podemos ter
estações de trabalho apenas executando o “Centro de Controle” (veremos sobre este produto
em breve) com funções de administração do Database.
DB2 Workgroup Server Edition
DB2 WSE é um completo Sistema de Gerenciador de Banco de Dados Relacional (SGBDR
vamos utilizar sempre este termo!) provendo recursos de ambiente Cliente/Servidor. Disponível
nas plataformas UNIX (AIX, Solaris, and HP-UX), Linux, Windows NT (SP6 ou maior), Windows
2000 (SP2 recomendado), e Windows XP.
DB2 WSE tem todas as funções do DB2 Enterprise Server Edition, porém não está integra com o
Mainframe através de conectividade via DB2 Connect e também não suporta ambiente 64-bit.
Temos um outro similar o DB2 Workgroup Sever Unlimited Editon (DB2 WSUE), que difere do
DB2 WSE apenas no aspecto de “Licensa de Uso”.
DB2 Enterprise Server Edition
DB2 ESE estamos falando do SGBDR que contempla todas as funções do DB2 WSE, com a
vantagem de possuir o componente DB2 Connect no qual habilita a conexão com os Databases
pertencentes aos ambientes iSeries e zSeries, bem como utilização de recursos do Host, tais
como, CICS, VSAM e IMS.

Caminhando pelo DB2
Um pouco mais sobre outros produtos.
DB2 Clients:
• DB2 Run Time : Tem apenas a função de conectar estações de trabalhos aos servidores;
• DB2 Administration Client : Tem a função de acessar e administrar os Databases
através das estações de trabalhos, utilizando o “Centro de Controle” ou “Assistente de
Configuração”. Caso a estação possua o DB2 Connect, pode-se ainda gerenciar os
sistemas z/OS e IMS;
• DB2 Application Development Client : Prove ferramentas e ambiente necessários ao
desenvolvimento de aplicativos, que acessam servidores DB2, podendo construir e
executar tais aplicativos.
DB2 Extenders:
• XML : Prove novos de tipos de dados que podem ser armazenados em documentos XML
em Databases DB2;
• Net Searcher : Para auxiliar na construção de aplicativos Internet, que necessitam alta
performance em grandes índices e escalabilidade de pesquisas concorrentes;
• Spatial : Permite armazenar, gerenciar e analisar dados espaciais, do tipo localização
geográfica;
• TAIV (Text, Audio, Image, Video) : Próprio administrar em seu DB2 formatos não
tradicionais do tipo Músicas, Filmes, Fotografias.
DB2 Connect:
Em grandes organizações os dados estão armazenados em database DB2 em diversos
ambientes, tais como, AS/400, MVS, OS/390, z/OS, VSE e VM. Podemos administrar os diversos
ambientes em uma única estação de trabalho, utilizando o DB2 Connect que possue um grande
conjunto de ferramentas que permitem tais conectivades.
Muito temos que falar sobre os produtos relacionados com o DB2 UDB, o importante no
momento é ter uma real noção das inúmeras possibilidades de implementação e de
escalabilidade oferecidas por este SGBDR. Com certeza teremos outras oportunidades para
conhecer maiores detalhes sobre os produtos aqui mencionados, bem como ser apresentados
para outros produtos.

Caminhando pelo DB2
Capítulo 2 – O ambiente DB2 OS/390 e z/OS
Neste capítulo voce irá se familiarizar com algums objetos relacionados com o Sistema
Operacional e como o DB2 está organizado dentro deste sistema operacional. Viajaremos
também pelos componentes do SGBDR DB2 UDB.
OS/390 e z/OS
A familia IBM de servidores “enterprises” utiliza OS/390 e z/OS que são os softwares de sistema
operacional, que provem escalabilidade, segurança no processamento para diferentes carga de
trabalho em um ambiente de “alta” performance.
Neste ambiente de sistema operacional temos a convivência de multiplos tipos de aplicações,
sendo as principais BATCH e OLTP (Online Transaction Processing), destacando como
principais características: Gerenciamento, Escalabilidade, Flexibilidade, Disponibilidade e
Segurança.
DB2 UDB no ambiente OS/390 e z/OS
DB2 UDB visto pelo sistema operacional é um sub-sistema que gerencia os banco de dados, os
processos do DB2 UDB são executados em diversos “ADDRESS SPACES”, podemos definir
esses “ADDRESS SPACES” como serviços ou gerentes, existe um “ADDRESS SPACE” para
cada serviço, Na figura abaixo temos os nomes de cada “ADDRESS SPACE”:

Caminhando pelo DB2
DSN1MSTR – Responsável pelos serviços de Sistema DB2 UDB, executando as seguintes
tarefas:
- Processadores de comandos
- Suporte ao sub-sistema (Não esqueçam o DB2 é um sub-sistema para o S/390 e z/OS)
- Gerenciador de Serviços
- Gerenciador de Armazenamento
- Gerenciador de Recuperação
- Gerador de Mensagens
- Gerenciador de transações distribuidas
DSN1DBM1 – Responsável pelo gerenciamento das principais funções do Database,
destacamos as principais funções:
- Controlador de Serviços
- Gerenciador de Dados
- Gerenciador de Espaço de Dados (arquivos físicos)
- Gerenciador de “STORED PROCEDURE”
- Gerenciador de “BUFFER”
- Utilitários
IRLMPROC – Responsável pelo controle da integridade de dados.
DSN1SPAS – Prove um ambiente isolado no qual serão executados as “STORED
PROCEDURE”.
DSN1DIST – Responsável pelo controle de acesso a dados entre dois sub-sistemas DB2.
Existem outros “ADDRESS SPACES” que comunicam-se com o DB2 que não iremos detalhar
nesta publicação:
CICS, TSO, IMS entre outros.
DSN1MSTR DSN1DBM1 IRLMPROC DSN1SPAS DSN1DIST

Caminhando pelo DB2
Arquitetura DB2 UDB
Catálogo DB2
O Catálogo DB2 consiste de tabelas e dados sobre todos os objetos definidos em um DB2
Subsystem, incluindo tablespaces, indices, tabelas, storage groups, e tudo mais. O Catálogo
DB2 reside no database DSNDB06. Quando se cria, altera ou deleta qualquer estrutura DB2,
inserts, updates, ou deletes são executados nas linhas/colunas da estrutura do catálogo.
Existe todo um relacionamento entre as tabelas do Catálogo DB2, que é implementado a partir
de uma estrutura de links, similar a integridade referencial.
No manual IBM DB2 UDB for OS/390 SQL Reference Manual, tem uma lista detalhando todas
as tabelas e colunas pertencentes ao Catálogo DB2.
Diretório DB2
O Diretório DB2 contém informações usadas pelo DB2 durante a operação normal. Você não
pode acessar o Diretório DB2 usando SQL. Embora tenha o mesmo tipo de informações que o
Catálogo DB2. As estruturas do Diretório DB2 não estão descritas no Catálogo DB2.
O Diretório consiste em um conjunto de Tabelas DB2, armazenadas em 5 tablespaces no
database DSNDB01:
SCT02
SPT01
SYSLGRNX
DB2
CATÁLOGO
DIRETÓRIO

Caminhando pelo DB2
Arquitetura DB2 UDB – Objetos DB2
Database
No DB2, um database é onde todas as estruturas DB2 serão associadas.
Um Database poderá conter todos os dados associados com uma aplicação ou com um grupo
de aplicações.
Com isto temos a condição de start ou stop para todos os dados contidos no Database ou
permitir acesso aos mesmos.
DB2 Storage group
Um DB2 storage group é um conjunto de volumes em um direct access storage devices (DASD).
Os data sets residem nos volumes, nos quais as tabelas e índices estão armazenados. Um
storage group é composto de um volume e de um catalogo VSAM (Armazenamento utilizado no
ambiente OS/390 e z/OS). O Storage group SYSDEFLT, é o storagegroup default, e é criado
quando você instala o DB2.
Todos volumes de um storage group tem que ser do mesmo device type.
Create
StoGroup
Create
Database
DataBase
1
Catálogo
Diretório
VSAM
LDS
Subsistema DB2
Create
Tablespace
Stogroup1
Tablespace1
Create
table
Table1
Create
IndexIndex1 Index2
Table2

Caminhando pelo DB2
TableSpace
Um tablespace é composto por um ou mais data sets nos quais uma ou mais tabelas são
armazenadas. Um tablespace pode ser um ou mais arquivos VSAM. Estes arquivos VSAM são
do tipo linear data sets (LDSs). Esses tablespaces são formatados em páginas geralmente de
4kb de tamanho. Este é um componente físico das estruturas do DB2.
Tabela
Todos os dados de um database DB2 são apresentados em forma de Tabelas. Quando se cria
uma Tabela, define-se a ordem das colunas.
IndexesSpace
Um indexspace é o mesmo que um Tablespace. Chamamos o mesmo desta forma, pois tem
correlação apenas com os índices. Este é um componente físico das estruturas do DB2.
Arquitetura DB2 UDB – Objetos para Recuperação
Catálogo
Diretório
VSAMSubsistema DB2
ARCHIVE LOGS
LOG
ATIVA
BSDS

Caminhando pelo DB2
LOGS
Todas as alterações de dados nas tabelas DB2 UDB são eventos significantes e são gravados
nas Logs do DB2 UDB. Em caso de falha de uma aplicação ou do próprio Subsistema DB2 UDB,
estes dados são utilizados para Recuperação.
O processo de LOG DB2 nada mais é que gravar, em um arquivo VSAM Sequencial, o registro
antes e depois da atualização, mais o TIMESTAMP do momento da alteração. O arquivo de LOG
ATIVA por ser um arquivo VSAM tem um tamanho máximo permitido definido na Instalação do
DB2 UDB, assim sendo, quando este arquivo está próximo da sua capacidade máxima, é
executado um processo pelo Sub-sistema DB2 chamado ARCHIVE LOG. Este procedimento
descarrega todos os registros da LOG ATIVA em uma unidade de cartucho, e é registrado no
catálogo DB2 chamado SYSCOPY.
Todas as LOGs são definidas de forma DUAL, ou seja, gravados em duas unidades, para
garantir a recuperação mesmo em situação de falha na leitura das LOGS.
BSDS
O BootStrat DataSet é um arquivo do tipo VSAM-KSDS que contém informações críticas para o
funcionamento de um Subsistema DB2. O DB2 utiliza este arquivo durante o procedimento de
START, com a finalidade de garantir um ambiente seguro de recuperação. Fazem parte deste
arquivo as seguintes informações:
- Inventário das as Logs Ativas e Archives Logs
- Lista de Checkpoint efetuados em um Subsistema DB2
- Informações para a conecções remotas (DDF)
- Informações sobre Buffers

Caminhando pelo DB2
Capítulo 3 – Segurança todos pensam nisso
Segurança é uma tarefa vital dentro de um ambiente de banco de dados relacional veremos
neste capítulo os principais tópicos envolvidos nesta tarefa.
Na figura abaixo temos uma visão geral de como se integram os ambientes e a segurança dentro
do DB2 UDB:
Um procedimento comum é garantir o acesso de um determinado usuário sómente através do
RACF (sub-sistema de segurança da IBM) ou outro software similar.
Perfis de acessos ao DB2 UDB de diversos ambientes e “ADDRESS SPACES”, são definidos
como recurso para o RACF. Cada requisição para acesso ao DB2 UDB é associado com um
usuário (USERID). O RACF verifica que o USERID está autorizado pelo DB2 a utilizar os
recursos permitindo ou não o acesso.
Do lado do DB2 o controle de acesso aos objetos é feito pelo assinalamento de privilégios e
autorizações para os recursos passados pelo RACF.
Podemos ainda especificar um conjunto de privilégios administrativos, que são específicos e
definidos pelo próprio DB2.
O controle de acesso aos objetos é feito utilizando a linguagem SQL. Para permitir o acesso
usamos o SQL GRANT e para revogar o acesso o SQL REVOKE. Abaixo vamos ilustrar através
de um modelo genérico:
BATCH
TSO
CICS
IMS
DB2RACF
ID
PASSWORD
D
ID
GROUP1
GROUP2....
.

Caminhando pelo DB2
GRANT privilégio ON TABLE objeto TO recurso.
Para garantir ao usuário BARTH o acesso SELECT para a tabela RAMAIS temos que codificar o
seguint SQL :
GRANT SELECT ON TABLE RAMAIS TO BARTH.
Se precisamos garantir todos os acessos para a tabela RAMAIS à todos usuários teremos:
GRANT ALL ON TABLE RAMAIS TO PUBLIC.
Vamos ilustrar um exemplo de revogar o acesso:
REVOKE SELECT ON TABLE RAMAIS FROM BARTH.
Neste capítulo descrevemos as principaís características sobre o conceito “SEGURANÇA”, muito
temos que falar sobre segurança no ambiente DB2, como nosso objetivo nesta publicação é
sómente descrever todas as funções do ambiente DB2 UDB, deixaremos os detalhes sobre
“SEGURANÇA DB2” para uma outra publicação.
Podemos obter maiores detalhes nos seguintes manuais do fabricante:
IBM DB2 UDB for OS/390 SQL Reference Manual
IBM DB2 UDB for OS/390 SQL Administration Guide

Caminhando pelo DB2
 Parte 2 – Conversando com o DB2 (Conhecendo a linguagem SQL)
o Capítulo 4 – Somos os objetos DB2!
o Capítulo 5 – Fiquem a vontade, utilize-me, sou O SQL!
o Capítulo 6 – Sei que ainda é cedo, mas vamos falar de SQL avançado?

Caminhando pelo DB2
Capítulo 4 – Somos os objetos DB2!
Como podemos observar, um subsistema DB2 é composto de vários objetos organizados
hierarquicamente. Cuidado não estamos falando de Banco de Dados hierarquico. Hierarquia
nesse contexto simplesmente é a idéia de dependencia entre os objetos dentro do ambiente DB2
UDB.
Cada um desses objetos deve ter um nome que o identifique univocamente, com exceção de
nomes de tabelas, índices e views que podem ter nomes iguais mas com owners(proprietários)
distintos.
Para que seja possível gerenciar tal ambiente é importante que algumas regras de padronização
sejam seguidas de modo que seja possível estabelecer nomes que não entrem em conflitos e
que permitam uma identificação do tipo de objeto em questão.
Subsistema
Data base DB1
Storage group
DB2
x
SGn
Data base DBn
Tablespace TSn
Tablespace TS1
Table
Owner.TB
n
Table Owner.TB1
Index Owner.IX1 Index Owner.IXn
View Owner.V1 View Owner.Vn

Caminhando pelo DB2
Em algumas instalações um mesmo subsistema pode conter mais de um ambiente, por exemplo
desenvolvimento e homologação, tornando ainda mais importante um sistema de padronização
de nomes.
O pré-requisito básico para a construção e padronização de nomes aos objetos DB2, é a
modelagem de dados associada a construção de um Dicionário de Dados Lógico, podemos
utilizar algumas técnicas para essa construção, tais como Modelo Entidade Relacionamento
(MER) ou Diagrama Entidade Relacionamento (DER), apoiada a estas técnicas temos
ferramentas que melhoram a produtividade e qualidade, uma ferramenta muito conhecida pela
comunidade de informática é o ERWin.
Embora o enfoque desta publicação é o DB2 UDB e a implementação física do Modelo de
Dados, vamos rever alguns tópicos sobre a Modelagem de Dados Lógica.
Modelagem de Dados
Um passo importante em qualquer projeto de banco de dados é o levantamento de informações
de modo a retratar o mais fielmente possível as regras envolvidas no negócio e seus
relacionamentos. Uma boa modelagem dos negócios da empresa é fundamental para que um
projeto de banco de dados possa ser realizado de modo gradual sem que surjam problemas de
integração no futuro.
O projeto físico de um banco de dados relacional mapeia as entidades derivadas do modelo
lógico em tabelas levando-se em conta também fatores como quantidade de acessos,
atualizações, inserções, convivência entre processos BATCH e ONLINE, etc.
A modelagem lógica é um processo que procura determinar o mais fielmente possível as
entidades representativas de um negócio bem como seus relacionamentos e regras. Ao se
definir entidades como, por exemplo, funcionários, departamentos e projetos podemos ter regras
e relacionamentos diferentes em empresas distintas tais como:
- Na empresa A um funcionário pertence a um departamento e pode estar alocado a apenas
um projeto.
- Na empresa B um funcionário pertence a um departamento e pode estar alocado
simultaneamente a mais de um projeto.
Essas diferenças têm implicações no modelo físico, no primeiro caso, o projeto poderia ser
considerado como um atributo da entidade funcionário, pois normalmente, nas relações (1:1)
uma das entidades é na realidade atributo da outra, o que no caso da empresa B não é verdade.
O relacionamento entre as entidades poderá ser:
(1:1) um para um
(1:M) um para muitos
(M:M) muitos para muitos

Caminhando pelo DB2
Diagrama de Relacionamento:
O processo de modelagem lógica e o mapeamento dessas informações, por si só, é matéria
suficiente para um curso a parte e está sendo apresentado aqui de uma forma bastante
resumida.
O relacionamento entre as entidades pode ser mapeado graficamente através do diagrama de
Entidades – Relacionamentos, onde cada entidade é representada por retângulos e os
relacionamentos por setas no qual o número de pontas identifica o tipo de relacionamento.
No processo da modelagem física, cada entidade do negócio terá uma entidade equivalente no
modelo de dados físico mapeados numa tabela.
Os atributos de cada entidade serão representados por colunas dessa tabela.
Antes de começar esse processo é importante que se identifique as chaves primárias de cada
entidade do modelo e que este seja normalizado para evitar anomalias na implantação do
modelo físico.
DEPARTAMENTO LOCAL
EMPREGADOS PROJETOS
ESPECIALIDADES
1 : M
M : M
1 : M
M : M

Caminhando pelo DB2
Normalização
1ª. Forma Norma:
Pelas próprias características do modelo relacional, qualquer tabela satisfaz a primeira regra pois
não é possível para uma dada ocorrência de uma entidade haver mais de um valor para uma
dada coluna, conforme ilustrado na figura acima.
2ª. Forma Norma:
No nosso exemplo, para identificar cada ocorrência na tabela é necessário definir como chave o
código do componente e o local onde o mesmo está armazenado, mas essa tabela não está de
acordo com a segunda forma normal, pois o endereço, que é um atributo, depende apenas de
parte da chave que é o local.
Matricula SkillNome
0012345 João Skill1
Skill2
Skill3
Skill4
Component
e
Local Quant. Endereço
P001 L01 5 SP
P001 L02 10 RJ
P002 L01 18 SP
Chave

Caminhando pelo DB2
Como solução do exemplo anterior temos que separar os dados que dependem de apenas parte
da chave e criar uma nova tabela, abaixo temo o exemplo:
3ª. Forma Norma:
Nesse exemplo, Depto e NomeDepto são atributos que estão relacionados entre si, mas nenhum
deles pertencem à chave primária dessa tabela
Como solução teremos que separar os dados que dependem de uma coluna não chave.
Foi muito bom revisar Modelagem de Dados, mas vamos voltar para a Implementação Física dos
Objetos DB2.
Vamos falar sobre a Linguagem SQL mais precisamente a DDL. Tudo explicado no Capítulo 5.
Component
e
Local Quant.
P001 L01 5
P001 L02 10
P002 L01 18
Endereço
SP
RJ
Local
L01
L02
Matricula Nome Depto NomeDepto
001234 João RH Recursos Humanos
112233 Gustavo OP Operação
987654 Sonia CR Contas a Receber
Chave
Matricula Nome Depto
001234 João RH
112233 Gustavo OP
987654 Sonia CR
NomeDepto
Recursos Humanos
Operação
Contas a Receber
Depto
RH
OP
CR

Caminhando pelo DB2
Capítulo 5 – Fiquem a vontade, utilize-me, sou O SQL!
Muitos dos objetos DB2 já descritos até o momento podem ser referenciados diretamente pela
linguagem SQL, que é dividida em três categorias, a saber:
 DDL (Data Definition Language)
Usada para Criar, Modificar ou Excluir objetos DB2.
 DML (Data Manipulation Language)
Usada para Pesquisar, Inserir, Atualizar ou Deletar dados de tabelas (registros).
 DCL (Data Control Language)
Usada para prover controle de acesso aos dados.
Iremos conhecer todas as categorias SQL, mas não iremos aprofundar todos os elementos e
comandos que compõe cada uma das categorias e sua síntaxe. Este assunto é muito rico de
detalhes e informações. Temos material suficiente para produzir um Livro apropriado para
tratarmos desse assunto.
DDL (Data Definition Language)
Na DDL temos os seguintes comandos SQL:
- CREATE (Criação de Objetos DB2)
- ALTER (Alteração de Objetos DB2)
- DROP (Eliminação de Objetos DB2)
- DECLARE (Criação temporária de Objetos DB2)

Caminhando pelo DB2
Abaixo temos a síntaxe completa de um comando DDL, mais precisamento CREATE TABLE,
para podermos ter uma noção dos elementos que envolvem uma criação de uma tabela DB2:
Podemos destacar algumas informações para melhor conhecer esta DDL:
Column-definition: Podemos definir as características das colunas, tamanho, tipo de dado.
Unique-constraint: Definimos a chave primária ou não.
Referential-constraint: Regras de integridade referencial.
Check-constraint: Regras de negócio.

Caminhando pelo DB2
Sobre definição de colunas temos alguns detalhes a saber:
Mais detalhes sobre a DDL podemos obter no manual do fabricante de cada gerenciador de
banco de dados no caso do DB2 UDB temos IBM DB2 UDB for OS/390 SQL Reference
Manual.

Caminhando pelo DB2
DML (Data Manipulation Language)
Na DML temos os seguintes comandos SQL:
- SELECT (Pesquisando dados)
- INSERT (Inserindo dados)
- DELETE (Deletando dados)
- UPDATE (Atualizando dados)
Para detalharmos cada um dos comandos abaixo utilizaremos como base uma Tabela de nome
RAMAIS, abaixo o desenho da tabela :
7447 Sandra Peres B01
RAMAL NOME SOBRENOME DEPTO
7154 João Ribeiro C01
7033 Antonio Carlos ---
7123 Carlos Alberto A01
7717 Pedro Aleixo A01
7654 Paula Meneses A01
7865 Rogerio Santos C01
7209 Maria Guimarães C01
7315 Ana Paula B01
7005 Pedro Rocha X01

Caminhando pelo DB2
SELECT
Síntaxe básica:
Clause – quais colunas, funções escalares, colunas derivadas.
Where – condições de restrições de pesquisa (linhas).
Group by – Agrupamento de linhas.
Having – Condições sobre os agrupamento de linhas.
Exemplo prático:
No exemplo acima estamos selecionando apenas as colunas NOME e SOBRENOME da tabela
RAMAIS, sómente para as linhas que tenham como conteúdo o RAMAL 7447.
Evidente que temos inúmeras possibilidades de SELECT. Que não serão descritas nesta
publicação.
Um outro exemplo:
Neste caso temos o ORDER BY, que tem como função a classificação do resultado da
pesquisa.
SELECT NOME, SOBRENOME FROM RAMAIS WHERE
RAMAL = ‘7447’
SELECT RAMAL, NOME, DEPTO FROM RAMAIS WHERE
DEPTO = ‘A01’ ORDER BY NOME, RAMAL

Caminhando pelo DB2
INSERT
Síntaxe básica:
Exemplo prático:
INSERT INTO RAMAIS (RAMAL, NOME, SOBRENOME, DEPTO)
VALUES (‘7777’, ‘Alfredo’, ‘Camargo’, ‘D01’)
Considerações :
Todas as regras de integridade serão verificadas pelo DB2 antes de efetivar o comando INSERT,
essas regras são:
- Chave Primária e chave Única
- Chave Estrangeira
No exemplo acima considerando que a coluna RAMAL é chave primária e existe na tabela uma
linha com RAMAL = 7777, um SQL ERRO ocorrerá indicando a violação da chave primária.

Caminhando pelo DB2
Tratamento de NULOS:
Se algum atributo (coluna) permitir o NULO (NULLS), podemos inserir uma linha nova na tabela
utilizando três formas:
1a. Forma: Informando a coluna e colocando explicitamente o comando NULL no INSERT
VALUES (‘7777’, ‘Alfredo’, ‘Camargo’, NULL)
2a. Forma: Informando a coluna e não colocando o dado
VALUES (‘7777’, ‘Alfredo’, ‘Camargo’, ‘’)
3a. Forma: Não informando a coluna.
INSERT INTO RAMAIS (RAMAL, NOME, SOBRENOME)
VALUES (‘7777’, ‘Alfredo’, ‘Camargo’)
DELETE
Síntaxe básica:

Caminhando pelo DB2
Exemplo prático:
DELETE FROM RAMAIS WHERE RAMAL = ‘7000’
Considerações:
A regra de integridade referencial sera verificada pelo DB2 antes de efetivar o comando
DELETE, se existir alguma tabela que dependa da tabela RAMAIS um SQL ERRO ocorrerá
indicando a violação da chave estrangeira.
CUIDADO!!!!! com o DELETE sem a cláusula WHERE, pois o DB2 irá deletar todas as linhas da
Tabela, é claro, caso nenhuma regra de integridade referencial seja violada.
UPDATE
Síntaxe básica:

Caminhando pelo DB2
Exemplo prático:
UPDATE RAMAIS SET RAMAL = ‘7000’ WHERE RAMAL = ‘7717’
Considerações :
Todas as regras de integridade serão verificadas pelo DB2 antes de efetivar o comando
UPDATE, essas regras são:
- Chave Primária e chave Única
- Chave Estrangeira
No exemplo acima considerando que a coluna RAMAL é chave primária e existe na tabela uma
linha com RAMAL = 7717, um SQL ERRO ocorrerá indicando a violação da chave primária.

Caminhando pelo DB2
Capítulo 6 – Sei que ainda é cedo, mas vamos falar de SQL avançado?
SUBQUERIES
Utilizamos subqueries para resolvermos determinadas pesquisas, onde necessitamos de
executar uma query interna para obtermos valores que serão comparados com a query externa.
Tipicamente pesquisas do tipo ranqueamento são resolvidas com subqueries.
Por exemplo, queremos obter quais Funcionários existem na tabela EMPREGADOS que tenham
como SALARIO maior que a MÉDIA salarial do DEPARTAMENTO.
Algumas considerações:
1º. – Precisamos saber qual a média salarial do DEPARTAMENTO (query interna);
2º. – Precisamos comparar o salário dos Funcionários com esta média (query externa).
Para resolver este problema temos o seguinte SELECT:
SELECT DEPTO, NOME, SALARIO FROM EMPREGADOS T1
WHERE SALARIO > (SELECT AVG(SALARIO) FROM EMPREGADOS
WHERE DEPARTAMENTO = T1.DEPARTAMENTO)
JOINS
Utilizamos o JOIN para resolver problemas de normalização. Quando necessitamos pesquisar
informações que estão distribuídas em tabelas diferentes, por questões de normalização o JOIN
é a solução.
Queremos obter informações sobre os Ramais e o nome dos Departamentos da empresa, mas
esta útima informação não se encontra na tabela Ramais e sim na tabela Departamentos o
exemplo abaixo resolve nosso problema:
SELECT RAMAL, A.NOME, SOBRENOME, B.NOME FROM RAMAIS A, DEPARTAMENTOS B
WHERE A.DEPTO = B.DEPTO
Uma consideração importante para o JOIN é clausula WHERE que indica a condicão de JOIN.
Temos ainda outras situações de JOIN que não cobriremos nesta publicação:
- INNER JOIN
- OUTER JOIN
- FULL OUTER JOIN.

Caminhando pelo DB2
 Parte 3 – Mantendo a casa em ordem (Administração DB2 UDB)
o Capítulo 7 – Cuidando dos Dados.
o Capítulo 8 – Nem sempre acontece, mas Recuperar é importante.
o Capítulo 9 – Todos precisam de respostas rápidas!
o Capítulo 10 – Curiosidade mata! Um pouco de DATA SHARING!

Caminhando pelo DB2
Capítulo 7 – Cuidando dos Dados.
Básicamente este capítulo descreve um conjunto de serviços oferecido pelo DB2 UDB com o
objetivo de manter as bases de dados.
Neste capítulo iremos mostrar como podemos popular dados nas tabelas DB2 utilizando
utilitários do DB2 UDB, descrevendo as principais funções e alguns exemplos.
Iremos também descrever sobre o utilitário REORG que é responsável por organizar os dados
em uma tabela DB2.
Alguns tópicos adicionais serão incluídos neste capítulo, como o utilitário RUNSTATS que
garante estatísticas do catálogo DB2.
Utilitário LOAD
O utilitário LOAD é usado para carregar dados em uma ou mais tabelas, construindo todos os
índices definidos para cada tabela. Se existem dados na tabela a ser carregada, podemos
escolher entre colocar novos dados ou atualizar os dados já existentes.
INPUT
Chama rotinas de edit e validação
Chama rotinas de field procedures
Indica erros de índices únicos
Indica erros se ENFORCE CONSTRAINTS
Pode usar para SYSSTRINGs e SYSPROC
DISCARD
TABELA E ÍNDICE
EXISTENTES
TABELA
EXISTENTE
TABELA
NOVA
T
S

Caminhando pelo DB2
O utilitário LOAD possue várias fases a saber:
• UTILINIT inicialização e setup
• RELOAD carga
• SORT arquivos temporários
• BUILD criação de índices
• INDEXVAL correção de índices
• ENFORCE check de RI
• DISCARD criação do discard dataset
• REPORT geração do relatório sumário
• UTILTERM cleanup
Síntaxe básica do Utilitário LOAD:
Os utilitários DB2 são executados através procedimento BATCH utilizando o famoso JCL (JOB
CONTROL LANGUAGE), não iremos descrever os detalhes sobre o JCL, apenas mostraremos
um exemplo contemplando a síntaxe necessária para executar o LOAD.
Abaixo um exemplo de LOAD, incluindo o JCL:

Caminhando pelo DB2
//UTILSAMP EXEC PGM=DSNUTILB,REGION=1024K,PARM='V51A,DSNTEX'
//STEPLIB DD DSN=DSN510.SDSNLOAD,DISP=SHR
//*****************************************************************************************
//* DATA SETS USED BY THE UTILITY *
//*****************************************************************************************
//SORTOUT DD UNIT=SYSDA,SPACE=(4000,(20,20),,,ROUND)
//SORTWK01 DD UNIT=SYSDA,SPACE=(4000,(20,20),,,ROUND)
//SYSDISC DD UNIT=SYSDA,SPACE=(4000,(20,20),,,ROUND)
//SYSERR DD UNIT=SYSDA,SPACE=(4000,(20,20),,,ROUND)
//SYSMAP DD UNIT=SYSDA,SPACE=(4000,(20,20),,,ROUND)
//SYSRECAC DD DSN=DSN510.SDSNSAMP(DSN8LAC), DISP=SHR
//SYSUT1 DD UNIT=SYSDA,SPACE=(4000,(20,20),,,ROUND)
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
LOAD DATA INDDN(SYSRECAC) RESUME YES
INTO TABLE DSN8510.ACT
(ACTNO POSITION( 1) INTEGER EXTERNAL(3),
ACTKWD POSITION( 5) CHAR(6),
ACTDESC POSITION(13) VARCHAR)
ENFORCE NO
/*
//

Caminhando pelo DB2
Utilitário REORG
Síntaxe básica do Reorg:
Utilizamos também o JCL para executar o Utilitário REORG.
Reorganiza:
tablespace ou índice
Partição ou índice de partição
Melhora o acesso
Reaproveita espaços fragmentados
Pode especificar o grau de acesso
UNLOAD ONLY cria entrada para LOAD no mesmo DB2

Caminhando pelo DB2
Utilitário RUNSTATS
Devemos executar o Utilitário RUNSTAS nas seguintes situações:
• Depois da carga
• Depois da criação de um índice
• Depois de uma reorganização
• Depois de atualizações, deleções, e inserções em volume grande
• Depois que você executou:
– RECOVER TABLESPACE
– REBUILD INDEX
– REORG INDEX
DEPOIS DO RUNSTATS FAÇA REBIND.
Exemplo básico do Utilitário RUNSTATS:
//UTILSAMP EXEC PGM=DSNUTILB,REGION=1024K,PARM='V51A,DSNTEX'
//******************************************************
//******************************************************
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
RUNSTATS TABLESPACE DSN8D51A.DSN8S51E
INDEX(ALL) SHRLEVEL CHANGE
Tablespaces
Tablespaces e índices
Índices
Partições
User data Catálogo
BIND
Plano de
Acesso
Precisa
reorganizar Estatisticas
Pode ser no catálogo
Usado por user query

Caminhando pelo DB2
Capítulo 8 – Nem sempre acontece, mas Recuperar é importante
Existem muitos métodos para se recuperar um Banco de Dados DB2, iremos ilustrar nesse
capítulo uma situação básica de recuperação, por se tratar de um assunto muito extenso e
complexo.
Toda recuperação tem como pré-requisito básico um IMAGE COPY (BACKUP) feito para a
tabela. Portanto começaremos a falar sobre o Utilitário COPY que é responsável pelo BACKUP
das tabelas DB2.
Utilitário COPY
COPY
INCREMENTAL FULL
TSA TSB TSC
DS1 DS2P2P1

Caminhando pelo DB2
Considerações :
• Full image copy deve ser executado após LOAD ou REORG com LOG NO.
• Se o tablespace for particionado é possível copiar as partições em paralelo.
• Se o tablespace não particionado e constituído por mais de um data set, também é
possível a cópia paralela.
• Um único job pode conter mais de um statement COPY, essa opção é útil para copiar um
conjunto de tablespaces com integridade referencial após um QUIESCE.
• Se o tablespace for segmentado, o utilitário não copia páginas vazias e não formatadas.
• O uso do DFSMS permite uma cópia mais rápida.
Uso de GDG:
• É recomendado a utilização de GDG para controlar as cópias obtidas pelo utilitário
- versões mais antigas são automaticamente eliminadas
• Problema
Se uma cópia incremental for executada e nenhuma página alterada for detectada, o uso
do GDG implica em:
- um novo data set de cópia vazio.
- nenhum registro de SYSCOPY criado.
- a cópia mais antiga é eliminada.
Exemplo do utilitário COPY:
//UTILSAMP EXEC PGM=DSNUTILB,REGION=1024K,
// PARM='V51A,DSNTEX'
//******************************************************
//******************************************************
//SYSCOPY DD DSN=COPY001F.IFDY01,UNIT=SYSDA,
// VOL=SER=CPY01I,SPACE=(CYL,(15,1)),
// DISP=(NEW,CATLG,CATLG)
//SYSIN DD *
COPY TABLESPACE DSN8D51A.DSN8S51E
/*
//

Caminhando pelo DB2
Utilitário RECOVERY
NOTAS:
Podemos recuperar uma Tabela de várias formas:
- Deixar o DB2 recuperar a Tabela (automaticamente) para o Ponto mais atual (Ultimo COMMIT),
utilizando para isso o BACKUP e as LOGS disponíveis (RECOVER);
- Recuperar a Tabela de um BACKUP específico (RECOVER TOCOPY);
- Recuperar a Tabela em um determinado Ponto Estabelecido (QUIESCE), (RECOVER TORBA);
TS1
QUIESCEUpdate UpdateCOPY
FU
LL
Log
Log
RECOVER
t1 t2 t3 t4 t5

Caminhando pelo DB2
Capítulo 9 – Todos precisam de respostas rápidas!
Outro assunto que merece destaque, mas que nesta publicação iremos apenas mostrar
superficialmente são os conceitos que envolvem no Planejamento de Performance.
Performance é o caminho que um sistema de computação executa para uma determinada carga
de trabalho.
Vamos relembrar algums objetos que serão importantes para o planejamento de Performance
em ambiente DB2 UDB.
Tabela:
Todos os dados de um database DB2 são apresentados em forma de Tabelas. Quando se cria
uma Tabela, define-se a ordem das colunas.
A Performance é afetada por muitos fatores:
- Número de linhas acessadas
- Sequencia física dos dados
- Distribuição dos dados
- Estratégia de acesso
Índice:
Componente que prove controle de acesso aos dados sua utilização pode evitar algumas tarefas
indesejáveis na performance do DB2:
- TABLESPACE SCAN
- CLASSIFICAÇÕES
Create StoGroup
Create DatabaseDataBase1
Subsistema DB2
Create Tablespace
Stogroup1
Tablespace1
Create table
Table1
Create IndexIndex1 Index2
Table2

Caminhando pelo DB2
Otimizador DB2 – Acesso aos Dados
Com base em informações obtidas pelo SQL e Tabelas Internas do Catálogo DB2 o
OTIMIZADOR, que é um componente do SGBD DB2, irá determinar a melhor estratégia de
acesso aos dados solicitados.
Agora podemos entender claramente porque sempre temos que estar com a Estatística do
Catálogo DB2 atualizada, pois o Otimizador DB2 poderá criar uma estratégia de acesso não
compatível os dados contidos na Tabela DB2.
Portanto vale o ALERTA, SEMPRE garanta que o RUNSTAST esteja sendo executado
periódicamente para todas as tabelas.
OTIMIZADOR DB2
INDICE TABELA
QUERY AD HOCSQL ONLINE SQL BATCH

Caminhando pelo DB2
Otimizador DB2 – Dados utilizados
- O OTIMIZADOR DB2 é uma engenharia de Inferência construída no BIND
- É responsável por determinar a melhor estratégia de acesso possível para satisfazer uma
QUERY
- Determina o caminho de acesso, estimativas são calculadas utilizando as Estatística do
Catálogo
- Caso as Estatísticas não foram estabelecidas, o DB2 utilizará valores padrões para os
cálculos
ESTATÍSTICA VALOR PADRÃO
# de linhas 10.000
# valores na
coluna 25
- Estimativa de número de registros com um valor específico:
10.000
-------- = 400
25
SYSINDEXE
S
OTIMIZADOR DB2
SYSTABLE
S
COMANDO
S
SQL
SYSCOLUM
NS
SYSTABLE
SPACE
SYSFIELDS
Planos de
Aplicação
Estimativa de:
# de linhas examinadas
# de I/O
Quantidade de CPU usada
Atividade de SORT
Incluindo:
Estratégia de acesso
Estratégia de JOIN

Caminhando pelo DB2
Otimizador DB2 – EXPLAIN
Podemos obter informações sobre qual o a estratégia de acesso adotada pelo OTIMIZADOR
para uma determinada query, uma das maneiras possíveis é a utilização do COMANDO
EXPLAIN.
Com o EXPLAIN é gerado na Tabela PLAN_TABLE um conjunto de informações que indica
como o dado será obtido pelo DB2, por exemplo, utilizando o INDICE.
Esta claro que precisamos aprofundar mais tecnicamente sobre esse assunto, deixaremos isso
para uma outra ocasião. No momento temos elementos suficientes para entender sobre
PERFORMANCE.
OTIMIZADOR DB2
PLAN_
TABLE
EXPLAIN ALL
SET QUERYNO = 15 FOR
SELECT * FROM
EMPREGADO
WHERE
NOME LIKE ‘BAR%’
SORT
?
TECNIC
A
JOIN?
INDEX
ONLY
?
TABLESPAC
E
SCAN?
SEQUENTIAL OU
LIST
PREFETCH?
?
?
?

Caminhando pelo DB2
Capítulo 10 – Curiosidade mata! Um pouco de DATA SHARING!
Estamos aqui com outro assunto interessante, mas por força dos objetivos de nossa publicação
iremos apenas falar superficialmente.
DATA SHARING, basicamente é utilizar os recursos já existente no ambiente operacional
OS/390 e z/OS chamado PARALLEL SYSPLEX, que é pré-requisito básico para utlizarmos o
DATA SHARING no DB2.
Vamos tentar através da figura abaixo mostrar o ambiente DATA SHARING:
Dentro de um sistema operacional com PARALLEL SYSPLEX que é um conjunto de solução
HARDWARE + SOFTWARE. Podemos reparar os termos SYSPLEX TIMER e COUPLING
FACILITY.
Nesse mesmo sistema temos instalado dois sub-sistemas distintos DB2A e DB2B, cada um com
seu conjunto de WORK FILES, LOGS e BSDS. O que podemos perceber claramente é que o
BANCO DE DADOS está sendo compartilhado pelos dois DB2 simultâneamente.
Basicamente temos o ambiente DATA SHARING implementado e adminstrado pelo Gerenciador
DB2, evidente que temos inúmeras situações e detalhes que deixaremos para uma outra
ocasião.
DB2A
DB2
B
Sysplex
Timer
Coupling
Facility
Local
Buffer
Pools
Local
Buffer
Pools
Shared
DB
Work
Files
Work
Files
Logs
BSD
S
Logs
BSD
S

Caminhando pelo DB2
 Parte 4 - A hora é agora, vamos programar com o DB2?
o Capítulo 11 – Primeiro um pouco de conceito.
o Capítulo 12 – Considerações importantes.
o Capítulo 13 – Já que todos querem, vamos às Funções Avançadas.
o Capítulo 14 – Cuidado voce não está sózinho!

Caminhando pelo DB2
Capítulo 11 – Primeiro um pouco de conceito.
Em um ambiente de desenvolvimento de aplicações acessando dados DB2 geralmente
utilizamos as linguagens chamadas hospedeiras, tais como, COBOL, PL/I, ASSEMBLER, essas
linguagens não acessam nativamente a linguagem SQL, portanto devemos ter um procedimento
especial para compilarmos esses programas com o SQL embutido.
A primeira fase é chamada de pré-compilador que verifica a síntaxe SQL no programa fonte e
também substitui os comandos SQL por CALLs, gravando esses comandos em uma Biblioteca
chamada DBRM, a partir deste ponto dois procedimentos devem ser executados um que é o
processo tradicional de compilar a linguagem e gerar os módulos objeto e de carga (LOAD), o
segundo chamado de BIND que tem as seguintes funções:
- Verificar no Catálogo DB2 as descrições das tabelas e colunas e autorizações de acesso
- Criar a partir do DBRM uma entrada no catálogo SYSDBRM
- Criar o método de acesso pelo Otimizador DB2
- Gerar o PLANO ou PACKAGE no Catálogo e Diretório DB2
Após estas fases o programa está pronto para ser executado, e boa sorte!
SQL include Library
Código fonte com SQL
Fonte modificado
Modulo Objeto
LINK EDIT
Modulo de Carga/Language
Interface
COMPILE
PRECOMPILE
DBRM (PDSdo usuário)
Tabela/Coluna Descrição
SYSDBRM
Autorização
DB2 Catalogo
BIND
Package
DB2 Directory
Plano
DB2 Directory
EXECUTE

Caminhando pelo DB2
Capítulo 12 – Considerações importantes.
Elementos de um programa:
• Declaração de host variables
• Ler dados
• Passar dados para o DB2 inserir ou atualizar
• Usar em clausulas WHERE e HAVING
• Atribuir valores de CURRENT SQLID e DEGREE
• Inserir valores nulos (através de indicator variables)
• Conter um statement de SQL (EXECUTE, PREPARE, OPEN)
• Precedidas de “ : ”
• Estrutura host
• Um nome para varias variáveis host
• Declaração de tabelas/views
• Opcional, mas importante para melhor documentar o programa.
• Include de SQLCA
• Include/declaração de SQLDA
• Statements de SQL
• Checagem de erro/condições especiais
STATEMENT SQL
Teste
Execução
Comunicação
DB2
SQLCODE

Caminhando pelo DB2
Exemplo de um programa utilzando SQL:
MOVE 4476 TO RAISE.
MOVE '000220' TO PERSON.
EXEC SQL
SELECT EMPNO, LASTNAME, SALARY, SALARY + :RAISE
INTO :EMP-NUM, :PERSON-NAME, :EMP-SAL, :EMP-TTL
FROM DSN8510.EMP
WHERE EMPNO = :PERSON
END-EXEC.
Podemos notar no exemplo acima os seguintes detalhes:
- Os campos RAISE e PERSON na visão da linguagem hospedeira é um campo comum, já para
a linguagem SQL tem que ser precedida de “:”;
- Os delimitadores EXEC SQL e END-EXEC são obrigatórios para o pré-compilador saber quais
os comandos são SQL, portanto analisados e gravados no DBRM;
- A linguagem SQL é a padrão, não existe nenhum detalhe adicional, por estar codificada dentro
de um programa.
Exemplos de Variáveis Host aplicadas para cada Data Type do DB2:
DB2 PL/1 COBOL ASSEMBLER
SMALLINT DCL N1 BIN
FIXED (15);
01 N1 PIC S9(4) COMP. N1 DS H
INTEGER OR
INT
DCL N2 BIN
FIXED (31);
01 N2 PIC S9(9) COMP. N2 DS F
DECIMAL (5,2) *
OR
DEC (5,2)
DCL N3 DEC
FIXED (5,2);
01 N3 PIC S9(3)V9(2) COMP-3. N3 DC
PL5 ‘000.00’
FLOAT (21) OR
REAL
DCL N4 BIN
FLOAT (21);
01 N4 COMP-1. N4 DS E
FLOAT OR
FLOAT (53) OR
DOUBLE
PRECISION
DCL N5 BIN
FLOAT (53);
01 N5 COMP-2. N5 DS D

Caminhando pelo DB2
O Conceito de Cursores
Utilizamos os cursores quando necessitamos processar (acessar) multiplas linhas de uma tabela
dentro de uma linguagem hospedeira. Resumindo o cursor estabelece uma área de leitura da
tabela e passa uma linha por vez para o programa, pois as linguagens hospedeiras não
processam multiplas linhas simultaneamente.
Cursor
FETC
H
Identifica
Linha
Resultado do
SELECT
(OPEN
)
TABELA
Declare
Open, Close
Fetch
Select
Update
Delete

Caminhando pelo DB2
Capítulo 13 – Já que todos querem, vamos às Funções Avançadas
Basicamente iremos comentar sobre a utilização de STORED PROCEDURE.
Na figura abaixo podemos verificar claramente que ao utilizarmos a STORED PROCEDURE
teremos os seguintes benefícios:
Redução do tráfego de I/O na Rede
Elimina dependência do cliente no Servidor de Banco de Dados
Código é alterado no Servidor independente do Cliente
Reutilização de código
Segurança
CALL SP(P1,P2)
Aplicação
Cliente
SERVER – OS/390
STORED PROC
SQL
1
SQL
2
SQL
3
DB2
SP
Dados
Enviad
o
Banco
Dados

Caminhando pelo DB2
Capítulo 14 – Cuidado voce não está sózinho!
Neste capítulo estamos falando sobre concorrência de recursos pelas diversar aplicações o
gerenciador DB2 UDB possue um mecanismo de concorrência que é executado pelo
IRLMPROC, com as seguintes funções:
• Permite acesso concorrente aos dados
• Controlada através de locks
• Tamanho do lock
- Tablespace
- Table
- Página
- Linha
 Tipos de lock em páginas ou linhas:
- S (share) o proprietário do lock e qualquer processo concorrente pode ler, mas não
atualizar
- U (update) o proprietário do lock pode ler e atualizar e qualquer processo concorrente pode
obter lock S
- X (exclusive) somente o proprietário do lock pode ler e atualizar
Compatibilidade entre locks de página ou linha
Lock Mode
S
U
X
S U X

Caminhando pelo db2

Mais conteúdo relacionado

Mais procurados

Semelhante a Caminhando pelo db2

Caminhando pelo db2