Q/A Session on EBS:

1.Differences between the DBA_OBJECTS, DBA_OBJECTS_AE, and AD_OBJECTS tables?

DBA_OBJECTS shows object information for the current edition, but the STATUS column in this view may show the object as VALID even if the object actually needs to be compiled before use.

DBA_OBJECTS_AE is similar to DBA_OBJECTS, but shows object information across all editions.

AD_OBJECTS is the Oracle E-Business Suite workaround to the unreliable STATUS column in DBA_OBJECTS. AD_OBJECTS shows the correct status for each object visible in the current edition. It also shows whether the object is “actual” (a real object) in the current edition, or a “stub” object (the object definition was inherited from a previous edition).

Query AD_OBJECTS to locate objects that need to be recompiled before use:
SQL>select owner, object_name, object_type
from ad_objects
where status = ‘INVALID’
order by 1,2,3;

2.What is fs_clone and how is it used?
Command adop phase=fs_clone is a special command that is used to copy the run file system to the patch file system.

3.How to validate application user password from back-end?

select fnd_web_sec.validate_login(‘<username>’,’<password>') from dual;

Important query related to CM

Query to find out trace file created for the particular request:

prompt
column traceid format a8
column tracename format a80
column user_concurrent_program_name format a40
column execname format a15
column enable_trace format a12
set lines 80
set pages 22
set head off

SELECT ‘Request id: ‘||request_id, ‘Trace id: ‘||oracle_Process_id, ‘Trace flag: ‘||req.enable_trace, ‘Trace Name: ‘||dest.value||’ ‘||lower(dbnm.value)||’ora’||oracle_process_id||’.trc’, ‘Prog. Name: ‘||prog.user_concurrent_program_name, ‘File name: ‘||execname.execution_file_name||execname.subroutine_name , ‘Status :’||decode(phase_code, ‘R’, ‘Running’)||’ ‘||’-‘||decode(status_code, ‘R’, ‘Normal’), “SID Serial: “||ses.sid||” , “||ses.serial#, “Module : “||ses.module
from fnd_concurrent_requests req,
v$session ses, v$process proc,
v$parameter dest, v$parameter dbnm,
fnd_concurrent_programs_v1 prog,
fnd_executables execname
where req.request_id = &request
and req.oracle_process_id=proc.spid(+)
and proc.addr = ses.paddr(+)
and dest.name=’user_dump_dest’
and dbnm.name=’db_name’
and req.concurrent_program_id =
prog.concurrent_program_id
and req.program_application_id =
prog.application_id
and prog.application_id =
execname.application_id
and
prog.executable_id=execname.executable_id;

Find OPP Log File Using Concurrent Request ID:
Select
fcpp.concurrent_request_id req_id,
fcp.node_name,
fcp.logfile_name
FROM
fnd_conc_pp_actions fcpp,
fnd_concurrent_processes fcp
where
fcpp.processor_id = fcp.concurrent_process_id
AND
fcpp.action_type = 6
AND
fcpp.concurrent_request_id ='&1';

Concurrent Manager in Details:

Types of concurrent manager:

Internal Concurrent Manager (ICM) It is considered as the “brain” of concurrent processing.Its main task is to make sure that all other concurrent managers are up and running. It controls other manager through the requests made to the service manager. It also starts, stops and restarts the service manager for all nodes. It Activate/Deactivate/Abort Concurrent Manager and Terminate Concurrent Request. It Executes “control requests” submitted by the administrator. It Sets the target number of processes for each service based on the current work shift.

>If the ICM goes down,no need to kill all the managers,simply start the internal manager.
>ICM does not run or schedule any requests.

Standard Manager:Standard Manager is the master concurrent manager. It is always running and can take care of processing any concurrent request. If at all, no other manager is assigned to a program, that program will be picked by standard manager.

Conflict Resolution Manager:Conflict Resolution Manager (CRM) functions to check concurrent program definitions for incompatibility rules. However, the ICM can be configured to take over the CRM’s job to resolve incompatibilities.It takes care of resolving the program incompatibilities and checks if a request in queue can be run in parallel with the running request. If a program is identified as run alone, then it prevents concurrent managers from starting other programs in the same conflict domain.It  can using profile options “Concurrent: Use ICM”. Set it to “Y” to enable and disable “N”.

Internal monitors:Internal Monitors are used specifically in PCP to allow for ICM failover to other available middle tier nodes.Internal Monitors are seeded on every registered node by default.

Service Manager:FNDSM is the Service manager.It act as an agent of the ICM.

Transaction Manager:The transaction manager is responsible for taking the load off the concurrent request table for pooling the request submitted by the user.The transaction manager takes care of these requests and sends it to standard manager directly.In a RAC environment the Transaction manager is required to be activated on each node of the RAC environment.

Transaction Managers run synchronous processing of certain reports requested from a client Program but run as a server side program. These managers run as immediate programs, are started automatically by the ICM, and communicate with Transaction Managers automatically. Running the job is transparent to the calling user as the job runs extremely quickly and in real time. The calling client is notified of the ultimate outcome of the program Execution by a completion message and a set of values returned to them.A Transaction Manager is owned by an application and associated with a data group. Due to this association, and the fact that it runs immediate programs, the Transaction Manager can only run programs contained within its program Library.

Scheduler Manager:The Scheduler Manager, added in 11i, assists the ICM and the CRM in scheduling and conflict resolution.

Behind the scene when a concurrent request is submitted:

1) Once a concurrent request is submitted by the user, the table FND_CONCURRENT_REQUESTS is automatically updated with the details of the request. The table is also updated with the information about the schedule of the concurrent request whether it’s immediately scheduled or scheduled at a fixed time.

2)a) If the request is incompatible/constraints defined ,Once the request time to run is arrived,it status is set to pending/Standby.Now the conflict resolution manager takes care of the request and finds out what are the incompatibilities and set the status pending normal when the incompatibilities are cleared.

b) If there are no incompatibilities then Once the request time to run is arrived,it status is set to pending/Normal

c) ALL the standard concurrent Manager and special manager continuously poll the FND_CONCURRENT_REQUESTS table .The job of a concurrent manager is to execute concurrent requests that are in Pending / Normal phase / status and that it is qualified to run according to its specialization rules.
Concurrent Manager Processes
– Act independently
– Select only requests that: (a) match the manager specialization rules, (b) are Pending/Normal, (c) have a requested start time <= sysdate

d) Once the request is processed, the FND_CONCURRENT_REQUESTS table is updated with the status.

Concurrent manager hangs for below few reason:

The concurrent manager hangs due to many reasons, few of them are as below:

•  Pending/standby requests are too many
• The database is hanging may be because the archive log files have filled
• Long running jobs
• The internal manager was activated by someone other then owner of the application system
• The operating system files system is full
• It’s not able to create the log file
• You’ve shut down the internal manager, but actual has a number in it.

Manager is Inactive/No Manager:

If a concurrent request is on hold or unable to run when there are no active manager processes that can run the request, the request is placed in an Inactive phase.

1.Verify that Internal Concurrent Manager(ICM) is up and running.

Most common reason for the "inactive: No manager" message is that the conrurrent manager is shut down and needs to be started

However, if the Concurrent:Conflicts Domain at the responsibility level didn't exist in the Conflict Domain screen causing the request to go into "Inactive - No Manager state".
if the manager is up but it is showing the inactive-nomanager then check for the log file and do the needful.

As my idea y dont u try with cmclean.sql.(not supported by oracle)
1.Bring down CM.
2.run cmclean.sql

3.Bring up CM.

2. Verify that there is at least one active concurrent manager with/without specialization rules that allow the concurrent program to run.

Define rules identifying which requests a concurrent manager can read. 

