CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA

Transcrição

1 CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS CLÁUDIA QUINTO FELIX RENATA TAVARES VERGINASSI REPLICAÇÃO ENTRE BANCOS DE DADOS HETEROGÊNEOS UM ESTUDO SOBRE A REPLICAÇÃO ENTRE OS BANCOS ORACLE E MYSQL LINS/SP 1º SEMESTRE/2012

2 CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS CLÁUDIA QUINTO FELIX RENATA TAVARES VERGINASSI REPLICAÇÃO ENTRE BANCOS DE DADOS HETEROGÊNEOS UM ESTUDO SOBRE A REPLICAÇÃO ENTRE OS BANCOS ORACLE E MYSQL Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins para obtenção do Título de Tecnólogo(a) em Banco de Dados. Orientador: Prof. Me. Luiz Fernando de Oliveira Silva. LINS/SP 1º SEMESTRE/2012

3

4 Este trabalho é dedicado as nossas famílias, amigos e professores.

5 AGRADECIMENTOS Agradecemos em primeiro lugar a Deus que nos guia e protege. As nossas famílias, amigos e professores. Ao nosso orientador Luiz Fernando, ao professor Naylor e ao nosso grande amigo José Renato, pois sem ele nosso trabalho não teria continuidade.

6 RESUMO Atualmente as organizações buscam a ampliação de seus negócios, visando disseminar a informação. Para tornar isto possível, a informação precisa ser rápida, integra e sempre disponível. Sendo assim, a utilização de métodos que objetivam a transmissão da informação, levando-as até seu destino e assim, faz com que permaneça disponível ao responsável pela sua emissão. Neste sentido, a replicação de banco de dados é um dos métodos que possibilitam a disseminação da informação tornado-a sempre acessível e disponível, já que permite a disponibilização mesmo na ocorrência de falhas na rede. A replicação pode também auxiliar na implantação de políticas de utilização e realização de backup, tornando a informação sempre disponível a quem tiver direito de acessá-la. Este trabalho apresenta a replicação entre bases de dados heterogêneas. A replicação foi desenvolvida por meio de um estudo de caso entre os bancos de dados heterogêneos Oracle e MySQL, utilizando a ferramenta de replicação ObjectMMRS. Palavras-chave: Replicação, Oracle, MySQL, Banco de dados, ObjectMMRS.

7 ABSTRACT Currently seeking organizations to expand their business in order to disseminate information. To make this possible, the information needs to be fast, integrated and always available. Thus, the use of methods that focus on the transmission of information, leading them to their destination and thus makes available to remain responsible for their issuance. In this sense, the replication database is one of the methods that enable the dissemination of information made it always accessible and available, which enables the provision even in the event of network failures. Replication can also assist in the implementation of policies for use and backing up, making the information always available to those who have right to access it. This paper presents a replication between heterogeneous databases. Replication has been developed through a case study among heterogeneous databases Oracle and MySQL, using the replication tool ObjectMMRS. Keywords: Replication, Oracle, MySQL, Databases, ObjectMMRS.

8 LISTA DE ILUSTRAÇÕES Figura 1.1: Arquitetura do Oracle...9 Figura 1.2: Arquitetura do MySQL...20 Figura 2.1- Um sistema distribuído...23 Figura 3.1: Replicação Passiva...32 Figura 3.2: Replicação ativa...32 Figura 4.1: Configuração do alias de rede...39 Figura 4.2: Arquivo objectdb.properties...40 Figura 4.3: Arquivo publicar.bat...41 Figura 4.4 Configuração do slave de uma base master...41 Figura 4.5: Operações DML...41 Figura 4.6: Teste de conexão...42 Figura 4.7: Arquivo run.bat...42 Figura 4.8: Arquitetura de replicação...43 Figura 4.9: Operações de Insert no SGBD Oracle...44 Figura 4.10: Operação Select no SBGD MySQL...44 Figura 4.11: Operações de Update no SGBD Oracle...45 Figura 4.12: Operações de Select no SGBD MySQL...45 Figura 4.13: Operações de Delete no SGBD Oracle...46 Figura 4.14: Operações de Select no SGBD MySQL...46

9 LISTA DE SIGLAS ANSI - American National Standards Institute. BDD - Banco de Dados Distribuído. CODASYL - Conference on Data Systems Languages. DML - Data Manipulation Language. ERP - Enterprise Resource Planning. IBM - Internacional Business Machines. IMS - Information Management SysteM. ISO - International Organization of Standardization. LAN - Local-Area Networks. LCR - Logical Change Records. MRP - Management Resource Planning. MSDNAA Microsoft Develop Network Academic Alliance. OLTP On-Line Transaction Processing. SABRE - Semi-Automatic Business Related Environment. SGA - System Global Area. SGBD - Sistema Gerenciador de Banco de Dados. WAN - Wide-Area Networks.

10 SUMÁRIO INTRODUÇÂO HISTÓRIA DOS BANCOS DE DADOS ARQUIVOS DE SISTEMAS VERSUS SGBD Vantagens de um SGBD ARQUITERA ORACLE ARQUITETURA MYSQL BANCOS DE DADOS DISTRIBUÍDOS SISTEMA DE GERÊNCIA DE BANCO DE DADOS DISTRIBUÍDOS Arquitetura genérica para SGBDs Distribuídos Tipos de Bancos de Dados Distribuídos Arquiteturas de SGBD Distribuído PROJETO LÓGICO DE BANCO DE DADOS DISTRIBUÍDOS Fragmentação de dados Replicação e Alocação de dados Banco de Dados Distribuídos X Banco de Dados Replicados REPLICAÇÃO TÉCNICAS DE REPLICAÇÃO MODELO DE REPLICAÇÃO MÉTODOS DE REPLICAÇÃO CONFLITOS DE REPLICAÇÃO REPLICAÇÃO UTILIZADA NO ORACLE Visão materializada ESTUDO DE CASO OBJECTMMRS... 38

11 4.2 CRIAÇÃO DO PROCESSO DE REPLICAÇÃO CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS... 48

12 11 INTRODUÇÂO Com o avanço do uso das tecnologias, o acesso à informação passou a ser imprescindível. A partir deste fato, começaram as preocupações com a segurança das informações contidas em banco de dados, tais preocupações estão relacionadas à perda de informações, fraudes e também a danos causados nos equipamentos que ocasionariam problemas no armazenamento e processamento de dados. Partindo desta necessidade iniciou-se a replicação de banco de dados, segundo Oliveira (2006), a replicação de dados aparece como uma forma de melhorar a disponibilidade de informações dentro de ambientes e sistemas oferecendo diversas funcionalidades para o controle e disponibilidade de dados replicados. O autor ainda afirma que as técnicas de replicação são utilizadas em muitos sistemas e aplicações, tais como: aplicações de massa crítica, sistemas de suporte a decisão, sistemas de tempo real, entre outros. A replicação aumenta a disponibilidade dos dados e também o desempenho dos sistemas, já que em muitos casos as informações estão disponíveis em mais de um lugar. De acordo com Hopkins; Thomas (1998) a replicação em um banco de dados tem dois tipos básicos: síncrona onde as atualizações são aplicadas na mesma transação e assíncrona onde as atualizações são passadas em transações separadas. A escolha do tipo de replicação deve ser feita de acordo com a necessidade do banco de dados a ser replicado. Um sistema de banco de dados deve prever o uso da replicação de dados como uma forma de mantê-los atualizados e consistentes aumentando o desempenho geral do sistema e dando privilégio ao acesso de dados mais próximos. Este trabalho tem como objetivo principal estudar a replicação de dados utilizando os Sistemas Gerenciadores de Banco de Dados (SGBD) Oracle e MySQL, sua utilização, implementação, ferramentas e aplicação. Dentre os objetivos específicos estão: conhecer a história da utilização de banco de dados e sua evolução; analisar as ferramentas existentes no mercado para a implementação da replicação; compreender a replicação de dados, seu funcionamento, características e também os motivos que levaram a sua utilização. No que se refere a metodologia, a composição deste trabalho será feita a

