155

Departamento de Computao Trabalho de Concluso de Curso
ERIC TERUO SHIBAYAMA
Estudo Comparativo entre Bancos de Dados Distribudos
Londrina 2004
Trabalho de concluso de curso obrigatrio desenvolvido durante o 4o ano do Curso de Graduao em Cincia da Computao como requisito parcial obteno do ttulo de Bacharel. Orientador: Prof. Ms. Daniel dos Santos Kaster
2004
COMISSO EXAMINADORA
____________________________________ Prof. Ms. Daniel dos Santos Kaster Universidade Estadual de Londrina
____________________________________ Prof. Ms. Evandro Bacarin Universidade Estadual de Londrina
____________________________________ Prof. Ms. Rodolfo Miranda de Barros Universidade Estadual de Londrina
Londrina, ___ de ___________ de 200_
DEDICATRIA
A Deus, a toda minha famlia e a minha namorada.
AGRADECIMENTO
Ao Prof. Ms. Daniel dos Santos Kaster, que me orientou durante todas as fases deste trabalho. Aos meus amigos e professores, que sempre estavam dispostos a ajudar. Ao meu pai, minha me, meu tio Lauro e minha tia Isaura, que juntos fizeram com que eu conclusse esta importante etapa de minha vida. A minha namorada que sempre me apoiou e me motivou em todos momentos.
RESUMO
Com as novas descobertas tecnolgicas para comunicao de dados, j possvel se trabalhar com bancos de dados no mais centralizados em um nico servidor, mas distribudos em diversos servidores, que podem estar localizados em uma rede local ou em pontos diferentes do planeta, compartilhando informaes de forma transparente aos usurios. Este trabalho tem por objetivo descrever as principais caractersticas dos bancos de dados distribudos (BDD), apresentando os requisitos de um Sistema de Gerncia de Bancos de Dados Distribudos (SGBDD) e fazer um estudo comparativo entre dois dos principais SGBDDs disponveis: o Oracle9i Enterprise Edition e o Microsoft SQL Server 2000, cujo objetivo consiste em observar as principais caractersticas dos bancos de dados distribudos e analisar as funcionalidades dos SGBDDs estudados.
Palavras-chave: Banco de dados, distribudos, Oracle, SQL Server.
ABSTRACT
With the new technologies for data communication, it is possible to work with databases not centered in a server, but distributed in some servers, that can be located at the same network, as well as at different countries, sharing information in a transparent way for the users. This work has the objective of describing the main characteristics of the distributed databases (DDB), it will be showing the requisites of a Database Manager System (DBMS) and doing a comparative study between two of the main available DDBMSs: the Oracle9i Enterprise Edition and The Microsoft SQL Server 2000 whose objective consists of observing the main characteristics of the distributed databases and analysing the functionalities of the studied DDBMSs.
Keywords: Database, Distributed, Oracle, SQL Server.
SUMRIO
1 2
INTRODUO ..............................................................................................................11 BANCO DE DADOS DISTRIBUIDOS ........................................................................12 2.1 INTRODUO ............................................................................................................. 12 2.2 CONCEITOS ................................................................................................................ 13 2.2.1 Vantagens dos Bancos de Dados Distribudos................................................. 14 2.2.1.1 Independncia de dados................................................................................ 14 2.2.1.2 Confiabilidade em transaes distribudas ...................................................15 2.2.1.3 Desempenho otimizado ................................................................................15 2.2.1.4 Expanso de sistema mais fcil .................................................................... 16 2.3 TRANSPARNCIA DE DADOS ....................................................................................... 16 2.3.1 Transparncia de rede...................................................................................... 16 2.3.2 Transparncia de replicao............................................................................ 17 2.3.3 Transparncia de fragmentao....................................................................... 17 2.4 ARQUITETURA DE UM BANCO DE DADOS DISTRIBUDO............................................... 17 2.5 ESTRATGIAS DE DISTRIBUIO DE DADOS .............................................................. 20 2.5.1 Replicao de Dados ........................................................................................ 20 2.5.2 Fragmentao de Dados .................................................................................. 20 2.5.2.1 Tipos de Fragmentao................................................................................. 21 2.6 PROPAGAO DE ATUALIZAES .............................................................................. 23 2.7 PROCESSAMENTO DE CONSULTAS ............................................................................. 23 2.7.1 Processadores de consultas.............................................................................. 23 2.7.2 Camadas de processamento de consulta .......................................................... 26 2.7.2.1 Localizao de dados.................................................................................... 26 2.7.2.2 Otimizao de consultas globais .................................................................. 26 2.7.2.3 Otimizao de consultas locais..................................................................... 26 2.7.2.4 Otimizao de consultas distribudas ........................................................... 27 2.8 PROCESSAMENTO DE TRANSAES ........................................................................... 28 2.8.1 Protocolo Two-fase commit (2PC) ...................................................................29 2.9 CONTROLE DISTRIBUDO DE CONCORRNCIA ............................................................ 30
BANCO DE DADOS TESTADOS................................................................................32 3.1 INTRODUO ............................................................................................................. 32 3.2 TIPOS DE REPLICAO............................................................................................... 32 3.2.1 Tipos de replicao do Oracle ......................................................................... 32 3.2.1.1 Replicao de View materializada somente para leitura ..............................33 3.2.1.2 Replicao de view materializada atualizvel .............................................. 34 3.2.1.3 Replicao Multimestre................................................................................35 3.2.1.4 Replicao Hbrida ....................................................................................... 35 3.2.2 Tipos de replicao do SQL Server.................................................................. 36 3.2.2.1 Replicao Snapshots ................................................................................... 38 3.2.2.2 Replicao Transacional............................................................................... 38 3.2.2.3 Replicao Merge ......................................................................................... 39 3.3 TRANSPARNCIA DE DADOS ....................................................................................... 39 3.3.1 Transparncias no Oracle ................................................................................ 40 3.3.1.1 Transparncia de Nome ................................................................................ 40
3.3.1.2 Transparncia de Replicao ........................................................................ 40 3.3.2 Transparncias no SQL Server ........................................................................ 41 3.3.2.1 Transparncia de nome................................................................................. 41 3.3.2.2 Transparncia de Replicao ........................................................................ 41 3.4 ARQUITETURA ........................................................................................................... 41 3.4.1 Conexo entre servidores Oracle ..................................................................... 41 3.4.2 Conexo entre servidores SQL Server ............................................................. 42 3.5 ESTRATGIAS DE DISTRIBUIO DE DADOS ............................................................... 43 3.5.1 Replicao de dados......................................................................................... 43 3.5.2 Fragmentao de dados ................................................................................... 43 3.5.2.1 Fragmentao de dados no Oracle................................................................43 3.5.2.2 Fragmentao de dados no SQL Server ....................................................... 44 3.6 PROPAGAO DE ATUALIZAES .............................................................................. 45 3.6.1 Propagao de atualizaes no Oracle ........................................................... 45 3.6.2 Propagao de atualizaes no SQL Server .................................................... 47 3.7 PROCESSAMENTO DE CONSULTAS DISTRIBUDAS ....................................................... 48 3.7.1 Processamento de Consultas Distribudas no Oracle...................................... 48 3.7.2 Processamento de Consultas Distribudas no SQL Server .............................. 51 3.8 PROCESSAMENTO DISTRIBUDO DE TRANSAES ...................................................... 54 3.8.1 Processamento Distribudo de Transao no Oracle ...................................... 54 3.8.2 Processamento Distribudo de Transao no SQL Server............................... 55 3.9 CONTROLE DE CONCORRNCIA ................................................................................. 56 3.9.1 Controle de Concorrncia no Oracle............................................................... 56 3.9.1.1 Controle de Concorrncia no SQL Server.................................................... 57 3.10 RESOLUO DE CONFLITOS ....................................................................................... 57 3.10.1 Resoluo de conflitos no Oracle..................................................................... 57 3.10.2 Resoluo de Conflitos no SQL Server ............................................................ 60 4 CONCLUSO................................................................................................................. 61 4.1 RESULTADOS DO ESTUDO COMPARATIVO .................................................................. 61
REFERNCIAS ..................................................................................................................... 63
LISTA DE FIGURAS
Figura 1: Banco de dados e redes de computadores................................................................. 12 Figura 2: Esquema de um BD centralizado(esq.) e de um BD distribudo(dir.) ......................14 Figura 3: Arquitetura de banco de dados distribudo ...............................................................18 Figura 4: Componentes de um SGBDD Distribudo ................................................................ 19 Figura 5: Relao inteira(PROJ) e uma relao fragmentada horizontalmente(PROJ1) .........21 Figura 6: Relao inteira(PROJ) e uma relao fragmentada verticalmente(PROJ2).............. 22 Figura 7: Relao inteira (PROJ) e uma relao fragmentada (PROJ3) ..................................22 Figura 8: Tabela FUNC (dir) e PAG(esq) ................................................................................ 25 Figura 9: Resultado da juno(dir) e da semijuno(esq) ........................................................26 Figura 10: Cost-Based Optimization ........................................................................................50
LISTA DE ABREVIATURAS E SIGLAS
BDD SGBDD EIL ECG ECL EE D/DG D/DL ACID MS DTC
Banco de Dados Distribudos Sistema de Gerenciamento de Banco de Dados Distribudos Esquema Interno Local Esquema Conceitual Global Esquema Conceitual Local Esquema Externo Dicionrio/Diretrio Global Dicionrio/Diretrio Local Atomicidade, Consistncia, Isolamento e Durabilidade Microsoft Distributed Transaction Coordinator
11
INTRODUO Um banco de dados um sistema de armazenamento de dados, ou seja, um
conjunto de arquivos de dados computadorizados que oferece diversos recursos ao usurio, possibilitando-lhe a realizao de operaes, tais como, a incluso de novos arquivos ao banco de dados, a insero de novos dados nos arquivos existentes, a recuperao, atualizao e eliminao de dados dos arquivos existentes. Normalmente esses conjuntos de dados se encontram armazenados de forma centralizada em apenas um local. Com o crescente aumento dos dados a serem armazenado, o gerenciamento centralizado desses dados pode se tornar uma tarefa muito trabalhosa, assim, possvel distribuir os dados em vrios pontos de forma a facilitar as atividades administrativas, permitindo que cada ponto mantenha controle sobre seus prprios dados, alm de oferecer um compartilhamento global no uso destes por outros pontos. Assim, podemos definir um Sistema de banco de dados distribudos como uma coleo de ns, cada um mantendo localmente um banco de dados, que esto interligados logicamente atravs de uma rede de computador, permitindo o acesso aos dados de maneira transparente. O presente trabalho tem como objetivo descrever as caractersticas e o funcionamento de um banco de dados distribudos, as funcionalidades de um SGBDD, alm de fazer um estudo comparativo entre dois dos principais SGBDDs disponveis: o Oracle9i Entreprise Edition e o Microsoft SQL Server 2000. Para fazer um estudo comparativo entre os SGBDDs escolhidos, sero analisadas as funcionalidade e caractersticas de cada um, entre os temas abordados esto: tipos replicaes de dados, nveis de transparncias, processamentos de consultas e transaes distribudas, resoluo de conflitos e controle distribudo de concorrncia. No captulo 2 ser feita uma introduo aos Bancos de dados Distribudos, em que sero apresentadas as suas vantagens, a arquitetura de um BDD, a forma como os dados podem ser distribudos, como so feitos o processamento de consultas e transaes distribudas e o controle distribudo de concorrncia. No captulo 3 ser apresentado um estudo sobre os dois SGBDDs utilizados neste trabalho: o Oracle9i Entreprise Edition e o Microsoft SQL Server 2000, em que o foco principal deste estudo foi em relao as principais caractersticas de um BDD apresentadas no captulo 1. No captulo 4 feita uma concluso sobre os BDDs e os SGBDDs estudados.
12
2 2.1
BANCO DE DADOS DISTRIBUIDOS

