Tuesday, September 17, 2019

Linux command cheat sheet


at No comments:

FlashGrid Reference Architecture and Deployment Guide for Highly Available Oracle E-Business Suite in AWS

https://www.flashgrid.io/wp-content/sideuploads/resources/FlashGrid_EBS_AWS_RefArchDeploymentGuide.pdf


https://www.kb.flashgrid.io/


© 2018 FlashGrid Inc. FlashGrid Reference Architecture and Deployment Guide for Highly Available Oracle E-Business Suite in AWS rev. 18.06-2018.07.25 © 2018 FlashGrid Inc. 2 Table of Contents 1 Introduction .................................................................................................................................................................... 3 2 Architecture Highlights ................................................................................................................................................... 3 3 Supported Cluster Configurations................................................................................................................................... 4 4 Compatibility................................................................................................................................................................... 4 5 Deployment Steps........................................................................................................................................................... 4 5.1 Getting Access to FlashGrid AMI............................................................................................................................. 4 5.2 Uploading Oracle Installation Files to S3 ................................................................................................................ 4 5.3 Preparing the VPC ................................................................................................................................................... 5 5.4 Creating cluster with CloudFormation.................................................................................................................... 6 5.5 Verifying cluster health........................................................................................................................................... 7 5.6 OS User Accounts.................................................................................................................................................... 7 5.7 Changing ASM passwords....................................................................................................................................... 8 5.8 Preparing DB Nodes for EBS Installation................................................................................................................. 8 5.9 Preparing App Nodes for EBS Installation............................................................................................................... 9 5.10 Opening Network Access between App and DB Nodes........................................................................................10 5.11 Downloading EBS software ...................................................................................................................................10 5.12 Installing EBS Database Tier..................................................................................................................................12 5.13 Installing EBS APP Tier...........................................................................................................................................25 5.14 Adding a node to APP Tier ....................................................................................................................................28 5.15 Configuring TNS parameters on APP Tier .............................................................................................................29 5.16 Enabling Strict Read-Local Mode for a New Database .........................................................................................30 5.17 Enabling instance termination protection ............................................................................................................30 6 Uninstalling EBS software .............................................................................................................................................31 6.1 Uninstalling APP Tier.............................................................................................................................................31 6.2 Uninstalling DB Tier...............................................................................................................................................31 7 Monitoring Cluster Health ............................................................................................................................................31 8 Deleting a cluster ..........................................................................................................................................................32 9 Additional Information..................................................................................................................................................32 10 Contacting FlashGrid Technical Support.......................................................................................................................33 © 2018 FlashGrid Inc. 3 1 Introduction Running highly available Oracle E-Business Suite in AWS requires having the database tier based on Oracle Real Application Clusters (RAC). FlashGrid Cloud Area Network software and FlashGrid Storage Fabric software enable running Oracle RAC clusters in AWS cloud. FlashGrid Cloud Provisioning simplifies the deployment process by automating configuration of multiple components required for an Oracle RAC cluster, including Grid Infrastructure. Oracle RAC has the following infrastructure requirements that are not directly available in AWS:  Shared high-performance storage accessible from all database nodes  Multicast enabled network between all database nodes  Separate networks for different types of traffic: client, cluster interconnect, and storage FlashGrid Storage Fabric™ and FlashGrid Cloud Area Network™ software address these requirements and enable running highly available Oracle E-Business Suite clusters with Oracle RAC database in AWS. This document provides architectural overview of the solution and step-by-step instructions for system and database administrators deploying Oracle E-Business Suite in AWS. Additional information about running Oracle RAC in AWS is available in the following white paper: “Mission-Critical Databases in the Cloud. Oracle RAC on Amazon EC2 Enabled by FlashGrid®.” 2 Architecture Highlights  FlashGrid Cloud Area Network™ enables high-speed overlay networks with multicast and virtual IP support for transparent connectivity between the database and app tier nodes.  FlashGrid Storage Fabric turns local drives (elastic block storage or local instance-store SSDs) into shared drives accessible from all nodes in the cluster  FlashGrid Read‑Local™ Technology minimizes network overhead by serving reads from local drives  2-way or 3-way mirroring of data across separate nodes or Availability Zones  Oracle ASM and Clusterware provide data protection and availability Figure 1. EBS cluster with 2 DB nodes and 2 APP nodes. (Quorum node not shown) © 2018 FlashGrid Inc. 4 3 Supported Cluster Configurations The FlashGrid architecture enables variety of EBS cluster configurations in AWS. This document focuses on a configuration with two database nodes and two app tier nodes. However, the architecture can be extended to a larger number of nodes. Two or three node database tier clusters are recommended in most cases. Clusters with four or more database nodes can be used for extra HA or performance. Nodes of a cluster can be in one availability zone or can be spread across availability zones. 4 Compatibility The following versions of software are covered in this guide:  Oracle E-Business suite 12.2  Oracle Grid Infrastructure: ver. 12.2.0.1 with April'18 Release Update  Operating System: Oracle Linux 7  FlashGrid Storage Fabric: ver. 18.06  FlashGrid Cloud Area Network: ver. 18.03 The solution can be deployed on the following Amazon EC2 instance types: M4, M5, R4, i3, X1, X1E. 5 Deployment Steps 5.1 Getting Access to FlashGrid AMI To be able to create cluster your AWS account must have a subscription to a FlashGrid AMI via AWS Marketplace. FlashGrid AMIs are based on either Oracle Linux 7 or RHEL 7. Please contact your FlashGrid representative if you need to customize the AMI. To get access to the FlashGrid AMI 1. Open FlashGrid product page at AWS Marketplace 2. Click Continue button 3. Select Manual Launch tab 4. Click Accept Software Terms button 5.2 Uploading Oracle Installation Files to S3 During cluster provisioning Oracle installation files will be downloaded from an S3 bucket. The following files must be placed in the S3 bucket:  oracle-instantclient12.2-basic-12.2.0.1.0-1.x86_64.rpm  linuxx64_12201_grid_home.zip  p27468969_122010_Linux-x86-64.zip (GI APR 2018 RELEASE UPDATE 12.2.0.1.180417. Requires Oracle support subscription.)  p6880880_122010_Linux-x86-64.zip (OPatch patch, Release: OPatch 12.2.0.1.0, Platform: Linux x86-64. Requires Oracle support subscription.) Two options are available for allowing access to the files in the S3 bucket for the cluster node instances:  Enabling public access to each file for the duration of cluster provisioning © 2018 FlashGrid Inc. 5 OR  Assigning the cluster node instances an IAM role that has permissions for accessing files in the bucket To allow public access to the files in S3 1. Create an S3 bucket/folder for uploading the installation files 2. Upload the required files to the S3 bucket/folder 3. In S3 Management Console navigate to the bucket and the folder to see the list of files 4. Select all files 5. Click More -> Make Public 6. You can disable public access after the cluster completes initialization To use an IAM role for access to the files in S3 1. Create an S3 bucket/folder for uploading the installation files 2. Upload the required files to the S3 bucket/folder 3. In IAM Management Console create a new policy named GetOracleFilesFromS3 that allows s3:GetObject action on all uploaded files. See an example below. 4. In IAM Management Console create a new role named GetOracleFilesFromS3 and attach the GetOracleFilesFromS3 policy to it. 5. Use the GetOracleFilesFromS3 role when configuring cluster parameters in the FlashGrid Cloud Provisioning tool. Example of an IAM policy: { "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1508867055000", "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::mybucket/mydirectory/*" ] } ] } 5.3 Preparing the VPC When creating a new cluster you have two options:  Automatically create a new VPC. This option is usually used for test clusters isolated in their own sandbox VPCs. A VPC will be created together with the required subnets, placement group(s), and security groups. By default the VPC will be created with CIDR 10.100.0.0/16  Create the cluster in an existing VPC. This option is used for majority of production deployments where other systems (e.g. app servers) share the same VPC as the cluster. You will need to provide the VPC ID in the Cloud Provisioning tool and subnet IDs and security group IDs in the CloudFormation Manager. If using an existing VPC then make sure that the following pre-requisites are met before creating a cluster: © 2018 FlashGrid Inc. 6  The VPC has a subnet in each of the availability zones used for the cluster nodes.  The VPC has an S3 endpoint configured (required unless public IPs can be enabled for access to S3)  The VPC has a security group with the following ports open for inbound traffic: o UDP ports 4801, 4802, 4803 between any members of the security group o TCP ports 1521, 1522, 1528 for SCAN and Local Listener access to the database nodes from app servers and other database clients. These are default port numbers that can be changed in the Cloud Provisioning tool. o TCP port 22 for SSH access to the cluster nodes o TCP port 5901 if you choose to use VNC for running Oracle tools in GUI mode  Create a Spread Placement Group that will be used for the VM instances. The use of the spread placement group is not required only if each VM is placed in a separate availability zone, e.g. 2 db nodes + 1 quorum node across three AZs, or 3 db nodes + 2 quorum nodes across five AZs. It is required in all other cases to guarantee that all nodes are running on separate physical hosts. 5.4 Creating cluster with CloudFormation The FlashGrid Cloud Provisioning tool simplifies provisioning of Oracle Grid Infrastructure cluster by automating the following tasks:  Creating and configuring EC2 VPC, subnets, security group (optional)  Creating EC2 instances for database, quorum, and app tier nodes  Creating EBS volumes  Installing and configuring FlashGrid Cloud Area Network  Installing and configuring FlashGrid Storage Fabric  Installing and patching Oracle Grid Infrastructure software  Configuring Grid Infrastructure cluster  Creating ASM disk groups To create a cluster 7. Log in to AWS Management Console with a user account that has the following privileges:  AWSCloudFormationFullAccess  AmazonEC2FullAccess  AmazonVPCFullAccess (required only if creating a new VPC) 8. Open FlashGrid Cloud Provisioning tool for EBS: https://1806.cloudprov.flashgrid.io/upload?s3_file=18.06/AWS-2nodes-for-EBS-Marketplace.cfg 9. Configure parameters of the cluster 10. Click Verify button 11. If verification passes then click Create Cluster button, which will take you to AWS CloudFormation Manager 12. Click Next 13. Select your SSH key 14. If using an existing VPC, then select a spread placement group, subnet(s), and security group. 15. Click Next 16. Click Next (if you added tags at the cluster configuration page then do not add the same tags in CloudFormation Manager) 17. Click Create 18. Wait until the status of the stack changes to CREATE_COMPLETE 19. If creating the stack fails: a) Check for the cause of the failure on the Events tab b) Correct the cause of the error c) Delete the failed stack © 2018 FlashGrid Inc. 7 d) Repeat the steps for creating a new stack 20. Get IP addresses of the newly launched instances on the Outputs tab 21. SSH to the first (as it was specified on the cluster configuration page) cluster node as user fg@ 22. If the cluster initialization is still in progress or failed then you will see a corresponding welcome message. If there is no welcome message then the cluster initialization has completed successfully. 23. Wait for cluster initialization (including Oracle software installation and configuration) to complete. You will receive a broadcast message when initialization completes or fails. Cluster initialization takes approximately 90 minutes. 5.5 Verifying cluster health On any of the cluster nodes run flashgrid-cluster command to verify that the cluster status is Good and all checks are passing. [fg@rac1 ~]$ flashgrid-cluster FlashGrid 18.06.29.46032 #95f2b5603f206af26482ac82386b1268b283fc3c License: via Marketplace Subscription Support plan: 24x7 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ FlashGrid running: OK Clocks check: OK Configuration check: OK Network check: OK Querying nodes: quorum, rac1, rac2 ... Cluster Name: myrac Cluster status: Good -------------------------------------------------------------- Node Status ASM_Node Storage_Node Quorum_Node Failgroup -------------------------------------------------------------- rac1 Good Yes Yes No RAC1 rac2 Good Yes Yes No RAC2 racq Good No No Yes QUORUM -------------------------------------------------------------- -------------------------------------------------------------------------------------------------------- GroupName Status Mounted Type TotalMiB FreeMiB OfflineDisks LostDisks Resync ReadLocal Vote -------------------------------------------------------------------------------------------------------- GRID Good AllNodes NORMAL 12588 3376 0 0 No Enabled 3/3 DATA Good AllNodes NORMAL 2048000 2048000 0 0 No Enabled None FRA Good AllNodes NORMAL 1024000 1024000 0 0 No Enabled None -------------------------------------------------------------------------------------------------------- 5.6 OS User Accounts During cluster initialization the following OS user accounts are created:  fg - the user account used to SSH to the VMs with the SSH key that was selected when creating the cluster configuration. It can also be used for running FlashGrid Storage Fabric or FlashGrid Cloud Area Network utilities. The user fg has sudo rights.  grid - Grid Infrastructure owner. GI environment variables are preconfigured.  oracle - Database home owner. Database environment variables, except ORACLE_SID and ORACLE_UNQNAME, are preconfigured. After creating a database you can configure ORACLE_SID and ORACLE_UNQNAME by editing /home/oracle/.bashrc file on each database node. Note that no passwords are configured for any users. Also password-based SSH authentication is disabled in /etc/ssh/sshd_config. Key-based authentication is recommended for better security. Creating passwords for any user is not recommended. © 2018 FlashGrid Inc. 8 User fg has sudo rights and allows switching to any other user without requiring a password (which is not configured by default). Example: $ sudo su - grid Users fg, grid, and oracle have key-based SSH access configured between the nodes of the cluster. The corresponding key pairs are generated automatically during cluster initialization. For example, if you are logged in to node1 as user fg then you can SSH into node2 by simply running 'ssh node2' without entering a password or providing a key. 5.7 Changing ASM passwords A temporary password for ASM users SYS and ASMSNMP is configured during cluster initialization. The temporary password is "MyPassword2017". Use the following commands to set new password(s): $ sudo su - grid $ sqlplus / as sysasm SQL> alter user sys identified by "MyNewPassword"; SQL> alter user asmsnmp identified by "MyNewPassword"; 5.8 Preparing DB Nodes for EBS Installation Perform the following tasks on each of the database nodes. 1. Add entries in /etc/hosts corresponding to each database node's fg-pub IP (192.168.1.x subnet) and App node's VPC Private IP using the following format: [ip_address] [node_name].[domain_name] [node_name] Example: 192.168.1.1 rac1.example.com rac1 192.168.1.2 rac2.example.com rac2 10.100.100.101 app1.example.com app1 10.100.100.102 app2.example.com app2 2. Modify iptables  on DB node 1: -A PREROUTING -i eth0 -p tcp -m tcp --dport 1528 -j DNAT --to-destination 192.168.1.1  on DB node 2: -A PREROUTING -i eth0 -p tcp -m tcp --dport 1528 -j DNAT --to-destination 192.168.1.2 3. Restart iptables service: # systemctl restart iptables.service 4. Add one of the following lines to /etc/oratab file:  on DB node 1: +ASM1:/u01/app/12.2.0/grid:N  on DB node 2: +ASM2:/u01/app/12.2.0/grid:N 5. Install rpms for EBS: © 2018 FlashGrid Inc. 9 # yum install -y --enablerepo=ol7_addons oracle-ebs-server-R12-preinstall # ldconfig -v 6. Create a directory for EBS installation: # mkdir /ebs/Install # chown -R oracle:oinstall /ebs # chmod -R 775 /ebs 7. Modify the following entry in /etc/security/limits.conf: oracle hard memlock unlimited 8. On DB nodes only, add user oracle to asmadmin group: # usermod -a -G asmadmin oracle 5.9 Preparing App Nodes for EBS Installation 1. Launch App node instances using the same FlashGrid AMI used for the database nodes. Place the App nodes in the same VPC used for the DB nodes or in a peered VPC. 2. Add HOSTNAME, DOMAINNAME, and 'NOZEROCONF=yes' parameters in /etc/sysconfig/network. Example: # cat /etc/sysconfig/network HOSTNAME=app1 DOMAINNAME=example.com NOZEROCONF=yes 3. Add entries in /etc/hosts corresponding to each DB and App node's VPC Private IP using the following format: [ip_address] [node_name].[domain_name] [node_name] Example: 10.100.0.1 rac1.example.com rac1 10.100.0.2 rac2.example.com rac2 10.100.0.101 app1.example.com app1 10.100.0.102 app2.example.com app2 4. Add records on the DNS servers used by the App nodes On the DNS server(s) used by clients, for each database node add two records resolving to the VPC Private IP address of the node VM:  Hostname of the database node  SCAN address Example for a 2-node cluster: rac1.example.com 10.100.0.1 rac2.example.com 10.100.0.2 © 2018 FlashGrid Inc. 10 myrac-scan.example.com 10.100.0.1 myrac-scan.example.com 10.100.0.2 5. Install rpms for EBS: # yum install -y --enablerepo=ol7_addons oracle-ebs-server-R12-preinstall # ldconfig -v 6. On APP nodes only, add 300G size disk and create a filesystem for EBS installation: # pvcreate /dev/xvdz # vgcreate ebs_vg /dev/xvdz # lvcreate -l 100%FREE ebs_vg # mkfs -t ext4 /dev/ebs_vg/lvol0 # mkdir /ebs # mount /dev/ebs_vg/lvol0 /ebs 7. On APP nodes only, add mount point in /etc/fstab: /dev/ebs_vg/lvol0 /ebs ext4 defaults 0 0 8. Create a directory for EBS installation: # mkdir /ebs/Install # chown -R oracle:oinstall /ebs # chmod -R 775 /ebs 5.10 Opening Network Access between App and DB Nodes 1. Make sure that ICMP traffic is open between DB and App servers in the corresponding AWS security group settings. 2. Make sure TCP ports 1521, 1522, and 1528 are open from App to DB servers in the corresponding AWS security group settings. 5.11 Downloading EBS software 1. Open https://edelivery.oracle.com/: 2. In search box enter: "Oracle E-Business Suite 12.2.7.0.0" 3. Select the required components, select Linux x86_64 platform, and click Continue: © 2018 FlashGrid Inc. 11 4. Agree to the license terms and continue: 5. Click on WGET options: 6. Click Download .sh button in the popup window: 1. Place the wget.sh file in /ebs/Install directory on the first DB node (e.g. rac1) and on the first App node (e.g. app1) and run it to download the files using your Oracle account: # chmod 777 /ebs/Install/wget.sh # chown -R oracle:oinstall /ebs # sudo su - oracle $ cd /ebs/Install $ ./wget.sh SSO User Name:myname@mycompany.com SSO Password: Note: After entering password, press Enter twice. © 2018 FlashGrid Inc. 12 2. When download is finished, unzip parts of StartHere CD on the first database node and the first app node. Names of zip files that contain startCD can be identified from the download page: $ cd /ebs/Install $ unzip V100052-01_"*".zip $ chmod -R 777 /ebs/Install 5.12 Installing EBS Database Tier 5.12.1 Create stage area on the first database node (e.g. rac1) [oracle@rac1 ~]$ cd /ebs/Install/startCD/Disk1/rapidwiz/bin/ [oracle@rac1 ~]$ ./buildStage.sh Press Enter to continue... Build Stage Menu ------------------------------------------------------ 1. Create new stage area 2. Copy patches to existing stage area 3. List files in TechPatches directory 4. Exit menu Enter your choice [4]: 1 Rapid Install Platform Menu ------------------------------------------------------ 1. Oracle Solaris SPARC (64-bit) 2. Linux x86 (64-bit) 3. IBM AIX on Power Systems (64-bit) 4. HP-UX Itanium 5. Exit Menu Enter your choice [5]: 2 Running command: … Specify the directory containing the zipped installation media: /ebs/Install … ------------------------------------------------------ 1. Create new stage area 2. Copy patches to existing stage area 3. List files in TechPatches directory 4. Exit menu Enter your choice [4]: 4 © 2018 FlashGrid Inc. 13 5.12.2 Patch adrun12c.sh script According to Doc 2041374.1, Grid Infrastructure version 12.1 has the bug 16875041 when using connection pooling. As a result, during the installation script adrun12c.sh hangs waiting for the following command to complete: sh -c "asmcmd ls $DATAFILES" To avoid this bug during the installation, backup and patch the adrun12c.sh script on the first database node (e.g. rac1): $ cp /ebs/Install/startCD/Disk1/rapidwiz/template/adrun12c.sh /ebs/Install/startCD/Disk1/rapidwiz/template/adrun12c_backup.sh $ sed -i -e 's/asmcmd/asmcmd --nocp/g' /ebs/Install/startCD/Disk1/rapidwiz/template/adrun12c.sh 5.12.3 Patch rapidwiz template file to avoid NTP check error CHRONYD service is installed instead of NTPD for NTP synchronization. This patch prevents NTP check failure. # cp /ebs/Install/startCD/Disk1/rapidwiz/TechInstallers/DBInstallHome/fnd/admin/template/txkCfgDB12cR1_tmpl.xml /ebs/Install/startCD/Disk1/rapidwiz/TechInstallers/DBInstallHome/fnd/admin/template/txkCfgDB12cR1_tmpl_backup.xml # sed -i -e 's/ignoreSysPrereqs/ignoreSysPrereqs -ignorePrereq/g' /ebs/Install/startCD/Disk1/rapidwiz/TechInstallers/DBInstallHome/fnd/admin/template/txkCfgDB12cR1_tmpl.xml 5.12.4 Run rapidwiz Configure X11 Forwarding, run rapidwiz on the first database node (e.g. rac1), and select options according to the screenshots below: [oracle@rac1~]$ /ebs/Install/startCD/Disk1/rapidwiz/rapidwiz © 2018 FlashGrid Inc. 14 © 2018 FlashGrid Inc. 15 Note: At the port selection screen check that the database port (in our case 1528) is available on each DB node. The following command must return empty results on each DB node: # netstat -nltp|grep 1528 © 2018 FlashGrid Inc. 16 © 2018 FlashGrid Inc. 17 © 2018 FlashGrid Inc. 18 © 2018 FlashGrid Inc. 19 Fill Application Tier details: © 2018 FlashGrid Inc. 20 © 2018 FlashGrid Inc. 21 © 2018 FlashGrid Inc. 22 © 2018 FlashGrid Inc. 23 5.12.5 Configure LOCAL_LISTENER parameter On each DB node, create IFILE that is indicated at the end of /tnsnames.ora and add NODEFQDN entry. DB node 1: $ . /ebs/oracle/PROD/12.1.0/PROD1_rac1.env $ cat $TNS_ADMIN/tnsnames.ora |grep IFILE IFILE=/ebs/oracle/PROD/12.1.0/network/admin/PROD1_rac1/PROD1_rac1_ifile.ora $ vi $TNS_ADMIN/PROD1_rac1_ifile.ora DONOTDELETE,NODEFQDN = (ADDRESS = (PROTOCOL = TCP)(Host = rac1.example.com)(Port = 1528)) Set local_listener parameter: $ . /ebs/oracle/PROD/12.1.0/PROD1_rac1.env $ sqlplus / as sysdba SQL> ALTER SYSTEM SET LOCAL_LISTENER="NODEFQDN" scope=both sid='PROD1'; DB node 2: $ . /ebs/oracle/PROD/12.1.0/PROD2_rac2.env $ cat $TNS_ADMIN/tnsnames.ora |grep IFILE IFILE=/ebs/oracle/PROD/12.1.0/network/admin/PROD2_rac2/PROD2_rac2_ifile.ora © 2018 FlashGrid Inc. 24 $ vi $TNS_ADMIN/PROD2_rac2_ifile.ora DONOTDELETE,NODEFQDN = (ADDRESS = (PROTOCOL = TCP)(Host = rac2.example.com)(Port = 1528)) Set local_listener parameter: $ . /ebs/oracle/PROD/12.1.0/PROD2_rac1.env $ sqlplus / as sysdba SQL> ALTER SYSTEM SET LOCAL_LISTENER="NODEFQDN" scope=both sid='PROD2'; 5.12.6 Enable SCAN support: On each DB node, regenerate context file and run AutoConfig. DB node 1: $ . /ebs/oracle/PROD/12.1.0/PROD1_rac1.env $ /ebs/oracle/PROD/12.1.0/appsutil/bin/adbldxml.pl … Enter Database Service Name: PROD Do you want to enable SCAN addresses[N]:Y Specify value for s_scan_name[]: myebs-scan Specify value for s_scan_port[]:1521 Enter the value for Display Variable: localhost:1 … $ /ebs/oracle/PROD/12.1.0/appsutil/scripts/PROD1_rac1/adautocfg.sh DB node 2: $ . /ebs/oracle/PROD/12.1.0/PROD2_rac2.env $ /ebs/oracle/PROD/12.1.0/appsutil/bin/adbldxml.pl … Enter Database Service Name: PROD Do you want to enable SCAN addresses[N]:Y Specify value for s_scan_name[]: myebs-scan Specify value for s_scan_port[]:1521 Enter the value for Display Variable: localhost:1 … $ /ebs/oracle/PROD/12.1.0/appsutil/scripts/PROD2_rac2/adautocfg.sh Note: If the installation failed, because of some misconfiguration, you can re-run DB tier installation using saved configuration file without going through all the configuration steps again: © 2018 FlashGrid Inc. 25 1. Create copy of the configuration file: $ cp /ebs/oracle/PROD/12.1.0/appsutil/conf_PROD.txt /tmp/conf_PROD.txt 2. Clean up failed software, please see section 6. Uninstalling Software. 3. Rerun it as follows: [oracle@rac1 ~]$ /ebs/Install/startCD/Disk1/rapidwiz/rapidwiz -silent -config /tmp/conf_PROD.txt 5.13 Installing EBS APP Tier 5.13.1 Create stage area on the first app node (e.g. app1) [oracle@app1 ~]$cd /ebs/Install/startCD/Disk1/rapidwiz/bin/ [oracle@app1 ~]$./buildStage.sh Press Enter to continue... Build Stage Menu ------------------------------------------------------ 1. Create new stage area 2. Copy patches to existing stage area 3. List files in TechPatches directory 4. Exit menu Enter your choice [4]: 1 Rapid Install Platform Menu ------------------------------------------------------ 1. Oracle Solaris SPARC (64-bit) 2. Linux x86 (64-bit) 3. IBM AIX on Power Systems (64-bit) 4. HP-UX Itanium 5. Exit Menu Enter your choice [5]: 2 Running command: … Specify the directory containing the zipped installation media: /ebs/Install … ------------------------------------------------------ 1. Create new stage area 2. Copy patches to existing stage area 3. List files in TechPatches directory 4. Exit menu Enter your choice [4]: 4 5.13.2 Copy configuration from database node to the app node 1. Copy /ebs/oracle/PROD/12.1.0/appsutil/conf_PROD.txt from the first database node to /tmp on the first app node (e.g. app1). 2. Set necessary permissions for the copied file: [root@app1 tmp]# chmod a+r /tmp/conf_PROD.txt © 2018 FlashGrid Inc. 26 5.13.3 Add inventory location in /etc/oraInst.loc [root@app1 ~]# cat /etc/oraInst.loc inventory_loc=/ebs/oracle/oraInventory inst_group=oinstall Double-check that there is no extra space after "/ebs/oracle/oraInventory". 5.13.4 Run rapidwiz on the first App node: Configure X11 forwarding and run rapidwiz. [oracle@app1 ~]$ /ebs/Install/startCD/Disk1/rapidwiz/rapidwiz -silent -config /tmp/conf_PROD.txt 5.13.5 Log in to EBS 1. Find login URL at the end of the installation log file or by querying the EBS database: [oracle@rac1 ~]$ . /ebs/oracle/PROD/12.1.0/PROD1_rac1.env [oracle@rac1 ~]$ sqlplus apps/apps SQL> SELECT home_url FROM icx_parameters; HOME_URL ---------------------------------------------------------------------- http://app1.example.com:8007/OA_HTML/AppsLogin 2. Make sure port 8007 (TCP) is open via the EC2 security group settings. 3. Make sure the server address is resolvable from the client system by adding the app node servers to either the DNS server, or to /etc/hosts on the client. 4. Use the following default credentials: Username: SYSADMIN Password: SYSADMIN © 2018 FlashGrid Inc. 27 5.13.6 Start OPMN managed processes Before starting processes, some configuration files must be corrected: 1. Find remote port number [root@app1 ~]# cat /ebs/oracle/PROD/fs1/EBSapps/10.1.2/opmn/conf/opmn.xml | grep remote 2. Modify /ebs/oracle/PROD/fs1/EBSapps/10.1.2/opmn/conf/ons.conf as follows: nodes=: Example: nodes=app1.example.com:6001 3. Download and apply the patch 6078836 from My Oracle Support to fix an issue with the Oracle HTTP Server (missing libdb.so.2). Place libdb.so.2 in /usr/lib and set the necessary permissions: [root@app1 ~]# chmod 755 /usr/lib/libdb.so.2 4. Create the following soft link: [root@app1 ~]# ln -s /usr/lib/libdb-4.7.so /usr/lib/libdb-4.3.so 5. Change group name from autobldgrp to oinstall in httpd.conf file: [root@app1 ~]# sed -i -e 's/autobldgrp/oinstall/' /ebs/oracle/PROD/fs1/EBSapps/10.1.2/Apache/Apache/conf/httpd.conf 6. Change group name in webcache.conf file: [root@app1 ~]# sed -i -e 's/autobldgrp/oinstall/' /ebs/oracle/PROD/fs1/EBSapps/10.1.2/webcache/webcache.xml 7. Run autoconfig: © 2018 FlashGrid Inc. 28 [root@app1 ~]# su – oracle [oracle@app1 ~]$ /ebs/oracle/PROD/fs1/inst/apps/PROD_app1/admin/scripts/adautocfg.sh 8. In case vncserver is running, stop it to free up port 6001: [oracle@app1 ~]$ vncserver -kill :1 9. Start processes using opmnctl and check that the status is Alive for each component: [oracle@app1 ~]$/ebs/oracle/PROD/fs1/EBSapps/10.1.2/opmn/bin/opmnctl startall [oracle@app1 ~]$/ebs/oracle/PROD/fs1/EBSapps/10.1.2/opmn/bin/opmnctl startproc iascomponent=LogLoader [oracle@app1 ~]$/ebs/oracle/PROD/fs1/EBSapps/10.1.2/opmn/bin/opmnctl startproc iascomponent=dcm-daemon [oracle@app1 ~]$/ebs/oracle/PROD/fs1/EBSapps/10.1.2/opmn/bin/opmnctl status -------------------+--------------------+---------+--------- ias-component | process-type | pid | status -------------------+--------------------+---------+--------- LogLoader | logloaderd | 22250 | Alive HTTP_Server | HTTP_Server | 22113 | Alive dcm-daemon | dcm-daemon | 22286 | Alive WebCache | WebCache | 22129 | Alive WebCache | WebCacheAdmin | 22115 | Alive OC4J | home | 22116 | Alive 5.14 Adding a node to APP Tier This section provides high-level steps for adding a node to the App tier. For detailed instructions see Doc ID 1383621.1 Section 5.3 Adding a New Application Tier Node to an Existing System. 1. Follow 5.6 Configuring OS for EBS installation and 5.7 Configuring NTP service sections for preparing the new application node. 2. Apply the AD/TXK (Delta) patches on the source. 3. On DB nodes only, update the tcp.invited_nodes parameter in sqlnet.ora and add host.domain for the new node being added. For changes to take effect restart PROD listener. 4. On app2, add inventory location in /etc/oraInst.loc. 5. On app1, start admin server from Run and Patch Edition File Systems. 6. Run adpreclone.pl on Run and Patch Edition File Systems in the primary application tier node. 7. Setup SSH Key-Based Authentication between application nodes. 8. Copy the Run Edition File System to the target secondary node. Only the following directories should be copied: © 2018 FlashGrid Inc. 29 9. Execute adcfgclone.pl to clone both the Run and Patch file system. 10. Register the newly added application tier node with the application tier TNS listener. 11. If the Node Manager service is up on the Patch Edition File System of the newly added application tier node, shut it down. 12. Shut down the Admin Server and the Node Manager on the Patch Edition File System of the primary node. 13. Run AutoConfig on all database tier nodes to add the newly added node to the Access Control List. 14. Start services on application nodes. 15. Make sure the server address is resolvable from the client system by adding the app node servers to either the DNS server, or to /etc/hosts on the client. After adding new nodes, refer to My Oracle Support Knowledge Document 1375686.1, Using Load-Balancers with Oracle E-Business Suite Release 12.2, for details on how to set up load balancing. 5.15 Configuring TNS parameters on APP Tier The following parameters must be specified in the connect string:  TRANSPORT_CONNECT_TIMEOUT=3 The time, in seconds, for a client to establish a TCP connection to the database server. The default value is 60 seconds. It must be changed to avoid a long wait in case one of the database servers is down.  RETRY_COUNT=6 The number of connection attempts before the connection is terminated. Add new TNS alias that contains the above parameters in IFILE indicated at the end of $INST_TOP/ora/10.1.2/network/admin/tnsnames.ora: Example: $ . /ebs/oracle/PROD/fs1/EBSapps/appl/PROD_app1.env $ cat $INST_TOP/ora/10.1.2/network/admin/PROD_app1_ifile.ora PROD_BALANCE2= (DESCRIPTION=(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=6) (ADDRESS=(PROTOCOL=tcp)(HOST=myebs-scan.example.com)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=PROD) ) ) Update the following variables in application context file by the following way: $ . /ebs/oracle/PROD/fs1/EBSapps/appl/PROD_app1.env $ java oracle.apps.ad.context.UpdateContext $CONTEXT_FILE s_apps_jdbc_connect_alias PROD_BALANCE2 © 2018 FlashGrid Inc. 30 $ java oracle.apps.ad.context.UpdateContext $CONTEXT_FILE s_tools_twotask PROD_BALANCE2 $ java oracle.apps.ad.context.UpdateContext $CONTEXT_FILE s_weboh_twotask PROD_BALANCE2 $ java oracle.apps.ad.context.UpdateContext $CONTEXT_FILE s_cp_twotask PROD_BALANCE2 $ java oracle.apps.ad.context.UpdateContext $CONTEXT_FILE s_apps_jdbc_connect_descriptor "jdbc:oracle:thin:@(DESCRIPTION=(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=6)(ADDR ESS=(PROTOCOL=tcp)(HOST=myebsscan.example.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=PROD)))" $ java oracle.apps.ad.context.UpdateContext $CONTEXT_FILE s_jdbc_connect_descriptor_generation false Run AutoConfig: $ adautocfg.sh Restart App Tier services: $ adstpall.sh apps/apps Enter the WebLogic Server password: welcome1 $ adstrtal.sh apps/apps Enter the WebLogic Server password: welcome1 5.16 Enabling Strict Read-Local Mode for a New Database It is recommended that Strict Read-Local mode is enabled for every new database. ASM does not allow reads from disks that are resynchronizing data (SYNCING state) after being offline. As a result, if database is running on a node whose local disks are in SYNCING state, all reads will be performed remotely over the network. This may result in lower performance of the database instance on a node that has just rebooted and is still resynchronizing its data. Strict Read-Local mode prevents such performance asymmetry between nodes. When the Strict Read-Local mode is enabled, a database instance start will be delayed until its local disks complete resynchronization. Use the following commands to enable, disable, and show status of Strict Read-Local mode: $ flashgrid-cluster strict-read-local-enable $ flashgrid-cluster strict-read-local-disable $ flashgrid-cluster strict-read-local-show Note that enabling Strict Read-Local mode changes the setting only for existing databases. Re-running the enable command is required after creating new database(s). Note that in order to unmount a disk group while Strict Read-Local mode is enabled, srvctl stop diskgroup command with -force option must be used. Example: $ srvctl stop diskgroup -diskgroup DGNAME -node rac1,rac2 -force 5.17 Enabling instance termination protection It is strongly recommended to enable instance termination protection for all cluster nodes. © 2018 FlashGrid Inc. 31 6 Uninstalling EBS software 6.1 Uninstalling APP Tier Delete the software directory and restart the server: # rm -rf /ebs/oracle # reboot 6.2 Uninstalling DB Tier 1. On each DB node Delete the following home entries from /u01/app/oraInventory/ContentsXML/inventory.xml 2. On each DB node delete the software directory: # rm -rf /ebs/oracle # reboot 3. If +DATA/dbfiles and +DATA/PROD directories exist remove them by running the bellow command on the first database node: [oracle@rac1 ~]$ . oraenv ORACLE_SID = [+ASM1] ? +ASM1 [oracle@rac1 ~]$ asmcmd --nocp rm -rf +DATA/dbfiles [oracle@rac1 ~]$ asmcmd --nocp rm -rf +DATA/PROD 4. Remove PROD service if it exists. Run the following on the first database node: [oracle@rac1 ~]$ . oraenv ORACLE_SID = [+ASM1] ? +ASM1 [oracle@rac1 ~]$ srvctl remove database -db PROD Remove the database PROD? (y/[n]) y 7 Monitoring Cluster Health The following methods of monitoring cluster health are available:  The flashgrid-cluster utility displays status of the cluster and its main components.  Alerts about failures are recorded in system log and can be analyzed by 3rd -party tools.  Email alerts can be sent to one or several email addresses.  ASM disk group monitoring and alerting via Oracle Enterprise Manager. To test email alerts 1. On all nodes (including quorum node) run $ flashgrid-node test-alerts © 2018 FlashGrid Inc. 32 2. Check that test alert emails were received from all cluster nodes at each of the configured email addresses. To modify the list of email alert recipients As user fg@ on any database node run $ flashgrid-cluster set-email-alerts name1@host1 name2@host2 ... Note that by default the From address is set to flashgrid@localhost.localdomain. This will ensure that delivery failure notifications are sent to root's mailbox on the originating node, which can help with troubleshooting delivery issues. It is recommended to add this address to the whitelist of senders on the receiving email server and in the email clients. 8 Deleting a cluster To delete a cluster 1. Disable instance termination protection for all cluster nodes 2. Open AWS CloudFormation Manager console 3. Delete the stack corresponding to the cluster 9 Additional Information For additional information about deploying Oracle RAC in AWS see the following documents:  Whitepaper: Mission-Critical Databases in the Cloud. Oracle RAC on Amazon EC2 Enabled by FlashGrid® Software.  FlashGrid Provisioning and Maintenance Guide for Oracle RAC in AWS © 2018 FlashGrid Inc. 33 10 Contacting FlashGrid Technical Support For help with troubleshooting an issue on an existing FlashGrid cluster please use Technical Support Request form located at https://www.flashgrid.io/support/ To expedite troubleshooting please also collect diagnostic data by running ‘flashgrid-node collect-diags’ command on each node and upload it using a secure upload form provided to your company by FlashGrid technical support. Customers with Mission-Critical SLA subscription may also use the 24x7 telephone hotline for reporting critical issues that require immediate attention: +1-650-641-2421 ext 7 © 2018 FlashGrid Inc. 34 Copyright © 2018 FlashGrid Inc. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. FlashGrid is a registered trademark of FlashGrid Inc. Amazon and Amazon Web Services are registered trademarks of Amazon.com Inc. and Amazon Web Services Inc. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Red Hat is a registered trademark of Red Hat Inc. Other names may be trademarks of their respective owners.
at No comments:

