Oracle Certified Associate

Resumo Geral Certificação OCA

O banco de dados Oracle tem três edições, Enterprise, Standard e Personal


OFA ( Optimal Flexible Architeture )


                - Organizar grandes volumes de software e dados no disco, a fim de evitar gargalos no dispositivo e desempenho insatisfatório.

                - Facilitar tarefas administrativas rotineiras, como backup de software e dados, que estão constantemente vulneráveis a danos nos dados

                - Facilitar a alternância entre vários banco de dados

                - Gerenciar e administrar adequadamente o crescimento do banco de dados

                - Ajudar a eliminar a fragmentação do espaço livre no dicionário de dados, isolar outra fragmentação e minimizar a disputa por recursos

 

/Pm                       – ponto de montagem                           – exemplo: /u01

/H                           – nome do diretório                             – exemplo: /u01/app

/u                           - Proprietario                                       - exemplo: /u01/app/Oracle

  

/pm/h/u/product/v                                            - exemplo: /u01/app/Oracle/product/10.0.0

 

/h                           - Proprietario                                       - exemplo: /app

/admin                    – um literal                                          - exemplo: /app/admin

/d                           - database                                           - exemplo: /app/admin/dbseg

/a                           - subdiretório                                      - exemplo: /app/Amin/dbseg/adump

 

/h/admin/d/a                                                     - exemplo: /Oracle/admin/db_seg/udump

 

  

Tipos de Subdiretórios

 

Adhoc: Script SQL ad hoc para um banco de dados específico

Arch: Arquivos de redolog arquivados

Adump: Arquivos de auditoria (Defina o parâmetro de inicialização AUDIT_FILE_DEST para o diretório adump. Esvazie este subdiretório periodicamente)

Bdump: Arquivos de rastreamento de processos background (Smon, Pmon, DBWRT, LOGWRT)

Cdump: Arquivos de Dump de memória

Create: Programas usados para criar o banco de dados

Exp: Arquivos de exportação de banco de dados

Logbook: Arquivos de registro do status e do histórico do banco de dados

Pfile: Arquivos de parâmetros de Instancia

Udump: Arquivos de rastreamento de código SQL

 

Observação: Serão salvos apenas arquivos: REDOLOG (.log), CONTROLE (.ctl) e de DADOS (.dbf) abaixo:

Pm: Um nome de ponto de montagem

Q: uma string que distingue os dados Oracle de todos os outros arquivos, normalmente chama-se oradata ou ORACLE

D: o valor do parâmetro de inicialização DB_NAME

T: um nome de tablespace Oracle

N: Uma string de dois dígitos

Exemplo: pm/q/d/tn:   app/oradata/db_seg/table01.dbf

   

Definição de Variáveis de ambiente

ORACLE_BASE =               /u01/app/oracle                                             /pm/h/u

ORACLE_HOME =             $ORACLE_BASE/product/10.0.0                        /product/v

ORACLE_SID =                 ORCL

NLS_LANG =      language_territory.charachter set                         AMERICAN_DENMARK.WE8MSWIN1252

 

Scripts de Instalação

$ sh runInstaller - ignoreSysPrereqs

orainstRoot.sh

Durante a instalação em uma plataforma UNIX, execute o script orainstRoot.sh como raiz. Esse script cria o arquivo de ponteiro de inventario ( no Linux, esse arquivo é o /etc/oraInst.loc). O arquivo de ponteiro de inventario é usado pelo Oracle Universal Installer na inicialização para encontrar a localização do inventario. Este é um exemplo do arquivo:

                Inventory_loc=/oracle/oraInventory

                Inst_group=oinstall

Em uma instalação com o Microsoft Windows, a localização de inventario é armazenada no registro.O script oraintRoot.sh é semelhante a este

#!/bin/sh

INVPTR=/etc/oraInst.loc

INVLOC=/oracle/oraInventory

GRP=oinstall

PTRDIR=”’dirname $INVPTR’”;

 

# CREATE the software inventory location pointer file

If [ ! –d “$PTRDIR” ]; then

Mkdir –p $PTRDIR;

F1

Echo      inventory_loc=$INVLOC > $INVPTR

Echo      inst_group=$GRP >> $INVPTR

Chmod 644 $INVPTR

 

#CREATE the inventory directory if it doesn´t exit

If [ ! –d “$INVLOC” ]; then

Echo “Creating the oracle inventory directory ($INVLOC)”;

Mkdir –p $INVLOC;

Chmod 775 $INVLOC:

F1

Echo “ Changing groupname of $INVLOC to oinstall.”;

Chgrp oinstall $INVLOC;

If [ $? != 0 ]; then

Echo “WARNING: chgrp of $INVLOC to oinstall failed:”;

F1

 

O Oracle Enterprise Edition Oferece escalabilidade e confiabilidade lideres do setor para configurações de sistema clusterizadas e de um único sistema, ele oferece os recursos mais abrangentes para o processamento de transações on-line e business inteligente

O Oracle Stardard Ediition é destinado a pequenas e medias empresas, os recursos abaixo não estão disponíveis nas versões standard edition

- Oracle Data Guard,

- Oracle Advanced Security, Oracle Label Security, Segurança do usuario Enterprise, Banco de Dados Virtual Privado, autenticação de N camadas e Auditoria Detalhada;

- Oracle Partitioning, Oracle OLAP, Exportação de Tablespaces Transportáveis; entre outros

 

 Arquitetura de Banco de Dados

Arquivos de controle: ele é lido quando você inicia a instancia e monta o banco de dados, os arquivos de controle armazenam as informações para manter e verificar a integridade de um banco de dados, como o nome do banco de dados, o timestamp, nomes e local de arquivos de dados de redolog. As informações armazenadas nos arquivos de controle são usadas para identificar os arquivos de dados e o arquivo de redolog. Os arquivos de controle deve ser abertos quando você abrir o banco de dados. Se o DBA alterar a estrutura do banco de dados o servidor Oracle modificará automaticamente o arquivo de controle. Quando ocorrer uma falha no sistema os arquivos de controle são utilizados juntos com os arquivos de redolog para a recuperação do banco de dados. Cada banco de dados precisa de pelo menos um arquivo de controle. Contem dados sobre o próprio banco de dados, denominados metadados, esses arquivos são fundamentais para o banco de dados sem eles não é possível abrir os arquivos de dados para acessar os dados do banco de dados, exclusivamente estes arquivos tem que ser multiplexados, para garantir a integridade do sistema se caso houver uma falha no arquivo central de controle.

Arquivos de dados: Pertence a apenas uma Tablespace USERS, contem os dados do Banco de dados O arquivo de dados armazena o dicionário de dados e os objetos do usuário. Este tipo de arquivo armazena também as ultimas alterações submetidas a Commit feita nos dados. O servidor lê os dados no arquivo de dados e armazena no cachê de buffer do banco de dados. O servidor não grava dados novos ou modificados imediatamente no arquivo de dados ele lê e joga os dados no cache de buffer de dados.

Arquivo de redolog: Permitem uma recuperação de instância do banco de dados, se o banco de dados travarem e não perder arquivo de dados algum, a instancia poderá recuperá-lo com as informações desses arquivos Todo banco de dados Oracle tem no mínimo dois grupos de arquivos de redolog cada um com pelo menos um arquivo de redolog. Serve pra registrar alterações feitas nos dados. Para proteger os arquivos contra falha no disco, o Oracle suporta arquivos redolog multiplexado. Você pode manter uma cópia do arquivo em diferentes discos. As cópias do arquivo de redolog mantidos em discos diferentes são chamados de arquivos de log espelhados. Cada membro de cada grupo de arquivo de log tem um arquivo de log espelhado de um mesmo tamanho.

Outros arquivos que completam a estrutura de Banco de dados

Arquivo de parâmetros: Usado para definir o modo de configuração da instancia durante sua inicialização, definir uma característica de uma instância Oracle, configuração da instância - inicialização (arquivo de parâmetros) - especifica o nome do banco de dados a quantidade de memória a ser alocada o nome de arquivo de controle e outros parâmetros do sistema.

Arquivo de Senhas: Permite que os usuários estabeleçam uma conexão remota com o banco de dados e executem tarefas administrativas, é utilizado para autenticar ou validar os usuários privilegiado pelo banco de dados Oracle.

Arquivos de log arquivados: Contém um histórico contínuo do redolog gerado pela instancia, esses arquivos permitem a recuperação do banco de dados, você poderá recuperar um arquivo de dados perdido usando esses arquivos e um backup do banco de dados, ele armazena copia off-line de arquivos de redolog utilizado pra recuperação de uma falha de mídia, após o arquivamento é possível reutilizar os arquivos. No modo archivelog é possível reutilizar o banco todo em caso de falha.


Segmentos, Extensões e Blocos

Existem segmentos em um tablespace, os segmentos são compostos de um conjunto de extensões, as extensões são um conjunto de blocos de dados, os blocos de dados são mapeados para blocos do sistema operacional,

 

 

 

                 Os Objetos do banco de dados, como tabelas e índices, são armazenadas nos tablespaces como segmentos, cada segmento contém uma ou mais extensões, uma extensão consiste em blocos de dados contíguos, ou seja, cada extensão somente pode existir em um arquivo de dados, os blocos de dados representam a menor unidade de entrada/saída no banco de dados, quando o banco de dados solicita um conjunto de blocos de dados do sistema operacional o sistema mapeia esse conjunto para o bloco real localizado no dispositivo de armazenamento no próprio sistema, portanto não é necessário saber o endereço físico de nenhum dado em seu banco de dados, isso também significa que um arquivo de dados pode ser dividido e espelhado em vários discos, o tamanho default do bloco é de 8k, mas pode ser definido ao criar o banco de dados, se for um data warehouse, seria interessante um bloco maior, e se for transacional seria interessante se fosse menor, o tamanho mínimo do bloco é de 2K.

  

OIM – Oracle Instance Mainagement ( A Instancia )

            A instancia Oracle é composta por buffers de memória conhecidos como SGA (System Global Area), e processos de background que lidam com a maior parte do trabalho oculto envolvido na execução de uma instância, a instancia permanecerá inativa ate ser iniciada, quando a instancia é iniciada um arquivo de parâmetros é lido e a instancia será configurada de acordo com o que houver no arquivo de parâmetros, depois que a instancia for iniciada e o banco aberto os usuários podem conectar no banco.

                SGA ( System Global Area ): Compartilhada por todos os processos do servidor e de background, nela contem:

·         Cache Buffer banco de dados: O cache de buffer de banco de dados (Database Buffer Cachê) armazena os dados do usuário utilizados mais recentemente. Este cachê contém a lista de gravação (dados modificados, mas não gravados no disco) e a lista de gravação LRU (least recently used). LRU - buffer sujos, retidos (atualmente em uso), buffers livres.

·         Buffer de redolog: Armazena no cache as informações de redo (usadas para recuperação de instancia) até que elas possam ser gravadas nos arquivos de redolog físicos armazenados no disco.

·         Shared Pool: Armazena no cache construtos que podem ser compartilhados entre usuários,  Comandos e planos de execução dos últimos comandos executados É bom, pois O Oracle pula boa parte do parse, pois a shared pool armazena os planos de parses realizados anteriormente.

o   Library cache: É onde é armazenado o texto propriamente dito, o código compilado e o plano do seu comando. É usado pra SQL e PL/SQL. Ex.: procedure, select.

o   Cache do dicionário de dados: são armazenadas todas as informações necessárias pra validar o seu comando. Ele Consulta no dicionário do disco que fica na tabela system. Funciona totalmente em função do library cache, um mecânismo do Oracle muito utilizado pelas áreas de memória é o 

o   LRU: O Oracle joga a informação que faz mais tempo que não é utilizada.

o   UGA: É um pedaço da PGA. É uma subdivisão do PGA. Se você utiliza um servidor compartilhado, ela vai ficar dentro da SGA. Pois é na SGA que ficam as áreas compartilhadas.

o   Hard parse: é o nome dado quando o parse foi realizado por completo (o Oracle procurou em memória e não achou, e teve que fazer todas as fases do parse). Trabalho pesado.

o   Soft parse – É quando a shared pool encontra o comando em memória, mas mesmo assim é necessário uma parte do parse, pois ele precisa ver se você tem privilégios (ele pulou o plano de execução). Logo, Ele faz uma parte pequena do parse.

·         Large Pool: Área OPCIONAL usada para armazenar grandes solicitações de entrada e saída no Buffer, operações que necessitam de grandes blocos assim como data warehousing, permite o compartilhamento de eventos e dados de um ambiente distribuído.

·         Java Pool: Usado para todos os códigos e dados específicos JAVA de sessão dentro do JVM, da mesma forma que o PL/SQL é usado no shared pool.

·         Streams pool: Usado pelo Oracle Streams, permite também a gerencia de dados e eventos em um ambiente distribuído.

PGA (Program Global Área): Privada de cada processo do servidor e background, há um PGA para cada processo, é uma região da memória que contém dados e informações de controle para cada processo do servidor, o processo do servidor atende as solicitações de um cliente, cada processo do servidor possui sua própria PGA, criada quando o processo é iniciado, isso irá variar entre a forma que o modo do servidor estiver configurado como compartilhado ou dedicado, a PGA contem a Área de SQL Privativa, que contem dados tais como as informações de bind e as estruturas  de memoria runtime, cada sessão que executa uma instrução SQL tem uma área SQL privada, e também a memoria de sessão, que é alocada para reter as variáveis de uma sessão e outras informações relativas a sessão, o processo do usuário pede uma conexão que forma o processo do Servidor, autorizando esta conexão gera a PGA com o espaço de memoria que default é de 64k para cada conexão junto disso tem a área de SQL e memoria de sessão:

·         SMON: (System Monitor) - Quando ocorre uma falha na instância Oracle, as informações contidas na Sga que não foram gravadas em disco serão perdidas. Por exemplo, uma falha no sistema operacional provoca uma falha na instância. Após a perda da instância, o processo de segundo plano smon recupera automaticamente a instância quando o banco é reaberto.

 

·         PMON: PMON (Process Monitor) - O Pmon faz uma limpeza após ocorrerem falhas em processos ele executa as seguintes ações, faz roolback da transação atual do user, listas bloqueios de tabela ou linha, Reinicializa dispatchers inativos,

               

·         DBWN: O DBWN grava quando ocorre um checkpoint, os buffers sujos atingem o limite, na há buffers livres, ocorre um timeout, tablespace offline e read only, tablespace begin backup.

 

·         CKPT: (Checkpoint) - Responsável por sinalizar o dbwn em checkpoints, atualizar as informações de checkpoint nos cabeçalhos dos arquivos de dados, atualizar as informações de checkpoint nos arquivos de controle.

               

·         LGWR: (Log Writer) - Executa gravações seqüencial do buffer de redo log no arquivo de redo log on-line quando: uma transação é submetida a commit, quando um-terço do buffer é submetida a commit, quando há mais de 1mb de alterações registrado no buffer de redo log. A cada três segundos, o processo ckpt armazena dados no arquivo de controle para identificar o local (checkpoint) no arquivo de redo log on-line em que a recuperação deve começar .

 

·         ARCN: (Archiver) processo de segundo plano que armazena os redo logs on-line quando modo ARCHIVELOG é definido, e quando os arquivos de logs estão cheios e também ocorre uma alternância de log,

  

Dicionario de Dados

 

            O dicionário de dados é o conjunto central de tabelas e views usadas como uma referencia somente para leitura de um banco de dados específico, ele armazena informações como;

 

                - A estrutura lógica e física do banco de dados

                - Os usuários validos do banco de dados

                - Informações sobre restrições de integridade

                - O volume de espaço alocado para um objeto de esquema e em uso

               

                Um dicionário de dados criado durante a criação de um banco de dados é atualizado automaticamente no momento em que a estrutura do banco de dados é atualizada. O dicionário de dados é o local onde o EM recupera informações sobre os objetos do banco de dados, você também pode selecionar informações nas tabelas do dicionário de dados, o EM faz isso para você e apresenta as informações em um formato de fácil utilização, a view DICTIONARY contem descrições de views e tabelas do dicionário de dados, essas tabelas e views geralmente possuem um dos três prefixos:

               

                USER: informações correspondentes aos objetos pertencentes ao usuário atual

                ALL: Informações correspondentes aos objetos acessíveis ao usuário atual

                DBZ: Informações correspondentes a cada objeto do banco de dados



               

Inciando e Interropendo o IsqlPlus

 

No Linux:

 

Inciando:               $ isqlplusclt start

Parando:               $ isqlplusctl stop

 

No Windows:

Services.msc , encontre o service iSQL*Plus, PracleOracleHomeNameiSQL*Plus

   

Framework de Gerenciamento

 

  Há três componentes principais do framework de gerenciamento do banco de Dados Oracle 10g:

·         O banco de dados e a instancia gerenciada;

·         Um listener que permite conexões ao banco de dados;

·         A interface do gerenciamento. Pode ser um agente de gerenciamento, que conecta este servidor ao controle de grade do Oracle Entreprise Manager, ou o Database Control stand-alone do Oracle Enterprise Manager

O processo seria iniciar o ISQLplus (interface de gerenciamento) depois consultar o Listener e conectar na Instancia Remotamente

Para os banco de dados não conectados ao framework de controle de grade, o Oracle fornece uma console de gerenciamento stand-alone denominada Database Control, o Database Control requer que um processo seja iniciado que seria o dbconsole os comandos abaixo, iniciam , param e mostram os status do processo, lembrando que é possível o gerenciamento apenas de uma base de dados pelo Database Control,

Emctl start dbconsole

Emctl stop dbconsole

Emctl status dbconsole

  

SYSOPER and SYSDBA

SYSOPER: Ao estabelecer conexões com o usuário SYSOPER você esta em um esquema Publico, Uma atribuição especial que permite os comandos;

-   STARTUP, SHUTDOWN, ALTERDATABASE OPEN, ALTER DATABASE MOUNT, ALTER DATABASE BACKUP, ARCHIVE LOG e RECOVER;

Previlégios;

-   RESTRICTED SESSION

SYSDBA: Uma atribuição que contem cada privilégio do Sistema, permite os seguintes comandos;

                 - CREATE DATABASE, e uma recuperação incompleta

                Previlégios;

     - ADMIN e SYSOPER

 Listener

C:\oracle\product\10.2.0\db_1\NETWORK\ADMIN

