AWS Study Group

Giảm thiểu downtime khi di chuyển dữ liệu từ cơ sở dữ liệu Oracle đến Amazon RDS for Oracle sử dụng các tablespace cho phép chuyển dời và AWS DMS

bởi Manash Kalita, Sudip Acharya, và Viqash Adwani | vào 07 MAY 2024 | trong Advanced (300), Amazon RDS, RDS for Oracle, Technical How-to | Permalink | 

Thuật ngữ: 

  • Tablespace (Không gian bảng) – một đơn vị lưu trữ logic dùng để quản lý dữ liệu trong cơ sở dữ liệu Oracle. Nó tương tự như một thư mục trên hệ điều hành, nơi bạn có thể lưu trữ các tệp tin khác nhau.
  • RMAN (Recovery Manager) Cross-Platform Transportable Tablespace Backup Sets (XTTS) : một kĩ thuật trong Oracle để di chuyển tablespace giữa các hệ điều hành khác nhau
  • SCN:  System Change Number – dãy số tự động tăng kiểm tra thay đổi trong CSDL.
  • Backup: Bản sao lưu
  • Level: Cấp độ

Các tổ chức đang tìm cách di chuyển các khối lượng công việc quan trọng của Oracle sang Amazon Relational Database Service (Amazon RDS) dành cho Oracle với khoảng thời gian ngừng hoạt động (downtime) và gián đoạn tối thiểu để tận dụng sự linh hoạt, khả năng mở rộng và đổi mới của AWS Cloud. Trong bài viết này, chúng ta sẽ khám phá các tùy chọn để chuyển cơ sở dữ liệu Oracle từ nền tảng cũ (ví dụ: HPUX, AIX, SOLARIS và các nền tảng khác) sang Amazon RDS for Oracle bằng cách sử dụng phương pháp RMAN Cross-Platform Transportable Tablespaces Backup Sets (XTTS) và dịch vụ AWS Database Migration Service (AWS DMS).

Di chuyển cơ sở dữ liệu Oracle bằng XTTS là chiến lược di chuyển vật lý, nơi dữ liệu Oracle được sao chép từng khối. Downtime của phương pháp này không liên quan đến kích thước cơ sở dữ liệu mà phụ thuộc vào số lượng đối tượng siêu dữ liệu (bảng và chỉ mục) cần di chuyển.

Di chuyển cơ sở dữ liệu Oracle sử dụng AWS DMS là chiến lược di chuyển logic, trong đó chỉ dữ liệu thay đổi được lấy từ nguồn và áp dụng cho cơ sở dữ liệu đích theo logic. Trong suốt quá trình này, hệ thống nguồn vẫn sẵn sàng cho khối lượng công việc của ứng dụng. Chỉ cần một thời gian ngừng hoạt động ngắn để chuyển các ứng dụng sang cơ sở dữ liệu RDS của Oracle đích.

Nhìn chung, các phương pháp di chuyển vật lý hiệu quả hơn di chuyển logic đối với khối lượng dữ liệu lớn, nhưng chúng cần nhiều thời gian ngừng hoạt động hơn.

Giải pháp chúng tôi đề xuất kết hợp cả hai cách tiếp cận: RMAN Cross-Platform Transportable Tablespace Backup Sets cho toàn bộ dữ liệu và AWS DMS để đồng bộ dữ liệu tăng dần nhằm giảm thiểu thời downtime.

Tổng quan giải pháp

Như hình minh họa bên dưới, bằng cách chỉ sử dụng phương pháp XTTS, bạn có thể giảm thiểu đáng kể downtime vì cơ sở dữ liệu nguồn có thể mở ở chế độ đọc/ghi cho đến bản sao lưu (backup) tăng cường cuối cùng yêu cầu không gian bảng ở chế độ chỉ đọc (Bước D).

Dưới đây là các bước di chuyển chỉ sử dụng XTTS:

(A) Thiết lập cơ sở dữ liệu Oracle nguồn và đích trên RDS for Oracle.

(B) Backup toàn bộ dữ liệu (Level = 0) trên điểm nguồn và phục hồi trên điểm đích.

