Oracle 마이그레이션을 위한 데이터 마이그레이션, ETL 및 로드

아티클
06/01/2023

이 문서는 Oracle에서 Azure Synapse Analytics로 마이그레이션하는 방법의 지침을 제공하는 7부 시리즈 중 2부입니다. 이 문서는 ETL 및 로드 마이그레이션에 대한 모범 사례에 중점을 두고 있습니다.

데이터 마이그레이션 고려 사항

레거시 Oracle 데이터 웨어하우스와 데이터 마트의 데이터, ETL 및 로드를 Azure Synapse로 마이그레이션할 때는 여러 가지 사항을 고려해야 합니다.

Oracle에서 데이터 마이그레이션에 대한 초기 결정

기존 Oracle 환경에서 마이그레이션을 계획할 때는 다음과 같은 데이터 관련 질문을 고려하세요.

사용하지 않는 테이블 구조도 마이그레이션해야 하나요?
사용자에게 미치는 영향과 위험을 최소화하는 최상의 마이그레이션 방법은 무엇인가요?
데이터 마트를 마이그레이션할 때 실제로 유지하나요, 가상으로 전환해야 하나요?

다음 섹션에서는 Oracle에서 마이그레이션 맥락 내에서 이러한 사항을 설명합니다.

사용하지 않는 테이블도 마이그레이션해야 하나요?

사용 중인 테이블만 마이그레이션하는 것이 좋습니다. 활성 상태가 아닌 테이블을 마이그레이션 대신 보관할 수 있으므로 향후 필요한 경우에 데이터를 사용할 수 있습니다. 설명서가 최신 상태가 아닐 수 있으므로 사용 중인 테이블을 확인하기 위해 설명서보다 시스템 메타데이터 및 로그 파일을 사용하는 것이 가장 좋습니다.

Oracle 시스템 카탈로그 테이블과 로그에는 지정된 테이블에 마지막으로 액세스한 시간을 확인하는 데 사용할 수 있는 정보가 포함되어 있으며, 이 정보를 사용하여 테이블이 마이그레이션 후보인지 여부를 결정할 수 있습니다.

Oracle 진단 팩에 라이선스를 부여한 경우 활성 세션 기록에 액세스할 수 있으며, 이 활성 세션 기록을 사용하여 테이블에 마지막으로 액세스한 시간을 확인할 수 있습니다.

팁

레거시 시스템에서 시간이 지남에 따라 테이블이 중복되는 것은 드문 일이 아니며 대부분의 경우 마이그레이션할 필요가 없습니다.

다음은 특정 기간 내에 특정 테이블의 사용을 찾는 예제 쿼리입니다.

SELECT du.username,
    s.sql_text,
    MAX(ash.sample_time) AS last_access ,
    sp.object_owner ,
    sp.object_name ,
    sp.object_alias as aliased_as ,
    sp.object_type ,
    COUNT(*) AS access_count 
FROM v$active_session_history ash         
    JOIN v$sql s ON ash.force_matching_signature = s.force_matching_signature
    LEFT JOIN v$sql_plan sp ON s.sql_id = sp.sql_id
    JOIN DBA_USERS du ON ash.user_id = du.USER_ID
WHERE ash.session_type = 'FOREGROUND'
    AND ash.SQL_ID IS NOT NULL
    AND sp.object_name IS NOT NULL
    AND ash.user_id <> 0
GROUP BY du.username,
    s.sql_text,
    sp.object_owner,
    sp.object_name,
    sp.object_alias,
    sp.object_type 
ORDER BY 3 DESC;

수많은 쿼리를 실행한 경우 이 쿼리를 실행하는 데 시간이 걸릴 수 있습니다.

사용자에게 미치는 영향과 위험을 최소화하는 최상의 마이그레이션 방법은 무엇인가요?

이 질문은 회사가 민첩성을 개선하기 위해 데이터 웨어하우스 데이터 모델에 대한 변경의 영향을 낮추기를 원할 수 있으므로 자주 제기됩니다. 회사에는 ETL 마이그레이션 중에 데이터를 더욱 현대화하거나 변환할 기회가 많이 있습니다. 이 방법은 여러 요소를 동시에 변경하여 기존 시스템과 새 시스템의 결과를 비교하기 어렵게 만들기 때문에 더 높은 위험을 수반합니다. 여기에서 데이터 모델을 변경하면 다른 시스템에 대한 업스트림 또는 다운스트림 ETL 작업에도 영향을 줄 수 있습니다. 이러한 위험 때문에 데이터 웨어하우스 마이그레이션 후에 이 규모로 재설계하는 것이 좋습니다.

