Aula 2 - Arquitetura do Oracle

Prévia do material em texto

/
Administração de Banco de Dados III
Aula 2: Arquitetura do Oracle
Apresentação
Esta segunda aula da disciplina Administração de Bancos de Dados III é uma apresentação da arquitetura de referência do
Oracle Database. Logo, vamos aprender alguns conceitos fundamentais para compreensão e uso do Oracle.
Nesta aula serão apresentados alguns diagramas que vão nos mostrar os principais componentes dessa arquitetura e
como eles se integram para fornecer a capacidade de armazenamento e processamento de consultas no Oracle.
Objetivo
Identi�car os principais componentes do Oracle;
Descrever os principais componentes do Oracle com base em diagramas de arquitetura e analisar sua integração
entre si;
Descrever as mudanças arquiteturais na versão 12c quanto a multitenancy.
Introdução
Esta aula está dividida em duas partes.
1
Primeira parte
vamos estudar os principais componentes da arquitetura do
Oracle, incluindo as áreas de memória e os processos que
fazem uso dessas áreas.
2
Segunda parte
vamos examinar a versão 12c e a mudança arquitetural
realizada na organização dos bancos de dados. Essa foi
uma mudança importante no curso da evolução do Oracle,
que trouxe uma série de benefícios para a administração do
SGBD.
/
No estudo da arquitetura de uma solução importa compreender como esses componentes trabalham juntos e, no caso
especí�co do Oracle, como as solicitações ao SGBD são resolvidas pela integração entre os componentes.
Durante a aula, é importante que você mantenha o foco no caminho que os dados percorrem para que o SGBD retorne o
resultado de uma consulta ou execute uma atualização. Em uma consulta, os dados que estão nos arquivos são transferidos
para áreas de memória. Em uma atualização, os dados são atualizados em memória e, em seguida, transferidos para os
arquivos de disco e arquivos de log de transações.
Conceitos básicos
Os conceitos de banco de dados e instância de banco de dados do Oracle são um pouco diferentes para aqueles que, como
você, já estudaram esses mesmos conceitos para outros SGBDs.
Banco de dados
Tradicionalmente, o banco de dados refere-se aos arquivos em disco do Oracle e a instância do banco de dados refere-se às
estruturas em memória que operam o banco de dados. Assim, o banco de dados inclui os arquivos em que �sicamente estão
os dados e estruturas de acesso aos dados, os arquivos de log de transações e os arquivos de controle que serão utilizados
pela instância do banco de dados para subir as estruturas em memória.
Instância
A instância, por sua vez, contém os processos que rodam em background e recebem e processam as solicitações dos
usuários, utilizando para isso uma série de mecanismos dispostos em áreas de memória bem de�nidas, como SGA (System
Global Area) e PGA (Program Global Area).
Comentário
Com o lançamento da versão 12c isso mudou. Uma nova arquitetura tornou possível a implantação de bancos de dados diversos
sob o gerenciamento de uma única instância. Conforme veremos em detalhes durante a aula, há benefícios concretos nessa
mudança para o dia a dia do DBA Oracle.
Independentemente da versão, uma conexão ao Oracle é estabelecida a partir de um descritor que inclui o listener e o serviço. Um
banco de dados Oracle pode ter vários serviços. Para usar um deles o cliente primeiramente conecta-se ao listener, informando
qual serviço deseja utilizar.
 Fonte: Oracle (2020).
javascript:void(0);
/
Listener
O listener devolve a requisição informando o endereço do dispatcher associado à instância do banco de dados.
Dispatcher
O dispatcher encaminha a solicitação de conexão para uma �la associada a um pool de processos Server. A conexão é
associada a um desses processos e é estabelecida.
Dica
Acesse a referência interativa do Oracle no endereço
https://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/r1/poster/OUTPUT_poster/poster.html e abra a guia
Database Architecture. Aí está um diagrama de arquitetura do Oracle, interativo, onde você pode clicar sobre os componentes para
vê-los com mais detalhes e abrir a documentação correspondente.
Diagrama de arquitetura
Inicialmente, identi�que no diagrama dois dos principais componentes dessa arquitetura, a SGA (System Global Area) na parte
superior central e a PGA (Program Global Area) na parte inferior central. Na SGA residem as estruturas em memória utilizadas
para a manutenção de dados lidos a partir do disco e alterados pelos processos. Dentro da SGA você pode identi�car regiões
bem delimitadas.
 Fonte: Oracle (2020).
javascript:void(0);
javascript:void(0);
/
System Global Area (SGA)
Observe a imagem a seguir.
 Fonte: Oracle (2020).
Database Buffer Cache
No Database Buffer Cache estão os blocos de dados lidos do disco. Alguns deles podem ter sido alterados por processos em
execução. Interessante notar que o tamanho padrão do bloco de dados é 8 KBytes, mas é possível alocar blocos de outros
tamanhos, menores e maiores, por conta de tablespaces construídas com tamanhos de bloco diferentes.
Outros buffers
Note dois outros buffers ao lado do Database Buffer Cache:
Clique nos botões para ver as informações.
O Flashback Buffer é utilizado quando a funcionalidade de Flashback Queries (consultas com timestamp para recuperação
de valores passados), lançada na versão 9i, está habilitada. Neste caso, o processo RVWR (Recovery Writer) está ativo e
copiando alterações do Buffer Cache para este Flashback Buffer, e daí para o Flashback Database.
Flashback Buffer 
Já o Redo Log Buffer, à direita do Database Buffer Cache, é um buffer circular que mantém as alterações DML e DDL
realizadas na instância do banco de dados. Com ele, o Oracle é capaz de recuperar as transações executadas e que não
tenham sido efetivadas no banco de dados, como nos casos em que ocorre falha do servidor e é necessário que o banco
de dados reexecute as transações que já haviam sido con�rmadas antes da falha, mas que não tinham sido
descarregadas em disco. Note que esse buffer está conectado ao LGWR (Redo Log Writer), que é o processo que escreve
essas alterações nos arquivos de log em disco.
Redo Log Buffer 
Pools
Ainda dentro da SGA, para além das áreas de buffers, você pode encontrar os pools. São três os principais pools no diagrama:
Shared Pool Large Pool Java Pool
javascript:void(0);
/
Shared Pool
É o mais utilizado dos pools. nele estão a lista
de sessões ativas no banco de dados (ASH
Buffers), os planos de execução de cada
solicitação SQL emitida (Shared SQL Area), o
dicionário de dados (Data Dictionary Cache),
e a área reservada para as instâncias de um
banco de dados distribuídas em um cluster
RAC (Global Resource Directory), que
mantém um cache central (Gobal Cache
Service) e as informações sobre
en�leiramento de solicitações nas várias
instâncias (Global Enqueue Service), ambos
apoiados por um diretório central, o Global
Resource Directory.
Large Pool
É utilizado para solicitações que necessitam
de espaço maior do que o oferecido por
padrão no Shared Pool. Outra diferença
importante é que no Large Pool não há
manutenção de uma lista LRU (Last Recently
Used) que permita ao SGBD circular os
buffers alocados. No Large Pool os buffers só
são desalocados quando de fato o processo
correspondente libera o buffer.
Java Pool
Recebe as estruturas de controle da JVM
(Java Virtual Machine) e as variáveis de
sessão de todo código Java que está em
execução na JVM.
Outros pools
Você pode notar ainda dois outros pools no diagrama:



/
Shared I/O Pool
É utilizado para carregar large objects se a
opção no cache está con�gurada para a
coluna correspondente. 
Stream Pool
É utilizado para captura e utilização de
streams de dados, utilizados, por exemplo,
pelo Oracle GoldenGate.
É importante para o DBA Oracle compreender que a arquitetura do SGBD
privilegia áreas de memória que possuem requisitos especí�cos, como as
áreas exclusivas para execução de código SQL e de código Java que vimos
até aqui. O administrador, tendo isso em mente, sabe que precisa revisitar
constantemente as con�guraçõesdessas áreas de memória especializadas
da instância Oracle, a �m de medir sua utilização e concluir sobre a
necessidade de alteração dos parâmetros de con�guração.
Programa Global Area (PGA)
Na PGA estão as estruturas em memória reservadas para cada processo em execução, que armazenam os dados para
controle do processo. Essas áreas são destinadas tanto para processos do servidor quanto para processos de usuários.
Quando você se conecta a um banco de dados Oracle por meio de um serviço listener, um processo é criado no SGBD para
gerenciar essa conexão. De imediato, uma área de memória dedicada a esse processo é criada na PGA; essa área é acessada
exclusivamente pelo processo gerenciador da sessão.
Os processos do SGBD que são executados em background também contêm sua área reservada na PGA. Como podemos ver
na imagem a seguir dentro de cada área reservada a um processo há três áreas distintas:
 Fonte: Oracle (2020).
