Arşiv

Archive for the ‘ORA-Errors’ Category

12c Veritabanında “ORA-29548: Java system class reported” Hatası Nasıl Çözülür?

Merhaba,

12.1.0.2.0 veritabanımıza PSU uyguladıktan sonra, uygulamamız aşağıdaki hatayı almaya başladı.

[Error] Execution (1: 1): ORA-29548: Java system class reported: release of classes.bin in the database does not match that of the oracle executable
ORA-06512: at “MDSYS.SDO_JAVA_STP”, line 370
ORA-06512: at “MDSYS.SDO_UTIL”, line 3188
ORA-06512: at “MDSYS.SDO_UTIL”, line 3211

Alert log dosyasını kontrol ettiğimde aşağıdaki hata ile karşılaştım.

joxcsys: release mismatch 12.1.0.2.160719 1.6 in database (classes.bin) vs 12.1.0.2.0 1.7 in executable

Veritabanımda INVALID obje olup olmadığını kontrol ettim. Ama herşey yolundaydı. Java ile ilgili küçük bir test yaptım.

SQL> select dbms_java.get_jdk_version() from dual
*
ERROR at line 1:
ORA-29548: Java system class reported: release of classes.bin in the database
does not match that of the oracle executable

Java ile ilgili bir uyumsuzluk vardı. Bu problemi aşmak için aşağıdaki scriptleri SYSDBA ile bağlanıp çalıştıralım.

SQL> @?/javavm/install/update_javavm_db.sql
SQL> SET FEEDBACK 1
SQL> SET NUMWIDTH 10
SQL> SET LINESIZE 80
SQL> SET TRIMSPOOL ON
SQL> SET TAB OFF
SQL> SET PAGESIZE 100
SQL>
SQL> alter session set “_ORACLE_SCRIPT”=true;

Session altered.

SQL>
SQL> — If Java is installed, do CJS.
SQL>
SQL> — If CJS can deal with the SROs inconsistent with the new JDK,
SQL> — the drop_sros() call here can be removed.
SQL> call initjvmaux.drop_sros();

Call completed.

SQL>
SQL> create or replace java system;
2 /

Java created.