INTRODUO
Enquanto os primeiros banco de dados tomaram o rumo da centralizao e resultaram em gigantescos bancos de dados nos anos 70 e incio dos anos 80, a tendncia se reverteu em direo a uma maior descentralizao no final dos anos 80. As organizaes tm se mostrado muito interessadas na descentralizao do processamento (nvel do sistema) ao mesmo tempo em que obtm uma integrao dos recursos de informao (no nvel lgico) dentro de seus sistemas geograficamente distribudos de banco de dados, aplicaes e usurios [ELM, 2002]. A tecnologia de Banco de Dados Distribudos(BDDs) surgiu como uma intercalao de duas tecnologias:tecnologia de banco de dados e tecnologia de comunicao de dados e de rede [MATT,1998].
Figura 1: Banco de dados e redes de computadores
Com as novas tecnologias de comunicao de dados, alm da necessidade da descentralizao, possvel se trabalhar com bancos de dados no mais centralizados em um servidor, mas sim distribudos em vrios servidores, que podem estar na mesma rede, assim como podem estar em pases diferentes, compartilhando informaes de uma maneira transparente para os usurios [MOURA,1995]. Um dos motivos para distribuir um banco de dados que, um banco de dados distribudo alm de ser mais confivel, tem a capacidade de resolver da melhor maneira os grandes e complexos problemas com que nos defrontamos hoje, usando uma variao da regra de dividir e conquistar, ou seja, problemas complicados podem ser resolvidos simplesmente dividindo-os em fragmentos menores e atribuindo-os a grupos de software distintos, que fun-
13
cionem em computadores diferentes e produzam um sistema que atue sobre vrios elementos de processamento, mas que possam colaborar de forma eficaz para a execuo de uma tarefa em comum.
2.2
CONCEITOS
Os bancos de dados distribudos mostram as vantagens da computao distribuda sob domnio da gerncia de banco de dados. Um sistema de computao distribudo consiste em uma srie de elementos de processamento que so interligados por um sistema de rede de computadores e que cooperam na realizao de determinadas tarefas especficas. Como objetivo geral, sistemas de computao distribudos repartem um grande e ingerencivel problema em partes menores e resolvem o mesmo de maneira eficiente e coordenada [ELM,2002]. Em um sistema de banco de dados distribudos, o banco de dados armazenado em diversos computadores que se comunicam uns com os outros atravs de vrios meios de comunicao, tais como redes de alta velocidade ou linhas de telefone, em que cada qual pode participar na execuo de transaes que acessam dados em um ou diversos ns. A diferena principal entre sistemas de bancos de dados centralizados e distribudos que no primeiro os dados esto localizados em um nico lugar, enquanto no ltimo os dados residem em diversos locais [COU,1984]. Podemos definir banco de dados distribudos (BDD) como uma coleo de vrios bancos de dados logicamente inter-relacionados (integrao lgica significa que qualquer n tem acesso potencial a todo o banco de dados), distribudos ao longo de um sistema de redes de computadores e sistema de gerncia de banco de dados distribudos (SGBDD) como um sistema de software que permite o gerenciamento de um banco de dados distribudo e que torna a distribuio transparente ao usurio [ZSU,1999].
14
Figura 2: Esquema de um BD centralizado(esq.) e de um BD distribudo(dir.)
2.2.1 Vantagens dos Bancos de Dados Distribudos A gerncia de banco de dados distribudos foi proposta por vrios motivos, abrangendo desde a descentralizao organizacional e o processamento econmico at uma maior autonomia. Todas essas razes podem ser resumidas em quatro princpios fundamentais que tambm podem ser vistos como promessas da tecnologia SBDDs.
2.2.1.1 Independncia de dados Independncia de dados que tambm importante dentro do contexto dos SGBD centralizado, se refere imunidade de aplicativos dos usurios a mudanas na definio e na organizao de dados, e vice-versa. Pode-se dividir a independncia de dados em dois tipos: a independncia de dados lgica e a independncia de dados fsica. A independncia de dados lgica se refere imunidade de aplicativos de usurios a mudanas na estrutura lgica do banco de dados, ou seja, se um aplicativo de usurio atua sobre um subconjunto dos atributos de uma relao, ele no deve ser afetado quando novos atributos forem adicionados. A independncia de dados fsica lida com a ocultao dos detalhes da estrutura de armazenamento em relao aos aplicativos do usurio, ou seja, quando um aplicativo escrito, ele no deve se preocupar com os detalhes da organizao fsica dos dados [ZSU,199].
15
importante assinalar que a transparncia completa no um objetivo universalmente aceito. Gray argumenta que a transparncia completa torna o gerenciamento de dados muito difcil e afirma que aplicativos codificados com acesso transparente a banco de dados distribudos geograficamente tm: fraca maneabilidade, fraca modularidade e fraco desempenho [GRAY, 1989].
2.2.1.2 Confiabilidade em transaes distribudas As transaes distribudas so executadas em vrios sites nos quais elas acessam o banco de dados local, assim com suporte total para transaes distribudas, os aplicativos podem acessar uma nica imagem lgica do banco de dados e confiar no SGBD distribudo para assegurar que suas solicitaes sero executadas corretamente, independentes do que acontecer no sistema [ZSU, 1999]. Corretamente significa que os aplicativos no precisaro se preocupar com a coordenao de seus acessos a banco de dados locais individuais, nem tero de se preocupar com a possibilidade de falhas de sites ou links de comunicao durante a execuo de suas transaes.
2.2.1.3 Desempenho otimizado O desempenho otimizado dos SGBDs distribudos se baseia em dois pontos: Um SGBD distribudo fragmenta o banco de dados, permitindo que os dados fiquem armazenados prximos a seus pontos de utilizao, reduzindo o atraso de acesso remoto, alm disso, cada site manipula apenas uma parte do banco de dados, tornando a administrao deste mais simples. O paralelismo inerente de sistemas distribudos pode ser explorado para se obter paralelismo entre consultas e intraconsulta, assim possvel executar vrias consultas ao mesmo tempo e o paralelismo intraconsulta alcanado desmembrando uma nica consulta em vrias subconsultas que sero executas em locais diferentes. A possibilidade de autonomia local freqentemente a maior vantagem de bancos de dados distribudos [MOURA, 1985]. Pelo motivo que os dados so replicados em vrios ns, uma transao que necessita de um particular item de dado pode encontr-lo em qualquer outro ns. Com isso, a
16
falha de um n no necessariamente implica na parada de funcionamento de um sistema, aumentando a confiabilidade e disponibilidade do sistema.
2.2.1.4 Expanso de sistema mais fcil Um sistema distribudo pode crescer mais facilmente que um sistema centralizado. Se for necessrio expandir o sistema porque o volume de dados cresceu ou o volume de processamento aumentou, mais fcil acrescentar um novo n a rede de computadores, desde que os ns sejam autnomos, do que substituir um sistema centralizado j existente por outro maior.
2.3
TRANSPARNCIA DE DADOS A transparncia oculta dos usurios os detalhes de implementao. Um sis-
tema pode ser fragmentado e replicado, ou seja, uma relao pode ser particionada e cada uma dessas parties ser armazenada em locais distintos, isso chamada de fragmentao. Alm disso, talvez seja prefervel duplicar alguns desses dados em outros lugares por razes de confiabilidade e desempenho, que conhecido como replicao de dados, o resultado um banco de dados distribudo que fragmentado e replicado. Para lidar de maneira adequada com este banco de dados distribudo, fragmentado e replicado, o sistema deve ser capaz de lidar com vrios tipos de transparncias, que ser discutido agora [ZSU, 1999].
2.3.1 Transparncia de rede Em um ambiente de gerenciamento de banco de dados distribudo o usurio deve ser protegido contra os detalhes operacionais da rede ou at mesmo ocultar a existncia da rede, assim no haveria nenhuma diferena entre a execuo de um aplicativo em um banco de dados centralizado e um distribudo. Esse tipo de transparncia referido com transparncia de rede ou transparncia de distribuio. Alguns autores separam a transparncia de distribuio em duas: a transparncia de localizao e transparncia de nomenclatura. A transparncia de localizao se refere ao fato que a execuo de um comando independe da localizao dos dados. A transpa-
17
rncia de nomenclatura significa que um nome exclusivo dado para cada objeto no banco de dados e na ausncia desta transparncia o usurio obrigado a incorporar o nome da localizao como parte do nome do objeto [ZSU, 1999].
2.3.2 Transparncia de replicao A transparncia de replicao se refere ao fato que os usurios no devem estar cientes das existncias de cpias, ou seja, o sistema deve tratar do gerenciamento das cpias e os usurios devem agir como se houvesse uma nica cpia dos dados. Assim o usurio no deve se envolver com a manipulao de cpias e com a obrigao de especificar o fato de que uma certa ao pode e/ou deve ser executada sobre vrias cpias [ZSU, 1999].
2.3.3 Transparncia de fragmentao Dividir cada relao de um banco de dados em fragmentos menores e tratar cada fragmento como um objeto de banco de dados separado (isto , outra relao) aumenta o desempenho, disponibilidade e confiabilidade do sistema [ZSU, 1999]. A fragmentao de dados ser estudada mais detalhadamente na seo 2.52. Ento quando objetos de um banco de dados esto fragmentados, deve-se lidar com o problema de manipular consultas do usurio que foram especificadas sobre relaes inteiras, mas que agora devem ser executadas em sub-relaes, a transparncia de fragmentao livra os usurios da existncia destes fragmentos, fazendo com que se parea que exista apenas uma relao.
2.4
ARQUITETURA DE UM BANCO DE DADOS DISTRIBUDO preciso observar que, a organizao dos dados fsicos em cada mquina
pode ser, e provavelmente , diferente, assim h necessidade de definir um esquema interno individual em cada site, o que chamado de esquema interno local (EIL), h tambm o esquema conceitual global (ECG), que global porque descreve a estrutura lgica dos dados em todos os sites. Como os dados em um banco de dados distribudo em geral esto fragmentados e replicados, preciso descrever em cada site a organizao lgica dos dados, assim necessria uma terceira camada na arquitetura, o esquema conceitual local (ECL), o esquema
18
conceitual global a unio dos esquemas conceituais locais. Por fim, o acesso de aplicativos do usurio e o acesso de usurios ao banco de dados so admitidos pelos esquemas externos (EEs) [ZSU, 1999].
Figura 3: Arquitetura de banco de dados distribudo
O modelo de arquitetura descrito acima fornece os nveis de transparncia discutidos anteriormente, as transparncias de localizao e replicao so admitidas pela definio dos esquemas conceituais locais e globais, e pelo mapeamento intermedirio, j a transparncia de rede aceita pela definio do esquema conceitual global, assim o usurio pode examinar os dados independentemente de sua localizao ou de qual componente local do sistema de banco de dados distribudo o servir. Uma descrio mais detalhada deste modelo estendida pela adio de um dicionrio/diretrio global (D/DG), que permite os mapeamentos globais exigidos, e os mapeamentos locais so executados por um dicionrio/diretrio local (D/DL). Um SGBD distribudo dividido em dois importantes componentes: o processador do usurio e o processador de dados. O primeiro componente importante, que chamado de processador do usurio, consiste em quatro elementos: O tratador da interface do usurio: responsvel pela interpretao dos comandos do usurio e pela formatao dos dados do resultado conforme so enviados ao usurio.
19
O controlador de dados semnticos utiliza as restries de integridade e as autorizaes definidas como parte do esquema conceitual global para verificar se a consulta do usurio pode ser processada.
O otimizador e decompositor de consultas globais determina uma estratgia de execuo para minimizar o custo alm de converter as consultas globais em consultas locais.
O monitor de execuo distribuda coordena a execuo distribuda da solicitao do usurio.
O segundo componente importante o processador de dados, que consiste em trs elementos: O otimizador de consulta local responsvel pela escolha do melhor caminho de acesso a qualquer item de dados. O gerenciador de recuperao local responsvel pela garantia de que o banco de dados local permanecer consistente, mesmo com a ocorrncia de falhas. O processador de suporte runtime acessa fisicamente o banco de dados de acordo com os comandos fsicos no escalonamento gerado pelo otimizador.
Figura 4: Componentes de um SGBDD Distribudo
20
2.5
ESTRATGIAS DE DISTRIBUIO DE DADOS
2.5.1 Replicao de Dados A replicao de dados pode ser simplesmente definida como o processo de gerao e reproduo de mltiplas cpias de dados em um ou vrios ns [CONN, 1999]. Assim o sistema mantm vrias rplicas idnticas de uma relao, em que cada rplica armazenada em um n diferente. A replicao pode ser total, quando todo o banco replicado, criando assim um banco de dados totalmente replicado, isso melhora bastante a disponibilidade e tambm melhora o desempenho de recuperao para consultas globais, pois uma consulta pode ser decomposta e executada em paralelo. A desvantagem da replicao total que pode desacelerar drasticamente operaes de atualizaes, uma vez que uma nica atualizao deve ser realizada em todas as cpias do banco de dados para manter a consistncia. Por outro, pode no haver nenhuma replicao, ou seja, cada fragmento armazenado em exatamente um n, que em geral chamado de banco de dados particionado. Entre esses dois extremos, existe a replicao parcial, em que alguns fragmentos do banco podem ser replicados, enquanto outros no [ELM, 2002].
2.5.2 Fragmentao de Dados Em um BDD, devem ser tomadas decises em relao a qual n dever ser utilizado para armazenar quais partes do banco de dados, assim, a diviso de uma relao r em unidades lgicas menores para fins de distribuio chamada de Fragmentao de Dados. A questo mais importante para fragmentar dados que, uma relao no uma unidade adequada, pois em geral as vises de aplicativos so subconjuntos de relaes, e, portanto o carter local de acessos de aplicativos no definido sobre relaes inteiras, mas sim em subconjuntos de relaes. Se uma relao r fragmentada, r dividida em um nmero de fragmentos r1, r2,..., rn. Estes fragmentos contm informao suficiente para reconstruir a relao r original. Esta reconstruo pode ser feita atravs da aplicao de uma operao de unio ou um tipo especial de juno dos vrios fragmentos [COU, 1984].
21
2.5.2.1 Tipos de Fragmentao Existem trs tipos de fragmentao:
1 - Fragmentao Horizontal Um fragmento horizontal de uma relao um subconjunto das tuplas dessa relao, ou seja, a fragmentao horizontal divide uma relao horizontalmente agrupando linhas para criar subconjuntos de tuplas, nas quais cada subconjunto tem um certo significado lgico, esses fragmentos podem ser ento designados para diferentes ns no sistema distribudo [ELM, 2002]. Um fragmento horizontal pode ser definido como uma seleo sobre a relao global r:
A reconstruo de uma relao r pode ser obtida tomando a unio de todos os
fragmentos, isto :
Exemplo de fragmentao horizontal:
Figura 5: Relao inteira(PROJ) e uma relao fragmentada horizontalmente(PROJ1)
2 - Fragmentao vertical Cada n pode no precisar de todos atributos de uma relao, assim surgiu a fragmentao vertical, que divide uma relao verticalmente atravs das colunas, um fragmento vertical de uma relao mantm apenas alguns atributos da relao [ELM, 2002]. Um fragmento vertical pode ser definido como uma projeo sobre a relao global r:
22
Essa fragmentao no muito apropriada porque, se dois fragmentos estiverem armazenados separadamente no podemos colocar juntas de novo as tuplas originais, uma vez que no existe nenhum atributo comum entre os dois fragmentos, assim necessrio incluir o atributo da chave primria ou o atributo de alguma chave candidata em todos fragmentos verticais, de modo que a relao completa possa ser reconstruda. A relao r pode ser reconstruda a partir da juno natural dos fragmentos:
Exemplo de fragmentao vertical:
Figura 6: Relao inteira(PROJ) e uma relao fragmentada verticalmente(PROJ2)
3 Fragmentao Mista Em alguns casos, uma fragmentao vertical ou horizontal simples no ser suficiente para satisfazer as necessidades de um aplicativo do usurio, assim, nesse caso, uma fragmentao vertical pode ser seguida por uma horizontal ou vice-versa, resultando na fragmentao mista. Cada fragmento obtido como resultado da aplicao dos mtodos para fragmentao horizontal e vertical na relao r ou em um fragmento de r que foi previamente obtido. Exemplo de fragmentao mista:
Figura 7: Relao inteira (PROJ) e uma relao fragmentada (PROJ3)
23
2.6
PROPAGAO DE ATUALIZAES Como em um sistema de banco de dados distribudos os dados geralmente
esto replicados e fragmentados, ou seja, existem vrias cpias do mesmo dado, assim, quando ocorre uma atualizao em uma destas cpias, preciso que esta atualizao seja propagada para as demais cpias para manter a consistncias entre os dados e para que a existncia de vrias rplicas do mesmo dado seja transparente ao usurio. Basicamente, existem dois tipos de propagao de atualizaes: a sncrona e a assncrona. Na propagao de atualizaes Sncrona, quando feita alguma alterao em umas das cpias de um determinado dado, esta alterao imediatamente propagada para as demais replicas, j na propagao de atualizaes Assncrona, as alteraes so armazenadas em uma fila e so propagadas em intervalos de tempos determinados ou quando for solicitada a propagao.
2.7
PROCESSAMENTO DE CONSULTAS Em um sistema distribudo, vrios fatores adicionais complicam ainda mais o
processamento de consultas, principalmente o custo de transferir dados ao longo da rede, para tentar reduzir este custo, algoritmos de otimizao de consultas tentam diminuir o volume de transferncia de dados. Por outro lado, o processamento de consultas em sistemas distribudos possui um ganho potencial de desempenho, tendo diversos ns da rede processando partes da consulta em paralelo [ELM, 2002].
2.7.1 Processadores de consultas A seguir sero relacionadas s caractersticas mais importantes dos processadores de consultas, em que as trs primeiras caractersticas so vlidas para processadores de consulta centralizado e distribudo, enquanto que as trs caractersticas seguintes so especficas para o distribudo.
1 - Tipos de Otimizao A otimizao de consulta visa escolha da melhor estratgia de execuo entre todas possveis. Um mtodo imediato pesquisar o espao de solues, prever exaustiva-
24
mente o custo de cada estratgia e escolher a de menor custo, embora este mtodo seja eficiente na escolha da melhor estratgia, h o problema caso o espao de solues seja muito grande, mas ter um alto custo de otimizao no necessariamente ruim, assim muitas vezes utilizada uma abordagem de pesquisa exaustiva. Tentando evitar o alto custo da pesquisa exaustiva, forma propostas estratgias randomizadas, como a otimizao iterativa [SWAMI, 1989] e o fortalecimento simulado [IOANNIDIS, 1987] que procuram encontrar uma soluo muito boa, mas no necessariamente a melhor. Outra maneira de reduzir o custo da pesquisa exaustiva e usar a heurstica, cujo efeito restringir o espao de solues em que apenas algumas estratgias so consideradas. Uma heurstica importante em sistemas distribudos a utilizao de semijunes.
2 - Sincronizao da otimizao A otimizao da consulta pode ser feita de forma esttica antes da execuo da consulta, ou de forma dinmica durante a execuo da consulta. A otimizao esttica feita em tempo de compilao da consulta, assim o custo de otimizao pode ser amortizado sobre vrias execues da consulta, essa sincronizao apropriado para o tipo de pesquisa exaustiva. A otimizao dinmica ocorre em tempo de execuo da consulta. Em qualquer ponto da execuo, a escolha da melhor operao seguinte pode se basear no conhecimento preciso dos resultados das operaes executadas anteriormente. A principal vantagem em relao esttica que os tamanhos reais das relaes intermedirias esto disponveis para o processador de consulta, minimizando assim a possibilidade de uma escolha inadequada. A principal desvantagem que a otimizao de consulta deve ser repetida para cada execuo de consulta.
3 - Estatstica A eficincia da otimizao de consultas depende de estatsticas sobre o banco de dados. A otimizao dinmica exige estatstica a fim de escolher as operaes que devem ser executadas em primeiro lugar. A otimizao esttica ainda mais exigente, pois o tamanho das relaes intermedirias tambm deve ser estimado baseado nas estatsticas.
25
As estatsticas sobre o banco de dados se relacionam com os fragmentos e incluem a cardinalidade e o tamanho dos fragmentos, o nmero de valores distintos de cada atributo, etc.
4 - Sites de Deciso Quando a otimizao esttica utilizada, um ou vrios sites podem participar da seleo da estratgia a ser aplicada para responder a consulta. A maioria dos sistemas usa a abordagem de deciso centralizada, no qual um nico site gera a estratgia.
5 - Explorao de fragmentos As consultas distribudas expressas sobre relaes globais so mapeadas em consultas sobre fragmentos fsicos de relaes, este processo chamado de localizao, pois sua funo principal localizar os dados envolvidos na consulta.
6 Semijunes Um semijuno da relao R definida sobre o conjunto de atributos A pela relao S definida sobre o conjunto de atributos B o subconjunto das tuplas de R que participam da juno de R com S. A operao de semijuno tem a importante propriedade de reduzir o tamanho da relao operando. Quando o principal componente de custo considerado pelo processador de consultas a comunicao, uma semijuno til para melhorar o processamento de operaes de juno distribuda, pois ela reduz o tamanho dos dados trocados entre os sites. Para demonstrar a diferena entre juno e semijuno sobre o predicado FUNC.CARGO=PAG.CARGO sero utilizadas as duas tabelas detalhadas abaixo:
Figura 8: Tabela FUNC (dir) e PAG(esq)
Os resultados da juno e da semijuno so mostrado na figura 9:
26
Figura 9: Resultado da juno(dir) e da semijuno(esq)
2.7.2 Camadas de processamento de consulta H quatro camadas principais para mapear uma consulta distribuda em uma seqncia otimizada de operaes locais, cada uma atuando sobre um banco de dados local. Essas camadas so: Decomposio de consultas, localizao de dados, otimizao de consultas globais e otimizao de consultas locais.
2.7.2.1 Localizao de dados A principal funo desta segunda camada localizar os dados da consulta com o uso de informaes de distribuio de dados, determinado quais fragmentos esto envolvidos na consulta e transformando a consulta distribuda em uma consulta sobre fragmentos.
2.7.2.2 Otimizao de consultas globais O Objetivo da otimizao de consultas encontrar uma estratgia de execuo para a consulta que esteja prxima da estratgia tima. A otimizao de consultas consiste em encontrar a melhor ordenao de operaes na consulta de fragmentos, inclusive operaes de comunicao que minimizam uma funo de custo.
2.7.2.3 Otimizao de consultas locais Esta ltima camada executada por todos os sites que tm fragmentos envolvidos na consulta, cada subconsulta executada em um site, chamada de consulta local, ento otimizada com o uso do esquema local do site.
27
2.7.2.4 Otimizao de consultas distribudas O objetivo real do otimizador de consulta encontrar uma estratgia prxima da estratgia tima e, talvez o mais importante, evitar estratgias ruins. A otimizao de consulta se refere ao processo de produzir um plano de execuo de consultas, que representa uma estratgia de execuo da consulta. O plano escolhido minimiza uma funo de custo. Um otimizador de consulta um conjunto de trs componentes: um espao de pesquisa, um modelo de custo e uma estratgia de pesquisa. Um espao de pesquisa o conjunto de planos alternativos de execuo para representar a consulta, estes planos so equivalentes no sentido de que chegam ao mesmo resultado, mas diferem na ordem de execuo das operaes e no modo como essas operaes so implementadas. Utilizar um espao de pesquisa muito grande pode tornar o tempo de otimizao proibitivo, assim geralmente os otimizadores restringem o espao de pesquisa, em que a primeira restrio utilizar heurstica, a heurstica mais comum executar operaes de seleo e projeo ao acessar relaes bsicas, uma outra heurstica evitar produtos cartesianos que no sejam exigidos pela consulta. O modelo de custo prev o custo de um dado plano de execuo atravs de uma funo de custos para operadores, estatsticas e dados bsicos. O custo de uma estratgia de execuo distribuda pode ser expresso de acordo com o tempo da consulta. O principal fator que afeta o desempenho de uma estratgia de execuo o tamanho das relaes intermedirias produzidas durante a execuo, assim preciso avaliar os resultados intermedirios, em que essa estimativa se baseia em informaes estatsticas sobre as relaes bsicas e frmulas para prever a cardinalidade dos resultados das operaes. A estratgia de pesquisa explora o espao de pesquisa e seleciona o melhor plano, utilizando o modelo de custo. A estratgia de pesquisa mais popular usada por otimizadores de consultas a programao dinmica, que determinstica, que constroem todos os planos possveis antes de escolher o melhor plano, para reduzir o custo de otimizao, planos parciais que provavelmente no conduziro ao plano timo so descartados. A programao dinmica quase exaustiva e assegura que seja encontrado o melhor de todos planos, mas este processo se torna muito dispendioso quando o nmero de relaes maior que cinco ou seis, assim recentemente tem aumentado o interesse em estratgias randomizadas ou aleatrias, que garantem a otimizao, mas no garantem o melhor plano de todos.
28
2.8
PROCESSAMENTO DE TRANSAES Uma transao entendida como uma srie de operaes sobre itens no ban-
co de dados que podem vir a alterar o estado do mesmo. Neste ponto, encontra-se o conceito de atomicidade da transao. Transaes atmicas so constantemente empregadas em sistemas distribudos, caracterizando-se pelo fato de que, se algo impede o trmino desta transao, o banco de dados deve ser restaurado ao estado anterior ao incio da execuo desta transao RollBack, evitando com isto, que o mesmo passe a um estado de inconsistncia [REICH, 1997]. As transaes podem ser Locais ou Globais, as transaes locais so aquelas que mantm acesso e atualizam apenas a base de dados local, j as transaes globais mantm acesso e atualizam diversas bases de dados locais e remotas. Para processar uma transao, cada n do sistema contm dois subsistemas, um Gerenciador de Transaes e um Coordenador de Transaes, o Gerenciador de Transaes responsvel pelo gerenciamento de execues das transaes (ou subtransaes), que acessam dados armazenados em um n local, alm de garantir as propriedades ACID (Atomicidade, Consistncia, Isolamento e Durabilidade) e o Coordenador de Transaes coordena a execuo de vrias transaes (locais e globais) iniciados naquele n e deve garantir a atomicidade da transao atravs do protocolo de efetivao, em que o protocolo mais utilizado o Protocolo de Efetivao em duas fases (two-phase commit protocol) que ser detalhado mais frente. Transaes distribudas podem ocorrer devido a diversos fatores, entre os quais incluem [DEMP, 1997]: Itens de informaes pertencentes a uma operao podem estar distribudas em diversos servidores (ns); Uma transao pode necessitar de acesso a mais de um recurso e talvez, conseqentemente, mais de um servidor; Um servidor provendo um servio pode ter que contactar outro servidor para poder prover este mesmo servio; Vrios so os problemas originados com transaes distribudas, segundo [MATT, 1998], pode-se citar o problema de como manter um estado consistente da base de dados com tanta replicao.
29
Existe ainda, o fato de transaes poderem geralmente ser executadas em paralelo, devido s informaes residirem em localizaes diferentes, com isto, so necessrios o controle de concorrncia e a capacidade de recuperao de dados. A execuo de transaes em paralelo aumenta a complexidade de aes, como, por exemplo, determinar quando realizar um commit de uma transao [ZAS, 1997]. A filosofia por trs desta idia verificar que o trmino das transaes num sistema distribudo seja uniforme, ou seja, ou as transaes so abortadas em todos os ns, ou so atualizadas nestes ns [NOEL, 1998].
2.8.1 Protocolo Two-fase commit (2PC) O protocolo Two-phase Commit (2PC) um protocolo muito simples que assegura a consolidao atmica de transaes distribudas. Uma transao distribuda necessita de um commit especial. Durante uma transao, o gerenciador de uma transao no pode simplesmente aguardar a resposta de commit de um dos sites, pois, durante o commit de um deles, pode haver um erro, e se os outros j deram commit, no ser possvel dar rollback na transao. Por isso o 2PC divide esta tarefa em duas fases [MIT, 1995].
1 - Fase de preparao Na fase de preparao o gerenciador de transao envia uma mensagem prepare a todos os sites participantes e entra no estado de espera. Ento os gerenciadores locais de cada site participante da transao verificam se possvel consolidar a transao. Depois de receber uma resposta de todos os participantes, o gerenciador decide entre consolidar ou abortar a transao (Fase Commit).
2 - Fase Commit Para o gerenciador chegar a uma deciso de trmino global de uma transao, duas regras governam essa deciso; juntas elas formam a regra de consolidao global: Se at mesmo um participante votar por abortar a transao, o gerenciador tem de chegar a uma deciso de abortar global. Se todos os participantes votarem por consolidar a transao, o gerenciador tem de chegar a uma deciso de consolidao global.
30
2.9
CONTROLE DISTRIBUDO DE CONCORRNCIA O mecanismo de controle de concorrncia de um SGBD distribudo assegura
que a consistncia do banco de dados seja mantida, assim se as transaes so consistentes internamente, a maneira mais simples de alcanar esse objetivo executar cada transao sozinha, mas claramente esta alternativa s tem interesse terico e no pode ser implementada em sistema prtico, pois minimiza a concorrncia do sistema, em que o nvel de concorrncia talvez seja o parmetro mais importante em sistemas distribudos [BALTER, 1982]. A seguir, sero discutidos alguns mecanismos para o controle de concorrncia:
1 - Bloqueio em transaes distribudas Segundo [TAN, 1992] o precursor e mais amplamente difundido algoritmo de controle de concorrncia, o bloqueio (locking). Este mecanismo pessimista consiste no fato de que quando algum processo (o que d incio transao) requer operaes de leitura ou gravao sobre registros (ou outro objeto), como parte da transao, ele deve primeiro obter o bloqueio do recurso ou dos recursos que ir utilizar. Outros processos que requeiram tais recursos no iro obt-los, pelo fato destes estarem bloqueados. O gerenciador mantm uma lista de objetos bloqueados e assim rejeita todas as tentativas de bloqueio sobre estes objetos, que j se encontram nesta situao por outros processos. Existem dois tipos de bloqueios: de leitura (read lock) e o de gravao (write lock). A granularidade do bloqueio, ou seja, o tamanho do objeto que est sendo bloqueado, permite determinar a preciso do bloqueio, quanto menor a granularidade, mais preciso ser o bloqueio e mais paralelismo poder ser alcanado. Por outro lado granularidades menores requerem mais bloqueios e podem levar a deadlocks.
2 - Timestamping Um mtodo completamente diferente para implementar controle de concorrncia utilizando uma tcnica otimista chamada timestamping, o qual consiste na designao de um valor (timestamp ou simplesmente, identificador) para cada transao, no exato momento em que aquela ocorre [REE, 1983]. Em outras palavras, a idia fundamental desta tcnica a seguinte [DATE, 1988]:
31
Cada transao recebe um identificador (timestamp) nico global; As operaes de atualizaes no so aplicadas fisicamente sobre o banco de dados, at o trmino (bem-sucedido) da respectiva transao; Cada um dos objetos do banco de dados (conforme conceito j definido anteriormente), carrega o timestamp da transao que por ltimo o leu (read), e o timestamp da transao que por ltimo o atualizou (write). Se uma solicitao de operao sobre um banco de dados feita por determinada transao T1, conflitar com alguma outra operao j executada, baseada na solicitao de outra transao mais jovem T2, a transao T1 cancelada e reiniciada. Quando uma transao reiniciada por algum motivo, esta receber um novo identificador (timestamp).
32
3 3.1
BANCO DE DADOS TESTADOS INTRODUO Para realizar a distribuio de dados, existem vrios SGBDDs disponveis,
entre eles pode-se destacar: Oracle, SQL Server, DB2, PostgreSQL, Firebird/Interbase, Informix, MySql, entre outros. Neste trabalho, foram utilizado dois dos principais SGBDDs, o Oracle9i Entreprise Edition e o Microsoft SQL Server 2000, estes dois bancos de dados, foram escolhidos por possurem um sistema de distribuio de dados mais completo, permitindo uma melhor avaliao. 3.2 TIPOS DE REPLICAO
3.2.1 Tipos de replicao do Oracle Os ambientes de replicao do Oracle suportam dois tipos bsicos de sites: sites-mestres e sites de views materializadas. Um site mestre recebe uma cpia completa de todos os objetos de replicao e se comunicam diretamente entre si para propagar as alteraes de dados. Um site de view materializada recebe todos ou uma parte dos objetos replicados, por exemplo, pode-se escolher replicar apenas as tabelas selecionadas ou somente partes selecionadas de uma tabela. Os sites de view materializada devem ser associados a um nico site mestre e recebem somente as atualizaes do site mestre ao qual esto associados [ORA1]. Uma das formas do Oracle replicar dados atravs de views mate-rializadas, que podem conter todas ou um subconjunto de linhas e/ou colunas da tabela mestre, assim possvel incluir na view somente os dados necessrios das tabelas mestre. As views materializadas podem ser somente para leitura ou atualizveis.
View somente p/ leitura View atualizvel Somente para consultas Para consultas e atualizaes Podem ser derivados de uma nica ou vrias derivada apenas de uma nica tabela mestre tabelas mestres CREATE SNAPSHOT nomedatabela CREATE SNAPSHOT nomedatabela FOR UPDATE
33
Para gerenciar todos os objetos de uma replicao, o Oracle utiliza grupos de replicao, assim administrar vrios objetos juntos se torna mais fcil. Existem dois tipos de grupos, o grupo mestre e o grupo de views materializadas. O grupo mestre pode ser criado da seguinte maneira:
BEGIN DBMS_REPCAT.CREATE_MASTER_REPGROUP( gname => nomedogrupo ); END;
A criao do grupo de views materializadas pode ser feita como abaixo:

