Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Índice

Informações

Este artigo aborda a migração de uma database Protheus+PostgreSQL com dados reais, porém pode ser usado com outros bancos de dados de destino. Neste documento também é mencionado o sizing utilizado para a migração. 

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?

Aviso
A escolha do software para banco de dados é do cliente e de seus times de TI; estes são soberanos em suas decisões. A documentação apresentada tem o propósito de Esta página tem como propósito encurtar alguns passos da migração, bem como solucionar possíveis dúvidas e antecipar alguns contratempos específicos ao banco de dados PostgreSQL.

Cenários que podem migrar para o PostgreSQL:

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 recomendável 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 erro error log.

Aviso
titleCláusulas especificas de bancos de dados

Em algumas customizações de SQL Server, é possível encontrar a cláusula With (NOLOCK). O tratamento de Locks no PostgreSQL é diferente, por isso, atente-se às queries escritas em customizações.

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 de migração, e verifique se não existem outros erros de da migração, e . Também disponibilize o ambiente para que os times de negócios e backoffice possam efetuar os efetuem seus testes , bem como verificar 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, para validar pois se migrou um novo Banco 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. 

Nota
titleAtenção - Ambiente a ser migrado
Durante o processo de homologação, não realize alterações no ERP ou no banco de dados. Isto inclui aplicações de patchs de correção que possam alterar qualquer forma de estrutura das tabelas. Desta forma, é possível garantir que o processo de homologação não terá discrepâncias da migração no ambiente de produção.

3. Produção: O time de TI deve se preparar e organizar para migrar, passa passado o período que foi avaliado 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

Nota
Antes de iniciar a migração, efetue a leitura das documentações sobre o DBTools e Migrador de Ambiente. Também confira os detalhes de como subir o PostgreSQL para ambiente produtivo.

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

Bloco de código
titleDBAccess.ini da base de destino - PostgreSQL
[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
Bloco de código
titleDBAccess.ini do ambiente origem - SQL Server
[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
Bloco de código
titleDBTools.ini
[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

utilizado

do ambiente de migração

Nota
titlePerformance de rede

Para melhor performance na migração, é importante que a rede para o tráfego TCP/IP esteja adequada; uma ferramenta que pode auxiliar na avaliação do ambiente de teste e homologação, neste cenário, é o IPERF.

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

Servidor

SQL Server

VM DBTools

PostgreSQL

Processador

8 Core

8 Core

8 Core

Memória RAM

32 GB

12 GB

32 GB

Rede

4Gbit

4Gbit

4Gbit

IOPS

1200

800

2000

Throughput máximo do disco (MBps)

300

200

400

Informações
titleInformações adicionais

O sizing utilizado é apenas destinado para migração entre os SGBDs, e não tem relação com o processamento dos módulos do ERP Protheus. 

Para a migração ser bem sucedida, é importante que os ambientes de teste e homologação sejam monitorados e o tempo para cada operação seja medido. Para o ambiente de destino, é importante se preocupar com a área temporária do banco de dados. Cenários provenientes do Oracle ou SQL Server podem ter um término menos eficiente se a área não estiver ajustada; conforme o processo ocorre, o destino sofre muitas alterações relacionadas aos comandos create table, insert into e create index. Por isso, é importante o monitoramento de DBA, para avaliar o consumo e auxiliar no processo conforme a experiência obtida com os ambientes de homologação e teste, para ser ajustada em produção.

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.