13 12 partir de revisões bibliográficas de diversos autores, tais como: Oliveira, Hopkins; Thomas, Gehrke; Ramakrisnan, entre outros e estudos especializados no assunto para que este possa servir como uma base para estudos futuros. É importante analisar esta questão, pois a replicação de dados se faz necessária para garantir a segurança de dados contidos nos bancos de dados, pois assim haverá uma maneira de se recuperar os mesmos casos haja algum problema. O resultado desta pesquisa será apresentado através de uma implementação de replicação de dados em bancos de dados heterogêneos. No primeiro capítulo é feita um levantamento sobre o uso dos bancos de dados ao longo da história e sua evolução. O segundo capítulo será feita uma explanação sobre banco de dados distribuídos, seus aspectos e utilização. O terceiro capítulo aborda a replicação de dados, sua funcionalidade e as ferramentas que possibilitam sua utilização. Já no quarto capítulo é realizada a configuração de bancos de dados heterogêneos onde será exemplificada a replicação de dados através da ferramenta ObjectMMRS, observando sua configuração, desenvolvimento e resultados. A conclusão é feita a partir de uma retomada dos motivos que levaram a sua realização e se os objetivos propostos foram alcançados. Propõe-se também possíveis continuações deste trabalho para que assim a replicação seja aprofundada em alguns aspectos relevantes.

14 13 1 HISTÓRIA DOS BANCOS DE DADOS Neste capítulo será abordado o início e a evolução dos bancos de dados. Serão analisados os motivos que levaram a sua criação e seu fundamento nos antigos arquivos de sistemas. Desde os primeiros computadores, armazenar e manipular dados têm sido o principal objetivo dos aplicativos. Segundo Gehrke; Ramakrisnan (2008), o primeiro Sistema Gerenciador de Banco de Dados (SGBD) de propósito geral foi projetado no início da década de 1960 por Charles Bachman, na General Eletric, foi chamado de Depósito de Dados Integrados (Integrated Data Store). Ele constitui a base para o modelo de dados de rede padronizado pela Conference on Data Systems Languages (CODASYL) e teve uma forte influência nos sistemas de banco de dados da década de Pelo trabalho na área de banco de dados, em 1973 Bachman recebeu o premi Turing da ACM que é o equivalente ao prêmio Nobel na Ciência da Computação. Os autores seguem afirmando que em 1960 a Internacional Business Machines (IBM) desenvolveu o SGBD Sistema de Gerenciamento da Informação o Information Management System (IMS) que ainda é usado atualmente em diversas instalações. O IMS compõe a base da estrutura de representação alternativa de dados, chamada de modelo de dados hierárquico. O sistema Semi-Automatic Business Related Environment (SABRE) desenvolvido pela American Airlines e IBM que servia para reservas de passagens permitiu que diversas pessoas acessassem os mesmos dados através de uma rede de computadores. Nos dias de hoje o mesmo sistema SABRE é utilizado para fornecer serviços populares de viagens baseados na Web, tais como o Travelocity. Em 1970 foi proposta uma nova estrutura de representação de dados chamada de modelo de dados relacional, que se tornou um marco histórico no desenvolvimento de sistema de banco de dados. Esta estrutura foi proposta por Edgar Codd do Laboratório de Pesquisas de San Jose da IBM. Sendo assim, impulsionou o rápido desenvolvimento de vários SGBDs baseados no modelo relacional, juntamente com um rico conjunto de resultados teóricos que consolidaram a área. O prêmio Turing foi dado a Codd em 1981, pelo seu trabalho original. Os sistemas de banco de dados foram amadurecendo como uma disciplina

15 14 acadêmica, e a popularidade dos SGBDs relacionais alterou o cenário comercial. Os benefícios trazidos por eles foram amplamente reconhecidos e o uso dos SGBDs para gerenciar dados corporativos passou a ser uma prática padrão. (GEHRKE; RAMAKRISNAN, 2008) Durante o desenvolvimento dos SGBDs, surgiram alguns modelos de banco de dados, tais como: o modelo de banco de dados hierárquico que é descrito por um diagrama de estrutura de árvore, com dois componentes básicos: as caixas correspondentes aos tipos de registro e as linhas que representam as ligações entre os tipos de registro; o modelo de rede, que é composto de uma estrutura mais completa, por possuir as propriedades básicas de registros, conjuntos e ocorrências, e utiliza a linguagem de definição de bancos de dados e linguagem de manipulação de dados, além de permitir uma evolução mais eficiente do modelo hierárquico e também o relacional que é composto de relações entre entidades, possuindo fortes características de segurança, compartilhamento e integridade dos dados. Ainda segundo Gehrke; Ramakrisnan (2008), na década de 1980 o modelo relacional foi consolidado como o paradigma dominante de SGBD, e o uso dos sistemas de banco de dados continuou a ser difundido cada dia mais. A linguagem de consulta SQL para banco de dados relacional que foi desenvolvida como parte de um projeto chamado System R da IBM, passou então a ser a linguagem de consultas padrão. Esta linguagem foi padronizada no fim da década de 1980, pela American National Standards Institute (ANSI) e International Organization of Standardization (ISO). Pode-se argumentar que a maneira mais utilizada de programação concorrente é a execução concorrente de programas de banco de dados, que são chamadas de transações. Nela os usuários escrevem os programas como se fossem executá-los de maneira isolada, dando a responsabilidade de executá-los de forma concorrente ao SGBD. Em 1999 James Gray ganhou o prêmio Turing por suas contribuições para o gerenciamento de transações de banco de dados. No fim dos anos 1980 e na década de 1990 houve grandes avanços em diversas áreas dos sistemas de bancos de dados. Foram realizadas pesquisas para o desenvolvimento de linguagens de consultas mais poderosas e modelos de dados mais ricos, dando ênfase no suporte à análise complexa de dados originários de todas as áreas da empresa. Muitos fabricantes estenderam seus sistemas com a capacidade de armazenar novos tipos de dados, tais como, imagens e textos, e

