[DB] Oracle Shareplex

[서론]

팀마다 사용하는 DB가 다를 것이다. 그리고 동기화하는 방법도 여러가지겠지만, CDC 인터페이스 중 Quest Software사의 Shareplex 솔루션을 간단히 정리해보고자 한다.

 

 

[인터페이스 유형]

* MQ : 비동기 메시지 서비스 / 서비스 및 이벤트간 연계 / 높은 응집도, 낮은 결합성 / 오픈소스 기반으로 낮은 유지보수성

* CDC : DBMS간 연계 솔루션 / 데이터 간 연계 / 양방향 데이터 동기화 문제

 

엔터프라이즈에서 가장 많이 사용하는 인터페이스 유형

 

 

 

---

[Shareplex]

소스와 타켓 간 DB동기화를 Redo/Archieve Log를 사용하여 진행한다. 

 

[동기화 순서]

1. 소스에 DML이 발생하면, 로그가 Capture 프로세스에 의해 Capture 큐에 Insert된다.

2. Read Process는 Capture 큐에 쌓인 로그를 읽어 Export 큐에 insert한다.

3. Export Process는 Export 큐에 있는 로그를 Target DB의 Shareplex의 Post Queue로 보낸다.

4. Post Process는 Post 큐에 있는 로그를 읽어 Target DB에 데이터를 반영한다.

 

[운영하면서 느낀점]

1. Archieve 로그를 통해 동기화가 진행되며, 대량의 DML이 발생하는 경우 (약 1000만건 이상) 동기화에 지연이 발생한다.

2. 간단한 명령어로 sync가 맞지 않는 테이블에 대해 바로 동기화가 가능하다.

3. 모든 테이블을 감시하는 것은 아니고, DML이 발생해야 실제 sync가 맞는 지 알 수 있다.

    즉, Source에서 UPDATE문이 발생하였는데, Target에 해당 ROW가 없다면 SYNC 에러가 발생한다.

    서비스가 중단되는 것은 아니며, 운영 담당자의 확인이 필요하다.

4. 신규 테이블 연동은 쉽지만, 실시간성 테이블 또는 대용량 테이블 연동하기에는 주의가 필요하다.

 

★중요★

- 오라클은 기본적으로 테이블 생성 시 no logging 조건으로 생성되는데, 대용량 DML이 발생하는 경우 Shareplex 프로세스가 아카이브 로그를 소화하는 데 지연이 발생할 수 있다.

- 지연만 발생한다면 그나마 다행인데, 아카이브 로그 또한 데이터이므로 로그가 쌓이다보면 DB용량의 한계치에 도달할 수 있다.

이 때, DB 담당자는 이를 조치하고자 로그 자체를 백업하려고 하는데, 백업 시 Shareplex가 아직 못 읽은 로그를 백업한다면 큰 장애로 이어질 수 있다. (Shareplex는 로그를 순서대로 읽어 Target DB로 전송한다)

 

이를 예방하기 위한 방법은

1. 대용량 작업 시, 굳이 CDC하는 테이블이 아니라면 NO LOGGING  조건을 부여하여 DML 작업을 진행한다.
2. 만약 이미 DB 담당자가 백업을 진행하여 Shareplex 프로세스가 로그를 못찾는다면, 백업한 아카이브 로그를 Restore(복구)하여 Shareplex 프로세스가 다시 아카이브 로그를 찾을 수 있게 해야한다.
3. Restore(복구) 후 Shareplex는 다시 동기화를 진행하는데, 이때 아카이브 로그 양에 따라 Source 와 Target DB 간 100% 동기화가 이루어 지는데 아카이브 로그 양에 따라 지연이 발생한다. (캡처 프로세스가 하나씩 읽어 Target에 전송하기 때문에)
4. 복구 후에는 큐 프로세스들이 모두 소화할 때까지 그냥 기다릴 수 밖에 없다... ㅠㅠ (캡처 큐가 하나이므로, 캡처 큐가 소화하는 걸 기다리는 방법 뿐이다)
    

 

[주로 사용하는 명령어]

명령어 모드($$)로 접속	설명	비고
$$ show	모든 큐 상태를 간략하게 볼 수 있다.
$$ qstatus	큐마다 지연되는 정도를 확인할 수 있다.
$$ repair SOURCE_SCHEMA.TABLE_NAME	동기화가 필요한 테이블에 대해 데이터 동기화 진행	- 실 운영은 거의 99.9% 동기화되고 있으므로 많이는 안쓰이며, 개발기에서 주로 사용 - repair시 테이블 자체가 LOCK이 잡히므로, 운영DB인 경우 신중하게 사용하여야 함
$$ list config	동기화되고 있는 테이블 목록 확인
$$ edit config CONFIG_FILENAME	동기화되고 있는 테이블 설정파일 변경
$$ copy config CONFIG_FILENAME to CONFIG_FILENAME_NEW	테이블 설정파일 복제
$$ verify config CONFIG_FILENAME	테이블 설정파일 검증
$$ activate config CONFIG_FILENAME	해당 설정파일로 동기화 진행

 

[shareplex 운영 재기동, 주의필요]

오라클 shareplex 프로세스를 재기동해야하는 경우가 있다. 운영 환경에서는 매우 주의가 필요하다(다운 시, 데이터 동기화 중단됨)

 

예시상황)

• R-IP : 1번 노드에 shareplex프로세스 있음
• V-IP : 2번 노드에 shareplex프로세스 있음
• 잘못된 상황($ ps -ef | grep sp_ 명령어보니, sp_cop 프로세스가 양 노드에 다 떠있음)

대처)

• R-IP, V-IP 모두 동일한 노드에만 떠 있어야 함
• 아래 명령어들 수행하여, shareplex 재기동 후 리소스 재배치 진행

쉘	설명	비고
$ crsctl stat res -t	shareplex 프로세스 상태 확인
$ crsctl stop resource shareplex	shareplex 프로세스 중지	root 또는 oracle 계정으로 가능
$ ps -ef | grep sp_ $ kill -9 P_ID	미처 다운되지 못한 프로세스 kill	root 또는 oracle 계정으로 가능
$ crsctl start resource shareplex	shareplex 프로세스 기동	root 또는 oracle 계정으로 가능
$ crsctl relocate resource shareplex -f	리소스 재배치	root 또는 oracle 계정으로 가능

 

---

참고자료

https://www.datanet.co.kr/news/articleView.html?idxno=167477

퀘스트소프트웨어, DB 관리·복제 솔루션 ‘셰어플렉스 10.1.2’ 출시 - 데이터넷

https://sharplee7.tistory.com/115

EAI, ESB, Message Queue 그리고 CDC 비교