TECH
QUESTION
자주하는 질문답변 입니다.
Oracle
| 작성자 | 유건데이타 | 등록일 | 2015-06-02 |
| 제목 | DDB 기본 기능 및 분산 트랜잭션 문제의 해결(ora-02050등) | ||
|---|---|---|---|
|
DDB 기본 기능 및 분산 트랜잭션 문제의 해결
=========================================== PURPOSE --------- 여기서는 DDB(분산 데이타베이스)의 기능과 역할 및 사용 시에 발생하는 문제점들에 대해서 알아보기로 한다. Explanation ------------- 분산 DB 환경과 관련된 init 같은 것들이 있다. - DB_NAME - DB_DOMAIN - GLOBAL_NAME - DISTRIBUTED_RECOVER_CONNECTION_HOLD_TIME - DISTRIBUTED_TRANSACTIONS - DISTRIBUTED_LOCK_TIMEOUT - COMMIT_POINT_STRENGTH - OPEN_LINKS 분산 DB와 관련된 VIEW와 TABLE은 다음과 같다. - GLOBAL_NAME - DBA_DB_LINKS, ALL_DB_LINKS, USER_DB_LINKS - DBA_2PC_PENDING - DBA_2PC_NEIGHBORS * RECO:Recoverer Process 분산 트랜잭션의 Failure를 해결하는 Process로 RECO는 In-doubt 분산 트랜잭션을 가지고 있는 다른 DB에 자동적으로 Connect 하여 모든 In-doubt 트랜잭션을 해결한다. 만일 RECO가 Remote Server에 Connection을 시도했는데 Remote Server가 사용 가능하지 않거나 Network가 복구 되어 있지 않을 경우 RECO는 일정한 시간 후에 다시 Connect를 시도한다. * DATABASE LINK 1. Database Link에는 Private Database Link와 Public Database Link의 두 종류가 있는데 일반적으로 Public Database Link로 정의하여 사용한다. 2. Public Database Link Local 데이타베이스의 모든 사용자가 Remote 데이타베이스의 데이타를 사용할 수 있다. 이 경우 Remote Database에 대해서 필요한 권한을 가지고 있어야 한다. 3. Public Database Link Creation EXAMPLES ) CREATE PUBLIC DATABASE LINK sales.acme.com USING 'dbstring'; 4. Dropping Databsae Link EX ) DROP PUBLIC DATABASE LINK sales.acme.com; 분산처리 문제와 해결 방법 1. Two-Phase Commit을 인터럽트하는 Failures [ 현상 ] ORA-02050: Transaction ID rolled back, some remote dbs may be in-doubt ORA-02051: Transaction ID committed, some remote dbs may be in-doubt ORA-02054: Transaction ID in-doubt 만일 프로그램 사용 중 위의 에러 가운데 하나가 발생한다면 그 트랜잭션에 대한 정보가 자동적으로 저장되며 이 정보는 후에 분산 트랜잭션에 대한 Manual Recovery 시에 사용될 수 있다. [ 조치 방법 ] DBA는 특별한 Action을 취할 필요가 없다. RECO Process가 Session Tree의 모든 노드에서 같은 결과가 발생되도록 (즉 모두 Commit 혹 모두 Rollback) In-doubt 트랜잭션을 자동적으로 Recovery 한다. 그러나 장기적인 Power Failure인 경우 Lock된 리소스를 Release 하기 위해 강제적으로 Commit나 Rollback을 시켜준다. 2. 데이타의 Access를 금지시키는 Failure [ 현상1. ] Transaction Time-out ORA-02049: time-out : distributed transaction waiting for lock Local의 DML 문장이 Remote의 다른 Transaction에 의해 Lock 되어 있는 데이타를 수정 및 삭제 하려고 할 때 Time-out이 발생하고 그 명령은 Rollback 된다. (Scenario) [ in REMOTE ] SQL>update dept set deptno=10; [ in LOCAL ] SQL>update dept set deptno=10; SQL>update dept@ORA7 set deptno=10; ORA-02049 : time-out [ 조치 방법 ] Local DB에는 Update가 발생하므로 항상 Rollback을 시켜야 한다. Remote DB는 변경되지 않으므로 Time-out의 결과로 다른 조치는 필요 없다. 위 상황에서 Time-Out Interval은 DISTRIBUTED_LOCK_TIMEOUT 파라미터로 Time Out 시간을 조정할 수 있다. [ 현상2. ] Lock from In-doubt Transaction ORA-01591 : Lock held by in-doubt distributed transaction ID Local DB에 Lock을 발생시키는 DML 문장을 In-doubt 분산 트랜잭션에 의해 Lock된 Resource에 계속해서 실행할 경우 발생하는 에러 (Scenario) (1) update dept@ORA7 set dname='AA'; (2) Remote DB down (3) Commit ORA-02054 : transaction 2.1.207 is in-doubt transaction (4) select * from dept; ORA-01591 : Lock held by in-doubt distributed transaction id 2.1.207 Local에서 dba_2pc_pending으로부터 In-doubt 트랜잭션 정보를 확인할 수 있다. [ 조치 방법 ] 이 경우 SQL 문장은 즉시 Rollback 되어야 하며 만일 Lock이 계속해서 걸려있으면 DBA에게 알리도록 한다. 이런 현상은 드물게 발생하며 Network나 System Failure가 빠르게 복구되면 문제는 자동적으로 해결된다. 3. 두 개 NODE 사이에 Connection이 만들어진 이후에 Network Failure가 발생한 경우 (Scenario) (1) Forms 화면에서 Data Update (2) Commit - DB Trigger에 의해서 Server Machine에 Server process가 생기며 Network와 Remote DB 가 정상적인 경우 Commit 된다. (3) Network Fail(Line 을 Disconnect) (4) Forms 화면에서 Update (5) Commit (6) Forms Screen이 Holding 상태로 됨 [ 조치 방법 ] Network이 복구되면 자동적으로 Commit 되지만 Network Failure가 장기화될 경우 강제로 Abort 시키는 조치가 필요하다. 강제로 Abort 이후 자동적으로 Rollback 되므로 더이상 조치가 필요하지 않다. 4. Network이 Down된 상태에서 Connection을 시도하려는 경우 (Scenario) (1) Network Down (2) Forms 화면에서 Data 수정 (3) Commit [조치 방법] 모든 Transaction이 Rollback 되므로 더 이상 조치가 필요하지 않으나 다만 Network Down된 상태에서 Connect를 시도하려고 하는 시간을 줄여서 곧바로 Error가 발생되도록 해야 한다. 5. Server Machine의 orasrv가 Down된 상태에서 Connect를 하려고 하는 경우 : ORA-06108 error 발생 6. In-doubt 트랜잭션을 Manually Overriding ?ORA-01591 Message가 발생하여 User가 조치를 요구하는 경우 ?In-doubt 트랜잭션이 Rollback Segment의 Extension를 막는 경우 ?Network 및 System Failure가 장기화 될 경우 t In-doubt 트랜잭션에 대한 정보를 얻는 방법 a.User Feedback을 기록 b.Local dba_2pc_pending View를 조회 c.Local dba_2pc_neighbors View를 조회 d.정상적으로 통신이 복구된 후에 Mixed Outcome Flag를 Check * Record User Feedback ORA-01591: Lock held by in-doubt distributed transaction 1.21.17 1.21.17 : local transaction id - Query dba_2pc_pending < global_db_name format > global_database_name.hhhhhhhh.local_transaction_id cf ) global_database_name=global coordinator db name hhhhhhhh=internal db id - Query dba_2pc_neighbors In-doubt 트랜잭션이 관 되어 있는 Connection에 대한 정보를 조회한다. 각 Connection에 대한 정보는 Connection이 Inbound, Outbound 이냐에 따라 다르다. 만일 Connection이 Inbound이면 그 Node는 다른 Node 의 Server이다. 만일 Connection이 Outbound이면 그 Node는 다른 Server의 Client이다. Interface Column 은 Local Node 혹은 Subordinate Node가 Commit Point Site 인지를 알려준다. 만일 Local Transaction id와 Global Transaction id가 일치하면 그 Node 는 Global Coordinator이다. - Check for Mixed Outcome 트랜잭션이 Manual로 Commit 혹은 Rollback된 후에 해당 Row가 Pending 트랜잭션 테이블에 남아있다. 그 트랜잭션의 상태는 "forced commit" or "forced abort" 로 변경되어지고 Instance 사이에 Connection이 복구되면 RECO는 트랜잭션의 Global Outcome을 Check하여 정상적인 경우 Row를 삭제하지만 틀린 방법으로 트랜잭션을 Force 시키면 삭제되지 않고 Mixed Column이 "Yes" 로 변경된다. 7. Manual Commiting In-Doubt Transaction COMMIT FORCE 'SALES.ACME.COM.55dic563.193.29'; COMMIT FORCE 'global_id', 829381993 (system commit number) 8. Manually Rolling Back In-Doubt Transaction ROLLBACK FORCE '2.9.4'; 9. Disabling and Enabling RECO ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY; ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY; 10. Commit Point Site 결정 . 번째 Commit하는 Node . In-Doubt Data를 가질 수 없다. . Prepared 상태로 될 수 없다. . 분산 데이타베이스에 참여하는 시스템 중 가장 안정된 시스템에 가장 높은 값을 준다. |
|||
| Comment | |||
|---|---|---|---|
| 등록된 코멘트가 없습니다. |