Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

변환 작업공간

변환 작업공간은 소스 데이터베이스의 스키마 및 객체를 대상 데이터베이스와 호환되는 SQL 문법으로 변환하는 데 도움이 됩니다. 이 페이지에서는 Database Migration Service 변환 작업공간을 간략하게 설명합니다.

소스 스키마 초기화 옵션에서는 데이터베이스에 직접 연결하거나 스키마 파일을 Cloud Storage에 업로드하여 작업공간을 채우는 방법을 설명합니다.
변환 개요는 스키마 변환 진행 상황의 단면을 제공합니다.
결정론적 코드 및 스키마 변환에서 지원하는 객체에는 결정론적 스키마 변환에 지원되는 Oracle 객체가 나열되어 있습니다.
대화형 SQL 편집기는 변환 작업공간 편집기에서 직접 수정할 수 있는 객체를 설명합니다.
Gemini 기반 변환 기능에서는 생성형 AI 지원을 통합하여 스키마 변환 프로세스를 가속화하는 방법을 살펴봅니다.
변환 매핑 파일 섹션에서는 결정론적 스키마 변환 규칙을 재정의하는 데 사용할 수 있는 맞춤설정 지시문에 대한 개요를 제공합니다.
기존 변환 작업공간은 대화형 SQL 편집기를 지원하지 않는 기존 작업공간을 설명합니다.

Oracle 마이그레이션에서 지원되지 않는 특정 데이터 유형이 있습니다. 자세한 내용은 데이터 유형의 알려진 제한사항을 참조하세요.

소스 스키마 초기화 옵션

데이터베이스 스키마를 변환하려면 Database Migration Service에 소스 데이터베이스 객체의 초기 스냅샷이 필요합니다. 이 스냅샷은 다음 두 가지 방법으로 제공할 수 있습니다.

직접 데이터베이스 연결: Database Migration Service는 연결 프로필을 통해 실행 중인 소스 데이터베이스에 직접 연결하고 네트워크 연결을 통해 스키마를 검색합니다.
Cloud Storage의 스키마 파일: Google에서 제공하는 추출 스크립트를 사용하여 스키마 메타데이터를 로컬에서 추출하고, 결과 파일을 Cloud Storage 버킷에 업로드하고, 소스 데이터베이스에 연결하지 않고 작업공간을 준비할 수 있습니다.

직접 데이터베이스 연결 또는 Cloud Storage의 스키마 파일을 사용하여 변환 작업공간을 만드는 방법을 알아보려면 변환 작업공간 만들기를 참조하세요.

전환 진행 상황 개요

변환 작업공간의 강력한 개요 정보: 미해결 또는 해결된 변환 문제의 총 수, Gemini 지원 증강, 변환 프로세스의 전반적인 상태에 대한 유용한 정보를 얻을 수 있습니다.

변환된 객체 수, 변환 문제, Gemini 지원 변환 개선사항을 확인할 수 있는 변환 개요 탭이 있는 변환 작업공간 화면 — **그림 1.** 변환 진행 상황을 모니터링하고, 문제를 확인하고, 결과 PostgreSQL 코드를 검사할 수 있는 변환 작업공간 개요 화면 (확대하려면 클릭)

이 뷰를 사용하여 스키마의 객체를 유형, 문제 심각도, 조치 필요 또는 변환 상태별로 필터링할 수 있습니다.

변환된 객체를 유형 또는 상태별로 필터링하는 방법을 보여주는 변환 작업공간 화면 — **그림 2.** 상태 및 객체 유형별로 필터링된 변환된 객체 (확대하려면 클릭)

변환 개요를 사용하여 변환 결과를 검사하는 방법에 대한 자세한 내용은 변환 작업공간 작업을 참조하세요.

결정론적 코드 및 스키마 변환

변환 작업공간을 만들면 Database Migration Service는 특정 Oracle 데이터 유형 및 객체가 특정 PostgreSQL 데이터 유형 및 객체에 매핑되는 결정론적 변환 규칙 집합을 사용하여 초기 스키마 변환을 즉시 수행합니다. 이 프로세스는 사용 가능한 Oracle 데이터베이스 객체의 매우 구체적인 하위 집합을 지원합니다.

결정론적 코드 변환은 다음 Oracle 데이터베이스 객체를 지원합니다.

지원되는 Oracle 스키마 요소

제약조건
색인 (테이블과 동일한 스키마에서 생성된 색인만 해당)
구체화된 뷰
객체 유형 (부분 지원)
시퀀스
동의어
테이블
조회수

지원되는 Oracle 코드 요소

트리거 (테이블 수준만 해당)
패키지
함수
저장 프로시저

대화형 SQL 편집기