Changing the Oracle WebLogic Server Administration User Password

The option to set the Oracle WebLogic Server Administration User password to a non-default value is available during Oracle E-Business Suite installation. This section describes the procedure to use (on the run file system) if you need to change the password at a later time.
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 Oracle WebLogic Server domain EBS_domain_<SID> (dedicated to Oracle E-Business Suite) 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.
By default, Oracle WebLogic Server used with Oracle E-Business Suite enforces the following password validation rules:
  • Minimum password length: 8
  • Minimum number of non-alphabetic characters, including numeric characters or special characters such as %, *, #, or }: 1
Important: If any provider-specific attributes have been changed for either the default WebLogic Authentication provider (DefaultAuthenticator) or the default Password Validation provider (SystemPasswordValidator), the new password must adhere to the above rules.
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.
For more information, see: "Changing the Administrative User Password" in Chapter 3 of Oracle Fusion Middleware Administrator's Guide 11g Release 1 (11.1.1).
  1. Shut down all application tier services except the Admin Server.
    1. 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
    Note: The above examples are for UNIX. If you are using Windows, employ the appropriate equivalent syntax.
  2. 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:
      • On UNIX, run the command:
        $ perl $FND_TOP/patch/115/bin/txkUpdateEBSDomain.pl -action=updateAdminPassword
      • On Windows, open a DOS command window and perform the following steps on the nodes directed:
        1. Run the following command on all nodes:
          C:\>perl %FND_TOP%\patch\115\bin\txkUpdateEBSDomain.pl -action=updateAdminPassword -allnodes=no
          Warning: Do not specify -allnodes=no on UNIX platforms.
        2. Run the following commands on the primary node only:
          C:\><ADMIN_SCRIPTS_HOME>\adadminsrvctl.cmd stop
