MRP0: Background Media Recovery terminated with error 1111

Issue:

MRP0: Background Media Recovery terminated with error 1111

Errors in file <path>xxx_18127.trc:

ORA-01111: name for data file 29 is unknown - rename to correct file

ORA-01110: data file 29: '<path>/UNNAMED00029'

ORA-01157: cannot identify/lock data file 29 - see DBWR trace file

ORA-01111: name for data file 29 is unknown - rename to correct file

ORA-01110: data file 29: '<path>/UNNAMED00029'

Cause:

This issue was happened due to the standby_file_management set to manual.

<path>a_media03.dbf data file is not shipped properly to  standby.

Action Plan:

To fix this error, Please find the action plan below..

1. Check for the files needs to be recovered.

select * from v$recover_file where error like '%FILE%';

Identify on primary of data file 124(Primary Database)

select file#,name from v$datafile where file#='124'

Identify on primary of data file 124(Standby Database)

select file#,name from v$datafile where file#='124'

Crosscheck that no MRP is running and STANDBY_FILE_MANAGEMENT can be enabled once after creating file on standby

ENABLE STANDBY_FILE_MANAGEMENT to MANUAL on the STANDBY server

alter system set standby_file_management=MANUAL scope=both;

show parameter standby_file_management

Create missing datafile on the Standby Server

alter database create datafile '/drhome/oradr/STANDBY/db/tech_st/10.2.0/dbs/UNNAMED00124' as '/drdata/oradr/db/apps_st/data/switchover01.dbf';

ENABLE STANDBY_FILE_MANAGEMENT to MANUAL on the STANDBY server

alter system set standby_file_management=AUTO scope=both;

show parameter standby_file_management

alter database recover managed standby database disconnect from session;

After creating the file, MRP will start applying archives on standby database.

 

Purging data in FND tables

Step1: Close the System Alerts of all severities

1. Navigate to System Administrator > Oracle Applications Manager > System Alert
2. Select the Critical Alert Click on the critical alert value.
3. Then click on  Close all button.
4. Repeat the steps for Error and Warnings, ensure all the alerts are closed.

Step2: Submit the concurrent request “Purge Logs and Closed System Alerts”

Step3: 
Run below sql commands.

 --- Verify the size -- 
SELECT SEGMENT_NAME, TABLESPACE_NAME, BYTES, BLOCKS, EXTENTS FROM DBA_SEGMENTS  WHERE segment_name ='FND_LOG_MESSAGES';

alter table APPLSYS.FND_LOG_MESSAGES enable row movement;

ALTER TABLE APPLSYS.FND_LOG_MESSAGES SHRINK SPACE;

alter table APPLSYS.FND_LOG_MESSAGES SHRINK SPACE CASCADE;

alter table APPLSYS.FND_LOG_MESSAGES disable row movement;

--- Verify the size ---

SELECT SEGMENT_NAME, TABLESPACE_NAME, BYTES, BLOCKS, EXTENTS FROM DBA_SEGMENTS  WHERE segment_name ='FND_LOG_MESSAGES';

FND_LOBS:


To Avoide abnormal growth of FND_LOBS table in Applications 11i [ID 298698.1]

select PCTVERSION from dba_lobs where TABLE_NAME = 'FND_LOBS' and COLUMN_NAME='FILE_DATA'; 
ALTER TABLE FND_LOBS MODIFY LOB (FILE_DATA) ( PCTVERSION 0 );

How To Manage, Reduce, and/or Purged The FND_LOBS Table? [ID 1288149.1]

Running the "Purge Obsolete Generic File Manager Data" (FNDGFMPR) program is the only supported method of purging data

Questions on Purge Obsolete Generic File Manager Data [ID 1165208.1]

Program Parameters:
    Expired:
    Enter "Y" if you want to purge expired data only. Enter "N" if you want the purge to include all data. The default is "Y."
    Program Name:
    Enter the program name(s) to process. Leave blank to process all programs.
    Program Tag:
    Enter the program tag(s) to process. Leave blank to process all program tags. Tags are identifiers used by the Generic File Manager for categorization purposes.

Unable to Change apps password using FNDCPASS

Issue:

FNDCPASS was not able to decrypt password for user 'AUTOINSTALL' during applsys

password change.

FNDCPASS was not able to decrypt password for user 'INDEX' during applsys

password change.

APP-FND-02704: Unable to alter user APPS to change password

Solution:

alter role dba not identified;

alter role aq_administrator_role not identified;

alter role scheduler_admin not identified;

Retest the issue.

Workflow notications status diagram is blank

Solution:
1. Ensure the Profile Server Timezone value is set to the db physical servertime zone Ex "(GMT -06:00) Central Time".

2. Ensure the Profile WF: Workflow Mailer Framework Web Agent value to physical server url ex http://xxx.xxx.xxx:8000 (8000 is default web port accordingly we need to set)
3. Bounce middle tier services
4. Retest the issue

ORA-19809: limit exceeded for recovery files or ORA-19815: WARNING: db_recovery_file_dest_size 100% used

ORA-19809: limit exceeded for recovery files or ORA-19815: WARNING: db_recovery_file_dest_size 100% used

Error message:

ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 
bytes is 100.00% used and has 0 remaining bytes available.
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 10150912 bytes disk space from 2147483648 limit
ARC0: Error 19809 Creating archive log file to 
'/u01/app/oracle/flash_recovery_area/scr10/archivelog/2007_05_25/o1_mf_1_444_0_.arc'
ARC0: Failed to archive thread 1 sequence 444 (19809)
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance scr10 - Archival Error
ORA-16038: log 2 sequence# 444 cannot be archived
ORA-19809: limit exceeded for recovery files


Solution:


To verify this run the following query. It will show the size of the recovery area and how full it is:

set lines 100
col name format a60
select name
, floor(space_limit / 1024 / 1024) "Size MB"
, ceil(space_used  / 1024 / 1024) "Used MB"
from v$recovery_file_dest
order by name
/

We can fix this this problem by increasing the size of flash recovery area (db_recovery_file_dest_size)  or remove some files from the location.

If you have the disk space available, make the  recovery area larger:

alter system set db_recovery_file_dest_size= scope=both
/

To remove files you must use RMAN. Manually moving or deleting files will have no effect as oracle will be unaware. The obvious choice is to backup and remove some archive log files. However, if you usually write your RMAN backups to disk, this could prove tricky. RMAN will attempt to write the backup to the flash recovery area...which is full. You could try sending the backup elsewhere using a command such as this:
This will backup all archive log files to a location of your choice and then remove them. 

rman target / catalog user/pass@rmancat

run {
allocate channel t1 type disk;
backup archivelog all delete input format '//arch_%d_%u_%s';
release channel t1;
}