A Cláusula WITH READ ONLY

Trabalho de Cliente e Servidor
ORACLE
Professora:
-
Elvira Uchôa
Componentes:
-
Nome: Fabiano
Matrícula:
Nome: Gustavo Scaffa Brum
Matrícula: 9824743-7
Nome: João Luis Silva Bacha
Matrícula: 9824451-5
Índice
1) Projeto a BD - Distribuído
a) Suporte a fragmentação
b) Mecanismos de replicação
- Quiescing Master Groups
- Snapshot Replication
- Read-Only Snapshots
- Updateable Snapshots
- Snapshot Refresh
- Snapshot Log
- Deployment Templates
- Online and Offline Instantiation
- Multimaster and Snapshot Hybrid
- Resolução de Conflitos
2) Controle do Ambiente Distribuído
a) Gerenciamento de view
- A Cláusula WITH CHECK OPTION
- A Cláusula WITH READ ONLY
- Visões Materializadas
b) Controle de segurança
- Domínio de Segurança
- Profiles
- Privilégios
- Roles
- Criptografia
c) Controle de Integridade
- Integridade Referencial entre as visões materializadas
3) Transparência
a) Transparência de distribuição (rede)
b) Transparência de replicação
c) Transparência de fragmentação
4) Processamento Distribuído de Consulta
a) Suporte ao processamento distribuído de consulta
b) Tipo de otimizador de consulta utilizado
- Cost-Based Optimizer (CBO)
- Caminhos de acesso para o RBO
- Full Table Scans
- Sample Table Scans
- Table Access by Rowid
- Cluster Scans
- Hash Scans
- Index Scans
- Rule-Based Optimizer (RBO)
3
3
3
5
5
6
7
8
8
8
8
9
10
11
11
11
12
12
13
13
14
14
16
16
16
17
17
17
18
19
19
19
19
19
20
20
21
21
21
21
22
22
2
- Caminhos de acesso para o RBO
- Rank e caminhos de acesso
c) Mecanismo de otimização de consulta distribuída
5) Processamento Distribuído de Transação
a) Suporte ao Processamento Distribuído de Transação
- Two-Phase Commit(2PC)
b) Protocolo de Recuperação
6) Suporte a acesso a dados de SGBD Heterogêneo
7) Bibliografia
22
22
26
27
27
27
28
28
30
1) Projeto de BD – Distribuído
a) Suporte à fragmentação ( horizontal, vertical, híbrida ):
O Oracle não implementa qualquer tipo de fragmentação. É sugerido a criação
VIEWS.
b) Mecanismos de Replicação:
O Oracle implementa três mecanismos de replicação:
- Multimaster Replication ( conhecido também como peer-to-peer ou nway replication):
Autoriza vários sites, agindo como pares, para gerenciar grupos de
objetos replicados do banco de dados. Cada site é um site master e nessa
configuração, as aplicações podem atualizar qualquer tabela replicada em
qualquer site.
O servidor Oracle opera como um site master trabalhando para
convergir dados de todas as tabelas replicadas e assegurar consistência para
as transações globais e integridade de dados.
A maneira mais comum de implementar é através da Replicação
Assíncrona ( mas também possível fazê-lo usando replicação síncrona e
procedural ). Quando se usa a replicação assíncrona, o update em uma tabela
é guardado em uma “fila” de transações no site master, onde a mudança
3
ocorreu. Essas mudanças são chamadas de transações adiadas ( deferred
transactions ). As transações adiadas são propagadas para os outros sites
masters em intervalos regulares sendo possível controlar o seus tempos.
O problema de se usar replicação assíncrona é a ocorrência de
conflitos, caso valores de uma mesma tupla sejam modificados ao mesmo
tempo em sites masters diferentes, mas técnicas podem ser usadas para evitar
este problema. Caso ele aconteça, o Oracle dispõe de mecanismos para
resolvê-los.
4
Na replicação síncrona, as mudanças feitas no site master ocorrem
imediatamente em todos sites masters participantes. Se por algum motivo o
site máster não conseguir realizar a transação, essa é desfeita em todos os
sites master ( rollback ). Quando um conflito ocorre requer muita agilidade e
maciez para resolver o problema. Se a conexão com um dos site master não
for possível, por exemplo, nenhuma transação pode ser completada até que
essa seja re-estabelecida .
Aplicações processadas em modo batch podem realizar mudanças em
uma grande quantidade de dados com uma única transação. Nesse caso,
típicas replicações estarão na rede com muitas mudanças de dados. Para
resolver esse problema, essas aplicações podem usar a replicação
procedural para replicar simples chamadas a stored procedure para
convergir a replica dos dados. A replicação procedural replica somente a
chamada para a stored procedure que a aplicação usa para realizar um update
na tabela, não replicando a modificação dos dados. Para ser usada, é
necessário replicar as packages que modificam dados no sistema para todos
os sites, depois disso é preciso gerar o wrapper para a package em cada
site.Quando uma aplicação chama essa packaged procedure no site local para
modificar dados, o wrapper assegura que a chamada é feita para a mesma
packaged procedure em todos os outros sites. A replicação procedural pode
ocorrer assíncronamente ou síncronamente. O conflito nesse caso é quase
nulo porque como essa replicação é usada para bancos de dados modificados
somente com muitas operações batch essas transações não seriam para o
mesmo dado.
- Quiescing Master Groups
Às vezes é necessário interromper todas as atividades de replicação
em um grupo de masters, para realizar certas tarefas de administração no
mesmo. Por exemplo, as atividades de replicação são paradas para editar as
Data Definition Language ( Create, Alter, Drop ) em qualquer tabela do
grupo. O nome que se dá quando se pára todas as replicações é quiescing.
Quando o grupo de masters é quiesced, usuários não podem realizar Data
Manipulation Language ( Select, Insert, Update, Delete ) em qualquer dos
objetos do grupo de masters.
- Snapshot Replication :
O snapshot contém a cópia completa ou parcial de uma tabela master
de um ponto do tempo. O snapshot pode ser read-only ou updateable.
Todos snapshots apresentam os seguintes benefícios:
 Acesso local, o que melhora o tempo de resposta e torna os
dados mais acessíveis.

Diminui as queries para o site master, porque acessam os
dados locais ( snapshot local ).

Aumenta a segurança dos dados, autorizando a réplica de
apenas algumas tabelas do master.
5
- Read-Only Snapshots
Na configuração básica, o snapshots pode prover o acesso read-only
nas tabelas originadas do site master. Aplicações podem realizar acessos a
dados dos snapshots read-only para evitar congestionamentos na rede. No
entanto, as aplicações precisam acessar o site master para realizarem
qualquer alteração ( Update ). As tabelas masters do snapshots read-only não
precisam pertencer ao grupo master.
Snapshots read-only permitem os seguintes benefícios:
 Eliminam a possibilidade de conflito porque não podem ser