BEGIN DBMS_REPCAT.CREATE_SNAPSHOT_REPGROUP( gname => nomedogrupo ... ); END;
No Oracle existem quatro tipos de replicao [ORA1]: Replicao de View materializada somente para leitura Replicao de View materializada atualizvel Replicao Multimestre Replicao Hbrida
3.2.1.1 Replicao de View materializada somente para leitura Nesta opo bsica de replicao, as views materializadas fornecem acesso local s tabelas replicadas do site mestre, porm no podem ser atualizadas, desta maneira preciso acessar remotamente a tabela mestre no site mestre para atualizar os dados [ORA1]. A vantagem de se utilizar views materializadas somente para leitura, so que [ORA2]: Como no podem ser atualizados, no existe o risco de conflitos; Permitem o acesso local, o que aumenta os tempos de resposta e a disponibilidade. Tiram a carga de consultas do site mestre, porque os usurios podem consultar a view materializada local.
34
Suportam tanto a criao de views materializadas simples (utilizando apenas uma tabela mestre) como complexas (utilizando vrias tabelas mestres).
Log de view materializada Um log de view materializada uma tabela no site mestre que grava todas mudanas na tabela mestre ou na view materializada mestre, este log associado a uma nica tabela-mestre ou view materializada-mestre, e cada uma delas possui somente um log de view materializada, assim s possvel utilizar o log com view materializadas simples [ORA1]. Para criar um log de view materializada utilizado o seguinte comando:
CREATE MATERIALIZED VIEW LOG ON nomedatabela
3.2.1.2 Replicao de view materializada atualizvel A replicao de view materializada atualizvel permite que os usurios atualizem as views materializadas, mas ao contrrio da replicao de view materializada somente para leitura, que permite que as views sejam simples ou complexas, esta s permite a utilizao de views simples, ou seja, baseadas em apenas uma tabela mestre. O log de view materializada tambm utilizado assim como na replicao de view materializada somente para leitura [ORA1]. O Oracle propaga as alteraes feitas em uma view materializada atualizvel para a tabela-mestre remota da view materializada. As vantagens de utilizar as views materializadas atualizveis so [ORA2]: Permitem que os usurios consultem e atualizem um conjunto local de dados replicados, mesmo quando desconectados do mestre. Requer menos recursos do que a replicao multimestre e oferece suporte a atualizaes de dados. Alm disso, como as views materializadas podem residir em um banco de dados que contm um volume bem menor de dados, os requisitos de espao em disco e memria dos clientes de views materializadas podem ser menores que os de um servidor Oracle contendo sites-mestre.
35
3.2.1.3 Replicao Multimestre Na replicao Multimestre (tambm conhecida como no-hierrquica ou ndirecional), todos os sites participantes esto autorizados a atualizar as tabelas replicadas, assim, as modificaes em uma tabela so propagadas e aplicadas diretamente em todos os outros sites, estas modificaes podem ser transmitidas assincronamente ou sincronamente [ORA2]. Na replicao multimestre, todos os sites participantes possuem os mesmos objetos replicados, assim, caso se deseja replicar apenas parte dos objetos, preciso trabalhar os sites como de view materializada. As aplicaes podem atualizar qualquer tabela replicada em qualquer site de uma configurao multimestre. Na configurao multimestre preciso definir um dos sites como mestre definition, que ser o responsvel pela criao dos outros sites mestres e do grupo mestre de objetos replicados, normalmente o site mestre definition o primeiro site configurado como mestre, caso seja necessrio, possvel alterar o site mestre definition. Se todos os sites participantes se comunicam um com o outro sincronizadamente, ento no h ocorrncia de conflitos de atualizao, porm, se as modificaes esto sendo propagadas assincronamente, o Oracle detecta automaticamente os conflitos que ocorrerem, que sero resolvidos utilizando um mtodo apropriado escolhido pelo usurio [ORA1].
3.2.1.4 Replicao Hbrida A replicao multimestre e de views materializadas (somente para leitura e/ou atualizveis) podem ser combinadas em configuraes hbridas ou misturadas para atender aos diferentes requisitos de aplicao. As configuraes hbridas podem ter qualquer nmero de sites-mestre e vrios sites de view materializada para cada mestre. Por exemplo, a replicao multimestre (ou n-direcional) entre dois mestres pode suportar a replicao de tabela inteira entre os bancos de dados que suportam duas regies geogrficas. As Views Materializadas podem ser definidas nos mestres para replicar tabelas inteiras ou subconjuntos de tabelas para sites dentro de cada regio [ORA1]. As principais diferenas entre views materializadas e mestres replicados incluem as seguintes [ORA2]:
36
Os mestres replicados devem conter dados da tabela inteira que est sendo replicada, ao passo que as views materializadas podem replicar subconjuntos de dados.
A replicao multimestre permite que voc replique alteraes para cada transao medida que elas ocorrem. As renovaes de view materializada so baseadas em conjuntos, propagando as alteraes de vrias transaes em uma operao mais eficiente baseada em lotes, mas em intervalos menos freqentes. Se ocorrerem conflitos devido s alteraes feitas em vrias cpias dos mesmos dados, a deteco e a resoluo de conflitos sempre ocorrer em um elementomestre, que poder ser um site-mestre ou um site-mestre de view materializada.
3.2.2
Tipos de replicao do SQL Server Para implementar a replicao de dados, o SQL Server utiliza trs tipos de si-
tes: Publicador, Distribuidor e Assinante. O site Publicador o responsvel por disponibilizar os dados (publicaes) que sero replicados para outros sites, alm disso, detecta os dados que so alterados durante uma transao e mantm informaes sobre todas as publicaes existentes no servidor. Exemplo de como configurar um publicador:
sp_adddistpublisher
@publisher = NomedoServidor
O site Distribuidor hospeda um banco de dados distribuidor que armazena dados sobre transaes e histricos, geralmente o site publicador tambm configurado como site distribuidor. Exemplo de como configurar um distribuidor e criar um banco de dados distribuidor:
sp_adddistributor @distributor = NomedoServidor //configura um servidor como distribuidor sp_adddistributiondb @database = N'distribution' //cria o banco de dados Distribuidor
37
O site Assinante recebe os dados replicados que foram disponibilizados pelo Publicador, mas no necessariamente ele precisa receber todos as publicaes, apenas as quais necessita [SHAPIRO, 2002]. Exemplo configurar um assinante:
sp_addsubscriber
@subscriber = NomedoServidor
Para disponibilizar os dados que sero replicados, o SQL Server utiliza Publicaes, Artigos e Assinaturas. Um artigo pode ser um objeto de banco de dados, como uma tabela de dados inteira, determinadas linha ou colunas de uma tabela. Uma publicao uma coleo de artigos composta por um ou mais artigos. Exemplo de como criar uma publicao:
\\criar uma publicao do tipo Merge sp_addmergepublication @publication = NomedaPublicao, \\criar uma publicao do tipo Snapshot ou Transacional sp_addpublication @publication = NomedaPublicao
Uma assinatura uma solicitao de uma cpia de dados de um banco de dados, em que uma assinatura define o local e qual publicao ser recebida. Exemplo para se criar uma assinatura:
\\cria uma assinatura do tipo Merge sp_addmergesubscription @publication = NomedaPublicao \\cria uma assinatura do tipo Snapshots ou Transacional sp_addsubscription @publication = NomedaPublicao
O SQL Server fornece trs tipos de replicao: Replicao Snapshots Replicao Transaction Replicao Merge
38
3.2.2.1 Replicao Snapshots Na replicao Snapshots, tirado um retrato do banco de dados em um determinado momento, ou seja, os dados so distribudos exatamente como aparecem em um momento especfico e no so monitorados por atualizaes. Esta replicao mais bem utilizada quando os dados sofrem pouca atualizao. Quando ocorre a sincronizao de dados, o snapshots inteiro criado novamente e enviado para o Assinante. A replicao Snapshots mais indicada quando h uma alterao substancial nos dados, mas no freqentemente, mais utilizada quando se necessita distribuir dados somente de leitura. As atualizaes feitas na tabela do assinante podem ser imediatamente transmitidas para o publicador, caso tenho selecionado a opo immediate updating, mas as atualizaes na tabela do Publicador so transmitidas para o assinante somente no intervalo de tempo especificado ou continuadamente. Quando o Assinante est configurado como somente para leitura a consistncia transacional est garantida, mas quando permite atualizaes, a consistncia transacional entre o Publicador e o Assinante mantida atravs do protocolo two-phase commit(2PC) [SHAPIRO, 2002].
3.2.2.2 Replicao Transacional Na Replicao transacional, as operaes que atualizam os dados do publicador so capturadas individualmente e propagadas para os Assinantes. Para capturar tais mudanas, existe um log que armazena informaes sobre as operaes que alteraram os dados. O SQL Server monitora comandos como INSERT, UPDATE, DELETE entre outros, gravando-os no banco de dados distribuidor para que as alteraes sejam propagadas em sua ordem cronolgica. Este tipo de replicao mais indicado quando a consistncia entre o publicador e os assinantes fundamental, pois a replicao transacional particiona o aplicativo para evitar conflitos ao invs de tentar soluciona-los quando ocorrem. Aqui os ns Assinante no so autnomos, pois preciso que o Publicador e o Assinante estejam continuadamente conectados para a propagao imediata das atualizaes [SHAPIRO, 2002].
39
3.2.2.3 Replicao Merge O sistema de replicao Merge permite que os sites atuem de forma autnoma, desta maneira podem ser feitas atualizaes em cada um dos servidores participantes da replicao de forma independente, assim, os mesmos dados podem ser atualizados no publicador ou em mais de um assinante, com isso conflitos podem ocorrer quando os mesmos dados so atualizados, para resolver estes conflitos, utilizado um resolvedor que soluciona os conflitos de acordo com o mtodo de resoluo de conflito escolhido [SHAPIRO, 2002]. A replicao Merge recomendada quando: Vrios assinantes necessitam atualizar dados em vrios tempos e propagar estas mudanas para o publicador ou para outros assinantes. Assinantes precisam receber dados, realizar atualizaes off-line e sincronizar as mudanas depois com o publicador e outros assinantes. Site autnomo importante.
Pelo fato da replicao Merge permitir que vrios sites realizem atualizaes, pode ocorrer que, ao se efetuar uma atualizao esta viole alguma restrio, mas mesmo assim a atualizao permitida, s sendo resolvida quando ocorre a sincronizao, e nesta fase que feita a verificao de conflitos, na qual atualizaes que esto violando algumas das restries so desfeitas, por exemplo, ao se fazer uma insero de um funcionrio do Paran em um servidor X que contenha uma tabela com a restrio de possuir somente cadastros de funcionrio do estado de So Paulo, ela aceita, mas ao se realizar a sincronizao, esta atualizao propagada para um servidor Y que a aceite e ento desfeita do servidor X.
3.3
TRANSPARNCIA DE DADOS Os SGBDDs devem disponibilizar mecanismo que tornem a distribuio de
dados transparente ao usurio, ou seja, devem esconder detalhes de rede, a existncia de vrias cpias de uma relao, entre outros aspectos. A transparncia de localizao pode ser obtida tanto no Oracle quanto no SQL Server da mesma maneira, utilizando vises. Por Exemplo, assumindo que a tabela EMP armazenada em um banco de dados local e a tabela DPTO em um banco de dados remoto. Para fazer a localizao, e o relacionamento, transparente destas tabelas aos usurios, criada uma viso chamada COMPANY:
40
CREATE VIEW company AS SELECT empno, ename, dname FROM scott.emp a, scoot.dept@filiala.dc.uel br WHERE a.deptno = b.deptno;
Assim, quando o usurio acessar esta viso, a localizao fsica dos dados ser transparente. 3.3.1 Transparncias no Oracle 3.3.1.1 Transparncia de Nome A transparncia de nome permite que os usurios referenciem universalmente tabelas em outros sites sem se preocupar com os sites em que estas tabelas esto localizadas. A transparncia de nome configurada atravs da utilizao de sinnimos, a criao de um sinnimo feita da seguinte maneira [ORA2]:
CREATE PUBLIC SYNONYM emp FOR scott.emp@sales.us.americas.acme_auto.com
Uma consulta que acesse uma tabela em outro site geralmente feita como abaixo,
SELECT ename, dname FROM scott.emp@sales.us.americas.acme_auto.com e, WHERE e.deptno = d.deptno;
Atravs dos sinnimos possvel realizar esta consulta da seguinte maneira:

SELECT ename, dname FROM emp WHERE e.deptno = d.deptno;
3.3.1.2 Transparncia de Replicao O Oracle possui dois mecanismos para fornecer a transparncia na replicao de tabelas [ORA2].
41
A opo de replicao de tabelas assncrona em que as modificaes em uma tabela so replicadas somente em intervalos determinados. E alternativamente, a opo de implementar a replicao de tabelas sncrona em que as modificaes em uma tabela so aplicadas nas tabelas replicadas imediatamente. Em cada um dos casos a replicao de tabelas transparente para os usurios que modificam dados nas tabelas replicadas.
3.3.2 Transparncias no SQL Server 3.3.2.1 Transparncia de nome O SQL Server no fornece transparncia de nome, assim, ao realizar uma consulta que acessa dados em outros servidores preciso referenciar explicitamente o nome do servidor ao qual queremos acessar. Exemplo:
SELECT * FROM "COP-LC32".Teste.dbo.empregado
3.3.2.2 Transparncia de Replicao O SQL Server fornece a transparncia de replicao atravs das trs opes de atualizaes, pois atravs delas, a existncia de vrias cpias de um fragmento transparente ao usurio.
3.4
ARQUITETURA Em um sistema de banco de dados distribudos existe a necessidade de que
os servidores se comuniquem entre si, para isso preciso que os sistemas de gerenciamento de banco de dados distribudos forneam mecanismos que faam a conexo entre dois ou mais servidores. 3.4.1 Conexo entre servidores Oracle Para realizar a conexo entre os servidores Oracle, utilizado o Database Link (DL), que permite que os dados de um servidor remoto fiquem visveis os demais servidores.
42
Para criar um database link em um servidor, preciso se conectar a este servidor e criar um database link para todos os outros sites que participam da replicao.Um database link pode ser criado da seguinte maneira [ORA1]:
CREATE DATABASE LINK teste.dc.uel.br USING 'teste.dc.uel.br'
3.4.2 Conexo entre servidores SQL Server Para que os servidores do SQL Server possam trocar informaes entre si utilizado os Linked Serevers, que so servidores virtuais definidos atravs da store procedures SQL Server sp_addlinkedserver, que cria um servidor para a execuo de operaes distribudas em origens de dados OLE DB [SQL Server 2000]. Exemplo:
sp_addlinkedserver 'COP-LC32', ' SQL Server'
O SQL Server utiliza mapeamentos para se conectar com o provedor OLE DB como o login do SQL Server atual. Os mapeamentos so feitos atravs de store procedures sp_addlinkedsrvlogin e sp_droplinkedsrvlogin, que faz o mapeamento de um ID de login de um servidor local para um ID de login em outro servidor permitindo assim que usurios sejam mapeados no servidor virtual includo atravs do sp_addlinkedserver [SQL Server 2000]. Exemplo:
sp_addlinkedsrvlogin 'COP-LC32', 'false', NULL, 'SA', ''
Por ltimo criada uma permisso para acessar os dados do servidor remoto, que tambm feita atravs de uma store procedure, sp_serveroption que define as opes para servidores virtuais e as opes para a consulta distribuda [SQL Server 2000]. Exemplo:
sp_serveroption 'COP-LC32', 'data access', true
43
3.5
ESTRATGIAS DE DISTRIBUIO DE DADOS
3.5.1 Replicao de dados Tanto o Oracle quanto o SQL Server suportam a replicao total e parcial, ou seja, permitem que sejam replicadas apenas algumas ou todas tabelas, j a replicao particionada no possvel, pois todos os dados que sero utilizados na replicao de dados devem estar disponveis no site mestre no caso do Oracle ou no Publicador no caso do SQL Server. 3.5.2 Fragmentao de dados Tanto o SQL Server quanto o Oracle suportam os trs tipos de fragmentao: a fragmentao horizontal, vertical e mista.
3.5.2.1 Fragmentao de dados no Oracle O Oracle permite que sejam utilizados os trs tipos de fragmentao, para isso utiliza o comando SELECT para selecionar os dados necessrios.
1 - Fragmentao Horizontal Para realizar a fragmentao horizontal o Oracle utiliza o predicado da clusula WHERE do comando SELECT, por exemplo:
CREATE SNAPSHOT "ERIC"."ESTOQUE" AS SELECT * FROM "ERIC"."ESTOQUE"@MATRIZ.DC.UEL.BR WHERE "FILIAL"='FILIAL A'
2 - Fragmentao Vertical Na fragmentao vertical, o Oracle permite que sejam escolhidos apenas os atributos desejados, isso feito atravs do comando SELECT, por exemplo:
44 CREATE SNAPSHOT "ERIC"."ESTOQUE" AS SELECT COD_PROD", "FILIAL", "QUANTIDADE" FROM "ERIC"."ESTOQUE"@MATRIZ.DC.UEL.BR
3 - Fragmentao Mista A Fragmentao mista feita utilizando a fragmentao horizontal e vertical ao mesmo tempo, por exemplo:
CREATE SNAPSHOT "ERIC"."ESTOQUE" AS SELECT COD_PROD", "FILIAL", "QUANTIDADE"

