Expand Your Skills: Announcing New OCI training for AWS and Azure Architects

 One of the of the most effective ways to learn a new skill is to leverage your existing experience, learning, and knowledge in that area and build upon it. For example, let’s say you have a fair amount of experience with gardening and now want to learn about vertical hydroponic gardening (quite a craze in the last few years!). To do that, you don’t need to relearn everything you already know about gardening (basics of how plants grow, the amount of sunshine they need, etc.). Instead, you can leverage your existing expertise (gardening) in learning a new skill (vertical hydroponic gardening). The same approach can be applied in learning many new skills, including cloud technologies.

Our customers tell us that they would like to learn more about Oracle Cloud, but don’t want to start from scratch. Our customers (and most of us) are time-constrained. Moreover, many organizations have only recently started experimenting with Oracle Cloud. However, many of them use AWS and/or Microsoft Azure and are familiar with cloud-operating models.    

Build on your previous experience with Azure or AWS

As part of our transferable skills strategy, we are excited to announce two new courses:

• OCI for AWS Architects

• OCI for Azure Architects.

The idea behind these two courses is to help you ramp-up to Oracle Cloud faster by building on your existing cloud skillsets, knowledge and experience. These courses are short in length (~3 hours each) and can be completed in 2-3 brief sessions. Moreover, they are available for free to everyone.   

We compare ~35 services each from OCI, AWS and Azure across these nine categories – that’s over 100+ services across the two courses

These courses are technical and do not include any sales or marketing pitches. Our goal with these courses is to help you get started on OCI quickly, so we compare the core-primitives of OCI with those of AWS and Azure. We compare these core building blocks:

• Global Infrastructure
• Identity and Access Management
• Networking
• Compute
• Storage
• Database
• Security
• Application Development
• Monitoring and Observability

Each of the categories have services and features compared side by side. For example, this slide from the Security Module course compares capabilities around OS and workload protection covering managed Bastions, OS patching, dedicated compute hosts, etc. Throughout the courses, we discuss how AWS and Azure services and features translate to OCI, so you can relate and build upon your existing knowledge.  

One of the key challenges we faced was determining how detailed these courses should be. Any competitive discussion can go deep when you start comparing individual features – most of the cloud services have very extensive feature sets. Therefore, for the sake of brevity, we do not cover every individual feature, but do touch on the key similarities and differences.

Each of these categories include OCI services walk-throughs, because it is much easier to understand the product when you see it in action. We also realized this could be the first OCI course many learners would encounter, so we cover many how-to topics:

• How you set up identity (authentication and authorization)
• Spin up a compute instance
• Configure a network or peer networks
• Create various types of storage service
• Spin up an autonomous database

and more.

The idea, quite simply, is to show you how services work in OCI.

Finally, as these courses are technical in nature, we don’t discuss pricing, SLAs, support, or any of the business side of OCI or AWS/Azure. However, we do have webpages where you can learn more about OCI technical differentiation, including SLAs and Pricing: OCI v/s AWS, OCI v/s Microsoft Azure and OCI v/s Google Cloud Platform.

Get Started

The courses are available here:

• OCI for AWS Architects
• OCI for Azure Architects

If you have an existing OCI tenancy, you can use it to practice the service walkthroughs shown in these courses. If you don’t have an existing OCI account, we recommend that you open an Oracle Cloud Free Tier account in order to run these walkthroughs – for free.

Thanks for reading and good luck with your learning journey!

Ref : https://blogs.oracle.com/oracleuniversity/post/oci-training-for-aws-and-azure-architects

Discovery

 Please run the ETCC report on Run FS and DB and share the output

  Patch 17537119: EBS 12.2 TECHNOLOGY CODELEVEL CHECKER (ETCC)

Please run the below reports on DB & Applications side and share the results

 E-Business Suite Applications Technology Stack Utility / Script To Check The Techstack Component Versions (Forms, Http Server, JDK, Framework, Database, etc) (Doc ID 601736.1)