(C) Thực hiện backup tăng cường trên điểm nguồn và phục hồi trên điểm đích. Lặp lại bước này cho đến khi bạn sẵn sàng chuyển không gian bảng sang chế độ chỉ đọc trên cơ sở dữ liệu nguồn. 

(D) Chuyển không gian bảng sang chế độ chỉ đọc trên  điểm nguồn, backup  gia tăng lần cuối và xuất siêu dữ liệu bằng Oracle Data Pump. 

(E) Phục hồi bản backup  gia tăng cuối cùng trên đích và nhập các đối tượng siêu dữ liệu bằng Oracle Data Pump. Chuyển không gian bảng sang chế độ đọc/ghi trên cơ sở dữ liệu đích RDS cho Oracle.

Trong khoảng thời gian ngừng hoạt động (Bước D và E), việc nhập siêu dữ liệu (Bước E) thường tốn nhiều thời gian hơn. Do nhập siêu dữ liệu là hoạt động đơn luồng, thời gian nhập tỷ lệ thuận với số lượng đối tượng siêu dữ liệu.

Bạn có thể giảm thiểu thêm thời gian ngừng hoạt động bằng cách kết hợp AWS DMS với phương pháp XTTS, như được minh họa trong hình tiếp theo. Trong cách tiếp cận này, trên cơ sở dữ liệu nguồn, chúng ta đưa không gian bảng trở lại chế độ đọc/ghi ngay sau khi xuất hoàn tất. Kể từ thời điểm đó, chúng ta di chuyển dữ liệu bằng AWS DMS.

Các bước để di chuyển dữ liệu sử dụng XTTS và AWS DMS được mô tả như sau (Các bước A đến D và Bước E giống với kiến trúc trước đó):

(A) Thiết lập cơ sở dữ liệu Oracle nguồn và đích trên dịch vụ Amazon RDS for Oracle.

(B) Backup  đầy đủ (Level = 0) trên nguồn và khôi phục trên đích.

(C) Backup tăng cường trên nguồn và khôi phục trên đích. Đây là quá trình lặp lại cho đến khi bạn sẵn sàng chuyển tablespace sang chế độ chỉ đọc trên cơ sở dữ liệu nguồn.

(D) Đặt tablespace thành chỉ đọc trên nguồn, backup tăng cường cuối cùng và hoàn thành xuất siêu dữ liệu thông qua Oracle Data Pump.

(X) Ghi lại SCN từ cơ sở dữ liệu nguồn, cần thiết để sao chép các thay đổi đang diễn ra thông qua AWS DMS. Chuyển tablespace trên nguồn sang chế độ đọc/ghi.

(E) Khôi phục bản backup tăng cường cuối cùng trên đích và nhập các đối tượng siêu dữ liệu bằng Oracle Data Pump. Chuyển trạng thái của tablespace sang đọc/ghi trên cơ sở dữ liệu đích Amazon RDS cho Oracle.

(Y) Cấu hình AWS DMS để sao chép các thay đổi đang diễn ra từ SCN được ghi lại ở Bước X.

(Z) Thực hiện ngắt kết nối ngắn để chuyển đổi sang cơ sở dữ liệu sản xuất trên Amazon RDS cho Oracle.

Bài viết Amazon RDS for Oracle Transportable Tablespaces using RMAN cung cấp tất cả các chi tiết để thiết lập, cấu hình và di chuyển dữ liệu sang Amazon RDS for Oracle thông qua tablespace di động sử dụng RMAN. Chúng tôi không đề cập đến các chi tiết tương tự trong bài viết này; thay vào đó, chúng tôi tập trung vào cách bạn có thể tích hợp AWS DMS để thực hiện di chuyển dữ liệu với thời gian downtime gần như bằng 0.

Các bước sau đây được thực hiện cho mục đích thử nghiệm, do đó tên tablespace và bảng được đặt cho phù hợp. Đối với việc di chuyển cơ sở dữ liệu thực tế, bạn phải cập nhật chúng theo môi trường cơ sở dữ liệu nguồn hiện tại của mình.

Chuẩn bị

Trước khi bắt đầu di chuyển dữ liệu, bạn cần đáp ứng các điều kiện tiên quyết sau:

Bạn phải có một cơ sở dữ liệu Oracle nguồn đang chạy trên môi trường on-premises hoặc Amazon Elastic Compute Cloud (Amazon EC2) hiện có.

