1

Conhecendo melhor o seu Banco de Dados: Redo Log File

Bem, não é de hoje que eu sempre vejo artigos excelentes espalhados por inúmeros blogs de diversos técnicos impressionantes, falando sobre

estruturação e sobre como organizar as bases de dados de maneira eficiente e eficaz.

Pensando sobre esses assuntos, eu trago até vocês hoje uma visita ao nosso passado, pois vou falar um pouco sobre uma das estruturas que

compõem o Banco de Dados, que é os Redo Log Files.

Redo Log Files

Conceito: Essa estrutura localizada fisicamente em nosso Banco de Dados é a principal responsável por tornar possível refazermos uma determinada

transação que possa ter sofrido algum tipo de indisponibilidade, seja por falhas ou gaps causados por nosso ambiente. Basicamente, em seu conteúdo

estão as informações transacionadas pelas seções e instruções executadas, preservando sempre a imagem antiga do dado e a nova, pois em caso de

queda da instancia no processo de instance recovery, são eles que farão os chamados Roll Fowarding.

Vejam na figura abaixo uma ilustração acerca do esquema de funcionamento dos arquivos de redo log file:

Entendendo um pouco melhor a mecânica do Redo Log File

Na minha opinião, não há dúvida de que os arquivos de redo log são umas das estruturas mais importantes existentes no Banco de Dados. No

decorrer do nosso dia-a-dia em banco de dados damos pouca importância às maravilhas que se procedem nos bastidores dos algoritmos Oracle que

cercam as funcionalidades do nosso Banco de Dados.

No caso dos nossos arquivos de redo, antes mesmo de serem gravados em disco, são geradas entradas no Buffer de redo, ou Redo Log Buffer, para

aqueles que estão mais acostumados com as nomenclaturas padrões do Oracle. Só depois de realizado o comprometimento e/ou confirmação

(commit) o Buffer é esvaziado, para dar lugar a novas estradas, pois nossos arquivos de Redo Log File trabalham de maneira cíclica entre os seus

grupos, que por sua vez possuem seus respectivos membros.

Via de regra nós, DBAs, já os determinamos na criação, mas há a possibilidade de adicionarmos mais membros ou mais grupos posteriormente à

criação do nosso Banco de Dados.

Uma coisa muito importante sobre a utilização dos arquivos de redos pelo nosso banco é que, em caso de falhas, eles nos garantirão a recuperação

até o ponto onde eles tenham gravado a informação; por essa razão, se faz necessária a "multiplexação" desses arquivos em diferentes locais e de

preferência em hardwares distintos, porque mesmo que você os coloque em diferentes locais, se os colocar em um mesmo disco, caso este disco seja

corrompido ou apresente problemas seja lá de qual natureza for, que nos impeça de ter uma leitura e escrita consistente neste hardware, fatalmente

você perderá seus arquivos de Redo e, com isso, terá algumas dores de cabeça quanto a processos de Disaster Recover.

Criados em grupos eles, são gravados um por vez pela Instância Oracle, daí se dá o comportamento cíclico dos mesmos, como mostra a figura que

coloquei acima.

Internamente, o Oracle grava nesses arquivos em paralelo, e é permitido e recomendado, como mencionei, o espelhamento dos mesmo e, em caso de

perda de um membro online, nenhum dado será perdido e seu Banco continuará a funcionar normalmente.

Nota Importante: em caso de ambientes em Oracle Real Application Cluster (RAC), cada nó participante do cluster tem sua identidade de redo logs

individualmente criada; um grupo do nó 1 criado neste nó não poderá ser criado no nó 2 com o mesmo nome. Uma outra característica importante dos

2

redos em RAC é que há um parâmetro novo a ser passado no comando de criação, que são os threads, eles indicaram em qual nó será criado aquele

Relog Member.

Particularidades dos Redos

Em um banco de dados Oracle é necessário que haja pelo menos dois grupos de redo online, com um único membro em cada, porém recomenda-se

que sejam criados, no mínimo, três membros por grupo, espelhados de maneira eficiente e lógica.

Se por ventura nós estivermos trabalhando em modo Archivelog, depois que o Oracle fechar o arquivo de redo log que está cheio, um processo interno

