IT study

[RDS Oracle] Data Pump와 Amazon S3 버킷으로 데이터 내보내기, 가져오기

DBnA — Wed, 4 Feb 2026 11:35:14 +0900

소스서버에서 타겟서버로 특정 스키마 이관

1.사전 작업

--s3관련 패키지 확인 없으면 RDS 옵션그룹에 S3_INTEGRATION 추가 (유지보수잇으면 같이반영될수 있음)
https://repost.aws/knowledge-center/rds-oracle-s3-integration

SELECT object_name, object_type
FROM dba_objects
WHERE owner = 'RDSADMIN'
AND object_name LIKE '%S3%';

--s3 iam 역할 생성 후 > RDS 연결

2.소스서버 테스트데이터 생성

-- ts 생성
CREATE TABLESPACE TS_TEST;

--스키마생성
CREATE USER test_user IDENTIFIED BY test DEFAULT TABLESPACE TS_TEST
TEMPORARY TABLESPACE TEMP QUOTA UNLIMITED ON TS_TEST;

--권한부여
GRANT CONNECT, RESOURCE, CREATE VIEW, CREATE SEQUENCE, CREATE TRIGGER TO test_user;

CREATE TABLE test_user.tb_article (
    article_id   NUMBER PRIMARY KEY,
    title        VARCHAR2(200),
    content      CLOB,
    created_at   DATE DEFAULT SYSDATE
)
TABLESPACE TS_TEST LOB (content)
STORE AS ( TABLESPACE TS_TEST ENABLE STORAGE IN ROW );

CREATE INDEX test_user.idx_tb_article_title ON test_user.tb_article(title) TABLESPACE TS_TEST;

CREATE SEQUENCE test_user.seq_tb_article START WITH 1 INCREMENT BY 1 NOCACHE;

BEGIN
  FOR i IN 1..100 LOOP
    INSERT INTO test_user.tb_article (article_id, title, content )
VALUES (i, 'Test Title ' || i, 'This is CLOB test content for article #' || i || '. ' || RPAD('CLOB_DATA_', 2000, 'X') );
  END LOOP;
  COMMIT;
END;

3. 소스 작업

select * from table(rdsadmin.rds_file_util.listdir('DATA_PUMP_DIR')) order by mtime; --기본데이터덤프

--export 진행
DECLARE
  v_hdnl NUMBER;
BEGIN
  v_hdnl := DBMS_DATAPUMP.OPEN(
    operation => 'EXPORT',
    job_mode  => 'SCHEMA',
    job_name  => null
  );
  DBMS_DATAPUMP.ADD_FILE(
    handle    => v_hdnl         ,
    filename  => 'test_user_expdp_260204.dmp'   ,
    directory => 'DATA_PUMP_DIR',
    filetype  => dbms_datapump.ku$_file_type_dump_file
  );
  DBMS_DATAPUMP.ADD_FILE(
    handle    => v_hdnl,
    filename  => 'test_user_expdp_260204.log',
    directory => 'DATA_PUMP_DIR' ,
    filetype  => dbms_datapump.ku$_file_type_log_file
  );
  DBMS_DATAPUMP.METADATA_FILTER(v_hdnl,'SCHEMA_EXPR','IN (''TEST_USER'')');
  DBMS_DATAPUMP.METADATA_FILTER(
    v_hdnl,
    'EXCLUDE_NAME_EXPR',
    q'[IN (SELECT NAME FROM SYS.OBJ$
           WHERE TYPE# IN (66,67,74,79,59,62,46)
           AND OWNER# IN
             (SELECT USER# FROM SYS.USER$
              WHERE NAME IN ('RDSADMIN','SYS','SYSTEM','RDS_DATAGUARD','RDSSEC')
             )
          )
    ]',
    'PROCOBJ'
  );
  DBMS_DATAPUMP.START_JOB(v_hdnl);
END;
/

--생성 파일 확인
select * from table(rdsadmin.rds_file_util.listdir('DATA_PUMP_DIR')) order by mtime;

--s3에 업로드
SELECT rdsadmin.rdsadmin_s3_tasks.upload_to_s3(
  p_bucket_name    =>  'sbn-bucket-test',
  p_prefix => 'test_user_expdp_260204.dmp',
  p_s3_prefix      =>  'oracle_dump/',
  p_directory_name =>  'DATA_PUMP_DIR' )
AS TASK_ID FROM DUAL;

-->taskid나오면 확인
SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-1770169906983-178.log'));

4. 타겟 작업

--타겟db dump 파일 다운로드
SELECT rdsadmin.rdsadmin_s3_tasks.download_from_s3(
  p_bucket_name    =>  'sbn-bucket-test',
  p_s3_prefix      =>  'oracle_dump/',
  p_directory_name =>  'DATA_PUMP_DIR')
AS TASK_ID FROM DUAL;

SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-1770170979421-189.log'));

-- Directory Dump 파일 확인
SELECT *
   FROM TABLE(rdsadmin.rds_file_util.listdir('DATA_PUMP_DIR'))
  ORDER BY mtime;

--특정스키마 지정, 테이블스페이스 remap 안할시 타겟에 TS, 스키마 먼저 생성
CREATE TABLESPACE TS_TEST;

--스키마생성
CREATE USER test_user IDENTIFIED BY test DEFAULT TABLESPACE TS_TEST TEMPORARY TABLESPACE TEMP
QUOTA UNLIMITED ON TS_TEST;

-- import 진행
DECLARE
  v_hdnl NUMBER;
BEGIN
  v_hdnl := DBMS_DATAPUMP.OPEN(
    operation => 'IMPORT',
    job_mode  => 'SCHEMA',
    job_name  => null);
  DBMS_DATAPUMP.ADD_FILE(
    handle    => v_hdnl,
    filename  => 'test_user_expdp_260204.dmp',
    directory => 'DATA_PUMP_DIR',
    filetype  => dbms_datapump.ku$_file_type_dump_file);
  DBMS_DATAPUMP.ADD_FILE(
    handle    => v_hdnl,
    filename  => 'test_user_impdp_260204.log',
    directory => 'DATA_PUMP_DIR',
    filetype  => dbms_datapump.ku$_file_type_log_file);
     DBMS_DATAPUMP.METADATA_FILTER(v_hdnl,'SCHEMA_EXPR','IN (''TEST_USER'')'); --특정스키마 지정시
    --DBMS_DATAPUMP.METADATA_REMAP(handle=>v_hdnl, name=> 'REMAP_SCHEMA', old_value=>'TEST_USER', value=>'ADMIN'); --스키마변경필요시
    --DBMS_DATAPUMP.METADATA_REMAP(handle=>v_hdnl, name=> 'REMAP_TABLESPACE', old_value=>'TS_TEST', value=>'USERS');--테이블스페이스 변경 필요시
     --작업건너뛰기 설정도 가능
  DBMS_DATAPUMP.START_JOB(v_hdnl);
END;

--log파일 확인
SELECT * FROM TABLE
    (rdsadmin.rds_file_util.read_text_file(
        p_directory => 'DATA_PUMP_DIR',
        p_filename  => 'test_user_impdp_260204.log'));

--확인
SELECT * FROM DBA_objects WHERE OWNER=' TEST_USER ';

5. 추후 불필요 파일 삭제

--생성 파일 확인
select * from table(rdsadmin.rds_file_util.listdir('DATA_PUMP_DIR')) order by mtime;

