오라클 DB를 AWS 데이터베이스로 마이그레이션 하기 - 윤기원 :: AWS Database Modernization Day 온라인

Database Modernization Day
Oracle to Aurora MySQL
Hands-On Lab
Aug, 2020
Kiwon Yoon
Amazon Web Services

AWS Migration Immersion DAY(HOL)
Copyright 2018, Amazon Web Services, All Right Reserved Page 2
Table of Contents
1. Overview ............................................................................................................................................. 3
2. 목표 구성도 및 작업 순서 ..................................................................................................................... 4
3. KeyPair 생성 ........................................................................................................................................ 6
4. VPC 생성 (OnPrem VPC & AWSDC VPC)...........................................................................................7
5. OnPREM 1 AWSDC VPC Connectivity 확인....................................................................................12
6. VPC Peering 생성 (OnPREM VPC 1 AWSDC VPC).........................................................................13
7. Routing Table 수정 ............................................................................................................................15
8. OnPREM 1 AWSDC VPC Connectivity 확인 (2).............................................................................20
9. OnPREM-TOMCAT 의 JSP Connection String 수정 ........................................................................21
10. AWSDC 에서 신규 Aurora Instance 생성.......................................................................................... 23
11. SCT 를 이용한 DB Schema 변환........................................................................................................ 25
12. OnPREM Oracle 선행 작업................................................................................................................36
13. DMS 를 사용한 Oracle Data Migration ............................................................................................40
14. OnPREM-Tomcat 의 Connection String 수정..................................................................................55
15. soe schema 초기화 작업-1.................................................................................................................57
16. DB 마이그레이션 속도에 영향을 주는 요소 확인 ...............................................................................60
a. Case 1 – Load Parallel = 2 & No Index .............................................................................................61
b. Case 2 – Load Parallel = 16 & No Index..........................................................................................68
17. 마이그레이션 성능 점검을 위한 테이블 인덱스 생성 ......................................................................... 74
a. Case 3 – Load Parallel = 2 & with Index......................................................................................... 76
b. Case 4 – Load Parallel = 16 & with Index.......................................................................................82
18. soe schema 초기화 작업-Iterate ......................................................................................................89
19. OnPREM Oracle CPU & Network Utilization..................................................................................94
Appendix – Resource 삭제........................................................................................................................ 95

1. Overview
Cloud 환경으로 데이터 센터를 마이그레이션 할 때 고객이 가장 큰 부담을 느끼는 부분은 Database
Migration 입니다. Database 마이그레이션이 잘못될 경우 데이터 유실 등의 이유로 비지니스에
악영향을 미칠 수 있기 때문입니다. 대다수의 온-프레미스 데이터센터에서는 기능 및 성능 측면의
이유로 또는 (그리고) 유지보수의 편의성의 이유로 상용 데이터베이스를 많이 사용하고 있고, 이중
가장 많이 사용하는 것은 Oracle 입니다. 온-프레미스 데이터 센터의 데이터베이스르 클라우드 상의
오픈소스 데이터베이스로 마이그레이션을 할 경우 고객은 ROI(Return On Investment)를 높일 수
있고, 상용 라이센스 관리 부담에서 벗어날 수 있습니다.
본 실습에서는 OnPREM Oracle 환경을 가상으로 만들고, Schema Conversion Tool(SCT)과
Database Migration Service(DMS)를 이용하여 Amazon Aurora MySQL 로 Migration 을
수행합니다.
Migration 속도에 영향을 끼치는 다양한 요소들 중 PARALLEL Load Count 와 Index 가 Migration
속도에 얼마나 영향을 주는지 확인 합니다.
OnPREM ßà AWS 환경을 Simulation 하기 위하여 VPC Peering 을 사용하여 유사하게
구성합니다.
본 Lab 은 아래의 내용을 포함하고 있습니다.
• CloudFormation 을 사용하여 VPC 및 Network 환경 구성
• TOMCAT on EC2, ORACLE on EC2, Windows on EC2 를 AMI 를 이용하여 구성
• System Manager 의 Session Manager 를 이용하여 EC2 에 ACCESS
• SCT 를 이용하여 ORACLE on OnPREM 의 SCHEMA 및 Stored Procedure 등을 Aurora
MySQL 로 이관 합니다.
• DMS 를 사용하여 ORACLE on OnPREM 의 Data 를 Aurora MySQL 로 이관 합니다.
• 인스턴스 삭제 방법 (Hands on Lab 종료 후 꼭 삭제를 하셔야지 과금 되지 않습니다!!!!!)
본 LAB 은 Seoul Region 을 선택하셔서 진행하셔야 합니다.

2. 목표 구성도 및 작업 순서
OnPREM VPC(10.100.0.0/16) 과 AWSDC VPC(10.200.0.0/16) 은 VPC Peering 연결을 통해
가상의 전용망(Direct Connect)처럼 동작 합니다.
CloudFormation 을 이용하여 OnPREM VPC 에 ORACLE 11g, TOMCAT8, Windows2019 를
생성합니다.
Windows Server 에 RDP(mstsc.exe)를 이용하여 접속하여 “Schema Conversion Tool”, “MySQL
Workbench”, “SQL Developer for Oracle”을 사용하여 작업 합니다.

OnPREM TOMCAT8 은 OnPREM Oracle 을 repository target 으로 사용 중이며, Aurora
MySQL 로 Migration 후에는 repository target 을 Aurora MySQL 로 변경합니다.
전체적인 Handson Lab 의 순서는 다음과 같습니다.
1. Key Pair 생성
2. CloudFormation 을 사용하여 OnPREM VPC 와 Oracle, Tomcat, windows EC2 를 생성
3. CloudFormation 을 사용하여 AWSDC VPC 를 생성
4. OnPREM VPC 와 AWSDC VPC 간의 연결을 위해 VPC Peering 생성
5. OnPREM Tomcat 을 OnPREM Oracle 과 연결하여 정상 동작 확인
6. Migration Target 이 될 Aurora MySQL 을 생성
7. OnPREM Oracle 의 OSHOP SCHEMA 를 SCT 를 이용하여 Aurora MySQL 로 이관
8. Data Full Load & CDC 를 위한 OnPREM Oracle 사전 작업 수행
9. OnPREM Tomcat 을 AWSDC Aurora MySQL 과 연결하여 정상 동작 확인
10. Load Parallel 개수와 Index 생성 유무에 따른 Migration 속도 변화 확인

