> 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/patch.md).

# 패치 가이드

이 절차의 1단계부터 3단계까지는 패치 전 구버전 환경에서 구버전 바이너리로 수행하며, 명령 문법도 구버전 기준이다.

### 1. 로그 스위치 수행 (SRC DB)

4.0 기준 Abort 종료 시 이력을 저장하지 않기 때문에 로그를 처음부터 읽는다. 이를 위해 로그 스위치를 먼저 수행해야 한다.

```sql
ALTER SYSTEM SWITCH LOGFILE;
```

### 2. 프로세스 강제 종료 (SRC / TAR)

4.0 버전의 경우 `abort` 종료가 반드시 필요하다.

```bash
ADMIN> shutd man (abort);
```

### 3. 메타데이터 백업을 위한 유저 생성 (SRC / TAR)

기존 메타데이터를 백업하기 위해 별도의 백업 전용 유저를 생성하고 필요한 권한을 부여한다.

```sql
CREATE USER [백업유저이름] IDENTIFIED BY "[백업유저암호]";
GRANT CONNECT, RESOURCE, CREATE SESSION TO [백업유저이름];
GRANT INSERT ANY TABLE TO [백업유저이름];
GRANT CREATE ANY SYNONYM TO [백업유저이름];
GRANT CREATE ANY VIEW TO [백업유저이름];
```

### 4. var / config 디렉토리 이관

기존 환경의 데이터를 보존하면서 새 버전 바이너리로 마이그레이션하기 위해 디렉토리를 재구성한다.

```bash
mv prosync/var prosync_new/var
mv prosync/config prosync_new/config
mv prosync old_prosync
mv prosync_new prosync
```

### 5. prs\_install.cfg 작성

`prosync_new/prs_install.cfg` 파일을 생성하고 아래 내용을 포함한다.

```bash
############################################
#
# ProSync Installation Parameters
#
############################################

# (Mandatory)
INSTANCE_ID=instance
PRS_USER=prosync_user
PRS_PWD=prosync_user_password

# (Optional)
#PRS_TS_NAME=
#PRS_TS_FILE=
#PRS_TS_SIZE=
#PRS_SKIP_USER_CREATE=N
#PRS_TARGET_MIN_PRIVILEGE=N
#PRS_LOG_DIR=
#LOG_BACKUP_DIR=
#CREATE_DSN_FILE=N
#DSN_DIR=
#DSN_FILE=#need DSN_DIR

############################################
#
# ProSync Processes Informations for Instance Map
#
############################################
### (Optional)
AGENT_LIST_DELIMITER=,

### (Mandatory)
# Ext process
## Ext cnt must be the same as SRC_DB_CNT
EXT_CNT=1
EXT_AGENT_ID_LIST_0=agent1
#EXT_AGENT_ID_LIST_1=agent1,agent2

# Apply process
APPLY_PORT=7620
APPLY_AGENT_ID_LIST=agent1

# Llob process
LLOB_PORT=7630
LLOB_AGENT_ID_LIST=agent1

...
```

### 6. 메타데이터 백업 수행

기존 ProSync 환경에서 메타 정보를 백업한다.

```bash
export PREVIOUS_PRS_HOME=[old_prosync의 절대경로]
```

```bash
$PRS_HOME/install/prs_backup.sh \
  -c prs_install.cfg \
  -u [백업유저이름] \
  -p [백업유저암호]
```

{% hint style="info" %}
Oracle DB의 경우, 백업 수행하는 TABLESPACE 에 대한 쓰기 권한이 필요할 수 있다.

ALTER USER \[백업유저이름] QUOTA \[필요크기] ON \[TABLESPACE 명];

쿼리를 통하여 충분한 크기를 할당한다.
{% endhint %}

### 7. SRC DB 권한 부여

메타데이터 수집을 위해 SRC DB에서 필요한 권한을 부여한다.

```sql
GRANT SELECT ANY DICTIONARY TO $PRS_USER;
GRANT DELETE ANY TABLE TO $PRS_USER;

-- source db oracle인 경우
GRANT SELECT ON SYS.USER$ TO $PRS_USER;
GRANT SELECT ON SYS.ENC$ TO $PRS_USER;
GRANT SELECT ON SYS.OBJ$ TO $PRS_USER;
```

{% hint style="info" %}
Source DB가 Oracle인 경우 4.7의 Extract 프로세스는 기동 시 `SYS.ENC$`를 조회한다. Oracle 12c 이상에서는 `SELECT ANY DICTIONARY` 권한으로 `SYS.USER$`, `SYS.ENC$`를 조회할 수 없으므로 별도로 부여해야 하며, 권한이 없으면 Extract 프로세스가 기동하지 못한다.

9단계의 `prs_meta.sh`는 설치 config 파일의 `SRC_INSTALL_USER` 계정으로 Source DB의 ProSync 유저 권한을 다시 부여한다.
{% endhint %}

