我們有2個數據庫之間用DBLink訪問,遠端DB是9206,本地是9201,以前本地訪問遠端都是好好的.現在出現了一個問題,直接用select語句訪問沒有什麼問題,但是把這個Select語句放在Procedure裡面,就必須在訪問的對象前面加owner,否則就會報ORA-03113的錯誤,並產生TRC文件.

舉個例子:
下面這兩句都可以正常執行:

SELECT * FROM aa1@mptr11iprod

DECLARE
v_test VARCHAR2(100);
BEGIN
SELECT TO_CHAR(COUNT(1)) INTO V_TEST FROM mhr.aa1@mptr11iprod WHERE ROWNUM=1;
END;

但是下面這個語句就回報ORA-03113的錯:
DECLARE
v_test VARCHAR2(100);
BEGIN
SELECT TO_CHAR(COUNT(1)) INTO V_TEST FROM aa1@mptr11iprod WHERE ROWNUM=1;
END;

不知道大家有沒有遇到這個問題,該如何解決.

補充一下:
就那上面的例子,aa1是遠端DB mhr用戶下面的一個表,本地dblink直接連過去的用戶是遠端的用戶scott,scott有select any table的權限, aa1在scott下面建了一個別名也叫aa1.

它有測試環境,測試環境卻很正常.

部分TRC文件內容如下:

/export/home/webora/admin/WEBPROD/udump/webprod_ora_19266.trc
Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
ORACLE_HOME = /export/home/webora/product/9.0.1
System name:       SunOS
Node name:       MPSSDB04
Release:       5.9
Version:       Generic_112233-07
Machine:       sun4u
Instance name: WEBPROD
Redo thread mounted by this instance: 1
Oracle process number: 318
Unix process pid: 19266, image: oracle@MPSSDB04 (TNS V1-V3)

*** SESSION ID297.13547) 2008-06-05 14:09:58.129
Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x50, PC: [0x100975b14, 0000000100975B14]
*** 2008-06-05 14:09:58.146
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [0000000100975B14] [SIGSEGV] [Address not mapped to object] [0x000000050] [] []
Current SQL statement for this session:
DECLARE
v_test VARCHAR2(100);
BEGIN
SELECT TO_CHAR(COUNT(1)) INTO V_TEST FROM aa1@mptr11iprod WHERE ROWNUM=1;
END;
----- Call Stack Trace -----
calling             call    entry             argument values in hex
location          type    point             (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+328       CALL    ksedst()+0          FFFFFFFF7FFF3C60 ?
                                                000000000 ? 000000000 ?
                                                00000003E ?
                                                FFFFFFFF7FFF44F8 ?
                                                103060868 ?
ssexhd()+604       CALL    ksedmp()+0          000000000 ? 000103400 ?
                                                000103460 ? 000102C00 ?
                                                103460000 ? 103460D70 ?
sigacthandler()+44 PTR_CALL 0000000000000000    103468000 ?
                                                FFFFFFFF7FFF5490 ?
                                                000000000 ? 000000001 ?
                                                103465F08 ? 00000000B ?
kkdlgob()+4884    PTR_CALL 0000000000000000    00000000B ?
                                                FFFFFFFF7FFF5490 ?
                                                FFFFFFFF7FFF51B0 ?
                                                386264778 ? 38FD93B18 ?
                                                000000001 ?
qcsfgob()+208       CALL    kkdlgob()+0       38C912DE0 ? 000000002 ?
                                                000000000 ? 000000000 ?
                                                000000001 ? 386264778 ?
qcsprfro()+432    CALL    qcsfgob()+0       FFFFFFFF7FFF6108 ?
                                                38C912DE0 ? 000000001 ?

分析過程:

1.望:先看看日誌,TRC文件看看問題是否碰到過,然後用最快速的辦法看能否解決(其實就是baidu+google啦),答案是未果,網上說差不多07445與BUG有關.

2.聞:登錄到這個機器上,df -k,show sga,show一些常見的參數,看看等待事件,改寫一下SQL看看是否是parse的BUG,只是發現了某一個目錄的空間達到100%,sqlplus執行就發生了ora-09817的錯誤,解決了這個錯誤,問題還是沒解決.

3.問:問問當事人問題發生的時間,再那段時間內是否做過什麼動作,回答沒有.問問其他同事最近有沒有在該DB上做過什麼事情,也沒.

4.切:這下子要動真格了.一般我的習慣是,自己摸索+問別人雙管齊下,問別人就是在itpub上發帖或者metalink上查.自己摸索呢,那就要18般武藝都要用上了.

A.根據別人的反應,以前都是正常的,是最近才出的問題,那對比一下V$parameter看看,發現有部份參數兩邊不一樣,但是這些參數不會影響大局.

B.查看一下SGA的參數,發現遠端DB的SGA中shared_pool有1.8G,PGA有8G,這兩個參數會不會影響到呢,暫放一邊

C.用SQL Trace跟蹤這個執行過程所用到SQL

ITPub博客

ORA-03113,ORA-07445

最新文章