3. KeyPair 생성
이 과정에서는 EC2 Instance 접속 등에 사용 할 Key Pair 를 생성 합니다.(실제 대부분의 접속은 Key
Pair 를 이용한 SSH 접속이 아닌, Session Manager 를 이용한 방식을 사용합니다. Session Manager
이용이 불가능 할 경우 생성한 Key Pair 를 이용하여 SSH Client 로 EC2 에 접속합니다.
1. Services -> EC2 선택
2. 화면 좌측의 “Key Pairs” Click
3. “Create key pair” Click
4. Name : id_rsa_main 입력 후 “Create key pair” click
5. 자동으로 pem key 가 다운로드 됩니다. 해당 파일은 EC2 접속을 할 수 있는 중요한 key
파일입니다. 파일 퍼미션을 400 으로 변경 후, 안전한 곳에 파일을 저장합니다.

4. VPC 생성 (OnPrem VPC & AWSDC VPC)
이 과정에서는 OnPREM 환경에 해당하는 OnPREM VPC 와 AWS 환경에 해당하는 AWSDC VPC 를
CloudFormation 을 이용하여 생성합니다.
참고 -------------------------------------------------
OnPrem VPC :
ONPREM-VPC 10.100.0.0/16
ONPREM-PUBLIC-SUBNET1 10.100.1.0/24
ONPREM-PUBLIC-SUBNET2 10.100.2.0/24
ONPREM-PRIVATE-SUBNET1 10.100.101.0/24
ONPREM-PRIVATE-SUBNET2 10.100.102.0/24
AWS VPC :
AWSDC-VPC 10.100.0.0/16
AWSDC-PUBLIC-SUBNET1 10.200.1.0/24
AWSDC-PUBLIC-SUBNET2 10.200.2.0/24
AWSDC-PRIVATE-SUBNET1 10.200.101.0/24
AWSDC-PRIVATE-SUBNET2 10.200.102.0/24
1. Services -> CloudFormation 선택
2. OnPREM VPC 생성 을 위해 “Create Stack” Click
3. “Amazon S3 URL” 부분에
https://migration-hol-kiwony.s3.ap-northeast-2.amazonaws.com/OnPREM2.yml
를 입력하고 “Next” Click

4. Stack name: “OnPREM”을 입력
KeyName : id_rsa_main 을 선택
나머지는 Default 로 두고 “Next” Click
5. “Configure stack options”은 Default 로 두고 “Next” Click
6. “Review” Page 에서 “I acknowledge that AWS CloudFormation might create IAM resources
with custom names.”을 Check 하고, “Create Stack”을 Click 하여 CloudFormation 실행

7. Service -> CloudFormation 선택
8. AWSDC VPC 생성 을 위해 “Create Stack” Click
9. “Create Stack” Click
10. “Amazon S3 URL” 부분에
https://migration-hol-kiwony.s3.ap-northeast-2.amazonaws.com/AWSDC2.yml
를 입력하고 “Next” Click
11. Stack name: “AWSDC”를 입력
KeyName : id_rsa_main 을 선택
“Next” Click

12. “Configure stack options”는 Default 로 두고 “Next” Click
13. “Review” Page 에서 “I acknowledge that AWS CloudFormation might create IAM
resources.”를 Check 하고 “Create Stack”을 Click 하여 CloudFormation 실행
14. OnPREM Stack 과 AWSDC Stack 이 생성 완료 되는 것을 확인 (5~10 분)

15. Stack 이 완료되면 OnPREM Stack Outputs Tab 의 내용 중 OraclePrivateIP, TomcatPublicIP,
WindowsPublicIP 를 복사해둡니다. (IP 로 필터링하면 EC2 IP 만 아래처럼 확인 가능합니다.)
16. AWSDC Stack 이 완료되면 AWSDC Stack Outputs Tab 의 내용 중
AWSDCTomcatPrivateIP 를 복사해둡니다.

5. OnPREM 1 AWSDC VPC Connectivity 확인
OnPREM VPC 는 본 실습에서 고객의 Data Center 역할을 대신 합니다.
AWSDC VPC 는 AWS 상의 새로운 Infrastructure 입니다.
OnPREM VPC 와 AWSDC VPC 는 서로 다른 가상 네트워크 구간이기 때문에 현재 통신이 되지
않습니다. 다음의 과정을 통해 실제로 네트웍 연결이 되지 않는 것을 확인합니다.
1. Services -> EC2 -> Running Instances
2. OnPREM-Tomcat 을 선택 후 “Connect”를 Click 합니다.
3. Connect to your instance -> “Session Manager”를 선택 후 “Connect” Click
4. OnPREM-Tomcat 에서 AWSDC-Tomcat 으로 netcat 을 사용하여 네트웍 연결을
확인합니다.(AWSDC-Tomcat 의 IP 는 복사 해둔 AWSDC Stack Output 에서 확인 합니다.)
$ nc -vzw 10 <AWSDC-TOMCAT-PRIVATE-IP> 8080
5. 아래처럼 Timed Out 이 나면서 접속이 되지 않는 것을 확인합니다.

6. VPC Peering 생성 (OnPREM VPC 1 AWSDC VPC)
이 과정에서는 OnPREM VPC 와 AWSDC VPC 를 VPC Peering 으로 연결합니다. VPC Peering 을
생성하면 고객 Data Center 와 AWS VPC 간의 전용선연결(DirectConnect)을 Emulation 합니다.
1. Services -> VPC 로 이동
2. Menu 좌측에 “Peering Connections” Click
3. “Create Peering Connection” Click
4. “Create Peering Connection” 화면에서 아래처럼 입력
a. Peering connection name tag : OnPREM-to-AWSDC
b. VPC (Requester) : OnPREM VPC 선택
c. VPC (Accepter) : AWSDC VPC 선택

5. “Create Peering Connection”을 Click 하여 Peering Request 생성
6. “Peering Connections” Page 에서 방금 생성한 VPC Peering Entry 를 선택하고 Actions ->
“Accept Request” Click 후 “Yes, Accept” Click

7. Routing Table 수정
VPC Peering 을 통해 OnPREM VPC <-> AWSDC VPC 간의 가상 네트워크 연결을 완료했습니다.
이제 두 VPC 간의 Network Routing 을 위해 Routing Table 을 수정합니다.
7. Menu 좌측의 Route Tables 를 Click 하여 이동
8. OnPREM Public Routes 1 개와 OnPREM Private Routes 2 개를 수정합니다.
9. OnPREM Public Routes 를 선택
a. 화면 아래의 “Routes” Tab 으로 이동하여 “Edit routes”를 Click
b. “Add route”를 Click 후 다음 정보를 입력
i. Destination : 10.200.0.0/16
ii. Target 부분 Click 후 “Peering Connection” Click 후 생성했던 “OnPREM-
to-AWSDC” VPC Peering Connection 을 선택
iii. “Save Routes”를 Click

10. “OnPREM Private Routes (AZ1)” 와 “OnPREM Private Routes (AZ2)도 위의 2~3 Step 을
동일하게 수행하여 아래처럼 Routing Table 을 수정
n OnPREM Private Routes (AZ1)”

n OnPREM Private Routes (AZ2)”

11. AWSDC Public Routes (Routing Table) 1 개와 AWSDC Private Routes 2 개를 수정합니다.
12. AWSDC Public Routes 를 선택
a. 화면 아래의 “Routes” Tab 으로 이동하여 “Edit routes”를 Click
b. “Add route”를 Click 후 다음 정보를 입력
i. Destination : 10.100.0.0/16
ii. Target 부분 Click 후 “Peering Connection” Click 후 생성했던 “OnPREM-
to-AWSDC” VPC Peering Connection 을 선택
iii. “Save Routes”를 Click

13. “AWSDC Private Routes (AZ1)” 와 “AWSDC Private Routes (AZ2)도 위의 2~3 Step 을
동일하게 수행하여 아래처럼 Routing Table 을 수정
n AWSDC Private Routes (AZ1)”
n AWSDC Private Routes (AZ2)”

8.OnPREM 1 AWSDC VPC Connectivity 확인 (2)
OnPREM VPC 와 AWSDC VPC 간의 VPC Peering 과 Routing 설정을 완료하였습니다.
기존에 연결이 되지 않던 OnPREM-Tomcat -> AWSDC-Tomcat 의 연결을 다시 확인합니다.
1. Services -> EC2 -> Running Instances
2. OnPREM-Tomcat 을 선택 후 “Connect”를 Click 합니다.
1. Connect to your instance -> “Session Manager”를 선택 후 “Connect” Click
2. OnPREM-Tomcat 에서 AWSDC-Tomcat 으로 netcat 을 사용하여 네트웍 연결을
확인합니다.(AWSDC-Tomcat 의 IP 는 복사 해둔 AWSDC Stack Output 에서 확인 합니다.)
$ nc -vzw 10 <AWSDC-TOMCAT-PRIVATE-IP> 8080
3. 아래처럼 정상적으로 접속이 됨을 확인합니다. 이제 OnPREM VPC 와 AWSDC 는 VPC Peering
연결을 통해 가상의 전용망처럼 연결되어 있습니다.
OnPREM VPC 와 AWSDC VPC 간의 VPC Peering 과 Routing 설정을 완료하였습니다.

9. OnPREM-TOMCAT 의 JSP Connection String 수정
이 과정에서는 OnPREM Tomcat Instance JSP File 의 Connection String 을 설정하여 정상적으로
동작하는지 확인 합니다. OnPREM-Tomcat 의 DB Connection String 을 OnPREM-
OracleServer 의 Private IP 로 변경합니다.
1) Services -> EC2 -> Running Instances
2) OnPREM-Tomcat 을 선택 후 Session Manager 를 이용해서 접속 합니다.
(접속 방법은 7. OnPREM VPC 와 AWSDC VPC Connectivity 확인(2) 참고)
3) Terminal 접속 후 아래처럼 Command 수행
sh-4.2$ sudo su -
Last login: Thu Jul 16 07:03:32 UTC 2020 on pts/0
root@ip-10-100-1-193:/root# cd /var/lib/tomcat8/webapps/ROOT
root@ip-10-100-1-193:/var/lib/tomcat8/webapps/ROOT# cp oracle.jsp ~/.
root@ip-10-100-1-193:/var/lib/tomcat8/webapps/ROOT# vi oracle.jsp
oracle.jsp 를 vi 로 열고 아래처럼 DB_HOST_IP 를 “OnPREM stack OraclePrivateIP”의 IP 로 변경
root@ip-10-100-1-193:/var/lib/tomcat8/webapps/ROOT# diff ./oracle.jsp ~/oracle.jsp
24c24
< String DB_HOST_IP="10.100.101.128";
---
> String DB_HOST_IP="10.100.101.191";