16 15 também possibilitando consultas mais complexas. Alguns sistemas especializados têm sido desenvolvidos por muitos fabricantes para criarem data warehouses, fazendo a consolidação dos dados de diversos bancos de dados, com o objetivo de conduzir uma análise especializada. (MACHADO, 2008) De acordo com Machado (2008), é interessante o fenômeno da emergência de diversos pacotes de planejamento de recurso empresarial, ou, Enterprise Resource Planning (ERP) e de planejamento de recurso de gerenciamento, ou, Management Resource Planning (MRP), que acrescentaram uma camada substancial de recursos orientados a aplicativos acima de um SGBD. Os pacotes utilizados incluíam sistemas Baan, Oracle, PeopleSoft, SAP e Siebel. Tais pacotes identificam um conjunto de tarefas comuns, tais como, gerenciamento de inventário, planejamento de recursos humanos e análise financeira, que são desempenhadas por muitas organizações e que fornecem uma camada de aplicativos genérica que realize todas essas tarefas. Um dado é armazenado em um SGBD relacional, e sua camada de aplicativos pode ser customizada de acordo com a necessidade de cada empresa, o que diminui os custos totais para as organizações se comparados ao custo de criar uma camada de aplicativos do início. Ainda segundo o autor, talvez a entrada dos SGBDs na Era Internet seja o fato histórico mais significativo, pois enquanto a primeira geração de web sites armazenava seus dados exclusivamente em arquivos do sistema operacional, o uso dos SGBDs para armazenar dados que podem ser acessados através de um navegador Web foi difundido cada vez mais. As consultas passam a ser geradas através de formulários acessíveis na Web e respostas são formatadas em linguagem de marcação HTML, para que assim possam ser facilmente exibidas nos navegadores. Sendo assim os fabricantes de SGBDs estão acrescentando a eles recursos que tem com o objetivo adequá-los ao desenvolvimento para a Internet. De acordo com Nassu (1999), o gerenciamento de banco de dados se torna mais importante conforme mais dados ficam disponíveis on-line e mais acessíveis através da rede de computadores. Hoje em dia a área está sendo impulsionada por idéias inovadoras, dentre elas pode-se citar banco de dados multimídia, vídeo interativo, fluxo de dados, bibliotecas digitais, além do desejo de empresas de consolidar seus processos de tomada de decisão e vasculhar seus repositórios de dados em busca de informações úteis sobre seus negócios. Em termos de comércio, os SGBDs representam um dos maiores segmentos do mercado.

17 ARQUIVOS DE SISTEMAS VERSUS SGBD Segundo Nassu (1999), para que seja possível compreender a necessidade de um SGBD, é importante considerar um cenário motivador, por exemplo, em uma empresa que possui cerca de 500GB de dados sobre seus funcionários, departamentos, produtos, vendas e etc. Tais dados são acessados por diversos funcionários ao mesmo tempo, e as consultas sobre estes dados devem ser respondidas de forma rápida, as alterações que forem realizadas nos dados pelos diversos usuários deveram ser aplicadas de maneira consistente, e o acesso a algumas partes dos dados, tais como, o salário, devem ser marcados como restrito. O autor ainda afirma que o gerenciamento de dados armazenados em um sistema tem algumas desvantagens, são elas: o espaço para armazenamento na memória principal provavelmente não será suficiente, então será necessário armazenar os dados em dispositivos de memória tais como disco ou fita, e os dados mais importantes devem ser carregados na memória principal; mesmo no caso de se ter o espaço suficiente, em se tratando de um sistema computacional de 32 bits de endereçamento, não será possível fazer a referencia direta a mais do que aproximadamente 4GB de dados, o que tornará necessária a programação de algum método de identificação de todos os itens de dados; torna-se necessário escrever programas complexos especiais para responder cada pergunta sobre os dados que o usuário fizer; os dados devem ser protegidos de alterações inconsistentes realizadas por usuários, assegurar que os dados sejam restaurados a um estado consistente caso ocorra falha no sistema enquanto as alterações estejam sendo feitas e os sistemas operacionais tem apenas um mecanismo de senha para a segurança, o que não é suficiente para reforçar as políticas de segurança que determina as permissões dos diferentes usuários. As tarefas mencionadas anteriormente são mais facilmente tratadas e executadas pelos SGBDs. Armazenar dados em um SGBD ao invés de uma coleção de arquivos de sistema operacional torna possível utilizar os recursos do SGBD para realizar o gerenciamento de dados de forma robusta e eficiente. Conforme ocorre o crescimento do volume dos dados e o número de usuários o suporte de um SGBD torna-se imprescindível (NASSU, 1999)

18 Vantagens de um SGBD De acordo com Machado (2008) o uso de um SGBD para realizar o gerenciamento de dados traz inúmeras vantagens, tais como: independência de dados; acesso eficiente aos dados; integridade e segurança de dados; administração de dados; tempo reduzido de desenvolvimento de aplicativo; acesso concorrente e recuperação de falhas. A independência de dados consiste na capacidade de permitir que haja evolução na descrição dos dados e uma empresa, sem que os sistemas ou aplicações tenham que ser alterados, ou seja, imunidade das aplicações às mudanças na estrutura de armazenagem e estratégias de acesso. Já a independência dos dados em relação à aplicação representa um avanço no sentido de tornar qualquer modificação das estruturas dos arquivos imperceptível para os programas. Desta forma, as mudanças na organização dos dados não geram qualquer necessidade de alteração dos programas que o manipulam. Por exemplo, a inclusão de um novo atributo em uma tabela é feita sem que sejam alterados os programas, pois nos programas não estão definidos as estruturas dos arquivos. (GEHRKE; RAMAKRISNAN, 2008) O autor ainda afirma que no caso do acesso eficiente a dados um SGBD utiliza varias técnicas sofisticadas para armazenar e recuperar dados de forma eficiente. Tal recurso é especialmente importante se os dados forem armazenados em dispositivos de armazenamento externos. Já a integridade e segurança de dados tratam do acesso aos dados através do SGBD que pode forçar as restrições de integridade, como por exemplo, antes de inserir uma informação sobre o salário de determinado funcionário, o SGBD pode verificar se o orçamento do departamento não está se excedendo. Também pode ser forçado o controle de acesso que governa os dados que estão visíveis a diferentes classes de usuários. (GEHRKE; RAMAKRISNAN, 2008) Em relação à administração de dados, quando vários usuários compartilham dados, fazer uma administração centralizada dos dados oferece melhorias significativas. A compreensão da natureza dos dados sendo gerenciados, e como os usuários os utilizam pode ser responsável por organizar a representação dos dados minimizando a redundância e realizando as sintonizações finas do armazenamento

19 18 dos dados para que se possa garantir uma eficiente recuperação. O autor afirma que o acesso concorrente e recuperação de falhas ocorrem quando um SGBD planeja o acesso concorrente aos dados de maneira que os usuários possam achar que os dados estão sendo acessados somente por um único usuário por vez. Além disso, o SGBD faz a proteção dos usuários em relação a falhas de sistema. Ainda segundo o autor o SGBD suporta funções importantes que são muito comuns em vários aplicativos que acessam os dados, isso em conjunto com uma interface de alto nível aos dados facilita o desenvolvimento rápido de aplicativos, ou seja, tempo reduzido de desenvolvimento de aplicativos. Os aplicativos do SGBD tendem a ser mais robustos que os aplicativos similares independentes já que muitas de suas tarefas importantes são tratadas pelo SGBD, sendo assim elas não precisam ser depuradas e testadas no aplicativo. Segundo o autor, existem todas essas vantagens na utilização de um SGBD, porém algumas vezes podem existir desvantagens. Por exemplo, um SGBD é um software complexo, otimizado para alguns tipos de processamento, tais como, responder a consultas complexas ou tratar várias requisições concorrentes, e o desempenho pode não responder de maneira adequada em determinadas situações. Alguns exemplos incluem aplicativos com restrições rígidas de tempo real ou então algumas operações críticas definidas para as quais os códigos customizados devem ser escritos. Também há uma razão para não se utilizar um SGBD, é o caso de um aplicativo que necessite de uma manipulação de dados de maneira que a linguagem de consulta utilizada não suporte. Nesses casos, a visualização abstrata dos dados apresentada pelo SGBD pode não corresponder as necessidades do aplicativo e realmente impossibilitar o seu funcionamento. O exemplo de banco de dados relacionais que não suportam a análise flexível de dados textuais, embora os fabricantes já estejam estendendo seus produtos nesta direção se encaixa perfeitamente nesta situação. (GEHRKE; RAMAKRISNAN, 2008) O autor ainda afirma que o desempenho especializado ou solicitações de manipulação de dados são essenciais nos aplicativos, então pode-se optar por não utilizar um SGBD, especialmente se os benefícios de um SGBD, como por exemplo, as consultas flexíveis, a segurança, o acesso concorrente e recuperação de falha não forem imprescindíveis. No entanto a maioria das situações em que o

