데이터베이스 링크가 자꾸 끊어집니다.db link 10g - 8i

Question

IBM 장비에
OS : AIX 5L
Oracle: oracle 10.2.0.1.0 standard
WAS: WEBLOGIC8.1
이 장비에 아이피가 두개입니다.
192.168.1.100 ---> en0
172.10.10.10 ---> en1(요건VPN)아이피입니다.
입니다.
이서버에서 기존에 있던 오라클 8.1.7.0.0로 디비링크를 걸었습니다.
기존장비는
OS : solaris8
Oracle : oracle 8.1.7.0.0
아이피는 192.168.1.200
입니다.
오라클10에서 오라클8 쪽으로 디비링크를 건것이죠
근데 문제는 이 링크가 2,3 일에 한번씩 끊어집니다.
링크가 끊어지면 오라클10을 내렸다올리면 다시 링크가 됩니다.
이짓을 2,3일에 한번씩 링크가 끊어질때마다 하고 있습니다.
이거 어떻게 해야될지 모르겟습니다.
디비링크를 잘못 걸었다면 아주 안되거나 할텐데
잘 되다가 2,3일에 한번씩 끊어지니....
alert 로그를 봐도 특별히 에러로그는 찍히지 않습니다.
오라클 10에 프로시져를 많이 만들어서 쓰는데 한...200 개정도
링크가 끊어질때마다 프로시져에서 디비링크를 걸어 사용하는
오라클8쪽 테이블의 컬럼을 찾을수 없다고 나오네요. 그러면서 프로시져가
에러가 나는거죠. 특히아 특정 몇몇 컬럼만 그러면 오라클8쪽
컬럼이 이상하겠다 싶은데 그것도아닙니다 링크가 깨질때마다
컬럼이 계속 바뀌더군요....
이거 어디서 부터 손봐야될지...도와주세요..ㅠㅠ

Answer 1

우선 이 문제는 metalink SR을 진행해야 정확하게 해결할 수 있을 것
같습니다.
그리고 link가 2~3일에 끊어진다면...
두 장비간에 혹시 switch 등의 네트워크 장비가 있는지요?
db link가 끊어지는 것이 스위치에서 timeout설정이 되어 있으면
끊어지기도 하거든요.
metalink Note:207303.1 Client / Server / Interoperability Support Between Different Oracle Versions
을 보면 8.1.7과 10g와는 호환이 되긴하나 추가적인 문제가 발생했더라도
패치를 만들어 준다던지 하는 건 좀 힘들어 보이네요. 기존에 알려진 문제이고
패치가 나와있다면 가능하겠지만요..
우선 SR을 진행해보세요. H/W환경도 체크해보시구요..
Was Was a supported combination but one of the releases is no longer covered by any of Premier Support , Primary Error Correct support , Extended Support nor Extended Maintenance Support so fixes are no longer possible.
# 분산 트랜잭션의 문제해결 절차
1. 분산 트랜잭션의 문제해결 절차
=>. Alert!.log 의 에러발생 상태를 점검한다.
=>. Valid한 dblink 정보를 조회한다.
SQL> select * from v$dblink;
SQL> select * from gv$dblink;
=>. DBA_2PC_PENDING 뷰를 조회한다.
에러가 발생한 분산 트랜잭션의 ID를 조회한다.
col GLOBAL_TRAN_ID format a31
col LOCAL_TRAN_ID format a20
col state format a10
col host format a10
col commit# format a10
SELECT LOCAL_TRAN_ID, GLOBAL_TRAN_ID, STATE, MIXED, HOST, COMMIT# , FAIL_TIME, FORCE_TIME, RETRY_TIME
FROM DBA_2PC_PENDING
order by fail_time;
LOCAL_TRAN_ID는 Alert!.log에 분산 트랜잭션 에러와 함께 나타난다.
=>. DBA_2PC_NEIGHBORS 뷰를 조회한다.
이 뷰는 에러가 발생한 트랜잭션에 연관된 다른 노드의 정보를 조회한다.
SELECT LOCAL_TRAN_ID, IN_OUT, DATABASE, INTERFACE
FROM DBA_2PC_NEIGHBORS;
=>. 분산 노드의 각각에 대해 COMMIT_POINT_STRENGTH 값을 조회한다.
값을 비교하여 가장 큰 값을 가지는 노드가 먼저 Commit되어야 함을 의미한다.
=>. DBA_2PC_PENDING에서 STATE 컬럼값을 조회한다.
이 값이 COMMIT이면 Local Database는 성공적으로 Commit되었슴을 나타내며
PREPARED이면 트랜잭션이 완전하지 않음을 의미한다.
2. COMMIT FORCE 명령어
[예제]
SCN : 88123887 Local Transaction ID : 1.13.5197 (from dba_2pc_pending,alert!.log)
SQL> COMMIT FORCE 'your local transactionID on this node',
'highest SCN from already committed site';
SQL> COMMIT FORCE '1.13.5197', '88123887';
3 ROLLBACK FORCE command
[예제]
Local Transaction ID : 1.13.5197 (from dba_2pc_pending or alert!.log)
SQL> ROLLBACK FORCE 'your local transactionID on this node';
SQL> ROLLBACK FORCE '1.13.5197';
4. PURGING VIEWS
[예제]
Lost local transactionID : 1.13.5197 (from dba_2pc_pending or alert!.log)
$ sqlplus internal
SQL> execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY ('1.13.5197');
SQL> execute DBMS_TRANSACTION.PURGE_MIXED ('1.13.5197');
PURGE_MIXED Procedure 는 Remote Site loss를 포함한다.
5. SCN RECOVERY
SQL> RECOVER DATABASE UNTIL CHANGE '1.13.5197';
6. RECO Sleep & Wake Up
[Sleep]
SQL> ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY;
[Wake Up]
SQL> ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY;
# 처리방법
col GLOBAL_TRAN_ID format a30
col LOCAL_TRAN_ID format a20
col host format a10
SELECT LOCAL_TRAN_ID, GLOBAL_TRAN_ID, STATE, MIXED, HOST, COMMIT#
FROM DBA_2PC_PENDING
LOCAL_TRAN_ID GLOBAL_TRAN_ID STATE MIX HOST COMMIT#
15.7.29596 PM.725b6797.15.7.29596 collecting no UCWAS2 8272921656207
61.1.22743 PM.725b6797.61.1.22743 collecting no UCWAS1 8272923935983
22.4.24642 PM.725b6797.22.4.24642 collecting no UCWAS1 8272940697898
5.21.59794 PM.725b6797.5.21.59794 collecting no UCWAS2 8272940700642
6.0.696702 PM.725b6797.6.0.696702 collecting no UCWAS1 8272940703126
61.37.24361 PM.725b6797.61.37.24361 collecting no UCWAS1 8272940705147
17.42.52574 PM.725b6797.17.42.52574 collecting no UCWAS2 8272940705158
7.44.52413 ORAMCG.69bdbef8.13.45.1085272 committed no mcg1 8272940711288
12.31.42365 PM.725b6797.12.31.42365 collecting no UCWAS2 8272940843415
14.33.43474 PM.725b6797.14.33.43474 collecting no UCWAS1 8272941002871
4.22.89003 PM.725b6797.4.22.89003 collecting no UCWAS2 8273024275247
11 rows selected.
SQL> commit;
Commit complete.
SQL> alter session set "_smu_debug_mode" = 4;
Session altered.
SQL> execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('15.7.29596');
PL/SQL procedure successfully completed.
SQL> commit;