Recuperando credenciais de administrador no weblogic

 

Dica para quem esqueceu as credenciais de acesso ao Weblogic.

Capture as informações criptografadas a partir do arquivo boot.properties localizado no $USERDOMAIN_HOME/servers/AdminServer/security/

[root@wls ~]# export USERDOMAIN_HOME=/u01/Oracle/Middleware/Oracle_Home/user_projects/domains/app_domain
[root@wls ~]# cd $USERDOMAIN_HOME/servers/AdminServer/security/
[root@wls security]# cat boot.properties
# Generated by Configuration Wizard on Mon Jun 27 07:42:49 BRT 2016
username={AES}zoDTpzXJwBoWCPwqbTuoBhQiR8bIneBw1nnumM2XkAU=
password={AES}MRuZtj19v4RBzFCb4gX5IM+qItLDVAaP1IC13WvTitA=

Carregue as as variáveis de ambiente do domínio:

[root@wls security]# . $USERDOMAIN_HOME/bin/setDomainEnv.sh

Crie um arquivo chamado recoverpassword.java, por exemplo, contendo o seguinte comando:

[root@wls app_domain]# cat recoverpassword.java
public class recoverpassword {
 public static void main(String[] args)
 {
  System.out.println(
  new weblogic.security.internal.encryption.ClearOrEncryptedService(
  weblogic.security.internal.SerializedSystemIni.getEncryptionService(args[0]
   )).decrypt(args[1]));
  }
}

Chame a classe java criada passando a string criptografada do arquivo boot.properties como parâmetro:

[root@wls app_domain]# java -cp $CLASSPATH:. recoverpassword $DOMAIN_HOME {AES}zoDTpzXJwBoWCPwqbTuoBhQiR8bIneBw1nnumM2XkAU=
weblogic
[root@wls app_domain]# java -cp $CLASSPATH:. recoverpassword $DOMAIN_HOME {AES}MRuZtj19v4RBzFCb4gX5IM+qItLDVAaP1IC13WvTitA=
Passw0rd

A saída do comando trará em texto simples o nome de usuário e senha do administrador do Weblogic.

Mesmo que existam vários ambientes com as mesmas credenciais, o retorno do arquivo boot.properties pode conter textos criptografados diferentes, pois ao criptografar e descriptografar o weblogic usa a chave cifrada armazenada no arquivo "security/SerializedSystemIni.dat". Portanto, sendo a chave de cifra diferente, é possível obter um texto criptografado diferente até para a mesma entrada.

Mais informações →

Alterando senhas no Exadata Database Machine (Database Node, Cell Node, ILOM, KVM, Switches e PDU)

Com a globalização, passamos a viver em um mundo cada vez mais digital, redes sociais, comercio eletrônico e até computação nas nuvens passou a fazer parte do dia-a-dia de muitas pessoas.

É fatídico dizer que, quanto mais nos tornamos digitais mais nos tornamos vulneráveis. Ataques a grandes sistemas e empresas são exemplos atuais do que podemos dizer, frutos da globalização e agora internet das coisas (do inglês, Internet of Things).

Investir em segurança deixou de ser banal e cada vez mais se faz necessário estarmos seguros.

Muitos sistemas e equipamentos adquiridos no mercado possuem senhas padrões. No Exadata não é diferente, ele também é implementado com várias contas de usuários e senhas padrões. Estando ele na internet, com as senhas padrões, qual seria a probabilidade de não ser invadido em um tentativa de ataque?

É o mesmo que dizer que a senha bancária das pessoas correspondem ao seu próprio nome, desta forma, o que me impediria de acessar a conta alheia?

Abaixo temos os usuários e senhas padrões de vários componentes do Exadata Database Machine:

Componente	User Name	Password
Compute Nodes	root oracle grid dbmadmin   (image 12.1.2.x.x ou acima) dbmmonitor (image 12.1.2.x.x ou acima) grub root ILOM)	welcome1 welcome1 welcome1 welcome1 welcome1 sos1Exadata welcome1
Cell Nodes	root celladmin cellmonitor root (ILOM)	welcome1 welcome1 welcome1 welcome1
InfiniBand switches	root nm2user ilom-admin (ILOM) ilom-operator (ILOM)	welcome1 changeme ilom-admin ilom-operator
Ethernet switches	admin	welcome1
Power distribution units (PDUs)	admin root	welcome1 welcome1

NOTA: Nas PDUs o usuário/senha default, conforme Doc ID 1570252.1 também pode ser admin/admin para PDU firmware anterior a 1.05 e admin/adm1n para PDU firmware 1.06 e superior.

Como visto acima, "welcome1" faz um enorme sucesso como senha! Mas bem, veremos a seguir como alterar estas senhas.

•         Componente: Database Node (compute node)

Estando conectado no database node, podemos alterar a senha com o comando "passwd" ou "passwd <username>", ou para tornar o trabalho mais rápido e prático, podemos utilizar o DCLI para alterar a senha em todos os database nodes de uma única vez.

Exemplo:

Alterando a senha do usuário oracle para H4rdPwd234 em todos os database nodes de uma única vez.

[root@dbnode1 ~]# dcli -g dbs_group -l root "echo H4rdPwd234 | passwd --stdin oracle"
170.10.0.10: Changing password for user oracle.
170.10.0.10: passwd: all authentication tokens updated successfully.
170.10.0.11: Changing password for user oracle.
170.10.0.11: passwd: all authentication tokens updated successfully.

O comando pode ser executado para qualquer conta a nível de sistema operacional.

Para outras contas padrões de instalação:

dcli -g dbs_group -l root "echo H4rdPwd234 | passwd --stdin oracle"
dcli -g dbs_group -l root "echo H4rdPwd234 | passwd --stdin grid"
dcli -g dbs_group -l root "echo H4rdPwd234 | passwd --stdin dbmadmin"

Podemos também atribuir diferentes senhas para cada usuário:

dcli -g dbs_group -l root "echo pWD4acc355 | passwd --stdin root"

Se ao executar o DCLI informar que o grupo não existe, basta criar um arquivo com o nome do grupo que você desejar (dbs_groups, cell_groups, dbs_cell_groups) e adicionar neste arquivo os ips dos servidores que você quer que façam parte dele.

[root@dbnode1 ~]# cat cell_group
170.10.0.12
170.10.0.13
170.10.0.14
[root@dbnode1 ~]# cat dbs_group
170.10.0.10
170.10.0.11

