TABELAS READ ONLY

Olá, hoje vamos falar de uma nova funcionalidade do 11G, colocar uma tabela no modo read only.

A partir do Oracle 11G release 1 o estado de uma tabela pode ser alterado de read write para read only com o comando ALTER TABLE.

Abaixo uma demonstração dessa nova funcionalidade:

SQL> CREATE TABLE TESTE(
  2  CODIGO NUMBER);

Tabela criada.

SQL> INSERT INTO TESTE
  2  VALUES(1);

1 linha criada.

SQL> SELECT TABLE_NAME,READ_ONLY FROM USER_TABLES WHERE TABLE_NAME = 'TESTE';

TABLE_NAME                     REA
------------------------------ ---
TESTE                          NO

SQL> ALTER TABLE TESTE READ ONLY;

Tabela alterada.

SQL> SELECT TABLE_NAME,READ_ONLY FROM USER_TABLES WHERE TABLE_NAME = 'TESTE';

TABLE_NAME                     REA
------------------------------ ---
TESTE                          YES

SQL> DELETE TESTE;
DELETE TESTE
       *
ERRO na linha 1:
ORA-12081: operação de atualização não permitida na tabela "ISABELE"."TESTE"


SQL> TRUNCATE TABLE TESTE;
TRUNCATE TABLE TESTE
               *
ERRO na linha 1:
ORA-12081: operação de atualização não permitida na tabela "ISABELE"."TESTE"


SQL> UPDATE TESTE
  2  SET CODIGO = 2;
UPDATE TESTE
       *
ERRO na linha 1:
ORA-12081: operação de atualização não permitida na tabela "ISABELE"."TESTE"


SQL> INSERT INTO TESTE
  2  VALUES(2);
INSERT INTO TESTE
            *
ERRO na linha 1:
ORA-12081: operação de atualização não permitida na tabela "ISABELE"."TESTE"


SQL> ALTER TABLE TESTE READ WRITE;

Tabela alterada.

SQL>  INSERT INTO TESTE
  2   VALUES(2);

1 linha criada.

SQL> COMMIT;

Commit concluído.

Qualquer comando DML e DDL(Truncate) não irá funcionar enquanto a tabela estiver no modo READ ONLY. Comandos merge e select for update também não serão permitidos.
Uma ótima forma de restringuir o acesso a uma tabela específica.

Um abraço e até o próximo post.


Fonte:http://eduardolegatti.blogspot.com.br/2008/06/read-only-table-abordando-uma-nova.html

RESIZE UNDO TABLESPACE

Olá Pessoal,

Hoje vou compartilhar com vocês uma experiência, onde tive que realizar a recriação de uma tablespace de undo.
O datafile da tablespace foi colocado UNLIMITED, ou seja, chegou a 32GB e ao tentar fazer o resize ocorria o ORA-3297 erro: arquivo contém dados usados além do valor de RESIZE solicitado, então tive que criar uma nova tablespace e eliminar a antiga.

Segue o passo a passo realizado:

1- Criar uma nova tablespace de UNDO:

CREATE UNDO TABLESPACE UNDOTBS2 DATAFILE '/u01/oradata/orcl/undotbs2_01.dbf'
SIZE 2048M;

2- Definir a nova tablespace criada como default do banco de dados:

OBS:Podemos ter várias tablespaces de undo criadas, mas apenas 1 delas pode ser a default do banco.

ALTER SYSTEM SET UNDO_TABLESPACE=UNDOTBS2 SCOPE=BOTH;

As novas transações vão utilizar a nova tablespace de undo, depois de um tempo(você deve esperar no mínimo o tempo do parâmetro UNDO_RETENTION).

3- Eliminar a tablespace de UNDO antiga ou realizar o resize:

DROP TABLESPACE UNDOTBS1 INCLUDING CONTENTS AND DATAFILES;

OU

ALTER DATABASE DATAFILE '/u01/oradata/orcl/undotbs1_01.dbf' RESIZE 1M;

Por hoje é só, até o próximo post.

ADD DATAFILE FAILOVER

Esta semana precisei aidiconar um datafile em um banco de dados que tem espelhamento, como está de forma
manual tive que adiconar manualmente no standby.

Depois de adicionado no primário:
adicionei o datafile '/oradata/bdprod/data24.dbf';
Fui até o secundário e:

-- copiei os ultimos archives gerados no primário para o secundário.
-- montei o banco de dados secundário.


