Oracle® OLTP 시스템에서 Spanner로 마이그레이션

이 문서에서는 Oracle® 온라인 트랜잭션 처리(OLTP) 시스템의 데이터베이스를 Spanner로 마이그레이션하는 방법을 설명합니다.

참고: Online Analytical Processing(OLAP) 데이터베이스의 경우, 대안으로 BigQuery를 사용하는 것이 좋습니다.

Spanner는 다른 엔터프라이즈 데이터베이스 관리 도구와는 다른 개념을 사용하므로, 해당 기능을 최대한 활용하려면 애플리케이션을 조정해야 할 수 있습니다. 또한 요구사항을 충족하기 위해 Google Cloud의 다른 서비스로 Spanner를 보완해야 할 수도 있습니다.

마이그레이션 제약조건

애플리케이션을 Spanner로 마이그레이션하는 경우에는 사용할 수 있는 여러 기능을 고려해야 합니다. Spanner의 특성 세트에 맞추고 추가 Google Cloud 서비스와 통합하기 위해 애플리케이션 아키텍처를 다시 설계해야 할 수도 있습니다.

저장 프로시저 및 트리거

Spanner는 데이터베이스 수준에서 사용자 코드 실행을 지원하지 않으므로, 마이그레이션의 일환으로 데이터베이스 수준 저장 프로시저 및 트리거로 구현된 비즈니스 로직을 애플리케이션으로 이동해야 합니다.

시퀀스

UUID 버전 4를 기본 방법으로 사용하여 기본 키 값을 생성하는 것이 좋습니다. GENERATE_UUID() 함수(GoogleSQL, PostgreSQL)는 UUID 버전 4 값을 STRING 유형으로 반환합니다.

64비트 정수 값을 생성해야 하는 경우 Spanner는 포지티브 비트 반전 시퀀스(GoogleSQL, PostgreSQL)를 지원하며, 이러한 시퀀스는 양의 64비트 숫자 공간에 균등하게 분산되는 값을 생성합니다. 부하 집중 문제를 방지하기 위해 이러한 수치를 사용할 수 있습니다.

자세한 내용은 기본 키 기본값 전략을 참고하세요.

액세스 제어

Spanner는 IAM 액세스 권한과 역할을 사용하여 데이터베이스 수준 액세스만 제어할 수 있습니다. 사전 정의된 역할은 데이터베이스에 대한 읽기-쓰기 또는 읽기 전용 액세스 권한을 부여할 수 있습니다.

보다 세부적인 권한이 필요하면 애플리케이션 레이어에서 해당 권한을 구현해야 합니다. 일반적인 시나리오에서는 애플리케이션만 데이터베이스를 읽고 쓸 수 있어야 합니다.

보고를 위해 데이터베이스를 사용자에게 노출해야 하고 테이블 및 뷰 수준 권한과 같은 세부적인 보안 권한을 사용하려면 데이터베이스를 BigQuery로 내보내야 합니다.

데이터 유효성 검사 제약조건

Spanner는 데이터베이스 레이어에서 데이터 유효성 검사 제약조건을 제한적으로 지원할 수 있습니다.

더 복잡한 데이터 제약조건이 필요하면 애플리케이션 레이어에서 해당 제약조건을 구현합니다.

다음 표에서는 Oracle® 데이터베이스에서 흔히 볼 수 있는 제약조건 유형과 Spanner에서 이를 구현하는 방법이 제시되어 있습니다.

제약조건	Spanner로 구현
null 아님	NOT NULL 열 제약조건
고유	UNIQUE 제약조건을 가진 보조 색인
외래 키(일반 테이블용)	외래 키 관계 만들기 및 관리를 참조하세요.
외래 키 ON DELETE/ON UPDATE 작업	인터리브 처리된 테이블에서만 가능함. 그렇지 않으면 애플리케이션 레이어에서 구현됨.
CHECK 제약조건 또는 트리거를 통한 값 확인 및 유효성 검사	애플리케이션 레이어에서 구현됨

지원되는 데이터 유형

Oracle® 데이터베이스와 Spanner는 서로 다른 데이터 유형 집합을 지원합니다. 다음 표에는 Oracle 데이터 유형 및 그에 해당하는 Spanner 데이터 유형이 나열되어 있습니다. 각 Spanner 데이터 유형의 자세한 정의는 데이터 유형을 참조하세요.

Oracle 데이터를 Spanner 데이터베이스에 맞게 만들기 위해 참고 열의 설명처럼 데이터를 추가로 변환해야 할 수도 있습니다.