Bạn cần có một cơ sở dữ liệu đích Amazon RDS for Oracle.

Bạn cần có Amazon Elastic File System (Amazon EFS) được gắn kết với cả cơ sở dữ liệu nguồn và Amazon RDS Oracle đích. Tham khảo tài liệu về tích hợp Amazon EFS để biết thêm chi tiết.

Cài đặt Oracle làm cơ sở dữ liệu nguồn để AWS DMS thu thập thay đổi dữ liệu (CDC).

Liệt kê các file dữ liệu trên cơ sở dữ liệu nguồn và ghi chú lại.

Đảm bảo cơ sở dữ liệu đích có cùng bộ ký tự với cơ sở dữ liệu nguồn.

Nếu có bất kỳ đối tượng nào trong tablespace SYSTEM, hãy di chuyển chúng sang một tablespace khác để sử dụng TTS.

Xác định các tablespace cần di chuyển sang cơ sở dữ liệu đích (cụ thể là bất kỳ tablespace nào chứa các đối tượng dữ liệu thực tế cần thiết cho việc di chuyển).

Đảm bảo các tablespace được chọn là độc lập và không bật tính năng TDE (Transparent Data Encryption).

Tạo các schema cần thiết cho tablespace di chuyển mong muốn trong cơ sở dữ liệu đích nhưng chưa chứa đối tượng.

Ví dụ về cơ sở hạ tầng

Đối với bài viết này, chúng tôi sử dụng cơ sở hạ tầng sau:

  • Cơ sở dữ liệu nguồn – 19c trên EC2 (Oracle Linux – r5.2xlarge)
  • Cơ sở dữ liệu đích – RDS for Oracle 19c (db.r5.2xlarge)

Thiết lập cơ sở dữ liệu nguồn

Thực hiện các bước sau để chuẩn bị cơ sở dữ liệu nguồn:

  1. Tạo tablespace để di chuyển bằng XTTS:
SQL> create tablespace XTTDMS datafile ‘/u01/oradata/ORCLOEM/xttdms_1.dbf’ size 100M autoextend on next 128M maxsize 200M;
  1. Đảm bảo người sử dụng cơ sở dữ liệu có đủ quyền để viết vào tablespace:
SQL> alter user dms_sample quota unlimited on XTTDMS;
  1. Tạo bảng trong tablespace:
SQL> create table dms_sample.tablextts (a int primary key, b varchar2(20)) tablespace XTTDMS;
  1. Chèn dữ liệu mẫu vào bảng:
SQL> insert into dms_sample.tablextts values (1,’Before_Level-0′);

Backup dữ liệu toàn phần trên cơ sở dữ liệu nguồn

Thực hiện các bước sau để backup tablespace di chuyển mức độ 0 (Level 0) từ cơ sở dữ liệu nguồn bằng XTTS:

  1. Cập nhật tên tablespace trong file `xtts.properties`:
#linux systemplatformid=13#list of tablespaces to transporttablespaces= XTTDMS#location where backup will be generatedsrc_scratch_location=/mnt/efs/fs1/datapump1/xtt/xtts_scratch#RMAN command for performing backup#This should be set if using 12c or higher.usermantransport=1

Khởi tạo backup Level 0 sử dụng xtts script:

cd /mnt/efs/fs1/datapump1/xttexport TMPDIR=/mnt/efs/fs1/datapump1/xtt/xtts_tmp$ORACLE_HOME/perl/bin/perl xttdriver.pl –backup –debug 3

Chạy script xtts để tạo bản backup  `mức độ 0` ban đầu. Script này thông minh ở chỗ nó sẽ tự kiểm tra xem có bất kỳ bản backup  nào trước đó cho tablespace này không. Nếu chưa có, script sẽ tự động khởi tạo một bản backup mức độ 0. Quá trình này cũng được ghi lại trong file log chi tiết.