Another reason could be,  you might have included some program under 'Specialization Rules' for the concurrent manager . If you include any program that means all other program get excluded automatically. So all the requests stay in inactive manager status

i. Run the following query to check whether any specialization rule defined for any concurrent manager that includes/excludes the concurrent program in question. Query returns 'no rows selected' when there are no Include/Exclude specialization rules of Program type for the given concurrent program.
select 'Concurrent program '||fcp.concurrent_program_name||' is ' ||decode(fcqc.include_flag,'I','included in ','E','excluded from ')||fcqv.user_concurrent_queue_name specialization_rule_details from fnd_concurrent_queues_vl fcqv,fnd_concurrent_queue_content fcqc,fnd_concurrent_programs fcp where fcqv.concurrent_queue_id=fcqc.concurrent_queue_id and fcqc.type_id=fcp.concurrent_program_id and fcp.concurrent_program_name='<PROGRAM_SHORT_NAME>';

Note: Program Short Name is visible when the program is queried in concurrent program definition form.

Example:
SQL> select 'Concurrent program '||fcp.concurrent_program_name||' is ' ||decode(fcqc.include_flag,'I','included in ','E','excluded from ')||fcqv.user_concurrent_queue_name specialization_rule_details from fnd_concurrent_queues_vl fcqv,fnd_concurrent_queue_content fcqc,fnd_concurrent_programs fcp where fcqv.concurrent_queue_id=fcqc.concurrent_queue_id and fcqc.type_id=fcp.concurrent_program_id and fcp.concurrent_program_name='OKCRAQE';

SPECIALIZATION_RULE_DETAILS
-----------------------------------------------------------------------------
Concurrent program OKCRAQE is included in Contracts Core Concurrent Manager
Concurrent program OKCRAQE is excluded from Standard Manager
From the sample output above, it shows that the OKCRAQE(Listener for Events Queue) concurrent program has been excluded from the Standard Manager and included in Contracts Core Concurrent Manager. That means the concurrent request OKCRAQE can be run only by the Contracts Core Concurrent Manager which should be up and running to run and complete the OKCRAQE concurrent request.
Make sure that Concurrent Manager whose specialization rule includes the concurrent program is up and running.
ii. Ensure that standard concurrent manager is up and running.
Follow the below step only when you have confirmed the previous points and the issue is still remaining as there may be an issue with concurrent request queue view.
3. Manually re-create the concurrent request queue view for concurrent managers by entering the following command as an applmgr user at operating system prompt.
FNDLIBR FND FNDCPBWV apps/<pwd> SYSADMIN 'System Administrator' SYSADMIN

Successful completion of the above command shows the message "View created successfully" in the generated log file.

The concurrent request queue view is used internally to map requests to managers. This view would be regenerated when concurrent managers are created, or specialization rules are altered.
==========================
"Include Specialization Rule" Exists for the Standard Manager.

Solution:
1. Log into Applications.
2. Navigate: System Administrator / Concurrent / Manager / Define.
3. Query for 'Standard'.
4. Click Specialization Rules.
5. Remove any Include Rules from the Specialization Rules for Standard Manager.
6. Restart the Managers to test.

The profile 'Concurrent:Conflicts Domain' at responsibility level of the problematic resp is set to a value by mistake.With a value to the profile means specifying a conflict domain for data group of the responsibility. A conflict domain identifies the data where two incompatible programs cannot run simultaneously. This will lead all the requests submit from the responsibility inactive with no manager.

Solution:

To implement the solution, please execute the following steps:

1. Go to the responsibility: System Administrator.

2. Navigate to Profile > System.

3. Select the problematic responsibility and find profile 'Concurrent:Conflicts Domain', clear out value of this profile at the responsibility level and save.

4. Retest the issue.

5. Migrate the solution as appropriate to other environments.


In general, If manager is not processing any requests, there can only be few reasons:


 1) Specialization rules prohibits processing any requests (<Note 1311526.1>)
 2) Program with Run alone flag is submitted with pending or running statusn
 3) All the Managers are all busy.
 4) Concurrent Program has crashed and managers are still waiting for completion.
 5) Concurrent Managers have crashed and somehow not recovered yet .



But here , Concurrent Request ID 2728699 is "Periodic Alert Scheduler" which is set to Run alone flag Y.

Runalone means exactly what it says. It means that it runs alone, no other requests can be running. It also means that it cannot start until no other requests are running. "Periodic Alert Scheduler" was waiting for other "Running" requests to complete. Once running requests are completed,then "Periodic Alert Scheduler" will begin to run and complete. Until then "Periodic Alert Scheduler" will prevent other Concurrent Requests from being executed; and leaving them in Inactive/No Manager status. This is the root-cause of the issue.

Run the Below query to identify the programs that are Run alone flag enabled.
SQL> select request_id from fnd_concurrent_requests
where CONCURRENT_PROGRAM_ID in (
SELECT CONCURRENT_PROGRAM_ID
FROM FND_CONCURRENT_PROGRAMS_VL
WHERE RUN_ALONE_FLAG='Y');

Solution:

Remove Run alone: Y for the "Periodic Alert Scheduler".

Following documents which discuss a similar topic:

Concurrent Requests stay Pending / Standby and Inactive/No Manager forever ; Concurrent Manager Up but does not process requests (Doc ID 2083388.1)

Concurrent Program Spawns Child That is Going to Inactive No Manager (Doc ID 1621537.1)

Concurrent Request Immediately After Submission Ends Up With Inactive Phase and No Manager Status (Doc ID 1947558.1)

All Requests Submitted from A Specific Responsibility are 'Inactive' with 'No Manager' (Doc ID 1539937.1)

Concurrent Requests Are In 'Inactive' 'No Manager' Status in RAC Environment (Doc ID 431022.1)

Concurrent Processing: What to Do When Concurrent Requests Are Not Processing and Have Inactive No Manager Status? (Doc ID 1311526.1)

Phase/Status of  CM:

A concurrent request has a life cycle consisting of the following phases: Pending, Running, and Completed. During each phase, a request has a specific status. Listed below are the possible statuses for each phase:
Pending Phase - Normal, Standby, Scheduled, Waiting
Running Phase - Normal, Paused, Resuming, Terminating
Completed Phase - Normal, Error, Warning, Cancelled, Terminated
Inactive Phase - Disabled, On Hold, No Manager

Variables/Executables for CM

$APPLCSF  is the top-level directory in which the Concurrent Manager puts log and output files.

$APPLLOG & $APPLOUT are the subdirectories in which the Concurrent Manager puts log and output files.

$APPLTMP is the directory in which Oracle Applications temporary files are created.

$APPLPTMP is the directory in which PL/SQL output files are created.

Note: The value must be exactly the same as “utl_file_dir” value in init.ora parameter file.

FNDLIBR ( executable ) The ICM (Internal Concurrent Manager) spawns FNDLIBR processes based on the concurrent manager definitions. The number of FNDLIBR processes at the operating system level will be equal to the total number of max requests for each Oracle concurrent manager defined plus one for the ICM.

Concurrent Managers Tables in R12

FND_CONCURRENT_PROCESSES FND_CONCURRENT_REQUESTS

FND_CONCURRENT_QUEUES

FND_CONCURRENT_PROGRAMS

FND_CONCURRENT_PROCESSES — Lists information about managers; Useful for determining UNIX and Oracle process is associated with managers; Identifies logfiles associated with managers.

FND_CONCURRENT_REQUESTS — Primary jobs submission table; Queried by the managers; Jobs are inserted into this table; Table can grow rather large thus affecting performance; Cleanup scripts available with the Applications.

FND_CONCURRENT_PROGRAMS –Stores information about concurrent programs. Each row includes a name and description of the concurrent program. Each row also includes the execution methods for the program (EXECUTION_METHOD_CODE), the argument method (ARGUMENT_METHOD_CODE), and whether the program is constrained (QUEUE_METHOD_CODE).