4) OnPREM stack 의 TomcatPublicIP 를 확인하고 IP 를 복사 합니다.
5) Web Broswer 에서 http://<TomcatPublicIP>:8080/oracle.jsp 로 접속하여 정상 동작하는지
확인합니다.

10. AWSDC 에서 신규 Aurora Instance 생성
AWSDC 로 이전할 신규 Aurora MySQL Instance 를 생성합니다.
1. Services -> RDS 이동
2. “Create Database” Click
3. Choose a database creation method : “Standard Create”
4. “Engine options”
a. Engine type : Amazon Aurora
b. Edition : Amazon Aurora with MySQL compatibility
5. Version : Aurora (MySQL 5.7) 2.08.1
6. Templates : Dev/Test
7. Settings
a. DB Instance Identifier : AWSDC-Aurora
b. Master username : admin
c. Master password : Octank#1234
8. DB Instance size
a. Memory Optimized classes (includes r and x classes)
b. db.r5.2xlarge
9. Availability & durability : Don't create an Aurora Replica
10. Connectivity
a. Virtual Private Cloud(VPC) : AWSDC
b. Additional connectivity configuration
i. Subnet group : Create new DB Subnet Group
ii. Publicly accessible : No
c. VPC Security Group : Choose existing
d. Existing VPC security groups : AWSDC-AWSDCAuroraSecurityGroup-XXXXXXX
e. Availability zone : No preference
f. Database port : 3306
11. Database authentication : Password authentication
12. Additional configuration
a. Initial database name : soe
b. Enable Encryption : Uncheck

c. Enable Enhanced monitoring : Check
d. Granularity : 5sec
e. Log exports : Audit log, Error log, General log, Slow query log 모두 체크
13. “Create database” Click
14. Database 생성이 완료 되면 awsdc-aurora 를 Click 하여 Writer type 의 Endpoint 를 확인 후
기록해 둡니다. (이후 Schema Conversion 작업등에서 사용 예정)