데이터 모델이 전체 마이그레이션의 일부로 의도적으로 변경되더라도 새 플랫폼에서 리엔지니어링을 수행하는 것보다 기존 모델을 있는 그대로 Azure Synapse에 마이그레이션하는 것이 좋습니다. 이 방법은 기존 프로덕션 시스템에 대한 영향을 최소화하는 동시에 일회성 리엔지니어링 작업을 위해 Azure 플랫폼의 성능과 탄력적인 확장성을 활용합니다.

팁

향후에 데이터 모델에 대한 변경이 계획되어 있더라도 초기에 기존 모델을 있는 그대로 마이그레이션합니다.

데이터 마트를 마이그레이션할 때 실제로 유지하나요 아니면 가상으로 전환하나요?

레거시 Oracle 데이터 웨어하우스 환경에서는 조직 내 특정 부서나 비즈니스 함수의 임시 셀프 서비스 쿼리와 보고서에 우수한 성능을 제공하도록 구성된 데이터 마트를 여러 개 만드는 것이 일반적입니다. 데이터 마트는 일반적으로 사용자가 빠른 응답 시간으로 해당 데이터를 쉽게 쿼리할 수 있는 형식의 집계된 데이터 버전이 포함된 데이터 웨어하우스의 하위 집합으로 구성됩니다. 사용자는 데이터 마트와 비즈니스 사용자 상호 작용을 지원하는 Microsoft Power BI와 같은 사용자 친화적인 쿼리 도구를 사용할 수 있습니다. 데이터 마트의 데이터 형식은 일반적으로 차원 데이터 모델입니다. 데이터 마트의 한 가지 용도는 기본 웨어하우스 데이터 모델이 다른 모델(예: 데이터 자격 증명 모음)인 경우에도 데이터를 사용 가능한 형식으로 노출하는 것입니다.

조직 내의 개별 사업부에 대해 별도의 데이터 마트를 사용하여 강력한 데이터 보안 체제를 구현할 수 있습니다. 사용자와 관련된 특정 데이터 마트에 대한 액세스를 제한하고 중요한 데이터를 제거, 난독 처리 또는 익명화할 수 있습니다.

이러한 데이터 마트가 실제 테이블로 구현되는 경우 이를 사용하려면 빌드하고 정기적으로 새로 고칠 수 있는 추가 스토리지 리소스와 처리가 필요합니다. 또한 마트의 데이터는 마지막 새로 고침 작업만큼만 최신 상태이므로 변동성이 큰 데이터 대시보드에는 적합하지 않을 수 있습니다.

팁

데이터 마트를 가상화하면 스토리지 및 처리 리소스를 절약할 수 있습니다.

Azure Synapse와 같은 저렴한 확장 가능한 MPP 아키텍처의 출현과 이러한 아키텍처의 고유한 성능 특성으로 인해 마트를 일련의 실제 테이블로 인스턴스화하지 않고도 데이터 마트 기능을 제공할 수 있습니다. 한 가지 방법은 SQL 보기를 통해 데이터 마트를 효과적으로 주 데이터 웨어하우스로 가상화하는 방법입니다. 또 다른 방법은 Azure 또는 타사 가상화 제품의 보기와 같은 기능을 사용하여 가상화 레이어를 통해 데이터 마트를 가상화하는 방법입니다. 이 방법은 추가 스토리지 및 집계 처리의 필요성을 간소화하거나 제거하고 마이그레이션할 전체 데이터베이스 개체 수를 줄입니다.

이 방법에는 또 다른 잠재적인 이점이 있습니다. 가상화 레이어 내에서 집계 및 조인 논리를 구현하고 가상화된 뷰를 통해 외부 보고 도구를 표시하면 이러한 뷰를 만드는 데 필요한 처리가 데이터 웨어하우스로 푸시 다운됩니다. 데이터 웨어하우스는 일반적으로 대용량 데이터에서 조인, 집계 및 기타 관련 작업을 실행하는 데 가장 적합한 장소입니다.

실제 데이터 마트보다 가상 데이터 마트를 구현하려는 주요 동인은 다음과 같습니다.