scp xxxxx.arc 199.999.999.999:/aaa/bbb/ccc/arch/

-- startup mount

depois:

-- recover stanby database;

escolhi a opção AUTO

esperei gerar o erro em que ele não acha o datafile adicionado.

-- depois de feita a verificação dos archives,
-- fiz a consulta para ver onde estava o DBF simbólico criado automaticamente.

-- select name from v$datafile

/aa/bbb/ccc/UNNAMED00044

-- troquei o nome arquivo para o arquivo adicionado no primário:

alter database
create datafile '/xxx/xxxx/xxx/xxxx/xxxx/xxx/UNNAMED00044' as '/oradata/bdprod/data24.dbf';


executei novamente o recover, para me certificar q não iria dar o erro ao procurar o datafile.


shutdown immediate

('.') Everaldo Ferreira - DBA

Comandos básicos VI Solaris

Pessoal segue uma pequena lista de comandos que ajudam bastante na hora de editar um arquivo no Solaris.

ESC x -> apaga caracter atual
ESC X -> apaga caracter anterior
ESC h -> esquerda
ESC l -> direita
ESC k -> cima
ESC j -> baixo
dd ----> remove linha
ESC i -> entra no modo editável do vi, similar ao INSERT (Linux)
ESC a -> insere após o caracter atual
ESC A -> final da linha
SHIFT A -> vai para o próximo campo vazio na linha, similar ao ESC a.

('.') Everaldo Ferreira - DBA

Deployee Agent 12c GRID

Instalando agent para monitoração no grid 12c

1- baixar o agent
2- disponibilizar no servidor alvo, descompactar o arquivo:
12.1.0.1.0_AgentSoftware_23.zip

- vá até o diretório archives, descompactar os arquivos:
12.1.0.1.0_AgentCore_23.zip
agentcoreimage.zip


3- Editar o arquivo agent.rsp, com seguintes parametros.

4- Dentro do oracle_home, criar diretorio, OMSagent

OMS_HOST= servidor onde está o grid
EM_UPLOAD_PORT=4900
AGENT_REGISTRATION_PASSWORD= senha do sysman do grid
AGENT_INSTANCE_HOME="ORACLE_HOME"/OMSagent
AGENT_PORT=porta para comunicação com agente do OMS_HOST
b_startAgent=true
ORACLE_HOSTNAME= nome do servidor onde está sendo instalado o agent, colocar dominio
s_agentHomeName=agent_home
 
5-  executar: (exemplo)

./agentDeploy.sh AGENT_BASE_DIR=/oracle/prdbd/10.2.0.5/ RESPONSE_FILE=/oracle/prdbd/10.2.0.5/OMSagent/agent.rsp

-- se ocorrer o erro abaixo:

-e
 ERROR: OMS_HOST cannot be null. Pass OMS_HOST value either as command-line arguments or in response file.

executar, passando os parametros separados por espaço conforme abaixo. alterar a senha do sysman na variável AGENT_REGISTRATION_PASSWORD

Estes são obrigatórios


./agentDeploy.sh AGENT_BASE_DIR=/oracle/prdbd/10.2.0.5/ OMS_HOST=serverbd EM_UPLOAD_PORT=4900 AGENT_REGISTRATION_PASSWORD=******** AGENT_PORT=3872 b_startAgent=true ORACLE_HOSTNAME=serverbd.local s_agentHomeName=agent_home


('.') Everaldo Ferreira - DBA

Reiniciando EXADATA

Aloo pessoal olha a hora!!!

DESABILITAR O START AUTOMATICO DO CRS, isso é porque ele irá tentar subir automaticamente uma vez q o serviço fique indisponível.

Conectar no servidor via Putty – ssh –   servidor    servidorprd

CARREGAR O PROFILE DO ASM-GRID
. oraenv

+ASM1

-- Testar se o comando decli esta conectando nos  servidores

dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l root date

-- Executar o comando para realizar o disable do crs

dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l root /u01/app/11.2.0.2/grid/bin/crsctl disable crs

servidorprd1: CRS-4622: Oracle High Availability Services autostart is disabled.
servidorprd2: CRS-4622: Oracle High Availability Services autostart is disabled.
servidorprd3: CRS-4622: Oracle High Availability Services autostart is disabled.
servidorprd4: CRS-4622: Oracle High Availability Services autostart is disabled.

