Sumrio

Projeto/ Modelagem

Boas Prticas
06 Modelagem conceitual de um sistema de manutenes de automveis
[ Claudio Rinaldo ]

Boas Prticas
14 Trabalhando com herana no PostgreSQL
[ Marcelo Josu Telles ]

20 Migrao de dados utilizando Pentaho Data Integration

Banco de Dados [ Eduardo Alves de Carvalho ]
Banco de Dados/ Persistncia

Ol, eu sou o DevMan! Desta

34 Particionamento de dados no SQL Server pgina em diante, eu estarei
Boa Ideia
[ Ismael Costa Junior ] lhe ajudando a compreender
com ainda mais facilidade o
contedo desta edio. Ser
Banco de Dados
42 Seu banco de dados na nuvem da Amazon um prazer contar com sua
[ Rodrigo Buriola ] companhia! Confira abaixo o
que teremos nesta revista:

Minicurso
50 Particionamento no Oracle Parte 2
[ Ricardo Rezende ]

Minicurso
59 Oracle Scheduler Parte 2
[ Ricardo Rezende ]

Brinde na web desta edio

1) Criando Stored Procedures em C# com estrutura dinmica e parmetros - Curso Desenvolvimento para SQL Server com .NET - Parte 8
Nesta vdeo ser mostrado como criar uma Stored Procedure que utilize mais objetos do .NET, como DataTable e DataView em conjunto com o
SqlDataAdapter. Este ltimo usado para executar o comando SQL e preencher um DataTable com dados da tabela. A seguir, veremos como aplicar

1
um filtro nos dados usando um DataView (objeto que funciona de forma semelhante a uma View do SQL Server). O filtro seleciona apenas os registros
de acordo com um filtro condicional passado como parmetro para o mtodo. O interessante aqui que no devolvemos essa estrutura para o cliente.
Dinamicamente criamos uma estrutura de dados usando SqlMetaData, onde definimos as colunas e tipos. Depois, varremos a viso e para cada registro
filtrado criamos um SqlDataRecord, enviando ao cliente atravs do Pipe. Isso mostra como podemos manipular dados antes de envi-los ao cliente,
bem como criar uma estrutura dinmica de dados. Voc pode, por exemplo, usar SqlMetaData/SqlRecord para montar sua prpria tabela, com dados
provenientes das mais diversas fontes e obtidos das mais diferentes formas.
Vdeo
Para visualizar acesse o link:
http://www.devmedia.com.br/articles/listcomp.asp?keyword=sql106&codigobanca=green1

Gostou das vdeo aulas? O portal www.devmedia.com.br possui mais de 2 mil vdeo aulas e dezenas de cursos online sobre desenvolvimento de
software! Agora voc pode comprar as vdeo aulas que preferir e fazer sua prpria combinao de vdeos! Saiba mais em www.devmedia.com.br/creditos

eu
Feedback
D seu feedback sobre esta edio!
s
D

A SQL Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista!
sobre e

D seu voto sobre esta edio, artigo por artigo, atravs do link:
s

ta
edio
www.devmedia.com.br/sqlmagazine/feedback - Para votar, voc vai precisar do cdigo de banca desta edio, que : green1
 Expediente Editorial
EDITORIAL

C
om o implemento de novas tecnologias e o aumento da competitivi-
dade de se esperar que todas as organizaes passem por um pro-
cesso de evoluo em seus sistemas de informao. Independente de
ser motivada pelas deficincias do sistema atual ou pelos ganhos que o novo
sistema trar, a preocupao em no perder informao unnime.
normal que os sistemas tenham estruturas de dados e regras distintas en-
Ano 9 - 106 Edio 2012 - ISSN 1677918-5 - Impresso no Brasil tre si e por isso o processo de migrao pode ser bastante trabalhoso e o risco
de haver uma restrio que impea este processo de ser executado at o fim
muito grande. Como seria impossvel encapsular todo o processo em uma ni-
ca transao do banco de dados, o que permitiria um rollback em caso de erro,
Corpo Editorial algumas tcnicas so fundamentais para manter a rastreabilidade dos dados e
Atendimento ao Leitor
Editor Geral A DevMedia conta com um departamento exclu- poder retomar o processo de migrao de onde parou.
Rodrigo Oliveira Spnola sivo para o atendimento ao leitor. Se voc tiver Neste contexto, a SQL Magazine destaca nesta edio o tema Migrao de
rodrigo.devmedia@gmail.com algum problema no recebimento do seu exemplar Dados. O artigo em destaque apresenta tcnicas fundamentais para migrao
ou precisar de algum esclarecimento sobre assina-
turas, exemplares anteriores, endereo de bancas de dados e as suas melhores prticas atravs da utilizao de ferramenta espe-
Sub Editores
Eduardo Oliveira Spnola e Ricardo Rezende de jornal, entre outros, entre em contato com: cialista gratuita, de cdigo aberto, o Pentaho Data Integration (PDI).
Em complemento, a SQL Magazine traz nesta edio outras matrias muito
Jornalista Responsvel www.devmedia.com.br/central
interessantes envolvendo assuntos como SQL Server, Oracle, Banco de Dados
Kaline Dolabella - JP24185 (21) 3382-5038
na Nuvem e PostgreSQL. Uma tima leitura a todos.
Na Web Publicidade
Para informaes sobre veiculao de anncio na
www.devmedia.com.br/sqlmagazine
revista ou no site e para fechar parcerias ou aes
especficas de marketing com a DevMedia, entre
Distribuio
em contato com:
FC Comercial e Distribuidora S.A Rodrigo Oliveira Spnola
Rua Teodoro da Silva, 907 publicidade@devmedia.com.br
Graja - RJ - 206563-900 rodrigo.devmedia@gmail.com
Editor Chefe da SQL Magazine, Mobile e Engenharia
de Software Magazine.

Fale com o Editor!

muito importante para a equipe saber o que voc est
achando da revista: que tipo de artigo voc gostaria de
ler, que artigo voc mais gostou e qual artigo voc menos
gostou. Fique a vontade para entrar em contato com os
editores e dar a sua sugesto!
Se voc estiver interessado em publicar um artigo na
revista ou no site SQL Magazine, entre em contato com os
editores, informando o ttulo e mini-resumo do tema que
voc gostaria de publicar:
Rodrigo Oliveira Spnola - Editor da Revista
rodrigo.devmedia@gmail.com
Professor da Faculdade Ruy Barbosa, uma
instituio parte do Grupo DeVry.
Doutor e Mestre em Engenharia de Software pela
COPPE/UFRJ. Autor de diversos artigos cientficos
sobre Engenharia de Software publicados em
revistas e conferncias renomadas, dentro e fora
do pas.

Assine agora e tenha acesso a

todo o contedo da DevMedia:
www.devmedia.com.br/mvp
 the right-size Database

SQL E Isam Uma

Combinao De Sucesso!

Deixe o sistema de sua empresa mais leve

e rpido. Conhea as novidades do c-tree e
faa toda a diferena!
U ADICIONE processamento de transaes,
recuperao automtica, backups dinmicos e
replicao aos seus aplicativos.
U AMPLIE sua escolha de APIs com C, C++,
.NET, ODBC, JDBC, PHP e SQL.
U FAA como muitas empresas no mundo todo,
lderes em diversos segmentos como finanas,
telecomunicaes e sade, que tm baseado
suas solues crticas na tecnologia c-tree.

Baixe seu SDK grtis

www.faircom.com
ration
Corpo

11-3872-9802
irCom
1 Fa
201
 Modelagem conceitual de um sistema de manutenes de automveis
Seo Projeto/Modelagem Nesta seo voc encontra artigos sobre projeto, anlise ou modelagem de dados
Modelagem conceitual:
sistema de manutenes
de automveis
Construindo um modelo para sistemas de frotas
de veculos
D
urante a fase de levantamento de informaes
para o desenvolvimento de sistemas, comum
encontrarmos clientes e usurios que possuem
completo domnio sobre as informaes que sero traba-
lhadas em suas aplicaes, mas que por no possurem
a viso sistmica inerente aos profissionais de TI, no
conseguem expressar todos os aspectos que devem ser
cobertos na modelagem dos dados.
Naturalmente, aqueles que iro usufruir das melhorias
em seus sistemas atuais ou instalaes de novos aplica-
tivos devem ser especialistas em suas reas de conheci-
mento, deixando a cargo de analistas e desenvolvedores
a tarefa de interpretao dos dados e transformao dos
requisitos em ferramentas utilizveis para o usurio
final, melhorando assim seu fluxo de trabalho e conse-
quentemente sua produtividade.
O mercado de trabalho em TI utiliza diversas nomen-
claturas para funes semelhantes (analista de sistemas,
analista de requisitos, arquiteto de sistemas) cujas res-
ponsabilidades muitas vezes se sobrepem. Vamos con-
siderar o profissional responsvel pela modelagem de
dados apenas como projetista e apresentar um modelo
de negcio cujo foco de fcil compreenso para o leitor:
o controle de dados para manuteno de veculos.
Ao analisarmos os dados envolvidos na manuteno de
um veculo, podemos perceber uma quantidade aceitvel
de informaes que pode ser extrada para a criao de
um modelo de dados e que futuramente venha a gerar
acompanhamentos destas manutenes.
O modelo final poderia ser acoplado a outros sis-
temas que j possuem a entidade veculo como, por
exemplo, uma locadora de automveis ou uma empresa
de transportes. As possibilidades so mais atraentes para
6 SQL Magazine Edio 106
Resumo DevMan
De que se trata o artigo:
Este artigo apresenta os conceitos envolvidos na modelagem
conceitual e lgica dos dados que compe o controle de manuten-
es veiculares. Alm disso, ser apresentada a sua derivao para
o modelo fsico na forma de script de banco de dados, bem como
o entendimento da situao de negcios proposta.
Em que situao o tema til:
Partindo-se das entidades conceituais de um negcio e o relacio-
namento entre elas, possvel modelar todas as informaes que
estaro presentes no banco de dados. Tal abordagem comum em
diversas situaes reais de desenvolvimento de sistemas, onde o
projetista aborda as questes relevantes da modelagem atravs das
entidades identificadas na fase de levantamento e na sequncia
crias os atributos correspondentes.
Modelagem conceitual de um sistema de manutenes de automveis:
Na fase de modelagem de dados de um sistema comercial,
comum encontrarmos situaes onde a equipe de projetos aborda
as informaes a serem armazenadas atravs da identificao das
entidades representadas no sistema e a forma como se relacionam.
Atravs do entendimento do negcio a ser modelado, possvel
utilizar diagramas que apresentam graficamente a viso da equipe
de modelagem, demonstrando como foram definidas as entida-
des, seus relacionamentos e os atributos identificados para cada
uma delas. Para melhor entendimento, utilizamos as entidades e
atributos envolvidos em manutenes de veculos automotores.
Como parte de um sistema maior, foi concentrada a ateno s
entidades e informaes que devero ser abordadas para permitir
guardar os dados e recuperar informaes gerenciais sobre estas
manutenes.
estes ltimos casos, mas ao considerar a quantidade de informa-
es que podem ser extradas com os dados inseridos de forma
satisfatria, um pequeno aplicativo que permita relatrios e vises
com dados filtrados j seria de grande valia para o usurio final,
ainda que este disponha de um nico automvel.
Outro fator que observamos no dia a dia nas fases de anlise de um
sistema a tendncia das informaes j existirem em planilhas com
os dados do negcio a ser analisado. Estas planilhas naturalmente
no passam pelo processo de normalizao, onde as informaes ao modo como os usurios percebem os dados. a viso das pessoas sobre a informao. Nesta
encontram-se com repeties e incidncia de valores que podem ser
calculados a partir de outros. Como ponto de partida de nosso exem-
plo, vamos analisar quais dados devem ser anotados para registrar
uma manuteno em um veculo, conforme indicado na Figura 1.
Abordagem
Se considerarmos a abordagem de um levantamento de dados
e criao das entidades estruturadas que por fim iro definir
atributos e tabelas, o enfoque do ponto de vista acadmico e
metodolgico seria a definio de todas as informaes presen- Ferramenta
tes no contexto e sua decomposio atravs da normalizao.
O desenvolvedor provavelmente j se deparou com situaes onde
o ponto de partida no a informao em sua menor unidade, ou gratuito que permite a construo do Modelo Conceitual, sua
seja, os atributos, mas sim o conceito das entidades e a forma como
se relacionam. Os atributos so ento inseridos em cada entidade, banco de dados do Modelo Fsico em padro SQL ANSI-2003 (ver
que em uma decomposio do modelo conceitual do sistema em seu
modelo lgico, produziria todas as tabelas e relacionamentos a se-
rem implementados no banco de dados (ver Nota do DevMan 1).
A percepo das informaes pelas pessoas, neste caso usurios
e clientes, definindo entidades e a forma como estas se relacionam,
ir gerar um Modelo Entidade-Relacionamento que, apesar de
criado em simbologia, permite a apresentao de forma clara aos
usurios do futuro sistema.
Vale ressaltar o papel do profissional de TI neste instante, que
de forma consciente deve apresentar seu entendimento e mostrar
como foram identificadas as entidades, atributos e principalmente
seus relacionamentos, jamais deixando a cargo dos usurios a
interpretao isolada e sem possibilidade de questionamentos.
A representao do sistema em entidades parte do princpio que
no mundo real estas nunca esto sozinhas, geralmente associadas
entre si atravs dos relacionamentos.
A tarefa do projetista, neste contexto, reconhecer e registrar
as associaes entre entidades, fornecendo uma representao do
ambiente do sistema. O objetivo na fase de validao do entendi-
mento da equipe de desenvolvimento com os usurios, como o
prprio sugere, validar se a interpretao feita est de acordo produtos, o que no garante a imediata portabilidade da estrutura de um gerenciador para outro.
com a realidade do negcio.
Figura 1. Dados dispostos em uma planilha de controle de manutenes
Sendo assim, partiremos do entendimento como as entidades
envolvidas na manuteno de um veculo esto relacionadas, para
depois definir quais atributos e at mesmo suas chaves.
Nota do DevMan 1
Modelos de dados: Modelo de dados de alto nvel ou conceituais: apresenta conceitos prximos
situao temos o Modelo Conceitual, facilmente entendvel para os usurios atravs de um Modelo
(ou Diagrama) Entidade-Relacionamento. Este nvel de abstrao em muito facilita a validao das
informaes, gerando uma ponte entre o entendimento de negcios e a viso do desenvolvedor.
Modelo de dados de baixo nvel ou fsicos: apresentam detalhes de como os dados so armazenados
em meio eletrnico. Representa a viso da tecnologia sobre a informao. Encontram-se neste grupo
os Modelos Lgico e Fsico. O primeiro gerado a partir do Modelo Conceitual e dispe os atributos em
tabelas, define tipos de dados, identifica chaves e relacionamentos e permite a adoo de padres e
nomenclaturas, e no segundo considera-se limitaes dos SGBDs definidos para o sistema dentro das
definies impostas pelos modelos anteriores.
Para a criao do modelo conceitual dos exemplos utilizou-se a
ferramenta CASE brModelo (ver Nota do DevMan 2), software
derivao para o Modelo Lgico e at a gerao dos scripts de
Nota do DevMan 3). A ferramenta de fcil utilizao, e alm
do diferencial da gratuidade, permite a execuo diretamente em
dispositivos de armazenamento mvel como pen drives.
Nota do DevMan 2
Ferramentas CASE: Ferramenta CASE (Computer Aided Software Engineering) um tipo de
software que auxilia a equipe de projeto a desenhar o sistema e gerar estruturas que podero ser
direcionadas para a criao de bases de dados e cdigos fonte.
Nota do DevMan 3
SQL: A linguagem SQL (Structured Query Language) uma linguagem comercial de banco de dados
de larga utilizao no mercado atual de armazenamento de informaes. Organizaes internacionais
como ANSI e ISO trabalham no sentido de padroniz-la desde 1986, gerando as verses SQL-86, SQL-
92, SQL:1999 e SQL:2003, o mais atual. Como caractersticas das ltimas verses podemos destacar no
SQL:1999 o uso de expresses regulares de emparelhamento, queries recursivas e gatilhos (triggers)
e na verso SQL:2003 a adio de tipos no-escalados, caractersticas de orientao a objeto,
caractersticas de XML, sequncias padronizadas e colunas com valores de auto-generalizao. Apesar
destas especificaes, os fabricantes de bancos de dados implementam variaes especficas em seus
Edio 106 SQL Magazine 7
Modelagem conceitual de um sistema de manutenes de automveis
Na implementao fsica do banco de dados foi utilizado o
Microsoft SQL Server 2008 Express (ver Nota do DevMan 4),
verso gratuita do gerenciador. Apesar das limitaes que apre-
senta em sua utilizao comercial frente s verses pagas, permite
implantar e utilizar o modelo de dados proposto.
Nota do DevMan 4
SQL Server 2008: O SQL Server 2008 Express apresenta em sua verso gratuita ferramentas de
gerenciamento de fcil utilizao como, por exemplo, a ferramenta de gerenciamento grfico SQL
Server Management Studio (SMSS) Express. Esta verso apresenta limitaes de CPU e memria,
respectivamente uma CPU e 1GB RAM, alm da limitao de base de dados de 10GB. Apesar das
limitaes, a verso liberada para uso comercial.
Tutorial
Sistema
O ponto de partida ser a existncia de uma entidade veculo, de
onde queremos manter o controle das manutenes efetuadas ao
longo de sua existncia. Conforme indicado anteriormente, uma
vez definida esta entidade, possvel relacionar o modelo com
outros que representam negcios automotivos onde relevante
o controle de manutenes.
Dada a maneira como as informaes sero dispostas, com a
utilizao constante do sistema ser possvel extrair diversos
nveis de informaes que ajudariam a identificar manutenes
preventivas e antecipar desgaste de peas. Afinal, querendo
ou no, veculos fazem visitas regulares oficinas e servios
especializados como consequncia da prpria utilizao no
cotidiano.
Em seguida, temos outra entidade de grande importncia para
nosso modelo, que a prpria manuteno em si, ou melhor, a
entidade que ir permitir controlar estas informaes. Partindo-
se das entidades principais do sistema, neste caso, Veculo e
Manuteno, ser mais natural a definio das demais, evitando
distraes por parte do profissional que executa a modelagem.
Sendo assim, definimos na Figura 2 que um determinado veculo
ir possuir diversas manutenes.
Figura 2. Relacionamento entre as entidades Veculo e Manuteno
Na prxima parte a ser analisada, identificamos que uma
determinada manuteno poder ser atravs da execuo de
Servios (ex.: Funilaria, Pintura, Instalao) e que poder envolver
8 SQL Magazine Edio 106
Peas (ex.: Amortecedor, Correia) e Produtos (ex.: leo do Motor,
Lanterna). Estas entidades estaro relacionadas com a entidade
Manuteno, que ir centralizar o conceito de algum tipo de ati-
vidade que dever ser registrada no sistema.
Da mesma forma, necessrio prever que uma mesma manu-
teno poder exigir todos estes conceitos como, por exemplo, a
instalao de uma pea que envolva produtos e onde seria cobrada
a mo-de-obra na forma de servio. Um dos atributos que j deve
ser identificado neste momento diz respeito questo dos valores,
onde ser necessrio armazenar em cada uma destas entidades
o valor de cada Pea/Produto/Servio e efetuando-se as devidas
operaes para obter o valor total da manuteno.
O projetista teria neste ponto da anlise a possibilidade de uti-
lizar mais de uma tcnica de modelagem. Uma alternativa que
foi apresentada no modelo final seria a utilizao dos conceitos
de Generalizao/Especializao, que nos remete s tcnicas de
orientao a objetos no entendimento de como as entidades base
fornecem atributos para as entidades derivadas.
Podemos partir dos tipos bsicos de manuteno (Servio/Peas/
Produtos), identificar suas caractersticas em comum e gerar uma
entidade que serviria de base para estas, o que permitiria aplicar
o conceito de herana. Esta tcnica definida como generalizao,
pois atravs de uma anlise bottom-up, os conjuntos de entidades
so sintetizados em uma entidade de nvel mais alto com base nos
atributos em comum.
A outra abordagem seria pensar em uma manuteno e realizar
a sua especializao, tcnica top-down que permite destacar na
forma de atributos distintos as entidades dos nveis inferiores.
A representao das tcnicas de generalizao/especializao
para este cenrio pode ser conferida na Figura 3.
Figura 3. Generalizao/Especializao das entidades relacionadas Manuteno
O projetista, porm, optou por no representar as informaes
desta forma, mantendo a diagramao do modelo conceitual
apenas com o relacionamento direto entre as entidades, como
apresentado na Figura 4. No estudo deste modelo conceitual,
observou-se que o efeito produzido ser o mesmo na derivao
deste modelo para o lgico que define a estrutura das tabelas no
banco de dados.
No ocorrendo prejuzo para o registro dos dados no sistema ou
mesmo para as regras de normalizao, as duas formas podem ser
utilizadas sem prejuzo no resultado final. interessante ressaltar
que para utilizar os conceitos de generalizao/especializao o
projetista dever ter noes claras de como funciona o conceito
de herana de atributos. Desta forma, evita-se que mais adiante
na modelagem apaream informaes que jamais seriam preen-
chidas, pela no necessidade de uma determinada informao
sobre a entidade.
Figura 4. Entidades ligadas Manuteno atravs de relacionamentos
Um para muitos ou nenhum para muitos?
Observa-se que em alguns modelos entidade-relacionamento,
existe pouca preocupao em definir corretamente o que 1
para muitos e 0 para muitos. No primeiro caso, criada um
obrigatoriedade, ou seja, uma ocorrncia da entidade tem que estar
relacionada com pelo menos uma de outra ou vrias, enquanto que
no segundo caso uma ocorrncia pode ou no estar relacionada
com outra entidade.
A diferena parece clara, porm em alguns casos a modelagem
feita de maneira uniforme, sempre indicando o mesmo tipo
de relao, sendo que a perda acaba ocorrendo no sentido de
documentao do sistema, pois a obrigatoriedade ou no das
ocorrncias ajuda no melhor entendimento do negcio.
Este ser o ponto de maior trabalho em nosso modelo, pois ca-
racterizar a manuteno de acordo com o servio relativamente
simples. Ao utilizar um relacionamento N-N (muitos para muitos),
o prprio software de modelagem, ao derivar o modelo lgico, j
cria as entidades associativas. Uma manuteno poder ter gerado
diversas ocorrncias de servio e estas por sua vez podero estar
em diversas ocorrncias de manuteno.
Entre estas entidades ser gerada uma entidade associativa, que
ir concentrar as duas chaves primrias no formato de chaves
estrangeiras. Nas Figuras 5 e 6, respectivamente, possvel obser-
var o modelo conceitual com a indicao de N-N e sua derivao
gerando uma tabela associativa entre as demais.
Na mesma linha de raciocnio, uma manuteno poderia utili-
zar produtos e peas, sendo que devemos levar em considerao
os fabricantes de cada caso. No exemplo da Figura 7, observa-se
que um Fabricante pode produzir ou no produtos, enquanto
que um Produto deve obrigatoriamente ser de pelo menos um
fabricante.
Figura 5. Relacionamento conceitual entre as entidades Manuteno e Servio
Figura 6. Relacionamento lgico entre as entidades Manuteno e Servio
Figura 7. Relacionamento conceitual entre as entidades Produto e Fabricante
Naturalmente faria pouco sentido, quando da utilizao do
sistema, cadastrar fabricantes que no produzem produtos que
sero utilizados para caracterizar uma manuteno. A mesma
abordagem ser dada ao conceito de Fabricante e Pea, sendo que
aproveitaremos a primeira entidade para o mesmo fim.
Resolvendo-se os relacionamentos N-N entre as entidades Fabri-
cante/Pea e Fabricante/Produto, necessrio atualizar esta nova
entidade que ser gerada com a entidade Manuteno. Exempli-
ficando atravs de informaes, imaginemos uma determinada
manuteno onde foi utilizado um produto X do fabricante A e
uma pea Y do fabricante B. necessrio associar no somente
a pea ou produto, mas a composio das duas informaes na
entidade que associou Produto/Fabricante e Pea/Fabricante.
Apesar da praticidade da ferramenta utilizada, foi necessrio
uma carga extra de trabalho para gerar esta entidade de forma a
produzir um modelo lgico coerente a ser implementado no banco
de dados. O resultado pode ser conferido nas Figuras 8 e 9, onde
ainda estamos definindo as chaves no modelo conceitual apenas
para conferir a gerao do modelo fsico.
Observa-se na Figura 9 que a ferramenta automaticamente ge-
rou uma tabela Fabricante/Pea e outra para Fabricante/Produto,
uma vez que esta a forma que um relacionamento N-N assume
no modelo lgico. Podemos dizer que o relacionamento N-N
transformou-se em um 1-N / N-1, ou seja, um Fabricante pode
produzir 1 ou mais Peas, uma Pea pode ser produzida por 1 ou
mais Fabricantes.
Porm, ao gerar o modelo lgico, necessrio realizar uma
alterao nestas tabelas, pois como em nosso modelo conceitual
nomeamos as relaes como Produz, necessrio atribuir um
Edio 106 SQL Magazine 9
Modelagem conceitual de um sistema de manutenes de automveis
nome nico no modelo gerado, pois este ser derivado para o
modelo fsico, ou se preferir, um script para criao das tabelas
em um banco de dados.
Criamos ento as tabelas FABRICANTE_PECA e FABRICANTE_
PRODUTO, que iro relacionar as informaes das entidades en-
volvidas. Este tipo de construo auxilia no desenvolvimento de
Figura 8. Relacionamento lgico entre as entidades de Manuteno
Figura 9. Relacionamento conceitual entre as entidades de Manuteno
10 SQL Magazine Edio 106
telas de cadastro, onde o usurio poder associar uma mesma Pea
ou Produto diversos Fabricantes, que o conceito regularmente
encontrado em sistemas automotivos.
Estas entidades geradas devero agora ser associadas com as
respectivas entidades de manuteno, ou seja, uma manuteno
de Pea dever estar associada Fabricante/Pea e uma de Produto
dever associar-se Fabricante/Produto.
Para que continuemos utilizando a ferramenta brModelo, a
melhor abordagem, pensando-se no produto final que a ge-
rao do modelo fsico, foi a associao direta das entidades de
manuteno de Pea e Produto diretamente com as entidades
menores, ao invs das entidades associativas. Novamente nas
Figuras 8 e 9 possvel observar estas caractersticas, sendo
que em outras ferramentas CASE o modelo poderia assumir
variaes com o mesmo propsito.
Analisando-se em seguida os demais conceitos de Montadora,
Loja e Oficina, assumiu-se que uma manuteno poder ser feita
em uma oficina que pode ou no pertencer prpria montadora e
que tambm desejamos guardar as informaes de onde o veculo
foi adquirido.
Da mesma forma, a loja poder pertencer ou no uma
montadora, caracterizando uma concessionria, porm man-
teremos o relacionamento entre estas entidades como descrito
na Figura 10.
Aproveitando-se a explicao sobre a entidade Montadora, tam-
bm podemos definir que esta fabrica diversos Modelos, cada um
caracterizado por um nico Tipo (passeio, carga, utilitrio, etc.)
e que ir gerar diversos Veculos. Fechamos assim o conceito do
modelo como um todo, voltando entidade Veculo. Basta agora
finalizar a incluso dos demais atributos s tabelas, ressaltando-se
duas caractersticas em nosso modelo final:
Consideramos chaves auto incrementadas, exceto pela chave
da tabela Veculo, para a qual sugerido o nmero do Rena-
vam, o qual consta na forma de valor nico para o sistema do
Figura 10. Relacionamento conceitual entre Montadora/Veculo/Oficinas
departamento de trnsito e que pode facilmente ser encontrado
na documentao do veculo;
No abordaremos, para efeito de aumentar mais ainda nosso
modelo, informaes sobre a venda do veculo. Alguns atributos
foram indicados apenas para complementar o conceito, porm
tal discusso aumentaria demais o escopo. Fica a sugesto para o
leitor finalizar este conceito, como forma de praticar a modelagem
em todas as suas fases.
A Figura 11 exibe a forma final de nosso modelo Conceitual.
A Figura 12 demonstra como o modelo lgico foi gerado e ajustado
com os respectivos nomes nas entidades associativas. Por fim, o
script final de banco de dados implementado no Microsoft SQL
Server Express e gerou o modelo exibido na Figura 13. O script
completo encontra-se disponvel no download da revista, no site
da DevMedia.
Figura 11. Modelo Conceitual completo
Concluso
A modelagem de informaes de importncia crucial em
qualquer sistema que manipule uma quantidade de dados
relacionados entre si na forma de tabelas. Erros nesta fase
podem gerar manutenes complexas e delicadas, envolven-
do no apenas os profissionais que administram os bancos
de dados, mas tambm as equipes de desenvolvimento de
aplicaes.
Compreender e praticar a modelagem de dados uma tarefa
que cabe ao projetista de sistemas quando incumbido desta
fase do projeto, e a chave para o sucesso na compreenso do
negcio a que se destina o sistema. Oferecemos neste artigo
uma abordagem de fcil compreenso, porm com elaborao
detalhada, que poder direcionar os profissionais que se de-
dicam tarefa de definio de entidades e relacionamentos
em um projeto de sistemas.
Edio 106 SQL Magazine 11
Modelagem conceitual de um sistema de manutenes de automveis

Figura 12. Modelo Lgico completo