가상 데이터 마트는 실제 테이블 및 관련 ETL 프로세스보다 변경하기 쉬우므로 민첩성이 향상됩니다.
가상화된 구현에는 더 적은 수의 데이터 저장소와 데이터 복사본이 필요하므로 총 소유 비용이 낮아집니다.
가상화된 환경에서 마이그레이션 및 단순화된 데이터 웨어하우스 아키텍처를 위한 ETL 작업을 제거합니다.
성능: 실제 데이터 마트 성능이 역사적으로 더 우수했지만 가상화 제품은 이제 이러한 차이를 완화하도록 지능형 캐싱 기술을 구현합니다.

팁

Azure Synapse의 성능과 확장성은 성능 저하 없이 가상화를 가능하게 합니다.

Oracle에서 데이터 마이그레이션

데이터 이해

데이터 양이 마이그레이션 방법을 결정하는 데 영향을 미칠 수 있으므로 마이그레이션 계획의 일부로 마이그레이션할 데이터 양을 자세하게 이해해야 합니다. 시스템 메타데이터를 사용하여 마이그레이션할 테이블 내의 원시 데이터가 차지하는 실제 공간을 결정합니다. 이 컨텍스트에서 원시 데이터는 인덱스 및 압축과 같은 오버헤드를 제외하고 테이블 내 데이터 행에서 사용하는 공간 양을 의미합니다. 가장 큰 팩트 테이블은 일반적으로 95%가 넘는 데이터를 구성합니다.

이 쿼리는 Oracle의 총 데이터베이스 크기를 제공합니다.

SELECT
  ( SELECT SUM(bytes)/1024/1024/1024 data_size 
    FROM sys.dba_data_files ) +
  ( SELECT NVL(sum(bytes),0)/1024/1024/1024 temp_size 
    FROM sys.dba_temp_files ) +
  ( SELECT SUM(bytes)/1024/1024/1024 redo_size 
    FROM sys.v_$log ) +
  ( SELECT SUM(BLOCK_SIZE*FILE_SIZE_BLKS)/1024/1024/1024 controlfile_size 
    FROM v$controlfile ) "Size in GB"
FROM dual

데이터베이스 크기는 (data files + temp files + online/offline redo log files + control files) 크기와 같습니다. 전체 데이터베이스 크기에는 사용된 공간과 사용 가능한 공간이 포함됩니다.

다음 예제 쿼리는 테이블 데이터와 인덱스에서 사용하는 디스크 공간을 분석합니다.

SELECT
   owner, "Type", table_name "Name", TRUNC(sum(bytes)/1024/1024) Meg
FROM
  ( SELECT segment_name table_name, owner, bytes, 'Table' as "Type" 
    FROM dba_segments 
    WHERE segment_type in  ('TABLE','TABLE PARTITION','TABLE SUBPARTITION' )
UNION ALL
    SELECT i.table_name, i.owner, s.bytes, 'Index' as "Type"
    FROM dba_indexes i, dba_segments s
    WHERE s.segment_name = i.index_name
    AND   s.owner = i.owner
    AND   s.segment_type in ('INDEX','INDEX PARTITION','INDEX SUBPARTITION')
UNION ALL
    SELECT l.table_name, l.owner, s.bytes, 'LOB' as "Type"
    FROM dba_lobs l, dba_segments s
    WHERE s.segment_name = l.segment_name
    AND   s.owner = l.owner
    AND   s.segment_type IN ('LOBSEGMENT','LOB PARTITION','LOB SUBPARTITION')
UNION ALL
    SELECT l.table_name, l.owner, s.bytes, 'LOB Index' as "Type"
    FROM dba_lobs l, dba_segments s
    WHERE s.segment_name = l.index_name
    AND   s.owner = l.owner
    AND   s.segment_type = 'LOBINDEX')
    WHERE owner in UPPER('&owner')
GROUP BY table_name, owner, "Type"
HAVING SUM(bytes)/1024/1024 > 10  /* Ignore really small tables */
ORDER BY SUM(bytes) desc;