Recovery Manager: Release 19.0.0.0.0 – Production on Mon Dec 4 01:06:54 2023Version 19.3.0.0.0Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.RMAN-06005: connected to target database: ORCLOEM (DBID=3703663678)RMAN> #PLAN:XTTDMS::::134297692> backup for transport allow inconsistent incremental level 0 datafile3> #NEWDESTDF:14,/XTTDMS_14.dbf4> 145> #PLAN:146> format ‘/mnt/efs/fs1/datapump1/xtt/xtts_scratch/%N_%f_%U.bkp’;7>
RMAN-03090: Starting backup at 04-DEC-23RMAN-06009: using target database control file instead of recovery catalogRMAN-08030: allocated channel: ORA_DISK_1RMAN-08500: channel ORA_DISK_1: SID=383 device type=DISKRMAN-08048: channel ORA_DISK_1: starting incremental level 0 datafile backup setRMAN-08010: channel ORA_DISK_1: specifying datafile(s) in backup setRMAN-08522: input datafile file number=00014 name=/u01/oradata/ORCLOEM/xttdms_1.dbf
RMAN-08038: channel ORA_DISK_1: starting piece 1 at 04-DEC-23RMAN-08044: channel ORA_DISK_1: finished piece 1 at 04-DEC-23RMAN-08530: piece handle=/mnt/efs/fs1/datapump1/xtt/xtts_scratch/XTTDMS_14_1c2d57dg_1_1.bkp tag=TAG20231204T010656 comment=NONERMAN-08540: channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01RMAN-03091: Finished backup at 04-DEC-23Recovery Manager complete.

Script backup  này cũng tạo ra một tệp `res.txt` trong tập tin tạm chú thích tên của tệp so lưu cấp 0 và SCN. Tệp Res.txt trong giống dòng lệnh sau:

#0:::14,13,XTTDMS_14_1c2d57dg_1_1.bkp,0,13429769,0,0,0,XTTDMS,XTTDMS_14.dbf

3. Sao chép `res.txt` tới cùng vị trí (/mnt/efs/fs1/datapump1/xtt/xtts_scratch/) nơi tệp backup  được tạo ra:

cp /mnt/efs/fs1/datapump1/xtt/xtts_tmp/res.txt /mnt/efs/fs1/datapump1/xtt/xtts_scratch/

4. Đảm bảo quyền của tệp được chỉnh thành 777 trong tệp backup cũng như là tệp res.txt :

Bản backup  được lưu trữ trên một thư mục được tạo trên Amazon EFS. Hệ thống file EFS này cũng được gắn kết với Amazon RDS for Oracle, do đó bạn không cần sao chép thủ công file backup  giữa các máy chủ. Điều này giúp giảm thiểu chi phí truyền dữ liệu giữa máy chủ cơ sở dữ liệu nguồn và đích.

Khôi phục bản backup tới cơ sở dữ liệu đích

 Hoàn thiện các bước sau để phục hồi bản backup tới cơ sở dữ liệu RDS dành cho Oracle sử dụng XTTS:

  1. Cập nhật tên tablespaces và chạy script sau trên cơ sở dữ liệu RDS gốc để hoàn thành backup Level 0:
VAR task_id CLOB BEGIN :task_id:=rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces(‘XTTDMS’,’DATA_PUMP_DIR_XTTS’, p_platform_id =>13);END; / 
PRINT task_id
  1. Ghi chú lại TASK_ID.
  2. Kiểm tra trạng thái tác vụ để đảm bảo không có lỗi nào xảy ra khi chạy lệnh khôi phục trên RDS đích cho cơ sở dữ liệu Oracle. (Không cần dịch các thuật ngữ chuyên ngành như RDS, Oracle).
SELECT * FROM rdsadmin.rds_xtts_operation_info where xtts_job_name = ‘1701652158158-651’ order by xtts_operation_end_utc;

Khi lệnh khôi phục hoàn thành thành công, trạng thái của cột XTTS_OPERATION_STATE sẽ hiển thị là HOÀN THÀNH (COMPLETED). Trong trường hợp gặp bất kỳ lỗi nào, cột này sẽ được cập nhật thành THẤT BẠI (FAILED).

Để xác định lý do của sự thất bại, một tệp tin (FAILED) sẽ được tạo trong cùng thư mục với đường dẫn tệp vật lý trên Amazon EFS. Bạn cần kiểm tra lý do thất bại và khắc phục sự cố trước khi chạy lại lệnh khôi phục (restore).