예를 들어 큰 BLOB을 데이터베이스가 아닌 Cloud Storage 버킷에 객체로 저장한 후 Cloud Storage 객체에 대한 URI 참조를 데이터베이스에 STRING으로 저장할 수 있습니다.

Oracle 데이터 유형	대응하는 Spanner 데이터 유형	참고
문자 유형(CHAR, VARCHAR, NCHAR, NVARCHAR)	STRING	참고: Spanner는 전체적으로 유니코드 문자열을 사용합니다. Oracle은 유형에 따라 최대 길이 32,000바이트 또는 32,000자(영문)를 지원하지만 Spanner는 최대 2,621,440자(영문)를 지원합니다.
BLOB, LONG RAW, BFILE	BYTES 또는 STRING(객체의 URI 포함)	작은 객체(10MiB 미만)를 BYTES로 저장할 수 있습니다. 더 큰 객체를 저장하려면 Cloud Storage와 같은 다른 Google Cloud 서비스를 사용해야 합니다.
CLOB NCLOB, LONG	STRING(데이터 또는 외부 객체의 URI 포함)	작은 객체(2,621,440자 미만(영문 기준))를 STRING으로 저장할 수 있습니다. 더 큰 객체를 저장하려면 Cloud Storage와 같은 다른 Google Cloud 서비스를 사용해야 합니다.
NUMBER, NUMERIC, DECIMAL	STRING, FLOAT64, INT64	NUMBER Oracle 데이터 유형은 최대 38자리의 정밀도를 지원하는 반면, FLOAT64 Spanner 데이터 유형은 최대 16자리의 정밀도를 지원합니다. 다른 메커니즘에 대해서는 임의 정밀도 숫자 데이터 저장을 참조하세요.
INT, INTEGER, SMALLINT	INT64
BINARY_FLOAT BINARY_DOUBLE	FLOAT64
DATE	DATE	Spanner DATE 유형의 기본 STRING 표현은 Oracle과 달리 yyyy-mm-dd이므로, 날짜의 STRING 표현 간 자동 변환 시 주의해야 합니다. 날짜를 형식이 지정된 문자열로 전환할 수 있는 SQL 함수가 제공됩니다.
DATETIME	TIMESTAMP	Spanner는 시간대와 관계없이 시간을 저장합니다. 시간대를 저장해야 하는 경우, 별도의 STRING 열을 사용해야 합니다. 타임스탬프를 표준 시간대를 사용한 형식이 지정된 문자열로 전환할 수 있는 SQL 함수가 제공됩니다.
XML	STRING(데이터 또는 외부 객체의 URI 포함)	작은 XML 객체(2,621,440자 미만(영문 기준))를 STRING으로 저장할 수 있습니다. 더 큰 객체를 저장하려면 Cloud Storage와 같은 다른 Google Cloud 서비스를 사용해야 합니다.
URI, DBURI, XDBURI, HTTPURI	STRING
ROWID	PRIMARY KEY	Spanner는 테이블의 기본 키를 사용하여 행을 내부적으로 정렬하고 참조하므로, Spanner에서는 ROWID 데이터 유형과 사실상 동일합니다.
SDO_GEOMETRY SDO_TOPO_GEOMETRY_SDO_GEORASTER		Spanner는 지리정보 데이터 유형을 지원하지 않습니다. 이 데이터를 표준 데이터 유형으로 저장하고 애플리케이션 레이어에서 검색 및 필터링 로직을 구현해야 합니다.
ORDAudio, ORDDicom, ORDDoc, ORDImage, ORDVideo, ORDImageSignature		Spanner는 미디어 데이터 유형을 지원하지 않습니다. 미디어 데이터를 저장하려면 Cloud Storage 사용을 고려합니다.

이전 프로세스

이전 프로세스의 전체 과정은 다음과 같습니다.

1. 스키마와 데이터 모델을 전환합니다.
2. 모든 SQL 쿼리를 변환합니다.
3. Oracle 이외에 Spanner를 사용하도록 애플리케이션을 마이그레이션합니다.
4. Oracle에서 데이터를 일괄적으로 내보내고 Dataflow를 사용하여 Spanner로 데이터를 가져옵니다.
5. 마이그레이션 중에는 두 데이터베이스 간의 일관성을 유지합니다.
6. Oracle에서 애플리케이션을 이전합니다.

1단계: 데이터베이스 및 스키마 변환

