Oracle Transparent Gateways
Propaganda
Pontifícia Universidade Católica - PUC-Rio Tecnólogo em Processamento de Dados - Bacharel em Informática Construção de Aplicações em Ambiente Cliente-Servidor Professora: Elvira Maria Antunes Uchôa Trabalho 1 – Sistemas de Banco de Dados Distribuídos SGBD Comercial => Oracle Alunos: Adriano Rodrigues Gonçalves Adriano Souza Barroso Elisangela Assis de Oliveira 9915213-1 9620046-9 9824362-5 Data de entrega e apresentação : 30 de abril de 2002. Parte 1 - Projeto de BD-Distribuído a) Suporte à fragmentação (horizontal, vertical, híbrida) Oracle disponibiliza fragmentações juntamente com mecanismos de replicação b) Mecanismos de replicação Replicação – cópia Replicação é o processo de esquema de copia e manutenção de objetos em um banco de dados múltiplo que constitui um sistema de banco de dados distribuído. Uma replicação pode normalmente acessar um database local ao invés de acessar um servidor remoto para minimizar o trafego de rede e alcançar a melhor performance. Além disso, a aplicação pode continuar a funcionar se o servidor local falha enquanto outros servidores com dados replicados permanecem acessíveis. Oracle suporta duas formas de replicação: replicação básica e avançada. Replicação básica - snapshot Com a replicação básica, replicas de dados provêm acesso de read-only (somente leitura) para a tabela originária de um site mestre. Aplicações podem perguntar dados de replicas de dados locais para evitar acesso a rede sem se importar com a disponibilidade de rede. Entretanto, aplicações através do sistema devem acessar dados no primeiro site quando atualizações são necessárias. Servidor Oracle pode suportar replicação básica, ambientes de replicação read-only usando read-only tabelas de snapshot. Replicação avançada A replicação avançada do Oracle caracteriza a extensão das capacidades da replicação básica por permitir que as aplicações possam atualizar replicas através do sistema de banco de dados replicado. Com replicação avançada, quaisquer replicas de dados no sistema podem prover acesso de leitura e atualização aos dados da tabela. Servidores de banco de dados participativo Oracle automaticamente trabalha para converger o dado de todas as replicas de uma tabela, e garante a consistencia da transação global e a integridade do dado. Conceitos de replicação básica Ambiente de replicação básica suporta aplicações que requerem acesso read-only para tabelas de dados originadas de um primeiro site. 1 Snapshots de tabelas read-only Um snapshot de tabela read-only é uma cópia local de uma tabela originária de uma ou mais tabelas mestres remotas. Uma aplicação pode consultar o dado em um snapshot de tabela read-only, mas não pode inserir, atualizar ou deletar linhas de um snapshot. Arquitetura de snapshot read-only Oracle suporta replicação de dados básica com seu mecanismo de snapshot de tabela. As seções seguintes explicam a arquitetura de um simples snapshot de tabela read-only Um snapshot definido por uma query A estrutura lógica dos dados de um snapshpt de tabela é definida por uma query que referencia dados em um ou mais tabelas mestres remotas. Uma query de definição de um snapshot determina quais dados o snapshot vai conter. Um snapshot definido por query deve ser tal que cada linha no snapshot corresponda diretamente a uma linha ou a parte de uma linha em uma singular tabela mestre. Especificamente, a query definidora de um snapshot não deve conter uma clausula distinct ou função agregada, uma clausula de GROUP BY or CONNECT BY, join, tipos de subquery restritas, ou uma operação. O exemplo a seguir mostra uma definição simples de snapshot de tabela CREATE SNAPSHOT sales.customers AS SELECT * FROM [email protected] Nota: em todos os caso, a query definidora de um snapshot deve referenciar todas as chaves primárias de colunas na tabela mestre. A query definidora do snapshot pode incluir tipos restritos de subqueries que referenciem múltiplas tabelas para filtrar linhas do snapshot da tabela mestre. Uma subquery de um snapshot pode ser usada para criar snapshot que “walk up” a muitas-para-uma referencia de uma filha para tabelas parentes que devem envolver múltiplos níveis. O exemplo a seguir cria um snapshot simples com subquery CREATE SNAPSHOT sales.orders AS SELECT * FROM [email protected] o WHERE EXISTS ( SELECT c_id FROM [email protected] c WHERE o.c_id = c.c_id AND zip = 19555); Snapshots atualizáveis Um dado de snapshot não necessariamente corresponde ao dado corrente da sua tabela mestre. Um snapshot de tabela é uma expressão de uma transação consistente de seu dado mestre com aquele dado existente em um específico ponto no tempo. Para manter um dado de snapshot relativamente corrente com o dado do seu mestre, Oracle periodicamente atualiza o snapshot. Um snapshot atualizável é uma eficiente operação de procedimentos que faz com que o snapshot reflita o estado mais atual do seu mestre. Você deve decidir como e quando atualizar cada snapshot para fazê-lo mais atual possível. Por exemplo, snapshots originam-se de tabelas mestres que aplicações freqüentemente atualiza usualmente requer freqüentes atualizações. Em contraste, snapshots dependem relativamente de tabelas mestres estáticas usualmente requerem infrequentemente atualizações. Em resumo, você deve analisar as características e exigências da aplicação para determinar o intervalo apropriado de atualização do snapshot. 2 Para atualizar snapshots, Oracle suporta diferentes tipos de atualizações, “completa” e “rápida” atualizações de grupo de snapshot, bem como atualizações “manual” e “automática”. Atualização completa Para executar uma atualização completa de um snapshot, o servidor que gerencia o snapshot executa a query definidora do snapshot. O resultado da query substitui o dado existente no snapshot para atualizar o snapshot. Oracle pode executar uma atualização completa para qualquer snapshot. Atualização rápida Para executar uma atualização rápida, o servidor que gerencia o snapshot primeiro identifica as mudanças que ocorreram no mestre desde a mais recente atualização do snapshot e então as aplica para o snapshot. Atualizações rápidas são mais eficientes do que completas quando existem poucas alterações para o mestre porque servidores participantes e rede replicam menos dados. Atualizações rápidas estão disponíveis para snapshots somente quando a tabela mestre tem um snapshot de log. Snapshot logs – replicação transacional Quando uma tabela mestre corresponde a um ou mais snapshots, cria um registro de snapshot para a tabela de maneira que atualizações rápidas de snapshot sejam uma opção. Um snapshot log de tabela mestre trilha uma atualização rápida para todos os snapshots correspondentes-somente um snapshot log é possível por tabela mestre. Quando um servidor executa uma atualização rápida para um snapshot, ele usa dados do seu snapshot log de tabela mestre para atualizar o snapshot eficientemente. Oracle automaticamente depura atualização específica do dado de um snapshot log depois de todos os snapshot executarem atualizações tais que o log do dado é não muito necessário. Atualização automática de snapshot Quando se cria um grupo de snapshot atualizável, administradores usualmente configuram o grupo então o Oracle automaticamente atualiza seus snapshots. De outro modo, administradores teriam condições de realizar atualização manualmente quando necessário. Tipo de atualizações Por default, Oracle tenta executar uma atualização rápida de cada snapshot em um grupo de atualização. Se Oracle não pode executar uma atualização rápida para um snapshot individual, por exemplo quando uma tabela mestre não tem snapshot log, o servidor executa uma atualização completa para o snapshot. Atualização manual de snapshot Programadas, atualizações automáticas de snapshot podem não ser adequadas. Por exemplo, imediatamente acompanhando um volume de dado carregado em uma tabela mestre, snapshots dependentes não mais representará o dado da tabela mestre. Ao invés de esperar pela próxima programação automática de atualizações de grupo, você deve querer manualmente atualizar grupos de snapshot dependentes para imediatamente propagar as novas linhas de uma tabela mestre para snapshots associados. Snapshots complexos 3 Quando a query que define um snapshot contém um distinct, ou uma função agregada, uma cláusula group by ou connect by, join, tipos de subqueries restritas, ou uma operação, o snapshot é um snapshot complexo. exemplo CREATE SNAPSHOT scott.emp AS SELECT ename, dname FROM [email protected] a, [email protected] b WHERE a.deptno = b.deptno SORT BY dname A primeira desvantagem de um snapshot complexo é que Oracle não pode executar uma atualização rápida do snapshot, Oracle somente executa atualização completa de um snapshot complexo. Consequentemente o uso de snapshots complexos pode afetar o desempenho da rede durante as atualizações completas de snapshot. ROWID snapshots Snapshot de Chave primária são o default para Oracle. Oracle baseia um snapshot de chave primária sobre a chave primária de sua tabela mestre. Por causa desta estrutura, você pode: Reorganizar as tabelas mestres de um snapshot sem a atualização completa de um snapshot Criar um snapshot com uma query que inclua tipos de queries restritas. Oracle também suporta ROWID snapshots baseados nos identificadores físicos da linha ou "ROWIDs" de linhas na tabela mestre. Somente usa-se ROWID snapshots para snapshots de tabelas mestres no banco de dados Oracle 7.3 e não quando cria novos snapshots de tabelas mestres em banco de dados Oracle 8. Nota: para suportar um snapshot ROWID, Oracle cria um índice adicional sobre a tabela base do snapshot com o nome I_SNAP$_snapshotname Criando sites de snapshot ou slave A página inicial do setup de replicação sugere a você para indicar qual tipo de ambiente de replicação que você quer realizar. 1. Select Setup Snapshot Sites. 2. Click Next. Especificar o site mestre The next page of the wizard asks you to identify the master site for the new snapshot site(s) that you will be creating. 1. Type the name of the master site (for example, DBS1). 2. Type the password for the SYSTEM user at the master site. Clone de snapshot para ambientes de replicação básica para reduzir um overhead de rede associado com a criação de sites de snapshot em muitos bd, você pode realizar snapshot “cloning” pelos passos seguintes: 4 1 – criar o snapshot e o grupo correspondente de atualização que você quer clonar no bd separado do bd que contém as tabelas mestres. o bd no qual você cria snapshot das tabelas mestres é o exemplo guia de snapshot para o processo de clonagem. 2- no bd que contém o exemplo guia de snapshot, exporte os esquemas contendo os snapshots e grupos de atualização que você quer clonar para outros bds de snapshot. o utilitário de exportação não suporta a exportação individual de snapshots. por isso, você deve exportar snapshots no nível de esquema. 3-prepare todos os outros bd de snapshots para receber os snapshots do bd mestre. nota: para ter certeza que você preparou um snapshot apropriado, conecte cada snapshot no esquema do bd.m a seguir, execute a definição das queries do snapshot proposto para certificar que eles executarão sem erros. adicionalmente, certifique-se que cada novo bd de snapshot tenha espaço livre suficiente para suportar novos snapshots. 4- a cada novo bd de snapshot, importe os esquemas de snapshots que foram exportados do bd que contém o exemplo guia de snapshot. este cria e distribui os mesmos snapshot que foram exportados do bd de snapshot guia. 5-execute uma rápida atualização do todos os snapshots rapidamente atualizáveis. fazendo assim registros dos novos snapshots no bd mestre.1 os O Oracle também oferece recursos de instanciação offline de sites mestres e sites de snapshot em sistemas de replicação avançada, indicando passo a passo para a implantar o uso destes recursos. instanciação offline de um site snapshot em um ambiente de replicação avançada é aplicável quando você precisa criar uma grande quantidade de site de snapshot, e o tempo requerido para transferir a replicação de dados através da rede para o novo site seria proibitiva. use os passos seguintes para criar um site de snapshot usando instanciação offline No site mestre 1-antes de iniciar, crie um log de snapshot para cada tabela mestre. 2. Create a snapshot of each master group table. Create each snapshot in the same schema as its master table. To accomplish this, each snapshot's name must be different from its corresponding master table. Additionally, the snapshot's defining query must use a loopback database link to reference the master table. For example, to create a snapshot EMPLOYEE of the EMP table in the same database DBS1: 2- crie um snapshot para cada grupo de tabelas do mestre. crie cada snapshot no mesmo esquema da sua tabela mestre. para executar isso, cada nome de snapshot deve ser diferente da sua tabela mestre correspondente. adicionalmente, a query que define o snapshot deve usar um loopback database para referenciar a tabela mestre. por exemplo, criar um snapshot employee da tabela empregados no mesmo bd chamadao dbs1. CREATE SNAPSHOT sales.employee AS SELECT * FROM sales.emp@dbs1 SALES=SITE EMP E EMPLOYEE = TABELA BDS1 = BANCO atenção: antes de criar snapshots, certifique-se que o banco mestre tem amplo espaço de memória. 5 3- como proprietário do esquema, use export para exportar todos os esquemas que contém os snapshots. 4-delete o snapshot no site mestre que foi criado por instanciação offline 5-transferir o arquivo de exportação para o novo site de snapshot Em um novo site de snapshot 1-usando o gerenciador de replição do setup wizard, prepare o novo site de snapshot para se comunicar com o site mestre. 2-usando o gerenciador de replicação de grupo de snapshot wizard, crie um grupo de snapshot vazio para corresponder com o grupo do mestre. não escolha a replicação de nenhum objeto do grupo do mestre. 3-para cada esquema e snapshot, use a procedure dbms_offline_ snapshot.begin_load (gname, sname, master_site, snapshot_oname) para criar snapshots vazios no esquema especificado e grupo de objeto no novo site de snapshot, bem como todos os objetos de suporte necessários. 4- importe somente as tabelas base do snapshot do arquivo de exportação. 5- quando a importação estiver completa, para cada esquema e snapshot, use a procedure dbms_offline_snapshot.end_load (gname, sname, snapshot_oname) Configurações de replicação avançada Oracle suporta os requisitos de um ambiente de replicação avançada usando replicação multimaster bem como sites de snapshots. Replicação multimaster Replicação multimaster Oracle permite múltiplos sites, atuando em iguais camadas, para gerenciar grupos de objetos de banco de dados replicados. Aplicações podem atualizar qualquer tabela replicada em qualquer site em uma configuração multimaster. Figura de Sistema de Replicação Multimaster 6 Sites de snapshots e snapshots atualizáveis Sites mestres em um sistema de replicação avançada pode consolidar informação que aplicações atualizam em snapshot de sites remotos. Replicação avançada do Oracle permite aplicações para inserir, atualizar e deletar linhas de tabelas através de snapshots atualizáveis. Figura de Sistema de Replicação Avançada com Snapshot Atualizável Configurações híbridas Replicação multimaster e snapshots atualizáveis podem ser combinados em uma configuração mista ou híbrida. Configurações mistas podem Ter qualquer número de sites mestres e múltiplos sites de snapshots para cada mestre Figura de Configuração Híbrida O Oracle oferece replicação de objetosd, grupos, sites e catálogos Arquitetura de replicação avançada oracle Oracle converge dados de configurações típicas de replicação avançada usando row-level replication com propagação assíncrona de dados. Nota: Oracle oferece outras características de replicação avançada tais como replicação procedural e propagação de dados síncrona para exigências únicas da aplicação. 7 Replicação row-level Transação típica do processo de aplicações modifica pequeno números de linhas por transação. Tais aplicações trabalham em ambientes de replicação avançada dependerão usualmente do mecanismo de replicação row-level do Oracle. Com replicação row-level, aplicações usam padrões de declarações DML para modificar o dado das replicas de dados locais. Quando uma transação muda um dado local, o servidor automaticamente captura informação sobre as modificações e forma filas correspondentes de transações adiadas para encaminhar mudanças locais para sites remotos. Propagação de dados assíncrona (store-and-forward) Configurações típicas de replicação avançada que contam com replicação de row-level propaga dado nível muda usando replicação de dados assíncrona. Replicação de dados assíncrona ocorre quando uma aplicação atualiza uma replica local de uma tabela, guarda a informação replicada em uma fila local e então encaminha a informação replicada para outros sites de replicação em um momento posterior. Consequentemente, replicação de dados assíncrona é também chamada de replicação de dados store-and-forward. Detecção de conflito em atualização de cópia assíncrona se todos os sites de um grupo de mestre se comunicam sincronamente com outro, aplicações nunca experimentam conflitos de replicação. entretanto, se um site está enviando mudanças assincronamente para outro site, aplicações podem experimentar conflitos em algum site do ambiente replicado. se a mudança está sendo propagada sincronamente, um erro é gerado e um rollback será requerido. se a mudança é propagada assincronamente, oracle automaticamente detecta os conflitos e derruba o conflito ou, se você designar um método de resolução apropriado , resolve o conflito. Propagação serial Com a propagação serial, Oracle propaga assincronamente transações replicadas, uma a cada tempo, na mesma ordem em que elas foram confirmadas no site de origem. Propagação paralela Com propagação paralela, Oracle propaga assincronamente transações replicadas usando multiplo, fluxo de transito paralelo pra alto throughput. Quando necessário, Oracle orderna a execução de transações dependentes para garantir a integridade global do banco de dados. Primeiro site – posse estática Posse primária, também chamado de posse estática, é um modelo de dado replicado que ambiente de replicação read-only básica suporta. Posse primária previne todas os conflitos de replicação, porque somente um servidor permite o acesso para atualização de um dado replicado. Posse dinâmica O modelo de replicação de dados com posse dinâmica é menos restritivo do que a posse primária. Com a posse dinâmica, a capacidade de atualizar uma replica de um dado move de site pra site, ainda garantindo que somente um site provê acesso de atualização para um dado específico em qualquer ponto do sistema. 8 Usando posse dinâmica para evitar conflitos – propriedade do dado Descreve-se aqui mais um método avançado para designar suas aplicações para evitar conflitos. Este método, conhecido como token passing, é similar ao método workflow. Você pode usar formas modificadas deste método para controlar a posse de grupos individuais de colunas dentro da linha. Workflow e token passing permitem posse dinâmica do dado. Com a posse dinâmica, somente um site em um determinado tempo é autorizado a atualizar a linha, mas a posse da linha pode ser passada de site para site. Workflow e token passing usam o valor de um ou mais identificadores de colunas para determinar que é atualmente autorizado para atualizar a linha. Workflow – propriedade do dado com o particionamento workflow, você pode achar que dados do proprietário estão sendo “passados” de site pra site. somente o proprietário atual de uma linha é autorizado a passar a posse da linha para outro site, através da mudança de valor do identificador de colunas. para evitar conflitos com sucesso, aplicações implementam posse de dados dinâmica deve garantir que as seguintes condições sejam atendidas: -somente o proprietário da linha pode atualizar a linha -a linha nunca é posse de mais de um site -ordenação de conflitos podem ser resolvidos com sucesso por todos os sites. com o particionamento de workflow, somente o proprietário atual da linha pode passar a posse da linha para o próximo site para atualizar o identificador de colunas. a nenhum site é dado a posse a menos que outro site tenha dado a posse, assim garante que nunca terá mais de um proprietário para a linha. Token passing – variação do workflow – propriedade do dado Para implementar token passing, ao invés de identificador de colunas, suas tabelas replicadas devem ter proprietários e período de colunas. O proprietário da coluna guarda o nome global do banco do site atualmente confiado para possuir a linha. Uma vez que você tenha designado um mecanismo token passing, você pode usá-lo para implementar uma variedade de formas de particionamento dinâmico de posse do dado, incluindo workflow. Você deve designar sua aplicação para implementar token passing para você automaticamente. Você não deve permitir que o proprietário ou época de colunas seja atualizado fora desta aplicação. Sempre que você tentar atualizar uma linha, sua aplicação deve: 1-localizar o proprietário atual da linha 2-bloquear a linha para previnir atualizações enquanto a posse está sendo trocada 3-guardar/manter a posse da linha 4-executar a atualização ( Oracle libera o bloqueio quando você confirma sua transação) Tipos de conflitos de replicação – propriedade do dado – update-anywhere Replicação avançada inclui facilidades pra detectar e resolver atualização, conflitos de uniqueness e conflitos de deleção. três tipos de conflitos: conflitos de 9 Conflitos de atualização - update conflicts Um conflito de atualização ocorre quando a replicação de uma atualização para uma linha conflita com outra atualização sobre a mesma linha. Conflitos de atualização podem acontecer quando duas transações, originárias de sites diferentes, atualizam a mesma linha quase no mesmo tempo Conflitos de unicidade - uniqueness conflicts Um conflito de uniqueness ocorre quando a replicação de uma linha tenta violar a integridade de uma entidade ( uma chave primária ou restrição unique). Por exemplo, considere o que acontece quando duas transações originadas de dois sites diferentes onde cada um insereuma linha em uma respectiva replica de uma tabela com o mesmo valor de chave primária. Neste caso, replicação de transações causa um conflito de unicidade. Conflitos de deleção - delete conflicts Um conflito de deleção ocorre quando duas transações originadas de sites diferentes, com uma transação deletando uma linha que a outra transação atualiza ou deleta. Recurso para evitar tipos de conflitos específicos - avoiding specific types of conflicts Quando o site com posse estática e o de posse dinâmica de modelos de dados são restringidos pelas exigências de sua aplicação, você deve usar um método de posse compartilhada de modelo de dados. Mesmo assim, tipicamente você pode usar algumas estratégias simples para evitar tipos específicos de conflitos, tais como: - Uniqueness Conflicts - Delete Conflicts - Update Conflicts Como oracle detecta diferentes tipos de conflitos O site mestre de destino em um sistema de replicação avançada detecta conflitos de atualização, unicidade e deleção. O site de destino detecta um conflito de atualização se existe alguma diferença entre os valores antigos de uma linha replicada ( o valor antes da modificação) e os valores atuais da mesma linha no site de destino. O site de destino detecta um conflito de unicidade se ocorrer uma violação da restrição de unique ocorre durante um insert ou update de uma linha replicada. O site de destino detecta um conflito de deleção se ele não pode achar uma linha para a declaração de um update ou delete porque a chave primária da linha não existe. Nota: para detectar e resolver um conflito de update para uma linha, o site propagador deve enviar uma certa quantidade de dados sobre as versões nova e antiga da linha para o site receptor. Para máxima performance, regule a quantidade de dados qe Oracle usa para suportar detecção e resolução de conflito de atualização. 10 Resolução de conflitos Quando conflitos de replicação ocorrem no site mestre de destino, você deve resolvê-los para garantir que o dado completo o sistema eventualmente converge. Convergência de dados significa que todos os sites com gerência de dados replicados correspondam a uma mesma informação. Se conflitos de replicação acontece e você deixar de resolvê-los, o dado replicado em vários sites permance inconsistente. Além disso, pode trazerm efeitos cascata indesejáveis. Uma inconsistência pode criar conflitos adicionais, os quais criam inconsistências adicionais e assim sucessivamente. Se você não pode evitar todos os tipos de conflitos de replicação em seu sistema, você pode configurar o sistema para usar Características de resolução de conflitos automática do Oracle. Resolução de conflito automática x manual Você deve sempre usar as características de resolução de conflitos automática do Oracle para resolver os conflitos quando eles ocorrem. Quando você não configura a resolução de conflito automática para tabelas replicadas, Oracle simplesmente registra os conflitos em cada site. Neste caso, você é forçado a resolver os conflitos manualmente para preservar a integridade do dado replicado. Resolução manual de conflitos pode ser um desafio para ser executado. Além disso, atrasos na execução manual de resolução de conflitos podem levar a inconsistências no dado que podem criar efeito cascata de erros. Resolução de conflitos de atualização e grupos de colunas - (fragmentação vertical) Oracle usa grupo de colunas para detectar e resolver conflitos de atualização. Um grupo de colunas é um grupamento lógico de uma ou mais colunas em uma tabela replicada. Toda coluna em uma tabela replicada é parte de um grupo singular de colunas. Quando é feita a configuração de tabelas replicadas na definição do site mestre, você pode criar grupos de colunas e associar colunas e corresponder métodos de resolução de conflito para cada grupo. Resolução de conflito de unicidade Na maioria dos casos, você deve construir um sistema de replicação avançada e aplicações correspondentes para que conflitos de unicidade não sejam possíveis. Entretanto, se você não pode evitar conflitos de unicidade você pode associar um ou mais métodos de resolução de conflitos para restrições de chave primária ou unique em uma tabela replicada para resolver conflitos de unicidade quando eles ocorrerem. Oracle provê poucos métodos de resolução de conflitos de unicidade pré-desenvolvidos. Entretanto você tipicamente vai querer usar estes métodos com notificação de conflito a fim de que você possa validar a precisão dos conflitos de unicidade resolvidos. Resolução de conflito de deleção Você sempre deve projetar ambientes de replicação avançada tentando evitar conflitos de deleção. Se evitar conflitos de deleção é restritivo demais para um projeto de aplicação, você pode escrever de modo geral métodos de resolução de coflitos e designá-los para tabelas replicadas. Oracle não oferece nenhum método de resolução de conflitos de deleção pré-desenvolvido. Métodos de resolução de conflitos Para resolver conflitos de replicação automaticamente, você pode designar um ou mais métodos de resolução de conflitos. Oracle tem muitos métodos pré-desenvolvido de resolução de conflitos que você pode usar para resolver conflitos. Se necessário, você pode construir/desenvolver seus próprios métodos parar resolver conflitos. 11 Métodos pré-definidos de resolução de conflito de atualização Oracle oferece métodos de conflitos de atualização para designar para grupo de colunas. Overwrite and discard value. Minimum and maximum value. Earliest and latest timestamp value. Additive and average value. Priority groups and site priority. Métodos pré-definidos de resolução de conflito de unicidade Oracle oferece os métodos para resolução de conflitos de unicidade para associá-los a restrições de chaves primárias e unique. Append site name to duplicate value. Append sequence to duplicate value. Discard duplicate value. Restrições para métodos pré-definidos para resolução de conflitos Métodos pré-definidos de resolução de conflitos do Oracle não suporta as seguintes situações: Delete conflicts. Changes to primary key (or identity key) columns. NULLs in the columns that you designate to resolve the conflict. Referential integrity constraint violations. Usando múltiplos métodos de resolução de conflitos Indicando múltiplos métodos de resolução de conflitos para um grupo de colunas permite ao Oracle resolver um conflito em diferentes maneirasde outras falhas para resolver o conflito. Quando tenta resolver um conflito, Oracle executa para cada grupo os métodos na ordem que você listar. Você deve usar multiplos métodos de resolução de conflitos pelas seguintes razões: Para empregar alternativas de métodos de resolução de conflitos quando o métedo escolhido não pode resolver o conflito Para receber notificação automáticados conflitos de replicação quando eles ocorrerem. Nota: você pode também designar multiplos métodos de resolução de conflitos para restrição de uma chave primária ou unique para resolver conflitos de unicidade e para uma tabela replicada para resolver conflitos de deleção. Oracle disponibiliza multiplos métodos de resolução de conflitos para Backup e para notificação Implementando resolução de conflito Depois de planejar, use o gerenciador de replicação oracle e o gerenciamento de replicação oracle API para configurar resolução de conflitos para tabelas replicadas em um grupo mestre, com os seguintes passos: 12 1-suspenda a atividade de replicação para o grupo mestre. 2-configure resolução de conflito para as tabelas replicadas no grupo mestre no site de definição mestre. Por exemplo, quando configurar resolução de conflito de atualização para uma tabela, use o gerenciador de replicação para criar os grupos de colunas necessárias e designe métodos de resolução de conflitos para os grupos. 3-regenere o suporte de replicação para as tabelas replicadas ou para todos os objetos no grupo mestre depois que você terminar a configuração de resolução de conflito. 4-retome a atividade de replicação para o grupo mestre uma vez que você já tenha terminado com todas as modificações e teste sua configuração de resolução de conflito. Configuração de resolução de conflito de atualização Em um ambiente típico de replicação avançada, conflitos de unicidade e deleção não são possíveis, e conflitos de atualização, portanto, requerem mais atenção durante o projeto e configuração do sistema. Facilitador de replicação avançada Oracle usa grupos de colunas para detectar e resolver conflitos de atualização. Oracle explica omo configurar grupos de colunas para tabelas replicadas e associar métodos de resolução de conflitos de atualização para cada grupod de colunas. Oracle oferece recursos tais como criar um grupo de colunas, adcionar e remover colunas em um grupo de colunas, deletar um grupo de colunas. Para gerenciar um método de resolução de conflito de atualização sobre um grupo, é possível designar métodos, remover métodos, ordenar os métodos para um grup de colunas. Oracle também permite usar gerenciar prioridades para grupos para resolução de conflito de atualização, com recursos de criar uma prioridade de grupo adcionar membros nestes grupos, alterar o valor dos membros destes grupos, remover membros destes grupos, remover membros por valor ou por prioridade, remover a prioridade do grupo Pode-se também criar prioridade para sites para resolução de conflito de atualização, criar uma prioridade para um grupo de sites, adicionar sites ao grupo, alterar o nível de prioridade do site, remover um site pelo nome, pela prioridade ou pela prioridade do grupo, Pode configurar associar e remover métodos A documentação do oracle explica como resolver os três tipos de conflitos de replicação. Posse compartilhada Modelos de replicação de dados de posse primária e posse dinâmica que promovem condições para evitar conflitos são oferecidos também/com muita restritividade para implementar par alguma aplicação de banco de dados. Algumas aplicações devem operar usando um modelo de replicação de dado com posse compartilhada na qual aplicações podem atualizar o dado de qualquer replica de tabela em qualquer tempo. Quando sistema de posse de dado compartilhada replica mudanças assincronamente (replicação store-andforward), aplicações correspondentes devem evitar o detectar e resolver conflitos de replicação se e quando eles ocorrerem. 13 Replicação procedural – replicação transacional Procedimentos de aplicações podem mudar uma grande quantidade de dados dentro de uma única transação, nesses casos, replicação típica row-level poderia carregas a rede com uma grande quantidade de alterações de dados. Para evitar esses problemas, um lote de processamento numa aplicação operando em um ambiente de replicação avançada pode usar a replicação procedural pra replicar a chamada da stored procedure para converger replicas de dados. Replicação procedural replica somente a chamada a uma stored procedure que uma aplicação usa para atualizar um tabela. Replicação procedural não replica modificações de dados. Propagação de dados síncrona (real-time) Propagação de dados assíncrona é a configuração normal para ambiente de replicação avançada. Entretanto, Oracle também suporta propagação de dados síncrona para aplicações com requisitos especiais. propagação de dados síncrona ocorre quando uma aplicação atualiza um replica local de um tabela, e dentro da mesma transação também atualiza todas as outras replicas da mesma tabela. Consequentemente, propagação de dados síncrona é também chamada de propagação de dados real-time. Usa-se esta propagação somente quando aplicações exigem que sites replicados permaneçam continuamente sincronizados. nota: um sistema de replicação que usa propagação em tempo real de uma replicação de dados é altamente dependente da disponibilidade do sistema e da rede porque isto somente pode funcionar quando todos os sites do sistema estejam concorrentemente disponíveis. Você pode criar um ambiente replicado com algumas propagações de mudanças sincronamente enquanto outros usam propagação assíncrona. Destino de transações replicadas sincronamente as chamadas necessárias a procedure remota para suporte de replicação síncrona são incluídas no trigger interno para cada objeto. quando você gera suporte de replicação para um objeto replicado, oracle ativa os triggers em todos os sites mestres para adicionar as chamadas necessárias a procedure remota para o novo site. quando você remove um site mestre de um grupo de mestres, oracle remove as chamadas dos triggers interno. Triggers e replicação - mecanismo de replicação Se você tem definido uma replicação de trigger sobre uma tabela replicada, você precisa garantir que o trigger dispare somente uma vez para cada mudança que você faça. Tipicamente , você somente vai querer que o trigger dispare quando a mudança é a feita pela primeira vez, e você não vai querer o trigger remoto dispare quando a mudança é replicada para o site remoto. Você deve verificar o valor da variável do pacote DBMS_REPUTIL.FROM_REMOTE no início do seu trigger. O trigger deve atualizar a tabela somente se o valor desta variável for falso. Alternativamente, você pode desabilitar a replicação no início do trigger e reabilitá-la no final do trigger quando modifica linhas exceto aquela que levou o trigger a disparar. Usando este método, somente a mudança origianal é replicada para sites remotos. Então o trigger de replicação será disparado para cada site remoto. Qualquer atualização executada pela replicação de trigger não será passada para nenhum outro site. Usando este método, a resolução de conflito não é invocada. Portanto, você deve garantir que as mudanças resultantes do trigger não afetem a consistência do dado. 14 Parte 2 – Controle do Ambiente Distribuído a) Gerenciamento de view View - Visão Definida por uma query no nível de esquema externo do banco do dados e o seu usuário criador deve ter associado a ele o privilégio de criação de view - create view - ou para criar views em qualquer esquema, o privilégio create any view. Ela deve ter um proprietário e ela terá os privilégios do seu proprietário. Se o proprietário da view quiser dar acesso da view a outro usuário deverá ter privilégio para isso através de grant option. Exemplo de criação de uma view CREATE VIEW sales_staff AS SELECT empno, ename, deptno FROM emp WHERE deptno = 10 WITH CHECK OPTION CONSTRAINT sales_staff_cnst; Oracle permite criar uma view com erros de sintaxe que não será executada sendo considerada “created with errors” Para criar view com erros deve-se usar o comando force CREATE FORCE VIEW AS ....; Recurso de modifiação da view DISTINCT operator aggregate functions: AVG, COUNT, GLB, MAX, MIN, STDDEV, SUM, or VARIANCE set operations: UNION, UNION ALL, INTERSECT, MINUS GROUP BY or HAVING clauses START WITH or CONNECT BY clauses ROWNUM pseudocolumn Pode-se utilizar comandos de DML para composição da view: update, delete e insert. Views podem ser alteradas e deletadas e possui recursos de segurança através das permissões de acesso a objetos oferecidas pelo Oracle. b) Controle de segurança Política de Segurança Segurança de dados inclui mecanismos de controle de acesso ao nível de objeto de banco de dados. A política de segurança do dado determina quais usuários possuem acesso a um objeto específico do esquema e especifica os tipos de ações permitidas aos usuários sobre cada objeto. 15 A segurança do dado será determinada primeiramente pelo nível de seguridade que você deseja estabelecer para o dado no seu banco de dados. Segurança do dado é baseada na sensibilidade do dado. Se a informação não é sensível, então a política de segurança do dado pode ser mais frouxa. Entretanto, se o dado é sensível, uma política de segurança deve ser desenvolvida para manter o controle do acesso ao objeto. A seguridade do dado pode ser feita através de senha e privilégios ou concessões. Segurança do administrador Quando o banco é grande e existem vários tipos de administradores do banco, a segurança do administrador deve decidir regras para os grupos de administradores e seus privilégios. As regras de administrador somente devem ser concedidas para usuários administradores apropriados. c) Controle de Integridade Tipos de restrições de integridade Para ser usado associado a valores de colunas: NOT NULL Integrity Constraints UNIQUE Key Integrity Constraints PRIMARY KEY Integrity Constraints FOREIGN KEY (Referential) Integrity Constraints CHECK Integrity Constraints Usando restrições de integridade Você pode definir restrições para forçar regras de negócio sobre o dados nas suas tabelas. Uma vez que uma restrição de integridade é ativada, todos os dados da tabela devem estar de acordo com as regras específicas para ela. Oracle garante que o resultados das operações sobre o dado satisfaçam a restrição de integridade. Usando restrições de integridade referenciais Toda vez que duas tabelas são relacionadas por uma coluna comum ou um conjunto de colunas, defina uma restrição de chave primária ou unique sobre a coluna na tabela pai e defina uma restrição de chave estrangeira na tabela filha, para manter o relacionamento entre as duas tabelas. Chaves estrangeiras podem ser de múltiplas colunas. Entretanto, uma chave estrangeira deve referenciar uma chave primária ou unique para a mesma estrutura, tendo o mesmo número de colunas e tipos de dados. O limite dado pelo Oracle é de 16 colunas para chaves primárias e estrangeiras. Pode-se dar nomes às restrições de integridade e elas podem ser habilitadas ou desabilitadas Violações de restrição de integridade Se uma linha de uma tabela não adere a uma restrição de integridade, esta linha é dita ser a violação da restrição e é conhecida como uma exceção para a restrição. Se existir qualquer exceção, a restrição não pode ser habilitada. A linha que viola a restrição deve ser atualizada ou deletada para a restrição ser habilitada. 16 Definição da integridade do dado É importante que o dado atenda a um conjunto de regras pré-definidas, como determinado pelo administrador do banco de dados ou pelo desenvolvedor da aplicação. Tipos de integridade do dado Nulls or Not null Unique Column Values Primary Key Values Referential Integrity Restrict Set to Null Set to Default Delete Cascade No Action Como Oracle impõe integridade do dado Oracle habilita você a definir e forçar para cada tipo de integridade regras definidas anteriormente. Maioria dessas regras são facilmente definidas usando restrições de integridade ou triggers de banco de dados. Triggers e restrições de integridade Oracle também permite você forçar regras de integridade com um método não declarativo usando triggers ( procedimento armazenado disparado automaticamente invocado por operações de insert, update, or delete) Parte 3 – Transparência Transparência em um Sistema de Banco de Dados Distribuído Com esforço mínimo, você pode fazer a funcionalidade de um sistema da base de dados distribuída do oracle transparente aos usuários que trabalham com o sistema. O objetivo da transparência é fazer um sistema da base de dados distribuída parecer uma única base de dados do Oracle. As seções seguintes explicam mais sobre a transparência em um sistema da base de dados distribuída. 1 - Transparência de Distribuição Existem dois aspectos a serm obervados quando se trata de Transparência de Distribuição, um é quanto à Transparência de Localização dos dados, permitindo que o comando usado por um cliente seja independente da localizaçào física dos dados sobre os quais o comando deverá atuar, o outro refere-se à Transparência de Denominação, que trata dos conflitos entre nomes dos objetos do BD distribuído, de forma que cada objeto tenha um identificador único. Um sistema da base de dados distribuída do oracle tem as características que permitem que os desenvolvedores e os administradores de aplicação escondam a posição física de objetos da base de dados das aplicações e dos usuários. A transparência de localização existe quando um usuário pode universalmente consultar a um objeto da base de dados tal como uma tabela, não obstante o nó a que uma aplicação conecta. A transparência da localização tem diversos benefícios, incluindo: 17 O acesso aos dados remotos é simples, porque os usuários da base de dados não necessitam conhecer a posição física de objetos da base de dados; Os administradores podem mover objetos da base de dados com nenhum impacto nos usuário finais ou em aplicações existentes da base de dados. Usando Views As views locais podem fornecer a transparência de localização para acesso à tabelas remotas em um sistema da base de dados distribuída, uma vez que, ao acessar uma visão os usuários não necessitam saber onde os dados são armazenados fisicamente, ou se os dados de mais de uma tabela estão sendo acessados. EX: Criação de View que Junta dados de dois sites CREATE VIEW company AS SELECT a.empno, a.ename, b.dname FROM scott.emp a, [email protected] b WHERE a.deptno = b.deptno; Após a criação desta View é possível executar a seguinte consulta: SELECT * FROM company; Views e Privilégios O proprietário local da view só pode conceder privilégios aos objetos da view local que foram possuídos pelo usuário remoto. O mesmo para view que referenciam dados locais. Usando Sinônimos Freqüentemente, os administradores e os colaboradores usam sinônimos para estabelecer a transparência para as tabelas e os objetos em um schema da aplicação distribuida. Por exemplo, comandos a seguir criam sinônimos em uma base de dados para tabelas em uma outra base de dados remota. A sintaxe de criação de um sinônimo é a seguinte: CREATE [PUBLIC] synonym_name FOR [schema.]object_name[@database_link_name] onde … [ PUBLIC ] - Especifica que este sinônimo está disponível a todos os usuários. Omitir este parâmetro faz um sinônimo confidencial, e acessível somente pelo criador. Os sinônimos públicos podem ser criados somente por um usuário com o privilégio CREATE PUBLIC SYNONYM. [ synonym_name] - Especifica o nome através do qual o objeto será referenciado pelos usuários e aplicações. 18 [ schema ] - Especifica o banco do objeto especificado no object_name. Omitir este parâmetro usa o banco do criador como o banco do objeto. [ object_name ] - Especifica o objeto do sinonimo. [ database_link_name ] - Especifica a base de dados remota e o banco em que o objeto especificado em [object_name] se encontra. Exemplo: CREATE PUBLIC SYNONYM dept FOR [email protected]_auto.com Agora, as tabelas remotas, que só podiam ser acessadas com uma query como: SELECT ename, dname FROM [email protected]_auto.com e, [email protected]_auto.com d WHERE e.deptno = d.deptno; Podem ser acessadas através de uma consulta muito mais simples que não tenha que esclarecer a posição das tabelas remotas, como: SELECT ename, dname FROM emp e, dept d WHERE e.deptno = d.deptno; Sinônimos e Privilégios Um sinônimo é uma referência ao objeto real. Um usuário que tenha o acesso a um sinônimo para um objeto particular do schema, tem também os privilégios no objeto do schema. Por exemplo, se o usuário tentar acessar um sinônimo mas não tiver privilégios na tabela que identifique, um erro ocorrerá indicando que a tabela ou a visão não existem. Suponha que um sinônimo local seja um pseudônimo para um objeto remoto. O proprietário do sinônimo local não pode conceder nenhum privilégio ao objeto do synonym a nenhum outro usuário local. Este comportamento é diferente da gerência do privilégio para os sinônimos que são pseudônimos para tabelas ou visões locais. No argumento onde um sinônimo é um pseudônimo para um objeto remoto, os privilégios locais para o sinônimo não podem ser concedidos, porque isto implicaria em conceder privilégios para o objeto remoto, que não é permitido. Conseqüentemente, nenhuma gerência local do privilégio pode ser executada quando os sinônimos são usados para a transparência da localização. Usando Procedures Através do mecanismo de Stored Procedures o Oracle oferece Transparência de Distribuição, podendo ser de três tipos. Procedures Locais Referenciando Dados Remotos Procedures ou functions (standalone ou em Pacotes) remotos. podem conter consultas que referencia dados 19 Exemplo: CREATE PROCEDURE fire_emp (enum NUMBER) AS BEGIN DELETE FROM [email protected] WHERE empno = enum; END; Quando o usuário de uma aplicação chama fire_emp procedure, não necessita saber que uma tabela remota está sendo acessada. As procedures podem também usar sinônimos para acesso aos objetos remotos. Procedures Locais Referenciando Procedures Remotas Procedures podem fazer acesso a procedures em outros sites para acesso aos dados remotos. Exemplo: Criação da Procedure local que Chama uma Procedure Remota CONNECT elvira/tiger@local_db CREATE PROCEDURE fire_emp (enum NUMBER) AS BEGIN EXECUTE [email protected]; END; Criação da Procedure remota CONNECT elvira /[email protected] CREATE PROCEDURE term_emp (enum NUMBER) AS BEGIN DELETE FROM emp WHERE empno = enum; END; Quando um usuário de uma aplicação conectado a local_db chamar a Procedure fire_emp, esta procedure irá chamar a procedure remota term_emp em hq.acme.com., acessando assim, dados remotos de forma transparente ao usuário. Sinônimos Locais Referenciando Procedures Remotas Como já vimos, podem der criados sinônimos para Procedures remotas. Exemplo: Elvira se conecta ao banco sales.acme.com no site local e cria a seguinte procedure: CREATE PROCEDURE fire_emp (enum NUMBER) AS BEGIN DELETE FROM [email protected] WHERE empno = enum; 20 END; Elisangela se conecta ao banco supply.acme.com e cria um sinônimo para a procedure remota criada por Elvira no banco sales: SQL> CONNECT elisangela/hill@supply SQL> CREATE PUBLIC SYNONYM emp FOR [email protected]; O usuário pode acessar o sinônimo para executar a procedure remota. Procedures e Privilégios Suponha um procedimento local inclua uma consulta que referencie uma tabela remota ou uma view. O proprietário do procedimento local pode conceder o privilégio executar a todo o usuário, dando desse modo a esse usuário a abilidade de executar o procedimento e, de alcançar indiretamente dados remotos. Em geral, os privilégios para os objetos referenciados dentro de um procedimento não necessitam ser concedidos explicitamente aos usuários de chamada. 2 - Transparência de Replicação É quando o SGBD transparece ao usuário a existência de réplicas dos objetos do Banco de Dados, sendo sua existência controlada pelo Sistema e não pelo usuário. A replicação dá suporte a uma variedade das aplicações com diferentes necessidades e exigências. Algumas aplicações permitem a existência de sites locais com visões materializadas em sistemas onde o mais immportante é a autonomia. Por exemplo, a automatização da equipe de vendas, o serviço de campo, o varejo, e outras aplicações maciças da distribuição requerem tipicamente que os dados das bases centrais estejam atualizados com grande número pequenos sites, remotos, que são desconectados frequentemente da base de dados central. Os membros de uma equipe de vendas devem poder executar transações, independentemente de estarem conectados à base central. Neste caso, os sites remotos devem ser autônomos Sendo assim, o Oracle oferece transparência de replicação, pois para que se faça acesso aos dados em uma tabela remota através de um snapshot, por exemplo é necessário apenas que a aplicação se referencie ao nome do snapshot criado, como se os dados fossem locais: Create Snapshot COMPANY as SELECT * FROM COMPANY@link_to_master; SELECT * FROM COMPANY WHERE state = ‘DE’; Fonte: Oracle 8 Advanced Tuning & Administration pag.511 3 - Transparência de Fragmentação Para acesso a dados fragmentados, o usuário não tem transparência oferecida diretamente pelo Oracle, o usuário tem que usar view para fazer o acesso. Redefine the accounts view. 21 CREATE OR REPLACE VIEW accounts AS SELECT * FROM accounts_jan98 UNION ALL SELECT * FROM accounts_feb_98 UNION ALL ... UNION ALL SELECT * FROM accounts_new PARTITION (nov98) UNION ALL SELECT * FROM accounts_new PARTITION (dec98); Parte 4 – Processamento Distribuído de Consulta Processamento Distribuído de Consulta 1 – Suporte ao Processamento Distribuído de Consulta O Oracle oferece suporte à consultas distribuídas transparentes para acesso a dados das bases de dados múltiplas. Fornece também muitas outras características distribuídas, tais como transações distribuídas transparentes e two-phase commit inteiramente automático. Se uma consulta SQL referencia uma ou mais tabelas remotas o otimizador determina primeiramente se todas as tabelas remotas estão situadas em um mesmo local. Se todas as tabelas estiverem situadas no mesmo local remoto, o oracle emite a consulta inteira ao local remoto para a execução. O site remoto emite o resultado ao site local. Isto é chamado de consulta remota (remote SQL statement). Se as tabelas estiverem situadas em mais de um site, o otimizador irá decompor a consulta em outras consultas separadas para alcançar cada uma das tabelas remotas. Isto é chamado de consulta distribuída (distributed SQL statement). O site onde a consulta é executada, chamado "coordenador" é normalmente o site local. Consulta Remota Se toda a query SQL for emitida à um mesmo site remoto, o otimizador usa os pseudônimos A1 da tabela, A2, e assim por diante, para todas as tabelas e colunas na query, a fim evitar conflitos de nome. Por exemplo: SELECT DNAME, ENAME FROM DEPT@REMOTE, EMP@REMOTE WHERE DEPT.DEPTNO = EMP.DEPTNO; É enviado so site remoto como: SELECT A2.DNAME, A1.ENAME FROM DEPT A2, EMP A1 WHERE A1.DEPTNO = A2.DEPTNO; Consulta Distribuída Quando uma consulta alcança dados em um ou mais sites, um site "coordena" a execução da consulta. Ele é conhecido como "coordenador"; é onde os dados serão juntados, agrupados e requisitados. Por default, o site local será o diretor. Uma constante chamada DRIVING_SITE permite especificar manualmente o site coordenador. 22 Por Exemplo: SELECT O.CUSTNAME, P.PROJNO, E.ENAME, FROM ORDERS@DB2 O, EMP@ORACLE9 E, WHERE O.PROJNO = P."PROJNO" AND P."EMPNO" = GROUP BY O.CUSTNAME, P."PROJNO", E.ENAME SUM(E.RATE*P."HOURS") "PROJECTS"@SYBS P E.EMPNO 2 – Tipo de Otimizador de Consulta Utilizado 1- Mecanismo de Otimização O mecanismo de otimização de consultas do Oracle procede da seguinte forma: O usuário submete uma query. O parser passa aquery para o otimizador. O otimizador (que pode estar usando o RBO (Buled-Based Otimization) ou CBO (Cost-Based Otimization). Se está usando CBO ele irá buscar informações estatísticas no dicionário. O plano gerado pelo otimizador é enviado ao Row Source Generator. È feita a execução da query eretornado o resultado ao usuário. 23 Parser O parser realize duas tarefas: Análise Sintática; Análise Semântica: Optimizer O optimizer usa dados internos ou métodos de avaliação de custo para determinar a maneira a mais eficiente de produzir o resultado da consulta. A saída do optimizer é um plano que descreve o melhor método de execução. O Oracle fornece dois tipos de optimização: cost-based optimizer (CBO) and rule-based optimizer (RBO). Row Source Generator Recebe o plano ótimo do otimizador e gera a saída do plano. O plano de execução é uma coleção de linhas estruturadas em forma de árvore. Neste passo, cada linha retorna uma quantidade de tuplas. SQL Execution Engine SQL Execution Engine é o componente que opera sobre o plano de execução gerado para a consulta, produzindo o resultado da consulta. Cada linha produzida pelo Row Source Generator é executada pelo SQL Execution Engine. Tipos de Otimizadores Rule-Based Optimization (RBO) Usando o RBO, o otimizador escolhe um plano da execução baseado nos métodos de acesso disponíveis e no ranking destes trajetos de acesso. O ranking do oracle dos métodos de acesso é determinado por uma heurística. Se houver mais do que um modo de executar uma consulta, então o RBO usa sempre a operação com o Ranking mais baixo. Geralmente, as operações de um Rank mais baixo executam mais rapidamente do que aqueles associados com as construções de um Rank mais elevado. Por exemplo, um Full Table Scan de uma tabela remota tem um custo estimado maior do que a mesma operação em uma tabela local idêntica. Para um plano de execução, o otimizador não considera índices em tabelas remotas. Métodos de Acesso: RBO Path 1: Single Row by Rowid RBO Path 2: Single Row by Cluster Join RBO Path 3: Single Row by Hash Cluster Key with Unique or Primary Key RBO Path 4: Single Row by Unique or Primary Key RBO Path 5: Clustered Join RBO Path 6: Hash Cluster Key RBO Path 7: Indexed Cluster Key RBO Path 8: Composite Index RBO Path 9: Single-Column Indexes RBO Path 10: Bounded Range Search on Indexed Columns RBO Path 11: Unbounded Range Search on Indexed Columns RBO Path 12: Sort Merge Join RBO Path 13: MAX or MIN of Indexed Column 24 RBO Path 14: ORDER BY on Indexed Column RBO Path 15: Full Table Scan Cost-Based Optimization (CBO) Pode considerar mais planos de execução do que o RBO. Cost-Based Optimization sabe se os índices em tabelas remotas estão disponíveis, e em que casos faria a sentido os usar. Considera também estatísticas dos objetos do esquema envolidos na consulta, além de considerar sugestões de otimização colocadas como comentários da consulta (hints). O CBO é mais poderoso que o RBO, por exemplo visões materializadas e tabelas particionadas só podem ser avaliadas pelo CBO. O CBO executa as seguintes etapas: 1. O otimizador gera um conjunto de plantos potenciais de execução para a consulta baseado em seus trajetos de acesso disponíveis e sugestões. 2. O otimizador estima o custo de cada plano baseado em estatisticas no dicionário dos dados para as características da distribuição e do armazenamento dos dados das tabelas, dos índices, e dos fragementos acessados pela consulta. O custo é um valor estimado proporcional ao uso previsto do recurso necessitado para a execução executar de um plano em particular. O optimizer calcula o custo de trajetos de acesso e junções baseado no uso estimado dos recursos do computador, incluindo I/O, CPU, e memória. 3. O optimizer compara os custos dos planos e escolhe o plano com o custo o mais baixo. 3 – Mecanismos de Otimização de Consulta Distribuida Distributed Query Otimization usa o Cost-Based Optimization do Oracle para encontrar ou gerar as expressões que extraem somente os dados necessários das tabelas remotas, processar os dados em um site remoto ou às vezes no site local, e emitir os resultados ao site local para o processamento final. 25 O otimizador escolhe planos de execução para as consultas que acessam dados em bases de dados remotas da mesma maneira que escolhe planos as consultas que acessam somente dados locais: Se todas as tabelas acessadas por uma consulta estiverem no mesmo site remoto o oracle emitirá a consulta a essa base de dados remota. O site remoto executa a consulta e emite somente os resultados de volta à base de dados local. Se uma consulta acessa tabelas que estão situadas em bases de dados diferentes, o oracle decompõe a consulta em fragmentos individuais, e cada um acessa as tabelas de um mesmo site remoto . O oracle emite então cada fragmento à base de dados que acessa. O site remoto para cada uma destas bases de dados executa seu fragmento e retorna os resultados à base de dados local, onde o site local pode executar algum processamento adicional se quiser. Ao escolher um plano de execução para uma consulta distribuída, o optimizador considera os índices disponíveis em bases de dados remotas da mesma maaneira que faz para índices na base de dados local. O optimizador considera também estatisticas em bases de dados remotas para o CBO. Além disso, o optimizer considera a localização dos dados ao estimar o custo de acesso. Por exemplo, um Full-Table Scan em uma base remota tem um custo estimado maior que em uma tabela local idêntica. Parte 5 – Processamento Distribuído de Transação Processamento Distribuído de Transação Suporte ao processamento distribuído de transação O que é uma transação distribuída? Uma transação distribuída é um comando que individualmente ou em grupo altera dois ou mais participantes de um banco de dados distribuído. Se os comandos referenciarem apenas um participante a transação será remota e não distribuída. 26 1. Session Tree O Oracle® define uma session tree de todos os participantes da transação distribuída. A Session Tree é um modelo hierárquico que descreve as relações entre os participantes envolvidos. Cada participante possui uma tarefa na transação, por exemplo, o participante que originou a transação é o coordenador global, e o participante que inicia o commit ou o rollback é chamado de commit point site. Todos os participantes de uma session tree de uma transação distribuída assume uma ou mais das seguintes responsabilidades: Cliente; Servidor de Banco de Dados; Coordenador; Participante; O Ponto de Commit. As definições das responsabilidades dos participantes de uma transação distribuída são definidas por: Se a transação é local ou remota; A força do Ponto de Commit; Se todos os dados requeridos estão disponíveis no local, ou outros participantes tiverem que referenciá-los para completarem a transação; O Participante é Read-Only. O Cliente Um participante age como cliente quando referencia informações em um banco de dados de outro participante, no exemplo acima o site SALES.FINANCE.COM é um cliente dos participantes (servidores de banco de dados) onde estão hospedados os bancos WAREHOUSE e FINANCE. 27 Servidores e Servidores de Banco de Dados O servidor é um participante que seja diretamente referenciado por uma transação distribuída ou é requisitado para participar da transação por outro participante necessitar de dados de seu banco. No exemplo uma aplicação no participante que hospeda o banco de dados SALES inicia uma transação distribuída que acessa dados dos participantes que hospedam os bancos WAREHOUSE e FINANCE. Neste caso o SALES.FINANCE.COM é um cliente e WAREHOUSE e FINANCE são servidores de banco de dados. SALES é um servidor de banco de dados e um cliente uma vez que está requisitando uma mudança no banco de dados SALES. Coordenador Local (local coodinator) Um participante que referencie dados em outros participantes para completar a transação é chamado de coordenador local. No exemplo SALES.ACME.COM aparece como coordenador global, mas também é considerado um coordenador local por coordenar diretamente os participantes que referencia: WAREHOUSE.ACME.COM e FINANCE.ACME.COM. O Coordenador local é responsável por coordenar a transação pelos participantes ligados diretamente a ele: Recebendo e propagando informações sobre o estado destes participantes; Passando as queries para eles; Recebendo queries desses participantes e repassando a outros; Retornando os resultados das queries para o participante que a iniciou. Coordenador Global (Global Coodinator) O participante onde a transação distribuída se originou (onde a aplicação de banco de dados está conectada diretamente) é chamado de coordenador global. Ele realiza as seguintes operações durante uma transação distribuída: Todos os atributos SQL, procedimentos armazenados, etc... São enviados pelo coordenador global para os participantes ligados a ele diretamente. No exemplo o coordenador global é o participante SALES.ACME.COM, que referencia informações dos servidores de banco de dados WAREHOUSE.ACME.COM e FINANCE.ACME.COM Algumas atribuições do coordenador global: Informa a todos os participantes diretos que não sejam o commit point site para executar a preparação da transação; Se todos os participantes executarem o prepare corretamente o coordenador global instrui o commit point site para iniciar o commit global da transação; Se houver uma ou mais mensagens de abort o coordenador global instrui todos os participantes a executarem o rollback da transação. 28 Ponto de Commit (Commit Point Site) O Trabelho do ponto de commit é de iniciar um commit ou rollback instruído pelo coordenador global. O Administrador do sistema deve designar um participante para ser o commit point site na session tree definindo para todos os participantes um commit point strength. O participante selecionado para ser o commit point site deve ser o que possua mais dados críticos. O participante commit point site distingui-se dos demais por: Nunca entrar no modo de prepare. Essa é uma grande vantagem uma vez que contendo os dados mais críticos, seus dados estarão sempre disponíveis sem gerar lock ou ficar em espera. Determina quando toda a transação terminou o commit ou rollback. A transação pode ser considerada pronta para o commit quando todos os participantes enviam a mensagem de prepared e já foi executado o commit no ponto de commit. Seu log é atualizado no momento em que seu commit é finalizado. Commit Point Strength Todos os participantes do modelo distribuído que sejam servidores de banco de dados devem possuir um commit point strength. De todos os participantes referenciados diretamente pelo coordenador global o commit point site será o que possuir maior commit point strength. 29 2. Two-Phase Commit Todos os participantes de uma transação distribuída devem tomar a mesma decisão quanto à ação a ser tomada para a transação. Todos devem executar um commit ou rollback. O Oracle® controla e monitora o Commit e Rollback de uma transação distribuída automaticamente e mantém a integridade do Banco de Dados utilizando o mecanismo de two-phase commit. Esse mecanismo é totalmente transparente ao usuário e ao desenvolvedor. Para executar um commit de uma transação distribuída existem duas fases distintas (two-phase commit). Fase de Preparação Fase de Commit a. Fase onde o Coordenador manda os participantes se prepararem (para o commit ou rollback se houver alguma falha). Caso todos os participantes respondem que estão preparados, o Coordenador ordena que todos os participantes executem o commit. Caso algum não possa, ele ordena a todos que executem um rollback. Fase de Preparação A primeira fase para commitar uma transação distribuída é a fase de preparação onde o commit da transação não foi totalmente carregado. Na preparação os participantes registram a informação necessária para posteriormente possa ser efetuado um commit ou um rollback Quando um participante recebe uma ordem de preparação ele pode responder de 3 maneiras: Preparado Somente-Leitura Abortar O participante está preparado, garantindo um posterior rollback ou commit. Nenhum dado foi alterado ou pode ser alterado, então a preparação não é necessária. O participante não conseguiu se preparar.. Fase de Preparação pelos Participantes Para executar a preparação os participantes devem executar os seguintes passos: O participante manda a ordem para seus descendentes prepararem; Checa se a transação alterou algum dado nele ou em algum de seus descendentes. Caso não haja alteração, passa ao próximo passo em responde com mensagem de Somente-Leitura (read-only); O participante aloca todos os recursos necessários para a execução do commit no caso existir alguma alteração; O participante grava em seu log todas as entradas correspondentes à alteração dos dados; O participante garante que, o lock desta transação está habilitado a sobreviver a uma possível falha; O participante responde ao Coordenador com uma mensagem de preparado ou caso não tenha sido possível executar o prepare em ele mesmo ou em algum de seus descendentes, responde com uma mensagem de Abort. A execução desses passos garante que a transação pode executar um commit ou um rollback neste SGBD. Sendo enviada a mensagem de preparado o SGBD fica em estado de espera até que receba um comando de commit ou rollback. 30 Resposta Read-Only Quando um participante é perguntado para preparar e as operações executadas no banco não alteram os dados do participante em questão, ele responde com uma mensagem de Read-Only. Esses SGBD não participam da segunda fase, a do commit. Preparação sem sucesso (mensagem de abort) Quando o participante não consegue se preparar, ele segue os seguintes passos: O participante libera os recursos alocados para a transação e executa um rollback da parte local da transação; Responde ao seu coordenador a mensagem de “abort”. Essas ações se propagam para os outros participantes que executam o rollback da transação mantendo a integridade do banco. Forçando assim a regra principal de uma transação distribuída no Oracle e do protocolo de two-phase commit, ou executa um commit em todos participantes ou é executado o rollback. b. Fase de commit Esta é a segunda fase para o commit de uma transação distribuída. Antes da ocorrência desta fase todos os participantes referenciados garantiram que possuem todos os recursos necessários para executar o commit na transação. A fase de commit consiste nos seguintes passos: O Coordenador envia a mensagem aos participantes que devem executar o commit da transação; O Oracle8® executa o commit na porção local da transação distribuída, liberando os locks, e guarda no arquivo de log indicando o fim da transação. Quando finalizada a fase de commit, os dados em todos os participantes estão consistentes uns com os outros. Protocolo de recuperação (recovery) The Recoverer (RECO) Background Process O processo de background RECO de uma instancia do Oracle8® resolve automaticamente todos os erros envolvendo transações distribuídas. O RECO pode utilizar uma conexão já aberta ou estabelecer uma nova conexão com os participantes envolvidos na transação que falhou. Quando a conexão for estabelecida, o RECO resolve todos os erros da transação distribuída. As linhas correspondentes dos participantes a transação são removidas de cada banco de dados. O processo de recuperação, RECO, pode ser habilitado ou desabilitado no sistema usando o comando ALTER SYSTEM ENABLED/DISABLE DISTRIBUTED RECOVERY. 31 Ações do Coordenador para casos de falha Falha no Estágio Inicial Reenvia o comando de prepare para os participantes. Falha no Estágio Wait Espera o timeout e reenvia o comando de prepare para o participante que não respondeu. Falha no Estágio Abort ou Commit Reenvia o comando de abort ou commit, caso o participante não receba o comando após o timeout executa o abort. Ações do Participante para casos de falha Falha no Estágio Inicial Executa o abort por não conseguir o prepare. Falha no Estágio Ready Envia decisão abort ou commit. E espera a decisão do coordenador. Controle de Conflitos Resolução de Conflitos Automatic versus Manual Conflict Resolution Você pode usar sempre as características de resolução de conflitos do Oracle® para resolvê-los quando ocorrer. Quando você não configurar a resolução automática de conflitos para tabelas replicadas, o Oracle® simplesmente registra no log dos sites os conflitos. Neste caso você é forçado a resolver os conflitos manualmente para preservar a integridade do banco. Update Conflict Resolution and Column Groups O Oracle® usa grupos de colunas para resolver conflitos. Um grupo de colunas é um grupamento lógico de uma ou mais colunas de uma tabela replicada. Toda coluna numa tabela replicada faz parte de um grupo de coluna simples. Quando configurando as tabelas replicadas no Master site, você pode criar grupos de colunas e associá-los colunas e métodos de resolução de conflitos. Uniqueness Conflict Resolution Na construção de ambientes replicados avançados podem ocorrer erros de chaves ou campos únicos. Para isso associa-se métodos de resolução de conflitos a PRIMARY KEY ou UNIQUE constraint numa tabela replicada. Delete Conflict Resolution Para o caso de conflitos de deleção pode-se escrever os métodos e associá-los as tabelas replicadas. O Oracle® não oferece nenhum método para resolução de conflitos de deleção. Métodos de resolução de conflitos de update (concorrência) O Oracle® possui alguns métodos já prontos para a solução de problemas de concorrência: Additive and Average; Minimum and Maximum; Timestamp; Overwrite and discard; Priority groups and site priority. 32 Additive and Average (Adição e Média) Este método funciona com grupos de colunas, consistido de uma coluna numérica simples. Additive: Valor corrente = valor corrente + (valor novo – valor antigo). Average: Valor corrente = (valor corrente + Valor Novo)/2. Maximum and Minimum (Máximo e mínimo) Neste método ele compara o novo valor do site original com o valor corrente do site de destino. Chamando o método de resolução de conflito Minimum, se o novo valor for maior do que o valor corrente ele altera o valor corrente para o novo valor. Caso seja menor o valor corrente permanece inalterado. O contrario acontece caso seja chamado o método Maximum. Para o método Maximum, o valor da coluna está sempre crescendo; Para o método Minimum, o valor está sempre decrescendo. Timestamp Para a utilização deste método você deve designar uma coluna da tabela replicada do tipo date. Quando uma aplicação muda alguma coluna no grupo, a aplicação deve alterar o timestamp com a data do sistema atual. Para a alteração do site de destino o timestamp registro do site de origem deve ser maior do que o do destino. Overwrite and discard Este método ignora os dados existentes no site original e no de destino e não se pode garantir a convergência para o caso de houver mais de um master site. Esses métodos são utilizados para o caso de um único master e vários snapshots. Esses métodos são usáveis quando: Possui um master site apenas; Não existe regra de negócio se executar um update após o outro; Se existir vários sites master e haja a necessidade de se alterar. Priority Groups and Site Priority Possibilita atribuir um valor de prioridade para cada coluna. Caso o Oracle® detecte um conflito, ele atualiza a tabela cuja prioridade seja menor usando os dados da tabela com maior prioridade. Parte 6 – Suporte a acesso a dados de SGBD Heterogêneo A Oracle possui duas soluções para o acesso e a integração de dados de uma base não Oracle. São elas o Oracle Transparent Gateways e o Generic Conectivity. Generic Conectivity O Generic Conectivity é uma solução genérica que utiliza os drivers ODBC ou OLE DB para acessar qualquer compilador ODBC ou OLE DB de um sistema não Oracle. Permitindo assim transparência de conexão com bases de dados como Acess, Excel, DBase e FoxPro. 33 Oracle Transparent Gateways Em contraste com o Generic Conectivity o Oracle Transparent Gateways possui soluções especialmente codificadas para o sistema não Oracle. Gerando uma solução otimizada, com mais funcionalidades e melhor performance do que o generic Conectivity. Acesso a dados do SGBD não Oracle O Oracle cria um link com a base de dados não Oracle. Para acessar dados de uma tabela em um banco não Oracle: SELECT SUBSTR(ENAME,1,5) FROM EMP@GTWLINK 34
