Aula 9 - Alta Disponibilidade e Recuperação de Desastres no Oracle

Prévia do material em texto

/
Administração de Banco de Dados III
Aula 9: Alta Disponibilidade e Recuperação de Desastres no
Oracle
Apresentação
Esta nona aula da disciplina Administração de Bancos de Dados III trata das técnicas e ferramentas disponíveis no Oracle
para implementação de funcionalidades para Alta Disponibilidade de bancos de dados Oracle e construção de soluções
para cenários de Recuperação de Desastres.
Ao �nal desta aula você será capaz de discutir sobre as opções existentes para Alta Disponibilidade e Recuperação de
Desastres no Oracle, indicando aquelas que são mais apropriadas de acordo com as características dos ambientes mais
comuns. Você será capaz de implantar soluções usando replicação de dados e de conhecer a arquitetura do Oracle RAC –
Real Application Cluster.
Objetivo
Examinar os conceitos e as técnicas disponíveis no Oracle para construção de soluções de Alta Disponibilidade e
Recuperação de Desastres;
Descrever a arquitetura do Oracle RAC – Real Application Cluster, seus principais componentes e como eles se
integram para implementar um cluster de Alta Disponibilidade;
Usar ferramentas e técnicas para implementação de replicação de dados no Oracle Database, incluindo as soluções
Oracle Data Guard e Oracle Golden Gate.
Introdução
As questões relacionadas à Alta Disponibilidade e Recuperação de Desastres devem ser endereçadas a partir de uma
abordagem adequada às necessidades do negócio e dos usuários, além de ajustada aos recursos e às técnicas disponíveis.
Nesta aula vamos abordar as técnicas disponíveis no Oracle, de forma que você possa selecionar aquelas que mais se
adaptam à sua realidade.
Inicialmente veremos o Oracle RAC – Real Application Cluster, uma solução robusta para a construção de um cluster composto
de nós ativos, capaz de prover alta disponibilidade para os serviços con�gurados e balanceamento da carga de trabalho
submetida ao cluster. Ao expandi-lo rumo a um datacenter secundário, alcançamos uma solução para cenários de disaster
recovery, na qual nós ativos do cluster podem estar segregados em uma rede distinta, em um datacenter distante �sicamente. 
/
Na segunda parte da aula vamos trabalhar com a replicação baseada em snapshots do Oracle, no ambiente multitenant. Com
essa técnica vamos ver que é possível criar réplicas dos bancos de dados, em uma solução simples e e�ciente para endereçar
não só as questões colocadas na aula, mas também provisionar ambientes segregados para consulta e exploração de dados,
atividade cada vez mais frequente no contexto de Data Science.
Oracle RAC - Real Application Cluster
Oracle RAC é uma das tecnologias mais importantes na
implementação de uma solução de Alta Disponibilidade para
bancos de dados Oracle. Com uma arquitetura shared disk,
permite que nós computacionais compartilhem arquivos em
disco, como control �les, arquivos de parâmetros, arquivos
de redo log, além dos próprios bancos de dados. Esses nós
compõem o que chamamos de RAC e, em cada nó do
cluster, uma instância do banco de dados pode estar ativa.
 Oracle RAC. Fonte: Oracle (2020).
