Você está na página 1de 111

ndice

Utilizando UML: Diagramas de Implantao, Comunicao e Tempo ............................................................ 3 Desafio SQL ................................................................................................................................................16 Alta Disponibilidade no SQL Server 2005/2008............................................................................................22 Compactao de Dados com o SQL Server 2008 ..........................................................................................41 Gerenciando Usurios e Permisses no PostgreSQL ....................................................................................55 Desvendando o Oracle Data Integrator .......................................................................................................71 Oracle RAC Instalao - Parte 2 .................................................................................................................101

Utilizando UML: Diagramas de Implantao, Comunicao e Tempo


Paulo Csar Barreto da Silva Graduado em Anlise de Sistemas pelo Centro Universitrio Salesiano de So Paulo e Ps graduado pela Universidade Estadual de Campinas na rea de Orientao a Objetos. De que trata o artigo: Este artigo apresenta trs dos 13 diagramas propostos pela UML na verso 2.0, os Diagramas de Implantao, Comunicao e Tempo. Para que serve: Os diagramas apresentados neste artigo permitem a ilustrao das atividades relacionadas ao produto de software em suas etapas de desenvolvimento e validao de lgica. Em que situao o tema til: A utilizao destes diagramas est amplamente associada etapa de anlise e projeto, principalmente na modelagem dos comportamentos esperados pela implementao do sistema. No oitavo artigo da srie Utilizando a UML, apresentaremos mais trs dos 13 diagramas descritos na especificao 2.0 da UML, completando assim a srie de artigos que descreveu todos os diagramas da UML 2.0. Em nosso ltimo artigo, tratamos dos Diagramas de Interao Geral, Componentes e Pacotes indicados por muitos autores como mtodo de especificao e documentao das etapas de modelagem de soluo e implementao. No presente artigo, vamos tratar de trs Diagramas bastante conhecidos na verso 2.0 da UML: os Diagramas de Implantao, Comunicao e Tempo. Entre as verses 1.5 e 2.0 da UML, diversas alteraes/evolues foram realizadas. Os trs diagramas que iremos abordar ao longo deste artigo so resultados ntidos de tal evoluo da UML, como veremos a seguir. O Diagrama de Implantao determina as necessidades de hardware do sistema, as caractersticas fsicas como servidores, estaes, topologias e protocolos de comunicao, ou seja, todo o aparato fsico sobre o qual o sistema dever ser executado. Os Diagramas de Componentes e de Implantao so bastante associados, podendo ser representados em separado ou em conjunto. O Diagrama de Comunicao era conhecido como Diagrama de Colaborao at a verso 1.5 da UML, tendo seu nome modificado para Diagrama de Comunicao a partir da verso 2.0. Este Diagrama est amplamente associado ao Diagrama de Seqncia. Na verdade, um complementa o outro. O Diagrama de Tempo a fuso do Diagrama de Seqncia e Estado apresentando o comportamento dos objetos e sua interao em uma escala de tempo, ou seja, o estado dos objetos em relao ao tempo e s mensagens que modificam esse estado. Estes trs diagramas permitem na etapa anlise e projeto modelar com bastante clareza os comportamentos e a implementao do modelo a ser desenvolvido. Neste artigo, vamos falar um pouco da definio, da sua utilizao e principalmente dos aspectos de produtividade que fazem desses diagramas, importantes ferramentas na etapa de projeto e desenvolvimento. O Diagrama de Implantano O Diagrama de Implantao o diagrama com a viso mais fsica da UML (GUEDES, 2007). Este diagrama foca a questo da organizao da arquitetura fsica sobe a qual o software ir ser implantado e executado em termos de hardware, ou seja, as mquinas (computadores pessoais, servidores etc.) que suportam o sistema, alm de definir como estas mquinas sero conectadas e por meio de quais protocolos se comunicaro e transmitiro as informaes. Os elementos bsicos deste diagrama so os Ns, que representam os componentes, Associaes entre Ns, que so as ligaes entre os Ns do diagrama, e os Artefatos, representaes de entidades fsicas do mundo real. Veremos cada um dos componentes que compem o Diagrama de Implantao a seguir.

Ns Ns so componentes fundamentais do Diagrama de Implantao. Um n pode ilustrar um item de hardware, como um servidor em que um ou mais mdulos do software so executados ou que armazene arquivos consultados pelos mdulos do sistema, ou pode representar um ambiente de execuo, ou seja, um ambiente que suporta o sistema de alguma forma. Ns podem conter outros ns, sendo comum encontrar um n que representa um item de hardware contendo outro n que representa um ambiente de execuo, embora n que represente um item de hardware possa conter outros ns representando itens de hardware, e um n que represente um ambiente de execuo possa conter outros ambientes de execuo. Quando um n representa um hardware, deve possuir o esteretipo <<device>>; quando, porm, um n representa um ambiente de execuo, pode utilizar o esteretipo <<ExecutionEnvironment>>. A Figura 1 apresenta exemplo de utilizao de n para representar um item de hardware. Outros exemplos de ambientes de execuo so os sistemas operacionais ou sistemas e banco de dados. Os esteretipos so um dos trs mecanismos de extenso da UML. Eles do mais poder UML, permitindo classificar elementos "com algo em comum" (Wikipdia). Associao entre Ns Os Ns possuem ligaes fsicas entre si de forma que possam se comunicar e trocar informaes. Essas ligaes so chamadas associaes e so representadas por retas ligando um N a outro. Uma associao pode conter esteretipos utilizados para determinar, por exemplo, o tipo de protocolo e comunicao utilizado entre os ns (ver Figura 2). A Figura 2 demonstra um exemplo de associao entre o N que representa o Servidor de Comunicao e o N que representa o Servidor de Firewall. O protocolo de comunicao descrito na Associao como um esteretipo <<TCP/IP>>. Figura 1. Exemplo de N (GUEDES, pg. 162, 2007)

Figura 2. Exemplo de associao entre Ns (GUEDES, pg. 162, 2007)

Exemplo de Diagrama de Implantao Os Diagramas de Implantao so conhecidos, principalmente, pela sua simplicidade e facilidade de compreenso. Como facilitador, apresentaremos um exemplo de Diagrama de Implantao referente arquitetura fsica necessria para suportar um Sistema de Controle de Submisses (ver Figura 3). O exemplo apresentado na Figura 3 o mesmo modelado na edio 67 da SQL Magazine. O sistema que estamos modelando representa um processo de submisso de artigos edio de um peridico. A Figura 3 demonstra as associaes existentes entre os vrios Ns, que representam cada um dos hardwares existentes na arquitetura de implantao do sistema. Atravs deste diagrama, notamos que

a comunicao entre o N Hardware do Autor, equipamento utilizado pelo autor para desenvolver o artigo, e o N Servidor de Aplicao I, equipamento instalado do lado do servidor onde a aplicao Sistema de Controle de Submisses est instalada, passa pelos Ns Servidor de Comunicao, equipamento que garantir a boa performance e zelar pela transmisso e recepo dos dados, e Servidor de Firewall, responsvel pela proteo da arquitetura do sistema. Podemos notar que aps a comunicao com o N Servidor de Aplicao I, h a comunicao com os Ns Servidor de Banco de Dados, onde ocorre a persistncia e gesto dos dados do sistema, e o N Servidor de Aplicao II, que neste contexto representa um modelo de balanceamento ou de administrao de sistemas de apoio, como por exemplo, ferramentas de controle administrativo. Podemos obter tambm atravs da leitura deste diagrama (ver Figura 3) o Protocolo de comunicao adotado entre os vrios Ns, representado pelo esteretipo <<TCP/IP>>. A Figura 4 apresenta o Diagrama de Componentes (ler Nota DevMan 1) equivalente aos mdulos executveis do Sistema de Controle de Submisses que estamos modelando. Alguns mdulos no so exatamente executveis, como o caso do componente que representa a pgina de submisso de artigos, ou pertencem exclusivamente ao sistema, como o componente que representa o Sistema Gerenciador de Banco de Dados, mas so indispensveis para o funcionamento do mesmo. Nota do Devman
Na edio 67 da SQL Magazine, apresentamos o Diagrama de Componentes. O Diagrama de Componentes, como o prprio nome sugere, apresenta a identificao dos componentes que compem um sistema, subsistema ou mesmo componentes ou classes internas de um componente individual. Para maiores detalhes, leia os artigos anteriores da srie Utilizando UML.

Figura 3.

Exemplo de Diagrama de Implantao (adaptado Guedes, 2007)

Figura 4.

Diagrama de Componentes do Sistema de Controle de Submisses (adaptado de GUEDES, 2007)

Podemos observar a utilizao dos relacionamentos entre componentes por meio de Interfaces Fornecidas e Requeridas, onde podemos notar, por exemplo, que o componente Sistema de Gerenciamento de Banco de Dados Interface Fornecida por outros oito componentes: Gerenciador de Login, Gerenciador de Submisses do Autor, Cadastro de Avaliadores, Cadastro de Temas, Gerenciador de Avaliaes, Relatrio de Avaliaes, Notificao de Autor e Gerenciador de Submisses do Coordenador. O componente Pgina Eletrnica de Submisso de Artigos o componente inicial deste diagrama. Percebemos isso porque atravs dele que o Submissor tem o acesso a executar o componente Controlador de Submisses. O componente Controlador de Submisses Interface Provida pelo componente Pgina Eletrnica de Submisso de Artigos, e Interface Requerida para os componentes Gerenciador de Login e Gerenciador de Submisses do Autor. Artefatos Um artefato uma entidade fsica, um elemento concreto que existe realmente no mundo real, assim como os ns que o suportam. Um artefato pode ser um arquivo fonte, um arquivo executvel, um arquivo de ajuda, um documento de texto etc. Um artefato deve estar implementado em um N. Na Figura 5 apresentado um exemplo de Artefato implementado em um N. Na Figura 5 podemos notar que o artefato denominado Mdulo Gerenciador de Login possui a mesma denominao que um dos componentes apresentados na Figura 4. Na verdade, um artefato muitas vezes uma manifestao no mundo real de um componente. No entanto, no necessariamente existir um artefato de cada componente, sendo possvel existirem diversos artefatos manifestados a partir de um nico componente. A Figura 6 demonstra um exemplo de artefato instanciado a partir de um componente. Observe que existe um relacionamento de dependncia entre o componente e o artefato, contendo o esteretipo <<manifest>>, significando que o artefato uma representao do componente do mundo real.

Figura 5. Exemplo de Artefato implementado em um N

Figura 6. Exemplo de Artefato manifestado a partir de um Componente Outra forma de manifestar um artefato contido em um N, segundo Guedes em seu livro UML Guia Prtico, utilizar um relacionamento de dependncia, contendo o esteretipo <<deploy>> entre o n e os artefatos (ver Figura 7). Um N pode conter componentes da mesma forma que artefatos, como uma maneira de demonstrar em que lugar os componentes podero ser localizados no hardware que suportar o sistema. Especificao de Implantao A Especificao de Implantao especifica um conjunto de propriedades que determinam parmetros de execuo de um artefato implementado em um N (ver Figura 8). A Figura 8 demonstra a Especificao de Implantao do artefato Modulo.jar. O arquivo Mdulo.xml o conjunto de propriedade que descreve o parmetros que o artefato Modulo.jar implementado na aplicao Sistema de Controle de Submisses. Diagrama de Comunicao O Diagrama de Comunicao era conhecido como Diagrama de Colaborao at a verso 1.5 da UML, tendo o seu nome modificado para Diagrama de Comunicao a partir da verso 2.0 da UML. Esse diagrama est amplamente associado ao diagrama de seqncia - na verdade, um complementa o outro. As informaes mostradas no Diagrama de Comunicao so, com freqncia, praticamente as mesmas apresentadas no Diagrama de Seqncia (ler Nota DevMan 2), porm com um enfoque diferente, visto que este diagrama no se preocupa com a ordem temporal dos processos, concentrando-se em como os objetos esto vinculados e quais mensagens trocam entre si durante o processo.

Figura 7. Artefato implementado em um N (adaptado de GUEDES, 2007)

Figura 8. Especificao de Implantao Nota do Devman No artigo publicado na edio 64 da SQL Magazine, abordamos a definio e a estrutura do Diagrama de Seqncia. O Diagrama de Seqncia serve para representar a ordem temporal em que as mensagens so trocadas entre os objetos envolvidos em determinado processo. Um diagrama de seqncia mostra a colaborao dinmica entre os vrios objetos de um sistema Por ser muito semelhante ao Diagrama de Seqncia, o Diagrama de Comunicao utiliza muitos de seus elementos, como atores e objetos, incluindo seus esteretipos de fronteira e controle. No entanto, os objetos no Diagrama de Comunicao no possuem linhas de vida. Alm disso, esse diagrama no suporta ocorrncias de interao ou fragmentos combinados como o Diagrama de Seqncia, por isso utilizado para a modelagem de processos mais simples. Da mesma forma que o Diagrama de Seqncia, um Diagrama de Comunicao enfoca um processo, normalmente baseado em um Caso de Uso. As semelhanas entre ambos so to grandes que existem at mesmo ferramentas CASE capazes de gerar um dos diagramas a partir do outro. Atores Os atores so os mesmos descritos no Diagrama de Casos de Uso (ler Nota DevMan 3) e Diagrama de seqncia, ou seja, descreve entidades externas que interagem com o sistema, solicita servios e gera, dessa forma, eventos que iniciam processos. Normalmente representa usurios que interagem com o sistema e outros softwares, como um sistema integrado ou um hardware especfico. Atores so representados por bonecos magros idnticos aos usados no Diagrama de Casos de Uso. Nota do Devman No artigo publicado na edio 62 da SQL Magazine, apresentamos a definio e a forma de utilizao do diagrama de casos uso.

Objetos Os objetos representam as instncias das classes que esto envolvidas no processo descrito pelo diagrama de seqncia. Os objetos so representados com um retngulo contendo um texto que identifica primeiramente o nome do objeto, em minsculo, e depois o nome da classe, com letras iniciais maisculas, a qual o objeto pertence. As duas informaes so separadas por dois pontos (:). Mensagens Como comentamos, o Diagrama de Comunicao se preocupa com o relacionamento entre os objetos envolvidos em um processo, e isto feito principalmente por meio de mensagens. Uma mensagem causada por um evento e pode conter uma descrio, uma chamada de um mtodo ou ambos. Mensagens podem ainda conter condies de guarda, bastante teis neste diagrama. Para que possa ser enviada uma mensagem de um componente necessrio haver uma associao entre os componentes. Aps existir a associao, pode-se ento acrescentar mensagens a ela. Uma mensagem se caracteriza por conter uma seta apontando ao objeto para o qual est sendo enviada (ver Figura 9). O Controlador_Congresso, representado por um smbolo em forma de circulo com uma seta includa, uma Control Class (Classes de Controle geralmente so as classes que conectam as classes de interface s classes do domnio).

Figura 9. Exemplo de Mensagem entre componentes Autochamada Um objeto pode disparar uma mensagem em si prprio, o que conhecido como auto-chamada, onde a mensagem parte do objeto e retorna ao prprio objeto. A Figura 10 apresenta um exemplo de autochamada em um objeto. A Figura 10 demonstra o envio de uma mensagem do objeto autor1 para si prprio, solicitando o disparo do mtodo ValCpf() responsvel pela validao do CPF. Esta instncia da classe Autor est contida no processo de submisso de artigos como um mtodo de validao da informao de CPF do autor do artigo. Condies de Guarda e Iteraes Condies de Guarda so textos entre colchetes que estabelecem condies ou validaes para que uma mensagem possa ser enviada. J Iteraes representam uma situao em que uma mensagem pode ser enviada vrias vezes, correspondendo muitas vezes a um lao de repetio. As iteraes so representadas por um asterisco (*) na frente da mensagem e em geral vm apoiadas por Condies de Guarda. Uma vez que o Diagrama de Comunicao no suporta fragmentos combinados, muitas vezes necessrio lanar mo desse artifcio para representar situaes opcionais ou laos. Um exemplo apresentado na Figura 11. Na Figura 11 observamos a utilizao da Condio de Guarda e Iterao no processo de ordenao das submisses em relao instncia da classe Edicao. O processo se inicia com a validao das informaes de acesso do Ator Editor_Chefe e em seguida pela execuo do processo de ordenao. Esta Condio de Guarda e Iterao representa que para cada submisso uma ordem ser definida e isso ocorre enquanto houver submisses a serem ordenadas.

Figura 10. Exemplo de Autochamada (adaptado de GUEDES, pg. 242, 2009)

Figura 11. Exemplo de Condio de Guarda e Iterao (adaptado de GUEDES, 2009) O responsvel por esta atividade o mtodo DefOrd(ord), recebe como parmetro ordem desta submisso dentro da edio, da classe Edicao estimulado/executado pela instancia da classe Editor. Modelando Diagrama de Comunicao para o Sistema de Controle de Submisses A partir de agora, iremos demonstrar a continuao da modelagem do Sistema de Controle de Submisses, citado anteriormente e descrito no artigo anterior desta srie. Os diagramas seguintes correspondem aos mesmos processos apresentados na Figura 4, que demonstra o Diagrama de Componentes. A Figura 12 demonstra o processo de Login do Submissor atravs do Diagrama de Comunicao. O processo de Login do Submissor executado com o objetivo de validar suas informaes de acesso, e em seguida executar a atividade de ordenao das submisses realizadas pelos autores dentro de uma edio. Este processo inicia-se com a mensagem Informar login e senha na interface Pagina_Congresso que validada pelo componente Controlador_Congresso que executa o mtodo Login() da instncia da classe Autor (objeto autor1). A seguir, a Figura 13 demonstra o processo de Submisso de artigos, atravs do Diagrama de Comunicao. O processo apresentado no exemplo demonstra a validao das informaes de acesso do responsvel pela submisso no sistema.

Figura 12. Realizar Login (adaptado de GUEDES, pg. 113, 2007)

Figura 13. Realizar Submisso (adaptado de GUEDES, pg. 113, 2007) O processo iniciado pelo Ator Submissor que comea selecionando a opo de submisso na interface Pagina_Congresso. Em seguida, ele seleciona o tema e informa os dados de submisso. Atravs das informaes transmitidas pelo Ator Interface, o componente Controlador_Congresso recebe de Pagina_Congresso a solicitao de submisso (mensagem Submisso solicitada), a informao de tema (mensagem Tema) e a confirmao de submisso (mensagem Submisso confirmada). Aps receber as mensagens enviadas ao componente Controlador_Congresso, este realiza um processo executado sobre a Condio de Guarda Para cada tema, que para cada tema executar o mtodo SelTema() do objeto da classe Tema. Em seguida o componente Controlador_Congresso executa o mtodo SelTema() do objeto da classe Tema e o mtodo RegSub() do objeto sub1 da classe Submissao, responsvel pelo registro da submisso. Continuando, a Figura 14 demonstra o processo de verificao de submisses de artigos tambm. Para cada submisso realizada uma verificao atravs do componente Controlador-_Congresso. A Figura 15 demonstra o processo de verificao de comentrios de um artigo. Para cada submisso realizada uma avaliao atravs do componente Controlador-_Congresso que executa o mtodo SelAval()do objeto da classe Avaliacao. Neste exemplo h duas Condies de Guarda. A primeira Condio de Guarda restringe que para cada avaliao ser executado uma vez o mtodo SelAval() da

classe Avaliacao. A segunda Condio de Guarda possui comportamento semelhante, porm a restrio se refere a um comentrio sobre uma avaliao realizada.

Figura 14. Verificar Submisses (adaptado de GUEDES, pg. 114, 2007)

Figura 15. Verificar Comentrios (adaptado de GUEDES, pg. 114, 2007) A Figura 16 apresenta o processo que permite a manuteno, modificao, das informaes relacionadas s avaliaes e comentrios em relao a uma submisso. Este processo complementa aspectos apresentados no processo descrito na Figura 15. A Figura 17 demonstra o processo de manuteno de comentrios que podem ser feitos durante o processo de avaliao de um artigo. O processo iniciado pelo Avaliador que poder ao longo do processo criar um novo comentrio, alterar, selecionar e excluir a qualquer momento um comentrio. As Condies de Guarda do inicio do Diagrama de Comunicao iro determinar o fluxo de mensagens. O exemplo apresentado na Figura 18 demonstra o processo de emisso de relatrios no Sistema de Controle de Submisses. Neste diagrama, o estmulo inicial que parte do Ator Coordenador que seleciona a opo Relatrio de Avaliaes e o Tema e Tipo de Submisso desejada. Para cada Submisso, seleciona-se o Tema, o contedo submetido e a avaliao desta submisso.

Diagrama de Tempo ou de Temporizao Esse diagrama apresenta algumas semelhanas com o Diagrama de Mquinas de Estados. No entanto, ele enfoca as mudanas de estado de um objeto ao longo do tempo. Esse diagrama ter pouca utilidade, segundo Guedes, em seu livro UML - Uma Abordagem Prtica, para modelar aplicaes comerciais, contudo, poder ser utilizado na modelagem de sistemas de tempo real ou sistemas que utilizem recursos de multimdia/hipermdia, onde o tempo em que o objeto executada algo muitas vezes importante.

Figura 16. Manter Avaliaes (adaptado de GUEDES, pg. 114, 2007)

Figura 17. Manter Comentrios (adaptado de GUEDES, pg. 114, 2007)

Figura 18. Relatrio de Avaliaes (adaptado de GUEDES, pg. 114, 2007)

Em um sistema, por exemplo, de concurso pblico, h uma seqncia lgica de etapas que necessita ser executada. No se pode Aplicar prova de seleo sem antes Elaborar Edital de Concurso. O exemplo do processo de concurso (ver Figura 19) descreve a mudana no estado ou condio da instncia de Concurso durante o tempo de existncia da instncia. Tipicamente os Diagramas de Tempo demonstram mudanas no estado de um objeto no tempo em repostas a eventos externos. Cada etapa ou estado do objeto da classe Concurso apresentada por meio de um hexgono, sendo que o primeiro e o ltimo estado se encontram abertos. Abaixo de cada etapa, entre barras verticais, se encontram as restries de durao que determinam o tempo em que transcorrem as etapas. No caso do estado Abrindo Inscries, o perodo vai de 05 de janeiro a 31 de janeiro. muito importante destacar que o Diagrama de Tempo tem duas notaes ou formas de representao: uma notao conhecida como concisa, mais simples (conforme foi usado na Figura 19), chamada de linha de vida de valor, e uma notao considerada mais robusta, onde as etapas so apresentadas em uma forma semelhante a um grfico (ver Figura 20), chamada linha de vida de estado. No Diagrama de Tempo, o termo linha de vida (lifeline) refere-se ao caminho percorrido por um objeto durante um determinado tempo. A Figura 20 demonstra o mesmo diagrama da Figura 19, dessa vez utilizando a forma robusta e linha de vida de estado, onde as transies de estado so determinadas por mudanas em um grfico, podendo estas conter descries que determinam o evento que causou a mudana, se isso for considerado necessrio. Um Diagrama de Tempo pode ter linhas de vida de mltiplos objetos, utilizando a mesma notao ou notaes diferentes.

Figura 19. Diagrama de Tempo - Forma concisa

Figura 20. Diagrama de Tempo - Forma considerada mais robusta

Concluso Este foi o ltimo artigo da srie Utilizando UML. No decorrer destes 8 artigos pudemos com bastante detalhe conhecer cada um dos 13 diagramas da UML 2.0. A Modelagem atravs da UML adotada em processos de desenvolvimento representa uma das boas prticas da programao e manuteno de softwares. At a prxima, sucesso e bons estudos!

Desafio SQL
Wagner Crivelini Engenheiro formado pela UNICAMP, consultor em TI com 15 anos de experincia, particularmente em projetos de Business Intelligence. Atualmente trabalha na IBM, onde atua como DBA em projeto internacional. De que trata o artigo? Desenvolvimento de solues para problemas cotidianos enfrentados por DBAs e desenvolvedores de aplicaes para banco dados. Para que serve? Fornecer conceitos de utilizao de funcionalidades do padro SQL ANSI na resoluo de problemas enfrentados no dia-a-dia na recuperao de informaes do banco de dados. Em que situao o tema til? Integridade referencial.

Estamos de volta com a coluna Desafio SQL. Para quem nunca a leu, tratamos aqui de problemas enfrentados no dia-a-dia pelos profissionais que trabalham com bancos de dados. E para situarmos estes desafios, a cada artigo contamos um novo captulo da histria da empresa fictcia chamada ItsMyBusiness. Por curiosidade, lembro aos interessados que esta histria comeou faz um bom tempo, na Revista #50. Este o 14o captulo desta "novela" (no bom sentido, claro). A ItsMyBusiness uma empresa de varejo que fez recentemente o seu site de e-commerce. E este site est "bombando"! Vender mais significa mais dinheiro. Mas do ponto de vista de um banco de dados, representa tambm um volume maior de transaes, maiores cuidados com performance, com armazenamento de dados e disponibilidade do sistema. Estes so quesitos que devemos ter em mente desde o incio da modelagem de qualquer banco. Mas o fato que a ItsMyBusiness tratou seu e-commerce como se fosse uma experincia e no tomou cuidados bsicos com a criao deste sistema. Se voc achou que este cenrio se parece com o de algum sistema real com o qual voc trabalhou, isso no mera coincidncia. triste dizer, mas isso terrivelmente comum. As empresas economizariam muito dinheiro se seguissem noes bsicas de projeto. Bom ou mal, certo ou errado, o fato que agora a ItsMyBusiness tem que consertar o "motor do seu carro" quando a corrida j est em andamento. Uma srie de melhorias e correes de bugs no modelo do banco de dados da empresa tem sido feitas nos ltimos meses. No nosso ltimo desafio, apresentamos uma soluo de modelagem para melhorar o controle sobre os pedidos que a ItsMyBusiness recebe. A soluo previa o detalhamento dos possveis status que um pedido poderia ter ao longo da sua histria, ou seja, desde o momento em que ele submetido pelo cliente at o momento em que ele encerrado pela empresa (seja por qual razo for). Esta mesma soluo inclua a integridade referencial dos dados, ou seja, nosso modelo deveria garantir que os dados registrados no banco fossem 100% consistentes. O modelo final da base, j includas as alteraes citadas acima, apresentado a seguir (Figura 1).

