Você está na página 1de 133

SISTEMA

GERENCIADOR DE
BANCO DE DADOS
ORACLE


DBA
ADMINISTRAO DE
BANCO DE DADOS



PROF. PAULO AUGUSTO DOS
SANTOS
SISTEMA GERENCIADOR DE BANCO DE DADOS ORACLE
DBA - ADMINISTRAO DO BANCO DE DADOS

1 - Arquitetura do Banco de Dados ORACLE





Background Processes
System Global Area
Users
Servers
Control Files
Parameter
File
Redo Log
Files
Data
Data
Data Files
ARQUITETURA DO ORACLE
Viso Geral

Uma Base de Dados ORACLE composta de Control Files, que so as
estruturas fsicas do Banco de Dados e contm os nomes das Tabelas de
Dados e dos Redo Log Files, que so arquivos onde sero guardados todos
os registros das alteraes feitas nas Tabelas de Dados, para eventuais
recuperaes de dados.

Sempre que o ORACLE for iniciado, a SYSTEM GLOBAL AREA (SGA)
alocada e os processos de background so iniciados. A combinao dos
buffers de memria e dos processos de background so chamados de
INSTANCE.

A SGA um grupo de buffers de memria compartilhados, alocados pelo
ORACLE para uma INSTANCE. Os processos de background assncronos,
executam tarefas distintas em favor de todas as tabelas dos usurios. O
arquivo de parmetros ir determinar as caractersticas da instance.

Antes de um determinado dado ser acessado, o processo servidor deve colocar
o dado em um CACHE BUFFER. Os blocos de dados modificados so
gravados no disco pelo processo de background chamado DATABASE
WRITER (DBWR). Para processar comandos SQL, o servidor de processos
usa memria compartilhada (shared memory) na SGA.


S G A

Shared Pool Memory Database Buffer Cache Redo Log
Buffer














DBWR
SERVERS



TABELAS


USERS



Um processo de usurio (user) criado quando um usurio roda uma
aplicao. O ORACLE cria um processo servidor para manipular as requisies
de conexo com o processo usurio. Os servios executados pelo processo
servidor e que so requisitados pelo processo usurio so :

Interpretao e execuo de comandos SQL
Leitura em disco de blocos de dados disponibilizando-os nos buffers
de memria na SGA
Retorna o resultado de comandos SQL ao processo usurio.
Processando Comandos SQL

Todo comando SQL implementado pelo processo servidor, usando trs fases
distintas :
1. 1. Interpretao

1.1 - Verificao da sintaxe
1.2 - Consulta o dicionrio de dados para verificar a existncia do objeto
selecionado, da segurana e privilgios e o caminho da pesquisa
1.3 - Determina a arvore de execuo (parse tree) ou o plano de execuo
do comando.

Obs. :
A rvore de execuo armazenada na shared pool rea.
Mltiplos processos servidores podem compartilhar de uma mesma
arvore de execuo
O tamanho da shared pool determinada pelo parmetro
SHARED_POOL_SIZE no arquivo de parmetros.
2. 2. Execuo

2.1 - Valida a rvore de execuo para os buffers de dados
2.2 - Realiza as leituras e gravaes fsicas e lgicas.
3. 3. Fetch

3.1 - Recupera as linhas de dados de tabelas em um comando SELECT.

A shared pool rea contem informaes usadas na execuo de comandos
especficos. Processos que executam idnticos comandos, compartilham estas
informaes.
Program Global rea

A PROGRAM GLOBAL REA (PGA), uma regio da memria que ir conter
dados e informaes de controle de um usurio ou de um processo servidor. A
PGA alocada pelo ORACLE quando um processo usurio se conecta a uma
base de dados ORACLE e a sesso estabelecida.


SERVER PROCESS



PGA
STACK USER
SPACE SESSION
DATA


O STACK SPACE a memria alocada para manter as variveis e arrays das
sesses. A USER SESSION DATA uma memria adicional para a sesso do
usurio.
A PGA regravvel e no compartilhada.

Database Buffer Cache

A DATABASE BUFFER CACHE mantm uma cpia dos dados lidos do disco.
Os buffers so compartilhados por todos os processos usurios concorrentes,
conectados instance. O tamanho do bloco determinado pelo parmetro
DB_BLOCK_SIZE. O nmero de blocos cached na memria determinado
pelo parmetro DB_BLOCK_BUFFERS.
A DATABASE BUFFER CACHE organizada em duas listas : a lista suja e a
LRU - least-recently-used list (lista do ultimo mais recentemente utilizado). A
lista suja ir conter os buffers modificados que no foram gravados em disco.
Quando um processo servidor necessita ler um bloco de dados do disco na
DATABASE BUFFER CACHE, ele realiza os seguintes passos :
Pesquisa a lista LRU,
Procura por um buffer livre, e
Move os buffers para a lista suja.
Operao de Select

Uma operao de SELECT necessita que o bloco de dados selecionado
atravs dos critrios de pesquisa, se encontre na DATABASE BUFFER
CACHE. O SELECT realiza os seguintes passos :
Pesquisa na LRU pelo bloco de dados requerido.
Se o bloco no se encontra na memria, realiza a leitura fsica em
disco.
Se o bloco se encontra na memria, realiza a leitura lgica.

Rollback Segments

O ROLLBACK SEGMENT uma tabela ou mais tabelas, que mantm registros
anteriores s alteraes realizadas em blocos de dados, de forma a permitir
que as alteraes sejam desfeitas sob determinadas circunstancias. O
ROLLBACK SEGMENT sera usado em casos de :
Read Consistency
Comandos SQL de ROLLBACK
Na recuperao de transaes ou de tabelas.

Exemplos de operaes de ROLLBACK :
Erros de deadlock
Retornar toda a transao ou at um determinado savepoint
Retornar a transao em caso de trmino anormal
Durante uma recuperao automtica de instance.

Operao de Update

Toda operao de UPDATE (atualizao em tabelas) necessita segmentos de
rollback suficientes para suportar problemas de read consistency, recuperaes
ou comando de rollback. O UPDATE realiza os seguintes passos :
Obtm os blocos de dados na DATABASE BUFFER CACHE.
Obtm os blocos de rollback na DATABASE BUFFER CACHE.
Realiza as alteraes nas linhas reservadas para as alteraes.
Salva a imagem anterior das linhas nos blocos de rollback.
Libera as alteraes nos blocos de dados.

Se o usurio re-executar uma operao de SELECT, uma imagem read
consistent da linha alterada sera feita. Se um bloco estiver sujo, o processo
servidor ira construir uma imagem read consistent atravs do uso do rollback
segment.
Read Consistency

Do comeo ao fim do processamento de um comando, o ORACLE ira retornar
uma imagem da tabela com os mesmos valores encontrados no comeo deste
comando. O SGBD garantira que dois usurios iro ter a mesma imagem de
uma tabela, obtida por um SELECT, mesmo que um terceiro usurio tenha
realizado e comitado algum tipo de alterao nesta tabela, durante a
execuo do comando. Estas alteraes s estaro disponveis a estes
usurios, se eles realizarem um novo comando SELECT.
Processos DBWR

O DBWR gerencia o DATABASE BUFFER CACHE para que os processos
usurios possam sempre achar buffers livres. O processo DBWR ir :
Gravar todas as alteraes realizadas nos blocos de dados dos
buffers.
Usar um algoritmo da LRU para manter os blocos, mais
recentemente utilizados, na memria.
Retardar as gravaes para obter uma otimizao de tempo de I/O.

O DBWR ir gravar buffers sujos no disco quando :
A lista suja alcana um tamanho final.
Um processo procura por um numero especfico de buffers na LRU,
sem encontrar um buffer livre.
Quando ocorre um timeout.
Quando ocorre um checkpoint.


Revendo o acesso a dados

Antes que um dado possa ser acessado, o processo servidor deve
colocar o dado na DATABASE BUFFER CACHE. Os blocos de dados
modificados so gravados de volta no disco por um processo secundrio, o
DBWR. Para processar um comando SQL, o processo servidor utiliza a
memria compartilhada na SGA.
Log de Transaes

O ORACLE grava todas as alteraes feitas em tabelas, em um redo log buffer.
Um processo secundrio, o LGWR, grava as informaes destes redo log
buffers em uma tabela de redo log no disco. Um outro processo secundrio, o
ARCHIVER (ARCH), pode recuperar as informaes das tabelas de redo log.

S G A

Shared Pool Memory Database Buffer Cache Redo Log
Buffer













DBWR LGWR
SERVERS



TABELAS Redo Log Files


USERS




ARCH


Armazenamento
Offline
Redo Log Buffer

O REDO LOG BUFFER um buffer circular que contem informaes sobre
todas as alteraes realizadas nas tabelas da base de dados. Estas
informaes so armazenadas em redo entries (entradas do redo logo buffer),
e sero utilizadas para reconstruir ou retornar (rollback) mudanas feitas nas
tabelas, sempre que necessrio.
Vamos rever o processo de UPDATE, com a utilizao dos redo log buffers :
Obtm os blocos de dados na DATABASE BUFFER CACHE.
Obtm os blocos de rollback na DATABASE BUFFER CACHE.
Realiza as alteraes nas linhas reservadas para as alteraes.
Adiciona a imagem anterior e posterior dos blocos no redo log buffer
Salva a imagem anterior das linhas nos blocos de rollback.
Libera as alteraes nos blocos de dados.
O Processo LGWR

O processo secundrio de LOG WRITER (LGWR), grava as entradas dos redo
logs no disco. Isso acontecer sempre que :
Ocorrer um COMMIT
O redo log buffer estiver com um tero j preenchido
O processo de DBWR precisar limpar o buffer de dados para um
checkpoint, ou
Ocorrer um timeout.
COMMIT

O comando COMMIT ir fazer com que todas as alteraes, incluses e
excluses realizadas nas tabelas de dados, sejam gravadas permanentemente
no disco.
Uma operao COMMIT sera solicitada pelo usurio, e ir :
Gravar uma imagem do registro comitado no redo log buffer.
O LGWR grava fisicamente os redo log buffers em uma tabela,
usando se possvel, uma gravao do tipo multi-block.
Avisa ao usurio que a transao foi comitada.
Todas os locks de linha so liberados nos blocos de dados e nas
reas de rollback.
O bloco de dados marcado como j atualizado (pinned).
Redo Log Files

Os REDO LOG FILES tm gravados todas as alteraes realizadas nas tabelas
de dados, e usado para recuperaes.
Os REDO LOG FILES so gravados de forma circular, ou seja, aps ser
gravada a ultima linha, o sistema ir fazer com que a gravao seja iniciada
novamente, a partir da primeira linha do arquivo. Deve haver, no mnimo, dois
grupos de REDO LOG.

Sempre que um redo log est completo e ser iniciada a gravao em um outro
redo log, criado um numero de sincronizao, denominado LOG SWITCH,
que ir servir para identificar as informaes gravadas, alm de ser usado
tambm, como sincronizao no caso de recuperao de informaes.
Checkpoint
Durante um CHECKPOINT, o DBWR grava todos os buffers sujos da
DATABASE BUFFER CACHE no disco, garantindo que todos os blocos de
dados modificados desde o ultimo CHECKPOINT, sejam gravados no disco.
O CHECKPOINT ocorre :
Em cada log switch,
Quando atinge um numero determinado de segundos aps o ultimo
CHECKPOINT,
Quando um numero pr-determinado de blocos do redo log so
gravados no disco, desde o ultimo CHECKPOINT,
Em um shutdown da instance,
Quando forado pelo DBA, e
Quando a tablespace e colocada offline.

O parmetro LOG_CHECKPOINT_TIMEOUT determina o intervalo de tempo
entre CHECKPOINTS.
O parmetro LOG_CHECKPOINT_INTERVAL determina o nmero de blocos
de redo log recentemente preenchidos que so necessrios para iniciar um
checkpoint.
Deve-se observar que no caso da necessidade de recuperao de uma
instance, ser necessrio refazer somente as alteraes desde o ultimo
checkpoint. O checkpoint permite que um redo log on-line seja reusado,
garantindo que todas as alteraes armazenadas em um redo log estejam
gravadas nas respectivas tabelas de dados.
Processo CKPT

S G A

Shared Pool Memory Database Buffer Cache Redo Log
Buffer











DBWR LGWR


SERVERS
CKPT


TABELAS Redo Log
Files


USERS




ARCH


Armazenamento
Offline

Os checkpoints asseguram que todos os buffers, de base de dados,
modificados so gravados no disco. As tabelas so marcadas com a data
corrente da gravao e o checkpoint e gravado no arquivo de controle (control
file).

O processo CKPT :
Regravara os headers de dados e control files aps um checkpoint
haver sido completado.
Checkpoints realizados com maior freqncia, iro reduzir o tempo
necessrio para uma recuperao no caso de uma falha de instance,
agilizando sua performance.
O processo de checkpoint sera habilitado pelo parmetro
CHECKPOINT_PROCESS.
Processo ARCH

O Processo ARCHIVER (ARCH) copia on-line, redo logs com espao completo
(cheio) sejam gravados em um arquivo designado, fazendo com que estas
informaes sejam guardadas e usadas no caso de recuperaes.
Os redo log files so copiados para uma fita ou outro disco, e ser usado no
caso de uma recuperao de dados em funo de um erro ocorrido, por
exemplo, com a mdia de armazenamento.
O ARCH opera somente quando ocorre um log file group switch. O ARCH
opcional e ser executado somente se estiver habilitado no arquivo de
parmetros ou se requisitado manualmente.
Control File

O CONTROL FILE um pequeno arquivo binrio, que descreve a estrutura da
base de dados:
Todas as tabelas e log files da base de dados esto identificados no
CONTROL FILE.
O nome da base de dados (banco) esta armazenada no CONTROL
FILE
O CONTROL FILE necessrio em toda a abertura e acesso ao
Banco de Dados.
As informaes de sincronizao necessrias recuperao do
banco, esto armazenadas no CONTROL FILE.

Recomenda-se uma configurao mnima de dois CONTROL FILES em discos
diferentes.
O parmetro CONTROL_FILES identifica o CONTROL FILE a ser usado pelo
Banco de Dados.
Processo PMON e SMON

O Processo MONITOR (PMON) e o SYSTEM MONITOR (SMON), recuperam
os recursos que no esto mais sendo utilizados pelo usurio, no tangente s
bases de dados.

PMON :
Limpa as coneces terminadas de forma anormal.
Faz o Roll back em transaes no comitadas
Libera o lock de linhas quando os processos so terminados
Libera os recursos de SGA alocados em processos que falharam
Detecta deadlocks e automaticamente resolve o problema,
ocasionando o roll back nas transaes.


SMON :
Realiza automaticamente a recuperao de instance
Libera espao para fazer sort de tabelas.

Em suma, o PMON e o SMON so processos que liberam recursos alocados e
que no esto sendo mais utilizados.
Os processos RECO e LCKn so utilizados em transaes com Banco de
Dados distribudos. O processo RECO resolve erros envolvendo transaes
distribudas e o processo LCKn realiza o lock entre instances em servidores
paralelos.



PMON LCKn RECO SMON



S G A

Shared Pool Memory Database Buffer Cache Redo Log
Buffer













DBWR LGWR
SERVERS



TABELAS
Redo Log
Files
USERS


Arquivo de Control
Parmetros Files
ARCH

Armazenamento
Offline

SISTEMA GERENCIADOR DE BANCO DE DADOS ORACLE
DBA - ADMINISTRAO DO BANCO DE DADOS

2 - Iniciando e Finalizando uma Instance

Para se inicializar o Banco de Dados, disponibilizando o acesso aos usurios,
deve-se inicializar uma instance, seguindo os seguintes passos :

1 - Invocar o SQL*DBA ou Server Manager (Verses mais recentes)

OBS: dependente do Sistema Operacional e da Verso do SGBD em
uso:

Exemplo utilizando Rede Novell:

ORALOAD
LOAD SQLDBA
Inicia o Monitor de gerenciamento do Banco de Dados. Deve ser
iniciado aps a inicializao da rede.

Exemplo utilizando Rede Windows NT e Oracle 7.3:

C:\ SVRMGR23
SVRMGR>

Exemplo utilizando AIX e Oracle 8:

$ svrmgrl
SVRMGR>


2 - Conectar o banco como Internal
CONNECT INTERNAL/SENHA
Ser verificado os privilgios de uso do Banco de Dados. Pode
no ser necessrio a digitao de senhas se a autorizao for
implcita e fornecida pelo prprio sistema operacional do Banco de
Dados. O CONNECT INTERNAL equivalente conexo como
SYS, que o usurio proprietrio do ORACLE Data Dictionary.

3 - Iniciar a instance : Montar o Banco de Dados e abrir as bases de
dados
STARTUP
A Instance sera iniciada
O arquivo de parmetros INIT.ORA ser lido
Ser alocada a SGA
Os processos de background (secundrios) sero iniciados
Os arquivos de acompanhamento sero abertos em background
O Banco de Dados ser montado
Os control files especificados no arquivo de parmetros sera
aberto
Os control files sero lidos para se obter os nomes da base de
dados e dos redo logs
O ORACLE Server confirma que estes arquivos existem como
foram especificados.
As bases de dados (tabelas) sero abertas
Disponibiliza as tabelas para as operaes com usurios.
Comando STARTUP - Opes alternativas

Comando do SQL*DBA ou Server Manager

STARTUP
OPEN EXCLUSIVE
MOUNT database PARALLEL/SHARED RETRY
NOMOUNT
PFILE=parfile RECOVER FORCE RESTRICT

Onde :

OPEN : Permite aos usurios acessarem o Banco de Dados

MOUNT : Monta o Banco de Dados para operaes do DBA, mas
no permite
o acesso de usurios ao Banco de Dados

NOMOUNT : Cria a SGA e inicializa os processos de background, mas
no
permite o acesso de usurios ao Banco de Dados

EXCLUSIVE : Permite apenas instance corrente, acessar as bases de
dados
(tabelas)

PARALLEL : Permite que mltiplas instances acessem o Banco de
Dados

PFILE=parfile : Permite que se utilize outro arquivo de parmetros
(parfile) que no
o padro INIT.ORA, para configurar a instance.

FORCE : Cancela a instance aps realizar um startup normal

RESTRICT : Permite que apenas os usurios com permisso de
sesso restrita
acessem o Banco de Dados

RECOVER : Inicia a recuperao de dados quando do inicio do Banco
de Dados

Exemplo do startup de uma instance com acesso restrito a usurios com o
privilgio de restricted session :

STARTUP OPEN TEST RESTRICT

Exemplo de inicio de instance e mount do Banco de Dados TEST com um
arquivo de parmetros diferente do padro, chamado de INITEST.ORA :

STARTUP EXCLUSIVE MOUNT TEST PFILE=INITEST.ORA

OBS.: Os itens em negrito e sublinhado, so os executados normalmente
quando no comando STARTUP.
Comando MOUNT - Opes alternativas

Comando do SQL*DBA ou Server Manager

ALTER DATABASE nome
MOUNT EXCLUSIVE/PARALLEL
OPEN RESETLOGS/NORESETLOGS

Opo para mudar o atual estado do Banco de Dados aberto onde :

OPEN : Permite aos usurios acessarem o Banco de Dados


MOUNT : Monta o Banco de Dados para operaes do DBA, mas
no permite
o acesso de usurios ao Banco de Dados

EXCLUSIVE : Permite apenas instance corrente, acessar as bases de
dados
(tabelas)

PARALLEL : Permite que mltiplas instances acessem o Banco de
Dados


Exemplo de mount exclusivo de um Banco de Dados :

ALTER DATABASE MOUNT EXCLUSIVE

Exemplo de abertura de um Banco de Dados j montado, usando o comando
ALTER DATABASE :

CONNECT INTERNAL
ALTER DATABASE OPEN


Para se finalizar o Banco de Dados, deve-se desativar a instance, seguindo os
seguintes passos :

1 - Na tela do SQL*DBA ou Server Manager , desmontar e fechar as bases
de dados
SHUTDOWN
DISCONNECT
EXIT
ORAUNLD (Novell)
Comando SHUTDOWN - Opes

Comando SQL*DBA

Finalizar uma sesso ORACLE

SHUTDOWN ABORT/IMMEDIATE/NORMAL

Onde :

ABORT : a maneira mais rpida de shutdown, pois no permite
aos usurios que encerrem normalmente suas atividades, abortando seus
processos e coneces com o Banco de Dados

IMMEDIATE : Aguarda o trmino de comandos SQL e transaes de roll
back

NORMAL : Aguarda que os usurios terminem suas sesses de
forma normal.

Exemplos :

CONNECT INTERNAL
SHUTDOWN NORMAL
Outros Comandos

Alterao do estado do Banco de Dados, de forma a permitir que os prximos
usurios a se conectarem com o Banco de Dados sejam apenas aqueles com
privilgio de RESTRICTED SESSION:

ALTER SYSTEM
ENABLE/DISABLE RESTRICT SESSION

Onde :

ENABLE RESTRICTED SESSION : Permite futuros logins apenas para
usurios
com privilgio de RESTRICTED
SESSION

DISABLE RESTRICTED SESSION : No permite futuros logins a
nenhum tipo de
usurio.

Exemplo :

CONNECT INTERNAL
ALTER SYSTEM ENABLE RESTRICTED SESSION

SISTEMA GERENCIADOR DE BANCO DE DADOS ORACLE
DBA - ADMINISTRAO DO BANCO DE DADOS

3 - Gerenciamento do Armazenamento nas Bases de
Dados



TABLESPACE

























Segmentos Extenses Extenses Blocos de
de 112 K de 28 K de 84 K Dados


O ORACLE aloca espaos na base de dados, para todos os dados
armazenados. Termos:

BLOCK (BLOCO) :

Mltiplos espaos fsicos alocados para blocos de dados de um arquivo de
dados (tabela)

EXTENT(EXTENSO) :