No Oracle RAC, cada instância do banco de dados reside em um servidor do cluster, chamado nó do cluster. Na imagem
anterior temos um banco de dados (database) e três instâncias do mesmo banco, uma em cada um dos três nós do cluster.
Cada nó é conectado ao outro por meio de uma conexão especial, chamada interconnect, por onde trafegam os heartbeats.
Saiba mais
A partir desses heartbeats, o cluster monitora os nós e pode detectar, por exemplo, quando um deles apresenta uma falha. Para
implementar essa interconexão entre os nós, uma rede privada é construída. Somente os nós do cluster participam dessa rede,
isolando-os de quaisquer interferências advindas de outras.
O suporte ao Oracle RAC nasce com as versões “g” do Oracle Database. Na versão 10g, o Oracle Clusterware implementou as
funcionalidades básicas para o gerenciamento de grupos de servidores que, juntos, podem fornecer escalabilidade e alta
disponibilidade. Observe que se um nó do cluster acima falhar, os outros dois continuam o trabalho sem manobra manual
alguma, pois neles existem instâncias do mesmo banco de dados.
Uma das funcionalidades do Clusterware é manter os serviços habilitados no cluster, enquanto provê o gerenciamento dos
recursos compartilhados pelos servidores que o compõem.  
/
Os serviços são o ponto de entrada das aplicações. Note que, do lado do RAC, o que você tem são instâncias do banco de
dados funcionando em servidores separados. Como uma aplicação pode conectar-se a essas instâncias? Ela deve escolher
uma delas e realizar a conexão? Não, exatamente por conta dos serviços. Eles proveem um único ponto de conexão para as
aplicações e o Clusterware encaminha a conexão internamente para a instância mais adequada.
É aí que entra o balanceamento da carga, pois o Clusterware conhece o que está sendo processado em cada instância e
controla o encaminhamento das conexões para instâncias menos sobrecarregadas.
Para que esse encaminhamento funcione adequadamente, cada nó em um
cluster RAC possui um endereço VIP (virtual IP). Quando um cliente quer
conectar-se ao cluster, ele solicita a conexão ao serviço por meio de um
listener chamado Scan. Conhecedor das instâncias que hospedam o serviço,
o Scan seleciona uma dessas instâncias e roteia o cliente para o seu
listener, que estabelece a conexão com o cliente utilizando seu endereço
VIP e porta correspondentes. Daí em diante, o cliente está conectado ao nó
local e pode seguir com seu processamento.
Pode ocorrer de um nó falhar. Nesse cenário, os clientes conectados nas instâncias desse nó são transferidos para outras e
passam por um processo de recovery para garantir que as transações con�rmadas sejam persistidas no banco de dados. O
endereço VIP do nó com falha é transferido para um nó operacional, mas não aceita novas conexões. Ele passa a responder
com connection refused e só volta a aceitar conexões quando o nó original está ativo novamente.
Atenção
Um requisito fundamental para o Clusterware é o sistema de arquivos. Como os databases, arquivos de parâmetros, redo log �les,
entre outros, são compartilhados por todos os nós, o sistema de arquivos deve prover algumas funcionalidades para que essa
implementação seja realizada.
Oracle ASM (Automatic Storage Management) provê essas funcionalidades e é a recomendação da Oracle para suporte ao
Clusterware, muito embora ele seja compatível com outras soluções, como NFS (Network File System).
Oracle Clusterware, Oracle ASM e outros componentes de software formam o que hoje chamamos Grid Infrastructure (GI). A
instalação da GI é um pré-requisito para a construção de um RAC e nele está todo o suporte para a operação do cluster.  
ASM é um componente especial na solução porque provê uma série de recursos que permitem o compartilhamento dos
arquivos do banco de dados e permitem que todas as instâncias leiam e escrevam simultaneamente nesses arquivos. 
Dois componentes principais da infraestrutura do Grid são o Oracle Cluster Registry (OCR) e os voting disks. Você pode vê-los
no diagrama a seguir. No OCR �cam todas as informações sobre os recursos do Grid, incluindo seus membros, endereços VIP
e listeners, diskgroups do ASM, entre outros. É o catálogo de recursos do Grid. Os voting disks contêm os voting �les, que
existem para que os nós do cluster registrem que estão operacionais.
/
Dessa forma, conexões e processamentos podem ser
encaminhados. Caso um nó não faça seu registro em um
determinado intervalo de tempo (30 segundos por padrão),
ele é considerado indisponível e é removido
temporariamente do cluster. Quando volta a registrar-se nos
voting �les, é reincorporado ao cluster.
A implementação de um Oracle RAC pode ser estendida
para datacenters distintos, para a construção de uma
solução de Disaster Recovery. Veja na imagem adiante.
 Oracle RAC e ASM. Fonte: Oracle (2020).
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Os dois sites são conectados por uma rede privada combaixa latência e os nós são distribuídos entre os datacenters primário
e secundário. Observe ainda a inclusão de um terceiro site para o gerenciamento dos voting disks. Com uma implementação
desse tipo, temos garantida tanto a Alta Disponibilidade quanto uma solução para Recuperação de Desastres, na medida em
que, se o site principal �car completamente indisponível, todas as conexões podem ser direcionadas para o site secundário.
Replicação
Solução clássica para aumentar a disponibilidade dos dados, a replicação é capaz de manter cópias de esquemas em bancos
de dados distintos, seja no mesmo servidor ou em outro, no mesmo datacenter ou em outro.  
Comentário
Assim, considere essa técnica quando estiver planejando sua estratégia de trabalho, não somente no escopo da Alta
Disponibilidade e da Recuperação de Desastres, mas também na implementação de soluções práticas, por exemplo para grupos
de usuários que desejem acessar uma cópia dos dados para realizar consultas.
Atualmente, cientistas de dados precisam de fontes de dados não produtivas para realizar simulações e experimentos. Réplicas
são certamente uma alternativa nesses cenários.
No Oracle, a replicação pode ser implementada utilizando-se os próprios recursos do Oracle Database, ou a partir do Oracle
Golden Gate, uma ferramenta especí�ca para construção de replicações mais elaboradas, inclusive bidirecionais. Vamos, nesta
aula, implementar um caso prático utilizando a replicação nativa do banco de dados, que é baseada em snapshots. 
A ideia é criar um novo pluggable database na nossa instância de trabalho e con�gurar uma replicação das tabelas
CRM.Usuarios e CRM.Usuarios_Historico para esse novo banco de dados. Vamos estabelecer uma ligação entre o banco de
dados master, que é o database em que as tabelas residem e será a origem da replicação, XEPDB1, e o novo banco de dados,
que vamos chamar de CRM_replica e que será o destino da replicação.
Vamos começar criando o novo banco de dados?
/
 Criação de pluggable database. Fonte: Oracle (2020).