Figura 1. Modelo de dados simplificado da empresa ItsMyBusiness. O script de criao deste banco de dados est disponvel para download no portal da SQL Magazine. O script apresenta verses para rodar em SQL SERVER, DB2, ORACLE e FIREBIRD. Voltando ao nosso assunto, para sorte da empresa ItsMyBusiness, o DBA que ela contratou, que no caso voc, um cara muito cuidadoso. Antes de implementar esta soluo, o DBA abriu seu caderno de anotaes e viu a seguinte frase escrita 100 vezes em letras garrafais: NUNCA FAREI ALTERAES NO MEU AMBIENTE DE PRODUO ANTES DE VALIDAR MINHAS SOLUES EM UM AMBIENTE DE TESTES QUE SIMULE A OPERAO REAL. Ento ele passou o script de alterao da base para a equipe de testes, que depois de avaliar dezenas de casos de teste, apresentou o seguinte veredito: Por razes desconhecidas, o modelo em anlise permite a insero manual de informaes inconsistentes na tabela tblPedidoStatus. O problema foi observado quando fizemos insero de dados usando uma declarao SQL do tipo INSERT. Xiiii... a casa caiu! Na verdade, ainda no caiu, porque a alterao no foi para produo e para isso mesmo que fazemos testes meticulosos antes de qualquer implementao. J sabemos qual o problema, pois os testadores no s disseram que o modelo deu pau. Eles disseram detalhadamente o que eles estavam fazendo quando o erro foi observado. O que houve foi o seguinte: foram executadas vrias declaraes de insero de dados na tabela dbo.tblPedidoHistorico. Algumas delas deveriam ser aceitas e outras deveriam ser rejeitadas. Chamamos isso de casos de testes. Na Listagem 1 vemos quatro casos de teste que deveriam ser rejeitados.

