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)

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)

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-

Oracle E-Business Suite Release 12.2: Validations Performed By the adop Online Patching Utility (Doc ID 1678355.1) 4-Patching Parameters - http://docs.oracle.com/cd/E26401_01/doc.122/e22954/T202991T531062.htm

Oracle E-Business Suite: Increasing Patch Level - Patch Seviyesini Yükseltmek - Upgrading to 12.1.3.+

Patch seviyesini yükseltme ihtiyacımız en son çıkan 12.1.3. RPC'isinden sonra ortaya çıktı. (Recommended Patch Collection). Bu RPC R12.1.3. için bir ilk olarak çıkartılmıştır.(RPC1) RPC1 12.1.3 versiyonu için tavsiye edilen patch'lerin bir araya getirilmiş halidir. İlgili metalink notu aşağıdaki linktedir.

Oracle E-Business Suite Release 12.1.3+ Recommended Patch Collection 1 (RPC1) (Doc ID 1638535.1)

Bunu yüklemek için versiyonumuz 12.1.3. olmaldır. 12.1.3. versiyonunda bireysel patch'ler olduğu gibi RUP yani Release Update Pack'ler ve ürüne özel RPC (Recommended Patch Collection)'lar bulunmaktadır. Normal versiyonumuzun üzerine patch çıkmak, gerekli patch'leri aramak zaman aldığı için böyle patch'lerin bir araya getirilip sunulması bizim için büyük bir kolaylık sağlar.  Bu RPC'nin birleştirildiği patch numarası ise Patch 17774755:12.1.0'dır.

Patch Seviyesini Yükseltmek:

RPC1 patch'i için bulunan ihtiyaçlar listesine baktığımızda versiyonumuzun 12.1.3 olması gerektiğini , AD'nin de delta 4 versiyonunda olması gerekir. (AD=Applications DBA)

• 12.1.3
• R12.AD.B.delta.3
• R12.AD.B.delta.4
• R12.ADO.B.delta.4

Kısaltmaların ne demek olduğunu aşağıdaki sorguyla görebiliriz.

 select fa.application_id,  
 fa.application_short_name,  
 fpi.status,  
 fatl.application_name,fpi.patch_level  
 from  
 fnd_product_installations fpi,  
 fnd_application fa,  
 fnd_application_tl fatl  
 where  
 (  
 fa.application_id = fpi.application_id and  
 fa.application_id = fatl.application_id and  
 fatl.language = 'US'  
 and fa.application_short_name like '%AD%'  
 )  
 order by fa.application_short_name;  
   

Yukarıdaki programlardan Applications DBA dışındaki programlarının herbirinin yüklü olması gerekmez. Eğer program yüklü değilse doğal olarak patch içinde prerequisite olarak gösterilmesinin bir anlamı olmaz. Bu patch yüklendiğinde de, o program ile ilgili patch'lerin bir anlamı olmaz.

Bizdeki Applications DBA yani AD patch'i R12.AD.B.delta 3 olduğu için, bunu yükseltmek için

Oracle Support sayfasına gidip aşağıdaki gibi patch'imizi indirebiliriz.

İndirdikten sonra patch seviyemiz prerequisite'leri karşılamış hale gelir. Yani versiyonumuz zaten 12.1.3.'tü Şimdi de AD  delta 4 seviyesine gelmiş olduk.

Referanslar:

http://www.dba-oracle.com/t_oracle_applications_modules.htm

https://blogs.oracle.com/stevenChan/entry/ebs_12_1_3_rpc1

Oracle E-Business Suite: Patch'lerden Geri Dönüş - Backing Out Patches and Restoring To A Previous State

Uygulanan patch'lerden bazıları bazen hata geri döndürebilir. Bu durumda apply edilmiş patch'ler geri döndürülmez. Hatalı halleriyle kalırlar. Oracle tarafından da otomatize edilmiş patch'ten geri dönüş yolu yoktur. Bu yüzden hatalı patch'leri düzeltme adımları vardır. Yani bakılacak aşamalar, kontrol edilecek işlemler bulunmaktadır.