또한 Microsoft 데이터베이스 마이그레이션 팀은 Oracle 인벤토리 스크립트 아티팩트를 포함하여 여러 가지 리소스를 제공합니다. Oracle 인벤토리 스크립트 아티팩트 도구에는 Oracle 시스템 테이블에 액세스하고 스키마 형식, 개체 형식 및 상태별로 개체 수를 제공하는 PL/SQL 쿼리가 포함되어 있습니다. 또한 도구는 각 스키마의 대략적인 원시 데이터 예측과 각 스키마의 테이블 크기 조정을 CSV 형식으로 저장된 결과와 함께 제공합니다. 포함된 계산기 스프레드시트는 CSV를 입력으로 사용하고 크기 조정 데이터를 제공합니다.

테이블의 경우 행 100만개와 같은 데이터의 대표적인 샘플을 추출하여 압축되지 않은 구분된 플랫 ASCII 데이터 파일로 마이그레이션해야 하는 데이터 양을 정확하게 예측할 수 있습니다. 그런 다음, 해당 파일의 크기를 사용하여 행당 평균 원시 데이터 크기를 구합니다. 마지막으로 해당 평균 크기에 전체 테이블의 총 행 수를 곱하여 테이블의 원시 데이터 크기를 제공합니다. 계획에 원시 데이터 크기를 사용합니다.

SQL 쿼리를 사용하여 데이터 형식 찾기

Oracle 정적 데이터 사전 DBA_TAB_COLUMNS 보기를 쿼리하여 스키마에서 사용 중인 데이터 형식과 이러한 데이터 형식을 변경해야 하는지 여부를 확인할 수 있습니다. SQL 쿼리를 사용하여 Oracle 스키마에서 Azure Synapse 데이터 형식에 직접 매핑되지 않는 데이터 형식이 있는 열을 찾습니다. 마찬가지로, 쿼리를 사용하여 Azure Synapse에 직접 매핑되지 않는 각 Oracle 데이터 형식 발생 횟수를 계산할 수 있습니다. 이러한 쿼리의 결과를 데이터 형식 비교 테이블과 함께 사용하여 Azure Synapse 환경에서 변경해야 하는 데이터 형식을 결정할 수 있습니다.

Azure Synapse에서 데이터 형식에 매핑되지 않는 데이터 형식이 있는 열을 찾으려면 <owner_name>을 스키마의 관련 소유자로 바꾼 후 다음 쿼리를 실행합니다.

SELECT owner, table_name, column_name, data_type
FROM dba_tab_columns
WHERE owner in ('<owner_name>')
AND data_type NOT IN 
    ('BINARY_DOUBLE', 'BINARY_FLOAT', 'CHAR', 'DATE', 'DECIMAL', 'FLOAT', 'LONG', 'LONG RAW', 'NCHAR', 'NUMERIC', 'NUMBER', 'NVARCHAR2', 'SMALLINT', 'RAW', 'REAL', 'VARCHAR2', 'XML_TYPE') 
ORDER BY 1,2,3;

매핑할 수 없는 데이터 형식의 수를 계산하려면 다음 쿼리를 사용합니다.

SELECT data_type, count(*) 
FROM dba_tab_columns 
WHERE data_type NOT IN 
    ('BINARY_DOUBLE', 'BINARY_FLOAT', 'CHAR', 'DATE', 'DECIMAL', 'FLOAT', 'LONG', 'LONG RAW', 'NCHAR', 'NUMERIC', 'NUMBER', 'NVARCHAR2', 'SMALLINT', 'RAW', 'REAL', 'VARCHAR2', 'XML_TYPE') 
GROUP BY data_type 
ORDER BY data_type;

Microsoft는 데이터 형식 매핑을 포함하여 레거시 Oracle 환경에서 데이터 웨어하우스 마이그레이션을 자동화하도록 Oracle용 SSMA(SQL Server Migration Assistant)를 제공합니다. Azure Database Migration Services를 사용하여 Oracle과 같은 환경에서 마이그레이션을 계획하고 수행할 수도 있습니다. 타사 공급업체도 마이그레이션을 자동화하는 도구와 서비스를 제공합니다. 이미 Oracle 환경에서 타사 ETL 도구를 사용하고 있으면 필요한 모든 데이터 변환을 구현하는 도구를 사용할 수 있습니다. 다음 섹션에서는 기존 ETL 프로세스 마이그레이션을 살펴봅니다.

ETL 마이그레이션 고려 사항

Oracle ETL 마이그레이션에 대한 초기 결정