chamado Arch é convocado a entrar na jogada para fazer seu papel, movendo todos os arquivos de Redo Log para os seus destinos pré-

determinados.

A outra opção para trabalharmos é o modo NoArchivelog, onde é solicitado ao DBwr (Db Writer) que grave todas as alterações nos respectivos

datafiles antes de reaproveitar um determinado membro de redo log.

Como forma de mecanismo de autoproteção, o Oracle apenas reutiliza um membro em modo Archivelog depois que ele for integralmente gravado no

destino e liberado para uso. Essa é uma das belezas dos processos internos do Oracle que não são visíveis. Caso não haja membros disponíveis o

suficiente para que o Oracle trabalhe dessa forma, ocorrerá uma interrupção na Base até que o Oracle possa gravar de maneira consistente no

destino, por isso é mais uma vez importante salientar o uso de 2 ou mais membros, para evitar esse tipo de cenário.

Determinando tamanho de Redo e realizando manutenções

Algo sempre me ocorreu quando eu era questionado a respeito de criar um Banco novo: na hora de definir os tamanhos dos Redo Logs era sempre um

"parto" - quanto devo colocar?

Olha, sinceramente, a menos que você conheça cada "fio de cabelo" do que conterá seu Banco de Dados, eu sugiro que você os crie com um tamanho

de uns 50M, pra uma instance mediana creio que seja o suficiente até você acompanhar os desempenhos e os tempos de gravação e conseguir

determinar um tamanho perto do "excelente" para os seus Redo Log Files.

A própria Oracle determina que as alternâncias entre os arquivos devem compreender um tempo de 15 minutos, e se elas não satisfazerem a esse

requisito você deverá aumentar seus redo logs até que alcancem esse patamar de tempo.

3

Como criar novos grupos de Redo?

Essa é uma tarefa de administração comum, não há nada de espetacular, porém eu mesmo já me confundi "N" vezes na hora de executar esses

"benditos" comandos. Vejamos como podemos proceder para criarmos um grupo de redo novo.

Antes de mais nada, defina a localização, pois será necessário checar algumas variáveis antes, como se há espaço suficiente para ele ser criado.

Feito isso, proceda da seguinte forma:

Logado com um usuário com poderes de DBA para executar essa tarefa administrativa, visto que será usado o comando ALTER DATABASE, faça :

ALTER DATABASE ADD LOGFILE [THREAD x] GROUP [numero do grupo]('path do arquivo+Nome do Arquivo de log') SIZE [tamanho em mega];

Nota: reparem que coloquei a palavra thread, como eu havia mencionado. Para quem trabalha com RAC, após a opção group você informará o

número do novo grupo, que vai depender de quantos você já possui no seu banco. A questão do nome é que eles devem ser com extensão .LOG por

padrão e o tamanho fica por conta do que dissemos acima.

Surge então a pergunta:

"Ok, espertão! Criei o grupo, mas agora quero adicionar mais membros. Se vira aí, como faço isso?

Antes de mais nada, tenha calma e fé! Brincadeirinha, é uma tarefa quase tão simples quanto a acima mencionada, vejam:

ALTER DATABASE ADD LOGFILE MEMBER 'PATH+NOME DO ARQUIVO.LOG TO GROUP x;

Nota: a particularidade aqui é que nós informamos, no comando, o grupo onde ele será criado, por razões bem óbvias. É claro, observem também a

opção Add LogFile.

Bom, já vimos como criar um Grupo, como adicionar um Membro. Que tal agora vermos como remover um redo log?

Antes de prosseguirmos, é bom que fique bem claro que você não pode proceder com a remoção do grupo que estiver como current, pelo fato de ele

estar sendo utilizado atualmente pela instância, e causaria um certo problema remover arquivos que estão sendo gravados no momento; portanto,

opere apenas nos grupos que estiverem como inactive e unused.

Caso você precise remover o grupo que está marcado como current, proceda antes com alguns LogSwitches, para forçar o esvaziamento e a troca de

Arquivos e Grupos, até que o grupo desejado esteja em um dos status determinados para a remoção segura. O comando de troca é o seguinte:

ALTER SYSTEM SWITCH LOGFILE;

4

Reparem na figura a situação dos Logs:

Vejam após alguns Switches o que ocorre com a coluna status:

Antes de darmos prosseguimento, gostaria de falar das visões de apoio que usei para obter essas informações sobre os arquivos de Redo Log:

V$LOG - displays log file information from the control file.

COLUMN DATATYPE DESCRIPTION

GROUP# NUMBER Log group number

THREAD# NUMBER Log thread number

SEQUENCE# NUMBER Log sequence number

BYTES NUMBER Size of the log (in bytes)

MEMBERS NUMBER Number of members in the log group

ARCHIVED VARCHAR2(3) Archive status (YES or NO)

STATUS VARCHAR2(16)

Log status:

UNUSED - Online redo log has never been written to. This is the state of a redo log

that was just added, or just after a RESETLOGS, when it is not the current redo log.

CURRENT - Current redo log. This implies that the redo log is active. The redo log

could be open or closed.

ACTIVE - Log is active but is not the current log. It is needed for crash recovery. It

may be in use for block recovery. It may or may not be archived.

CLEARING - Log is being re-created as an empty log after an ALTER DATABASE

CLEAR LOGFILE statement. After the log is cleared, the status changes to

UNUSED.

CLEARING_CURRENT - Current log is being cleared of a closed thread. The log can

stay in this status if there is some failure in the switch such as an I/O error writing the

new log header.

INACTIVE - Log is no longer needed for instance recovery. It may be in use for

media recovery. It might or might not be archived.

FIRST_CHANGE# NUMBER Lowest system change number (SCN) in the log

FIRST_TIME DATE Time of the first SCN in the log

5

V$LOGFILE - This view contains information about redo log files.

COLUMN DATATYPE DESCRIPTION

GROUP# NUMBER Redo log group identifier number

STATUS VARCHAR2(7)

Status of the log member:

INVALID - File is inaccessible

STALE - File's contents are incomplete

DELETED - File is no longer used

null - File is in use

TYPE VARCHAR2(7)

Type of the logfile:

ONLINE

STANDBY

MEMBER VARCHAR2(513) Redo log member name

IS_RECOVERY_DEST_FILE VARCHAR2(3) Indicates whether the file was created in the flash recovery area (YES) or not (NO)

Vamos então à remoção dos nossos arquivos de Redo.

A sintax para essa tarefa é:

ALTER DATABASE DROP LOGFILE MEMBER'PATH+NOME_DO_ARQUIVO.LOG';

Nota: reparem que a remoção do arquivo se deu sem problemas, pois ele atendia às particularidades que falamos acima.

Encontrei problemas de tamanho de Redo Log File. O que devo fazer?

Bem, na nossa última abordagem sobre os arquivos de redo, nós vimos que era possível, criar, adicionar e remover membros de maneira segura e

eficaz.

Agora nós iremos ver que é possível também realizar tarefas de redimensionamento e também de limpeza de arquivos de redo.

Notadamente alguns de vocês já devem ter percebido que o Oracle não possibilita a realização do uso da cláusula Resize em Redo Log Files,

portanto, para que possamos redimensioná-los, é necessário que nós os recriemos, removendo-os e recriando-os com os devidos tamanhos.

Preciso limpar meus Redo Logs. Como devo fazer?

Antes de mais nada, é preciso entender o porquê de realizar limpezas nos redos. Isso ocorre porque, via de regra, os arquivos de redo têm problemas

de corrupção em seus conteúdos, o que impossibilita que os serviços da Oracle os descarreguem. Para solucionar esse problema, procede-se com a

limpeza. Veja como fazer:

ALTER DATABASE CLEAR LOGFILE GROUP x;

Pronto, com esse comando você limpa seus redos, deixando-os prontos para receberem dados novamente. Caso esses problemas de corrupção em

logs se repitam, eu sugiro que fique atento às entradas no seu alert log e monitore, se possível, as querys mais impactantes que exercem tarefas de

DML.

Como devo monitorar meus Redo Log Files?