Please share Demantra Patches 

select * from version_details_history order by 4 desc;

Pease share the output from Demantra Weblogic home

$ORACLE_HOME/OPatch/opatch lsinventory

$ORACLE_HOME/OPatch/opatch lspatches

$ORACLE_HOME/OPatch/opatch lsinventory | grep –i  applied

Delete a node from application Tier in Oracle Apps R12.2

 

Delete a node from application Tier in Oracle Apps R12.2 in shared application file system.

.4 Deleting an Application Tier Node

Note: These steps are ONLY for deletion of secondary application tier nodes. The primary application tier node cannot be deleted using these steps.

The following steps should be performed to delete a secondary application tier node from an existing Oracle E-Business Suite Release 12.2 multi-node instance. The steps described in this section are applicable to secondary application tier nodes with shared and non-shared file systems.

Note: In case OHS is enabled only on the secondary node being deleted, OHS needs to first be enabled on some other node before starting with deletion of the node.

Before performing the following steps, ensure that the WebLogic administration server is running from both the Run and Patch Edition File Systems of the primary application tier node.

Note: Do not perform a 'delete node' operation when a patching cycle is active.

1. Delete the run file system and patch file system configuration of the secondary application tier node.
   
   
   
   Note: Deletion of nodes may need to be performed in two scenarios - when the node is still accessible (users are able to login to the node) and in the remote case when the node is not accessible due to some issues ( the node may not be physically present and/or login to the node is not possible).
   
   In the first scenario, all information related to the node has to be cleaned up altogether (including removal of references from the WebLogic domain and EBS topology as well as removal of the file system and inventory references). Case 1 describes the steps to be performed in this scenario.
   
   In the second scenario, references to the node can be cleaned up only from the WebLogic domain and the EBS topology. The steps for deletion of secondary nodes in this scenario are described in Case 2 below. Please note that this option has been introduced in R12.TXK.C.DELTA.6 and is not available in the earlier releases.
   
   In order to keep the E-Business Suite instance in a consistent state, steps should be followed strictly based on the scenario.
   
   
   Case 1: If the secondary node to be deleted is accessible, run the following steps:
   
   
   1. Login to the secondary node to be deleted.
      
      
   2. Source the run file system.
      
      
   3. Ensure that all application tier services from the run and patch file system for the node to be deleted are shut down.
      
      
   4. Run the ebs-delete-node option of the adProvisionEBS.pl script as follows:
      
      $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-delete-node \
-contextfile=<CONTEXT_FILE> -logfile=<LOG_FILE>
      This will delete the managed servers, OHS instances and Node Manager on the current node from the run file system WebLogic domain.
      
      
   5. If the node is a non-shared node, verify and remove the following Oracle Home entries of both the Run and Patch file systems from the Oracle Inventory:
      
      
      • <FMW_HOME>/webtier
      • <FMW_HOME>/oracle_common
      • <FMW_HOME>/Oracle_EBS-app1
      
      If any of the above Oracle Home entries are already registered in Oracle Inventory, you can run the following command to de-register or detach that Oracle Home:
      $ cd <Oracle Home>/oui/bin
$ ./runInstaller -detachhome ORACLE_HOME=<Oracle Home Location> [-invPtrLoc <s_invPtrLoc>]
      Here,
-invPtrLoc argument needs to be specified only if the 'EBS installation central' inventory is being used.
      s_invPtrLoc is the context variable that stores the inventory pointer location.
      
      For example:
      $ cd /u02/r122/fs1/FMW_Home/oracle_common/oui/bin
$ ./runInstaller -detachhome \
ORACLE_HOME=/u02/r122/fs1/FMW_Home/oracle_common -silent
      Note: The Oracle Home <FMW_HOME>/webtier should be de-registered from the Oracle Inventory before trying to remove the Oracle Home <FMW_HOME>/oracle_common.
      
      
   6. If the node is a non-shared node, verify and remove the following Oracle Home entry from the Oracle Inventory:
      
