ORACLE DataBase Administrator: 2009

------------------------------------ARQUITECTURA

Existem 5 pacotes de instalação do Oracle 10G
a) Enterprise
b) Standard
c) Standard Edition one
d) Personal
e) Lite

Produtos Oracle:
Oracle Application Server 10g
Oracle Developer Suite
Oracle Applications 11i
Oracle Collaboration Suite
Oracle Services

SQL - Structured Query Language
DDL (DATA DEFENITION LANGUAGE) : CREATE / ALTER / DROP
DCL (DATA CONTROL LANGUAGE) : GRANT / REVOKE
DML (DATA MODIFICATION LANGUAGE) : INSERT / UPDATE / DELETE

NOTA: AS TABELAS PODEM TER 1 milhão de Colunas e Bilies de Registos.

METADATA: É o conjunto de informação referente à estrutura das tabelas, número de registos, permissões e tipo de dados.
Existem dois tipos de vistas sobre a metadata:
a) vistas dinâmicas de perfomace ( V$ )
b) vistas do dicionário de dados (DBA_ // ALL_ // USER_ )

O tamanho mínimo de um 1- extent são 5 blocos.
O tamanho do Bloco pode ser definido na criação da base dados: 2kb,4kb,6kb,16kb

O Motor da base de Dados já integra o JVM (Java Virtual Machine ) de disponibiliza JODBC's para conexões java.

a) Os Ficheiros físicos são as bases de dados.
b) A estrutura de memória criada pelo oracle, é designada por instância.
c) E relação de processos entre os user.

Estas 3 secções são as que constituem o que designamos por ARQUITECTURA DE UM Servidor ORACLE.

USER PROCESS (nivel de Utilizador)
Existem apenas dois processos que interagem com a instancia oracle:
1- Server Process
2- User Process

O user Liga-se à bd, após o user process ter-se conectado com a base de dados, é criando então um sessão na base de dados.
Após esta conexao, a base de dados está apta a responder ao pedidos do user process, através de server process.
Paralelemente a este processo criado entre o user process e server process(geralmente 1-1) é criado uma área de memória
designda por PGA (Program Global Memory), cujo objectivo se destina a guardar as "bind variables" e "variaveis de sessão" para cada
user. Podemos então dizer, que é o server process, em nome do user que comunica com a instancia.

ORACLE INSTANCE:
A instancia de oracle é composta essencialmete pelo que designamos SGA (SYSTEM GLOBAL MEMORY) e um conjunto de background process.

SGA - é composta obrigatóriamente pelos 3 componentes:
1-SHARED POOL - ( mantem em cache o sql mais recente/usado pelos os users)
2-DATABASE BUFFER CACHE - ( mantem em cache a informação[dados] que foram usados mais recentemente pelo os users)
3-REDO LOG BUFFER - ( armazena informação das transações, com objectivos de reposição)

SGA - Componentes opcionais:
4-JAVA POOL - ( mamtem em cache os objectos mais usados/recentes quado é usado a JVM)
5-LARGE POOL - ( mantem em cache informação[dados] relativa a grande operações de reposições pelo RMAN, operações
partilhadas[SHARED SERVERS])
6-STREEMS POOL - ( mantem em cache informação relativa a mensagens em fila quando a opção ORACLE ADVANCING QUEUING está activo)

A manutenção da SGA pode ser efectuada manualmente ou automáticamente.
Se for manual, tem de ser especificada para cada sub-componente da SGA.
Porém quer de uma forma ou de outra o user se precisar de espaço na SGA, vai alocando ou desalocando de todas as outras areas da SGA,
de forma automática. Esse espaço é conhecido por GRANULES (que podem ser de 2, 4, 8 ou 16 Mb).

A configuração dos parametros da base de dados pode ser feita em dois files:
a) PFILE - Gestão manual - precisa de REBOOT (aceita mais de 250 parametros definidos) em que 30 são considerados os basicos.
b) SPFILE - Gestão Automatica - Não Precisa de REBOOT

30 PARAMETROS Básicos :
CLUSTER_DATABASE -> Indica se a instancia faz parte de um ambiente CLUSTER
COMPATAIBLE -> Especifica o nivel da release e funcionalidades activas da instancia
CONTROL_FILES -> Especifica a localização fisica dos Files de control
DB_BLOCK_SIZE -> Especifica o tamanho do block por defeito
DB_CREATE_FILE_DEST -> Especifica a localização fisica onde vão ser colocados os datafiles, se usarmos(OMF - ORACLE MAANGED FILES)
DB_CREATE_ONLINE_LOG_DEST_n -> Especifica a localização fisica dos REDO LOG FILEs, se for usado o OMF
DB_DOMAIN -> Especifica a localização lógica da base de dados na rede.
DB_NAME -> Especifica o nome da base dados que é montada na instancia
DB_RECOVERY_FILE_DEST -> Especifica a localização fisica onde vão ser escritos os files de recuperação se a opção FLASH RECOVERY está ON
DB_RECOVERY_FILE_DEST_SIZE -> Especifica o tamanho de disco fisico disponivel para serem escritos os files de recuperação
DB_UNIQUE_NAME -> Especifica o nome unico dentro do Enterprise Manager
INSTANCE_NUMBER -> Idenitifica a instancia num ambiente RAC.
JOB_QUEUE_PROCESSES -> Especifica o numero de processos que podem ser lançados em background para tratamento de Jobs(quer por DBMS_JOBS ou E.M.)
LOG_ARCHIVE_DEST_STATE_N -> Especifica o local fisico onde vão ser escritos os archive logs
NLS_LANGUAGE -> Especifica a linguagem por defeito da base de dados
NLS_TERRITORY -> Especifica a região/território por defeito da base de dados
OPEN_CURSORES -> Especifica o numero de cursores por sessão
PGA_AGGREGATE_TARGET -> Estabelece a quantidade total de memória que o todos processo PGA, juntos podem consumir
PROCESSES -> Especifica o numero máximo de processo do Sistema Operativo podem conectar à instancia
REMOTE_LISTENER -> Especifica o localização remota do LISTENER
REMOTE_LOGIN_PASSWORDFILE -> Determina se uma instancia usa file de password e de que tipo
ROLLBACK_SEGMENTS -> Especifica apenas quando não está a ser usado o AUTOMATIC UNDO MANAGEMENT
SESSIONS -> Determina o numero máximo de sessões que se podem conectar à base de dados
SGA_TARGET -> Estabelece o tamanho máximo da SGA, este valor é repartido por todos os sub-componentes
SHARED_SERVERS -> Especifica o numero de SHARED SERVERS PROCESSES para arrancarem no startup da instancia
STAR_TRANSFORMATION_ENABLED -> Determina se o optimizador do motor da BD, usar o metodo STAR, na execção das queries ou não
UNDO_MANEGEMENT -> Estabelece se o system UNDO é manual ou automatico
UNDO_TABLESPACE -> Especifica qual TBS é definido para guardar o undo segment(CASO o AUM esta activo)

Para a gestão automatica da SGA, o oracle apenas deixa definir o tamanho máximo para a SGA, poder sub-divir pelos seu filhos.
NOTA: ver V$SGA_DYNAMIC_COMPONENTS

BACKGROUND PROCESSES:
Dos processos usados em background, apenas 5 são importantes, os restantes são opticionais e podem ser usados ou nao de acordo
com as componentes oracle a serem usadas.

Os 5 Background processes obrigatórios:
1 - SYSTEM MONITOR (SMON) - Efectua a recuperação da instancia, em caso de CRASH; Efectua o "COALESCE" do espaço livre da base
de dados gere-o para os sortings
2 - PROCESSES MONITOR (PMON) - Limpa as conexões falhadas dos utilizadores
3 - DATABASE WRITER (DBWn*) - Escreve nos datafiles os blocos modificados que estão na filha da SGA, a BUFFER CACHE
4 - LOG Writer (LGWR) - Escreve as transacções recuperadas da filha da SGA, a REDO-LOG_BUFFER para os redo on-line logfiles no disco
5 - CHECKPOINT (CKPT) - Efecuta a actualização dos datafiles após um evento(accção) de CheckPoint

PROCESSOS OPCIONAIS:
6 - ARCHIVER (ARCn) - Efectua a cópia da transação para recuperação que foi escrita no disco pelo
LGWR para os files online (REDOFILES) e para uma segunda localização caso seja necessario
para recuperação
7 - ...

ORACLE DATABASE , é constituida por files fisicos, tais como os control files, datafiles e redologs.
CONTROL FILE- Tem a localização dos restantes files da base de dados, nome da base de dados, blocksize, charater set
e informação de recuperação, sendo necessário pelo menos 1 para abrir a base de dados.
REDO log, Guardam todas as transações efectuadas na bd, de forma a ser possivel a recuperação.

TBS necssários para bd 10g:
SYSTEM - armazana o dicionário de dados e codigo pl/Sql
SYSAUX - armazena os componentes opcionais da bd
TEMP - SORTs

REDOLOGS , estes devem de ter pelo menos 1 membro e dois grupos.
O processo responsável de escrever nos redo logbuffer para os redo logfiles, é o LGWr sendo essa escrita accionada nas seguintes
condições:
a) cada 3 segundos
b) commit é invocado pelo user
c) redo-log-buffer tem 1/3 ocupado do seu espaço
d) redo-log-buffer tem 1Mb de informação
e) antes do checkpoint acontecer pelo DBWR

DATAFILES:
O user process, é o processo responsavel em pegar na informação para ser alterada e coloca-la na buffer cache, se a transação for
terminada com um COMMIT, então os dados a serem escritos (DBRWn) no datafile é a informação resultante da transação, caso seja rollback
então a informação será reposta a apartir do Buffer Cache da SGA.

REDOLOGS
Local onde é gravada toda e qualquer transação efectuada pelos user, por forma a ser possivel refazer em caso de crasch mesmo antes do commit;
Essa operação é efectuada pelo LGWR, geralmete estão multiplexados ou copiados, conhecido por "REDO LOG GROUPS"(minimo 2). Sendo necessario
cada grupo ter 1 ou mais elementos.
Como o funcionamento é circular, o tempo de recuperação baseia no tempo da volta de cada redo group, assim sendo a informação para recuperação
está limitada ao retention time e ao temanho do proprio redo.
A solução para armazenar todas as transações efectuadas seria usar os archives logs. cujo iriam ter toda a informação que cada redo group tem
antes de voltar a escrever por cima...

------------------------------------INSTALAÇÃO

Requisitos para o 10G

Disco Rigido:
1,5 Gb - Software oracle
1Gb - Basic Database
SWAP - 1 Gb ou 2* RAM
TEMP - 400 Mb
Memoria
RAM - 512 Mb

OFA - OPTIMAL FLEXIBLE ARQUITECTURE (by default)

CRiar uma conta no S.O.(tipicamente: oracle, ora10g, ora101)
Criar um grupo : dba

$ORACLE_BASE :- Directorio de TOPO do software Oracle
$ORACLE_HOME :- Directorio onde o software 10G vai ser instalado

UNIX:
Quando necessario pode-se criar um link simbolico para o pfile apartir do $ORACLE_HOME/dbs para $ORACLE_BASE/admin/PROD/pfile/:
ln -s $ORACLE_BASE/admin/PROD/pfile/initPROD.ora $ORACLE_HOME/dbs/initPROD.ora

WINDOWS:
Criar um file identico com uma unica linha:
ifile=D:\oracle\admin\PROD\pfile\initPROD.ora

Variaveis que precisam de ser configuradas antes da instalação:
$ ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
$ ORACLE_HOME=$ORACLE_BASE/product/10.1.0; export ORACLE_HOME
$ PATH=$ORACLE_HOME/bin:$PATH; export PATH
$ LD_LIBRARY_PATH=$ORACLE_HOME/lib; export LD_LIBRARY_PATH
$ DISPLAY=192.168.1.100:0.0; export DISPLAY

e depois
$ /cdrom/runInstaller

-----------------------------------CRIAR E CONTROLAR UMA BASE DE DADOS

FRAMEWORK DO ENTERPRISE MANAGER:
Todas as comunicações efectuadas entre a frameqwork do Oracle EM, são controladas pelos ORACLE MANAGEMENT AGENTS. São estes que tem a
responsabilidade de recolher informação sobre todas as entidades de interesses ligadas à framework.
Geralmente cada agente posiciona-se em cada host onde está instalado um componente ORACLE, armazenado posteriormente num repositório
de informação designado por "MANAGEMENT REPOSITORY".

Oracle Enterprise Management Framework subdivide-se nas seguintes partes:
MANAGED TARGETS / MANAGEMENT SERVICE / ORACLE MANEGEMENT REPOSITORY / ORACLE ENTERPRISE MANAGER 10G Grid CONTROL / ORACLE ENTERPRISE
MANGER 10g DATABASE CONTROL / APPLICATION SERVER CONTROL

a) MANAGED TARGETS -> Consegue administrar os seguintes targets ( Bases de dados; Aplication servers; Web Servers; Aplications;
Oracle agents; Listener; Connection Manager.
Pode-se adicionar e remover deacordo com as necessidades. Muitos destes "Targets" ja comunicam por defeito com o
ORACLE ENTERPRISE MANAGEMENT FRAMEWORK

b) MANAGEMENT SERVICE -> É um serviço baseado num componente em JAVA, que tem por carateristica ser o interface usado pelo user
para monitorizar e gerir os "Targets" dentro da OEMFramwork.

c) ORACLE MANEGEMENT REPOSITORY -> Local onde é armazada toda a informação recolhida dos "TARGETS" e de administradores. Esta informação é guardada
em dois TBS. Os MANG. AGENTS comunicam com o MANGEMENT SERVICE para colocar a info no repositorio organizado.

d) ORACLE ENTERPRISE MANAGER 10g Grid Control -> Deve de conseguir administrar várias bases de dados, servidores de aplicações, servidores web
e outros componentes que o EM10gGC possa usar. Tem um interface WEB que comunica e ao mesmo tempo gere todos os componentes dentro dele.
O EM10gGc permite administrar e monitorizar todo o ambiente de forma integrada e de um unico local(maquinas, bds, listener, servidores
HTTP servers e aplicaçoes web)

e) ORACLE ENTERPRISE MANAGER 10g DATABASE CONTROL -> É um compoente web pertencente ao EMFrameWork, com o objectivo de gerir as bases de dados 10g
Este componente permite monitorizar e controlar uma unica instancia de base de dados ou entao um ambiente em RAC

f) APPLICATION SERVER CONTROL -> Mais outro componente Web do EM que permite monitorizar o ORACLE APPLICATION SERVER 10g
Permite apenas gerir 1 unica instancia do ORACLE APPL SERVER ou entao uma coleçãio de INSTACIAS do OAServers ou 1 Cluster de OAServers

EMCTL START/STOP AGENT -> comando para arrancar o OMAgent em cada HOST onde tem um componente para ser monitorizado.

exemplo: (/u01/app/oracle/product/10.0.1/bin> emctl start agent)

Em caso de ser satand alone instance o serviço é:

EMCTL START DBCONSOLE
EMCTL STATUS DBCONSOLE
EMCTL STOP DBCONSOLE

A gestão da base de dados via web é feita pelo seguinte link : http://hostname:portnumber/em
a porta por defeito é a 5500

Para aceder ao iesqlplus :
ORACLE_HOME%\bin\isqlplusctl start

o endereço web para aceder ao isqlplus é:
http://machine_name.domain_name:port/iSQLplus
O porto por defeito é o: 5560

NOTA:
Para analisarmos os portos que o ORACLE está a usar podemos analisar o seguinte file: PORTLIST.INI que se encontra debaixo da ORACLE_HOME/install.

USING DBCA (ORACLE DATABASE CONFIGURATION ASSISTANTE)

Opções disponiveis: - Create a database
- Delete a database
- Configure database options
- Gerir Templates

SID - Oracle sistem identifier - o nome é criado a relação entre a instancia e base de dados. Este nome apenas pode ter no máximo de 8 carateres.
E tem de ser unico no servidor.

Na instalação de varias instancias no mesmo servidor, podemos ter uma gestão centralizada caso tenhamos instalado o ORACLE MANEGEMENT AGENT
ou então separadamente umas das outras.

DATABASE CREDENTIALS:
São necessárias para definir os niveis de acesso dos utilizadores mais importantes na base de dados:
SYS -> Dono de todas as tabelas internas, que constituiem o dicionario de dados. Este user deve de estar bloqueado e nao deve ser usado para meceher em
objectos dos users.
SYSTEM -> User aditional que contem cum conjunto de vistas e tabelas para administração.

DBSNMP -> É um user apenas de leitura de perfomance da base de dados usado essencialmente pelo EM para monitorizar a bd.
SYSMAN -> É equivalente ao SYS, destinado para a gstão do EM. Tem permições par criar e modificar contras usadas no EM, como poderes para administra-lo.

STORAGE OPTIONS:
Existem 3 possibilidades de armazenamento da nossa base de dados:
1 - FILE SYSTEM
2 - AUTOMATIC STORAGE MANAGEMENT (ASM)
3 - RAW DEVICES

1 - Já conhecido tipo de file system, flexivel, onde permite por em pratica o sistem OFA
2 - Novo mecanismo de armazenamento de dados em disco, surge apartir do 10g. Este tipo de abordagem tira o onus do DBA de gerir separadamente cada
datafile, para passar o oracle a ter essa função, apenas temos de definir os desigandos DISK GROUPS. É estruturada como uma nova BASE DE DADOS.
3 - Este sistema de armazenamento, permite passar por cima do sistema operativo. O oracle passa a aceder ao hardware de forma
directa. Necessitando de ser definido previamente quais as particões dos discos que vao ser para o oracle.

RECOVERY AREA:
Oracle Flash Recover - Esta nova funcionalidade do 10g tem como principal objectivo centralizar um espaço para todos os files da base de dados
que estejam realcionados com backup/recovery. Esta area é totalmente separada das areas dos datafiles, control files, e redologs. Pode ser
usado ainda para o oracle gerir os archives logs. No uso do RMAN, ele pressupoe que a FLASG RECOVERY AREA vai ser onde ele vai ler e repor
os files necessarios para backup ou restore se for caso disso.

PARAMETROS DE INICIALIZAÇÃO:
a) Memory -- A alocação de memoria por defeito é de 40% da memoria total.
b) Sizing -- Onde se define o BLOCK SIZE da base de dados, por defeito 8Kb para bd transact e de 16kb para Data warehouses.
c) Character Sets - Onde se definie o caracter nacional, a linguagem por defeito, e o formato da data.
d) Connection Mode - ONde se define o tipo de conexoes, dedicado ou partilhas as sessoes. Por defeito é dedicado.

