Restore INST_TOP if it is deleted or corrupted accidently?

 

Restore INST_TOP if it is deleted or corrupted accidently?

Below steps to restore the INST_TOP if it is deleted or corrupted without using adcfgclone.

Step 1: 

If we have CONTEXT_FILE backup then we can easily restore (follow  step-2). If CONTEXT_FILE is not there then need to follow below steps to restore CONTEXT_FILE.

  perl /clone/bin/adclonectx.pl retrieve 

Step 2:

Once we restored CONTEXT_FILE then run the auto-config using below script. It will recreate INST_TOP without using adcfgcolne.

Run AutoConfig using: "perl $AD_TOP/bin/adconfig.pl contextfile=<CONTEXT_FILE>" command and it will create the $INST_TOP

Rman backup & Restore in different locations

Introduction

Managing large Oracle database backups—especially when they exceed multiple terabytes—often forces us to use multiple mount points due to limited storage availability. In my setup, I had RMAN backup files spread across /u02 and /u03, which made restoring using a single RMAN command challenging.

Instead of restructuring storage, I used a workaround: creating soft links. This makes the backup pieces from different locations appear as though they're under one directory—simplifying the RMAN restore process.

Below is a detailed, step-by-step walkthrough based on my practical experience.

---

Solution

Let’s assume your backup files reside in:

• /u02/backup/location1

• /u03/backup/location2

Since RMAN’s DUPLICATE DATABASE command accepts only one backup source, we overcome this by consolidating all files via symbolic links.

Example Structure

In /u02/backup/location1, run the following commands:

cd /u02/backup/location1

ln -s /u03/backup/location2/PROD_df_full_143926_1.bak PROD_df_full_143926_1.bak
ln -s /u03/backup/location2/PROD_df_full_143927_1.bak PROD_df_full_143927_1.bak
ln -s /u03/backup/location2/PROD_df_full_143929_1.bak PROD_df_full_143929_1.bak
ln -s /u03/backup/location2/PROD_df_full_143936_1.bak PROD_df_full_143936_1.bak
ln -s /u03/backup/location2/PROD_df_full_143935_1.bak PROD_df_full_143935_1.bak

Afterward, executing ls -l in /u02/backup/location1 yields:

FINP01_df_full_143926_1.bak -> /u03/backup/rbackup/FINS01/FINP01_df_full_143926_1.bak
FINP01_df_full_143927_1.bak -> /u03/backup/rbackup/FINS01/FINP01_df_full_143927_1.bak
FINP01_df_full_143929_1.bak -> /u03/backup/rbackup/FINS01/FINP01_df_full_143929_1.bak
FINP01_df_full_143936_1.bak -> /u03/backup/rbackup/FINS01/FINP01_df_full_143936_1.bak
FINP01_df_full_143935_1.bak -> /u03/backup/rbackup/FINS01/FINP01_df_full_143935_1.bak

This setup tricks RMAN into recognizing all backup pieces as coming from a single location.

---

Step-by-Step: Using RMAN Duplicate with Soft Links

1. Create Soft Links
   As shown above, link all backup files from /u03 into /u02.

2. Execute the RMAN Duplicate Command
   Run this command, pointing to the single aggregated location:

   DUPLICATE TARGET DATABASE TO <TARGETDB>
   BACKUP LOCATION '/u02/backup/location1'
   NOFILENAMECHECK;
   

   By doing this, RMAN treats /u02/backup/location1 as the only backup source, while it effectively includes files from both mount points via soft links.

Oracle Apps R12 – Fix for "Cannot Complete Your Request"

When working with Oracle E-Business Suite (R12), you may sometimes face the error "Cannot complete your request" while accessing certain pages or forms. This usually happens due to an incorrect guest user password configuration in the context file.

error:

“Cannot complete applications logon.
You may have entered an invalid applications password,
or there may have been a database connect error.”

The problem usually occurs when the GUEST user password in the context file doesn't match the actual database setup. This leads to authentication failures in Apache, JServ, and other components.

It was clear that GUEST password was out of sync. Since we could not pinpoint where the issue was we followed this strategy to solve this issue:

1. Change the s_guest_passwd to GUEST/GUEST in context file and run autoconfig.
2. Checked everything was working fine, including Apache, Jserv, Forms
3. Changed back s_guest_passwd to GUEST/ORACLE in context file and run autoconfig.

 

Find largest table in oracle

The below query gives you the top 10 largest tables in oracle database.

Script

SELECT * FROM
(select 
 SEGMENT_NAME, 
 SEGMENT_TYPE, 
 BYTES/1024/1024/1024 GB, 
 TABLESPACE_NAME 
from 
 dba_segments
order by 3 desc ) WHERE
ROWNUM <= 10

Multinode adop patching:

 In a multi-node setup on EBS 12.2, we can apply patches individually on each node as well.

If ssh is enabled from primary to secondary node then it is not necessary.

But I will show in this post how we can do it manually. This is an interview question and may be required sometimes.

Scenario 1: Shared Application Tier File System with SSH enabled

primary node run below

adop phase=<phase_name>

Scenario 2: Shared Application Tier File System without SSH enabled

primary node: 

adop phase=<phase_name> allnodes=no action=db

secondary node:

adop phase=<phase_name> allnodes=no action=nodb

Note: In a multi-node environment, the cleanup phase is to be executed on the primary node only as it is the DB phase. All other phases have to be executed on primary and all secondary nodes.

Scenario 3: Non-Shared Application Tier File System with SSH enabled

primary node run below

adop phase=<phase_name>

Scenario 4: Non-Shared Application Tier File System without SSH enabled

primary node: 

adop phase=<phase_name> allnodes=no action=db

secondary node:

adop phase=<phase_name> allnodes=no action=nodb

DBA SCRIPTS

 https://dbaclass.com/monitor-your-db/

Restore INST_TOP if it is deleted or corrupted accidently?

 

Restore INST_TOP if it is deleted or corrupted accidently?

Below steps to restore the INST_TOP if it is deleted or corrupted without using adcfgclone.

Step 1: 

If we have CONTEXT_FILE backup then we can easily restore 

(follow  step-2). If CONTEXT_FILE is not there

 then need to follow below steps to restore CONTEXT_FILE.

  perl /clone/bin/adclonectx.pl retrieve 

Step 2:

Once we restored CONTEXT_FILE then run the auto-config using below script. 

It will recreate INST_TOP without using adcfgcolne.

Run AutoConfig using:

 "perl $AD_TOP/bin/adconfig.pl contextfile=<CONTEXT_FILE>" command 

and it will create the $INST_TOP