C:\><ADMIN_SCRIPTS_HOME>\adnodemgrctl.cmd stop
        3. Start Node Manager by running the following commands on all nodes:
          C:\>cd %INST_TOP%\admin\install
C:\>adsvNodeManager.cmd
        4. When prompted, enter the new password you just set.
        5. Close the DOS command window.
  3. From a terminal window, start all services on all nodes using the appropriate command for your platform.
    • On UNIX, run the command:
      $ <ADMIN_SCRIPTS_HOME>/adstrtal.sh
    • On Windows run the command:
      C:\><ADMIN_SCRIPTS_HOME>\adstrtal.cmd
  4. You now need to perform an fs_clone operation to change the WebLogic EBS Domain password on the patch file system:
    1. Launch a new session and connect to the Oracle E-Business Suite instance.
    2. Source the application tier environment file.
    3. Run the following command:
      $ adop phase=fs_clone
If the Admin Password of an EBS WebLogic Domain is lost or forgotten
As noted earlier, the EBS WebLogic domain uses Node Manager to control startup of the AdminServer and Managed Servers. For the EBS WebLogic domain, the Node Manager and WebLogic AdminServer passwords must be same. If the passwords are different, the AD control scripts will not work properly.
If the AdminServer password has been lost or forgotten, it can be reset by carrying out the following steps on the run file system. As described in the final step, an fs_clone operation should then be performed to synchronize the run and patch file systems.
  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.
    1. Connect to the Oracle E-Business Suite instance and source the application tier environment file.
    2. 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"
    3. 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.
    Note: For certain servers, the boot.properties file may be present in only one location of the two specified above. In such a case, back it up and then delete it.
  3. Set up a new environment to change the WLS AdminServer password.
    1. Start a new session and connect to the Oracle E-Business Suite instance.
    2. Do not source the application tier environment file.
    3. Run the following command to source the WebLogic Server domain environment:
      $ cd <EBS_DOMAIN_HOME>/bin