LISTENER – O processo ouvidor A aplicação cliente faz uma conexão inicial ao servidor de BD através do ouvidor (listener), que por sua vez é um processo que “ouve” as requisições de conexão como representante de um ou mais BDs. Algumas características do listener são:


* Um listener pode “ouvir” mais de um BD;
* Vários listeners podem “ouvir” um mesmo BD afim de promover balanceamento de carga;
* Um listener pode “ouvir” através de vários protocolos;
* O nome padrão do listener em uma rede Oracle é LISTENER;
* O nome do arquivo do listener deve ser listener.ora.

 

Configuração estática do listener

 

- Quando o banco de dados é instalado as seguintes opções são configuradas no listener:


- Listener name: LISTENER
- Port: 1521
- Protocols: TCP/IP e IPC
- SID name: nome da instância
- Host name: nome do servidor


Pode ser utilizado o Oracle Net Manager para configurar o listerner.

 

Configuração estática do listener

LISTENER =
              (ADDRESS_LIST =
                     (ADDRESS= (PROTOCOL = TCP)(Host=NOMEDOSERVIDOR)(Port=1521))
)

 SID_LIST_LISTENER =
             (SID_DESC =
                    (ORACLE_HOME= /home/oracle)
                   (GLOBAL_DBNAME = ORCL.us.oracle.com)
                  (SID_NAME = ORCL)
)

 

Configuração dinâmica
Os seguinte parâmetros devem estar definidos no seu init.ora:


- SERVICE_NAMES = sales.us.oracle.com
- INSTANCE NAME = salesdb


O PMON vai utilizar os mesmos parâmetros da configuração manual;
O PMON pode registrar um listener diferente se forem definidos os seguintes parâmetros:


- LOCAL_LISTENER = listener_alias
- DISPATCHERS = num. Dispatcher

 

O listener_alias deve ser resolvido através de um método de nomeação, ex: tnsnames.ora


- Ex: listener_alias = (DESCRIPTION= (ADRESS= (PROTOCOL=TCP) (HOST=sales-server) (PORT=1421)))

 

Configurando o listener para IIOP e HTTP

 

