Oracle Database: Compiling Invalid Objects Continued - Invalid Objelerin Compile Edilmesi Devam

During our health check, ıt appeared to us that we were working with invalid objects and we thought that there must be some script Oracle has done for it. We found out that we were right .

Oracle has 2 scripts for it. "Utlprp.sql" and "Utlrp.sql" which are found under $ORACLE_HOME/rdbms/admin.

It asks for just one input value. Its answer must be given accordingly.
0 - The level of parallelism is derived based on the CPU_COUNT parameter.
1 - The recompilation is run serially, one object at a time.
N - The recompilation is run in parallel with "N" number of threads.

Both scripts must be run as the SYS user, or another user with SYSDBA, to work correctly.
However sometimes we need to some manuel compilation.

For example the following states a compilation of package.

 BEGIN  
  FOR cur_rec IN (SELECT owner,  
              object_name,  
              object_type,  
              DECODE(object_type, 'PACKAGE', 1,  
                        'PACKAGE BODY', 2, 2) AS recompile_order  
          FROM  dba_objects  
          WHERE object_type IN ('PACKAGE', 'PACKAGE BODY')  
          AND  status != 'VALID'  
          ORDER BY 4)  
  LOOP  
   BEGIN  
    IF cur_rec.object_type = 'PACKAGE' THEN  
     EXECUTE IMMEDIATE 'ALTER ' || cur_rec.object_type ||   
       ' "' || cur_rec.owner || '"."' || cur_rec.object_name || '" COMPILE';  
    ElSE  
     EXECUTE IMMEDIATE 'ALTER PACKAGE "' || cur_rec.owner ||   
       '"."' || cur_rec.object_name || '" COMPILE BODY';  
    END IF;  
   EXCEPTION  
    WHEN OTHERS THEN  
     DBMS_OUTPUT.put_line(cur_rec.object_type || ' : ' || cur_rec.owner ||   
                ' : ' || cur_rec.object_name);  
   END;  
  END LOOP;  
 END;  
 / 

References:

1- Compile Invalid Objects

http://oracle-base.com/articles/misc/recompiling-invalid-schema-objects.php

Oracle Database: Error ORA-48165 In the Sqlnet.log File

 ORA-48165 this error was noticed while we were checking for sqlnet.ora log file.  The error message was like the following.


--------
NL-08014: Failed to initialize Diagnosability framework, falling back to old network tracing/logging

 NL-08015: Client(OCI) side initialization of Diagnosability framework failed
  ORA-48165: user missing read, write, or exec permission on specified ADR Base directory []
User inputted base directory is invalid [48187] [/u01/E-BIZ/db/tech_st/11.2.0/admin/VISION_slc01ozg]

--------

This message was in fact indicating us that we had misconfiguration in our sqlnet.ora file. Therefore we had to change it.

Solution:

Go to $ORACLE_HOME/network/admin and then change the ADR_BASE to the correct value.

The correct value has to be value of the diagnostic_dest:

SQL> show parameter diag

NAME                                 TYPE        VALUE

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

diagnostic_dest                      string      /u01/install/PROD/11.2.0/admin

                                                 /TEST_DBMACHINE

References:

1-http://onlineappsdba.blogspot.com.tr/2007/11/oracle-11g-alert-log-file.html

2- Oracle Documentation About Network Connectivity Issues:

https://docs.oracle.com/cd/A57673_01/DOC/net/doc/NWTR23/apa.htm

Oracle E-Business Suite: Forms Compilation Error - Form Derleme Hatası

In R12.1.3

Recently we have encountered errors such as these:


Compiling KEY-NXTBLK trigger on QUERY_FIND data block...
Compilation error on KEY-NXTBLK trigger on QUERY_FIND data block:
PL/SQL ERROR 49 at line 1, column 1
bad bind variable 'parameter.G_query_find'
PL/SQL ERROR 49 at line 1, column 1
bad bind variable 'parameter.G_query_find'
PL/SQL ERROR 49 at line 3, column 1
bad bind variable 'parameter.G_query_find'