<OracleAS Tools 10.1.2 ORACLE_HOME>
      
      If the above Oracle Home entry is registered in Oracle Inventory, you can run the following command to de-register the Oracle Home:
      
      $ ./runInstaller -removeHome ORACLE_HOME=<s_tools_oh> -silent
      Here,
-invPtrLoc argument needs to be specified only if the 'EBS installation central' inventory is being used.
      s_invPtrLoc is the context variable that stores the inventory pointer location.
      
      For example:
      
      $ cd /u02/r122/fs1/EBSapps/10.1.2/oui/bin
$ ./runInstaller -removeHome \
ORACLE_HOME=/u02/r122/fs1/EBSapps/10.1.2 -silent
      
      
   
   Case 2: If the secondary node to be deleted is not accessible, run the following steps to remove the node from the FND topology and the EBS domain:
   
   
   1. Login to the primary node.
      
      
   2. Source the run file system.
      
      
   3. Run the ebs-delete-node option of the adProvisionEBS.pl script as follows:
      
      $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-delete-node \
-contextfile=<CONTEXT_FILE> -hostname=<HOSTNAME OF NODE TO BE DELETED> -logfile=<LOG_FILE>
      This will delete all information corresponding to the specified node from the Weblogic domain like the managed servers, OHS instances and Node Manager of the specified node from both the run and patch file system WebLogic domain. In addition, it will also remove the node from the list of active nodes registered in the topology.
      
      
      
      Note: Since the steps mentioned in Case 2 take care of only partial cleanup of the node, these steps should be performed only in case the node to be deleted is not accessible due to some issues. In all other scenarios, the nodes should be deleted by following steps mentioned in Case1. Otherwise, this may lead to the E-Business Suite instance being in an inconsistent state.
      
      
   
   
2. Sync the OHS configuration on the other nodes to remove references of the deleted node.
   
   Perform the following steps on the other nodes:
   
   1. Source the run file system.
      
      
   2. If any of the managed servers from the deleted node are part of the cluster configuration defined on the current node, run 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, if the deleted node was on host 'testserver1' and domain 'example.com' and it contained managed servers oacore_server3 and oafm_server3 with ports 7205 and 7605 respectively, the following command should be run to remove references to these managed servers:
      $ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE>
-configoption=removeMS -oacore=testserver1.example.com:7205 -oafm=testserver1.example.com:7605
3. Review and update the value of the context variable 's_shared_file_system' on the primary node (required only while deleting a shared file system node).
   
   If the deleted node was the only node sharing the file system with a primary application tier node, run the following steps on the primary node:
   
   
   1. Set the value of the context variable 's_shared_file_system' in the run context file of the primary node to 'false' via the Oracle Applications Manager.
      
      
   2. Login to the primary node.
      
      
   3. Source the run file system.
      
      
   4. Run AutoConfig as follows:
      
      On UNIX:
      
      
      $ sh <ADMIN_SCRIPTS_HOME>/adautocfg.sh
      On Windows:
      
      
      C:\> <ADMIN_SCRIPTS_HOME>\adautocfg.cmd
      
      
4. Run AutoConfig on the database tier.
   
   
   1. Log in to the database tier node.
      
      
   2. Run AutoConfig on the database tier by running the following command:
      
      For UNIX:
      
      $ <RDBMS_OH>/appsutil/scripts/<CONTEXT_NAME>/adautocfg.sh
      For Windows:
      
      C:>\ <RDBMS_OH>\appsutil\scripts\<CONTEXT_NAME>\adautocfg.cmd
      This step is required to sync-up the tcp.invited_nodes attribute in sqlnet.ora to remove the deleted node from the value of this attribute.
       
   3. Restart the database listener by running the following command:
       
      For UNIX:
      $ sh <RDBMS_OH>/appsutil/scripts/<CONTEXT_NAME>/addlnctl.sh stop <ORACLE_SID>
$ sh <RDBMS_OH>/appsutil/scripts/<CONTEXT_NAME>/addlnctl.sh start <ORACLE_SID>
      For Windows:
      C:\> <RDBMS_OH>\appsutil\scripts\<CONTEXT_NAME>\addlnctl.cmd stop <ORACLE_SID>
C:\> <RDBMS_OH>\appsutil\scripts\<CONTEXT_NAME>\addlnctl.cmd start <ORACLE_SID>

Notes:

• Using the ebs-delete-node option as mentioned above will not delete the contents of the file system. This has to be done manually by the customer once the above steps to delete the node are completed successfully.
  
  For non-shared node, the following directories can be deleted:
  
  
  • <NE_BASE>
  • <RUN_BASE>
  • <PATCH_BASE>
  • EBSapps.env
  
  For a shared file system node, only the <INST_TOP> directory of the Run Edition File System and the Patch Edition File System should be deleted.
  
  
• On all OHS enabled nodes, patch file system OHS configuration will automatically be synced up during next adop prepare phase.

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

Post Clone Steps on EBS Environment

 Post Clone Steps on EBS Environment

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

1) Drop the Private Database link using apps user( ie these db link names are depend on your environment, just for example)

drop database link XXTEST.NIZAMAPPSDBA.COM;

drop database link XXTEST1.NIZAMAPPSDBA.COM;

2) Drop the Private Database link using sys user( ie these db link names are depend on your environment, just for example)

exec dropschema_dblinks('NIZAMAPPSDBA);

exec dropschema_dblinks('APPS');

3) Update the Worflow tables and FND table on Clone Environment(depend on your environment, just for example below)

Update apps.wf_systems (This should show the target Instance and not the source Instance)

select name,display_name from apps.wf_systems;

update apps.wf_systems set name=’<SID>’,display_name=’ <SID>.<hostname.domainname>’;

COMMIT;

eg: update apps.wf_systems set name='TEST.NIZAMAPPSDBA.COM',display_name='TEST.AU123.NIZAMAPPSDBA.COM’;

update apps.wf_systems set name='UATTEST.NIZAMAPPSDBA.COM',display_name='UATEST.DX123.NIZAMAPPSDBA.COM’;

UPDATE wf_notifications SET status ='CLOSED',mail_status ='SENT', end_date ='26-JAN-16' WHERE mail_status in ('MAIL','INVALID','OPEN');

update wf_agents set address = replace (address,'PROD','DEV') ;

eg: update wf_agents set address = replace (address,'HRD','TEST') ;

update wf_agents set address = replace (address,'HRD','UATTEST') ;

select name ,display_name from wf_systems;

update wf_systems set DISPLAY_NAME = replace (DISPLAY_NAME,'PROD.DBALOUNGE.COM','DEV.DBALOUNGE.COM');

eg:update wf_systems set DISPLAY_NAME = replace (DISPLAY_NAME,'PROD.NIZAMAPPSDBA.COM','TEST.NIZAMAPPSDBA.COM'); 

   update wf_systems set DISPLAY_NAME = replace (DISPLAY_NAME,'PROD.NIZAMAPPSDBA.COM','UATTEST.NIZAMAPPSDBA.COM'); 

Commit;

Update the target node in CM fnd_concurrent_queues table using below post_clone.sql script. values will be different and it is based on our environment

WHENEVER SQLERROR EXIT FAILURE

WHENEVER OSERROR EXIT FAILURE

SET echo OFF

SET linesize 150

set verify off

SET show OFF

define Backup_date = "&Backup_Date"

UPDATE fnd_profile_option_values

SET profile_option_value = 'Production Copy '||'&BACKUP_DATE'

WHERE profile_option_id=125;

UPDATE fnd_concurrent_queues

SET node_name='TEST1243'

WHERE node_name in('PROD252','PROD253','PROD214','PROD215','PROD258','PROD259','PROD250','PROD251');

UPDATE fnd_concurrent_queues

SET node_name2='TEST1243'

WHERE node_name2 in('PROD252','PROD253','PROD214','PROD215','PROD258','PROD259','PROD250','PROD251');

UPDATE fnd_concurrent_queues

SET node_name2='TEST1243'

WHERE node_name2 in('PROD252','PROD253','PROD214','PROD215','PROD258','PROD259','PROD250','PROD251');

UPDATE fnd_concurrent_queues

SET target_node='TEST1243'

WHERE target_node in('PROD252','PROD253','PROD214','PROD215','PROD258','PROD259','PROD250','PROD251');

UPDATE fnd_concurrent_queues

SET target_node='TEST1243'

WHERE target_node in('PROD252','PROD253','PROD214','PROD215','PROD258','PROD259','PROD250','PROD251');

commit;

4) Cleaning the Clone Setup and Change the password in Clone Environment

FNDCPASS apps/****** 0 Y system/**** SYSTEM APPLSYS apps

FNDCPASS apps/***** 0 Y system/****** USER sysadmin Welcome123456789

perl $FND_TOP/patch/115/bin/txkManageDBConnectionPool.pl

exec FND_CONC_CLONE.SETUP_CLEAN;

Run cmclean.sql

1. Change the value for context variables s_url_protocol, s_local_url_protocol,s_webentryurlprotocol in context file from https to http. 

3. Change the value of s_help_web_agent, s_login_page, s_external_url context variables to point to http url and the port in the url refers to s_webport.

4. Change the value of s_enable_sslterminator to -  <sslterminator oa_var="s_enable_sslterminator">#</sslterminator>  

AUTOCONFIG

-----------

Run adautocfg.sql in DB and Apps Tier

$FND_TOP/bin/txkrun.pl -script=SetSSOReg -removereferences=yes -appspass=apps

Run adautocfg.pl in DB and Apps Tier

Start the application services.

5) Profile change if SSO to disabled on Clone Environment

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

Application Authenticate Agent to NULL

Applications SSO Type to SSWA

Applications SSO Login Types to Local

Applications Single Sign On Hint Cookie Name to ORASSO_AUTH_HINT

Application SSO LDAP Synchronization to NULL

Applications SSO Auto Link User to NULL

Applications SSO User Creation and Updation Allowed to NULL

 

6) Disable_concurrent_request on Clone Environment

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

update fnd_concurrent_requests

set phase_code = 'C', status_code = 'X'

where status_code in ('Q','I','P','R')

and requested_start_date > SYSDATE

and hold_flag = 'N';

update fnd_concurrent_requests

set phase_code = 'C', status_code = 'X'

where requested_start_date > SYSDATE

and hold_flag = 'N';

update fnd_concurrent_requests

set phase_code = 'C', status_code = 'X';

define Backup_date = "&Backup_Date"

UPDATE fnd_profile_option_values

SET profile_option_value = 'Production Copy '||'&BACKUP_DATE'

WHERE profile_option_id=125;

7) Data Masking on Clone Environment, ie it depend on the evironment and organization requirement

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

login to database using HR schema, run below scripts

create table Per_all_people_f_nomask as select *from Per_all_people_f;

update Per_all_people_f

set full_name=dbms_random.string('U', 20),

first_name=dbms_random.string('U', 20),

last_name=dbms_random.string('U', 20),

middle_names=dbms_random.string('U', 20),

global_name=dbms_random.string('U', 20),

local_name=dbms_random.string('U', 20);

create table per_phones_nomask as select *from per_phones; 

update per_phones

set phone_number=trunc(dbms_random.value(1000000000,9999999999));

create table per_analysis_criteria_no_mask as select *from per_analysis_criteria; 

update per_analysis_criteria

set segment1=trunc(dbms_random.value(1000000000,9999999999)),

segment5=trunc(dbms_random.value(1000000000,9999999999)),

segment6=trunc(dbms_random.value(1000000000,9999999999));