Migrando do SQL servidor para o SQL Postgre com AWS Schema Conversion Tool - AWS Schema Conversion Tool

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Migrando do SQL servidor para o SQL Postgre com AWS Schema Conversion Tool

Você pode usar o pacote de SQL extensão SQL Server to Postgre em AWS SCT. Esse pacote de extensão emula as funções SQL do banco de dados do servidor no código Postgre SQL convertido. Use o pacote de SQL extensão SQL Server to Postgre 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.

Privilégios do Postgre SQL como banco de dados de destino

Para usar o Postgre SQL como alvo, é AWS SCT necessário o CREATE ON DATABASE privilégio. Certifique-se de conceder esse privilégio para cada banco de dados Postgre SQL 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, substitua user_name com o nome do seu usuário. Em seguida, substitua db_name com o nome do seu banco de dados de destino. Finalmente, substitua your_password com uma senha segura.

No PostgreSQL, somente o proprietário ou a do esquema 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.

SQLConfigurações de SQL conversão do servidor para o Postgre

Para editar as configurações de SQL conversão SQL do Server para o Postgre, escolha Configurações e, em seguida, escolha Configurações de conversão. Na lista superior, escolha SQLServidor e, em seguida, escolha SQLServidor — Postgre SQL. AWS SCT exibe todas as configurações disponíveis para SQL conversão de SQL Servidor para Postgre.

SQLAs configurações de SQL conversão do servidor para o Postgre 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 o uso de índices com o mesmo nome em tabelas diferentes no SQL Servidor.

    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 SQL do servidor em SQL funções do Postgre.

    A SQL versão 10 e anteriores do Postgre 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 do servidor de origem pode armazenar 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.

  • 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:

    • <source_db>— Usa o nome SQL do banco de dados do servidor como um nome de esquema no Postgre. SQL

    • <source_schema>— Usa o nome SQL do esquema do servidor como nome do esquema no Postgre. SQL

    • _ <source_db><schema>— Usa uma combinação do banco de dados do SQL servidor e dos nomes do esquema como um nome de esquema no Postgre. SQL

  • 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.

Convertendo partições SQL do servidor em partições do Postgre SQL versão 10

Ao converter um banco de dados Microsoft SQL Server em Amazon Aurora Postgre SQL -Compatible Edition (Aurora Postgre) ou Amazon Relational SQL Database Service for Postgre (SQLAmazon RDS for Postgre), esteja ciente do seguinte. SQL

No SQL Servidor, você cria partições com funções de partição. Ao converter de uma tabela porcionada do SQL servidor para uma tabela particionada do Postgre SQL versão 10, esteja ciente de vários problemas em potencial:

  • SQLO servidor permite particionar uma tabela usando uma coluna sem NOT NULL restrições. Nesse caso, todos os NULL valores vão para a partição mais à esquerda. O Postgre SQL não suporta NULL valores para RANGE particionamento.

  • SQLO servidor permite criar chaves primárias e exclusivas para tabelas particionadas. Para o PostgreSQL, você cria chaves primárias ou exclusivas diretamente para cada partição. Portanto, PRIMARY nossa UNIQUE KEY restrição deve ser removida de sua tabela principal ao migrar para o Postgre. SQL Os nomes de chaves resultantes assumem o formato <original_key_name>_<partition_number>.

  • SQLO servidor permite que você crie restrições de chave estrangeira de e para tabelas particionadas. O Postgre SQL não suporta chaves estrangeiras referenciando tabelas particionadas. Além disso, o Postgre SQL não suporta referências de chave estrangeira de uma tabela particionada para outra tabela.

  • SQLO servidor permite criar índices para tabelas particionadas. Para o PostgreSQL, um índice deve ser criado diretamente para cada partição. Portanto, os índices devem ser removidos de suas tabelas principais ao migrar para o Postgre. SQL Os nomes de índices resultantes assumem o formato <original_index_name>_<partition_number>.

  • O Postgre SQL não oferece suporte a índices particionados.

Considerações sobre a migração