Excelente questionamento, pois não é tarefa lá muito trivial ficar monitorando determinadas áreas, o mais comum é atentarmos apenas para

Tablespaces e Archives.

Para monitorarmos nossas áreas de REDO LOG, utilizaremos como fonte de informação as nossas já conhecidas visões dinâmicas, cujos nomes de

algumas eu já citei (V$LOG e V$LOGFILE). Uma que eu ainda não lhes apresentei é a:

6

V$LOG_HISTORY - displays log history information from the control file.

COLUMN DATATYPE DESCRIPTION

RECID NUMBER Control file record ID

STAMP NUMBER Control file record stamp

THREAD# NUMBER Thread number of the archived log

SEQUENCE# NUMBER Sequence number of the archived log

FIRST_CHANGE# NUMBER Lowest system change number (SCN) in the log

FIRST_TIME DATE Time of the first entry (lowest SCN) in the log

NEXT_CHANGE# NUMBER Highest SCN in the log

RESETLOGS_CHANGE# NUMBER Resetlogs change number of the database when the log was written

RESETLOGS_TIME DATE Resetlogs time of the database when the log was written

Pois bem, essa é mais uma arma de auxílio para os nossos problemas com Redo Log Files. Como o próprio nome sugere, ela nos dá todas as

informações em formato de histórico sobre as situações dos nossos arquivos de Redo.

Erros "ORA" encontrados: o que devo fazer?

Como toda e boa estrutura Oracle, os arquivos de Redo não estão livres de erros e podem, sim, gerar alguns problemas falados na língua Oracle.

Língua Oracle?

É, pessoal, não estranhem, seu banco fala com você. O "dialeto" ORA-xxxx é a maneira que o Banco de Dados tem de sinalizar quando encontra

algum problema que fuja da sua funcionalidade normal e/ou seja causado por algo externo, que o tenha forçado a trabalhar de maneira errônea.

Vejamos abaixo alguns erros comuns relacionados a arquivos de Redo Log Files:

1. ORA-1571 - Este erro nos remete a uma situação de migração mal feita, pois no caso do não desligamento normal do Banco para dar início

ao processo de migração, dados relacionados à versão antiga podem se manter nos arquivos, ocasionando a mensagem de erro. Por isso,

em tarefas de migração, proceda sempre de maneira prudente e seguindo os passos do ReadMe que vem junto com a maioria dos How-To

encontrados no Oracle My Support.

2. ORA-1184 - Bem tranqüilo, aqui é apenas uma mensagem de alerta (warning), informando que você está tentando adicionar um arquivo que

já existe. Corrija a nomenclatura para um nome não existente e execute a tarefa novamente.

3. ORA-0301 - Neste caso temos erros mais apurados, que poderão ser encontrados em detalhes na forma dos Trace Files, isso faz com que

seja necessário que analisemos este trace, pois as causas podem ser inúmeras.

4. ORA-17610 - Esta mensagem aparecerá sempre que você tentar criar um redo sem definir para ele um tamanho qualquer, vale salientar que

em caso de uso de OMF, não será encontrado este erro.

5. ORA-1185 - Aqui você deve atentar ao parâmetro MaxLogFiles, pois este erro aparece quando se atinge o número máximo de arquivos de

Redo Log no seu Banco de Dados.

6. ORA-1566 - Se você informar o mesmo nome de Redo na instrução de Drop, dará de cara com este erro. Neste caso, remova apenas a

entrada duplicada e prossiga.

7. ORA-1900 - Mais uma mensagem do tipo Alerta. Acontece quando nos esquecemos de escrever logfile (junto) e escrevemos log file

(separado) na hora de exercer as tarefas de administração de Redo Logs. Este erro é para nos lembrar de que a escrita está errada.

8. ORA-0344 - Um erro tipicamente relacionado a problemas de localização, ou de limpeza de Redo Log, aparece muito em operações de

ResetLogs e Clear LogFile. Cheque se os diretórios destino estão todos normais, com espaço e permissões de gravação.

9. ORA-0357 - Aqui esbarramos em um problema de quantidade de membros por grupo. Esta mensagem nos informa que excedemos o