$ source setDomainEnv.sh
    4. 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.
      Note: Do not omit the trailing period ('.') in the above command: it is needed to specify the current domain directory.
  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.
    1. Go to the EBS Domain Home:
      $ cd <EBS_DOMAIN_HOME>
    2. 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.
    1. Log in to the WebLogic Administration console.
    2. Click the 'Lock & Edit' button.
    3. In the left panel, click on the EBS Domain link.
    4. Select the 'Security' tab.
    5. Click on the 'Advanced' link.
    6. 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.
    7. 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.
    8. Save and activate the changes.
  6. The first time, AdminServer has to be stopped from the Admin console. Follow these steps:
    1. Log in to the WebLogic Administration console.
    2. 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.
    1. Launch a new session and connect to the Oracle E-Business Suite instance.
    2. Source the application tier environment file.
    3. 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:
    1. Log in to the WebLogic Server Administration Console.
    2. 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:
    1. Log in to the WebLogic AdminServer console.
    2. Shut down all Managed Servers.
    3. 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 Server name>/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 Server name>/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:
    1. Launch a new session and connect to the Oracle E-Business Suite instance.
    2. Source the application tier environment file.
    3. Run the following command:
      $ adop phase=fs_clone

Known Issues


For the most current list of known issues with the AutoConfig-related configuration management of Oracle E-Business Suite Release 12.2 environments, see My Oracle Support Knowledge Document, 1905593.1, Managing Configuration of Oracle HTTP Server and Web Application Services in Oracle E-Business Suite Release 12.2.
at No comments:

Managing Configuration of Oracle HTTP Server and Web Application Services in Oracle E-Business Suite Release 12.2 (Doc ID 1905593.1)

This document provides an overview of configuration management of Oracle HTTP Server and web applications in Oracle E-Business Suite Release 12.2. It also lists the known issues in configuration management. The most current version of this document can be obtained in My Oracle Support Knowledge Document 1905593.1, Managing Configuration of Oracle HTTP Server and Web Application Services in Release 12.2, by Oracle E-Business Suite Development.
A change log is available at the end of this document.

In This Document

This document is divided into the following sections:

Section 1: Overview

Prior to Oracle E-Business Suite Release 12.2, AutoConfig managed all Oracle HTTP Server configuration files throughout the system lifecycle. In Release 12.2, AutoConfig is only involved in the initial setup of the Oracle HTTP Server configuration files. Later, it can optionally be used to manage and customize a limited set of Oracle HTTP Server configuration files. Otherwise, as described in this document, native Oracle WebLogic Server and Fusion Middleware tools are used to manage these files.
In Oracle E-Business Suite Release 12, the oacore, oafm, forms and forms-c4ws services were deployed as applications on OC4J instances and were managed by Oracle Process Manager (OPMN). Because Oracle WebLogic Server has replaced OC4J in Oracle E-Business Suite Release 12.2, these services are now deployed as applications on individual managed servers. Consequently, only part of the configuration of these applications and managed servers is still managed via AutoConfig. This document describes those areas that remain managed by AutoConfig and those that are not.
Note: You are strongly encouraged to be on the latest AD/TXK codelevel. Refer to My Oracle Support Knowledge Document 1583092.1, Oracle E-Business Suite Release 12.2: Suite-Wide Rollup and AD/TXK Delta Information, and apply the most recent delta patches.