ETL/ELT 처리의 경우 레거시 Oracle 데이터 웨어하우스에서 사용자 지정 빌드 스크립트, 타사 ETL 도구 또는 시간이 경과함에 따라 진화한 방법의 조합을 사용하는 경우가 많습니다. Azure Synapse로 마이그레이션을 계획할 때 비용과 위험을 최소화하면서 새 환경에서 필요한 ETL/ELT 처리를 구현하는 최상의 방법을 결정합니다.

팁

ETL 마이그레이션에 대한 방법을 미리 계획하고 적절한 경우 Azure 시설을 활용합니다.

이 순서도는 한 가지 방법을 요약합니다.

마이그레이션 옵션 및 권장 사항의 순서도.

순서도처럼 초기 단계에서는 항상 마이그레이션해야 하는 ETL/ELT 프로세스의 인벤토리를 빌드합니다. 표준 기본 제공 Azure 기능을 사용하면 일부 기존 프로세스를 이동하지 않아도 될 수 있습니다. 계획을 위해 마이그레이션 규모를 이해하는 것이 중요합니다. 다음으로 순서도 의사 결정 트리의 질문을 고려합니다.

네이티브 Azure로 이동하나요? 대답은 완전히 Azure 네이티브 환경으로 마이그레이션하는지 여부에 따라 다릅니다. 이러한 경우 Azure Data Factory의 파이프라인 및 작업 또는 Azure Synapse 파이프라인을 사용하여 ETL 처리를 다시 설계하는 것이 좋습니다.
타사 ETL 도구를 사용하고 있나요? 완전히 Azure 네이티브 환경으로 이동하지 않는 경우 이미 기존 타사 ETL 도구를 사용하고 있는지 여부를 확인합니다. Oracle 환경에서는 Oracle SQL Developer, Oracle SQL*Loader 또는 Oracle Data Pump와 같은 Oracle 관련 유틸리티를 사용하여 사용자 지정 스크립트에서 ETL 처리의 일부 또는 전부를 수행했는지 확인할 수 있습니다. 이 경우의 방법은 Azure Data Factory를 사용하여 다시 설계하는 것입니다.
타사에서 Azure Synapse 내 전용 SQL 풀을 지원하나요? 타사 ETL 도구의 기술에 많은 투자를 했는지 또는 기존 워크플로와 일정에서 해당 도구를 사용하는지 여부를 고려합니다. 이러한 경우 도구에서 효율적으로 Azure Synapse를 대상 환경으로 지원할 수 있는지 여부를 결정합니다. 이상적으로 도구에는 가장 효율적인 데이터 로드를 위해 PolyBase 또는 COPY INTO와 같은 Azure 기능을 사용할 수 있는 네이티브 커넥터가 포함됩니다. 그러나 네이티브 커넥터가 없더라도 일반적으로 PolyBase 또는 COPY INTO와 같은 외부 프로세스를 호출하고 해당 매개 변수를 전달할 수 있는 방법이 있습니다. 이 경우 Azure Synapse를 새 대상 환경으로 사용하여 기존 기술과 워크플로를 사용합니다.

ELT 처리에 ODI(Oracle Data Integrator)를 사용하는 경우 Azure Synapse용 ODI 기술 모듈이 필요합니다. 조직에서 이러한 모듈을 사용할 수 없지만 ODI가 있으면 ODI를 사용하여 플랫 파일을 생성할 수 있습니다. 그런 다음, 이러한 플랫 파일을 Azure로 이동하고 Azure Synapse에 로드할 수 있도록 Azure Data Lake Storage로 수집할 수 있습니다.
Azure에서 ETL 도구를 실행하나요? 기존 타사 ETL 도구를 유지하기로 결정한 경우 기존 온-프레미스 ETL 서버가 아닌 Azure 환경 내에서 해당 도구를 실행할 수 있습니다. 그러면 Azure Data Factory에서 기존 워크플로의 전체 오케스트레이션을 처리합니다. 따라서 비용, 성능 및 확장성 이점을 얻기 위해 기존 도구를 그대로 실행할지 또는 Azure 환경으로 이동할지 여부를 결정합니다.

팁

성능, 확장성 및 비용 이점을 활용하려면 Azure에서 ETL 도구를 실행하는 것이 좋습니다.

기존 Oracle 관련 스크립트 재설계

