banco de dados distribuído
Propaganda
ADABAS D BANCO DE DADOS DISTRIBUÍDO ADABAS Grupo: Ana Carolina Brito Helena Alves Isa Madalena Joelma Dias 1 28/05/17 ADABAS D Índice 123456- Projeto de BD-Distribuído Controle do Ambiente Distribuído Transparência Processamento Distribuído de Consulta Processamento Distribuído de Transação Suporte a Acesso a Dados de SGBD Heterogêneo 2 28/05/17 ADABAS D 1- Projeto de BD-Distribuído: - Suporte à fragmentação Horizontal, em função de valores de determinadas colunas ( Ex.: Separar dados de acordo com a região: Clientes do RJ, clientes de SP etc) Vertical, em função das colunas mais acessadas em um determinado site Híbrida Para obter fragmentação no Adabas D é necessário ter a ferramenta Adabas Vista, que distribui um arquivo Adabas grande em vários arquivos chamados partições. O arquivo original é particionado de acordo com os valores do campo particionamento do Adabas. Os dados no particionamento não são replicados; cada registro é armazenado em uma única partição. Benefícios: Custo de manutenção reduzido, maior flexibilidade, aumento de disponibilidade (Partições individuais podem ser acessadas remotamente); Rápido acesso aos dados (Consultas são direcionadas dinamicamente para uma única partição, se for apropriada). 3 28/05/17 ADABAS D Características do Adabas Vista Acesso distribuído e direcionado Pode pegar uma ou mais partições offline enquanto as aplicações continuam acessando as partições restantes. Facilidade de restringir partições Manutenção das Partições-> Cada partição é separada em arquivos Adabas. É possível operar os arquivos individualmente e paralelamente. Acesso misto -> As aplicações podem acessar os dados por um arquivo de partição específico através do arquivo real em paralelo com acesso à uma view baseada no acesso através do Vista. Consolidação Uma nova partição pode ser criada para cada período de tempo e os dados antigos podem ser recuperados para um armazenamento barato para ser acessível pelas aplicações. As partições não são armazenadas no mesmo local do banco de dados Adabas. Elas podem ser distribuídas sobre vários banco de dados em uma rede de computadores. 4 28/05/17 ADABAS D - Mecanismos de Replicação Replicação Completa Assíncrona Propriedade Master/Slave Mecanismo: Snapshot e Replicação Transacional Para implementar a replicação assíncrona é usado o Empire Transaction Propagator. Neste caso, o dado replicado é atualizado e sincronizado com o dado mestre de acordo com o intervalo estabelecido pelo usuário. Os arquivos mestres podem estar localizados próximos do local onde seus dados são frequentemente modificados e as suas cópias próximas a locais que o acesso somente leitura seja suficiente. Os Snapshots são tabelas de leituras (read-only) e que são atualizadas explicitamente pelo comando “refresh”. O “Refresh” tem que ser solicitado explicitamente em uma primeira vez através do comando específico (Refresh). Com isso, o usuário pode programar os próximos “refreshes” (Parametros START_WITH e NEXT) para serem realizados automaticamente. O “Refresh” não é definido pelo comando de criação do snapshot. Se uma tabela snapshot só conter dados de uma tabela “base” e se existir um snapshot log, ou seja, um protocolo de operacoes de modificação realizadas entre o último "refresh" e o ponto atual, só estas modificações são realizadas na tabela snapshot (Replicação Transacional). Caso contrário, toda a tabela é reconstruída. As modificações da base de dados iniciadas por “triggers” que seguem outras tuplas de tabelas são executadas sincronamente. O comando “updmaster” organiza a extensão e o procedimento de atualização. A manutenção dos dados reais é feita chamando o comando “updslave”. 5 28/05/17 ADABAS D 2- Controle do Ambiente Distribuído: - Gerenciamento de View . Views Atualizáveis: O conceito de join view consiste em uma view cuja cláusula FROM referencie duas ou mais tabelas. O Adabas D permite que operações de modificação sejam feitas sobre join views (INSERT, UPDATE, DELETE). Dessa forma, uma alteração que referencie uma join view, irá alterar as tabelas base que a compõem. Para que alterações possam ser feitas sobre join views, estas devem ser criadas como “with check option” e deve conter as primary keys de todas as tabelas base. Além disso foreign keys entre as tabelas base devem ser definidas. As seguintes construções não podem ser feitas sobre join views: GROUP BY, HAVING, DISTINCT, UNION, INTERSECT, EXCEPT, Outer Join e Subqueries. Como o acesso aos dados através de views é síncrono, isto é, todas as vezes que um usuário desejar realizar uma operação sobre a view, o SGBD terá que acessar as tabelas que formam a mesma. Como essas tabelas podem estar em sites diferentes, esse acesso pode gerar um custo alto devido ao tráfego na rede. 6 28/05/17 ADABAS D . Snapshots O uso de snapshots minimiza o problema de custo causado pelo uso de views. Snapshots são cópias estáticas de uma tabela que são armazenadas fisicamente no banco de dados. Alterações na tabela base não são automaticamente atualizadas nos snapshots. As modificações podem ser feitas assincronamente através da cópia inteira dos dados ou através da utilização de um log de alterações. A execução das modificações são feitas através do comando REFRESH. Somente cláusulas SELECT são permitidas em um snapshot. INSERT, UPDATE ou DELETE não são permitidos. Views em databases distribuídos Através do módulo Adabas Vista, o ADABAS D permite que views sejam definidas sobre partições. Essas partições podem estar localizadas em um único database ou em databases distribuídos pela rede. Uma view é acessada como se fosse uma única entidade mesmo que ela acesse fragmentos localizados em databases distribuídos. Consultas Distribuídas Views sobre fragmentos podem implicar em consultas distribuídas. Acesso distribuído e direcionado -> Ex.: Particionamento pela chave mais acessada. As consultas sobre views definidas com base nesta chave são endereçadas para só uma das partições(direcionado). Se uma consulta feita sobre uma view que não seja 7 28/05/17 ADABAS D baseada nesta chave, ela é enviada para todas as partições e o Vista irá agrupar os resultados encontrados (distribuído). - Controle de Segurança . Proteção do Dado O controle de usuários no ADABAS D é feito a nível de partição. É possível restringir o uso de uma partição de acordo com roles de usuários. Para cada partição um usuário pode ter tipos de acessos diferentes, eses acessos podem ser none, read ou read/write. A segurança dos dados é implementada através da utilização de alias que não permitem que a localização física dos dados sejam visualizados pelos usuários. Esse controle é implementado pelo Entire Net-Work. Com o ADABAS D, o usuário não tem que se preocupar com extensões do SQL, pois toda a criação e manutenção de objetos na base de dados não requerem nenhuma parametrização, como tamanho de tabela, localização etc. Os dados dos usuários e dos objetos ficam armazenados em um catálogo parcial no site em que os objetos/usuários foram criados (HOMESERVERDB). As informações sobre os objetos replicados ficam armazenados no catálogo do HOMESERVERDB e no catálogo de cada uma das réplicas. Os dados de acessos de usuário (login e senha) são copiados do local original para cada uma das réplicas. O catálogo global consiste em uma parte que é copiada para todos os SERVERDBs e de uma outra parte armazenada em apenas um servidor. 8 28/05/17 ADABAS D O ADABAS D oferece segurança através de bloqueio de linhas e tabelas, privilégio de classes de usuário, triggers e integridade referencial e de domínio. Existem também limites atribuídos pelo DBA aos usuários quanto ao uso de recursos de espaço de discos e custos de consultas SQL. . Controle de Autorização Privilégios Os privilégios definem que usuários estão autorizados para acessar determinadas tabelas (e suas colunas) em um banco de dados específico. Cada tabela possui sua lista de privilégios, indicando os poderes de cada usuário que possui acesso à ela. Quando for necessário criar uma tabela para que todos os usuários, tenham acesso, basta colocar a palavra PUBLIC no momento de criação da tabela. Somente os usuários do banco de dados em que a tabela está sendo criada, poderão acessá-la. Um usuário pode ter os seguintes privilégios: ALL, SELECT, INSERT, DELETE, UPDATE, SELUPD, REFERENCES, INDEX e ALTER. Quando os privilégios de SELECT ou UPDATE forem atribuídos à um usuário, pode-se especificar a quais colunas da tabela esses privilégios se aplicam. . Autorização 9 28/05/17 ADABAS D Grupos de Usuários O controle de autorização de usuários é muito importante para garantir a segurança dos dados, visto que um usuário só poderá visualizar e/ou alterar os dados que ele possui acesso. Para facilitar o controle de acesso ao banco de dados, o ADABAS possui o conceito de grupos de usuários. São atribuídos privilégios a um grupo no momento da criação deste. Quando criamos usuários, podemos referenciá-los a determinado grupo, todos os privilégios do grupo são cascateados para seus usuários. Se for necessário, pode-se retirar ou dar privilégios a um usuário específico, mesmo se este estiver dentro de um grupo. Direitos de Usuários O ADABAS oferece quatro tipos de classes de usuários: DBA : Podem criar usuários ou grupos de usuários com status RESOURCE ou STANDARD, dar privilégios à outros usuários e criar dados privados. SYSDBA: Possui os mesmos poderes da classe DBA, além de poderem criar usuários DBA em seu SERVERDB. RESOURCE: Os usuários podem definir suas próprias tabelas, views e sinônimos, além de dar privilégios à outros usuários sobre esses objetos. STANDARD: Os usuários podem definir views e sinônimos, porém, só podem efetuar operações nos dados em que possuem privilégios. 10 28/05/17 ADABAS D - Controle de Integridade Para manter a consistência no banco de dados, é necessário garantir que todas as restrições sobre o banco sejam respeitadas. Como em banco de dados distribuído nós possuímos vários usuários acessando os mesmos dados, e em algumas vezes, em réplicas diferentes, é necessário que o SGBD implemente técnicas de acesso aos dados sem que a integridade do banco de dados seja prejudicada. O Adabas D não suporta foreign key entre tabelas de bancos de dados distintos. Como resolução do problema de integridade entre os dados, é sugerida a utilização de triggers. O controle de primary keys entre fragmentos de uma mesma tabela, é feito através da utilização de uma chave global do banco de dados (SYSKEY), essa chave deve ser única e engloba todas as linhas de todos os fragmentos de uma tabela. Isso é possível visto que a fragmentação no adabas é feita de forma direcionada, conforme explicado anteriormente. Locks Para solucionar o problema de acesso concorrente às tuplas de uma tabela o ADABAS D utiliza o conceito de lock. Três tipos de locks são implementados: Locks de leitura: Permite que diversos usuários leiam concorrentemente os dados de uma tabela e previne a alteração de dados na mesma; 11 28/05/17 ADABAS D Locks de escrita: Permite que um único usuário altere dados em uma tabela e mantêm os dados inacessíveis aos demais usuários; Lock otimizado (Optimistic Locking): Caso tenha existido alguma transação concorrente à sua que tenha alterado tuplas na mesma tabela, o SGBD envia uma mensagem para o usuário no momento do commit de sua transação e aborta as alterações. Caso contrário, as alterações são executadas. O ADABAS D tem como padrão liberar os locks automaticamente no final da transação. Apesar disso, podem ser implementados locks que continuem ativos após o fim da transação através da declaração explícita do mesmo. A tabela abaixo exemplifica o comportamento dos locks quanto à transações paralelas: (Excl: Exclusivo, Comp: Compartilhado) Uma transação que possui… Permite que outra transação… Excl Comp Lock em uma tabela Excl Comp Excl Comp Lock em uma linha Lock no catálogo Efetuar lock exclusivo em uma tabela? Não Não Não Não Não Sim Efetuar lock compartilhado em uma tabela? Não Sim Não Sim Não Sim Não Não --- --- Não Sim Lock em uma linha que já está no modo lock exclusivo? --- --- Não Não --- --- Lock exclusivo em outra linha? --- --- Sim Sim --- --- Lock na linha de uma tabela que está com lock em modo exclusivo? 12 28/05/17 ADABAS D Lock compartilhado em qualquer linha da tabela? Não Sim --- --- Não Sim Lock em uma linha que já está no modo lock compartilhado? --- --- Não Sim --- --- Lock compartilhado em outra linha? --- --- Não Sim --- --- Alterar a definição de uma tabela no catálogo do sistema? Não Não Não Não Não Não Leitura da definição de uma tabela no catálogo do sistema? Sim Sim Sim Sim Não Sim Atitudes do ADABAS D para garantir a consistência do banco de dados: - Caso 1 (Dirty Read) : A transação T1 altera uma linha Y na tabela X, a transação T2, lê a linha Y antes de T1 ter sido concluída (antes do comando commit). Nesses casos, T1 executa o rollback.; - Caso 2 (Leitura não-repetitiva) : A transação T1 lê a linha Y da tabela X, T2 altera ou exclui a linha Y e confirma as atualizações com o comando commit. Nesses casos T1 lê novamente a linha Y, e uma mensagem é exibida informando que a linha não existe mais; - Caso 3 ( Fenômeno Fantasma): A transação T1 executa um comando SQL que lê um conjunto de linhas que satisfazem uma determinada condição. Uma transação T2 cria uma tupla que satisfaz a condição especificada por T1. Para evitar inconsistência na quantidade de tuplas que satisfazem as condições, a transação T1 reexecuta os comandos SQL. 13 28/05/17 ADABAS D Controle de Consistência O controle de consistência é responsável por manter o banco de dados funcionando em boa performance. Para isso ele implementa os seguintes procedimentos: Check em tempo de execução: Verifica se existe consistência nas cadeias internas de árvore B, utilizadas nos bancos de dados. Se forem encontradas inconsistências, a base de dados deve ser restaurada (restore). Essa averiguação de consistência deve ser feita antes de cada backup completo no banco de dados; Check antes do restart no SERVERDB (Cold Mode): Páginas com erros de gravação devido à um termino irregular do banco de dados são liberadas. 3- Transparência: - Distribuição No Adabas D pode ser usado um alias para cada objeto do banco de dados com nome prefixado (nome local), portanto não existe transparência de Distribuição. Ao executar o start-up da base de dados, é necessário usar o hostname original, ou seja, o caminho completo do banco. Mas isto só é feito no momento de construção da base de dados. Posteriormente, pode ser usado somente um alias para referenciá-lo. No Entire Net-Work, as aplicações não precisam saber a localização dos dados para poderem acessá-los. O Entire Net-Work é um meio baseado em mensagens que permite que o banco de dados seja acessado de qualquer lugar na rede, sem que seja necessário explicitar a sua localização física, podendo mascará-la através de um alias. 14 28/05/17 ADABAS D - Não possui Transparência de Replicação - Fragmentação No Adabas Vista, os arquivos particionados são vistos como uma única entidade lógica. Em outras palavras, as partições são transparentes para o usuário final. Existe um particionamento pela chave mais acessada. As consultas baseadas nesta chave são endereçadas para só uma das partições(direcionado). Se não for baseada nesta chave, a consulta é enviada para todas as partições e o Vista irá agrupar os resultados encontrados (distribuído). 4- Processamento Distribuído de Consulta: - Suporte ao processamento distribuído de consulta: Quando as consultas não são direcionadas para uma determinada partição, elas são enviadas para todas as partições e o Adabas Vista se encarrega de agrupar estes resultados. - Tipo de otimizador de consulta utilizada: 15 28/05/17 ADABAS D Baseado em custo. A otimização no Adabas é baseado em custo e cria alternativas de planos de acesso em tempo de compilação e em tempo de execução ele escolhe o melhor custo, ou seja, o menor custo. - A medida do plano melhor é feito em custo, baseando-se no I/O fisico. - Mecanismos de otimização de consulta distribuída: O Adabas adota o mecanismo de otimização trabalhando com estatísticas referentes ao tamanho dos objetos da base de dados e nos valores distribuídos. Esse processamento é baseado nas estatísticas geradas que estão sempre atualizadas. Estas estatísticas que servem para determinação do plano de acesso são baseadas no número de linhas de uma tabela e na seletividade das colunas individualmente. O que o otimizador utiliza para escolher o melhor plano, o plano ótimo? - o número de linhas das tabelas bases, as tabelas que estão sendo consultadas . - o tamanho das arvores B dessas tabelas e índices. - o número dos diferentes valores em colunas, ou seja, otimização de joins. Observação: 16 28/05/17 ADABAS D Se o Adabas reparar que houveram diferenças entre o otimizador atual e as estatísticas calculadas, ele mesmo dispara um update estatístico implícito. Se o tamanho ou a quantidade de acesso em uma tabela mudar muito deve ser feito uma atualização nas estatísticas. Se não houver a atualização das estatísticas, o otimizador pode selecionar um caminho não favorável de processamento que pode causar uma perda drástica da performance do sistema. 5- Processamento Distribuído de Transação: - Sub-Transações Quando uma Stored Procedure no ADABAS D for chamada pro uma aplicação, todas as ações serão efetuadas caso haja sucesso e não haverá nenhum efeito no Banco de Dados caso haja alguma falha. Para que isso ocorra o ADABAS D utiliza Sub-Transações. Quando utilizamos Stored Procedures não podemos utilizar COMMIT e ROLLBACK, pois poderá haver Sub-transações ativas que não serão finalizadas. Sendo assim devemos utilizar os comandos SUBTRANS BEGIN, SUBTRANS END e SUBTRANS ROLLBACK. Caso haja sucesso, a Procedure será concluída com SUBTRANS END. Caso haja alguma situaçõa de erro, não haverá inluência na aplicação pois a transação não será comitada, onde o SUBTRANS ROLLBACK será executado. Isolamento 17 28/05/17 ADABAS D ADABAS A NSI Tipo do Lock Read 0 0 uncommitted Read 1 , 10 1 committed Consistent 15 - Select Repeatable 2 , 20 2 Read Serializable 3 , 30 3 Nível 0 (Dirty Reads) – O acesso é permitido aos objetos que estão sendo alterados por outro usuário em uma transação não comitada. O Nível de isolamento 0 permite o maior nível de paralelismo. Nível 1 , 10 - O ADABAS faz um lock shared em cada linha que está sendo usada na tabela, previnindo o acesso a transações ainda não completadas. Nível 15 – As tabelas relacionadas a transação não podem ser modificadas enquanto os comandos estão sendo processados. Isto é implementado através de um lock em toda a tabela. Nível 2 , 20 – Em uma transação as tabelas são lockadas, de modo que as outras transações possam enxerga-las apenas para consultas. As linha também são lockadas, mas as outras transações não poderão enxerga-las. 18 28/05/17 ADABAS D Nível 3, 30 – Assegura que o usuário somente enxergue as modificações feitas por ele mesmo. -Two-Phase Commit Por meio do protocolo Two-Phase Commit, o Adabas sincroniza as transações do ambiente distribuído. Este garante a consistência dos dados nos respectivos bancos de dados, coordenando as mudanças feitas em cada um. O Protocolo Two-Phase Commit é usado para sincronizar atualizações em diferentes Bases de dados, de modo que toda a transação seja executada com sucesso, ou caso haja alguma falha, não seja executado. Cada Base de Dados particpa da Transação Global independentemente. A transação é comitada ou não, após passar pelas duas fases: Na Primeira fase todos os participantes devem informar se ja comitaram a sua parte da transação. Na Segunda Fase, após todos os participantes terem respondido, a transação local é comitada, caso todas as respostas forem positivas ou não, caso alguém nao tenha comitado. Durante a fase um os participantes devem armazenar todos os recursos da transação para s preparar para os eventos da fase dois. O gerente de transação é um elemento chave dessa estratégia. Ele permite que os bancos de dados do Adabas participem de transações globais, aumentando a sua flexibilidade. 19 28/05/17 ADABAS D Uma Transação Global é uma unidade de trabalho que envolve mudanças operando uma ou mais base de dados na mesma ou em diferentes máquinas. O Banco de Dados pode ser local ou remoto. Gerente de Transação do Adabas: - Coordena as mudanças dos Bancos de dados que estão participando da transação global. - Monta as regras para coordenar transações globais que envolvem bancos de dados em mais de uma imagem de Sistema. - Processa as instruções do Protocolo Two-Phase Commit no nível mais alto de gerencia da Transação, envolvendo transações que estão em Bancos de dados ADABAS ou não. - Recovery Nas situações de erro que não envolvem falhas do meio de armazenamento, o Adabas restaura automaticamente o último estado consistente da base de dados quando restarta. Isto significa que todos os efeitos de transações comitadas são preservados, enquanto os efeitos das transações abertas no momento em que o erro ocorreu, são cancelados. As falhas do meio de armazenamento requerem o carregamento de uma versão de backup da base de dados realizada previamente. Pode também ser necessário carregar diversos dados incrementais de backup para restaurar a base de dados para um estado acima das últimas versões do log que podem ser reaplicadas. Quando estas ações são concluídas, o último estado consistente da base de dados foi restaurado. 20 28/05/17 ADABAS D 6 -Suporte a acesso a dados de SGBD Heterogêneo Através do Adabas 7.1 para mainframes e do Adabas Transaction Manager para mainframes, é possível sincronizar as transações envolvidas em múltiplos sistemas de banco de dados. ATM 1.2 suporta a sincronização entre Adabas e: DB2, IMS e VSAM. O Adabas pode comunicar-se com outros SGBDs também através do driver ODBC. O driver ODBC executa dentro do contexto da aplicação, na máquina do cliente se necessário. O driver ODBC fornece as funções definidas para o ODBC e converte o pedido de SQL antes de passá-lo para o Kernel. 21 28/05/17