A criação de um pluggable database é baseada em um template, denominado pdb$seed, e herda boa parte dos parâmetros de
con�guração desse template. Você pode especi�car um usuário administrador e sua senha. Para as condições de
armazenamento, temos o volume máximo do banco de dados e as especi�cações para o tablespace e seu data�le associado.
No exemplo anterior alteramos também o path e incluímos a cláusula FILE_NAME_CONVERT para substituir o caminho
herdado do template.
 
O comando é executado e o novo database CRM_replica é criado. Esse será o banco de dados conterá as réplicas das tabelas
Usuarios e Usuarios_Historico do esquema CRM, armazenado no banco de dados de origem XEPDB1. Logo após a criação do
banco, ele é montado. Você pode ver seu status através da visão v$pdbs.
Para utilizá-lo, você deve abrir o banco de dados a partir de um ALTER PLUGGABLE DATABASE, passando a instrução OPEN.
 Abertura do pluggable database. Fonte: Oracle (2020).
Observe que, após o comando OPEN, o database passa de MOUNTED para READ WRITE, indicando que está pronto para uso,
no modo leitura e escrita. Veja também que pdb$seed está aberto em modo somente leitura, indicando que o template não
pode sofrer alterações.
/
 SELECT nas tabelas origem. Fonte: Oracle (2020).
Podemos, então, iniciar a con�guração para a replicação. Vamos abrir duas conexões, uma para o pluggable database XEPDB1,
onde residem as tabelas Usuarios e Usuarios_Historico, e outra conexão para o banco de dados recém-criado, CRM_replica.
Você pode ver na imagem anterior as janelas correspondentes abertas.  
Na sessão conectada a XEPDB1 veri�camos os totais de linhas em ambas as tabelas. Queremos nos certi�car de que as
tabelas possuem os dados a serem replicados. A execução dos dois SELECT COUNT mostra que ambas as tabelas possuem
99.999 linhas.
Na sessão conectada ao novo banco, executamos um CREATE USER para criar o usuário CRM e o esquema de mesmo nome.
Aqui, temos algo importante a respeito da replicação. É preciso que o esquema a ser replicado exista no banco de dados
destino. Não é preciso que as tabelas existam, mas é preciso que o esquema exista e, conforme veremos adiante, é preciso que
o usuário tenha os privilégios adequados para acessá-lo e modi�cá-lo.
 Criação do esquema CRM. Fonte: Oracle (2020).
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Concedemos o privilégio de conexão ao usuário para que ele possa conectar-se ao banco de dados. Em seguida, concedemos
o privilégio de execução de CREATE DATABASE LINK. Um database link é uma ligação entre um banco de dados e outro.
/
Atenção
Essa ligação é fundamental na con�guração da replicação, na medida em que o banco de dados CRM_replica vai estabelecer uma
conexão com o banco de dados XEPDB1 para copiar os dados das tabelas Usuarios e Usuarios_Historico.
 Permissão para criação de database links. Fonte: Oracle (2020).
A criação da replicação é realizada em dois passos. O primeiro no banco de dados master e o segundo no banco de dados que
vai receber a replicação. Então, no database XEPDB1, vamos criar um SNAPSHOT LOG para cada tabela a ser replicada. Veja a
seguir.
 Criação do snapshot. Fonte: Oracle (2020).