Eliminar uma bd manualmente:
connect as sysdba
Startup mount;
Drop database; :-)

STARTUP & SHUTDOWN A DATABASE

Para fechar e abrir uma base de dados é necessário ter um dos dois previlégios:
SYSDBA - Previlégio que dá acesso a todas as actividades na base de dados
SYSOPER - Menos "poderoso", além de permitir startup e shutdown nao permite efectuar alguma actividades de administração

Estados da BASE DE DADOS:
NOMOUNT / MOUNT / OPEN

1) STARTUP NOMOUNT -> Inicia a base de dados sem a montar. Isto é, é lido o ficheiro de configurações, é criado os processos basicos, mas
não são estabelecidas relações com a parte fisica da base de dados. Neste estado a base de dados não está disponivel para uso.
Este estado serve por exemplo para correr scripts para criar a própria base de dados. Em NOMMOUNT o CTL's ainda nao foram lidos.

2) STARTUP MOUNT -> Este estado permite a instancia conectar-se à parte fisica da base de dados. Geralmente este estado é usado para
recuperações, ou então para alterar localizações ou alterar de NOARCHIVELOG para ARCHIVELOG.

3) STARTUP OPEN -> Permite disponibilizar a base de dados para toda a gente.

4) STARTUP FORCE -> Usado em situações em que a base de dados nao consegue voltar ao estado normal, esta operação efectua um abort e
startup.

5) STARUP RESTRICT -> Este comando permite abrir a base de dados, porém apenas quem tem o previlégio de RESTRICTED SESSION é que pode aceder.
Esta operação pode ser útil para export's e import's entre outras actividades que possam necessitar esclusividade.
Para voltar a full access: -> ALTER SYSTEM DESABLE/ENABLE RESTRICTED SESSION;

- > STARTUP [NOMOUNT|MOUNT|OPEN] [PFILE/SPFILE=] [RESTRICT] <- SHUTDOWN DA BASE DE DADOS: Shutdown normal : Não são permitidas novas ligações hà base de dados A base de dados espera q todos os users se desliguem. SHUTDOWN TRANSACTIONAL: Não permite novas ligações ha base de dados. Não são permitidas novas transações. Espera q todas as transações terminem, antes de fechar a base de dados.

SHUTDOWN IMMEDIATE: Não permite novas ligações hà base de dados. As transações que ainda não foram terminadas são cançeladas, isto é, é feito rollback.

SHUTDOWN ABORT: Não são permitidas novas conexões As transações que ainda nao terminaram não são rollback. O restart seguinte obriga a recovery.

- > SHUTDOWN [NORMAL|IMMEDIATE|RESTRICT|ABORT] < - ALERT LOG FILE: Neste file são escritos as seguintes carecteristicas: Data de inicio e fecho da base de dados, erros do tipo ORA-600, erros de espaço, alterações ao parametros iniciais, aplicação de comandos do tipo ALTER SYSTEM e ALTER DATABASE. Este file, pode ser frequentemente limpo, e efectuado backup, este é o unico file q pode ser eliminado que a base de dados volta-o a criar. ---------------OBJECTOS DOS SCHEMAS & DATABASE STORAGE

a) Identificação do Segmentos, Extents e blocos de dados: Cada extent apenas pode estar num único datafile, por sua vez cada segmento pode pertencer a diferentes datafiles. Cada extent é composto pode um conjunto contiguo de blocos de dados.

Como já vimos anteriormente cada DATA BLOCK é um conjunto fixo de bytes no sistema operativo. Apenas os TBS SYSTEM e SYSAUX tem por defeito o tamanho definido na altura da criação da base de dados. Os restante podem ter diferentes tamanhos para o "BLOCK SIZE".

O tamanho do BLOCO pode variar entre 8k e 32k, porém tem de ser múltiplo do block size do STORAGE DEVICE. Em data warehouses, por norma o tamanho do bloco size é maior.

TABLESPACES: Este objectos são usados para armazenar objectos, tais como tabelas e indexes, em que sao criados segments, podendo ter 0 ou muitos segmentos. Constraints ou sequências nao ocupam segmentos, logo não estão fora do system/sysaux. É possivel colocar o TBS off-line, e recuperá-lo para um ponto no tempo, podemos, deslocar o TBS para outra base de dados, ou até mesmo coloca-lo em modo "READ-ONLY".

exemplo: CREATE TABLESPACE HR_DATA DATAFILE 'D:\oracle\oradata\ora10\HR_DATA01.DBF' SIZE 2G;

O TBS SYSAUX, é criado na migração de uma versão antiga para o 10g. O TBS SYSAUX, é usado para colocar algumas "features" do oracle.

TBS - BIGGILES - é criado num único datafile/tempfile, cujo tamanho pode atingir 2 elevado a 32 blocos. Assim o big file pode atingir os 32Tb , a usar como tamanho do blocksize 8Kb. Estes TBS são usados em BD's bastante grandes e com um número de leituras/escritas em datafiles bastante elevado, desta forma a usar os BIGFILES, consegue-se reduzir os checkpoints ganhando assim alguma rapidez.

exemplo: CREATE BIGFILE TABLESPACE hist2004apr DATAFILE '/ORADATA/PROD/HIST2004APR.DBF' SIZE 25G;

TBS - SMALLFILES - Podem ser criados diversos(1022) datafiles em cada TBS, o tamnho pode atingir 2 elevado a 22 blocos. Assim os smallfiles podem atingir cerca de 32Tb, se usarem como tamanho do bloco cerca de 8Kb.

exemplo: CREATE TABLESPACE hist2004apr DATAFILE '/ORADATA/PROD/HIST2004APR.DBF' SIZE 25G;

Se for usada a tecnologia OMF, apenas basta definir o seguinte: CREATE TABLESPACE hr_data; Que a estrutura a ser criada vai ser a que se encontrar definida no seguinte parametro:

SQL> ALTER SYSTEM SET db_create_file_dest = 'D:\oracle\oradata\ora10\OMF' SCOPE=BOTH;

ESCOLHA da Gestao dos Extent's: Existem duas forma de escolher os TBS:
a- local extent mangement (faz uso de bitmaps)
b - dictionry extent manegement (este processo gera sql recursivo)

Na opção de local extent management, podemos ter duas opções de alocação dos extents (Uniform / AUTOALLOCATE)
1- Na UNIFORM, a base de dados aloca e desaloca os extents sempre da mesma forma e com o mesmo tamanho. Esta variação é definida, normalmente para os TBS TEMP e não pode ser usada para os TBS do tipo UNDO.
2- Na AUTOALLOCATE, a base de dados varia na alocação dos extents dentro dos segmentos. ESCOLHA da Gestão dos Segmentos: Existem duas formas possíveis:
a - MANUAL (por razões de compatibilidade) Este método usa as "FREE LISTS" para identificar os blocos livres, conjuntamente com o PCT_FREE e PCT_USED, por forma a controlar quando um bloco está disponível para inserts.
Depois de cada INSERT ou UPDATE a base de dados compara o espaço livre que sobra com o parâmetro PCT_FREE, se a percentagem for menor do que a especificada, significa que está quase cheio, é retirado 1 block das FREE LISTS, sendo esse espaço reservado para posteriores updates da linha desse mesmo bloco de dados.
Depois do INSERT ou UPDATE tb é validado o parâmetro PCT_USED, sendo este para comparar com o espaço efectivamente livre no bloco de dados, caso o espaço q tenha livre seja inferior, o data block é "limpo" o suficiente para INSERTS, sendo ainda acrescentado na lista de blocos livres (FREE BLOCK LIST)

b - AUTOMATIC (é usado BITMAPS) Os atributos PCT_USED e PCT_FREE são ignorados.
Reduz a manutenção e é recomendado pela ORACLE.
Em vez de serem usadas listas para identificação de blocos livres são usados BITMAPS, para identificarem blocos livres para INSERTS.

exemplo: CREATE TABLESPACE hist2004apr DATAFILE '/ORADATA/PROD/HIST2004APR.DBF' SIZE 25G EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT AUTO;

CREATING TEMPORARY SEGMENT:

Este TBS é usado para criar segmentos de carácter TEMPORÁRIO. As operações que podem provocar esta alocação são as seguintes:
- GROUP BY
- ORDER BY
- CREATE INDEX
- HASH JOINS
- INSERTS EM TABELAS TEMPORáRIAS

exemplo: CREATE TEMPORARY TABLESPACE temp TEMPFILE 'C:\ORACLE\ORADATA\ORA10\TEMP01.DBF' SIZE 2G;

Este TEMPORARY TBS não gera redo logs nem precisa de ser "BACKED UP"

NOTA: uma técnica para usar o espaço todo do temp em disco, é criar um TBS normal, e elimina-lo, e de seguida criar o TEMP TBS, com a clausula REUSE. CREATING UNDO TBS Este TBS, aloca os designados UNDO SEGMENTS.

Entre outras necessidades, a base de dados usa o TBS UNDO para:
- Rolling back da transacção explicita quando invocada o comando "ROLLBACK"
- Rolling back da transacção implicita quando a transacção falhou ou em processo de recuperação. - Reconstrução de uma imagem consistente de dados
- Reconstrução de uma corrupção lógica de dados.

Para a construção do UNDO, basta a inicialização do seguinte parâmetro : UNDO_MANAGEMENT=AUTO
e adicionar um UNDO TBS ao seguinte script:
exemplo da criação de uma base de dados:

CREATE DATABASE TEST CONTROLFILE REUSE
LOGFILE
GROUP 1 'C:\ORADATA\TEST\REDO01.LOG' SIZE 10M,
GROUP 2 'C:\ORADATA\TEST\REDO02.LOG' SIZE 10M,
GROUP 3 'C:\ORADATA\TEST\REDO03.LOG' SIZE 10M
DATAFILE 'C:\ORADATA\TEST\SYSTEM01.DBF' SIZE 500M AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED

CREATE TABLESPACE temp DATAFILE '/ORADATA/PROD/TEMP01.DBF' SIZE 2G;

-- dropping the tablespace does not remove -- the file from the file system

DROP TABLESPACE temp;
-- the keyword REUSE is needed to use the existing
-- file created in the previous steps

CREATE TEMPORARY TABLESPACE temp TEMPFILE '/ORADATA/PROD/TEMP01.DBF' SIZE 2G REUSE

Managing Tablespaces

EXTENT MANAGEMENT
LOCAL SYSAUX
DATAFILE 'C:\ORADATA\TEST\SYSAUX01.DBF' SIZE 250M AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED

EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE temp TEMPFILE 'C:\ORADATA\TEST\TEMP01.DBF' SIZE 100M AUTOEXTEND ON NEXT 100M MAXSIZE 8000M

UNDO TABLESPACE undo DATAFILE 'C:\ORADATA\TEST\undo01.DBF' SIZE 500M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL CHARACTER SET WE8MSWIN1252 NATIONAL CHARACTER SET AL16UTF16 USER SYS IDENTIFIED BY SOUPERSEEKRET USER SYSTEM IDENTIFIED BY MYSEEKRET;

Caso seja necessário criar o TBS UNDO depois da criação da base de dados teremos então:

CREATE UNDO TABLESPACE undo DATAFILE '/ORADATA/PROD/UNDO01.DBF' SIZE 2G;

Remover TABLESPACES: Existem 3 varições para o comando DROP TABLEPSACE:

DROP TABLESPACE xxxx; -> se tiver vazio
DROP TABLESPACE xxxx INCLUDING CONTENTES: -> se o TB nao tiver vazio
DROP TABLESPACE xxxx INCLUDING CONTENTES AND DATAFILES; -> para remover dados e os files do S.O.

MOVER UM TABLESPACE:
A necessiade pode ser variada, pois a colocação em READ-ONLY ou READ/WRITE, OFLINE, adicionar um datafile, coloca-lo OFLINE/ONLINE
ou alterar o estado de backup do TBS.
exmplo:
SQL> ALTER TABLESPACE velho_nome RENAME TO novo_nome;

ADICIONAR UM DATAFILE AO TBS:
SQL> alter tablespace XPTO add datafile 'caminho/nome.bdf' size xxxxM;

COLOCAR ON-LINE ou OFF-LINE:
Esta método serve para deslocar o TBS para um novo local, ou então em caso de recuperação.
Exemplo: deslocação:
1- ALTER TABLESPACE xpto OFFLINE;
2- copiar ou mover o bdf no S.O.
3- ALTER TABLESPACE receivables RENAME DATAFILE 'velho_local/xxx_nome.DBF' TO 'novo_local/xxx_nome.DBF';
4- ALTER TABLSEPACE xpTo ONLINE;

TORNAR O TBS Só de READ-ONLY
Com esta opção apenas pode ser lida informação do TBS.
exemplo:
SQL> ALTER TABLESPACE xpro READ ONLY; - Activar apenas a leitura
SQL> ALTER TABLESPACE xpro READ WRITE; - Activar leitura e escrita.

COLOCAR EM MODO "BACKUP":
Este metodo é necessário quando se efectua uma cópia online da base de dados sem ser usado o RMAN.
Este método, permite efectuar inserções, nos datafiles, atraves de CHECKPOINS, porém os cabeçalhos dos mesmos nao são actualizados.
Alguma informação também pode ser gravada nos redo logs, caso seja necessario um recovery.
Desta maneira caso haja um crash, a base de dados vai saber que é necessário efectuar algum trabalho de recuperação.

Exemplo:
SQL> ALTER TABLESPACE xptop BEGIN BACKUP;
operações...
SQL> ALTER TABLESPACE xpto END BACKUP;
Nota: caso seja esquecido de alterar de BEGIN backup para end backup, no próximo arranque a base dados vai perceber que o nº do checkpoint
nos CTLS está mais ha frente do que os datafiles, precisando assim de ser feito uma recuperação.

Tabelas sobre TABLESPACES:
DBA_DATA_FILES
V$DATAFILES;
V$TABLESPACE;
DBA_TEMP_FILES;
DBA_TABLESPACEs;

SELECT tablespace_name, file_name, bytes/1024 kbytes FROM dba_data_files
UNION ALL
SELECT tablespace_name, file_name, bytes/1024 kbytes FROM dba_temp_files;

GERACÇÃO de DDL
O package que permite gerar o DDL (DATA DEFINITION LANGUAGE) é:
DBMS_METADATA.
SELECT DBMS_METADATA.GET_DDL('TABLESPACE','USERS') FROM dual;

Trabalho com DATAFILES;
a ) resize
b ) Coloca-los online ou offline
c ) Move-los ou renomea-los
d ) Recuperá-los

Exmplo de resize manual:
SQL> ALTER DATABASE DATAFILE 'C:\ORACLE\ORADATA\ORA10\DATA01.DBF' RESIZE 2000M;

Exemplo de deslocação:
1- ofline
2- copia no S.O.
3- rename na bd (alter database rename file 'xxx' rename to 'xxxx';)
4- recover datafiles (RECOVER DATAFILE 'C:\ORACLE\ORADATA\ORA10\DATA02.DBF';)
5- online (ALTER DATABASE DATAFILE 'C:\ORACLE\ORADATA\ORA10\DATA02.DBF' ONLINE;)

SCHEMAS: - é um conjunto de objectos existentes na base de dados que pertencem a um determinado user.

Tipos de dados:
* Character
* Numeric
* Datetime
* LOB (Large Object)
* ROWID
* Binary

TABELAS
As tabelas e vistas partilham o mesmo storage, logo nao podem ter o mesmo nome.
As tabelas e indices não partilham o mesmo storage, logo podem ter nomos iguais.
As tabelas e constraints não partilham o mesmo storage, logo podem ter nomes iguais.

CREATE A TABLE FROM A SELECT:

CREATE TABLE A2 NOLOGGING COMPRESS TABLESPACE xpto
AS SELECT * FROM change_log ;

CRIAÇÃO DE TABELAS TEMPORÁRIAS:
Esta tabelas temporárias são apenas visiveis para a sessão que as crias/insere dados. Apenas se torna volátil o contéudo da tabela.
A estrutura da tabela é perssistente. Os dados desaparecem assim que é invocado o comando: "ON COMMIT DELETE ROWS" isto se for a nivel
de transação, se for a nível de SESSÃO: "ON COMMIT PRESERVE ROWS".

exemplo:
CREATE GLOBAL TEMPORARY TABLE my_session (
category VARCHAR2(16)
,running_count NUMBER
) ON COMMIT DELETE ROWS;

RENAMING TABLES:
É possivel renomear tabelas, vistas, sinonimos privados ou procedimentos, a base de dados vai alterar automáticamente todas a associações
desses objectos alterados aos indexes, grants e constraints.

Exemplo :
RENAME velho_nome TO novo_nome;
ou
ALTER TABLE velho_nome RENAME TO novo_nome;
Adicionar colunas:
ALTER TABLE change_log ADD how VARCHAR2(45);

Remover colunas:
ALTER TABLE change_log DROP COLUMN how;
ALTER TABLE change_log DROP (how,why);

Modificação de Colunas:
ALTER TABLE change_log MODIFY what VARCHAR2(250);

Constraints:
* C is for Check
* P is for Primary Key
* R is for Referential (or Foreign Key)
* U is for Unique - Nesta opção a ORACLE SUGERE Q SEJA CRIADA UM UNIKE INDEX automanticamente. Caso adicione a uma tabela
que ja tenha dados e seja dado erro é necessario efectuar os seguintes passos:
1- usar utlexcpt.sql (vai criar uma tabela designada EXCEPTIONS onde vai ser inserido a linha que foi identificada a excepation)
2- adicionar o seguinte comando EXCEPTIONS INTO exceptions
exemplo:
ALTER TABLE employees ADD CONSTRAINT uniq_payroll_id UNIQUE (payroll_id)
USING INDEX TABLESPACE indx
EXCEPTIONS INTO exceptions;

Eliminação de registos:
a) ON DELETE CASCADE - esta opção elimina as filhas
b) ON DELETE SET NULL - esta opção acualiza as filhas com NULL no campo respéctivo da constraint;
c) DEFERABLE - Consegue de certa forma violar as chaves estrangeiras.

ACTIVAR/DESASATIVAR CONSTRAINTS:
ALTER TABLE employees DISABLE CONSTRAINT mgr_emp_fk;
ALTER TABLE employees ENABLE CONSTRAINT mgr_emp_fk;
ALTER TABLE employees ADD CONSTRAINT validate_hire_date CHECK (hire_date > TO_DATE('15-Apr-1999','DD-Mon-YYYY'));
ALTER TABLE employees DROP CONSTRAINT validate_hire_date;
ALTER TABLE employees DROP PRIMARY KEY CASCADE;
ALTER TABLE employees RENAME CONSTRAINT validate_hire_date TO hire_date_check;