Oracle SQL*Plus, Oracle SQL Developer, Oracle SQL*Loader 또는 Oracle Data Pump와 같은 Oracle 관련 유틸리티를 사용하는 사용자 지정 스크립트에서 기존 Oracle 웨어하우스 ETL/ELT 처리의 일부나 전부를 처리하는 경우 Azure Synapse 환경에 사용되는 이러한 스크립트를 다시 코딩해야 합니다. 마찬가지로, Oracle의 저장 프로시저를 사용하여 ETL 프로세스를 구현한 경우 해당 프로세스를 다시 코딩해야 합니다.

ETL 프로세스의 일부 요소는 마이그레이션하기 쉽습니다(예: 외부 파일의 대량 데이터를 간단하게 준비 테이블로 로드). 예를 들어 SQL*Loader 대신 Azure Synapse COPY INTO 또는 PolyBase를 사용하여 프로세스의 해당 부분을 자동화할 수도 있습니다. 임의의 복잡한 SQL 및/또는 저장 프로시저를 포함하는 프로세스의 다른 부분은 재설계하는 데 더 많은 시간이 걸립니다.

팁

마이그레이션할 ETL 작업의 인벤토리에는 스크립트와 저장 프로시저가 포함되어야 합니다.

Azure Synapse 호환성을 위해 Oracle SQL을 테스트하는 한 가지 방법은 Oracle v$active_session_history 및 v$sql 조인에서 몇 가지 대표적인 SQL 문을 캡처하여 sql_text를 가져온 다음, 해당 쿼리에 EXPLAIN을 접두사로 추가하는 것입니다. Azure Synapse에서 유사 마이그레이션된 데이터 모델을 가정하면 Azure Synapse에서 해당 EXPLAIN 문을 실행합니다. 호환되지 않는 모든 SQL에서 오류가 발생합니다. 이 정보를 사용하여 재코딩 작업 규모를 결정할 수 있습니다.

팁

EXPLAIN을 사용하여 SQL 비호환성을 확인합니다.

최악의 경우 수동 재코딩이 필요할 수 있습니다. 그러나 Oracle 관련 코드를 다시 설계하는 데 도움이 되도록 Microsoft 파트너에서 제공하는 제품과 서비스가 있습니다.

팁

파트너는 Oracle 관련 코드를 다시 설계하는 데 도움이 되는 제품과 기술을 제공합니다.

기존 타사 ETL 도구 사용

많은 경우 이미 타사 ETL 제품에서 기존 레거시 데이터 웨어하우스 시스템을 채우고 유지합니다. Azure Synapse의 현재 Microsoft 데이터 통합 파트너 목록은 Azure Synapse Analytics 데이터 통합 파트너를 참조하세요.

Oracle 커뮤니티에서는 인기 있는 여러 ETL 제품을 자주 사용합니다. 다음 단락에서는 가장 인기 있는 Oracle 웨어하우스용 ETL 도구를 설명합니다. Azure의 VM 내에서 이러한 모든 제품을 실행하고 사용하여 Azure 데이터베이스와 파일을 읽고 쓸 수 있습니다.

팁

기존 타사 도구에 대한 투자를 활용하여 비용과 위험을 줄입니다.

Oracle에서 데이터 로드

Oracle 데이터 웨어하우스에서 데이터를 마이그레이션하려고 준비할 때 기존 온-프레미스 Oracle 환경에서 클라우드의 Azure Synapse로 데이터를 물리적으로 이동하는 방법과 전송 및 로드를 수행하는 데 사용할 도구를 결정합니다. 다음 섹션에서 논의될 다음 질문을 고려합니다.

데이터를 파일로 추출하려고 하나요, 아니면 네트워크 연결을 통해 직접 이동하려고 하나요?
원본 시스템 또는 Azure 대상 환경 중 어디서 프로세스를 오케스트레이션할 예정인가요?
마이그레이션 프로세스를 자동화하고 관리하는 데 사용할 도구는 무엇인가요?

파일 또는 네트워크 연결을 통해 데이터를 전송하나요?

마이그레이션할 데이터베이스 테이블이 Azure Synapse에서 생성되면 데이터를 이동하여 레거시 Oracle 시스템에서 해당 테이블을 채우고 새 환경으로 로드할 수 있습니다. 다음과 같은 두 가지 기본 방법이 있습니다.