Pode ocorrer também problema por falta de equivalência (chave pública) entre os servidores.

Para testar se a equivalência do grupo está funcionando:

[root@dbnode1 ~]# dcli -g cell_group -l root 'hostname'
170.10.0.12: cellnode1
170.10.0.13: cellnode2
170.10.0.14: cellnode3

Caso ocorra erros informando a necessidade de password, basta executar o procedimento abaixo para criar a equivalência.

[root@dbnode1 ~]# dcli -g cell_group -l root -k
root@cellnode1's password:
root@cellnode2's password:
root@cellnode3's password:
cellnode1: ssh key added
cellnode2: ssh key added
cellnode3: ssh key added

•        Componente: Cell node

Da mesma forma que nos compute nodes, nos cell nodes também podemos alterar a senha conectando em cada um deles e executando um "passwd" ou então, ainda conectado em um compute node, podemos usar o DCLI apenas ajustando o grupo para cell_group e alterar a senha de todos os cell nodes de uma única vez.

Exemplo:

[root@dbnode1 ~]# dcli -g cell_group -l root "echo H4rdPwd234 | passwd --stdin celladmin"
170.10.0.12: Changing password for user celladmin.
170.10.0.12: passwd: all authentication tokens updated successfully.
170.10.0.13: Changing password for user celladmin.
170.10.0.13: passwd: all authentication tokens updated successfully.
170.10.0.14: Changing password for user celladmin.
170.10.0.14: passwd: all authentication tokens updated successfully.
[root@dbnode1 ~]#

Para outras contas padrões de instalação:

dcli -g cell_group -l root "echo pWD4acc355 | passwd --stdin root" 
dcli -g cell_group -l root "echo H4rdPwd234 | passwd --stdin cellmonitor"

• ·           Componente: ILOM

Para alterar a senha na ILOM (Integrated Lights Out Manager), além do DCLI que veremos mais abaixo, temos ainda a possibilidade de alterar a senha via interface web (https://<ilom_ip>)

No menu Navigation à ILOM Administration à User Managementà User Accounts à Escolha o usuário à Edit à Altere a senha à Save.

OBS: Dependendo da versão da ILOM, o layout da página pode ser diferente tanto quanto o local de ajuste da senha.

Para alterar conectado na ILOM via command-line:

-> set /SP/users/root password

E finalmente a partir do DCLI que permite alterar facilmente em todos os dbnodes e cellnodes.

[root@dbnode1 ~]# dcli -g dbs_group -l root " ipmitool sunoem cli 'set /SP/users/root password=pWD4acc355' pWD4acc355 "
170.10.0.10: Connected. Use ^D to exit.
170.10.0.10: -> set /SP/users/root password=pWD4acc355
170.10.0.10: Changing password for user /SP/users/root...
170.10.0.10: Enter new password again: ***********
170.10.0.10: New password was successfully set for user /SP/users/root
170.10.0.10:
170.10.0.10: -> Session closed
170.10.0.10: Disconnected
170.10.0.11: Connected. Use ^D to exit.
170.10.0.11: -> set /SP/users/root password=pWD4acc355
170.10.0.11: Changing password for user /SP/users/root...
170.10.0.11: Enter new password again: ***********
170.10.0.11: New password was successfully set for user /SP/users/root
170.10.0.11:
170.10.0.11: -> Session closed
170.10.0.11: Disconnected

[root@dbnode1 ~]# dcli -g cell_group -l root " ipmitool sunoem cli 'set /SP/users/root password=pWD4acc355' pWD4acc355 "
170.10.0.12: Connected. Use ^D to exit.
170.10.0.12: -> set /SP/users/root password=pWD4acc355
170.10.0.12: Changing password for user /SP/users/root...
170.10.0.12: Enter new password again: ***********
170.10.0.12: New password was successfully set for user /SP/users/root
170.10.0.12:
170.10.0.12: -> Session closed
170.10.0.12: Disconnected
170.10.0.13: Connected. Use ^D to exit.
170.10.0.13: -> set /SP/users/root password=pWD4acc355
170.10.0.13: Changing password for user /SP/users/root...
170.10.0.13: Enter new password again: ***********
170.10.0.13: New password was successfully set for user /SP/users/root
170.10.0.13:
170.10.0.13: -> Session closed
170.10.0.13: Disconnected
170.10.0.14: Connected. Use ^D to exit.
170.10.0.14: -> set /SP/users/root password=pWD4acc355
170.10.0.14: Changing password for user /SP/users/root...
170.10.0.14: Enter new password again: ***********
170.10.0.14: New password was successfully set for user /SP/users/root
170.10.0.14:
170.10.0.14: -> Session closed
170.10.0.14: Disconnected

•         Componente: KVM

Para alterar a senha do KVM (Keyboard, Vídeo, Mouse) siga conforme os procedimentos abaixo:

1.       Puxe a bandeja KVM para fora (localizado na frente do rack), abra-a usando a alça;

2.       Toque no touch pad;

3.       Alterne entre o host e a interface KVM pressionando a tecla CTRL no lado esquerdo duas vezes;

4.       Selecione "local" em User Accounts;

5.       Clique em Admin;

6.       Defina a senha para a conta administrador e Salve.

•           Componente: PDU

Acesse a interface web da PDU e clique sobre "Net Configuration", será solicitado usuário e senha.

Conforme supracitado, na PDU o usuário/senha também pode ser admin/admin ou admin/adm1n dependendo da verão do firmware.

Estando conectado, role página até encontrar "Admin/User"

Altere a senha e clique em "Submit"

•                     Componente: Infiniband Switch

Conectando na IB via ssh, verifique a versão do firmware.

[root@sw-iba01 ~]# version
SUN DCS 36p version: 2.1.5-1

Estando na versão 1.3.* use a ILOM para alterar a senha para evitar o bug 13494021

ssh -l ilom-admin 

set /SP/users/ password

Para versões 2.0.3 e superiores:

1.       Conectado no SO usar o "passwd <username>" (com exceção da conta ilom_admin que é necessário conectar na ILOM para realizar a alteração "set /SP/users/ilom-admin password")

2.        Usar o DCLI para alterar a senha em todos os Switches da Infiniband (IB)

a)      Verifique a equivalência com os switches

dcli -g ibswitch_group -l root "hostname"

