Note the changed disk controller numbers in the below image
txkrun.pl -script=SetSSOReg -deregister=Yes
FUNCTION: TXK::advconfig::SSO::validateParams [ Level 1 ]ERRORMSG: Invalid ORASSO database user credentials.Connecting to ORASSO schema using dbhost.mycompany.com:1521:OIDDB failed.
The ORASSO password was correct. So the above error has nothing to do with the password. Upon further investigation, I found out the script is unable to establish the SSO database connection. Because the database has been converted to RAC, the current SID OIDDB is not applicable anymore. During the RAC conversion, a new SID has been generated for each of the two instances in the RAC viz. OIDDB1 and OIDDB2 respectively. The service name is still the same OIDDB, but Oracle is trying to establish a connection using OIDDB as a SID, resulting in the above error.
More often that not, Oracle utility scripts show the input arguments so we can choose the right argument for the database connection string and pass it to the script. However, txkrun.pl does not seem to be good at it. txkrun.pl -help too does not provide the input argument list. The only way to find the txkrun.pl input arguments is to check its failed logfile in $COMMON_TOP/rgf/$CONTEXT_NAME/sso/txkSetSSOReg*.log file ( infraconnstr )
txkrun.pl -script=SetSSOReg -deregister=Yes -infraconnstr="(Description =(ADDRESS_LIST =(LOAD_BALANCE = yes)(ADDRESS = (PROTOCOL = TCP)(HOST = node1-vip)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = node2-vip)(PORT = 1521)))(CONNECT_DATA =(SERVICE_NAME = OIDDB)))"
I hope txkrun.pl provides a better way to find its input argument list in the future. This can be an enhancement request for Oracle. Moreover, the script should prompt for the service name instead of the database SID currently (Enter the Oracle iAS Infrastructure database SID ? ) if one does not intput the infraconnstr argument. Service name is a much better way of referencing a database instead of a SID, because the former remains constant across RAC conversions, not the latter.
The SSO Administration Guide mentions that running ssooconf.sql alone is enough to recognize the new OID server. However, as mentioned above, the SSO server does not seem to read the change from the database, but instead from its configuration files to get this working.