Delete Old Obsolete and Expired Oracle RMAN Backup

How to Delete Old Obsolete and Expired Oracle RMAN Backup

$ rman target /
RMAN> SHOW ALL;

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;

I. Delete Obsolete Backup

1. What is an Obsolete Backup?

In our example above, any backup that we have in our system (both on RMAN catalog, and as physical RMAN backup files at the filesystem level) that is older than 4 days is considered obsolete. Please keep in mind that sometimes it might not be just 4 days. It depends on whether a full-backup is available within the last 4 days. If you don’t have a full backup in the last 4 days, then what RMAN considers as obsolete will be even longer than that. i.e Until the last full backup.

Obsolete backups are those that are not required to satisfy RMAN requirement of what is specified in the retention policy to recover the database from the backup.

The following three things will happen when you perform “DELETE OBSOLETE” from RMAN prompt:

The physical backup files are removed from the filesystem level (or from tape backup)
The backup entries are removed from the RMAN recovery catalog
The entries are marked as DELETED in the Oracle control file



2. View Backups Before Delete Obsolete

In the following example, I see that there are lot of backup that I have on the system that are way older than what I need to satisfy my recovery requirement. i.e I have backups starting from 6th June until 26th Sep (several months).
RMAN> LIST BACKUP SUMMARY;

3. Perform RMAN CrossCheck

Before we start executing the delete obsolete command, it is always recommended to do a crosscheck of the backup as shown below.

crosscheck backup command will check for the records in the RMAN repository to make sure they are accurate. If there is an record in the RMAN catalog that is not available on the physical filesystem, it will make that entry with appropriate status.
RMAN> CROSSCHECK BACKUP;

4. Delete Obsolete RMAN backup

Once the crosscheck is done, it is time to delete the old obsolete backup using the DELETE OBSOLETE command as shown below.
RMAN> DELETE OBSOLETE;

5. Other Delete Obsolete Options

If you are writing a shell script that will automatically do this for you on an on-going basis, you don’t want to manually say “YES” to delete obsolete command as shown above.

Instead, you can ignore the prompt and automatically delete all obsolete backups as shown below.
RMAN> DELETE NOPROMPT OBSOLETE;

Also, if you want to delete obsolete backup based on your own recovery window criteria (instead of what is configured in RMAN when you do “show all”), you can specify it as shown below. The following will delete old backups based on recovery window of 10 days.
RMAN> DELETE OBSOLETE RECOVERY WINDOW OF 10 DAYS;

6. View Backups After Delete Obsolete

Finally, if you do the list backup summary, you’ll notice that this has only the backups that are required to satisfy the recovery criteria. All other backups are deleted.
RMAN> LIST BACKUP SUMMARY;





II. Delete Expired Backup

1. What is an Expired Backup?

When you have an entry in the RMAN repository for a backup, but there are no corresponding physical rman backup files at the filesystem level, that is considered as expired entry.

But, you need to execute the crosscheck command, which will go through all the records in the RMAN catalog, and mark any expired records appropriately.
RMAN> CROSSCHECK BACKUP;

3. View Backups Before Delete Expired

As you see from the output below, there are several records in the RMAN catalog that are marked as EXPIRED.
RMAN> LIST BACKUP SUMMARY;

4. Delete Expired RMAN Catalog Entries

The following will delete all the records that are in RMAN catalog which are marked as EXPIRED. In other words, this deletes the expired records that don’t have the corresponding physical RMAN backup file in the filesystem.
RMAN> DELETE EXPIRED BACKUP;



5. View Backups After Delete Expired

After deleting the expired entries, view the catalog to make sure it contains only the active available RMAN backup records.
RMAN> LIST BACKUP SUMMARY;

Upgrade from 12.2.0 to 12.2.4

http://way2ebsupgrade.blogspot.com/

Upgrade 12.2.5

http://ermanarslan.blogspot.com/2016/06/ebs-ebs-1225-12c-db-installation-on.html

Oracle E-business Suite R12

RESTARTING ADOP

Restarting ADOP

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

 If you have shut down the workers, or if adop quits while performing processing actions, it saves all the actions completed up to that point in restart files.

 Investigate and Patching Utilities resolve the problem that caused the failure,
then restart adop.
After you restart adop, it will ask if you want to continue with the previous session
(at the point where the processing stopped), or start a new session.

To restart from beginning,  use restart=no abandon=yes

To restart a patch you need to use restart=yes abandon=no .

eg. adop restart=no abandon=yes  phase=apply