Caso o grupo "ibswitch_group" não exista, basta criar o arquivo contendo o IP dos IB switches

Crie a equivalência:

[root@dbnode1 ~]# dcli -g ibswitch_group -l root -k
root@170.10.0.22's password:
root@170.10.0.21's password:
170.10.0.21: ssh key added
170.10.0.22: ssh key added
[root@dbnode1 ~]# dcli -g ibswitch_group -l root "hostname"
170.10.0.21: sw-iba01
170.10.0.22: sw-ibb01

b)      Altere a senha em todos os switches da IB de uma única vez via DCLI

[root@dbnode1 ~]# dcli -g ibswitch_group -l root -k
root@170.10.0.22's password:
root@170.10.0.21's password:
170.10.0.21: ssh key added
170.10.0.22: ssh key added
[root@dbnode1 ~]# dcli -g ibswitch_group -l root "hostname"
170.10.0.21: sw-iba01
170.10.0.22: sw-ibb01

Referências:

How to change OS user password for Cell Node, Database Node , ILOM, KVM , Infiniband Switch , GigaBit Ethernet Switch and PDU on Exadata Database Machine (Doc ID 1291766.1)

PDU default password changed after firmware 1.06 and above on Sun Rack II platforms and Engineered Systems (Doc ID 1570252.1)

Mais informações →

ILOM - Erros no "Launch Remote Console"

Recentemente precisei acessar a ILOM (Integrated Lights Out Manager) de um ODA para iniciar a console remota - "Launch Remote Console", contudo veio o primeiro erro:

java.lang.SecurityException: Missing required Permissions manifest attribute in main jar

Pesquisando um pouco encontrei a solução para este erro, conforme passos a seguir:

• Acessar painel de controle;
• "Encontrar" o Java e clicar sobre para abrir o Painel de Controle Java (para facilitar a localização escreva java na caixa de pesquisa);

• Acessar a aba Segurança;
• Clicar sobre "Editar Lista de Sites..."

• Clicar sobre "Adicionar";

• Inserir o IP e porta da ILOM conforme dados do erro;
• OK; OK ..

Feito isto fui abrir novamente a console remota da ILOM.

Agora a console abriu com sucesso, mas como podemos ver abaixo, tive outro erro sendo reportado:

No appropriate protocol (protocol is disabledor cipher suites are inappropriate)

Fazendo mais algumas pesquisas, identifiquei que na CVE-2014-3566 - "SSL V3.0 "Poodle" Vulnerability" o algoritmo SSLv3, por padrão, foi desabilitado a partir da JDK 8u31. Nas versões 7u75 e 6u91 também foram ajustadas.

Conforme nota da versão, habilitei novamente o SSLv3 editando o arquivo <JRE_HOME>/lib/security/java.security

Como estou utilizando um sistema operacional Windows, o arquivo foi localizado em "C:\Program Files\Java\jre1.8.0_91\lib\security" conforme imagem abaixo.

Ao abrir o arquivo com o editor bloco de notas, localizei a entrada jdk.tls.disabledAlgorithms, comentei a linha e salvei o arquivo. 

OBS: retirando apenas a entrada SSLv3 não funcionou comigo

de:

jdk.tls.disabledAlgorithms= SSLv3, RC4, MD5withRSA, DH keySize < 768

para:

#jdk.tls.disabledAlgorithms= SSLv3, RC4, MD5withRSA, DH keySize < 768

Mesmo com o ajuste, ao abrir a console fui submetido a um novo erro:

java.security.cert.CertificateException: Certificates does not conform to algorithm constraints

Voltando as pesquisas... encontrei um novo parâmetro, também dentro do java.security 

Abri novamente o arquivo java.security, localizei o jdk.certpath.disabledAlgorithms e comentei a linha.

de:

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

para:

#jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

Tentando novamente abrir a console remota.. 

Bingo!

Console remota abrindo com sucesso, basta inserir o usuário e senha.

Espero ter ajudado!

Referências:

http://stackoverflow.com/questions/21404830/securityexception-during-executing-jnlp-file-missing-required-permissions-manif

http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html

http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html

http://www.oracle.com/technetwork/java/javase/8u31-relnotes-2389094.html

https://www.richardnichols.net/2012/08/arrrggh-java-security-cert-certificateexception-certificates-does-not-conform-to-algorithm-constraints/

Mais informações →

Default Role

Proporcionado por necessidades distintas de aplicação, segurança e até mesmo alterações incorretas ou desnecessárias é comum nos depararmos com usuários de banco de dados que contenham roles de forma não default (DEFAULT_ROLE = NO).

*Muitos casos com roles não default são constatados quando liberamos uma role a um usuário e ele retorna informando que ainda não possui as permissões esperadas pela role, ao verificar nos deparamos com DEFAULT_ROLE = NO na DBA_ROLE_PRIVS.

SQL> select granted_role, default_role from dba_role_privs where grantee='EXEMPLO';
 
GRANTED_ROLE                   DEF
------------------------------ ---
CONNECT                        YES
RESOURCE                       NO

Quando uma role não é uma DEFAULT ROLE, para que o usuário possa utilizar das permissões a ela atribuídas é preciso “habilitá-la” utilizando o comando SET ROLE.

As roles’s são ajustadas de modo DEFAULT ou NÃO DEFAULT através do comando ALTER USER conforme imagem abaixo:

Quando criamos um usuário, implicitamente ele contém um DEFAULT ROLE ALL, ou seja, as roles atribuídas a este usuário serão automaticamente DEFAULT ROLE (DEFAULT_ROLE = YES). Contudo se um “alter user default role” for executado e a role for alterada de ALL, as novas roles atribuídas ao usuário serão automaticamente não default o que nos submete ao caso apresentado acima(*) do usuário que contem a role mas não consegue utilizar as permissões. 

Para identificarmos estes casos onde uma nova role concedida será NÃO DEFAULT podemos utilizar a SYS.USER$ 

A coluna DEFROLE da SYS.USER$ representa um “status geral” das roles podendo ser 0, 1 ou 2 conforme abaixo: 

0 – Nenhuma. As roles atribuídas ao usuário são todas NÃO DEFAULT. Este valor é setado através de um “ALTER USER DEFAULT ROLE NONE”

SQL> create user exemplo identified by exemplo;
 
User created.
 
SQL> grant connect, resource to exemplo;
 
Grant succeeded.
 
SQL> select name, defrole from sys.user$ where name='EXEMPLO';
 
NAME                              DEFROLE
------------------------------ ----------
EXEMPLO                                 1
 
SQL> alter user exemplo default role none;
 
User altered.
 
SQL> select name, defrole from sys.user$ where name='EXEMPLO';
 
NAME                              DEFROLE
------------------------------ ----------
EXEMPLO                                 0
 
SQL> select granted_role, default_role from dba_role_privs where grantee='EXEMPLO';
 
GRANTED_ROLE                   DEF
------------------------------ ---
CONNECT                        NO
RESOURCE                       NO

1 – As roles atribuidas ao usuários serão sempre DEFAULT ROLE(padrão de criação do usuário). Este valor é setado através de um “ALTER USER DEFAULT ROLE ALL”

SQL> alter user exemplo default role all;
 
User altered.
 
SQL> select name, defrole from sys.user$ where name='EXEMPLO';
 
NAME                              DEFROLE
------------------------------ ----------
EXEMPLO                                 1
 
SQL> select granted_role, default_role from dba_role_privs where grantee='EXEMPLO';
 
GRANTED_ROLE                   DEF
------------------------------ ---
CONNECT                        YES
RESOURCE                       YES

2 – Aponta que existem roles específicas com DEFAULT ROLE (YES). As novas roles concedidas serão sempre NÃO DEFAULT, se precisa ser DEFAULT necessita ser ajustada. Este valor é setado através de um “ALTER USER DEFAULT ROLE ”

SQL> alter user exemplo default role connect;
 
User altered.
 
SQL> select name, defrole from sys.user$ where name='EXEMPLO';
 
NAME                              DEFROLE
------------------------------ ----------
EXEMPLO                                 2
 
SQL> select granted_role, default_role from dba_role_privs where grantee='EXEMPLO';
 
GRANTED_ROLE                   DEF
------------------------------ ---
CONNECT                        YES
RESOURCE                       NO
 
SQL> grant dba to exemplo;
 
Grant succeeded.
 
SQL> select granted_role, default_role from dba_role_privs where grantee='EXEMPLO';
 
GRANTED_ROLE                   DEF
------------------------------ ---
DBA                            NO
CONNECT                        YES
RESOURCE                       NO

A lista das DEFAULT ROLES (YES) podem ser obtidas na SYS.KU$_DEFROLE_LIST_VIEW:

SQL> set lines 200
SQL> select * from sys.KU$_DEFROLE_LIST_VIEW where user_name='EXEMPLO';
 
   USER_ID USER_NAME                      ROLE                              ROLE_ID
---------- ------------------------------ ------------------------------ ----------
      1422 EXEMPLO                        CONNECT                                 2
 
SQL> alter user exemplo default role connect,resource;
 
User altered.
 
SQL> select * from sys.KU$_DEFROLE_LIST_VIEW where user_name='EXEMPLO';
 
   USER_ID USER_NAME                      ROLE                              ROLE_ID
---------- ------------------------------ ------------------------------ ----------
      1422 EXEMPLO                        CONNECT                                 2
      1422 EXEMPLO                        RESOURCE                                3
 
SQL> select granted_role, default_role from dba_role_privs where grantee='EXEMPLO';
 
GRANTED_ROLE                   DEF
------------------------------ ---
DBA                            NO
CONNECT                        YES
RESOURCE                       YES

Fique atento! Como mencionado no inicio deste artigo (necessidades distintas de aplicação e segurança) podem fazer com que realmente seja preciso a existência de roles NÃO DEFAULT e alterando-as para DEFAULT pode gerar problemas. 

Referências: http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_10004.htm#SQLRF55312 http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_4003.htm#SQLRF53554

Mais informações →

Alterando o tempo de inatividade do Enterprise Manager console

Quando o Enterprise Manager, seja database, grid ou cloud control console é acessado, por default exite um tempo de inatividade até que o client HTTP seja desconectado em função do tempo máximo inativo ser violado. Em um EM Coud Control 12c, por exemplo, o client HTTP recebe a mensagem “The page has expired. Click OK to continue”, já no EM Database Control 10g ao tentar reutiliza-lo ele automaticamente redireciona para a página de logon sendo necessário inserir novamente as credenciais de acesso.

Segundo a documentação da Oracle este timout ocorre para prevenir o acesso de pessoas não autorizadas a console, onde após o tempo de inatividade predefinido a página é automaticamente expirada.

“To prevent unauthorized access to the Cloud Control, Enterprise Manager will automatically log you out of Cloud Control when there is no activity for a predefined period of time. For example, if you leave your browser open and leave your office. This default behavior prevents unauthorized users from using your Enterprise Manager administrator account.”

Apesar do timeout ser uma forma de segurança predefinida, visualizar algumas vezes a mensagem de página expirada e/ou precisar inserir novamente as credenciais pode começar a causar certa aflição, principalmente para quem gosta de estar sempre acompanhando o “ambiente” pela console e não está ativamente interagindo com ela, fazendo o timeout ser constantemente alcançado.

Banco=unicloud-> $OMS_HOME/bin/emctl get property -name oracle.sysman.eml.maxInactiveTime
Oracle Enterprise Manager Cloud Control 12c Release 2
Copyright (c) 1996, 2012 Oracle Corporation.  All rights reserved.
SYSMAN password:
Value for property oracle.sysman.eml.maxInactiveTime for oms All Management Servers is null
Banco=unicloud->

É possível visualizar no exemplo acima(cloud control 12c) que o maxInactiveTime está definido como “null“, desta forma prevalece o tempo default de inatividade (45 minutos para grid/cloud control).

Alterando o value para -1 e restartando o OMS (Oracle Management Service), os serviços são ajustados para nunca expirarem, eliminando assim que a mensagem “The page has expired.” seja novamente visualizada no client HTTP.

Banco=unicloud-> $OMS_HOME/bin/emctl set property -name oracle.sysman.eml.maxInactiveTime -value -1
Oracle Enterprise Manager Cloud Control 12c Release 2
Copyright (c) 1996, 2012 Oracle Corporation.  All rights reserved.
SYSMAN password:
Property oracle.sysman.eml.maxInactiveTime has been set to value -1 for all Management Servers
OMS restart is required to reflect the new property value
Banco=unicloud->

O value é sempre especificado em minutos, caso não queira definir o tempo de inatividade como ilimitado(-1) coloque 1 (para 1 minuto), 2,3,4,5 … Para finalizar, reiniciar os serviços(solicitado apos o ajuste do maxInactiveTime):

Banco=unicloud-> $OMS_HOME/bin/emctl stop oms -all
Oracle Enterprise Manager Cloud Control 12c Release 2
Copyright (c) 1996, 2012 Oracle Corporation.  All rights reserved.
Stopping WebTier...
WebTier Successfully Stopped
Stopping Oracle Management Server...
Oracle Management Server Successfully Stopped
AdminServer Successfully Stopped
Oracle Management Server is Down
Banco=unicloud-> $OMS_HOME/bin/emctl start oms
Oracle Enterprise Manager Cloud Control 12c Release 2
Copyright (c) 1996, 2012 Oracle Corporation.  All rights reserved.
Starting Oracle Management Server...
Starting WebTier...
WebTier Successfully Started
Oracle Management Server Successfully Started
Oracle Management Server is Up
Banco=unicloud->

Para a versão 11.x Enterprise Manager Grid Console, o procedimento é basicamente o apresentado acima.

1. Navegar até o diretório de instalação do OMS software e setar o oracle.sysman.eml.maxInactiveTime para o valor requerido:

$ cd $OMS_HOME/bin
$ ./emctl set property -name oracle.sysman.eml.maxInactiveTime -value 60 -sysman_pwd password

2. Reiniciar o OMS:

$ cd $OMS_HOME/bin
$ ./emctl stop oms
$ ./emctl start oms

Na versão 10.x Enterprise Manager Grid Console é necessário editar o arquivo emoms.properties conforme abaixo:

1. Navegar até o diretório $OMS_HOME/sysman/config

2. Efetuar um backup(copia) do arquivo emoms.properties e abrir o arquivo original(emoms.properties) com um editor

3. Vá até o final do arquivo e adicione a seguinte linha: (60 é o tempo em minutos de idle time até que a sessão seja desconectada)

oracle.sysman.eml.maxInactiveTime=60

4. Reiniciar o OMS:

 

$ cd $OMS_HOME/bin
$ ./emctl stop oms
$ ./emctl start oms

Quando utilizamos o Database Control, seja 10 ou 11, devemos seguir as seguintes etapas: -> Diferentemente do grid/cloud control que o tempo default de inatividade é de 45 minutos o database control possui como default 35 minutos! 

1. Parar o dbconsole:

 

$ emctl stop dbconsole

2. Efetuar um backup(copia) do arquivo emoms.properties localizado no diretório $ORACLE_HOME//sysman/config e abrir o arquivo original(emoms.properties) com um editor adicionando ao final do arquivo a seguinte linha:

oracle.sysman.eml.maxInactiveTime=tempo em minutos

3. Atualizar o arquivo web.xml abaixo do diretorio 

$ORACLE_HOME/oc4j/j2ee/oc4j_applications/applications/em/em/WEB-INF com:

<session-config><session-timeout>-1</session-timeout></session-config>

onde o -1 indica que não existe timeout. Qualquer valor positivo indica o tempo de inatividade antes da sessão ser desconectada. 

4. Reiniciar o database console:

$ emctl start dbconsole

Referências:

12c Cloud Control: How to Change the Default Login (Idle) Timeout Value for the Enterprise Manager Cloud Console Connections? (Doc ID 1385996.1) 

How to Change the Default Session Timeout for Database Control/DB Control ? (Doc ID 1170373.1) 

How to Change the Default Login Timeout Value for the 10g/11g Enterprise Manager Grid Console Connections? (Doc ID 234875.1) 

http://docs.oracle.com/cd/E24628_01/install.121/e24089/addnl_tasks.htm#EMADV570

Mais informações →

Enterprise Manager Database Express – 12c

Juntamente com o Oracle Database 12c, a Oracle introduziu um novo console de administração chamado Oracle Enterprise Manager Express (EM Express). O EM Express pode ser considerado como uma versão “ligth” do antigo Enterprise Manager Database control que já não é mais disponibilizado na versão 12c. Agora para gerenciar os bancos de dados 12c (cdb ou non-cdb) você pode utilizar o EM Cloud control 12c ou EM database Express.

O Oracle Enterprise Manager Express é uma ferramenta de gerenciamento de banco de dados baseado na web que é construído dentro do banco de dados Oracle. Ele suporta funções básicas de administração de banco de dados e gerenciamento de desempenho.

Configuração:

• Gerenciamento dos parâmetros de inicialização (init.ora) 
• Gerenciamento de memória 
• Uso das features do banco de dados 
• Propriedades de Banco de Dados 

Armazenamento:

• Gerenciamento de Tablespace 
• Gerenciamento de Undo 
• Gerenciamento de Redo 
• Gerenciamento de Archive log 
• Gerenciamento de Control file 

Performance:

• Hub de desempenho, que inclui os seguintes recursos: 
• Monitoramento de desempenho e tuning em tempo real 
• Histórico de desempenho e tuning 
• Monitoramento de SQL (tempo real e histórico) 
• Monitoramento de operações de banco de dados 
• ADDM, incluindo ADDM em Tempo Real 
• Active Session History (ASH) 
• SQL Tuning Advisor, automático e manual 

Sua “instalação” diferentemente do que ocorria nas versões anteriores se tornou muito simples. Na verdade não há nenhuma instalação! Quando o database é criado é possível selecionar a opção Configurar EM (Enterprise Manager) Database Express que já deixa tudo ajustado para o acesso via web.

Para iniciar o EM Express utilize a URL informada durante o processo de configuração do Database via DBCA (Database Configuration Assistant) ou então utlize o pacote dbms_xdb_config para identificar a porta do EM Express.

SQL> select dbms_xdb_config.gethttpsport() from dual;
 
DBMS_XDB_CONFIG.GETHTTPSPORT()
------------------------------
                          5500

Agora basta acessar a URL:

https://database-hostname:portnumber/em/

Exemplo:

https://note-anderson:5500/em

Caso o EM Express não tenha sido configurado durante a criação do database, não seja exibido nenhuma porta pelo dbms_xdb_config.gethttpsport ou você necessita alterar a porta default, utilize o dbms_xdb_config.sethttpsport

Primeiro verifique se o parâmetro dispatchers está habilitado:

SQL> show parameter dispatchers
 