atualizados.
 Suportam snapshots complexos. Exemplos de snapshots
complexos são aqueles que contêm set operations (UNION,
INTERSECT, ou MINUS ) ou a clausula CONNECT BY.
6
- Updateable Snapshots
Em uma configuração mais avançada, pode ser criado um updateable
snapshot que permite usuários realizarem insert, update, e delete tuplas da
própria tabela master. O updateable snapshot pode também conter só
algumas tabelas. Updateable snapshots são baseados em tabelas do site
master que apóiam a replicação. O fato é que updateable snapshots precisam
ser uma parte do snapshot group que é baseado no grupo de masters do site
master.
Updateable snapshots têm as seguintes propriedades:

São sempre baseados em tabelas simples.

Podem ser atualizado.

O Oracle propaga as mudanças feitas em um updateable
snapshot para as tabelas no master. Se necessário, atualiza as
tabelas do master e propaga para os outros sites masters.

O Oracle pode atualizar o updateable snapshot como parte da
atualização do grupo da mesma maneira que acontece no
read-only snapshots.
Updateable snapshots propiciam dos seguintes benefícios:

Deixam o usuário fazer consultas e atualizações nas réplicas
locais mesmo quando estão desconectados do site master.

Requerem menos recursos que o multimaster replication,
ainda suportando atualizações aos dados.
7
- Snapshot Refresh
Para assegurar que o snapshot é consistente com a master table, é
necessário atualiza-lo o snapshot periodicamente. O Oracle possui três
métodos para atualizar os snapshots:

Fast refresh: usa os snapshot logs para atualizar só as tuplas
que tiveram alteração desde o ultimo refresh.

Complete refresh: atualiza todo o snapshot.

Force refresh realiza o fast refresh quando possível. Quando
não é possível fazê-lo, realiza o complete refresh.
Quando é importante para os snapshots serem transacionalmente
consistentes uns com os outros, pode-se organizá-los em refresh groups.
Atualizando o refresh group, assegura-se que os dados em todos os
snapshots do refresh group estão consistentes transacionalmente naquele
momento. Um snapshot no refresh group ainda pode ser atualizado
individualmente, mas com isso anula os benefícios do refresh group porque
atualizando individualmente o snapshot não atualiza os outros snapshots do
refresh group.
- Snapshot Log
Snapshot log é uma tabela que grava todas as mudanças referentes à
Data Manipulation Language ( Select, Insert, Update, Delete ) para uma
master table. Um snapshot log é associado a uma única master table, e cada
master table tem somente um snapshot log. Um fast refresh de um snapshot é
possível somente se o snapshot da master table tem um snapshot log.
Quando um snapshot realizar um fast refresh, as entradas do snapshot
associadas ao snapshot log que apareceram desde de que ele foi atualizado
são aplicadas no snapshot.
- Deployment Templates
Deployment templates simplificam a tarefa de guardar e manter
vários sites snapshots remotos. Usando deployment templates, pode-se
definir uma coleção de snapshot definidos num master site, e também usar
parâmetros na definição. Assim os snapshots podem ser customizados para
usuários individuais ou grupos específicos.
Por exemplo, deve-se criar um formulário para vendas e outro para
pesquisa. Nesse caso, o valor do parâmetro deve ser território de vendas ou
nível de suporte ao consumidor. Quando um usuário remoto conecta ao
master site, este pode selecionar uma lista de formulários disponíveis.
Quando instancia um formulário, os snapshots apropriados são criados e
populados no site remoto. Os valores apropriados aos parâmetros podem
tanto ser fornecidos pelo usuário remoto quanto ser tomado da tabela
mantida do site master.
8
- Online and Offline Instantiation
Quando um usuário instancia um formulário em um site snapshot, o
objeto DDL (por exemplo, CREATE SNAPSHOT... ou CREATE TABLE...)
é executado para criar o esquema apropriado para o site snapshot, e este
populado com os dados compatíveis.
Usuários podem instanciar formulários enquanto conectados ao site
master através da rede (online instantiation), ou enquanto desconectado dele
(offline instantiation).
Offline instantiation é bastante usado para diminuir o trabalho do
servidor durante os períodos de pico e para reduzir a quantidade de conexões
remotas. Para instanciar um formulário offline, junta-se o formulário e os
dados requeridos em algum tipo de mídia de armazenamento, como fita, CDROM, e assim por diante. Então, em vez de colher o dado do site master,
usuários colhem da mídia de armazenamento que contem o formulário e
dados.
- Multimaster and Snapshot Hybrid:
Multimaster replication e snapshots podem ser configurados juntos (
hybrid ) ou "misturados" para atender a diferentes requisições de aplicações.
Na “mistura” dessas configurações podem aparecer vários sites masters e
múltiplos snapshot sites de cada master.
Por exemplo, multimaster (or n-way) replication entre does masters
pode suportar full-table replication entre os bancos de dados que abrengem
duas regiões geográficas. Snapshots podem ser definidos num masters para
replicar full tables ou table subsets para sites de cada região.
9
A diferença chave entre snapshots e replicated masters são as seguintes:

Replicated masters têm que conter todos os dados da tabela
que foi replicada, já o snapshots podem replicar sub-conjuntos
da tabela master.

Multimaster replication permite replicar mudanças para cada
transação assim que essas ocorram. Snapshot refreshes são
orientados, propagando mudanças para múltiplas transações
com mais eficiência, operações batch-oriented, mas com
intervalos menos freqüentes.

Sites masters detectam e resolvem os conflitos que ocorrem
pelas mudanças, ao mesmo tempo, nas múltiplas cópias.
Resolução de Conflitos:
Quando o Oracle replica tabelas, qualquer Data Manipulation Language (
Select, Insert, Update, Delete ) que possa causar conflito de dados é
automaticamente detectado pelo servidor Oracle no site master. Isso em qualquer
replicação de sites ( master ou snapshot ). Sites snapshots não conseguem detectar
ou resolver nenhum conflito de dados, qualquer desses introduzidos pelo site
snapshot são detectados e resolvidos pelo site master do snapshot.
Por exemplo, se o seguinte master group é agendado para propagar
mudanças de uma em uma hora, considere o que acontece quando:
Time
Master Site A
Master Site B
Status
8:00
Propago Mudanças para Propago Mudanças para Dados convergidos.
AM
o Master Site B
8:15
Atualizo Linha 1
o Master Site A
AM
8:30
Atualizo Linha 1
AM
9:00
Propago Mudanças para Propago Mudanças para Conflito Detectado na
AM
Master Site B
Master Site A
Linha 1
10
Se o tempo entre as propagações é um intervalo considerado e dois ou mais
sites atualizam a mesma linha durante esse intervalo, ocorre um conflito.
Além do conflito de atualizar existe o de insert e de delete. Como no caso do
exemplo, o conflito ocorre caso aconteça no mesmo intervalo.