Cada snapshot log vai manter os logs das atualizações que serão enviadas para o banco de dados destino, sendo que, na
implantação da replicação todas as linhas existentes, elas serão replicadas. O próximo passo é criar o database link no banco
de destino, para que seja possível criar a ponta da replicação apontando para os snapshot logs do banco master.
É preciso, então, abrir uma nova conexão para o banco CRM_replica, desta vez com o usuário CRM. Na sessão aberta
executamos um CREATE DATABASE LINK informando o nome da ligação, o usuário e a senha de autenticação no banco de
dados XEPDB1 e o nome da conexão correspondente a esse banco destino na cláusula USING.
/
 Teste no database link. Fonte: Oracle (2020).
É fundamental que esse nome de conexão esteja con�gurado, por exemplo, em tnsnames.ora e que o caminho desse arquivo
esteja con�gurado na variável de ambiente TNS_ADMIN. Adiante você pode ver uma string TNS correspondente a XEPDB1:
 
XEPDB1 =
(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = Avell-G1511FIRE)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = XEPDB1))
)
Uma vez que o database link tenha sido criado, você pode testá-lo. Veja logo a seguir do comando CREATE DATABASE LINK um
SELECT na tabela DUAL do banco de dados correspondente ao link denominado xepdb1. O sucesso na execução do comando
indica que o database link está operacional.
Na sequência, como a ligação de CRM_replica para XEPDB1 está estabelecida, podemos criar o snapshot no banco destino. O
comando CREATE SNAPSHOT nomeia o snapshot e determina a consulta que será realizada na ligação xepdb1. É preciso que a
tabela utilizada na consulta tenha um snapshot log correspondente no banco master.
Dica
Observe que snapshot é um sinônimo de materialized view. A atualização provocada por um snapshot é gerada a partir da
materialização da visão correspondente ao SELECT de�nido na criação do snapshot. Veja o link
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_6003.htm que fornece todos os detalhes sobre esse
mecanismo
javascript:void(0);
/
 Erro na criação do snapshot. Fonte: Oracle (2020).
Ao executar o comando CREATE SNAPSHOT, é apresentado um erro ORA-01031. Erros de insu�cient privileges são muito
comuns e você, como administrador Oracle, deve preparar-se para investigá-los, identi�cando que tipo de privilégios são
necessários para que um usuário possa executar uma determinada ação no banco de dados.  
Um ponto de partida na investigação desse problema é realizar um SELECT na tabela Usuarios do banco XEPDB1 usando a
ligação xepdb1.
 Erro na criação do snapshot. Fonte: Oracle (2020).
Veja que o SELECT funciona, isto é, o usuário CRM conectado no banco CRM_replica é capaz de ler os dados da tabela
Usuariosdo banco XEPDB1. Nesse ponto, você pode considerar a hipótese de que o problema apresentado está na capacidade
de o usuário CRM executar um CREATE SNAPSHOT e perguntar-se quais são os privilégios necessários para uma execução
desse tipo. A seguir você pode visualizar quais os GRANTs necessários.
/
 Concessões para criação do snapshot. Fonte: Oracle (2020).
Após a efetivação das concessões, você pode visualizar por meio de uma consulta a session_privs, na sessão do usuário CRM,
quais são de fato os seus privilégios. Veja, na imagem a seguir que o CREATE SNAPSHOT é executado com sucesso.
 Snapshot criado. Fonte: Oracle (2020).
Tão logo os snapshots são criados, as 99.999 linhas das tabelas Usuarios e Usuarios_Historico são transferidas do banco
XEDPB1 para o banco CRM_replica. Você pode executar um SELECT no banco replicado para comprovar que as linhas de fato
foram transferidas.
/
 Snapshot criado. Fonte: Oracle (2020).
O último passo para a con�guração da replicação é criar um agendamento para o refresh do snapshot, isto é, de quanto em
quanto tempo você quer que as tabelas sejam atualizadas no banco de dados replicado.
Para tanto, você deve utilizar o procedimento anterior para criar o agendamento do refresh e informar o intervalo de tempo
desejado. Pelo comando visto, os snapshots das tabelas CRM.Usuarios e CRM.Usuarios_Historico serão atualizados de hora
em hora.
 Snapshot criado. Fonte: Oracle (2020).