11. SCT 를 이용한 DB Schema 변환
이 과정에서는 Schema Conversion Tool (SCT)를 사용하여 OnPREM Oracle 의 OSHOP
Schema 를 AWSDC Aurora MySQL 로 Migration 합니다.
1. OnPREM stack Outputs 의 WindowsPublicIP 를 확인합니다.
2. RDP Client(mstsc.exe)를 실행하고 Windows Server 에 접속
3. User name : administrator
4. Password : cm4&gFxSBN@E5AWW)gL@@wTJ=N(IoToo <= 공백이 없도록 주의하세요!!
5. “Shutdown Event Tracker” 경고창이 뜰 경우 “Cancel”을 누릅니다.
6. Task Bar 에서 AWS Schema Conversion Tool 을 실행합니다. (최초 실행 시 10~20 초 필요)
7. Check for updates 메시지 나오면 “Not Now” Click
8. File -> New Project 실행 후 아래 정보 입력
a. Project Name : OracleToAuroraMigration
b. Transactional database(OLTP)
c. Source database engine : Oracle
d. Target database engine : Amazon Aurora(MySQL Compatible)
e. “OK” Click
9. Menu 상단의 “Connect to Oracle” Click

10. “Connect to Oracle” 화면에서 아래 정보 입력
a. Server name : OnPREM stack Outputs 의 OraclePrivateIP 입력
b. Server Port : 1521
c. Oracle SID : salesdb
d. User name : system
e. Password : Octank#1234
f. “Store Password” Check
g. “Test Connection” Click
h. Potential Security Risk Ahead Message 에서 “Accept the risk and continue” Click

i. Oracle Driver Issue 발생 시 C:jdbcojdbc8.jar 를 선택
11. “Connection Successful Alert” 창에서 “OK” Click
12. “Connect to Oracle” 창에서 “OK” Click 후 화면 좌측에 Oracle Schema 보이는 것 확인

13. 메뉴 상단의 “Connect to Amazon Aurora(MySQL compatible)” Click 후 아래 정보 입력
a. Server name : awsdc-aurora 의 writer endpoint(9. AWSDC 에서 신규 Aurora
Instance 생성-Step 14 에서 확인)
b. Server Port : 3306
c. User name : admin
d. Password : Octank#1234
e. “Store password” Check
f. “Test Connection” Click
14. “Connection Successful Alert” 창에서 “OK” Click
15. “Connect to Amazon Aurora(MySQL compatible)” 창에서 “OK” Click
16. 화면 좌측에 Source Database 정보가, 우측에 Target Aurora Database 정보가 표시

17. File => “Save Project” 를 실행하여 Project 저장
18. 화면 좌측 OnPREM Oracle 에서 Schemas 를 Uncheck 하고, OSHOP 만 Check 합니다.

19. OSHOP 에 마우스 커서를 두고, 마우스 우클릭을 하고, Create Report 를 통해서 Oracle to
Aurora-MySQL Schema 변환 보고서를 생성합니다.
20.Report 를 확인합니다. 대부분의 Schema Object 들이 “Objects Automatically
converted”(SCT 에서 자동으로 Schema 적용 가능) 상태입니다. Code Objects 중 1 개는
“Objects with Simple actions”이 필요한 상태입니다.
21. 화면 상단의 “Action Items”을 선택하여 원래 화면으로 돌아갑니다.
22. OSHOP Schema 에 !(느낌표)가 생겼음을 확인합니다.
23. OSHOP Schmea 를 다시 선택 후 “Convert Schema”를 선택하여 Target Aurora Instance 로
적용을 준비합니다.
24. “These Objects might already exist in the target database. Replace?” 경고창에서 YES 를
선택합니다.

25. 화면 우측의 Target Aurora 에서 oshop schema 가 새로 보이는 것을 확인합니다. oshop
schema 는 아직 생성된 상태가 아닙니다.
26. OSHOP Schema Tree 를 확장하여 Procedures 를 확장합니다. 먼저 DUMMYDELETE 를
Click 합니다(노란색 1 번).
화면 우측 하단의 oshop.DUMMYDELETE()의 내용 중 “FROM DUMMY”를 “FROM dummy”로
변경 합니다(노란색 2 번). Oracle 의 경우 Schema 의 대소문자의 구별이 없으나, MySQL 에서는
Schema 들의 대소문자를 구분 합니다. 이번 LAB 에서는 ORACLE 의 Table 명이 모두
대문자지만, Aurora MySQL 로 이관하면서 모두 소문자로 변환을 할 것 입니다. 이를 위해서
Procedure 내에서도 Table 명을 모두 소문자로 변경합니다.

27. DUMMYINSERT 를 Click 하고 위의 25 번 Step 과 동일하게 “INSERT INTO DUMMY” 를
“INSERT INTO dummy”로 변경합니다.
28.DUMMYTRUNCATE 를 Click 하고 25 번 Step 과 동일하게 “TRUNCATE TABLE DUMMY”를
“TRUNCATE TABLE dummy”로 변경합니다.
29. DUMMYUPDATE 를 Click 하고 25 번 Step 과 동일하게 “UPDATE DUMMY”를 “UPDATE
dummy”로 변경합니다.
30.4 개의 Procedure 의 대문자 DUMMY 를 소문자 dummy 로 변경을 완료 하였습니다.

31. Target Aurora Instance 에서 oshop schema 를 생성하기 위해 oshop 을 선택 후 “Apply to
database”를 Click 합니다.
32. Task Bar 아래의 MySQL Workbench 를 실행하여 실제로 oshop database 가 생성되었는지
확인 합니다.
33. 생성되어 있는 “Aurora-MySQL”에 마우스를 두고 마우스 우클릭을 합니다. “Edit Connection”을
Click 합니다.

34. Setup New Connection 에 정보들을 입력합니다.
a. Connection Name : Aurora-MySQL
b. Connection Method : Standard(TCP/IP)
c. Hostname : Aurora Writer Endpoint(9. AWSDC 에서 신규 Aurora Instance 생성-
Step 14 에서 확인)
d. Port : 3306
e. Username : admin
f. Password : Stored in Vault : Octank#1234
g. “Test Connection” Click 하여 “Successfully made the MySQL connection” 확인
h. “OK”를 Click 하여 Popup 창을 닫은 후 다시 Close 버튼을 클릭
i. Aurora-MySQL 을 클릭하면 Query 창이 뜹니다.
j. Query Tab 에서 다음의 Query 들을 수행합니다. Query 를 실행하려면 Query
Statement 을 Drag 하고, 번개 모양 아이콘을 클릭합니다. 한줄씩 Drag 하여 활성화하고
실행합니다.
k. show databases;
=> oshop DB 가 있는지 확인

l. use oshop;
show tables;
=>bigemp, bognus, dept, dummy, emp, salgrade 확인
m. select * from emp;
=> Schema Conversion Tool 로 Schema 만 Migration 하였고, DATA 는 아직
Migration 하지 않았기 때문에 Data 가 존재하지 않습니다.

12. OnPREM Oracle 선행 작업
이 과정에서는 SQL Developer 를 이용하여 Source OnPREM Oracle 에서 Migration 을 위한 선행
작업을 수행합니다. 이 선행 작업은 DMS 를 이용하여 Data Full Load 와 CDC 작업을 위해
필요합니다.
1. Windows Server 화면 아래, MySQL Workbench 메뉴 옆의 SQL Developer 실행
2. 화면 좌측의 + Button 을 Click 하고 아래처럼 입력
a. Name : OnPREM-ORACLE
b. Username : sys
c. Role : SYSDBA
d. Password : Octank#1234
e. Hostname : ORACLE-ON-EC2 의 Private IP
f. Port : 1521
g. SID : salesdb
h. “Save” Click
i. “Test” Click 후 Status : Success 확인

3. OnPREM-ORACLE 선행 작업 수행
a. “Connect” Click 하여 접속(다시 sys password 를 물어볼 경우 Octank#1234 입력)
b. Worksheet 에서 다음의 선행작업을 수행
c. 바탕화면의 Query.txt 에서 “2. SQL Developer 를 이용하여 OnPREM Oracle 선행 작업”
부분을 복사
d. 한 줄씩 Query 를 수행 (실행하려는 Statement 에 마우스 커서를 두고, 아래 화면의 맨
좌측 초록색 화살표를 클릭하면 Query 실행)
e. create user dms_user identified by Octank#1234 default tablespace users
temporary tablespace temp quota unlimited on users;
f. grant connect, resource to dms_user;
g. grant EXECUTE ON dbms_logmnr to dms_user;

h. 다음의 Grant Statement 들을 Drag 하여 모두 선택 후 Query 실행(SQL Developer 의
Bug 때문에 Grant 문장들을 3 번 정도 실행합니다.)
GRANT SELECT ANY TRANSACTION to dms_user;
GRANT SELECT on V_$ARCHIVED_LOG to dms_user;
GRANT SELECT on V_$LOG to dms_user;
GRANT SELECT on V_$LOGFILE to dms_user;
GRANT SELECT on V_$DATABASE to dms_user;
GRANT SELECT on V_$THREAD to dms_user;
GRANT SELECT on V_$PARAMETER to dms_user;
GRANT SELECT on V_$NLS_PARAMETERS to dms_user;
GRANT SELECT on V_$TIMEZONE_NAMES to dms_user;
GRANT SELECT on V_$TRANSACTION to dms_user;
GRANT SELECT on ALL_INDEXES to dms_user;
GRANT SELECT on ALL_OBJECTS to dms_user;
GRANT SELECT on DBA_OBJECTS to dms_user;
GRANT SELECT on ALL_TABLES to dms_user;
GRANT SELECT on ALL_USERS to dms_user;
GRANT SELECT on ALL_CATALOG to dms_user;
GRANT SELECT on ALL_CONSTRAINTS to dms_user;
GRANT SELECT on ALL_CONS_COLUMNS to dms_user;
GRANT SELECT on ALL_TAB_COLS to dms_user;
GRANT SELECT on ALL_IND_COLUMNS to dms_user;
GRANT SELECT on ALL_LOG_GROUPS to dms_user;
GRANT SELECT on SYS.DBA_REGISTRY to dms_user;
GRANT SELECT on SYS.OBJ$ to dms_user;
GRANT SELECT on DBA_TABLESPACES to dms_user;
GRANT SELECT on ALL_TAB_PARTITIONS to dms_user;
GRANT SELECT on ALL_ENCRYPTED_COLUMNS to dms_user;
GRANT SELECT on V_$LOGMNR_LOGS to dms_user;
GRANT SELECT on V_$LOGMNR_CONTENTS to dms_user;
GRANT SELECT on ALL_VIEWS to dms_user;
GRANT SELECT ANY TABLE to dms_user;
GRANT ALTER ANY TABLE to dms_user;
GRANT create any directory to dms_user;

i. SELECT name, value, description FROM v$parameter WHERE name = 'compatible';
결과 값이 9.0.0 이상인지 확인
j. ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
k. SELECT supplemental_log_data_min FROM v$database;
결과 값이 YES 혹은 IMPLICIT 인지 확인
l. SELECT A.TABLE_NAME, A.CONSTRAINT_NAME, B.COLUMN_NAME, B.POSITION
FROM ALL_CONSTRAINTS A, ALL_CONS_COLUMNS B
WHERE A.CONSTRAINT_TYPE = 'P'
AND A.OWNER = B.OWNER
AND A.CONSTRAINT_NAME = B.CONSTRAINT_NAME
AND A.OWNER= 'OSHOP'
ORDER BY B.POSITION;
결과 값이 아래처럼 나오는지 확인
m. ALTER TABLE OSHOP.DUMMY ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY)
COLUMNS;
n. ALTER TABLE OSHOP.EMP ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY)
COLUMNS;
o. ALTER TABLE OSHOP.DEPT ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY)
COLUMNS;
p. ALTER TABLE OSHOP.BIGEMP ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
q. ALTER TABLE OSHOP.BONUS ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
r. ALTER TABLE OSHOP.SALGRADE ADD SUPPLEMENTAL LOG DATA (ALL)
COLUMNS;
s. l, m, n, o, p, q Step 실행 시 ORA-32588 은 무시