SQL>
SQL> update dependency$
2 set p_timestamp=(select stime from obj$ where obj#=p_obj#)
3 where (select stime from obj$ where obj#=p_obj#)!=p_timestamp and
4 (select type# from obj$ where obj#=p_obj#)=29 and
5 (select owner# from obj$ where obj#=p_obj#)=0;

0 rows updated.

SQL>
SQL> commit;

Commit complete.

SQL>
SQL> alter session set “_ORACLE_SCRIPT”=false;

Session altered.

SQL>

Şimdi testimizi tekrar yapalım.

SQL> select dbms_java.get_jdk_version() from dual;

DBMS_JAVA.GET_JDK_VERSION()
——————————————————————————–
1.7.0_51

1 row selected.

SQL> select dbms_java.longname(‘TEST’) from dual
2 ;

DBMS_JAVA.LONGNAME(‘TEST’)
——————————————————————————–
TEST

1 row selected.

SQL>

 

Herşey yolunda. Uygulamamızın da sorunu çözülmüş oldu. Kolay gelsin.

Reklamlar

ORA-28043: invalid bind credentials for DB-OID connection

Merhaba Arkadaşlar,

Bu yazımda ORA-28043 hatasının çözümünde uygulanması gereken adımlardan bahsedeceğim.

Şirketimizde veritabanlarımız Oracle Internet Directory ile entegre çalışmaktadır. Örnek olarak dc=tholdap,dc=local domaini altında OID ile çalıştığını varsayalım. Bazı veritabanı OID kullanıcılarım veritabanına erişirken ORA-28043 hatası ile karşılaştıklarını ve login olamadıklarını ilettiler.
Bu durumda hatanın çözümü için yapmamız gereken ilk iş, aşağıdaki gibi bir trace başlatmaktır.

sqlplus / as sysdba

SQL> alter system set events ‘28033 trace name context forever, level 9’;

Yukarıdaki gibi SYS user ile trace başlattıktan sonra kullanıcımızdan veritabanına tekrar login olmasını ve hata almasını isteyelim. Kullanıcımız hata aldıktan sonra $ORACLE_BASE/diag/rdbms/$SID/$SID/trace dizini altında oluşan trace dosyamızı vi ile açalım.

vi /u01/app/oracle/diag/rdbms/testdb/TESTDB/trace/TESTDB_ora_9951.trc

ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1
System name: SunOS
Node name: dbtest
Release: 5.10
Version: Generic_150400-09
Machine: sun4v
Instance name: TESTDB
Redo thread mounted by this instance: 1
Oracle process number: 2610
Unix process pid: 9951, image: oracle@dbtest

*** ACTION NAME:() 2016-02-24 09:04:40.463
*** MODULE NAME:(Toad.exe) 2016-02-24 09:04:40.463
*** SERVICE NAME:(TESTDB) 2016-02-24 09:04:40.463
*** SESSION ID:(1212.44043) 2016-02-24 09:04:40.463
kzld_discover received ldaptype: OID
kzld found pwd in wallet
KZLD_ERR: Failed to bind to LDAP server. Err=49
KZLD_ERR: 49
KZLD is doing LDAP unbind
KZLD_ERR: found err from kzldini.
~
~

Trace dosyamızdan gördüğümüz üzere hata LDAP server binding işleminde ki bir problemden kaynaklanıyor.

kzld_discover received ldaptype: OID
kzld found pwd in wallet
KZLD_ERR: Failed to bind to LDAP server. Err=49
KZLD_ERR: 49
KZLD is doing LDAP unbind
KZLD_ERR: found err from kzldini.

O halde veritabanı wallet da bulunan kullanıcı adı ve şifremizle ldap sunucusuna bağlanmaya çalışalım.

Peki bu iş nasıl olacak? Wallet da bulunan kullanıcı adı ve şifremizi nasıl öğrenebiliriz? Aşağıdaki gibi mkstore ile bu bilgileri elde edebiliriz.

$ mkstore -wrl $ORACLE_BASE/admin/TESTDB/wallet -viewEntry ORACLE.SECURITY.DN
Oracle Secret Store Tool : Version 11.2.0.3.0 – Production
Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.

Enter wallet password: abcd678xx_

ORACLE.SECURITY.DN = cn=TESTDB,cn=OracleContext,dc=tholdap,dc=local
$ mkstore -wrl $ORACLE_BASE/admin/TESTDB/wallet -viewEntry ORACLE.SECURITY.PASSWORD
Oracle Secret Store Tool : Version 11.2.0.3.0 – Production
Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.

Enter wallet password: abcd678xx_

ORACLE.SECURITY.PASSWORD = +HKRbmQ7

mkstore, veritabanımızı OID ”ye register ederken belirlediğimiz wallet şifresini soracaktır. Şifremizi yukarıdaki gibi girdiğimizde kullanıcı adı ve şifremizi elde edebileceğiz.

Son durumda kullanıcı adı ve şifremiz aşağıdaki gibidir.

ORACLE.SECURITY.PASSWORD = +HKRbmQ7
ORACLE.SECURITY.DN = cn=TESTDB,cn=OracleContext,dc=tholdap,dc=local

Şimdi yukarıdaki bilgilerle LDAP sunucumuza bağlantı yapmaya çalışalım.

$ORACLE_HOME/network/admin dizininde bulunan ldap.ora dosyasından port numarasını öğrenelim.

$ cat /u01/app/oracle/product/11.2.0/db_1/network/admin/ldap.ora
# ldap.ora Network Configuration File: /u01/app/oracle/product/11.2.0/db_1/network/admin/ldap.ora
# Generated by Oracle configuration tools.

DIRECTORY_SERVERS= (idmoid.vodafone.local:1389:1636)

DEFAULT_ADMIN_CONTEXT = “dc=tholdap,dc=local”

DIRECTORY_SERVER_TYPE = OID

ldapbind komutu ile aşağıdaki gibi LDAP sunucusu bağlantı testi yapalım.

$ ldapbind -h idmoid.vodafone.local -p 1389 -D cn=TESTDB,cn=OracleContext,dc=tholdap,dc=local -w kSlIt+n2
ldap_bind: Invalid credentials

Gördüğümüz gibi problemin sebebi geçersiz login bilgilerinden kaynaklanıyor. Wallet da bulunan bilgilerle OID tarafı örtüşmüyor. Peki bu problemi nasıl çözebiliriz? Çözüm için iki yol var:
1- OID tarafında cn=TESTDB,cn=OracleContext,dc=tholdap,dc=local CN şifresi, ORACLE.SECURITY.PASSWORD ile elde ettiğimiz şifre ile güncellenir.

2- DBCA ile veritabanımızı aşağıdaki gibi yeniden register edebiliriz.

dbca -silent -configureDatabase -sourceDB TESTDB -unregisterWithDirService true -dirServiceUserName cn=dirManager -dirServicePassword OracleTHO11 walletPassword abcd678xx_

dbca -silent -configureDatabase -sourceDB TESTDB -registerWithDirService true -dirServiceUserName cn=dirManager -dirServicePassword OracleTHO11 walletPassword abcd678xx_

Yeniden register işlemi yaptıktan sonra ldapbind ile LDAP sunucumuza bağlantı testi yaptığımızda aşağıdaki gibi başarılı olduğunu görürüz.

$ ldapbind -h idmoid.vodafone.local -p 1389 -D cn=TESTDB,cn=OracleContext,dc=tholdap,dc=local -w +HKRbmQ7
bind successful

Artık kullanıcılarımız başarılı bir şekilde OID ile login olabileceklerdir.

Önemli bir noktayıda burada not etmek istiyorum. CN (Directory Service username) adında boşluklar varsa DBCA hata veriyor. Boşlukların yerine aşağıdaki gibi \20 yazarak bu problemi de çözebiliriz.

örneğin; Directory Service kullanıcı adımız “directory manager” olsun. Bu durumda DBCA da aşağıdaki gibi yazmamız gerekir.

dbca -silent -configureDatabase -sourceDB TESTDB -unregisterWithDirService true -dirServiceUserName cn=directory\20manager -dirServicePassword OracleTHO11 walletPassword abcd678xx_

Aksi durumda aşağıdaki hatayı alırız.

dbca -silent -configureDatabase -sourceDB TESTDB -unregisterWithDirService true -dirServiceUserName cn=directory manager -dirServicePassword OracleTHO11 walletPassword abcd678xx_
manager is an invalid command line argument.

Yukarıdaki gibi ldapbind ile bağlantı testimiz başarılı olmasına rağmen hala aynı hatayı alıyorsak, bu  Oracle IDM şifremizle alakalı bir durumdur. Bu durumda IDM şifremizi resetlememiz çözüm sağlayacaktır.

clscfg.bin: error while loading shared libraries: libcap.so.1: cannot open shared object file

Merhaba Arkadaşlar,

Red Hat Enterprise Linux 6.3 üzerinde 11.2.0.3 Grid Infrastructure yazılımını kurduktan sonra root.sh scriptini çalıştırırken aşağıdaki hatayı aldım.

/oracle/grid11g/bin/clscfg.bin: error while loading shared libraries: libcap.so.1: cannot open shared object file: No such file or directory Failed to create keys in the OLR, rc = 127, Message:

Bu hata özellikle Linux 6.X üzerinde Oracle yazılımı yüklenirken alınmaktadır.

Root.sh scriptini çalıştırdığımda çıktı aşağıdaki gibiydi.

[root@dbtestvm1 ~]# /oracle/grid11g/root.sh
Performing root user operation for Oracle 11g

The following environment variables are set as:
ORACLE_OWNER= ora11g
ORACLE_HOME= /oracle/grid11g

Enter the full pathname of the local bin directory: [/usr/local/bin]:
The contents of “dbhome” have not changed. No need to overwrite.
The contents of “oraenv” have not changed. No need to overwrite.
The contents of “coraenv” have not changed. No need to overwrite.

Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: /oracle/grid11g/crs/install/crsconfig_params
/oracle/grid11g/bin/clscfg.bin: error while loading shared libraries: libcap.so.1: cannot open shared object file: No such file or directory Failed to create keys in the OLR, rc = 127, Message:

Failed to write the checkpoint:” with status:FAIL.Error code is 256

Failed to create keys in the OLR at /oracle/grid11g/crs/install/crsconfig_lib.pm line 7497. /oracle/grid11g/perl/bin/perl -I/oracle/grid11g/perl/lib -I/oracle/grid11g/crs/install /oracle/grid11g/crs/install/roothas.pl execution failed

libcap rpm dosyasının yüklü olup olmadığını kontrol ettim.

[root@dbtestvm1 ~]# rpm -q libcap
libcap-2.16-5.5.el6.x86_64

libcap-2.16-5.5.el6.x86_64 rpm dosyasının yüklü olduğunu gördüm. Hatada libcap.so.1 dosyasını arıyordu. https://taliphakanozturk.wordpress.com/2012/03/17/yum-ile-bagimliligi-fazla-rpm-paketin-yuklenmesi/  makaleme göre YUM ayarlarını yaptım.

İsminde libcap geçen dosyaları listeledim.

[root@dbtestvm1 ~]# yum list | grep libcap 
libcap.i686 2.16-5.5.el6 @cd
libcap.x86_64 2.16-5.5.el6 @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
libcap-devel.x86_64 2.16-5.5.el6 @cd
libcap-ng.x86_64 0.6.4-3.el6_0.1 @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
libcap-ng-devel.x86_64 0.6.4-3.el6_0.1 @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
compat-libcap1.i686 1.10-1 cd
compat-libcap1.x86_64 1.10-1 cd
libcap-devel.i686 2.16-5.5.el6 cd
libcap-ng.i686 0.6.4-3.el6_0.1 cd
libcap-ng-devel.i686 0.6.4-3.el6_0.1 cd

compat-libcap1.x86_64 rpm dosyasını yükledim. (makinam 64 bit)

[root@dbtestvm1 ~]# yum install compat-libcap1.x86_64
Loaded plugins: product-id, refresh-packagekit, security, subscription-manager
Updating certificate-based repositories.
Unable to read consumer identity
Setting up Install Process
Resolving Dependencies
–> Running transaction check
—> Package compat-libcap1.x86_64 0:1.10-1 will be installed
–> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
compat-libcap1 x86_64 1.10-1 cd 17 k

Transaction Summary
================================================================================
Install 1 Package(s)

Total download size: 17 k
Installed size: 29 k
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : compat-libcap1-1.10-1.x86_64 1/1
Installed products updated.
Verifying : compat-libcap1-1.10-1.x86_64 1/1

Installed:
compat-libcap1.x86_64 0:1.10-1

Complete!

Artık devam edebiliriz. Root.sh scriptini çalıştırdığımız için önce root kullanıcısı ile aşağıdaki gibi deconfig yapalım.

[root@dbtestvm1 ~]# /oracle/grid11g/crs/install/roothas.pl -deconfig -force
Using configuration parameter file: /oracle/grid11g/crs/install/crsconfig_params
CRS-4639: Could not contact Oracle High Availability Services
CRS-4000: Command Stop failed, or completed with errors.
CRS-4639: Could not contact Oracle High Availability Services
CRS-4000: Command Delete failed, or completed with errors.
CRS-4544: Unable to connect to OHAS
CRS-4000: Command Stop failed, or completed with errors.
Failure in execution (rc=-1, 0, No such file or directory) for command /etc/init.d/ohasd deinstall
Successfully deconfigured Oracle Restart stack

Şimdi root.sh scriptimizi tekrar çalıştıralım. Başarılı bir şekilde çalışacaktır.

[root@dbtestvm1 ~]# /oracle/grid11g/root.sh
Performing root user operation for Oracle 11g

The following environment variables are set as:
ORACLE_OWNER= ora11g
ORACLE_HOME= /oracle/grid11g

Enter the full pathname of the local bin directory: [/usr/local/bin]:
The contents of “dbhome” have not changed. No need to overwrite.
The contents of “oraenv” have not changed. No need to overwrite.
The contents of “coraenv” have not changed. No need to overwrite.

Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: /oracle/grid11g/crs/install/crsconfig_params
LOCAL ADD MODE
Creating OCR keys for user ‘ora11g’, privgrp ‘dba’..
Operation successful.
LOCAL ONLY MODE
Successfully accumulated necessary OCR keys.
Creating OCR keys for user ‘root’, privgrp ‘root’..
Operation successful.
CRS-4664: Node dbtestvm1 successfully pinned.
Adding Clusterware entries to upstart

dbtestvm1 2013/02/28 16:55:21 /oracle/grid11g/cdata/dbtestvm1/backup_20130228_165521.olr
Successfully configured Oracle Grid Infrastructure for a Standalone Server
[root@dbtestvm1 ~]#

Talip Hakan Öztürk

ORA-06508 | ORA-04065 | ORA-04068 Hatalarını Nasıl Çözeriz?

19/04/2012 3 yorum

Merhaba Arkadaşlar,

Bu yazımda, ORA-06508, ORA-04065, ORA-04068 hataları ile karşılaştığımızda ne yapmamız gerektiğini yazacağım. Bir paket veya prosedür içinden çağırılan bağımlı bir nesne, DDL cümlesi ile değiştirildiğinde, çağıran paket veya prosedür ORA-04068 hatası ile karşılaşır. Bunun sebebi paketler derlendiklerinde shared_pool alanındaki kopyaları invalid olarak işaretlenir. Bu esnada çağıran paket çağrılan paketin yeni bir kopyasının olduğunu anlar. Ve ORA-04068 hatası alınır. Çağıran paket veya procedure bu hatayı ilk çağırdığı esnada alır. İkinci kez çağırdığında işlem başarılı olarak gerçekleştirilir. Ama bazı durumlarda bu hatalardan kurtulmak için kodumuzda küçük bir değişiklik yapmamız gerekebilir.

Şimdi bu konu ile ilgili bir test yapalım. Aşağıdaki gibi talip_test adında bir paket oluşturuyorum. Paketin SPEC kısmında global bir değişken tanımlayalım.

CREATE OR REPLACE PACKAGE talip_test
IS
global_var NUMBER := 10;

PROCEDURE inner_test_proc;
END;
/

CREATE OR REPLACE PACKAGE BODY talip_test
IS
PROCEDURE inner_test_proc
IS
BEGIN
global_var := global_var + 1;
DBMS_OUTPUT.put_line (‘Değişken =’ || global_var);
END;
END;
/

Şimdide bu paketi çağıracak olan bir procedure oluşturalım.

CREATE OR REPLACE PROCEDURE outer_test_proc
AS
err VARCHAR2 (1024);
BEGIN
talip_test.inner_test_proc;
END;
/

SQL*Plus üzerinde prosedürü çalıştırdığımızda başarılı çalıştığını görürüz.

SQL> set serveroutput on

SQL> begin outer_test_proc; end; /

Değişken =12

PL/SQL procedure successfully completed.

Şimdi talip_test paketinin SPEC kısmında biraz değişiklik yapalım. İkinci bir global değişken ekleyelim. Ve SPEC+BODY yeniden derleyelim.

CREATE OR REPLACE PACKAGE talip_test
IS
global_var NUMBER := 10;
global_var2 NUMBER := 10;

PROCEDURE inner_test_proc;
END;
/

CREATE OR REPLACE PACKAGE BODY talip_test
IS
PROCEDURE inner_test_proc
IS
BEGIN
global_var := global_var + 1;
DBMS_OUTPUT.put_line (‘Değişken =’ || global_var);
END;
END;
/

outer_test_proc prosedürü invalid olacaktır. Prosedürümüzü aşağıdaki gibi derleyelim.

SQL> select status from dba_objects where object_name=’OUTER_TEST_PROC’;

STATUS

——-

INVALID

SQL> alter procedure outer_test_proc compile ;

SQL> select status from dba_objects where object_name=’OUTER_TEST_PROC’;

STATUS

——-

VALID

Bu durumda veritabanına bağlı olan oturumlar (session) prosedürü çağırdıklarında aşağıdaki gibi ORA-04068 hatası alırlar. Paketi çağıran oturum bu hatayı sadece bir kere alır.

SQL>begin outer_test_proc; end; /

begin outer_test_proc; end;

* ERROR at line 1: ORA-04068: existing state of packages has been discarded

ORA-04061: existing state of package body “TALIP.TALIP_TEST” has been invalidated

ORA-04065: not executed, altered or dropped package body “TALIP.TALIP_TEST”

ORA-06508: PL/SQL: could not find program unit being called: “TALIP.TALIP_TEST”

ORA-06512: at “TALIP.OUTER_TEST_PROC”, line 5 ORA-06512: at line 1

Aynı oturum ikinci kez çalıştırdığında paket başarılı çalıştırılır.

SQL> set serveroutput on

SQL> /

Değişken =12

PL/SQL procedure successfully completed.

Çağıran paket veya procedure de “when others then” ile exception handling yapılıyorsa, veritabanına bağlı oturumlar paketi her çağırdıklarında hata alırlar. Şimdi outer_test_proc prosedürümüzü aşağıdaki gibi değiştirelim.

CREATE OR REPLACE PROCEDURE outer_test_proc
AS
err VARCHAR2 (1024);
BEGIN
talip_test.inner_test_proc;
EXCEPTION
WHEN OTHERS
THEN
err := SUBSTR (SQLERRM, 0, 1000);
DBMS_OUTPUT.put_line (err);
ROLLBACK;
END;
/

Şimdi talip_test paketinin SPEC kısmında biraz değişiklik yapalım. Üçüncü bir global değişken ekleyelim. Ve SPEC+BODY yeniden derleyelim.

CREATE OR REPLACE PACKAGE talip_test
IS
global_var NUMBER := 10;
global_var2 NUMBER := 10;
global_var3 NUMBER := 10;

PROCEDURE inner_test_proc;
END;
/

CREATE OR REPLACE PACKAGE BODY talip_test
IS
PROCEDURE inner_test_proc
IS
BEGIN
global_var := global_var + 1;
DBMS_OUTPUT.put_line (‘Değişken =’ || global_var);
END;
END;
/

outer_test_proc prosedürü invalid olacaktır. Prosedürümüzü aşağıdaki gibi derleyelim.

SQL> select status from dba_objects where object_name=’OUTER_TEST_PROC’;

STATUS

——-

INVALID

SQL> alter procedure outer_test_proc compile ;

SQL> select status from dba_objects where object_name=’OUTER_TEST_PROC’;

STATUS

——-

VALID

Bu durumda outer_test_proc prosedürü valid olmasına rağmen, veritabanına bağlı oturumlar outer_test_proc prosedürünü her çağırdıklarında ORA-06508 hatası alırlar.

SQL> begin outer_test_proc; end; /

ORA-06508: PL/SQL: could not find program unit being called

PL/SQL procedure successfully completed.

SQL> /

ORA-06508: PL/SQL: could not find program unit being called

PL/SQL procedure successfully completed.

“when others then” bloğu içerisinde exception tekrar aşağıdaki gibi raise edilirse, bağlı oturumlar prosedürü ilk çağırdıklarında hata alırlar ve ikinci kez çağırdıklarında işlem başarılı gerçekleşir.

CREATE OR REPLACE PROCEDURE outer_test_proc
AS
err VARCHAR2 (1024);
BEGIN
talip_test.inner_test_proc;
EXCEPTION
WHEN OTHERS
THEN
err := SUBSTR (SQLERRM, 0, 1000);
DBMS_OUTPUT.put_line (err);
ROLLBACK;
RAISE;
END;
/

Şimdi terkrar çalıştıralım. İlk çalıştırdığımızda hata alacağız. Tekrar çalıştırdığımızda işlem başarılı gerçekleşecektir.

SQL> begin outer_test_proc; end; /

begin outer_test_proc; end;

* ERROR at line 1: ORA-04068: existing state of packages has been discarded

ORA-04061: existing state of package “TALIP.TALIP_TEST” has been invalidated

ORA-04065: not executed, altered or dropped package “TALIP.TALIP_TEST”

ORA-06508: PL/SQL: could not find program unit being called: “TALIP.TALIP_TEST”

ORA-06512: at “TALIP.OUTER_TEST_PROC”, line 11 ORA-06512: at line 1

SQL> /

PL/SQL procedure successfully completed.

Faydalı olması dileğiyle…

Talip Hakan Öztürk

%d blogcu bunu beğendi: