LinkedIn pixel

How to Manage and Purge Various Logs and Application Data in EBS Environments

  • Centroid
  • $
  • Blog
  • $
  • How to Manage and Purge Various Logs and Application Data in EBS Environments

by Vikram Kotwani – Principal Architect

An excessive number of various logs and out files from EBS applications can impact the performance of the EBS applications. Hence it is particularly important to regularly purge or archive these files to separate locations.

There are many aspects to consider when purging various logs, including:

  1. Is there a business requirement to maintain certain concurrent manager log and out files for certain days?
  2. Is there any retention policy for retaining various logs for certain days?

Note: Before any changes or purges are made in the Production environment, please test it in the lower environment first. Please make sure you have a good backup to restore in case of issues. 

EBS Related Logs and Other Data to Purge

Managing APPLCSF Mount 

APPLCSF is the primary variable set to point the application, where it will write various concurrent manager-related log and out files.

Both the log and out directories should be on a separate mount with high-speed disks for better performance.

Having many files under one directory can create performance issues on NFS or shared file systems. Setup APPLLDM parameter to distribute the log and out files to multiple subdirectories. This allows keeping log and out files for a longer duration (up to 45 days if needed)

The example setup for APPLLDM below will create directory split by first 5 digits on conc req id:

<APPLLDM oa_var=”s_applldm”>reqidexp:5</APPLLDM>   

Purging Application Related Logs and Out Files

For concurrent log and out files, retention of 1 day is enough for regularly running jobs like pick slips, Alerts, etc. For other business-critical CM tasks, it can be decided to keep them for 15 to 30 days, depending on business requirements.

Oracle recommends keeping the count in FND_CNCURRENT_REQUESTS tables below 100k. Run the below SQL to identify the number of rows in the FND_CONCURRENT_REQUESTS table:

SELECT count(1) FROM fnd_concurrent_requests; 

Scheduling the “Purge Concurrent request and/or manager data” program regularly reduces the number of records in FND_CONCURRENT_REQUESTS Table, which is a requirement for better concurrent manager performance.

Besides this, there are many other purge programs provided in EBS for cleaning up various tables.

For various application modules related to data purge, please review

Oracle Support Doc ID: 752322.1 and 2528000.1

You can visit the Purge Portal Dashboard to review current and past activities related to recommended purge programs.

 

Logs

 

Note that only 34 out of the 280 Purge programs are available from the Purge Portal. None are populated in the Portal as seeded, but they can be added. It is a useful way of grouping some Purge Concurrent programs together and monitoring. Typically, they will include regular housekeeping activities such as Purge Obsolete Workflow Runtime Data, Purge Concurrent Request and/or Manager Data, or Purge Signon Audit data. 

 

Purge Portal Nav Path

 

Purge Portal

For more information, please see the Oracle E-Business Suite Maintenance Guide Release 12.2 > Purging in Oracle Applications Manager.

OACORE and FORMS Server Logs

Each managed server in the EBS system produces various logs. All oacore and forms-managed servers should be regularly purged.

Other Application-Level Debug Files

If you have Debug turned ON for some programs, that will negatively impact performance and generate many log files.

  • Check your concurrent requests definitions if you have any debug turned ON and turn them OFF when debugging is done.
  • Turn OFF any debug related profiles at the site or user levels.

Note: BNE related debug logs tend to become huge and should be truncated periodically.

The below query will give you a list of concurrent programs with trace enabled:

select CONCURRENT_PROGRAM_NAME,

USER_CONCURRENT_PROGRAM_NAME,

DESCRIPTION,

LAST_UPDATE_DATE,

LAST_UPDATED_BY,

LAST_UPDATE_LOGIN,

ENABLE_TRACE

from  apps.fnd_concurrent_programs_vl

where enable_trace=’Y’;

Database Related Logs

Over time, various trace files get accumulated, and alert and listener logs tend to get very big, resulting in lost space and database performance issues. Various logs related to the Oracle cluster and database need to be purged or truncated regularly.

A few examples are listed below:

  • Trace files – Set up an adrci or manual process to clean up various trace files.
  • RAC Cluster logs – Set up an adrci or manual process to clean up various trace files.
  • Alert logs – Manually copy, archive, and truncate alert logs weekly or monthly.
  • Listener logs – Manually copy, archive and truncate listener logs weekly or monthly.

Oracle provides a single script to clean up various logs in a database system.

Please review the script provided in Oracle Support Doc ID: 2081655.1

References:

Oracle Support Documents: https://support.oracle.com

  • Reducing the Oracle E-Business Suite Data Footprint (Doc ID 752322.1)
  • Oracle E-Business Suite Performance Best Practices (Doc ID 2528000.1)
  • Managing Concurrent Manager Log and Out Directories (Doc ID 1616827.1)
  • How To Stop the Size of the Bne.log File from Increasing (Doc ID 1988199.1)
  • purgeLogs: Archive & Cleanup traces, logs in one command (Doc ID 2081655.1)

Product Document:

Oracle E-Business Suite Maintenance Guide:  https://docs.oracle.com/cd/E26401_01/doc.122/e22954/toc.htm

Take the First Step Towards a More Efficient EBS Environment

Contact the author or our office today to learn how to boost your EBS performance.

Vikram Kotwani – Principal Architect

LinkedIn: https://www.linkedin.com/in/vikramkotwani/