listener =
              (DESCRIPTION_LIST=
                   (DESCRIPTION=
                  (ADDRESS=(PROTOCOL=tcp)(host=nomedoservidor)(port=2481)
                 (PROTOCOL_STACK=
                (PRESENTATION=giop)
               (SESSION=raw)))

 

Controlando o Listener

 

O programa responsável pelo listerner chama-se: LSNRCTL;
Pode ser passados comando para o listerner ou entrar com os comandos no prompt do

LSNRCTL, ex:


- lsnrctl stop
-lsnrctl start
-lsnrctl reload
-lsnrctl status



INICIALIZAÇÃO e SHUTDOWN

Existem 3 formas de inicializar o banco de dados, NOMOUNT, MOUNT e OPEN,

                -NOMOUNT: Uma instancia só é inicializada no estagio de NOMOUNT quando ela é instalada, durante a criação do Banco de Dados ou recriação de arquivos de controle

Leitura do arquivo de inicialização em $ ORACLE_HOME/dbs é da seguinte ordem:

1.       spfileSID.ora

2.       Se não encontrar, vai tentar ler o spfile.ora

3.       Se não encontrar, vai tentar ler o initSID.ora

 

-          A especificação PFILE com STARTUP sobrepõe o default,

-          Alocação da SGA

-          Inicialização dos processos de background

-          Abertura do arquivo alertSID.log e dos arquivos de rastreamento

               

 

 

 

- MOUNT: é utilizado para manutenções especificas do banco enquanto ele não estiver aberto abaixo algumas tarefas que exigem que o banco esteja montado e não iniciado;

A montagem de um banco de dados inclui as seguintes tarefas;

1.       Associação de um banco de dados a uma instancia inicializada anteriormente (NOMOUNT)

2.       Localização e abertura dos arquivos de controle especificados no arquivo de parâmetros

3.       Leitura dos arquivos de controle para obtenção dos nomes e status dos arquivos de dados e arquivos de redo log on-line, neste momento não é verificado a existência dos arquivos de redo log e de controle

 

-          Renomeação de arquivos de dados (.dbf) (em exceção quando a tablespace de arquivos de dados estiver off-line)

-          Ativação e Desativação de opções de arquivamento de redo log

-          Recuperação INTEGRAL da base de dados

-OPEN: A Abertura de um Banco de dados inclui as seguintes tarefas:

1.       Abertura dos arquivos de dados on-line

2.       Abertura dos arquivos de redo log on-line        

 

-          Se algum arquivos de dados ou redo log não estiver presente quando tentar abrir o banco o Servidor retornará um erro

-          Durante este estagio ele verificara todos os arquivos de redo log e de controle se necessário o processo SMON iniciará a recuperação da Instancia.

 

Existem 4 formas de efetuar um Shutdown no Banco de Dados Oracle: ABORT, IMMEDIATE, TRANSACTIONAL E NORMAL

O shutdown é feito para gerar backup off-line do sistema operacional e de todas as estruturas, e para que o parâmetros de inicialização estático modificado tenha efeito,

Como usuário para fazer o Shutdown de uma instancia você precisa estar logado como SYSOPER ou SYSDBA, e usar o seguinte comando;

                SHUTDOWN [ NORMAL, TRANSACTIONAL, IMMEDIATE, ABORT ]

 

SHUTDOWN NORMAL: Normal é o modo default do shutdown, ele ocorre nas seguintes condições;

1.       Não é possível obter novas conexões no banco

2.       O servidor aguarda a desconexão de todos os usuário antes de efetuar o shutdown

3.       Os arquivos de banco e redo log são gravados no disco

4.       Os processos de background são encerrados corretamente e a SGA é removida da memória

5.       O Oracle fecha e desmonta o banco antes de efetuar o shutdown

6.       A próxima inicialização não irá requerer recuperação da Instancia

SHUTDOWN TRANSACTIONAL:  O Shutdown transactional evita que o usuário perca trabalho, ele ocorre nas seguintes condições;

1.       Não é possível obter novas conexões nessa instancia em especifico

2.       O cliente é desconectado quando termina uma transação em andamento

3.       Quanto termina todas as transações é feito o shutdown

4.       A próxima inicialização não irá requerer recuperação da Instancia

SHUTDOWN IMMEDIATE: O shutdown imediato ocorre nas seguinte condições;

1.       As transações ou instruções SQL não são terminadas imediatamente

2.       O Servidor Oracle não aguarda a desconexão dos usuários

3.       O Servidor Oracle efetua rollback de transações ativas e desconecta todos os usuários

4.       O oracle fecha e desmonta o banco antes de efetuar o shutdown

5.       A próxima inicialização não irá requerer recuperação da Instancia

SHUTDOWN ABORT: Quando o shutdown Normal e Immediate não funcionarem voce pode usar a opção ABORT ela ocorre nas seguintes condições;

1.       As transações ou instruções SQL não são terminadas imediatamente

2.       O Servidor Oracle não aguarda a desconexão dos usuários

3.       Os arquivos de banco e redo log NÃO são gravados no disco

4.       O Servidor Oracle NÃO efetua rollback de transações não submetidas a commit

5.       O Banco de dados não é fechado e nem desmontado

6.       A próxima inicialização EXIGE recuperação da Instancia, que ocorre automaticamente

 

Arquivo de Parametros de Inicialização

 

São dois arquivos. O PFILE, mais conhecido por “init.ora”, e o SPFILE, que é um arquivo de parâmetro do servidor, conhecido como “spfile.ora”.

 

Os arquivos costumam ficar no caminho:

C:\oracle\product\10.2.0\db_1\dbs\SPFILEORCL.ORA – SPFILE

C:\oracle\product\10.2.0\db_1\database\initorcl.ora – PFILE

C:\oracle\product\10.2.0\admin\orcl\pfile\init.ora.514201254337 – Cópia ORIG

 

A instância Oracle inicialmente procura pelo SPFILE, caso não o encontre, buscará pelo PFILE. O SPFILE é uma versão binária do PFILE. Uma das maiores vantagens de se utilizar o SPFILE, é a possibilidade da alteração de diversos parâmetros de forma dinâmica, ativando-os sem a necessidade de reinicialização do banco de dados.

Para verificar a existência do SPFILE, basta executar o seguinte comando:

 

SQL> show parameter SPFILE;

 

Para criar o SPFILE a partir do PFILE, utilize os seguintes comandos:

 

SQL>create SPFILE from PFILE;


ou


SQL> create SPFILE from PFILE=’/u01/app/oracle/product/11.2.0/dbhome_1/dbs/init.ora’


ou


SQL>create SPFILE=’/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfileNomeInstancia.ora’ from PFILE=’/u01/app/oracle/product/11.2.0/dbhome_1/dbs/init.ora’

 

Após isto, basta reiniciar o Oracle:

 

SQL>shutdown immediate;


SQL> startup

 

Durante o processo de reinicialização, o Oracle encontrará o SPFILE automaticamente.

Sempre faça um backup do SPFILE para um PFILE, pois um dia seu SPFILE pode corromper, então basta inicializar o Oracle a partir do PFILE. Como?

 

Criando um PFILE a partir do SPFILE, faça:

 

SQL> create PFILE=’u01/app/oracle/product/11.2.0/dbhome_1/dbs/initBACKUP.ora’ from SPFILE;

Caso o Oracle não inicie devido a um problema no SPFILE, inicialize-o a partir do PFILE salvo:

 

SQL> startup PFILE=’u01/app/oracle/product/11.2.0/dbhome_1/dbs/initBACKUP.ora’;

 

O Oracle inicializará normalmente – só por que você fez o backup do SPFILE. Já que agora está tudo mais tranquilo, aproveite para criar um novo SPFILE a partir do PFILE – já que o atual está corrompido – Repetirei:

 

SQL> create SPFILE from

PFILE=’/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initBACKUP.ora’;


SQL> shutdown immediate;


SQL> startup

 

O Oracle voltou a iniciar a partir do SPFILE.

Lembre-se de sempre manter um backup “atualizado” do seu SPFILE em um PFILE.

 

Arquivo de Log de Alerta

 

Cada banco de dados possui seu arquivo de LOG de ALERTA, ele fica localizado:

 

C:\oracle\product\10.2.0\admin\orcl\bdump\alert_orcl.log

 

 

O arquivo de alerta de um banco de dados é um log cronológico de mensagens e erros que inclui o seguinte:

-          Todos os erros internos (ORA-600), erros de blocos danificados (ORA-1578) e erros de deadlock (ORA-60);

-          Operações administrativas, como instruções SQL CREATE, ALTER, DROP DATABASE, TABLESPACE, ROLLBACK SEGMENT, STARTUP, SHUTDOWN, ARCHIVE LOG E RECOVER;

-          Varias mensagens de erros relacionadas ás funções de servidor compartilhado e processo de dispatcher

-          Erros durante a atualização da view materializada

O arquivo é automaticamente gerado assim que inicia a instancia, em caso de backup, copie e apague o atual, para não ocupar muito espaço em disco,

 

 

 Tablespaces e Arquivos de Dados

 

O Oracle armazena dados LOGICAMENTE em tablespaces e FISICAMENTE em arquivos de dados

 

TABLESPACES: Só podem pertencer a um banco de dados por vez, consistem em um ou mais arquivos de dados, são divididos posteriormente em unidades logicas de armazenamento

 

ARQUIVO DE DADOS: Podem pertencer a apenas um tablespace e um banco de dados, são um repositório para dados de objetos do esquema

 

Um banco de dados Oracle consiste em uma ou mais unidades de armazenamento logicas denominadas Tablespaces, que armazenam coletivamente todos os dados do banco de dados, cada Tablespace em um banco de dados Oracle consiste em um ou mais arquivos denominados arquivos de dados, que são estruturas físicas compatíveis com o sistema operacional no qual o Oracle é executado, os dados de um banco de dados armazenado coletivamente nos arquivos de dados que constituem cada tablespace do banco de dados,

 

 

 

 Por exemplo: Um Banco de Dados poderá ter 3 Tablespaces com 2 arquivos de dados cada, sendo assim tendo 3 tablespaces com 6 arquivos de dados;

 

Tablespaces gerenciadas localmente: As extensões são gerenciadas no tablespace por bitmaps. Cada bitmap corresponde a um bloco ou a um grupo de blocos. Quando uma extensão é alocada ou liberada para reutilização, o servidor Oracle altera os valores do bitmap para mostrar o novo status do bloco;

 

Tablespaces gerenciados por dicionário: As extensões são gerenciadas pelo dicionário de dados, o oracle atualiza as tabelas apropriadas no dicionário de dados sempre que uma extensão é alocada ou desalocada, isso é feito para fins de recompatibilidade, todos os tablespaces devem ser gerenciados localmente.

 

As extensões podem ser alocadas em duas maneiras:

               -Automatic; Autollocate, especifica que o tamanho das extensões são geradas no sistema, não sendo possível indicar um tamanho de extensão, tablespace temporário não pode ser automatic;

               -Uniform; é gerenciado por um tamanho especificado, o default é de 1MB, todas as tablespaces temporárias possuem tamanho uniform, não sendo possível especificar para tablespace de UNDO;

 

Gerenciamento de espaço de segmento em um tablespace gerenciado localmente;

 

               - Automatic, o Oracle usa bitmaps para gerenciar espaço livre nos segmentos, nesse caso um bitmap é um mapa que descreve o status de cada bloco de dados em relação ao espaço disponível para inserção de linhas, a medida que for liberado espaço isso é refletido no bloco

               - Manual; Isso informa que você deseja usar freelists para gerenciar o espaço livre nos segmentos, Freelists são listas de blocos de dados com espaço disponível para inserção de linhas, devido a necessidade de especificar e ajustar os parâmetros de armazenamento PCTUSED, FREELISTS and FREELIST GROUPS, para objetos de esquema criados no tablespace;

 

Vantagens de Tablespaces gerenciados localmente;

1.       O gerenciamento local evita operações recursivas de gerenciamento de dados, elas ocorrem em tablespaces gerenciados por dicionário, se o consumo ou a liberação de espaço em uma extensão resultar em outra operação que consuma ou libere espaço em um segmento de undo ou em uma tabela de dicionário de dados,

2.       Não registram espaço livre em tabelas de dicionário de dados, eles reduzem a disputa nessas tabelas (tabela de dicionário de dados)

3.       Controla automaticamente o espaço livre adjacente, eliminando a necessidade de aglutinar extensões livres

4.       Determina automaticamente as extensões

5.       Alterações de bitmap, não geram informações de undo, pois não atualiza tabelas no dicionário de dados

 

É possível transformar tablespace gerenciada por dicionário de dados em localmente, basta utiliza o procedimento                 dbms_space_admin.tablespace_migrate_to_local

 

Logging: As alterações feitas são gravadas no fluxo do redo, ele inicia na memoria e em seguida é gravado nos arquivos de redo log on-line, podendo ser gravados nos arquivos de log de arquivamento, é possível desativar esse processo, os objetos de tablespace serão irrecuperáveis em qualquer tipo de falha

Alguns exemplos de Tablespaces: SYSTEM, SYSAUX, TEMP, UNDOTBS1, USERS, EXAMPLE

              -SYSTEM: é usada para gerenciar o banco de dados, contém o dicionário de dados e informações administrativas, isto tudo esta contido no esquema SYS, e somente pode ser acessado pelo usuário SYS, ou por algum usuário com o privilégio

                -SYSAUX: é auxiliar a SYSTEM, componentes e produtos que utilizavam o tablespace SYSTEM ou seus próprios tablespaces de releases anteriores, qualquer base que for superior a 10g deve ter a tablespace SYSAUX

                -TEMP: é usada para armazenar tabelas temporárias durante o processo de instrução SQL, se nenhum tablespace for atribuído ao usuário quando criado ele usa esta como default

                -UNDOTBS1: é usado para armazenar informações de undo, cada banco de dados deve ter uma no projeto

             -USERS: é usado para armazenar dados e objetos dos usuários permanentes, ele é usado como default no banco de dados pré-configurado para todos os objetos criados por usuários não pertencentes ao sistema;

              -EXAMPLE: contem exemplos de esquema que podem ser instalados durante a criação do banco de dados, courseware e a documentação Oracle contem exemplos baseados nesses esquemas;

 

Alternad tablespaces: uma tablespace pode ser alterada sempre que necessário e for autorizado para isso, elas tem três tipos diferente,

                -Read Write: On-line e pode ser usado para leitura e gravação

                -Read Only: ele coloca a tablespace em modo de transição somente leitura, as transações existentes podem ser concluídas mas nenhuma operação DML é permitida, exceto o rollback de transações existentes que modificaram blocos anteriormente. Não é possível tornar o tablespace SYSTEM ou SYSAUX em somente para leitura;

                -Off-Line: pode colocar um tablespace em modo off-line de modo que esta parte do banco não esteja disponível temporariamente, o restante do banco está aberto e disponível para acesso dos usuários, temos abaixo algumas opções de como colocar o tablespace em off-line;

                               - Normal: O oracle realiza um checkpoint de todos os arquivos do tablespace ao coloca-la em off-line Normal, não podendo haver nenhum erro, em qualquer arquivo de dados do tablesapce;

                               - Temporario; pode ser colocado mesmo não tendo nenhum erro nos arquivos de dados, realiza o checkpoint e coloca os arquivos em modo de off-line, se nenhum arquivo estiver off-line e você usar a opção temporary, a recuperação de mídia não será necessária para colocar online, entretanto se algum arquivo conter erro de gravação e for feita a tentativa de colocar temporary, ele fara automaticamente a recuperação para colocar online

                               -Immediate: pode ser colocado off-line imediatamente sem que o oracle faça nenhum checkpoint em qualquer arquivo de dados, a recuperação de mídia é necessária antes de coloca-lo online novamente, se o banco de dados estiver configurado como NOARCHIVELOG, não poderá colocar off-line imediatamente;

                               -For Recover; Obsoleta, usada para fins de retrocompatibilidade;

Para adicionar espaço a um tablespace adiciona arquivo de dados a ele ou altere o tamanho de um arquivo de dados existente, sendo possível aumentar ou diminuir um tablespace, entretanto não sendo possível diminuir o arquivo de dados, se tentar diminuir recebera um erro,

 

Temos três tipos de alerta para thresholds:

                -Use Default Thresoulds: Utiliza default predefinidos, que podem ser definidos

                -Specify Thresould: Permite definir limites para este tablespace especifico

                - Disable Thresolds: Desativa os alertas de uso do espaço para este tablespace

Podemos utilizar as seguintes ações nos tablespaces: ADD DATAFILE, CREATE LIKE, GENERATE DDL, MAKE LOCALLY MANAGED, MAKE READONLY, MAKE WRITBALE, PLACE ONLINE, REORGANIZE, SHOW DEPENDENCES, RUN SEGMENTE ADVISER, TAKE OFFLINE,

 

PARA VERIFICAR INFORMAÇÕES SOBRE TABLESPACES UTILIZE OS SEGUINTES COMANDO ABAIXO:

- DBA_TABLESPACES

- V$TABLESPACE

Sobre arquivos de dados

- DBA_DATA_FILES

- V$DATAFILE

Arquivos temporários

- DBA_TEMP_FILES

- V$TEMPFILE

Contas de Usuario

 

Nomes de usuário exclusivos que não podem passar 30 caracteres, não podem conter caracteres especiais e começar por uma letra;

Um método de autenticação, senha, biométrica, certificação de token;

Um tablespace default, um lugar aonde o usuário vai criar seus objetos, claro se ele não indicar nenhum outro lugar,

Um tablespace temporário, Um lugar onde o usuário pode criar objetos temporários como classificações e tabelas temporárias,

Um perfil de Usuario, um conjunto de restrições para senhas e recursos atribuídos ao usuário,

Os perfis não poderão impor limitações aos usuários em relação aos recursos, a menos que o parâmetro de inicialização RESOURCE_LIMIT esteja como TRUE, se o RESOURCE_LIMIT estiver como FALSE, as limitações de perfil serão ignoradas,

Comandos para criar, inserir senhas, dar permissões, assim como retirá-las também e adicionar em um perfil ou criar um perfil

create user peter                                             ( Criando usuario Chamado peter)

identified by peter                                           ( Senha peter )

default tablespace users                                 ( indicando qual tablespace o usuário vai usar)              

quota 15m on users;                                       ( Definindo uma quota de 15M para este usuario)

grant create session to peter;                          ( dando permissão de criar sessões )                             

Revoke session to peter                                  ( retirando a permissão do usuário para criar sessões)

create profile grace_5 limit                              ( Criação de um profile)

failed_login_attempts 3                                   ( Definindo quantas tentativas de login)

password_lock_time unlimited                        ( senha)

password_life_time 30                                     ( Tempo maximo da senha será 30 dias )

password_reuse_time 30                                  ( poderá usar a senha dos ultimos 30 dias)

password_verify_function verify_function        ( )

password_grace_time 5;                                   ( )

Os perfis permitem que o administrador controle os seguintes recursos do sistema;

CPU: Os recursos de CPU podem ser limitados em cada sessão ou em cada chamada, uma limitação de CPU/sessão igual a 1000 significa que se qualquer sessão individual que estiver usando esse perfil consumir mais do que 10 segundos de tempo de CPU ( as limitações de tempo de CPU ocorrem em centésimos de segundo ), essa sessão receberá um erro;

                ORA-02392: exceded session limit n CPU usage, you are being logged off

Uma limitação por chamada executa a mesma ação, mas em vez de limitar a sessão geral do usuário, ela impede que qualquer comando individual consuma uma quantidade muito grande de CPU, se o campo CPU/Call estiver limitado e o usuário exceder a limitação, o comando abortará e o usuário receberá uma mensagem de erro,

                ORA-02393: exceded call timit on CPU usage

NETWORK/MEMORY: Cada sessão de banco de dados consome recursos da memoria do sistema ( Se a sessão for de um usuário não local no servidor ) recursos de rede também,

                - Connect timed (quanto tempo o usuário pode permanecer conectado antes de ser desconectado automaticamente)

                - Idle Timed: Quanto tempo ( minutos ) a sessão de um usuário pode permanecer inativa antes de ser desconectada automaticamente, o tempo de inatividade é calculado somente para o processo do servidor, a atividade da aplicação não é considerada, nem por outras operações,

                - Current Sessions: Quantas sessões concorrentes podem ser criadas usando uma conta de usuário banco de dados,

                - Private SGA: Limita a quantidade de espaço consumido na SGA para classificar, intercalar bitmaps etc, essa restrição somente terá efeito se a sessão usar um servidor compartilhado

DISK I/O: Limita a quantidade de dados que podem ser lidos por um usuário em cada nível da sessão ou de chamada, Read/Session and Read/Call, impõem uma limitação no numero total de leituras de memoria e do disco, isso pode ser feito para garantir que instruções com muitas operações de entrada/saída não utilizem excesso de memoria nem comprometam o disco,

 

Os perfis também permitem limite composto, os limites compostos se baseiam em uma combinação ponderada de sessão/CPU, leitura/sessão, tempo de conexão e SGA privada,

Autenticação de Usuários: as autenticações de usuários podem ser Password, External e Global, essas configurações podem ser mudadas posteriormente,

Password: é criada assim como o usuário, quando criamos um usuário inserimos uma senha para este usuário, você pode forçar que o usuário altere ela quando se logar a primeira vez, mas lembrando que temos algumas aplicações que não podem ter essa configuração,

External: Autenticação pelo sistema operacional é mais fácil a conexão ao banco de dados, A senha de um banco de dados não é utilizada para este tipo de login, para isso temos que definir OS_AUTHENT_PREFIX e use esse prefixo nos nomes de usuário Oracle, o parâmetro OS_AUTHENT_PREFIX define um prefixo adicionado pelo Oracle ao inicio de cada nome do usuário no sistema operacional, o parâmetro default é OS_AUTHENT_PREFIX=OPS$, este parâmetro faz distinção entre maiúsculos e minúsculos,

Global: é uma autenticação forte ativada pela opção Oracle Advanced Security, feito por meio de autenticação biométrica, certificados x509, dispositivos token e pelo Oracle Internet Directory.

Tablespace Default, é onde todos os objetos serão criados caso nenhuma tablespace seja especificada na criação do objeto,

Tablespace Temporário: é onde ocorre qualquer ação de classificação, uma classificação é feita quando um índice é criado ou quando uma clausula ORDER BY é usada em uma instrução SELECT,

Quando o usuário é criado ele pode estar com o status bloqueado ou desbloqueado,  o default do Oracle deixa os usuários desbloqueados

 

 Esquema e Usuários de Banco de Dados

Esquema: é o conjunto de objetos pertencentes a um usuário, ele possui o mesmo nome de seu proprietário, os objetos incluem;

·         Tabelas

·         Views

·         Indices

·         Código armazenado ( JAVA e PL/SQL)

Lembrando que não há relação entre tablespaces e esquema, quando um usuário de banco é criado um esquema correspondente com o mesmo nome é criado para esse usuário, Os proprietários de esquemas possuem controle total sobre seus próprios objetos de esquema, podendo conceder permissão a outros usuários para a utilização desses objetos.

Lista de Verificação para criar usuários: para criar um usuário, o administrador deve

·         atribuir um perfil,

·         escolher uma técnica de autenticação

·         atribuir tablespace,

Por default quando um usuário é criado ele não recebe nenhum previlégio, o que significa que ele não poderá realizar nenhuma ação no banco de dados, o banco de dados concede alguns objetos no banco de dados, entretanto, se o usuário não tiver cota em nenhum tablespace, ele ainda assim não poderá criar objetos,

Quando criamos um banco de dados são criados dois esquemas o SYS e o System:

·         SYS: Todas as tables-base e viwes que constituem o dicionário de dados são criados no esquema SYS o dicionário de dados é um conjunto de tabelas que descreve o banco de dados, esse dicionário é criado no tablespace SYSTEM quando o banco de dados é criado e atualizado pelo servidor do banco de dados, durante uma execução DDL, O dicionário de dados possui informações sobre usuários, objetos de esquema e estruturas de armazenamento, você pode acessa-lo através de views, ninguém nunca pode criar tabelas no esquema de usuário SYS,

·         SYSTEM: Contém tabelas e viwes que armazenam informações administrativas, e tabelas e views internas usadas por varias opções e ferramentas, você não deve criar objetos no esquema SYSTEM, Durante uma instalação é criada amostras de esquema com essas amostras é possível oferecer uma plataforma comum de exemplos, elas consistem de um conjunto de esquemas interligados que se destina a oferecer uma abordagem em camadas que incluem as seguintes:

o   HR: o esquema Human Resources é um esquema simples para apresentação de tópicos básicos, uma extensão desse esquema suporta demonstrações do Oracle Internet Directory

o   OE: o esquema Order Entry se destina a assuntos de complexidade intermediaria, há vários tipos de dados disponíveis nesse esquema,

§  O sub-esquema OC ( Online Catalog ) é um conjunto de objetos de banco de dados relacional construído dentro do esquema OE.

o   PM: o esquema Product Media é dedicado a tipos de dados multimídia

o   QS: O esquema QUEUED SHIPPING contém um conjunto de esquemas usados para demonstrar os recursos do Oracle Advanced Queuing.

o   SH: O esquema Sales History permite demonstrações com volumes de dados maiores, uma extensão desse esquema oferece suporte para o processamento analítico e avançado.

Previlégio

Há dois tipos de privilégios de usuário, System e Objeto

System: Permite que os usuários executem determinadas ações(operação) no banco de dados, Exemplo, criar tablespaces, eles podem ser concedidos pelo administrador ou por alguma pessoa que forneça permissão explicitamente para administrar o privilégio, existem mais de 100 tipos de privilégios de sistema

grant create table to marcelo;

revoke create table from marcelo;

SELECT ANY TABLE: permite que o usuário fala seleção nas tabelas pertencentes a outros usuários;

RESTRICED_SESSION: permite que o usuário efetue login se o banco tiver sido aberto no modo restrito;

SYSDBA e SYSOPER: permite que o usuário desative, inicie, execute recuperação e outras tarefas administrativas;

DROP ANY: permite que os usuários delete objetos que não pertencem a eles;

CRATE, MANAGE, DROP, ALTER TABLESPACE: os usuários que não são administradores não devem controlar tablespaces;

CREATE ANY DIRECTORY: permite que o usuário chame objetos de códigos inseguros;

EXEMPT ACCESS POLICY :permite que um usuário ignore as functions de segurança inseridas em tables ou views;

GRANT ANY OBJECT PRIVILEGE: permite que um usuário concedam permissões a objetos que não pertencerão a eles;

ALTER DATABASE e ALTER SYSTEM: os usuários que não são administradores não devem ter permissão para alterar banco de dados ou Instancias;

Objeto: Permite que os usuários acessem e manipulem um objeto específico, como table, view, sequencia, procedure, function ou package, Sem a permissão especifica os usuários somente poderão acessar seus próprios objetos, os privilégios de objeto podem ser concedidos pelos proprietários do objeto, pelo administrador ou por alguma pessoa que tenha recebido uma permissão explicita para conceder previlegio no objeto

grant update on scott.tab_sys to marcelo with grant option;

revoke update on scott.tab_sys from marcelo;

Escolha o objeto no qual deseja conceder privilegio (Select, Alter, Delete, Index, references e Updates, informando o nome do usuario username. object)

COTA para usuários

A cota é um pequeno espaço em um tablespace específico, por default o usuário não possui cota em nenhum tablespace, São fornecidas três opções de cota para um usuário em um tablespace:

1.       Unlimeted: esta cota permite ao usuário utilizar todo o espaço disponível no tablespace;

2.       Value: é o numero de Kilobytes ou Megabytes que podem ser usados pelo usuário, ele não garante que o espaço será reservado para o usuário, esse valor pode ser maior ou menor que o espaço atual disponível no tablespace

3.       UNLIMITED_TABLESPACE (System): substitui todas as cotas de tablespace individual e fornece uma cota ilimitada ao usuário em todos os tablespaces incluindo os tablespaces SYSTEM e SYSAUX, este privilegio deve ser concedido com MUITO cuidado

Não forneça cota aos usuários no tablespace System ou SYSAUX, Em geral, somente usuário SYS e SYSTEM tem permissões para criar objetos no tablespace SYSTEM ou SYSAUX.

Os usuários não precisam de cota em seus tablespaces temporários atribuídos ou em qualquer tablespace de undo.

Atribuições

As atribuições são feitas para controlar privilégios, são grupos nomeados de privilégios concedidos a usuários ou á outras atribuições, tem um gerenciamento mais fácil, dinâmico e disponibilidade seletiva, e também podem ser concedidos pelo sistema operacional.

Elas simplificam o gerenciamento de privilégios, assim podendo criar uma atribuição e dar como privilegio ao usuário ou até a outros privilégios também, fácil inserção e também fácil revogar o privilegio, se os privilégios associados mudarem eles automaticamente mudam,

 

Nomeando Objetos de Banco de Dados

Os nomes dos banco de dados devem conter de 1 a 30 bytes com as exceções, os nomes de banco de dados são limitados a 8 bytes, e os nomes de links de banco de dados podem ter 128 bytes,  os nomes sem aspas não podem ser palavras reservadas, as palavras aceitas são, (caracteres alfa numéricos, Sublinhado _ , Cifrão $, Cerquilha #)devem começar com um caractere alfabético do conjunto de caracteres do banco de dados, os nomes são armazenados em maiúsculas, os nomes não são case sensitive Oracle, os nomes com aspas, são case sensitive criados com aspas duplas antes e depois do nome, dois objetos não podem ter o mesmo nome no mesmo namespace,

Os seguintes Itens abaixo estão no mesmo Namespace:

§  Tabelas

§  Viwes

§  Sequencias

§  Sinonimos particulares

§  Procedures stand-alone

§  Funçoes stand-alone armazenadas

§  Packages

§  Views materializadas

§  Tipos definidos pelo  usuário

 

Os seguintes Itens abaixo tem seu próprio Namespace:

§  Indices

§  Constraints

§  Clusters

§  Trigers de banco de Dados

§  Links para bancos de dados particulares

§  Dimensões

 

O banco de dados usa namespaces para resolver referencias de objetos de esquema, quando você faz referencia a um objeto em uma instrução SQL, considera o contexto dessa instrução e localiza o objeto no namespace adequado, Após localizar o objeto, o Oracle executa a operação especifica pela instrução no objeto, se o objeto nomeado não puder ser encontrado no namespace adequado, o Oracle retornará um erro, como as tabelas e views estão no mesmo namespace, uma tabela e uma view contidas no mesmo esquema não podem ter o mesmo nome, Contudo, como as tabelas e índices estão em namespaces distintos, uma tabela e um índice no mesmo esquema podem ter o mesmo nome, cada esquema do banco de dados tem seus próprios namespaces para os objetos nele contidos, por exemplo que duas tabelas contidas em esquemas distintos estão diferentes em namespaces e podem ter o mesmo nome

Existem alguns tipos de Dados: CHAR, VARCHAR, DATE, NUMBER, FLOAT, INTEGER, NCHAR, NVARCHAR2, LONG, LONG RAW, RAW, ROWID, UROWID, BLOB, CLOB, NCLOB, BFILE, TIMESTAMP

Tabelas: consistem na unidade básica de armazenamento de dados em um banco de dados, ela contem todos os dados acessíveis pelo usuário, cada tabela possui colunas e linhas,

                Contraints, são usadas para impôr restrições quanto a entrada de valores nas colunas

§  NOT NULL: Por default as colunas aceitam valores nulos que são a ausência de valores para você definir que uma coluna necessita de qualquer valor declare ela como NOT NULL

§  UNIQUE: exige que os valores sejam exclusivos, isto é duas linhas não podem ter o mesmo valor, permite valor nulo

§  PRIMARY KEY: duas linhas não podem ter o mesmo valores e as colunas de chave primaria não permitem valores nulos

Indices: São estruturas especiais associadas as tabelas, é possível cria-los para melhorar o desempenho da recuperação de dados, um índice Oracle fornece um caminho direto aos dados de uma tabela, é possível criar índices de forma explicita ou implícita por meio de constraints incluídas em uma tabela,

Viwe: representação dos dados em uma ou mais tabelas ou outras viwes, podem ser consideradas como consultas armazenadas, na verdade, as viwes não contem dados, em vez disso, deveriam seus dados das tabelas nas quais são baseada, essas tabelas são chamadas de tabela-base-viwes,

Sequencia: é um objeto do banco de dados com base no qual vários usuários podem gerar valores inteiros exclusivo, em geral você deve usar sequencias para gerar valores de chave primaria,

§  Name: use as regras de nomeação abordadas anteriormente

§  Schema: é o proprietário da sequencia

§  Type: Uma sequencia pode ser crescente ou decrescente

§  Maximun Value: o valor máximo pode ter 28 digitos ou menos, deve ser maior que os valores contidos em minimun values e initial, o valor Unlimited é igual a 10 elevado a 27 para crescente ou -1 para decrescente, o default é Unlimited

§  Minimun Value: o valor mínimo da squencia, esse valor inteiro pode ter 28 digitos ou menos deve ser menor ou igual ao valor Initial, e menor que o maximun Value, o uso de Unlimited indica o valor 1 para sequencia crescente ou 10 elevado a -1026 para sequencia decrescente, o default é Unlimited

§  Interval: intervalo entre números da sequencia, pode ser qualquer numero positivo ou negativo, e pode ter de 28 digitos a 1 o default é 1

§  Initial: primeiro numeor da sequencia

§  Cycle Values: Depois que a suquencia atinge seu valor máximo, ela gera seu valor mínimo, depois que uma squencia decrescente alcança seu valor mínimo ela gera seu valor máximo. Se esta opção for escolhida, um erro será retornado se você tentar recuperar um valr depois que a sequencia se esgotar

§  Order Values: Garante que números de sequencia sejam criadas por ordem de solicitação, é bom o uso com timestamps,

§  Cache Options: Especifica quantos valores da sequencia o oracle pré aloca e mantem na memoria para agilizar o acesso, esse valor inteiro pode ter 28 digitos ou menos, o valor mínimo para esse parâmetro é 2, para sequencias que realizam ciclos esse valor deve ser menor que o numero de valores do ciclo, você não pode armazenar no cache uuma quantidade de valores maior que é possível encaixar em determinado ciclo de números de sequencia.

Manipulando Dados por meio de Instruções

Insert: Criar uma linha de cada vez, inserir varias linhas de outra tabela;

Update: Altera linhas de uma tabela;

Delete: remove linhas da tabela;

Commit; torna a alteração permanente;

Rollback: Desfaz a alteração;

 

Constraint de integridade e DML

Colunas FOREIGN KEY

                                Insert e Update: o valor deve existir na tabela mãe;

                                Delete: Não é possível deletar uma linha da tabela mãe que tem pelo menos uma linha fazendo referencia a ela;

Colunas NOT NULL:

                                Insert; Não é possível usar insert sem um valor;

                                Update: não é possível modificar o valor para NULL;

 

 

 

Colunas de chave UNIQUE

                Insert e update: Não podem ter o mesmo valor que qualquer outra coluna da tabela, exceto nulo, cada valor nulo é considerado exclusivo, portanto todas as linhas podem ter esse valor em uma coluna com uma constraint de chave UNIQUE;

Colunas PRIMARY KEY

                Aplicam as regras para chave UNIQUE e as colunas NOT NULL

Colunas CHECK

                Insert e Update: Os valores devem atender a condição Constraint;

 

Data Pump Export

Permite a transferência de dados em alta velocidade de um banco para o outro,

·         Banco de Dados: Exporta o banco de dados FULL por inteiro, chamada de exportação completa, os esquemas de sistema a seguir não são exportados como parte de uma exportação completa, pois os metadados neles contidos são exportados como parte de outros objetos do conjunto de arquivos dump; SYS, ORDSYS, ORDPLUGINS, CTXSYS, MDSYS, LBASYS e XBD, esse modo requer a atribuição EXP_FULL_DATABASE;

·         Esquemas: Exporta todos os objetos de um ou mais esquemas, Se não tiver a atribuição EXP_FULL_DATABASE, você só poderá especificar o seu próprio esquema, as referencias cruzadas entre esquemas não são exportadas, a menos que o esquema a que foi feita referencia também esteja especificado na lista de esquema a serem exportados;

·         Tabelas:  é descarregado apenas um conjunto especifico de tabelas, de partições e de seus objetos dependentes, você deve ter a atribuição EXP_FULL_DATABASE

Exemplos:

No prompt de comando:

Exporte e Importe Tabelas:

 

expdp scott/tiger tables=EMP,DEPT directory=TEST_DIR dumpfile=EMP_DEPT.dmp logfile=expdpEMP_DEPT.log (EXPORTE)

 

impdp scott/tiger tables=EMP,DEPT directory=TEST_DIR dumpfile=EMP_DEPT.dmp logfile=impdpEMP_DEPT.log (IMPORTE)

 

  

Exporte e Importe SCHEMA

 

expdp scott/tiger schemas=SCOTT directory=TEST_DIR dumpfile=SCOTT.dmp logfile=expdpSCOTT.log ( Exporte )

 

impdp scott/tiger schemas=SCOTT directory=TEST_DIR dumpfile=SCOTT.dmp logfile=impdpSCOTT.log (Importe )

 

Exporte e Importe Data base

 

expdp system/oracle full=Y directory=TEST_DIR dumpfile=DB10G.dmp logfile=expdpDB10G.log

 

impdp system/oracle full=Y directory=TEST_DIR dumpfile=DB10G.dmp logfile=impdpDB10G.log,

 

Use o arquivo de controle para carga de dados:

Sqlldr scott/tiger@dbdom control=c:\oracle\ulcase6.ctl log=c:\oracle\case1.log direct=y

 

Data Pump Import

É usado para carregar os dados exportados pelo Data Pump Export

 

Objetos DIRECTORY

O Utilitário Data Pump é baseado em servidor ( e não em cliente ), arquivos de dump , arquivos de log e arquivos SQL são acessados em relação aos caminhos de diretório baseados em servidor, esse utilitário requer que você especifique caminhos de diretório como objetos de diretório, esses objetos mapeiam nomes para um caminho de diretório no sistema de arquivos, use a instrução CREATE DIRECTORY para criar um objeto de diretório, esse objeto especifica um apelido para um diretório no sistema de arquivos do servidor, é preciso ter privilégio de sistema CREATE ANY DIRECTORY, para criar diretórios,

Ao criar um diretório você automaticamente recebe privilégios de leitura e gravação de objetos no diretório, e pode conceder esses privilégios a outros usuários e outras atribuições, para ver a definição do objeto de diretório, use a viwe DBA_DIRECTORIES.

Obs: o Oracle não verifica se o diretório existe e faz distinções de maiúsculos e minúsculos, lembrando que o SO que controla a segurança dos arquivos.

 

SQL *Loader

 

             O Sql Loader carrega dados de arquivos externos em tabelas de banco de dados Oracle, ele tem um mecanismo de parse de dados avançado que impõe poucas limitações ao formato dos dados no arquivo de dados, os arquivos usados pelo SQL* Loader são os seguintes:

                    Arquivo de dados de Entrada: Lê os dados de um ou mais arquivos ( ou equivalente de arquivos no sistema operacional) especificados no arquivo de controle, são organizados por registros, o arquivo de dados especifico pode estar no formato de registro fixo, registro variável ou registro fluxo, com parâmetro INFILE, é possível especificar o formato de registro no arquivo de controle, Se nenhum formato de registro for especificado, o default será o formato de registro de fluxo;

·         Formato de registro fixo: quando todos os registros de um arquivo de dados tem o mesmo tamanho em bytes, embora esse formato seja menos felxivel, ele resulta em melhor desempenho do que o formato variável e de fluxo, é fácil de ser especificado,

·         Formato de registro variável: quando o tamanho de cada registro de um campo de caracteres é incluído no inicio de cada registro de arquivo de dados, esse formato oferece alguma flexibilidade adicional em relação ao formato de registro fixo além de uma vantagem de desempenho em relação ao formato de registro de fluxo

·         Formato de Registro de fluxo: quando os registros não são especificados por tamanho, para formar os registro, o SQL*Loader procura finalizador de registro, embora esse seja o formato mais flexível de todos, ele pode afetar o desemprenho de forma negativa, a especificação para que um arquivo de dados seja interpretado com formato de registro de flu a semelhança é esta:

INFILE <datafile_name> [] “str terminator_string”]

O valor terminator_string é especificado como char_string ou Xhex_string

                Arquivo de Controle: Onde encontrar os dados de entrada, o formato dos dados, detalhes da configuração, Gerenciamento de memoria, rejeição de registros detalhes do tratamento de carga interrompida, como manipular os dados, é um arquivo texto criado em uma linguagem compreendida pelo SQL*Loader, o arquivo informa aonde encontrar os dados, como analisa-los e interpretá-los, onde incluí-los etc. tem três sessões

·         Primeira: Opções globais, como tamanho de bind, linhas, registros  a serem ignorados e assim por diante, Clausulas INFILE para especificar onde os dados de entrar estão localizados, dados a serem carregados

·         Segunda: um ou mais blocos INTO TABLE, cada bloco contem informações sobre a tabela na qual os dados devem ser carregados, como o nome e as colunas da tabela

·         Terceira: é opcional se existir conterá dados de entrada

        Arquivo de Log: quando é iniciado é criado um arquivo de log, se esse programa não puder criar o arquivo de log, a execução será encerrada, o arquivo de log contem um resumo detalhado da carga, incluindo uma descrição dos erros ocorridos durante esta

                       Arquivo de Erros: contem registros rejeitados, pelo SQL*Loader ou pelo banco, os registros do arquivo de dados rejeitados pelo SQL *Loader quando o formato de entrada é invalidodepois que um arquivo de dados for aceito para processamento pelo SQL*Loader, será enviado ao banco para ser incluído como linha de uma tabela, se a linha for valida ele insere e não for valida ele registra como rejeitado no arquivo de erros

            Arquivo de Descarte: Ele só é criado quando necessário e somente especifica se for ativado, contem registros que foram retirados da carga por não correspo0nderem aos critérios de seleção de registro especificados no arquivo de controle,

 

  

Metodos de carga

O SQL*Loader aceita dois métodos de carga de dados:

                Caminho Convencional e Caminho Direto:

·         Caminho Convencional: Cria um array de linhas a serem inseridas e usa a instrução SQL INSERT para carregar dados, durante as cargas de caminho convencional, é efetuado parse dos registros de entrada de acordo com especificações de campo, e um array de registros é criado e inserido na tablea especificada, no arquivo de controle, os registros que não estiverem em conformidade com as especificações de campo serão rejeitados, e os registros que não correspondem aos critérios de seleção serão descartados, podem ser usadas para carregar dados em tabelas clusterizadas ou não clusterizadas, a geração redo log é controlada pelo atributo de registro para a tabela que está sendo carregada

·         Caminho Direto: Constrói blocos de dados na memoria e salva esses blocos diretamente nas extensões alocadas para a tabela que esta sendo carregada, as entradas de redo log on-line não são geradas, a menos que o banco de dados esteja em modo de ARCHIVELOG, usam especificações de campo para criar blocos inteiros de dados no banco e gravá-los diretamente nos respectivos arquivos de dados, acima da HWM (High-Water Mark) é o ponto mais alto em que os dados foram gravados na tabela até o momento, ignora cache de buffer de banco e acessa a SGA somente para gerenciamento de extenções e ajuste da HMW

 

Comparação entre as duas

 

Carga convencional usa commit para tornas as alterações permanentes

Carga Caminho Direto usa salvamento

 

Carga convencional sempre são geradas entrada de Redo

Carga Caminho Direto gera redo apenas em condições especificas

 

Carga Convencional Impõe todas as contraints

Carga Caminho Diret Impoe apenas Primery Key, UNIQUE e NOT NULL

 

Carga Convencional Triggers INSERT são acionados

Carga Caminho Direto Tirger INSERT não são acionados

 

Carga Convencional Podem fazer cargas em tables clusterizadas

Carga Caminho Direto Não faz cargas em tables clusterizadas

 

Carga convencional Outros Usuarios podem fazer alterações em tabelas

Carga Caminho Direto Outros usuários NÃO podem fazer alterações em tabelas

PL/SQL

 

É uma linguagem de programação de 4º geração de propriedade da Oracle, que fornece extensões procedurais da linguagem SQL, independente de sistema operacional e hardware, é possível manipular dados com instruções SQL e controlar o fluxo do programa com construtor procedurais, podendo declarar constantes e variáveis, definir procedures e functions, usar conjuntos e tipos de objetos, além de interceptar erros de runtime.

 

Os tipo de objetos do PL/SQL são:

§  Package: são o conjunto (agrupamentos) de procedures e functions relacionadas logicamente, essa parte de um package também é denominada especificação, ou spec, e é a interface com as aplicações, ela declara os tipos, as variáveis, as constraints, as exceções, os cursores e os subprogramas disponíveis para uso, o agrupamento oferece vantagem em termos de desempenho e manutenção

§  Package body: Define totalmente os cursores e os subprogramas, e implementa a especificação, o corpo armazena detalhes de implementação e declarações privadas que permanecem ocultas para aplicação, pode ser alterado e recompilado, é nesse local que as operações são executadas, é possível criar uma especificação sem um corpo mas não um ciorpo sem especificação, podem ser encapsulados para ocultar detalhes de código, Wrap é um programa Stand-alone que oculta o código fonte PL/SQL, dessa maneira é possível fornecer aplicações PL/SQL sem expor esse codigo

§  Type body: um conjunto de métodos ( procedures e functions associadas aos tipos de dados definidos pelo usuário,)

§  Procedure: São blocos PL/SQL que executam uma e ação especifica, assim como a functions as procedures podem aceitar valores de entrada e executar instruções condicionais como IF-THEN, CASE e LOOP

§  Function: São blocos PL/SQL que retornam um único valor usando o comando RETURN PL/SQL, são usadas para calcular um valor, há diversas functions internas como SYSDATE, SUM, AVG e TO_DATE, deve conter a instrução RETURN

§  Trigger: São Blocos PL/SQL executados quando ocorre um evento especifico no banco de dados, esses eventos podem se basear em uma tabela, como quando uma linha é inserida na tabela, eles também podem ser eventos de banco de dados como quando um usuário efetua login no banco, permitem varias ações, como inserção de uma tabela, o login do usuário no banco, tentativa de eliminação da tabela ou alteração de definição de auditoria, os triggers podem chamar os procedures ou functions, geralmente colocam códigos curtos nos triggers e mantem os códigos longos em outros packages

 

Segurança do Banco de Dados

 

Um sistema seguro garante a confidencialidade dos dados nele contidos, a segurança envolve diversos aspectos assim como:

·         Restrições de acesso aos dados e serviços: nem todos os usuários devem ter acesso a todos os dados, dependendo das informações armazenadas no banco, talvez seja necessário restringir o acesso os dados pessoais devem ser protegidos contra acesso não autorizado, o Oracle oferece controle extremamente detalhado de autorização para limitar o acesso ao banco, a restrição de acesso deve incluir a aplicação do principio de pivilégio mínimo,

·         Autenticação dos usuários: para impor controle de acesso o sistema tem que saber quem esta tentando entrar, a autenticação reconhecida pode tornar inúteis todas as outras precauções, a forma básica é exigir que o usuário informe alguma informação conhecida como uma senha, a garantia de que a senha sigam regras simples podem aumentar significamente a segurança do sistema, um exemplo mais forte é exigir algum certificado ou token, uma forma ainda mais forte é identificar o usuário a partir de uma característica biométrica, o Oracle fornece suporte a token, certificado e biometria, por meio da advanced security option, as contas de usuários não usadas devem se bloqueadas á favor de segurança do sistema,

·         Monitoração de atividade suspeitas: Até mesmo os usuários autenticados autorizados podem comprometer o sistema algumas vezes, a identificação de uma atividade de banco incomun, como funcionário que de repente começa a consultar grandes volumes de dados de cartões de credito é um dos primeiros passos para detectar o roubo de informações, o Oracle fornece um amplo conjunto de ferramentas de auditoria para controlar a atividade do usuários e identificar técnicas suspeitas

  

Aplicar o Princípio do Privilegio mínimo

O princípio de privilégio mínimo significa que os usuários só devem receber os privilégios necessários para concluir uma tarefa com eficiência, isso reduz as chances de que eles modifiquem ou exibam, de forma acidental ou mal-intencionada, dados que eles não devem ter o privilégio para modificar ou exibir,

·         Proteger dicionário de dados: os não administradores não precisam ter acesso ao dicionário de dados, mas poderão ter acesso se você conceder privilégios de sistema ANY TABLE, como por exemplo SELECT ANY TABLE e UPDATE ANY TABLE, o dicionário contem informações importantes aonde usuários podem danificar ou tentar invadir o sistema, para isentar o ANY TABLE defina o parâmetro 07_DICTIONARY_ACCESSIBILTY = FALSE, para dar o acesso para não administradores que precisam acessar o dicionário de dados você pode usar o GRANT ou concedendo o privilégio SELECT ANY DICTIONARY, o valor default para o 07_DICTIONARY_ACESSIBILITY é FALSE, entretanto em versões 8i e anteriores é TRUE, tendo que manualmente ativar para o FALSE para garantir a segurança do dicionário de dados

·         Revogar os privilégios desnecessários de PUBLIC: Revogue atribuições e privilégios desnecessários do grupo de usuários PUBLIC, esses privilégios incluem o EXECUTE em diversos packages PL/SQL, no qual pode permitir que um usuário com privilegio mínimo acesse e execute packages que não devem ser acessados por ele, vários packages DBMS e UTL são instalados com o privilégio EXECUTE concedido ao PUBLIC você deve revogar as permissões e privilégios e conceder a cada usuário que necessita dele, a restrição de acesso do PUBLIC afeta a todos os usuários, se a restrição não for um processo muito pratico, você também pode usar a auditoria do acesso, abaixo uma lista dos packages mais avançados que podem ser utilizado: UTL_SMTP, UTL_TCP, UTL_HTTP, UTL_FILE, DBMS_OBFUSCATION_TOOLKIT

·         Restringir os diretórios que os usuários podem acessar: O parâmetro de configuração UTL_FILE_DIR designa em quais diretórios do sistema o código PL/SQL pode fazer leituras e gravações, Por default nenhum diretório poderá ser acessado, os privilégios de sistema operacional ainda se aplicam, os diretórios que não poderiam ser acessados pelo usuário que iniciou o banco de dados ainda permanecem inacessíveis, independentemente da definição de UTL_FILE_DIR, a instancia não verifica se os diretórios existem, então você pode alterar o parâmetro e criar os diretórios depois, como todos os usuário PL/SQL podem ler ou gravar em todos os arquivos especificados por esse parâmetro, a confiabilidade desses usuários deverá se basear nas informações dos diretórios especificados pelos parâmetros, os diretórios listados também devem poder ser acessados pela instancia Oracle,

·         Limitar os usuários com privilégios administrativos: Nunca conceda aos usuários do banco de dados mais privilégios do que necessário, para implementar o privilegio mínimo, restrinja os seguintes tipos de privilégios:

o   Concessões de privilégios de sistema e de objeto

o   Conexões com o banco com privilégios de SYS, como SYSDBA e SYSOPER

o   Outros privilegios de DBA como DROP ANY TABLE

SELECT * FROM V$PWFILE_USERS ( para verificar os usuários com privilégios de DBA )

·         Restringir autenticação remota do banco de dados: Só utilize autenticações remotas quando tiver certeza de que todos os clientes autenticam os usuários de forma adequada, Processo de autenticação remota:

o   O usuário do banco é autenticado externamente

o   O sistema remoto autentica o usuário

o   O usuário efetua login no banco sem autenticação adicional

Para desativar, verifique se o seguinte parâmetro de inicialização da instancia está configurado com sua definição default: REMOTE_OS_AUTHENT = FALSE

Gerenciar contas de usuário default

O Oracle é instalado com diversas contas de usuário de servidor de banco, essas contas são usadas para armazenar dados e possuem objetos de código PL/SQL ou Java, a fim de impedir conexões de banco de dados, quando o DBCA é usado para criar um banco ele bloqueia e expira automaticamente todas as contas de usuário de banco default, exceto:

·         SYS

·         SYSTEM

·         DBSNMP

·         SYSMAN

O Oracle oferece suporte a criação de banco personalizados com script, muitas aplicações esperam que seu banco seja configurado de determinada maneira e automatizam essa configuração usando a criação de banco com script, é possível que os bancos criados dessa forma não bloqueiam as contas default, além disso varias aplicações criam contas de usuário que devem ser bloqueadas, validem se essas contas desbloqueadas estão realmente sendo usadas para conexões de banco em vez de apenas para o armazenamento de dados.

  

Implementar recursos de Segurança de Senha Padrão:

·         Bloqueio de conta: ativa o bloqueio automático da conta quando o usuário não consegue fazer o logon após o numero especifico de tentativas, o valor esta configurado em FAILED_LOGIN_ATTEMPTS, depois de bloqueado ficara por um tempo bloqueado, o tempo para a conta ser debloqueada esta especificado em PASSWORD_LOCK_TIME, ou deverá ser desbloqueado pelo comando ALTER USER;

·         Expiração de vencimento de senha determina um tempo de vida útil para cada senha, pode ser especificado através de PASSWORD_GRACE_TIME, que tem inicio após a primeira tentativa de logon, depois da expiração da senha é gerado um aviso, se o usuário não trocar a senha a conta será bloqueada;

·         Histórico de senha: Verifica a nova senha para que ela não seja reutilizada, em PASSWORD_REUSE_TIME, especifica que o usuário não pode reutilizar uma senha por determinado numero de dias e PASSWORD_REUSE_MAX, especifica o numero de alterações de senha necessárias antes de a senha atual poder ser reutilizada

·         Verificação da complexidade da senha: verifica se a senha atende as determinadas regras de senha,

o   VERIFY_FUNCTION

§  Tamanho mínimo de quatro caracteres;

§  Não pode ser igual ao nome do usuário;

§  Deve ter no mínimo um caractere alfabético, um numérico e um especial;

§  Deve ter pelo menos três letras diferentes da anteriores;

 

 Auditoria

O Oracle fornece três tipos de auditoria, o administrador pode fazer auditoria de todas as ações que ocorrem no banco de dados, a auditoria deve ter um foco especifico para que somente os eventos relevantes sejam capturados, dessa maneira ele terá um impacto mínimo no desempenho do sistema, quando não há um foco a auditoria pode afetar o desempenho.

·         Auditoria de banco de dados: captura varias informações sobre o evento auditado, incluindo a ocorrência do evento, quando ele ocorre, o usuário que gerou o evento auditado e em qual maquina cliente o usuário estava quando o evento ocorreu;

·         Auditoria baseada em valor: no caso de alteração de dados (inserção, atualização e deleção) este tipo de auditoria se estende a auditoria de banco de dados padrão, capturando não só a ocorrência do evento auditado como também os valores reais inseridos, atualizados ou deletados, a auditoria baseada em valor é implementada através de triggers de banco de dados;

·         FGA: (fine-gramed-auditing) para fazer auditoria de instruções SQL, a FGA estende a auditoria de banco de dados padrão, capturando a instrução SQL real emitida em vez de apenas a ocorrência da ação,

 

  

Auditoria de Banco de dados Padrão

Ativada por meio do parâmetro AUDIT_TRAIL

·         NONE: Desativa a coleta de registros de auditorias

·         DB: Ativa a auditoria com registros armazenados no banco de dados, armazenado em DBA_UDIT_TRAIL

·         OS: Ativa a auditoria com os registros armazenados na trilha de auditoria do sistema operacional

Especificando Opções de auditoria

 

- Auditoria de instruções  SQL:

AUDIT table;

- Auditoria (não especifica e específica) dos privilégios do sistema

                AUDIT select any table, create any trigger;

                AUDIT select any table BY hr BY SESSION;

- Auditoria (não especifica e específica) dos privilégios de objeto

AUDIT ALL on hr.employees;

                AUDIT UPDATE, DELETE on hr.employees BY ACCESS

- Auditoria de Sessões:

AUDIT session whenever not sucessful;

 

DBA_STMT_AUDIT_OPTS e DBA_PRIV_AUDIT_OPTS contem somente registros de opções de auditoria de instruções ou de privilégios especifico,

DBA_OBJ_AUDIT_OPTS contem um registro por objeto que pode ser auditado independentemente das opções de auditoria de objeto especificado, a viwer mostra uma coluna para cada opção que pode ser auditada,

 

 

Depois que o administrador ativar a auditoria de banco de dados (com o parâmetro AUDIT_TRAIL) e especificar opções de auditoria (com instruções SQL conforme mostrado nas paginas anteriores) o banco de dados começará a coletar informações de auditoria, se o AUDIT_TRAIL estiver definido como OS, será gravado no sistema operacional se for Windows será no log de eventos se for Unix será gravado no caminho que estiver configurado no arquivo AUDIT_FILE_DEST, pressuponho que AUDIT_TRAIL esteja definido como DB, os registros serão armazenado em uma tabela que faz parte do esquema SYS, a manutenção da trilha de auditoria é uma tarefa importante, dependendo do foco das opções de auditoria, o tamanho da trilha de auditoria poderá aumentar muito, de forma bastante rápida, a manutenção inadequada da trilha de auditoria poderá resultar em um grande consumo de espaço, o que afetará o desempenho do sistema,

 

 

Auditoria baseada em valor


A auditoria do banco de dados registra que operações de inserção, atualização e deleção ocorreram nos objetos auditados, mas não captura os valores reais que foram alterados, a auditoria baseada em valor estende a auditoria de banco de dados, capturando esses valores, a auditoria baseada em valor utiliza triggers, quando um usuário insere, atualiza ou deleta dados de uma tabela com o trigger adequado anexado, o trigger atua no segundo plano a fim de copiar as informações de auditoria para uma tabela designada para conter essas informações, a auditoria baseada em valor costuma degradar mais o desempenho do que a auditoria de banco de dados, porque o código do trigger deve ser executado toda vez que ocorre uma operação de inserção, atualização ou deleção, a auditoria baseada em valor só deve ser usada quando a auditoria padrão for insuficiente,

 

FGA

Monitora o acesso aos dados com base no conteúdo, faz auditoria de SELECT ou de INSERT, UPDATE, DELETE, pode ser vinculada a uma tabela ou viwer, pode acionar um procedure, é administrada com o package DBMS_FGA,

A FGA permite a captura das instruções SQL reais que consultam ou manipulam dados, ela também permite que a auditoria tenha um foco mais limitado do que a auditoria padrão ou de valor, as opções da FGA podem se basear em tabelas ou viwes, elas também podem ser condicionadas de modo que as auditorias sejam capturadas somente se determinadas especificações definidas pelo administrador forem atendidas, não exige uso de triggers, o impacto de desempenho é semelhante ao de auditoria de banco de dados, o administrador usa o package DBMS_FGA, e se caso for feito uma pesquisa que retorna milhares de linhas gera apenas um registro de auditoria,

 

Package DBMS_FGA

É uma ferramenta de administração das functions de auditoria detalhada, são necessários privilégios de execução nesse package para administrar as politicas de auditoria detalhada, como trilha de auditoria detalhada poderá conter informações confidenciais, os privilégios de execução nesse package devem ser reservados somente aos administradores


Comandos para ativar, desativar e deletar uma politica FGA

Ativar

Dbms_fga.enable_policy (

Object_schema       => ‘hr’,

Object_name           => ‘ employees’,

Policy_name             => ‘ audit_emps_salary’);

 

Desativar

Dbms_fga.disable_policy (

Object_schema       => ‘hr’,

Object_name           => ‘ employees’,

Policy_name             => ‘ audit_emps_salary’);

 

Eliminar

Dbms_fga.Drop_policy (

Object_schema       => ‘hr’,

Object_name           => ‘ employees’,

Policy_name             => ‘ audit_emps_salary’);

                        

  

Views de Dicionário de dados


 

As entradas da auditoria FGA são registradas em uma tabela separada das auditorias de objeto ou de privilégio, as entradas são registradas na view DBA_FGA_AUDIT_TRAIL, as outras três views listadas contem definições de politica,

 

Fazendo auditoria dos usuários SYSDBA e SYSOPER

 

Os usuários com privilégios SYSDBA e SYSOPER podem se conectar ao banco de dados fechado

-          A trilha de auditoria deve ser armazenada fora do banco de dados

-          A conexão como SYSDBA ou SYSOPER é sempre auditada

-          Ative a auditoria adicional das ações de SYSDBA ou de SYSOPER com audit_sys_operations=TRUE o default é FALSE

-          Controle a trilha de auditoria com audit_file_dest, O defaul é:

o   $ORALE_HOME/rdbms/audit

o   Log de evento do Windows

 

 Listener

 

Oracle Net Services


O Oracle Net services permite conexões de rede entre uma aplicação cliente ou de camada intermediaria e o Oracle Database Server, uma vez estabelecida a conexão o Oracle net server como corrier de dados entre o usuário e o Database, bem como realizar trocas entre eles, sendo necessário o JDBC que esta configurado em cada computador que tenta a conexão,

Na maquina cliente o Oracle Net é um componente background acessado por qualquer aplicação que precise estabelecer conexão com o banco de dados, o usuário nunca vê o Oracle net apenas a aplicação que esta sendo utilizada,

No servidor de banco de dados o Oracle Net possui um processo ativo chamado Listener, o Listener é responsável pela coordenação das conexões entre o banco de dados e as aplicações externas, sem o Listener as conexões externas não são possíveis,

Embora o uso de Oracle Net seja para conexões de entrada também é possível configurar serviços para permitir acesso a procedures e bibliotecas de códigos externos (EXTPROC) bem como para conectar a instancia Oracle a fonte de dados não Oracle, como Sybase, Infomix, DB2 e SQL SERVER, por meio de Oracle Heterogeneous Services,

O Oracle Net Listener é o gateway para a instancia Oracle de todas as conexões de usuários não locais, um único Listener pode utilizar varias instancias de banco de dados e milhares de conexões clientes,

O Oracle Net Listener é controlado pela linha de comando lsnrctl, os listener são configurados pelo Data base Control, no server, o Database control controla a configuração do listener, bem como parâmetros gerais, como proteção por senha ou locais de arquivos log,

Pode ser configurado via VI Notepad ou qualquer outro editor de texto,

Cada Listener deve ter no mínimo o local aonde a atividade listening será executada, o protocolo usado Default é o TCP/IP mas temos alguns outros como: IPC, normalmente usado para conexões locais, EXTPROC, biblioteca de códigos externos e TCP/IP com SSL, informa o numero do ip e a porta,

Configuração de parâmetros adicionais: você pode configurar parâmetros adicionais como Logging e Tracing, o Logging é aonde deseja manter um log das conexões, e o tracing, e aonde deseja manter informações detalhadas das conexões se caso for a quantidade de informações que deseja coletar, e onde os arquivos de rastreamento serão armazenados,

Para que o listener encaminhe clientes a esta instancia ele precisa saber o nome da instancia e para isso ele tem duas formas de localizar,

·         Registro de Serviço dinâmico: as instancias 8i, 9i, e 10g são registradas automaticamente no listener default durante a inicialização do banco nenhuma configuração adicional é necessária para o listener default

·         Registro de Serviço Estático: versões mais antigas não são registradas automaticamente no listener e requerem um arquivo  de configuração deste contenha uma lista de todos os serviços do banco de dados que o listener utilizará, você terá que usar este arquivo nas versões mais recentes se:

o   O listener não estiver na porta default e você não quiser configurar sua instancia para registrar em uma porta default;

o   A aplicação exigir um registro de serviço estático.

Para estabelecer uma conexão com o cliente ou com a camada intermediaria, o Oracle Net requer que o cliente saiba o host em que o listener esta sendo executado, a porta que o listener esta monitorando, o protocolo que o listener esta usando o nome do serviço que o listener esta manipulando,

O Oracle Net fornece suporte a vários métodos de resolução de informações de conexão, como:

·         Conexão Facil: o usuário fornece todas as informações necessárias para conexão com o Oracle Net, como parte da string de conexão, as strings de conexão fácil tem o seguinte formato:

<username>/<password>@<hostname>:<listener port>/<service name>

                A porta do listener e o service são opcionais, se não colocar a porta será entendido a default (1521) e o serviço pressupondo que o nome do serviço seja idêntico ao de conexão,

                               SQL> connect hr/hr@db.us.oracle.com

o   Ativada por default,

o   Não requer nenhuma configuração de cliente,

o   Oferece suporte apenas um protocolo TCP/IP sem SSL,

o   Não oferece suporte a opções de conexão avançadas,

§  Failover de tempo de conexão,

§  Roteamento de origem,

§  Balanceamento de carga,

 

·         Nomeação local: o usuário oferece um apelido ao Oracle Net Services, o Oracle Net verificará em uma lista local de serviços se encontrar uma correspondência, o converterá em um nome de host, de protocolo, de porta ou de serviço, a lista local é armazenada no TNSNAMES.ORA

o   Requer um arquivo de resolução de nomes do cliente;

o   Oferece suporte a todos os protocolos Oracle Net;

o   Oferece suporte a opções de conexão avançadas;

§  Failover de tempo de conexão;

§  Roteamento de origem;

§  Balanceamento de carga;

 

·         Nomeação de Diretórios: o usuário oferece um apelido ao Oracle Net Services, o Oracle Net verificará em uma lista local de serviços se encontrar uma correspondência, o converterá em um nome de host, de protocolo, uma vantagem é que logo que um serviço novo é adicionado ao LDAP, o nome do serviço torna-se disponível aos usuários para conexão;

o   Requer o LDAP com as informações carregadas sobre resolução de nomes Oracle Net;

§  Oracle Internet Directory;

§  Serviços Microsoft Active Directory;

o   Suporta todos os protocolos Oracle Net;

o   Suporta opções de conexão avançadas;

Opções avançadas de listener

Com o failover de tempo de conexão ativado, o apelido passa a ter dois ou mais endereços de listeners listados, se o primeiro endereço não estiver disponível, tentara usar o segundo, ficara tentando ate achar um que esteja funcionado, ou ate que todos tenham falhado,

Com o Balance de carga ativado, o Oracle Net escolhe um endereço aleatoriamente na lista de endereços, em um RAC a carga de trabalho é balanceada em varias instancias do mesmo banco de dados,

O roteamento de origem permite que o tráfego seja feito com segurança através de um firewall, ele trata o endereço como uma lista de relays, conectando ao primeiro e depois solicitando que a passagem seja do primeiro ao segundo ate que o destino seja alcançado a diferença é que todos os endereços são usados sempre que uma conexão é estabelecida

Testando Conectividade do Oracle Net,

O utilitário tnsping testa os apelidos do Oracle Net Services,

§  Garante a conectividade entre o cliente e o Oracle Net Listener,

§  Não verifica se o serviço solicitado está disponível,

§  Suporta resolução de nomes da Conexão fácil,

§  Suporta a nomeação local e de diretórios,


Criando os serviços de rede (LISTENER e TNSNAME.ORA)

Como já estamos como todo o nosso banco de dados criado, vamos ter que disponibilizar aos usuários e possíveis aplicações, e para isso, precisamos do serviço ouvinte (LISTENER) e depois efetuar as configurações nas máquinas client (TNSNAMES) para acessar o banco de dados. E para isso, devemos configurar os arquivos responsáveis por essa tarefa.


Criando o Listener

A atividade a ser realizada agora é a criação do LISTENER, ou o serviço ouvinte, que é um processo separado no banco de dados que tem como responsabilidade receber as conexões dos clientes (usuários ou outras bases de dados) e gerenciar o tráfico e pedidos dessas requisições. O arquivo LISTENER.ORA que pode ser encontrado em $ORACLE_HOME/network/admin é o responsável por esse serviço, abaixo segue um exemplo de criação de um LISTENER usando protocolo TCP e disponibilizando as portas 1521 e 1522 para comunicação.

Arquivo: LISTENER.ORA

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = PELSPOS7H)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = PELSPOS7H)(PORT = 1522))

)

)