FROM "ERIC"."ESTOQUE"@MATRIZ.DC.UEL.BR
WHERE "FILIAL"='FILIAL A'
3.5.2.2 Fragmentao de dados no SQL Server A fragmentao de dados no SQL Server atravs dos filtros de artigo para a fragmentao horizontal e particionamento do colunas de artigo para a fragmentao vertical.
1- Fragmentao Horizontal Para selecionar apenas as tuplas desejadas, na fragmentao horizontal o SQL Server utiliza os filtros de artigo, por exemplo:
sp_articlefilter
@publication = 'Matriz', @article = @filter_clause = 'filial=''FILIAL A'''
'estoque',
2 - Fragmentao Vertical Na fragmentao vertical o SQL Server utiliza o particionamento de colunas do artigo para selecionar apenas os atributos desejados, por exemplo:
//Adiciona apenas os atributos cod_fabricante e nome sp_articlecolumn @publication = N'Matriz1', @article = N'fabricante', @column = N'cod_fabricante', @operation = N'add'
45 sp_articlecolumn @publication = N'Matriz1', @article = N'fabricante', @column = N'nome, @operation = N'add'
3 - Fragmentao Mista Na fragmentao mista so utilizados os filtros de artigo e o particionamento de colunas do artigo, por exemplo:
sp_articlefilter @publication = 'Matriz', @filter_clause = 'filial=''FILIAL A'''
@article
'estoque',
sp_articlecolumn @publication = N'Matriz1', @article = N'fabricante', @column = N'cod_fabricante', @operation = N'add' sp_articlecolumn @publication = N'Matriz1', @article = N'fabricante', @column = N'nome, @operation = N'add'
3.6
PROPAGAO DE ATUALIZAES Para que as atualizaes realizadas em servidor sejam propagadas para os
demais servidores, os SGBDDs utilizam vrios mecanismos de propagao de atualizaes.
3.6.1 Propagao de atualizaes no Oracle No Oracle a propagao de atualizaes pode ocorrer de vrias maneiras, como: Transaes atrasadas Renovao das views materializadas Replicao Sncrona
Transaes atrasadas Em um ambiente de replicao que utiliza a propagao assncrona de dados, o Oracle utiliza um sistema interno de transaes adiadas e filas para propagar alteraes nos dados de forma assncrona entre sites-mestres e tambm de uma view materializada atualizvel e sua tabela-mestre [ORA1].
46
O sistema de transaes atrasadas funciona da seguinte maneira: quando feita alguma alterao em algum site local, esta alterao armazenada em uma fila de transaes atrasadas do site local, assim todas as alteraes so mantidas nesta fila at que seja feita a sincronizao de dados, esta sincronizao poder ser feita de forma programada, ou seja, a sincronizao ocorrer em tempos determinados ou de forma contnua, e tambm pode se feita manualmente. Uma transao ao ser aplicada em seu site destino no necessita mais permanecer no fila de transaes atrasadas, assim ao ser submetida ao site destino retirada da fila, mantendo o tamanho da fila mais fcil de ser manipulada [ORA2]. Tambm possvel retirar uma transao adiada da fila, este procedimento til quando possvel saber que uma transao poder causar um erro no site destino caso se submeta a ele.
Renovao das views materializadas A renovao das views materializada utilizada para assegurar que as views materializadas sejam consistente com a sua tabela mestre, com isso necessrio atualiz-las periodicamente; o Oracle fornece trs mtodos para atualizar os snapshots [ORA1]. Fast refresh: Utiliza o Log de view materializada para atualizar apenas as tuplas que foram alteradas desde a ltima renovao; Complete Refresh: Atualiza a view materializada completamente; Force Refresh: Realiza o fast refresh quando for possvel, seno realiza o complete refresh; A configurao do mtodo de atualizao das views materializadas feita da seguinte maneira:
CREATE SNAPSHOT nome REFRESH FAST
Grupo de renovao de views materializadas O Oracle permite que se crie um grupo de view materializadas para que sejam atualizados todos os membros do grupo ao mesmo tempo, isto permite que todas as views materializadas sejam consistentes umas com as outras, tanto as views de materializadas somente
47
para leitura quanto as atualizveis podem ser includas em um grupo de renovao [ORA1]. Exemplo de como criar um grupo de renovao:
BEGIN DBMS_REFRESH.MAKE( name => NomedoGrupo, ... ); END
Uma view materializada de um grupo de renovao tambm pode ser renovada manualmente, mas isto anula as vantagens do grupo de renovao, pois a renovao individual de uma view no renova as outras views do grupo.
Replicao Sncrona Alm dos mecanismos assncronos para propagar as atualizaes, o Oracle tambm fornece um outro mecanismo alternativo para a propagao das modificaes entre as rplicas: a replicao sncrona. A Replicao Sncrona utiliza o mesmo mecanismo das transaes atrasadas para propagar as modificaes, porm no utiliza a fila de transaes atrasadas, assim quando uma atualizao feita, esta j propagada.
3.6.2 Propagao de atualizaes no SQL Server A opo Updatable Subscriptions permite que os dados de um Assinante sejam atualizveis e est disponvel para a replicao por snapshot e transacional. Na replicao por merge, os dados de um assinante so automaticamente atualizveis [SHAPIRO, 2002]. No que diz respeito propagao das atualizaes, esta pode ocorrer de trs formas [SQL Server 2000]. Queued updating: Permite que alteraes sejam efetuadas no assinante quando este estiver desconectado do publicador. Quando o assinante se reconectar, as alteraes so enviadas para o publicador e validadas, se aceitas o processo ocorre normalmente.
48
Immediate updating: As alteraes s podem ser feitas se o publicador aceita-las imediatamente. Se as alteraes forem aceitas, elas sero propagadas para os demais assinantes. Os assinantes tm que estar conectados continuamente a publicador para que alteraes possam ser feitas no assiante. Utiliza protocolo 2PC.
Immediate updating com Queued updating: Em caso de falha na conexo, o sistema opera em modo queued updating.
Exemplo de como configurar o tipo de propagao das atualizaes:
sp_addsubscription @publication = NomedaPublicao, @update_mode = 'read only' - A assinatura somente p/ leitura 'sync tran' - Tipo Immediate updating 'queued tran' - Tipo Queued updating 'failover' - Tipo Immediate updating com queued updating
3.7
PROCESSAMENTO DE CONSULTAS DISTRIBUDAS Em um sistema de banco de dados distribudos, podem ocorrer consultas dis-
tribudas, ou seja, consultas que acessem mais de uma base de dados remota ou local, assim os SGBDDs possuem mecanismos para processar estas consultas distribudas.
3.7.1 Processamento de Consultas Distribudas no Oracle Uma consulta distribuda decomposta pelo Oracle local em um nmero correspondente ao nmero de consultas remotas, as quais so enviadas para o site remoto para serem executadas, o site remoto executa estas consultas e retornam o resultado para o site em que foram feitas as consultas.
Decomposio de Consulta SQL Quando uma consulta faz referncia a vrias tabelas, o otimizador precisa determinar quais colunas pertencem a qual tabela antes de decompor a consulta, por exemplo:
49
SELECT DNAME, ENAME FROM DEPT, EMP@REMOTE WHERE DEPT.DEPTNO = EMP.DEPTNO
Primeiro o otimizador verifica que a coluna DNAME pertence tabela local DEPT e que a coluna EMP pertence a tabela remota EMP, uma vez que o otmizador possui informaes do Dicionrio de Dados(conjunto de informaes sobre todos os objetos criados,como tabelas, ndices entre outros, que so mantidas em tabelas de sistema) de todas as tabelas remotas, a consulta pode ser decomposta. O otimizador decompe a consultas em outras consultas separadas que sero enviadas para serem executadas em diferentes bancos de dados, em que os dados resultantes so juntados localmente, tudo isto feito de forma automtica e transparente para o usurio.
Otimizao de Consulta O mecanismo de otimizao de consultas do Oracle procede da seguinte forma: O usurio realiza uma consulta; O Parser analiza e passa a consulta para o otimizador; O Otimizador gera um plano de execuo atravs do Cost-Based Optimizer; O plano gerado pelo otimizador enviado ao Row Source Generator; feita execuo da consulta atravs do SQL Execution Engine retornando o resultado ao usurio;
Cost-Basead Optimizer (CBO) O CBO determina qual plano de execuo o mais eficiente considerando os acesso disponveis e criando informaes baseadas em estatsticas para os esquemas de objetos (tabelas ou ndices) acessados pela consulta. O CBO executa os seguintes passos: O otimizador gera um conjunto de planos de execuo potenciais para a consulta, baseados nos acesso disponveis;
50
O otimizador estima o custo de cada plano baseado nas estatsticas do dicionrio de dados para os dados distribudos e caractersticas de armazenamento das tabelas, ndices e as parties acessadas pela consulta;
O custo um valor estimado proporcionalmente para estimar os recursos necessrios para a execuo de uma consulta com um plano particular. O otimizador calcula o custo dos acessos necessrios, baseados nos recursos estimados pelo computador, incluindo E/S, CPU e memria;
O otimizador compara os custos de cada plano e escolhe o de menor custo;
Para manter os melhores resultados o CBO deve reunir as estatsticas e mant-las atualizadas.
Figura 10: Cost-Based Optimization
Row Source Generator Recebe o plano timo do otimizador e gera a sada do plano. O plano de execuo uma coleo de linhas estruturadas em forma de rvore. Neste passo, cada linha retorna uma quantidade de tuplas.
51
SQL Execution Engine SQL Execution Engine o componente que opera sobre o plano de execuo gerado para a consulta, produzindo o resultado da consulta. Cada linha produzida pelo Row Source Generator executada pelo SQL Execution Engine.
3.7.2 Processamento de Consultas Distribudas no SQL Server O SQL Server 2000 suporta o processamento de consultas distribudas utilizando o OLE DB e criando os linked servers, o OLE DB necessrio para que os Linkeds servers possam se comunicar entre si e permite que aplicaes SQL Server acessem dados distribudos homogneos ou heterogneos [SQL Server 2000]. O OLE DB composto de trs elementos, o OLE DB, OLE DB data source e o OLE DB provider: OLE DB gerencia e interage com o data source ; OLE DB data source identifica o banco de dados especfico acessado atravs do OLE DB, alm de permitir que os rowsets sejam referenciados atravs de comandos SQL ; OLE DB provider serve para interagir com os vrios formatos de arquivos; O OLE DB expe os dados em objetos na forma de tabela chamados rowsets, o SQL Server permite que estes rowsets possam ser referenciados dentro de comandos SQL como se eles fossem uma tabela SQL Server, assim dados localizados em banco de dados externos podem ser acessados diretamente atravs de comandos SQL. Quando realizada uma consulta distribuda atravs de um linked server, basicamente o SQL Server decompe o comando e envia as requisies dos rowset ao OLE DB.
Otimizao de Consulta O SQL Server pode otimizar uma consulta utilizando store procedures, visto que as stores procedures j so compiladas e armazenadas no banco de dados, assim so executadas mais rapidamente j que o processo de compilao e anlise no precisa ocorrer no momento em que a store procedure chamada; ou tambm atravs do processamento paralelo
52
de consultas, em que diferentes partes de uma consulta so executadas separadamente em diferentes servidores [SHAPIRO, 2002].
Execuo remota da consulta O SQL server tenta enviar o mximo da execuo de uma consulta distribuda, ou seja, aquelas que provavelmente iro gerar um nmero considervel de linhas, para serem processadas no servidor remoto, assim uma consulta SQL que acessa somente tabelas remotas armazenadas na fonte de dados do provedor extrada da consulta distribuda original e executada no provedor [SHAPIRO, 2002]. Com isso o nmero de dados retornados do provedor reduzido, visando diminuir ao mximo o trfego de dados atravs da rede, alm de permitir ao provedor usar seus ndices disponveis para a execuo da consulta.
Acesso Indexado O SQL Server pode executar estratgias que envolvem usar os ndices dos servidores para avaliar predicados e executar operaes de ordenao em tabelas remotas [SHAPIRO, 2002].
Plano de Execuo Para escolher o melhor plano de execuo de uma consulta, o SQL Server baseia-se nas informaes dos valores das estatsticas de distribuio, as estatsticas de distribuio so locais e mantidas para colunas e ndices, assim, com estas informaes o processador de consulta determina a melhor estratgia para realizar a consulta. Todos ndices possuem estatstica de distribuio que descreve a seletividade e distribuio das chaves indexadas. Quando um ndice criado, o SQL Server automaticamente armazena os valores da estatstica de distribuio para a coluna indexada. O otimizador de consulta utiliza estas estatsticas para estimar os custos da realizao da consulta. O SQL Server possui um Query Governor que determina os custos de uma consulta em relao ao tempo, assim, se um plano de execuo for menor que um tempo prdefinido, medido em segundos, este plano ser escolhido, por outro lado, possvel estabelecer um valor mximo para a execuo de uma consulta. Se o custo de uma consulta for maior que
53
este limite, a mesma no ser executada [SHAPIRO, 2002]. Para configurar o tempo prdefinido do Query Governor utilizado o seguinte comando:
SET QUERY_GOVERNOR_COST_LIMIT value
Armazenamento em cache e reutilizao de planos de execuo A maioria das instrues SELECT idntica ou podem diferir somente nos valores especificados na expresso de pesquisa. Considere as instrues SELECT a seguir [SQL Server 2000]:
SELECT * FROM PEDIDOS WHERE VALORTOTPED < 400 SELECT * FROM PEDIDOS WHERE VALORTOTPED < 10000 SELECT * FROM PEDIDOS WHERE VALORTOTPED < ?
Um otimizador eficiente deduzir que as instrues SELECT precedentes provavelmente resultaro nos mesmos planos de execuo ou que sero muito semelhantes. Portanto, no faz sentido o SQL Server compilar um plano de execuo se um deles j tiver sido compilado anteriormente. Assim o SQL Server mantm um pool de memria, chamado de cache de procedimento, que usado para armazenar tanto os planos de execuo como os buffers de dados. O tamanho do pool de memria varia de sistema para sistema e tambm se altera de acordo com o estado do sistema.Qualquer usurios pode reutilizar os planos de execuo do SQL Server. A qualquer momento uma instruo pode ser enviada ao servidor, este primeiro verificar a cache de procedimentos para verificar se existe um plano de execuo que satisfaa a instruo SQL. A economia surge pela eliminao da necessidade de desenvolver um novo plano de execuo.
54
3.8
PROCESSAMENTO DISTRIBUDO DE TRANSAES
3.8.1 Processamento Distribudo de Transao no Oracle O Oracle automaticamente controla e monitora commits e rollbacks de uma transao distribuda e mantm a consistncia e integridade das bases de dados utilizando um mecanismo de gerenciamento de transao como o protocolo Two-Phase Commit(2PC). Este mecanismo totalmente transparente ao usurio. Exemplo de uma transao distribuda, sendo executada no site FILIALA.DC.UEL.BR:
BEGIN UPDATE scott.estoque SET preco_venda = preo_venda*1,1 UPDATE scott.estoque@filiala.dc.uel.br SET preco_venda = preo_venda*1,2 UPDATE scott.estoque@filialb.dc.uel.br SET preco_venda = preo_venda*1,3 END; COMMIT;
Para garantir a consistncia e integridade de uma transao distribuda, o Oracle utiliza o 2PC da seguinte forma: na primeira fase, a fase de preparao, o coordenador global (site que iniciou a transao) envia uma mensagem a todos os sites participantes da transao para que eles fiquem preparados para realizar commit da transao e fica aguardando que cada um responda a esta solicitao, em que os sites podem enviar trs tipos de respostas: Preparado: Todos os dados referenciados no site pela transao j foram modificados e o site est pronto para finalizar a transao; Somente para leitura: Os dados no podem ser modificados, pois somente para leitura, neste caso ele no participa mais da transao; Abortar: Ocorreu um erro e o site no est preparado para terminar a transao com xito; Na segunda fase, a fase do commit, quando todos sites responderem que esto preparados, o coordenador geral envia uma mensagem para que todos possam efetuar o commit da transao, ou seja, em cada site o SGBD faz o commit da parte local da transao. Assim, ao final do Two-Phase commit os dados em todos os sites sero consistentes.
55
3.8.2 Processamento Distribudo de Transao no SQL Server Uma transao distribuda aquela em que envolve recursos de 2 ou mais sites. O Sql Server 2000 suporta transaes distribudas, permitindo que usurios criem transaes que atualizem vrios bancos de dados Sql Server e outras fontes de dados [SHAPIRO, 2002]. Para iniciar uma transao distribuda utilizada a instruo BEGIN DISTRIBUTED TRANSACTION. Exemplo:
BEGIN DISTRIBUTED TRANSACTION UPDATE estoque SET preco_venda = preco_venda= preco_venda*1.1 UPDATE "CPO-LC39".filiala.dbo.estoque SET preco_venda = preco_venda= preco_venda*1.1 COMMIT TRAN
Para realizar uma transao distribuda preciso utilizar o MS DTC (Distributed Transaction Coordinator), que um gerenciador de transaes que coordena o commit em uma transao distribuda entre os servidores participantes na transao. O MS DTC requer que o participante que iniciou a transao seja o nico que pode chamar o commit. Uma transao distribuda envolve: Gerenciador de recurso: O software que controla cada recurso envolvido em uma transao distribuda. Cada resource manager deve estar apto a realizar commit ou rollback em suas transaes locais em conjunto com todos os outros resource managers na transao distribuda. Os resource managers so representados pelos linkeds servers Gerenciador de transao: o software que controla o commit e o rollback das transaes distribudas. Ele coordena as fontes de recursos para garantir que todas as transaes iro ser comitadas ou ser dado rollback em todas elas. O servio Microsoft Distributed Transaction Coordinator (MS DTC) opera como um gerenciador de transaes e deve estar disponvel em cada um dos participantes da transao.
56
O DTC mantm um arquivo de log de transao em disco no sistema local. O arquivo de log de transao contm as seguintes informaes: Nmero de identificao da transao; Lista de participantes da transao; Indica o resultado da transao e quais dos participantes e DTC's responderam ao resultado; Para garantir a consistncia de uma transao distribuda, o SQL Server utiliza o protocolo Two-Phase Commit.O MS DTC usa o 2PC da seguinte maneira: O gerente de transao pede a cada gerente de recurso para se preparar para consolidar a transao, se todos se prepararem com sucesso, ento o gerente de transao transmite a deciso commit, caso algum gerente de recurso no puder se preparar, o gerente de transao transmite uma deciso de abortar a todos envolvidos na transao. Quando um os componentes envolvidos estiver preparado, mas ainda no realizou commit ou rollback, a transao definida como duvidosa. Caso uma transao duvidosa persistir por muito tempo, o operador de sistema pode forar a transao para consolidar ou abortar Se ocorrer falha em algum participante ou no DTC, as transaes duvidosas sero recuperadas quando conectarem novamente.
3.9
CONTROLE DE CONCORRNCIA
3.9.1 Controle de Concorrncia no Oracle O Oracle mantm a concorrncia, integridade e consistncia dos dados utilizando um modelo de controle de concorrncia multiverso, alm de vrios tipos de bloqueios e transaes. O controle de concorrncia multiverso armazena diferentes verses do mesmo registro, assim h uma melhora no acesso concorrentes aos dados contidos no banco de dados. A consistncia em uma transao garantida pelo Oracle atravs de informaes que so armazenadas em segmentos de Rollback. O segmento de Rollback uma poro do banco de dados que registra as imagens dos dados antes de serem modificados por uma transao, permitindo que as alteraes sejam desmanchadas (ou desfeitas) sob certas circunstncias .
57
3.9.1.1 Controle de Concorrncia no SQL Server O SQL Server trabalha com o controle de concorrncia pessimista e o otimista, no qual o controle de concorrncia pessimista o padro do SQL Server [SQL Server 2000]. Para configurar um protocolo de concorrncia usando bloqueio, o SQL server permite que o usurio configure o protocolo de acordo com suas necessidades. O SQL Server tambm fornece bloqueio de nvel de vrias granularidades, em que a granularidade pode ser um registro, uma tabela, todo o banco de dados, etcConcluso
3.10 RESOLUO DE CONFLITOS 3.10.1 Resoluo de conflitos no Oracle Nos ambientes de replicao em que possvel atualizar dados tanto nos sites mestres quanto no sites de views materializadas existe a possibilidade de que ocorram conflitos de replicao quando, por exemplo, duas transaes provenientes de sites diferentes atualizam a mesma linha quase ao mesmo tempo.Quando ocorrem conflitos, preciso que sejam designados mecanismos de resoluo de conflitos. A replicao avanada oferece vrios mtodos de resoluo de conflitos, em que so utilizados grupos de colunas para detectar e resolver conflitos de atualizao, em que um grupo de colunas pode ser uma nica coluna, algumas colunas ou tambm todas as colunas de uma tabela. O mecanismo de deteco de conflito detecta um conflito de atualizao atravs de um grupo de coluna, conseqentemente, todas as colunas deveriam fazer parte de algum grupo de colunas, entretanto, para no ser preciso atribuir todas as colunas a um grupo de colunas, possvel designar ao mecanismo de resoluo de conflito, somente as colunas que foram definidas a um grupo de coluna.
Designando um Mtodo de Resoluo de Conflito Quando alguma atualizao pode causar um conflito, o Oracle detecta automaticamente este conflito no site mestre da replicao, mas os sites de view materializada no
58
conseguem detectar ou resolver nenhum conflito, sendo assim os conflitos sero detectados e resolvidos no site metsre da view materializada. Quando um conflito de dados detectado, primeiro o Oracle aplica o mtodo de resoluo de conflitos e tenta resolver o conflito, caso o conflito no seja resolvido, ele guardado em uma fila de erros no site onde ocorreu, ento, o administrador do banco de dados responsvel por resolver manualmente esse conflito.
Tipos de mtodos de resoluo de conflitos O Oracle oferece vrios tipos de mtodos de resoluo de conflito, como:
Timestamp No mtodo de resoluo de conflito de timestamp necessrio que a tabela destino possua uma coluna timestamp, para que seja inserido um valor timestamp quando uma linha for inserida ou atualizada. O mtodo timestamp dividido em dois tipos: o Primeiro e ltimo timestamp. No mtodo primeiro timestamp as alteraes mais antigas so sempre aplicadas, j no mtodo do ltimo timestamp as alteraes mais recentes sempre sero aplicadas. Para que o mtodo de Timestamp funcione corretamente, necessrio que a definio de tempo entre os computadores seja sincronizada e que haja um campo timestamp e um gatilho para registrar automaticamente o timestamp.
Mtodo de Sobregravao e Descarte No mtodo de Sobregravao o valor atual do site destino substitudo pelo novo valor do site original, j no mtodo de Descarte, o novo valor do site original ignorado. Como neste mtodo de sobregravao e descarte os valores dos sites de origem ou de destino so ignorados, no possvel garantir a convergncia com mais de um site mestre.
59
Mnimo e Mximo No mtodo de valores mnimos, se o novo valor da coluna designada no site original for menor que o valor atual no site de destino, os valores do grupo de colunas no site original sero aplicados ao site de destino. No mtodo de valores mximos, se o novo valor da coluna designada no site original for maior que o valor atual no site de destino, os valores do grupo de colunas no site original sero aplicados ao site de destino.
Grupo de prioridades Os grupos de prioridades permitem designar um nvel de prioridade a cada valor possvel de uma coluna especfica. Se o Oracle detectar um conflito, ele substituir a tabela cuja coluna prioridade tem um valor mais baixo pelos dados da tabela com valor de prioridade mais alto.
Prioridade de site No mtodo de resoluo de conflitos por prioridade de site preciso designar uma coluna de sites na tabela destino para registrar o valor do site quando uma linha for inserida ou atualizada. A prioridade de site uma forma especializada de grupos de prioridades. Sendo assim, muitos dos procedimentos associados prioridade de site se comportam de maneira semelhante aos procedimentos associados a grupos de prioridades. Em vez de resolver conflitos com base na prioridade do valor de um campo, o conflito resolvido com base na prioridade dos sites envolvidos no seu ambiente replicado.
Aditivo e Mdia Os mtodos aditivo e mdio funcionam com grupos de colunas que consistem somente em uma nica coluna numrica. No mtodo aditivo o valor original adicionado ao valor de destino, j no mtodo mdio, calculada a mdia entre o valor original e o valor de destino.
60
3.10.2 Resoluo de Conflitos no SQL Server O SQL Server 2000 utiliza os resolvedores para solucionar os possveis conflitos que ocorrerem, quando ocorre algum conflito o resolvedor chamado e ento resolve o conflito de acordo com o mtodo de resoluo de conflito especificado. O SQL Server disponibiliza vrios mtodos de resoluo de conflitos, em que o padro o mtodo de prioridades, em que so atribudas prioridades a cada um dos servidores, assim quando dois ou mais servidores atualizarem o mesmo dado, ser mostrado o dado atualizado pelo servidor que possui a maior prioridade (1 tem maior prioridade que o 2), alm deste mtodo, existem outros, alguns deles muito semelhante ao do Oracle, em que os mtodos semelhantes aos do Oracle no sero detalhados novamente. Entre os mecanismos de resoluo de conflitos que so semelhantes aos utilizados pelo Oracle esto: Aditivo e mdia, Timestamp que aqui chamado de DATETIME e Mnimo e mximo.
61
CONCLUSO Sistemas Distribudos representam, sem dvida, uma alternativa interessante
para aumentar o desempenho dos sistemas de banco de dados. A evoluo dos sistemas de transmisso de dados tem possibilitado que a tecnologia de bancos de dados distribudos venha cada vez mais sendo utilizada nas organizaes, resultando numa evoluo crescente das redes de computadores. A possibilidade de dispor dos dados mais prximos de onde sero utilizados, com um grau de controle de cada n sobre os dados locais - autonomia local, a maior vantagem dos bancos de dados distribudos. No entanto, deve considerar a complexidade adicionada a coordenao entre os ns, que pode ser apontada como a principal desvantagem de sistemas de banco de dados distribudos.
4.1
RESULTADOS DO ESTUDO COMPARATIVO Entre os SGBDDs estudados, o Oracle possu uma certa vantagem em rela-
o ao SQL Server por possuir algumas caractersticas e mecanismos que facilitam e melhoram o funcionamento e a manipulao de dados em um sistema de banco de dados distribudo. Em relao aos tipos de replicaes, o Oracle possui uma maior diversidade. O SQL Server fornece trs tipos de replicao: Snapshots, Transacional e Merge, mas em nenhuma delas possvel configurar uma replicao de dados utilizando vrios servidores publicadores, ou seja, permite apenas que se tenha apenas um publicador e vrios assinantes, assim caso o publicador esteja indisponvel os dados entre todos os assinantes podero no ser consistentes. J o Oracle permite que se tenha uma replicao entre vrios servidores mestres atravs da replicao Multimestre, em que todos os mestres se comunicam entre si, alm disso, permite que cada mestre tenha vrios servidores de views materializadas atravs da replicao Hbrida, obtendo assim uma maior flexibilidade na distribuio de dados. Para realizar a comunicao entre os servidores participantes na replicao de dados, o Oracle possui caractersticas que tornam esta tarefa mais simples, pois ele trata um banco de dados remoto como se fosse local, precisando apenas configura-lo atravs do Database Link. J no SQL Server preciso realizar trs operaes, primeiro necessrio criar um linked server, depois adicionar um login para se conectar no servidor e por ltimo criar uma per-
62
misso para acessar os dados no servidor remoto. Com isso, realizar a comunicao entre dois servidores do tipo SQL Server uma tarefa mais trabalhosa. A manipulao de dados atravs do Oracle facilitada atravs da transparncia de nome, feita atravs dos sinnimos, com isso para referenciar um banco de dados remoto no preciso mencionar a localizao dos dados. No SQL Server para referenciar um banco de dados remoto preciso utilizar um nome composto de quatro partes, assim, em um sistema de banco de dados distribudos em que preciso acessar vrios bancos de dados remotos, o SQL Server exige mais trabalho. O processamento de consultas e transaes distribudas foi um item de difcil avaliao, pois s foi possvel compreender o seu funcionamento atravs dos manuais dos fabricantes, assim no foi possvel realizar uma avaliao mais crtica. No controle distribudo de concorrncia o Oracle mais eficiente, pois possui um mecanismo de controle de concorrncia Multiverso, permitindo que sejam armazenadas vrias verses de um dado. Com isso, conclui-se que em relao distribuio de dados, o Oracle ter uma certa vantagem em relao ao SQL Server, por outro lado preciso levar em conta um outro fator, o custo de implantao de cada um destes sistemas, mas este fator est fora do contexto deste trabalho.
63
REFERNCIAS [ZSU, 1999] ZSU, M.T. e VALDURIEZ, P. "Princpios de Sistemas de Banco de Dados Distribudos", Segunda edio.Prentice Hall, 1999. [ELM, 2002] ELMASRI, R. e NAVATHE, S. "Sistemas de Banco de Dados - Fundamentos e Aplicaes", Terceira edio, LTC, 2002. [COU, 1984] COUCEIRO, L. A.; BARRENECHA, H. F. "Sistemas de Gerncia de Banco de Dados Distribudos". Rio de Janeiro: Livros Tcnicos e Cientficos Editora, 1984. [CONN, 1999] CONNOLY, T. ; BEGG, C. "Database Systems - A Pratical Approach to Design, Implementation and Management", Segunda edio, 1999. [MIT, 1995] MITCHELL, Alex. "Concurrency Control in CSCW Systems", 1995. [DEMP, 1997] DEMPSTER, Robert. "Distributed Systems: Distributed Transactions", 1997. [MATT, 1998] MATTOSO, Marta. "Bancos de Dados Distribudos". Universidade Federal do Rio de Janeiro, 1998. [NOEL, 1998] NOEL, Rick. "Scale Up in Distributed Database". Renselaer Polytechnic Institute, 1998. [ZAS, 1997] ZASLAVSKY, A. "Distributed Database Overview", 1997. [REICH, 1997] REICH, Sigi. "Synchronisation in Distributed Systems". Distributed Computing and Networks Center, 1997. [DATE, 1991] DATE, C. J. "Introduo a Sistemas de Bancos de Dados". Rio de Janeiro: Campus, 1991 [DATE, 1988] DATE, C.J. "Banco de Dados - Tpicos Avanados", 2 Reempresso, Ed.Campus, 1988 [MOURA, 1985] CASANOVA, M. A.; MOURA, A. V. "Princpios de Sistemas de Gerncia de Bancos de Dados Distribudos". Rio de Janeiro: Campus, 1985
64
[HOPKINS, 1998] HOPKINS, M. e THOMAS, D. "Replicao de Dados com Interbase/Firebird" ,Borland Developers Conference 1998. [SHAPIRO,2002] SHAPIRO R., Jeffrey. "SQL Server 2000 Completo e Total"'. So Paulo: Makron Books, 2002. [OVIATT, 1997] OVIATT, Lori. "Treinamento do Microsoft SQL Server". Volume 1. USA: Microsoft Press. 1997. [SQL Server, 2000] "SQL Server Book On-Line". Microsoft SQL Server 2000. [GRAY, 1989] GRAY J. "Transaparency in its Place - The Case Against Transparent Acess to Geographically Distributed Data", Relatrio tcnico TR89.1, Cupertino. Calif.:Tandem Computer Inc.,1989 [SWAMI, 1989] SWAMI A. "Optimization of Large Join Queries:combining heuristics and combinatorial techniques". Em Proc. ACM SIGMOD Int. Conf. on Management of Data, junho de 1989, pp.367-376. [IOANNIDIS, 1987] IOANNIDIS Y.E., WONG E. "Query optimization by simulated annealing". Em Proc. ACM SIGMOD Int. Conf. on Management of Data, junho de 1987,pp. 9-22. [BALTER, 1982] BALTER R., BERARD P. e DECITRE P. "Why Control of Concurrency Level in Distributed System Is More Important Than Deadlock Management". Em Proc. ACM SIGACT-SIGOPS Symp. on Principles of Distributed Computing, agosto de 1982, pp. 183193. [TAN, 1992] TANENBAUM,Andrew S. "Modern Operating Systems". Prentice Hall, New Jersey, 1992. [REE, 1983] REED, D. P. "Implementing Atomic Actions on Decentralized Data"'. ACM Trans. on Computer Systems, vol. 1, 1983. [ORA1] PRATT, M. "Oracle9i Server Distributed System, Volume I". Oracle Corporation [ORA2] PRATT, M. "Oracle9i Server Distributed System, Volume II". Oracle Corporation [ORA3] "Ajuda" do Oracle 9i Entreprise Edition.
65