--생성 파일 삭제
BEGIN
UTL_FILE.FREMOVE('DATA_PUMP_DIR', 'test_user_expdp_260204.log');
UTL_FILE.FREMOVE('DATA_PUMP_DIR', 'test_user_expdp_260204.dmp');
END;

[PostgreSQL] 물리 백업과 복구 2 - pg_basebackup

DBnA — Tue, 30 Dec 2025 10:16:33 +0900

1. pg_basebackup을 이용한 전체 백업

pg_basebackup은 postgresql이 제공하는 기본 백업 도구로 전체 백업 간편하게 수행할 수 있다.

# pg_hba.conf 파일에 로컬 복제 항목 추가
[postgres@11039b77a76b svcdb]$ vi $PGDATA/pg_hba.conf

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   replication     postgres                                peer

# archive_command 설정

archive_mode = on
archive_command = 'dd if=%p of=/dbbackup/svc01/archive/tmp/%f.tmp && mv /dbbackup/svc01/archive/tmp/%f.tmp /dbbackup/svc01/archive/%f'

# 아카이브 디렉토리 생성 후 인스턴스 재기동
[postgres@11039b77a76b svc01]$ mkdir -p /dbbackup/svc01/archive/tmp/
[postgres@11039b77a76b svc01]$ pg_ctl restart

#백업 수행
-D 옵션으로 디렉토리 경로 설정
[postgres@11039b77a76b ~]$ pg_basebackup -D /dbbackup/svc01/20251229F -U postgres -c fast -v -P

테이블스페이스 사용시 --tablespace-mapping 옵션으로 테이블스페이스별로 백업 경로 명시적으로 지정해줘야한다.

2. pg_basebackup 증분 백업

V17부터는 pg_basebackup은 블록 단위 증분 백업 기능을 지원한다.
블록 단위 증분 백업을 위해서는 WAL 파일 기반으로 변경된 블록 위치를 식별해야한다.
변경된 블록위치 저장하기 위해 walsummarize 백그라운드 프로세스가 추가되어있으며, summarize_wal 파라미터를 on으로 설정하면 해당 프로세스가 기동된다.

# summarize_wal 파라미터 on 설정
[postgres@11039b77a76b 20251230F]$ echo "summarize_wal = on" >> $PGDATA/postgresql.conf
[postgres@11039b77a76b 20251230F]$ pg_ctl reload

[postgres@11039b77a76b 20251230F]$ cd $PGDATA/pg_wal/summaries
디렉토리에 저장됨

#테스트 데이터 생성
svcdb=# drop table t1 cascade;
DROP TABLE
svcdb=# create table t1(c1 char(100));
CREATE TABLE
svcdb=# insert into t1 select 'A' from generate_series(1,1000000);
INSERT 0 1000000

#전체 백업 1회 수행
[postgres@11039b77a76b svc01]$ pg_basebackup -D /dbbackup/svc01/20251230F -U postgres -c fast -v -P

#테스트 데이터 1건 입력
svcdb=# insert into t1 values ('B');
INSERT 0 1

#증분 백업 진행
[postgres@11039b77a76b svc01]$ pg_basebackup -D /dbbackup/svc01/20251230I -U postgres -c fast -v -P --incremental=/dbbackup/svc01/20251230F/backup_manifest

#확인
svcdb=# select pg_relation_filepath('t1');
pg_relation_filepath
----------------------
base/57359/65551
(1 row)

[postgres@11039b77a76b 57359]$ pwd
/dbbackup/svc01/20251230I/base/57359
[postgres@11039b77a76b 57359]$ ls -alh *65551*
-rw------- 1 postgres postgres 16K Dec 30 00:50 INCREMENTAL.65551
-rw------- 1 postgres postgres 12 Dec 30 00:50 INCREMENTAL.65551_vm

16K로 변경된 블록만 저장됨을 확인

3. pg_basebackup 을 이용한 완전 복구 (전체 백업)

pg_basebackup을 이용한 완전 복구는 전체 백업 or 증분 백업을 이용하는 방식이 있다.

3.1 전체 백업 을 이용한 완전 복구

1) 데이터베이스 클러스터 내의 모든 파일을 삭제한다
2) 백업본을 원래 위치로 복사한다
3) 심볼릭 링크 생성
4) recovery.signal 파일 생성
5) restore_command 파라미터 설정
6) 인스턴스 시작

#복구 테스트 위해 전체 백업 수행
[postgres@11039b77a76b svc01]$ pg_basebackup -D /dbbackup/svc01/20260114F -U postgres -c fast -v -P
Password:
pg_basebackup: initiating base backup, waiting for checkpoint to complete
...

#백업 후 테스트 테이블에 100만건 추가 입력
svcdb=# insert into t1 select 'B' from generate_series(1,1000000);
INSERT 0 1000000

#$PGDATA 볼륨 디스크 장애로 모든 데이터 파일 손상 가정
[postgres@11039b77a76b svc01]$ rm -rf $PGDATA

#백업된 $PGDATA 파일 원래 위치로 복사
[postgres@11039b77a76b svc01]$ cd /dbbackup/svc01
[postgres@11039b77a76b svc01]$ cp -rp 20260114F /data/svc01

#pg_wal 디렉토리에 심볼릭 링크 생성 - WAL파일 별도 디렉토리에 저장되므로
[postgres@11039b77a76b svc01]$ cd $PGDATA
[postgres@11039b77a76b svc01]$ rm -rf pg_wal
[postgres@11039b77a76b svc01]$ ln -s /pg_wal/svc01 ./pg_wal

->복구준비 완료
# $PGDATA에 recovery.signal 파일 생성
[postgres@11039b77a76b svc01]$ cd $PGDATA
[postgres@11039b77a76b svc01]$ touch recovery.signal

#아카이브 적용 설정
[postgres@11039b77a76b svc01]$ echo "restore_command ='cp /dbbackup/svc01/archive/%f %p'" >> postgresql.auto.conf

# 인스턴스 기동 -> restore_command 파라미터에 지정된 디렉토리에서 아카이브된 WAL 파일 모두 적용하고, 이어서 $PGDATA/pg_wal 디렉토리의 Current WAL 파일 적용한다.
[postgres@11039b77a76b svc01]$ pg_ctl start
waiting for server to start....2026-01-14 07:49:44.167 UTC [4341] LOG:  redirecting log output to logging collector process
2026-01-14 07:49:44.167 UTC [4341] HINT:  Future log output will appear in directory "log".
done
server started

#확인
[postgres@11039b77a76b svc01]$ psql
psql (17.7)
Type "help" for help.

postgres=# \c svcdb
You are now connected to database "svcdb" as user "postgres".
svcdb=# select count(1) from t1;
  count
---------
2000001
(1 row)

3.2 증분 백업을 이용한 완전 복구

pg_combinebackup 명령어 이용 외에 전체복구와 비슷

1) 데이터베이스 클러스터 내의 모든 파일을 삭제한다
2) pg_combinebackup 명령어를 이용해서 전체,증분 백업 파일을 합쳐서 복원한다.
3) 심볼릭 링크 생성
4) recovery.signal 파일 생성
5) restore_command 파라미터 설정
6) 인스턴스 시작

#테스트 데이터 insert
svcdb=# insert into t1 select 'C' from generate_series(1,1000);
INSERT 0 1000

