Friday, July 22, 2016

Abort a patch applied to run file system via Hotpatch in EBS 12.2.x

In EBS 12.2.x, we may get this error sometimes while applying the patch using adop.

APPL_TOP is set to /ERPAPP/TEST/fs1/EBSapps/appl
[STATEMENT] [START 2016/07/04 12:36:16] Determining admin node
[STATEMENT] [END 2016/07/04 12:36:18] Determining admin node
[STATEMENT] Recommended Worker Count: 2 Max Allowed Workers: 9
[STATEMENT] [START 2016/07/04 12:36:22] Acquiring lock on sessions table
[STATEMENT] [END 2016/07/04 12:36:23] Acquiring lock on sessions table
[STATEMENT] [START 2016/07/04 12:36:23] Checking for any pending sessions
[STATEMENT] There is already a session which is incomplete. Details are:
[STATEMENT] Session Id: 2
[STATEMENT] Prepare phase status: Y
[STATEMENT] Apply phase status: P
[STATEMENT] Cutover phase status: N
[STATEMENT] Abort phase status: N
[STATEMENT] Session status: F
[STATEMENT] [Note: Y denotes that the phase is done
[STATEMENT] N denotes that the phase has not been completed
[STATEMENT] X denotes that the phase is not applicable
[STATEMENT] R denotes that the phase is running (in progress) or ran
[STATEMENT] F denotes that the phase has failed
[STATEMENT] P (is applicable only to APPLY phase) denotes atleast
[STATEMENT] one patch is already applied for the session id
[ERROR] Cannot apply hotpatch as another online patching cycle is going on
[ERROR] Unrecoverable error occured. Exiting the current session.


The reason for this error is because another patching session is active.
[applmgr@cvm-928 ~]$ adop -status
Enter the APPS username: apps
Enter the APPS password:

Current Patching Session ID: 2


Node Name       Node Type       Phase       Status          Started                        Finished                       Elapsed
--------------- --------------- ----------- --------------- ------------------------------ ------------------------------ ------------
cvm-928         master          APPLY       FAILED          30-JUN-16 01:44:53 +05:30      30-JUN-16 01:48:01 +05:30      0:03:08
                                PREPARE     COMPLETED       30-JUN-16 12:07:26 +05:30      30-JUN-16 12:37:40 +05:30      0:30:14
                                CUTOVER     NOT STARTED
                                CLEANUP     NOT STARTED

File System Synchronization Used in this Patching Cycle: None

Solution: Abort the patching cycle and run full cleanup.

adop phase=abort
adop phase=cleanup cleanup_mode=full




Patch can be rolled back till we reached the cutover phase. Once we reach the cutover phase, we cannot abort a phase. Thus the question comes, what will we do, if some problem occur which eventually lead to failure of cutover phase.Taking a backup is always recommended before applying a patch but it is too costly. We cannot take a cold back up of EBS application filesystema and Database everytime just to apply a single patch. There is a time constraint, downtime and cost involved to keep the backup.

Thus we have to go for flashback option for database where we can roll back the database just before the cutover stage. To enable the flashback option, execute the below statements


Connect to the oracle database

1. sqlplus / as sysdba

alter system set db_recovery_file_dest='/oracle/stage/backups' scope=BOTH SID='*';

alter system set db_recovery_file_dest_size=200GB scope=BOTH SID='*';

alter system set db_flashback_retention_target=300;(this is in minutes, set it according to the environment)

alter database flashback on;


2. Stop the ebs services, conc processing and other outgoing interface just to ensure that there won't be any loss of data.

3.start the patching cycle

adop phase=prepare,apply,finalize

4. Create a restore point

alter system switch logfile;
create restore point ABc guarantee flashback database;
alter system switch logfile;

5. execute adop phase=cutover.

if we face any issue, we can flashback the database to the restore point.

shutdown immediate;
startup mount;
flashback database to restore point ABC;
alter database open read only;

shutdown immediate;
startup mount;
alter database open resetlogs;

6.
Disable flashback
alter database flashback off;
drop restore point ABC;
Restore point dropped.
alter system set db_recovery_file_dest='';
System altered.
select FLASHBACK_ON from v$database;


now we also have to revert back the appliction file system. By checking the cutover logs, we can check that if the cutover has failed before the cutover happened or after the cutover. If the cutover has not happened, then just clean shutdown and startup the ebs services.

if the cutover has happened and file system has switched, then we have to switch the filesystem again.

shutdown the ebs services
perl $AD_TOP/patch/115/bin/txkADOPCutOverPhaseCtrlScript.pl -action=ctxupdate -contextfile=<full path to new run context file> \
-patchcontextfile=<full path to new patch file system context file> \
-outdir=<full path to out directory>

and start the services from the old file system

In a multi-node environment, repeat the preceding two steps on all nodes, starting with the admin node and then proceeding to the slave nodes.

Options and Next Steps
After the restore is complete, you have two basic options for proceeding:
Abort the current patching cycle, if the issue that required you to restore was caused by the patches you were attempting to apply.

Identify and fix any other issues in the current patching cycle, and proceed with patching.


Reference-Document 1584097.1, Oracle E-Business Suite Release 12.2: Backup and Recovery Guidelines For Online Patching Cutover.

https://docs.oracle.com/cd/E26401_01/doc.122/e22954/T202991T531065.htm





Wednesday, July 20, 2016

Autoconfig bits and pieces and how EBS services are started


I will not go through what autoconfig is. There are  number of docs available in the net.
Just wanted to brush what internally autoconfig does which helps during the troubleshooting times.

1. Report version conflict
2. Backup of the context file
3. Synchronization of file system Context file and its templates with those in the database (Establish DB Connection)
4. Check for customizations to Context template
5. Check the context file for possible updates from database
6. compare the context file stored in database with the context file sored in Database and update it accordingly
   Result                  : The two Context files are in sync

===========================================================================
Starting Updates of Context file Fri May 27 04:28:13 EDT 2016

      found context version     : 120.271.12010000.36
      available update version  : 120.271.12010000.36


7. Start Config Tool CVMHelper
  Updating local context file variables for Middle Tier

Checking file $AD_TOP/12.0.0/admin/template/adgendbc_ux.sh
FND_SECURE: $FND_SECURE
DBC FILE NAME: Instance name
File exists, getting the version
Version: 120.8.12010000.6
No updates to s_fnd_secure needed

Writing Context File back to File System
Context file updated

8. Making database connection using DBUtil
9. Check for new context variables
   No new variables found in the context file

Updated  s_dbGlnam to "instance name"

Processing existing variables with updated defaults
Updated  s_defterr to AMERICA
Updated  s_apps_version to 12.1.3

Writing Context File back to File System
Context file updated
Closing connection

10.Start synchronisation of context file

11. Start location of IANA character set
    [s_iana_cset]
    IANA Charset obtained from Database    : UTF-8
    IANA Charset present in Context file   : UTF-8
    IANA Charset based on APPL_TOP char set: UTF-8
    IANA Charset decided for Context file  : UTF-8
    Action taken : None, since the correct value exists in the Context file

12. Start context value management system
    Performs the task of validating the APPL_TOP
    Start $FND_TOP/patch/115/bin/txkSetConfig.pl (TXK Script to update the Applications configuration
    Start $AD_TOP/adgentns.pl (seeds the entries in to the data model and generates the tnsnames.ora)

13. Upload file system Context file and its templates to the database
14. Upload the Context information template to the DataBase
15. Configure templates from all of the product tops
16. AutoConfig Profile Phase--This prepares all the application TOPS
17. Start Restore Profile utility  

************************************************************************

We might have observed that in multi node install few services are started
in one server and some in another server.
During the Rapid Install, you select the above configuration via the
“Edit Services” button as follows :
•APPS1 : enable “Root Service Group”, “Batch Processing Services”
•APPS2 : enable “Root Service Group”, “Web Entry Point Services”, “Web Application Services”,
“Other Service Group”



Configuring Applications Node Services in Oracle E-Business Suite Release 12
(Doc ID 406558.1)



The logic behind these service classification is as follows :
1.Root Service Group (Runs services on AS, 10.1.3 OH) 1.Oracle Process Manager (OPM)
: adopmnctl.sh

2.Web Entry Point Services (Runs services on AS, 10.1.3 OH) 1.HTTP Server
: adapcctl.sh

3.Web Application Services (Runs services on AS, 10.1.3 OH) 1.OACORE OC4J
: adoacorectl.sh
2.FORMS OC4J : adformsctl.sh
3.OAFM OC4J : adoafmctl.sh

4.Batch Processing Services (Concurrent Managers and Apps Listener) 1.APPS TNS Listener
: adalnctl.sh
2.Concurrent Managers : adcmctl.sh, adsvcm.sh, ieoicsm.sh, ieosvicsm.sh
3.Fulfillment Server : jtffmctl.sh, jtfsvfm.sh

5.Other Service Group: (Runs services for Forms on 10.1.2) 1.Oracle Forms Server :
adformsrvctl.sh
2.Oracle MWA Service : mwactlwrpr.sh


After the installation you see that the Autoconfig XML file is generated with the following
entries for APPS1 and APPS2 :
•s_isDB=NO
•s_isAdmin=YES
•s_isForms=YES
•s_isConc=YES
•s_isWeb=YES

Why are all services enabled on the two application tier nodes instead of the configuration
that was selected via the “Edit Services” feature ?

In R12, the concept for Applications Nodes has changed.  When installing R12 with multiple nodes all the nodes are now set as ‘Y’ in FND_NODES.

This occurs because in R12, concept of unified APPL_TOP is introduced which means everything is laid down on all servers.

From the APPL_TOP perspective, all the Servers on a Multi-Node Environment will have the same files and can now potentially start any Service if needed.  In some cases, additional configuration will be required before this can be done since there can be profiles, etc associated with each Server.

For R12, the only difference between the Servers, are the Services that have been activated on each Node.
 The Services are identified by the variables on the /service_group/ section in the APPS Context File:
•Root Service Group : s_root_status
•Web Entry Point Services : s_web_entry_status
•Web Application Services : s_web_applications_status
•Batch Processing Services : s_batch_status
•Other Service Group : s_other_service_group_status

Depending on the value of these variables (enabled or disabled), adstrtal.sh / adstpall.sh will only start/stop the Services associated with them, ignoring the rest.

For example, if a node has only /s_batch_status/ “enabled” and the rest of the services are disabled, when you run adstrtall.sh on that Server and it will only start the Concurrent Managers and the TNS Listener for Apps.


With a Unified APPL_TOP, all Applications tier nodes have their corresponding context variables set to ‘Y’.
As the difference between nodes is in the services that are activated rather than the files that are present, and since there is no one-to-one match between service groups and nodes, services can easily be switched to run on a different node if desired. This provides a failover capability, whereby a service can be enabled on a node so it can take over the role of a failed node. Equally, it is possible to start a service on a node that was not specified to run that service when Rapid Install was executed.

******************************************************************

                                                      Few Important notes:

Sometimes we can face an issue where the serial number of the context file is less than the serial number present in FND_OAM_CONTEXT_FILES. In this case, autoconfig repalces the values stored in our context file with the values present in FND_OAM_CONTEXT_FILES table. This scenario can also happen when during cloning only DB is refreshed and apps tier is not.
In this case, value present in table will come from source and thus there can be anomaly.

This scenario can also happen in EBS 12.2 where due to adop phase=abort the there is a serial mismatch between file system context file and DB table values. Metalink note:adop phase=abort causes "Serial number in context file contains lower value than that of database copy." (Doc ID 1916658.1)

adpatch generally does not update the "values" of a context file directly. Patches usually update templates. After the file is updated by adpatch, the autoconfig portion automatically launched from the patch session will replicate the templates into configuration files. The same applies for the context file. Having said that, if for some reason, a patch changes the setting of a context variable (which I really don't recall any particular case) then the autoconfig portion will update it in the database first and second it will also update the context file on the node where autoconfig was executed. If that is the case for a patch, autoconfig should be executed separately on all the nodes to make sure the configuration is transported. If such a patch exists, the README should include this clarification.
Regardless of this particular use case, it is always recommended to run autoconfig on all the nodes to assure consistency.

Additionally, the template of the context file is treated as any other file in EBS. If it has a lower version than the patch, then adpatch will replace the file and run AC. If the version in the file system is higher, then all the actions are skipped including the AC phase.
Adpatch has a smart criteria to run AC. In the same way, the AC phase will not be launched from adpatch if the files included in the patch don't belong to the "autoconfig template" category. In other words if a patch includes another file type not related with AC (ie .o file for binaries) then it will not run AC because is not necessary.

For more information refer to metalink note:-Using AutoConfig to Manage System Configurations in Oracle E-Business Suite Release 12 (Doc ID 387859.1)













Tuesday, July 12, 2016

Hourly/Daily Archive generation

The below query comes handy to understand the archivelog generation of an Oracle database on
 an hourly /daily basis, per thread – in case of RAC databases. Archivelog generation on a daily 
basis:

set pages 1000select trunc(COMPLETION_TIME,'DD') Day, thread#, round(sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024) GB,count(*) Archives_
Generated from v$archived_loggroup by trunc(COMPLETION_TIME,'DD'),thread# order
 by 1;

Archive log generation on an hourly basis:

set pages 1000select trunc(COMPLETION_TIME,'HH') Hour,thread# , round(sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024) GB,count(*) Archives from 
v$archived_loggroup by trunc(COMPLETION_TIME,'HH'),thread#  order by 1 ;

Sample output:

HOUR                   THREAD#         MB   ARCHIVES
------------------- ---------- ---------- ----------
2013 08 20 12:00:00          1      31268        339
2013 08 20 13:00:00          1       4994         55
2013 08 20 14:00:00          1       4412         48
2013 08 20 15:00:00          1       4805         52
2013 08 20 16:00:00          1       3364         37
2013 08 20 17:00:00          1         22          1
2013 08 20 21:00:00          1          9          1

Also, the following script is useful to find the archivelog switches on an hourly basis that happened in the past 
one week, I got this from http://kubilaykara.blogspot.com/2008/02/redo-log-generation.html and is quite an 
useful one.

SELECT to_date(first_time) DAY,to_char(sum(decode(to_char(first_time,'HH24'),'00',
1,0)),'99') "00",to_char(sum(decode(to_char(first_time,'HH24'),'01',1,0)),'99') "01",to_char(sum(decode(to_char(first_time,'HH24'),'02',1,0)),'99') "02",to_char(sum(decode(to_char(first_time,'HH24'),'03',1,0)),'99') "03",to_char(sum(decode(to_char(first_time,'HH24'),'04',1,0)),'99') "04",to_char(sum(decode(to_char(first_time,'HH24'),'05',1,0)),'99') "05",to_char(sum(decode(to_char(first_time,'HH24'),'06',1,0)),'99') "06",to_char(sum(decode(to_char(first_time,'HH24'),'07',1,0)),'99') "07",to_char(sum(decode(to_char(first_time,'HH24'),'08',1,0)),'99') "08",to_char(sum(decode(to_char(first_time,'HH24'),'09',1,0)),'99') "09",to_char(sum(decode(to_char(first_time,'HH24'),'10',1,0)),'99') "10",to_char(sum(decode(to_char(first_time,'HH24'),'11',1,0)),'99') "11",to_char(sum(decode(to_char(first_time,'HH24'),'12',1,0)),'99') "12",to_char(sum(decode(to_char(first_time,'HH24'),'13',1,0)),'99') "13",to_char(sum(decode(to_char(first_time,'HH24'),'14',1,0)),'99') "14",to_char(sum(decode(to_char(first_time,'HH24'),'15',1,0)),'99') "15",to_char(sum(decode(to_char(first_time,'HH24'),'16',1,0)),'99') "16",to_char(sum(decode(to_char(first_time,'HH24'),'17',1,0)),'99') "17",to_char(sum(decode(to_char(first_time,'HH24'),'18',1,0)),'99') "18",to_char(sum(decode(to_char(first_time,'HH24'),'19',1,0)),'99') "19",to_char(sum(decode(to_char(first_time,'HH24'),'20',1,0)),'99') "20",to_char(sum(decode(to_char(first_time,'HH24'),'21',1,0)),'99') "21",to_char(sum(decode(to_char(first_time,'HH24'),'22',1,0)),'99') "22",to_char(sum(decode(to_char(first_time,'HH24'),'23',1,0)),'99') 
"23"fromv$log_historywhere to_date(first_time) > sysdate - 8 -- or else change 
it you want for more days to viewGROUP byto_char(first_time,'YYYY-MON-DD'), 
to_date(first_time)order by to_date(first_time)
/

Sample output:

DAY 00 01 02 03 04 05 06 09 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23
--------- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- -
01-NOV-13 0 1 1 0 1 0 1 0 1 4 1 1 0 1 0 1 1 0 1 1 1 1 1 1
02-NOV-13 0 1 1 1 1 0 1 1 1 1 0 1 1 7 1 1 1 1 1 2 1 1 1 1
03-NOV-13 1 2 2 1 1 1 1 1 1 1 1 2 1 1 1 1 1 2 1 1 2 1 1 2
04-NOV-13 1 1 8 1 7 2 1 1 1 2 1 1 2 1 2 1 2 1 2 1 2 1 2 2
05-NOV-13 2 1 2 1 2 2 1 2 1 2 2 1 2 2 1 2 2 2 1 2 2 2 2 2
06-NOV-13 2 1 2 2 2 2 1 2 2 2 2 2 1 2 2 1 0 2 0 0 0 0 1 0
09-NOV-13 0 0 1 7 0 0 1 0 0 0 0 0 0 0 7 0 0 0 0 0 0 0 0 0

Sunday, July 3, 2016

Blocks corrupted in system tablespace after fresh installation of EBS 12.1.1

Today, i encountered an issue where i installed the EBS 12.1.1 and tried to take a full rman backup.
First converted the db to archive mode and then tried to take a full rman backup.
Then configured the rman channel to place the backup in disk at the designated location.

RMAN backup error.

thankfully, these corruptions does not belong to any object and hence it will not impact the installtion or db startup.

To verify the blocks corrupted, we need to run the dbv command line utility:
[oracle@sam fmw]$ dbv file=/u01/12.1.1/EBS/SOURCE/db/apps_st/data/system09.dbf

DBVERIFY - Verification complete

Total Pages Examined         : 192128
Total Pages Processed (Data) : 52304
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 26450
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 2123
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 84778
Total Pages Marked Corrupt   : 26473
Total Pages Influx           : 0
Total Pages Encrypted        : 0

Highest block SCN            : 3712725850 (1388.3712725850)





Once you conform through dbv the blocks are corrupted then you need to run the Rman validating script 

Rman script to  validate

run {
allocate channel d1 type disk;
allocate channel d2 type disk;
allocate channel d3 type disk;
backup check logical validate database;
release channel d1;
release channel d2;
release channel d3;
}

it  will produce the error in the alert log for all the corrupted blocks it will validate all the blocks corrupted and populate into the v$database_block_corruption Once the Rman command completes then you can proceed to the next step ..it is mandatory to complete this step



Check the no of blocks corrupted

SQL> Select * from v$database_block_corruption ;

     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTI
---------- ---------- ---------- ------------------ ---------
       352     165660      26341                  0 ALL ZERO

note the  it is the data file number which is effected  and the block number



Check the corrupted block belongs to any object


 SYNTEX :select segment_name, segment_type, owner
       from dba_extents
      where file_id = <data_file_name>
        and  < corrupted block number >between block_id
            and block_id + blocks -1;



SQL> select segment_name, segment_type, owner
       from dba_extents
      where file_id = 352
        and  165660 between block_id
            and block_id + blocks -1;

It will return now rows selected and then proceed with the steps if it returns now row selected then the particular block  does not belongs to any object and it is empty
To conform the empty block run the below query



Then, i performed the below action plan

Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter database datafile '/u01/12.1.1/EBS/SOURCE/db/apps_st/data/system09.dbf' resize 1056M;

Database altered.


Verified again the count of corrupted objects

[oracle@sam 11.1.0]$ dbv file=/u01/12.1.1/EBS/SOURCE/db/apps_st/data/system09.dbf

DBVERIFY: Release 11.1.0.7.0 - Production on Sun Jul 3 10:54:10 2016

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

DBVERIFY - Verification starting : FILE = /u01/12.1.1/EBS/SOURCE/db/apps_st/data/system09.dbf


DBVERIFY - Verification complete

Total Pages Examined         : 135168
Total Pages Processed (Data) : 104090
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 26450
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 2124
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 2504
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 3714312362 (1388.3714312362)
[oracle@sam 11.1.0]$ 


Re initiated the backup again and it completed successfully.


Reference
=======
1. Oracle E-Business Suite Installation and Upgrade Notes Release 12 (12.1.1) for Linux x86-64 [ID 761566.1]
2. More than 20000 Blocks Corrupted in system09.dbf After Fresh Installation of E-Business Suite R12.1.1 on Linux x86_64 Platform [ID 840963.1]