NAME                 TYPE        VALUE
-------------------- ----------- ---------------------------------
dispatchers          string      (PROTOCOL=TCP) (SERVICE=homolXDB)

Se não estiver habilitado, habilite e reinicie o database:

dispatchers=”(PROTOCOL=TCP)(SERVICE=<sid>XDB)”

Agora utilize o dbms_xdb_config.sethttpsport para setar uma porta para o EM Express:

SQL> select dbms_xdb_config.gethttpsport() from dual;
 
DBMS_XDB_CONFIG.GETHTTPSPORT()
------------------------------
 
SQL> exec DBMS_XDB_CONFIG.SETHTTPSPORT(5500);
 
Procedimento PL/SQL concluido com sucesso.
 
SQL> select dbms_xdb_config.gethttpsport() from dual;
 
DBMS_XDB_CONFIG.GETHTTPSPORT()
------------------------------
                          5500

Pronto! Agora é só acessar o Enterprise Manager Database Express

Permissão de acesso ao EM Express para usuário não-administrativos:

Como administrador, você pode logar no EM Express utilizando as constas SYS e SYSTEM para executar as operações administrativas e outras tarefas necessárias. Para logar no EM com um usuário não-administrativo é necessário conceder uma das seguintes roles:

EM_EXPRESS_BASIC: Permite que o usuário conecte no EM Express e visualize as paginas em modo read-only(apenas leitura). A role EM_EXPRESS_BASIC inclui a role SELECT_CATALOG_ROLE.

EM_EXPRESS_ALL: Permite que o usuário conecte no EM Epress e utilize de todas as funcionalidades providas pelo EM Express (read/write). A role EM_EXPRESS_ALL contém a EM_EXPRESS_BASIC.

Referência:

http://docs.oracle.com/cd/E16655_01/server.121/e17643/em_manage.htm#BABCGBJF

Mais informações →

Oracle database 12c – Iniciando e parando Pluggable Databases (PDB)

Na verão Oracle database 12c tivemos o surgimento da Arquitetura Multitenant onde permite que o banco de dados funcione como um container – CDB(Container Database) e que inclua zero ou muitos bancos de dados plugáveis – PDB(Pluggable Database).

Neste novo cenário de CDB e PDB, o startup/shutdown de um banco de dados plugável pode ser feito de algumas formas diferentes do que estamos acostumados. O objetivo deste artigo é justamente demonstrar algumas destas formas de parar, iniciar e verificar o estado desdes pluggable databases.

Abrindo uma conexão com o CDB (no meu caso criado como ORCL):

C:>sqlplus sys@ORCL as sysdba
 
SQL*Plus: Release 12.1.0.1.0 Production on Tue Ago 13 15:56:07 2013
 
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
 
Informe a senha:
 
Conectado a:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
 
SQL> show con_name
 
CON_NAME
------------------------------
CDB$ROOT

Observe que quando executo o comando “show con_name” para visualizar o container que estou conectado ele apresenta CDB$ROOT.

O CDB$ROOT é o recipiente raiz do banco de dados, nele é armazenado todos os metadados e usuários comuns. Um usuário comum é um usuário do banco de dados conhecido em cada recipiente.
Conectado no meu container(CDB) vou verificar o status de todos os pluggable databases utilizando a visão V$PDBS.

SQL> set lines 190
SQL> col open_time for a30
SQL> select name,
  2         open_mode,
  3         to_char(open_time,'dd/mm/yyyy hh24:mi:ss') open_time
  4    from v$pdbs
  5  /
 
NAME                           OPEN_MODE  OPEN_TIME
------------------------------ ---------- ------------------------------
PDB$SEED                       READ ONLY  13/08/2013 15:58:34
TESTE1                         MOUNTED    13/08/2013 16:38:47
TESTE2                         MOUNTED    13/08/2013 16:25:17

Na coluna NAME temos o nome de cada PDB.

Na coluna OPEN_MODE é exibido o estado do PDB. Quando um PDB esta fechado(closed) seu estado é MOUNTED. Um PDB pode ser aberto com as seguintes condições: READ WRITE, READ ONLY ou MIGRATE.

A coluna OPEN_TIME mostra o ultimo dia e horário em que o plugabble database estava aberto.

NOTA: O pluggable database PDB$SEED é um template que o CDB utiliza para criar novos PDBs. Nele não podemos adicionar ou modificar nenhum objeto.

 Mudando o estado dos PDB através do comando ALTER PLUGGABLE DATABASE:

--Abrindo em read write
SQL> alter pluggable database teste1 open;
 
Banco de dados plugável alterado.
 
--Abrindo em read only
SQL> alter pluggable database teste2 open read only;
 
Banco de dados plugável alterado.
 
Verificando novamente o estado dos PDBs. Observe que a coluna OPEN_TIME também foi alterada!
 
SQL> select name,
  2         open_mode,
  3         to_char(open_time,'dd/mm/yyyy hh24:mi:ss') open_time
  4    from v$pdbs
  5  /
 
NAME                           OPEN_MODE  OPEN_TIME
------------------------------ ---------- ------------------------------
PDB$SEED                       READ ONLY  13/08/2013 15:58:34
TESTE1                         READ WRITE 13/08/2013 16:44:48
TESTE2                         READ ONLY  13/08/2013 16:45:04
 
--Fechando um pdb
SQL> alter pluggable database teste1 close immediate;
 
Banco de dados plugável alterado.
 
SQL> select name,
  2         open_mode,
  3         to_char(open_time,'dd/mm/yyyy hh24:mi:ss') open_time
  4    from v$pdbs
  5  /
 
NAME                           OPEN_MODE  OPEN_TIME
------------------------------ ---------- ------------------------------
PDB$SEED                       READ ONLY  13/08/2013 15:58:34
TESTE1                         MOUNTED    13/08/2013 16:46:18
TESTE2                         READ ONLY  13/08/2013 16:45:04

A palavra IMMEDIATE especificada depois do CLOSE significa que a base será fechada imediatamente, semelhante ao comando shutdown immediate. Caso o immediate seja omitido do comando o banco de dados é fechado de forma normal(shutdown).

Outro método para iniciar e parar um PDB é conectando no mesmo e emitindo os comandos startup e shutdown já conhecidos.

--conectando na teste2
SQL> alter session set container=teste2;
 
Sessão alterada.
 
