> For the complete documentation index, see [llms.txt](https://docs.tibero.com/prosync/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tibero.com/prosync/administration/apply/key-features/flow-control/conflict/data-conflict-rule.md).

# Data Conflict Rule (DCR)

MAP Rule에서 소개한 Data Conflict Rule의 시나리오들을 정리한다. 옵션을 설정하는 방법은 해당 문서를 참고한다.

## DCR의 제약사항

Data Conflict를 확인하려면 Row를 특정할 수 있어야 한다. ProSync에서는 이에 대한 기준을 Primary key로 두고 있다. Primary key 로 인해 충돌이 발생할 경우, Source Database, Target Database, Column Min(Max) 기준으로 데이터 Conflict에 대한 처리를 결정한다.

{% hint style="info" %}
ProSync는 where절에 lob column은 확인하지 않으므로, 비교 시 해당 column의 데이터가 다르더라도 다른 column 값이 동일하다면 성공적으로 dml을 수행한다.

DCR - MIN/MAX 설정 후 동일한 값으로 dml 수행 시, 비교 로직에서 충돌을 유발하지 않으므로 양측 노드에서 정상 dml을 수행한다.
{% endhint %}

## 시나리오

### Resolve By Source

#### 1. Insert

Insert문에서 충돌이 발생한다는 것은, 이미 데이터가 존재한다는 의미이다. 따라서 존재하는 데이터를 모두 Source Database 기준으로 맞춰주어야 한다.

Insert문을 Update로 변경하여 Conflict를 해소해준다.

#### 2. Update

Update에서의 데이터 충돌은 원하는 Row가 없다는 의미이다.

Update문을 Insert로 변경하여 Conflict를 해소해준다.

#### 3. Delete

Delete에서의 데이터 충돌 또한 마찬가지로 Row가 없다는 의미가 된다.

Delete에 대한 추가적인 처리가 없이 넘어가면 된다.

### Resolve By Target

#### 1. Insert

Insert문의 충돌은 이미 데이터가 있을 때 발생하는데, Target Database 기준으로 맞춰야 하므로, 별도의 작업 없이 해당 처리를 건너뛴다.

#### 2. Update

Row가 없는 상황이 맞다고 판단하기 때문에 별도의 작업 없이 해당 처리를 건너뛴다.

#### 3. Delete

Row가 없는 상황이 맞다고 판단하기 때문에 별도의 작업 없이 해당 처리를 건너뛴다.

### Resolve By Min/Max

위 두 경우에 대한 조합으로 볼 수 있다. 상황에 따라 Source 기준 또는 Target 기준에 맞춰 수행하는 시나리오다. 기준이 되는 것이 Database 단위가 아닌 Column 내 데이터의 대소 비교로 이루어진다는 점이 다르고, 이에 따라 충돌 처리 동작은 위의 Source / Target과 동일하게 작동한다.

{% hint style="warning" %}
**주의**

**Data Conflict Rule(DCR) 관련**

Data Conflict Rule(DCR) 옵션을 사용할 경우 `USE_PK_FOR_WHERE` 옵션은 무시된다. 동기화의 논리 구조상 Conflict를 찾는 것이 우선이기 때문에 ProSync에선 두 옵션 간에 이와 같은 우선순위를 둔다.
{% endhint %}