Vamos praticar?
Utilizando a sua instância, execute os procedimentos para replicação dos dados das tabelas Usuarios e Usuarios_Historico e
con�gure uma atualização dos snapshots para três minutos. Simule atualizações de linhas e deleção de linhas, con�rmando
que ambas são replicadas para o banco de dados destino.
Oracle Data Guard e Oracle Golden Gate
Oracle Dataguard implementa uma solução de Alta Disponibilidade baseada nos redo logs e nos archive logs de um banco de
dados primário para um ou mais bancos de dados standby. Veja na imagem adiante seu diagrama de arquitetura.
/
 Oracle Data Guard. Fonte: Oracle (2020).
O banco de dados standby recebe o redo log �le, que é recebido a partir do banco de dados primário. Esse redo é reaplicado no
banco de dados, deixando-o sempre em modo consistente. Quando há uma falha, o failover pode ser manual ou automático e,
se posicionarmos o standby database em um datacenter alternativo, podemos construir uma solução para Disaster Recovery.
Comentário
Trata-se de uma solução bastante completa. Podemos ter vários bancos de dados standby, distribuídos e com funcionalidades
distintas. Podemos ter, por exemplo, uma réplica do banco de dados dedicada à execução de relatórios e outra dedicada à
exploração de dados. É também uma ferramenta utilizada frequentemente para migração de bancos de dados entre servidores.
Em uma abordagem para distribuição da replicação, podemos con�gurar um database que centraliza o recebimento dos redo
log �les e os distribui para vários outros bancos de dados replicados. Esse banco de dados central é chamado, nessa solução,
farsync standby database e é dotado da conectividade e das con�gurações necessárias para distribuir os logs para os vários
bancos de dados standby, sendo ele próprio desabilitado para operações de consulta.
Saiba mais
Oracle Golden Gate é o produto mais completo da Oracle para replicação de bancos de dados. Com esse produto é possível
integrar fontes de dados heterogêneas, como SQL Server, IBM DB2 e MySQL. Possui integração também com bancos de dados
em nuvem, provendo suporte para replicação de dados em tempo real.
Na imagem a seguir você pode ver os modelos de
implementação possível com Oracle Golden Gate. A
replicação básica é a unidirecional, muito semelhante à que
implementamos anteriormente por meio de snapshots. Na
bidirecional temos um cluster ativo-ativo, em que ambas as
instâncias permitem atualizações e as replicam para a outra
instância ativa. Na peer-to-peer aumentamos o número de
instâncias no sentido do balanceamento de carga.
 Oracle Golden Gate. Fonte: Oracle (2020).