Bạn sẽ không thể nhìn thấy bất kỳ tablespace hoặc dữ liệu nào trên RDS đích cho cơ sở dữ liệu Oracle cho đến khi bản backup metadata được khôi phục. Ở giai đoạn này, bản backup  Level 0 đã được khôi phục thành công trên RDS đích cho cơ sở dữ liệu Oracle.

  1. Bạn có thể chèn một vài bản ghi trước khi bắt đầu backup  Level 1. Hoặc bạn có thể tiếp tục các hoạt động thông thường trên cơ sở dữ liệu nguồn cho đến khi bạn sẵn sàng bắt đầu backup  tăng cường Level 1 tiếp theo.
SQL> insert into dms_sample.tablextts values (2,’Before_Level-1′);

Backup tăng cường trên cơ sở dữ liệu nguồn

Bạn cần chạy lại script Perl XTTS. Script này tự động nhận diện bản backup Mức 0 (đã được thực hiện) và bắt đầu một bản backup Mức 1. Sau đó, bạn có thể chạy thêm nhiều bản backup Mức 1 tùy ý, XTTS sẽ kiểm tra tính toàn vẹn của dữ liệu. Quan trọng là nhớ sao chép file res.txt mới nhất vào thư mục EFS đích sau mỗi lần backup tăng cường.

Khôi phục bản backup gia tăng trên cơ sở dữ liệu đích

Hoàn thành các bước sau để khôi phục bản backup Mức 1 lên RDS Oracle đích sử dụng XTTS

  1. Cập nhật tên Tablespace và chạy script phục hồi trên RDS Oracle đích để phục hồi backup  Level 0:
VAR task_id CLOB BEGIN :task_id:=rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces(‘XTTDMS’,’DATA_PUMP_DIR_XTTS’); END;/ PRINT task_id
  1. Ghi chú lại  TASK_ID .
  2. Kiểm tra trạng thái của tác vụ để đảm bảo không có lỗi xảy ra khi chạy lệnh phục hồi trên cơ sở RDS Oracle đích.
SELECT * FROM rdsadmin.rds_xtts_operation_info where xtts_job_name = ‘1701652640394-651’ order by xtts_operation_end_utc;

Thư mục backup giống trên (/mnt/efs/fs1/datapump1/xtt/xtts_scratch) sẽ có một tệp gọi là xttnewdatafiles.txt để ghi chú lại vị trí của tệp dữ liệu sẽ được tạo ra ở Amazon RDS cho Oracle. Nội dung của file giống như đoạn mã sau:

14,/rdsdbdata/db/ORCL_A/datafile//XTTDMS_14.dbf

Đoạn mã trên có thông tin về tất cả các tệp dữ liệu của tablespaces và bao gồm trong tệp xtts.properties

  1. Sao chép tệp này tới cùng vị trí nơi siêu dữ liệu backup  được xuất ra.:
cd /mnt/efs/fs1/datapump1/xtt/xtts_scratchcp xttnewdatafiles.txt /mnt/efs/fs1/datapump1/

Điều này chỉ cần thiết khi siêu dữ liệu backup và thư mục backup  sử dụng XTTS khác nhau. Nếu bạn tạo siêu dữ liệu backup  trong cùng một thư mục với bản backup vật lý, bước này không cần thiết.

  1. Đảm bảo rằng tệp chứa siêu dữ liệu backup  và xttnewdatafiles.txt có quyền 777 :
cd /mnt/efs/fs1/datapump1/chmod 777 xttdump.dmpchmod 777 xttnewdatafiles.txt

Khôi phục bản backup cuối cùng trên cơ sở dữ liệu đích

Khoảng downtime của hệ thống bắt đầu tại đây. Hoàn thành các bước sau đây để khôi phục bản backup  Level 1 cuối cùng trên RDS cho Oracle đích sử dụng XTTS:

  1. Đặt các tablespaces ( để di chuyển đi) trong chế độ chỉ đọc:
SQL> alter tablespace XTTDMS read only;
  1. Chạy script để hoàn thiện backup  Level 1:
cd /mnt/efs/fs1/datapump1/xttexport TMPDIR=/mnt/efs/fs1/datapump1/xtt/xtts_tmp$ORACLE_HOME/perl/bin/perl xttdriver.pl –backup –debug 3