número de membros por grupo, então devemos diminuir esse número e executar a tarefa novamente.

10. ORA-0359 - Se você tentar remover um grupo de Redo que não exista, vai se deparar com este erro especifico.

11. ORA-0360 - Aqui temos o mesmo problema apontado acima, mas, no caso, é quando tentamos remover um membro que não existe.

12. ORA-0361 - Se você tentou remover o último membro de um dos grupos e isso resultou neste erro, aborte a tarefa e remova o grupo todo.

7

Situações envolvendo Redo Logs. Como fazer para "driblar esses problemas?

Vejamos algumas situações onde nossos arquivos de Redo são acessados, lidos ou somente mencionados.

1. Acabei de iniciar minha instância, onde meus arquivos de redo entram nesta história? Qualquer modificação feita na sua instância

após este fato será gravada no seu arquivo de Redo arquivados.

2. Meu tempo de recover está muito alto, o que eu posso fazer para diminuir isso? Uma das coisas a serem feitas é reduzir o tamanho

dos Redo Log Files.

3. Os redos do meu grupo x foram corrompido, o que devo fazer para poder voltar ao normal? Meu arquivamento está parado?

Proceda com o comando de limpeza ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP x.

4. Estava fazendo uma análise no meu Banco de Dados e identifiquei uma contenção nos meus redo log files, o que posso fazer?

Cheque antes se os seus arquivos não estão em um mesmo disco físico. Caso sua resposta seja positiva, proceda com a separação deles e

depois aumente seu parâmetro de Redo Log Buffer.

5. Tive uma falha em um dos meus discos que estava em Mirror, e este disco tinha Bad Blocks; isso ocasionou a perda de um

Membro de Redo, o que vai ocorrer com a minha instância? Nada, neste caso sua instância não é afetada.

6. Onde entra o papel dos meus Redo Logs quando minha instância é aberta? Todos seus arquivos de Redo são lidos e abertos para isso.

7. Como faço para habilitar ou desabilitar o arquivamento dos meus Redo Logs? Coloque sua instância em estado de Mount.

8. Perdi um dos meus membros. Se eu checar o status dele na V$LOGFILE, qual será a resposta encontrada? Estará com o flag de

Invalid.

9. Sofri uma queda de energia no meu ambiente e percebi que na hora do recover necessitei do meu redo, de que maneira ele me

ajudou? O processo de checkpoint irá verificar o final do seu redo log file e proceder com o instance recover e aplicação de seu conteúdo

através do SMON.

Bem, pessoal, era isso que tinha para dividir com vocês sobre Redo Log Files. Espero que tenham apreciado e que tenham se divertido tanto quanto

eu.

http://imasters.com.br/artigo/18105/bancodedados/conhecendo_melhor_o_seu_banco_de_dados_redo_log_file/

VPD - Virtual Private Database - Segurança dos dados em nível de linha

Neste artigo vamos falar sobre o VPD - Virtual Private Database - uma feature que a Oracle disponibiliza nas versões Enterprise do seus bancos de

dados, a partir da versão 8i, para implementar a segurança em nível de linha.

Necessidade

A segurança dos dados contidos em um Banco de Dados, até bem pouco tempo, era possível ser garantida simplesmente através dos privilégios de

objeto, controlando as operações DML básicas (select, insert, update e delete). No entanto, nos dias de hoje, com o mundo conectado através da

internet, ganham cada vez mais espaço as web applications (sistemas desenvolvidos para a web).

A necessidade de disponibilidade de dados on-line e informações em tempo real impulsionam o desenvolvimento deste tipo de aplicação.

Um banco de dados voltado para ambiente web possui características e necessidades peculiares como, por exemplo, a convergência de dados de

múltiplos bancos para um único database, fazendo com que dados de diferentes organizações sejam consolidados em um mesmo objeto do banco.

Nos bancos voltados para web, os privilégios de objeto, por si só, não são suficientes para controlar o acesso e garantir a segurança dos dados. Isso

porque não será possível apenas dizer que um determinado usuário tem permissão de leitura em uma determinada tabela, mas sim, a quais dados

desta tabela ele deve ter acesso. Se não fosse assim, este usuário teria acesso a informações de várias entidades.