javascript:void(0);
/
1
SQL Work Area
Tem áreas especí�cas para sort, para hash joins e para
mesclagem de índices bitmapp.
2
User Global Area
Contém as áreas para armazenamento de valores de
variáveis de sessão, que são aquelas variáveis que
controlam comportamentos especí�cos da sessão do
usuário, como o formato de datas ou a versão do
otimizador. No pool especí�co para sessões OLAP �cam as
variáveis de sessão especí�cas para execução de consultas
a cubos, por exemplo.
3
Private SQL Area
Nela estão as variáveis bind dos procedimentos SQL e
variáveis temporárias utilizadas para execução do código
SQL.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Processos
As caixas pretas e cinza que circundam o diagrama representam os processos do Oracle executados no nível do sistema
operacional. Em instalações Linux você poderá encontrá-los separadamente, enquanto em instalações Windows eles rodam
como threads dentro do processo principal, Oracle.exe, e você pode encontrá-los utilizando uma console MMC do Windows
com Oracle Managed Objects. Faremos isso na aula de Instalação do Oracle.
Vamos trabalhar com esta outra imagem da documentação da Oracle, que mostra mais de perto a interação entre os principais
processos e as regiões de memória que vimos anteriormente.
/
 Fonte: Oracle (2020).
Comentário
Note que existem duas categorias principais de processos, os que trabalham diretamente na SGA e outros que trabalham na faixa
de interação entre a PGA e a SGA. Vamos começar por aí. Quando o processo cliente emite uma solicitação com uma consulta
SQL, caso os dados já estejam em cache, eles são devolvidos ao solicitante; caso contrário, são carregados do disco para
memória a partir de um processo Server, criado especi�camente para o cliente e cuja função é ler os blocos de dados necessários
do disco para os buffers em memória. Note que é esse processo que carrega também todas as estruturas necessárias à
execução da solicitação na PGA.
Checkpoint e Database Writer
Caso a solicitação seja uma alteração de dados, ela é primeiramente realizada em memória. De tempos em tempos, o
processo CKPT (Checkpoint) dispara a gravação desses dados alterados em memória. Essa gravação é executada pelo
processo DBW, que descarrega esses buffers nos arquivos de dados e garante que as alterações realizadas em memória sejam
persistidas em disco. Note que você pode ter vários processos DBW em execução simultaneamente.
Logo a seguir, o DBW informa ao CKPT que pode emitir um checkpoint, isto é, que pode atualizar os arquivos de controle
informando que aqueles dados foram gravados.
E como são identi�cados os dados gravados?
javascript:void(0);
/
1
Um SCN (System Change Number) funciona como um relógio para o Oracle. Cada transação é marcada com um SCN e
todas as alterações realizadas em uma mesma transação possuem o mesmo SCN. Se uma transação possui um SCN
menor do que outra transação, podemos concluir que a primeira transação aconteceu antes da segunda.
2
Quando um checkpoint é emitido pelo processo CKPT, os arquivos de controle são atualizados com um SCN e isso
signi�ca que todas as transações anteriores a esse SCN foram persistidas em disco.
3
O processo de Checkpoint (CKPT) também veri�ca, de três em três segundos por padrão, a quantidade total de memória
em uso na PGA. Caso esteja maior do que a con�guração PGA_AGGREGATE_LIMIT, ele dispara uma série de ações para
reduzir o volume alocado e diminuir a pressão sobre essa área da memória.
Log Writer e Archive Log
Paralelamente a essa gravação de dados pelo DBW, você também verá os buffers de redo log sendo atualizados. Eles contêm
as instruções de atualização que o processo do cliente emitiu e que são encaminhadas para os arquivos de redo log por meio
do processo de escrita de log (LGWR). Se você optar por arquivar esses logs, terá os processos ARCH (Archive Log) em
execução. Veja a imagem a seguir.
 Fonte: Oracle (2020).