20 19 gerenciamento de dados em grande escala se faz necessário, o uso dos SGBDs tem se tornado indispensável. 1.2 ARQUITERA ORACLE Segundo Carvalho (2011), o servidor Oracle é composto de duas entidades: a instância e o banco de dados, conforme ilustrado na figura 1.1. Figura 1.1: Arquitetura do Oracle. Fonte: Date, 2005, p A instância Oracle é composta de estruturas de memória e processos, sendo que sua existência é temporária, na memória RAM e nas CPU s, e quando a instância em execução é desligada, os seus vestígios são perdidos. Os processos que compõem esta instância são conhecidos como processos de segundo plano ou processos de background, já que estão presentes e em execução durante o tempo em que a instância estiver ativa. As estruturas de memória, implementadas em segmentos de memória compartilhados fornecidos pelo sistema operacional, são conhecidos como a área de sistema global ou System Global Area (SGA), essa área é alocada na inicialização da instância e liberada no desligamento.

21 20 As sessões de usuário compõem-se de processos de usuário que estão sendo executados localmente na máquina do usuário, conectados a um processo de servidor executando localmente na máquina do servidor. Carvalho (2011), afirma que o banco de dados é composto por arquivos físicos no disco. Esteja em execução ou parado, seus arquivos permanecem. Tais arquivos são os arquivos de dados, os arquivos de redo log e os arquivos de controle. 1.3 ARQUITETURA MYSQL Segundo Tahaghoghi; Williams, a arquitetura do MySQL é muito diferente da dos outros servidores de banco de dados e também é útil para uma grande variedade de objetivos. O SGBD MySQL é flexível o suficiente para trabalhar bem em ambientes muito exigentes, como aplicações web. Deste modo, o MySQL pode potencializar aplicações embutidas, depósitos de dados, indexação de conteúdo e software de distribuições, sistemas redundantes altamente disponíveis, On Line Transaction Processing (OLTP), entre outras. Quanto a arquitetura lógica do MySQL os autores afirmam que os componentes deste SGBD trabalham juntos, porém são divididos em camadas. A camada superior contém serviços que não são exclusivos deste, geralmente são serviços que a maioria das ferramentas cliente/servidor baseadas em redes ou servidores necessitam, são elas: gerenciamento de conexão; autenticação; segurança. A segunda camada é onde ficam situados o código de interpretação de consultas, análise, otimização, cache. É neste nível que ficam todos os tipos de funcionalidade oferecida através das ferramentas de armazenamento: procedimentos armazenados, triggers e visualizações, por exemplo. Já a terceira camada contém as ferramentas de armazenamento. Estas são responsáveis pelo armazenamento e recuperação de todos os dados no MySQL. Como os diversos sistemas de arquivo disponíveis para GNU/Linux, cada ferramenta de armazenamento possui seus próprios benefícios e desvantagens. O servidor é responsável por fazer a comunicação através da API da ferramenta de

22 21 armazenamento. A API pode conter várias funções de baixo nível que realizam operações como, por exemplo, o início de uma transação. As ferramentas de armazenamento não interpretam a linguagem SQL e também não se comunicam umas com as outras; elas simplesmente respondem às requisições do servidor. (TAHAGHOGHI; WILLIAMS, 2007) A arquitetura do SGBD MySQL está representada na figura 1.2. Figura 1.2: Arquitetura do MySQL. Fonte: MySQl Forge, 2012, p.1. No capítulo seguinte serão abordados os bancos de dados distribuídos para que se possa ter uma base de seu funcionamento.

23 22 2 BANCOS DE DADOS DISTRIBUÍDOS Devido à crescente utilização dos sistemas computacionais, temos uma alta demanda em automatização dos processos em geral e conseqüentemente há uma maior dependência dos bancos de dados, que também passam a receber novos tipos de dados, como som e imagens, exigindo maior poder de processamento e armazenamento. Com a fusão da tecnologia de bancos de dados e a de redes, surgiu a de banco de dados distribuídos, e esta foi utilizada para suprir às necessidades citadas acima. Pode-se definir um Banco de Dados Distribuído (BDD) como uma coleção de múltiplos bancos de dados logicamente inter-relacionados distribuídos por uma rede de computadores. (ELMASRI; NAVATHE, 2005, p.579). Os computadores que compõem a rede de um banco de dados distribuídos são chamados de site ou nó, e cada um é gerenciado por um sistema de gerenciamento de banco de dados executado independentemente dos outros sites. A visão clássica de um sistema de banco de dados distribuído é que o sistema deve tornar o impacto da distribuição dos dados transparente. (RAMAKRISHNAN; GEHRKE, 2008, P.613). Duas propriedades, quase sempre são requeridas a um BDD, são elas: independência dos dados distribuídos, ou seja, as consultas são feitas pelos usuários, sem que eles saibam onde as relações referenciadas estão armazenadas; e a atomicidade da transação, que trata do acesso e atualização de dados que se encontram e sites diferentes devem estar disponíveis aos usuários, como se estas estivessem locais. As atualizações de transações devem persistir quando efetivada e se cancelada não deve haver persistência, ou seja, os efeitos das transações devem ser atômicos. No caso de um sistema que utilize uma rede lenta essas propriedades nem sempre são desejáveis. A comunicação entre os computadores de um banco distribuído pode ser feita de diversas maneiras, sem o compartilhamento da memória principal ou discos, e esses computadores podem variar de tamanho e função como, por exemplo, podem conter estações de trabalho e até servidores e computadores de grande porte. A configuração de um BDD possui segundo Silberschatz; Korth; Sudarshan (1999) os seguintes aspectos: os sites são disponíveis entre si; um esquema global

24 23 comum é compartilhado entre os sites, mesmo que algumas relações estejam armazenadas em alguns sites; os ambientes para execuções de transações locais e globais são oferecidas por todos os sites. Na figura 2.1 é exemplificado um sistema distribuído. Figura 2.1- Um sistema distribuído. Fonte: Silberschatz; Korth; Sudarshan, 1999, p.558. Entre os mais variados motivos para a utilização de um banco de dados distribuído, podemos destacar: compartilhamento de dados, que caracteriza-se como principal vantagem de um banco de dados a criação de um ambiente onde um usuário de site pode acessar recursos instalados em outros sites; a autonomia local sobre os dados. O gerenciamento global é feito por um administrador geral que libera outros administradores locais; a disponibilidade, pois o fato de um site sair do ar, ou apresentar mau funcionamento não afeta o sistema como um todo, ainda mais se os dados estiverem replicados em diversos sites. Segundo o autor dentre algumas desvantagens em relação ao uso de um sistema de banco de dados distribuído, podemos destacar o aumento de complexidade para assegurar a coordenação entre os sites. Esse aumento se dá de diferentes modos: a implementação de sistemas banco de dados distribuídos é mais

