` 형식을 사용합니다.
다음 테이블에서 예제를 찾을 수 있습니다.
| Oracle 문 | MySQL 문 |
| --- | --- |
| CREATE PROCEDURE
TEST_ORA_PG.P_WITH_SELECT_VARIABLE_01
(p_state IN NUMBER)
AS
l_dept_id NUMBER := 1;
BEGIN
FOR cur IN
(WITH dept_empl(id, name, surname,
lastname, state, dept_id)
AS
(
SELECT id, name, surname,
lastname, state, dept_id
FROM test_ora_pg.dept_employees
WHERE state = p_state AND
dept_id = l_dept_id)
SELECT id,state
FROM dept_empl
ORDER BY id) LOOP
NULL;
END LOOP;
| CREATE PROCEDURE test_ora_pg.P_WITH_SELECT_VARIABLE_01(IN par_P_STATE DOUBLE)
BEGIN
DECLARE var_l_dept_id DOUBLE DEFAULT 1;
DECLARE var$id VARCHAR (8000);
DECLARE var$state VARCHAR (8000);
DECLARE done INT DEFAULT FALSE;
DECLARE cur CURSOR FOR SELECT
ID, STATE
FROM (SELECT
ID, NAME, SURNAME, LASTNAME, STATE, DEPT_ID
FROM TEST_ORA_PG.DEPT_EMPLOYEES
WHERE STATE = par_p_state AND DEPT_ID = var_l_dept_id) AS dept_empl
ORDER BY ID;
DECLARE CONTINUE HANDLER FOR NOT FOUND
SET done := TRUE;
OPEN cur;
read_label:
LOOP
FETCH cur INTO var$id, var$state;
IF done THEN
LEAVE read_label;
END IF;
BEGIN
END;
END LOOP;
CLOSE cur;
END;
|
| CREATE PROCEDURE
TEST_ORA_PG.P_WITH_SELECT_REGULAR_MULT_01
AS
BEGIN
FOR cur IN (
WITH dept_empl AS
(
SELECT id, name, surname,
lastname, state, dept_id
FROM test_ora_pg.dept_employees
WHERE state = 1),
dept AS
(SELECT id deptid, parent_id,
name deptname
FROM test_ora_pg.department
)
SELECT dept_empl.*,dept.*
FROM dept_empl, dept
WHERE dept_empl.dept_id = dept.deptid
) LOOP
NULL;
END LOOP;
| CREATE VIEW TEST_ORA_PG.`P_WITH_SELECT_REGULAR_MULT_01$dept_empl
`(id, name, surname, lastname, state, dept_id)
AS
(SELECT id, name, surname, lastname, state, dept_id
FROM test_ora_pg.dept_employees
WHERE state = 1);
CREATE VIEW TEST_ORA_PG.`P_WITH_SELECT_REGULAR_MULT_01$dept
`(deptid, parent_id,deptname)
AS
(SELECT id deptid, parent_id, name deptname
FROM test_ora_pg.department);
CREATE PROCEDURE test_ora_pg.P_WITH_SELECT_REGULAR_MULT_01()
BEGIN
DECLARE var$ID DOUBLE;
DECLARE var$NAME VARCHAR (30);
DECLARE var$SURNAME VARCHAR (30);
DECLARE var$LASTNAME VARCHAR (30);
DECLARE var$STATE DOUBLE;
DECLARE var$DEPT_ID DOUBLE;
DECLARE var$deptid DOUBLE;
DECLARE var$PARENT_ID DOUBLE;
DECLARE var$deptname VARCHAR (200);
DECLARE done INT DEFAULT FALSE;
DECLARE cur CURSOR FOR SELECT
dept_empl.*, dept.*
FROM TEST_ORA_PG.`P_WITH_SELECT_REGULAR_MULT_01$dept_empl
` AS dept_empl,
TEST_ORA_PG.`P_WITH_SELECT_REGULAR_MULT_01$dept
` AS dept
WHERE dept_empl.DEPT_ID = dept.DEPTID;
DECLARE CONTINUE HANDLER FOR NOT FOUND
SET done := TRUE;
OPEN cur;
read_label:
LOOP
FETCH cur INTO var$ID, var$NAME, var$SURNAME,
var$LASTNAME, var$STATE, var$DEPT_ID, var$deptid,
var$PARENT_ID, var$deptname;
IF done THEN
LEAVE read_label;
END IF;
BEGIN
END;
END LOOP;
CLOSE cur;
END;
call test_ora_pg.P_WITH_SELECT_REGULAR_MULT_01()
|
| CREATE PROCEDURE
TEST_ORA_PG.P_WITH_SELECT_VAR_CROSS_02(p_state IN NUMBER)
AS
l_dept_id NUMBER := 10;
BEGIN
FOR cur IN (
WITH emp AS
(SELECT id, name, surname,
lastname, state, dept_id
FROM test_ora_pg.dept_employees
WHERE dept_id > 10
),
active_emp AS
(
SELECT id
FROM emp
WHERE emp.state = p_state
)
SELECT *
FROM active_emp
) LOOP
NULL;
END LOOP;
END;
| CREATE VIEW TEST_ORA_PG.`P_WITH_SELECT_VAR_CROSS_01$emp
`(id, name, surname, lastname, state, dept_id)
AS
(SELECT
id, name, surname, lastname,
state, dept_id
FROM TEST_ORA_PG.DEPT_EMPLOYEES
WHERE DEPT_ID > 10);
CREATE PROCEDURE
test_ora_pg.P_WITH_SELECT_VAR_CROSS_02(IN par_P_STATE DOUBLE)
BEGIN
DECLARE var_l_dept_id DOUBLE DEFAULT 10;
DECLARE var$ID DOUBLE;
DECLARE done INT DEFAULT FALSE;
DECLARE cur CURSOR FOR SELECT *
FROM (SELECT
ID
FROM
TEST_ORA_PG.
`P_WITH_SELECT_VAR_CROSS_01$emp` AS emp
WHERE emp.STATE = par_p_state)
AS active_emp;
DECLARE CONTINUE HANDLER FOR NOT FOUND
SET done := TRUE;
OPEN cur;
read_label:
LOOP
FETCH cur INTO var$ID;
IF done THEN
LEAVE read_label;
END IF;
BEGIN
END;
END LOOP;
CLOSE cur;
END;
|
# 를 사용하여 Oracle Database에서 Amazon RDS for Oracle로 마이그레이션 AWS Schema Conversion Tool
Oracle 스키마와 코드를 Amazon RDS for Oracle로 마이그레이션할 경우 몇 가지 사항을 고려해야 합니다.
+ AWS SCT 는 객체 트리에 디렉터리 객체를 추가할 수 있습니다. 디렉터리 객체는 서버 파일 시스템의 물리적 디렉터리를 나타내는 논리적 구조입니다.** DBMS\$1LOB, UTL\$1FILE, DBMS\$1FILE\$1TRANSFER, DATAPUMP 유틸리티 등과 같은 패키지를 통해 디렉터리 객체를 사용할 수 있습니다.
+ AWS SCT 는 Oracle 테이블스페이스를 Amazon RDS for Oracle DB 인스턴스로 변환할 수 있도록 지원합니다. Oracle은 데이터를 테이블스페이스에 논리적으로 저장하고, 해당 테이블스페이스와 연결된 데이터 파일에 물리적으로 저장합니다. Oracle에서는 데이터 파일 이름을 사용하여 테이블스페이스를 만들 수 있습니다. Amazon RDS는 데이터 파일, 로그 파일 및 제어 파일에 대해서만 Oracle Managed Files(OMF)를 지원합니다.는 변환 중에 필요한 데이터 파일을 AWS SCT 생성합니다.
+ AWS SCT 는 서버 수준 역할 및 권한을 변환할 수 있습니다. Oracle 데이터베이스 엔진에는 역할 기반 보안이 사용됩니다. 역할이란 사용자에 대해 부여하거나 취소할 수 있는 권한 모음입니다. Amazon RDS의 사전 정의된 역할인 DBA는 일반적으로 Oracle 데이터베이스 엔진에 대한 모든 관리 권한을 허용합니다. 아래의 권한들은 Oracle 엔진을 사용하는 Amazon RDS DB 인스턴스의 DBA 역할에는 사용할 수 없습니다.
+ 데이터베이스 변경
+ 시스템 변경
+ 디렉터리 생성
+ 권한 부여
+ 역할 부여
+ 외부 작업 생성
Amazon RDS for Oracle 사용자 역할에 고급 필터링 및 열 권한을 포함하여 다른 모든 권한을 부여할 수 있습니다.
+ AWS SCT 는 Oracle 작업을 Amazon RDS for Oracle에서 실행할 수 있는 작업으로 변환할 수 있도록 지원합니다. 이 변환에는 다음과 같은 몇 가지 제한 사항이 있습니다.
+ 실행 작업은 지원되지 않습니다.
+ ANYDATA 데이터 유형을 인수로 사용하는 일정 작업은 지원되지 않습니다.
+ Oracle 실제 애플리케이션 클러스터(RAC) 단일 노드는 Oracle Database 11g Release 2와 함께 제공된 Oracle Database Enterprise Edition에 속한 옵션입니다. Amazon RDS for Oracle은 RAC 기능을 지원하지 않습니다. 고가용성을 위해서는 Amazon RDS 다중 AZ를 사용하십시오.
다중 AZ 배포에서 Amazon RDS는 자동으로 서로 다른 가용 영역에 동기식 예비 복제본을 프로비저닝하고 유지합니다. 기본 DB 인스턴스는 가용 영역 전체에서 대기 복제본으로 동기식으로 복제됩니다. 이 기능은 데이터 중복을 제공하고, I/O 중지를 없애고, 시스템 백업 중에 지연 시간 스파이크를 최소화합니다.
+ Oracle Spatial에는 Oracle 데이터베이스에서 공간 데이터의 저장, 검색, 업데이트 및 쿼리를 신속하게 실행할 수 있는 SQL 스키마 및 기능이 있습니다. Oracle Locator에는 인터넷 및 무선 서비스 기반 애플리케이션과 파트너 기반 GIS 솔루션을 지원할 때 필요한 기능이 있습니다. Oracle Locator는 Oracle Spatial의 제한된 서브셋입니다.
Oracle Spatial 및 Oracle Locator 기능을 사용하려면 SPATIAL 옵션 또는 LOCATOR 옵션(함께 사용할 수 없음)을 DB 인스턴스의 옵션 그룹에 추가합니다.
Amazon RDS for Oracle DB 인스턴스에서 Oracle Spatial 및 Oracle Locator를 사용하기 위해서는 몇 가지 전제 조건이 있습니다.
+ 인스턴스가 Oracle Enterprise Edition 버전 12.1.0.2.v6 이상 또는 11.2.0.4.v10 이상을 사용해야 합니다.
+ 인스턴스가 VPC(Virtual Private Cloud) 내에 있어야 합니다.
+ 인스턴스가 Oracle 기능을 지원할 수 있는 DB 인스턴스 클래스를 사용해야 합니다. 예를 들어 db.m1.small, db.t1.micro, db.t2.micro 또는 db.t2.small DB 인스턴스 클래스에는 Oracle Spatial이 지원되지 않습니다. 자세한 내용은 [Oracle을 위한 DB 인스턴스 클래스 지원](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html#Oracle.Concepts.InstanceClasses)을 참조하세요.
+ 인스턴스에 대해 자동 마이너 버전 업그레이드를 활성화해야 합니다. CVSS 점수가 9 이상인 보안 취약성 또는 발표된 기타 보안 취약성이 있을 경우 Amazon RDS는 DB 인스턴스를 최신 Oracle PSU로 업데이트합니다. 자세한 내용은 다음 섹션을 참조하세요.
[Oracle DB 인스턴스 설정](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ModifyInstance.Oracle.html#USER_ModifyInstance.Oracle.Settings)
+ DB 인스턴스가 버전 11.2.0.4.v10 이상인 경우 XMLDB 옵션을 설치해야 합니다. 자세한 내용은 다음 섹션을 참조하세요.
[Oracle XML DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.XMLDB.html)
+ Oracle의 Oracle Spatial 라이선스가 있어야 합니다. 자세한 내용은 Oracle 설명서의 [Oracle Spatial and Graph](https://shop.oracle.com/apex/product?p1=OracleSpatialandGraph)를 참조하십시오.
+ Data Guard는 Oracle Database Enterprise Edition에 포함되어 있습니다. 고가용성을 위해서는 Amazon RDS 다중 AZ 기능을 사용하십시오.
다중 AZ 배포에서 Amazon RDS는 자동으로 서로 다른 가용 영역에 동기식 예비 복제본을 프로비저닝하고 유지합니다. 기본 DB 인스턴스는 가용 영역 전체에서 대기 복제본으로 동기식으로 복제됩니다. 이 기능은 데이터 중복을 제공하고, I/O 중지를 없애고, 시스템 백업 중에 지연 시간 스파이크를 최소화합니다.
+ AWS SCT 는 Amazon RDS for Oracle로 마이그레이션할 때 Oracle DBMS\$1SCHEDULER 객체 변환을 지원합니다. AWS SCT 평가 보고서는 일정 객체를 변환할 수 있는지 여부를 나타냅니다. Amazon RDS에서 일정 객체를 사용하는 방법에 대한 자세한 내용은 [Amazon RDS 설명서](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.System.html#Appendix.Oracle.CommonDBATasks.ModifyScheduler) 를 참조하십시오.
+ Oracle에서 Oracle용 Amazon RDS로 변환하는 경우 DB Links를 지원합니다. 데이터베이스 링크는 특정 데이터베이스 내 스키마 객체로서, 사용자는 이 객체를 통해 다른 데이터베이스에 있는 객체에 액세스할 수 있습니다. 다른 데이터베이스가 Oracle 데이터베이스이어야 할 필요는 없습니다. 하지만 Oracle 데이터베이스가 아닌 데이터베이스에 액세스하려면 Oracle Heterogeneous Services를 사용해야 합니다.
데이터베이스 링크를 생성하면 이 링크를 SQL 문에서 사용하여 다른 데이터베이스에 있는 테이블, 보기 및 PL/SQL 객체를 참조할 수 있습니다. 데이터베이스 링크를 사용하려면 테이블, 보기 또는 PL/SQL 객체 이름에 `@dblink`를 붙입니다. SELECT 문을 사용해 다른 데이터베이스에 있는 테이블 또는 보기를 쿼리할 수 있습니다. Oracle 데이터베이스 링크를 사용하는 방법에 대한 자세한 정보는 [ Oracle 설명서](https://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts002.htm#ADMIN12083)를 참조하십시오.
Amazon RDS에서 데이터베이스 링크를 사용하는 방법에 대한 자세한 정보는 [ Amazon RDS 설명서](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.Database.html#Appendix.Oracle.CommonDBATasks.DBLinks)를 참조하십시오.
+ AWS SCT 평가 보고서는 변환을 위한 서버 지표를 제공합니다. Oracle 인스턴스에 대한 이러한 측정치에는 다음이 포함됩니다.
+ 대상 DB 인스턴스의 컴퓨팅 및 메모리 용량
+ 지원되지 않는 Oracle 기능(예: Amazon RDS가 지원하지 않는 Real Application Clusters 등)
+ 디스크 읽기/쓰기 로드
+ 평균 총 디스크 처리량
+ 서버 정보(서버 이름, OS, 호스트 이름, 문자 집합 등)
## RDS for Oracle을 대상으로 사용하기 위한 권한
Amazon RDS for Oracle로 마이그레이션하려면 권한이 있는 데이터베이스 사용자를 생성합니다. 다음과 같은 코드 예제를 사용할 수 있습니다.
```
CREATE USER user_name IDENTIFIED BY your_password;
-- System privileges
GRANT DROP ANY CUBE BUILD PROCESS TO user_name;
GRANT ALTER ANY CUBE TO user_name;
GRANT CREATE ANY CUBE DIMENSION TO user_name;
GRANT CREATE ANY ASSEMBLY TO user_name;
GRANT ALTER ANY RULE TO user_name;
GRANT SELECT ANY DICTIONARY TO user_name;
GRANT ALTER ANY DIMENSION TO user_name;
GRANT CREATE ANY DIMENSION TO user_name;
GRANT ALTER ANY TYPE TO user_name;
GRANT DROP ANY TRIGGER TO user_name;
GRANT CREATE ANY VIEW TO user_name;
GRANT ALTER ANY CUBE BUILD PROCESS TO user_name;
GRANT CREATE ANY CREDENTIAL TO user_name;
GRANT DROP ANY CUBE DIMENSION TO user_name;
GRANT DROP ANY ASSEMBLY TO user_name;
GRANT DROP ANY PROCEDURE TO user_name;
GRANT ALTER ANY PROCEDURE TO user_name;
GRANT ALTER ANY SQL TRANSLATION PROFILE TO user_name;
GRANT DROP ANY MEASURE FOLDER TO user_name;
GRANT CREATE ANY MEASURE FOLDER TO user_name;
GRANT DROP ANY CUBE TO user_name;
GRANT DROP ANY MINING MODEL TO user_name;
GRANT CREATE ANY MINING MODEL TO user_name;
GRANT DROP ANY EDITION TO user_name;
GRANT CREATE ANY EVALUATION CONTEXT TO user_name;
GRANT DROP ANY DIMENSION TO user_name;
GRANT ALTER ANY INDEXTYPE TO user_name;
GRANT DROP ANY TYPE TO user_name;
GRANT CREATE ANY PROCEDURE TO user_name;
GRANT CREATE ANY SQL TRANSLATION PROFILE TO user_name;
GRANT CREATE ANY CUBE TO user_name;
GRANT COMMENT ANY MINING MODEL TO user_name;
GRANT ALTER ANY MINING MODEL TO user_name;
GRANT DROP ANY SQL PROFILE TO user_name;
GRANT CREATE ANY JOB TO user_name;
GRANT DROP ANY EVALUATION CONTEXT TO user_name;
GRANT ALTER ANY EVALUATION CONTEXT TO user_name;
GRANT CREATE ANY INDEXTYPE TO user_name;
GRANT CREATE ANY OPERATOR TO user_name;
GRANT CREATE ANY TRIGGER TO user_name;
GRANT DROP ANY ROLE TO user_name;
GRANT DROP ANY SEQUENCE TO user_name;
GRANT DROP ANY CLUSTER TO user_name;
GRANT DROP ANY SQL TRANSLATION PROFILE TO user_name;
GRANT ALTER ANY ASSEMBLY TO user_name;
GRANT CREATE ANY RULE SET TO user_name;
GRANT ALTER ANY OUTLINE TO user_name;
GRANT UNDER ANY TYPE TO user_name;
GRANT CREATE ANY TYPE TO user_name;
GRANT DROP ANY MATERIALIZED VIEW TO user_name;
GRANT ALTER ANY ROLE TO user_name;
GRANT DROP ANY VIEW TO user_name;
GRANT ALTER ANY INDEX TO user_name;
GRANT COMMENT ANY TABLE TO user_name;
GRANT CREATE ANY TABLE TO user_name;
GRANT CREATE USER TO user_name;
GRANT DROP ANY RULE SET TO user_name;
GRANT CREATE ANY CONTEXT TO user_name;
GRANT DROP ANY INDEXTYPE TO user_name;
GRANT ALTER ANY OPERATOR TO user_name;
GRANT CREATE ANY MATERIALIZED VIEW TO user_name;
GRANT ALTER ANY SEQUENCE TO user_name;
GRANT DROP ANY SYNONYM TO user_name;
GRANT CREATE ANY SYNONYM TO user_name;
GRANT DROP USER TO user_name;
GRANT ALTER ANY MEASURE FOLDER TO user_name;
GRANT ALTER ANY EDITION TO user_name;
GRANT DROP ANY RULE TO user_name;
GRANT CREATE ANY RULE TO user_name;
GRANT ALTER ANY RULE SET TO user_name;
GRANT CREATE ANY OUTLINE TO user_name;
GRANT UNDER ANY TABLE TO user_name;
GRANT UNDER ANY VIEW TO user_name;
GRANT DROP ANY DIRECTORY TO user_name;
GRANT ALTER ANY CLUSTER TO user_name;
GRANT CREATE ANY CLUSTER TO user_name;
GRANT ALTER ANY TABLE TO user_name;
GRANT CREATE ANY CUBE BUILD PROCESS TO user_name;
GRANT ALTER ANY CUBE DIMENSION TO user_name;
GRANT CREATE ANY EDITION TO user_name;
GRANT CREATE ANY SQL PROFILE TO user_name;
GRANT ALTER ANY SQL PROFILE TO user_name;
GRANT DROP ANY OUTLINE TO user_name;
GRANT DROP ANY CONTEXT TO user_name;
GRANT DROP ANY OPERATOR TO user_name;
GRANT DROP ANY LIBRARY TO user_name;
GRANT ALTER ANY LIBRARY TO user_name;
GRANT CREATE ANY LIBRARY TO user_name;
GRANT ALTER ANY MATERIALIZED VIEW TO user_name;
GRANT ALTER ANY TRIGGER TO user_name;
GRANT CREATE ANY SEQUENCE TO user_name;
GRANT DROP ANY INDEX TO user_name;
GRANT CREATE ANY INDEX TO user_name;
GRANT DROP ANY TABLE TO user_name;
GRANT SELECT_CATALOG_ROLE TO user_name;
GRANT SELECT ANY SEQUENCE TO user_name;
-- Database Links
GRANT CREATE DATABASE LINK TO user_name;
GRANT CREATE PUBLIC DATABASE LINK TO user_name;
GRANT DROP PUBLIC DATABASE LINK TO user_name;
-- Server Level Objects (directory)
GRANT CREATE ANY DIRECTORY TO user_name;
GRANT DROP ANY DIRECTORY TO user_name;
-- (for RDS only)
GRANT EXECUTE ON RDSADMIN.RDSADMIN_UTIL TO user_name;
-- Server Level Objects (tablespace)
GRANT CREATE TABLESPACE TO user_name;
GRANT DROP TABLESPACE TO user_name;
-- Server Level Objects (user roles)
/* (grant source privileges with admin option or convert roles/privs as DBA) */
-- Queues
grant execute on DBMS_AQADM to user_name;
grant aq_administrator_role to user_name;
-- for Materialized View Logs creation
GRANT SELECT ANY TABLE TO user_name;
-- Roles
GRANT RESOURCE TO user_name;
GRANT CONNECT TO user_name;
```
이전 예제에서 *user\$1name*을 사용자 이름으로 바꿉니다. 그런 다음 *your\$1password*를 안전한 암호로 바꿉니다.
## Oracle에서 Amazon RDS for Oracle로 변환할 때 제한 사항
Oracle 스키마와 코드를 Amazon RDS for Oracle로 마이그레이션할 경우 몇 가지 제한 사항을 고려해야 합니다.
+ Amazon RDS의 사전 정의된 역할인 DBA는 일반적으로 Oracle 데이터베이스 엔진에 대한 모든 관리 권한을 허용합니다. 아래의 권한들은 Oracle 엔진을 사용하는 Amazon RDS DB 인스턴스의 DBA 역할에는 사용할 수 없습니다.
+ 데이터베이스 변경
+ 시스템 변경
+ 디렉터리 생성
+ 권한 부여
+ 역할 부여
+ 외부 작업 생성
다른 모든 권한을 Oracle RDS 사용자 역할에 부여할 수 있습니다.
+ Amazon RDS for Oracle은 기존 방식의 감사, DBMS\$1FGA 패키지를 사용한 세분화된 감사 및 Oracle Unified Auditing을 지원합니다.
+ Amazon RDS for Oracle은 CDC(변경 데이터 캡처)를 지원하지 않습니다. 데이터 마이그레이션 도중이나 그 이후에 CDC를 수행하려면 AWS Database Migration Service를 사용합니다.
# 를 사용하여 PostgreSQL 데이터베이스에 연결 AWS Schema Conversion Tool
AWS SCT 를 사용하여 스키마, 데이터베이스 코드 객체 및 애플리케이션 코드를 PostgreSQL에서 다음 대상으로 변환할 수 있습니다.
+ Amazon RDS for MySQL
+ Amazon Aurora MySQL 호환 버전
+ Amazon RDS for PostgreSQL
+ Amazon Aurora PostgreSQL 호환 에디션
자세한 내용은 다음 단원을 참조하세요.
**Topics**
+ [PostgreSQL을 소스 데이터베이스로 사용할 수 있는 권한](#CHAP_Source.PostgreSQL.Permissions)
+ [PostgreSQL에 소스로 연결](#CHAP_Source.PostgreSQL.Connecting)
+ [MySQL을 대상 데이터베이스로 사용하기 위한 권한](#CHAP_Source.PostgreSQL.ConfigureMySQL)
## PostgreSQL을 소스 데이터베이스로 사용할 수 있는 권한
PostgreSQL을 소스로 사용하기 위해 필요한 권한은 다음과 같습니다.
+ CONNECT ON DATABASE **
+ USAGE ON SCHEMA **
+ SELECT ON ALL TABLES IN SCHEMA **
+ SELECT ON ALL SEQUENCES IN SCHEMA **
## PostgreSQL에 소스로 연결
다음 절차에 따라 AWS Schema Conversion Tool을 사용하여 PostgreSQL 소스 데이터베이스에 연결합니다.
**PostgreSQL 소스 데이터베이스에 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **PostgreSQL**을 선택한 후 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 데이터베이스의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. 에서 데이터베이스 자격 증명을 사용하거나 수동으로 AWS Secrets Manager 입력합니다.
+ Secrets Manager의 데이터베이스 보안 인증 정보를 사용하려면 다음 지침을 따릅니다.
1. **AWS Secret**에서 보안 암호의 이름을 선택합니다.
1. **Populate**를 선택하여 Secrets Manager에서 데이터베이스 연결 대화 상자에 있는 모든 값을 자동으로 채웁니다.
Secrets Manager의 데이터베이스 보안 인증 사용에 대한 자세한 내용은 [AWS Secrets Manager 에서 구성 AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md) 섹션을 참조하세요.
+ PostgreSQL 소스 데이터베이스 연결 정보를 수동으로 입력하려면 다음 지침을 사용합니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.PostgreSQL.html)
1. **연결 테스트를** 선택하여가 소스 데이터베이스에 연결할 AWS SCT 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 데이터베이스에 연결합니다.
## MySQL을 대상 데이터베이스로 사용하기 위한 권한
PostgreSQL에서 마이그레이션할 때 MySQL을 대상으로 사용하기 위해 필요한 권한은 다음과 같습니다.
+ CREATE ON \$1.\$1
+ ALTER ON \$1.\$1
+ DROP ON \$1.\$1
+ INDEX ON \$1.\$1
+ REFERENCES ON \$1.\$1
+ SELECT ON \$1.\$1
+ CREATE VIEW ON \$1.\$1
+ SHOW VIEW ON \$1.\$1
+ TRIGGER ON \$1.\$1
+ CREATE ROUTINE ON \$1.\$1
+ ALTER ROUTINE ON \$1.\$1
+ EXECUTE ON \$1.\$1
+ INSERT, UPDATE ON AWS\$1POSTGRESQL\$1EXT.\$1
+ INSERT, UPDATE, DELETE ON AWS\$1POSTGRESQL\$1EXT\$1DATA.\$1
+ CREATE TEMPORARY TABLES ON AWS\$1POSTGRESQL\$1EXT\$1DATA.\$1
다음 코드 예제를 사용하여 데이터베이스 사용자를 생성하고 권한을 부여할 수 있습니다.
```
CREATE USER 'user_name' IDENTIFIED BY 'your_password';
GRANT CREATE ON *.* TO 'user_name';
GRANT ALTER ON *.* TO 'user_name';
GRANT DROP ON *.* TO 'user_name';
GRANT INDEX ON *.* TO 'user_name';
GRANT REFERENCES ON *.* TO 'user_name';
GRANT SELECT ON *.* TO 'user_name';
GRANT CREATE VIEW ON *.* TO 'user_name';
GRANT SHOW VIEW ON *.* TO 'user_name';
GRANT TRIGGER ON *.* TO 'user_name';
GRANT CREATE ROUTINE ON *.* TO 'user_name';
GRANT ALTER ROUTINE ON *.* TO 'user_name';
GRANT EXECUTE ON *.* TO 'user_name';
GRANT INSERT, UPDATE ON AWS_POSTGRESQL_EXT.* TO 'user_name';
GRANT INSERT, UPDATE, DELETE ON AWS_POSTGRESQL_EXT_DATA.* TO 'user_name';
GRANT CREATE TEMPORARY TABLES ON AWS_POSTGRESQL_EXT_DATA.* TO 'user_name';
```
이전 예제에서 *user\$1name*을 사용자 이름으로 바꿉니다. 그런 다음 *your\$1password*를 안전한 암호로 바꿉니다.
Amazon RDS for MySQL 또는 Amazon RDS for Aurora MySQL을 대상으로 사용하려면 `lower_case_table_names` 파라미터를 `1`로 설정합니다. 이 값은 MySQL 서버가 테이블, 인덱스, 트리거 및 데이터베이스와 같은 객체 이름의 식별자를 대소문자 구분 없이 처리한다는 것을 의미합니다. 대상 인스턴스에서 이진 로깅을 활성화했다면 `log_bin_trust_function_creators` 파라미터를 `1`로 설정합니다. 이 경우 저장된 함수를 생성하기 위해 `DETERMINISTIC`, `READS SQL DATA` 또는 `NO SQL` 특성을 사용할 필요가 없습니다. 이들 파라미터를 구성하려면 새 DB 파라미터 그룹을 생성하거나 기존 DB 파라미터 그룹을 수정해야 합니다.
# 를 사용하여 SAP 데이터베이스에 연결 AWS Schema Conversion Tool
AWS SCT 를 사용하여 SAP(Sybase) Adaptive Server Enterprise(ASE)의 스키마, 데이터베이스 코드 객체 및 애플리케이션 코드를 다음 대상으로 변환할 수 있습니다.
+ Amazon RDS for MySQL
+ Amazon Aurora MySQL 호환 버전
+ Amazon RDS for MariaDB
+ Amazon RDS for PostgreSQL
+ Amazon Aurora PostgreSQL 호환 에디션
자세한 내용은 다음 단원을 참조하세요.
**Topics**
+ [SAP ASE를 소스 데이터베이스로 사용할 수 있는 권한](#CHAP_Source.SAP.Permissions)
+ [SAP ASE(Sybase) 소스에 연결](#CHAP_Source.SAP.Connecting)
+ [MySQL을 대상 데이터베이스로 사용하기 위한 권한](#CHAP_Source.SAP.ConfigureMySQL)
+ [SAP ASE에서 MySQL로 변환 설정](#CHAP_Source.SAP.MySQLConversionSettings)
+ [PostgreSQL을 대상 데이터베이스로 사용하기 위한 권한](#CHAP_Source.SAP.ConfigurePostgreSQL)
+ [SAP ASE에서 PostgreSQL로 변환 설정](#CHAP_Source.SAP.PostgreSQLConversionSettings)
## SAP ASE를 소스 데이터베이스로 사용할 수 있는 권한
SAP ASE 데이터베이스를 소스로 사용하려면 데이터베이스 사용자를 생성하고 권한을 부여해야 합니다. 이 작업을 수행하려면 다음 단계를 수행합니다.
**데이터베이스 사용자 생성 및 구성**
1. 소스 데이터베이스에 연결합니다.
1. 다음 명령을 사용하여 데이터베이스 사용자를 생성합니다. 새 사용자의 암호를 입력합니다.
```
USE master
CREATE LOGIN min_privs WITH PASSWORD
sp_adduser min_privs
grant select on dbo.spt_values to min_privs
grant select on asehostname to min_privs
```
1. 마이그레이션하려는 모든 데이터베이스에 대해 다음 권한을 부여합니다.
```
USE
sp_adduser min_privs
grant select on dbo.sysusers to min_privs
grant select on dbo.sysobjects to min_privs
grant select on dbo.sysindexes to min_privs
grant select on dbo.syscolumns to min_privs
grant select on dbo.sysreferences to min_privs
grant select on dbo.syscomments to min_privs
grant select on dbo.syspartitions to min_privs
grant select on dbo.syspartitionkeys to min_privs
grant select on dbo.sysconstraints to min_privs
grant select on dbo.systypes to min_privs
grant select on dbo.sysqueryplans to min_privs
```
## SAP ASE(Sybase) 소스에 연결
다음 절차에 따라 AWS Schema Conversion Tool을 사용하여 SAP ASE 소스 데이터베이스에 연결합니다.
**SAP ASE 소스 데이터베이스에 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **SAP ASE**를 선택하고 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 데이터베이스의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. 에서 데이터베이스 자격 증명을 사용하거나 수동으로 AWS Secrets Manager 입력합니다.
+ Secrets Manager의 데이터베이스 보안 인증 정보를 사용하려면 다음 지침을 따릅니다.
1. **AWS Secret**에서 보안 암호의 이름을 선택합니다.
1. **Populate**를 선택하여 Secrets Manager에서 데이터베이스 연결 대화 상자에 있는 모든 값을 자동으로 채웁니다.
Secrets Manager의 데이터베이스 보안 인증 사용에 대한 자세한 내용은 [AWS Secrets Manager 에서 구성 AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md) 섹션을 참조하세요.
+ SAP ASE 소스 데이터베이스 연결 정보를 수동으로 입력하려면 다음 지침을 사용합니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.SAP.html)
1. **연결 테스트를** 선택하여가 소스 데이터베이스에 연결할 AWS SCT 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 데이터베이스에 연결합니다.
## MySQL을 대상 데이터베이스로 사용하기 위한 권한
MySQL을 대상으로 사용하기 위해 필요한 권한은 다음과 같습니다.
+ CREATE ON \$1.\$1
+ ALTER ON \$1.\$1
+ DROP ON \$1.\$1
+ INDEX ON \$1.\$1
+ REFERENCES ON \$1.\$1
+ SELECT ON \$1.\$1
+ CREATE VIEW ON \$1.\$1
+ SHOW VIEW ON \$1.\$1
+ TRIGGER ON \$1.\$1
+ CREATE ROUTINE ON \$1.\$1
+ ALTER ROUTINE ON \$1.\$1
+ EXECUTE ON \$1.\$1
+ INSERT, UPDATE ON AWS\$1SAPASE\$1EXT.\$1
+ CREATE TEMPORARY TABLES ON AWS\$1SAPASE\$1EXT.\$1
다음 코드 예제를 사용하여 데이터베이스 사용자를 생성하고 권한을 부여할 수 있습니다.
```
CREATE USER 'user_name' IDENTIFIED BY 'your_password';
GRANT CREATE ON *.* TO 'user_name';
GRANT ALTER ON *.* TO 'user_name';
GRANT DROP ON *.* TO 'user_name';
GRANT INDEX ON *.* TO 'user_name';
GRANT REFERENCES ON *.* TO 'user_name';
GRANT SELECT ON *.* TO 'user_name';
GRANT CREATE VIEW ON *.* TO 'user_name';
GRANT SHOW VIEW ON *.* TO 'user_name';
GRANT TRIGGER ON *.* TO 'user_name';
GRANT CREATE ROUTINE ON *.* TO 'user_name';
GRANT ALTER ROUTINE ON *.* TO 'user_name';
GRANT EXECUTE ON *.* TO 'user_name';
GRANT INSERT, UPDATE ON AWS_SAPASE_EXT.* TO 'user_name';
GRANT CREATE TEMPORARY TABLES ON AWS_SAPASE_EXT.* TO 'user_name';
```
이전 예제에서 *user\$1name*을 사용자 이름으로 바꿉니다. 그런 다음 *your\$1password*를 안전한 암호로 바꿉니다.
Amazon RDS for MySQL 또는 Amazon RDS for Aurora MySQL을 대상으로 사용하려면 `lower_case_table_names` 파라미터를 `1`로 설정합니다. 이 값은 MySQL 서버가 테이블, 인덱스, 트리거 및 데이터베이스와 같은 객체 이름의 식별자를 대소문자 구분 없이 처리한다는 것을 의미합니다. 대상 인스턴스에서 이진 로깅을 활성화했다면 `log_bin_trust_function_creators` 파라미터를 `1`로 설정합니다. 이 경우 저장된 함수를 생성하기 위해 `DETERMINISTIC`, `READS SQL DATA` 또는 `NO SQL` 특성을 사용할 필요가 없습니다. 이들 파라미터를 구성하려면 새 DB 파라미터 그룹을 생성하거나 기존 DB 파라미터 그룹을 수정해야 합니다.
## SAP ASE에서 MySQL로 변환 설정
SAP ASE에서 MySQL로의 변환 설정을 편집하려면 **설정**을 선택한 다음 **변환 설정**을 선택합니다. 상단 목록에서 **SAP ASE**를 선택한 다음 **SAP ASE – MySQL** 또는 **SAP ASE – Amazon Aurora (MySQL compatible)**를 선택합니다. AWS SCT 는 SAP ASE에서 PostgreSQL로의 변환에 사용할 수 있는 모든 설정을 표시합니다.
의 SAP ASE에서 MySQL로의 변환 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 변환된 코드에서 소스 데이터베이스 객체의 정확한 이름을 사용합니다.
기본적으로는 데이터베이스 객체, 변수 및 파라미터의 이름을 소문자로 AWS SCT 변환합니다. 이러한 이름에서 원래의 대/소문자를 유지하려면 **Treat source database object names as case sensitive**를 선택합니다. 소스 SAP ASE 데이터베이스 서버에서 대소문자를 구분한 객체 이름을 사용하는 경우 이 옵션을 선택합니다.
## PostgreSQL을 대상 데이터베이스로 사용하기 위한 권한
PostgreSQL을 대상으로 사용하려면 `CREATE ON DATABASE`에 권한이 AWS SCT 필요합니다. 각 대상 PostgreSQL 데이터베이스에 대해 이 권한을 부여해야 합니다.
변환된 공개 동의어를 사용하려면 데이터베이스 기본 검색 경로를 `"$user", public_synonyms, public`으로 변경합니다.
다음 코드 예제를 사용하여 데이터베이스 사용자를 생성하고 권한을 부여할 수 있습니다.
```
CREATE ROLE user_name LOGIN PASSWORD 'your_password';
GRANT CREATE ON DATABASE db_name TO user_name;
ALTER DATABASE db_name SET SEARCH_PATH = "$user", public_synonyms, public;
```
이전 예제에서 *user\$1name*을 사용자 이름으로 바꿉니다. 그런 다음 *db\$1name*을 대상 데이터베이스의 이름으로 바꿉니다. 마지막으로 *your\$1password*를 안전한 암호로 바꿉니다.
PostgreSQL에서는 스키마 소유자 또는 `superuser`만 스키마를 삭제할 수 있습니다. 소유자는 스키마 소유자가 일부 객체를 소유하지 않은 경우에도 스키마 및 이 스키마에 포함된 모든 객체를 삭제할 수 있습니다.
다른 사용자를 사용하여 대상 데이터베이스에 다른 스키마를 변환하고 적용하는 경우에서 스키마를 삭제할 수 없는 경우 오류 메시지가 표시될 AWS SCT 수 있습니다. 이 오류 메시지가 표시되지 않도록 하려면 `superuser` 역할을 사용하세요.
## SAP ASE에서 PostgreSQL로 변환 설정
SAP ASE에서 PostgreSQL로의 변환 설정을 편집하려면 **설정**을 선택한 다음 **변환 설정**을 선택합니다. 상단 목록에서 **SAP ASE**를 선택한 다음 **SAP ASE – PostgreSQL** 또는 **SAP ASE – Amazon Aurora (PostgreSQL compatible)**를 선택합니다. AWS SCT 는 SAP ASE에서 PostgreSQL로의 변환에 사용할 수 있는 모든 설정을 표시합니다.
의 SAP ASE에서 PostgreSQL로의 변환 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 변환된 코드의 스키마 이름에 사용할 템플릿을 정의합니다. **Schema name generation template**에서 다음 옵션 중 하나를 선택합니다.
+ **** – PostgreSQL에서 SAP ASE 데이터베이스 이름을 스키마 이름으로 사용합니다.
+ **** – PostgreSQL에서 SAP ASE 스키마 이름을 스키마 이름으로 사용합니다.
+ **\$1** – PostgreSQL에서 SAP ASE 데이터베이스와 스키마 이름의 조합을 스키마 이름으로 사용합니다.
+ 변환된 코드에서 소스 데이터베이스 객체의 정확한 이름을 사용합니다.
기본적으로는 데이터베이스 객체, 변수 및 파라미터의 이름을 소문자로 AWS SCT 변환합니다. 이러한 이름에서 원래의 대/소문자를 유지하려면 **Treat source database object names as case sensitive**를 선택합니다. 소스 SAP ASE 데이터베이스 서버에서 대소문자를 구분한 객체 이름을 사용하는 경우 이 옵션을 선택합니다.
대소문자를 구분하는 작업의 경우 데이터베이스 객체 이름을 소문자로 변환하지 않아도 AWS SCT 됩니다. 이렇게 하려면 **Avoid casting to lowercase for case sensitive operations**를 선택합니다.
+ SAP ASE의 여러 테이블에서 이름이 같은 인덱스를 사용할 수 있도록 합니다.
PostgreSQL에서는 스키마에서 사용하는 모든 인덱스 이름이 고유해야 합니다. 가 모든 인덱스에 대해 고유한 이름을 AWS SCT 생성하도록 하려면 **인덱스에 대해 고유한 이름 생성을** 선택합니다.
# 를 사용하여 Microsoft SQL Server 연결 AWS Schema Conversion Tool
AWS SCT 를 사용하여 스키마, 데이터베이스 코드 객체 및 애플리케이션 코드를 SQL Server에서 다음 대상으로 변환할 수 있습니다.
+ Amazon RDS for MySQL
+ Amazon Aurora MySQL 호환 버전
+ Amazon RDS for PostgreSQL
+ Amazon Aurora PostgreSQL 호환 에디션
+ Amazon RDS for SQL Server
+ Amazon RDS for MariaDB
**참고**
AWS SCT 는 Amazon RDS for SQL 서버를 소스로 사용하는 것을 지원하지 않습니다.
AWS SCT 를 사용하여 다음에 설명된 대로 SQL Server에서 Babelfish for Aurora PostgreSQL로 스키마, 데이터베이스 코드 객체 및 애플리케이션 코드를 마이그레이션하기 위한 평가 보고서를 생성할 수 있습니다.
**Topics**
+ [Microsoft SQL Server를 소스로 사용하기 위한 권한](#CHAP_Source.SQLServer.Permissions)
+ [Microsoft SQL Server를 소스로 사용할 때 Windows 인증 사용](#CHAP_Source.SQLServer.Permissions.WinAuth)
+ [SQL Server에 소스 연결](#CHAP_Source.SQLServer.Connecting)
+ [SQL Server를 MySQL로 변환](CHAP_Source.SQLServer.ToMySQL.md)
+ [를 사용하여 SQL Server에서 PostgreSQL로 마이그레이션 AWS Schema Conversion Tool](CHAP_Source.SQLServer.ToPostgreSQL.md)
+ [를 사용하여 SQL Server에서 Amazon RDS for SQL Server로 마이그레이션 AWS Schema Conversion Tool](CHAP_Source.SQLServer.ToRDSSQLServer.md)
## Microsoft SQL Server를 소스로 사용하기 위한 권한
Microsoft SQL Server를 소스로 사용하기 위해 필요한 권한은 다음과 같습니다.
+ VIEW DEFINITION
+ VIEW DATABASE STATE
권한을 사용하면 퍼블릭 액세스 권한이 있는 사용자가 객체 `VIEW DEFINITION` 정의를 볼 수 있습니다. `VIEW DATABASE STATE`는 권한을 AWS SCT 사용하여 SQL Server Enterprise 에디션의 기능을 확인할 수 있습니다.
변환하려는 스키마의 각 데이터베이스에 대해 권한 부여를 반복합니다.
또한 `master` 데이터베이스에 다음 권한을 부여합니다.
+ VIEW SERVER STATE
+ VIEW ANY DEFINITION
AWS SCT 는 `VIEW SERVER STATE` 권한을 사용하여 서버 설정 및 구성을 수집합니다. 엔드포인트를 보려면 `VIEW ANY DEFINITION` 권한을 부여해야 합니다.
Microsoft Analysis Services에 관한 정보를 읽으려면 `master` 데이터베이스에서 다음 명령을 실행합니다.
```
EXEC master..sp_addsrvrolemember @loginame = N'', @rolename = N'sysadmin'
```
이전 예제에서 `` 자리 표시자를 이전에 권한을 부여한 사용자의 이름으로 바꿉니다.
SQL Server 에이전트에 관한 정보를 읽으려면 사용자를 `SQLAgentUser` 역할에 추가합니다. `msdb` 데이터베이스에서 다음 명령을 실행합니다.
```
EXEC sp_addrolemember , ;
```
앞의 예제에서 `` 자리 표시자를 SQL Server 에이전트 역할의 이름으로 바꿉니다. 그런 다음, `` 자리 표시자를 이전에 권한을 부여한 사용자의 이름으로 바꿉니다. 자세한 내용은 *Amazon RDS 사용 설명서*의 [SQLAgentUser 역할에 사용자 추가](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.SQLServer.CommonDBATasks.Agent.html#SQLServerAgent.AddUser)를 참조하세요.
로그 전달을 감지하려면 `msdb` 데이터베이스에 대한 `SELECT on dbo.log_shipping_primary_databases` 권한을 부여합니다.
DDL 복제의 알림 방식을 사용하려면 소스 데이터베이스에 대해 `RECEIVE ON .` 권한을 부여합니다. 이 예제에서는 `` 자리 표시자를 데이터베이스의 스키마 이름으로 바꿉니다. 그런 다음, `` 자리 표시자를 대기열 테이블 이름으로 바꿉니다.
## Microsoft SQL Server를 소스로 사용할 때 Windows 인증 사용
Windows 기반 인트라넷에서 애플리케이션을 실행하는 경우 데이터베이스 액세스에 Windows 인증을 사용할 수 있습니다. Windows 인증은 운영 체제 스레드에 설정된 현재 Windows ID를 사용하여 SQL Server 데이터베이스에 액세스합니다. 그런 다음 Windows ID를 SQL Server 데이터베이스 및 권한에 매핑할 수 있습니다. Windows 인증을 사용하여 SQL Server에 연결하려면 애플리케이션에서 사용하는 Windows ID를 지정해야 합니다. 또한 SQL Server 데이터베이스에 대한 Windows ID 액세스 권한을 부여해야 합니다.
SQL Server에는 Windows 인증 모드와 혼합 모드의 두 가지 액세스 모드가 있습니다. Windows 인증 모드에서는 Windows 인증을 활성화하고 SQL Server 인증을 비활성화합니다. 혼합 모드에서는 Windows 인증과 SQL Server 인증을 모두 사용할 수 있습니다. Windows 인증은 항상 사용할 수 있으며 비활성화할 수 없습니다. Windows 인증에 대한 자세한 내용은 Microsoft Windows 설명서를 참조하세요.
다음은 TEST\$1DB에 사용자를 생성하는 것을 보여주는 예입니다.
```
USE [TEST_DB]
CREATE USER [TestUser] FOR LOGIN [TestDomain\TestUser]
GRANT VIEW DEFINITION TO [TestUser]
GRANT VIEW DATABASE STATE TO [TestUser]
```
### JDBC 연결에서 Windows 인증 사용
JDBC 드라이버는 Windows 이외의 운영 체제에서 사용되는 경우 Windows 인증을 지원하지 않습니다. Windows 이외의 운영 체제에서 SQL Server에 연결할 때는 사용자 이름 및 암호와 같은 Windows 인증 보안 인증 정보가 자동으로 지정되지 않습니다. 이 경우 애플리케이션은 SQL Server 인증을 대신 사용해야 합니다.
JDBC 연결 문자열에서 Windows 인증을 사용하여 연결하려면 `integratedSecurity` 파라미터를 지정해야 합니다. JDBC 드라이버는 `integratedSecurity` 연결 문자열 파라미터를 통해 Windows 운영 체제에서 Windows 통합 인증을 지원합니다.
통합 인증을 사용하려면
1. JDBC 드라이버를 설치합니다.
1. JDBC 드라이버가 설치된 컴퓨터의 Windows 시스템 경로에 있는 디렉터리에 `sqljdbc_auth.dll` 파일을 복사합니다.
`sqljdbc_auth.dll` 파일은 다음 위치에 설치됩니다.
\$1sqljdbc\$1\$1\$1auth\$1******
Windows 인증을 사용하여 SQL Server 데이터베이스에 연결을 시도하는 경우 "이 드라이버는 통합 인증에 맞게 구성되지 않았습니다"라는 오류가 발생할 수 있습니다. 이 문제는 다음 작업을 수행하여 해결할 수 있습니다.
+ 다음과 같이 JDBC 설치 경로를 가리키는 두 가지 변수를 선언합니다.
`variable name: SQLJDBC_HOME; variable value: D:\lib\JDBC4.1\enu`(sqljdbc4.jar이 있는 위치);
`variable name: SQLJDBC_AUTH_HOME; variable value: D\lib\JDBC4.1\enu\auth\x86`(32비트 OS를 실행하는 경우) 또는 `D\lib\JDBC4.1\enu\auth\x64`(64비트 OS를 실행하는 경우). `sqljdbc_auth.dll`이 있는 위치입니다.
+ JDK/JRE가 실행 중인 폴더에 `sqljdbc_auth.dll`을 복사합니다. lib 폴더, bin 폴더 등에 복사할 수 있습니다. 예를 들어 다음 폴더에 복사할 수 있습니다.
```
[JDK_INSTALLED_PATH]\bin;
[JDK_INSTALLED_PATH]\jre\bin;
[JDK_INSTALLED_PATH]\jre\lib;
[JDK_INSTALLED_PATH]\lib;
```
+ JDBC 라이브러리 폴더에는 SQLJDBC4.jar 파일만 있어야 합니다. 이 폴더에서 다른 sqljdbc\$1.jar 파일을 모두 제거(또는 다른 폴더로 복사)합니다. 드라이버를 프로그램의 일부로 추가하는 경우 사용할 드라이버로 SQLJDBC4.jar만 추가해야 합니다.
+ 애플리케이션의 해당 폴더에 sqljdbc\$1auth.dll 파일을 복사합니다.
**참고**
32비트 Java Virtual Machine(JVM)을 실행 중인 경우 x86 폴더에 있는 sqljdbc\$1auth.dll 파일을 사용합니다. 이는 운영 체제가 x64 버전인 경우에도 마찬가지입니다. x64 프로세서에서 64비트 JVM을 실행하는 경우에 x64 폴더의 sqljdbc\$1auth.dll 파일을 사용합니다.
SQL Server 데이터베이스에 연결할 때 **인증** 옵션으로 **Windows 인증** 또는 **SQL Server 인증**을 선택할 수 있습니다.
## SQL Server에 소스 연결
다음 절차에 따라 AWS Schema Conversion Tool을 사용하여 Microsoft SQL Server 소스 데이터베이스에 연결합니다.
**Microsoft SQL Server 소스 데이터베이스에 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **Microsoft SQL Server**를 선택한 후 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 데이터베이스의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. 에서 데이터베이스 자격 증명을 사용하거나 수동으로 AWS Secrets Manager 입력합니다.
+ Secrets Manager의 데이터베이스 보안 인증 정보를 사용하려면 다음 지침을 따릅니다.
1. **AWS Secret**에서 보안 암호의 이름을 선택합니다.
1. **Populate**를 선택하여 Secrets Manager에서 데이터베이스 연결 대화 상자에 있는 모든 값을 자동으로 채웁니다.
Secrets Manager의 데이터베이스 보안 인증 사용에 대한 자세한 내용은 [AWS Secrets Manager 에서 구성 AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md) 섹션을 참조하세요.
+ Microsoft SQL Server 소스 데이터베이스 연결 정보를 수동으로 입력하려면 다음 지침을 사용합니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServer.html)
1. **연결 테스트를** 선택하여가 소스 데이터베이스에 연결할 AWS SCT 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 데이터베이스에 연결합니다.
# SQL Server를 MySQL로 변환
변환된 MySQL 코드에서 Microsoft SQL Server 데이터베이스 함수를 에뮬레이션하려면 AWS SCT에서 SQL Server-MySQL 확장 팩을 사용합니다. 확장 팩에 대한 자세한 내용은 [에서 확장 팩 사용 AWS Schema Conversion Tool](CHAP_ExtensionPack.md) 섹션을 참조하세요.
**Topics**
+ [MySQL을 대상 데이터베이스로 사용하기 위한 권한](#CHAP_Source.SQLServer.ToMySQL.ConfigureTarget)
+ [SQL Server에서 MySQL로의 변환 설정](#CHAP_Source.SQLServer.ToMySQL.ConversionSettings)
+ [마이그레이션 고려 사항](#CHAP_Source.SQLServer.ToMySQL.MigrationConsiderations)
## MySQL을 대상 데이터베이스로 사용하기 위한 권한
MySQL을 대상으로 사용하기 위해 필요한 권한은 다음과 같습니다.
+ CREATE ON \$1.\$1
+ ALTER ON \$1.\$1
+ DROP ON \$1.\$1
+ INDEX ON \$1.\$1
+ REFERENCES ON \$1.\$1
+ SELECT ON \$1.\$1
+ CREATE VIEW ON \$1.\$1
+ SHOW VIEW ON \$1.\$1
+ TRIGGER ON \$1.\$1
+ CREATE ROUTINE ON \$1.\$1
+ ALTER ROUTINE ON \$1.\$1
+ EXECUTE ON \$1.\$1
+ INSERT, UPDATE ON AWS\$1SQLSERVER\$1EXT.\$1
+ INSERT, UPDATE, DELETE ON AWS\$1SQLSERVER\$1EXT\$1DATA.\$1
+ CREATE TEMPORARY TABLES ON AWS\$1SQLSERVER\$1EXT\$1DATA.\$1
다음 코드 예제를 사용하여 데이터베이스 사용자를 생성하고 권한을 부여할 수 있습니다.
```
CREATE USER 'user_name' IDENTIFIED BY 'your_password';
GRANT CREATE ON *.* TO 'user_name';
GRANT ALTER ON *.* TO 'user_name';
GRANT DROP ON *.* TO 'user_name';
GRANT INDEX ON *.* TO 'user_name';
GRANT REFERENCES ON *.* TO 'user_name';
GRANT SELECT ON *.* TO 'user_name';
GRANT CREATE VIEW ON *.* TO 'user_name';
GRANT SHOW VIEW ON *.* TO 'user_name';
GRANT TRIGGER ON *.* TO 'user_name';
GRANT CREATE ROUTINE ON *.* TO 'user_name';
GRANT ALTER ROUTINE ON *.* TO 'user_name';
GRANT EXECUTE ON *.* TO 'user_name';
GRANT INSERT, UPDATE ON AWS_SQLSERVER_EXT.* TO 'user_name';
GRANT INSERT, UPDATE, DELETE ON AWS_SQLSERVER_EXT_DATA.* TO 'user_name';
GRANT CREATE TEMPORARY TABLES ON AWS_SQLSERVER_EXT_DATA.* TO 'user_name';
```
이전 예제에서 *user\$1name*을 사용자 이름으로 바꿉니다. 그런 다음 *your\$1password*를 안전한 암호로 바꿉니다.
MySQL 데이터베이스 버전 5.7 이하를 대상으로 사용하는 경우 다음 명령을 실행합니다. MySQL 데이터베이스 버전 8.0 이상에서는 이 명령이 더 이상 사용되지 않습니다.
```
GRANT SELECT ON mysql.proc TO 'user_name';
```
Amazon RDS for MySQL 또는 Amazon RDS for Aurora MySQL을 대상으로 사용하려면 `lower_case_table_names` 파라미터를 `1`로 설정합니다. 이 값은 MySQL 서버가 테이블, 인덱스, 트리거 및 데이터베이스와 같은 객체 이름의 식별자를 대소문자 구분 없이 처리한다는 것을 의미합니다. 대상 인스턴스에서 이진 로깅을 활성화했다면 `log_bin_trust_function_creators` 파라미터를 `1`로 설정합니다. 이 경우 저장된 함수를 생성하기 위해 `DETERMINISTIC`, `READS SQL DATA` 또는 `NO SQL` 특성을 사용할 필요가 없습니다. 이들 파라미터를 구성하려면 새 DB 파라미터 그룹을 생성하거나 기존 DB 파라미터 그룹을 수정해야 합니다.
## SQL Server에서 MySQL로의 변환 설정
SQL Server에서 MySQL로의 변환 설정을 편집하려면에서 **설정을** AWS SCT 선택한 다음 **변환 설정을** 선택합니다. 상단 목록에서 **SQL Server**를 선택한 다음 **SQL Server – MySQL**을 선택합니다. AWS SCT 는 SQL Server에서 MySQL로의 변환에 사용할 수 있는 모든 설정을 표시합니다.
의 SQL Server에서 MySQL로의 변환 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 소스 SQL Server 데이터베이스가의 출력을 table. AWS SCT create`EXEC`s 임시 테이블과이 기능을 에뮬레이션하는 추가 프로시저에 저장할 수 있도록 합니다. 이 에뮬레이션을 사용하려면 **Create additional routines for handling open datasets**를 선택합니다.
## 마이그레이션 고려 사항
SQL Server 스키마를 MySQL로 마이그레이션할 때는 다음 사항을 고려합니다.
+ MySQL은 `MERGE` 문을 지원하지 않습니다. 그러나 AWS SCT 는 변환 중에 `INSERT ON DUPLICATE KEY` 절과 `MERGE` 문을 사용하여 `UPDATE FROM and DELETE FROM` 문을 에뮬레이션할 수 있습니다.
`INSERT ON DUPLICATE KEY`를 사용하여 올바르게 에뮬레이션하기 위해서는 대상 MySQL 데이터베이스에 고유한 제약 조건 또는 프라이머리 키가 있어야 합니다.
+ `GOTO` 문과 레이블을 사용하여 명령문 실행 순서를 변경할 수 있습니다. `GOTO` 문 뒤에 오는 Transact-SQL 문은 건너뛰며 프로세스는 레이블에서 계속됩니다. `GOTO` 문과 레이블은 프로시저, 배치(batch), 명령문 블록 내 어디든 사용할 수 있습니다. `GOTO` 문을 중첩할 수도 있습니다.
MySQL은 `GOTO` 문을 사용하지 않습니다. 는 `GOTO` 문이 포함된 코드를 AWS SCT 변환할 때 `BEGIN…END` 또는 문을 사용하도록 `LOOP…END LOOP` 문을 변환합니다. 다음 표에서가 `GOTO` 문을 AWS SCT 변환하는 방법의 예를 찾을 수 있습니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServer.ToMySQL.html)
+ MySQL은 다중 문 테이블 값 함수를 지원하지 않습니다.는 변환 중에 임시 테이블을 생성하고 이러한 임시 테이블을 사용하도록 문을 다시 작성하여 테이블 값 함수를 AWS SCT 시뮬레이션합니다.
# 를 사용하여 SQL Server에서 PostgreSQL로 마이그레이션 AWS Schema Conversion Tool
AWS SCT에서는 SQL Server에서 PostgreSQL로의 확장 팩을 사용할 수 있습니다. 이 확장 팩은 변환된 PostgreSQL 코드에서 SQL Server 데이터베이스 함수를 에뮬레이션합니다. SQL Server에서 PostgreSQL로의 확장 팩을 사용하여 SQL Server 에이전트 및 SQL Server Database Mail을 에뮬레이션할 수 있습니다. 확장 팩에 대한 자세한 내용은 [에서 확장 팩 사용 AWS Schema Conversion Tool](CHAP_ExtensionPack.md) 섹션을 참조하세요.
**Topics**
+ [PostgreSQL을 대상 데이터베이스로 사용하기 위한 권한](#CHAP_Source.SQLServer.ToPostgreSQL.ConfigurePostgreSQL)
+ [SQL Server에서 PostgreSQL로 변환 설정](#CHAP_Source.SQLServer.ToPostgreSQL.ConversionSettings)
+ [SQL Server 파티션을 PostgreSQL 버전 10 파티션으로 변환](#CHAP_Source.SQLServer.ToPostgreSQL.PG10Partitions)
+ [마이그레이션 고려 사항](#CHAP_Source.SQLServer.ToPostgreSQL.MigrationConsiderations)
+ [AWS SCT 확장 팩을 사용하여 PostgreSQL에서 SQL Server 에이전트 에뮬레이션](CHAP_Source.SQLServer.ToPostgreSQL.ExtensionPack.Agent.md)
+ [AWS SCT 확장 팩을 사용하여 PostgreSQL에서 SQL Server Database Mail 에뮬레이션](CHAP_Source.SQLServer.ToPostgreSQL.ExtensionPack.Mail.md)
## PostgreSQL을 대상 데이터베이스로 사용하기 위한 권한
PostgreSQL을 대상으로 사용하려면 `CREATE ON DATABASE`에 권한이 AWS SCT 필요합니다. 각 대상 PostgreSQL 데이터베이스에 대해 이 권한을 부여해야 합니다.
변환된 공개 동의어를 사용하려면 데이터베이스 기본 검색 경로를 `"$user", public_synonyms, public`으로 변경합니다.
다음 코드 예제를 사용하여 데이터베이스 사용자를 생성하고 권한을 부여할 수 있습니다.
```
CREATE ROLE user_name LOGIN PASSWORD 'your_password';
GRANT CREATE ON DATABASE db_name TO user_name;
ALTER DATABASE db_name SET SEARCH_PATH = "$user", public_synonyms, public;
```
이전 예제에서 *user\$1name*을 사용자 이름으로 바꿉니다. 그런 다음 *db\$1name*을 대상 데이터베이스의 이름으로 바꿉니다. 마지막으로 *your\$1password*를 안전한 암호로 바꿉니다.
PostgreSQL에서는 스키마 소유자 또는 `superuser`만 스키마를 삭제할 수 있습니다. 소유자는 스키마 소유자가 일부 객체를 소유하지 않은 경우에도 스키마 및 이 스키마에 포함된 모든 객체를 삭제할 수 있습니다.
다른 사용자를 사용하여 대상 데이터베이스에 다른 스키마를 변환하고 적용하는 경우에서 스키마를 삭제할 수 없는 경우 오류 메시지가 표시될 AWS SCT 수 있습니다. 이 오류 메시지가 표시되지 않도록 하려면 `superuser` 역할을 사용하세요.
## SQL Server에서 PostgreSQL로 변환 설정
SQL Server에서 PostgreSQL로의 변환 설정을 편집하려면 **설정**을 선택한 다음 **변환 설정**을 선택합니다. 상단 목록에서 **SQL Server**를 선택한 다음 **SQL Server – PostgreSQL**을 선택합니다. AWS SCT 는 SQL Server에서 PostgreSQL로의 변환에 사용할 수 있는 모든 설정을 표시합니다.
의 SQL Server에서 PostgreSQL로의 변환 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ SQL Server의 여러 테이블에서 이름이 같은 인덱스를 사용할 수 있도록 합니다.
PostgreSQL에서는 스키마에서 사용하는 모든 인덱스 이름이 고유해야 합니다. 가 모든 인덱스에 대해 고유한 이름을 AWS SCT 생성하도록 하려면 **인덱스에 대해 고유한 이름 생성을** 선택합니다.
+ SQL Server 프로시저를 PostgreSQL 함수로 변환합니다.
PostgreSQL 버전 10 이하에서는 프로시저를 지원하지 않습니다. PostgreSQL에서 프로시저를 사용하는 데 익숙하지 않은 고객의 경우 프로시저를 함수로 변환할 AWS SCT 수 있습니다. 이렇게 하려면 **프로시저를 함수로 변환**을 선택합니다.
+ 테이블에서 `EXEC` 출력을 에뮬레이션하려면
소스 SQL Server 데이터베이스는 `EXEC`의 출력을 테이블에 저장할 수 있습니다. AWS SCT 는 임시 테이블과 추가 프로시저를 생성하여 이 기능을 에뮬레이션합니다. 이 에뮬레이션을 사용하려면 **Create additional routines for handling open datasets**를 선택합니다.
+ 변환된 코드의 스키마 이름에 사용할 템플릿을 정의합니다. **Schema name generation template**에서 다음 옵션 중 하나를 선택합니다.
+ **** – PostgreSQL에서 SQL Server 데이터베이스 이름을 스키마 이름으로 사용합니다.
+ **** – PostgreSQL에서 SQL Server 스키마 이름을 스키마 이름으로 사용합니다.
+ **\$1** – PostgreSQL에서 SQL Server 데이터베이스와 스키마 이름의 조합을 스키마 이름으로 사용합니다.
+ 소스 객체 이름의 대소문자를 그대로 사용합니다.
객체 이름을 소문자로 변환하지 않으려면 **Avoid casting to lower case for case sensitive operations**를 선택합니다. 이 옵션은 대상 데이터베이스에서 대소문자 구분 옵션을 활성화한 경우에만 적용됩니다.
+ 소스 데이터베이스의 파라미터 이름을 유지합니다.
변환된 코드의 파라미터 이름에 큰따옴표를 추가하려면 **원본 파라미터 이름 유지**를 선택합니다.
## SQL Server 파티션을 PostgreSQL 버전 10 파티션으로 변환
Microsoft SQL Server 데이터베이스를 Amazon Aurora PostgreSQL-Compatible Edition(Aurora PostgreSQL) 또는 Amazon Relational Database Service for PostgreSQL(Amazon RDS for PostgreSQL)로 변환할 때는 다음 사항에 유의합니다.
SQL Server에서는 파티션 함수를 사용하여 파티션을 생성합니다. SQL Server 파티션 테이블을 PostgreSQL 버전 10 파티션 테이블로 변환할 때는 다음과 같은 몇 가지 잠재적 문제에 유의해야 합니다.
+ SQL Server에서는 NOT NULL 제약 조건 없이 열을 사용하여 테이블을 분할할 수 있습니다. 이 경우 모든 NULL 값은 맨 왼쪽 파티션으로 이동합니다. PostgreSQL은 RANGE 파티셔닝에서 NULL 값을 지원하지 않습니다.
+ SQL Server에서는 파티션 테이블의 프라이머리 키와 고유 키를 만들 수 있습니다. PostgreSQL에서는 각 파티션의 프라이머리 키 또는 고유 키를 직접 생성할 수 있습니다. 따라서 PostgreSQL로 마이그레이션할 때 PRIMARY 또는 UNIQUE KEY 제약 조건을 상위 테이블에서 제거해야 합니다. 결과 키 이름은 `_` 형식입니다.
+ SQL Server를 사용하면 파티션 테이블에서 또는 파티션 테이블에 외래 키 제약 조건을 만들 수 있습니다. PostgreSQL은 파티션 테이블을 참조하는 외래 키를 지원하지 않습니다. 또한 PostgreSQL은 파티션 테이블에서 다른 테이블로의 외래 키 참조를 지원하지 않습니다.
+ SQL Server를 사용하면 파티션 테이블의 인덱스를 만들 수 있습니다. PostgreSQL에서는 각 파티션에 대해 직접 인덱스를 생성해야 합니다. 따라서 PostgreSQL로 마이그레이션할 때 해당 인덱스를 상위 테이블에서 제거해야 합니다. 결과 인덱스 이름은 `_` 형식입니다.
+ PostgreSQL은 파티션된 인덱스를 지원하지 않습니다.
## 마이그레이션 고려 사항
SQL Server 스키마에서 PostgreSQL로 마이그레이션할 때 고려해야 할 사항:
+ PostgreSQL에서는 스키마의 모든 객체 이름(인덱스 포함)이 고유해야 합니다. 인덱스 이름은 기본 테이블의 스키마에서 고유해야 합니다. SQL Server에서는 서로 다른 테이블에서 인덱스 이름이 동일할 수 있습니다.
인덱스 이름의 고유성을 보장하기 위해는 인덱스 이름이 고유하지 않은 경우 고유한 인덱스 이름을 생성할 수 있는 옵션을 AWS SCT 제공합니다. 이렇게 하려면 프로젝트 속성에서 **Generate unique index names(고유한 인덱스 이름 생성)** 옵션을 선택합니다. 이 옵션은 기본적으로 활성화되어 있습니다. 이 옵션을 활성화하면 IX\$1table\$1name\$1index\$1name 형식을 사용하여 고유한 인덱스 이름이 생성됩니다. 이 옵션을 비활성화하면 인덱스 이름이 변경되지 않습니다.
+ GOTO 문과 레이블을 사용하여 문 실행 순서를 변경할 수 있습니다. GOTO 문 뒤에 오는 Transact-SQL 문은 건너뛰며 프로세스는 레이블에서 계속됩니다. GOTO 문과 레이블은 프로시저, 배치(batch), 문 블록 내 어디든 사용할 수 있습니다. GOTO 문은 중첩될 수 있습니다.
PostgreSQL은 GOTO 명령문을 사용하지 않습니다. 가 GOTO 문이 포함된 코드를 AWS SCT 변환할 때 BEGIN...END 또는 LOOP...END LOOP 문을 사용하도록 문을 변환합니다. 다음 표에서가 GOTO 문을 AWS SCT 변환하는 방법의 예를 찾을 수 있습니다.
**SQL Server GOTO 문 및 변환된 PostgreSQL 문**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServer.ToPostgreSQL.html)
+ PostgreSQL은 MERGE 문을 지원하지 않습니다.는 다음과 같은 방식으로 MERGE 문의 동작을에 AWS SCT 뮬레이션합니다.
+ INSERT ON CONFLICT 생성.
+ UPDATE FROM DML 문 사용(예: MERGE without a WHEN NOT MATCHED 절)
+ CURSOR 사용(예: MERGE with DELETE 절) 또는 복잡한 MERGE ON 조건문 사용
+ AWS SCT 는 Amazon RDS가 대상일 때 객체 트리에 데이터베이스 트리거를 추가할 수 있습니다.
+ AWS SCT 는 Amazon RDS가 대상일 때 객체 트리에 서버 수준 트리거를 추가할 수 있습니다.
+ SQL Server는 `deleted` 및 `inserted` 테이블을 자동으로 생성하고 관리합니다. 이러한 임시 메모리 상주 테이블을 사용하여 특정 데이터 수정의 영향을 테스트하고 DML 트리거 작업에 대한 조건을 설정할 수 있습니다.는 DML 트리거 문 내에서 이러한 테이블의 사용을 변환할 AWS SCT 수 있습니다.
+ AWS SCT Amazon RDS가 대상인 경우는 연결된 서버를 객체 트리에 추가할 수 있습니다.
+ Microsoft SQL Server에서 PostgreSQL로 마이그레이션하면 내장된 SUSER\$1SNAME 함수가 다음과 같이 변환됩니다.
+ SUSER\$1SNAME - 보안 식별 번호(SID)와 연결된 로그인 이름을 반환합니다.
+ SUSER\$1SNAME() – 지원되지 않습니다.
+ SUSER\$1SNAME() CURRENT\$1USER – 현재 실행 컨텍스트의 사용자 이름을 반환합니다.
+ SUSER\$1SNAME(NULL) – NULL을 반환합니다.
+ 테이블 반환 함수 변환이 지원됩니다. 테이블 반환 함수는 테이블을 반환하며 쿼리에서 테이블을 대신할 수 있습니다.
+ PATINDEX에서는 유효한 모든 텍스트 및 문자 데이터 형식의 지정된 표현식에서 패턴이 처음으로 발생하는 시작 위치를 반환하고, 패턴을 찾을 수 없는 경우 0을 반환합니다. SQL Server에서 Amazon RDS for PostgreSQL로 변환할 때는 PATINDEX를 aws\$1sqlserver\$1ext.patindex(<패턴 문자>, <표현 문자 변형>)와 함께 사용하는 애플리케이션 코드를 AWS SCT 대체합니다.
+ SQL Server에서 사용자 정의 테이블 유형은 테이블 구조의 정의를 나타내는 유형입니다. 사용자 정의 테이블 유형을 사용하여 저장 프로시저 또는 함수에 테이블-값 파라미터를 선언합니다. 또한 사용자 정의 테이블 유형을 사용하여 저장 프로시저 또는 함수의 배치 또는 본문에 사용할 테이블 변수를 선언할 수 있습니다. 임시 테이블을 생성하여 PostgreSQL에서이 유형을에 AWS SCT 뮬레이션했습니다.
SQL Server에서 PostgreSQL로 변환할 때는 SQL Server 시스템 객체를 PostgreSQL에서 인식 가능한 객체로 AWS SCT 변환합니다. 다음 표에서는 시스템 객체가 어떻게 변환되는지 보여줍니다.
| MS SQL Server 사용 사례 | PostgreSQL 대체 |
| --- | --- |
| SYS.SCHEMAS | AWS\$1SQLSERVER\$1EXT.SYS\$1SCHEMAS |
| SYS.TABLES | AWS\$1SQLSERVER\$1EXT.SYS\$1TABLES |
| SYS.VIEWS | AWS\$1SQLSERVER\$1EXT.SYS\$1VIEWS |
| SYS.ALL\$1VIEWS | AWS\$1SQLSERVER\$1EXT.SYS\$1ALL\$1VIEWS |
| SYS.TYPES | AWS\$1SQLSERVER\$1EXT.SYS\$1TYPES |
| SYS.COLUMNS | AWS\$1SQLSERVER\$1EXT.SYS\$1COLUMNS |
| SYS.ALL\$1COLUMNS | AWS\$1SQLSERVER\$1EXT.SYS\$1ALL\$1COLUMNS |
| SYS.FOREIGN\$1KEYS | AWS\$1SQLSERVER\$1EXT.SYS\$1FOREIGN\$1KEYS |
| SYS.SYSFOREIGNKEYS | AWS\$1SQLSERVER\$1EXT.SYS\$1SYSFOREIGNKEYS |
| SYS.FOREIGN\$1KEY\$1COLUMNS | AWS\$1SQLSERVER\$1EXT.SYS\$1FOREIGN\$1KEY\$1COLUMNS |
| SYS.KEY\$1CONSTRAINTS | AWS\$1SQLSERVER\$1EXT.SYS\$1KEY\$1CONSTRAINTS |
| SYS.IDENTITY\$1COLUMNS | AWS\$1SQLSERVER\$1EXT.SYS\$1IDENTITY\$1COLUMNS |
| SYS.PROCEDURES | AWS\$1SQLSERVER\$1EXT.SYS\$1PROCEDURES |
| SYS.INDEXES | AWS\$1SQLSERVER\$1EXT.SYS\$1INDEXES |
| SYS.SYSINDEXES | AWS\$1SQLSERVER\$1EXT.SYS\$1SYSINDEXES |
| SYS.OBJECTS | AWS\$1SQLSERVER\$1EXT.SYS\$1OBJECTS |
| SYS.ALL\$1OBJECTS | AWS\$1SQLSERVER\$1EXT.SYS\$1ALL\$1OBJECTS |
| SYS.SYSOBJECTS | AWS\$1SQLSERVER\$1EXT.SYS\$1SYSOBJECTS |
| SYS.SQL\$1MODULES | AWS\$1SQLSERVER\$1EXT.SYS\$1SQL\$1MODULES |
| SYS.DATABASES | AWS\$1SQLSERVER\$1EXT.SYS\$1DATABASES |
| INFORMATION\$1SCHEMA.SCHEMATA | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1SCHEMATA |
| INFORMATION\$1SCHEMA.VIEWS | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1VIEWS |
| INFORMATION\$1SCHEMA.TABLES | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1TABLES |
| INFORMATION\$1SCHEMA.COLUMNS | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1COLUMNS |
| INFORMATION\$1SCHEMA.CHECK\$1CONSTRAINTS | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1CHECK\$1CONSTRAINTS |
| INFORMATION\$1SCHEMA.REFERENTIAL\$1CONSTRAINTS | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1REFERENTIAL\$1CONSTRAINTS |
| INFORMATION\$1SCHEMA.TABLE\$1CONSTRAINTS | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1TABLE\$1CONSTRAINTS |
| INFORMATION\$1SCHEMA.KEY\$1COLUMN\$1USAGE | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1KEY\$1COLUMN\$1USAGE |
| INFORMATION\$1SCHEMA.CONSTRAINT\$1TABLE\$1USAGE | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1CONSTRAINT\$1TABLE\$1USAGE |
| INFORMATION\$1SCHEMA.CONSTRAINT\$1COLUMN\$1USAGE | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1CONSTRAINT\$1COLUMN\$1USAGE |
| INFORMATION\$1SCHEMA.ROUTINES | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1ROUTINES |
| SYS.SYSPROCESSES | AWS\$1SQLSERVER\$1EXT.SYS\$1SYSPROCESSES |
| sys.system\$1objects | AWS\$1SQLSERVER\$1EXT.SYS\$1SYSTEM\$1OBJECTS |
# AWS SCT 확장 팩을 사용하여 PostgreSQL에서 SQL Server 에이전트 에뮬레이션
SQL Server 에이전트는 SQL Server 작업을 실행하는 Microsoft Windows 서비스입니다. SQL Server 에이전트는 일정에 따라, 특정 이벤트 발생 시 또는 필요에 따라 작업을 실행합니다. SQL Server 에이전트에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/ssms/agent/sql-server-agent?view=sql-server-ver15)를 참조하세요.
PostgreSQL은 SQL Server 에이전트와 동일한 기능을 제공하지 않습니다. SQL Server 에이전트 기능을 에뮬레이션하기 위해는 확장 팩을 AWS SCT 생성합니다. 이 확장 팩은 AWS Lambda 및 Amazon CloudWatch를 사용합니다.는 일정을 관리하고 작업을 실행하는 데 사용하는 인터페이스를 AWS Lambda 구현합니다. Amazon CloudWatch는 예약 규칙을 유지 관리합니다.
AWS Lambda 및 Amazon CloudWatch는 JSON 파라미터를 사용하여 상호 작용합니다. 이 JSON 파라미터의 구조는 다음과 같습니다.
```
{
"mode": mode,
"parameters": {
list of parameters
},
"callback": procedure name
}
```
이전 예제에서 *`mode`*는 작업 유형이고 `list of parameters`는 작업 유형에 따라 달라지는 파라미터 집합입니다. 또한 `procedure name`은 작업이 완료된 후 실행되는 프로시저의 이름입니다.
AWS SCT 는 Lambda 함수 하나를 사용하여 작업을 제어하고 실행합니다. CloudWatch 규칙은 작업 실행을 시작하고, 작업을 시작하는 데 필요한 정보를 제공합니다. CloudWatch 규칙이 트리거되면 규칙의 파라미터를 사용하여 Lambda 함수를 시작합니다.
프로시저를 호출하는 단순 작업을 생성하려면 다음 형식을 사용합니다.
```
{
"mode": "run_job",
"parameters": {
"vendor": "mysql",
"cmd": "lambda_db.nightly_job"
}
}
```
여러 단계가 포함된 작업을 생성하려면 다음 형식을 사용합니다.
```
{
"mode": "run_job",
"parameters": {
"job_name": "Job1",
"enabled": "true",
"start_step_id": 1,
"notify_level_email": [0|1|2|3],
"notify_email": email,
"delete_level": [0|1|2|3],
"job_callback": "ProcCallBackJob(job_name, code, message)",
"step_callback": "ProcCallBackStep(job_name, step_id, code, message)"
},
"steps": [
{
"id":1,
"cmd": "ProcStep1",
"cmdexec_success_code": 0,
"on_success_action": [|2|3|4],
"on_success_step_id": 1,
"on_fail_action": 0,
"on_fail_step_id": 0,
"retry_attempts": number,
"retry_interval": number
},
{
"id":2,
"cmd": "ProcStep2",
"cmdexec_success_code": 0,
"on_success_action": [1|2|3|4],
"on_success_step_id": 0,
"on_fail_action": 0,
"on_fail_step_id": 0,
"retry_attempts": number,
"retry_interval": number
},
...
]
}
```
PostgreSQL에서 SQL Server 에이전트 동작을 에뮬레이션하기 위해 AWS SCT 확장 팩은 다음 테이블과 절차도 생성합니다.
## PostgreSQL에서 SQL Server 에이전트를 에뮬레이션하는 테이블
SQL Server 에이전트를 에뮬레이션하기 위해 확장 팩은 다음 테이블을 사용합니다.
**sysjobs**
작업에 대한 정보를 저장합니다.
**sysjobsteps**
작업의 단계에 대한 정보를 저장합니다.
**sysschedules**
작업 예약에 대한 정보를 저장합니다.
**sysjobschedules**
개별 작업의 예약 정보를 저장합니다.
**sysjobhistory**
예약된 작업의 실행 관련 정보를 저장합니다.
## PostgreSQL에서 SQL Server 에이전트를 에뮬레이션하는 프로시저
SQL Server 에이전트를 에뮬레이션하기 위해 확장 팩은 다음 프로시저를 사용합니다.
**sp\$1add\$1job**
새 작업을 추가합니다.
**sp\$1add\$1jobstep**
작업에 단계를 추가합니다.
**sp\$1add\$1schedule**
Amazon CloudWatch에 새 예약 규칙을 생성합니다. 여러 작업에서 이 예약 일정을 사용할 수 있습니다.
**sp\$1attach\$1schedule**
선택한 작업의 예약을 설정합니다.
**sp\$1add\$1jobschedule**
Amazon CloudWatch에서 작업에 대한 예약 규칙을 생성하고 이 규칙의 대상을 설정합니다.
**sp\$1update\$1job**
이전에 생성한 작업의 속성을 업데이트합니다.
**sp\$1update\$1jobstep**
작업의 단계 속성을 업데이트합니다.
**sp\$1update\$1schedule**
Amazon CloudWatch에서 예약 규칙의 속성을 업데이트합니다.
**sp\$1update\$1jobschedule**
지정된 작업의 예약 속성을 업데이트합니다.
**sp\$1delete\$1job**
작업을 삭제합니다.
**sp\$1delete\$1jobstep**
작업에서 작업 단계를 삭제합니다.
**sp\$1delete\$1schedule**
일정을 삭제합니다.
**sp\$1delete\$1jobschedule**
Amazon CloudWatch에서 지정된 작업의 예약 규칙을 삭제합니다.
**sp\$1detach\$1schedule**
예약과 작업 간의 연결을 제거합니다.
**get\$1jobs, update\$1job**
와 상호 작용하는 내부 절차입니다 AWS Elastic Beanstalk.
**sp\$1verify\$1job\$1date, sp\$1verify\$1job\$1time, sp\$1verify\$1job, sp\$1verify\$1jobstep, sp\$1verify\$1schedule, sp\$1verify\$1job\$1identifiers, sp\$1verify\$1schedule\$1identifiers**
설정을 확인하는 내부 프로시저입니다.
## PostgreSQL에서 SQL Server 에이전트를 에뮬레이션하는 프로시저의 구문
확장 팩의 `aws_sqlserver_ext.sp_add_job` 프로시저는 `msdb.dbo.sp_add_job` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-add-job-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_job_name varchar,
par_enabled smallint = 1,
par_description varchar = NULL::character varying,
par_start_step_id integer = 1,
par_category_name varchar = NULL::character varying,
par_category_id integer = NULL::integer,
par_owner_login_name varchar = NULL::character varying,
par_notify_level_eventlog integer = 2,
par_notify_level_email integer = 0,
par_notify_level_netsend integer = 0,
par_notify_level_page integer = 0,
par_notify_email_operator_name varchar = NULL::character varying,
par_notify_netsend_operator_name varchar = NULL::character varying,
par_notify_page_operator_name varchar = NULL::character varying,
par_delete_level integer = 0,
inout par_job_id integer = NULL::integer,
par_originating_server varchar = NULL::character varying,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_add_jobstep` 프로시저는 `msdb.dbo.sp_add_jobstep` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-add-jobstep-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_job_id integer = NULL::integer,
par_job_name varchar = NULL::character varying,
par_step_id integer = NULL::integer,
par_step_name varchar = NULL::character varying,
par_subsystem varchar = 'TSQL'::bpchar,
par_command text = NULL::text,
par_additional_parameters text = NULL::text,
par_cmdexec_success_code integer = 0,
par_on_success_action smallint = 1,
par_on_success_step_id integer = 0,
par_on_fail_action smallint = 2,
par_on_fail_step_id integer = 0,
par_server varchar = NULL::character varying,
par_database_name varchar = NULL::character varying,
par_database_user_name varchar = NULL::character varying,
par_retry_attempts integer = 0,
par_retry_interval integer = 0,
par_os_run_priority integer = 0,
par_output_file_name varchar = NULL::character varying,
par_flags integer = 0,
par_proxy_id integer = NULL::integer,
par_proxy_name varchar = NULL::character varying,
inout par_step_uid char = NULL::bpchar,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_add_schedule` 프로시저는 `msdb.dbo.sp_add_schedule` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-add-schedule-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_schedule_name varchar,
par_enabled smallint = 1,
par_freq_type integer = 0,
par_freq_interval integer = 0,
par_freq_subday_type integer = 0,
par_freq_subday_interval integer = 0,
par_freq_relative_interval integer = 0,
par_freq_recurrence_factor integer = 0,
par_active_start_date integer = NULL::integer,
par_active_end_date integer = 99991231,
par_active_start_time integer = 0,
par_active_end_time integer = 235959,
par_owner_login_name varchar = NULL::character varying,
*inout par_schedule_uid char = NULL::bpchar,*
inout par_schedule_id integer = NULL::integer,
par_originating_server varchar = NULL::character varying,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_attach_schedule` 프로시저는 `msdb.dbo.sp_attach_schedule` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-attach-schedule-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_job_id integer = NULL::integer,
par_job_name varchar = NULL::character varying,
par_schedule_id integer = NULL::integer,
par_schedule_name varchar = NULL::character varying,
par_automatic_post smallint = 1,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_add_jobschedule` 프로시저는 `msdb.dbo.sp_add_jobschedule` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-add-jobschedule-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_job_id integer = NULL::integer,
par_job_name varchar = NULL::character varying,
par_name varchar = NULL::character varying,
par_enabled smallint = 1,
par_freq_type integer = 1,
par_freq_interval integer = 0,
par_freq_subday_type integer = 0,
par_freq_subday_interval integer = 0,
par_freq_relative_interval integer = 0,
par_freq_recurrence_factor integer = 0,
par_active_start_date integer = NULL::integer,
par_active_end_date integer = 99991231,
par_active_start_time integer = 0,
par_active_end_time integer = 235959,
inout par_schedule_id integer = NULL::integer,
par_automatic_post smallint = 1,
inout par_schedule_uid char = NULL::bpchar,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_delete_job` 프로시저는 `msdb.dbo.sp_delete_job` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-delete-job-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_job_id integer = NULL::integer,
par_job_name varchar = NULL::character varying,
par_originating_server varchar = NULL::character varying,
par_delete_history smallint = 1,
par_delete_unused_schedule smallint = 1,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_delete_jobstep` 프로시저는 `msdb.dbo.sp_delete_jobstep` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-delete-jobsteplog-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_job_id integer = NULL::integer,
par_job_name varchar = NULL::character varying,
par_step_id integer = NULL::integer,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_delete_jobschedule` 프로시저는 `msdb.dbo.sp_delete_jobschedule` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-delete-jobschedule-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_job_id integer = NULL::integer,
par_job_name varchar = NULL::character varying,
par_name varchar = NULL::character varying,
par_keep_schedule integer = 0,
par_automatic_post smallint = 1,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_delete_schedule` 프로시저는 `msdb.dbo.sp_delete_schedule` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-delete-schedule-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_schedule_id integer = NULL::integer,
par_schedule_name varchar = NULL::character varying,
par_force_delete smallint = 0,
par_automatic_post smallint = 1,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_detach_schedule` 프로시저는 `msdb.dbo.sp_detach_schedule` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-detach-schedule-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_job_id integer = NULL::integer,
par_job_name varchar = NULL::character varying,
par_schedule_id integer = NULL::integer,
par_schedule_name varchar = NULL::character varying,
par_delete_unused_schedule smallint = 0,
par_automatic_post smallint = 1,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_update_job` 프로시저는 `msdb.dbo.sp_update_job` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-update-job-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_job_id integer = NULL::integer
par_job_name varchar = NULL::character varying
par_new_name varchar = NULL::character varying
par_enabled smallint = NULL::smallint
par_description varchar = NULL::character varying
par_start_step_id integer = NULL::integer
par_category_name varchar = NULL::character varying
par_owner_login_name varchar = NULL::character varying
par_notify_level_eventlog integer = NULL::integer
par_notify_level_email integer = NULL::integer
par_notify_level_netsend integer = NULL::integer
par_notify_level_page integer = NULL::integer
par_notify_email_operator_name varchar = NULL::character varying
par_notify_netsend_operator_name varchar = NULL::character varying
par_notify_page_operator_name varchar = NULL::character varying
par_delete_level integer = NULL::integer
par_automatic_post smallint = 1
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_update_jobschedule` 프로시저는 `msdb.dbo.sp_update_jobschedule` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-update-jobschedule-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_job_id integer = NULL::integer
par_job_name varchar = NULL::character varying
par_name varchar = NULL::character varying
par_new_name varchar = NULL::character varying
par_enabled smallint = NULL::smallint
par_freq_type integer = NULL::integer
par_freq_interval integer = NULL::integer
par_freq_subday_type integer = NULL::integer
par_freq_subday_interval integer = NULL::integer
par_freq_relative_interval integer = NULL::integer
par_freq_recurrence_factor integer = NULL::integer
par_active_start_date integer = NULL::integer
par_active_end_date integer = NULL::integer
par_active_start_time integer = NULL::integer
par_active_end_time integer = NULL::integer
par_automatic_post smallint = 1
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_update_jobstep` 프로시저는 `msdb.dbo.sp_update_jobstep` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-update-jobstep-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_job_id integer = NULL::integer
par_job_name varchar = NULL::character varying
par_step_id integer = NULL::integer
par_step_name varchar = NULL::character varying
par_subsystem varchar = NULL::character varying
par_command text = NULL::text
par_additional_parameters text = NULL::text
par_cmdexec_success_code integer = NULL::integer
par_on_success_action smallint = NULL::smallint
par_on_success_step_id integer = NULL::integer
par_on_fail_action smallint = NULL::smallint
par_on_fail_step_id integer = NULL::integer
par_server varchar = NULL::character varying
par_database_name varchar = NULL::character varying
par_database_user_name varchar = NULL::character varying
par_retry_attempts integer = NULL::integer
par_retry_interval integer = NULL::integer
par_os_run_priority integer = NULL::integer
par_output_file_name varchar = NULL::character varying
par_flags integer = NULL::integer
par_proxy_id integer = NULL::integer
par_proxy_name varchar = NULL::character varying
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sp_update_schedule` 프로시저는 `msdb.dbo.sp_update_schedule` 프로시저를 에뮬레이션합니다. 소스 SQL Server 에이전트 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-update-schedule-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_schedule_id integer = NULL::integer
par_name varchar = NULL::character varying
par_new_name varchar = NULL::character varying
par_enabled smallint = NULL::smallint
par_freq_type integer = NULL::integer
par_freq_interval integer = NULL::integer
par_freq_subday_type integer = NULL::integer
par_freq_subday_interval integer = NULL::integer
par_freq_relative_interval integer = NULL::integer
par_freq_recurrence_factor integer = NULL::integer
par_active_start_date integer = NULL::integer
par_active_end_date integer = NULL::integer
par_active_start_time integer = NULL::integer
par_active_end_time integer = NULL::integer
par_owner_login_name varchar = NULL::character varying
par_automatic_post smallint = 1
out returncode integer
```
## PostgreSQL에서 SQL Server 에이전트를 에뮬레이션하는 프로시저 사용 예제
새 작업을 추가하려면 다음과 같이 `aws_sqlserver_ext.sp_add_job` 프로시저를 사용합니다.
```
SELECT * FROM aws_sqlserver_ext.sp_add_job (
par_job_name := 'test_job',
par_enabled := 1::smallint,
par_start_step_id := 1::integer,
par_category_name := '[Uncategorized (Local)]',
par_owner_login_name := 'sa');
```
새 작업 단계를 추가하려면 다음과 같이 `aws_sqlserver_ext.sp_add_jobstep` 프로시저를 사용합니다.
```
SELECT * FROM aws_sqlserver_ext.sp_add_jobstep (
par_job_name := 'test_job',
par_step_id := 1::smallint,
par_step_name := 'test_job_step1',
par_subsystem := 'TSQL',
par_command := 'EXECUTE [dbo].[PROC_TEST_JOB_STEP1];',
par_server := NULL,
par_database_name := 'GOLD_TEST_SS');
```
단순 일정을 추가하려면 다음과 같이 `aws_sqlserver_ext.sp_add_schedule` 프로시저를 사용합니다.
```
SELECT * FROM aws_sqlserver_ext.sp_add_schedule(
par_schedule_name := 'RunOnce',
par_freq_type := 1,
par_active_start_time := 233000);
```
작업 일정을 설정하려면 다음과 같이 `aws_sqlserver_ext.sp_attach_schedule` 프로시저를 사용합니다.
```
SELECT * FROM aws_sqlserver_ext.sp_attach_schedule (
par_job_name := 'test_job',
par_schedule_name := 'NightlyJobs');
```
작업에 대한 예약을 생성하려면 다음과 같이 `aws_sqlserver_ext.sp_add_jobschedule` 프로시저를 사용합니다.
```
SELECT * FROM aws_sqlserver_ext.sp_add_jobschedule (
par_job_name := 'test_job2',
par_name := 'test_schedule2',
par_enabled := 1::smallint,
par_freq_type := 4,
par_freq_interval := 1,
par_freq_subday_type := 4,
par_freq_subday_interval := 1,
par_freq_relative_interval := 0,
par_freq_recurrence_factor := 0,
par_active_start_date := 20100801,
par_active_end_date := 99991231,
par_active_start_time := 0,
par_active_end_time := 0);
```
## PostgreSQL에서 SQL Server 에이전트를 에뮬레이션하기 위한 사용 사례 예제
소스 데이터베이스 코드가 SQL Server Agent를 사용하여 작업을 실행하는 경우 용 SQL Server to PostgreSQL 확장 팩 AWS SCT 을 사용하여이 코드를 PostgreSQL로 변환할 수 있습니다. 확장 팩은 AWS Lambda 함수를 사용하여 SQL Server 에이전트의 동작을 에뮬레이션합니다.
새 AWS Lambda 함수를 생성하거나 기존 함수를 등록할 수 있습니다.
**새 AWS Lambda 함수를 생성하려면**
1. 의 대상 데이터베이스 트리 AWS SCT에서 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 열고 **확장 팩 적용을** 선택한 다음 **PostgreSQL**을 선택합니다.
확장 팩 마법사가 표시됩니다.
1. **SQL Server Agent emulation service** 탭에서 다음을 수행합니다.
+ ** AWS Lambda 함수 생성을** 선택합니다.
+ **Database login**에 대상 데이터베이스 사용자의 이름을 입력합니다.
+ **데이터베이스 암호**에 이전 단계에서 입력한 사용자 이름의 암호를 입력합니다.
+ **Python library folder**에 Python 라이브러리 폴더의 경로를 입력합니다.
+ ** AWS Lambda 함수 생성을** 선택한 **후 다음을** 선택합니다.
**이전에 배포한 AWS Lambda 함수를 등록하려면**
+ 대상 데이터베이스에서 다음 스크립트를 실행합니다.
```
SELECT
FROM aws_sqlserver_ext.set_service_setting(
p_service := 'JOB',
p_setting := 'LAMBDA_ARN',
p_value := ARN)
```
이전 예제에서 *`ARN`*은 배포된 AWS Lambda 함수의 Amazon 리소스 이름(ARN)입니다.
다음 예제에서는 한 단계로 구성된 단순 작업을 생성합니다. 이 작업은 5분마다 이전에 생성된 `job_example` 함수를 실행합니다. 이 함수는 `job_example_table` 테이블에 레코드를 삽입합니다.
**이 단순 작업을 생성하려면**
1. 다음과 같이 `aws_sqlserver_ext.sp_add_job` 함수를 사용하여 작업을 생성합니다.
```
SELECT
FROM aws_sqlserver_ext.sp_add_job (
par_job_name := 'test_simple_job');
```
1. 다음과 같이 `aws_sqlserver_ext.sp_add_jobstep` 함수를 사용하여 작업 단계를 생성합니다.
```
SELECT
FROM aws_sqlserver_ext.sp_add_jobstep (
par_job_name := 'test_simple_job',
par_step_name := 'test_simple_job_step1',
par_command := 'PERFORM job_simple_example;');
```
작업 단계는 함수가 수행하는 작업을 지정합니다.
1. 다음과 같이 `aws_sqlserver_ext.sp_add_jobschedule` 함수를 사용하여 작업에 대한 스케줄러를 생성합니다.
```
SELECT
FROM aws_sqlserver_ext.sp_add_jobschedule (
par_job_name := 'test_simple_job',
par_name := 'test_schedule',
par_freq_type := 4, /* Daily */
par_freq_interval := 1, /* frequency_interval is unused */
par_freq_subday_type := 4, /* Minutes */
par_freq_subday_interval := 5 /* 5 minutes */);
```
작업 단계는 함수가 수행하는 작업을 지정합니다.
이 작업을 삭제하려면 다음과 같이 `aws_sqlserver_ext.sp_delete_job` 함수를 사용합니다.
```
PERFORM aws_sqlserver_ext.sp_delete_job(
par_job_name := 'PeriodicJob1'::character varying,
par_delete_history := 1::smallint,
par_delete_unused_schedule := 1::smallint);
```
# AWS SCT 확장 팩을 사용하여 PostgreSQL에서 SQL Server Database Mail 에뮬레이션
SQL Server Database Mail을 사용하여 SQL Server 데이터베이스 엔진 또는 Azure SQL Managed Instance에서 사용자에게 이메일 메시지를 보낼 수 있습니다. 이러한 이메일 메시지는 쿼리 결과를 포함하거나 네트워크에 있는 리소스의 파일을 포함할 수 있습니다. SQL Server Database Mail에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/database-mail/database-mail?view=sql-server-ver15)를 참조하세요.
PostgreSQL은 SQL Server Database Mail과 동일한 기능을 제공하지 않습니다. SQL Server Database Mail 기능을 에뮬레이션하기 위해 AWS SCT 는 확장 팩을 생성합니다. 이 확장 팩은 AWS Lambda 및 Amazon Simple Email Service(Amazon SES)를 사용합니다.는 사용자에게 Amazon SES 이메일 전송 서비스와 상호 작용할 수 있는 인터페이스를 AWS Lambda 제공합니다. 이 상호 작용을 설정하려면 Lambda 함수의 Amazon 리소스 이름(ARN)을 추가합니다.
새 이메일 계정의 경우 다음 명령을 사용합니다.
```
do
$$
begin
PERFORM sysmail_add_account_sp (
par_account_name :='your_account_name',
par_email_address := 'your_account_email',
par_display_name := 'your_account_display_name',
par_mailserver_type := 'AWSLAMBDA'
par_mailserver_name := 'ARN'
);
end;
$$ language plpgsql;
```
Lambda 함수의 ARN을 기존 이메일 계정에 추가하려면 다음 명령을 사용합니다.
```
do
$$
begin
PERFORM sysmail_update_account_sp (
par_account_name :='existind_account_name',
par_mailserver_type := 'AWSLAMBDA'
par_mailserver_name := 'ARN'
);
end;
$$ language plpgsql;
```
이전 예제에서 *`ARN`*은 Lambda 함수의 ARN입니다.
PostgreSQL에서 SQL Server Database Mail 동작을 에뮬레이션하기 위해 AWS SCT 확장 팩은 다음과 같은 테이블, 보기 및 프로시저를 사용합니다.
## PostgreSQL에서 SQL Server Database Mail을 에뮬레이션하는 테이블
SQL Server Database Mail을 에뮬레이션하기 위해 확장 팩은 다음 테이블을 사용합니다.
**sysmail\$1account**
이메일 계정에 대한 정보를 저장합니다.
**sysmail\$1profile**
사용자 프로필에 대한 정보를 저장합니다.
**sysmail\$1server**
이메일 서버에 대한 정보를 저장합니다.
**sysmail\$1mailitems**
이메일 메시지 목록을 저장합니다.
**sysmail\$1attachment**
각 이메일 첨부 파일마다 하나의 행을 포함합니다.
**sysmail\$1log**
이메일 메시지 전송에 대한 서비스 정보를 저장합니다.
**sysmail\$1profileaccount**
사용자 프로필 및 이메일 계정에 대한 정보를 저장합니다.
## PostgreSQL에서 SQL Server Database Mail을 에뮬레이션하는 보기
SQL Server Database Mail을 에뮬레이션하기 위해는 호환성을 보장하기 위해 PostgreSQL 데이터베이스에 다음 뷰를 AWS SCT 생성합니다. 확장 팩에서는 이러한 보기를 사용하지 않지만 변환된 코드는 이러한 보기를 쿼리할 수 있습니다.
**sysmail\$1allitems**
모든 이메일 목록이 포함됩니다.
**sysmail\$1faileditems**
전송할 수 없는 이메일 목록이 포함됩니다.
**sysmail\$1sentitems**
보낸 이메일 목록이 포함됩니다.
**sysmail\$1unsentitems**
아직 전송되지 않은 이메일 목록이 포함됩니다.
**sysmail\$1mailattachments**
첨부 파일 목록이 포함됩니다.
## PostgreSQL에서 SQL Server Database Mail을 에뮬레이션하는 프로시저
SQL Server Database Mail을 에뮬레이션하기 위해 확장 팩은 다음 프로시저를 사용합니다.
**sp\$1send\$1dbmail**
지정된 수신자에게 이메일을 보냅니다.
**sysmail\$1add\$1profile\$1sp**
새 사용자 프로필을 생성합니다.
**sysmail\$1add\$1account\$1sp**
SMTP(Simple Mail Transfer Protocol) 보안 인증 정보 등과 같은 정보를 저장하는 새로운 이메일 계정을 생성합니다.
**sysmail\$1add\$1profileaccount\$1sp**
지정된 사용자 프로필에 이메일 계정을 추가합니다.
**sysmail\$1update\$1profile\$1sp**
설명, 이름 등과 같은 사용자 프로필의 속성을 변경합니다.
**sysmail\$1update\$1account\$1sp**
기존 이메일 계정의 정보를 변경합니다.
**sysmail\$1update\$1profileaccount\$1sp**
지정된 사용자 프로필의 이메일 계정 정보를 업데이트합니다.
**sysmail\$1delete\$1profileaccount\$1sp**
지정된 사용자 프로필에서 이메일 계정을 제거합니다.
**sysmail\$1delete\$1account\$1sp**
이메일 계정을 삭제합니다.
**sysmail\$1delete\$1profile\$1sp**
사용자 프로필을 삭제합니다.
**sysmail\$1delete\$1mailitems\$1sp**
내부 테이블에서 이메일을 삭제합니다.
**sysmail\$1help\$1profile\$1sp**
사용자 프로필에 대한 정보를 표시합니다.
**sysmail\$1help\$1account\$1sp**
이메일 계정에 대한 정보를 표시합니다.
**sysmail\$1help\$1profileaccount\$1sp**
사용자 프로필과 연결된 이메일 계정 관련 정보를 표시합니다.
**sysmail\$1dbmail\$1json**
AWS Lambda 함수에 대한 JSON 요청을 생성하는 내부 절차입니다.
**sysmail\$1verify\$1profile\$1sp, sysmail\$1verify\$1account\$1sp, sysmail\$1verify\$1addressparams\$1sp**
설정을 확인하는 내부 프로시저입니다.
**sp\$1get\$1dbmail, sp\$1set\$1dbmail, sysmail\$1dbmail\$1xml**
더 이상 사용되지 않는 내부 프로시저입니다.
## PostgreSQL에서 SQL Server Database Mail을 에뮬레이션하는 프로시저의 구문
확장 팩의 `aws_sqlserver_ext.sp_send_dbmail` 프로시저는 `msdb.dbo.sp_send_dbmail` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-send-dbmail-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_profile_name varchar = NULL::character varying,
par_recipients text = NULL::text,
par_copy_recipients text = NULL::text,
par_blind_copy_recipients text = NULL::text,
par_subject varchar = NULL::character varying,
par_body text = NULL::text,
par_body_format varchar = NULL::character varying,
par_importance varchar = 'NORMAL'::character varying,
par_sensitivity varchar = 'NORMAL'::character varying,
par_file_attachments text = NULL::text,
par_query text = NULL::text,
par_execute_query_database varchar = NULL::character varying,
par_attach_query_result_as_file smallint = 0,
par_query_attachment_filename varchar = NULL::character varying,
par_query_result_header smallint = 1,
par_query_result_width integer = 256,
par_query_result_separator VARCHAR = ' '::character varying,
par_exclude_query_output smallint = 0,
par_append_query_error smallint = 0,
par_query_no_truncate smallint = 0,
par_query_result_no_padding smallint = 0,
out par_mailitem_id integer,
par_from_address text = NULL::text,
par_reply_to text = NULL::text,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_delete_mailitems_sp` 프로시저는 `msdb.dbo.sysmail_delete_mailitems_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-delete-mailitems-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_sent_before timestamp = NULL::timestamp without time zone,
par_sent_status varchar = NULL::character varying,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_add_profile_sp` 프로시저는 `msdb.dbo.sysmail_add_profile_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-profile-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_profile_name varchar,
par_description varchar = NULL::character varying,
out par_profile_id integer,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_add_account_sp` 프로시저는 `msdb.dbo.sysmail_add_account_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-account-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_account_name varchar
par_email_address varchar
par_display_name varchar = NULL::character varying
par_replyto_address varchar = NULL::character varying
par_description varchar = NULL::character varying
par_mailserver_name varchar = NULL::character varying
par_mailserver_type varchar = 'SMTP'::bpchar
par_port integer = 25
par_username varchar = NULL::character varying
par_password varchar = NULL::character varying
par_use_default_credentials smallint = 0
par_enable_ssl smallint = 0
out par_account_id integer
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_add_profileaccount_sp` 프로시저는 `msdb.dbo.sysmail_add_profileaccount_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-profileaccount-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_profile_id integer = NULL::integer,
par_profile_name varchar = NULL::character varying,
par_account_id integer = NULL::integer,
par_account_name varchar = NULL::character varying,
par_sequence_number integer = NULL::integer,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_help_profile_sp` 프로시저는 `msdb.dbo.sysmail_help_profile_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-help-profile-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_profile_id integer = NULL::integer,
par_profile_name varchar = NULL::character varying,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_update_profile_sp` 프로시저는 `msdb.dbo.sysmail_update_profile_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-update-profile-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_profile_id integer = NULL::integer,
par_profile_name varchar = NULL::character varying,
par_description varchar = NULL::character varying,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_delete_profile_sp` 프로시저는 `msdb.dbo.sysmail_delete_profile_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-delete-profile-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_profile_id integer = NULL::integer,
par_profile_name varchar = NULL::character varying,
par_force_delete smallint = 1,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_help_account_sp` 프로시저는 `msdb.dbo.sysmail_help_account_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-help-account-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_account_id integer = NULL::integer,
par_account_name varchar = NULL::character varying,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_update_account_sp` 프로시저는 `msdb.dbo.sysmail_update_account_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-update-account-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_account_id integer = NULL::integer,
par_account_name varchar = NULL::character varying,
par_email_address varchar = NULL::character varying,
par_display_name varchar = NULL::character varying,
par_replyto_address varchar = NULL::character varying,
par_description varchar = NULL::character varying,
par_mailserver_name varchar = NULL::character varying,
par_mailserver_type varchar = NULL::character varying,
par_port integer = NULL::integer,
par_username varchar = NULL::character varying,
par_password varchar = NULL::character varying,
par_use_default_credentials smallint = NULL::smallint,
par_enable_ssl smallint = NULL::smallint,
par_timeout integer = NULL::integer,
par_no_credential_change smallint = NULL::smallint,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_delete_account_sp` 프로시저는 `msdb.dbo.sysmail_delete_account_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-delete-account-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_account_id integer = NULL::integer,
par_account_name varchar = NULL::character varying,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_help_profileaccount_sp` 프로시저는 `msdb.dbo.sysmail_help_profileaccount_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-help-profileaccount-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_profile_id integer = NULL::integer,
par_profile_name varchar = NULL::character varying,
par_account_id integer = NULL::integer,
par_account_name varchar = NULL::character varying,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_update_profileaccount_sp` 프로시저는 `msdb.dbo.sysmail_update_profileaccount_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-update-profileaccount-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_profile_id integer = NULL::integer,
par_profile_name varchar = NULL::character varying,
par_account_id integer = NULL::integer,
par_account_name varchar = NULL::character varying,
par_sequence_number integer = NULL::integer,
out returncode integer
```
확장 팩의 `aws_sqlserver_ext.sysmail_delete_profileaccount_sp` 프로시저는 `msdb.dbo.sysmail_delete_profileaccount_sp` 프로시저를 에뮬레이션합니다. 소스 SQL Server Database Mail 프로시저에 대한 자세한 내용은 [Microsoft 기술 문서](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-delete-profileaccount-sp-transact-sql?view=sql-server-ver15)를 참조하세요.
```
par_profile_id integer = NULL::integer,
par_profile_name varchar = NULL::character varying,
par_account_id integer = NULL::integer,
par_account_name varchar = NULL::character varying,
out returncode integer
```
## PostgreSQL에서 SQL Server Database Mail을 에뮬레이션하는 프로시저 사용 예제
이메일을 보내려면 다음과 같이 `aws_sqlserver_ext.sp_send_dbmail` 프로시저를 사용합니다.
```
PERFORM sp_send_dbmail (
par_profile_name := 'Administrator',
par_recipients := 'hello@rusgl.info',
par_subject := 'Automated Success Message',
par_body := 'The stored procedure finished'
);
```
다음 예제는 쿼리 결과가 포함된 이메일을 전송하는 방법을 보여줍니다.
```
PERFORM sp_send_dbmail (
par_profile_name := 'Administrator',
par_recipients := 'hello@rusgl.info',
par_subject := 'Account with id = 1',
par_query := 'SELECT COUNT(*)FROM Account WHERE id = 1'
);
```
다음 예제는 HTML 코드가 포함된 이메일을 전송하는 방법을 보여줍니다.
```
DECLARE var_tableHTML TEXT;
SET var_tableHTML := CONCAT(
'Work Order Report
',
'',
'| Work Order ID | Product ID | ',
'Name | Order Qty | Due Date | ',
'Expected Revenue |
|---|
',
'
'
);
PERFORM sp_send_dbmail (
par_recipients := 'hello@rusgl.info',
par_subject := 'Work Order List',
par_body := var_tableHTML,
par_body_format := 'HTML'
);
```
이메일을 삭제하려면 다음과 같이 `aws_sqlserver_ext.sysmail_delete_mailitems_sp` 프로시저를 사용합니다.
```
DECLARE var_GETDATE datetime;
SET var_GETDATE = NOW();
PERFORM sysmail_delete_mailitems_sp (
par_sent_before := var_GETDATE
);
```
다음 예제는 가장 오래된 이메일을 삭제하는 방법을 보여줍니다.
```
PERFORM sysmail_delete_mailitems_sp (
par_sent_before := '31.12.2015'
);
```
다음 예제는 전송할 수 없는 모든 이메일을 삭제하는 방법을 보여줍니다.
```
PERFORM sysmail_delete_mailitems_sp (
par_sent_status := 'failed'
);
```
새 사용자 프로필을 생성하려면 다음과 같이 `aws_sqlserver_ext.sysmail_add_profile_sp` 프로시저를 사용합니다.
```
PERFORM sysmail_add_profile_sp (
profile_name := 'Administrator',
par_description := 'administrative mail'
);
```
다음 예제는 새 프로필을 생성하고 고유한 프로필 식별자를 변수로 저장하는 방법을 보여줍니다.
```
DECLARE var_profileId INT;
SELECT par_profile_id
FROM sysmail_add_profile_sp (
profile_name := 'Administrator',
par_description := ' Profile used for administrative mail.')
INTO var_profileId;
SELECT var_profileId;
```
새 이메일 계정을 생성하려면 다음과 같이 `aws_sqlserver_ext.sysmail_add_account_sp` 프로시저를 사용합니다.
```
PERFORM sysmail_add_account_sp (
par_account_name :='Audit Account',
par_email_address := 'dba@rusgl.info',
par_display_name := 'Test Automated Mailer',
par_description := 'Account for administrative e-mail.',
par_mailserver_type := 'AWSLAMBDA'
par_mailserver_name := 'arn:aws:lambda:us-west-2:555555555555:function:pg_v3'
);
```
사용자 프로필에 이메일 계정을 추가하려면 다음과 같이 `aws_sqlserver_ext.sysmail_add_profileaccount_sp` 프로시저를 사용합니다.
```
PERFORM sysmail_add_profileaccount_sp (
par_account_name := 'Administrator',
par_account_name := 'Audit Account',
par_sequence_number := 1
);
```
## PostgreSQL에서 SQL Server Database Mail을 에뮬레이션하기 위한 사용 사례 예제
소스 데이터베이스 코드가 SQL Server Database Mail을 사용하여 이메일을 보내는 경우 AWS SCT 확장 팩을 사용하여이 코드를 PostgreSQL로 변환할 수 있습니다.
**PostgreSQL 데이터베이스에서 이메일을 보내려면**
1. AWS Lambda 함수를 생성하고 구성합니다.
1. AWS SCT 확장 팩을 적용합니다.
1. 다음과 같이 `sysmail_add_profile_sp` 함수를 사용하여 사용자 프로필을 생성합니다.
1. 다음과 같이 `sysmail_add_account_sp` 함수를 사용하여 이메일 계정을 생성합니다.
1. 다음과 같이 `sysmail_add_profileaccount_sp` 함수를 사용하여 이 이메일 계정을 사용자 프로필에 추가합니다.
```
CREATE OR REPLACE FUNCTION aws_sqlserver_ext.
proc_dbmail_settings_msdb()
RETURNS void
AS
$BODY$
BEGIN
PERFORM aws_sqlserver_ext.sysmail_add_profile_sp(
par_profile_name := 'Administrator',
par_description := 'administrative mail'
);
PERFORM aws_sqlserver_ext.sysmail_add_account_sp(
par_account_name := 'Audit Account',
par_description := 'Account for administrative e-mail.',
par_email_address := 'dba@rusgl.info',
par_display_name := 'Test Automated Mailer',
par_mailserver_type := 'AWSLAMBDA'
par_mailserver_name := 'your_ARN'
);
PERFORM aws_sqlserver_ext.sysmail_add_profileaccount_sp(
par_profile_name := 'Administrator',
par_account_name := 'Audit Account',
par_sequence_number := 1
);
END;
$BODY$
LANGUAGE plpgsql;
```
1. 다음과 같이 `sp_send_dbmail` 함수를 사용하여 이메일을 보냅니다.
```
CREATE OR REPLACE FUNCTION aws_sqlserver_ext.
proc_dbmail_send_msdb()
RETURNS void
AS
$BODY$
BEGIN
PERFORM aws_sqlserver_ext.sp_send_dbmail(
par_profile_name := 'Administrator',
par_recipients := 'hello@rusgl.info',
par_body := 'The stored procedure finished',
par_subject := 'Automated Success Message'
);
END;
$BODY$
LANGUAGE plpgsql;
```
모든 사용자 프로필에 대한 정보를 보려면 다음과 같이 `sysmail_help_profile_sp` 프로시저를 사용합니다.
```
SELECT FROM aws_sqlserver_ext.sysmail_help_profile_sp();
```
다음 예제는 특정 사용자 프로필에 대한 정보를 표시합니다.
```
select from aws_sqlserver_ext.sysmail_help_profile_sp(par_profile_id := 1);
select from aws_sqlserver_ext.sysmail_help_profile_sp(par_profile_name := 'Administrator');
```
모든 이메일 계정에 대한 정보를 보려면 다음과 같이 `sysmail_help_account_sp` 프로시저를 사용합니다.
```
select from aws_sqlserver_ext.sysmail_help_account_sp();
```
다음 예제는 특정 이메일 계정에 대한 정보를 표시합니다.
```
select from aws_sqlserver_ext.sysmail_help_account_sp(par_account_id := 1);
select from aws_sqlserver_ext.sysmail_help_account_sp(par_account_name := 'Audit Account');
```
사용자 프로필과 연결된 모든 이메일 계정에 대한 정보를 보려면 다음과 같이 `sysmail_help_profileaccount_sp` 프로시저를 사용합니다.
```
select from aws_sqlserver_ext.sysmail_help_profileaccount_sp();
```
다음 예제는 식별자, 프로필 이름 또는 계정 이름을 기준으로 레코드를 필터링합니다.
```
select from aws_sqlserver_ext.sysmail_help_profileaccount_sp(par_profile_id := 1);
select from aws_sqlserver_ext.sysmail_help_profileaccount_sp(par_profile_id := 1, par_account_id := 1);
select from aws_sqlserver_ext.sysmail_help_profileaccount_sp(par_profile_name := 'Administrator');
select from aws_sqlserver_ext.sysmail_help_profileaccount_sp(par_account_name := 'Audit Account');
```
사용자 프로필 이름 또는 설명을 변경하려면 다음과 같이 `sysmail_update_profile_sp` 프로시저를 사용합니다.
```
select aws_sqlserver_ext.sysmail_update_profile_sp(
par_profile_id := 2,
par_profile_name := 'New profile name'
);
```
이메일 계정 설정을 변경하려면 다음과 같이 `ysmail_update_account_sp` 프로시저를 사용합니다.
```
select from aws_sqlserver_ext.sysmail_update_account_sp (
par_account_name := 'Audit Account',
par_mailserver_name := 'arn:aws:lambda:region:XXXXXXXXXXXX:function:func_test',
par_mailserver_type := 'AWSLAMBDA'
);
```
# 를 사용하여 SQL Server에서 Amazon RDS for SQL Server로 마이그레이션 AWS Schema Conversion Tool
SQL Server 스키마와 코드를 Amazon RDS for SQL Server로 마이그레이션할 경우 몇 가지 사항을 고려해야 합니다.
+ AWS SCT 는 SQL Server 에이전트를 변환하여 Amazon RDS for SQL Server DB 인스턴스에서 일정, 알림 및 작업을 제공할 수 있습니다. 변환 후 Amazon RDS for SQL Server DB 인스턴스를 SSRS(SQL Server Reporting Service), SSAS(SQL Server Analysis Services), SSIS(SQL Server Integration Services)와 함께 사용할 수 있습니다.
+ 현재 Amazon RDS는 SQL Server Service Broker 또는 CREATE ENDPOINT 명령을 실행하는 데 필요한 추가 T-SQL 엔드포인트를 지원하지 않습니다.
+ Amazon RDS는 연결된 서버를 제한적으로 지원합니다. 연결된 서버를 사용하는 SQL Server 애플리케이션 코드를 변환할 때는 애플리케이션 코드를 AWS SCT 변환합니다. 사용자는 이 변환된 코드를 실행하기 전에 먼저 연결 서버를 사용하는 객체의 동작을 검토해야 합니다.
+ 상시 가동 기능이 사용됩니다.
+ AWS SCT 평가 보고서는 변환을 위한 서버 지표를 제공합니다. SQL Server 인스턴스에 대한 이러한 측정치에는 다음이 포함됩니다.
+ 데이터 미러링이 사용됩니다.
+ SQL Server 로그 전달이 구성되었습니다.
+ 장애 조치 클러스터가 사용됩니다.
+ Database Mail이 구성되었습니다.
+ 전체 텍스트 검색 서비스가 사용됩니다. Amazon RDS for SQL Server는 전체 텍스트 검색이 제한적이며 의미 체계 검색을 지원하지 않습니다.
+ 데이터 품질 서비스(DQS)가 설치되었습니다. Amazon RDS는 DQS를 지원하지 않으므로 Amazon EC2 인스턴스에 SQL Server를 설치하는 것이 좋습니다.
## RDS for SQL Server를 대상으로 사용하기 위한 권한
RDS for SQL Server로 마이그레이션하려면 데이터베이스 사용자를 생성하고 각 데이터베이스에 필요한 권한을 부여합니다. 다음과 같은 코드 예제를 사용할 수 있습니다.
```
CREATE LOGIN user_name WITH PASSWORD 'your_password';
USE db_name
CREATE USER user_name FOR LOGIN user_name
GRANT VIEW DEFINITION TO user_name
GRANT VIEW DATABASE STATE TO user_name
GRANT CREATE SCHEMA TO user_name;
GRANT CREATE TABLE TO user_name;
GRANT CREATE VIEW TO user_name;
GRANT CREATE TYPE TO user_name;
GRANT CREATE DEFAULT TO user_name;
GRANT CREATE FUNCTION TO user_name;
GRANT CREATE PROCEDURE TO user_name;
GRANT CREATE ASSEMBLY TO user_name;
GRANT CREATE AGGREGATE TO user_name;
GRANT CREATE FULLTEXT CATALOG TO user_name;
GRANT CREATE SYNONYM TO user_name;
GRANT CREATE XML SCHEMA COLLECTION TO user_name;
```
이전 예제에서 *user\$1name*을 사용자 이름으로 바꿉니다. 그런 다음 *db\$1name*을 대상 데이터베이스의 이름으로 바꿉니다. 마지막으로 *your\$1password*를 안전한 암호로 바꿉니다.
# 용 데이터 웨어하우스 소스 AWS Schema Conversion Tool
AWS SCT 는 다음 소스 데이터 웨어하우스의 스키마를 지원되는 대상으로 변환할 수 있습니다. 권한, 연결 및 대상 데이터베이스 또는 데이터 웨어하우스와 함께 사용할 수 있도록 변환 AWS SCT 할 수 있는 항목에 대한 자세한 내용은 다음의 세부 정보를 참조하세요.
**Topics**
+ [에 Amazon Redshift 연결 AWS Schema Conversion Tool](CHAP_Source.Redshift.md)
+ [에 Azure Synapse Analytics 연결 AWS Schema Conversion Tool](CHAP_Source.AzureSynapse.md)
+ [를 사용하여 Google BigQuery에 연결 AWS Schema Conversion Tool](CHAP_Source.BigQuery.md)
+ [에 Greenplum 데이터베이스 연결 AWS Schema Conversion Tool](CHAP_Source.Greenplum.md)
+ [를 사용하여 Netezza에 연결 AWS Schema Conversion Tool](CHAP_Source.Netezza.md)
+ [에 Oracle Data Warehouse 연결 AWS SCT](CHAP_Source.OracleDW.md)
+ [를 사용하여 Snowflake 데이터 웨어하우스에 연결 AWS Schema Conversion Tool](CHAP_Source.Snowflake.md)
+ [를 사용하여 SQL Server Data Warehouse에 연결 AWS Schema Conversion Tool](CHAP_Source.SQLServerDW.md)
+ [를 사용하여 Teradata Data Warehouse에 연결 AWS Schema Conversion Tool](CHAP_Source.Teradata.md)
+ [AWS Schema Conversion Tool Vertica 데이터베이스에 연결](CHAP_Source.Vertica.md)
# 에 Amazon Redshift 연결 AWS Schema Conversion Tool
AWS SCT 를 사용하여 Amazon Redshift 클러스터를 최적화할 수 있습니다.는 Amazon Redshift 클러스터의 배포 및 정렬 키 선택에 대한 권장 사항을 AWS SCT 제공합니다. Amazon Redshift 최적화 프로젝트는 소스와 대상이 서로 다른 Amazon Redshift 클러스터를 가리키는 AWS SCT 프로젝트로 간주할 수 있습니다.
## Amazon Redshift를 소스 데이터베이스로 사용하기 위한 권한
Amazon Redshift를 소스로 사용하기 위해 필요한 권한은 다음과 같습니다.
+ USAGE ON SCHEMA **
+ SELECT ON ALL TABLES IN SCHEMA **
+ SELECT ON PG\$1CATALOG.PG\$1STATISTIC
+ SELECT ON SVV\$1TABLE\$1INFO
+ SELECT ON TABLE STV\$1BLOCKLIST
+ SELECT ON TABLE STV\$1TBL\$1PERM
+ SELECT ON SYS\$1SERVERLESS\$1USAGE
+ SELECT ON PG\$1DATABASE\$1INFO
+ SELECT ON PG\$1STATISTIC
이전 예제에서 ** 자리 표시자를 소스 스키마의 이름으로 바꿉니다.
Amazon Redshift를 대상으로 사용하기 위해 필요한 권한에 대한 자세한 내용은 [Amazon Redshift를 대상으로 사용할 수 있는 권한](CHAP_Converting.DW.md#CHAP_Converting.DW.ConfigureTarget) 섹션을 참조하세요.
## Amazon Redshift에 소스로 연결
다음 절차에 따라 AWS Schema Conversion Tool을 사용하여 Amazon Redshift 소스 데이터베이스에 연결합니다.
**Amazon Redshift 소스 데이터베이스에 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **Amazon Redshift**를 선택한 후 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 데이터베이스의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. 에서 데이터베이스 자격 증명을 사용하거나 수동으로 AWS Secrets Manager 입력합니다.
+ Secrets Manager의 데이터베이스 보안 인증 정보를 사용하려면 다음 지침을 따릅니다.
1. **AWS Secret**에서 보안 암호의 이름을 선택합니다.
1. **Populate**를 선택하여 Secrets Manager에서 데이터베이스 연결 대화 상자에 있는 모든 값을 자동으로 채웁니다.
Secrets Manager의 데이터베이스 보안 인증 사용에 대한 자세한 내용은 [AWS Secrets Manager 에서 구성 AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md) 섹션을 참조하세요.
+ Amazon Redshift 소스 데이터베이스의 연결 정보를 입력하려면 다음 지침을 사용합니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.Redshift.html)
1. **연결 테스트를** 선택하여가 소스 데이터베이스에 연결할 AWS SCT 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 데이터베이스에 연결합니다.
## Amazon Redshift 최적화 설정
Amazon Redshift 최적화 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Amazon Redshift**를 선택한 다음 **Amazon Redshift – Amazon Redshift**를 선택합니다. AWS SCT 는 Amazon Redshift 최적화에 사용할 수 있는 모든 설정을 표시합니다.
의 Amazon Redshift 최적화 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 대상 Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 최대 테이블 수를 설정합니다.
**대상 Amazon Redshift 클러스터의 최대 테이블 수에서** Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 테이블 수를 선택합니다.
Amazon Redshift에는 여러 클러스터 노드 유형에 사용하는 테이블을 제한하는 할당량이 있습니다. **자동**을 선택하면 노드 유형에 따라 대상 Amazon Redshift 클러스터에 적용할 테이블 수를 AWS SCT 결정합니다. 값을 수동으로 선택할 수도 있습니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [Amazon Redshift의 할당량 및 제한](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) 섹션을 참조하세요.
AWS SCT 는 Amazon Redshift 클러스터가 저장할 수 있는 테이블 수보다 많더라도 모든 소스 테이블을 변환합니다.는 변환된 코드를 프로젝트에 AWS SCT 저장하고 대상 데이터베이스에 적용하지 않습니다. 변환된 코드를 적용할 때 테이블의 Amazon Redshift 클러스터 할당량에 도달하면가 경고 메시지를 AWS SCT 표시합니다. 또한 테이블 수가 한도에 도달할 때까지 대상 Amazon Redshift 클러스터에 테이블을 AWS SCT 적용합니다.
+ 마이그레이션 전략을 선택합니다.
AWS 에서는 다양한 클러스터를 최적화 프로젝트의 소스 및 대상으로 사용할 것을 권장합니다. Amazon Redshift 최적화 프로세스를 시작하기 전에 소스 Amazon Redshift 클러스터의 사본을 생성합니다. 이 사본에 소스 데이터를 포함하거나 빈 클러스터를 생성할 수 있습니다.
소스 클러스터의 데이터를 대상 클러스터에 포함하려면 **Migration strategy**에서 **Migration to a copy**를 선택합니다.
최적화 제안을 검토하려면 **Migration strategy**에서 **Migration to a clean slate**를 선택합니다. 이러한 제안을 수락한 후에는 소스 데이터를 대상 클러스터로 마이그레이션합니다.
+ Amazon Redshift 테이블 열에 압축을 적용합니다. 이렇게 하려면 **Use compression encoding**을 선택합니다.
AWS SCT 는 기본 Amazon Redshift 알고리즘을 사용하여 열에 압축 인코딩을 자동으로 할당합니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [압축 인코딩](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)을 참조하세요.
기본적으로 Amazon Redshift는 정렬 및 배포 키로 정의된 열에 압축을 적용하지 않습니다. 이 동작을 변경하여 이러한 열에 압축을 적용할 수 있습니다. 이렇게 하려면 **Use compression encoding for KEY columns**를 선택합니다. **Use compression encoding** 옵션을 선택한 경우에만 이 옵션을 선택할 수 있습니다.
+ 자동 테이블 최적화 작업을 수행합니다.
자동 테이블 최적화는 테이블 디자인을 자동으로 최적화하는 Amazon Redshift의 자체 조정 프로세스입니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [자동 테이블 최적화 작업](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)을 참조하세요.
자동 테이블 최적화에만 사용하려면 왼쪽 창에서 **Optimization strategies**를 선택합니다. 그런 다음 **Use Amazon Redshift automatic table tuning**을 선택하고 **Initial key selection strategy**에서 **없음**을 선택합니다.
+ 전략을 사용하여 정렬 및 배포 키를 선택합니다.
Amazon Redshift 메타데이터, 통계 정보 또는 두 옵션을 모두 사용하여 정렬 및 배포 키를 선택할 수 있습니다. **Optimization strategies** 탭의 **Initial key selection strategy**에서 다음 옵션 중 하나를 선택합니다.
+ 메타데이터 사용, 통계 정보 무시
+ 메타데이터 무시, 통계 정보 사용
+ 메타데이터 및 통계 정보 사용
선택한 옵션에 따라 최적화 전략을 선택할 수 있습니다. 그런 다음 각 전략에 대해 값(0\$1100)을 입력합니다. 이러한 값은 각 전략의 가중치를 정의합니다. AWS SCT 는 이러한 가중치 값을 사용하여 각 규칙이 배포 및 정렬 키 선택에 미치는 영향을 정의합니다. 기본값은 AWS 마이그레이션 모범 사례를 기반으로 합니다.
**Find small tables** 전략에서 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 정의합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
+ 전략 세부 정보를 구성합니다.
각 최적화 전략의 가중치를 정의하는 것 외에 최적화 설정도 구성할 수 있습니다. 이 작업을 수행하려면 **Conversion optimization**을 선택합니다.
+ **Sort key columns limit**에 정렬 키의 최대 열 수를 입력합니다.
+ **Skewed threshold value**에 열에 대한 스큐된 값의 백분율(0\$1100)을 입력합니다. AWS SCT 는 스큐 값이 임계값보다 큰 열을 배포 키의 후보 목록에서 제외합니다. AWS SCT 는 열의 스큐된 값을 전체 레코드 수에 대한 가장 일반적인 값 발생 횟수의 백분율로 정의합니다.
+ **Top N queries from the query history table**에 분석할 가장 자주 사용되는 쿼리의 수(1\$1100)를 입력합니다.
+ **Select statistics user**에서 쿼리 통계를 분석하려는 데이터베이스 사용자를 선택합니다.
# 에 Azure Synapse Analytics 연결 AWS Schema Conversion Tool
AWS SCT 를 사용하여 스키마, 코드 객체 및 애플리케이션 코드를 Azure Synapse Analytics에서 Amazon Redshift로 변환할 수 있습니다.
## Azure Synapse Analytics를 소스 데이터베이스로 사용하기 위한 권한
Azure Synapse Analytics 데이터 웨어하우스를 소스로 사용하려면 다음과 같은 권한이 필요합니다.
+ VIEW DEFINITION
+ VIEW DATABASE STATE
스키마를 변환하려는 각 데이터베이스에 권한을 적용합니다.
## Azure Synapse Analytics에 소스로 연결
다음 절차에 따라 AWS Schema Conversion Tool을 사용하여 Azure Synapse Analytics 데이터 웨어하우스에 연결합니다.
**Azure Synapse Analytics 데이터 웨어하우스에 소스로 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **Azure Synapse Analytics**를 선택한 후 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 데이터베이스의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. 에서 데이터베이스 자격 증명을 사용하거나 수동으로 AWS Secrets Manager 입력합니다.
+ Secrets Manager의 데이터베이스 보안 인증 정보를 사용하려면 다음 지침을 따릅니다.
1. **AWS Secret**에서 보안 암호의 이름을 선택합니다.
1. **Populate**를 선택하여 Secrets Manager에서 데이터베이스 연결 대화 상자에 있는 모든 값을 자동으로 채웁니다.
Secrets Manager의 데이터베이스 보안 인증 사용에 대한 자세한 내용은 [AWS Secrets Manager 에서 구성 AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md) 섹션을 참조하세요.
+ Azure Synapse Analytics 데이터 웨어하우스의 연결 정보를 수동으로 입력하려면 다음 지침을 사용합니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.AzureSynapse.html)
1. **Test Connection**을 선택하여 AWS SCT 가 소스 데이터베이스에 연결할 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 데이터베이스에 연결합니다.
## Azure Synapse Analytics에서 Amazon Redshift로의 변환 설정
Azure Synapse Analytics에서 Amazon Redshift로의 변환 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Azure Synapse**를 선택한 다음 **Azure Synapse – Amazon Redshift**를 선택합니다.는 Azure Synapse Analytics에서 Amazon Redshift로의 변환에 사용할 수 있는 모든 설정을 AWS SCT 표시합니다.
의 Azure Synapse Analytics에서 Amazon Redshift로의 변환 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 대상 Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 최대 테이블 수를 설정합니다.
**대상 Amazon Redshift 클러스터의 최대 테이블 수에서** Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 테이블 수를 선택합니다.
Amazon Redshift에는 여러 클러스터 노드 유형에 사용하는 테이블을 제한하는 할당량이 있습니다. **자동**을 선택하면 노드 유형에 따라 대상 Amazon Redshift 클러스터에 적용할 테이블 수를 AWS SCT 결정합니다. 값을 수동으로 선택할 수도 있습니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [Amazon Redshift의 할당량 및 제한](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) 섹션을 참조하세요.
AWS SCT 는 Amazon Redshift 클러스터가 저장할 수 있는 것보다 많더라도 모든 소스 테이블을 변환합니다.는 변환된 코드를 프로젝트에 AWS SCT 저장하고 대상 데이터베이스에 적용하지 않습니다. 변환된 코드를 적용할 때 테이블의 Amazon Redshift 클러스터 할당량에 도달하면 AWS SCT 에서 경고 메시지가 표시됩니다. 또한 테이블 수가 한도에 도달할 때까지 대상 Amazon Redshift 클러스터에 테이블을 AWS SCT 적용합니다.
+ 소스 테이블의 파티션을 Amazon Redshift의 개별 테이블로 마이그레이션합니다. 이 작업을 수행하려면 **Use the UNION ALL view**를 선택하고 AWS SCT 가 단일 소스 테이블에 대해 생성할 수 있는 대상 테이블의 최대 수를 입력합니다.
Amazon Redshift는 테이블 파티셔닝을 지원하지 않습니다. 이 동작을 에뮬레이션하고 쿼리를 더 빠르게 실행하려면 소스 테이블의 각 파티션을 Amazon Redshift의 별도 테이블로 AWS SCT 마이그레이션할 수 있습니다. 그런 다음는 이러한 모든 테이블의 데이터가 포함된 뷰를 AWS SCT 생성합니다.
AWS SCT 는 소스 테이블의 파티션 수를 자동으로 결정합니다. 소스 테이블 파티셔닝 유형에 따라서는 이 숫자가 Amazon Redshift 클러스터에 적용할 수 있는 테이블의 할당량을 초과할 수 있습니다. 이 할당량에 도달하지 않으려면가 단일 소스 테이블의 파티션에 대해 생성할 AWS SCT 수 있는 최대 대상 테이블 수를 입력합니다. 기본 옵션은 368개 테이블이며, 이는 1년 중 366일 동안의 파티션과 `NO RANGE` 및 `UNKNOWN` 파티션에 대한 테이블 두 개를 나타냅니다.
+ Amazon Redshift 테이블 열에 압축을 적용합니다. 이렇게 하려면 **Use compression encoding**을 선택합니다.
AWS SCT 는 기본 Amazon Redshift 알고리즘을 사용하여 열에 압축 인코딩을 자동으로 할당합니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [압축 인코딩](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)을 참조하세요.
기본적으로 Amazon Redshift는 정렬 및 배포 키로 정의된 열에 압축을 적용하지 않습니다. 이 동작을 변경하여 이러한 열에 압축을 적용할 수 있습니다. 이렇게 하려면 **Use compression encoding for KEY columns**를 선택합니다. **Use compression encoding** 옵션을 선택한 경우에만 이 옵션을 선택할 수 있습니다.
## Azure Synapse Analytics에서 Amazon Redshift로의 변환 최적화 설정
Azure Synapse Analytics에서 Amazon Redshift로의 변환 최적화 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Azure Synapse**를 선택한 다음 **Azure Synapse – Amazon Redshift**를 선택합니다. 왼쪽 창에서 **최적화 전략을** 선택합니다. Azure Synapse Analytics에서 Amazon Redshift로의 변환에 대한 변환 최적화 설정을 AWS SCT 표시합니다.
의 Azure Synapse Analytics에서 Amazon Redshift로의 변환 최적화 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 자동 테이블 최적화 작업을 수행합니다. 이 작업을 수행하려면 **Use Amazon Redshift automatic table tuning**을 선택합니다.
자동 테이블 최적화는 테이블 디자인을 자동으로 최적화하는 Amazon Redshift의 자체 조정 프로세스입니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [자동 테이블 최적화 작업](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)을 참조하세요.
자동 테이블 최적화만 사용하려면 **Initial key selection strategy**에서 **없음**을 선택합니다.
+ 전략을 사용하여 정렬 및 배포 키를 선택합니다.
Amazon Redshift 메타데이터, 통계 정보 또는 두 옵션을 모두 사용하여 정렬 및 배포 키를 선택할 수 있습니다. **Optimization strategies** 탭의 **Initial key selection strategy**에서 다음 옵션 중 하나를 선택합니다.
+ 메타데이터 사용, 통계 정보 무시
+ 메타데이터 무시, 통계 정보 사용
+ 메타데이터 및 통계 정보 사용
선택한 옵션에 따라 최적화 전략을 선택할 수 있습니다. 그런 다음 각 전략에 대해 값(0\$1100)을 입력합니다. 이러한 값은 각 전략의 가중치를 정의합니다. AWS SCT 는 이러한 가중치 값을 사용하여 각 규칙이 배포 및 정렬 키 선택에 미치는 영향을 정의합니다. 기본값은 AWS 마이그레이션 모범 사례를 기반으로 합니다.
**Find small tables** 전략에서 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 정의합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
+ 전략 세부 정보를 구성합니다.
각 최적화 전략의 가중치를 정의하는 것 외에 최적화 설정도 구성할 수 있습니다. 이 작업을 수행하려면 **Conversion optimization**을 선택합니다.
+ **Sort key columns limit**에 정렬 키의 최대 열 수를 입력합니다.
+ **스큐된 임계값**에 열에 대해 스큐된 값의 백분율(0\$1100)을 입력합니다.는 배포 키의 후보 목록에서 스큐 값이 임계값보다 큰 열을 AWS SCT 제외합니다.는 열의 스큐된 값을 총 레코드 수에 대한 가장 일반적인 값의 발생 횟수의 백분율 비율로 AWS SCT 정의합니다.
+ **Top N queries from the query history table**에 분석할 가장 자주 사용되는 쿼리의 수(1\$1100)를 입력합니다.
+ **Select statistics user**에서 쿼리 통계를 분석하려는 데이터베이스 사용자를 선택합니다.
또한 **Optimization strategies** 탭에서 **Find small tables** 전략을 위한 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 간주합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
# 를 사용하여 Google BigQuery에 연결 AWS Schema Conversion Tool
AWS SCT 를 사용하여 스키마, 코드 객체 및 애플리케이션 코드를 BigQuery에서 Amazon Redshift로 변환할 수 있습니다.
## BigQuery를 소스로 사용하기 위한 권한
BigQuery 데이터 웨어하우스를 소스로 사용하려면 서비스 계정을 AWS SCT생성합니다. Google Cloud에서 애플리케이션은 서비스 계정을 사용하여 승인된 API 호출을 수행합니다. 서비스 계정은 사용자 계정과 다릅니다. 자세한 내용은 Google Cloud Identity and Access Management 문서에서 [서비스 계정](https://cloud.google.com/iam/docs/service-accounts)을 참조하세요.
서비스 계정에 다음 역할을 부여해야 합니다.
+ `BigQuery Admin`
+ `Storage Admin`
`BigQuery Admin` 역할은 프로젝트 내의 모든 리소스를 관리할 수 있는 권한을 제공합니다.는이 역할을 AWS SCT 사용하여 마이그레이션 프로젝트에서 BigQuery 메타데이터를 로드합니다.
`Storage Admin` 역할은 데이터 객체 및 버킷에 대한 모든 제어 권한을 부여합니다. 이 역할은에서 찾을 수 있습니다`Cloud Storage`.는이 역할을 AWS SCT 사용하여 BigQuery에서 데이터를 추출한 다음 Amazon Redshift에 로드합니다.
**서비스 계정 키 파일을 생성하려면**
1. [https://console.cloud.google.com/](https://console.cloud.google.com/)에서 Google Cloud 관리 콘솔에 로그인합니다.
1. [BigQuery API](https://console.cloud.google.com/apis/library/bigquery.googleapis.com) 페이지에서 **활성화**를 선택합니다. **API Enabled**가 표시된 경우에는 이 단계를 건너뜁니다.
1. [서비스 계정](https://console.cloud.google.com/iam-admin/serviceaccounts) 페이지에서 프로젝트를 선택한 다음 **Create service account**를 선택합니다.
1. **Service account details** 페이지에서 **서비스 계정 이름**을 설명하는 값을 입력합니다. **Create and continue**를 선택합니다. **Grant this service account access to the project** 페이지가 열립니다.
1. **역할 선택**에서 **BigQuery**를 선택한 다음 **BigQuery Admin**을 선택합니다.
1. **다른 역할 추가**를 선택합니다. **역할 선택**에서 **Cloud Storage**를 선택한 다음 **Storage Admin**을 선택합니다.
1. **계속**을 선택한 다음 **완료**를 선택합니다.
1. [서비스 계정](https://console.cloud.google.com/iam-admin/serviceaccounts) 페이지에서 생성된 서비스 계정을 선택합니다.
1. **키**를 선택한 다음 **키 추가**에서 **새 키 생성**을 선택합니다.
1. **JSON**을 선택한 다음 **생성**을 선택합니다. 프라이빗 키를 저장할 폴더를 선택하거나 브라우저에서 다운로드에 사용할 기본 폴더를 선택합니다.
BigQuery 데이터 웨어하우스에서 데이터를 추출하려면 Google Cloud Storage 버킷 폴더를 AWS SCT 사용합니다. 데이터 마이그레이션을 시작하기 전에 이 버킷을 생성합니다. **Create Local task** 대화 상자에 Google Cloud Storage 버킷 폴더의 경로를 입력합니다. 자세한 내용은 [ AWS SCT 작업 생성, 실행 및 모니터링](agents.md#agents.Tasks) 단원을 참조하십시오.
## BigQuery에 소스로 연결
다음 절차에 따라 AWS Schema Conversion Tool을 사용하여 소스 BigQuery 프로젝트에 연결합니다.
**BigQuery 소스 데이터 웨어하우스에 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **BigQuery**를 선택한 후 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 BigQuery 프로젝트의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. **키 경로**에는 서비스 계정 키 파일의 경로를 입력합니다. 이 파일 생성에 대한 자세한 내용은 [BigQuery를 소스로 사용하기 위한 권한](#CHAP_Source.BigQuery.Permissions) 섹션을 참조하세요.
1. **연결 테스트를** 선택하여가 소스 BigQuery 프로젝트에 연결할 AWS SCT 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 BigQuery 프로젝트에 연결합니다.
## BigQuery를 소스로 사용할 때의 제한 사항 AWS SCT
BigQuery를 소스로 사용할 때는 AWS SCT다음과 같은 제한 사항이 적용됩니다.
+ AWS SCT 는 분석 함수의 하위 쿼리 변환을 지원하지 않습니다.
+ AWS SCT 를 사용하여 BigQuery `SELECT AS STRUCT` 및 `SELECT AS VALUE` 문을 변환할 수 없습니다.
+ AWS SCT 는 다음 유형의 함수 변환을 지원하지 않습니다.
+ Approximate aggregate
+ Bit
+ 디버깅
+ Federated query
+ Geography
+ 해시
+ Mathematical
+ Net
+ Statistical aggregate
+ UUID
+ AWS SCT 는 문자열 함수 변환을 제한적으로 지원합니다.
+ AWS SCT 는 `UNNEST` 연산자의 변환을 지원하지 않습니다.
+ AWS SCT에서 상관 관계가 있는 조인 연산은 변환할 수 없습니다.
+ AWS SCT 는 `QUALIFY`, `WINDOW`, `LIMIT`및 `OFFSET` 절의 변환을 지원하지 않습니다.
+ AWS SCT 를 사용하여 재귀적 공통 테이블 표현식을 변환할 수 없습니다.
+ AWS SCT 는 `VALUES` 절 내에 하위 쿼리가 있는 `INSERT` 문의 변환을 지원하지 않습니다.
+ AWS SCT 는 중첩 필드 및 반복 레코드에 대한 `UPDATE` 문 변환을 지원하지 않습니다.
+ AWS SCT 를 사용하여 `STRUCT` 및 `ARRAY` 데이터 형식을 변환할 수 없습니다.
## BigQuery에서 Amazon Redshift로의 변환 설정
BigQuery에서 Amazon Redshift로의 변환 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Google BigQuery**를 선택한 다음 **Google BigQuery – Amazon Redshift**를 선택합니다.는 BigQuery에서 Amazon Redshift로의 변환에 사용할 수 있는 모든 설정을 AWS SCT 표시합니다.
의 BigQuery에서 Amazon Redshift로의 변환 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 대상 Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 최대 테이블 수를 설정합니다.
**대상 Amazon Redshift 클러스터의 최대 테이블 수에서** Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 테이블 수를 선택합니다.
Amazon Redshift에는 여러 클러스터 노드 유형에 사용하는 테이블을 제한하는 할당량이 있습니다. **자동**을 선택하면 노드 유형에 따라 대상 Amazon Redshift 클러스터에 적용할 테이블 수를 AWS SCT 결정합니다. 값을 수동으로 선택할 수도 있습니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [Amazon Redshift의 할당량 및 제한](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) 섹션을 참조하세요.
AWS SCT 는 Amazon Redshift 클러스터가 저장할 수 있는 것보다 많더라도 모든 소스 테이블을 변환합니다.는 변환된 코드를 프로젝트에 AWS SCT 저장하고 대상 데이터베이스에 적용하지 않습니다. 변환된 코드를 적용할 때 테이블의 Amazon Redshift 클러스터 할당량에 도달하면 AWS SCT 에서 경고 메시지가 표시됩니다. 또한 테이블 수가 한도에 도달할 때까지 대상 Amazon Redshift 클러스터에 테이블을 AWS SCT 적용합니다.
+ Amazon Redshift 테이블 열에 압축을 적용합니다. 이렇게 하려면 **Use compression encoding**을 선택합니다.
AWS SCT 는 기본 Amazon Redshift 알고리즘을 사용하여 열에 압축 인코딩을 자동으로 할당합니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [압축 인코딩](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)을 참조하세요.
기본적으로 Amazon Redshift는 정렬 및 배포 키로 정의된 열에 압축을 적용하지 않습니다. 이 동작을 변경하여 이러한 열에 압축을 적용할 수 있습니다. 이렇게 하려면 **Use compression encoding for KEY columns**를 선택합니다. **Use compression encoding** 옵션을 선택한 경우에만 이 옵션을 선택할 수 있습니다.
## BigQuery에서 Amazon Redshift로의 변환 최적화 설정
BigQuery에서 Amazon Redshift로의 변환 최적화 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Google BigQuery**를 선택한 다음 **Google BigQuery – Amazon Redshift**를 선택합니다. 왼쪽 창에서 **최적화 전략을** 선택합니다. BigQuery에서 Amazon Redshift로의 변환에 대한 변환 최적화 설정을 AWS SCT 표시합니다.
의 BigQuery에서 Amazon Redshift로의 변환 최적화 설정에는 다음과 같은 옵션이 AWS SCT 포함됩니다.
+ 자동 테이블 최적화 작업을 수행합니다. 이 작업을 수행하려면 **Use Amazon Redshift automatic table tuning**을 선택합니다.
자동 테이블 최적화는 테이블 디자인을 자동으로 최적화하는 Amazon Redshift의 자체 조정 프로세스입니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [자동 테이블 최적화 작업](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)을 참조하세요.
자동 테이블 최적화만 사용하려면 **Initial key selection strategy**에서 **없음**을 선택합니다.
+ 전략을 사용하여 정렬 및 배포 키를 선택합니다.
Amazon Redshift 메타데이터, 통계 정보 또는 두 옵션을 모두 사용하여 정렬 및 배포 키를 선택할 수 있습니다. **Optimization strategies** 탭의 **Initial key selection strategy**에서 다음 옵션 중 하나를 선택합니다.
+ 메타데이터 사용, 통계 정보 무시
+ 메타데이터 무시, 통계 정보 사용
+ 메타데이터 및 통계 정보 사용
선택한 옵션에 따라 최적화 전략을 선택할 수 있습니다. 그런 다음 각 전략에 대해 값(0\$1100)을 입력합니다. 이러한 값은 각 전략의 가중치를 정의합니다. AWS SCT 는 이러한 가중치 값을 사용하여 각 규칙이 배포 및 정렬 키 선택에 미치는 영향을 정의합니다. 기본값은 AWS 마이그레이션 모범 사례를 기반으로 합니다.
**Find small tables** 전략에서 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 정의합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
+ 전략 세부 정보를 구성합니다.
각 최적화 전략의 가중치를 정의하는 것 외에 최적화 설정도 구성할 수 있습니다. 이 작업을 수행하려면 **Conversion optimization**을 선택합니다.
+ **Sort key columns limit**에 정렬 키의 최대 열 수를 입력합니다.
+ **스큐된 임계값**에 열에 대해 스큐된 값의 백분율(0\$1100)을 입력합니다.는 배포 키의 후보 목록에서 스큐 값이 임계값보다 큰 열을 AWS SCT 제외합니다.는 열의 스큐된 값을 총 레코드 수에 대한 가장 일반적인 값의 발생 횟수의 백분율 비율로 AWS SCT 정의합니다.
+ **Top N queries from the query history table**에 분석할 가장 자주 사용되는 쿼리의 수(1\$1100)를 입력합니다.
+ **Select statistics user**에서 쿼리 통계를 분석하려는 데이터베이스 사용자를 선택합니다.
또한 **Optimization strategies** 탭에서 **Find small tables** 전략을 위한 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 간주합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
# 에 Greenplum 데이터베이스 연결 AWS Schema Conversion Tool
AWS SCT 를 사용하여 스키마, 코드 객체 및 애플리케이션 코드를 Greenplum 데이터베이스에서 Amazon Redshift로 변환할 수 있습니다.
## Greenplum Database를 소스로 사용하기 위한 권한
Greenplum Database를 소스로 사용하기 위해 필요한 권한은 다음과 같습니다.
+ CONNECT ON DATABASE **
+ USAGE ON SCHEMA **
+ SELECT ON *.*
+ SELECT ON SEQUENCE *.*
이전 예제에서 다음과 같이 자리 표시자를 바꿉니다.
+ *database\$1name*을 소스 데이터베이스의 이름으로 바꿉니다.
+ *schema\$1name*을 소스 스키마의 이름으로 바꿉니다.
+ *table\$1name*을 소스 테이블의 이름으로 바꿉니다.
+ *sequence\$1name*을 시퀀스 이름으로 바꿉니다.
## Greenplum Database에 소스로 연결
다음 절차에 따라 Greenplum 소스 데이터베이스에 연결합니다 AWS SCT.
**Greenplum 소스 데이터베이스에 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **SAP ASE**를 선택하고 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 데이터베이스의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. 에서 데이터베이스 자격 증명을 사용하거나 수동으로 AWS Secrets Manager 입력합니다.
+ Secrets Manager의 데이터베이스 보안 인증 정보를 사용하려면 다음 지침을 따릅니다.
1. **AWS Secret**에서 보안 암호의 이름을 선택합니다.
1. **Populate**를 선택하여 Secrets Manager에서 데이터베이스 연결 대화 상자에 있는 모든 값을 자동으로 채웁니다.
Secrets Manager의 데이터베이스 보안 인증 사용에 대한 자세한 내용은 [AWS Secrets Manager 에서 구성 AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md) 섹션을 참조하세요.
+ Greenplum 소스 데이터베이스 보안 인증 정보를 수동으로 입력하려면 다음 지침을 사용합니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.Greenplum.html)
1. **연결 테스트를** 선택하여가 소스 데이터베이스에 연결할 AWS SCT 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 데이터베이스에 연결합니다.
## Greenplum에서 Amazon Redshift로의 변환 설정
Greenplum에서 Amazon Redshift로의 변환 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Greenplum**을 선택한 다음 **Greenplum – Amazon Redshift**를 선택합니다. Greenplum에서 Amazon Redshift로의 변환에 사용할 수 있는 모든 설정을 AWS SCT 표시합니다.
의 Greenplum에서 Amazon Redshift로의 변환 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 대상 Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 최대 테이블 수를 설정합니다.
**대상 Amazon Redshift 클러스터의 최대 테이블 수에서** Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 테이블 수를 선택합니다.
Amazon Redshift에는 여러 클러스터 노드 유형에 사용하는 테이블을 제한하는 할당량이 있습니다. **자동**을 선택하면 노드 유형에 따라 대상 Amazon Redshift 클러스터에 적용할 테이블 수를 AWS SCT 결정합니다. 값을 수동으로 선택할 수도 있습니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [Amazon Redshift의 할당량 및 제한](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) 섹션을 참조하세요.
AWS SCT 는 Amazon Redshift 클러스터가 저장할 수 있는 것보다 많더라도 모든 소스 테이블을 변환합니다.는 변환된 코드를 프로젝트에 AWS SCT 저장하고 대상 데이터베이스에 적용하지 않습니다. 변환된 코드를 적용할 때 테이블의 Amazon Redshift 클러스터 할당량에 도달하면 AWS SCT 에서 경고 메시지가 표시됩니다. 또한 테이블 수가 한도에 도달할 때까지 대상 Amazon Redshift 클러스터에 테이블을 AWS SCT 적용합니다.
+ 소스 테이블의 파티션을 Amazon Redshift의 개별 테이블로 마이그레이션합니다. 이 작업을 수행하려면 **Use the UNION ALL view**를 선택하고 AWS SCT 가 단일 소스 테이블에 대해 생성할 수 있는 대상 테이블의 최대 수를 입력합니다.
Amazon Redshift는 테이블 파티셔닝을 지원하지 않습니다. 이 동작을 에뮬레이션하고 쿼리를 더 빠르게 실행하려면 소스 테이블의 각 파티션을 Amazon Redshift의 별도 테이블로 AWS SCT 마이그레이션할 수 있습니다. 그런 다음는 이러한 모든 테이블의 데이터가 포함된 뷰를 AWS SCT 생성합니다.
AWS SCT 는 소스 테이블의 파티션 수를 자동으로 결정합니다. 소스 테이블 파티셔닝 유형에 따라서는 이 숫자가 Amazon Redshift 클러스터에 적용할 수 있는 테이블의 할당량을 초과할 수 있습니다. 이 할당량에 도달하지 않으려면가 단일 소스 테이블의 파티션에 대해 생성할 AWS SCT 수 있는 최대 대상 테이블 수를 입력합니다. 기본 옵션은 368개 테이블이며, 이는 1년 중 366일 동안의 파티션과 `NO RANGE` 및 `UNKNOWN` 파티션에 대한 테이블 두 개를 나타냅니다.
+ Amazon Redshift 테이블 열에 압축을 적용합니다. 이렇게 하려면 **Use compression encoding**을 선택합니다.
AWS SCT 는 기본 Amazon Redshift 알고리즘을 사용하여 열에 압축 인코딩을 자동으로 할당합니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [압축 인코딩](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)을 참조하세요.
기본적으로 Amazon Redshift는 정렬 및 배포 키로 정의된 열에 압축을 적용하지 않습니다. 이 동작을 변경하여 이러한 열에 압축을 적용할 수 있습니다. 이렇게 하려면 **Use compression encoding for KEY columns**를 선택합니다. **Use compression encoding** 옵션을 선택한 경우에만 이 옵션을 선택할 수 있습니다.
## Greenplum에서 Amazon Redshift로의 변환 최적화 설정
Greenplum에서 Amazon Redshift로의 변환 최적화 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Greenplum**을 선택한 다음 **Greenplum – Amazon Redshift**를 선택합니다. 왼쪽 창에서 **최적화 전략을** 선택합니다. Greenplum에서 Amazon Redshift로의 변환에 대한 변환 최적화 설정을 AWS SCT 표시합니다.
의 Greenplum에서 Amazon Redshift로의 변환 최적화 설정에는 다음과 같은 옵션이 AWS SCT 포함됩니다.
+ 자동 테이블 최적화 작업을 수행합니다. 이 작업을 수행하려면 **Use Amazon Redshift automatic table tuning**을 선택합니다.
자동 테이블 최적화는 테이블 디자인을 자동으로 최적화하는 Amazon Redshift의 자체 조정 프로세스입니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [자동 테이블 최적화 작업](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)을 참조하세요.
자동 테이블 최적화만 사용하려면 **Initial key selection strategy**에서 **없음**을 선택합니다.
+ 전략을 사용하여 정렬 및 배포 키를 선택합니다.
Amazon Redshift 메타데이터, 통계 정보 또는 두 옵션을 모두 사용하여 정렬 및 배포 키를 선택할 수 있습니다. **Optimization strategies** 탭의 **Initial key selection strategy**에서 다음 옵션 중 하나를 선택합니다.
+ 메타데이터 사용, 통계 정보 무시
+ 메타데이터 무시, 통계 정보 사용
+ 메타데이터 및 통계 정보 사용
선택한 옵션에 따라 최적화 전략을 선택할 수 있습니다. 그런 다음 각 전략에 대해 값(0\$1100)을 입력합니다. 이러한 값은 각 전략의 가중치를 정의합니다. AWS SCT 는 이러한 가중치 값을 사용하여 각 규칙이 배포 및 정렬 키 선택에 미치는 영향을 정의합니다. 기본값은 AWS 마이그레이션 모범 사례를 기반으로 합니다.
**Find small tables** 전략에서 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 정의합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
+ 전략 세부 정보를 구성합니다.
각 최적화 전략의 가중치를 정의하는 것 외에 최적화 설정도 구성할 수 있습니다. 이 작업을 수행하려면 **Conversion optimization**을 선택합니다.
+ **Sort key columns limit**에 정렬 키의 최대 열 수를 입력합니다.
+ **스큐된 임계값**에 열에 대해 스큐된 값의 백분율(0\$1100)을 입력합니다.는 배포 키의 후보 목록에서 스큐 값이 임계값보다 큰 열을 AWS SCT 제외합니다.는 열의 스큐된 값을 총 레코드 수에 대한 가장 일반적인 값의 발생 횟수의 백분율 비율로 AWS SCT 정의합니다.
+ **Top N queries from the query history table**에 분석할 가장 자주 사용되는 쿼리의 수(1\$1100)를 입력합니다.
+ **Select statistics user**에서 쿼리 통계를 분석하려는 데이터베이스 사용자를 선택합니다.
또한 **Optimization strategies** 탭에서 **Find small tables** 전략을 위한 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 간주합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
# 를 사용하여 Netezza에 연결 AWS Schema Conversion Tool
AWS SCT 를 사용하여 스키마, 코드 객체 및 애플리케이션 코드를 Netezza에서 Amazon Redshift로 변환할 수 있습니다.
## Netezza를 소스로 사용하기 위한 권한
Netezza를 소스로 사용하기 위해 필요한 권한은 다음과 같습니다.
+ select on system.definition\$1schema.system view
+ select on system.definition\$1schema.system table
+ select on system.definition\$1schema.management table
+ list on **
+ list on **
+ list on **.all.table
+ list on **.all.external table
+ list on **.all.view
+ list on **.all.materialized view
+ list on **.all.procedure
+ list on **.all.sequence
+ list on **.all.function
+ list on **.all.aggregate
이전 예제에서 다음과 같이 자리 표시자를 바꿉니다.
+ *database\$1name*을 소스 데이터베이스의 이름으로 바꿉니다.
+ *schema\$1name*을 소스 스키마의 이름으로 바꿉니다.
AWS SCT 에서는 다음 시스템 테이블 및 뷰에 대한 액세스 권한이 필요합니다. 위 목록의 `system.definition_schema.system view` 및 `system.definition_schema.system tables`에 대한 액세스 권한을 부여하는 대신 다음과 같은 객체에 대한 액세스 권한을 부여할 수 있습니다.
+ select on system.definition\$1schema.\$1t\$1aggregate
+ select on system.definition\$1schema.\$1t\$1class
+ select on system.definition\$1schema.\$1t\$1constraint
+ select on system.definition\$1schema.\$1t\$1const\$1relattr
+ select on system.definition\$1schema.\$1t\$1database
+ select on system.definition\$1schema.\$1t\$1grpobj\$1priv
+ select on system.definition\$1schema.\$1t\$1grpusr
+ select on system.definition\$1schema.\$1t\$1hist\$1config
+ select on system.definition\$1schema.\$1t\$1object
+ select on system.definition\$1schema.\$1t\$1object\$1classes
+ select on system.definition\$1schema.\$1t\$1proc
+ select on system.definition\$1schema.\$1t\$1type
+ select on system.definition\$1schema.\$1t\$1user
+ select on system.definition\$1schema.\$1t\$1usrobj\$1priv
+ select on system.definition\$1schema.\$1vt\$1sequence
+ select on system.definition\$1schema.\$1v\$1aggregate
+ select on system.definition\$1schema.\$1v\$1constraint\$1depends
+ select on system.definition\$1schema.\$1v\$1database
+ select on system.definition\$1schema.\$1v\$1datatype
+ select on system.definition\$1schema.\$1v\$1dslice
+ select on system.definition\$1schema.\$1v\$1function
+ select on system.definition\$1schema.\$1v\$1group
+ select on system.definition\$1schema.\$1v\$1obj\$1relation
+ select on system.definition\$1schema.\$1v\$1obj\$1relation\$1xdb
+ select on system.definition\$1schema.\$1v\$1procedure
+ select on system.definition\$1schema.\$1v\$1relation\$1column
+ select on system.definition\$1schema.\$1v\$1relation\$1keydata
+ select on system.definition\$1schema.\$1v\$1relobjclasses
+ select on system.definition\$1schema.\$1v\$1schema\$1xdb
+ select on system.definition\$1schema.\$1v\$1sequence
+ select on system.definition\$1schema.\$1v\$1synonym
+ select on system.definition\$1schema.\$1v\$1system\$1info
+ select on system.definition\$1schema.\$1v\$1sys\$1constraint
+ select on system.definition\$1schema.\$1v\$1sys\$1object\$1dslice\$1info
+ select on system.definition\$1schema.\$1v\$1sys\$1user
+ select on system.definition\$1schema.\$1v\$1table
+ select on system.definition\$1schema.\$1v\$1table\$1constraint
+ select on system.definition\$1schema.\$1v\$1table\$1dist\$1map
+ select on system.definition\$1schema.\$1v\$1table\$1organize\$1column
+ select on system.definition\$1schema.\$1v\$1table\$1storage\$1stat
+ select on system.definition\$1schema.\$1v\$1user
+ select on system.definition\$1schema.\$1v\$1view
+ select on system.information\$1schema.\$1v\$1relation\$1column
+ select on system.information\$1schema.\$1v\$1table
+ select on \$1hist\$1column\$1access\$1\$1
## Netezza에 소스로 연결
다음 절차에 따라 AWS Schema Conversion Tool을 사용하여 Netezza 소스 데이터베이스에 연결합니다.
**Netezza 소스 데이터베이스에 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **Netezza**를 선택한 후 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 데이터베이스의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. 에서 데이터베이스 자격 증명을 사용하거나 수동으로 AWS Secrets Manager 입력합니다.
+ Secrets Manager의 데이터베이스 보안 인증 정보를 사용하려면 다음 지침을 따릅니다.
1. **AWS Secret**에서 보안 암호의 이름을 선택합니다.
1. **Populate**를 선택하여 Secrets Manager에서 데이터베이스 연결 대화 상자에 있는 모든 값을 자동으로 채웁니다.
Secrets Manager의 데이터베이스 보안 인증 사용에 대한 자세한 내용은 [AWS Secrets Manager 에서 구성 AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md) 섹션을 참조하세요.
+ Netezza 소스 데이터베이스 연결 정보를 수동으로 입력하려면 다음 지침을 사용합니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.Netezza.html)
1. **연결 테스트를** 선택하여가 소스 데이터베이스에 연결할 AWS SCT 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 데이터베이스에 연결합니다.
## 지속적인 데이터 복제 구성
Netezza 데이터베이스 스키마를 변환하여 Amazon Redshift 데이터베이스에 적용한 후 데이터 추출 에이전트를 사용하여 AWS SCT 데이터를 마이그레이션할 수 있습니다. 에이전트가 데이터를 추출하여 Amazon S3 버킷에 업로드합니다. 그런 다음 AWS SCT 를 사용하여 Amazon S3에서 Amazon Redshift로 데이터를 복사할 수 있습니다.
마이그레이션 프로세스 중에 소스 데이터베이스의 데이터가 변경되면 AWS SCT 데이터 추출 에이전트를 사용하여 지속적인 변경 사항을 캡처할 수 있습니다. 그러면 초기 데이터 마이그레이션을 완료한 후 대상 데이터베이스에 이러한 진행 중인 변경 사항을 복제할 수 있습니다. 이 프로세스를 지속적인 데이터 복제 또는 *변경 데이터 캡처*(CDC)라고 합니다.
**Netezza에서 Amazon Redshift로의 마이그레이션을 위한 지속적인 데이터 복제를 구성하려면**
1. 소스 데이터베이스에서 기록 데이터베이스를 생성합니다. Netezza 명령줄 인터페이스(CLI)에서 다음 코드 예제를 사용할 수 있습니다.
```
nzhistcreatedb -d history_database_name -t query -v 1 -u load_user -o histdb_owner -p your_password
```
이전 예제에서 *history\$1database\$1name*을 기록 데이터베이스의 이름으로 바꿉니다. 그 다음으로, *load\$1user*를 데이터베이스에 기록 데이터를 로드하기 위해 정의한 사용자 이름으로 바꿉니다. 그런 다음, *histdb\$1owner*를 기록 데이터베이스의 소유자로 정의한 사용자 이름으로 바꿉니다. 이 사용자를 이미 생성하고 `CREATE DATABASE` 권한을 부여했는지 확인합니다. 마지막으로 *your\$1password*를 안전한 암호로 바꿉니다.
1. 기록 로깅을 구성합니다. 이 작업을 수행하려면 다음 코드 예제를 사용합니다.
```
CREATE HISTORY CONFIGURATION history_configuration_name HISTTYPE QUERY
DATABASE history_database_name USER load_user PASSWORD your_password COLLECT PLAN, COLUMN
LOADINTERVAL 1 LOADMINTHRESHOLD 0 LOADMAXTHRESHOLD 0 STORAGELIMIT 25
LOADRETRY 2 VERSION 1;
```
이전 예제에서 *history\$1configuration\$1name* 및 *history\$1database\$1name*을 기록 구성 및 기록 데이터베이스의 이름으로 바꿉니다. 그 다음으로, *load\$1user*를 데이터베이스에 기록 데이터를 로드하기 위해 정의한 사용자 이름으로 바꿉니다. 그런 다음 *your\$1password*를 안전한 암호로 바꿉니다.
1. 기록 데이터베이스의 모든 테이블에 읽기 권한을 부여합니다. 다음 코드 예제를 사용하여 `SELECT` 권한을 부여할 수 있습니다.
```
GRANT SELECT ON history_database_name.ALL.TABLE TO your_user;
```
이전 예제에서 *history\$1database\$1name*을 기록 데이터베이스의 이름으로 바꿉니다. 다음으로, *your\$1user*를 Netezza 데이터베이스 작업에 필요한 최소 권한을 가진 사용자 이름으로 바꿉니다. 에서이 데이터베이스 사용자의 자격 증명을 사용합니다 AWS SCT.
1. 소스 스키마의 각 테이블에 대한 통계를 수집하여 열의 카디널리티에 대한 정보를 가져옵니다. 다음 명령을 사용하여 기록 데이터베이스에 통계를 생성할 수 있습니다.
```
GENERATE STATISTICS on "schema_name"."table_name";
```
이전 예제에서 *schema\$1name* 및 *table\$1name*을 데이터베이스 스키마 및 테이블의 이름으로 바꿉니다.
1. 다음 쿼리를 실행하여 사전 조건을 완료해야 합니다.
```
SELECT COUNT(*) FROM history_database_name.history_schema_name."$hist_column_access_N";
```
이전 예제에서 *history\$1database\$1name* 및 *history\$1schema\$1name*을 기록 데이터베이스 및 스키마의 이름으로 바꿉니다. 그 다음, *N*을 기록 데이터베이스의 버전 번호로 바꿉니다. 기록 데이터베이스 버전에 대한 자세한 내용은 [IBM Netezza 설명서](https://www.ibm.com/docs/en/netezza?topic=history-database-versions)를 참조하세요.
1. 데이터 추출 에이전트를 설치합니다. 자세한 내용은 [추출 에이전트 설치](agents.md#agents.Installing) 단원을 참조하십시오.
모든 추출기 인스턴스에 대해 `settings.properties` 파일의 `{working.folder}` 파라미터가 동일한 폴더를 가리키는지 확인합니다. 이 경우 추출기가 CDC 세션을 조정하고 모든 하위 작업에 대한 단일 트랜잭션 지점을 사용할 수 있습니다.
1. 데이터 추출 에이전트를 등록합니다. 자세한 내용은 [에 추출 에이전트 등록 AWS Schema Conversion Tool](agents.md#agents.Using) 단원을 참조하십시오.
1. CDC 작업을 생성합니다. 자세한 내용은 [ AWS SCT 작업 생성, 실행 및 모니터링](agents.md#agents.Tasks) 단원을 참조하십시오.
1. AWS SCT에서 프로젝트를 엽니다. 왼쪽 창에서 소스 테이블을 선택합니다. 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 열고 **Create local task**를 선택합니다.
1. **작업 이름**에 데이터 마이그레이션 작업을 설명하는 이름을 입력합니다.
1. **Migration mode**에서 **Extract, upload, and copy**를 선택합니다.
1. **Enable CDC**를 선택합니다.
1. **CDC settings** 탭을 선택하고 CDC 세션의 범위와 일정을 정의합니다.
1. **Test task**를 선택하여 작업 폴더, Amazon S3 버킷 및 Amazon Redshift 데이터 웨어하우스에 연결할 수 있는지 확인합니다.
1. **생성**을 선택하여 작업을 생성합니다.
1. **작업** 탭을 선택하고 목록에서 작업을 선택한 다음 **시작**을 선택합니다.
1. AWS SCT 작업은 대상 데이터베이스에서 트랜잭션 일관성을 유지합니다. 데이터 추출 에이전트는 소스의 트랜잭션을 트랜잭션 ID 순서대로 복제합니다.
마이그레이션 세션이 중지되거나 실패한 경우 CDC 처리도 중지됩니다.
## Netezza에서 Amazon Redshift로의 변환 설정
Netezza에서 Amazon Redshift로의 변환 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Netezza**를 선택한 다음 **Netezza – Amazon Redshift**를 선택합니다. Netezza에서 Amazon Redshift로의 변환에 사용할 수 있는 모든 설정을 AWS SCT 표시합니다.
의 Netezza에서 Amazon Redshift로의 변환 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 대상 Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 최대 테이블 수를 설정합니다.
**대상 Amazon Redshift 클러스터의 최대 테이블 수에서** Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 테이블 수를 선택합니다.
Amazon Redshift에는 여러 클러스터 노드 유형에 사용하는 테이블을 제한하는 할당량이 있습니다. **자동**을 선택하면 노드 유형에 따라 대상 Amazon Redshift 클러스터에 적용할 테이블 수를 AWS SCT 결정합니다. 값을 수동으로 선택할 수도 있습니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [Amazon Redshift의 할당량 및 제한](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) 섹션을 참조하세요.
AWS SCT 는 Amazon Redshift 클러스터가 저장할 수 있는 것보다 많더라도 모든 소스 테이블을 변환합니다.는 변환된 코드를 프로젝트에 AWS SCT 저장하고 대상 데이터베이스에 적용하지 않습니다. 변환된 코드를 적용할 때 테이블의 Amazon Redshift 클러스터 할당량에 도달하면 AWS SCT 에서 경고 메시지가 표시됩니다. 또한 테이블 수가 한도에 도달할 때까지 대상 Amazon Redshift 클러스터에 테이블을 AWS SCT 적용합니다.
+ Amazon Redshift 테이블 열에 압축을 적용합니다. 이렇게 하려면 **Use compression encoding**을 선택합니다.
AWS SCT 는 기본 Amazon Redshift 알고리즘을 사용하여 열에 압축 인코딩을 자동으로 할당합니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [압축 인코딩](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)을 참조하세요.
기본적으로 Amazon Redshift는 정렬 및 배포 키로 정의된 열에 압축을 적용하지 않습니다. 이 동작을 변경하여 이러한 열에 압축을 적용할 수 있습니다. 이렇게 하려면 **Use compression encoding for KEY columns**를 선택합니다. **Use compression encoding** 옵션을 선택한 경우에만 이 옵션을 선택할 수 있습니다.
## Netezza에서 Amazon Redshift로의 변환 최적화 설정
Netezza에서 Amazon Redshift로의 변환 최적화 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Netezza**를 선택한 다음 **Netezza – Amazon Redshift**를 선택합니다. 왼쪽 창에서 **최적화 전략을** 선택합니다. Netezza에서 Amazon Redshift로의 변환에 대한 변환 최적화 설정을 AWS SCT 표시합니다.
의 Netezza에서 Amazon Redshift로의 변환 최적화 설정에는 다음과 같은 옵션이 AWS SCT 포함됩니다.
+ 자동 테이블 최적화 작업을 수행합니다. 이 작업을 수행하려면 **Use Amazon Redshift automatic table tuning**을 선택합니다.
자동 테이블 최적화는 테이블 디자인을 자동으로 최적화하는 Amazon Redshift의 자체 조정 프로세스입니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [자동 테이블 최적화 작업](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)을 참조하세요.
자동 테이블 최적화만 사용하려면 **Initial key selection strategy**에서 **없음**을 선택합니다.
+ 전략을 사용하여 정렬 및 배포 키를 선택합니다.
Amazon Redshift 메타데이터, 통계 정보 또는 두 옵션을 모두 사용하여 정렬 및 배포 키를 선택할 수 있습니다. **Optimization strategies** 탭의 **Initial key selection strategy**에서 다음 옵션 중 하나를 선택합니다.
+ 메타데이터 사용, 통계 정보 무시
+ 메타데이터 무시, 통계 정보 사용
+ 메타데이터 및 통계 정보 사용
선택한 옵션에 따라 최적화 전략을 선택할 수 있습니다. 그런 다음 각 전략에 대해 값(0\$1100)을 입력합니다. 이러한 값은 각 전략의 가중치를 정의합니다. AWS SCT 는 이러한 가중치 값을 사용하여 각 규칙이 배포 및 정렬 키 선택에 미치는 영향을 정의합니다. 기본값은 AWS 마이그레이션 모범 사례를 기반으로 합니다.
**Find small tables** 전략에서 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 정의합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
+ 전략 세부 정보를 구성합니다.
각 최적화 전략의 가중치를 정의하는 것 외에 최적화 설정도 구성할 수 있습니다. 이 작업을 수행하려면 **Conversion optimization**을 선택합니다.
+ **Sort key columns limit**에 정렬 키의 최대 열 수를 입력합니다.
+ **스큐된 임계값**에 열에 대한 스큐된 값의 백분율(0\$1100)을 입력합니다.는 배포 키의 후보 목록에서 스큐 값이 임계값보다 큰 열을 AWS SCT 제외합니다.는 열에 대한 스큐된 값을 총 레코드 수에 대한 가장 일반적인 값의 발생 횟수의 백분율 비율로 AWS SCT 정의합니다.
+ **Top N queries from the query history table**에 분석할 가장 자주 사용되는 쿼리의 수(1\$1100)를 입력합니다.
+ **Select statistics user**에서 쿼리 통계를 분석하려는 데이터베이스 사용자를 선택합니다.
또한 **Optimization strategies** 탭에서 **Find small tables** 전략을 위한 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 간주합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
# 에 Oracle Data Warehouse 연결 AWS SCT
AWS SCT 를 사용하여 스키마, 코드 객체 및 애플리케이션 코드를 Oracle Data Warehouse에서 Amazon Redshift 또는 Amazon Redshift로 변환하고 조합하여 AWS Glue 사용할 수 있습니다.
## Oracle Data Warehouse를 소스로 사용하기 위한 권한
Oracle Data Warehouse를 소스로 사용하기 위해 필요한 권한은 다음과 같습니다.
+ 연결
+ select\$1catalog\$1role
+ select any dictionary
## Oracle Data Warehouse에 소스로 연결
다음 절차에 따라 AWS Schema Conversion Tool을 사용하여 Oracle Data Warehouse 소스 데이터베이스에 연결합니다.
**Oracle Data Warehouse 소스 데이터베이스에 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **Oracle**를 선택한 후 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 데이터베이스의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. 에서 데이터베이스 자격 증명을 사용하거나 수동으로 AWS Secrets Manager 입력합니다.
+ Secrets Manager의 데이터베이스 보안 인증 정보를 사용하려면 다음 지침을 따릅니다.
1. **AWS Secret**에서 보안 암호의 이름을 선택합니다.
1. **Populate**를 선택하여 Secrets Manager에서 데이터베이스 연결 대화 상자에 있는 모든 값을 자동으로 채웁니다.
Secrets Manager의 데이터베이스 보안 인증 사용에 대한 자세한 내용은 [AWS Secrets Manager 에서 구성 AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md) 섹션을 참조하세요.
+ Oracle 소스 데이터 웨어하우스 연결 정보를 수동으로 입력하려면 다음 지침을 사용합니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.OracleDW.html)
1. **연결 테스트를** 선택하여가 소스 데이터베이스에 연결할 AWS SCT 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 데이터베이스에 연결합니다.
## Oracle Data Warehouse에서 Amazon Redshift로의 변환 설정
Oracle Data Warehouse에서 Amazon Redshift로의 변환 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Oracle**을 선택한 다음 **Oracle – Amazon Redshift**를 선택합니다.는 Oracle Data Warehouse에서 Amazon Redshift로의 변환에 사용할 수 있는 모든 설정을 AWS SCT 표시합니다.
의 Oracle Data Warehouse에서 Amazon Redshift로의 변환 설정에는 다음과 같은 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 대상 Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 최대 테이블 수를 설정합니다.
**대상 Amazon Redshift 클러스터의 최대 테이블 수에서** Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 테이블 수를 선택합니다.
Amazon Redshift에는 여러 클러스터 노드 유형에 사용하는 테이블을 제한하는 할당량이 있습니다. **자동**을 선택하면 노드 유형에 따라 대상 Amazon Redshift 클러스터에 적용할 테이블 수를 AWS SCT 결정합니다. 값을 수동으로 선택할 수도 있습니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [Amazon Redshift의 할당량 및 제한](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) 섹션을 참조하세요.
AWS SCT 는 Amazon Redshift 클러스터가 저장할 수 있는 것보다 많더라도 모든 소스 테이블을 변환합니다.는 변환된 코드를 프로젝트에 AWS SCT 저장하고 대상 데이터베이스에 적용하지 않습니다. 변환된 코드를 적용할 때 테이블의 Amazon Redshift 클러스터 할당량에 도달하면 AWS SCT 에서 경고 메시지가 표시됩니다. 또한 테이블 수가 한도에 도달할 때까지 대상 Amazon Redshift 클러스터에 테이블을 AWS SCT 적용합니다.
+ 소스 테이블의 파티션을 Amazon Redshift의 개별 테이블로 마이그레이션합니다. 이 작업을 수행하려면 **Use the UNION ALL view**를 선택하고 AWS SCT 가 단일 소스 테이블에 대해 생성할 수 있는 대상 테이블의 최대 수를 입력합니다.
Amazon Redshift는 테이블 파티셔닝을 지원하지 않습니다. 이 동작을 에뮬레이션하고 쿼리를 더 빠르게 실행하려면 소스 테이블의 각 파티션을 Amazon Redshift의 별도 테이블로 AWS SCT 마이그레이션할 수 있습니다. 그런 다음는 이러한 모든 테이블의 데이터가 포함된 뷰를 AWS SCT 생성합니다.
AWS SCT 는 소스 테이블의 파티션 수를 자동으로 결정합니다. 소스 테이블 파티셔닝 유형에 따라서는 이 숫자가 Amazon Redshift 클러스터에 적용할 수 있는 테이블의 할당량을 초과할 수 있습니다. 이 할당량에 도달하지 않으려면가 단일 소스 테이블의 파티션에 대해 생성할 AWS SCT 수 있는 최대 대상 테이블 수를 입력합니다. 기본 옵션은 368개 테이블이며, 이는 1년 중 366일 동안의 파티션과 `NO RANGE` 및 `UNKNOWN` 파티션에 대한 테이블 두 개를 나타냅니다.
+ Amazon Redshift에서 지원하지 않는 날짜/시간 형식 요소를 사용하여 `TO_CHAR`, `TO_DATE`, `TO_NUMBER` 등의 데이터 유형 서식 설정 함수를 변환합니다. 기본적으로 AWS SCT 는 확장 팩 함수를 사용하여 변환된 코드에서 지원되지 않는 이러한 형식 요소의 사용을 에뮬레이션합니다.
Oracle의 날짜/시간 형식 모델에는 Amazon Redshift의 날짜/시간 형식 문자열과 비교하여 더 많은 요소가 포함되어 있습니다. 소스 코드에 Amazon Redshift가 지원하는 날짜/시간 형식 요소만 포함된 경우 변환된 코드에 확장 팩 함수가 필요하지 않습니다. 변환된 코드에서 확장 팩 함수를 사용하지 않으려면 **Datetype format elements that you use in the Oracle code are similar to datetime format strings in Amazon Redshift**를 선택합니다. 이 경우, 변환된 코드는 더 빠르게 작동합니다.
Oracle의 숫자 형식 모델에는 Amazon Redshift의 숫자 형식 문자열과 비교하여 더 많은 요소가 포함되어 있습니다. 소스 코드에 Amazon Redshift가 지원하는 숫자 형식 요소만 포함된 경우 변환된 코드에 확장 팩 함수가 필요하지 않습니다. 변환된 코드에서 확장 팩 함수를 사용하지 않으려면 **Numeric format elements that you use in the Oracle code are similar to numeric format strings in Amazon Redshift**를 선택합니다. 이 경우, 변환된 코드는 더 빠르게 작동합니다.
+ Oracle `LEAD` 및 `LAG` 분석 함수를 변환합니다. 기본적으로 AWS SCT 가 각 `LEAD` 및 `LAG` 함수에 대한 작업 항목을 발생시킵니다.
소스 코드가 이러한 함수의 오프셋에 대해 기본값을 사용하지 않는 경우 AWS SCT 는 `NVL` 함수를 사용하여 이러한 함수의 사용을 에뮬레이션할 수 있습니다. 이렇게 하려면 **Use the NVL function to emulate the behavior of Oracle LEAD and LAG functions**를 선택합니다.
+ Amazon Redshift 클러스터에서 기본 키와 고유 키의 동작을 에뮬레이션하려면 **Emulate the behavior of primary and unique keys**를 선택합니다.
Amazon Redshift는 고유 키와 기본 키를 적용하지 않으며 정보 제공 목적으로만 사용합니다. 코드에 이러한 제약 조건을 사용하는 경우가 변환된 코드에서 해당 동작을 AWS SCT 에뮬레이션하는지 확인합니다.
+ Amazon Redshift 테이블 열에 압축을 적용합니다. 이렇게 하려면 **Use compression encoding**을 선택합니다.
AWS SCT 는 기본 Amazon Redshift 알고리즘을 사용하여 열에 압축 인코딩을 자동으로 할당합니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [압축 인코딩](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)을 참조하세요.
기본적으로 Amazon Redshift는 정렬 및 배포 키로 정의된 열에 압축을 적용하지 않습니다. 이 동작을 변경하여 이러한 열에 압축을 적용할 수 있습니다. 이렇게 하려면 **Use compression encoding for KEY columns**를 선택합니다. **Use compression encoding** 옵션을 선택한 경우에만 이 옵션을 선택할 수 있습니다.
## Oracle Data Warehouse에서 Amazon Redshift로의 변환 최적화 설정
Oracle Data Warehouse에서 Amazon Redshift로의 변환 최적화 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Oracle**를 선택한 다음 **Oracle – Amazon Redshift**를 선택합니다. 왼쪽 창에서 **최적화 전략을** 선택합니다. Oracle Data Warehouse에서 Amazon Redshift로의 변환에 대한 변환 최적화 설정을 AWS SCT 표시합니다.
의 Oracle Data Warehouse에서 Amazon Redshift로의 변환 최적화 설정에는 다음과 같은 옵션이 AWS SCT 포함됩니다.
+ 자동 테이블 최적화 작업을 수행합니다. 이 작업을 수행하려면 **Use Amazon Redshift automatic table tuning**을 선택합니다.
자동 테이블 최적화는 테이블 디자인을 자동으로 최적화하는 Amazon Redshift의 자체 조정 프로세스입니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [자동 테이블 최적화 작업](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)을 참조하세요.
자동 테이블 최적화만 사용하려면 **Initial key selection strategy**에서 **없음**을 선택합니다.
+ 전략을 사용하여 정렬 및 배포 키를 선택합니다.
Amazon Redshift 메타데이터, 통계 정보 또는 두 옵션을 모두 사용하여 정렬 및 배포 키를 선택할 수 있습니다. **Optimization strategies** 탭의 **Initial key selection strategy**에서 다음 옵션 중 하나를 선택합니다.
+ 메타데이터 사용, 통계 정보 무시
+ 메타데이터 무시, 통계 정보 사용
+ 메타데이터 및 통계 정보 사용
선택한 옵션에 따라 최적화 전략을 선택할 수 있습니다. 그런 다음 각 전략에 대해 값(0\$1100)을 입력합니다. 이러한 값은 각 전략의 가중치를 정의합니다. AWS SCT 는 이러한 가중치 값을 사용하여 각 규칙이 배포 및 정렬 키 선택에 미치는 영향을 정의합니다. 기본값은 AWS 마이그레이션 모범 사례를 기반으로 합니다.
**Find small tables** 전략에서 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 정의합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
+ 전략 세부 정보를 구성합니다.
각 최적화 전략의 가중치를 정의하는 것 외에 최적화 설정도 구성할 수 있습니다. 이 작업을 수행하려면 **Conversion optimization**을 선택합니다.
+ **Sort key columns limit**에 정렬 키의 최대 열 수를 입력합니다.
+ **스큐된 임계값**에 열에 대해 스큐된 값의 백분율(0\$1100)을 입력합니다.는 배포 키의 후보 목록에서 스큐 값이 임계값보다 큰 열을 AWS SCT 제외합니다.는 열의 스큐된 값을 총 레코드 수에 대한 가장 일반적인 값의 발생 횟수의 백분율 비율로 AWS SCT 정의합니다.
+ **Top N queries from the query history table**에 분석할 가장 자주 사용되는 쿼리의 수(1\$1100)를 입력합니다.
+ **Select statistics user**에서 쿼리 통계를 분석하려는 데이터베이스 사용자를 선택합니다.
또한 **Optimization strategies** 탭에서 **Find small tables** 전략을 위한 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 간주합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
# 를 사용하여 Snowflake 데이터 웨어하우스에 연결 AWS Schema Conversion Tool
AWS SCT 를 사용하여 스키마, 코드 객체 및 애플리케이션 코드를 Snowflake에서 Amazon Redshift로 변환할 수 있습니다.
## Snowflake를 소스 데이터베이스로 사용할 수 있는 권한
권한이 있는 역할을 생성하고 `SECURITYADMIN` 역할 및 `SECURITYADMIN` 세션 컨텍스트를 사용하여 이 역할에 사용자 이름을 부여할 수 있습니다.
다음 예제에서는 최소 권한을 생성하여 `min_privs` 사용자에게 부여합니다.
```
create role role_name;
grant role role_name to role sysadmin;
grant usage on database db_name to role role_name;
grant usage on schema db_name.schema_name to role role_name;
grant usage on warehouse datawarehouse_name to role role_name;
grant monitor on database db_name to role role_name;
grant monitor on warehouse datawarehouse_name to role role_name;
grant select on all tables in schema db_name.schema_name to role role_name;
grant select on future tables in schema db_name.schema_name to role role_name;
grant select on all views in schema db_name.schema_name to role role_name;
grant select on future views in schema db_name.schema_name to role role_name;
grant select on all external tables in schema db_name.schema_name to role role_name;
grant select on future external tables in schema db_name.schema_name to role role_name;
grant usage on all sequences in schema db_name.schema_name to role role_name;
grant usage on future sequences in schema db_name.schema_name to role role_name;
grant usage on all functions in schema db_name.schema_name to role role_name;
grant usage on future functions in schema db_name.schema_name to role role_name;
grant usage on all procedures in schema db_name.schema_name to role role_name;
grant usage on future procedures in schema db_name.schema_name to role role_name;
create user min_privs password='real_user_password'
DEFAULT_ROLE = role_name DEFAULT_WAREHOUSE = 'datawarehouse_name';
grant role role_name to user min_privs;
```
이전 예제에서 다음과 같이 자리 표시자를 바꿉니다.
+ *`role_name`*을 읽기 전용 권한이 있는 역할의 이름으로 바꿉니다.
+ `db_name`을 소스 데이터베이스의 이름으로 바꿉니다.
+ `schema_name`을 소스 스키마의 이름으로 바꿉니다.
+ *`datawarehousename`*을 필수 데이터 웨어하우스의 이름으로 바꿉니다.
+ 최소 권한을 가진 사용자 이름으로 `min_privs`를 바꿉니다.
`DEFAULT_ROLE` 및 `DEFAULT_WAREHOUSE` 파라미터는 키를 구분합니다.
## Amazon S3에 대한 보안 액세스 구성
Amazon S3 버킷의 보안 및 액세스 관리 정책을 통해 Snowflake는 S3 버킷에 액세스하고, S3 버킷에서 데이터를 읽고, S3 버킷에 데이터를 쓸 수 있습니다. Snowflake `STORAGE INTEGRATION` 객체 유형을 사용하여 프라이빗 Amazon S3 버킷에 대한 보안 액세스를 구성할 수 있습니다. Snowflake 스토리지 통합 객체는 Snowflake ID 및 액세스 관리 엔터티에 인증 책임을 위임합니다.
자세한 내용은 Snowflake 설명서에서 [Amazon S3에 액세스하기 위한 Snowflake 스토리지 통합 구성](https://docs.snowflake.com/en/user-guide/data-load-s3-config-storage-integration.html)을 참조하세요.
## Snowflake에 소스로 연결
다음 절차에 따라 AWS Schema Conversion Tool을 사용하여 소스 데이터베이스에 연결합니다.
**Snowflake 소스 데이터베이스에 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **Snowflake**를 선택한 후 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 데이터베이스의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. 에서 데이터베이스 자격 증명을 사용하거나 수동으로 AWS Secrets Manager 입력합니다.
+ Secrets Manager의 데이터베이스 보안 인증 정보를 사용하려면 다음 지침을 따릅니다.
1. **AWS Secret**에서 보안 암호의 이름을 선택합니다.
1. **Populate**를 선택하여 Secrets Manager에서 데이터베이스 연결 대화 상자에 있는 모든 값을 자동으로 채웁니다.
Secrets Manager의 데이터베이스 보안 인증 사용에 대한 자세한 내용은 [AWS Secrets Manager 에서 구성 AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md) 섹션을 참조하세요.
+ Snowflake 소스 데이터 웨어하우스 연결 정보를 수동으로 입력하려면 다음 지침을 사용합니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.Snowflake.html)
1. **연결 테스트를** 선택하여가 소스 데이터베이스에 연결할 AWS SCT 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 데이터베이스에 연결합니다.
## Snowflake를 소스로 사용 시 적용되는 제한 사항
다음은 Snowflake를 소스로 사용할 때의 제한 사항입니다 AWS SCT.
+ 객체 식별자는 객체 유형과 상위 객체의 컨텍스트 내에서 고유해야 합니다.
**Database**
스키마 식별자는 데이터베이스 내에서 고유해야 합니다.
**스키마**
테이블 및 보기와 같은 객체 식별자는 스키마 내에서 고유해야 합니다.
**테이블/보기**
열 식별자는 테이블 내에서 고유해야 합니다.
+ 대형(large) 및 배수(xlarge) 클러스터 노드 유형에 대한 최대 테이블 수는 9,900개입니다. 8xlarge 클러스터 노드 유형에 대한 최대 테이블 수는 100,000개입니다. 이 제한에는 임시 테이블이 포함되며, 모두 쿼리 처리 또는 시스템 유지 관리 중에 Amazon Redshift에서 사용자 정의하거나 생성할 수 있습니다. 자세한 내용은 *Amazon Redshift 클러스터 관리 안내서*의 [Amazon Redshift 할당량](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) 섹션을 참조하세요.
+ 저장 프로시저의 경우 입력 및 출력 인수의 최대 개수는 32개입니다.
## Snowflake의 소스 데이터 형식
아래에서를 사용할 때 지원되는 Snowflake 소스 데이터 유형 AWS SCT 과 Amazon Redshift 대상에 대한 기본 매핑을 확인할 수 있습니다.
| Snowflake 데이터 형식 | Amazon Redshift 데이터 형식 |
| --- | --- |
| NUMBER | NUMERIC(38) |
| NUMBER(p) | If p is =< 4, then SMALLINT If p is => 5 and =< 9, then INTEGER If p is => 10 and =< 18, then BIGINT If p is => 19 then NUMERIC(p) |
| NUMBER(p, 0) | If p is =< 4, then SMALLINT If p is => 5 and =< 9, then INTEGER If p is => 10 and =< 18, then BIGINT If p is => 19 then: NUMERIC(p,0) |
| NUMBER(p, s) | If p is => 1 and =< 38, and if s is => 1 and =< 37, then NUMERIC(p,s) |
| FLOAT | FLOAT |
| TEXT 최대 16,777,216바이트의 유니코드 문자, 문자당 최대 4바이트 | VARCHAR(MAX) |
| TEXT(p) 최대 65,535바이트의 유니코드 문자, 문자당 최대 4바이트 | If p is =< 65,535 then, VARCHAR(p) |
| TEXT(p) 최대 16,777,216바이트의 유니코드 문자, 문자당 최대 4바이트 | If p is => 65,535 and =< 16,777,216 then, VARCHAR(MAX) |
| BINARY 최대 8,388,608바이트의 싱글 바이트 문자, 문자당 1바이트 | VARCHAR(MAX) |
| BINARY(p) 최대 65,535바이트의 싱글 바이트 문자, 문자당 1바이트 | VARCHAR(p) |
| BINARY(p) 최대 8,388,608바이트의 싱글 바이트 문자, 문자당 1바이트 | VARCHAR(MAX) |
| BOOLEAN | BOOLEAN |
| DATE | DATE |
| TIME 00:00:00에서 23:59:59.999999999 사이의 시간 값 | VARCHAR(18) |
| TIME(f) 00:00:00에서 23:59:59.9(f) 사이의 시간 값 | VARCHAR(n) – 9 \$1 dt-attr-1 |
| TIMESTAMP\$1NTZ | TIMESTAMP |
| TIMESTAMP\$1TZ | TIMESTAMPTZ |
## Snowflake에서 Amazon Redshift로의 변환 설정
Snowflake에서 Amazon Redshift로의 변환 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Snowflake**를 선택한 다음 **Snowflake – Amazon Redshift**를 선택합니다.는 Snowflake에서 Amazon Redshift로의 변환에 사용할 수 있는 모든 설정을 AWS SCT 표시합니다.
의 Snowflake에서 Amazon Redshift로의 변환 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 대상 Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 최대 테이블 수를 설정합니다.
**대상 Amazon Redshift 클러스터의 최대 테이블 수에서** Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 테이블 수를 선택합니다.
Amazon Redshift에는 여러 클러스터 노드 유형에 사용하는 테이블을 제한하는 할당량이 있습니다. **자동**을 선택하면 노드 유형에 따라 대상 Amazon Redshift 클러스터에 적용할 테이블 수를 AWS SCT 결정합니다. 값을 수동으로 선택할 수도 있습니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [Amazon Redshift의 할당량 및 제한](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) 섹션을 참조하세요.
AWS SCT 는 Amazon Redshift 클러스터가 저장할 수 있는 것보다 많더라도 모든 소스 테이블을 변환합니다.는 변환된 코드를 프로젝트에 AWS SCT 저장하고 대상 데이터베이스에 적용하지 않습니다. 변환된 코드를 적용할 때 테이블의 Amazon Redshift 클러스터 할당량에 도달하면 AWS SCT 에서 경고 메시지가 표시됩니다. 또한 테이블 수가 한도에 도달할 때까지 대상 Amazon Redshift 클러스터에 테이블을 AWS SCT 적용합니다.
+ Amazon Redshift 테이블 열에 압축을 적용합니다. 이렇게 하려면 **Use compression encoding**을 선택합니다.
AWS SCT 는 기본 Amazon Redshift 알고리즘을 사용하여 열에 압축 인코딩을 자동으로 할당합니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [압축 인코딩](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)을 참조하세요.
기본적으로 Amazon Redshift는 정렬 및 배포 키로 정의된 열에 압축을 적용하지 않습니다. 이 동작을 변경하여 이러한 열에 압축을 적용할 수 있습니다. 이렇게 하려면 **Use compression encoding for KEY columns**를 선택합니다. **Use compression encoding** 옵션을 선택한 경우에만 이 옵션을 선택할 수 있습니다.
## Snowflake에서 Amazon Redshift로의 변환 최적화 설정
Snowflake에서 Amazon Redshift로의 변환 최적화 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Snowflake**를 선택한 다음 **Snowflake – Amazon Redshift**를 선택합니다. 왼쪽 창에서 **최적화 전략을** 선택합니다.는 Snowflake에서 Amazon Redshift로의 변환에 대한 변환 최적화 설정을 AWS SCT 표시합니다.
의 Snowflake에서 Amazon Redshift로의 변환 최적화 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 자동 테이블 최적화 작업을 수행합니다. 이 작업을 수행하려면 **Use Amazon Redshift automatic table tuning**을 선택합니다.
자동 테이블 최적화는 테이블 디자인을 자동으로 최적화하는 Amazon Redshift의 자체 조정 프로세스입니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [자동 테이블 최적화 작업](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)을 참조하세요.
자동 테이블 최적화만 사용하려면 **Initial key selection strategy**에서 **없음**을 선택합니다.
+ 전략을 사용하여 정렬 및 배포 키를 선택합니다.
Amazon Redshift 메타데이터, 통계 정보 또는 두 옵션을 모두 사용하여 정렬 및 배포 키를 선택할 수 있습니다. **Optimization strategies** 탭의 **Initial key selection strategy**에서 다음 옵션 중 하나를 선택합니다.
+ 메타데이터 사용, 통계 정보 무시
+ 메타데이터 무시, 통계 정보 사용
+ 메타데이터 및 통계 정보 사용
선택한 옵션에 따라 최적화 전략을 선택할 수 있습니다. 그런 다음 각 전략에 대해 값(0\$1100)을 입력합니다. 이러한 값은 각 전략의 가중치를 정의합니다. AWS SCT 는 이러한 가중치 값을 사용하여 각 규칙이 배포 및 정렬 키 선택에 미치는 영향을 정의합니다. 기본값은 AWS 마이그레이션 모범 사례를 기반으로 합니다.
**Find small tables** 전략에서 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 정의합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
+ 전략 세부 정보를 구성합니다.
각 최적화 전략의 가중치를 정의하는 것 외에 최적화 설정도 구성할 수 있습니다. 이 작업을 수행하려면 **Conversion optimization**을 선택합니다.
+ **Sort key columns limit**에 정렬 키의 최대 열 수를 입력합니다.
+ **스큐된 임계값**에 열에 대해 스큐된 값의 백분율(0\$1100)을 입력합니다.는 배포 키의 후보 목록에서 스큐 값이 임계값보다 큰 열을 AWS SCT 제외합니다.는 열의 스큐된 값을 총 레코드 수에 대한 가장 일반적인 값의 발생 횟수의 백분율 비율로 AWS SCT 정의합니다.
+ **Top N queries from the query history table**에 분석할 가장 자주 사용되는 쿼리의 수(1\$1100)를 입력합니다.
+ **Select statistics user**에서 쿼리 통계를 분석하려는 데이터베이스 사용자를 선택합니다.
또한 **Optimization strategies** 탭에서 **Find small tables** 전략을 위한 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 간주합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
# 를 사용하여 SQL Server Data Warehouse에 연결 AWS Schema Conversion Tool
AWS SCT 를 사용하여 스키마, 코드 객체 및 애플리케이션 코드를 Microsoft SQL Server DW에서 Amazon Redshift 또는 Amazon Redshift로 변환하고 조합하여 AWS Glue 사용할 수 있습니다.
## Microsoft SQL Server Data Warehouse를 소스로 사용할 수 있는 권한
Microsoft SQL Server 데이터 웨어하우스를 소스로 사용하기 위해 필요한 권한은 다음과 같습니다.
+ VIEW DEFINITION
+ VIEW DATABASE STATE
+ SELECT ON SCHEMA :: **
이전 예제에서 ** 자리 표시자를 소스 source\$1schema의 이름으로 바꿉니다.
변환하려는 스키마의 각 데이터베이스에 대해 권한 부여를 반복합니다.
또한 다음 권한을 부여하고 마스터 데이터베이스에서 권한 부여를 실행합니다.
+ VIEW SERVER STATE
## SQL Server Data Warehouse를 소스로 사용 시 적용되는 제한 사항
Microsoft SQL Server Parallel Data Warehouse(PDW)를 소스로 사용하는 것은 현재 지원되지 않습니다.
## SQL Server Data Warehouse에 소스로 연결
다음 절차에 따라 AWS Schema Conversion Tool을 사용하여 SQL Server Data Warehouse 소스 데이터베이스에 연결합니다.
**SQL Server Data Warehouse 소스 데이터베이스에 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **Microsoft SQL Server**를 선택한 후 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 데이터베이스의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. 에서 데이터베이스 자격 증명을 사용하거나 수동으로 AWS Secrets Manager 입력합니다.
+ Secrets Manager의 데이터베이스 보안 인증 정보를 사용하려면 다음 지침을 따릅니다.
1. **AWS Secret**에서 보안 암호의 이름을 선택합니다.
1. **Populate**를 선택하여 Secrets Manager에서 데이터베이스 연결 대화 상자에 있는 모든 값을 자동으로 채웁니다.
Secrets Manager의 데이터베이스 보안 인증 사용에 대한 자세한 내용은 [AWS Secrets Manager 에서 구성 AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md) 섹션을 참조하세요.
+ Microsoft SQL Server 소스 데이터 웨어하우스 연결 정보를 수동으로 입력하려면 다음 지침을 사용합니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServerDW.html)
1. **연결 테스트를** 선택하여가 소스 데이터베이스에 연결할 AWS SCT 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 데이터베이스에 연결합니다.
## SQL Server Data Warehouse에서 Amazon Redshift로의 변환 설정
SQL Server Data Warehouse에서 Amazon Redshift로의 변환 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Microsoft SQL Server**를 선택한 다음 **Microsoft SQL Server – Amazon Redshift**를 선택합니다.는 SQL Server Data Warehouse에서 Amazon Redshift로의 변환에 사용할 수 있는 모든 설정을 AWS SCT 표시합니다.
의 SQL Server Data Warehouse에서 Amazon Redshift로의 변환 설정에는 다음과 같은 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 대상 Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 최대 테이블 수를 설정합니다.
**대상 Amazon Redshift 클러스터의 최대 테이블 수에서** Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 테이블 수를 선택합니다.
Amazon Redshift에는 여러 클러스터 노드 유형에 사용하는 테이블을 제한하는 할당량이 있습니다. **자동**을 선택하면 노드 유형에 따라 대상 Amazon Redshift 클러스터에 적용할 테이블 수를 AWS SCT 결정합니다. 값을 수동으로 선택할 수도 있습니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [Amazon Redshift의 할당량 및 제한](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) 섹션을 참조하세요.
AWS SCT 는 Amazon Redshift 클러스터가 저장할 수 있는 것보다 많더라도 모든 소스 테이블을 변환합니다.는 변환된 코드를 프로젝트에 AWS SCT 저장하고 대상 데이터베이스에 적용하지 않습니다. 변환된 코드를 적용할 때 테이블의 Amazon Redshift 클러스터 할당량에 도달하면 AWS SCT 에서 경고 메시지가 표시됩니다. 또한 테이블 수가 한도에 도달할 때까지 대상 Amazon Redshift 클러스터에 테이블을 AWS SCT 적용합니다.
+ 소스 테이블의 파티션을 Amazon Redshift의 개별 테이블로 마이그레이션합니다. 이 작업을 수행하려면 **Use the UNION ALL view**를 선택하고 AWS SCT 가 단일 소스 테이블에 대해 생성할 수 있는 대상 테이블의 최대 수를 입력합니다.
Amazon Redshift는 테이블 파티셔닝을 지원하지 않습니다. 이 동작을 에뮬레이션하고 쿼리를 더 빠르게 실행하려면 소스 테이블의 각 파티션을 Amazon Redshift의 별도 테이블로 AWS SCT 마이그레이션할 수 있습니다. 그런 다음는 이러한 모든 테이블의 데이터가 포함된 뷰를 AWS SCT 생성합니다.
AWS SCT 는 소스 테이블의 파티션 수를 자동으로 결정합니다. 소스 테이블 파티셔닝 유형에 따라서는 이 숫자가 Amazon Redshift 클러스터에 적용할 수 있는 테이블의 할당량을 초과할 수 있습니다. 이 할당량에 도달하지 않으려면가 단일 소스 테이블의 파티션에 대해 생성할 AWS SCT 수 있는 최대 대상 테이블 수를 입력합니다. 기본 옵션은 368개 테이블이며, 이는 1년 중 366일 동안의 파티션과 `NO RANGE` 및 `UNKNOWN` 파티션에 대한 테이블 두 개를 나타냅니다.
+ Amazon Redshift 테이블 열에 압축을 적용합니다. 이렇게 하려면 **Use compression encoding**을 선택합니다.
AWS SCT 는 기본 Amazon Redshift 알고리즘을 사용하여 열에 압축 인코딩을 자동으로 할당합니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [압축 인코딩](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)을 참조하세요.
기본적으로 Amazon Redshift는 정렬 및 배포 키로 정의된 열에 압축을 적용하지 않습니다. 이 동작을 변경하여 이러한 열에 압축을 적용할 수 있습니다. 이렇게 하려면 **Use compression encoding for KEY columns**를 선택합니다. **Use compression encoding** 옵션을 선택한 경우에만 이 옵션을 선택할 수 있습니다.
## SQL Server Data Warehouse에서 Amazon Redshift로의 변환 최적화 설정
SQL Server Data Warehouse에서 Amazon Redshift로의 변환 최적화 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Microsoft SQL Server**를 선택한 다음 **Microsoft SQL Server – Amazon Redshift**를 선택합니다. 왼쪽 창에서 **최적화 전략을** 선택합니다. SQL Server Data Warehouse에서 Amazon Redshift로의 변환에 대한 변환 최적화 설정을 AWS SCT 표시합니다.
의 SQL Server Data Warehouse에서 Amazon Redshift로의 변환 최적화 설정에는 다음과 같은 옵션이 AWS SCT 포함됩니다.
+ 자동 테이블 최적화 작업을 수행합니다. 이 작업을 수행하려면 **Use Amazon Redshift automatic table tuning**을 선택합니다.
자동 테이블 최적화는 테이블 디자인을 자동으로 최적화하는 Amazon Redshift의 자체 조정 프로세스입니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [자동 테이블 최적화 작업](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)을 참조하세요.
자동 테이블 최적화만 사용하려면 **Initial key selection strategy**에서 **없음**을 선택합니다.
+ 전략을 사용하여 정렬 및 배포 키를 선택합니다.
Amazon Redshift 메타데이터, 통계 정보 또는 두 옵션을 모두 사용하여 정렬 및 배포 키를 선택할 수 있습니다. **Optimization strategies** 탭의 **Initial key selection strategy**에서 다음 옵션 중 하나를 선택합니다.
+ 메타데이터 사용, 통계 정보 무시
+ 메타데이터 무시, 통계 정보 사용
+ 메타데이터 및 통계 정보 사용
선택한 옵션에 따라 최적화 전략을 선택할 수 있습니다. 그런 다음 각 전략에 대해 값(0\$1100)을 입력합니다. 이러한 값은 각 전략의 가중치를 정의합니다. AWS SCT 는 이러한 가중치 값을 사용하여 각 규칙이 배포 및 정렬 키 선택에 미치는 영향을 정의합니다. 기본값은 AWS 마이그레이션 모범 사례를 기반으로 합니다.
**Find small tables** 전략에서 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 정의합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
+ 전략 세부 정보를 구성합니다.
각 최적화 전략의 가중치를 정의하는 것 외에 최적화 설정도 구성할 수 있습니다. 이 작업을 수행하려면 **Conversion optimization**을 선택합니다.
+ **Sort key columns limit**에 정렬 키의 최대 열 수를 입력합니다.
+ **스큐된 임계값**에 열에 대해 스큐된 값의 백분율(0\$1100)을 입력합니다.는 배포 키의 후보 목록에서 스큐 값이 임계값보다 큰 열을 AWS SCT 제외합니다.는 열의 스큐된 값을 총 레코드 수에 대한 가장 일반적인 값의 발생 횟수의 백분율 비율로 AWS SCT 정의합니다.
+ **Top N queries from the query history table**에 분석할 가장 자주 사용되는 쿼리의 수(1\$1100)를 입력합니다.
+ **Select statistics user**에서 쿼리 통계를 분석하려는 데이터베이스 사용자를 선택합니다.
또한 **Optimization strategies** 탭에서 **Find small tables** 전략을 위한 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 간주합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
# 를 사용하여 Teradata Data Warehouse에 연결 AWS Schema Conversion Tool
AWS SCT 를 사용하여 스키마, 코드 객체 및 애플리케이션 코드를 Teradata에서 Amazon Redshift 또는 Amazon Redshift로 변환하고 조합하여 AWS Glue 사용할 수 있습니다.
## Teradata를 소스로 사용할 수 있는 권한
Teradata를 소스로 사용하기 위해 필요한 권한은 다음과 같습니다.
+ SELECT ON DBC
+ SELECT ON SYSUDTLIB
+ SELECT ON SYSLIB
+ SELECT ON **
+ CREATE PROCEDURE ON **
이전 예제에서 ** 자리 표시자를 소스 데이터베이스의 이름으로 바꿉니다.
AWS SCT 는 소스 데이터베이스의 모든 절차에 대해 HELP PROCEDURE를 수행하려면 CREATE PROCEDURE 권한이 필요합니다. AWS SCT 는이 권한을 사용하여 소스 Teradata 데이터베이스에 새 객체를 생성하지 않습니다.
## Teradata에 소스로 연결
다음 절차에 따라 AWS Schema Conversion Tool을 사용하여 Teradata 소스 데이터베이스에 연결합니다.
**Teradata 소스 데이터베이스에 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **Teradata**를 선택한 후 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 데이터베이스의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. 에서 데이터베이스 자격 증명을 사용하거나 수동으로 AWS Secrets Manager 입력합니다.
+ Secrets Manager의 데이터베이스 보안 인증 정보를 사용하려면 다음 지침을 따릅니다.
1. **AWS Secret**에서 보안 암호의 이름을 선택합니다.
1. **Populate**를 선택하여 Secrets Manager에서 데이터베이스 연결 대화 상자에 있는 모든 값을 자동으로 채웁니다.
Secrets Manager의 데이터베이스 보안 인증 사용에 대한 자세한 내용은 [AWS Secrets Manager 에서 구성 AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md) 섹션을 참조하세요.
+ Teradata 소스 데이터베이스 연결 정보를 수동으로 입력하려면 다음 지침을 사용합니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.Teradata.html)
1. **연결 테스트를** 선택하여가 소스 데이터베이스에 연결할 AWS SCT 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 데이터베이스에 연결합니다.
### Teradata 소스에서 LDAP 인증 사용
Windows에서 Microsoft Active Directory를 실행하는 Teradata 사용자를 위한 Lightweight Directory Access Protocol(LDAP) 인증을 설정하려면 다음 절차를 사용합니다.
다음 절차에서 Active Directory 도메인은 `test.local.com`입니다. Windows 서버는 `DC`이며 기본 설정으로 구성되어 있습니다. 다음 스크립트는 `test_ldap` Active Directory 계정을 생성하며 이 계정은 `test_ldap` 암호를 사용합니다.
**Windows에서 Microsoft Active Directory를 실행하는 Teradata 사용자에 대한 LDAP 인증을 설정하려면**
1. `/opt/teradata/tdat/tdgss/site` 디렉터리에서 `TdgssUserConfigFile.xml` 파일을 편집합니다. LDAP 섹션을 다음과 같이 변경합니다.
```
AuthorizationSupported="no"
LdapServerName="DC.test.local.com"
LdapServerPort="389"
LdapServerRealm="test.local.com"
LdapSystemFQDN="dc= test, dc= local, dc=com"
LdapBaseFQDN="dc=test, dc=local, dc=com"
```
1. 다음과 같이 구성을 실행하여 변경 사항을 적용합니다.
```
#cd /opt/teradata/tdgss/bin
#./run_tdgssconfig
```
1. 다음 명령을 실행하여 구성을 테스트합니다.
```
# /opt/teradata/tdat/tdgss/14.10.03.01/bin/tdsbind -u test_ldap -w test_ldap
```
다음과 같이 출력됩니다
```
LdapGroupBaseFQDN: dc=Test, dc=local, dc=com
LdapUserBaseFQDN: dc=Test, dc=local, dc=com
LdapSystemFQDN: dc= test, dc= local, dc=com
LdapServerName: DC.test.local.com
LdapServerPort: 389
LdapServerRealm: test.local.com
LdapClientUseTls: no
LdapClientTlsReqCert: never
LdapClientMechanism: SASL/DIGEST-MD5
LdapServiceBindRequired: no
LdapClientTlsCRLCheck: none
LdapAllowUnsafeServerConnect: yes
UseLdapConfig: no
AuthorizationSupported: no
FQDN: CN=test, CN=Users, DC=Anthem, DC=local, DC=com
AuthUser: ldap://DC.test.local.com:389/CN=test1,CN=Users,DC=test,DC=local,DC=com
DatabaseName: test
Service: tdsbind
```
1. 다음 명령을 사용하여 TPA를 다시 시작합니다.
```
#tpareset -f "use updated TDGSSCONFIG GDO"
```
1. 다음과 같이 Active Directory와 동일한 사용자를 Teradata 데이터베이스에서 생성합니다.
```
CREATE USER test_ldap AS PERM=1000, PASSWORD=test_ldap;
GRANT LOGON ON ALL TO test WITH NULL PASSWORD;
```
Active Directory에서 LDAP 사용자의 사용자 암호를 변경하는 경우 LDAP 모드에서 Teradata에 연결하는 동안 이 새 암호를 지정합니다. DEFAULT 모드에서 LDAP 사용자 이름과 암호를 사용하여 Teradata에 연결합니다.
## 소스 Teradata 데이터 웨어하우스에서 통계 수집 구성
소스 Teradata 데이터 웨어하우스를 변환하려면 통계를 AWS SCT 사용하여 변환된 Amazon Redshift 데이터 웨어하우스를 최적화합니다. AWS SCT 에서 통계를 수집하거나 통계 파일을 업로드할 수 있습니다. 자세한 내용은 [통계 수집 또는 업로드](CHAP_Converting.DW.md#CHAP_Converting.DW.Statistics) 단원을 참조하십시오.
가 데이터 웨어하우스에서 통계를 AWS SCT 수집할 수 있도록 하려면 다음 사전 조건 작업을 완료합니다.
**Teradata 데이터 웨어하우스에서 통계를 수집하려면**
1. 다음 쿼리를 실행하여 데이터 웨어하우스의 모든 테이블에 대한 통계를 다시 수집합니다.
```
collect summary statistics on table_name;
```
이전 예제에서 *table\$1name*을 소스 테이블의 이름으로 바꿉니다. 변환하는 각 테이블에 대해 쿼리를 반복합니다.
1. 다음 쿼리를 실행하여 사용자가 데이터 웨어하우스를 변환하는 데 사용할 계정 문자열을 결정합니다.
```
select * from dbc.accountinfo where username ='user_name'
```
1. 이전 예제의 계정 문자열을 사용하여 특정 사용자에 대한 쿼리 로깅을 켭니다.
```
BEGIN QUERY LOGGING WITH OBJECTS, SQL ON ALL ACCOUNT=('$M$BUSI$S$D$H');
```
또는 모든 데이터베이스 사용자에 대해 쿼리 로깅을 켤 수도 있습니다.
```
BEGIN QUERY LOGGING WITH SQL, OBJECTS LIMIT SQLTEXT=0 ON ALL;
```
데이터 웨어하우스 통계 수집을 완료한 후에는 쿼리 로깅을 끕니다. 다음 코드 예제를 사용하여 이 작업을 수행할 수 있습니다.
```
end query logging with explain, objects, sql on all account=(' $M$BUSI$S$D$H');
```
## 소스 Teradata 데이터 웨어하우스에서 오프라인 모드로 통계 수집
Teradata 데이터 웨어하우스에서 통계 수집을 구성한 후 AWS SCT 프로젝트에서 통계를 수집할 수 있습니다. 또는 Basic Teradata Query(BTEQ) 스크립트를 사용하여 오프라인 모드로 통계를 수집할 수 있습니다. 그런 다음 수집된 통계가 포함된 파일을 AWS SCT 프로젝트에 업로드할 수 있습니다. 자세한 내용은 [통계 수집 또는 업로드](CHAP_Converting.DW.md#CHAP_Converting.DW.Statistics) 단원을 참조하십시오.
**오프라인 모드로 Teradata 데이터 웨어하우스에서 통계를 수집하려면**
1. 다음 콘텐츠가 포함된 `off-line_stats.bteq` 스크립트를 생성합니다.
```
.OS IF EXIST column-stats-tera.csv del /F column-stats-tera.csv
.OS IF EXIST table-stats-tera.csv del /F table-stats-tera.csv
.OS IF EXIST column-skew-script-tera.csv del /F column-skew-script-tera.csv
.OS IF EXIST column-skew-stats-tera.csv del /F column-skew-stats-tera.csv
.OS IF EXIST query-stats-tera.csv del /F query-stats-tera.csv
.LOGON your_teradata_server/your_login, your_password
.EXPORT REPORT FILE = table-stats-tera.csv
.SET TITLEDASHES OFF
.SET WIDTH 10000
SELECT
'"' || OREPLACE(COALESCE(c.DatabaseName, ''), '"', '""') || '";' ||
'"' || OREPLACE(COALESCE(c.TableName, ''), '"', '""') || '";' ||
'"' || TRIM(COALESCE(s.reference_count, '0')) || '";' ||
'"' || TRIM(COALESCE(CAST(p.RowCount AS BIGINT), '0')) || '";' ||
'"' || CAST(CAST(w.size_in_mb AS DECIMAL (38,1) FORMAT 'Z9.9') AS VARCHAR(38)) || '";' ||
'"' || TRIM(COALESCE(r.stat_fk_dep_count, '0')) || '";' ||
'"' || CAST(CAST(current_timestamp(0) as timestamp(0) format 'YYYY-MM-DDBHH:MI:SS') as VARCHAR(19)) || '"'
(TITLE '"database_name";"table_name";"reference_count";"row_count";"size_in_mb";"stat_fk_dep_count";"current_ts"')
FROM (select databasename, tablename
from DBC.tablesv
where tablekind IN ('T','O')
and databasename = 'your_database_name'
) c
left join
(select DatabaseName, TableName, max(RowCount) RowCount
from dbc.tableStatsv
group by 1,2)p
on p.databasename = c.databasename
and p.tablename = c.tablename
left join
(SELECT r.ChildDB as DatabaseName,
r.ChildTable as TableName,
COUNT(DISTINCT r.ParentTable) reference_count
FROM DBC.All_RI_ChildrenV r
GROUP BY r.ChildDB, r.ChildTable) s
on s.databasename = c.databasename
and s.tablename = c.tablename
left join
(SELECT r.ParentDB as DatabaseName,
r.ParentTable as TableName,
COUNT(DISTINCT r.ChildTable) stat_fk_dep_count
FROM DBC.All_RI_ParentsV r
GROUP BY r.ParentDB, r.ParentTable) r
on r.databasename = c.databasename
and r.tablename = c.tablename
left join
(select databasename, tablename,
sum(currentperm)/1024/1024 as size_in_mb
from dbc.TableSizeV
group by 1,2) w
on w.databasename = c.databasename
and w.tablename = c.tablename
WHERE COALESCE(r.stat_fk_dep_count,0) + COALESCE(CAST(p.RowCount AS BIGINT),0) + COALESCE(s.reference_count,0) > 0;
.EXPORT RESET
.EXPORT REPORT FILE = column-stats-tera.csv
.SET TITLEDASHES OFF
.SET WIDTH 10000
'"' || TRIM(COALESCE(CAST(t2.card AS BIGINT), '0')) || '";' ||
SELECT
'"' || OREPLACE(COALESCE(trim(tv.DatabaseName), ''), '"', '""') || '";' ||
'"' || OREPLACE(COALESCE(trim(tv.TableName), ''), '"', '""') || '";' ||
'"' || OREPLACE(COALESCE(trim(tv.columnname), ''), '"', '""') || '";' ||
'"' || TRIM(COALESCE(CAST(t2.card AS BIGINT), '0')) || '";' ||
'"' || CAST(current_timestamp AS VARCHAR(19)) || '"' (TITLE '"database_name";"table_name";"column_name";"cardinality";"current_ts"')
FROM dbc.columnsv tv
LEFT JOIN
(
SELECT
c.DatabaseName AS DATABASE_NAME,
c.TABLENAME AS TABLE_NAME,
c.ColumnName AS COLUMN_NAME,
c.UniqueValueCount AS CARD
FROM dbc.tablestatsv c
WHERE c.DatabaseName = 'your_database_name'
AND c.RowCount <> 0
) t2
ON tv.DATABASENAME = t2.DATABASE_NAME
AND tv.TABLENAME = t2.TABLE_NAME
AND tv.COLUMNNAME = t2.COLUMN_NAME
WHERE t2.card > 0;
.EXPORT RESET
.EXPORT REPORT FILE = column-skew-script-tera.csv
.SET TITLEDASHES OFF
.SET WIDTH 10000
SELECT
'SELECT CAST(''"' || TRIM(c.DatabaseName) || '";"' || TRIM(c.TABLENAME) || '";"' || TRIM(c.COLUMNNAME) || '";"'' ||
TRIM(CAST(COALESCE(MAX(cnt) * 1.0 / SUM(cnt), 0) AS NUMBER FORMAT ''9.9999'')) || ''";"'' ||
CAST(CURRENT_TIMESTAMP(0) AS VARCHAR(19)) || ''"'' AS VARCHAR(512))
AS """DATABASE_NAME"";""TABLE_NAME"";""COLUMN_NAME"";""SKEWED"";""CURRENT_TS"""
FROM(
SELECT COUNT(*) AS cnt
FROM "' || c.DATABASENAME || '"."' || c.TABLENAME ||
'" GROUP BY "' || c.COLUMNNAME || '") t' ||
CASE WHEN ROW_NUMBER() OVER(PARTITION BY c.DATABASENAME
ORDER BY c.TABLENAME DESC, c.COLUMNNAME DESC) <> 1
THEN ' UNION ALL'
ELSE ';' END (TITLE '--SKEWED--')
FROM dbc.columnsv c
INNER JOIN
(SELECT databasename, TABLENAME
FROM dbc.tablesv WHERE tablekind = 'T'
AND databasename = 'your_database_name') t
ON t.databasename = c.databasename
AND t.TABLENAME = c.TABLENAME
INNER JOIN
(SELECT databasename, TABLENAME, columnname FROM dbc.indices GROUP BY 1,2,3
WHERE TRANSLATE_CHK (databasename USING LATIN_TO_UNICODE) + TRANSLATE_CHK (TABLENAME USING LATIN_TO_UNICODE) + TRANSLATE_CHK (columnname USING LATIN_TO_UNICODE) = 0
) i
ON i.databasename = c.databasename
AND i.TABLENAME = c.TABLENAME
AND i.columnname = c.columnname
WHERE c.ColumnType NOT IN ('CO','JN','N','++','VA','UT','AN','XM','A1','BO')
ORDER BY c.TABLENAME, c.COLUMNNAME;
.EXPORT RESET
.EXPORT REPORT FILE = column-skew-stats-tera.csv
.SET TITLEDASHES OFF
.SET WIDTH 10000
.RUN FILE = column-skew-script-tera.csv
.EXPORT RESET
.EXPORT REPORT FILE = query-stats-tera.csv
.SET TITLEDASHES OFF
.SET WIDTH 32000
SELECT
'"' || RTRIM(CAST(SqlTextInfo AS VARCHAR(31900)), ';') || '";"' ||
TRIM(QueryCount) || '";"' ||
TRIM(QueryId) || '";"' ||
TRIM(SqlRowNo) || '";"' ||
TRIM(QueryParts) || '";"' ||
CAST(CURRENT_TIMESTAMP(0) AS VARCHAR(19)) || '"'
(TITLE '"query_text";"query_count";"query_id";"sql_row_no";"query_parts";"current_ts"')
FROM
(
SELECT QueryId, SqlTextInfo, SqlRowNo, QueryParts, QueryCount,
SUM(QueryFirstRow) OVER (ORDER BY QueryCount DESC, QueryId ASC, SqlRowNo ASC
ROWS UNBOUNDED PRECEDING) AS topN
FROM
(SELECT QueryId, SqlTextInfo, SqlRowNo, QueryParts, QueryCount,
CASE WHEN
ROW_NUMBER() OVER (PARTITION BY QueryCount, SqlTextInfo ORDER BY QueryId, SqlRowNo) = 1 AND SqlRowNo = 1
THEN 1 ELSE 0 END AS QueryFirstRow
FROM (
SELECT q.QueryId, q.SqlTextInfo, q.SqlRowNo,
MAX(q.SqlRowNo) OVER (PARTITION BY q.QueryId) QueryParts,
COUNT(q.SqlTextInfo) OVER (PARTITION BY q.SqlTextInfo) QueryCount
FROM DBC.dbqlsqltbl q
INNER JOIN
(
SELECT QueryId
FROM DBC.DBQLogTbl t
WHERE TRIM(t.StatementType) IN ('SELECT')
AND TRIM(t.AbortFlag) = '' AND t.ERRORCODE = 0
AND (CASE WHEN 'All users' IN ('All users') THEN 'All users' ELSE TRIM(t.USERNAME) END) IN ('All users') --user_name list
AND t.StartTime > CURRENT_TIMESTAMP - INTERVAL '30' DAY
GROUP BY 1
) t
ON q.QueryId = t.QueryId
INNER JOIN
(
SELECT QueryId
FROM DBC.QryLogObjectsV
WHERE ObjectDatabaseName = 'your_database_name'
AND ObjectType = 'Tab'
AND CollectTimeStamp > CURRENT_TIMESTAMP - INTERVAL '30' DAY
GROUP BY 1
) r
ON r.QueryId = t.QueryId
WHERE q.CollectTimeStamp > CURRENT_TIMESTAMP - INTERVAL '30' DAY
) t
) t
WHERE SqlTextInfo NOT LIKE '%";"%'
) q
WHERE
QueryParts >=1
AND topN <= 50
ORDER BY QueryCount DESC, QueryId, SqlRowNo
QUALIFY COUNT(QueryId) OVER (PARTITION BY QueryId) = QueryParts;
.EXPORT RESET
.LOGOFF
.QUIT
```
1. 이전 단계에서 생성한 BTEQ 스크립트를 실행하는 `td_run_bteq.bat` 파일을 생성합니다. 다음 내용을 이 파일에 사용합니다.
```
@echo off > off-line_stats1.bteq & setLocal enableDELAYedexpansion
@echo off > off-line_stats2.bteq & setLocal enableDELAYedexpansion
set old1=your_teradata_server
set new1=%1
set old2=your_login
set new2=%2
set old3=your_database_name
set new3=%3
set old4=your_password
set /p new4=Input %2 pass?
for /f "tokens=* delims= " %%a in (off-line_stats.bteq) do (
set str1=%%a
set str1=!str1:%old1%=%new1%!
>> off-line_stats1.bteq echo !str1!
)
for /f "tokens=* delims= " %%a in (off-line_stats1.bteq) do (
set str2=%%a
set str2=!str2:%old2%=%new2%!
>> off-line_stats2.bteq echo !str2!
)
type nul > off-line_stats1.bteq
for /f "tokens=* delims= " %%a in (off-line_stats2.bteq) do (
set str3=%%a
set str3=!str3:%old3%=%new3%!
>> off-line_stats1.bteq echo !str3!
)
type nul > off-line_stats2.bteq
for /f "tokens=* delims= " %%a in (off-line_stats1.bteq) do (
set str4=%%a
set str4=!str4:%old4%=%new4%!
>> off-line_stats2.bteq echo !str4!
)
del .\off-line_stats1.bteq
echo export starting...
bteq -c UTF8 < off-line_stats.bteq > metadata_export.log
pause
```
1. 이전 단계에서 생성한 배치 파일을 실행하는 `runme.bat` 파일을 생성합니다. 다음 내용을 이 파일에 사용합니다.
```
.\td_run_bteq.bat ServerName UserName DatabaseName
```
`runme.bat` 파일에서 *ServerName*, *UserName* 및 *DatabaseName*을 해당하는 값으로 바꿉니다.
그런 다음 `runme.bat` 파일을 실행합니다. Amazon Redshift로 변환하는 각 데이터 웨어하우스마다 이 단계를 반복합니다.
이 스크립트를 실행한 후 각 데이터베이스에 대한 통계가 포함된 파일 3개를 수신하게 됩니다. 이러한 파일을 AWS SCT 프로젝트에 업로드할 수 있습니다. 이 작업을 수행하려면 프로젝트의 왼쪽 패널에서 데이터 웨어하우스를 선택하고 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 엽니다. **Upload Statistics**를 선택합니다.
## Teradata에서 Amazon Redshift로의 변환 설정
Teradata를 Amazon Redshift로 변환 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Teradata**를 선택한 다음 **Teradata – Amazon Redshift**를 선택합니다.는 Teradata에서 Amazon Redshift로의 변환에 사용할 수 있는 모든 설정을 AWS SCT 표시합니다.
의 Teradata에서 Amazon Redshift로의 변환 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 대상 Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 최대 테이블 수를 설정합니다.
**대상 Amazon Redshift 클러스터의 최대 테이블 수에서** Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 테이블 수를 선택합니다.
Amazon Redshift에는 여러 클러스터 노드 유형에 사용하는 테이블을 제한하는 할당량이 있습니다. **자동**을 선택하면 노드 유형에 따라 대상 Amazon Redshift 클러스터에 적용할 테이블 수를 AWS SCT 결정합니다. 값을 수동으로 선택할 수도 있습니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [Amazon Redshift의 할당량 및 제한](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) 섹션을 참조하세요.
AWS SCT 는 Amazon Redshift 클러스터가 저장할 수 있는 것보다 많더라도 모든 소스 테이블을 변환합니다.는 변환된 코드를 프로젝트에 AWS SCT 저장하고 대상 데이터베이스에 적용하지 않습니다. 변환된 코드를 적용할 때 테이블의 Amazon Redshift 클러스터 할당량에 도달하면 AWS SCT 에서 경고 메시지가 표시됩니다. 또한 테이블 수가 한도에 도달할 때까지 대상 Amazon Redshift 클러스터에 테이블을 AWS SCT 적용합니다.
+ 소스 테이블의 파티션을 Amazon Redshift의 개별 테이블로 마이그레이션합니다. 이 작업을 수행하려면 **Use the UNION ALL view**를 선택하고 AWS SCT 가 단일 소스 테이블에 대해 생성할 수 있는 대상 테이블의 최대 수를 입력합니다.
Amazon Redshift는 테이블 파티셔닝을 지원하지 않습니다. 이 동작을 에뮬레이션하고 쿼리를 더 빠르게 실행하려면 소스 테이블의 각 파티션을 Amazon Redshift의 별도 테이블로 AWS SCT 마이그레이션할 수 있습니다. 그런 다음는 이러한 모든 테이블의 데이터가 포함된 뷰를 AWS SCT 생성합니다.
AWS SCT 는 소스 테이블의 파티션 수를 자동으로 결정합니다. 소스 테이블 파티셔닝 유형에 따라서는 이 숫자가 Amazon Redshift 클러스터에 적용할 수 있는 테이블의 할당량을 초과할 수 있습니다. 이 할당량에 도달하지 않으려면가 단일 소스 테이블의 파티션에 대해 생성할 AWS SCT 수 있는 최대 대상 테이블 수를 입력합니다. 기본 옵션은 368개 테이블이며, 이는 1년 중 366일 동안의 파티션과 `NO RANGE` 및 `UNKNOWN` 파티션에 대한 테이블 두 개를 나타냅니다.
+ Amazon Redshift 테이블 열에 압축을 적용합니다. 이렇게 하려면 **Use compression encoding**을 선택합니다.
AWS SCT 는 기본 Amazon Redshift 알고리즘을 사용하여 열에 압축 인코딩을 자동으로 할당합니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [압축 인코딩](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)을 참조하세요.
기본적으로 Amazon Redshift는 정렬 및 배포 키로 정의된 열에 압축을 적용하지 않습니다. 이 동작을 변경하여 이러한 열에 압축을 적용할 수 있습니다. 이렇게 하려면 **Use compression encoding for KEY columns**를 선택합니다. **Use compression encoding** 옵션을 선택한 경우에만 이 옵션을 선택할 수 있습니다.
+ 변환된 코드에서 `SELECT *` 문에 대해 명시적 열 목록을 사용하려면 **Use explicit column declaration**을 선택합니다.
+ Amazon Redshift 클러스터에서 기본 키와 고유 키의 동작을 에뮬레이션하려면 **Emulate the behavior of primary and unique keys**를 선택합니다.
Amazon Redshift는 고유 키와 기본 키를 적용하지 않으며 정보 제공 목적으로만 사용합니다. 코드에 이러한 제약 조건을 사용하는 경우가 변환된 코드에서 해당 동작을 AWS SCT 에뮬레이션하는지 확인합니다.
+ 대상 Amazon Redshift 테이블의 데이터 고유성을 보장합니다. 이렇게 하려면 **Emulate the behavior of SET tables**를 선택합니다.
Teradata는 `SET` 구문 요소를 기본 옵션으로 사용하여 테이블을 생성합니다. `SET` 테이블에는 중복된 행을 추가할 수 없습니다. 소스 코드에서 이 고유성 제약 조건을 사용하지 않는 경우에는 이 옵션을 끕니다. 이 경우, 변환된 코드는 더 빠르게 작동합니다.
소스 코드가 고유성 제약 조건으로 테이블에서 `SET` 옵션을 사용하는 경우 이 옵션을 켭니다. 이 경우는 변환된 코드의 `INSERT..SELECT` 문을 AWS SCT 다시 작성하여 소스 데이터베이스의 동작을 에뮬레이션합니다.
## Teradata에서 Amazon Redshift로의 변환 최적화 설정
Teradata에서 Amazon Redshift로의 변환 최적화 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Teradata**를 선택한 다음 **Teradata – Amazon Redshift**를 선택합니다. 왼쪽 창에서 **최적화 전략을** 선택합니다. Teradata에서 Amazon Redshift로의 변환에 대한 변환 최적화 설정을 AWS SCT 표시합니다.
의 Teradata에서 Amazon Redshift로의 변환 최적화 설정에는 다음과 같은 옵션이 AWS SCT 포함됩니다.
+ 자동 테이블 최적화 작업을 수행합니다. 이 작업을 수행하려면 **Use Amazon Redshift automatic table tuning**을 선택합니다.
자동 테이블 최적화는 테이블 디자인을 자동으로 최적화하는 Amazon Redshift의 자체 조정 프로세스입니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [자동 테이블 최적화 작업](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)을 참조하세요.
자동 테이블 최적화만 사용하려면 **Initial key selection strategy**에서 **없음**을 선택합니다.
+ 전략을 사용하여 정렬 및 배포 키를 선택합니다.
Amazon Redshift 메타데이터, 통계 정보 또는 두 옵션을 모두 사용하여 정렬 및 배포 키를 선택할 수 있습니다. **Optimization strategies** 탭의 **Initial key selection strategy**에서 다음 옵션 중 하나를 선택합니다.
+ 메타데이터 사용, 통계 정보 무시
+ 메타데이터 무시, 통계 정보 사용
+ 메타데이터 및 통계 정보 사용
선택한 옵션에 따라 최적화 전략을 선택할 수 있습니다. 그런 다음 각 전략에 대해 값(0\$1100)을 입력합니다. 이러한 값은 각 전략의 가중치를 정의합니다. AWS SCT 는 이러한 가중치 값을 사용하여 각 규칙이 배포 및 정렬 키 선택에 미치는 영향을 정의합니다. 기본값은 AWS 마이그레이션 모범 사례를 기반으로 합니다.
**Find small tables** 전략에서 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 정의합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
+ 전략 세부 정보를 구성합니다.
각 최적화 전략의 가중치를 정의하는 것 외에 최적화 설정도 구성할 수 있습니다. 이 작업을 수행하려면 **Conversion optimization**을 선택합니다.
+ **Sort key columns limit**에 정렬 키의 최대 열 수를 입력합니다.
+ **스큐된 임계값**에 열에 대해 스큐된 값의 백분율(0\$1100)을 입력합니다.는 배포 키의 후보 목록에서 스큐 값이 임계값보다 큰 열을 AWS SCT 제외합니다.는 열의 스큐된 값을 총 레코드 수에 대한 가장 일반적인 값의 발생 횟수의 백분율 비율로 AWS SCT 정의합니다.
+ **Top N queries from the query history table**에 분석할 가장 자주 사용되는 쿼리의 수(1\$1100)를 입력합니다.
+ **Select statistics user**에서 쿼리 통계를 분석하려는 데이터베이스 사용자를 선택합니다.
또한 **Optimization strategies** 탭에서 **Find small tables** 전략을 위한 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 간주합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
# AWS Schema Conversion Tool Vertica 데이터베이스에 연결
AWS SCT 를 사용하여 스키마, 코드 객체 및 애플리케이션 코드를 Vertica에서 Amazon Redshift로 변환할 수 있습니다.
## Vertica를 소스로 사용할 수 있는 권한
Vertica를 소스로 사용하기 위해 필요한 권한은 다음과 같습니다.
+ USAGE ON SCHEMA **
+ USAGE ON SCHEMA PUBLIC
+ SELECT ON ALL TABLES IN SCHEMA **
+ SELECT ON ALL SEQUENCES IN SCHEMA **
+ EXECUTE ON ALL FUNCTIONS IN SCHEMA **
+ EXECUTE ON PROCEDURE **
이전 예제에서 다음과 같이 자리 표시자를 바꿉니다.
+ *schema\$1name*을 소스 스키마의 이름으로 바꿉니다.
+ *procedure\$1name*을 소스 프로시저의 이름으로 바꿉니다. 변환하려는 각 프로시저에 대해 권한 부여를 반복합니다.
+ *procedure\$1signature*를 쉼표로 구분된 프로시저 인수 유형 목록으로 바꿉니다.
## Vertica에 소스로 연결
다음 절차에 따라 AWS Schema Conversion Tool을 사용하여 Vertica 소스 데이터베이스에 연결합니다.
**Vertica 소스 데이터베이스에 연결하려면**
1. 에서 **소스 추가**를 AWS Schema Conversion Tool선택합니다.
1. **Vertica**를 선택한 후 **다음**을 선택합니다.
**소스 추가** 대화 상자가 나타납니다.
1. **연결 이름**에 데이터베이스의 이름을 입력합니다. AWS SCT 는 왼쪽 패널의 트리에 이 이름을 표시합니다.
1. 에서 데이터베이스 자격 증명을 사용하거나 수동으로 AWS Secrets Manager 입력합니다.
+ Secrets Manager의 데이터베이스 보안 인증 정보를 사용하려면 다음 지침을 따릅니다.
1. **AWS Secret**에서 보안 암호의 이름을 선택합니다.
1. **Populate**를 선택하여 Secrets Manager에서 데이터베이스 연결 대화 상자에 있는 모든 값을 자동으로 채웁니다.
Secrets Manager의 데이터베이스 보안 인증 사용에 대한 자세한 내용은 [AWS Secrets Manager 에서 구성 AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md) 섹션을 참조하세요.
+ Vertica 소스 데이터베이스 연결 정보를 수동으로 입력하려면 다음 지침을 사용합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Source.Vertica.html)
1. **연결 테스트를** 선택하여가 소스 데이터베이스에 연결할 AWS SCT 수 있는지 확인합니다.
1. **연결**을 선택하여 소스 데이터베이스에 연결합니다.
## Vertica에서 Amazon Redshift로의 변환 설정
Vertica에서 Amazon Redshift로의 변환 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Vertica**를 선택한 다음 **Vertica – Amazon Redshift**를 선택합니다.는 Vertica에서 Amazon Redshift로의 변환에 사용 가능한 모든 설정을 AWS SCT 표시합니다.
의 Vertica에서 Amazon Redshift로의 변환 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 변환된 코드에서 작업 항목이 포함된 설명의 수를 제한합니다.
**선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석 추가에서** 작업 항목의 심각도를 선택합니다.는 선택한 심각도 이상의 작업 항목에 대해 변환된 코드에 주석을 AWS SCT 추가합니다.
예를 들어, 변환된 코드의 설명 수를 최소화하려면 **오류만**을 선택하세요. 변환된 코드의 모든 작업 항목에 대한 설명을 포함하려면 **모든 메시지**를 선택합니다.
+ 대상 Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 최대 테이블 수를 설정합니다.
**대상 Amazon Redshift 클러스터의 최대 테이블 수에서** Amazon Redshift 클러스터에 적용할 AWS SCT 수 있는 테이블 수를 선택합니다.
Amazon Redshift에는 여러 클러스터 노드 유형에 사용하는 테이블을 제한하는 할당량이 있습니다. **자동**을 선택하면 노드 유형에 따라 대상 Amazon Redshift 클러스터에 적용할 테이블 수를 AWS SCT 결정합니다. 값을 수동으로 선택할 수도 있습니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [Amazon Redshift의 할당량 및 제한](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) 섹션을 참조하세요.
AWS SCT 는 Amazon Redshift 클러스터가 저장할 수 있는 것보다 많더라도 모든 소스 테이블을 변환합니다.는 변환된 코드를 프로젝트에 AWS SCT 저장하고 대상 데이터베이스에 적용하지 않습니다. 변환된 코드를 적용할 때 테이블의 Amazon Redshift 클러스터 할당량에 도달하면 AWS SCT 에서 경고 메시지가 표시됩니다. 또한 테이블 수가 한도에 도달할 때까지 대상 Amazon Redshift 클러스터에 테이블을 AWS SCT 적용합니다.
+ 소스 테이블의 파티션을 Amazon Redshift의 개별 테이블로 마이그레이션합니다. 이 작업을 수행하려면 **Use the UNION ALL view**를 선택하고 AWS SCT 가 단일 소스 테이블에 대해 생성할 수 있는 대상 테이블의 최대 수를 입력합니다.
Amazon Redshift는 테이블 파티셔닝을 지원하지 않습니다. 이 동작을 에뮬레이션하고 쿼리를 더 빠르게 실행하려면 소스 테이블의 각 파티션을 Amazon Redshift의 별도 테이블로 AWS SCT 마이그레이션할 수 있습니다. 그런 다음는 이러한 모든 테이블의 데이터가 포함된 뷰를 AWS SCT 생성합니다.
AWS SCT 는 소스 테이블의 파티션 수를 자동으로 결정합니다. 소스 테이블 파티셔닝 유형에 따라서는 이 숫자가 Amazon Redshift 클러스터에 적용할 수 있는 테이블의 할당량을 초과할 수 있습니다. 이 할당량에 도달하지 않으려면가 단일 소스 테이블의 파티션에 대해 생성할 AWS SCT 수 있는 최대 대상 테이블 수를 입력합니다. 기본 옵션은 368개 테이블이며, 이는 1년 중 366일 동안의 파티션과 `NO RANGE` 및 `UNKNOWN` 파티션에 대한 테이블 두 개를 나타냅니다.
+ Amazon Redshift 테이블 열에 압축을 적용합니다. 이렇게 하려면 **Use compression encoding**을 선택합니다.
AWS SCT 는 기본 Amazon Redshift 알고리즘을 사용하여 열에 압축 인코딩을 자동으로 할당합니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [압축 인코딩](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)을 참조하세요.
기본적으로 Amazon Redshift는 정렬 및 배포 키로 정의된 열에 압축을 적용하지 않습니다. 이 동작을 변경하여 이러한 열에 압축을 적용할 수 있습니다. 이렇게 하려면 **Use compression encoding for KEY columns**를 선택합니다. **Use compression encoding** 옵션을 선택한 경우에만 이 옵션을 선택할 수 있습니다.
## Vertica에서 Amazon Redshift로의 변환 최적화 설정
Vertica에서 Amazon Redshift로의 변환 최적화 설정을 편집하려면에서 **설정을** 선택한 AWS SCT다음 **변환 설정을** 선택합니다. 상단 목록에서 **Vertica**를 선택한 다음 **Vertica – Amazon Redshift**를 선택합니다. 왼쪽 창에서 **최적화 전략을** 선택합니다. Vertica에서 Amazon Redshift로의 변환에 대한 변환 최적화 설정을 AWS SCT 표시합니다.
의 Vertica에서 Amazon Redshift로의 변환 최적화 설정에는 다음에 대한 옵션이 AWS SCT 포함됩니다.
+ 자동 테이블 최적화 작업을 수행합니다. 이 작업을 수행하려면 **Use Amazon Redshift automatic table tuning**을 선택합니다.
자동 테이블 최적화는 테이블 디자인을 자동으로 최적화하는 Amazon Redshift의 자체 조정 프로세스입니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [자동 테이블 최적화 작업](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)을 참조하세요.
자동 테이블 최적화만 사용하려면 **Initial key selection strategy**에서 **없음**을 선택합니다.
+ 전략을 사용하여 정렬 및 배포 키를 선택합니다.
Amazon Redshift 메타데이터, 통계 정보 또는 두 옵션을 모두 사용하여 정렬 및 배포 키를 선택할 수 있습니다. **Optimization strategies** 탭의 **Initial key selection strategy**에서 다음 옵션 중 하나를 선택합니다.
+ 메타데이터 사용, 통계 정보 무시
+ 메타데이터 무시, 통계 정보 사용
+ 메타데이터 및 통계 정보 사용
선택한 옵션에 따라 최적화 전략을 선택할 수 있습니다. 그런 다음 각 전략에 대해 값(0\$1100)을 입력합니다. 이러한 값은 각 전략의 가중치를 정의합니다. AWS SCT 는 이러한 가중치 값을 사용하여 각 규칙이 배포 및 정렬 키 선택에 미치는 영향을 정의합니다. 기본값은 AWS 마이그레이션 모범 사례를 기반으로 합니다.
**Find small tables** 전략에서 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 정의합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.
+ 전략 세부 정보를 구성합니다.
각 최적화 전략의 가중치를 정의하는 것 외에 최적화 설정도 구성할 수 있습니다. 이 작업을 수행하려면 **Conversion optimization**을 선택합니다.
+ **Sort key columns limit**에 정렬 키의 최대 열 수를 입력합니다.
+ **스큐된 임계값**에 열에 대해 스큐된 값의 백분율(0\$1100)을 입력합니다.는 배포 키의 후보 목록에서 스큐 값이 임계값보다 큰 열을 AWS SCT 제외합니다.는 열의 스큐된 값을 가장 일반적인 값의 발생 횟수와 총 레코드 수의 백분율 비율로 AWS SCT 정의합니다.
+ **Top N queries from the query history table**에 분석할 가장 자주 사용되는 쿼리의 수(1\$1100)를 입력합니다.
+ **Select statistics user**에서 쿼리 통계를 분석하려는 데이터베이스 사용자를 선택합니다.
또한 **Optimization strategies** 탭에서 **Find small tables** 전략을 위한 작은 테이블의 크기를 정의할 수 있습니다. **최소 테이블 행 수** 및 **최대 테이블 행 수**에 테이블의 최소 및 최대 행 수를 입력하여 작은 테이블로 간주합니다.는 작은 테이블에 `ALL` 배포 스타일을 AWS SCT 적용합니다. 이 경우 전체 테이블의 사본이 모든 노드에 배포됩니다.