기존 스키마를 Spanner 스키마로 전환하여 데이터를 저장합니다. 애플리케이션을 보다 간단하게 수정하려면 기존 Oracle 스키마와 최대한 가깝게 일치해야 합니다. 하지만 기능 차이로 인해 일부 변경이 필요합니다.

스키마 설계 권장사항을 따르면 처리량을 높이고 Spanner 데이터베이스의 부하 집중 문제를 줄일 수 있습니다.

기본 키

Spanner에서 행을 2개 이상 저장해야 하는 모든 테이블은 하나 이상의 열을 가진 테이블로 구성된 기본 키가 있어야만 합니다. 테이블의 기본 키는 테이블의 각 행을 고유하게 식별하며 테이블 행은 기본 키를 기준으로 정렬됩니다. Spanner는 고도로 분산되어 있으므로 데이터 증가에 맞춰 확장되는 기본 키 생성 기술을 선택하는 것이 중요합니다. 자세한 내용은 추천 기본 키 마이그레이션 전략을 참조하세요.

기본 키를 지정한 후에는 테이블을 삭제하고 다시 만들어야 기본 키 열을 추가 또는 제거하거나 나중에 기본 키 값을 변경할 수 없습니다. 기본 키 지정 방법에 대한 자세한 내용은 스키마 및 데이터 모델 - 기본 키를 참조하세요.

테이블 인터리브 처리

Spanner에는 테이블 2개를 일대다 상위-하위 관계로 정의할 수 있는 기능이 있습니다. 이 기능은 스토리지의 상위 행과 함께 하위 데이터 행을 인터리브 처리하므로, 상위 테이블과 하위 테이블을 함께 쿼리하면 테이블이 미리 효과적으로 결합되어 데이터 검색 효율성이 향상됩니다.

하위 테이블의 기본 키는 상위 테이블의 기본 키 열로 시작해야 합니다. 하위 행에서 볼 때 상위 행의 기본 키는 외래 키입니다. 상위-하위 관계를 최대 6단계까지 정의할 수 있습니다.

하위 테이블에 대한 삭제 시 작업을 정의하여 상위 행이 삭제되면 수행할 작업을 결정할 수 있습니다. 즉, 모든 하위 행을 삭제하거나 하위 행이 존재하는 동안에 상위 행 삭제를 차단할 수 있습니다.

다음은 앞에서 정의한 상위 Singers 테이블에 인터리브 처리된 Albums 테이블을 만드는 예입니다.

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId)
INTERLEAVE IN PARENT (Singers)
ON DELETE CASCADE;

보조 색인 만들기

또한 보조 색인을 만들어 테이블 내에서 기본 키 밖에 있는 데이터의 색인을 생성할 수 있습니다.

Spanner는 테이블과 동일한 방식으로 보조 색인을 구현하므로, 색인 키로 사용할 열 값에는 테이블의 기본 키와 동일한 제약조건이 있습니다. 이는 또한 색인의 일관성이 Spanner 테이블과 동일하게 보장됨을 의미합니다.

보조 색인을 사용한 값 조회는 테이블 조인을 사용하는 쿼리와 실제로 동일합니다. STORING 절을 사용하여 보조 색인에 원래 테이블의 열 값을 복사하여 저장함으로써 커버링 색인을 만들 수 있으므로, 색인을 사용하여 쿼리 성능을 향상시킬 수 있습니다.

Spanner의 쿼리 최적화 도구는 색인 자체가 쿼리되는 모든 열을 저장하고 있는 경우에만(커버드 쿼리) 보조 색인을 자동으로 사용합니다. 원래 테이블의 열 쿼리 시 색인을 사용하게 만들려면 SQL 문에서 FORCE INDEX 지시문을 사용해야 합니다. 예를 들면 다음과 같습니다.

SELECT *
FROM MyTable@{FORCE_INDEX=MyTableIndex}
WHERE IndexedColumn=@value

색인을 사용하면 테이블 열에 UNIQUE 색인을 정의하여 해당 열 내의 값을 고유하게 만들 수 있습니다. 중복 값 추가는 색인에 의해 방지됩니다.

다음은 Albums 테이블에 대한 보조 색인을 만드는 DDL 문의 예입니다.

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

데이터가 로드된 후에 추가 색인을 만들면 색인을 채우는데 다소 시간이 걸릴 수 있습니다. 추가 속도를 일일 평균 3회로 제한해야 합니다. 보조 색인 만들기에 대한 자세한 내용은 보조 색인을 참조하세요. 색인 생성 시 제한사항에 대한 자세한 내용은 스키마 업데이트를 참조하세요.