12 SQL Magazine Edio 106

Figura 13. Representao do Modelo Fsico implementado no SQL Express 2008

Claudio Rinaldo Silberschatz, Abraham; Korth, Henry F. e Sudarshan, S. Sistema

prof.rinaldo@hotmail.com de Banco de Dados, Pearson Makron Books, 1999.
Profissional de desenvolvimento de sistemas atuando no
mercado desde 1994, formado em Processamento de Dados e Elmasri, Ramez; Navathe, Sistemas de Banco de Dados - 6 Ed.,
Ps-graduado em Sistemas de Informatizao Empresarial e Gesto Pearson Education do Brasil
de Projetos. Trabalhou em diversas empresas sempre em equipes de
anlise e desenvolvimento de aplicaes, quase em sua totalidade em plataforma Microsoft SQL Server 2008 Express
Microsoft (Visual Basic/C++/C#, SQL Server). http://www.microsoft.com/pt-br/download/details.aspx?id=23650

D seu feedback sobre esta edio! eu

Feedback Ferramentas Case
http://www.devmedia.com.br/ferramentas-case-parte-i/1505/
s
D

A SQL Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que
sobre e

voc, leitor, acha da revista! brModelo

s

ta
edio

D seu voto sobre este artigo, atravs do link: http://www.devmedia.com.br/brmodelo-um-software-free-para-modelagem-

www.devmedia.com.br/sqlmagazine/feedback de-dados/2192

Edio 106 SQL Magazine 13

Seo Banco de Dados/Persistncia
Nesta seo voc encontra artigos banco de dados, SQL ou persistncia
Trabalhando com
herana no PostgreSQL
O Resumo DevMan
padro SQL:1999 (ver Nota do DevMan 1) intro-
duziu uma srie de extenses, para o at ento
suficiente padro SQL-92. Uma das extenses
do SQL:1999, definida como herana de tabela, par-
cialmente oferecida pelo PostreSQL. Para utiliz-la ne-
cessrio compreender a sua respectiva sintaxe. Ao longo
deste artigo ser apresentado desde como implementar
o recurso de herana at como realizar as consultas em
tabelas que herdam atributos.
Verses anteriores do PostgreSQL utilizavam sintaxes
que foram reestruturadas a partir da verso 7.1. Atual-
mente a verso disponibilizada no site do desenvolve-
dor a 9.2, no entanto, a verso adotada para os testes
que sero realizados neste artigo a 9.0. O SGBDOR
PostgreSQL pode ser obtido no site do prprio desenvol-
vedor ou tambm no site EnterpriseDB, que um dos
patrocinadores oficiais do PostgreSQL.
Assim, neste artigo ser apresentada a sintaxe do
PostgreSQL, bem como suas modificaes para imple-
mentao de herana em tabelas. Para isso, ser criado
um banco de dados e duas tabelas (uma delas com he-
rana) para testar o funcionamento das consultas sobre
tais dados. Para verificar motivos de implantar tabelas
com herana, sero desenvolvidas tabelas sem herana,
para no final do artigo realizar comparaes em um mo-
delo com herana e um modelo sem herana. Ao final, o
artigo destaca a importncia e os aspectos que podem
obter vantagem com o correto uso de herana.
Tutorial
Desenvolvimento da base de dados, tabelas e vises
Nos testes feitos ao longo deste artigo ser utilizada a
base de dados da Listagem 1.
O conceito de herana proposto pelo SQL:1999 define
que uma tabela pode herdar atributos de uma outra tabe-
la, facilitando em algumas situaes a manipulao dos
dados, alm de armazenar em apenas um local dados
de mesma estrutura. No PostgreSQL temos a clusula
INHERITS, que uma extenso do PostgreSQL
linguagem. O estilo de herana proposto no SQL:1999
14 SQL Magazine Edio 106
De que se trata o artigo:
Este artigo descreve conceitualmente o recurso herana de tabelas
oferecido pelo Gerenciador de Bancos de Dados Objeto-Relacional
(SGBDOR) PostgreSQL. Alm de conceituar, ser dada nfase em
exemplos diversificados, visando esclarecer a utilidade e a forma de
utilizao de tal recurso bem como compreender a sintaxe especfica
do PostgreSQL para herana de tabelas. Como objetivo o artigo busca
explorar a forma que o PostgreSQL permite a implantao do recurso
de herana, limitando-se em apresentar detalhes para: criao dos
tipos (type) de dados, criao das tabelas (table) e desenvolvimento
de consultas (view e function) dos dados.
Em que situao o tema til:
Durante o desenvolvimento de estruturas para armazenar dados,
existe a necessidade de levar em considerao exigncias das apli-
caes e recursos que o banco de dados oferece. O banco de dados
PostgreSQL 9.0 apresenta algumas caractersticas importantes de
serem conhecidas. As funcionalidades do PostgreSQL esto em
conformidade com o SQL-92 e ainda admite vrios recursos da
SQL:1999. Neste sentido, o presente artigo visa apresentar formas
de utilizao do recurso de herana em tabelas.
Trabalhando com herana no PostgreSQL:
Neste artigo ser apresentada a sintaxe do PostgreSQL bem como
suas modificaes (da verso 7.1 em diante) para implementao de
herana em tabelas. Ser criado um banco de dados e duas tabelas
(uma delas com herana) para testar o funcionamento das consultas
sobre tais dados. Para conhecer motivos de implantar tabelas com
herana, sero desenvolvidas tabelas sem herana, para no final
do artigo realizar comparaes em um modelo com herana e um
modelo sem herana. Embora algumas fontes indiquem que no
vantajoso utilizar herana, inclusive alguns sites indicam no
utilizar, o artigo destaca a importncia e os aspectos que podem
obter vantagem com o correto uso de herana.
ainda no suportado pelo PostgreSQL, pois o PostgreSQL, no
contempla todas as funcionalidades de forma idntica.
No PostgreSQL, quando um tabela criada, podemos utilizar a
clusula INHERITS citada acima. Desta forma, a tabela receber
todas as colunas de uma outra tabela. Abaixo temos um exemplo
de criao de um tipo de dado chamado tipo_empregado na
Listagem 2 e a tabela chamada empregados na Listagem 3.
Criada a tabela empregados, podemos criar uma view. Na
Listagem 4 temos a criao e utilizao de uma view para
empregados.
Listagem 1. Base de dados do exemplo
Criada a tabela gerentes, podemos criar a visualizao de
seus dados. Na Listagem 6 temos a criao e utilizao de uma
view para gerentes.
Para remover uma view basta utilizar o comando: DROP view
<nome da view>. J para popular as tabelas, utilizamos normal-
mente as operaes insert. Na Listagem 7 temos um conjunto de
dados sendo inseridos.

CREATE DATABASE sqlMagHerancaPostgreSQL

WITH OWNER = postgres Listagem 5. Tabela gerentes
ENCODING = UTF8
TABLESPACE = pg_default create table gerentes(
LC_COLLATE = C comissao float,
LC_CTYPE = C CONSTRAINT codigo PRIMARY KEY (codigo)
CONNECTION LIMIT = -1; )
inherits (empregados);
Listagem 2. Criao do tipo de dado tipo_empregado
Listagem 6. View da tabela gerentes
CREATE TYPE tipo_empregado AS (
codigo integer, CREATE VIEW dados_gerentes AS
nome text,
dataNascimento date, select codigo,nome,dataNascimento,salario,comissao from gerentes;
salario numeric);
select * from dados_gerentes;
Listagem 3. Criao da tabela empregados
Listagem 7. Instrues SQL para inserir os registros utilizados nos testes
CREATE TABLE empregados
INSERT INTO empregados VALUES (1, Julio, 1970-01-15, 1000.50);
OF tipo_empregado
(
INSERT INTO empregados VALUES (2, Maria, 1975-07-22, 1450.10);
codigo WITH OPTIONS NOT NULL,
-- Inherited from type tipoempregado: name,
INSERT INTO empregados VALUES (3, Pedro, 1974-12-01, 2000.90);
-- Inherited from type tipoempregado: salario,
CONSTRAINT empregados_pkey PRIMARY KEY (codigo)
INSERT INTO gerentes VALUES (4, Floriano, 1968-12-21, 1700.45, 10);
)
INSERT INTO gerentes VALUES (5, Maximiliano, 1965-10-19, 1900.99, 18);
WITH (
OIDS=FALSE
);

Listagem 4. Nova view

Sintaxe do PostgreSQL
Dadas s duas tabelas apresentadas na seo anterior, podemos
CREATE VIEW dados_empregados AS imaginar as seguintes situaes:
Consultar apenas os empregados que no so gerentes;
select codigo,nome,dataNascimento,salario from empregados;
Consultar apenas os empregados que so gerentes;
select * from dados_empregados; Consultar todos os empregados da empresa, incluindo gerentes e
no gerentes, estes ltimos com o valor de sua respectiva comisso.

Perceba que a execuo da view dados_empregados retorna

Nota do DevMan 1 o seguinte conjunto de dados:

Padro SQL:1999 1;Julio;1970-01-15;1000.50

SQL:1999 ou SQL3 um conjunto de tipos, formas de armazenamento e operaes sobre dados. 2;Maria;1975-07-22;1450.10
Este conjunto foi proposto por uma srie rgos e publicado na ISO (International Organization for
Standardization) em 1999. A proposta fruto de anos de estudo e tem como resultado um documento 3;Pedro;1974-12-01;2000.90
onde so definidas regras e demais detalhes de funcionamento que constituem o padro SQL:1999.
4;Floriano;1968-12-21;1700.45

Neste momento podemos criar a tabela que herdar as informa- 5;Maximiliano;1965-10-19;1900.99

es contidas em empregados. Na Listagem 5 temos o exemplo de

criao da tabela (gerentes) que herda todas as colunas da tabela Perceba que os dois ltimos registros no fazem parte do con-
empregados. Perceba que na criao da tabela gerentes temos a junto de dados desejado. Para obter os dados corretos, devemos
clusula INHERITS. utilizar a clusula ONLY, como mostrado na Listagem 8.

Edio 106 SQL Magazine 15

Trabalhando com herana no PostgreSQL
Listagem 8. Busca dos dados apenas da tabela empregados
-- View: dados_empregados
-- DROP VIEW dados_empregados;
CREATE OR REPLACE VIEW dados_empregados AS
SELECT empregados.codigo, empregados.nome, empregados.datanascimento,
empregados.salario
FROM ONLY empregados;
ALTER TABLE dados_empregados OWNER TO postgres;
Desta forma, a view ir retornar o seguinte resultado:
1;Julio;1970-01-15;1000.50
2;Maria;1975-07-22;1450.10
3;Pedro;1974-12-01;2000.90
Para obter apenas os dados dos funcionrios que so gerentes,
podemos apenas utilizar a view dados_gerentes apresentada
sem a necessidade de utilizar a clusula ONLY. Perceba que a
view dados_gerentes mostra o mesmo resultado caso tivesse
a clusula ONLY. A view gerentes utilizando a clusula ONLY
ficar da seguinte forma:
SELECT gerentes.codigo, gerentes.nome, gerentes.datanascimento, gerentes.salario,
gerentes.comissao
FROM ONLY gerentes
A seguir temos o resultado da consulta anterior com ONLY e da
view dados_gerentes sem o uso do ONLY:
4;Floriano;1968-12-21;1700.45;10
5;Maximiliano;1965-10-19;1900.99;18
Como a visualizao dados_gerentes foi desenvolvida na
tabela gerentes, a qual apenas recebe os atributos de uma outra
tabela (empregados), os dados relativos a empregados (que no
so gerentes) no so encontrados na tabela gerentes. O contrrio
no verdadeiro, pois na tabela empregados, a qual armazena
os atributos que so herdados, todos os dados de empregados
e gerentes so encontrados (com exceo da comisso), j que a
comisso faz parte da estrutura da tabela gerentes.
Para mostrar os dados das duas tabelas, podemos proceder como
mostrado na Listagem 9.
Listagem 9. Unio das consultas s duas tabelas
SELECT
empregados.codigo, empregados.nome, empregados.dataNascimento, emprega-
dos.salario
from empregados
UNION ALL
select gerentes.codigo, gerentes.nome, gerentes.dataNascimento, gerentes.salario
from gerentes
16 SQL Magazine Edio 106
Perceba que a clusula UNION ALL pode no atender plena-
mente a necessidade, pois como feita uma unio de todas as
linhas, o resultado ser uma repetio de um registro (todos os
registros da tabela gerentes tambm esto na tabela empre-
gados). Observe abaixo o resultado da consulta anterior (no
apresenta a comisso):
1;Julio;1970-01-15;1000.50
2;Maria;1975-07-22;1450.10
3;Pedro;1974-12-01;2000.90
4;Floriano;1968-12-21;1700.45
5;Maximiliano;1965-10-19;1900.99
4;Floriano;1968-12-21;1700.45
5;Maximiliano;1965-10-19;1900.99
Caso no estivssemos utilizando o ALL, o resultado seria o
seguinte:
1;Julio;1970-01-15;1000.50
2;Maria;1975-07-22;1450.10
3;Pedro;1974-12-01;2000.90
4;Floriano;1968-12-21;1700.45
5;Maximiliano;1965-10-19;1900.99
Note que dessa forma resolvemos o problema da repetio, mas
a consulta continua no apresentando a comisso.
Mais detalhes sobre a sintaxe do PostgreSQL
Nas verses anteriores a 7.1 do PostgreSQL, tais consultas eram
feitas de formas diferentes. O comportamento padro era no
incluir as tabelas descendentes, ou seja, as tabelas que herdam.
Portanto, os comandos SELECT, UPDATE, DELETE no funcio-
navam com a mesma lgica apresentada acima utilizando ONLY.
Descobriu-se que isso ocasionava muitos erros, e que tambm
violava o padro SQL:1999. Na sintaxe antiga, para incluir as ta-
belas descendentes era necessrio anexar um sinal de * (asterisco)
ao nome da tabela, conforme exemplo a seguir:
SELECT * FROM empregados*;
Na verso 9.0 do PostgreSQL, o uso do asterisco tambm funciona
sem problemas, mostrando dados de empregados e gerentes. Des-
ta forma, as verses posteriores a 7.1 ainda permitem especificar
explicitamente a varredura das tabelas descendentes anexando o
*, assim como especificar explicitamente para no varrer as tabelas
descendentes escrevendo ONLY. A partir da verso 7.1 o com-
portamento padro para nomes de tabelas sem adornos passou a
ser varrer as tabelas descendentes tambm, enquanto antes desta
verso o comportamento padro era no varrer as tabelas descen-
dentes. Para habilitar o comportamento padro antigo, podemos
proceder de duas formas. Uma delas em tempo de execuo, via
sentena SQL, onde podemos definir o comportamento de herana
conforme desejarmos. A seguir temos o exemplo onde opo de
configurao sql_inheritance desabilitada:
SET sql_inheritance TO OFF;
A outra forma de definir a configurao sql_inheritance para
que aplicaes que foram desenvolvidas utilizando verses an-
teriores a 7.1 funcionem em verses posteriores configurando
uma varivel no servidor, nas propriedades de configurao (no
arquivo .conf), e esta varivel deve ter o valor FALSE. Em longo
prazo incentiva-se mudar os aplicativos para que passe a utilizar
a palavra chave ONLY para excluir as subtabelas e deixar o valor
desta varivel como true ou no utiliz-la.
Perceba que a unio das tabelas ainda no apresenta todos os
dados da tabela gerentes, o mais comum apresentar dados das
duas tabelas. Perceba ainda que os dados precisam de um controle
maior. Caso desejemos apresentar os dados de todos os empre-
gados, incluindo gerentes com seus dados especficos (comisso),
podemos proceder da seguinte forma: criar uma funo, assim
como apresentado na Listagem 10.
til apenas se desejarmos remover futuramente a funo, por
algum motivo qualquer.
Na linha 3 temos a criao da funo. Perceba que estamos
utilizando o comando REPLACE. Este comando juntamente com
o comando CREATE til, pois caso seja feita uma modificao
na funo, podemos rodar a Listagem 10 novamente e no ser
exibido erro. Imagine a seguinte situao: a funo j existe,
caso rodssemos a Listagem 10, (sem o REPLACE) para uma
modificao, teramos um erro reportado pelo servidor, pois
seria informado que a funo j existe. Portanto, a utilizao do
CREATE OR REPLACE facilita a manuteno da funo caso seja
necessrio modific-la futuramente.
A linha 4 indica o tipo de retorno que a funo devolve. Neste
caso, o tipo de dado retornado dados_gerentes. Perceba que
dados_gerentes uma view, apresentada seo Desenvolvi-
mento da base de dados tabelas e vises.
Agora vamos para as linhas 9 e 12, onde estamos utilizando
um lao de repetio para percorrer os resultados de cada view
(dados_gerentes e dados_empregados). Esta parte da funo
a parte que exige mais processamento, pois a cada registro en-
contrado por cada uma das views a funo devolve o resultado.
A linha 18 indica o tipo de linguagem adotada, que pode ser SQL,
C ou outra linguagem procedural definida pelo usurio.

Listagem 10. Funo para apresenta dados de gerentes e empregados

1 -- Function: junta_empregados_com_gerentes()
2 -- DROP FUNCTION junta_empregados_com_gerentes();
3 CREATE OR REPLACE FUNCTION junta_empregados_com_gerentes()
4 RETURNS SETOF dados_gerentes AS
5 $BODY$
6 DECLARE
7 dados dados_gerentes;
8 BEGIN
9 FOR dados IN SELECT * FROM dados_empregados LOOP
10 RETURN NEXT dados;
11 END LOOP;
12 FOR dados IN SELECT * FROM dados_gerentes LOOP
13 RETURN NEXT dados;
14 END LOOP;
15 RETURN;
16 END;
17 $BODY$
18 LANGUAGE plpgsql VOLATILE
19 COST 100
20 ROWS 1000;
21 ALTER FUNCTION junta_empregados_com_gerentes() OWNER TO postgres;

Abaixo segue a utilizao/chamada da funo que acabamos

de criar:

SELECT * FROM junta_empregados_com_gerentes();

Vamos analisar as principais partes da funo. A linha 1 ape-

nas um comentrio para identificar o nome da funo. A linha 2

Edio 106 SQL Magazine 17

Trabalhando com herana no PostgreSQL

Na linha 19 temos o parmetro (que deve ser um inteiro po-
sitivo) que define o custo estimado de execuo para a funo
em unidades de cpu_operator_cost (ver Nota do DevMan 2).
Caso uma funo retorne um conjunto, o valor informado em
cpu_operator_cost o custo por linha retornada. Se o custo
no for especificado, 1 (uma) unidade atribuda para funes
de linguagem C, e 100 (cem) unidades para as funes em todas
as outras linguagens.
menor volume de dados. Uma amostra de 50.000 empregados
e 50.000 gerentes chega a apresentar um tamanho 25% menor
quando se utiliza herana e demais recursos aqui discutidos.
Com relao velocidade nas consultas, quando se utiliza
herana, testes preliminares demonstram que existe uma
pequena desvantagem com relao utilizao de relaciona-
mento e RIGHT JOIN, mas no chega a ser uma desvantagem
significativa.

Marcelo Josu Telles

Nota do DevMan 2
cpu_operator_cost
No PostgreSQL possvel definir uma previso de tempo necessrio que cada operao ir consumir do
processador. Em mdia, cada consulta tem um custo de 0,0025, ou seja, menos de 3 milissegundos.
Na linha 20 temos o parmetro que define a estimativa de linhas
que a funo vai devolver. Este parmetro s possvel caso a
funo retorne um conjunto de resultados. Por padro, este valor
1000. Conforme seja o tamanho do conjunto que vai ser utilizado,
podemos reduzir este nmero.
marcelojtelles@gmail.com
Graduado em Licenciatura da Computao pela Universidade
Feevale(2007), especialista em informtica na Educao pela
UFRGS(2011). Cursou disciplinas do Programa de Ps Graduao em
Computao na UFRGS (PPGC e PGMICRO), como aluno especial. Atua como
professor desde 2008. Atualmente leciona na Escola de Educao Profissional Olmpio, Escola
de Educao Bsica Feevale Escola de Aplicao, Colgio Sinodal e Instituto de Educao Ivoti.
Trabalha com desenvolvimento de software nas linguagens PHP, Java e Visual Basic.
MILANI, Andr. PostgreSQL Guia do Programador.
So Paulo: Novatec Editora, 2008.
(1) http://www.postgresql.org/docs/9.0/static/intro-whatis.html

Concluso (2) http://www.postgresql.org/

Dadas s teorias e exemplos apresentados, percebe-se que os (3) http://www.enterprisedb.com/
mesmos resultados poderiam ser obtidos sem utilizar nenhuma
(4) http://www.postgresql.org/docs/9.0/static/sql-createdatabase.html
das funcionalidades apresentadas (tipos, visualizao, herana
e funo). possvel desenvolver apenas duas tabelas com um (5) http://www.postgresql.org.br/
relacionamento 1:1 e utilizar uma consulta com RIGHT JOIN e
(6) http://www.postgresql.org/docs/9.0/static/sql-createtable.html
obter o mesmo resultado. No entanto, as vantagens em organi-
zar os dados utilizando herana e demais recursos apresentados (7) http://www.postgresql.org/docs/7.1/static/inherit.html
(tipos, visualizaes e funes) permite manipular os dados
(8) http://www.postgresql.org/docs/8.3/static/sql-createfunction.html
mais facilmente. Como outras vantagens podem perceber:
f acilidade e menor tempo para insero de uma mesma
carga de dados, visto que o relacionamento de herana no D seu feedback sobre esta edio! eu
Feedback

s
D
tem a necessidade de controle de chaves estrangeiras. Alm A SQL Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que

sobre e
disso, os dados de um gerente, por exemplo, s precisam ser voc, leitor, acha da revista!
s
ta
edio

enviados para a tabela gerentes quando se utiliza herana,

D seu voto sobre este artigo, atravs do link:
caso utilizssemos relacionamento deveramos enviar dados www.devmedia.com.br/sqlmagazine/feedback
para duas tabelas;

18 SQL Magazine Edio 106

Edio 106 SQL Magazine 19
Seo Banco de Dados/Persistncia
Nesta seo voc encontra artigos banco de dados, SQL ou persistncia
Migrao de dados
utilizando Pentaho
Data Integration
Como migrar os dados com segurana para um
novo sistema de informaes?
C
om o implemento de novas tecnologias e o au-
mento da competitividade de se esperar que
todas as organizaes passem por um processo
de evoluo em seus sistemas de informao. Indepen-
dente de ser motivada pelas deficincias do sistema atual
ou pelos ganhos que o novo sistema trar, a preocupao
em no perder informao unnime.
Existem ferramentas que movem os dados de uma
estrutura para a outra, entretanto no permitem maio-
res tratamentos, pois resumem-se a um de-para nos
tipos de dados. Entretanto, como na maioria dos casos
a mudana do Sistema Gerenciador de Banco de Dados
Relacional (SGBDR) vem aliada a uma nova verso do
sistema, esse tipo de ferramenta pouco auxilia.
normal que os sistemas tenham estruturas de dados
e regras distintas entre si e por isso o processo de migra-
o pode ser bastante trabalhoso e o risco de haver uma
restrio que impea este processo de ser executado at
o fim muito grande. Como seria impossvel encapsular
todo o processo em uma nica transao do banco de
dados, o que permitiria um rollback em caso de erro,
algumas tcnicas so fundamentais para manter a ras-
treabilidade dos dados e poder retomar o processo de
migrao de onde parou.
O incio da execuo de qualquer projeto de Tecnologia
da Informao e Comunicao (TIC) o levantamento de
requisitos e de regras de negcio. Esta etapa fundamen-
tal para delimitar o que se espera como resultado deste
trabalho e como ele ser validado e com a migrao de
dados no diferente. Abaixo apresentam-se os requi-
sitos e regras de negcio do case proposto.
20 SQL Magazine Edio 106
Resumo DevMan
De que se trata o artigo:
O artigo apresenta tcnicas fundamentais para migrao de dados e as
suas melhores prticas atravs da utilizao de ferramenta especialista
gratuita, de cdigo aberto, Pentaho Data Integration (PDI).
O case utilizado o de uma suposta fuso entre duas lojas de e-
Commerce, no qual o sistema de uma delas, armazenado em MySQL, se
tornar responsvel por gerir as informaes sendo necessria, portanto,
uma migrao de dados do SQL Server para o MySQL.
Em que situao o tema til:
Sistemas de informao tm um ciclo de vida til e, com o tempo,
tornam-se obsoletos, sendo necessria a evoluo deste. Nestes casos,
existe a preocupao de no perder informao e de melhorar a qua-
lidade dos dados armazenados. Ocorre que muitas vezes a migrao
exige que seja feita quente, ou seja, com a base Destino em operao,
e algumas tcnicas so fundamentais para garantir a integridade dos
dados e minimizar o tempo deste processo, independente dos bancos
de dados envolvidos.
Migrao de dados utilizando Pentaho Data Integration:
Processos de migrao de dados so sempre desafiadores e esto se
tornando cada vez mais necessrios.
Embasado em um case do cotidiano de um Administrador de Dados,
este artigo mostra de forma prtica solues para resolver alguns dos
problemas mais comuns em processos de migrao de dados, situaes
carentes de anlise pela doutrina especializada. So abordadas a instala-
o e a configurao do Pentaho Data Integration, assim como tcnicas
de validao, formatao e desduplicao de dados, tcnicas para
minimizar o tempo de execuo do processo de migrao e tambm para
permitir a rastreabilidade dos dados, fundamental para que o resultado
possa ser aferido de forma segura.
Requisitos e Regras de Negcio cliente com o nome da cidade em sua estrutura, ao invs do cdigo
Neste estudo de caso iremos considerar que o diretor da Magazine apontando para uma tabela de cidades.
Setorial, uma grande empresa de e-commerce, contrata os servios
de administrao de dados de uma empresa especializada e explica, Base de Dados Destino MySQL
nos itens a seguir, as caractersticas e as necessidades do projeto: Na Figura 3 apresentado o Modelo de ER da base que arma-
1. Duas grandes lojas de departamento foram fundidas e a ad- zena os dados do sistema Destino, no SGBDR gratuito MySQL.
ministrao da nova organizao ser unificada; Analisando suas tabelas extrai-se que estas j possuem dados e
2. A empresa Magazine Setorial comprou a empresa Setoria-
nas. Ambas as empresas possuem um software funcional, capaz
de gerir a organizao. Entretanto, as empresas gostariam de
unificar seu programa de fidelizao do cliente e a centralizao
destes dados fundamental;
3. O sistema da empresa Magazine Setorial foi definido como
o responsvel pela gesto a partir da fuso e vai receber todos os
dados do sistema da empresa Setorianas;
4. A estrutura de dados dos sistemas so similares, mas no
idnticos;
5. O SGBDR do sistema Origem SQL Server enquanto o do sis-
tema Destino o MySQL;
6. A migrao de dados deve ser feita sem que o sistema da em-
presa Magazine Setorial fique inoperante, pois o e-Commerce
no pode ser prejudicado;
7. O processo de migrao de dados deve prever a sua execuo
de forma parcial, para o caso do processo ser interrompido por
alguma exceo acarretada, por exemplo, por inconsistncia nos
dados ou falha na rede, permitindo a retomada de onde parou;
8. A base de dados do sistema Destino no aceita: Figura 1. Modelo de Classes resumido do Sistema Destino, em MySQL
- E-mails duplicados ou nulos para clientes;
- E-mails duplicados ou nulos para vendedores;
- Nomes duplicados ou nulos para filiais;
- Produtos com Cdigos de Barra duplicados ou nulos;
- Categoria de Produtos com nomes duplicados ou nulos.

9. Um cliente de uma empresa pode j estar cadastrado como

cliente na outra, com o mesmo e-mail.
- Deve ser possvel emitir uma listagem destes clientes pr-
existentes na base Destino.
10. O sistema Destino dever emitir relatrios de vendas por
Filial, Vendedor, Produto e Categoria do Produto, respeitando
um intervalo de datas;
11. Um Vendedor pode estar alocado somente a uma Filial;
12. Respeitando o conceito de Registro Ativo (Active Record), as
entidades tm como chave primria um cdigo de autoincremento,
a chamada chave burra;
13. necessria a rastreabilidade dos dados, para saber o que foi
migrado e qual o destino de cada informao a fim de possibilitar
conferncia; Figura 2. Modelo de ER da base Origem em SQL Server
14. Resumidamente, o modelo de classes dos dois sistemas pode
ser representado pela Figura 1. no SGBDR SQL Server 2008 R2. Analisando a base, percebe-se
que a sua estrutura simples e a desnormalizao na tabela de
Base de Dados Origem SQL Server produtos, por exemplo, facilmente identificvel, uma vez que
Na Figura 2 apresentado o Modelo de Entidade Relacionamento armazena em sua estrutura o nome, suas categoria e subcatego-
(MER ou ER) da base que armazena os dados do sistema Origem, ria. A desnormalizao tambm pode ser visualizada na tabela

Edio 106 SQL Magazine 21

Migrao de dados utilizando Pentaho Data Integration

foram criadas com a engine InnoDB, que cidade. Com isso, tem-se inicialmente que de Extract, Transform and Load (ETL veja
permite, entre outras coisas, a integrida- no ser necessrio tratamento algum ao a Nota do DevMan 1) de cdigo aberto e
de referencial. Percebe-se tambm uma migrar essa informao. desenvolvido em Java, como o Pentaho
base de dados bastante similar ao sistema Com essa anlise prvia das bases, bem Data Integration (PDI), garante que os
Origem. A tabela de produto, diferente- como dos requisitos e regras de negcio, requisitos sejam contemplados.
mente da base Origem, est normalizada, possvel mensurar com assertividade O PDI uma das ferramentas da sute
pois possui referncia para a tabela de o esforo que ser empreendido nessa Open Source de BI Pentaho e comumente
produtocategorias, que tem um autorre- migrao. chamado pelos nomes dos projetos que
lacionamento para possibilitar a criao lhe deram origem, como o Kettle. Essa
da rvore de categorias em vrios nveis. Pentaho Data Integration (Kettle) ferramenta se encaixa perfeitamente neste
Entretanto, a tabela cliente, assim como na A migrao ser realizada entre SGBDRs estudo de caso, pois pode ser utilizada em
base Origem, est redundando o nome da distintos e a utilizao de uma ferramenta qualquer plataforma, de forma gratuita,
alm de dar embasamento para a futura
montagem de Datamarts.
Nota do DevMan 1 Com a adoo do PDI, a migrao prati-
camente independe dos SGBDRs Origem
Extract, Transform and Load - ETL e Destino e permite que os dados passem
O processo de ETL dividido em trs etapas: por processos de validao, higienizao,
formatao, desduplicao, sincroniza-
Extraction (extrao): Consiste na leitura de dados a partir de uma ou mais fontes como, por exemplo, na obteno de todos os registros
adicionados ou alterados depois da ltima carga, na leitura de pginas da web, de webservices, XML, XLS, CSV, JSON, alm de formatos Big o, etc. Ele se conecta em praticamente to-
Data, como Hadoop, Cassandra, MongoDB e HBase. dos os bancos de dados, acessa webservice,
Transformation (transformao): Consiste na alterao da forma ou do contedo do dado para que se encaixe estrutura da base http, l e gera xml, json, csv, excel, etc.
Destino. A transformao ocorre, por exemplo, ao se fazer um lookup pelo nome da cidade para armazenar o seu cdigo, ao ajustar o
nome do bairro a partir do seu CEP, ao invalidar um registro por ter CPF ou e-mail invlidos, ao fazer decodificaes, renomeaes, clculos,
agregaes, etc.
Load (carga): Consiste na gravao dos dados em seu destino, independente do seu formato, que pode ser em um arquivo, em uma tabela
da base transacional, em uma dimenso ou tabela fato de um cubo ou em format Big Data.
Tutorial
A ETL uma das etapas do processo de Business Intelligence, que visa a criao de um grande armazm para os dados, da o nome em
ingls datawarehouse. Para que o processo de Business Intelligence se tornasse vivel foi necessrio o desenvolvimento de ferramentas
especialistas, capazes de executar todas as tarefas exigidas pela atividade. A adoo destas ferramentas para outros processos, como a Download, Instalao e Configurao
migrao e a sincronizao de dados entre sistemas transacionais era apenas uma questo de tempo. Hoje em dia estas ferramentas so
utilizadas para atividades como garimpagem de dados, leitura e anlise de contedo das redes sociais e bolsas de valores, envio de email
do PDI
marketing, etc. Para a realizao das atividades aqui
propostas, ser utilizado o Pentaho Data
Integration, disponvel para download
no sourceforge. Ao final deste artigo
esto disponveis os links para os arqui-
vos citados, as bases de dados e o fonte
capaz de executar toda a migrao e a
conferncia de dados migrados, com um
nico clique.
Pa ra i n ic ia r as at iv idades, faa o
download da verso mais recente do PDI
e descompacte o arquivo, disponibilizado
em formato .zip com aproximadamente
350MB, seguindo as etapas de acordo com
o seu Sistema Operacional (SO):
Para o caso do Mac, basta executar Data In-
tegration 64-bit ou Data Integration 32-bit.
Para o Linux instale o JavaRuntime En-
vironment (JRE), com o Path apontando
para a pasta $JAVA_HOME/bin. Por exem-
plo, digite no terminal ou inclua no etc/
profile export PATH=$PATH:/usr/java/
Figura 3. Modelo de ER da base Destino em MySQL jdk1.6.0_07/bin e ento execute spoon.sh.

22 SQL Magazine Edio 106

 Caso o sistema operacional seja o Windows, instale o JavaRunti-
me Environment (JRE) e configure as variveis de sistema JAVA_
HOME e Path. Para isso, acesse o Painel de Controle, Sistema e
Segurana e, por fim, Sistema. Selecione Configuraes avanadas
do sistema e na aba Avanado clique em Variveis de Ambiente.
Nas Variveis do sistema, clique em Novo e na janela Nova Vari-
vel de Sistema em Nome da varivel digite JAVA_HOME. Em
Valor da varivel aponte para a pasta JRE da sua instalao do
Java. Digite, por exemplo: C:\Program Files\Java\jre7.
Para finalizar a configurao no Windows selecione Path, ainda
em Variveis do sistema e clique em Editar..., completando o valor
de Path apontando para a pasta JRE\BIN. Digite, por exemplo,
ao final da string: ;C:\Program Files\Java\jre7\bin e execute o
arquivo Spoon.bat.
Drivers JDBC
Com o PDI j instalado e em execuo, a primeira tarefa con-
ferir se ele, em sua configurao inicial, j possui conectividade
com os SGBDRs envolvidos. Caso seja necessria a instalao do
driver, apenas salve o .jar do driver JDBC correspondente, em data-
integration\libext\JDBC e reinicie o PDI. De acordo com os bancos
envolvidos neste estudo de caso e suas respectivas verses:
Ser necessrio o .jar do MySQL:
- Por exemplo: mysql-connector-java-5.1.17.jar
No necessrio driver para o SQL Server tampouco para ler ou
gerar arquivos XLS, TXT, CSV, etc.
uma nica vez e as conexes sero compartilhadas entre todas
as transformaes. Isto d uma flexibilidade muito grande, pois
todo o processo impactado quando estes dados so alterados,
permitindo que com uma nica configurao todo o processo
aponte para uma base de dados diferente. Para isso, ser criada
uma conexo para a base Origem, em SQL Server.
Inicialmente clique no primeiro cone para criar um novo ar-
quivo, selecione Transformation (File/New/Transformation) e clique
no cone salvar. Em seguida, aponte para a pasta SQLMagazine, j
criada e crie a transformao com o nome: 1-Testa_Conexoes. Na
interface do PDI, ao lado esquerdo, tem-se a barra de Componen-
tes (steps) organizados por categorias (veja Nota do DevMan 3).
Arraste para a rea de programao do PDI o step Table input, que
fica na categoria Input, cuja finalidade buscar dados via SQL.
Com um duplo clique no step criado abra a tela de edio.
Nota do DevMan 2
Ambiente de desenvolvimento
As boas prticas de Engenharia de Software pregam que se deve trabalhar com ambientes distintos
para Desenvolvimento, Homologao e Produo. Ambiente de Desenvolvimento o que os
programadores utilizam para construir o software, onde se tem maior liberdade, para ento public-
lo no ambiente de Homologao. Este utilizado pela equipe de testes ou de negcio para verificar o
seu correto funcionamento para que, somente ento, o software seja publicado em Produo, para o
usurio final, acessando aos dados reais.

Organizao
O PDI permite armazenar todo o processo em banco de dados.
Entretanto, para isso seria necessria a criao do repositrio do
Pentaho. Neste case, utilizaremos a opo de salvar em arquivos e
para a organizao foi criada uma pasta chamada SQLMagazine
onde eles sero salvos.
Ao longo deste artigo ser criado um arquivo .ktr para cada
transformao que armazenar uma srie de steps. As flechas
(hops) que ligam os steps indicam a direo do fluxo dos dados
entre eles.
Uma transformao pode ser executada individualmente ou
fazer parte de um Job, que permite a execuo de transformaes
ou at mesmo de Jobs em sequncia, armazenados em arquivos
.kjb. Tanto os arquivos .ktr quanto os .kjb possuem o formato xml,
sem criptografia.
Uma dica importante, embora trivial, lembrar-se de antes de
iniciar os trabalhos, ter o backup das bases de trabalho. O ideal
que o processo de migrao seja criado sempre acessando bases
de desenvolvimento. Depois do processo pronto e completamente
testado, basta alterar os endereos das conexes para que apontem
para as bases de produo (veja Nota do DevMan 2) e ento exe-
cutar novamente, com a mxima segurana e performance.
Conexo Origem
Para que tenhamos acesso aos dados, existe a necessidade de que
sejam criadas as conexes com os bancos envolvidos. Isto feito
Nota do DevMan 3
Busca pelo nome do componente
O PDI possui duas abas no frame esquerdo. Na primeira, chamada View, esto todos os objetos
utilizados, enquanto na segunda, chamada Design, esto todos os componentes disponveis para
utilizao. Ambas possuem, na parte superior, um campo de busca pelo nome do componente.
Ao lado de Connection, clique em New... e preencha com os
dados de conexo da base de Origem, em SQL Server, conforme
a Figura 4.
Agora em Options, useCursorFetch, preencha com true e pressio-
ne enter. Este procedimento vai facilitar a leitura de tabelas com
grande volume de dados. Feito isso, selecione a opo Test para
se certificar que a conexo est correta e ento em OK. Clique
em Get SQL select statement e selecione com duplo clique a tabela
vendedor, conforme a Figura 5.
Neste momento voc ser questionado: Do you want to include the
field-names in the SQL? Clique em Yes para que o PDI gere a query
com os nomes das colunas ao invs do SELECT *. Em seguida cli-
que em Preview e em OK para visualizar as primeiras 1000 linhas.
Clique em Close para fechar o Preview e em Step name escreva um
nome que no deixe dvidas da sua funcionalidade, como, por
exemplo: L vendedor. Ao final, selecione a opo OK para
fechar o step e, por fim, salve o arquivo. Neste momento, temos
nossa conexo com a base de origem configurada.

Edio 106 SQL Magazine 23

Migrao de dados utilizando Pentaho Data Integration

da tabela chamada teste no banco destino, com todos os campos

do resultset. Em seguida, clique em Execute e receba a mensagem
de retorno do banco de dados, informando que a tabela foi criada
com sucesso. Agora clique em OK e feche o step.

Figura 4. Conexo para a base Origem, em SQLServer Figura 6. Criando conexo Origem, para SQLServer

Figura 5. Tabela vendedor selecionada no Database Explorer

Conexo Destino
Com a conexo para a base Origem em SQL Server j con-
figurada, realizaremos um procedimento parecido para nos
conectarmos base Destino no MySQL conforme especificaes
descritas abaixo.
Inicialmente, arraste para a rea de programao do PDI o step
Table output, que fica na categoria Output. Crie uma seta de liga-
o (hop) entre os dois steps, clicando no primeiro step, mantendo Figura 7. Conexo para a base Origem, em MySQL
pressionada a tecla shift, arraste at o step Table output, tal como se
visualiza na Figura 6. Para testar efetivamente as conexes, rode a transformao pelo
Na sequncia, com um duplo clique em Table output, que tem a menu Action, Run ou clicando no cone verde da transformao,
finalidade de persistir os dados, informe em Step name o nome com boto de Play. A tela representada na Figura 8 ser visuali-
teste. Agora clique em New..., ao lado de Connection e preencha zada, onde ser possvel configurar alguns parmetros para a sua
com os dados de conexo da base de Destino, em MySQL, con- execuo. Selecione a opo Launch.
forme Figura 7. Com isso, a primeira migrao de dados da tabela vendedor do banco
Feito isto, clique em Test para se certificar que a conexo est origem para a tabela teste do banco destino foi efetivada. Observe os
correta e ento em OK. No campo Target table escreva teste. resultados diretamente no banco de dados. Com isso foram testados
O prximo passo clicar em SQL e visualizar a DDL para a criao os drivers de conexo, encodes, grants de banco, de rede, etc.

24 SQL Magazine Edio 106

 Para que as conexes criadas possam ser
utilizadas por todas as transformaes,
no PDI, clique na aba View, Database con-
nections. Em cada uma das duas conexes
criadas, clique com o boto direito e ento
em Share.
Com as conexes criadas, pode-se pra-
ticamente abstrair quais SGBDRs esto
sendo manipulados, pois para o PDI so
apenas Data Sources. Isso porque existem
componentes que executam praticamente
as mesmas tarefas que o SQL, porm, em
algumas situaes o conhecimento deste
pode ser relevante, na medida em que
repercute em ganho de produtividade.
Outra vantagem na utilizao do PDI
poder valer-se dele para computar dados
que esto em bancos de dados distintos ou
at mesmo em arquivos, como planilhas
Excel ou CSV.
Migrando os dados
Superadas as tarefas anteriores, o am-
biente est todo configurado e pronto para
iniciar a migrao de dados. A primeira
deciso a tomar, mesmo que mentalmente,
sobre as tabelas que daro incio aos tra-
balhos. Para tanto, algumas consideraes
so necessrias, a saber:
A base Destino j possui dados, est e
ser mantida em operao 24h x 7 dias da
semana;
O desafio respeitar as regras de integri-
dade impostas na base destino, mantendo
a rastreabilidade dos dados. Nenhuma
informao pode ser perdida, sendo ne-
cessria esta comprovao;
A rastreabilidade poderia ser bidirecio-
nal ou unidirecional. No presente estudo
de caso, verificou-se que unidirecional
suficiente, ou seja, os registros da base
Origem sabero para qual registro na base
Destino foram migrados, mas na base Des-
tino os registros no tero a informao so-
bre qual registro deu origem a eles. Dessa
forma, a base Destino fica completamente
limpa, sem dados desnecessrios;
Para que isto seja possvel, todas as tabe-
las da base Origem recebero pelo menos
uma coluna com o nome idBaseDestino.
O objetivo que, ao fim do processo de
migrao, cada registro da base Origem
aponte para um registro na base Destino;
Figura 8. Tela de parametros para a execuo da transformao
Listagem 1. Queries para conferncia inicial na base Origem.
USE MagazineSetorial;
SELECT count(*) FROM dbo.cliente;
SELECT count(*) FROM dbo.notafiscal;
SELECT count(*) FROM dbo.notafiscal_produto;
SELECT sum(vlTotal) vlTotal FROM dbo.notafiscal;
SELECT sum(vlVenda * qtProduto) vlTotal FROM dbo.notafiscal_produto;
Listagem 2. Queries para conferncia inicial na base Destino.
USE Setorianas;
SELECT count(*) FROM cliente;
SELECT count(*) FROM notafiscal;
SELECT count(*) FROM notafiscal_produto;
SELECT sum(vlTotal) vlTotal FROM notafiscal;
SELECT sum(vlVenda * qtProduto) vlTotal FROM notafiscal_produto;
As tabelas pai, sem relacionamentos, base Destino deve ter o seu valor acrescido
so as melhores candidatas para darem exatamente do valor da soma de todas
incio migrao; as notas fiscais da base Origem. Para a
Depois da leitura atenta dos requisitos, conferncia neste estudo de caso, algu-
anlise das bases de dados Origem e mas queries foram executadas no incio
Destino e entendimento das validaes da migrao, conforme Listagens 1 e 2.
necessrias, a seguinte ordem foi defini- Perceba que atravs dela iremos computar
da: filial, vendedor, cliente, produtocategoria, um conjunto de variveis que ao final do
produto, notafiscal e por fim, a associativa processo sero comparadas.
notafiscal_produto.
Filial
Conferncia inicial Antes de migrar cada tabela importante
Uma boa maneira de conferir os dados lembrar quais dos Requisitos, elencados
anotar a quantidade de registros em inicialmente, devem ser contemplados e
cada tabela, tanto na Origem, como no quais regras de negcio devem ser obede-
destino. cidas. Alm disso, necessrio analisar os
Na manipulao de valores como, por seus dados e elaborar um pequeno algo-
exemplo, as notas fiscais, conveniente ritmo para orientar o desenvolvimento da
tambm computar a soma desses valores. transformao. Estas boas prticas foram
Depois de rodar todo o processo de mi- adotadas em todo este artigo e o mesmo
grao, a soma de todas as notas fiscais da formato ser seguido ao longo deste artigo,
Edio 106 SQL Magazine 25
Migrao de dados utilizando Pentaho Data Integration
por grupo de informaes: Requisitos e Regras de Negcio, Anli-
se dos dados, Algoritmo e ento um passo a passo com as devidas
orientaes para a migrao.
Para a Tabela Filial, tal como salientado nos requisitos, a base
Destino no permite nomes de filiais duplicados.
Com uma rpida anlise, percebe-se que no h duplicidade nos
dados de filiais nas bases Origem e Destino. Como so poucos
registros, facilmente se verifica tambm que as filiais da Origem
no existem no Destino, dispensando a validao.
No PDI, o componente Table output tem a opo de retornar
o id autoincremento do registro gerado. O Componente Insert/
Update, que seria conveniente neste caso, no retorna o id gerado,
por isso no ser til.
Ento, o processo deve persistir os dados das filiais na base Des-
tino, recuperar o id gerado e armazen-lo com o registro Origem,
na coluna idBaseDestino.
Para a elaborao deste filtro seguiremos alguns os passos. Ini-
cialmente, crie uma transformao e salve com o nome: 1-Filial.
Feito isso, arraste um componente Table input, d o nome de L
filial e selecione a conexo para a base Origem. Neste momento,
clique em Get SQL select statement e selecione com duplo clique a
tabela filial e ento em Yes. Em seguida, faa um Preview dos dados
e clique em OK para fechar o step. Ento, arraste o componente
Table output e crie uma seta de ligao entre os dois steps. Ser
necessrio tambm editar o step, dando o nome de Cria filial e
selecionando a conexo para a base Destino.
Na sequncia (ver Figura 9), em Target table escreva filial.
Figura 9. Table output para gravar filial
Ainda na Figura 9, marque a opo Return auto-generated key,
e informe logo abaixo idBaseDestino como nome da coluna,
em nosso result set, que vai receber o valor da chave primria
de autoincremento gerada na base Destino. Tambm nesta tela,
marque a opo Specify database fields para que, na segunda aba,
com nome Database fields, seja possvel fazer o mapeamento das
26 SQL Magazine Edio 106
colunas que recebero valor neste Insert. Selecione, em Table field
e em Stream field a coluna dsNome.
Feito isso, agora arraste o componente Update da categoria
Output e crie uma seta de ligao entre os dois steps. Edite o step,
d o nome de Update idBaseDestino e selecione a conexo para
a base Origem.
Em Target table escreva filial. Conforme se visualiza na Figura 10,
indique os campos de look up, ou seja, os campos chave. Neste caso,
Table Field e Stream field recebem id. Em Update fields, escreva
idBaseDestino em Table Field e Stream Field. Ainda na Figura 10,
a coluna idBaseDestino, referida no passo anterior, ainda no existe
no banco Origem. Para cri-la, pressione SQL. Neste passo, o PDI
pode sugerir a criao de um ndice na coluna id. Como a chave
primria e no existe a necessidade, basta apagar do script sugerido.
Clique em Execute e a mensagem de sucesso ser apresentada.
Figura 10. SQL de criao do atributo idBaseDestino, para rastreabilidade
boa prtica criar um arquivo SQL para armazenar as DDL ne-
cessrias para a rastreabilidade e conferncia dos dados, que sero
executadas na base Origem ao longo do processo. Salve o arquivo,
execute a transformao, clicando no boto de Play e acompanhe
a execuo. Feito isso, as filiais foram migradas com sucesso e
o id que receberam na base Destino est informado na coluna
idBaseDestino. Agora confira os dados em ambas as bases.
Vendedor
Seguindo a padronizao estabelecida neste artigo, apresentam-
se, na continuidade, os Requisitos e Regras de Negcio, a Anlise
dos dados, o Algoritmo e ento um passo a passo com as devidas
orientaes para efetuar a migrao dos vendedores. importante
registrar, embora implcito, que a repetio destes passos por um
administrador de dados tem como resultado um raciocnio mais
automatizado.
Como requisito da tabela vendedor, a base Destino no permite
e-mail de vendedores duplicados. Dentre as regras de negcio, o
telefone celular na base Origem um nico campo, string, com
formataes por exemplo, (11)99917-7758. Na base Destino, esta
informao deve ser gravada em dois campos numricos distintos,
um para o DDD e outro para o celular.
Com uma rpida anlise nos dados, percebe-se que no h
duplicidade nos dados nas bases Origem e Destino. Entretanto,
pode ser que algum vendedor j tenha cadastro na base Destino
com o mesmo e-mail. O processo deve possibilitar a criao de
uma lista destes Vendedores.
Este processo deve verificar se j existe um vendedor com este
e-mail na base Destino e caso ainda no exista, deve separar o
campo do telefone celular em dois campos numricos, persistir
o registro recuperando o id gerado e armazenando no registro
Origem, na coluna idBaseDestino. Caso j exista um vendedor
com este e-mail, o seu id deve ser recuperado e armazenado no
registro Origem, na coluna idBaseDestino.
Para a migrao, siga os seguintes passos:
1. Crie uma nova transformao com o nome 2-Vendedor;
2. Inclua um Table input com nome L vendedor e busque os
dados da tabela vendedor, na base Origem; Figura 11. Componente Database Value Lookup para recuperar, na base Destino, o id do
3. Inclua o componente Select values, da categoria Transform e vendedor com o mesmo e-mail que est se tentando gravar
crie uma seta de ligao entre os dois steps. Na terceira aba,
Meta-data, clique em Get fields to change e as colunas do resultset
sero apresentadas, seguida de outras informaes, como o
tipo de dado, tamanho, formato, encode. Pode-se renomear as
colunas e alterar algum parmetro ou simplesmente utilizar
este step para organizar a casa e ter a viso dos tipos de dados
envolvidos;
4. Inclua o componente Database Lookup da categoria Lookup,
chame-o de busca idBaseDestino e faa a ligao com o step
anterior, conforme Figura 11. Ele tem a finalidade de verificar se
um registro j existe, informando a tabela, os campos chave para
a busca e os campos a serem retornados. Neste caso, ser utilizado
para verificar se j existe um vendedor cadastrado na base Destino
com o e-mail informado. Selecione a conexo Destino e em Lookup
table escreva o nome da tabela vendedor ou clique em Browse e Figura 12. SQL de criao do atributo idBaseDestino e bJaExistiaNoDestino para rastreabilidade
a selecione com duplo clique;
5. Para melhorar a performance, marque Enable Cache e Load all
data from table. Nos campos de Lookup, selecione dsEmail tanto em
Table field como em Field1 e em Comparator o sinal =;
6. Nos valores a serem retornados selecione o campo id e o novo
nome para ele idBaseDestino do tipo Integer;
7. Inclua o componente Filter rows, da categoria Flow e chame-o de
Criar Registro?. Este o componente do famoso if! estipulada Figura 13. Para criar os campos separados para DDD e Celular, o Step String Cut
uma condio e qual a direo do fluxo para o caso de o resultado
dela ser verdadeira e falsa. Nas condies, selecione o campo
idBaseDestino e is null. Clique em OK e feche o step;
8. Como um dos requisitos gerar uma lista dos vendedores que
j estavam cadastrados na base Destino, no basta simplesmente
atualizar o campo idBaseDestino, sendo necessrio incluir um flag
para marcar os pr-existentes. Inclua o componente Add Constants,
crie a constante bJaExistiaNoDestino, selecione o tipo Boolean e
escreva o valor True; Figura 14. Mapeamento dos campos a serem persistidos em vendedor

Edio 106 SQL Magazine 27

Migrao de dados utilizando Pentaho Data Integration
9. Faa a ligao do step Criar Registro? para este step, informando
que para ser executado no caso de Result is FALSE;
10. Inclua o componente Update este fluxo, chame-o de Update
idBaseDestino e aponte para a tabela vendedor da base Origem e
configure para que o id do vendedor encontrado com mesmo e-mail
seja gravado na coluna idBaseDestino, da mesma forma utilizada
com a filial. Inclua, alm disso, o campo bJaExistiaNoDestino para
ser atualizado. Como o registro que est sendo atualizado o
mesmo da query inicial, tem-se a certeza de que o registro existe.
Assim, podemos marcar o Skip lookup para ganhar em perfor-
mance;
11. Agora crie os campos idBaseDestino, bJaExistiaNoDestino clican-
do em SQL, conforme Figura 12. Perceba que tipos booleanos so
criados como char(1) e recebero como seus valores Y ou N; Destino, pois 10 deles j existiam com o mesmo e-mail, conforme
12. Feito isso, os steps para a condio verdadeira sero criados,
ou seja, o registro de Vendedor. Inclua o step Calculator e faa a
ligao dele com o step Criar Registro?, informando que para ser
executado no caso de Result is TRUE. Como o prprio nome diz,
este step utilizado para fazer clculos e criar novas colunas no
resultset. Neste estudo de caso, ser utilizado para retirar da string
do telefone tudo o que no for numrico. Para isso, em new field
escreva dsCelularSomenteNumeros; em Calculation selecione
dentre as diversas funes disponveis Return only digits from
string A; em field A selecione dsCelular e, finalmente, em Value
Type selecione String.
13. Para obter os campos para o celular, inclua, conforme Figura 13,
o step String Cut ao fluxo;
14. Para incluir o vendedor, inclua ao fluxo o step Table output,
apontando para a tabela vendedor da base Destino, marque Return
auto-generated key e informe idBaseDestinoCRIADO como nome
para esta informao. Marque Specify database fields e, na segunda
aba, clique em Get fields para que o PDI busque todos os valores
e ento em Enter field mapping para que graficamente sejam se-
Figura 15. Resultado da execuao da transformaao 2-Vendedor
28 SQL Magazine Edio 106
lecionados os campos a serem includos. Conforme Figura 14, a
coluna id foi excluda deste mapeamento, pois na base Destino o
registro receber um valor automaticamente. Confirme e feche o
step;
15. Aps estas etapas, deve-se, por fim, gravar na base Origem o
id gerado para os vendedores, informando que no existia na base
Destino. Copie e cole o step criado no Passo 8 e altere o valor do
booleano para False, ligando-o ao fluxo;
16. Copie e cole o step criado no Passo 10, ligando-o ao fluxo e
em Update fields, Stream field, troque de idBaseDestino para idBase
DestinoCRIADO;
17. Execute a transformao e verifique no resultado que dos 60
vendedores da base Origem, somente 50 foram includos na base
a Figura 15;
Por fim, verifique os dados em ambas as bases e certifique-se de
ter salvo a transformao que acabamos de desenvolver.
Cliente
Seguindo a padronizao adotada neste artigo, os Requisitos e
Regras de Negcio, a Anlise dos dados, o Algoritmo e ento um
passo a passo com as devidas orientaes para a migrao dos
clientes so apresentados a partir de agora.
Para a tabela cliente como requisito deste case, tm-se que a
base Destino no permite duplicidade nos e-mails de clientes.
Por outro lado, a regra de negcio para esta tabela refere-se ao
telefone celular, que na base Origem um nico campo string, com
formataes como (11)99917-7758. Entretanto, na base Destino,
esta informao deve ser gravada em dois campos numricos
distintos, um para o DDD e outro para o celular.
Considerando que o volume de dados significativo, impres-
cindvel conferir a qualidade destes via SQL, na base Origem,
para verificao de eventual duplicidade de e-mail,
conforme a Listagem 3.
Concluiu-se que h vrios clientes cadastrados
com o e-mail em duplicidade. Tal como ocorreu com
a migrao dos vendedores, os clientes podem j
possuir cadastro na base Destino, razo pela qual,
o processo deve permitir a criao uma lista destes
clientes.
Listagem 3. Query para verificao da existncia de e-mail em
duplicidade na base Origem.
SELECT dsEmail, count(*)
FROM dbo.cliente
GROUP BY dsEmail
HAVING count(*) > 1
ORDER BY count(*) DESC, dsEmail;
Este processo deve ler todos os vendedores e eliminar
as duplicidades de e-mail no resultset para ento veri-
ficar se j existe um vendedor com este e-mail na base
Destino e, caso ainda no exista, separar o campo do telefone celular
em dois campos numricos e persistir o registro, recuperando o id
gerado e armazenado no registro Origem, na coluna idBaseDestino.
Caso j exista um cliente com este e-mail, o seu id deve ser recuperado
e armazenado no registro Origem, na coluna idBaseDestino.
Para a migrao destes dados, siga os passos abaixo:
1. Salve a transformao do item anterior com o novo nome
3-Cliente;
2. Edite o primeiro step e aponte para a tabela cliente da base
Origem, trazendo todos os seus campos;
3. Edite o step Selelect values, clique em Get fields to change e depois Figura 16. Ordenando o resultset pelo campo dsEmail, descartando os duplicados
em Clear and add all. No campo dtNascimento, selecione em Type e
a opo Date; agilizar em muito o processo de lookup na gravao dos dados
4. Inclua ao fluxo o step Sort Rows, selecione a coluna dsEmail na base Origem (ver Figura 17).
e marque Only pass unique rows, como se v na Figura 16. Este 6. Edite o step Update idBaseDestino e em Target table, troque de
componente l e ordena todo o resultset pelas colunas informadas, vendedor para cliente. Nos campos de lookup, troque id por dsEmail,
na ordem desejada (ascendente ou descendente). Com esta opo tanto em Table field quanto em Stream field, conforme Figura 18.
marcada apenas um cliente por e-mail continuar no resultset e Perceba que a coluna utilizada como chave neste lookup, que em
os duplicados sero completamente desconsiderados; uma query SQL de Update corresponderia clusula Where, foi o
5. Agora edite o step busca idBaseDestino e em Lookup table, troque e-mail. Isto importante, pois no step Sort rows com a opo de
de vendedor para cliente. Diante do volume considervel de dados, eliminar os duplicados marcado, somente existir um registro por
desmarque a opo Load all data from table. Para criar os campos e-mail no resultset e fazer o Update pelo e-mail ao invs de pelo
de rastreabilidade, clique em SQL e ento em Execute. Perceba que id do registro fundamental para atualizar todos os vendedores
o PDI sugeriu a criao de um ndice na coluna dsEmail, o qual com este e-mail.

Edio 106 SQL Magazine 29

Migrao de dados utilizando Pentaho Data Integration
Outro detalhe interessante de ser comentado que neste estudo
de caso a unicidade do cliente feita por e-mail, mas poderia ser
por CPF.
7. Edite o step Criar vendedor e chame-o de Criar cliente. Em Target
table, troque de vendedor para cliente. Na aba Database fields, clique
em Get fields, Clear and add all e ento em Field mapping, tal como
realizado nos casos anteriores, excluindo a coluna id, conforme
a Figura 19;
8. Edite o ltimo step, Update idBaseDestinoCRIADO e, em Target
table, troque de vendedor para cliente;
Figura 17. DDLs para novos atributos em cliente
Figura 18. Update cliente pr-existente
Figura 19. Mapeamento para persitir cliente
30 SQL Magazine Edio 106
9. Por fim, execute a transformao e verifique a quantidade de
clientes criados e de pr-existentes. Observe tambm a velocidade
(nmero de registros includos por segundo) obtida, conforme
pode ser visualizado na Figura 20. Caso acontea qualquer tipo de
erro e o processo tenha sido interrompido, para se evitar a leitura
de um registro j migrado, edite o primeiro step, incluindo ao final
da query a instruo where idBaseDestino is null.
Por fim, verifique os dados em ambas as bases e certifique-se de
ter salvo a transformao que acabamos de desenvolver.
Figura 20. Resultados da execuo da transformao 3-Cliente
Categoria de Produto
Partiremos agora para a migrao da categoria produto. Como
requisito da categoria de produto, a base Destino no permite
nomes duplicados. A base Origem no possui tabela para esta
informao, entretanto possui na tabela produto tais dados de
forma desnormalizada em duas colunas descritivas: dsCategoria
e dsSubcategoria.
Alm disso, importante estar atento ao fato de que na base
Destino, a estrutura produtocategoria possui um autorrelaciona-
mento para que uma rvore com vrios nveis seja possvel.
As categorias de produto podem j existir na base Destino
com o mesmo nome. O processo deve permitir que uma lista
destas categorias de produto seja gerada.
Este processo deve ler todos os produtos, eliminar as duplicida-
des de dsCategoria no resultset para ento verificar se j existe
uma categoria de produto com este nome na base Destino e, caso
ainda no exista, persistir o registro, recuperando o id gerado e
armazenado no registro Origem, na coluna idBaseDestino. Caso
j exista uma categoria de produto com este nome, o seu id deve
ser recuperado e armazenado no registro Origem, na coluna id-
BaseDestinoCategoria.
Para a migrao destes dados, siga os passos abaixo:
1. Salve a transformao do item anterior 3-Cliente com o novo
nome 4-Produtocategoria;
2. Edite o primeiro step e aponte para a tabela produto da base
Origem, trazendo todos os seus campos;
3. Edite o step Selelect values e atualize a lista de campos;
4. Em Sort rows, selecione dsCategoria e
marque para no trazer duplicados;
5. Edite o step de Database lookup e verifique
se j existe uma categoria cadastrada com
este nome, conforme exemplificado na
Figura 21;
6. Em seguida edite o step Update idBase-
Destino, alterando o nome para Update
idBaseDestinoCategoria. A tabela produto
da base Destino dar origem aos dados de
Categoria, Subcategoria e Produto e cada
um desses conceitos receber duas colunas
para a rastreabilidade. Neste caso, sero
criadas as colunas idBaseDestinoCate-
goria e bJaExistiaNoDestinoCategoria.
Faa o lookup pela coluna dsCategoria e
crie os novos campos, clicando em SQL,
conforme a Figura 22;
7. Em seguida, editando o outro lado do
fluxo da ETL, apague os 2 steps que tra-
tavam do telefone do cliente. Edite o Criar
cliente, alterando para Criar categoria.
Nos campos a serem inseridos, em Table
field, selecione dsNome. Em Stream field,
dsCategoria;
8. Edite o step Update idBaseDestino
CRIADO, alterando os nomes das colunas,
conforme a Figura 23;
Feito isso, execute a transformao,
salvando-a. Figura 21. Lookup para recuperar, na base Destino, o id da categoria de produto com o mesmo nome que est se tentando gravar

Edio 106 SQL Magazine 31

Migrao de dados utilizando Pentaho Data Integration

Outras informaes, mesmas tcnicas
A migrao das demais informaes que completam este
processo, como subcategoria de produto, produto, notafiscal e
notafiscal_produto se utilizam das mesmas tcnicas vistas nos
passos anteriores e poder ser visualizada, na ntegra, nos fontes
disponibilizados no portal da SQL Magazine.
Vale salientar que as procedimentos adotados at aqui
sero comuns em diferentes migraes de dados e sero a
Na continuidade, deveremos verificar se o montante total das
notas fiscais no Destino sofreu o acrscimo do mesmo valor
do total das notas fiscais na Origem. Para isso, as queries das
Listagens 4 e 5 sero utilizadas.
Listagem 4. Queries para conferncia final na base Origem.
USE MagazineSetorial;

base para, com pequenas adaptaes, migrar outros dados -- a quantidade de registros que no
com segurana, contemplando os requisitos e respeitando as -- tm um correspondente no Destino
regras de negcio. SELECT count(*)
FROM dbo.cliente
WHERE idBaseDestino IS NOT NULL;

SELECT count(*)
FROM dbo.notafiscal
WHERE idBaseDestino IS NOT NULL;

SELECT count(*)
FROM dbo.notafiscal_produto
WHERE idBaseDestino IS NOT NULL;

-- Soma dos valores migrados

SELECT sum(vlTotal) vlTotal
FROM dbo.notafiscal
WHERE idBaseDestino IS NOT NULL;

SELECT sum(vlVenda * qtProduto) vlTotal

FROM dbo.notafiscal_produto
WHERE idBaseDestino IS NOT NULL;

Listagem 5. Queries para conferncia final na base Destino

Figura 22. DDLs para a criao dos atributos de rastreabilidade em produto
USE Setorianas;
-- Verifica-se, comparado com os valores da conferncia
-- inicial com estes, se o crescimento na base Destino foi -- exatamente igual aos
-- valores da base Origem
SELECT count(*) FROM cliente;
SELECT count(*) FROM notafiscal;
SELECT count(*) FROM notafiscal_produto;
SELECT sum(vlTotal) vlTotal FROM notafiscal;
SELECT sum(vlVenda * qtProduto) vlTotal FROM notafiscal_produto;

Migrao de dados em um clique

Aps a migrao ter seus resultados aferidos, a prxima tarefa
ser alterar os parmetros das conexes e executar todo o processo
em produo. Para que o tempo gasto na execuo do processo
seja o menor possvel, a criao de um Job, como o da Figura 24,
conveniente (veja a Nota do DevMan 4). Lembre-se de executar
o arquivo SQL com as DDLs para as colunas de rastreabilidade na
base Origem antes de executar o Job em ambiente de produo.

Figura 23. Gravando na base Origem o id gerado pela base Destino

Nota do DevMan 4
Conferncia final
Para concluir o trabalho com chave de ouro, necessrio provar Executando Jobs e Transformaes
que tudo ocorreu 100% como previsto e nenhuma informao foi Os Jobs, bem como as transformaes, tambm podem ser chamados atravs de linha de comando,
perdida. via web ou ainda executadas automaticamente em horrio e periodicidade configurveis, atravs de
um BI-Server.
A primeira conferncia que se faz necessria se todos os
registros da Origem possuem um correspondente no Destino.

32 SQL Magazine Edio 106

 Em inmeras situaes, mesmo
utilizando-se das melhores prticas, a
performance do processo de migrao
pode ficar prejudicada em razo da
topologia de redes, quando os ban-
cos so acessados de forma remota.
Diante disso, a utilizao de uma
ferramenta de ETL de cdigo aberto,
gratuita e desenvolvida em Java, como
o PDI, permite, por exemplo, a sua
instalao em uma mquina virtual,
em qualquer Sistema Operacional
(SO), dentro da infraestrutura onde
esto os bancos de dados envolvidos.
Dessa forma, o acesso aos dados pode
ser feito de maneira local, enquanto
o acesso seria remoto apenas para
esta mquina virtual onde est o PDI
instalado espera do disparo do Job,
que executar o processo com a per-
formance maximizada.
Feito isso, tm-se conhecimento
suficiente para encarar a tarefa da Figura 24. Job com toda a migrao de dados para ser executada com um nico clique
migrao de dados.

Concluso Download Pentaho Data Integration Kettle

Ao final deste artigo resta deixar claro que o auxlio de uma http://sourceforge.net/projects/pentaho/files/Data%20Integration/4.3.0-
poderosa ferramenta, como o caso do PDI, bem como a adoo stable/pdi-ce-4.3.0-stable.zip/download
das melhores prticas no dispensa o olhar tcnico de um profis-
sional da rea, pois ser ele quem tomar a deciso, analisando os Download Java JRE
dados sobre a necessidade de determinada validao, assim como http://www.java.com/pt_BR/download/
verificar se os resultados obtidos ao trmino do trabalho foram
realmente os esperados. As inmeras ferramentas existentes no Download Driver JDBC para Mysql
mercado, sem dvida, minimizam o trabalho e automatizam a http://dev.mysql.com/downloads/connector/j/
sua execuo, porm no fazem mgica.
Inegavelmente o PDI, uma das ferramentas mais poderosas da The 38 Subsystems of ETL - Ralph Kimball
sute open source Pentaho de Business Intelligence, executa a ta- http://www.informationweek.com/software/business-intelligence/the-38-
refa com maestria e traz muitos ganhos com a sua adoo. Aliado subsystems-of-etl/54200319
s tcnicas e boas prticas descritas neste artigo, ser possvel
executar migraes de dados, mesmo entre SGBDRs distintos ou Wiki oficial do Pentaho Data Integration Kettle
distantes, com total segurana e assertividade. http://wiki.pentaho.com/display/EAI/Latest+Pentaho+Data+Integration+%28
aka+Kettle%29+Documentation
Eduardo Alves de Carvalho
eduardo@e-Setorial.com.br
Especializado em Administrao de Dados e Business Intelligence,
consultor e scio da e-Setorial Consultorias. Atua h 20 anos com D seu feedback sobre esta edio! eu
Feedback
s
D

sistemas de alta disponibilidade, j atuou em instituies como PUC-PR, A SQL Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que
sobre e

Esfera Informtica, Badesc, Gennera, Cetil e Knowtec. Atualmente voc, leitor, acha da revista!
s

ta
edio

responsvel pela Administrao de Dados e Business Intelligence no Instituto de Estudos

Avanados (IEA). Atua com a suite Pentaho h 5 anos. Site: www.e-Setorial.com.br LinkedIn: D seu voto sobre este artigo, atravs do link:
www.br.linkedin.com/in/eduardocarvalhodba. www.devmedia.com.br/sqlmagazine/feedback

Edio 106 SQL Magazine 33

Seo Banco de Dados/Persistncia
Nesta seo voc encontra artigos banco de dados, SQL ou persistncia
Particionamento de
dados no SQL Server
M
onitorar, propor e implementar solues
para melhoria do ambiente funo do DBA.
Desde a verso 2005 do SQL Server (Verso
Enterprise) disponibilizada a funcionalidade de par-
ticionamento de dados. Esta facilita o gerenciamento
de dados que so inseridos atravs de sistemas OLTP e
tambm dados que podem ser utilizados para emisso
de relatrios gerenciais e sistema OLAP. O particiona-
mento de dados melhora o desempenho e simplifica a
manuteno. Quando uma tabela grande particionada,
ao se executar uma consulta, blocos menores dos dados
so lidos, fazendo com que as informaes sejam retor-
nadas de forma mais rpida.
Quando no utilizado o particionamento de dados
no SQL Server, pode-se armazenar uma tabela dentro
de um filegroup apenas, e este filegroup pode conter
vrios arquivos em vrios discos, porm voc como DBA
no consegue determinar em qual destes arquivos ou
em qual dos discos voc ir armazenar uma parte dos
dados. Ao particionar uma tabela no banco de dados,
pode-se realizar um dimensionamento fsico dos dados,
ou seja, em um ambiente onde se tem mais que um disco
para se armazenar os dados e um deles mais lento,
pode-se escolher armazenar os dados que so utilizados
para emisso de relatrios ou armazenamento de dados
histricos (possivelmente dados referentes a notas ficais
de uma empresa que precisam ficar arquivados durante
pelos cinco anos) no disco mais lento e no disco com
maior velocidade os dados atuais.
O particionamento dos dados feito com base em um
atributo, ou seja, um campo da tabela no momento da
insero ser verificado e, com isso, o engine do SQL
Server saber para qual filegroup dever encaminhar
o registro. Alm da tabela, o particionamento tambm
pode ser utilizado em um ndice ou view indexada,
e funcionam da mesma forma como explicado para a
tabela. Quando um ndice estiver utilizando a mesma
regra de particionamento da tabela, dizemos que a tabela
est alinhada, ou seja, os dados da tabela e ndice so
armazenados no mesmo filegroup.
Para criar uma tabela, ndice ou view indexada, uma
funo de partio e esquema de partio devem ser
criados no banco de dados. A funo de partio um
objeto independente no banco de dados que pode ser
34 SQL Magazine Edio 106
Resumo DevMan
De que se trata o artigo:
Particionamento de dados o recurso no qual o administrador de
banco de dados poder ter o domnio dos locais onde seus dados so
armazenados. Atualmente, no utilizando esta funcionalidade, podemos
determinar em qual diretrio ou diretrios nossos arquivos de filegroup
ficaro armazenados, porm no caso de vrios filegroups no temos a
certeza de qual lugar seu registro realmente est. Com o particionamento
dos dados, podemos ter um gerenciamento melhor dos dados, ganhando
em performance e tambm acompanhando em que partio/filegroup
o registro est alocado.
Em que situao o tema til:
As informaes contidas neste artigo podem ser aplicadas em am-
bientes de banco de dados de qualquer porte, fazendo com que o
gerenciamento dos dados seja melhorado. "Espalhando" os dados em
diferentes discos no servidor, o banco de dados visa melhorar o desem-
penho das leituras, facilitando assim a busca por resultados, onde ao
invs de consultar toda a massa de dados, faz-se apenas a consulta em
uma parte da mesma.
Particionamento de dados no SQL Server:
Este artigo introduz o conceito de particionamento de dados no banco
de dados SQL Server, podendo ser aplicado a partir da verso 2005 verso
Enterprise. Ao longo do artigo sero abordados o conceito de filegroup,
funes de partio e esquemas de partio, que so os primeiros passos
para criar uma tabela particionada. Sero mostrados tambm os meios de
gerenciamento do particionamento de dados, onde poder se incluir e
excluir intervalos de particionamento e transferir dados de parties entre
tabelas utilizando o menor esforo administrativo possvel.
reaproveitado em mais de um particionamento e que estabelece
os limites (intervalo) dos dados a serem inseridos nas tabelas.
O esquema de partio um objeto no banco de dados que
relacionado diretamente com a funo de partio, onde faz o
apontamento do intervalo com o filegroup ao qual os dados devem
ser armazenados e tambm declarado no momento da criao
da tabela, ndice ou view indexada.
Aps a tabela ser criada e os dados serem includos em todas as
parties, surgem necessidades de administrao destas parties,
sejam por motivos de se fazer ajustes no intervalo da funo de
partio, alteraes dos filegroups ou at mesmo enviar uma par-
tio inteira para uma outra tabela ou outra partio. Para estes
casos existem os operadores SPLIT, MERGE e SWITCH.
Tutorial
Funes de partio e esquemas de partio
Para que os dados sejam particionados dentro de um banco de
dados de dados SQL Server, necessrio que tenhamos criado uma
funo de partio e um esquema de partio. As prximas sees
mostraro como criar uma funo de partio e um esquema de
partio para particionar uma tabela.
Funes de partio
Assim como apresentado no resumo, a funo de partio
um objeto independente criado no banco de dados que faz o
mapeamento dos dados de uma tabela, ndice ou view indexada,
informando qual o intervalo de valores que sero armazenados em
cada um dos particionamentos. Intervalo este que ser relacionado
mais adiante com o esquema de partio, apontando assim em
qual filegroup dever ser armazenado (ler Nota do DevMan 1).
Nota do DevMan 1
Funo de partio
A funo de partio um objeto independente no banco de dados, ou seja, ele no est vinculado a
uma tabela, ndice ou view indexada em especfico, podendo ser reaproveitado em diversas tabelas
ou ndices no banco de dados.
A sintaxe para criar uma funo de partio atravs do co-
mando CREATE PARTITION FUNCTION, como apresentada na
Listagem 1.
Listagem 1. Sintaxe completa do comando CREATE PARTITION FUNCTION
CREATE PARTITION FUNCTION partition_function_name ( input_parameter_type )
AS RANGE [ LEFT | RIGHT ]
FOR VALUES ( [ boundary_value [ ,...n ] ] )
[;]
Nesta funo temos que:
CREATE PARTITION FUNCTON: Identifica ao SQL Server que
estamos criando uma funo de partio de dados;
partition_function_name: Deve ser especificado o nome para a
funo de partio;
( input_parameter_type ): Deve ser informado o tipo de dados
da coluna que ser utilizada para particionar a tabela. Aqui no
so aceitos os tipos de dados text, ntext, image, xml, timestamp,
varchar(max), nvarchar(max), varbinary(max) e tipos de dados
CLR (Common Language Runtime) definidos pelo usurio;
AS RANGE [ LEFT | RIGHT ]: Este parmetro definir como a
funo de partio ir tratar os pontos limite, ou seja, se o atributo
RANGE for configurado como LEFT, estamos considerando que
o ponto limite ser feito na partio da esquerda e caso o atributo
seja configurado como RIGHT, o ponto limite ser feito na partio
da direita.
([boundary_value)]: Neste atributo iremos especificar os inter-
valos do particionamento da tabela ou ndice.
Para que possamos dar seguimento criao do particionamento
de uma tabela no banco de dados, o conceito de LEFT e RIGHT
apresentado no comando de criao da funo de partio precisa
estar bem claro, caso contrrio, pode-se causar inmeras confu-
ses nos intervalos criados. Vamos imaginar a seguinte situao:
deve-se particionar a tabela PEDIDOS baseando-se em um
campo chamado dt_ped que do tipo DATE, no qual o intervalo
os dados que no sejam do ano de 2012 fiquem em uma partio
separada, pois se tratam de dados histricos que so utilizados
em relatrios gerenciais pouco utilizados. Os dados do ano de
2012 devem ser armazenados em parties diferentes com base
no ms. Desta forma, pode-se configurar a funo de partio
como LEFT ou como RIGHT.
A Listagem 2 mostra como realizar a criao das funes de
partio considerando o RANGE LEFT. O resultado desta funo
para um conjunto fictcio de dados pode ser observado na Tabela 1
(que apresenta os pontos limites considerados para a opo
RANGE LEFT).
J a Listagem 3 mostra como realizar a criao das funes
de partio considerando o RANGE RIGHT. O resultado desta
funo para um conjunto fictcio de dados pode ser observado
na Tabela 2 (que apresenta os pontos limites considerados para
a opo RANGE RIGHT).
Listagem 2. Criando a funo de partio particao_range_left
CREATE PARTITION FUNCTION
particao_range_left (date)
AS RANGE LEFT
FOR VALUES (2012-01-01, 2012-02-01, 2012-03-01, 2012-04-01, 2012-05-01,
2012-06-01, 2012-07-01, 2012-08-01, 2012-09-01, 2012-10-01, 2012-11-01,
2012-12-01)
GO
Listagem 3. Criando a funo de partio particao_range_right
CREATE PARTITION FUNCTION
particao_range_right (date)
AS RANGE RIGHT
FOR VALUES (2012-01-01, 2012-02-01, 2012-03-01, 2012-04-01, 2012-05-01,
2012-06-01, 2012-07-01, 2012-08-01, 2012-09-01, 2012-10-01, 2012-11-01,
2012-12-01)
GO
Edio 106 SQL Magazine 35
Particionamento de dados no SQL Server

Partio Filegroup Valor mnimo Valor mximo Para que se possa criar um esquema de partio, utiliza-se o co-
1 FG1 - 01/01/2012 mando CREATE PARTITION SCHEME, conforme Listagem 4.
2 FG2 02/01/2012 01/02/2012 Neste comando temos que:
3 FG3 02/02/2012 01/03/2012
CREATE PARTITION SCHEME: Determina que est sendo
criado um esquema de partio;
4 FG4 02/03/2012 01/04/2012
Partition_scheme_name: Especifica o nome do esquema de
5 FG5 02/04/2012 01/05/2012
partio a ser criado;
6 FG6 02/05/2012 01/06/2012 AS PARTITION partition_function_name: Neste parmetro ser
7 FG7 02/06/2012 01/07/2012 apontada a funo de partio no qual o esquema de partio ir
8 FG8 02/07/2012 01/08/2012 ser relacionado;
9 FG9 02/08/2012 01/09/2012 [ALL]: Caso o parmetro seja especificado, apenas um filegroup
poder ser especificado no parmetro TO file_group_name (mos-
10 FG10 02/09/2012 01/10/2012
trado a seguir);
11 FG11 02/10/2012 01/11/2012
TO ({file)_gripo_name | [PRIMARY]} [ ,...n]): Neste parmetro
12 FG12 02/11/2012 01/12/2012 dever ser especificado o filegroup onde cada um dos intervalos
13 FG13 02/12/2012 + sero armazenados. Caso PRIMARY seja especificado, todos os
intervalos sero armazenados no filegroup principal do banco de
Tabela 1. Funo de partio com RANGE LEFT
dados.