Ela mostra bem a interação entre os processos e os arquivos em disco. Você pode observar o �uxo de dados dos database �les
javascript:void(0);
/
para a memória a partir dos processos Server. Pode também con�rmar o que acontece no sentido inverso, quando os
processos DBW armazenam os dados alterados em memória nos database �les. Ao lado, pode ver que as transações ainda
não con�rmadas e ainda presentes no Redo Log Buffer são persistidas nos Redo Log Files pelo processo LGWR e daí seguem
para os archives por meio do processo ARCH. Note também que tanto LGWR quanto ARCH utilizam os control �les.
Todo banco de dados Oracle tem pelo menos um control �le . Quando LGWR e ARCH executam suas atualizações, eles
gravam aqui as informações correspondentes, de maneira que os control �les tenham sempre as informações sobre o último
checkpoint realizado.
1
Recovery Writer
O processo RVWR é o responsável pelo gerenciamento dos buffers alocados na área de Flashback. O processo de
disponibilização desse recurso envolve diretamente um �ush da área de memória para arquivos de log especí�cos, �ashback
logs.
System Monitor
Os processos que acessam diretamente a SGA são os que estão à direita no diagrama . O System Monitor (SMON) é um dos
principais. Sua função primeira é recuperar uma instância em caso de falha. Para isso, ele mantém o sincronismo do SCN com
uma time table. Os SCNs utilizados para marcação de transações e emissão de checkpoints são gerados na SGA e mantidos
pelo SMON.
Vimos anteriormente, na seção sobre SGA, que o Redo Log Buffer
mantém as alterações DML e DDL realizadas na instância do banco
de dados. Esses são os registros de log das transações utilizados pelo
SMON para recuperar uma instância. Baseado nos SCNs das
transações e o último SCN con�rmado no banco de dados, o SMON é
capaz de refazer as transações que foram con�rmadas, mas não
persistidas.
Manageability Monitor
Os processos de monitoramento da gerenciabilidade apoiam a geração e manutenção de uma série de informações do SGBD,
incluindo consultas SQL executadas, estatísticas de uso dos recursos e desempenho.
https://estacio.webaula.com.br/cursos/go0680/aula2.html
/
MMON
Suporta o AWR (Automatic Workload
Repository), um repositório de carga de
trabalho que armazena dados sobre as
instruções SQL executadas no banco de
dados, como tempos de execução, plano
de execução utilizado e consumo de
recursos.

MMNL
Suporta o ASH (Active Session History)
que, como o próprio nome diz, armazena
um histórico das sessões do Oracle e é
utilizado pelo Enterprise Manager para
mostrar as sessões ativas. O ASH faz parte
de uma das options do Oracle, o
Diagnostics and Tuning pack.
Process Monitor
O processo PMON monitora os processos e gerencia as áreas de memória utilizadas por eles. Quando ocorre uma falha em um
processo de usuário, é o PMON que:
Libera as áreas da PGA reservadas
ao processo.
Limpa as áreas do Database Buffer
que estavam alocadas.
Libera seus bloqueios e remove o
PID (Process Identi�cation) da lista
de processos ativos.
A operação das estruturas de memória realizada pelo PMON pode ser demandada por outros processosdo sistema. Suponha
que o cliente que acessou o database e solicitou alterações em dados em uma transação, fez rollback. Para isso, os undo
records são utilizados para realizar o rollback da transação não con�rmada e o PMON é acionado para realizar as
desalocações nas áreas de memória e quaisquer liberações que sejam necessárias, como dos locks que estavam concedidos
ao processo no momento do rollback.
2
Comentário
Por último, é importante destacar o processo MMAN (Memory Manager). É ele quem faz o gerenciamento das alocações e
realocações dos endereços de memória associados a cada uma das regiões, monitorando seu uso e expandindo as áreas caso
necessário.
Multitenancy
Quando a Oracle lançou sua versão 12c, o foco era as implementações necessárias para implantação de bancos de dados em
nuvem. Você sabe que, quando falamos de nuvem, seja pública ou privada, estamos falando de requisitos como elasticidade e
escalabilidade, horizontal ou vertical, que garanta ao serviço estar sempre adequado à demanda.
Atenção
https://estacio.webaula.com.br/cursos/go0680/aula2.html
/
Para SGBDs, a monitoração da carga de trabalho é fundamental, enquanto o banco de dados e os recursos associados a ele
devem ser capazes de sofrer essa adequação sem interromper as respostas a solicitações de usuários.
A arquitetura do banco de dados Oracle que vimos até aqui não é preparada para nuvem. Por uma série de fatores, incluindo
especialmente os conceitos e as implementações existentes para banco de dados e instância de banco de dados, não atendem
aos requisitos citados. Para nuvem, é preciso que o SGBD implemente o conceito de multitenancy, isto é, a capacidade de
acomodar vários bancos de dados em um mesmo SGBD.
Por quê?
Exemplo
Suponha que você desenvolveu um software usando Java e Oracle. Você tem vários clientes e gostaria de fornecer o seu software
na nuvem. Isso, certamente, traz uma série de vantagens bastante competitivas para você. Então, você vai a um fornecedor de
nuvem, como a Amazon ou a própria Oracle, e solicita um banco de dados para o primeiro cliente que contratou seu novo serviço.
Para o seu segundo cliente, você vai precisar de um novo banco de dados porque você não consegue acomodar esse segundo
cliente no mesmo banco de dados do primeiro, a menos que você use outro esquema e isso poderia implicar alterações de
código, algo não desejável. Então, você contrata um segundo banco de dados e, em pouco tempo, tem dezenas ou centenas de
bancos de dados Oracle para administrar. É viável, mas com alto custo.
A versão 12c implementou a arquitetura multitenant, mostrada na imagem a seguir.
 Fonte: Oracle (2020).