Após criar o seu arquivo listener.ora e salva-lo, deverá iniciar o serviço do listener, usando o aplicativo LSNRCTL (Listener Control), veja:

[oracle@pelspos7h admin]$ lsnrctl

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 27-FEB-2009 23:06:18

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Welcome to LSNRCTL, type "help" for information.

LSNRCTL> status

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=PELSPOS7H)(PORT=1521)))

TNS-12541: TNS:no listener

 TNS-12560: TNS:protocol adapter error

  TNS-00511: No listener

   Linux Error: 111: Connection refused

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=PELSPOS7H)(PORT=1522)))

TNS-12541: TNS:no listener

 TNS-12560: TNS:protocol adapter error

  TNS-00511: No listener

   Linux Error: 111: Connection refused

Ao verificar o atual status do serviço de LISTENER, verificamos que não está disponível, basta iniciarmos o serviço e pronto! Após a configuração nos clientes, a comunicação será possível com o banco de dados.

LSNRCTL> start LISTENER

Starting /u01/app/oracle/product/10.2.0/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 10.2.0.4.0 - Production

System parameter file is /u01/app/oracle/product/10.2.0/db_1/network/admin/listener.ora

Log messages written to /u01/app/oracle/product/10.2.0/db_1/network/log/listener.log

Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=pelspos7h)(PORT=1521)))

Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=pelspos7h)(PORT=1522)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=PELSPOS7H)(PORT=1521)))

