BULLETIN CATEGORY
BULLETIN TOPIC : RDBMS
: DDB 기본기능 및 분산 트랜잭션 문제의 해결
--------------------------------------------------------------------------------
여기서는 DDB(분산 데이타베이스)의 기능과 역할 및 사용 시에 발생하는 문제점들에 대해서 알아보기로 한다. 분산 DB 환경과 관련된 init<SID>.ora 화일의 파라미터는 다음과 같은 것들이 있다.
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
EX ) CREATE PUBLIC DATABASE LINK sales.acme.com USING 'dbstring';
4. Dropping Databsae Link
EX ) DROP PUBLIC DATABASE LINK sales.acme.com;
Two-Phase Commit의 구성
Two-Phase Commit은 Prepare Phase와 Commit Phase로 나누어 진다.
1. Prepare Phase
Global Coordinator(분산 Transaction을 일으킨 Node)가 분산 Transaction에 참석한 Node들에 대해 Commit이나 Rollback을 수행해도 되는가를 확인하는 단계이다.
2. Commit Phase
분산 Transaction에 참여한 Node가 Global Coordinator에게 분산 Commit해도 좋다는Response(즉 Prepare 되었음)를 받고 Transaction을 Commit한다. 어떠한 Node라도 Prepare가 안되었다는 Response가 있으면 Transaction을 Rollback한다.
Two-Phase Commit의 수행
1. Prepare Phase에 대한 Response는 Prepared, Read-Only, Abort가 있다.
A. Prepared는 Data가 정상적으로 수정되었으며 Prepare되었음을 의미한다.
B. Read-Only 는 해당Node에서 Data의 수정이 없었다는 의미이다.
C. Abort는 Prepare되지 않았음을 의미한다.
2. 모든 Node에서 Prepared가 되면 Commit Phase가 수행된다.
그러나 한 Node라도 Abort되면 Commit Phase에서 전 Node에 Rollback을 수행한다.
Two-Phase Commit 메카니즘
예를 들어 다음과 같은 경우를 가정해 보자
SQL> update 부서@Pusan
set 부서이름 = 기술연구소
where 부서코드 = 40;
SQL> update 사원@Seoul
set 부서코드 = 40;
where 사번 = 777;
SQL> commit; <-- 현재 시점에서 부서@Pusan 테이블은 변경이 됐지만, 사원
@Seoul 테이블을 변경하다가 네트웍 장애로 인해 변경이 안됐을 경우.
이런 경우에 오라클은 Two-Phase commit 알고리즘에 따라 자동으로 모두 롤백시킨다. 한 트랜잭션안에 remote update나 distributed update등이 있을때, commit이나 rollback을 실행하는 시점에서 트랜잭션의 모든 변경된 내용이 동시에 commit되거나 rollback된다.
분산처리 문제와 해결 방법
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가 장기화 될 경우
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 상태로 될 수 없다.
분산 데이타베이스에 참여하는 시스템 중 가장 안정된 시스템에 가장 높은 값을
준다.
BULLETIN TOPIC : RDBMS
: DDB 기본기능 및 분산 트랜잭션 문제의 해결
--------------------------------------------------------------------------------
여기서는 DDB(분산 데이타베이스)의 기능과 역할 및 사용 시에 발생하는 문제점들에 대해서 알아보기로 한다. 분산 DB 환경과 관련된 init<SID>.ora 화일의 파라미터는 다음과 같은 것들이 있다.
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
EX ) CREATE PUBLIC DATABASE LINK sales.acme.com USING 'dbstring';
4. Dropping Databsae Link
EX ) DROP PUBLIC DATABASE LINK sales.acme.com;
Two-Phase Commit의 구성
Two-Phase Commit은 Prepare Phase와 Commit Phase로 나누어 진다.
1. Prepare Phase
Global Coordinator(분산 Transaction을 일으킨 Node)가 분산 Transaction에 참석한 Node들에 대해 Commit이나 Rollback을 수행해도 되는가를 확인하는 단계이다.
2. Commit Phase
분산 Transaction에 참여한 Node가 Global Coordinator에게 분산 Commit해도 좋다는Response(즉 Prepare 되었음)를 받고 Transaction을 Commit한다. 어떠한 Node라도 Prepare가 안되었다는 Response가 있으면 Transaction을 Rollback한다.
Two-Phase Commit의 수행
1. Prepare Phase에 대한 Response는 Prepared, Read-Only, Abort가 있다.
A. Prepared는 Data가 정상적으로 수정되었으며 Prepare되었음을 의미한다.
B. Read-Only 는 해당Node에서 Data의 수정이 없었다는 의미이다.
C. Abort는 Prepare되지 않았음을 의미한다.
2. 모든 Node에서 Prepared가 되면 Commit Phase가 수행된다.
그러나 한 Node라도 Abort되면 Commit Phase에서 전 Node에 Rollback을 수행한다.
Two-Phase Commit 메카니즘
예를 들어 다음과 같은 경우를 가정해 보자
SQL> update 부서@Pusan
set 부서이름 = 기술연구소
where 부서코드 = 40;
SQL> update 사원@Seoul
set 부서코드 = 40;
where 사번 = 777;
SQL> commit; <-- 현재 시점에서 부서@Pusan 테이블은 변경이 됐지만, 사원
@Seoul 테이블을 변경하다가 네트웍 장애로 인해 변경이 안됐을 경우.
이런 경우에 오라클은 Two-Phase commit 알고리즘에 따라 자동으로 모두 롤백시킨다. 한 트랜잭션안에 remote update나 distributed update등이 있을때, commit이나 rollback을 실행하는 시점에서 트랜잭션의 모든 변경된 내용이 동시에 commit되거나 rollback된다.
분산처리 문제와 해결 방법
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가 장기화 될 경우
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 상태로 될 수 없다.
분산 데이타베이스에 참여하는 시스템 중 가장 안정된 시스템에 가장 높은 값을
준다.
 |  [100%환급,개발자전문]빅데이터/SQL/자바/스프링/안드로이드/닷… | 12-27 | 2641 | |