Partio Filegroup Valor mnimo Valor mximo

O cdigo apresentado na Listagem 5 mostra a criao do esque-
1 FG1 - 31/12/2011
ma de partio chamado esquema_date. Neste esquema estamos
2 FG2 01/01/2012 31/01/2012 definindo os 13 filegroups que recebero os dados particionados
3 FG3 01/02/2012 29/02/2012 de nossa tabela.
4 FG4 01/03/2012 31/03/2012
5 FG5 01/04/2012 30/04/2012
Listagem 4. Sintaxe completa do comando CREATE PARTITION SCHEME
6 FG6 01/05/2012 31/05/2012
7 FG7 01/06/2012 30/06/2012 CREATE PARTITION SCHEME partition_scheme_name
8 FG8 01/07/2012 31/07/2012 AS PARTITION partition_function_name
[ ALL ] TO ( { file_group_name | [ PRIMARY ] } [ ,...n ] )
9 FG9 01/08/2012 31/08/2012
[;]
10 FG10 01/09/2012 30/09/2012
Listagem 5. Criando o esquema de partio esquema_date
11 FG11 01/10/2012 31/10/2012
12 FG12 01/11/2012 30/11/2012 CREATE PARTITION SCHEME esquema_date
13 FG13 01/12/2012 + AS PARTITION particao_range_right
TO (FG1, FG2, FG3, FG4, FG5, FG6, FG7, FG8, FG9, FG10,FG11,FG12,FG13)
Tabela 2. Funo de partio com RANGE RIGHT GO