25 24 difícil e por isso há um aumento no custo de desenvolvimento dos softwares; a precisão dos algoritmos pode ser afetada por se tratar de um sistema distribuído, ainda mais durante a ocorrência e recuperação de falhas. Isso abre portas para possíveis bugs; o aumento de processamento e troca de mensagens devido à coordenação entre sites acabam se tornando um overhead. Em relação aos tipos de redes que comportam um SBDD, existem as redes locais, ou Local-area networks (LAN) que são projetadas para cobrir uma pequena área geográfica como um edifício ou alguns prédios próximos; e as redes de longa distância, ou Wide-area networks (WAN) que abrangem áreas extensas, como um país ou até mesmo pode-se considerar, por exemplo, no caso da internet que a abrangência é mundial. Essa diferença interfere na variação de velocidade, confiabilidade e segurança das redes, e refletem no sistema operacional. 2.1 SISTEMA DE GERÊNCIA DE BANCO DE DADOS DISTRIBUÍDOS O autor afirma que o SGBDD é utilizado para facilitar a gerência de dados, e permite o armazenamento de um banco de dados que pode ser divido em todos os nós de uma rede de comunicação de dados, possibilitando ainda aos usuários uma visão única do banco. A criação de SGBDDs teve uma contribuição significativa do aumento da produtividade em desenvolvimento de aplicações. Tais sistemas reduzem a tarefa de se definir aplicações que requerem o compartilhamento de informação entre usuários, programas ou organizações onde os usuários da informação, ou mesmo as fontes de informação, estão geograficamente dispersos. As características das aplicações incluem, por exemplo: sistemas de controle de inventario; contabilidade ou pessoal de grandes empresas; sistemas de consulta a saldos bancários; sistemas voltados para cliente e bancos de dados censitários. (SILBERSCHATZ; KORTH; SUDARSHAN, 1999) Segundo o autor a ideia de SGBDDs torna-se interessante por vários pontos de vista, tais como: o administrativo, pois permite que o sistema, mesmo que geograficamente disperso, mantenha o controle de seus próprios dados, e a nível global oferece compartilhamento desses dados; o econômico, já que este sistema

26 25 pode diminuir os custos de comunicações, sendo que hoje em dia este tipo de custo é maior do que o próprio equipamento; o técnico, por facilitar o crescimento modular do sistema, aumenta a confiabilidade e aumenta a eficiência. Porém existe outro aspecto, já que não é difícil argumentar que sistemas com esta arquitetura levantam problemas de implementação sérios, têm um custo de desenvolvimento elevado, consomem recursos e podem ter um desempenho duvidoso. (SILBERSCHATZ; KORTH; SUDARSHAN, 1999) Arquitetura genérica para SGBDs Distribuídos Por uma visão geral, podemos dizer que SGBDs são como uma associação de SGBDs centralizados, autônomos, onde estes sãos chamados de SGBDs locais e são interligados por uma camada de software chamada de SGBD da rede ou SGBD global. Um SGBD local é um SGBD centralizado sendo este gerenciado de forma autônoma do banco de dados local, não podendo receber comandos de usuários locais ou da copia local do SGBD global que faz uso do sistema operacional local que garante as seguintes facilidades básicas: métodos de acessos; gerência de processos; gerência de memória. (SILBERSCHATZ; KORTH; SUDARSHAN, 1999) De acordo com Silberschatz; Korth; Sudarshan (1999), é esta coletividade dos bancos locais que constitui uma implementação do banco distribuído. Nela todos os problemas de comunicação de dados e distribuição de recursos são transparentes ao SGBD global, onde irá funcionar sob uma aplicação do sistema operacional da rede de comunicação de dados Tipos de Bancos de Dados Distribuídos O autor escreve que um sistema onde os dados são distribuídos e todos os servidores executam o mesmo software de SGBD é chamado de sistema de banco de dados distribuído homogêneo. E um sistema de banco de dados heterogêneo é

27 26 um sistema que utiliza diferentes SGBDs para controlar seus diversos sites. Os SGBDDs homogêneos aparecem com mais frequência quando a aplicação destinada não existia antes. Já os heterogêneos surgem quando há necessidade de integrar sistemas legados. A escolha entre uma arquitetura ou outra é influenciada pelo aproveitamento de hardware e software já existentes e pelo próprio hábito e grau de cooperação esperado dos usuários se houver necessidade de mudança para um sistema diferente Arquiteturas de SGBD Distribuído Silberschatz; Korth; Sudarshan (1999), afirma que existem três tipos de arquiteturas denominam as diferentes funcionalidades de um de um SGBDD, a cliente-servidor, servidor colaborador e a middleware. No sistema cliente-servidor, são admitidos um ou mais clientes, que se tornam responsáveis por questões da interface com o usuário; e um ou mais servidores, que gerenciam dados e executam transações. Qualquer cliente pode enviar, de um computador pessoal, uma consulta para qualquer servidor que a executa em um computador de grande porte. Porém esse sistema não permite que uma consulta acesse vários servidores. Nos sistemas servidor colaborador, são utilizados outros servidores, que executam cooperativamente, cada uma com seus dados locais, as transações para gerar respostas a subconsultas, os resultados são reunidos gerando a resposta da consulta original. Já nos sistemas de middleware, apenas um servidor gerencia consultas e transações que abranjam outros servidores, e assim os outros servidores ficam apenas com as operações locais. Pode-se considerar esse servidor especial como uma camada de software que coordena a execução de consultas e transações em um ou mais servidores de banco de dados independentes; tal software é freqüentemente chamado de middleware. (RAMAKRISHNAN; GEHRKE, 2008).

28 PROJETO LÓGICO DE BANCO DE DADOS DISTRIBUÍDOS De acordo com Elmasri; Navathe (2005) algumas técnicas são usadas durante o processo de projeto do BDD como a fragmentação que possibilita quebrar o banco de dados em unidades lógicas e armazená-las em vários sites e a replica e alocação de dados que permite que alguns dados sejam gravados em mais de um site Fragmentação de dados Ainda segundo os autores, para que a distribuição de dados de um banco seja feita devem ser tomadas algumas decisões referentes a qual site deveria ser usado para armazenar quais partes, e ainda, antes dessa decisão determinar as unidades lógicas do banco de dados que serão distribuídas. As unidades lógicas mais simples são as relações e cada relação inteira deve ser armazenada em um site em particular. Porém uma relação pode ser fragmentada em unidades lógicas menores para a distribuição. Há dois esquemas de fragmentação de uma relação. A fragmentação horizontal e a vertical. A horizontal divide a relação horizontalmente agrupando linhas para criar subconjuntos de tuplas, onde cada subconjunto possui um significado lógico, assim esses fragmentos podem ser designados a diferentes sites do sistema. (ELMASRI; NAVATHE, 2005) A fragmentação horizontal derivada aplica a partição de uma relação primária em outras relações secundarias que são relacionados à relação primaria por uma chave estrangeira. Desse modo, os dados relacionados entre as relações primária e secundária são fragmentados da mesma maneira. A fragmentação vertical divide uma relação verticalmente segundo colunas, mantendo apenas certos atributos de uma relação, sendo necessária a aplicação de uma chave primaria ou algum atributo que seja chave candidata em cada fragmento para que a relação completa possa ser reconstruída a partir desses.

29 28 Segundo os autores ainda há a fragmentação híbrida é quando se faz utilização da fragmentação horizontal e depois da vertical ou vice-versa Replicação e Alocação de dados De acordo com Elmasri; Navathe (2005) existem dois extremos quando se trata de replicação, um é a replicação total de um banco de dados que com certeza aumenta a disponibilidade dos dados, melhora o desempenho para consultas globais, porém pode reduzir drasticamente a velocidade das operações de atualizações de dados, e o outro é quando não há replicação alguma, ou seja, cada fragmento é armazenado em exatamente um site; temos a replicação parcial dos dados, o que significa que alguns fragmentos são replicados e outros não. O processo de alocação de dados que compreende na escolha do site a qual os fragmentos serão atribuídos e o grau de replicação depende dos objetivos de desempenho e de disponibilidade do sistema e dos tipos e das frequências das transações submetidas em cada site Banco de Dados Distribuídos X Banco de Dados Replicados Segundo Maron; Torquato; Silva (2008) em um banco de dados distribuídos puro (ou seja, não reproduzido), o sistema é capaz de gerar uma única cópia de todos os dados e suporta objetos de banco de dados. Normalmente, as aplicações de dados distribuídos utilizam transações distribuídas para realizar o acesso aos dados a nível local e remoto, e também modificar o banco de dados global em tempo real....o termo replicação refere-se à operação de cópia e manutenção de objetos de bancos de dados em múltiplos bancos de dados pertencentes a um sistema distribuído.( Maron; Torquato; Silva, 2008, p.3). Embora a replicação assente na tecnologia de dados distribuídos, banco de dados replicados vem oferecendo benefícios para aplicações que não são possíveis