#전체백업 이후 첫번째 증분백업  (전체백업은 직전 생성한 20260114F 이용)
[postgres@11039b77a76b svc01]$ pg_basebackup -D /dbbackup/svc01/2026011417I -U postgres -c fast -v -P --incremental=/dbbackup/svc01/20260114F/backup_manifest

#테스트 데이터 insert 2 (복수개의 증분파일 생성위함)
svcdb=# insert into t1 select 'D' from generate_series(1,1000);
INSERT 0 1000

#2번째 증분백업 ( 이전 증분백업의 backup_manifest 사용)
[postgres@11039b77a76b svc01]$ pg_basebackup -D /dbbackup/svc01/2026011418I -U postgres -c fast -v -P --incremental=/dbbackup/svc01/2026011417I/backup_manifest

#$PGDATA 볼륨 삭제 -장애
[postgres@11039b77a76b svc01]$ rm -rf $PGDATA

#pg_combinebackup 으로 전체백업과 증분백업을 순서대로 조합하여 복원한다. 전체백업 -> 가장오래된 증분백업 -> 최근 증분백업 순
[postgres@11039b77a76b svc01]$ pg_combinebackup -o /data/svc01 /dbbackup/svc01/20260114F /dbbackup/svc01/2026011417I /dbbackup/svc01/2026011418I

--이하 과정 전체증분 복구과정과 동일
#pg_wal 디렉토리에 심볼릭 링크 생성 - WAL파일 별도 디렉토리에 저장되므로
[postgres@11039b77a76b svc01]$ cd $PGDATA
[postgres@11039b77a76b svc01]$ rm -rf pg_wal
[postgres@11039b77a76b svc01]$ ln -s /pg_wal/svc01 ./pg_wal

->복구준비 완료
# $PGDATA에 recovery.signal 파일 생성
[postgres@11039b77a76b svc01]$ cd $PGDATA
[postgres@11039b77a76b svc01]$ touch recovery.signal

#아카이브 적용 설정
[postgres@11039b77a76b svc01]$ echo "restore_command ='cp /dbbackup/svc01/archive/%f %p'" >> postgresql.auto.conf

# 인스턴스 기동 -> restore_command 파라미터에 지정된 디렉토리에서 아카이브된 WAL 파일 모두 적용하고, 이어서 $PGDATA/pg_wal 디렉토리의 Current WAL 파일 적용한다.
[postgres@11039b77a76b svc01]$ pg_ctl start
waiting for server to start....2026-01-14 08:39:00.718 UTC [5077] LOG:  redirecting log output to logging collector process
2026-01-14 08:39:00.718 UTC [5077] HINT:  Future log output will appear in directory "log".
done
server started

#확인
[postgres@11039b77a76b svc01]$ psql
psql (17.7)
Type "help" for help.

svcdb=# select count(1) from t1;
  count
---------
2002001

[PostgreSQL] 물리 백업과 복구 1 - pgBackRest

DBnA — Mon, 29 Dec 2025 17:21:08 +0900

물리 백업 : 데이터베이스 클러스터를 구성하는 파일 단위의 백업
온라인 백업 - 인스턴스가 기동 중인 상태에서 수행
오프라인 백업 - 인스턴스를 종료한 뒤 수행

장애시점까지의 '완벽한 복구'를 지원하며,
사용자의 실수로 데이터가 삭제되었을 경우에도 손실 직전 시점까지 복구할 수 있는 시점 복구(Point-in-Time Recovery) 기능 제공

1. 백업 및 복구 개요

1) 백업 유형
- 전체 백업 ( Full Backup ) : 데이터베이스 클러스터 내의 모든 파일을 백업
- 증분 백업 ( Incremental Backup ) : 마지막 증분 백업 이후에 변경된 내용만 백업
- 차등 백업 ( Differential Backup ) : 마지막 전체 백업 이후에 변경된 내용만 백업

2) 복구에 필요한 백업 데이터 세트
최근 백업 파일 + 장애시점까지 생성된 모든 WAL 파일
- 증분 백업 : 마지막 전체 백업 + 모든 증분 백업 + 마지막 증분 백업 이후의 WAL 파일
- 차등 백업 : 마지막 전체 백업 + 마지막 차등 백업 + 해당 시점 이후의 WAL 파일

증분 백업의 경우 이전 백업 이후 변경분만 백업하므로 백업속도는 빠르나, 전체 백업 주기가 길어질수록 복구 대상이 많아지고 북구시간이 늘어날 수 있음.
차등백업 : 전체 백업 이후의 변경분을 백업하므로 백업속도는 느리나, 하나의 전체백업과 하나의 차등 백업만 있으면 복구가 가능하므로, 복구 속도 측면에서는 차등 백업 방식이 더 유리

3) 백업 주기
복구시간 관점에서 전체 백업을 매일 수행하는 것이 이상적. 최근 수행 전체백업과 이후 WAL파일만 있으면 완전 복구 가능.
어려운 경우
전체백업 주 1회 + 차등 or 증분 백업 매일 수행하는 방식으로 운영

4) 백업 파일 보관 기간
필요에 따라 1주일 ~ 1개월 범위 내에서 파일 보관

5) 백업 툴 선정
v16 이하 : pgBackRest 모든 측면에서 유리
v17 이상 : pg_basebackup 강력한 증분 백업 기능 지원

pgBackRest : 변경된 파일 단위의 증분 백업, 1GB 파일에서 1바이트만 변경돼도 1GB파일을 다시 백업하므로 증분or 차등 백업 사용해도 백업 디스크 사용률 절감 효과 크지 않음.
pg_basebackup : '변경된 블록 단위', 백업 시간과 백업 용량 모두 줄일 수 있다.

2. pgBackRest 설치 및 환경 파일 설정

#EPEL 저장소 설치 및 pgBackRest설치
[root@11039b77a76b /]# dnf install epel-release-9-10.el9.noarch.rpm

[root@ 11039b77a76b /]# dnf install -y epel-release
[root@11039b77a76b /]# dnf install pgbackrest

#백업파일 생성
[root@11039b77a76b /]# mkdir dbbackup
[root@11039b77a76b /]# chown -R postgres:postgres /dbbackup
[postgres@11039b77a76b dbbackup]$ mkdir log
[postgres@11039b77a76b dbbackup]$ mkdir spool

#pgBackRest 환경 설정 파일 생성
[postgres@11039b77a76b dbbackup]$ vi pgbackrest.conf
[postgres@11039b77a76b dbbackup]$ mkdir log
[postgres@11039b77a76b dbbackup]$ mkdir spool
[postgres@11039b77a76b dbbackup]$ cat pgbackrest.conf

[global]
repo1-path=/dbbackup
log-path=/dbbackup/log
spool-path=/dbbackup/spool
repo1-retention-full=2
repo1-retention-diff=2

[svcdb]
pg1-path=/data/svc01
pg1-port=5432
start-fast=y
compress-type=gz
compress-level=1
process-max=4

#스탠자 생성
[postgres@11039b77a76b dbbackup]$ pgbackrest --stanza=svcdb stanza-create --config=/dbbackup/pgbackrest.conf
[postgres@11039b77a76b dbbackup]$ ls -al
total 28
..
drwxr-x--- 3 postgres postgres 4096 Dec 29 04:41 archive
drwxr-x--- 3 postgres postgres 4096 Dec 29 04:41 backup
..