파일 추출: Oracle 테이블의 데이터를 구분된 플랫 파일(일반적으로 CSV 형식)로 추출합니다. 다음과 같은 여러 가지 방법으로 테이블 데이터를 추출할 수 있습니다.
- SQL*Plus, SQL Developer 및 SQLcl과 같은 표준 Oracle 도구를 사용합니다.
- ODI(Oracle 데이터 통합자)를 사용하여 플랫 파일을 생성합니다.
- Data Factory에서 Oracle 커넥터를 사용하여 파티션별로 데이터 로드를 사용하도록 Oracle 테이블을 병렬로 언로드합니다.
- 타사 ETL 도구를 사용합니다.
Oracle 테이블 데이터를 추출하는 방법에 대한 예제는 문서 부록을 참조하세요.

이 방법을 사용하려면 추출된 데이터 파일을 저장할 공간이 필요합니다. 공간은 Oracle 원본 데이터베이스의 로컬 공간(사용 가능한 스토리지가 충분한 경우) 또는 Azure Blob Storage의 원격 공간일 수 있습니다. 파일이 로컬로 기록되면 네트워크 오버헤드가 방지되므로 최상의 성능을 얻을 수 있습니다.

스토리지 및 네트워크 전송 요구 사항을 최소화하려면 gzip과 같은 유틸리티를 사용하여 추출된 데이터 파일을 압축합니다.

추출 후 플랫 파일을 Azure Blob Storage로 이동합니다. Microsoft는 다음을 포함하여 대량의 데이터를 이동하는 다양한 옵션을 제공합니다.
- 네트워크에서 Azure Storage로 파일을 이동하는 AzCopy
- 프라이빗 네트워크 연결을 통해 대량의 데이터를 이동하는 Azure ExpressRoute
- 로드를 위해 Azure 데이터 센터에 제공하는 실제 스토리지 디바이스로 파일을 이동하는 Azure Data Box
자세한 내용은 Azure 간 데이터 전송을 참조하세요.
네트워크에서 직접 추출 및 로드: 대상 Azure 환경은 일반적으로 SQL 명령을 통해 데이터 추출 요청을 레거시 Oracle 시스템에 전송하여 데이터를 추출합니다. 결과는 네트워크를 통해 전송되고 Azure Synapse에 직접 로드되며 데이터를 중간 파일에 '랜딩'할 필요가 없습니다. 이 시나리오의 제한 요인은 일반적으로 Oracle 데이터베이스와 Azure 환경 간의 네트워크 연결 대역폭입니다. 이례적인 대용량 데이터에는 이 방법이 실용적이지 않을 수 있습니다.

팁

이러한 요인이 마이그레이션 방법 결정에 영향을 미치므로 마이그레이션할 데이터 양과 사용 가능한 네트워크 대역폭을 파악합니다.

두 가지 방법을 모두 사용하는 하이브리드 방법도 있습니다. 예를 들어 더 작은 차원 테이블과 더 큰 팩트 테이블의 샘플에 대한 직접 네트워크 추출 방법을 사용하여 Azure Synapse에서 테스트 환경을 빠르게 제공할 수 있습니다. 대용량 기록 팩트 테이블의 경우 Azure Data Box를 사용하여 파일 추출 및 전송 방법을 사용할 수 있습니다.

Oracle 또는 Azure 중 어디서 오케스트레이션하나요?

Azure Synapse로 이동할 때의 권장 방법은 SSMA 또는 Data Factory를 사용하여 Azure 환경에서 데이터 추출 및 로드를 오케스트레이션하는 방법입니다. 가장 효율적으로 데이터를 로드할 수 있도록 PolyBase 또는 COPY INTO와 같은 관련 유틸리티를 사용합니다. 이 방법은 기본 제공 Azure 기능의 이점을 활용하고 재사용 가능한 데이터 로드 파이프라인을 빌드하는 수고를 줄입니다. 메타데이터 기반 데이터 로드 파이프라인을 사용하여 마이그레이션 프로세스를 자동화할 수 있습니다.

또한 관리 및 로드 프로세스가 Azure에서 실행되므로 권장 방법은 데이터 로드 프로세스 중에 기존 Oracle 환경의 성능 저하를 최소화합니다.

기존 데이터 마이그레이션 도구

데이터 변환과 이동은 모든 ETL 제품의 기본 함수입니다. 데이터 마이그레이션 도구가 이미 기존 Oracle 환경에서 이미 사용 중이고 Azure Synapse를 대상 환경으로 지원하는 경우 데이터 마이그레이션이 간소화되도록 해당 도구를 사용하는 것이 좋습니다.