TRABALHAR COM INDEXES
Tipos de indices:
BTREE - Cria as chaves numa àrvore ordenada, conjuntamente com os ROWSID's (alta cardinalidade) - permite a row lock.
BITMAP - É criado um bitmap para cada chave, existe um bit em cada bitmap para cada Rowid da tabela, formando uma matriz bidimensional.
(baixa ou media - cardinalidade) - Não permite o lock há linha

exemplos:
ALTER INDEX emp_seniority REBUILD;
ALTER INDEX emp_seniority REBUILD TABLESPACE novo_tbs;
ALTER INDEX uniq_payroll_id COALESCE; - Não diminui os niveis da arvore
CREATE BITMAP INDEX state_bix ON geography (state);
CREATE UNIQUE INDEX dname_uix ON departments (dept_name);
CREATE INDEX emp_dept_nbr ON employees (dept_nbr) TABLESPACE indx;

VISTAS:
São tabelas vistuais, de queries criadas.
Algumas vistas podem ser actualizadas através de "updates", "inserts into". Estas vistas servem também para restringir o acesso a
informação a acerto utilizadores, mostrando apenas os campos autorizados.

exmplo:
CREATE OR REPLACE VIEW empv (employee_name ,department ,manager ,hire_date ) AS
SELECT E.first_name||' '||E.last_name ,D.dept_name ,M.first_name||' '||M.last_name ,E.hire_date
FROM employees E ,departments D ,employees M
WHERE E.dept_nbr = D.dept_nbr
AND D.manager_id = M.employee_id ;
DROP VIEW empv;

SEQUENCIAS: - Gera nº sequenciais inteiros, geralmente usados para chaves prímarias
CREATE SEQUENCE employees_seq START WITH 100500 NOMAXVALUE NOMINVALUE;

-------------------------- ORACLE NET SERVICE

INTRO:
É possivel escolher de entre 3 opções básicas de configuração de redes, na definição de uma arquitectura ORACLE:
a) SINGLE TIER - Associadas aos ecras verdes e a main frames aplications.
b) TWO TIER - Associada ao uso do PC-actual, designda por arquitectura cliente / servidor. Esta arquitectura utiliza como protocolo
o TCP/IP(mais comum). Conseguindo tirar em parte o onus do processamento total do Servidor. Agora certas operações conseguem ser processadas
no "CLIENTE". Esta Arquitectura tem como aspecto negativo a capacidade de escability.
c) n - TIER - Esta passa pelo aperfeiçoamento da arquitectura anterior, isto é, é introduzido entre o cliente e o servidor, na designada
midleware novos interfaces, cujo o papel persiste em retirar carga tanto do servidor, como do cliente.
Alguns exemplos de componentes/funções de midleware são os "APPLICATIONS SERVERS" / "WEB SERVES", balancemento entre servidores,
gestor de transações, servir de gateway para novos sistemas, etc.

O oracle NET SERVICE, é a componente que estabelece a comunicação entre o cliente e o servidor e entre servidores.
Aspectos em ter em conta:
1 - Connectivity
2 - Manageability
3 - Scalability
4 - Security
5 - Accessibility

1) A conectividade entre clientes e servidores pode ser efectuada por dois protocolos definidos, o TCP/IP ou NIMEPIPES.
O oracle permite que seja executado em diferentes Sistemas Operativos, permite ainda desenvolvimentos em java conectarem-se ao
ORACLE via "drivers JDBC". Neste momento essa conexão é possivel através dos seguintes componentes:
- JDBC Oracle Call Interface (OCI): - Este é o driver do lado do cliente, que é usado para interagir com aplicações JAVA.
Faz uso do OCI para interagir com infraestrutura NET do ORACLE.
- JDBC thin : - Aplicação independente em java e não precisa de ser instalado no cliente.

Directório de Nomes: - Este é um método que permite os serviços serem resolvidos atraves da centralização dos nomes num repositório.
Esse repositório faz uso do protocolo LDAP(Leightweight Directory Access Protocol). Este protocolo e linguagem,
permite definir regras de como armazenar, como identificar e tratar os serviços e facilita a gestão de directórios
de informação acerca do utilizadores e de serviços ORACLE que estejam ligados. A standardização deste protocolo
permite a criação de uma interface de gestão designada por OID (ORACLE INTERNET DIRECTORY), permitindo assim segurança
e rentabilidade visto que a informação está armazenada numa base de dados ORACLE.

ORACLE SHARED SERVER
Esta é uma funcionalidade opcional, que permite a n-conexões terem transações concorrentes na base de dados, sem ser preciso aumentar
as capacidades fisicas. Este feito é conseguido atraves da criação de grupos de utilizadores e da partilha do recursos pelos mesmos.

CONNECTION MANAGER - Camada midleware que fornece as seguintes 3 funcionalidades:

1. MULTIPLEXING - permite agrupar as conexões dos utilzadores e envia-las uma única vez para o servidor oracle, reduzindo assim
o número de conexões para serem geridas.

2. NETWORK ACCESS - Permite definir regras, ao nivel do IP, autorizando ou bloqueando, ou então a nível de origem ou destino.

3. CROSS PROTOCOL CONECTIVITY - Esta funcionalidade permite que dois protocolos diferentes consigam comunicar. Sendo o
CONNECTION MANAGER o tradutor entre elas.

Mecanismos de Segurança:
- Encryptação
- Checksumming
- Biometrics
- Token cards
- Public keys - certificados de autenticação
- Single-sign-on (pwd unica)
- Kerberos - mecanismo q permite a autenticação a partir da partilha de pwd secretas entre dois sistemas.

FIRE WALLS
Neste momento existem dois tipos de mecanismos disponiveis:

IP - Filtering firewalls ->> Faz a gestão de pacotes atraves da rede regendo-se por IP's

PROXY - Base firewalls ->> Faz o bloqueio de acessos a redes "internas", isto é, a redes que têm como guardiãs as PROXY-FWlS,
servindo assim de "quador" de acessos.

TRANSPARENT GATEWAY ->> Permite ao oracle conectar-se a outras bd's não oracle.

EXTERNAL PROCEDURES ->> Procedimentos externos há base de dados, geralmente escritos em C. O ORACLE NET MANAGER, permite que esses
mesmos procedimentos sejam invocados internamete na bd por chamadas de PL-SQL. Esses procedimentos são identificados por EXTPROC,
sendo da responsabilidade do LISTENER fornecer informação necessaria para o bom funcionamento dos mesmos.

CONFIGURAÇÃO DE UM LISTENER:
Listener ->> É o componente que estabelece a ligação entre os entervinientes oracle na rede e a base de dados.
O listener faz uso de um único ficheiro designado por LISTENER.ORA, sendo apenas possivel existir um por cliente.
No caso de existir mais do que 1 por servidor, tem como funcionalidades o "LOAD BALANCE" de serviços, por forma a minimizar os
custos de acessos, ou então por cofigurações de "FAIL-OVER".
Cada listener tem o nome do processo que pode estar a correr no "servidor" ou então na "middle-tier server". O nome por defeito que
é atribuido ao listener na sua criação é: LISTENER

COMO O LISTENER RESPONDE AO PEDIDOS DE CONEXÃO?
O listener ao fim de estabelecer a conexão como o servidor, passa o controlo da sessão para o servidor, no caso de ser um ambiente
em que o servidor é dedicado (DEDICATED SERVER) então temos um processo do lado do servidor para cada cliente. Estes processos
não são partilhados entre os clientes. Para este tipo de ambiente podemos destinguir dois métodos de ligação:
a) DIRECT - possivel quando o cliente e servidor estão na mesma máquina.(conhecido por BEQUEATH [direct handhoff conections])
b) REDIRECT - possivel quando o cliente e o servidor estão em máquinas diferentes

Ambos tratam separadamente as sessões.
Para ligações remotas que usem o metodo DIRECT, o listener tem de estar fisicamente activo no mesmo local do servidor de base de dados.

Porém também é possivel o listener passar a ligação para um "DISPATCHER" - Este método apenas é possivel ser tivermos perante um
ambiente em que o servidor é partilhado (SHARED SERVER). Neste ambiente continua a existir dois métodos de ligação:
a) DIRECT
b) REDIRECT
Neste ambiente o listener pode nao estar fisicamente activo no mesmo servidor de base de dados. Existindo tb o dispatcher que pode
ser usado como intermediario entre o cliente e servidor.

GESTÃO DE LISTENER:
A gestão de listener pode ser feita via EM, ou ORACLE NET MANAGER ou então a usar a linha de comando : LSNRCTL
1 - NETMANAGER pode ser lançado via windows ou então via linha de comando: $ORACLE_HOME/bin -> ./netmgr
No net manager, temos a possibilidade de criar 3 tipos de files.
- SQLNET.ORA
- LISTENER.ORA - Os seus nomes tem de ser unicos e as portas distinctas. Posteriormente pode ser adicioanado as bds que vai servir.
- TNSNAMES.ORA
2- EM -Enterprise manager (web)
3- LSNRCTL (linha de comando)

Registo dinamico de serviços:
O PMON é o serviço das bases de dados que é responsável pelo registo da sua base de dados no listener. Quando é feito dinamicamente
esses serviços não são visiveis no file LISTENER.ORA, para tal é necessário correr LSNRCTL SERVICES.
Este registo é efectuado automaticamente se o listener por defeito estiver configurado. Ou então definir no INIT.ORA os seguintes
parametros:
(LOCAL_LISTENER=destino_listener)
(SERVICES_NAMES=nome_serviço)
(INSTANCE_NAME=nome_instancia)
exemplo:
local_listener="(ADDRESS_LIST = (Address = (Protocol = TCP) (Host=weishan) (Port=1522)))
Instance_name = DBA
Service_names = DBA.GR.COM

NOTA: caso nao seja usado "DOMAIN-NAMES" os dois parametros (INSTANCE/SERVICE) devem de ser iguais.

Configurações Possíveis com a utilização vários LISTENERs
1 - CONNECTION-TIME FAILOVER
Este funcionalidade permite aos clientes poderem ter outro listener disponivel em caso do primeiro não estabelcer a comunucação com a bd.
exemplo:
ORCL =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=DBPROD)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=DBFAIL)(PORT=1521))
)
(CONNECT_DATA=(SERVICE_NAME=PROD)(SERVER=DEDICATED)
)
)

Nota: o tempo necessário até escolher o listener secundário é parametrizavél pelo sistema.

2- TRANSPARENT APPLICATION FAILOVER (TAF)
Esta funcoinalidade é usada em ambientes em que a disponibilidade é essencial, por exemplo em ambientes que usem
RAC (REAL APPLICATION CLUSTER)
Neste método caso exista uma falha no momento de um da execução de um "select" permite que a sessão efectue o "RECONNECT"
e prossiga com a operção em curso(SELETC). Este método faz uso da libraria OCI do oracle.
exemplo:
ORCL =
(DESCRIPTION=
(FAILOVER=ON)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=DBPROD)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=DBFAIL)(PORT=1521))
)
(CONNECT_DATA=(SERVICE_NAME=PROD)(SERVER=DEDICATED)
(FAILOVER_MODE=(TYPE=select)(METHOD=basic))
)
)

3- CLIENTE LOAD BALANCING
Esta funcoinalidade permite que o ORACLE NET MANAGER, consiga gerir todas as conexões dos clientes pela listas de entradas dos listener,
permitindo assim uma gestão mais balanceada, não carregando apenas um focal-point.

exemplo:
ORCL =
(DESCRIPTION=
(LOAD_BALANCE=ON)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=MWEISHAN-DELL)(PORT=1522))
(ADDRESS=(PROTOCOL=TCP)(HOST=MWEISHAN-DELL)(PORT=1521))
)
(CONNECT_DATA=
(SERVICE_NAME=ORCL)
)
)

NOTA: Geralmente o LOAD BALANCING exite no ambiente SHARED- SERVERS e com os DISPATCHER activos.

Exemplo de analise de problemas:
- ping
- tnsping
- hostname
- adaptars -> $ORACLE_HOME/bin ./adapters oracle
- Time outs de Rede - podem gerar os seguintes oras: ora-12535 / ora-12547, surgem geralmete antes do cliente se conectar com o listener.
possivel resolução -> aumentar o parametro: inbound_connect_timeout (segundos).

TRACING & LOGGING:
SERVER- por defeito o log do listener, regista as conexoes efectudas quer as que tiveram êxito quer as que nao tiveram êxito, o arranque e
fecho do listener e alguns tipos de erros de rede.
o nome por defeito é LISTENER.LOG quer em windows quer em unix

exemplos de codigos em traces de listener

nspsend: plen=12, type=4
CODE Packet Type
1 Connect
2 Accept
3 Acknowledge
4 Refuse
5 Redirect
6 Data
7 Null, empty data
9 Abort
11 Resend
12 Marker
13 Attention
14 Control information

SERVER TRACING - ON
O nivel de trace pode ser :
-- OFF
-- USER
-- ADMIN
-- SUPPORT

Exemplos de configuração:

TRACE_LEVEL_LISTENER = ADMIN
TRACE_FILE_LISTENER = LISTENER.trc
TRACE_DIRECTORY_LISTENER = D:\Oracle\ora10g\network\trace
LOG_DIRECTORY_LISTENER = D:\Oracle\ora10g\network\log
LOG_FILE_LISTENER = LISTENER.log

CLIENT TRACING - ON
Resolução de Nomes no lado do cliente,
O cliente precisa de fornecer 3 peças importantes:
1- USER ID
2- PASSWORD
3- SERVICE NAME - Fornece em forma de descriptor a localização da bd na rede, fornece ainda o nome do serviço e caminho para o
servidor de base de dados, sendo este não mais do que um alias para a base de dados. A localização desta informação varia
consuante o método de resolução que foi escolhido.
Os 5 serviços disponiveis para resolução de nomes são os seguintes:

a) ORACLE INTERNET DIRECTORY - Usado em ambientes complexos de rede com varios servidores ORACLE

b) EXTERNAL NAMING

c) HOSTNAMING - este método é bom para ambientes com poucos servidores, que usam apenas o protocolo TCP/IP e necessitam ainda de um file de "hosts"
em cada cliente, precisam ainda da configuração do GLOBAL_NAME definido no listener que deve ser igual ao nome da máquina - ficehrio produzido (SQLNET.ORA)

d) ORACLE EASY CONNECT - disponivel no 10G. Este método nao precisa de configurações no lado do cliente. alguns exemplos:
CONNECT scott/tiger@mweishan-dell:1522/orcl.
CONNECT scott/tiger@//mweishan-dell/orcl

e) LOCAL NAMING - mais conhecido e mais usado, é conhecido como TNSNAMES.ORA, a localização deste file pode ser definida para qualquer
ponto desde que a variavel "TNS_ADMIN" seja definida com o caminho. Em Windows esta definição é feita a nivel de registry no Unix
é usado o export da variavel para a sessão do user.

O service name pode ser o mais variado.

Nota: Por norma apenas é selccionando um para uso, porém a combinação deles é possível

Erros mais comuns:
ORA-12154 “TNS: could not resolve connect identifier specified”
ORA-12198 “TNS: could not find path to destination”
ORA-12203 “TNS: Unable to connect to destination”
ORA-12533 “TNS: illegal address parameters”
ORA-12541 “TNS: No listener”
ORA-12154 - Indica que o cliente nao consegue encontrar o serviço listado no TNSNAMES.ORA.
Some of the causes of this are described previously, such as the file is not in the proper directory
or the TNS_ADMIN variable is not specified or specified incorrectly.
ORA-12198 & ORA-12203 - Indica que foi encontrado um entrada no TNSNAMES.ORA cujo o respectivo serviço nao foi encontrado.
Check to make sure that the service specified in the tnsnames.ora file actually points to a valid database service.
ORA-12533 - Indica que o endereço foi espacificado incorrectamente no TNSNAMES.ora Check to make sure the syntax is correct or re-create the definition using the Oracle
Net Manager tool.
ORA-12541 - Indica que o cliente chegou ao servidor e nao encontrou um listener a escutar na porta especificada. Make sure that
the listener is started on the server and that the listening port specifications on the client and the server match.

------------------------------------SHARED SERVERS

ORACLE SHARED SERVERS - Esta arquitectura pode ser interessante quando a rentabilidade pode estar em causa, isto é, o nº de utilizadores
que precisam de se logar e o custo necessário para esse efeito não ser compatível.
Quando bem configurada pode evitar que sejam feitos upgrades adicionais aos sistemas. Vejamos os seus benefícios.

Esta configuração permite então a conectividade de várias transacções concorrentes sem que para isso seja necessário existir um aumento
de memória fisica. Essa capacidade vem da partilha de recursos para GRUPOS DE UTILIZADORES.
As transacções típicas para esta arquitectura, são aquelas que a duração das transações é bastante curto. São tambem conhecidas,
como as "sessões pensantes", pois passam bastante tempo paradas(idle).

Exemplo: aplicações baseadas em WEB que usem "forms" onde a quantidade de informação é controloda e limitada, tanto no pedido há bd
(cliente -> bd), como na resposta (bd -> cliente).
Uma má candidata ao uso dos - OSS - são as DWH, visto terem queries ad-hoc, provocando assim que os data-sets retornados sejam mais
diversificados e pesados (>16Kb) e desta forma não controlados.

DEDICATED SERVER Vs SHARED SERVER:
Dedicated server -> Consiste em cada ligação há BD ter exclusivamente o seu "shadow service", disponivel até se desconectar da bd.
Shared server -> Temos um dispatcher que gere uma lista de sessões, colocando os pedidos em "request queue" dentro da SGA, onde
os shared severs vão despacha-los 1 a 1, voltado a colocar os resultados na SGA numa área designada por "response queue", onde vai
ser enviada novamente pelo dispatcher para o cliente.

VANTAGENS:
- diminuição de recursos no lado do servidor.
- reutilização de conexões, previamente já usadas a colocadas em standby
- faz uso do multiplexing e client access control(ORACLE CONNECTION MANAGER)- permitindo criar regras de acesso.