Bu yüzden 5-10 mb'tan yüksek patch'ler için backup alınmalıdır. Hem veritabanı backup'ı hem de application backup'ı alınmalıdır.

Eğer bir patch hata alırsa:

1- Hatanın nedenini belirlemek:

Hatanın nedeni genelde ekranda ortaya çıkar. Ancak ekranda çalışıyor gibi gözüküyorsa eğer bu durumda bakılacak belirli yerler vardır. Öncelikle bakacağımız yer "adctrl" tool'udur.

Bu tool'u çalıştırıp worker'ların durumunu görebilir ve loglarına bakabiliriz. Bu logları okuyaraktan hangi form, procedure,sql veya script'de hata ile karşılaşıldığı bulunabilinir.

Bu işlemler dışında adpatch loguna bakabiliriz. Bu patch log'u genelde adpatch'in çalıştırıldığı yere konur. Ancak özel bir yer belirtilmediyse $APPL_TOP/admin/$SID/log altına konur. Dosyanın ismi bilinmiyorsa "ls -lrt" komutyla patch sırasında en son değişen dosya bulunabilinir. Bu şekilde hatayla ilgili daha fazla bilgi edinebiliriz.

Hatalarla ilgili baktığımız diğer log lokasyonları da buradaki gibidir.

2-  Bununla İlgili Yapılacak Aksiyonları Belirlemek:

Yukarıdaki belirttiğimiz log dosyalarına bakıp, hata alan işlemleri düzeltmeye çalışabiliriz.

3-  Dosyaları Eski Yerlerine Koymak:

Adpatch dosyaları uygularken eğer bulunduğu klasördeki doküman, değiştireceği dokümandan daha yeniyse eğer, bu dosya (patch_klasörü)/backup/($SID)/($HOSTNAME) kendi ilişkili klasörü altına yedeklenir. Eğer patch çok büyükse patch uygulamadan önceki aldığımız "Apps" dizini backup'ından bütün sistem dönülür.

4- Relink'lemek:

Dosyaların bozulma ihtimaline karşı relink işlemi gerçekleştirilir. Bunun için bozulan dosyalar belirlenir ve adrelink ile tekrar bağlantıları sağlanır.

5- Java Dosyalarını Geri Döndürmek:

Java dosyaları patch sırasında değiştirildiyse eğer  bu dizinden (patch_klasörü)/backup/($SID)/($HOSTNAME) java dosyaları geri döndürülür.

 $ adjava -mx256m oracle.apps.ad.jri.adjcopy @undoScript.cmd 

6- Jar Dosylarının Tekrar Yaratılması: 

Java dosyalarını yukarı da belirttiğimiz gibi tekrar ürettiysek, o zaman Jar dosyalarını da tekrar yaratmalıyız. Bu işlemleri de Adadmin aracıyla yapabiliriz.

7- İlişkili Form'ların Tekrar Yaratılması:

En son olarak da etkilenen bütün modüllerin formlarının compile'ı adadmin ile gerçekleştirilir.

Oracle E-Business Suite: Patch Application Assistant - PAA

Patch Application Assistant kısaca PAA bize Oracle E-Business Suite'de patch geçme konusunda çok büyük kolaylık sağlamaktadır. PAA ile bir patch geçimi için gereklilikleri güzel bir arayüzle görebiliriz. Bu bir arayüz olduğu için "DISPLAY" parametresinin aktif olması gerekir. Eğer arayüz yoksa vncserver veya benzeri bir program ile bağlantı yapmamız gerekir.

Bağlantı yaptıktan sonra $APPL_TOP/$APPLENV dosyasını çalıştırır ve ortamı set ederiz. Sonrasında patch'in driver'ının bulunduğu klasöre gideriz ve bu klasör de "admsi.pl" dosyasını çalışıtırırız. Çalıştırdıktan sonra aşağıdaki gibi bir ekran görüntüsü elde ederiz. Burada patch'in bulunduğu klasörün adını ve Apps kulla nıcısnın şifresini girmemiz gerekir.