What is actual and target in concurrent manager?

In the administer concurrent manager form, there are two columns target and actual. Target columns lists the number of processes that are running for each manager for a particular work shift. The actual column that is currently how many processes are running.

How do I increase concurrent manager processes in r12?

To allocate more processes to a manager, log in as a user with the System Administrator responsibility. Navigate to Concurrent -> Manager -> Define. Increase the number in the Processes column.

How do I clean out the Concurrent Manager tables?

Run the script, cmclean.sql, article Note 134007.1

How do we process more concurrent requests concurrently?

Login as a Sysdba and navigate ->Concurrent -> Manager -> Define and Query for the relevant concurrent manager), done in two steps: (i) Increase the Number of Target processes for the manager (ii) Change the cache size of the concurrent manager.

Flow of a Concurrent Request

Once Concurrent Request is submitted the following things happen ->

A. FND_CONCURRENT_REQUESTS table is updated with the request with scheduled time.

B. Once request is scheduled the concurrent manager checks the table FND_CONCURRENT_TABLES to find out if there is any incompatibility in program.

C. If there is any incompatibility CRM [Conflict Resolution Manager] takes care.

D. For no incompatibility it first checks whether there is any special manager who can take care the request else standard manager takes care.

E. Once completed FND_CONCURRENT_REQUEST table is updated with status.

Some Important phases of concurrent manager

Standby = Request is put in standby mode while CRM is resolving the incompatibility.

No Manager = CM is down or no manager was defined.

Disabled = Concurrent Program is disabled.

Specialization Rules

If we want to run certain types of request only and include and exclude some Cons Request the this screen is used.

A specialization rule associates an action with a type of request. There are two kinds of actions: Include and Exclude.

• Include defines a manager to only read requests of the type specified.
• Exclude defines a manager to read all requests except the type specified.

To prevent the Standard manager from running a particular program we need to exclude the concurrent program from Standard manager.

Work Shifts

It defines the time for which the concurrent manager will be active. To define workshifts go to Concurrent > Manager > Work Shifts.

Sleep Seconds – Amount of time the manager waits between checking for pending requests. 

How to Create a Custom Concurrent Manager in oracle application?

Below is the steps to create custom concurrent manager in oracle apps 11i/R12.

1. Navigate to Concurrent----> Manager----> Define.

2. Manager Field: Custom Manager.

3. Short Name: CUSTOM.

4. Type: Concurrent Manager.

5. Program Library: FNDLIBR.

6. Enter desired cache.

7. Work Shifts: Standard.

8. Enter number of Processes.

9. Provide Specialization Rules (you can include or exclude program, id, user, types or combination).

10. Save.

11. Navigate to Concurrent / Manager / Administer.

12. Activate the Custom Manager.

How to Create a Custom Concurrent Manager (Doc ID 170524.1)

How To Set Concurrent Program To Run Exclusively From A Custom Manager (Doc ID 2268941.1)

When I run a Concurrent request I get Phase – Pending and the Status – Standby. What does pending standby means and how to fix it ?

Pending Standby  - Phase Pending and Status Standby means Program to run request is incompatible with other program(s) currently running.

Why concurrent request is in pending standby mode for long time ?

Cause:

Phase code Pending and Status code Standby means concurrent request has been processed by ICM (Internal Concurrent Manager) , however it is held by CRM(conflict resolution manager) due to incompatibilities with other programs that are currently running. One more possibility of pending standby is CRM itself is not available / not running.

Solution:

i. Through SYSADMIN login go to System Administrator responsibility -> concurrent manager -> CRM And check if it is running state if not then activate the same

ii. In above scenario if CRM is running and still concurrent request is in pending standby state then click on verify button and resubmit the request.

iii. if above two steps doesn't help then application developer intervention is required to re-validate the

incompatibilities in application developer responsibility -> concurrent -> program -> Incompatibilities

In administer concurrent manager form, what is the significance of the verify button and for which manager's it's available?

The verify button becomes enable only when you select the internal manager. One of the functions of the internal manager is to monitor the processes of each concurrent manager. The process of monitoring the other concurrent manager by internal manager is known as the PMON cycle. When you click the verify button you can force the process monitoring or the PMON activity to occur. The verify button is also available for the conflict resolution manager which checks for the program incompatibilities.

When I run a request in GL,the status appears Inactive and phase as No Manager. Please tell me what the problem could be ?

What to do if a request is Inactive/No Manager?

If a concurrent request is on hold or unable to run when there are no active manager processes that can run the request, the request is placed in an Inactive phase.

Verify that Internal Concurrent Manager(ICM) is up and running.

Verify that there is at least one active concurrent manager with/without specialization rules that allow the concurrent program to run.

Ensure that standard concurrent manager is up and running.

***

i) No manager is defined to run the request

or

ii) All managers are locked by run-alone requests

or

iii) Concurrent Manager Service is down

or

iv) No concurrent manager process because of workshift

To check Work Shift for any Concurrent Manager From System Administrator responsibility > Concurrent > Manager > Define > Work Shifts > Processes

Answer: This is quite tricky questions

a) Make certain that there is at least one active manager with specialization rules that allow the program.

b) If you have confirmed the previous point, then the problem may be a stale Worker Request View

– The view is used internally to map requests to managers

– The view is regenerated when managers are created, or specialization rules are altered

c) You can manually regenerate the view

FNDLIBR FND FNDCPBWV apps/apps SYSADMIN ‘System Administrator’ SYSADMIN

 How can we enable/disable Conflict Resolution Manager?

Answer: It can be done using profile options “Concurrent: Use ICM”. Set it to “Y” to enable the Conflict Resolution manager. To disable it, set the profile option to “N”.

What is a Child Request?

A child request is a concurrent request submitted by another concurrent request.

http://www.moreajays.com/2017/12/interview-questions-on-concurrent.html

ORA-28007: the password cannot be reused

SQL>  alter user system identified by xxxx;
 alter user system identified by xxxx
*
ERROR at line 1:
ORA-28007: the password cannot be reused

User status:
select USERNAME, PROFILE, ACCOUNT_STATUS from dba_users where username = 'SYSTEM';

Check user profile:

select * from dba_profiles where profile='USER_PROFILE';
select * from dba_profiles where profile='DBUSER' and  RESOURCE_NAME in ('PASSWORD_REUSE_TIME') ;

col PROFILE format a50;
select * from dba_profiles where profile like '%C##EMGC_PROFIL%';

alter profile USER_PROFILE limit password_verify_function NULL;
alter profile USER_PROFILE limit PASSWORD_REUSE_MAX unlimited;
alter profile C##EMGC_PROFILE limit PASSWORD_REUSE_MAX unlimited;
alter profile USER_PROFILE limit PASSWORD_REUSE_TIME unlimited;

Once the password is changed make it to default...


Disable Password Policy in Oracle Database 12c and solution to ORA-28003: password verification for the specified password failed
Check if PASSWORD_VERIFY_FUNCTION is used:
SQL> select limit from dba_profiles where profile = 'DEFAULT' and resource_name = 'PASSWORD_VERIFY_FUNCTION';
--Turn off verification:
alter profile default limit password_verify_function null;

======
set pages 200;
set lines 200;
col LIMIT format a30;
col PROFILE format a40;
select profile, resource_name, limit from dba_profiles where resource_type='PASSWORD' order by 1,2;

alter profile DEFAULT limit PASSWORD_REUSE_TIME UNLIMITED;

alter profile DEFAULT limit PASSWORD_REUSE_MAX UNLIMITED;

alter profile default limit password_verify_function ORA12C_STRONG_VERIFY_FUNCTION;

Difference between Applsys&App, Applpub and APPS_NE.