13. DMS 를 사용한 Oracle Data Migration
이 과정에서는 DMS 를 사용하여 OnPREM Oracle Data 를 AWSDC Aurora-MySQL 로 Migration
합니다.
1. DMS 에서 사용할 dms-vpc-role 을 우선 생성합니다.
a. Service -> IAM 으로 이동
b. 좌측 메뉴에서 Roles 클릭
c. “Create role” 버튼 클릭
d. Select type of trusted entity 에서 DMS 선택 후 “Next: Permissions” 클릭

e. Attach permissions policies 에서 AmazonDMSVPCManagementRole 선택 후 “Next:
Tags” 클릭
f. Add tags (optional)은 Skip 하고 “Nex: Review” 버튼 클릭
g. Review 에서 Role name 에 “dms-vpc-role” 입력 후 “Create role” 버튼 클릭. (만약
이미 해당 Role 이 있다고 나올 경우 Cancel 하고, 이후 Step 을 진행합니다.
2. DMS 에서 사용할 dms-cloudwatch-logs-role 을 생성합니다.
a. Service -> IAM 으로 이동
b. 좌측 메뉴에서 Roles 클릭
c. “Create role” 버튼 클릭
d. Select type of trusted entity 에서 DMS 선택 후 “Next: Permissions” 클릭

e. Attach permissions policies 에서 AmazonDMSCloudWatchLogsRole 선택 후 “Next:
Tags” 클릭
f. Add tags (optional)은 Skip 하고 “Nex: Review” 버튼 클릭

g. Review 에서 Role name 에 “dms-vpc-role” 입력 후 “Create role” 버튼 클릭. (만약
이미 해당 Role 이 있다고 나올 경우 Cancel 하고, 이후 Step 을 진행합니다.
3. DMS Replication Instance 를 생성합니다.
a. Services => Database Migration Service 이동
b. 화면 좌측의 Replication Instances 를 Click
c. “Create replication instance”를 Click
d. Replication instance configuration 에서 아래처럼 입력
(나머지는 기본값을 그대로 사용합니다.)
i. Name : RI-OracleToAurora
ii. Description : RI-OracleToAurora
iii. Instance class : dms.c4.2xlarge
iv. Engine version : 3.4.0
v. Allocated storage : 50
vi. VPC : AWSDC
vii. Multi AZ : Uncheck
viii. Publicly accessible : Uncheck
e. Advanced security and network configuration
i. Availability zone : ap-northeast-2a
ii. 나머지는 기본 값 그대로 사용
f. “Create” Click
4. Source 인 OnPREM Oracle 에 대한 Endpoint 를 생성합니다.
a. 화면 좌측의 Endpoints 를 Click
b. “Create Endpoints” Click
c. “Create Endpoint” Page 에서 아래처럼 입력

d. “Endpoint type” : Source endpoint
e. “Endpoint identifier” : OnPREM-ORACLE
f. Source engine : oracle
g. Server name : ORACLE-ON-EC2 의 Private IP
h. Port : 1521
i. User name : dms_user
j. Password : Octank#1234
k. SID/Service name : salesdb
l. “Create endpoint” Click

5. Target 인 Oracle RDS 에 대한 Endpoint 를 생성합니다.
a. 화면 좌측의 Endpoints 를 Click
b. “Create Endpoints” Click
c. “Create Endpoint” Page 에서 아래처럼 입력
d. “Endpoint type” : Target endpoint
e. “Select RDS DB instance” : Check
f. RDS Instance : 생성한 Aurora Instance 선택(awsdc-aurora-instance-1)
g. “Endpoint identifier” : 자동으로 입력됨
h. Source engine : 자동으로 입력됨
i. Server name : 자동으로 입력됨
j. Port : 자동으로 입력됨(1521)
k. User name : 자동으로 입력됨 (admin)
l. Password : Octank#1234
m. “Create endpoint” Click

6. DMS Replication Instance 에서 각 Endpoints 들로 정상적으로 연결되는지 확인합니다. (앞서
생성한 Replication Instance 의 상태가 Ready 인지 확인)
a. OnPREM Oracle Test Connection 수행
b. Actions -> Test Connection -> Run Test
c. RDS Oracle Test Connection 수행
d. Actions -> Test Connection -> Run Test

7. DMS 를 이용한 DB migration 용 task 를 생성합니다.
a. 화면 좌측의 “Database migration tasks”를 Click
b. “Create task” Click
c. “Task configuration”에서 아래처럼 입력
i. Task Identifier : Migration-Oracle-To-AuroraMySQL-OSHOP
ii. Replication Instance : ri-oracletoaurora
iii. Source database endpoint : onprem-oracle
iv. Target database endpoint : awsdc-aurora-instance-1
v. Migration type : Migrate existing data and replicate ongoing changes
(Data Full Load 와 변경 분의 Change Data Capture<CDC>로 Migration)
vi. Start task on create : Check

d. “Task settings”에서 아래처럼 입력
i. CDC stop mode : Don't use custom CDC stop mode
ii. Target table preparation mode : Truncate
iii. Stop task after full load completes : Don’t stop
iv. Include LOB columns in replication : Limited LOB mode
v. Maximum LOB size(KB) : 32
vi. Enable validation : Check
vii. Enable CloudWatch logs : Check

e. Table mapping 에서 아래처럼 입력
i. Editing mode – Guided UI
ii. Selection rules : “Add new selection rule” Click 후 아래처럼 입력
1. Schema : Enter a schema
2. Schema name: OSHOP
3. Table name : %
4. Action : Include
iii. Transformation rules : “Add new transformation rule” Click 후 아래처럼 입력
1. Target : Schema
2. Schema name : Enter a schema
4. Action : Make lowercase
iv. Transformation rules : “Add new transformation rule” Click 후 아래처럼 입력
1. Target : Table
4. Table name : %

f. “Create Task” Click
8. Database migration task 가 생성되고 실행되는데 1 분 정도 시간이 걸립니다. Task 를 클릭하여
작업 현황을 확인합니다.
a. Summary 에서 Monitoring Status, Full Loading 결과 확인

b. Table statistics 에서 각 Table 별 loading 된 row count 가 다음과 같은지 확인
DUMMY : 0 , DEPT : 4, BIGEMP : 28,672, SALGRADE : 5, BONUS : 0, EMP : 14
9. OnPREM Source Database 에서 계속 고객 Request 에 의한 Transaction 이 있다고 가정하고,
해당 Transaction 에 대한 CDC 정상 동작 유무를 확인해 보겠습니다.
OnPREM 에서 User 가 사용하던 DUMMYINSERT, DUMMYUPDATE, DUMMYDELETE stored
procedure 를 사용하여 DML Transaction 을 Simulation 합니다.
CDC 동작 확인을 위해 Services ->EC2 로 이동합니다.
OnPREM-OracleServer 를 선택하고 “Connect” => “Session Manager”를 선택하여
Terminal 을 시작합니다. (Session Manager 접속 방법은 위에서 수행한 7. OnPREM VPC 와
AWSDC VPC Connectivity 확인(2)을 참고하세요.)
10. Terminal 접속 후 다음을 수행합니다.
sh-4.2$ sudo su -
Last login: Sun Jun 23 10:24:54 EDT 2019 on pts/0
root@oracle11g:/root# su - oracle
Last login: Sun Jun 23 10:24:56 EDT 2019 on pts/0
oracle@oracle11g:/home/oracle> sqlplus OSHOP/Octank#1234
11. DUMMY Table 에 20000 건 Data 를 Insert 합니다.
SQL> exec dummyinsert(20000);
PL/SQL procedure successfully completed.

12. DMS Task 의 Table Statistics 를 확인합니다. DUMMY Table 에 신규 Data 20,000 건이
CDC 로 정상적으로 넘어 온 것을 확인합니다.
13. DUMMY Table 의 DATA 를 Update 해보겠습니다.
SQL> exec dummyupdate();
14. DMS Task 의 Table Statistics 를 확인합니다. DUMMY Table 에 Update 1000 건이 정상적으로
넘어왔는지 확인 합니다.

15. DUMMY Table 의 Data 를 Delete 해보겠습니다.
SQL> exec dummydelete();
16. DMS Task 의 Table Statistics 를 확인합니다. DUMMY Table 에 Delete 1000 건이 정상적으로
넘어왔는지 확인 합니다.
# Insert, Update, Delete 등 Source Database 의 변경 분을 DMS 가 정상적으로 인식하고
Target 인 Aurora MySQL 적용함을 확인 했습니다.
또한 Oracle 에서 사용하던 4 개의 Stored Procedure 가 정상적으로 Aurora MySQL 로
Migration 되어서 동작함을 확인 하였습니다.
17. 화면 좌측의 “Database migration tasks”로 이동 후 “migration-oracle-to-auroramysql”
task 를 선택 후 Action => Stop 합니다.
18. Task 가 “Stopped” 상태가 되면 Task 를 삭제합니다. (Delete 메뉴가 활성화가 안 될 경우 전체
Page 를 Refresh 합니다.)

14. OnPREM-Tomcat 의 Connection String 수정
12 번 과정에서 OnPREM Oracle 의 OSHOP Schema 를 AWSDC Aurora MySQL 로 Data
Migration 완료하였습니다. OnPREM Tomcat 에서 JDBC Connection String 을 AWSDC Aurora
MySQL 로 변경하여 Application 이 정상 구동하는지 확인합니다.
1. Services -> EC2 이동
2. OnPREM-Tomcat 을 선택하고 “Connect” => “Session Manager”를 실행
3. MySQL Driver 를 사용해야 하기 때문에, aurora.jsp 의 DB_SERVER_IP 를
수정합니다.(oracle.jsp 와 aurora.jsp 의 logic 은 동일합니다.)
4. “Start session” 후 다음을 수행
sh-4.2$ sudo su -
Last login: Thu Jul 25 14:21:12 UTC 2019 on pts/0
root@ip-82-20-1-103:/root#
root@ip-82-20-1-103:/root# cd /var/lib/tomcat8/webapps/ROOT
root@ip-82-20-1-103:/var/lib/tomcat8/webapps/ROOT# cp aurora.jsp ~
cp: overwrite ‘/root/aurora.jsp’? y
root@ip-82-10-1-5:/var/lib/tomcat8/webapps/ROOT# vi aurora.jsp
# DB_HOST_IP 부분을 Aurora 의 endpoint URL 로 변경(9. AWSDC 에서 신규 Aurora Instance
생성-14 에서 확인)
root@ip-10-100-1-241:/var/lib/tomcat8/webapps/ROOT# vi aurora.jsp
root@ip-10-100-1-241:/var/lib/tomcat8/webapps/ROOT# diff aurora.jsp ~/aurora.jsp
24c24
< String DB_HOST_IP="awsdc-aurora.cluster-cf89zyffo8dr.ap-northeast-
2.rds.amazonaws.com";
---
> String DB_HOST_IP=” <AURORA-ENDPOINT>”
5. http://TARGET_MACHINE_PUBLIC_IP:8080/aurora.jsp 로 접속하여 정상적으로 마이그레이션
되었는지 확인합니다. Application 의 Connection String 이 OnPREM-Oracle 에서 AWSDC
Aurora MySQL 로 변경 후에도 정상 동작함을 확인합니다.

15. soe schema 초기화 작업-1
1. OnPREM-WindowsServer 에 Remote RDP(mstsc.exe)로 접속
2. MySQL Workbench 를 실행하고 아까 생성한 Aurora-MySQL 을 클릭하면 Query 창이 뜹니다.
3. show databases; 를 실행
4. drop database soe; 를 실행
5. show databases; 를 실행하여 soe Database 가 없음을 확인

6. AWS Schema Conversion Tool 을 실행
7. 화면 우측의 Amazon Aurora 창에서 Schemas 에 커서를 두고, 마우스 우측 버튼 Click 후
“Refresh from database”를 실행하여 최신 Metadata 로 Update
8. 화면 우측의 Amazon Aurora 창에서 soe schema 가 없어진 것을 확인

9. 화면 좌측의 OnPREM-Oracle Schema 를 모두 Uncheck 후 SOE 만 Check 후 “Convert
Schema” 실행
10. 화면 우측의 MySQL Aurora 창에서 “Apply Database”실행

16. DB 마이그레이션 속도에 영향을 주는 요소 확인
Migration 속도에 영향을 끼치는 다양한 요소들 중 Load Parallel 과 Index 의 영향도를 직접 실습해
보겠습니다.
DMS 를 이용한 Full Load + CDC 의 경우 다양한 요소들에 의한 Migration 속도가 결정 됩니다.
1. Source Database Performance
a. H/W 요소 : CPU, Memory, I/O, Network Bandwidth 등
b. S/W 요소 : Constraints, Indexes, Supplemental Logging, Binary Reader 등
2. Replication Instance Performance
3. Target Database Performance
b. S/W 요소 : Constraints, Indexes, Supplemental Logging 등
4. Replication Endpoint & Replication Task
a. extra connection 설정, logminer vs binary reader
b. Parallel Load 갯수 설정
5. Partitioned Table 의 Sub Partition 사용 유무
6. LOB Data MAX Size Limit 사용 유무
7. Table 별 Migration 순서 설정
8. Big Table, Small Table 을 Task 별 구분
Migration 속도에 영향을 주는 다양한 요소들 중 이번 실습에서는 Load Parallel 개수와 Target
DB 의 Index 가 어떻게 영향을 주는지 살펴 보겠습니다.
동일한 OnPREM Oracle 의 Data 를 동일한 Aurora MySQL 로 DMS 로 Migration 하되, Load
Parallel 개수와 Index 설정을 다음과 같은 조건으로 Test 해보겠습니다.
각 Test 후에는 “18. soe schema 초기화 작업-Iterate”을 통해서 soe schema 를 초기화 후 다시
Data Migration 을 수행합니다.
각 Case 별 테스트 후에 아래의 표를 Update 하여 Migration 성능을 확인 합니다.
Load Parallel Aurora with Index Migration Elapsed Time RDS CPU Usage
Case 1 2 No Index
Case 2 16 No Index
Case 3 2 With Index in Aurora
Case 4 16 With Index in Aurora

a. Case 1 – Load Parallel = 2 & No Index
0. Load Parallel = 2 , No Index 조건에서 Migration 수행
1. Services => Database Migration Service 로 이동
2. “Database migration tasks”를 선택 후 “Create Task”를 Click
a. “Task configuration”에서 아래처럼 입력
i. Task Identifier : Oracle-To-AuroraMySQL-SOE-PARALLEL-2
v. Migration type : Migrate existing data

b. “Task settings”에서 아래처럼 입력
i. Target table preparation mode : Truncate
ii. Include LOB columns in replication : Limited LOB mode
iii. Maximum LOB size(KB) : 32
iv. Enable validation : Check
v. Enable CloudWatch logs : Check
c. Table mapping 에서 아래처럼 입력
iii. Schema : Enter a schema
iv. Schema name: SOE
v. Table name : ORDERS0%
vi. Action : Include

d. Transformation rules : “Add new transformation rule” Click 후 아래처럼 입력
i. Target : Schema
ii. Schema name : Enter a schema
iii. Schema name: SOE
iv. Action : Make lowercase

e. Transformation rules : “Add new transformation rule” Click 후 아래처럼 입력
i. Target : Table
ii. Schema name : Enter a schema
iii. Schema name: SOE
iv. Table name : %
v. Action : Make lowercase

f. Advanced task settings
i. Maximum number of tables to load in parallel : 2
g. “Create Task” Click
h. 1 분 이내에 Task 가 시작 됩니다. Task 가 시작되면 Identifier oracle-to-auroramysql-
soe-parallel-2 를 click 하여 모니터링 합니다.

i. Table statistics 를 Click 하여 Table migration 상태를 모니터링 합니다. Parallel 조건을
2 로 했기 때문에 한번에 2 개의 Table 을 Migration 합니다.
j. Status 가 Completed 가 될 때까지 기다립니다. Migration 이 완료되면 Aurora-
MySQL 의 CloudWatch 를 확인합니다.

% Migration 시 Aurora MySQL 의 CPU Util 이 약 20~25%정도임을 알 수 있습니다.
k. DMS Task 로 이동 후 Overview Details => View CloudWatch logs 를 Click
l. Log Events 에서 “ORDERS001”를 입력하여 Loading 을 시작하는 시점을 확인
Ex) 14:29:43 에 Loading 시작
m. “ORDERS040”을 입력하여 마지막 Table Loading 완료 시점을 확인
Ex) 14:37:47 에 Loading 완료
n. Parallel 2 & No Index 일 경우 약 8min 4sec 소요
o. 다음 Test 를 위하여 soe schema 를 초기화 합니다.( 18. soe schema 초기화 작업-
Iterate”)

b. Case 2 – Load Parallel = 16 & No Index
1. Load Parallel = 16, No Index 조건에서 Migration 수행
i. Task Identifier : Oracle-To-AuroraMySQL-SOE-PARALLEL-16

2. Schema name: SOE
3. Table name : ORDERS0%
4. Action : Include

1. Target : Schema
3. Schema name: SOE
1. Target : Table
3. Schema name: SOE
4. Table name : %

d. Advanced task settings
i. Maximum number of tables to load in parallel : 16
e. “Create Task” Click
f. 1 분 이내에 Task 가 시작 됩니다. Task 가 시작되면 Identifier oracle-to-auroramysql-
soe-parallel-16 를 click 하여 모니터링 합니다.
g. Table statistics 를 Click 하여 Table migration 상태를 모니터링 합니다. Parallel 조건을
16 으로 했기 때문에 한번에 16 개의 Table 을 Migration 합니다.

h. Status 가 Completed 가 될 때까지 기다립니다. Migration 이 완료되면 Aurora-

% Migration 시 Aurora MySQL 의 CPU Util 이 약 70~75%로 증가했음을 알 수 있습니다.
p. DMS Task 로 이동 후 Overview Details => View CloudWatch logs 를 Click
q. Log Events 에서 “ORDERS001”를 입력하여 Loading 을 시작하는 시점을 확인
r. “ORDERS040”을 입력하여 마지막 Table Loading 완료 시점을 확인
s. Parallel 16 일 경우 2min 15sec 소요

