OHUC-1026 changing home password

In the new Oracle 12c, there is a new security feature – the oracle home user and password. I managed to forget it, and DBCA asks for it when I create a new instance.

Changing it is pretty simple – all you need to do is type the following:

orahomeuserctl updpwd -user <name>

However, I got the below:

Enter new Password:
OHUC-1026 : unable to authenticate the new password

 

The solution is simple – you need to make sure that ORACLE_HOME and PATH are properly set. The former should be the path to 12c and the latter should begin with the path to the 12c binaries.

Separating entries by characterset

We recently had an issue with a column containing data both in Hebrew and English. The request was to separate English records.

The solution was quite simple – an English string converted to English is equal to itself. The one in Hebrew isn’t, so:

SELECT firstname, lastname FROM accounts
WHERE CONVERT(firstname,’AL32UTF8′,’US7ASCII’)=firstname

Listener not starting with TNS-00525: Insufficient privilege for operation

I recently got a listener that refused to start on AIX. The message it returned was:

Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC0)))
TNS-12555: TNS: Permission denied
TNS-12560: TNS: Protocol adapter error
TNS-00525: Insufficient privilege for operation
IBM/AIX RISC System/6000 Error: 1: Not owner

Checking the binaries and config files revealed nothing suspect – all were owned by Oracle. So I decided to try a truss:

truss -aefo result.txt lsnrctl start

Somewhere in the file I got my answer:

1785960: 1511613: access(“/tmp/.oracle/sEXTPROC0”, 0)   = 0
1785960: 1511613: connext(3, 0x0FFFFFFFFFFF77A0, 106)   Err#79 ECONNREFUSED
1785960: 1511613: access(“/tmp/.oracle/sEXTPROC0”, 0)   = 0
1785960: 1511613: _poll(0x0000000000000000, 0, 100)     = 0
1785960: 1511613: close(3)                              = 0
1785960: 1511613: socket(1, 1, 0)                       = 3
1785960: 1511613: connext(3, 0x0FFFFFFFFFFF77A0, 106)   Err#79 ECONNREFUSED
1785960: 1511613: access(“/tmp/.oracle/sEXTPROC0”, 0)   = 0

I checked in /tmp/.oracle/ and some files were owned by root (apparently someone tried to start the listener as root):

srwxrwxrwx  1 oracle dba    0 2011-05-27 16:46 s#200950.1
srwxrwxrwx  1 root   system 0 2011-06-29 10:25 sEXTPROC0
srwxrwxrwx  1 root   system 0 2011-06-29 10:25 s#1642742.1

I removed  the two files and was able to start the listener.

Trailing backslash causes OEM to malfunction

After reconfiguring OEM on a machine, I was able to log in, but the page displayed:

java.lang.Exception: Exception in sending Request :: null

and the rest of data was unavailable. Logs showed a “no data found” exception, among others. This is usually due to an incorrect timezone setting. In my case, the timezone was properly set.

The solution was very simple – change ORACLE_HOME from i.e. “d:\oracle\product\10.2.0\db_1\” to “d:\oracle\product\10.2.0\db_1”. The trailing backslash caused the entire problem.

JDBC takes forever to login

JDBC applications trying to connect to an 11g database appear to freeze. No error message appears and truss/strace reveals a never-ending FUTEX call:

futex(0x4152f9d0, FUTEX_WAIT, 16502, NULL) = -1 EINTR (Interrupted system call)
futex(0x4193b9d0, FUTEX_WAIT, 16368, NULL <unfinished … exit status 129>

The root cause was the fact that the JDBC 11g needs about 40 bytes of secure random numbers (see here), gathered from /dev/random, to encrypt its connect string. But the documentation states that:

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

The workaround is to use /dev/urandom instead, by adding the below directive:

Djava.security.egd=file:///dev/urandom

Instance unavailable

Yesterday while trying to revive an unresponsive OEM (via emca -configure dbcontrol db -repos create) I got the following:

SEVERE: Database instance unavailable.

Obviously the instance was up and the environment parameters were properly set. The actual issue was that there was no password file so it was impossible to authenticate as SYSDBA remotely. After creating the password file it worked like a charm.