Apps is a schema which does not contain any tables of itself. We can say APPS is the shared runtime schema for all E-Business Suite products. It contains all the synonyms of all the table in Oracle apps. But it also contains packages, functions, procedures. The default password is apps.

Applsys schema contains all the tables required for administarative purpose. The default password is apps. All the technical products’ database objects are consolidated into a single schema called Applsys

Applsyspub schema is responsible for password checking.The default password is pub.Applsyspub is used for authentication by having read only views.

APPS_NE schema is the owner of those objects previously owned by APPS that cannot be Editioned or in other words; the APPS_NEW is the APPS schema for the non-editioned database objects.
For the E-Business Suite to make use of Editioning, Oracle has added a new schema to the ‘APPS’ family – the APPS_NE schema.The default password for APPS_NE is 'APPS.'

APPS_NE has 3 privileges APPS does not           
CREATE MATERIALIZED VIEW
CREATE SEQUENCE
DROP ANY TYPE

APPS has 18 privileges that APPS_NE does not
ALTER ANY PROCEDURE
ALTER DATABASE
ANALYZE ANY DICTIONARY
CHANGE NOTIFICATION
CREATE ANY DIRECTORY
CREATE ANY EDITION
CREATE ANY PROCEDURE
CREATE EXTERNAL JOB
CREATE JOB
CREATE PUBLIC DATABASE LINK
CREATE PUBLIC SYNONYM
DEQUEUE ANY QUEUE
DROP ANY EDITION
DROP ANY PROCEDURE
DROP PUBLIC SYNONYM
ENQUEUE ANY QUEUE
EXECUTE ANY TYPE
MANAGE ANY QUEUE


APPS_NE has 56 system privileges
ALTER ANY CLUSTER
ALTER ANY INDEX
ALTER ANY MATERIALIZED VIEW
ALTER ANY OUTLINE
ALTER ANY ROLE
ALTER ANY SEQUENCE
ALTER ANY TABLE
ALTER ANY TRIGGER
ALTER ANY TYPE
ALTER SESSION
ALTER SYSTEM
ANALYZE ANY
COMMENT ANY TABLE
CREATE ANY CLUSTER
CREATE ANY CONTEXT
CREATE ANY INDEX
CREATE ANY MATERIALIZED VIEW
CREATE ANY OUTLINE
CREATE ANY SEQUENCE
CREATE ANY SYNONYM
CREATE ANY TABLE
CREATE ANY TRIGGER
CREATE ANY TYPE
CREATE ANY VIEW
CREATE DATABASE LINK
CREATE MATERIALIZED VIEW
CREATE PROCEDURE
CREATE ROLE
CREATE SEQUENCE
CREATE SESSION
CREATE SYNONYM
CREATE TRIGGER
CREATE TYPE
CREATE VIEW
DELETE ANY TABLE
DROP ANY CLUSTER
DROP ANY CONTEXT
DROP ANY INDEX
DROP ANY MATERIALIZED VIEW
DROP ANY OUTLINE
DROP ANY ROLE
DROP ANY SEQUENCE
DROP ANY SYNONYM
DROP ANY TABLE
DROP ANY TRIGGER
DROP ANY TYPE
DROP ANY VIEW
EXECUTE ANY PROCEDURE
GLOBAL QUERY REWRITE
GRANT ANY ROLE
INSERT ANY TABLE
LOCK ANY TABLE
SELECT ANY SEQUENCE
SELECT ANY TABLE
UNLIMITED TABLESPACE
UPDATE ANY TABLE

Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone:

Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone:

Use Rapid Clone to create template files for cloning on the Source System. After copying the Source System to the Target System, Rapid Clone updates these templates to include the new Target System configuration settings. Rapid Clone never changes the Source System configuration.

What is cloning:

Cloning is the process of creating a copy of an existing Oracle E-Business Suite system.
Cloning process consists of the following three phases, each of which is made up of several logical sections and their steps.

• Prepare the Source System for database tier and application tier. 
• Copy both database tier and application tier nodes from the Source System to Target System. 
• Configure the Target System for both database tier and application tier.

For Oracle E-Business Suite Release 12.2 system that is on the AD-TXK Delta 6 or lower codelevel.

Prepare the Source System for database tier and application tier:

Prepare the Source System database tier for cloning :

Execute the following commands:

$ cd <RDBMS ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME> 

$ perl adpreclone.pl dbTier

• It’s create the clone directory >$ORACLE_HOME/appsutil/clone/directory
• Obtains Database Information and Creates adcrdbclone.sql

Prepare the Source System application tier for cloning:

Source the environment file of the Run Edition File system.

To Verify:

$ echo $FILE_EDITION

should return the value:

run

Execute the following commands:

$ cd <INST_TOP>/admin/scripts

$ perl adpreclone.pl appsTie

It will collect all the information about the source system, creates a cloning stage area, and generates templates and drivers. All of these are to reconfigure the instance on a Target machine.

Adpreclone.pl process on the application tier creates a complete compressed archive of the Oracle Fusion Middleware and its components as follows:

A compressed archive of the Oracle WebLogic Server home, Oracle Web Tier Utilities home, Oracle Common Utilities home and the Oracle E-Business Suite home: 

<COMMON_TOP>/clone/FMW/FMW_Home.jar

A compressed archive of the Oracle E-Business Suite WebLogic domain:

<COMMON_TOP>/clone/FMW/WLS/EBSdomain.jar

The Oracle E-Business Suite WebLogic domain's configuration template:

<COMMON_TOP>/clone/FMW/WLS/plan/moveplan.xml

A compressed archive of the Oracle Web Tier/Oracle HTTP Server configuration instance:

<COMMON_TOP>/clone/FMW/OHS/ohsarchive.jar

The Oracle HTTP Server configuration instance's configuration template:

<COMMON_TOP>/clone/FMW/OHS/moveplan.xml

These jar files created in clone directory are sufficent to clone the FMW home,So we dont need to copy FMW home in the clone process from source to target

>>>It’s create the Clone directory in application side >cd $COMMON_TOP/clone

Log Location:

adpreclone log files are created in the <INST_TOP>/admin/log/clone directory.

Copy both database tier and application tier nodes from the Source System to the Target System:

Database:

Copy the Source System database ORACLE_HOME to the Target System.

Use , Tar or cp

Copy the application tier file system from the Source "Run Edition File System" to the Target "Run Edition File System":

Copy the following application tier directories from the Source Node to the Target Run Edition File System application tier node:

<APPL_TOP> 

<COMMON_TOP>

<OracleAS Tools 10.1.2 ORACLE_HOME>

Configure the Target System:

Configure the Target System database:

$ cd <RDBMS ORACLE_HOME>/appsutil/clone/bin
$ perl adcfgclone.pl dbTechstack
$perl adcfgclone.pl dbTier <Database Target context file>  (when using previous context file).


log file is created in <RDBMS_ORACLE_HOME>/appsutil/log/<CONTEXT_NAME> directory.

Options:

Database Node: dbTier   | database | dbconfig | dbTechStack 

dbTier :
configure the ORACLE_HOME on the target database tier node and  recreate the controlfiles.

• It’s Create the context file
• Register the ORACLE_HOME
• Relink the ORACLE_HOME
• Configure the ORACLE_HOME
• Recreate the control files
• Start SQL*Net Listener

dbTechStack :
configure the ORACLE_HOME on the target database tier node only.

• Create the context file
• Register ORACLE_HOME
• Configure the ORACLE_HOME
• Start SQL*Net Listener

dbconfig :
configure the database with  context file.Database should be in open mode.

• This scripts configure the database

database:

• Configure the ORACLE_HOME
• Recreate the control files
• Start SQL*Net Listener

Configure the Target System application tier :