2단계: 모든 SQL 쿼리 변환

Spanner는 ANSI 2011 SQL 언어(확장 포함)를 사용하며 데이터를 변환하고 집계하는 데 유용한 다양한 함수 및 연산자를 포함합니다. Oracle 관련 문법, 함수, 유형을 사용하는 모든 SQL 쿼리를 Cloud Spanner와 호환되도록 전환해야 합니다.

Spanner는 구조화된 데이터를 열 정의로 지원하지 않습니다. 하지만 ARRAY 및 STRUCT 유형을 사용하여 SQL 쿼리에서 구조화된 데이터를 사용할 수 있습니다.

예를 들어 사전 결합된 데이터를 활용하여 STRUCTs의 ARRAY를 사용하는 아티스트의 모든 앨범을 반환하는 쿼리를 작성할 수 있습니다. 자세한 내용은 문서의 하위 쿼리에 대한 참고사항을 참조하세요.

Google Cloud 콘솔의 Spanner 스튜디오 페이지에서 SQL 쿼리를 프로파일링하여 쿼리를 실행할 수 있습니다. 일반적으로 큰 테이블에 전체 테이블 검색을 수행하는 쿼리의 비용이 비싸므로 아껴서 사용해야 합니다.

SQL 쿼리 최적화에 대한 자세한 내용은 SQL 권장사항 문서를 참조하세요.

3단계: Spanner를 사용하도록 애플리케이션 마이그레이션

Spanner는 다양한 언어에 대한 클라이언트 라이브러리 집합과 함께 Spanner 관련 API 호출, SQL 쿼리, DML(Data Modification Language) 문을 사용하여 데이터를 읽고 쓸 수 있는 기능을 제공합니다. SQL 문을 변환할 필요가 없으므로, 키로 행 직접 읽기와 같은 일부 쿼리에 대해서는 API 호출을 사용하는 것이 더 빠를 수 있습니다.

또한 기존 도구와 기본 통합 없는 인프라를 활용하여 JDBC(자바 데이터베이스 연결) 드라이버로 Spanner에 연결할 수 있습니다.

마이그레이션 프로세스의 일부로 Spanner에서 사용할 수 없는 기능을 애플리케이션에 구현해야 합니다. 예를 들어 데이터 값을 확인하고 관련 테이블을 업데이트하는 트리거는 애플리케이션에서 읽기/쓰기 트랜잭션을 사용하여 기존 행을 읽고 제약조건을 확인한 후 두 테이블에 업데이트된 행을 쓰도록 구현되어야 합니다.

Spanner는 읽기/쓰기 및 읽기 전용 트랜잭션을 제공하여 데이터의 외부 일관성을 보장합니다. 또한 읽기 트랜잭션에 타임스탬프 경계를 적용할 수 있어, 다음 중 하나에서 일관된 버전의 데이터를 읽을 수 있습니다.

• 과거의 정확한 시점(최대 1시간 전)
• 미래(해당 시간에 도달할 때까지 읽기가 차단됨)
• 허용된 양의 제한된 비활성이 지난 후. 이 시간이 지나면 다른 복제본에서 나중에 데이터를 사용할 수 있는지 확인하지 않고도 과거의 일정 시간까지 일관된 뷰가 반환됩니다. 이 경우 비활성 데이터를 희생시키는 대신 성능상의 이점을 얻을 수 있습니다.

4단계: Oracle에서 Spanner로 데이터 전송

Oracle에서 Spanner로 데이터를 전송하려면 Oracle 데이터베이스를 포터블 파일 형식(예: CSV)으로 내보낸 후 Dataflow를 사용하여 Spanner로 해당 데이터를 가져와야 합니다.

Oracle에서 일괄 내보내기

Oracle은 전체 데이터베이스를 포터블 파일 형식으로 내보내거나 언로드할 수 있는 유틸리티를 기본 제공하지 않습니다.

내보내기를 수행하기 위한 몇 가지 옵션은 Oracle FAQ에 있습니다.

예를 들면 다음과 같습니다.

• SQL*plus 또는 SQLcl을 사용하여 쿼리를 텍스트 파일로 스풀링합니다.
• UTL_FILE을 통해 PL/SQL 함수를 작성하여 테이블을 텍스트 파일에 동시에 언로드합니다.
• Oracle APEX 또는 Oracle SQL Developer의 기능을 사용하여 테이블을 CSV 또는 XML 파일에 언로드합니다.