Bu bilgileri girdikten sonra karşımıza aşağıdaki gibi bir ekran çıkar. Bu ekrandan patch'imizle ilgili uygulanması gereken prerequisite'ler, post-installation task'leri gibi şeyler varsa görebiliriz.

Bu sırada başka bir ekrandan burada istenen işlemleri gerçekletiririz. Bu uygulamayla biz patch uygulamayız. Sadece patch için gereken işlemleri rahat gerçekleştirmek için yararlanırız. Bütün işlemleri gerçekleştirip "next" dediğimizde yapılması zorunlu işlemlerden hangilerinini yapıldığını "Completed" sütununda tıklı olarak görürsek yaptığımız işlemlerin başarıyla gerçekleştirildiğini bilebiliriz.

Oracle E-Business Suite: EBS Patch Geçme Prosedürü - EBS Patching Procedures

Oracle E-Business Suite'de patch geçmek için belli başlı adımları takip etmemiz gerekir. Patch işlemine başlamadan önce her zaman uygulamanın kapatılması "adstpall.sh" ve uygulamanın maintenance mode'a alınması (Adadmin>Enable Maintenance Mode)tavsiye edilir.

1- Patch Readme'sini Okuma:

Patch Readme dosyası, patch klasörünün içinde bulunur. Bu dosyada her patch öncesi,sırası ve sonrasında eğer varsa uygulanması gereken adımları belirtilir. Okunması ve buradaki adımların gerçekleştirilmesi çok önemlidir. Patch'in sağlıklı bir şekilde geçilmesini sağlar.

Bununla ilgili bir Oracle tool'u da bulunmaktadır. Bu yazımızda bununla ilgili bilgileri görebiliriz.


2- Patch Gerekliliklerini (Prerequisites) Gerçekleştirme:

Bu adım Readme dosyasında Pre-Install Tasks başlığı altında gösterilir. Aynı zamanda bu patch'in üzerine kurulması gereken  patch'ler de "Additional Information" başlığı altında gösterilir.

Patch gereklilikleri elle gerçekleştirilmesi gereken adımlarda olabilir. Bir dosyanın başka bir yere elle kopyalanması, formların compile edilmesi veya invalid object'lerin düzeltilmesi gibi işlemler olabilir.

Önceki istenen patch'lerin kurulması veya istenen patch seviyelerinin kontrolü önemlidir. Buna göre patch'ler başarıyla geçilebilinir.


3- Patch Apply Etme:

Patch'i uygulamamız için terminal de "adpatch" komutunu vermemiz gerekir. İlk olarak patch'in bulunduğu klasöre gidip, orada adpatch komutunu çalıştırırız.Sonrasında gereken cevaplar verilerek uygulama safhasına kadar gelinir. Bize en son patch klasörü içinde bulunup bulunmadığımız ve patch dosyasının ismi sorulur. Bu sorular sorulduktan sonra patch apply edilmeye başlanır.

Patch apply edilirken eğer dil bakımından başka bir opsiyon varsa bu opsiyon patch uygulanmadan önce sorulur. Eğer patch'in "Türkçesi" varsa bu patch "US" versiyonundan sonra uygulanmalıdır. İlk önce "US" yani "American"  patch versiyonu uygulanır. Ertesinde "Türkçe" versiyonu uygulanır. Patch uygulanırken bunun temin edilmesi gerektiği belirtilir sadece. Sonrasında uygulanan adımlar ve yapılan işlemler ekranda gösterilir.

Patch Test Etme:

Patch'in etkilerini gözlemlemek için patch'leri ilk olarak test ortamlarına uygularız. Ancak eğer test ortamımız yoksa patch'i uygulamadan yükleriz. Yani "adpatch apply=no" komutunu veririz. Böylece patch tarafından gerçekleştirilecek hareketler listelenir ancak veritabanı veya dosya sisteminde bir değişiklik gerçekleştirilmez.

4- Post Installation Adımları:

Post installation adımları, pre-installation adımları gibi uygulanması gereken adımlardır. Bu adımlarda patch'in sağlıklı bir şekilde bitirilmesi ve sorunun ortadan kaldırılması için önemlidir.