155

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

155

Enviado por

Direitos autorais:

Formatos disponíveis

Departamento de Computao Trabalho de Concluso de Curso

ERIC TERUO SHIBAYAMA

Estudo Comparativo entre Bancos de Dados Distribudos

ERIC TERUO SHIBAYAMA

Estudo Comparativo entre Bancos de Dados Distribudos

ERIC TERUO SHIBAYAMA

Estudo Comparativo entre Bancos de Dados Distribudos

____________________________________ Prof. Ms. Evandro Bacarin Universidade Estadual de Londrina

____________________________________ Prof. Ms. Rodolfo Miranda de Barros Universidade Estadual de Londrina

Londrina, ___ de ___________ de 200_

Palavras-chave: Banco de dados, distribudos, Oracle, SQL Server.

Keywords: Database, Distributed, Oracle, SQL Server.

LISTA DE ABREVIATURAS E SIGLAS

BDD SGBDD EIL ECG ECL EE D/DG D/DL ACID MS DTC

INTRODUO Um banco de dados um sistema de armazenamento de dados, ou seja, um

BANCO DE DADOS DISTRIBUIDOS

Figura 1: Banco de dados e redes de computadores

Figura 2: Esquema de um BD centralizado(esq.) e de um BD distribudo(dir.)

TRANSPARNCIA DE DADOS A transparncia oculta dos usurios os detalhes de implementao. Um sis-