#postgresql.conf 파일 설정 추가 후 재시작
[postgres@11039b77a76b svc01]$ vi postgresql.conf

archive_mode = on # enables archiving; off, on, or always
archive_command = 'pgbackrest --stanza=svcdb archive-push %p --config=/dbbackup/pgbackrest.conf'

[postgres@11039b77a76b svc01]$ pg_ctl restart

3. pgBackRest 이용한 백업

--type에 따라 full(전체) / diff(차등) / incr (증분)
pgbackrest --stanza=svcdb --type=full backup --config=/dbbackup/pgbackrest.conf
pgbackrest --stanza=svcdb --type=diff backup --config=/dbbackup/pgbackrest.conf
pgbackrest --stanza=svcdb --type=incr backup --config=/dbbackup/pgbackrest.conf

4. pgBackRest 를 이용한 완전 복구

완전 복구를 위해서는 최근 백업본 + 아카이브된 WAL 파일 + Current WAL 파일이 필요하다.

$PGDATA 디렉토리와 테이블스페이스 디렉토리 존재하는 모든 데이터 파일 삭제된 상황에서도
위 파일을 통해 완전 복구가 가능하다.

WAL디스크볼륨손상으로 Current Wal 파일 유실된 경우, 완전 복구할 수 없으며 백업된 WAL 까지만 복구가능하다.
이를 불완전 복구라고 한다.

* pgBackRest 사용시에는 summarize_wal 파라미터를 off로 유지해야한다.

4-1. pgBackRest 를 이용한 완전 복구 (전체 복원 방식)

$PGDATA 볼륨 자체가 손상된 경우에 사용한다.
1) pgbackrest restore 명령어 실행
2) WAL 파일 저장 디렉토리에 대한 심볼릭 링크 생성
3) 인스턴스 시작

#테스트 데이터 입력
svcdb=# drop table t1 cascade;
DROP TABLE
svcdb=# create table t1 (c1 char(100));
CREATE TABLE
svcdb=# insert into t1 select 'A' from generate_series(1,1000);
INSERT 0 1000

#전체백업 수행
[postgres@c05692802685 dbbackup]$ pgbackrest --stanza=svcdb --type=full backup --config=/dbbackup/pgbackrest.conf

#추가 데이터 입력
svcdb=# insert into t1 select 'B' from generate_series(1,1000000);
INSERT 0 1000000

#장애가정1) 볼륨 디스크 장애로 모든 데이터파일 손상된 - $PGDATA 디렉토리 삭제
[postgres@c05692802685 svcdb]$ rm -rf $PGDATA

#복원명령어 수행

[postgres@c05692802685 svcdb]$ pgbackrest --stanza=svcdb restore --config=/dbbackup/pgbackrest.conf --log-level-console=info

2025-12-30 01:51:55.399 P00   INFO: restore command begin 2.57.0: --config=/dbbackup/pgbackrest.conf --exec-id=1319-ed377784 --log-level-console=info --log-path=/dbbackup/log --pg1-path=/data/svc01 --proc
ess-max=4 --repo1-path=/dbbackup --spool-path=/dbbackup/spool --stanza=svcdb
2025-12-30 01:51:55.404 P00   INFO: repo1: restore backup set 20251230-014945F, recovery will start at 2025-12-30 01:49:45
2025-12-30 01:51:55.404 P00   WARN: contents of directory link 'pg_wal' will be restored in a directory at the same location
2025-12-30 01:51:58.069 P00   INFO: write updated /data/svc01/postgresql.auto.conf
2025-12-30 01:51:58.084 P00   INFO: restore global/pg_control (performed last to ensure aborted restores cannot be started)
2025-12-30 01:51:58.087 P00   INFO: restore size = 197.9MB, file total = 1286
2025-12-30 01:51:58.088 P00   INFO: restore command end: completed successfully (2691ms)

복구 완료시, 복구를 위한 아래 사항이 자동 적용됨
- 복구모드로 인스턴스 기동하도록 $PGDATA 디렉토리에 recovery.signal 파일 생성
- $PGDATA/postgresql.auto.conf 파일에 restore_command 파라미터 설정

[postgres@c05692802685 svc01]$ cat $PGDATA/postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.
synchronous_standby_names = ''
primary_conninfo = 'user=dbarep password=reppass channel_binding=prefer host=172.17.0.2 port=5432 sslmode=prefer sslnegotiation=postgres sslcompression=0 sslcertmode=allow sslsni=1 ssl_min_protocol_versio
n=TLSv1.2 gssencmode=prefer krbsrvname=postgres gssdelegation=0 target_session_attrs=any load_balance_hosts=disable'

# Recovery settings generated by pgBackRest restore on 2025-12-30 01:51:58
restore_command = 'pgbackrest --config=/dbbackup/pgbackrest.conf --stanza=svcdb archive-get %f "%p"'

# current WAL 파일 적용. 완전 복구 수행을 위한 매우 중요한 작업
[postgres@c05692802685 svc01]$ cd $PGDATA
[postgres@c05692802685 svc01]$ rm -rf pg_wal
[postgres@c05692802685 svc01]$ ln -s /pg_wal/svc01 ./pg_wal

#인스턴스 기동
[postgres@c05692802685 svc01]$ pg_ctl start

인스턴스 기동하면 restore_command파라미터에 지정된 명령어를 이용해서 WAL 파일이 순차적으로 적용된다.
아카이브된 WAL 파일 적용 후 /pg_wal/svc01 디렉토리에 저장된 current WAL 파일이 적용됨

#확인
svcdb=# select count(1) from t1;
  count
---------
1001000
(1 row)

4.2 pgBackRest 를 이용한 완전 복구 ( Delta 옵션)

델타 옵션을 이용한 완전 복구는 $PGDATA 디스크 볼륨 전체가 아닌,
일부 데이터 파일만 손상된 경우 사용하는 방식

1) 인스턴스 종료
2) pgbackrest restore 명령어를 --delta 옵션으로 실행
3) WAL 파일 저장 디렉토리에 대한 심볼릭 링크 생성
4) 인스턴스 시작

svcdb=# select pg_relation_filepath('t1');
pg_relation_filepath
----------------------
base/16395/65551
(1 row)

#위치 삭제
svcdb=# \! rm $PGDATA/base/16395/65551

svcdb=# select count(1) from t1;
ERROR:  could not open file "base/16395/65551": No such file or directory

#인스턴스 종료 후 delta 옵션으로 복원 수행
svcdb=# exit
[postgres@c05692802685 svc01]$ pg_ctl stop

[postgres@c05692802685 svc01]$ pgbackrest --stanza=svcdb restore --delta --config=/dbbackup/pgbackrest.conf --log-level-console=info
2026-01-14 05:46:18.503 P00   INFO: restore command begin 2.57.0: --config=/dbbackup/pgbackrest.conf --delta --exec-id=2982-12f03714 --log-level-console=info --log-path=/dbbackup/log --pg1-path=/data/svc0
1 --process-max=4 --repo1-path=/dbbackup --spool-path=/dbbackup/spool --stanza=svcdb
2026-01-14 05:46:18.520 P00   INFO: repo1: restore backup set 20251230-014945F, recovery will start at 2025-12-30 01:49:45
2026-01-14 05:46:18.520 P00   WARN: contents of directory link 'pg_wal' will be restored in a directory at the same location
2026-01-14 05:46:18.526 P00   INFO: remove invalid files/links/paths from '/data/svc01'
2026-01-14 05:46:19.199 P00   INFO: write updated /data/svc01/postgresql.auto.conf
2026-01-14 05:46:19.231 P00   INFO: restore global/pg_control (performed last to ensure aborted restores cannot be started)
2026-01-14 05:46:19.237 P00   INFO: restore size = 197.9MB, file total = 1286
2026-01-14 05:46:19.237 P00   INFO: restore command end: completed successfully (737ms)

