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 TempoPaulo 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 ; quando, porm, um n representa um ambiente de execuo, pode utilizar o esteretipo . 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 . 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 . 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 DevmanNa 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 , 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 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 SQLWagner 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/2008Priscila 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 2008Pedro 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