javascript:void(0);
/
A primeira informação interessante que podemos extrair do diagrama vem do próprio título, Multitenant Container Database.
Nessa arquitetura, todos os bancos de dados são containers. Assim, CDB$ROOT, PDB$SEED, PDB_1 e PDB_n são containers e,
juntos, implementam um banco de dados multitenant, no qual o CDB (Container Database) é o banco de dados principal, que
contém outros bancos de dados PDB (Pluggable Database).
Comentário
A instância é única para todo o conjunto CDB e PDBs. Observe que a SGA, gerenciada pela instância, é compartilhada por todos os
bancos de dados. O mesmo ocorre para os processos que rodam em background, como PMON e SMON.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Todo container database possui um root database e um seed.
O root contém os objetos do sistema que
são compartilhados por todos os outros
databases. No diagrama você pode ver o
dicionário OBJ$, a DBA_OBJECTS (visão de
objetos do sistema) e pacotes de objetos
PL/SQL como DBMS_COMPRESSION ou
DBMS_CRYPTO, entre outros.
O seed é o template de banco de dados a
partir do qual todos os PDBs são criados.
Com relação aos PDBs, você pode observar que cada um deles contém seus próprios arquivos de dados contendo tablespaces
SYSTEM e SYSAUX, tablespaces associados aos esquemas de aplicações e tablespaces temporários. Observe também que
cada PDB contém seus usuários locais, incluindo seus próprios administradores, com roles e privilégios concedidos
localmente.
Um aspecto especialmente importante de um PDB é que você pode movê-lo para outro CDB. De fato, o nome “Pluggable”
aponta exatamente para esta característica. Por ser um container autocontido, você pode desplugá-lo do seu CDB atual e
plugá-lo em outro CDB, adicionando �exibilidade à solução oferecida. Veja a outra imagem a seguir.
/
 Fonte: Oracle (2020).