**델타 복원시 --link-map 옵션 사용
WAL 저장 디렉토리에 대한 심볼릭 링크를 자동으로 생성할 수 있으나, 동일 장비에서 완전 복구 수행시에는 사용해서는 안된다.
ex) --link-map=pg_wal=/pg_wal/svc01 옵션 적용시 'remove invalid files /links/paths from /pg_wal/svc01' 메시지와 함께
current WAL 파일이 삭제되는 위험성이 있기 때문이다.

#델타 복원시 수동으로 pg_wal 디렉토리 삭제 후 심볼릭 링크 생성
[postgres@c05692802685 svc01]$ cd $PGDATA
[postgres@c05692802685 svc01]$ rm -rf pg_wal
[postgres@c05692802685 svc01]$ ln -s /pg_wal/svc01 ./pg_wal

#PG 재기동 후 정상 복구 확인
[postgres@c05692802685 svc01]$ pg_ctl start
waiting for server to start....2026-01-14 05:49:34.014 UTC [2991] LOG:  redirecting log output to logging collector process
2026-01-14 05:49:34.014 UTC [2991] HINT:  Future log output will appear in directory "log".
done
server started
[postgres@c05692802685 svc01]$ psql
psql (17.7)
Type "help" for help.

postgres=# \c svcdb
You are now connected to database "svcdb" as user "postgres".

svcdb=# select count(1) from t1;
  count
---------
1001000
(1 row)

4.3 pgBackRest를 이용한 시점 복구 (별도 서버)

시점 복구(Point-In-Time Recovery, PITR) 는 사용자 실수나 애플리케이션 오류 등으로 인해 데이터가 손실되었을 때
특정시점으로 데이터베이스를 되돌리는 기능이다.
시점 복구는 동일서버에서 수행할 수도 있고, 별도의 서버에서 수행할 수도 있다.

ㅇ동일서버 복구 진행시 복원 위치, 포트, 로그 파일 경로, 아카이브 명령어 등 모두 재설정 해야한다.

복구를 위해 일시적으로 동일 서버에 별도 인스턴스를 기동해야하므로 메모리 여유율도 함께 고려해야한다.

-> 이런 제약사항으로 시점 복구는 별도의 서버에서 수행하는 것이 보다 안전하고 편리함

1. 별도서버에서의 시점 복구 절차
1) pg_switch_wal() 함수를 이용해서 current WAL 파일을 아카이브 디렉토리로 복사한다.
2) 백업 파일을 복구용 서버로 전송한다.
3) 복구 시점을 지정하고 pgbackrest restore 명령어 수행하는
4) 인스턴스 시작
5) 복구된 테이블 덤프
6) 덤프 파일을 원본 서버로 전송한 후 복원

#테스트데이터입력
svcdb=# insert into t1 select 'PITR' from generate_series(1,10000);
INSERT 0 10000
svcdb=# select count(1) from t1;
  count
---------
1031001
(1 row)

svcdb=# drop table t1;  --20260116 13:48~
DROP TABLE
2026-01-20 06:40:01.849 UTC [167] LOG:  statement: drop table t1;

#pg_switch_wal 수행
svcdb=# select pg_switch_wal();
pg_switch_wal
---------------
0/48F17328
(1 row)

[root@c05692802685 /]#  tar -czvf dbbackup.tar.gz dbbackup

#복구용 서버로 전송
C:\Users\tttttt>docker cp pgtest02:/dbbackup.tar.gz %USERPROFILE%\Desktop\dbbackup.tar.gz
Successfully copied 53.5MB to C:\Users\tttttt\Desktop\dbbackup.tar.gz

C:\Users\tttttt>docker cp "C:\Users\tttttt\Desktop\dbbackup.tar.gz" pgtest02-2:/dbbackup.tar.gz
Successfully copied 53.5MB to pgtest02-2:/dbbackup.tar.gz

#복구서버에서 압축해제
[root@c05692802685 /]# tar -xvf dbbackup.tar.gz

#복구서버에서 시점 복구

--type옵션은 time으로 설정하고, --target 옵션은 복구 시점을 설정한다.
시점복구는 기본적으로 마스터로 승격되지않기때문에 --target-action 옵션을 promote로 지정한다.

pgbackrest --stanza=svcdb restore --config=/dbbackup/pgbackrest.conf --type=time --target="2026-01-20 06:40:00" --target-action=promote --log-level-console=info
# Recovery settings generated by pgBackRest restore on 2026-01-16 08:03:55
restore_command = 'pgbackrest --config=/dbbackup/pgbackrest.conf --stanza=svcdb archive-get %f "%p"'
recovery_target_time = '2026-01-16 04:48:00'
recovery_target_action = 'promote'

#PGDATA/postgresql.auto.conf 복원 후 파일 확인 -파라미터 자동 설정

#인스턴스 기동
pg_ctl start

4.4 pgBackRest를 이용한 시점 복구 (동일 서버)

1) pg_switch_wal() 함수 수행
2) pgBackRest 환경 파일을 복사한 후, 복원 경로를 변경한다.
3) 복구 시점을 지정하고 pgbackrest restore 명령어 수행하는
4) 복원된 디렉토리의 postgresql.conf 파일에서 일부 파라미터를 수정한다.
5) 새 인스턴스를 시작한다.
6) 복구 완료 후 테이블 덤프 후 원본 환경에 복원

#테스트데이터 입력
svcdb=# insert into t1 select 'PITR2' from generate_series(1,20000);
INSERT 0 20000
svcdb=# select count(1) from t1;
  count
---------
1021000
(1 row)

#테이블 삭제
svcdb=# drop table t1;

#PostgreSQL 로그 에서 삭제 시점 확인 ( drop 문 로그 남도록 설정되어있어야함.)

#pg_switch_wal 수행 - currentWAL 파일 아카이브 디렉토리로 복사 위함
svcdb=# select pg_switch_wal();
pg_switch_wal
---------------
0/413197A8
(1 row)

#시점 복구 위한 환경 설정
[root@c05692802685 /]# mkdir -p /logs/svcdb_pitr
[root@c05692802685 /]# chown -R postgres:postgres /logs/svcdb_pitr
[root@c05692802685 /]# chmod 700 /logs/svcdb_pitr

[postgres@c05692802685 log]$ cd $PGDATA
[postgres@c05692802685 svc01]$ cp /dbbackup/pgbackrest.conf /dbbackup/pgbackrest_pitr.conf
[postgres@c05692802685 dbbackup]$ vi pgbackrest_pitr.conf
[svcdb]
pg1-path=/data/svc01_pitr

#수정 파일 기반으로 시점 복구 수행
[postgres@c05692802685 dbbackup]$ pgbackrest --stanza=svcdb restore --config=/dbbackup/pgbackrest_pitr.conf --type=time --target="2026-01-15 01:29:50" --target-action=promote --log-level-console=info

