Convertendo um SQL Server em PostgreSQL - 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á.

Convertendo um SQL Server em PostgreSQL

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 AWS SCT pacotes de extensão.

Privilégios do PostgreSQL como um banco de dados de destino

Para usar o PostgreSQL como destino, a AWS SCT necessita do 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, substitua user_name pelo nome do seu usuário. Substitua, então, db_name pelo nome do banco de dados de destino. Por fim, substitua your_password 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 AWS SCT não 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 de conversão do SQL Server para PostgreSQL em 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. A 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 a 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, a AWS SCT pode converter procedimentos em perfis. 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:

    • <source_db> – Usa o nome do banco de dados SQL Server como o nome de um esquema no PostgreSQL.

    • <source_schema> – Usa o nome do esquema do SQL Server como o nome de um esquema no PostgreSQL.

    • <source_db>_<schema> – 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 <original_key_name>_<partition_number>.

  • 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 <original_index_name>_<partition_number>.

  • 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, a AWS SCT oferece a opção de gerar nomes de índice exclusivos se os seus 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 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. Quando a AWS SCT converte o código que contém uma instrução GOTO, ela converte a instrução para usar uma instrução BEGIN... END ou LOOP... END LOOP. Você pode encontrar exemplos de como a AWS SCT converte instruções GOTO na tabela a seguir.

    As instruções GOTO do SQL Server e as instruções PostgreSQL convertidas
    Instrução do SQL Server Instrução do PostgreSQL
    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 PostgreSQL não suporta uma instrução MERGE. A 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.

  • A AWS SCT poderá adicionar triggers de banco de dados à árvore do objeto quando o Amazon RDS for o destino.

  • A AWS SCT poderá adicionar triggers no nível do servidor à árvore do objeto quando o Amazon RDS for 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 trigger de DML. A AWS SCT pode converter o uso dessas tabelas em instruções de trigger de DML.

  • A AWS SCT poderá adicionar servidores vinculados à árvore do objeto quando o Amazon RDS for o destino.

  • Ao migrar do Microsoft SQL Server para PostgreSQL, a função SUSER_SNAME incorporada é 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>) – Sem suporte.

    • SUSER_SNAME CURRENT_USER () – Retorna o nome do usuário do contexto de execução atual.

    • SUSER_SNAME (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 para PostgreSQL, a AWS SCT substitui o código de aplicativo que usa PATINDEX por aws_sqlserver_ext.patindex(<pattern character>, <expression character varying>).

  • 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. Também é possível usar um tipo de tabela definido pelo usuário para declarar variáveis de tabela a serem usadas em um lote ou no corpo de um procedimento armazenado ou uma função. A AWS SCT emulou esse tipo no PostgreSQL ao criar uma tabela temporária.

Ao converter do SQL Server para PostgreSQL, a AWS SCT converte objetos do sistema do 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_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