30 29 dentro de um ambiente de banco de dados distribuídos puro. Segundo o autor é comum que a replicação de dados locais seja utilizada para melhorar o desempenho de banco de dados locais e proteger a disponibilidade de aplicações, já que existem opções alternativas de acesso aos dados. Dados um exemplo, caso uma aplicação possa acessar normalmente um banco de dados local ao invés de um servidor remoto para minimizar o tráfego de rede e assim obter o máximo de desempenho possível. Além disso, a aplicação poderá continuar funcionando até mesmo se ocorrer alguma falha no servidor local, já que outros servidores com dados replicados permanecem acessíveis. No próximo capítulo será realizada uma explanação sobre a replicação de dados que é o foco deste trabalho.

31 30 3 REPLICAÇÃO De acordo com Maron; Torquato; Silva (2008), replicação é o processo de cópia e manutenção de objetos de bancos de dados ou tabelas em vários bancos de dados que compõem um sistema de banco de dados distribuído. As mudanças aplicadas em um site são capturadas e armazenadas localmente para, posteriormente, serem aplicadas em cada banco de dados remoto. Se uma tabela for replicada, uma cópia da tabela é armazenada em dois ou mais sites. No caso mais extremo, temos a replicação total, na qual cada cópia é armazenada em todos os sites do sistema. Ainda segundo os autores, a replicação usa tecnologia de bancos de dados distribuídos para compartilhar dados entre vários sites, mas um banco de dados replicado e um banco de dados distribuído não são a mesma coisa. Em um banco de dados distribuído, o dado está acessível em diversos locais, mas uma tabela particular reside em uma só localização. O modelo de BDD replicado pode resolver diversos problemas, tais como: vários locais necessitam acessar a cópia de um mesmo dado, o que se torna muito comum com usuários remotos e localizações distantes; e a necessidade de se melhorar o desempenho local. É indicado para unir bancos de dados fisicamente separados; melhorando o tempo de resposta na busca e agregação de dados; distribuem o processamento através servidores múltiplos; escalona o acesso para leitura e divide as informações baseadas nas necessidades de cada unidade de uma determinada empresa. (MARON; TORQUATO; SILVA, 2011) Além disso, têm diversas vantagens, Tanenbaum; Steen (2007) citam algumas delas, tais como: aumento da disponibilidade dos dados, já que estes podem ser acessados em locais diferentes; aumento da confiabilidade, uma vez que os dados podem ser acessados mesmo quando houver indisponibilidade em determinado local; redução do tráfego de rede em horários de pico, pois a replicação pode ser programada para acontecer em horários com menor tráfego de dados; aumento do paralelismo, pois as informações podem ser acessadas no site que estiver mais próximo de onde a transação está sendo executada e assim minimizar o movimento de dados entre os diversos locais. Porém os autores ainda dizem que a replicação também tem algumas

32 31 desvantagens, tais como: a redundância nas operações, que torna necessário um tempo adicional para as operações de atualização das réplicas; o aumento da propagação de atualização de dados, já que para assegurar a consistência das informações, as atualizações devem ser propagadas em todos os locais onde estão contidas as suas réplicas; o espaço adicional para armazenamento e, em conseqüência, um maior espaço em memória, discos e unidades de backup; o aumento do custo de operação, uma vez que existe maior complexidade no tratamento da replicação e, em alguns casos, softwares licenciados serão necessários. A replicação é a chave para prover disponibilidade e tolerância a falhas em sistemas distribuídos. A disponibilidade tem crescente interesse principalmente com a tendência à computação móvel e, à operação desconectada. A tolerância a falhas é uma preocupação permanente dos serviços fornecidos em sistemas onde a segurança é critica e em outros tipos importantes de sistemas. (COULOURIS; DOLLIMORE; KINDBERG, 2007) Os motivos para utilizar a replicação são: a melhora no desempenho, pois assim os dados são colocados em cache em clientes e servidores é uma forma conhecida de melhorar o desempenho, navegadores e servidores de proxy colocam na memória cache cópias de recursos web evitando assim a latência da busca desses recursos no servidor de origem, além disso, às vezes os dados são replicados de forma transparente entre vários servidores de origem no mesmo domínio; e a maior disponibilidade, pois os usuários exigem que os serviços sejam de alta disponibilidade, isto é, a proporção do tempo durante a qual o serviço está acessível com tempo de resposta razoável deve ser próxima a 100%. Fora os atrasos decorrentes dos conflitos do controle de concorrência pessimista, os fatores relevantes para a alta disponibilidade são falhas no servidor e/ou particionamento da rede e operação desconectada. 3.1 TÉCNICAS DE REPLICAÇÃO As técnicas de replicação segundo Tanenbaum; Steen (2007) podem ser apresentadas da seguinte forma: a replicação passiva, onde os front ends somente

33 32 se comunicam com o gerenciador de réplica primário para obterem o serviço. O gerenciador de réplica primário executa as operações e envia cópias dos dados atualizados para os backups. Se o primário falhar, um dos backups será promovido para atuar como primário, conforme exemplificado na figura 3.1. Figura 3.1: Replicação Passiva Santos; Curvello; Goulart; Rossales; Cunha, 2010, p. 03. Na replicação ativa, em relação à tolerância a falhas os gerenciadores de réplica são máquinas de estado capazes de desempenhar papéis equivalentes e são organizados com um grupo. Neste caso, os front ends enviam as requisições como multicast para o grupo de gerenciadores de réplica, então todos os gerenciadores de réplica irão processar a requisição independentemente, porém isto é feito de forma idêntica, e respondem. Caso qualquer gerenciador de réplica falhe, isso não terá nenhum impacto no desempenho do serviço, já que os gerenciadores de réplica que restam continuaram a responder normalmente, conforme é ilustrado na figura 3.2. (TANENBAUM; STEEN, 2007) Figura 3.2: Replicação ativa. Santos; Curvello; Goulart; Rossales; Cunha, 2010, p. 04.

