Simon Krenger

Alright, so when we need to recreate a database link for some reason and we do not happen to have the password handy, we’re usually stuck. However, sometimes there is a way to recover passwords for database links.

The method described below only works for the “old” password versions (<= 11.2.0.2)!

Starting with Oracle 11.2.0.2, Oracle salts the password hashes, therefore you will need to crack the password and cannot just query it. However, if the database link was created pre-11.2.0.2, the password is saved in an “old” format without the salt. To check if there are any database links with this old format, query SYS.LINK$ like so:

As of PSU 12.1.0.2, Oracle introduced “PDB State Management Across CDB Restart”, which will automatically put a pluggable database in a previously defined state on database startup. To show the current saved state of the PDBs, you can query the documented view cdb_pdb_saved_states:

SQL> SELECT con_name, instance_name, state FROM cdb_pdb_saved_states;

CON_NAME		       INSTANCE_NAME		      STATE
------------------------------ ------------------------------ --------------
P1			       cdb2			      OPEN
P2			       cdb2			      OPEN

But beware: When you unplug and plug in the database, this saved state will be lost.

I think this is one of the more awesome improvements in 12.1.0.2, since the original startup trigger was more of a workaround than a real solution.

So often when issuing a emctl (Enterprise Manager Command Line Utility) command, one needs to specify a target type. This is often the case when the command affects a certain target (for example emctl reload agent dynamicproperties ...).

The most often used target types are the following:

• oracle_database (Oracle Instance)
• oracle_emd (Agent)
• host (Host Machine)

However, there are a lot of other target types available. We can get all available target types for Oracle Enterprise Manager Cloud Control 12c if we query the SYSMAN.EM_TARGET_TYPES table in the Enterprise manager repository:

So today, during the upgrade of a database, all other databases using the same ORACLE_HOME stopped dead in their tracks. The ALERT log reported the following:

2014-09-30 13:34:41.622000 +02:00
Archived Log entry 24398 added for thread 1 sequence 24398 ID 0x2d91d796 dest 1:
2014-09-30 13:47:39.764000 +02:00
Errors in file /u00/app/oracle/diag/rdbms/kdb12345/kdb12345/trace/kdb12345_psp0_57147560.trc:
ORA-07274: spdcr: access error, access to oracle denied.
IBM AIX RISC System/6000 Error: 2: No such file or directory
PSP0 (ospid: 57147560): terminating the instance due to error 7274
2014-09-30 13:47:41.346000 +02:00
System state dump requested by (instance=1, osid=57147560 (PSP0)), summary=[abnormal instance termination].
System State dumped to trace file /u00/app/oracle/diag/rdbms/kdb12345/KDB12345/trace/KDB12345_diag_49938448_20140930134741.trc
2014-09-30 13:47:44.779000 +02:00
Instance terminated by PSP0, pid = 57147560

Hmm, so what to do? In the trace file, we find out a bit more:

When working with the new multitenant architecture of Oracle 12c, one is often confronted with questions like “Ok, is this or that possible in the pluggable database? And where is that value stored?”. In this article, I want to show you where the parameters of the pluggable databases are stored. Hint: there is no SPFILE for a pluggable database!

Consider the following container database (CDB), named “cdb2”, with the following pluggable databases (PDBs). Using SQL*Plus, connected to the CDB, we can issue show pdbs to get a list of the PDBs and their status:

As we are migrating the last databases from Oracle 10gR2 to the latest 11.2.0.4 release, there are some errors that we stumbled upon along our way. For example, when we tried to upgrade one particular database, during the upgrade the following error was thrown:

SQL> SELECT TO_NUMBER('DATA_VAULT_OPTION_ON') FROM v$option
  2   WHERE
  3    value = 'TRUE' and parameter = 'Oracle Database Vault';
SELECT TO_NUMBER('DATA_VAULT_OPTION_ON') FROM v$option
                 *
ERROR at line 1:
ORA-01722: invalid number

Ouch. That is something that you do not want to see during an upgrade! Needless to say, the upgrade won’t continue here, so how to fix this?

Well, basically this is a well-known error, and there is MOS note 1409844.1 that describes how to fix the problem: Catupgrd Returns : Ora-01722 Select To_number(‘DATA_VAULT_OPTION_ON’) From V$option

To connect to a PDB, you have to use the service name of the pluggable database. But what when there is an older legacy application that can only use an SID to connect to a database? And what if we just migrated an older legacy database to a PDB? When starting the application, you might see something like:

ORA-12505: TNS:listener does not currently know of SID given in connect descriptor

There is a parameter called USE_SID_AS_SERVICE_listener that can be used to tell the listener to handle SIDs like service names. So the listener will interpret the SID given in the connection as a service name and will then connect you to the database.

Before starting, here is the deal: While “ALTER USER simon PASSWORD EXPIRE” exists, the “PASSWORD UNEXPIRE” statement does not exist in Oracle, see the ALTER USER statement in the language reference. Now, there is a good reason that command does not exist.

One problem that occasionally pops up is that a DBA needs to recreate a user with a password that he does not know. This happened to me when I had to create a schema with the same password on a development database. After I set an initial password for the developer, he exclaimed that he wanted the same password that he had for the schema X, but he did not want to tell me the password (don’t ask here, that’s a completely other story).

One way to do this is to use ALTER USER ... IDENTIFIED BY VALUES. Using the excellent article on the ALTER USER commands from Laurent Schneider, we can generate a dynamic SQL query to set a password without knowing the password itself!

Here is the query to read the password from sys.user$ from Laurents article:

One thing that you don’t want to see while performing an update of a database with the OPatch utility is a SEGFAULT. In my scenario, I simply wanted to list all the installed patches for an ORACLE_HOME and therefore issued opatch lsinventory:

$ cd $ORACLE_HOME/OPatch
$ ./opatch lsinventory
Oracle Interim Patch Installer version 11.1.0.10.1
Copyright (c) 2013, Oracle Corporation.  All rights reserved.

Unhandled exception
Type=Segmentation error vmState=0x00060000
[..]