#복원된 디렉토리 내의 postgresql.conf 파일 수정
[postgres@c05692802685 ~]$ cd /data/svc01_pitr
[postgres@c05692802685 svc01_pitr]$ vi postgresql.conf
log_directory='/logs/svcdb_pitr'
port =54322
archive_command = '/usr/bin/pgbackrest --stanza=svcdb archive-push %p --config=/dbbackup/pgbackrest_pitr.conf'

#복원 디렉토리 -D옵션으로 지정 후 인스턴스 시작
[postgres@c05692802685 ~]$ pg_ctl start -D /data/svc01_pitr

#복구 확인
[postgres@c05692802685 ~]$ psql -p 54322
psql (17.7)
Type "help" for help.

postgres=# \c svcdb
You are now connected to database "svcdb" as user "postgres".
svcdb=# select count(1) from t1;
  count
---------
1021000
(1 row)

# 복구완료 테이블 덤프
[postgres@c05692802685 ~]$ pg_dump -Fc -Z1 -p 54322 -d svcdb -t t1 -f svcdb_table.custom

# 기존 인스턴스에 복원
[postgres@c05692802685 ~]$ pg_restore -v -d svcdb svcdb_table.custom > svcdb_table.log 2>&1
[postgres@c05692802685 ~]$ psql
psql (17.7)
Type "help" for help.

postgres=# \c svcdb
You are now connected to database "svcdb" as user "postgres".
svcdb=# select count(1) from t1;
  count
---------
1021000
(1 row)

svcdb=# insert into t1 select 'a' ;
INSERT 0 1
svcdb=# select count(1) from t1;
  count
---------
1021001
(1 row)

svcdb=# exit;
[postgres@c05692802685 ~]$ psql -p 54322
psql (17.7)
Type "help" for help.

postgres=# \c svcdb
You are now connected to database "svcdb" as user "postgres".
svcdb=# select count(1) from t1;
  count
---------
1021000
(1 row)

#인스턴스 정리
[postgres@c05692802685 svc01_pitr]$ pg_ctl stop -D /data/svc01_pitr
[postgres@c05692802685 /]$ rm -rf /data/svc01_pitr
[root@c05692802685 /]# rm -rf /logs/svcdb_pitr
[postgres@c05692802685 dbbackup]$ rm -rf /dbbackup/pgbackrest_pitr.conf

[PostgreSQL] 논리 백업과 복구

DBnA — Sat, 27 Dec 2025 12:32:35 +0900

논리 백업은 백업 시점의 데이터를 복원하는 용도로 사용되며, 복구보다는 데이터 보관 및 이행 목적으로 활용된다.

물리백업처럼 아카이브 파일을 이용해서 장애 시점까지 복구 할 수 있는 기능이 없다.

Pg_dumpall, pg_dump, COPY 명령어를 제공한다.

1. Pg_dumpall 을 이용한 백업

데이터베이스 클러스터 내의 모든 데이터베이스와 관련 정보를 한꺼번에 백업할 수 있는 기능을 제공한다. 압축 및 병렬 백업 기능을 제공하지 않는 다는 단점이 있음.

주로 논리 복제 구성 시에 데이터베이스 클러스터 내의 모든 형상 정보와 롤(Role) 정보를 백업하는데 사용

데이터베이스 클러스터 생성 스크립트 백업 방법

모든 오브젝트 생성 스크립트만 백업할 경우 -s 옵션을 사용한다.

데이터는 백업하지 않고 오브젝트 생성 스크립트만 백업한다.

[postgres@11039b77a76b pgdump]$ pg_dumpall -s -f db_cluster_251226.sql > db_cluster_251226_dump.log 2>&1

[postgres@11039b77a76b pgdump]$ ls

db_cluster_251226.sql db_cluster_251226_dump.log

데이터베이스 클러스터 형상 복원 방법

전체 형상 복원시에는 psql 명령어 사용

postgres=# drop database svcdb;

DROP DATABASE

postgres=# exit;

[postgres@11039b77a76b pgdump]$ psql -f db_cluster_251226.sql

SET

psql:db_cluster_251226.sql:16: ERROR: role "dbarep" already exists

ALTER ROLE

psql:db_cluster_251226.sql:18: ERROR: role "lglrep" already exists

ALTER ROLE

…

[postgres@11039b77a76b pgdump]$ psql

psql (17.7)

Type "help" for help.

postgres=# \c svcdb

You are now connected to database "svcdb" as user "postgres".

svcdb=#

Role 백업

Pg_dumpall -r -f role.sql

Role 복원

Psql -f role.sql

2. Pg_dump를 이용한 백업

개발환경의 데이터베이스 백업이나, 데이터베이스 및 스키마 단위의 이행 업무에 자주 사용.

압축과 병렬 처리 기능도 제공하므로 대용량 데이터 백업 작업에 유용하게 활용할 수 있다.

'pg_dump --help' 명령어로 옵션 목록 확인 가능.

Format 옵션

P (plain) : 텍스트파일, 압축X, 병렬 백업 X, 부분복구 X => 거의 사용x,

C (custom) : 바이너리파일, 압축O, 병렬 백업 X, 부분 복구O

D (directory) : 바이너리파일, 압축O, 병렬 백업 O, 부분 복구 O

T (tar) : Tar 파일, 압축X, 병렬 백업 X, 부분복구 X

압축 옵션
-Z 옵션을 활용하여 압축 방식 지정.

gzip : 0~9까지 압축 레벨 제공하며, 레벨이 높아질수록 백업 파일 크기는 작아지지만 그만큼 압축 시간이 길어짐.
0 레벨은 압축하지 않는다.
lz4 : 0부터 12까지 압축 레벨 지원. 버전 16부터 사용 가능

사용 시스템 환경과 데이터 특성에 따라 차이가 있으므로 , 적절한 압축 방식을 선택해야함.

병렬 처리 옵션
-j
이 옵션은 directory 포맷(-Fd) 사용할때만 적용 가능하며, 병렬로 데이터를 백업하는 워커 프로세스의 개수를 지정한다.
병렬 프로세스 수는 시스템의 CPU 코어 수나 디스크 I/O 성능 등에 따라 달라 질 수 있다.

ex) pg_dump -Fd -Z1 -j4 -f backup_pg4

그 외의 옵션들
-d : 백업 대상 데이터베이스 지정, pgdatabase 환경 변수로 설정되지 않은 데이터베이스 백업시 사용
-s : 오브젝트 생성 스크립트만 백업하며, 데이터는 포함하지않음
-a : 데이터만 백업
-n : 특정 스키마만 백업, 옵션 반복해서 여러 스키마 지원가능하며 패턴 매칭도 가능하다. -n schema[0-9] / -n sc1 -n sc2
-t : 특정 데이블만 백업. 패턴 매칭 지원
-b : large 오브젝트는 pg_largeobject 시스템 테이블에 저장되기 때문에, large object 포함한 테이블을 백업할 때는 -b 옵션을 함께 사용해야함.

3. psql과 pg_restore 를 이용한 복원

- 스키마 형상을 타 데이터베이스에 적용하는 방법
* 현 시점의 스키마 형상을 다른 데이터베이스에 반영
> 개발 데이터베이스에서 pg_dump를 이용해 스키마 형상 백업
> 이행 대상 데이터베이스에서 기존 스키마르 삭제
> 백업한 스키마 스크립트를 psql을 이용해서 적용한다.

pg_dump -Fp -n svc -d svcdb -s -f svc_schema.sql

