Hurriyet

adop etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
adop etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

27 Ocak 2015 Salı

Oracle E-Business Suite: Collecting Online Patching Log Files - Log Dosyalarının Toplanması

This article is all about collecting logs that will help you in analysis of the Patches, finding errors in the process or assist you in your Service Request.(Ref-1) (This article is all about the Support Articles in the References). The goal is to collect everyone of these articles in case there might be a problem. In the end, we will also form a script that will report us a lot of things about patches.

All the patch sessions include a patch session id, in which all the related log files concerning that patch, is inserted.  The following SQL will help us the current details about the patch sessions:

select ADOP_SESSION_ID,PREPARE_STATUS,APPLY_STATUS,FINALIZE_STATUS,CUTOVER_STATUS,CLEANUP_STATUS,ABORT_STATUS,STATUS,ABANDON_FLAG,NODE_NAME from AD_ADOP_SESSIONS order by ADOP_SESSION_ID desc; 


Note:
       Y denotes that the phase is done
       N denotes that the phase has not been completed
       X denotes that the phase is not applicable
       R denotes that the phase is running (in progress)
       F denotes that the phase has failed
       P (is applicable only to APPLY phase) denotes at least one patch is already applied for the session id
       C denotes that the status of this ADOP session has completed

Note: Numerical statuses are only relevant for the cutover phase.

These status values are updated when a step has completed, and are as follows:

N denotes that the phase has not been completed
0 denotes that cutover/force_shutdown has started
1 denotes the "force_shutdown" step has successfully executed
3 denotes the "db_cutover" step has successfully executed
4 denotes the "fs_cutover" step has successfully executed
6 denotes the "force_startup" step has successfully executed
Y denotes that the phase is done

Where are the Log Files:
Patch log files are given in the $ADOP_LOG_HOME path. If we look deeper, we will see directories for log groups such as ("Prepare","Apply","Finalize","Cutover","Cleanup").
In these files we will have directories

Adop Scanlog:


This utility analyzes adop log directories for errors and warnings, and displays messages to help the user quickly identify any problems that may have occurred during an adop run. 

To scan all log directories of the latest adop session for errors:
    $ adopscanlog
To scan log directories relating to the latest run of adop in the latest session:
    $ adopscanlog -latest=yes
To scan log directories relating to the latest run of the specified phase, in the latest session:
    $ adopscanlog -latest=yes -phase=
To scan all log directories of a given session (represented by a session_id) for errors:
    $ adopscanlog -session_id=
To see a complete list of supported parameters:
    $ adopscanlog -help

Adop Status:

Adop status gives us the information for the current patching session. However "adop -status " command lets us learn about any given patch session.

Source the run filesystem environment file and run command
adop -status
usage
adop -status  generates a summary report
adop -status generates a summary report for that session ID
adop -status -detail generates a detailed report



Check AD and TXK C Patch levels

The following command gives us details about the patch levels of very important modules. The reason we are emphasizing these patch level information is that after the upgrade from previous 12.2 releases, the missing upgrade of these modules will cause problems. Therefore these are checked by the Oracle Support.

SELECT codelevel FROM AD_TRACKABLE_ENTITIES WHERE abbreviation in ('txk','ad');


Check middle tier technology patch levels

perl $FND_TOP/patch/115/bin/TXKScript.pl -script=$FND_TOP/patch/115/bin/txkInventory.pl -txktop=$APPLTMP -contextfile=$CONTEXT_FILE -appspass=apps -outfile=/tmp/Inventory_Report.html


References:
1-12.2 E-Business Suite - Collecting Online Patching and fs_clone Log Files (Doc ID 1542162.1)

23 Ocak 2015 Cuma

Oracle E-Business Suite: Adop Workers Issue While Applying A Patch in 12.2.4 - Worker Kısıtı 12.2.*

When we were trying to apply patch we saw something peculiar in the application process. The application was working well until that moment. Even though we didnt need to state "workers" parameter during the process, we were failing because we didn't enter it.
-------------------------------------------
]$ adop phase=prepare

Enter the APPS password:
Enter the SYSTEM password:
Enter the WLSADMIN password:

 Please wait. Validating credentials...