$ cd <COMMON_TOP>/clone/bin
$ perl adcfgclone.pl appsTier

At the prompt “Target System Base Directory”, enter the location of the base directory. For example: /<SID>/applmgr.

When asked the question:
Do you want to startup the Application Services for mult35? (y/n)” you should answer ‘n’.

log files are created in the <INST_TOP>/admin/log/clone directory in the Run Edition File System.

Option:

Application Node: appsTier | appltop  | atTechStack

 atTechStack:

• It’s Create the context file
• Register the ORACLE_HOME
• Relink the ORACLE_HOME
• Configure the ORACLE_HOME
• Create INST_TOP
• Start SQL*Net Listener

appltop:

• Configure the apple top
• Create INST_TOP
• Start SQL*Net Listener

appsTier

• It’s Create the context file
• Register the ORACLE_HOME
• Relink the ORACLE_HOME
• It’s create the INST_TOP
• Configure APPL_TOP
• Start APPS Process

Copy the following Oracle E-Business Suite application directories from the Run Edition File System to the Patch Edition File System.

<APPL_TOP>
<COMMON_TOP>
<OracleAS Tools 10.1.2 ORACLE_HOME>

Log on to the Patch Edition File System in the Target System as the applmgr user and enter the following commands:
$ cd <COMMON_TOP>/clone/bin
$ perl adcfgclone.pl appsTier

The Patch Edition File System must be aware of the location of the Run Edition File System that will be configured in the next step. At the prompt “Location of Run System Context File”, enter the absolute path to the context file for the Run Edition File System that was created in the previous step.

For exmp:/<SID>/applmgr/fs1/inst/apps/TEST_<servername>/appl/admin/TEST_<servername>.xml.

log files are created in the <INST_TOP>/admin/log/clone directory in the Patch Edition File System.

start the services from run file system

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

High level Steps:-

PART 1 : PREREQUISITE TASKS

—————————-

– check for in-progress online patching cycle

PART 2 : PREPARE SOURCE SYSTEM

——————————

perl adpreclone.pl dbTier

perl adpreclone.pl appsTier

**require Apps User password and Weblogic AdminServer password

In 12.2, the adpreclone.pl process on the application tier creates a complete compressed archive of the Oracle Fusion Middleware and its components

PART 3 : COPY APPLICATION TIER NODE

———————————–

Copy Application Tier node from the Source “Run Edition File System” to the Target “Run Edition File System”.

so if source run edition is fs2, then target run edition will also be fs2

Only copy “EBSapps” directory from under $RUN_BASE. DO NOT COPY “inst” or “FMW_Home”

PART 4 : COPY DATABASE TIER NODE

——————————–

do normal RMAN cloning

PART 5 : CONFIGURE TARGET DATABASE SYSTEM

—————————————–

SQL> exec fnd_conc_clone.setup_clean;

$ perl adconfig.pl dbTier

PART 6 : CONFIGURE TARGET APPLICATION SYSTEM

——————————————–

$ perl adcfgclone.pl appsTier

RUN ADPRECLONE ON RUN EDITION <<< NEW STEP IN R12.2

COPY TARGET RUN EDITION OVER TARGET PATCH EDITION <<< NEW STEP IN R12.2

RUN ADCFGCLONE ON TARGET APPLICATION NODE PATCH EDITION <<< NEW STEP IN R12.2

PART 7 : FINISHING TASKS

————————-

Update profiles, workflow settings, SESSION_COOKIE_DOMAIN, SSL and SSO configuration as required

Changing SYS/SYSTEM/APPS/SYSADMIN/OTHER ORACLE passwords as per business requirements

• Run adpreclone on the source database and application nodes.

• Back up the full Container Database (CDB) database with archives by using RMAN Hot backup and copy it to the target node.

• Clean up the target database and application node.

• Copy the source application binaries and database binaries to the target node.

• Configure $Oracle_Home on the target database node.

• Restore and recover the databases.

• Perform post-restore steps on the Target database node.

• Configure the application on the target application node.

• Perform post-clone steps on the application node.

• Start the target application services.

Oracle EBS Cloning steps are as follows.

1. Running Pre-Clone on the Source Apps Tier and DB Tier
2. Backup Full database and Archivelogs via RMAN
3. Copy Some Application Tier directories from Source to Target
4. Copy Oracle database Home and backups from Source to Target
5. Configure and start Oracle Instance on Target
6. Duplicate & Restore and Recover database and open clone database on Target
7. Run Post Clone Steps on Target Database Server ( DB Tier )
8. Run Post Clone Steps on Target Application Server ( Apps Tier )
9. Run Pre-Clone on the Target Apps Tier for Creating Patch edition
10. Copy EBSpps directory from Run edition to patch edition on Target Application server
11. Run Post Clone on Patch Edition of Target Application server
12. Start EBS Clone Environment

https://ittutorial.org/ebs-cloning-ebs-clone-oracle-r12-2-e-business-suite-step-by-step-cloning-ebs-clone/

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

Adpreclone.pl on the Application Tier 

The adpreclone.pl process on the Application Tier creates a complete compressed archive of the Oracle Fusion Middleware and its components as follows:  A compressed archive of the Oracle WebLogic Server home, Oracle Web Tier Utilities home, Oracle Common Utilities home and the Oracle E-Business Suite home:

<COMMON_TOP>/clone/FMW/FMW_Home.jar

A compressed archive of the Oracle E-Business Suite Weblogic domain:

 <COMMON_TOP>/clone/FMW/WLS/EBSdomain.jar

 The Oracle E-Business Suite Weblogic domain’s configuration template:

 <COMMON_TOP>/clone/FMW/WLS/plan/moveplan.xml

A compressed archive of the Oracle Web Tier/Oracle HTTP Server Cloning Oracle E-Business Suite with Rapid Clone 17-9 configuration instance:

 <COMMON_TOP>/clone/FMW/OHS/ohsarchive.jar

The Oracle HTTP Server configuration instance’s configuration template:

<COMMON_TOP>/clone/FMW/OHS/moveplan.xml

****The 'dualfs' option will clone the Run and Patch file systems in a single operation.

$ perl adcfgclone.pl appsTier dualfs

Adding a New Application Tier Node to an Existing System:

• add it to the existing Applications system, a process also known as scale up or scale out.
• Before adding a new node, you should update the tcp.invited_nodes parameter of sqlnet.ora on the database tier to include the host.domain of the new node being added.
• The addition of nodes should not be done during an active adop cycle.

Steps for adding a node on a non-shared file system:

1.Run adpreclone.pl on both the Run and Patch Edition File Systems in the primary application tier node of the E-Business Suite instance

Note: Before executing this step, ensure the AdminServer on both the Run Edition File System and the Patch Edition File System is running. The AdminServer on the Patch Edition File System can be shut down after completion of adpreclone.pl.

2.Copy the Run Edition File System to the Target secondary node.

Only the following directories should be copied:

<APPL_TOP>

<COMMON_TOP>

<OracleAS Tools 10.1.2 ORACLE_HOME>

The secondary node must be on a different host.

3.Configure both Run and Patch Edition File Systems in the Target secondary node.

Note: Before executing these steps, ensure the AdminServer on both the Run Edition File System and the Patch Edition File System is running. This is required for adcfgclone.pl to properly register the new node on the Oracle E-Business Suite instance.

The adcfgclone.pl script can be executed in either the interactive mode or in the non-interactive mode for adding the node. You can choose one of the two options.

Running adcfgclone.pl in the interactive mode

Execute the following command:

$ cd <COMMON_TOP>/clone/bin

$ perl adcfgclone.pl appsTier dualfs

When asked the questions:

"Do you want to add a node (yes/no)" you should answer 'yes'