psql -d svcdb_mig
drop schema svc cascade;

psql -d svcdb_mig -f svc_schema.sql

- 스키마 형상 및 데이터를 타 DB에 적용하는 방법
pg_dump -Fc -Z1 -n svc -d svcdb -f svc_schema_data.custom

psql -d svcdb_mig
drop schema svc cascade;

pg_restore -d svcdb_mig -v -j4 svc_schema_data.custom

4. pg_restore를 이용한 복구

- 특정 테이블 복구 방법
[postgres@11039b77a76b pgdump]$ pg_dump -Fc -Z1 -f svcdb_full_20251226.custom svcdb

[postgres@11039b77a76b pgdump]$ pg_restore -d svcdb -v -n svc -t t1 -a svcdb_full_20251226.custom
pg_restore: connecting to database for restore
pg_restore: processing data for table "svc.t1"

* 테이블 복수 시 -c 옵션 주의사항
-c 사용시 기존 존재하는 테이블 drop 후 다시 생성한다.
테이블 단위로 -c 옵션 사용하면 기존에 설정되더 있던 PK, 인덱스, 제약조건, 논리복제설정은 복원되지 않으므로 주의필요

스키마나 DB 단위 복원시에는 -c 옵션사용해도 pk, 인덱스, 제약조건 및 논리 복제 설정 내용을 포함한 모든 내용이 복원된다.

출처 : PostgreSQL DBA를 위한 Admin 이야기

Cloudy Bay Sauvignon Blanc / 클라우디 베이

DBnA — Fri, 26 Dec 2025 10:58:12 +0900

오마카세 방문할때 들고간 콜키지용 클라우디베이 쇼비뇽블랑

돌고래보틀 양재점에서 할인가 42,000원에 구매.

가격이 너무 괜찮아서 구매해봤다.

오.. 클라우디베이는 처음인데 맛 좋다

역시 대중적인건 이유가 있다.

바비치 쇼블이나 오이스터베이 등 2~3만원대 쇼블 다 나름 괜찮게 먹었었는데

클라우디베이 쇼블이 좀 더 산도도 낮은 것 같아 먹기 편하고 부드럽다

가격따라가는게 맞나..?

비비노 4.2

재구매의사 있음 !!

chateau la ribaud 2018 medoc cre bourgeios 샤또 라 리보 메독 크뤼 브르주아

DBnA — Fri, 26 Dec 2025 10:49:15 +0900

chateau la ribaud medoc cru 2018 샤또 라 리보 메독 크뤼 브르주아

이마트에서 행사하길래 구매해본 프랑스 메독 와인

세일해서 23,880원에 구매

비비노 3.8로 나쁘지않은 평점대다.

메독 특유의 탄탄한 구조감과 균형 잡힌 타닌
잘 익은 블랙커런트와 체리
은은한 바닐라와 스파이스
오크 숙성으로 완성된 깊이 있는 풍미와 긴 여운

당도는 낮고 바디감은 묵직한편

이라고 이마트에서 소개하고있는데..
전반적으로 괜찮기는 하나 개인적으로는 조금 가볍게 느껴졌다.
내 취향은 아닌걸로 !

재구매 의사 X

2026 ADsP / ADP 데이터 분석 준 전문가 자격시험일정

DBnA — Wed, 24 Dec 2025 15:26:34 +0900

안녕하세요.

2026년 ADsP / ADP 데이터분석 준전문가 / 전문가 자격 시험 일정이 공개되어 공유드립니다.

ADP 는 2회 시행되며, 실기시험의 경우 서울,대전,부산 에서만 시행되네요.

ADsP는 총 4회시행됩니다.

시험일정 잘챙기셔서 원하는 결과 얻길 바랍니다.

시험 시간은 위와 같고 퇴실은 입실 기준 한시간뒤에 가능하네요.

[PostgreSQL] 논리복제(3) - Publication 대상 테이블 추가, 삭제, 재설정

DBnA — Wed, 24 Dec 2025 12:27:19 +0900

Publication 을 테이블 레벨로 생성한 경우, 복제 대상 테이블을 추가, 삭제 또는 재설정할 수 있다.

ALTER PUBLICATION 명령어를 이용한다.

작업	명령어
테이블 추가	Alter publication <Publication명> add table <테이블 목록>;
테이블 삭제	Alter publication <Publication명> drop table <테이블 목록>;
테이블 재설정	Alter publication <Publication명> set table <테이블 목록>;

테이블 추가

1. 테이블 생성

--발행 서버에 테이블 생성 및 초기 데이터 추가

svcdb=# Set role svc;

SET

svcdb=> Create table svc.t3(c1 integer, c2 integer, constraint t3_pk primary key(c1));

CREATE TABLE ^

svcdb=> Insert into svc.t3 select i,i from generate_series(1,1) I;

INSERT 0 1

--구독 서버에 동일 테이블 추가

svcdb=# Set role svc;

SET

svcdb=> Create table svc.t3(c1 integer, c2 integer, constraint t3_pk primary key(c1));

CREATE TABLE

2. Publication 에 svc.t3 테이블 추가

svcdb=# set role postgres;

SET

svcdb=# alter publication pub_svc_tbl add table svc.t3;

ALTER PUBLICATION

svcdb=# select * from pg_publication_tables;

pubname | schemaname | tablename | attnames | rowfilter

-------------+------------+-----------+----------+-----------

pub_svc_tbl | svc | t1 | {c1,c2} |

pub_svc_tbl | svc | t2 | {c1,c2} |

pub_svc_tbl | svc | t3 | {c1,c2} |

(3 rows)

3.구독 서버에 REFRESH PUBLICATION으로 테이블 반영

svcdb=# alter subscription sub_svc_tbl refresh publication;

ALTER SUBSCRIPTION

svcdb=# select count(1) from svc.t3;

count

-------

(1 row)

테이블 삭제

Svc.t1 테이블을 publication 에서 삭제하려면 DROP TABLE 옵션 사용한다.

해당 테이블은 발행 목록에서 삭제되는 즉시 논리 복제가 중단된다.

발행서버	구독서버
svcdb=# select * from pg_publication_tables; pubname \| schemaname \| tablename \| attnames \| rowfilter -------------+------------+-----------+----------+----------- pub_svc_tbl \| svc \| t1 \| {c1,c2} \| pub_svc_tbl \| svc \| t2 \| {c1,c2} \| pub_svc_tbl \| svc \| t3 \| {c1,c2} \| (3 rows)
	svcdb=# select count(1) from svc.t1; count ------- 12 (1 row)
svcdb=# alter publication pub_svc_tbl drop table svc.t1; ALTER PUBLICATION
svcdb=# select * from pg_publication_tables; pubname \| schemaname \| tablename \| attnames \| rowfilter -------------+------------+-----------+----------+----------- pub_svc_tbl \| svc \| t2 \| {c1,c2} \| pub_svc_tbl \| svc \| t3 \| {c1,c2} \| (2 rows)
svcdb=# delete from svc.t1 where c1 in (11,12); DELETE 2 svcdb=# select count(1) from svc.t1 ; count ------- 10 (1 row)
	svcdb=# select count(1) from svc.t1; count ------- 12 (1 row)

테이블 재설정

복제 대상 테이블을 대폭 변경해야 할 경우, SET TABLE 옵션으로 전체 발행 목록을 재설정할 수 있다.
ex) svc.t1 테이블 다시 추가하고 svc.t3 테이블 제거