RUN file system context file: /u01/install/APPS/fs1/inst/apps/$SID_$HOSTNAME/appl/admin/$SID_$HOSTNAME.xml

PATCH file system context file: /u01/install/APPS/fs2/inst/apps/$SID_$HOSTNAME/appl/admin/$SID_$HOSTNAME.xml
Execute SYSTEM command : df /u01/install/APPS/fs2

Worker count determination...

[UNEXPECTED]Invalid Worker Count: 0
[UNEXPECTED]Only a maximum of 1 workers can be invoked
[UNEXPECTED]Error while validating worker count
Log file: /u01/install/APPS/fs_ne/EBSapps/log/adop/adop_20150121_040942.log


[STATEMENT] Please run adopscanlog utility, using the command

"adopscanlog -latest=yes"

to get the list of the log files along with snippet of the error message corresponding to each log file.


adop exiting with status = 2 (Fail)
-------------------------------------------

Solution:
Actually this problem faded once we were able to patch things with the following method below but we didnt understand what has caused this issue. Maybe they will find it later on.

This problem can only be handled by giving an additional property which is "workers"
adop phase=prepare workers=2

References:
1- Adworker Problem - https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=362105903059544&id=1575085.1&displayIndex=1&_afrWindowMode=0&_adf.ctrl-state=dceackd46_774#SYMPTOM

13 Ocak 2015 Salı

Oracle E-Business Suite: Error During Adop Phase=Abort - Adop'ta Patch Abort Edilirken Hata Alınması

We have encountered adop failure while we were aborting a patching process. We wanted to cancel the patch  but there was an error such as the error below:

Exception : Error executng BEGIN fnd_gsm_util.upload_context_file(:1,:2,:3,:4,:5); END;: 1; Serial number in context file contains lower value than that of database copy.  

After a brief search on Oracle Support we found that there is a bug which causes the context file session id's to be not synchronized between RUN and Patch file systems.

Therefore according to the support document (Doc ID 1916658.1), we changed the context file session id of the Patch file system to the same value with the context file of the Run file system.

The variable to be changed is "s_contextserial". 

First of all we read the s_contextserial value of the context file of the RUN File System.


 . /u01/install/APPS/EBSapps.env RUN  
 more $CONTEXT_FILE | grep s_contextserial  

Then the value which is read can be put into the context file of PATCH File System:

   
 . /u01/install/APPS/EBSapps.env PATCH  
 vi $CONTEXT_FILE