Listagem 1. Os testes de rejeio . 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 -- Insero de cdigo de pedido inexistente -- =====> Insert REJEITADO (CORRETO) INSERT INTO dbo.tblPedidoHistorico (codPedido, codProduto, codPedidoStatus, Observacao) VALUES (1000, 1,1, nao existe pedido # 1000) -- Insero de cdigo de produto inexistente -- =====> Insert REJEITADO (CORRETO) INSERT INTO dbo.tblPedidoHistorico (codPedido, codProduto, codPedidoStatus,Observacao) VALUES (1, 2000 ,1, nao existe produto # 2000) -- Insercao de cdigo de status inexistente -- =====> Insert REJEITADO (CORRETO) INSERT INTO dbo.tblPedidoHistorico (codPedido, codProduto, codPedidoStatus, Observacao) VALUES (1, 1, 3000, nao existe status # 3000) -- Insercao com produto que no pertence ao pedido -- =====> Insert ACEITO (ERRADO!!!!!!!!!!!!!) INSERT INTO dbo.tblPedidoHistorico (codPedido, codProduto, codPedidoStatus, Observacao) VALUES (1, 8, 1, o produto # 8 nao faz parte do pedido # 1)

Nos trs primeiros, tentamos inserir cdigos que no existem (linhas 1 a 22 da Listagem 1) e todos eles foram corretamente rejeitados. Mas no quarto teste houve um erro. Neste teste, tnhamos cdigos vlidos para os campos codPedido, codProduto e codPedidoStatus. Mas o produto descrito no faz parte daquele pedido. O banco deveria rejeitar esta insero, mas ele erradamente a aceitou (linhas 19 a 23). Agora volta tudo para as suas mos, j que voc o DBA/arquiteto/desenvolvedor responsvel por este projeto. Sua misso : 1. identificar onde est o problema 2. propor uma nova soluo Divirta-se! Resposta do desafio Muita gente simplesmente despreza o uso de chaves estrangeiras dentro dos seus bancos de dados. A maioria dos sistemas de gesto empresarial com os quais eu trabalhei as tratam como se fossem um pecado que deve ser evitado a qualquer custo. A alegao que as chaves estrangeiras tem impacto na performance do banco, porque o banco de dados sempre far a validao dos dados contra cada uma das chaves estrangeiras existentes numa tabela toda vez que for executar qualquer declarao INSERT, DELETE ou UPDATE. Isso verdade. Existe mesmo um pequeno custo. E vai acontecer a cada transao que ocorrer no seu banco de dados, exigindo um pouco mais de tempo para execuo de qualquer insero, excluso ou alterao nos seus dados. Mas este pensamento estreito esquece um pequeno detalhe: a qualidade dos dados armazenados no seu banco. A integridade referencial (e todos os recursos que ela nos oferece, como o caso das chaves estrangeiras) existe para garantir a consistncia das informaes. Para uma empresa que vive na era da informao, muito mais caro dispor de informaes erradas e/ou inconsistentes do que levar um pouco mais de tempo para realizar cada transao. Pessoalmente, eu uso chaves estrangeiras em todos os modelos de dados que eu crio e no vejo motivo que justifique a sua ausncia.

Mas vamos ao que interessa. Em primeiro lugar, temos que traduzir as palavras dos testadores em termos do modelo do banco de dados. Quando dissemos "o produto descrito no faz parte daquele pedido", precisamos entender como o modelo lida com esta informao. Por isso vamos ver esta parte do modelo com maior detalhe (Figura 2).

Figura 2. Tratamento do ciclo de vendas Veja que o modelo usa a tabela dbo.tblPedidoDetalhe exatamente para armazenar as informaes dos produtos que fazem parte de cada pedido. Tanto assim que a chave primria desta tabela composta pelos campos cdigo de Pedido e cdigo de Produto. Entendendo isso, podemos reformular a frase que apresentamos acima. Em termos do modelo de dados, estamos falando que no existe na tabela dbo.tblPedidoDetalhe nenhuma chave primria composta pelos cdigo de Pedido e cdigo de Produto que estamos inserindo na tabela de histrico do status do pedido. Para todos os efeitos prticos, ns acabamos de responder a primeira pergunta deste desafio! Olhe novamente o modelo na Figura 2. Veja que a integridade referencial que criamos no ltimo desafio no garante que a tabela dbo.tblPedidoHistorico receba combinaes de cdigos de pedido e de produto que j estejam cadastrados na tabela dbo.tblPedidoDetalhe. Ao invs disso, a definio existente garante apenas que no poderemos cadastrar cdigos de pedido e de produto que no existam nas tabelas dbo.tblPedido e dbo.tblProduto, respectivamente. Mas isso no faz tudo o que precisamos. Escrevendo explicitamente a resposta primeira pergunta: o modelo em teste no usa a integridade referencial adequada para a tabela dbo.tblPedidoHistorico, a qual precisa ser alterada. Ento t, sabemos o que est errado. Mas o que vamos fazer para corrigir? Bom, ns precisamos criar chaves estrangeiras na tabela dbo.tblPedidoHistorico que faam referncia chave primria da tabela dbo.tblPedidoDetalhe. E a chave primria formada pelo par de campos codPedido + codProduto. Maravilha. A soluo parece simples. E a vem outra pergunta: o que fazer com as chaves estrangeiras existentes?

Essa uma boa pergunta. Muita gente acaba deixando lixo para trs dentro do banco de dados simplesmente porque ele parece inofensivo. Mas se as chaves existentes no resolvem o problema que deveriam cuidar, muito importante avaliar se elas podem simplesmente ser eliminadas. Lembre-se que seria uma perda de tempo deixar para trs chaves estrangeiras inteis, porque isso tem sim um pequeno impacto na performance do sistema, como eu j comentei anteriormente. No caso em questo, basta olharmos para Figura 2 para termos uma resposta. A tabela dbo.tblPedidoHistorico possui trs chaves estrangeiras: uma referenciando dbo.tblPedidoStatus, outra referenciando dbo.tblPedido e a terceira referenciando dbo.tblProduto. A primeira delas, criada sobre o campo codPedidoStatus, no afetada pela soluo proposta. Portanto ela fica. J sobre as duas outras, veja que elas so idnticas s chaves estrangeiras que existem na tabela dbo.tblPedidoDetalhe: uma referenciando a tabela dbo.tblPedido e outra referenciando dbo.tblProduto Como ns vamos criar uma nova chave estrangeira em dbo.tblPedidoHistorico referenciando exatamente a tabela dbo.tblPedidoDetalhe, seria redundante manter as referncias antigas. Ento devemos excluir ambas. Para isso, vamos precisar saber os nomes das chaves que sero excludas. E esta parte nem sempre to fcil... E cada SGBD tem um meio de lhe mostrar esta informao. No SQL SERVER, por exemplo, existem vises de sistema (as Dynamic Management Views ou DMVs) que nos do estas e outras informaes. Aos interessados, recomendo dar uma olhada na soluo apresentada por Pinal Dave (http://blog.sqlauthority.com/2007/09/04/sql-server-2005-find-tables-withforeign-key-constraint-in-database/). Respondemos metade da segunda pergunta. Dissemos o que fazer, mas no como fazer a alterao.Faltou criarmos uma nova chave estrangeira referenciando dois campos ao mesmo tempo. O padro ANSI SQL prev esta situao de forma muito simples e intuitiva: basta referenciar os dois campos desejados, separando-os por uma vrgula. A Listagem 2 mostra o script final incluindo a excluso das chaves antigas e a criao da nova chave. Este script vlido para SQL SERVER, DB2 e ORACLE. Listagem 2. Soluo do desafio (SQL SERVER, DB2 e ORACLE). 1 2 3 4 5 6 7 8 9 10 11 12 13 14 -- exclui FKs existentes ALTER TABLE dbo.tblPedidoHistorico DROP CONSTRAINT FK_tblPedidoH_tblPedido ; ALTER TABLE dbo.tblPedidoHistorico DROP CONSTRAINT FK_tblPedidoH_tblProduto ;

-- cria a FK correta!!! ALTER TABLE dbo.tblPedidoHistorico ADD CONSTRAINT fkPedidoH_DUPLO FOREIGN KEY (codPedido, codProduto) REFERENCES dbo.tblPedidoDetalhe (codPedido, codProduto) 15 ;

Para o FIREBIRD, a nica alterao necessria excluir a referncia ao esquema dbo, j que este SGBD no usa nome de esquema e/ou login frente do nome dos objetos. O restante da sintaxe idntico, conforme Listagem 3. Com isso terminamos o desafio SQL deste ms. Agora podemos passar a correo do cdigo para nova srie de testes e, se tudo der certo, em breve teremos as novas implementaes rodando no ambiente de produo da ItsMyBusiness! Espero que voc tenha gostado. Listagem 3. Soluo do desafio (FIREBIRD) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 -- exclui FKs existentes ALTER TABLE tblPedidoHistorico DROP CONSTRAINT FK_tblPedidoH_tblPedido ; ALTER TABLE tblPedidoHistorico DROP CONSTRAINT FK_tblPedidoH_tblProduto ;

-- cria a FK correta!!! ALTER TABLE tblPedidoHistorico ADD CONSTRAINT fkPedidoH_DUPLO FOREIGN KEY (codPedido, codProduto) REFERENCES dbo.tblPedidoDetalhe (codPedido, codProduto) 15 ;

Alta Disponibilidade no SQL Server 2005/2008


Priscila Azarias Formada pela Universidade Tecnolgica Federal do Paran (UTFPR) em Sistemas de Informaes. Atualmente especializando em Engenharia de Produo pela UTFPR. Atualmente trabalha na empresa W.Security, como DBA utilizando SQL Server 2005. De que se trata o artigo: O presente artigo apresenta os principais conceitos sobre alta disponibilidade e as solues que podem ser implementadas utilizando o SQL Server. . Para que serve: Este artigo serve de base introdutria para a construo de uma soluo que mantm a disponibilidade de um sistema aps uma falha de hardware ou software. Em que situao o tema til: Minimizar o tempo de inatividade de um sistema em caso de alguma falha de software ou hardware, disponibilizando um segundo servidor responsvel em assumir os servios do servidor principal. Alta disponibilidade pode ser definida como uma soluo que mascara os efeitos de uma falha de hardware ou software e mantm a disponibilidade dos aplicativos, de modo a minimizar o tempo de inatividade de um sistema. Para algumas empresas, esta definio significa que dever existir um hardware redundante igual ao de produo, o que requer que os dados e o hardware tenham durao e disponibilidade de 99,995 % ou mais. Outras empresas necessitam apenas que os dados propriamente ditos tenham alta disponibilidade, sem tanta preocupao com o desempenho do nvel de produo caso um failover (processo no qual uma mquina assume os servios de outra, quando esta ltima apresenta alguma falha) seja necessrio. Para determinar a melhor soluo de alta disponibilidade, necessrio avaliar questes referentes aos tipos de interrupes que podero ocorrer e indicar como isso afeta seus Contratos de Nvel de Servio (SLAs). As interrupes que podem afetar a disponibilidade so: - Desempenho Planejado: normalmente uma manuteno programada sobre a qual os usurios dos sistemas so informados com antecedncia; - No Planejado: geralmente resulta de uma falha de hardware ou software que torna os dados inacessveis; e - Degradao do Desempenho: a degradao do desempenho tambm pode provocar interrupes, e normalmente medida no tempo de resposta do usurio final. E por fim, identificar o nvel de atividade dos dados e se estes devem estar sempre on-line ou offline ocasionalmente. A seguir ser descrito previamente cada opo de disponibilidade disponvel para o Microsoft SQL Server 2005, que seriam: Cluster de Failover, Espelhamento de banco de dados, Log Shipping e Replicao. Cluster de Failover O Cluster de failover basicamente uma soluo de hardware que consiste em um grupo de computadores independentes que trabalham juntos para aumentar a disponibilidade de aplicativos e servios. Os servidores em cluster (chamados de ns) so conectados atravs de cabos fsicos e de software. Se um dos ns do cluster falhar, outro comear a fornecer os servios, sendo que os usurios do sistema teriam o mnimo de interrupes nos servios. Um requisito inicial que deve ser verificado antes da instalao do cluster identificar se o hardware certificado pela Microsoft. Este deve constar na lista de solues de hardware certificada,

chamada de Hardware Compatibility List (HCL). Por ser uma soluo de alta disponibilidade, preciso assegurar que componentes lgicos e fsicos funcionam da maneira adequada. Para uma soluo em cluster, so necessrios os seguintes componentes fsicos (ver Figura 1): - Ns de cluster (Cluster Nodes): um servidor que faz parte do cluster e compartilha os recursos do cluster. Todos os ns do cluster devem possuir o mesmo sistema operacional e plataforma (32 bits ou 64 bits). - Rede Privada (Private Network): a funo da rede privada verificar se os ns que compem o cluster esto funcionando e disponveis. A rede privada implementada atravs de uma placa de rede dedicada e exclusiva no n do cluster. - Rede Pblica (Public Network): a funo da rede pblica permitir que as aplicaes conectemse no cluster e que o cluster possa conectar-se na rede. A rede pblica implementada atravs de uma placa de rede dedicada e exclusiva no n do cluster. - Conjunto de discos compartilhados (Shared Disk Array): conjunto de discos fsicos (SCSI ou Fiber Channel) que so acessados pelos ns do cluster. O conjunto de discos compartilhados tambm conhecido como storage do cluster. A storage apresenta para os ns do cluster um conjunto lgico de discos que so acessados pelo sistema operacional como se fossem discos internos do servidor. O servio de cluster da Microsoft implementa o conceito de shared nothing disk, pois desta forma somente um n do cluster tem acesso exclusivo a uma ou mais unidades lgicas da storage de cada vez. - Disco de Quorum (Quorum Disk): uma unidade lgica na storage que contm o arquivo de log e informaes de estado do cluster. O n que for o dono do disco de quorum o n responsvel pelo cluster. Na Figura 1 possvel visualizar como ficaria um cluster completo com todos os seus componentes mais um disco onde possui uma instalao de uma instncia (servio) do SQL Server. No caso de uma falha no n principal, o segundo n assumir os servios que estavam sendo disponibilizados, sendo transparente para o usurio final. A mudana entre os ns pode ser feita de forma manual ou automtica.

Figura 1. Cluster Completo

Espelhamento de banco de dados O espelhamento de banco de dados basicamente uma soluo de software para aumentar a disponibilidade dos dados, dando suporte a failover quase instantneo. O espelhamento de banco de dados mantm duas cpias de um nico banco de dados em servidores diferentes. Uma instncia do servidor atua como banco de dados para os clientes (servidor principal) enquanto a outra instncia funciona como servidor em espera ativa ou passiva (servidor de espelho), dependendo da configurao. A configurao mais simples do espelhamento do banco de dados envolve apenas os servidores: principal e espelho. Nessa configurao, se o servidor principal for perdido, o servidor espelho poder ser usado como um servidor de espera passiva (a mudana deve ocorrer de forma manual), onde poder ocorrer possvel perda de dados (Ver Figura 2). Outra configurao dita como modo de alta segurana com failover. Neste caso envolver mais uma instncia de servidor de banco de dados, conhecido como testemunha, que possibilita que o servidor espelho atue como um servidor em espera ativa (a mudana ocorre de forma automtica) (ver Figura 3). O failover do banco principal para o banco de espelho normalmente demora vrios segundos.

Figura 2. Espelhamento de Banco de Dados

Figura 3. Espelhamento com Servidor de Testemunha

As Figuras 2 e 3 demonstram como resultaria a configurao do espelhamento de banco de dados com e sem o servidor de testemunha. Caso ocorra uma falha no banco de dados principal o servidor espelho dever assumir o seu lugar, fazendo com que os usurios possam continuar acessando o aplicativo, mesmo aps a ocorrncia de alguma falha. O espelhamento de banco de dados oferece os seguintes benefcios: - Deteco e failover automtico; - Failover manual; - Redirecionamento transparente para os clientes; - Opera em nvel de banco de dados; - Usa uma nica cpia duplicada do banco de dados; - Usa servidores padro; - Fornece relatrios no servidor de espelho, usando cpias do banco de dados (instantneos); - Quando opera sincronicamente, proporciona zero perda de trabalho por meio de confirmao atrasada no banco de dados principal. Log Shipping (Envio de Logs) Assim como o espelhamento de banco de dados, o Log Shipping tambm uma soluo de software. Este recurso pode ser utilizado para manter um ou mais banco de dados de espera passiva (banco de dados secundrio) para um banco de dados de produo (banco de dados primrio). O Log Shipping permite o envio automtico de backups do log de transaes (ver Nota DevMan ) de um banco de dados primrio para um banco de dados secundrio. Os backups de logs de transao so aplicados individualmente aos bancos de dados secundrios, dessa forma existindo cpias do banco de dados primrio. Uma terceira instncia de servidor opcional, conhecido como servidor monitor, registra o histrico e o status das operaes de backup e restaurao e podendo emitir alertas se essas operaes no forem executadas corretamente. Nota Devman - Controle de Log de Transaes Controle de Log e Transaes do SQL Server: Uma transao garante que qualquer operao seja ou totalmente completada ou desfeita caso ocorra uma falha, mas nunca permite que o banco de dados fique em um estado intermedirio. O SQL Server implementa as transaes usando um arquivo de Log. Quaisquer mudanas realizadas em qualquer dado iro atualizar a memria cach, simultaneamente todas as operaes realizadas sero escritas no Log. A Figura 4 mostra a configurao do envio de logs com uma instncia do servidor primrio, uma instncia secundria e uma instncia de servidor monitor. Esta figura ilustra as etapas executadas pelos backups, cpia e restaurao: 1. A instncia do servidor primrio executa o trabalho de backup do log de transaes do banco de dados primrio. Essa instncia do servidor coloca o backup do log em um arquivo de backup de log primrio, enviado para a pasta de backup. 2. A instncia de servidor secundrio executa seu prprio trabalho de cpia do arquivo de backup de log primrio para a sua prpria pasta de destino local. 3. O servidor secundrio executa seu prprio trabalho de restaurao do arquivo de backup de log a partir da pasta de destino local no banco de dados secundrio local. O Log Shipping envolve um atraso modificvel pelo usurio entre o momento em que o servidor primrio cria um backup de log do banco de dados e quando o servidor secundrio restaura um banco do backup. Antes que um failover possa ocorrer, um banco de dados deve ser atualizado completamente pela aplicao manual de quaisquer backups de log no restaurados. Esta soluo fornece a flexibilidade de suportar vrios bancos de dados de espera, oferecendo as seguintes funcionalidades: - Suporte a vrios bancos de dados secundrios em vrias instncias de servidor para um nico banco de dados primrio;

- Permite um atraso especificado pelo usurio entre o momento em que o servidor primrio faz backup do log do banco de dados primrio e quando os servidores secundrios devem restaurar o backup de log. Um atraso mais longo pode ser til, por exemplo, se dados forem alterados acidentalmente no banco de dados primrio. Se a alterao acidental for notada rapidamente, um atraso pode permitir que voc recupere dados ainda inalterados de banco de dados secundrio, antes que alterao seja refletida.

Replicao A replicao utilizada para copiar dados para um servidor e distribu-los para outros servidores. Tambm pode ser utilizada para copiar, transformar e distribuir os dados personalizados entre os mltiplos servidores. Usando a replicao, possvel distribuir dados para diferentes locais e para usurios remotos e mveis atravs de redes locais e de longa distncia, conexes dial-up, conexes sem fio e a Internet. Algumas razes para usar a replicao incluem: - Sincronizar alteraes para bancos de dados remotos com um banco de dados central. Por exemplo, se a equipe de vendas utiliza laptops remotos, voc pode precisar criar uma cpia de dados para a regio de vendas da equipe no laptop. Mais tarde, um vendedor no campo poder desconectado da rede, acrescentar informaes ou fazer alteraes. Com a replicao, essas modificaes seriam sincronizadas com o banco de dados central. - Criar mltiplas instncias de um banco de dados para que voc possa distribuir a carga de trabalho. Por exemplo, se tiver um banco de dados central que atualizado regularmente, talvez seja recomendvel obter alteraes para os bancos de dados departamentais medida que elas ocorram. Os empregados podem ento acessar os dados departamentais em vez de tentar se conectar ao banco de dados central. - Mover conjuntos de dados especficos de um servidor central e distribu-los para vrios outros servidores. Por exemplo, usar a replicao para um banco de dados central que precisasse distribuir os dados de vendas para todos os bancos de dados de lojas de departamento da empresa. A replicao foi projetada para atender s necessidades de uma ampla variedade de ambientes. A arquitetura de replicao dividida em vrios processos, procedimentos e componentes diferentes, cada um dos quais utilizado para personalizar a replicao para uma situao particular. A arquitetura de replicao inclui: - Componentes da replicao: so os componentes servidores e dados na replicao. Sendo eles: - Publicador: so servidores que disponibilizam os dados para a replicao em outros servidores. Tambm monitoram alteraes nos dados e mantm outras informaes sobre o banco de dados de origem. Todo agrupamento de dados tem apenas um publicador. - Distribuidor: so servidores que distribuem os dados replicados. Os distribuidores armazenam o banco de dados de distribuio, os metadados, os dados histricos e (para replicao transacional) as transaes.

- Assinante: so servidores de destino para replicaes. Esses servidores armazenam os dados replicados e recebem atualizaes. Os assinantes tambm podem fazer alteraes em dados. Os dados podem ser publicados em mltiplos assinantes. - Agentes e trabalhos de replicao: Aplicativos que auxiliam no processo de replicao. - Variantes da replicao: So os tipos de replicao, sendo elas: * Replicao Transacional: normalmente usada em cenrios de servidor para servidor que requerem alta taxa de transferncia, incluindo: melhora da escalabilidade e disponibilidade; armazenamento de dados data warehouse e relatrios; integrao de dados de vrios sites; integrao de dados heterogneos e descarregamento de processamento em lote. * Replicao de Mesclagem: projetada principalmente para aplicativos mveis ou de servidor distribudo que possuem possveis conflitos de dados. Os cenrios comuns incluem: troca de dados com usurios mveis; aplicativos de POS (ponto de vendas) para o consumidor e integrao de dados de vrios sites. * Replicao de Instantneo (Snapshot): usada para fornecer o conjunto inicial de dados para replicao transacional e de mesclagem. Ela tambm pode ser usada quando as atualizaes completas de dados estiverem apropriadas. A Figura 5 demonstra como ficaria a arquitetura da replicao. A replicao possibilita disponibilidade em tempo real e escalabilidade entre servidores. Suporta filtragem para fornecer um subconjunto de dados nos Assinantes e tambm permite atualizaes particionadas. Os Assinantes ficam online e disponveis para relatrios e outras funes, sem recuperao de consultas. Configurando Espelhamento de Banco de Dados Agora que conhecemos as solues disponveis para disponibilidade de um banco de dados, vamos agora simular uma das solues de disponibilidade que o SQL Server 2005/2008 fornece levando em considerao o seguinte estudo de caso: voc administrador de um banco de dados de uma empresa que vende seus produtos atravs da web. preciso garantir a disponibilidade dos dados, sem qualquer tipo de interrupo. Analisando o ambiente do cliente, voc decide implementar o espelhamento do banco com espera ativa.

Figura 5. Replicao

Antes de aprendermos como criar um espelhamento no banco, vamos criar o banco de dados SQLMagazine e as tabelas que o compem: PRODUTOS, CLIENTES e VENDAS (Ver Listagem 1). Para executar a Listagem 1, abra o SQL Server Management Studio, conecte-se na instncia que ser o servio principal do espelhamento. Em seguida, na barra de ferramentas solicite uma nova query (Ver Figura 6).

Figura 6. Solicitando uma nova query Listagem 1. Criando banco de dados e tabelas USE [MASTER] GO -- CRIA O BANCO DE DADOS CREATE DATABASE SQLMagazine GO USE [SQLMAGAZINE] GO -- TABELA CLIENTE CREATE TABLE [dbo].[CLIENTE]( [PKID] [int] IDENTITY(1,1) PRIMARY KEY CLUSTERED NOT NULL, [RAZAO_SOCIAL] [varchar](50) NULL, [NOME_FANTASIA] [varchar](50) NULL, [CPF_CNPJ] [varchar](18) NOT NULL, [TIPO] [int] NULL, [DATA_CADASTRO] [datetime] NOT NULL CONSTRAINT [DF_ DATA_CADASTRO] DEFAULT (getdate()), [MUNICIPIO] [varchar](50) NULL, [ENDERECO] [varchar](60) NULL, [NUMERO] [varchar](7) NULL, [BAIRRO] [varchar](30) NULL, [COMPLEMENTO] [varchar](40) NULL, [CEP] [varchar](10) NULL )GO

-- TABELA PRODUTO CREATE TABLE [dbo].PRODUTOS( [PKCODIGO] [varchar](20) PRIMARY KEY CLUSTERED NOT NULL, [VALOR_UNITARIO] [decimal](18, 2) NULL, [STATUS] [bit] NOT NULL, [PRECO_VENDA] [decimal](18, 2) NOT NULL, [QTDE_ESTOQUE] [decimal](18, 4) NULL, [DATA_VALIDADE] [datetime] NULL ) GO -- TABELA VENDA CREATE TABLE [dbo].[VENDA]( [PKID] [int] IDENTITY(1,1) PRIMARY KEY CLUSTERED NOT NULL, [CLIENTE_PKID] [int] NULL, [PRODUTO_PKCODIGO] [varchar](20) NULL, [DATA_VENDA] [datetime] NULL, [QUANTIDADE] [decimal](18, 2) NULL, [VALOR_TOTAL] [decimal](18, 2) NULL ) GO -- CRIANDO O RELACIONAMENTO DAS TABELAS -- ENTRE VENDA/CLIENTE ALTER TABLE [dbo].[VENDA] WITH CHECK ADD CONSTRAINT [FK_VENDA_CLIENTE] FOREIGN KEY([CLIENTE_PKID]) REFERENCES [dbo].[CLIENTE] ([PKID]) GO -- CRIANDO O RELACIONAMENTO DAS TABELAS -- ENTRE VENDA/PRODUTO ALTER TABLE [dbo].[VENDA] WITH CHECK ADD CONSTRAINT [FK_VENDA_PRODUTO_SERVICO] FOREIGN KEY([PRODUTO_PKCODIGO]) REFERENCES [dbo].[PRODUTOS] ([PKCODIGO]) GO Agora que possumos nosso banco de dados, vamos preparar o nosso ambiente. necessrio ter uma ateno especial na preparao inicial do espelhamento de banco de dados, cuidando para atender todos os pr-requisitos. Sendo eles: - Os servidores que voc escolher para o espelhamento devem possuir a mesma edio do SQL Server 2005/2008. Sendo que as verses que permitem o espelhamento so SQL Server Enterprise e SQL Server Standard, para os papis do banco principal e espelho. A terceira instncia, que responsvel pelo failover, poder utilizar as seguintes verses: SQL Server Express, SQL Server Workgroup. Para verificar as verses, voc deve executar uma consulta em todas as instncias que sero utilizadas. Para tal, abra uma nova query (Figura 6), digite e execute a consulta mostrada na Figura 7. Verifique se todos os servidores esto se comunicam. Est verificao pode ser feita dando um ping nos servidores atravs dos seguintes passos: - Menu Iniciar -> Executar; - Digite CMD; - Na janela que aparece, digite ping [Nome Servidor], conforme pode ser visualizado na Figura 8.

Figura 7. Verificando a verso do SQL Server

Figura 8. Verificando a comunicao Repita o processo nos outros servidores, disparando o comando de um para outro, por exemplo, ping SRV01 - no servidor SRV02; ping SRV02 - no servidor SRV01. - O banco de dados principal deve estar configurado com o modo de recuperao FULL. Execute a Listagem 2 em uma nova query para configurar est opo. Aps concluir os pr-requisitos, poderemos iniciar a configurao do espelho do banco de dados. Em uma ambiente de produo, o ideal que cada instncia esteja em mquinas diferentes, mas a ttulo de teste voc pode instalar trs instncias na mesma mquina. Para iniciar o processo, conecte-se na instncia que ser o principal. Deve-se realizar um backup completo e um backup de log. Este backup ser restaurado na instncia que ser o espelho, isto necessrio para sincronizar as informaes. Aps o backup, o ideal que nenhum aplicativo adicione novos dados no banco principal. Para realizar os backups, execute a Listagem 3 em uma nova query. Com os backups realizados, o prximo passo restaur-los na instncia que ser o espelho. Copie os arquivos para o servidor espelho, conecte-se na instncia que possura o espelho do banco. Abra uma nova query e execute o cdigo da Listagem 4. Listagem 2. Alterando o modo de recuperao USE [master] GO ALTER DATABASE [SQLMagazine] SET RECOVERY FULL GO Listagem 3. Realizando o backup do banco de dados SQLMagazine USE [master] GO -- BACKUP COMPLETO BACKUP DATABASE SQLMagazine TO DISK=C:\Backup\BKPSQLMagazine.bak WITH INIT GO

-- BACKUP DO LOG BACKUP LOG SQLMagazine TO DISK=C:\Backup\BKPLOG_SQLMagazine.trn WITH INIT GO Listagem 4. Restaurando o banco de dados SQLMagazine no servidor espelho USE [master] GO -- RESTAURANDO OS ARQUIVOS RESTORE DATABASE SQLMagazine FROM DISK=C:\Backup\BKPSQLMagazine.bak WITH NORECOVERY GO -- RESTAURANDO O LOG BACKUP LOG SQLMagazine TO DISK=C:\Backup\BKPLOG_SQLMagazine.trn WITH REPLACE, NORECOVERY GO Ao restaurar o banco de dados espelho, verifique se o banco de dados possui o mesmo nome do banco principal, e a restaurao deve ser no modo WHIT NORECOVERY, conforme Listagem 4. Se possvel, o caminho do banco de dados espelho deve ser idntico ao caminho do banco de dados principal. Se os caminhos no forem idnticos, ser necessrio adicionar a opo MOVE na instruo de restaurao (ver Listagem 5). Listagem 5. estaurando o banco de dados (MOVE) USE [master] GO RESTORE DATABASE SQLMagazine FROM DISK=C:\Backup\BKPSQLMagazine.bak REPLACE,NORECOVERY, MOVE SQLMagazine_Data TO F:/Dados/SQLMagazine_Data.mdf, MOVE SQLMagazine_Log TO F:/Dados/SQLMagazine_Log.ldf GO

WITH

Concluda esta etapa, voc dever possuir uma imagem semelhante Figura 9 na instncia do banco de dados espelho.

Figura 9. Banco de Dados Espelho

Com o servidor espelho preparado, retornaremos para o servidor principal para configurar o espelhamento. Para isto, conecte-se na instncia que possui o banco principal. No Object Explore, clique com o boto direito no banco, nas opes que aparecem selecione Task Mirror (Figura 10). Em seguida, aparecer uma nova janela (Figura 11) onde voc configurar a conexo entre os servidores e modo de operao, que poder ser escolhido uma das trs opes disponveis. Aps a configurao do espelhamento elas sero habilitadas. As opes disponveis so: - High Availability: Para maximizar o desempenho, o banco de dados espelho fica sempre um pouco atrs do banco de dados principal, isto , h uma demora para sincronizar todos os dados do banco. Porm, a lacuna entre os bancos de dados geralmente pequena. A perda de um parceiro tem o seguinte efeito: o Se a instncia do servidor espelho ficar indisponvel, o principal continuar. o Se a instncia do servidor principal ficar indisponvel, o espelho ir parar; mas se a sesso no tiver um servidor testemunha (como recomendado) ou se o servidor testemunha estiver conectado ao servidor espelho, o servidor espelho ficar acessvel como espera passiva e o proprietrio do banco de dados poder forar o servio para a instncia do servidor espelho (com possvel perda de dados).

Figura 10. Acessando a opo de criao de Espelho (Mirror)

Figura 11. Configurando o espelho - High Protection: Todas as transaes confirmadas tm a garantia de serem gravadas no disco do servidor espelho. O failover manual possvel quando os parceiros esto conectados um ao outro e o banco de dados est sincronizado. A perda de um parceiro tem o seguinte efeito: * Se a instncia do servidor espelho ficar indisponvel, o principal continuar. * Se a instncia do servidor principal ficar indisponvel o espelho ir parar, mas ficar acessvel como espera passiva e o DBA poder forar a inicializao do servio do servidor espelho (com possvel perda de dados). - High Performance: Todas as transaes confirmadas tm a garantia de serem gravadas no disco no servidor espelho. A disponibilidade maximizada incluindo uma instncia do servidor testemunha para dar suporte ao failover automtico. Observe que voc s pode selecionar a opo Alta segurana com failover automtico (sncrono) se tiver antes especificado o endereo de um servidor testemunha. Na presena de um servidor testemunha, a perda de um parceiro tem o seguinte efeito: * Se a instncia do servidor principal ficar indisponvel, ocorrer failover automtico. A instncia do servidor espelho alternada para a funo principal e oferece seu banco de dados como banco de dados principal. * Se a instncia do servidor espelho ficar indisponvel, o principal continuar. Feito isso, clique no boto Configure Security... (Figura 11). Aparecer um Wizard que ajudar a configurar o espelhamento. Clique next nesta primeira janela.

A primeira etapa a ser configurada se a sesso de espelhamento possuir um servidor de testemunha. No nosso exemplo, precisamos do failover automtico, ento selecionaremos a opo Yes. Clique em next. Aparecer uma lista com os servidores que devero fazer parte do espelhamento (Figura 12). Deixe as opes padro e clique em next. A prxima etapa consiste em criar as conexes entre os servidores. Para tal, o SQL Server criar um endpoint, que um objeto que permite a comunicao entre a rede. Quando o espelhamento configurado, a instncia requer seu prprio e dedicado endpoint mirroring, que usado exclusivamente para receber a comunicao entre os bancos de dados (principal, espelho e testemunha).

Figura 12. Servidores que sero configurados As Figuras 13, 14 e 15 mostram essa configurao. Voc dever identificar cada instncia SQL Server que ir participar e informar uma porta (se as instncias estivem em mquinas diferentes pode deixar a porta default; caso contrrio dever informar portas diferentes). Para a conexo nos servidores, utilize Windows Authentication se estiverem no mesmo domnio, seno utilize a SQL Authentication, informando um usurio e senha.

Figura 13. Principal Server

Figura 14. Server Mirror

Figura 15. Server Witness Aps terminar de configurar o Witness e clicar em next, aparecer uma janela pedindo para informar a conta que deve iniciar o servio (Figura 16). Se a mesma conta iniciar todos os servios ,voc poder deixar as caixas em brancos, caso contrrio dever informar uma conta que possua permisses de acesso em todos os servidores.

Figura 16. Contas de Servio

Clique em next, aparecer uma listagem com todos as configuraes que foram efetuadas. Se estiver tudo de acordo clique em Finish, e o SQL Server ir criar todas as configuraes. Se tudo estiver correto voc ver a Figura 17.

Figura 17. Finalizando a criao dos endpoints

Ao clicar em close, aparecer uma mensagem se voc deseja iniciar o espelhamento (Ver Figura 18).

Figura 18. Iniciando o espelhamento Clique no boto iniciar, para que o espelhamento comece. Como configuramos um servidor testemunha, ele iniciar com o modo High Performance. Se tudo estiver ocorrido bem voc ver a seguinte imagem no Object Explorer (Figura 19).

Figura 19. Verificando o espelhamento

Pronto! O espelhamento est configurado e iniciado. Agora voc pode inserir, alterar ou excluir os dados ou criar novas tabelas, que as mudanas sero refletidas para o banco espelho. Para testar isto, vamos criar uma nova tabela, bem simples, apenas para teste. Execute a Listagem 6 para criar uma nova tabela no banco de dados principal. Listagem 6. Criando uma nova tabela USE [SQLMagazine] GO CREATE TABLE TB01( COD INT NOT NULL) GO Vamos verificar agora se a tabela foi replicada para o banco espelho. Iremos parar o servio do banco de dados principal. Com a interrupo do servio, dever ocorrer um failover automtico para o banco espelho. Para isto, selecione com o boto direito do mouse na instncia principal. Nas opes que aparecem cliquem em Stop (Figura 20).

Figura 20. Parando servio do banco principal

Atualize as instncias e poder ser verificado que agora quem est como principal a segunda instncia (Figura 21).

Figura 21. Verificando o failover Conforme podemos visualizar na Figura 21, a segunda instncia assumiu os servios do banco principal. Verificamos tambm que a tabela que foi criada no banco principal foi replicada para o espelho, possuindo a mesma estrutura, dados e informaes. possvel visualizar que ao lado do banco vemos o status do banco, que aparece SQLMagazine (Principal, Disconnected). A mensagem Desconectado aparece por que o outro parceiro ainda no est no ar. Quando iniciarmos o servio novamente, os bancos ficaro como a tela mostrada na Figura 19, apenas com os papis trocados. O espelhamento til quando os dados devem estar sempre disponveis. Assim poderemos ter uma alternativa rpida de troca de servios quando um problema acontece ou quando o servidor principal precisa passar uma manuteno, que exigem deix-lo indisponvel. Concluso A alta disponibilidade tem como objetivo eliminar as paradas no planejadas. Paradas no planejadas ocorrem por defeitos, j as paradas planejadas so normalmente por causa de atualizaes, manuteno preventiva e atividades correlatas. Desta forma preciso identificar primeiramente todas as necessidades de negcios da empresa para que se possa definir a correta opo de alta disponibilidade. No artigo foram apresentadas, de forma resumida, as diversas opes que o SQL Server disponibiliza para a alta disponibilidade dos dados, assim como foi demonstrado como configurado um espelhamento do banco de dados, que uma das opes de alta disponibilidade. Possuindo assim as informaes em outro servidor que poder assumir o papel de principal sem que os usurios percebam e sem grandes transtornos.

Compactao de Dados com o SQL Server 2008


Pedro Antonio Galvo Junior Experincia de mais de 14 anos na rea de Tecnologia da Informao e solues Microsoft. Graduado no Curso Superior em Gesto da Tecnologia de Sistemas de Informao na Faculdade FAC So Roque (Filiada a Faculdades Uninove de So Paulo). Ps-Graduado no Curso de Gesto e Engenharia de Processos para Desenvolvimento de Software com RUP na Faculdade FIAP - Faculdade de Informtica e Administrao Paulista de So Paulo. Certificado Microsoft MVP - Most Valuable Profissional na competncia Windows Server System - SQL Server. Formao MCDBA Microsoft SQL Server 2000. Especialista na Administrao de Servidores de Banco de Dados, Coordenador de Projetos e Processos relacionados a rea de TI. Atuou em diversas empresas e instituies acadmicas na regio do So Roque e Sorocaba. De que trata o artigo: Neste artigo veremos as formas de compactao de dados existente no Microsoft SQL Server 2008. Em seguida, demonstraremos como utilizar cada uma destas formas, com base em duas tabelas contendo dados fictcios. Para que serve: A compactao de dados tem como objetivo proporcionar um melhor dimensionamento de espao em disco necessrio para alocar dados existentes em tabelas do Microsoft SQL Server 2008. Procurando evitar qualquer tipo de aumento no tempo de processamento necessrio para armazenar ou consultar estes dados compactados. Em que situao o tema til: A compactao de dados uma tcnica muito til para ambientes com falta de espao em disco, mas que possuem uma grande necessidade de armazenamento de dados. Sua utilizao reflete diretamente na perda de tempo e esforo necessrio para alocar os dados armazenados nas tabelas ou ndices que utilizam compactao em linha de linha ou pginas de dados. Alm disso, a compactao de dados pode trazer alguns benefcios em relao diminuio da fragmentao de dados armazenados em uma tabela que esteja utilizando o nvel de compactao em linha.

Quando falamos em armazenamento de dados, sempre pensamos na necessidade que temos em guardar uma informao em local seguro, confivel e ntegro. A evoluo da capacidade de armazenamento de dados ocorrido nos ltimos anos ofereceu s empresas recursos que permitem armazenar e gerenciar grandes volumes de informao, independente da sua origem. Acompanhando este crescimento e evoluo, as empresas desenvolvedoras de Sistemas Gerenciadores de Bancos de Dados identificaram como pr-requisito para seus produtos a capacidade de armazenar qualquer tipo de informao, sendo elas arquivos de udio, vdeo, apresentaes, ou simplesmente um dado. Mas o aumento da capacidade de armazenamento tambm obrigou estas empresas a se preocuparem com o gerenciamento deste volume de informaes, e, ainda mais, a buscarem uma melhor forma para alocar informaes evitando desperdcios da capacidade de armazenamento, sem ocasionar aumento no tempo de processamento. Com base no atual momento tecnolgico e procurando manter seus produtos atualizados, a Microsoft decidiu fazer algumas mudanas no formato de compactao de dados realizada pelo SQL Server 2008, oferecendo suporte nativo a esta funcionalidade. Utilizando as funcionalidades de compactao de dados existentes no SQL Server 2008, torna-se possvel realizar esta tarefa economizando espao de armazenamento, mas, em algumas situaes, ocasionando um pequeno aumento de processamento e tempo de execuo. Neste artigo, iremos apresentar esta nova funcionalidade, provida a partir das verses Standard e Enterprise do SQL Server 2008

Conhecendo a compactao de dados A possibilidade de compactao de dados no SQL Server surgiu no lanamento do Service Pack 2 para o SQL Server 2005, com base no formato de armazenamento vardecimal (sendo um formato de armazenamento, no um tipo de dados).Anteriormente o Microsoft SQL Server no apresentava recursos relacionados a compactao de dados. Analisar a melhor forma para se alocar um dado em uma tabela sem gerar fragmentao ou desperdcio de espao em disco era de total responsabilidade e dever do administrador de banco de dados (DBA) ou administrador de dados (DA).O SQL Server 2008 oferece suporte a compactao de linha e de pgina para tabelas e ndices. A compactao de dados pode ser configurada para os seguintes objetos do banco de dados: - Uma tabela inteira que armazenada como um heap; - Uma tabela inteira que armazenada como um ndice clusterizado; - Um ndice no clusterizado inteiro; - Uma view indexada inteira. A partir SQL Server 2005 Service Pack 2 e verses posteriores, tipos de dados como decimal e numeric tornaram-se mais versteis e compatveis com o formato de armazenamento vardecimal. Este formato de dados possibilita a reduo do tamanho ocupado pelos dados, podendo ocasionar um pequeno aumento no tempo de processamento.Quando utilizamos vardecimal o SQL Server dever verificar inicialmente o tamanho da informao que ser armazenada e, logo aps, estabelecer o quanto de espao ser necessrio para sua alocao. Caso o dado que ser armazenado esteja compactado em nvel de pgina, o SQL Server ter a misso de identificar a melhor posio de armazenamento dentro da pgina de dados, evitando a alocao desnecessria em outra pgina, sem gerar disperdcio de espao ou aumentando o tempo de processamento. Entendendo a compactao de dados Compactar um dado parece ser uma tarefa fcil, tendo em vista as diversas ferramentas ou aplicaes compactadoras de arquivos existentes no mercado. Alm disso, atualmente a grande maioria dos sistemas operacionais apresenta este tipo de recurso. Em um Sistema Gerenciador de Banco de Dados o recurso de compactao um pouco diferente em relao a estas ferramentas. O Microsoft SQL Server 2008 apresenta este recurso de forma nativa, sem necessitar de ferramentas externas ou de terceiros para trabalhar sobre as informaes armazenadas em tabelas ou ndices. Realizando uma anlise de acordo com os dados que se encontram armazenados nestes objetos e possibilitando aplicar a melhor forma de compactao. O processo de compactao necessita de uma identificao prvia da forma que o dado se encontra ou ser armazenado. Na verso atual, o SQL Server 2008 estabelece duas formas bsicas de compactao, chamadas: Compactao por linha de dados (registros) e Compactao por pgina de dados. No podemos dizer que existe a melhor forma de compactao ou a forma mais correta para realizar este processo. O que existe a necessidade de compactar um dado mediante o seu estado atual. Na compactao em nvel de linha de dados, o SQL Server dever procurar dimensionar cada linha de registros armazenadas em uma tabela ou ndice da forma a evitar fragmentao de dados, seja em uma nova linha ou a necessidade de criar mais uma pgina de dados. Na compactao em nvel de pgina de dados, a tarefa do SQL Server um pouco mais complicada. O processo de dimensionamento da informao no consiste simplesmente em identificar o tamanho do dado ou da linha, mas sim em estabelecer em qual pgina de dados aquele conjunto de informaes poder ser alocada, respeitando inicialmente os dados j armazenados na pgina como tambm a informao que poder ser repassada para outra pgina ou a criao de uma nova pgina. Durante a leitura deste artigo voc poder identificar as diversas caractersticas e peculiaridades existentes nos dois tipos de compactao. Estabelecer qual ser a mais indicada para sua necessidade no

tarefa deste artigo, nosso objetivo apresentar e demonstrar como utilizar este recurso muito til e de extrema importante. Conhecendo a compactao em nvel de linha de dados Como destacado anteriormente, a compactao em nvel de linha de dados representa um recurso para dimensionamento e alocao de informaes para cada linha de informaes (registros), armazenadas em uma tabela ou ndice. Sua utilizao est diretamente relacionada com cada informao manipulada sobre a tabela configurada para trabalhar com este tipo de compactao. Antes de utilizar a compactao de linhas de dados, torna-se necessrio conhecer algumas caractersticas e consideraes importantes desta forma de compactao, entre elas: - A compactao pode permitir que mais linhas sejam armazenadas em uma pgina devido diminuio do tamanho do dado que ser alocado em cada linha. Isso alcanado sem ultrapassar o tamanho por linha e evitando gerar qualquer tipo de fragmentao dos dados; - Somente as edies Enterprise e Developer do SQL Server 2008 possuem a capacidade de trabalhar com compactao de linhas e pginas; - Uma tabela no pode ser habilitada para compactao quando o tamanho mximo da linha mais a sobrecarga de compactao exceder o tamanho mximo de linha de 8060 bytes. Por exemplo, uma tabela que tem as colunas col1 char (8000) e col2 char (53) no pode ser compactada por causa da sobrecarga de compactao adicional; - Para a compactao de linha e de pgina, a verificao do tamanho da linha executada quando o objeto inicialmente compactado e, depois, verificado medida que cada linha inserida ou modificada. A compactao impe as seguintes regras: - Quando a estrutura de uma tabela modificada, a compactao existente preservada, a menos que especificada de outra maneira, atravs do nmero da partio ou da lista de parties. Esta lista de parties corresponde quantidade de parties existentes em uma Tabela. Caso seja especificado um valor ou uma faixa de valores fora do nmero de parties existentes o SQL Server ser forado a emitir uma mensagem de erro; - ndices no clusterizados no herdam a propriedade de compactao da tabela. Para compactar ndices preciso definir explicitamente a sua propriedade de compactao. Por padro, a configurao de compactao de ndices ser definida como NONE quando o ndice for criado; - Quando um ndice clusterizado criado em um heap, ele herda o estado de compactao do heap, a menos que um estado de compactao alternativo seja especificado. - Uma atualizao para um tipo de comprimento fixo sempre deve ter xito, por exemplo, se utilizamos uma coluna do tipo varchar (10) e alterarmos para um campo char (10); - A desabilitao da compactao de dados sempre deve ter xito. Mesmo que a linha compactada caiba em uma pgina (o que significa que ela menor do que 8060 bytes). Em alguns casos, a linha descompactada poder sofrer atualizaes que possam gerar a necessidade de armazenar estas alteraes em outra pgina de dados, mesmo que a atual pgina possua um pequeno espao livre. - Quando uma lista de parties especificada, o tipo de compactao deve ser definido como ROW, PAGE ou NONE em parties individuais, possibilitando uma melhor alocao de espao; A Tabela 1 apresenta um exemplo de como a compactao de dados em nvel de linha possibilita a diminuio do consumo do armazenamento de dados. Como a compactao de linha afeta o armazenamento A Tabela 2 descreve como a compactao de linha afeta os tipos existentes no SQL Server. Ela no destaca o possvel aumento do tamanho fsico de uma tabela caso a compactao utilizada esteja definida no nvel de pgina de dados. Em algumas situaes, o nvel de compactao de pgina de dados poder ocasionar o armazenamento de dados em novas pginas. Desta forma, o SQL Server ser obrigado a utilizar mais espao fsico do disco rgido para armazenamento destas informaes. A compactao em nvel de linha reduz a quantidade de metadados usado para armazenar a linha, ou seja, de acordo com tamanho informado para este tipo de dado, o SQL Server dever reservar e dimensionar o espao de alocao para o dado independente do tamanho real que o dado for ocupar.

A partir do momento em que utilizamos a compactao de dados sobre tipos de dados de tamanho fixo, Char, Nchar, entre outros. O SQL Server ir realizar o mesmo procedimento para dados de formato varivel, ou seja, se o dado CHAR (100) utilizar apenas 10 caracteres, os espaos em branco no utilizados sero descartados, podendo assim reduzir o espao necessrio para seu armazenamento.

Tabela 1. Compactao de dados aplicada em nvel de linha.

Tabela 2. Como a compactao em nvel de linha afeta cada tipo de dados.

Por outro lado, no sero compactados valores em campos de tamanho fixo ou varivel, caso a infomao passada apresentar valores nulos (NULL) ou for simplesmente um nmero 0 (zero), para a compactao em nvel de linha. Neste caso, no ocorrer nenhum ganho de armazenamento se comparado com o tamanho a original ocupado sem a compactao. A seguir destacaremos a forma de compactao em nvel de pgina de dados, suas caractersticas e consideraes. Conhecendo a compactao em nivel de pginas de dados Como destacado anteriomente, a compactao em nvel de pgina de dados est relacionada diretamente com as informaes armazenadas em cada pgina de dados que compem uma tabela. Esse recurso uma tarefa um pouco mais complicada em relao compactao em nvel de linha de dados. O processo de dimensionamento da informao no consiste simplesmente em identificar o tamanho do dado ou da linha, mas sim em estabelecer em qual pgina de dados aquele conjunto de informaes poder ser alocada, respeitando inicialmente os dados j armazenados na pgina como tambm a informao que poder ser repassada para outra pgina ou a criao de uma nova pgina. Quando uma tabela criada e seu nvel de compactao foi definido como pgina, o SQL Server no realizar qualquer tipo de compactao. A partir do momento em que os dados comearem a ser adicionados, os mesmos sero alocados na primeira pgina de dados, mas utilizando a compactao por linha. Este procedimento necessrio para que o SQL Server consiga identificar a pgina que o dado ser alocado posteriormente. A compactao por pgina ser realizada conforme a insero de novos dados. Durante o processo de insero de dados, o SQL Server dever dimensionar o tamanho de alocao destes dados para cada linha, no permitindo que o conjunto de dados ultrapasse o tamanho de 8060 bytes. Quando este valor ultrapassado, o SQL Server identificar esta linha de registro como uma linha cheia e inicia o processo de alocao do dado para uma prxima linha. Esta alocao ser realizada utilizando a compactao em nvel de pgina. Por outro lado, se o espao obtido pela compactao de pgina for menor que o espao exigido para o armazenamento dos dados, a compactao de pgina no ser utilizada para pgina. Caso a compactao de pgina tenha criado espao suficiente na pgina para uma linha adicional, esta linha ser adicionada e os dados sero compactados por linha e pgina. O armazenamento da informao nesta pgina ser realizada aps uma reviso em cada coluna que compem a tabela avaliada. Para realizar esta avaliao e validao o SQL Server utiliza por padro a chamada compactao de prefixo. Em seguida o SQL Server definir se utiliza a compactao de prefixo ou compactao por dicionrio. Tanto a compactao por prefixo e dicionrio sero destacadas posteriormente, A s linhas futuras sero ajustadas nova pgina se no couberem na pgina atual. O SQL Server dever adicionar tabela uma nova pgina de dados semelhante primeira pgina. Esta nova pgina no ser compactada imediatamente, ou seja, esta pgina dever ser dimensionada a partir do momento em que uma das linhas de dados ultrapassar o seu tamanho mximo. Assim, devemos destacar que a compactao de pginas de dados tambm necessita de uma anlise sobre algumas caractristas e consideraes importantes antes da sua aplicao, entre elas: - Quando um heap configurado para compactao em nvel de pgina, as pginas s recebem compactao em nvel de pgina nos seguintes modos: * Os dados so inseridos usando a sintaxe BULK INSERT; * Os dados so inseridos usando INSERT INTO ... Sintaxe WITH (TABLOCK); * Uma tabela recriada executando ALTER TABLE ... Instruo REBUILD com a opo de compactao PAGE. - As novas pginas alocadas em um heap como parte de operaes DML no usaro a compactao PAGE at o heap ser recompilado; - A alterao da configurao de compactao de um heap exige que todos os ndices no clusterizados na tabela sejam recriados, para que tenham ponteiros para os novos locais de linha no heap;

- Os requisitos de espao em disco para habilitar ou desabilitar a compactao de pgina ou de linha so os mesmos que para criar ou recriar um ndice. Para dados particionados voc pode reduzir o espao exigido para habilitar ou desabilitar a compactao para uma partio de cada vez; - Para determinar o estado de compactao das parties em uma tabela particionada, consulte a coluna data_compression existente no catlogo de vises (view catalog), chamada sys.partitions; - Quando voc estiver compactando ndices, as pginas de nvel folha podero ser compactadas com a compactao de linha e de pgina. As pginas que no so de nvel folha no recebem a compactao de pgina; - A compactao de dados no est disponvel para os dados armazenados separadamente. A compactao de pgina semelhante para tabelas, parties de tabela, ndices e parties de ndice. A compactao do nvel folha de tabelas e ndices usando a compactao de pgina consiste em trs operaes, nesta ordem: 1. Compactao de linha; 2. Compactao de prefixo; 3. Compactao de dicionrio. Este tipo compactao mais eficiente pois oferece um ganho a mais na compresso, entretanto, proporciona um aumento na utilizao da CPU. Quando voc usa a compactao de pgina, as pginas do nvel no-folha dos ndices so compactadas usando apenas a compactao de linha. Compactao em nvel de pgina utilizando a compactao por prefixo Nesta forma de compactao o SQL Server utiliza um caractere identificador chamado prefixo para procurar dados que possam apresentar caractersticas compatveis para esta tcnica de compactao. Este caractere dever identificar em cada informao armazenada sobre as colunas analisadas, os dados que podem ser compactados. Para cada pgina que est sendo compactada, a compactao de prefixo usa trs etapas para estabelecer a melhor forma de compactao: 1. Para cada coluna avaliada identificada qual informao poder ser compactada. Isto feito com o objetivo de reduzir o espao de armazenamento para os valores de cada coluna; 2. Uma linha que representa os valores de prefixo de cada coluna criada e armazenada em uma estrutura CI (informaes de compactao) que segue imediatamente o cabealho da pgina; 3. Os valores de prefixo repetidos da coluna so substitudos por uma referncia ao prefixo correspondente. Se o valor de uma linha no corresponder exatamente ao valor do prefixo selecionado, dever ser indicada uma correspondncia parcial. A Figura 1 a mostra um exemplo de pgina de uma tabela antes da compactao de prefixo.

Figura 1. Exemplo da pgina de dados antes da compactao do prefixo.

A Figura 2 mostra a mesma pgina aps a compactao de prefixo. O prefixo movido para o cabealho e os valores da coluna so alterados para referncias ao prefixo. Na primeira linha da primeira coluna o valor 4b indica que os primeiros quatro caracteres do prefixo (aaab) esto presentes para essa linha e, tambm, o caractere b na rea de cabealho da pgina. Isso gera o valor resultante aaabb, que o valor original.

Figura 2. Exemplo da pgina de dados aps a compactao do prefixo. Compactao em nvel de pgina utilizando a compactao por dicionrio Aps entendermos como realizada a compactao de prefixo, podemos agora conhecer a compactao de dicionrio. A compactao de dicionrio procura valores repetidos em qualquer lugar da pgina e os armazena na rea de informaes de compactao. Diferentemente da compactao de prefixo, a compactao de dicionrio no restrita a uma coluna. A compactao de dicionrio pode substituir valores repetidos que ocorrem em qualquer lugar de uma pgina. A Figura 3 mostra o mesmo exemplo da Figura 1 aps a compactao de dicionrio.

Figura 3. Exemplo pgina de dados aps a compactao do dicionrio.

O SQL Server realizou uma busca para identificar todos os dados repetidos, deslocando os mesmos para a rea de compactao no cabealho da pgina de dados. Observe que os valores [0bbbb] que se encontravam repetidos em duas colunas distintas agora o est armazenado no cabealho e possui um valor de identificao. Neste caso, o nmero 1 o nmero identificador dos dados que estavam armazenados nestas colunas. Agora que j conhecemos um pouco mais sobre as duas formas de compactao, suas principais caractersticas e particularidades, o que nos resta por a mo na massa e utilizar estes recursos. Para isso criaremos um ambiente de demonstrao trabalhando com um conjunto de informaes fictcias para auxiliar e melhorar nosso entendimento sobre o assunto. A seguir veremos como aplicar a compactao de dados utilizando o nvel de compactao por linha de dados e posteriormente a compactao de pgina de dados ser abordada. Aplicando a compactao de dados A forma de aplicao da compactao de dados consiste na utilizao das funcionalidades disponveis no Microsoft SQL Server 2008 sobre as tabelas e ndices disponveis. Iniciaremos o processo de demonstrao do uso destes recursos em nvel de linhas, atravs da criao do banco de dados SQLMagazine, conforme a Listagem 1. Posteriormente criaremos duas tabelas chamadas Revistas e RevistasCompactadas, onde a tabela Revistas no sofrer nenhum tipo de compactao de dados. O cdigo para criao das tabelas pode ser visto na Listagem 2. O processo de compactao de dados pode ser definido no momento da criao de uma nova tabela ou ndice, fazendo uso das instrues CREATE TABLE, de acordo com o Bloco 2 da Listagem 2. Listagem 1. Criao do Banco de dados -- Bloco 1 -Create Database SQLMagazine Go Use SQLMagazine Go Listagem 2. Criao das tabelas Revistas e RevistasCompactadas -- Bloco 1 -Create Table Revistas (Codigo SmallInt Identity(1,1) Primary Key, Descricao Varchar(50), Edicao Int Default(1), AnoPublicacao Int Default(2009)) On [Primary] Go -- Bloco 2 -Create Table RevistasCompactadas (Codigo SmallInt Identity(1,1) Primary Key, Descricao Varchar(50), Edicao Int Default(1), AnoPublicacao Int Default(2009)) On [Primary]

Agora que j temos o Banco e as tabelas criadas, vamos povoar estas tabelas com informaes fictcias para ilustrar nosso exemplo. Acompanhando a Listagem 3, encontramos as instrues para colocar informaes nas tabelas Revistas e RevistasCompactadas. Listagem 3. Inserindo dados nas tabelas Revistas e RevistasCompactadas -- Bloco 1 -Declare @Cont Int Set @Cont=1 While (@Cont <= 10000) Begin Insert Into Revistas Values (SQL Magazine,@Cont,2009) Set @Cont +=1; End Go -- Bloco 2 -Declare @Cont Int Set @Cont=1 While (@Cont <= 10000) Begin Insert Into RevistasCompactadas Values (SQL Magazine,@Cont,2009) Set @Cont +=1; End Go Agora, ambas as tabelas possuem informaes simulando tabelas verdadeiras. Se consultarmos os dados armazenados em cada tabela, poderemos observar que a insero de dados ocorreu normalmente. A seguir, a Figura 4 apresenta uma pequena relao de registros armazenados nas tabelas Revistas e RevistasCompactadas.

Figura 4. Dados armazenados nas tabelas Revistas e RevistasCompactadas.

Na Figura 4 podemos observar visualmente que a estrutura das tabelas e os dados existentes em cada uma no apresentam diferenas, sendo que, a tabela RevistasCompactadas est neste momento configurada para trabalhar com compactao de dados em nvel de linhas. Agora vamos comparar o espao fsico ocupado por cada tabela fazendo uso da system stored procedure sp_spaceused definida na Listagem 4. O resultado da execuo desta stored procedure exibido na Figura 5. Listagem 4. Consultando o espao fsico ocupado por cada tabela -- Bloco 1 -sp_spaceused Revistas Go -- Bloco 2 -sp_spaceused RevistasCompactadas Go

Figura 5. Comparativo entre a tabela Revistas e RevistasCompactadas. Analisando os resultados gerados atravs da system stored procedure sp_spaceused, podemos observar a diferena de tamanho no espao ocupado ploes dados na tabela RevistasCompactadas em relao a tabela Revistas. O prximo passo realizar algumas alteraes na forma de compactao dos dados, iniciando pela mudana do nvel de compactao de linha para pgina, de acordo com a Listagem 5. Listagem 5. Alterando o nvel de compactao da tabela RevistasCompactadas -- Bloco 1 -Alter Table RevistasCompactadas Rebuild With (DATA_COMPRESSION=PAGE) Go Aps a alterao na forma de compactao realizada na tabela RevistasCompactas, devemos verificar se o espao ocupado fisicamente por esta tabela sofreu alguma mudana. Para isso, executaremos o cdigo apresentado na Listagem 6. Voc poder observar alguma semelhana entre os resultados apresentados na Figura 6. Listagem 6. Consultando o espao fsico ocupado por cada tabela em nvel de pagina -- Bloco 1 -sp_spaceused Revistas Go -- Bloco 2 -sp_spaceused RevistasCompactadas Go

Figura 6. Comparativo entre a tabela Revistas e RevistasCompactadas com compactao em nvel de pgina. Mais uma vez a compactao de dados nos apresenta algumas mudanas em relao aos dados armazenados em uma tabela. Neste caso, observamos de forma clara que a compactao em nvel de pgina de dados dimensionou consideravelmente a alocao de dados, como tambm diminuiu o espao no alocado para o armazenamento dos dados compactados. Agora devemos verificar se esta alterao ocasionou alguma mudana nos dados armazenados na tabela RevistasCompactadas. Podemos consultar alguns registros, conforme demonstrado na Figura 7.

Figura 7. Dados armazenados nas tabela RevistasCompactadas.

Estimando o tamanho da tabela de acordo com sua compactao Depois de vrios testes realizados, temos a certeza de que a compactao de dados em nvel de linhas ou pginas de dados pode apresentar diferenas no armazenamento fsico dos dados. Agora vamos conhecer como podemos realizar uma estimativa do tamanho de uma tabela de acordo com sua compactao. A compactao pode ser avaliada para tabelas inteiras ou partes de tabelas. Isso inclui heaps, ndices clusterizados, ndices no clusterizados, exibies indexadas e parties de tabelas e ndices. Estruturas de tabela podem ser compactadas usando compactao de linha ou de pgina. Se a tabela, ndice ou partio j estiverem compactadas, possvel usar esse procedimento para estimar o tamanho da tabela, do ndice ou da partio se eles forem descompactados. Para realizar esta estimativa do tamanho de uma tabela devemos utilizar a system stored procedure sp_estimate_data_compression_savings, conforme a sintaxe apresentada na Listagem 7 e descrita na Tabela 3.

Listagem 7. Sintaxe da sp_estimate_data_compression_savings -- Bloco 1 -sp_estimate_data_compression_savings [ @schema_name = ] schema_name , [ @object_name = ] object_name , [@index_id = ] index_id , [@partition_number = ] partition_number , [@data_compression = ] data_compression [;]

Tabela 3. Conjunto de resultados retornados para fornecer o tamanho atual e estimado da tabela, ndice ou partio. No cdigo apresentado na Listagem 7: - [ @schema_name = ] schema_name: o nome do esquema de banco de dados que contm a tabela ou viso indexada. Se schema_name no for informado, ou seja, considerado NULL, o esquema padro do usurio atual ser usado, pois o SQL Server no considera um schema_name definido como NULL; - [ @object_name = ] object_name: o nome da tabela ou viso indexada onde ndice est; - [ @index_id = ] index_id: o ID do ndice. O index_id int e pode ter um dos seguintes valores: o nmero do ID de um ndice, NULL ou 0 se object_id for um heap. Para retornar informaes de todos os ndices de uma tabela base ou viso, especifique NULL. Se voc especificar NULL, tambm dever especificar NULL para partition_number, com isso, o SQL Server tentar estimar o espao de compactao de dados para tabelas desconsiderando a existncia ou no de particionamento; - [ @partition_number = ] partition_number: o nmero da partio no objeto. partition_number int e pode ter um dos seguintes valores: o nmero da partio de um ndice ou heap, NULL ou 1 para um heap ou ndice no particionado. Para especificar a partio, tambm possvel especificar a funo $partition. Para retornar informaes de todas as parties do objeto proprietrio, especifique NULL; - [ @data_compression = ] data_compression: o tipo de compactao a ser avaliada. data_compression pode ser um dos seguintes valores: NONE, ROW ou PAGE. Nota Devman - Row Altera somente o formato de armazenamento fsico dos dados associados a um tipo de dados, mas no sua sintaxe ou semntica. No so exigidas alteraes de aplicativo quando uma ou mais tabelas so habilitadas para compactao. Nota Devman - Page A compactao de pgina semelhante para tabelas, parties de tabela, ndices e parties de ndice.

Como j conhecemos a finalidade da sp_estimate_data_compression_savings, agora temos a possibilidade de realizar o clculo da estimativa do tamanho da tabela, como pode ser visto nas Listagens 8 e 9. O resultado apresentado nas Figuras 8 e 9. Listagem 8. Obtendo os resultados da estimativa de compactao em nvel de linha -- Bloco 1 EXEC sp_estimate_data_compression_savings dbo, RevistasCompactadas, NULL, NULL, ROW

Figura 8. Estimativa do tamanho da compactao em nvel de linha. A Figura 8 apresenta os resultados de estimativa do tamanho da tabela com base na compactao em nvel de linha para a tabela RevistasCompactadas. Com base neste resultado, podemos observar uma possvel mudana no tamanho fsico da tabela RevistasCompactadas, representando um ganho na alocao do espao em disco. Listagem 9. Obtendo os resultados da estimativa de compactao em nvel de pgina -- Bloco 1 EXEC sp_estimate_data_compression_savings dbo, RevistasCompactadas, NULL, NULL, PAGE

Figura 9. Estimativa do tamanho da compactao em nvel de pgina de dados. Nota Devman - Parties individuais O particionamento pode ser atingido sem dividir tabelas, colocando-se as tabelas fisicamente em unidades individuais de disco. Colocar uma tabela em uma unidade fsica e as tabelas relacionadas em uma unidade separada pode vir a melhorar o desempenho das consultas, pois, quando as consultas que envolvem junes entre as tabelas forem executadas, diversos cabeotes de discos lero os dados ao mesmo tempo. Grupos de arquivos do SQL Server podem ser usados para especificar em quais discos colocar as tabelas Nota Devman - none Representa que a tabela selecionada no utilizar compactao de dados. Concluso Atravs da compactao de dados presente no SQL Server 2008, possvel melhorar a alocao de dados armazenados fisicamente, como tambm evitar possveis desperdcios de espao em disco sem gerar perda de performance. O artigo demonstrou o conceito e a prtica deste recurso presente no SQL Server 2005 SP 2 e melhorado no SQL Server 2008. Aprendemos com os exemplos a utilizar a compactao de dados em nvel de linha e pgina de dados, suas principais consideraes e impactos em relao aos dados armazenados em uma tabela tanto no momento da sua criao, como tambm aps os dados j estarem armazenados.

Gerenciando Usurios e Permisses no PostgreSQL


Willamys Rangel Nunes de Sousa Atua no ramo de tecnologia da informao e banco de dados h mais de 5 anos. Atualmente professor do Instituto Federal de Educao, Cincia e Tecnologia do Piau (IFPI). Possui especializao em Banco de Dados e graduado em tecnologia da Informao. De que se trata o artigo: O artigo aborda os conceitos relacionais com gerenciamento de usurios e permisses de acesso em SGBDs, focando o PostgreSQL. Neste artigo, foi implementado um estudo de caso para demonstrar na prtica as funes do PostgreSQL no que se refere ao gerenciamento de usurios. Para que serve: O contedo deste artigo visa solucionar problemas inerentes do acesso a dados em um SGBD, buscando formas eficientes de controlar as permisses dos usurios. Em que situao o tema til: Em toda aplicao com conexo a banco de dados importante o controle de acesso diferenciado para cada papel de usurio no sistema. Tendo em vista isto, este artigo torna-se uma boa opo de fonte de pesquisa.

A segurana dos sistemas de informao engloba um nmero elevado de reas que podero estar sob a responsabilidade de uma ou vrias pessoas. Entre estas reas encontram-se a segurana de redes, a segurana fsica, a segurana de computadores, a segurana das aplicaes, a segurana da informao etc. O responsvel pela implementao da segurana dos sistemas de informao em uma organizao possui como primeira misso, e mais importante, a garantia da segurana da informao que protege. Esta garantia conseguida mediante a utilizao de vrios instrumentos. Uma poltica de backup e recuperao de dados adequadamente elaborada e executada proteger a organizao contra a perda de informao devido a falhas de hardware, defeitos de software, erros humanos, intrusos, sabotagem e desastres naturais. Entretanto, esta no a nica maneira existente de proteo das informaes. Afinal, precisamos mais do que uma soluo relativa ao acontecimento de falhas. Quando se trata de proteger informaes guardadas em banco de dados, nos preocupamos em que dados proteger e como proteg-los. Os SGBDs atuais nos fornecem poderosas ferramentas que auxiliam em tais tarefas. Sendo os bancos de dados sistemas de armazenamento de informao, e sendo esta um elemento de elevado valor, quer seja financeiro, quer seja estratgico, necessrio que haja algum tipo de controle de acesso a essa informao. Para mantermos a integridade das informaes e realizarmos auditoria das mesmas, podemos utilizar os recursos dos gatilhos. Alm disso, podemos fazer uso de uma linguagem especial para controle de acesso e permisso aos dados. Esta linguagem a DCL (Data Control Language - Linguagem de Controle de Dados). Ela um subconjunto da SQL para o controle de permisses dos usurios aos objetos do banco de dados. Neste artigo, ser demonstrado o funcionamento do controle de permisses de acesso aos objetos do banco de dados PostgreSQL.

Administrando Usurios e Privilgios no PostgreSQL Todo agrupamento de bancos de dados possui um conjunto de usurios de banco de dados. Estes usurios so distintos dos usurios gerenciados pelo sistema operacional onde o servidor executa. Eles possuem objetos de banco de dados (por exemplo, tabelas, vises etc.), e podem conceder privilgios nestes objetos para outros usurios controlando, assim, quem pode acessar qual objeto. A DCL controla os aspectos de autorizao de dados e licenas de usurios para controlar quem tem acesso para ver ou manipular dados dentro do banco de dados. Os nomes dos usurios de banco de dados so globais para todo o agrupamento de bancos de dados (e no apenas prprio de cada banco de dados). No decorrer deste artigo, veremos conceitos relacionados a usurios, grupos e roles (papis), ao passo que aprenderemos como cri-los e quando utiliz-los em nossas aplicaes. Criao de Usurio de Banco de Dados - CREATE USER Como foi mencionado, existem usurios que so independentes do sistema operacional, que servem para manipular objetos do SGBD. No PostgreSQL existe o comando CREATE USER que adiciona um novo usurio no bancos de dados. Este comando j foi muito utilizado, mas mesmo ainda funcionando, hoje apenas um alias para o comando CREATE ROLE que veremos mais adiante. O comando genrico de criao de um usurio est exibido na Listagem 1. Listagem 1. Comando de Criao de um gatilho no PostgreSQL CREATE USER nome [ [ WITH ] opo [ ... ] ] As opes que acompanham este comando esto listadas na Tabela 1.

Tabela 1. Opes do comando CREATE USER. Removendo um Usurio no Banco de Dados - DROP USER Uma vez criado no banco de dados, o comando DROP USER remove o usurio especificado. Porm, esse comando no remove as tabelas, vises ou outros objetos pertencentes ao usurio. Se o usurio possuir algum banco de dados, uma mensagem de erro ser gerada. O comando que remove um usurio do PostgreSQL est mostrado na Listagem 2 . Listagem 2. Comando que remove um usurio no PostgreSQL DROP USER nome_usurio

Neste caso, nome_usurio refere-se ao usurio que est sendo removido. Para remover um usurio que possui um banco de dados, primeiro remove-se o banco de dados ou muda-se o dono do mesmo. Alterando um Usurio - ALTER USER Em alguns casos, conveniente modificar um usurio, seja para alterar sua senha ou validade da mesma ou para incluir a permisso de criao de usurios ou retir-la, caso exista etc. O comando para modificar um usurio o ALTER USER e est demonstrado na Listagem 3. Listagem 3. Comando que altera um usurio no PostgreSQL ALTER USER nome [ [ WITH ] opo [ ... ] ] As opes desse comando so exibidas na Tabela 2.

Tabela 2. Opes do comando ALTER USER Uma variao do comando ALTER USER exibido na Listagem 4, muda o nome de um usurio. importante comentar que apenas um super-usurio pode mudar o nome de outro usurio. Listagem 4. Comando para alterar o nome de um usurio ALTER USER nome RENAME TO novo_nome Conceitos de Grupos de Usurios no PostgreSQL Assim como nos sistemas operacionais baseados em Unix, os grupos so uma forma lgica de juntar usurios para facilitar o gerenciamento de privilgios. Tais privilgios podem ser concedidos, ou revogados, para o grupo como um todo. Para criar um grupo, deve ser utilizado o comando CREATE GROUP, como mostrado na Listagem 5. Listagem 5. Comando para criar um grupo no PostgreSQL CREATE GROUP nome_do_grupo;

Podemos adicionar ou remover usurios em um grupo existente utilizando o comando ALTER GROUP da Listagem 6, respectivamente. Uma vez criado um grupo, ainda podemos remov-lo. Tal operao pode ser feita usando o comando DROP GROUP, conforme Listagem 7. O comando DROP GROUP remove os grupos, mas no remove os usurios membros do grupo. Uma coisa importante que deve ser comentada que no existe o comando CREATE GROUP no padro SQL. O conceito de "papis" (roles) que veremos adiante semelhante ao de grupos e ser o foco principal deste artigo.

Alterando Grupos no PostgreSQL - ALTER GROUP Assim como podemos modificar um usurio criado no banco de dados, podemos, da mesma forma, modificar um grupo. Para fazermos isso, utilizamos o comando ALTER GROUP. A Listagem 8 adiciona, remove e altera usurios em um grupo, respectivamente. Listagem 6. Comandos para adicionar e remover usurios em um grupo ALTER GROUP nome_do_grupo ADD USER nome_do_usurio; ALTER GROUP nome_do_grupo DROP USER nome_do_usurio; Listagem 7. Comando para remover um grupo no PostgreSQL DROP GROUP nome_do_grupo; Listagem 8. Comandos para alterar um grupo no PostgreSQL ALTER GROUP nome_do_grupo ADD USER nome_do_usurio; ALTER GROUP nome_do_grupo DROP USER nome_do_usurio; ALTER GROUP nome_do_grupo RENAME TO novo_nome; Criando Papis (roles) no PostgreSQL - CREATE ROLE O comando CREATE ROLE adiciona um novo papel (role) ao agrupamento de bancos de dados do PostgreSQL. O papel uma entidade que pode possuir objetos do banco de dados e possuir privilgios do banco de dados. Ele pode ser considerado como sendo um "usurio", um "grupo", ou ambos, dependendo de como utilizado. O comando CREATE ROLE o substituto dos comandos CREATE USER e CREATE GROUP por possuir mais recursos que os mesmos. A Listagem 9 demonstra o comando de criao de um ROLE, enquanto a Tabela 3 explica as opes que podem ser utilizadas neste comando. Listagem 9. Comando para criar um role no PostgreSQL CREATE ROLE nome [ [WITH] opo [...]];

Tabela 3. Opes do comando CREATE ROLE.

Removendo um Role - DROP ROLE O comando DROP ROLE remove os papis especificados. A Listagem 10 demonstra como o comando DROP ROLE funciona. Listagem 10. Comando para remover um role no PostgreSQL DROP ROLE [ IF EXISTS ] nome [, ...] O papel no poder ser removido se ainda estiver sendo referenciado em qualquer banco de dados do agrupamento. Assim ser lanado um erro caso tente-se remov-lo. Antes de remover o papel, necessrio remover todos os objetos pertencentes ao mesmo (ou mudar o dono), e revogar todos os privilgios concedidos pelo papel. Alterando um Role - ALTER ROLE O comando ALTER ROLE altera os atributos de um papel do PostgreSQL. demonstra o comando genrico de alterao de um role. Listagem 11. Comando para alterar um role no PostgreSQL ALTER ROLE nome [ [ WITH ] opo [ ... ] ] O comando ALTER ROLE pode modificar um role, utilizando as mesmas opes mostradas na Tabela 3. Concedendo e Revogando Privilgios no PostgreSQL Quando um objeto do banco de dados criado, atribudo um dono ao mesmo. O dono o usurio que executou o comando de criao do objeto. Para mudar o dono de uma tabela, ndice, seqncia ou viso deve ser utilizado o comando ALTER TABLE. A Listagem 12 mostra a modificao de um dono de uma tabela de um banco de dados. Por padro, somente o dono (ou um super-usurio) pode fazer qualquer coisa com o objeto. Para permitir o uso por outros usurios, devem ser concedidos privilgios aos mesmos. Em SQL, existe o comando GRANT. Ele possui duas funcionalidades bsicas: conceder privilgios para um objeto do banco de dados (tabela, viso, seqncia, banco de dados, funo, linguagem procedural, esquema e espao de tabelas) e conceder o privilgio de ser membro de um papel. Existem vrios privilgios distintos: SELECT, INSERT, UPDATE, DELETE, RULE, REFERENCES, TRIGGER, CREATE, TEMPORARY, EXECUTE, USAGE e ALL PRIVILEGES. A Tabela 4 exibe os privilgios possveis e os seus significados. Listagem 12. Comando para alterar um dono de uma tabela no PostgreSQL ALTER TABLE nome_da_tabela OWNER TO novo_dono A Listagem 11

Tabela 4. Todos os possveis privilgios de acesso Em alguns casos tambm se torna necessrio revogar alguns privilgios de acesso a usurios ou grupos de usurios. Para que isso seja feito, utiliza-se o comando REVOKE. Deve ser observado que os super-usurios do banco de dados podem acessar todos os objetos, independentemente dos privilgios definidos para o objeto. Assim, no aconselhvel operar como um super-usurio a no ser quando for absolutamente necessrio. Se um super-usurio decidir submeter o comando GRANT ou REVOKE, o comando ser executado como se tivesse sido submetido pelo dono do objeto afetado. Em particular, os privilgios concedidos atravs destes comandos aparecero como se tivessem sido concedidos pelo dono do objeto. Atualmente, o PostgreSQL no suporta conceder ou revogar privilgios para as colunas da tabela individualmente. Uma forma simples de contornar isso seria criar uma viso contendo apenas as colunas desejadas e, ento, conceder os privilgios para a viso. Os privilgios especiais do dono da tabela (ou seja, o direito de DROP (remover), GRANT (conceder), REVOKE (revogar), etc.) so sempre implcitos ao fato de ser o dono, no podendo ser concedidos ou revogados. Estudo de Caso Hotel Para demonstrar o controle de permisses de acesso aos objetos de um banco de dados no PostgreSQL, foi criado um banco de dados de um hotel fictcio. Este banco de dados possui as tabelas cliente, reserva, hospedagem, quarto, tipo_quarto, atendimento e servio. No exemplo, foi considerado que cada cliente pode realizar vrias reservas e vrias hospedagens. Alm de, a cada hospedagem, solicitar vrias servios. Ainda interessante notar que os quartos podem ser de tipos diferentes (apartamento simples, sute casal, sute luxo etc.). A Figura 1 apresenta o diagrama Entidade-Relacionamento do banco de dados em estudo.

Figura 1. Diagrama Entidade-Relacionamento de um hotel. Neste banco de dados, alm das tabelas foram criadas trs funes e uma viso. A primeira funo chamada de adicionaReserva e serve para realizar a reserva de um determinado quarto para um cliente. Uma outra funo, chamada adicionaHospedagem, cria uma hospedagem para o cliente em um quarto. A ltima funo, denominada realizaPedido, ser responsvel por registrar os pedidos feitos pelos clientes, enquanto estiverem hospedados. Alm das funes mencionadas, existe a viso listaClientes, que exibe apenas os nomes e os sexos dos clientes, descartando o RG e o telefone dos mesmos. A viso listaClientes foi criada para demonstrar a permisso de acessar apenas algumas colunas de uma determinada tabela. Tambm foram criados alguns roles e foram dadas permisses diferentes de acesso aos dados para os mesmos. A Tabela 5 mostra os trs roles (neste caso, servem para definir o perfil de alguns grupos de usurios) que tm acesso ao banco e que tipo de permisso cada um deles possui. Implementao do Banco de Dados Hotel no PostgreSQL O PostgreSQL ser utilizado para criar o banco de dados, as funes, a viso e os roles citados na seo anterior. A ferramenta grfica PgAdmin III foi utilizada para a criao do banco de dados do estudo em caso. A Listagem 13 exibe o comando SQL para criao do banco de dados chamado hotel.

Tabela 5. Roles do banco de dados hotel Listagem 13. Comando SQL para criao do banco hotel CREATE DATABASE hotel;

As tabelas do banco de dados hotel so criadas pelos comandos da Listagem 14. Listagem 14. Comandos SQL para criao das tabelas do banco hotel // Tabela de CLIENTES CREATE TABLE cliente ( rg NUMERIC NOT NULL, nome VARCHAR(40) NOT NULL, sexo CHAR(1) NOT NULL, telefone NUMERIC(10,0), PRIMARY KEY (rg) ) WITHOUT OIDS; // Tabela TIPO_QUARTO CREATE TABLE tipo_quarto ( id_tipo SERIAL NOT NULL, descricao VARCHAR(40) NOT NULL, valor NUMERIC(9,2) NOT NULL, PRIMARY KEY (id_tipo) ) WITHOUT OIDS; // Tabela QUARTO CREATE TABLE quarto ( num_quarto INTEGER NOT NULL, andar CHAR(10), id_tipo INTEGER NOT NULL, status CHAR(01) NOT NULL DEFAULT D, PRIMARY KEY (num_quarto), FOREIGN KEY (id_tipo) REFERENCES tipo_quarto (id_tipo) ON UPDATE RESTRICT ON DELETE RESTRICT ) WITHOUT OIDS; // Tabela SERVIO CREATE TABLE servico ( id_servico SERIAL NOT NULL, descricao VARCHAR(60) NOT NULL, valor NUMERIC(9,2) NOT NULL, PRIMARY KEY (id_servico) ) WITHOUT OIDS;

// Tabela RESERVA CREATE TABLE reserva ( id_reserva SERIAL NOT NULL, rg NUMERIC NOT NULL, num_quarto INTEGER NOT NULL, dt_reserva DATE NOT NULL, qtd_dias INTEGER NOT NULL, data_entrada DATE NOT NULL, status CHAR(1) NOT NULL DEFAULT A, PRIMARY KEY (id_reserva), FOREIGN KEY (rg) REFERENCES cliente (rg) ON UPDATE RESTRICT ON DELETE RESTRICT, FOREIGN KEY (num_quarto) REFERENCES quarto (num_quarto) ON UPDATE RESTRICT ON DELETE RESTRICT ) WITHOUT OIDS; // Tabela HOSPEDAGEM CREATE TABLE hospedagem ( id_hospedagem SERIAL NOT NULL, rg NUMERIC NOT NULL, num_quarto INTEGER NOT NULL, data_entrada DATE NOT NULL, data_saida DATE, status CHAR(1) NOT NULL, PRIMARY KEY (id_hospedagem), FOREIGN KEY (rg) REFERENCES cliente (rg) ON UPDATE RESTRICT ON DELETE RESTRICT, FOREIGN KEY (num_quarto) REFERENCES quarto (num_quarto) ON UPDATE RESTRICT ON DELETE RESTRICT ) WITHOUT OIDS; // Tabela ATENDIMENTO CREATE TABLE atendimento ( id_atendimento SERIAL NOT NULL, id_servico INTEGER NOT NULL, id_hospedagem INTEGER NOT NULL, PRIMARY KEY (id_atendimento), FOREIGN KEY (id_servico) REFERENCES servico (id_servico) ON UPDATE RESTRICT ON DELETE RESTRICT, FOREIGN KEY (id_hospedagem) REFERENCES hospedagem (id_hospedagem) ON UPDATE RESTRICT ON DELETE RESTRICT ) WITHOUT OIDS;

As funes adicionaHospedagem, adicionaReserva e realizaPedido so criadas com os comandos das Listagens 15, 16 e 17, respectivamente. Listagem 15. Comando de criao da funo adicionaHospedagem CREATE OR REPLACE FUNCTION adicionaHospedagem(rg_cliente numeric, numero_quarto int) RETURNS void AS $$ begin perform * from cliente where rg = rg_cliente; if found then perform * from quarto where upper(status) = D and num_quarto = numero_quarto; if found then insert into hospedagem values (default, rg_cliente, numero_quarto, current_date, null, A); update quarto set status = O where num_quarto = numero_quarto; RAISE NOTICE Hospedagem realizada com sucesso!; else RAISE EXCEPTION Quarto indisponivel para hospedagem!; end if; else RAISE EXCEPTION Cliente nao consta no cadastro!; end if; end; $$ LANGUAGE plpgsql SECURITY DEFINER;

Listagem 16. Comando de criao da funo adicionaReserva CREATE OR REPLACE FUNCTION adicionaReserva (rg_cliente numeric, numero_quarto int, dias int, data_entrada date) RETURNS void AS $$ begin perform * from cliente where rg = rg_cliente; if found then perform * from quarto where upper(status) = D and num_quarto = numero_quarto; if found then insert into reserva values (default, rg_cliente, numero_quarto, current_date, dias, data_entrada, A); update quarto set status = R where num_quarto = numero_quarto; RAISE NOTICE Reserva realizada com sucesso!; else RAISE EXCEPTION Quarto indisponivel para reserva!; end if; else RAISE EXCEPTION Cliente nao consta no cadastro!; end if; end; $$ LANGUAGE plpgsql SECURITY DEFINER; Listagem 17. Comando de criao da funo realizaPedidos CREATE OR REPLACE FUNCTION realizaPedido(hosp int, serv int) RETURNS void AS $$ begin perform * from hospedagem where upper(status) = A and id_hospedagem = hosp; if found then perform * from servico where id_servico = serv; if found then insert into atendimento values (default, serv, hosp); RAISE NOTICE Pedido realizado com sucesso!; else RAISE EXCEPTION Servico indisponivel!; end if; else RAISE EXCEPTION Hospedagem nao consta no cadastro ou ja foi desativada!; end if; end; $$

LANGUAGE plpgsql SECURITY DEFINER; No interessante que alguns usurios acessem todas as informes sobre os clientes, como, por exemplo, o RG e o tefefone. Por esse motivo, foi criada uma viso que permite apenas visualizar apenas o nome e o sexo dos clientes (veja Listagem 18). Tendo definido os trs tipos de usurios que tero acesso aos objetos do banco de dados (veja Tabela 5), agora criaremos cada um (veja Listagem 19) e, mais adiante, daremos as permisses que ambos tm direito. Depois de criarmos todos os papis que iro agrupar todos os usurios com perfis semelhantes, temos que dar as permisses para cada tipo, de acordo com o que foi definido anteriormente. Antes de dar as permisses sobre as funes importante explicar a opo SECURITY DEFINER usada na criao das trs funes. Esta opo serve para permitir que todos os usurios acessem essas funes com a mesma permisso de quem as criou. Isto muito importante, pois os usurios dos grupos atendente e estagirio no tm acesso s tabelas do banco de dados hotel, ento no poderiam execut-las. Por exemplo, os grupos atendente e estagirio no executariam a funo adicionaHospedagem, porque na sua definio existem consultas que buscam valores que esto em algumas tabelas como clientes e quartos e esses grupos de usurios no tm permisso para acessa-las. Para resolver este problema, foram criadas todas as funes com a opo SECURITY DEFINER, e antes de dar a permisso de execuo para os grupos gerente, atendente e estagirio, deve-se revogar o direito de qualquer usurio do banco executar tais funes. Os comandos que revogam o execuo das funes adicionaHospedagem, adicionaReserva e realizaPedido pelos usurios, esto exibidos na Listagem 20. Listagem 18. Criao da viso para consultar o nome e o sexo dos clientes CREATE VIEW listaClientes (nome_cliente,sexo) AS SELECT nome, sexo FROM cliente Listagem 19. Criao dos papis (roles) gerente, atendente e estagirio CREATE ROLE gerente; CREATE ROLE atendente; CREATE ROLE estagiario; Listagem 20. Revogando a execuo das trs funes para todos os usurios REVOKE ALL ON FUNCTION adicionaReserva(numeric,int,int,date) FROM PUBLIC; REVOKE ALL ON FUNCTION adicionaHospedagem(numeric,int) FROM PUBLIC; REVOKE ALL ON FUNCTION realizaPedido(int,int) FROM PUBLIC; Feito isso, podemos agora dar as permisses de acesso para cada um dos grupos de usurios. O papel gerente poder modificar todos os registros de todas as tabelas (veja Listagem 21), alm de acessar as funes adicionaReserva (veja Listagem 22), adicionaHospedagem (veja Listagem 23) e listaClientes (veja Listagem 24) e a viso listaClientes (veja Listagem 25). Listagem 21. Concedendo permisso para o role gerente acessar todas as tabelas e conceder permisses para outros usurios GRANT SELECT, INSERT ON cliente, reserva, hospedagem, quarto, tipo_quarto, atendimento, servico, listaClientes TO gerente WITH GRANT OPTION; Listagem 22. Concedendo permisso para o role gerente para acessar a funo adicionaHospedagem GRANT EXECUTE ON FUNCTION adicionaHospedagem(numeric,int) TO gerente;

Listagem 23. Concedendo permisso para o role gerente para acessar a funo adicionaReserva GRANT EXECUTE ON FUNCTION adicionaReserva(numeric,int,int,date) TO gerente; Listagem 24. Concedendo permisso para o role gerente para acessar a funo realizarPedido GRANT EXECUTE ON FUNCTION realizaPedido(int,int) TO gerente; Listagem 25. Concedendo permisso para o role gerente para acessar a view listaClientes GRANT SELECT ON listaClientes TO gerente O grupo de usurios atendente no pode ter acesso a nenhuma tabela. Ele pode apenas acessar as funes adicionaHospedagem, adicionaReserva e realizaPedidos. As permisses para acessar tais funes esto disponveis nas Listagens 26, 27 e 28, respectivamente. Listagem 26. Concedendo permisso para o role atendente para acessar a funo adicionaHospedagem GRANT EXECUTE ON FUNCTION adicionaHospedagem(numeric,int) TO atendente; Listagem 27. Concedendo permisso para o role atendente para acessar a funo adicionaReserva GRANT EXECUTE ON FUNCTION adicionaReserva(numeric,int,int,date) TO atendente; Listagem 28. Concedendo permisso para o role atendente para acessar a funo realizaPedidos GRANT EXECUTE ON FUNCTION realizaPedido(int,int) TO atendente; A Listagem 29 d a permisso para o grupo de usurios do tipo estagirio acessar a viso listaClientes. Com o banco de dados, as funes, a viso e os usurios criados, j podemos realizar testes para verificar se o que foi permitido para cada tipo de usurio est de acordo com cada um dos seus perfis. Simulando Testes para Validar as Permisses Com todos os papis criados, iremos realizar alguns testes para validar as permisses que foram concedidas para cada um dos papis. Em um primeiro momento, sero criados trs usurios pertencentes a cada um dos papis criados (gerente, atendente e estagirio). A Listagem 30 exibe a criao do um usurio chamado tony e que pertencer ao grupo de usurios gerente. O parmetro LOGIN permite que o usurio possa logar no sistema e o parmetro PASSWORD atribui a senha 111 para o mesmo. Por sua vez, a Listagem 31 cria o usurio maria com direito de logar no sistema, mas agora pertencendo ao grupo de atendentes. O ltimo usurio criado a vitoria. Ela pertencer ao grupo de estagirios e sua criao est mostrada na Listagem 32. Listagem 29. Concedendo permisso para o role estagirio acessar a viso listaCliente GRANT SELECT ON listaClientes TO estagiario; Listagem 30. Criao de usurio com papel de gerente CREATE ROLE tony LOGIN PASSWORD 111 IN ROLE gerente; Listagem 31. Criao de usurio com papel de atendente CREATE ROLE maria LOGIN PASSWORD 222 IN ROLE atendente;

Listagem 32. Criao de usurio com papel de atendente CREATE ROLE vitoria LOGIN PASSWORD 333 IN ROLE estagiario; Com o usurio tony logado, pode-se realizar todas as operaes com as tabelas, exceto operaes prprias dos donos dos objetos, como por exemplo, remover uma tabela (DROP TABLE). Quando este usurio tenta executar o comando de incluso de um novo cliente, conforme Figura 2, o sistema executa o comando normalmente.

Figura 2. Usurio tony incluindo um novo cliente. Se usurio tambm tentar realizar qualquer operao (SELECT, DELETE, UPDATE, INSERT) com qualquer uma das tabelas, o sistema executar o comando normalmente. Porm, o mesmo no ocorrer, caso ele tente remover uma tabela do banco de dados (veja Figura 3).

Figura 3. Usurio tony tentando apagar do banco de dados a tabela tipo_quarto Agora com o usurio maria logado, tenta-se utilizar a funo adicionaReserva, conforme Figura 4.

Figura 4. Usurio maria acessando a funo adicionaReserva

O mesmo no aconteceria se esse usurio tentasse acessar diretamente a tabela reserva, porque o seu perfil no tem permisso para isto (veja Figura 5).

Figura 5. Usurio maria tentando selecionar os registros da tabela reserva

Por ltimo, com o usurio vitoria, tenta-se consultar a viso listaClientes (veja Figura 6). Verifique que vitoria no teve problema porque o seu perfil tem permisso para consultar somente a viso listaClientes. O mesmo no ocorreria caso ele tentasse consultar diretamente a tabela cliente (veja Figura 7).

Figura 6. Usurio vitria acessando a viso listaClientes

Figura 7. Vitria tentando consultar diretamente a tabela cliente

Concluso Segurana importante em todos os nveis, principalmente a nvel de informao. Hoje o maior patrimnio de uma empresa so seus dados e por isso to importante preserva-los ntegros. Com o que foi visto neste artigo, percebe que podemos controlar de forma bastante eficaz os nossos dados, dando permisso de acesso queles que possuem determinadas caractersticas e dar acesso diferenciado para outros. O PostgreSQL um SGBD bastante utilizado e como foi visto, uma excelente opo por vrios motivos, alm de permitir meios eficazes de controle de acesso aos dados.

Desvendando o Oracle Data Integrator


Rodrigo Atkinson Graduado em Informtica - Sistemas de Informaes e Mestre em Gesto de Organizaes com nfase em Sistemas de Informaes. J atuou como DBA, Analista de BI\DW. Atualmente professor do curso de Graduao da FTEC-POA. Rodrigo Radtke de Souza Graduado em Engenharia de Computao pela FURG e certificado Java SCJP e SCWCD. Atualmente trabalha como analista de sistemas em Porto Alegre. De que trata o artigo: Uso da ferramenta Oracle Data Integrator (ODI) para a construo de processos ETL (Extract, Transform, Load). Neste artigo, utilizaremos o ODI para integrar dados de diferentes origens (SGBD Oracle, Firebird e arquivo texto) para uma base de destino Oracle. Para que serve: O ODI nos permite transformar o trabalho, muitas vezes maante, da construo de processos ETLs, em interfaces e fluxos de fcil desenvolvimento, manuteno e visualizao. Em que situao o tema til: Alm de padronizar e otimizar processos de ETL, o ODI capaz de fazer a integrao de diferentes tecnologias e bancos de dados em um nico lugar, facilitando o trabalho de qualquer projeto que necessite fazer integrao de dados. Para retomarmos a estrutura apresentada no artigo publicado na SQL Magazine 65, vamos relembrar de que maneira est estruturada e armazenada as tabelas envolvidas no processo de ETL. Como explicado, embora nosso modelo esteja em um DER nico, nossas origens esto armazenadas em estruturas diferentes: as tabelas Cliente, TipoCliente, Venda e Vendedor esto alocadas no banco de dados ORACLE; as tabelas Grupo, Item e ItVenda esto no FIREBIRD; e ainda vamos utilizar uma fonte de dados oriunda de arquivo texto. Para facilitar o entendimento e a leitura dos tpicos apresentados a seguir, vamos disponibilizar no contexto da estrutura relacional apresentada no primeiro artigo, todas as DDLs e DMLs envolvidas nos processos descritos. Estes scripts podem ser obtidos no site da revista SQL Magazine. Iniciando o desenvolvimento Depois de configurada todas as Topologias (passos apresentados na primeira parte do artigo), vamos iniciar o desenvolvimento no mdulo Designer. A primeira tarefa que temos criar um novo projeto. Na aba Projetos do Mdulo Designer devemos clicar com o boto direito e escolher a opo Inserir Projeto. Vamos nomear nosso projeto como PROJETO_ETL conforme Figura 1.

Figura 1. Inserindo Projeto de ETL. Ainda na Figura 1 vamos explorar alguns conceitos importantes. Na Primeira Pasta localizam-se os nossos objetos criados no ODI que so disponibilizados em estruturas de pastas para uma melhor organizao. Porm, uma pasta sempre contm um conjunto de trs tipos de objetos: Pacotes, Interfaces e Procedimentos. - Pacotes: so os objetos que serviro para modelar o nosso fluxo no processo de ETL. No pacote so armazenados os objetos utilizados e a ligao entre eles. Depois que finalizamos a construo de um pacote, geramos a partir dele, um Cenrio, que a verso compilada do nosso pacote. Faamos uma analogia a um programa comum. Os pacotes contm os arquivos fonte do programa e os cenrios so os executveis gerados a partir dos arquivos fonte; - Interfaces: so os objetos que realmente fazem o trabalho de ETL. Nas interfaces so definidas as tabelas de origem, de destino e quais as regras sero aplicadas no processo de ETL; - Procedimentos: como o nome indica, so objetos em que so escritos qualquer tipo de procedimento extra que se faa necessrio no processo de ETL. Podemos criar procedimentos que contenham vrios tipos de cdigos, de diferentes tecnologias suportadas pelo ODI, como por exemplo, escrever um procedimento em PL/SQL, em Java, em Jython, etc. Dentro da hierarquia do PROJETO_ETL ainda temos: - Variveis: so utilizadas no ODI como qualquer varivel utilizada em um programa. Elas armazenam um valor que utilizado e modificado durante o processo de ETL; - Seqncias: o ODI nos d a possibilidade de criao de Sequences, iguais a uma Sequence de Banco de Dados. Criamos seqncias no ODI quando a Tecnologia que estamos utilizando no nos permite ter uma Sequence prpria no banco; Dentro da hierarquia do PROJETO_ETL ainda temos: - Variveis: so utilizadas no ODI como qualquer varivel utilizada em um programa. Elas armazenam um valor que utilizado e modificado durante o processo de ETL; - Seqncias: o ODI nos d a possibilidade de criao de Sequences, iguais a uma Sequence de Banco de Dados. Criamos seqncias no ODI quando a Tecnologia que estamos utilizando no nos permite ter uma Sequence prpria no banco; - Funes do Usurio: estas funes nos do a possibilidade de criao de funes que iro ser utilizadas vrias vezes no processo de ETL. Por exemplo, se temos que fazer um determinado tratamento em uma string ou uma data, podemos criar uma funo para no ter que escrever a mesma funo vrias vezes nas nossas Interfaces;zes nas nossas Interfaces; - Mdulos de Conhecimento: so conhecidos tambm como KMs (Knowledge Modules). Os KMs so considerados os coraes do processo de ETL no ODI. Eles so os responsveis por todas as tarefas executadas nos processos de ETL.

Para melhorar o entendimento vamos detalhar cada tipo de Mdulo de Conhecimento (KM): - RKM - Reverse Knowledge Module (Engenharia Reversa): o responsvel por fazer uma reversa customizada dos armazenamentos de dados no ODI. Por exemplo: se existir uma situao em que se necessite fazer algum tipo de procedimento extra ao reverter um modelo de dados, podemos utilizar RKMs especficos e no o padro para esta tarefa. O ODI faz reversas de tabelas automaticamente, mas podemos customizar estas reversas com um RKM; - LKM - Load Knowledge Module (Carga): o responsvel por carregar os dados das tabelas de origens no nosso processo de ETL quando estas tabelas se encontram em servidores de dados (Data Servers) diferentes; - CKM - Check Knowledge Module (Verificao): o responsvel por realizar as validaes dos dados no processo de ETL. No ODI podemos criar check constraints prprias contendo alguma regra de negcio (por exemplo, valor no pode ser negativo) ou podemos validar FKs de banco antes de inserir os dados na tabela de destino, ou ainda, durante o prprio processo de ETL, podemos verificar dados not null, etc. O CKM o responsvel por executar todas estas verificaes; - IKM - Integration Knowledge Module (Integrao): o responsvel pela integrao dos dados efetivamente no banco de destino. Ele resolve as regras do ETL descritas nas interfaces e insere os dados finais na tabela de destino; - JKM - Journalizing Knowledge Module (Documentao): o responsvel por fazer a jornalizao de dados quando se trabalha com este tipo de conceito. Pode ser usado, por exemplo, para se fazer replicao de bancos de dados; - SKM - Service Knowledge Modules (Servio): utilizado para publicar dados utilizando Web Services. Pode ser utilizado para gerar e manipular dados via Web Services para arquiteturas SOA (Service Oriented Architecture - Arquitetura Orientada a Servios); - Marcadores: so utilizados para colocar marcadores nos objetos criados no ODI. Servem para a organizao do projeto. Nesta fase de nosso projeto ainda no temos nenhum KM. A cada novo projeto fundamental a escolha de quais KMs iremos utilizar. Para o nosso projeto vamos importar os KMs necessrios, que so dois: - LKM: para carregar os dados de origens diferentes do nosso destino; - IKM: para fazer a integrao efetiva dos nossos dados para o destino; No Mdulo Designer, acessamos a aba Projetos e clicamos com o boto direito sobre a opo Importar e escolhemos a opo Importar Knowledge Modules.... Devemos ento informar o diretrio onde se encontram os KMs a serem importados. Originalmente os KMs que fazem parte da instalao do ODI esto na pasta oracledi\oracledi\impexp. Vrias opes sero apresentadas e devemos escolher as que se encaixam ao Projeto. Os KMs que vamos utilizar no nosso projeto so: - LKM File to SQL: Carrega dados de arquivos texto e traz para uma rea de armazenamento temporrio (ou rea de estagiamento, ou stagging, onde ficam as tabelas temporrias que o ODI cria automaticamente no processo de ETL); - LKM SQL to ORACLE: Carrega dados de um banco de dados genrico para um banco de dados ORACLE; - IKM ORACLE Incremental Update: Integra os dados de forma incremental em um banco de dados ORACLE, ou seja, linhas que ainda no existem na tabela so inseridas, linhas que existem sofrem atualizao. Quando os KMs j estiverem importados podemos ter uma definio do que cada um faz, bastando clicar duas vezes sobre o mesmo, surgindo assim uma tela com a descrio e a funcionalidade do mesmo. Para este processo de ETL no importamos todos os KMs, pois isso dificultaria a seleo dos mesmos no momento do desenvolvimento devido grande quantidade de KMs existentes. Portanto, uma boa prtica importar para o seu projeto apenas os KMs que sero realmente utilizados, a fim de trabalhar com um ambiente mais limpo e com menos chances de selecionar um KM errado. Em relao aos KMs

importados para o nosso projeto, suas funcionalidades ficaro mais claras no decorrer do Projeto, mais precisamente no momento do desenvolvimento das Interfaces. Construindo a Estrutura do Projeto - Modelos de Dados Partimos para a definio de nosso Modelo de Dados, e neste ponto o entendimento de dois conceitos so importantes: Modelo de Dados (Data Models) e o Armazenamento de Dados (Data Stores). Um Modelo de Dados pode conter N armazenamentos de dados (tabelas efetivas do banco de dados). utilizado para agrupar tabelas de uma determinada tecnologia de um determinado Esquema Lgico. Em nosso Projeto teremos quatro Modelos de Dados, um para cada finalidade: Origem Oracle, Origem Firebird, Origem File e Destino Oracle. Dentro de cada modelo estaro os nossos armazenamentos de dados, ou seja, nossas tabelas do banco de dados. Portanto, dentro do Mdulo Designer, mais precisamente na aba Modelos, vamos criar pastas para melhor organizao. Vamos inserir duas pastas de modelos: uma chamada Destinos e outra Origens. Agora vamos inserir as pastas de modelos para ambas. Para isso, basta clicar com o boto direito sobre a pasta Destinos e selecionar a opo Inserir Pasta de Modelos. Vamos inserir a pasta ORACLE, onde ficaro as tabelas de destino da tecnologia ORACLE, e repetimos a tarefa para as Origens, criando trs pastas: FILE, FIREBIRD e ORACLE, onde ficaro as tabelas de origem das suas respectivas tecnologias. Inserindo o Modelo de Dados Oracle - Origem Vamos criar nosso Modelo da Origem ORACLE. Para esta tarefa devemos clicar com o boto direito sobre a Pasta de Modelo ORACLE que acabamos de criar e escolher a opo Inserir Modelo. Na janela que se abre devemos inserir o nome para o nosso modelo, selecionar a tecnologia (ORACLE) e a qual Esquema Lgico (ORACLE_ORIGEM) o modelo ir se referenciar. O nome de nosso Modelo auto-explicativo (MODELO_ORACLE_ORIGEM). Ainda nas configuraes do Modelo vamos acessar a aba Reverter, pois devemos setar o Contexto que iremos utilizar para importar as nossas tabelas. Em nosso Projeto o Contexto selecionado o Desenvolvimento. Nesta aba tambm devemos selecionar quais tipos de objetos queremos que a reversa importe para o ODI. Para o nosso caso selecionamos apenas Tabelas, pois queremos reverter apenas as tabelas criadas nos scripts (que se encontram no site da SQL Magazine). Nesta aba de configurao poderamos tambm aplicar alguma mscara de filtro para que no momento da reversa o ODI selecionasse apenas os objetos que se adequassem a esta determinada mscara. A prxima aba de configurao a Reverso Seletiva (Figura 2). Nesta aba devemos escolher, das tabelas que passaram no filtro anterior, quais tabelas importar para o ODI. Para o nosso projeto iremos importar as quatro tabelas que esto alocadas no banco de dados. Aps selecionar as tabelas podemos clicar na opo Aplicar, e aps em Reverter. Uma mensagem de confirmao ser exibida: Deseja fazer engenharia reversa neste modelo antes de fechar esta janela? Se anteriormente j clicamos na opo Reverter podemos clicar em No nesta confirmao. Depois de revertido, teremos as tabelas da nossa origem ORACLE no ODI. Inserindo o Modelo de Dados Firebird Origem Devemos agora inserir o Modelo de Dados tambm para o Firebird. Faremos o mesmo processo detalhado anteriormente apenas alterando a Tecnologia escolhida. Selecionamos a Tecnologia Interbase que foi a selecionada para utilizao com o Firebird no momento da criao da Topologia. Conforme a Figura 3, selecionamos a tecnologia Interbase e o Esquema Lgico FIREBIRD_ORIGEM.

Figura 2. Executando a Reversa do Modelo de Origem.

Figura 3. Criando modelo de Origem do Firebird. Aps selecionar o contexto e quais objetos queremos importar na aba Reverter (novamente selecionamos Tabelas), e quais as tabelas que importaremos na aba Reverso Seletiva (tabelas criadas no script que se encontra no site da SQL Magazine), podemos clicar na opo Aplicar e aps em Reverter. Se o procedimento for correto, as tabelas da Origem Firebird sero importadas. Inserindo o Modelo de Dados File Origem Terminada a incluso dos Modelos de Dados ORACLE e Firebird vamos partir para a incluso do Modelo de Dados do tipo FILE. Para esta tecnologia existem algumas particularidades que devem ser observadas. Vamos proceder com a criao do modelo de forma normal seguindo os padres da incluso da Tecnologia ORACLE. Nomeamos o modelo para MODELO_FILE_ORIGEM e selecionamos a Tecnologia FILE. Tambm associamos neste ponto o Esquema Lgico FILE_ORIGEM. Vamos aba Reverter, selecionando o contexto Desenvolvimento. A nica particularidade est no momento de salvar o modelo: devemos salv-lo sem revert-lo. Podemos notar que o ODI no apresentou nenhuma mensagem de aviso ou confirmao em relao reversa no momento que ns criamos o modelo. Isso acontece porque a Tecnologia FILE no segue necessariamente um padro. Podemos ter arquivos com delimitaes por caracteres, como ; (ponto e vrgula) ou ento | (pipe) como podemos ter arquivos que no so delimitados mas sim fixos por um determinado valor em cada coluna. Todos estes padres se encaixam na Tecnologia FILE. Devido a particularidades de cada arquivo devemos fazer a reversa de cada arquivo de forma individual.

Para isso devemos estar no Repositrio de Trabalho do ODI, e clicar com o boto direito no MODELO_FILE_ORIGEM que se encontra dentro da pasta FILE. Devemos escolher a opo Inserir Armazenamento de Dados. Nota Devman - Tabela Dual Oracle Tabela dual Oracle: A tabela DUAL uma pequena tabela no dicionrio de dados que o Oracle ou qualquer usurio pode referenciar para garantir um resultado conhecido. Esta tabela possui apenas uma coluna, chamada DUMMY com apenas uma linha, contendo o valor X. A DUAL criada automaticamente pelo Oracle, sob o esquema SYS, mas pode ser acessada por outros usurios. Sempre que precisamos verificar um resultado conhecido, como a data e hora do servidor ou o valor atual de uma sequence, simplesmente fazemos a consulta referenciando a tabela DUAL. Isto por que toda consulta SQL deve envolver uma tabela, porm, se utilizarmos qualquer tabela povoada nesta consulta, teremos uma srie de inconvenientes, como estratgia de acesso ou eventual utilizao de ndices, etc. Na janela que ser exibida, na aba Definio, devemos colocar um nome para o modelo de dados e devemos escolher o arquivo correspondente que queremos reverter. Neste caso o arquivo do tipo TXT (dtempo.txt) e armazena as informaes referentes dimenso tempo de nosso Data Warehouse. Depois de feita a seleo do arquivo, vamos para a aba Arquivos (Figura 4), onde devemos informar se o arquivo possui ou no delimitao. No nosso caso, escolhemos que ele Delimitado. Neste ponto informamos que o caractere separador de campos do arquivo dtempo.txt o ; (ponto e vrgula). Tambm nesta estrutura de configurao podemos informar se o arquivo possui cabealho e de quantas linhas o mesmo formado. Para este caso informamos o valor 0 (zero). Se algum valor fosse informado, a quantidade de linhas informada seria retirada do incio do arquivo e seria desprezada. Outra opo que precisamos definir diz respeito ao Separador de Registros. Podemos selecionar se o arquivo tem separador do tipo: - MS-DOS (CR+LF (Carriage Return / Line Feed) = \r\n - hexa 0D0A); - UNIX (LF (Line Feed) = \n - hexa 0A). Estes padres de separadores de registros se referem s possveis quebras de linhas do arquivo. Tambm devemos configurar o delimitador de texto que neste caso (aspas simples), ou seja, as strings do arquivo texto so envoltos por aspas simples. Com esta configurao o ODI ir considerar apenas o contedo interno da string ignorando as aspas. Neste ponto tambm podemos indicar qual separador decimal os nossos valores esto utilizando, o que no se aplica neste caso.

Figura 4. Criando o armazenamento de dados da origem TXT.

Nota Devman - DDL (Linguagem de Definio de Dados): A DDL permite ao usurio definir tabelas novas e elementos associados. A maioria dos bancos de dados de SQL comerciais tm extenses proprietrias no DDL. Os comandos bsicos da DDL so poucos: - CREATE: cria um objeto (uma Tabela, por exemplo) dentro da base de dados; - DROP: apaga um objeto do banco de dados. Alguns sistemas de banco de dados (Oracle, por exemplo) usam o comando ALTER, que permite ao usurio alterar um objeto, por exemplo, adicionando uma coluna a uma tabela existente. Outros comandos DDL: ALTER TABLE, CREATE INDEX, ALTER INDEX, DROP INDEX, CREATE VIEW, DROP VIEW. Finalizando o processo de configurao devemos clicar na aba Colunas e selecionar a opo reverter. Neste momento o ODI busca as informaes da aba arquivos e separa em colunas automaticamente (Figura 5). Por padro as colunas ficam com nomes C1, C2, C..., mas podem ser renomeadas conforme necessidade e\ou organizao. Nota Devman - DML (Linguagem de Manipulao de Dados): A DML um subconjunto da linguagem usada para selecionar, inserir, atualizar e apagar dados. - SELECT: o mais usado do DML, comanda e permite ao usurio especificar uma query como uma descrio do resultado desejado. - INSERT: usada para inserir um registro (formalmente uma tupla) a uma tabela existente; - UPDATE: para mudar os valores de dados em uma ou mais linhas da tabela existente; - DELETE: permite remover linhas existentes de uma tabela. Inserindo o Modelo de Dados Oracle - Destino Vamos agora proceder com a criao do modelo de destino seguindo os padres da incluso da tecnologia Oracle para Origem. Nomeamos o modelo como MODELO_ORACLE_DESTINO conforme Figura 6. Devemos reverter as tabelas repetindo os mesmos passos do modelo de dados Oracle da origem. Para isso, na aba Definio devemos selecionar a tecnologia Oracle e o esquema lgico ORACLE_DESTINO. Na aba Reverter selecionamos o contexto de Desenvolvimento e o tipo de armazenamento de dados a ser revertido (Tabela), e na aba Reverso Seletiva escolhemos as tabelas contidas no script disponvel no site da SQL Magazine. Depois deste passo estamos prontos para iniciar o desenvolvimento das interfaces. Iniciando o Desenvolvimento das Interfaces Neste ponto iniciamos efetivamente o desenvolvimento ETL. Vamos desenvolver as interfaces, procedimentos, variveis e pacotes, que sero os objetos utilizados para a realizao do ETL. Desenvolvimento da Interface - Carga Destino DIM_CLIENTE Para iniciarmos o desenvolvimento das interfaces vamos alternar da aba Modelos para a aba Projetos no Mdulo Designer. Nesta aba vamos alterar o nome da Primeira Pasta para DW. Esta alterao pode ser feita dando duplo clique sobre a estrutura. Vamos iniciar carregando as dimenses do DW. A primeira interface a ser desenvolvida dever fazer a carga de dados para a Dimenso Cliente. Ainda na aba Projetos devemos expandir a pasta DW e clicar com o boto direito sobre Interfaces selecionando a opo Inserir Interface, conforme Figura 7.

Figura 6. Criao do Modelo de destino Oracle.

Figura 7. Inserindo uma nova interface Vamos desenvolver a Interface para contemplar o ETL da Dimenso Cliente e, portanto, nomeamos a Interface como CLIENTES_IN. Neste passo tambm devemos selecionar o contexto de otimizao, que serve para o ODI montar o fluxo de execuo (Figura 8).

Figura 8. Criando a interface de clientes. Para melhorar a explicao sobre o contexto de otimizao, vamos imaginar o seguinte exemplo: temos em desenvolvimento dois esquemas que apontam para uma mesma instancia de banco de dados.

Para o ODI, como os dois esquemas esto no mesmo banco no seria necessria a utilizao de um LKM (o LKM busca os dados de data servers diferentes), pois o IKM (mdulo de integrao) conseguiria fazer sozinho a integrao de dados, otimizando assim o cdigo, pois diminuiria os passos do mesmo. Porm, se estes mesmos esquemas, em um contexto de Produo, estiverem em servidores fisicamente separados, o ODI necessitaria utilizar um LKM, pois a sua origem est fisicamente separada do destino. Se a interface fosse construda com o contexto de otimizao menos fragmentado (como o de desenvolvimento neste caso) teramos um problema ao rodar esta interface em produo, pois o cdigo gerado no contemplaria um LKM. Portanto, ao selecionar um contexto de otimizao, devemos escolher sempre o contexto mais fragmentado, pois o ODI ir se basear neste contexto para montar o fluxo do ETL. No nosso caso, como temos apenas um contexto, pode-se manter o contexto de desenvolvimento. Outra opo que podemos selecionar nesta etapa (Figura 8) esta relacionada rea de Stagging, que pode ser diferente do destino. Por padro, a rea de Stagging sempre no destino, ou seja, os objetos temporrios necessrios ao processo de ETL sero criados no Esquema de Trabalho do destino setado anteriormente, no momento da criao da topologia (ESQUEMA_TMP do banco ORACLE). Neste ponto poderamos selecionar qualquer esquema para ser a Stagging, mas vamos mant-lo no Esquema de Trabalho do destino. Aps inserir esta nova Interface devemos acessar a aba Diagrama. Nesta estrutura sero armazenados todos os relacionamentos, regras e mapeamentos de origem e destino que devero ser configurados. No lado direito (Figura 9) temos a tabela de destino, no esquerdo, teremos as tabelas de origem e seus relacionamentos. Na estrutura do Diagrama vamos montar a regra de ETL para o nosso destino. Primeiro devemos clicar na aba Modelos e selecionar a estrutura DESTINOS/ORACLE/MODELO_ORACLE_DESTINO. Aps localizar a estrutura basta clicar e arrastar a tabela DIM_CLIENTE para dentro da estrutura de armazenamento DESTINO, como pode ser visto na Figura 10.

Figura 9. Diagrama de uma Interface.

Figura 10. Adicionando as tabelas de Origem. Posteriormente devemos selecionar e arrastar a ORIGEM para o lado esquerdo do Diagrama. Neste momento o ODI pergunta se desejamos fazer o mapeamento automtico dos campos. Como na nossa estrutura a nomenclatura das colunas so iguais, o mapeamento iria funcionar sem problemas. Na prtica de desenvolvimento de um projeto, o mapeamento automtico no recomendado. Na grande maioria dos casos, as nomenclaturas de origem e destino so diferentes e\ou existir alguma regra de transformao. Desta forma o ODI pode mapear campos para os locais errados, gerando re-trabalho para mape-los novamente. Portanto, selecione No e vamos mapear manualmente. Porm, antes disso, temos que fazer um join entre tabelas de origem com o objetivo de popular a tabela DIM_CLIENTE. A DIM_CLIENTE recebe tanto as informaes dos clientes quanto do seu tipo. Para isso, clique e arraste TIPOCLI para o diagrama. Podemos ver pela Figura 11 que o ODI identificou as colunas que fazem relacionamento entre as tabelas e j colocou o join automaticamente. Se o processo de montagem dos joins no acontecesse de forma automtica teramos que clicar sobre a primeira coluna do relacionamento, arrastar e soltar em cima da segunda coluna do relacionamento. Este o processo manual quando o mapeamento automatizado no acontece.

Figura 11. Montando os Joins entre as tabelas de Origem.

Podemos notar ao clicar no join (Figura 12) que vrias opes so apresentadas (todas so autoexplicativas), como por exemplo, se o join vai ser um inner join ou um left outer join. Clicando nos diferentes tipos de joins, o ODI nos diz o que ir acontecer em cada caso. No caso apresentado para a construo da DIM_CLIENTE utilizamos um inner join. Esta tarefa avisa que retornar Todas as linhas emparelhadas pela condio de unio entre CLIENTE e TIPOCLI. IMPORTANTE: Neste ponto temos a opo de executar este join na origem ou na rea de teste (stagging). Se for na stagging, o ODI trar as duas tabelas inteiras para o esquema de trabalho e depois far o join entre elas. Se a opo na origem, o ODI far o join na origem e trar apenas o resultado daquele join para o esquema de trabalho. Esta escolha depende de cada caso. No nosso exemplo mais eficiente resolver o join na origem e trazer resolvido para o destino, pois isso resultar em trazer apenas os registros que obedeceram regra do join, tornando assim o volume de dados trafegados de uma ponta a outra menor. Para mapear um campo no ODI o processo relativamente simples. Deve-se clicar no campo de destino que se deseja mapear, clicar no campo de origem a ser mapeado, arrastar e soltar na rea branca Implementao, que fica na parte de baixo do diagrama. O resultado pode ser visto na Figura 13.

Figura 12. Opes de Join para montagem da interface de carga.

Figura 13. Mapeando uma coluna no ODI. Faltou apenas o mapeamento do campo ID_CLIENTE e neste passo faremos algo diferente. Todas as tabelas de destino tm um ID prprio e nico que a PK da tabela. Estas PKs devem ser populadas com um nmero nico de uma sequence chamada SEQ_DESTINOS, que se encontra criada no banco de destino. Agora, devemos clicar sobre a coluna ID_CLIENTE e clicar diretamente no cone do lpis para abrir o editor de expresses (Figura 14). O editor de expresses auxilia a montar as expresses que estaro mapeadas nas colunas. Neste caso, mapeamos uma sequence na coluna ID_CLIENTE. Para isso, prefixamos o esquema onde a mesma se encontra no banco, por exemplo, ESQUEMA_DESTINO.SEQ_DESTINOS. O procedimento de manter prefixado (ESQUEMA.OBJETO) o esquema na Interface desenvolvida no recomendado para grandes projetos. Exemplo: o esquema principal est nomeado como ESQUEMA_DESTINO em desenvolvimento, mas em outro ambiente (produo) o esquema pode variar de nome.

Esta alterao faria com que a Interface no executasse de maneira correta. A soluo deste problema seria utilizar uma funo prpria do ODI que retorna o nome do esquema em que a interface esta sendo executada. Esta funo pode ser encontrada dentro do Editor de Expresses (Figura 15), mais precisamente em Funes OdiRef. O ODI possui vrias funes muito teis. A lista completa destas funes podem ser encontradas no manual de referncia da ferramenta. Para este exemplo em vez de ter uma sequence com o esquema prefixado (ESQUEMA_DESTINO.SEQ_DESTINOS) substituiramos pela funo denominada getShemaName, Figura 15.

Figura 14. Editor de expresses.

Figura 15. Editor de Expresses. Aps escrever o comando a ser mapeado confirmamos com um OK na janela. Voltamos para a montagem da Interface. Notamos na Figura 16 que, ao lado do nome das colunas, encontram-se pequenos cones, como uma pequena janela, um martelo (que ainda no se encontra na tela), um alvo e uma chave. Cada smbolo possui um significado: - Janela: indica que o campo ser resolvido na origem e ser avaliado durante o processo do ETL; - Martelo: indica que o campo ser resolvido na rea de stagging e ser avaliado durante o processo do ETL; - Alvo: indica que o campo ser resolvido apenas no destino, o que significa que ele no ser avaliado durante o ETL e ser apenas inserido no destino; - Chave: indica a chave da tabela. Por default, o ODI escolhe para ser a chave a prpria chave primria (PK) da tabela, mas, como veremos neste caso, podemos modificar a chave para fazer com que o ODI resolva o ETL da maneira que ns desejamos.

Podemos trocar o local que o campo ser executado (resolvido) clicando na coluna que desejamos modificar e em seguida na opo Executar em:, selecionando o local escolhido. No caso da sequence, iremos especificar que ir executar no ambiente de destino. Esta troca de diretrio tem um motivo: a sequence no deve ser avaliada durante o processo de ETL e deve ser executada somente no momento da insero do novo registro no destino. Se no for estruturada desta maneira causar um erro na sua execuo. Outra tarefa necessria a alterao da chave da tabela Cliente. Esta tabela tem como PK o campo ID_CLIENTE e populado por uma sequence. Isso significa que o valor da PK sempre muda e novos registros seriam inseridos na tabela sempre que a Interface fosse executada. Se executssemos dez vezes a carga, os clientes estariam dez vezes duplicados na tabela de destino

Figura 16. Mapeamento completo para DIM_CLIENTE. O correto para a tabela Cliente existir apenas um cdigo por cliente, ou seja, precisamos que a coluna CDCLI seja a chave natural (NK - Natural Key). Para o ODI levar em considerao a coluna CDCLI como chave e no a atual PK ID_CLIENTE devemos proceder com a alterao conforme a Figura 17. Ao clicar sobre a tabela de destino DIM_CLIENTE percebemos que na opo Atualizar Chave est selecionado DIM_CLIENTE_PK que representa a PK da tabela no ODI.

Figura 17. Chave de DIM_CLIENTE. Trocamos o Atualizar Chave para a opo sem definio e agora temos a liberdade de selecionar a chave que necessitamos. Selecionamos ento a coluna CDCLI e clicamos em chave, conforme Figura 18.

Figura 18. Mapeamento de DIM_CLIENTE. Com isso a chave para o ODI passa a ser CDCLI. Clicando sobre as colunas, podemos notar na estrutura Atualizar, check-boxes de Inserir, Atualizar, UD1, UD2, etc. (Figura 19). Estes checks

funcionam para configurar se o campo ser inserido no destino, se ele ser atualizado no destino ou se ele executar alguma das funes definidas pelo usurio (UD - User Defined). No nosso caso, todos os campos por padro esto marcados como Inserir e Atualizar. Porm, no caso da coluna ID_CLIENTE devemos desmarcar a opo Atualizar (Figura 19), pois a sequence no pode participar do passo de update gerado pelo KM sob o risco de erros serem gerados na execuo. Este processo ficar mais claro no momento da execuo da interface que ser explicado a seguir.

Figura 19. Configurando o comportamento dos campos. Concluda as configuraes vamos para a aba Fluxo. Na tela de Fluxo (Figura 20) representada a forma como a ferramenta ir fazer a execuo da Interface.

Figura 20. Fluxo de trabalho do ODI.

Para este caso o ODI demonstra apenas um nico exemplo com a utilizao do IKM, que por si s ir resolver todo processo de ETL. Esta estrutura nica devido s tabelas que estamos utilizando como origem e as tabelas que queremos popular (tabelas de destino) se encontrarem em um mesmo Data Server (uma mesma Origem) configurado na topologia. Se esta estrutura estivesse em Data Servers diferentes, a ferramenta nos mostraria duas estruturas distintas, uma com a composio de um LKM responsvel pela carga dos dados para as reas de stage e outra com o IKM que realizaria os demais processos de ETL. Este caso ser explorado no momento da construo das Interfaces que carregam os dados oriundos dos arquivos do tipo texto e do banco de dados Firebird. Ao clicar sobre a caixa denominada Alvo-rea de Teste (Figura 20) podemos observar que o KM utilizado por padro o IKM (Oracle incremental Update). Resumidamente este KM faz cargas incrementais, ou seja, ele verifica a chave definida na interface (CDCLI neste caso). E se esta chave ainda no existe no destino o processo faz a insero da mesma de forma automtica. Se esta chave j existe o processo apenas faz o Update nas colunas selecionadas com a opo Atualizar (Figura 19). Podemos notar tambm que o KM vem com vrias opes de valores padres. Ao clicar sobre cada opo, ao lado, apresenta-se a sua descrio. Para este trabalho iremos modificar apenas a opo Flow Control que devemos mudar para opo no (Figura 20). Quando a opo descrita estiver selecionada como Sim o ODI ir invocar o CKM (Validaes - Ver explicao sobre CKM neste artigo) selecionado e far a verificao dos dados durante o processo de ETL. Como no criamos nenhuma validao para esta tabela, podemos retirar a opo de Flow Control desta interface. Para realizar a execuo da interface basta clicar sobre o boto Executar no canto inferior direito da interface (Figura 21). Neste momento ser apresentada uma tela questionando em qual contexto executar, neste caso o contexto de Desenvolvimento; qual o agente, vamos executar no agente local; e o nvel de registro, que indica o grau de informaes que deve ser gerado no log do ODI, que podemos deixar o valor padro 5.

Figura 21. Execuo de uma Interface Durante a execuo da Interface podemos acessar a Lista de sesses do mdulo Operator e acompanhar o processo de execuo das cargas (Figura 22). Verificando a execuo (Figura 22), podemos observar os passos criados pelos KMs do ODI. Reparamos que a primeira palavra escrita Integrao. Isto significa que todos os passos gerados por esta Interface foram de um IKM. Para carregar a tabela DIM_CLIENTES, a ferramenta gerou onze passos distintos. Os cones em verde indicam comandos executados com sucesso. cones em amarelo indicam que o comando falhou, porm a execuo continua normalmente. cones em vermelho significam erros que interrompem a execuo da carga, que no foi o caso. No exemplo da Figura 22 percebe-se que o passo indicou ateno. Isto aconteceu porque o ODI tentou dropar uma tabela temporria que ainda no existia no banco. Clicando duas vezes sobre qualquer passo possvel ver o que executou, quanto tempo levou para executar a carga, quantas linhas foram inseridas, entre outros.

Esta Interface (CLIENTES_IN) inseriu sete linhas na tabela de destino. Se esta Interface fosse executada novamente veramos novamente os mesmos onze passos, mas no processo nenhuma nova linha seria inserida. Como esta Interface incremental, ela carrega apenas as linhas que ainda no foram carregadas e faz a atualizao de linhas quando a mesma no existir. DICA: Para compreender melhor como funcionam as configuraes feitas no ODI, tente marcar a opo Atualizao no campo ID_CLIENTE que carregada juntamente com a sequence ou mude o local de execuo de Destino para Stagging e compare os passos de uma execuo e outra. No comeo parece complicado, mas depois que aprendemos os pequenos truques da ferramenta verificamos que o ODI uma poderosa e flexvel ferramenta para processos ETL.

Figura 22. Execuo da Interface CLIENTES_IN. Desenvolvimento da Interface - Carga Destino DIM_PRODUTO O prximo passo para o projeto criar a Interface que carrega a tabela DIM_PRODUTO. A tarefa para montagem da carga a mesma explanada anteriormente. Desta forma, vamos direto para o Diagrama da Interface (Figura 23). Todas as tabelas desta estrutura so provenientes da origem FIREBIRD. Importante: Devemos efetuar a modificao da coluna ID_PRODUTO para ser executada no banco de destino (cone do Alvo da coluna ID_PRODUTO na Figura 23). Tambm devemos desmarcar a opo Atualizar para este atributo. Outra modificao que dever ser efetuada a troca da chave da tabela (DIM_PRODUTO) para ser CDITEM e CDGRUPO, pois estes dois atributos referenciam a NK (Natural Key Chave Natural) da tabela. Outro ponto importante que ao clicar no cone do lpis, o ODI perguntar qual a tecnologia a ser considerada no editor, pois temos duas tecnologias no diagrama (Firebird e Oracle). Selecionaremos o Oracle pois a sequence est no banco Oracle. Clicando na estrutura da aba Fluxo temos uma novidade: a caixa do LKM (Figura 24). Esta estrutura se encontra presente devido necessidade de carregar dados que se encontram em outro banco de dados (neste caso o Firebird).

Figura 23. Diagrama de PRODUTOS_IN.

Figura 24. Fluxo de PRODUTOS_IN. Com isso o ODI primeiro extrai estes dados da base de origem repassando os mesmos para a stagging rea. Em relao ao IKM, este ter o papel de pegar os dados e inserir nas tabelas de destino. Para a carga da tabela destino DIM_PRODUTO, vamos utilizar o LKM SQL to Oracle. J em relao ao IKM selecionamos o IKM Oracle Incremental Update no esquecendo que neste devemos modificar a opo de Flow Control para No. Ao executar esta Interface os resultados podem ser consultados na lista de sesses do Operator (veja a Figura 25). Notamos na Figura 25 que o nmero de passos de execues aumentou para dezessete e que temos descries das aes como Carregando e Integrao. Os passos com as descries carregando se referem aos passos gerados pelo LKM e os passos com Integrao se referem aos passos gerados pelo IKM. Desenvolvimento da Interface - Carga Destino DIM_VENDEDORES Para criar a interface de vendedores basta seguir os mesmos passos das interfaces anteriores: selecionamos o nosso destino, a nossa origem, mapeamos os campos, colocamos a execuo da sequence no alvo, desmarcamos a opo de Atualizar e trocamos a chave para CDVEND (Figura 26).

Figura 25. Execuo de PRODUTOS_IN.

Figura 26. Mapeamento de VENDEDORES_IN. Em alguns casos a utilizao de um filtro para os dados se torna necessria e pode auxiliar no processo de carga. Para exemplificar a utilizao de um filtro na Interface de carga vamos inserir para esta interface, especificamente, um filtro na nossa origem (representada por um funil amarelo no diagrama -( Figura 26). Para fazer um filtro, basta clicar no campo que se deseja filtrar, arrast-lo para o lado e soltar na rea livre do diagrama. Aps isso, podemos montar a estrutura e escrever o filtro que desejamos fazer. Neste caso colocaremos que o campo PERCCOM deve possuir valor menor a 50 (Figura 27). Esta carga possui somente o IKM, pois se trata do mesmo banco de dados e far a carga com a estratgia incremental (IKM Oracle Incremental Update). Modificamos a opo do Flow Control para No e executamos a interface.

Desenvolvimento da Interface - Carga Destino DIM_TEMPO Para a carga da dimenso tempo temos uma particularidade. A origem para esta carga um arquivo texto com uma estrutura simples (Figura 28).

Figura 27. Utilizando filtro no ODI.

Figura 28. Mapeamento para TEMPO_IN. Aqui temos uma novidade: no mapeamento da coluna DATA_DIA utilizamos a funo TO_DATE do Oracle (Figura 29), pois estamos lendo uma string do arquivo texto e estamos populando um campo do tipo DATE (TO_DATE(DTE.DATA_DIA,DD/MM/YYYY)). Neste caso no iremos utilizar a sequence do banco e sim a prpria sequence existente no arquivo texto. Na aba fluxo para este caso teremos um LKM e um IKM. O LKM que iremos utilizar ser o LKM File to SQL. Para o IKM utilizaremos o Oracle Incremental, onde devemos setar a opo Flow Control igual a No. Executando a interface podemos ver o resultado no Operator, como explicado anteriormente. Desenvolvimento da Interface - Carga Destino FATO_VENDAS Esta interface j tem uma lgica mais elaborada (Figura 30): estamos buscando as informaes de duas origens: a tabela VENDA que tem sua origem proveniente do banco de dados Oracle e da tabela ITVENDA que vem do banco de dados Firebird. Alm dessas origens ainda fazemos joins com as nossas tabelas de Dimenses, pois precisamos buscar os IDs que foram gravados anteriormente nas nossas interfaces. Os joins que so realizados so os seguintes:

- VENDA.NUMNF=ITVENDA.NUMNF; - VENDA.CDCLI=DIM_CLIENTE.CDCLI; - (DIM_PRODUTO.CDITEM =ITVENDA.CDITEM) AND DIM_PRODUTO.CDGRUPO =ITVENDA.CDGRUPO; - DIM_VENDEDOR.CDVEND =VENDA.CDVEND; - VENDA.DTVENDA =DIM_TEMPO.DATA_DIA. Para este caso vamos inserir outro filtro (para reforar o exemplo de utilizao): DIM_TEMPO.TURNO = Manh. Notamos na Figura 30 que a estrutura DIM_TEMPO possui, assim como explicado anteriormente, um pequeno funil amarelo representando que existe um filtro no processo de carga desta estrutura.

Figura 29. Diagrama de FATO_VENDAS_IN.

Figura 30. Mapeamento utilizando procedimento TO_DATE.

No fluxo selecionamos o LKM SQL to Oracle para ler as tabelas do banco Firebird e o IKM Oracle Incremental Update para fazer a carga. Marcamos tambm a opo Flow Control no IKM para No. Como padro, podemos executar a interface e ver o seu resultado no Operator.

Desenvolvimento do Pacote para Carga de Dados Aps executar individualmente cada Interface podemos consultar as tabelas de destino e conferir que todas esto carregadas. Mesmo com a eficincia comprovada para cada carga este no um modo prtico para execuo de cargas. Em um grande projeto, por exemplo, estas Interfaces no poderiam ser enviadas para outros ambientes, pois no so estruturas compiladas para execuo em outros ambientes. Neste sentido necessitamos criar Pacotes para controlar o fluxo e criar cenrios compilados para que a execuo em outros ambientes seja garantida. Para inserir um novo Pacote, no projeto DW, clique com o boto direito sobre a opo Pacotes e em seguida selecione Inserir Pacote. Na aba Definio nomeamos o pacote. na aba Diagrama que ser desenvolvido o fluxo do processo de ETL. Nesta mesma tela pode-se encontrar vrias funcionalidades (em forma de botes) que podem ser detalhados com o simples passar do mouse sobre cada um. A caixa de ferramentas do ODI contm diversos objetos que podem ser includos no fluxo ETL do nosso pacote. Entre eles temos objetos de envio de e-mail, execuo de comandos do sistema operacional, processo de espera de eventos (tempo limite ou espera de algum registro em alguma tabela especfica), manipulao de arquivos, entre outros. O detalhamento de cada componente pode ser visto no arquivo de ajuda do ODI, que se encontra no menu Ajuda na parte superior da tela. Para montar o fluxo devemos colocar as interfaces no diagrama do pacote. Para isso, clicamos sobre alguma interface e arrastamos para dentro do diagrama, conforme Figura 31. Podemos notar na Figura 31 que a interface CLIENTES_IN possui uma pequena flecha verde que indica que ela vai ser o primeiro objeto a ser executado. Para modificar qual objeto ser o primeiro a ser executado possvel clicar em cima do objeto escolhido com o boto direito e escolher a opo Primeira etapa. Se executssemos o pacote neste momento somente a interface CLIENTES_IN seria executada, pois ainda no criamos o fluxo de execuo completo do pacote.

Figura 31. Adicionando as Interfaces ao Pacote. Para criar este fluxo devemos clicar no boto ok (Etapa seguinte ao xito) que contm uma flecha verde, na barra superior. Aps este passo deve-se clicar sobre o objeto de origem e arrastar at o objeto de destino, conforme Figura 32. Temos tambm o boto ko (Prxima etapa ao falhar) que contm uma flecha vermelha, que desviar o fluxo se algum erro acontecer. Aplicaremos o fluxo de erro em momentos onde for pertinente.

Figura 32. Criando Fluxo de Execuo. O mesmo procedimento deve ser repetido para o restante das Interfaces (Figura 33). Aps isso, executaremos o pacote clicando no boto Executar (canto inferior direito).

OBSERVAO: Para manipular o local dos objetos no pacote, escolha o primeiro boto (o cursor branco - Escolha livre) na barra superior.

Figura 33. Fluxo do Pacote. Observando a execuo da Interface no mdulo Operator (Figura 34) podemos verificar que agora todas as nossas interfaces esto agrupadas em uma nica execuo do pacote, evitando a execuo individual de cada uma. Outra tarefa importante pode ser realizada neste Pacote. Vamos implementar um LOG personalizado para guardar as informaes importantes relacionadas a execuo deste Pacote. Para isso usaremos a tabela LOG_CARGA que conter o ID da sesso do ODI correspondente execuo e uma descrio informando se todos os processos da carga executaram com sucesso ou com erro. Para completar esta demanda vamos precisar criar uma Varivel e dois novos Procedimentos: um para inserir os dados e outro para retornar o ID da sesso. Para completar esta tarefa precisamos entender melhor o que uma Varivel e um Procedimento no ODI. Criando Variveis Para criar uma Varivel devemos acessar o projeto PROJETO_ETL, na aba projetos, clicar com o boto direito sobre a opo Variveis e escolher Inserir Varivel. Na aba Definio, colocamos o nome da varivel, escolhemos o seu tipo de dado e a sua Ao (Figura 35).

Figura 34. Execuo do Pacote.

Figura 35. Criao de Variveis no ODI. Para a opo Ao, temos as seguintes opes: - Historiar: O ODI manter na aba Histrico todos os valores que a varivel j recebeu durante as suas execues; - Valor mais recente: O ODI manter na aba Histrico o ltimo valor que a varivel recebeu durante as suas execues; - No persistente: O ODI no manter nenhum histrico. A Ao escolhida neste caso a No persistente, pois no temos a necessidade de manter histrico para esta tarefa. Na aba Atualizando vamos adicionar um comando DDL que retornar o valor para a varivel, ou seja, o comando executado no banco de dados e o resultado atribudo para a varivel. Para este exemplo utilizamos um select simples na tabela dual (que retornar apenas um registro) utilizando a funo do ODI <%=odiRef.getSession("SESS_NO")%>, que retornar o nmero da sesso. No combobox Esquema escolhemos em qual esquema queremos executar esta DDL, que neste caso o ORACLE_DESTINO (Figura 36). O teste para verificar se o procedimento foi realizado com sucesso pode ser feito ao clicar no boto Renovar. Se a Ao da varivel Historiar ou Valor mais recente, podemos ver o valor da varivel na aba Histrico (Figura 37).

Figura 36. Configurando a varivel.

Figura 37. Histrico da Varivel. Nosso prximo passo adicionar a varivel no pacote e setarmos a mesma para ser executada como demanda inicial, pois queremos ter o nmero da sesso para gravar no log antes de comear o processo de ETL. Quando clicamos sobre a varivel, podemos observar as suas propriedades, entre elas o Tipo, que pode ser setado de vrias formas (o cone no pacote e suas propriedades mudaro conforme o que for setado). As opes de Tipo so: - Declarar varivel: utilizado para receber um valor passado por parmetro quando executamos um cenrio compilado; - Avaliar varivel: utilizado para fazer um teste lgico (=, <>, >, <, etc.) sobre o valor da varivel. Se o teste lgico retornar verdadeiro, o fluxo segue para a prxima etapa seguinte ao xito (flecha verde). Se retornar falso, o fluxo segue a prxima etapa ao falhar (flecha vermelha); - Renovar varivel: executa o select colocado na aba Atualizando da varivel, atribuindo o resultado do select varivel (o select deve retornar apenas um valor, ou um erro ocorrer); - Definir varivel: atribui manualmente o valor desejado varivel. Para o nosso pacote, escolheremos o tipo Renovar varivel, pois queremos que a varivel contenha o valor retornado do select da aba Atualizando. Isto faz com que tenhamos o valor da sesso do ODI atribuda a nossa varivel, com o objetivo de gravarmos posteriormente no log (Figura 38).

Figura 38. Tipos de Variveis.

Criando Procedimentos Para criar Procedimentos no ODI devemos acessar a pasta DW, clicar com o boto direito sobre a opo Procedimentos e depois em Inserir Procedimento (Figura 39). Na aba Definio devemos apenas colocar o nome do nosso Procedimento. J na aba Detalhes, devemos clicar no primeiro boto Adicionar na parte superior. Aps este passo ser aberta uma janela onde deve ser inserido o comando que queremos que este Procedimento execute. Percebemos aqui o nvel de flexibilidade de trabalhar com o ODI. Nesta tela que foi apresentada possvel adicionar qualquer tipo de comando de qualquer tipo de tecnologia suportada pelo ODI, entre elas Oracle, Java, DBase, Hyperion Essbase, Java Script, entre outros. A lista completa de tecnologias suportadas pode ser vista no combobox Tecnologia. Para este exemplo, faremos apenas um simples insert em uma tabela, mas as possibilidades so muito maiores, podendo ter blocos inteiros de PL/SQL com uma lgica muito mais complexa, tudo dependendo da necessidade do projeto. Portanto, escolhemos a tecnologia Oracle, o esquema ORACLE_DESTINO (onde est a tabela de log) e escrevemos o comando a ser realizado, conforme a Figura 40.

Figura 39. Inserindo novo procedimento.

Figura 40. Criando novo Procedimento.

Notamos alguns detalhes diferentes neste procedimento: - <%=odiRef.getSchemaName( )%>: Funo que retorna o nome do esquema do banco de dados referente ao esquema lgico escolhido (ORACLE_DESTINO). Isso se faz necessrio pois podemos ter nomes de esquemas diferentes em contextos diferentes. Em desenvolvimento podemos ter ORACLE_DESTINO e em produo podemos ter ORACLE_DESTINO_PROD. Assim, no podemos deixar o nome do esquema fixo, pois em produo geraria um erro; - #SESSAO_ODI: Nome da varivel que criamos que conter o nmero da sesso do ODI, prefixada com #. No momento de execuo, a ferramenta procurar e substituir as variveis que ele encontrar no cdigo pelo seu valor no momento da execuo. Devemos ter apenas cuidado para que a varivel contenha algum valor, caso contrrio um erro ser gerado.

Podemos clicar em OK para fechar esta janela (Figura 40). Observe que poderamos incluir quantos comandos fossem necessrios, bastando apenas clicar no boto Adicionar. Poderamos inclusive executar comandos de N tecnologias diferentes em ordem seqencial. Nossa prxima tarefa realizar a incluso de outro procedimento. Para criar procedimentos no ODI devemos acessar novamente a pasta DW, clicar com o boto direito sobre a opo Procedimentos e clicar em Inserir Procedimento. Para esta estrutura basta nome-la e clicar em OK, pois iremos inserir uma nova Opo para este Procedimento. Opes so parmetros que so repassados para o Procedimento. Para inserirmos uma Opo clicamos com o boto direito sobre o Procedimento e em seguida Inserir Opo. Ser inserida uma Opo para indicar ao Procedimento se desejamos gravar uma mensagem de sucesso ou erro. Uma Opo pode ser de trs tipos: - Marcar Caixa: Opo do tipo checkbox, onde possvel escolher entre as opes SIM/NO; - Valor: Recebe um valor alfanumrico com capacidade mxima de 250 caracteres; - Texto: Recebe um valor alfanumrico com capacidade ilimitada. O acesso a este tipo de opo mais lenta do que o tipo Valor. Escolheremos o tipo Valor (ver Figura 41).

Figura 41. Criando uma nova Opo.

Vamos abrir novamente o procedimento, agora para criar um comando. Escolhemos neste sentido a tecnologia Oracle, o esquema ORACLE_DESTINO e digitamos o comando conforme a Figura 42. Este comando far com que a tabela de log seja atualizada com uma mensagem de Erro ou de Sucesso, conforme o parmetro passado para ele.

Figura 42. Procedimento para gravar detalhes em LOG. Neste comando temos o <%=odiRef.getOption("STATUS")%> que ir buscar o valor passado para o parmetro atravs da Opo que criamos no passo anterior. Clicamos em OK e vamos inserir os Procedimentos no nosso fluxo do pacote. Na Figura 43 visualizamos o Fluxo de nossa carga.

Figura 43. Fluxo Final do Pacote. A leitura deste Fluxo pode ser feita desta forma: 1- Comece executando a atualizao da varivel SESSAO_ODI; 2- Insira um registro na tabela de LOG; 3- Execute as cinco interfaces e grave o status final na tabela do LOG;

4- Se algum procedimento der errado (flechas vermelhas), grave no LOG o status de erro. As flechas verdes indicam o fluxo sem erros no pacote. As flechas vermelhas indicam o fluxo a ser tomado se algum erro ocorrer. Para incluir as flechas vermelhas, clique no boto ko na barra superior, clique no objeto origem e arraste para o objeto destino. Para as flechas verdes, funciona da mesma forma, mas selecionando o boto ok. A ltima tarefa necessria para execuo do pacote setar a Opo de cada procedimento de Update conforme a sua finalidade. Temos, portanto dois procedimentos, um que registrar as mensagens de erro e outro as mensagens de sucesso. Clicando no Procedimento que ir gravar a mensagem de erro (UPDATE_LOG_pr), vamos na aba Opes para inserir o valor de STATUS que este Procedimento deve receber quando for executado, que neste caso E (ERRO) (Figura 44). Seguiremos os mesmos passos para outro procedimento (tambm UPDATE_LOG_pr), onde adicionamos o STATUS para S (SUCESSO). Pronto, agora podemos executar o nosso pacote clicando no boto Executar na parte inferior da tela. Executando um Pacote Executando uma carga com sucesso (Figura 45) podemos notar na nossa tabela de log (LOG_CARGA) o seguinte registro: A CARGA DA SESSAO 77001 TERMINOU COM SUCESSO!

Figura 44. Setando o Status do procedimento de erro.

Figura 45. Execuo com sucesso do pacote. Neste ponto podemos simular um erro para verificar a diferena com o processo de carga anterior. Para esta simulao vamos dropar a tabela FATO_VENDAS do banco de destino. Executando o cenrio observamos que o fluxo foi desviado para o procedimento de LOG e foi gravado o seguinte registro (Figura 46): A CARGA DA SESSAO 79001 TERMINOU COM ERRO! VEJA OPERATOR PARA MAIS DETALHES. Percebe-se que existe uma diferena entre a Figura 45, que teve a execuo da carga aplicada com sucesso e a Figura 46 que resultou em erro. Gerando um Cenrio Agora que temos nosso pacote completo, falta apenas criar um cenrio, que nada mais do que a verso compilada do pacote. este cenrio que ser mandado para outros ambientes (testes, produo, etc.) e que ser utilizado para rodar as cargas. Para gerar um cenrio, basta clicar com o boto direito sobre o pacote e depois em Gerar cenrio (Figura 47).

Figura 46. Execuo com erro do pacote.

Figura 47. Gerando um cenrio.

Quando geramos um cenrio, temos a opo de colocar uma verso para o mesmo e tambm a opo de dizer quais so as variveis que o cenrio receber de entrada. Neste exemplo no temos variveis de entrada, logo, podemos desmarc-las. Pronto! Temos nosso cenrio criado, como pode ser visto na Figura 48.

Figura 48. Cenrio Criado. Este cenrio funciona como qualquer programa compilado, onde no sofre mais alteraes. possvel ento fazer modificaes nas nossas interfaces, modificar o fluxo do pacote, etc., porm este cenrio continuar com a verso compilada anteriormente. Podemos, no entanto, recriar o cenrio para refletir as modificaes que por ventura foram realizadas, bastando para isso clicar com o boto direito sobre o cenrio gerado e escolher a opo Regenerar.... Nota Devman - Sequence. No Oracle possvel gerar de forma automtica uma seqncia de nmeros, usando o comando sequence. Isto pode ser bastante til quando se pretende criar um nmero nico para uma chave primria. Concluso Vimos neste artigo a facilidade e a versatilidade do ODI para construir processos de ETL. Sem muito esforo, conseguimos integrar diferentes origens de dados (Oracle, Firebird e arquivo texto) para um destino nico Oracle. Fora a facilidade de se trabalhar com uma ferramenta visual, vimos que os Mdulos de Conhecimento (KMs) nos facilitam a manuteno e a padronizao dos cdigos, tornando assim o ODI uma grande ferramenta para o desenvolvimento dos processos de ETL.

Oracle RAC Instalao - Parte 2


Ricardo Portilho Proni Com 20 anos de experincia profissional, Ricardo Portilho Proni Oracle ACE e j trabalhou em grande parte dos maiores bancos de dados Oracle e MySQL do Brasil. certificado em Oracle, MySQL, SQL Server, DB2, Sybase e WebSphere. Consultor e Instrutor da Nerv Informtica Ltda (http://nervinformatica.com.br), tambm conselheiro dos grupos de usurios GPO e GUOB, e palestrante dos eventos ENPO, GUOB Tech Day e Oracle Open World LAD. De que se trata o artigo? Instalao de um Banco de Dados em Cluster simulado, baseado na arquitetura Oracle RAC. Este artigo o segundo de uma srie sobre RAC. Para que serve? Para disponibilizar o acesso a um nico Banco de Dados a partir de vrias Instncias, acomodadas em computadores diferentes. Em que situao o tema til? Em casos onde a disponibilidade e o poder de processamento so caractersticas fundamentais do ambiente. Nesta segunda parte, iremos finalizar a instalao de um banco de dados em Cluster utilizando o Oracle RAC. Na edio anterior, terminamos de instalar e configurar o Linux CentOS 4.7, e a mquina virtual foi desligada para iniciar a criao dos Shared Disks (Discos Compartilhados). Os Shared Disks so necessrios porque, como o Cluster trata de vrios computadores acessando o mesmo banco de dados, este precisa estar em um local que permita o acesso contnuo a todos os ns. Alm do banco de dados - que compreende os data files, temporary files, redo logs, control files, entre outros - dois componentes muito importantes do Oracle RAC necessitam de armazenamento em Shared Disks. Estes dois componentes so o OCR, ou Oracle Cluster Registry e o Voting Disk, que sero melhor explicados mais adiante. O Oracle RAC suporta vrios tipos de configurao para os Shared Disks. Podem ser utilizados Raw Devices, NFS (Nota DevMan), LVM, OCFS (Nota DevMan), OCFS2, ASM, ou mesmo filesystems proprietrios de Cluster, desde que seja homologado pela Oracle para uso com Oracle RAC. Nota Devman - NFS NFS (acrnimo para Network File System) um sistema de arquivos distribudos desenvolvido inicialmente pela Sun Microsystems, Inc., a fim de compartilhar arquivos e diretrios entre computadores conectados em rede, formando assim um diretrio virtual. O protocolo Network File System especificado nas seguintes RFCs: RFC 1094, RFC 1813 e RFC 3530 (que tornou obsoleta a RFC 3010). Nota Devman - OCFS OCFS significa Oracle Cluster File System. um sistema de arquivos compartilhado desenvolvido pela Oracle Corporation e lanado sob a licena GNU General Public License. A primeira verso do OCFS foi desenvolvida com o principal foco de acomodar arquivos de bancos de dados Oracle para bancos em Cluster. Por este motivo no era um sistema de arquivos compatvel com POSIX. Com a verso 2, as funcionalidades POSIX foram includas. OCFS2 (verso 2) foi integrada na verso 2.6.16 do kernel do Linux. Inicialmente, foi marcada como cdigo experimental. Esta restrio foi removida na verso 2.6.19. Com a verso 2.6.29 mais funcionalidades foram includas no ocfs2, especialmente controle de acesso e cotas. OCFS2 usa um gerenciador distribudo de arquivos que lembra o OpenVMS DLM, mas muito mais simples.

Nesta srie de artigos, iremos utilizar principalmente o ASM, ou Automatic Storage Management, que um sistema de arquivos de uso especfico para bancos de dados desenvolvido pela prpria Oracle. O ASM ser preferido por sua ampla adoo atual no mercado, sendo que a Oracle est visivelmente favorecendo seu desenvolvimento desde o incio em detrimento do OCFS e OCFS2. No nosso ambiente de testes, para evitar que o leitor precise adquirir um Storage para utilizar os Shared Disks, iremos emul-los utilizando os arquivos de discos do prprio VMware. Criao dos Shared Disks Iremos a seguir criar cinco discos virtuais: um para o OCR (Nota DevMan), um para o Voting Disk (Nota DevMan), e trs para o ASM. Nota Devman OCR O OCR utilizado no Oracle RAC para armazenar configuraes do Cluster e as informaes de status de cada recurso que administrado por ele. Por exemplo: os nomes dos ns, os endereos IPs e VIPs, qual a localizao dos voting disks, nomes dos bancos de dados e instncias, nomes dos listeners e etc. O OCR um arquivo de formato binrio, mantido pelo daemon CRS, que deve ser armazenado em uma partio - um Raw Device - ou um arquivo em um Cluster File System. Nota Devman - Voting Disk Um Voting Disk (Disco de Voto) um disco compartilhado, uma partio ou um arquivo usado para determinar a disponibilidade de um n do Cluster. Todas as instncias do RAC gravam no Voting Disk regularmente para indicar que esto ativas. Isso exigido, pois no caso de uma das instncias no poder se comunicar com a outra, as informaes de quais instncias esto ativas ainda esto disponveis para o Cluster em um local compartilhado. O Voting Disk pode ser armazenado, por exemplo, em um Raw Device ou um Cluster File System. Eles podem e devem ser espalhados para evitar-se um ponto nico de falhas no Cluster. Para criar o primeiro disco, o do OCR, siga os passos: 1. Desligue a mquina virtual; 2. No VMware, clique em Edit Virtual Machine Settings, e depois, em Add; 3. Em Add Hardware Wizard, clique em Next; 4. Em Hardware Type, selecione Hard Disk; 5. Em Select a Disk, selecione Create a Virtual Disk; 6. Em Select a Disk Type, selecione SCSI; 7. Em Specify Disk Capacity, selecione 10 GB em Disk Size. Deselecione Allocate all disk space now, e selecione Split into 2 GB files; 8. Em Specify Disk File, coloque C:\Virtual Machines\Shared\ocr.vmdk. No clique em Finish ainda, e clique em Advanced; 9. Em Advanced, em Virtual device node, selecione SCSI 1:1. Selecione tambm Independent, e depois Persistent; 10. Agora sim, clique em Finish. Para criar o segundo disco, o do Voting Disk, siga os passos 1 a 7 anteriores e logo aps: 8. Em Specify Disk File, coloque C:\Virtual Machines\Shared\votingdisk.vmdk. No clique em Finish ainda, e clique em Advanced; 9. Em Advanced, em Virtual device node, selecione SCSI 1:2. Selecione tambm Independent, e depois Persistent; 10. Agora sim, clique em Finish.

Para criar o terceiro disco, o primeiro do ASM, siga os passos 1 a 7 anteriores e logo aps: 8. Em Specify Disk File, coloque C:\Virtual Machines\Shared\asm1.vmdk. No clique em Finish ainda, e clique em Advanced; 9. Em Advanced, em Virtual device node, selecione SCSI 1:3. Selecione tambm Independent, e depois Persistent; 10. Agora sim, clique em Finish. Para criar o quarto disco, que ser o segundo do ASM, siga os passos 1 a 7 anteriores e logo aps: 8. Em Specify Disk File, coloque C:\Virtual Machines\Shared\asm2.vmdk. No clique em Finish ainda, e clique em Advanced; 9. Em Advanced, em Virtual device node, selecione SCSI 1:4. Selecione tambm Independent, e depois Persistent; 10. Agora sim, clique em Finish; Da mesma forma, para criar o quinto disco, que ser o terceiro do ASM, siga os passos 1 a 7 anteriores e logo aps: 8. Em Specify Disk File, coloque C:\Virtual Machines\Shared\asm3.vmdk. No clique em Finish ainda, e clique em Advanced; 9. Em Advanced, em Virtual device node, selecione SCSI 1:5. Selecione tambm Independent, e depois Persistent; 10. Agora sim, clique em Finish.

Configurao dos Shared Disks Depois de criar os discos na mquina virtual, iremos editar o seu arquivo de configurao para a simulao dos Shared Disks. Verifique se as linhas da Listagem 1 esto no arquivo C:\Virtual Machines\RAC1\Red Hat Enterprise Linux 4.vmx. Olhe linha a linha. Se a linha j existir, deixe-a intacta. Se no existir, adicione-a. Particionamento dos Shared Disks Agora precisamos configurar estes discos novos dentro do Linux. Para isto, inicie o RAC1. Durante a inicializao do CentOS, quando o Kudzu (um servio do CentOS que verifica se ocorreram mudanas no hardware) avisar que um novo hardware foi encontrado, selecione a opo Configure. Aps a inicializao, execute logon com o usurio root, e execute os comandos da Listagem 2. Estes comandos, com o utilitrio fdisk, iro criar uma partio (Nota DevMan) em cada disco. Nota Devman - Parties Uma partio uma diviso de um disco rgido (SCSI ou ATA). Cada partio pode conter um sistema de arquivos diferente. Conseqentemente, vrios sistemas operacionais podem ser instalados na mesma unidade de disco.

Listagem 1. Configurao do arquivo C:\Virtual Machines\RAC1\Red Hat Enterprise Linux 4.vmx. disk.locking = "FALSE" diskLib.dataCacheMaxSize = "0" diskLib.dataCacheMaxReadAheadSize = "0" diskLib.dataCacheMinReadAheadSize = "0" diskLib.dataCachePageSize = "4096" diskLib.maxUnsyncedWrites = "0" scsi1.sharedBus = "VIRTUAL" tools.syncTime.period = "1" timeTracker.periodicStats="TRUE" timeTracker.statsIntercal="10" reslck.timeout = "300" scsi1:1.deviceType = "plainDisk" scsi1:1.redo = "" scsi1:2.deviceType = "plainDisk" scsi1:2.redo = "" scsi1:3.deviceType = "plainDisk" scsi1:3.redo = "" scsi1:4.deviceType = "plainDisk" scsi1:4.redo = "" scsi1:5.deviceType = "plainDisk" scsi1:5.redo = "" Listagem 2. Comandos a serem executados como root. fdisk /dev/sdb 1. - Aperte a tecla n, para criar uma nova partio; 2. - Em seguida, aperte a tecla p, para que a nova partio seja primria; 3. - Em seguida, aperte a tecla 1, pois ser a primeira partio do disco; 4. - Em seguida, aperte Enter, para aceitar as opes padro de tamanho, usando todo o disco; 5. - Em seguida, aperte w, para gravar as alteraes. fdisk /dev/sdc -- siga os passos 1 a 5 fdisk /dev/sdd -- siga os passos 1 a 5 fdisk /dev/sde -- siga os passos 1 a 5 fdisk /dev/sdf -- siga os passos 1 a 5 Em seguida, para que cada partio seja relacionada a um raw device, edite o arquivo /etc/sysconfig/rawdevices e adicione as linhas da Listagem 3. Listagem 3. Configurao do arquivo /etc/sysconfig/rawdevices. /dev/raw/raw1 /dev/sdb1 /dev/raw/raw2 /dev/sdc1 /dev/raw/raw3 /dev/sdd1 /dev/raw/raw4 /dev/sde1 /dev/raw/raw5 /dev/sdf1

Depois, execute os comando da Listagem 4 como root. Listagem 4. Comandos a serem executados como root. service rawdevices restart ln -s /dev/raw/raw1 /u01/oradata/ocr ln -s /dev/raw/raw2 /u01/oradata/votingdisk ln -s /dev/raw/raw3 /u01/oradata/asm1 ln -s /dev/raw/raw4 /u01/oradata/asm2 ln -s /dev/raw/raw5 /u01/oradata/asm3 chown oracle:oinstall /dev/raw/raw1 chown oracle:oinstall /dev/raw/raw2 chown oracle:oinstall /dev/raw/raw3 chown oracle:oinstall /dev/raw/raw4 chown oracle:oinstall /dev/raw/raw5 chmod 600 /dev/raw/raw1 chmod 600 /dev/raw/raw2 chmod 600 /dev/raw/raw3 chmod 600 /dev/raw/raw4 chmod 600 /dev/raw/raw5 Pronto, o primeiro n do Cluster est pronto para receber o Clusterware. Clonando a Mquina Virtual Para no termos que instalar o outro n desde o incio, iremos simplesmente clonar o primeiro n, que j est configurado da forma correta. Para fazer a clonagem: - Desligue o primeiro n. A partir de agora, iremos nos referir a ele pelo nome da mquina, ou seja, RAC1; - Copie a pasta C:\Virtual Machines\RAC1 para C:\Virtual Machines\RAC2; - No arquivo C:\Virtual Machines\ RAC2\Red Hat Enterprise Linux 4.vmx, procure pela linha que contm displayName = "RAC1" e mude para DisplayName = "RAC2". - No Vmware, importe o RAC2 (File Open - Browse) - Inicie o RAC2 (ainda no inicie o RAC1) - Ao iniciar a VM, escolha a opo Create - No Kudzu, escolha Keep Configuration e depois Ignore Agora, com o RAC2 ligado, precisamos ajustar suas configuraes de rede, que neste momento esto iguais ao do RAC1, de onde foi clonado. Para isso: - Execute logonj no RAC2, como root, no ambiente grfico; - Clique em Applications, depois em System Settings, e escolha o menu Network; - Clique em DNS. Em Hostname, coloque rac2.localdomain; - Clique na aba Devices e selecione eth0. Em Edit, clique em Hardware Device, depois em Probe, e OK. Este passo foi necessrio para alterar-se o MAC Address da placa de rede virtual, que deve ser trocado quando a mquina virtual clonada; - Na aba Devices, selecione eth0, clique em Edit, e General. Em Address, mude o final do endereo IP de 101 para 102; - Clique na aba Devices e selecione eth1. Em Edit, clique em Hardware Device, depois em Probe, e OK. Este passo foi necessrio para alterar-se o MAC Address da placa de rede virtual, que deve ser trocado quando a mquina virtual clonada. - Na aba Devices, selecione eth1, clique em Edit, e General. Em Address, mude o final do endereo IP de 101 para 102; - Clique em File, e em Save. Clique em OK; - Em Devices, selecione eth0, e clique em Activate; - Em Devices, selecione eth1, e clique em Activate; - Como usurio oracle, edite o arquivo /home/oracle/.bash_profile, e troque ORCL1 por ORCL2. Este ser o SID do Oracle no no RAC2.

Pronto, o RAC 2 est com o nome da mquina e endereos IPs corretos. Neste momento, voc pode ligar o RAC1 novamente, pois no haver conflitos de IP. Instalao do Oracle Clusterware Agora iremos instalar o software que ir cuidar da administrao do Cluster e todos os programas que funcionaro neste ambiente, incluindo o prprio Oracle (ler Nota DevMan ). Nota Devman - Oracle Clusterware Oracle Clusterware um software de Cluster portvel que agrupa servidores individuais para que cooperem como um nico sistema. Componente fundamental do Oracle RAC, o Oracle Clusterware pode operar de forma independente e ajuda a assegurar a proteo de um aplicativo, seja da Oracle ou de terceiros. O Oracle Clusterware possibilita a alta disponibilidade, um componente essencial da continuidade dos negcios, para aplicativos e bancos de dados gerenciados no ambiente de Cluster incluindo bancos de dados Oracle de uma nica instncia, Oracle Application Server, componentes do Oracle Enterprise Manager, bancos de dados de outros fornecedores e outros aplicativos. A instalao do Oracle Clusterware s precisa ser feita em um dos ns, e automaticamente ser replicada para todos os outros ns existentes no Cluster. Em um certo momento da instalao, sero solicitados que sejam executados scripts como o usurio root em todos os ns, mas a maior parte da instalao replicada automaticamente por todo o Cluster. Para instalar o Oracle Clusterware, teremos que copiar os Softwares baixados anteriormente da mquina Host (Windows) para a mquina Virtual (Linux). Este tipo de cpia pode ser feita com um utilitrio como o WinSCP. O WinSCP pode ser baixado em http://winscp.net. - Copie o arquivo 10201_clusterware_linux32.zip para o RAC1; - Copie o arquivo 10201_database_linux32.zip para o RAC1; - Execute logon no RAC1 com o usurio oracle, e descompacte os arquivos (Listagem 5). - Verifique se h uma linha no arquivo /etc/hosts que comea com 127.0.0.1. Esta linha deve estar como na Listagem 6. Se no estiver, edite-a para que fique correta: - Execute logon no RAC2, com o usurio root. Listagem 5. Comandos a serem executados como o usurio oracle. cd /home/oracle unzip 10201_clusterware_linux32.zip unzip 10201_database_linux32.zip Listagem 6. Configurao do arquivo /etc/hosts. 127.0.0.1 localhost Agora iremos iniciar o assistente para instalao do Oracle Clusterware. No RAC1, abra um terminal e execute os comandos da Listagem 7. O ltimo comando da Listagem 7 ir lanar o instalador do Clusterware. Depois de iniciado o instalador do Clusterware, siga este passos: - Clique em Next; - Na tela Specify Cluster Configuration, voc deve verificar se os nomes dos ns do Cluster esto corretos. Nesta tela, so informados os 3 nomes (sendo que cada um corresponde a um endereo IP, configurados anteriormente) de cada n: um pblico (Public Node Name), um privado (Private Node Name), e um virtual (Virtual Node Name), conforme mostrado na Figura 1. Em seguida, clique em Next; - Na tela Specify Network Interface Usage, devem ser especificadas as redes pblicas e privadas dos ns. Na linha que mostra a Interface Name como eth0, voc deve colocar no campo Subnet o endereo 192.168.202.0. Da mesma forma, na linha que mostra a Interface Name a eth1, voc deve colocar no campo Subnet o enredeo 192.168.203.0.

Listagem 7. Comandos a serem executados como o usurio oracle. export $ORACLE_HOME=$CRS_HOME /home/oracle/clusterware/runInstaller.sh

Figura 1. Tela Specify Cluster Configuration. - Na tela Specify Network Interface Usage, devem ser especificadas as redes pblicas e privadas dos ns. Na linha que mostra a Interface Name como eth0, voc deve colocar no campo Subnet o endereo 192.168.202.0. Da mesma forma, na linha que mostra a Interface Name a eth1, voc deve colocar no campo Subnet o enredeo 192.168.203.0.(Figura 2.)

Figura 2. Tela Specify Network Usage Configuration.

- Na tela Specify Oracle Cluster Registry (OCR) Location, deve ser especificado o link simblico para o raw device que configuramos anteriormente para o OCR, o /u01/oradata/ocr, como est na Figura 3. Em seguida, clique em Next;

Figura 3. Tela Specify Oracle Cluster Registry (OCR) Location. - Na tela Specify Voting Disk Location, deve ser especificado o link simblico para o raw device que configuramos anteriormente para o Voting Disk, o /u01/oradata/votingdisk, como est na Figura 4. Em seguida, clique em Next;

Figura 4. Tela Specify Voting Disk Location. - Aps executados estes passos, a instalao do Clusterware ir prosseguir nos dois ns, e o instalador ir executar uma verificao ao trmino da instalao. Em alguns ambientes, o VIPCA no configurado automaticamente, e isto ser acusado nesta ltima verificao, como na Figura 5. Mas isto no um problema: quando o ltimo check acusar problemas, como root, execute o VIPCA (Virtual IP Configuration Assistant).

Figura 5. Erro na verificao final do Clusterware.

Para executar o VIPCA, abra um terminal, e como root, execute o comando da Listagem 8. Listagem 8. Comandos a serem executados como o usurio root. /u01/app/oracle/product/10.2.0/crs/bin/vipca - No VIPCA, devem ser configurados os nomes e IPs dos VIPs (192.168.202.111 e 192.168.202.112), como demonstrado na Figura 6.

Figura 6. Configurao do VIPCA. Aps executar o VIPCA, volte para a tela de instalao do Clusterware, clique em Retry na verificao, em seguida, em Finish. Pronto, o Clusterware foi instalado com sucesso e est pronto para receber o Oracle.

Instalao do Oracle Agora o Cluster est pronto para receber o software que ir gerenciar o banco de dados. A instalao do Oracle em ambiente RAC s precisa ser feita em um dos ns, e automaticamente ser replicada para todos os outros ns existentes no Cluster. Para instalar o Software Oracle, execute logon no RAC1, e execute o comando da Listagem 9. Ser iniciado ento o Oracle Universal Installer. Na tela inicial do OWI, clique em Next. Selecione a opo "Enterprise Edition", e depois clique em "Next"; - Aceite as opes para o ORACLE_HOME, clicando em Next; - Selecione a opo "Cluster Installation", e verifique se os dois ns do Cluster esto selecionados. Depois, clique em Next; - Aguarde a verificao dos pr-requisitos. Tudo deve ocorrer bem nesta verificao se todos os passos anteriores forem cumpridos. Depois, clique em Next. Se houver algum warning, provavelmente ser pelos pr-requisitos de memria, mas isso no ser problema neste ambiente. Pode clicar em Yes, se este tipo de alerta aparecer; - Em Select Configuration Option, escolha Configure Automatic Storage Management (ASM), escolha uma senha para administrar o ASM (Nota DevMan), e clique em Next. Esta opo far com que, alm de instalar o Software, o ASM j seja configurado. As instncias ASM iro rodar nos dois ns, sobre os discos virtuais criados e gerenciar os arquivos do banco de dados. Tambm ser necessrio criarmos um Disk Group, que a unidade bsica de gerenciamento de discos no ASM, onde poderemos colocar os dados. Listagem 9. Comandos a serem executados como o usurio oracle. /home/oracle/database/runInstaller.sh

Nota Devman ASM Automatic Storage Management (ASM) uma funcionalidade provida pelo Oracle a partir da verso 10g reviso 1. ASM procura simplificar o gerenciamento de arquivos de bancos de dados. Para isso, ele oferece ferramentas para gerenciar sistemas de arquivos e volumes diretamente dentro do kernel do banco de dados, permitindo que administradores de bancos de dados (DBAs) controlem volumes e discos com familiares comandos SQL no Oracle. Desta forma o DBA no precisa de conhecimentos extras em sistemas de arquivos especficos ou gerenciadores de volume, que geralmente operam no nvel do sistema operacional. Com ASM: - IOs podem tomar vantagem de striping de dados e mirroring via software. - DBAs podem automatizar redistribuies sem paradas, com a adio ou remoo de discos. - O sistema mantm cpias redundantes e oferece funcionalidades de RAID de terceiros. - Oracle suporta tecnologias de multipathing IO de terceiros (failover ou load balancing para acessos a SAN, etc.) - A necessidade de hot spares diminui. - Em Configure Automatic Storage Management, como em Disk Group Name, coloque DATA. Este ser o nome do Disk Group que usaremos para o Banco de Dados. Selecione o nvel de Redundancy como External, que nenhuma redundncia, o que apropriado para nosso teste, mas no para um ambiente produtivo. No quadro Candidate Disks, verifique se os trs raw devices que criamos anteriormente esto selecionados (/dev/raw/raw3, /dev/raw/raw4 e /dev/raw/raw5). - Clique em Install, e aguarde a finalizao da instalao e configurao do ASM. - Ao trmino da instalao, ser solicitado que um script seja executa como root. Execute conforme esta tela lhe mostrar, e depois prossiga.

Criao do banco de dados Iremos agora criar o banco de dados. Esta operao, na verso 10g, bem mais tranquila, pois pode ser feita com o assistente DBCA, ou Database Configuration Assistant. Esta operao s precisa ser feita em um dos ns do cluster, e as instncias sero criadas automaticamente em todos os ns. Neste artigo iremos executar esta configurao a partir do RAC1. Para criar o banco de dados: - Verifique se o RAC1 e RAC2 esto iniciados; - Execute logon no RAC1 com o usurio oracle, e inicie o Database Configuration Assistant, digitando F2, e em seguida, dbca; - Em "Welcome", selecione a opo "Oracle Real Application Clusters database", e depois clique em "Next"; - Selecione "Create a Database", e depois clique em "Next"; - Selecione os dois ns do RAC, e depois clique em Next; - Selecione "Custom Database", e depois clique em "Next"; - Em Global Database Names, coloque ORCL. Em SID, tambm coloque ORCL. Este ser o nome do Banco de Dados. Depois, clique em Next; - Aceite as opes de gerenciamento, e clique em Next; - Selecione senhas para as contas do Banco de Dados. Depois, clique em Next; - Selecione a opo Automatic Storage Management (ASM)", e depois clique em "Next"; - Selecione DATA como Disk Group, e depois clique em Next; - Aceite a opo Use Oracle-Managed Files", e depois clique em Next; - Selecione a opo "Specify Flash Recovery Area" e "Enable Archiving. Coloque "+DATA" como a Flash Recovery Area, e depois clique em "Next"; - Aceite as configuraes padro de Database Services, clicando em Next; - Em Memory Management, Selecione a opo "Custom", e depois clique em Next; - Aceite as opes de Storage Settings, clicando em Next; - Aceite as opes de Database Creation, clicando em Next; - Aceite as informaes do Summary Information, clicando em Next; Espere enquanto o DBCA finaliza a criao do banco de dados. Quando a instalao terminar, pode clicar em Finish. Pronto, seu banco de dados em Cluster est rodando!

Concluses Neste artigo finalizamos a instalao de um banco de dados em Cluster utilizando Oracle RAC, rodando sobre mquinas virtuais em VMware Server, e utilizando o Linux CentOS. No prximo artigo, iremos abordar as tarefas de administrao do Oracle RAC, e ver como elas diferem de uma implementao Single Instance do Oracle. Veremos como funciona o Backup e Restore, os Archived Redo Logs, as manutenes no ASM, Backup e Restore do OCR e Voting Disk, como adicionar e remover ns, e executar Rolling Upgrades, que so as aplicaes de patch sem indisponiblidade. Abraos e at a prxima!