STATUS of the LISTENER

------------------------

Alias                     LISTENER

Version                   TNSLSNR for Linux: Version 10.2.0.4.0 - Production

Start Date                27-FEB-2009 23:06:38

Uptime                    0 days 0 hr. 0 min. 0 sec

Trace Level               off

Security                  ON: Local OS Authentication

SNMP                      OFF

Listener Parameter File   /u01/app/oracle/product/10.2.0/db_1/network/admin/listener.ora

Listener Log File         /u01/app/oracle/product/10.2.0/db_1/network/log/listener.log

Listening Endpoints Summary...

  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=pelspos7h)(PORT=1521)))

  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=pelspos7h)(PORT=1522)))

The listener supports no services

The command completed successfully

Na versão do Oracle Database 10g, existe uma opção no SQL*NET de trabalhar por serviços ou SERVICE_NAME, onde deverá ser realizado outros procedimentos. Mais detalhes nesse documento Quick Start to Oracle Net Connections.


Configurando o TNSNAMES.ORA e SQLNET.ORA do cliente.

Os arquivos TNSNAMES.ORA e SQLNET.ORA são os arquivos de configuração no lado do cliente ou em algum banco de dados remoto, cada arquivo com sua respectiva função. O arquivo TNSNAMES.ORA tem como finalidade fornecer as principais informações para um serviço ouvinte, como nome do banco de dados, porta de comunicação, tipo de protocolo utilizado e host de destino. A função do arquivo SQLNET.ORA é dizer o método de conexão, habilitar a rota de específicas conexões, tipo de autenticação utilizada e fornecer um rastreamento detalhado sobre a comunicação do cliente e servidor. Ambos os arquivos podem ser encontrados em $ORACLE_HOME/network/admin. Abaixo segue um modelo que iremos utilizar.