Um grupo de blocos de dados contguos

SEGMENT(SEGMENTO) :

O conjunto de uma ou mais extenses que contm dados de uma tabela
especfica no Banco de Dados

TABLESPACE :

Um repositrio de dados lgicos, para um grupo fsico de dados

FILE :

Um arquivo de dados fsico pertencentes a uma nica tablespace

DATABASE :

Uma coleo lgica de dados compartilhados, armazenados em uma
tablespace, ou seja, so as tabelas de dados.
Blocos de Dados - Database Blocks

Um bloco de dados ORACLE e a menor unidade de I/O usada pelo Banco de
Dados.
Bloco de Dados :
Tambm chamado de bloco lgico e ORACLE bloco
Corresponde a um ou mais blocos fsicos no disco
O tamanho determinado, na criao, pelo parmetro
DB_BLOCK_SIZE e, sera constante para todas as tabelas
O tamanho do bloco tambm determina o tamanho de cada buffer
de dados na SGA

O formato do bloco similar, apesar de poder ter dados de uma tabela, de um
ndice ou um dado tipo cluster. O bloco se divide em :
Header - Cabealho
Contm informaes gerais sobre o bloco, como o endereo do
bloco e o tipo do segmento. Em mdia a poro fixa e varivel do
bloco, tem um total de 85 a 100 bytes.
Table Directory - Diretrio da tabela
Contm informaes sobre a tabela no cluster, e usado com
cluster segmentados.
Row Directory - Diretrio da linha
Contm informaes de linha, sobre a linha atual no bloco.
Permite 2 bytes de overhead por linha.
Free Space - Espao Livre
Consiste em um grupo de bytes no bloco, disponveis para
inseres ou regravaes.
Row Data - Dados da linha
Armazena dados de tabelas ou ndices.

O Uso de Controle de Espaos

O controle dos espaos livres para inseres, regravaes e delees (insert,
update e delete) de linhas em um bloco de dados, ter seus valores
especificados atravs da utilizao de parmetros.
Parmetros :
PCTFREE
PCTUSED
INITRANS
MAXTRANS

PCTFREE

Determina percentualmente, o espao de blocos a ser reservado durante uma
insero de linha, para uma possvel atualizao de linhas constantes neste
bloco.
Aps essa porcentagem ser atingida, o bloco considerado cheio e no mais
disponvel para a insero de novas linhas.
O espao restante disponvel no bloco sera reservado para as alteraes das
linhas constantes neste bloco.
Este parmetro tambm pode ser especificado na criao ou alterao de
ndices.

PCTUSED

Permite que um bloco seja reconsiderado para insero de novas linhas.
Novas linhas sero inseridas, enquanto o bloco estiver espaos livres e no
atingir o limite determinado pelo PCTFREE.
Quando a porcentagem de blocos a serem usados cair abaixo do definido pelo
PCTUSED, em funo de deleo de linhas, o bloco novamente habilitado
para a insero de novas linhas. o PCTUSED default do sistema de 40.
PCTFREE e PCTUSED trabalham juntos para otimizar a utilizao de espaos
em um bloco de dados. Por exemplo, um PCTFREE de 20 e um PCTUSED de
40 faz com que :
As linhas sejam inseridas no bloco, at completar 80 % de sua
capacidade, o restante do espao fica reservado para alteraes.
Quando a quantidade de espaos usados ficar abaixo de 40 % ,
novas linhas podero ser inseridas no bloco.

Incrementando-se o PCTFREE, reduz-se a ocorrncia de ROW CHAINING (
linhas segmentadas em outros blocos) e ROW MIGRATION ( mudana de
linhas de um bloco para outro ). Um PCTFREE muito baixo resulta em ROW
MIGRATION.
Um ROW CHAINING ocorre com linhas grandes que contm colunas grandes,
quando todos os dados desta linha de tabela no cabem no mesmo bloco de
dados. Para se obter os dados da linha, deve-se chamar vrios blocos de
dados.

Um ROW MIGRATION ocorre se uma linha em um bloco de dados for alterada
e o seu tamanho extrapolar a capacidade do bloco, fazendo com que toda a
linha seja migrada para um novo bloco.
Tanto um row chaining como um row migration, causam problemas de
performance em operaes de I/O, pois o ORACLE devera procurar as
informaes em mais de um bloco de dados para a mesma linha.
Para resolver estes dois problemas, deve-se :
Examinar a extenso do chaining ou migration com o comando
ANALYZE
Alterar o PCTFREE para a tabela em questo
Exportar a tabela, deleta-la atravs do comando DROP e importa-la.

O PCTUSED usado tambm para diminuir a incidncia de fragmentao nos
blocos, em funo do grande volume de deleo de linhas dos blocos.
A fragmentao ocorre quando os espaos livres de um bloco no so
contguos, em funo de delees ou baixa valor definido no PCTUSED.
Para resolver este problema :
Automaticamente
O ORACLE ira realizar a operao de condensao de espao
livre nos blocos, em memria, sob circunstancias especiais.
Manualmente
Exportar a tabela, deleta-la atravs do comando DROP e importa-
la.
Modificando o PCTUSED para um valor mais apropriado.

Em suma, deve-se escolher valores para o PCTFREE e PCTUSED de forma a
permitir um melhor aproveitamento da utilizao de espaos e performance do
Banco de Dados. Para tanto deve-se observar que :
PCTFREE baixo :
Permite mais inseres de linha por bloco
Pode necessitar de menos blocos para armazenar dados
Pode tornar os processos mais lentos pois o ORACLE ira
reorganizar os blocos com mais freqncia
Pode causar problemas de ROW MIGRATION.

PCTFREE alto :
Reserva mais rea para alterao de linhas
Pode necessitar de mais blocos para armazenar dados
Torna os processos mais rpidos porque no ir reorganizar blocos
com freqncia
Reduz a necessidade de chain rows em funo de ROW
MIGRATION.

PCTUSED baixo :
Reduz o processamento porque os blocos no estaro livres com
freqncia, diminuindo o gerenciamento de espao livre no bloco
Aumenta a quantidade de espao no utilizado

PCTUSED alto
Aumenta o processamento porque os blocos podero ficar livres
com mais freqncia, aumentando o gerenciamento sobre o
reaproveitamento de espaos livres no bloco.
Melhora a utilizao de espaos no bloco.


INITRANS

o numero inicial de entradas de transao, para transaes concorrentes,
que sero alocadas em cada block header quando o bloco for alocado. Cada
entrada de transao ocupa 23 bytes em mdia, dependendo do sistema
operacional. Default sera 1, o mnimo sera 1 e o mximo sera 255

MAXTRANS

o numero mximo de transaes concorrentes que sero suportadas por
um bloco. Default sera 255, o mnimo sera 1 e o mximo sera 255.

INITRANS e MAXTRANS determinam o numero de transaes ativas em um
nico bloco.
Extenso - EXTENTS

Uma extenso um conjunto de blocos contguos alocados a um segmento.
Extenses so alocadas quando :
O segmento criado (INITIAL EXTENT)
O segmento cresce (NEXT EXTENT)
A tabela alterada alocando mais extenses

Extenses so desalocadas quando :
O segmento truncado ou deletado (DROPPED)
O segmento maior que a clausula OPTIMAL do rollback segments
e contem extenses livres ( apenas para o rollback segments).

Cada segmento em um Banco de Dados criado com pelo menos uma
extenso. Rollback segments, entretanto, ser sempre criada com pelo menos
duas extenses.
A primeira extenso chamada de extenso inicial do segmento. As extenses
subsequentes so chamadas de extenses de incrementao dos segmentos.
Uma tabela ou objeto do Banco de Dados somente alocar uma nova
extenso quando todas as extenses atuais estiverem sendo usadas.
Freqentes desalocaes de extenses podero causar fragmentao fsica de
arquivos no disco.

Controle de Alocao de Extenses

O controle de alocao de extenses para os segmentos, pode ser feito
atravs de parmetros individuais por objeto do Banco de Dados ou ser
definido com parmetros defaults para a tablespace.
So parmetros para armazenamento de :
Tabelas
Cluster
ndice
Rollback Segment
Tablespace

Parmetros :

INITIAL
Tamanho em bytes da primeira extenso a ser alocada pelo
segmento. O default equivalente a 5 blocos de dados (10 K).
NEXT
Tamanho em bytes das prximas extenses incrementadas no
segmento. O default equivalente a 5 blocos de dados (10 K).
MAXEXTENTS
Numero total de extenses que podem ser alocadas para o
segmento. O mximo depende do tamanho do bloco definido para
o ORACLE. O default 99.
MINEXTENTS
Numero total de extenses que sempre sero alocadas quando
o segmento for criado. O default 1 (uma) extenso.
PCTINCREASE
Percentual de crescimento de cada extenso de incremento,
sobre a ultima extenso de incremento alocada. Default de 50
porcento.
OPTIMAL
Especifica o melhor tamanho (optimal size) em bytes para o
rollback segment. O default nulo.
FREELIST
Numero de listas de blocos livres reservados para inseres em
tabelas.

Qualquer parmetro especificado para um objeto ira anular o parmetro
correspondente especificado para a tablespace, no caso deste objeto.
Quando nenhum parmetro for especificado para o objeto, sero assumidos os
parmetros default definidos para a tablespace.
Quando nenhum parmetro for especificado para a tablespace, sero aplicados
os defaults do sistema ORACLE.
Se os parmetros forem alterados, estes s sero aplicados nas novas
extenses a serem alocadas.

Mudanas nos parmetros de armazenamento:
Todos os parmetros default de armazenamento para a tablespace podem
ser inicializados ou alterados, sendo que no caso de alteraes, as mesmas s
sero vlidas a partir da criao dos novos objetos.

Estes parmetros devem ser usados para permitir que os armazenamentos de
objetos sejam feitos em espaos contguos do disco, minimizando as
fragmentaes, eliminando degradaes nos processos de I/O.
Segmentos (segments)

Um segmento o conjunto de uma ou mais extenses que contm todos os
dados armazenados de uma estrutura lgica (objetos e tabelas), em uma
tablespace.
So do tipo :
Segmento de dados (data segment)
Uma coleo de extenses de dados de uma tabela ou cluster.
Segmentos de ndice (ndex segment)
Uma coleo de extenses de dados de ndice usados para
otimizar as pesquisas em tabelas ou clusters
Segmentos Temporrios (temporary segments)
Uma coleo de extenses de dados pertencentes a tabelas
temporrias criadas durante uma operao de sort ou agrupamento.
Segmentos de Rollback (rollback segments)
Uma coleo de extenses de dados para rollback (update,
insert, delete), read-consistency ou recuperao (recovery).
Segmentos de Bootstrap (bootstrap segments)
Extenses que contm definies do dicionrio de dados, que
sero carregados quando da abertura do Banco de Dados. Este
segmento no necessita de ateno especial por parte do DBA,
ser controlado pelo ORACLE.

Recomenda-se que sejam criadas tablespace diferentes para cada um dos
segmentos acima.
Segmentos so estruturas lgicas que podem ser criadas, ocupando reas de
armazenamento iniciais, crescendo medida que necessrio.
Os segmentos no podem se expandir alm da rea definida da tablespace.
Os parmetros de armazenamento para os segmentos temporrios sero os
mesmos definidos para a tablespace, pois no se podem definir parmetros
especficos para este tipo de segmento.

Segmentos de Dados (data segments)

Segmentos de dados que contm dados das tabelas dos usurios.
Este segmento criado a partir do comando CREATE TABLE.

Exemplo :

CREATE TABLE TESTE
( ORDERID NUMBER(3) NOT NULL,
ORDERDATE DATE,
SHIPDATE DATE,
CLIENT VARCHAR(3) NOT NULL,
AMOUNT_DUE NUMBER(10,2),
AMOUNT_PAID NUMBER(10,2) )
PCTFREE 5
PCTUSED 65
TABLESPACE USER_DATA
STORAGE
( INITIAL 5M
NEXT 5M
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 121 );


Os dados da tabela so armazenados em forma de linhas. Uma linha a
combinao de valores de uma tabela, lidos de forma horizontal e contm uma
combinao nica de informaes descrevendo o relacionamento entre partes
de dados similares.
Com relao a linhas :
Tecnicamente falando, no existe limites de nmeros de linha em
uma tabela.
Linhas podem se expandir em mltiplos blocos, causando linhas
encadeadas (chained rows).
Linhas so armazenadas uma aps a outra, sem espaos entre si
Os valores das colunas so armazenados um aps o outro, em
formatos de tamanho variado.
O tamanho de um campo indica o tamanho de cada coluna
Colunas de tamanho zerado indica um campo nulo
Campos com seqncia de nulos no so armazenados.

Um CLUSTER um grupo de tabelas armazenadas juntas, em funo de
compartilharem colunas comuns e so, muitas vezes, usadas juntas.
Com relao a :
Clusters :
Armazenam uma ou varias tabelas no mesmo segmento de
dados.
Fora com que linhas de uma ou mais tabelas sejam
armazenadas juntas.
O tamanho do bloco lgico do cluster variado.
SIZE especifica o valor mdio do espao para armazenar todas
as linhas com a mesma chave de cluster.
Chave de cluster (cluster key) :
Pode ser uma ou mais colunas
Linhas de uma ou mais tabelas com a mesma chave de cluster,
so armazenadas juntas, no mesmo bloco de cluster.
Cada chave de cluster distinta armazenada apenas uma vez.
ndice do cluster (cluster ndex) :
Deve ser criado manualmente
No se pode inserir, alterar ou deletar informaes de tabelas em
clusters sem que exista o ndice do cluster.

O armazenamento em clusters mais usualmente utilizado para :
Dados mestre / detalhe (master/detail) em tabelas separadas
Tabelas grandes que sempre so lidas juntas e
Tabelas com baixo ndice de alteraes e delees.

Exemplo :
Criao de um cluster