É importante compreender que a separação existente entre os PDBs tem
lógica. Fisicamente, continuamos tendo exatamente a mesma arquitetura
para o banco de dados, com os data �les, control �les, online redo log,
archives e �ashback log.
Comentário
Conforme comentamos no início da seção, a arquitetura multitenant trouxe uma série de benefícios, dentre os quais podemos
destacar a redução dos custos diretos com aquisição de licenças e dos custos de administração da plataforma, na medida em
que tarefas como atualização de versão e gerenciamento de backups são concentradas na instância CDB.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Conclusão
O diagrama de arquitetura do Oracle oferece uma excelente visão sobre seus componentes e como eles funcionam juntos para
o gerenciamento de recursos e atendimento às solicitações de bancos de dados. Nesta aula você pôde compreender como o
Oracle resolve essas solicitações, desde a fase da conexão do cliente, uso das estruturas de memória, carregamento dos
dados em buffers, atualização dos dados, até a gravação em disco desses dados atualizados.
Em seguida, analisamos a proposta arquitetural da versão 12c. Nessa nova arquitetura, o Oracle passou a comportar vários
bancos de dados pluggable em uma única instância. Essa mudança trouxe benefícios relevantes para os administradores dos
bancos de dados Oracle, na medida em que pode-se tratar o encaminhamento de uma série de atividades administrativas,
como atualização, auditoria e backups, com maior produtividade.
javascript:void(0);
/
Atividade
1. Assinale a seguir a opção que não corresponde a um componente da arquitetura do Oracle.
a) Database Buffer Cache.
b) OLAP Pool.
c) Process Pool.
d) Redo Log Buffer.
e) Process Global Area.
2. Assinale a alternativa incorreta a respeito do funcionamento do Oracle.
a) Quando um cliente conecta-se ao Oracle, uma área de memória dedicada ao processo do cliente é criada na PGA; essa área é acessada
exclusivamente pelo processo gerenciador da sessão.
b) Os processos de monitoramento da gerenciabilidade apoiam a geração e a manutenção de uma série de informações do SGBD,
incluindo consultas SQL executadas, estatísticas de uso dos recursos e desempenho.
c) Quando um cliente que solicitou alterações em dados em uma transação faz rollback. os undo records são utilizados para realizar o
rollback da transação não confirmada e o PMON é acionado para realizar as desalocações nas áreas de memória.
d) O processo Checkpoint realiza a gravação de dados alterados em memória, descarregando os buffers nos arquivos de dados e
liberando os recursos alocados.
e) No Shared Pool, região interna da SGA, estão a lista de sessões ativas no banco de dados (ASH Buffers), os planos de execução de cada
solicitação SQL emitida (Shared SQL Area) e o dicionário de dados (Data Dictionary Cache).
3. Assinale a alternativa incorreta sobre a arquitetura Multitenant.
a) Na arquitetura Multitenant, todos os bancos de dados são containers. Assim, CDB$ROOT, PDB$SEED e até 253 PDBs são containers.
b) É possível mover um PDB para outro CDB.
c) Na arquitetura Multitenant só existe uma SGA.
d) O database root contém objetos do sistema que são compartilhados por todos os PDBs.
e) Multitenancy traz uma série de vantagens para os administradores Oracle, entre elas redução do custo de administração e tuning
automático dos bancos de dados.
Notas
Control file 1
Ele é um arquivo binário que contém uma série de informações sobre o database,como seu nome, sua data de criação, sua
estrutura física (nomes e localização dos arquivos de dados e arquivos de redo log), além do SCN corrente e das informações
de checkpoint.
Undo records 2
/
São registros especialmente mantidos pelo Oracle em undo segments que são persistidos em um tablespace especí�co do
sistema, chamado undo tablespace. Vamos ver mais sobre isso na aula de Instalação do Oracle.
Referências
LOGICAL Storage Structures. Oracle Help Center. Disponível em:
https://docs.oracle.com/database/121/CNCPT/logical.htm#CNCPT004. Acesso em: 3 set. 2020.
MANAGING Control Files. Oracle Help Center. Disponível em:
https://docs.oracle.com/cd/B19306_01/server.102/b14231/control.htm. Acesso em: 3 set. 2020.
MEMORY Architecture. Oracle Help Center. Disponível em:
https://docs.oracle.com/cd/E11882_01/server.112/e40540/memory.htm#CNCPT007. Acesso em: 2 set. 2020.
OVERVIEW of the Multitenant Architecture. Oracle Help Center. Disponível em:
https://docs.oracle.com/database/121/CNCPT/cdblogic.htm#CNCPT89257. Acesso em: 3 set. 2020.
PROCESS Architecture. Oracle Help Center. Disponível em: https://docs.oracle.com/cd/B19306_01/server.102/b14220/process.htm#i24686.
Acesso em: 2 set. 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. 332
p.
RAMAKHRISHNAN, R.; GEHRKE, J., 2002. Database Management Systems. 3rd. edition. New York: McGraw-Hill. 1098p.
WHAT Are You Backing Up? Oracle8 Backup and Recovery Guide. Disponível em:
https://docs.oracle.com/cd/A58617_01/server.804/a58396/ch2.htm. Acesso em: 3 set. 2020.
Próxima aula
Instalação do Oracle;
Con�guração básica do Oracle;
Utilização do Oracle SQL Developer.
Explore mais
Um site de referência para todo DBA Oracle é o Ask Tom. Há muito material em formato de perguntas e respostas, e também
vídeos sobre os mais diversos assuntos. Link: https://asktom.oracle.com/pls/apex/f?p=100:1000::::::
Procure por ask tom oracle architecture. Você vai encontrar um vídeo excelente sobre a arquitetura do Oracle e sua
implementação como containers Docker.
Explore esse vídeo! Você vai entender como a arquitetura multitenant está integrada à arquitetura Docker.
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);