Script này phát hiện bản backup Level 0 và chỉ bắt đầu một lần backup tăng cường. Một lần chạy backup thành công thường có script như thế này:

Recovery Manager: Release 19.0.0.0.0 – Production on Mon Dec 4 01:12:08 2023
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
RMAN-06005: connected to target database: ORCLOEM (DBID=3703663678)RMAN> set nocfau;2> host ‘echo ts::XTTDMS’;3> backup incremental from scn 134297694> tablespace ‘XTTDMS’ format5> ‘/mnt/efs/fs1/datapump1/xtt/xtts_scratch/%U’;6>RMAN-03023: executing command: SET NOCFAURMAN-06009: using target database control file instead of recovery catalog

Một script bắt đầu backup tăng cường từ SCN từ lần backup cuối cùng:

/ as sysdbasize of tablespace 8No. of tablespaces per batch 1TABLESPACE STRING :’XTTDMS’Prepare newscn for Tablespaces: ‘XTTDMS’DECLARE*ERROR at line 1:ORA-20001: TABLESPACE(S) IS READONLY OR,OFFLINE JUST CONVERT, COPYORA-06512: at line 284
####################################################################Warning:——Warnings found in executing /mnt/efs/fs1/datapump1/xtt/xtts_tmp/backup_Dec4_Mon_01_11_20_659//xttpreparenextiter.sql####################################################################DECLARE*ERROR at line 1:ORA-20001: TABLESPACE(S) IS READONLY OR,OFFLINE JUST CONVERT, COPYORA-06512: at line 284TABLESPACE STRING :”””””””Prepare newscn for Tablespaces: ”””””””
New /mnt/efs/fs1/datapump1/xtt/xtts_tmp/xttplan.txt with FROM SCN’s generated

Sẽ có cảnh báo trong bước backup tăng cường cuối dùng bởi vì tablespaces trong chế độ chỉ đọc. Điều này thể hiện rằng dữ liệu chúng ta đang có là thống nhất.

Script backup sẽ ghi chèn thông tin bảng backup Level 1  trong cùng tệp res.txt và một dòng mới sẽ được thêm vào cùng một tệp với tên tập tin được tạo ra bởi Level 1 cũng như là SCN mới:

#0:::14,13,XTTDMS_14_1c2d57dg_1_1.bkp,0,13429769,0,0,0,XTTDMS,XTTDMS_14.dbf#1:::14,13,1e2d57nb_1_1,13429769,13431017,0,0,0,XTTDMS_14.dbf,XTTDMS_14.dbf
  1. Sao chép res.txt  tới cùng vị trí (/mnt/efs/fs1/datapump1/xtt/xtts_scratch/) nơi tệp backup được tạo ra:
cp /mnt/efs/fs1/datapump1/xtt/xtts_tmp/res.txt /mnt/efs/fs1/datapump1/xtt/xtts_scratch/
  1. Đảm bảo quyền được chỉnh thành 777 cho tệp backup  cũng như res.txt:
cd /mnt/efs/fs1/datapump1/xtt/xtts_scratchchmod 777 *
  1. Thu lại thông tin SCN. Điều này là cần thiết cho AWS DMS để bắt đầu tái bản các thay đổi từ thời điểm đó đến cơ sở dữ liệu RDS cho Oracle đích.
more /mnt/efs/fs1/datapump1/xtt/xtts_tmp/xttplan.txtXTTDMS::::1343101714
  1. Xuất siêu dữ liệu backup từ cơ sở dữ liệu nguồn:

Cũng giống như bản backup của Data Pump, nó được thực hiện trên một thư mục được gắn kết trên Amazon EFS. Do Amazon RDS for Oracle sử dụng cùng thư mục EFS đó, nên không cần sao chép các file backup từ máy chủ cơ sở dữ liệu nguồn sang máy chủ đích.

  1. Đặt tablespaces trong chế độ đọc/ghi:
alter tablespace XTTDMS read write;

