`.
Você pode encontrar exemplos na tabela a seguir.
| Instrução do Oracle | Instrução do 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;
|
# Migração do banco de dados Oracle para o Amazon RDS for Oracle com AWS Schema Conversion Tool
Há alguns aspectos a serem considerados ao migrar o esquema e o código do Oracle para o Amazon RDS para Oracle:
+ AWS SCT pode adicionar objetos de diretório à árvore de objetos. Os *objetos do diretório* são estruturas lógicas que representam um diretório físico no sistema de arquivos do servidor. Você pode usar objetos de diretório com pacotes, como DBMS\$1LOB, UTL\$1FILE, DBMS\$1FILE\$1TRANSFER, o utilitário DATAPUMP, etc.
+ AWS SCT suporta a conversão de espaços de tabela Oracle em uma instância de banco de dados Amazon RDS for Oracle. O Oracle armazena dados logicamente em tablespaces e fisicamente em arquivos de dados associados ao tablespace correspondente. No Oracle é possível criar tablespace com nomes de arquivo de dados. O Amazon RDS oferece suporte ao Oracle Managed Files (OMF) somente para arquivos de dados, arquivos de log e arquivos de controle. AWS SCT cria os arquivos de dados necessários durante a conversão.
+ AWS SCT pode converter funções e privilégios em nível de servidor. O mecanismo de banco de dados Oracle usa a segurança baseada em funções. Uma função é uma coleção de privilégios que podem ser concedidos ou revogados de um usuário. Uma função predefinida no Amazon RDS, chamada de administrador de banco de dados, normalmente permite todos os privilégios administrativos em um mecanismo de banco de dados Oracle. Os seguintes privilégios não estão disponíveis para a função DBA em uma instância de banco de dados do Amazon RDS usando o mecanismo Oracle:
+ Alter database
+ Alterar o sistema
+ Criar qualquer diretório
+ Conceder qualquer privilégio
+ Conceder qualquer função
+ Criar trabalho externo
Você pode conceder todos os outros privilégios a uma função de usuário do Amazon RDS para Oracle, incluindo filtragem avançada e privilégios de coluna.
+ AWS SCT suporta a conversão de trabalhos Oracle em trabalhos que podem ser executados no Amazon RDS for Oracle. Há algumas limitações à conversão, incluindo as seguintes:
+ Trabalhos executáveis não são suportados.
+ Trabalhos de programação que usam o tipo de dados ANYDATA como argumento não são suportados.
+ O Oracle Real Application Clusters (RAC) One Node é uma opção ao Oracle Database Enterprise Edition que foi introduzida com o Oracle Database 11g Release 2. O Amazon RDS para Oracle não é compatível com o atributo RAC. Para obter alta disponibilidade, use o Multi-AZ do Amazon RDS.
Em uma implantação Multi-AZ, o Amazon RDS automaticamente provisiona e mantém uma réplica em espera síncrona em outra Zona de disponibilidade. A instância de banco de dados primária é sincronicamente replicada ao longo das zonas de disponibilidade para uma réplica em espera. Essa funcionalidade fornece redundância de dados, elimina I/O congelamentos e minimiza os picos de latência durante os backups do sistema.
+ O Oracle Spatial fornece um esquema SQL e funções que facilitam o armazenamento, a recuperação, a atualização e a consulta de coleções de dados espaciais em um banco de dados Oracle. O Oracle Locator oferece recursos normalmente obrigatórios para dar suporte à Internet e a aplicativos baseados em serviço sem fio além de soluções GIS baseadas no parceiro. O Oracle Locator é um subconjunto limitado do Oracle Spatial.
Para usar os recursos do Oracle Spatial e do Oracle Locator, adicione a opção SPATIAL ou LOCATOR (mutuamente exclusivas) ao grupo de opções da instância de banco de dados.
Há alguns pré-requisitos para usar o Oracle Spatial e o Oracle Locator em uma instância de banco de dados do Amazon RDS para Oracle:
+ A instância deve usar o Oracle Enterprise Edition versão 12.1.0.2.v6 ou posterior ou 11.2.0.4.v10 ou posterior.
+ A instância deve estar em uma nuvem privada virtual (VPC).
+ A instância deve ser a classe de instância de banco de dados que pode oferecer suporte ao recurso da Oracle. Por exemplo, o Oracle Spatial não é compatível com as classes de instância de banco de dados db.m1.small, db.t1.micro, db.t2.micro ou db.t2.small. Para obter mais informações, consulte [Suporte a classes de instância de banco de dados para Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html#Oracle.Concepts.InstanceClasses).
+ A instância deve ter a opção Atualização de versão do Auto Minor habilitada. O Amazon RDS atualizará a instância de banco de dados para o Oracle PSU mais recente se houver vulnerabilidades de segurança com uma pontuação CVSS de 9 ou mais ou outras vulnerabilidades de segurança anunciadas. Para obter mais informações, consulte .
[Configurações para instâncias de banco de dados do Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ModifyInstance.Oracle.html#USER_ModifyInstance.Oracle.Settings).
+ Se a instância de banco de dados for a versão 11.2.0.4 .v10 ou posterior, você deverá instalar a opção XMLDB. Para obter mais informações, consulte .
[Oracle XML DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.XMLDB.html).
+ Você deve ter uma licença do Oracle Spatial da Oracle. Para obter mais informações, consulte [Oracle Spatial and Graph](https://shop.oracle.com/apex/product?p1=OracleSpatialandGraph) na documentação da Oracle.
+ O Data Guard é incluído com o Oracle Database Enterprise Edition. Para obter alta disponibilidade, use o atributo Multi-AZ do Amazon RDS.
Em uma implantação Multi-AZ, o Amazon RDS automaticamente provisiona e mantém uma réplica em espera síncrona em outra Zona de disponibilidade. A instância de banco de dados primária é sincronicamente replicada ao longo das zonas de disponibilidade para uma réplica em espera. Essa funcionalidade fornece redundância de dados, elimina I/O congelamentos e minimiza os picos de latência durante os backups do sistema.
+ AWS SCT suporta a conversão de objetos Oracle DBMS\$1SCHEDULER ao migrar para o Amazon RDS for Oracle. O relatório AWS SCT de avaliação indica se um objeto de cronograma pode ser convertido. Para obter mais informações sobre como usar objetos de programação com o Amazon RDS, consulte a [Documentação do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.System.html#Appendix.Oracle.CommonDBATasks.ModifyScheduler).
+ Para conversões o Oracle para Amazon RDS para Oracle, os links de banco de dados são compatíveis. Um link de banco de dados é um objeto de esquema em um banco de dados que permite acessar objetos em outro banco de dados. O outro banco de dados não precisa ser um banco de dados Oracle. No entanto, para acessar bancos de dados que não sejam Oracle, é necessário usar o Oracle Heterogeneous Services.
Depois de criar um link de banco de dados, você pode usar o link nas instruções SQL para se referir a tabelas, exibições e PL/SQL objetos no outro banco de dados. Para usar um link de banco de dados, anexe `@dblink` à tabela, exibição ou nome do PL/SQL objeto. Você pode consultar uma tabela ou visualização em outro banco de dados com a instrução SELECT. Para obter mais informações sobre como usar links do banco de dados Oracle, consulte a [Documentação do Oracle](https://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts002.htm#ADMIN12083).
Para obter mais informações sobre como usar links do banco de dados com o Amazon RDS, consulte a [Documentação do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.Database.html#Appendix.Oracle.CommonDBATasks.DBLinks).
+ O relatório de AWS SCT avaliação fornece métricas do servidor para a conversão. Essas métricas sobre sua instância da Oracle incluem:
+ Capacidade de computação e memória da instância de banco de dados de destino.
+ Recursos da Oracle sem suporte, como o Real Application Clusters, aos quais o Amazon RDS não oferece suporte.
+ Carga de leitura/gravação de disco
+ Taxa de throughput total
+ Informações do servidor, como nome do servidor, sistema operacional, nome do host e conjunto de caracteres.
## Privilégios para RDS para Oracle como destino
Para migrar para o Amazon RDS para Oracle, crie um usuário de banco de dados privilegiado. Você pode usar o exemplo de código a seguir.
```
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;
```
No exemplo anterior, *user\$1name* substitua pelo nome do seu usuário. Em seguida, *your\$1password* substitua por uma senha segura.
## Limitações ao converter Oracle para Amazon RDS para Oracle
Você deve considerar algumas limitações ao migrar o esquema e o código da Oracle para o Amazon RDS para Oracle:
+ Uma função predefinida no Amazon RDS, chamada de administrador de banco de dados, normalmente permite todos os privilégios administrativos em um mecanismo de banco de dados Oracle. Os seguintes privilégios não estão disponíveis para a função DBA em uma instância de banco de dados do Amazon RDS usando o mecanismo Oracle:
+ Alter database
+ Alterar o sistema
+ Criar qualquer diretório
+ Conceder qualquer privilégio
+ Conceder qualquer função
+ Criar trabalho externo
Você pode conceder todos os outros privilégios a uma função de usuário do Oracle RDS.
+ O Amazon RDS para Oracle oferece suporte a auditoria tradicional, auditoria de acesso refinado usando o pacote DBMS\$1FGA e Oracle Unified Auditing.
+ O Amazon RDS para Oracle não oferece suporte à captura de dados de alterações (CDC). Para fazer o CDC durante e após a migração do banco de dados, use AWS Database Migration Service.
# Conectando-se aos bancos de dados PostgreSQL com o AWS Schema Conversion Tool
Você pode usar AWS SCT para converter esquemas, objetos de código de banco de dados e código de aplicativo do PostgreSQL para os seguintes destinos:
+ Amazon RDS para MySQL
+ Amazon Aurora Edição Compatível com MySQL
+ Amazon RDS para PostgreSQL
+ Amazon Aurora Edição Compatível com PostgreSQL
Para obter mais informações, consulte as seções a seguir:
**Topics**
+ [
## Privilégios para PostgreSQL como um banco de dados de origem
](#CHAP_Source.PostgreSQL.Permissions)
+ [
## Conectar-se ao PostgreSQL como origem
](#CHAP_Source.PostgreSQL.Connecting)
+ [
## Privilégios do MySQL como um banco de dados de destino
](#CHAP_Source.PostgreSQL.ConfigureMySQL)
## Privilégios para PostgreSQL como um banco de dados de origem
Os privilégios obrigatórios para PostgreSQL como origem são listados a seguir:
+ CONECTE-SE AO BANCO DE DADOS **
+ USO NO ESQUEMA **
+ SELECIONE EM TODAS AS TABELAS NO ESQUEMA **
+ SELECIONE EM TODAS AS SEQUÊNCIAS NO ESQUEMA **
## Conectar-se ao PostgreSQL como origem
Use o procedimento a seguir para conectar seu banco de dados de origem do PostgreSQL com a AWS Schema Conversion Tool.
**Para conectar-se a um banco de dados de origem do PostgreSQL**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **PostgreSQL** e, em seguida, escolha **Avançar.**
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para o banco de dados. A AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Use as credenciais do banco de dados AWS Secrets Manager ou insira-as manualmente:
+ Para usar as credenciais do banco de dados do Secrets Manager, use as instruções a seguir:
1. Em **AWS Secret**, escolha o nome do segredo.
1. Escolha **Preencher** para preencher automaticamente todos os valores na caixa de diálogo de conexão do banco de dados do Secrets Manager.
Para obter informações sobre o uso de credenciais de banco de dados do Secrets Manager, consulte a [Configurando AWS Secrets Manager no AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Para inserir manualmente as informações de conexão do banco de dados do PostgreSQL, use as instruções a seguir:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.PostgreSQL.html)
1. Escolha **Testar conexão** para verificar se AWS SCT pode se conectar ao seu banco de dados de origem.
1. Escolha **Conectar** para se conectar ao banco de dados de origem.
## Privilégios do MySQL como um banco de dados de destino
Os privilégios obrigatórios para MySQL como destino quando migrados do PostgreSQL são os seguintes:
+ CREATE ON \$1.\$1
+ ALTER ON \$1.\$1
+ DROP ON \$1.\$1
+ INDEX ON \$1.\$1
+ REFERENCES ON \$1.\$1
+ SELECT ON \$1.\$1
+ CREATE VIEW ON \$1.\$1
+ SHOW VIEW ON \$1.\$1
+ TRIGGER ON \$1.\$1
+ CREATE ROUTINE ON \$1.\$1
+ ALTER ROUTINE ON \$1.\$1
+ EXECUTE ON \$1.\$1
+ INSIRA, ATUALIZE EM AWS\$1POSTGRESQL \$1EXT. \$1
+ INSIRA, ATUALIZE E EXCLUA EM AWS\$1POSTGRESQL \$1EXT\$1DATA. \$1
+ CRIE TABELAS TEMPORÁRIAS EM AWS\$1POSTGRESQL \$1EXT\$1DATA. \$1
É possível utilizar o exemplo de código a seguir para criar um usuário do banco de dados e conceder os privilégios.
```
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';
```
No exemplo anterior, *user\$1name* substitua pelo nome do seu usuário. Em seguida, *your\$1password* substitua por uma senha segura.
Para usar o Amazon RDS para MySQL ou o Aurora MySQL como destino, defina o parâmetro `lower_case_table_names` como `1`. Esse valor significa que o servidor MySQL manipula identificadores de nomes de objetos como tabelas, índices, acionadores e bancos de dados sem distinção entre maiúsculas e minúsculas. Se você ativou o registro binário em sua instância de destino, defina o parâmetro `log_bin_trust_function_creators` como `1`. Nesse caso, você não precisa usar as características `DETERMINISTIC`, `READS SQL DATA` ou `NO SQL` para criar funções armazenadas. Para configurar esses parâmetros, crie um novo grupo de parâmetros de banco de dados ou modifique um grupo de parâmetros de banco de dados existente.
# Conectando-se aos bancos de dados SAP com o AWS Schema Conversion Tool
Você pode usar AWS SCT para converter esquemas, objetos de código de banco de dados e código de aplicativo do SAP (Sybase) Adaptive Server Enterprise (ASE) para os seguintes destinos:
+ Amazon RDS para MySQL
+ Amazon Aurora Edição Compatível com MySQL
+ Amazon RDS para MariaDB
+ Amazon RDS para PostgreSQL
+ Amazon Aurora Edição Compatível com PostgreSQL
Para obter mais informações, consulte as seções a seguir:
**Topics**
+ [
## Privilégios do SAP ASE como um banco de dados de origem
](#CHAP_Source.SAP.Permissions)
+ [
## Conectando-se ao SAP ASE (Sybase) como origem
](#CHAP_Source.SAP.Connecting)
+ [
## Privilégios do MySQL como um banco de dados de destino
](#CHAP_Source.SAP.ConfigureMySQL)
+ [
## Configurações de conversão do SAP ASE para MySQL
](#CHAP_Source.SAP.MySQLConversionSettings)
+ [
## Privilégios do PostgreSQL como um banco de dados de destino
](#CHAP_Source.SAP.ConfigurePostgreSQL)
+ [
## Configurações de conversão de SAP ASE para PostgreSQL.
](#CHAP_Source.SAP.PostgreSQLConversionSettings)
## Privilégios do SAP ASE como um banco de dados de origem
Para usar um banco de dados do SAP ASE como origem, você cria um usuário de banco de dados e concede permissões. Para fazer isso, siga as etapas a seguir.
**Criar e configurar um usuário de banco de dados**
1. Conectar-se ao banco de dados de origem.
1. Criar um usuário de banco de dados com os seguintes comandos. Forneça uma senha para o novo usuário.
```
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. Para cada banco de dados que você vai migrar, conceda os seguintes privilégios.
```
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
```
## Conectando-se ao SAP ASE (Sybase) como origem
Use o procedimento a seguir para conectar seu banco de dados do SAP ASE de origem com a AWS Schema Conversion Tool.
**Para se conectar a um banco de dados do SAP ASE de origem**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **SAP ASE** e, em seguida, escolha **Avançar**.
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para o banco de dados. A AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Use as credenciais do banco de dados AWS Secrets Manager ou insira-as manualmente:
+ Para usar as credenciais do banco de dados do Secrets Manager, use as instruções a seguir:
1. Em **AWS Secret**, escolha o nome do segredo.
1. Escolha **Preencher** para preencher automaticamente todos os valores na caixa de diálogo de conexão do banco de dados do Secrets Manager.
Para obter informações sobre o uso de credenciais de banco de dados do Secrets Manager, consulte a [Configurando AWS Secrets Manager no AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Para inserir manualmente as informações de conexão do banco de dados do SAP ASE de origem, use as instruções a seguir:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.SAP.html)
1. Escolha **Testar conexão** para verificar se AWS SCT pode se conectar ao seu banco de dados de origem.
1. Escolha **Conectar** para se conectar ao banco de dados de origem.
## Privilégios do MySQL como um banco de dados de destino
Os privilégios obrigatórios para MySQL como destino são listados a seguir:
+ CREATE ON \$1.\$1
+ ALTER ON \$1.\$1
+ DROP ON \$1.\$1
+ INDEX ON \$1.\$1
+ REFERENCES ON \$1.\$1
+ SELECT ON \$1.\$1
+ CREATE VIEW ON \$1.\$1
+ SHOW VIEW ON \$1.\$1
+ TRIGGER ON \$1.\$1
+ CREATE ROUTINE ON \$1.\$1
+ ALTER ROUTINE ON \$1.\$1
+ EXECUTE ON \$1.\$1
+ INSIRA, ATUALIZE EM AWS\$1SAPASE \$1EXT. \$1
+ CRIE TABELAS TEMPORÁRIAS EM AWS\$1SAPASE \$1EXT. \$1
É possível utilizar o exemplo de código a seguir para criar um usuário do banco de dados e conceder os privilégios.
```
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';
```
No exemplo anterior, *user\$1name* substitua pelo nome do seu usuário. Em seguida, *your\$1password* substitua por uma senha segura.
Para usar o Amazon RDS para MySQL ou o Aurora MySQL como destino, defina o parâmetro `lower_case_table_names` como `1`. Esse valor significa que o servidor MySQL manipula identificadores de nomes de objetos como tabelas, índices, acionadores e bancos de dados sem distinção entre maiúsculas e minúsculas. Se você ativou o registro binário em sua instância de destino, defina o parâmetro `log_bin_trust_function_creators` como `1`. Nesse caso, você não precisa usar as características `DETERMINISTIC`, `READS SQL DATA` ou `NO SQL` para criar funções armazenadas. Para configurar esses parâmetros, crie um novo grupo de parâmetros de banco de dados ou modifique um grupo de parâmetros de banco de dados existente.
## Configurações de conversão do SAP ASE para MySQL
Para editar as configurações de conversão do SAP ASE para MySQL, escolha **Configurações** e, em seguida, escolha **Configurações de conversão**. Na lista superior, escolha **SAP ASE** e, depois, selecione **SAP ASE: MySQL** ou **SAP ASE: Amazon Aurora (compatível com MySQL)**. O AWS SCT exibe todas as configurações disponíveis para conversão de SAP ASE em PostgreSQL.
As configurações de conversão do SAP ASE para MySQL AWS SCT incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para usar os nomes exatos dos objetos do banco de dados de origem no código convertido.
Por padrão, AWS SCT converte os nomes dos objetos, variáveis e parâmetros do banco de dados em minúsculas. Para manter as maiúsculas e minúsculas originais desses nomes, selecione **Tratar nomes de objetos do banco de dados de origem com distinção entre maiúsculas e minúsculas**. Escolha essa opção se você usar nomes de objetos com distinção entre maiúsculas e minúsculas no servidor de banco de dados do SAP ASE de origem.
## Privilégios do PostgreSQL como um banco de dados de destino
Para usar o PostgreSQL como destino AWS SCT , é necessário o privilégio. `CREATE ON DATABASE` Certifique-se de conceder esse privilégio para cada banco de dados PostgreSQL de destino.
Para usar os sinônimos públicos convertidos, altere o caminho de pesquisa padrão do banco de dados para `"$user", public_synonyms, public`.
É possível utilizar o exemplo de código a seguir para criar um usuário do banco de dados e conceder os privilégios.
```
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;
```
No exemplo anterior, *user\$1name* substitua pelo nome do seu usuário. Em seguida, *db\$1name* substitua pelo nome do seu banco de dados de destino. Por fim, *your\$1password* substitua por uma senha segura.
No PostgreSQL, apenas o proprietário do esquema ou um `superuser` pode descartar um esquema. O proprietário pode descartar um esquema e todos os objetos incluídos nesse esquema, mesmo que o proprietário do esquema não possua alguns de seus objetos.
Ao usar usuários diferentes para converter e aplicar esquemas diferentes ao banco de dados de destino, você pode receber uma mensagem de erro quando não AWS SCT consegue descartar um esquema. Para evitar essa mensagem de erro, use o perfil `superuser`.
## Configurações de conversão de SAP ASE para PostgreSQL.
Para editar as configurações de conversão do SAP ASE para PostgreSQL, escolha **Configurações** e, em seguida, escolha **Configurações de conversão**. Na lista superior, escolha **SAP ASE** e, depois, selecione **SAP ASE: PostgreSQL** ou **SAP ASE: Amazon Aurora (compatível com PostgreSQL)**. O AWS SCT exibe todas as configurações disponíveis para conversão de SAP ASE em PostgreSQL.
As configurações AWS SCT de conversão do SAP ASE para PostgreSQL incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para definir o modelo a ser usado para os nomes dos esquemas no código convertido. Para **Modelo de geração de nome de esquema**, escolha uma das opções a seguir:
+ ****: Usa o nome do banco de dados SAP ASE como nome de esquema no PostgreSQL.
+ ****: Usa o nome do esquema SAP ASE como nome do esquema no PostgreSQL.
+ **\$1**: Usa uma combinação do banco de dados SAP ASE e dos nomes do esquema como um nome de esquema no PostgreSQL.
+ Para usar os nomes exatos dos objetos do banco de dados de origem no código convertido.
Por padrão, AWS SCT converte os nomes dos objetos, variáveis e parâmetros do banco de dados em minúsculas. Para manter as maiúsculas e minúsculas originais desses nomes, selecione **Tratar nomes de objetos do banco de dados de origem com distinção entre maiúsculas e minúsculas**. Escolha essa opção se você usar nomes de objetos com distinção entre maiúsculas e minúsculas no servidor de banco de dados do SAP ASE de origem.
Para operações com distinção entre maiúsculas e minúsculas, AWS SCT pode evitar a conversão de nomes de objetos do banco de dados em minúsculas. Para fazer isso, selecione **Evitar conversão para minúsculas para operações com distinção entre maiúsculas e minúsculas**.
+ Permitir o uso de índices com o mesmo nome em tabelas diferentes no SAP ASE.
No PostgreSQL, todos os nomes de índice que você usa no esquema devem ser exclusivos. Para garantir que isso AWS SCT gere nomes exclusivos para todos os seus índices, selecione **Gerar nomes exclusivos para índices**.
# Conecte Microsoft SQL Servers com AWS Schema Conversion Tool
Você pode usar AWS SCT para converter esquemas, objetos de código de banco de dados e código de aplicativo do SQL Server para os seguintes destinos:
+ Amazon RDS para MySQL
+ Amazon Aurora Edição Compatível com MySQL
+ Amazon RDS para PostgreSQL
+ Amazon Aurora Edição Compatível com PostgreSQL
+ Amazon RDS para SQL Server
+ Amazon RDS para MariaDB
**nota**
AWS SCT não oferece suporte ao uso do Amazon RDS para SQL server como fonte.
Você pode usar AWS SCT para criar um relatório de avaliação para a migração de esquemas, objetos de código de banco de dados e código de aplicativo do SQL Server para o Babelfish para o Aurora PostgreSQL, conforme descrito a seguir.
**Topics**
+ [
## Privilégios do Microsoft SQL Server como origem
](#CHAP_Source.SQLServer.Permissions)
+ [
## Usando a autenticação do Windows ao usar o Microsoft SQL Server como origem
](#CHAP_Source.SQLServer.Permissions.WinAuth)
+ [
## Conectando-se ao SQL Server como origem
](#CHAP_Source.SQLServer.Connecting)
+ [
# Convertendo o SQL Server em MySQL
](CHAP_Source.SQLServer.ToMySQL.md)
+ [
# Migrando do SQL Server para o PostgreSQL com AWS Schema Conversion Tool
](CHAP_Source.SQLServer.ToPostgreSQL.md)
+ [
# Migração do SQL Server para o Amazon RDS for SQL Server com AWS Schema Conversion Tool
](CHAP_Source.SQLServer.ToRDSSQLServer.md)
## Privilégios do Microsoft SQL Server como origem
Os privilégios obrigatórios para Microsoft SQL Server como origem são listados a seguir:
+ VIEW DEFINITION
+ VIEW DATABASE STATE
O `VIEW DEFINITION` privilégio permite que usuários com acesso público vejam as definições de objetos. AWS SCT usa o `VIEW DATABASE STATE` privilégio para verificar os recursos da edição SQL Server Enterprise.
Repetir a concessão para cada banco de dados cujo esquema que você está convertendo.
Além disso, conceda os seguintes privilégios no banco de dados `master`:
+ VIEW SERVER STATE
+ VIEW ANY DEFINITION
AWS SCT usa o `VIEW SERVER STATE` privilégio para coletar as definições e configurações do servidor. Certifique-se de conceder o privilégio `VIEW ANY DEFINITION` de visualizar endpoints.
Para ler as informações sobre o Microsoft Analysis Services, execute o comando a seguir no banco de dados `master`.
```
EXEC master..sp_addsrvrolemember @loginame = N'', @rolename = N'sysadmin'
```
No exemplo anterior, substitua o espaço reservado `` pelo nome do usuário que você concedeu com os privilégios anteriores.
Para ler informações sobre o SQL Server Agent, adicione seu usuário ao perfil `SQLAgentUser`. Execute o comando a seguir no banco de dados `msdb`.
```
EXEC sp_addrolemember , ;
```
No exemplo anterior, substitua o espaço reservado `` pelo nome do perfil do SQL Server Agent. Em seguida, substitua o espaço reservado `` pelo nome do usuário que você concedeu com os privilégios anteriores. Para obter mais informações, consulte [Adicionar um usuário à função de SQLAgent usuário](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.SQLServer.CommonDBATasks.Agent.html#SQLServerAgent.AddUser) no *Guia do usuário do Amazon RDS*.
Para detectar o envio de logs, conceda o privilégio `SELECT on dbo.log_shipping_primary_databases` no banco de dados `msdb`.
Para usar a abordagem de notificação da replicação DDL, conceda o privilégio `RECEIVE ON .` em seus bancos de dados de origem. Neste exemplo, substitua o espaço reservado `` pelo nome do esquema do banco de dados. Substitua o espaço reservado `` pelo nome de uma tabela de filas.
## Usando a autenticação do Windows ao usar o Microsoft SQL Server como origem
Se o seu aplicativo for executado em uma intranet baseada no Windows, você poderá usar a autenticação do Windows para acesso ao banco de dados. A autenticação do Windows usa a identidade atual do Windows estabelecida no thread do sistema operacional para acessar o banco de dados do SQL Server. Em seguida, você pode mapear a identidade do Windows para um banco de dados e para as permissões do SQL Server. Para se conectar ao SQL Server usando a autenticação do Windows, você deve especificar a identidade do Windows que seu aplicativo está usando. Também é necessário conceder o acesso de identidade do Windows ao banco de dados do SQL Server.
O SQL Server possui dois modos de acesso: modo de autenticação do Windows e modo misto. O modo de autenticação do Windows habilita a autenticação do Windows e desabilita a autenticação do SQL Server. O modo misto habilita a autenticação do Windows e a autenticação do SQL Server. A autenticação do Windows está sempre disponível e não pode ser desativada. Para obter mais informações sobre a autenticação do Windows, consulte a documentação do Microsoft Windows.
Um possível exemplo de criação de usuário no TEST\$1DB é mostrado abaixo.
```
USE [TEST_DB]
CREATE USER [TestUser] FOR LOGIN [TestDomain\TestUser]
GRANT VIEW DEFINITION TO [TestUser]
GRANT VIEW DATABASE STATE TO [TestUser]
```
### Usando a autenticação do Windows com uma conexão JDBC
O driver JDBC não oferece suporte à autenticação do Windows quando o driver é usado em sistemas operacionais que não sejam Windows. Credenciais de autenticação do Windows, como nome de usuário e senha, não são automaticamente especificados ao se conectar ao SQL Server a partir de sistemas operacionais que não sejam Windows. Nesses casos, os aplicativos devem usar a autenticação do SQL Server.
Na string de conexão JDBC, o parâmetro `integratedSecurity` deve ser especificado para se conectar usando a autenticação do Windows. O driver JDBC oferece suporte à autenticação integrada do Windows em sistemas operacionais Windows por meio do parâmetro de string de conexão `integratedSecurity`.
Para usar a autenticação integrada.
1. Instalar o driver de JDBC.
1. Copie o arquivo `sqljdbc_auth.dll` para um diretório no caminho do sistema Windows no computador em que o driver JDBC está instalado.
Os arquivos `sqljdbc_auth.dll` são instalados no seguinte local:
<*diretório de instalação*>\$1sqljdbc\$1<*versão*>\$1<*linguagem*>\$1auth\$1
Ao tentar estabelecer uma conexão com o banco de dados do SQL Server usando a autenticação do Windows, você pode receber o erro: Este driver não está configurado para autenticação integrada. Esse problema pode ser resolvido executando as seguintes ações:
+ Declare duas variáveis que indicam o caminho instalado do seu JDBC:
`variable name: SQLJDBC_HOME; variable value: D:\lib\JDBC4.1\enu` (onde seu sqljdbc4.jar existe);
`variable name: SQLJDBC_AUTH_HOME; variable value: D\lib\JDBC4.1\enu\auth\x86` (se estiver executando um sistema operacional de 32 bits) ou `D\lib\JDBC4.1\enu\auth\x64` (se estiver executando um sistema operacional de 64 bits). É aqui que o seu `sqljdbc_auth.dll` está localizado.
+ Copie `sqljdbc_auth.dll` para a pasta em que o seu JDK/JRE está sendo executado. Você pode copiar na pasta lib, bin, etc. Por exemplo, você pode copiar na pasta a seguir.
```
[JDK_INSTALLED_PATH]\bin;
[JDK_INSTALLED_PATH]\jre\bin;
[JDK_INSTALLED_PATH]\jre\lib;
[JDK_INSTALLED_PATH]\lib;
```
+ Certifique-se de que, na pasta da biblioteca JDBC, você tenha somente o SQLJDBC4 arquivo.jar. Remova qualquer outro arquivo sqljdbc\$1.jar dessa pasta (ou copie em outra pasta). Se você estiver adicionando o driver como parte do seu programa, certifique-se de adicionar somente SQLJDBC4 o.jar como o driver a ser usado.
+ Copie o arquivo sqljdbc\$1auth.dll na pasta com o aplicativo.
**nota**
Se você estiver executando uma Java Virtual Machine (JVM) de 32 bits, use o arquivo sqljdbc\$1auth.dll na pasta x86, mesmo se o sistema operacional for a versão x64. Se você estiver executando uma JVM de 64 bits em um processador x64, use o arquivo sqljdbc\$1auth.dll na pasta x64.
Ao se conectar a um banco de dados do SQL Server, você pode escolher a **Autenticação do Windows** ou a **Autenticação do SQL Server** para a opção **Autenticação**.
## Conectando-se ao SQL Server como origem
Use o procedimento a seguir para se conectar ao banco de dados de origem do Microsoft SQL Server com a AWS Schema Conversion Tool.
**Para conectar-se a um banco de dados de origem do Microsoft SQL Server**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **Microsoft SQL Server** e, em seguida, escolha **Avançar**.
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para o banco de dados. A AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Use as credenciais do banco de dados AWS Secrets Manager ou insira-as manualmente:
+ Para usar as credenciais do banco de dados do Secrets Manager, use as instruções a seguir:
1. Em **AWS Secret**, escolha o nome do segredo.
1. Escolha **Preencher** para preencher automaticamente todos os valores na caixa de diálogo de conexão do banco de dados do Secrets Manager.
Para obter informações sobre o uso de credenciais de banco de dados do Secrets Manager, consulte a [Configurando AWS Secrets Manager no AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Para inserir manualmente as informações de conexão do banco de dados de origem do Microsoft SQL Server, use as instruções a seguir:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServer.html)
1. Escolha **Testar conexão** para verificar se AWS SCT pode se conectar ao seu banco de dados de origem.
1. Escolha **Conectar** para se conectar ao banco de dados de origem.
# Convertendo o SQL Server em MySQL
Para emular funções de banco de dados do Microsoft SQL Server em seu código MySQL convertido, use o pacote de extensão SQL Server para MySQL em AWS SCT. Para obter mais informações sobre pacotes de extensão, consulte [Usando pacotes de extensão com AWS Schema Conversion Tool](CHAP_ExtensionPack.md).
**Topics**
+ [
## Privilégios do MySQL como um banco de dados de destino
](#CHAP_Source.SQLServer.ToMySQL.ConfigureTarget)
+ [
## Configurações de conversão do SQL Server para MySQL
](#CHAP_Source.SQLServer.ToMySQL.ConversionSettings)
+ [
## Considerações sobre a migração
](#CHAP_Source.SQLServer.ToMySQL.MigrationConsiderations)
## Privilégios do MySQL como um banco de dados de destino
Os privilégios obrigatórios para MySQL como destino são listados a seguir:
+ CREATE ON \$1.\$1
+ ALTER ON \$1.\$1
+ DROP ON \$1.\$1
+ INDEX ON \$1.\$1
+ REFERENCES ON \$1.\$1
+ SELECT ON \$1.\$1
+ CREATE VIEW ON \$1.\$1
+ SHOW VIEW ON \$1.\$1
+ TRIGGER ON \$1.\$1
+ CREATE ROUTINE ON \$1.\$1
+ ALTER ROUTINE ON \$1.\$1
+ EXECUTE ON \$1.\$1
+ INSIRA, ATUALIZE EM AWS\$1SQLSERVER \$1EXT. \$1
+ INSIRA, ATUALIZE E EXCLUA EM AWS\$1SQLSERVER \$1EXT\$1DATA. \$1
+ CRIE TABELAS TEMPORÁRIAS EM AWS\$1SQLSERVER \$1EXT\$1DATA. \$1
É possível utilizar o exemplo de código a seguir para criar um usuário do banco de dados e conceder os privilégios.
```
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';
```
No exemplo anterior, *user\$1name* substitua pelo nome do seu usuário. Em seguida, *your\$1password* substitua por uma senha segura.
Se você usar um banco de dados MySQL versão 5.7 ou inferior como destino, execute o comando a seguir. Para bancos de dados MySQL versão 8.0 e superior, esse comando está obsoleto.
```
GRANT SELECT ON mysql.proc TO 'user_name';
```
Para usar o Amazon RDS para MySQL ou o Aurora MySQL como destino, defina o parâmetro `lower_case_table_names` como `1`. Esse valor significa que o servidor MySQL manipula identificadores de nomes de objetos como tabelas, índices, acionadores e bancos de dados sem distinção entre maiúsculas e minúsculas. Se você ativou o registro binário em sua instância de destino, defina o parâmetro `log_bin_trust_function_creators` como `1`. Nesse caso, você não precisa usar as características `DETERMINISTIC`, `READS SQL DATA` ou `NO SQL` para criar funções armazenadas. Para configurar esses parâmetros, crie um novo grupo de parâmetros de banco de dados ou modifique um grupo de parâmetros de banco de dados existente.
## Configurações de conversão do SQL Server para MySQL
Para editar as configurações de conversão do SQL Server para MySQL, AWS SCT escolha **Configurações** e, em seguida, escolha Configurações **de conversão**. Na lista superior, escolha **SQL Server** e, em seguida, escolha **SQL Server: MySQL**. A AWS SCT exibe todas as configurações disponíveis para conversão de SQL Server para MySQL.
As configurações de conversão do SQL Server para MySQL AWS SCT incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para permitir que seu banco de dados SQL Server de origem armazene a saída de `EXEC` em uma tabela. AWS SCT cria tabelas temporárias e um procedimento adicional para emular esse recurso. Para usar essa emulação, selecione **Criar rotinas adicionais para lidar com conjuntos de dados abertos**.
## Considerações sobre a migração
Há alguns aspectos a serem considerados ao migrar um esquema do SQL Server para o MySQL:
+ O MySQL não é compatível com a instrução `MERGE`. No entanto, AWS SCT pode emular a `MERGE` declaração durante a conversão usando a `INSERT ON DUPLICATE KEY` cláusula e as `UPDATE FROM and DELETE FROM` declarações.
Para emulação correta usando `INSERT ON DUPLICATE KEY`, é necessário que haja uma restrição ou chave primária no banco de dados MySQL de destino.
+ Uma instrução `GOTO` e um rótulo podem ser usados para alterar a ordem em que as instruções são executadas. Todas as instruções Transact-SQL que seguem a instrução `GOTO` são ignoradas, e o processamento continua no rótulo. As instruções `GOTO` e os rótulos podem ser usados em qualquer lugar em um procedimento, lote ou bloco de instruções. Você também pode aninhar instruções `GOTO`.
O MySQL não usa instruções `GOTO`. Quando AWS SCT converte o código que contém uma `GOTO` instrução, ele converte a instrução para usar uma instrução `BEGIN…END` ou`LOOP…END LOOP`. Você pode encontrar exemplos de como AWS SCT converte `GOTO` declarações na tabela a seguir.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServer.ToMySQL.html)
+ O MySQL não oferece suporte a funções com valor de tabela de várias instruções. AWS SCT simula funções com valor de tabela durante uma conversão criando tabelas temporárias e reescrevendo instruções para usar essas tabelas temporárias.
# Migrando do SQL Server para o PostgreSQL com AWS Schema Conversion Tool
Você pode usar o pacote de extensão SQL Server para PostgreSQL em AWS SCT. Esse pacote de extensão emula as funções do banco de dados do SQL Server no código PostgreSQL convertido. Use o pacote de extensão SQL Server para PostgreSQL para emular o SQL Server Agent e o SQL Server Database Mail. Para obter mais informações sobre pacotes de extensão, consulte [Usando pacotes de extensão com AWS Schema Conversion Tool](CHAP_ExtensionPack.md).
**Topics**
+ [
## Privilégios do PostgreSQL como um banco de dados de destino
](#CHAP_Source.SQLServer.ToPostgreSQL.ConfigurePostgreSQL)
+ [
## Configurações de conversão do SQL Server para o PostgreSQL
](#CHAP_Source.SQLServer.ToPostgreSQL.ConversionSettings)
+ [
## Converter as partições do SQL Server para as partições do PostgreSQL versão 10
](#CHAP_Source.SQLServer.ToPostgreSQL.PG10Partitions)
+ [
## Considerações sobre a migração
](#CHAP_Source.SQLServer.ToPostgreSQL.MigrationConsiderations)
+ [
# Usando um pacote AWS SCT de extensão para emular o SQL Server Agent no PostgreSQL
](CHAP_Source.SQLServer.ToPostgreSQL.ExtensionPack.Agent.md)
+ [
# Usando um pacote AWS SCT de extensão para emular o SQL Server Database Mail no PostgreSQL
](CHAP_Source.SQLServer.ToPostgreSQL.ExtensionPack.Mail.md)
## Privilégios do PostgreSQL como um banco de dados de destino
Para usar o PostgreSQL como destino AWS SCT , é necessário o privilégio. `CREATE ON DATABASE` Certifique-se de conceder esse privilégio para cada banco de dados PostgreSQL de destino.
Para usar os sinônimos públicos convertidos, altere o caminho de pesquisa padrão do banco de dados para `"$user", public_synonyms, public`.
É possível utilizar o exemplo de código a seguir para criar um usuário do banco de dados e conceder os privilégios.
```
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;
```
No exemplo anterior, *user\$1name* substitua pelo nome do seu usuário. Em seguida, *db\$1name* substitua pelo nome do seu banco de dados de destino. Por fim, *your\$1password* substitua por uma senha segura.
No PostgreSQL, apenas o proprietário do esquema ou um `superuser` pode descartar um esquema. O proprietário pode descartar um esquema e todos os objetos incluídos nesse esquema, mesmo que o proprietário do esquema não possua alguns de seus objetos.
Ao usar usuários diferentes para converter e aplicar esquemas diferentes ao banco de dados de destino, você pode receber uma mensagem de erro quando não AWS SCT consegue descartar um esquema. Para evitar essa mensagem de erro, use o perfil `superuser`.
## Configurações de conversão do SQL Server para o PostgreSQL
Para editar as configurações de conversão do SQL Server para PostgreSQL, escolha **Configurações** e, em seguida, escolha **Configurações de conversão**. Na lista superior, escolha **SQL Server** e, em seguida, escolha **SQL Server: PostgreSQL**. A AWS SCT exibe todas as configurações disponíveis para conversão de SQL Server para PostgreSQL.
As configurações AWS SCT de conversão do SQL Server para PostgreSQL incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para permitir o uso de índices com o mesmo nome em tabelas diferentes no SQL Server.
No PostgreSQL, todos os nomes de índice que você usa no esquema devem ser exclusivos. Para garantir que isso AWS SCT gere nomes exclusivos para todos os seus índices, selecione **Gerar nomes exclusivos para índices**.
+ Para converter procedimentos do SQL Server em funções do PostgreSQL.
A versão 10 e anteriores do PostgreSQL não oferece suporte a procedimentos. Para clientes que não estão familiarizados com o uso de procedimentos no PostgreSQL AWS SCT , podem converter procedimentos em funções. Para fazer isso, selecione **Converter procedimentos em perfis**.
+ Para emular a saída de `EXEC` em uma tabela.
Seu banco de dados SQL Server de origem pode armazenar a saída de `EXEC` em uma tabela. A AWS SCT cria tabelas temporárias e um procedimento adicional para emular esse atributo. Para usar essa emulação, selecione **Criar rotinas adicionais para lidar com conjuntos de dados abertos**.
+ Para definir o modelo a ser usado para os nomes dos esquemas no código convertido. Para **Modelo de geração de nome de esquema**, escolha uma das opções a seguir:
+ ****: Usa o nome do banco de dados SQL Server como o nome de um esquema no PostgreSQL.
+ ****: Usa o nome do esquema do SQL Server como o nome de um esquema no PostgreSQL.
+ **\$1**: Usa uma combinação do banco de dados SQL Server e dos nomes do esquema como um nome de esquema no PostgreSQL.
+ Para manter as letras maiúsculas dos nomes dos objetos de origem.
Para evitar a conversão de nomes de objetos em minúsculas, selecione **Evitar conversão para minúsculas para operações com distinção entre maiúsculas e minúsculas**. Essa opção se aplica somente ao ativar a opção de diferenciação de maiúsculas e minúsculas no banco de dados de destino.
+ Para manter os nomes dos parâmetros do seu banco de dados de origem.
Para adicionar aspas duplas aos nomes dos parâmetros no código convertido, selecione **Manter nomes de parâmetros originais**.
## Converter as partições do SQL Server para as partições do PostgreSQL versão 10
Ao converter um banco de dados Microsoft SQL Server em Amazon Aurora Edição Compatível com PostgreSQL (Aurora PostgreSQL) ou o serviço de banco de dados relacional da Amazon para PostgreSQL (Amazon RDS para PostgreSQL), esteja ciente do seguinte.
No SQL Server, você cria partições com funções de partição. Ao fazer a conversão de uma tabela particionada do SQL Server para uma tabela particionada do PostgreSQL versão 10, atente-se aos possíveis problemas:
+ O SQL Server permite que você particione uma tabela usando uma coluna sem restrição NOT NULL. Nesse caso, todos os valores NULL passam para a partição mais à esquerda. O PostgreSQL não é compatível com os valores NULL para particionamento RANGE.
+ O SQL Server permite que você crie chaves primárias e exclusivas para tabelas particionadas. No PostgreSQL, é possível criar chaves primárias e exclusivas para cada partição diretamente. Assim, a restrição PRIMARY UNIQUE KEY deve ser removida da tabela pai ao migrar para o PostgreSQL. Os nomes de chaves resultantes assumem o formato `_`.
+ O SQL Server permite que você crie a restrição de chave estrangeira para e de tabelas particionadas. O PostgreSQL não é compatível com chaves estrangeiras que referenciam tabelas particionadas. Além disso, o PostgreSQL não é compatível com as referências de chave estrangeira de uma tabela particionada para outra tabela.
+ O SQL Server permite que você crie índices para tabelas particionadas. No PostgreSQL, um índice deve ser criado para cada partição diretamente. Assim, os índices devem ser removidos das tabelas pai ao migrar para o PostgreSQL. Os nomes de índices resultantes assumem o formato `_`.
+ O PostgreSQL não é compatível com índices particionados.
## Considerações sobre a migração
Há alguns aspectos a serem considerados ao migrar um esquema do SQL Server para o PostgreSQL:
+ No PostgreSQL, todos os nomes de objeto em um esquema devem ser exclusivos, incluindo os índices. Os nomes de índice devem ser exclusivos no esquema da tabela-base. No SQL Server, um nome de índice pode ser o mesmo em tabelas diferentes.
Para garantir a exclusividade dos nomes de índice, você tem AWS SCT a opção de gerar nomes de índice exclusivos se seus nomes de índice não forem exclusivos. Para isso, clique na opção **Generate unique index names (Gerar nomes de índice exclusivos)** nas propriedades do projeto. Por padrão, essa opção é habilitada. Se essa opção estiver habilitada, os nomes de índice exclusivos são criados usando o formato IX\$1table\$1name\$1index\$1name. Caso contrário, os nomes de índice não são alterados.
+ Uma instrução GOTO e um rótulo podem ser usados para alterar a ordem em que as instruções são executadas. Todas as instruções Transact-SQL que seguem a instrução GOTO são ignoradas, e o processamento continua no rótulo. As instruções GOTO e os rótulos podem ser usados em qualquer lugar dentro de um procedimento, lote ou bloco de instruções. Além disso, as instruções GOTO podem ser agrupadas.
O PostgreSQL não usa instruções GOTO. Ao AWS SCT converter o código que contém uma instrução GOTO, ele converte a instrução para usar uma instrução BEGIN... END ou LOOP... END LOOP. Você pode encontrar exemplos de como AWS SCT converte instruções GOTO na tabela a seguir.
**As instruções GOTO do SQL Server e as instruções PostgreSQL convertidas**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServer.ToPostgreSQL.html)
+ O PostgreSQL não suporta uma instrução MERGE. AWS SCT emula o comportamento de uma instrução MERGE das seguintes formas:
+ Com a construção INSERT ON CONFLICT.
+ Com a instrução UPDATE FROM DML, como MERGE sem uma cláusula WHEN NOT MATCHED.
+ Ao usar CURSOR, como com uma cláusula MERGE com DELETE ou usando uma instrução de condição MERGE ON complexa.
+ AWS SCT pode adicionar gatilhos de banco de dados à árvore de objetos quando o Amazon RDS é o destino.
+ AWS SCT pode adicionar gatilhos em nível de servidor à árvore de objetos quando o Amazon RDS é o destino.
+ O SQL Server cria e gerencia tabelas `deleted` e `inserted` automaticamente. Você pode usar essas tabelas temporárias residentes na memória para testar os efeitos de determinadas modificações de dados e definir condições para ações de acionamento de DML. AWS SCT pode converter o uso dessas tabelas em declarações de gatilho DML.
+ AWS SCT pode adicionar servidores vinculados à árvore de objetos quando o Amazon RDS é o destino.
+ Ao migrar do Microsoft SQL Server para PostgreSQL, a função SUSER\$1SNAME incorporada é convertida da seguinte forma:
+ SUSER\$1SNAME – retorna o nome de login associado a um número de identificação de segurança (SID).
+ SUSER\$1SNAME() – Sem suporte.
+ SUSER\$1SNAME CURRENT\$1USER () – Retorna o nome do usuário do contexto de execução atual.
+ SUSER\$1SNAME (NULL) – Retorna NULL.
+ A conversão de funções com valor de tabela é suportada. As funções com valor de tabela retornam uma tabela e podem substituir uma tabela em uma consulta.
+ PATINDEX retorna a posição inicial da primeira ocorrência de um padrão em uma expressão especificada em todos os tipos de dados de texto e caracteres válidos. Ele retornará zeros se o padrão não for encontrado. Ao converter do SQL Server para o Amazon RDS for AWS SCT PostgreSQL, substitui o código do aplicativo que usa PATINDEX por aws\$1sqlserver\$1ext.patindex (,).
+ No SQL Server, um tipo de tabela definido pelo usuário representa a definição de uma estrutura de tabela. Use um tipo de tabela definido pelo usuário para declarar parâmetros de valor de tabela para procedimentos armazenados ou funções. Você também pode usar um tipo de tabela definido pelo usuário para declarar variáveis de tabela que você deseja usar em um lote ou no corpo de um procedimento ou função armazenado. AWS SCT emulou esse tipo no PostgreSQL criando uma tabela temporária.
Ao converter do SQL Server para o PostgreSQL AWS SCT , converte objetos do sistema SQL Server em objetos reconhecíveis no PostgreSQL. A tabela a seguir mostra como os objetos do sistema foram convertidos.
| Casos de uso do MS SQL Server | Substituição do PostgreSQL |
| --- | --- |
| SYS.SCHEMAS | AWS\$1SQLSERVER\$1EXT.SYS\$1ESQUEMAS |
| SYS.TABLES | AWS\$1SQLSERVER\$1EXT.SYS\$1TABELAS |
| SYS.VIEWS | AWS\$1SQLSERVER\$1EXT.SYS\$1VIEWS |
| SYS.ALL\$1VIEWS | AWS\$1SQLSERVER\$1EXT.SYS\$1ALL\$1VIEWS |
| SYS.TYPES | AWS\$1SQLSERVERTIPOS \$1EXT.SYS |
| SYS.COLUMNS | AWS\$1SQLSERVER\$1EXT.SYS\$1COLUNAS |
| SYS.ALL\$1COLUMNS | AWS\$1SQLSERVER\$1EXT.SYS\$1ALL\$1COLUMNS |
| SYS.FOREIGN\$1KEYS | AWS\$1SQLSERVER\$1EXT.SYS\$1CHAVES ESTRANGEIRAS |
| SYS.SYSFOREIGNKEYS | AWS\$1SQLSERVER\$1EXT.SYS\$1SYS CHAVES ESTRANGEIRAS |
| SYS.FOREIGN\$1KEY\$1COLUMNS | AWS\$1SQLSERVER\$1EXT.SYS\$1COLUNAS\$1CHAVE\$1ESTRANGEIRAS |
| SYS.KEY\$1CONSTRAINTS | AWS\$1SQLSERVERRESTRIÇÕES \$1EXT.SYS\$1KEY\$1 |
| SYS.IDENTITY\$1COLUMNS | AWS\$1SQLSERVER\$1EXT.SYS\$1IDENTITY\$1COLUMNS |
| SYS.PROCEDURES | AWS\$1SQLSERVERPROCEDIMENTOS \$1EXT.SYS |
| SYS.INDEXES | AWS\$1SQLSERVER\$1EXT.SYS\$1INDEXES |
| SYS.SYSINDEXES | AWS\$1SQLSERVERÍNDICES \$1EXT.SYS\$1SYS |
| SYS.OBJECTS | AWS\$1SQLSERVER\$1EXT.SYS\$1OBJECTS |
| SYS.ALL\$1OBJECTS | AWS\$1SQLSERVER\$1EXT.SYS\$1TODOS\$1OBJETOS |
| SYS.SYSOBJECTS | AWS\$1SQLSERVER\$1EXT.SYS\$1SYSOBJECTS |
| SYS.SQL\$1MODULES | AWS\$1SQLSERVER\$1EXT.SYS\$1SQL\$1MODULES |
| SYS.DATABASES | AWS\$1SQLSERVER\$1EXT.SYS\$1BANCOS DE DADOS |
| INFORMATION\$1SCHEMA.SCHEMATA | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1SCHEMATA |
| INFORMATION\$1SCHEMA.VIEWS | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1VIEWS |
| INFORMATION\$1SCHEMA.TABLES | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1TABLES |
| INFORMATION\$1SCHEMA.COLUMNS | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1COLUMNS |
| INFORMATION\$1SCHEMA.CHECK\$1CONSTRAINTS | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1CHECK\$1CONSTRAINTS |
| INFORMATION\$1SCHEMA.REFERENTIAL\$1CONSTRAINTS | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1REFERENTIAL\$1CONSTRAINTS |
| INFORMATION\$1SCHEMA.TABLE\$1CONSTRAINTS | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1TABLE\$1CONSTRAINTS |
| INFORMATION\$1SCHEMA.KEY\$1COLUMN\$1USAGE | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1KEY\$1COLUMN\$1USAGE |
| INFORMATION\$1SCHEMA.CONSTRAINT\$1TABLE\$1USAGE | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1CONSTRAINT\$1TABLE\$1USAGE |
| INFORMATION\$1SCHEMA.CONSTRAINT\$1COLUMN\$1USAGE | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1CONSTRAINT\$1COLUMN\$1USAGE |
| INFORMATION\$1SCHEMA.ROUTINES | AWS\$1SQLSERVER\$1EXT.INFORMATION\$1SCHEMA\$1ROTINAS |
| SYS.SYSPROCESSES | AWS\$1SQLSERVERPROCESSOS \$1EXT.SYS\$1SYS |
| sys.system\$1objects | AWS\$1SQLSERVER\$1EXT.SYS\$1SYSTEM\$1OBJECTS |
# Usando um pacote AWS SCT de extensão para emular o SQL Server Agent no PostgreSQL
SQL Server Agent é um serviço do Microsoft Windows que executa trabalhos do SQL Server. SQL Server Agent pode executar trabalhos agendados em resposta a um evento específico ou sob demanda. Para obter mais informações sobre o SQL Server Agent, consulte a [documentação técnica da Microsoft](https://docs.microsoft.com/en-us/sql/ssms/agent/sql-server-agent?view=sql-server-ver15).
O PostgreSQL não tem um equivalente para SQL Server Agent. Para emular os recursos do SQL Server Agent, AWS SCT cria um pacote de extensão. Este pacote de extensão usa AWS Lambda e Amazon CloudWatch. AWS Lambda implementa a interface que você usa para gerenciar agendamentos e executar trabalhos. A Amazon CloudWatch mantém as regras de programação.
AWS Lambda e a Amazon CloudWatch usam um parâmetro JSON para interagir. Esse parâmetro JSON tem a seguinte estrutura.
```
{
"mode": mode,
"parameters": {
list of parameters
},
"callback": procedure name
}
```
No exemplo anterior, *`mode`* é o tipo da tarefa e `list of parameters` é um conjunto de parâmetros que dependem do tipo da tarefa. Além disso, `procedure name` é o nome do procedimento executado após a conclusão da tarefa.
AWS SCT usa uma função Lambda para controlar e executar trabalhos. A CloudWatch regra inicia a execução do trabalho e fornece as informações necessárias para iniciar o trabalho. Quando a CloudWatch regra é acionada, ela inicia a função Lambda usando os parâmetros da regra.
Para criar um trabalho simples que chame um procedimento, use o formato a seguir.
```
{
"mode": "run_job",
"parameters": {
"vendor": "mysql",
"cmd": "lambda_db.nightly_job"
}
}
```
Para criar um trabalho com várias etapas, use o formato a seguir.
```
{
"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
},
...
]
}
```
Para emular o comportamento do SQL Server Agent no PostgreSQL, AWS SCT o pacote de extensões também cria as tabelas e os procedimentos a seguir.
## Tabelas que emulam o SQL Server Agent no PostgreSQL
Para emular o SQL Server Agent, o pacote de extensão usa as seguintes tabelas:
**sysjobs**
Armazena as informações sobre os trabalhos.
**sysjobsteps**
Armazena as informações sobre as etapas de um trabalho.
**sysschedules**
Armazena as informações sobre os cronogramas de trabalho.
**sysjobschedules**
Armazena as informações de cronograma de trabalhos individuais.
**sysjobhistory**
Armazena as informações sobre as execuções de trabalhos programados.
## Procedimentos que emulam o SQL Server Agent no PostgreSQL
Para emular o SQL Server Agent, o pacote de extensão usa os seguintes procedimentos:
**sp\$1add\$1job**
Adiciona um novo trabalho.
**sp\$1add\$1jobstep**
Adiciona uma etapa a um trabalho.
**sp\$1add\$1schedule**
Cria uma nova regra de agendamento na Amazon CloudWatch. Você pode usar esse cronograma com qualquer número de trabalhos.
**sp\$1attach\$1schedule**
Define um cronograma para o trabalho selecionado.
**sp\$1add\$1jobschedule**
Cria uma regra de agendamento para um trabalho na Amazon CloudWatch e define a meta para essa regra.
**sp\$1update\$1job**
Atualiza os atributos do trabalho criado anteriormente.
**sp\$1update\$1jobstep**
Atualiza os atributos da etapa em um trabalho.
**sp\$1update\$1schedule**
Atualiza os atributos de uma regra de agendamento na Amazon CloudWatch.
**sp\$1update\$1jobschedule**
Atualiza os atributos do cronograma para o trabalho especificado.
**sp\$1delete\$1job**
Exclui um trabalho.
**sp\$1delete\$1jobstep**
Exclui uma etapa do trabalho de um trabalho.
**sp\$1delete\$1schedule**
Exclui um cronograma.
**sp\$1delete\$1jobschedule**
Exclui a regra de agendamento para o trabalho especificado da Amazon CloudWatch.
**sp\$1detach\$1schedule**
Remove uma associação entre um cronograma e um trabalho.
**get\$1jobs, update\$1job**
Procedimentos internos que interagem com 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**
Procedimentos internos que verificam as configurações.
## Sintaxe para procedimentos que emulam o SQL Server Agent no PostgreSQL
O procedimento `aws_sqlserver_ext.sp_add_job` no pacote de extensão emula o procedimento `msdb.dbo.sp_add_job`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_add_jobstep` no pacote de extensão emula o procedimento `msdb.dbo.sp_add_jobstep`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_add_schedule` no pacote de extensão emula o procedimento `msdb.dbo.sp_add_schedule`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_attach_schedule` no pacote de extensão emula o procedimento `msdb.dbo.sp_attach_schedule`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_add_jobschedule` no pacote de extensão emula o procedimento `msdb.dbo.sp_add_jobschedule`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_delete_job` no pacote de extensão emula o procedimento `msdb.dbo.sp_delete_job`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_delete_jobstep` no pacote de extensão emula o procedimento `msdb.dbo.sp_delete_jobstep`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_delete_jobschedule` no pacote de extensão emula o procedimento `msdb.dbo.sp_delete_jobschedule`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_delete_schedule` no pacote de extensão emula o procedimento `msdb.dbo.sp_delete_schedule`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_detach_schedule` no pacote de extensão emula o procedimento `msdb.dbo.sp_detach_schedule`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_update_job` no pacote de extensão emula o procedimento `msdb.dbo.sp_update_job`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_update_jobschedule` no pacote de extensão emula o procedimento `msdb.dbo.sp_update_jobschedule`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_update_jobstep` no pacote de extensão emula o procedimento `msdb.dbo.sp_update_jobstep`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sp_update_schedule` no pacote de extensão emula o procedimento `msdb.dbo.sp_update_schedule`. Para obter mais informações sobre o procedimento do SQL Server Agent de origem, consulte a [documentação técnica da 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
```
## Exemplos de uso de procedimentos que emulam o SQL Server Agent no PostgreSQL
Para adicionar um novo trabalho, use o procedimento `aws_sqlserver_ext.sp_add_job` conforme mostrado a seguir.
```
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');
```
Para adicionar uma nova etapa do trabalho, use o procedimento `aws_sqlserver_ext.sp_add_jobstep` conforme mostrado a seguir.
```
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');
```
Para adicionar um cronograma simples, use o procedimento `aws_sqlserver_ext.sp_add_schedule` conforme mostrado a seguir.
```
SELECT * FROM aws_sqlserver_ext.sp_add_schedule(
par_schedule_name := 'RunOnce',
par_freq_type := 1,
par_active_start_time := 233000);
```
Para definir um cronograma para um trabalho, use o procedimento `aws_sqlserver_ext.sp_attach_schedule` conforme mostrado a seguir.
```
SELECT * FROM aws_sqlserver_ext.sp_attach_schedule (
par_job_name := 'test_job',
par_schedule_name := 'NightlyJobs');
```
Para criar um cronograma para um trabalho, use o procedimento `aws_sqlserver_ext.sp_add_jobschedule` conforme mostrado a seguir.
```
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);
```
## Use exemplos de casos para emular o SQL Server Agent no PostgreSQL
Se o código-fonte do banco de dados usa o SQL Server Agent para executar trabalhos, você pode usar o pacote de extensão SQL Server para PostgreSQL AWS SCT para converter esse código em PostgreSQL. O pacote de extensão usa AWS Lambda funções para emular o comportamento do SQL Server Agent.
Você pode criar uma nova AWS Lambda função ou registrar uma função existente.
**Para criar uma nova AWS Lambda função**
1. Em AWS SCT, na árvore do banco de dados de destino, abra o menu de contexto (clique com o botão direito do mouse), escolha **Aplicar pacote de extensão para** e, em seguida, escolha **PostgreSQL**.
O assistente do pacote de extensões é exibido.
1. Na guia **Serviço de emulação do SQL Server Agent**, faça o seguinte:
+ Escolha **Criar uma AWS Lambda função**.
+ Em **Login do banco de dados**, insira o nome do usuário do banco de dados de destino.
+ Em **Senha do banco de dados**, insira a senha do nome de usuário que você inseriu na etapa anterior.
+ Para a **pasta da biblioteca Python**, insira o caminho para a pasta da biblioteca Python.
+ Escolha **Criar AWS Lambda função** e, em seguida, escolha **Avançar**.
**Para registrar uma AWS Lambda função que você implantou anteriormente**
+ Execute o script a seguir no banco de dados de destino.
```
SELECT
FROM aws_sqlserver_ext.set_service_setting(
p_service := 'JOB',
p_setting := 'LAMBDA_ARN',
p_value := ARN)
```
No exemplo anterior, *`ARN`* é o nome do recurso da Amazon (ARN) da função AWS Lambda implantada.
O exemplo a seguir cria uma tarefa simples que consiste em uma etapa. A cada cinco minutos, essa tarefa executa a função `job_example` criada anteriormente. Essa função insere registros na tabela `job_example_table`.
**Para criar essa tarefa simples**
1. Crie um trabalho usando a função `aws_sqlserver_ext.sp_add_job`, conforme mostrado a seguir.
```
SELECT
FROM aws_sqlserver_ext.sp_add_job (
par_job_name := 'test_simple_job');
```
1. Crie uma etapa de trabalho usando a função `aws_sqlserver_ext.sp_add_jobstep`, conforme mostrado a seguir.
```
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;');
```
A etapa do trabalho especifica o que a função faz.
1. Crie um programador para o trabalho usando a função `aws_sqlserver_ext.sp_add_jobschedule`, conforme mostrado a seguir.
```
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 */);
```
A etapa do trabalho especifica o que a função faz.
Para excluir esse trabalho, use a função `aws_sqlserver_ext.sp_delete_job` conforme mostrado a seguir.
```
PERFORM aws_sqlserver_ext.sp_delete_job(
par_job_name := 'PeriodicJob1'::character varying,
par_delete_history := 1::smallint,
par_delete_unused_schedule := 1::smallint);
```
# Usando um pacote AWS SCT de extensão para emular o SQL Server Database Mail no PostgreSQL
Você pode usar o SQL Server Database Mail para enviar mensagens de e-mail aos usuários a partir do mecanismo de banco de dados do SQL Server ou da instância gerenciada do Azure SQL. Essas mensagens de e-mail podem conter resultados de consultas ou incluir arquivos de qualquer recurso em sua rede. Para obter mais informações sobre o SQL Server Database Mail, consulte a [documentação técnica da Microsoft](https://docs.microsoft.com/en-us/sql/relational-databases/database-mail/database-mail?view=sql-server-ver15).
O PostgreSQL não tem um equivalente para o SQL Server Database Mail. Para emular os atributos do SQL Server Database Mail, a AWS SCT cria um pacote de extensão. Esse pacote de extensão usa AWS Lambda o Amazon Simple Email Service (Amazon SES). AWS Lambda fornece aos usuários uma interface para interagir com o serviço de envio de e-mail do Amazon SES. Para configurar essa interação, adicione o nome do recurso da Amazon (ARN) da sua função do Lambda.
Para uma nova conta de e-mail, use o comando a seguir.
```
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;
```
Para adicionar o ARN da sua função do Lambda à conta de e-mail existente, use o comando a seguir.
```
do
$$
begin
PERFORM sysmail_update_account_sp (
par_account_name :='existind_account_name',
par_mailserver_type := 'AWSLAMBDA'
par_mailserver_name := 'ARN'
);
end;
$$ language plpgsql;
```
Nos exemplos anteriores, *`ARN`* é o ARN da sua função do Lambda.
Para emular o comportamento do SQL Server Database Mail no PostgreSQL, o pacote de extensão da AWS SCT usa as seguintes tabelas, visualizações e procedimentos.
## Tabelas que emulam o SQL Server Database Mail no PostgreSQL
Para emular o SQL Server Database Mail, o pacote de extensão usa as seguintes tabelas:
**sysmail\$1account**
Armazena as informações sobre as contas de e-mail.
**sysmail\$1profile**
Armazena as informações sobre os perfis de usuário.
**sysmail\$1server**
Armazena as informações sobre os servidores de e-mail.
**sysmail\$1mailitems**
Armazena a lista das mensagens de e-mail.
**sysmail\$1attachments**
Contém uma linha para cada anexo de e-mail.
**sysmail\$1log**
Armazena as informações do serviço sobre o envio de mensagens de e-mail.
**sysmail\$1profileaccount**
Armazena as informações sobre os perfis de usuário e contas de e-mail.
## Visualizações que emulam o SQL Server Database Mail no PostgreSQL
Para emular o SQL Server Database Mail, AWS SCT cria as seguintes visualizações no banco de dados PostgreSQL para garantir a compatibilidade. O pacote de extensão não as usa, mas seu código convertido pode consultar essas visualizações.
**sysmail\$1allitems**
Inclui uma lista de todos os e-mails.
**sysmail\$1faileditems**
Inclui uma lista de e-mails que não puderam ser enviados.
**sysmail\$1sentitems**
Inclui uma lista de e-mails enviados.
**sysmail\$1unsentitems**
Inclui uma lista de e-mails que ainda não foram enviados.
**sysmail\$1mailattachments**
Inclui uma lista de arquivos anexados.
## Procedimentos que emulam o SQL Server Database Mail no PostgreSQL
Para emular o SQL Server Database Mail, o pacote de extensão usa os seguintes procedimentos:
**sp\$1send\$1dbmail**
Envia um e-mail para os destinatários especificados.
**sysmail\$1add\$1profile\$1sp**
Cria um novo perfil de usuário.
**sysmail\$1add\$1account\$1sp**
Cria uma nova conta de e-mail que armazena informações como credenciais do Simple Mail Transfer Protocol (SMTP) e assim por diante.
**sysmail\$1add\$1profileaccount\$1sp**
Adiciona uma conta de e-mail ao perfil de usuário especificado.
**sysmail\$1update\$1profile\$1sp**
Altera os atributos do perfil do usuário, como descrição, nome e assim por diante.
**sysmail\$1update\$1account\$1sp**
Altera as informações na conta de e-mail existente.
**sysmail\$1update\$1profileaccount\$1sp**
Atualiza as informações da conta de e-mail no perfil de usuário especificado.
**sysmail\$1delete\$1profileaccount\$1sp**
Remove uma conta de e-mail do perfil de usuário especificado.
**sysmail\$1delete\$1account\$1sp**
Exclui a conta de e-mail.
**sysmail\$1delete\$1profile\$1sp**
Exclui o perfil de usuário.
**sysmail\$1delete\$1mailitems\$1sp**
Exclui e-mails de tabelas internas.
**sysmail\$1help\$1profile\$1sp**
Exibe informações sobre o perfil do usuário.
**sysmail\$1help\$1account\$1sp**
Exibe informações sobre a conta de e-mail.
**sysmail\$1help\$1profileaccount\$1sp**
Exibe informações sobre contas de e-mail associadas ao perfil de usuário.
**sysmail\$1dbmail\$1json**
Um procedimento interno que gera solicitações JSON para AWS Lambda funções.
**sysmail\$1verify\$1profile\$1sp, sysmail\$1verify\$1account\$1sp, sysmail\$1verify\$1addressparams\$1sp**
Procedimentos internos que verificam as configurações.
**sp\$1get\$1dbmail, sp\$1set\$1dbmail, sysmail\$1dbmail\$1xml**
Procedimentos internos obsoletos.
## Sintaxe para procedimentos que emulam o SQL Server Database Mail no PostgreSQL
O procedimento `aws_sqlserver_ext.sp_send_dbmail` no pacote de extensão emula o procedimento `msdb.dbo.sp_send_dbmail`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_delete_mailitems_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_delete_mailitems_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_add_profile_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_add_profile_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_add_account_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_add_account_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_add_profileaccount_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_add_profileaccount_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_help_profile_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_help_profile_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_update_profile_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_update_profile_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_delete_profile_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_delete_profile_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_help_account_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_help_account_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_update_account_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_update_account_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_delete_account_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_delete_account_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_help_profileaccount_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_help_profileaccount_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_update_profileaccount_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_update_profileaccount_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
O procedimento `aws_sqlserver_ext.sysmail_delete_profileaccount_sp` no pacote de extensão emula o procedimento `msdb.dbo.sysmail_delete_profileaccount_sp`. Para obter mais informações sobre o procedimento do SQL Server Database Mail de origem, consulte a [documentação técnica da 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
```
## Exemplos de uso de procedimentos que emulam o SQL Server Database Mail no PostgreSQL
Para enviar um e-mail, use o procedimento `aws_sqlserver_ext.sp_send_dbmail` conforme mostrado a seguir.
```
PERFORM sp_send_dbmail (
par_profile_name := 'Administrator',
par_recipients := 'hello@rusgl.info',
par_subject := 'Automated Success Message',
par_body := 'The stored procedure finished'
);
```
O exemplo a seguir mostra como enviar um e-mail com resultados da consulta.
```
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'
);
```
O exemplo a seguir mostra como enviar e-mails brutos com código 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'
);
```
Para excluir e-mails, use o procedimento `aws_sqlserver_ext.sysmail_delete_mailitems_sp` conforme mostrado a seguir.
```
DECLARE var_GETDATE datetime;
SET var_GETDATE = NOW();
PERFORM sysmail_delete_mailitems_sp (
par_sent_before := var_GETDATE
);
```
O exemplo a seguir mostra como excluir os e-mails mais antigos.
```
PERFORM sysmail_delete_mailitems_sp (
par_sent_before := '31.12.2015'
);
```
O exemplo a seguir mostra como excluir todos os e-mails que não podem ser enviados.
```
PERFORM sysmail_delete_mailitems_sp (
par_sent_status := 'failed'
);
```
Para criar um novo perfil de usuário, use o procedimento `aws_sqlserver_ext.sysmail_add_profile_sp` conforme mostrado a seguir.
```
PERFORM sysmail_add_profile_sp (
profile_name := 'Administrator',
par_description := 'administrative mail'
);
```
O exemplo a seguir mostra como criar um novo perfil e salvar o identificador de perfil exclusivo em uma variável.
```
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;
```
Para criar uma nova conta de e-mail, use o procedimento `aws_sqlserver_ext.sysmail_add_account_sp` conforme mostrado a seguir.
```
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'
);
```
Para adicionar uma conta de e-mail ao perfil do usuário, use o procedimento `aws_sqlserver_ext.sysmail_add_profileaccount_sp` conforme mostrado a seguir.
```
PERFORM sysmail_add_profileaccount_sp (
par_account_name := 'Administrator',
par_account_name := 'Audit Account',
par_sequence_number := 1
);
```
## Use exemplos de casos para emular o SQL Server Database Mail no PostgreSQL
Se o código-fonte do banco de dados usa o SQL Server Database Mail para enviar e-mails, você pode usar o pacote de AWS SCT extensão para converter esse código em PostgreSQL.
**Para enviar um e-mail do seu banco de dados PostgreSQL**
1. Crie e configure sua AWS Lambda função.
1. Aplique o pacote AWS SCT de extensão.
1. Crie um perfil de usuário usando a função `sysmail_add_profile_sp` conforme mostrado a seguir.
1. Crie uma conta de e-mail usando a função `sysmail_add_account_sp` conforme mostrado a seguir.
1. Adicione essa conta de e-mail ao seu perfil de usuário usando a função `sysmail_add_profileaccount_sp` mostrada a seguir.
```
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. Envie um e-mail usando a função `sp_send_dbmail`, conforme mostrado a seguir.
```
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;
```
Para ver as informações sobre todos os perfis de usuário, use o procedimento `sysmail_help_profile_sp` conforme mostrado a seguir.
```
SELECT FROM aws_sqlserver_ext.sysmail_help_profile_sp();
```
O exemplo a seguir exibe as informações sobre o perfil de usuário específico.
```
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');
```
Para visualizar as informações sobre todas as contas de e-mail, use o procedimento `sysmail_help_account_sp` conforme mostrado a seguir.
```
select from aws_sqlserver_ext.sysmail_help_account_sp();
```
O exemplo a seguir exibe as informações sobre a conta de e-mail específica.
```
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');
```
Para visualizar as informações sobre todas as contas de e-mail que estão associadas com os perfis de usuário, use o procedimento `sysmail_help_profileaccount_sp` conforme mostrado a seguir.
```
select from aws_sqlserver_ext.sysmail_help_profileaccount_sp();
```
O exemplo a seguir filtra os registros por identificador, nome do perfil ou nome da conta.
```
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');
```
Para alterar o nome ou a descrição do perfil do usuário, use o procedimento `sysmail_update_profile_sp` conforme mostrado a seguir.
```
select aws_sqlserver_ext.sysmail_update_profile_sp(
par_profile_id := 2,
par_profile_name := 'New profile name'
);
```
Para alterar as configurações da conta de e-mail, use o procedimento `ysmail_update_account_sp` conforme mostrado a seguir.
```
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'
);
```
# Migração do SQL Server para o Amazon RDS for SQL Server com AWS Schema Conversion Tool
Há alguns aspectos a serem considerados ao migrar o esquema e o código do SQL Server para o Amazon RDS for SQL Server:
+ AWS SCT pode converter o SQL Server Agent para fornecer agendas, alertas e trabalhos em uma instância de banco de dados Amazon RDS for SQL Server. Após a conversão, é possível usar uma instância de banco de dados do Amazon RDS for SQL Server com o SQL Server Reporting Service (SSRS), o SQL Server Analysis Services (SSAS) e o SQL Server Integration Services (SSIS).
+ Atualmente, o Amazon RDS não é compatível com o SQL Server Service Broker nem outros endpoints do T-SQL que exijam a execução do comando CREATE ENDPOINT.
+ O Amazon RDS tem suporte limitado para servidores vinculados. Ao converter o código do aplicativo SQL Server que usa servidores vinculados, AWS SCT converte o código do aplicativo. No entanto, certifique-se de revisar o comportamento de objetos que usam servidores vinculados antes de executar o código convertido.
+ Sempre ativo é usado.
+ O relatório de AWS SCT avaliação fornece métricas do servidor para a conversão. Essas métricas sobre sua instância do SQL Server incluem:
+ O espelhamento de dados é usado.
+ O envio de logs do SQL Server é configurado.
+ O cluster de failover é usado.
+ O e-mail do banco de dados é configurado.
+ O serviço Full Text Search é usado. O Amazon RDS for SQL Server tem um Full Text Search limitado. Além disso, ele não oferece suporte à pesquisa semântica.
+ O Data Quality Service (DQS) está instalado. O Amazon RDS não oferece suporte ao DQS. Portanto, recomendamos que você instale o SQL Server em uma instância do Amazon EC2.
## Privilégios do RDS para SQL Server como destino
Para migrar para o RDS para SQL Server, crie um usuário de banco de dados e, em seguida, conceda os privilégios necessários para cada banco de dados. Você pode usar o exemplo de código a seguir.
```
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;
```
No exemplo anterior, *user\$1name* substitua pelo nome do seu usuário. Em seguida, *db\$1name* substitua pelo nome do seu banco de dados de destino. Por fim, *your\$1password* substitua por uma senha segura.
# Fontes de armazenamento de dados para AWS Schema Conversion Tool
AWS SCT pode converter esquemas dos seguintes data warehouses de origem em um destino compatível. Para obter informações sobre permissões, conexões e o que AWS SCT pode ser convertido para uso com o banco de dados de destino ou o data warehouse, consulte os detalhes a seguir.
**Topics**
+ [
# Conectando o Amazon Redshift com o AWS Schema Conversion Tool
](CHAP_Source.Redshift.md)
+ [
# Conectando o Azure Synapse Analytics com AWS Schema Conversion Tool
](CHAP_Source.AzureSynapse.md)
+ [
# Conectando-se ao Google BigQuery com AWS Schema Conversion Tool
](CHAP_Source.BigQuery.md)
+ [
# Conectando o banco de dados Greenplum com AWS Schema Conversion Tool
](CHAP_Source.Greenplum.md)
+ [
# Conectando-se ao Netezza com AWS Schema Conversion Tool
](CHAP_Source.Netezza.md)
+ [
# Conectando o Oracle Data Warehouse com AWS SCT
](CHAP_Source.OracleDW.md)
+ [
# Conectando-se a um data warehouse do Snowflake com AWS Schema Conversion Tool
](CHAP_Source.Snowflake.md)
+ [
# Conectando-se a um SQL Server Data Warehouse com o AWS Schema Conversion Tool
](CHAP_Source.SQLServerDW.md)
+ [
# Conectando-se a um data warehouse da Teradata com o AWS Schema Conversion Tool
](CHAP_Source.Teradata.md)
+ [
# Conectando os bancos AWS Schema Conversion Tool de dados Vertica
](CHAP_Source.Vertica.md)
# Conectando o Amazon Redshift com o AWS Schema Conversion Tool
Você pode usar AWS SCT para otimizar seu cluster do Amazon Redshift. AWS SCT fornece recomendações sobre a seleção de chaves de distribuição e classificação para seu cluster do Amazon Redshift. Você pode considerar o projeto de otimização do Amazon Redshift como um AWS SCT projeto com a origem e o destino apontando para os diferentes clusters do Amazon Redshift.
## Privilégios do Amazon Redshift como um banco de dados de origem
Os privilégios obrigatórios para usar o Amazon Redshift como uma origem estão listados a seguir:
+ USO NO ESQUEMA **
+ SELECIONE EM TODAS AS TABELAS NO ESQUEMA **
+ SELECT ON PG\$1CATALOG.PG\$1STATISTIC
+ SELECT ON SVV\$1TABLE\$1INFO
+ SELECT ON TABLE STV\$1BLOCKLIST
+ SELECT ON TABLE STV\$1TBL\$1PERM
+ SELECT ON SYS\$1SERVERLESS\$1USAGE
+ SELECT ON PG\$1DATABASE\$1INFO
+ SELECT ON PG\$1STATISTIC
Nos exemplos anteriores, substitua o ** espaço reservado pelo nome do esquema de origem.
Para obter os privilégios necessários para o Amazon Redshift como destino, consulte a [Permissões para o Amazon Redshift como destino](CHAP_Converting.DW.md#CHAP_Converting.DW.ConfigureTarget).
## Como se conectar ao Amazon Redshift como origem
Use o procedimento a seguir para conectar seu banco de dados de origem do Amazon Redshift com a AWS Schema Conversion Tool.
**Para se conectar a um banco de dados do Amazon Redshift de origem**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **Amazon Redshift** e, em seguida, escolha **Avançar**.
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para o banco de dados. A AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Use as credenciais do banco de dados AWS Secrets Manager ou insira-as manualmente:
+ Para usar as credenciais do banco de dados do Secrets Manager, use as instruções a seguir:
1. Em **Segredo da AWS **, escolha o nome do seu segredo.
1. Escolha **Preencher** para preencher automaticamente todos os valores na caixa de diálogo de conexão do banco de dados do Secrets Manager.
Para obter informações sobre o uso de credenciais de banco de dados do Secrets Manager, consulte a [Configurando AWS Secrets Manager no AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Para inserir as informações de conexão para o banco de dados de origem do Amazon Redshift, use as instruções a seguir:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.Redshift.html)
1. Escolha **Testar conexão** para verificar se AWS SCT pode se conectar ao seu banco de dados de origem.
1. Escolha **Conectar** para se conectar ao banco de dados de origem.
## Configurações de otimização do Amazon Redshift
Para editar as configurações de otimização do Amazon Redshift, escolha **Configurações** em e AWS SCT, em seguida, escolha Configurações **de conversão**. Na lista superior, escolha **Amazon Redshift** e, em seguida, escolha **Amazon Redshift: Amazon Redshift**. A AWS SCT exibe todas as configurações disponíveis para a otimização do Amazon Redshift.
As configurações de otimização do Amazon Redshift AWS SCT incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para definir o número máximo de tabelas que AWS SCT podem ser aplicadas ao seu cluster de destino do Amazon Redshift.
Em **O número máximo de tabelas para o cluster de destino do Amazon Redshift**, escolha o número de tabelas que AWS SCT podem ser aplicadas ao seu cluster do Amazon Redshift.
O Amazon Redshift tem cotas que limitam as tabelas de uso para diferentes tipos de nós de cluster. Se você escolher **Auto**, AWS SCT determinará o número de tabelas a serem aplicadas ao seu cluster de destino do Amazon Redshift, dependendo do tipo de nó. Opcionalmente, escolha o valor manualmente. Para obter mais informações, consulte “[Cotas e limites no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*.
AWS SCT converte todas as suas tabelas de origem, mesmo que o número de tabelas seja maior do que o seu cluster do Amazon Redshift pode armazenar. AWS SCT armazena o código convertido em seu projeto e não o aplica ao banco de dados de destino. Se você atingir a cota de cluster do Amazon Redshift para as tabelas ao aplicar o código convertido, AWS SCT exibirá uma mensagem de aviso. Além disso, AWS SCT aplica tabelas ao seu cluster de destino do Amazon Redshift até que o número de tabelas atinja o limite.
+ Para escolher a estratégia de migração.
AWS recomenda o uso de clusters diferentes como origem e destino para seu projeto de otimização. Antes do início do processo de otimização do Amazon Redshift, você cria uma cópia do seu cluster do Amazon Redshift de origem. Você pode incluir seus dados de origem nessa cópia ou criar um cluster vazio.
Em **Estratégia de migração**, escolha **Migração para uma cópia** para incluir dados do seu cluster de origem no cluster de destino.
Em **Estratégia de migração**, escolha **Migração para uma lista limpa** para analisar as sugestões de otimização. Depois de aceitar essas sugestões, migre seus dados de origem para o cluster de destino.
+ Para aplicar compactação às colunas da tabela do Amazon Redshift. Para fazer isso, selecione **Usar codificação de compressão**.
AWS SCT atribui a codificação de compactação às colunas automaticamente usando o algoritmo padrão do Amazon Redshift. Para obter mais informações, consulte [Codificações de compactação](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.
Por padrão, o Amazon Redshift não aplica compactação a colunas definidas como chaves de classificação e distribuição. É possível alterar esse comportamento e aplicar compactação a essas colunas. Para fazer isso, selecione **Usar codificação de compactação para colunas KEY**. Você pode selecionar essa opção somente quando você selecionou a opção **Usar codificação de compactação**.
+ Para trabalhar com otimização automática de tabelas.
A otimização automática de tabelas é um processo de autoajuste no Amazon Redshift que otimiza automaticamente o design de tabelas. Para obter mais informações, consulte [Como trabalhar com a otimização automática de tabelas](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) no *Guia do desenvolvedor do banco de dados Amazon Redshift*.
Para usar somente na otimização automática de tabelas, escolha **Estratégias de otimização** no painel esquerdo. Em seguida, selecione **Usar ajuste automático de tabela do Amazon Redshift** e escolha **Nenhum** para a **Estratégia de seleção inicial de chaves**.
+ Para escolher chaves de classificação e distribuição usando sua estratégia.
Você pode escolher chaves de classificação e distribuição usando metadados, informações estatísticas ou ambas as opções do Amazon Redshift. Para **Estratégia inicial de seleção de chave** na guia **Estratégias de otimização**, escolha uma das seguintes opções:
+ Use metadados, ignore informações estatísticas
+ Ignore metadados, use informações estatísticas
+ Use metadados e informações estatísticas
Dependendo da opção escolhida, você pode selecionar estratégias de otimização. Em seguida, para cada estratégia, insira o valor (0-100). Esses valores definem o peso de cada estratégia. Usando esses valores de peso, a AWS SCT define como cada regra influencia na escolha das chaves de distribuição e classificação. Os valores padrão são baseados nas melhores práticas de AWS migração.
Você pode definir o tamanho de tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para defini-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
+ Para configurar os detalhes da estratégia.
Além de definir o peso de cada estratégia de otimização, você pode definir as configurações de otimização. Para fazer isso, escolha **Otimização de conversões**.
+ Em **Limite de colunas da chave de classificação**, insira o número máximo de colunas na chave de classificação.
+ Em **Valor limite distorcido**, insira a porcentagem (0-100) de um valor distorcido para uma coluna. A AWS SCT exclui colunas com um valor de inclinação maior que o limite da lista de candidatos para a chave de distribuição. A AWS SCT define o valor distorcido de uma coluna como a proporção percentual entre o número de ocorrências do valor mais comum e o número total de registros.
+ Para as **N principais consultas da tabela do histórico de consultas**, insira o número (1-100) das consultas usadas com mais frequência para análise.
+ Em **Selecionar usuário de estatísticas**, escolha o usuário do banco de dados cujas estatísticas de consulta você deseja analisar.
# Conectando o Azure Synapse Analytics com AWS Schema Conversion Tool
Você pode usar AWS SCT para converter esquemas, objetos de código e código de aplicativo do Azure Synapse Analytics para o Amazon Redshift.
## Privilégios do Azure Synapse Analytics como banco de dados de origem
Os seguintes privilégios são necessários para usar um data warehouse do Azure Synapse Analytics como origem:
+ VIEW DEFINITION
+ VIEW DATABASE STATE
Aplique os privilégios para cada banco de dados cujo esquema você está convertendo.
## Como se conectar ao Azure Synapse Analytics como origem
Use o procedimento a seguir para se conectar ao data warehouse do Azure Synapse Analytics com a AWS Schema Conversion Tool.
**Para se conectar a um data warehouse do Azure Synapse Analytics como origem**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **Azure Synapse Analytics** e, em seguida, escolha **Avançar**.
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para o banco de dados. A AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Use as credenciais do banco de dados AWS Secrets Manager ou insira-as manualmente:
+ Para usar as credenciais do banco de dados do Secrets Manager, use as instruções a seguir:
1. Em **Segredo da AWS **, escolha o nome do seu segredo.
1. Escolha **Preencher** para preencher automaticamente todos os valores na caixa de diálogo de conexão do banco de dados do Secrets Manager.
Para obter informações sobre o uso de credenciais de banco de dados do Secrets Manager, consulte a [Configurando AWS Secrets Manager no AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Para inserir as informações de conexão do data warehouse do Azure Synapse Analytics manualmente, use as instruções a seguir:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.AzureSynapse.html)
1. Escolha **Testar conexão** para verificar se a AWS SCT pode se conectar ao banco de dados de origem.
1. Escolha **Conectar** para se conectar ao banco de dados de origem.
## Configurações de conversão do Azure Synapse Analytics para o Amazon Redshift
**Para editar as configurações de conversão do Azure Synapse Analytics para o Amazon Redshift, **escolha Configurações em e, AWS SCT em seguida, escolha** Configurações de conversão.** Na lista superior, escolha **Azure Synapse** e, em seguida, escolha **Azure Synapse — Amazon Redshift**. AWS SCT exibe todas as configurações disponíveis para conversão do Azure Synapse Analytics para o Amazon Redshift.
As configurações AWS SCT de conversão do Azure Synapse Analytics para o Amazon Redshift incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para definir o número máximo de tabelas que AWS SCT podem ser aplicadas ao seu cluster de destino do Amazon Redshift.
Em **O número máximo de tabelas para o cluster de destino do Amazon Redshift**, escolha o número de tabelas que AWS SCT podem ser aplicadas ao seu cluster do Amazon Redshift.
O Amazon Redshift tem cotas que limitam as tabelas de uso para diferentes tipos de nós de cluster. Se você escolher **Auto**, AWS SCT determinará o número de tabelas a serem aplicadas ao seu cluster de destino do Amazon Redshift, dependendo do tipo de nó. Opcionalmente, escolha o valor manualmente. Para obter mais informações, consulte “[Cotas e limites no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*.
AWS SCT converte todas as suas tabelas de origem, mesmo que isso seja mais do que o seu cluster do Amazon Redshift pode armazenar. AWS SCT armazena o código convertido em seu projeto e não o aplica ao banco de dados de destino. Se você atingir a cota de cluster do Amazon Redshift para as tabelas ao aplicar o código convertido, a AWS SCT exibirá uma mensagem de aviso. Além disso, AWS SCT aplica tabelas ao seu cluster de destino do Amazon Redshift até que o número de tabelas atinja o limite.
+ Para migrar partições da tabela de origem para tabelas separadas no Amazon Redshift. Para fazer isso, selecione **Usar a exibição UNION ALL** e insira o número máximo de tabelas de destino que a AWS SCT pode criar para uma única tabela de origem.
O Amazon Redshift não oferece suporte ao particionamento de tabelas. Para emular esse comportamento e acelerar a execução das consultas, AWS SCT você pode migrar cada partição da sua tabela de origem para uma tabela separada no Amazon Redshift. Em seguida, AWS SCT cria uma exibição que inclui dados de todas essas tabelas.
AWS SCT determina automaticamente o número de partições na tabela de origem. Dependendo do tipo de particionamento da tabela de origem, esse número pode exceder a cota das tabelas que você pode aplicar ao seu cluster do Amazon Redshift. Para evitar atingir essa cota, insira o número máximo de tabelas de destino que AWS SCT podem ser criadas para partições de uma única tabela de origem. A opção padrão é 368 tabelas, que representam uma partição para 366 dias do ano e duas tabelas para partições `NO RANGE` e `UNKNOWN`.
+ Para aplicar compactação às colunas da tabela do Amazon Redshift. Para fazer isso, selecione **Usar codificação de compressão**.
AWS SCT atribui a codificação de compactação às colunas automaticamente usando o algoritmo padrão do Amazon Redshift. Para obter mais informações, consulte [Codificações de compactação](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.
Por padrão, o Amazon Redshift não aplica compactação a colunas definidas como chaves de classificação e distribuição. É possível alterar esse comportamento e aplicar compactação a essas colunas. Para fazer isso, selecione **Usar codificação de compactação para colunas KEY**. Você pode selecionar essa opção somente ao selecionar a opção **Usar codificação de compactação**.
## Configurações de otimização de conversão do Azure Synapse Analytics para o Amazon Redshift
**Para editar as configurações de otimização de conversão do Azure Synapse Analytics para o Amazon Redshift, **escolha Configurações em e, AWS SCT em seguida, escolha** Configurações de conversão.** Na lista superior, escolha **Azure Synapse** e, em seguida, escolha **Azure Synapse: Amazon Redshift**. No painel esquerdo, escolha **Estratégias de otimização**. AWS SCT exibe as configurações de otimização de conversão para a conversão do Azure Synapse Analytics para o Amazon Redshift.
As configurações AWS SCT de otimização de conversão do Azure Synapse Analytics para o Amazon Redshift incluem opções para o seguinte:
+ Para trabalhar com otimização automática de tabelas. Para fazer isso, selecione **Usar o ajuste automático da tabela do Amazon Redshift**.
A otimização automática de tabelas é um processo de autoajuste no Amazon Redshift que otimiza automaticamente o design de tabelas. Para obter mais informações, consulte [Como trabalhar com a otimização automática de tabelas](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) no *Guia do desenvolvedor do banco de dados Amazon Redshift*.
Para confiar somente na otimização automática da tabela, escolha **Nenhuma** para a **Estratégia inicial de seleção de chave**.
+ Para escolher chaves de classificação e distribuição usando sua estratégia.
Você pode escolher chaves de classificação e distribuição usando metadados, informações estatísticas ou ambas as opções do Amazon Redshift. Para **Estratégia inicial de seleção de chave** na guia **Estratégias de otimização**, escolha uma das seguintes opções:
+ Use metadados, ignore informações estatísticas
+ Ignore metadados, use informações estatísticas
+ Use metadados e informações estatísticas
Dependendo da opção escolhida, você pode selecionar estratégias de otimização. Em seguida, para cada estratégia, insira o valor (0-100). Esses valores definem o peso de cada estratégia. Usando esses valores de peso, a AWS SCT define como cada regra influencia na escolha das chaves de distribuição e classificação. Os valores padrão são baseados nas melhores práticas de AWS migração.
Você pode definir o tamanho de tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para defini-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
+ Para configurar os detalhes da estratégia.
Além de definir o peso de cada estratégia de otimização, você pode definir as configurações de otimização. Para fazer isso, escolha **Otimização de conversões**.
+ Em **Limite de colunas da chave de classificação**, insira o número máximo de colunas na chave de classificação.
+ Em **Valor limite distorcido**, insira a porcentagem (0—100) de um valor distorcido para uma coluna. AWS SCT exclui colunas com o valor de inclinação maior que o limite da lista de candidatos para a chave de distribuição. AWS SCT define o valor distorcido de uma coluna como a proporção percentual entre o número de ocorrências do valor mais comum e o número total de registros.
+ Para as **N principais consultas da tabela do histórico de consultas**, insira o número (1-100) das consultas usadas com mais frequência para análise.
+ Em **Selecionar usuário de estatísticas**, escolha o usuário do banco de dados para o qual você deseja analisar as estatísticas de consulta.
Além disso, na guia **Estratégias de otimização**, você pode definir o tamanho das tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para considerá-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
# Conectando-se ao Google BigQuery com AWS Schema Conversion Tool
Você pode usar AWS SCT para converter esquemas, objetos de código e código de aplicativo BigQuery para o Amazon Redshift.
## Privilégios BigQuery como fonte
Para usar um BigQuery data warehouse como fonte AWS SCT, crie uma conta de serviço. No Google Cloud, os aplicativos usam contas de serviço para fazer chamadas de API autorizadas. As contas de serviço são diferentes das contas de usuário. Para obter mais informações, consulte [Contas de serviço](https://cloud.google.com/iam/docs/service-accounts) na documentação do Gerenciamento de acesso e identidade do Google Cloud.
Certifique-se de conceder as seguintes funções à sua conta de serviço:
+ `BigQuery Admin`
+ `Storage Admin`
A `BigQuery Admin` função fornece permissões para gerenciar todos os recursos do projeto. AWS SCT usa essa função para carregar seus BigQuery metadados no projeto de migração.
A função `Storage Admin` concede controle total sobre objetos e buckets de dados. Você pode encontrar essa função em`Cloud Storage`. AWS SCT usa essa função para extrair seus dados BigQuery e depois carregá-los no Amazon Redshift.
**Para criar um arquivo de chave da conta de serviço**
1. Faça login no console de gerenciamento do Google Cloud em [https://console.cloud.google.com/](https://console.cloud.google.com/).
1. Na página da [BigQuery API](https://console.cloud.google.com/apis/library/bigquery.googleapis.com), escolha **Ativar**. Ignore esta etapa se você vir a **API ativada**.
1. Na página [Contas de serviço](https://console.cloud.google.com/iam-admin/serviceaccounts), escolha seu projeto e, em seguida, escolha **Criar conta de serviço**.
1. Na página **Detalhes da conta de serviço**, insira um valor descritivo para o **Nome da conta de serviço**. Escolha **Criar e continuar**. A página **Conceder à conta de serviço acesso ao projeto** é aberta.
1. Em **Selecionar uma função**, escolha e **BigQuery**, em seguida, escolha **BigQuery Administrador**.
1. Escolha **Adicionar outra função**. Em **Selecionar uma função**, escolha **Armazenamento na nuvem** e, em seguida, escolha **Storage Admin**.
1. Escolha **Continuar** e, em seguida, escolha **Salvar**.
1. Na página [Contas de serviço](https://console.cloud.google.com/iam-admin/serviceaccounts), escolha a conta de serviço que você criou.
1. Escolha **Chaves** e, em seguida, escolha **Criar nova chave** em **Adicionar chave**.
1. Selecione **JSON** e, em seguida, escolha **Criar**. Escolha a pasta para salvar sua chave privada ou selecione a pasta padrão para downloads em seu navegador.
Para extrair dados de um BigQuery data warehouse, AWS SCT use a pasta bucket do Google Cloud Storage. Crie esse bucket antes de iniciar a migração de dados. Insira o caminho para sua pasta de bucket do Google Cloud Storage na caixa de diálogo **Criar tarefa local**. Para obter mais informações, consulte [Criando, executando e monitorando uma AWS SCT tarefa](agents.md#agents.Tasks).
## Conectando-se BigQuery como fonte
Use o procedimento a seguir para se conectar ao seu BigQuery projeto de origem com AWS Schema Conversion Tool o.
**Para se conectar a um data warehouse de BigQuery origem**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **BigQuery**e, em seguida, escolha **Avançar**.
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para seu BigQuery projeto. AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Em **Caminho da chave**, insira o caminho para o arquivo de chave da conta de serviço. Para obter mais informações sobre a criação desse arquivo, consulte a [Privilégios BigQuery como fonte](#CHAP_Source.BigQuery.Permissions).
1. Escolha **Testar conexão** para verificar se AWS SCT pode se conectar ao seu BigQuery projeto de origem.
1. Escolha **Connect** para se conectar ao seu BigQuery projeto de origem.
## Limitações no uso BigQuery como fonte para AWS SCT
As seguintes limitações se aplicam ao uso BigQuery como fonte para AWS SCT:
+ AWS SCT não suporta a conversão de subconsultas em funções analíticas.
+ Você não pode usar AWS SCT para converter BigQuery `SELECT AS STRUCT` `SELECT AS VALUE` declarações.
+ AWS SCT não suporta a conversão dos seguintes tipos de funções:
+ Agregado aproximado
+ Bit
+ Depuração
+ Consulta federada
+ Geografia
+ Hash
+ Matemáticas
+ Net
+ Agregado estatístico
+ UUID
+ AWS SCT fornece suporte limitado para a conversão de funções de string.
+ AWS SCT não suporta a conversão de `UNNEST` operadores.
+ Você não pode converter operações de junção correlacionadas em AWS SCT.
+ AWS SCT não suporta a conversão de `OFFSET` cláusulas `QUALIFY` `WINDOW``LIMIT`,, e.
+ Você não pode usar AWS SCT para converter expressões de tabela comuns recursivas.
+ AWS SCT não suporta a conversão de `INSERT` declarações com subconsultas dentro `VALUES` de cláusulas.
+ AWS SCT não suporta a conversão de `UPDATE` declarações para campos aninhados e registros repetidos.
+ Você não pode usar AWS SCT para converter `STRUCT` nem tipos de `ARRAY` dados.
## BigQuery para as configurações de conversão do Amazon Redshift
BigQuery Para editar as configurações de conversão do Amazon Redshift, escolha **Configurações** em e, em seguida AWS SCT, escolha Configurações **de conversão**. Na lista superior, escolha **Google** e BigQuery, em seguida, escolha **Google BigQuery — Amazon Redshift**. AWS SCT exibe todas as configurações disponíveis para conversão BigQuery para o Amazon Redshift.
BigQuery para as configurações de conversão do Amazon Redshift em AWS SCT Inclua opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para definir o número máximo de tabelas que AWS SCT podem ser aplicadas ao seu cluster de destino do Amazon Redshift.
Em **O número máximo de tabelas para o cluster de destino do Amazon Redshift**, escolha o número de tabelas que AWS SCT podem ser aplicadas ao seu cluster do Amazon Redshift.
O Amazon Redshift tem cotas que limitam as tabelas de uso para diferentes tipos de nós de cluster. Se você escolher **Auto**, AWS SCT determinará o número de tabelas a serem aplicadas ao seu cluster de destino do Amazon Redshift, dependendo do tipo de nó. Opcionalmente, escolha o valor manualmente. Para obter mais informações, consulte “[Cotas e limites no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*.
AWS SCT converte todas as suas tabelas de origem, mesmo que isso seja mais do que o seu cluster do Amazon Redshift pode armazenar. AWS SCT armazena o código convertido em seu projeto e não o aplica ao banco de dados de destino. Se você atingir a cota de cluster do Amazon Redshift para as tabelas ao aplicar o código convertido, a AWS SCT exibirá uma mensagem de aviso. Além disso, AWS SCT aplica tabelas ao seu cluster de destino do Amazon Redshift até que o número de tabelas atinja o limite.
+ Para aplicar compactação às colunas da tabela do Amazon Redshift. Para fazer isso, selecione **Usar codificação de compressão**.
AWS SCT atribui a codificação de compactação às colunas automaticamente usando o algoritmo padrão do Amazon Redshift. Para obter mais informações, consulte [Codificações de compactação](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.
Por padrão, o Amazon Redshift não aplica compactação a colunas definidas como chaves de classificação e distribuição. É possível alterar esse comportamento e aplicar compactação a essas colunas. Para fazer isso, selecione **Usar codificação de compactação para colunas KEY**. Você pode selecionar essa opção somente ao selecionar a opção **Usar codificação de compactação**.
## BigQuery para as configurações de otimização de conversão do Amazon Redshift
BigQuery Para editar as configurações de otimização de conversão do Amazon Redshift, escolha **Configurações** em e AWS SCT, em seguida, escolha Configurações **de conversão**. Na lista superior, escolha **Google** e BigQuery, em seguida, escolha **Google BigQuery — Amazon Redshift**. No painel esquerdo, escolha **Estratégias de otimização**. AWS SCT exibe as configurações de otimização de conversão para BigQuery a conversão para o Amazon Redshift.
BigQuery para as configurações de otimização de conversão do Amazon Redshift, AWS SCT inclua opções para o seguinte:
+ Para trabalhar com otimização automática de tabelas. Para fazer isso, selecione **Usar o ajuste automático da tabela do Amazon Redshift**.
A otimização automática de tabelas é um processo de autoajuste no Amazon Redshift que otimiza automaticamente o design de tabelas. Para obter mais informações, consulte [Como trabalhar com a otimização automática de tabelas](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) no *Guia do desenvolvedor do banco de dados Amazon Redshift*.
Para confiar somente na otimização automática da tabela, escolha **Nenhuma** para a **Estratégia inicial de seleção de chave**.
+ Para escolher chaves de classificação e distribuição usando sua estratégia.
Você pode escolher chaves de classificação e distribuição usando metadados, informações estatísticas ou ambas as opções do Amazon Redshift. Para **Estratégia inicial de seleção de chave** na guia **Estratégias de otimização**, escolha uma das seguintes opções:
+ Use metadados, ignore informações estatísticas
+ Ignore metadados, use informações estatísticas
+ Use metadados e informações estatísticas
Dependendo da opção escolhida, você pode selecionar estratégias de otimização. Em seguida, para cada estratégia, insira o valor (0-100). Esses valores definem o peso de cada estratégia. Usando esses valores de peso, a AWS SCT define como cada regra influencia na escolha das chaves de distribuição e classificação. Os valores padrão são baseados nas melhores práticas de AWS migração.
Você pode definir o tamanho de tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para defini-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
+ Para configurar os detalhes da estratégia.
Além de definir o peso de cada estratégia de otimização, você pode definir as configurações de otimização. Para fazer isso, escolha **Otimização de conversões**.
+ Em **Limite de colunas da chave de classificação**, insira o número máximo de colunas na chave de classificação.
+ Em **Valor limite distorcido**, insira a porcentagem (0—100) de um valor distorcido para uma coluna. AWS SCT exclui colunas com o valor de inclinação maior que o limite da lista de candidatos para a chave de distribuição. AWS SCT define o valor distorcido de uma coluna como a proporção percentual entre o número de ocorrências do valor mais comum e o número total de registros.
+ Para as **N principais consultas da tabela do histórico de consultas**, insira o número (1-100) das consultas usadas com mais frequência para análise.
+ Em **Selecionar usuário de estatísticas**, escolha o usuário do banco de dados para o qual você deseja analisar as estatísticas de consulta.
Além disso, na guia **Estratégias de otimização**, você pode definir o tamanho das tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para considerá-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
# Conectando o banco de dados Greenplum com AWS Schema Conversion Tool
Você pode usar AWS SCT para converter esquemas, objetos de código e código de aplicativo do Greenplum Database para o Amazon Redshift.
## Privilégios do banco de dados Greenplum como origem
Os privilégios obrigatórios para o banco de dados Greenplum como origem são listados a seguir:
+ CONECTE-SE AO BANCO DE DADOS **
+ USO NO ESQUEMA **
+ SELECIONE ATIVADO *.*
+ SELECIONE NA SEQUÊNCIA *.*
No exemplo anterior, substitua os espaços reservados conforme a seguir:
+ Substitua *database\$1name* pelo nome do banco de dados de origem.
+ Substitua *schema\$1name* pelo nome do esquema de origem.
+ *table\$1name*Substitua pelo nome da tabela de origem.
+ *sequence\$1name*Substitua pelo nome do nome da sequência.
## Como se conectar ao banco de dados Greenplum como origem
Use o procedimento a seguir para se conectar ao seu banco de dados de origem do Greenplum com. AWS SCT
**Para conectar-se a um banco de dados de origem do Greenplum**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **SAP ASE** e, em seguida, escolha **Avançar**.
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para o banco de dados. A AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Use as credenciais do banco de dados AWS Secrets Manager ou insira-as manualmente:
+ Para usar as credenciais do banco de dados do Secrets Manager, use as instruções a seguir:
1. Em **Segredo da AWS **, escolha o nome do seu segredo.
1. Escolha **Preencher** para preencher automaticamente todos os valores na caixa de diálogo de conexão do banco de dados do Secrets Manager.
Para obter informações sobre o uso de credenciais de banco de dados do Secrets Manager, consulte a [Configurando AWS Secrets Manager no AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Para inserir as credenciais do banco de dados do Greenplum de origem manualmente, use as instruções a seguir:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.Greenplum.html)
1. Escolha **Testar conexão** para verificar se AWS SCT pode se conectar ao seu banco de dados de origem.
1. Escolha **Conectar** para se conectar ao banco de dados de origem.
## Configurações de conversão do Greenplum para o Amazon Redshift
**Para editar as configurações de conversão do Greenplum para o Amazon Redshift, escolha Configurações em e, AWS SCT em seguida, **escolha** Configurações de conversão.** Na lista superior, escolha **Greenplum** e, em seguida, escolha **Greenplum — Amazon Redshift**. AWS SCT exibe todas as configurações disponíveis para a conversão do Greenplum para o Amazon Redshift.
As configurações AWS SCT de conversão do Greenplum para o Amazon Redshift incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para definir o número máximo de tabelas que AWS SCT podem ser aplicadas ao seu cluster de destino do Amazon Redshift.
Em **O número máximo de tabelas para o cluster de destino do Amazon Redshift**, escolha o número de tabelas que AWS SCT podem ser aplicadas ao seu cluster do Amazon Redshift.
O Amazon Redshift tem cotas que limitam as tabelas de uso para diferentes tipos de nós de cluster. Se você escolher **Auto**, AWS SCT determinará o número de tabelas a serem aplicadas ao seu cluster de destino do Amazon Redshift, dependendo do tipo de nó. Opcionalmente, escolha o valor manualmente. Para obter mais informações, consulte “[Cotas e limites no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*.
AWS SCT converte todas as suas tabelas de origem, mesmo que isso seja mais do que o seu cluster do Amazon Redshift pode armazenar. AWS SCT armazena o código convertido em seu projeto e não o aplica ao banco de dados de destino. Se você atingir a cota de cluster do Amazon Redshift para as tabelas ao aplicar o código convertido, a AWS SCT exibirá uma mensagem de aviso. Além disso, AWS SCT aplica tabelas ao seu cluster de destino do Amazon Redshift até que o número de tabelas atinja o limite.
+ Para migrar partições da tabela de origem para tabelas separadas no Amazon Redshift. Para fazer isso, selecione **Usar a exibição UNION ALL** e insira o número máximo de tabelas de destino que a AWS SCT pode criar para uma única tabela de origem.
O Amazon Redshift não oferece suporte ao particionamento de tabelas. Para emular esse comportamento e acelerar a execução das consultas, AWS SCT você pode migrar cada partição da sua tabela de origem para uma tabela separada no Amazon Redshift. Em seguida, AWS SCT cria uma exibição que inclui dados de todas essas tabelas.
AWS SCT determina automaticamente o número de partições na tabela de origem. Dependendo do tipo de particionamento da tabela de origem, esse número pode exceder a cota das tabelas que você pode aplicar ao seu cluster do Amazon Redshift. Para evitar atingir essa cota, insira o número máximo de tabelas de destino que AWS SCT podem ser criadas para partições de uma única tabela de origem. A opção padrão é 368 tabelas, que representam uma partição para 366 dias do ano e duas tabelas para partições `NO RANGE` e `UNKNOWN`.
+ Para aplicar compactação às colunas da tabela do Amazon Redshift. Para fazer isso, selecione **Usar codificação de compressão**.
AWS SCT atribui a codificação de compactação às colunas automaticamente usando o algoritmo padrão do Amazon Redshift. Para obter mais informações, consulte [Codificações de compactação](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.
Por padrão, o Amazon Redshift não aplica compactação a colunas definidas como chaves de classificação e distribuição. É possível alterar esse comportamento e aplicar compactação a essas colunas. Para fazer isso, selecione **Usar codificação de compactação para colunas KEY**. Você pode selecionar essa opção somente ao selecionar a opção **Usar codificação de compactação**.
## Configurações de otimização de conversão do Greenplum para o Amazon Redshift
**Para editar as configurações de otimização de conversão do Greenplum para o Amazon Redshift, escolha Configurações em e, AWS SCT em seguida, **escolha** Configurações de conversão.** Na lista superior, escolha **Greenplum** e, em seguida, escolha **Greenplum: Amazon Redshift**. No painel esquerdo, escolha **Estratégias de otimização**. AWS SCT exibe as configurações de otimização de conversão da Greenplum para a conversão do Amazon Redshift.
As configurações AWS SCT de otimização de conversão do Greenplum para o Amazon Redshift incluem opções para o seguinte:
+ Para trabalhar com otimização automática de tabelas. Para fazer isso, selecione **Usar o ajuste automático da tabela do Amazon Redshift**.
A otimização automática de tabelas é um processo de autoajuste no Amazon Redshift que otimiza automaticamente o design de tabelas. Para obter mais informações, consulte [Como trabalhar com a otimização automática de tabelas](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) no *Guia do desenvolvedor do banco de dados Amazon Redshift*.
Para confiar somente na otimização automática da tabela, escolha **Nenhuma** para a **Estratégia inicial de seleção de chave**.
+ Para escolher chaves de classificação e distribuição usando sua estratégia.
Você pode escolher chaves de classificação e distribuição usando metadados, informações estatísticas ou ambas as opções do Amazon Redshift. Para **Estratégia inicial de seleção de chave** na guia **Estratégias de otimização**, escolha uma das seguintes opções:
+ Use metadados, ignore informações estatísticas
+ Ignore metadados, use informações estatísticas
+ Use metadados e informações estatísticas
Dependendo da opção escolhida, você pode selecionar estratégias de otimização. Em seguida, para cada estratégia, insira o valor (0-100). Esses valores definem o peso de cada estratégia. Usando esses valores de peso, a AWS SCT define como cada regra influencia na escolha das chaves de distribuição e classificação. Os valores padrão são baseados nas melhores práticas de AWS migração.
Você pode definir o tamanho de tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para defini-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
+ Para configurar os detalhes da estratégia.
Além de definir o peso de cada estratégia de otimização, você pode definir as configurações de otimização. Para fazer isso, escolha **Otimização de conversões**.
+ Em **Limite de colunas da chave de classificação**, insira o número máximo de colunas na chave de classificação.
+ Em **Valor limite distorcido**, insira a porcentagem (0—100) de um valor distorcido para uma coluna. AWS SCT exclui colunas com o valor de inclinação maior que o limite da lista de candidatos para a chave de distribuição. AWS SCT define o valor distorcido de uma coluna como a proporção percentual entre o número de ocorrências do valor mais comum e o número total de registros.
+ Para as **N principais consultas da tabela do histórico de consultas**, insira o número (1-100) das consultas usadas com mais frequência para análise.
+ Em **Selecionar usuário de estatísticas**, escolha o usuário do banco de dados para o qual você deseja analisar as estatísticas de consulta.
Além disso, na guia **Estratégias de otimização**, você pode definir o tamanho das tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para considerá-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
# Conectando-se ao Netezza com AWS Schema Conversion Tool
Você pode usar AWS SCT para converter esquemas, objetos de código e código de aplicativo do Netezza para o Amazon Redshift.
## Privilégios do Netezza como origem
Os privilégios obrigatórios para Netezza como origem são listados a seguir:
+ select on system.definition\$1schema.system view
+ select on system.definition\$1schema.system table
+ select on system.definition\$1schema.management table
+ lista em **
+ lista em **
+ lista em ** .all.table
+ lista na ** tabela.all.external
+ lista em ** .all.view
+ lista na visualização ** .all.materialized
+ lista em ** .all.procedure
+ lista em ** .all.sequence
+ lista em ** .all.function
+ lista em ** .all.aggregate
No exemplo anterior, substitua os espaços reservados conforme a seguir:
+ Substitua *database\$1name* pelo nome do banco de dados de origem.
+ Substitua *schema\$1name* pelo nome do esquema de origem.
AWS SCT requer acesso às seguintes tabelas e visualizações do sistema. Você pode conceder acesso a esses objetos em vez de conceder acesso à `system.definition_schema.system view` e `system.definition_schema.system tables` na lista anterior.
+ select on system.definition\$1schema.\$1t\$1aggregate
+ select on system.definition\$1schema.\$1t\$1class
+ select on system.definition\$1schema.\$1t\$1constraint
+ select on system.definition\$1schema.\$1t\$1const\$1relattr
+ select on system.definition\$1schema.\$1t\$1database
+ select on system.definition\$1schema.\$1t\$1grpobj\$1priv
+ select on system.definition\$1schema.\$1t\$1grpusr
+ select on system.definition\$1schema.\$1t\$1hist\$1config
+ select on system.definition\$1schema.\$1t\$1object
+ select on system.definition\$1schema.\$1t\$1object\$1classes
+ select on system.definition\$1schema.\$1t\$1proc
+ select on system.definition\$1schema.\$1t\$1type
+ select on system.definition\$1schema.\$1t\$1user
+ select on system.definition\$1schema.\$1t\$1usrobj\$1priv
+ select on system.definition\$1schema.\$1vt\$1sequence
+ select on system.definition\$1schema.\$1v\$1aggregate
+ select on system.definition\$1schema.\$1v\$1constraint\$1depends
+ select on system.definition\$1schema.\$1v\$1database
+ select on system.definition\$1schema.\$1v\$1datatype
+ select on system.definition\$1schema.\$1v\$1dslice
+ select on system.definition\$1schema.\$1v\$1function
+ select on system.definition\$1schema.\$1v\$1group
+ select on system.definition\$1schema.\$1v\$1obj\$1relation
+ select on system.definition\$1schema.\$1v\$1obj\$1relation\$1xdb
+ select on system.definition\$1schema.\$1v\$1procedure
+ select on system.definition\$1schema.\$1v\$1relation\$1column
+ select on system.definition\$1schema.\$1v\$1relation\$1keydata
+ select on system.definition\$1schema.\$1v\$1relobjclasses
+ select on system.definition\$1schema.\$1v\$1schema\$1xdb
+ select on system.definition\$1schema.\$1v\$1sequence
+ select on system.definition\$1schema.\$1v\$1synonym
+ select on system.definition\$1schema.\$1v\$1system\$1info
+ select on system.definition\$1schema.\$1v\$1sys\$1constraint
+ select on system.definition\$1schema.\$1v\$1sys\$1object\$1dslice\$1info
+ select on system.definition\$1schema.\$1v\$1sys\$1user
+ select on system.definition\$1schema.\$1v\$1table
+ select on system.definition\$1schema.\$1v\$1table\$1constraint
+ select on system.definition\$1schema.\$1v\$1table\$1dist\$1map
+ select on system.definition\$1schema.\$1v\$1table\$1organize\$1column
+ select on system.definition\$1schema.\$1v\$1table\$1storage\$1stat
+ select on system.definition\$1schema.\$1v\$1user
+ select on system.definition\$1schema.\$1v\$1view
+ select on system.information\$1schema.\$1v\$1relation\$1column
+ select on system.information\$1schema.\$1v\$1table
+ select on \$1hist\$1column\$1access\$1\$1
## Conectando-se ao Netezza como origem
Use o procedimento a seguir para conectar seu banco de dados de origem do Netezza com a AWS Schema Conversion Tool.
**Para se conectar a um banco de dados de origem do Netezza**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **Netezza** e, em seguida, escolha **Avançar**.
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para o banco de dados. A AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Use as credenciais do banco de dados AWS Secrets Manager ou insira-as manualmente:
+ Para usar as credenciais do banco de dados do Secrets Manager, use as instruções a seguir:
1. Em **Segredo da AWS **, escolha o nome do seu segredo.
1. Escolha **Preencher** para preencher automaticamente todos os valores na caixa de diálogo de conexão do banco de dados do Secrets Manager.
Para obter informações sobre o uso de credenciais de banco de dados do Secrets Manager, consulte a [Configurando AWS Secrets Manager no AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Para inserir manualmente as informações de conexão do banco de dados do Netezza de origem, use as instruções a seguir:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.Netezza.html)
1. Escolha **Testar conexão** para verificar se AWS SCT pode se conectar ao seu banco de dados de origem.
1. Escolha **Conectar** para se conectar ao banco de dados de origem.
## Como configurar a replicação contínua de dados
Depois de converter seus esquemas de banco de dados Netezza e aplicá-los ao seu banco de dados do Amazon Redshift, você pode migrar dados com agentes de extração de dados. AWS SCT O agente extrai seus dados e os carrega no bucket do Amazon S3. Em seguida, você pode usar AWS SCT para copiar os dados do Amazon S3 para o Amazon Redshift.
Se os dados em seu banco de dados de origem mudarem durante o processo de migração, você poderá capturar as alterações contínuas com seus agentes de extração de AWS SCT dados. Em seguida, você pode replicar essas alterações contínuas em seu banco de dados de destino depois de concluir a migração inicial de dados. Esse processo é chamado de replicação contínua de dados ou *captura de dados de alteração* (CDC).
**Para configurar a replicação contínua de dados para migrações do Netezza para o Amazon Redshift**
1. Em seu banco de dados de origem, crie um banco de dados de histórico. É possível usar o exemplo de código a seguir na interface de linha de comandos (CLI) do Netezza.
```
nzhistcreatedb -d history_database_name -t query -v 1 -u load_user -o histdb_owner -p your_password
```
No exemplo anterior, *history\$1database\$1name* substitua pelo nome do seu banco de dados de histórico. Em seguida, *load\$1user* substitua pelo nome do usuário que você definiu para carregar os dados do histórico no banco de dados. Em seguida, *histdb\$1owner* substitua pelo nome do usuário que você definiu como proprietário do banco de dados de histórico. Verifique se você já criou esse usuário e concedeu a permissão `CREATE DATABASE`. Por fim, *your\$1password* substitua por uma senha segura.
1. Configure o registro do histórico. Para fazer isso, use o exemplo de código a seguir:
```
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;
```
No exemplo anterior, substitua *history\$1configuration\$1name* e *history\$1database\$1name* pelos nomes da configuração do histórico e do banco de dados do histórico. Em seguida, *load\$1user* substitua pelo nome do usuário que você definiu para carregar os dados do histórico no banco de dados. Em seguida, *your\$1password* substitua por uma senha segura.
1. Conceda permissões de leitura para todas as tabelas no banco de dados do histórico. Você pode usar o exemplo de código a seguir para conceder a permissão `SELECT`.
```
GRANT SELECT ON history_database_name.ALL.TABLE TO your_user;
```
No exemplo anterior, *history\$1database\$1name* substitua pelo nome do seu banco de dados de histórico. Em seguida, *your\$1user* substitua pelo nome do usuário com permissões mínimas para trabalhar com seu banco de dados Netezza. Você usa as credenciais desse usuário do banco de dados em AWS SCT.
1. Colete estatísticas para cada tabela em seu esquema de origem para obter as informações sobre a cardinalidade das colunas. É possível usar o seguinte comando para gerar estatísticas em seu banco de dados de histórico.
```
GENERATE STATISTICS on "schema_name"."table_name";
```
No exemplo anterior, substitua *schema\$1name* e *table\$1name* pelo nome do esquema e da tabela do banco de dados.
1. Atenda aos pré-requisitos executando a seguinte consulta:
```
SELECT COUNT(*) FROM history_database_name.history_schema_name."$hist_column_access_N";
```
No exemplo anterior, substitua *history\$1database\$1name* e *history\$1schema\$1name* pelo nome do seu banco de dados de histórico e esquema. Em seguida, *N* substitua pelo número da versão do seu banco de dados de histórico. Para obter mais informações sobre as versões do banco de dados de histórico, consulte a [Documentação do IBM Netezza](https://www.ibm.com/docs/en/netezza?topic=history-database-versions).
1. Instale seus agentes de extração de dados. Para obter mais informações, consulte [Como instalar atendentes de extração](agents.md#agents.Installing).
Certifique-se de que o parâmetro `{working.folder}` no arquivo `settings.properties` para todas as instâncias do extrator aponte para a mesma pasta. Nesse caso, seus extratores podem coordenar a sessão da CDC e usar um único ponto de transação para todas as subtarefas.
1. Registre seu agente de extração de dados. Para obter mais informações, consulte [Registrando agentes de extração com o AWS Schema Conversion Tool](agents.md#agents.Using).
1. Crie sua tarefa da CDC. Para obter mais informações, consulte [Criando, executando e monitorando uma AWS SCT tarefa](agents.md#agents.Tasks).
1. Abra seu projeto em AWS SCT. No painel esquerdo, escolha sua tabela de origem. Abra o menu de contexto (clique com o botão direito do mouse) do objeto e escolha **Criar tarefa local**.
1. Em **Nome da tarefa**, insira um nome descritivo para a tarefa de migração de dados.
1. Para o **Modo de migração**, escolha **Extrair, carregar e copiar**.
1. Selecione **Habilitar CDC**.
1. Escolha a guia **Configurações da CDC** e defina o escopo e a programação das sessões da CDC.
1. Selecione **Testar tarefa** para verificar se você pode se conectar à sua pasta de trabalho, bucket do Amazon S3 e data warehouse do Amazon Redshift.
1. Escolha **Criar** para criar sua tarefa.
1. Escolha a guia **Tarefas**, escolha sua tarefa na lista e escolha **Iniciar**.
1. A AWS SCT tarefa mantém a consistência transacional no banco de dados de destino. O agente de extração de dados replica as transações da origem na ordem do ID da transação.
Se você interromper qualquer uma das sessões de migração ou se ela falhar, o processamento da CDC também será interrompido.
## Configurações de conversão do Netezza para o Amazon Redshift
**Para editar as configurações de conversão do Netezza para o Amazon Redshift, escolha Configurações em e, AWS SCT em seguida, **escolha** Configurações de conversão.** Na lista superior, escolha **Netezza** e, em seguida, escolha **Netezza — Amazon** Redshift. AWS SCT exibe todas as configurações disponíveis para conversão de Netezza para Amazon Redshift.
As configurações AWS SCT de conversão do Netezza para o Amazon Redshift incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para definir o número máximo de tabelas que AWS SCT podem ser aplicadas ao seu cluster de destino do Amazon Redshift.
Em **O número máximo de tabelas para o cluster de destino do Amazon Redshift**, escolha o número de tabelas que AWS SCT podem ser aplicadas ao seu cluster do Amazon Redshift.
O Amazon Redshift tem cotas que limitam as tabelas de uso para diferentes tipos de nós de cluster. Se você escolher **Auto**, AWS SCT determinará o número de tabelas a serem aplicadas ao seu cluster de destino do Amazon Redshift, dependendo do tipo de nó. Opcionalmente, escolha o valor manualmente. Para obter mais informações, consulte “[Cotas e limites no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*.
AWS SCT converte todas as suas tabelas de origem, mesmo que isso seja mais do que o seu cluster do Amazon Redshift pode armazenar. AWS SCT armazena o código convertido em seu projeto e não o aplica ao banco de dados de destino. Se você atingir a cota de cluster do Amazon Redshift para as tabelas ao aplicar o código convertido, a AWS SCT exibirá uma mensagem de aviso. Além disso, AWS SCT aplica tabelas ao seu cluster de destino do Amazon Redshift até que o número de tabelas atinja o limite.
+ Para aplicar compactação às colunas da tabela do Amazon Redshift. Para fazer isso, selecione **Usar codificação de compressão**.
AWS SCT atribui a codificação de compactação às colunas automaticamente usando o algoritmo padrão do Amazon Redshift. Para obter mais informações, consulte [Codificações de compactação](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.
Por padrão, o Amazon Redshift não aplica compactação a colunas definidas como chaves de classificação e distribuição. É possível alterar esse comportamento e aplicar compactação a essas colunas. Para fazer isso, selecione **Usar codificação de compactação para colunas KEY**. Você pode selecionar essa opção somente ao selecionar a opção **Usar codificação de compactação**.
## Configurações de otimização de conversão do Netezza para o Amazon Redshift
**Para editar as configurações de otimização de conversão do Netezza para o Amazon Redshift, escolha Configurações em e, AWS SCT em seguida, **escolha** Configurações de conversão.** Na lista superior, escolha **Netezza** e, em seguida, escolha **Netezza: Amazon Redshift**. No painel esquerdo, escolha **Estratégias de otimização**. AWS SCT exibe as configurações de otimização de conversão para a conversão do Netezza para o Amazon Redshift.
As configurações AWS SCT de otimização de conversão do Netezza para o Amazon Redshift incluem opções para o seguinte:
+ Para trabalhar com otimização automática de tabelas. Para fazer isso, selecione **Usar o ajuste automático da tabela do Amazon Redshift**.
A otimização automática de tabelas é um processo de autoajuste no Amazon Redshift que otimiza automaticamente o design de tabelas. Para obter mais informações, consulte [Como trabalhar com a otimização automática de tabelas](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) no *Guia do desenvolvedor do banco de dados Amazon Redshift*.
Para confiar somente na otimização automática da tabela, escolha **Nenhuma** para a **Estratégia inicial de seleção de chave**.
+ Para escolher chaves de classificação e distribuição usando sua estratégia.
Você pode escolher chaves de classificação e distribuição usando metadados, informações estatísticas ou ambas as opções do Amazon Redshift. Para **Estratégia inicial de seleção de chave** na guia **Estratégias de otimização**, escolha uma das seguintes opções:
+ Use metadados, ignore informações estatísticas
+ Ignore metadados, use informações estatísticas
+ Use metadados e informações estatísticas
Dependendo da opção escolhida, você pode selecionar estratégias de otimização. Em seguida, para cada estratégia, insira o valor (0-100). Esses valores definem o peso de cada estratégia. Usando esses valores de peso, a AWS SCT define como cada regra influencia na escolha das chaves de distribuição e classificação. Os valores padrão são baseados nas melhores práticas de AWS migração.
Você pode definir o tamanho de tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para defini-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
+ Para configurar os detalhes da estratégia.
Além de definir o peso de cada estratégia de otimização, você pode definir as configurações de otimização. Para fazer isso, escolha **Otimização de conversões**.
+ Em **Limite de colunas da chave de classificação**, insira o número máximo de colunas na chave de classificação.
+ Em **Valor limite distorcido**, insira a porcentagem (0—100) de um valor distorcido para uma coluna. AWS SCT exclui colunas com o valor de inclinação maior que o limite da lista de candidatos para a chave de distribuição. AWS SCT define o valor distorcido de uma coluna como a proporção percentual entre o número de ocorrências do valor mais comum e o número total de registros.
+ Para as **N principais consultas da tabela do histórico de consultas**, insira o número (1-100) das consultas usadas com mais frequência para análise.
+ Em **Selecionar usuário de estatísticas**, escolha o usuário do banco de dados para o qual você deseja analisar as estatísticas de consulta.
Além disso, na guia **Estratégias de otimização**, você pode definir o tamanho das tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para considerá-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
# Conectando o Oracle Data Warehouse com AWS SCT
Você pode usar AWS SCT para converter esquemas, objetos de código e código de aplicativo do Oracle Data Warehouse para o Amazon Redshift ou o Amazon Redshift e usá-los em combinação AWS Glue .
## Privilégios do data warehouse do Oracle como origem
Os privilégios obrigatórios para data warehouse do Oracle como origem são listados a seguir:
+ connect
+ select\$1catalog\$1role
+ select any dictionary
## Conectando-se a um data warehouse Oracle de origem
Use o procedimento a seguir para se conectar ao banco de dados de origem do data warehouse do Oracle com a AWS Schema Conversion Tool.
**Para se conectar a um banco de dados de origem do data warehouse do Oracle**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **Oracle** e, em seguida, escolha **Avançar**.
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para o banco de dados. A AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Use as credenciais do banco de dados AWS Secrets Manager ou insira-as manualmente:
+ Para usar as credenciais do banco de dados do Secrets Manager, use as instruções a seguir:
1. Em **Segredo da AWS **, escolha o nome do seu segredo.
1. Escolha **Preencher** para preencher automaticamente todos os valores na caixa de diálogo de conexão do banco de dados do Secrets Manager.
Para obter informações sobre o uso de credenciais de banco de dados do Secrets Manager, consulte a [Configurando AWS Secrets Manager no AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Para inserir manualmente as informações de conexão do data warehouse do Oracle de origem, use as instruções a seguir:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.OracleDW.html)
1. Escolha **Testar conexão** para verificar se AWS SCT pode se conectar ao seu banco de dados de origem.
1. Escolha **Conectar** para se conectar ao banco de dados de origem.
## Configurações de conversão do data warehouse Oracle para o Amazon Redshift
Para editar as configurações de conversão do Oracle Data Warehouse para o Amazon Redshift, escolha **Configurações** em e AWS SCT, em seguida, escolha Configurações **de conversão**. Na lista superior, escolha **Oracle** e, em seguida, escolha **Oracle — Amazon Redshift**. AWS SCT exibe todas as configurações disponíveis para conversão do Oracle Data Warehouse para o Amazon Redshift.
As configurações de conversão do Oracle Data Warehouse para o Amazon Redshift AWS SCT incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para definir o número máximo de tabelas que AWS SCT podem ser aplicadas ao seu cluster de destino do Amazon Redshift.
Em **O número máximo de tabelas para o cluster de destino do Amazon Redshift**, escolha o número de tabelas que AWS SCT podem ser aplicadas ao seu cluster do Amazon Redshift.
O Amazon Redshift tem cotas que limitam as tabelas de uso para diferentes tipos de nós de cluster. Se você escolher **Auto**, AWS SCT determinará o número de tabelas a serem aplicadas ao seu cluster de destino do Amazon Redshift, dependendo do tipo de nó. Opcionalmente, escolha o valor manualmente. Para obter mais informações, consulte “[Cotas e limites no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*.
AWS SCT converte todas as suas tabelas de origem, mesmo que isso seja mais do que o seu cluster do Amazon Redshift pode armazenar. AWS SCT armazena o código convertido em seu projeto e não o aplica ao banco de dados de destino. Se você atingir a cota de cluster do Amazon Redshift para as tabelas ao aplicar o código convertido, a AWS SCT exibirá uma mensagem de aviso. Além disso, AWS SCT aplica tabelas ao seu cluster de destino do Amazon Redshift até que o número de tabelas atinja o limite.
+ Para migrar partições da tabela de origem para tabelas separadas no Amazon Redshift. Para fazer isso, selecione **Usar a exibição UNION ALL** e insira o número máximo de tabelas de destino que a AWS SCT pode criar para uma única tabela de origem.
O Amazon Redshift não oferece suporte ao particionamento de tabelas. Para emular esse comportamento e acelerar a execução das consultas, AWS SCT você pode migrar cada partição da sua tabela de origem para uma tabela separada no Amazon Redshift. Em seguida, AWS SCT cria uma exibição que inclui dados de todas essas tabelas.
AWS SCT determina automaticamente o número de partições na tabela de origem. Dependendo do tipo de particionamento da tabela de origem, esse número pode exceder a cota das tabelas que você pode aplicar ao seu cluster do Amazon Redshift. Para evitar atingir essa cota, insira o número máximo de tabelas de destino que AWS SCT podem ser criadas para partições de uma única tabela de origem. A opção padrão é 368 tabelas, que representam uma partição para 366 dias do ano e duas tabelas para partições `NO RANGE` e `UNKNOWN`.
+ Para converter as funções de formatação de tipo de dados como `TO_CHAR`, `TO_DATE` e `TO_NUMBER` com elementos de formato de data e hora que o Amazon Redshift não suporta. Por padrão, a AWS SCT usa as funções do pacote de extensão para emular o uso desses elementos de formato não suportados no código convertido.
O modelo de formato de data e hora no Oracle inclui mais elementos em comparação com strings de formato de data e hora no Amazon Redshift. Quando seu código-fonte inclui somente elementos de formato de data e hora compatíveis com o Amazon Redshift, você não precisa das funções do pacote de extensões no código convertido. Para evitar o uso das funções do pacote de extensões no código convertido, selecione **Elementos do formato Datetype que você usa no código Oracle são semelhantes às strings de formato de data e hora no Amazon Redshift**. Nesse caso, o código convertido funciona mais rápido.
O modelo de formato numérico no Oracle inclui mais elementos em comparação com strings de formato numérico no Amazon Redshift. Quando seu código-fonte inclui somente elementos de formato numérico compatíveis com o Amazon Redshift, você não precisa das funções do pacote de extensões no código convertido. Para evitar o uso das funções do pacote de extensões no código convertido, selecione **Elementos de formato numérico que você usa no código Oracle são semelhantes às strings de formato numérico no Amazon Redshift**. Nesse caso, o código convertido funciona mais rápido.
+ Para converter funções analíticas `LEAD` e `LAG` do Oracle. Por padrão, a AWS SCT gera um item de ação para cada função `LEAD` e `LAG`.
Quando seu código-fonte não usa os valores padrão para offset nessas funções, a AWS SCT pode emular o uso dessas funções com a função `NVL`. Para fazer isso, selecione **Usar a função NVL para emular o comportamento das funções LEAD e LAG do Oracle**.
+ Para emular o comportamento das chaves primárias e exclusivas em seu cluster do Amazon Redshift, selecione **Emular o comportamento das chaves primárias e exclusivas**.
O Amazon Redshift não impõe chaves exclusivas e primárias e as usa apenas para fins informativos. Se você usar essas restrições em seu código, certifique-se de que AWS SCT emula o comportamento delas no código convertido.
+ Para aplicar compactação às colunas da tabela do Amazon Redshift. Para fazer isso, selecione **Usar codificação de compressão**.
AWS SCT atribui a codificação de compactação às colunas automaticamente usando o algoritmo padrão do Amazon Redshift. Para obter mais informações, consulte [Codificações de compactação](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.
Por padrão, o Amazon Redshift não aplica compactação a colunas definidas como chaves de classificação e distribuição. É possível alterar esse comportamento e aplicar compactação a essas colunas. Para fazer isso, selecione **Usar codificação de compactação para colunas KEY**. Você pode selecionar essa opção somente ao selecionar a opção **Usar codificação de compactação**.
## Configurações de otimização de conversão do data warehouse Oracle para o Amazon Redshift
Para editar as configurações de otimização de conversão do Oracle Data Warehouse para o Amazon Redshift, escolha **Configurações** em e AWS SCT, em seguida, escolha Configurações **de conversão**. Na lista superior, escolha **Oracle** e, em seguida, escolha **Oracle: Amazon Redshift**. No painel esquerdo, escolha **Estratégias de otimização**. AWS SCT exibe as configurações de otimização de conversão para conversão do Oracle Data Warehouse para o Amazon Redshift.
As configurações de otimização de conversão do Oracle Data Warehouse para o Amazon Redshift AWS SCT incluem opções para o seguinte:
+ Para trabalhar com otimização automática de tabelas. Para fazer isso, selecione **Usar o ajuste automático da tabela do Amazon Redshift**.
A otimização automática de tabelas é um processo de autoajuste no Amazon Redshift que otimiza automaticamente o design de tabelas. Para obter mais informações, consulte [Como trabalhar com a otimização automática de tabelas](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) no *Guia do desenvolvedor do banco de dados Amazon Redshift*.
Para confiar somente na otimização automática da tabela, escolha **Nenhuma** para a **Estratégia inicial de seleção de chave**.
+ Para escolher chaves de classificação e distribuição usando sua estratégia.
Você pode escolher chaves de classificação e distribuição usando metadados, informações estatísticas ou ambas as opções do Amazon Redshift. Para **Estratégia inicial de seleção de chave** na guia **Estratégias de otimização**, escolha uma das seguintes opções:
+ Use metadados, ignore informações estatísticas
+ Ignore metadados, use informações estatísticas
+ Use metadados e informações estatísticas
Dependendo da opção escolhida, você pode selecionar estratégias de otimização. Em seguida, para cada estratégia, insira o valor (0-100). Esses valores definem o peso de cada estratégia. Usando esses valores de peso, a AWS SCT define como cada regra influencia na escolha das chaves de distribuição e classificação. Os valores padrão são baseados nas melhores práticas de AWS migração.
Você pode definir o tamanho de tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para defini-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
+ Para configurar os detalhes da estratégia.
Além de definir o peso de cada estratégia de otimização, você pode definir as configurações de otimização. Para fazer isso, escolha **Otimização de conversões**.
+ Em **Limite de colunas da chave de classificação**, insira o número máximo de colunas na chave de classificação.
+ Em **Valor limite distorcido**, insira a porcentagem (0—100) de um valor distorcido para uma coluna. AWS SCT exclui colunas com o valor de inclinação maior que o limite da lista de candidatos para a chave de distribuição. AWS SCT define o valor distorcido de uma coluna como a proporção percentual entre o número de ocorrências do valor mais comum e o número total de registros.
+ Para as **N principais consultas da tabela do histórico de consultas**, insira o número (1-100) das consultas usadas com mais frequência para análise.
+ Em **Selecionar usuário de estatísticas**, escolha o usuário do banco de dados para o qual você deseja analisar as estatísticas de consulta.
Além disso, na guia **Estratégias de otimização**, você pode definir o tamanho das tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para considerá-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
# Conectando-se a um data warehouse do Snowflake com AWS Schema Conversion Tool
Você pode usar AWS SCT para converter esquemas, objetos de código e código de aplicativo do Snowflake para o Amazon Redshift.
## Privilégios do Snowflake como um banco de dados de origem
Você pode criar uma função com privilégios e conceder a essa função o nome de um usuário usando a função `SECURITYADMIN` e o contexto da sessão `SECURITYADMIN`.
O exemplo a seguir cria privilégios mínimos e os concede ao usuário `min_privs`.
```
create role role_name;
grant role role_name to role sysadmin;
grant usage on database db_name to role role_name;
grant usage on schema db_name.schema_name to role role_name;
grant usage on warehouse datawarehouse_name to role role_name;
grant monitor on database db_name to role role_name;
grant monitor on warehouse datawarehouse_name to role role_name;
grant select on all tables in schema db_name.schema_name to role role_name;
grant select on future tables in schema db_name.schema_name to role role_name;
grant select on all views in schema db_name.schema_name to role role_name;
grant select on future views in schema db_name.schema_name to role role_name;
grant select on all external tables in schema db_name.schema_name to role role_name;
grant select on future external tables in schema db_name.schema_name to role role_name;
grant usage on all sequences in schema db_name.schema_name to role role_name;
grant usage on future sequences in schema db_name.schema_name to role role_name;
grant usage on all functions in schema db_name.schema_name to role role_name;
grant usage on future functions in schema db_name.schema_name to role role_name;
grant usage on all procedures in schema db_name.schema_name to role role_name;
grant usage on future procedures in schema db_name.schema_name to role role_name;
create user min_privs password='real_user_password'
DEFAULT_ROLE = role_name DEFAULT_WAREHOUSE = 'datawarehouse_name';
grant role role_name to user min_privs;
```
No exemplo anterior, substitua os espaços reservados conforme a seguir:
+ Substitua *`role_name`* pelo nome de uma função com privilégios somente leitura.
+ Substitua `db_name` pelo nome do banco de dados de origem.
+ Substitua `schema_name` pelo nome do esquema de origem.
+ Substitua *`datawarehousename`* pelo nome de um data warehouse necessário.
+ Substitua `min_privs` pelo nome de um usuário que tenha privilégios mínimos.
Os parâmetros `DEFAULT_ROLE` e `DEFAULT_WAREHOUSE` são sensíveis a maiúsculas e minúsculas.
## Como configurar o acesso seguro ao Amazon S3
As políticas de gerenciamento de segurança e acesso para um bucket do Amazon S3 permitem que o Snowflake acesse, leia e grave dados no bucket do S3. Você pode configurar o acesso seguro a um bucket privado do Amazon S3 usando o tipo de objeto `STORAGE INTEGRATION` do Snowflake. Um objeto de integração de armazenamento do Snowflake delega a responsabilidade de autenticação a uma entidade de gerenciamento de identidade e acesso do Snowflake.
Para obter mais informações, consulte [Como configurar uma integração de armazenamento do Snowflake para acessar o Amazon S3](https://docs.snowflake.com/en/user-guide/data-load-s3-config-storage-integration.html) na documentação do Snowflake.
## Como se conectar ao Snowflake como origem
Use o procedimento a seguir para conectar seu banco de dados de origem com a AWS Schema Conversion Tool.
**Para se conectar a um banco de dados de origem do Snowflake**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **Snowflake** e, em seguida, escolha **Avançar**.
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para o banco de dados. A AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Use as credenciais do banco de dados AWS Secrets Manager ou insira-as manualmente:
+ Para usar as credenciais do banco de dados do Secrets Manager, use as instruções a seguir:
1. Em **Segredo da AWS **, escolha o nome do seu segredo.
1. Escolha **Preencher** para preencher automaticamente todos os valores na caixa de diálogo de conexão do banco de dados do Secrets Manager.
Para obter informações sobre o uso de credenciais de banco de dados do Secrets Manager, consulte a [Configurando AWS Secrets Manager no AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Para inserir manualmente as informações de conexão do data warehouse do Snowflake de origem, use as instruções a seguir:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.Snowflake.html)
1. Escolha **Testar conexão** para verificar se AWS SCT pode se conectar ao seu banco de dados de origem.
1. Escolha **Conectar** para se conectar ao banco de dados de origem.
## Limitações do Snowflake como origem
A seguir estão as limitações ao usar o Snowflake como fonte para: AWS SCT
+ Os identificadores de objeto devem ser exclusivos dentro do contexto do tipo de objeto e do objeto pai:
**Banco de dados**
Os identificadores do esquema devem ser exclusivos dentro de um banco de dados.
**Esquemas**
Os identificadores de objetos, como tabelas e visualizações, devem ser exclusivos em um esquema.
**Tabelas/Visualizações**
Os identificadores de colunas devem ser exclusivos em uma tabela.
+ O número máximo de tabelas para tipos de nó de cluster large e xlarge é 9.900. O número máximo de tabelas para tipos de nó de cluster 8xlarge é 100.000. O limite inclui tabelas temporárias, tanto definidas pelo usuário ou criadas pelo Amazon Redshift durante o processamento de consultas ou a manutenção do sistema. Para obter mais informações, consulte [Cotas do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html) no *Guia de gerenciamento de clusters do Amazon Redshift*.
+ Para procedimentos armazenados, o número máximo de argumentos de entrada e saída é 32.
## Tipos de dados de origem do Snowflake
A seguir, você pode encontrar os tipos de dados de origem do Snowflake que são compatíveis com o uso AWS SCT e o mapeamento padrão para um destino do Amazon Redshift.
| Tipos de dados do Snowflake | Tipos de dados do Amazon Redshift |
| --- | --- |
| NUMBER | NUMERIC(38) |
| NUMBER(p) | Se p for =< 4, então SMALLINT Se p for => 5 e =< 9, então INTEGER Se p for => 10 e =< 18, então BIGINT Se p for => 19, então NUMERIC(p) |
| NUMBER(p, 0) | Se p for =< 4, então SMALLINT Se p for => 5 e =< 9, então INTEGER Se p for => 10 e =< 18, então BIGINT Se p for => 19, então: NUMERIC(p,0) |
| NUMBER(p, s) | Se p for => 1 e =< 38, e se s for => 1 e =< 37, então NUMERIC(p,s) |
| FLOAT | FLOAT |
| TEXT Caracteres Unicode de até 16.777.216 bytes; até 4 bytes por caractere. | VARCHAR(MAX) |
| TEXT(p) Caracteres Unicode de até 65.535 bytes; até 4 bytes por caractere. | Se p for =< 65.535 então, VARCHAR(p) |
| TEXT(p) Caracteres Unicode de até 16.777.216 bytes; até 4 bytes por caractere. | Se p for => 65.535 e =< 16.777.216 então, VARCHAR(MAX) |
| BINARY Caracteres de byte único de até 8.388.608 bytes; 1 byte por caractere. | VARCHAR(MAX) |
| BYNARY(p) Caracteres de byte único de até 65.535 bytes; 1 byte por caractere. | VARCHAR(p) |
| BYNARY(p) Caracteres de byte único de até 8.388.608 bytes; 1 byte por caractere. | VARCHAR(MAX) |
| BOOLEAN | BOOLEAN |
| DATE | DATE |
| TIME Valores de tempo entre 00:00:00 e 23:59:59.999999999. | VARCHAR(18) |
| TIME(f) Valores de tempo entre 00:00:00 e 23:59:59.9(f). | VARCHAR (n): 9 \$1 dt-attr-1 |
| TIMESTAMP\$1NTZ | TIMESTAMP |
| TIMESTAMP\$1TZ | TIMESTAMPTZ |
## Configurações de conversão do Snowflake para o Amazon Redshift
**Para editar as configurações de conversão do Snowflake para o Amazon Redshift, escolha Configurações em e, AWS SCT em seguida, **escolha** Configurações de conversão.** Na lista superior, escolha **Snowflake** e, em seguida, escolha **Snowflake — Amazon Redshift**. AWS SCT exibe todas as configurações disponíveis para conversão do Snowflake para o Amazon Redshift.
As configurações AWS SCT de conversão do Snowflake para o Amazon Redshift incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para definir o número máximo de tabelas que AWS SCT podem ser aplicadas ao seu cluster de destino do Amazon Redshift.
Em **O número máximo de tabelas para o cluster de destino do Amazon Redshift**, escolha o número de tabelas que AWS SCT podem ser aplicadas ao seu cluster do Amazon Redshift.
O Amazon Redshift tem cotas que limitam as tabelas de uso para diferentes tipos de nós de cluster. Se você escolher **Auto**, AWS SCT determinará o número de tabelas a serem aplicadas ao seu cluster de destino do Amazon Redshift, dependendo do tipo de nó. Opcionalmente, escolha o valor manualmente. Para obter mais informações, consulte “[Cotas e limites no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*.
AWS SCT converte todas as suas tabelas de origem, mesmo que isso seja mais do que o seu cluster do Amazon Redshift pode armazenar. AWS SCT armazena o código convertido em seu projeto e não o aplica ao banco de dados de destino. Se você atingir a cota de cluster do Amazon Redshift para as tabelas ao aplicar o código convertido, a AWS SCT exibirá uma mensagem de aviso. Além disso, AWS SCT aplica tabelas ao seu cluster de destino do Amazon Redshift até que o número de tabelas atinja o limite.
+ Para aplicar compactação às colunas da tabela do Amazon Redshift. Para fazer isso, selecione **Usar codificação de compressão**.
AWS SCT atribui a codificação de compactação às colunas automaticamente usando o algoritmo padrão do Amazon Redshift. Para obter mais informações, consulte [Codificações de compactação](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.
Por padrão, o Amazon Redshift não aplica compactação a colunas definidas como chaves de classificação e distribuição. É possível alterar esse comportamento e aplicar compactação a essas colunas. Para fazer isso, selecione **Usar codificação de compactação para colunas KEY**. Você pode selecionar essa opção somente ao selecionar a opção **Usar codificação de compactação**.
## Configurações de otimização de conversão do Snowflake para o Amazon Redshift
**Para editar as configurações de otimização de conversão do Snowflake para o Amazon Redshift, **escolha Configurações em e, AWS SCT em seguida, selecione** Configurações de conversão.** Na lista superior, escolha **Snowflake** e, em seguida, escolha **Snowflake: Amazon Redshift**. No painel esquerdo, escolha **Estratégias de otimização**. AWS SCT exibe as configurações de otimização de conversão para a conversão do Snowflake para o Amazon Redshift.
As configurações AWS SCT de otimização de conversão do Snowflake para o Amazon Redshift incluem opções para o seguinte:
+ Para trabalhar com otimização automática de tabelas. Para fazer isso, selecione **Usar o ajuste automático da tabela do Amazon Redshift**.
A otimização automática de tabelas é um processo de autoajuste no Amazon Redshift que otimiza automaticamente o design de tabelas. Para obter mais informações, consulte [Como trabalhar com a otimização automática de tabelas](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) no *Guia do desenvolvedor do banco de dados Amazon Redshift*.
Para confiar somente na otimização automática da tabela, escolha **Nenhuma** para a **Estratégia inicial de seleção de chave**.
+ Para escolher chaves de classificação e distribuição usando sua estratégia.
Você pode escolher chaves de classificação e distribuição usando metadados, informações estatísticas ou ambas as opções do Amazon Redshift. Para **Estratégia inicial de seleção de chave** na guia **Estratégias de otimização**, escolha uma das seguintes opções:
+ Use metadados, ignore informações estatísticas
+ Ignore metadados, use informações estatísticas
+ Use metadados e informações estatísticas
Dependendo da opção escolhida, você pode selecionar estratégias de otimização. Em seguida, para cada estratégia, insira o valor (0-100). Esses valores definem o peso de cada estratégia. Usando esses valores de peso, a AWS SCT define como cada regra influencia na escolha das chaves de distribuição e classificação. Os valores padrão são baseados nas melhores práticas de AWS migração.
Você pode definir o tamanho de tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para defini-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
+ Para configurar os detalhes da estratégia.
Além de definir o peso de cada estratégia de otimização, você pode definir as configurações de otimização. Para fazer isso, escolha **Otimização de conversões**.
+ Em **Limite de colunas da chave de classificação**, insira o número máximo de colunas na chave de classificação.
+ Em **Valor limite distorcido**, insira a porcentagem (0—100) de um valor distorcido para uma coluna. AWS SCT exclui colunas com o valor de inclinação maior que o limite da lista de candidatos para a chave de distribuição. AWS SCT define o valor distorcido de uma coluna como a proporção percentual entre o número de ocorrências do valor mais comum e o número total de registros.
+ Para as **N principais consultas da tabela do histórico de consultas**, insira o número (1-100) das consultas usadas com mais frequência para análise.
+ Em **Selecionar usuário de estatísticas**, escolha o usuário do banco de dados para o qual você deseja analisar as estatísticas de consulta.
Além disso, na guia **Estratégias de otimização**, você pode definir o tamanho das tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para considerá-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
# Conectando-se a um SQL Server Data Warehouse com o AWS Schema Conversion Tool
Você pode usar AWS SCT para converter esquemas, objetos de código e código de aplicativo do Microsoft SQL Server DW para o Amazon Redshift ou o Amazon Redshift e usá-los em combinação. AWS Glue
## Privilégios do data warehouse do Microsoft SQL Server como origem
Os privilégios obrigatórios para o data warehouse do Microsoft SQL Server como origem são listados a seguir:
+ VIEW DEFINITION
+ VIEW DATABASE STATE
+ SELECIONE NO ESQUEMA: **
No exemplo anterior, substitua o ** espaço reservado pelo nome do source\$1schema de origem.
Repetir a concessão para cada banco de dados cujo esquema que você está convertendo.
Além disso, conceda o seguinte e execute a concessão no banco de dados mestre:
+ VIEW SERVER STATE
## Limitações de uso do data warehouse do SQL Server como origem
Atualmente, não há suporte para o uso do data warehouse do Microsoft SQL Server Parallel (PDW) como origem.
## Como se conectar ao data warehouse do SQL Server como origem
Use o procedimento a seguir para se conectar ao banco de dados de origem do data warehouse do SQL Server com a AWS Schema Conversion Tool.
**Para conectar-se a um banco de dados de origem do data warehouse do SQL Server**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **Microsoft SQL Server** e, em seguida, escolha **Avançar**.
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para o banco de dados. A AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Use as credenciais do banco de dados AWS Secrets Manager ou insira-as manualmente:
+ Para usar as credenciais do banco de dados do Secrets Manager, use as instruções a seguir:
1. Em **Segredo da AWS **, escolha o nome do seu segredo.
1. Escolha **Preencher** para preencher automaticamente todos os valores na caixa de diálogo de conexão do banco de dados do Secrets Manager.
Para obter informações sobre o uso de credenciais de banco de dados do Secrets Manager, consulte a [Configurando AWS Secrets Manager no AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Para inserir manualmente as informações de conexão do data warehouse de origem do Microsoft SQL Server, use as instruções a seguir:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.SQLServerDW.html)
1. Escolha **Testar conexão** para verificar se AWS SCT pode se conectar ao seu banco de dados de origem.
1. Escolha **Conectar** para se conectar ao banco de dados de origem.
## Configurações de conversão do data warehouse do SQL Server para o Amazon Redshift
Para editar as configurações de conversão do SQL Server Data Warehouse para o Amazon Redshift, escolha **Configurações** em e AWS SCT, em seguida, escolha Configurações **de conversão**. Na lista superior, escolha **Microsoft SQL Server** e, em seguida, escolha **Microsoft SQL Server — Amazon Redshift**. AWS SCT exibe todas as configurações disponíveis para conversão do SQL Server Data Warehouse para o Amazon Redshift.
As configurações de conversão do SQL Server Data Warehouse para o Amazon Redshift AWS SCT incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para definir o número máximo de tabelas que AWS SCT podem ser aplicadas ao seu cluster de destino do Amazon Redshift.
Em **O número máximo de tabelas para o cluster de destino do Amazon Redshift**, escolha o número de tabelas que AWS SCT podem ser aplicadas ao seu cluster do Amazon Redshift.
O Amazon Redshift tem cotas que limitam as tabelas de uso para diferentes tipos de nós de cluster. Se você escolher **Auto**, AWS SCT determinará o número de tabelas a serem aplicadas ao seu cluster de destino do Amazon Redshift, dependendo do tipo de nó. Opcionalmente, escolha o valor manualmente. Para obter mais informações, consulte “[Cotas e limites no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*.
AWS SCT converte todas as suas tabelas de origem, mesmo que isso seja mais do que o seu cluster do Amazon Redshift pode armazenar. AWS SCT armazena o código convertido em seu projeto e não o aplica ao banco de dados de destino. Se você atingir a cota de cluster do Amazon Redshift para as tabelas ao aplicar o código convertido, a AWS SCT exibirá uma mensagem de aviso. Além disso, AWS SCT aplica tabelas ao seu cluster de destino do Amazon Redshift até que o número de tabelas atinja o limite.
+ Para migrar partições da tabela de origem para tabelas separadas no Amazon Redshift. Para fazer isso, selecione **Usar a exibição UNION ALL** e insira o número máximo de tabelas de destino que a AWS SCT pode criar para uma única tabela de origem.
O Amazon Redshift não oferece suporte ao particionamento de tabelas. Para emular esse comportamento e acelerar a execução das consultas, AWS SCT você pode migrar cada partição da sua tabela de origem para uma tabela separada no Amazon Redshift. Em seguida, AWS SCT cria uma exibição que inclui dados de todas essas tabelas.
AWS SCT determina automaticamente o número de partições na tabela de origem. Dependendo do tipo de particionamento da tabela de origem, esse número pode exceder a cota das tabelas que você pode aplicar ao seu cluster do Amazon Redshift. Para evitar atingir essa cota, insira o número máximo de tabelas de destino que AWS SCT podem ser criadas para partições de uma única tabela de origem. A opção padrão é 368 tabelas, que representam uma partição para 366 dias do ano e duas tabelas para partições `NO RANGE` e `UNKNOWN`.
+ Para aplicar compactação às colunas da tabela do Amazon Redshift. Para fazer isso, selecione **Usar codificação de compressão**.
AWS SCT atribui a codificação de compactação às colunas automaticamente usando o algoritmo padrão do Amazon Redshift. Para obter mais informações, consulte [Codificações de compactação](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.
Por padrão, o Amazon Redshift não aplica compactação a colunas definidas como chaves de classificação e distribuição. É possível alterar esse comportamento e aplicar compactação a essas colunas. Para fazer isso, selecione **Usar codificação de compactação para colunas KEY**. Você pode selecionar essa opção somente ao selecionar a opção **Usar codificação de compactação**.
## Configurações de otimização de conversão do data warehouse do SQL Server para o Amazon Redshift
Para editar as configurações de otimização de conversão do SQL Server Data Warehouse para o Amazon Redshift, escolha **Configurações** em e AWS SCT, em seguida, escolha Configurações **de conversão**. Na lista superior, escolha **Microsoft SQL Server** e, em seguida, escolha **Microsoft SQL Server: Amazon Redshift**. No painel esquerdo, escolha **Estratégias de otimização**. AWS SCT exibe as configurações de otimização de conversão para conversão do SQL Server Data Warehouse para o Amazon Redshift.
As configurações de otimização de conversão do SQL Server Data Warehouse para o Amazon Redshift AWS SCT incluem opções para o seguinte:
+ Para trabalhar com otimização automática de tabelas. Para fazer isso, selecione **Usar o ajuste automático da tabela do Amazon Redshift**.
A otimização automática de tabelas é um processo de autoajuste no Amazon Redshift que otimiza automaticamente o design de tabelas. Para obter mais informações, consulte [Como trabalhar com a otimização automática de tabelas](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) no *Guia do desenvolvedor do banco de dados Amazon Redshift*.
Para confiar somente na otimização automática da tabela, escolha **Nenhuma** para a **Estratégia inicial de seleção de chave**.
+ Para escolher chaves de classificação e distribuição usando sua estratégia.
Você pode escolher chaves de classificação e distribuição usando metadados, informações estatísticas ou ambas as opções do Amazon Redshift. Para **Estratégia inicial de seleção de chave** na guia **Estratégias de otimização**, escolha uma das seguintes opções:
+ Use metadados, ignore informações estatísticas
+ Ignore metadados, use informações estatísticas
+ Use metadados e informações estatísticas
Dependendo da opção escolhida, você pode selecionar estratégias de otimização. Em seguida, para cada estratégia, insira o valor (0-100). Esses valores definem o peso de cada estratégia. Usando esses valores de peso, a AWS SCT define como cada regra influencia na escolha das chaves de distribuição e classificação. Os valores padrão são baseados nas melhores práticas de AWS migração.
Você pode definir o tamanho de tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para defini-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
+ Para configurar os detalhes da estratégia.
Além de definir o peso de cada estratégia de otimização, você pode definir as configurações de otimização. Para fazer isso, escolha **Otimização de conversões**.
+ Em **Limite de colunas da chave de classificação**, insira o número máximo de colunas na chave de classificação.
+ Em **Valor limite distorcido**, insira a porcentagem (0—100) de um valor distorcido para uma coluna. AWS SCT exclui colunas com o valor de inclinação maior que o limite da lista de candidatos para a chave de distribuição. AWS SCT define o valor distorcido de uma coluna como a proporção percentual entre o número de ocorrências do valor mais comum e o número total de registros.
+ Para as **N principais consultas da tabela do histórico de consultas**, insira o número (1-100) das consultas usadas com mais frequência para análise.
+ Em **Selecionar usuário de estatísticas**, escolha o usuário do banco de dados para o qual você deseja analisar as estatísticas de consulta.
Além disso, na guia **Estratégias de otimização**, você pode definir o tamanho das tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para considerá-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
# Conectando-se a um data warehouse da Teradata com o AWS Schema Conversion Tool
Você pode usar AWS SCT para converter esquemas, objetos de código e código de aplicativo da Teradata para o Amazon Redshift ou Amazon Redshift e usá-los em combinação. AWS Glue
## Privilégios do Teradata como origem
Os privilégios obrigatórios para Teradata como origem são listados a seguir:
+ SELECT ON DBC
+ SELECT ON SYSUDTLIB
+ SELECT ON SYSLIB
+ SELECIONE ATIVADO **
+ CRIAR PROCEDIMENTO EM **
No exemplo anterior, substitua o espaço reservado ** pelo nome do banco de dados de origem.
AWS SCT requer o privilégio CREATE PROCEDURE para executar HELP PROCEDURE em todos os procedimentos no banco de dados de origem. AWS SCT não usa esse privilégio para criar novos objetos no banco de dados Teradata de origem.
## Como se conectar ao Teradata como origem
Use o procedimento a seguir para conectar seu banco de dados de origem do Teradata com a AWS Schema Conversion Tool.
**Para conectar-se a um banco de dados de origem Teradata**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **Teradata** e, em seguida, escolha **Avançar**.
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para o banco de dados. A AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Use as credenciais do banco de dados AWS Secrets Manager ou insira-as manualmente:
+ Para usar as credenciais do banco de dados do Secrets Manager, use as instruções a seguir:
1. Em **Segredo da AWS **, escolha o nome do seu segredo.
1. Escolha **Preencher** para preencher automaticamente todos os valores na caixa de diálogo de conexão do banco de dados do Secrets Manager.
Para obter informações sobre o uso de credenciais de banco de dados do Secrets Manager, consulte a [Configurando AWS Secrets Manager no AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Para inserir manualmente as informações de conexão do banco de dados do Teradata de origem, use as instruções a seguir:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.Teradata.html)
1. Escolha **Testar conexão** para verificar se AWS SCT pode se conectar ao seu banco de dados de origem.
1. Escolha **Conectar** para se conectar ao banco de dados de origem.
### Usar autenticação LDAP com um Teradata de origem
Para configurar a autenticação Lightweight Directory Access Protocol (LDAP) para usuários Teradata que executam o Microsoft Active Directory no Windows, use o procedimento a seguir.
No procedimento a seguir, o domínio do Active Directory é `test.local.com`. O servidor do Windows é `DC` e está configurado com as configurações padrão. O script a seguir cria a conta no Active Directory `test_ldap` e essa conta usa a senha `test_ldap`.
**Para configurar a autenticação LDAP para usuários do Teradata que executam o Microsoft Active Directory no Windows**
1. No diretório `/opt/teradata/tdat/tdgss/site`, edite o arquivo `TdgssUserConfigFile.xml`. Altere a seção LDAP para o seguinte:
```
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. Aplique as alterações executando a configuração a seguir.
```
#cd /opt/teradata/tdgss/bin
#./run_tdgssconfig
```
1. Teste a configuração executando o comando a seguir.
```
# /opt/teradata/tdat/tdgss/14.10.03.01/bin/tdsbind -u test_ldap -w test_ldap
```
A saída deve ser semelhante a esta.
```
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. Reinicie o TPA usando o comando a seguir.
```
#tpareset -f "use updated TDGSSCONFIG GDO"
```
1. Crie o mesmo usuário no banco de dados Teradata como no Active Directory, conforme mostrado a seguir.
```
CREATE USER test_ldap AS PERM=1000, PASSWORD=test_ldap;
GRANT LOGON ON ALL TO test WITH NULL PASSWORD;
```
Se você alterar a senha de usuário no Active Directory do seu usuário LDAP, especifique essa nova senha durante a conexão ao Teradata em modo LDAP. No modo PADRÃO, você se conecta ao Teradata usando o nome de usuário LDAP e qualquer senha.
## Como configurar a coleta de estatísticas em seu data warehouse do Teradata de origem
Para converter seu armazém de dados Teradata de origem, AWS SCT usa estatísticas para otimizar seu armazém de dados convertido do Amazon Redshift. Você pode coletar estatísticas em AWS SCT ou fazer o upload do arquivo de estatísticas. Para obter mais informações, consulte [Como coletar ou carregar as estatísticas](CHAP_Converting.DW.md#CHAP_Converting.DW.Statistics).
Para garantir que AWS SCT possa coletar estatísticas do seu data warehouse, conclua as seguintes tarefas de pré-requisito.
**Para coletar estatísticas do seu data warehouse do Teradata**
1. Execute a consulta a seguir para recuperar as estatísticas de todas as tabelas em seu data warehouse.
```
collect summary statistics on table_name;
```
No exemplo anterior, *table\$1name* substitua pelo nome da tabela de origem. Repita a consulta para cada tabela que você converter.
1. Execute a consulta a seguir para determinar a string da conta do usuário, que você usa para converter seu data warehouse.
```
select * from dbc.accountinfo where username ='user_name'
```
1. Ative o registro de consultas para um usuário específico usando a string da conta do exemplo anterior.
```
BEGIN QUERY LOGGING WITH OBJECTS, SQL ON ALL ACCOUNT=('$M$BUSI$S$D$H');
```
Como alternativa, ative o registro de consultas para todos os usuários do banco de dados.
```
BEGIN QUERY LOGGING WITH SQL, OBJECTS LIMIT SQLTEXT=0 ON ALL;
```
Depois de concluir a coleta das estatísticas do data warehouse, desative o registro de consultas. Para fazer isso, você pode usar o exemplo de código a seguir.
```
end query logging with explain, objects, sql on all account=(' $M$BUSI$S$D$H');
```
## Como coletar estatísticas em modo off-line do seu data warehouse do Teradata de origem
Depois de configurar a coleta de estatísticas em seu data warehouse Teradata, você pode coletar estatísticas em seu AWS SCT projeto. Como alternativa, você pode usar scripts Basic Teradata Query (BTEQ) para coletar estatísticas em um modo off-line. Em seguida, você pode fazer o upload dos arquivos com as estatísticas coletadas para o seu projeto da AWS SCT . Para obter mais informações, consulte [Como coletar ou carregar as estatísticas](CHAP_Converting.DW.md#CHAP_Converting.DW.Statistics).
**Para coletar estatísticas do seu data warehouse do Teradata em um modo off-line**
1. Crie o script `off-line_stats.bteq` com o conteúdo a seguir.
```
.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. Crie o arquivo `td_run_bteq.bat` que executa o script BTEQ que você criou na etapa anterior. Use o conteúdo a seguir para esse arquivo.
```
@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. Crie o arquivo `runme.bat` que executa o arquivo de lote que você criou na etapa anterior. Use o conteúdo a seguir para esse arquivo.
```
.\td_run_bteq.bat ServerName UserName DatabaseName
```
No `runme.bat` arquivo, substitua *ServerName**UserName*, e *DatabaseName* pelos valores aplicáveis.
Em seguida, execute o arquivo `runme.bat`. Repita essa etapa para cada data warehouse que você converter para o Amazon Redshift.
Depois de executar esse script, você recebe três arquivos com estatísticas para cada banco de dados. Você pode fazer o upload desses arquivos para o seu AWS SCT projeto. Para fazer isso, escolha seu data warehouse no painel esquerdo do projeto e abra o menu contextual (clique com o botão direito do mouse). Escolha **Fazer upload estatísticas**.
## Configurações de conversão do Teradata para o Amazon Redshift
**Para editar as configurações de conversão do Teradata para o Amazon Redshift, escolha Configurações em e, AWS SCT em seguida, **escolha** Configurações de conversão.** Na lista superior, escolha **Teradata** e, em seguida, escolha **Teradata — Amazon Redshift**. AWS SCT exibe todas as configurações disponíveis para conversão de Teradata para Amazon Redshift.
As configurações AWS SCT de conversão de Teradata para Amazon Redshift incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para definir o número máximo de tabelas que AWS SCT podem ser aplicadas ao seu cluster de destino do Amazon Redshift.
Em **O número máximo de tabelas para o cluster de destino do Amazon Redshift**, escolha o número de tabelas que AWS SCT podem ser aplicadas ao seu cluster do Amazon Redshift.
O Amazon Redshift tem cotas que limitam as tabelas de uso para diferentes tipos de nós de cluster. Se você escolher **Auto**, AWS SCT determinará o número de tabelas a serem aplicadas ao seu cluster de destino do Amazon Redshift, dependendo do tipo de nó. Opcionalmente, escolha o valor manualmente. Para obter mais informações, consulte “[Cotas e limites no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*.
AWS SCT converte todas as suas tabelas de origem, mesmo que isso seja mais do que o seu cluster do Amazon Redshift pode armazenar. AWS SCT armazena o código convertido em seu projeto e não o aplica ao banco de dados de destino. Se você atingir a cota de cluster do Amazon Redshift para as tabelas ao aplicar o código convertido, a AWS SCT exibirá uma mensagem de aviso. Além disso, AWS SCT aplica tabelas ao seu cluster de destino do Amazon Redshift até que o número de tabelas atinja o limite.
+ Para migrar partições da tabela de origem para tabelas separadas no Amazon Redshift. Para fazer isso, selecione **Usar a exibição UNION ALL** e insira o número máximo de tabelas de destino que a AWS SCT pode criar para uma única tabela de origem.
O Amazon Redshift não oferece suporte ao particionamento de tabelas. Para emular esse comportamento e acelerar a execução das consultas, AWS SCT você pode migrar cada partição da sua tabela de origem para uma tabela separada no Amazon Redshift. Em seguida, AWS SCT cria uma exibição que inclui dados de todas essas tabelas.
AWS SCT determina automaticamente o número de partições na tabela de origem. Dependendo do tipo de particionamento da tabela de origem, esse número pode exceder a cota das tabelas que você pode aplicar ao seu cluster do Amazon Redshift. Para evitar atingir essa cota, insira o número máximo de tabelas de destino que AWS SCT podem ser criadas para partições de uma única tabela de origem. A opção padrão é 368 tabelas, que representam uma partição para 366 dias do ano e duas tabelas para partições `NO RANGE` e `UNKNOWN`.
+ Para aplicar compactação às colunas da tabela do Amazon Redshift. Para fazer isso, selecione **Usar codificação de compressão**.
AWS SCT atribui a codificação de compactação às colunas automaticamente usando o algoritmo padrão do Amazon Redshift. Para obter mais informações, consulte [Codificações de compactação](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.
Por padrão, o Amazon Redshift não aplica compactação a colunas definidas como chaves de classificação e distribuição. É possível alterar esse comportamento e aplicar compactação a essas colunas. Para fazer isso, selecione **Usar codificação de compactação para colunas KEY**. Você pode selecionar essa opção somente ao selecionar a opção **Usar codificação de compactação**.
+ Para usar uma lista explícita de colunas no código convertido para as instruções `SELECT *`, selecione **Usar instrução de coluna explícita**.
+ Para emular o comportamento das chaves primárias e exclusivas em seu cluster do Amazon Redshift, selecione **Emular o comportamento das chaves primárias e exclusivas**.
O Amazon Redshift não impõe chaves exclusivas e primárias e as usa apenas para fins informativos. Se você usar essas restrições em seu código, certifique-se de que AWS SCT emula o comportamento delas no código convertido.
+ Para garantir a exclusividade dos dados nas tabelas do Amazon Redshift de destino. Para fazer isso, selecione **Emular o comportamento das tabelas SET**.
O Teradata cria tabelas usando o elemento de sintaxe `SET` como opção padrão. Você não pode adicionar linhas duplicadas em uma tabela `SET`. Se o código-fonte não usar essa restrição de exclusividade, desative essa opção. Nesse caso, o código convertido funciona mais rápido.
Se o código-fonte usa a opção `SET` em tabelas como uma restrição de exclusividade, ative essa opção. Nesse caso, AWS SCT reescreve `INSERT..SELECT` as instruções no código convertido para emular o comportamento do seu banco de dados de origem.
## Configurações de otimização de conversão do Teradata para o Amazon Redshift
**Para editar as configurações de otimização de conversão do Teradata para o Amazon Redshift, escolha Configurações em e, AWS SCT em seguida, **escolha** Configurações de conversão.** Na lista superior, escolha **Teradata** e, em seguida, escolha **Teradata: Amazon Redshift**. No painel esquerdo, escolha **Estratégias de otimização**. AWS SCT exibe as configurações de otimização de conversão para conversão de Teradata para Amazon Redshift.
As configurações AWS SCT de otimização de conversão do Teradata para o Amazon Redshift incluem opções para o seguinte:
+ Para trabalhar com otimização automática de tabelas. Para fazer isso, selecione **Usar o ajuste automático da tabela do Amazon Redshift**.
A otimização automática de tabelas é um processo de autoajuste no Amazon Redshift que otimiza automaticamente o design de tabelas. Para obter mais informações, consulte [Como trabalhar com a otimização automática de tabelas](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) no *Guia do desenvolvedor do banco de dados Amazon Redshift*.
Para confiar somente na otimização automática da tabela, escolha **Nenhuma** para a **Estratégia inicial de seleção de chave**.
+ Para escolher chaves de classificação e distribuição usando sua estratégia.
Você pode escolher chaves de classificação e distribuição usando metadados, informações estatísticas ou ambas as opções do Amazon Redshift. Para **Estratégia inicial de seleção de chave** na guia **Estratégias de otimização**, escolha uma das seguintes opções:
+ Use metadados, ignore informações estatísticas
+ Ignore metadados, use informações estatísticas
+ Use metadados e informações estatísticas
Dependendo da opção escolhida, você pode selecionar estratégias de otimização. Em seguida, para cada estratégia, insira o valor (0-100). Esses valores definem o peso de cada estratégia. Usando esses valores de peso, a AWS SCT define como cada regra influencia na escolha das chaves de distribuição e classificação. Os valores padrão são baseados nas melhores práticas de AWS migração.
Você pode definir o tamanho de tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para defini-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
+ Para configurar os detalhes da estratégia.
Além de definir o peso de cada estratégia de otimização, você pode definir as configurações de otimização. Para fazer isso, escolha **Otimização de conversões**.
+ Em **Limite de colunas da chave de classificação**, insira o número máximo de colunas na chave de classificação.
+ Em **Valor limite distorcido**, insira a porcentagem (0—100) de um valor distorcido para uma coluna. AWS SCT exclui colunas com o valor de inclinação maior que o limite da lista de candidatos para a chave de distribuição. AWS SCT define o valor distorcido de uma coluna como a proporção percentual entre o número de ocorrências do valor mais comum e o número total de registros.
+ Para as **N principais consultas da tabela do histórico de consultas**, insira o número (1-100) das consultas usadas com mais frequência para análise.
+ Em **Selecionar usuário de estatísticas**, escolha o usuário do banco de dados para o qual você deseja analisar as estatísticas de consulta.
Além disso, na guia **Estratégias de otimização**, você pode definir o tamanho das tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para considerá-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
# Conectando os bancos AWS Schema Conversion Tool de dados Vertica
Você pode usar AWS SCT para converter esquemas, objetos de código e código de aplicativo do Vertica para o Amazon Redshift.
## Privilégios do Vertica como origem
Os privilégios obrigatórios para o Vertica como origem são listados a seguir:
+ USO NO ESQUEMA **
+ USAGE ON SCHEMA PUBLIC
+ SELECIONE EM TODAS AS TABELAS NO ESQUEMA **
+ SELECIONE EM TODAS AS SEQUÊNCIAS NO ESQUEMA **
+ EXECUTAR EM TODAS AS FUNÇÕES NO ESQUEMA **
+ EXECUTAR O PROCEDIMENTO **
No exemplo anterior, substitua os espaços reservados conforme a seguir:
+ Substitua *schema\$1name* pelo nome do esquema de origem.
+ *procedure\$1name*Substitua pelo nome de um procedimento de origem. Repita a concessão para cada procedimento que você está convertendo.
+ *procedure\$1signature*Substitua pela lista delimitada por vírgula dos tipos de argumentos do procedimento.
## Como se conectar ao Vertica como origem
Use o procedimento a seguir para conectar seu banco de dados de origem do Vertica com a AWS Schema Conversion Tool.
**Para conectar-se a um banco de dados de origem Vertica**
1. No AWS Schema Conversion Tool, escolha **Adicionar fonte**.
1. Escolha **Vertica** e, em seguida, escolha **Avançar**.
A caixa de diálogo **Adicionar origem** é exibida.
1. Em **Nome da conexão**, insira um nome para o banco de dados. A AWS SCT exibe esse nome na árvore no painel esquerdo.
1. Use as credenciais do banco de dados AWS Secrets Manager ou insira-as manualmente:
+ Para usar as credenciais do banco de dados do Secrets Manager, use as instruções a seguir:
1. Em **Segredo da AWS **, escolha o nome do seu segredo.
1. Escolha **Preencher** para preencher automaticamente todos os valores na caixa de diálogo de conexão do banco de dados do Secrets Manager.
Para obter informações sobre o uso de credenciais de banco de dados do Secrets Manager, consulte a [Configurando AWS Secrets Manager no AWS Schema Conversion Tool](CHAP_UserInterface.SecretsManager.md).
+ Para inserir manualmente as informações de conexão do banco de dados do Vertica de origem, use as instruções a seguir:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Source.Vertica.html)
1. Escolha **Testar conexão** para verificar se AWS SCT pode se conectar ao seu banco de dados de origem.
1. Escolha **Conectar** para se conectar ao banco de dados de origem.
## Configurações de conversão do Vertica para o Amazon Redshift
Para editar as configurações de conversão do Vertica para o Amazon Redshift, **escolha** Configurações AWS SCT em e, em seguida, **escolha** Configurações de conversão. Na lista superior, escolha **Vertica** e, em seguida, escolha **Vertica — Amazon Redshift**. AWS SCT exibe todas as configurações disponíveis para conversão de Vertica para Amazon Redshift.
As configurações AWS SCT de conversão do Vertica para o Amazon Redshift incluem opções para o seguinte:
+ Para limitar o número de comentários com itens de ação no código convertido.
Em **Adicionar comentários no código convertido para os itens de ação de severidade selecionada e superior**, escolha a severidade dos itens de ação. AWS SCT adiciona comentários no código convertido para itens de ação da severidade selecionada e superior.
Por exemplo, para minimizar o número de comentários em seu código convertido, escolha **Somente erros**. Para incluir comentários para todos os itens de ação em seu código convertido, escolha **Todas as mensagens**.
+ Para definir o número máximo de tabelas que AWS SCT podem ser aplicadas ao seu cluster de destino do Amazon Redshift.
Em **O número máximo de tabelas para o cluster de destino do Amazon Redshift**, escolha o número de tabelas que AWS SCT podem ser aplicadas ao seu cluster do Amazon Redshift.
O Amazon Redshift tem cotas que limitam as tabelas de uso para diferentes tipos de nós de cluster. Se você escolher **Auto**, AWS SCT determinará o número de tabelas a serem aplicadas ao seu cluster de destino do Amazon Redshift, dependendo do tipo de nó. Opcionalmente, escolha o valor manualmente. Para obter mais informações, consulte “[Cotas e limites no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*.
AWS SCT converte todas as suas tabelas de origem, mesmo que isso seja mais do que o seu cluster do Amazon Redshift pode armazenar. AWS SCT armazena o código convertido em seu projeto e não o aplica ao banco de dados de destino. Se você atingir a cota de cluster do Amazon Redshift para as tabelas ao aplicar o código convertido, a AWS SCT exibirá uma mensagem de aviso. Além disso, AWS SCT aplica tabelas ao seu cluster de destino do Amazon Redshift até que o número de tabelas atinja o limite.
+ Para migrar partições da tabela de origem para tabelas separadas no Amazon Redshift. Para fazer isso, selecione **Usar a exibição UNION ALL** e insira o número máximo de tabelas de destino que a AWS SCT pode criar para uma única tabela de origem.
O Amazon Redshift não oferece suporte ao particionamento de tabelas. Para emular esse comportamento e acelerar a execução das consultas, AWS SCT você pode migrar cada partição da sua tabela de origem para uma tabela separada no Amazon Redshift. Em seguida, AWS SCT cria uma exibição que inclui dados de todas essas tabelas.
AWS SCT determina automaticamente o número de partições na tabela de origem. Dependendo do tipo de particionamento da tabela de origem, esse número pode exceder a cota das tabelas que você pode aplicar ao seu cluster do Amazon Redshift. Para evitar atingir essa cota, insira o número máximo de tabelas de destino que AWS SCT podem ser criadas para partições de uma única tabela de origem. A opção padrão é 368 tabelas, que representam uma partição para 366 dias do ano e duas tabelas para partições `NO RANGE` e `UNKNOWN`.
+ Para aplicar compactação às colunas da tabela do Amazon Redshift. Para fazer isso, selecione **Usar codificação de compressão**.
AWS SCT atribui a codificação de compactação às colunas automaticamente usando o algoritmo padrão do Amazon Redshift. Para obter mais informações, consulte [Codificações de compactação](https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html) no *Guia do desenvolvedor de banco de dados do Amazon Redshift*.
Por padrão, o Amazon Redshift não aplica compactação a colunas definidas como chaves de classificação e distribuição. É possível alterar esse comportamento e aplicar compactação a essas colunas. Para fazer isso, selecione **Usar codificação de compactação para colunas KEY**. Você pode selecionar essa opção somente ao selecionar a opção **Usar codificação de compactação**.
## Configurações de otimização de conversão do Vertica para o Amazon Redshift
Para editar as configurações de otimização de conversão do Vertica para o Amazon Redshift, **escolha** Configurações AWS SCT em e, em seguida, **escolha** Configurações de conversão. Na lista superior, escolha **Vertica** e, em seguida, escolha **Vertica: Amazon Redshift**. No painel esquerdo, escolha **Estratégias de otimização**. AWS SCT exibe as configurações de otimização de conversão para a conversão de Vertica para Amazon Redshift.
As configurações AWS SCT de otimização de conversão do Vertica para o Amazon Redshift incluem opções para o seguinte:
+ Para trabalhar com otimização automática de tabelas. Para fazer isso, selecione **Usar o ajuste automático da tabela do Amazon Redshift**.
A otimização automática de tabelas é um processo de autoajuste no Amazon Redshift que otimiza automaticamente o design de tabelas. Para obter mais informações, consulte [Como trabalhar com a otimização automática de tabelas](https://docs.aws.amazon.com/redshift/latest/dg/t_Creating_tables.html) no *Guia do desenvolvedor do banco de dados Amazon Redshift*.
Para confiar somente na otimização automática da tabela, escolha **Nenhuma** para a **Estratégia inicial de seleção de chave**.
+ Para escolher chaves de classificação e distribuição usando sua estratégia.
Você pode escolher chaves de classificação e distribuição usando metadados, informações estatísticas ou ambas as opções do Amazon Redshift. Para **Estratégia inicial de seleção de chave** na guia **Estratégias de otimização**, escolha uma das seguintes opções:
+ Use metadados, ignore informações estatísticas
+ Ignore metadados, use informações estatísticas
+ Use metadados e informações estatísticas
Dependendo da opção escolhida, você pode selecionar estratégias de otimização. Em seguida, para cada estratégia, insira o valor (0-100). Esses valores definem o peso de cada estratégia. Usando esses valores de peso, a AWS SCT define como cada regra influencia na escolha das chaves de distribuição e classificação. Os valores padrão são baseados nas melhores práticas de AWS migração.
Você pode definir o tamanho de tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para defini-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.
+ Para configurar os detalhes da estratégia.
Além de definir o peso de cada estratégia de otimização, você pode definir as configurações de otimização. Para fazer isso, escolha **Otimização de conversões**.
+ Em **Limite de colunas da chave de classificação**, insira o número máximo de colunas na chave de classificação.
+ Em **Valor limite distorcido**, insira a porcentagem (0—100) de um valor distorcido para uma coluna. AWS SCT exclui colunas com o valor de inclinação maior que o limite da lista de candidatos para a chave de distribuição. AWS SCT define o valor distorcido de uma coluna como a proporção percentual entre o número de ocorrências do valor mais comum e o número total de registros.
+ Para as **N principais consultas da tabela do histórico de consultas**, insira o número (1-100) das consultas usadas com mais frequência para análise.
+ Em **Selecionar usuário de estatísticas**, escolha o usuário do banco de dados para o qual você deseja analisar as estatísticas de consulta.
Além disso, na guia **Estratégias de otimização**, você pode definir o tamanho das tabelas pequenas para a estratégia **Localizar tabelas pequenas**. Em Contagem **mínima de linhas da tabela e Contagem** **máxima de linhas** da tabela, insira o número mínimo e máximo de linhas em uma tabela para considerá-la como uma tabela pequena. AWS SCT aplica o estilo `ALL` de distribuição a tabelas pequenas. Nesse caso, uma cópia de toda a tabela é distribuída para cada nó.