Full Text of the Error:

 [applmgr@T1VSTEBSAPP01 admin]$ adop phase=abort  
 Enter the APPS password:   
 Enter the SYSTEM password:   
 Enter the WLSADMIN password:   
   
  Please wait. Validating credentials...  
   
   
 RUN file system context file: /u01/install/APPS/fs1/inst/apps/IKYSDEV_T1VSTEBSAPP01/appl/admin/IKYSDEV_T1VSTEBSAPP01.xml  
   
 PATCH file system context file: /u01/install/APPS/fs2/inst/apps/IKYSDEV_T1VSTEBSAPP01/appl/admin/IKYSDEV_T1VSTEBSAPP01.xml  
 Execute SYSTEM command : df /u01/install/APPS/fs2   
   
 Worker count determination...  
   
 Validation successful. All expected nodes are listed in ADOP_VALID_NODES table.  
 [EVENT]   [START 2015/01/09 04:19:14] Performing database sanity checks  
 [EVENT]   [END  2015/01/09 04:19:16] Finished performing database sanity checks  
  There is already a session which is incomplete. Details are:  
     Session Id      :  29  
     Prepare phase status :  COMPLETED  
     Apply phase status  :  ATLEAST ONE PATCH IS ALREADY APPLIED  
     Cutover phase status :  NOT COMPLETED  
     Abort phase status  :  RUNNING  
     Session status    :  FAILED  
 The above session would be aborted/rolled back. Do you want to continue [Y/N]? Y  
  [START 2015/01/09 04:19:37] adzdoptl.pl run  
   ADOP Session ID: 29  
   Phase: abort  
   Log file: /u01/install/APPS/fs_ne/EBSapps/log/adop/29/adop_20150109_041858.log  
   Abort status: R  
   [START 2015/01/09 04:19:38] abort phase   
 ERROR: InDbCtxFile.uploadCtx() : Exception : Error executng BEGIN fnd_gsm_util.upload_context_file(:1,:2,:3,:4,:5); END;: 1; Serial number in context file contains lower value than that of database copy.  
   
 Cause: Context file editing through Oracle Applications Manager did not complete file system syncronization. Please correct the errors that caused during editing and then run this program again. (FILE=/u01/install/APPS/fs2/inst/apps/IKYSDEV_T1VSTEBSAPP01/appl/admin/IKYSDEV_T1VSTEBSAPP01.xml)  
 oracle.apps.ad.autoconfig.oam.InDbCtxFileException: Error executng BEGIN fnd_gsm_util.upload_context_file(:1,:2,:3,:4,:5); END;: 1; Serial number in context file contains lower value than that of database copy.  
   
 Cause: Context file editing through Oracle Applications Manager did not complete file system syncronization. Please correct the errors that caused during editing and then run this program again. (FILE=/u01/install/APPS/fs2/inst/apps/IKYSDEV_T1VSTEBSAPP01/appl/admin/IKYSDEV_T1VSTEBSAPP01.xml)  
     at oracle.apps.ad.autoconfig.oam.InDbCtxFile.uploadCtx(InDbCtxFile.java:281)  
     at oracle.apps.ad.autoconfig.oam.CtxSynchronizer.uploadToDb(CtxSynchronizer.java:332)  
     at oracle.apps.ad.autoconfig.oam.CtxSynchronizer.main(CtxSynchronizer.java:845)  
 Exception : Error executng BEGIN fnd_gsm_util.upload_context_file(:1,:2,:3,:4,:5); END;: 1; Serial number in context file contains lower value than that of database copy.  
   
 Cause: Context file editing through Oracle Applications Manager did not complete file system syncronization. Please correct the errors that caused during editing and then run this program again. (FILE=/u01/install/APPS/fs2/inst/apps/IKYSDEV_T1VSTEBSAPP01/appl/admin/IKYSDEV_T1VSTEBSAPP01.xml)  
 oracle.apps.ad.autoconfig.oam.InDbCtxFileException: Exception : Error executng BEGIN fnd_gsm_util.upload_context_file(:1,:2,:3,:4,:5); END;: 1; Serial number in context file contains lower value than that of database copy.  
   
 Cause: Context file editing through Oracle Applications Manager did not complete file system syncronization. Please correct the errors that caused during editing and then run this program again. (FILE=/u01/install/APPS/fs2/inst/apps/IKYSDEV_T1VSTEBSAPP01/appl/admin/IKYSDEV_T1VSTEBSAPP01.xml)  
     at oracle.apps.ad.autoconfig.oam.InDbCtxFile.uploadCtx(InDbCtxFile.java:297)  
     at oracle.apps.ad.autoconfig.oam.CtxSynchronizer.uploadToDb(CtxSynchronizer.java:332)  
     at oracle.apps.ad.autoconfig.oam.CtxSynchronizer.main(CtxSynchronizer.java:845)  
 *******FATAL ERROR*******  
 PROGRAM : (/u01/install/APPS/fs1/EBSapps/appl/ad/12.0.0/bin/adzdoptl.pl)  
 TIME  : Fri Jan 9 04:19:44 2015  
 FUNCTION: ADOP::CommonBusinessRoutines::uploadCtxFile [ Level 1 ]   
 ERRORMSG: Upload of context file failed  
   
   
 [STATEMENT] Please run adopscanlog utility, using the command  
   
 "adopscanlog -latest=yes"  
   
 to get the list of the log files along with snippet of the error message corresponding to each log file.  
   
   
 adop exiting with status = 2 (Fail)  
 [applmgr@T1VSTEBSAPP01 admin]$ 

References:

1- adop phase=abort causes "Serial number in context file contains lower value than that of database copy." (Doc ID 1916658.1)

Oracle E-Business Suite: Where are the EBS Log Files - Adop - Adadmin - Service - File Structure in EBS 12.2.* - EBS R12.2'de Log Dosyaları Nerededir? - EBS 12.2.* Dizin Yapısı