Esquemas de partio Consultando funes de partio e esquemas de partio

Aps ser criada a funo de partio, o prximo passo para o
particionamento dos dados a criao de um esquema de partio.
Este dever fazer o relacionamento entre o intervalo e o filegroup
ao qual receber os dados. O esquema de partio includo na
clausula CREATE.
Os filegroups (ou filegroup) que so declarados no comando
de criao de um esquema de partio (que ser visto a seguir)
devero j estar criados previamente no banco de dados, caso
contrrio o comando ir falhar. A quantidade de filegroups es-
pecificada no esquema de partio tambm dever corresponder
ao nmero de intervalos especificados na funo de partio
mais um, pois conforme exemplificado na criao da funo de
partio anteriormente, o intervalo foi de 12 meses, porm as
Tabelas 1 e 2 mostram treze intervalos.
Para validar se realmente a partio foi criada com sucesso, exis-
tem algumas maneiras de se consultar os metadados (atravs das
tabelas sys) e tambm via SQL Server Management Studio.
A seguir seguem as tabelas que podem ser utilizadas para con-
sultar os metadados referentes s parties, funes de partio
e esquemas de partio:
sys.partitions: Esta tabela de sistema alm de armazenar as ta-
belas particionadas, tambm armazena todas as tabelas e ndices
do banco de dados, pois para o SQL Server, cada tabela e ndice
que no particionada tem por padro um particionamento;
sys.partition_functions: Esta tabela contm uma linha para cada
funo de partio.
sys.partition_schemes: Esta tabela contm uma linha para es-
quema de partio;

36 SQL Magazine Edio 106

 sys.partition_range_values: Contm uma linha para cada um
dos intervalos especificados na criao da funo de partio;
sys.partition_parameters: Contm uma linha para cada par-
metro especificado em uma funo de partio.
Alm das tabelas de sistema, tambm possvel consultar as
funes de partio e esquemas de partio atravs do SQL Server
Management Studio (SSMS). Para isso, basta expandir o banco de
uma coluna que no est participando do ndice. No exemplo
da Listagem 7 ser criado o ndice ix_id_ped_id_cli, onde ser
utilizado o esquema de partio esquema_date, da mesma forma
como foi utilizado na criao da tabela. Fazendo desta forma,
dizemos que a tabela e ndice esto alinhados.
Listagem 7. Criando o ndice particionado ix_id_ped_id_cli

dados ao qual teve a tabela ou ndice particionados, expandir a

CREATE INDEX ix_id_ped_id_cli ON pedidos(id_ped,id_cli) ON esquema_date
opo STORAGE e depois ter os nomes Partition Schemes e
(dta_ped)
Partition Functions (ver Figura 1). GO

Inserindo dados e consultando parties

Aps a tabela ser criada e os dados comearem a serem inseridos,
devemos investigar se realmente os dados esto indo para os file-
groups corretos. Utilizando a funo $Partition juntamente com o
nome da funo de partio e passando o registro contido na tabela,
o resultado ser o nmero da partio. Pode-se tambm utilizar a
funo $Partition.nome_funcao_particao(tipo de dados) somente
para visualizar em qual partio o registro ser inserido.
Observe a Figura 2. Nela foram includas duas linhas na tabela
pedidos, onde cada uma deveria ir para um filegroup diferente.
Aps isso, foi utilizado o comando SELECT para verificar se
realmente o local de armazenamento estava correto.
Figura 1. Object Explorer do SQL Server Management Studio

Particionando tabelas e ndices

Com a funo de partio e o esquema de partio criado, o
prximo passo para iniciar o particionamento dos dados criar
a tabela. Nesta seo ser analisado o processo de criao de uma
tabela particionada.
Para criar uma tabela particionada deve-se acrescentar clusula
ON o nome do esquema de partio e o campo que ser tomado
como base para a distribuio dos dados nos filegroups especifi-
cados no esquema de partio. A Listagem 6 mostra o script de
criao da tabela PEDIDOS, onde os dados sero distribudos com
base na data da venda.

Listagem 6. Criando a tabela particionada pedidos

CREATE TABLE pedidos

(
id_ped int not null,
id_cli int not null, Figura 2. Inserindo dados na tabela pedidos e selecionando os dados
dta_ped date not null
) ON esquema_date(dta_ped)
GO
Gerenciando parties
Aps os dados serem particionados, muitas vezes h necessi-
dade de se fazerem alteraes nos intervalos da partio, como
Para se particionar um ndice, a sintaxe a mesma de um ndice adicionar intervalos, retirar intervalos, transferir dados de uma
no particionado, porm deve-se acrescentar a clusula ON e partio para outra ou at mesmo copiar uma partio inteira
especificar o esquema de partio e nome da coluna que a base para outra tabela. Para isso, so disponibilizados os comandos
da funo de partio. No caso da coluna, pode ser utilizada SPLIT, MERGE e SWITCH.

Edio 106 SQL Magazine 37

Particionamento de dados no SQL Server

Partio Valor mnimo Valor mximo Split

FG1 - 31/12/2011 O operador SPLIT utilizado para incluir um intervalo em
uma determinada funo de partio. Suponhamos que estamos
FG2 01/01/2012 31/01/2012
chegando ao ano de 2013 e se faz necessrio incluir o intervalo
FG3 01/02/2012 29/02/2012 do ms de janeiro na partio a fim de armazenar todos os regis-
FG4 01/03/2012 31/03/2012 tros deste ms em uma nica partio. Como configurado nas
FG5 01/04/2012 30/04/2012 sees acima, a funo de particionamento ir armazenar todos
os dados com data aps o dia 01 de dezembro de 2012 dentro do
FG6 01/05/2012 31/05/2012
filegroup FG13. Para que se possa ter uma melhor administrao
FG7 01/06/2012 30/06/2012 e controle dos dados, pode-se incluir um novo intervalo, adicio-
FG8 01/07/2012 31/07/2012 nando o ms de janeiro de 2013. Para isso, deve-se executar os
dois passos abaixo:
FG9 01/08/2012 31/08/2012
Alterar o esquema de partio e incluir um filegroup para ar-
FG10 01/09/2012 30/09/2012
mazenar o novo intervalo de dados;
FG11 01/10/2012 31/10/2012 Alterar a funo de partio utilizando o operador SPLIT para
FG12 01/11/2012 30/11/2012 incluir o novo intervalo.

