` の形式が使用されます。
次の表で例を確認できます。
| 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 マネージドファイル (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 Real Application Clusters (RAC) One Node は、Oracle Database 11g Release 2 とともに導入された Oracle Database Enterprise Edition のオプションです。Amazon RDS for Oracle は RAC 機能をサポートしていません。可用性を高めるには Amazon RDS マルチ AZ を使用してください。
Amazon RDS のマルチ AZ 配置では、異なるアベイラビリティーゾーンに同期スタンバイレプリカが自動的にプロビジョニングされて維持されます。プライマリ DB インスタンスは、同期的にアベイラビリティーゾーン間でスタンバイレプリカにレプリケートされます。この機能により、データの冗長性が確保されて I/O のフリーズがなくなり、システムバックアップ時のレイテンシー急上昇が最小限に抑えられます。
+ Oracle Spatial は、Oracle データベースのストレージ、取得、更新、および spatial データコレクションのクエリを可能にする 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 以降が実行されていること。
+ インスタンスが Virtual Private Cloud (VPC) 内にあること。
+ インスタンスの DB インスタンスクラスが Oracle 機能をサポート可能であること。例えば、Oracle Spatial は、db.m1.small、db.t1.micro、db.t2.micro、または db.t2.small の DB インスタンスクラスではサポートされません。詳細については、「[DB インスタンスクラスの Oracle のサポート](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 機能を使用してください。
Amazon RDS のマルチ AZ 配置では、異なるアベイラビリティーゾーンに同期スタンバイレプリカが自動的にプロビジョニングされて維持されます。プライマリ 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 から Amazon RDS for Oracle の変換では、DB リンクがサポートされます。データベースリンクは、別のデータベースのオブジェクトにアクセスできるようにする、1 つのデータベース内のスキーマオブジェクトです。もう 1 つのデータベースは 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 統合監査がサポートされています。
+ 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**] を選択し、その後 [**Next**] (次へ) を選択します。
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] にデータベースの名前を入力します。この名前が AWS SCT の左側のパネルのツリーに表示されます。
1. からデータベース認証情報を使用する AWS Secrets Manager か、手動で入力します。
+ Secrets Manager のデータベース認証情報を使用するには、以下の手順に従ってください。
1. [**AWS シークレット**] で、シークレットの名前を選択します。
1. [**入力**] を選択すると、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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.PostgreSQL.html)
1. **接続のテスト**を選択して、 がソースデータベースに接続 AWS SCT できることを確認します。
1. [**Connect**] (接続) を選択して、ソースデータベースに接続します。
## 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 または 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) への接続
以下の手順を使用して、SAP ASE ソースデータベースを AWS Schema Conversion Toolに接続します。
**SAP ASE ソースデータベースに接続するには**
1. で AWS Schema Conversion Tool、**ソースの追加**を選択します。
1. [**SAP ASE**] を選択し、その後 [**Next**] (次へ) を選択します。
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] にデータベースの名前を入力します。この名前が AWS SCT の左側のパネルのツリーに表示されます。
1. からデータベース認証情報を使用する AWS Secrets Manager か、手動で入力します。
+ Secrets Manager のデータベース認証情報を使用するには、以下の手順に従ってください。
1. [**AWS シークレット**] で、シークレットの名前を選択します。
1. [**入力**] を選択すると、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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.SAP.html)
1. **接続のテスト**を選択して、 がソースデータベースに接続 AWS SCT できることを確認します。
1. [**Connect**] (接続) を選択して、ソースデータベースに接続します。
## 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 または 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 互換)]** を選択します。 AWS SCT に、SAP ASE から PostgreSQL への変換に使用できるすべての設定が表示されます。
の SAP ASE から MySQL への変換設定には、以下のオプション AWS SCT が含まれています。
+ 変換されたコード内のアクション項目に関するコメントの数を制限する。
選択した**重要度以上のアクション項目の変換されたコードにコメントを追加する で**、アクション項目の重要度を選択します。 は、選択した重要度以上のアクション項目の変換されたコードにコメント AWS SCT を追加します。
たとえば、変換したコード内のコメントの数を最小限に抑えるには、[**エラーのみ**] を選択します。変換したコードのすべてのアクション項目にコメントを含めるには、[**すべてのメッセージ**] を選択します。
+ 変換後のコードでソースデータベースオブジェクトの正確な名前を使用する。
デフォルトでは、 はデータベースオブジェクト、変数、およびパラメータの名前を小文字 AWS SCT に変換します。これらの名前を元の大文字と小文字を区別しないでおくには、[**ソースデータベースオブジェクト名の大文字と小文字を区別する**] を選択します。ソース 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 互換)]** を選択します。 AWS SCT に、SAP ASE から PostgreSQL への変換に使用できるすべての設定が表示されます。
の SAP ASE から PostgreSQL への変換設定には、以下のオプション AWS SCT が含まれています。
+ 変換されたコード内のアクション項目に関するコメントの数を制限する。
選択した**重要度以上のアクション項目の変換されたコードにコメントを追加する で**、アクション項目の重要度を選択します。 は、選択した重要度以上のアクション項目の変換されたコードにコメント AWS SCT を追加します。
たとえば、変換したコード内のコメントの数を最小限に抑えるには、[**エラーのみ**] を選択します。変換したコードのすべてのアクション項目にコメントを含めるには、[**すべてのメッセージ**] を選択します。
+ 変換されるコード内のスキーマ名に使用するテンプレートを定義する。[**スキーマ名生成テンプレート**] では、次のオプションのいずれかを選択します。
+ [****] – PostgreSQL のスキーマ名として SAP ASE データベース名を使用します。
+ [****] – PostgreSQL のスキーマ名として SAP ASE スキーマ名を使用します。
+ [**\$1**] – SAP ASE データベースとスキーマ名の組み合わせを PostgreSQL のスキーマ名として使用します。
+ 変換後のコードでソースデータベースオブジェクトの正確な名前を使用する。
デフォルトでは、 はデータベースオブジェクト、変数、およびパラメータの名前を小文字 AWS SCT に変換します。これらの名前を元の大文字と小文字を区別しないでおくには、[**ソースデータベースオブジェクト名の大文字と小文字を区別する**] を選択します。ソース SAP ASE データベースサーバーで大文字と小文字を区別するオブジェクト名を使用する場合は、このオプションを選択してください。
大文字と小文字を区別するオペレーションでは、データベースオブジェクト名の小文字への変換を回避 AWS SCT できます。そのためには、[**大文字と小文字を区別する操作では小文字へのキャストを避ける**] を選択します。
+ 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 Server の使用をサポートしていません。
以下に示すように、 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` 権限により、パブリックアクセス権を持つユーザーはオブジェクト定義を表示できます。 は、SQL Server Enterprise Edition `VIEW DATABASE STATE` の機能をチェックする権限 AWS SCT を使用します。
スキーマを変換する、各データベースの付与を繰り返します。
さらに、`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 認証モードと混合モードの 2 つのアクセスモードがあります。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 認証情報は、Windows 以外のオペレーティングシステムから SQL Server に接続するときには自動的に指定されません。このような場合、アプリケーションは代わりに 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 のインストール先パスを指す 2 つの変数を宣言します。
`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` の場所です。
+ `sqljdbc_auth.dll` を、JDK/JRE が実行されているフォルダにコピーします。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) を実行している場合は、オペレーティングシステムが x64 バージョンであっても、x86 フォルダの sqljdbc\$1auth.dll ファイルを使用します。64 ビットの JVM を x64 プロセッサで実行している場合は、x64 フォルダの sqljdbc\$1auth.dll ファイルを使用します。
SQL Server データベースに接続するときは、[**Windows Authentication**] (Windows 認証) または [**SQL Server Authentication**] (SQL Server 認証) のどちらかを [**Authentication**] (認証) オプションで選択できます。
## ソースとしての SQL Server への接続
以下の手順を使用して、Microsoft SQL Server ソースデータベースを AWS Schema Conversion Toolに接続します。
**Microsoft SQL Server ソースデータベースに接続するには**
1. で AWS Schema Conversion Tool、**ソースの追加** を選択します。
1. [**Microsoft SQL Server**]、次に [**Next**] (次へ) を選択します。
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] にデータベースの名前を入力します。この名前が AWS SCT の左側のパネルのツリーに表示されます。
1. からデータベース認証情報を使用する AWS Secrets Manager か、手動で入力します。
+ Secrets Manager のデータベース認証情報を使用するには、以下の手順に従ってください。
1. [**AWS シークレット**] で、シークレットの名前を選択します。
1. [**入力**] を選択すると、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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServer.html)
1. **接続のテスト**を選択して、 がソースデータベースに接続 AWS SCT できることを確認します。
1. [**Connect**] (接続) を選択して、ソースデータベースに接続します。
# 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* を安全なパスワードに置き換えます。
バージョン 5.7 以前の MySQL データベースをターゲットとして使用する場合は、次のコマンドを実行します。MySQL データベースバージョン 8.0 以降では、このコマンドは廃止されました。
```
GRANT SELECT ON mysql.proc TO 'user_name';
```
Amazon RDS for MySQL または 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 データベースがテーブル`EXEC`に の出力を保存できるようにするには。 は一時テーブルと、この機能をエミュレートするための追加の手順 AWS SCT を作成します。このエミュレーションを使用するには、[**オープンデータセットを処理するための追加ルーチンを作成する**] を選択します。
## 移行に関する考慮事項
SQL Server スキーマを MySQL に移行する際は以下の点を考慮してください。
+ MySQL は `MERGE` ステートメントをサポートしていません。ただし、 は `INSERT ON DUPLICATE KEY`句と `MERGE`ステートメントを使用して、変換中に `UPDATE FROM and DELETE FROM`ステートメントをエミュレート AWS SCT できます。
`INSERT ON DUPLICATE KEY` を使用して正しくエミュレーションするために、一意の制約またはプライマリキーがターゲット MySQL データベースで存在することを確認してください。
+ `GOTO` ステートメントとラベルを使用して、ステートメントを実行する順序を変更できます。`GOTO` ステートメントに続くすべての Transact-SQL ステートメントはスキップされ、ラベルで処理が継続されます。`GOTO` ステートメントとラベルは、プロシージャ、バッチ、またはステートメント ブロック内のどこでも使用できます。`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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServer.ToMySQL.html)
+ MySQL は、複数ステートメントのテーブル値関数をサポートしていません。 は、一時テーブルを作成し、これらの一時テーブルを使用するようにステートメントを書き換えることで、変換中にテーブル値関数を AWS SCT シミュレートします。
# を使用した SQL Server から PostgreSQL への移行 AWS Schema Conversion Tool
AWS SCTでは、SQL サーバーから PostgreSQL への拡張パックを使用できます。この拡張パックは、変換された PostgreSQL コード内の SQL Server データベース関数をエミュレートします。SQL Server から PostgreSQL への拡張パックを使用すると、SQL Server エージェントと SQL Server データベースメールをエミュレートできます。拡張パックの詳細については、「[での拡張パックの使用 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 データベースメールをエミュレートする](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 は、一時テーブルと、この機能をエミュレートする追加のプロシージャを作成します。このエミュレーションを使用するには、[**オープンデータセットを処理するための追加ルーチンを作成する**] を選択します。
+ 変換されるコード内のスキーマ名に使用するテンプレートを定義する。[**スキーマ名生成テンプレート**] では、次のオプションのいずれかを選択します。
+ [****] – SQL Server のデータベース名を PostgreSQL のスキーマ名として使用する。
+ **** PostgreSQL のスキーマ名として SQL サーバのスキーマ名を使用します。
+ [**\$1**] – SQL Server データベースとスキーマ名の組み合わせを PostgreSQL のスキーマ名として使用します。
+ ソースオブジェクト名の大文字と小文字を維持する。
オブジェクト名が小文字に変換されないようにするには、**[大文字と小文字を区別する操作では小文字へのキャストを避ける]** を選択します。このオプションは、ターゲットデータベースで大文字と小文字の区別オプションをオンにした場合にのみ適用されます。
+ ソースデータベースのパラメータ名をそのまま使用する。
変換されたコード内のパラメータ名に二重引用符を追加するには、**[元のパラメータ名を保持]** を選択します。
## SQL Server パーティションから PostgreSQL バージョン 10 パーティションへの変換
Microsoft SQL Server データベースを Amazon Aurora PostgreSQL 互換エディション (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 を提供します。これを行うには、プロジェクトのプロパティで**一意のインデックス名を生成する**オプションを選択します。デフォルトでは、この機能は有効になっています。このオプションが有効になっている場合、一意のインデックス名が IX\$1table\$1name\$1index\$1name 形式を使用して作成されます。このオプションが無効になっている場合、インデックス名は変更されません。
+ GOTO ステートメントとラベルを使用して、ステートメントを実行する順序を変更できます。GOTO ステートメントに続くすべての Transact-SQL ステートメントはスキップされ、ラベルで処理が継続されます。GOTO ステートメントとラベルはプロシージャ、バッチ、またはステートメントブロックの任意の場所で使用できます。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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServer.ToPostgreSQL.html)
+ PostgreSQL は MERGE ステートメントをサポートしていません。 は次の方法で MERGE ステートメントの動作を AWS SCT エミュレートします。
+ INSERT の ON CONFLICT 句。
+ UPDATE FROM DML ステートメント (例: WHEN NOT MATCHED 句を指定しない MERGE)。
+ CURSOR (例: DELETE 句を指定した MERGE)、または複雑な 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 は、すべての有効なテキストおよび文字データ型で指定された式でパターンが最初に出現する開始位置を返します。パターンが見つからない場合は、ゼロを返します。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 は、1 つの 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\$1identifier、sp\$1verify\$1schedule\$1identifiers**
設定を確認する内部プロシージャ。
## PostgreSQL で SQL サーバーエージェントをエミュレートするプロシージャの構文
拡張パック内の `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 サーバーエージェントをエミュレートするためのユースケースの例
ソースデータベースコードが SQL Server エージェントを使用してジョブを実行する場合は、 の SQL Server から PostgreSQL への拡張パックを使用して AWS SCT 、このコードを PostgreSQL に変換できます。拡張機能パックは、 AWS Lambda 関数を使用して SQL Server エージェントの動作をエミュレートします。
新しい AWS Lambda 関数を作成するか、既存の関数を登録できます。
**新しい AWS Lambda 関数を作成するには**
1. ターゲットデータベースツリー AWS SCTで、コンテキスト (右クリック) メニューを開き、**拡張パックの適用**を選択し、**PostgreSQL** を選択します。
拡張パックウィザードが表示されます。
1. [**SQL Server エージェントエミュレーションサービス**] タブで、次の操作を行います。
+ ** AWS Lambda 関数の作成** を選択します。
+ [**データベースログイン**] には、ターゲットデータベースユーザーの名前を入力します。
+ [**データベースパスワード**] には、前のステップで入力したユーザー名のパスワードを入力します。
+ [**Python ライブラリフォルダ**] には、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) です。
次の例では、1 つのステップで構成されるシンプルなタスクを作成します。このタスクでは、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 データベースメールをエミュレートする
SQL Server データベース メールを使用すると、SQL Server データベース エンジンまたは Azure SQL Managed Instance からユーザーに電子メール メッセージを送信できます。これらのメールメッセージには、クエリ結果を含めたり、ネットワーク上の任意のリソースからのファイルを含めることができます。SQL Server データベースメールの詳細については、『[Microsoft 技術ドキュメント](https://docs.microsoft.com/en-us/sql/relational-databases/database-mail/database-mail?view=sql-server-ver15)』を参照してください。
PostgreSQL には SQL Server データベースメールに相当するものはありません。SQL Server データベースメール機能をエミュレートするために、 AWS SCT は拡張パックを作成します。この拡張パックは、 AWS Lambda と Amazon Simple Email Service (Amazon SES) を使用します。 AWS Lambda は、Amazon SES E メール送信サービスとやり取りするためのインターフェイスをユーザーに提供します。このインタラクションを設定するには、Lambda 関数の Amazon リソースネーム (ARN) を追加します。
新しいE メールアカウントの場合、次のコマンドを使用します。
```
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 を既存の E メールアカウントに追加するには、次のコマンドを使用します。
```
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 データベースメールの動作をエミュレートするために、 AWS SCT 拡張パックは次のテーブル、ビュー、およびプロシージャを使用します。
## PostgreSQL で SQL サーバーデータベースメールをエミュレートするテーブル
SQL Server データベースメールをエミュレートするために、拡張パックは次のテーブルを使用します。
**sysmail\$1account**
E メールアカウントに関する情報を格納します。
**sysmail\$1profile**
ユーザープロファイルに関する情報を格納します。
**sysmail\$1server**
E メールサーバに関する情報を格納します。
**sysmail\$1mailitems**
メールメッセージのリストを保存します。
**sysmail\$1attachments**
E メール添付ごとに 1 つの行が含まれます。
**sysmail\$1log**
E メール送信に関するサービス情報を格納します。
**sysmail\$1profileaccount**
ユーザープロファイルとE メールアカウントに関する情報を格納します。
## PostgreSQL で SQL サーバーデータベースメールをエミュレートするビュー
SQL Server データベースメールをエミュレートするために、 は互換性を確保するために PostgreSQL データベースに次のビュー AWS SCT を作成します。拡張パックではこれらのビューを使用しませんが、変換したコードでこれらのビューをクエリできます。
**sysmail\$1allitems**
すべてのメールのリストが含まれます。
**sysmail\$1faileditems**
送信できなかったメールのリストが含まれます。
**sysmail\$1sentitems**
送信済みメールのリストが含まれます。
**sysmail\$1unsentitems**
まだ送信されていないメールのリストが含まれます。
**sysmail\$1mailattachments**
添付ファイルのリストが含まれます。
## PostgreSQL で SQL サーバーデータベースメールをエミュレートするプロシージャ
SQL Server データベースメールをエミュレートするために、拡張パックは次の手順を使用します。
**sp\$1send\$1dbmail**
指定した受信者に E メールを送信します。
**sysmail\$1add\$1profile\$1sp**
新しいユーザープロファイルを作成します。
**sysmail\$1add\$1account\$1sp**
簡易メール転送プロトコル (SMTP) 認証情報などの情報を保存する新しいメールアカウントを作成します。
**sysmail\$1add\$1profileaccount\$1sp**
指定したユーザープロファイルにメールアカウントを追加します。
**sysmail\$1update\$1profile\$1sp**
説明、名前など、ユーザープロファイルの属性を変更します。
**sysmail\$1update\$1account\$1sp**
既存のメールアカウントの情報を変更します。
**sysmail\$1update\$1profileaccount\$1sp**
指定したユーザープロファイルのメールアカウント情報を更新します。
**sysmail\$1delete\$1profileaccount\$1sp**
指定したユーザープロファイルからメールアカウントを削除します。
**sysmail\$1delete\$1account\$1sp**
E メールアカウントを削除します。
**sysmail\$1delete\$1profile\$1sp**
ユーザープロファイルを削除します。
**sysmail\$1delete\$1mailitems\$1sp**
内部テーブルからメールを削除します。
**sysmail\$1help\$1profile\$1sp**
ユーザープロファイルに関する情報を表示します。
**sysmail\$1help\$1account\$1sp**
E メールアカウントに関する情報を表示します。
**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 データベースメールをエミュレートするプロシージャの構文
拡張パック内の `aws_sqlserver_ext.sp_send_dbmail` プロシージャは、`msdb.dbo.sp_send_dbmail` プロシージャをエミュレートします。SQL Server データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールのソース手順の詳細については、『[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 データベースメールをエミュレートするプロシージャを使用する場合の例
E メールを送信するには、次に示す `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'
);
```
次の例は、クエリ結果を E メールで送信する方法を示しています。
```
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 コードを使用して E メールを送信する方法を示しています。
```
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'
);
```
E メールを削除するには、次に示す `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
);
```
次の例は、最も古い E メールを削除する方法を示しています。
```
PERFORM sysmail_delete_mailitems_sp (
par_sent_before := '31.12.2015'
);
```
次の例は、送信できないすべての E メールを削除する方法を示しています。
```
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 データベースメールをエミュレートするためのユースケースの例
ソースデータベースコードが SQL Server データベースメールを使用して E メールを送信する場合は、 AWS SCT 拡張パックを使用してこのコードを PostgreSQL に変換できます。
**PostgreSQL データベースからE メールを送信するには**
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` 関数を使用して E メールを送信します。
```
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();
```
次の例では、特定のE メールアカウントに関する情報を表示します。
```
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 インスタンスを SQL Server Reporting Service (SSRS)、SQL Server Analysis Services (SSAS)、および SQL Server Integration Services (SSIS) と使用できます。
+ Amazon RDS は現在、SQL Server サービスブローカーまたは CREATE ENDPOINT コマンドを実行する必要がある追加の T-SQL エンドポイントをサポートしていません。
+ Amazon RDS には、リンクされたサーバーのサポートに制限があります。リンクされたサーバーを使用する SQL Server アプリケーションコードを変換する場合、 はアプリケーションコードを AWS SCT 変換します。ただし、変換されたコードを実行する前に、リンクサーバーを使用するオブジェクトの動作を確認してください。
+ 常にオンで使用されます。
+ AWS SCT 評価レポートには、変換のサーバーメトリクスが表示されます。SQL Server インスタンスに関するこれらのメトリクスには、次のようなものがあります。
+ データミラーリングを使用する。
+ SQL Server ログ配布を設定する。
+ フェイルオーバークラスターを使用する。
+ データベースメールを設定する。
+ 全文検索サービスを使用する。Amazon RDS for SQL Server の全文検索は制限されており、セマンティック検索はサポートされません。
+ Data Quality Service (DQS) をインストールする。Amazon RDS は DQS をサポートしていないため、SQL Server を Amazon EC2 インスタンスにインストールすることをお勧めします。
## ターゲットとして RDS for SQL を使用する場合の権限
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 データウェアハウスへの接続 AWS Schema Conversion Tool](CHAP_Source.SQLServerDW.md)
+ [を使用した Teradata データウェアハウスへの接続 AWS Schema Conversion Tool](CHAP_Source.Teradata.md)
+ [Vertica データベース AWS Schema Conversion Tool への の接続](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 への接続
以下の手順を使用して、Amazon Redshift ソースデータベースを AWS Schema Conversion Toolに接続します。
**Amazon Redshift ソースデータベースへの接続**
1. で AWS Schema Conversion Tool、**ソースの追加**を選択します。
1. [**Amazon Redshift**] を選択し、次に [**Next**] (次へ) を選択します。
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] にデータベースの名前を入力します。この名前が AWS SCT の左側のパネルのツリーに表示されます。
1. からデータベース認証情報を使用する AWS Secrets Manager か、手動で入力します。
+ Secrets Manager のデータベース認証情報を使用するには、以下の手順に従ってください。
1. [**AWS シークレット**] で、シークレットの名前を選択します。
1. [**入力**] を選択すると、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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.Redshift.html)
1. **接続のテスト**を選択して、 がソースデータベースに接続 AWS SCT できることを確認します。
1. [**Connect**] (接続) を選択して、ソースデータベースに接続します。
## 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 には、クラスターノードタイプの使用を制限するクォータがあります。**Auto** を選択した場合、 はノードタイプに応じてターゲット 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 クラスターのコピーを作成します。このコピーにソースデータを含めることも、空のクラスターを作成することもできます。
[**移行戦略**] では、[**コピーに移行**] を選択して、ソースクラスターのデータをターゲットクラスターに含めます。
[**移行戦略**] では、[**クリーンな状態に移行する**] を選択し、最適化の提案を確認します。これらの提案を受け入れたら、ソースデータをターゲットクラスターに移行します。
+ Amazon Redshift テーブルの列に圧縮を適用します。そのためには、[**圧縮エンコードを使用**] を選択します。
AWS SCT は、デフォルトの Amazon Redshift アルゴリズムを使用して、圧縮エンコーディングを列に自動的に割り当てます。詳細については、『*Amazon Redshift データベースデベロッパーガイド*』の「[圧縮エンコード](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)」を参照してください。
デフォルトでは、Amazon Redshift はソートキーと分散キーとして定義されている列に圧縮を適用しません。この動作を変更したり、これらの列に圧縮を適用したりできます。そのためには、[**KEY 列には圧縮エンコードを使用**] を選択します。このオプションは、[**圧縮エンコードを使用**] オプションを選択した場合にのみ選択できます。
+ 自動テーブル最適化を使用するには。
自動テーブル最適化は、テーブルの設計を自動的に最適化する Amazon Redshift の自己調整プロセスです。詳細については、『*Amazon Redshift データベース開発者ガイド*』の「[自動テーブル最適化の操作](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)」を参照してください。
自動テーブル最適化にのみ使用するには、左側のペインで [**最適化戦略**] を選択します。次に [**Amazon Redshift 自動テーブルチューニングを使用する**] を選択し、[**初期キー選択戦略**] で [**なし**] を選択します。
+ 戦略を使用してソートキーと分散キーを選択するには。
Amazon Redshift メタデータ、統計情報、またはこれらのオプションの両方を使用して、ソートキーと配布キーを選択できます。[**最適化戦略**] タブの [**初期キー選択戦略**] では、以下のいずれかのオプションを選択します。
+ メタデータを使用し、統計情報は無視する
+ メタデータを無視し、統計情報を使用する
+ メタデータと統計情報を使用する
選択したオプションに応じて、最適化戦略を選択できます。次に、各戦略について、値 (0～100) を入力します。これらの値は各戦略の重みを定義します。これらの重み値を使用して、 AWS SCT は各ルールがディストリビューションキーとソートキーの選択にどのように影響するかを定義します。デフォルト値は、 AWS 移行のベストプラクティスに基づいています。
[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブルの最小行数と最大行数を入力して、スモールテーブルとして定義します。 は`ALL`、分散スタイルをスモールテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
+ 戦略の詳細を設定するには。
各最適化戦略の重みを定義することに加えて、最適化設定を構成できます。そのためには、[**変換の最適化**] を選択します。
+ [**ソートキー列の制限**] には、ソートキーの列の最大数を入力します。
+ [**歪んだしきい値**] には、列の歪んだ値のパーセンテージ (0 ～ 100) を入力します。 AWS SCT は、歪み値がしきい値より大きい列を分散キーの候補リストから除外します。 AWS SCT では、列の歪んだ値をレコードの総数に対する最も一般的な値の出現回数の割合として定義します。
+ [**クエリ履歴テーブルの上位 N 件のクエリ**] には、分析対象として最も頻繁に使用されるクエリの数 (1 ～ 100) を入力します。
+ **[統計ユーザーを選択]** では、クエリ統計を分析するデータベースユーザーを選択します。
# 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**] を選択し、次に[**Next**] (次へ) を選択します。
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] にデータベースの名前を入力します。この名前が AWS SCT の左側のパネルのツリーに表示されます。
1. からデータベース認証情報を使用する AWS Secrets Manager か、手動で入力します。
+ Secrets Manager のデータベース認証情報を使用するには、以下の手順に従ってください。
1. [**AWS シークレット**] で、シークレットの名前を選択します。
1. [**入力**] を選択すると、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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.AzureSynapse.html)
1. [**Test Connection**] (接続のテスト) を選択して、 AWS SCT がソースデータベースに正常に接続できることを確認します。
1. [**Connect**] (接続) を選択して、ソースデータベースに接続します。
## 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 には、クラスターノードタイプの使用を制限するクォータがあります。**Auto** を選択した場合、 はノードタイプに応じてターゲット 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 の別のテーブルに移行するには。そのためには、[**UNION ALL ビューを使用する**] を選択し、 AWS SCT が 1 つのソーステーブルに対して作成できるターゲットテーブルの最大数を入力します。
Amazon Redshift は、テーブルのパーティションをサポートしていません。この動作をエミュレートしてクエリの実行を高速化するには、ソーステーブルの各パーティションを Amazon Redshift の別のテーブル AWS SCT に移行できます。次に、 はこれらのすべてのテーブルのデータを含むビュー AWS SCT を作成します。
AWS SCT は、ソーステーブル内のパーティションの数を自動的に決定します。ソーステーブルパーティショニングのタイプによっては、この数は Amazon Redshift クラスターに適用できるテーブルのクォータを超える場合があります。このクォータに達しないようにするには、単一のソーステーブルのパーティションに対して が作成 AWS SCT できるターゲットテーブルの最大数を入力します。デフォルトのオプションは 368 テーブルで、これは 1 年 366 日のパーティションと、`NO RANGE` および `UNKNOWN` パーティションの 2 つのテーブルを表します。
+ Amazon Redshift テーブルの列に圧縮を適用します。そのためには、[**圧縮エンコードを使用**] を選択します。
AWS SCT は、デフォルトの Amazon Redshift アルゴリズムを使用して、圧縮エンコーディングを列に自動的に割り当てます。詳細については、『*Amazon Redshift データベースデベロッパーガイド*』の「[圧縮エンコード](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)」を参照してください。
デフォルトでは、Amazon Redshift はソートキーと分散キーとして定義されている列に圧縮を適用しません。この動作を変更したり、これらの列に圧縮を適用したりできます。そのためには、[**KEY 列には圧縮エンコードを使用**] を選択します。このオプションは、[**圧縮エンコードを使用**] オプションを選択した場合にのみ選択できます。
## Azure Synapse Analytics から Amazon Redshift への変換最適化設定
Azure Synapse Analytics から Amazon Redshift への変換最適化設定を編集するには、**「 の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上のリストから [**Azure Synapse**] を選択し、次に [**Azure Synapse — Amazon Redshift**] を選択します。左側のペインで、**最適化 strategies**. AWS SCT displays conversion Optimization settings for Azure Synapse Analytics to Amazon Redshift conversion を選択します。
の Azure Synapse Analytics から Amazon Redshift への変換最適化設定 AWS SCT には、次のオプションが含まれています。
+ 自動テーブル最適化を使用するには。そのためには、[**Amazon Redshift の自動テーブルチューニングを使用する**] を選択します。
自動テーブル最適化は、テーブルの設計を自動的に最適化する Amazon Redshift の自己調整プロセスです。詳細については、『*Amazon Redshift データベース開発者ガイド*』の「[自動テーブル最適化の操作](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)」を参照してください。
自動テーブル最適化のみを利用するには、[**初期キー選択戦略**] で [**なし**] を選択します。
+ 戦略を使用してソートキーと分散キーを選択するには。
Amazon Redshift メタデータ、統計情報、またはこれらのオプションの両方を使用して、ソートキーと配布キーを選択できます。[**最適化戦略**] タブの [**初期キー選択戦略**] では、以下のいずれかのオプションを選択します。
+ メタデータを使用し、統計情報は無視する
+ メタデータを無視し、統計情報を使用する
+ メタデータと統計情報を使用する
選択したオプションに応じて、最適化戦略を選択できます。次に、各戦略について、値 (0～100) を入力します。これらの値は各戦略の重みを定義します。これらの重み値を使用して、 AWS SCT は各ルールがディストリビューションキーとソートキーの選択にどのように影響するかを定義します。デフォルト値は、 AWS 移行のベストプラクティスに基づいています。
[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブル内の最小行数と最大行数を入力して、スモールテーブルとして定義します。 は`ALL`、分散スタイルをスモールテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
+ 戦略の詳細を設定するには。
各最適化戦略の重みを定義することに加えて、最適化設定を構成できます。そのためには、[**変換の最適化**] を選択します。
+ [**ソートキー列の制限**] には、ソートキーの列の最大数を入力します。
+ **歪んだしきい値**には、列の歪んだ値の割合 (0～100) を入力します。分散キーの候補リストから、歪んだ値がしきい値より大きい列 AWS SCT を除外します。 は、列の歪んだ値を、レコードの合計数に対する最も一般的な値の出現回数の割合として AWS SCT 定義します。
+ [**クエリ履歴テーブルの上位 N 件のクエリ**] には、分析対象として最も頻繁に使用されるクエリの数 (1 ～ 100) を入力します。
+ [**統計ユーザーを選択**] では、クエリ統計を分析したいデータベースユーザーを選択します。
また、[**最適化戦略**」タブでは、[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブルの最小行数と最大行数を入力して、それを小さなテーブルと見なします。 は`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 が [**有効**] になっている場合は、このステップをスキップしてください。
1. [[サービスアカウント](https://console.cloud.google.com/iam-admin/serviceaccounts)] ページで、プロジェクトを選択し、[**サービスアカウントの作成**] を選択します。
1. [**サービスアカウント詳細**] ページで、[**サービスアカウント名**] にわかりやすい値を入力します。[**作成して続ける]** を選択します。[**このサービスアカウントにプロジェクトへのアクセス権を付与**] ページが開きます。
1. **[ロールの選択] で** [**BigQuery**] を選択し、次に [**BigQuery 管理者**] を選択します。
1. [**別のロールを追加**] を選択します。[**ロールの選択**] で [**クラウドストレージ**] を選択し、[**ストレージ管理者**] を選択します。
1. [**続ける**] を選択し、次に [**保存**] を選択します。
1. [[サービスアカウント](https://console.cloud.google.com/iam-admin/serviceaccounts)] ページで、作成したサービスアカウントを選択します。
1. [**キー**] を選択し、[**キーの追加**] で [**新しいキーの作成**] を選択します。
1. [**JSON**]、[**作成**] の順に選択します。プライベートキーを保存するフォルダを選択するか、ブラウザのダウンロード用のデフォルトフォルダを選択します。
BigQuery データウェアハウスからデータを抽出するには、 は Google Cloud Storage バケットフォルダ AWS SCT を使用します。データ移行を開始する前に、このバケットを作成してください。Google Cloud Storage バケットフォルダへのパスを [**ローカルタスクの作成**] ダイアログボックスに入力します。詳細については、「[ AWS SCT タスクの作成、実行、モニタリング](agents.md#agents.Tasks)」を参照してください。
## BigQuery へソースとして接続
以下の手順を使用して、ソースデータベースを AWS Schema Conversion Toolに接続します。
**BigQuery ソースデータウェアハウスに接続するには**
1. で AWS Schema Conversion Tool、**ソースの追加**を選択します。
1. [**BigQuery**] を選択し、[**次へ ] を選択します。**
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] に BigQuery プロジェクトの名前を入力します。 AWS SCT で、この名前が左側のパネルのツリーに表示されます。
1. [**キーパス**] にサービスアカウントのキーファイルへのパスを入力します。このファイルの作成の詳細については、「[BigQuery をソースとする場合の権限](#CHAP_Source.BigQuery.Permissions)」を参照してください。
1. **接続のテスト**を選択して、 がソース BigQuery プロジェクトに接続 AWS SCT できることを確認します。
1. [**接続**] を選択して、ソース BigQuery プロジェクトに接続します。
## BigQuery を のソースとして使用する場合の制限 AWS SCT
BigQuery をソースとして使用する場合は、次の制限が適用されます AWS SCT。
+ AWS SCT は、分析関数でのサブクエリの変換をサポートしていません。
+ を使用して BigQuery `SELECT AS STRUCT`および `SELECT AS VALUE`ステートメント AWS SCT を変換することはできません。
+ AWS SCT は、次のタイプの関数の変換をサポートしていません。
+ 近似値
+ ビット
+ デバッグ
+ 横串検索
+ 地域別
+ ハッシュ
+ 数学的
+ 正味
+ 統計集計
+ UUID
+ AWS SCT では、文字列関数の変換のサポートが制限されています。
+ AWS SCT は`UNNEST`演算子の変換をサポートしていません。
+ AWS SCTでは相関結合操作を変換できません。
+ AWS SCT は、`QUALIFY`、、`WINDOW`、`LIMIT`および `OFFSET`句の変換をサポートしていません。
+ を使用して再帰的な共通テーブル式 AWS SCT を変換することはできません。
+ AWS SCT は、 `VALUES`句内のサブクエリを含む`INSERT`ステートメントの変換をサポートしていません。
+ AWS SCT は、ネストされたフィールドと繰り返しレコードの`UPDATE`ステートメントの変換をサポートしていません。
+ を使用して `STRUCT`および `ARRAY` データ型 AWS SCT を変換することはできません。
## BigQuery から Amazon Redshift への変換設定
BigQuery から Amazon Redshift への変換設定を編集するには、「 **の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上部のリストから Google ** BigQuery** を選択し、**Google BigQuery – Amazon Redshift**. AWS SCT displays all available settings for BigQuery to Amazon Redshift conversion を選択します。
の BigQuery から Amazon Redshift への変換設定には、以下のオプション AWS SCT が含まれます。
+ 変換されたコード内のアクション項目に関するコメントの数を制限する。
選択した**重要度以上のアクション項目の変換されたコードにコメントを追加する で**、アクション項目の重要度を選択します。 は、選択した重要度以上のアクション項目の変換されたコードにコメント AWS SCT を追加します。
たとえば、変換したコード内のコメントの数を最小限に抑えるには、[**エラーのみ**] を選択します。変換したコードのすべてのアクション項目にコメントを含めるには、[**すべてのメッセージ**] を選択します。
+ ターゲット Amazon Redshift クラスターに適用 AWS SCT できるテーブルの最大数を設定するには。
**ターゲット Amazon Redshift クラスターのテーブルの最大数で**、Amazon Redshift クラスターに適用 AWS SCT できるテーブルの数を選択します。
Amazon Redshift には、クラスターノードタイプの使用を制限するクォータがあります。**Auto** を選択した場合、 はノードタイプに応じてターゲット 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 テーブルの列に圧縮を適用します。そのためには、[**圧縮エンコードを使用**] を選択します。
AWS SCT は、デフォルトの Amazon Redshift アルゴリズムを使用して、圧縮エンコーディングを列に自動的に割り当てます。詳細については、『*Amazon Redshift データベースデベロッパーガイド*』の「[圧縮エンコード](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)」を参照してください。
デフォルトでは、Amazon Redshift はソートキーと分散キーとして定義されている列に圧縮を適用しません。この動作を変更したり、これらの列に圧縮を適用したりできます。そのためには、[**KEY 列には圧縮エンコードを使用**] を選択します。このオプションは、[**圧縮エンコードを使用**] オプションを選択した場合にのみ選択できます。
## BigQuery から Amazon Redshift への変換最適化設定
BigQuery から Amazon Redshift への変換最適化設定を編集するには、**「 の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上のリストから [**Google BigQuery**] を選択し、次に [**Google BigQuery — Amazon Redshift**] を選択します。左側のペインで、**最適化 strategies**. AWS SCT displays conversion Optimization settings for BigQuery to Amazon Redshift conversion を選択します。
の BigQuery から Amazon Redshift への変換最適化設定には、次のオプション AWS SCT が含まれます。
+ 自動テーブル最適化を使用するには。そのためには、[**Amazon Redshift の自動テーブルチューニングを使用する**] を選択します。
自動テーブル最適化は、テーブルの設計を自動的に最適化する Amazon Redshift の自己調整プロセスです。詳細については、『*Amazon Redshift データベース開発者ガイド*』の「[自動テーブル最適化の操作](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)」を参照してください。
自動テーブル最適化のみを利用するには、[**初期キー選択戦略**] で [**なし**] を選択します。
+ 戦略を使用してソートキーと分散キーを選択するには。
Amazon Redshift メタデータ、統計情報、またはこれらのオプションの両方を使用して、ソートキーと配布キーを選択できます。[**最適化戦略**] タブの [**初期キー選択戦略**] では、以下のいずれかのオプションを選択します。
+ メタデータを使用し、統計情報は無視する
+ メタデータを無視し、統計情報を使用する
+ メタデータと統計情報を使用する
選択したオプションに応じて、最適化戦略を選択できます。次に、各戦略について、値 (0～100) を入力します。これらの値は各戦略の重みを定義します。これらの重み値を使用して、 AWS SCT は各ルールがディストリビューションキーとソートキーの選択にどのように影響するかを定義します。デフォルト値は、 AWS 移行のベストプラクティスに基づいています。
[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブル内の最小行数と最大行数を入力して、スモールテーブルとして定義します。 は`ALL`、分散スタイルをスモールテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
+ 戦略の詳細を設定するには。
各最適化戦略の重みを定義することに加えて、最適化設定を構成できます。そのためには、[**変換の最適化**] を選択します。
+ [**ソートキー列の制限**] には、ソートキーの列の最大数を入力します。
+ **歪んだしきい値**には、列の歪んだ値の割合 (0 ～ 100) を入力します。分散キーの候補リストから、歪んだ値がしきい値より大きい列 AWS SCT を除外します。 は、列の歪んだ値を、レコードの合計数に対する最も一般的な値の出現回数の割合として AWS SCT 定義します。
+ [**クエリ履歴テーブルの上位 N 件のクエリ**] には、分析対象として最も頻繁に使用されるクエリの数 (1 ～ 100) を入力します。
+ [**統計ユーザーを選択**] では、クエリ統計を分析したいデータベースユーザーを選択します。
また、[**最適化戦略**」タブでは、[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブル内の最小行数と最大行数を入力して、それを小さなテーブルと見なします。 は`ALL`分散スタイルを小さなテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
# Greenplum データベースを に接続する AWS Schema Conversion Tool
AWS SCT を使用して、スキーマ、コードオブジェクト、アプリケーションコードを Greenplum Database から Amazon Redshift に変換できます。
## ソースとしての Greenplum データベースの権限
Greenplum データベースをソースとして使用するのに必要な権限を以下に示します。
+ CONNECT ON DATABASE **
+ USAGE ON SCHEMA **
+ SELECT ON *.*
+ SELECT ON SEQUENCE *.*
上記の例で、次のプレースホルダを置き換えます。
+ *database\$1name* をソースデータベースの名前に置き換えます。
+ *schema\$1name* をソーススキーマの名前に置き換えます。
+ *table\$1name* をテーブルの名前に置き換えます。
+ *sequence\$1name* をシーケンスの名前に置き換えます。
## ソースとしての Greenplum データベースへの接続
を使用して Greenplum ソースデータベースに接続するには、次の手順に従います AWS SCT。
**Greenplum ソースデータベースに接続するには**
1. で AWS Schema Conversion Tool、**ソースの追加** を選択します。
1. [**SAP ASE**] を選択し、その後 [**Next**] (次へ) を選択します。
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] にデータベースの名前を入力します。この名前が AWS SCT の左側のパネルのツリーに表示されます。
1. からデータベース認証情報を使用する AWS Secrets Manager か、手動で入力します。
+ Secrets Manager のデータベース認証情報を使用するには、以下の手順に従ってください。
1. [**AWS シークレット**] で、シークレットの名前を選択します。
1. [**入力**] を選択すると、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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.Greenplum.html)
1. **接続のテスト**を選択して、 がソースデータベースに接続 AWS SCT できることを確認します。
1. [**Connect**] (接続) を選択して、ソースデータベースに接続します。
## Greenplum から Amazon Redshift への変換設定
Greenplum から Amazon Redshift への変換設定を編集するには、「 **の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上部のリストから **Greenplum** を選択し、**Greenplum – Amazon Redshift**. AWS SCT displays all available settings for Greenplum to Amazon Redshift conversion を選択します。
の Greenplum から Amazon Redshift への変換設定には、以下のオプション AWS SCT が含まれています。
+ 変換されたコード内のアクション項目に関するコメントの数を制限する。
選択した**重要度以上のアクション項目の変換されたコードにコメントを追加する で**、アクション項目の重要度を選択します。 は、選択した重要度以上のアクション項目の変換されたコードにコメント AWS SCT を追加します。
たとえば、変換したコード内のコメントの数を最小限に抑えるには、[**エラーのみ**] を選択します。変換したコードのすべてのアクション項目にコメントを含めるには、[**すべてのメッセージ**] を選択します。
+ ターゲット Amazon Redshift クラスターに適用 AWS SCT できるテーブルの最大数を設定するには。
**ターゲット Amazon Redshift クラスターのテーブルの最大数で**、Amazon Redshift クラスターに適用 AWS SCT できるテーブルの数を選択します。
Amazon Redshift には、クラスターノードタイプの使用を制限するクォータがあります。**Auto** を選択した場合、 はノードタイプに応じてターゲット 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 の別のテーブルに移行するには。そのためには、[**UNION ALL ビューを使用する**] を選択し、 AWS SCT が 1 つのソーステーブルに対して作成できるターゲットテーブルの最大数を入力します。
Amazon Redshift は、テーブルのパーティションをサポートしていません。この動作をエミュレートしてクエリの実行を高速化するには、ソーステーブルの各パーティションを Amazon Redshift の別のテーブル AWS SCT に移行できます。次に、 はこれらのすべてのテーブルのデータを含むビュー AWS SCT を作成します。
AWS SCT は、ソーステーブル内のパーティションの数を自動的に決定します。ソーステーブルパーティショニングのタイプによっては、この数は Amazon Redshift クラスターに適用できるテーブルのクォータを超える場合があります。このクォータに達しないようにするには、単一のソーステーブルのパーティションに対して が作成 AWS SCT できるターゲットテーブルの最大数を入力します。デフォルトのオプションは 368 テーブルで、これは 1 年 366 日のパーティションと、`NO RANGE` および `UNKNOWN` パーティションの 2 つのテーブルを表します。
+ Amazon Redshift テーブルの列に圧縮を適用します。そのためには、[**圧縮エンコードを使用**] を選択します。
AWS SCT は、デフォルトの Amazon Redshift アルゴリズムを使用して、圧縮エンコーディングを列に自動的に割り当てます。詳細については、『*Amazon Redshift データベースデベロッパーガイド*』の「[圧縮エンコード](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)」を参照してください。
デフォルトでは、Amazon Redshift はソートキーと分散キーとして定義されている列に圧縮を適用しません。この動作を変更したり、これらの列に圧縮を適用したりできます。そのためには、[**KEY 列には圧縮エンコードを使用**] を選択します。このオプションは、[**圧縮エンコードを使用**] オプションを選択した場合にのみ選択できます。
## Greenplum から Amazon Redshift への変換最適化設定
Greenplum から Amazon Redshift への変換最適化設定を編集するには、**「 の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上のリストから [**Greenplum**] を選択し、次に [**Greenplum – Amazon Redshift**] を選択します。左側のペインで、**最適化 strategies**. AWS SCT displays conversion Optimization settings for Greenplum to Amazon Redshift conversion を選択します。
の Greenplum から Amazon Redshift への変換最適化設定 AWS SCT には、以下のオプションが含まれています。
+ 自動テーブル最適化を使用するには。そのためには、[**Amazon Redshift の自動テーブルチューニングを使用する**] を選択します。
自動テーブル最適化は、テーブルの設計を自動的に最適化する Amazon Redshift の自己調整プロセスです。詳細については、『*Amazon Redshift データベース開発者ガイド*』の「[自動テーブル最適化の操作](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)」を参照してください。
自動テーブル最適化のみを利用するには、[**初期キー選択戦略**] で [**なし**] を選択します。
+ 戦略を使用してソートキーと分散キーを選択するには。
Amazon Redshift メタデータ、統計情報、またはこれらのオプションの両方を使用して、ソートキーと配布キーを選択できます。[**最適化戦略**] タブの [**初期キー選択戦略**] では、以下のいずれかのオプションを選択します。
+ メタデータを使用し、統計情報は無視する
+ メタデータを無視し、統計情報を使用する
+ メタデータと統計情報を使用する
選択したオプションに応じて、最適化戦略を選択できます。次に、各戦略について、値 (0～100) を入力します。これらの値は各戦略の重みを定義します。これらの重み値を使用して、 AWS SCT は各ルールがディストリビューションキーとソートキーの選択にどのように影響するかを定義します。デフォルト値は、 AWS 移行のベストプラクティスに基づいています。
[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブル内の最小行数と最大行数を入力して、スモールテーブルとして定義します。 は`ALL`、分散スタイルをスモールテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
+ 戦略の詳細を設定するには。
各最適化戦略の重みを定義することに加えて、最適化設定を構成できます。そのためには、[**変換の最適化**] を選択します。
+ [**ソートキー列の制限**] には、ソートキーの列の最大数を入力します。
+ **歪んだしきい値**には、列の歪んだ値の割合 (0～100) を入力します。分散キーの候補リストから、歪んだ値がしきい値より大きい列 AWS SCT を除外します。 は、列の歪んだ値を、レコードの合計数に対する最も一般的な値の出現回数の割合として AWS SCT 定義します。
+ [**クエリ履歴テーブルの上位 N 件のクエリ**] には、分析対象として最も頻繁に使用されるクエリの数 (1 ～ 100) を入力します。
+ [**統計ユーザーを選択**] では、クエリ統計を分析したいデータベースユーザーを選択します。
また、[**最適化戦略**」タブでは、[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブル内の最小行数と最大行数を入力して、それを小さなテーブルと見なします。 は`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 への接続
以下の手順を使用して、Netezza ソースデータベースを AWS Schema Conversion Toolに接続します。
**Netezza ソースデータベースに接続するには**
1. で AWS Schema Conversion Tool、**ソースの追加**を選択します。
1. [**Netezza**] [**Next**] (次へ) の順に選択します。
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] にデータベースの名前を入力します。この名前が AWS SCT の左側のパネルのツリーに表示されます。
1. からデータベース認証情報を使用する AWS Secrets Manager か、手動で入力します。
+ Secrets Manager のデータベース認証情報を使用するには、以下の手順に従ってください。
1. [**AWS シークレット**] で、シークレットの名前を選択します。
1. [**入力**] を選択すると、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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.Netezza.html)
1. **接続のテスト**を選択して、 がソースデータベースに接続 AWS SCT できることを確認します。
1. [**Connect**] (接続) を選択して、ソースデータベースに接続します。
## 継続的なデータ複製の設定
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 つのトランザクションポイントを使用できます。
1. データ抽出エージェントを登録します。詳細については、「[に抽出エージェントを登録する AWS Schema Conversion Tool](agents.md#agents.Using)」を参照してください。
1. CDC タスクを作成します。詳細については、「[ AWS SCT タスクの作成、実行、モニタリング](agents.md#agents.Tasks)」を参照してください。
1. AWS SCTでプロジェクトを開きます。左のペインで、ソーステーブルを選択します。オブジェクトのコンテキスト (右クリック) メニューを開き、[**ローカルタスクの作成**] を選択します。
1. [**タスク名**] に、データ移行タスクのわかりやすい名前を入力します。
1. [**移行モード**] には、[**抽出、アップロード、コピー**] を選択します。
1. **[同期の有効化]** を選択します。
1. [**CDC 設定**] タブを選択し、CDC セッションの範囲とスケジュールを定義します。
1. [**タスクのテスト**] を選択して、作業フォルダ、Amazon S3 バケット、および Amazon Redshift データウェアハウスに接続できることを確認します。
1. [**作成**] を選択して、タスクを作成します。
1. [**タスク**] タブを選択し、一覧からタスクを選択して [**開始**] を選択します。
1. AWS SCT タスクは、ターゲットデータベースのトランザクション整合性を維持します。データ抽出エージェントは、ソースからのトランザクションをトランザクション ID 順に複製します。
移行セッションのいずれかを停止したり、失敗したりすると、CDC 処理も停止します。
## Netezza から Amazon Redshift への変換設定
Netezza から Amazon Redshift への変換設定を編集するには、「 **の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上部のリストから **Netezza** を選択し、**Netezza – Amazon Redshift**. AWS SCT displays all available settings for Netezza to Amazon Redshift conversion を選択します。
の Netezza から Amazon Redshift への変換設定には、以下のオプション AWS SCT が含まれています。
+ 変換されたコード内のアクション項目に関するコメントの数を制限する。
選択した**重要度以上のアクション項目の変換されたコードにコメントを追加する で**、アクション項目の重要度を選択します。 は、選択した重要度以上のアクション項目の変換されたコードにコメント AWS SCT を追加します。
たとえば、変換したコード内のコメントの数を最小限に抑えるには、[**エラーのみ**] を選択します。変換したコードのすべてのアクション項目にコメントを含めるには、[**すべてのメッセージ**] を選択します。
+ ターゲット Amazon Redshift クラスターに適用 AWS SCT できるテーブルの最大数を設定するには。
**ターゲット Amazon Redshift クラスターのテーブルの最大数で**、Amazon Redshift クラスターに適用 AWS SCT できるテーブルの数を選択します。
Amazon Redshift には、クラスターノードタイプの使用を制限するクォータがあります。**Auto** を選択した場合、 はノードタイプに応じてターゲット 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 テーブルの列に圧縮を適用します。そのためには、[**圧縮エンコードを使用**] を選択します。
AWS SCT は、デフォルトの Amazon Redshift アルゴリズムを使用して、圧縮エンコーディングを列に自動的に割り当てます。詳細については、『*Amazon Redshift データベースデベロッパーガイド*』の「[圧縮エンコード](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)」を参照してください。
デフォルトでは、Amazon Redshift はソートキーと分散キーとして定義されている列に圧縮を適用しません。この動作を変更したり、これらの列に圧縮を適用したりできます。そのためには、[**KEY 列には圧縮エンコードを使用**] を選択します。このオプションは、[**圧縮エンコードを使用**] オプションを選択した場合にのみ選択できます。
## Netezza から Amazon Redshift への変換最適化設定
Netezza から Amazon Redshift への変換最適化設定を編集するには、**「 の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上のリストから [**Netezza**] を選択し、次に [**Netezza – Amazon Redshift**] を選択します。左側のペインで、**最適化 strategies**. AWS SCT displays conversion Optimization settings for Netezza to Amazon Redshift conversion を選択します。
の Netezza から Amazon Redshift への変換最適化設定 AWS SCT には、以下のオプションが含まれています。
+ 自動テーブル最適化を使用するには。そのためには、[**Amazon Redshift の自動テーブルチューニングを使用する**] を選択します。
自動テーブル最適化は、テーブルの設計を自動的に最適化する Amazon Redshift の自己調整プロセスです。詳細については、『*Amazon Redshift データベース開発者ガイド*』の「[自動テーブル最適化の操作](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)」を参照してください。
自動テーブル最適化のみを利用するには、[**初期キー選択戦略**] で [**なし**] を選択します。
+ 戦略を使用してソートキーと分散キーを選択するには。
Amazon Redshift メタデータ、統計情報、またはこれらのオプションの両方を使用して、ソートキーと配布キーを選択できます。[**最適化戦略**] タブの [**初期キー選択戦略**] では、以下のいずれかのオプションを選択します。
+ メタデータを使用し、統計情報は無視する
+ メタデータを無視し、統計情報を使用する
+ メタデータと統計情報を使用する
選択したオプションに応じて、最適化戦略を選択できます。次に、各戦略について、値 (0～100) を入力します。これらの値は各戦略の重みを定義します。これらの重み値を使用して、 AWS SCT は各ルールがディストリビューションキーとソートキーの選択にどのように影響するかを定義します。デフォルト値は、 AWS 移行のベストプラクティスに基づいています。
[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブル内の最小行数と最大行数を入力して、スモールテーブルとして定義します。 は`ALL`、分散スタイルをスモールテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
+ 戦略の詳細を設定するには。
各最適化戦略の重みを定義することに加えて、最適化設定を構成できます。そのためには、[**変換の最適化**] を選択します。
+ [**ソートキー列の制限**] には、ソートキーの列の最大数を入力します。
+ **歪んだしきい値**には、列の歪んだ値の割合 (0～100) を入力します。分散キーの候補リストから、歪んだ値がしきい値より大きい列 AWS SCT を除外します。 は、列の歪んだ値を、レコードの合計数に対する最も一般的な値の出現回数の割合として AWS SCT 定義します。
+ [**クエリ履歴テーブルの上位 N 件のクエリ**] には、分析対象として最も頻繁に使用されるクエリの数 (1 ～ 100) を入力します。
+ [**統計ユーザーを選択**] では、クエリ統計を分析したいデータベースユーザーを選択します。
また、[**最適化戦略**」タブでは、[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブル内の最小行数と最大行数を入力して、スモールテーブルと見なします。 は`ALL`分散スタイルをスモールテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
# を使用した Oracle Data Warehouse の接続 AWS SCT
AWS SCT を使用して、スキーマ、コードオブジェクト、アプリケーションコードを Oracle Data Warehouse から Amazon Redshift または Amazon Redshift に変換し、組み合わせて AWS Glue 使用できます。
## ソースとしての Oracle データウェアハウスの権限
Oracle データウェアハウスをソースとして使用するには、次の権限が必要です。
+ 接続
+ select\$1catalog\$1role
+ ディクショナリを選択します
## ソースとしての Oracle データウェアハウスへの接続
以下の手順を使用して、Oracle データウェアハウスソースデータベースを AWS Schema Conversion Toolに接続します。
**Oracle データウェアハウスソースデータベースに接続するには**
1. で AWS Schema Conversion Tool、**ソースの追加**を選択します。
1. [**Oracle**] を選択し、その後 [**Next**] (次へ) を選択します。
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] にデータベースの名前を入力します。この名前が AWS SCT の左側のパネルのツリーに表示されます。
1. からデータベース認証情報を使用する AWS Secrets Manager か、手動で入力します。
+ Secrets Manager のデータベース認証情報を使用するには、以下の手順に従ってください。
1. [**AWS シークレット**] で、シークレットの名前を選択します。
1. [**入力**] を選択すると、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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.OracleDW.html)
1. **接続のテスト**を選択して、 がソースデータベースに接続 AWS SCT できることを確認します。
1. [**Connect**] (接続) を選択して、ソースデータベースに接続します。
## Oracle データウェアハウスから 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 には、クラスターノードタイプの使用を制限するクォータがあります。**Auto** を選択した場合、 はノードタイプに応じてターゲット 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 の別のテーブルに移行するには。そのためには、[**UNION ALL ビューを使用する**] を選択し、 AWS SCT が 1 つのソーステーブルに対して作成できるターゲットテーブルの最大数を入力します。
Amazon Redshift は、テーブルのパーティションをサポートしていません。この動作をエミュレートしてクエリの実行を高速化するには、ソーステーブルの各パーティションを Amazon Redshift の別のテーブル AWS SCT に移行できます。次に、 はこれらのすべてのテーブルのデータを含むビュー AWS SCT を作成します。
AWS SCT は、ソーステーブル内のパーティションの数を自動的に決定します。ソーステーブルパーティショニングのタイプによっては、この数は Amazon Redshift クラスターに適用できるテーブルのクォータを超える場合があります。このクォータに達しないようにするには、単一のソーステーブルのパーティションに対して が作成 AWS SCT できるターゲットテーブルの最大数を入力します。デフォルトのオプションは 368 テーブルで、これは 1 年 366 日のパーティションと、`NO RANGE` および `UNKNOWN` パーティションの 2 つのテーブルを表します。
+ Amazon Redshift がサポートしていない日時フォーマット要素を使用して、`TO_CHAR`、`TO_DATE`、`TO_NUMBER` などのデータ型フォーマット関数を変換するには。デフォルトでは、 AWS SCT は拡張パック関数を使用して、変換されたコード内のサポートされていないフォーマット要素の使用をエミュレートします。
Oracle の日時フォーマットモデルには、Amazon Redshift の日時フォーマット文字列と比較してより多くの要素が含まれています。ソースコードに Amazon Redshift がサポートする日時形式の要素のみが含まれている場合、変換されたコードに拡張パック関数は必要ありません。変換後のコードで拡張パック関数を使用しないようにするには、Oracle コードで使用する [**日付型フォーマット要素が Amazon Redshift の日時フォーマット文字列に似ている**] ものを選択してください。この場合、変換されたコードの処理が速くなります。
Oracle の数値フォーマットモデルには、Amazon Redshift の数値フォーマット文字列よりも多くの要素が含まれています。ソースコードに Amazon Redshift がサポートする数値形式の要素のみが含まれている場合、変換されたコードに拡張パック関数は必要ありません。変換後のコードで拡張パック関数を使用しないようにするには、[**Oracle コードで使用する数値形式の要素は Amazon Redshift の数値形式の文字列と類似している**] を選択します。この場合、変換されたコードの処理が速くなります。
+ Oracle `LEAD` および `LAG` 分析関数を変換します。デフォルトでは、 AWS SCT は `LEAD` および `LAG` 関数ごとにアクション項目が生成されます。
ソースコードでこれらの関数でオフセットのデフォルト値を使用していない場合、 AWS SCT は `NVL` 関数でこれらの関数の使用をエミュレートできます。そのためには、[**NVL 関数を使用して Oracle LEAD 関数と LAG 関数の動作をエミュレートする**] を選択します。
+ Amazon Redshift クラスターのプライマリキーとユニークキーの動作をエミュレートするには、[**プライマリキーとユニークキーの動作をエミュレートする**] を選択します。
Amazon Redshift はユニークキーやプライマリキーを強制せず、情報提供のみを目的として使用します。これらの制約をコードで使用する場合は、 AWS SCT が変換されたコードでそれらの動作をエミュレートすることを確認します。
+ Amazon Redshift テーブルの列に圧縮を適用します。そのためには、[**圧縮エンコードを使用**] を選択します。
AWS SCT は、デフォルトの Amazon Redshift アルゴリズムを使用して、圧縮エンコーディングを列に自動的に割り当てます。詳細については、『*Amazon Redshift データベースデベロッパーガイド*』の「[圧縮エンコード](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)」を参照してください。
デフォルトでは、Amazon Redshift はソートキーと分散キーとして定義されている列に圧縮を適用しません。この動作を変更したり、これらの列に圧縮を適用したりできます。そのためには、[**KEY 列には圧縮エンコードを使用**] を選択します。このオプションは、[**圧縮エンコードを使用**] オプションを選択した場合にのみ選択できます。
## Oracle データウェアハウスから Amazon Redshift への変換最適化設定
Oracle Data Warehouse から Amazon Redshift への変換最適化設定を編集するには、**「 の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上のリストから [**Oracle**] を選択し、次に [**Oracle – Amazon Redshift**] を選択します。左側のペインで、**最適化 strategies**. AWS SCT displays conversion Optimization settings for Oracle Data Warehouse to Amazon Redshift conversion を選択します。
の Oracle Data Warehouse から Amazon Redshift への変換最適化設定 AWS SCT には、以下のオプションが含まれています。
+ 自動テーブル最適化を使用するには。そのためには、[**Amazon Redshift の自動テーブルチューニングを使用する**] を選択します。
自動テーブル最適化は、テーブルの設計を自動的に最適化する Amazon Redshift の自己調整プロセスです。詳細については、『*Amazon Redshift データベース開発者ガイド*』の「[自動テーブル最適化の操作](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)」を参照してください。
自動テーブル最適化のみを利用するには、[**初期キー選択戦略**] で [**なし**] を選択します。
+ 戦略を使用してソートキーと分散キーを選択するには。
Amazon Redshift メタデータ、統計情報、またはこれらのオプションの両方を使用して、ソートキーと配布キーを選択できます。[**最適化戦略**] タブの [**初期キー選択戦略**] では、以下のいずれかのオプションを選択します。
+ メタデータを使用し、統計情報は無視する
+ メタデータを無視し、統計情報を使用する
+ メタデータと統計情報を使用する
選択したオプションに応じて、最適化戦略を選択できます。次に、各戦略について、値 (0～100) を入力します。これらの値は各戦略の重みを定義します。これらの重み値を使用して、 AWS SCT は各ルールがディストリビューションキーとソートキーの選択にどのように影響するかを定義します。デフォルト値は、 AWS 移行のベストプラクティスに基づいています。
[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブルの最小行数と最大行数を入力して、スモールテーブルとして定義します。 は`ALL`、分散スタイルをスモールテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
+ 戦略の詳細を設定するには。
各最適化戦略の重みを定義することに加えて、最適化設定を構成できます。そのためには、[**変換の最適化**] を選択します。
+ [**ソートキー列の制限**] には、ソートキーの列の最大数を入力します。
+ **歪んだしきい値**には、列の歪んだ値の割合 (0～100) を入力します。 は、歪んだ値がディストリビューションキーの候補リストからしきい値より大きい列 AWS SCT を除外します。 は、列の歪んだ値を、レコードの合計数に対する最も一般的な値の出現回数の割合として AWS SCT 定義します。
+ [**クエリ履歴テーブルの上位 N 件のクエリ**] には、分析対象として最も頻繁に使用されるクエリの数 (1 ～ 100) を入力します。
+ [**統計ユーザーを選択**] では、クエリ統計を分析したいデータベースユーザーを選択します。
また、[**最適化戦略**」タブでは、[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブルの最小行数と最大行数を入力して、それを小さなテーブルと見なします。 は`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 バケットにアクセスし、データの読み取りおよび書き込みができるようになります。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**] を選択し、その後 [**Next**] (次へ) を選択します。
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] にデータベースの名前を入力します。この名前が AWS SCT の左側のパネルのツリーに表示されます。
1. からデータベース認証情報を使用する AWS Secrets Manager か、手動で入力します。
+ Secrets Manager のデータベース認証情報を使用するには、以下の手順に従ってください。
1. [**AWS シークレット**] で、シークレットの名前を選択します。
1. [**入力**] を選択すると、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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.Snowflake.html)
1. **接続のテスト**を選択して、 がソースデータベースに接続 AWS SCT できることを確認します。
1. [**Connect**] (接続) を選択して、ソースデータベースに接続します。
## Snowflake をソースとして使用する場合の制限
Snowflake をソースとして使用する場合の制限は次のとおりです AWS SCT。
+ オブジェクト識別子は、オブジェクトタイプと親オブジェクトのコンテキスト内で一意である必要があります。
**データベース**
スキーマ識別子は、データベース内で一意である必要があります。
**スキーマ**
テーブルやビューなどのオブジェクト識別子は、スキーマ内で一意である必要があります。
**テーブル/ビュー**
列識別子は、テーブル内で一意である必要があります。
+ 大規模および 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 バイトまでの Unicode 文字。1 文字あたり最大 4 バイト。 | VARCHAR(MAX) |
| TEXT(p) 65,535 バイトまでの Unicode 文字。1 文字あたり最大 4 バイト。 | If p is =< 65,535 then, VARCHAR(p) |
| TEXT(p) 16,777,216 バイトまでの Unicode 文字。1 文字あたり最大 4 バイト。 | If p is => 65,535 and =< 16,777,216 then, VARCHAR(MAX) |
| BINARY 8 388,608 バイトまでのシングルバイト文字、1 文字あたり 1 バイト。 | VARCHAR(MAX) |
| BINARY(p) 65,535 バイトまでのシングルバイト文字、1 文字あたり 1 バイト。 | VARCHAR(p) |
| BINARY(p) 8 388,608 バイトまでのシングルバイト文字、1 文字あたり 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**. AWS SCT displays all available settings for Snowflake to Amazon Redshift conversion を選択します。
の Snowflake から Amazon Redshift への変換設定 AWS SCT には、以下のオプションが含まれています。
+ 変換されたコード内のアクション項目に関するコメントの数を制限する。
選択した**重要度以上のアクション項目の変換されたコードにコメントを追加する で**、アクション項目の重要度を選択します。 は、選択した重要度以上のアクション項目の変換されたコードにコメント AWS SCT を追加します。
たとえば、変換したコード内のコメントの数を最小限に抑えるには、[**エラーのみ**] を選択します。変換したコードのすべてのアクション項目にコメントを含めるには、[**すべてのメッセージ**] を選択します。
+ ターゲット Amazon Redshift クラスターに適用 AWS SCT できるテーブルの最大数を設定します。
**ターゲット Amazon Redshift クラスターのテーブルの最大数で**、Amazon Redshift クラスターに適用 AWS SCT できるテーブルの数を選択します。
Amazon Redshift には、クラスターノードタイプの使用を制限するクォータがあります。**Auto** を選択した場合、 はノードタイプに応じてターゲット 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 テーブルの列に圧縮を適用します。そのためには、[**圧縮エンコードを使用**] を選択します。
AWS SCT は、デフォルトの Amazon Redshift アルゴリズムを使用して、圧縮エンコーディングを列に自動的に割り当てます。詳細については、『*Amazon Redshift データベースデベロッパーガイド*』の「[圧縮エンコード](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)」を参照してください。
デフォルトでは、Amazon Redshift はソートキーと分散キーとして定義されている列に圧縮を適用しません。この動作を変更したり、これらの列に圧縮を適用したりできます。そのためには、[**KEY 列には圧縮エンコードを使用**] を選択します。このオプションは、[**圧縮エンコードを使用**] オプションを選択した場合にのみ選択できます。
## スノーフレークから Amazon Redshift への変換最適化設定
Snowflake から Amazon Redshift への変換最適化設定を編集するには、**「 の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上のリストから [**Snowflake**] を選択し、次に [**Snowflake – Amazon Redshift**] を選択します。左側のペインで、**最適化 strategies**. AWS SCT displays conversion Optimization settings for Snowflake to Amazon Redshift conversion を選択します。
の Snowflake から Amazon Redshift への変換最適化設定 AWS SCT には、次のオプションが含まれています。
+ 自動テーブル最適化を使用するには。そのためには、[**Amazon Redshift の自動テーブルチューニングを使用する**] を選択します。
自動テーブル最適化は、テーブルの設計を自動的に最適化する Amazon Redshift の自己調整プロセスです。詳細については、『*Amazon Redshift データベース開発者ガイド*』の「[自動テーブル最適化の操作](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)」を参照してください。
自動テーブル最適化のみを利用するには、[**初期キー選択戦略**] で [**なし**] を選択します。
+ 戦略を使用してソートキーと分散キーを選択するには。
Amazon Redshift メタデータ、統計情報、またはこれらのオプションの両方を使用して、ソートキーと配布キーを選択できます。[**最適化戦略**] タブの [**初期キー選択戦略**] では、以下のいずれかのオプションを選択します。
+ メタデータを使用し、統計情報は無視する
+ メタデータを無視し、統計情報を使用する
+ メタデータと統計情報を使用する
選択したオプションに応じて、最適化戦略を選択できます。次に、各戦略について、値 (0～100) を入力します。これらの値は各戦略の重みを定義します。これらの重み値を使用して、 AWS SCT は各ルールがディストリビューションキーとソートキーの選択にどのように影響するかを定義します。デフォルト値は、 AWS 移行のベストプラクティスに基づいています。
[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブルの最小行数と最大行数を入力して、スモールテーブルとして定義します。 は`ALL`、分散スタイルをスモールテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
+ 戦略の詳細を設定するには。
各最適化戦略の重みを定義することに加えて、最適化設定を構成できます。そのためには、[**変換の最適化**] を選択します。
+ [**ソートキー列の制限**] には、ソートキーの列の最大数を入力します。
+ **歪んだしきい値**には、列の歪んだ値の割合 (0～100) を入力します。分散キーの候補のリストから、歪んだ値がしきい値より大きい列 AWS SCT を除外します。 は、列の歪んだ値を、レコードの合計数に対する最も一般的な値の出現回数の割合として AWS SCT 定義します。
+ [**クエリ履歴テーブルの上位 N 件のクエリ**] には、分析対象として最も頻繁に使用されるクエリの数 (1 ～ 100) を入力します。
+ [**統計ユーザーを選択**] では、クエリ統計を分析したいデータベースユーザーを選択します。
また、[**最適化戦略**」タブでは、[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブルの最小行数と最大行数を入力して、それを小さなテーブルと見なします。 は`ALL`分散スタイルを小さなテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
# を使用した SQL Server データウェアハウスへの接続 AWS Schema Conversion Tool
AWS SCT を使用して、スキーマ、コードオブジェクト、アプリケーションコードを Microsoft SQL Server DW から Amazon Redshift または Amazon Redshift に変換し、組み合わせて AWS Glue 使用できます。
## Microsoft SQL Server データウェアハウスのソースとしての権限
ソースとして Microsoft SQL Server データウェアハウスに必要な特権を以下に示します。
+ VIEW DEFINITION
+ VIEW DATABASE STATE
+ SELECT ON SCHEMA :: **
前の例では、** プレースホルダーをソースの source\$1schema の名前に置き換えます。
スキーマを変換する、各データベースの付与を繰り返します。
さらに、次の権限を付与し、マスターデータベースで権限を実行します。
+ VIEW SERVER STATE
## SQL Server データウェアハウスをソースとして使用する場合の制限
Microsoft SQL Server 並列データウェアハウス (PDW) をソースとして使用することは、現在サポートされていません。
## ソースとしての SQL Server データウェアハウスへの接続
以下の手順を使用して、SQL Server データウェアハウスソースデータベースを AWS Schema Conversion Toolに接続します。
**SQL Server データウェアハウスソースデータベースに接続するには**
1. で AWS Schema Conversion Tool、**ソースの追加**を選択します。
1. [**Microsoft SQL Server**]、次に [**Next**] (次へ) を選択します。
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] にデータベースの名前を入力します。この名前が AWS SCT の左側のパネルのツリーに表示されます。
1. からデータベース認証情報を使用する AWS Secrets Manager か、手動で入力します。
+ Secrets Manager のデータベース認証情報を使用するには、以下の手順に従ってください。
1. [**AWS シークレット**] で、シークレットの名前を選択します。
1. [**入力**] を選択すると、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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServerDW.html)
1. **接続のテスト**を選択して、 がソースデータベースに接続 AWS SCT できることを確認します。
1. [**Connect**] (接続) を選択して、ソースデータベースに接続します。
## SQL Server データウェアハウスから Amazon Redshift への変換設定
SQL Server データウェアハウスから Amazon Redshift への変換設定を編集するには、**「 の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上部のリストから Microsoft **SQL Server** を選択し、**Microsoft SQL Server – Amazon Redshift** を選択します。SQL Server データウェアハウスから Amazon Redshift への変換に使用できるすべての設定 AWS SCT を表示します。
の SQL Server データウェアハウスから Amazon Redshift への変換設定 AWS SCT には、以下のオプションが含まれています。
+ 変換されたコード内のアクション項目に関するコメントの数を制限する。
選択した**重要度以上のアクション項目の変換されたコードにコメントを追加する で**、アクション項目の重要度を選択します。 は、選択した重要度以上のアクション項目の変換されたコードにコメント AWS SCT を追加します。
たとえば、変換したコード内のコメントの数を最小限に抑えるには、[**エラーのみ**] を選択します。変換したコードのすべてのアクション項目にコメントを含めるには、[**すべてのメッセージ**] を選択します。
+ ターゲット Amazon Redshift クラスターに適用 AWS SCT できるテーブルの最大数を設定します。
**ターゲット Amazon Redshift クラスターのテーブルの最大数で**、Amazon Redshift クラスターに適用 AWS SCT できるテーブルの数を選択します。
Amazon Redshift には、クラスターノードタイプの使用を制限するクォータがあります。**Auto** を選択した場合、 はノードタイプに応じてターゲット 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 の別のテーブルに移行するには。そのためには、[**UNION ALL ビューを使用する**] を選択し、 AWS SCT が 1 つのソーステーブルに対して作成できるターゲットテーブルの最大数を入力します。
Amazon Redshift は、テーブルのパーティションをサポートしていません。この動作をエミュレートしてクエリの実行を高速化するには、ソーステーブルの各パーティションを Amazon Redshift の別のテーブル AWS SCT に移行できます。次に、 はこれらのすべてのテーブルのデータを含むビュー AWS SCT を作成します。
AWS SCT は、ソーステーブル内のパーティションの数を自動的に決定します。ソーステーブルパーティショニングのタイプによっては、この数は Amazon Redshift クラスターに適用できるテーブルのクォータを超える場合があります。このクォータに達しないようにするには、単一のソーステーブルのパーティションに対して が作成 AWS SCT できるターゲットテーブルの最大数を入力します。デフォルトのオプションは 368 テーブルで、これは 1 年 366 日のパーティションと、`NO RANGE` および `UNKNOWN` パーティションの 2 つのテーブルを表します。
+ Amazon Redshift テーブルの列に圧縮を適用します。そのためには、[**圧縮エンコードを使用**] を選択します。
AWS SCT は、デフォルトの Amazon Redshift アルゴリズムを使用して、圧縮エンコーディングを列に自動的に割り当てます。詳細については、『*Amazon Redshift データベースデベロッパーガイド*』の「[圧縮エンコード](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)」を参照してください。
デフォルトでは、Amazon Redshift はソートキーと分散キーとして定義されている列に圧縮を適用しません。この動作を変更したり、これらの列に圧縮を適用したりできます。そのためには、[**KEY 列には圧縮エンコードを使用**] を選択します。このオプションは、[**圧縮エンコードを使用**] オプションを選択した場合にのみ選択できます。
## SQL Server データウェアハウスから Amazon Redshift への変換最適化設定
SQL Server データウェアハウスから Amazon Redshift への変換最適化設定を編集するには、**「 の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上のリストから [**Microsoft SQL Server**] を選択し、次に [**Microsoft SQL Server — Amazon Redshift**] を選択します。左側のペインで、**最適化 strategies**. AWS SCT displays conversion Optimization settings for SQL Server Data Warehouse to Amazon Redshift conversion を選択します。
の SQL Server データウェアハウスから Amazon Redshift への変換最適化設定 AWS SCT には、以下のオプションが含まれています。
+ 自動テーブル最適化を使用するには。そのためには、[**Amazon Redshift の自動テーブルチューニングを使用する**] を選択します。
自動テーブル最適化は、テーブルの設計を自動的に最適化する Amazon Redshift の自己調整プロセスです。詳細については、『*Amazon Redshift データベース開発者ガイド*』の「[自動テーブル最適化の操作](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)」を参照してください。
自動テーブル最適化のみを利用するには、[**初期キー選択戦略**] で [**なし**] を選択します。
+ 戦略を使用してソートキーと分散キーを選択するには。
Amazon Redshift メタデータ、統計情報、またはこれらのオプションの両方を使用して、ソートキーと配布キーを選択できます。[**最適化戦略**] タブの [**初期キー選択戦略**] では、以下のいずれかのオプションを選択します。
+ メタデータを使用し、統計情報は無視する
+ メタデータを無視し、統計情報を使用する
+ メタデータと統計情報を使用する
選択したオプションに応じて、最適化戦略を選択できます。次に、各戦略について、値 (0～100) を入力します。これらの値は各戦略の重みを定義します。これらの重み値を使用して、 AWS SCT は各ルールがディストリビューションキーとソートキーの選択にどのように影響するかを定義します。デフォルト値は、 AWS 移行のベストプラクティスに基づいています。
[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブル内の最小行数と最大行数を入力して、スモールテーブルとして定義します。 は`ALL`、分散スタイルをスモールテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
+ 戦略の詳細を設定するには。
各最適化戦略の重みを定義することに加えて、最適化設定を構成できます。そのためには、[**変換の最適化**] を選択します。
+ [**ソートキー列の制限**] には、ソートキーの列の最大数を入力します。
+ **歪んだしきい値**には、列の歪んだ値の割合 (0～100) を入力します。分散キーの候補リストから、歪んだ値がしきい値より大きい列 AWS SCT を除外します。 は、列の歪んだ値を、レコードの合計数に対する最も一般的な値の出現回数の割合として AWS SCT 定義します。
+ [**クエリ履歴テーブルの上位 N 件のクエリ**] には、分析対象として最も頻繁に使用されるクエリの数 (1 ～ 100) を入力します。
+ [**統計ユーザーを選択**] では、クエリ統計を分析したいデータベースユーザーを選択します。
また、[**最適化戦略**」タブでは、[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブル内の最小行数と最大行数を入力して、スモールテーブルと見なします。 は`ALL`、分散スタイルをスモールテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
# を使用した Teradata データウェアハウスへの接続 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 権限が必要です。この権限を使用してソース Teradata データベースに新しいオブジェクトを作成 AWS SCT しないでください。
## ソースとしての Teradata への接続
以下の手順を使用して、Teradata ソースデータベースを AWS Schema Conversion Toolに接続します。
**Teradata ソースデータベースに接続するには**
1. で AWS Schema Conversion Tool、**ソースの追加**を選択します。
1. [**Teradata**] を選択し、その後 [**Next**] (次へ) を選択します。
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] にデータベースの名前を入力します。この名前が AWS SCT の左側のパネルのツリーに表示されます。
1. からデータベース認証情報を使用する AWS Secrets Manager か、手動で入力します。
+ Secrets Manager のデータベース認証情報を使用するには、以下の手順に従ってください。
1. [**AWS シークレット**] で、シークレットの名前を選択します。
1. [**入力**] を選択すると、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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.Teradata.html)
1. **接続のテスト**を選択して、 がソースデータベースに接続 AWS SCT できることを確認します。
1. [**Connect**] (接続) を選択して、ソースデータベースに接続します。
### Teradata ソースでの LDAP 認証の使用
Windows で Microsoft Active Directory を実行する Teradata ユーザーに対して Lightweight Directory Access Protocol (LDAP) 認証をセットアップするには、以下の手順を使用します。
以下の手順では、アクティブディレクトリドメインは `test.local.com` です。Windows サーバーは `DC` で、デフォルト設定で構成されています。以下のスクリプトは `test_ldap` Active Directory を作成し、このアカウントはパスワード `test_ldap` を使用します。
**Microsoft Active Directory を Windows で実行する 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;
```
LDAP ユーザー用に Active Directory でユーザーパスワードを変更する場合、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 プロジェクトの統計を収集できます。また、ベーシック Teradata クエリ (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 プロジェクトにアップロードできます。このためには、プロジェクトの左側のパネルからデータウェアハウスを選択し、右クリックによりコンテキストメニューを開きます。[**統計をアップロード**] を選択します。
## 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 には、クラスターノードタイプの使用を制限するクォータがあります。**Auto** を選択した場合、 はノードタイプに応じてターゲット 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 の別のテーブルに移行するには。そのためには、[**UNION ALL ビューを使用する**] を選択し、 AWS SCT が 1 つのソーステーブルに対して作成できるターゲットテーブルの最大数を入力します。
Amazon Redshift は、テーブルのパーティションをサポートしていません。この動作をエミュレートしてクエリの実行を高速化するには、ソーステーブルの各パーティションを Amazon Redshift の別のテーブル AWS SCT に移行できます。次に、 はこれらのすべてのテーブルのデータを含むビュー AWS SCT を作成します。
AWS SCT は、ソーステーブル内のパーティションの数を自動的に決定します。ソーステーブルパーティショニングのタイプによっては、この数は Amazon Redshift クラスターに適用できるテーブルのクォータを超える場合があります。このクォータに達しないようにするには、単一のソーステーブルのパーティションに対して が作成 AWS SCT できるターゲットテーブルの最大数を入力します。デフォルトのオプションは 368 テーブルで、これは 1 年 366 日のパーティションと、`NO RANGE` および `UNKNOWN` パーティションの 2 つのテーブルを表します。
+ Amazon Redshift テーブルの列に圧縮を適用します。そのためには、[**圧縮エンコードを使用**] を選択します。
AWS SCT は、デフォルトの Amazon Redshift アルゴリズムを使用して、圧縮エンコーディングを列に自動的に割り当てます。詳細については、『*Amazon Redshift データベースデベロッパーガイド*』の「[圧縮エンコード](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)」を参照してください。
デフォルトでは、Amazon Redshift はソートキーと分散キーとして定義されている列に圧縮を適用しません。この動作を変更したり、これらの列に圧縮を適用したりできます。そのためには、[**KEY 列には圧縮エンコードを使用**] を選択します。このオプションは、[**圧縮エンコードを使用**] オプションを選択した場合にのみ選択できます。
+ 変換後のコードで明示的な列リストを `SELECT *` ステートメントに使用するには、[**明示的な列宣言を使用する**] を選択します。
+ Amazon Redshift クラスターのプライマリキーとユニークキーの動作をエミュレートするには、[**プライマリキーとユニークキーの動作をエミュレートする**] を選択します。
Amazon Redshift はユニークキーやプライマリキーを強制せず、情報提供のみを目的として使用します。これらの制約をコードで使用する場合は、 AWS SCT が変換されたコードでそれらの動作をエミュレートすることを確認します。
+ ターゲット Amazon Redshift テーブル内のデータの一意性を確保するには。そのためには、[**SET テーブルの動作をエミュレート**] を選択します。
Teradata は、`SET` 構文要素をデフォルトオプションとして使用してテーブルを作成します。`SET` テーブルに重複する行を追加することはできません。ソースコードでこの一意性制約が使用されていない場合は、このオプションをオフにしてください。この場合、変換されたコードの処理が速くなります。
ソースコードで一意性制約としてテーブル内の `SET` オプションを使用している場合は、このオプションをオンにしてください。この場合、 は変換されたコード内の`INSERT..SELECT`ステートメントを書き AWS SCT 換えて、ソースデータベースの動作をエミュレートします。
## Teradata から Amazon Redshift への変換最適化設定
Teradata から Amazon Redshift への変換最適化設定を編集するには、**「 の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上のリストから [**Teradata**] を選択し、次に [**Teradata – Amazon Redshift**] を選択します。左側のペインで、**最適化 strategies**. AWS SCT displays conversion Optimization settings for Teradata to Amazon Redshift conversion を選択します。
の Teradata から Amazon Redshift への変換最適化設定には、以下のオプション AWS SCT が含まれています。
+ 自動テーブル最適化を使用するには。そのためには、[**Amazon Redshift の自動テーブルチューニングを使用する**] を選択します。
自動テーブル最適化は、テーブルの設計を自動的に最適化する Amazon Redshift の自己調整プロセスです。詳細については、『*Amazon Redshift データベース開発者ガイド*』の「[自動テーブル最適化の操作](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)」を参照してください。
自動テーブル最適化のみを利用するには、[**初期キー選択戦略**] で [**なし**] を選択します。
+ 戦略を使用してソートキーと分散キーを選択するには。
Amazon Redshift メタデータ、統計情報、またはこれらのオプションの両方を使用して、ソートキーと配布キーを選択できます。[**最適化戦略**] タブの [**初期キー選択戦略**] では、以下のいずれかのオプションを選択します。
+ メタデータを使用し、統計情報は無視する
+ メタデータを無視し、統計情報を使用する
+ メタデータと統計情報を使用する
選択したオプションに応じて、最適化戦略を選択できます。次に、各戦略について、値 (0～100) を入力します。これらの値は各戦略の重みを定義します。これらの重み値を使用して、 AWS SCT は各ルールがディストリビューションキーとソートキーの選択にどのように影響するかを定義します。デフォルト値は、 AWS 移行のベストプラクティスに基づいています。
[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブルの最小行数と最大行数を入力して、スモールテーブルとして定義します。 は`ALL`、分散スタイルをスモールテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
+ 戦略の詳細を設定するには。
各最適化戦略の重みを定義することに加えて、最適化設定を構成できます。そのためには、[**変換の最適化**] を選択します。
+ [**ソートキー列の制限**] には、ソートキーの列の最大数を入力します。
+ **歪んだしきい値**には、列の歪んだ値の割合 (0～100) を入力します。分散キーの候補リストから、歪んだ値がしきい値より大きい列 AWS SCT を除外します。 は、列の歪んだ値を、レコードの合計数に対する最も一般的な値の出現回数の割合として AWS SCT 定義します。
+ [**クエリ履歴テーブルの上位 N 件のクエリ**] には、分析対象として最も頻繁に使用されるクエリの数 (1 ～ 100) を入力します。
+ [**統計ユーザーを選択**] では、クエリ統計を分析したいデータベースユーザーを選択します。
また、[**最適化戦略**」タブでは、[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブルの最小行数と最大行数を入力して、それを小さなテーブルと見なします。 は`ALL`分散スタイルを小さなテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
# Vertica データベース AWS Schema Conversion Tool への の接続
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 への接続
以下の手順を使用して、Vertica ソースデータベースを AWS Schema Conversion Toolに接続します。
**Vertica ソースデータベースに接続するには**
1. で AWS Schema Conversion Tool、**ソースの追加**を選択します。
1. [**Vertica**] を選択し、その後 [**Next**] (次へ) を選択します。
[**Add source**] (ソースの追加) ダイアログボックスが表示されます。
1. [**接続名**] にデータベースの名前を入力します。この名前が AWS SCT の左側のパネルのツリーに表示されます。
1. からデータベース認証情報を使用する AWS Secrets Manager か、手動で入力します。
+ Secrets Manager のデータベース認証情報を使用するには、以下の手順に従ってください。
1. [**AWS シークレット**] で、シークレットの名前を選択します。
1. [**入力**] を選択すると、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/ja_jp/SchemaConversionTool/latest/userguide/CHAP_Source.Vertica.html)
1. **接続のテスト**を選択して、 がソースデータベースに接続 AWS SCT できることを確認します。
1. [**Connect**] (接続) を選択して、ソースデータベースに接続します。
## 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 には、クラスターノードタイプの使用を制限するクォータがあります。**Auto** を選択した場合、 はノードタイプに応じてターゲット 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 の別のテーブルに移行するには。そのためには、[**UNION ALL ビューを使用する**] を選択し、 AWS SCT が 1 つのソーステーブルに対して作成できるターゲットテーブルの最大数を入力します。
Amazon Redshift は、テーブルのパーティションをサポートしていません。この動作をエミュレートしてクエリの実行を高速化するには、ソーステーブルの各パーティションを Amazon Redshift の別のテーブル AWS SCT に移行できます。次に、 はこれらのすべてのテーブルのデータを含むビュー AWS SCT を作成します。
AWS SCT は、ソーステーブル内のパーティションの数を自動的に決定します。ソーステーブルパーティショニングのタイプによっては、この数は Amazon Redshift クラスターに適用できるテーブルのクォータを超える場合があります。このクォータに達しないようにするには、単一のソーステーブルのパーティションに対して が作成 AWS SCT できるターゲットテーブルの最大数を入力します。デフォルトのオプションは 368 テーブルで、これは 1 年 366 日のパーティションと、`NO RANGE` および `UNKNOWN` パーティションの 2 つのテーブルを表します。
+ Amazon Redshift テーブルの列に圧縮を適用します。そのためには、[**圧縮エンコードを使用**] を選択します。
AWS SCT は、デフォルトの Amazon Redshift アルゴリズムを使用して、圧縮エンコーディングを列に自動的に割り当てます。詳細については、『*Amazon Redshift データベースデベロッパーガイド*』の「[圧縮エンコード](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html)」を参照してください。
デフォルトでは、Amazon Redshift はソートキーと分散キーとして定義されている列に圧縮を適用しません。この動作を変更したり、これらの列に圧縮を適用したりできます。そのためには、[**KEY 列には圧縮エンコードを使用**] を選択します。このオプションは、[**圧縮エンコードを使用**] オプションを選択した場合にのみ選択できます。
## Vertica から Amazon Redshift への変換最適化設定
Vertica から Amazon Redshift への変換最適化設定を編集するには、**「 の設定**」を選択し AWS SCT、**「変換設定**」を選択します。上のリストから [**Vertica**] を選択し、次に [**Vertica – Amazon Redshift**] を選択します。左側のペインで、**最適化 strategies**. AWS SCT displays conversion Optimization settings for Vertica to Amazon Redshift conversion を選択します。
の Vertica から Amazon Redshift への変換最適化設定 AWS SCT には、以下のオプションが含まれています。
+ 自動テーブル最適化を使用するには。そのためには、[**Amazon Redshift の自動テーブルチューニングを使用する**] を選択します。
自動テーブル最適化は、テーブルの設計を自動的に最適化する Amazon Redshift の自己調整プロセスです。詳細については、『*Amazon Redshift データベース開発者ガイド*』の「[自動テーブル最適化の操作](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html)」を参照してください。
自動テーブル最適化のみを利用するには、[**初期キー選択戦略**] で [**なし**] を選択します。
+ 戦略を使用してソートキーと分散キーを選択するには。
Amazon Redshift メタデータ、統計情報、またはこれらのオプションの両方を使用して、ソートキーと配布キーを選択できます。[**最適化戦略**] タブの [**初期キー選択戦略**] では、以下のいずれかのオプションを選択します。
+ メタデータを使用し、統計情報は無視する
+ メタデータを無視し、統計情報を使用する
+ メタデータと統計情報を使用する
選択したオプションに応じて、最適化戦略を選択できます。次に、各戦略について、値 (0～100) を入力します。これらの値は各戦略の重みを定義します。これらの重み値を使用して、 AWS SCT は各ルールがディストリビューションキーとソートキーの選択にどのように影響するかを定義します。デフォルト値は、 AWS 移行のベストプラクティスに基づいています。
[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブルの最小行数と最大行数を入力して、スモールテーブルとして定義します。 は`ALL`、分散スタイルをスモールテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。
+ 戦略の詳細を設定するには。
各最適化戦略の重みを定義することに加えて、最適化設定を構成できます。そのためには、[**変換の最適化**] を選択します。
+ [**ソートキー列の制限**] には、ソートキーの列の最大数を入力します。
+ **歪んだしきい値**には、列の歪んだ値の割合 (0～100) を入力します。分散キーの候補リストから、歪んだ値がしきい値より大きい列 AWS SCT を除外します。 は、列の歪んだ値を、レコードの合計数に対する最も一般的な値の出現回数の割合として AWS SCT 定義します。
+ [**クエリ履歴テーブルの上位 N 件のクエリ**] には、分析対象として最も頻繁に使用されるクエリの数 (1 ～ 100) を入力します。
+ [**統計ユーザーを選択**] では、クエリ統計を分析したいデータベースユーザーを選択します。
また、[**最適化戦略**」タブでは、[**小さいテーブルを検索**] 戦略の小さいテーブルのサイズを定義できます。**最小テーブル行数**と**最大テーブル行数**には、テーブル内の最小行数と最大行数を入力して、それを小さなテーブルと見なします。 は`ALL`分散スタイルを小さなテーブル AWS SCT に適用します。この場合は、テーブル全体のコピーがすべてのノードに分散されます。