It is important to read the release notes for those patches, since they may require other patches. Refer to My Oracle Support Knowledge Document 1617461.1, Applying the Latest AD and TXK Release Update Packs to Oracle E-Business Suite Release 12.2.
The instructions in this document are applicable only for AD/TXK Delta 4 codelevel and higher which is the minimum supported codelevel for AD/TXK at this time.

Section 2: Tools for Configuration Synchronization

In Oracle E-Business Suite Release 12.2, some Oracle HTTP Server configurations and WebLogic configurations are managed via AutoConfig while some are managed natively via Fusion Middleware Control and WebLogic Server Administration Console. A new mechanism has been introduced to keep the context variables and the OHS configuration parameters (where applicable) in synchronization. This mechanism is called the 'feedback loop'.
Following tools are used for performing this synchronization:
Script NameLocationPurpose
adRegisterWLSListeners.plOn Applications Tier:
<AD_TOP>/bin		This script is used to listen to changes to the WebLogic Server configuration parameters and update the context variables accordingly.
Note: This script is not able to synchronize changes to Oracle HTTP Server configuration.
adSyncContext.plOn Applications Tier:
<AD_TOP>/bin		This script is used to explicitly pull the values of the WebLogic Server and Oracle HTTP Server configuration parameters and synchronize the corresponding context variable values accordingly.

2.1 Run adRegisterWLSListeners Tool on the Application Tier

As noted previously, some Oracle E-Business Suite Release 12.2 configurations are managed via AutoConfig, and some are managed natively via Fusion Middleware Control or Oracle WebLogic Server Administration Console.
The adRegisterWLSListeners tool performs automatic synchronization of context variables with the corresponding Oracle WebLogic Server configuration parameters.
Note: This tool does not listen for changes to the Oracle HTTP Server configuration parameters.
On UNIX instances, the tool is started automatically on the primary node whenever WebLogic Administration Server is started.
On Windows instances, the tool needs to be explicitly started up on the primary node every time WebLogic Administration Server is started up.
Execute the following command to start adRegisterWLSListeners.pl:
$ perl <AD_TOP>/bin/adRegisterWLSListeners.pl contextfile=<CONTEXT_FILE>
Once started, adRegisterWLSListeners keeps running, listening for changes to the WebLogic Server configuration and synchronizing the context files stored in the database. The tool automatically stops when WebLogic Administration Server is shut down.

2.2 Run SyncContext on the Application Tier

The SyncContext tool is used for explicit synchronization of the context variables with the WebLogic Server and Oracle HTTP Server configurations.
It differs from adRegisterWLSListeners.pl in that it is able to synchronize the context file with the Oracle HTTP Server configuration changes as well.
Execute the following command to run adSyncContext.pl on a respective Application tier node.
$ perl <AD_TOP>/bin/adSyncContext.pl contextfile=<CONTEXT_FILE>
Note: The Node Manager and the WebLogic AdminServer must be running during execution of adSyncContext.pl.

Section 3: Managing Configuration of Oracle HTTP Server

As mentioned in Section 1, AutoConfig manages only a limited set of Oracle HTTP Server Configuration files in Release 12.2. Most Oracle HTTP Server configuration files are now managed via native Oracle WebLogic Server and Fusion Middleware tools.

3.1 Updating AutoConfig-Managed Oracle HTTP Server Configurations

The table below shows the Oracle HTTP Server configuration templates that are managed by AutoConfig in Oracle E-Business Suite Release 12.2. The configurations defined in these files can be customized by customizing the templates.
Template NameConfiguration File
ssl_terminator_conf_FMW.tmpssl_terminator.conf
trusted_conf_FMW.tmptrusted.conf
oracle_apache_conf_FMW.tmporacle_apache.conf
oracle_apache_ssl_conf_FMW.tmporacle_apache_ssl.conf
url_fw_conf_FMW.tmpurl_fw.conf
url_fw_ws_conf_FMW.tmpurl_fw_ws.conf
security2_dmz_conf_FMW.tmpsecurity2_dmz.conf
security2_conf_FMW.tmpsecurity2.conf
security2_conf_FMW_nt.tmpsecurity2.conf
custom_conf_FMW.tmpcustom.conf
webgate_conf_FMW.tmpwebgate.conf


Note: For more information regarding customization of AutoConfig templates, refer to Chapter 3: Technical Configuration in Oracle E-Business Suite Setup Guide for Release 12.2.

3.2 Updating Seeded Oracle HTTP Server Configurations

During creation of the Oracle HTTP Server instance, AutoConfig performs the first instantiation of configuration files such as httpd.conf and mod_wl_ohs.conf. After the installation or upgrade to Release 12.2 is complete, seeded Oracle HTTP Server configurations are generally managed via Fusion Middleware Control. In certain specific cases, however, manual editing of the configuration files may be needed: this will be advised separately where required.
Note: For further information, refer to Section 3.3: Getting Started Using Oracle Enterprise Manager Fusion Middleware Control in Oracle Fusion Middleware Administrator's Guide. This book can be found in the Oracle Fusion Middleware Documentation Library.
When modifying Oracle HTTP Server protocols or port numbers, these values must be updated in both the context file as well as in the configuration files. This is to ensure that the new values are updated in the AutoConfig-managed database profile values as well.
To modify HTTP server protocols or port numbers, perform the following steps on the run file system:
  1. Login to Oracle Fusion Middleware Control Console.
  2. Select Web Tier Target under EBS Domain.
  3. Select Administation > Advanced Configuration.
  4. Edit the relevant file to update the respective HTTP configuration parameter value.
  5. Run the following command on all application tier nodes:
    $ perl <AD_TOP>/bin/adSyncContext.pl contextfile=<CONTEXT_FILE>
  6. Run AutoConfig on all application tier nodes.
  7. Restart HTTP services by executing the following command on the run file system:

    On UNIX:
    $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop
    $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start
    On Windows:
    C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd stop
    C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd start

3.3 Running Oracle HTTP Server on a Privileged Port

On a UNIX system, the TCP/IP port numbers below 1024 are special in that only processes with root privileges are allowed to listen on those ports. If you wish to configure Oracle HTTP Server to run on a privileged port, you must first edit the HTTP port as specified in Section 3.2 and then perform the following additional steps to enable Oracle HTTP Server to run as root. These steps are required for both SSL and non-SSL privileged ports.
  1. Execute the following commands as the root user on both the run file system and the patch file system.
    $ chown root <FMW_HOME>/webtier/ohs/bin/.apachectl
    $ chmod 6750 <FMW_HOME>/webtier/ohs/bin/.apachectl
  2. Restart HTTP services by executing the following command on the run file system:

    On UNIX:
    $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop
    $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start
    On Windows:
    C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd stop
    C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd start
For more information, see: Starting Oracle HTTP Server on a Privileged Port, Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.

