이 페이지에서는 Database Migration Service를 사용한 이기종 Oracle 마이그레이션에 대한 알려진 제한사항 (
기본 키 또는
외래 키 및 트리거와 같은 엔티티 처리에 관한 특별 고려사항 포함)과
권장사항을 설명합니다.
이전되지 않는 항목
사용자와 권한은 이전되지 않습니다.
활성 상태의 마이그레이션 작업 중에 발생하는 스키마 변경사항은 자동으로 마이그레이션되지 않습니다. 이전 중에 스키마를 변경하는 경우 먼저 스키마 변경사항으로 변환 작업공간을 업데이트한 다음 관련 이전 작업을 새로고침해야 합니다. 자세한 내용은
마이그레이션 작업에 업데이트된 스키마 또는 테이블 추가를 참고하세요.
Database Migration Service는 사용자 정의 데이터 유형을 복제하지만 사용자 정의 유형을 파생하는 기본 데이터 유형만 저장합니다.
예를 들어 USERNAME 데이터 유형을 기반으로 VARCHAR2 데이터 유형을 정의하는 경우 데이터는 대상에 VARCHAR로 저장됩니다.
데이터베이스, 트랜잭션, 데이터 일관성
Database Migration Service는 각 트랜잭션을 발생하는 대로 복제하지 않으므로 마이그레이션은 최종적으로 일관됩니다. 마이그레이션은 여러 테이블의 데이터를 가져옵니다. 데이터가 대상에 로드되는 순서는 다를 수 있지만 소스에 대한 쓰기가 중지되고 마이그레이션 버퍼가 지워진 후 소스와 다시 정렬됩니다.
이기종 Oracle 마이그레이션의 경우 Database Migration Service는 마이그레이션 작업당 하나의 데이터베이스만 마이그레이션할 수 있습니다.
Database Migration Service는 Oracle 멀티 테넌트 아키텍처 (CDB/PDB)를 지원하지만 마이그레이션 작업당 플러그인 가능한 단일 데이터베이스만 마이그레이션할 수 있습니다.
Oracle 라벨 보안(OLS)은 복제되지 않습니다.
마이그레이션 프로세스 중에 소스 데이터베이스에서 롤백된 트랜잭션은 트랜잭션이 충분히 긴 경우 대상에 일시적으로 표시될 수 있습니다.
Database Migration Service는 Oracle Real Application Clusters (RAC) 환경에서 단일 클라이언트 액세스 이름(SCAN) 기능을 사용하여 데이터베이스에 대한 직접 연결을 지원하지 않습니다. 이러한 환경에서 공개 IP 허용 목록 연결을 사용하는 데 대한 잠재적인 해결 방법은
Oracle SCAN 오류 문제 해결을 참고하세요.
데이터 인코딩
Database Migration Service는 대상 데이터베이스의 UTF8 설정 인코딩만 지원합니다. UTF8 인코딩 세트에 포함되지 않은 문자가 포함된 스키마 및 테이블 이름은 지원되지 않습니다.
Database Migration Service는 Oracle 데이터베이스에 대해 다음 문자 집합 인코딩을 지원합니다.
AL16UTF16
AL32UTF8
IN8ISCII
IW8ISO8859P8
JA16SJIS
JA16SJISTILDE
KO16MSWIN949
US7ASCII
UTF8
WE8ISO8859P1
WE8ISO8859P9
WE8ISO8859P15
WE8MSWIN1252
ZHT16BIG5
테이블, 스키마, 기타 객체
마이그레이션 중에는 데이터, 스키마, 메타데이터에 대한 데이터 정의 언어 (DDL) 변경이 지원되지 않습니다. 마이그레이션 중에 스키마를 업데이트하는 경우 변환 작업공간으로 변경사항을 가져오고, 코드를 변환하고, 대상을 정리하고, 마이그레이션 작업을 다시 실행해야 합니다.
영숫자 문자 또는 밑줄 (_) 이외의 문자가 포함된 표 열 이름은 지원되지 않습니다.
표 또는 열의 최대 이름 길이는 30자입니다.
Database Migration Service는 이 한도를 초과하는 테이블이나 이름이 이 한도를 초과하는 열이 포함된 테이블을 복제할 수 없습니다.
색인 구성 테이블(IOT)은 지원되지 않습니다.
전역 임시 테이블에는 대상에 pgtt PostgreSQL 확장 프로그램이 설치되고 생성되어야 합니다.
BFILE 유형 열의 경우 파일 경로만 복제됩니다. 파일 콘텐츠는 복제되지 않습니다.
Oracle 11g의 경우 데이터 유형이 ANYDATA 또는 UDT인 열이 있는 테이블은 지원되지 않으며 전체 테이블이 복제되지 않습니다.
구체화된 뷰 정의는 이전되지만 구체화된 데이터는 이전되지 않습니다. 마이그레이션을 완료한 후 구체화된 뷰를 새로고침하여 마이그레이션된 테이블의 데이터로 채웁니다.
시퀀스 값은 마이그레이션되지만 마이그레이션이 완료되기 전에 소스 데이터베이스의 값이 계속 증가할 수 있습니다. 마이그레이션을 완료한 후 대상 인스턴스의 시퀀스 값을 소스 데이터베이스의 값과 일치하도록 업데이트합니다.
마이그레이션 작업은 테이블 10,000개로 제한됩니다.
행의 크기는 100MB로 제한됩니다. 100MB 제한을 초과하는 행은 이전되지 않으며 마이그레이션 작업에 오류로 표시됩니다.
이전이 시작된 후에 생성된 테이블은 자동으로 이전되지 않습니다. 먼저 변환 작업공간에서 스키마를 가져오고, 변환된 정의를 대상에 적용하고, 마이그레이션 작업을 업데이트해야 합니다.
데이터 유형 제한사항
Oracle 마이그레이션에 지원되지 않는 데이터 유형은 다음과 같습니다.
ANYDATA (Oracle 11g의 경우 ANYDATA가 있는 테이블은 완전히 지원되지 않으며 복제되지 않습니다.)
BFILE
INTERVAL DAY TO SECOND
INTERVAL YEAR TO MONTH
LONG/LONG RAW
SDO_GEOMETRY
UDT
UROWID
XMLTYPE
TIMESTAMP의 제로 날짜
기본 키 고려사항
기본 키가 없는 테이블은 일관된 복제를 보장하지 않습니다.
Database Migration Service는 기본 키가 있는 테이블만 마이그레이션합니다.
소스 데이터베이스에 기본 키가 없는 테이블이 포함된 경우
소스 코드와 스키마를 변환할 때 Database Migration Service 변환 작업공간에서 대상 테이블에 누락된 기본 키를 자동으로 만듭니다.
기존 변환 작업공간을 사용하는 경우 마이그레이션을 시작하기 전에 대상 데이터베이스의 변환된 테이블에서 기본 키 제약 조건을 수동으로 만들어야 합니다. 자세한 내용은
기존 변환 작업공간을 참고하세요.
Database Migration Service에서 복제한 데이터에는 이미 소스 데이터베이스의 트리거에 의해 이루어진 변경사항이 포함되어 있습니다. 대상에서 트리거가 사용 설정된 경우 트리거가 다시 실행되어 데이터를 조작할 수 있으므로 데이터 무결성 또는 중복 문제가 발생할 수 있습니다.
외래 키
Database Migration Service는 트랜잭션 방식으로 데이터를 복제하지 않으므로 테이블이 순서대로 마이그레이션되지 않을 수 있습니다. 외래 키가 있고 외래 키를 사용하는 하위 테이블이 상위 테이블보다 먼저 이전되면 복제 오류가 발생할 수 있습니다.
권장사항
대상 Cloud SQL 데이터베이스를 만들 때 마이그레이션 요구사항을 충족할 수 있는 충분한 컴퓨팅 및 메모리 리소스를 사용해야 합니다. 적어도 1개의 듀얼 코어 CPU가 있는 머신 유형을 사용하는 것이 좋습니다.
예를 들어 머신 이름이 db-custom이고 CPU 2개와 3,840MB의 RAM을 사용하는 경우 머신 유형 이름의 형식은 db-custom-2-3840입니다.
필요한 경우 데이터 조작 언어 (DML) 변경사항을 적용할 수 있도록 마이그레이션 중에 대상 Cloud SQL 데이터베이스를 쓸 수 있습니다.
마이그레이션 프로세스를 중단하거나 데이터 무결성에 영향을 미칠 수 있는 데이터베이스 구성 또는 테이블 구조를 변경하지 않도록 주의하세요.
할당량
어느 시점에든지 최대 2,000개의 연결 프로필과 1,000개의 마이그레이션 작업이 존재할 수 있습니다. 더 많은 항목을 위한 여유 공간을 확보하려면 마이그레이션 작업 (완료된 작업 포함) 및 연결 프로필을 삭제하면 됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[[["\u003cp\u003eDatabase Migration Service only supports \u003ccode\u003eUTF8\u003c/code\u003e encoding for the destination database, and schema or table names not in this set are unsupported.\u003c/p\u003e\n"],["\u003cp\u003eMigration jobs are limited to a maximum of 10,000 tables, and only a single pluggable database can be migrated in one job.\u003c/p\u003e\n"],["\u003cp\u003eCertain data types, including \u003ccode\u003eANYDATA\u003c/code\u003e, \u003ccode\u003eLONG/LONG RAW\u003c/code\u003e, and \u003ccode\u003eXMLTYPE\u003c/code\u003e, are not supported and will be replaced with \u003ccode\u003eNULL\u003c/code\u003e values during migration.\u003c/p\u003e\n"],["\u003cp\u003eThe service does not support schema changes directly; updates must be made in the conversion workspace and relevant migration jobs accordingly.\u003c/p\u003e\n"],["\u003cp\u003eAll tables in the destination database must have a primary key, and if one is not present in the source, one will need to be created.\u003c/p\u003e\n"]]],[],null,["# Known limitations and recommendations\n\nThis page describes known limitations (including special considerations for\nhandling entities like\n[primary keys](#primary-keys-considerations) or\n[foreign keys and triggers](#foreign-keys-triggers-considerations)), as well as\n[recommended practices](#) for heterogeneous Oracle migrations with Database Migration Service.\n\nWhat isn't migrated\n-------------------\n\n- Users and permissions aren't migrated.\n- Schema changes that occur during an active migration job aren't automatically migrated. If you change your schema during the migration, you need to first update the conversion workspace with schema changes, and then refresh the relevant migration jobs. For more information, see [Add updated schema or tables to the migration job](/database-migration/docs/oracle-to-postgresql/manage-migration-jobs#edit-non-draft-job).\n- [`SAVEPOINT` statements](https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/SAVEPOINT.html) aren't supported and can cause data discrepancy in case of a rollback.\n- Database Migration Service replicates user-defined data types, but only stores the base data type from which you derive your user-defined types. For example, if you define a `USERNAME` data type based on the `VARCHAR2` data type, the data is stored in the destination as `VARCHAR`.\n\nDatabase, transactions and data consistency\n-------------------------------------------\n\n- The migration is eventually consistent, as Database Migration Service doesn't replicate each transaction as it happens. The migration brings in data from multiple tables. The order in which data is loaded into the destination may vary, but re-aligns with the source after writes on the source are stopped and the migration buffer is cleared.\n- For heterogeneous Oracle migrations, Database Migration Service can only migrate one database per migration job.\n- Database Migration Service supports Oracle multi-tenant architecture (CDB/PDB), but you can only migrate a single pluggable database per migration job.\n- Oracle Label Security (OLS) isn't replicated.\n- Any transactions that are rolled back in your source database during the migration process might be visible in the destination temporarily (when the transaction is long enough).\n- Database Migration Service doesn't support direct connectivity to databases using the Single Client Access Name (SCAN) feature in Oracle Real Application Clusters (RAC) environments. For potential solutions to using public IP allowlist connectivity with such environments, see [Troubleshoot Oracle SCAN errors](/database-migration/docs/oracle-to-postgresql/diagnose-issues#troubleshoot-scan).\n\nData encoding\n-------------\n\n- Database Migration Service supports only `UTF8` set encodings for the destination database. Schema and table names that include characters which aren't part of the `UTF8` encoding set are not supported.\n- Database Migration Service supports the following character set encodings for Oracle databases:\n - `AL16UTF16`\n - `AL32UTF8`\n - `IN8ISCII`\n - `IW8ISO8859P8`\n - `JA16SJIS`\n - `JA16SJISTILDE`\n - `KO16MSWIN949`\n - `US7ASCII`\n - `UTF8`\n - `WE8ISO8859P1`\n - `WE8ISO8859P9`\n - `WE8ISO8859P15`\n - `WE8MSWIN1252`\n - `ZHT16BIG5`\n\nTables, schemas, and other objects\n----------------------------------\n\n- During a migration, data definition language (DDL) changes to data, schemas, and metadata aren't supported. If you update your schema during the migration, you need to pull the changes to your conversion workspace, convert the code, clean your destination and run the migration job again.\n- Table column names that include characters other than alphanumeric characters or an underscore (`_`) aren't supported.\n- Maximum name length for tables or columns is 30 characters. Database Migration Service can't replicate tables that exceed this limit, or tables that contain columns whose names exceed this limit.\n- Index-organized tables (IOTs) aren't supported.\n- Global temporary tables require the `pgtt` PostgreSQL extension installed and created on the destination.\n- For columns of type `BFILE`, only the path to the file will be replicated. The contents of the file won't be replicated.\n- For Oracle 11g, tables that have columns of data types `ANYDATA` or `UDT` aren't supported, and the entire table won't be replicated.\n- Jobs that are scheduled by using [`dbms_job`](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_JOB.html) or [`dbms_scheduler`](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_SCHEDULER.html) aren't migrated.\n- Materialized views definitions are migrated, but their materialized data isn't. After you finish migrating, refresh your materialized views in order to populate them with data from the migrated tables.\n- Sequence values are migrated, but their values in the source database might keep advancing before the migration is completed. After complete the migration, update the sequence values on the destination instance to match those in the source database.\n- Migration jobs are limited to 10,000 tables.\n- Rows have a size limitation of 100 MB. Rows that exceed the 100 MB limit are not migrated, and show up as errors in the migration job.\n- Any tables that are created after the migration has started aren't be migrated automatically. First, you need to pull their schema in the conversion workspace, apply converted definitions to the destination, and update the migration job.\n\n### Data type limitations\n\nThe following data types are unsupported for Oracle migrations:\n\n- `ANYDATA` (For Oracle 11g, tables with `ANYDATA` are completely unsupported and not replicated.)\n- `BFILE`\n- `INTERVAL DAY TO SECOND`\n- `INTERVAL YEAR TO MONTH`\n- `LONG/LONG RAW`\n- `SDO_GEOMETRY`\n- `UDT`\n- `UROWID`\n- `XMLTYPE`\n- **Zero dates** in `TIMESTAMP`\n\n### Considerations for primary keys\n\nTables without primary keys don't promise consistent replication.\nDatabase Migration Service migrates only tables that have primary keys.\nIf your source database includes tables that don't have primary keys,\nDatabase Migration Service conversion workspaces automatically create any missing\nprimary keys in the destination tables when you\n[convert your source code and schema](/database-migration/docs/oracle-to-postgresql/convert-sql).\n\nIf you use legacy conversion workspaces, you need to manually create primary\nkey constraints in the converted tables in the destination database before\nyou start the migration. For more information, see\n[Legacy conversion workspaces](/database-migration/docs/oracle-to-postgresql/legacy-conversion-workspaces).\n\n### Considerations for foreign keys and triggers\n\nForeign keys and triggers present in your source database might lead to\ndata integrity issues, or even cause the migration job to fail.\nYou can prevent these issues if you skip foreign keys and triggers\n[by using the `REPLICATION` option for the migration user](/database-migration/docs/oracle-to-postgresql/configure-your-destination-postgresql-database).\nAlternatively, you can also drop all foreign keys and triggers in the destination\ndatabase and re-create them when the migration is complete.\n\n#### Triggers\n\nData replicated by Database Migration Service already incorporates any changes made by\ntriggers on the source database. If triggers are enabled on the destination,\nthey can fire again and potentially manipulate data, resulting in data integrity\nor duplication issues.\n\n#### Foreign keys\n\nDatabase Migration Service doesn't replicate data in a transactional\nmanner, so tables might be migrated out of order. If foreign keys are present,\nand a child table that uses a foreign key is migrated before its parent, you might\nencounter replication errors.\n\nRecommendations\n---------------\n\n- When you [create your destination Cloud SQL database](/database-migration/docs/oracle-to-postgresql/configure-your-destination-postgresql-database), make sure that you use enough compute and memory resources to cover your migration needs. We recommend a machine type with at least a dual-core CPU.\n\n For example, if your machine name is `db-custom`, and it has\n 2 CPUs and 3840 MB of RAM, then the format for the machine type name\n is `db-custom-2-3840`.\n- The destination Cloud SQL database is writable during the migration to allow Data Manipulation Language (DML) changes to be applied if needed. Take care not to make any changes to the database configuration or table structures which might break the migration process or impact data integrity.\n\nQuotas\n------\n\n- Up to 2,000 connection profiles and 1,000 migration jobs can exist at any given time. To create space for more, migration jobs (including completed ones) and connection profiles can be deleted."]]