34 MODELO DE REPLICAÇÃO Segundo Baracho (2011) além da técnica de replicação, outro ponto importante na replicação de dados é o modelo adotado. Existem dois modelos básicos de replicação, a replicação síncrona e a assíncrona. Na replicação síncrona, a replicação de dados é feita no mesmo momento em que determinada cópia é alterada. Neste caso, todas as cópias ou replicações de dados serão feitas no instante em que for realizada a sincronização e consistência. Se alguma cópia do banco for alterada, essa mudança será imediatamente aplicada a todos os outros bancos dentro da transação. Os servidores replicados usam estratégias sincronizadas e protocolos especializados de réplica para manter os conjuntos de dados replicados coerentes. Nesse modelo de replicação, há uma demanda de conexão constante e também uma eventual intermitência do meio de comunicação. Este tipo de replicação não tolera atrasos na propagação das atualizações. (BARACHO, 2011) Segundo o autor, na replicação assíncrona, somente a réplica que for alterada é tratada em tempo real; a cópia destes dados fica fora de sincronia entre os bancos de dados. Se uma base de dados for modificada, a alteração será propagada e aplicada para outra base de dados em um segundo passo, ou seja, em uma transação separada, sendo que esta poderá ocorrer alguns segundos, minutos, horas ou até mesmo dias depois da primeira. A cópia pode ficar fora de sincronia temporariamente, provocada pela interrupção de comunicação entre as réplicas, porém quando a sincronização for realizada, os dados a serem atualizados irão convergir para todos os locais que foram especificados. 3.3 MÉTODOS DE REPLICAÇÃO Baracho (2011), explica que em sistemas de bancos de dados, as replicações requerem métodos para realizar as alterações feitas em dados replicados. Destes métodos, dois são mais utilizados, são eles: arquivo de registro e gatilhos transacionais.

35 34 O autor ainda afirma que no caso da utilização de arquivo de registro, cada transação, tais como insert, update e delete feita no banco de dados irá criar uma entrada na tabela de log. Em um tempo determinado, essa entrada será processada e então a transação será propagada para todas as cópias do dado alterado. Já os gatilhos transacionais, permitem que os usuários do banco de dados possam criar suas próprias regras no que diz respeito ao tratamento de dados replicados. Esses gatilhos podem ser disparados de acordo com os eventos que forem determinados. (BARACHO, 2011) Os arquivos de log e gatilhos podem ser usados individual ou conjuntamente em um SGBD, dependendo das características de cada sistema e de suas aplicações. Um ponto favorável ao uso de gatilhos para a realização de replicação de dados é que esse esquema demanda menos tempo e consome menos recursos do que arquivos de log. (BARACHO, 2011) Ainda de acordo com Baracho (2011), a replicação de dados baseada em log demandaria que, em determinados intervalos de tempo, seria gravado um arquivo com todas as alterações realizadas e, posteriormente, este seria processado em cada um dos sites envolvidos na replicação. Por meio da utilização de gatilhos e procedimentos, um mesmo processo poderá ser realizado de maneira mais rápida e com um consumo menor de recursos, uma alteração em uma réplica implica na execução de procedimentos responsáveis por enviar aos demais sites às atualizações feitas naquela época, e esperar por uma resposta afirmativa ou negativa de cada um dos sites em relação à efetivação da modificação em suas réplicas locais. 3.4 CONFLITOS DE REPLICAÇÃO Em se tratando de ambientes de replicação deve-se sempre criar um ambiente que seja capaz de evitar a possibilidade de conflitos. O autor afirma que se algumas técnicas forem utilizadas isto se torna possível, porém não em sua totalidade, mas sim de maneira que se permita um ambiente acessível. Alguns tipos de conflitos podem ocorrer de acordo com a replicação utilizada, estes conflitos são: update, delete e chaves únicas e sequenciais. (BARACHO, 2011)

36 35 O conflito relacionado ao Update, ocorre quando se usa a replicação ativa, pois somente nela se consegue fazer alterações. Este pode ocorrer quando duas transações, oriundas de bancos diferentes, atualizem a mesma linha no mesmo instante. Este tipo de conflito poder ser evitado, a partir do pensamento de que quanto menor for o tempo de atualização da réplica, ou seja, houver um menor intervalo de atualização, menor será a chance de ocorrer conflitos de atualização. O autor segue afirmando que o conflito de Delete é muito parecido com o conflito de update. Por exemplo, se duas bases A e B deletarem a mesma linha no mesmo momento, quando houver a sincronização das bases então o conflito surgirá, pois haverá uma tentativa de apagar uma linha que já não existe. Baracho (2011) afirma que o conflito de chaves únicas e seqüenciais, ocorre quando a replicação de uma linha viola a integridade de uma tabela Primary Key ou Unique Key. Quando duas transações provenientes de lugares diferentes tentarem inserir um registro em uma mesma tabela (réplica) utilizando o mesmo valor para Primary Key. 3.5 REPLICAÇÃO UTILIZADA NO ORACLE Segundo a documentação oficial da Oracle, a replicação funciona através de arquivo de registro da seguinte maneira: um processo de captura irá armazenar eventos do banco de dados, como por exemplo, alterações feitas em tabelas, esquemas, ou um banco de dados inteiro. As alterações registradas no arquivo de redo log são armazenadas em um registro chamado Logical Change Record (LCR). As regras usadas neste processo de captura são chamadas de mensagens capturadas. O banco de dados onde as mudanças são feitas no redo log é chamado de banco de dados fonte Visão materializada A replicação no Oracle é realizada criando uma visão materializada de uma

37 36 tabela. Essa visão é materializada, já que consiste em uma cópia completa ou parcial de uma tabela, armazenando-a em outro site. Existe também a configuração de somente leitura, que é uma configuração básica, onde uma visão materializada fornece acesso somente leitura para os dados da tabela que foram originados na tabela original (master). As alterações feitas na tabela master são refletidas nas tabelas que foram replicadas assim que for requisitada uma atualização dessas tabelas. Como o acesso pelas tabelas refletidas é de somente leitura, fica eliminada a possibilidade de conflitos, já que não é possível atualizá-las. Outro tipo de configuração é a atualizável, onde é necessária configuração mais avançada, que torna possível criar uma visão materializada atualizável que permite ao usuário inserir, atualizar e deletar linhas de uma tabela master executando essas operações na visão materializada. Essa visão é similar à somente leitura exceto pelo fato de poder haver modificações e enviá-las à tabela master. No capítulo a seguir será apresentada a ferramenta de replicação ObjectMMRS, que será utilizada na implementação do estudo de caso realizado neste trabalho.

38 37 4 ESTUDO DE CASO Este trabalho foi realizado a fim de exemplificar a replicação de um banco de dados de uma empresa que faz envio de mala direta a clientes, com informações sobre diferentes coisas. Este é um trabalho ilustrativo de uma situação real. Para a realização deste trabalho foram utilizados dois SGBDs, escolhidos pela facilidade de acesso e conhecimento na sua utilização, são eles: o Oracle 10g e o MySQL 5.5. O trabalho foi realizado em máquinas virtuais, pois assim evita-se o uso de mais máquinas físicas. O sistema operacional instalado nas máquinas foi o WindowsXP, pois o Centro Paula Sousa oferece um programa em parceria com Microsoft o Microsoft Developer Network Academic Alliance (MSDNAA) que visa a possibilidade de acesso a softwares de maneira gratuita. A solução para que todas as filiais desta empresa possam ter acesso aos dados de clientes é a criação de um mecanismo de replicação, pois assim a cada nova inserção de cliente na matriz, esta será replicada para todas as filiais da empresa. Porém como se trata de um teste, a situação ilustra um link unidirecional, onde será feito a ligação entre matriz e filial, porém somente a matriz é capaz de enviar réplicas. De acordo com os estudos realizados, atualmente existem vários softwares de replicação que poderiam ser utilizados neste caso, porém optou-se pela utilização da ferramenta ObjectMMRS. Antes da escolha por esta ferramenta, foi realizada uma verificação nos replicadores nativos dos SGBDs, porém estes foram descartados por falta de interoperabilidade entre os bancos de dados utilizados. Para realizar o envio de informações entre os bancos de dados, o software de replicação utiliza-se de tabelas de dicionário de dados do replicador, que são criadas no banco de dados. Tais informações são armazenadas de maneira temporária nestas tabelas e logo após a efetivação da transferência destes registros são descartadas. A ferramenta de replicação será responsável por replicar toda e qualquer informação manipulada nos bancos de dados Oracle e MySQL. A criação de replicação de banco de dados será realizada segundo o ambiente oferecido pela utilização das máquinas virtuais.