No modelo broadcast é possível implantar a replicação unidirecional para vários bancos de dados, enquanto no modelo
consolidation podemos receber replicações de vários bancos de dados, consolidando-as em um único repositório. Já no
modelo cascading temos implementação semelhante ao farsync standby, disponível no Oracle Data Guard.
/
Conclusão
Vimos nesta aula técnicas e ferramentas clássicas do mundo Oracle para a construção de soluções que enderecem os
problemas de Alta Disponibilidade de serviços e cenários de Recuperação de Desastres. A replicação básica de dados usando
snapshots é uma primeira abordagem para a construção de réplicas.
Você vai encontrar Oracle RAC em muitas instalações Oracle. Seu uso é bastante difundido e é, de fato, a principal solução para
Alta Disponibilidade de bancos de dados Oracle. É uma solução robusta para implementação de um cluster ativo-ativo com
balanceamento de carga.
Para uma replicação completa de bancos de dados, Oracle Data Guard é a solução mais frequentemente utilizada. Com Data
Guard podemos criar soluções abrangentes entre bancos de dados primários e bancos de dados standby, incluindo a
con�guração de failover automático. Já o Oracle Golden Gate, implementa integrações com outros SGBDs, como SQL Server e
IBM DB2, bancos de dados em nuvem, como Amazon RDS e Oracle Cloud, e também plataformas de Big Data, como Apache
Hadoop, Cloudera e Kafka.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Atividade
1.Assinale a alternativa incorreta sobre as técnicas e ferramentas disponíveis no Oracle para implementação de soluções de Alta
Disponibilidade e Recuperação de Desastres. 
a) Oracle RAC é uma das principais soluções para a implementação de soluções de Alta Disponibilidade e Recuperação de Desastres.
b) Data Guard é uma ferramenta do Oracle para implementar espelhamento entre bancos de dados.
c) Oracle oferece replicação de dados síncrona a partir de snapshots incrementais gerados a partir de uma origem para um destino.
d) É possível clonar pluggable databases por meio das ferramentas de replicação do Oracle.
e) Golden Gate possibilita replicação de dados entre instâncias, incluindo transformações de dados durante a movimentação.
2. Assinale a alternativa incorreta sobre Oracle RAC. 
a) Um cluster RAC pode ser estendido em um datacenter distinto, configurando a construção de uma solução para cenários de Disaster
Recovery.
b) No OCR (Oracle Cluster Registry) residem todas as informações sobre os recursos do Grid, incluindo seus membros, endereços VIP e
listeners, e diskgroups ASM.
c) Os voting disks são fundamentais na arquitetura do Oracle RAC, pois armazenam os voting files que são arquivos em que os nós do
cluster registram que estão operacionais.
d) Uma conexão ao RAC é estabelecida a partir do Scan listener, que roteia o cliente para o listener de uma das instâncias do cluster.
e) Em um cluster RAC, os bancos de dados são distribuídos pelos nós e a carga de trabalho é balanceada no cluster.
/
3. Assinale a opção que não corresponde a uma tarefa na construção de uma replicação no Oracle.
a) Criar snapshot logs na origem da informação.
b) Garantir que o esquema e tabelas a serem replicadas sejam criadas no destino, ainda que sem os dados que serão replicados.
c) Garantir que o usuário correspondente no banco de dados replicado tenha as concessões correspondentes a CREATE SNAPSHOT,
CREATE TABLE e CREATE MATERIALIZED VIEW.
d) Criar snapshots no banco de dados replicado.
e) Criar um database link no banco de dados replicado que aponte para o banco de dados master.
Notas
Referências
CREATE Database Link. Oracle Help Center. Disponível em:
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5005.htm. Acesso em: 12 out. 2020.
INTRODUCTION to Oracle GoldenGate. Oracle Help Center. Disponível em: https://docs.oracle.com/goldengate/1212/gg-
inux/GWUAD/wu_about_gg.htm#GWUAD110. Acesso em: 10 out. 2020.
INTRODUCTIONto Oracle Real Application Cluste. Oracle Help Center. Disponível em:
https://docs.oracle.com/cd/B28359_01/rac.111/b28254/admcon.htm#i1058057. Acesso em: 10 out. 2020.
LOCAL Naming Parameters (tnsnames.ora). Oracle Help Center. Disponível em:
https://docs.oracle.com/cd/B28359_01/network.111/b28317/tnsnames.htm#NETRF007. Acesso em: 5 out. 2020.
OVERVIEW of Virtual IP Addresses. Oracle Help Center. Disponível em: https://docs.oracle.com/database/121/RACAD/GUID-
6C72F02D-BB43-4C56-9F46-244C8D6BB670.htm#RACAD8950. Acesso em: 10 out. 2020.
PUGA, S.; FRANÇA, E.; GOYA, M., 2013. Banco de Dados: implementação em SQL, PL/SQL e Oracle 11g. São Paulo: Pearson.
332p.
RAMAKHRISHNAN, R.; GEHRKE, J., 2002. Database Management Systems. 3rd. edition. New York: McGraw-Hill. 1098p.
READ - Only Snapshots. Docs Oracle. Disponível em: https://docs.oracle.com/cd/A57673_01/DOC/server/doc/SD273/ch3.htm.
Acesso em: 12 out. 2020.
USING Basic Replication. Docs Oracle. Disponível em:
https://docs.oracle.com/cd/A64702_01/doc/server.805/a58245/ch2.htm. Acesso em: 15 out. 2020.
Próxima aula
Tarefas programadas;
Monitoração de jobs;
Encerramento da disciplina.
Explore mais
A Oracle disponibiliza laboratórios gratuitos para administradores de banco de dados. No endereço a seguir você encontra
workshops com foco em assuntos bem especí�cos: https://oracle.github.io/learning-library/
Selecionando a opção Database 19c Featured Workshops você pode encontrar a opção Multitenant Fundamentals. Ao
selecionar essa opção você será redirecionado para o endereço a seguir:
https://apexapps.oracle.com/pls/apex/dbpm/r/livelabs/view-workshop?p180_id=573
Esse workshop é focado no uso do ambiente multitenant e nas técnicas para Alta Disponibilidade. Existem três opções
para realização do workshop como a que está adiante
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
/
para realização do workshop, como a que está adiante.