It turned out that FORMS60_PATH was not set correctly. Whenever forms are compiled FORMS60_PATH is set to:

FORMS60_PATH=$FORMS60_PATH:$AU_TOP/forms/US:$AU_TOP/resource

In context file it was set as:

$AU_TOP/resource:$AU_TOP/resource/stub

After correcting this and compiling manually it worked. To make this permanent change the s_f60path to include $AU_TOP/forms/US:$AU_TOP/resource

In R12.2.4 or in R12.2 we should be adding the following to the $FORMS_PATH variable in the context file which is in the $APPL_TOP/$SID_$HOSTNAME.env path  

$AU_TOP/forms/US:$AU_TOP/forms/TR 

After that forms can be compiled with the following command.

E.g.:

frmcmp_batch AKDFLOWB.fmb   apps/apps output_file=$AK_TOP/forms/TR/AKDFLOWB.fmx compile_all=special;


Referanslar:

Forms Compilation hatası
http://oracleappstechnology.blogspot.com.tr/2009/03/forms-compilation-errors.html

Oracle E-Business Suite: Error - JVM Leaked Connections:

"System Administrator > System Administration:Diagnostics > AOL/J Database Connection Pool Status" altında Java bağlantılarıyla ilgili belirli istatistikleri gösteren bir ekran vardır. Bu ekranın önemi veritabanına yapılan JDBC bağlantılarının performans düşüklüklerine neden olabilmesidir.

JDBC bağlantıları Java  programları ile veritabanları arasındaki bağlantıyı sağlamaktadır. Java JDBC bağlantılarıyla çalıştırılan SQL'lerin sonuçları geri döndürülür.

Bu ekranda "leaked connections" bağlantısına tıkladığımızda aşağıdaki gibi bir hata görebiliriz.

oracle.apps.fnd.security.LeakedConnectionException 1, 0x1421fc8, 2010-05-17+14:09:23.745-0700,   
 Thread[AJPRequestHandler-HTTPThreadGroup-12,5,HTTPThreadGroup]  
 at oracle.apps.fnd.security.CallStack.getInstance(CallStack.java:109)  
 at oracle.apps.fnd.security.DBConnObj.setBorrowingThread(DBConnObj.java:990)  
 at oracle.apps.fnd.security.DBConnObj.setBorrowingThread(DBConnObj.java:973)  
 at oracle.apps.fnd.common.Pool.costBasedSelection(Pool.java:1885)  
 at oracle.apps.fnd.common.Pool.selectObject(Pool.java:1686)  
 at oracle.apps.fnd.common.Pool.borrowObject(Pool.java:950)  
 at oracle.apps.fnd.security.DBConnObjPool.borrowObject(DBConnObjPool.java:584)  
 at oracle.apps.fnd.security.AppsConnectionManager.borrowConnection(AppsConnectionManager.java:330)  
 at oracle.apps.fnd.common.Context.borrowConnection(Context.java:1719)  
 at oracle.apps.fnd.common.AppsContext.getPrivateConnectionFinal(AppsContext.java:2314)

Eğer bunlardan çok varsa bir bug'a bağlantılı olarak bunlar çıkıyor olabilir. Eğer durum böyleyse bunlar gerçek olmayan sızmalardır. Bağlantılar pool'a geri döndürüldüğünde ve boş bağlantı kalmadığında oluşmaktadır. Bunun için 9907719 nolu patch indirilmeli ve uygulanmalıdır.

Connection Leakage Nedir?

Bir uygulama aldığı bağlantıyı belirtilen bir sürede geri vermez ise bununla ilgili uyarı burada çıkar.

Connection Lock Nedir?

Eğer DML operasyonları JDBC bağlantıları içerisinde gerçekleştirilip commit edilmiyorlarsa, o connection bu işi gerçekleştirene kadar locked olarak kalır.