DESVANTAGENS:
- processos que lancem queries ad-hoc não são boas candidatas para esta arquitectura
- algumas funções não são permitidas:(startup/sutdown/recover(algumas operações)
- loads tipo "bulk data" não são permitidas
- indices e table rebuilds não são permitidas
- análise de estatísticas a tabelas também não são permitidas

A utilização da SHARED SERVER, involve algumas alterações a nível da configuração interna da memória do ORACLE. Provocado também
intereação diferente entre os diferentes componentes: listener - sessões - base de dados.

PGA e SGA modifications:
Na utilização de SHARED SERVER's são utilizados dois novos interfaces na memória SGA: A "REQUEST QUEUE" e a "RESPONSE QUEUE".
O "RESPONSE QUEUE" fica do lado de cada cliente e o "REQUEST QUEUE" fica do lado do servidor. Assim se tivermos 4 clientes, teremos
1 RQ queue e 4 RP queue.

Papel do Listener quando usamos a SHARED SERVER:
O LISTENER tem a função de fornecer o local do dispatcher, para este efectuar ligações, assim que receber pedidos do utilizador para
se conectar. Também tem uma lista activa de DISPATACHERS disponiveis.
O PMON, é o processso de background que tem a responsabilidade de notificar o LISTENER qual dispatcher é responsavél por cada
circuito. Passando o LISTENER a ter um conhecimento do nº total de conecções que cada dispatcher esta a gerir.
Permitindo assim efectuar um "LOAD BALANCING" dos dispatchers. Isto é, com esta técnica de LOAD BALANCE, é possível gerir a carga
que cada dispatcher tem por forma a encaminhar as novas conexões para os menos carregados.
Desta maneira tenta-se que as conexões estajam distribuidas por todos os DISPATCHERS.
O inverso deste processo é verdade, aquando a conexão com a base de dados é fechada.

CONFIGURAÇÃO DO SHARED SERVERS:
Esta configuração é possivel no momento da criação da base de dados, ou então usar o EM, após a criação da mesma, ou manualmente
usado o "INITFILE.ORA".
Com a versão, 10G, a configuração dos DISPATCHER's deixou de ser necessária, pois esta é feita automaticamente pelo ORACLE.
Uma das vantagens da configuração dos SHARED SERVERS é ser totalmente dinâmica.

Exemplo:
DISPATCHERS = “(PRO=TCP)(DIS=3)(PRO=IPC)(DIS=2)” -> 2 dispatchers para protocolo tipo IPC e 3 dispatacher's para protoclo TCP-IP

-> Como determminar o nº de dispatchers:
Number of Dispatchers = CEIL (máximum number of concurrent sessions / connections per dispatcher)

a)
Se tivermos por exmplo 500 conecções concorrentes e querendo que cada dispatcher administre 50 conexões concorrentes,
vamos precisar de 10 dispatchers. Teremos então a seguinte configuração dos DISPATCHERS:
DISPATCHERS = “(PRO=TCP)(DIS=10)”

Para determinar a quantidade de sessões concorrentes numa bd, podemos analisar a seguintes vistas:
### V$SESSION ##
-> select sid,serial#,username,server,program from v$session where username is not null;

B) Outra forma de calacular o nº de dispatchers é em determinados periodos efectuar uma contagem de users, nesta vista.
Ou então analisar a seguinte vista:
### V$LICENSE ## - "sessions highwater", este campo mostra o número máximo de users que já se ligaram na base de dados,
desde a abertura desta.

A gestão dos dispatchers é totalmente dinâmica. Podendo ser adicioando ou removido dispatchers ao existentes.

Exemplo:
ALTER SYSTEM SET DISPATCHERS=”(PRO=TCP)(DIS=5)”;
DISPATCHERS="(PROTOCOL=tcp)(DISPATCHERS=1)(POOL=on)(TICK=1) (CONNECTIONS=500)(SESSIONS=1000)"
TICK - > representa o tempo de minutos que a demora até ser considerada idle.
MAX_DISPATCHERS = (maximum number of concurrent sessions/connections per dispatcher)
MAX_DISPATCHERS = 5
ALTER SYSTEM SET MAX_DISPATCHERS=10;

O PARÂMETRO SHARED SERVERS estando a 0(zero) ou não existir, significa que o mecanismo de "sared servers" nao está implementado.
Por defeito o parâmetro quando activado está com o valor = 1.
Mais uma tabela auxiliar:

- > select * from v$shared_server_monitor;

PARAMETERS CIRCUITS -> Este parâmetro permite definir o número de circuitos virtuais de recepção e envio para as sessões.
Exemplo:
ALTER SYSTEM SET CIRCUITS = 300;

Uma maneira de realizar a gestão dos serviços é via LISTENER, para isso usamos o camando : LSRNCTL status

mais uma tabela auxiliar:
-> select name,status, messages,idle,busy,bytes,breaks from v$dispatcher;
-> select conf_indx,dispatchers,connections,sessions “SESS”,service from v$dispatcher_config where network like ‘%TCP%’
-> select * from v$queue; -> a coluna wait convém que esteja o mais próximo ou igual a zero.

Exemplo de um conexão explicita a um "servidor dedicado":
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = MJW01)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = orcl)
(SRVR = DEDICATED) # Request a dedicated connection for DBA
)
)

O net Manager é acedido via windoes por: ORACLE_NET_MANAGER
O net Manager é acedido via unix por: NETSTAT

Tunning ORACLE_SHARED_SERVERS:
Exemplo de algumas medidas a tomar préviamente:
1º examinar a perfomance dos dispatchers e dos servers process
2º Verificar que os dispatchers são suficientes para os clientes não ficarem em listas de espera para os pedidos serem respondidos.
3ª verificar que existem shared server processes, para processarem os pedidos todos.
4ª Configurar a LARRGE POOL na memoria SGA. A LP é onde é definida a UGA, cujo contém a informação da PGA da configuração de um dedicated server.
5º A Large POOL é orientada para a bd poder usa-la com grandes quantidades de memória, actualemte esta large poool não interfere na Shared pool com antigamente.

Configuração da LARGE POOL:
O parâmetro da large pool é identificado no "init.ora" por: LARGE_POOL_SIZE, sendo este um parâmetro dinâmico.
O minimo de memória possível de alocar à large pool é 300Kb o máximo é 2Gb(dependente do Sistema Operativo).

Exemplo:
ALTER SYSTEM SET LARGE_POOL_SIZE = 100M

-> select * from v$sgastat where pool = 'large pool'; - devolve o tamanho total da LARGE POOL e o máximo atingido.

Geralmente cada sessão á base de dados ocupa de large pool cerca de 1-3Mb, claro que depende pela "actividade real" de cada sessão.

Como calcular o valor total da LP:
-> select sum(value) "Max MTS Memory Allocated" from v$sesstat ss, v$statname st where name = 'session uga memory max'
and ss.statistic# =st.statistic#;

O resultado deve ser multiplicado pelo nº de users.
Caso o tamanho de LP seja insuficiente, os utilizadares poderão obter a seguinte mensagem de erro:

ORA-04031: unable to allocate 490 bytes of shared memory
("large pool","MWEIS","session heap","define var info")

sendo necessário alterar a memória dinamicamente com o seguinte instrução:

ALTER SYSTEM SET LARGE_POOL_SIZE = 51200000 SCOPE=MEMORY

Nota: o tamanho de SGA por utilizador pode ser limitada pela elaboração de profiles.

d)
Verificar a necessidade de aumentar o nº de dispatchers:

-> Select name, (busy / (busy + idle))*100 "Dispatcher % busy Rate" From V$DISPATCHER; - esta querie indica-nos o tempo em segundos
da taxa de ocupação de cada dispatcher. Sendo que a necessidade só relevante, quando a taxa dá superior a 50% de ocupação.

Sendo necessário aumentar o numero em 1 ou 2 dispatcher com a instrução:
ALTER SYSTEM SET DISPATCHERS=”(PRO=TCP)(DIS=4)”;

e)
Verificar o tempo que os users esperam por um dispatcher:
-> SELECT decode(sum(totalq),0,’No Responses’, Sum(wait)/sum(totalq)) “Average Wait time” FROM V$QUEUE q, V$DISPATCHER d
WHERE q.type = ‘DISPATCHER’ AND q.paddr = d.paddr; - Se o resultado tiver um aumento consideravel em várias amostras,
torna-se necessário tb aumentar os dispatchers.

f)
Verificar se os SHARED SERVES são suficientes:
Estas espera indica o temmpo que uma resposta permanece na RESPONSE QUEUE ha espera de ser entregue ao utilizador que a pediu.
-> Select decode(totalq,0,’No Requests’) “Wait Time”, Wait/totalq || ‘ hundredths of seconds’ “Average Wait time per request”
from V$QUEUE where type = ‘COMMON’; - Se este o valor for aumentando consideravelmente, tb deve.se aumentar os shared servers.

--------------------------------USER ADMINISTRATION & SECURITY

a) - Criar e manter contas dos utilizadores:
A criação de users é feita com o comando: -> CREATE USER
Para alterar propriedades de users, usamos o comando: -> ALTER USER

b) - Autenticação de users:
A autenticação pode ser efectuada pelas seguintes maneiras:
(1)- via password - A password é encryptada no dicionario de dados.

Exemplo: CREATE USER rajesh IDENTIFIED BY welcome;

(2)- via externa(externally) - Esta autenticação pressupõe que o Sistema Operativo já validou o user, logo não é
registado nenhuma password na base de dados. Geralmente estes users são identificados por "OPS$_xxxx".
Este prefixo é definido no 10g no seguinte parâmetro: OS_AUTHTENT_PREFIX

Exemplo: CREATE USER ops$oracle IDENTIFIED EXTERNALLY;

(3)- via globally - Este tipo de conexões requer outros tipos externos de autenticação, assim que foram validados
com sucesso na bd. Geralmente os mecanismos mais usados são os:
- Biometrics; Certificados x509; Kerberos e RADIUS

Exemplo: CREATE USER spy_master IDENTIFIED GLOBALLY AS 'CN=spy_master, OU=tier2, O=security, C=US';

DEFAULT TABLSEPACE:
Atribuido na criação de um user: -> CREATE USER rajesh IDENTIFIED BY welcome DEFAULT TABLESPACE users;
Alterar um user já existente: -> ALTER USER rajesh DEFAULT TABLESPACE users;
Alteração do DEFAULT TBS na BD total: -> ALTER DATABASE DEFAULT TABLESPACE users;

TEMPORARIO TABLESPACE:
Este Tbs é usado para ser alocado os segmentos referentes às seguintes operações de ordenação:
- ORDER BY
- GROUP BY
- SELECT DISTINCT
- MERGE JOIN
- CREATE INDEX
- Tabelas temporárias

Alteração do TBS TEMP de um user: -> ALTER USER rajesh TEMPORARY TABLESPACE temp;
Alteração do temp TBS da base de dados: -> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;
(Nota: por vezes necessário para reconstruir o TMP)

PROFILES:
Os profiles, tem dois grandes objectivos:

1-> Reforçar as questões de segurança de cada user
2-> Limitar/restringir recursos de certos users.

Alteração do profile de um user: -> ALTER USER hamish PROFILE resource_profile;

ELIMINAÇÃO DE USER NA BD:
DROP USER XPTIOO;
DROP USER XPTO CASCADE; -> Executa a eliminação recursiva de objectos do user.

PRIVILEGIOS:
Nesta versão(10g) existem 3 níveis de privilégios:
a) Objectos - permite atribuir privilegios sobre: tabelas, vistas, sequências, procedimentos e pacotes.
b) Sistema - além dos privilégios para DML e DDL, existem ainda os seguintes grupos:
alter database
alter system
audit any
debug connect session
debug any procedure
c) Roles

GRANTs: -> GRANT XXX WITH GRANT OPTION - Não funciona com os ROLES e ainda se o dono do objecto remover os grantes
todas as dependencias directas serão removidas.
Exemplo: GRANT SELECT,INSERT,UPDATE,DELETE ON customers TO sales_manager;

GRANT SELECT ON customers TO public; -> todos users da bd tem acesso ha tabela.

GRANT zzx WITH ADMIN OPTION - > permite delegar funcoes de DDL a outro user. Este nao apaga em cascata se o dono
eliminar os grants atribuidos.

ROLES:
CREATE ROLE xpto;
CRAETE ROLE xpto identified by pwd;
SET ROLE xtpo identified by pwd; -> para activação da role;
GRANT ROLE_XPTO to NOME_USER/PUBLIC; - > atribuição da role a um user/publico;
SET ROLE ALL EXCEPT hr_admin; -> excluir uma role;
SELECT role FROM session_roles; -> ver as roles da sessão activa;
SET ROLE NONE; - > desactiva as todas as roles da sessão.

Existe um parâmetro designado por: MAX_ENABLED_ROLES
que define o numero máximo de roles activas numa base de dados, para cada user.

CONTROLO DE RECURSOS
Atribuição de quotas: -> CREATE USER chip IDENTIFIED BY "Seek!r3t" QUOTA 100M ON USERS;
Alteração da quotas: -> ALTER USER bart QUOTA UNLIMTED ON USERS;

O cpu e recursos orientados à sessão, são geridas pelo PROFILE. Vejamos alguns exemplos de recursos definidos
pelo PROFILE:
- CPU_PER_CALL -> Limita em tempo o uso do cpu, por cada chamada à base de dados. Caso o tempo seja atingido
é gerado rollback da transacção e levantada uma excepção.
- CPU_PER_SESSION -> Limita em tempo o uso do CPU, mas agora ao nivel da sessão, caso o tempo seja atingido
a transação é desfeita(rollback) e é levantada um a excepção.
- IDDLE_TIME -> Define o tempo limite entre as chamadas à base de dados. Notas as long-operations nao terminam com
esta opção.
- LOGICAL_READS_PER_SESSION -> Sem uma sessão execede o volume definido de leituras fisicas a transação é cancelada.
exemplo: alter profile xpto limit logical_reads_pers_session 35000000;
- PRIVATE_SGA -> Este parametro limita o uso da SGA para ambientes MTS-SHARED SERVERS para cada user.
- SESSIONS_PER_USER -> Impede que os users estabeleçam sessoes para além das definidas neste parametro.
- COMPOSITE_LIMIT -> Este parametro define o peso medio compostos pela soma dos seguintes parametros (cpu_per_session;logical_reads
per_session;connect_time; private_sga).

- Nº LOGICAL READS (leituras lógicas) -> É a medida de trabalho executada pela base de dados enquanto executa
queries SQL. Existe queries SQL, que geram mais ou menos "LOGICAL READS" necessários para concluir o
trabalho necessário pedido pela querie SQL. Podemos dizer técnicamente que cada "LOGICAL RAED"
corresponde ao acesso físico a cada linha, identificada pelo seu ROWID(INDEXACCESS) ou então para cada
conjunto de blocos lidos (via full table scan ou index fast full scan).

Isto durante uma conexão de uma sessão há base de dados ou então uma chamada (CALL) há base de dados.
Na chamada (CALL) há base de dados, estão incluidas as seguintes fases:
-- PARSE
-- EXECUTION
-- FETCH

Geralmente estas fases são executadas implicitamente pela base de dados. Porém a usar JAVA, PLSQL ou programas OCI,
é possível efectuar uma chamada a acada uma das 3 fases anteriores de forma explicita.

Estas funcionalidades só estão disponiveis caso esteja activado o parâmetro - RESOURCE_LIMIT - com o valor TRUE.
Visto FALSE ser o default. Exemplo: -> ALTER SYSTEM DATABASE SET RESOURCE_LIMIT=TRUE scope=BOTH;
-> CREATE PROFILE agent LIMIT CONNECT_TIME 10;
-> ALTER PROFILE data_analyst LIMIT CONNECT_TIME UNLIMITED;

Restrições devem ser sempre pretendidas, por forma a não ser divulgado para cada user informação de que realmente
não precisa. Para tal, ter em atenção as seguintes condições sobre o dicionário de dados:

SELECT_ANY_TABLE -> não atribuir este privilegio a qualquer pessoa
07_DICTIONARY_ACCESSIBILITY = FALSE -> validar sempre

mais alguns exemplos que devem ser retirados do PUBLIC:
REVOKE EXECUTE ON utl_tcp FROM PUBLIC;
REVOKE EXECUTE ON utl_smtp FROM PUBLIC;
REVOKE EXECUTE ON utl_http FROM PUBLIC;
REVOKE EXECUTE ON utl_file FROM PUBLIC;
REVOKE EXECUTE ON dbms_obfuscation_toolkit FROM PUBLIC;
REVOKE EXECUTE ON dbms_crypto FROM PUBLIC;
REMOTE_OS_AUTHENT = FALSE (DEFAULT);
ALTER USER mdsys PASSWORD EXPIRE ACCOUNT LOCK; -> Expire and LOCK accounts.
Nao activar o REMOTE_OS_AUTHENT, caso passe a true a bd passa a confiar em todas as ligações externas.

Funcionalidades da PASSWORD:
"FAILED_LOGIN_ATTENTPS" -> Definde o nº de vezes que o user pode errar a password, e a
"PASSWORD_LOCK_TIME" -> Define o tempo que a conta vai estar bloqueada, caso estaja definifo como "UNLIMETD"
a conta só será desbloqueada manualmente.
Exemplo:
CREATE PROFILE agent LIMIT FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 10/1440;

"PASSWORD_LIFE_TIME" -> Define o nº de dias da validade da password
"PWD_GRACE_TIME" -> Define quantos dias é que o user vai ser notificado para alterar a password.
NOTA: se a "PWD_LIFEW_TIME" for definida e a "GRACE_TIME=unlimited", o user sempre q se loga vai ser pedido
para altera a password.

"PASSWORD_REUSE_TIME" -> Número de dias minimo, que a password pode ser usada.
"PWD_REUSE_MAX" -> Define o número minimo de vezes necessário para poder repetir a mesma pwd.
Estes dois parâmetros para ficarem desabilitados precisam que o sejam em conjunto.

"PASSWORD_VERIFY_FUNCTION" -> Usado para criar novas politicas de segurança. Este funcção a ser criada precisa
de 3 parâmetros do tipo VARCHAR2 (USERNAME, PWD_VELHA, PWD_NOVA). IMP -> Esta função tem de ser criada no user SYS.
Exemplo:
Activar o uso da função: -> CREATE PROFILE agent LIMIT PASSWORD_VERIFY_FUNCTION my_function;
desabilitar o uso da função: -> ALTER PROFILE student LIMIT PASSWORD_VERIFY_FUNCTION DEFAULT;

AUDITING DATABASE ACTIVITY:
Em 10g é possivel definir 4 niveis de auditoria:
1- AUDIT_TRAIL=NONE; -<< audit_trail="DB;" audit_trail="DB_EXTENDED;" audit_trail="SO;"> UNIx /XP -> event viewer [AUDIT_FILE_DEST=xxxxx]