Arquivo: SQLNET.ORA

AUTOMATIC_IPC = OFF

names.directory_path = (TNSNAMES)

names.default_domain = world

name.default_zone = world

Arquivo: TNSNAMES.ORA

ranet.WORLD =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(Host = 10.72.30.83)(Port = 1522))

)

(CONNECT_DATA =

(SID = ranet)

)

)

Caso você queira acessar o seu banco de dados de uma outra máquina que tenha o Oracle Client instalado, basta adicionar a entrada de TNS acima, mostrada no modelo do TNSNAMES.ORA e caso seja necessário, colocar as configurações de SQLNET acima.


Validação da conexão

Ao realizar todas as tarefas acima de configuração dos arquivos do SQLNET, basta validar se a conexão com o banco de dados remotamente será realizado com sucesso, para isso, basta utilizar o aplicativo TNSPING para validar. Exemplo.

[oracle@pelspos7h admin]$ tnsping ranet

TNS Ping Utility for Linux: Version 10.2.0.4.0 - Production on 27-FEB-2009 23:33:58

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:

/u01/app/oracle/product/10.2.0/db_1/network/admin/sqlnet.ora

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(Host = 10.72.30.83)(Port = 1522))) (CONNECT_DATA = (SID=ranet)))

OK (0 msec)

 

 

Servidores Dedicados e Compartilhados

Depois que a resolução de nomes Oracle Net estiver concluída, uma solicitação de conexão será passada do usuário ou da aplicação de camada intermediaria, para o Listener ele receberá um pacote CONNECT e verificará se o nome de serviço é valido, se o nome do serviço não for solicitado no caso do TNSPING o listener continuara a solicitação da conexão e não executará qualquer outra ação, se o nome for invalido o listener comunicará um erro,

§  Processo de Servidor Dedicado: Se o pacote CONNECT solicitar um nome de servidor Válido, o listener gerará um novo processo para lidar com a conexão, esse novo processo é conhecido como processo de Servidor, também chamado de processo sombra, uma vez gerado o processo o listener conecta a ele e passa as informações de inicialização, incluindo dados de endereço referentes ao processo do usuário, neste ponto o listener não lida mais com a conexão e todo o trabalho é passado para o processo do servidor, em seguida esse processo envia um pacote de RESEND de volta ao processo de usuário,

Depois que a sessão do usuário recebe o pacote RESEND, ela retransmite o pacote CONNECT, o processo do servidor verificará se as credenciais de autenticação do usuário, normalmente a senha e se forem validas uma sessão do usuário será criada,

o   Analisar e executar as instruções SQL executadas por meio de aplicação,

o   Verificar no cache de buffer do banco de dados se há blocos de dados necessários para a execução de instrução SQL,

o   Ler os blocos de dados necessários de arquivos de dados do disco na parte do cache de buffer de banco de dados da SGA, se os blocos ainda não estiverem nessa área,

o   Gerenciar toda a atividade de classificação, parte do processo do servidor chamado PGA contem uma área de memoria conhecida como área de classificação usada para efetuar a classificação

o   Retornar resultados ao processo do usuário de modo que a aplicação possa processar as informações,

Os processos de servidor também reservam memoria e esta configurado em PGA_AGGREGATE_TARGET e WORKAREA_SIZE_POLICY



 

O relacionamento é de UM para UM entre os processos de servidor e processos de usuário, cada processo de servidor consome recursos do sistema, incluindo ciclos de CPU e Memoria,

Os dados da sessão do usuário são mantidos na PGA

 




§  Processo de Servidor Compartilhado: Cada serviço que participa do servidor compartilhado tem pelo menos um dispatcher ( normalmente mais ) quando chega uma solicitação o listener não gera um processo dedicado ele mantem uma lista de dispatchers disponíveis para cada nome de serviço, juntamente com a carga de conexão, as conexões são roteadas para o dispatcher com a carga mais leve, que esteja utilizando determinado nome de serviço, os usuários permanecem conectados ao mesmo dispatcher durante toda a sessão,

Um único dispatcher pode gerenciar centenas de sessões de usuários, ele envia as solicitações para uma fila comum na SGA é armazenada na large pool a área de memoria compartilhada,

 

Processando uma solicitação:

1.       Processo Usuário encaminha a solicitação ao respectivo Dispatcher;

2.       O dispatcher coloca a solicitação na fila comum de solicitação na SGA;

3.       O próximo servidor compartilhado disponível retira a solicitação da fila e a processa;

4.       O servidor compartilhado insere a resposta na fila de respostas do dispatcher que fez a chamada, cada dispatcher possui sua própria fila de respostas;

5.       O dispatcher recupera a resposta da respectiva fila de respostas;

6.       O dispatcher retorna a resposta ao usuário.

 

Fila de solicitações: é compartilhada por todos os dispatchers, os servidores compartilhados monitoram a fila em busca de novas solicitações, é processada em base no método FIFO, sem definição de prioridade

Os dados de sessão do usuário são mantidos na SGA

 

Para configurar o servidor compartilhado, edite os parâmetros de inicialização da sua instancia, a maioria dos parâmetros opcionais tem defaults coerentes, em muitos sistemas o único parâmetro que deverá ser configurado é DISPATCHERS,

Dependendo das opções selecionadas quando você criou o banco de dados, o parâmetro DISPATCHERS já poderia ser configurado para iniciar um dispatcher a fim de entender ao banco de dados XML, o parâmetro DISPATCHERS aceita vários conjuntos de valores de formato,

Dispatchers

Especifica o numero de dispatchers que a principio são inicializados para determinado protocolo

DISPATCHERS = “(PROTOCOL=TCP) (DISPATCHERS=2) \ (PROTOCOL=IPC) (DISPATCHERS=1)”

O parametro DISPATCHERS permite que cada dispatcher tenha varios atributos, suportando uma sintaxe de nome-valor, para permitir a especificação dos atributos existentes e adicionais, independente de posição e sem distinção entre maiúsculas e minúsculas

DISPATCHERS = “(PROTOCOL=TCP) (DISPATCHERS=3)”

O único atributo de dispatcher necessário é PROTOCOL, todos os outros são opcionais

PROTOCOL (PRO / PROT), DISPATCHERS (DIS / DISP), SERVICE (SER / SERV), LISTENER (LIS / LIST), SESSIONS (SES / SESS), CONNECTIONS (CON / CONN)

§  SHARED_SERVERS: Especifica o numero mínimo de processos de servidor compartilhado criados quando uma instancia é inicializada e retidos durante a operação da instancia, a definição deste parâmetro não é muito importante porem a instancia monitora a Fila comum de solicitações e iniciará servidores compartilhados adicionais conforme necessário, uma boa conduta é reter um servidor compartilhado para cada vinte e cinco conexões de banco simultâneos, usando servidor compartilhado

§  MAX_SHARED_SERVERS: Especifica o numero máximo de processo de servidor compartilhado que podem ser iniciados, permite que servidores compartilhados sejam alocados dinamicamente com base no tamanho da fila de solicitações, esta definição é importante porque a instancia cria automaticamente processos adicionais de servidor compartilhado conforme necessário, para monitorar usando V$SHARED_SERVER_MONITOR

§  CIRCUITS: São conexões virtuais do usuários com o banco, através de dispatchers e servidores, Especifica o numero total de circuitos virtuais disponíveis para sessões de rede de entrada e saída, contribui para tamanho total da SGA, este parâmetro é definido apenas se você quiser limitar o numero total de conexões que os usuários possam estabelecer,

§  SHARED_SERVER_SESSION: Especifica o numero total de sessões permitidas para o usuário do servidor compartilhado, permite reservar as sessões do usuário para  servidores dedicados,

§  LARGE_POOL_SIZE: especifica o tamanho de bytes da large pool, o servidor compartilhado usa a large pool para armazenar informações de sessão que normalmente residem na PGA em uma sessão de servidor dedicado,

§  SESSIONS: especifica o numero máximo de sessões que podem ser criadas no sistema talvez isso precise ser ajustado para servidor compartilhado, pois agora o sistema pode atender a mais sessões

§  PROCESSES: controla o numero de processos do servidor

§  LOCAL_LISTENER: define a porta e o protocolo usada pelo listener, se o listener não usar a porta TTCP/IP na porta 1521, ou se houver vários listeners, configure LOCAL_LISTENER para que os dispatcher possam ser registrados neles,

§  NOTA: se não configurar o LARGE_POOL_SIZE o servidor Oracle usara o shared pool como memoria da sessão do usuário no servidor compartilhado,

Para verificar se os dispatchers foram registrados no listener o banco de dados foi iniciado execute lsnrctl services, verifique se esta conectado por meio de servidores compartilhados, estabelecendo uma conexão efetuando uma consulta na view V$CIRCUIT para exibir uma entrada por conexão de servidor compartilhado,

§  V$CIRCUIT:  Esta view contem informações sobre circuitos virtuais, que são conexões de usuário com o banco por meio de dispatcher e servidores, todas as conexões de servidores compartilhados criam um registro na V$CIRCUIT,

§  V$SHARED_SERVER: contem informações sobre processos de servidor compartilhado,

§  V$DISPATCHER: contem informações sobre processo de dispatcher,

§  V$SHARED_SERVER_MONITOR: contem informações para ajuste dos processos do servidor compartilhado,

§  V$QUEUE: contem informações sobre filas de solicitações e respostas,

§  V$SESSION: contem informações para cada sessão atual,

A menos que seja configurado de outra maneira as conexões Oracle Net usarão, um servidor compartilhado se houver algum disponível, se não houver nenhum disponível ele usara um servidor dedicado,

NÃO usamos servidores compartilhados quando administramos um banco de dados, em operação de backup restore, em processos de batch e operação de carga em alto volume, e também em Data Warehouse.

 

 Monitorando o Desempenho

O Oracle suporta o monitoramento Pró-ativo e Reativo, o monitoramento reativo consiste em uma resposta a um problema conhecido ou reportado, você pode começar a monitorar as métricas de desempenho em reação a reclamações dos usuários, sobre tempo de resposta, falhas da instancia ou erros localizados no log de alerta,

A meta do usuário é detectar e reparar problemas antes de afetarem a operação do sistema, a correção antes que ocorra ou pelo menos antes que sejam notados, consiste em um método pró ativo de manutenção do sistema,

O Oracle contem varias ferramentas que ajudam no monitoramento pró-ativo, duas delas são os alertas gerados pelo servidor e o ADDM,

Centenas de estatísticas de desempenho estão disponíveis por meio de Dicionário de dados, views dinâmicas de desempenho e estatísticas do otimizador,

·         Dicionário de dados fornece informações sobre consumo de espaço e o status de objetos,

·         Metricas de desempenho em tempo real que abrangem o uso de memoria, eventos de espera, throughput de dispositivo de entrada e saída e atividades da instancia estão disponíveis por meio de views dinâmicas de desempenho , também conhecidas como v$ views,

Os bancos de dados podem ser extremamente grandes, com um conjunto de dados tão grande, é essencial que a instancia localize da maneira mais eficiente possível, os dados que um usuário esteja usando, a parte da instancia que decide como localizar os dados chama-se OTIMIZADOR,

As métricas de distribuição de dados são usadas para ajudar o otimizador do Oracle a maneira mais eficiente de recuperar dados e portanto são normalmente chamadas de “estatísticas do otimizador”,

As estatisticas de otimizador que mostram a distribuição de dados em cada tabela incluem:

o   Numero de linhas;

o   Comprimento médio de linha;

o   Espaço vazio alocado para a tabela;

o   Numero de linhas encadeadas ( existentes em dois ou mais blocos em decorrência de linhas grandes ou de definições ineficientes de armazenamento );

Um exemplo seria a varredura integral de uma tabela, ler a tabela inteira para localizar uma linha especifica, ou varredura de índice, procurar a linha em um índice e depois passar diretamente para o bloco de dados da tabela que contem a linha, em tabelas menores a varredura completa chega a ser eficiente, do que procurar o índice, e depois passar para o bloco correto, em uma tabela grande será bem mais sensato buscar o índice,

 

Métricas de Dicionário de Dados

A métrica mais importante do dicionário de dados é o status do objeto, os índices e procedures precisam estar como VALID para serem usados,

Os índices podem ficar UNUSABLE de acordo a manutenção de tabelas ele contem ponteiros para localização física das linhas de dados individuais, se o DBA usar o MOVE por exemplo os ponteiros não serão mais validos e o índice não poderá ser usado ate ser reconstruído e passa a fazer consulta na tabela por varredura,

Os objetos de código PL/SQL ou procedures podem ter o status como INVALID, se o código obtiver um erro de programação, o objeto não será compilado e será marcado como INVALID, a procedure pode ser invalida se houver mudança em um objeto que ele faça referencia,

Os índices e Procedures inutilizadas requerem a intervenção do DBA para serem restaurados, os objetos PL/SQL normalmente serão recompilados automaticamente a primeira vez que forem chamados, mas precisarão da intervenção do DBA caso ocorra o erro novamente,

Objetos Inválidos e Inutilizáveis:

                Pl/sql: Se encontrar um objeto PL/SQL INVALID devido a um erro de código não há muito o que fazer até que o erro seja corrigido, agora se a procedure tiver se tornado INVALID recentemente, embora tivesse VALID em algum momento há duas opções para corrigir o problema,

1.       Não fazer nada, os objetos PL/SQL são recompilados automaticamente,

2.       Recompilar automaticamente, assim como o exemplo abaixo;

a.       ALTER PROCEDURE HR.updatesalary COMPILE;

b.      ALTER PACKATE HR.maintainemp COMPILE

c.       ALTER PACKATE HR.maintainemp COMPILE BODY

Indice: Os indices invalidos tornam-se válidos quando são reconstruídos para recalcular os ponteiros, a reconstrução de um índice inutilizável o recria em um novo local e elimina o índice anterior, segue exemplo abaixo                ;

                ALTER INDEX HR.emp_empid_pk REBUILD;

                ALTER INDEX HR.emp_empid_pk REBUILD ONLINE;

                ALTER INDEX HR.email REBUILD TABLESPACE USERS;

 

Se a clausula TABLESPACE for omitida, o indice será reconstruído no mesmo tablespace em que ela já existir, a clausula REBUILD ONLINE permite que os usuários continuem a atualizar a tabela do índice durante a reconstrução ( sem a palavra-chave ONLINE, os usuários devem esperar até que a reconstrução seja finalizada antes de executarem a instrução DML na tabela afetada) lembrando que a reconstrução do indece requer espaço em disco livre,

 

 

Estatísticas do Otimizador

 

As estatísticas do otimizador referentes as tabelas e índices são armazenadas em dicionários de dados e essas estatísticas não se destinam a fornecer dados em tempo real, elas fornecem um snapshot estaticamente correto do armazenamento e da distribuição dos dados, que o otimizador usa para tomar decisões sobre como acessar os dados, incluindo;

·         O tamanho da tabela ou do índice nos blocos do banco;

·         Numero de Linhas;

·         O tamanho médio das linhas e a contagem em cadeia ( somente tabelas );

·         Altura e numero de linhas de folha deletadas;

Se o banco for criado pelo DBCA essas estatísticas são criadas entre as 22 e as 06 uma vez por dia caso o contrario terá que ser criado na mão;

SQL> EXEC dbms_stats.gather_table_stats (‘HR’,’EMP’);

SQL> SELECT num_rows FROM dba_tables

2 WHERE owner=’HR’ AND table_name = ‘EMP’

NUM_ROWS

-----------------

214

 

Coletando estatísticas do otimizador, para ser configurado temos que usar o Enterprise manager,

·         Default Method: Oferece a opção para deletar, estimar ou calcular estatísticas, o calculo de estatísticas examina todas as linhas da tabela, a estimativa cria uma amostra estatística, para índices e tabelas pequenas o método calculo deve ser usado, para tabelas grandes geralmente uma estimativa é a melhor opção, um percentual de estimativa igual ou maior que 50% dispara um calculo, quando escolhe manualmente os valores de 5 a 15% são sufucientes,

·         Object selection: escolha os objetos para os quais serão coletadas as estatísticas, você pode selecionar tabelas ou índices individuais, ou ampliar escopos para coletar esquemas inteiros ou ate o banco completo,

·         Schedule: fornece credenciais de host e determina quando as estatísticas serão coletadas as opções são: Immediately, Scheduled Time ou Named Maintence Window,

Podemos automatizar até três tarefas repetitivas como coleta de estatísticas, lembre-se que o ato de coletar estatísticas do otimizador com frequência sufuciente para que ele possa tomar decisões adequadas sobre melhores métodos de acesso a dados;

 

 

Views Dinamicas de Desempenho

 

Existem mais de 300 viwes dinâmicas de desempenho, elas fornecem informações detalhadas de estáticas em tempo real, a contagem é reinciada toda vem que a instancia é desativada,

 

Reagindo a problemas de desempenho: a pagina performance do Enterprise Manager, é o melhor lugar para se começar, esta pagina é dividida em 3 partes,

·         Host: métricas de servidor que mostram o numero de processos de espera e o volume de paginação de memoria

·         Active Sessions: Waiting and Working: visão geral do desempenho da instancia que mostra métricas agrupadas a partir de varias categorias, se uma categoria estiver consumindo grande parte do tempo de espera da instancia a categorias será o local onde iniciar o diagnostico e a solução de problemas;

·         Instance Throghtput: informações sobre sessões atuais geração de redo e atividade de leitura de arquivo de dados;

Voce pode fazer o Drill down em cada uma dessas seções clicando na métrica de interesse, o drill-down no tempo de espera de configuração revela que a maior parte desse tempo se destina a obter espaço no buffer de redo logs, nesse caso o DBA precisa determinar se o problema ocorreu no próprio buffer log, precisando de mais memoria alocada ou no redo log o tempo de gravação pode ser muito longo para que o LGWR mantenha a demanda,

 