Conflito de Update: dois ou mais updates são realizados para a mesma
linhaantes que o processo de update possa ser propagado para os outros
sites.

Conflito de Uniqueness: um insert é realizado em dois ou mais sites e a
chave primária ( ou outro da unique columns ) para cada insert contem o
mesmo valor, ou um update num site que modifica a chave primária ( ou
outro da unique columns ), que contenha o masmo valor já inserido em
um outro site.

Conflito de Delete: uma linha é deletada em um site e um update ocorre
em outro site, isso pode resultar em um update a uma linha que nao
existe, ou a mesma linha é deletada no mesmo intervlo de tempo em
mais de um site.
Quando um conflito de dados é detectado, as seguintes ações ocorrem:

O método de resolução de conflitos tenta resolver o conflito.

Se o conflito não for resolvido, esse é guardado em uma fila de erros
no site onde o correu.
Se o conflito é guardado em uma fila de erros, o administrador do bando de
dados é responsável por resolver manualmente esse conflito.
Se for escolhido para usar o Oracle ou definido pelo usuário o método de
resolução de conflitos, o servidor Oracle automaticamente tenta resolver o conflito.
O método de resolução de conflito, que são implementados, devem estar de acordo
com a regra de negócio definidas para o método de replicação e devem trabalhar
para garantir a consistência dos dados.
2) Controle do Ambiente Distribuído
a) Gerenciamento de view
As views podem ser de dois tipos: Simples e Complexas.
O tipo simples e composto por apenas um SELECT, utiliza apenas uma tabela e
suas colunas são formadas por colunas da tabela original, sem cálculos ou funções.
A view complexa é aquela onde há um join entre tabelas na subquery.
Nota:
1. Com uma VIEW simples serra possível executarmos comandos INSERT,
UPDATE e DELETE(alem do SELECT);
11
2. A manipulação dos dados através de uma VIEW não desabilita as constraints
das tabelas as quais os mesmos se referem;
3. Cada coluna definida para VIEWs deve ter um nome de coluna valido;
4. Caso seja uma formula, deve possuir um alias.
A Cláusula WITH CHECK OPTION
Podemos garantir que os dados inseridos ou atualizados numa tabela através de uma
view, poderão ser visualizados através da própria view com esta opção.
Exemplo:
Criando uma view
CREATE OR REPLACE VIEW ALUNOS_V_UF
AS SELECT *
FROM ALUNOS
WHERE estado = `RJ`
WITH CHECK OPTION CONSTRAINT ALUNOS_V_UK_CK;
Atualizando a view ALUNOS_V_UF
UPDATE ALUNOS_V_UF
SET estado = `BA`;
Nota:
Uma mensagem de erro serra exibida pois estamos tentando, através da view que
somente visualiza o estado `RJ`, altera-lo para `BA`, o que certamente impediria o acesso a
tabela pela view, pois esta tentaria construir a query restringindo pelo `RJ`.
A Cláusula WITH READ ONLY
Podemos impedir operações DML sobre view, criando-a com a opção WITH READ
ONLY, o que a restringe apenas a operações de leitura.
Exemplo:
Criando uma view
CREATE OR REPLACE VIEW ALUNOS_V_UF
AS SELECT *
FROM ALUNOS
WHERE estado = `RJ`
WITH READ ONLY;
Deletando dados da view ALUNOS_V_UF
DELETE FROM ALUNOS_V_UF;
12
Nota:
A view esta protegida para operações DML, portanto causara erro qualquer tentativa
de inserção, atualização ou deleção.
Visões Materializadas
São usadas para agregar dados e melhorar o desempenho da consulta. Uma visão
materializada é idêntica em estrutura a um snapshot – ela é uma tabela física que contem os
dados que normalmente seriam lidos com uma visão. Quando cria uma visão materializada,
você especifica a consulta base da visão, bem como uma programação para as atualizações
de seus dados. Em seguida, você pode indexar a visão materializada para melhorar o
desempenho das consultas feitas nela. Como resultado, você pode fornecer dados aos
usuários no formato que eles precisam e indexados adequadamente.
As visões materializadas podem ser usadas dinamicamente pelo otimizador para
alterar os caminhos de execução das consultas. Esse recurso, chamado regravação de
consulta, permite que o otimizador use uma visão materializada no lugar da tabela
consultada pela visão materializada, mesmo que a visão materializada não seja nomeada na
consulta. Por exemplo, se tiver uma tabela SALES por região. Se um usuário for consultar a
tabela SALES para obter a soma dos dados de SALES para uma região, o Oracle pode
redirecionar essa consulta para usar a sua visão materializada no lugar da tabela SALES.
Como resultado, você pode reduzir o numero de acessos a sua tabela maior , melhorando o
desempenho do sistema.
Exemplo:
Criando uma visão materializada
CREATE MATERIALIZED VIEW SALES_MONTH_MV
TABLESPACE AGG_DATA
REFRESH COMPLETE
START WITH SYSDATE
NEXT SYSDATE + 1
ENABLE QUERY REWRITE /* permite que o otimizador redirecione as consultas a
sales para sales_month_mv se for apropriado */
AS
SELECT SALES.Sales_Month, PRODUCT.Product_Type, CUSTOMER.Customer_Type,
SUM(SALES.Amount)
FROM SALES, PRODUCT, CUSTOMER
WHERE SALES.Product_ID = PRODUCT.Product_ID
And SALES.Customer_ID = CUSTOMER.Customer_ID
GROUP BY SALES.Sales_Month, PRODUCT.Product_Type,
CUSTOMER.Customer_Type;
13
b) Controle de segurança
Um usuário e o proprietário do que chamamos de “schema”, ou seja, um conjunto
de objetos pertencentes a este usuário. Um schema Oracle esta intimamente ligado a um
usuário ou conta, conforme preferimos chamar.
O schema só começa a ter sentido a medida que o usuário possui objetos próprios.
Caso contrário, a este usuário serão repassados direitos de acessos e operações
sobre objetos de outro schema.
Domínio de Segurança
O banco de dados Oracle possui um conjunto de objetos que relacionam-se com os
seus usuários que tem como objetivo manter o gerenciamento de acesso e a segurança dos
dados nele contido.
Um domínio da segurança pode estar associado a um determinado schema e pode
ser composto de objetos como privilégios, roles, profiles, quotas e resource limits.
Objetos
Privilégios
Role
Profiles
Quotas
Resource Limit
Descrição
São regras de segurança aplicadas a um determinado
usuário.
Objeto criado no banco de dados e que pode ser
associado a um determinado schema. Uma role e um
agrupamento de privilégios ou outras roles e é
utilizada para facilitar a administração de privilégios
em um banco de dados.
É um conjunto que contém uma certa quantidade de
limites para recursos do sistema, utilizado para
facilitar a administração destes. Um profile também
pode ser associado a um usuário.
São objetos associados a um usuário e que são
utilizados para controlar a quantidade de espaço
utilizado por este em uma determinada tablespace.
São limites impostos a determinados recursos do
sistema que são associados com um determinado
usuário. Um resource limit pode ser associado a um
profile.
Profiles
Um profile constitui um conjunto de limites sobre os recursos do banco de dados.
Podemos utilizar profiles para limitar os recursos disponíveis ao usuário por chamada de
procedimento ou por sessão como um todo.
Por exemplo, quando o usuário excede um limite tipo CONNECT_TIME ou
IDLE_TIME, o Oracle faz um rollback na transação corrente e termina sua sessão, caso não
seja especificado o usuário estará associado ao profile default, que não impõe limites de
recurso(UNLIMITED).
14
Nota:
Para que os limites de recurso sejam controlados pelo Oracle, devemos habilitar o
parâmetro RESOURCE_LIMIT = TRUE, que terá validade a nível de instancia, ou então,
através de ALTER SYSTEM SET RESOURCE_LIMIT = TRUE|FALSE.
Os limites que envolvem senhas estão sempre habilitados, independente do valor do
parâmetro acima.
Privilégios
Existem dois tipos de privilégios num banco de dados Oracle. Privilégios de sistema
e privilégios de objetos.
Privilégios de sistema permitem conectar-se ao banco de dados, utilizar os recurso
que estão disponíveis, criar, alterar ou remover objetos, etc. Geralmente só pode ser
concedidos aos usuários por um DBA, ou algum usuário que tenha privilégios para tal.
Exemplo:
GRANT <PRIVILEGIO> [, <PRIVILEGIO> …]
TO <USUARIO> [, <USUARIO> …] | <ROLE> [,<ROLE> …] | PUBLIC
[WITH ADMIN OPTION]
<PRIVILEGIO>
<USUARIO>
<ROLE>
PUBLIC
WITH ADMIN OPTION
Tipo de privilegio de sistema do Oracle
Usuário que recebera os direitos
Role que recebera os direitos
Todos os usuário cadastrados no Oracle
Usuário recebedor do privilegio poderá
repassá-lo igualmente a outro usuário
qualquer
Privilégios de objetos podem ser cedidos por qualquer usuário que possua objetos
no seu schema ou tenha privilégios para faze-lo.
Exemplo:
GRANT <PRIVILEGIO> [, ...] | ALL [(<COLUNA>)] ON [<SCHEMA>].<OBJETO>
TO <USUARIO> [, …] | <ROLE> [, …] | PUBLIC
[WITH GRANT OPTION]
<PRIVILEGIO>
<COLUNA>
Tipo de privilegio de objeto do Oracle como
permissão para executar comandos tipo:
select, update, delete, insert ou todos.
Privilégios do tipo insert ou update podem
restringir o acesso a determinadas colunas.
No caso do insert, todas as colunas
15
<SCHEMA>
<OBJETO>
<USUARIO>
<ROLE>
PUBLIC
WITH GRANT OPTION
obrigatórias devem ser especificadas.
Schema que pertence o objeto, default e o
schema do usuário que esta cedendo os
direitos.
Nome do objeto que serra cedido direitos
Usuário que recebera os direitos
Role que recebera os direitos
Todos os usuário cadastrados no Oracle
Permite ao <USUARIO> recebedor dos
direitos, repassa-los a outros usuários. Caso
o dono original revogue estes direitos, todos
que receberam em cascata, também
perderão.
Para remover um privilegio dado utilizamos o comando REVOKE, independente do
tipo de privilegio, seja de sistema ou de objeto.
Exemplo:
REVOKE <PRIVILEGIO> [, <PRIVILEGIO> ...]
FROM <USUARIO> [, <USUARIO> ...] | <ROLE> [, <ROLE>] | PUBLIC; (SISTEMA)
REVOKE (<PRIVILEGIO> [, <PRIVILEGIO> ...] | ALL) ON [<SCHEMA>].<OBJETO>
FROM (<USUARIO> [, <USUARIO> …] | <ROLE> [, <ROLE>] | PUBLIC)
[CASCADE CONSTRAINTS];(OBJETOS)
Roles
Conjuntos de privilégios que podem ser atribuídos ou retirados de uma só vez para
os devidos usuários, ou outras roles. O Oracle possui roles já definidas como: DBA,
CONNECT E RESOURCE. A DBA e atribuída a usuários administradores, traz consigo
todos os privilégios do sistema. Já a CONNECT E RESOURCE são roles típicas de
usuários desenvolvedores do ambiente Oracle.
Exemplo:
CREATE ROLE <NOME_ROLE>
[IDENTIFIED BY (<PASSWORD> | <EXTERNALLY>) | NOT IDENTIFIED];
Criptografia
O Oracle permite a criptografia de senhas antes de transmiti-las. Para ativar a
criptografia de senha e definido os seguinte parâmetros:
Para maquinas clientes o parâmetro ORA_ENCRYPT_LOGIN no arquivo
sqlnet.ora deve ser TRUE.
Para maquinas servidoras o parâmetro DBLINK_ENCRYPT_LOGIN no arquivo
init.ora deve ser TRUE.
16
Após esses parâmetros estarem definidos as senhas serão enviadas do cliente para o
servidor e de um servidor para o outro de forma criptografada.
A senha criptografada e armazenada no dicionário de dados, a mesma senha para
contas diferentes resultara em criptografias diferentes. Para todas as senhas, o valor
criptografado tem 16 caracteres de comprimento e contem números e letras maiúsculas.
Quando uma senha e inserida durante uma validação de usuário, aquela senha e
criptografada e a criptografia gerada e comparada com aquela do dicionário de dados
daquela conta. Se elas coincidirem, a senha esta correta e a autorização e bem-sucedida.
c) Controle de Integridade
Integridade Referencial entre as visões materializadas
A integridade relacional entre duas tabelas relacionadas, sendo que ambas tem
visões materializadas simples que se baseiam nelas, pode não ser implantada em suas
visões materializadas. Se as tabelas forem atualizadas em momentos diferentes ou se as
transações ocorrerem nas tabelas master durante a atualização, e possível que as visões
materializadas dessas tabelas não reflitam a integridade referencial das tabelas master.
Também pode acontecer uma falha do banco de dados ou servidor durante a
execução do procedimento de atualização, REFRESH_ALL, atualização das visões
materializadas.
Como alternativa, criação de grupos de atualização. A finalidade e coordenar as
programações de atualização de seus membros. As visões materializadas cujas tabelas
master tem relacionamento com outras tabelas master são boas candidatas para entrarem no
grupo de atualização.
A coordenação das programações de atualização das visos materializadas também
manterá a integridade referencial das tabelas master na visão materializada. Se não forem
usados os grupos de atualização, os dados de visões materializadas podem ser
inconsistentes com relação a integridade referencial das tabelas master.
3) Transparência
a) Transparência de Distribuição (rede)
Não existe no Oracle nem na maioria dos SGBDD’s. É implementada através do
uso de sinônimos pelos DBA’s, que apesar de simular essa transparência não é realmente
uma transparência de distribuição, onde é feita uma transparência de localização..
É implementada através da colocação das quatro partes do nome – o host, a
instância, o proprietário e o nome – resultando em um nome global do objeto. Para acessa
ruma tabela remota é necessário que o nome global dessa tabela seja conhecido. Essa
transparência de localização tem como objetivo tornar as três primeiras partes do nome do
objeto global – host, instância e esquema – transparentes para o usuário. Exata três
primeiras partes do objeto global são especificadas através dos links de banco de dados, de
17
modo que todo serviço para atingir a transparência de localização deve começar nesse
ponto. Logo abaixo segue um exempl de de link de BD típico:
create public database link HR_LINK
connect to HR identified by PUFFINSTUFF
using ‘hq’;
Usando um nome de serviço (hq), os nomes de host são mantidos transparentes.
Exemplo de descrição do serviço hq:
hq = (DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = HQ)
(PORT = 1521))
(CONNECT DATA =
(SID = LOC))))
As duas linhas em negrito dessa listagem preenchem as duas partes que faltam do
nome do objeto global: Quando o nome do serviço HQ é usado, o nome do host é HQ e o
nome da instância é LOC.
Para resolver a transparência da parte do esquema do nome do objeto global, você
pode modificar a sintaxe de link de banco de dados, como no exemplo abaixo:
create public database link HR_LINK
connect to current_user
using ‘hq’;
Este link usa a cláusula connect to current_user. Ele usará aquilo que é conhecido
como conexão de usuário conectado, enauqnto enquanto o exemplo anterior era uma
conexão de usuário fixo. Veja abiaixo um exemplo desse link em uso:
select * from EMPLOYEE@HR_LINK;
Quando HR_LINK é usado, o banco de dados resolve o nome do objeto global da
seguinte maneira:
1. Pesquisa no arquivo o tnsnames.ora local para determinar o nome de host
adequado, a porta e o nome da instância.
2. Verifica o link de banco de dados e procura uma especificação connect to. Se a
cláusula connect to current_user for encontrada, ele tenta se conectar ao banco de dados
especificado usando o nome de usuário e a senha do usuário conectado.
3. Pesquisa a cláusula from da consulta e procura o nome do objeto.
b) Transparência de Replicação
18
Havendo a encessidade de replicação de dados e estas serem relativamente
limitadas, pode-se fazer o uso de triggers do banco de dados para replicar os dados de uma
tabela para outra, porém, esse método é usado quando o único tipo de dados enviado par ao
banco de dados remoto é uma operação de insert ou delete. O código necessário para dar
suporte às transações de update geralmente é muito mais complexo do que uma visão
materializada comparável.
Os triggers de banco de dados são executados quando ocorrem ações específicas.
Eles podem ser executados para cada linha de uma transação, para toda uma transação
como uma unidade ou quando ocorrem eventos no nível do sistema. Ao lidar com a
replicação de dados, preocupa-se com os triggers que afetam cada linha de dados.
Mas, antes de criar um trigger relacionado à replicação, deve-se criar um link de
banco de dados que o trogger irá usar. Assim, o link é criado no banco de dados que tem a
propriedade dos dados e qe pode ser acessado pelo proprietário da tabela que está sendo
replicada.
create public database link TRIGGER_LINK
connect to current_user
using ‘remote1’;
Esse link (TRIGGER_LINK) usa um nome de serviço (remote1) para especificar a
conexão com um BD remoto. Ele tenta fazer o login no BD remote 1 usando o mesmo
nome do usuário e senha de conta que chama o link.
c) Transparência de Fragmentação
Como visto anteriormente – “Projeto de BD – Distribuído”, 1.a – o Oracle não
implementa fragmentação, só sendo possível a implementação de Transparência de
Fragmentação através da criação de VIEWS.
19
4) Processamento Distribuído de Consulta
a) Suporte ao processamento distribuído de consulta
O Oracle realiza o processamento distribuído agindo como um cliente requisitando
dados a outro servidor.
b) Tipo de otimizador de consulta utilizado
O Oracle tem dois métodos de otimização: rule-based optimizer (RBO) e cost-based
optimizer (CBO).
Cost-Based Optimizer (CBO)
Em geral, deve-se usar o cost-based. O rule-based está disponível para
qualquer aplicação.
O CBO determina qual plano de execução é mais eficiente considerando
todos os acessos disponíveis e criando informações baseadas em estatísticas para
esquema de objetos ( tabelas ou índices ) acessados pela declaração SQL. Também
aceita sugestões visando a otimização inseridas no contexto.
Passos:
1. O otimizador gera um conjunto de planos potenciais para a
declação SQL, baseada nos acessos disponíveis e sugestões.
2. O otimizador estima o custo de cada plano baseado nas
estatísticas do dicionário de dados para os dados distribuídos e
característica de armazenamento das tabelas, índices e as
partições acessadas pela declaração.
O custo é um valor estimado proporcional para estimar os
recursos necessários para executar a declaração com um plano
particular. O otimizador calcula os custos para cada método
possível de acesso e ordena baseado na estimativa dos recursos
do computador, incluindo ( mas não limitando ) I/O e memória,
que são requeridas para a execução do declaração usando o
plano.
Planos em série com maiores custos levam mais tempo para
executar que aqueles com menores custos. Quando são usados
planos paralelos os recursos não estão diretamente relacionados
com o decorrer do tempo.
3. O otimizador compara os custos dos planos e escolhe o de menos
custo.
Para manter os melhores resultados o CBO deve reunir as estatísticas e
mantê-las atualizadas.
Para colunas de tabelas que contenham dados skewed ( valores com grande
variação em números duplicados ), deve-se coletar histogramas.
20
O resultado das estatísticas provem o CBO com informações sobre unicidade
de dados e distribuição. Usando essas informações, o CBO está apto para calcular o
custo dos planos com grande grau de exatidão. Isso possibilita o CBO escolher o
melhor plano de execução baseado no menos custo.
Caminhos de acesso para o RBO:
Uma das escolhas mais importantes o otimizador faz quando formula o plano
de execução é como faz para retirar dados do banco de dados. Para cada linha em
cada tabela associada pela declaração SQL, deve ter vários caminhos de acesso para
que cada linha poder ser alocada e retirada.
O otimizador escolhe um desses:
Full Table Scans
Um full table scan recupera linhas de uma tabela. Para realizar um full table
scan, o Oracle lê todas as linhas da tabela, examinando cada linha para determinar
de qual forma isso satisfaz a clausula WHERE da declaração. O Oracle lê todo
bloco alocado de dados para tabelas seqüenciais, assim um full table scan pode
realizar com muita eficiência usando leitura a blocos. O Oracle lê bloco de dados
somente uma vez.
Sample Table Scans
Um sample table scan recupera um exemplo randômico de dados de uma
tabela. Esse método de acesso é usado quando o clausula FROM da declaração
inclui a clausula SAMPLE ou SAMPLE BLOCK. Para realizar um sample table
scan quando exemplifica para linhas ( a clausula SAMPLE ), o Oracle lê um
específico percentual de linhas de uma tabela e examina cada uma dessas linhas
para determinar de qual forma isso satisfaz a clausula WHERE da declaração. Para
realizar um sample table scan quando exemplificado para blocos ( a clausula
SAMPLE BLOCK ), o Oracle lê um percentual específico de blocos de tabelas a
examina cada linha do bloco exemplificado para determinar de qual forma isso
satisfaz a clausula WHERE da declaração.
O Oracle não suporta sample table scans quando a query envolve uma
junção ou uma tabela remota. Mesmo assim, pode-se realizar uma operação
equivalente usando uma query CREATE TABLE AS SELECT para materializar um
exemplo de uma tabela básica e reescrever a query original para referenciar o
exemplo da nova tabela criada. Adicionalmente queries podem ser escritas para
materializar exemplos para outras tabelas. Sample table scans requer o CBO.
Table Access by Rowid
A table access by rowid também recupera linhas de uma tabela. O rowid de
uma linha especifica o datafile e o data block que contem a linha e a localização da
linha naquele bloco. Localizando uma linha pelo seu rowid é a maneira mais rápida
para o Oracle localizar um única linha.
Para acessar a tabela pelo rowid, o Oracle primeiro obtém os rowids das
linhas selecionadas, tanto pela cláusula WHERE da declaração quanto através de
21
um index scan de um ou mais índices de tabela. O Oracle então aloca cada linha
selecionada na tabela baseada no rowid.
Cluster Scans
Para uma tabela armazenada em um índice cluster, o cluster scan recupera
linhas que tenham o mesmo valor cluster key. Em um índice cluster, todas as linhas
com o mesmo valor cluster key são armazenados o mesmo bloco de dados. Para
realizar o cluster scan, o Oracle primeiro obtem o rowid de uma das linhas
selecionadas para procurar o índice cluster. O Oracle então aloca as linhas baseadas
no seu rowid.
Hash Scans
O Oracle pode usar o hash scan para alocar linhas em um hash cluster
baseado no valor hash. Em um hash cluster, todas as linhas com o mesmo valor hash
são armazenados nos mesmos blocos de dados. Para realizar o hash scan, o Oracle
primeiro obtem o valor hash para aplicar uma função hash para um valor cluster key
especificado pela declaração. O Oracle então localiza os blocos de dados que
contem linhas com o mesmo valor hash.
Index Scans
Um index scan recupera dados de um índice baseado no valor de uma ou
mais colunas de índeces. Para realizar um index scan, o Oracle procura o índice na
coluna indexada por valores associados pela declaração. Se a declaração acessa
somente colunas de indices, então o Oracle lê os valores das colunas indexadas
diretamente para o índice, melhor que da tabela.
O índice não contem somente o valor indexado, mas também o valor dos
rowids de cada linha. Logo, se a declaração acessar outras colunas incluindo
colunas indexadas, então o Oracle pode procurar as linhas na tabela com acesso a
um tabela pelo rowid ou cluster scan.
Rule-Based Optimizer (RBO)
Mesmo o Oracle suportando o otimizador rule-based, deve-se designar as
novas aplicações para usar o otimizador cost-based. Deve-se também usar o CBO
para aplicações de data warehousing, porque ele suporta melhorias para DSS. Várias
melhorias de performance, assim como tabelas particionadas, melhoria do
processamento de star query, e views materializadas, estão somente disponíveis para
o CBO.
Caminhos de acesso para o RBO:
No RBO o otimizador escolhe um plano de execução baseado nos caminhos
de acesso disponíveis e o rank deles. No Oracle o ranking desses caminhos de
acessos é heurístico. Se tiver mais de uma maneira de executar a declaração SQL,
então o RBO sempre a operação com o mais baixo no rank. Usualmente, as
operações mais baixas no rank executam mais rápido do que aquelas associadas
com construtores do topo do rank.
22
Rank e caminhos de acesso:
1a. Single Row by Rowid
Está disponível apenas se a clausula WHERE da declaração identificar as
linhas selecionadas pelo rowid ou com o dado corrente do cursor embutido na
sintaxe SQL suportado pelo pré-compilador do Oracle. Para executar a declaração, o
Oracle acessa a tabela pelo rowid.
2a. Single Row by Cluster Join
Está disponível para declarações que juntam tabelas armazenadas no mesmo
cluster se as duas seguintes condições forem verdadeiras:

a clausula WHERE da declaração contem condições que igualam cada
coluna do cluster key em uma tabela com a coluna correspondente na
outra tabela.

a clausula WHERE da declaração também contem um condição que
garante que a junção retorne uma única linha. Tal condição é feita para
ter uma igualdade de condição na coluna(s) de uma unique ou primary
key.
Essas condições devem ser combinadas com operadores AND. Para executar
a declaração, o Oracle realiza a operação em loops aninhados.
3a. Single Row by Hash Cluster Key with Unique or Primary Key
Está disponível se as duas seguintes condições forem verdadeiras:

A clausula WHERE da declaração usa todas as colunas de uma hash
cluster key em igualdade de condições. Para compor os cluster keys, a
igualdade de condições deve ser combinada com o operador AND.

A declaração garante o retorno de uma única linha, porque a coluna que
faz uma hash cluster key também faz uma unique ou primary key.
Para executar a declaração, o Oracle aplica a função hash do cluster para um
valor hash cluster key especificado na declaracao para obter o valor hash. O Oracle
então usa o valor hash para realizar o hash scan na tabela.
4a. Single Row by Unique or Primary Key
Está disponível se a clausula WHERE da declaração usar todas as colunas de
uma unique ou primary key em igualdade de condições. Para compor as chaves, as
igualdades de condições devem ser combinadas com o operador AND. Para
executar a declaração, o Oracle realiza um unique scan no índice da uma unique ou
primary key para recuperar um único rowid, e então acessar a tabela pelo rowid.
23
5a. Clustered Join
Está disponível para declarações juntam tabelas armazenadas em um mesmo
cluster se a clausula WHERE da declaração conter condições que igualam cada
coluna do the cluster key em uma tabela com a coluna correspondente em outra
tabela. Para compor um cluster key, as igualdades de condições devem ser
combinadas com o operador AND. Para executar a declaração, o Oracle realiza a
operação em loops aninhados.
6a. Hash Cluster Key
Está disponível se a clausula WHERE da declaração usar todas as colunas de
uma hash cluster key em igualdade de condições. Para compor um cluster key, as
igualdades de condições devem ser combinadas com o operador AND. Para
executar a declaração, o Oracle aplica a função hash do cluster para um valor hash
cluster key especificado na declaracao para obter o valor hash. O Oracle então usa o
valor hash para realizar o hash scan na tabela.
7a. Indexed Cluster Key
Está disponível se a clausula WHERE da declaração usar todas as colunas de
um cluster key indexado em igualdade de condições. Para compor um cluster key,
as igualdades de condições devem ser combinadas com o operador AND. Para
executar a declaração, o Oracle realiza um unique scan no cluster index para retirar
o rowid de uma linha com o valor específico do cluster key. O Oracle então usa esse
rowid para acessar a tabela com um cluster scan. Porque todas as linhas com o
mesmo valor do cluster key estão guadados juntos, o cluster scan requer somente
um único rowid para localizar todos eles.
8a. Composite Index
Está disponível se a clausula WHERE da declaração usar todas as colunas de
um índice composto em igualdade de condições combinados com o operador AND.
Para executar a declaração, o Oracle realiza um range scan no índice para retirar os
rowids das linhas selecionadas, e então acessa a tabela por esses rowids.
9a. Single-Column Indexes
Está disponível se a clausula WHERE da declaração usar as colunas de um
ou mais single-column indexes em igualdade de condições. Para múltiplos singlecolumn indexes, as condições devem estar combinadas com o operador AND.
Se a clausula WHERE usar a coluna de um único índice, então o Oracle
executa a declaração realizando um range scan no índice para retirar os rowids das
linhas selecionadas, e então acessa a tabela por esses rowids.
Se a clausula WHERE usar colunas de varios single-column indexes, então o
Oracle executa a declaração realizando um range scan em cada índice para retirar os
24
rowids das linhas que satisfação cada condição. O Oracle então faz o merge dos
rowids para obter os rowids das linhas que satisfação todas as condições. O Oracle
então acessa a tabela usando esses rowids.
O Oracle pode fazer merge em até cinco índices. Se a cláusula WHERE usar
colunas de mais de cinco single-column indexes, então o Oracle faz o merge de
cinco deles, acessa a tabela pelo rowed, e então testa as linhas resultantes para
determinar de qual forma eles satisfazem as condições restantes antes de retorná-los.
10a. Bounded Range Search on Indexed Columns
Está disponível se a clausula WHERE da declaração conter uma condição
que use a coluna de um single-column index ou uma ou mais colunas que fazem
menção a uma porção da um composite index:
column = expr
column >[=] expr AND column <[=] expr
column BETWEEN expr AND expr
column LIKE 'c%'
Cada uma dessas condições especifica um alcance limitado ( bounded range
) dos valores indexados que são acessados pela declaração. O alcance é dito
limitado porque a condição especifica tanto o menor valor quanto o maior valor.
Para executar tal declaração, o Oracle raliza um range scan no índice, e então acessa
a tabela pelo rowid.
Isso não está disponível se a expressão expr referenciar a coluna indexada.
11a. Unbounded Range Search on Indexed Columns
Está disponível se a clausula WHERE da declaração contem uma das
seguintes condições que usa tanto a coluna de um single-column index quanto uma
ou mais colunas que fazem menção a uma porção da um composite index::
WHERE column >[=] expr
WHERE column <[=] expr
Cada uma dessas condições especifica um alcance ilimitado ( unbounded
range ) dos valores indexados que são acessados pela declaração. O alcance é ditto
ilimitado porque a condição especifica tanto o menor valor quanto o maior valor,
mas não os dois. Para executar tal declaração, o Oracle realiza um range scan no
índice, e então acessa a tabela pelo rowid.
12a. Sort-Merge Join
Está disponível para declarações que juntem tabelas que não estão
armazenadas juntas em um cluster e se a clausula WHERE da declaração usar
colunas de cada tabela em igualdade de condições. Para executar tal declaração, o
Oracle usa uma operação sort-merge. O Oracle pode também usar a operação em
loops aninhados para executar a junção.
25
13a. MAX or MIN of Indexed Column
Está disponível para declarações com SELECT, e todos as seguintes
condições são verdadeiras:

A query usa a função MAX ou MIN para selecionar o valor máximo ou o
mínimo tanto de uma coluna de single-column index quanto a menção a
um coluna de um índice composto. O índice não pode ser um índice
cluster. O argumento para a função MAX ou MIN pode ser qualquer
expressão envolvendo a coluna, uma constante, ou o operador adicional
(+), o operador concatenal (||), ou a função CONCAT.

Não tem nenhuma outra expressão na lista de select.

A declaração não tem nenhuma clausula WHERE ou GROUP BY.
Para executar a query, o Oracle realiza um range scan do índice para
localizar o maior ou o menor valor indexado. Porque somente esse valor é
selecionado, o Oracle não precisa acessar a tabela depois de realizar o scan no
índice.
14a. ORDER BY on Indexed Column
Está disponível para declarações com SELECT, e todos as seguintes
condições são verdadeiras:

A query contem uma clausula ORDER BY que usa tanto a coluna de um
single-column index quanto a menção a uma porção de um índice
composto. O índice não pode ser índice cluster.

Tem uma integridade de PRIMARY KEY ou NOT NULL que garante
que no mínimo uma das colunas indexadas listadas na clausula ORDER
BY não contenham nenhum null.

O parametro NLS_SORT é fixado para BINARY.
Para executar a query, o Oracle realiza um range scan do índice para retirar
os rowids das linhas selecionadas na ordem. O Oracle então acessa a tabela por
essas rowids.
15a. Full Table Scan
Está disponível para qualquer declaração SQL, despreocupando-se com as
condições da clausula WHERE, exceto quando a clausula FROM contem SAMPLE ou
SAMPLE BLOCK.
Note que o full table scan está no final da lista do rank, isso significaque o
RBO sempre escolhe um caminho de acesso que usa um índice se um estiver
disponível, mesmo se uma full table scan possa executar mais rápido.
26
As seguintes condições fazem o caminho de acesso ao índice indisponível:
 coluna1 > coluna2
 coluna1 < coluna2
 coluna1 >= coluna2
 coluna1 <= coluna2