Nota: este parâmetro apenas pode ser modificado a nivel de SPFILE/PFILE; O que implica um restart da bd.
(alter system database set AUDIT_TRAIL=XXX scope=SPFILE;

Como verificar os AUDITs em curso:
-> SELECT audit_option, failure, success, user_name FROM dba_stmt_audit_opts ORDER BY audit_option, user_name;

Como examinar os resultados dos AUDITs:
-> SELECT username, timestamp, action_name FROM dba_audit_trail WHERE username = 'JUANITA';

Validar quem tem o privilégio de efectuar AUDIT's:
-> SELECT privilege, user_name FROM dba_priv_audit_opts ORDER BY privilege, user_name;

Atribuir a objectos diferentes niveis de auditorias:
-> AUDIT select ON hr.employee_salary BY ACCESS WHENEVER SUCCESSFUL;

Identificar os objectos que estão a ser auditados:
-> SELECT owner, object_name, object_type, ins, sel FROM dba_obj_audit_opts WHERE owner='HR' AND object_name='EMPLOYEE_SALARY';

Remover as audits dos objectos:
-> NOAUDIT select ON hr.employee_salary WHENEVER NOT SUCCESSFUL;

Limpeza das auditorias da BD:
-> DELETE FROM sys.aud$ WHERE timestamp# <> SELECT policy_name ,object_schema||'.'|| object_name object_name,policy_column,enabled ,
audit_trail FROM dba_audit_policies;

Forma de identificar as auditorias efectuadas pelas processos FGA:
-> SELECT db_user, timestamp, userhost FROM dba_fga_audit_trail WHERE policy_name='COMPENSATION_AUD'

------------------------Gestão de dados, usado PL-SQL, SQL & Utilities

Gestão de dados, usado PL-SQL, SQL & Utilities:
Manipulação de dados a usar SQL (STRUTURED QUERIE LANGUAGE):
DDL - data definition language
DCL - data control language
DML - data modification language

USING INSERT:
O insert pode ser efectuado omitindo a lista de colunas, caso seja inserido 1 valor para todos campos,
porém a insercção vai ser efectuada por ordem de acordo com o id (ROWID) da própria coluna.

É possivel inserir tb em vistas, porém isso é válido desde que a vista não contenha uma das seguintes restrinções:
- DISTINTCT OPERATOR
- SET OPERATOR(UNION,MINUS, ...
- AGGREGATE FUNCTION ( sum, count, avg,...
- GROUP BY, ORDER BY ou CONNECT BY
- SUB-Queries

USING INSERT EM MULTIPLES TABLES:
INSERT FIRST
WHEN policy_type = 'P' THEN
INTO property_premium_fact(policy_id,policy_nbr ,premium_amt) VALUES (property_premium_seq.nextval,policy_number ,gross_premium)
WHEN p.policy_type = 'C' THEN
INTO property_premium_fact(policy_id,policy_nbr ,premium_amt) VALUES (property_premium_seq.nextval,policy_number ,gross_premium)
SELECT policy_nbr ,gross_premium ,policy_type FROM policies
WHERE policy_date >= TRUNC(SYSDATE,'MM') - TO_YMINTERVAL('00-01');

USINIG UPDATES
Exemplo:
UPDATE order_rollup SET (qty, price) = (SELECT SUM(qty), SUM(price) FROM order_details WHERE customer_id = 'XYZ')
WHERE customer_id = 'XYZ' AND order_period = TO_DATE('01-Oct-2004');

USING DELETE
DELETE line_details WHERE rowid NOT IN (SELECT MAX(rowid) FROM line_detail GROUP BY line_detail_id);

--Remove all rows from the table order_staging
DELETE FROM order_staging;

PL-SQL
Procedural Language: é uma extensão ao sql, em que estão contidos ciclos, condições de control, tratamento de excepções,
algumas funcioanalidades "Object Oriented", tais como objectos, "overloading", tipos de herança, e casting.
Estes objectos gerados dentro do PLSQL, podem ser todos codificados em linguagem binária, a usar uma
funcioanalidade com o nome: - WRAP

PL-SQL (FUNÇÕES)- executam 0 ou muitas queries e retornam um valor pela clausula RETURN. Podem receber 0 ou
mais parametros.
exmplos:
CREATE OR REPLACE FUNCTION is_weekend(check_date IN DATE DEFAULT SYSDATE)
RETURN VARCHAR2 AS
BEGIN
CASE TO_CHAR(check_date,'DY')
WHEN 'SAT' THEN
RETURN 'YES';
WHEN 'SUN' THEN
RETURN 'YES';
ELSE
RETURN 'NO';
END CASE;
END;

PL-SQL (PROCEDIMENTOS)
Executa 1 ou mais queries, podem receber e retornar valores apenas pela lista valores definida. Apenas nos
procedimentos é possivel executar procedimentos pré-definidos como por exemplo: RAISE_APPLICATION_ERROR
exemplos:
EXEC DBMS_OUTPUT.PUT_LINE('Hello world!');
CALL DBMS_OUTPUT.PUT_LINE('Hello world!');

PL-SQL (PACKAGES)
É um container para packages, funções, procedimentos e estruturas de dados como cursores, variaveis, e constantes.
As permissões de execute são ao nível do package.

PL-SQL(TRIGGERS)
Os triggers, são programas que respondem a eventos da base de dados.
Os triggers podem incluir a sintaxe: FOR EACH ROW, quando for necessario que seja tratada linhha a linha.
Os triggers não podem ser criadaos em objectos do user SYS.
Os triggers podem incluir a sintaxe: ON DATABASE, quando a accção ocorre a nível de user na base de dados.

exemplo trigger de linha:

CREATE OR REPLACE TRIGGER employee_trg
BEFORE INSERT OR UPDATE OF hire_date
ON employees FOR EACH ROW
BEGIN
log_update(USER,SYSTIMESTAMP);
IF INSERTING THEN -- if fired due to insert
:NEW.create_user := USER;
:NEW.create_ts := SYSTIMESTAMP;
ELSEIF UPDATING THEN -- if fired due to update
IF :OLD.hire_date <> :NEW.hire_date THEN
RAISE_APPLICATION_ERROR(-20013,
'update of hire_date not allowed');
END IF;
END IF;
END;

EVENTOs de um TRIGGER (DML):
INSERT - antes ou depois da inserção
UPDATE - antes ou depois do update
DELETE - antes ou depois do delete

EVENTOS de um TRIGGER (DDL):
ALTER - Quando é invocado o "alter" para mudar a estrutura de um objecto.
ANALYZE - Quando são invocadas as estatisitcas sobres os objectos.
ASSOCIATE STATISTICS - Quando são adicionadas estatisticas a uma bd, a usar o comando "ASSOCIATE STATISTICS" sobre um objecto.
AUDIT - Quando estão a decorrer as auditorias (except FGA).
COMMENT - Quando é alterado um comentario de uma coluna ou tabela.
CREATE - Quando é criado um objecto.

DDL -
DISSOCIATE STATISTICS - Quando são removidas estatisticas a uma bd, a usar o comando "DISSOCIATE STATISTICS" sobre um objecto.
DROP - Quando é invocado o comando "DROP" para eliminar um objecto.
GRANT - Quando é atribuido um GRANT.
NOAUDIT - Quando invocado para parar as auditorias.
RENAME - Quando é invocado para renomear um objecto.
REVOKE - Quando é retirado um previlegio.
TRUNCATE - Quando é invocado o comando "TRUNCATE".

EVENTOS de um trigger (BASE DE DADOS):
LOGON - Quando a sessão é estabelecida após validação do trigger.
LOGOFF - Quando a sessão é terminada com sucesso e após validação do trigger.
STARTUP - Qaundo a base de dados abre após a validação do trigger.
SHUTDOWN - Qaundo a base de dados fecha após a validação do trigger.
SERVERERROR - Qaundo uma exception é levantada apóes a validação do trigger.
SUSPEND - Quando uma transação deu erro provocando a sua suspenção.

exemplo:
ALTER TRIGGER after_ora60 DISABLE; - desactivação
ALTER TRIGGER load_packages ENABLE; - activação
ALTER TABLE employees DISABLE ALL TRIGGERS;
ALTER TABLE employees ENABLE ALL TRIGGERS;

DESCRIBE - funciona com todos os objectos da base de dados excepto os TRIGGERS.
outras funções:
A base de dados ao necessitar de um objecto que não esteja compilado, o compilador recompila-os automáticamente,
por exemplo após ter existido um comando de ALTER sobre objectos.

ALTER PROCEDURE archive_orders COMPILE;
ALTER FUNCTION is_weekend COMPILE;
ALTER PACKAGE table_util COMPILE BODY;

TUNNING PL-SQL:
* PLSQL_WARNING - ALTER SYSTEM SET plsql_warnings='DISABLE:ALL' SCOPE=BOTH;
* PLSQL_DEBUG - ALTER SYSTEM SET plsql_debug=[FALSE(PRD)TRUE(DEV)] SCOPE=BOTH;
* PLSQL_OPTIMIZE_MODE - ALTER SYSTEM SET plsql_optimize_mode=2 SCOPE=BOTH;
* PLSQL_CODE_TYPE - usado na utilização de "C".

CREATE DIRECTORYS:
Este comando permite colocar Bfiles, utl_files, tabelas externas e DATA_PUMP

EM unix:
CREATE DIRECTORY dump_dir AS '/oracle/data_pump/dumps';
CREATE DIRECTORY log_dir AS '/oracle/data_pump/logs';

EM Windows:
CREATE DIRECTORY dpump_dir AS 'G:\datadumps';

Os users apenas têm acesso a estes dir, caso sejam dados os grantes de LEITURA ou ESCRITA:
exemplo:
GRANT read,write ON DIRECTORY dump_dir TO XPTO/PUBLIC;

DATA PUMP :
Esta funcioanalida de estração de dados ou apenas de metadata(DDL), ou até mesmo a deslocação entre máquinas,
ao contrário do velho exp/imp apenas corre no lado do servidor. Usado também para copiar dados entre dois
schemas de bases de dados distinctas.
Serve tb para efectuar uma cópia integral da base de dados, cópia de schemas, cópia de tabelas, cópia de tablespaces.
A interação com esta funcioanalidade pode ser feita via linha de comando: expdp / impdp ou então via package: DBMS_DATAPUMP ou ainda
via EM.

EXPDP tem 4 modos de execução:
a) database: - toda a bd é exportada
exemplo : expdp system/secret full=Y dumpfile=full_bd.dmp, full_bd2.dmp filesize 2G parallel=2 logfile=full_bd.log;

b) SCHEMA: - toda metadata e dados do conjunto de schemas selecionados.
exemplo : expdp hr/hr dumpfile=schema.dmp logfile=schema.out; -< schemas="nome_1," dumpfile="user_tables.dmp" nologfile="y" content="metadata_only(/DATA_only)" tables="jobs,job_history;" dumpfile="chap7:users_ts.dmp" logfile="chap7:users_ts.out" tablespaces="users;" dumpfile="nome_ts.dmp" logfile="nome_ts.out" tablespaces="users" network_link="prod" schemas="HR" remap_schema="HR:HR_TEST" content="metadata_only" logfile="log.imp" keyword="valor" control="regions.ctl" userid="system/password" control="regions.ctl" segments =" rollback"> mostra as segmentos activos
select * from DBA_ROLLBACK_SEGS; -> mostra todos os estado possiveis do segmentos.

Todos os segmentos são do user SYS. Durante uma falha de media em especial do undoTBS , este pode ser recuperado através dos
archives e dos online redo-logs, porém a instância precisa de estar em MOUNT mode para recuperar o undo TBS.

Using Undo Data - > É designada pelos valores velhos, isto é, guarda os valores depois de terem sido alterados. Eis algumas operações
possiveis de efectuar:
-> User rollback of a transaction
-> Read consistency of DML operations and queries
-> Database recovery operations
-> Flashback functionality

Os inserts usam pouco espaço no UNDO SEGMET, pois apenas guardam o ponteiro para a nova row.
Algumas operações atómicas:
- SELECT statements without the FOR UPDATE clause
- LOCK TABLE
- SET ROLE
- ALTER SESSION
- ALTER SYSTEM

Para operações de recover o TBS undo é bastante importante, pois todas a transações que não foram comitadas voltam ao ponto antes de
ter acontecido o crashe.

A operção de FLASHBACK - podes ser usado apenas na imformação existente no UNDO TBS

Monitorização, gestão, configuração do UNDO TBS:
Ao contrário dos rolbacks em 9i, a administração em 10g é mínima, porém exsite duas situações a ter em conta:
1- Não existir espaço no undo para tratar de todas as transações activas.
Caso aconteça temos: "ORA-01650- unable to extend rollback segment"

2- Espaço suficiente para correr queries longas.
Caso aconteça, temos: "ORA-1555: Snapshot to old"

A configuiração do UNDO pode ser efectuada manualemte ou automáticamente. Se for manualmente é via rolback segments,
se for automáticamente é via TBS UNDO. Apenas pode existir 1 por bd, excepto na situação em que foi criado 1 novo e o velho
ainda tem transacções activas. Ficando com 2 apenas até as transacções do velho acabarem.
Caso não seja explicitamente definido na criação um TBs de UNDO, o ORACLE cria dinamicamente o TBS UNDO com o
seguinte nome: SYS_UNDOTBS

PARAMETROS ESTATICOs: -> requerem restart da bd
UNDO_MANAGEMENT-> MANUAL/AUTO
UNDO_TABLESPACE-> nome do TBS UNDO

exemplo:
raname do TBS para no novo_nome
alter system set undo_management = manual "scope=spfile" ; --"caso use spfile" --
restart.

UNDO RETENTION - determina em segundos o periodo que a informação que foi "commited" deve ficar no UNDO até ser descartada/escrita
por cima. Caso seja definido o valor 0 (ZERO), então o tamanho/tempo será definido de acordo com a querie mais longa até então.
By de default=900s == 15 minutos

exemplo:
alter system set undo_retention = 43200; (12h).
Quanto maior for o periodo definido, maior deverá ser o tamanho no TBS.

Os erros de SnapSHOT To old, significam que o undo não têm espaço suficente para o resultado das queries. Estes tipo de erros, podem
ser controlados com o parâmetro de Tablespaces (RETENTION GUARANTEE)
exemplo:
ALTER TABLESPACE UNDOTBS retention garantuee;
ALTER TABLESPACE UNDOTBS retention NOgarantuee;

O ORA-1555 também é conhecido por: "LONG QUERIE WARNING ALERT".
AS alterações a nivel do periodo de rentenção só fazem efeito assim que passarem 24h. REcebendo um alert em cada 24h.

exemplos tunning manual:
tamanho que deverá ter o undo_tablespace_size =>
(Undo_Retention_parameter * Undo_Blocks_per_Second * BLOCK_SIZE_BD ) e podes adicionar 15% como folga.
select to_char(begin_time,'yyyy-mm-dd hh24:mi:ss') starttime, to_char(end_time,'yyyy-mm-dd hh24:mi:ss') endtime, undoblks, maxquerylen/60 temp_Min,
tuned_undoretention/60 und_ret_Min from v$undostat ;

MONITORIZAR LOCKS:
Na bd 10g é possivel realizar transações que efectuem LOCKs a nivel de linha, várias linhas ou à tabela completa.
Os locks activos, são desfeitos assim que é invocado implicitamente ou explicitamente um dos seguintes comandos:
COMMIT:
ROLLBACK:
A Naturaza do Locks baseia-se em accções sobre determinados objectos, sendo esse funcionamento baseado na técnica FIFO, para
realizar o lock, mantendo os restantes em lista de espera, até esse objecto pretendido estar liberto.

NOTA:
SQL> @?/rdbms/admin/utllockt.sql -> permite detectar locks na base de dados.

TIPOS DE LOCKS A TABELAS:

ROW SHARE - > Permite acessos concorrentes à tabela em lock, mas proibe que outros users de bloquearem a tabela toda em modo EXCLUSIVE.

ROW EXCLUSIVE -> Igual ao ROW SHARE, mas proibe o bloqueio em modo SHARE. Este tipo de lock é activado automaticamente quando usado
um dos seguintes comandos DML: UPDATE, INSERT, or DELETE.

SHARE -> Permite queries concorrentes, mas proibe UPDATES à tabela. Este modo é automáticamente invocado na criação de indexes
(CREATE INDEXES...) sobre a tabela.

SHARE ROW EXCLUSIVE -> Usado para queries sobre a tabela toda, permitido a outros users lerem a tabela inteira, mas
mas impede que os outros users bloqueiam a tabela em modo SHARE ou façam UPDATES.

EXCLUSIVE -> O Modo mais restrito de bloqueio; Permite que as queries realizadas bloqueiem a tabela, mas proibe, qualquer tipo
de operação DML por parte de qualquer user. Este modo é usado quando se elimina uma tabela e é automaticamente acionado assim que
invocado o comando DROP TABLE.

exemplo de bloqueio manual:
select * from hr.employees where manager_id = 100 for update;
so termina com um commit ou rollback.

NOWAIT MODE:
Permite ao user saber de immediato se o objecto pretendido está em modo de locking ou não. Evitando assim entrar para a fila de
espera (FIFO) para poder aceder ao objecto.
a usar este comando "NOWAIT" permite que a linha de comando seja devolvida ao user de imediato.
exemplo:
lock table hr.employees in share row exclusive mode nowait;

lock table hr.employees
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified

DEADLOCKS:
São tratados pela base de dados.

---------------------- MANUTENÇÃO e TUNNING PROACTIVO

Foram introduzidas novas funcioanlidades na versão 10g, para monitorias e advisores:
ADDM - AUTOMATED DATABASE DIAGONOSTIC MONITORING
AWR - AUTOMATIC WORLOAD REPOSITORY
Tunnig Oracle Advisores

AUTOMATIC WORLOAD REPOSITORY:
Para o AWR, foram introduzidos dois novos processos de background:
- MMON (MEMORIE MONITOR)
- MMONL (MEMORIE MONITOR LIGHT)

Estes dois processos, trabalham em conjunto por forma a recolher estatisticas da SGA. O PERIODO DE ACTIVIDADE
do MMON é a cada 60 minutos. Com um periodo de retenção de 7 dias de informação.

Toda esta informação é guardada no AWR, cujo o dono é o SYSMAN, dentro do TBS SYSAUX.

A activação desta funcionalidade, depende do parâmetro STATISTIC_LEVEL = BASIC/TYPICAL/ALL
BASIC: - Desactiva o AWR e a colecta da maioria das estatisticas, e de todos os advisores, raramente são analisadas
as estaticas dentro do intervalo definido.
TYPICAL: - Activa a colecta "STANDARD" para as bd's, sendo esta, suficiente para a maiorias das bases de dados.
ALL: - Compila todas as estatisticas definidas pelo opção "TYPICAL", mais os tempos de execução conjuntamente com
informação do S.O.

O pacote DBMS_WORKLOAD_REPOSITOY - permite gerir os parâmetros do AWR referentes a periodos de colecta e de retenção.
Exemplo:
SQL> execute dbms_workload_repository.modify_snapshot_settings (interval=>60,retention=>43200);
significado: (activa a snapshot de hora em hora com um retenção de 30 dias).

AUTOMATIC DATABASE DIAGNOSTIC MONITORING (ADDM)
Este novo processo, executa comparações entre snpahots tiradas pelo AWR, permitindo assim a identificação de
potenciais problemas na base de dados, quer no S.O. quer engarrafamentos de I/O, demasiada utilização de recursos, provenientes de SQL's ou PL/SQL, contenção gerada por locks e finalmente a utilização da SGA pelo Oracle.

Basedo nestas analises o ADDM pode sugerir alterações com o objectivo de reduzir o tempo de resposta da base dados, mais conhecido por "BD-TIME".

Esta "BD-TIME" é IDENTIFICADO essencialemte pelo NON_IDLE_TIME dos utlizadores, que é composto por:
CPU-TIME + WAIT-TIME

Toda esta informação a guardada, por forma a existir metricas de utilização quer de processos de utilizadores, quer pelo respectivo consumo de CPU, SGA usada e I/O necessário.

Uma maneira pratica de analisar os resultados obtidos é usar o "EM Database Control".
ANALISE de EVENTOS: No. B10755-01
ANALISE MANUAL ADDM:
SQL> @?/RDBMS/Admin/addmrpt.sql
VISTAS com informação da analise ADDM:
-DBA_ADVISOR_FINDINGS
-DBA_ADVISOR_OBJECTS
-DBA_ADVISOR_RECOMENDITIONS
-DBA_ADVISOR_RATIONALE

Exemplo de querie:
a) SELECT task_id, type, message
FROM dba_advisor_findings
WHERE impact=(select MAX(impact) FROM dba_advisor_findings);

