오라클에서 MERGE를 수행 할 수 있습니까?

Question

단일 WebLogic 클러스터에서 실행중인 J2EE 응용 프로그램의 인스턴스가 2 개 있습니다.

이러한 응용 프로그램은 어느 시점에서 백 엔드 Oracle 데이터베이스에 레코드를 삽입하거나 업데이트하기 위해 MERGE를 수행합니다. MERGE는 지정된 기본 키가있는 행이 있는지 여부를 확인합니다. 그것이 있으면 업데이트하십시오. 그렇지 않은 경우 삽입하십시오.

이제 두 개의 app 인스턴스가 기본 키가 100 인 행을 삽입하거나 업데이트하려고한다고 가정합니다. 행이 존재하지 않는다고 가정합니다. 병합의 "확인"단계에서 두 행은 병합되지 않았으므로 두 행 모두 삽입을 시도합니다. 그런 다음 고유 한 키 제약 조건 위반이 발생합니다.

내 질문은 : Oracle에 원자력이 있습니까? 내 응용 프로그램에서 SQL 만 실행할 수 있다는 점을 제외하면 PL/SQL의 INSERT ... FOR UPDATE과 비슷한 효과가있는 것을 찾고 있습니다.

편집 : 명확하지 않았습니다. 이 오류가 계속 발생하는 동안 MERGE 문을 사용하고 있습니다. 것은 "수정"부분 만이 전체 병합이 아니라 원자 (atomic)라는 것입니다.

Answer 1

두 번째 세션의 MERGE 문은 해당 세션이 커밋 될 때까지 첫 번째 세션이 수행 한 삽입을 "볼"수 없습니다. 트랜잭션의 크기를 줄이면 트랜잭션이 발생할 확률이 줄어 듭니다.

또는 주어진 기본 키의 모든 레코드가 동일한 세션에 제공되도록 데이터를 정렬하거나 파티셔닝 할 수 있습니까? "기본 키 mod N"과 같은 간단한 함수는 N 개의 세션에 균등하게 분산되어야합니다.

btw 두 레코드가 동일한 기본 키를 갖고 있으면 두 번째 레코드가 첫 번째 레코드를 덮어 씁니다. 좀 이상하다.

Answer 2

예, 그것이라고 .... MERGE

편집이 물 꽉을 얻을 수있는 유일한 방법은, 삽입 DUP_VAL_ON_INDEX 예외를 캐치 (적절하게 업데이트가 그것을 처리, 혹은 다른 레코드를 삽입하는 것입니다). 이것은 PL/SQL로 쉽게 수행 할 수 있지만 사용할 수는 없습니다.

해결 방법이 필요합니다. Java에서 dup_val_on_index를 catch하고 추가 UPDATE를 다시 발행 할 수 있습니까? 의사 코드에서

:

try { 
    // MERGE 
} 
catch (dup_val_on_index) { 
    // UPDATE 
} 

Answer 3

내가 그 MERGE 당신이 설명하는 방식으로 작동 할 놀라지,하지만 나는 그것을해야하는지 여부를 말할 충분히 그것을 사용하지 않았습니다.

어떤 경우에도 병합을 실행하려는 트랜잭션의 격리 수준이 SERIALIZABLE로 설정되어있을 수 있습니다. 나는 그것이 당신의 문제를 해결할 것 같아요.

Answer 4

MERGE와 같이 문제가되지 않습니다. 오히려 문제는 응용 프로그램에 있습니다.

create or replace procedure upsert_t23 
    (p_id in t23.id%type 
     , p_name in t23.name%type) 
is 
    cursor c is 
     select null 
     from t23 
     where id = p_id; 
    dummy varchar2(1); 
begin 
    open c; 
    fetch c into dummy; 
    if c%notfound then 
     insert into t23 
      values (p_id, p_name); 
    else 
     update t23 
      set name = p_name 
      where id = p_id; 
    end if; 
end; 

따라서 T23의 MERGE와 동일한 PL/SQL입니다. 두 세션이 동시에 그것을 호출하면 어떻게됩니까?

SSN1> exec upsert_t23(100, 'FOX IN SOCKS') 

SSN2> exec upsert_t23(100, 'MR KNOX') 

SSN1이 먼저 도착하고 일치하는 레코드를 찾지 않고 레코드를 삽입합니다. SSN1은 커밋되지 않고 SSN1이 커밋되기 전에 레코드를 찾지 않고 레코드를 삽입하고을 정지시킵니다. SSN1이 100의 고유 인덱스 노드를 잠그기 때문에 SSN2가 DUP_VAL_ON_INDEX 위반을 던집니다.

MERGE 문은 완전히 똑같은 방식으로 작동합니다. 두 세션 모두 on (t23.id = 100)을 확인하고 찾지 않고 INSERT 분기로 이동합니다. 첫 번째 세션은 성공하고 두 번째 세션은 ORA-00001을 던집니다.

이 문제를 처리하는 한 가지 방법은 비관적 잠금을 도입하는 것입니다.UPSERT_T23 절차의 시작에서 우리는 테이블을 잠글 :

는

... 
lock table t23 in row shared mode nowait; 
open c; 
... 

이제 SSN1 도착, 잠금을 잡고 이전과 같이 진행된다. SSN2가 도착하면 잠금을 얻을 수 없으므로 즉시 실패합니다. 두 번째 사용자에게는 실망스러운 점이 있지만 최소한 매달려 있지는 않으며, 다른 사람이 동일한 기록을 작성하고 있음을 알 수 있습니다.

선택할 필요가 없으므로 SELECT ... FOR UPDATE와 동일한 INSERT 구문이 없습니다. 따라서 MERGE에 대한 구문도 없습니다. 당신이해야 할 일은 MERGE를 발행하는 프로그램 유닛에 LOCK TABLE 문을 포함시키는 것입니다. 이것이 가능한지 여부는 사용중인 프레임 워크에 따라 다릅니다.