-- PARAR DBFS –  filesystem

crsctl stop resource dbfs_scorp

-- utilizando USUARIO ORACLE

parar todas as bases de dados

. oraenv

srvctl stop database -d xyz -o immediate


-- Conectar no servidor como ROOT

-- parar o cluster

crsctl stop cluster -ALL

dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l crsctl stop crs

-- desligar o dbservers - poweroff

dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l root init 0

-- desligar celulas de armazenamento (storage)

-- celula1

ssh xx.x.xx.xxx

-- testar a conexão das células

dcli -g cell_group -l root date

-- comando para desligar

dcli -g cell_group -l root init 0



                                             Reiniciando o Ambiente



ligar as células fisicamente (dedão mesmo no power)

Aguardar...

-- VIA PUTTY NA CELULA 1

-- TESTAR A CONEXAO DAS CELULAS

dcli -g cell_group -l root date

-- TESTAR TODAS AS CELULAS

dcli -g cell_group -l root /etc/init.d/celld status
servercel01: rsStatus:             running
servercel01: msStatus:             running
servercel01: cellsrvStatus:        running
servercel02: rsStatus:             running
servercel02: msStatus:             running
servercel02: cellsrvStatus:        running
servercel03: rsStatus:             running
servercel03: msStatus:             running
servercel03: cellsrvStatus:        running
servercel04: rsStatus:             running
servercel04: msStatus:             running
servercel04: cellsrvStatus:        running
servercel05: rsStatus:             running
servercel05: msStatus:             running
servercel05: cellsrvStatus:        running



REINICIAR OS SERVIDORES DE BANCO
. oraenv
+ASM1

1.    crsctl start cluster -ALL
2.    dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l crsctl start crs
3.    dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l root /u01/app/11.2.0.2/grid/bin/crsctl enable crs



-- com USUARIO ORACLE
subir os bancos de dados

. oraenv

srvctl start database -d xyz


No final para subir o NFS, tem q reconectar como root

INICIAR O  DBFS
. oraenv
+ASM1

crsctl start resource dbfs_scorp

('.') Everaldo Ferreira - DBA

Desinstalar Agente GRID 12c

Desinstalando o agente e todas as suas ramificações:

Dificil mas achei um doc.

Segue o comando:

-- exportando a variável, caso esteja utilizando por exemplo o x-manager
export DISPLAY=10.2.1.200:0.0

-- digite o comando abaixo
$AGENT_HOME/oui/bin/runInstaller –deinstall

-- irá abrir a tela para remover os componentes, selecione os que fazem referencia ao agente, se escolher todos de uma só vez pode dar um erro referente a dependencias. Escolha novamente na ordem e prossiga.


('.') Everaldo Ferreira - DBA

TUNING DE REDO LOG

Pessoal,

Neste Post vamos falar um pouco sobre um assunto que tenho muito interesse, o Tuning do Banco Oracle.
Tuning é um assunto muito grande e complexo, por isso vou atacar neste Post apenas uma parte do Tuning do Redo Log, porém de forma objetiva e eficaz.

O tamanho e a quantidade dos REDO LOG's influenciam muito no desempenho de gravação do Banco. Tanto para um processo de importação de dados quanto para instruções DML.

Para melhoria de performance a Oracle recomenda que os arquivos de Redo Log estejam em um disco diferente do disco onde localiza-se os os arquivos de dados (Data Files) e que a troca dos arquivos de redo log seja feita entre 20 à 30 minutos no máximo, pois menos causa contenção de escrita e mais que 30 minutos aumenta muito o tempo de recuperação.

Como posso identificar de quanto em quanto tempo a troca do Redo Log está sendo realizada ?

Para isso você deve fazer uma regra de três no tamanho do redo:
Ex: você tem troca de redo a cada 10 minutos, o tamanho do seu redo log é de 100MB cada grupo.
Então você deve recriar com 300MB para que o tempo suba para 30 minutos.

A query que faz esta verificação é a seguinte:

select group#,
       thread#,
       to_char(first_time,'DD/MM HH24:MI') TROCA_REDO,
       (BYTES /1024/1024) TAMANHO_MB
  FROM V$LOG ORDER BY 2, FIRST_TIME;

Como faço para alterar o tamanho dos arquivos de Redo Log ?

Abaixo segue o procedimento para realizar a alteração:

-- Para verificar o arquivo de redo log corrente:

SELECT * FROM V$LOG;


-- Para alterar/recriar o arquivo de redo log ele deve estar com STATUS INATIVO, caso necessite forçar a troca do arquivo de Redo Log, execute o comando abaixo:

ALTER SYSTEM SWITCH LOGFILE;


-- Não é possível alterar o tamanho do Redo Log já existente, portanto deve-se eliminar o arquivo ou grupo de Redo Log:

ALTER DATABASE DROP LOGFILE GROUP <<numero_grupo>>;

Exemplo:
ALTER DATABASE DROP LOGFILE GROUP 1;


-- Agora basta adicionar o novo grupo de Redo Log com o novo tamanho:

ALTER DATABASE ADD LOGFILE GROUP <<numero_grupo>> ('<<caminho dos membros>>') size <<tamanho>>;

Exemplo:
ALTER DATABASE ADD LOGFILE GROUP 1 (‘\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01A.LOG’, ‘\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01B.LOG’) SIZE 200M;


A T E N Ç Ã O ! ! !

Por padrão ao criar a Instância Oracle é criado 3 grupos de Redo Log. Porém para que a mesma possa ser iniciada é necessário no mínimo 2 grupos de Redo Log.
Enfim, ao apagar, garanta que tenha ao menos 2 grupos de Redo Log, só apague novamente outro grupo após criar mais um novo !!



Galera é isso aí !!!  Espero que esse procedimento possa ajudar a todos caso seja necessário !!

Abraços e até o próximo post,

DIEGO GARCIA FRANCISCO
DBA Oracle
Oracle Database 11g Administrator Certified Associate
(21) 7925-4500 / (21) 8714-2496

DEFERRED_SEGMENT_CREATION

Olá pessoal,

Hoje vamos falar de um parâmetro incluído no oracle 11GR2 o DEFERRED_SEGMENT_CREATION, que é a criação adiada de segmento, ou seja, só é alocado segmento na tabela quando uma linha é inserida, por default esse parâmetro vem como TRUE.

Vamos ao exemplo:

SQL> CREATE TABLE B
2 (ID NUMBER);

Tabela criada.

SQL> select segment_name from user_segments where segment_name = 'B';
não há linhas selecionadas

SQL> INSERT INTO B
2 VALUES(1);
1 linha criada.

SQL> select segment_name from user_segments where segment_name = 'B';
SEGMENT_NAME
-------------------------------------------------------------------------
B

Veja que só trouxe resultado na view user_segments após o insert.

As vantagens desse parâmetro são:

1-Economia de espaço, pois evita a alocação de segmentos em tabelas vazias.
2-Na criação da tabela não ocorrerá erros referentes a falta de privilégios ou falta de espaço em tablespace.
3-As execuções de instruções DDL ficam mais rápidas, pois não é criado segmento em disco.

Para alterar o parâmetro a nível de instância utilize o comando abaixo:

ALTER SYSTEM SET DEFERRED_SEGMENT_CREATION=[TRUE | FALSE];

Também pode ser alterado a nível de sessão:

ALTER SESSION SET DEFERRED_SEGMENT_CREATION =[TRUE | FALSE];

E a nível de tabela:

CREATE TABLE T1 (id number) SEGMENT CREATION [IMMEDIATE | DEFERRED];

Alguns pontos importantes sobre essa nova funcionalidade:

1- Só está disponível para a versão Enterprise Edition, então caso seja efetuado um export de um banco oracle 11GR2 Enterprise Edition para um banco oracle 11GR2 Standart Edition ou release/versão inferior, deve se usar o parâmetro compatibilidade (version) no expdp, pois se existir alguma tabela sem segmento, ocorrerá o erro ORA-00439: feature not enabled: Deferred Segment Creation. 

2- O utilitário EXP não reconhece tabelas sem segmentos, ou seja, se você utilizar o exp no banco 11GR2 e existir alguma tabela sem segmento, ela não será exportada.Então utilize o EXPDP ou então desabilite o parâmentro e force a criação de segmentos com o comando ALTER TABLE <<table_name>> ALLOCATE EXTENT. Esse problema foi corrigido no release 11.2.0.2.

3- No 11.2.0.2 o parâmentro também é válido para tabelas particionadas e foi adicionado 2 procedimentos ao pacote DBMS_SPACE_ADMIN para o gerenciamento de segmentos:

DBMS_SPACE_ADMIN.materialize_deferred_segments -> Força a criação de segmentos para tabela em que a criação dos segmentos foi adiada. Exemplo:

BEGIN
DBMS_SPACE_ADMIN.materialize_deferred_segments (
schema_name => 'TESTE'
table_name => 'TAB1',
nome_da_partição => NULL);
END;
/

DBMS_SPACE_ADMIN.drop_empty_segments -> Elimina os segmentos de tabelas sem linhas.
Exemplo:

BEGIN
DBMS_SPACE_ADMIN.drop_empty_segments (
schema_name => 'TESTE'
table_name => 'TAB1',
nome_da_partição => NULL);
END;
/

Até o próximo post.
Isabele Barros

CASE SENSITIVE ORACLE 11G

Olá Pessoal,

Nesse post estarei falando sobre o case sensitive, que foi implementado no oracle 11G.

A partir do oracle 11G a senha tem diferenciação entre letras maiúsculas e minúsculas.
O parâmetro que faz esse controle é o sec_case_sensitive_logon que por padrão é TRUE.

Exemplo:

SQL> CREATE USER TESTE IDENTIFIED BY TESTE;

Usuário criado.

SQL> conn TESTE/teste
ERROR:
ORA-01017: senha/nome do usuário inválido; log-on negado

SQL> conn TESTE/Teste
ERROR:
ORA-01017: senha/nome do usuário inválido; log-on negado

SQL> conn TESTE/TESTE
Conectado.

Para desabilitar essa funcionalidade basta executar o comando abaixo:

ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON= FALSE SCOPE=BOTH;

Outra mudança foi com relação a view dba_users, além de não tem incluída a informação do password, agora contém mais uma coluna a PASSWORD_VERSIONS:

Quando o valor da coluna está 10G, mesmo que o parâmetro sec_case_sensitive_logon esteja ativado, essa senha não será case sensitive.
Quando o valor da coluna está 10G 11G, a senha será case sessitive se o parâmetro sec_case_sensitive_logon estiver ativado.
Quando o valor da coluna está 11G, o usuário só poderá se conectar ao banco de dados se o parâmetro sec_case_sensitive_logon estiver ativado.

A alteração dessas informações pode ser realizada através do ALTER USER:

ALTER USER TESTE IDENTIFIED BY TESTE;

Valor da coluna PASSWORD_VERSIONS 10G 11G

ALTER USER TESTE IDENTIFIED BY VALUES '864B0E03A5061B6D';

Valor da coluna PASSWORD_VERSIONS 10G

ALTER USER TESTE IDENTIFIED BY VALUES 'S:C2876E5B7D4AF6281DB01D658FABB63E11C6BB9F8D501C73255484CC65B1';

Valor da coluna PASSWORD_VERSIONS 11G

As informações da senha criptografada você encontra na view SYS.USER$ nas colunas PASSWORD(10G) e SPARE4(11G).

Espero que tenha esclarecido um pouco sobre essas mudanças.

Até o próximo post.
Isabele Barros

Recover Desaster RMAN

********************************************************
 RESTAURAÇÃO EM DESASTRES DE BANCO DE DADOS
********************************************************

Fala galera !!!

Como é meu Post de estréia na MHDBA, não poderia falar de outro assunto se não o RMAN !!
Como todos sabem gosto muito desta ferramenta de Backup poderosa do Oracle.

Este Post mostra como recuperar um Banco de dados em outro servidor em casos de desastres/perdas de todo Banco de dados.

Tentarei sempre fazer um passo-à-passo em meus Posts para facilitar o entendimento e a execução do mesmo.
Vamos ao que interessa ...

NO NOVO SERVIDOR:

1- INSTALAR APENAS O SOFTWARE DO ORACLE SEM INSTANCIA.

2- CRIAR A MESMA ESTRUTURA DO OUTRO SERVIDOR. ( INCLUSIVE AS PASTAS - ADUMP,BDUMP.CDUMP,DPDUMP,PFILE E UDUMP )

3- COLOCAR O BACKUP RMAN NO MESMO CAMINHO ONDE ENCONTRAVA-SE NO ANTIGO SERVIDOR (INDICADO NO PARAMETRO db_recovery_file_dest).

4- SE FOR WINDOWS, CRIAR O SERVIÇO DO WINDOWS(ORACLE) COM O ORADIM.

   oradim -new -sid Instancia_do_banco -syspwd senha