이들 각 방법은 한 번에 테이블 하나만 내보낼 수 있다는 단점이 있습니다. 즉, 내보내기를 위해 데이터베이스를 일관된 상태로 유지하려면 애플리케이션을 일시중지하거나 데이터베이스를 정지시켜야 합니다.

다른 옵션으로는 Oracle FAQ 페이지에 있는 서드 파티 도구가 있으며, 그 중 일부는 전체 데이터베이스의 일관된 뷰를 언로드할 수 있습니다.

이러한 데이터 파일을 언로드한 후에는 가져올 수 있도록 Cloud Storage 버킷에 업로드해야 합니다.

Spanner로 일괄 가져오기

Oracle과 Spanner 간에 데이터베이스 스키마가 다를 가능성이 높으므로, 가져오기 프로세스의 일부로 데이터 일부를 전환해야 할 수도 있습니다.

이러한 데이터 전환을 수행하고 Spanner로 데이터를 가져오는 가장 쉬운 방법은 Dataflow를 사용하는 것입니다.

Dataflow는 Google Cloud 분산 추출, 변환, 로드(ETL) 서비스로, Apache Beam SDK로 작성된 데이터 파이프라인을 실행하여 대량의 데이터를 여러 머신에서 병렬로 읽고 처리하기 위한 플랫폼입니다.

Apache Beam SDK를 사용하려면 데이터 읽기, 변환, 쓰기를 설정하는 간단한 자바 프로그램을 작성해야 합니다. Cloud Storage 및 Spanner용 Beam Connector가 제공되므로, 데이터 변환 자체에 대한 코드만 작성하면 됩니다.

CSV 파일에서 읽고 Spanner에 쓰는 간단한 파이프라인의 예시는 이 문서와 함께 제공된 샘플 코드 저장소를 참조하세요.

Spanner 스키마에서 상위-하위 인터리브 처리된 테이블을 사용하는 경우, 가져오기 프로세스에서 하위 행 앞에 상위 행이 생성되도록 주의해야 합니다. Spanner 가져오기 파이프라인 코드는 먼저 루트 수준 테이블의 모든 데이터를 가져온 후 모든 수준 1 하위 테이블과 모든 수준 2 하위 테이블 등의 데이터를 차례로 가져오는 방식으로 이를 처리합니다.

Spanner 가져오기 파이프라인을 직접 사용하여 데이터를 일괄적으로 가져올 수 있습니다. 하지만 이 방법을 사용하려면 Avro 파일에 있는 데이터가 올바른 스키마를 사용하고 있어야 합니다.

5단계: 두 데이터베이스 간의 일관성 유지

대부분의 애플리케이션에는 가용성 요구사항이 있으므로, 데이터를 내보내고 가져오는 데 필요한 시간 동안 애플리케이션을 오프라인 상태로 유지할 수 없습니다. 데이터를 Spanner로 전송하는 동안 애플리케이션이 기존 데이터베이스를 계속 수정합니다. 애플리케이션이 실행되는 동안 Spanner 데이터베이스에 업데이트 내용을 복제해야 합니다.

변경 데이터 캡처, 애플리케이션에서 동시 업데이트 구현 등 두 데이터베이스를 동기화 상태로 유지할 수 있는 다양한 방법이 있습니다.

변경 데이터 캡처

Oracle GoldenGate는 Oracle 데이터베이스를 위한 변경 데이터 캡처(CDC) 스트림을 제공할 수 있습니다. Oracle LogMiner 또는 Oracle XStream Out은 Oracle GoldenGate와 관련되지 않은 CDC 스트림을 가져오기 위한 Oracle 데이터베이스용 대체 인터페이스입니다.

이 스트림 중 하나를 구독하고 Spanner 데이터베이스에 동일한 수정 사항(물론 데이터 변환 후)을 적용하는 애플리케이션을 작성할 수 있습니다. 이러한 스트림 처리 애플리케이션은 몇 가지 기능을 구현해야 합니다.

• Oracle 데이터베이스(소스 데이터베이스)에 연결
• Spanner(대상 데이터베이스)에 연결
• 다음 작업 반복 수행:
  • Oracle 데이터베이스 CDC 스트림 중 하나로 생성되는 데이터 수신
  • CDC 스트림으로 생성되는 데이터 해석
  • 데이터를 Spanner INSERT 문으로 변환
  • Spanner INSERT 문 실행