onde coluna1 e coluna2 estão na mesma tabela.
 coluna IS NULL
 coluna IS NOT NULL
 coluna NOT IN
 coluna != expr
 coluna LIKE '%pattern'
despreocupando-se de que maneira a coluna é indexada.
 expr = expr2
onde expr é uma expressão que opera em uma coluna com um operador
ou função, despreocupando-se de que maneira a coluna é indexada
 NOT EXISTS subquery
 ROWNUM pseudo-coluna em uma view
 Qualquer condição envolvendo uma coluna que não está indexada
Qualquer declaração SQL que contenha somente esses construtores e não
outros que fazem disponíveis os caminhos de acesso a índices, deve usar o full table
scans.
c) Mecanismo de otimização de consulta distribuída
O otimizador escolhe planos de execução para declarações SQL que acessam
dados em bancos remotos ou somente dados locais:

Se todas as tabelas acessadas pela declaração SQL são alocadas em um
mesmo banco de dados remoto, então o Oracle envia a declaração SQL para
esse banco de dados. A instância remota do Oracle executa a declaração e
envia o resultado de volta para o banco de dados local.

Se a declaração SQL acessar tabelas que estejam alocadas em bancos de
dados diferentes, então o Oracle decompõe a declaração em fragmentos
individuais, cada um acessando tabelas em um único banco. O Oracle então
envia cada fragmento para o banco de dados que este acessa. Cada instância
remota do Oracle executa o seu referente fragmento e retorna o resultado
para o banco de dados local, onde a instância local do Oracle deve realizar
qualquer processamento adicional requerido pela declaração.
Quando escolhe um plano de execução cost-based para declaração distribuída, o
otimizador considera os índices disponíveis no banco de dados remoto assim como no
local. O otimizador também considera estatísticas no banco de dados remoto para CBO.
Além disso, o otimizado considera o local do dado quando estima o custo do acesso a
27
ele. Por exemplo, um full scan de uma tabela remota tem a melhor estimativa de custo
que o de uma tabela local idêntica.
Para um plano de execução rule-based, o otimizador não considera índices em
tabelas remotas.
5) Processamento Distribuído de Transação
a) Suporte ao Processamento Distribuído de Transação
Two-Phase Commit(2PC)
O 2PC permite que grupos de transação em diversos nós sejam tratados
como uma unidade: ou todas as transações tem o commit ou todas tem o rollback.
As duas fases do 2PC:
A fase de preparação, um nó chamado coordenador global notifica todos os
sites envolvidos na transação para estarem prontos para a transação de commit ou
de rollback.
A fase de commit, se não houver problema com a fase de preparação, todos
os sites fazem o commit de suas transações. Se ocorrer uma falha de rede ou de no,
todos os sites fazem o rollback de suas transações.
Se o nó que inicia a transação se esquecer da transação, uma terceira fase, a
fase de esquecimento, e executada.
O trabalho com banco de dados distribuídos aumenta o número de causas de
falhas em potencial durante um conjunto de transações relacionadas. Quando uma
transação distribuída esta pendente , uma entrada para essa transação aparece no
dicionário de dados DBA_2PC_PENDING. Quando a transação e concluída, os
seus registros DBA_2PC_PENDING são removidos. Se a transação estiver
pendente, mas não puder ser concluída, o seu registro permanece no
DBA_2PC_PENDING.
b) Protocolo de Recuperação
O processo de segundo plano RECO(Recoverer) verifica periodicamente as
transações distribuídas cuja conclusão falhou na visão DBA_2PC_PENDING.
Usando essas informações, o processo RECO de um no tenta recuperar
automaticamente a parte local de uma transação em duvida. Em seguida, ele tenta
estabelecer as conexões com quaisquer outros bancos de dados envolvidos na
transação e resolve a parte distribuída da transação. As linhas relacionadas das
visões DBA_2PC_PENDING de cada banco de dados são removidas.
28
6) Suporte a Acesso de Dados de SGBD Heterogêneo
O Oracle suporta o acesso a diferentes BD’s em uma arquitetura de SGBDD’s,
como o INFORMIX e SYBASE. Essa compatibilidade se faz através de um Gateway do
Oracle, onde são rescritos códigos SQL nos dois sentidos do tráfego de dados (E/S).
Para acesso a SGBDD’s diferentes do Oracle , ele possui um Gateway transparente
e agentes de de conectividade genérica, que se encontram dentro de Serviços Heterogêneos.
É necessário rodar um script para criar todos os Serviços Heterogêneos instalando
uma tabela de dicionário de dados, views e pacotes. Na maioria dos sistemas o script é
conhecido como CATHS.SQL e se localiza em $ORACLE_HOME/rdbms/admin.
Se for feita uma requisição do Oracle para um Banco de Dados remoto diferente, os
Serviços Heterogêneos do Oracle atuam da seguinte forma:
1. Traduz a requisição de SQL Oracle em uma requisição SQL equivalente que seja
entendida pelo sistema diferente do Oracle (Gateway).
2. Acessa os dados do site diferente do Oracle.
3. Torna os dados disponíveis para o servidor de BD Oracle para um seguido.
O serviço SQL provê capacidade de:
 Transformar o SQL Oracle em um uma linguagem SQL que possa ser entendida