Section 4: Managing Configuration of Web Application services

In Oracle E-Business Suite Release 12.2, the oacore, oafm, forms, forms-c4ws and oaea services are deployed as applications on individual managed servers. Some of the configuration parameters of these services are managed at the application level while others are managed at individual managed server level.

4.1 Updating Configuration Parameters for Individual Applications

The basic configurations of the oacore, oafm, forms, forms-c4ws and oaea applications are maintained in their respective deployment plans. The deployment plan for an application contains configurable parameters such as session timeout, log file rotation size, and log file rotation time. Each deployment plan is delivered as an AutoConfig template containing a limited set of context variables.
AutoConfig instantiates the deployment plan initially. Subsequently, AutoConfig only updates the existing deployment plan: this is needed in case any of the context variables used in the deployment plan have been customized.
The only parameters that can be updated using AutoConfig are for the oacore application. Following is the list of parameters in the deployment plan for oacore application that is managed via AutoConfig:
ParameterValue
help_InitParam_ohwConfigFileURLfile:%s_ora_config_home%/FMW/oacore/config/ohwconfig.xml
CGIServlet_InitParam_cgiDir%s_config_home%/admin/install
CGIServlet_InitParam_*.pl%s_adperlprg%
oowa_InitParam_log_main_file%s_logs_dir%/ora/FMW/oacore/oowa.log
oowa_InitParam_log_spl2_file%s_logs_dir%/ora/FMW/oacore/oowa.log
LoopProcServlet_InitParam_ARCHIVE%s_applptmp%
TransmitServlet_InitParam_ARCHIVE%s_applptmp%
The remaining parameters for each application need to be updated through the WebLogic Server Administration Console, as follows:
  1. Log on to the WebLogic Server Administration Console.
  2. Click on the 'Deployments' link in the left panel for 'Domain Structure.'
  3. Examine the page that gives a summary of all deployments.
  4. If the configuration is to be customized at the application level, click on the application whose configuration is to be updated. For example, if updating oacore configuration, click on the link for 'oacore' and take the desired action.
  5. If the configuration changes are to be done at the Web Application level, click on the link for the respective Web Application in the Deployments page, and select the 'Configuration' tab to customize the configuration parameters for the application.
  6. After editing and setting the parameters, click on the 'Save' button. This updates the deployment plan for the application.
  7. Once all configuration changes have been saved, click on the 'Activate Changes' button in the 'Change Center' panel to activate the changes.
Note: For further information, refer to Section 3.4: Getting Started Using Oracle WebLogic Server Administration Console in Oracle Fusion Middleware Administrator's Guide 11g Release 1 (11.1.1). This book can be found in the Oracle Fusion Middleware Documentation Library.

4.2 Managing Configuration Parameters for Individual Managed Servers

4.2.1 Customizing Managed Server Configuration via WebLogic Server Administration Console

The managed server configuration can be customized via native WebLogic tools such as the WebLogic Server Administration Console and WLST commands.
Use the following steps to customize the managed server configuration via the WebLogic Server Administration Console.
  1. Log on to the WebLogic Server Administration Console.
  2. Click on the 'Servers' link. This link takes you to a page containing a summary of the WebLogic Administration Server and all managed servers.
  3. Click on the managed server whose configuration needs to be updated. A page containing various tabs for the settings of the managed server appears.
  4. Update the configuration parameters as needed.
  5. Click the 'Save' button to save the configuration changes.
  6. Once the customizations are complete and saved, click the 'Activate Changes' button in the 'Change Center' panel to activate the changes.
Note: If the managed server port number is to be changed, in addition to updating the port number via the native WebLogic tools you must also perform the additional steps in Section 4.2.4.

4.2.2 Managing Classpath and JVM Arguments for the Managed Server

The classpath and JVM arguments of a managed server can be modified from the WebLogic Server Administration Console or through WLST commands as specified above, which is the preferred way.
In addition, in case these properties are to be set from the command line, it can be done as follows:
  • To set the managed server classpath, execute the following command:
    $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-set-managedsrvproperty \
    -contextfile=<CONTEXT_FILE> -managedsrvname=<MANAGED SERVER NAME> \
    -managedsrvclasspath="<COMPLETE MANAGED SERVER CLASSPATH>"

    Note: The above command will overwrite the existing managed server's classpath to the value specified for the argument -managedsrvclasspath.

    So it should be ensured that the complete managed server classpath is provided in the above command. The existing managed server classpath value can be obtained from the WebLogic AdminServer Console, by navigating to the respective managed server as specified in Section 4.2.1 and then clicking on the 'Server Start' tab.

    Only in the unlikely case when the value cannot be retrieved from the WebLogic AdminServer Console, the default value supplied for the managed server classpath in the context file can be used. Refer to Section 4.2.3 for details of the managed server classpath context variables.
  • To set the managed server JVM arguments, execute the following command:
    $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-set-managedsrvproperty \
    -contextfile=<CONTEXT_FILE> -managedsrvname=<MANAGED SERVER NAME> \
    -serverstartargs="<COMPLETE LIST OF JVM ARGUMENTS>"
    Note: The above command will overwrite the existing managed server's JVM arguments to the value specified for the argument -serverstartargs.

    So it should be ensured that the complete set of JVM arguments for the managed server is provided in the above command. The existing JVM arguments for the managed server can be obtained from the WebLogic AdminServer Console, by navigating to the respective managed server as specified in Section 4.2.1 and then clicking on the 'Server Start' tab.

    Only in the unlikely case when the value cannot be retrieved from the WebLogic AdminServer Console, the default value supplied for the managed server JVM arguments in the context file can be used. Refer to Section 4.2.3 for details of the context variables for the managed server JVM arguments.
During startup of a managed server using the adstrtal.sh/cmd script or the individual control script admanagedsrvctl.sh/cmd, the Oracle E-Business Suite-specific library path is updated in the managed server JVM arguments. If the JVM arguments have already been customized for the managed server, the E-Business Suite specific library path is prepended to the list of customized library paths.

4.2.3 Resetting Managed Server Classpath and JVM Arguments to Default Values

If you need to reset the managed server classpath or JVM arguments to the default values, refer to the default values in the context file and update these properties using either the native WebLogic tools or the adProvisionEBS.pl script used in Section 4.2.2.
The default values for the managed server classpath can be identified from the context variables listed in the following table:
Service TypeContext Variable
oacores_oacore_classpath
oafms_oafm_classpath
formss_forms_classpath
forms-c4wss_forms-c4ws_classpath
The default values for the managed server JVM arguments can be identified from the context variables listed in the following table:
Service TypeContext Variable
oacores_oacore_jvm_start_options
oafms_oafm_jvm_start_options
formss_forms_jvm_start_options
forms-c4wss_forms-c4ws_jvm_start_options

4.2.4 Changing the Port Numbers of the Managed Servers

To change the port number of a managed server, you must first edit the port number by following the steps in Section 4.2.1.

Then perform the following steps on all application tier nodes participating in the same cluster that this managed server is part of:
  1. Source the run file system.
  2. Execute the following command to delete references of the old managed server port in the OHS configuration files mod_wl_ohs.conf and apps.conf:
    $ 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 port number of the managed server oacore_server3 on host 'testserver' and domain 'example.com' is being changed from 7205 to 7305, the following command should be executed to remove references of port 7205:
    $ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> \
    -configoption=removeMS -oacore=testserver.example.com:7205
  3. Execute the following command to add back the managed server entry in the OHS configuration files with the new port:
    $ 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, to add back entry of managed server oacore_server3 on host 'testserver' and domain 'example.com' with port 7305, the following command should be executed:
    $ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> \
    -configoption=addMS -oacore=testserver.example.com:7305
  4. If Oracle HTTP Server is enabled on the node, restart it as follows:

    On UNIX:
    $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop
    $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start
    On Windows:
    C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd stop
    C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd start

4.3 Additional Steps Needed on Non-Shared Multi-Node Systems

Configuration changes performed via Oracle WebLogic Server (WLS) Console to any of the oacore, oafm, forms and forms-c4ws applications are reflected in the associated deployment plans. The changes are made automatically to the deployment plan on the node where the AdminServer is running.
If you have a multi-node system, you must manually update the deployment plans on the other nodes so that the plans on all nodes are synchronized.
The deployment plans are located as follows:
  • <EBS_ORACLE_HOME>/deployment_plans/oacore/plan.xml
  • <EBS_ORACLE_HOME>/deployment_plans/oafm/plan.xml
  • <EBS_ORACLE_HOME>/deployment_plans/forms/plan.xml
  • <EBS_ORACLE_HOME>/deployment_plans/forms-c4ws/plan.xml
If any configuration changes are made to a deployment plan via WLS Console, follow the steps below to synchronize the deployment plans on the other nodes.
  1. Edit the relevant deployment plan to enter the new configuration value in the variable-definition section.

    For example, if the Session cookies max age parameter is changed via WLS console, you must make a corresponding update to the variable WeblogicApplication_SessionDescriptor_CookieMaxAgeSecs in the variable-definition section of the deployment plan.
     
  2. Save the deployment plan.
     
  3. Restart the managed server.