5- Patch Kurulumunun Kontrolleri:

Bununla ilgili kontroller genellikle patch klasörü içindeki "Readme.txt" 'i içerisinde belirtilir. Bu kontrolleri veritabanını sorgulayaraktan veya uygulamada uygun yerleri kontrol ederekten yapabiliriz.

Genelde patch'ler kurulduktan bazı dosyaların versiyonları değişir. Bu versiyon değişimlerini bu yazımızda belirttiğimiz gibi kontrol edebiliriz.

Uygulamadan kontrol etmek istiyorsak da "System Administrator" sorumluluğuna giderekten  "Dashboard" fonksiyonuna tıklayıp giriş yapıp oradan "Software Update" seçeneğini seçeriz

Software Update

2. yöntem olarak "System Administrator" sorumluluğunun altında "Patching and Utilites" sekmesine girip oradan patch numarasına bakabiliriz.

Patching and Utilities

Veritabanından patch'in kurulumunu kontrol etmek istiyorsak ad_applied_patches veya ad_bugs tablolarını kontrol edebiliriz. "ad_bugs" tablosu patch'lerin varlığını kontrol etmek için daha garanti bir yoldur; çünkü bazı patch'ler diğer patch'lerle merge edilmiş olabilirler. Bu yüzden "ad_applied_patches" tablosunda görünmeyebilirler. Uygulamadan kontrol etmek de her zaman garanti bir yoldur.

Oracle E-Business Suite: Dosya Versiyonlarının Kontrolü - Checking The Versions of The Files

Oracle E-Business Suite'de dosya ve sistemin versiyonlarının kontrol edilmesi, patch geçilmesi sırasında gerekebilmektedir. Bazı patch'lerde kontrol yapmak için bizden dosyaların versiyonları istenmektedir. Bunun için genel istekleri sıralarsak:

-Application versiyonu için:

 select release_name from apps.fnd_product_Groups;  

-Herhangi bir form'un veya report'un dosya versiyonunu bulmak için:

strings -a form_ismi | grep Header 

Örnek:

strings -a APXINWKB.fmb | grep Header 

Başka bir yöntem ise aşağıdaki komutu kullanmaktır.

 adident Header form_ismi

-Application Product, Patch Set Level, Code Level:

Patch'lerde gözüken, ve prerequisite olarak bazen istenen bilgiler olarak Application Product ya da Patch Set Level ya Code Level aşağıdaki sorguyla bulunabilinir. Örneğin Application DBA uygulaması için Patch Set Level'ı aşağıdaki sorgunun sonucudur.

select patch_level from fnd_product_installations where patch_level like '%AD%'; 

Eğer başka bir uygulama için isteniyorsa da "AD" yerine o uygulamanın kısa adını yazabiliriz.

Bu sorguyla yine diğer bütün uygulamaların seviyelerini bulabiliriz.

 select APP_SHORT_NAME, max(PATCH_LEVEL) from AD_PATCH_DRIVER_MINIPKS GROUP BY APP_SHORT_NAME;

Uygulamanın geliştirilme versiyonları aşağıdaki sorguyla bulunabilinir.

 select ARU_RELEASE_NAME||'.'||MINOR_VERSION||'.'||TAPE_VERSION version,  
  START_DATE_ACTIVE updated, END_DATE_ACTIVE "when lasted",  
  CASE WHEN BASE_RELEASE_FLAG = 'Y' Then 'BASE VERSION'  
  ELSE 'Upgrade' END "BASE/UPGRADE", ROW_SOURCE_COMMENTS "how it is done"  
  from APPS.AD_RELEASES; 

Oracle Veritabanı ve E-Business Suite: My Oracle Support(Metalink)'ten Nasıl Patch İndirilir? - How To Download a Patch For EBS or Oracle Database