대화형 SQL 편집기를 사용하면 Database Migration Service에서 직접 변환된 PostgreSQL 문법을 수정할 수 있습니다. 이를 사용하여 변환 문제를 해결하거나 필요에 맞게 스키마를 조정할 수 있습니다. 일부 객체는 기본 제공 편집기에서 수정할 수 없습니다.

수정 가능한 Oracle 객체

소스 데이터베이스 코드와 스키마를 변환한 후 대화형 편집기를 사용하여 특정 유형의 객체에 대해 생성된 SQL을 수정할 수 있습니다. 편집기에서 지원하는 Oracle 객체는 다음과 같습니다.

테이블 트리거 (권한 필요)
구체화된 뷰
패키지
함수, 저장 프로시저
동의어
조회수
제약조건
색인
시퀀스

또한 일부 객체는 변환되지만 Database Migration Service 내에서 직접 수정할 수 없습니다. 이러한 객체를 수정하려면 변환된 스키마와 코드를 적용한 후 대상 데이터베이스에서 직접 업데이트를 수행해야 합니다.

수정이 지원되지 않는 객체:

사용자 정의 객체 유형
테이블
스키마

Gemini로 코드 및 스키마 변환 가속화

Database Migration Service는 Google Cloud 를 위한 Gemini를 변환 작업공간에 통합하여 다음 영역에서 변환 프로세스를 가속화하고 개선할 수 있도록 지원합니다.

Gemini 기반 자동 변환을 통해 결정론적 변환 결과를 개선하여 AI의 힘을 활용하고 PostgreSQL 코드에 필요한 수동 조정 횟수를 크게 줄입니다.
Gemini 기반 품질 평가를 통해 변환된 코드의 품질과 기능적 동등성을 보장합니다. 이러한 평가는 변환된 코드를 분석하여 소스 코드와 비교한 정확성과 기능에 대한 피드백을 제공합니다.
변환 지원이 포함된 코드 설명 가능성 기능을 제공합니다. 변환 로직을 더 잘 이해하거나 변환 문제 해결을 제안하거나 변환된 코드를 최적화하는 데 도움이 되는 일련의 전용 프롬프트입니다.
Gemini 코드 변환 추천을 사용하여 변환 문제 해결을 신속하게 적용합니다. 변환 문제를 해결하고 작업공간의 다른 결함 있는 객체에 대한 변경사항을 제안하면서 Gemini 모델을 학습시킬 수 있는 메커니즘입니다.

Gemini 기반 변환에 대한 자세한 내용은 다음 페이지를 참조하세요.

전환 매핑 파일

변환 매핑 파일을 사용하여 변환 로직을 맞춤설정할 수 있습니다. 변환 매핑 파일은 Oracle 객체를 PostgreSQL 객체로 변환하는 방법에 대한 정확한 안내(변환 지시문이라고 함)가 포함된 텍스트 파일입니다.

지원되는 변환 지시문

Database Migration Service는 변환 매핑 파일에 대해 다음 변환 지시어를 지원합니다.

`EXPORT_SCHEMA`

EXPORT_SCHEMA은 모든 변환 매핑 파일에 필수 지시문입니다. Database Migration Service는 소스 스키마가 올바른 대상 스키마로 변환되도록 이 안내를 필요로 합니다. 전환 매핑 파일에 다음 줄이 포함되어 있는지 확인합니다.

EXPORT_SCHEMA 1

`SCHEMA`

Database Migration Service는 변환 지시어로 수정해야 하는 객체가 포함된 스키마를 확인할 수 있어야 합니다. SCHEMA 지시문은 파일에 제공된 다른 모든 맞춤설정 지시문을 이 특정 스키마의 객체에 적용합니다.

이 지시어를 사용하면 데이터베이스에 포함된 다른 스키마도 변환되지만 객체는 수정되지 않습니다.
변환 매핑 파일에 이 지시어를 포함하면 모든 맞춤설정이 이 특정 스키마에 포함된 객체에만 적용됩니다.
이 지시어를 건너뛰는 경우 다른 변환 지시어로 수정된 객체의 스키마 이름을 포함하는 정규화된 객체 이름을 제공해야 합니다. 예를 들어 REPLACE_TABLES 지시문에 SOURCE_TABLE_NAME를 사용하는 대신 "SCHEMA_NAME.SOURCE_TABLE_NAME"를 사용해야 합니다.
다른 스키마의 객체를 맞춤설정하려면 다음을 시도해 보세요.
- 다른 스키마에 대해 별도의 변환 매핑 파일을 만들고 변환 작업공간에 업로드합니다.
- SCHEMA 지시문에 제공하는 스키마와 다른 스키마에 있는 객체의 경우 스키마 이름을 포함하는 정규화된 객체 이름을 사용합니다.