CONTINUANDO ...


-- Entrar no Prompt de comando e executar os seguintes comandos:


SET ORACLE_SID=<<NOME DO BANCO NOVO>>

SQLPLUS SYS AS SYSDBA

SHUTDOWN IMMEDIATE;


-- Startando o RMAN e conectando no banco Target:

 RMAN

 RMAN> CONNECT TARGET SYS


-- Setando o DBID

 RMAN> SET DBID <<dbid_do_banco_origem>>;  -- DBID do banco que parou (ANTIGO).


-- Startando o Banco em Modo Nomount, já que o Control File ainda não foi restaurado 

 RMAN> STARTUP FORCE NOMOUNT PFILE '?/oradata/teste/initteste.ora';  -- Caminho init.ora


OBS.: SE EXISTIR, APAGAR OS ARQUIVOS DE REDO ANTIGOS EXISTENTES NA PASTA ORADATA.


-- Restaurando o Control file e alterando o Status do banco para MOUNT

 RMAN>   RESTORE CONTROLFILE FROM AUTOBACKUP;
          ALTER DATABASE MOUNT;


-- Restaurando o Banco e aplicando os archives necessários.

OBS.: Reparem que abri 3 Canais (Conexões) para que o processo de recuperação seja o mais rápido possível. A restauração trabalhará em paralelismo. Neste caso 3 forças ao invés de apenas 1.


RMAN>   RUN{
               ALLOCATE CHANNEL c1 DEVICE TYPE disk;
               ALLOCATE CHANNEL c2 DEVICE TYPE disk;
               ALLOCATE CHANNEL c3 DEVICE TYPE disk;
           RESTORE DATABASE;
      RECOVER DATABASE;}

Pronto !! Banco Restaurado e emprego mantido !!! rsrsrs

Mais ainda não acabou !!!


CONTINUANDO ...

-- Saia do Prompt do RMAN, vá até o sqlplus e abra o Banco de dados para apenas leitura e verifique se os dados estão corretos. 

 SQL> ALTER DATABASE OPEN READ ONLY;


 -- Após verificar se os dados estão corretos, abra o Banco resetando os Logs.

 RMAN> ALTER DATABASE OPEN RESETLOGS;


-- Não esqueça de criar o SPFILE e Startar o(s) LISTENER(s) do Banco.

CREATE SPFILE FROM PFILE='C:\oracle\admin\TL07\pfile\initTL07.ora';


LSNRCTL START <<NOME_DO_LISTENER>>


OBS.: Após todo esse processo o aconselhável é fazer um Backup Full do novo Banco de dados !!!

 FIM DO PROCESSO !!!

Galera é isso aí !!  Espero que possamos divulgar cada vez mais nossos conhecimentos e assim crescermos juntos na Profissão !!!
Lembrando:

     " Jesus faz milagre !!!  DBA faz Backup !!! "

Abraços,
DIEGO GARCIA FRANCISCO
DBA Oracle
Oracle Database 11g Administrator Certified Associate
(21) 7925-4500 / (21) 8714-2496

Verificar senha criptografada dos usuários no oracle 11G

Como trazer a senha que é armazenada na coluna PASSWORD da view DBA_USERS no Oracle 11g?

Galera, descobri isso há pouco tempo e achei interessante postar aqui. O Oracle 11g veio com algumas novidades na segurança, como o parâmetro case sensitive. Nas versões mais antigas do Oracle é possível extrair a senha criptografada dos usuários através da view DBA_USERS. No Oracle 11 a coisa é diferente, se você fizer o select retornará o campo PASSWORD em branco.

SQL> SELECT USERNAME, PASSWORD
2 FROM DBA_USERS
3 WHERE USERNAME='SYSTEM';

USERNAME PASSWORD
--------------- ------------------------------
SYSTEM<>

Analisando a view DBA_USERS, resolvi dar uns selects direto nas tabelas que ela se baseia, e encontrei a SYS.USER$. O Oracle 11g dificulta um pouquinho, mas conseguimos da nossa maneira tradicional, com nossos scripts dinâmicos, extrair a senha numa boa usando essa tabela. (claro, tendo privilégio de select para mesma).

Bom, caros amigos DBA'S...é isso. Achei interessante compartilhar. Desculpa se não tá muito bem explicado, mas sou péssimo em didática hehe

Grande abraço e até a próxima!