39 OBJECTMMRS O ObjectMMRS é um software de replicação que utiliza modelos de replicação assíncrona, entrega e captura de dados através de log ou gatilhos suporte a bancos de dados heterogêneos tais como: DB2, Oracle, Postgresql, SQL Server, Firebird, MySQL, Apache Derby, HSQLDB e SQLite. É um replicador assíncrono e bi-direcional de bases de dados, simples, pois não utiliza recursos específicos do SGBD, como leitura de logs de transações, entre outros. A ferramenta coleta informações de colunas e linhas alteradas por meio de uma trigger gerada pelo replicador para cada tabela a ser replicada, reduzindo assim problemas de uso excessivo de rede e minimizando problemas de concorrência na atualização dos dados. Esta trigger pode ser editada pelo usuário conforme suas necessidades. As informações coletadas pela trigger são armazenadas em tabelas chamadas de filas de operações a replicar, e um processo consome esta fila a cada N segundos enviando dados para os servidores. Segundo o site da Object Sistemas, no caso, de falha na rede ou indisponibilidade do servidor remoto a fila de operações a replicar é mantida, garantindo a entrega quando a rede ou o servidor remoto se restabelecerem. Após um número de tentativas, que também pode ser configurado, o processo pode opcionalmente enviar s de alertas aos responsáveis. Além deste foco na descentralização, o produto também pode ser usado em diversas outras situações tais como: backups em tempo real de banco de dados; eliminação de rotinas de atualização de dados em batch; comunicação de dados entre bancos de dados de diferentes fabricantes; importação de dados a partir de arquivos texto, planilhas, etc. E uma das principais características e vantagens é de que se trata de uma tecnologia nacional, com possibilidade de customizações. Além de possuir desenvolvimento e suporte técnico locais, tornando-se mais acessível. 4.2 CRIAÇÃO DO PROCESSO DE REPLICAÇÃO

40 39 Para instalação do replicador ObjectMMRS, é necessário a preparação do servidor da base de dados master a ser replicada, configurando o alias de rede do slave no arquivo C:Windows\System32\Drivers\Etc\Hosts, conforme a figura 4.1 e instalando a máquina virtual JVM da Sun 1.7. Figura 4.1: Configuração do alias de rede. Fonte: Elaborado pelas autoras. Após a instalação devem ser criados no mínimo dois usuários no SGBD Oracle 10g: o objectmmrs, que será dono das tabelas de dicionário de dados do replicador, e o master, que será o proprietário das tabelas a serem replicadas. No servidor MySQL deverá ser no mínimo um usuário pra o qual será enviado a replicação dos dados. O script or_master_squema.sql encontrado no diretório: \objectmmrs\sql\oracle deve ser executado pelo usuário objectmmrs para que seja feita a criação do dicionário de dados, onde serão armazenados todas as informações referentes a replicação. Segundo o manual de instalação da ferramenta, o usuário objectmmrs precisa ter direito de criar objetos no seu próprio esquema, e também precisa ter privilégios de SELECT, INSERT, UPDATE, DELETE e de CREATE TRIGGER em todas as tabelas que serão replicadas. O usuário master precisa dos privilégios apenas de SELECT, INSERT, UPDATE e DELETE nas tabelas replicadas e também de

41 40 SELECT nas tabelas do dicionário de dados do replicador e direito de uso (SELECT/ALTER) na sequence or_seq_transaction_id. No arquivo objectdb.proprerties, localizado na pasta da instalação do replicador, devem ser configurados os aliases master e slave de conexão com o banco de dados, exemplificado na figura 4.2. Figura 4.2: Arquivo objectdb.properties. Fonte: Elaborado pelas autoras. O arquivo publicar.bat, ilustrado na figura 4.3, é encontrado no mesmo diretório, deve ser editado, cadastrando-se as tabelas que serão replicadas, e depois executado. Essa execução gera o arquivo publicar.sql contendo o script de criação das triggers utilizadas para capturar os dados, armazená-los em tabelas temporárias e replicá-los para o servidor cadastrado. Esse script deve ser executado pelo usuário

42 41 objectmmrs. Figura 4.3: Arquivo publicar.bat. Fonte: Elaborado pelas autoras. O servidor escravo deve ser cadastrado na tabela or_tb_client do usuário objectmmrs conforme a figura 4.4, e depois devem ser cadastradas as tabelas que este servidor utilizará para receber os dados, e as operações Data Manipulation Language (DML) que serão realizadas de acordo com a figura 4.5. Figura 4.4 Configuração do slave de uma base máster. Fonte: Elaborado pelas autoras. Figura 4.5: Operações DML. Fonte: Elaborado pelas autoras. Com os cadastros devidamente realizados, o arquivo contest.bat deve ser executado para que se possa fazer o teste de conexão entre as bases de dados master e slave, conforme exemplificado na figura 4.6.

43 42 Figura 4.6: Teste de conexão. Fonte: Elaborado pelas autoras. Após as configurações no arquivo contest.bat, exemplificado na figura 4.6, torna-se necessário iniciar o serviço de replicação através da execução do arquivo run.bat localizado no diretório padrão da instalação do replicador, exemplificado pela figura 4.7. Figura 4.7: Arquivo run.bat. Fonte: Elaborado pelas autoras.

44 43 Na figura 4.8 é apresentada a arqutetura de replicação após instalada e configura a ferramenta ObejctMMRS, onde as alterações realizadas na matriz serão replicadas para a filial, num processo unidirecional e de forma assíncrona. Figura 4.8: Arquitetura de Replicação Fonte: Elaborado pelas autoras. 4.3 TESTES DE REPLICAÇÃO Neste trabalho foram realizados testes de replicação, visando mostrar a validação do processo de replicação de dados. Sendo que estes testes mostram se está havendo a comunicação adequada entre todos os sites, para isso serão a realizadas algumas operações de Insert, Update e Delete no servidor master e, assim poderá ser avaliada se a replicação está ocorrendo de maneira correta aos demais sites. O processo de replicação será exemplificado através de figuras. Na figura 4.9 é ilustrada uma operação de Insert realizada no SGBD Oracle.

45 44 Figura 4.9: Operações de Insert no SGBD Oracle. Fonte: Elaborada pelos autores. Na figura 4.10 é exemplificada a operação de Select no SGBD MySQL. Figura 4.10: Operação Select no SBGD MySQL. Fonte: Elaborada pelos autores. Existe também a operação de Update que realiza a atualização dos dados, caso haja uma alteração de registros no servidor. Conforme ilustrado na figura 4.11

46 45 é realizada a operação de Update no SGBD Oracle. Figura 4.11: Operações de Update no SGBD Oracle. Fonte: Elaborada pelos autores. Na figura 4.12 é exemplificada a operação de Select no SGBD MySQL. Figura 4.12: Operações de Select no SGBD MySQL. Fonte: Elaborada pelos autores.

47 46 E por fim existem as operações de Delete, que são responsáveis por apagar registros no banco. Todas as operações executadas devem ser propagadas gerando suas réplicas. A operação de Delete no SGBD Oracle pode ser visualizada na figura E a seguir na figura 4.14 é ilustrada a operação de Select no SGBD MySQL. Figura 4.13: Operações de Delete no SGBD Oracle. Fonte: Elaborada pelos autores. Figura 4.14: Operações de Select no SGBD MySQL. Fonte: Elaborada pelos autores.