### 8. TAR DB 권한 부여

```sql
GRANT LOCK ANY TABLE TO $PRS_USER;
GRANT CREATE ANY TABLE TO $PRS_USER;
GRANT CREATE ANY SEQUENCE TO $PRS_USER;
GRANT CREATE ANY INDEX TO $PRS_USER;
GRANT CREATE ANY TRIGGER TO $PRS_USER;
GRANT CREATE ANY SYNONYM TO $PRS_USER;
GRANT CREATE ANY VIEW TO $PRS_USER;
GRANT CREATE ANY PROCEDURE TO $PRS_USER;
GRANT SELECT ANY DICTIONARY TO $PRS_USER;
GRANT ALTER ANY TABLE TO $PRS_USER;
GRANT ALTER ANY INDEX TO $PRS_USER;
GRANT ALTER ANY TRIGGER TO $PRS_USER;
GRANT ALTER ANY SEQUENCE TO $PRS_USER;
GRANT ALTER ANY PROCEDURE TO $PRS_USER;
GRANT DROP ANY TABLE TO $PRS_USER;
GRANT DROP ANY INDEX TO $PRS_USER;
GRANT DROP ANY TRIGGER TO $PRS_USER;
GRANT DROP ANY SEQUENCE TO $PRS_USER;
GRANT DROP ANY VIEW TO $PRS_USER;
GRANT DROP ANY PROCEDURE TO $PRS_USER;
GRANT DROP ANY SYNONYM TO $PRS_USER;
GRANT COMMENT ANY TABLE TO $PRS_USER;

-- target db oracle인 경우
GRANT SELECT ON SYS.OBJ$ TO $PRS_USER;
GRANT SELECT ON SYS.USER$ TO $PRS_USER;
GRANT SELECT ON SYS.COL$ TO $PRS_USER;
GRANT SELECT ON SYS.SEQ$ TO $PRS_USER;
```

### 9. prs\_obj\_group1.list 생성 및 메타 정보 이관

```bash
cp /dev/null $PRS_HOME/install/prs_obj_group1.list
```

{% hint style="info" %}
**참고**

`prs_meta.sh`는 목록 파일(`prs_obj_group#.list`)의 항목을 실행 시점의 Source DB에서 다시 조회해, 동기화 대상 목록(`PRS_OBJ_LIST`)에 아직 없는 객체만 새로 등록한다. 이미 등록된 객체는 그룹 번호를 포함해 그대로 유지되고, 목록 파일에 없는 기존 등록 객체도 삭제되지 않는다. `prs_backup.sh`로 백업 유저 스키마에 저장한 메타데이터는 `prs_meta.sh`가 참조하지 않으며, [롤백 가이드](/prosync/rollback.md)에서 메타데이터를 복구할 때 사용한다.

따라서 동기화 대상을 바꾸지 않으려면 위 예시처럼 항목이 없는 빈 목록 파일을 만든다. 설치 이후 Admin 명령 `ALTER <instance> ADD TABLE`, `ALTER <instance> DELETE TABLE`로 바꾼 동기화 대상도 `PRS_OBJ_LIST`에 이미 반영되어 있으므로 목록 파일에 적을 필요가 없다. 패치와 함께 동기화 대상을 추가하려면 추가할 객체만 목록 파일에 적는다.

설치 당시의 목록 파일이나 `$PRS_HOME/install/templates/prs_obj_group1.list.template`을 복사해 쓰지 않는다. 설치 이후 `DELETE TABLE`로 제외한 객체도 목록 항목에 맞으면 다시 등록되고, `TEST.%`처럼 `%`가 들어간 항목은 패턴에 맞지만 동기화 대상이 아니던 테이블과 시퀀스(설치 이후 생성한 객체 등)까지 등록한다. 템플릿에는 `TIBERO.%` 항목이 들어 있어, Source DB가 Tibero이면 TIBERO 스키마의 모든 테이블과 시퀀스가 등록된다. 이렇게 새로 등록된 객체는 Target DB에 같은 객체가 없으면 반영 단계에서 실패한다.

`prs_meta.sh`에 `-c`로 지정한 설치 config 파일(5단계의 `prs_install.cfg`)에 `GROUP_NUM`을 2 이상으로 지정했다면 `prs_obj_group2.list`부터 `prs_obj_group<GROUP_NUM>.list`까지도 같은 방법으로 빈 파일을 만든다. 하나라도 없으면 `prs_meta.sh`가 `not found`를 출력하고 Source DB 메타를 갱신하는 도중에 중단되며 Target DB 메타는 갱신되지 않으므로, 파일을 모두 만든 뒤 `prs_meta.sh`를 다시 수행한다. 설치 시 `-l` 옵션으로 다른 목록 파일을 사용했더라도 `prs_meta.sh`에는 `-l`을 지정하지 않는다.
{% endhint %}

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