FG13 01/12/2012 31/12/2012

A Listagem 8 mostra como adicionar um novo filegroup ao
FG13 01/01/2013 + esquema de partio esquema_particao. Este novo filegroup ir
Tabela 3. Tabela de partio aps alterao armazenar o ms de janeiro.
Nesta funo, o uso do NEXT USED FG13 indica o nome do
Listagem 8. Adicionando um filegroup no esquema de partio esquema_particao filegroup que receber o novo intervalo de dados que ser
especificado na funo de partio que ser alterada adiante.
ALTER PARTITION SCHEME esquema_particao Assim como explicado anteriormente, o nmero de filegroups
NEXT USED FG13 especificados no esquema de partio deve ser sempre o n-
GO
mero total de intervalo da funo de partio mais um. Um
Listagem 9. Executando o comando ALTER PARTITION FUNCTION com o operador filegroup pode ser especificado mais de uma vez no esquema
SPLIT RANGE de partio, fazendo com que dois intervalos sejam armaze-
nados no mesmo local.
ALTER PARTITION FUNCTION particao_range_right
SPLIT RANGE(2013-01-01)
A Listagem 9 mostra como executar o comando SPLIT para adi-
GO cionar o intervalo funo de partio particao_range_right.
Nesta listagem, o uso do SPLIT RANGE(2013-01-01) indica que
Listagem 10. Utilizando o operador MERGE para excluir um intervalo da funo
de partio particao_range_right
um novo intervalo ser includo na funo de partio. Caso o
filegroup no tenha sido adicionado como visto anteriormente,
ALTER PARTITION FUNCTION funcao_range_right () o banco de dados ir retornar um erro no momento da alterao.
MERGE RANGE (2013-01-01) Aps a incluso do intervalo, a funo de partio ficar conforme
GO Tabela 3.
Consultando novamente as tabelas sys.partition_
functions e sys.partition_range_values, pode-se per-
ceber que agora so retornadas treze linhas para a
funo de partio particao_range_right. A Figura 3
apresenta os dados selecionados.

Merge
Assim como o operador SPLIT utilizado para
incluir um intervalo dentro de um particionamento,
o operador MERGE faz o inverso, ou seja, retira um
intervalo do particionamento. Continuando com
o exemplo da tabela pedidos, a Listagem 10 ir
retirar o intervalo do ms de janeiro de 2013 criado
anteriormente.
Com este comando, os valores do ano de 2013
Figura 3. Verificando o nmero de parties voltaro a ser armazenados na partio junto com

38 SQL Magazine Edio 106

o ms de dezembro de 2012, ou seja, a partio que retirada
transferida para a partio da esquerda.
Swtich
Em algumas empresas e dependendo de como o sistema que o
banco de dados suporta, normal que se tenha duas tabelas para
uma mesma finalidade, onde uma armazena os dados atuais e outra
fique com os dados histricos, para fins de relatrio gerenciais. Para
que seja possvel fazer esta transferncia de dados no necessa-
riamente preciso utilizar um particionamento, pois poderia ser
utilizado um simples comando INSERT com SELECT, porm, neste
caso o esforo administrativo seria relativamente maior, pois aps
ter sido feito o comando INSERT, os dados que foram inseridos na
tabela de histrico ainda estariam na tabela de dados atuais, ten-
Em caso de a tabela de destino ser uma tabela particionada, a
mesma deve estar sendo particionada pela mesma coluna atravs
da funo de partio;
As tabelas de origem e destino devem estar no mesmo filegroup.
Para ficar mais claro o conceito, ser criada uma tabela chamada
pedidos_historico que ter a mesma estrutura da tabela pedidos.
Aps isso, todos os dados do ms de junho de 2012 sero trans-
feridos para a tabela recm-criada. A Listagem 11 exemplifica
a criao da tabela pedidos_historico assim como o comando
ALTER TABLE com o operador SWITCH PARTITION.
Listagem 11. Criao da tabela pedidos_historico e transferindo dados para a
tabela pedidos_historico

do ento que fazer a deleo dos dados na tabela. Dentro de uma CREATE TABLE pedidos_historico
tabela particionada, se possui uma facilidade que a utilizao (
do operador SWITCH, no qual se permite fazer a transferncia de id_ped int not null,
id_cli int not null,
uma determinada partio para outra tabela de forma mais rpida dta_ped date not null
e prtica. Porm, antes de iniciar o processo de transferncia dos ) ON FG7
GO
dados, alguns pr-requisitos devem ser obedecidos:
A tabela de destino j deve existir no servidor; ALTER TABLE pedidos
A partio da tabela destino (independente de ser particionada SWITCH PARTITION 7 TO pedidos_historico
GO
ou no) dever estar vazia;

Edio 106 SQL Magazine 39

Particionamento de dados no SQL Server
Aps o comando ser executado, todos os dados que faziam par-
te da partio 7 estaro na tabela pedidos_historico e no mais
presentes na tabela pedidos. A Figura 4 mostra o resultado dos
selects executados nas tabelas pedido e pedidos_historico.
Figura 4. Consultando dados nas tabelas pedidos e pedidos_historico
Concluso
O particionamento de dados um recurso muito interessante
de ser utilizado no SQL Server principalmente para gerenciarmos
tabelas grandes. Com ele podemos aproveitar ao mximo os re-
cursos do banco de dados, particionando os dados entre discos,
dividindo assim o I/O de leitura e gravao dos dados. Atravs do
particionamento de dados podemos tambm espalhar os dados
pelos discos dentro do servidor, aproveitando assim as caracte-
rsticas de cada um deles, podendo colocar os dados que j no
40 SQL Magazine Edio 106
so to utilizados em consultas ou que so mais utilizados para
relatrios gerenciais em um disco um pouco mais lento e deixar
os discos mais rpidos para as transaes OLTP do dia a dia e para
dados mais atuais, melhorando assim a performance.
Alm disso, podem aparecer necessidades de se fazer o ge-
renciamento das parties, onde ao final de um ano, devem-se
incluir os meses no intervalo das parties para que possam ser
armazenados em locais separados. Para isso, podemos utilizar
os operadores SPLIT, MERGE e SWITCH, que permitem, alm
de criar um intervalo, retirar um intervalo da partio ou at
mesmo transferir os dados de uma partio para outra na mesma
tabela ou transferir os dados para uma outra tabela, desde que
sejam seguidos alguns pr-requisitos, aos quais foram explica-
dos no artigo.
Ismael Costa Junior
icjunior07@gmail.com
Administrador de banco de dados SQL Server. Formado em sistemas
de banco de dados pela faculdade Veris IBTA. Trabalha com tecnologia
h 6 anos, onde h 4 anos atua com banco de dados. Possui certificao
MCTS SQL Server 2008.
SQL Server Books Online (BOL)
http://technet.microsoft.com/pt-br/library/ms130214.aspx
D seu feedback sobre esta edio! eu
Feedback
s
D
A SQL Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que
sobre e
voc, leitor, acha da revista!
s
ta
edio
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/sqlmagazine/feedback
Edio 106 SQL Magazine 41
Seo Banco de Dados/Persistncia
Nesta seo voc encontra artigos banco de dados, SQL ou persistncia
Seu banco de dados
na nuvem da Amazon
Criando uma instncia Oracle no RDS em poucos
cliques
A Resumo DevMan
origem do termo Cloud Computing ainda
desconhecida, e as informaes encontradas
na internet dificilmente convergem para um
ponto em comum. O fato que j utilizamos servios na
nuvem h muito tempo, seja ele um webmail, um drive
virtual, at datacenters terceirizados.
A computao em nuvem existia tambm dentro de
muitas empresas. Solues Citrix e VMware j permi-
tiam a virtualizao de servidores e desktops h muito
tempo. O objetivo sempre foi o mesmo: otimizao na
utilizao dos recursos computacionais e reduo de
custos.
Os avanos nas tecnologias de virtualizao permiti-
ram que empresas que j possuam grandes infraestrutu-
ras passassem a comercializar servios computacionais
e de armazenamento pela internet.
Uma das pioneiras nesse ramo a Amazon, com o
AWS (Amazon Web Services). Lanado em 2006, esse
servio j conta com vrios clientes de peso como Netflix,
Samsung, Sega entre outros.
Neste contexto, este artigo mostra que uma empresa
pode colocar seus bancos de dados na nuvem com segu-
rana, escalabilidade e alta disponibilidade a um custo
relativamente baixo, pagando apenas pelo que usar. Para
isso, o artigo esclarece algumas dvidas relacionadas
ao servio de banco de dados Oracle da Amazon consi-
derando aspectos tcnicos importantes que devem ser
levados em considerao na migrao de um banco de
dados para a nuvem.
A infraestrutura por trs da nuvem da Amazon
Para atender as enormes demandas de recursos por
parte dos clientes e usurios espalhados pelo mundo, a
Amazon disponibiliza diversos datacenters localizados
em regies estratgicas do globo terrestre. As regies
42 SQL Magazine Edio 106
De que se trata o artigo:
O artigo mostra de forma simples, com exemplos e simulaes,
que uma empresa pode colocar seus bancos de dados na nuvem
com segurana, escalabilidade e alta disponibilidade a um custo
relativamente baixo, pagando apenas pelo que usar.
Em que situao o tema til:
O artigo ajuda a esclarecer algumas dvidas relacionadas ao
servio de banco de dados Oracle da Amazon, detalhando a forma
de clculo do valor do servio, licenciamento e aspectos tcnicos
importantes que devem ser levados em considerao na migrao
de um banco de dados para a nuvem.
Seu banco de dados na nuvem da Amazon:
Neste artigo, o tema Computao em Nuvem entra em pauta
novamente, com foco no servio de banco de dados da Amazon,
o RDS (Relational Database Services).
Utilizando o Oracle como engine de banco de dados, sero de-
monstrados atravs de exemplos e simulaes o funcionamento,
mtricas e custos do servio. So abordados tambm servios
opcionais para as instncias RDS, como o Multi-AZ, que permite
criar rplicas em outras instalaes fsicas para garantir a alta dis-
ponibilidade em caso de falhas na instalao fsica primria.
sia-Pacfico (Tquio) e Amrica do Sul (So Paulo) so as mais
recentes e foram inauguradas em 2011.
Cada regio subdividida em Availability Zones (AZs), que so
instalaes fsicas distintas, isto , datacenters com suas prprias
infraestruturas e gerenciamentos independentes, mas ligados
entre si por conexes de rede de baixa latncia.
Cada regio possui pelo menos duas AZs:
 Regio Leste dos EUA (Norte da Virgnia) AZs: 4;
Regio Oeste dos EUA (Norte da Califrnia) AZs: 2;
Regio Oeste dos EUA (Oregon) AZs: 3;
Regio AWS GovCloud (EUA) AZs: 2;
Regio UE (Irlanda) AZs: 3;
Regio sia-Pacfico (Cingapura) AZs: 2;
Regio sia-Pacfico (Tquio) AZs: 2;
Regio de So Paulo AZs: 2.
Alm da alta disponibilidade, a segurana tambm priori-
dade nos servios da Amazon. Do acesso aos dados, ao acesso
s instalaes fsicas, o AWS possui diversas certificaes reco-
nhecidas nos EUA, desde a mais conhecida (ISO-27001) at uma
bem curiosa, relacionada ao trfico internacional de armas.
Para evitar o compartilhamento de senhas e usurios, que
poderia abrir uma brecha na segurana, a Amazon disponibi-
liza o AWS Identity and Access Management (IAM). Por ele,
possvel criar usurios e conceder permisses de acordo com
a funo de cada usurio, atravs de roles e grupos.
Para cada servio da AWS existem dois templates de policy,
um concedendo acesso total e outro apenas para visualizao.
Um grupo para administradores de bancos de dados, por
exemplo, teria acesso total ao RDS, usando o template Amazon
RDS Full Access.
No entanto, possvel customizar as policies, usando um
gerador ou, para quem j est mais familiarizado com o CLI
da Amazon, atravs de scripts.
Em uma configurao mais avanada, alm do grupo de DBAs,
um ambiente de produo teria tambm um grupo de opera-
dores. Se fossem concedidas apenas as permisses para reboot
de instncias e criao de snapshots, as aes selecionadas no
gerador de policy seriam RebootDBInstance e CreateDBSnap-
shot respectivamente.
Alm do gerenciamento de usurios, grupos e roles, o AIM
permite tambm que usurios corporativos (empregados de
uma empresa, por exemplo) acessem o AWS Management
Console e APIs da AWS usando um sistema de identificao
existente, como o Active Directory da Microsoft.
Segurana, alta disponibilidade e baixa latncia so itens
imprescindveis para o negcio, mas o que pode fazer uma
empresa realmente pensar em migrar suas aplicaes para a
nuvem a reduo de custo.
O custo de uma infraestrutura prpria
A maioria dos gestores de TI e Infraestrutura sabem que
Produto Named User Plus
Standard Edition One 180
Standard Edition 350
Enterprise Edition 950
Tabela 1. Lista de preos dos produtos da Oracle (Fonte: Oracle Global Pricing and Licensing)
um datacenter tem um custo muito alto. Ter um datacenter
prprio significa manter e gerir equipes ou empresas terceiras
para cuidar da parte eltrica, ar-condicionado, sistemas anti-
incndio, etc.
Na viso de uma empresa onde o core do negcio no TI,
um servidor, um storage, ou qualquer outro equipamento do
datacenter visto como uma despesa, um passivo (se financiado).
Com o tempo, esses equipamentos vo se tornando obsoletos
e incapazes de atender as demandas que s tendem a crescer.
Novamente, o gestor de TI vai precisar avaliar a possibilidade de
upgrade ou aquisio de novos equipamentos e softwares para
manter a qualidade e eficincia das operaes, criando-se assim
um crculo vicioso.
Graas virtualizao, as empresas conseguiram utilizar melhor
seus recursos computacionais e, portanto, conseguiram reduzir
substancialmente os custos com hardware. No entanto, no se
pode dizer o mesmo para software. Mesmo que existam formas
de comercializao diferenciada para ambientes virtuais, ainda
sim os departamentos de TI sofrem quando precisam adquirir
novas licenas ou renovar os contratos de suporte e atualizao,
principalmente quando falamos de banco de dados.
Tomamos como exemplo a Oracle que, assim como os concor-
rentes, disponibiliza verses de entrada para os seus produtos.
Se uma empresa quer comear a trabalhar com banco de dados
Oracle para um projeto pequeno, a verso mais indicada para ela
o Standard Edition One. Mesmo sendo a verso mais econmica
da Oracle, o valor pode assustar e at impedir que esse projeto
se concretize.
A Tabela 1 foi extrada do site da Oracle. Os valores esto em
dlares e existem algumas regras para cada produto e edio.
Para um sistema Web, por exemplo, no possvel determinar
a quantidade de usurios que o acessam. Nesse caso, o tipo de
licena Oracle que precisa ser adquirida a por processador
(Processor License).
Imaginando que o servidor tenha dois processadores (mximo
para esse produto), teramos a seguinte situao:
Licenas: 2 x U$ 5.800 = U$ 11.600
Suporte e atualizaes: 2 x U$ 1276 = U$ 2.552
Notem que o investimento inicial seria de US$ 14.152,00 pela li-
cena mais barata. Por outro lado, se fosse decidido pela utilizao
dos servios na nuvem, o investimento inicial seria bem menor e a
empresa s iria pagar pelo que usasse. Pensando nesse mercado,
a Amazon criou servios especficos para bancos de dados. So
eles: ElasticCache, DynamoDB e RDS.
Software Update License & Support Processor License Software Update License & Support
39,60 5.800 1.276,00
77,00 17.500 3.850,00
209,00 47.500 10.450,00
Edio 106 SQL Magazine 43
Seu banco de dados na nuvem da Amazon
O ElasticCache o servio de in-memory cache da Amazon,
utilizado para aumentar a velocidade de aplicaes, armazenando
informaes que so muito acessadas na memria RAM e, dessa
forma, evitando o acesso frequente a discos e bancos de dados.
O DynamoDB banco de dados NoSQL desenvolvido pela
Amazon. Resultado de anos de pesquisas em busca de alta esca-
labilidade e confiabilidade para os servios de ecommerce, esse
banco de dados no relacional baseado em chave-valor (key/value)
foi disponibilizado tambm como um web service.
Por ltimo, o RDS, que o servio de banco de dados relacional
da Amazon. Vamos conhecer com mais detalhes como ele fun-
ciona, custo de utilizao, vantagens e limitaes.
RDS Relational Database Service
Esse servio especfico para banco de dados relacionais permite
a utilizao de banco de dados Oracle, MySQL e SQL Server de
forma simples e econmica.
O gerenciamento da instncia todo feito pela Amazon.
O usurio no precisa preocupar-se, por exemplo, com aplicaes
de patches. A parametrizao tambm feita por eles de acordo
com a classe de instncia selecionada.
As classes determinam a quantidade de memria e CPUs dispo-
nveis para a instncia (dados extrados do site da Amazon):
Micro instncia de BD: 630 MB de memria, at 2 ECU (para
intermitncias peridicas curtas) - somente SQL Server.
Instncia de Banco de Dados pequena: memria de 1,7 GB,
1 ECU (1 virtual core com 1 ECU).
Instncia de Banco de Dados grande: memria de 7,5 GB, 4 ECUs
(2 virtual cores com 2 ECUs cada).
Instncia de Banco de Dados extragrande: 15 GB de memria,
8 ECUs (4 ncleos virtuais com 2 ECUs cada) - somente MySQL.
Instncia Extra Grande com memria elevada: 17,1 GB de
memria, 6,5 ECU (2 ncleos virtuais com 3,25 ECUs cada).
Instncia de Banco de Dados dupla extragrande com mais
memria: 34 GB de memria, 13 ECUs (4 ncleos virtuais com
3,25 ECUs cada).
Instncia de Banco de Dados Qudrupla extragrande com mais
memria: 68 GB de memria, 26 ECUs (8 ncleos virtuais com
3,25 ECUs cada).
Alm da escolha da classe, pode-se escolher o tipo do servio:
On-demand ou Instncia Reservada.
O tipo On-demand a forma mais simples de contratao do
servio. Voc paga pela capacidade computacional por hora uti-
lizada sem prazo definido.
J para a Instncia Reservada, voc determina o tempo que voc vai
reservar a instncia. As diferenas para o tipo On-demand so:
Investimento inicial, para planos de 1 ou 3 anos;
Definio de leve, mdia e alta utilizao.
Para esta opo, a Amazon concede descontos na taxa de uso por
hora em curso. Fazendo uma analogia com planos de telefonia
mvel, seria a diferena do valor do minuto utilizado entre um
plano ps-pago e um plano pr-pago.
44 SQL Magazine Edio 106
Para ambos os tipos, possvel usar uma licena includa (devido
a um acordo com a Oracle e Microsoft), ou usar o modelo BYOL
(Bring Your Own Licence).
Para utilizar o BYOL, necessrio ter a licena e o suporte apro-
priados para a classe selecionada e edio do Oracle.
As edies disponveis com o RDS so:
BYOL: Standard Edition One (SE1), Standard Edition (SE) e
Enterprise Edition (EE);
Licena includa: Standard Edition One (SE1).
possvel trocar a forma de licenciamento, por exemplo, de BYOL
para licena includa, mas necessrio excluir a instncia atual de
banco de dados (criando um snapshot final) e depois criar uma nova
a partir do snapshot, definindo a nova opo de licenciamento.
Como tudo isso calculado?
Devido variedade de mtricas e servios, a Amazon disponi-
biliza o Simple Monthly Calculator para facilitar o calculo final
dos servios que esto sendo contratados.
Podemos fazer uma comparao entre os tipos On-demand e
Reservada. A Tabela 2 mostra os parmetros e valores que sero
utilizados para o clculo.
A Tabela 3 mostra o resultado da simulao pelo tipo do servio
e tempo de utilizao/contratao.
Observando os nmeros acima, notamos que, para uma utili-
zao constante em longo prazo, a instncia reservada (mdia
utilizao) seria mais vantajosa que a On-demand. Portanto, o
que pode ser determinante na escolha do tipo o tempo que a
Instncia ficar no ar.
Alm das mtricas acima, existem outros servios que podem ser
adquiridos, como replicao, armazenamento de backup adicional
e transferncia de dados da internet.
A replicao (Implantao Multi-AZ) permite ter uma rplica
do banco de dados (em espera) em outra zona da regio (j expli-
cado anteriormente), garantindo assim disponibilidade em caso
de falhas na instncia ou na infraestrutura da zona primria.
O failover automtico e transparente para o usurio.
Region So Paulo
DB Engine and license Oracle (license included)
Class and deployment type Small Standard
Usage 24 * 30 = 720 (30 dias rodando 24h por dia)
Provisioned Storage 20GB por ms
I/O requests 1 milho
Offering and term (somente Medium 1 ano
reservada) Medium 3 anos
Tabela 2. Parmetros para o clculo do valor/hora da instncia
1 ano 3 anos
On-demand $ 147,88 * 12 = $ 1774,56 $ 147,88 * 36 = $ 5323,68
Reservada $ 67,24 * 12 + $ 427 = $ 1233,88 $ 47,08 * 36 + $ 617 = $ 2311,88
Tabela 3. Simulao do valor/hora por tipo de instncia (Fonte: AWS Simple Monthly Calculator)
 Alm do backup automtico, mencionado anteriormente, o usu-
rio pode tirar snapshots do banco de dados em qualquer momento.
O espao utilizado por eles gratuito at um limite de 100% do
armazenamento provisionado que foi contratado. Por exemplo:
se o armazenamento provisionado de 20GB/ms, o espao para
armazenamento do backup ser gratuito at 20GB/ms.
Vale reforar que, pelo fato dos recursos serem provisionados,
um snapshot dessa base no ocuparia necessariamente os 20GB,
e sim o que ela est utilizando. Alm disso, os backups costumam
ser menores que as bases e, portanto, esse espao gratuito de
backup acaba sendo o suficiente.
No entanto, se existir a necessidade de uma reteno maior,
ou at manter o banco de dados aps desativar a instncia, esse
servio poder ser contratado e o valor cobrado depender da
quantidade de GB/ms.
O ltimo servio parte oferecido o de transferncia de da-
dos pela internet. Cargas para dentro da nuvem da Amazon so
gratuitas, mas de dentro para fora so cobradas e divididas em
faixas, sendo que at 1GB/ms esse servio gratuito.
Aps uma viso geral do RDS, dos seus servios e custos, pode-
mos ver na prtica como ele funciona.
Tutorial
Implementando uma instncia Oracle pelo RDS
A Amazon possui um programa de teste que permite criar uma
instncia Oracle pequena e utiliz-la por 60 dias gratuitamente.
Nessa configurao, o usurio poder usar por ms:
750 horas de uma instncia pequena single-AZ (sem replicao);
20 Gb de armazenamento;
10 milhes de I/O;
20 Gb de armazenamento para backup e snapshot.
Figura 1. Pgina principal do RDS
Para os marinheiros de primeira viagem, o link Getting Started
Guide explica como criar uma instncia, conceder acesso e at
como termin-la.
O boto Launch a DB Instance chama um wizard. O processo
muito simples e divido em etapas sequencias. Inicialmente deve-
se escolher o tipo de banco de dados. No nosso caso, o Oracle SE
One, para o teste gratuito.
A Figura 2 mostra a segunda etapa da criao de uma instncia
de banco de dados Oracle.
Nesta etapa, definimos os parmetros da instncia. So eles:
License Model: licena includa ou BYOL.
DB Engine Version: verso do SGBD, no caso Oracle.
DB Engine Class: tamanho da instncia.
Multi-AZ Deployment: se utilizaremos outra Zona de Disponi-
bilidade.
Auto Minor Version Upgrade: define se patches de banco sero
ou no aplicados automaticamente.
Allocated Storage: tamanho do espao de armazenamento.
DB Instance Identifier: nome da instncia (no do banco).
Master Username: o seu usurio de banco, com a role DBA.
Master Password: senha do usurio Master.

Para utilizar o servio necessrio criar uma conta na Amazon.

Alm das informaes bsicas para o cadastro, ser solicitado
tambm um nmero de carto de crdito vlido (internacional).
Aps criar a conta, j possvel acessar a pgina de gerencia-
mento do AWS, o AWS Management Console.
A pgina inicial disponibiliza os links dos servios agrupados
por categorias:
Computing & Networking Servios computacionais e rede;
Storage & Content Delivery Servios de armazenamento;
Database Servios de banco de dados;
Deployment & Management Gerenciamento de contas e
servios;
App Services Servios de busca, notificao, email e message
queue e workflow.
Clicando no link RDS, somos direcionados para a pgina princi-
pal do servio. A criao e gerenciamento das instncias so feitas
nessa pgina, como podemos observar na Figura 1. Figura 2. Segunda etapa: escolha de verso, licena, tamanho e armazenamento

Edio 106 SQL Magazine 45

Seu banco de dados na nuvem da Amazon
A Figura 3 mostra a terceira etapa, onde so definidos parme-
tros especficos do banco de dados, VPC, Zona de Disponibilidade
preferencial e Grupos.
Figura 3. Terceira etapa: definio de parmetros de banco de dados e grupos
Antes de continuarmos, bom termos o conhecimento da fun-
o de cada grupo. Aps o domnio das funes bsicas do RDS
e do AWS Management Console, a utilizao dos grupos abaixo
ser de grande importncia para um ambiente de produo:
Option Groups: so grupos que permitem definir se uma
instncia ter um ou mais servios habilitados. Para o Oracle, as
opes disponveis so: OEM, APEX, APEX-DEV e XMLDB;
Parameter Groups: so grupos de parmetros customizados
de banco de dados. No Oracle, por exemplo, podemos definir
o parmetro AUDIT_TRAIL em um grupo que ser usado em
instncias de produo. No entanto, como as instncias so pr-
configuradas, no temos como aumentar alguns parmetros de
memria, por exemplo;
Figura 4. Tela de configurao dos grupos de segurana e acesso
46 SQL Magazine Edio 106
S ecurity Groups: so grupos de controle de acesso via rede,
como se fosse um firewall. Ao criar um grupo novo, necessrio
informar um IP ou faixa de IP que poder acessar a instncia.
A configurao de um grupo, ou criao de um novo, pode ser
feito antes ou depois da criao da instncia.
Na penltima etapa, definimos o perodo de reteno do
backup e as janelas de backup e manuteno.
Aplicaes de patches ocorrem na janela de manuteno.
Portanto, se a aplicao automtica for habilitada, aconselh-
vel determinar o perodo do dia que a instncia poder ficar
indisponvel.
Se no forem definidos horrios preferenciais, as janelas res-
peitaro os horrios de acordo com a regio onde a instncia
est rodando, conforme podemos observar na Tabela 4.
Region Time Block
US East (Northern Virginia) Region 03:00-11:00 UTC
US West (Northern California) Region 06:00-14:00 UTC
US West (Oregon) Region 06:00-14:00 UTC
EU (Ireland) Region 22:00-06:00 UTC
Asia Pacific (Singapore) Region 14:00-22:00 UTC
Asia Pacific (Tokyo) Region 17:00-03:00 UTC
South America (So Paulo) Region 00:00-08:00 UTC
Tabela 4. Horrios das janelas de todas as regies da Amazon (Fonte: Amazon AWS)
No final, uma tela mostrar o resumo de tudo que foi definido
para a instncia. Se for necessrio corrigir algum parmetro,
possvel voltar qualquer etapa antes de inici-la.
Para que possamos nos conectar nessa instncia, precisamos
autorizar o acesso a ela atravs de um Security Group.
No frame esquerdo da pgina do RDS, clicando no link DB
Security Groups, podemos alterar o grupo default ou criar um
novo. Como estamos testando o servio, vamos apenas alterar o
default e incluir uma faixa de IP.
A Figura 4 mostra o detalhe (em amarelo)
do tipo da conexo e o IP da mquina
que est conectada ao AWS Management
Console.
Reparem que o IP informado no campo
Details possui /32 no final, que significa
que o acesso ser permitido apenas para este
IP, e no para uma faixa.
Com o acesso autorizado, precisamos apenas
identificar o Endpoint da instncia para que
possamos nos conectar a ela. Esse campo est
localizado no frame que contm os detalhes da
instncia, conforme observado na Figura 5.
O Endpoint uma url de um web service
da Amazon. Podemos identificar nesse en-
dereo o nome da instncia, seguido de um
hash, regio e o domnio da Amazon.
 No caso de uma instncia RDS Oracle,