Isso é segurança de dados em nível de linha (Row Level Security).

É possível implementar e controlar row level security por meio das aplicações, mas o desenvolvimento e a manutenção das políticas são trabalhosas e

não trazem um bom nível de confiabilidade, pois somente o acesso por meio destas aplicações é que estaria assegurado. Se um usuário conseguisse

acessar o banco por outra aplicação ou ferramenta (SQL Plus, SQL Developer, Toad, etc), ele não estaria sujeito à política de segurança e poderia ter

acesso a todos os dados de um determinado objeto.

8

VPD – Virtual Private Database

A Oracle possibilita a implementação de row level security por meio do VPD, uma feature nativa da versão Enterprise (8i em diante).

A idéia chave do VPD é adicionar uma condição extra na cláusula WHERE de todos os DMLs, de forma transparente ao usuário.

Nos DMLs concebidos pelo usuário sem uma cláusula WHERE, o VPD se encarrega de 'criar' uma, com os predicados definidos pela política de

segurança. Esta política pode ser anexada a tabelas, views e sinônimos e é acionada quando os DMLs acessam os objetos associados com a política.

A segurança dos dados passa então a ser centralizada no banco de dados, valendo para todo e qualquer acesso ao banco, independente da fonte

(aplicação, ferramenta de terceiros, SQL*Plus, etc.).

Application Context

Application contexts (contextos de aplicação) são úteis para determinar como a política será implementada, e poderão ser usados na procedure

responsável em definir o predicado, a condição 'extra' que será anexada às cláusulas WHERE.

Os contextos podem ser alimentados por meio de trigger (de logon, por exemplo) ou a partir de uma chamada em um determinado ponto da aplicação.

Estes contextos podem conter informações sobre conexão (IP, host, usuário) ou conteúdo de qualquer coluna de tabela do banco (nome, código ou

cargo do usuário, código da entidade, centro de custo, departamento, etc), o que melhor definir a coluna alvo do VPD, que será usada para definir os

privilégios de acesso.

Exemplo:

Consideremos a existência de duas tabelas: gerentes e salarios, conforme abaixo:

GERENTES

cod_pessoa nome cod_empresa

1 Maria 1

2 João 2

3 Pedro 3

SALARIOS

funcionário salário cod_empresa

José 1000 1

Antônio 2000 3

Tereza 3000 1

Betânia 4000 2

Imaginemos que a coluna alvo do VPD seja a cod_empresa, e esta informação é passada para um contexto no momento em que o usuário faz o

logon no banco (por meio de logon trigger).

Neste caso, quando a gerente Maria fizer o logon, a trigger chama a procedure que alimenta o contexto e este recebe o valor 1, que é o código do

setor da gerente Maria.

Suponhamos ainda que a política de segurança tenha sido adicionada à tabela salarios, e no momento em que a gerente Maria fizer um SELECT para

saber os salários dos funcionários, o VPD vai se encarregar de anexar o predicado 'cod_empresa=1' a todas as cláusulas WHERE.

Então, o SELECT da gerente Maria passa a retornar somente os funcionários José e Tereza, que pertencem à empresa 1.

SELECT da gerente Maria:

select * from salarios;

Neste momento o VPD iria alterar o comando para:

select * from salarios where cod_empresa=1;

E teríamos como resultado:

funcionário cod_setor salario

José 1 1000

Tereza 1 3000

PASSO A PASSO

Passo 1 - Criação do application context

create context ctx_emps using proc_ctx_emp;

9

Passo 2 -Package pra setar o valor do contexto

create or replace package proc_ctx_emp

is

procedure set_ctx_emp(retorno varchar2);

end;

create or replace package body proc_ctx_emp

is

procedure set_ctx_emp (retorno varchar2) is

v_ctx_emp varchar2(100);

begin

dbms_session.set_context('ctx_emps','ctx_emp',retorno);

end proc_ctx_emp;

Passo 3 - Package pra setar o conteúdo do predicado (cláusula where)

create or replace package proc_ctx_vpd_emp

is

function fc_emp(d1 varchar2, d2 varchar2) return varchar2;