데이터베이스 마이그레이션 기술은 해당 기능의 일부로 필수 기능을 구현한 미들웨어 기술입니다. 데이터베이스 마이그레이션 플랫폼은 고객 요구사항에 따라 소스 위치 및 대상 위치에서 개별 구성요소로 설치됩니다. 데이터베이스 마이그레이션 플랫폼은 소스에서 대상 데이터베이스로 연속되는 데이터 전송을 지정하고 시작하기 위해 관련된 데이터베이스의 연결 구성만 필요합니다.

Striim은 Google Cloud에서 제공되는 데이터베이스 마이그레이션 기술 플랫폼입니다. Oracle LogMiner 및 Oracle XStream Out은 물론 Oracle GoldenGate의 CDC 스트림 연결을 제공합니다. Striim은 Oracle에서 Spanner로 데이터를 전송하기 위해 필요한 데이터베이스 연결 및 모든 변환 규칙을 구성할 수 있게 해주는 그래픽 도구를 제공합니다.

스트림 처리 애플리케이션을 직접 빌드할 필요 없이 Google Cloud Marketplace Connect에서 Striim을 소스 및 대상 데이터베이스에 설치하고, 모든 변환 규칙을 구현하고, 데이터 전송을 시작할 수 있습니다.

애플리케이션에서 두 데이터베이스 모두 동시 업데이트

또 다른 방법은 두 데이터베이스 모두에 쓰기 작업을 수행하도록 애플리케이션을 수정하는 방법입니다. 데이터베이스 하나(처음에는 Oracle)가 진실의 근원(Source of truth)으로 간주되고 각 데이터베이스 쓰기 후에 전체 행이 읽혀지고 전환되어 Spanner 데이터베이스에 작성됩니다.

이러한 방법으로 애플리케이션이 Spanner 행을 최신 데이터로 계속 덮어씁니다.

모든 데이터가 올바르게 전송되었다고 확신하면 정보의 근원(source of truth)을 Spanner 데이터베이스로 전환할 수 있습니다.

이러한 메커니즘을 통해 Spanner로 전환 시 문제가 발견되면 롤백 경로를 제공합니다.

데이터 일관성 확인

데이터가 Spanner 데이터베이스로 스트리밍되는 과정에서 Spanner 데이터와 Oracle 데이터를 정기적으로 비교하여 데이터 일관성을 유지할 수 있습니다.

두 데이터 소스 모두 쿼리하고 결과를 비교하여 일관성을 확인할 수 있습니다.

Dataflow에서 조인 변환을 통해 대규모 데이터 세트를 자세히 비교할 수 있습니다. 이 변환은 키가 지정된 데이터 세트 2개를 취해 키별로 값을 일치시킵니다. 그런 다음 일치된 값이 동일한지 비교할 수 있습니다.

일관성 수준이 비즈니스 요구사항에 부합될 때까지 이러한 확인을 정기적으로 실행할 수 있습니다.

6단계: Spanner를 애플리케이션의 정보 근원으로 전환

데이터 마이그레이션에 확신이 서면 Spanner를 정보 소스로 사용하도록 애플리케이션을 전환할 수 있습니다. Oracle 데이터베이스에 변경사항을 계속해서 기록하면 Oracle 데이터베이스가 최신 상태로 유지되므로, 문제 발생 시 롤백 경로가 제공됩니다.

마지막으로 Oracle 데이터베이스 업데이트 코드를 중지 및 삭제한 후 Oracle 데이터베이스를 종료할 수 있습니다.

Spanner 데이터베이스 내보내기 및 가져오기

Dataflow 템플릿으로 내보내기를 수행하여 Spanner에서 Cloud Storage 버킷으로 테이블을 선택적으로 내보낼 수 있습니다. 결과 폴더에는 내보낸 테이블이 있는 JSON 매니페스트 파일과 Avro 파일 집합이 포함됩니다. 이들 파일은 다음과 같은 다양한 용도로 사용됩니다.

• 데이터 보관 정책 준수 또는 재해 복구를 위한 데이터베이스 백업
• Avro 파일을 BigQuery와 같은 다른 Google Cloud 제품으로 가져오기

내보내기 및 가져오기 프로세스에 대한 자세한 내용은 데이터베이스 내보내기와 데이터베이스 가져오기를 참조하세요.

다음 단계

• Spanner 스키마 최적화 방법 알아보기
• 더 복잡한 상황에서 Dataflow를 사용하는 방법 알아보기