b) SELECT attr4 FROM dba_advisor_objects WHERE task_id = XPTO;

c) SELECT TRIM(attr1) ATTR1, TRIM(attr2) ATTR2, TRIM(attr3) ATTR3
FROM dba_advisor_actions
WHERE task_id = XPTO;

d) SELECT message FROM dba_advisor_rationale WHERE task_id = XPTO;

ADVISORES de Diagonóstico existente no ADDM:
- SQL Tunning Advisor
- SQL Access Advisor
- Memory Advisor
- Mean Time To Recover Advisosr
- Segment Advisor
- Undo Management Advisor

SEGMENT_ADVISOR:
Permite identificar quais os segmentos disponiveis a libertarerm espaço não necessário.
Esta funcioanlidade está disponivel para duas formas:
1) TABLESPACE LEVEL
2) SCHEMA LEVEL

Ambos podem ainda ser definidos como:
a- Compreenhsive
b- Limited

A possibilidade de efectuar um shrink, apenas é possivel se a opção de ROW-MOVEMENT estiver definida no objecto.
Só desta forma a libertação dos extents será possível.

UNDO MANAGEMNT ADVISOR:
Este Advisor, baseia-se no TBS UNDO, serndo necessário para as seguintes operações:
a - Na execução de trasações, landaçadas por operações DML, é copiado para uma parte da SGA identificada por "DATABASE BUFFER CACHE" uma imagem do estado dos dados antes de qualquer operação.
b - É copiado também para o "undo segement" a mesma imagem antes da alteração dos dados, pelo DML invocado, sendo
este mantido no TBS UNDO.

Ambas cópias tem os seguintes objectivos:
1- é usado para repor a imagem dos dados caso o user execute "ROLLBACK".
2- é usado para mater uma imagem coerente aos restantes users, visto que ainda não foi executado "commit";
3- é usado em caso de necessidade de recuperação da base de dados, pois repoe a imagem dos dados, no momento antes do crash. Desfazendo todas as transacções que ainda não foram completadas com o "COMMIT";

Assim que são assignadas transações a segmentos do undo, não existe a possibilidade de ser trocado por outro mais favorável para essa transacção.

Um dos erros mais comuns, resultantes do uso do undo, é o ORA-01555-SNAPSHOT TO OLd, ou sejam
algum utilizador que precise de efectual dml a dados, esses são colocados no undo, porém outro user está a ler esses mesmos dados, criando assim uma inconsistencia visto o undo não ser in finito em termos de espaço.

Fontes de informação para TUNING:
- ALert log
- Backgroung & User Traces
Tunning manual usando a o trace file 10046:
Ver nota: 171647.1

- Vistas de perfomance Dinamicas

- Vistas do dicionários de Dados
Rebuild um Index, necessita de uma vez e meia (1.5), de espaço para o próprio index poder ser recompilado.

Armazanamento de ESTATISTICAS NO DICIOANÁRIO DE DADOS
O preenchimento de estatisticas como o tamanho da linha, blocos vazios, tamanho médio da linha, entre outros, apenas é preenchida assim que a respéctiva tabela for analisada.

O optimizador do ORACLE, baseado em custo, mais conhecido por CBO é gerido pelas estatisticas que cada objecto tem armazenado no dicionário de dados, por forma a escolher o melhor plano de execução com o mais baixo custo para determinda operação.
Método de recolha de estatisticas:
AUTOMÁTICO - Caso a BD tenha sido criada com com DABASE CONFIGURATION ASSISTENT GUI
Por defeito são 10% do volume da tabela que analizado.
MANUAL
Neste método podemos usar o package- DBMS_STATS, que nos permite efectuar um conjunto de opções mais alargado comparativamente com o método "COMPUTE STATISTICS".

Funcionalidades:

* Eliminar estatisticas
* Efectuar backup das estatisticas
* Efectuar reposicção total ou parcial
* Executar as estatisticas em parallelo
* Executar as estatisticas sobre : TABELAS / INDEXS / SCHEMAS / BASE DE DADOS
- GATHER_INDEX_STATS > Gathers statistics on a specified index
- GATHER_TABLE_STATS > Gathers statistics on a specified table
- GATHER_SCHEMA_STATS > Gathers statistics on a specified schema
- GATHER_DATABASE_STATS > Gathers statistics on an entire database

Exemplo:
SQL> EXECUTE DBMS_STATS.GATHER_TABLE_STATS (‘SH’,’PRODUCT_HISTORY’);

------------------------------Implementação de BACKUPS

O objectivo principal, é manter a base de dados o máximo de tempo disponivel, e ter sempre disponivel uma hipotese de recuperação da base de dados, de uma forma rápida e mais recente possivel.

Para isso existem vários itens a ter em conta:
1- Proactivamente resolver problemas correntes
2- Aumentar o tempo entre falhas (MTBF)
3- Garantir que o hardware tem altos niveis de redundancia
4- Aumentar a disponibilidade através da implementação de ORACLE-RAC e ORACLE_STREAMS(tecnologia avançada de replicação)
5- Diminuir o tempo médio de recuperação, através da configuração de parâmetros, e garantir que os backups estão disponiveis.
6- Minimizar ou se possível eliminar transacções ja "COMMITED", através do uso de archives, dos redo logs, standby databases e ORACLE DATA GUARDs.

CONFIGURAÇÃO DOS COMPONENTES DE RECUPERAÇÃO

Um dos ficheiros mais importantes, é o "CONTROL-FILE", pois é neste ficheiro que é registado os ficheiros que pertencem à base de dados é onde é registado os backups mais recentes que foram executados(CASO seja usado o RMAN).

Os processo de background CKPT e o DBWn, são os responsáveis pelo tempo necessário para a recuperação da base de dados.
Durante a recuperação são usados os redo-logfiles para ser efectuada uma sincronização com os datafiles.

No caso de uma crash mais sério, tipo media, os archives redo logs, serão aplicados para uma reposição do datafiles, de forma a que todos fiquem sincronizados no tempo, tentando que nao sejam perdidas transações ja "commited".

A partir do 10G existe uma area designada por "FLASH RECOVERY AREA", que é usada para todas a operações de recuperação, ou de backup.

ARQUITECTURA do CONTROL FILE
É um ficheiro binario, geralmente não passa dos megas, onde está armazada a estrutura da base de dados, podemos disigna-lo como o repositório da metadata da nossa base de dados física.
Tem guardado a estrutura dos datafiles e redo-logfiles, é criado no momento da criação da base dados, é actualizado sempre que existe uma alteração a nivel da estrutura de um datafile (renomeação). Além destas actualizações é constantemente actualizado, e tem de estar sempre disponivel, e nunca deve ser editado, o local no disco nao pode ficar sem espaço caso contrário a bd será fecada automaticamente.
Este file é lido no momento da abertura da base de dados, por forma a serem identificados os redo-logfiles e datafiles respectivos.

O control-file tem um papel fundamental nas reposições da base de dados, pois nele encontra-se a seguinte informação:
- nome da base de dados cujo o CTL pertence.
- data da criação da base de dados.
- nome, localização, estado(online/offline) de cada datafile
- nome e localização dos redo logfiles
- informação dos redo log archive
- Nome dos TABLESPACES
- O numero "CURRENT" sequêncial e único que é gerado sempre que existe um switch dos redo-logfiles.
- A informação mais recente do ultimo chekpoint
- O inicio e fim do segmentos undo
- Informação relativa aos backups via RMAN

O tamanho do controlfile é determinado pelo definição do conjunto dos seguintes parametros:
+ MAXLOGFILES
+ MAXLOGMEMBERS
+ MAXLOGHISTORY
+ MAXDATAFILES
+ MAXINSTANCES

O oracle consegue alocar espaço, deacordo com os parametros pré-definidos. Devido a isso sempre que existe uma renomeação ou até mesmo a adição de um datafile, o tamanho do CTL não varia, desde que se encontre dentro dos parametros definidos.

O CTL sempre que existe uma alteração estrutural na base de dados, é feito uma actualização e efetuado um backup ao CTL, O processo de background responsável de actualizar o CTL com actual "SEQUENCIAL NUMBER" dos LOGFILES é o LGWR.

O processo CHKP, actualiza o CTL com o Chekpoint efectuado na base de dados mais recente.
Caso a BD esteja em modo de ARCHIVE (ARCHIVEMODE ON), o processo responsável de actualizar o CTL com o nome e o número sequêncial do archive gerado, é o ARCn.

O ficheiros CTL são constituidos por duas seccções destintas.
Uma que é reutilizável e outra que não é reutilizável (estática).
A reutilizável é gerida de forma circular. Nesta secção é guardada informação relativa ao RMAN, informação essa relativa ao nome dos datafiles que são guardados, isto é, feito backup, via RMAN.
Porém esta informação está diponivél, apenas durante o valor definido no seguinte parametro: CONTROL_FILE_KEEP_TIME,
sendo este parametro que delimita o tamanho do CTL.

MULTIPLEXING CTL
Devido à criticidade do file CTL, são necessários no minimo 2 files CTLs, porém a recomendação da ORACLE é que existam 3 files CTL's, aconcelhando ainda que estejam fisicamente posicionados em sitios diferentes.

A configuração desta disposição dos CTL's pode ser efectuada via DBCA, ou então via INTI.ORA.

INIT.ORA:
CONTROL_FILES = (‘/ora01/oradata/MYDB /ctrlMYDB01.ctl’,
‘/ora02/oradata/MYDB/ctrlMYDB02.ctl’,
‘/ora03/oradata/MYDB/ctrlMYDB03.ctl’)

IMP-> A instância actualiza todos os CTL's definidos, porém apenas lê o 1º para levantar a bd.

Exemplo de adição mais CTL's à bd:

1. SHUTDOWN
2. Cópia de um CTL para o novo sitio
3. Alteração do parametro CONTROL_FILES no init.ora
4. STARTUP

SPFILE.ORA:
Esta alteração fisica é efectiva apenas depois da base de dados ter feito reboot.
1-SQL> ALTER SYSTEM SET CONTROL_FILES = ‘/ora01/oradata/MYDB/ctrlMYDB01.ctl’,
‘/ora02/oradata/MYDB/ctrlMYDB02.ctl’,
‘/ora03/oradata/MYDB/ctrlMYDB03.ctl’,
‘/ora04/oradata/MYDB/ctrlMYDB04.ctl’ SCOPE=SPFILE;

2- shutdown
3- cópia fisica dos CTL's
4- Startup

CHECKPOINTS
O processo de background de checkpoint é responsável por controlar o tempo necessário para efectuar a recuperação da base de dados.

Durante o processo de CKPT é actualizado o cabeçalho de cada datafile(tanto nos OFFLINE como nos READ-ONLY). Esta alteração do cabeçalho dos CTL'S, ter por objectivo refletir as últimas transações realizadas na bd. Este registo é efectuado com o SCN (SYSTEM CHANGE NUMBER), que representa sequencialmete cada transação da base de dados.

Novamente, um checkpoint é algo similar aos log-switchs, vejamos: não é mais do que um evento que passa os dados modificados da BUFFER CACHE para o disco, em que é actualizado o CTL's e DATAFILES sendo cabeçalho de cada um destes files actualizado com um novo "sequence number". Quase em paralelo o DBW'n escreve as alterações nos ficheiros.
É tb efectuado um CHKP, assim que um redo log file está cheio ou então é executado um log SWITCH no fecho da base de dados por uma destas formas:( normal; transactional; immediate) ou ainda quando o estado do TBS passa para READ-ONLY/BACKUP.

SQL-> ALTER SYSTEM CHECKPOINT;

REDO LOG FILES
Tem como função gravar todas as alterações realizadas na base de dados, mesmo antes de serem confirmadas nos datafiles.
No caso de uma falha quer de media ou no recover da bd, os REDO LOGFILES são usados para avançar os datafiles no tempo, por forma refletirem todas as trasações efectuadas com sucesso.
Sugerem as boas prácticas que existam pelo menos dois membros por cada grupo, por forma a garantir a redundância ao nivel do grupo.

ARQUITECTURA DOS REDOS LOG-GRUPOS:
Cada redo logfile reflete as alterações efectudas a cada bloco de dados.
Quando existe uma recuperação da base dados via REDO LOGFILES, este são lidos, por forma a serem aplicadas todas as alterações efectuadas aos blocos de dados serem efetuadas aos datafiles.

O processo de background LGWR, escreve informação relevante dos redo log buffers para os redo log files, quando as seguintes condições se realizam:

a) um commit é executado, mesmo que seja a nível de log buffer.
b) quando um terço do redo buffer é cheio.
c) quando o log buffer tem cerca de 1Mb de blocos alterados.
NOTA- não inlcui DELETES nem INSERTS

Num ambiente de RAC, em que temos uma base de dados a servir várias instâncias, existe uma thread online do redo para cada instancia.
Isto é, cada LGWR de cada instancia vai escrever nos mesmos "online redo log files" permitindo ao ORACLE saber de onde vieram as alterações.

No caso de uma única instância, apenas existe uma thread online de redo logs, cujo é identificada pelo nº 1.
São guardadas quer transações que foram efectuadas commit quer as que nao foram commited. Sempre que são efectudas transações completas, isto é, em que o commit é efectuado com sucesso, é atribuido um número sequencial nos redos log files.

Cada grupo criado numa base de dados é identificado por um nº inteiro. Sendo possível criar os grupos no momento da criação da base de dados ou então numa fase posterior. É possível efecutar as seguintes operações sobre os redo logs:
- ADD
- DROP
- RENAME

O nº máximo de log files é definido pelo parametro: MAXLOGFILES
Sendo sugerido pelas boas prácticas que sejam todos do mesmo tamanho.

OPERAÇÕES DO REDO LOGS
Cada LGWR apenas consegue escrever num único grupo em deternminado momento. Então esse file que está a ser acedido para escrita tem o seu estado definido com "CURRENT";

Os log files, que são necessários para a base de dados poder recuperar em caso de falha, são os que têm o estado "ACTIVE".
Nota: A BD recupera automáticamente a partir dos online redo log files em caso de necessidade(CRASH).
Isto é, será necessário efectuar uma recuperação da base de dados(INSTANCE RECOVERY).

Os restantes possuem no seu estado "INACTIVE".

Um log switch ocorre sempre que um log grupo fica cheio, como sabemos esta escrita é circular.
Porém é possível forçar a troca de grupo, usado o comando: ALTER SYSTEM SWITCH LOGFILE;

Cada troca de log file, o motor da base de dados atribui um outro numero sequencial à respectiva operação, sendo registado no ALERT_LOG cada switch efectuado.

Dizem as boa prácticas que cada membro deve estar localizado em filesystems diferentes.
IMP:-> Um commit nao pode terminar se a escrita nos redos log file não for bem sucessida.

O tamanho dos redos afectam a perfomance dos checkpoints, isto é se o tamanho dos redos logs files são mais pequenos comparativamente com o volume das transações, provoca que a ocorrencia de "LOG SWITCHS" seja mais frequente e por consequencia os checkpoints.

Os processos de background DBWn escrevem os "DIRTY BUFFER's" sempre que ocorre um chekpoint, conseguido assim que o tempo necessario para recuperação em caso de falha seja o mais reduzido possível, contudo pode prejudicar a perfomance.

É possivel ajustar os intervalos de checkpoints, através do parametro: FAST_START_MTTR_TARGET em substituição do antigo
FAST_START_IO_TARGET e LOG_CECKPOINT_TIMEOUT. A utilização deste parâmetro vai definir o tempo máximo(em segundos) para a base de dados em caso de crash demorará a iniciar(startup).

NOTA: Após definir os grupos e membros necessários para a instalação, é de boas prácticas adicionar mais um.

MULTIPLEXING REDO LOG FILES:
A multiplexagem dos membros, permite diminuir a redundância de erro em caso de falha, pois a escrita é feita em simultaneo em cada membro de cada grupo definido. Ou seja quantos mais membros menor possibilidade de falha, visto cada grupo ter várias cópias exactas.
Em caso do motor da base de dados não conseguir escrever em nenhum dos membros de um grupo a base de dados para, crasha ou pode mesmo fechar-se. Sendo necessário efectuar um "INSTANCE RECOVERY" ou até mesmo "MEDIA RECOVERY" para levantar a bd, podendo ter-se perdido transações efectuadas com sucesso.

exemplo:
CREATE DATABASE “MYDB01”
. . .
LOGFILE
GROUP 1 (‘/ora02/oradata/MYDB01/redo0101.log’,
‘/ora03/oradata/MYDB01/redo0102.log’) SIZE 10M, -> multiplexagem
GROUP 2 (‘/ora02/oradata/MYDB01/redo0201.log’,
‘/ora03/oradata/MYDB01/redo0202.log’) SIZE 10M; -> multiplexagem

O número máximo de membros ou de grupos é definido pelos seguintes parámetros: MAXLOGMEMBERS e MAXLOGFILES.

CRIAR NOVOS GRUPOS:

ALTER DATABASE ADD LOGFILE
GROUP 3 (‘/ora02/oradata/MYDB01/redo0301.log’,
‘/ora03/oradata/MYDB01/redo0302.log’) SIZE 10M; -> multiplexagem
NOta: Se a clausula GRUPO for omitida, o SGBD atribuirá o próximo numero disponivel para o grupo

ALTER DATABASE ADD LOGFILE
‘/ora02/oradata/MYDB01/redo0301.log’ REUSE; -> sem multiplexagem (REUSE -O FILE JA EXISTE E FICARÁ com o mesmo tamanho).

Adicionar novos membros a grupos existentes:
a) Apenas definndo o numero do grupo:
ALTER DATABASE ADD LOGFILE MEMBER ‘/ora04/oradata/MYDB01/redo0203.log’ TO GROUP 2;

b) Explicitamente apenas definindo os outros membros:
ALTER DATABASE ADD LOGFILE MEMBER ‘/ora04/oradata/MYDB01/redo0203.log’ TO
(‘/ora02/oradata/MYDB01/redo0201.log’,
‘/ora03/oradata/MYDB01/redo0202.log’);

RENOMEAÇÃO DOS LOG FILES MEMBERS:
1- Fechar a bd
2- Coipa via S.O. o ficheiro pretendido.
3- Levantar a bd em modo MOUNT (Startup Mount)
4- Renomear dentro da bd o file antigo para o novo (ALTER DATABASE RENAME FILE 'old_name' TO 'NEW_NAME';)
5- Abir a bd (Alter Database Open)
6- Backup Control File. (ALter database backup control file;)

A outra forma que nao implica o fecho da bd, será a adicção de novos grupos e eliminação dos antigos.
NOTA: apenas se podem eliminar os grupos q estão inactivos e temos de ter sempre no minimo 2 grupos.
NOTA2: Caso o grupo q pretendamos eliminar ainda esteja activo ou current, temos de usar o:
ALTER SYSTEM SWITCH LOGFILE;
NOTA3: NAo esquecer de eliminar do S.O os eliminados da BD.

ELIMINAÇÃO DE MEMBROS(>2G e >1 membro):
- ALTER DATABASE DROP LOGFILE MEMBER ‘/ora04/oradata/MYDB01/redo0203.log’;
NOTA4: se os archves estiverem ON, apenas é possivel eliminar se ja tiver passado para os archives.

FLUSH do ONLINE REDO LOG FILES:
Uma das vantagens é nao necessário recriar os grupos ou membros em casos identificados de corrupção.
Pois depois da exeucção deste comando é imperial q seja efectuado um full backup.
ALTER DATABASE CLEAR LOGFILE GROUP 2;

ARCHIVE REDO LOG FILES
Nao tendo os achives activos, a nossa bd apenas consegue recuperar de uma situação de falha da instancia, e nao de uma situação de "media failure", pois apenas usa os online redo log files;

ARQUITECTURA DOS ARQUIVE REDO LOG FILES.

Nada mais nada menos do que uma cópia dos redo log file, antes de ser substituido por nova informação. Visto estes ultimos funcioanrem numa forma circular.
O processo de gravação é designado por ARCHIVING. Sendo o processo responsável por isso o ARCn. Este processo de gração permite a recuperação da base de dados em caso de falha, realizar uma actualização da uma base de dados em stand by, ou então para realizar auditoria na base de dados através do aplicativo LOG Miner.

Assim que o redo log file se encontra cheio o processo LGWr inicia a escrita no seguinte redo log file, permitindo assim que o processo ARCn possa copiar a informação residente no redo anterior para novo destino definido por archive.
Sendo possivel definir vários sitios como destino destas copias dos redo logfiles. Mais conhecidos por archives logs.
O LGWr apenas pode usar o mesmo redo log file apenas quando o ARCn terminar o processo de cópia com sucesso.

Em caso de falha desta mesma cópia a base de dados pode falhar, perdendo transacções que nao tenham sido realizadas com sucesso, isto é com "COMMIT". Isto porque a mensagem de commit com sucesso nao será enviada para o cliente/aplicação caso o LGWr não consiga passar toda a informação para os archives.

Um dos problemas da utilização dos ARCHIVES, é o espaço, pois caso a localização fisica onde estes se encontram encher a base de dados irá parar por completo.

Os estados da base de dados são então definidos em dois:
* NOARCHIVELOG MODE
* ARCHIVELOG MODE

Destino dos ARCHIVES:
A localização dos archives está definida no INIT.ORA da base de dados, ou então pode ser definida no normal funcionamento da mesma com o comando: ALTER SYSTEM

LOG_ARCHIVE_DEST_n -> Podem ser definidos até 10 locais diferentes para serem gerados os archives. Estes locais tem de ser locais ou então remotos, na maquina onde se encontra a base de dados em standby.

sintaxe:
LOG_ARCHIVE_DEST_n = “null_string” |
((SERVICE = tnsnames_name | LOCATION = ‘directory_name’) [MANDATORY | OPTIONAL] [REOPEN [= integer]])

exemplo:
LOG_ARCHIVE_DEST_1 = ((LOCATION=’/archive/MYDB01’) MANDATORY REOPEN = 60);
* localização dos archives
* MAMNDATORY = a escrita tem de ser bem sucessida
* REOPEN = tempo em segundos para tentar escrever novamente no local (60 segundos)

LOG_ARCHIVE_DEST_2 = (SERVICE =STANBY01) OPTIONAL REOPEN;

SERVICE = Nome definido no NET SEREVICE
OTIONAL = a bd continua a funcioanar mesmo que a escrita dos archives nao tenha sido realaizada com sucesso.

A ultima posição é usada para definir como destino a zona da FALSH_RECOVERY_AREA, passando o seguinte parametro:
USE_DB_RECOVERY_FILE_DEST

PARAMETROS IMPORTANTES:

LOG_ARCHIVE_MIN_SUCCED_DEST -> define o numero de sitios em que é obrigatorio escrever.
caso as localizações definidas com MANDATORY sejam inferiores ao valor definido neste parameto, ele é ignorado.

LOG_ARCHIVE_FORMAT -> Define o nome cujo vao ser gravados os nomes dos arquives, sendo assim garantido que cada arquive log file gerado é unico e não é subreposto pelo seguinte.
Exemplo de parametros a definir no nome:

%s -> Log sequence number
%t -> Thread number
%r -> Resetlogs ID: ensures uniqueness even after using advanced recovery techniques that resets the log sequence numbers
%d -> Database ID (usado caso o local seja usado por diversas bd's)

exemplo: arc_%t_%s_%r.dbf

Activação do ARCHIVELOG:
1- Shutdown da base dados
2- alteração dos parametros necessários
3- Abrir a bd em estado mount - STARTUP MOUNT;
4- Alterar o estado do ARCHIVE com ALTER DATABASE ARCHIVELOG ou NOARCHIVELOG;
5- Abrir a BD -ALTER DATABASE OPEN;
6- Validação na bd: select dbid, name, created, log_mode from v$database;

FLASH RECOVER AREA
O uso desta funcionalidade, permite o acesso a dados de backup muito mais rápidamente, permitindo a disponibilização da informação necessária muito mais rápidamente, quer seja erros lógicos ou fisicos.
Esta àrea pode ser um directorio, um filesytem, ou uma àrea de ASM.

O que ocupa a àrea de FLASH-RECOVER-AREA
CONTROL FILES: No momento da criação da base de dados é criada uma cópia do CTL, dentro da flasbackarea
ARCHIVE LOG FILES: São criados automáticamente assim que a FLAS_RECOVERY_AREA é criada. Sendo setado o seguinte parameto (LOG_ARCHIVE_DEST_10) com o local exacto para a criação dos ARCHIVESs pelo processo de backgraound ARCn.
FLASHBACK LOGS: Caso a opção de FLASHBACK DATABASE is ON então os logs desta função são escritos na FLASH RECOVER AREA.
CONTROL FILES e SPFILE Autobackups: Caso o RMAN esteja activo, então as copias geridas por ele dos CTLS e SPFIles são geridas neste espaço.
DATAFFILES copies: Quando o RMAN tem definido para efectuar uma copia dos datafiles por imagem (RMAN BACKUP AS COPY), é por defeito que vem para FRArea os files.

RMAN BACKUP SET- A FLASH RECOVER AREA tb é usada pelo RMAN caso eseja definido copia como BACKUP SETS. Pois será nesta area (FLASH RECOVER AREA) onde serão colocados os archives trazidos das tapes para a recuperação da base de dados.

FLASH RECOVER AREA & SQL COMANDOS:
É necessario definidr dois parametros dinamicos para ser possivel usar a FLASH RECOVER AREA:
1- DB_RECOVERY_FILE_DEST_SIZE - DEfine o tamanho desta area, sendo no minimo 1 vez o tamanho da bd, mais o espaço para os archives logos que ainda nao tiverem sido copiados para tape. Quer seja ASM ou outro formato.O aumento de espaço tb é transparente para a BD.
2- DB_RECOVERY_FILE_DEST - DEfine o local de destino

exemplo1:
SQL> alter system set db_recovery_file_dest_size = 8g scope=both;
*both -> alterações efectivas de imediato e após restart.
*tamanho-> 8 Gb
NOTA IMP: Em ambientes RAC estes parametros tem de sem identicos.

exemplo2:
SQL> alter system set db_recovery_file_dest = ‘/OraFlash’ scope=both;

O processo de desactivação é o inverso, em primeiro desactiva-se o local e depois o espaço.
Sempre que a bd decida que certos files já existentes na FLASH RECOVER AREA não são mais necessários, a bd apaga-os e regista no alert.log ou então quando o espaço definido atinja os 85% de ocupação é enviada uma mensagem de aviso.
Assim que atinja os 95% é enviada uma mensagem crítica. Todas as mensagens são escritas no ALERT.LOG da bd.
Esta actividade também está acessível pelo dicionário de dados através da vista: DBA_OUTSTANDING_ALERTS

EFECTUAR BACKUPS
A politica de backups tem de ir ao encontro com as necessidade inerentes ao negocio. Isto é, é necessario deternminar,
o tempo possivel que a base de dados poder estar inactiva para recoperação. Pois cada bd é deve ter associada niveis de serviço definidas, isto é cada instância dever ter associada SLA's de resposta.

Estes SLA's vão definir a politica de backups a definir.

Terminologia de backups
Temos backups da base de dados inteira, ou então temos backup de parte da base dados. Como tal podemos distinguir dois niveis de backups, FULL BACKUPS e INCREMENTAIS. Dependendo se a base de dados está aberta ou fechada, ou então
backups concistentes ou backups inconcistentes.

Para operacionalizar estes backups, temos comandos SQL ou então o RMAN, sendo esta ferramenta que consegue concretizar a maioria das opções possiveis de backups, incluindo os incrementais.

Vamos comparar backups full e incrementais:
Total BACKUPS-> implica efectuar backup a todos os datafiles e pelo menos um CONTROL FILE. Os Online REDO LOGS nunca são copiados, caso seja reposto os redos log files, durante uma recuperação dos media files, vamos ter quase de certeza perda de informação.

Parcial backup-> IMplica a copia de zero(0) ou mais datafiles, o CTL é opcional

Full -> Implica a copia de todos os blocos de cada datafile backup total ou parcial.

Incremental ->Implica a copia de todos os blocos que foram alterados desde o backup anterior. Nesta versão de base de dados 10G, temos disponiveis 5 niveis de backups, [0-4].
Por isso um backup incremental de nivel [0], é considerado um backup baseline, o que é equivalente a um full backup, incluido todos os blocos dos datafiles. Um backup deste tipo, incremental, demora sempre menos tempo.
Poré numa situação de restore é necessario efectuar um reposição do ultimo baselaine, e deseguida aplicar os incrementais disponiveis, até ao momento que pretendemos ou entao até ao mais recente.

Consistente ->É conhecido por backup offline. Neste caso a bd nao está aberta, todos os cabeçalhos de todos os files, datafiles e control files, tem o mesmo SCN. Nesta opção não é necessario a recoperação adicioanl, pois não existem transsções pendentes. Sendo neste caso o periodo de downtime desprezivel para o negocio.

Inconsistente -> É uma forma de manter a base de dados sempre disponível. é conhecido por BAckup Online, pois a base de dados encontra-se aberta e disponível para os utilizadores. Nesta situação a consistencia deriva do SCN ser distinto entre os datafiles e dos CTL's. Neste tipo de backups é necessária a recuperação da base de dados em caso de "media failure".

BACKUP do CONTROL FILE:
Paralelamente à multiplexagem do control file, é possivel efectuar uma cópia do CTL em modo de TEXTO. Sendo este backup
identificado por "BACKUP TO TRACE". O TRC gerado é no USER_DUMP_DEST e o formato é: "sid_ora_pid.trc"
em que o SID identifica o sid do user que efectou o backup, e o PID o numero do processo correspondente ao comando efectuado.
A realização deste backup especial é mais uma funcção proactiva do que reactivo da actiuvidade do DBA, pois sempre que existe uma alteração da estrutura da base de dados, tal como adicção/remoção de um datafile ou a criação/adição de um redo log group/membro.

exemplo:
SQL -> alter database backup controlfile to trace resetlogs; -> Texto + limpesa de redos.
SQL -> alter database backup controlfile to trace; -> TEXTO
SQL -> alter database backup CONTROLFILE to trace as 'destino.log'; -> TEXTO
SQL -> alter database backup controlfile to '/u03/oradata/ctlfile20040911.bkp'; -> BINARIO

RMAN PARA BACKUPS:
O RMAN continua a ser a excelência para bakcups rápidos e eficazes. Ferramenta gratuita e embebida com o ORACLE, permite efectuar backups por inteiro ou parciais, consistentes ou inconsistentes.
Trata-se de uma ferramente de linha de comando, ou então agora disponivel no EM do 10g. Permite efectuar backups a todos os files usados na base de dados, permitindo criar um histórico de backups.

Configuração dos parametros de backup do RMAN:
DOS> RMAN target /
RMAN> SHOW ALL

Alguns parâmetros no EM:
PARALLELISM - Permite tirar partido do numero de discos existentes no sistema.
DISCK BACKUP LOCATION - Usado quando nao se usa o FLASH-RECOVER-AREA
DISCK BACKUP TYPE - IMAGE COPIE, BACKUPSET , Ou COMPRESSED BACKUP SET

BACKUP SET Versus IMAGE COPIES:

Image copies, tal como a expressão designa, são cópias exactas dos ficheiros, isto é, cada ficheiro tem um cópia exacta de si memsmo.
Enquando que os backups set's são cópias de um ou mais files, num único conjunto(SET), em formato próprio do RMAN.

Criação de full e incremental backup - 570
A recomendação da ORACLE é que seja efectuado um backup semanal via RMAN de nivel 0, isto é um full backup da base de dados. Durante os restantes dias da semana que seja efectuado backups de nivel 1, isto é, backups incrementais.
Muito fácilemente e rápidamente preparamos um backup de Nivel 2 para o meio dia de sábado, caso estejam a serem executados processos de DML.

BACKUP NIVEL 0:
RMAN> backup incremental level 0 as compressed backupset database;

RMAN> backup incremental level 1
2> as compressed backupset database;

A única diferença deste para o anterior, é que apenas serão copiados para o "set" os blocos que foram alterados desde o bck de nivel 0.
Existe ainda a possibilidade de efectuar o de nivel 1, o incremental com actualização do backup, indo actualizar a imagem copia existente do backup, por forma a tornala num unico backup consistente em caso de restore. ver exempo:

run
{
recover copy of database with tag 'inc_upd_img';
backup incremental level 1 for
recover of copy with tag 'inc_upd_img' database;
}

ADMINISTRAR BACKUPS VIA RMAN:

a) Manutenção do Catalogo
Existe várias opções para manter a gestão do catalogo eficiente:
CROSSCHECK ALL - > Permite validar o catalogo com os files existentes no disco, validando que todos estao disponiveis para serem usasdos.
DELETE ALL OBSOLETE -> Apaga todos backups que já não satisfaçam as politicas de retenção.
DELETE ALL EXPIRE -> Apaga as entradas do catalogo de backus que falharam no crosscheck.

b) Monitorização da area de FLSH RECOVERY
Se está activo a FLASH RECOVERY como área de repositório dos backups e estao a ser gerados arquives para a mesma area, e se ficas sem espaço para os arcqives escreverem, a bd irá parar, até ser possivel os arquives voltarem a escrever.

Exemplo de limpeza da área:
1- Limpeza dos arquives que forem obsoletos.
RMAN> delete noprompt obsolete;

2- select name, space_limit max_size, space_used used, space_reclaimable obsolete,number_of_files num_files from v$recovery_file_dest;
(devolve informação que nao se ve no EM)

c) Automação dos BACKUPS
(VER EM)

RESUMO:

---------------- IMPLEMENTAÇÃO DA RECUPERAÇÃO DA BASE DE DADOS

Tipos de FALHAS:
Existem 6 tipos distinctos de possiveis de falhas que podem ocorrer numa base de dados.
1 - Nivel de Statment (operações DML) - pode ser originadas por comandos sql, tais como inserts, updates, deletes.
2 - User Process - a conexão com a base dados falha
3 - Network - Um componente entre o utilizador e a base dados falha, provocando a desconexão do user
4 - User Error - Quando não é gerado um erro, mesmo sendo executada a operação. Exemplo a eliminação de uma tabela.
5 - Instance - Quando a instancia falha sem explicação
6 - Media - Quando um ou mais ficheiros da base de dados é perdido.

Agora em detalhe cada uma das seis ateriores:

1- Falhas a nível de declarações sql
Estas falhas podem acontecem quando são executadas declarações tais como INSERT, criação de tabelas. Exemplos de possivels problemas que podem acontecer: Inserção de registos em tabelas sem os privilégios correctos. Execução de acções sem o espaço atribuido a quota.
Erros de logica derivados da programação.

2- Falhas do User process
Estas falhas são geralmente oriundas de transações que não foram terminadas com COMMIT. Para tal o PMON, tem a função de limpar as sessoes que ficarm ainda pendentes. Verificando que as sessoes que estão conectadas
Geralmente estas situações acontecem quando:

- A janela de SQLPLUS é ecerrada sem ser feito o logout.
- É feito um reboot sem ter terminado a aplicação em primeiro lugar.
- É gerada uma excepção provocando o termino anormal da aplicação
- É ocorrido timeout do processo e o oracle termina a sessão.

3- Falhas de Rede
AS conexões entre os clientes e os servidores, são geralmente constituidas por diversos caminhos, por forma a tornar redundate algumas falhas de conectividade. Desta forma podem ser criados diversos listeneres e diversos path's.

4 - Falhas do utilizador
Estas falhas são originadas pro DROPS de Tabelas, deletes de registos.
Para o caso da eliminação dos registos caaso o COMMIT ainda não tenha sido realizado podemos fazer ROLLBACK da operação.
Caso o COMMIT já tenha sido realizado uma forma de repor a informação será usar o mecanismo de FLASHBACK QUERY ou ainda usar os achives e online redo logs através da funcionalidade do LOGMINER, estando este disponivel em modo de linha de comando ou entao com interface gráfico.
No caso das tabelas dropadas, podemos usar o recycle bin como meio para recoperar a tabela. Os objectos permanecem nesta área até que o espaço seja reclamado pelo por novos objectos que foram eliminados.
Porém existe ainda a funcioanlidade TSPITR - Table Space Point In Time Recover ou então FLASHBACK DATABASE RECOVERY. Esta método pode por em causa outros objectos que tenham sido gerados numa data posterior à data do evento suposto a recuperar.

Caso a recuperação de tabelas seja pequena e estas não tenham dependencias com outras existentes, podemos aplicar a funcionalidade de "FLASHBACK TABLE".

5 - FALHAS DA INSTANCIA
Uma falha da instancia ocorre quando é feito um shutdown sem que a bd tenha conseguido sincronizar todos os cabeçalhos dos datafiles.
Esta sincronização é conhecida pelo SCN - System Change Number. Nesta situação, no próximo arranque da base de dados, vais ser executado uma recuperação da mesma.

Exemplo de possiveis causas:
- FAlha de Energia
- FAlha do Servidor
- Falha do processo de BKground do Oracle
- Procedimentos de emergência (Shutdown Abort)

A solução para estes casos é efectuar um STARUP da BD e deixa-la efectuar a recuperação da instancia(por vezes é demorado), mas é vai usar cojuntamente a informação do TBS UNDO e dos REDO LOGS FILES.
Caso seja uma falha do Background process é gerado um trace que em conjunto do alert log deverá ser usado para analisar a causa dessa falha. Com o EM esta analise é bastante facilitada.

6 - MEDIA FAILURES
As falhas da "media" geralmente não as conseguimos controlar. Esta falha geralmente origina uma perda de 1 ou mais datafiles, control-files ou redo-logs files ou então a perda do init.ora ou do SPFile.
Exemplos de falha:
- Falha da drive
- Falha do Controlador
- Eliminação de uma datafile ou corrupção do mesmo.

Uma das soluções aconselhadas pela ORACLE é o MIRROR de FILEs. Tanto os Controlfiles como os redologfiles podem e deve ser duplicados.
Não esquecendo as politicas de backups essenciais.

EFECTUAR OPERAÇÕES DE RECUPERAÇÃO - 588

PERCEBER o ARRANQUE da BASE DE DADOS
SHUTDOWN -> Nehum processo background está activo
NOMOUNT -> Apenas foi lido o ficheiro INIT.ORA ou o SPifile
MOUNT -> Valida todos os control files, caso um falhe a bd não entra neste estado e permanece em NOMOUNT
OPEN - > Todos os redo logs são validados e todos os datafiles tem de estar disponiveis.

Exemplo de erro na abertura de uma bd:
Startup
ORACLE instance started.
Performing Recovery Operations 549
Total System Global Area 197132288 bytes
Fixed Size 778076 bytes
Variable Size 162537636 bytes
Database Buffers 33554432 bytes
Redo Buffers 262144 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: '/u05/oradata/ord/users01.dbf'

Exemplo de querires que se podem validar em caso de falha:

SQL> select file#, error from v$recover_file;
FILE# ERROR
---------- ---------------------------------------------
4 FILE NOT FOUND
11 FILE NOT FOUND

SQL> select file#, name from v$datafile join v$recover_file using (file#);
FILE# NAME
---------- ----------------------------------------
4 /u05/oradata/ord/users01.dbf
11 /u08/oradata/ord/idx02.dbf

Nota: caso um TBS esteja offline no arranque ou seja colocado, a bd ainda pode ser levantada, desde que esses tbs não sejam o TBS SYSTEM e O UNDO.

Caso seja possivel se tenha recuperao todos os TBS, a bd iniciará automaticamente a sincronização do SCN atraves dos REDO FILEs. Caso isso já não seja possivel só será com os ARCHIVES.

Caso nao exista um membro do grupo a bd pode abrir, porém será gerado um erro no alert log.

Como manter uma instancia sem falhar:
Nem todas as falhas de media são perigosas, apenas dependem dos TBS ou files que possam ter-se danificado.
exemplo de files que provocam falhas:
- CTL's
- Um dos Grupo do redos
- Algum TBS do SYSTEM ou UNDO

A bd ao fechar com SHUTDOWN ABORT não efectua o sincronismo dos datafiles. Sendo efectuado uma recuperação automática pela instancia, no próximo arranque.

Recuperar a instancia após uma falha:

Como ja verificamos anteriormente, após uma crash da instancia a bd efectua uma recuperação automática, esse processo tb é cohecido por
CRASH RECOVERY
Este passo apenas é efectuado apenas quando os datafles não se encontram sincronizados. Primeiro é lido os file de consfigurações - o INTI.ORA/SPFILES depois os "monta" os CTLS e depois os datafiles.

A recuperação da instacia divide-se em dois passos:
1 passo - é usado os redos log files para repor a informação no datafiles para o momento exatactamente antes da falha, executando uma operação conhecida por de "roll forward".
2 passo - é usado o undo tablespace para repor a informação que não foi completamente fechada com o COMMIT;

TUNNING INSTANCE RECOVERY

Antes de ser passada a mensagem para o user de "COMMIT COM SUCESSO" todas as alterações foram escritas com sucesso nos REDO LOGSFILES
Num futuro próximo essa informação será passada para os datafiles. Este desfazamento de operações, é justificado devido à velocidade que esta mesma operação leva a fazer sequencialemente nos redos e de forma aleatória nos datafiles.

Uma maneira de ser possivel identificar a informação que ainda não foi/que já foi para os datafiles são os CHECKPOINTS automáticos ou manuais.
Exemplo todas as transações que ainda nao passaram para os datafiles, tem um SCN superior ao do último CHECKPOINT.
O tempo de recuperação é proporcional ao tempo necessário para actualizar os SCN dos datafiles com o SCN dos CTL's.
Uma nota a ter em mente é que para evitar problemas de perfomance, a distancia entre o ultimo CHECKPOINT e o fim dos REDO LOGS GROUPS não pode ser superior a 90% do tamanho dos redo log groups.
Um parametro que permite efectuar tunning sobre esta questão é o FAST_START_MTTR_TARGET (MTTR), que permite definir o tempo em segundos entre [0 - 3600(1h)] .

Com o parametro definido em zero, o tempo de espera entre a escrita nos redos log files e os datafiles é reduzido, porém quando o parametro está setado com um valor diferente de zero, esse valor é aplicado na espera entre a escrita dos redos e dos datafiles. Contudo o tempo de espera para a bd se inicializada tb vai aumentando à medida que o valor vai crescendo no parametro.
Um valor alto torna a recuperação impraticavel.

Exsitem ainda dois outros parametros usados para o tempo de recuperação da instancia:
LOG_CHECKPOINT_TIMEOUT - > o tempo de espera para os novos blocos na buffer cache até serem escritos em disco.
FAST_START_IO_TARGET - > tempo de espera até serem passados dos redos logs files para os datafiles, agora em I/Os em vez de segundos.

A definição destes dois parametros anula o FAST_START_MTTR_TARGET, estes parametros são dinamicos, estando disponiveis no próximo startup da instancia.

SQL> alter system set fast_start_mttr_target=60 scope=both;

Recuperação de erros dos Utilizadores:

FLASH BACK QUERY:
Esta funcionalidades já existe apartir do oracle 9i, permitindo ao user voltar atrás no tempo.
A estrutura desta funcionalidade é identica a uma instrução SQL adicionada de "AS OF TIMESTAMP"
Esta funcionalidade para estar disponibilizada para os utilizadores, os dba's precisam de validar os seguintes pontos:
- ver se o undo TBS permite guardar informação temporal desde o tempo presente até ao periodo desejado no passado
- Definir o tempo (em sergundos) da retenção através do parametro UNDO_RETENTION
exemplo:
UNDO_RETENTION=172800 - > dois dias de alterações é o tempo disponivel para viajar no tempo através dos FLASHBACK QUERIE.

SQL> select employee_id, last_name, email from hr.employees AS OF TIMESTAMP (systimestamp - interval '15' minute)
where employee_id = 101;

SQL> select employee_id, last_name, email from hr.employees
as of timestamp (to_timestamp ('01-Sep-04 16:18:57.845993', 'DD-Mon-RR HH24:MI:SS.FF')) where employee_id = 101;

Nota: caso a informação já não esteja disponivel no undo, será envida a seguinte mensagem para o utilizador:

ERROR at line 1:
ORA-08180: no snapshot found based on specified time

FLASHBACK DROP & O RECYCLE BIN
Esta funcionalidade permite repor uma tabela sem usar o mecanismo do TBS point in time recovery já disponivel na 9i. Agora com esta novo mecanismo é possivel repor a tabela com os dados no momento antes de ser eliminada.

Conceitos do Recycle bin:
É uma estrutura lógica que é definida em cada TBS, onde existem tabelas e Indexes. O espaço associado ao objectos que foram eliminados apenas é visivel acedendo ao dicionário de dados à seguinte vista: DBA_FREE_SPACE. O espaço ocupado por este objectos apenas é eliminado quando existe a necessidade de espaço, sendo os mesmos eliminados pela ordem que foram chegando, isto é, FIFO - first in first out, conseguindo assim maximizar o tempo disponivel no recycle bin dos objectos que foram eliminados.
Os objectos permanecem associados aos seus donos e contam para o espaço definido na quota.
Os objectos que foram eliminados podem ser recuperados usando as seguintes declarações: FLASHBACK TABLE...TO BEFORE DROP

exemplo:
SQL> flashback table order_items to before drop;

Existe a possibilidade ainda da tabela a repor ter de ser renomeada devido à original estar ja com outra estrutura, para tal usa-se o seguinte comando.

SQL> Flashback table order_items to before drop rename to order_items_old_version;

Limitações do RECYCLE BIN e algumas considerações:
Apenas os tablespaces definidos como não SYSTEM LOCALLY manage conseguem ter recycle bin, os objectos associados à tabela tb são removidos excepto os bitmap join indexes e foreign keys e logs das MV.
Nota: caso o index seja eliminado explicitamente não vai para o recycle, apenas se for fruto da eliminação da tabela.

FLASHBACK TABLE

Esta funcionalidade apenas afecta o objecto e indexes associados, mantendo o resto da base de dados em pleno funcionamento.
Flashback table é diferente de flashback drop.
FLASHBACK TABLE permite recoperar transacções que foram efectuadas numa tabela. Enquanto que FLASBACK DROP permite recuperar uma tabela que foi eliminada.
A FLASHBACK TABLE usa informação disponivel no UNDO TBS, enquanto que os FLASHBACK DROP é usada informação que está no recycle bin.
O FLASHBACK TABLE precisa que na estrutura do objecto esteja activa a opção de "ROW MOVEMENT", isto porque é usado DML para repor a informação. Porém caso os ROWSID'S sejam necessários para manterem a integridade da informação da tabela, esta função de "ROW MOVEMENT", não é viavél.
Esta metodo de reposição de informação nao mexe com o resto da base de dados, apenas coloca em exclusive mode a tabela por forma a repor a informação disponivel.e
A integridade não é posta em causa, apenas temos de activar a funcionalidade nas tabelas com constraints de integridade, ou então tabelas com relações de pais-filhos.

exemplo:
SQL> FLASHBACK TABLE HR.EMPLOYEES, HR.JOBS,HR.DEPARTMENTS, HR.LOCATIONS TO TIMESTAMP TO_TIMESTAMP(‘2004-09-12 01:15:25 PM’, ‘YYYY-MM-DD HH:MI:SS AM’)

LOG MINER
É mais uma forma de analisar as actividades realizadas na base de dados. Esta ferramenta permite analisar registos alterarados, através da pesquisa do LOGMINER, com o uso de procedimentos PL-SQL e Funções.
O LOG MINER permite estrair DDL e DML, das actividades realizadas de dentro dos REDO LOGS FILEs quer dos online quer ja dos arquivados, através da seguinte vista dinâmica:
-> V$LOGMNR_CONTENTS

Nesta vista, tb se capta o DML necessário para repor a informação. Esta funcionalidade difere do FLASH BACK TABLE, uma vez que este apenas ve o conteudo da tabela, ou seja apenas visualiza os registos.

A configuração do LOGMINER pode ser realizada quer via comando SQL ou via GUI. O log miner nao desfaz os eventos, apenas gera o DML/DDL ncessário para o fazer.

PERDA DE UM CTL FILE

Quando se perde um control file, a base de dados falha imediatamente(aborta).
PAssos:
a) caso a bd nao tenha morrido, é necessário executar um ShUTDOWN ABORT de imediato.
b) Efectuar uma copia fisica de um dos restantes CTLS e repo-lo no local onde falhou
c) caso a falha seja fisica, existem duas opções:
1) desactvar o CTL em falha e mudar no ini.
2) mudar para uma nova localização e mudar no ini.
d) Startup da BD

Nota: em caso de se estar a usar um SPFILE , o startup da bd terá de ser apenas no estado NOMOUNT, por forma a nao ser lido o int errado.
Aplicando de seguida o seguinte comandos:
SQL> select name, value from v$spparameters where name = 'control_files';
SQL> alter system set control_files = '/u02/oradata/ord/control01.ctl', '/u06/oradata/ord/control02.ctl' scope = spfile;
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP

RECUPERAÇÃO EM CASO DE PERDA DOS REDO LOGS FILES:

A base de dados precisa apenas de um redo log group para abrir sem problemas, em caso de problemas de qualquer grupo o alert.log tem o registo, e da maiorias dos estados da base de dados.

A vista dinamica que nos informa dos estados de cada redo log member/groupo é dado pelo V$LOGFILE.
Os estados possiveis de cada log file são:
- INVALIDE -> o ficheiro está corrumpido ou em falta
- STALE -> file é um novo mebro e nunca foi usado
- DELETED -> O file já não é usado
- sem nada -> O log file está a ser usado e não está corrumpido.

Em caso de falha de redo logs, deve ser seguidos os seguintes passos:
1- Verificar que redo log file member está em falta.
2- Arquivar os conteudos de cada redo groups, caso este files seja limpos sem terem passado para arquives, é de boas práticas efectua um backup full, por forma a garantir a reposição de datafiles em caso de perdas.

O comando para forçar a passar a informação dos grupos para os ARQUIVES é:

SQL> ALTER SYSTEM ARQUIVE LOG GROUP num_grupo;

Após a passagem para os archives, pode-se limpar os redos com o seguinte comando:

SQL> ALTER DATABASE CLEAR LOGFILE GROUP num_grupo;

Nota: geralmente apenas se dinine no num_grupo o que tem o status INVALID.

RECUPERAÇÃO EM CASO DE PERDA DO DATAFILE SYSTEM:
Quando é destruido um datafile do undo ou do system tbs, a sua reposição vai depender se temos a bd em modo de archive ou não.

- BD EM NOARCHIVE MODE, como recuperar um datafile critico: - implica a reposição da base de dados toda.
- BD EM ARCHIVE MODE, como recuperar um datafile critico: - implica que a bd tem de passar para o estado MOUNT

SQL> shutdown abort
SQL> startup mount

Usando o EPM, segue-se os passos para recuperar os datafiles em falta. No EPM é usado implicitamente comandos RMAN.
No fim da reposição a bd passará para os estado aberta:

SQL> ALTER DATABASE OPEN

RECUPERAÇÃO DE DATAFILES NÃO CRITICOS:

A principal diferença para os datafiles criticos, ou seja os dos systema, é que estes podem ser repostos usando na mesma os archives logs, e com a base de dados aberta.

No caso da base de dados nao estar em modo ARCHIVELOG, é necessário uma reposição intergral da base de dados, incluido control files e redologs files. Sendo necessário posteriormente aplicar as alterações desde o ultimo backup.

No caso da base de dados estar em modo ARCHIVELOG, apenas os objectos que estão em falta são os que irão ser afectados.
1- identificação dos datafiles corrumpidos
exemplo :
SQL> select t.name, d.name from v$tablespace t join v$datafile d using (ts#) where t.name = 'USERS';

Como a bd se encontra em modo ARCHIVE, todas as transações efectuadas, ou melhor, que foram concluidas com COMMIT, serão repostas no tablespace em questão.

O RMAN será a aplicação que vai ser utilizada para efectuar a recuperação necessária.
Ex:
RMAN> run { sql 'alter database datafile 4 offline';
sql 'alter database datafile 7 offline';
restore datafile 4,7;
recover datafile 4,7;
sql 'alter database datafile 4 online';
sql 'alter database datafile 7 online'; }

--- FINITO ---

Nota: "Notas obtidas a partir de ISBN0782143679.Sybex.OCA.Oracle.10g.Administration.I.Study.Guide.1Z0.042.2005.pdf"

ORACLE DataBase Administrator

terça-feira, 27 de outubro de 2009

Objectos invalidos

Analise de Queries.

quinta-feira, 22 de outubro de 2009

Queries para analisar através do "Explain Plan"

Descobir que sessão está usar mais CPU

Valor da SGA por componentes dinâmicos

TRACES sobre sessões

Comandos para gestão de utilizadores:

Introdução - Administração Oracle - @by JMaia

Hobbies