| [채용확정무료교육]오라클자바개발잘하는신입뽑기2개월과정,교육… | 12-11 | 1909 | |
| 53 | [평일100%환급7건]Spring,자바&JSP,안드로이드,웹퍼블리싱,C#닷… | 03-15 | 1723 | |
| 52 | [주말]C#,ASP.NET마스터 | 01-31 | 1847 | |
| 51 | [기업100%환급,평일주간]SQL기초에서스키마오브젝트,PLSQL,힌트… | 01-31 | 2684 | |
| 50 | [평일주간야간,주말]C기본&자료구조,알고리즘 | 01-31 | 1437 | |
| 49 | [평일주간,평일야간,주말]Spring,MyBatis,Hibernate개발자과정-… | 01-19 | 1759 | |
| 48 | [평일야간,주말]안드로이드개발자과정(Android기초실무) | 01-11 | 1645 | |
| 47 | [평일야간,주말주간야간]JAVA,Network&JSP&Spring,MyBatis,Hiber… | 01-03 | 2163 | |
| 46 | [100%환급,개발자전문]빅데이터/SQL/자바/스프링/안드로이드/닷… | 12-27 | 2641 | |
| 45 | [평일주간]NoSQL,MongoDB,빅데이터기초과정 | 12-19 | 1868 | |
| 44 | [평일주간야간, 주말]웹퍼블리싱 마스터(HTML5,CSS3,jQUERY,AJAX… | 12-14 | 1838 | |
| 43 | [채용확정무료교육]오라클자바개발잘하는신입뽑기2개월과정,교육… | 12-11 | 1909 | |
| 42 | [평일주간]빅데이터하둡기초과정(BigData Hadoop) | 12-09 | 1499 | |
| 41 | [평일야간]닷넷(C#,Network,ADO.NET,ASP.NET)마스터 | 12-01 | 1730 | |
| 40 | [기업100%환급]오라클&자바웹스프링신입과정3주(SQL,JAVA,JSP,Se… | 12-01 | 1907 | |
| 39 | [평일야간,주말]SQL기초에서실무까지(SQL기초,PLSQL,힌트,튜닝) | 12-01 | 1373 | |
댓글 없음:
댓글 쓰기