ela identifica o Host na string de cone-
xo.
Para conectar-se instncia usando o
SQL Plus, podemos colocar a string intei-
ra depois do @ ou alterar o tnsnames.
ora, conforme o exemplo da Listagem 1.
O master user um usurio com a role DBA
e, portanto, pode realizar tarefas adminis-
trativas, acessar o dicionrio de dados, etc.
Listagem 1. String de conexo no tnsnames.ora
A Figura 6 mostra uma conexo estabele-
cida com a instncia rdsora01 e a criao
de uma tablespace e de um usurio.
No entanto, nem tudo possvel em
uma instncia RDS, mesmo tendo a role
DBA. O UTL_FILE, por exemplo, no
funciona porque, para gerar ou ler um
arquivo, o Oracle precisaria ter acesso a
um filesystem. J o Data Pump funciona
parcialmente, somente no modo network
(usando db_links). Alm deles, algumas
packages e options tambm no funcio-
nam ou no esto disponveis. Abaixo,
algumas restries notadas:
As packages UTL_TCP, UTL_MAIL,
DBMS_EPG, SESSION_INFO so visuali-
zadas pela view DBA_OBJECTS mas no
funcionam.
As options Real Application Cluster e
Java Virtual Machine no esto dispo-
nveis. A primeira j mencionada pela
prpria Amazon, que at o momento no
oferece esse tipo de implementao.

rdsora01 = Configurando o Oracle Enterprise

(DESCRIPTION =
(ADDRESS_LIST =
Manager
(ADDRESS = (PROTOCOL = TCP)(HOST = rdsora01.<hash>.amazonaws.com) (PORT = 1521)) Para configurar o OEM em uma instn-
) cia do RDS, necessrio criar um grupo
(CONNECT_DATA =
(sid = rdsora01) no Option Groups. Podemos dar o nome
) de OEM, caso a funo seja somente essa
) (lembrando que possvel adicionar outras
opes para um grupo).
Com o grupo criado, podemos ento
adicionar a opo do OEM, especificando a
porta ou deixando a padro 1158, conforme
podemos observar na Figura 7.
Em seguida, vamos alterar o Option
Group da nossa instncia, de Default para
o OEM e mandar aplicar imediatamente.
Nesse momento, o status da instncia
muda para modifying. Esse processo
pode levar certo tempo at terminar.
Quando o status voltar para available,
o OEM ento pode ser acessado pelo bro-
wser usando o Endpoint da instncia e a
porta definida. Como podemos observar
na Figura 8, no existe nenhuma diferen-
a entre o OEM do RDS e o OEM de uma
Figura 5. Detalhes da instncia rdsora01 e o campo Endpoint a esquerda e a baixo
instalao local.

Backups e Snapshots
Como foi explicado anteriormente, o
backup gerenciado pela Amazon, mas
possvel tirar snapshots manuais em
qualquer momento. O procedimento bem
simples: basta clicar em Take Snapshot e
dar um nome para ele (sempre comeando
por uma letra), conforme o exemplo da
Figura 9.
O tempo que leva para concluir um
snapshot varia de acordo com o tamanho
da base. Quando concludo, o status muda
Figura 6. Conexo usando SQL*Plus e a criao de uma tablespace e de um usurio para available.

Edio 106 SQL Magazine 47

Seu banco de dados na nuvem da Amazon

Concluso
A evoluo tecnolgica permitiu o
surgimento de uma srie de servios na
nuvem com foco em negcios e empresas.
Com apenas alguns cliques, temos uma
instncia de banco de dados disponvel
para acesso de qualquer lugar que tenha
uma conexo com a internet.
Empresas com pouco capital, e at
simples usurios, agora podem usufruir
de softwares, poder computacional e ar-
mazenamento que somente uma grande
empresa poderia ter antes do surgimento
desses servios na nuvem.

Figura 7. My Option Groups e os grupos default e oem

Rodrigo Buriola
rburiola@gmail.com
Bacharel em Cincia da Compu-
tao pela PUC-SP e certificado
Oracle OCP, atua como DBA Oracle h
mais de 12 anos, com passagens por
empresas de grande porte de diversos ramos de ativi-
dade. Alm do SGBD Oracle, possui bons conhecimentos
em Storages e Sistemas Operacionais Unix. Atualmente
vem se dedicando tambm s pesquisas e estudos sobre
inovaes em Sistemas de armazenamento, Virtualizao
e Computao em nuvem.

Lista de preos dos produtos da Oracle

- Global Pricing and Licensing
http://www.oracle.com/us/corporate/
pricing/technology-price-list-070617.pdf
Licenciamento de software Oracle em
Figura 8. Pgina inicial do OEM Database Control da instncia criada no RDS ambientes na nuvem
http://www.oracle.com/us/corporate/pricing/
cloud-licensing-070579.pdf

D seu feedback sobre esta edio! eu

Feedback
s
D

A SQL Magazine tem que ser feita ao seu gosto.

sobre e

Para isso, precisamos saber o que voc, leitor,

s

ta
edio

acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/sqlmagazine/feedback

Figura 9. Tirando um snapshot manual da instncia

48 SQL Magazine Edio 106

Edio 106 SQL Magazine 49
Seo Banco de Dados/Persistncia
Nesta seo voc encontra artigos banco de dados, SQL ou persistncia
Particionamento no
Oracle - Parte 2
Mais estratgias
Este artigo faz parte de um curso
E
ste artigo o segundo de uma srie que trata
sobre particionamento de tabelas e ndices no
banco de dados Oracle. Alm de facilidade no
gerenciamento de dados, o particionamento oferece um
grande ganho de desempenho em tabelas cujo volume
de dados muito alto.
Pensando justamente nesta necessidade a Oracle ofe-
rece j h bastante tempo uma soluo realmente muito
boa. Trata-se do particionamento de objetos. Atravs
desta funcionalidade o DBA poder prover aplica-
o uma soluo de baixssimo custo (trata-se de uma
funcionalidade presente na verso Enterprise Edition
do banco de dados Oracle sem custo adicional), sem a
necessidade de alteraes de cdigo e que oferece um
desempenho realmente impressionante.
A versatilidade oferecida pela soluo realmente im-
pressiona, permitindo que parties sejam criadas com
base em um intervalo de dados (que podem ser valores
numricos ou mesmo datas) ou uma lista de valores (es-
tados da federao, por exemplo) ou ainda atravs de um
algoritmo de particionamento e, como se no bastasse,
at mesmo baseado na combinao destas estratgias.
O melhor de tudo que toda essa implementao to-
talmente transparente para a camada de aplicao.
Esta funcionalidade no est limitada apenas a situa-
es onde existam tabelas gigantescas (como ambientes
de Data Warehouse, por exemplo), mas se adaptam per-
feitamente a situaes em que seja necessrio gerenciar o
ciclo de vida das informaes ou at mesmo organizar
melhor a forma em que os dados estejam armazenados
nas tabelas.
Na primeira parte desta srie de artigos vimos os
principais conceitos sobre particionamento no banco
de dados Oracle. Dentre os conceitos pudemos perceber
que a estratgia de particionamento especialmente
50 SQL Magazine Edio 106
Resumo DevMan
De que se trata o artigo:
O SGBD Oracle disponibiliza uma soluo completa de particionamento
de dados. So vrias as opes que podem ser utilizadas. Nesta segunda
parte do artigo, daremos continuidade anlise das tcnicas de particio-
namento atravs de uma abordagem terica e prtica.
Em que situao o tema til:
Particionamento de dados um tema bastante til para facilitar o
gerenciamento de grandes bases de dados. Atravs dele possvel re-
alizado o gerenciamento descentralizado das informaes. Alm disso,
seu uso tende a tornar o armazenamento dos dados mais eficiente e com
melhor desempenho.
Particionamento no Oracle - Parte 2:
A crescente quantidade de dados armazenados em SGBDs em organiza-
es dispersas geograficamente tem levado necessidade cada vez maior
de um gerenciamento eficiente e performtico das bases de dados.
Neste artigo conheceremos mais algumas tcnicas de particionamento
em banco de dados. Abordaremos as tcnicas de particionamento por
hash, intervalo, referncia, composto range-range, composto range-list,
composto range-hash e composto list-list. Todas as tcnicas sero apre-
sentadas considerando suas definies e exemplos de uso.
importante no que diz respeito a desempenho em consultas a
tabelas com volumes de dados realmente grandes.
A crescente demanda pela necessidade de armazenamento de
arquivos binrios tambm uma das caractersticas beneficiadas
pela tcnica de particionamento. Outra caracterstica bastante be-
neficiada pelo particionamento o gerenciamento do ciclo de vida
das informaes. Muitas vezes, por questes legais ou estratgicas,
as informaes precisam ser mantidas no banco de dados por um
perodo definido de tempo e, aps esse perodo, estas informaes
j podem ser retiradas do banco de dados. Mais uma vez podemos
ver a grande facilidade de expurgar estas informaes atravs da
utilizao de particionamento.
Ainda no primeiro artigo apresentamos duas estratgias
de particionamento: de nvel nico do tipo range (intervalo) e
list (lista). Neste artigo apresentaremos a terceira estratgia
de particionamento de nvel nico, do tipo hash (ver Nota do Nota do DevMan 1
DevMan 1) e tambm comearemos a apresentar as estratgias
de particionamento composto. A funo Hash
Uma funo hash qualquer algoritmo ou sub-rotina que mapeia grandes conjuntos de dados de
Particionamento por Hash comprimento varivel, denominadas chaves, para conjuntos de dados menores de um comprimento
fixo. Por exemplo, o nome de uma pessoa, que tem um comprimento varivel, pode ser convertido em
No particionamento por hash, o banco de dados mapeia os um nico nmero inteiro. Os valores retornados por uma funo hash so chamados de valores de
registros para parties com base em um algoritmo de hashing hash, cdigos de hash ou simplesmente hashes.
que o banco de dados aplica na chave de particionamento espe- As funes hash so usadas principalmente para acelerar as tarefas de pesquisa em tabelas ou
cificada pelo usurio. O destino do registro determinado pela comparao de dados, tais como encontrar itens em um banco de dados, detectar duplicidades ou
funo hash que foi aplicada ao registro. O algoritmo de hashing registros similares em um arquivo grande, encontrar trechos semelhantes em sequncias de DNA,
e assim por diante.
concebido para distribui uniformemente as linhas entre as
parties, de modo que cada partio contenha o mesmo nmero Uma funo hash deve ser referencialmente transparente (estvel), ou seja, se chamada duas vezes
na entrada que igual (por exemplo, os strings que consistem na mesma sequncia de caracteres),
de registros. deve retornar o mesmo resultado. Este um consenso em muitas linguagens de programao que
O particionamento por hash til para dividir grandes tabelas permite que o usurio substitua igualdade e funes de hash para um objeto: se dois objetos so
aumentando a capacidade de gerenciamento. Em vez de uma iguais, seus cdigos de hash devem ser o mesmo. Isso crucial para encontrar um elemento em uma
tabela hash rapidamente, porque dois elementos iguais compartilhariam o mesmo slot de dados.
grande tabela para gerenciar, o DBA tem vrios pedaos menores
para gerenciar. A perda de uma nica partio hash no afeta as
parties restantes e pode ser recuperada de forma independente.
Particionamento por hash tambm se mostra til em sistemas OLTP Listagem 1. Criao da tabela de vendas particionada por hash.
com alto ndice de atualizaes (updates). Por exemplo, uma vez que
01. CREATE TABLE HASH_SALES
a tabela est particionada em vrios pedaos menores, as atuali-
02. (PROD_ID NUMBER(6),
zaes podem ser feitas independentemente em cada uma destas 03. CUST_ID NUMBER,
parties, evitando assim contenes em uma nica tabela. 04. TIME_ID DATE,
05. CHANNEL_ID CHAR(1),
Ainda utilizando o mesmo exemplo da tabela de vendas apresenta- 06. PROMO_ID NUMBER(6),
do no primeiro artigo da srie, vamos agora particion-la por hash. A 07. QUANTITY_SOLD NUMBER(3),
Tabela 1 apresenta as informaes presentes na tabela de vendas. 08. AMOUNT_SOLD NUMBER(10,2))
09. PARTITION BY HASH (PROD_ID)
A Listagem 1 apresenta a instruo SQL para criao da tabela 10. PARTITIONS 2;
hash_sales, que a tabela de vendas particionada por hash.
Perceba que a criao de uma tabela particionada, em sua pri-
meira parte (linhas 01 a 08 da Listagem 1), exatamente igual a Neste nosso exemplo haver duas parties. Mas como sero
criao de uma tabela convencional, ou seja, a instruo CREATE definidos quais registros estaro em cada partio? a que entra
TABLE (linha 01) e a definio das colunas (linhas 02 a 08) no a funo hash, que aplicar o algoritmo hashing no valor presente
diferem em nada de uma tabela convencional. na coluna PROD_ID do registro e o resultado da funo definir
A clusula PARTITION o diferencial. A linha 09 define qual em qual das duas parties o registro ser armazenado. Em outras
o tipo de partio (no caso, hash) e qual a chave de partio palavras, o prprio Oracle que define em qual partio o registro
(PROD_ID) e a linha 10 define em quantas parties se quer ser armazenado e ele far de tudo para manter um volume igual
dividir a tabela. em cada partio.

PROD_ID CUST_ID TIME_ID CHANNEL_ID PROMO_ID QUANTITY_SOLD AMOUNT_SOLD

116 11393 05-JUN-99 2 999 1 12.18
40 100530 30-NOV-98 9 33 1 44.99
118 133 06-JUN-01 2 999 1 17.12
133 9450 01-DEC-00 2 999 1 31.28
36 4523 27-JAN-99 3 999 1 53.89
125 9417 04-FEB-98 3 999 1 16.86
30 170 23-FEB-01 2 999 1 8.8
24 11899 26-JUN-99 4 999 1 43.04
35 2606 17-FEB-00 3 999 1 54.94
45 9491 28-AUG-98 4 350 1 47.45

Tabela 1. Tabela de vendas, usada como base

Edio 106 SQL Magazine 51

Particionamento no Oracle - Parte 2

Partio SYS_P33
PROD_ID CUST_ID TIME_ID CHANNEL_ID PROMO_ID QUANTITY_SOLD AMOUNT_SOLD
40 100530 30-NOV-98 9 33 1 44.99
118 133 06-JUN-01 2 999 1 17.12
36 4523 27-JAN-99 3 999 1 53.89
30 170 23-FEB-01 2 999 1 8.8
35 2606 17-FEB-00 3 999 1 54.94

Partio SYS_P34
PROD_ID CUST_ID TIME_ID CHANNEL_ID PROMO_ID QUANTITY_SOLD AMOUNT_SOLD
116 11393 05-JUN-99 2 999 1 12.18
133 9450 01-DEC-00 2 999 1 31.28
125 9417 04-FEB-98 3 999 1 16.86
24 11899 26-JUN-99 4 999 1 43.04
45 9491 28-AUG-98 4 350 1 47.45

Tabela 2. Tabela de vendas particionada por hash

Aps a carga de dados feita com base nas informaes apresenta-
das na Tabela 1, a distribuio dos registros na tabela particionada
se dar conforme apresentado na Tabela 2.
Particionamento por Interva l (Intervalo)
O particionamento por interval , na verdade, uma subdiviso
do particionamento por range. Por isso no considerado como
sendo uma das estratgias de particionamento. Interval uma
clusula que pode ser utilizada quando feito o particionamento
por range.
A clusula de interval, da instruo CREATE TABLE, estabele-
ce um intervalo de particionamento para a tabela. necessrio
especificar pelo menos uma partio do tipo range na clusula
PARTITION. O valor de chave de particionamento determina o
valor do limite superior das parties, que chamado de ponto
de transio, e o banco de dados cria automaticamente parties
do tipo interval para os dados alm desse ponto de transio. O
limite inferior do intervalo de cada partio a fronteira superior,
no inclusiva, da partio anterior.
Por exemplo, ao criar uma tabela particionada do tipo interval
com intervalos de um ms e o ponto de transio 01 de janeiro
de 2010, ento o limite inferior para este intervalo 01 de janeiro
de 2010. O limite inferior do intervalo julho de 2010 01 de julho
de 2010, independentemente se a partio junho de 2010 tenha
sido criada anteriormente.
Para o particionamento do tipo interval, a chave de particiona-
mento pode ser apenas uma nica coluna da tabela e deve ser do
tipo NUMBER ou DATE.
A Listagem 2 apresenta a instruo SQL para a criao de uma
tabela particionada utilizando a clusula interval.
Novamente, perceba que o incio da instruo SQL (linhas 01 a
08 da Listagem 2) exatamente igual a instruo de criao de
qualquer tabela comum.
Listagem 2. Criao da tabela de vendas particionada por hash.
01. CREATE TABLE INTERVAL_SALES
02. (PROD_ID NUMBER(6),
03. CUST_ID NUMBER,
04. TIME_ID DATE,
05. CHANNEL_ID CHAR(1),
06. PROMO_ID NUMBER(6),
07. QUANTITY_SOLD NUMBER(3),
08. AMOUNT_SOLD NUMBER(10,2))
09. PARTITION BY RANGE (TIME_ID)
10. INTERVAL(NUMTOYMINTERVAL(1, MONTH))
11. (PARTITION P0 VALUES LESS THAN (TO_DATE(1-1-2008, DD-MM-YYYY)),
12. PARTITION P1 VALUES LESS THAN (TO_DATE(1-1-2009, DD-MM-YYYY)),
13. PARTITION P2 VALUES LESS THAN (TO_DATE(1-7-2009, DD-MM-YYYY)),
14. PARTITION P3 VALUES LESS THAN (TO_DATE(1-1-2010, DD-MM-YYYY)));
A linha 09 define que a tabela ser particionada atravs do
mtodo range e as linhas 11 a 14 definem quais so as par-
ties criadas inicialmente e o respectivo intervalo de cada
partio.
A diferena aqui de uma tabela particionada pura e sim-
plesmente por range est na linha 10, onde foi utilizada a
clusula interval cujo intervalo foi definido como mensal
(NUMTOYMINTERVAL(1, MONTH)). Na prtica, isto significa
que todos os registros cujo TIME_ID for menor que 01/01/2008
sero armazenados na partio P0. Registros com TIME_ID
menores que 01/01/2009 sero armazenados na partio P1,
TIME_IDs menores que 01/07/2009 iro para a partio P2 e
registros cujo valor de TIME_ID seja menor que 01/01/2010
sero armazenados na partio P3.
OK, at aqui um particionamento por range puro e simples.
Sim, mas a partir dos valores para a coluna TIME_ID maiores
ou iguais a 01/01/2010 que a histria muda. O Oracle criar
parties automaticamente para cada ms a partir de 2010. Ou
seja, todos os registros cujo TIME_ID esteja entre 01/01/2010

52 SQL Magazine Edio 106

e 31/01/2010 sero armazenados em uma partio nova e Na primeira parte da Listagem 3 (linhas 01 a 15) foi criada a
automaticamente criada e, para um registro com TIME_ID tabela ORDERS particionada por range com quatro parties (uma
igual a 01/02/2010, uma nova partio ser criada e assim para cada trimestre do ano de 2005).
sucessivamente. Logo depois iniciada a criao da tabela filho ORDER_ITEM,
Trocando em midos, no ser necessrio criar novas parties, mas perceba que a instruo tambm praticamente a mesma
pois o Oracle se encarregar de fazer isso automaticamente. de uma tabela convencional, com o CREATE TABLE (linha 17),
definio das colunas (linhas 18 a 22) e definio da FK (linhas
Particionamento por Reference (Referncia) 23 e 24). O que torna esta tabela particionada apenas a clusula
H tambm a opo de criar uma tabela particionada com base PARTITION BY (linha 25) em que definida a estratgia de par-
em uma referncia. o caso em que necessrio criar uma tabela ticionamento como sendo do tipo reference utilizando a FK como
particionada, porm utilizando todas as especificaes de parti- chave do particionamento.
cionamento de uma tabela pai. Por isso a referncia. A tabela Na verdade, o Oracle ir utilizar a definio do particiona-
filho referencia a tabela pai atravs da chave estrangeira (FK, mento encontrado na tabela pai, ou seja, do tipo range com
de Foreign Key) e, atravs desta restrio de integridade referencial, quatro parties.
a tabela filho herdar as caractersticas de particionamento Caso utilize os descritores de partio ao invs de utilizar o par-
da tabela pai. ticionamento por reference, ento o nmero de parties descritas
Para criar uma tabela particionada por reference, necessrio deve ser exatamente igual ao nmero de parties ou subparties
especificar a clusula PARTITION BY REFERENCE na instruo na tabela referenciada (tabela pai). Se a tabela pai uma tabela
CREATE TABLE. Esta clusula especifica o nome de uma restrio particionada composta (veremos adiante), a tabela dever ter uma
de integridade referencial e esta restrio torna-se a restrio do partio para cada subpartio definida na tabela pai.
particionamento referencial que usada como a base para parti- Na verdade, nos casos de tabela pai tabela filho, o ideal
cionamento da tabela. A FK deve estar habilitada. utilizar o particionamento do tipo reference, evitando a possibili-
A Listagem 3 apresenta a criao de uma tabela "pai" particio- dade de erros por definies de partio equivocadas.
nada por range (ORDERS) e, logo aps, criada a tabela "filho" Limites de partio no podem ser especificados para as parti-
particionada por reference (ORDER_ITEM). es de uma tabela particionada por reference.
As parties de uma tabela particionada por reference podem
ser nomeadas. Se uma partio no explicitamente nomeada,
Listagem 3. Criao da tabela pai particionada por range e tabela filho particio- ento ele herda o nome da partio correspondente na tabela
nada por reference.
pai, a menos que esta herana gere algum conflito de nome
01. CREATE TABLE ORDERS com parties j criadas. Neste caso, a partio receber um nome
02. (ORDER_ID NUMBER(12), gerado pelo sistema.
03. ORDER_DATE TIMESTAMP WITH LOCAL TIME ZONE, Novamente, a utilizao de particionamento do tipo reference
04. ORDER_MODE VARCHAR2(8),
j resolve todo este problema. No h a menor necessidade de
05. CUSTOMER_ID NUMBER(6),
06. ORDER_STATUS NUMBER(2), preocupaes com nomes e definies das parties.
07. ORDER_TOTAL NUMBER(8,2),
08. SALES_REP_ID NUMBER(6), Particionamento Composto (Composite Partitioning)
09. PROMOTION_ID NUMBER(6),
10. CONSTRAINT ORDERS_PK PRIMARY KEY(ORDER_ID))
Existe ainda a possibilidade de criao de subparties, ou seja,
11. PARTITION BY RANGE(ORDER_DATE) particionar as parties de uma tabela. Desta maneira, est sendo
12. (PARTITION Q1_2005 VALUES LESS THAN (TO_DATE(01-APR-2005, criada uma tabela com particionamento composto, onde cada
DD-MON-YYYY)), partio da tabela tambm particionada.
13. PARTITION Q2_2005 VALUES LESS THAN (TO_DATE(01-JUL-2005,
DD-MON-YYYY)),
O mais interessante nesta histria toda que no estamos limi-
14. PARTITION Q3_2005 VALUES LESS THAN (TO_DATE(01-OCT-2005, tados a utilizar a mesma estratgia de particionamento para as
DD-MON-YYYY)), parties e subparties, ou seja, possvel fazer uma composio
15. PARTITION Q4_2005 VALUES LESS THAN (TO_DATE(01-JAN-2006, entre as parties e subparties da seguinte forma:
DD-MON-YYYY)));
16.
Particionamento composto range-range;
17. CREATE TABLE ORDER_ITEMS Particionamento composto range-list;
18. (ORDER_ID NUMBER(12) NOT NULL, Particionamento composto range-hash;
19. LINE_ITEM_ID NUMBER(3) NOT NULL,
Particionamento composto list-list;
20. PRODUCT_ID NUMBER(6) NOT NULL,
21. UNIT_PRICE NUMBER(8,2),
Particionamento composto list-range;
22. QUANTITY NUMBER(8), Particionamento composto list-hash;
23. CONSTRAINT ORDER_ITEMS_FK Particionamento composto interval-range;
24. FOREIGN KEY(ORDER_ID) REFERENCES ORDERS(ORDER_ID))
Particionamento composto interval-list;
25. PARTITION BY REFERENCE(ORDER_ITEMS_FK);
Particionamento composto interva -hash;

Edio 106 SQL Magazine 53

Particionamento no Oracle - Parte 2
Particionamento Composto range-range
Os intervalos das parties de uma tabela com particionamento
composto do tipo range-range so semelhantes aos intervalos de
uma tabela com particionamento no-composto. Isto permite
a utilizao de parmetros opcionais da clusula PARTITION
para especificar atributos fsicos e outros atributos, incluindo
tablespace, especficos para cada partio. Se no for definido no
nvel da partio, ento as parties herdam os atributos da sua
tabela de base.
O tablespace um local de armazenamento onde os dados dos
objetos de banco de dados so efetivamente armazenados. Ele
fornece uma camada de abstrao entre os dados fsicos e lgi-
cos, e serve para alocar espao de armazenamento para todos
os objetos gerenciados pelo SGBD. Uma vez criado, o tablespace
pode ser referenciado no momento da criao dos segmentos
de banco de dados.
Tablespaces especificam apenas os locais de armazenamento de
banco de dados e no a estrutura lgica do banco de dados, ou
esquema de banco de dados. Por exemplo, objetos diferentes no
mesmo esquema podem ter seu armazenamento em diferentes
tablespaces. Da mesma forma, um tablespace pode atender segmen-
tos de mais de um esquema.
Ao utilizar tablespaces, o DBA pode controlar o layout de disco na
criao do tablespace. Um uso comum de tablespace para otimizar
o desempenho. Por exemplo, um ndice muito usado pode ser co-
locado sobre um disco SCSI rpido. Por outro lado, uma tabela do
banco de dados que contm dados histricos, que so raramente
acessados, pode ser armazenada em um disco IDE mais barato,
porm de acesso mais lento.
Embora seja comum em tablespaces armazenar os dados em
arquivo no sistema operacional, este arquivo deve ser parte de
apenas um nico tablespace. Alguns SGBDs permitem que os
tablespaces utilizem diretamente dispositivos brutos, chamados
raw devices, proporcionando um melhor desempenho por evitar
a utilizao da camada de sistema operacional no gerenciamento
dos arquivos.
O Oracle armazena dados logicamente em tablespaces e fisica-
mente em arquivos de dados (datafiles) associados ao tablespace
correspondente.
A descrio dos intervalos das subparties, nas clusulas
SUBPARTITION, so semelhantes s parties de tabela com
particionamento no-composto, exceto o nico atributo fsico
opcional que pode ser especificado, tablespace. Subparties
herdam todos os outros atributos fsicos a partir da descrio
de partio.
A Listagem 4 apresenta como um particionamento range-range
pode ser usado. O exemplo se refere ao rastreiamento das entre-
gas dos pedidos. O contrato de servio com o cliente define que
cada pedido entregue no ms seguinte ao que o pedido foi feito.
Os seguintes tipos de entrega so utilizados:
E (early - cedo): encomendas que so entregues antes da metade
do prximo ms aps o pedido ter sido efetivado. Estas encomen-
das provavelmente iro exceder as expectativas do cliente;
54 SQL Magazine Edio 106
A (agreed - de acordo): as encomendas que so entregues no ms
do calendrio aps a efetivao do pedido (mas que no foram
entregues antes da metade do ms).
L (late - atrasado): encomendas que foram entregues apenas
depois do segundo ms aps a efetivao do pedido.
Perceba, na Listagem 4, que a base da criao da tabela continua
sendo a mesma (linhas 01 a 06) e, na linha 07, definido o tipo do
particionamento (range) utilizando a coluna ORDER_DATE como
chave de particionamento.
A diferena comea na linha 08, em que definido o subparti-
cionamento, tambm do tipo range, mas agora utilizando a coluna
DELIVERY_DATE como chave do particionamento.
E para finalizar, para cada partio definida (linhas 09, 13, 17,
21, 25 e 29), so definidas as subparties (linhas 10 a 12, 14 a 16,
18 a 20, 22 a 24, 26 a 28 e 30 a 32).
Cada registro ser mapeado para uma partio verificando se o
valor da chave de partio do registro cai dentro de um intervalo
especfico de partio.
O registro ento mapeado para uma subpartio dentro dessa
partio identificando se o valor da chave de subparticionamento
cai dentro de um intervalo especfico. Por exemplo, uma entrega
com uma data de pedido (ORDER_DATE) em setembro de 2006
e uma data de entrega (DELIVERY_DATE) de 28 de outubro de
2006 ser mapeado para a subpartio P06_OCT_A.
Particionamento Composto range-list
Os intervalos das parties de uma tabela com particionamento
composto do tipo range-list so semelhantes aos intervalos de uma
tabela com particionamento no-composto e, da mesma forma
que o particionamento composto range-range, podemos definir a
tablepace para cada subpartio.
A descrio da lista das subpart ies, nas clusulas
SUBPARTITION, semelhante a parties de tabela com parti-
cionamento no-composto, exceto o nico atributo fsico opcional
que pode ser especificado, tablespace. Subparties herdam todos
os outros atributos fsicos a partir da descrio de partio.
A Listagem 5 apresenta como um particionamento range-list
pode ser usado. O exemplo rastreia os dados de vendas de pro-
dutos por trimestres e, dentro de cada trimestre, agrupados por
estado da federao.
Veja, na Listagem 5, que a base da criao da tabela continua
sendo a mesma (linhas 01 a 06) e, na linha 07, definido o tipo
do particionamento (range) utilizando a coluna TXN_DATE como
chave de particionamento.
A diferena comea na linha 08, em que definido o subparti-
cionamento, agora do tipo list, utilizando a coluna STATE como
chave do particionamento.
E para finalizar, para cada partio definida (linhas 09, 17, 25 e
33), so definidas as subparties (linhas 10 a 16, 18 a 24, 26 a 32
e 34 a 40) porm do tipo list.
Cada registro ser mapeado para uma partio verificando se o
valor da chave de partio do reg istro cai dentro de um intervalo
 Listagem 4. Criao da tabela particionada por range-range.

01. CREATE TABLE SHIPMENTS (TO_DATE(15-OCT-2006,DD-MON-YYYY)),

02. (ORDER_ID NUMBER NOT NULL, 19. SUBPARTITION P06_SEP_A VALUES LESS THAN
03. ORDER_DATE DATE NOT NULL, (TO_DATE(01-NOV-2006,DD-MON-YYYY)),
04. DELIVERY_DATE DATE NOT NULL, 20. SUBPARTITION P06_SEP_L VALUES LESS THAN (MAXVALUE)),
05. CUSTOMER_ID NUMBER NOT NULL, 21. PARTITION P_2006_OCT VALUES LESS THAN
06. SALES_AMOUNT NUMBER NOT NULL) (TO_DATE(01-NOV-2006,DD-MON-YYYY))
07. PARTITION BY RANGE (ORDER_DATE) 22. (SUBPARTITION P06_OCT_E VALUES LESS THAN
08. SUBPARTITION BY RANGE (DELIVERY_DATE) (TO_DATE(15-NOV-2006,DD-MON-YYYY)),
09. (PARTITION P_2006_JUL VALUES LESS THAN 23. SUBPARTITION P06_OCT_A VALUES LESS THAN
(TO_DATE(01-AUG-2006,DD-MON-YYYY)) (TO_DATE(01-DEC-2006,DD-MON-YYYY)),
10. (SUBPARTITION P06_JUL_E VALUES LESS THAN 24. SUBPARTITION P06_OCT_L VALUES LESS THAN (MAXVALUE)),
(TO_DATE(15-AUG-2006,DD-MON-YYYY)), 25. PARTITION P_2006_NOV VALUES LESS THAN
11. SUBPARTITION P06_JUL_A VALUES LESS THAN (TO_DATE(01-DEC-2006,DD-MON-YYYY))
(TO_DATE(01-SEP-2006,DD-MON-YYYY)), 26. (SUBPARTITION P06_NOV_E VALUES LESS THAN
12. SUBPARTITION P06_JUL_L VALUES LESS THAN (MAXVALUE)), (TO_DATE(15-DEC-2006,DD-MON-YYYY)),
13. PARTITION P_2006_AUG VALUES LESS THAN 27. SUBPARTITION P06_NOV_A VALUES LESS THAN
(TO_DATE(01-SEP-2006,DD-MON-YYYY)) (TO_DATE(01-JAN-2007,DD-MON-YYYY)),
14. (SUBPARTITION P06_AUG_E VALUES LESS THAN 28. SUBPARTITION P06_NOV_L VALUES LESS THAN (MAXVALUE)),
(TO_DATE(15-SEP-2006,DD-MON-YYYY)), 29. PARTITION P_2006_DEC VALUES LESS THAN
15. SUBPARTITION P06_AUG_A VALUES LESS THAN (TO_DATE(01-JAN-2007,DD-MON-YYYY))
(TO_DATE(01-OCT-2006,DD-MON-YYYY)), 30. (SUBPARTITION P06_DEC_E VALUES LESS THAN
16. SUBPARTITION P06_AUG_L VALUES LESS THAN (MAXVALUE)), (TO_DATE(15-JAN-2007,DD-MON-YYYY))
17. PARTITION P_2006_SEP VALUES LESS THAN 31. SUBPARTITION P06_DEC_A VALUES LESS THAN
(TO_DATE(01-OCT-2006,DD-MON-YYYY)) (TO_DATE(01-FEB-2007,DD-MON-YYYY))
18. (SUBPARTITION P06_SEP_E VALUES LESS THAN 32. SUBPARTITION P06_DEC_L VALUES LESS THAN (MAXVALUE)));

Listagem 5. Criao da tabela particionada por range-list.

01. CREATE TABLE QUARTERLY_REGIONAL_SALES 21. SUBPARTITION Q2_1999_SOUTHEAST VALUES (FL, GA),
02. (DEPTNO NUMBER, 22. SUBPARTITION Q2_1999_NORTHCENTRAL VALUES (SD, WI),
03. ITEM_NO VARCHAR2(20), 23. SUBPARTITION Q2_1999_SOUTHCENTRAL VALUES (OK, TX)
04. TXN_DATE DATE, 24. SUBPARTITION Q2_1999_OTHERS VALUES (DEFAULT) TABLESPACE TS5),
05. TXN_AMOUNT NUMBER, 25. PARTITION Q3_1999 VALUES LESS THAN
06. STATE VARCHAR2(2)) (TO_DATE(1-OCT-1999,DD-MON-YYYY)) TABLESPACE TS3
07. PARTITION BY RANGE (TXN_DATE) 26. (SUBPARTITION Q3_1999_NORTHWEST VALUES (OR, WA),
08. SUBPARTITION BY LIST (STATE) 27. SUBPARTITION Q3_1999_SOUTHWEST VALUES (AZ, UT, NM),
09. (PARTITION Q1_1999 VALUES LESS THAN 28. SUBPARTITION Q3_1999_NORTHEAST VALUES (NY, VM, NJ),
(TO_DATE(1-APR-1999,DD-MON-YYYY)) TABLESPACE TS1 29. SUBPARTITION Q3_1999_SOUTHEAST VALUES (FL, GA),
10. (SUBPARTITION Q1_1999_NORTHWEST VALUES (OR, WA), 30. SUBPARTITION Q3_1999_NORTHCENTRAL VALUES (SD, WI),
11. SUBPARTITION Q1_1999_SOUTHWEST VALUES (AZ, UT, NM), 31. SUBPARTITION Q3_1999_SOUTHCENTRAL VALUES (OK, TX)
12. SUBPARTITION Q1_1999_NORTHEAST VALUES (NY, VM, NJ), 32. SUBPARTITION Q3_1999_OTHERS VALUES (DEFAULT) TABLESPACE TS5),
13. SUBPARTITION Q1_1999_SOUTHEAST VALUES (FL, GA), 33. PARTITION Q4_1999 VALUES LESS THAN
14. SUBPARTITION Q1_1999_NORTHCENTRAL VALUES (SD, WI), ( TO_DATE(1-JAN-2000,DD-MON-YYYY)) TABLESPACE TS4
15. SUBPARTITION Q1_1999_SOUTHCENTRAL VALUES (OK, TX) 34. (SUBPARTITION Q4_1999_NORTHWEST VALUES (OR, WA),
16. SUBPARTITION Q1_1999_OTHERS VALUES (DEFAULT) TABLESPACE TS5), 35. SUBPARTITION Q4_1999_SOUTHWEST VALUES (AZ, UT, NM),
17. PARTITION Q2_1999 VALUES LESS THAN 36. SUBPARTITION Q4_1999_NORTHEAST VALUES (NY, VM, NJ),
( TO_DATE(1-JUL-1999,DD-MON-YYYY)) TABLESPACE TS2 37. SUBPARTITION Q4_1999_SOUTHEAST VALUES (FL, GA),
18. (SUBPARTITION Q2_1999_NORTHWEST VALUES (OR, WA), 38. SUBPARTITION Q4_1999_NORTHCENTRAL VALUES (SD, WI),
19. SUBPARTITION Q2_1999_SOUTHWEST VALUES (AZ, UT, NM), 39. SUBPARTITION Q4_1999_SOUTHCENTRAL VALUES (OK, TX)
20. SUBPARTITION Q2_1999_NORTHEAST VALUES (NY, VM, NJ), 40. SUBPARTITION Q4_1999_OTHERS VALUES (DEFAULT) TABLESPACE TS5));

especfico de partio. O registro ento mapeado para uma
subpartio dentro dessa partio identificando se o valor da
chave de subparticionamento cai dentro de uma lista especfica.
Como exemplo, considere a insero dos seguintes registros:
( 10, 4532130, 23-Jan-1999, 8934.10 ,WA): ser mapeado para a
subpartio Q1_1999_NORTHWEST;
( 20, 5671621, 15-may1999, 49021.21, OR): ser mapeado para a
subpartio Q2_1999_NORTHWEST;
(30, 9977612, 07-Sep-1999 , 30987.90, FL): ser mapeado para a
subpartio Q3_1999_SOUTHEAST;
(40, 9977612, 29-Nov-1999, 67891.45, TX): ser mapeado para a
subpartio Q4_1999_SOUTHCENTRAL;
(40, 4532130, 5-Jan-2000, 897231.55, TX): no ser mapeado
para nenhuma partio e, consequentemente, para nenhuma
subpartio, resultando em erro;
(50, 5671621, 17-Dec-1999, 76.123.35, CA): ser mapeado para a
subpartio Q4_1999_OTHERS.
Outra caracterstica encontrada no exemplo apresentado na
Listagem 5 a definio da clusula TABLESPACE. possvel
definir esta clusula apenas uma vez na criao da tabela (entre as
linhas 06 e 07, por exemplo), no entanto, isso faria com que todas
as parties e subparties herdassem esta caracterstica e todos
os dados seriam armazenados na mesma tablespace.

Edio 106 SQL Magazine 55

Particionamento no Oracle - Parte 2
Para oferecer um poder de gerenciamento ainda maior, a clu-
sula TABLESPACE pode ser definida no nvel de cada partio
e at mesmo de subpartio.
Sendo assim, todos os dados contidos nas seis primeiras
subparties (linhas 10 a 15) da partio Q1_1999 sero arma-
zenados na tablespace TS1, pois herdaro a tablespace definida
para a partio (linha 09). J os dados contidos na subpartio
Q1_1999_OTHERS sero armazenados na tablespace TS5, pois
a clusula TABLESPACE foi explicitamente definida para esta
subpartio (linha 16).
Perceba ainda que este mesmo tipo de definio foi feito para
todas as parties, onde os dados contidos em cada partio (e
as seis primeiras subparties) sero armazenados em tablespa-
ces especficas, mas as subparties *OTHERS tero seus dados
armazenados na tablespace TS5.
Particionamento Composto range-hash
Os intervalos das parties de uma tabela com particionamento
composto do tipo range-hash so semelhantes aos intervalos de
uma tabela com particionamento no-composto e, da mesma
forma que o particionamento composto range-range e range-list,
podemos definir a tablepace para cada subpartio.
A descrio da funo hash que ser usada para distribuir os da-
dos nas subparties est definida na clusula SUBPARTITION,
e semelhante s parties de tabela com particionamento
no-composto, exceto o nico atributo fsico opcional que
pode ser especificado, tablespace. Subparties herdam todos
os outros atributos fsicos a partir da descrio de partio.
A Listagem 6 apresenta a criao de uma tabela com particio-
namento range-hash.
Observe, na Listagem 6, que a base da criao da tabela con-
tinua sendo a mesma (linhas 01 a 08) e, na linha 09, definido
o tipo do particionamento (range) utilizando a coluna TIME_ID
como chave de particionamento.
A diferena comea na linha 10, em que definido o subpar-
ticionamento, agora do tipo hash, utilizando a coluna CUST_ID
como chave do particionamento e, na linha 11, definida a
quantidade de subparties que sero criadas para armazenar os
dados. Note tambm que foi especificada a clusula STORE IN,
que define em quais tablespaces os dados sero armazenados.
Logo aps (linhas 12 a 17) so definidas as parties. Mas
note um detalhe: as subparties das parties SALES_
Q1_2006 e SALES_Q2_2006 tero seus dados armazenados nas
tablespaces presentes pela clusula STORE IN da definio da
subpartio (linha 11) porm, as subparties das parties
SALES_Q3_2006 e SALES_Q4_2006 tero os dados armazena-
dos em tablespaces prprias, pois houve uma definio explcita
para isso (linhas 15 e 17).
Cada registro ser mapeado para uma partio verificando se
o valor da chave de partio do registro cai dentro de um in-
tervalo especfico de partio. O registro ento mapeado para
uma subpartio dentro dessa partio atravs da definio do
valor hashing da chave de subparticionamento.
56 SQL Magazine Edio 106
Particionamento Composto list-list
A descrio da lista das parties de uma tabela com particiona-
mento composto do tipo list-list so semelhantes s listas de uma
tabela com particionamento no-composto e podemos definir a
tablepace para cada subpartio. A descrio da lista das subparti-
es, nas clusulas SUBPARTITION, semelhante a parties de
tabela com particionamento no-composto, exceto o nico atributo
fsico opcional que pode ser especificado, tablespace. Subparties
herdam todos os outros atributos fsicos a partir da descrio de
partio. A Listagem 7 mostra a criao de uma tabela de contas
(ACCOUNTS) que do tipo list particionada por regio e subpar-
ticionada usando a lista por status da conta.
Listagem 6. Criao da tabela particionada por range-hash.
01. CREATE TABLE SALES
02. (PROD_ID NUMBER(6),
03. CUST_ID
04. TIME_ID
NUMBER,
DATE,
05. CHANNEL_ID CHAR(1),
06. PROMO_ID NUMBER(6),
07. QUANTITY_SOLD NUMBER(3),
08. AMOUNT_SOLD NUMBER(10,2))
09. PARTITION BY RANGE (TIME_ID)
10. SUBPARTITION BY HASH (CUST_ID)
11. SUBPARTITIONS 8 STORE IN (TS1, TS2, TS3, TS4)
12. (PARTITION SALES_Q1_2006 VALUES LESS THAN
(TO_DATE(01-APR-2006,DD-MON-YYYY)),
13. PARTITION SALES_Q2_2006 VALUES LESS THAN
(TO_DATE(01-JUL-2006,DD-MON-YYYY)),
14. PARTITION SALES_Q3_2006 VALUES LESS THAN
(TO_DATE(01-OCT-2006,DD-MON-YYYY))
15. STORE IN (TS5, TS6, TS7, TS8),
16. PARTITION SALES_Q4_2006 VALUES LESS THAN
(TO_DATE(01-JAN-2007,DD-MON-YYYY))
17. STORE IN (TS5, TS6, TS7, TS8));
Listagem 7. Criao da tabela particionada por list-list.
01. CREATE TABLE ACCOUNTS
02. (ID NUMBER,
03. ACCOUNT_NUMBER NUMBER,
04. CUSTOMER_ID NUMBER,
05. BALANCE NUMBER,
06. BRANCH_ID NUMBER,
07. REGION VARCHAR(2),
08. STATUS VARCHAR2(1))
09. PARTITION BY LIST (REGION)
10. SUBPARTITION BY LIST (STATUS)
11. (PARTITION P_NORTHWEST VALUES (OR, WA)
12. (SUBPARTITION P_NW_BAD VALUES (B),
13. SUBPARTITION P_NW_AVERAGE VALUES (A),
14. SUBPARTITION P_NW_GOOD VALUES (G)),
15. PARTITION P_SOUTHWEST VALUES (AZ, UT, NM)
16. (SUBPARTITION P_SW_BAD VALUES (B),
17. SUBPARTITION P_SW_AVERAGE VALUES (A),
18. SUBPARTITION P_SW_GOOD VALUES (G)),
19. PARTITION P_NORTHEAST VALUES (NY, VM, NJ)
20. (SUBPARTITION P_NE_BAD VALUES (B),
21. SUBPARTITION P_NE_AVERAGE VALUES (A),
22. SUBPARTITION P_NE_GOOD VALUES (G)),
23. PARTITION P_SOUTHEAST VALUES (FL, GA)
24. (SUBPARTITION P_SE_BAD VALUES (B),
25. SUBPARTITION P_SE_AVERAGE VALUES (A),
26. SUBPARTITION P_SE_GOOD VALUES (G)),
27. PARTITION P_NORTHCENTRAL VALUES (SD, WI)
28. (SUBPARTITION P_NC_BAD VALUES (B),
29. SUBPARTITION P_NC_AVERAGE VALUES (A),
30. SUBPARTITION P_NC_GOOD VALUES (G)),
31. PARTITION P_SOUTHCENTRAL VALUES (OK, TX)
32. (SUBPARTITION P_SC_BAD VALUES (B),
33. SUBPARTITION P_SC_AVERAGE VALUES (A),
34. SUBPARTITION P_SC_GOOD VALUES (G)));
Edio 106 SQL Magazine 57
Particionamento no Oracle - Parte 2
A Listagem 7 mostra que a base da criao da tabela continua
sendo a mesma (linhas 01 a 08) e, na linha 09, definido o tipo do
particionamento (list) utilizando a coluna REGION como chave
de particionamento.
A definio da subpartio comea na linha 10, onde a clusula
SUBPARTITION tambm usa o tipo list onde a coluna STATUS
a chave do particionamento.
As listas para cada partio so definidas nas linhas 11, 15, 19, 23,
27 e 31 enquanto as subparties so definidas nas linhas 12 a 14,
16 a 18, 20 a 22, 24 a 26, 28 a 30 e 32 a 34 tambm do tipo list.
Perceba que no exemplo as subparties so iguais para todas as
parties alterando apenas o nome delas, ou seja, a lista utilizada
nas subparties so as mesmas para todas as parties.
importante ressaltar tambm que as definies de tablespaces
apresentadas nas estratgias anteriores tambm se aplicam aqui,
ou seja, possvel definir uma nica vez qual a tablespace que todas
as parties e subparties utilizaro para armazenar os dados ou
pode-se ainda definir a tablespace no nvel de cada partio.
Concluso
Apresentamos nesta segunda parte desta srie mais algumas
estratgias de particionamento no banco de dados Oracle. Uma
das coisas que a Oracle faz muito bem desenvolver novas e
boas funcionalidades para seu banco de dados e, com certeza, o
particionamento uma delas.
O mais interessante que as estratgias de particionamento no
ficam simplesmente nas trs bsicas (range, list e hash). Temos um
58 SQL Magazine Edio 106
mundo de possibilidades abertas no momento em que temos o
poder de mesclar diferentes estratgias para prover o melhor
gerenciamento e desempenho para o banco de dados.
E no se esquea de que tudo isso totalmente transparente
para a aplicao. O que ocorre por trs de uma consulta pro-
blema do Oracle. Ele apenas lhe garante que retornar os dados
solicitados.
Ricardo Rezende
DBA Oracle certificado pela Oracle University (DBA 9i track e DBA OCP
10g). IBM Certified Database Associate DB2 9. DBA Oracle na IBM do
Brasil em projeto internacional administrando ambiente de produo
de alta criticidade. Consultor independente de Bancos de Dados. Editor
tcnico da revista SQL Magazine. Mestrando em Cincia da Computao
pelo Instituto de Computao da Universidade Estadual de Campinas IC UNICAMP. Docente
no curso de Administrao de Banco de Dados na Dextra Systemas.
Oracle Database Documentation Library: 11g Release 2 (11.2)
http://www.oracle.com/pls/db112/homepage
D seu feedback sobre esta edio! eu
Feedback
s
D
A SQL Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que
sobre e
voc, leitor, acha da revista!
s
ta
edio
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/sqlmagazine/feedback
Seo Banco de Dados/Persistncia
Nesta seo voc encontra artigos banco de dados, SQL ou persistncia
Oracle Scheduler
Parte 2
Primeiros exemplos prticos
Este artigo faz parte de um curso
O
Oracle Scheduler um utilitrio do banco
de dados Oracle disponvel tanto na verso
Standard Edition One quanto na Standard
Edition e, claro, na Enterprise Edition. Ele permite que
o gerenciamento das mais variadas tarefas seja feito de
forma eficaz e inteligente.
No Oracle Scheduler o agrupamento de tarefas atravs
de classes, limitao de recursos para cada tipo de classe
de tarefas, criao de janelas de execuo de tarefas e ou-
tras funcionalidades esto disponveis fazendo com que
ele no seja simplesmente um agendador de tarefas.
Atravs dele possvel executar desde cdigos de
banco de dados, como stored procedures ou packages,
at programas executveis no sistema operacional,
como shell scripts (no UNIX) ou arquivos de lote
(batch) e ainda arquivos executveis no Windows (os
famosos .exe).
A sofisticao do Oracle Scheduler to impressionan-
te que, alm de permitir que as tarefas sejam executadas
com base em um evento pr-determinado, este evento
pode ser pura e simplesmente a chegada de um arqui-
vo no sistema operacional, ou seja, o Oracle Scheduler
transcende os limites do banco de dados oferecendo
uma poderosa ferramenta para os DBAs e tambm para
as aplicaes.
Assim, sempre que se pretende automatizar tarefas
no Banco de Dados necessrio que haja um bom
gerenciador para que estas tarefas sejam iniciadas em
momentos adequados e no interfiram na execuo de
outras tarefas. justamente para este tipo de situao
que o Oracle Scheduler se mostra muito til.
Neste contexto, sero apresentados neste segundo ar-
tigo desta srie os conceitos de mais alguns objetos do
Scheduler e j sero iniciados alguns exemplos em que
ser colocada efetivamente a mo na massa.
Resumo DevMan
De que se trata o artigo:
Esta o segundo artigo de uma srie que trata da funcionalidade de
agendamento de tarefas no banco de dados Oracle atravs da ferramenta
Oracle Scheduler. O Oracle Scheduler permite que o gerenciamento de
tarefas seja feito de forma eficaz e inteligente. Neste artigo comearemos
a ver na prtica como trabalhar com esta facilidade.
Em que situao o tema til:
O conhecimento sobre como utilizar o Oracle Scheduler extrema-
mente til quando desejamos realizar a automatizao de tarefas no
banco de dados que muitas vezes so repetitivas e tornam a atividade
de administrao do SGBD repetitiva e propensa a erros. Alm disso,
fundamental quando precisamos iniciar tarefas em horrios adequados
que no interfiram nas atividades dirias da organizao.
Oracle Scheduler: Muito mais que um simples agendador de tarefas:
Este artigo apresentar inicialmente uma srie de definies importan-
tes sobre o Oracle Scheduler. Sero discutidos assuntos como windows,
sobreposio de windows, groups, destination groups e window group.
Na seguida, apresentaremos uma srie de exemplos prticos sobre o uso
do agendador de tarefas do Oracle.
Windows (Janelas)
As windows so criadas para iniciar jobs ou para alterar a aloca-
o de recursos entre os jobs durante vrios perodos de tempo
do dia, semana, e assim por diante. A window representada por
um intervalo de tempo com incio e fim bem definidos, tal como
das 0:00 s 06:00.
As janelas (windows) so criadas apenas pelo administrador do
Scheduler que, usualmente, o prprio DBA.
As windows trabalham com job classes para controlar a alocao
de recursos. Cada window define o plano de recursos (resource plan)
que ser usado quando a window se abre (fica ativa), e cada job class
define um grupo de consumidores de recursos (resource consumers
group) ou define um servio de banco de dados que pode mapear
Edio 106 SQL Magazine 59
Oracle Scheduler Parte 2
para um resource consumers group. Um job que executado dentro
de uma window tem recursos alocados de acordo com o resource
consumers group da job class e resource plan da window.
Apenas lembrando que resource consumers group e resource plan so
objetos do Oracle database resource manager. O Oracle Database Resource
Manager (Gerenciador de Recursos do Banco de Dados) permite ge-
renciar vrias cargas de trabalho dentro de um banco de dados que
esto lutando por recursos do sistema e do banco de dados.
Quando as decises de alocao de recursos de banco de dados
so deixadas para o sistema operacional, pode-se encontrar os se-
guintes problemas com o gerenciamento de carga de trabalho:
- Sobrecarga excessiva;
- Programao ineficiente;
- Alocao inadequada de recursos;
- Incapacidade de gerenciar recursos especficos do banco de
dados, como execuo paralela e sesses ativas.
O Resource Manager ajuda a resolver esses problemas, permitindo
um maior controle do banco de dados sobre como os recursos
de hardware so alocados. Em um ambiente com vrias sesses
de usurios simultneas que executam tarefas com prioridades
diferentes, todas as sesses no devem ser tratadas de forma igual.
O Resource Manager permite classificar sesses em grupos com
base em atributos de sesso, e em seguida, alocar recursos para
os grupos de uma forma que otimiza a utilizao do hardware
para o seu ambiente de aplicao.
Com o Resource Manager possvel:
- Garantir a determinadas sesses uma quantidade mnima de
CPU, independentemente da carga no sistema e o nmero de
usurios;
- Distribuir CPU disponvel atravs da alocao de percentual de
tempo de CPU para diferentes usurios e aplicaes. Em um Data
Warehouse, uma porcentagem maior pode ser dada a aplicaes
ROLAP (Relational Online Analytical Processing Processamento
Analtico Relacional em Tempo Real) do que para processos
executados em lote (batch);
- Limitar o grau de paralelismo de qualquer operao realizada
por membros de um grupo de usurios;
- Limitar o nmero de servidores paralelos que um grupo de
usurios pode usar. Isso assegura que todos os servidores dis-
ponveis no sejam atribudos a um nico grupo de usurios;
- Criar um pool de sesses ativas. Um pool de sesses ativas
consiste em um nmero mximo especificado de sesses de
usurios autorizados a estar simultaneamente ativas dentro de
um grupo de usurios. Sesses adicionais para alm do mximo
so enfileiradas para execuo, mas pode-se especificar um per-
odo de tempo, aps o qual os trabalhos em fila sero encerrada.
O pool de sesses ativas limita o nmero total de sesses ativas
competindo por recursos, permitindo sesses ativas a fazer um
progresso mais rpido;
- Impedir a execuo de operaes que, segundo as estimativas
do otimizador, sero executadas por um tempo maior do que o
limite especificado;
60 SQL Magazine Edio 106
- Limitar a quantidade de tempo que uma sesso pode ficar
ociosa;
- Permitir que o banco de dados utilize diferentes planos de
recursos (resource plan), com base na mudana de requisitos de
carga de trabalho. possvel alterar dinamicamente o plano de
recursos, por exemplo, de um plano de recursos do dia para um
plano de recursos da noite, sem ter que reiniciar a instncia.
Pode-se tambm agendar uma mudana no plano de recursos
com scheduler.
Veja na Figura 1 um exemplo de como seria a configurao de
windows num dia normal de trabalho do banco de dados.
Figura 1. Configurao de duas windows num dia normal de trabalho
A Figura 1 mostra um dia de trabalho com duas windows. Nesta
configurao, os jobs pertencentes job class que est ligado ao Con-
sumer Group 1 pode utilizar mais recursos no perodo da manh
(Window 1) do que tarde/noite (Window 2). O oposto verdadeiro
para jobs na job class ligada ao Consumer Group 2.
possvel atribuir uma prioridade a cada window. Caso haja
uma sobreposio de windows, a window com a maior prioridade
escolhida em detrimento de outras windows com prioridades
mais baixas. O Scheduler abre e fecha automaticamente as windows
conforme as configuraes de incio e fim de cada window.
Um job pode atribuir um nome a uma window atravs do atributo
SCHEDULE_NAME. O Scheduler, em seguida, inicia o job quan-
do a window aberta. Se uma window j est aberta, e um novo job
criado apontando esta window que j est aberta, o novo job no
ser iniciado at a prxima vez que a window for aberta.
Sobreposio de Windows
Embora a Oracle no recomende, as windows podem se sobre-
postas. Uma vez que apenas uma window pode estar ativa ao
mesmo tempo, as seguintes regras so usadas para determinar
qual a window ativa quando estiverem sobrepostas:
Se windows com mesma prioridade se sobrepuserem, a window
que estiver ativa vai se manter ativa, ignorando a window que
tentar se sobrepor ativa. No entanto, se a sobreposio com
uma window de maior prioridade, a window de menor prioridade
ser fechada e a window com a maior prioridade ser aberta. Jobs
atualmente em execuo em uma window de baixa prioridade
podero ser interrompidos, dependendo da configurao do job
no momento de sua criao;
Se, no final de uma window, existem vrias windows definidas, a
window com a prioridade mais elevada aberta. Se todas as windows
tm a mesma prioridade, a window que
tem o maior percentual de tempo restante
(tempo restante em relao ao tempo total
da window) aberta.
Uma window que est aberta e excluda
ser fechada automaticamente.
Sempre que duas window se sobrepem,
ser gravada uma entrada no log do
Scheduler.
A Figura 2 mostra um exemplo tpico
de como as windows, os resource plans e
prioridades podem ser determinadas
para um horrio de 24 horas. Considere
que Window 1 est associada com Resource
Plan 1, Window 2 com Resource plan 2, e
assim por diante.
Conforme a configurao de windows
apresentada na Figura 2, a seguinte sequn-
cia de acontecimentos ser utilizada:
Das 00:00 s 04:00 => no h windows
abertas, portanto, o resource plan padro
est em vigor;
Figura 2. Configurao de sobreposio de windows num dia normal de trabalho
Figura 3. Configurao de sobreposio de windows num manh normal de trabalho
Das 04:00 s 06:00 => foi atribuda uma
prioridade baixa para a Window 1, mesmo
assim ela ser aberta porque no h win-
dows com prioridade alta. Desta forma, o
Resource Plan 1 est em vigor;
Das 06:00 s 09:00 => Window 3 ser
aberta porque tem uma prioridade maior
do que Window 1 e o Resource Plan 3 entra
em vigor;
Das 09:00 s 11:00 => Mesmo que a Win-
dow 1 tenha sido fechada s 06:00 devido
a abertura da Window 3 (prioridade mais
alta), s 09:00 a Window 3 fechada e a
Window 1 ainda tem duas horas restantes
em sua programao original. Por isso, a
Window 1 ser reaberta para estas duas
horas restantes e o Resource Plan 1 estar
em vigor novamente;
Das 11:00 s 14:00 => o Resource Plan pa-
dro est em vigor porque no h windows
abertas;
Das 14:00 s 15:00 => Window 2 ser aber-
ta e o Resource Plan 2 estar em vigor;
Das 15:00 s 20:00 => Window 4 tem a
mesma prioridade que a Window 2, ento
a Window 2 no interrompida e o Resource
Plan 2 continua em vigor;
Das 20:00 s 22:00 => a Window 4 ser aber-
ta e o Resource Plan 4 entrar em vigor;
De 22:00 s 00:00 => o Resource Plan pa-
dro est em vigor porque no h windows
abertas.
A Figura 3 mostra outro exemplo de
windows sobrepostas e as consequncias
em relao aos resource plans e prioridades.
Novamente, considere que Window 1 est
associada com Resource Plan 1, Window 2
com Resource plan 2, e assim por diante.
Conforme a configurao de windows
apresentada na Figura 3, a seguinte sequn-
cia de acontecimentos ser utilizada:
Das 00:00 s 04:00 => o Resource Plan
padro est em vigor;
Das 04:00 s 06:00 => foi atribuda prio-
ridade baixa para a Window 1, mas ela se
abre porque no h windows de prioridade
alta definidas neste mesmo momento e,
consequentemente, o Resource Plan 1 entra
em vigor;
Das 06:00 s 09:00 => Window 3 ser
aberta porque tem uma prioridade maior
do que Window 1. Perceba que Window 6
no ser aberta, pois outra window com
prioridade alta j est aberta e o Resource
Plan 3 estar em vigor;
Das 09:00 s 11:00 => s 09:00, Window 5
ou Window 1 so as duas possibilidades
presentes. Ambas tm prioridade baixa,
ento a escolha feita com base na que tem
um percentual maior de tempo restante.
Window 5 tem maior percentual de tempo
restante em comparao com percentual
restante para Window 1. A Window 5 tem
66% de tempo restante (duas horas de um
total de trs horas das 08:00 s 11:00) en-
quanto que a Window 1 tem apenas 28,6%
de tempo restante (duas horas de um total
de sete horas das 04:00 s 11:00). Portanto,
o Resource Plan 5 estar em vigor.
Groups (Grupos)
Um grupo define uma lista de objetos do
Scheduler. Em vez de passar uma lista de
objetos como argumentos para um procedure
do pacote DBMS_SCHEDULER, possvel
Edio 106 SQL Magazine 61
Oracle Scheduler Parte 2
criar um grupo que tem esses objetos Tarefa
como seus membros e, em seguida, pas- Criar um job
Alterar um job
sar o nome do grupo para o procedure.
Executar um job
Existem trs tipos de grupos:
Copiar um job
Grupos de bancos de dados de
Excluir um job
destino: os membros destes grupos Parar um job
so, na verdade, destinos de banco Desabilitar um job DISABLE
de dados para a execuo de jobs em Habilitar um job ENABLE
banco de dados remotos; Tabela 1. Procedures e privilgios necessrios para execuo de tarefas com jobs
Grupos de destinos externos: os
membros destes grupos so destinos externos, para a execuo
de jobs externos em bancos de dados remotos;
Grupos de window: os membros destes grupos so windows do
Scheduler.
Todos os membros de um grupo devem ser do mesmo tipo e
cada membro deve ser exclusivo. Para cria um grupo usado o
procedure DBMS_SCHEDULER.CREATE_GROUP.
Destination Groups (Grupos de Destino)
Quando necessrio que um JOB seja executado em vrios desti-
nos, cria-se um grupo de destino de banco de dados (database desti-
nation group) ou grupo de destino externo (external destination group)
e define-se o nome do grupo ao atributo DESTINATION_NAME
do job. Esta a nica forma vlida para especificar vrios destinos
para o job.
Window Group
Os window group so criados apenas pelo administrador do
Scheduler que , normalmente, o DBA.
Pode-se agrupar windows para facilitar o uso em agendamento
de jobs. Se um job deve ser executado durante vrios perodos de
tempo ao longo do dia, semana, e assim por diante, pode-se criar
uma window para cada perodo de tempo, e em seguida, adicione
as windows em um window group. Ento, defina o atributo SCHE-
DULE_NAME do job com o nome deste window group e o job ser
executado durante todos os perodos de tempo especificados pelas
windows no window group.
Por exemplo, caso haja uma window chamada FINAIS_DE_SE-
MANA e uma window chamada NOITE_SEMANA, pode-se
adicionar estas duas windows para um window group chamado
INTERRUPCAO. A equipe de data warehouse poderia, ento,
criar um job para executar consultas de acordo com este window
group durante a semana e finais de semana, quando as consultas
poderiam ter um alto percentual de recursos disponveis.
Se uma window de um window group j est aberta, e um novo job
criado apontando para esse window gropu, o job no iniciado
at que a prxima window no window group se abra.
Consideraes sobre os objetos do Scheduler e seus nomes
O Oracle Scheduler usado atravs da criao e gerenciamento de
um conjunto de objetos Scheduler. Cada objeto Scheduler um objeto
de esquema de banco de dados na forma esquema.nome. Objetos
62 SQL Magazine Edio 106
Procedure Privilgio Necessrio
CREATE_JOB ou CREATE_JOBS CREATE JOB ou CREATE ANY JOB
SET_ATTRIBUTE ou SET_JOB_ATTRIBUTES
RUN_JOB
COPY_JOB
DROP_JOB ALTER ou CREATE ANY JOB ou ser o proprietrio
STOP_JOB
Scheduler seguem as mesmas regras de nomeao que todos os
outros objetos de banco.
A regra de nomenclatura para nomear objetos do Scheduler no
pacote DBMS_SCHEDULER define que, por padro, os nomes de
objetos do Scheduler so em letras maisculas (uppercase), a menos
que eles estejam entre aspas.
Por exemplo, ao criar um job, job_name=>meu_job o mesmo
que job_name=>Meu_Job e job_name=>MEU_JOB, mas dife-
rente de job_name=>my_job. Estas regras de nomenclatura
so seguidas tambm nos casos em que listas de nomes de objetos
Scheduler delimitados por vrgula so usados dentro do pacote
DBMS_SCHEDULER.
Tutorial
Mo na Massa
Agora que o leitor j conhece os principais conceitos do Oracle
Scheduler e seus objetos, iremos iniciar a parte prtica sobre como
lidar com esta ferramenta. A partir de agora e nos prximos arti-
gos da srie sero apresentados, de maneira prtica (mas sem nos
esquecermos dos conceitos) os seguintes tpicos:
Criao, execuo e gerenciamento de jobs;
Criao e gerenciamento de programs para definir jobs;
Criao e gerenciamento de schedules para definir jobs;
Utilizao de eventos para iniciar jobs;
Criao e gerenciamento de job chains;
Priorizao de jobs;
Monitoramento de jobs.
Criao, execuo e gerenciamento de jobs
Um job a combinao de uma agenda (schedule) e um progra-
ma (program), juntamente com quaisquer argumentos adicio-
nais exigidos pelo program. Para executar as tarefas referentes
aos jobs necessrio utilizar os procedures presentes no pacote
DBMS_SCHEDULER, como mostra a Tabela 1.
Criao de Jobs
Para criar um ou mais jobs necessrio usar um dos procedures
DBMS_SCHEDULER.CREATE_JOB ou DBMS_SCHEDULER.
CREATE_JOBS. O procedure CREATE_JOB usado para criar
um nico trabalho. Atravs dele podemos criar diferentes tipos
de jobs que so base em diferentes objetos. possvel ainda criar
vrios trabalhos em uma nica transao utilizando o procedure
CREATE_JOBS.
Para cada job que est sendo criado, necessrio especificar o
tipo do job, uma ao e um cronograma. Opcionalmente, pos-
svel especificar um nome de credential, um nome de destination
ou destination group, uma job clas, e outros atributos. Assim, o
job habilitado, ele automaticamente executado pelo Scheduler
na data e hora marcada. Por padro, os jobs so desativados
quando criados e devem ser habilitados com o procedure DBMS_
SCHEDULER.ENABLE para que seja executado. Pode-se ainda
definir o argumento ENABLED do procedure CREATE_JOB para
TRUE, assim o job est pronto para ser executado automaticamente,
de acordo com a programao definida na criao.
Alguns atributos do job no podem ser definidos com o
procedure CREATE_ JOB e, em vez disso, deve ser definido
com o procedure DBMS_SCHEDULER.SET_ATTRIBUTE. Por
exemplo, para definir o atributo LOGGING_LEVEL para um
job, preciso executar o procedure SET_ATTRIBUTE depois de
executar o CREATE_JOB.
possvel ainda criar um job em outro esquema, especificando o
formato esquema.nome_do_job. O criador de um job , portanto,
no necessariamente o proprietrio do job. O proprietrio do job
o usurio do esquema onde o job foi criado.
A Listagem 1 apresenta a criao de um job chamado ATUALIZA
_SUMARIO_VENDAS que executa o procedure ATUALIZA_
SUMARIO_VENDAS do pacote VENDAS_PKG do esquema
VENDAS para atualizar a tabela de sumrio de vendas.
Listagem 1. Criao do job ATUALIZA_SUMARIO_VENDAS
01. BEGIN
02. DBMS_SCHEDULER.CREATE_JOB (
03. JOB_NAME => ATUALIZA_SUMARIO_VENDAS,
04. JOB_TYPE => STORED_PROCEDURE,
05. JOB_ACTION => VENDAS.VENDAS_PKG.ATUALIZA_SUMARIO_VENDAS,
06. START_DATE => 28-APR-08 19:00:00,
07. REPEAT_INTERVAL => FREQ=DAILY;INTERVAL=2, /* A CADA DOIS DIAS */
08. END_DATE => 20-NOV-08 19:00:00,
09. AUTO_DROP => FALSE,
10. JOB_CLASS => JOBS_ATUALIZACAO_BATCH,
11. COMMENTS => MEU NOVO JOB);
12. END;
13. /
Pelo fato do atributo DESTINATION_NAME no ter sido espe-
cificado, o job executado no banco de dados de origem (local).
O job executado como o usurio que o criou.
O argumento REPEAT_INTERVAL especifica que este job exe-
cutado em dias alternados at alcanar a data e hora de fim. Outra
maneira de limitar o nmero de vezes que um job seja repetido
definir para o atributo MAX_RUNS um nmero positivo.
O job est sempre desativado quando ele criado, por padro. ne-
cessrio habilit-lo com o procedure DBMS_SCHEDULER.ENABLE
antes do Scheduler comear a execut-lo automaticamente.
Os jobs so definidos para serem descartados automaticamente
por padro depois de completar. Definir o atributo AUTO_DROP
para FALSE faz com que o job persista. Perceba que os jobs de
repetio no so auto-excludos a menos que a data de final
de trabalho seja alcanada, o nmero mximo de execues
(MAX_RUNS) seja alcanado, ou o nmero mximo de falhas seja
alcanado (MAX_FAILURES).
Existem vrios modos diferentes de utilizar o procedure CREA-
TE_JOB. Alm de especificar a ao do job e intervalo de repetio
como atributos do job, como mostrado na Listagem 1, tambm
conhecido como especificao do atributos de modo in-line, pos-
svel criar um job que aponta para um program para especificar o
ao do job, um schedule para especificar o intervalo de repetio,
ou mesmo um program e um schedule.
Para criar um job apontando para um program, preciso espe-
cificar um valor para o atributo PROGRAM_NAME no procedure
CREATE_JOB ao criar o job e no especificar valores para JOB_
TYPE, JOB_ACTION, e NUMBER_OF_ARGUMENTS, pois os
mesmos j esto especificados no program em questo.
Para usar um program j existente ao criar um job, o proprietrio
do job deve ser o proprietrio do program ou ter privilgios EXE-
CUTE sobre ele. A Listagem 2 mostra um exemplo de criao de
um job utilizando um program como atributo.
Listagem 2. Criao do job MEU_NOVO_JOB1 informando um program como
atributo.
01. BEGIN
02. DBMS_SCHEDULER.CREATE_JOB (
03. JOB_NAME => MEU_NOVO_JOB1,
04. PROGRAM_NAME => MEU_PROGRAM,
05. REPEAT_INTERVAL => FREQ=DAILY;BYHOUR=12,
06. COMMENTS => DIARIAMENTE A MEIA NOITE);
07. END;
08. /
Perceba, na Listagem 2, que no foram definidos os atributos
JOB_TYPE, JOB_ACTION, e NUMBER_OF_ARGUMENTS, mas
apenas o atributo PROGRAM_NAME (linha 04).
Podemos ainda criar um job que aponte para um schedule pre-
viamente criado e, desta forma, necessrio apenas definir um
valor para o atributo SCHEDULE_NAME e omitir os atributos
START_DATE, REPEAT_INTERVAL e END_DATE.
possvel utilizar qualquer schedule previamente criado, inde-
pendente de propriedade, pois todos os schedules so criados com
acesso a PUBLIC. A Listagem 3 mostra um exemplo de criao de
um job utilizando um schedule como atributo.
Perceba, na Listagem 3, que no foram definidos os atributos
START_DATE, REPEAT_INTERVAL e END_DATE
, mas sim ape-
nas o atributo SCHEDULE_NAME (linha 06).
Um job pode ainda ser criado apontando tanto um program
quanto um schedule. A partir do momento que a empresa tenha um
DBA bastante organizado, com toda certeza essas possibilidades
ajudaro muito na administrao do Scheduler.
Edio 106 SQL Magazine 63
Oracle Scheduler Parte 2

A Listagem 4 apresenta um exemplo em que um job criado e Criao de Credentials

aponta tanto para um program quanto para um schedule. Uma credential um par de nome de usurio e senha arma-
Veja a simplicidade da criao de um job, na Listagem 4, a zenados em um objeto de banco de dados. Uma credential de-
partir do momento em que o program e o schedule j est pre- ver ser atribuda a um job para que ele possa autenticar com
viamente criado. um banco de dados Oracle ou o sistema operacional antes de
executar.
Listagem 3. Criao do job MEU_NOVO_JOB2 informando um schedule como atributo. Para criar uma credential necessrio executar o procedure
1. BEGIN
DBMS_SCHEDULER.CREATE_CREDENTIAL.
2. DBMS_SCHEDULER.CREATE_JOB ( Como apresentado na Tabela 2, necessrio ter o privilgio
3. JOB_NAME => MEU_NOVO_JOB2, CREATE JOB para criar uma credenTial no seu prprio esque-
4. JOB_TYPE => PLSQL_BLOCK,
5. JOB_ACTION => BEGIN ma, e o privilgio CREATE ANY JOB para criar uma credential
VENDAS_PKG.ATUALIZA_SUMARIO_VENDAS; em qualquer esquema, exceto SYS. A credential pode ser usada
END;,
6. SCHEDULE_NAME => MEU_SCHEDULE);
apenas por um job cujo proprietrio tenha privilgios EXECUTE
7. END; na credential ou cujo proprietrio tambm seja o dono da
8. / credential. Pelo fato de uma credential pertencer a um esquema
Listagem 4. Criao do job MEU_NOVO_JOB3 informando um program e um como qualquer outro objeto de esquema, possvel usar a
schedule como atributos. instruo SQL GRANT para conceder os privilgios em uma
1. BEGIN credential.
2. DBMS_SCHEDULER.CREATE_JOB ( A Listagem 5 apresenta a criao de uma credential.
3. JOB_NAME => MEU_NOVO_JOB3,
4. PROGRAM_NAME => MEU_PROGRAM,
5. SCHEDULE_NAME => MEU_SCHEDULE);
6. END; Listagem 5. Criao da credential DW_CREDENTIAL.
7. /
1. BEGIN
2. DBMS_SCHEDULER.CREATE_CREDENTIAL(DW_CREDENTIAL, USUARIODW,
Quando usamos jobs externos, locais ou remotos, ou ainda jobs dW_User!1012);
3. END;
de banco de dados remotos, necessrio especificar as credenciais
4. /
sob as quais o job ser executado. Isso possvel atravs da criao 5.
de uma credential e definindo o atributo CREDENTIAL_NAME 6. GRANT EXECUTE ON DW_CREDENTIAL TO USUARIOVENDA;
do job.
Ainda para jobs externos ou de banco de dados, porm ambos
externos, preciso especificar tambm o destino onde o job deve Veja, na Listagem 5, que a credential DW_CREDENTIAL foi
ser executado e, para isso, pode-se criar um destination e defini-lo criada atravs da procedure CREATE_CREDENTIAL recebendo
no atributo DESTINATION_NAME do job. Um job com um atri- como parmetros: 1) o nome da credential; 2) o nome do usurio e 3)
buto DESTINATION_NAME nulo executado no host onde o job a senha deste usurio (linha 02).
foi criado. A linha 05 mostra tambm que foi concedido o privilgio de
Para executar as tarefas referentes a credentials e destination EXECUTE na credential para o usurio USUARIOVENDA
necessrio utilizar os procedures presentes no pacote DBMS_ portanto, um job criado no esquema USUARIOVENDA poder
SCHEDULER, como mostra a Tabela 2. utilizar este credential sem problema algum.

Tarefa Procedure Privilgio Necessrio

Criar um credential CREATE_CREDENTIAL CREATE JOB ou CREATE ANY JOB
Excluir um credential DROP_CREDENTIAL CREATE ANY JOB ou ser o proprietrio
Criar um external destination No h Veremos adiante
Excluir um external destination DROP_AGENT_DESTINATION MANAGE SCHEDULER
Criar um database destination CREATE_DATABASE_DESTINATION CREATE JOB ou CREATE ANY JOB
Excluir um database destination DROP_DATABASE_DESTINATION CREATE ANY JOB ou ser o proprietrio
Criar um destination group CREATE_GROUP CREATE JOB ou CREATE ANY JOB
Excluir um destination group DROP_GROUP CREATE ANY JOB ou ser o proprietrio
Adicionar membros a um destination group ADD_GROUP_MEMBER ALTER ou CREATE ANY JOB ou ser o proprietrio
Adicionar membros de um destination group REMOVE_GROUP_MEMBER ALTER ou CREATE ANY JOB ou ser o proprietrio

Tabela 2. Procedures e privilgios necessrios para execuo de tarefas com destination e credentials

64 SQL Magazine Edio 106

Criao de Destinations
Um destination um objeto do Scheduler que define um local para
a execuo de um job. Os locais onde um job ser executado so
definidios especificando ou um nico destination ou um destination
group no atributo DESTINATION_NAME do job. Se o atributo
estiver definido como nulo, o job executado no host local (host
onde o job foi criado).
Use external destinations para especificar os locais onde external
jobs remotos sero executados. Use database destinations para es-
pecificar os locais onde os jobs de banco de dados remotos sero
executados.
No necessrio privilgios de objeto para usar um destination
criado por outro usurio. Para criar um external destination ne-
cessrio registrar o agente do Scheduler remoto no banco de dados.
Na verdade, no h um procedure no pacote DBMS_SCHEDULER
para criar um external destination. Ele ser implicitamente criado
atravs do registro do agente no banco de dados.
possvel tambm registrar agentes locais do Scheduler caso haja
mais instncias de banco de dados no mesmo servidor. O nome
do external destination automaticamente definido como sendo o
nome do agente.
Nesta srie de artigos no ser abordada a instalao e configu-
rao de agentes do Scheduler. Para criar um database destination
necessrio executar o procedimento DBMS_SCHEDULER.
CREATE_DATABASE_DESTINATION.
necessrio especificar o nome de um external destination
como argumento do procedure. Isto ir definir o host remoto que
o destination do banco de dados aponta. Pode-se especificar um
nome de servio de rede ou descritor de conexo completo, que
identifica a instncia de banco de dados a ser conectado. Se for
especificado um nome de servio de rede, ele deve ser resolvido
pelo arquivo tnsnames.ora local. Se no for especificada uma
instncia de banco de dados, o agente Scheduler remoto se conecta
ao seu banco de dados padro, que especificado no arquivo de
configurao do agente.
Para criar um database destination, necessrio ter o privilgio
de sistema CREATE JOB. Para criar um database destination em um
esquema diferente, necessrio ter o privilgio CREATE ANY
JOB. A Listagem 6 apresenta a criao do database destination
DBHOST1_ORCLDW.
Listagem 6. Criao do database destination DBHOST1_ORCLDW.
1. BEGIN
2. DBMS_SCHEDULER.CREATE_DATABASE_DESTINATION (
3. DESTINATION_NAME => DBHOST1_ORCLDW,
4. AGENT => DBHOST1,
5. TNS_NAME => ORCLDW,
6. COMMENTS => Instancia ORCLDW no host DBHOST1);
7. END;
8. / Porm, ainda possvel adicionar um membro ao destination
Apenas alguma consideraes referentes ao database destination
criado na Listagem 6:
O agente do Scheduler j est instalado no host remoto dbhost1,
e o agente j foi registrado no banco de dados local;
O arquivo de configurao do agente no foi modificado para
definir o nome do agente. Por isso o nome do agente e do external
destination foram definidos como o padro, que DBHOST1;
O host local possui o descritor de conexo no tnsnames.ora para
a instncia de banco de dados chamada ORCLDW, que reside
no host remoto dbhost1. E o nome de servio de rede (alias) est
definido como ORCLDW para este descritor de conexo.
Pode-se ainda criar um job que ser executado em vrios destinos.
Para isso, necessrio criar um destination group e definir esse grupo
no atributo DESTINATION_NAME do job. possvel especificar
os membros do grupo (destinations) ao criar o grupo, ou pode-se
adicionar os membros do grupo em um momento posterior.
Para criar um destination group preciso executar o procedure
DBMS_SCHEDULER.CREATE_GROUP.
Para o caso de remote external jobs preciso especificar um group
do tipo EXTERNAL_DEST e todos os membros do group devem
ser external destinations. E para remote database jobs, deve-se espe-
cificar um group do tipo DB_DEST e todos os membros devem
ser database destinations.
Os membros de destination groups devem considerar o seguinte
formato: [[esquema.]credential@][esquema.]destination . Neste caso,
credential o nome de uma credential j existente e destination o
nome de um database destination ou um external destination vlidos.
Ainda, credential do membro de um destination opcional, mas
caso no seja definido o job utilizar a credential padro.
possvel incluir um outro group do mesmo tipo como um
membro de um destionation group.
Caso seja necessrio que o host local seja um dos muitos
destionations em que um job seja executado, preciso incluir a
palavra-chave LOCAL como um membro do group para qualquer
tipo de destination group. LOCAL pode ser precedida por uma
credential apenas num external destionation group.
Um group de propriedade do usurio que o criou. necessrio
ter o privilgio de sistema CREATE JOB para criar um group no
seu prprio esquema, e o privilgio de sistema CREATE ANY JOB
para criar um group em outro esquema.
A Listagem 7 apresenta a criao do database destination group
VARIOS_BDS e tambm a adio de um novo membro ao group.
A primeira parte da Listagem 7 (linhas 01 a 08) apresenta a
criao do database destination group chamado VARIOS_BDS.
Perceba que o tipo do group foi definido como DB_DEST (linha
04), pois se trata de um database destination. Veja tambm que
trs destinations foram definidos como membros deste destination
group j no momento da criao (destionations ORCL, ORCLDW e
LOCAL linha 05).
group aps a sua criao, e exatamente isso que foi feito na
segunda parte da Listagem 7 (linhas 10 a 15), onde o database
destionation ORCLDW2 foi adicionado ao destination group
VARIOS_BDS (linha 13).
Edio 106 SQL Magazine 65
Oracle Scheduler Parte 2

Listagem 7. Criao do database destination group VARIOS_BDS e adio de novo Scheduler. Entretanto, a utilizao de todos (ou a maioria deles)
membro. facilitar muito a tarefa de administrao do banco de dados e
01. BEGIN do Scheduler em si.
02. DBMS_SCHEDULER.CREATE_GROUP(
03. GROUP_NAME => VARIOS_BDS, Listagem 8. Criao de um job que ser executado em vrias instncias de banco
04. GROUP_TYPE => DB_DEST,
de dados.
05. MEMBER => OLTP_ADMIN@ORCL, ORCLDW1, LOCAL,
06. COMMENTS => VARIOS BANCOS DE DADOS GERENCIADOS POR MIM);
07. END; 01. SELECT OWNER, GROUP_NAME, GROUP_TYPE, NUMBER_OF_MEMBERS
08. / 02. FROM ALL_SCHEDULER_GROUPS
09. 03. WHERE GROUP_TYPE=DB_DEST
10. BEGIN 04. OR GROUP_TYPE = EXTERNAL_DEST;
11. DBMS_SCHEDULER.ADD_GROUP_MEMBER( 05.
12. GROUP_NAME => VARIOS_BDS, 06. OWNER GROUP_NAME GROUP_TYPE NUMBER_OF_MEMBERS
13. MEMBER => DW_ADMIN@ORCLDW2); 07. --------------- --------------------- ----------------------- -------------------------------
14. END; 08. DBA1 VARIOS_DBS DB_DEST 4
15. / 09. DBA1 VARIOS_HOSTS EXTERNAL_DEST 4
10.
11. BEGIN
12. DBMS_SCHEDULER.CREATE_CREDENTIAL(DBA_CREDENTIAL, DBA1,
Ainda no assunto sobre destionations, possvel criar um job SYS040533);
13. DBMS_SCHEDULER.CREATE_JOB (
que ser executado em vrios destinations, mas que gerenciado 14. JOB_NAME => JOB_MANUTENCAO,
a partir de um nico local. Uma razo comum de fazer isso 15. JOB_TYPE => STORED_PROCEDURE,
16. JOB_ACTION => PROCEDURE_MANUTENCAO,
executar um job de manuteno de banco de dados em todos os 17. START_DATE => 15-JUL-09 23:00:00,
bancos de dados administrados pelo DBA. Em vez de criar o job 18. REPEAT_INTERVAL => FREQ=DAILY,
19. CREDENTIAL_NAME => CREDENCIAL_DBA,
em cada banco de dados, cria-se o job uma vez e define-se vrios 20. DESTINATION_NAME => VARIOS_DBS);
destinations para o job. A partir do banco de dados onde o job foi 21. END;
22. /
criado (o banco de dados local), possvel monitorar o estado e os
resultados de todas as instncias do job em todos os locais.
Para criar um job que seja executado em vrios destinations ne- Neste artigo j comeamos a colocar a mo na massa atravs de
cessrio executar o procedure DBMS_SCHEDULER.CREATE_JOB e exemplos de utilizao do Scheduler. J ficou claro o grande poten-
definir como valor do atributo DESTINATION_NAME o nome de cial desta ferramenta e as inimaginveis opes de utilizao.
um database destination group ou o nome de um external destination Tenho certeza que o leitor j deve estar pensando nos seus bancos
group. de dados e analisando potenciais usos desta ferramenta.
Mas ateno, pois se nem todos os membros do destination group Apenas o fato de termos a possibilidade de executar no apenas
incluem o esquema na credential, uma credential padro ser usada cdigos do banco de dados (como stored procedures), mas tambm
para o job. Alm disso, tenha certeza que a palavra-chave LOCAL programas externos (scripts shell, arquivos de lote .bat e at mes-
esteja presente como membro do destination group para que o job mo executveis do MS Windows .exe) ampliam os horizontes do
seja executado tambm localmente (se esta for a inteno). banco de dados de maneira grandiosa.
A Listagem 8 apresenta a criao de um job que ser executado E mais ainda, a possibilidade de centralizar todos os seus jobs em
em vrias instncias de banco de dados. uma nica instncia de banco de dados e, a partir dela, executar
A consulta apresentada na primeira parte da Listagem 8 (linhas o job em diferentes instncias de banco de dados at mesmo em
01 a 04) foi feita para verificar quais os destinations disponveis, servidores diferentes amplia ainda mais os horizontes do DBA.
onde foram encontrados dois destinations (linhas 06 a 09) sendo
um deles um database destionation (linha 08) e o outro um external Ricardo Rezende
destionation (linha 09), ambos com quatro membros cada. DBA Oracle certificado pela Oracle University (DBA 9i track e DBA OCP
A segunda parte da Listagem 8 (linhas 11 a 22) a criao do job 10g). IBM Certified Database Associate DB2 9. DBA Oracle na IBM do
em si. Inicialmente criada uma credential (linha 12) e, na criao Brasil em projeto internacional administrando ambiente de produo
do job definida qual a credential que ser usada (linha 19) e qual de alta criticidade. Consultor independente de Bancos de Dados. Editor
o destionation. Perceba que o destionation usado no apenas um tcnico da revista SQL Magazine. Mestrando em Cincia da Computao
destination, mas sim um destination group e, portanto, o job ser pelo Instituto de Computao da Universidade Estadual de Campinas IC UNICAMP. Docente
no curso de Administrao de Banco de Dados na Dextra Systemas.
executado em todos os membros deste destination group.

Concluso D seu feedback sobre esta edio! eu

Feedback
s
D

Nesta segunda parte desta srie de artigos sobre o Oracle A SQL Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que
sobre e

Scheduler vimos os conceitos de mais alguns objetos presentes voc, leitor, acha da revista!
s

ta
edio

nesta funcionalidade do banco de dados Oracle. Perceba que

D seu voto sobre este artigo, atravs do link:
so vrios os objetos e tambm que nem todos so efetivamente
www.devmedia.com.br/sqlmagazine/feedback
obrigatrios para que possamos ter uma boa utilizao do

66 SQL Magazine Edio 106

Edio 106 SQL Magazine 67
Oracle Scheduler Parte 2

68 SQL Magazine Edio 106