Histórico da Página
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:
- 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 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 | ||
---|---|---|
| ||
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 | ||
---|---|---|
| ||
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, já 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 | ||
---|---|---|
| ||
[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 | ||
---|---|---|
| ||
[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 | ||
---|---|---|
| ||
[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
utilizadodo ambiente de migração
Nota | ||
---|---|---|
| ||
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 | |||
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 | ||
---|---|---|
| ||
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.