17. 마이그레이션 성능 점검을 위한 테이블 인덱스 생성
이번에는 Aurora MySQL 의 soe schema 의 Table 들에 Index 를 생성하고, Index 가 마이그레이션
성능에 어떤 영향을 주는지 확인해 보겠습니다.
1. OnPREM-WindowsServer 의 Remote RDP 로 접속
2. MySQL Workbench 를 실행하고 Aurora-MySQL 접속
3. 다음 Test 를 위하여 soe schema 를 초기화 합니다.( 18. soe schema 초기화 작업-
Iterate”참고 )
4. 바탕화면에서 index.txt 를 열고, DDL 을 복사 하여 MySQL Workbench 에 Paste 합니다.
5. MySQL Workbench 에서 ctrl+A 를 눌러서 모든 “Create index”를 선택 후 실행합니다.

6. MySQL Workbench 의 Action Ouput 에서 Index 가 모두 정상적으로 생성되었는지
확인합니다.

a. Case 3 – Load Parallel = 2 & with Index
1. Load Parallel = 2 조건 + Table 들에 Index 생성 후 Migration
i. Task Identifier : Oracle-To-AuroraMySQL-SOE-PARALLEL-2-Index

2. Schema name: SOE
4. Action : Include

1. Target : Schema
3. Schema name: SOE
1. Target : Table
3. Schema name: SOE
4. Table name : %