발행서버	구독서버
svcdb=# alter publication pub_svc_tbl set table svc.t1,svc.t2; ALTER PUBLICATION
	svcdb=# alter subscription sub_svc_tbl refresh publication with (copy_data=false); ALTER SUBSCRIPTION
svcdb=# insert into svc.t1 select 11,11; INSERT 0 1
	svcdb=# select * from svc.t1 where c1 = 11; c1 \| c2 ----+---- 11 \| 11 (1 row)

svc.t1의 경우 기존에 복제 수행이력이 있어서 copy_data=true로 초기 복제 수행하면 PK중복오류가 발생할 수 있다.
방지를 위해 copy_data = false 옵션을 이용해서 초기데이터 복제하지 않고 REFRESH를 수행한다.

PK오류는 발생하지 않지만, 그동안 svc.t1에 입력된 데이터 복제되지않아 데이터 누락 발상.

이런 경우, 구독 서버의 테이블 TRUNCATE 한 뒤, copy_data=true 옵션으로 REFRESH를 수행한다.

Subscription 생성 옵션 및 설정 변경

출처 : PostgreSQL DBA를 위한 Admin 이야기

create subscription <Subscription명> connection '<접속정보>' publication <Publication명> with ( streaming=false, copy_date=false);

물리복제는 트랜잭션 변경 내용을 리플리카 서버로 실시간 스트리밍 방식으로 전송,

논리복제는 트랜잭션 종료된 이후에 논리 디코딩 과정을 거쳐 데이터 구독 서버로 전달 !

이러한 구조로 인해 대량 트랜잭션이 발생하는 환경에서 synchronous_commit = off 권장됨.

streaming 옵션도 on이나 parallel로 사용시, '트랜잭션 진행 중에' 논리 디코딩 수행 후 결과를 구독서버를 전달해야

트랜잭션이 완료되므로 트랜잭션 성능 저하에 영향을 미친다. (복제 지연시간은 줄어들 수 있음)
일반 운영환경에서는 트랜잭션 성능이 더 중요하다고 파악하므로 기본값은 off 사용 권장.

Subcription 주요 작업

1. subscription 중단

alter subscription <Subscription명> disable;

*중단 시 유의사항

중단 시점에 복제 지연이 발생하고 있으면, 복제 지연 중인 레코드는 구독서버에 반영되지않음.

svcdb=# select sent_lsn, write_lsn, flush_lsn, replay_lsn, write_lag, flush_lag, replay_lag from pg_stat_replication;
  sent_lsn  | write_lsn  | flush_lsn  | replay_lsn | write_lag | flush_lag | replay_lag
------------+------------+------------+------------+-----------+-----------+------------
 0/2F039158 | 0/2F039158 | 0/2F039158 | 0/2F039158 |           |           |

위 모든 lsn 값이 동일하고 lag 컬럼이 null인 경우, 변경 내용 구독서버로 전송 및 적용 완료 상태.

lsn동일, lag 존재시, 전송 완료됐으나 반영 진행 중 의미.

-> 반영까지 되고나서 중단하는 것이 바람직하다.

2. subscription 재개

alter subscription <Subscription명 > able;

3. 에러 skip

alter subscription <Subscription명> skip (lsn='<LSN>');

주로 pk중복오류 발생시, 오류 발생한 위치(LSN) 건너뛰면 된다.

해결 전까지 apply worker 프로세스가 반복적으로 종료 및 재시작되며 복제가 지연된다.

출처 : PostgreSQL DBA를 위한 Admin 이야기

[RDS for ORACLE] RMAN(Recovery Manager) 로 데이터베이스 백업

DBnA — Tue, 23 Dec 2025 13:41:32 +0900

Amazon RDS ORACLE DB 인스턴스에서 Oracle RMAN(Recovery Manager) DBA 작업을 수행하는 방식을 알아보며
rdsadmin.rdsadmin_rman_util 패키지 사용하여 오라클 데이터베이스 백업을 진행 테스트를 진행

0. 테스트데이터 생성

CREATE TABLE xtmp_test (
    id          NUMBER PRIMARY KEY,
    name        VARCHAR2(100),
    created_at  DATE DEFAULT SYSDATE
);

BEGIN
  FOR i IN 1..100 LOOP
    INSERT INTO xtmp_test (id, name)
    VALUES (i, 'User_' || i);
  END LOOP;
  COMMIT;
END;
/

1. RMAN 백업 사전 요구 사항 확인

--마스터계정에서
GRANT SELECT ANY DICTIONARY TO testdb;

--archivelog 모드 확인
SELECT log_mode FROM v$database;

--redo log 보존 기간 확인 (0이상)
SELECT name, value
FROM v$parameter
WHERE name LIKE '%retention%';

--redo log 보존 기간 설정 (--admin계정에서 실행)

begin
    rdsadmin.rdsadmin_util.set_configuration(
        name  => 'archivelog retention hours',
        value => '24');
end;
/
commit;

2. 데이터베이스 검증
BEGIN
rdsadmin.rdsadmin_rman_util.validate_database;
END;

--충분한 저장공간 확보
--freestoragespace로 요유공간 모니터링

--전체 백업 수행
BEGIN
    rdsadmin.rdsadmin_rman_util.backup_database_full(
        p_owner               => 'SYS',
        p_directory_name      => 'DATA_PUMP_DIR',
        p_section_size_mb     => 1024,
        p_tag                 => 'FULL_DB_BACKUP',
        p_rman_to_dbms_output => FALSE);
END;

--증분 백업 수행
BEGIN
    rdsadmin.rdsadmin_rman_util.backup_database_incremental(
        p_owner               => 'SYS',
        p_directory_name      => 'DATA_PUMP_DIR',
        p_level               => 1,
        p_section_size_mb     => 1024,
        p_tag                 => 'MY_INCREMENTAL_BACKUP',
        p_rman_to_dbms_output => FALSE);
END;

--파일확인
SELECT filename,type,filesize/1024/1024 size_megs,to_char(mtime,'DD-MON-YY HH24:MI:SS') timestamp
FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => upper('DATA_PUMP_DIR'))) order by 4;

--파일 삭제
BEGIN
  FOR rec IN (
    SELECT filename
    FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => upper('DATA_PUMP_DIR')))
    WHERE TYPE='file'  -- 필요한 경우 필터 조건
  ) LOOP
    BEGIN
      UTL_FILE.FREMOVE('DATA_PUMP_DIR', rec.filename);
      DBMS_OUTPUT.PUT_LINE('Deleted: ' || rec.filename);
    EXCEPTION
      WHEN OTHERS THEN
        DBMS_OUTPUT.PUT_LINE('Failed to delete: ' || rec.filename || ' - ' || SQLERRM);
    END;
  END LOOP;
END;

참고 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.RetainRedoLogs.html

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.RMAN-requirements.html

2026 DAsP / DAP 시험일정 공유

DBnA — Sun, 21 Dec 2025 12:17:23 +0900

안녕하세요.

2026년도 DAsP 와 DAP 시험일정이 공개되어 공유드립니다.

2026년도 DAsP와 DAP 는 모두 2회차만 진행되네요.

DAsP의 시험 회수도 줄어들어 필요하신분들은 미리 준비하면 좋을 것 같습니다.

아래는 검정시간입니다.