Đến giai đoạn này,downtime đã kết thúc. Cơ sở dữ liệu gốc hiện đã hoạt động và sẵn sàng cho các hoạt động từ ứng dụng của bất kỳ người dùng nào.Nếu bạn không sử dụng AWS DMS, thời gian ngừng hoạt động sẽ tiếp tục cho đến khi bản backup Level 1 được khôi phục và việc nhập siêu dữ liệu Data Pump hoàn tất.

  1. Lúc này bạn có thể tiếp tục các hoạt động cơ sở dữ liệu thông thường trên cơ sở dữ liệu gốc. Hiện tại, tất cả các bản ghi trong giai đoạn này sẽ không khả dụng trong bản backup Level 1và chỉ được quản lý bởi AWS DMS.
SQL> insert into dms_sample.tablextts values (3, ‘After_Level-1′);SQL> insert into dms_sample.tablextts values (4,’Before_DMS’);

Nhập các siêu dữ liệu của tablespace có thể chuyển dời

Hoàn thành các bước sao để để nhập các đối tượng siêu dữ liệu:

  1. Phục hồi các backup siêu dữ liệu để backup  trên máy chứa cơ sở dữ liệu RDS cho Oracle
exec rdsadmin.rdsadmin_transport_util.import_xtts_metadata(‘xttdump.dmp’,’DATA_PUMP_DIR_EFS’);


Khôi phục bản backup siêu dữ liệu có thể mất thời gian tùy thuộc vào số lượng đối tượng cần khôi phục. Sau khi hoàn tất, bạn sẽ thấy thông báo “PL/SQL procedure successfully completed” (Thủ tục PL/SQL đã hoàn thành thành công). Tuy nhiên, điều này không nhất thiết có nghĩa là công việc đã hoàn thành suôn sẻ.

Để xác minh việc nhập khẩu hoàn tất thành công và không có lỗi, bạn có thể kiểm tra nội dung của log nhập siêu dữ liệu Data Pump:

SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file(p_directory => ‘DATA_PUMP_DIR_EFS’,p_filename => ‘tts_export.log’));

Sau khi nhập siêu dữ liệu thành công, bạn sẽ thấy tablespace trên RDS đích cho cơ sở dữ liệu Oracle ở chế độ chỉ đọc. Vùng dữ liệu này là ảnh chụp nhất quán của bản backup được lấy từ cơ sở dữ liệu gốc. Trong giai đoạn đó, vùng dữ liệu cũng ở chế độ chỉ đọc trong cơ sở dữ liệu gốc.

3. Để xác nhận rằng vùng dữ liệu trên cơ sở dữ liệu đích có cùng dữ liệu với cơ sở dữ liệu gốc, hãy chuyển vùng dữ liệu sang chế độ đọc/ghi trên RDS đích cho phiên bản Oracle.

alter tablespace XTTDMS read write;

Tái tạo các thay đổi sử dụng AWS DMS

Ở thời điểm này, cơ sở dữ liệu đích của bạn có một bản sao của dữ liệu từ cơ sở dữ liệu gốc được chụp lại trước khi chuyển vùng dữ liệu sang chế độ chỉ đọc. Tất cả các giao dịch xảy ra sau thời điểm đó sẽ không có trong cơ sở dữ liệu đích và sẽ được nhân bản bởi AWS DMS.

Ví dụ, trong môi trường thử nghiệm của chúng tôi, dữ liệu trong cơ sở dữ liệu nguồn và đích trông giống như các ảnh chụp màn hình sau.

Cơ sở dữ liệu nguồn:

Cơ sở dữ liệu đích:

Xem qua dữ liệu này, chúng ta có thể xác minh rằng cơ sở dữ liệu đích chỉ có các bản ghi được chèn trước khi backup Level 1 trên cơ sở dữ liệu gốc. Tất cả các bản ghi sau đó đều bị thiếu và cần được nhân bản.

Do AWS DMS cho phép bạn bắt đầu nhân bản các thay đổi từ điểm bắt đầu CDC (Change Data Capture – Thu thập Dữ liệu Thay đổi), bạn có thể sử dụng nó để nhân bản các thay đổi đang diễn ra. Bạn cần sử dụng SCN (System Change Number – Số Thay đổi Hệ thống) mà bạn đã ghi lại như một phần của bản backup Level 1 cuối cùng từ cơ sở dữ liệu gốc.