A contenção de entrada/saída é um gargalo de desempenho,

 

·         Colocar os arquivos de redo log em discos separados

·         Separar arquivos de tablespace de índices e de dados

 

  

Manutenção Pró-Ativa

 

O Oracle exibe alertas sobre problemas através do console do Entreprise manager ou por email, você também pode definir limites para o sistema em várias das métricas pertinentes as notificações previas permitem responder rapidamente aos problemas e normalmente resolve-los antes que os usuários notem, abaixo algumas métricas principais;

·         Avarage File Read Time

·         Dump Area Used

·         Response Time

·         SQL Response Time

·         Tablespace Used

·         Wait Time

 

É possível designar dois limites a cada Métrica, o da advertência e o critico, quando os limites são atingidos alertas são disparados por notificações que aparecem na região Alerts da home page Database Control, ou alertas de email,

Os alertas críticos devem ser usados para indicar problemas que requerem atenção imediata, é possível automatizar alguma ações quando os limites críticos forem atingidos

 

Advisors de Ajuste e Diagnostico

 

O Oracle contem vários advisors de ajuste de diagnostico:

·         ADDM: Especialista baseado em servidor, que analisa o desempenho do banco a cada 60 minutos, o objetivo do ADDM é detectar antecipadamente possíveis gargalos no sistema e recomendar correções antes que haja uma redução brusca de desempenho;

·         SQL Tunning Advisor: este advisor analisa uma instrução SQL individual e faz recomendações para melhorar seu desempenho, as recomendações podem incluir ações como recriação da instrução, alteração da configuração da instancia ou inclusão de índices, o SQL Tunning Advisor não é chamado diretamente, em vez disso ele é chamado a partir de outras ferramentas, como o TOP SQL ou o TOP Sessions, para ajudar a otimizar instruções SQL de alto impacto, o objetivo é identificar as instruções SQL de alto impacto e fazer sugestões sobre como melhorar seu desempenho,

·         SQL Access Advisor: este advisor analisa todas as instruções SQL executada em determinado período e sugere a criação de índices adicionais ou viwes materializadas para melhorar o desempenho

·         Memory Advisor: Na verdade este advisor consiste em um conjunto de várias funções de supervisão que ajudam a determinar as melhores definições para o shared pool, o cache de buffer de banco e a PGA, além das funções de adivesor essa pagina fornece um ponto central de controle para o large pool e o java pool, um detalhe que se a SGA for definida com um valor muito pequeno haverá uma redução brusca no desempenho assim como se for definida com muito mais , este advisor permite localizar e definir facilmente os componentes da SGA, é importante lembrar que não vale a pena alocar tanta memoria ao SGA e fazer o sistema usar o SWAP,

·         MTTR: ajuda a definir o tempo necessário para a recuperação do banco após uma falha na instancia,

·         Segment Advisor: procura tabelas e índices que estejam consumindo mais espaço que o necessário, ele verifica o consumo de espaço ineficiente no nível de tablespace e de esquema e produz scripts para reduzir esse consumo onde possível,

·         Undo Management Advisor: ajuda a determinar o tamanho do tablespace de undo necessário para oferecer suporte a determinado período de retenção.

 

AWR – Automatic Workload Repository

 

Por default a cada 60 minutos o banco captura automaticamente informações, estatísticas da SGA e as armazena na AWR, na forma de snapshot, esses snapshots são armazenado em disco e retidos por 7 dias, podemos usar o package DBMS_WORKLOAD_REPOSITORY,

Defina o nível de coleta como ALL, ela coleta os planos de execução e as estatísticas de sincronização SQL, que aprimoram as recomendações dos advisors de SQL, quando o ajuste estiver correto essa definição devera ser alterada para tipical,

O nível de coleta como basic, desativa a maior parte de funcionamento do ADDM

 

 

ADDM – Automatic Database Diagnostic Monitor

È executado a cada snapshot do AWR, Monitora a instancia e detecta gargalos, os resultados são armazenados na AWR,

Faz analise no período correspondente a os dois últimos snapshots, ele monitora a instancia de forma pró ativa e detecta a maioria dos gargalos antes que se tornem problemas mais sérios, ele recomenda soluções e até quantifica os benefícios referentes as recomendações, além de serem armazenados no AWR podem ser acessados pelo Enterprise manager,

Gerenciamento de Undo

Os dados de undo são uma cópia dos dados originais, antes da modificação, capturados para cada transação cujos dados são alterados e retidos pelo menos até que a transação seja concluída, são usados para oferecer suporte a operações de roolback, consultas de flashback e com leitura consistente e recuperação de falhas em transações, O Oracle salva o antigo valor dados de UNDO, quando o processo altera os dados de um banco de dados, armazena os dados da maneira que encontrava-se antes de serem modificados, a captura dos dados de undo permite que usuários efetuem rollback,  flashback com leitura consistente, as leituras consistente são iniciadas antes de uma alteração nos dados e finalizadas após a alteração, o Oracle fornece resultados consistentes com os dados a partir do inicio de uma consulta, para que uma consulta com leitura consistente seja bem sucedida, as informações originais devem existir como informações de undo, desde que as  informações de undo sejam retidas, o Oracle reconstrói os dados para satisfazer as consultas com leitura consistente, as consultas de flashback exigem uma imagem de como eram no passado, desde que existam informações de undo referentes a esse momento no passado, podendo ser concluídas com sucesso, os dados de undo também são usados para recuperação de falhas em transações, ocorre falha na transação quando um usuário termina de forma anormal ( decorrente de erros na rede ou na maquina do usuário ) antes do commit ou rollback, as falhas ocorrem também com falhas na instancia, caso haja falha na transação o Oracle reverte as alterações, restaurando os dados originais.

As informações de undo são retidas para todas as informações, pelo menos até que elas sejam encerradas da seguinte maneira:

·         Os usuários mudam de ideia efetuando rollback;

·         Os usuários encerram uma transação efetuando commit;

·         A sessão do usuário é encerrada de forma anormal através de rollbak;

·         A sessão do usuário é encerrada de forma normal com uma saída através de commit.

 

Transações e dados de Undo

Cada transação é designada a apenas um segmento de Undo, esse segmento pode atender a mais de uma transação ao mesmo tempo,

Verificando a view v$transaction você pode saber quais transações foram designadas a determinados segmentos de undo, quando uma transação é iniciada ela é designado a um segmento de undo, durante a transação todas as informações são alteradas nos segmentos de undo,

Os segmentos são criados automaticamente pela instancia, conforme necessário oferecendo suporte a transações, como todos os segmentos, os segmentos de undo são constituídos de extensões que também consistem de blocos de dados, eles crescem automaticamente e são compactados conforme necessários, a transação preenche as extensões de segmentos ate que seja toda consumida, se uma extensão toda for consumida e exigir mais espaço ela alocará outra extensão do segmento, se for consumida todas as extensões , a transação será distribuída na primeira extensão assim subscrevendo os dados de undo não mais necessários, ou solicitará uma nova extensão seja alocada ao segmento de undo,

Armazenando informações de undo

As informações de undo são armazenadas em segmentos de undo que por sua vez são armazenadas em tablespaces, as tablespaces são usadas apenas para segmentos de undo, envolvem considerações especiais de recuperação e podem ser associadas apenas a uma única instancia, podendo ter apenas uma tablespace ativa por vez.

O banco pode ter vários tablespaces de undo mas pode usar apenas um por vez, os segmento pertence a SYS sendo do tipo TYPE 2 UNDO, cada segmento terá no mínimo 2 extensões  agindo domo buffer circular, o numero máximo de extensões depende do tamanho do bloco, o bloco default de 8k suporta 32.765 extensões, os tablespaces de undo são permanentes e gerenciados localmente com alocação automática de extensões, sabendo que os tablespaces de undo podem ser recuperados apenas no estado MOUNT

  

Monitorando atividade de Undo

Normalmente a operação de undo requer pouco gerenciamento, as áreas a serem monitoradas é sobre espaço livre no tablespace de undo e erros do tipo snapshot too old, sendo gerenciado automaticamente pela instancia,

As informações de undo são retidas até que uma transação seja finalizada,

Por exemplo, imagina se um usuário decide deletar  de 100gb de dados o tablespace de undo terá que ter um tamanho equivalente para manter os dados no undo, porem quando o tablespace de undo não tiver mais espaço ele receberá uma mensagem de erro,

Outro erro é quando precisa acessar informações de undo já sobregravadas, isso pode acontecer em uma consulta de flashback ou de grande gravação, quando uma consulta precisa de um snapshot dos dados a partir de algum momento do passado e a reconstrução deste snapshot requer dados de undo que não existam mais, a consulta retornará o erro de snapshot too old,

O uso do gerenciamento automático de undo configurado pela definição do parâmetro UNDO_MANAGEMENT como AUTO, isso é usado para ter compatibilidado com versões anteriores,

Com o gerenciamento manual de undo deve considerar:

·         Dimensionamento de segmentos, incluindo o máximo de extensões;

·         A identificação e eliminação de transações de bloqueio;

·         A criação de segmentos de rollback, para manipular as transações;

·         A escolha de um tablespace para conter os segmentos de rollback.

  

Configuração a retenção de Undo

A retenção de Undo especifica ( em segundos ) o volume de informações de undo submetidas a commit, que deverão ser retidas, o valor default é 0 e o máximo é 2 á 32, mais de 187 anos,

UNDO_RETENTION = 0

A retenção de undo default tentará reter as informações ate que expirem porem se uma transação ativa necessitar de espaço e as informações não expiradas submetidas a commit serão sobregravadas, independente das definições de renteção de undo, a fim de evitar que haja falha nessa transação,

A retenção automática de undo mantem pelo menos 15 minutos de informações de undo, se possível, sem exibir erro de espaço,

As informações de undo são divididas em três categorias:

1.       Informações de undo não submetidas a commit: Oferecem suporte a uma transação em execução e serão necessárias se um usuário quiser efetuar rollback ou se houver falha na transação, as informações de undo não submetidas a commit nunca são sobregravadas,

2.       Informações de undo submetidas a commit: Não mais necessárias para oferecer suporte a uma transação em execução, mas ainda são necessárias para cumprir o intervalo de rentenção de undo, também conhecidas como informações de undo “não expiradas” as informações de undo submetidas a commit são retidas quando possível sem que haja falha em uma transação ativa por falta de espaço,

3.       Informações de undo expiradas: Não são mais necessárias para oferecer suporte a uma transação em execução, são sobregravadas quando há necessidade de espaço para uma transação ativa,

 

As informações de undo submetidas a commit serão sobregravadas em vez de causarem falhas nas transações devido a falta de espaço de undo, a menos que a retenção de undo seja garantida

O comportamento default de undo é sobregravar as transações submetidas a commit ainda não expiradas, a fim de evitar que haja em uma transação ativa por causa da falta de espaço em undo, é possível alterar esse comportamento garantindo a retenção, com a retenção garantida as definições de undo são impostas mesmo que causem falhas nas transações, RETENTION GUARANTEE pode ser alterado via instruções SQL, esta garantia aplica-se somente a tablespace de undo, se fizer em outra tablespace retornará um erro, os arquivos de dados pertencentes a um tablespace de undo poderão ser estendidos automaticamente quando não houver espaço livre suficiente, ao contrario de outros tablespaces, a oracle recomenda que a extensão automática de undo, não seja ativada nos arquivos de dados associados a tablespaces de undo, ao dimensionar a primeira vez você terá que ativar o dimensionamento mas assim que terminar as configurações terá que desativa-la,

Monitorando e Resolvendo Conflitos de Bloqueio

Antes que uma sessão possa modificar os dados de um banco, será necessário bloquear os dados que estão sendo modificados, o bloqueio permite que a sessão tenha controle exclusivo sobre os dados, de modo que nenhuma outra transação possa modificar os dados bloqueados até que o bloqueio seja liberado, as transações podem bloquear linhas de dados individuais, varias linhas ou até mesmo tabelas inteiras, o Oracle 10g suporta bloqueio manual e automático, os bloqueios aplicados automaticamente sempre tem níveis mais baixos, para minimizar conflitos com outras transações,

O mecanismo de bloqueio destina-se o máximo grau possível de concorrência de dados do banco, as transações que modificam os dados adquirem bloqueios de linha, e não a nível de pagina ou tabelas modificações de objetos adquirem bloqueios de objetos e não do banco ou schema,

As consultas de dados não requerem bloqueio, a consulta sempre sera bem sucedida mesmo que alguém aplique o bloqueio, quando varias transações precisam bloquear o mesmo recurso será obtido pela primeira transação que solicitar outras solicitações ficaram na espera no enfileiramento, o mecanismo de fila é automático e não requer intervenção do administrador, todos os bloqueios são liberados no final da transação, o mecanismo de bloqueio define como default um modo de bloqueio detalhado em nível de linha, diversas transações podem atualizar linhas distintas na mesma tabela sem que haja interferência entre elas, embora o modelo default seja bloquear no nível de linha o Oracle 10g oferece suporte ao bloqueio manual em níveis mais altos, se necessário,

Exemplo:

SQL> LOCK TABLE hr.employees IN EXCLUSIVE MODE;

Isso transforma o modo de bloqueio para exclusive, sendo o modo de bloqueio mais rigoroso

·         ROW SHARE: Permite acesso simultâneo a tabela bloqueada, mas impede que as sessões bloqueiem a tabela inteira para acesso exclusivo,

·         ROW EXCLUSIVE: O mesmo que o ROW SHARE, mas também impede o bloqueio no modo SHARE, os bloqueios ROW EXCLUSIVE são obtidos automaticamente durante a atualização, a inserção ou a deleção de dados,

·         SHARE: Permite consultas concorrentes, mas proíbe ( solicitação automaticamente ) para criar em uma tabela,

·         SHARE ROW EXCLUSIVE: Usado para consultar uma tabela inteira e para permitir que outras pessoas consultem linhas da tabelas, mas proíbe que elas bloqueiem a tabela do modo SHARE ou atualizem linhas,

·         EXCLUSIVE: Permite consultas na tabela bloqueada, mas proíbe qualquer outra atividade nela, o bloqueio exclusivo é necessário para eliminar uma tabela,

 

Cada bloqueio DML obtem dois bloqueios:

1.       Um bloqueio de linha exclusivo na linha que estão sendo atualizados, haverá um bloqueio de linha exclusivo independentemente do numero de linhas alteradas,

2.       Um bloqueio compartilhado no nível da tabela que está sendo atualizada, destina-se a impedir que outra sessão bloqueie toda a tabela, enquanto a alteração estiver sendo feita,


Mecanismo de enfileiramento

Solicita que os bloqueios sejam enfileirados automaticamente, logo que a transação com bloqueio é concluída, a próxima sessão da linha recebe bloqueio.

O mecanismo de enfileiramento controla a ordem em que os bloqueios foram solicitados e o modo de bloqueio solicitado, as sessões que já tem bloqueio podem solicitar a conversão desse bloqueio sem precisar chegar ao fim da fila, pro exemplo suponha que uma sessão mantenha um bloqueio compartilhado em uma tabela a sessão pode solicitar a conversão a do bloqueio compartilhado em um bloquei exclusivo, desde que não haja mais nenhum bloqueio exclusivo ou compartilhado na tabela, a sessão que mantem o bloqueio compartilhado recebe um bloqueio exclusivo sem precisar esperar na fila novamente,

Possíveis causas dos conflitos de bloqueio são as alterações não submetidas a commit, transações de longa execução e níveis de bloqueio desnecessariamente altos, os conflitos de bloqueio são comuns quando a transação e o processamento batch estão sendo executados simultaneamente,

Resolvendo conflitos de Bloqueio, para resolver conflitos de bloqueio submeta a commit ou rollback a sessão que mantem o bloquei e como ultimo recurso encerre a sessão,

Deadlocks é um exemplo especial de conflito de bloqueio, os deadlocks podem surgir quando duas ou mais sessões aguardam pelos dados bloqueados entre elas, como uma esta esperando a outra, nenhuma delas consegue concluir a transação para resolver o conflito, o servidor Oracle detecta e resolve automaticamente os deadlocks, fazendo rollback da instrução que detectou o deadlock,

 

 Backup e Recuperação

 

A tarefa do DBA é proteger o banco de dados contra falhas quando possível, aumentar o MTBF, Diminuir o MTTR e minimizar perdas,

MTBF: Tempo médio entre falhas, podendo usar o RAC e fluxos,

O DBA tem que garantir que o hardware seja de confiança, que os componentes críticos sejam protegidos por redundância e a manutenção do sistema operacional,

MTTR: Diminuir o tempo médio para recuperação, pode executar recuperação antecipadamente e configurar backups que estejam disponíveis quando necessário, o MTTR é o tempo que o banco tem para efetuar checkpoint dos dados, no checkpoint os dados são gravados nos arquivos de dados, a configuração do MTTR é o tempo que os arquivos vão demorar para fazer a gravação nos arquivos de dados (checkpoint) toda transação é gravada nos grupos de redo log, essas informações garantem que a transação pode ser recuperada em caso de falha, para controlar as gravações nos arquivos de dados usamos os checkpoints, ele garante que todos os dados ate determinado SCN foram gravados nos arquivos de dados,  a definição do MTTR em 0 desativa o recurso e o máximo é de 3600 segundos, o comando é FAST_START_MTTR_TARGET, se definir um valor muito baixo para o MTTR alvo, as gravações nos grupos de logs esperarão as gravações nos arquivos de dados, prejudicando o desempenho, se for definido um valor muito alto, a instancia levará mais tempo para se recuperar após uma falha

Configurando os redo logs arquivados junto com o banco de dados standby e Oracle data guard, podemos minimizar a perda de dados e as transações que não são submetidas ao commit,

  

Categoria de falhas

·         Falha de Instrução: há uma falha em uma única operação de banco de dados, Select, insert, update ou delete, ás vezes seja necessário para corrigir erros referentes aos privilégios do usuário ou a alocação de espaço do banco de dados:

o   Tentativa de informar dados inválidos em uma tabela

§  Trabalhe com usuários para validar e corrigir os dados

o   Erros lógicos em aplicações

§  Trabalhar com desenvolvedores para corrigir erros de programa

o   Tentativa de executar operações com privilégios insuficientes