What I have noticed since now is that the we have to have a list to find the proper destination of the log files. Because the log files are all over the place, highly distributed, we may not remember all of the log destinations. With the new EBS 12.2.* versions it seems that services seem to write to logs even more than before.

We are going to list the locations and their corresponding paths for our installation in case we ever need them. The corresponding paths may differ according to your installation because the naming conventions of the companies however variable at the beginning of the list is the same for every EBS 12.2.* installation.


1- $ADOP_LOG_HOME=/u01/install/APPS/fs_ne/EBSapps/log/adop

Log files of the adop sessions. Each adop session creates a folder and writes its logs underneath it.


2- $LOG_HOME=/u01/install/APPS/fs1/inst/apps/IKYSDEV_T1VSTEBSAPP01/logs


A change in Release 12.2 is that HTTP, Oracle WebLogic Server, and concurrent processing log files are not stored under $LOG_HOME as they were in previous releases:


HTTP log files are located under the native instance home.


Oracle WebLogic Server log files are located under the domain home.(7)


Concurrent processing log files are located on the none-editioned file system (fs_ne)

3- $LOG_HOME/appl/admin/log = /u01/install/APPS/fs1/inst/apps/IKYSDEV_T1VSTEBSAPP01/logs/appl/admin/log

Under the log directory specified above  we could find the logs which specific services write during their startup and shutdown processes.

These services are:

1-Adadminsrvctl
2-Adapcctl
3-Adforms-c4wsctl
4-Adnodemgrctl
5-Adoafmctl
6-Adstpall
7-Adstrtal
8-Adalnctl
9-Adcmctl
10-Adformsctl
11-Adoacorectl
12-Adopmnctl
13-Jtfmctl


4-  $FORMS_TRACE_DIR=/u01/install/APPS/fs1/inst/apps/IKYSDEV_T1VSTEBSAPP01/logs/ora/10.1.2/forms

5- $APPLRGF=/u01/install/APPS/fs1/inst/apps/IKYSDEV_T1VSTEBSAPP01/logs/appl/rgf


6- $APPLCSF=/u01/install/APPS/fs_ne/inst/IKYSDEV_T1VSTEBSAPP01/logs/appl/conc

7- $RUN_BASE/FMW_HOME/logs: /u01/install/APPS/fs1/FMW_Home/logs/

This is the location where Weblogic logs are kept.

8- $INST_TOP/logs/appl/admin/log: /u01/install/APPS/fs1/inst/apps/IKYSDEV_T1VSTEBSAPP01/logs/ora/10.1.2

Where Oracle Related log files are kept.

Log File Paths:

The picture below is take from the Oracle Doc which is given in the references.(Ref-2)
It shows us the location of log fi



References:

1- Finding the Log File Destinations:
http://docs.oracle.com/cd/E26401_01/doc.122/e22949/T120505T120509.htm
Log Files
Patching Log Files

$LOG_HOME

2-Oracle Applications E-Business Suite 12.2 Fusion Middleware Log Files: Locate,View, and Control (Doc ID 1366187.1)

2 Ocak 2015 Cuma

Oracle E-Business Suite: How to apply patches in EBS R12.2 using Adop -- Abort or Rollback a Patch 12.2.4 Versiyonunda Adop Nasıl Kullanılır? Nasıl Patch Geçilir? - Nasıl Patch İptal Edilir?

In EBS Release 12.2 a new patching tool was introduced.  All the patching is now done with adop. The context of this patching system has also changed. It means that the patches are now applied to the online patching cycle. The patching cycle has a number of phases. These phases are:

  1. Prepare - creates the patch edition.
  2. Apply - apply ARU or manual patches to the patch edition.
  3. Finalize - perform any actions required to prepare for cutover.
  4. Cutover - Promote Patch Edition to be the new Run Edition.
  5. Cleanup - remove obsolete code and data from old editions.
We will now introduce the syntax and the usage of each phase:

Prepare:
The online patching cycle starts with prepare command.  That's why we connect to application node and  source the ebs RUN environment. Then we execute the following command which is
" adop phase=prepare"

 [applmgr@T1VSTEBSAPP01 APPS]$ cd /u01/install/APPS  
 [applmgr@T1VSTEBSAPP01 APPS]$ . EBSapps.env RUN  
 [applmgr@T1VSTEBSAPP01 APPS]$ adop phase=prepare  