v. Maximum number of tables to load in parallel : 2
soe-parallel-2-index 를 click 하여 모니터링 합니다.

t. DMS Task 로 이동 후 Overview Details => View CloudWatch logs 를 Click
u. Log Events 에서 “ORDERS001”를 입력하여 Loading 을 시작하는 시점을 확인
v. “ORDERS040”을 입력하여 마지막 Table Loading 완료 시점을 확인
w. Parallel 2 + Index 일 경우 14min 54 sec 소요
x. 다음 실습을 위해 18. soe schema 초기화 작업-Iterate”과 17. 마이그레이션 성능 점검을
위한 테이블 인덱스 생성을 차례대로 다시 수행합니다.

b. Case 4 – Load Parallel = 16 & with Index
1. Load Parallel = 16 조건 + Table 들에 Index 생성 후 Migration
i. Task Identifier : Oracle-To-AuroraMySQL-SOE-PARALLEL-16-Index

2. Schema name: SOE
4. Action : Include
1. Target : Schema
3. Schema name: SOE

1. Target : Table
3. Schema name: SOE
4. Table name : %

v. Maximum number of tables to load in parallel : 16
soe-parallel-16-index 를 click 하여 모니터링 합니다.

i. DMS Task 로 이동 후 Overview Details => View CloudWatch logs 를 Click
j. Log Events 에서 “ORDERS001”를 입력하여 Loading 을 시작하는 시점을 확인
k. “ORDERS040”을 입력하여 마지막 Table Loading 완료 시점을 확인
l. Parallel 16+Index 일 경우 5min 44 sec 소요

18. soe schema 초기화 작업-Iterate
1. OnPREM-WindowsServer 에 Remote RDP(mstsc.exe)로 접속
2. MySQL Workbench 를 실행하고 아까 생성한 Aurora-MySQL 을 클릭하면 Query 창이 뜹니다.
3. use soe; 실행
4. 다음의 Query 를 통해 몇개의 orders table 의 Data 개수를 확인합니다. Migration 전에는 모든
row 수가 0 입니다. Migration 이후에는 row 수가 1,430,862 와 199,999 건입니다.
select count(*) from orders001
union all
union all
union all
union all
union all
select count(*) from orders040;
% Migration 전에는 모든 Table 의 row 수가 0 입니다.

% Migration 후에는 orders001~020 은 1,430,862 건, orders021~040 은 199,999 건입니다.
5. drop database soe; 를 실행
6. show databases; 를 실행하여 soe Database 가 없음을 확인

7. AWS Schema Conversion Tool 을 실행
8. 화면 우측의 Amazon Aurora 창에서 Schemas 에 커서를 두고, 마우스 우측 버튼 Click 후
“Refresh from database”를 실행하여 최신 Metadata 로 Update

9. 화면 우측의 Amazon Aurora 창에서 soe schema 가 없어진 것을 확인
10. 화면 좌측의 OnPREM-Oracle Schema 를 모두 Uncheck 후 SOE 만 Check 후 “Convert
Schema” 실행

11. 화면 우측의 MySQL Aurora 창에서 “Apply Database”실행

19. OnPREM Oracle CPU & Network Utilization
Source 인 OnPREM Oracle 의 경우 Migration 시 CPU Utilization 은 상대적으로 적음을 알 수 있습니다.
다만 실제 환경에서의 Migration 은 적게는 수백 개에서 많게는 수천, 수 만개의 Table 들을 동시에 옮기기
때문에 CPU 와 I/O, Network 사용률이 상승합니다. 이번 HOL 테스트에서는 Parallel 16 으로 Data 를
Migration 시 CPU 관점에서는 약 4%정도의 Usage 를 확인 할 수 있었습니다. 만약 Parallel 48 로
Migration 시 산술적으로 약 12% 정도의 CPU Usage 증가를 예측 해 볼 수 있습니다. 다만 이러한 H/W
Metric 수치 변경은 H/W Spec 이나 Network 상황 등에 따라서 변할 수 있습니다.
Load Parallel Aurora with Index Migration Elapsed Time RDS CPU Usage
Case 1 2 No Index 8min 2sec 20 ~ 25%
Case 2 16 No Index 2min 15sec 70 ~ 75%
Case 3 2 With Index in Aurora 14min 54sec 50 ~ 60%
Case 4 16 With Index in Aurora 5min 44sec 90 ~ 100%

Appendix – Resource 삭제
1. DMS TASK Stop & Delete
a. Services => Database Migration Service
b. 화면 좌측의 “Database migration tasks” Click
c. 4 개의 Task 를 모두 선택 후 Actions => Delete
d. 화면 좌측의 “Replication Instances” Click
e. ri-oracleoaurora 를 선택 후 Actions => Delete
f. 화면 좌측의 “Endpoints” Click
g. Onprem-oracle 과 awsdc-aurora-instance-1 을 선택하고 Actions => Delete

2. Services => RDS
a. Awsdc-aurora-instance-1 을 선택 후 Actions => Delete

3. Services => VPC
a. 화면 좌측 “Peering Connections” Click
b. OnPREM-to-AWSDC 선택 후 Actions => Delete Peering Connection

4. Services => IAM 이동
a. 화면 좌측 Roles Click
b. EC2SSMRole 검색
c. EC2SSMRole 선택 후 “Delete role” Click

5. Services => CloudFormation
a. OnPREM 선택 후 Delete Click
b. AWSDC 선택 후 Delete Click
END OF DOCUMENT

오라클 DB를 AWS 데이터베이스로 마이그레이션 하기 - 윤기원 :: AWS Database Modernization Day 온라인

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 오라클 DB를 AWS 데이터베이스로 마이그레이션 하기 - 윤기원 :: AWS Database Modernization Day 온라인

Similar to 오라클 DB를 AWS 데이터베이스로 마이그레이션 하기 - 윤기원 :: AWS Database Modernization Day 온라인 (20)

More from Amazon Web Services Korea

More from Amazon Web Services Korea (20)

오라클 DB를 AWS 데이터베이스로 마이그레이션 하기 - 윤기원 :: AWS Database Modernization Day 온라인