§  Conceda privilégios adequados de objeto e de sistema

 

·         Falha de processo de usuário: há falha em uma única sessão de banco de dados, o usuário se desconecta da instancia de forma anormal e pode ter trabalho que não foi submetido a commit e que precisa ser removido, então podemos contar com a ajuda do PMON, que consulta periodicamente os processos do servidor para garantir que as conexões estejam bem, se o PMON encontrar um processo de usuário cujo o usuário não esteja mais conectado ele automaticamente inicia o processo de recuperação efetuando rollback e flashback das informações

o   O usuário realizou uma desconexão anormal

o   A sessão do usuário foi encerrada de forma anormal

o   Houve um erro no programa do usuário, que encerrou a sessão

§  Em geral uma ação do DBA não é necessária para resolver falhas de processo do usuário, os processos de segundo plano da instancia efetuam rollback de alterações não submetidas a commit e liberam os bloqueios;

·         Falha de rede: a conectividade com o banco é perdida: a melhor solução é oferecer planos de redundância para conexões de rede, como Listeners de backup de rede e placas de interface de rede que reduzem a probabilidade de falhas de rede que afetem a disponibilidade do sistema:

o   Falha de listener

§  Configure um listener de backup e um de failover de tempo de conexão;

o   Falhas de NIC

§  Configurar varias placas de rede;

o   Falhas de conexão de rede

§  Configurar um backup de conexão de rede;

  

·         Erro de usuário: o usuário conclui uma operação com êxito, que estava incorreta e gostaria de voltar ao que era antes, também o usuário efetua commit de informações incorretas, podemos resolver este problema efetuando rollback, ou se o rollback ainda não obtiver a informação correta podemos fazer consultas flashback, e mesmo assim se a consulta flashback não for possível por causa do tempo de retenção de undo podemos tentar recuperar a informação da lixeira, ou por Oracle Log Miner, e também se os usuários eliminarem tabelas podemos recuperar da lixeira, mas somente se o usuário não usar o comando PURGE:

o   O usuário modifica ou deleta inadvertidamente os dados;

§  Efetuar rollback ou usar consultas flashback para recuperação;

o   O usuário elimina uma tabela;

§  Recuperar a tabela da lixeira;

·         Falha de instancia: a instancia de banco de dados é encerrada inesperadamente, antes da sincronização de todos os arquivos de dados, essa falha pode ocorrer decorrente a uma falha de hardware ou software, ou por meio dos comandos SHUTDOWN ABORT  e STARTUP FORCE, sendo limitado a reinicialização da instancia,

o   Recuperação da Instancia

Recuperação de instancia ou de falha:

·         É causada por tentativas de abrir um banco cujo arquivo não foi sincronizado durante shutdown;

·         É automática;

·         Usa informações armazenadas nos grupos de redo log para sincronizar arquivos;

·         Envolve duas operações distintas:

o   Rollforward: os arquivos de dados são restaurados ao estado original antes que haja falha na instancia;

o   Rollback: as alterações efetuadas mas não submetidas a commit voltam ao estado original;

Ele recupera sozinho de uma falha de instancia, o DBA inicia a instancia, a instancia montará os arquivos de controle e tentará abrir os arquivos de dados, quando descobrir que os arquivos de dados não foram sincronizados durante o shutdown usara as informações contidas nos arquivos de redo log,  ele fara um rollforward dos arquivos de dados até o momento do shutdown, em seguida (como o tablespace de undo foi submetido a rollforward) ele efetuara rollback das transações não submetidas a commit,

·         Falha de mídia: um ou mais arquivos de banco de dados são perdidos, tais como arquivo de controle, redo log e arquivos de dados, a recuperação é restaurar e recuperar os arquivos ausentes, assim temos que ter sempre backup dos arquivos de dados, e também multiplexar os arquivos de controle e de log, criando grupos de redo log

 

Configurando a Capacidade de Recuperação

 

Para configurar o Banco de modo a obter o máximo de capacidade de recuperação

·         Programe backup regulares: a maioria das falhas de mídia requer restauração do arquivo perdido ou danificado a partir de backup;

·         Multiplexe arquivos de controle: o arquivo de controle é um arquivo binário pequeno que descreve toda a estrutura do banco, ele deverá estar disponível para que o servidor execute gravações sempre que o banco for montado ou aberto, sem o arquivo de controle não é possível montar o banco de dados e será necessário recuperar ou recriar o arquivo, Todos os arquivos de controle são idênticos, a recuperação não é difícil, basta fazer varias copias de qualquer arquivo de controle, a Oracle suger que tenha no mínimo 3;

·         Multiplexar grupos de redo log: as informações de redo log são utilizadas para fazer rollforward dos arquivos de dados até a ultima transação submetida a commit, se os grupos de redolog utilizarem apenas um único arquivo de redo log a perda desse arquivo significara uma probabilidade de perda desses dados, garanta que haja pelo menos duas cópias de cada arquivo de redo log e que esses arquivos estejam separados por discos diferentes controladoras diferentes separadas, a perda de todo o grupo de log é uma das falhas de mídias mais importantes que existe;

·         Reter copiar arquivadas de redolog: Se um arquivo for perdido e restaurado a partir de um backup, a instancia deverá aplicar informações de redo para trazer esse arquivo para o ultimo SCN contido no arquivo de controle, a definição default consiste em sobregravar as informações de redo depois que elas forem sobregravadas nos arquivos de dados, é possível configurar o banco para reter as informações e redo em copias autenticas de redo log, essa ação e conhecida como colocar o banco em modo de ARQUIVELOG; é possível gravar arquivos de log arquivo dos em dez diferentes destinos, os destinos podem ser locais ou remoto, os destinos locais deverão terminar com uma barra(/) ou invertida (\) se for Windows, o destino default (numero 10) envia arquivos de log arquivados para um local determinado pelo parâmetro de inicialização DB_RECOVERY_FILE_DEST o parâmetro de inicialização DB_RECOVERY_FILE_DEST também conhecido como área de recuperação flash,,

 

  

ARQUIVELOG

O banco tem que estar no modo MOUNT para ser colocar como ARQUIVELOG, o comando SQL é:

SQL> ALTER DATABASE ARQUIVELOG;

Só é possível se houver credenciais como SYSDBA, com o banco em modo NOARQUIVELOG (default) a recuperação só será possível até o ultimo backup, todas as transações realizadas após esse backup serão perdidas

O modo ARQUIVELOG a recuperação será possível ate o momento do ultimo commit, a maioria do bancos estão em modo ARQUIVELOG

 

1º  Limpar os Redo Log.

ALTER SYSTEM SWITCH LOGFILE;
OR
ALTER SYSTEM CHECKPOINT;

Este comandos acima irá forçar os dados a serem gravados, fazendo com os mesmos mudem de status.

2º Consultar o status do Redo Log.

SQL> SELECT * FROM V$LOG;

Neste momento você irá analisar como se encontra o status dos grupos de Redo Log, isto por que você só poderá DELETAR um grupo se o mesmo se encontrar com o status igual há INATIVO ou INACTIVE, como mostra o exemplo abaixo:

Ex.:

GROUP#  THREAD#  SEQUENCE#     BYTES    MEMBERS  ARC STATUS    FIRST_CHANGE# FIRST_TI
——  ——– ———-   ——– —— ———– ————   ——–
     1          1               46             2147483648    2      YES  INACTIVE  2021438           24/07/09
     2          1               47             2147483648    2      YES   INACTIVE  2062590           27/07/09
     3          1               48             2147483648    2      NO   CURRENT   2108705           28/07/09

Observe no exemplo acima que dois grupos se encontram com status INACTIVE, isto implica dizer que nós podemos DELETAR um deste dois grupo. Cada vez que você os procedimentos do 1º passo você identificará que o status dos grupos de Redo sempre será modificado.

 

 

3º  Adcionando um grupo de Redo Log.

SQL> ALTER DATABASE ADD LOGFILE GROUP 4 (‘\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO04A.LOG’, ‘\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO04A.LOG’) SIZE 200M reuse;

Observe acima que já está sendo adcionado ao grupo 4 dois membros de Redo Log. Todos os dois membros com tamanho de 200M e sendo reutilizados.

4º Deletar um grupo de Redo Log.

SQL> ALTER DATABASE DROP LOGFILE GROUP 1;

Se você tiver mais de um membro no grupo, todos serão excluidos automaticamete.

5º  Limpar um grupo de Redo Log.

SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;

Este comando acima irá limpar o grupo 1 e não deletar.

6º Forçando a Limpeza do Redo Log.

SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1;

O exemplo acima é utilizado quando você tenta realizar o passo 5 e não consegue. Mas saiba o que você está fazendo.

7º  Renomeando os arquivos de Redo Log.

SQL> ALTER DATABASE RENAME FILE (‘/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01b.LOG’) TO (‘/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01B.LOG’);

Observe que foi uma renomeação bem simples como todos os comandos acima.

 

  

Backup de Banco de Dados

A estratégia pode ser:

·         O banco de dados inteiro (completo): incluindo todos os arquivos do banco de dados e pelo menos um arquivo de controle;

·         Uma parte do banco de dados (parcial): incluindo zero ou mais tablespaces, zero ou mais arquivos de dados, e podem não incluir nenhum arquivo de controle;

O tipo de banco de dados pode ser:

·         Backup de Banco de dados completo: criam uma copia de todos os blocos de dados nos arquivos quem contem dados cujo backup esta sendo feito

·         Backup de Banco de dados Incremental: criam uma copia de todos os blocos que foram alterados desde um backup anterior, suportando dois níveis de backup ( 0 a 1 )

·         Backup Nivel 0: é equivalente a um backup completo que contem todas as linhas

·         Backup Nivel 1: abrange todos os blocos do banco alterados desde o backup de nível 0, para fazer a restauração de backups de nível 1 faça primeiro o do nível 0 e depois o do nível 1

O modo de backup pode ser:

·         Backups Off-line: Conhecidos como backup consistentes, são feitos quando o banco não está aberto, eles são consistentes porque no momento do backup os cabeçalhos do arquivo de dados SCN correspondente ao SCN dos arquivos de controle

·         Backups On-line: Conhecidos como backup quentes ou inconsistentes, são feitos quando o banco esta aberto, os backups incosistes são que não há garantia de que o arquivos de dados esteja sincronizados com os arquivos de controle, ele requerem recuperação para que sejam usados

É possível armazenar os backups como:

·         Cópias-Imagem: As copias de imagem são duplicatas dos arquivos de dados ou dos arquivos de log arquivados, uma vantagem é na melhor granulidade da operação de recuperação a partir de fita somente os arquivos serão recuperados;

·         Conjuntos de backup: são cópias de um ou mais arquivos de dados ou arquivos log arquivados, com conjuntos de backup, os blocos de dados vazios não são armazenados, fazendo assim com que os conjuntos de backups usem menos espaço em disco ou fita, é possível compactar os conjuntos de backup, para reduzir ainda mais os requisitos de espaço em backup não sejam armazenados, com conjuntos de backup é necessário extrair o conjunto inteiro antes de usar o arquivo;

Os bancos no modo NOARCHIVELOG deve efetuar backups de banco de dados off-line, integrais e completos, os banco de dados no modo ARCHIVELOG tem acesso a todas as opções de backup,

 

RMAN (Recovery Manager)

O RMAN é utilizado para executar operações de backup e recuperação, ele pode efetuar backups consistentes e inconsistentes, executar backups integrais ou incrementais, além de efetuar backup de todo o banco ou de parte dele, esse gerenciador usa seu próprio controle de Jobs e sua própria linguagem de scripts de forma eficiente, bem como o API publicada que permite a interação dele com varias soluções de software de backup comuns,

O RMAN pode armazenar backups no disco para recuperação rápida ou coloca-la em fita para armazenar a longo prazo, para que ele armazene backups em fita, é necessário configurar uma interface para o dispositivo de fita, conhecida como MML, o enterprise manager, fornece uma interface gráfica para o uso do RMAN, usadas com mais frequência, sendo possível acessar as operações de backup e recuperação avançadas por meio do cliente de linha de comando RMAN,

Backups podem ser feitos em disco ou fita, no Enterprise manager podemos configura algumas opções assim como abaixo:

·         Paralelismo: Quantos fluxos separados de informação de backup você deseja criar, a melhor definição de paralelismo depende do seu hardware, a realização de backups paralelos não é vantajosa pra uma única CPU, uma única controladora de Disco ou um único servidor de discos, a medida que aumentam os recursos de hardware, também aumenta o grau de paralelismo

·         Localização de backup em disso: onde os backups devem ser armazenados, o default é na área de recuperação Flash, se você mudar isso, temos que verificar se o RMAN pode gravar isso em outro local

·         Tipo de backup em disco: Selecione a cópia-imagem, o conjunto de backup ou conjunto de backup compactado

·         Na aba backup set podemos definir o tamanho máximo de arquivo de backup, ainda sendo possível dividir os conjuntos de backup, para facilitar o arquivamento

·         Efetuar o backup automático do SPFILE em cada backup

·         Otimizar os backups não fazendo backup dos arquivos que correspondam exatamente a um arquivo que já faça parte dos backups retidos, essa definição permite ignorar arquivos de dados off-line e somente para leitura

·         Permitir o controle de alterações de bloco e especificar um local para o arquivo de controle, se você pretende criar backups incrementais, essa definição pode diminuir o tempo necessário para escolher os blocos a serem incluído no backup incremental

·         Excluir tablespace de um backup completo de banco, alguns administradores preferem efetuar backup de tablespaces que contenham dados ou objetos que possam ser facilmente recriados

·         Politica de retenção: por quanto tempo o RMAN deve manter os backups se você estiver usando uma área de recuperação flash o RMAN deletara automaticamente os backups antigos a fim de liberar espaço para novos backups (se a politica de retenção permitir)

Gerenciar backups:

·         Catalog Aditional Files: é possível criar copias de imagem de outra maneira com recursos do sistema operacional

·         Crosscheck all: podemos deletar arquivos obsoletos usando comandos do sistema operacional, se for deletado um backup fora do RMAN, o catalogo não saberá que ele esta ausente ate for executada uma verificação cruzada, entre o catalogo e o que realmente se encontra la

·         Delete All Obsolete: Deleta backups mais antigos que a politica de rentenção,

·         Delete All Expired: Deleta a lista de catalogo de qualquer backup não encontrado quando a verificação cruzada executada


Area de Recuperação Flash

É um espaço que foi separado para conter logs arquivados, backups e logs de flashback, se for configurado para serem gravados é bom monitorar o espaço para garantir que ele não atinja a capacidade máxima, se não conseguir criar log por causa de espaço haverá uma pausa ate que o DBA arrume a situação.


Recuperação de Banco de Dados

Para abrir o banco de dados precisamos ter, todos os arquivos de controle devem estar presentes e sincronizados, todos os arquivos de dados on-line devem estar presentes e sincronizados, pelo menos um membro de cada grupo de redo logs precisa estar disponível

Uma vez aberto haverá falhas na instancia com pera de qualquer arquivo de controle, perda de um arquivo de dados pertencente ao tablespace de undo ou do sistema, perda de um grupo inteiro de redo logos, desde que pelo menos um membro do grupo esteja disponível, a instancia permanecerá aberta,

Perda de uma arquivo de controle: Se um arquivo de controle for perdido ou danificado:

1.       Normalmente, a instancia será abortada, se ela ainda estiver aberta, feche-a, se ainda não houve falha na instancia, faça um shutdown abort

2.       Restaure o arquivo de controle ausente copiando um arquivo de controle existente, copie um dos arquivos de controle restantes para o local do arquivo ausente, se a falha de mídia ocorreu devido a perda de uma unidade de disco ou controladora copie os arquivos de controle restantes para outro local e atualize o arquivo de parâmetros da instancia para apontar para esse local, como alternativa você pode deletar do arquivo de parâmetros de inicialização a referencia ao arquivo de controle,

3.       Inicie a Instancia

Perda de um arquivo de redo log: Se um membro de um grupo de arquivos de log for perdido, desde que o grupo ainda tenha pelo menos um membro:

1.       A operação normal da instancia não será afetada, determine se há um arquivo de log ausente examinando o log de alerta,

2.       Voce receberá uma mensagem no log de alerta notificando que um membro não pode ser encontrado

3.       Restaure o arquivo de log ausente copiando um dos arquivos restantes do mesmo grupo

4.       Se a falha de mídia tiver ocorrido devido a perda de uma unidade de disco ou controladora, renomeie o arquivo ausente

5.       Se o grupo já tiver sido arquivado, ou se você estiver no modo noarchivelog, convem solucionar o problema limpando o grupo de logs para recriar o arquivo ausente, selecione o grupo adequado e em seguida a ação clear logfile, também é possível limpar manualmente o grupo afetado com o comando
SQL> ALTER DATABASE CLEAR LOGFILE GROUP #

Perda de um arquivo de dados no modo NOARCHIVELOG: Se o banco estiver no modo NOARCHIVELOG e houver perda de algum arquivo:

1.       Faça shutdowm da instancia se isso não tiver sido feito

2.       Restaure o backup de todo o banco incluindo todos os dados e arquivos de controle

3.       Abra o banco

4.       Solicite que o usuário especifique novamente todas as alterações efetuadas desde o ultimo backup

Perda de um arquivo de dados não critico no modo ARCHIVELOG: Se um arquivo de dados for perdido ou danificado e não pertencer ao tablespace SYSTEM ou UNDO, restaure e recupere o arquivo de dados ausente

1.       Clique em perform recovery na pagina de propriedades maintenance

2.       Selecione “Datafiles” como tipo de recuperação e em seguida “ Restore to current time”

3.       Adicione todos os arquivos de dados que precisam de recuperação

4.       Determine se você deseja restaurar os arquivos no local default ou em outro local, se estive faltando um disco ou uma controladora

5.       Submeta o job do RMAN para restaurar e recuperar os arquivos ausentes

Perda de um arquivo de dados critico do sistema no modo de ARCHIVELOG: Se um arquivo de dados for perdido ou danificado e pertencer ao tablespace SYSTEM ou UNDO

1.       A instancia poderá ou não ter shutdown automático, se não tiver, use o SHUTDOWN ABORT para fazer shutdown

2.       Monte o banco de dados

3.       Restaure e recupere o arquivo de dados ausente

4.       Abra o banco de dados