When this command is executed a new patch edition is created.

File system synchronization can be done by applying the delta from the recent patching cycle, or by forming the entire patch edition file system as a copy of the run edition (called "fs_clone").

If prepare fails then we should abort the prepare phase.

 [applmgr@T1VSTEBSAPP01 APPS]$ adop phase=abort

Apply:

When the preparation phase is over, changes to the patch edition is isolated from the run edition. Therefore run edition can be used as usual.

We first change our directory to the patch's path.. Then we read the readme.txt of the patch. Unless there is not anything required to do before the patch, we execute apply patch command. 

 [applmgr@T1VSTEBSAPP01 Localization Patch]$ cd 20279504_TR/  
 [applmgr@T1VSTEBSAPP01 20279504_TR]$ adop phase=apply  
 [applmgr@T1VSTEBSAPP01 20279504_TR]$  


Finalize:


The finalize phase is the part where system is prepared to ready the system for a fast cutover.

[applmgr@T1VSTEBSAPP01 20279504_TR]$ adop phase=finalize  

Cutover: 

The cutover is made when the system is ready for downtime. It should be applied after the system can endure a downtime. Moreover the patch edition becomes the new run edition.

The Run/patch designation of the dual file systems are swapped during cutover. We re-source the run edition after the cutover phase.

[applmgr@T1VSTEBSAPP01 20279504_TR]$ adop phase=finalize 

Cleanup:

With cleanup unnecessary code created during the patch phase will be removed.


[applmgr@T1VSTEBSAPP01 20279504_TR]$ adop phase=cutover  
[applmgr@T1VSTEBSAPP01 20279504_TR]$ adop phase=c
There is another option which specifies cleanup mode with which full statistics is taken.

Note: Due to a known issue in Release 12.2.2, full cleanup is is currently available only in Release 12.2.3 and higher

Other Options:

FS Clone
$ adop phase=fs_clone
Abort
$ adop phase=abort
$ adop phase=cleanup 





General Structure:

$ . /EBSapps.env run
$ adop phase=prepare
$ adop phase=apply patches=123456
$ adop phase=finalize
$ adop phase=cutover
$ . /EBSapps.env run
$ adop phase=cleanup


How to abort a Patch Process - Rollback: 

We would want to abort a patch if we are failing during a patching process.If we cant solve the problem, the need to abort the cycle arises. To abort a patch, first we need to be at a status before cleanup phase.

The abort command is only available until successful completion of the cutover phase. After cutover completes, the system is running on the new edition and abort is no longer available for that
patching cycle. Warning: Aborting a patching cycle will drop the patch edition, but you must then run the cleanup and fs_clone phases before starting a new patching cycle. The cleanup must be a full cleanup ($ adop phase=cleanup cleanup_mode=full).

$ adop phase=prepare
$ adop phase=apply patches=123456
[Patch application encounters problems and you want to abort]
$ adop phase=abort
$ adop phase=cleanup cleanup_mode=full
$ adop phase=fs_clone

Patch - Patching Parameters:

In there reference-4, we have added a link which shows us the available patching parameters that can be used with adop.

 adop phase=prepare workers=1  

The command above is an example for that. We could use workers parameter with adop.


Where are the Adop Logs?

Adop logs are placed into the $ADOP_LOG_HOME which is in the non editione application file system." For example: /u01/install/APPS/fs_ne/EBSapps/log/adop"

In that folder, in the session id that we are in, we would see all the phases that we have done like "Prepare,Finalize,Apply,Cutover,Cleanup,Abort". Other than that within everyone of these folders, everything regarding that phase is inserted like subroutines depending on their execution time.

That is how we could find the related log file.

Inside the $ADOP_LOG_HOME:



Inside the directory of the patch session id:




References:
1-Developing and Deploying Customizations in Oracle E-Business Suite Release 12.2 (Doc ID 1577661.1)
2-Patching Utilities - Adop: http://docs.oracle.com/cd/E26401_01/doc.122/e22954/T202991T531062.htm
3-Validations done by adop-

4-Patching Parameters - http://docs.oracle.com/cd/E26401_01/doc.122/e22954/T202991T531062.htm