Oracle'ın bütün ürünleri için aşağıdaki adımları izleyerek patch'ler indirebiliriz. Burada anlattığımız yollar Oracle Veritabanı ve Oracle E-Business Suite özelinde hazırlanmıştır ancak diğer ürünler içinde nereden indirilebileceğini aşağıdaki yoldan görebiliriz. İlk olarak My Oracle Support sayfasına gitmemiz gerekir. Bu ana sayfadan diğer yerlere yönlenebiliriz.

Bu sayfadan sonra yukarıdaki tab'dan "Patches & Updates" sekmesine tıklarız.

 Bu örnek için özel olarak patch numarasını bildiğimiz için buna göre bir arama gerçekleştiririz. Üzerine yükleyeceğimiz patch'i de seçip "search" düğmesine tıklayınca bununla ilgili sonuçlar aşağıdaki gibi karşımıza çıkar.

Bu patch arama işlemi sonrasında çıkan sayfada gerekli seçeneklleri seçeriz. Bazen versiyon seçenekleri, dil seçenekleri ve platform tipini sorabilmektedir. Aşağıdaki örnek için sadece dil seçeneğini seçeriz. Dil olarak türkçe seçmemiz önemlidir; çünkü sistemimiz türkçe'dir. Tabi bu duruma göre değişir. Türkçe'yi direk seçersek beraberinde US versiyonu da birlikte gelmektedir. Eğer EBS kurulumunda olduğu gibi US versiyonu Base installation'la birlikte gelmektedir. Yani default kurulumla birlikte gelir. Eğer Türkçeyi seçersek  yanında US versiyonunu da indirmek için soracaktır.

Burada da US versiyonunu indirmek için sormaktadır; çünkü öncesinde  versiyonu Türkçe olarak belirtmiştik.

Buradan her ikisini de indiririz.

Yukarıdaki resim de ise Oracle Database için nasıl patch indirilebileceğini görmekteyiz. Ürün olarak Oracle Database seçtikten sonra versiyonumuzu ve platformumuzu seçeriz. Sonrasında "Search"  diyip buna uygun patch'ler karşımıza çıkar

Karşımıza çıkan sonuçlardan istediğimizi seçip aşağıdaki örnekteki gibi indirip kurabiliriz.

Oracle E-Business Suite: Patch Impact Analysis - Patch'lerin Uygulanmasının Sonuçları - Etkilerinin Analizi

Oracle DBA'lerinin en genel işleri arasında veritabanı ortamlarına patch'lerin geçilmesi yer almaktadır. Bu geçilen patch'lerin etkilerinin analiz edilmesi, herhangi bir sorun durumunda hangi dosyaların etkilendiğinin görülmesi çok önemlidir. Bunun için aşağıdaki sorguyu kullanabiliriz.

 select f.bug_number "BUG_NBR",  
 a.filename "FILE_NAME",  
 substr(c.version,1,20) "PATCH_VERSION",  
 substr(d.version,1,20) "SITE_VERSION",  
 b.executed_flag,  
 b.creation_date "PATCH_DATE"  
 from  
 ad_files a,  
 ad_patch_run_bug_actions b,  
 ad_file_versions c,  
 ad_file_versions d,  
 ad_patch_run_bugs e,  
 ad_bugs f  
 where a.file_id=b.file_id  
 and c.file_version_id=b.patch_file_version_id  
 and d.file_version_id=b.onsite_file_version_id  
 and b.executed_flag = 'Y'  
 and e.bug_id=f.bug_id  
 and e.patch_run_bug_id=b.patch_run_bug_id  
 and f.bug_number='&Patch_number'  
 order by b.creation_date desc;  

Bu sorguda bizden patch numarası istenir. Bunun sonucunda bize etkilenen dosyalar gösterilir.

Oracle E-Business Suite Console'dan Patch Impact Analysis Nasıl Yapılır?

Bu işlem için Oracle Application Manager'a bağlanılır. Oradan "System Administrator" sorumluluğuna tıklayıp karşımıza çıkan ekranda "Site Map">"Maintenance">"Patch Wizard" seçeneklerine tıklayıp "Recommend Patches" işine tıklarız. Buradan da araştırdığımız patch numarasını girip araştırma "Patch Impact Analysis" yapabiliriz.