다음 형식을 사용합니다.

SCHEMA SCHEMA_NAME

여기서 SCHEMA_NAME은 소스 데이터베이스의 스키마 이름입니다.

`CASE_HANDLING`

기본적으로 Database Migration Service는 모든 객체 이름을 소문자로 변환합니다. CASE_HANDLING 지시어를 사용하여 이 동작을 수정할 수 있습니다.

이 지시문은 SCHEMA 지시문의 영향을 받지 않습니다. 전역적으로 작동하며 변환 작업공간의 모든 객체에 영향을 미칩니다.
RENAME_*, MOVE_*, REPLACE_* 지시문은 CASE_HANDLING 지시문보다 우선 적용되며 CASE_HANDLING 속성과 관계없이 객체의 이름을 정확하게 바꿉니다.
이 지시어가 충돌하는 값이 있는 여러 구성 파일에 있으면 Database Migration Service에서 스키마 가져오기 중에 오류가 발생합니다.

다음 형식을 사용합니다.

CASE_HANDLING OPTION

여기서 OPTION는 다음 중 하나일 수 있습니다.

UPPERCASE: 모든 객체 이름을 대문자로 변환합니다.
LOWERCASE: 모든 객체 이름을 소문자로 변환합니다 (기본 동작).
PRESERVE_ORIGINAL: 소스 스키마의 원래 대소문자를 유지합니다. 이는 애플리케이션에서 대소문자를 구분하는 식별자를 사용하는 경우에 유용합니다.

예시:

CASE_HANDLING PRESERVE_ORIGINAL

`GENERATE_MISSING_PK`

기본 키가 없는 테이블은 일관된 복제를 보장하지 않습니다. Database Migration Service는 기본 키가 있는 테이블만 마이그레이션합니다. 기본적으로 Database Migration Service 변환 작업공간은 소스 코드 및 스키마를 변환할 때 대상 테이블에서 누락된 기본 키를 자동으로 만듭니다.

GENERATE_MISSING_PK 지시어를 사용하여 기본 키 자동 생성을 제어할 수 있습니다. 자동 키 생성을 사용 중지하려면 이 지시어를 0로 설정합니다.

예시:

GENERATE_MISSING_PK 0

이 지시문은 특정 변환 작업공간의 모든 객체에 영향을 미칩니다. 특정 테이블에 대해서만 기본 키 자동 생성을 사용 중지할 수는 없습니다.

Database Migration Service는 변환된 PostgreSQL 버전에 기본 키 제약 조건이 있는 테이블만 마이그레이션할 수 있습니다. 기본 키 자동 생성을 사용 중지하는 경우 변환된 스키마를 적용한 후 대상 데이터베이스의 변환된 테이블에서 기본 키 또는 고유 제약 조건을 수동으로 만들어야 합니다. 샘플 SQL 명령어에 대한 다음 섹션을 펼칩니다.

기존 열을 사용하여 기본 키 만들기

테이블에 이미 열 또는 열 조합을 기반으로 하는 논리적 기본 키가 있을 수 있습니다. 예를 들어 고유 제약 조건 또는 색인이 구성된 열이 있을 수 있습니다. 이러한 열을 사용하여 소스 데이터베이스의 테이블에 대한 새 기본 키를 생성합니다. 예를 들면 다음과 같습니다.

ALTER TABLE TABLE_NAME
ADD PRIMARY KEY (COLUMN_NAME);

모든 열을 사용하여 기본 키 만들기

기본 키로 사용할 수 있는 기존 제약 조건이 없는 경우 테이블의 모든 열을 사용하여 기본 키를 만듭니다. PostgreSQL 클러스터에서 허용하는 기본 키의 최대 길이를 초과하지 않아야 합니다. 예를 들면 다음과 같습니다.

ALTER TABLE TABLE_NAME
ADD PRIMARY KEY (COLUMN_NAME_1, COLUMN_NAME_2, COLUMN_NAME_3, ...);

이와 같이 복합 기본 키를 만들 때는 사용하려는 모든 열 이름을 명시적으로 나열해야 합니다. 이 목적으로 모든 열 이름을 검색하는 데 문을 사용할 수 없습니다.

`ROWID` 의사 열을 사용하여 고유 제약 조건 만들기

Oracle 데이터베이스는 ROWID 유사 열을 사용하여 테이블에 있는 각 행의 위치를 저장합니다. 기본 키가 없는 Oracle 테이블을 마이그레이션하려면 대상 PostgreSQL 데이터베이스에 ROWID 열을 추가하면 됩니다. Database Migration Service는 소스 Oracle ROWID 유사 열의 해당 숫자 값으로 열을 채웁니다.

열을 추가하고 기본 키로 설정하려면 다음을 실행합니다.

ALTER TABLE TABLE_NAME ADD COLUMN rowid numeric(33,0) NOT NULL;
CREATE SEQUENCE TABLE_NAME_rowid_seq INCREMENT BY -1 START WITH -1 OWNED BY TABLE_NAME.rowid;
ALTER TABLE TABLE_NAME ALTER COLUMN rowid SET DEFAULT nextval('TABLE_NAME_rowid_seq');
ALTER TABLE TABLE_NAME ADD CONSTRAINT CONSTRAINT_DISPLAY_NAME PRIMARY KEY (rowid);

객체 이름 바꾸기 (`RENAME_*`)

변환 중에 다양한 데이터베이스 객체의 이름을 바꿀 수 있습니다. Database Migration Service는 새 이름을 사용하도록 모든 코드 참조(뷰, 저장 프러시저, 함수 등)를 자동으로 업데이트합니다.

일반 문법

RENAME_OBJECT_TYPE SOURCE_NAME1:DESTINATION_NAME1 SOURCE_NAME2:DESTINATION_NAME2 ...

중요 고려사항

RENAME_* 지시문은 대상 객체 이름에 대해 대소문자를 구분하며 CASE_HANDLING 지시문보다 우선 적용됩니다. 예를 들어 두 지시어를 모두 사용하는 경우 다음과 같습니다.

SCHEMA MySchema
CASE_HANDLING PRESERVE_ORIGINAL
# Destination objects are renamed exactly
# to 'SoMe_tAbLe' and 'RenamedView', respecting the case
# despite the CASE_HANDLING directive
RENAME_TABLES some_table:SoMe_tAbLe
RENAME_VIEWS MyView:RenamedView

SOURCE_NAME의 경우 MOVE_*와 같은 다른 지시어를 사용하더라도 항상 원래 객체 이름을 참조합니다. 예를 들어 뷰 객체 중 하나의 이름을 바꾸고 새 스키마로 이동하려면 두 지시어 모두에 원래 뷰 이름을 참조합니다.
```
RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
```
RENAME_TABLES 지시문은 단일 파일에서 REPLACE_TABLES 지시문을 재정의합니다. 테이블의 이름을 바꾸고 이동하려면 대신 MOVE_* 지시어를 사용하는 것이 좋습니다.
SOURCE_NAME 변수의 전체 형식은 SCHEMA 지시어도 사용하는지 여부에 따라 달라집니다.
- SCHEMA 지시문 사용: 정규화되지 않은 이름을 사용합니다(예: MyTable).
- SCHEMA 지시문 없음: 정규화된 이름을 사용합니다(예: MySchema.MyTable).

지원되는 RENAME_* 지시문

RENAME_SCHEMA: 스키마 이름을 바꿉니다.
단일 구성 파일에는 RENAME_SCHEMA 지시문이 하나만 포함될 수 있습니다. SCHEMA 지시문이 제공되면 RENAME_SCHEMA는 해당 스키마의 이름만 바꿀 수 있습니다.
RENAME_TABLES: 테이블 이름을 바꿉니다. 동일한 파일의 REPLACE_TABLES를 재정의합니다.
RENAME_COLUMNS: 테이블 내의 열 이름을 바꿉니다. 동일한 파일의 REPLACE_COLS 지시어를 재정의합니다. 다음 형식을 사용합니다.
```
RENAME_COLUMNS TABLE1.SRC_COL:DEST_COL TABLE2.SRC_COL:DEST_COL
```
SCHEMA 지시어를 사용하는 경우 정규화되지 않은 테이블 이름을 사용합니다. SCHEMA 지시어를 사용하지 않는 경우 정규화된 테이블 이름(예: SCHEMA.TABLE1)을 포함합니다.
RENAME_VIEWS
RENAME_MATERIALIZED_VIEWS
RENAME_SEQUENCES
RENAME_FUNCTIONS
RENAME_STORED_PROCEDURES
RENAME_TRIGGERS
RENAME_PACKAGES: Database Migration Service는 Oracle 패키지를 PostgreSQL 스키마로 변환합니다. 스키마에 이름을 공유하는 패키지가 포함된 경우 PostgreSQL 코드가 동일한 이름으로 두 스키마를 만들려고 할 때 이름 충돌이 발생할 수 있습니다. 이 지시어를 사용하여 이러한 충돌을 방지할 수 있습니다.

예를 들어 SALES.REPORTING_PKG 및 HR.REPORTING_PKG와 같은 패키지가 있는 경우 고유한 이름으로 이름을 바꿀 수 있습니다.
```
RENAME_PACKAGES SALES.UTILS:SALES_UTILS
RENAME_PACKAGES HR.UTILS:HR_UTILS
```
RENAME_USER_DEFINED_TYPES

사용 가능한 별칭: RENAME_UDTS

객체 이동 (`MOVE_*`)

대상 데이터베이스의 다른 스키마로 객체를 이동할 수 있습니다. 이는 마이그레이션 중에 데이터베이스 구조를 재구성하는 데 유용합니다. Database Migration Service는 뷰, 저장 프로시져, 함수 등의 모든 코드 참조를 자동으로 업데이트합니다.

일반 문법

MOVE_OBJECT_TYPE SOURCE_NAME1:DESTINATION_SCHEMA1 SOURCE_NAME2:DESTINATION_SCHEMA2 ...

중요 고려사항

SOURCE_NAME의 경우 RENAME_*와 같은 다른 지시어를 사용하더라도 항상 원래 객체 이름을 참조합니다. 예를 들어 뷰 객체 중 하나의 이름을 바꾸고 새 스키마로 이동하려면 두 지시어 모두에 원래 뷰 이름을 참조합니다.
```
RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
```
지시문은 전체 객체 이름이 아닌 DESTINATION_SCHEMA 이름만 예상합니다.
SOURCE_NAME 변수의 전체 형식은 SCHEMA 지시어도 사용하는지 여부에 따라 달라집니다.
- SCHEMA 지시문 사용: 정규화되지 않은 이름을 사용합니다(예: MyTable).
- SCHEMA 지시문 없음: 정규화된 이름을 사용합니다(예: MySchema.MyTable).

지원되는 MOVE_* 지시문

MOVE_TABLES: 테이블을 다른 스키마로 이동합니다. 단일 구성 파일의 스키마 변경사항에 대해 REPLACE_TABLES보다 우선 적용됩니다.
MOVE_VIEWS
MOVE_MATERIALIZED_VIEWS
MOVE_SEQUENCES
MOVE_FUNCTIONS
MOVE_STORED_PROCEDURES
MOVE_USER_DEFINED_TYPES

사용 가능한 별칭: MOVE_UDTS

예시: 스키마 재구성

SCHEMA LegacyApp

# Moves the 'LegacyApp.Users' and 'LegacyApp.Orders' tables
# to the 'data' schema.
MOVE_TABLES Users:data Orders:data

# Moves the 'LegacyApp.CreateUser' and 'LegacyApp.ProcessOrder'
# stored procedures to the 'api' schema
MOVE_STORED_PROCEDURES CreateUser:api ProcessOrder:api

# Moves the 'LegacyApp.SalesSummary' views to the 'reporting' schema
MOVE_VIEWS SalesSummary:reporting

`DATA_TYPE`

이 지시어를 사용하여 Oracle과 PostgreSQL 문법 간에 지원되는 데이터 유형을 명시적으로 매핑할 수 있습니다. 이 지시문에는 쉼표로 구분된 매핑 목록이 필요합니다. 전체 정의는 한 줄로 제공되어야 하지만 구성 파일에 여러 DATA_TYPE 지시어를 포함합니다. 다음 형식을 사용합니다.

DATA_TYPE ORACLE_DATA_TYPE1:PGSQL_DATA_TYPE1
DATA_TYPE ORACLE_DATA_TYPE2:PGSQL_DATA_TYPE2...

여기서 ORACLE_DATA_TYPE 및 PGSQL_DATA_TYPE는 마이그레이션에 사용하는 각 Oracle 및 PostgreSQL 버전에서 지원하는 데이터 유형입니다. 지원되는 버전에 대한 자세한 내용은 시나리오 개요를 참조하세요.

예시:

DATA_TYPE REAL:double precision,SMALLINT:integer

Oracle 및 PostgreSQL 데이터 유형에 대한 자세한 내용은 다음을 참조하세요.

Oracle 문서의 Oracle 데이터 유형
PostgreSQL 문서의 PostgreSQL 데이터 유형

`MODIFY_TYPE`

MODIFY_TYPE 지시어를 사용하면 Database Migration Service가 소스 테이블의 특정 열을 변환하는 데이터 유형을 제어할 수 있습니다. 이 지시문에는 쉼표로 구분된 매핑 목록이 필요합니다. 전체 정의는 한 줄로 제공되어야 하지만 구성 파일에 여러 MODIFY_TYPE 지시어를 포함할 수 있습니다. 다음 형식을 사용합니다.

MODIFY_TYPE SOURCE_TABLE_NAME1:COLUMN_NAME:EXPECTED_END_RESULT_DATA_TYPE
MODIFY_TYPE SOURCE_TABLE_NAME2:COLUMN_NAME:EXPECTED_END_RESULT_DATA_TYPE...

각 항목의 의미는 다음과 같습니다.

SOURCE_TABLE_NAME은 데이터 유형을 변경하려는 열이 포함된 테이블의 이름입니다.
중요: SCHEMA 지시어를 사용하지 않는 경우 정규화된 테이블 이름(SCHEMA_NAME.SOURCE_TABLE_NAME)을 사용해야 합니다.
COLUMN_NAME은 변환 매핑을 맞춤설정할 열의 이름입니다.
EXPECTED_END_RESULT_DATA_TYPE는 변환된 열에서 사용할 PostgreSQL 데이터 유형입니다.

예시:

MODIFY_TYPE events:dates_and_times:DATETIME,users:pseudonym:TEXT

`PG_INTEGER_TYPE`

기본적으로 Database Migration Service는 NUMBER(p,s) 유형을 PostgreSQL DECIMAL(p,s) 유형으로 변환합니다.

PG_INTEGER_TYPE 지시어를 사용하여 이 동작을 수정할 수 있습니다. 값을 1로 설정하고 정밀도 및 소수 자릿수 (NUMBER(p,s)) 유형이 있는 모든 NUMBER를 정밀도 자릿수에 따라 PostgreSQL smallint, integer 또는 bigint 유형으로 강제 변환합니다.

팁: 이 지시어를 DEFAULT_NUMERIC 지시어와 결합하면 일반 NUMBER 유형에도 사용할 수 있습니다.

전환 매핑 파일에 다음 설정을 포함합니다.

PG_INTEGER_TYPE 1

`PG_NUMERIC_TYPE`

정밀도 및 소수 자릿수 (NUMBER(p,s)) 유형이 있는 모든 NUMBER를 PostgreSQL real 또는 float 유형 (정밀도 자릿수 기준)으로 변환하려면 이 지시어를 1로 설정합니다.

이 지시어를 0로 설정하면 NUMBER(p,s) 값이 정확한 원래 값을 유지하고 내부 PostgreSQL 데이터 유형을 사용합니다.

전환 매핑 파일에 다음 설정을 포함합니다.

PG_NUMERIC_TYPE 1

`DEFAULT_NUMERIC`

정밀도가 없는 NUMBER의 기본 변환은 PG_INTEGER_TYPE 지시문도 사용하는지 여부에 따라 변경됩니다.

PG_INTEGER 지시어를 사용하는 경우 정밀도가 없는 NUMBER가 DECIMAL 값으로 변환됩니다.
PG_INTEGER 지시어를 사용하지 않으면 정밀도가 없는 NUMBER가 BIGINT 값으로 변환됩니다.

이 동작을 수정하고 DEFAULT_NUMERIC 지시어를 사용하여 지정된 정밀도 포인트가 없는 NUMBER 유형에 사용해야 하는 데이터 유형을 지정할 수 있습니다. 다음 형식을 사용합니다.

DEFAULT_NUMERIC POSTGRESQL_NUMERIC_DATA_TYPE

여기서 POSTGRESQL_NUMERIC_DATA_TYPE은 integer, smallint, bigint 중 하나입니다.

예시:

DEFAULT_NUMERIC integer

`REPLACE_COLS`

REPLACE_COLS 지시어를 사용하여 변환된 스키마에서 열 이름을 바꿀 수 있습니다. 이 지시문에는 쉼표로 구분된 매핑 목록이 필요합니다.

다음 형식을 사용합니다.

REPLACE_COLS SOURCE_TABLE_NAME1(SOURCE1_TABLE1_COLUMN_NAME1:DESTINATION_TABLE1_COLUMN_NAME1,SOURCE_TABLE1_COLUMN_NAME2:DESTINATION_TABLE1_COLUMN_NAME2),SOURCE_TABLE_NAME2(SOURCE_TABLE2_COLUMN_NAME1:DESTINATION_TABLE2_COLUMN_NAME1,SOURCE_TABLE2_COLUMN_NAME2:DESTINATION_TABLE2_COLUMN_NAME2)...

각 항목의 의미는 다음과 같습니다.

SOURCE_TABLE_NAME은 이름을 변경할 열이 포함된 테이블의 이름입니다. SCHEMA 지시어를 사용하지 않는 경우 정규화된 테이블 이름인 SCHEMA_NAME.SOURCE_TABLE_NAME를 사용해야 합니다.
SOURCE_COLUMN_NAME은 이름을 변경하려는 소스의 열 이름입니다.
DESTINATION_COLUMN_NAME는 변환된 스키마에서 사용할 열의 새 이름입니다.

예시:

REPLACE_COLS events(dates_and_times:event_dates),users(pseudonym:nickname)

`REPLACE_TABLES`

REPLACE_TABLES 지시어를 사용하여 테이블 이름을 바꾸거나 새 스키마로 이동할 수 있습니다. 이 지시문에는 공백으로 구분된 매핑 목록이 필요합니다. 각 사용 사례의 문법에 관한 자세한 내용은 다음 섹션을 펼치세요.

SCHEMA 지시어를 사용하지 않는 경우 소스 및 대상 변수 모두에 따옴표로 묶인 정규화된 테이블 이름을 사용해야 합니다.

"SCHEMA_NAME.SOURCE_TABLE_NAME"
"SCHEMA_NAME.DESTINATION_TABLE_NAME"

테이블 이름 바꾸기

변환된 스키마에서 테이블 이름을 바꾸려면 다음 형식을 사용합니다.

REPLACE_TABLES SOURCE_TABLE_NAME1:DESTINATION_TABLE_NAME1 SOURCE_TABLE_NAME2:DESTINATION_TABLE_NAME2

각 항목의 의미는 다음과 같습니다.

SOURCE_TABLE_NAME은 변환된 스키마에서 이름을 바꾸려는 소스 테이블의 이름입니다.
DESTINATION_TABLE_NAME는 변환된 스키마에서 사용할 테이블의 새 이름입니다.

예시:

REPLACE_TABLES "events:login_events" "users:platform_users"

스키마 간 테이블 이동

이 지시어를 사용하여 새 테이블 이름에 스키마 프리픽스를 추가하여 스키마 간에 테이블을 이동할 수 있습니다. 이 메커니즘은 전체 변환 파일에 SCHEMA 지시어를 사용하는 방식과 관계없이 사용할 수 있습니다. 예를 들면 다음과 같습니다.

REPLACE_TABLES "events:NEW_SCHEMA_NAME.login_events"

데이터 유형 맞춤설정을 위한 별칭

변환 지시어를 사용하여 Database Migration Service가 다양한 데이터 유형을 변환하는 방법을 수정하는 경우 (예: DATA_TYPE, MODIFY_TYPE 또는 PG_NUMERIC_TYPE 지시어 사용) 소스 SQL 데이터 유형 대신 별칭을 사용할 수 있습니다.

다음 섹션을 펼쳐 Database Migration Service에서 지원하는 데이터 유형 별칭 목록을 확인하세요.

데이터 유형 별칭

별칭	PostgreSQL 유형으로 변환됨
`bigint`, `int8`	`BIGINT`
`bool`, `boolean`	`BOOLEAN`
`bytea`	`BYTEA`
`char`, `character`	`CHAR`
`character varying`, `varchar`	`VARCHAR`
`date`	`DATE`
`decimal`, `numeric`	`DECIMAL`
`double precision`, `float8`	`DOUBLE PRECISION`
`real` `float4`	`REAL`
`int`, `integer`, `int4`	`INTEGER`
`int2`	`SMALLINT`
`interval`	`INTERVAL`
`json`	`JSON`
`smallint`	`SMALLINT`
`text`	`TEXT`
`time`	`TIME`
`timestamp`	`TIMESTAMP`
`timestamptz`	`TIMESTAMPTZ`
`timetz`	`TIMETZ`
`uuid`	`UUID`
`XML`	`XML`

샘플 전환 매핑 파일

지원되는 스키마 변환 지시문 중 일부를 사용하는 다음 샘플 변환 매핑 파일을 참조하세요.

EXPORT_SCHEMA 1
SCHEMA root

# Preserve original casing for all objects
CASE_HANDLING PRESERVE_ORIGINAL

# Data type conversions
PG_NUMERIC_TYPE 0
PG_INTEGER_TYPE 1
DEFAULT_NUMERIC integer
DATA_TYPE NUMBER(4\,0):integer
MODIFY_TYPE events:dates_and_times:TIMESTAMP

# Renaming objects using the RENAME_* directives
# These allow case-sensitive destination names
RENAME_TABLES events:LoginEvents users:PlatformUsers
RENAME_COLUMNS events.dates_and_times:EventDates users.pseudonym:Nickname
RENAME_VIEWS InternalReport:FinInternalReport

# Moving objects to new schemas using the MOVE_* directives
MOVE_TABLES audit_log:archive
MOVE_VIEWS InternalReport:reporting

이 파일을 사용한 결과는 다음과 같습니다.

EXPORT_SCHEMA 1는 필수 지시어입니다.
SCHEMA root는 정규화된 이름이 사용되지 않는 한 다른 지시문이 root 스키마 내의 객체에 적용되도록 합니다.
CASE_HANDLING PRESERVE_ORIGINAL은 소스 root 스키마의 모든 객체 이름이 대상에서 원래 대소문자를 유지하도록 합니다(RENAME_* 지시어로 재정의되지 않는 한).
PG_INTEGER_TYPE 1는 Database Migration Service가 root 스키마의 테이블에 있는 모든 Oracle 숫자 데이터 유형을 ANSI 휴대용 숫자 유형 대신 PostgreSQL 관련 유형으로 변환하도록 합니다.
DEFAULT_NUMERIC integer는 Database Migration Service가 지정된 정밀도 지점이 없는 NUMBER 값을 PostgreSQL INTEGER 유형으로 변환하도록 합니다.
DATA_TYPE NUMBER(4\,0):integer는 Database Migration Service가 특정 NUMBER(4,0) 값을 PostgreSQL INTEGER로 변환하도록 합니다.
MODIFY_TYPE events:dates_and_times:TIMESTAMP 지시문은 Database Migration Service가 events 소스 테이블의 dates_and_times 열에 있는 데이터를 PostgreSQL TIMESTAMP 유형으로 변환하도록 합니다.
RENAME_TABLES events:LoginEvents users:PlatformUsers는 지정된 대소문자를 유지하면서 테이블 이름을 바꿉니다.
- events 테이블의 이름이 LoginEvents로 변경되었습니다.
- users 테이블의 이름이 PlatformUsers로 변경되었습니다.
RENAME_COLUMNS events.dates_and_times:EventDates user.pseudonym:Nickname는 대상에서 지정된 대소문자를 유지하면서 열 이름을 바꿉니다.
- LoginEvents 테이블 (원래 이름 events)에서 dates_and_times 열의 이름이 EventDates로 변경됩니다.
- PlatformUsers (원래 이름 users)에서 pseudonym 열의 이름이 Nickname로 변경됩니다.
I will use these as hints for our translations.RENAME_VIEWS InternalReport:FinInternalReportInternalReportFinInternalReport
MOVE_TABLES audit_log:archive는 audit_log 테이블을 root 스키마에서 archive 스키마로 이동합니다.
MOVE_VIEWS InternalReport:reporting는 InternalReport 뷰를 reporting 스키마로 이동합니다. 이 뷰는 RENAME_VIEWS 지시어로 인해 FinInternalReport로 이름이 변경됩니다. Database Migration Service는 종속 항목을 처리합니다. 객체의 이름이 먼저 변경된 후 이동됩니다.

기존 변환 작업공간

기존 변환 작업공간은 더 오래되고 제한적인 유형의 변환 작업공간입니다. 기존 변환 작업공간은 Gemini로 향상된 변환 기능이나 대화형 SQL 편집기를 지원하지 않습니다. Ora2Pg 마이그레이션 도구를 사용하여 소스 스키마를 변환하는 데만 사용할 수 있습니다.

마이그레이션에 기존 유형의 변환 작업공간을 사용하지 않는 것이 좋습니다. 시나리오에서 기존 변환 작업공간을 사용해야 하는 경우 기존 변환 작업공간 사용을 참조하세요.

다음 단계

변환 작업공간 사용에 대해 알아보려면 다음을 참조하세요.

변환 작업공간 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

소스 스키마 초기화 옵션

전환 진행 상황 개요

결정론적 코드 및 스키마 변환

지원되는 Oracle 스키마 요소

지원되는 Oracle 코드 요소

대화형 SQL 편집기

수정 가능한 Oracle 객체

Gemini로 코드 및 스키마 변환 가속화

전환 매핑 파일

지원되는 변환 지시문

EXPORT_SCHEMA

SCHEMA

CASE_HANDLING

GENERATE_MISSING_PK

기존 열을 사용하여 기본 키 만들기

모든 열을 사용하여 기본 키 만들기

ROWID 의사 열을 사용하여 고유 제약 조건 만들기

객체 이름 바꾸기 (RENAME_*)

객체 이동 (MOVE_*)

DATA_TYPE

MODIFY_TYPE

PG_INTEGER_TYPE

PG_NUMERIC_TYPE

DEFAULT_NUMERIC

REPLACE_COLS

REPLACE_TABLES

테이블 이름 바꾸기

스키마 간 테이블 이동

데이터 유형 맞춤설정을 위한 별칭

데이터 유형 별칭

샘플 전환 매핑 파일

기존 변환 작업공간

다음 단계

변환 작업공간

`EXPORT_SCHEMA`

`SCHEMA`

`CASE_HANDLING`

`GENERATE_MISSING_PK`

`ROWID` 의사 열을 사용하여 고유 제약 조건 만들기

객체 이름 바꾸기 (`RENAME_*`)

객체 이동 (`MOVE_*`)

`DATA_TYPE`

`MODIFY_TYPE`

`PG_INTEGER_TYPE`

`PG_NUMERIC_TYPE`

`DEFAULT_NUMERIC`

`REPLACE_COLS`

`REPLACE_TABLES`