`.
Vous trouverez des exemples dans le tableau ci-dessous.
| Instruction Oracle | Instruction 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;
|
# Migration d'une base de données Oracle vers Amazon RDS for Oracle avec AWS Schema Conversion Tool
Éléments à prendre en compte lors de la migration d'un schéma et de code Oracle vers Amazon RDS pourOracle :
+ AWS SCT peut ajouter des objets de répertoire à l'arborescence des objets. Les *objets de répertoire* sont des structures logiques qui représentent chacune un répertoire physique sur le système de fichiers du serveur. Vous pouvez utiliser des objets de répertoire avec les packages tels que DBMS\$1LOB, UTL\$1FILE, DBMS\$1FILE\$1TRANSFER, l'utilitaire DATAPUMP, et ainsi de suite.
+ AWS SCT prend en charge la conversion des tablespaces Oracle en une instance de base de données Amazon RDS for Oracle. Oracle stocke les données logiquement dans les espaces de table et physiquement dans les fichiers de données associés à l'espace de table correspondant. Dans Oracle, vous pouvez créer des espaces de table avec des noms de fichier de données. Amazon RDS prend en charge Oracle Managed Files (OMF) pour les fichiers de données, les fichiers journaux et les fichiers de contrôle uniquement. AWS SCT crée les fichiers de données nécessaires lors de la conversion.
+ AWS SCT peut convertir les rôles et les privilèges au niveau du serveur. Le moteur de base de données Oracle utilise une sécurité basée sur le rôle. Un rôle est un ensemble de privilèges que vous pouvez accorder ou révoquer à un utilisateur. Un rôle prédéfini dans Amazon RDS, appelé DBA, autorise normalement tous les privilèges d'administration sur un moteur de base de données Oracle. Les privilèges suivants ne sont pas disponibles pour le rôle DBA sur une instance de base de données Amazon RDS en utilisant le moteur Oracle :
+ Alter database
+ Alter system
+ Create any directory
+ Grant any privilege
+ Grant any role
+ Create external job
Vous pouvez accorder tous les autres privilèges à un rôle d'utilisateur Amazon RDS pour Oracle, y compris les privilèges de filtrage avancés et de colonne.
+ AWS SCT prend en charge la conversion de tâches Oracle en tâches pouvant être exécutées sur Amazon RDS for Oracle. Quelques limitations s'appliquent à la conversion, notamment :
+ Les tâches exécutables ne sont pas prises en charge.
+ Les tâches de planification qui utilisent le type de données ANYDATA comme argument ne sont pas prises en charge.
+ Oracle Real Application Clusters (RAC) One Node est une option pour Oracle Database Enterprise Edition qui a été introduite avec Oracle Database 11g version 2. Amazon RDS pour Oracle ne prend pas en charge la fonction RAC. Pour un haut niveau de disponibilité, utilisez multi-AZ Amazon RDS.
Dans un déploiement multi-AZ, Amazon RDS fournit et maintient automatiquement un réplica de secours synchrone dans une autre zone de disponibilité. L'instance de base de données principale est répliquée de manière synchrone entre les zones de disponibilité et un réplica de secours. Cette fonctionnalité assure la redondance des données, élimine les I/O blocages et minimise les pics de latence lors des sauvegardes du système.
+ Oracle Spatial fournit un schéma SQL et des fonctions qui facilitent le stockage, la récupération, la mise à jour et la requête de collections de données spatiales dans une base de données Oracle. Oracle Locator fournit des capacités généralement requises pour prendre en charge les applications basées sur des services sans fil et sur Internet, ainsi que les solutions GIS basées sur le partenariat. Oracle Locator est un sous-ensemble limité d'Oracle Spatial.
Pour utiliser les fonctionnalités Oracle Spatial et Oracle Locator, ajoutez l'option SPATIAL ou LOCATOR (mutuellement exclusives) au groupe d'options de votre instance de base de données.
Il existe certains prérequis pour utiliser Oracle Spatial et Oracle Locator sur une instance de base de données Amazon RDS pour Oracle :
+ L'instance doit utiliser Oracle Enterprise Edition version 12.1.0.2.v6 ou supérieure, ou 11.2.0.4.v10 ou supérieure.
+ Votre instance doit être dans un VPC (cloud privé virtuel).
+ L'instance doit être la classe d'instance de base de données qui peut prendre en charge la fonctionnalité Oracle. Par exemple, Oracle Spatial n'est pas pris en charge pour les classes d'instance de base de données db.m1.small, db.t1.micro, db.t2.micro ou db.t2.small. Pour plus d'informations, consultez la section [Support des classes d'instance de base de données pour Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html#Oracle.Concepts.InstanceClasses).
+ L'option Mise à niveau automatique de versions mineures doit être activée pour l'instance. Amazon RDS met à jour votre instance de base de données vers le PSU Oracle le plus récent en cas de vulnérabilités de sécurité présentant un score CVSS égal ou supérieur à 9, ou d'autres vulnérabilités de sécurité annoncées. Pour plus d’informations, veuillez consulter la rubrique
[Paramètres pour les instances de base de données Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ModifyInstance.Oracle.html#USER_ModifyInstance.Oracle.Settings).
+ Si votre instance de base de données est de version 11.2.0.4.v10 ou supérieure, vous devez installer l'option XMLDB. Pour plus d’informations, veuillez consulter la rubrique
Base de [données XML Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.XMLDB.html).
+ Vous devez disposer d'une licence Oracle Spatial fournie par Oracle. Pour plus d'informations, consultez [Oracle Spatial et Graph](https://shop.oracle.com/apex/product?p1=OracleSpatialandGraph) dans la documentation d'Oracle.
+ Data Guard est inclus avec Oracle Database Enterprise Edition. Pour un haut niveau de disponibilité, utilisez la fonction multi-AZ Amazon RDS.
Dans un déploiement multi-AZ, Amazon RDS fournit et maintient automatiquement un réplica de secours synchrone dans une autre zone de disponibilité. L'instance de base de données principale est répliquée de manière synchrone entre les zones de disponibilité et un réplica de secours. Cette fonctionnalité assure la redondance des données, élimine les I/O blocages et minimise les pics de latence lors des sauvegardes du système.
+ AWS SCT prend en charge la conversion des objets Oracle DBMS\$1SCHEDULER lors de la migration vers Amazon RDS for Oracle. Le rapport AWS SCT d'évaluation indique si un objet de planification peut être converti. Pour plus d'informations sur l'utilisation des objets de planification avec Amazon RDS, consultez la [documentation Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.System.html#Appendix.Oracle.CommonDBATasks.ModifyScheduler).
+ Pour les conversions d'Oracle vers Amazon RDS pour Oracle, les liens de base de données sont pris en charge. Un lien de base de données est un objet de schéma dans une base de données qui vous permet d'accéder aux objets d'une autre base de données. L'autre base de données ne doit pas nécessairement être une base de données Oracle. Toutefois, pour accéder aux bases de données autres qu'Oracle, vous devez utiliser Oracle Heterogeneous Services.
Une fois que vous avez créé un lien de base de données, vous pouvez l'utiliser dans les instructions SQL pour faire référence aux tables, aux vues et aux PL/SQL objets de l'autre base de données. Pour utiliser un lien de base de données, ajoutez-le `@dblink` au nom de la table, de la vue ou de PL/SQL l'objet. Vous pouvez interroger une table ou une vue dans l'autre base de données avec l'instruction SELECT. Pour plus d'informations sur l'utilisation des liens de base de données Oracle, consultez la [documentation Oracle](https://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts002.htm#ADMIN12083).
Pour plus d'informations sur l'utilisation des liens de base de données avec AMazon RDS, consultez la [documentation Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.Database.html#Appendix.Oracle.CommonDBATasks.DBLinks).
+ Le rapport AWS SCT d'évaluation fournit les indicateurs du serveur pour la conversion. Ces metrics sur votre instance Oracle sont les suivantes :
+ Capacité de calcul et de mémoire de l'instance de base de données cible.
+ Fonctionnalités Oracle non prises en charge, telles que Real Application Clusters, qu'Amazon RDS ne prend pas en charge.
+ Charge de travail en lecture/écriture sur disque
+ Total moyen du débit de disque
+ Les informations du serveur telles que le nom du serveur, le nom d'hôte, le système d'exploitation et le jeu de caractères.
## Privilèges accordés à RDS for Oracle en tant que cible
Pour migrer vers Amazon RDS for Oracle, créez un utilisateur de base de données privilégié. Vous pouvez utiliser l'exemple de code suivant.
```
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;
```
Dans l'exemple précédent, remplacez *user\$1name* par le nom de votre utilisateur. Remplacez-le ensuite *your\$1password* par un mot de passe sécurisé.
## Limitations lors de la conversion d'Oracle vers Amazon RDS for Oracle
Quelques éléments à prendre en compte lors de la migration d'un schéma Oracle et d'un code vers Amazon RDS pour Oracle :
+ Un rôle prédéfini dans Amazon RDS, appelé DBA, autorise normalement tous les privilèges d'administration sur un moteur de base de données Oracle. Les privilèges suivants ne sont pas disponibles pour le rôle DBA sur une instance de base de données Amazon RDS en utilisant le moteur Oracle :
+ Alter database
+ Alter system
+ Create any directory
+ Grant any privilege
+ Grant any role
+ Create external job
Vous pouvez accorder tous les autres privilèges à un rôle d'utilisateur Oracle RDS.
+ Amazon RDS for Oracle prend en charge l'audit traditionnel, l'audit détaillé à l'aide du package DBMS\$1FGA et Oracle Unified Auditing.
+ Amazon RDS pour Oracle ne prend pas en charge la capture des données modifiées (CDC). Pour effectuer le CDC pendant et après une migration de base de données, utilisez AWS Database Migration Service.
# Connexion aux bases de données PostgreSQL à l'aide du AWS Schema Conversion Tool
Vous pouvez les utiliser AWS SCT pour convertir des schémas, des objets de code de base de données et du code d'application de PostgreSQL vers les cibles suivantes :
+ Amazon RDS for MySQL
+ Amazon Aurora MySQL-Compatible Edition
+ Amazon RDS pour PostgreSQL
+ Amazon Aurora PostgreSQL-Compatible Edition
Pour plus d’informations, consultez les sections suivantes :
**Topics**
+ [Privilèges pour PostgreSQL en tant que base de données source](#CHAP_Source.PostgreSQL.Permissions)
+ [Connexion à PostgreSQL en tant que source](#CHAP_Source.PostgreSQL.Connecting)
+ [Privilèges pour MySQL en tant que base de données cible](#CHAP_Source.PostgreSQL.ConfigureMySQL)
## Privilèges pour PostgreSQL en tant que base de données source
Les privilèges requis pour PostgreSQL en tant que source sont les suivants :
+ CONNEXION À LA BASE DE DONNÉES **
+ UTILISATION SUR LE SCHÉMA **
+ SÉLECTIONNEZ SUR TOUTES LES TABLES DU SCHÉMA **
+ SÉLECTIONNEZ TOUTES LES SÉQUENCES DU SCHÉMA **
## Connexion à PostgreSQL en tant que source
Utilisez la procédure suivante pour vous connecter à votre base de données source PostgreSQL avec AWS Schema Conversion Tool.
**Pour vous connecter à une base de données source PostgreSQL**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. **Choisissez **PostgreSQL**, puis Next.**
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement :
+ Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes :
1. Pour **AWS Secret**, choisissez le nom du secret.
1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager.
Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Pour saisir manuellement les informations de connexion à la base de données source PostgreSQL, suivez les instructions suivantes :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.PostgreSQL.html)
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source.
1. Choisissez **Connect pour vous** connecter à votre base de données source.
## Privilèges pour MySQL en tant que base de données cible
Les privilèges requis pour MySQL en tant que cible lors de la migration depuis PostgreSQL sont les suivants :
+ CRÉER SUR\$1 . \$1
+ MODIFIER \$1 . \$1
+ DÉPOSEZ \$1 . \$1
+ INDEX SUR \$1 . \$1
+ RÉFÉRENCES SUR\$1 . \$1
+ SELECT ON \$1.\$1
+ CRÉER UNE VUE SUR \$1 . \$1
+ SHOW VIEW ON \$1.\$1
+ DÉCLENCHEUR ACTIVÉ\$1 . \$1
+ CRÉER UNE ROUTINE SUR\$1 . \$1
+ MODIFIER LA ROUTINE SUR \$1 . \$1
+ EXÉCUTER SUR\$1 . \$1
+ INSÉRER, METTRE À JOUR SUR AWS\$1POSTGRESQL \$1EXT. \$1
+ INSÉREZ, METTEZ À JOUR, SUPPRIMEZ SUR AWS\$1POSTGRESQL \$1EXT\$1DATA. \$1
+ CRÉEZ DES TABLES TEMPORAIRES SUR AWS\$1POSTGRESQL \$1EXT\$1DATA. \$1
Vous pouvez utiliser l’exemple de code suivant pour créer un utilisateur de base de données et accorder les privilèges.
```
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';
```
Dans l'exemple précédent, remplacez *user\$1name* par le nom de votre utilisateur. Remplacez-le ensuite *your\$1password* par un mot de passe sécurisé.
Pour utiliser Amazon RDS for MySQL ou Aurora MySQL en tant que cible, définissez le paramètre `lower_case_table_names` sur `1`. Cette valeur signifie que le serveur MySQL traite les identifiants des noms d’objets tels que les tables, les index, les déclencheurs et les bases de données sans distinction entre majuscules et minuscules. Si vous avez activé la journalisation binaire dans votre instance cible, définissez le paramètre `log_bin_trust_function_creators` sur `1`. Dans ce cas, vous n’avez pas besoin d’utiliser les caractéristiques `DETERMINISTIC`, `READS SQL DATA` ni `NO SQL` pour créer des fonctions stockées. Pour configurer ces paramètres, créez un nouveau groupe de paramètres de base de données ou modifiez un groupe de paramètres de base de données existant.
# Connexion aux bases de données SAP à l'aide du AWS Schema Conversion Tool
Vous pouvez les utiliser AWS SCT pour convertir les schémas, les objets de code de base de données et le code d'application de SAP (Sybase) Adaptive Server Enterprise (ASE) vers les cibles suivantes :
+ Amazon RDS for MySQL
+ Amazon Aurora MySQL-Compatible Edition
+ Amazon RDS for MariaDB
+ Amazon RDS pour PostgreSQL
+ Amazon Aurora PostgreSQL-Compatible Edition
Pour plus d’informations, consultez les sections suivantes :
**Topics**
+ [Privilèges pour SAP ASE en tant que base de données source](#CHAP_Source.SAP.Permissions)
+ [Connexion à SAP ASE (Sybase) en tant que source](#CHAP_Source.SAP.Connecting)
+ [Privilèges pour MySQL en tant que base de données cible](#CHAP_Source.SAP.ConfigureMySQL)
+ [Paramètres de conversion SAP ASE vers MySQL](#CHAP_Source.SAP.MySQLConversionSettings)
+ [Privilèges pour PostgreSQL en tant que base de données cible](#CHAP_Source.SAP.ConfigurePostgreSQL)
+ [Paramètres de conversion de SAP ASE vers PostgreSQL](#CHAP_Source.SAP.PostgreSQLConversionSettings)
## Privilèges pour SAP ASE en tant que base de données source
Pour utiliser une base de données SAP ASE comme source, vous devez créer un utilisateur de base de données et accorder des autorisations. Pour ce faire, suivez les étapes ci-dessous.
**Création et configuration d'un utilisateur de base de données**
1. Etablit une connexion à la base de données source.
1. Créez un utilisateur de base de données à l'aide des commandes suivantes. Entrez un mot de passe pour le nouvel utilisateur.
```
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. Pour chaque base de données que vous allez migrer, accordez les privilèges suivants.
```
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
```
## Connexion à SAP ASE (Sybase) en tant que source
Utilisez la procédure suivante pour vous connecter à votre base de données source SAP ASE avec le AWS Schema Conversion Tool.
**Pour vous connecter à une base de données source SAP ASE**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. Choisissez **SAP ASE**, puis **Next**.
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement :
+ Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes :
1. Pour **AWS Secret**, choisissez le nom du secret.
1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager.
Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Pour saisir manuellement les informations de connexion à la base de données source SAP ASE, suivez les instructions suivantes :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.SAP.html)
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source.
1. Choisissez **Connect pour vous** connecter à votre base de données source.
## Privilèges pour MySQL en tant que base de données cible
Les privilèges requis pour MySQL en tant que cible sont les suivants :
+ CRÉER SUR\$1 . \$1
+ MODIFIER \$1 . \$1
+ DÉPOSEZ \$1 . \$1
+ INDEX SUR \$1 . \$1
+ RÉFÉRENCES SUR\$1 . \$1
+ SELECT ON \$1.\$1
+ CRÉER UNE VUE SUR \$1 . \$1
+ SHOW VIEW ON \$1.\$1
+ DÉCLENCHEUR ACTIVÉ\$1 . \$1
+ CRÉER UNE ROUTINE SUR\$1 . \$1
+ MODIFIER LA ROUTINE SUR \$1 . \$1
+ EXÉCUTER SUR\$1 . \$1
+ INSÉRER, METTRE À JOUR SUR AWS\$1SAPASE \$1EXT. \$1
+ CRÉEZ DES TABLES TEMPORAIRES SUR AWS\$1SAPASE \$1EXT. \$1
Vous pouvez utiliser l’exemple de code suivant pour créer un utilisateur de base de données et accorder les privilèges.
```
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';
```
Dans l'exemple précédent, remplacez *user\$1name* par le nom de votre utilisateur. Remplacez-le ensuite *your\$1password* par un mot de passe sécurisé.
Pour utiliser Amazon RDS for MySQL ou Aurora MySQL en tant que cible, définissez le paramètre `lower_case_table_names` sur `1`. Cette valeur signifie que le serveur MySQL traite les identifiants des noms d’objets tels que les tables, les index, les déclencheurs et les bases de données sans distinction entre majuscules et minuscules. Si vous avez activé la journalisation binaire dans votre instance cible, définissez le paramètre `log_bin_trust_function_creators` sur `1`. Dans ce cas, vous n’avez pas besoin d’utiliser les caractéristiques `DETERMINISTIC`, `READS SQL DATA` ni `NO SQL` pour créer des fonctions stockées. Pour configurer ces paramètres, créez un nouveau groupe de paramètres de base de données ou modifiez un groupe de paramètres de base de données existant.
## Paramètres de conversion SAP ASE vers MySQL
Pour modifier les paramètres de conversion SAP ASE vers MySQL, choisissez **Paramètres**, puis **Paramètres de conversion**. Dans la liste supérieure, choisissez **SAP ASE**, puis **SAP ASE — MySQL** ou **SAP ASE — Amazon Aurora (compatible avec MySQL)**. AWS SCT affiche tous les paramètres disponibles pour la conversion de SAP ASE vers PostgreSQL.
Les paramètres de conversion de SAP ASE vers MySQL AWS SCT incluent des options pour les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour utiliser les noms exacts des objets de base de données source dans le code converti.
Par défaut, AWS SCT convertit les noms des objets, des variables et des paramètres de base de données en minuscules. Pour conserver les majuscules et minuscules d'origine de ces noms, sélectionnez **Traiter les noms des objets de base de données source en distinguant les majuscules et minuscules**. Choisissez cette option si vous utilisez des noms d'objets distinguant majuscules et minuscules dans votre serveur de base de données SAP ASE source.
## Privilèges pour PostgreSQL en tant que base de données cible
Pour utiliser PostgreSQL comme cible AWS SCT , le privilège est requis. `CREATE ON DATABASE` Assurez-vous d'accorder ce privilège à chaque base de données PostgreSQL cible.
Pour utiliser les synonymes publics convertis, remplacez le chemin de recherche par défaut de la base de données par`"$user", public_synonyms, public`.
Vous pouvez utiliser l’exemple de code suivant pour créer un utilisateur de base de données et accorder les privilèges.
```
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;
```
Dans l'exemple précédent, remplacez *user\$1name* par le nom de votre utilisateur. Remplacez ensuite *db\$1name* par le nom de votre base de données cible. Enfin, remplacez-le *your\$1password* par un mot de passe sécurisé.
Dans PostgreSQL, seul le propriétaire du schéma ou un `superuser` peut supprimer un schéma. Le propriétaire peut supprimer un schéma et tous les objets qu'il inclut même si le propriétaire du schéma ne possède pas certains de ses objets.
Lorsque vous utilisez différents utilisateurs pour convertir et appliquer différents schémas à votre base de données cible, un message d'erreur peut s'afficher lorsque vous ne AWS SCT pouvez pas supprimer un schéma. Pour éviter ce message d’erreur, utilisez le rôle `superuser`.
## Paramètres de conversion de SAP ASE vers PostgreSQL
**Pour modifier les paramètres de conversion de SAP ASE vers PostgreSQL, **choisissez** Paramètres, puis Paramètres de conversion.** Dans la liste supérieure, choisissez **SAP ASE**, puis SAP ASE **— PostgreSQL ou SAP ASE —** **Amazon Aurora (**compatible avec PostgreSQL). AWS SCT affiche tous les paramètres disponibles pour la conversion de SAP ASE vers PostgreSQL.
Les paramètres de conversion de SAP ASE vers PostgreSQL incluent des options pour AWS SCT les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour définir le modèle à utiliser pour les noms de schéma dans le code converti. Pour **le modèle de génération de nom de schéma**, choisissez l'une des options suivantes :
+ ****— Utilise le nom de base de données SAP ASE comme nom de schéma dans PostgreSQL.
+ ****— Utilise le nom du schéma SAP ASE comme nom de schéma dans PostgreSQL.
+ **\$1** — Utilise une combinaison de la base de données SAP ASE et des noms de schéma comme nom de schéma dans PostgreSQL.
+ Pour utiliser les noms exacts des objets de base de données source dans le code converti.
Par défaut, AWS SCT convertit les noms des objets, des variables et des paramètres de base de données en minuscules. Pour conserver les majuscules et minuscules d'origine de ces noms, sélectionnez **Traiter les noms des objets de base de données source en distinguant les majuscules et minuscules**. Choisissez cette option si vous utilisez des noms d'objets distinguant majuscules et minuscules dans votre serveur de base de données SAP ASE source.
Pour les opérations distinguant majuscules et minuscules, AWS SCT vous pouvez éviter la conversion des noms d'objets de base de données en minuscules. Pour ce faire, sélectionnez **Éviter de convertir en minuscules pour les opérations sensibles aux majuscules et minuscules**.
+ Permettre l'utilisation d'index portant le même nom dans différentes tables dans SAP ASE.
Dans PostgreSQL, tous les noms d'index que vous utilisez dans le schéma doivent être uniques. Pour vous assurer que cela AWS SCT génère des noms uniques pour tous vos index, sélectionnez **Générer des noms uniques pour les index**.
# Connect Microsoft SQL Server avec AWS Schema Conversion Tool
Vous pouvez l'utiliser AWS SCT pour convertir des schémas, des objets de code de base de données et du code d'application de SQL Server vers les cibles suivantes :
+ Amazon RDS for MySQL
+ Amazon Aurora MySQL-Compatible Edition
+ Amazon RDS pour PostgreSQL
+ Amazon Aurora PostgreSQL-Compatible Edition
+ Amazon RDS for SQL Server
+ Amazon RDS for MariaDB
**Note**
AWS SCT ne prend pas en charge l'utilisation d'Amazon RDS pour SQL Server en tant que source.
Vous pouvez l'utiliser AWS SCT pour créer un rapport d'évaluation pour la migration de schémas, d'objets de code de base de données et de code d'application de SQL Server vers Babelfish pour Aurora PostgreSQL, comme décrit ci-dessous.
**Topics**
+ [Privilèges pour Microsoft SQL Server en tant que source](#CHAP_Source.SQLServer.Permissions)
+ [Utilisation de l'authentification Windows lors de l'utilisation de Microsoft SQL Server comme source](#CHAP_Source.SQLServer.Permissions.WinAuth)
+ [Connexion à SQL Server en tant que source](#CHAP_Source.SQLServer.Connecting)
+ [Conversion de SQL Server en MySQL](CHAP_Source.SQLServer.ToMySQL.md)
+ [Migration de SQL Server vers PostgreSQL avec AWS Schema Conversion Tool](CHAP_Source.SQLServer.ToPostgreSQL.md)
+ [Migration de SQL Server vers Amazon RDS for SQL Server avec AWS Schema Conversion Tool](CHAP_Source.SQLServer.ToRDSSQLServer.md)
## Privilèges pour Microsoft SQL Server en tant que source
Les privilèges requis pour Microsoft SQL Server en tant que source sont les suivants :
+ VIEW DEFINITION
+ VIEW DATABASE STATE
Ce `VIEW DEFINITION` privilège permet aux utilisateurs disposant d'un accès public de consulter les définitions des objets. AWS SCT utilise le `VIEW DATABASE STATE` privilège pour vérifier les fonctionnalités de l'édition Enterprise de SQL Server.
Répétez l'octroi pour chaque base de données dont vous convertissez le schéma.
En outre, accordez les privilèges suivants sur la base de données `master` :
+ VIEW SERVER STATE
+ VIEW ANY DEFINITION
AWS SCT utilise le `VIEW SERVER STATE` privilège pour collecter les paramètres et la configuration du serveur. Assurez-vous d'accorder le `VIEW ANY DEFINITION` privilège d'afficher les points de terminaison.
Pour lire des informations sur Microsoft Analysis Services, exécutez la commande suivante sur la base de données `master`.
```
EXEC master..sp_addsrvrolemember @loginame = N'', @rolename = N'sysadmin'
```
Dans l'exemple précédent, remplacez l'``espace réservé par le nom de l'utilisateur auquel vous avez accordé les privilèges précédents.
Pour lire des informations sur l'agent SQL Server, ajoutez votre utilisateur au `SQLAgentUser` rôle. Exécutez la commande suivante sur la base de données `msdb`.
```
EXEC sp_addrolemember , ;
```
Dans l’exemple précédent, remplacez l’espace réservé `` par le nom du rôle SQL Server Agent. Remplacez ensuite l'``espace réservé par le nom de l'utilisateur auquel vous avez accordé les privilèges précédents. Pour plus d'informations, consultez la section [Ajouter un utilisateur au rôle SQLAgent d'utilisateur](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.SQLServer.CommonDBATasks.Agent.html#SQLServerAgent.AddUser) dans le *guide de l'utilisateur Amazon RDS*.
Pour détecter l’expédition de journaux, accordez le privilège `SELECT on dbo.log_shipping_primary_databases` sur la base de données `msdb`.
Pour utiliser l'approche de notification de la réplication DDL, accordez le `RECEIVE ON .` privilège sur vos bases de données sources. Dans cet exemple, remplacez l’espace réservé `` par le nom du schéma de la base de données. Remplacez ensuite l’espace réservé `` par le nom d’une table de file d’attente.
## Utilisation de l'authentification Windows lors de l'utilisation de Microsoft SQL Server comme source
Si votre application s'exécute sur un intranet Windows, vous pouvez utiliser l'authentification Windows pour accéder à la base de données. L'authentification Windows utilise l'identité Windows actuelle établie sur le thread du système d'exploitation pour accéder à la base de données SQL Server. Vous pouvez ensuite faire correspondre l'identité Windows à une base de données et à des permissions SQL Server. Pour vous connecter à SQL Server à l'aide de l'authentification Windows, vous devez spécifier l'identité Windows qu'utilise votre application. Vous devez également accorder l'accès à l'identité Windows à la base de données SQL Server.
SQL Server possède deux modes d'accès : le mode d'authentification Windows et le mode mixte. Le mode d'authentification Windows active l'authentification Windows et désactive l'authentification SQL Server. Le mode mixte active à la fois l'authentification Windows et l'authentification SQL Server. L'authentification Windows est toujours disponible et ne peut pas être désactivée. Pour plus d'informations sur l'authentification Windows, consultez la documentation Microsoft Windows.
L'exemple ci-dessous illustre un moyen de créer un utilisateur dans TEST\$1DB.
```
USE [TEST_DB]
CREATE USER [TestUser] FOR LOGIN [TestDomain\TestUser]
GRANT VIEW DEFINITION TO [TestUser]
GRANT VIEW DATABASE STATE TO [TestUser]
```
### Utilisation de l'authentification Windows avec une connexion JDBC
Le pilote JDBC ne prend pas en charge l'authentification Windows lorsque le pilote est utilisé sur des systèmes d'exploitation autres que Windows. Les informations d'authentification Windows, telles que le nom d'utilisateur et le mot de passe, ne sont pas spécifiées automatiquement lors de la connexion à SQL Server à partir de systèmes d'exploitation autres que Windows. Dans ce cas, les applications doivent plutôt utiliser l'authentification SQL Server.
Dans la chaîne de connexion JDBC, le paramètre `integratedSecurity` doit être spécifié pour se connecter à l'aide de l'authentification Windows. Le pilote JDBC prend en charge l'authentification Windows intégrée sur les systèmes d'exploitation Windows via le paramètre de chaîne de connexion `integratedSecurity`.
Pour utiliser l'authentification intégrée
1. Installez le pilote JDBC.
1. Copiez le fichier `sqljdbc_auth.dll` dans un répertoire sur le chemin d'accès système Windows sur l'ordinateur où le pilote JDBC est installé.
Les `sqljdbc_auth.dll` fichiers sont installés à l'emplacement suivant :
<*répertoire d'installation*>\$1sqljdbc\$1<*version*>\$1<*language*>\$1auth\$1
Lorsque vous essayez d'établir une connexion à la base de données SQL Server à l'aide de l'authentification Windows, vous pouvez obtenir l'erreur suivante : Ce pilote n'est pas configuré pour l'authentification intégrée. Ce problème peut être résolu à l'aide des actions suivantes :
+ Déclaration de deux variables qui pointent vers le chemin d'accès de votre installation JDBC :
`variable name: SQLJDBC_HOME; variable value: D:\lib\JDBC4.1\enu`(où se trouve votre fichier sqljdbc4.jar) ;
`variable name: SQLJDBC_AUTH_HOME; variable value: D\lib\JDBC4.1\enu\auth\x86`(si vous utilisez un système d'exploitation 32 bits) ou `D\lib\JDBC4.1\enu\auth\x64` (si vous utilisez un système d'exploitation 64 bits). C'est ici que se `sqljdbc_auth.dll` trouve le vôtre.
+ Copiez `sqljdbc_auth.dll` dans le dossier dans lequel vous êtes JDK/JRE en cours d'exécution. Vous pouvez effectuer la copie vers le dossier lib, dans le dossier Bin, etc. Par exemple, vous pouvez copier le fichier dans le dossier suivant.
```
[JDK_INSTALLED_PATH]\bin;
[JDK_INSTALLED_PATH]\jre\bin;
[JDK_INSTALLED_PATH]\jre\lib;
[JDK_INSTALLED_PATH]\lib;
```
+ Assurez-vous que le dossier de votre bibliothèque JDBC ne contient que le SQLJDBC4 fichier .jar. Supprimez tous les autres fichiers sqljdbc\$1.jar de ce dossier (ou copiez-les dans un autre dossier). Si vous ajoutez le pilote dans le cadre de votre programme, assurez-vous d'ajouter uniquement SQLJDBC4 .jar comme pilote à utiliser.
+ Copie du fichier sqljdbc\$1auth.dll dans le dossier contenant votre application.
**Note**
Si vous exécutez une machine virtuelle Java (JVM) 32 bits, utilisez le fichier sqljdbc\$1auth.dll situé dans le dossier x86, même si la version du système d'exploitation est x64. Si vous exécutez une machine virtuelle Java 64 bits sur un processeur x64, utilisez le fichier sqljdbc\$1auth.dll dans le dossier x64.
Lorsque vous vous connectez à une base de données SQL Server, vous pouvez choisir l'**authentification Windows** ou l'**authentification SQL Server** comme option d'**authentification**.
## Connexion à SQL Server en tant que source
Utilisez la procédure suivante pour vous connecter à une base de données source Microsoft SQL Server avec le AWS Schema Conversion Tool.
**Pour vous connecter à une base de données source Microsoft SQL Server**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. Choisissez **Microsoft SQL Server**, puis **Next**.
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement :
+ Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes :
1. Pour **AWS Secret**, choisissez le nom du secret.
1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager.
Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Pour saisir manuellement les informations de connexion à la base de données source Microsoft SQL Server, suivez les instructions suivantes :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServer.html)
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source.
1. Choisissez **Connect pour vous** connecter à votre base de données source.
# Conversion de SQL Server en MySQL
Pour émuler les fonctions de base de données Microsoft SQL Server dans votre code MySQL converti, utilisez le pack d'extension SQL Server vers MySQL intégré. AWS SCT Pour plus d’informations sur les packs d’extension, consultez [Utilisation de packs d'extension avec AWS Schema Conversion Tool](CHAP_ExtensionPack.md).
**Topics**
+ [Privilèges pour MySQL en tant que base de données cible](#CHAP_Source.SQLServer.ToMySQL.ConfigureTarget)
+ [Paramètres de conversion SQL Server vers MySQL](#CHAP_Source.SQLServer.ToMySQL.ConversionSettings)
+ [Considérations concernant la migration](#CHAP_Source.SQLServer.ToMySQL.MigrationConsiderations)
## Privilèges pour MySQL en tant que base de données cible
Les privilèges requis pour MySQL en tant que cible sont les suivants :
+ CRÉER SUR\$1 . \$1
+ MODIFIER \$1 . \$1
+ DÉPOSEZ \$1 . \$1
+ INDEX SUR \$1 . \$1
+ RÉFÉRENCES SUR\$1 . \$1
+ SELECT ON \$1.\$1
+ CRÉER UNE VUE SUR \$1 . \$1
+ SHOW VIEW ON \$1.\$1
+ DÉCLENCHEUR ACTIVÉ\$1 . \$1
+ CRÉER UNE ROUTINE SUR\$1 . \$1
+ MODIFIER LA ROUTINE SUR \$1 . \$1
+ EXÉCUTER SUR\$1 . \$1
+ INSÉRER, METTRE À JOUR SUR AWS\$1SQLSERVER \$1EXT. \$1
+ INSÉREZ, METTEZ À JOUR, SUPPRIMEZ SUR AWS\$1SQLSERVER \$1EXT\$1DATA. \$1
+ CRÉEZ DES TABLES TEMPORAIRES SUR AWS\$1SQLSERVER \$1EXT\$1DATA. \$1
Vous pouvez utiliser l’exemple de code suivant pour créer un utilisateur de base de données et accorder les privilèges.
```
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';
```
Dans l'exemple précédent, remplacez *user\$1name* par le nom de votre utilisateur. Remplacez-le ensuite *your\$1password* par un mot de passe sécurisé.
Si vous utilisez une base de données MySQL version 5.7 ou inférieure comme cible, exécutez la commande suivante. Pour les bases de données MySQL version 8.0 et supérieures, cette commande est obsolète.
```
GRANT SELECT ON mysql.proc TO 'user_name';
```
Pour utiliser Amazon RDS for MySQL ou Aurora MySQL en tant que cible, définissez le paramètre `lower_case_table_names` sur `1`. Cette valeur signifie que le serveur MySQL traite les identifiants des noms d’objets tels que les tables, les index, les déclencheurs et les bases de données sans distinction entre majuscules et minuscules. Si vous avez activé la journalisation binaire dans votre instance cible, définissez le paramètre `log_bin_trust_function_creators` sur `1`. Dans ce cas, vous n’avez pas besoin d’utiliser les caractéristiques `DETERMINISTIC`, `READS SQL DATA` ni `NO SQL` pour créer des fonctions stockées. Pour configurer ces paramètres, créez un nouveau groupe de paramètres de base de données ou modifiez un groupe de paramètres de base de données existant.
## Paramètres de conversion SQL Server vers MySQL
Pour modifier les paramètres de conversion de SQL Server vers MySQL, AWS SCT sélectionnez **Paramètres**, puis sélectionnez **Paramètres de conversion**. Dans la liste supérieure, choisissez **SQL Server**, puis **SQL Server — MySQL**. AWS SCT affiche tous les paramètres disponibles pour la conversion de SQL Server vers MySQL.
Les paramètres de conversion de SQL Server vers MySQL AWS SCT incluent des options pour les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour permettre à votre base de données SQL Server source de stocker le résultat de `EXEC` dans une table. AWS SCT crée des tables temporaires et une procédure supplémentaire pour émuler cette fonctionnalité. Pour utiliser cette émulation, sélectionnez **Créer des routines supplémentaires pour gérer les ensembles de données ouverts**.
## Considérations concernant la migration
Tenez compte des éléments suivants lors de la migration d'un schéma SQL Server vers MySQL :
+ MySQL ne supporte pas `MERGE` cette déclaration. Cependant, AWS SCT vous pouvez émuler l'`MERGE`instruction lors de la conversion en utilisant la `INSERT ON DUPLICATE KEY` clause et les `UPDATE FROM and DELETE FROM` instructions.
Pour une émulation correcte`INSERT ON DUPLICATE KEY`, assurez-vous qu'une contrainte ou une clé primaire unique existe sur la base de données MySQL cible.
+ Vous pouvez utiliser une `GOTO` instruction et une étiquette pour modifier l'ordre dans lequel les instructions sont exécutées. Toutes les instructions Transact-SQL qui suivent une `GOTO` instruction sont ignorées et le traitement se poursuit au niveau de l'étiquette. Vous pouvez utiliser `GOTO` des instructions et des étiquettes n'importe où dans une procédure, un lot ou un bloc d'instructions. Vous pouvez également imbriquer `GOTO` des relevés.
MySQL n'utilise pas d'`GOTO`instructions. Lors de la AWS SCT conversion du code contenant une `GOTO` instruction, il convertit l'instruction pour utiliser une `LOOP…END LOOP` instruction `BEGIN…END` or. Vous trouverez des exemples de AWS SCT conversion d'`GOTO`instructions dans le tableau suivant.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServer.ToMySQL.html)
+ MySQL ne prend pas en charge les fonctions multiinstructions à valeur de table. AWS SCT simule des fonctions basées sur des tables lors d'une conversion en créant des tables temporaires et en réécrivant des instructions pour utiliser ces tables temporaires.
# Migration de SQL Server vers PostgreSQL avec AWS Schema Conversion Tool
Vous pouvez utiliser le pack d'extension SQL Server vers PostgreSQL dans. AWS SCT Ce pack d'extension émule les fonctions de base de données SQL Server dans le code PostgreSQL converti. Utilisez le pack d'extension SQL Server vers PostgreSQL pour émuler SQL Server Agent et SQL Server Database Mail. Pour plus d’informations sur les packs d’extension, consultez [Utilisation de packs d'extension avec AWS Schema Conversion Tool](CHAP_ExtensionPack.md).
**Topics**
+ [Privilèges pour PostgreSQL en tant que base de données cible](#CHAP_Source.SQLServer.ToPostgreSQL.ConfigurePostgreSQL)
+ [Paramètres de conversion SQL Server vers PostgreSQL](#CHAP_Source.SQLServer.ToPostgreSQL.ConversionSettings)
+ [Conversion de partitions SQL Server en partitions PostgreSQL version 10](#CHAP_Source.SQLServer.ToPostgreSQL.PG10Partitions)
+ [Considérations concernant la migration](#CHAP_Source.SQLServer.ToPostgreSQL.MigrationConsiderations)
+ [Utilisation d'un pack d' AWS SCT extension pour émuler l'agent SQL Server dans PostgreSQL](CHAP_Source.SQLServer.ToPostgreSQL.ExtensionPack.Agent.md)
+ [Utilisation d'un pack d' AWS SCT extension pour émuler SQL Server Database Mail dans PostgreSQL](CHAP_Source.SQLServer.ToPostgreSQL.ExtensionPack.Mail.md)
## Privilèges pour PostgreSQL en tant que base de données cible
Pour utiliser PostgreSQL comme cible AWS SCT , le privilège est requis. `CREATE ON DATABASE` Assurez-vous d'accorder ce privilège à chaque base de données PostgreSQL cible.
Pour utiliser les synonymes publics convertis, remplacez le chemin de recherche par défaut de la base de données par`"$user", public_synonyms, public`.
Vous pouvez utiliser l’exemple de code suivant pour créer un utilisateur de base de données et accorder les privilèges.
```
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;
```
Dans l'exemple précédent, remplacez *user\$1name* par le nom de votre utilisateur. Remplacez ensuite *db\$1name* par le nom de votre base de données cible. Enfin, remplacez-le *your\$1password* par un mot de passe sécurisé.
Dans PostgreSQL, seul le propriétaire du schéma ou un `superuser` peut supprimer un schéma. Le propriétaire peut supprimer un schéma et tous les objets qu'il inclut même si le propriétaire du schéma ne possède pas certains de ses objets.
Lorsque vous utilisez différents utilisateurs pour convertir et appliquer différents schémas à votre base de données cible, un message d'erreur peut s'afficher lorsque vous ne AWS SCT pouvez pas supprimer un schéma. Pour éviter ce message d’erreur, utilisez le rôle `superuser`.
## Paramètres de conversion SQL Server vers PostgreSQL
**Pour modifier les paramètres de conversion de SQL Server vers PostgreSQL, **choisissez** Paramètres, puis Paramètres de conversion.** Dans la liste supérieure, choisissez **SQL Server**, puis **SQL Server — PostgreSQL**. AWS SCT affiche tous les paramètres disponibles pour la conversion de SQL Server vers PostgreSQL.
Les paramètres de conversion de SQL Server vers PostgreSQL incluent des options pour AWS SCT les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Permettre d'utiliser des index portant le même nom dans différentes tables de SQL Server.
Dans PostgreSQL, tous les noms d'index que vous utilisez dans le schéma doivent être uniques. Pour vous assurer que cela AWS SCT génère des noms uniques pour tous vos index, sélectionnez **Générer des noms uniques pour les index**.
+ Pour convertir les procédures SQL Server en fonctions PostgreSQL.
Les versions 10 et antérieures de PostgreSQL ne prennent pas en charge les procédures. Les clients qui ne sont pas habitués à utiliser les procédures dans PostgreSQL peuvent les convertir AWS SCT en fonctions. Pour ce faire, sélectionnez **Convertir les procédures en fonctions**.
+ Pour émuler la sortie de `EXEC` dans un tableau.
Votre base de données SQL Server source peut stocker le résultat de `EXEC` dans une table. AWS SCT crée des tables temporaires et une procédure supplémentaire pour émuler cette fonctionnalité. Pour utiliser cette émulation, sélectionnez **Créer des routines supplémentaires pour gérer les ensembles de données ouverts**.
+ Pour définir le modèle à utiliser pour les noms de schéma dans le code converti. Pour **le modèle de génération de nom de schéma**, choisissez l'une des options suivantes :
+ ****— Utilise le nom de base de données SQL Server comme nom de schéma dans PostgreSQL.
+ ****— Utilise le nom du schéma SQL Server comme nom de schéma dans PostgreSQL.
+ **\$1** — Utilise une combinaison de noms de schéma et de base de données SQL Server comme nom de schéma dans PostgreSQL.
+ Pour conserver les noms de vos objets source en majuscules.
Pour éviter de convertir les noms d'objets en minuscules, sélectionnez **Éviter de convertir les noms en minuscules pour les opérations faisant la distinction entre majuscules et minuscules**. Cette option s'applique uniquement lorsque vous activez la distinction majuscules/minuscules dans votre base de données cible.
+ Pour conserver les noms des paramètres dans votre base de données source.
Pour ajouter des guillemets doubles aux noms des paramètres dans le code converti, sélectionnez **Conserver les noms des paramètres d'origine**.
## Conversion de partitions SQL Server en partitions PostgreSQL version 10
Lorsque vous convertissez une base de données Microsoft SQL Server vers Amazon Aurora PostgreSQL Compatible Edition (Aurora PostgreSQL) ou Amazon Relational Database Service for PostgreSQL (Amazon RDS for PostgreSQL), tenez compte des points suivants.
Dans SQL Server, vous créez des partitions avec des fonctions de partition. Lorsque vous convertissez une table SQL Server divisée en portions en une table PostgreSQL version 10 divisée en portions, vous devez être conscient de plusieurs problèmes potentiels :
+ SQL Server vous permet de partitionner une table à l'aide d'une colonne sans contrainte NOT NULL. Dans ce cas, toutes les valeurs NULL sont dirigées vers la partition la plus à gauche. PostgreSQL ne prend pas en charge les valeurs NULL pour le partitionnement RANGE.
+ SQL Server vous permet de créer des clés primaires et uniques pour les tables partitionnées. Pour PostgreSQL, vous créez des clés primaires ou uniques pour chaque partition directement. Par conséquent, la contrainte PRIMARY ou UNIQUE KEY doit être supprimée de la table parent lors de la migration vers PostgreSQL. Les noms de clé qui en résultent prennent le format`_`.
+ SQL Server vous permet de créer une contrainte de clé étrangère à partir de et vers des tables partitionnées. PostgreSQL ne prend pas en charge les clés étrangères qui référencent des tables partitionnées. De plus, PostgreSQL ne prend pas en charge les références de clé étrangère à partir d'une table partitionnée vers une autre table.
+ SQL Server vous permet de créer des index pour les tables partitionnées. Pour PostgreSQL, un index doit être créé pour chaque partition directement. Par conséquent, les index doivent être supprimés des tables parents lors de la migration vers PostgreSQL. Les noms d'index qui en résultent sont au format `_`.
+ PostgreSQL ne prend pas en charge les index partitionnés.
## Considérations concernant la migration
Voici quelques points à prendre en compte lors de la migration d'un schéma SQL Server vers PostgreSQL :
+ Dans PostgreSQL, tous les noms des objets dans un schéma doivent être uniques, y compris les index. Les noms d'index doivent être uniques dans le schéma de la table de base. Dans SQL Server, un nom d'index peut être identique pour différentes tables.
Pour garantir l'unicité des noms d'index, vous AWS SCT donne la possibilité de générer des noms d'index uniques si vos noms d'index ne sont pas uniques. Pour cela, choisissez l'option **Generate unique index names (Générer des noms d'index uniques)** dans les propriétés du projet. Cette option est activée par défaut. Si cette option est activée, les noms d'index uniques sont créés au format IX\$1table\$1name\$1index\$1name. Si cette option est désactivée, les noms d'index ne sont pas modifiés.
+ Une instruction GOTO et une étiquette peuvent être utilisées pour modifier l'ordre dans lequel les instructions sont exécutées. Toutes les instructions Transact-SQL qui suivent une instruction GOTO sont ignorées et le traitement continue au niveau de l'étiquette. Les instructions GOTO et les étiquettes peuvent être utilisées à n'importe quel endroit dans une procédure, un lot ou un bloc d'instructions. Les instructions GOTO peuvent également être imbriquées.
PostgreSQL n'utilise pas les instructions GOTO. Lors de la AWS SCT conversion du code contenant une instruction GOTO, il convertit l'instruction pour utiliser une instruction BEGIN... END ou LOOP... END LOOP. Vous trouverez des exemples de AWS SCT conversion des instructions GOTO dans le tableau suivant.
**Instructions GOTO SQL Server et instructions PostgreSQL converties**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServer.ToPostgreSQL.html)
+ PostgreSQL ne prend pas en charge les instructions MERGE. AWS SCT émule le comportement d'une instruction MERGE de la manière suivante :
+ Par une construction INSERT ON CONFLICT.
+ En utilisant l'instruction UPDATE FROM DML, par exemple MERGE sans clause WHEN NOT MATCHED.
+ En utilisant une instruction CURSOR, par exemple avec une clause MERGE avec DELETE ou à l'aide d'une instruction de condition MERGE ON complexe.
+ AWS SCT peut ajouter des déclencheurs de base de données à l'arborescence d'objets lorsque Amazon RDS est la cible.
+ AWS SCT peut ajouter des déclencheurs au niveau du serveur à l'arborescence des objets lorsque Amazon RDS est la cible.
+ SQL Server crée et gère automatiquement `deleted` des `inserted` tables. Vous pouvez utiliser ces tables temporaires résidant en mémoire pour tester les effets de certaines modifications de données et pour définir les conditions des actions de déclenchement DML. AWS SCT peut convertir l'utilisation de ces tables dans des instructions de déclenchement DML.
+ AWS SCT peut ajouter des serveurs liés à l'arborescence des objets lorsque Amazon RDS est la cible.
+ Lors de la migration de Microsoft SQL Server vers PostgreSQL, la fonction SUSER\$1SNAME intégrée est convertie comme suit :
+ SUSER\$1SNAME – Renvoie le nom de connexion associé à un numéro d'identification de sécurité (SID).
+ SUSER\$1SNAME() – Non pris en charge.
+ SUSER\$1SNAME () CURRENT\$1USER – Renvoie le nom d'utilisateur du contexte d'exécution actuel.
+ SUSER\$1SNAME (NULL) - Renvoie NULL.
+ La conversion de fonctions avec valeurs de table est prise en charge. Les fonctions avec valeurs de table renvoient une table et peuvent remplacer une table dans une requête.
+ PATINDEX renvoie la position de départ de la première occurrence d'un modèle dans une expression spécifiée sur tous les types de données texte et caractère. Il renvoie des zéros si le modèle n'est pas trouvé. Lors de la conversion de SQL Server vers Amazon RDS for AWS SCT PostgreSQL, le code d'application qui utilise PATINDEX est remplacé par aws\$1sqlserver\$1ext.patindex (,).
+ Dans SQL Server, un type de table défini par l'utilisateur est un type qui représente la définition d'une structure de table. Vous utilisez un type de table défini par l'utilisateur afin de déclarer les paramètres de valeur de table pour les procédures ou fonctions stockées. Vous pouvez également utiliser un type de table défini par l'utilisateur pour déclarer les variables de table que vous souhaitez utiliser dans un lot ou dans le corps d'une procédure stockée ou d'une fonction. AWS SCT a émulé ce type dans PostgreSQL en créant une table temporaire.
Lors de la conversion de SQL Server vers PostgreSQL AWS SCT , les objets système SQL Server sont convertis en objets reconnaissables dans PostgreSQL. Le tableau suivant montre la façon dont les objets système sont convertis.
| Cas d'utilisation de MS SQL Server | Substitution par 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\$1SQLSERVERCLÉS ÉTRANGÈRES \$1EXT.SYS\$1SYS |
| 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\$1INDEX |
| 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\$1SQLSERVEROBJETS \$1EXT.SYS\$1SYS |
| SYS.SQL\$1MODULES | AWS\$1SQLSERVERMODULES \$1EXT.SYS\$1SQL |
| SYS.DATABASES | AWS\$1SQLSERVERBASES DE DONNÉES \$1EXT.SYS\$1 |
| INFORMATION\$1SCHEMA.SCHEMATA | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHÉMA\$1SCHÉMAS |
| 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\$1CONTRAINTES |
| 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 |
# Utilisation d'un pack d' AWS SCT extension pour émuler l'agent SQL Server dans PostgreSQL
L'agent SQL Server est un service Microsoft Windows qui exécute des tâches SQL Server. L'agent SQL Server exécute les tâches selon un calendrier, en réponse à un événement spécifique ou à la demande. Pour plus d'informations sur SQL Server Agent, consultez la [documentation technique Microsoft](https://docs.microsoft.com/en-us/sql/ssms/agent/sql-server-agent?view=sql-server-ver15).
PostgreSQL n'a pas d'équivalent pour SQL Server Agent. Pour émuler les fonctionnalités de l'agent SQL Server, AWS SCT créez un pack d'extension. Ce pack d'extension utilise AWS Lambda Amazon CloudWatch. AWS Lambda implémente l'interface que vous utilisez pour gérer les plannings et exécuter des tâches. Amazon CloudWatch applique les règles de planification.
AWS Lambda et Amazon CloudWatch utilisent un paramètre JSON pour interagir. La structure de ce paramètre JSON est la suivante.
```
{
"mode": mode,
"parameters": {
list of parameters
},
"callback": procedure name
}
```
Dans l'exemple précédent, *`mode`* il s'agit du type de tâche et `list of parameters` d'un ensemble de paramètres qui dépendent du type de tâche. `procedure name`C'est également le nom de la procédure qui s'exécute une fois la tâche terminée.
AWS SCT utilise une fonction Lambda pour contrôler et exécuter des tâches. La CloudWatch règle lance l'exécution de la tâche et fournit les informations nécessaires pour démarrer la tâche. Lorsque la CloudWatch règle se déclenche, elle lance la fonction Lambda en utilisant les paramètres de la règle.
Pour créer une tâche simple qui appelle une procédure, utilisez le format suivant.
```
{
"mode": "run_job",
"parameters": {
"vendor": "mysql",
"cmd": "lambda_db.nightly_job"
}
}
```
Pour créer une tâche en plusieurs étapes, utilisez le format suivant.
```
{
"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
},
...
]
}
```
Pour émuler le comportement de l'agent SQL Server dans PostgreSQL, AWS SCT le pack d'extension crée également les tables et procédures suivantes.
## Tables qui émulent l'agent SQL Server dans PostgreSQL
Pour émuler l'agent SQL Server, le pack d'extension utilise les tableaux suivants :
**sysjobs**
Stocke les informations relatives aux tâches.
**étapes du sysjob**
Stocke les informations relatives aux étapes d'une tâche.
**plannings du système**
Stocke les informations relatives aux plannings de travail.
**plannings de tâches sysjob**
Stocke les informations de planification pour les tâches individuelles.
**sysjobhistory**
Stocke les informations relatives aux exécutions des tâches planifiées.
## Procédures qui émulent l'agent SQL Server dans PostgreSQL
Pour émuler l'agent SQL Server, le pack d'extension utilise les procédures suivantes :
**sp\$1add\$1job**
Ajoute une nouvelle tâche.
**sp\$1add\$1jobstep**
Ajoute une étape à une tâche.
**sp\$1add\$1schedule**
Crée une nouvelle règle de planification dans Amazon CloudWatch. Vous pouvez utiliser ce calendrier avec autant de tâches que vous le souhaitez.
**sp\$1attach\$1schedule**
Définit un calendrier pour le travail sélectionné.
**sp\$1add\$1jobschedule**
Crée une règle de planification pour une tâche sur Amazon CloudWatch et définit l'objectif de cette règle.
**sp\$1update\$1job**
Met à jour les attributs de la tâche créée précédemment.
**sp\$1update\$1jobstep**
Met à jour les attributs de l'étape d'une tâche.
**sp\$1update\$1schedule**
Met à jour les attributs d'une règle de planification dans Amazon CloudWatch.
**sp\$1update\$1jobschedule**
Met à jour les attributs du planning pour la tâche spécifiée.
**sp\$1delete\$1job**
Supprime une tâche.
**sp\$1delete\$1jobstep**
Supprime une étape d'une tâche.
**sp\$1delete\$1planning**
Supprime un planning.
**sp\$1delete\$1jobschedule**
Supprime d'Amazon CloudWatch la règle de planification pour la tâche spécifiée.
**sp\$1detach\$1schedule**
Supprime une association entre un planning et une tâche.
**get\$1jobs, update\$1job**
Procédures internes qui interagissent avec AWS Elastic Beanstalk.
**sp\$1verify\$1job\$1date, sp\$1verify\$1job\$1time, sp\$1verify\$1job, sp\$1verify\$1jobstep, sp\$1verify\$1schedule, sp\$1verify\$1job\$1identifiers, sp\$1verify\$1schedule\$1identifiers**
Procédures internes qui vérifient les paramètres.
## Syntaxe des procédures qui émulent l'agent SQL Server dans PostgreSQL
La `aws_sqlserver_ext.sp_add_job` procédure du pack d'extension émule la `msdb.dbo.sp_add_job` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_add_jobstep` procédure du pack d'extension émule la `msdb.dbo.sp_add_jobstep` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_add_schedule` procédure du pack d'extension émule la `msdb.dbo.sp_add_schedule` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_attach_schedule` procédure du pack d'extension émule la `msdb.dbo.sp_attach_schedule` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_add_jobschedule` procédure du pack d'extension émule la `msdb.dbo.sp_add_jobschedule` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_delete_job` procédure du pack d'extension émule la `msdb.dbo.sp_delete_job` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_delete_jobstep` procédure du pack d'extension émule la `msdb.dbo.sp_delete_jobstep` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_delete_jobschedule` procédure du pack d'extension émule la `msdb.dbo.sp_delete_jobschedule` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_delete_schedule` procédure du pack d'extension émule la `msdb.dbo.sp_delete_schedule` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_detach_schedule` procédure du pack d'extension émule la `msdb.dbo.sp_detach_schedule` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_update_job` procédure du pack d'extension émule la `msdb.dbo.sp_update_job` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_update_jobschedule` procédure du pack d'extension émule la `msdb.dbo.sp_update_jobschedule` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_update_jobstep` procédure du pack d'extension émule la `msdb.dbo.sp_update_jobstep` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sp_update_schedule` procédure du pack d'extension émule la `msdb.dbo.sp_update_schedule` procédure. Pour plus d'informations sur la procédure source de l'agent SQL Server, consultez [la documentation technique 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
```
## Exemples d'utilisation de procédures qui émulent l'agent SQL Server dans PostgreSQL
Pour ajouter une nouvelle tâche, suivez la `aws_sqlserver_ext.sp_add_job` procédure décrite ci-dessous.
```
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');
```
Pour ajouter une nouvelle étape de travail, suivez la `aws_sqlserver_ext.sp_add_jobstep` procédure décrite ci-dessous.
```
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');
```
Pour ajouter un calendrier simple, suivez la `aws_sqlserver_ext.sp_add_schedule` procédure ci-dessous.
```
SELECT * FROM aws_sqlserver_ext.sp_add_schedule(
par_schedule_name := 'RunOnce',
par_freq_type := 1,
par_active_start_time := 233000);
```
Pour définir un calendrier pour une tâche, suivez la `aws_sqlserver_ext.sp_attach_schedule` procédure décrite ci-dessous.
```
SELECT * FROM aws_sqlserver_ext.sp_attach_schedule (
par_job_name := 'test_job',
par_schedule_name := 'NightlyJobs');
```
Pour créer un calendrier pour une tâche, suivez la `aws_sqlserver_ext.sp_add_jobschedule` procédure décrite ci-dessous.
```
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);
```
## Exemples d'utilisation pour émuler l'agent SQL Server dans PostgreSQL
Si le code de votre base de données source utilise l'agent SQL Server pour exécuter des tâches, vous pouvez utiliser le pack d'extension SQL Server vers PostgreSQL AWS SCT pour convertir ce code en PostgreSQL. Le pack d'extension utilise des AWS Lambda fonctions pour émuler le comportement de SQL Server Agent.
Vous pouvez créer une nouvelle AWS Lambda fonction ou enregistrer une fonction existante.
**Pour créer une nouvelle AWS Lambda fonction**
1. Dans AWS SCT l'arborescence de la base de données cible, ouvrez le menu contextuel (clic droit), choisissez **Appliquer le pack d'extension pour**, puis **PostgreSQL**.
L'assistant Kit d'extension s'affiche.
1. Dans l'onglet **Service d'émulation de l'agent SQL Server**, procédez comme suit :
+ Choisissez **Créer une AWS Lambda fonction**.
+ Pour **Connexion à la base** de données, entrez le nom de l'utilisateur de la base de données cible.
+ Dans le **champ Mot de passe de la base** de données, entrez le mot de passe correspondant au nom d'utilisateur que vous avez saisi à l'étape précédente.
+ Pour **le dossier de bibliothèque Python**, entrez le chemin d'accès au dossier de votre bibliothèque Python.
+ Choisissez **Créer AWS Lambda une fonction**, puis **Next**.
**Pour enregistrer une AWS Lambda fonction que vous avez déployée précédemment**
+ Exécutez le script suivant sur votre base de données cible.
```
SELECT
FROM aws_sqlserver_ext.set_service_setting(
p_service := 'JOB',
p_setting := 'LAMBDA_ARN',
p_value := ARN)
```
Dans l'exemple précédent, *`ARN`* il s'agit de l'Amazon Resource Name (ARN) de la AWS Lambda fonction déployée.
L'exemple suivant crée une tâche simple composée d'une étape. Toutes les cinq minutes, cette tâche exécute la `job_example` fonction créée précédemment. Cette fonction insère des enregistrements dans la `job_example_table` table.
**Pour créer cette tâche simple**
1. Créez une tâche à l'aide de la `aws_sqlserver_ext.sp_add_job` fonction illustrée ci-dessous.
```
SELECT
FROM aws_sqlserver_ext.sp_add_job (
par_job_name := 'test_simple_job');
```
1. Créez une étape de travail à l'aide de la `aws_sqlserver_ext.sp_add_jobstep` fonction illustrée ci-dessous.
```
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;');
```
L'étape de travail indique le rôle de la fonction.
1. Créez un planificateur pour le travail à l'aide de la `aws_sqlserver_ext.sp_add_jobschedule` fonction illustrée ci-dessous.
```
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 */);
```
L'étape de travail indique le rôle de la fonction.
Pour supprimer cette tâche, utilisez la `aws_sqlserver_ext.sp_delete_job` fonction illustrée ci-dessous.
```
PERFORM aws_sqlserver_ext.sp_delete_job(
par_job_name := 'PeriodicJob1'::character varying,
par_delete_history := 1::smallint,
par_delete_unused_schedule := 1::smallint);
```
# Utilisation d'un pack d' AWS SCT extension pour émuler SQL Server Database Mail dans PostgreSQL
Vous pouvez utiliser SQL Server Database Mail pour envoyer des e-mails aux utilisateurs à partir du moteur de base de données SQL Server ou d'une instance gérée Azure SQL. Ces e-mails peuvent contenir les résultats de requêtes ou inclure des fichiers provenant de n'importe quelle ressource de votre réseau. Pour plus d'informations sur SQL Server Database Mail, consultez [la documentation technique Microsoft](https://docs.microsoft.com/en-us/sql/relational-databases/database-mail/database-mail?view=sql-server-ver15).
PostgreSQL n'a pas d'équivalent pour SQL Server Database Mail. Pour émuler les fonctionnalités de messagerie de base de données SQL Server, AWS SCT créez un pack d'extension. Ce pack d'extension utilise AWS Lambda Amazon Simple Email Service (Amazon SES). AWS Lambda fournit aux utilisateurs une interface leur permettant d'interagir avec le service d'envoi d'e-mails Amazon SES. Pour configurer cette interaction, ajoutez le nom de ressource Amazon (ARN) de votre fonction Lambda.
Pour créer un nouveau compte de messagerie, utilisez la commande suivante.
```
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;
```
Pour ajouter l'ARN de votre fonction Lambda au compte de messagerie existant, utilisez la commande suivante.
```
do
$$
begin
PERFORM sysmail_update_account_sp (
par_account_name :='existind_account_name',
par_mailserver_type := 'AWSLAMBDA'
par_mailserver_name := 'ARN'
);
end;
$$ language plpgsql;
```
Dans les exemples précédents, *`ARN`* c'est l'ARN de votre fonction Lambda.
Pour émuler le comportement du courrier de base de données SQL Server dans PostgreSQL, AWS SCT le pack d'extension utilise les tables, les vues et les procédures suivantes.
## Tables qui émulent le courrier de base de données SQL Server dans PostgreSQL
Pour émuler SQL Server Database Mail, le pack d'extension utilise les tables suivantes :
**compte sysmail\$1**
Stocke les informations relatives aux comptes de messagerie.
**sysmail\$1profile**
Stocke les informations relatives aux profils utilisateur.
**serveur\$1système**
Stocke les informations relatives aux serveurs de messagerie.
**sysmail\$1mailitems**
Stocke la liste des e-mails.
**sysmail\$1attachments**
Contient une ligne pour chaque pièce jointe à un e-mail.
**journal de messagerie système**
Stocke les informations de service relatives à l'envoi de messages électroniques.
**compte sysmail\$1profile**
Stocke les informations relatives aux profils d'utilisateurs et aux comptes de messagerie.
## Vues qui émulent le courrier de base de données SQL Server dans PostgreSQL
Pour émuler SQL Server Database Mail, AWS SCT créez les vues suivantes dans la base de données PostgreSQL afin de garantir la compatibilité. Le pack d'extension ne les utilise pas, mais votre code converti peut interroger ces vues.
**sysmail\$1allitems**
Inclut une liste de tous les e-mails.
**sysmail\$1faileditems**
Inclut une liste des e-mails qui n'ont pas pu être envoyés.
**sysmail\$1sentitems**
Inclut une liste des e-mails envoyés.
**sysmail\$1unsentitems**
Inclut une liste d'e-mails qui n'ont pas encore été envoyés.
**sysmail\$1mailattachments**
Inclut une liste des fichiers joints.
## Procédures qui émulent le courrier de base de données SQL Server dans PostgreSQL
Pour émuler SQL Server Database Mail, le pack d'extension utilise les procédures suivantes :
**sp\$1send\$1dbmail**
Envoie un e-mail aux destinataires spécifiés.
**sysmail\$1add\$1profile\$1sp**
Crée un nouveau profil utilisateur.
**sysmail\$1add\$1account\$1sp**
Crée un nouveau compte de messagerie qui stocke des informations telles que les informations d'identification du protocole SMTP (Simple Mail Transfer Protocol), etc.
**sysmail\$1add\$1profileaccount\$1sp**
Ajoute un compte e-mail au profil utilisateur spécifié.
**sysmail\$1update\$1profile\$1sp**
Modifie les attributs du profil utilisateur tels que la description, le nom, etc.
**sysmail\$1update\$1account\$1sp**
Modifie les informations du compte de messagerie existant.
**sysmail\$1update\$1profileaccount\$1sp**
Met à jour les informations du compte e-mail dans le profil utilisateur spécifié.
**sysmail\$1delete\$1profileaccount\$1sp**
Supprime un compte de messagerie du profil utilisateur spécifié.
**sysmail\$1delete\$1account\$1sp**
Supprime le compte de messagerie.
**sysmail\$1delete\$1profile\$1sp**
Supprime le profil utilisateur.
**sysmail\$1delete\$1mailitems\$1sp**
Supprime les e-mails des tables internes.
**sysmail\$1help\$1profile\$1sp**
Affiche des informations sur le profil utilisateur.
**sysmail\$1help\$1account\$1sp**
Affiche les informations relatives au compte de messagerie.
**sysmail\$1help\$1profileaccount\$1sp**
Affiche des informations sur les comptes de messagerie associés au profil utilisateur.
**sysmail\$1dbmail\$1json**
Procédure interne qui génère des requêtes JSON pour des AWS Lambda fonctions.
**sysmail\$1verify\$1profile\$1sp, sysmail\$1verify\$1account\$1sp, sysmail\$1verify\$1addressparams\$1sp**
Procédures internes qui vérifient les paramètres.
**sp\$1get\$1dbmail, sp\$1set\$1dbmail, sysmail\$1dbmail\$1xml**
Procédures internes déconseillées.
## Syntaxe des procédures qui émulent le courrier de base de données SQL Server dans PostgreSQL
La `aws_sqlserver_ext.sp_send_dbmail` procédure du pack d'extension émule la `msdb.dbo.sp_send_dbmail` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_delete_mailitems_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_delete_mailitems_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_add_profile_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_add_profile_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_add_account_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_add_account_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_add_profileaccount_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_add_profileaccount_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_help_profile_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_help_profile_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_update_profile_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_update_profile_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_delete_profile_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_delete_profile_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_help_account_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_help_account_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_update_account_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_update_account_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_delete_account_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_delete_account_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_help_profileaccount_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_help_profileaccount_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_update_profileaccount_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_update_profileaccount_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
La `aws_sqlserver_ext.sysmail_delete_profileaccount_sp` procédure du pack d'extension émule la `msdb.dbo.sysmail_delete_profileaccount_sp` procédure. Pour plus d'informations sur la procédure source de courrier de base de données SQL Server, consultez [la documentation technique 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
```
## Exemples d'utilisation de procédures qui émulent le courrier de base de données SQL Server dans PostgreSQL
Pour envoyer un e-mail, suivez la `aws_sqlserver_ext.sp_send_dbmail` procédure ci-dessous.
```
PERFORM sp_send_dbmail (
par_profile_name := 'Administrator',
par_recipients := 'hello@rusgl.info',
par_subject := 'Automated Success Message',
par_body := 'The stored procedure finished'
);
```
L'exemple suivant montre comment envoyer un e-mail contenant les résultats d'une requête.
```
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'
);
```
L'exemple suivant montre comment envoyer un e-mail avec du code HTML.
```
DECLARE var_tableHTML TEXT;
SET var_tableHTML := CONCAT(
'Work Order Report
',
'',
'| Work Order ID | Product ID | ',
'Name | Order Qty | Due Date | ',
'Expected Revenue |
|---|
',
'
'
);
PERFORM sp_send_dbmail (
par_recipients := 'hello@rusgl.info',
par_subject := 'Work Order List',
par_body := var_tableHTML,
par_body_format := 'HTML'
);
```
Pour supprimer des e-mails, suivez la `aws_sqlserver_ext.sysmail_delete_mailitems_sp` procédure ci-dessous.
```
DECLARE var_GETDATE datetime;
SET var_GETDATE = NOW();
PERFORM sysmail_delete_mailitems_sp (
par_sent_before := var_GETDATE
);
```
L'exemple suivant montre comment supprimer les e-mails les plus anciens.
```
PERFORM sysmail_delete_mailitems_sp (
par_sent_before := '31.12.2015'
);
```
L'exemple suivant montre comment supprimer tous les e-mails qui ne peuvent pas être envoyés.
```
PERFORM sysmail_delete_mailitems_sp (
par_sent_status := 'failed'
);
```
Pour créer un nouveau profil utilisateur, suivez la `aws_sqlserver_ext.sysmail_add_profile_sp` procédure décrite ci-dessous.
```
PERFORM sysmail_add_profile_sp (
profile_name := 'Administrator',
par_description := 'administrative mail'
);
```
L'exemple suivant montre comment créer un nouveau profil et enregistrer l'identifiant de profil unique dans une variable.
```
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;
```
Pour créer un nouveau compte de messagerie, suivez la `aws_sqlserver_ext.sysmail_add_account_sp` procédure ci-dessous.
```
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'
);
```
Pour ajouter un compte e-mail au profil utilisateur, suivez la `aws_sqlserver_ext.sysmail_add_profileaccount_sp` procédure ci-dessous.
```
PERFORM sysmail_add_profileaccount_sp (
par_account_name := 'Administrator',
par_account_name := 'Audit Account',
par_sequence_number := 1
);
```
## Exemples d'utilisation pour émuler SQL Server Database Mail dans PostgreSQL
Si le code de votre base de données source utilise SQL Server Database Mail pour envoyer des e-mails, vous pouvez utiliser le pack d' AWS SCT extension pour convertir ce code en PostgreSQL.
**Pour envoyer un e-mail depuis votre base de données PostgreSQL**
1. Créez et configurez votre AWS Lambda fonction.
1. Appliquez le pack d' AWS SCT extension.
1. Créez un profil utilisateur à l'aide de la `sysmail_add_profile_sp` fonction illustrée ci-dessous.
1. Créez un compte e-mail à l'aide de la `sysmail_add_account_sp` fonction illustrée ci-dessous.
1. Ajoutez ce compte e-mail à votre profil utilisateur à l'aide de la `sysmail_add_profileaccount_sp` fonction illustrée ci-dessous.
```
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. Envoyez un e-mail à l'aide de la `sp_send_dbmail` fonction illustrée ci-dessous.
```
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;
```
Pour consulter les informations relatives à tous les profils utilisateur, suivez la `sysmail_help_profile_sp` procédure décrite ci-dessous.
```
SELECT FROM aws_sqlserver_ext.sysmail_help_profile_sp();
```
L'exemple suivant affiche les informations relatives au profil utilisateur spécifique.
```
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');
```
Pour consulter les informations relatives à tous les comptes de messagerie, suivez la `sysmail_help_account_sp` procédure ci-dessous.
```
select from aws_sqlserver_ext.sysmail_help_account_sp();
```
L'exemple suivant affiche les informations relatives au compte de messagerie spécifique.
```
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');
```
Pour consulter les informations relatives à tous les comptes de messagerie associés aux profils utilisateur, suivez la `sysmail_help_profileaccount_sp` procédure décrite ci-dessous.
```
select from aws_sqlserver_ext.sysmail_help_profileaccount_sp();
```
L'exemple suivant filtre les enregistrements par identifiant, nom de profil ou nom de compte.
```
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');
```
Pour modifier le nom ou la description du profil utilisateur, suivez la `sysmail_update_profile_sp` procédure ci-dessous.
```
select aws_sqlserver_ext.sysmail_update_profile_sp(
par_profile_id := 2,
par_profile_name := 'New profile name'
);
```
Pour modifier les paramètres du compte de messagerie, suivez la `ysmail_update_account_sp` procédure décrite ci-dessous.
```
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'
);
```
# Migration de SQL Server vers Amazon RDS for SQL Server avec AWS Schema Conversion Tool
Éléments à prendre en compte lors de la migration d'un schéma et de code SQL Server vers Amazon RDS pour SQL Server :
+ AWS SCT peut convertir l'agent SQL Server pour fournir des plannings, des alertes et des tâches sur une instance de base de données Amazon RDS for SQL Server. Après la conversion, vous pouvez utiliser une instance de base de données Amazon RDS pour SQL Server avec SQL Server Reporting Service (SSRS), SQL Server Analysis Services (SSAS) et SQL Server Integration Services (SSIS).
+ Actuellement, Amazon RDS ne prend pas en charge les points de terminaison T-SQL supplémentaires ou SQL Server Service Broker qui nécessitent que vous exécutiez la commande CREATE ENDPOINT.
+ Amazon RDS offre une prise en charge limitée des serveurs associés. Lors de la conversion du code d'application SQL Server qui utilise des serveurs liés, AWS SCT convertit le code de l'application. Toutefois, assurez-vous de vérifier le comportement des objets qui utilisent des serveurs liés avant d'exécuter le code converti.
+ Always-On est utilisé.
+ Le rapport AWS SCT d'évaluation fournit les indicateurs du serveur pour la conversion. Ces metrics sur votre instance SQL Server sont les suivantes :
+ La mise en miroir de données est utilisée.
+ L'envoi de journaux SQL Server est configuré.
+ Un cluster de basculement est utilisé.
+ La messagerie de base de données est configurée.
+ Le service de recherche en texte intégral est utilisé. Amazon RDS pour SQL Server possède une recherche en texte intégral limitée et ne prend pas en charge les recherches sémantiques.
+ Data Quality Service (DQS) est installé. Amazon RDS ne prend pas en charge DQS. Nous vous recommandons donc d'installer SQL Server sur une instance Amazon EC2.
## Privilèges pour RDS for SQL Server en tant que cible
Pour migrer vers RDS pour SQL Server, créez un utilisateur de base de données, puis accordez les privilèges requis pour chaque base de données. Vous pouvez utiliser l'exemple de code suivant.
```
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;
```
Dans l'exemple précédent, remplacez *user\$1name* par le nom de votre utilisateur. Remplacez ensuite *db\$1name* par le nom de votre base de données cible. Enfin, remplacez-le *your\$1password* par un mot de passe sécurisé.
# Sources d'entrepôts de données pour AWS Schema Conversion Tool
AWS SCT peut convertir les schémas des entrepôts de données sources suivants en une cible prise en charge. Pour plus d'informations sur les autorisations, les connexions et les éléments AWS SCT pouvant être convertis pour une utilisation avec la base de données cible ou l'entrepôt de données, consultez les détails ci-dessous.
**Topics**
+ [Connecter Amazon Redshift au AWS Schema Conversion Tool](CHAP_Source.Redshift.md)
+ [Connecter Azure Synapse Analytics à AWS Schema Conversion Tool](CHAP_Source.AzureSynapse.md)
+ [Connexion à Google BigQuery avec AWS Schema Conversion Tool](CHAP_Source.BigQuery.md)
+ [Connecter la base de données Greenplum à AWS Schema Conversion Tool](CHAP_Source.Greenplum.md)
+ [Connexion à Netezza avec AWS Schema Conversion Tool](CHAP_Source.Netezza.md)
+ [Connecter Oracle Data Warehouse à AWS SCT](CHAP_Source.OracleDW.md)
+ [Connexion à un entrepôt de données Snowflake avec AWS Schema Conversion Tool](CHAP_Source.Snowflake.md)
+ [Connexion à un entrepôt de données SQL Server à l'aide du AWS Schema Conversion Tool](CHAP_Source.SQLServerDW.md)
+ [Connexion à un entrepôt de données Teradata à l'aide du AWS Schema Conversion Tool](CHAP_Source.Teradata.md)
+ [Connexion aux bases AWS Schema Conversion Tool de données Vertica](CHAP_Source.Vertica.md)
# Connecter Amazon Redshift au AWS Schema Conversion Tool
Vous pouvez l'utiliser AWS SCT pour optimiser votre cluster Amazon Redshift. AWS SCT vous fournit des recommandations sur la sélection des clés de distribution et de tri pour votre cluster Amazon Redshift. Vous pouvez considérer le projet d'optimisation Amazon Redshift comme un AWS SCT projet dont la source et la cible pointent vers les différents clusters Amazon Redshift.
## Privilèges accordés à Amazon Redshift en tant que base de données source
Les privilèges suivants sont requis pour utiliser Amazon Redshift comme source :
+ UTILISATION SUR LE SCHÉMA **
+ SÉLECTIONNEZ SUR TOUTES LES TABLES DU SCHÉMA **
+ SELECT ON PG\$1CATALOG.PG\$1STATISTIC
+ SELECT ON SVV\$1TABLE\$1INFO
+ SELECT ON TABLE STV\$1BLOCKLIST
+ SELECT ON TABLE STV\$1TBL\$1PERM
+ SÉLECTIONNEZ SUR SYS\$1SERVERLESS\$1USAGE
+ SÉLECTIONNEZ SUR PG\$1DATABASE\$1INFO
+ SÉLECTIONNEZ SUR PG\$1STATISTIC
Dans les exemples précédents, remplacez l'**espace réservé par le nom du schéma source.
Pour connaître les privilèges requis pour Amazon Redshift en tant que cible, consultez. [Autorisations pour Amazon Redshift en tant que cible](CHAP_Converting.DW.md#CHAP_Converting.DW.ConfigureTarget)
## Connexion à Amazon Redshift en tant que source
Suivez la procédure suivante pour vous connecter à votre base de données source Amazon Redshift avec le. AWS Schema Conversion Tool
**Pour vous connecter à une base de données source Amazon Redshift**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. **Choisissez **Amazon Redshift**, puis Next.**
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement :
+ Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes :
1. Pour **AWS Secret**, choisissez le nom du secret.
1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager.
Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Pour saisir les informations de connexion à la base de données source Amazon Redshift, suivez les instructions suivantes :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.Redshift.html)
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source.
1. Choisissez **Connect pour vous** connecter à votre base de données source.
## Paramètres d'optimisation d'Amazon Redshift
Pour modifier les paramètres d'optimisation d'Amazon Redshift, sélectionnez **Paramètres** dans AWS SCT, puis sélectionnez Paramètres de **conversion**. Dans la liste supérieure, choisissez **Amazon Redshift**, puis Amazon **Redshift — Amazon Redshift**. AWS SCT affiche tous les paramètres disponibles pour l'optimisation d'Amazon Redshift.
Les paramètres d'optimisation d'Amazon Redshift AWS SCT incluent des options pour les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour définir le nombre maximum de tables AWS SCT pouvant s'appliquer à votre cluster Amazon Redshift cible.
Pour **le nombre maximum de tables pour le cluster Amazon Redshift cible**, choisissez le nombre de tables qui AWS SCT peuvent s'appliquer à votre cluster Amazon Redshift.
Amazon Redshift dispose de quotas qui limitent l’utilisation des tables pour différents types de nœud de cluster. Si vous choisissez **Auto**, AWS SCT détermine le nombre de tables à appliquer à votre cluster Amazon Redshift cible en fonction du type de nœud. Vous pouvez éventuellement choisir la valeur manuellement. Pour plus d’informations, consultez [Quotas et limites dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) dans le *Guide de gestion Amazon Redshift*.
AWS SCT convertit toutes vos tables sources, même si le nombre de tables est supérieur à ce que votre cluster Amazon Redshift peut stocker. AWS SCT stocke le code converti dans votre projet et ne l'applique pas à la base de données cible. Si vous atteignez le quota de cluster Amazon Redshift pour les tables lorsque vous appliquez le code converti, un message d'avertissement s' AWS SCT affiche. AWS SCT Applique également des tables à votre cluster Amazon Redshift cible jusqu'à ce que le nombre de tables atteigne la limite.
+ Pour choisir la stratégie de migration.
AWS recommande d'utiliser différents clusters comme source et cible pour votre projet d'optimisation. Avant de commencer le processus d'optimisation Amazon Redshift, vous devez créer une copie de votre cluster Amazon Redshift source. Vous pouvez inclure vos données sources dans cette copie ou créer un cluster vide.
Pour **Stratégie de migration**, choisissez **Migration vers une copie** pour inclure les données de votre cluster source dans le cluster cible.
Pour **la stratégie de migration**, choisissez **Migration vers une table rase** pour passer en revue les suggestions d'optimisation. Après avoir accepté ces suggestions, migrez vos données sources vers le cluster cible.
+ Pour appliquer une compression aux colonnes d'un tableau Amazon Redshift. Pour ce faire, sélectionnez **Utiliser le codage par compression**.
AWS SCT attribue automatiquement un codage de compression aux colonnes à l'aide de l'algorithme Amazon Redshift par défaut. Pour plus d'informations, consultez la section [Encodages de compression](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) dans le manuel *Amazon Redshift Database* Developer Guide.
Par défaut, Amazon Redshift n'applique pas de compression aux colonnes définies comme clés de tri et de distribution. Vous pouvez modifier ce comportement et appliquer une compression à ces colonnes. Pour ce faire, sélectionnez **Utiliser le codage de compression pour les colonnes KEY**. Vous ne pouvez sélectionner cette option que lorsque vous avez sélectionné l'option **Utiliser le codage par compression**.
+ Pour travailler avec l'optimisation automatique des tables.
L'optimisation automatique des tables est un processus de réglage automatique dans Amazon Redshift qui optimise automatiquement la conception des tables. Pour plus d'informations, consultez la section [Utilisation de l'optimisation automatique des tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) dans le manuel *Amazon Redshift Database Developer Guide*.
Pour utiliser uniquement l'optimisation automatique des tables, choisissez **Stratégies d'optimisation** dans le volet de gauche. Sélectionnez ensuite **Utiliser le réglage automatique des tables Amazon Redshift**, puis sélectionnez **Aucun** pour la stratégie de **sélection des clés initiale**.
+ Pour choisir les clés de tri et de distribution selon votre stratégie.
Vous pouvez choisir des clés de tri et de distribution à l'aide des métadonnées Amazon Redshift, des informations statistiques ou des deux options. Pour **Stratégie initiale de sélection des clés** dans l'onglet **Stratégies d'optimisation**, choisissez l'une des options suivantes :
+ Utiliser des métadonnées, ignorer les informations statistiques
+ Ignorer les métadonnées, utiliser des informations statistiques
+ Utiliser des métadonnées et des informations statistiques
Selon l'option que vous choisissez, vous pouvez sélectionner des stratégies d'optimisation. Entrez ensuite la valeur (0 à 100) pour chaque stratégie. Ces valeurs définissent le poids de chaque stratégie. À l'aide de ces valeurs de pondération, AWS SCT définit l'influence de chaque règle sur le choix des clés de distribution et de tri. Les valeurs par défaut sont basées sur les meilleures pratiques de AWS migration.
Vous pouvez définir la taille des petites tables dans le cadre de la stratégie **Find small tables**. Pour Nombre **minimum de lignes de tableau et Nombre** **maximum de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le définir comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
+ Pour configurer les détails de la stratégie.
Outre la définition du poids pour chaque stratégie d'optimisation, vous pouvez configurer les paramètres d'optimisation. Pour ce faire, choisissez **Optimisation des conversions**.
+ Pour le **champ Limite des colonnes clés de tri**, entrez le nombre maximum de colonnes dans la clé de tri.
+ Pour une **valeur de seuil asymétrique**, entrez le pourcentage (0 à 100) d'une valeur asymétrique pour une colonne. AWS SCT exclut les colonnes dont la valeur asymétrique est supérieure au seuil de la liste des candidats pour la clé de distribution. AWS SCT définit la valeur asymétrique d'une colonne comme le pourcentage entre le nombre d'occurrences de la valeur la plus courante et le nombre total d'enregistrements.
+ Pour les **N principales requêtes de la table d'historique** des requêtes, entrez le nombre (1 à 100) des requêtes les plus fréquemment utilisées à analyser.
+ Pour **Sélectionner un utilisateur de statistiques**, choisissez l'utilisateur de base de données dont vous souhaitez analyser les statistiques de requête.
# Connecter Azure Synapse Analytics à AWS Schema Conversion Tool
Vous pouvez l'utiliser AWS SCT pour convertir des schémas, des objets de code et du code d'application d'Azure Synapse Analytics vers Amazon Redshift.
## Privilèges pour Azure Synapse Analytics en tant que base de données source
Les privilèges suivants sont requis pour utiliser un entrepôt de données Azure Synapse Analytics comme source :
+ VIEW DEFINITION
+ VIEW DATABASE STATE
Appliquez les privilèges pour chaque base de données dont vous convertissez le schéma.
## Connexion à Azure Synapse Analytics en tant que source
Utilisez la procédure suivante pour vous connecter à votre entrepôt de données Azure Synapse Analytics avec le AWS Schema Conversion Tool.
**Pour vous connecter à un entrepôt de données Azure Synapse Analytics en tant que source**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. Choisissez **Azure Synapse Analytics**, puis **Next**.
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement :
+ Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes :
1. Pour **AWS Secret**, choisissez le nom du secret.
1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager.
Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Pour saisir manuellement les informations de connexion pour l'entrepôt de données Azure Synapse Analytics, suivez les instructions suivantes :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.AzureSynapse.html)
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source.
1. Choisissez **Connect pour vous** connecter à votre base de données source.
## Paramètres de conversion d'Azure Synapse Analytics vers Amazon Redshift
**Pour modifier les paramètres de conversion d'Azure Synapse Analytics vers Amazon Redshift, **choisissez** Paramètres AWS SCT dans, puis sélectionnez Paramètres de conversion.** Dans la liste supérieure, choisissez **Azure Synapse**, puis **Azure Synapse — Amazon Redshift**. AWS SCT affiche tous les paramètres disponibles pour la conversion d'Azure Synapse Analytics vers Amazon Redshift.
Les paramètres de conversion d'Azure Synapse Analytics vers Amazon Redshift incluent des options pour AWS SCT les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour définir le nombre maximum de tables AWS SCT pouvant s'appliquer à votre cluster Amazon Redshift cible.
Pour **le nombre maximum de tables pour le cluster Amazon Redshift cible**, choisissez le nombre de tables qui AWS SCT peuvent s'appliquer à votre cluster Amazon Redshift.
Amazon Redshift dispose de quotas qui limitent l’utilisation des tables pour différents types de nœud de cluster. Si vous choisissez **Auto**, AWS SCT détermine le nombre de tables à appliquer à votre cluster Amazon Redshift cible en fonction du type de nœud. Vous pouvez éventuellement choisir la valeur manuellement. Pour plus d’informations, consultez [Quotas et limites dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) dans le *Guide de gestion Amazon Redshift*.
AWS SCT convertit toutes vos tables sources, même si c'est plus que ce que votre cluster Amazon Redshift peut stocker. AWS SCT stocke le code converti dans votre projet et ne l'applique pas à la base de données cible. Si vous atteignez le quota de cluster Amazon Redshift pour les tables lorsque vous appliquez le code converti, un message d'avertissement s' AWS SCT affiche. AWS SCT Applique également des tables à votre cluster Amazon Redshift cible jusqu'à ce que le nombre de tables atteigne la limite.
+ Pour migrer des partitions de la table source vers des tables séparées dans Amazon Redshift. Pour ce faire, sélectionnez **Utiliser la vue UNION ALL** et entrez le nombre maximum de tables cibles AWS SCT pouvant être créées pour une seule table source.
Amazon Redshift ne prend pas en charge le partitionnement des tables. Pour imiter ce comportement et accélérer l'exécution des requêtes, AWS SCT vous pouvez migrer chaque partition de votre table source vers une table distincte dans Amazon Redshift. AWS SCT Crée ensuite une vue qui inclut les données de toutes ces tables.
AWS SCT détermine automatiquement le nombre de partitions de votre table source. Selon le type de partitionnement de votre table source, ce nombre peut dépasser le quota de tables que vous pouvez appliquer à votre cluster Amazon Redshift. Pour éviter d'atteindre ce quota, entrez le nombre maximum de tables cibles AWS SCT pouvant être créées pour les partitions d'une seule table source. L'option par défaut est 368 tables, ce qui représente une partition pendant 366 jours par an et deux tables pour `NO RANGE` et `UNKNOWN` partitions.
+ Pour appliquer une compression aux colonnes d'un tableau Amazon Redshift. Pour ce faire, sélectionnez **Utiliser le codage par compression**.
AWS SCT attribue automatiquement un codage de compression aux colonnes à l'aide de l'algorithme Amazon Redshift par défaut. Pour plus d'informations, consultez la section [Encodages de compression](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) dans le manuel *Amazon Redshift Database* Developer Guide.
Par défaut, Amazon Redshift n'applique pas de compression aux colonnes définies comme clés de tri et de distribution. Vous pouvez modifier ce comportement et appliquer une compression à ces colonnes. Pour ce faire, sélectionnez **Utiliser le codage de compression pour les colonnes KEY**. Vous ne pouvez sélectionner cette option que lorsque vous sélectionnez l'option **Utiliser le codage par compression**.
## Paramètres d'optimisation de la conversion d'Azure Synapse Analytics vers Amazon Redshift
**Pour modifier les paramètres d'optimisation de conversion d'Azure Synapse Analytics vers Amazon Redshift, **choisissez** Paramètres AWS SCT dans, puis sélectionnez Paramètres de conversion.** Dans la liste supérieure, choisissez **Azure Synapse**, puis **Azure Synapse — Amazon Redshift**. Dans le volet de gauche, sélectionnez **Stratégies d'optimisation**. AWS SCT affiche les paramètres d'optimisation des conversions pour la conversion entre Azure Synapse Analytics et Amazon Redshift.
Les paramètres AWS SCT d'optimisation de la conversion d'Azure Synapse Analytics vers Amazon Redshift incluent des options pour les éléments suivants :
+ Pour travailler avec l'optimisation automatique des tables. Pour ce faire, sélectionnez **Utiliser le réglage automatique des tables Amazon Redshift**.
L'optimisation automatique des tables est un processus de réglage automatique dans Amazon Redshift qui optimise automatiquement la conception des tables. Pour plus d'informations, consultez la section [Utilisation de l'optimisation automatique des tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) dans le manuel *Amazon Redshift Database Developer Guide*.
Pour vous fier uniquement à l'optimisation automatique des tables, choisissez **Aucune** pour la **stratégie initiale de sélection des clés**.
+ Pour choisir les clés de tri et de distribution selon votre stratégie.
Vous pouvez choisir des clés de tri et de distribution à l'aide des métadonnées Amazon Redshift, des informations statistiques ou des deux options. Pour **Stratégie initiale de sélection des clés** dans l'onglet **Stratégies d'optimisation**, choisissez l'une des options suivantes :
+ Utiliser des métadonnées, ignorer les informations statistiques
+ Ignorer les métadonnées, utiliser des informations statistiques
+ Utiliser des métadonnées et des informations statistiques
Selon l'option que vous choisissez, vous pouvez sélectionner des stratégies d'optimisation. Entrez ensuite la valeur (0 à 100) pour chaque stratégie. Ces valeurs définissent le poids de chaque stratégie. À l'aide de ces valeurs de pondération, AWS SCT définit l'influence de chaque règle sur le choix des clés de distribution et de tri. Les valeurs par défaut sont basées sur les meilleures pratiques de AWS migration.
Vous pouvez définir la taille des petites tables dans le cadre de la stratégie **Find small tables**. Pour Nombre **minimum de lignes de tableau et Nombre** **maximum de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le définir comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
+ Pour configurer les détails de la stratégie.
Outre la définition du poids pour chaque stratégie d'optimisation, vous pouvez configurer les paramètres d'optimisation. Pour ce faire, choisissez **Optimisation des conversions**.
+ Pour le **champ Limite des colonnes clés de tri**, entrez le nombre maximum de colonnes dans la clé de tri.
+ Pour une **valeur de seuil asymétrique**, entrez le pourcentage (0 à 100) d'une valeur asymétrique pour une colonne. AWS SCT exclut les colonnes dont la valeur d'inclinaison est supérieure au seuil de la liste des candidats pour la clé de distribution. AWS SCT définit la valeur asymétrique d'une colonne comme le pourcentage entre le nombre d'occurrences de la valeur la plus courante et le nombre total d'enregistrements.
+ Pour les **N principales requêtes de la table d'historique** des requêtes, entrez le nombre (1 à 100) des requêtes les plus fréquemment utilisées à analyser.
+ Pour **Sélectionner un utilisateur de statistiques**, choisissez l'utilisateur de base de données pour lequel vous souhaitez analyser les statistiques de requête.
Dans l'onglet **Stratégies d'optimisation**, vous pouvez également définir la taille des petites tables pour la stratégie **Rechercher de petites tables**. Pour Nombre **minimal de lignes de tableau et Nombre** **maximal de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le considérer comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
# Connexion à Google BigQuery avec AWS Schema Conversion Tool
Vous pouvez l'utiliser AWS SCT pour convertir des schémas, des objets de code et du code d'application BigQuery vers Amazon Redshift.
## Privilèges pour BigQuery en tant que source
Pour utiliser un entrepôt de BigQuery données comme source dans AWS SCT, créez un compte de service. Dans Google Cloud, les applications utilisent des comptes de service pour effectuer des appels d'API autorisés. Les comptes de service sont différents des comptes d'utilisateurs. Pour plus d'informations, consultez la section [Comptes de service](https://cloud.google.com/iam/docs/service-accounts) dans la documentation de Google Cloud Identity and Access Management.
Assurez-vous d'attribuer les rôles suivants à votre compte de service :
+ `BigQuery Admin`
+ `Storage Admin`
Le `BigQuery Admin` rôle fournit des autorisations pour gérer toutes les ressources du projet. AWS SCT utilise ce rôle pour charger vos BigQuery métadonnées dans le projet de migration.
Le `Storage Admin` rôle garantit le contrôle total des objets de données et des compartiments. Vous trouverez ce rôle sous`Cloud Storage`. AWS SCT utilise ce rôle pour extraire vos données d'Amazon Redshift, BigQuery puis les charger dans celui-ci.
**Pour créer un fichier clé de compte de service**
1. Connectez-vous à la console de gestion Google Cloud à l'adresse [https://console.cloud.google.com/](https://console.cloud.google.com/).
1. Sur la page de [BigQuery l'API](https://console.cloud.google.com/apis/library/bigquery.googleapis.com), sélectionnez **Activer**. Ignorez cette étape si **l'API est activée**.
1. Sur la page [Comptes de service](https://console.cloud.google.com/iam-admin/serviceaccounts), choisissez votre projet, puis choisissez **Créer un compte de service**.
1. Sur la page des **détails du compte de service**, entrez une valeur descriptive pour le **nom du compte de service**. Choisissez **Créer et continuer**. La page **Accorder à ce compte de service l'accès au projet** s'ouvre.
1. Pour **Sélectionner un rôle**, choisissez **BigQuery**, puis choisissez **BigQuery Admin**.
1. Choisissez **Ajouter un autre rôle**. Pour **Sélectionner un rôle**, choisissez **Cloud Storage**, puis **Storage Admin**.
1. Choisissez **Continuer**, puis **OK**.
1. Sur la page [Comptes de service](https://console.cloud.google.com/iam-admin/serviceaccounts), choisissez le compte de service que vous avez créé.
1. Choisissez **Clés**, puis choisissez **Créer une nouvelle clé** pour **Ajouter une clé**.
1. Choisissez **JSON**, puis **Create**. Choisissez le dossier dans lequel enregistrer votre clé privée ou sélectionnez le dossier par défaut pour les téléchargements dans votre navigateur.
Pour extraire des données d'un entrepôt de BigQuery données, AWS SCT utilisez le dossier bucket de Google Cloud Storage. Créez ce compartiment avant de commencer la migration des données. Entrez le chemin d'accès à votre dossier de bucket Google Cloud Storage dans la boîte de dialogue **Créer une tâche locale**. Pour de plus amples informations, veuillez consulter [Création, exécution et surveillance d'une AWS SCT tâche](agents.md#agents.Tasks).
## Connexion à BigQuery en tant que source
Utilisez la procédure suivante pour vous connecter à votre BigQuery projet source avec le AWS Schema Conversion Tool.
**Pour se connecter à un entrepôt de données BigQuery source**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. Choisissez **BigQuery**, puis cliquez sur **Suivant**.
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de la connexion**, entrez le nom de votre BigQuery projet. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Pour **Chemin clé**, entrez le chemin d'accès au fichier clé du compte de service. Pour plus d'informations sur la création de ce fichier, consultez[Privilèges pour BigQuery en tant que source](#CHAP_Source.BigQuery.Permissions).
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre BigQuery projet source.
1. Choisissez **Connect** pour vous connecter à votre BigQuery projet source.
## Restrictions relatives à l'utilisation BigQuery en tant que source pour AWS SCT
Les restrictions suivantes s'appliquent lors de l'utilisation en BigQuery tant que source pour AWS SCT :
+ AWS SCT ne prend pas en charge la conversion de sous-requêtes dans les fonctions analytiques.
+ Vous ne pouvez pas l' AWS SCT utiliser pour convertir BigQuery `SELECT AS STRUCT` des `SELECT AS VALUE` instructions.
+ AWS SCT ne prend pas en charge la conversion des types de fonctions suivants :
+ Agrégat approximatif
+ Bit
+ Débogage
+ Requête fédérée
+ Géographie
+ Hachage
+ Mathématiques
+ Filet
+ Agrégat statistique
+ UUID
+ AWS SCT fournit un support limité pour la conversion des fonctions de chaîne.
+ AWS SCT ne prend pas en charge la conversion des `UNNEST` opérateurs.
+ Vous ne pouvez pas convertir les opérations de jointure corrélées en AWS SCT.
+ AWS SCT ne prend pas en charge la conversion des `OFFSET` clauses `QUALIFY` `WINDOW``LIMIT`,, et.
+ Vous ne pouvez pas l'utiliser AWS SCT pour convertir des expressions de table communes récursives.
+ AWS SCT ne prend pas en charge la conversion d'`INSERT`instructions contenant des sous-requêtes dans des `VALUES` clauses.
+ AWS SCT ne prend pas en charge la conversion des `UPDATE` instructions pour les champs imbriqués et les enregistrements répétés.
+ Vous ne pouvez pas l'utiliser AWS SCT pour convertir `STRUCT` des types de `ARRAY` données.
## BigQuery vers les paramètres de conversion d'Amazon Redshift
BigQuery Pour modifier les paramètres de conversion d'Amazon Redshift, choisissez **Paramètres** dans AWS SCT, puis sélectionnez Paramètres de **conversion**. Dans la liste supérieure, choisissez **Google BigQuery**, puis **Google BigQuery — Amazon Redshift**. AWS SCT affiche tous les paramètres disponibles pour la BigQuery conversion vers Amazon Redshift.
BigQuery vers les paramètres de conversion Amazon Redshift en AWS SCT incluant des options pour les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour définir le nombre maximum de tables AWS SCT pouvant s'appliquer à votre cluster Amazon Redshift cible.
Pour **le nombre maximum de tables pour le cluster Amazon Redshift cible**, choisissez le nombre de tables qui AWS SCT peuvent s'appliquer à votre cluster Amazon Redshift.
Amazon Redshift dispose de quotas qui limitent l’utilisation des tables pour différents types de nœud de cluster. Si vous choisissez **Auto**, AWS SCT détermine le nombre de tables à appliquer à votre cluster Amazon Redshift cible en fonction du type de nœud. Vous pouvez éventuellement choisir la valeur manuellement. Pour plus d’informations, consultez [Quotas et limites dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) dans le *Guide de gestion Amazon Redshift*.
AWS SCT convertit toutes vos tables sources, même si c'est plus que ce que votre cluster Amazon Redshift peut stocker. AWS SCT stocke le code converti dans votre projet et ne l'applique pas à la base de données cible. Si vous atteignez le quota de cluster Amazon Redshift pour les tables lorsque vous appliquez le code converti, un message d'avertissement s' AWS SCT affiche. AWS SCT Applique également des tables à votre cluster Amazon Redshift cible jusqu'à ce que le nombre de tables atteigne la limite.
+ Pour appliquer une compression aux colonnes d'un tableau Amazon Redshift. Pour ce faire, sélectionnez **Utiliser le codage par compression**.
AWS SCT attribue automatiquement un codage de compression aux colonnes à l'aide de l'algorithme Amazon Redshift par défaut. Pour plus d'informations, consultez la section [Encodages de compression](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) dans le manuel *Amazon Redshift Database* Developer Guide.
Par défaut, Amazon Redshift n'applique pas de compression aux colonnes définies comme clés de tri et de distribution. Vous pouvez modifier ce comportement et appliquer une compression à ces colonnes. Pour ce faire, sélectionnez **Utiliser le codage de compression pour les colonnes KEY**. Vous ne pouvez sélectionner cette option que lorsque vous sélectionnez l'option **Utiliser le codage par compression**.
## BigQuery vers les paramètres d'optimisation de conversion d'Amazon Redshift
BigQuery Pour modifier les paramètres d'optimisation des conversions d'Amazon Redshift, sélectionnez **Paramètres** dans AWS SCT, puis sélectionnez Paramètres de **conversion**. Dans la liste supérieure, choisissez **Google BigQuery**, puis **Google BigQuery — Amazon Redshift**. Dans le volet de gauche, sélectionnez **Stratégies d'optimisation**. AWS SCT affiche les paramètres d'optimisation des conversions pour BigQuery la conversion vers Amazon Redshift.
BigQuery vers les paramètres d'optimisation de conversion d'Amazon Redshift en AWS SCT incluant des options pour les éléments suivants :
+ Pour travailler avec l'optimisation automatique des tables. Pour ce faire, sélectionnez **Utiliser le réglage automatique des tables Amazon Redshift**.
L'optimisation automatique des tables est un processus de réglage automatique dans Amazon Redshift qui optimise automatiquement la conception des tables. Pour plus d'informations, consultez la section [Utilisation de l'optimisation automatique des tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) dans le manuel *Amazon Redshift Database Developer Guide*.
Pour vous fier uniquement à l'optimisation automatique des tables, choisissez **Aucune** pour la **stratégie initiale de sélection des clés**.
+ Pour choisir les clés de tri et de distribution selon votre stratégie.
Vous pouvez choisir des clés de tri et de distribution à l'aide des métadonnées Amazon Redshift, des informations statistiques ou des deux options. Pour **Stratégie initiale de sélection des clés** dans l'onglet **Stratégies d'optimisation**, choisissez l'une des options suivantes :
+ Utiliser des métadonnées, ignorer les informations statistiques
+ Ignorer les métadonnées, utiliser des informations statistiques
+ Utiliser des métadonnées et des informations statistiques
Selon l'option que vous choisissez, vous pouvez sélectionner des stratégies d'optimisation. Entrez ensuite la valeur (0 à 100) pour chaque stratégie. Ces valeurs définissent le poids de chaque stratégie. À l'aide de ces valeurs de pondération, AWS SCT définit l'influence de chaque règle sur le choix des clés de distribution et de tri. Les valeurs par défaut sont basées sur les meilleures pratiques de AWS migration.
Vous pouvez définir la taille des petites tables dans le cadre de la stratégie **Find small tables**. Pour Nombre **minimum de lignes de tableau et Nombre** **maximum de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le définir comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
+ Pour configurer les détails de la stratégie.
Outre la définition du poids pour chaque stratégie d'optimisation, vous pouvez configurer les paramètres d'optimisation. Pour ce faire, choisissez **Optimisation des conversions**.
+ Pour le **champ Limite des colonnes clés de tri**, entrez le nombre maximum de colonnes dans la clé de tri.
+ Pour une **valeur de seuil asymétrique**, entrez le pourcentage (0 à 100) d'une valeur asymétrique pour une colonne. AWS SCT exclut les colonnes dont la valeur d'inclinaison est supérieure au seuil de la liste des candidats pour la clé de distribution. AWS SCT définit la valeur asymétrique d'une colonne comme le pourcentage entre le nombre d'occurrences de la valeur la plus courante et le nombre total d'enregistrements.
+ Pour les **N principales requêtes de la table d'historique** des requêtes, entrez le nombre (1 à 100) des requêtes les plus fréquemment utilisées à analyser.
+ Pour **Sélectionner un utilisateur de statistiques**, choisissez l'utilisateur de base de données pour lequel vous souhaitez analyser les statistiques de requête.
Dans l'onglet **Stratégies d'optimisation**, vous pouvez également définir la taille des petites tables pour la stratégie **Rechercher de petites tables**. Pour Nombre **minimal de lignes de tableau et Nombre** **maximal de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le considérer comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
# Connecter la base de données Greenplum à AWS Schema Conversion Tool
Vous pouvez l'utiliser AWS SCT pour convertir des schémas, des objets de code et du code d'application de la base de données Greenplum vers Amazon Redshift.
## Privilèges pour la base de données Greenplum en tant que source
Les privilèges suivants sont requis pour utiliser la base de données Greenplum en tant que source :
+ CONNEXION À LA BASE DE DONNÉES **
+ UTILISATION SUR LE SCHÉMA **
+ SÉLECTIONNEZ SUR *.*
+ SÉLECTIONNEZ SUR LA SÉQUENCE *.*
Dans l'exemple précédent, remplacez les espaces réservés comme suit :
+ Remplacez *database\$1name* par le nom de la base de données source.
+ Remplacez *schema\$1name* par le nom du schéma source.
+ Remplacez *table\$1name* par le nom de la table source.
+ Remplacez *sequence\$1name* par le nom du nom de séquence.
## Connexion à la base de données Greenplum en tant que source
Utilisez la procédure suivante pour vous connecter à votre base de données source Greenplum avec AWS SCT.
**Pour vous connecter à une base de données source Greenplum**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. Choisissez **SAP ASE**, puis **Next**.
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement :
+ Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes :
1. Pour **AWS Secret**, choisissez le nom du secret.
1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager.
Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Pour saisir manuellement les informations d'identification de la base de données source Greenplum, suivez les instructions suivantes :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.Greenplum.html)
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source.
1. Choisissez **Connect pour vous** connecter à votre base de données source.
## Paramètres de conversion de Greenplum vers Amazon Redshift
**Pour modifier les paramètres de conversion de Greenplum vers Amazon Redshift, **choisissez** Paramètres AWS SCT dans, puis sélectionnez Paramètres de conversion.** Dans la liste supérieure, choisissez **Greenplum**, puis **Greenplum — Amazon Redshift**. AWS SCT affiche tous les paramètres disponibles pour la conversion de Greenplum vers Amazon Redshift.
Les paramètres de conversion de Greenplum vers Amazon Redshift incluent des options pour AWS SCT les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour définir le nombre maximum de tables AWS SCT pouvant s'appliquer à votre cluster Amazon Redshift cible.
Pour **le nombre maximum de tables pour le cluster Amazon Redshift cible**, choisissez le nombre de tables qui AWS SCT peuvent s'appliquer à votre cluster Amazon Redshift.
Amazon Redshift dispose de quotas qui limitent l’utilisation des tables pour différents types de nœud de cluster. Si vous choisissez **Auto**, AWS SCT détermine le nombre de tables à appliquer à votre cluster Amazon Redshift cible en fonction du type de nœud. Vous pouvez éventuellement choisir la valeur manuellement. Pour plus d’informations, consultez [Quotas et limites dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) dans le *Guide de gestion Amazon Redshift*.
AWS SCT convertit toutes vos tables sources, même si c'est plus que ce que votre cluster Amazon Redshift peut stocker. AWS SCT stocke le code converti dans votre projet et ne l'applique pas à la base de données cible. Si vous atteignez le quota de cluster Amazon Redshift pour les tables lorsque vous appliquez le code converti, un message d'avertissement s' AWS SCT affiche. AWS SCT Applique également des tables à votre cluster Amazon Redshift cible jusqu'à ce que le nombre de tables atteigne la limite.
+ Pour migrer des partitions de la table source vers des tables séparées dans Amazon Redshift. Pour ce faire, sélectionnez **Utiliser la vue UNION ALL** et entrez le nombre maximum de tables cibles AWS SCT pouvant être créées pour une seule table source.
Amazon Redshift ne prend pas en charge le partitionnement des tables. Pour imiter ce comportement et accélérer l'exécution des requêtes, AWS SCT vous pouvez migrer chaque partition de votre table source vers une table distincte dans Amazon Redshift. AWS SCT Crée ensuite une vue qui inclut les données de toutes ces tables.
AWS SCT détermine automatiquement le nombre de partitions de votre table source. Selon le type de partitionnement de votre table source, ce nombre peut dépasser le quota de tables que vous pouvez appliquer à votre cluster Amazon Redshift. Pour éviter d'atteindre ce quota, entrez le nombre maximum de tables cibles AWS SCT pouvant être créées pour les partitions d'une seule table source. L'option par défaut est 368 tables, ce qui représente une partition pendant 366 jours par an et deux tables pour `NO RANGE` et `UNKNOWN` partitions.
+ Pour appliquer une compression aux colonnes d'un tableau Amazon Redshift. Pour ce faire, sélectionnez **Utiliser le codage par compression**.
AWS SCT attribue automatiquement un codage de compression aux colonnes à l'aide de l'algorithme Amazon Redshift par défaut. Pour plus d'informations, consultez la section [Encodages de compression](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) dans le manuel *Amazon Redshift Database* Developer Guide.
Par défaut, Amazon Redshift n'applique pas de compression aux colonnes définies comme clés de tri et de distribution. Vous pouvez modifier ce comportement et appliquer une compression à ces colonnes. Pour ce faire, sélectionnez **Utiliser le codage de compression pour les colonnes KEY**. Vous ne pouvez sélectionner cette option que lorsque vous sélectionnez l'option **Utiliser le codage par compression**.
## Paramètres d'optimisation de la conversion de Greenplum vers Amazon Redshift
**Pour modifier les paramètres d'optimisation de conversion de Greenplum vers Amazon Redshift, **choisissez** Paramètres AWS SCT dans, puis sélectionnez Paramètres de conversion.** Dans la liste supérieure, choisissez **Greenplum**, puis **Greenplum — Amazon Redshift**. Dans le volet de gauche, sélectionnez **Stratégies d'optimisation**. AWS SCT affiche les paramètres d'optimisation des conversions pour la conversion de Greenplum vers Amazon Redshift.
Les paramètres AWS SCT d'optimisation de la conversion de Greenplum vers Amazon Redshift incluent des options pour les éléments suivants :
+ Pour travailler avec l'optimisation automatique des tables. Pour ce faire, sélectionnez **Utiliser le réglage automatique des tables Amazon Redshift**.
L'optimisation automatique des tables est un processus de réglage automatique dans Amazon Redshift qui optimise automatiquement la conception des tables. Pour plus d'informations, consultez la section [Utilisation de l'optimisation automatique des tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) dans le manuel *Amazon Redshift Database Developer Guide*.
Pour vous fier uniquement à l'optimisation automatique des tables, choisissez **Aucune** pour la **stratégie initiale de sélection des clés**.
+ Pour choisir les clés de tri et de distribution selon votre stratégie.
Vous pouvez choisir des clés de tri et de distribution à l'aide des métadonnées Amazon Redshift, des informations statistiques ou des deux options. Pour **Stratégie initiale de sélection des clés** dans l'onglet **Stratégies d'optimisation**, choisissez l'une des options suivantes :
+ Utiliser des métadonnées, ignorer les informations statistiques
+ Ignorer les métadonnées, utiliser des informations statistiques
+ Utiliser des métadonnées et des informations statistiques
Selon l'option que vous choisissez, vous pouvez sélectionner des stratégies d'optimisation. Entrez ensuite la valeur (0 à 100) pour chaque stratégie. Ces valeurs définissent le poids de chaque stratégie. À l'aide de ces valeurs de pondération, AWS SCT définit l'influence de chaque règle sur le choix des clés de distribution et de tri. Les valeurs par défaut sont basées sur les meilleures pratiques de AWS migration.
Vous pouvez définir la taille des petites tables dans le cadre de la stratégie **Find small tables**. Pour Nombre **minimum de lignes de tableau et Nombre** **maximum de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le définir comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
+ Pour configurer les détails de la stratégie.
Outre la définition du poids pour chaque stratégie d'optimisation, vous pouvez configurer les paramètres d'optimisation. Pour ce faire, choisissez **Optimisation des conversions**.
+ Pour le **champ Limite des colonnes clés de tri**, entrez le nombre maximum de colonnes dans la clé de tri.
+ Pour une **valeur de seuil asymétrique**, entrez le pourcentage (0 à 100) d'une valeur asymétrique pour une colonne. AWS SCT exclut les colonnes dont la valeur d'inclinaison est supérieure au seuil de la liste des candidats pour la clé de distribution. AWS SCT définit la valeur asymétrique d'une colonne comme le pourcentage entre le nombre d'occurrences de la valeur la plus courante et le nombre total d'enregistrements.
+ Pour les **N principales requêtes de la table d'historique** des requêtes, entrez le nombre (1 à 100) des requêtes les plus fréquemment utilisées à analyser.
+ Pour **Sélectionner un utilisateur de statistiques**, choisissez l'utilisateur de base de données pour lequel vous souhaitez analyser les statistiques de requête.
Dans l'onglet **Stratégies d'optimisation**, vous pouvez également définir la taille des petites tables pour la stratégie **Rechercher de petites tables**. Pour Nombre **minimal de lignes de tableau et Nombre** **maximal de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le considérer comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
# Connexion à Netezza avec AWS Schema Conversion Tool
Vous pouvez l'utiliser AWS SCT pour convertir des schémas, des objets de code et du code d'application de Netezza vers Amazon Redshift.
## Privilèges pour Netezza en tant que source
Les privilèges suivants sont requis pour utiliser Netezza en tant que source :
+ sélectionnez sur la vue system.definition\$1schema.system
+ sélectionnez sur la table system.definition\$1schema.system
+ sélectionnez sur la table system.definition\$1schema.management
+ liste sur **
+ liste sur **
+ liste sur ** .all.table
+ liste sur la table ** .all.external
+ liste sur ** .all.view
+ liste sur la vue ** .all.materialized
+ liste sur ** .all.procedure
+ liste sur ** .all.sequence
+ liste sur ** .all.function
+ liste sur ** .all.aggregate
Dans l'exemple précédent, remplacez les espaces réservés comme suit :
+ Remplacez *database\$1name* par le nom de la base de données source.
+ Remplacez *schema\$1name* par le nom du schéma source.
AWS SCT nécessite l'accès aux tables et vues système suivantes. Vous pouvez accorder l'accès à ces objets au lieu d'accorder l'accès à `system.definition_schema.system view` et `system.definition_schema.system tables` dans la liste précédente.
+ sélectionnez sur system.definition\$1schema. \$1t\$1aggregate
+ sélectionnez sur system.definition\$1schema. \$1t\$1class
+ sélectionnez sur system.definition\$1schema. \$1t\$1contrainte
+ sélectionnez sur system.definition\$1schema. \$1t\$1const\$1relattr
+ sélectionnez sur system.definition\$1schema. \$1t\$1base de données
+ sélectionnez sur system.definition\$1schema. \$1t\$1grpobj\$1priv
+ sélectionnez sur system.definition\$1schema. \$1t\$1groupes
+ sélectionnez sur system.definition\$1schema. \$1t\$1hist\$1config
+ sélectionnez sur system.definition\$1schema. \$1t\$1objet
+ sélectionnez sur system.definition\$1schema. \$1t\$1object\$1classes
+ sélectionnez sur system.definition\$1schema. \$1t\$1proc
+ sélectionnez sur system.definition\$1schema. \$1t\$1type
+ sélectionnez sur system.definition\$1schema. \$1t\$1utilisateur
+ sélectionnez sur system.definition\$1schema. \$1t\$1usrobj\$1priv
+ sélectionnez sur system.definition\$1schema. \$1vt\$1sequence
+ sélectionnez sur system.definition\$1schema. \$1v\$1aggregate
+ sélectionnez sur system.definition\$1schema. \$1v\$1constraint\$1depends
+ sélectionnez sur system.definition\$1schema. \$1v\$1base de données
+ sélectionnez sur system.definition\$1schema. \$1v\$1datatype
+ sélectionnez sur system.definition\$1schema. \$1v\$1dslice
+ sélectionnez sur system.definition\$1schema. fonction \$1v
+ sélectionnez sur system.definition\$1schema. \$1v\$1group
+ sélectionnez sur system.definition\$1schema. \$1v\$1obj\$1relation
+ sélectionnez sur system.definition\$1schema. \$1v\$1obj\$1relation\$1xdb
+ sélectionnez sur system.definition\$1schema. \$1v\$1procédure
+ sélectionnez sur system.definition\$1schema. Colonne \$1v\$1relation\$1
+ sélectionnez sur system.definition\$1schema. \$1v\$1relation\$1keydata
+ sélectionnez sur system.definition\$1schema. classes \$1v\$1relobj
+ sélectionnez sur system.definition\$1schema. \$1v\$1schema\$1xdb
+ sélectionnez sur system.definition\$1schema. \$1v\$1séquence
+ sélectionnez sur system.definition\$1schema. \$1v\$1synonyme
+ sélectionnez sur system.definition\$1schema. \$1v\$1system\$1info
+ sélectionnez sur system.definition\$1schema. \$1v\$1sys\$1contrainte
+ sélectionnez sur system.definition\$1schema. \$1v\$1sys\$1object\$1dslice\$1info
+ sélectionnez sur system.definition\$1schema. \$1v\$1sys\$1utilisateur
+ sélectionnez sur system.definition\$1schema. \$1v\$1table
+ sélectionnez sur system.definition\$1schema. \$1v\$1table\$1contrainte
+ sélectionnez sur system.definition\$1schema. \$1v\$1table\$1dist\$1map
+ sélectionnez sur system.definition\$1schema. \$1v\$1table\$1organiser\$1colonne
+ sélectionnez sur system.definition\$1schema. \$1v\$1table\$1storage\$1stat
+ sélectionnez sur system.definition\$1schema. \$1v\$1utilisateur
+ sélectionnez sur system.definition\$1schema. \$1v\$1view
+ sélectionnez sur system.information\$1schema. Colonne \$1v\$1relation\$1
+ sélectionnez sur system.information\$1schema. \$1v\$1table
+ sélectionnez \$1hist\$1column\$1access\$1\$1
## Connexion à Netezza en tant que source
Utilisez la procédure suivante pour vous connecter à votre base de données source Netezza avec AWS Schema Conversion Tool.
**Pour vous connecter à une base de données source Netezza**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. **Choisissez **Netezza**, puis Next.**
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement :
+ Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes :
1. Pour **AWS Secret**, choisissez le nom du secret.
1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager.
Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Pour saisir manuellement les informations de connexion à la base de données source Netezza, suivez les instructions suivantes :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.Netezza.html)
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source.
1. Choisissez **Connect pour vous** connecter à votre base de données source.
## Configuration de la réplication continue des données
Après avoir converti vos schémas de base de données Netezza et les avoir appliqués à votre base de données Amazon Redshift, vous pouvez migrer les données à l'aide d'agents d'extraction de données. AWS SCT L'agent extrait vos données et les télécharge dans votre compartiment Amazon S3. Vous pouvez ensuite les utiliser AWS SCT pour copier les données d'Amazon S3 vers Amazon Redshift.
Si les données de votre base de données source changent au cours du processus de migration, vous pouvez enregistrer les modifications en cours avec vos agents d'extraction de AWS SCT données. Vous pouvez ensuite répliquer ces modifications en cours dans votre base de données cible après avoir terminé la migration initiale des données. Ce processus est appelé réplication continue des données ou *capture des données de modification* (CDC).
**Pour configurer la réplication continue des données pour les migrations de Netezza vers Amazon Redshift**
1. Dans votre base de données source, créez une base de données historique. Vous pouvez utiliser l'exemple de code suivant dans l'interface de ligne de commande (CLI) de Netezza.
```
nzhistcreatedb -d history_database_name -t query -v 1 -u load_user -o histdb_owner -p your_password
```
Dans l'exemple précédent, remplacez *history\$1database\$1name* par le nom de votre base de données d'historique. Remplacez-le ensuite *load\$1user* par le nom de l'utilisateur que vous avez défini pour charger les données d'historique dans la base de données. Remplacez ensuite *histdb\$1owner* par le nom de l'utilisateur que vous avez défini comme propriétaire de la base de données d'historique. Assurez-vous d'avoir déjà créé cet utilisateur et d'avoir accordé l'`CREATE DATABASE`autorisation. Enfin, remplacez-le *your\$1password* par un mot de passe sécurisé.
1. Configurez la journalisation de l'historique. Pour ce faire, utilisez l'exemple de code suivant.
```
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;
```
Dans l'exemple précédent, remplacez *history\$1configuration\$1name* et *history\$1database\$1name* par les noms de votre configuration d'historique et de votre base de données d'historique. Remplacez-le ensuite *load\$1user* par le nom de l'utilisateur que vous avez défini pour charger les données d'historique dans la base de données. Remplacez-le ensuite *your\$1password* par un mot de passe sécurisé.
1. Accordez des autorisations de lecture pour toutes les tables de la base de données d'historique. Vous pouvez utiliser l'exemple de code suivant pour accorder l'`SELECT`autorisation.
```
GRANT SELECT ON history_database_name.ALL.TABLE TO your_user;
```
Dans l'exemple précédent, remplacez *history\$1database\$1name* par le nom de votre base de données d'historique. *your\$1user*Remplacez-le ensuite par le nom de l'utilisateur disposant d'autorisations minimales pour utiliser votre base de données Netezza. Vous utilisez les informations d'identification de cet utilisateur de base de données dans AWS SCT.
1. Collectez des statistiques pour chaque table de votre schéma source afin d'obtenir des informations sur la cardinalité des colonnes. Vous pouvez utiliser la commande suivante pour générer des statistiques dans votre base de données d'historique.
```
GENERATE STATISTICS on "schema_name"."table_name";
```
Dans l'exemple précédent, remplacez *schema\$1name* et *table\$1name* par le nom du schéma et de la table de votre base de données.
1. Vérifiez que vous avez rempli les conditions requises en exécutant la requête suivante :
```
SELECT COUNT(*) FROM history_database_name.history_schema_name."$hist_column_access_N";
```
Dans l'exemple précédent, remplacez *history\$1database\$1name* et *history\$1schema\$1name* par le nom de votre base de données d'historique et de votre schéma. Remplacez ensuite *N* par le numéro de version de votre base de données d'historique. Pour plus d'informations sur les versions des bases de données historiques, consultez la [documentation IBM Netezza](https://www.ibm.com/docs/en/netezza?topic=history-database-versions).
1. Installez vos agents d'extraction de données. Pour de plus amples informations, veuillez consulter [Installation d'agents d'extraction](agents.md#agents.Installing).
Assurez-vous que le `{working.folder}` paramètre du `settings.properties` fichier pour toutes les instances de l'extracteur pointe vers le même dossier. Dans ce cas, vos extracteurs peuvent coordonner la session CDC et utiliser un point de transaction unique pour toutes les sous-tâches.
1. Enregistrez votre agent d'extraction de données. Pour de plus amples informations, veuillez consulter [Enregistrement des agents d'extraction auprès du AWS Schema Conversion Tool](agents.md#agents.Using).
1. Créez votre tâche CDC. Pour de plus amples informations, veuillez consulter [Création, exécution et surveillance d'une AWS SCT tâche](agents.md#agents.Tasks).
1. Ouvrez votre projet dans AWS SCT. Dans le volet de gauche, choisissez votre table source. Ouvrez le menu contextuel (clic droit), puis choisissez **Créer une tâche locale**.
1. Dans **Nom de la tâche**, entrez un nom descriptif pour votre tâche de migration de données.
1. Pour le **mode migration**, choisissez **Extraire, uploader et copier**.
1. Sélectionnez **Activer le CDC**.
1. Choisissez l'onglet **Paramètres du CDC** et définissez la portée et le calendrier des sessions du CDC.
1. Choisissez **Tâche de test** pour vérifier que vous pouvez vous connecter à votre dossier de travail, à votre compartiment Amazon S3 et à votre entrepôt de données Amazon Redshift.
1. Choisissez **Créer** pour créer votre tâche.
1. Cliquez sur l'onglet **Tâches**, choisissez votre tâche dans la liste, puis sélectionnez **Démarrer**.
1. La AWS SCT tâche assure la cohérence transactionnelle dans la base de données cible. L'agent d'extraction de données réplique les transactions depuis la source dans l'ordre des numéros de transaction.
Si vous arrêtez l'une des sessions de migration ou si elle échoue, le traitement CDC s'arrête également.
## Paramètres de conversion de Netezza vers Amazon Redshift
**Pour modifier les paramètres de conversion de Netezza vers Amazon Redshift, **choisissez Paramètres AWS SCT dans, puis sélectionnez** Paramètres de conversion.** Dans la liste supérieure, choisissez **Netezza**, puis Netezza — **Amazon Redshift**. AWS SCT affiche tous les paramètres disponibles pour la conversion de Netezza vers Amazon Redshift.
Les paramètres de conversion de Netezza vers Amazon Redshift incluent des options pour AWS SCT les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour définir le nombre maximum de tables AWS SCT pouvant s'appliquer à votre cluster Amazon Redshift cible.
Pour **le nombre maximum de tables pour le cluster Amazon Redshift cible**, choisissez le nombre de tables qui AWS SCT peuvent s'appliquer à votre cluster Amazon Redshift.
Amazon Redshift dispose de quotas qui limitent l’utilisation des tables pour différents types de nœud de cluster. Si vous choisissez **Auto**, AWS SCT détermine le nombre de tables à appliquer à votre cluster Amazon Redshift cible en fonction du type de nœud. Vous pouvez éventuellement choisir la valeur manuellement. Pour plus d’informations, consultez [Quotas et limites dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) dans le *Guide de gestion Amazon Redshift*.
AWS SCT convertit toutes vos tables sources, même si c'est plus que ce que votre cluster Amazon Redshift peut stocker. AWS SCT stocke le code converti dans votre projet et ne l'applique pas à la base de données cible. Si vous atteignez le quota de cluster Amazon Redshift pour les tables lorsque vous appliquez le code converti, un message d'avertissement s' AWS SCT affiche. AWS SCT Applique également des tables à votre cluster Amazon Redshift cible jusqu'à ce que le nombre de tables atteigne la limite.
+ Pour appliquer une compression aux colonnes d'un tableau Amazon Redshift. Pour ce faire, sélectionnez **Utiliser le codage par compression**.
AWS SCT attribue automatiquement un codage de compression aux colonnes à l'aide de l'algorithme Amazon Redshift par défaut. Pour plus d'informations, consultez la section [Encodages de compression](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) dans le manuel *Amazon Redshift Database* Developer Guide.
Par défaut, Amazon Redshift n'applique pas de compression aux colonnes définies comme clés de tri et de distribution. Vous pouvez modifier ce comportement et appliquer une compression à ces colonnes. Pour ce faire, sélectionnez **Utiliser le codage de compression pour les colonnes KEY**. Vous ne pouvez sélectionner cette option que lorsque vous sélectionnez l'option **Utiliser le codage par compression**.
## Paramètres d'optimisation de la conversion de Netezza vers Amazon Redshift
**Pour modifier les paramètres d'optimisation de conversion de Netezza vers Amazon Redshift, **choisissez Paramètres AWS SCT dans, puis sélectionnez** Paramètres de conversion.** Dans la liste supérieure, choisissez **Netezza**, puis Netezza — **Amazon Redshift**. Dans le volet de gauche, sélectionnez **Stratégies d'optimisation**. AWS SCT affiche les paramètres d'optimisation des conversions pour la conversion de Netezza vers Amazon Redshift.
Les paramètres d'optimisation de la conversion de Netezza vers Amazon Redshift incluent des options pour AWS SCT les éléments suivants :
+ Pour travailler avec l'optimisation automatique des tables. Pour ce faire, sélectionnez **Utiliser le réglage automatique des tables Amazon Redshift**.
L'optimisation automatique des tables est un processus de réglage automatique dans Amazon Redshift qui optimise automatiquement la conception des tables. Pour plus d'informations, consultez la section [Utilisation de l'optimisation automatique des tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) dans le manuel *Amazon Redshift Database Developer Guide*.
Pour vous fier uniquement à l'optimisation automatique des tables, choisissez **Aucune** pour la **stratégie initiale de sélection des clés**.
+ Pour choisir les clés de tri et de distribution selon votre stratégie.
Vous pouvez choisir des clés de tri et de distribution à l'aide des métadonnées Amazon Redshift, des informations statistiques ou des deux options. Pour **Stratégie initiale de sélection des clés** dans l'onglet **Stratégies d'optimisation**, choisissez l'une des options suivantes :
+ Utiliser des métadonnées, ignorer les informations statistiques
+ Ignorer les métadonnées, utiliser des informations statistiques
+ Utiliser des métadonnées et des informations statistiques
Selon l'option que vous choisissez, vous pouvez sélectionner des stratégies d'optimisation. Entrez ensuite la valeur (0 à 100) pour chaque stratégie. Ces valeurs définissent le poids de chaque stratégie. À l'aide de ces valeurs de pondération, AWS SCT définit l'influence de chaque règle sur le choix des clés de distribution et de tri. Les valeurs par défaut sont basées sur les meilleures pratiques de AWS migration.
Vous pouvez définir la taille des petites tables dans le cadre de la stratégie **Find small tables**. Pour Nombre **minimum de lignes de tableau et Nombre** **maximum de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le définir comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
+ Pour configurer les détails de la stratégie.
Outre la définition du poids pour chaque stratégie d'optimisation, vous pouvez configurer les paramètres d'optimisation. Pour ce faire, choisissez **Optimisation des conversions**.
+ Pour le **champ Limite des colonnes clés de tri**, entrez le nombre maximum de colonnes dans la clé de tri.
+ Pour une **valeur de seuil asymétrique**, entrez le pourcentage (0 à 100) d'une valeur asymétrique pour une colonne. AWS SCT exclut les colonnes dont la valeur d'inclinaison est supérieure au seuil de la liste des candidats pour la clé de distribution. AWS SCT définit la valeur asymétrique d'une colonne comme le pourcentage entre le nombre d'occurrences de la valeur la plus courante et le nombre total d'enregistrements.
+ Pour les **N principales requêtes de la table d'historique** des requêtes, entrez le nombre (1 à 100) des requêtes les plus fréquemment utilisées à analyser.
+ Pour **Sélectionner un utilisateur de statistiques**, choisissez l'utilisateur de base de données pour lequel vous souhaitez analyser les statistiques de requête.
Dans l'onglet **Stratégies d'optimisation**, vous pouvez également définir la taille des petites tables pour la stratégie **Rechercher de petites tables**. Pour Nombre **minimal de lignes de tableau et Nombre** **maximal de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le considérer comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
# Connecter Oracle Data Warehouse à AWS SCT
Vous pouvez les utiliser AWS SCT pour convertir des schémas, des objets de code et du code d'application d'Oracle Data Warehouse vers Amazon Redshift ou Amazon Redshift et les utiliser en combinaison AWS Glue .
## Privilèges pour Oracle Data Warehouse en tant que source
Les privilèges suivants sont requis pour utiliser Oracle Data Warehouse comme source :
+ connect
+ select\$1catalog\$1role
+ select any dictionary
## Connexion à Oracle Data Warehouse en tant que source
Utilisez la procédure suivante pour vous connecter à votre base de données source d'entrepôt de données Oracle avec AWS Schema Conversion Tool.
**Pour vous connecter à une base de données source Oracle Data Warehouse**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. Choisissez **Oracle**, puis **Next**.
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement :
+ Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes :
1. Pour **AWS Secret**, choisissez le nom du secret.
1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager.
Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Pour saisir manuellement les informations de connexion à l'entrepôt de données source Oracle, suivez les instructions suivantes :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.OracleDW.html)
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source.
1. Choisissez **Connect pour vous** connecter à votre base de données source.
## Paramètres de conversion d’Oracle Data Warehouse vers Amazon Redshift
Pour modifier les paramètres de conversion d'Oracle Data Warehouse vers Amazon Redshift, sélectionnez **Paramètres** dans AWS SCT, puis sélectionnez Paramètres de **conversion**. Dans la liste supérieure, choisissez **Oracle**, puis **Oracle — Amazon Redshift**. AWS SCT affiche tous les paramètres disponibles pour la conversion d'Oracle Data Warehouse vers Amazon Redshift.
Les paramètres de conversion d'Oracle Data Warehouse vers Amazon Redshift AWS SCT incluent des options pour les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour définir le nombre maximum de tables AWS SCT pouvant s'appliquer à votre cluster Amazon Redshift cible.
Pour **le nombre maximum de tables pour le cluster Amazon Redshift cible**, choisissez le nombre de tables qui AWS SCT peuvent s'appliquer à votre cluster Amazon Redshift.
Amazon Redshift dispose de quotas qui limitent l’utilisation des tables pour différents types de nœud de cluster. Si vous choisissez **Auto**, AWS SCT détermine le nombre de tables à appliquer à votre cluster Amazon Redshift cible en fonction du type de nœud. Vous pouvez éventuellement choisir la valeur manuellement. Pour plus d’informations, consultez [Quotas et limites dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) dans le *Guide de gestion Amazon Redshift*.
AWS SCT convertit toutes vos tables sources, même si c'est plus que ce que votre cluster Amazon Redshift peut stocker. AWS SCT stocke le code converti dans votre projet et ne l'applique pas à la base de données cible. Si vous atteignez le quota de cluster Amazon Redshift pour les tables lorsque vous appliquez le code converti, un message d'avertissement s' AWS SCT affiche. AWS SCT Applique également des tables à votre cluster Amazon Redshift cible jusqu'à ce que le nombre de tables atteigne la limite.
+ Pour migrer des partitions de la table source vers des tables séparées dans Amazon Redshift. Pour ce faire, sélectionnez **Utiliser la vue UNION ALL** et entrez le nombre maximum de tables cibles AWS SCT pouvant être créées pour une seule table source.
Amazon Redshift ne prend pas en charge le partitionnement des tables. Pour imiter ce comportement et accélérer l'exécution des requêtes, AWS SCT vous pouvez migrer chaque partition de votre table source vers une table distincte dans Amazon Redshift. AWS SCT Crée ensuite une vue qui inclut les données de toutes ces tables.
AWS SCT détermine automatiquement le nombre de partitions de votre table source. Selon le type de partitionnement de votre table source, ce nombre peut dépasser le quota de tables que vous pouvez appliquer à votre cluster Amazon Redshift. Pour éviter d'atteindre ce quota, entrez le nombre maximum de tables cibles AWS SCT pouvant être créées pour les partitions d'une seule table source. L'option par défaut est 368 tables, ce qui représente une partition pendant 366 jours par an et deux tables pour `NO RANGE` et `UNKNOWN` partitions.
+ Pour convertir les fonctions de formatage des types de données telles que `TO_CHAR``TO_DATE`, et `TO_NUMBER` avec des éléments de format datetime non pris en charge par Amazon Redshift. Par défaut, AWS SCT utilise les fonctions du pack d'extension pour émuler l'utilisation de ces éléments de format non pris en charge dans le code converti.
Le modèle de format datetime d'Oracle inclut davantage d'éléments que les chaînes de format datetime d'Amazon Redshift. Lorsque votre code source inclut uniquement des éléments de format datetime pris en charge par Amazon Redshift, vous n'avez pas besoin des fonctions du pack d'extension dans le code converti. Pour éviter d'utiliser les fonctions du pack d'extension dans le code converti, sélectionnez les **éléments de format Datetype que vous utilisez dans le code Oracle qui sont similaires aux chaînes de format datetime dans Amazon Redshift**. Dans ce cas, le code converti fonctionne plus rapidement.
Le modèle de format numérique d'Oracle inclut davantage d'éléments que les chaînes de format numérique d'Amazon Redshift. Lorsque votre code source inclut uniquement des éléments de format numérique pris en charge par Amazon Redshift, vous n'avez pas besoin des fonctions du pack d'extension dans le code converti. Pour éviter d'utiliser les fonctions du pack d'extension dans le code converti, sélectionnez Les **éléments de format numérique que vous utilisez dans le code Oracle sont similaires aux chaînes de format numérique dans Amazon Redshift**. Dans ce cas, le code converti fonctionne plus rapidement.
+ Pour convertir des fonctions Oracle `LEAD` et `LAG` analytiques. Par défaut, AWS SCT déclenche une action pour chaque `LAG` fonction `LEAD` et.
Lorsque votre code source n'utilise pas les valeurs par défaut pour le décalage dans ces fonctions, AWS SCT vous pouvez émuler l'utilisation de ces fonctions avec la `NVL` fonction. Pour ce faire, sélectionnez **Utiliser la fonction NVL pour émuler le comportement des fonctions Oracle LEAD et LAG**.
+ Pour émuler le comportement des clés primaires et uniques dans votre cluster Amazon Redshift, **sélectionnez Émuler le comportement des clés primaires** et uniques.
Amazon Redshift n'applique pas les clés uniques et primaires et ne les utilise qu'à des fins d'information. Si vous utilisez ces contraintes dans votre code, assurez-vous qu'elles AWS SCT imitent leur comportement dans le code converti.
+ Pour appliquer une compression aux colonnes d'un tableau Amazon Redshift. Pour ce faire, sélectionnez **Utiliser le codage par compression**.
AWS SCT attribue automatiquement un codage de compression aux colonnes à l'aide de l'algorithme Amazon Redshift par défaut. Pour plus d'informations, consultez la section [Encodages de compression](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) dans le manuel *Amazon Redshift Database* Developer Guide.
Par défaut, Amazon Redshift n'applique pas de compression aux colonnes définies comme clés de tri et de distribution. Vous pouvez modifier ce comportement et appliquer une compression à ces colonnes. Pour ce faire, sélectionnez **Utiliser le codage de compression pour les colonnes KEY**. Vous ne pouvez sélectionner cette option que lorsque vous sélectionnez l'option **Utiliser le codage par compression**.
## Paramètres d'optimisation de la conversion d'Oracle Data Warehouse vers Amazon Redshift
Pour modifier les paramètres d'optimisation de conversion d'Oracle Data Warehouse vers Amazon Redshift, sélectionnez **Paramètres** dans AWS SCT, puis sélectionnez Paramètres de **conversion**. Dans la liste supérieure, choisissez **Oracle**, puis **Oracle — Amazon Redshift**. Dans le volet de gauche, sélectionnez **Stratégies d'optimisation**. AWS SCT affiche les paramètres d'optimisation des conversions pour la conversion d'Oracle Data Warehouse vers Amazon Redshift.
Les paramètres d'optimisation de la conversion d'Oracle Data Warehouse vers Amazon Redshift AWS SCT incluent des options pour les éléments suivants :
+ Pour travailler avec l'optimisation automatique des tables. Pour ce faire, sélectionnez **Utiliser le réglage automatique des tables Amazon Redshift**.
L'optimisation automatique des tables est un processus de réglage automatique dans Amazon Redshift qui optimise automatiquement la conception des tables. Pour plus d'informations, consultez la section [Utilisation de l'optimisation automatique des tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) dans le manuel *Amazon Redshift Database Developer Guide*.
Pour vous fier uniquement à l'optimisation automatique des tables, choisissez **Aucune** pour la **stratégie initiale de sélection des clés**.
+ Pour choisir les clés de tri et de distribution selon votre stratégie.
Vous pouvez choisir des clés de tri et de distribution à l'aide des métadonnées Amazon Redshift, des informations statistiques ou des deux options. Pour **Stratégie initiale de sélection des clés** dans l'onglet **Stratégies d'optimisation**, choisissez l'une des options suivantes :
+ Utiliser des métadonnées, ignorer les informations statistiques
+ Ignorer les métadonnées, utiliser des informations statistiques
+ Utiliser des métadonnées et des informations statistiques
Selon l'option que vous choisissez, vous pouvez sélectionner des stratégies d'optimisation. Entrez ensuite la valeur (0 à 100) pour chaque stratégie. Ces valeurs définissent le poids de chaque stratégie. À l'aide de ces valeurs de pondération, AWS SCT définit l'influence de chaque règle sur le choix des clés de distribution et de tri. Les valeurs par défaut sont basées sur les meilleures pratiques de AWS migration.
Vous pouvez définir la taille des petites tables dans le cadre de la stratégie **Find small tables**. Pour Nombre **minimum de lignes de tableau et Nombre** **maximum de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le définir comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
+ Pour configurer les détails de la stratégie.
Outre la définition du poids pour chaque stratégie d'optimisation, vous pouvez configurer les paramètres d'optimisation. Pour ce faire, choisissez **Optimisation des conversions**.
+ Pour le **champ Limite des colonnes clés de tri**, entrez le nombre maximum de colonnes dans la clé de tri.
+ Pour une **valeur de seuil asymétrique**, entrez le pourcentage (0 à 100) d'une valeur asymétrique pour une colonne. AWS SCT exclut les colonnes dont la valeur d'inclinaison est supérieure au seuil de la liste des candidats pour la clé de distribution. AWS SCT définit la valeur asymétrique d'une colonne comme le pourcentage entre le nombre d'occurrences de la valeur la plus courante et le nombre total d'enregistrements.
+ Pour les **N principales requêtes de la table d'historique** des requêtes, entrez le nombre (1 à 100) des requêtes les plus fréquemment utilisées à analyser.
+ Pour **Sélectionner un utilisateur de statistiques**, choisissez l'utilisateur de base de données pour lequel vous souhaitez analyser les statistiques de requête.
Dans l'onglet **Stratégies d'optimisation**, vous pouvez également définir la taille des petites tables pour la stratégie **Rechercher de petites tables**. Pour Nombre **minimal de lignes de tableau et Nombre** **maximal de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le considérer comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
# Connexion à un entrepôt de données Snowflake avec AWS Schema Conversion Tool
Vous pouvez l'utiliser AWS SCT pour convertir des schémas, des objets de code et du code d'application de Snowflake vers Amazon Redshift.
## Privilèges pour Snowflake en tant que base de données source
Vous pouvez créer un rôle doté de privilèges et attribuer à ce rôle le nom d'un utilisateur en utilisant le `SECURITYADMIN` rôle et le contexte de `SECURITYADMIN` session.
L'exemple suivant crée des privilèges minimaux et les accorde à l'`min_privs`utilisateur.
```
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;
```
Dans l'exemple précédent, remplacez les espaces réservés comme suit :
+ *`role_name`*Remplacez-le par le nom d'un rôle doté de privilèges de lecture seule.
+ Remplacez `db_name` par le nom de la base de données source.
+ Remplacez `schema_name` par le nom du schéma source.
+ Remplacez *`datawarehousename`* par le nom d'un entrepôt de données requis.
+ Remplacez `min_privs` par le nom d'un utilisateur disposant de privilèges minimaux.
Les `DEFAULT_WAREHOUSE` paramètres `DEFAULT_ROLE` et sont sensibles aux touches.
## Configuration de l'accès sécurisé à Amazon S3
Les politiques de sécurité et de gestion des accès pour un compartiment Amazon S3 permettent à Snowflake d'accéder au compartiment S3, de lire des données et d'y écrire des données. Vous pouvez configurer un accès sécurisé à un compartiment Amazon S3 privé à l'aide du type d'`STORAGE INTEGRATION`objet Snowflake. Un objet d'intégration de stockage Snowflake délègue la responsabilité de l'authentification à une entité de gestion des identités et des accès Snowflake.
Pour plus d'informations, consultez [la section Configuration d'une intégration de stockage Snowflake pour accéder à Amazon S3](https://docs.snowflake.com/en/user-guide/data-load-s3-config-storage-integration.html) dans la documentation de Snowflake.
## Connexion à Snowflake en tant que source
Suivez la procédure ci-dessous pour vous connecter à votre base de données source à l'aide du AWS Schema Conversion Tool.
**Pour vous connecter à une base de données source Snowflake**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. **Choisissez **Snowflake**, puis Next.**
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement :
+ Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes :
1. Pour **AWS Secret**, choisissez le nom du secret.
1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager.
Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Pour saisir manuellement les informations de connexion à l'entrepôt de données source Snowflake, suivez les instructions suivantes :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.Snowflake.html)
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source.
1. Choisissez **Connect pour vous** connecter à votre base de données source.
## Limitations de Snowflake en tant que source
Les limites suivantes s'appliquent à l'utilisation de Snowflake comme source pour : AWS SCT
+ Les identificateurs d'objet doivent être uniques dans le contexte du type d'objet et de l'objet parent :
**Base de données**
Les identificateurs de schéma doivent être uniques au sein d'une base de données.
**Schémas**
Les identifiants d'objets tels que les tables et les vues doivent être uniques au sein d'un schéma.
**Tables/Vues**
Les identificateurs de colonne doivent être uniques dans une table.
+ Le nombre maximal de tables pour les types de nœud de cluster large et xlarge est de 9 900. Pour les types de nœuds de cluster de 8 x large, le nombre maximum de tables est de 100 000. La limite inclut les tables temporaires, définies par l'utilisateur et créées par Amazon Redshift lors du traitement des requêtes ou de la maintenance du système. Pour plus d'informations, consultez la rubrique [Quotas Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) dans le *Guide de la gestion du cluster Amazon Redshift*.
+ Pour les procédures stockées, le nombre maximum d'arguments d'entrée et de sortie est de 32.
## Types de données source pour Snowflake
Vous trouverez ci-dessous les types de données source Snowflake pris en charge lors de l'utilisation AWS SCT et le mappage par défaut vers une cible Amazon Redshift.
| Types de données Snowflake | Types de données Amazon Redshift |
| --- | --- |
| NOMBRE | NUMÉRIQUE (38) |
| NUMÉRO (p) | Si p est =< 4, alors SMALLINT Si p est => 5 et =< 9, alors INTEGER Si p est => 10 et =< 18, alors BIGINT Si p est => 19 alors NUMERIC (p) |
| NUMÉRO (p, 0) | Si p est =< 4, alors SMALLINT Si p est => 5 et =< 9, alors INTEGER Si p est => 10 et =< 18, alors BIGINT Si p est => 19 alors : NUMERIC (p,0) |
| NUMÉRO (p, s) | Si p est => 1 et =< 38, et si s est => 1 et =< 37, alors NUMERIC(p,s) |
| FLOAT | FLOAT |
| TEXT Caractères Unicode jusqu'à 16 777 216 octets ; jusqu'à 4 octets par caractère. | VARCHAR(MAX) |
| TEXTE (p) Caractères Unicode jusqu'à 65 535 octets ; jusqu'à 4 octets par caractère. | Si p est =< 65 535 alors, VARCHAR (p) |
| TEXTE (p) Caractères Unicode jusqu'à 16 777 216 octets ; jusqu'à 4 octets par caractère. | Si p est => 65 535 et =< 16 777 216 alors, VARCHAR (MAX) |
| BINAIRE Caractères à un octet jusqu'à 8 388 608 octets ; 1 octet par caractère. | VARCHAR(MAX) |
| BINAIRE (p) Caractères à un octet jusqu'à 65 535 octets ; 1 octet par caractère. | VARCHAR (p) |
| BINAIRE (p) Caractères à un octet jusqu'à 8 388 608 octets ; 1 octet par caractère. | VARCHAR(MAX) |
| BOOLEAN | BOOLEAN |
| DATE | DATE |
| TIME Valeurs temporelles comprises entre 00:00:00 et 23:59:59.999 999999. | VARCHAR(18) |
| HEURE (f) Valeurs temporelles comprises entre 00:00:00 et 23:59:59.9 (f). | VARCHAR (n) — 9 \$1 dt-attr-1 |
| TIMESTAMP\$1NTZ | TIMESTAMP |
| TIMESTAMP\$1TZ | TIMESTAMPTZ |
## Paramètres de conversion de Snowflake vers Amazon Redshift
**Pour modifier les paramètres de conversion de Snowflake vers Amazon Redshift, **choisissez Paramètres AWS SCT dans, puis sélectionnez** Paramètres de conversion.** Dans la liste supérieure, choisissez **Snowflake**, puis Snowflake — **Amazon Redshift**. AWS SCT affiche tous les paramètres disponibles pour la conversion de Snowflake vers Amazon Redshift.
Les paramètres de conversion de Snowflake vers Amazon Redshift incluent des options pour AWS SCT les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour définir le nombre maximum de tables AWS SCT pouvant s'appliquer à votre cluster Amazon Redshift cible.
Pour **le nombre maximum de tables pour le cluster Amazon Redshift cible**, choisissez le nombre de tables qui AWS SCT peuvent s'appliquer à votre cluster Amazon Redshift.
Amazon Redshift dispose de quotas qui limitent l’utilisation des tables pour différents types de nœud de cluster. Si vous choisissez **Auto**, AWS SCT détermine le nombre de tables à appliquer à votre cluster Amazon Redshift cible en fonction du type de nœud. Vous pouvez éventuellement choisir la valeur manuellement. Pour plus d’informations, consultez [Quotas et limites dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) dans le *Guide de gestion Amazon Redshift*.
AWS SCT convertit toutes vos tables sources, même si c'est plus que ce que votre cluster Amazon Redshift peut stocker. AWS SCT stocke le code converti dans votre projet et ne l'applique pas à la base de données cible. Si vous atteignez le quota de cluster Amazon Redshift pour les tables lorsque vous appliquez le code converti, un message d'avertissement s' AWS SCT affiche. AWS SCT Applique également des tables à votre cluster Amazon Redshift cible jusqu'à ce que le nombre de tables atteigne la limite.
+ Pour appliquer une compression aux colonnes d'un tableau Amazon Redshift. Pour ce faire, sélectionnez **Utiliser le codage par compression**.
AWS SCT attribue automatiquement un codage de compression aux colonnes à l'aide de l'algorithme Amazon Redshift par défaut. Pour plus d'informations, consultez la section [Encodages de compression](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) dans le manuel *Amazon Redshift Database* Developer Guide.
Par défaut, Amazon Redshift n'applique pas de compression aux colonnes définies comme clés de tri et de distribution. Vous pouvez modifier ce comportement et appliquer une compression à ces colonnes. Pour ce faire, sélectionnez **Utiliser le codage de compression pour les colonnes KEY**. Vous ne pouvez sélectionner cette option que lorsque vous sélectionnez l'option **Utiliser le codage par compression**.
## Paramètres d'optimisation de la conversion de Snowflake vers Amazon Redshift
**Pour modifier les paramètres d'optimisation de conversion de Snowflake vers Amazon Redshift, **choisissez Paramètres AWS SCT dans, puis sélectionnez** Paramètres de conversion.** Dans la liste supérieure, choisissez **Snowflake**, puis Snowflake — **Amazon Redshift**. Dans le volet de gauche, sélectionnez **Stratégies d'optimisation**. AWS SCT affiche les paramètres d'optimisation des conversions pour la conversion de Snowflake vers Amazon Redshift.
Les paramètres d'optimisation de la conversion de Snowflake vers Amazon Redshift incluent des options pour AWS SCT les éléments suivants :
+ Pour travailler avec l'optimisation automatique des tables. Pour ce faire, sélectionnez **Utiliser le réglage automatique des tables Amazon Redshift**.
L'optimisation automatique des tables est un processus de réglage automatique dans Amazon Redshift qui optimise automatiquement la conception des tables. Pour plus d'informations, consultez la section [Utilisation de l'optimisation automatique des tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) dans le manuel *Amazon Redshift Database Developer Guide*.
Pour vous fier uniquement à l'optimisation automatique des tables, choisissez **Aucune** pour la **stratégie initiale de sélection des clés**.
+ Pour choisir les clés de tri et de distribution selon votre stratégie.
Vous pouvez choisir des clés de tri et de distribution à l'aide des métadonnées Amazon Redshift, des informations statistiques ou des deux options. Pour **Stratégie initiale de sélection des clés** dans l'onglet **Stratégies d'optimisation**, choisissez l'une des options suivantes :
+ Utiliser des métadonnées, ignorer les informations statistiques
+ Ignorer les métadonnées, utiliser des informations statistiques
+ Utiliser des métadonnées et des informations statistiques
Selon l'option que vous choisissez, vous pouvez sélectionner des stratégies d'optimisation. Entrez ensuite la valeur (0 à 100) pour chaque stratégie. Ces valeurs définissent le poids de chaque stratégie. À l'aide de ces valeurs de pondération, AWS SCT définit l'influence de chaque règle sur le choix des clés de distribution et de tri. Les valeurs par défaut sont basées sur les meilleures pratiques de AWS migration.
Vous pouvez définir la taille des petites tables dans le cadre de la stratégie **Find small tables**. Pour Nombre **minimum de lignes de tableau et Nombre** **maximum de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le définir comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
+ Pour configurer les détails de la stratégie.
Outre la définition du poids pour chaque stratégie d'optimisation, vous pouvez configurer les paramètres d'optimisation. Pour ce faire, choisissez **Optimisation des conversions**.
+ Pour le **champ Limite des colonnes clés de tri**, entrez le nombre maximum de colonnes dans la clé de tri.
+ Pour une **valeur de seuil asymétrique**, entrez le pourcentage (0 à 100) d'une valeur asymétrique pour une colonne. AWS SCT exclut les colonnes dont la valeur d'inclinaison est supérieure au seuil de la liste des candidats pour la clé de distribution. AWS SCT définit la valeur asymétrique d'une colonne comme le pourcentage entre le nombre d'occurrences de la valeur la plus courante et le nombre total d'enregistrements.
+ Pour les **N principales requêtes de la table d'historique** des requêtes, entrez le nombre (1 à 100) des requêtes les plus fréquemment utilisées à analyser.
+ Pour **Sélectionner un utilisateur de statistiques**, choisissez l'utilisateur de base de données pour lequel vous souhaitez analyser les statistiques de requête.
Dans l'onglet **Stratégies d'optimisation**, vous pouvez également définir la taille des petites tables pour la stratégie **Rechercher de petites tables**. Pour Nombre **minimal de lignes de tableau et Nombre** **maximal de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le considérer comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
# Connexion à un entrepôt de données SQL Server à l'aide du AWS Schema Conversion Tool
Vous pouvez les utiliser AWS SCT pour convertir des schémas, des objets de code et du code d'application de Microsoft SQL Server DW vers Amazon Redshift ou Amazon Redshift et les utiliser en combinaison. AWS Glue
## Privilèges pour Microsoft SQL Server Data Warehouse en tant que source
Les privilèges suivants sont requis pour utiliser l'entrepôt de données Microsoft SQL Server comme source :
+ VIEW DEFINITION
+ VIEW DATABASE STATE
+ SÉLECTIONNEZ SUR LE SCHÉMA : **
Dans l'exemple précédent, remplacez l'**espace réservé par le nom de la source source\$1schema.
Répétez l'octroi pour chaque base de données dont vous convertissez le schéma.
En outre, accordez les privilèges suivants et exécutez l'octroi sur la base de données principale :
+ VIEW SERVER STATE
## Limitations de l'entrepôt de données SQL Server en tant que source
L'utilisation de Microsoft SQL Server Parallel Data Warehouse (PDW) comme source n'est actuellement pas prise en charge.
## Connexion à l'entrepôt de données SQL Server en tant que source
Utilisez la procédure suivante pour vous connecter à votre base de données source SQL Server Data Warehouse avec le AWS Schema Conversion Tool.
**Pour vous connecter à une base de données source SQL Server Data Warehouse**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. Choisissez **Microsoft SQL Server**, puis **Next**.
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement :
+ Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes :
1. Pour **AWS Secret**, choisissez le nom du secret.
1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager.
Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Pour saisir manuellement les informations de connexion à l'entrepôt de données source Microsoft SQL Server, suivez les instructions suivantes :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServerDW.html)
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source.
1. Choisissez **Connect pour vous** connecter à votre base de données source.
## Paramètres de conversion de SQL Server Data Warehouse vers Amazon Redshift
Pour modifier les paramètres de conversion de SQL Server Data Warehouse vers Amazon Redshift, sélectionnez **Paramètres** dans AWS SCT, puis Paramètres de **conversion**. Dans la liste supérieure, choisissez **Microsoft SQL Server**, puis **Microsoft SQL Server — Amazon Redshift**. AWS SCT affiche tous les paramètres disponibles pour la conversion de SQL Server Data Warehouse vers Amazon Redshift.
Les paramètres de conversion de SQL Server Data Warehouse vers Amazon Redshift AWS SCT incluent des options pour les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour définir le nombre maximum de tables AWS SCT pouvant s'appliquer à votre cluster Amazon Redshift cible.
Pour **le nombre maximum de tables pour le cluster Amazon Redshift cible**, choisissez le nombre de tables qui AWS SCT peuvent s'appliquer à votre cluster Amazon Redshift.
Amazon Redshift dispose de quotas qui limitent l’utilisation des tables pour différents types de nœud de cluster. Si vous choisissez **Auto**, AWS SCT détermine le nombre de tables à appliquer à votre cluster Amazon Redshift cible en fonction du type de nœud. Vous pouvez éventuellement choisir la valeur manuellement. Pour plus d’informations, consultez [Quotas et limites dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) dans le *Guide de gestion Amazon Redshift*.
AWS SCT convertit toutes vos tables sources, même si c'est plus que ce que votre cluster Amazon Redshift peut stocker. AWS SCT stocke le code converti dans votre projet et ne l'applique pas à la base de données cible. Si vous atteignez le quota de cluster Amazon Redshift pour les tables lorsque vous appliquez le code converti, un message d'avertissement s' AWS SCT affiche. AWS SCT Applique également des tables à votre cluster Amazon Redshift cible jusqu'à ce que le nombre de tables atteigne la limite.
+ Pour migrer des partitions de la table source vers des tables séparées dans Amazon Redshift. Pour ce faire, sélectionnez **Utiliser la vue UNION ALL** et entrez le nombre maximum de tables cibles AWS SCT pouvant être créées pour une seule table source.
Amazon Redshift ne prend pas en charge le partitionnement des tables. Pour imiter ce comportement et accélérer l'exécution des requêtes, AWS SCT vous pouvez migrer chaque partition de votre table source vers une table distincte dans Amazon Redshift. AWS SCT Crée ensuite une vue qui inclut les données de toutes ces tables.
AWS SCT détermine automatiquement le nombre de partitions de votre table source. Selon le type de partitionnement de votre table source, ce nombre peut dépasser le quota de tables que vous pouvez appliquer à votre cluster Amazon Redshift. Pour éviter d'atteindre ce quota, entrez le nombre maximum de tables cibles AWS SCT pouvant être créées pour les partitions d'une seule table source. L'option par défaut est 368 tables, ce qui représente une partition pendant 366 jours par an et deux tables pour `NO RANGE` et `UNKNOWN` partitions.
+ Pour appliquer une compression aux colonnes d'un tableau Amazon Redshift. Pour ce faire, sélectionnez **Utiliser le codage par compression**.
AWS SCT attribue automatiquement un codage de compression aux colonnes à l'aide de l'algorithme Amazon Redshift par défaut. Pour plus d'informations, consultez la section [Encodages de compression](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) dans le manuel *Amazon Redshift Database* Developer Guide.
Par défaut, Amazon Redshift n'applique pas de compression aux colonnes définies comme clés de tri et de distribution. Vous pouvez modifier ce comportement et appliquer une compression à ces colonnes. Pour ce faire, sélectionnez **Utiliser le codage de compression pour les colonnes KEY**. Vous ne pouvez sélectionner cette option que lorsque vous sélectionnez l'option **Utiliser le codage par compression**.
## Paramètres d'optimisation de la conversion de SQL Server Data Warehouse vers Amazon Redshift
Pour modifier les paramètres d'optimisation de conversion de SQL Server Data Warehouse vers Amazon Redshift, sélectionnez **Paramètres** dans AWS SCT, puis Paramètres de **conversion**. Dans la liste supérieure, choisissez **Microsoft SQL Server**, puis **Microsoft SQL Server — Amazon Redshift**. Dans le volet de gauche, sélectionnez **Stratégies d'optimisation**. AWS SCT affiche les paramètres d'optimisation de la conversion pour la conversion de SQL Server Data Warehouse vers Amazon Redshift.
Les paramètres d'optimisation de la conversion de SQL Server Data Warehouse vers Amazon Redshift AWS SCT incluent des options pour les éléments suivants :
+ Pour travailler avec l'optimisation automatique des tables. Pour ce faire, sélectionnez **Utiliser le réglage automatique des tables Amazon Redshift**.
L'optimisation automatique des tables est un processus de réglage automatique dans Amazon Redshift qui optimise automatiquement la conception des tables. Pour plus d'informations, consultez la section [Utilisation de l'optimisation automatique des tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) dans le manuel *Amazon Redshift Database Developer Guide*.
Pour vous fier uniquement à l'optimisation automatique des tables, choisissez **Aucune** pour la **stratégie initiale de sélection des clés**.
+ Pour choisir les clés de tri et de distribution selon votre stratégie.
Vous pouvez choisir des clés de tri et de distribution à l'aide des métadonnées Amazon Redshift, des informations statistiques ou des deux options. Pour **Stratégie initiale de sélection des clés** dans l'onglet **Stratégies d'optimisation**, choisissez l'une des options suivantes :
+ Utiliser des métadonnées, ignorer les informations statistiques
+ Ignorer les métadonnées, utiliser des informations statistiques
+ Utiliser des métadonnées et des informations statistiques
Selon l'option que vous choisissez, vous pouvez sélectionner des stratégies d'optimisation. Entrez ensuite la valeur (0 à 100) pour chaque stratégie. Ces valeurs définissent le poids de chaque stratégie. À l'aide de ces valeurs de pondération, AWS SCT définit l'influence de chaque règle sur le choix des clés de distribution et de tri. Les valeurs par défaut sont basées sur les meilleures pratiques de AWS migration.
Vous pouvez définir la taille des petites tables dans le cadre de la stratégie **Find small tables**. Pour Nombre **minimum de lignes de tableau et Nombre** **maximum de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le définir comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
+ Pour configurer les détails de la stratégie.
Outre la définition du poids pour chaque stratégie d'optimisation, vous pouvez configurer les paramètres d'optimisation. Pour ce faire, choisissez **Optimisation des conversions**.
+ Pour le **champ Limite des colonnes clés de tri**, entrez le nombre maximum de colonnes dans la clé de tri.
+ Pour une **valeur de seuil asymétrique**, entrez le pourcentage (0 à 100) d'une valeur asymétrique pour une colonne. AWS SCT exclut les colonnes dont la valeur d'inclinaison est supérieure au seuil de la liste des candidats pour la clé de distribution. AWS SCT définit la valeur asymétrique d'une colonne comme le pourcentage entre le nombre d'occurrences de la valeur la plus courante et le nombre total d'enregistrements.
+ Pour les **N principales requêtes de la table d'historique** des requêtes, entrez le nombre (1 à 100) des requêtes les plus fréquemment utilisées à analyser.
+ Pour **Sélectionner un utilisateur de statistiques**, choisissez l'utilisateur de base de données pour lequel vous souhaitez analyser les statistiques de requête.
Dans l'onglet **Stratégies d'optimisation**, vous pouvez également définir la taille des petites tables pour la stratégie **Rechercher de petites tables**. Pour Nombre **minimal de lignes de tableau et Nombre** **maximal de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le considérer comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
# Connexion à un entrepôt de données Teradata à l'aide du AWS Schema Conversion Tool
Vous pouvez les utiliser AWS SCT pour convertir des schémas, des objets de code et du code d'application de Teradata vers Amazon Redshift ou Amazon Redshift et les utiliser en combinaison. AWS Glue
## Privilèges accordés à Teradata en tant que source
Les privilèges suivants sont requis pour utiliser Teradata en tant que source :
+ SELECT ON DBC
+ SÉLECTIONNEZ SUR SYSUDTLIB
+ SÉLECTIONNER SUR SYSLIB
+ SÉLECTIONNEZ SUR **
+ CRÉER UNE PROCÉDURE SUR **
Dans l'exemple précédent, remplacez l'**espace réservé par le nom de la base de données source.
AWS SCT nécessite le privilège CREATE PROCEDURE pour exécuter HELP PROCEDURE sur toutes les procédures de la base de données source. AWS SCT n'utilise pas ce privilège pour créer de nouveaux objets dans votre base de données Teradata source.
## Connexion à Teradata en tant que source
Utilisez la procédure suivante pour vous connecter à votre base de données source Teradata avec AWS Schema Conversion Tool.
**Pour vous connecter à une base de données source Teradata**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. Choisissez **Teradata**, puis **Next**.
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement :
+ Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes :
1. Pour **AWS Secret**, choisissez le nom du secret.
1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager.
Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Pour saisir manuellement les informations de connexion à la base de données source Teradata, suivez les instructions suivantes :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.Teradata.html)
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source.
1. Choisissez **Connect pour vous** connecter à votre base de données source.
### Utilisation de l'authentification LDAP avec une source Teradata
Pour configurer l'authentification LDAP (Lightweight Directory Access Protocol) pour les utilisateurs Teradata qui exécutent Microsoft Active Directory sous Windows, utilisez la procédure suivante.
Dans la procédure suivante, le domaine Active Directory est`test.local.com`. Le serveur Windows l'est`DC`, et il est configuré avec les paramètres par défaut. Le script suivant crée le compte `test_ldap` Active Directory, qui utilise le `test_ldap` mot de passe.
**Pour configurer l'authentification LDAP pour les utilisateurs de Teradata qui exécutent Microsoft Active Directory sous Windows**
1. Dans le répertoire `/opt/teradata/tdat/tdgss/site`, modifiez le fichier `TdgssUserConfigFile.xml`. Modifiez la section LDAP comme suit.
```
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. Appliquez les modifications en exécutant la configuration comme suit.
```
#cd /opt/teradata/tdgss/bin
#./run_tdgssconfig
```
1. Testez la configuration en exécutant la commande suivante.
```
# /opt/teradata/tdat/tdgss/14.10.03.01/bin/tdsbind -u test_ldap -w test_ldap
```
La sortie doit ressembler à ce qui suit.
```
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. Redémarrez TPA à l'aide de la commande suivante.
```
#tpareset -f "use updated TDGSSCONFIG GDO"
```
1. Créez le même utilisateur dans la base de données Teradata que dans Active Directory, comme indiqué ci-dessous.
```
CREATE USER test_ldap AS PERM=1000, PASSWORD=test_ldap;
GRANT LOGON ON ALL TO test WITH NULL PASSWORD;
```
Si vous modifiez le mot de passe utilisateur dans Active Directory pour votre utilisateur LDAP, spécifiez ce nouveau mot de passe lors de la connexion à Teradata en mode LDAP. En mode DEFAULT, vous vous connectez à Teradata en utilisant le nom d'utilisateur LDAP et n'importe quel mot de passe.
## Configuration de la collecte de statistiques dans votre entrepôt de données Teradata source
Pour convertir votre entrepôt de données Teradata source, utilisez AWS SCT des statistiques pour optimiser votre entrepôt de données Amazon Redshift converti. Vous pouvez collecter des statistiques dans le fichier de statistiques AWS SCT ou le télécharger. Pour de plus amples informations, veuillez consulter [Collecte ou téléchargement de statistiques](CHAP_Converting.DW.md#CHAP_Converting.DW.Statistics).
Pour être sûr de AWS SCT pouvoir collecter des statistiques à partir de votre entrepôt de données, effectuez les tâches préalables suivantes.
**Pour collecter des statistiques à partir de votre entrepôt de données Teradata**
1. Exécutez la requête suivante pour recueillir les statistiques de toutes les tables de votre entrepôt de données.
```
collect summary statistics on table_name;
```
Dans l'exemple précédent, remplacez *table\$1name* par le nom de votre table source. Répétez la requête pour chaque table que vous convertissez.
1. Exécutez la requête suivante pour déterminer la chaîne de compte de l'utilisateur, que vous utiliserez pour convertir votre entrepôt de données.
```
select * from dbc.accountinfo where username ='user_name'
```
1. Activez la journalisation des requêtes pour un utilisateur spécifique à l'aide de la chaîne de compte de l'exemple précédent.
```
BEGIN QUERY LOGGING WITH OBJECTS, SQL ON ALL ACCOUNT=('$M$BUSI$S$D$H');
```
Vous pouvez également activer la journalisation des requêtes pour tous les utilisateurs de la base de données.
```
BEGIN QUERY LOGGING WITH SQL, OBJECTS LIMIT SQLTEXT=0 ON ALL;
```
Une fois que vous avez terminé de collecter les statistiques de l'entrepôt de données, désactivez l'enregistrement des requêtes. Pour ce faire, vous pouvez utiliser l'exemple de code suivant.
```
end query logging with explain, objects, sql on all account=(' $M$BUSI$S$D$H');
```
## Collecte de statistiques en mode hors ligne à partir de votre entrepôt de données Teradata source
Après avoir configuré la collecte de statistiques dans votre entrepôt de données Teradata, vous pouvez collecter des statistiques dans votre AWS SCT projet. Vous pouvez également utiliser des scripts BTEQ (Basic Teradata Query) pour collecter des statistiques en mode hors ligne. Vous pouvez ensuite télécharger les fichiers contenant les statistiques collectées dans votre AWS SCT projet. Pour de plus amples informations, veuillez consulter [Collecte ou téléchargement de statistiques](CHAP_Converting.DW.md#CHAP_Converting.DW.Statistics).
**Pour collecter des statistiques à partir de votre entrepôt de données Teradata en mode hors ligne**
1. Créez le `off-line_stats.bteq` script avec le contenu suivant.
```
.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. Créez le `td_run_bteq.bat` fichier qui exécute le script BTEQ que vous avez créé à l'étape précédente. Utilisez le contenu suivant pour ce fichier.
```
@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. Créez le `runme.bat` fichier qui exécute le fichier batch que vous avez créé à l'étape précédente. Utilisez le contenu suivant pour ce fichier.
```
.\td_run_bteq.bat ServerName UserName DatabaseName
```
Dans le `runme.bat` fichier, remplacez *ServerName**UserName*, et *DatabaseName* par les valeurs applicables.
Exécutez ensuite le `runme.bat` fichier. Répétez cette étape pour chaque entrepôt de données que vous convertissez en Amazon Redshift.
Après avoir exécuté ce script, vous recevez trois fichiers contenant des statistiques pour chaque base de données. Vous pouvez télécharger ces fichiers dans votre AWS SCT projet. Pour ce faire, choisissez votre entrepôt de données dans le panneau de gauche de votre projet et ouvrez le menu contextuel (clic droit). Choisissez **Upload Statistics**.
## Paramètres de conversion de Teradata vers Amazon Redshift
**Pour modifier les paramètres de conversion de Teradata vers Amazon Redshift, **choisissez** Paramètres AWS SCT dans, puis sélectionnez Paramètres de conversion.** Dans la liste supérieure, choisissez **Teradata**, puis **Teradata — Amazon Redshift**. AWS SCT affiche tous les paramètres disponibles pour la conversion de Teradata vers Amazon Redshift.
Les paramètres de conversion de Teradata vers Amazon Redshift incluent des options pour AWS SCT les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour définir le nombre maximum de tables AWS SCT pouvant s'appliquer à votre cluster Amazon Redshift cible.
Pour **le nombre maximum de tables pour le cluster Amazon Redshift cible**, choisissez le nombre de tables qui AWS SCT peuvent s'appliquer à votre cluster Amazon Redshift.
Amazon Redshift dispose de quotas qui limitent l’utilisation des tables pour différents types de nœud de cluster. Si vous choisissez **Auto**, AWS SCT détermine le nombre de tables à appliquer à votre cluster Amazon Redshift cible en fonction du type de nœud. Vous pouvez éventuellement choisir la valeur manuellement. Pour plus d’informations, consultez [Quotas et limites dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) dans le *Guide de gestion Amazon Redshift*.
AWS SCT convertit toutes vos tables sources, même si c'est plus que ce que votre cluster Amazon Redshift peut stocker. AWS SCT stocke le code converti dans votre projet et ne l'applique pas à la base de données cible. Si vous atteignez le quota de cluster Amazon Redshift pour les tables lorsque vous appliquez le code converti, un message d'avertissement s' AWS SCT affiche. AWS SCT Applique également des tables à votre cluster Amazon Redshift cible jusqu'à ce que le nombre de tables atteigne la limite.
+ Pour migrer des partitions de la table source vers des tables séparées dans Amazon Redshift. Pour ce faire, sélectionnez **Utiliser la vue UNION ALL** et entrez le nombre maximum de tables cibles AWS SCT pouvant être créées pour une seule table source.
Amazon Redshift ne prend pas en charge le partitionnement des tables. Pour imiter ce comportement et accélérer l'exécution des requêtes, AWS SCT vous pouvez migrer chaque partition de votre table source vers une table distincte dans Amazon Redshift. AWS SCT Crée ensuite une vue qui inclut les données de toutes ces tables.
AWS SCT détermine automatiquement le nombre de partitions de votre table source. Selon le type de partitionnement de votre table source, ce nombre peut dépasser le quota de tables que vous pouvez appliquer à votre cluster Amazon Redshift. Pour éviter d'atteindre ce quota, entrez le nombre maximum de tables cibles AWS SCT pouvant être créées pour les partitions d'une seule table source. L'option par défaut est 368 tables, ce qui représente une partition pendant 366 jours par an et deux tables pour `NO RANGE` et `UNKNOWN` partitions.
+ Pour appliquer une compression aux colonnes d'un tableau Amazon Redshift. Pour ce faire, sélectionnez **Utiliser le codage par compression**.
AWS SCT attribue automatiquement un codage de compression aux colonnes à l'aide de l'algorithme Amazon Redshift par défaut. Pour plus d'informations, consultez la section [Encodages de compression](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) dans le manuel *Amazon Redshift Database* Developer Guide.
Par défaut, Amazon Redshift n'applique pas de compression aux colonnes définies comme clés de tri et de distribution. Vous pouvez modifier ce comportement et appliquer une compression à ces colonnes. Pour ce faire, sélectionnez **Utiliser le codage de compression pour les colonnes KEY**. Vous ne pouvez sélectionner cette option que lorsque vous sélectionnez l'option **Utiliser le codage par compression**.
+ Pour utiliser une liste explicite de colonnes dans le code converti pour les `SELECT *` instructions, sélectionnez **Utiliser une déclaration de colonne explicite**.
+ Pour émuler le comportement des clés primaires et uniques dans votre cluster Amazon Redshift, **sélectionnez Émuler le comportement des clés primaires** et uniques.
Amazon Redshift n'applique pas les clés uniques et primaires et ne les utilise qu'à des fins d'information. Si vous utilisez ces contraintes dans votre code, assurez-vous qu'elles AWS SCT imitent leur comportement dans le code converti.
+ Pour garantir l'unicité des données dans les tables Amazon Redshift cibles. Pour ce faire, sélectionnez **Émuler le comportement des tables SET**.
Teradata crée des tables en utilisant l'élément de `SET` syntaxe comme option par défaut. Vous ne pouvez pas ajouter de lignes dupliquées dans un `SET` tableau. Si votre code source n'utilise pas cette contrainte d'unicité, désactivez cette option. Dans ce cas, le code converti fonctionne plus rapidement.
Si votre code source utilise l'`SET`option dans les tables comme contrainte d'unicité, activez cette option. Dans ce cas, AWS SCT réécrit `INSERT..SELECT` les instructions dans le code converti pour imiter le comportement de votre base de données source.
## Paramètres d'optimisation de la conversion entre Teradata et Amazon Redshift
**Pour modifier les paramètres d'optimisation de conversion de Teradata vers Amazon Redshift, **choisissez** Paramètres AWS SCT dans, puis sélectionnez Paramètres de conversion.** Dans la liste supérieure, choisissez **Teradata**, puis **Teradata — Amazon Redshift**. Dans le volet de gauche, sélectionnez **Stratégies d'optimisation**. AWS SCT affiche les paramètres d'optimisation de conversion pour la conversion de Teradata vers Amazon Redshift.
Les paramètres AWS SCT d'optimisation de la conversion de Teradata vers Amazon Redshift incluent des options pour les éléments suivants :
+ Pour travailler avec l'optimisation automatique des tables. Pour ce faire, sélectionnez **Utiliser le réglage automatique des tables Amazon Redshift**.
L'optimisation automatique des tables est un processus de réglage automatique dans Amazon Redshift qui optimise automatiquement la conception des tables. Pour plus d'informations, consultez la section [Utilisation de l'optimisation automatique des tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) dans le manuel *Amazon Redshift Database Developer Guide*.
Pour vous fier uniquement à l'optimisation automatique des tables, choisissez **Aucune** pour la **stratégie initiale de sélection des clés**.
+ Pour choisir les clés de tri et de distribution selon votre stratégie.
Vous pouvez choisir des clés de tri et de distribution à l'aide des métadonnées Amazon Redshift, des informations statistiques ou des deux options. Pour **Stratégie initiale de sélection des clés** dans l'onglet **Stratégies d'optimisation**, choisissez l'une des options suivantes :
+ Utiliser des métadonnées, ignorer les informations statistiques
+ Ignorer les métadonnées, utiliser des informations statistiques
+ Utiliser des métadonnées et des informations statistiques
Selon l'option que vous choisissez, vous pouvez sélectionner des stratégies d'optimisation. Entrez ensuite la valeur (0 à 100) pour chaque stratégie. Ces valeurs définissent le poids de chaque stratégie. À l'aide de ces valeurs de pondération, AWS SCT définit l'influence de chaque règle sur le choix des clés de distribution et de tri. Les valeurs par défaut sont basées sur les meilleures pratiques de AWS migration.
Vous pouvez définir la taille des petites tables dans le cadre de la stratégie **Find small tables**. Pour Nombre **minimum de lignes de tableau et Nombre** **maximum de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le définir comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
+ Pour configurer les détails de la stratégie.
Outre la définition du poids pour chaque stratégie d'optimisation, vous pouvez configurer les paramètres d'optimisation. Pour ce faire, choisissez **Optimisation des conversions**.
+ Pour le **champ Limite des colonnes clés de tri**, entrez le nombre maximum de colonnes dans la clé de tri.
+ Pour une **valeur de seuil asymétrique**, entrez le pourcentage (0 à 100) d'une valeur asymétrique pour une colonne. AWS SCT exclut les colonnes dont la valeur d'inclinaison est supérieure au seuil de la liste des candidats pour la clé de distribution. AWS SCT définit la valeur asymétrique d'une colonne comme le pourcentage entre le nombre d'occurrences de la valeur la plus courante et le nombre total d'enregistrements.
+ Pour les **N principales requêtes de la table d'historique** des requêtes, entrez le nombre (1 à 100) des requêtes les plus fréquemment utilisées à analyser.
+ Pour **Sélectionner un utilisateur de statistiques**, choisissez l'utilisateur de base de données pour lequel vous souhaitez analyser les statistiques de requête.
Dans l'onglet **Stratégies d'optimisation**, vous pouvez également définir la taille des petites tables pour la stratégie **Rechercher de petites tables**. Pour Nombre **minimal de lignes de tableau et Nombre** **maximal de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le considérer comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
# Connexion aux bases AWS Schema Conversion Tool de données Vertica
Vous pouvez l'utiliser AWS SCT pour convertir des schémas, des objets de code et du code d'application de Vertica vers Amazon Redshift.
## Privilèges pour Vertica en tant que source
Les privilèges suivants sont requis pour utiliser Vertica en tant que source :
+ UTILISATION SUR LE SCHÉMA **
+ USAGE ON SCHEMA PUBLIC
+ SÉLECTIONNEZ SUR TOUTES LES TABLES DU SCHÉMA **
+ SÉLECTIONNEZ TOUTES LES SÉQUENCES DU SCHÉMA **
+ EXÉCUTER SUR TOUTES LES FONCTIONS DU SCHÉMA **
+ EXÉCUTER SUR LA PROCÉDURE **
Dans l'exemple précédent, remplacez les espaces réservés comme suit :
+ Remplacez *schema\$1name* par le nom du schéma source.
+ Remplacez *procedure\$1name* par le nom d'une procédure source. Répétez l'autorisation pour chaque procédure que vous convertissez.
+ Remplacez *procedure\$1signature* par la liste des types d'arguments de procédure séparés par des virgules.
## Connexion à Vertica en tant que source
Utilisez la procédure suivante pour vous connecter à votre base de données source Vertica avec AWS Schema Conversion Tool.
**Pour vous connecter à une base de données source Vertica**
1. Dans le AWS Schema Conversion Tool, choisissez **Ajouter une source**.
1. Choisissez **Vertica**, puis **Next**.
La boîte de dialogue **Ajouter une source** apparaît.
1. Dans **Nom de connexion**, entrez le nom de votre base de données. AWS SCT affiche ce nom dans l'arborescence du panneau de gauche.
1. Utilisez les informations d'identification de la base de données AWS Secrets Manager ou saisissez-les manuellement :
+ Pour utiliser les informations d'identification de base de données issues de Secrets Manager, suivez les instructions suivantes :
1. Pour **AWS Secret**, choisissez le nom du secret.
1. Choisissez **Populer pour renseigner** automatiquement toutes les valeurs dans la boîte de dialogue de connexion à la base de données depuis Secrets Manager.
Pour plus d'informations sur l'utilisation des informations d'identification de base de données depuis Secrets Manager, consultez[Configuration AWS Secrets Manager dans AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Pour saisir manuellement les informations de connexion à la base de données source Vertica, suivez les instructions suivantes :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/SchemaConversionTool/latest/userguide/CHAP_Source.Vertica.html)
1. Choisissez **Tester la connexion** pour vérifier que AWS SCT vous pouvez vous connecter à votre base de données source.
1. Choisissez **Connect pour vous** connecter à votre base de données source.
## Paramètres de conversion de Vertica vers Amazon Redshift
**Pour modifier les paramètres de conversion de Vertica vers Amazon Redshift, **choisissez** Paramètres AWS SCT dans, puis sélectionnez Paramètres de conversion.** Dans la liste supérieure, choisissez **Vertica**, puis **Vertica — Amazon Redshift**. AWS SCT affiche tous les paramètres disponibles pour la conversion de Vertica vers Amazon Redshift.
Les paramètres de conversion de Vertica vers Amazon Redshift incluent des options pour AWS SCT les éléments suivants :
+ Pour limiter le nombre de commentaires contenant des actions dans le code converti.
Pour **Ajouter des commentaires dans le code converti pour les actions de gravité sélectionnée ou supérieure**, choisissez la sévérité des actions. AWS SCT ajoute des commentaires dans le code converti pour les actions dont la sévérité est sélectionnée ou supérieure.
Par exemple, pour réduire au maximum le nombre de commentaires dans votre code converti, choisissez **Erreurs uniquement**. Pour inclure les commentaires pour tous les éléments d’action de votre code converti, choisissez **Tous les messages**.
+ Pour définir le nombre maximum de tables AWS SCT pouvant s'appliquer à votre cluster Amazon Redshift cible.
Pour **le nombre maximum de tables pour le cluster Amazon Redshift cible**, choisissez le nombre de tables qui AWS SCT peuvent s'appliquer à votre cluster Amazon Redshift.
Amazon Redshift dispose de quotas qui limitent l’utilisation des tables pour différents types de nœud de cluster. Si vous choisissez **Auto**, AWS SCT détermine le nombre de tables à appliquer à votre cluster Amazon Redshift cible en fonction du type de nœud. Vous pouvez éventuellement choisir la valeur manuellement. Pour plus d’informations, consultez [Quotas et limites dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) dans le *Guide de gestion Amazon Redshift*.
AWS SCT convertit toutes vos tables sources, même si c'est plus que ce que votre cluster Amazon Redshift peut stocker. AWS SCT stocke le code converti dans votre projet et ne l'applique pas à la base de données cible. Si vous atteignez le quota de cluster Amazon Redshift pour les tables lorsque vous appliquez le code converti, un message d'avertissement s' AWS SCT affiche. AWS SCT Applique également des tables à votre cluster Amazon Redshift cible jusqu'à ce que le nombre de tables atteigne la limite.
+ Pour migrer des partitions de la table source vers des tables séparées dans Amazon Redshift. Pour ce faire, sélectionnez **Utiliser la vue UNION ALL** et entrez le nombre maximum de tables cibles AWS SCT pouvant être créées pour une seule table source.
Amazon Redshift ne prend pas en charge le partitionnement des tables. Pour imiter ce comportement et accélérer l'exécution des requêtes, AWS SCT vous pouvez migrer chaque partition de votre table source vers une table distincte dans Amazon Redshift. AWS SCT Crée ensuite une vue qui inclut les données de toutes ces tables.
AWS SCT détermine automatiquement le nombre de partitions de votre table source. Selon le type de partitionnement de votre table source, ce nombre peut dépasser le quota de tables que vous pouvez appliquer à votre cluster Amazon Redshift. Pour éviter d'atteindre ce quota, entrez le nombre maximum de tables cibles AWS SCT pouvant être créées pour les partitions d'une seule table source. L'option par défaut est 368 tables, ce qui représente une partition pendant 366 jours par an et deux tables pour `NO RANGE` et `UNKNOWN` partitions.
+ Pour appliquer une compression aux colonnes d'un tableau Amazon Redshift. Pour ce faire, sélectionnez **Utiliser le codage par compression**.
AWS SCT attribue automatiquement un codage de compression aux colonnes à l'aide de l'algorithme Amazon Redshift par défaut. Pour plus d'informations, consultez la section [Encodages de compression](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) dans le manuel *Amazon Redshift Database* Developer Guide.
Par défaut, Amazon Redshift n'applique pas de compression aux colonnes définies comme clés de tri et de distribution. Vous pouvez modifier ce comportement et appliquer une compression à ces colonnes. Pour ce faire, sélectionnez **Utiliser le codage de compression pour les colonnes KEY**. Vous ne pouvez sélectionner cette option que lorsque vous sélectionnez l'option **Utiliser le codage par compression**.
## Paramètres d'optimisation de la conversion entre Vertica et Amazon Redshift
**Pour modifier les paramètres d'optimisation de conversion de Vertica vers Amazon Redshift, **choisissez** Paramètres AWS SCT dans, puis sélectionnez Paramètres de conversion.** Dans la liste supérieure, choisissez **Vertica**, puis **Vertica — Amazon Redshift**. Dans le volet de gauche, sélectionnez **Stratégies d'optimisation**. AWS SCT affiche les paramètres d'optimisation des conversions pour la conversion de Vertica vers Amazon Redshift.
Les paramètres AWS SCT d'optimisation de la conversion de Vertica vers Amazon Redshift incluent des options pour les éléments suivants :
+ Pour travailler avec l'optimisation automatique des tables. Pour ce faire, sélectionnez **Utiliser le réglage automatique des tables Amazon Redshift**.
L'optimisation automatique des tables est un processus de réglage automatique dans Amazon Redshift qui optimise automatiquement la conception des tables. Pour plus d'informations, consultez la section [Utilisation de l'optimisation automatique des tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) dans le manuel *Amazon Redshift Database Developer Guide*.
Pour vous fier uniquement à l'optimisation automatique des tables, choisissez **Aucune** pour la **stratégie initiale de sélection des clés**.
+ Pour choisir les clés de tri et de distribution selon votre stratégie.
Vous pouvez choisir des clés de tri et de distribution à l'aide des métadonnées Amazon Redshift, des informations statistiques ou des deux options. Pour **Stratégie initiale de sélection des clés** dans l'onglet **Stratégies d'optimisation**, choisissez l'une des options suivantes :
+ Utiliser des métadonnées, ignorer les informations statistiques
+ Ignorer les métadonnées, utiliser des informations statistiques
+ Utiliser des métadonnées et des informations statistiques
Selon l'option que vous choisissez, vous pouvez sélectionner des stratégies d'optimisation. Entrez ensuite la valeur (0 à 100) pour chaque stratégie. Ces valeurs définissent le poids de chaque stratégie. À l'aide de ces valeurs de pondération, AWS SCT définit l'influence de chaque règle sur le choix des clés de distribution et de tri. Les valeurs par défaut sont basées sur les meilleures pratiques de AWS migration.
Vous pouvez définir la taille des petites tables dans le cadre de la stratégie **Find small tables**. Pour Nombre **minimum de lignes de tableau et Nombre** **maximum de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le définir comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.
+ Pour configurer les détails de la stratégie.
Outre la définition du poids pour chaque stratégie d'optimisation, vous pouvez configurer les paramètres d'optimisation. Pour ce faire, choisissez **Optimisation des conversions**.
+ Pour le **champ Limite des colonnes clés de tri**, entrez le nombre maximum de colonnes dans la clé de tri.
+ Pour une **valeur de seuil asymétrique**, entrez le pourcentage (0 à 100) d'une valeur asymétrique pour une colonne. AWS SCT exclut les colonnes dont la valeur d'inclinaison est supérieure au seuil de la liste des candidats pour la clé de distribution. AWS SCT définit la valeur asymétrique d'une colonne comme le pourcentage entre le nombre d'occurrences de la valeur la plus courante et le nombre total d'enregistrements.
+ Pour les **N principales requêtes de la table d'historique** des requêtes, entrez le nombre (1 à 100) des requêtes les plus fréquemment utilisées à analyser.
+ Pour **Sélectionner un utilisateur de statistiques**, choisissez l'utilisateur de base de données pour lequel vous souhaitez analyser les statistiques de requête.
Dans l'onglet **Stratégies d'optimisation**, vous pouvez également définir la taille des petites tables pour la stratégie **Rechercher de petites tables**. Pour Nombre **minimal de lignes de tableau et Nombre** **maximal de lignes** de tableau, entrez le nombre minimum et maximum de lignes dans un tableau pour le considérer comme un petit tableau. AWS SCT applique le style `ALL` de distribution aux petites tables. Dans ce cas, une copie de la table complète est distribuée à chaque nœud.