Figura 3: Arquitetura de banco de dados distribudo

O monitor de execuo distribuda coordena a execuo distribuda da solicitao do usurio.

Figura 4: Componentes de um SGBDD Distribudo

ESTRATGIAS DE DISTRIBUIO DE DADOS

2.5.2.1 Tipos de Fragmentao Existem trs tipos de fragmentao:

A reconstruo de uma relao r pode ser obtida tomando a unio de todos os

Exemplo de fragmentao horizontal:

Figura 5: Relao inteira(PROJ) e uma relao fragmentada horizontalmente(PROJ1)

Exemplo de fragmentao vertical:

Figura 6: Relao inteira(PROJ) e uma relao fragmentada verticalmente(PROJ2)

Figura 7: Relao inteira (PROJ) e uma relao fragmentada (PROJ3)

PROPAGAO DE ATUALIZAES Como em um sistema de banco de dados distribudos os dados geralmente

Figura 8: Tabela FUNC (dir) e PAG(esq)

Os resultados da juno e da semijuno so mostrado na figura 9:

Figura 9: Resultado da juno(dir) e da semijuno(esq)

CONTROLE DISTRIBUDO DE CONCORRNCIA O mecanismo de controle de concorrncia de um SGBD distribudo assegura

A criao do grupo de views materializadas pode ser feita como abaixo:

TRANSPARNCIA DE DADOS Os SGBDDs devem disponibilizar mecanismo que tornem a distribuio de

CREATE PUBLIC SYNONYM emp FOR scott.emp@sales.us.americas.acme_auto.com

Atravs dos sinnimos possvel realizar esta consulta da seguinte maneira:

ARQUITETURA Em um sistema de banco de dados distribudos existe a necessidade de que

CREATE DATABASE LINK teste.dc.uel.br USING 'teste.dc.uel.br'

sp_addlinkedserver 'COP-LC32', ' SQL Server'

sp_addlinkedsrvlogin 'COP-LC32', 'false', NULL, 'SA', ''

sp_serveroption 'COP-LC32', 'data access', true

ESTRATGIAS DE DISTRIBUIO DE DADOS

CREATE SNAPSHOT "ERIC"."ESTOQUE" AS SELECT * FROM "ERIC"."ESTOQUE"@MATRIZ.DC.UEL.BR WHERE "FILIAL"='FILIAL A'

44 CREATE SNAPSHOT "ERIC"."ESTOQUE" AS SELECT COD_PROD", "FILIAL", "QUANTIDADE" FROM "ERIC"."ESTOQUE"@MATRIZ.DC.UEL.BR

CREATE SNAPSHOT "ERIC"."ESTOQUE" AS SELECT COD_PROD", "FILIAL", "QUANTIDADE"

WHERE "FILIAL"='FILIAL A'

@publication = 'Matriz', @article = @filter_clause = 'filial=''FILIAL A'''

45 sp_articlecolumn @publication = N'Matriz1', @article = N'fabricante', @column = N'nome, @operation = N'add'

sp_articlefilter @publication = 'Matriz', @filter_clause = 'filial=''FILIAL A'''

demais servidores, os SGBDDs utilizam vrios mecanismos de propagao de atualizaes.

CREATE SNAPSHOT nome REFRESH FAST

BEGIN DBMS_REFRESH.MAKE( name => NomedoGrupo, ... ); END

Exemplo de como configurar o tipo de propagao das atualizaes:

SELECT DNAME, ENAME FROM DEPT, EMP@REMOTE WHERE DEPT.DEPTNO = EMP.DEPTNO

O otimizador compara os custos de cada plano e escolhe o de menor custo;

Figura 10: Cost-Based Optimization

SET QUERY_GOVERNOR_COST_LIMIT value

PROCESSAMENTO DISTRIBUDO DE TRANSAES

CONCLUSO Sistemas Distribudos representam, sem dvida, uma alternativa interessante

Você também pode gostar

Londrina, _ de _________ de 200_