pelos sistemas diferentes.
 Transforma as requisições SQL da tabela de dicionário de dados do Oracle em
sistemas de dicionário de dados de sistemas diferentes
 Mapeia typos de dados diferentes dos do Oracle para tipos de dados do Oracle.
Genéricamente, os agentes de conectividade usam os seguintes tipos de agentes do
Serviço Heterogêneo:
 Agente ODBC para acessar o provedor de dados ODBC;
 Agente OLE DB para acessar os provedor de dados OLE DB que suporta
processamentos SQL – algumas vezes referenciado como OLE DB (SQL);
 Agente OLE DB SQL para acessar provedores de dados sem suporte de
processamento SQL – algumas vezes referido como OLE DB (FS).
Cada sessão usuária recebe seu próprio processo agente emitido quando o primeiro
acesso ao a sessão usuário for feita por um sistema diferente do Oracle. O processo agente é
finalizado quando a sessão a usuária termina.
Exemplo de uma configuração em SGBD Oracle e SGBD diferente do Oracle em
máquinas diferentes, se comunicando através do agente de Serviços Heterogêneos (SH)
ODBC:
29
Nessa configuração o cliente se conecta ao Oracle8i através do Net8. Depois part
parte do SH do SGBD Oracle se conecta através do Net8 ao agente ODBC do SH (ou HS).
Esse agente se comunica com os SGBD’s diferentes através dos seguintes componentes:
 Um gerenciador de driver ODBC
 Um driver ODBC
 Uma aplicação de um cliente diferente do Oracle
Bibliografia

Oracle Documentation Library, Release 8.1.7.

Internet.

Oracle 9i, o Manual do DBA.
30