Connection Leakage Nasıl Tespit Edilir?

Veritabanına bağlantı yapan modülleri aşağıdaki sorguyla incelemeliyiz. Eğer bu liste sürekli büyüyorsa burada bir sorun olduğunu düşünebiliriz.

 select s.machine, s.username, s.module, s.inst_id, count(*) how_many  
 from (select distinct PROGRAM, PADDR, machine, username, module, inst_id from gV$SESSION) s,  
 gv$process p  
 where s.paddr = p.addr  
 and p.inst_id = s.inst_id  
 group by s.machine,s.username, s.module, s.inst_id;  

Toplam sayıyı görmek için:

 select sum(how_many) from (select s.machine, s.username, s.module, s.inst_id, count(*) how_many  
 from (select distinct PROGRAM, PADDR, machine, username, module, inst_id from gV$SESSION) s,  
 gv$process p  
 where s.paddr = p.addr  
 and p.inst_id = s.inst_id  
 group by s.machine,s.username, s.module, s.inst_id);

Yine v$session tablosunu sorgulayaraktan hangi session'ların 24 saatten fazla açık kaldığına bakabiliriz. Sonrasında bu sessionlar incelenebilir ve kapatılabilinir.

select a.* from v$session a where sysdate-logon_time>24 and type!='BACKGROUND'; 

Referans:
1-http://oracledbascriptsfromajith.blogspot.com.tr/2010/10/how-to-prevent-inactive-jdbc.html
2-Connection Leak: Find LeakedConnectionException Reported in AOLJ Database Connection Pool Test (Doc ID 1177093.1)
3-http://ora-players.blogspot.com.tr/2011/08/jvm-taking-high-cpu-toooooooo-many-jdbc.html
4-Basic troubleshooting of JVM consuming CPU or too many JDBC connections in EBS Apps 11i (Doc ID 370583.1)
5-AOL/J JDBC Connection Pool White Paper (Doc ID 278868.1)

6-https://blogs.oracle.com/stevenChan/entry/understanding_jdbc_connections
7-Connection Leakage Problem - Tracking : http://mukx.blogspot.com.tr/2010/07/jdbc-connections-leakage-and.html
8-Understanding JDBC Connection: https://blogs.oracle.com/stevenChan/entry/understanding_jdbc_connections

Oracle E-Business Suite: Error - Workflow Mailer Will Not Start Stays In Starting Status - Workflow Mailer'ın Starting Mode'da Kalması

Workflow Mailer'da karşılaştığım bir hataya göre workflow notification mailer starting mode'da kalıyordu. Bunun için yaptığımız workflow container'ını restart etme ve uygulamayı açıp kapama işe yaramadı. Bunun üzerine yaptığım araştırmalara "notification mailer"'ın logunda bağlantıyla ilgili bir sorun olduğunu gördüm. Buna istinaden System Administrator>Workflow Manager>Edit>Advanced seçeneklerini seçip ayarları doğruladım. Buradan da gördüğüme göre uygulamanın mail sunucusuna bağlantısı sorunluydu.

Özetle workflow notification'daki sorunu görmek için ayarları doğruladım. Sonrasındaki bağlantı sorununu uygulama sununcusu adminleriyle çözebildik.

Referanslar:
Workflow Mailer Will Not Start Stays In Starting Status [ID 837893.1]
Unable To Start Workflow Notification Mailer [ID 418329.1]
Unable To Start Notification Mailer After Upgrade To 10.2.0.3 [ID 725852.1]
Unable To Connect To The Mail Account. Check The Host, User Name And Password [ID 1123684.1]
How to Troubleshoot 'Validation failed' Errors when Starting the Mailer [ID 463354.1]
Cannot Start Workflow Notification Mailer. 'System Deactivated' [ID 602624.1]
Unable To Perform The Workflow Mailer Configuration As It Keeps Giving "Validation Error Occured" [ID 603954.1]
SvcComponentException:Validation failed for the following parameters "PROCESSOR_READ_TIMEOUT' Causing Workflow Deferred Agent Listener to be Down. [ID 604775.1]
Java Mailer not Starting Error in Handling Component Event [ID 297725.1]

