The log file for request (XXXXX) is empty (0 bytes). The concurrent manager may have encountered an error while attempting to create this file.

Hi,

One of our customer facing issue in running a concurrent program which completed error and trouble opening output file of it and following pop-up message comes.


   The log file for request (XXXXX) is empty (0 bytes). The concurrent manager may have encountered an error while attempting to create this file.

Therefore, we've reviewed and identify the executable for this request doesn't have proper symbolic    link in place to the right path. Hence we've corrected it. symbolic should create against  fndcpesr.

 From program details
=================

The executable file /u01/app/ebstcshs/apps/apps_st/appl/jakaka/12.0.0/bin/XXTSI_VL_GL_FILE_LOAD for this concurrent program cannot be executed.

Contact your system administrator or support representative.

Verify that the execution path

Path earlier. It points to production.
=======================

-bash-3.2$ ls -ltr XXTSI_VL_GL_FILE_LOAD
lrwxrwxrwx 1 **** oinstall 58 Jan 22 21:36 XXTSI_VL_GL_FILE_LOAD -> /u01/app/ebsprod/apps/apps_st/appl/fnd/12.0.0/bin/fndcpesr
-bash-3.2$ date

Path corrected.

==========

cd $CUSTOM_TOP ( our case it is XXTSI)

ln -s $FND_TOP/bin/fndcpesr XXTSI_VL_GL_FILE_LOAD

-bash-3.2$ ls -ltrh XXTSI_VL_GL_FILE_LOAD

lrwxrwxrwx 1 **** oinstall 58 Jan 29 19:32 XXTSI_VL_GL_FILE_LOAD -> /u01/app/ebstcshs/apps/apps_st/appl/jakaka/12.0.0/bin/fndcpesr

Next program completed successfully.

Thanks,

Sreeharsha

Roll Forward a standby database using RMAN incremental backups

If a physical standby database has lost or corrupted archived redo data or has an unresolvable archive gap which could also due to archive logs getting missed out on the primary database or the archives getting corrupted and there would be no valid backups to recover.

If archive exist on primary, Troubleshoot the issue, it will automatically be shipped if the archive is not corrupted.

 If archive is corrupted at OS level and if we do have backup, then restore archive log from Backup.

If above both options don’t work, then we can recover standby with Incremental SCN for standby/ Roll Forward.

How does it work ::

================

Using the RMAN BACKUP INCREMENTAL FROM SCN command, you can create a backup on the primary database that starts at the standby database's current SCN, which can then be used to roll the standby database forward in time.

Record the SCN gap between Standby and Source i.e., production database.

SQL> select status,instance_name,database_role from v$database,v$instance;

STATUS       INSTANCE_NAME    DATABASE_ROLE

------------ ---------------- ----------------

MOUNTED      PSTLI            PHYSICAL STANDBY

SQL> SELECT to_char(CURRENT_SCN) FROM V$DATABASE;

CURRENT_SCN

-------------

5997422841600

Primary::

SQL> select status,instance_name,database_role from v$database,v$instance;

STATUS       INSTANCE_NAME    DATABASE_ROLE

------------ ---------------- ----------------

OPEN          PSTLI             PRIMARY

SQL> SELECT to_char(CURRENT_SCN) FROM V$DATABASE;

CURRENT_SCN

-------------

5997428587053

Take the incremental SCN backup that starts at the standby database's current SCN and create the standby control file backup.

rman target /

RMAN>BACKUP INCREMENTAL FROM SCN 5997422841600 DATABASE FORMAT '/u01/***/stage/TEMP/DBDR_%U' tag 'ArchiveGap';

Starting backup at 25-MAR-18

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

including current control file in backup set

channel ORA_DISK_1: starting piece 1 at 25-MAR-18

channel ORA_DISK_1: finished piece 1 at 25-MAR-18

piece handle=/u01/**/stage/TEMP/ DBDR123.bak tag= ArchiveGap comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03

