스키마 레벨 및 테이블 레벨 백업 및 복원
Db2 논리 스키마 백업 및 복원 기능을 사용하여 스키마의 전체, 누적 증분 또는 델타 증분 백업을 수행한 후 스키마 또는 스키마 내 하나 이상의 테이블을 전체 복원할 수 있습니다.
LOGICAL BACKUP 및 LOGICAL RESTORE 스토어드 프로시저는 테이블 레벨 데이터를 백업 및 복원하는 유연하고 가벼운 방법을 제공합니다. LOGICAL BACKUP 스토어드 프로시저가 데이터베이스 레벨 오브젝트를 캡처하지 않는 동안 다음 스키마 백업 옵션을 지원합니다.
- 전체
- 선택한 데이터베이스 스키마 및 스키마 내의 모든 테이블 데이터의 사본을 작성합니다.
- 누적 증분
- 최근에 성공한 전체 백업 조작 이후 선택된 스키마에서 변경된 모든 데이터베이스 데이터의 사본을 작성합니다.
- 델타 증분
- 최근에 성공한 모든 유형의 백업 조작 이후에 선택된 스키마에서 변경된 모든 데이터베이스 데이터의 사본을 작성합니다.
전체 및 증분 스키마 레벨 백업은 스키마의 테이블에 대한 읽기 및 동시 삽입, 갱신 및 삭제 액세스를 제공합니다.
컬럼으로 구성된 테이블에 대한 행 수정 추적
분석 워크로드에 사용되는 컬럼으로 구성된 스키마를 백업하는 경우 대상 스키마에서 행 수정 추적을 사용 해야 합니다. ENABLE ROW MODIFICATION TRACKING절을 스키마 작성 조작의 일부로 포함하여 컬럼으로 구성된 대상 스키마에서 행 수정 추적을 사용으로 설정합니다. 또한 ALTER SCHEMA 문에 절을 추가하여 기존 스키마를 수정할 수도 있습니다. 이를 완료하면 대상 스키마 내에 작성된 테이블이 행 수정 추적이 사용 가능한 상태로 작성됩니다. 이 설정을 사용하면 논리 스키마 백업 기능이 컬럼으로 구성된 테이블에서 테이블 데이터를 캡처할 수 있습니다.
행 수정 추적은 기본적으로 사용되지 않습니다. 증분 스키마 백업 및 리스토어를 이용하려면 ENABLE ROW MODIFICATION TRACKING절을 사용하여 명시적 스키마를 작성해야 합니다.
행 수정 추적이 사용되는 스키마의 Db2 오브젝트에 대한 제한사항
- db2load 및 INGEST 조작에 대한 예외 테이블 은 컬럼으로 구성될 수 없습니다. 대신, 별도의 스키마에서 행으로 구성된 예외 테이블을 작성하십시오. 이 테이블로 인해 증분 스키마 백업이 실패합니다. 또한 행으로 구성된 예외 테이블에는 행 수정 추적에 대해 구성된 컬럼으로 구성된 테이블과 유사한 정의가 있어야 합니다. 예외는 SYSROWID열입니다. 이 열은 예외 테이블에서 지원되지 않으므로 ID열이 될 수 없습니다. 예를 들어,
- 스키마 S1 작성 행 수정 추적 사용
- 스키마 작성 S2
- CREATE TABLE S1.T1 (C1 INT)
- 테이블 S2.LOADEXTBL (SYSROWID BIGINT NOT NULL, CREATEXID BIGINT NOT NULL, DELETEXID BIGINT NOT NULL, C1 INT)
- 로드 소스
S1.T1 예외 S2.LOADEXTBL
- 행 수정 추적에 사용 가능한 테이블의 최대 사용자 정의 열 수가 1009로 감소됩니다.
- 행 수정 추적에 사용 가능한 테이블에 CREATE 또는 REPLACE_CREATE 옵션을 사용하는 IMPORT가 실패할 수 있습니다.
- 최소한 하나의 테이블이 DISTRIBUTE BY RANDOM으로 정의되거나 GENERATED ALWAYS AS IDENTITY 컬럼을 포함하는 경우 'COPY' 또는 'COPYNO' 의 copymode 를 갖는 ADMIN_COPY_SCHEMA가 실패합니다.
- 구체화된 쿼리 테이블이 되도록 행 수정 추적에 사용 가능한 테이블의 변경을 지원하지 않습니다.
- 세 개의 새로운 숨겨진 컬럼 (SYSROWID, CREATEXID, DELETEXID) 중 어느 것도 테이블의 분산 키 내에서 지원되지 않습니다. (이는 DISTRIBUTE BY HASH 컬럼 목록에서 허용되지 않음을 의미합니다.)
- 소스 또는 대상이 행 수정 추적에 사용 가능한 스키마의 테이블인 경우 db2move 에 대한 지원이 없습니다.
- 세 개의 새로운 숨겨진 컬럼 중 어느 것도 인덱스 키의 일부로 또는 강제 실행된 제한조건에 포함될 수 없습니다.
- 행 수정 추적이 사용 가능한 시스템 기간 시간 테이블 또는 양측 시간 기간 테이블에 대한 지원은 없지만 애플리케이션 기간 시간 테이블은 행 수정 추적을 지원합니다.
- CREATE VIEW에 대한 지원 없음 ... 행 수정 추적이 사용 가능한 WITH ROW MOVEMENT입))니다니다니다.
- REORG 테이블 ... RECLAIM EXTENTS는 삭제된 SYSROWID/CREATEXID/DELETEXID 컬럼에서 공간을 재확보합니다. 마지막 -type ONL (전체 스키마) 백업 이전에 삭제된 행에 대해서만 스페이스가 재확보됩니다.
실패한 백업 및 복원 조작 처리
논리 스키마 백업 또는 복원 조작이 실패하면 오류에 대한 정보의 첫 번째 소스는 sqlca 메시지입니다. 예를 들어, 다음 오류 메시지는 백업할 스키마에 행 수정 추적에 사용할 수 없는 테이블이 포함되어 있음을 표시합니다.
SQL1797N The "SYSPROC.LOGICAL_BACKUP" utility has failed with error "non-RMT
table "T3".". SQLSTATE=5UA0Q
메시지가 명확하지 않거나 잘리지 않는 경우 다음 정보 지점은 추적 로그 파일입니다. 기본적으로 -errorlogdir 옵션 또는 sqllib/tmp/bnr/logs 로 제공되는 경로가 접두부로 붙은 경로에 저장됩니다. 경로에는 실패한 조작이 실행되었을 때의 대략적인 시간소인에 대해 이름 지정된 서브폴더가 추가됩니다. 예: /home/db2inst1/sqllib/tmp/bnr/logs/20221110202644
이 시간소인을 백업 이미지에 사용되는 시간소인과 혼동하지 마십시오.
클라우드 클라이언트는 서버의 파일에 액세스할 수 없으므로 이 매개변수를 설정하지 않아야 합니다.
폴더에는 다음 유형의 로그 파일이 포함될 수 있습니다.
- 외부 테이블 로그 파일.
- 커넥터 로그 파일 (외부 매체와의 통신: IBM Spectrum Protect, AWS S3또는 IBM COS).
- 백업 또는 복원 추적 로그 파일입니다.
- 백업 또는 복원 로그 파일. 이 파일은 추적 로그 파일의 간결한 버전입니다.
마이그레이션 고려사항
스키마에서 행 수정 추적을 사용하도록 설정해도 스키마의 테이블은 수정되지 않습니다. 스키마에서 작성된 새 테이블만 행 수정 추적에 사용됩니다. 논리 스키마 백업을 성공적으로 복원하려면 스키마가 행 수정 추적에 사용된 후에 대상 스키마의 모든 종횡배열 (columnar) 테이블을 다시 작성해야 합니다.
테이블 이주
테이블 재작성은 어떤 방법으로든 수행할 수 있습니다. 예를 들어, ADMIN_MOVE_TABLE 또는 CREATE TABLE ... 을 실행하여 대상 스키마에서 테이블을 다시 작성할 수 있습니다. AS (R)... WITH DATA문. 한 테이블에서 동일한 스키마의 새 테이블로 * 를 선택하기만 하면 됩니다. 다음 조건이 존재하는 한 대상 테이블은 행 수정 추적에 사용 가능한 것으로 작성됩니다. -행 수정 추적에 대해 대상 스키마가 사용으로 설정되어 있습니다. -대상 테이블 유형은 행 수정 추적을 지원합니다.
소스 테이블에서 행 수정 추적을 사용할 필요가 없습니다. 또한 숨겨진 컬럼이 행 수정 추적 사용 가능 대상 테이블에 이미 존재하므로 소스 테이블에서 대상 테이블로 숨겨진 컬럼을 이동하려고 하면 오류가 발생합니다. CREATE TABLE ... 중에는 숨겨진 새 컬럼의 값이 소스에서 대상으로 전달되지 않습니다. AS (fullselect) WITH DATA 조작.
논리 백업 및 복원을 사용하는 테이블 데이터 마이그레이션
이주를 지원하려면 SYSPROC.LOGICAL_BACKUP 은 -backup - migrate 옵션을 지정하여 행 수정 추적에 사용할 수 없는 스키마의 논리 백업 이미지를 작성할 수 있습니다. 이 백업의 전체 기간 동안 스키마의 테이블에 대한 읽기 액세스만 허용됩니다. 백업이 완료되면 SYSPROC.LOGICAL_RESTORE(- enable-row-modification-tracking) 옵션. 이 경우 스키마는 ENABLE ROW MODIFICATION TRACKING으로 작성되고 스키마의 모든 테이블도 사용으로 설정하려고 시도합니다. 행 수정 추적에 대해 테이블이 사용 가능하지 않도록 하는 원래 스키마의 모든 테이블 DDL/조건으로 인해 백업이 실패합니다.
스토어드 프로시저를 사용하여 Db2 테이블 레벨 데이터를 캡처하고 복원할 때 논리 스키마 백업 및 복원 조작의 진행 상태를 모니터할 수 있습니다.
스키마가 작성될 때 스키마에서 행 수정 추적을 활성화하거나 ALTER SCHEMA 명령을 사용하여 컬럼으로 구성된 스키마에서 논리 백업을 사용할 수 있습니다. 행으로 구성된 스키마 백업 조작에 적용되지 않는 이 구성에는 몇 가지 제한사항이 있습니다.