Sabemos o quanto é importante, nos dias de hoje, a escolha do SGBD (Sistema de gerenciamento de banco de dados) para uso com o ERP Protheus. No atual cenário, alguns clientes se encontram com bancos de dados no fim de ciclo de vida (EOF), e/ou com dificuldades financeiras para adquirir licenciamento de versões atualmente homologadas, ou mesmo para sair de cenários com versões express ou descontinuadas de outras versões.

O intuito deste documento é explicar como migrar o banco de dados para o PostgreSQL. O mesmo procedimento pode ser utilizado em outros tipos de migração; não haverão comparativos entre banco de dados e performance dos mesmos nesta ou em outras documentações, pois cada SGBD têm seus comportamentos e arquiteturas diferentes. Isto faz com que cada cenário possa demandar configurações e ajustes específicos; consequentemente, não faz sentido comparar os produtos de cada fornecedor. 

Antes de começar, está disponível um Step by Step para subir o PostgreSQL através deste artigo; a recomendação para o PostgreSQL, em cenários de produção, é que o software esteja em Linux. Não recomendamos o uso do PostgreSQL em produção em cenários de Windows.

Quais bancos podem migrar para o PostgreSQL?

Cenários que podem migrar para o PostgreSQL:

• Qualquer versão do SQL Server Express
• Qualquer versão do Oracle Express
• Qualquer versão DB2 (o ciclo de uso do Protheus com DB2 encerrou em 12/2020)
• Qualquer versão Informix (o ciclo de uso do Protheus com informix encerrou em 12/2020)
• Bancos que ainda tenham o suporte ativo
• Versões descontinuadas de SQL Server/Oracle que entraram no fim do ciclo de vida.

Dicas para a migração:

• Avalie a base de destino da migração. Ela está ajustada para uso com o Protheus e com as práticas recomendadas de mercado?
• Elabore o plano de teste. Quantas migrações serão necessárias para a migração total?

O mínimo recomendado são 3 períodos de migrações; porém, em alguns casos, foram necessárias apenas 2 migrações, já que a base era pequena e os dados estavam ajustados, facilitando a migração e não gerando nenhum tipo de error log.

1. Efetue o teste: esta é a primeira fase da migração. Neste momento, apenas utilize o DBTools para migrar, avaliar erros e processos necessários, bem como fazer os primeiros testes da aplicação.

2. Homologação: nesta fase, avalie o tempo e verifique se não existem outros erros da migração. Também disponibilize o ambiente para que os times de negócios e backoffice efetuem seus testes e verifiquem falhas de códigos ou de módulos customizados. Vale ressaltar que os módulos padrão já possuem suas queries ajustadas para os principais bancos de dados homologados (SQL Server, Oracle e PostgreSQL); porém, sempre recomendamos que os artefatos estejam em suas últimas versões ou sigam as recomendações de cada produto. Para que seja realizada uma migração de sucesso, compile as procedures novamente para validação, pois a migração resulta em um "novo" banco de dados. Após a validação, a pessoa responsável pela migração deverá gerar um relatório de todo o ambiente utilizado durante a homologação; desde os parâmetros de configuração do ambiente à configuração do banco de dados em si. Verifique, também, se a rede está configurada para Gigabit. Utilize a ferramenta IPERF para o diagnóstico da interface de rede, e para medir o throughput conforme a documentação. 

3. Produção: O time de TI deve se preparar e organizar para migrar, já passado o período de avaliação o tempo coletado no ambiente de homologação, o processo para produção não pode ocorrer erro, porém é necessário manter o mesmo ambiente sem qualquer alteração após as validações.

Realizando a migração

Onde encontrar o DBTools?

Dentro do diretório de instalação do DBAccess se encontra o diretório dbtools, conforme o print.

Exemplo de como migrar

O desenho a seguir representa a arquitetura utilizada para a migração da base, que tinha aproximadamente 600GB no SQL Server (compactada com a feature Data Compress). A VM de migração (VM Migração) é um Windows Server 2019, e possui os seguintes serviços instalados: DBAccess SQL Server; DBAccess PostgreSQL, DBTools. Os DBAccess são utilizados para conectar-se aos bancos de dados, e o ideal é que cada serviço acesse apenas um SGBD.

É importante que esta arquitetura esteja na mesma zona de processamento, para assegurar melhor conectividade e mitigar possíveis falhas relacionadas durante o processo.

Nos prints a seguir, são apresentadas as configurações de origem e destino dos dados pela ferramenta DBTools.

Abaixo, prints do DBMonitor de cada ambiente supracitado. 

Exemplos dos arquivos de configuração do DBAccess (DBAccess.ini) utilizados para o processo migratório entre SGBDs. Também está incluso o arquivo de configuração do DBTools (dbtools.ini):

[General]
port=7899
ThreadInfo=0
LogFull=0
GlbProfiler=0
ThreadMin=100
ThreadMax=10000
ThreadInc=200

[Service]
Name=DBAccessPostgreSQL
DisplayName=...TOTVS | DBAccess PostgreSQL

[POSTGRES/tpprd]
user=tpprd
password=œðö¼
TableSpace=tpprd_data
IndexSpace=tpprd_data

[POSTGRES]
environments=tpprd

[General]
port=7898
ThreadInfo=0
LogFull=0
GlbProfiler=0
ThreadMin=100
ThreadMax=1000
ThreadInc=200
LicenseServer=
LicensePort=0

[Service]
Name=DBAccessSQLServer
DisplayName=...TOTVS | DBAccess SQLServer

[MSSQL/tpprdsql]
user=tpprdsql
password=œðö¼±´
TableSpace=
IndexSpace=

[MSSQL]
environments=tpprdsql

[general]
threads=0
overwrite=0
resume=0
copydeleted=1
copyempty=1
createindex=1
errorstop=0
keeprecno=1
copymask=%
ignoremask=%BKP,%LOG

[sourcedb]
dbserver=10.171.231.101
dbport=7898
dbdatabase=MSSQL
dbalias=TPPRDSQL
dbuser=
dbpsw=

[targetdb]
dbserver=10.171.231.101
dbport=7899
dbdatabase=POSTGRES
dbalias=TPPRD
dbuser=
dbpsw=

Para maiores detalhes dos parâmetros, consulte a documentação do DBTools e a do Migrador de Ambiente.

Sizing do ambiente de migração

A tabela a seguir apresenta algumas especificações das bases migradas no exemplo acima.

Neste cenário, o tempo previsto estava em torno de 5h38min para migrar em torno de 600GB usando as configurações supracitadas. O tráfego de rede é um dos fatores importantes para a migração; no ambiente de destino, além do tráfego de rede, é necessário levar em consideração a taxa de IOPS, que será consumida.