"Do you want to startup the Application Services for <TWO_TASK>? (y/n)" you should answer 'y' if the Application services are to be started up. Otherwise, you should answer 'n'.

Note: Ensure that the port pool provided for the Run Edition File System is different from the port pool of the Patch Edition File System of the primary node. Otherwise, it will result in errors during execution of fs_clone.

As mentioned earlier, the function (run or patch) of the two file systems is not static, and their values switch every time when a cutover phase is complete. Hence, refer to the environment variables $RUN_BASE and $PATCH_BASE to determine the Run Edition File System and Patch Edition File System respectively. 

Running adcfgclone.pl in the non-interactive mode

Execute the following command:

$ cd <COMMON_TOP>/clone/bin

$ perl adcfgclone.pl component=appsTier pairsfile=<PAIRSFILE> addnode=yes dualfs=yes

The sample pairsfile for application tier is delivered under INST_TOP of each file system in the location <INST_TOP>/appl/admin/<CONTEXT_NAME>.txt. It should be updated to have values corresponding to the node being added.

Note:

Ensure the following while setting values in the pairs file:

The value of 's_shared_file_system' should be set to 'false' and the value of 's_atName' should be set to the hostname of the node being added.

The port pool provided for the Run Edition File System is different from the port pool of the Patch Edition File System of the primary node. Otherwise, it will result in errors during execution of fs_clone. As mentioned earlier, the function (run or patch) of the two file systems is not static, and their values switch every time when a cutover phase is complete. Hence, refer to the environment variables $RUN_BASE and $PATCH_BASE to determine the Run Edition File System and Patch Edition File System respectively.

The value of 'patch_s_port_pool' for the port pool of the Patch Edition File System is provided correctly.

5.Register the new topology from the newly added application tier node.

If OHS is enabled on the newly added node, perform the following steps on that node:

Source the Run Edition File System.

The OHS configuration files mod_wl_ohs.conf and apps.conf will contain entries of managed servers from all application tier nodes. If any of these managed servers are not desired to be part of the cluster configuration on the current node, execute the following command to delete details of these managed servers from the OHS configuration files mod_wl_ohs.conf and apps.conf on the current node:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \

  -contextfile=<CONTEXT_FILE> \

  -configoption=removeMS \

  -oacore=<host>.<domain>:<port>  \  

  -oafm=<host>.<domain>:<port> \

  -forms=<host>.<domain>:<port> \ 

  -formsc4ws=<host>.<domain>:<port> \

  -ekanban=<host>.<domain>:<port> \

  -accessgate=<host>.<domain>:<port> \

  -yms=<host>.<domain>:<port>

where

The argument contextfile accepts the complete path to the context file.

The arguments oacore, oafm, forms, formsc4ws, ekanban, accessgate and yms accept a comma-separated list of managed server details in the following format:

<host>.<domain>:<port>

host, domain and port are the hostname, domain and port of the managed server whose reference is to be deleted.

For example, to delete references of managed servers oacore_server1 on 'testserver1' and forms_server2 on host 'testserver2' on the domain 'example.com' with ports 7201 and 7601 respectively, the following command should be executed:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> \

  -configoption=removeMS -oacore=testserver1.example.com:7201 -forms=testserver2.example.com:7601

  

  

Perform the following steps on the other application tier nodes participating in the same cluster where this node is added:

Source the Run Edition File System.

If any of the managed servers from the newly added node are desired to be part of the cluster configuration on the current node, execute the following command to add details of these managed servers into the OHS configuration files mod_wl_ohs.conf and apps.conf on the current node:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \

  -contextfile=<CONTEXT_FILE> \

  -configoption=addMS \

  -oacore=<host>.<domain>:<port> \

  -oafm=<host>.<domain>:<port> \

  -forms=<host>.<domain>:<port> \

  -formsc4ws=<host>.<domain>:<port>

where

The argument contextfile accepts the complete path to the context file.

The arguments oacore, oafm, forms, formsc4ws accept a comma-separated list of managed server details in the following format:

<host>.<domain>:<port>

host and domain are the hostname and domain name of the newly added node

port is the port of the new managed server whose reference is to be added

For example, if the newly added node on host 'testserver1' and domain 'example.com' contains managed servers oacore_server3 and oafm_server3 with ports 7205 and 7605 respectively, the following command should be executed:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> \

-configoption=addMS -oacore=testserver1.example.com:7205 -oafm=testserver1.example.com:7605

6.On all application tier nodes, perform the following steps to register the newly added application tier node with the application tier TNS Listener (FNDFS listener) on each node:

Source the Run Edition file system.

Run AutoConfig.

On UNIX:

$ sh <ADMIN_SCRIPTS_HOME>/adautocfg.sh

Reload the application tier TNS Listener (FNDFS listener) as follows:

$ lsnrctl reload APPS_<TWO_TASK>

Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone (Doc ID 1383621.1)

Cloning Oracle E-Business Suite Release 12.2 with Multitenant Database using Rapid Clone (Doc ID 2552208.1)

https://www.funoracleapps.com/2022/04/ebs-step-by-step-oracle-apps-cloning.html

How to clear lock on web logic

Clear lock:

cd $DOMAIN_HOME/servers/AdminServer
mv tmp tmp_bkp
mv cache cache_bkp

cd data/ldap/ldapfiles
mv EmbeddedLDAP.lok EmbeddedLDAP.lok_bkp2

cd ../../store/default
 mv _WLS_ADMINSERVER000000.DAT _WLS_ADMINSERVER000000.DAT_bkp2

cd ../diagnostics
mv WLS_DIAGNOSTICS000000.DAT WLS_DIAGNOSTICS000000.DAT_bkp2

VCN:Virtual Cloud Network:

Basic terminology of VCN:

When you work with Oracle Cloud Infrastructure, one of the first steps is to set up a virtual cloud network (VCN) for your cloud resources.

VCN:Virtual Cloud Network:

A virtual, private network that you set up in Oracle data centers.

A Virtual Cloud Network (VCN) is a virtual version of a traditional network including subnets, route tables, and gateways on which your compute instances run.

A VCN is a customizable private network in Oracle Cloud Infrastructure.

A VCN resides within a single region but can cross multiple Availability Domains.VCN is specific to a region.

When you create your VCN, you assign a contiguous IPv4 CIDR block of your choice. VCN sizes ranging from /16 (65,533 IP addresses) to /30 (1 IP address) are allowed. Example: 10.0.0.0/16, 192.168.0.0/24.


Default Components that Come With Your VCN .Your VCN automatically comes with these default components:

Default route table, with no rules
Default security list, with default rules
Default set of DHCP options, with default values.

***Virtual Cloud Network (VCN) is a virtual network in which you can create subnets, route tables and gateways for your compute instances.

There are two options for creating VCN in OCI:
Create Virtual Cloud Network only: Creates a Virtual Cloud Network only. You’ll still need to set up at least one subnet, gateway and route rule to have a working Virtual Cloud Network.
Create Virtual Cloud Network plus related resources: Automatically sets up a Virtual Cloud Network with access to the internet. You can set up firewall rules and Security Lists to control ingress and egress traffic to your Instances. All related resources will be created in the same Compartment as the VCN.

SUBNET:
Each VCN network is subdivided into subnets.

Subnets can be either AD-specific or regional.Oracle recommends using regional subnets because they're more flexible.They make it easier to efficiently divide your VCN into subnets while also designing for availability domain failure.

Subnets contain virtual network interface cards (VNICs), which attach to instances. Instances are placed in subnets and can live across.

All VNICs in a given subnet use the same route table, security lists, and DHCP options

Instances draw their internal IP address and network configuration from their subnet.

Each subnet has a contiguous range of IPs, described in CIDR notation. Subnet IP ranges cannot overlap.