Oracle E-Business Suite: Error - Beyaz Ekran Hatası - Blank Login Page Screen - Unable To Access Login Page in Oracle Apps R12

Oracle E-Business Suite'de giriş yapıldığında beyaz ekran gözüküpde de ekranda hiçbir şey yüklenmezse yapabileceğimiz ilk işlerden biri cache dosyalarını temizlemek olacaktır. Bunun için ilk önce:

1- Uygulama kapatılır.

2- Jsp dosyaları elle derlenir.

 perl $FND_TOP/patch/115/bin/ojspCompile.pl –compile –flush -p 2 

3- Jsp dosyalari derlendikten sonra uygulama tekrar çalıştırılır.

4- Tarayıcının cache'i de temizlenir. Bunu yapmak için ctrl+f5 yapmamız yeterlidir.


Alternatif Yöntem:

Bununla ilgili başka bir çözümde bazı parametrelerin değiştirilmesi önerilmektedir.

1- Uygulamayı kapatırız. Ertesinde parametre olarak "s_jsp_main_mode"'dir. Parametre dosyamızda  $CONTEXT_FILE değişikliklerini yaparız.

Eski hali:

justrun

Yeni hali:

recompile
2- Sonrada autoconfig çalıştırılır. Autoconfig çalıştırdıktan sonra da mutlaka afterconfig.sh çalıştırırız.

3- Uygulama bunun ertesinde uygulama tekrar açılır.


Referanslar:
Oracle E-Business Suite R12 - Login Page showing a blank page Occuring Intermittently (Doc ID 1491845.1)
http://oraclepitstop.wordpress.com/2008/09/12/blank-appslogin-appslocallogin-page-in-r12/
http://appsdbatechstuff.blogspot.com.tr/2010/10/getting-blank-page-when-accessing.html
http://oracleappstechnology.blogspot.com.tr/2009/02/appslocalloginjsp-page-takes-forever-to.html
https://community.oracle.com/thread/2262815?tstart=0

Oracle Veritabanı: Oracle Error ORA-48913 Caught While Writing To Trace Files

ORA-48913 hatası trace file'ımız yeterince büyük olmadığı zaman karşılaştığımız bir hatadır. Alert loglarımızıda karşılaşabiliriz. Sistemimize yoğun bir yük geldiğinde bu yükle ilgili gerekli bilgiler loglanır ve trace file'a yazılır. Trace file'da yeterince yer olmadığında, bununla ilgili bir hata alert log'a yazılır. Bunu çözmemiz için Oracle'da bulunan bir parametreyi değiştirmemiz gerekir. Bu parametre max_dump_file_size'dir.

show parameter max_dump_file_size;  

Bu parametre kb cinsinden verilmektedir. Default değeri 10mb'dır. Bu parametreyi değiştirmek için, aşağıda tırnak içindeki kısma istediğimiz değeri yazabiliriz.

 alter system set max_dump_file_size='' scope=BOTH

Bu parametre dinamik bir parametredir. Hemen değiştirilebilinir.

Oracle E-Business Suite: Dashboard Error - Database Açıkken Host Status Kapalı Gözükmesi - Host Status Is Shown Down While Database is Up

Aşağıdaki hatayla bir uygulamanın klonlanması sonrasında karşılaştım. Uygulamanın Dashboard sayfasındaki  Host Status kısmında çarpı gözükmesine rağmen uygulamanın veritabanı açık durumdadır.

Bu durumun düzeltilmesi için aşağıdaki durumu kontrol ettim.

 select node_name, status, node_mode   
 From fnd_nodes   
 Where node_mode = 'O'  