end;

create or replace package body proc_ctx_vpd_emp is

function fc_emp (d1 varchar2, d2 varchar2) return varchar2 is

d_predicate varchar2(2000);

begin

d_predicate := '1=2';

-- não aplicar a política ao usuário DBA, para que ele possa ver todos os dados das tabelas

IF (SYS_CONTEXT('USERENV','SESSION_USER') = 'DBA') THEN

d_predicate := NULL;

ELSE

-- adicionar a condição cod_empresa = <conteúdo do contexto> a todas as cláusulas WHERE

d_predicate := 'cod_empresa=sys_context(''ctx_emps'',''ctx_emp'')';

END IF;

RETURN d_predicate;

end fc_emp;

end proc_ctx_vpd_emp;

Passo 4 - Procedure para adicionar a política às tabelas que possuem a coluna cod_empresa

begin

for x in (select table_name

from user_tab_cols

where column_name='cod_empresa')

loop

SYS.DBMS_RLS.ADD_POLICY ( object_schema => 'usuario_owner_das_tabelas',

object_name => x.table_name,

policy_name => 'vpd_emp',

function_schema => 'usuario_owner_das_tabelas',

policy_function => 'proc_ctx_vpd_emp.fc_emp',

statement_types => 'SELECT,INSERT,UPDATE,DELETE',

update_check => TRUE,

enable => TRUE );

end loop;

end;

/

10

Passo 5 - Criar trigger para que seja executada a procedure que alimenta o contexto a cada logon

create or replace trigger log_on_vpd

after logon on database

begin

call proc_ctx_emp.set_ctx_emp

end;

/

Pronto!

Com isso, após cada usuário logar no banco, o VPD irá identificar o seu cod_empresa e fará com que todos os selects, inserts, updates e deletes

filtrem pelo seu cod_empresa.

PS.: Há particularidades referentes aos inserts, onde não é naturalmente usada uma cláusula WHERE, e que não vamos abordar neste artigo, mas

pode ser usado o contexto como valor default da coluna alvo do VPD.

Considerações finais

Esta feature disponibilizada pela Oracle atende às necessidades das web applications, onde os dados de várias entidades passam a compartilhar os

mesmos objetos de banco.

E o melhor: de forma nativa, implementada pelo próprio fabricante do banco de dados.

Podemos destacar os seguintes pontos positivos:

O uso de VPD reduz a possibilidade de falhas de segurança que existem em políticas implementadas somente nas aplicações, assegurando

todos os acessos independente da fonte;

Facilita a manutenção;

Diminui o tempo de implementação;

Possui bom desempenho, por se tratar de uma feature nativa;

É transparente ao usuário, entre várias outras vantagens.

Existem outras features que a Oracle disponibiliza que podem ser implementadas juntamente com o VPD, como por exemplo grupos de políticas,

colunas relevantes e máscara para as colunas alvo do VPD (Relevant Column and Masking) e rótulos de segurança (LABEL SECURITY).

Estas outras features também estão documentadas nos manuais da Oracle e podem ser abordadas em futuros artigos.

Anderson Rodrigo Farias

http://www.devmedia.com.br/post-5747-VPD-Virtual-Private-Database-Seguranca-dos-dados-em-nivel-de-linha.html

A mágica dos bancos de dados

A economia mundial espera por uma explosão do e-commerce para breve e, preparando-se para a nova fase, as empresas se empenham em avaliar

os bancos de dados mais famosos do mercado, uma vez que seus negócios dependerão vitalmente deles. Performance, estabilidade, sistema de

licenças, escalabilidade, suporte corporativo e qualidade da mão-de-obra são alguns dos tópicos estratégicos e que podem significar um diferencial

importante perante a concorrência. A RdL começa nessa edição a apresentar uma série de artigos que analisarão as características dos principais

títulos nessa área.

Oracle Como o Linux é o sistema operacional que mais cresce no mundo, não era de se estranhar que as grandes empresas de software

decidissem portar seus produtos para a plataforma. A Oracle iniciou o processo de adaptação para o Linux após verificar uma gigantesca demanda no