Subnets can be designated as either
• Private (instances contain private IP addresses assigned to vNICs)
• Public (contain both private and public IP addresses assigned to vNICs)
 > Public has access to internet but private don't have and both types of subnets can co-exist in the same VCN.

Can have multiple subnet in an AD.

***Subnets: They are a logical subdivisions of the VCN and they contain virtual network interface cards (VNICs), which attach to instances.

VNIC:
A virtual network interface card (VNIC), which attaches to an instance and resides in a subnet to enable a connection to the subnet's VCN.The VNIC determines how the instance connects with endpoints inside and outside the VCN. Each instance has a primary VNIC that's created during instance launch and cannot be removed. You can add secondary VNICs to an existing instance (in the same availability domain as the primary VNIC), and remove them as you like. Each secondary VNIC can be in a subnet in the same VCN as the primary VNIC, or in a different subnet that is either in the same VCN or a different one. However, all the VNICs must be in the same availability domain as the instance.

SECURITY LISTS:

Virtual firewall rules for your VCN.

Security Lists provides two types of traffic:

• ingress: Incoming traffic
• Egress:Outgoing traffic.

You can choose whether a given rule is stateful or stateless.

For example, you can allow incoming SSH traffic from anywhere to a subnet's instances by setting up a stateful ingress rule with source CIDR 0.0.0.0/0, and destination TCP port 22.

***Security Lists: They have ingress and egress rules that specify the types of traffic (protocol and port) allowed in and out of the instances.

ROUTE TABLES:

Route Table is used to send traffic out of the VCN.

VCN comes with an empty default route table, and you can add custom route tables of your own.

Consists of a set of route rules; each rule specifies
• Destination CIDR block
• Route Target (the next hop) for the traffic that matches that CIDR.

Each subnet uses a single route table specified at time of subnet creation, but can be edited later.

Route table is used only if the destination IP address is not within the VCN's CIDR block

No route rules are required in order to enable traffic within the VCN itself

When you add an internet gateway, NAT gateway, service gateway, dynamic routing gateway or a peering connection, you must update the route table for any subnet that uses these gateways or connection.

***Route Tables: They have rules to route traffic from subnets to destinations outside the VCN by way of gateways or specially configured instances.

DHCP OPTIONS:

Configuration information that is automatically provided to the instances when they boot up.

***DHCP Options: Configuration information that is automatically provided to the instances when they boot up.

PRIVATE IP:
A private IP address and related information for addressing an instance (for example, a hostname for DNS).

Each VNIC has a primary private IP, and you can add and remove secondary private IPs.

The primary private IP address on an instance doesn't change during the instance's lifetime and cannot be removed from the instance.


PUBLIC IP:

A public IP address and related information. You can optionally assign a public IP to your instances or other resources that have a private IP. Public IPs can be either ephemeral or reserved.

DYNAMIC ROUTING GATEWAY (DRG):

It provides a path for private network traffic between your VCN and on-premises network. You can use it with other Networking components and a router in your on-premises network to establish a connection by way of IPSec VPN or Oracle Cloud Infrastructure FastConnect. It can also provide a path for private network traffic between your VCN and another VCN in a different region.

***You can think of a DRG as a virtual router that provides a path for private traffic (that is, traffic that uses private IPv4 addresses) between your VCN and networks outside the VCN's region.

You use a DRG when connecting your existing on-premises network to your virtual cloud network (VCN) with one (or both) of these:
IPSec VPN
Oracle Cloud Infrastructure FastConnect

You also use a DRG when peering a VCN with a VCN in a different region:
Remote VCN Peering (Across Regions)

A DRG is a standalone object. To use it, you must attach it to a VCN. A VCN can be attached to only one DRG at a time, and a DRG can be attached to only one VCN at a time.You can detach a DRG and reattach it at any time.

After attaching a DRG, you must add a route for the DRG in the VCN's route table to enable traffic flow

The VCN has three gateways:

INTERNET GATEWAY:

Internet gateway provides a path for network traffic between your VCN and the interne.
You can have only one internet gateway for a VCN.
After creating an internet gateway, you must add a route for the gateway in the VCN's Route Table to enable traffic flow.

NETWORK ADDRESS TRANSLATION (NAT) GATEWAY:

NAT gateway gives an entire private network access to the internet without assigning each host a public IP address.

Hosts can initiate outbound connections to the internet and receive responses, but not receive inbound connections initiated from the internet. Use case: updates, patches)(Connections can be initiated only from the subnet. )

You can have more than one NAT gateway on a VCN, though a given subnet can route traffic to only a single NAT gateway

It gives cloud resources without public IP addresses access to the internet without exposing those resources to incoming internet connections.


SERVICE GATEWAY:

It provides a path for private network traffic between your VCN and supported services in the Oracle Services Network (examples: Oracle Cloud Infrastructure Object Storage and Autonomous Database). For example, DB Systems in a private subnet in your VCN can back up data to Object Storage without needing public IP addresses or access to the internet.

Use case: back up DB Systems in VCN to Object Storage)

LOCAL PEERING GATEWAY (LPG):

It lets you peer one VCN with another VCN in the same region. Peering means the VCNs communicate using private IP addresses, without the traffic traversing the internet or routing through your on-premises network.

A given VCN must have a separate LPG for each peering it establishes.

REMOTE PEERING CONNECTION (RPC):

A component that you can add to a DRG. It lets you peer one VCN with another VCN in a different region.

Reset the WebLogic administration password (if locked or forgotten):

Previously,  discussed about changing the weblogic password of EBS WebLogic Domain  R12.2 if password is known.

Here, we are going to discuss when Reset the WebLogic administration password (if locked or forgotten):

1.Shut down all running services. Since the AdminServer password is not known, the servers cannot be stopped from the console and so must be killed as follows.

(i)Connect to the Oracle E-Business Suite instance and source the application tier environment file.


(ii)Identify the PIDs of Node Manager, AdminServer, and all running Managed
Servers:
$ ps -ef | grep "NodeManager"
$ ps -ef | grep "weblogic.Name=AdminServer"
$ ps -ef | grep "weblogic.Name=forms-c4ws_server"
$ ps -ef | grep "weblogic.Name=forms_server"
$ ps -ef | grep "weblogic.Name=oafm_server"
$ ps -ef | grep "weblogic.Name=oacore_server"


(iii)Kill all these processes, starting with Node Manager and followed by the
Managed Servers.

2. Back up these folders, and then delete them:
<EBS_DOMAIN_HOME>/security/ DefaultAuthenticatorInit.ldift
<EBS_DOMAIN_HOME>/servers/<server_name>/data/ldap
<EBS_DOMAIN_HOME>/servers/<server_name>/security/boot.properties
<EBS_DOMAIN_HOME>/servers/<server_name>/data/nodemanager/boot.properties

Where:
• <EBS_DOMAIN_HOME> is the absolute path of the EBS WebLogic domain
• <server_name> is the name of the server directory under <EBS_DOMAIN_HOME>.

If the password is not reset correctly, the backed up files and folders can be restored.

3. Set up a new environment to change the WLS AdminServer password.
(i) Start a new session and connect to the Oracle E-Business Suite instance.
(ii) Do not source the application tier environment file.
(iii) Run the following command to source the WebLogic Server domain environment:
$ cd <EBS_DOMAIN_HOME>/bin
$ source setDomainEnv.sh
(iv)Run the following commands:
$ cd <EBS_DOMAIN_HOME>/security
$ java weblogic.security.utils.AdminAccount <wls_adminuser> <wls_admin_new_password>

Where:
• <wls_adminuser> is the same as the value of context variable
s_wls_admin_user
• <wls_admin_new_password> is the new WLS AdminServer password you
wish to set.

