Oracle RAC로 2단계 커미트 분산 트랜잭션 구성
Oracle 10g의 RAC(Real Application Cluster) 구성은 Oracle이 여러 Oracle RAC 노드에 걸쳐 있는 2단계 커미트 분산 트랜잭션을 복구하려 시도할 때 트랜잭션 관리자와의 내재된 문제를 가지고 있습니다. 이 문제는 한 노드가 실패하고 Oracle RAC가 실패한 노드에 대한 필요한 복구 조치를 완료하기 전에 Oracle이 생존한 다른 노드를 비즈니스용으로 열 때 발생할 수 있습니다. Application Server의 트랜잭션 유사성을 유지하는 기능으로 이 문제를 피할 수 있습니다.
이 태스크 정보
ORA- 24756: transaction does not exist
이 오류가
발생하면 Oracle 데이터베이스 관리자는
롤백 또는 커미트 프로세스를 강제 실행하여 인다우트 트랜잭션을 수동으로
해결해야 할 수 있습니다. 하지만 수동 개입을 원하지 않으면
트랜잭션 복구를 위한 투명한 자동 전략을 구성하고자
할 수 있습니다. ORA-01591 lock held by in-doubt distributed transaction
결과는
데이터베이스의 일부를 사용할 수 없게 되는 것입니다. 투명한 복구 전략의 글로벌 트랜잭션이 여러 RAC 노드에서 둘 이상의 트랜잭션 분기에 걸쳐질 가능성을 제거하는 것입니다. 트랜잭션 분기는 글로벌 트랜잭션에서 얻는 데이터베이스 연결에 해당합니다. 글로벌 2단계 커미트 트랜잭션의 모든 연결이 동일한 노드에서 발생한 경우 트랜잭션 복구 문제가 발생하면 안됩니다. 2단계 트랜잭션에 대한 오류를 차단할 Application Server로 Oracle RAC를 구성하십시오.
Application Server는 수신 연결의 트랜잭션 유사성을 유지하며, 사용자는 이 기능을 이용하여 2단계 커미트 트랜잭션이 있는 Oracle RAC에 대한 자동 복구를 구성할 수 있습니다. 이 구성을 구현하면 주어진 Application Server로부터의 모든 연결이 동일한 Oracle 노드에서 수신되고 연결이 동일한 이 노드에서 완료됩니다. 이 구성은 트랜잭션이 여러 노드에 걸치는 상황을 피하며 하나 이상의 Oracle 노드가 중단될 경우 사용자는 복구 문제를 경험하지 않습니다.
프로시저
결과
srvctl start service -d -s
RAC 노드가
작동을 중지할 경우 Oracle은 Oracle RAC 정리 및 복구가
완료될 때까지 DTP 서비스를 장애 복구하지 않습니다. Oracle 노드가 다시 작동하더라도
Oracle DTP 서비스는 새로 다시 시작된 RAC 노드로
리턴하지 않습니다. 대신에 서비스를 다시 시작된 RAC 노드에 수동으로
이동시켜야 합니다. Oracle 서비스에 DTP을 구성하는 경우 Oracle JDBC 제공자에서 Application Server로 로드 밸런싱을 전송한 것입니다. Oracle 대신 Application Server가 워크로드를 분산하며, 이는 로드 밸런싱을 구현하지 않고 기본 노드를 하나만 사용하는 서비스를 작성했기 때문입니다. 이 구성은 트랜잭션 프로세스가 여러 RAC 노드에 걸치는 상황을 방지하고 하나 이상의 RAC 노드가 실패할 때 발생할 수 있는 복구 문제를 완화합니다.