mercado, por ser este sistema uma alternativa mais estável e de menor custo.

Vantagens As vantagens do banco de dados da Oracle sobre a concorrência são inúmeras. O Oracle conta com uma base instalada de milhares de

usuários. Isto acabou por criar uma enorme comunidade. Estes usuários têm o costume de trocar informações, facilitando a tarefa de resolução de

problemas.

Além disso, tecnologicamente o Oracle não tem paralelo no mundo, dando suporte, por exemplo, a:

Data Warehousing: o Oracle 8i torna simples a criação e manutenção de data warehouses. A versão 8i trouxe maior desempenho, melhor

utilização de recursos, maior capacidade de análise de dados e maior transparência na otimização de consultas.

Segurança: a Oracle Internet Platform protege o banco de ataques via Web sem prejudicar a disponibilidade de informações e desempenho.

A Virtual Private Database (VPD) do Oracle oferece uma separação segura dos dados dentro da base. A VPD garante que os usuário somente tenham

acesso àqueles dados pertinentes às suas atividades.

11

O banco permite que os dados sejam encriptados dentro do banco de dados. Isso torna possível esconder dados até mesmo do DBA e de

superusuários. Além disso, o Oracle 8i ainda pode encriptar os dados quando estes trafegam pela rede, evitando que sejam interceptados.

Com as auditorias avançadas, pode-se acompanhar toda a atividade dos usuários na base de dados, e responsabilizá-los por suas ações.

Além disso, o Oracle 8i é o único banco de dados comercial com certificação de segurança FIPS 140 Nível 2, a mais alta certificação da classe.

Desenvolvimento: o Oracle contém um arquitetura completa para desenvolvimento de aplicações cliente/servidor ou baseadas na Web. Ele

aposta na linguagem Java como padrão para desenvolvimento, trazendo uma máquina virtual totalmente compatível com as especificações

da Javasoft e vários wizards para desenvolvimento de aplicações em Java de maneira rápida. Além do Java, é possível o desenvolvimento

de aplicações utilizando outras linguagens, inclusive o PL/SQL e o Pro*C, ambos da Oracle.

Integração de Aplicações: muitas vezes surge a necessidade de um sistema distribuído. Por exemplo, quando se quer acessar várias

bases de dados em ponto geográficos isolados ou ainda melhorar o desempenho dividindo dados de maneira descentralizada. O Oracle 8i

tornou simples a tarefa de criação deste tipo de aplicação.

Alta Disponibilidade: segundo a Oracle, a disponibilidade e confiabilidade do banco de dados era o principal objetivo durante o

desenvolvimento do 8i. O banco pode fazer uma manutenção programada e recuperar-se de ações erradas de usuários.

Stored Procedures: o Oracle 8i suporta a programação de stored procedures em Java e em PL/SQL. Isso permite ao programador

centralizar grande parte do código no próprio banco de dados, aumentando o desempenho do sistema.

Triggers: os triggers permitem uma série de possibilidades interessantes. Com eles é possível programar o banco de dados para realizar

uma ação quando alguma condição for satisfeita.

Desvantagens Encontrar as desvantagens do banco mais popular que existe não é uma tarefa das mais simples, já que ele é um dos bancos mais

completos do mundo. Porém, podemos citar algumas:

Instalação Complexa: a instalação do Oracle 8i para Linux é complexa e extremamente demorada. A documentação da instalação é um

tanto confusa.

Exigência do X Instalado: uma das maiores queixas quanto à instalação do Oracle 8i é sua instalação gráfica. Como o Oracle é

normalmente instalado em servidores, onde, muitas vezes, não há o interesse de interfaces gráficas, obrigar os administradores a instalarem

o X é algo desagradável.

Software Proprietário: a maior desvantagem do Oracle 8i é não ser um software livre. Ele também tem um custo bastante alto de licenças

em comparação com outros bancos.

O Futuro A próxima versão do Oracle promete inovações revolucionárias. Entre elas está a utilização de um sistema de arquivos próprio. Ou seja,

os dados serão gravados de forma crua diretamente em disco, sem a intervenção do sistema operacional. Espera-se que isto aumente o desempenho

do sistema.