SQL> show con_name
 
CON_NAME
------------------------------
TESTE2
SQL> shutdown immediate;
Banco de Dados plugável Fechado.
 
--conectando na teste1
SQL> alter session set container=teste1;
 
Sessão alterada.
 
SQL> show con_name
 
CON_NAME
------------------------------
TESTE1
SQL> startup
Banco de Dados plugável aberto.
 
--conectando no recipiente raiz
SQL> alter session set container=cdb$root;
 
Sessão alterada.
 
SQL> show con_name
 
CON_NAME
------------------------------
CDB$ROOT
SQL> select name,
  2         open_mode,
  3         to_char(open_time,'dd/mm/yyyy hh24:mi:ss') open_time
  4    from v$pdbs
  5  /
 
NAME                           OPEN_MODE  OPEN_TIME
------------------------------ ---------- -------------------
PDB$SEED                       READ ONLY  13/08/2013 15:58:34
TESTE1                         READ WRITE 13/08/2013 16:51:11
TESTE2                         MOUNTED    13/08/2013 16:48:37

Imagine agora que você tem 100 PDBs. Certamente seria muito trabalhoso executar 100x o mesmo comando ALTER PDB ou conectar em todos os PDBs para poder iniciar e parar cada um deles. Então, como fazemos?

Uma das soluções é especificar o nome dos PDBs desejados no mesmo comando:

SQL> alter pluggable database teste1, teste2 open;
 
Banco de dados plugável alterado.

Mas ainda seria trabalhoso.. Então para facilitar ainda mais temos as mágicas palavras:

ALL: Para alterar o estado de “todos” os PDBs (O PDB$SEED não é afetado!);
ALL EXCEPT: Para alterar o estado dos PDBs exeto do PDB especificado.

SQL> alter pluggable database all close immediate;
 
Banco de dados plugável alterado.
 
SQL> select name,
  2         open_mode,
  3         to_char(open_time,'dd/mm/yyyy hh24:mi:ss') open_time
  4    from v$pdbs
  5  /
 
NAME                           OPEN_MODE  OPEN_TIME
------------------------------ ---------- -------------------
PDB$SEED                       READ ONLY  13/08/2013 15:58:34
TESTE1                         MOUNTED    13/08/2013 16:53:31
TESTE2                         MOUNTED    13/08/2013 16:48:37
 
SQL> alter pluggable database all open;
 
Banco de dados plugável alterado.
 
SQL> select name,
  2         open_mode,
  3         to_char(open_time,'dd/mm/yyyy hh24:mi:ss') open_time
  4    from v$pdbs
  5  /
 
NAME                           OPEN_MODE  OPEN_TIME
------------------------------ ---------- -------------------
PDB$SEED                       READ ONLY  13/08/2013 15:58:34
TESTE1                         READ WRITE 13/08/2013 16:54:18
TESTE2                         READ WRITE 13/08/2013 16:54:18
 
SQL> alter pluggable database all except teste1 close immediate;
 
Banco de dados plugável alterado.
 
SQL> select name,
  2         open_mode,
  3         to_char(open_time,'dd/mm/yyyy hh24:mi:ss') open_time
  4    from v$pdbs
  5  /
 
NAME                           OPEN_MODE  OPEN_TIME
------------------------------ ---------- -------------------
PDB$SEED                       READ ONLY  13/08/2013 15:58:34
TESTE1                         READ WRITE 13/08/2013 16:54:18
TESTE2                         MOUNTED    13/08/2013 16:56:20

Para finalizar, ainda podemos iniciar/parar um PDB das seguintes formas:

SQL> startup pluggable database teste2;
Banco de Dados plugável aberto.
 
SQL> exit
Desconectado de Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
 
C:>sqlplus sys@TESTE2 as sysdba
 
SQL*Plus: Release 12.1.0.1.0 Production on Tue Ago 13 17:00:09 2013
 
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
 
Informe a senha:
 
Conectado a:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
 
SQL> shutdown immediate;
Banco de Dados plugável Fechado.

Referências:

http://docs.oracle.com/cd/E16655_01/server.121/e17633/cdbovrvw.htm http://docs.oracle.com/cd/E16655_01/server.121/e17615/refrn30652.htm http://docs.oracle.com/cd/E16655_01/server.121/e17209/statements_2007.htm

Mais informações →

Alterando parâmetros de outra sessão

Muitas aplicações que conectam no banco de dados funcionam de formas diferentes, com regras diferentes e necessidades diferentes. Desta forma, varias vezes tornasse necessário ajustar parâmetros específicos (dinâmicos) para os usuários da aplicação que conectam no banco de dados, visando melhorar a performance, segurança e atender necessidades distintas.

Uma solução simples e que normalmente é adotada para estes cenários é criar triggers de logon, onde se o usuário for X o parâmetro da sessão é Y, caso contrario utiliza-se os padrões da instance.

Mas e quando precisamos alterar os parâmetros de um sessão (usuário) já aberta pela aplicação? Também é possível! Basta utilizarmos a package DBMS_SYSTEM.

A DBMS_SYSTEM é um pacote que permite coletar informações sobre os eventos da sessão atual e manipular as sessões dos demais usuários para definir eventos e alterar os valores de determinados parâmetros. Ela fornece algumas das capacidades da DBMS_SESSION mas com a capacidade de afetar qualquer sessão.

Vejamos um exemplo prático.

Primeiramente vou abrir uma sessão com meu usuário (ANDERSON). Supondo que ela foi aberta através de uma aplicação, digamos simplesmente que não consigo alterar os parâmetros.. “alter session set …” ou que ela esta em meio a varias operações e não pode ser finalizada sendo que o parâmetro X ou Y necessita ser alterado.

c0825:oracle:c0828sta> sqlplus anderson
 
SQL*Plus: Release 10.2.0.5.0 - Production on Mon Jul 8 14:25:07 2013
 
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.
 
Enter password:
 
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, Data Mining and Real Application Testing options
 
SQL>

Agora abrindo uma sessão como SYSDBA, vamos ver se meu usuário possui algum parâmetro diferente dos parâmetros estabelecidos na instance. Eles poderiam ter sido alterados por uma trigger de logon, por exemplo.

c0825:oracle:c0828sta> sqlplus / as sysdba
 
SQL*Plus: Release 10.2.0.5.0 - Production on Mon Jul 8 14:29:36 2013
 
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.
 
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, Data Mining and Real Application Testing options
 