Algumas coisas a considerar ao migrar um esquema de SQL servidor para o Postgre: SQL

  • No PostgreSQL, todos os nomes de objetos em um esquema devem ser exclusivos, incluindo índices. Os nomes de índice devem ser exclusivos no esquema da tabela-base. No SQL Servidor, o nome de um índice pode ser o mesmo para 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_table_name_index_name. Caso contrário, os nomes de índice não são alterados.

  • Uma GOTO instrução e um rótulo podem ser usados para alterar a ordem em que as instruções são executadas. Todas SQL as declarações Transact que seguem uma GOTO declaração são ignoradas e o processamento continua no rótulo. GOTOdeclarações e rótulos podem ser usados em qualquer lugar dentro de um procedimento, lote ou bloco de instruções. GOTOas declarações também podem ser aninhadas.

    O Postgre SQL não usa GOTO declarações. Quando AWS SCT converte o código que contém uma GOTO instrução, ele converte a instrução para usar uma instruçãoBEGIN... END ouLOOP... END LOOP Você pode encontrar exemplos de como AWS SCT converte GOTO declarações na tabela a seguir.

    SQLGOTOInstruções do servidor e as instruções Postgre SQL convertidas
    SQLDeclaração do servidor Declaração do Postger SQL
    BEGIN .... statement1; .... GOTO label1; statement2; .... label1: Statement3; .... END
    BEGIN label1: BEGIN .... statement1; .... EXIT label1; statement2; .... END; Statement3; .... END
    BEGIN .... statement1; .... label1: statement2; .... GOTO label1; statement3; .... statement4; .... END
    BEGIN .... statement1; .... label1: LOOP statement2; .... CONTINUE label1; EXIT label1; END LOOP; statement3; .... statement4; .... END
    BEGIN .... statement1; .... label1: statement2; .... statement3; .... statement4; .... END
    BEGIN .... statement1; .... label1: BEGIN statement2; .... statement3; .... statement4; .... END; END
  • O Postgre SQL não apóia uma MERGE declaração. AWS SCT emula o comportamento de uma MERGE declaração das seguintes formas:

    • Por INSERT ON CONFLICT construction.

    • Usando a UPDATE FROM DML declaração, como MERGE sem uma WHEN NOT MATCHED cláusula.

    • UsandoCURSOR, por exemplo, com uma DELETE cláusula MERGE with ou usando uma declaração de condição MERGE ON complexa.

  • AWS SCT pode adicionar acionadores de banco de dados à árvore de objetos quando a Amazon RDS é o destino.

  • AWS SCT pode adicionar gatilhos em nível de servidor à árvore de objetos quando a Amazon é o destino. RDS

  • SQLO servidor cria deleted e gerencia inserted tabelas 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 DML acionadoras. AWS SCT pode converter o uso dessas tabelas dentro de instruções de DML gatilho.

  • AWS SCT pode adicionar servidores vinculados à árvore de objetos quando a Amazon RDS for o destino.

  • Ao migrar do Microsoft SQL Server para o PostgreSQL, a SNAME função SUSER _ integrada é convertida da seguinte forma:

    • SUSER_ SNAME — Retorna o nome de login associado a um número de identificação de segurança (SID).

    • SUSER_ SNAME (<server_user_sid>) — Não suportado.

    • SUSER_ SNAME () CURRENT _ USER — Retorna o nome de usuário do contexto de execução atual.

    • SUSER_ SNAME (NULL) — DevoluçõesNULL.

  • 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.

  • PATINDEXretorna 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. <pattern character><expression character varying>Ao converter do SQL Server para o Amazon RDS para PostgreSQL, AWS SCT substitui o código do aplicativo usado por PATINDEX aws_sqlserver_ext.patindex (,).

  • No SQL Servidor, um tipo de tabela definido pelo usuário é um tipo que 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 Postgre SQL criando uma tabela temporária.

Ao converter do SQL Servidor para o PostgreSQL, AWS SCT converte objetos SQL do sistema do Servidor em objetos reconhecíveis no Postgre. SQL A tabela a seguir mostra como os objetos do sistema foram convertidos.

Casos de uso SQL do MS Server Substituição do Postgre SQL

SYS.SCHEMAS

AWS_SQLSERVER_EXT.SYS_SCHEMAS

SYS.TABLES

AWS_SQLSERVER_EXT.SYS_TABLES

SYS.VIEWS

AWS_SQLSERVER_EXT.SYS_VIEWS

SYS.ALL_VIEWS

AWS_SQLSERVER_EXT.SYS_ALL_VIEWS

SYS.TYPES

AWS_SQLSERVER_EXT.SYS_TYPES

SYS.COLUMNS

AWS_SQLSERVER_EXT.SYS_COLUMNS

SYS.ALL_COLUMNS

AWS_SQLSERVER_EXT.SYS_ALL_COLUMNS

SYS.FOREIGN_KEYS

AWS_SQLSERVER_EXT.SYS_FOREIGN_KEYS

SYS.SYSFOREIGNKEYS

AWS_SQLSERVER_EXT.SYS_SYSFOREIGNKEYS

SYS.FOREIGN_KEY_COLUMNS

AWS_SQLSERVER_EXT.SYS_FOREIGN_KEY_COLUMNS

SYS.KEY_CONSTRAINTS

AWS_SQLSERVER_EXT.SYS_KEY_CONSTRAINTS

SYS.IDENTITY_COLUMNS

AWS_SQLSERVER_EXT.SYS_IDENTITY_COLUMNS

SYS.PROCEDURES

AWS_SQLSERVER_EXT.SYS_PROCEDURES

SYS.INDEXES

AWS_SQLSERVER_EXT.SYS_INDEXES

SYS.SYSINDEXES

AWS_SQLSERVER_EXT.SYS_SYSINDEXES

SYS.OBJECTS

AWS_SQLSERVER_EXT.SYS_OBJECTS

SYS.ALL_OBJECTS

AWS_SQLSERVER_EXT.SYS_ALL_OBJECTS

SYS.SYSOBJECTS

AWS_SQLSERVER_EXT.SYS_SYSOBJECTS

SYS.SQL_MODULES

AWS_SQLSERVER_EXT.SYS_SQL_MODULES

SYS.DATABASES

AWS_SQLSERVER_EXT.SYS_DATABASES

INFORMATION_SCHEMA.SCHEMATA

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_SCHEMATA

INFORMATION_SCHEMA.VIEWS

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_VIEWS

INFORMATION_SCHEMA.TABLES

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_TABLES

INFORMATION_SCHEMA.COLUMNS

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_COLUMNS

INFORMATION_SCHEMA.CHECK_CONSTRAINTS

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_CHECK_CONSTRAINTS

INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_REFERENTIAL_CONSTRAINTS

INFORMATION_SCHEMA.TABLE_CONSTRAINTS

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_TABLE_CONSTRAINTS

INFORMATION_SCHEMA.KEY_COLUMN_USAGE

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_KEY_COLUMN_USAGE

INFORMATION_SCHEMA.CONSTRAINT_TABLE_USAGE

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_CONSTRAINT_TABLE_USAGE

INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_CONSTRAINT_COLUMN_USAGE

INFORMATION_SCHEMA.ROUTINES

AWS_SQLSERVER_EXT.INFORMATION_SCHEMA_ROUTINES

SYS.SYSPROCESSES

AWS_SQLSERVER_EXT.SYS_SYSPROCESSES

sys.system_objects

AWS_SQLSERVER_EXT.SYS_SYSTEM_OBJECTS