Để bắt đầu tạo nhân bản bằng AWS DMS, hãy thực hiện các bước sau:

  1. Tạo một phiên bản nhân bản (replication instance).
  2. Tạo các điểm cuối nguồn và đích (source and target endpoints).
  3. Kiểm tra xem mạng phiên bản nhân bản AWS DMS được thiết lập chính xác và có thể kết nối với cơ sở dữ liệu nguồn và đích của bạn.
  4. Tạo tác vụ nhân bản AWS DMS, tác vụ này sẽ nhân bản các thay đổi đang diễn ra. Dưới đây là các cài đặt quan trọng trong quá trình tạo tác vụ:
  1. Kiểu di chuyển (Migration type): Chọn Chỉ nhân bản thay đổi dữ liệu (Replicate data changes only). Điều này sẽ chỉ nhân bản các thay đổi, giữ nguyên dữ liệu hiện có trên cơ sở dữ liệu đích.
  2. Bật chế độ bắt đầu CDC tùy chỉnh (Enable custom CDC start mode): Bật tùy chọn này để đảm bảo các thay đổi CDC được nhân bản từ một SCN cụ thể.
  3. Số thay đổi hệ thống (System Change Number): Nhập SCN bạn đã ghi lại trước đó. Để đảm bảo tính nhất quán của dữ liệu, bạn sử dụng SCN được tạo sau bản backup Level 1.
  4. Chế độ chuẩn bị bảng đích (Target table preparation mode): Chọn Không làm gì (Do nothing). Điều này xác nhận rằng các bảng trên cơ sở dữ liệu đích sẽ được giữ nguyên và chỉ dữ liệu được nhân bản.
  5. Ánh xạ bảng (Table mappings): Chỉ định tên schema và tên bảng mà bạn muốn AWS DMS nhân bản các thay đổi đang diễn ra.
  6. Khởi động lại (Restart): Chọn Khởi động lại để đảm bảo các thay đổi được bắt đầu từ đầu SCN mà bạn đã chỉ định.

Sau khi tác vụ được khởi động lại, nó sẽ bắt đầu nhân bản các thay đổi và trạng thái của tác vụ sẽ hiển thị là Nhân bản đang diễn ra (Replication ongoing).

Ban có thể mở các tác vụ để có thêm thông tin và xác nhận nếu bạn có thể thấy các thay đổi được nhân bản trong cơ sở dữ liệu đích.

Cuối cùng, bạn có thể so sánh các bản ghi trong cơ sở dữ liệu gốc để xác nhận chúng đồng bộ với cơ sở dữ liệu nguồn như là trong hai ảnh chụp dưới đây.

Cơ sở dữ liệu nguồn

Cơ sở dữ liệu đích:

Dọn dẹp

Để tránh phát sinh các khoản phí trong tương lai, hãy hoàn thành các bước sau:

  1. Dừng phiên bản EC2 (nếu cơ sở dữ liệu Oracle gốc của bạn được triển khai trên phiên bản đó).
  2. Xóa phiên bản RDS for Oracle.
  3. Xóa hệ thống tệp EFS.
  4. Xóa tất cả các tác vụ nhân bản AWS DMS mà bạn đã tạo trước khi xóa phiên bản nhân bản AWS DMS.

Kết luận

Trong bài viết này, chúng ta đã tìm hiểu về việc di chuyển cơ sở dữ liệu Oracle sang Amazon RDS for Oracle. Với cách tiếp cận kết hợp RMAN XTTS để tải dữ liệu lớn và AWS DMS cho các thay đổi đang diễn ra, bạn có thể giảm thiểu đáng kể thời gian ngừng hoạt động cần thiết.

Bằng cách lên kế hoạch cẩn thận, các tổ chức có thể di chuyển khối lượng công việc Oracle của họ sang Amazon RDS for Oracle và tận dụng sự linh hoạt, khả năng mở rộng và tính sáng tạo của AWS. Tùy chọn di chuyển này cho phép bạn hiện đại hóa môi trường Oracle theo lịch trình riêng của mình.

Hãy thử cách tiếp cận này trong lần di chuyển cơ sở dữ liệu Oracle tiếp theo của bạn sang Amazon RDS for Oracle. Nếu bạn có bất kỳ bình luận hoặc câu hỏi nào, hãy để lại trong phần bình luận.

←
→

Leave a comment