기존 ETL 도구가 없는 경우에도 Azure Synapse Analytics 데이터 통합 파트너는 데이터 마이그레이션 작업을 간소화하는 ETL 도구를 제공합니다.

마지막으로 ETL 도구를 사용하려는 경우 Azure 환경 내에서 Azure 클라우드 성능, 확장성 및 비용을 활용하도록 해당 도구를 실행하는 것이 좋습니다. 이 방법을 사용하면 Oracle 데이터 센터의 리소스도 확보됩니다.

요약

Oracle에서 Azure Synapse로 데이터와 관련 ETL 프로세스 마이그레이션의 권장 사항을 요약하면 다음과 같습니다.

성공적인 마이그레이션을 위해 미리 계획합니다.
가능한 한 빨리 마이그레이션할 데이터 및 프로세스의 상세한 인벤토리를 빌드합니다.
시스템 메타데이터 및 로그 파일을 사용하여 데이터 및 프로세스 사용을 정확하게 이해합니다. 설명서가 오래되었을 수 있으므로 설명서에 의존하지 마세요.
마이그레이션할 데이터 볼륨과 온-프레미스 데이터 센터와 Azure 클라우드 환경 간의 네트워크 대역폭을 이해합니다.
Azure VM의 Oracle 인스턴스를 레거시 Oracle 환경에서 마이그레이션을 오프로드하기 위한 디딤돌로 사용하는 것이 좋습니다.
표준 기본 제공 Azure 기능을 사용하여 마이그레이션 워크로드를 최소화합니다.
Oracle 및 Azure 환경 모두에서 데이터 추출과 로드에 가장 효율적인 도구를 식별하고 이해합니다. 프로세스의 각 단계에서 적절한 도구를 사용합니다.
Data Factory와 같은 Azure 기능을 사용하여 Oracle 시스템에 대한 영향을 최소화하면서 마이그레이션 프로세스를 오케스트레이션하고 자동화합니다.

부록: Oracle 데이터를 추출하는 기술 예제

Oracle에서 Azure Synapse로 마이그레이션할 때 여러 가지 기술을 사용하여 Oracle 데이터를 추출할 수 있습니다. 다음 섹션에서는 Data Factory에서 Oracle SQL Developer 및 Oracle 커넥터를 사용하여 Oracle 데이터를 추출하는 방법을 보여 줍니다.

데이터 추출에 Oracle SQL Developer 사용

다음 스크린샷과 같이 Oracle SQL Developer UI를 사용하여 CSV를 포함한 여러 가지 형식으로 테이블 데이터를 내보낼 수 있습니다.

다른 내보내기 옵션으로는 JSON 및 XML이 있습니다. UI를 사용하여 테이블 이름 세트를 "카트"에 추가한 다음, 카트의 전체 세트에 내보내기를 적용할 수 있습니다.

Oracle SQLcl(SQL Developer 명령줄)을 사용하여 Oracle 데이터를 내보낼 수도 있습니다. 이 옵션에서는 셸 스크립트를 사용하는 자동화를 지원합니다.

비교적 작은 테이블에서 직접 연결을 통해 데이터를 추출하는 데 문제가 발생하는 경우 이 기술이 유용할 수 있습니다.

병렬 복사에 Azure Data Factory의 Oracle 커넥터 사용

Data Factory의 Oracle 커넥터를 사용하여 큰 Oracle 테이블을 병렬로 언로드할 수 있습니다. Oracle 커넥터는 Oracle에서 병렬로 데이터를 복사하는 기본 제공 데이터 분할을 제공합니다. 복사 작업의 원본 탭에서 데이터 분할 옵션을 찾을 수 있습니다.

원본 탭의 Azure Data Factory Oracle 파티션 옵션 스크린샷

병렬 복사에 사용할 Oracle 커넥터를 구성하는 방법은 Oracle에서 병렬 복사를 참조하세요.

Data Factory 복사 작업 성능 및 확장성에 대한 자세한 내용은 복사 작업 성능 및 확장성 가이드를 참조하세요.

다음 단계

보안 액세스 작업을 자세히 알아보려면 이 시리즈의 다음 문서인 Oracle 마이그레이션을 위한 보안, 액세스 및 작업을 참조하세요.

다음을 통해 공유