4. Start AdminServer from the command line. You will be prompted for the WebLogic
Server username and password, so that the AdminServer boot.properties file
can be generated.
(i) Go to the EBS Domain Home:
$ cd <EBS_DOMAIN_HOME>
(ii) Start AdminServer:
$ java <s_nm_jvm_startup_properties> -Dweblogic.system.StoreBootIdentity=true -Dweblogic.Name=AdminServer weblogic.Server

Where:
• <s_nm_jvm_startup_properties> is the same as the value of context variable ss_nm_jvm_startup_properties
The above command prompts for the WebLogic Server username and password:
Enter username to boot WebLogic server:
Enter password to boot WebLogic server:
Provide the same credentials as you provided in Step 3.

5. Change the Node Manager password.
(i)Log in to the WebLogic Administration console.
(ii)Click the 'Lock & Edit' button.
(iii)In the left panel, click on the EBS Domain link.
(iv)Select the 'Security' tab
(v) Click on the 'Advanced' link.
(vi)  Edit the 'Node Manager password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.
(vii)  Edit the 'Confirm Node Manager Password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.
(viii) Save and activate the changes.

6. The first time, AdminServer has to be stopped from the Admin console. Follow
these steps:
(i) Log in to the WebLogic Administration console.
(ii) Shut down AdminServer.

7. Set up your environment to start AdminServer again. AdminServer should now be started using the normal AD script, which will also start Node Manager using the new password.
(i)Launch a new session and connect to the Oracle E-Business Suite instance.
(ii) Source the application tier environment file.
(iii) Start AdminServer with the following command:
$ $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start

8. Start the Managed Servers. For the first time, all Managed Servers should be started from the WebLogic Server Admin console. This step will create boot.properties files for the respective Managed Servers. Follow these steps:
(i) Log in to the WebLogic Server Administration Console.
(ii) Start all Managed Servers, one at a time.

9. Shut down all the Managed Servers. This is so the new credentials will be picked up at the next startup. Follow these steps:
(i) Log in to the WebLogic AdminServer console.
(ii) Shut down all Managed Servers.
(iii) Shut down AdminServer.

10. Shut down Node Manager using the normal AD script.
$ $ADMIN_SCRIPTS_HOME/adnodemgrctl.sh stop

11. Copy the boot.properties file for each Managed Server. WebLogic Server native scripts use the boot.properties file. The above steps have created the boot.properties file under
<EBS_DOMAIN_HOME>/servers/<Managed Servername>/data/nodemanager, which is used by Node Manager. For each Managed Server, copy the newly-generated boot.properties file from
<EBS_DOMAIN_HOME>/servers/<Managed Servername>/data/nodemanager to <EBS_DOMAIN_HOME>/servers/<Managed Server name>/security.
The EBS WebLogic Server domain password has now been changed, and all servers can now be started using the normal AD scripts.
To start AdminServer:
$ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start
To start the Managed Servers:
$ $ADMIN_SCRIPTS_HOME/admanagedsrvctl.sh start <managed_server_name>

12. The above steps have changed the Oracle WebLogic AdminServer password on the run file system. You now need to perform an fs_clone operation, to change the WebLogic EBS Domain password on the patch file system:
(i) Launch a new session and connect to the Oracle E-Business Suite instance.
(ii)Source the application tier environment file.
(iii) Run the command:
$ adop phase=fs_clone

Change or Reset The WebLogic Administration Password In 12.2:

Changing the WebLogic administration password (if password is known):

The Oracle WebLogic Server domain EBS_domain_<SID> uses Node Manager to control the Administration Server and the managed servers. For this domain, the Node Manager and Oracle WebLogic Server Administration User passwords must be same or the AD control scripts will not work properly.

Important: If you need to change the Administration User password,you must change the Node Manager password first. If you do not do this, the WebLogic Server configuration change will not be detected and the next online patching cycle may fail.

The password-changing instructions that follow should be performed on the run file system. The password change will be automatically propagated to the patch file system during the next adop prepare phase or fs_clone operation.


Shut down all application tier services except the Admin Server:

On the primary node, run the command:
 $ <ADMIN_SCRIPTS_HOME>/adstpall.sh -skipNM -skipAdmin

 On all secondary nodes, run the command:
 $ <ADMIN_SCRIPTS_HOME>/adstpall.sh

Change the Oracle WebLogic Server Administration User password by performing the following steps as applicable.
1. Source the environment on the run file system.
2. Run the commands appropriate for your platform:

$ perl $FND_TOP/patch/115/bin/txkUpdateEBSDomain.pl -action=updateAdminPassword

start all services on all nodes using command :

$ <ADMIN_SCRIPTS_HOME>/adstrtal.sh

The above command is available only if TXK 7 is applied.

If that is not the case, the password need to changed from Console and few steps need to be performed.

Steps for Changing  the weblogic password pre TXK 7:

1)  Access Administrative console
2) Login using the current weblogic admin username and  password.
3) Select the lock and edit button and click domain
4) Click on Security TAB and then click on advanced tab
5) Provide the new password which you want to configure for weblogic admin user   in the node manager password field
6) Click on “save” and Verify settings updated successfully and then click on “Activate changes”
7) Now click on “Security Realms” and Click on “myrealm”
8)select “users and groups” and select weblogic User and then provide the new password for the weblogic user
9) Make sure the settings has been updated successfully

After this we need to edit the configuration file “boot.properties” for all managed and admin server  using text editor and update the password field with the above configured password ( new password)

a) take  backup of the below files

$FMW_HOME/user_projects/domains/EBS_domain/servers/AdminServer/security/boot.properties
$FMW_HOME/user_projects/domains/EBS_domain/servers/forms-c4ws_server1/data/nodemanager/boot.properties
$FMW_HOME/user_projects/domains/EBS_domain/servers/forms_server1/data/nodemanager/boot.properties
$FMW_HOME/user_projects/domains/EBS_domain/servers/oacore_server1/data/nodemanager/boot.properties
$FMW_HOME/user_projects/domains/EBS_domain/servers/oafm_server1/data/nodemanager/boot.properties

b) Update the password in password field and restart the application services using adstpall.sh and adstrtal.sh scripts.

Difference between R12.1 and R12.2

Difference between  R12.1 and R12.2 technology stack:


>>The most substantial difference is the inclusion of weblogic server in place of 10.1.3 Oracle home .

The 10.1.3 Application server is replaced by FMW_HOME.
The major change in R12.2 is involvement of Weblogic server to manager all the forms,oacore servers.

Replacing Oracle Containers for Java (OC4J) 10g with WebLogic Server 11g EBS 12.2 will use WebLogic Server from Fusion Middleware 11g in place of OC4J 10g as part of the release’s internal technology stack.  Other additional new Fusion Middleware 11g components used will include WebLogic JSP and UIX 11g.

>>In R12.2 we have two filesystems fs1(run filesystem) and fs2(patch filesystem), where as In R12.1.3 we only one application filesystem.


>>In 12.1.3 we have adpatch utility for patching, In R12.2.4 we have adop(online patching) utility patching.

Online Patching support via 11gR2 Edition-Based Redefinition.EBS 12.2 will use the 11gR2 Database’s Edition-Based Redefinition features to provide support for Online Patching.

>>A new “EBSenv.env” is introduced to select RUN/PATCH file system.

>>How to change apps user password in R12.2.4


All the services are started from Weblogic home.

Difference:

Replacing Oracle Containers for Java (OC4J) 10g with WebLogic Server 11g
Online Patching support via 11gR2 Edition-Based Redefinition
adpatch is replaced with adop.

Differe in R12.1 and R12.2 services:

The OPMN only manages Oracle HTTP Serve.

•        The run and patch file system, here each use a different s_port_pool.

•        In which few ports are same for both fs1 & fs2.   

    For example: s_webport, s_rpcport, s_java_object_cache_port