Bunun sorgu sonucunda aşağıdaki gibi bir çıktı aldım.

Burada olması gerek durum her makinenin karşısındaki "Status" kolonunun 'Y' ve Node_mode kolonunun 'O' olması gerekmektedir.

Bunu da aşağıdaki sorguyla düzeltebiliriz.

 update fnd_nodes set status='Y' where status='N';  

Bu sorguyu da commit ettikten sonra sorunumuzun düzelip düzelmediğini kontrol ederiz.

Oracle Veritabanı: Oracle Error ORA-28 Opiodr Aborting Process Unknown Ospid

Bu hata bilgi maiyetinde bir hatadır. Kullanıcının session'ınının bir dba veya yetkili birisi tarafından kill edildiğinde çıkar.

Oracle Veritabanı: Oracle Error ORA-1031 Signalled During ...

Oracle veritabanında bazen gerçekleştirmek istediğimiz işlemlere yetkimiz yetmediğinde bu hata ile karşılaşırız. Bu hatayı aşmamız için ya DBA'lere başvurmalıyız ya da yetkisi olan bir kullanıcı ile bağlanmalıyız.

Oracle E-Business Suite: Error - Gönderilmeyen E-Postalar - Unsent Worklow E-Mail

Oracle E-Business Suite'de gönderilemeyen e-postalar için bir uyarı ekranı vardır. Bu uyarı ekranı System Administrator sorumluluğu altında Dashboard seçeneğindeki Performance tab'ı altında görülebilinir. (System Administrator>Dashboard>Performance). Bu Performance tab'ı altında Activity adlı parça altında "Unsent Workflow E-Mail" olarak gözüken kısım da bu belirttiğimiz uyarı bilgisi yer alır. Bu uyarı aşağıdaki gibidir.

Bu örneğimizde 5 tane gönderilememiş e-posta olduğu gözükmektedir. Bunu veritabanından da görmek istersek aşağıdaki ekrandaki sorguyu kullanabiliriz.

 select * from wf_notifications where mail_status='MAIL' and end_date is not null and status='CLOSED';

Bu uyarıyı düzeltmek için veritabanında bir sorgu girmemiz gerekir.

 update wf_notifications  
 set mail_status = 'SENT'  
 where end_date is not null  
 and status = 'CLOSED'  
 and MAIL_STATUS = 'MAIL';  
   
 commit;  

Yukarıdaki sorguyu çalıştırdığımızda en başta belirttiğimiz ekrandaki uyarı 0'lanır.

Wf_Notifications Altındaki Gönderilecek Mailler:

Eğer bir mail notification'ın statüsü OPEN ve mail_status MAIL ise bununla ilgili bir mail gönderilecek demektir.

  select notification_id,status,mail_status,begin_date from WF_NOTIFICATIONS where status = 'OPEN' and mail_status = 'MAIL';

Gönderilmemesi İstenen Mailler:

Mail_status'leri Mail olanları Sent olarak değiştirirsek bunlarla ilgili mail atılmaz.

update WF_NOTIFICATIONS set mail_status = 'SENT' where mail_status = 'MAIL';

Workflow Mail'lerinin İptal Edilmesi:

Workflow'ların iptal edilmesini sağlamak için aşağıdaki kodu kullanmamız gerekir. Ancak dikkatli kullanılmalıdır çünkü o an çalışan workflow'lar da iptal edilebilinir. O yüzden bir şart belirtilmelidir.

 DECLARE   
 ln_sayi number;   
 BEGIN   
  ln_sayi := 0;   
   for rec in   
 (select * from apps.wf_notifications where status = 'OPEN' and Mail_status='MAIL' and begin_date

Yukarıdaki kodda bu şart başlangıçtan 7 gün öncesi için belirtilmiştir. 7 gündür açık olan bir notification maili hala mail status'unde gözüküyorsa o zaman bu notification kapatılır.

Wf_Notifications Queue(Sıra) Düzenlemesi:

Şimdi belirteceğimiz sql'i çalıştırarak bekleyen mailleri silip sadece gönderilecek mailleri sırada tutabiliriz.  Bu şekilde yanlış bir işlem yapıp eğer mail miktarını arttırmış olursak bunu bu şekilde düzenleyebiliriz.

 sqlplus apps/apps_pwd @$FND_TOP/patch/115/sql/wfntfqup APPS APPS_PWD APPLSYS

Not:Apps_pwd; apps kullanıcısının şifresidir.

Oracle Veritabanı: Oracle Error ORA-609 : Opiodr Aborting Process Unknown Ospid

ORA-609 hatası uygulama ile veritabanı arasındaki bağlantı kesikliğinden oluşabilir. Alert logumuzda bu hatayı görmek istemiyorsak bununla ilgili bazı parametreleri arttırabiliriz. Oracle 11g'de $ORACLE_HOME/network/admin altında sqlnet.ora dosyasındaki "Sqlnet.inbound_connect_timeout" parametresini  ve yine aynı klasör de bulunan "Inbound_connect_timeout_(listener_ismi)" parametrelerinin değerlerini arttırabiliriz.

Veritabanından herhangi bir session kill edildiğinde de bu uyarı çıkabilir. Yukarıda belirttiğimiz parametre için uygun değer 120 veya 180'dir.

Oracle Veritabanı: Oracle Error ORA-1688: Unable to Extend Table SYS.WRH$_ACTIVE_SESSION_HISTORY

Tablespace'imizin datafile'larında yer kalmadığında ORA-1688 hatasını alırız. Bunun nedeni ya datafile'larımızın ulaşabileceği maksimum boyuta ulaşmasıdır ya da daha fazla genişleyecek yer bulamamasıdır. Bu yüzden datafile eklenmesi ya da datafile'larla ilgili işlem yapılması gerekir.

Yukarıda belirtilen örnek hatamızda SYSAUX tablespace'inde genişleyecek yer bulamayasında Oracle snapshot alamaz hale gelmiştir. SYSAUX tablespace'inde AWR snapshot'ları tutulur. Maksimum ulaşabileceği boyuta gelince (32GB) snapshot alımı durduğunda yukarıdaki tabloda genişleme yapılamadığı belirtilmeiştir.

Bu sorunu SYSAUX tablespace'ine datafile ekleyerek çözebildik. Datafile yönetimi ile ilgili bilgiyi buradan bulabiliriz.

Oracle Veritabanı: ORA-00959 Tablespace Does Not Exist

ORA-00959 genelde bir SQL ifadesinin yanlış tanımlanmasıyla ortaya çıkar. Bu sorunu özel olarak yazmamın nedeni kullanıcılar ile tablespace'lerin karıştırılıyor olmasıdır. Genelde kullanıcılar tablespace'lerle aynı adla yaratılırlar. Bu yüzden buna göre SQL'ler formüle edilirler. Bir object'in yaratıldığı yerin adı illa kullanıcıyla aynı adı taşımak zorunda değildir.

Bu yüzden eğer bu hatayla karşılaşırsak, dba_tablespaces'den bu tablespace'lerin varlığını, dba_users'dan da kullanıcıların varlığı kontrol edilmelidir.

Bu sorun özetle bir kullanıcı hatasıdır.

Oracle Veritabanı: Oracle Error - ORA-00265 Instance Recovery Required - Cannot Set Archivelog Mode

ORA-00265 hatasıyla veritabanmı archivelog mode'a almaya çalıştığımda karşılaşmıştım. Bu hatanın nedeni sistemimi düzgün kapatmamakmış.

Aşağıdaki gibi düzgün açıp kapadıktan sonra veritabanımızı archivelog mode'a alabiliriz.

 startup;  
 shutdown immediate;  
 startup mount;  
 alter database archivelog;  
 alter database open;

Oracle Veritabanı: Oracle Error ORA-01950 No Privileges On Tablespace

Ora-01950 hatasını yeni bir tablespace yaratıp sonrasında içerisinde bir object yaratmak istediğimde aldım. Tablespace talebi sonrasında karşılaştığım bu sorun ertesinde bu tablespace'i kullanan default bir user olmadan genel kullanıcımızla ilgili bir yetki sorunu olabileceğini düşündüm. Yani ilgili tablespace üzerinde apps kullanıcımla yani E-Business Suite'deki en güçlü kullanıcıyla bir tablo yaratmak istediğimde bu sorunu aldım.

Bu sorunu gidermek için de yeni yaratılmış bu tablespace üzerinde apps kullanıcıma aşağıdaki yetkileri verip bu sorunu hallettim.

 ALTER USER apps UNLIMITED QUOTA ON tablespace_adı  
    
 GRANT UNLIMITED TABLESPACE TO apps;  

Oracle Veritabanı: Oracle Error ORA-01918 User Name Does Not Exist

Bu hatayı bir tablespace içerisinde bir object yaratmaya çalıştığım zaman aldım. Ancak bu işlemi yapmaya çalıştığım zaman kullanıcımın schema'sını göremeyip bu hatayı verdi.

Bu sorunun çözümü için ilk olarak gerçekten doğru olarak kullanıcıyı yazıp yazmadığımızı kontrol etmemiz gerekir.

 SELECT * FROM ALL_USERS;  

Eğer yukarıdaki sorgumuzda kullanıcımızı görüyorsak ve daha önceden de buna bağlı tablespace'i yarattıysak şimdi kullanıcımızın gerekli hakları olup olmadığını kontrol etmemiz gerekir.

 SELECT * FROM DBA_ROLES; 

Ayrıca aşağıdaki object'lere de bakmamız gerekebilir. Ayrıcalıklar için en çok sorgulanan object'ler bunlardır.

 dba_role_privs  
 dba_sys_privs  
 dba_tab_privs  

Buralarda gerekli yetkilerin varlığını sorgulayabiliriz. Bunlar için de en önemlileri "connect" ve "resource" yetkileridir. Burada yetkilerini sorguladığımız kullanıcı tablespace içerisinde object yaratmaya çalışan kullanıcıdır.

Sonuç olarak yukarıdaki hatayı aldığımızda ilk önce kullanıcının varlığı ve buna bağlı olarak schema'nın varlığını kontrol ederiz. Ertesinde de o schema üzerinde object yaratabilme yetkilerimizi sorgularız. Bu işlemlerin sonucuna göre aksiyon alabiliriz.

Oracle E-Business Suite: Error - "Concurrent Requests'de Request'lerin Inactive - Nomanager" Gösterilmesi

Concurrent Request Manager'da Developer'lardan gelen bir çağrı üzerine kontrol ettiğim bir request'in "Inactive - Nomanager" olarak gözüktüğünü fark ettim. İlk aklıma gelen düşünce concurrent request'in atandığı bellirli bir concurrent manager olabilirdi. O yüzden o concurrent manager'ı bulup, sonra o concurrent manager'ın ayakta olup olmadığını kontrol ettim. 

Bunun için "adapcctl.sh status" komutunu girdim ve ICM (Internal Concurrent Manager'ın) açık olup olmadığına baktım.

Açık olduğunu gördükten sonra Concurrent Manager'ı kapattım ve cmclean.sql dosyasını çalıştırdım ve tekrar açtım. 

Cmclean.sql dosyasını aşağıdaki path'de bulabilirsiniz.

"/orappl/(SID)/apps/apps_st/appl/ad/12.0.0/admin/template/install/template/db/adcmclean.sql"

Yukarıda takip ettiğim adımların sonucunda sorunun çözüldüğünü gördüm.