Here is the compilation of known 12c database issues with EBS. Hope it helps
The database was recently upgraded from 11g to 12c, and when trying to register database to sso using: $FND_TOP/bin/txkrun.pl the following error is received:
‘ORA-28040: No matching authentication protocol’
Resolution:To resolve the issue test the following steps in a development instance and then migrate accordingly:
- Copy ojdbc6.jar and orai18n.jar into the $IAS_ORACLE_HOME/jdbc/lib
- Make a backup of $HOME/apps/apps_st/appl/fnd/12.0.0/patch/115/bin/txkSetSSOReg.pl by copying the file to txtSetSSOReg.pl-bk1
- Update the $HOME/apps/apps_st/appl/fnd/12.0.0/patch/115/bin/txkSetSSOReg.pl to use ojdbc6.jar instead of ojdbc14.jar
- Retest the script execution, txkrun.pl
Issue 2: Script perl /product/220.127.116.11/appsutil/bin/adbldxml.pl fails when generating the Database Context File with the following errors:
‘Can’t locate Config.pm in @INC (@INC contains: /ebs/db/11.2.0/perl/lib/5.8.3 /ebs/db/11.2.0/perl/lib/site_perl/5.8.3 /ebs/db/11.2.0/appsutil/perl ../lib/site_perl/5.14.1/sun4-solaris-thread-multi-64 ../lib/site_perl/5.14.1 ../lib/5.14.1/sun4-solaris-thread-multi-64 ../lib/5.14.1 .) at /ebs/ebs/product/18.104.22.168/appsutil/bin/adbldxml.pl line 32.
BEGIN failed–compilation aborted at /ebs/ebs12c/product/22.214.171.124/appsutil/bin/adbldxml.pl line 32.
The issue occurs during a database upgrade to 12c referencing the following document:
Perl library location was referring to wrong version and path.
The existing perl version was referring to lower version, which adbldxml.pl is not able to locate as a new version is required.
To resolve the issue test the following steps in a development instance and then migrate accordingly:
- For an instance with 12c Database, the perl version on the Database tier required is ‘5.14’.
If the current perl version on the system is not 5.14 or greater (eg. 5.14.1) download the correct version of perl.
Set the variable ‘PERL5LIB’ on the 12c database tier to to following:
Retest the context file creation via adbldxml.pl and confirm the error is resolved.
Issue 3 : You may get the below ORA error in many cases while using 12c database
‘ORA-28040: No matching authentication protocol’
If you are on E-Business Suite Release 12.0, ensure that your sqlnet_ifile.ora has the line:
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8
If you are on E-Business Suite Release 12.1, ensure that your sqlnet_ifile.ora has the line:
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8 (if the initialization parameter SEC_CASE_SENSITIVE_LOGON is set to FALSE)
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 10 (if SEC_CASE_SENSITIVE_LOGON is set to TRUE)
TNS-12537: TNS:connection closed
TNS-12560: TNS:protocol adapter error
TNS-00507: Connection closed
Solaris Error: 29: Illegal seek
Add the below parameter in listener.ora
Issue 5 Database links may give tns errors after upgrading to 12c
Make sure you copied all the tns entries for the database link to work
Issue 6 sqlplus “/ as sysdba”
SP2-1503: Unable to initialize Oracle call interface
SP2-0152: ORACLE may not be functioning properly
The following ORACLE error:
ORA-28000: the account is locked
occurred while executing the SQL statement:
Unable to connect to ‘SYSTEM’; password may be invalid.
AutoPatch needs the password for your ‘SYSTEM’ ORACLE schema
in order to determine your installation configuration.
Account was locked .Unlock the system account
After database upgrade to 126.96.36.199, ” AR XLAACCUP module: Accounting Program ” concurrent job failed very quick with error:
An internal error occurred. Please inform your system administrator or support representative that:
An internal error has occurred in the program xla_ae_lines_pkg.AccountingReversal. ORA-01555: snapshot too old: rollback segment number 28
The fix is EBS patch 19591608 or workaround
set temp_undo_enabled = FALSE
Oracle 12c introduces a new default feature of using multiple LGWRs which may lead to DEADLOCK / Database Hang or ORA-742 “Log read detects lost write” or ORA-600 [kcrfrgv_nextlwn_scn] during instance OPEN or ORA-600 [krr_process_read_error_2] during Recovery on IBM AIX and potentially on HPUX Itanium 64bit.
The database may become unusable and fail to be OPEN.
This issue is specific to RDBMS version 12c (188.8.131.52 or 184.108.40.206) where the new default feature of using multiple LGWRs is introduced.
It affects databases on IBM AIX and potentially on HPUX Itanium 64bit
Disable the new feature of multiple LGWR slave processes by proactively setting _use_single_log_writer=true.
Setting _use_single_log_writer = true is a safe workaround; it is the behavior before 12c where multiple LGWR slave groups were not available.
ALTER SYSTEM SET “_use_single_log_writer”=TRUE SID=’*’ SCOPE=SPFILE;
— Restart the database or all instances of the RAC database
Note that while _use_single_log_writer=true is not set, then error ORA-600 [kcrfrgv_nextlwn_scn] might be produced avoiding the database to OPEN. Once the problem is introduced, _use_single_log_writer=true may not fix it. _use_single_log_writer = true prevents inconsistencies in the redo log to be introduced which causes that error.
If the parameter does not help, because the problem was already introduced when _use_single_log_writer=true had not been proactively set, then Point in Time Recovery (PITR) or Flashback Database are the options to recover from this situation.