`prs_meta.sh`는 5단계에서 작성한 `prs_install.cfg`의 값으로 Source DB의 DDL 트리거와 supplemental log를 다시 설정하므로, `AUTO_SYNC_ON_CREATE`, `AUTO_ADD_SUPP_LOG`, `SUPP_LOG_LVL_ALL`은 기존 설치에 사용한 설치 config 파일과 같은 값으로 둔다. `AUTO_SYNC_ON_CREATE=Y`가 없으면 동기화 대상 자동 등록이 꺼진다. Source DB가 Oracle이고 `AUTO_ADD_SUPP_LOG`가 `N`이 아니면, `SUPP_LOG_LVL_ALL=Y`가 없을 때 설정되어 있던 database level supplemental log(ALL)를 해제하고 동기화 대상 테이블에만 테이블 단위로 설정한다.
{% endhint %}

#### 메타 정보 이관 예시

```bash
$PRS_HOME/install/prs_meta.sh -c prs_install.cfg
```

`prs_meta.sh`는 Source DB의 ProSync DDL 트리거와 패키지를 다시 생성하고, 새 버전에서 추가된 메타 테이블과 컬럼을 만든다. Target DB가 Oracle 또는 Tibero인 경우에는 새 버전에서 추가된 메타 객체를 만들고 `PRS_APPLY` 패키지를 다시 생성한다. 설치 시 DB에 생성되는 객체에 포함된 변경은 바이너리 교체만으로 반영되지 않으므로 이 단계를 반드시 수행한다.

### 10. Config 파일 수정

#### 10.1. 각 process별 cfg 파일 내 파라미터 수정

* LISTENER\_PORT 제거
* TOP\_ID 제거
* Log 및 Backup Log 경로 수정

4.4.x 이후 Agent 포트는 cfg 가 아니라 `prs_instance.map` 의 `(PORT=...)` 로 지정되며, `TOP_ID` 는 인스턴스 이름으로 대체되었다.

#### 10.2. `vf.cfg` 삭제 확인

#### 10.3. `prs_mgr.cfg` → `prs_agent_{agent_id}.cfg` 으로 변경

### 11. Agent 설치

4.4.x 버전 이후(4.7 포함)에는 Agent 설치가 Instance 설치와 분리되었기 때문에, 패치 작업 전에 반드시 Agent 설치를 완료해야 한다. Agent 설치를 건너뛰고 Instance 설치를 진행하면 `prs_install.sh` 가 `Operation of prs_install_agent.sh should be preceded.` 를 출력하며 즉시 종료한다. 자세한 설치 방법은 [Agent 설치](/prosync/installation/prosync/agent.md) 문서를 참고한다.

### 12. prs\_top.map 변경 사항

4.4.x 부터는 `prs_top.map`에서 `prs_instance.map`으로 변경되었다.

#### 4.0 형식

```bash
MGR=(ID=lmgr)(HOST=localhost)(PORT=7600)

Prosync=(
    EXT1=(MGR=lmgr)(HOST=localhost)(PORT=7610)(PROGRAM=prs_ext)
    APPLY1=(MGR=lmgr)(HOST=localhost)(PORT=7620)(PROGRAM=prs_apply)
    LLOB=(MGR=lmgr)(HOST=localhost)(PORT=7630)(PROGRAM=prs_llob)
    VF=(MGR=lmgr)(HOST=localhost)(PORT=7640)(PROGRAM=prs_vf)
)
```

#### 4.4.x 이후 형식

```bash
AGENT=(ID=agent1)(HOST=172.19.0.11)(PORT=7600)

Prosync=(
    EXT1=(AGENT=agent1)(PROGRAM=prs_ext)
    APPLY1=(AGENT=agent1)(PORT=7620)(PROGRAM=prs_apply)
    LLOB=(AGENT=agent1)(PORT=7630)(PROGRAM=prs_llob)
)


```

위 예시의 `PROGRAM` 값은 Tibero 에서 Tibero 로 동기화하는 경우이며, `PROGRAM` 은 DB 종류에 따라 접두사가 붙는다. 무접두사는 Tibero, `o` 는 Oracle, `p` 는 PostgreSQL 이고 ext/llob 은 소스 DB, apply 는 타겟 DB 를 기준으로 선택된다. 예를 들어 Oracle 에서 Tibero 로 동기화하는 경우 `EXT1` 의 `PROGRAM` 은 `prs_oext`, `APPLY1` 의 `PROGRAM` 은 `prs_apply` 가 된다.

* localhost 제약 제거
* Instance에서 Host 제거 및 MGR → Agent로 변경
* ext process에서 Port 제거
* verify process삭제

### 13. ProSync 재기동

4.4.x 이후(4.7 포함)는 manager 대신 agent를 사용하기 때문에 agent 기동 명령어도 `man(ager)`에서 `age(nt)`로 변경되었다.

```bash
ADMIN> start age(nt) {AGENT_ID}
ADMIN> start {INSTANCE_ID}
```