If still can not restart,
2 Check the contents of the AD_ADOP_SESSIONS and AD_ADOP_SESSION_PATCHES tables
---------------------------------------------------------------------------------------
2.1
column id format 99
column nn format a10
column nt format a6
select adop_session_id id, prepare_status pr, apply_status ap, 
finalize_status fi, cutover_status cu, cleanup_status cl, abort_status ab, status st, node_name nn, node_type nt
from ad_adop_sessions
order by adop_session_id desc;

2.2
column id format 99
column bn format a12
column pr format 99999999
column afs format a40
column pfs format a40
column cs format a9
column nn format a10
column ed format a28
column drv format a28
column pt format a35

select adop_session_id id, bug_number bn, patchrun_id pr, status st, 
node_name nn, cast(end_date as timestamp) ed, driver_file_name drv, patch_top  pt
from ad_adop_session_patches
order by end_date desc;

2.3 explanation example of above output
=========================
 Examining the AD_ADOP_SESSIONS table,
 ID P A F C C A S NN         NT
 --- - - - - - - - ---------- ------
3 X P N X N X F test2    master
2 R N N N N Y C test2    master

It looks like the first ADOP cycle (prepare phase) was attempted at session ID 2 and then for some reason it didn't finish and then an abort was  initiated which did finish.  A new ADOP session (ID 3) was attempted but via hotpatch and it failed.  Since this table only reports what went on with ADOP there's no information about adpatch usage, i.e. if it was used before the
 first ADOP cycle or in between session 2 and 3, or after session 3.

2.4 To diagnostic further for the root cause why patch application failed, we need adpatch log for the failed patch xxxx.
cd  $APPL_TOP_NE/../log/adop/
eg.
 /d01/EBS/VIS/fs_ne/EBSapps/log/adop//timestamp/context_name/xxxx/log

3 If you are just wants to start from a fresh page and considering the state of these tables
I would suggest making a manual modification to the  AD_ADOP_SESSIONS table just so it would not hold up ADOP execution due to an
incomplete hotpatch session.
 Do the following:
update ad_adop_sessions set status='C' where adop_session_id=3;


4 restart adop and retest.

Change IP Address in an Oracle Applications Environment

How to Change IP Address in an Oracle Applications Environment

Step 1.

 Change the IP Address in the Server; 

Step 2. 

Verify the current ip address setup in the Oracle Applications environment. 

Connect as apps user 

select NODE_NAME, STATUS, NODE_MODE, NODE_ID,SERVER_ADDRESS, HOST, DOMAIN, WEBHOST, VIRTUAL_IP from fnd_nodes where node_name = upper('hostname');

Step 3. 

Run the following command to remove the old ip address from the Oracle Applications tables:

perl $AD_TOP/bin/adgentns.pl appspass=apps contextfile=$APPL_TOP/admin/_hostname.xml -removeserver 

replace _hostname.xml for the context file name under the $APPL_TOP/admin directory;

then connect to SQL*Plus as apps user and run:

begin
FND_NET_SERVICES.remove_server('', '');
end;
/
commit;
/

replace by the SID of the environment and by the hostname in the environment. Both must be entered in upper case.

Step 4.

--------

 Run autoconfig to populate the values using the new IP Address.

Step 5.

--------- 

Confirm the ip address has been changed to the new value changed in the step 1:

select NODE_NAME, STATUS, NODE_MODE, NODE_ID,SERVER_ADDRESS, HOST, DOMAIN, WEBHOST, VIRTUAL_IP from fnd_nodes where node_name = upper('hostname');

How to get the current Patchset level of Oracle Applications products in R12 ?

1) Login to OAM

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

(Responsibility "Oracle Applications Manager", menu "OAM Support Cart")

and Navigate: Support Cart -> Applications Signature -> Collect -> Check "Product Information" box -> Click on "View" (eyeglasses)

This will display the following patchset information :

Application Name
Current Patch Level
Product Version
Status (Installed, Shared Product, Inactive)

2) The patchset level information can be retrieved directly via sqlplus with the following diagnostic script :

$AD_TOP/sql/adutconf.sql

Oracle APPS

How to open Oracle Apps R12 forms in Internet Explorer 11 

1) In internet explorer 11 , navigate to Tools –> Compatibility View Settings . Then add Domain name in the URL (ex: chitrap.com) using Add this website option.

2.) Navigate to Tools –> Internet options –> Security . Select internet and click on Custom level. 

3.)Scroll down till end of the options and change the option Enable XSS filter to  Disable.

4.) Add EBS URL as Intranet Site in Internet Options to avoid most of the Java security related issues.