CREATE CLUSTER EMP_DEPT (DEPTNO NUMBER)
/* UMA OU MAIS COLUNAS NA CLUSTER KEY
SIZE 500
TABLESPACE USER_DATA
STORAGE
( INITIAL 2M
NEXT 500 K
PCTINCREASE 100 );

Criao das tabelas EMP e DEPT em um cluster

CREATE TABLE EMP
( EMPNO NUMBER NOT NULL,
DEPTNO NUMBER NOT NULL,
.................... )
CLUSTER EMP_DEPT (DEPTNO);

CREATE TABLE DEPT
( DEPTNO NUMBER NOT NULL,
DNAME CHAR(9),
LOC CHAR(9) )
CLUSTER EMP_DEPT (DEPTNO);

Criao do ndice

CREATE INDEX CLU_EMP_DEPT ON CLUSTER EMP_DEPT;

Segmento de ndice (ndex segment)

Se um ndice criado para uma tabela, um segmento de ndice sera criado
para cada ndice.
Caractersticas do segmento de ndice:
Uso de arvore balanceada (B*-TREE) localiza rapidamente os
valores chaves
Os valores chave so comprimidos
O endereo hexadecimal da linha (ROWID) permite um acesso
direto ao bloco de dados.
Consultas que referenciam apenas colunas indexadas so
resolvidas no prprio ndice.
Pesquisas indexadas so uma alternativa para se pesquisar tabelas
cheias
independente da tabela ou cluster
Cada ndice pode ter seus prprios parmetros de armazenamento
Os ndices so, geralmente, bem menores que a tabela que
indexam
Os ndices podem ser armazenados em tablespaces separados
para otimizao.

Exemplo da criao de ndices :

CREATE INDEX EMP_ENAME
ON EMP (ENAME) \* TABELA E
COLUNA *\
STORAGE ( INITIAL 500K NEXT 500K PCTINCREASE 0 )
TABLESPACE USER_DATA;

Segmentos Temporrios (temporary segment)

Segmentos temporrios so reas de trabalho utilizados pelo SGBD para o sort
e join de tabelas, enquanto executam consultas complexas.
So criados automaticamente pelo ORACLE durante a execuo de comandos
complexos como joins, group by, order by, criao de ndices e qualquer
operao que utilize classificao (sort).
Esses segmentos so criados em memria se houver espao suficiente, ou,
caso no haja espao de memria, criados em disco. Aps o final da operao,
essas reas so liberadas.
Sempre que criados em disco, sero utilizados espaos da tablespace
determinada pelo DEFAULT STORAGE.
A tamanho da rea de trabalho para o sort ser definido no parmetro
SORT_AREA_SIZE.

Segmentos de Rollback (rollback segments)

Os segmentos de rollback so gravados de forma circular para usos de
rollback, read consistency e recuperaes de dados.
Cada segmento de rollback :
Consiste de varias entradas de rollback de mltiplas transaes
Armazena blocos de informaes como arquivos e blocos de
identificao, alm de dados das linhas como eram antes das
modificaes
Devem ser criados sob condies especiais e colocados on-line
antes de executar-se qualquer transao
Ir desalocar extenses automaticamente quando o seu tamanho
for maior que o definido no
Ir crescendo de tamanho medida em que se forem executadas
novas transaes parmetro OPTIMAL
Poder ser associado transao automaticamente ou
explicitamente.

O ORACLE necessita de um rollback segment chamado SYSTEM para ser
aberto e colocado on-line. O SYSTEM rollback segment criado quando da
primeira criao das bases de dados.

Parmetros de armazenamento do rollback segment :
INITIAL
NEXT
MINEXTENTS (deve ser igual a 2 no mnimo)
MAXEXTENTS
OPTIMAL

O parmetro PCTINCREASE no pode ser especificado para rollback
segments, sendo sempre igual a zero.
Exemplo de criao de um rollback segment e de sua ativao on-line :

CREATE PUBLIC ROLLBACK SEGMENT RBS01
TABLESPACE RBS
STORAGE (INITIAL 10K NEXT 10K
OPTIMAL 20K MAXEXTENTS 121) ;

ALTER ROLLBACK SEGMENT RBS ONLINE;

Segmento de Bootstrap (bootstrap segment)

O Bootstrap segment contm tabelas do dicionrio de dados que sero
carregadas sempre que o Banco de Dados for aberto.
Este segmento no pode ser lido, modificado ou apagado. Sera criado na
tablespace SYSTEM e o seu proprietrio o usurio SYS.
Este segmento no necessita de aes por parte do DBA ocupa, usualmente,
cerca de 50 blocos.

RAMIRO

Tablespaces e Data Files - Informaes complementares

Os dados no Banco de Dados ORACLE so armazenados logicamente em
tablespaces e fisicamente so armazenados em arquivos de dados.

Estrutura lgica :

Uma base de dados ORACLE pode ser subdividida em reas lgicas menores
em uma tablespace.

Cada tablespace contm um ou mais arquivos operacionais do sistema.
As tablespaces podem ser colocadas online mesmo aps o banco ter sido
aberto.
As tablespaces podem ser colocadas offline mesmo aps o banco ter sido
aberto, menos a tablespace SYSTEM.
Objetos criados em uma tablespace no podem nunca, alocar espaos em
outra tablespace que no a sua original.
A tablespace SYSTEM usada em todas as operaes do Banco de Dados e,
contm as informaes do dicionrio de dados, definies de stored
procedures, packages e triggers, alm do rollback segment do sistema. Pode
vir a conter dados dos usurios.
Uma base de dados consiste em no mnimo, uma tablespace. Geralmente, so
criadas tablespaces para cada rea de dados do usurio, permitindo um melhor
controle e documentao das atividades do Banco de Dados. Por exemplo :
Uma tablespace s para os rollback segments
Uma tablespace s para os redo logs files
Uma tablespace s para as tabelas dos usurios
Uma tablespace s para ndices de tabelas
Uma tablespace s para reas temporrias
Etc...

Estrutura fsica

O total de espao fsico a ser alocado pelo ORACLE depende do tamanho das
tabelas do sistema e tabelas do usurio, alm da capacidade de
armazenamento do disco utilizado.
Cada tablespace composta de um ou mais arquivos fsicos no disco. Um
segmento, assim como uma tabela de segmentos, pode se expandir em
mltiplos arquivos, enquanto esses arquivos pertencerem mesma tablespace.

Informaes sobre extenses e segmentos

possvel saber quantas extenses foram alocadas e quantos segmentos
existem em cada objeto, utilizando-se consultas ao dicionrio de dados do
ORACLE , utilizando-se as views :
USER/DBA_EXTENTS
USER/DBA_FREE_SPACE
USER/DBA_SEGMENTS
DBA_TABLESPACES
DBA_DATA_FILES
Exemplos :
Listar o nome das colunas da view DBA_TABLESPACE :

DESCRIBE DBA_TABLESPACES;

NAME NULL? TYPE
---------------------------------- ----------- -----------------------------
TABLESPACE_NAME VARCHAR2(30)
INITIAL_EXTENT NUMBER
NEXT_EXTENT NUMBER
MIN_EXTENTS NUMBER
MAX_EXTENTS NUMBER
PCT_INCREASE NUMBER
STATUS VARCHAR2(9)

Listar o nome e o status de cada tablespace :
SELECT TABLESPACE_NAME, STATUS
FROM DBA_TABLESPACES;

TABLESPACE_NAME STATUS
------------------------------------- -----------------------
SYSTEM ONLINE
APPL_DATA ONLINE
RBS ONLINE
TEMP ONLINE

Listar o nome das colunas da view DBA_DATA_FILES :
DESCRIBE DBA_DATA_FILES;

NAME NULL? TYPE
---------------------------------- ----------- -----------------------------
FILE_NAME VARCHAR2(257)
FILE_ID NUMBER
TABLESPACE_NAME VARCHAR2(30)
BYTES NUMBER
BLOCKS NUMBER
STATUS VARCHAR2(9)

Listar informaes gerais sobre os arquivos pertencentes tablespace :
SELECT FILE_NAME, FILE_ID, TABLESPACE_NAME, BYTES
FROM DBA_DATA_FILES;

FILE_NAME FILE_ID TABLESPACE_NAME BYTES
-------------------------- ----------- ------------------------------ ---------------
DBA01_1.DBF 1 SYSTEM 10485760
.............

Mostrar as extenses com espao disponvel em cada tablespace :
SELECT *
FROM DBA_FREE_SPACE
ORDER BY FILE_ID, BLOCK_ID;

TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS
------------------------------ ----------- ------------- ---------- ------------
SYSTEM 1 900 18432 9
SYSTEM 1 909 4096 2
SYSTEM 1 1912 6572032 3209
.............

Listar os nomes das colunas da view DBA_SEGMENTS :
DESCRIBE DBA_SEGMENTS;

NAME NULL? TYPE
---------------------------------- ----------- -----------------------------
OWNER VARCHAR2(30)
SEGMENT_NAME VARCHAR2(81)
SEGMENT_TYPE VARCHAR(17)
TABLESPACE_NAME VARCHAR2(30)
HEADER_FILE NUMBER
HEADER_BLOCK NUMBER
BYTES NUMBER
BLOCKS NUMBER
EXTENTS NUMBER
MAX_EXTENTS NUMBER

Listar informaes gerais sobre todos os segmentos da base de dados
SELECT OWNER, EGMENT_NAME, EXTENTS, MAX_EXTENTS
FROM DBA_SEGMENTS
ORDER BY 1, 2;

OWNER SEGMENT_NAME EXTENTS MAX_EXTENTS
----------------- ------------------------- -------------- -----------------------
SCOTT EMP 5 25
SYSTEM RBS1 20 121
SYSTEM RBS2 2 121
SYS UNDO$ 50 99
........................

Listar informaes sumarizadas por grupo, sobre todos os segmentos em cada
tablespace :
SELECT TABLESPACE_NAME, COUNT(*) SEGMENTS,
SUM(BYTES) BYTES
FROM DBA_SEGMENTS
GROUP BY TABLESPACE_NAME;
TABLESPACE_NAME SEGMENTS BYTES
------------------------------ ---------------- --------------------
APPL_DATA 10 10240
RBS 2 40960
SYSTEM 108 2240512
TEMP 0 20480

Listar os nomes das colunas da view DBA_EXTENTS :
DESCRIBE DBA_EXTENTS;

NAME NULL? TYPE
---------------------------------- ----------- -----------------------------
OWNER VARCHAR2(30)
SEGMENT_NAME VARCHAR2(81)
SEGMENT_TYPE VARCHAR(17)
TABLESPACE_NAME VARCHAR2(30)
EXTENT_ID NUMBER
FILE_ID NUMBER
BLOCK_ID NUMBER
BYTES NUMBER
BLOCKS NUMBER
SISTEMA GERENCIADOR DE BANCO DE DADOS ORACLE
DBA - ADMINISTRAO DO BANCO DE DADOS

4 - Criao das Bases de Dados

Desenho da Base de Dados :




DATABASE


1

N


TABLESPACE OPERATING SYSTEM
FILE
1 N

1

N

EXTENT

BLOCK
FREE USED 1 N


N N
1 1



DATA INDEX CLUSTER




ROLLBACK TEMPORARY CACHE



Determinando as Tablespaces

As tablespaces podem ser colocadas online mesmo aps o banco ter sido
aberto.
As tablespaces podem ser colocadas offline mesmo aps o banco ter sido
aberto, menos a tablespace SYSTEM.
Objetos criados em uma tablespace no podem nunca, alocar espaos em
outra tablespace que no a sua original.
Toda Base de Dados deve ter um mnimo de 5 (cinco) tablespaces, alm da
tablespace SYSTEM. Recomenda-se que :
Uma tablespace s para os rollback segments
Uma tablespace s para os redo logs files
Uma tablespace s para as tabelas dos usurios
Pode-se considerar em alguns casos, uma tablespace para cada
aplicao
Uma tablespace s para ndices de tabelas
Uma tablespace s para reas temporrias.

Deve-se considerar as caractersticas dos dados antes de armazena-los, para
determinar qual a tablespace mais adequada.
Arquivo de Parmetros - INIT.ORA / INITORCL.ORA

O arquivo de parmetros somente lido durante a criao do Banco de Dados
ou na sua abertura. Se o arquivo for modificado com o banco aberto, deve-se
proceder ao shutdown e nova abertura do Banco de Dados para que os valores
alterados possam ser utilizados pelo Banco de Dados.

O arquivo de parmetros determina :
O tamanho dos componentes da SGA (shared global rea).
Os tamanhos default a serem utilizados pelo Banco de Dados
Os limites do Banco de Dados
Os vrios atributos fsicos do Banco de Dados, durante sua criao
Os control files do Banco de Dados
A otimizao de performance, ajustando a estruturas de memria
Vrios parmetros operacionais.

um arquivo tipo texto e pode ser manipulado por qualquer editor de arquivos.
Este arquivo usualmente chamado de INIT.ORA (na verso 7.3, seu nome
INITORCL.ORA), e automaticamente procurado durante a abertura do Banco
de Dados (default). Pode-se, entretanto, criar um outro arquivo de parmetros
com outro nome e, para utiliza-lo, informar seu nome durante a abertura do
Banco de Dados.
Existe uma srie de parmetros que podem ser especificados. Exatamente
quais devem ser especificados, ir depender muito das necessidades de
inicializao do Banco de Dados. Decidir sobre quais parmetros devem ser
modificados, s ser possvel aps a anlise das informaes obtidas durante
a monitorao do Banco de Dados.
Alguns dos Parmetros existentes :

DB_NAME
Nome do Banco de Dados com oito caracteres ou menos

CONTROL_FILES
Nome dos control files

INIT_SQL_FILES
Nomes de arquivos de comando (scripts) que devero ser executados
durante a criao do Banco de Dados.

LOG_ARCHIVE_DEST
Localizao dos redo log files.

LOG_ARCHIVE_FORMAT
Nome default do arquivo de formatos para o arquivamento dos redo logs

USER_DUMP_DEST
Local aonde ser criado os arquivos de trace

BACKGROUND_DUMP_DEST
Local onde os arquivos de trace dos processos de background sero
criados

AUDIT_TRAIL
Habilita ou desabilita a gravao de linhas de audit trail (trilha de
auditoria que mostra o caminho seguido por um comando SELECT)

DB_BLOCK_BUFFERS
Numero de blocos cached na SGA

DB_BLOCK_SIZE
Tamanho em bytes dos blocos do Banco de Dados ORACLE

DML_LOCKS
Numero mximo de DML LOCKS

IFILE
Nome de outro arquivo de parmetros a ser considerado

LOG_BUFFER
Numero de bytes alocados para os buffers de redo log na SGA

LOG_ARCHIVE_START
Habilita ou desabilita o arquivamento automtico no modo ARCHIVELOG

LOG_CHECKPOINT_INTERVAL
Para aumentar a freqncia dos checkpoints

MAX_DUMP_FILE_SIZE
Tamanho mximo dos blocos do sistema para arquivos trace

OPEN_CURSORS
Numero mximo de cursores que um usurio pode ter aberto ao mesmo
tempo.

PROCESSES
Numero mximo de processos conectados simultaneamente no ORACLE

ROLLBACK_SEGMENTS
Nome dos rollback segments alocados para a instance

SHARED_POOL_SIZE
Tamanho em bytes para compartilhamento de comandos SQL

SQL_TRACE
Habilita ou desabilita o trace para comandos SQL para cada usurio

TIMED_STATISTICS
Habilita ou disabilita o tempo de trace na tela do monitor

SORT_AREA_SIZE
Tamanho em bytes de rea a ser reservada em memria, para sort

DB_FILES
Numero mximo de data files para a instance

Exemplo :

BACKGROUND_DUMP_DEST = ORA:ORAWIN\RDBMS70
USER_DUMP_DEST = ORA:ORAWIN\RDBMS70
DB_FILES = 20
DB_BLOCK_BUFFERS = 200
SHARED_POOL_SIZE = 3000000
LOG_CHECPOINT_INTERVAL = 10000
PROCESSES = 50
LOG_BUFFER = 8192

Para se conhecer o valor default de determinado parmetro quando o banco
estiver sendo usado, utiliza-se o comando na console do servidor :
- SHOW PARAMETER nome do parmetro

Na verso 7.3 usa-se o menu da tela do gerenciador : LOAD NWDBMGR.
Exemplo :

Listar os valores de todos os parmetros com a string DB no seu nome :

- SHOW PARAMETER DB

NAME TYPE VALUE
--------------------------- -------------- -----------
DB_BLOCK_BUFFER INTEGER 60
DB_BLOCK_SIZE INTEGER 2048
.......................

Listar os valores de todos os parmetros com a string DEST no seu nome :

- SHOW PARAMETER DEST

NAME TYPE VALUE
--------------------------- -------------- -----------------------------------
BACKGROUND_DUMP_DEST STRING ORA:ORAWIN\RDBMS70
CORE_DUMP_DEST STRING ORA:DBS\CORE
LOG_ARCHIVE_DEST STRING ORA:DBS\ARCH
USER_DUMP_DEST STRING ORA:ORAWIN\RDBMS70
.......................

Criao do Banco de Dados

O Banco de Dados ORACLE (ORACLE database) consiste em
Arquivos de dados que sero armazenados em tabelas e ndices,
Arquivos de redo log, que fazem parte da estrutura de recuperao
de informaes do ORACLE
Control files, que contm informaes necessrias para abrir e
manter o Banco de Dados.

Para se criar um Banco de Dados, usa-se o comando :

CREATE DATABASE nome
CONTROLFILE REUSE
LOGFILE [GROUP numero] especificao
MAXLOGFILES numero
MAXLOGMEMBERS numero
MAXLOGHISTORY numero
DATAFILE especificao
MAXDATAFILES numero
MAXINSTANCES numero
ARCHIVELOG/NOARCHIVELOG
EXCLUSIVE

Onde :
nome = Nome do Banco de Dados a ser criado
especificao = Especificao do endereo e nome do arquivo a ser
usado

CONTROLFILE REUSE
Especifica que o control file existente, identificado no parmetro,
deve ser reusado.

LOGFILE GROUP
Especifica o nome dos arquivos que sero usados como log files
e o grupo a que pertencem.

MAXLOGFILES
O numero mximo de control files a ser criado para o Banco de
Dados.

MAXLOGMEMBERS
O numero mximo de membros pertencentes a um grupo de log
files.

MAXLOGHISTORY
O numero mximo de arquivamento dos redo logs, para
recuperao automtica em um servidor ORACLE paralelo.

DATAFILE
Nome do Data File a ser usado.

MAXDATAFILES
O numero mximo de data files que podem ser criados no Banco
de Dados.

MAXINSTANCES
O numero mximo de instances que podem ser montadas e
abertas simultaneamente.

ARCHIVELOG
Estabelece que os redo logs devem ser arquivados antes de
serem reutilizados.

NOARCHIVELOG
Estabelece que os redo logs no devem ser arquivados antes de
serem reutilizados.

EXCLUSIVE
Monta o Banco de Dados em modo exclusivo aps ele ser criado.

Se o REUSE for especificado, o data file especificado deve existir. Se a opo
SIZE for especificada, o data file no deve existir, ele ser criado juntamente
com o Banco de Dados.
Exemplo da criao de um Banco de Dados chamado TESTE, com um data file
chamado SYSTEM.DBS com 5 Mbytes de tamanho e, dois log files chamados
LOG1A.RDO e LOG2A.RDO com um tamanho de 500 Kbytes cada um :

CREATE DATABASE TESTE
DATAFILE ORA:PROD\RDBMS\SYSTEM.DBS SIZE 5M
LOGFILE ORA:PROD\LOGS\LOG1A.RDO SIZE 500K,
ORA:PROD\LOGS\LOG2A.RDO SIZE 500K;

O arquivo de controle - control file - lido em tempo de abertura do Banco de
Dados e, se no for encontrado, o Banco no ser aberto pois nesse arquivo
esto todos os dados de estrutura do Banco.
Para evitar problemas, recomenda-se que seja feita uma ou mais cpias do
control file e que seja referenciado no mnimo dois control files para cada
Banco de Dados. Para tanto, deve-se seguir os seguintes passos :

Shut down no Banco de Dados
Faa uma cpia do control file para uma outra localizao, se
possvel, em outro disco
Alterar o arquivo de parametros, incluindo o nome do novo control
file
Abrir o Banco de Dados com o recm modificado arquivo de
parmetros.

O redo log file tambm no deve ser um nico arquivo no Banco de Dados.
Devemos nos certificar de que cada grupo de redo log file tenha mais de um
membro. Para tanto, pode-se incluir novos membros nos grupos de redo log
file com o Banco online, utilizando-se o comando :
ALTER DATABASE nome
ADD LOGFILE MEMBER
nome do arquivo REUSE TO GROUP numero
Onde :

nome = o nome do Banco de Dados
nome do arquivo = o nome do novo arquivo de log - redo log file
numero = o numero do grupo em que o novo arquivo ir
pertencer.

Pode-se consultar os log files existentes, atravs da view V$LOGFILE,
verificando o status de cada um.
Exemplo :

Alterar o Banco de Dados TESTE, colocando mais um redo log
chamado LOG1B.RDOno grupo 1 e verificando em seguida se o
arquivo foi criado com sucesso :


ALTER DATABASE TESTE
ADD LOGFILE MEMBER ORA:PROD\LOGS\LOG1B.RDO
TO GROUP 1;

SELECT * FROM V$LOGFILE;

GROUP # STATUS MEMBER
------------- ----------- ----------------------------------------------------
1 ORA:PROD\LOGS\LOG1A.RDO
2 ORA:PROD\LOGS\LOG2A.RDO
1 ORA:PROD\LOGS\LOG1B.RDO
Outras Consideraes sobre o Dicionrio de Dados

Uma das partes mais importantes de um Banco de Dados ORACLE e o seu
Dicionrio de Dados. O Dicionrio de Dados um conjunto de tabelas e views
usadas apenas para leitura, que fornece informaes sobre o Banco de Dados.
Informaes do Dicionrio de Dados :
Nomes dos usurios ORACLE
Privilgios e Roles de cada usurio
Nomes e definies de varios objetos do Banco de Dados
Constraints de integridade referencial
Alocao de espao dos objetos do Banco de Dados
Estrutura geral do Banco de Dados
Informaes de auditoria do Banco de Dados
Armazenamento de triggers, functions, packages e procedures.

As bases de dados das tabelas do Dicionrio de Dados so criadas pelo
arquivo de comandos - script - SQL.BSQ, que est especificado pelo parmetro
INIT_SQL_FILES, no arquivo de parmetros usado para criar o Banco de
Dados - INIT.ORA.
Existem outros scripts que geram determinadas funes do Dicionrio de
Dados, que podem ser rodados durante ou aps a criao do Banco. Alguns
dos scripts so :
CATALOG.SQL
Cria as views mais comumente utilizadas do Dicionrio de Dados.

EXPVEW.SQL
Cria as views necessrias para rodar os utilitarios de importao
e Exportao.

AUDIT.SQL
Cria o audit trail e as views associadas.

BLOCKING.SQL
Cria a view BLOCKING_LOCKS, que poder ser usada para
investigar problemas de locking.

MONITOR.SQL
Permite acesso s tabelas dinamicas do banco, atravs do
GRANT PUBLIC.

DBA_SYNONYMS.SQL
Cria sinonimos privados para as views de DBA do Dicionrio de
Dados.

Estes scripts esto no diretrio RDBMS70/ADMIN.
O Dicionrio de Dados a fonte central de informaes para o servidor
ORACLE e os usurios do Banco de Dados. O Dicionrio usado por :
Administradores do Banco de Dados - DBA
Usurios do Banco de Dados
As aplicaes
O prprio ORACLE.

No se deve usar nunca comandos DML como INSERT, UPDATE e DELETE,
para alterar a base de dados do Dicionrio, diretamente. Altera-se o Dicionrio
implicitamente, atravs de comandos DDL. Para se pesquisar o Dicionrio de
Dados, usa-se o comando SELECT nas tabelas e views apropriadas do
Dicionrio de Dados.
As informaes do Dicionrio de Dados esto divididas em views e tabelas,
divididas nas seguintes categorias :
- DBA_XXXX = Acessadas apenas pelo DBA, dando informaes de
qualquer objeto do Banco de Dados.

- USER_XXXX = Acessadas por qualquer usurio, dando
informaes
somente sobre os objetos de sua
propriedade.

- ALL_XXXX = Acessadas por qualquer usurio, dando
informaes
sobre qualquer objeto acessvel pelo
usurio.

Comandos para a Tablespace

Criao de Tablespace

CREATE TABLESPACE nome
DATAFILE especificao


DEFAULT STORAGE
( INITIAL numero K/M
NEXT numero K/M
MINEXTENTS numero
MAXEXTENTS numero
PCTINCREASE numero
ONLINE / OFFLINE

Onde :

nome : Nome da tablespace a ser criada

especificao : Especifica o arquivo ou grupo de arquivos que
sero usados como redo log. Aceita ainda, a clasula SIZE ou REUSE

- INITIAL
Tamanho em bytes da primeira extenso a ser alocada pelo
segmento.

- NEXT
Tamanho em bytes das prximas extenses incrementadas no
segmento.

- MAXEXTENTS
Numero total de extenses que podem ser alocadas para o
segmento. O mximo depende do tamanho do bloco definido para o
ORACLE. O default 99.

- MINEXTENTS
Numero total de extenses que sempre sero alocadas quando o
segmento for criado. O default 1 (uma) extenso.

- PCTINCREASE
Percentual de crescimento de cada extenso de incremento, sobre
a ultima extenso de incremento alocada. Default de 50 porcento.

Exemplo :

Criao da tablespace MRP com um data file chamado MIS.DBF com o
tamanho de 50 Mbytes, deixando-a imediatamente disponvel para uso :

CREATE TABLESPACE MRP
DATAFILE ORA:SALTO\MIS.DBF SIZE 50M
DEFAULT STORAGE
( INITIAL 10K
NEXT 50K
MINEXTENTS 1
MAXEXTENTS 10
PCTINCREASE 10 )
ONLINE;


Alterao de Tablespace

Comando para alterar os parmetros de armazenamento (storage parameters),
deixar a tablespace online ou off line, adicionar data files, renomear data files :

ALTER TABLESPACE nome
ADD DATAFILE especificao
RENAME DATAFILE nomearq TO novonomearq
DEFAULT STORAGE
( INITIAL numero K/M
NEXT numero K/M
MINEXTENTS numero
MAXEXTENTS numero
PCTINCREASE numero
ONLINE / OFFLINE
NORMAL / TEMPORARY / IMMEDIATE
BEGIN / END BACKUP

Onde :

ADD TABLESPACE :
Adiciona um novo data file tablespace

RENAME DATAFILE :
Renomeia um ou mais data files da tablespace

DEFAULT STORAGE:
Define os novos parmetros de armazenamento da tablespace,
vlido apenas para os novos objetos a serem criados na tablespace

ONLINE :
Ativa a tablespace

OFFLINE :
Desativa a tablespace

NORMAL :
Realiza um checkpoint para todos os arquivos da tablespace

TEMPORARY :
Realiza um checkpoint para todos os arquivos online na tablespace,
mas no assegura que todos os arquivos sero gravados

IMMEDIATE :
No assegura que os arquivos da tablespace estejam disponveis e
no realiza um checkpoint.

Apagar tablespace

Comando para apagar uma tablespace do Banco de Dados :

DROP TABLESPACE nome
INCLUDING CONTENTS
CASCADE CONSTRAINTS

Onde :

INCLUDING CONTENTS :
Apaga todos os componentes da tablespace

CASCADE CONSTRAINTS :
Apaga todas as constraints de integridade referencial de tabelas
externas tablespace, que referenciam chaves primrias e unicas nas
tabelas da tablespace a ser dropada.

Rollback Segments - Outras Informaes

A rollback segment a poro do Banco de Dados que grava a imagem de
dado anterior sua modificao pela transao, permitindo que estas
modificaes sejam desfeitas (rolled back) sob certas circunstancias.
Uma transao uma unidade de trabalho que causa alteraes a serem feitas
nas bases de dados, inclusive lock de linhas. Cada transao alocada com
um unico identificador e assinala um e somente um rollback segment.
Rollback Segment permite :
Retornar as informaes anteriores de toda uma transao ou at o
savepoint especificado, em caso de erros de operao
O read consistency de linas das tabelas
A recuperao do Banco de Dados
A gravao de dados que foram modificados em qualquer
tablespace, com exceo da SYSTEM rollback segment
Gravar alteraes de multiplas tabelas.

Existem tres tipos de rollback segment :
PRIVATE : Deve ser incluida no parmetro
ROLLBACK_SEGMENTS no arquivo de parmetros, para ser
reconhecido pelo sistema.
PUBLIC : Forma um pool de rollback segment que pode ser usado
por qualquer instance que requeira um rollback segment adicional
DEFERRED : Criado quando uma tablespace colocada offline, de
modo que as transaes no sejam desfeitas imediatamente.
sempre criado na tablespace SYSTEM e no pode ser criada pelo
DBA.

Um rollback segment um objeto circular e cada transao pode ter muitas
entradas. Uma transao pode usar a proxima extenso de rollback, se no
houverem mais entradas ativas na extenso atual.
Se a prxima extenso usada tiver entradas ativas, novas extenses sero
somadas ao rollback segment, providenciando que o numero maximo de
extenses no seja alcanado.
Deve-se considerar o nivel de atividades e o numero de transaes que sero
gravadas no rollback segment, para determinar os parmetros de
armazenamento apropriados para criar e otimizar a area de rollback segment.
Considerar que :
Cada transao sera assinalada a um rollback segment
Existe um numero finito de headers de entrada em um rollback
segment, a que todas as transaes devem ser referenciadas.

Um rollback segment deve ter um tamanho definido na clausula OPTIMAL, em
bytes, que deve ser especificado na sua criao (ou alterao), de forma que o
rollback segment encolha sempre para este tamanho, toda vez que o nmero
de transaes ativas sejam confirmadas em disco e o espao por elas
ocupadas sejam apagados, criando extenses sem dados gravados, fazendo
com que estas extenses sejam desalocadas, otimizando o tamanho do
segmento de roll back.
Para se obter informaes sobre o crescimento e o encolhimento da rollback
segment, consultar a view V$ROLLSTAT ou a tela SQLDBA MONITOR
ROLLBACK.

Criar um Rollback Segment

Recomenda-se criar uma tablespace no Banco de Dados para que seja criada
especificamente para conter rollback segments.
Deve-se criar um rollback segment tipo DUMMY, na tablespace SYSTEM,
deixando-o online, caso seja a primeira vez que se est criando um rollback
segment no Banco de Dados.

Criar o rollback segment na tablespace especfica, tornado-o online.
Se o rollback segment for privado (private), referencia-lo no arquivo de
parmetros.
Tornar o rollback segment DUMMY offline.

Comando de criao :

CREATE [PUBLIC] ROLLBACK SEGMENT nome
TABLESPACE nome-tablespace
STORAGE
( INITIAL numero K/M
NEXT numero K/M
MINEXTENTS numero
MAXEXTENTS numero
OPTIMAL numero )

Onde :

PUBLIC : Especifica que a rollback segment pertence ao pool publico.

Exemplo :

Criao de rollback segment chamado RS1 na tablespace SYSTEM
:


CREATE ROLLBACK SEGMENT RS1
TABLESPACE SYSTEM
STORAGE ( INITIAL 100K
NEXT 100K
MINEXTENTS 2
MAXEXTENTS 121
OPTIMAL 1000K );

Alterao de Rollback Segment

Para tornar um rollback segment online ou offline, com o banco ativo.
Comando :

ALTER ROLLBACK SEGMENT nome
ONLINE / OFFLINE
STORAGE
( INITIAL numero K/M
NEXT numero K/M
MINEXTENTS numero
MAXEXTENTS numero
OPTIMAL numero )

Exemplo :
Tornar o rollback segment RS1 ativo, verificando seu status no
Dicionrio de Dados :

ALTER ROLLBACK SEGMENT RS1
ONLINE;

SELECT SEGMENT_NAME, STATUS
FROM DBA_ROLLBACK_SEGS;

SEGMENT_NAME STATUS
---------------------------------- --------------------------------
SYSTEM ONLINE
RS1 ONLINE


Apagar Rollback Segment

Um rollback segment dever ser apagado sempre que as extenses deste
segmento se tornarem muito fragmentadas ou se quiser que este rollback
segment ocupe outra tablespace.

Comando :

DROP ROLLBACK SEGMENT nome

Observar que o rollback segment deve estar offline para ser apagado, no
podendo estar em uso.

Exemplo :

Tornar o rollback segment RS01 offline e apaga-lo :

ALTER ROLLBACK SEGMENT RS01 OFFLINE;

DROP ROLLBACK SEGMENT RS01;

SISTEMA GERENCIADOR DE BANCO DE DADOS ORACLE
DBA - ADMINISTRAO DO BANCO DE DADOS

5 - Back Up e Recuperao de Dados


Base de Dados Online ( Online Database Files)







Data Files Redo Log Control Parameter
Files Files Files



Bases de Dados Offline - BACKUP (Offline Database File Backups)










Data Files Redo Log Control Parameter Offline Redo
Files Files Files Log Files


Uma das maiores responsabilidades do DBA o Backup e a recuperao das
bases de Dados em caso de erros. Prevendo-se os tipos de erros que podem
ocorrer durante o uso do Banco de Dados, poder-se-a definir nveis de backup
de forma que as operaes retornem ao normal o mais rpido possvel.
Para se executar uma recuperao com sucesso, deve-se :
Prever os tipos de erro que podem ocorrer
Escolher um mtodo de backup
Entender as estruturas de recuperao
Realizar os Backups corretamente
Familiarizar-se com as estratgias de backup
Praticar e testar as recuperaes.

Existem vrios tipos de erros que podem ocorrer em uma base de dados.
Alguns erros necessitam interveno do DBA, outros no.
Erros :
Erros do usurio
Erros de comando
Erros do processo
Erros de instance
Erros de midia.

A interveno do DBA mais usualmente requisitada na recuperao de erros
do usurio. As causas mais comuns so :
O usurio apagar ou truncar acidentalmente uma tabela
O usurio deleta todas as linhas de uma tabela
O usurio aps comitar os dados, descobre um erro.

As solues so :
Treinar o usurio
Recuperar as informaes de um backup vlido
Importar tabelas exportadas
Recuperar os dados at um momento antes do erro (point-in-time
recovery).

O DBA pode ou no intervir em erros de comandos. Os erros mais comuns so
:
Erro lgico na aplicao
O usurio tenta entrar com dados errados na tabela
O usurio tenta uma operao para qual no possui o privilgio
O usurio tenta criar uma tabela mas excede o seu limite de quota
(uso de espao em uma tablespace)
O usurio tenta inserir ou alterar uma tabela, causando a
necessidade de se alocar uma extenso, sem que haja espao livre
suficiente na tablespace.

As solues so :
Consertar a aplicao eliminando o erro
Modificar o comando SQL e reexecuta-lo
Fornecer os privilgios necessrios ao usurio
Mudar o limite de quota do usurio, atravs de comando ALTER
USER
Adicionar espao na tablespace, adicionando-se mais DATA FILES

O DBA no interfere em casos de erros de processos. Os mais comuns so :
O usurio realiza uma desconexo anormal de sesso
A sesso do usurio termina de forma anormal
O programa do usurio fornece um endereo de exceo durante a
execuo, terminando a sesso.


No caso de Erro de Instance, o DBA deve proceder recuperao da instance
pelo comando STARTUP, determinando o problema ocorrido. So as causas
mais comuns de erros em instance :
Queda de energia eltrica
Problemas de hardware, como falhas na CPU ou Memria
Problemas de software, como quedas do sistema operacional
Algum dos processos secudanrios do ORACLE apresentaram erros
(DBWR, LOGWR, PMON, SMON).

A recuperao de instance restaura os dados at o ponto em que ocorreu a
falha. Essa recuperao iniciada automticamente pelo servidor ORACLE
assim que o Banco for aberto, pelos comandos :
CONNECT INTERNAL;
STARTUP;

Passos do STARTUP :
O INIT.ORA lido, a SGA criada, os processos de background
so iniciados e a instance iniciada.
O control file lido e o Banco de Dados montado
Inicia-se a recuperao de dados que no foram gravados nas
bases de dados (tabelas), mas que foram gravadas online no redo log,
inclusive as areas de rollback segment so recuperadas
As transaes que sofreram roll back ou que no foram comitadas,
so retornadas (rolled back) conforme indicado no rollback segment
recuperado
Todas as transaes pendentes, antes do erro, so liberadas
Todas as transaes distribuidas pendentes so resolvidas atravs
do two-fase-commit, at o ponto em que o erro ocorreu
Uma vez que o processo SMON seja sincronizado e todas as
informaes dos redo log files forma aplicadas e recuperadas, o Banco
de Dados aberto aos usurios.

Os erros de midia, envolvem problemas fiscos em leituras e gravaes dos
dados necessrios operao do Banco de Dados. Os erros mais comuns so
:
Um dos arquivos do Banco de Dados encontra-se em setor
danificado do disco ou, foi gravado com a cabea de leitura e gravao
da unidade de disco danificada, impossibilitando sua recuperao
Existe um problema de acesso fsico ao disco
Um arquivo foi acidentalmente apagado.

A estratgia de recuperao dos dados ir depender do mtodo de backup
escolhido e de quais arquivos foram afetados. Se for possvel, deve-se aplicar
uma recuperao baseada nos archived redo log files, que devero atualizar os
dados desde o ultimo backup realizado.

Mtodos de Backup

Sistema de Backup sem archiving
Sistema de Backup com archiving
Utilitario EXPORT para Backup



Sistema de Backup

Realiza o backup de data files, redo log files e control file, com ou sem os
achiving redo log files.

Tipos :
Full Offline Database Backup
O Banco de Dados deve ser desativado (instance shutdown)
antes dos comandos de backup.
Full Online Database Backup
Necessita que o Banco de Dados tenha sido iniciado com o modo
de ARCHIVELOG e que todas as tablespaces estejam Online
durante o backup.
Partial Online Tablespace Backup
Necessita que o Banco de Dados tenha sido iniciado com o modo
de ARCHIVELOG e um tipo de backup Online em que so feitos
os backups das tablespaces, menos as que forem especificadas
como exceo.
Partial Offline Tablespace backup
Necessita que a tablespace a ser copiada como backup esteja
Offline, enquanto as demais tablespaces permanecem Online. O
ARCHIVING pode ser usado para este tipo de backup.


Full Offline Database Backup

o backup de todos as tabelas de usurios, redo log files e control files que
constituem o Banco de Dados ORACLE. O arquivo de parametros associado
ao Banco de Dados tambm deve ser copiado pelo backup.
Os passos para realizar o Full Offline Database Backup :
1 - Mantenha uma lista atualizada dos arquivos que devem ser guardados
2 - Desative o Banco de Dados, atravs do comando SHUTDOWN
3 - Copie todas as tabelas, redo log files, control files e o arquivo de
parmetros, usando qualquer utilitario de backup do sistema operacional
4 - Reinicializar o instace ORACLE.

Deve-se criar um arquivo de procedimentos, via sistema operacional, como por
exemplo: BACKUP.BAT, que ir sempre copiar os data files, redo log files,
control files e arquivo de parmetros para uma outra midia magntica, por
exemplo a FITA DAT, facilitando a atividade operacional do backup Offline.
Para saber o nome dos arquivos a serem copiados, utilizam-se as seguintes
views :

Nomes dos data files
- SELECT FILE_NAME FROM DBA_DATA_FILES;

Nomes dos redo log files
- SELECT MEMBER FROM V$LOGFILE;

Nomes dos control files
- SHOW PARAMETER CONTROL_FILES;
ou
- SELECT VALUE FROM V$PARAMETER
WHERE NAME = CONTROL_FILES;

As vantagens para este tipo de backup, so :
Extremamente simples
Facil de se realizar
Necessita de uma baixa interao com o operador
Confiavel.

Pode-se considerar que a nica desvantagem para este tipo de backup seja o
fato de o Banco de Dados ter que estar Offline.

Recuperao sem Archiving

Restaurar o mais recente Full Offline Database Backup em um Banco de
Dados que esta rodando sem o modo de archiving dos redo log files, deve
seguir os seguintes passos :
1 - Desativar o Banco de Dados - SHUTDOWN
3 - Restaurar o backup, atravs de utilitario do sistema operacional.
Recomenda-se tambm neste caso, um arquivo de procedimentos, como
por exemplo : RECUPERA.BAT
4 - Reinicializar o Banco de Dados - STARTUP.


Para restaurar no caso de problemas de midia, deve-se seguir os seguintes
passos :
1 - Desativar o Banco de Dados imediatamente - SHUTDOWN ABORT
2 - Reparar o problema de hardware que causou o erro de midia, se
necessrio
3 - Restaurar o mais recente backup. Todos os arquivos devero ser
retornados e no apenas aqueles que apresentaram problemas.
4 - Reinicializar o Banco de Dados - STARTUP. O seu Banco de Dados
estar com o mesmo estado que se encontrava quando o ultimo backup
foi realizado.


Caso o problema de midia no possa ser reparado, como por exemplo, no
caso do disco no mais for operacional, seguir os seguintes passos :
1 - Determinar um disco alternativo para armazenar os dados do Banco de
Dados
2 - Restaurar todos os arquivos do Banco de Dados para o novo disco
3 - Se necessrio , editar o recm copiado arquivo de parmetros para
indicar a nova localizao do control file
4 - Se algum dos arquivos pertencentes tablespace no puder ser
restaurada em sua localizao original, inicie a instance usando o
arquivo de parmetros, montando-a sem porm, abri-la :

- CONNECT INTERNAL;
- STARTUP MOUNT TESTE;


5 - Alterar a tablespace para renomear os data files :
- ALTER TABLESPACE USER_DATA
RENAME DATAFILE especificao anterior
TO nova especificao;

6 - Abrir o Banco de Dados :
- ALTER DATABASE OPEN;

O uso do NOARCHIVELOG recomendado quando perdas de informaes
entre os backups pode ser tolerada ou facil de ser manualmente aplicada. Este
uso tem como vantagem :
Ser simples de realizar
Ter pequena margem de erro
Ter um minimo tempo de recuperao.

Como desvantagens podemos citar :
Os dados perdidos devero ser recuperados manualmente
Todo o Banco de Dados sera retornado para a situao da data do
backup, mesmo que apenas um unico arquivo tenha sido danificado.

Estruturas Necessrias para a Recuperao

O Banco de Dados ORACLE deve ter um sincronismo entre os data files, log
files e control files. O ORACLE ir aplicar automaticamente, os registros do
redo log, sempre que for necessrio atualizar um arquivo que no se
encontrava up to date, fazendo todas as recuperaes de dados necessrias
para trazer esse arquivo para uma realidade atual.
Sobre a sincronizao de arquivos :
A sincronizao entre todos os arquivos do Banco de Dados
baseada na sequencia numrica do atual redo log
Um arquivo deve estar sincronizado com toda a base de dados
antes de ser aberto
O redo log aplicado para recuperar transaes comitadas at o
ponto do erro
O redo log consiste de archived redo logs files Online ou Offline.

Enquanto o DBA requisitado para restaurar os arquivos de um backup, o
ORACLE automaticamente realiza as fases de rollback e roll-forward da
recuperao.

Fases da Recuperao :

Restaurar os arquivos de backup
Copiar os arquivos do backup mais recente, sobre os arquivos danificados
Processo Roll-Forward
As entradas do redo log so aplicadas nos data files necessrios, no
importando se as transaes foram comitadas ou no.
Processo Rollback
As entradas do rollback segment so utilizadas para desfazer as
alteraes que no foram comitadas ou foram retornadas via roll back.

S aps estas fases de recuperao que os data files podem ser abertos
Online.

Operando um Banco de Dados com ARCHIVING

Usa-se o modo de ARCHIVING para recuperar o mximo possvel de dados
aps um erro de midia e para realizar backups Online.
Para tanto necessrio que :
O Banco de Dados esteja em modo de ARCHIVELOG
O processo secundrio ARCH seja habilitado para implementar
automticamente o ARCHIVING
Recursos suficientes para suportar o armazenamento dos redo log
files.


ARCHIVE MODE

O ARCHIVELOG MODE protege contra erros de midia e instance. Porm, um
Banco de Dados pode rodar com dois modos : ARCHIVELOG e
NOARCHIVELOG. O modo indica quando os redo log files podero ser
reusados.
NOARCHIVELOG MODE :
Redo log files so usados de forma circular
Um redo log file pode ser reusado imediatamente aps um
checkpoint
Uma vez que os redo log files foram regravados, a recuperao
de midia s sera possvel com o ultimo backup full.

Implicaes do NOARCHIVELOG MODE :
Recuperao de erros de instance at o ponto do erro, possvel
Se uma tablespace se torna indisponvel em virtude de erros, no
possivel continuar a operao com o Banco de Dados, at que a
tablespace seja apagada ou todo o Banco de Dados restaurado dos
backups
S possvel backups Offline
Todo o Banco de Dados, redo e control files devem ser copiados em
cada backup.

Opes de recuperao de midia :
Restaurar os dados, log e control files de um full backup mais
recente
Se o utilitario EXPORT foi usado para backup, usar o utilitario
IMPORT para restaurar o ultimo dado.

ARCHIVELOG MODE :
Um redo log file no pode ser reusado enquanto no houver um
checkpoint e os redo log files forem automaticamente copiados pelo
processo ARCH, para o disco
As alteraes mais recentes no Banco de Dados estaro
disponveis a qualquer instante para possiveis recuperaes de
instance e as copias de redo logs antigos podem ser usados no
caso de erro de midia.

Implicaes do ARCHIVELOG MODE
O Banco de Dados estar protegido de erros de instance
O Banco de Dados estar protegido de erros de midia
O Banco de Dados poder ter seu backup feito estando Online
ALTER TABLESPACE BEGIN / END BACKUP
Quando uma tablespace, que no a SYSTEM, fica Offline devido a
erros de midia, o restante do Banco de Dados permanece disponvel
uma vez que o dado relacionado tablespace Offline que estar no
redo log no ser perdido quando o redo log for reusado
Um numero grande de redo log files pode ser necessrio para
garantir que o arquivamento Online de redo log files possa ocorrer
antes deles precisarem ser reusados.

Opes de recuperao de midia :
Restaurar uma copia backup de arquivos danificados usando
archived log files para trazer os dados up-to-date com o Banco de
Dados Online ou Offline.
Restaurar o Banco de Dados at um ponto de tempo especfico
Restaurar o Banco de Dados at o fim de um archived log file
especfico
Restaurar o Banco de Dados at um system commit number (SCN).

Usa-se o comando SQL*DBA / Server Manager ARCHIVE LOG LIST para
verificar o estado atual do archiving para o Banco de Dados.
Exemplo :

- ARCHIVE LOG LIST

Database log mode ARCHIVELOG
Automatic archival ENABLED
Archive destination ORA:ORACLE\ARCH
Oldest online log sequence 278
Next log sequence to archive 279
Current log sequence 279

Onde :

Database log mode
Modo corrente de arquivamento
Automatic archival
Status do processo opcional ARCHIVE
Archive destination
Destino aonde os log files sero copiados
Oldest online log sequence
Sequencia anterior do log Online
Next log sequence to archive
Prxima sequencia do log Online
Current log sequence
Sequencia atual do log Online

Cada vez que um redo log file reusado, ele ser assinalado com o prximo
nmero da sequncia.
A especificao de ARCHIVELOG MODE ou NOARCHIVELOG MODE pode
ser feita na criao do Banco de Dados :

CREATE DATABASE nome
CONTROLFILE REUSE
LOGFILE [GROUP numero] especificao
MAXLOGFILES numero
MAXLOGMEMBERS numero
MAXLOGHISTORY numero
DATAFILE especificao
MAXDATAFILES numero
MAXINSTANCES numero
ARCHIVELOG/NOARCHIVELOG
EXCLUSIVE

Exemplo :

CREATE DATABASE TESTE
DATAFILE ORA:PROD\RDBMS\SYSTEM.DBS SIZE 5M
LOGFILE GROUP 1 ORA:PROD\LOGS\LOG1A.RDO SIZE 500K,
GROUP 2 ORA:PROD\LOGS\LOG2A.RDO SIZE
500K
ARCHIVELOG;

CREATE DATABASE TESTE
DATAFILE ORA:PROD\RDBMS\SYSTEM.DBS SIZE 5M
LOGFILE GROUP 1 ORA:PROD\LOGS\LOG1A.RDO SIZE 500K,
GROUP 2 ORA:PROD\LOGS\LOG2A.RDO SIZE
500K
NOARCHIVELOG;

Pode-se ainda, alterar o tipo de arquivamento de um Banco de Dados, Online,
usando-se o comando :

ALTER DATABASE nome ARCHIVELOG / NOARCHIVELOG


OBS.: DEVE-SE HABILITAR O PROCESSO ARCH COMO TRUE NO
ARQUIVO INIT.ORA, NO PARMETRO :
- LOG_ACHIVE_START = TRUE
ASSIM O PROCESSO DE GRAVAO SERA SEMPRE AUTOMTICO

CASO SE QUEIRA HABILITA-LO MANUALMENTE, SEMPRE QUE SE
INICIAR O BANCO, USA-SE O COMANDO :
- ALTER SYSTEM ARCHIVE LOG START TO destino;

Exemplo da sequencia de passos para se alterar o tipo de arquivamento :

CONNECT INTERNAL
STARTUP MOUNT
- Deve-se ter a certeza de que o Banco esta montado mas no
aberto
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

O archive log file ser criado no destino especificado no arquivo de parmetros
- INIT.ORA, no parmetro LOG_ARCHIVE_DEST e LOG_ARCHIVE_FORMAT,
ou no destino indicado no comando ALTER SYSTEM. Cada log file criado sera
associado a um numero sequencial unico.



OBS.: PARA SE DESABILITAR O PROCESSO ARCH NO ARQUIVO
INIT.ORA :
- LOG_ACHIVE_START = FALSE
ASSIM O PROCESSO DE GRAVAO NO SERA AUTOMATICO

CASO SE QUEIRA DESABILITA-LO MANUALMENTE, SEMPRE QUE SE
INICIAR O BANCO, USA-SE O COMANDO :
- ALTER SYSTEM ARCHIVE LOG STOP;


Backup Online Parcial

Um backup parcial realizado enquanto o Banco de Dados estiver aberto ou
fechado. No caso do backup parcial Online, ser feito um backup de uma
tablespace Online.
Passos a seguir :
Assegurar-se que o Banco de Dados esta rodando com o
ARCHIVELOG MODE
Pode-se usar a seguinte querry : SELECT LOG_MODE FROM
V$DATABASE
Determinar que tipo de arquivos sero copiados :
Data files pertencentes a uma unica tablespace
Control files
Pode-se usar a view DBA_DATA_FILES para listar os nomes
dos data files de cada tablespace.
Para os nomes de control files, pode-se obter atravs do
arquivo de parametros.
Realizar o backup Online ou Offline da tablespace
Backup parcial Online da tablespace :

- ALTER TABLESPACE nome BEGIN / END BACKUP
Onde
BEGIN :
Significa que um backup Online ser iniciado, copiando
todos data files da tablespace. Durante o backup, no
sera possvel utilizar a tablespace, as transaes que
envolvam esta tablespace sero gravadas no redo log e
aps o trmino do backup, sera feita a recuperao
automtica das transaes.

END :
Significa que o backup Online da tablespace esta
terminado.

Exemplo dos passos a serem seguidos no backup partial Online da tablespace
USER_DATA :

ALTER TABLESPACE USER_DATA BEGIN BACKUP;

UTILIZAR UM UTILITARIO PARA BACKUP DO SISTEMA
OPERACIONAL
PARA COPIAR TODOS OS DATA FILES DA TABLESPACE. PODE-SE
USAR UM ARQUIVO DE PROCEDIMENTOS (.BAT) PARA FACILITAR
A TAREFA

ALTER TABLESPACE USER_DATA END BACKUP;

Backup Online dos Control Files

Recomenda-se o backup constante do Control File (varias copias em lugares
diferentes), pois o control file ser usado sempre que uma instance for iniciada,
ou seja, sempre que se for usar o Banco de Dados. Perder esse arquivo
significa perder todo o Banco de Dados. Varias informaes do control file,
como por exemplo o nome do corrente redo log online, os nomes das tabelas,
etc...), so usadas pelo ORACLE durante uma recuperao de instance ou
midia. necessrio manter uma copia recente do control file, aps cada
mudana de sua configurao.

Comandos que mudam a configurao de um control file :

- ALTER DATABASE ADD LOGFILE
- ALTER DATABASE ADD LOGFILE MEMBER
- ALTER DATABASE RENAME FILE
- ALTER DATABASE DROP LOGFILE GROUP
- ALTER DATABASE DROP LOGFILE MEMBER
- CREATE TABLESPACE
- ALTER TABLESPACE ADD DATAFILE
- ALTER TABLESPACE RENAME DATAFILE
- DROP TABLESPACE

Escolha o melhor mtodo de manter uma cpia recente do control file :

Manter multiplas cpias de control files e nomea-los no arquivo de
parmetros INIT.ORA, parmetro CONTROL_FILES
Durante um full backup, dar shutdown na instance e usar um
utilitrio de backup do sistema operacional para copiar o control file
para a fita de backup
Durante um backup parcial, usar o comando ALTER DATABASE :
ALTER DATABASE BACKUP CONTROLFILE TO
destino;
* - Recomenda-se o uso constante deste tipo de backup do control
file.

Backup Offline Parcial

Para realizar o backup Offline de uma tablespace, quando for possivel
suspender temporariamente o seu uso pelas aplicaes.
Passos a seguir :
Deixar a tablespace Offline
Copiar os data files para a area de armazenamento de backup,
usualmente a FITA DAT.
OBS.:
Para se tirar um backup de todos os data files, inclusive aqueles pertencentes a
tablespace SYSTEM e qualquer tablespace de rollback segments Online e, os
control files sem que seja necessrio deixar o Banco de Dados Offline,
executa-se os seguintes passos :
1 - Certfique-se que o Banco de Dados esta rodando com a opo de
ARCHIVELOG MODE
2 - Realize os passos referentes ao backup Online parcial para cada
tablespace.
3 - Realize os passos referentes ao backup Online dos control files.

Recuperao de todas as transaes aps um erro de Midia

Archived Log Files permitem ao Banco de Dados, recuperar todas as
transaes comitadas, at o ponto em que ocorreu o erro.
Possiveis opes de Recuperao :
Recuperao do Banco de Dados Offline full (full offline database
recovery)
Recuperao de tablespace parcial Online ou Offline
Recuperao baseada em perodos (time based recovery)
Recuperao baseada em mudanas (change based recovery).

A recuperao no sera terminada at que todos os data files, control files e log
files sejam sincronizados com o mesmo nmero de sequncia do log.
Recuperao :
1 - SHUTDOWN no Banco de Dados

SQLDBA> SHUTDOWN
Database closed.
Database dismounted.
ORACLE instance shut down.

2 - Restaurar o mais recente backup dos arquivos danificados
3 - Montar o Banco de Dados

SQLDBA> CONNECT INTERNAL
Connected.
SQLDBA> STARTUP MOUNT PFILE=arquivo de parametros EXCLUSIVE
ORACLE instance started.
Database mounted.

4 - Recuperar os data files. Ser solicitado que se digite o nome do primeiro
archive file necessrio recuperao. Digite sua localizao e nome caso o
arquivo no esteja na localizao default.

SQLDBA> ALTER DATABASE RECOVER;
Statement processed.

5 - Aps a recuperao estar completa, abrir o Banco de Dados.


SQLDBA> ALTER DATABASE OPEN;
Statement processed.

Durante todo o processo de recuperao, o Banco de Dados no estar
disponvel aos usurios. No exemplo acima, a clausula EXCLUSIVE s ser
necessria para sistemas multi-instance, sendo assumido implicitamente no
caso de uma unica instance. A localizao default dos archived files estar
definida pelos parmetros LOG_ARCHIVE_DEST e LOG_ARCHIVE_FORMAT
do arquivo de parmetros.




ANTES DA Redo Log Redo Log Redo Log
RECUPERAO 27 15 18



Control Files DB File 1 DB File 2



DEPOIS DA Redo Log Redo Log Redo Log
RECUPERAO 27 27 27



O Banco de Dados ser recuperado at a ultima transao definida no control
file. O control file contm o nmero de sequncia do redo log file corrente.
Cada header de arquivo do Banco Dados contm o nmero de sequncia do
redo log imediatamente anterior, a ser aplicado.

Recuperando um Redo Log File Online

Quando um redo log Online sofre um erro de midia, o ORACLE ir parar com
um erro de operao. Para recuperar um redo log :
NOARCHIVELOG MODE
Restaurar o backup mais recente de todo o Banco de Dados
(gerado por um Offline full backup de todos os arquivos do Banco de
Dados)
ou
Criar um novo Banco de Dados (CREATE DATABASE) e realizar
uma importao total dos arquivos.

ARCHIVELOG MODE
Restaurar o Banco de Dados manualmente, at o ultimo redo log
sem problemas de leitura

Recuperando um Control File

Em geral, gravaes, protees e recuperaes de control files so
automticas. Para tanto basta apenas, especificar multiplos control files em
diferentes discos.

Erros na inicializao de uma instance so, usualmente, resultados de erros no
control file. Neste caso, onde apenas o control file apresenta problemas, basta
uma cpia de um control file atualizado, de uma rea de backup para a rea
de produo.

Passos para uma cpia de control file, com nome diferente do atual :
1 - SHUTDOWN na instance
2 - Copiar um control file sem erros, com um novo nome
3 - Editar o arquivo de parmetros, trocando o nome do control file anterior
pelo novo nome do control file
4 - Reiniciar a instance.

Se todos os control files esto danificados, todo o Banco de Dados deve ser
restaurado :

NOARCHIVELOG MODE
Restaurar o backup mais recente de todo o Banco de Dados
(gerado por um full backup de todos os arquivos do Banco de
Dados, redo log files e control files.
ou
Criar um novo Banco de Dados (CREATE DATABASE) e realizar
uma importao total dos arquivos.

ARCHIVELOG MODE
Restaurar manualmente, todo Banco de Dados, usando um
backup do control file.


EXPORT / IMPORT - Backup Lgico

Arquiva e recupera dados do ORACLE, usando arquivos do sistema, com o
utilitrio EXPORT e o utilitrio IMPORT.
Uso :
Salvar definies de tabelas e dados de um determinado espao de
tempo
Salvar definies de tabelas com ou sem os dados, Offline, para
uma posterior regravao das mesmas no Banco de Dados
Copiar dados do ORACLE de uma CPU para outra
Copiar dados de uma verso do ORACLE para outra
Previnir-se para futuras recuperaes de tabelas, permitindo que a
restaurao seja realizada sem a necessidade de se dar roll back em
todo o Banco de Dados
Reorganizar as tabelas, eliminando as fragmentaes.

EXPORT

Usado para copiar Dados do Banco de Dados em um arquivo padro do
sistema operacional, que somente poder ser lido e interpretado pelo utilitrio
IMPORT.
O utilitrio permite um dilogo interativo durante sua operao :


SQLDBA> EXPORT
Export ; version 7.0.x - Production on Fri May dd hh:mm:ss yyyy
Copyright @ Oracle Corporation 1979, 1992. All rights reserved.
Username : system/manager
Connected to : ORACLE RDBMS V7.0.x, transaction processing option
Enter array fetch buffer size : 4096 > (RETURN)
Export file : ser apresentado um nome default > (RETURN)
E(ntire database) , U(sers) , or T(ables) : U > T * opo de copia de tabelas *
Export table data (Y/N) : Y > Y
Compress extents (Y/N) : Y > N
About to export specified tables ...
Table to be exported : (RETURN to quit) >
Export terminated successfully without warnings

Modo de exportao :
Table :
Exporta as tabelas especficas pertencentes ao usurio :
Definies da tabela
Dados da tabela
Os GRANTS do proprietrio das tabelas
Os indices criados pelo proprietrio das tabelas
Os constraints das tabelas
Os triggers das tabelas

User :
Exporta todos os objetos pertencentes ao usurio :
Definies da tabela
Dados da tabela
Os GRANTS do proprietrio
Os indices criados pelo proprietrio
Os constraints das tabelas
Os triggers das tabelas
Clusters
Database Links
Sequncias
Snapshots
Snapshots Logs
Procedures
Sinnimos privados
Views

Full Database :
Exporta todos os objetos do Banco de Dados :
Definies da tabela
Dados da tabela
Os GRANTS
Os indices
Os constraints das tabelas
Os triggers das tabelas
Clusters
Database Links
Sequencias
Snapshots
Snapshots Logs
Procedures
Sinonimos privados
Views
Profiles
Roles
Definies da rollback segment
Opes de audit do sistema
Privilgios do sistema
Definies de tablespace
Definies de quotas de tablespace e definies de usurios.

Todos os usurios podem optar entre exportao de tabelas ou usurios (table,
user). Porm, apenas os usurios com o privilgio EXP_FULL_DATABASE
podem exportar todo o Banco de Dados (database).
O utilitrio export pode ser rodado tambm, atravs de uma linha de comando,
seguido de varios argumentos, como por exemplo :

- EXP SCOTT/TIGER GRANTS=Y TABLES=(EMP, DEPT,).

Os argumentos possveis so :
Argumento Valor default Descrio

USERID Indefinido Usurio e senha
BUFFER Depende do sistema Tamanho do buffer de dados
FILE EXPDAT.DMP Arquivo de sada
COMPRESS Y Compresso das extenses
GRANTS Y Exporta os privilgios
ROWS Y Exporta os dados das linhas
FULL N Exporta toda a base de dados
OWNER Indefinido Usurio a ser exportado
TABLES Indefinido Tabelas a serem exportadas
INDEXES Y Exportar as definies de indices
CONSTRAINTS Y Exporta as constraints das tabelas
RECORDLENGHT Depende do sistema Tamanho em bytes do registro
INCTYPE Indefinido Tipo da exportao :
COMPLETE :
- Todas as definies e dados das
tabelas

INCREMENTAL :
- Somente os objetos que tiveram
alguma alterao desde a data da
ultima exportao de qualquer tipo.

CUMULATIVE :
- Todas as tabelas que tiveram
alteraes desde de a ultima
exportao cumulative ou full .

RECORD Y Registro no SYS.INCVID,
SYS.INCFIL e SYS.INCEXP.
(deixar sempre Y)
PARFILE Indefinido Arquivo de especificao de
parmetros
para automatizar o export
HELP N Mostrar os parmetros de
exportao
LOG Indefinido Arquivo para informao de erros e
menssagens
CONSISTENT N Uma viso (view) read-consistent da
base de dados quando o dado
for
alterado durante uma exportao.

Para efeito de backups de segurana, recomenda-se o seguinte esquema de
exportao de dados :
Mensalmente, export do tipo COMPLETE,
Diariamente, export do tipo INCREMENTAL,
Semanalmente, export do tipo CUMULATIVE.

Em qualquer uma das tres opes, toda a tabela sera exportada e no apenas
os registros alterados.
As informaes relativas aos tipos de exportao INCREMENTAL e
CUMULATIVE , so incluidas em tabelas pertencentes ao usurio SYS.
O script CATEXP.SQL cria as tabelas SYS.INCEXP e SYS.INCFIL, que
suportam as exportaes do tipo INCREMENTAL.
IMPORT

Utilitrio usado para carregar dados exportados para arquivos do sistema pelo
utilitrio export. So necessrios alguns privilgios para se importar dados,
como por exemplo :

Objeto Tipo do privilgio Privilgio necessrio

Definio de tabela System CREATE TABLE
TABLESPACE QUOTA ou
UNLIMITED
TABLESPACE
Dados da tabela Object INSERT TABLE
Constraints de tabelas Object ALTER TABLE.

OBS.: Todos estes privilgios pertencem role RESOURCE.
Quando se importa uma tabela, o arquivo de exportao lido e a tabela e os
dados so criados obedecendo a seguinte ordem :
1 - Novas tabelas so criadas
2 - Os dados so importados
3 - Os indices so criados
4 - Os triggers so importados e as constraints de integridade so habilitadas
para as novas tabelas.

A ordem em que as tabelas so importadas pode ser importante. Por exemplo:
se uma tabela com chave estrangeira (foreign key) tem uma integridade
referencial com a chave primria (primary key) de uma outra tabela e, a tabela
de chave estrangeira for importada primeiro, ento, todas as linhas que
referenciam a chave primria, que no foram importadas ainda, sero
rejeitadas se o constraint for habilitado.
Tela do utilitrio IMPORT, no modo interativo

IMP SYSTEM/MANAGER
Import : Version 7.0 - Production on Ddd Mmm nn tt:tt:tt yyyy
Copyright @ Oracle Corporation 1979, 19xx. All rights reserved.

Connected to : ORACLE V7.0 - Production

Import File : EXPDAT.DMP > dba.dmp
Enter insert buffer size (minimum is 4096) : 10240 > (RETURN)
Export created by ORACLE version EXPORT:V7.0

List contents of import file only (Y/N) : N > (RETURN)
Ignore create errors due to object existence (Y/N) : Y > (RETURN)
Import grants (Y/N) : Y > (RETURN)
Import table data (Y/N) : Y > (RETURN)
Import entire export file (Y/N) : Y > N
Username : JOHN
Enter table names . Null list means all tables for user
Enter table name or . if done : PLACES
Enter table name or . if done : .
. importing JOHNs objects into JOHN
.. importing table PLACES 50 rows imported
...
. Username : JOE
. Enter table names . Null list means all tables for user
. Enter table name or . if done : PEOPLE
. Enter table name or . if done : THINGS
. Enter table name or . if done : .
. importing JOEs objects into JOE
.. importing table PEOPLE 100 rows imported
.. importing table THINGS 666 rows imported
...

O utilitrio import pode ser rodado tambm, atravs de uma linha de comando,
seguido de varios argumentos :
Argumento Valor default Descrio

USERID OPP$ Usurio e senha
BUFFER 4096 Tamanho do buffer de dados
FILE EXPDAT.DMP Arquivo de sada
SHOW N Lista somente o contedo
GRANTS N Importa os privilgios
ROWS Y Importa os dados das linhas
IGNORE Y Ignora erros de criao de objetos
existentes
FULL N Importa toda a base de dados
TABLES Indefinido Tabelas a serem importadas
INDEXES Y Importa as definies de indices
COMMIT N COMMIT aps cada insero na
tabela
RECORDLENGHT Depende do sistema Tamanho em bytes do registro
PARFILE Indefinido Arquivo de especificao de
parmetros
TOUSER Indefinido Lista de usurios para onde o dado
ser
importado
FROMUSER Indefinido Lista de usurios de onde os objetos
sero importados
HELP Y Mostrar os parmetros de
importao
INDEXFILE Indefinido Nome dos arquivos para salvar as
definies de indices
INCTYPE Indefinido Tipo da importao :
RESTORE / SYSTEM

Exemplo de restaurao do dia 19 :

1 - Criar um novo Banco de Dados
2 - Importar o mais recente arquivo exportado, controlados nas tabelas
SYS.INCVID, SYS.INCEXP e SYS.INCFIL

- IMP SYSTEM/MANAGER INCTYPE=SYSTEM FULL=Y FILE=DAY_19.DMP

3 - Importar o arquivo de exportao COMPLETE mais recente
- IMP SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y FILE=DAY_01.DMP

4 - Importar todos os arquivos de exportao CUMULATIVE aps o ultimo
export complete

- IMP SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y FILE=DAY_08.DMP
........
- IMP SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y FILE=DAY_15.DMP

5 - Importar todos os arquivos de exportao INCEMENTAL aps o ultimo
export cumulative

- IMP SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y FILE=DAY_16.DMP
........
- IMP SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y FILE=DAY_17.DMP
........
- IMP SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y FILE=DAY_18.DMP
........
- IMP SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y FILE=DAY_19.DMP

SISTEMA GERENCIADOR DE BANCO DE DADOS ORACLE
DBA - ADMINISTRAO DO BANCO DE DADOS

6 - Criao e Gerenciamento de Usurios
























O controle de acesso ao Banco de Dados ORACLE, feito atravs da criao,
alterao, deleo e monitorao dos usurios.
Um controle bsico, engloba :
Criao de nomes de usurios vlidos e suas senhas
Autorizar o usurio a se conectar ao Banco de Dados
Limitar o uso de espao em disco para cada usurio.

Gerencia-se a segurana no Banco de Dados, criando-se usurios e
associando-os a tarefas especficas, com seus respectivos nveis de acesso.
Cada Database ORACLE tem uma lista vlida de usurios, identificados por
seus usernames. Um username :
Necessrio para acessar o Banco de Dados
Fornecido para cada aplicao no Banco de Dados
novos
usurios
DBA
ORACLE
Usurio e senha
Privilgios de acesso
Cotas de uso de espao

Definido no Banco de Dados.

Quando um usurio do Banco de Dados criado, uma tarefa (schema)
correspondente, com o mesmo nome, criada para o usurio.
O controle de acesso dos usurios dividido em grupos (domain settings).
Uma senha criada para cada username e pode ser modificada mais tarde,
pelo usurio. O ORACLE armazena os usernames e criptografa as senhas. A
validao do usurio e senha feita sempre que o usurio se connectar ao
Banco de Dados.
Validaes feitas pelo Banco de Dados, especificadas na criao do usurio
(operating system authentication $OPS) :

Especificao Descrio

Default Tablespace Especifica em que tablespace sero criados os
objetos
do usurio, caso no seja especificada a tablespace
no
comando CREATE TABLE, CREATE INDEX ou
CREATE CLUSTER

Temporary Tablespace Especifica a tablespace que ser usada para
armazenar
dados temporarios, durante a execuo de sort de
comandos SQL

Tablespace Quotas Determina o tamanho mximo do espao da
tablespace
que pode ser usado pelo usurio

System Resource Limits Indica o tempo de uso da CPU, o numero de
leituras
lgicas, o numero de sesses concorrentes por
usurio
e um tempo de timeout (idle time) para a sesso,
especificados atravs de profiles.

Criao de usurio

Comando para criao de usurio :

CREATE SER username
IDENTIFIED BY senha
DEFAULT TABLESPACE nome da tablespace
TEMPORARY TABLESPACE nome da tablespace
PROFILE nome do profile
QUOTA numero inteiro / UNLIMITED ON nome da
tablespace

Onde :

username : Nome do usurio
senha : Senha do usurio
nome da tablespace : Nome da tablespace usada para default ou temporaria
nome do profile : Nome do arquivo profile com os dados de system
resource
limits
numero inteiro : Numero de bytes : tamanho maximos que pode ser
usado da
tablespace pelo usurio
UNLIMITED : Permite o usurio usar todo o espao disponvel da
tablespace.

Exemplo de criao de usurio chamado PAT, com a senha BARCOLENTO, usando a
tablespace APP_TS, com uma quota de 15 Mbytes, tendo como tablespace temporaria a
TEMP_TS e, especificando um profile default :

CREATE USER PAT
IDENTIFIED BY BARCOLENTO
DEFAULT TABLESPACE APP_TS
TEMPORARY TABLESPACE TEMP_TS
QUOTA 15M ON APP_TS
PROFILE DEFAULT;

Dois nomes de usurios so reservados para o ORACLE : SYS e SYSTEM.
Por default, um usurio no pode ter acesso a qualquer tablespace do Banco
de Dados. Para permitir a criao de extenses em uma tablespace, dever-se
fornecer uma quota de uso desta tablespace ao usurio. Estas quotas podero
ser modificadas caso necessrio.

Checklist para criao de usurios :

1 - Definir um username e uma senha para o usurio ORACLE

2 - Definir uma tablespace default para a criao de objetos deste usurio

3 - Definir uma tablespace temporaria para ser usada por comandos SQL deste usurio

4 - Identificar quais tablespaces o usurio ir necessitar para armazenar objetos

5 - Definir uma quota de uso para cada tablespace, ou uso ilimitado


Alterao de Usurio

Para modificar os parmetros de um usurio existente no Banco de dados.
Pode-se modificar :
Senha
Validaes (operating system authentication - $OPS)
Default tablespace
Temporary tablespace
Quota por tablespace
Profile
Role - grupo de privilgios.

Comando :
ALTER USER username
IDENTIFIED BY senha
DEFAULT TABLESPACE nome da tablespace
TEMPORARY TABLESPACE nome da tablespace
QUOTA numero inteiro / UNLIMITED ON nome da tablespace
PROFILE nome do profile
DEFAULT ROLE nome da role
ALL [EXCEPT nome da role]
NONE

Onde :

DEFAULT ROLE : Estabelece a role a que o usurio pertence

Exemplo de alterao de senha e de tablespace default para o usurio PAT :

ALTER USER PAT
IDENTIFIED BY QUEMSOUEU
DEFAULT TABLESPACE DATA_TS
QUOTA 10M ON DATA_TS;

Apagar um Usurio

Para excluir um usurio do Banco de Dados.
Comando :

DROP USER username CASCADE;

Onde :

CASCADE : Apaga todos os objetos do usurio antes de deletar o usurio.

A opo CASCADE usada muito raramente. O uso dessa opo faz com que
todos os objetos criados por este usurio sejam imediatamente apagados do
Banco de Dados. Consequentemente, tabelas criadas por este usurio que so
utilizadas tambm por outras aplicaes de outros usurios, deixariam de
existir, causando erros e danificando sistemas.
Um usurio que esta connectado ao Banco de Dados, no pode ser apagado.

Exemplo :
DROP USER PAT CASCADE;

Monitorao de Usurios

possivel atravs do uso de views do Dicionrio de Dados, que contm
informaes sobre cada username.
So informaes de :
Todos os usurios do Banco de Dados
Tablespace default das tabelas, clusters e indices para cada usurio
Tablespace usada como temporaria para cada usurio
Quotas de cada usurio.

So as views :
USER_USERS
ALL_USERS
DBA_USERS
USER_TS_QUOTAS
DBA_TS_QUOTAS.

Informaes sobre o usurio corrente so obtidas pela view USER_USERS :
- USERNAME : Nome do Usurio
- USER_ID : Numero de identificao do usurio
- DEFAULT_TABLESPACE : Tablespace de dados default
- TEMPORARY_TABLESPACE : Tablespace para informaes temporarias
- CREATED : Data de criao do usurio.

Informaes sobre todos os usurios do Banco de Dados so obtidas pela
view ALL_USERS :
- USERNAME : Nome do Usurio
- USER_ID : Numero de identificao do usurio
- CREATED : Data de criao do usurio.

Informaes sobre todos os usurios do Banco de Dados tambm podem ser
obtidas pela view DBA_USERS :
- USERNAME : Nome do Usurio
- USER_ID : Numero de identificao do usurio
- PASSWORD : Senha criptografada
- DEFAULT_TABLESPACE : Tablespace de dados default
- TEMPORARY_TABLESPACE : Tablespace para informaes temporarias
- CREATED : Data de criao do usurio
- PROFILE : Nome do arquivo profile do usurio.

As quotas de tablespace para o usurio corrente pode ser vista atravs da view
USER_TS_QUOTAS :
- TABLESPACE_NAME : Nome da tablespace
- BYTES : Numero de bytes usados pelo usurio
- MAX_BYTES : Quota em bytes ou UNLIMITED (-1)
- BLOCKS : Numero de blocos usados pelo usurio
- MAX_BLOCKS : Numero maximo da quota em blocos ou
UNLIMITED (-1).
As quotas de tablespace para todos os usurios do Banco de Dados pode ser
vista atravs da view DBA_TS_QUOTAS:
- TABLESPACE_NAME : Nome da tablespace
- USERNAME : Nome do usurio
- BYTES : Numero de bytes usados pelo usurio
- MAX_BYTES : Quota em bytes ou UNLIMITED (-1)
- BLOCKS : Numero de blocos usados pelo usurio
- MAX_BLOCKS : Numero maximo da quota em blocos ou
UNLIMITED (-1).

Interromper uma Sesso do usurio - KILL

Quando necessrio, pode-se terminar uma sesso do usurio que esta logado
no Banco de Dados, para liberar recursos urgentes que se encontram presos
por este usurio ou, no caso de ser necessrio um SHUTDOWN.
Comando :

ALTER SYSTEM
KILL SESSION inteiro 1, inteiro2

Onde :

KILL SESSION : Termina a sesso
inteiro 1 : Especifica a identificao do usurio SID
inteiro 2 : Especifica o numero serial do usurio.

Os efeitos causados pelo KILL SESSION so :
Rolling back da transao corrente do usurio
Libera todos os locks de linhas e tabelas usados pelo processo
cancelado
Libera todos os recursos reservados pelo processo cancelado.

Para identificar o SID e o nmero serial do usurio, usa-se a view virtual
V$SESSION.
Exemplo :

SELECT SID,SERIAL#, USERNAME
FROM V$SESSION;

SID SERIAL# USERNAME
----- ------------- -----------------
13 9 SCOTT

ALTER SYSTEM
KILL SESSION 13, 9 ;


SISTEMA GERENCIADOR DE BANCO DE DADOS ORACLE
DBA - ADMINISTRAO DO BANCO DE DADOS

7 - Controle dos Privilgios do Banco de Dados


Os privilgios so as permisses concedidas aos usurios, para a execuo de
determinadas tarefas no Banco de Dados. Fazem parte do sistema de
segurana de acesso do Banco de Dados.
Controle de Privilgios do DBA :
Determinar os direitos dos usurios conforme o tipo de operao
Habilitar e restringir o acesso para alteraes nas bases de dados
Habilitar e restringir a realizao de funes do sistema e alteraes
nas estruturas das bases de dados
GRANT de privilgios a usuarios individuais e roles
GRANT de privilgios a todos os usurios (PUBLIC).

Tipo do Privilgio Descrio

SYSTEM Um privilgio ou direito de realizar uma ao em
particular,
ou realizar uma ao particular em um tipo de objeto em
particular

OBJECT Um privilgio ou direito de realizar uma ao particular
em
uma tabela, view, sequence, procedure, function ou
package
especificos.

Para uma melhor administrao dos privilgios, devem ser criadas ROLES.
ROLES so grupos de privilgios aos quais se podem dar nomes, associando
depois, esses nomes aos usurios, o que ir fazer com que os usurios
pertencentes s roles, tenham os mesmos privilgios a elas associadas.
As roles :
Reduzem o trabalho de GRANT nos usurios
Tornam o gerenciamento destes privilgios mais gil e dinmico
Pode selecionar grupos de privilgios
Permitem uma aplicao de privilgios mais consciente.

Previlgio SYSTEM

Permite ao usurio, realizar uma operao em particular ou classes de
operaes, como :
Criar tabelas em seu prprio schema (rea de trabalho)
Criar uma sequencia em seu prprio schema
Criar tabelas em qualquer schema
Alterar linhas de qualquer tabela em qualquer schema
Criar usurios
Criar uma sesso (connect).

Existem mais de 80 privilgios distintos do tipo SYSTEM. Cada um deles
permite realizar uma operao em particular ou classes de operaes. So
alguns deles :

Privilgio Comando Operaes Permitidas

SESSION CREATE SESSION Permite conectar-se ao Banco de Dados

TABLE CREATE TABLE Permite criar tabelas em seu prprio
schema, assim como criar indices em
tabelas. Observe que o usurio ir ter o
direito de alocar blocos na tablespace,
assim como o direito de CONNECT,
DML, DROP, ALTER, TRUNCATE

TABLE SELECT
ANY TABLE Permite consulta a qualquer tabela,
view ou snapshot em qualquer schema.


Comando GRANT

O comando GRANT permite fornecer privilgios a usurios ou roles :

GRANT system_priv TO user
role role
public
WITH ADMIN OPTION

Onde :

system_priv : o privilgio tipo system a ser consedido
role : o nome da role cujos privilgios sero concedidos
TO : identifica quem ir receber o privilgio, que podera ser um
usurio, uma role ou ainda publico (PUBLIC), que significa
que o privilgio concedido ser para todos os usurios.
WITH ADMIN
OPTION : Permite que o recebedor do privilgio possa repassa-lo a
outros usurios ou roles.
Exemplos :
GRANT CREATE SESSION, CREATE TABLE TO SCOTT;

GRANT ALTER ANY TABLE TO SCOTT;

GRANT CREATE USER, ALTER USER, DROP USER TO SCOTT
WITH ADMIN OPTION;

Para saber a lista de system privileges concedido a roles e usurios, deve-se
consultar a view SYS.DBA_SYS_PRIVS.
Exemplo :

SELECT * FROM SYS.DBA_SYS_PRIVS
ORDER BY GRANTEE_NAME, PRIVILEGE;

GRANTEE_NAME PRIVILEGE ADM
-------------------------------- ------------------------------------ --------
OPS$DBATRAIN07 CREATE SESSION NO
RESOURCE CREATE CLUSTER NO
RESOURCE CREATE PROCEDURE NO
RESOURCE CREATE SEQUENCE NO
RESOURCE CREATE TABLE NO
RESOURCE CREATE TRIGGER NO
RON CREATE SESSION NO
SCOTT CREATE SESSION NO
SCOTT CREATE SYNONYN NO
SCOTT CREATE TABLE NO
SCOTT CREATE VIEW NO
SUE CREATE SESSION NO
SUE CREATE SYNONYN NO
SUE CREATE TABLE NO
SUE CREATE VIEW NO
SYS UNLIMITED TABLESPACE NO
SYSTEM UNLIMITED TABLESPACE NO


Comando REVOKE

O comando REVOKE, retira os privilgios concedidos ao usurio ou role.

REVOKE system_priv FROM user
role role
public

Onde :
system_priv : o privilgio tipo system a ser retirado
role : o nome da role cujos privilgios sero retirados
FROM : identifica quem ficar sem o privilgio, que podera ser um
usurio, uma role ou ainda publico (PUBLIC), que
significa
que o privilgio ser retirado de todos os usurios.

A especificao de WITH ADMIN OPTION no ser necessria quando se
retira um privilgio do usurio. Se a opo foi incluida no comando GRANT, ela
ser automticamente incluida no comando REVOKE.

Privilgio OBJECT

Permite ao usurio, realizar uma ao em particular, em uma tabela, view,
sequence ou procedure, especifica. Os tipos de privilgios OBJECT (objeto),
variam de objeto para objeto.
Tipos :

Privilgio Tabela View Sequence Procedure
Snapshot

ALTER X X
DELETE X X
EXECUTE X
INDEX X*
INSERT X X
REFERENCES X*
SELECT X X X X
UPDATE X X

* - Estes privilgios no podem ser concedidos a roles

Diferentes privilgios, permitem o uso de comandos SQL especficos :

Privilgio Comandos Permitidos

SELECT SELECT...FROM Tabela, View, Snapshot
Permitido tambm o uso de Sequence

UPDATE UPDATE Tabela ou View

INSERT INSERT INTO Tabela e View

ALTER ALTER Tabela ou Sequencia
CREATE TRIGGER ON Tabela

DELETE DELETE FROM Tabela ou View
TRUNCATE Tabela

EXECUTE EXECUTE Procedure ou Function
Referenciando a variaveis publicas em packges

INDEX CREATE INDEX ON Tabela

REFERENCES CREATE ou ALTER TABLE definindo uma constratint
de integridade referencial de FOREIGN KEY em Tabelas.

Comando GRANT

Comando :

GRANT object_priv [column]
ON [schema] objeto TO user
role
PUBLIC
WITH GRANT OPTION

Onde :

object_priv : o privilgio tipo object, a ser concedido
column : especifica a tabela ou view sobre a qual o
privilgio ser concedido
ON : especifica o objeto sobre o qual o privilgio ser
concedido
TO : identifica quem ir receber o privilgio, que podera ser
um
usurio, uma role ou ainda publico (PUBLIC), que
significa
que o privilgio concedido ser para todos os usurios.
WITH GRANT
OPTION : Permite que o recebedor do privilgio possa repass-lo a
outros usurios ou roles. O recebedor deste
privilgio no
poder ser uma role.

Exemplos :
GRANT o usurio SUE e RICH, com o privilgio de consultar a tabela
ACCOUNTS :

GRANT SELECT ON ACCOUNTS TO SUE, RICH;


GRANT o usurio SCOTT com os privilgios necessrios para consultar a
tabela EMP, inserir linhas na tabela EMP, com valores nas colunas EMPNO,
ENAME e DEPTNO, e Alterar a coluna ENAME na Tabela EMP :

GRANT SELECT, INSERT(EMPNO, ENAME, DEPTNO),
UPDATE(ENAME)
ON EMP TO SCOTT;

Para um usurio garantir privilgios sobre um objeto, necessrio que este
objeto seja de sua propriedade ou seja, que esteja em seu schema, ou que o
usurio em questo tenha recebido um GRANT do objeto, com a condio de
WITH GRANT OPTION.
O proprietrio do objeto pode conceder qualquer privilgio sobre o seu objeto, a
qualquer outro usurio ou role, pois o proprietrio de um objeto adquire
automticamente, todos os privilgios sobre este objeto.
Para se saber os privilgios que cada usurio tem, deve-se consultar as
seguintes views do Dicionrio de Dados :

Disponvel somente ao DBA :

- DBA_TAB_PRIVS Todos os privilgios dos objetos do Banco
de Dados

- DBA_COL_PRIVS Todos os privilgios das colunas de tabelas
do
Banco de Dados

Disponvel ao usurio :

- USER_TAB_PRIVS Privilgios em objetos que so proprietrios
ou
em objetos que receberam privilgios

- USER_TAB_PRIVS_MADE Todos os privilgios em objetos de sua
propriedade

- USER_TAB_PRIVS_RECD Todos os privilgios em objetos, recebidos
pelo
comando GRANT

- USER_COL_PRIVS Privilgios em colunas de tabelas que so
proprietrios ou em colunas de tabelas que
receberam privilgios

- USER_COL_PRIVS_MADE Todos os privilgios em colunas de tabelas
de sua propriedade

- USER_COL_PRIVS_RECD Todos os privilgios em colunas de tabelas,
recebidos pelo comando GRANT

Disponvel a todos os usurios :

- ALL_TAB_PRIVS Privilgios em objetos que so usurios ou
em objetos que receberam privilgios PUBLIC

- ALL_TAB_PRIVS_MADE Privilgios de usurio e privilgios
em objetos que so usurios

- ALL_TAB_PRIVS_RECD Todos os privilgios ou PUBLIC, em
objetos dos quais so usurios

- TABLE_PRIVILEGES Todos os privilgios em objetos dos quais so
usurios, proprietrios, recebedores de privilgios,
que tenha permisso para repassar o GRANT,
ou PUBLIC

- ALL_COL_PRIVS Privilgios em colunas de tabelas que so
usurios ou PUBLIC

- ALL_COL_PRIVS_MADE Todos os privilgios em colunas de tabelas
de sua
propriedade,ou que tenha permisso para
repassar
o GRANT


- USER_COL_PRIVS_RECD Todos os privilgios em colunas de tabelas,
recebidos pelo comando GRANT, ou
PUBLIC

- COLUMN_PRIVILEGES Todos os privilgios em colunas dos quais
so
usurios, proprietrios, recebedores de
privilgios,
que tenha permisso para repassar o
GRANT,
ou PUBLIC.

Comando REVOKE

Comando :

REVOKE object_priv ON [schema] objeto
FROM user CASCADE CONSTRAINT
role
PUBLIC
Onde :

object_priv : o privilgio tipo object, a ser retirado
ON : especifica o objeto sobre o qual o privilgio ser retirado
FROM : identifica quem ir ficar sem o privilgio, que podera ser
um
usurio, uma role ou ainda publico (PUBLIC), que
significa
que o privilgio ser retirado de todos os usurios.
CASCADE
CONSTRAINTS : Apaga qualquer integridade referencial definida
utilizando o
privilgio REFERENCES que foi retirado.

Exemplo :
Retirar o privilgio de consulta da tabela ACCOUNTS do usurio BAKER :

REVOKE SELECT ON ACCOUNTS FROM BAKER;

Somente o usurio que concedeu o privilgio que pode retira-lo.


ROLES

As ROLES simplificam o gerenciamento de privilgios a usurios. A role um
grupo de privilgios ao qual se atribui um nome, permitindo que ao se fornecer
como privilgio a um usurio o nome da role, todos os privilgios pertencentes
a esta role, passam a pertencer tambm ao usurio.
As roles :
Podem ter privilgios do tipo SYSTEM e OBJECT
No pertencem a nenhum usurio especfico ou schema
Podem ser concedidas a qualquer usurio ou role, menos ela
mesma
Podem ser habilitadas ou desabilitadas por cada usurio autorizado
Podem necessitar de senha para serem habilitadas

Benefcios do uso de roles :
Podem conceder ou retirar (GRANT ou REVOKE) varios privilgios
com um nico comando
Podem ser concedidas a novos usurios, sem a necessidade de se
lembrar cada um dos privilgios individualmente
Simplifica o gerenciamento de privilgios em sistemas com muitas
tabelas e muitos usurios.
Pode-se mudar varios privilgios de varios usurios, mudando
apenas uma role
Pode-se habilitar e desabilitar roles,para tornar os privilgios
temporarios a um usurio.

Para criar roles, deve-se observar primeiro, os seguintes detalhes :
1 - Criar uma role para cada aplicao (application role)
2 - Criar uma role para cada tipo de usurio (user role)
3 - GRANT somente roles de aplicao aos usurios da aplicao
4 - GRANT roles de aplicao e roles de usurios aos usurios.

Comando :

CREATE ROLE nome NOT IDENTIFIED
IDENTIFIED BY senha
EXTERNALLY

Onde :

nome : Nome da role a ser criada
NOT IDENTIFIED : Indica que o usurio no necessita de senha para
habilitar a role
IDENTIFIED : Indica que o usurio necessita de senha para
habilitar a role
BY senha : Senha de habilitao da role
EXTERNALLY : Indica que o ORACLE dever verificar o acesso do
usurio role usando um utilitrio (senha) do
sistema operacional.
(a senha do login, no caso da NOVELL)

Exemplo :
Criar a role MANAGER e atribuir privilgios a ela e atribuindo a role a um
usurio :


CREATE ROLE MANAGER;
GRANT CREATE SYNONYM, CREATE TABLE TO MANAGER;
GRANT MANAGER TO KEVIN;

Comando para alterar a role, atribuindo ou retirando a identificao por senha :

ALTER ROLE nome NOT IDENTIFIED
IDENTIFIED BY senha
EXTERNALLY

Onde :

nome : Nome da role a ser alterada
NOT IDENTIFIED : Indica que o usurio no necessita de senha para habilitar
a role
IDENTIFIED : Indica que o usurio necessita de senha para habilitar a
role
BY senha : Senha de habilitao da role
EXTERNALLY : Indica que o ORACLE dever verificar o acesso do
usurio role usando um utilitrio do sistema
operacional.

Exemplo :

ALTER ROLE MANAGER
IDENTIFIED BY SENHAMASTER;


Habilitando e Desabilitando Roles

Pode-se habilitar ou desabilitar roles, tornado-as disponvel ou restrito certos
privilgios para os usurios.
Efeitos :
Pode habilitar/desabilitar roles que j tenham sido concedidas a
usurios
Privilgios concedidos a uma role desabilitada, no estaro
disponveis ao usurio
Pode requisitar uma senha ou uma autorizao do sistema
operacional
Pode ser executada a partir de :
Linguagem de terceira gerao (PRO*C)
SQL*Plus e SQL*DBA
SQL*Forms e SQL*Menu
PL/SQL (usando comandos de library)
Procedures e Triggers de Banco de Dados.

Comando :
SET ROLE nome da role, nome da role2, ....... IDENTIFIED BY
senha

ALL [EXCEPT nome role, ...]

NONE


Onde :

nome da role : o nome da role (um ou mais nomes) a ser habilitada
para a
sesso corrente. Todas as roles no listadas, sero
desabilitadas para a sesso corrente.

senha : a senha da role. Se a role foi criada com senha, ela
deve ser especificada para poder ser habilitada


ALL / EXCEPT : ALL habilita todas as roles para a sesso corrente, menos
as
especificadas pelo EXCEPT

NONE : desabilita todas as roles para a sesso corrente

Exemplos :
SET ROLE ACCT_CLERK
IDENTIFIED BY BICENTENIAL;

SET ROLE ALL
EXCEPT ACCT_PAY;

SET ROLE NONE;


Estabelecendo Roles Default

Utiliza-se o camando ALTER USER para estabelecer uma role default ao
usurio :

ALTER USER nome
DEFAULT ROLE nome da role, nome da role2, .......
IDENTIFIED BY senha


ALL [EXCEPT nome role, ...]

NONE


Onde :

nome : nome do usurio a ser alterado
DEFAULT ROLE : estabelece as roles default para o usurio. O ORACLE
habilita as roles default do usurio, quando de seu logon.

Exemplo :

ALTER USER SCOTT
DEFAULT ROLE ACCT_CLERK;
Para se obter informaes sobre roles, usa-se as views :
ROLE_SYS_PRIVS Informaes sobre os privilgios SYSTEM concedidos a
roles
ROLE_TAB_PRIVS Informaes sobre os privilgios de tabelas concedidos a
roles
ROLE_ROLE_PRIVS Informaes sobre roles concedidas a outras roles
SESSION_ROLES Roles que o usurio tem habilitada nesta session
USER_ROLE_PRIVS Roles concedidas ao usurio
DBA_SYS_PRIVS Descrio dos privilgios SYSTEM concedidos a usurios
e roles
DBA_ROLES Todas as roles existentes no Banco de Dados

Duas roles especiais, a OSOPER e OSDBA, so usadas para controlar as
operaes do Banco de Dados, quando o Dicionrio de Dados estiver
inacessivel, ou seja, quando o Banco de Dados no estiver montado
(mounted), especificamente para proteger o uso da palavra chave INTERNAL.
As roles OSOPER e OSDBA permitem dois diferentes nveis de uso para a
palavra chave INTERNAL :
OSOPER : Permite realizar STARTUP, SHUTDOWN, ALTER DATABASE
OPEN/MOUNT, ALTER DATABASE BACKUP CONTROLFILE,
ALTER TABLESPACE BEGIN / END BACKUP, ARCHIVELOG
AND RECOVER.
Contm tambm, o privilgio RESTRICTED SESSION.

OSDBA : Contm todos os privilgios SYSTEM com o WITH ADMIN
OPTION e a
role SOPER. Somente a role OSDBA permite o CREATE
DATABASE e
a recuperao TIME-BASED.
Apndice A
A arquitetura do ORACLE7.

O entendimento da arquitetura do sistema gerenciador de banco de
dados da Oracle Corporation de extrema importncia para que
possamos monitorar e ajustar a performance de um banco de dados.
Por isso, nesse captulo apresentaremos uma viso geral da
arquitetura do ORACLE7, descreveremos todas as estruturas de
memria, a forma como o produto trabalha e como os dados so
acessados, a configurao Multi-threaded e o registro das
transaes.

________________________________________
Viso geral.

O conhecimento da arquitetura interna do ORACLE7 de extrema importncia para a
compreenso das tcnicas de otimizao do produto. Basicamente, os seus mecanismos de
execuo so as estruturas de memria e os processos executados em background. Todas as
vezes que um banco inicializado, uma SGA alocada e os processos so inicializados. A
combinao das estruturas de memria na SGA e dos processos em background chamada
de instncia ORACLE7. Algumas arquiteturas de hardware permitem mltiplos computadores
compartilharem os mesmos dados, softwares ou perifricos. Com a opo Parallel Server do
ORACLE7, podemos tirar proveito dessa caracterstica atravs da execuo de mltiplas
instncias que compartilham um nico banco de dados. Assim, os usurios de diversas
mquinas podem acessar o mesmo banco de dados com uma melhoria na performance.

Arquivos
de Dados
Arquivos
Redo Log
Arquivos
de Controle
Arquivo de
Parmetros
Usurio
Servidor
Dedicado
PMON SMON RECO LCKn SNPn
DBWR LGWR
CKPT
ARCH
SGA
Redo Log
Buffer
Shared Pool Area
Shared
SQL
Area
Data
Dictionary
Cache
Sequence
Cache
Database
Buffer Cache


Figura 1
Arquitetura do ORACLE7.

SGA A SGA um grupo de buffers de memria compartilhados que
so destinados pelo ORACLE7 para uma instncia.
Basicamente formada pelas estruturas identificadas por
shared pool, database buffer cache e redo log buffer cache.
Entretanto, em algumas configuraes do ORACLE7 podem
existir outras estruturas.

Processos em Background Os processos em background executam tarefas distintas
assincronicamente em benefcio a todos os usurios de um
banco de dados. No existe uma relao direta entre os
processos em background e os processos dos usurios
conectados a uma instncia ORACLE7. Apesar de poderem
existir outros em uma instncia, o que depende da
configurao do ORACLE7 utilizada, os processos mais
conhecidos so o PMON, SMON, DBWR, LGWR, RECO, LCK,
CKPT e o ARCH.

Geralmente um banco de dados est associado a somente uma instncia. Entretanto, como
vimos, em algumas configuraes do ORACLE7, um banco de dados pode estar associado a
mais de uma instncia. Assim, precisamos diferenciar os dois conceitos: um banco de dados
formado pelos arquivos fisicamente armazenados em disco enquanto que uma instncia
formada pelas estruturas e processos em memria. O banco de dados permanente,
enquanto que uma instncia voltil. Naturalmente, para acessarmos um banco de dados
necessrio que uma instncia seja inicializada e associada a ele.

________________________________________
Estruturas de memria.

As estruturas de memria so criadas pelo ORACLE7 e usadas para completar diversas
tarefas. Por exemplo, elas so usadas para guardar o cdigo de um programa que est sendo
executado e os dados que podem ser compartilhados pelos usurios.

SGA e PGA.

As principais estruturas so a SGA (System Global Area ou rea Global do Sistema) e a PGA
(Program Global Area ou rea Global de Programa).

A PGA o buffer de memria que contm dados e algumas informaes de controle de uma
sesso de um usurio. A PGA criada e alocada quando um novo processo inicializado no
servidor. As suas informaes dependem da configurao do ORACLE7. Assim, existe uma
rea de memria PGA para cada usurio que est executando seus trabalhos no ORACLE7.
Dentro da PGA existem trs estruturas: uma contendo um espao para a pilha (para
armazenar as variveis e matrizes), outra contendo dados sobre a sesso do usurio e uma
terceira com as informaes dos cursores usados. A PGA no compartilhada entre os
usurios; ela nica para cada sesso.

A SGA uma regio de memria compartilhada por todos os usurios e alocada pelo
ORACLE7. Contm os dados e as informaes de controle de uma instncia. Ela alocada
quando uma nova instncia inicializada e liberada quando a mesma finalizada. Os dados
na SGA so compartilhados pelos usurios que estiverem conectados ao banco de dados e,
para otimizar a performance, as entradas na SGA devem ser as maiores possveis para
guardar a maior quantidade de dados e minimizar o I/O em disco, uma das causas crticas que
tornam um banco de dados lento. As informaes na SGA esto organizadas em diversos
tipos de estruturas de memria, incluindo o buffer do banco de dados e o buffer para
recuperao do banco, por exemplo. As estruturas tm tamanho fixo e so criadas durante a
inicializao da instncia. O grupo de buffers do banco de dados em uma instncia so
chamados de database buffer cache. Esses buffers podem conter os dados modificados que
ainda no foram escritos em disco, para os arquivos de dados apropriados. Desse modo o I/O
minimizado e h uma melhora significativa da performance.

Essa estrutura compartilhada entre todos os usurios conectados a um banco de dados e os
blocos de dados que so armazenados no database buffer cache tm seus tamanhos
determinados pelo parmetro DB_BLOCK_SIZE. O nmero de blocos em memria
determinado pelo parmetro DB_BLOCK_BUFFERS.

O contedo do database buffer cache organizado em duas listas: a lista de blocos alterados
e a lista dos blocos menos recentemente utilizados (LRU - Least Recently Used). Essa
segunda lista contm os blocos livres, aqueles que esto em uso e os blocos alterados.
Quando um processo servidor precisa ler dados de um bloco do disco para o database buffer
cache, ele pesquisa a LRU para localizar um bloco livre e, quando encontrar um bloco
alterado, movimenta-o para a lista de blocos alterados. Esse processo termina quando um
bloco livre localizado ou quando um nmero especfico de blocos so pesquisados sem
encontrar um bloco livre.

Durante uma operao de SELECT, o ORACLE7 requer que os blocos que contm a
informao desejada esteja em memria. Assim, a lista LRU pesquisada e, se os blocos no
estiverem em memria, o produto efetua as leituras fsicas necessrias. Caso o bloco esteja
em memria, so efetuadas leituras lgicas. Lembremo-nos de que nenhuma tabela pode
ocupar menos de dois blocos de dados: um bloco para o cabealho e pelo menos outro bloco
de dados.

O redo log buffer cache da SGA armazena todas as alteraes feitas em um banco de dados
em memria. Todas as entradas redo log neste buffer so escritas nos arquivos redo log, que
so usados para a recuperao do banco de dados, se necessrio.

A shared pool uma poro de memria compartilhada que contm as reas chamadas
shared SQL, estruturas de memria compartilhadas que contm os comandos SQL que esto
sendo executados pelos mltiplos usurios conectados a um banco de dados. Essas reas
compartilhadas shared SQL contm informaes como o texto e a forma interpretada dos
comandos SQL, a fase de anlise dos comandos SQL e seus planos de execuo,
informaes do dicionrio de dados e de geradores de nmeros seqenciais. Uma nica rea
shared SQL pode ser compartilhada por diversas aplicaes que usam o mesmo comando
definido na rea compartilhada de comandos SQL, deixando assim mais rea em memria
disponvel para os outros usurios e melhorando a performance de execuo de um comando,
j que o plano de execuo j est definido e o ORACLE7 no precisa defini-lo novamente.

A shared pool contm ainda o data dictionary cache, com as informaes do dicionrio de
dados, e o sequence cache, com as informaes dos geradores de nmeros seqenciais. Um
cursor um nome ou ponteiro para a memria associada a um comando especfico. Muitas
aplicaes ORACLE7 tiram proveito dos cursores.

Processos.

Os processos podem ser vistos como programas que trabalham em memria (em background)
e executam outras tarefas especficas para o ORACLE7. Um processo uma forma de
controle ou um *mecanismo no sistema operacional que pode executar uma srie de passos e
normalmente tem sua rea particular de memria. Alguns sistemas operacionais usam o termo
job ou tarefa.

Existem dois tipos gerais de processos: os processos dos usurios e os processos do prprio
ORACLE7.

Um processo de usurio criado e mantido para executar o cdigo da aplicao (por exemplo
um programa Pro*C) ou uma ferramenta ORACLE7 (por exemplo o SQL*Plus). Os processos
dos usurios tambm gerenciam a comunicao com os processos do servidor ORACLE7
atravs do program interface.

Os processos ORACLE7 so chamados por outros processos para executar algumas funes
especficas. O produto cria os processos servidores (server process) para controlar as
requisies dos processos dos usurios conectados a um banco de dados. Assim, os
processos servidores so incumbidos de comunicar-se com os processos dos usurios e
interagir com o ORACLE7 para acessar seus recursos.

Por exemplo, se um usurio pesquisa alguns dados que no estejam no database buffer cache
da SGA, o processo servidor l os dados apropriados dos blocos de dados dos arquivos e os
coloca na SGA, para uso dos usurios. Dependendo da configurao do ORACLE7, um
processo servidor pode ser compartilhado por diversos usurios.

Todos os comandos SQL so processados pelos processos servidores que se utilizam de trs
fases para o processamento: anlise, execuo e busca dos dados. O plano de cada comando
armazenado na SGA, nas reas que contm comandos SQL a serem compartilhados entre
os usurios.

O ORACLE7 cria um conjunto de processos que rodam em background para cada instncia.
Esses processos executam diversas tarefas. So eles: DBWR, LGWR, CKPT, SMON, PMON,
ARCH, RECO, Dnnn e LCKn.

O processo database writer (DBWR) escreve os blocos modificados do database buffer cache
para os arquivos de dados fsicos. O DBWR no precisa escrever os dados a cada comando
COMMIT, pois otimizado para minimizar o I/O. Geralmente o DBWR escreve os dados para
o disco se muitos dados so lidos para o database buffer cache na SGA e no existe espao
livre para esses novos dados. Os dados menos recentemente usados so escritos para os
arquivos de dados em primeiro lugar.

O processo log writer (LGWR) escreve todas as entradas de redo log para o disco. Os dados
de redo log so armazenados em memria no redo log buffer cache, na SGA. No momento em
que uma transao for efetivada com o comando COMMIT e o redo log buffer estiver
preenchido, o LGWR escreve as entradas de redo log nos arquivos redo log apropriados.

A um tempo especfico, todos os dados do database buffer cache modificados so escritos em
disco pelo processo DBWR; este evento chamado de checkpoint. O processo checkpoint
responsvel para informar ao processo DBWR o momento de gravar os dados em disco. O
DBWR tambm atualiza os arquivos de controle do banco de dados para indicar o mais
recente checkpoint. O processo CKPT opcional; se ele no estiver presente, o LGWR
assume sua responsabilidade.

O processo system monitor (SMON) efetua a recuperao da instncia em caso de falhas,
durante a sua inicializao. Em um sistema com mltiplas instncias (como na configurao
Oracle7 Parallel Server, por exemplo), o processo SMON de uma instncia tambm pode
executar a recuperao de outras instncias que podem ter falhado. Ele tambm limpa os
segmentos temporrios que no esto sendo usados, liberando memria, e recupera qualquer
transao pendente no caso de uma falha em arquivos fsicos ou mesmo no disco. O processo
de recuperao dessas transaes executado pelo processo SMON quando a tablespace
afetada volta a ficar disponvel.

O process monitor (PMON) executa a recuperao do processo de um usurio quando esse
processo falha. Limpa a rea de memria e libera os recursos que o processo do usurio
estava usando. O PMON tambm verifica o processo despachante (dispatcher) e os processos
servidores (server processes) e os reinicializa se tiver acontecido qualquer falha.

O processo archiver (ARCH) copia os arquivos redo log para fita ou mesmo outro disco, no
momento em que um deles torna-se completo. Esse processo geralmente est presente
quando o banco de dados est sendo utilizado no modo ARCHIVELOG. Os arquivos redo log
nada tm a ver com auditoria. Eles so usados somente para a recuperao de um banco de
dados.

O processo recoverer (RECO) usado para resolver transaes distribudas pendentes
causadas por uma falha na rede em um sistema de bancos de dados distribudos. A certos
intervalos de tempo, o processo RECO do banco de dados local tenta conectar-se ao banco de
dados remoto para automaticamente completar e efetivar a transao (COMMIT) ou descartar
(ROLLBACK) a poro local de uma transao pendente em um sistema distribudo.

Os processos em background dispatchers (Dnnn) so opcionais e esto presentes somente
quando a configurao do Oracle7 Multi-thread Server usada. Pelo menos um processo
dispatcher criado para cada protocolo de comunicao em uso (D000, D0001, ..., Dnnn).
Cada processo dispatcher responsvel pelo direcionamento das requisies dos processos
dos usurios conectados ao banco de dados para o processo servidor disponvel e pelo
retorno da resposta de volta para o processo do usurio apropriado.

Por sua vez, os processos lock (LCKn) so usados para controlar o lock entre instncias em
uma configurao Parallel Server.

Program interface.

O program interface o mecanismo pelo qual um processo do usurio se comunica com o
processo servidor. Serve como um mtodo de comunicao padro entre a poro cliente de
uma aplicao ou uma ferramenta e o prprio servidor ORACLE7.

O program interface age como um mecanismo de comunicao, atravs da formatao dos
dados requisitados, trafegando esses dados, verificando e retornando possveis erros.
Tambm executa converses de dados, particularmente entre diferentes tipos de
computadores ou tipos de dados usados pelos usurios.

Se o usurio e os processos servidores esto em diferentes computadores de uma rede ou se
o processo dispatcher estiver sendo usado para conectar processos de usurios e processos
do servidor, ento o program interface inclui um software de comunicao chamado SQL*Net,
que faz a comunicao e transferncia de dados entre computadores.

________________________________________
Como o ORACLE7 trabalha?

Conhecendo os processos e estruturas de memria, fica bastante fcil para que entendamos
o modo como ORACLE7 trabalha:

1. Consideremos que uma instncia esteja sendo executada em um computador (servidor
de um banco de dados).

2. Um computador usado para executar uma aplicao (poro cliente ou front end)
executa uma aplicao de um usurio. Essa aplicao cliente tenta estabelecer uma
conexo com o servidor usando o driver apropriado do SQL*Net.

3. O servidor est executando o driver apropriado do SQL*Net e detecta a requisio de
conexo da aplicao cliente e cria um processo servidor dedicado ao usurio.

4. O usurio executa um comando SQL e efetiva a transao com o comando COMMIT.

5. O processo servidor recebe o comando e verifica se as reas shared SQL,
armazenadas na shared pool area, contm um comando idntico ao emitido pelo
usurio. Se localiza uma rea shared SQL com um comando idntico, o processo
servidor verifica os privilgios de acesso do usurio aos dados requisitados e o plano de
execuo definido usado para buscar os dados solicitados. Se o comando emitido pelo
usurio no estiver presente nessa rea, uma nova estrutura para o comando alocada
e ento ele pode ser analisado e processado.

6. O processo servidor recupera qualquer valor armazenado nos arquivos de dados ou os
busca da memria, se l estiverem, no database buffer cache.

7. O processo servidor modifica os dados na SGA. O processo DBWR escreve os dados
modificados em disco, quando necessrio. No momento do comando COMMIT, o
processo LGWR escreve imediatamente os registros das transaes no arquivo redo log
que estiver sendo usado no momento.

8. Se a transao for bem sucedida, o processo servidor manda uma mensagem atravs
da rede para a aplicao. Se no for bem sucedida, uma mensagem de erro ento
emitida.

________________________________________
Acesso aos dados.

Antes que os dados possam ser acessados, um processo servidor criado para um determinado
usurio conectado ao ORACLE7 traz os blocos dos arquivos fisicamente armazenados nos
discos para dentro do database buffer cache. Cada comando SQL armazenado na estrutura
de memria shared pool e so compartilhados entre todos os usurios conectados a uma
instncia. Em certo momento, os blocos de dados modificados pelos comandos dos usurios
que se encontram no database buffer cache so escritos novamente para os arquivos de
dados. Isso feito pelo processo em background DBWR.

Portanto, toda manipulao dos dados d-se na memria principal, ou seja, na SGA. por
isso que os dados precisam ser trazidos do disco para a memria antes de serem
manipulados.

Usamos dois termos para referenciarmos ao acesso aos dados: cache miss e cache hit. O
termo cache miss usado para identificar as vezes que um processo experimenta acessar
uma informao e o bloco que a contm precisa ser lido do disco. O termo cache hit usado
para identificar as vezes que um processo encontra uma informao na memria. Assim, um
acesso atravs de um cache hit mais rpido do que atravs de um cache miss.

Essa a forma bsica em que se processa o acesso aos dados, usando como exemplo um
comando SQL para a atualizao de informaes em uma tabela:

SQL> UPDATE emp
2 SET sal = sal * 1.1
3 WHERE ename = 'SCOTT';

1. O usurio emite um comando UPDATE, para atualizar a coluna SAL da linha identificada
pela coluna ENAME='SCOTT' de uma tabela hipottica chamada EMP.

2. O comando emitido pelo usurio analisado e armazenado na SGA, na estrutura
shared pool.

3. O processo servidor, criado quando o usurio faz a sua conexo com o ORACLE7,
efetua as leituras fsicas necessrias e traz os blocos de dados armazenados nos
arquivos de dados para dentro da SGA, na estrutura database buffer cache.

4. Em seguida o ORACLE7 aplica a alterao definida no comando UPDATE nos blocos
de dados que possuem a linha identificada por ENAME='SCOTT'.

5. Sob certas condies, o processo em background DBWR escreve os blocos de dados
alterados de volta para o arquivo de dados fsico apropriado. Esse processo em
background o responsvel por essa tarefa. Ele simplesmente libera rea de memria
do database buffer cache, j que a rea dessa estrutura limitada.


Processos de usurios e processos servidores.

Um processo de um usurio criado quando o usurio executa uma aplicao, ou seja,
quando cria uma conexo com uma instncia. Nesse momento, o ORACLE7 cria um processo
servidor dedicado que usado para executar as requisies do processo do usurio ao qual
se associa.

Portanto, um processo servidor comunica-se com um processo de um usurio, ou seja,
sempre vai ser requisitado para executar qualquer comando. Entretanto, em algumas
configuraes do ORACLE7, um processo servidor pode ser compartilhado por diversos
processos de usurios, isto , no vai ser utilizado para a conexo direta com qualquer
processo de usurio; na verdade essa conexo d-se com a utilizao de outros processos.
Portanto, nem sempre verdade que um processo servidor deve estar dedicado a um
processo de um usurio.

Basicamente, as funes de um processo servidor so:

1. Analisar e executar os comandos SQL.

2. Verificar se os blocos de dados encontram-se na estrutura database buffer cache.

3. Ler os blocos de dados dos arquivos fsicos no disco e lev-los para dentro do database
buffer cache, na SGA. Essa operao somente feita se os blocos de dados a serem
utilizados no se encontrarem em memria.

4. Retornar resultados dos comandos SQL para os processos dos usurios que os
emitiram.

Em um terminal dedicado em arquitetura multi-usurio, os processos dos usurios
permanecem no servidor, assim como os processos servidores criados pelo ORACLE7 . Em
arquitetura cliente-servidor os processos dos usurios permanecem na poro cliente,
enquanto os processos servidores criados pelo ORACLE7 permanecem no servidor.
Entretanto, para o ORACLE7 a forma de acesso independe da arquitetura utilizada, pois as
estruturas na SGA, os processos e os prprios arquivos fsicos so basicamente os mesmos.

A estrutura shared pool e seus buffers.

A estrutura de memria compartilhada chamada shared pool contm informaes usadas para
executar os comandos SQL. formada pelos buffers denominados shared SQL, data
dictionary cache e sequence cache.

Os buffers identificados como shared SQL areas contm o seguinte:

1. O texto dos comandos SQL e PL/SQL.

2. A forma analisada dos comandos SQL e PL/SQL.

3. O plano de execuo para os comandos SQL e PL/SQL.

O compartilhamento dos planos de execuo dos diversos comandos nas reas de comandos
SQL compartilhados melhoram o uso da memria, uma vez que as definies dos comandos
podem ser compartilhadas entre as diversas aplicaes.

A memria tambm dinamicamente ajustada de acordo com o conjunto de comandos SQL
que so executados e, como a fase de parse ou anlise resumida, o tempo de execuo de
um comando pode diminuir consideravelmente.

Por sua vez os buffers identificados como data dictionary cache contm:

1. Linhas com as informaes do dicionrio de dados.

Finalmente, os buffers identificados como sequence cache contm:

1. Informaes sobre os geradores de nmeros seqenciais usados pelos usurios.

Database buffer cache.

A estrutura de memria compartilhada chamada database buffer cache contm cpias dos
blocos de dados que so lidos do disco pelos processos servidores. Os buffers so
compartilhados por todos os usurios conectados a uma instncia ORACLE7.

O tamanho dos blocos de dados determinado pelo parmetro DB_BLOCK_SIZE,
especificado no momento da sua criao e no pode ser alterado a menos que o banco seja
novamente recriado.

O nmero de blocos lgicos em memria determinado pelo parmetro
DB_BLOCK_BUFFERS. Esses dois parmetros configuram o tamanho do database buffer
cache.

Ele organizado em duas listas: a dirty list e a least recently used list (LRU). A dirty list uma
lista que contm os blocos alterados que ainda no foram escritos em disco.

A LRU uma lista que contm blocos do ORACLE7 que foram alterados pelos comandos dos
usurios mas ainda no foram gravados em disco. Contm ainda blocos livres e blocos em
uso.

Assim, quando um processo servidor precisa ler um bloco de dados do disco para a memria,
ele:

1. Pesquisa nas listas LRU e dirty list pelo bloco de dados desejado.

2. Caso esse bloco de dados no seja localizado, o processo servidor pesquisa a lista LRU
em busca de um bloco livre.

3. Em seguida, o processo servidor move os blocos alterados encontrados na lista LRU
para a dirty list, ou seja, movimenta-os para a lista de blocos alterados ainda no
gravados nos arquivos de dados, de acordo com a localizao de cada um deles,
durante o processo de pesquisa de um bloco livre.

4. Finalmente, o processo servidor efetua uma cpia do bloco de dados do disco para um
bloco livre.

5. Esse procedimento termina quando o processo servidor localiza um bloco livre ou se um
nmero especfico de blocos forem pesquisados sem encontrar um nico bloco livre.

Se nenhum bloco foi encontrado, o ORACLE7 deve gravar os blocos alterados da dirty
list para os arquivos em disco, para liberar espao em memria para os novos blocos de
dados que precisam ser manipulados pelos comandos dos usurios.


Operao envolvendo o comando SELECT.

Para uma operao que envolve o comando SELECT preciso que os blocos de dados que
contm as linhas a serem retornadas, de acordo com o critrio de pesquisa, estejam em
memria, no database buffer cache.

So executados os seguintes passos:

1. A lista LRU pesquisada para que os blocos de dados necessrios sejam encontrados.

2. Caso no se encontrem em memria, o processo do servidor executa as leituras fsicas
necessrias e traz os blocos para a memria.

3. Em seguida so feitas leituras lgicas em memria.

Nenhuma tabela ocupa menos de dois blocos de dados. Portanto, quando uma certa
informao armazenada em uma tabela requerida na memria, pelo menos dois blocos de
dados so necessrios: um bloco de cabealho e outro bloco com os dados.

Segmentos de rollback.

Um segmento de rollback uma poro de um banco de dados que registra as aes das
transaes dos usurios nos dados para que possam ser desfeitas sob certas circunstncias;
um objeto usado para gravar os dados alterados pelos processos dos usurios. Cada banco
de dados deve possuir pelo menos um deles.

Um segmento de rollback usado para permitir a consistncia da leitura, recuperar um
comando quando ocorre o dead-lock, recuperar uma transao at uma certa marca
identificada por um SAVEPOINT, recuperar uma transao terminada por uma falha de
processo de um usurio e desfazer todas as transaes pendentes durante a recuperao de
uma instncia.

Cada transao deve ser assinalada a um segmento de rollback. Isso pode ser feito
automaticamente baseado em alguns critrios que o ORACLE7 possui, como pode ser feito
manualmente pelos usurios atravs do comando:

SQL> ALTER SYSTEM USE ROLLBACK SEGMENT rb_name;

Onde:

RB_NAME Nome do segmento de rollback.

Operao envolvendo o comando UPDATE.

Todas as operaes de atualizao de dados em um banco de dados envolvem os segmentos
de rollback para permitir a consistncia da leitura, a recuperao das informaes e permitir
que uma transao ou um comando sejam desconsiderados ou desfeitos.

So executados os seguintes passos:

1. Os blocos de dados da tabela a ser alterada, com as linhas que sofrero as alteraes,
so trazidos para a memria.

2. Os blocos de um segmento de rollback so alocados na mesma estrutura database
buffer cache. Nesse momento, o ORACLE7 aloca automaticamente um segmento de
rollback disponvel ou algum especificado pelo comando ALTER SYSTEM USE
ROLLBACK SEGMENT.

3. So feitos locks exclusivos nas linhas modificadas.

4. Os dados antigos so gravados em um bloco do segmento de rollback acionado
anteriormente. Nele so armazenados tambm a identificao da transao do usurio
que executou o comando UPDATE, o endereo da coluna com a especificao do bloco
de dados acionado, a identificao do arquivo fsico e o nmero da linha e da coluna a
serem alteradas em seguida.

5. As alteraes so aplicadas nas linhas da tabela em cada um dos blocos de dados que
as armazenam.

Caso o mesmo usurio que tenha executado um comando UPDATE pesquisar a tabela
atualizada, ele enxergar sua alterao. Os outros usurios no a enxergaro, isto , lero
apenas o valor antigo armazenado no segmento de rollback. Dessa forma mantm-se a
consistncia de leitura. Naturalmente, quando o usurio que executou o comando UPDATE
efetivar as alteraes com o comando COMMIT, todos os outros usurios passaro a enxergar
as alteraes feitas, exceto se algum outro estiver executando uma operao em andamento
com o comando SELECT.

Consistncia de leitura.

Durante todo o processamento de um comando SQL, o ORACLE7 mantm uma consistncia
dos dados de uma tabela de acordo com o momento em que o comando for inicializado.

Para o comando SELECT, o ORACLE7 marca o momento da sua execuo como o instante a
partir do qual a consistncia de leitura mantida.

A partir deste momento, quaisquer alteraes feitas em uma tabela por outros usurios no
so enxergadas pelo usurio que emitiu o comando SELECT, at que os outros usurios que
atualizaram a tabela terminem suas transaes, com os comandos COMMIT ou ROLLBACK.

Todas as alteraes feitas so mantidas em segmentos de rollback alocados pelo ORACLE7
ou pelos prprios usurios. Para quem estiver lendo a tabela o ORACLE7 l os valores antigos
no segmento de rollback apropriado, e no nos blocos de dados alterados.

A seguir apresentamos o funcionamento desse mecanismo:

10 h 00 min SQL> UPDATE EMP ...;

s dez horas o usurio A executa o comando UPDATE mas no efetiva a
alteraes.

10 h 01 min SQL> SELECT ... FROM emp;

s dez horas e um minuto o usurio B pesquisa a tabela EMP. Ele no
enxerga as alteraes feitas pelo usurio A. Do segmento de rollback que
registrou a alterao do usurio A trazido o valor antigo s alteraes,
ocorrendo a consistncia da leitura.

10 h 02 min SQL> COMMIT;

s dez horas e dois minutos o usurio A efetiva sua transao. Como no
existe nenhum processo de leitura em andamento e no foi utilizado
comando SET TRANSACTION READ ONLY, os segmentos de rollback
alocados so liberados.

10 h 03 min SQL> SELECT ... FROM emp;

Finalmente, s dez horas e trs minutos o usurio B passa a enxergar as
alteraes feitas na tabela EMP pelo comando UPDATE do usurio A, pois
a transao foi terminada e efetivada com o comando COMMIT.

Processo DBWR.

O processo Database Writer (DBWR) gerencia o database buffer cache para que os processos
dos usurios sempre localizem blocos livres para o processamento de seus comandos.

Ele escreve todos os buffers alterados para os arquivos de dados, usando o algoritmo LRU
para manter os blocos mais utilizados em memria.

O DBWR adia ao mximo a escrita dos blocos alterados para a otimizao do I/O em disco,
que uma das principais causas para a queda da performance de um banco de dados.

O processo DBWR escreve os blocos alterados para o disco quando:

1. A dirty list ultrapassar um certo limite. Essa lista usada no database buffer cache e
contm os buffers alterados.

2. Um processo pesquisar um nmero especfico de buffers na LRU sem encontrar um
bloco livre.

3. Ocorrer o time-out, ou seja, quando um certo tempo limite for ultrapassado. Esse tempo
limite geralmente de trs segundos.

4. Ocorrer um checkpoint.

________________________________________
Configurao multi-threaded.

O ORACLE7 pode ser configurado em trs diferentes formas para variar o nmero dos
processos de usurios que podem estar conectados em cada processo do servidor.

Dedicated Server Um processo servidor dedicado manuseia as
requisies emitidas por um nico usurio.

Esse processo servidor criado quando ocorre a
conexo de um usurio com o ORACLE7.

Multi-Threaded Server A configurao Multi-Threaded Server do ORACLE7
permite que diversos processos de usurios conectados
a uma instncia possam compartilhar um conjunto de
processos servidores disponveis.

Esses processos servidores so fornecidos pelo
ORACLE7 quando o usurio requisita um comando.

Combined User/Server Process Nesta configurao os cdigos de uma aplicao e do
ORACLE7 so combinados em uma nica tarefa.

Essa configurao disponvel em alguns sistemas
operacionais, como o VMS.

Arquivos
de Dados
Arquivos
Redo Log
Arquivos
de Controle
Arquivo de
Parmetros
Usurio
Servidor
Dedicado
PMON SMON RECO LCKn SNPn
DBWR LGWR
CKPT
ARCH
SGA
Redo Log
Buffer
Shared Pool Area
Shared
SQL
Area
Data
Dictionary
Cache
Sequence
Cache
Database
Buffer Cache
Usurio
Usurio
Usurio
Despachante
Servidor
Compartilhado
Servidor
Compartilhado
Servidor
Compartilhado


Figura 2
Configuraes do ORACLE7.

Com a utilizao apropriada dessas configuraes, podemos eventualmente melhorar o
desempenho do banco de dados. Por isso, nessa sesso discutiremos a arquitetura multi-
threaded, suas vantagens e a configurao do ambiente.

Quando devemos usar?

O uso do multi-threaded tem diversas vantagens em relao s outras configuraes. Com ele
podemos reduzir o nmero de processos em execuo na instncia e, dessa forma,
conseguimos aumentar o nmero de possveis usurios. O nmero de processos desocupados
pode ser drasticamente diminudo e temos uma sensvel melhora no uso da memria.

Somente em algumas situaes especiais devemos usar a configurao de servidores
dedicados. Para a execuo de procedimentos em lote, com uma grande quantidade de
comandos SQL e para nos conectarmos como INTERNAL (para fazermos o STARTUP,
SHUTDOWN ou a recuperao do banco de dados, por exemplo), devemos usar os servidores
dedicados. Tambm devemos faz-lo em algumas situaes incomuns envolvendo os dead-
locks no ambiente multi-threaded.

A arquitetura multi-threaded.

A arquitetura multi-threaded pode ser observada na Figura 2 e mais detalhadamente na
Figura 3. Para entendermos o seu funcionamento, vamos separ-la em duas fases.

A primeira caracterizada pela conexo dos usurios. Durante uma tentativa de conexo, um
processo chamado LISTENER (que faz parte do SQL*Net verso 2) percebe a requisio e
determina se o processo do usurio pode ou no usar um processo servidor compartilhado.
Caso seja permitido, o LISTENER informa ao processo do usurio o endereo de um processo
chamado despachante, ao qual permanecer conectado enquanto durar a sua sesso.
Quando o usurio requisita uma conexo dedicada, o LISTENER cria um processo servidor
dedicado e o associa ao usurio. Essa facilidade somente possvel com a verso 2 do
SQL*Net. As verses anteriores no suportam a facilidade do multi-threaded, ou seja, elas
aceitam to somente as conexes a processos servidores dedicados.

A segunda fase caracterizada pela emisso dos comandos SQL por parte dos usurios.
Quando um deles emite qualquer comando, essa requisio recebida pelo processo
despachante ao qual o usurio est conectado. Por sua vez, o despachante coloca a
requisio em uma fila de requisies, ou fila de entrada, que se encontra na SGA. O primeiro
processo servidor compartilhado que estiver disponvel obtm a requisio na fila de entrada e
o processa. Ao trmino do processamento, o processo servidor coloca a resposta em uma fila
de respostas, nica para o despachante ao qual o usurio estiver conectado. Finalmente, esse
despachante retorna a resposta ao usurio original.
Processo
Servidor
Processo
do Usurio
Despachante
SGA
Processo
Servidor Processo
Servidor
Fila de
Requisies
Fila de
Sada


Figura 3
A configurao multi-threaded em detalhes.

A fila de entrada, que recebe todas as requisies dos usurios, nica na instncia e
compartilhada por todos os despachantes. Essa fila do tipo FIFO, ou seja, primeiro-que-
entra-primeiro-que-sai (first-in-first-out). As filas de respostas so usadas para conter todas as
respostas dos comandos SQL executados pelos processos servidores compartilhados. Cada
um dos despachantes possui a sua prpria fila de respostas.

O contedo da PGA e da SGA diferencia-se quando implementamos o uso dos processos
servidores dedicados e compartilhados. A alocao de memria sem o multi-threaded, ou seja,
na configurao convencional (dedicada), difere-se da mutlti-threaded por que, nessa, parte do
contedo da PGA passa a residir na SGA; somente encontra-se originalmente na PGA um
espao para a pilha, que contm as variveis usadas por um usurio. As informaes sobre as
sesses dos usurios, que inclui dados sobre a segurana e o uso dos recursos do ORACLE7,
assim como as informaes sobre o estado dos cursores, passam a residir na SGA. Essa
alterao na PGA e na SGA totalmente transparente para os usurios. Podemos especificar
o montante de memria na SGA a ser alocada para cada usurio atravs dos profiles, que
controlam o uso dos recursos banco de dados.

A configurao do multi-threaded relativamente simples. Devemos inicialmente instalar e
configurar o SQL*Net Verso 2. Sem a verso 2 desse produto ficamos impedidos de usar
essa configurao.

Nesse documento no abordaremos toda a configurao, entretanto apresentaremos, em
seguida, os passos bsicos para configurarmos uma mquina servidora de banco de dados:

Passo 1: Configurar e criar o processo LISTENER.

O LISTENER o processo que controla as conexes s instncias. Podemos ter
vrios processos rodando em uma mesma mquina; entretanto apenas um j o
suficiente, pois podemos configur-lo para suportar diversas instncias e
diferenciados protocolos. Os tipos de conexes so determinados pelos
protocolos usados pelos processos despachantes.

Existe um arquivo especial, denominado LISTENER.ORA, que usamos para a
configurao do LISTENER. Geralmente ele encontra-se no diretrio
$ORACLE_HOME/NETWORK/ADMIN. Em alguns sistemas UNIX, esse diretrio
default pode ser o /etc.

Entretanto, podemos especificar qualquer diretrio que desejarmos; para isso
configuramos a varivel de ambiente chamada TNS_ADMIN com o nome do
diretrio desejado.

Nesse arquivo texto (LISTENER.ORA) inserimos todas as informaes sobre a
configurao do LISTENER. Abaixo, apresentamos um modelo:

################
# Exemplo do arquivo listener.ora
################
LISTENER =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL=TCP)
(HOST=192.1.1.10)
(PORT=1525)
)
)
STARTUP_WAIT_TIME_LISTENER=0
CONNECT_TIMEOUT_LISTENER=10
LOG_FILE_LISTENER=listener.log
SID_LIST_LISTENER=
(SID_LIST=
(SID_DESC=
(SID_NAME=sid1)
(ORACLE_HOME=/usr/oracle)
)
)
TRACE_LEVEL_LISTENER=0

Para criarmos o processo, usamos o utilitrio LSNRCTL:

$ lsnrctl start

Passo 2: Configurar os descritores de conexo.

Os descritores de conexo so usados para facilitar a conexo dos usurios. Eles
so armazenados no arquivo TNSNAMES.ORA, que fica nos mesmos diretrios
onde podemos encontrar o LISTENER.ORA. A seguir temos um exemplo:

###################
# Exemplo do arquivo tnsnames.ora
###################
sid1mts =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=192.1.1.10)
(PORT=1525)
)
)
(CONNECT_DATA=
(SID=sid1)
)
)
sid1dedic =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=192.1.1.10)
(PORT=1525)
)
)
(CONNECT_DATA=
(SID=sid1)
(SERVER=DEDICATED)
)
)

Passo 3: Configurar e criar a instncia.

Devemos fechar o banco e encerrar a instncia para em seguida colocarmos o
banco no ar, usando o arquivo de inicializao com os seguintes parametros:

MTS_DISPATCHERS="tcp,3", "ipc,2"
MTS_MAX_DISPATCHERS=10
MTS_SERVERS=4
MTS_MAX_SERVERS=14
MTS_SERVICE=sid1
MTS_LISTENER_ADDRESS="(ADDRESS=(PROTOCOL=TCP)(HOST=gp.com)(PORT=1525))"

________________________________________
Registro das transaes.

O ORACLE7 registra todas as alteraes feitas em um banco de dados na estrutura redo log
buffer cache.

Um processo em background denominado LGWR escreve as informaes desses buffers para
o disco, sob certas circunstncias.

Um outro processo em background conhecido como ARCH pode ser opcionalmente utilizado
para armazenar as informaes sobre as alteraes feitas nos dados em outro dispositivo,
sempre que um arquivo redo log for preenchido.

Somente um arquivo redo log utilizado por vez, entretanto em um banco de dados podem
existir diversos arquivos de redo log. O seu nmero mnimo de dois grupos, cada um deles
podendo conter um ou mais arquivos.

Redo log buffer cache.

O redo log buffer cache uma estrutura de memria de uso circular que contm buffers ou
conjuntos de blocos ORACLE7 com informaes sobre todas as alteraes feitas nos dados
de um banco de dados. Essas informaes so armazenadas sob a forma de entradas de redo
log e so usadas para recosntruir as informaes dos segmentos alterados, inclusive os
segmentos de rollback.

As entradas de redo log armazenam todas as alteraes feitas em um banco de dados dentro
da estrutura redo log buffer cache. So usadas para reconstruir ou descartar as alteraes
feitas nos dados quando uma recuperao for necessria, ou seja, armazenam a before image
e a after image. Esses termos so usados para identificarmos os dados antes e depois de uma
alterao.

Em situaes especiais, podemos desejar no registrar as alteraes nos arquivos de log. Por
exemplo, na criao de um ndice ou de uma tabela e na carga de dados atravs do
SQL*Loader; nos comandos de criao de tabelas e ndices podemos usar a clusula
UNRECOVERABLE.

O tamanho dessa estrutura determinado pelo parmetro LOG_BUFFER.

Comando UPDATE e o redo log buffer.

Como vimos, todas as alteraes feitas nos dados so armazenadas como entradas de redo
na estrutura redo log buffer cache.

Assim, a operao de UPDATE envolve realmente os seguintes passos:

1. Os blocos de dados da tabela a ser alterada com as linhas que sofrero as alteraes
so trazidos para a memria, para dentro do database buffer cache.

2. Os blocos de um segmento de rollback so alocados na mesma estrutura. Nesse
momento, o ORACLE7 aloca automaticamente um segmento de rollback disponvel ou
algum especificado pelo comando ALTER SYSTEM USE ROLLBACK SEGMENT.

3. So feitos locks exclusivos nas linhas a serem modificadas.

4. A imagem das informaes antes e depois das modificaes so acionadas para dentro
do redo log buffer cache como entradas de redo log.

5. Os dados antigos so gravados em um bloco do segmento de rollback acionado
anteriormente juntamente com a identificao da transao do usurio que executou o
comando UPDATE, o endereo da coluna com a especificao do bloco de dados
acionado, a identificao do arquivo fsico e o nmero da linha e da coluna a serem
alteradas em seguida.

6. As alteraes so aplicadas nas linhas da tabela em cada um dos blocos de dados que
as armazenam.

Processo LGWR.

O processo em background log writer (LGWR) escreve as entradas de redo log para o disco.
Isso acontece quando:

1. Ocorre a efetivao de uma transao com o comando COMMIT.

2. A estrutura redo log buffer atinge aproximadamente 1/3 de seu tamanho.

3. O processo em background DBWR precisa limpar os blocos dos buffers para a
ocorrncia de um checkpoint.

4. Ocorre o time-out.

Em uma instncia existe somente um nico grupo de arquivos redo log sendo utilizado para a
escrita das entradas de redo log, da memria para o disco, simultaneamente, assim como
somente um processo LGWR ativo. Enquanto uma transao no for registrada em um arquivo
redo log o COMMIT emitido no confirmado. Uma transao pode fazer com que outras
transaes sejam tambm gravadas nos arquivos redo log (piggy-backed, brincadeira
conhecida entre ns como cavalinho), quando so efetivadas simultaneamente.

Quando um grupo for preenchido, ocorre o log switch, ou seja, o prximo grupo disponvel
passa a ser utilizado. Caso o banco opere no modo ARCHIVELOG, podemos usar os
parmetros LOG_ARCHIVE_BUFFER_SIZE e LOG_ARCHIVE_BUFFERS para melhorarmos
a gravao dos mesmos para outro dipositivo. O primeiro parmetro determina o tamanho de
cada buffer de arquivamento do redo log buffer. O segundo parmetro determina o nmero de
buffers alocado para o arquivamento dos arquivos redo log.

Operao envolvendo o comando COMMIT.

O comando COMMIT efetiva as alteraes feitas nos dados por uma transao, tornando-as
permanentes.

So executados os seguintes passos:

1. Um usurio emite o comando COMMIT para finalizar sua transao.

2. Um registro desse COMMIT colocado no redo log buffer.

3. O processo em background LGWR grava as entradas de redo log dos buffers para o
arquivo redo log correntemente em uso, se possvel usando uma gravao multi-bloco.

4. O usurio notificado de que a transao foi efetivada.

5. Os locks nos recursos so liberados assim como os blocos do segmento de rollback
alocados para a transao do usurio.

Apesar de no fazerem parte do processo de COMMIT de uma transao, precisamos
assinalar que os blocos de dados so marcados como alterados e os blocos do segmento de
rollback so liberados ou marcados como reutilizveis e, eventualmente, o processo em
background DBWR pode escrever os blocos de dados alterados do database buffer cache
para os arquivos fsicos em disco.

O processo LGWR registra permanentemente todas as alteraes nos dados feitas pelas
transaes dos usurios, enquanto o DBWR adia ao mximo a escrita dos blocos alterados
nas transaes para diminuir o I/O, ou seja, reduzir o tempo de processamento da gravao
dos blocos de dados alterados que se encontram na estrutura database buffer cache para os
arquivos fsicos em disco, melhorando, assim, a performance. O I/O um dos aspectos que
causam os maiores problemas e deve ser melhorado.

Os comandos COMMIT simultneos dos usurios fazem com que as entradas de redo log para
suas transaes sejam gravadas juntas em uma nica operao de gravao fsica nos
arquivos redo log. Alm do mais, ocorre somente uma nica operao de gravao de
entradas redo log por transao, pois essa gravao ocorre no momento do COMMIT e esse
comando termina uma transao lgica. O tamanho de uma transao no afeta o tempo
necessrio para uma operao de COMMIT.

Você também pode gostar