‘ORA’ 카테고리의 보관물

DDB (Distributed DataBase)시 발생하는 ORA- 문제들

게시 날짜: 2011/09/15, 카테고리: ORA, ORACLE
태그:,

CASE 1. Two-Phase Commit 인터럽트

현상 :
ORA-02050: TRX ID rolled back, some remote dbs may be in-doubt
ORA-02051: TRX ID committed, some remote dbs may be in-doubt
ORA-02054: TRX ID in-doubt

프로그램 사용중에 위 에러중 하나가 발견되면 그 트랜젝션에 대한 정보가 자동으로 저장되어 이 정보는 후에 분산 트랜젝션에 대한 Manual Recovery 에 사용될 수 있다.

조치 :
DBA는 특별한 Action 을 취할 필요가 없다. RECO(Recovery) process 가 Session tree 의 모든 노드에서 같은 결과가 발생되도록 In-doubt 트랜젝션을 자동으로 Recovery 한다(All commit or All rollback). 그러나 장기적인 Power Failure 의 경우 Lock 된 리소르를 해제하기 위해 강제적으로 Commit 이나 Rollback 을 시켜준다.

SQL> COMMIT FORCE ‘SALES.ACME.COM.55dic563.193.29’; <OR>
SQL> COMMIT FORCE ‘global_id’,228444991
SQL> ROLLBACK FORCE ‘2.9.4’;

CASE 2. Lock 에 의해 데이터 접근을 금지시키는 Fail

현상:
ORA-02049: time-out : distributed transaction waiting for lock

로컬의 DML 문장이 원격의 다른 트랜젝션에 의해 Lock 이 되어있는 데이터를 수정 혹은 삭제를 시도하려 할 때 Time-out 이 발생하고 해당 명령은 Rollback 된다.

<in Remote>
SQL>update dept set deptno = 10;
<in Local>
SQL> update dept set deptno = 10;
SQL> update dept@REMOTE set deptno=10;
ORA-02049 : time-out

조치:
로컬에는 Update 가 발생하므로 항상 Rollback 을 시켜 주어야 하나,  원격은 변경할 수 없으므로 아무런 조치는 취하지 않아도 된다. 위 상황에서 Time-out 의 간격은 DISTRIBUTED_LOCK_TIMEOUT 파라미터로 시간을 조정할 수 있다.

현상:
ORA-01591 : Lock held by in-doubt distributed transaction ID

In-doubt 트랜젝션이 락을 잡고 있는 리소스에 대하여 접근을 시도시 발생하는 에러.

SQL> update dept@remote set dname=’AA’;
— Remote Database down
SQL> commit
ORA-02054 : transaction 2.1.207 is in-doubt transaction
SQL> select * from dept@remote;
ORA-01591 : Lock held by in-doubt distributed transaction id 2.1.207

로컬에서 DBA_2PC_PENDING 뷰를 통해 in-doubt 트랜젝션 정보를 확인할 수 있다.

조치:
이런 경우 SQL 문장은 Rollback 되어야 한다. Lock 이 계속해서 결려 있을 경우 Rollback 을 수행해 주어야 한다. Network 혹은 System Failure 가 빠르게 복구 될 경우 이 문제는 자동으로 해결 된다.

CASE 3. 두 Node 사이에 Connection 이 만들어 진 이후 Network Failure.

현상:
Forms 등을 통해 화면에서 데이터를 업데이트를 수행하면 네트워크와 원격 DB가 정상적일 경우 Commit 이 되나, 네트워크가 Fail 될 경우 화면이 Holding 상태로 멈춤.

조치:
네트워크가 복구되면 자동으로 Commit. 하지만 네트워크 Failure 가 장기화 될 경우 강제로 Abort 시켜주어야 한다. 강제 Abort 시 자동으로 Rollback 되므로 더이상의 조치는 필요치 않다.

opiodr aborting process unknown ospid (5112398) as a result of ORA-28

Oracle database 11g 버전에 들어와서 새로 생긴 정보성 메세지 이다. 특별히 데이터 베이스에서 장애가 생겼다기 보다는 권한있는 사용자가 다른 세션을 죽였을 때 발생하는 메세지 이다. (ORA-28)
위 메세지의 해석은 다음과 같다.

“unknown ” : 킬(Killed)된 백그라운드나 쉐도우 프로세스가  아닌 프로세스
“ospid (5112398) ” : OS PID
“as a result ” : opiodr 이 프로세스를 킬(Kill) 시킨 이유
“ORA-28 ” : opiodr 이 프로세스를 킬 시킨 정확한 이유. 이 경우에는 권한있는 사용자가 오라클 세션을 Kill 시켰기 때문이다.

* ORA – 28 Your session has been killed

좀더 정확한 정보는 메타링크 노트 를[1230858.1] 를 참고하면 되겠다.

ORA-27037

게시 날짜: 2011/09/03, 카테고리: ORA

ORA-27037 : Unable obtain file status
파일의 상태를 얻을 수 없을때 생기는 에러. 추가적으로 발생하는 ORA 메세지와 함께 확인해 보아야 한다.
일반적으로 파일이 지워졌거나 경로가 잘못 되었을 경우 일어날 수 있다.

EX)
SQL> alter database backup controlfile to ‘…’
ORA-00245 Control file backup operation failed
ORA-245 Signalled during : alter database backup con…
ORA-27037 Unable obtain file status

파일의 상태나 경로등을 다시 확인해 보고 재수행 한다.