4.4 Customizing the Number of Instances of a Particular Service Type

By default, every application tier node contains only a single instance of the oacore, oafm, forms and forms-c4ws services. If more instances of a particular service are required on an application tier node, new managed servers must be created. Similarly, if the number of instances of a particular service needs to be reduced, the relevant managed server needs to be deleted.
Note: For the oacore service, Oracle recommends up to 150-200 concurrent users per JVM of size 2 GB.


4.4.1 Adding a new managed server

Addition of managed servers needs to be done on the run file system when there is no active ADOP cycle. During the next adop prepare, the Configuration Change Detector identifies that the addition has been made and the managed servers are automatically synced up from the run file system to the patch file system. The synchronization also gets done when fs_clone is executed.
Note: Managed server creation should be done only through the adProvisionEBS.pl script as mentioned in this section. Managed servers should not be created from the WebLogic Server Administration Console.
To add a new managed server of a specific service type, perform the following steps on the run file system:
  1. Execute the following command to add a new managed server. This will create a managed server and add a new entry to the context file for starting and stopping the new managed server via the adstrtal and adstpall scripts:
    $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl \
    ebs-create-managedserver -contextfile=<CONTEXT_FILE> \
    -managedsrvname=<MANAGED_SERVER_NAME> -servicetype=<SERVICE_TYPE> \
    -managedsrvport=<MANAGED_SERVER_PORT> -logfile=<LOGFILE>
    For example, to add a managed server 'oacore_server2' of type 'oacore' with port 7203, run the following command:
    $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl \
    ebs-create-managedserver -contextfile=<CONTEXT_FILE> \
    -managedsrvname=oacore_server2 -servicetype=oacore \
    -managedsrvport=7203 -logfile=<APPLRGF>/TXK/addMS_oacoreserver2.log

    Note:
    • The managed server name must be of the form <SERVICE_TYPE>_server<n>, where n is an integer.
    • As well as being free, the port number for each managed server must be unique: no two managed servers across the run and
    • patch file systems can have the same port number.
  2. Startup the managed server as follows:

    On Unix:
    $ sh <ADMIN_SCRIPTS_HOME>/admanagedsrvctl.sh start <MANAGED SERVER NAME>
    On Windows:
    C:\><ADMIN_SCRIPTS_HOME>\admanagedsrvctl.cmd start <MANAGED SERVER NAME>
    For example, to startup the newly added managed server 'oacore_server2', execute the following command:
    $ sh <ADMIN_SCRIPTS_HOME>/admanagedsrvctl.sh start oacore_server2
  3. Perform the following steps on all application tier nodes participating in the same cluster where this managed server is added:

    1. Source the run file system.
    2. Execute the following command to add details of the newly added 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 managed server oacore_server2 has been added on host 'testserver' and domain 'example.com' with port 7205, the following command should be executed:
      $ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> \
      -configoption=addMS -oacore=testserver.example.com:7205
    3. If Oracle HTTP Server is enabled on the node, restart it as follows:

      On UNIX:
      $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop
      $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start
      On Windows:
      C:\><ADMIN_SCRIPTS_HOME>\adapcctl.cmd stop
      C:\><ADMIN_SCRIPTS_HOME>\adapcctl.cmd start

4.4.2 Removing a managed server

The following steps should be executed in order to delete a managed server from the domain. As in the case of managed server addition, deletion of managed servers should be done on the run file system, with synchronization between the run and the patch file systems subsequently being performed automatically during adop prepare execution or during fs_clone.
Note: Managed server deletion should be done only through the adProvisionEBS.pl script as mentioned in this section. Managed servers should not be deleted from the WebLogic Server Administration Console.
To delete a managed server of a specific service type, perform the following steps on the run file system:
  1. Perform the following steps on the application tier where the managed server resides.

    1. If the managed server to be deleted is running, shut it down as follows:

      On Unix:

      $ sh <ADMIN_SCRIPTS_HOME>/admanagedsrvctl.sh stop <MANAGED SERVER NAME>
      On Windows:
      C:\><ADMIN_SCRIPTS_HOME>\admanagedsrvctl.cmd stop <MANAGED SERVER NAME>
      For example, before deleting a managed server 'oacore_server2', execute the following command to shut it down.
      $ sh <ADMIN_SCRIPTS_HOME>/admanagedsrvctl.sh stop oacore_server2
    2. Run the command below on the application tier node where the managed server resides. This will delete the managed server, and also update the respective context variables that contain references to the deleted managed server.
      $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl \
      ebs-delete-managedserver \
      -contextfile=<CONTEXT_FILE> -managedsrvname=<MANAGED_SERVER_NAME> \
      -servicetype=<SERVICE_TYPE> -logfile=<LOGFILE>
      For example, for deleting a managed server 'oacore_server2' of type 'oacore', execute the following command:
      $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl \
      ebs-delete-managedserver \
      -contextfile=<CONTEXT_FILE> -managedsrvname=oacore_server2 \
      -servicetype=oacore -logfile=<APPLRGF>/TXK/delMS_oacoreserver2.log
  2. Perform the following steps on all application tier nodes participating in the same cluster as the deleted managed server:

    1. Source the run file system.
    2. If the deleted managed server is part of the cluster configuration defined on the current node, execute the following command to delete details of the managed server 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 remove references of the deleted managed server oacore_server2 with port 7205 on host 'testserver' and domain 'example.com', the following command should be executed:
      $ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> \
      -configoption=removeMS -oacore=testserver.example.com:7205
    3. If Oracle HTTP Server is enabled on the node, restart it as follows:

      On UNIX:
      $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop
      $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start
      On Windows:
      C:\><ADMIN_SCRIPTS_HOME>\adapcctl.cmd stop
      C:\><ADMIN_SCRIPTS_HOME>\adapcctl.cmd start

Section 5: Updating the Classpath and JVM Arguments of the WebLogic AdminServer

When the WebLogic AdminServer is started, the classpath and JVM arguments are picked up from the values of the context variables s_adminserver_classpath and s_nm_jvm_startup_properties respectively.
In order to update these WebLogic AdminServer properties, perform the following steps on the run file system of the primary node:
  1. Update the respective context variable ( s_adminserver_classpath for updating the AdminServer classpath and s_nm_jvm_startup_properties for updating the AdminServer JVM arguments).
  2. Run AutoConfig on the Application tier.
  3. Bounce the WebLogic AdminServer as follows:

    On UNIX:
    $ sh <ADMIN_SCRIPTS_HOME>/adadminsrvctl.sh stop
    $ sh <ADMIN_SCRIPTS_HOME>/adadminsrvctl.sh start
    On Windows:
    C:\><ADMIN_SCRIPTS_HOME>\adadminsrvctl.cmd stop
    C:\><ADMIN_SCRIPTS_HOME>\adadminsrvctl.cmd start
Note: Setting the WebLogic AdminServer classpath or JVM arguments from the WebLogic Administration Console or using WLST will not enforce any changes to these properties as the values will be always picked up from the respective context variables as mentioned above.

Section 6: Known Issues

This section lists any known issues with the AutoConfig-related configuration management of Oracle E-Business Suite Release 12.2 environments.

Issue 1

On a multi-node installation with the Forms Services and Batch Processing Services enabled on separate nodes, OAM fails to update the context variables on the Batch Processing Services node.
Solution:
Check whether the Listener Service is up on the Forms Services node. If the service is down, start the service using one of the following options:
  • Start the TNS listener service manually using the following command:

    On UNIX:

    $ $INST_TOP/admin/scripts/adalnctl.sh start <TWO_TASK>
    On Windows:
    C:\>%INST_TOP%\admin\scripts\adalnctl.cmd start <LOCAL>
  • Enable management of the TNS Listener Service using the adstrtal or adstpall scripts on the Forms Services node.
    1. Enable the TNS Listener Service by following the steps mentioned earlier.
    2. Stop all the application tier services using adstpall.sh or adstpall.cmd.
    3. Start all the application tier services using adstrtal.sh or adstrtal.cmd.

Change Log

DateDescription
01-Aug-2016
  • Updated the list of AutoConfig-managed OHS templates.
  • Updated the steps for changing the seeded OHS configuration.
29-Jan-2015
  • Inserted Section 2 regarding tools for synchronization and added the section for Known Issues.
  • Updated Section 3.2 and Section 3.3.
24-Sep-2014Added new section for updating AdminServer properties and updated Section 4.2.2.
08-Aug-2014Initial publication.

Documentation Notices

Copyright © 2014, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support
Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
at No comments:
Subscribe to: Posts (Atom)

Oracle E-Business Suite Release 12.2 System Schema Migration

In This Document Section 1: Overview of the EBS System Schema Section 2: Requirements for Using the EBS System Schema Section 3: Migrating t...