SQL> set lines 200
SQL> col name for a40
SQL> col username for a10
SQL> col value for a15
SQL> select a.sid, c.username, a.name, a.value
      from v$ses_optimizer_env a
      join v$sys_optimizer_env b on a.id = b.id
      join v$session c on a.sid = c.sid
     where a.value <> b.value
       and c.username is not null
          --and c.username not in ('SYS','SYSTEM','DBSNMP')
       and c.username = 'ANDERSON'
     order by a.sid, a.name;
 
no rows selected

Nenhum parâmetro diferente dos parâmetros do sistema! Agora através desta minha sessão (SYS) vou alterar um parâmetro da outra sessão (ANDERSON). Para fazer isto vou utilizar o pacote DBMS_SYSTEM, porém tenho 2 subprogramas(procedures): SET_INT_PARAM_IN_SESSION = Utilizado para alterar parâmetros com valores numéricos(inteiros) em outra sessão.

DBMS_SYSTEM.SET_INT_PARAM_IN_SESSION (
   sid       IN  NUMBER,
   serial#   IN  NUMBER,
   parnam    IN  VARCHAR2,
   intval    IN  BINARY_INTEGER);

SET_BOOL_PARAM_IN_SESSION = Utilizado para alterar parâmetros boolean(TRUE,FALSE) em outra sessão.

DBMS_SYSTEM.SET_BOOL_PARAM_IN_SESSION (
   sid       IN  NUMBER,
   serial#   IN  NUMBER,
   parnam    IN  VARCHAR2,
   bval      IN  BOOLEAN);

SQL> show user
USER is "SYS"
SQL> select sid, serial# from
  2  v$session
  3  where username='ANDERSON';
 
       SID    SERIAL#
---------- ----------
       293       8786
 
SQL> exec sys.dbms_system.set_int_param_in_session(293,8786,'optimizer_index_cost_adj',50);
 
PL/SQL procedure successfully completed.

Voltamos para a sessão “ANDERSON” e executamos um select from dual apenas para registrar a mudança do parâmetro.

SQL> show user
USER is "ANDERSON"
SQL> select 1 from dual;
 
         1
----------
         1

Vejamos agora se a sessão “ANDERSON” possui algum parâmetro diferente:

SQL> show user
USER is "SYS"
SQL> select a.sid, c.username, a.name, a.value
  2    from v$ses_optimizer_env a
  3    join v$sys_optimizer_env b on a.id = b.id
  4    join v$session c on a.sid = c.sid
  5   where a.value <> b.value
  6     and c.username is not null
  7        --and c.username not in ('SYS','SYSTEM','DBSNMP')
  8     and c.username = 'ANDERSON'
  9   order by a.sid, a.name;
 
       SID USERNAME   NAME                                     VALUE
---------- ---------- ---------------------------------------- ---------------
       293 ANDERSON   optimizer_index_cost_adj                 50

Vamos fazer outro teste:

-- Verificando usuário/criando uma tabela
SQL> show user
USER is "ANDERSON"
SQL> create table teste(
  2  cod number);
 
Table created.
 
-- Criando um indice sobre a tabela criada
SQL> create index teste_idx1 on teste(cod);
 
Index created.
 
-- Inserindo um registro
SQL> insert into teste values (1);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
-- Invalidando o indice
SQL> alter index teste_idx1 unusable;
 
Index altered.
 
-- Verificando o status do indice
SQL> select index_name,
  2  status
  3  from user_indexes
  4  where index_name='TESTE_IDX1';
 
INDEX_NAME                     STATUS
------------------------------ --------
TESTE_IDX1                     UNUSABLE
 
-- Consulta
SQL> select * from teste where cod=1;
 
       COD
----------
         1

Porque a consulta não retornou erro se o índice esta inválido? Pelo fato do parâmetro SKIP_UNUSABLE_INDEXES estar setado para TRUE, desta forma os índices inválidos(UNUSABLE) são ignorados. Agora vamos alterar o parâmetro boolean SKIP_UNUSABLE_INDEXES na sessão “ANDERSON” para FALSE:

SQL> show user
USER is "SYS"
SQL> show parameter skip_unusable_indexes
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
skip_unusable_indexes                boolean     TRUE
 
SQL> exec sys.dbms_system.set_bool_param_in_session(293,8786,'skip_unusable_indexes',false);
 
PL/SQL procedure successfully completed.
 
SQL> select a.sid, c.username, a.name, a.value
      from v$ses_optimizer_env a
      join v$sys_optimizer_env b on a.id = b.id
      join v$session c on a.sid = c.sid
     where a.value <> b.value
       and c.username is not null
          --and c.username not in ('SYS','SYSTEM','DBSNMP')
       and c.username = 'ANDERSON'
     order by a.sid, a.name;
 
         SID USERNAME   NAME                                     VALUE
---------- ---------- ---------------------------------------- ---------------
       293 ANDERSON   optimizer_index_cost_adj                 50

Observe que o parâmetro SKIP_UNUSABLE_INDEXES = FALSE ainda não foi validado (ATIVADO) na sessão “ANDERSON”. Vamos agora executar a mesma consulta anterior:

SQL> show user
USER is "ANDERSON"
SQL> select * from teste where cod=1;
select * from teste where cod=1
*
ERROR at line 1:
ORA-01502: index 'ANDERSON.TESTE_IDX1' or partition of such index is in unusable state

Observe que agora tivemos erro na consulta apontando que o índice TESTE_IDX1 esta inválido. Vejamos os parâmetros alterados da sessão “ANDERSON”:

SQL> show user
USER is "SYS"
SQL> select a.sid, c.username, a.name, a.value
      from v$ses_optimizer_env a
      join v$sys_optimizer_env b on a.id = b.id
      join v$session c on a.sid = c.sid
     where a.value <> b.value
       and c.username is not null
          --and c.username not in ('SYS','SYSTEM','DBSNMP')
       and c.username = 'ANDERSON'
     order by a.sid, a.name;
 
         SID USERNAME   NAME                                     VALUE
---------- ---------- ---------------------------------------- ---------------
       293 ANDERSON   optimizer_index_cost_adj                 50
       293 ANDERSON   skip_unusable_indexes                    false

Fique atento!: Para esta procedure não funciona para o parâmetro SQL_TRACE!

Mais informações →