Finished backup at 25-MAR-18

Step 2: create the standby controlfile backup on primary.

RMAN> backup current controlfile for standby format ='/u01/**/stage/TEMP/standby_control.bctl';

Step 3: Transfer the backups from the Primary Server to the Standby and catalog them.

Step 4: On Standby database.

  rman target /

Recovery Manager: Release 11.2.0.1.0 - Production on Sun Mar 2515:51:02 2012

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: PSTLI (DBID=431934829, not open)

RMAN> catalog start with ‘/u01/archives/stage/temp/’;  

This will catalog all the backup pieces and our control file.

Now Recover the standby database with the cataloged incremental backup pieces.

RMAN> RECOVER DATABASE NOREDO;

Shutdown the physical standby database, start it in nomount stage and restore the standby controlfile backup that we had taken from the primary database.

RMAN> shutdown immediate

database dismounted

Oracle instance shut down

RMAN> startup nomount

connected to target database (not started)

Oracle instance started

Total System Global Area     659730432 bytes

Fixed Size                     2216264 bytes

Variable Size                398462648 bytes

Database Buffers             255852544 bytes

Redo Buffers                   3198976 bytes

RMAN> restore standby controlfile from ‘/u01/archives/stage/temp/standby_control.bctl’; 

Finished restore at 25-MAR-18

Shutdown the standby database and mount the standby database, so that the standby database would be mounted with the new control file that was restored in the previous step.

Now standby database is in sync with the Primary Database

Thanks.

Sreeharsha

ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB column

Hello every one,

I will bring you a issue in to your notice while we performing EBS RPC5 Patch (Recommended patch collections) recently in to one of our test instance. The Patch had been stopped with below error while calling FNDLOAD function observed in patch log file.

ATTENTION: All workers either have failed or are waiting:

 FAILED: file pqpzzcncprg00025.ldt on worker  10.

 FAILED: file jg12acp.ldt  on worker  10.

Hence, we'd reviewed failed worker log file 10 and therefore found below error in LDT logs.

cd $APPL_TOP/admin/<TWO_TASK>/logs

A database error occurred:

 ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB column

It is because The value for environment variable NLS_LANG is different than the database character set parameter (NLS_CHARACTERSET) when invoking FNDLOAD.

Verified and found the parameter NLS_CHARACTERSET  at DB side has  set to AL32UTF8 and value on application side for this variable set to $NLS_LANG=American_America.UTF8 (echo $NLS_LANG)

Solution

=====

1) Shutdown all workers using adctrl use 3rd option.

    a. adctrl

    b. Select option 3 "Tell worker to shutdown/quit"

Ensure no worker processes are running.

   ps -a | grep adworker

2) Export environment variable  NLS_LANG to a proper value on where patch yet to applied as per value in DB side.

 In our case NLS_LANG  parameter set to below value .

  SQL> SELECT VALUE FROM V$NLS_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET';

VALUE

--------------------------------------------------------------------------------

AL32UTF8

As previously NLS_LANG set to American_America.UTF8 . we need to change below as per above DB parameter.

3) Export NLS_LANG=American_America.AL32UTF8

4) To fix it permanently make changes in Autoconfig TEXT file ( Context File)  where NLS_LANG parameters have different values than expected. If yes, please correct it and run autoconfig.

grep -i NLS_LANG $CONTEXT_FILE

        <NLS_LANG oa_var="s_tools_nlslang">American_America.AL32UTF8</NLS_LANG>

        <NLS_LANG oa_var="s_weboh_nlslang">American_America.AL32UTF8</NLS_LANG>

        <NLS_LANG oa_var="s_nlslang">American_America.AL32UTF8</NLS_LANG>

5) Test if changes to NLS_LANG were successful.

echo $NLS_LANG.

6) Start Patching activity. It will complete successfully.

Thanks,

Regards,
Sreeharsha