Tempo aproximado para leitura: 00:01:00 min
Dúvida
Como fazer o MIGRADOR Documento técnico de apoio - Migrador Oracle Winthor?
Ambiente
TOTVS Distribuição Linha Winthor - 0 - Framework - Todas as versões
Solução
Para documento com detalhamento para organizar e compactar arquivos de instalação a serem utilizados na migração On Premise x Edge, realize os seguintes passos:
1. Informações sobre o Procedimento;
2. Histórico do Documento;
3. Versão;
4. Objetivo;
Descrever o procedimento para apoio na geração do backup e do arquivo .csv no banco de origem para migração para a Cloud TOTVS.
5. Procedimento;
Backup do Banco
Para fazer a migração para a Cloud TOTVS usando o migrador deve ser gerado o backup e um arquivo .csv com algumas informações da estrutura do banco de dados de origem.
Legenda dos parâmetros do expdp do bloco acima:
- nohup: o uso do "nohup" com o "&" no final vai manter o processo em execução em segundo plano mesmo que a sessão que iniciou seja desconectada no sistema operacional. O nohup devera ser utilizado somente no Linux.
- expdp: é o comando do Datapump que faz o backup do banco e deve ser executado no servidor onde a instância está sendo executada. O "USUARIO_BD" deve ser um usuário do banco de dados que tenha privilégio para se conectar no banco de dados e executar o expdp. O "IP_SERVIDOR_BD" é o IP do servidor onde o banco está sendo executado. A "PORTA_BD" é a porta em que está configurada o listener do banco, a porta padrão do Oracle é a 1521. O "SERVICE_BD" é o serviço do banco de dados que está sendo usado para receber as conexões.
- SCHEMAS: nesse parâmetro deve ser informado o schema usado pelo Winthor.
- DIRECTORY: nesse parâmetro deve ser informado o objeto diretório do banco de dados onde será armazenado os arquivos de backup e log gerados no expdp.
- DUMPFILE: nesse parâmetro deverá ser informado o nome dos arquivos de dump gerados no expdp, sempre seguindo o padrão "EXPDP_CCODE_WINTHOR_%U.dmp", onde o CCODE é o código cloud do cliente, que é um identificador único de 6 dígitos.
- LOGFILE: nesse parâmetro deverá ser informado o nome do arquivo de log gerado no expdp, sempre seguindo o padrão "EXPDP_CCODE_WINTHOR.log", onde o CCODE é o código cloud do cliente, que é um identificador único de 6 digitos.
- FILESIZE: esse parâmetro define o tamanho dos arquivos de dump gerado nos backups e por padrão deve ser mantido o valor de "10G".
- CLUSTER: esse parâmetro deve ser mantido com o valor "NO". Ele garante que caso o banco esteja sendo executado em um RAC, o expdp seja executado sempre em uma única instância.
- EXCLUDE: esse parâmetro sempre deverá conter o valor "STATISTICS", pois será feito feita uma coleta de estatísticas no banco de destino no final da migração.
- PARALLEL: nesse parâmetro deve ser informado o número do paralelismo a ser usado durante a execução do expdp. Em servidores dedicados para a instância que está sendo feito o backup, caso a aplicação esteja parada para a migração deve-se ser usado o número de cores do servidor como valor do parâmetro. Caso esteja sendo executado um backup para a homologação, com a aplicação online, deve-se usar de 20% a 40% da quantidade de cores do servidor, dependendo do workload do ambiente, para não gerar impactos relacionados a performance. Na edição Standard do Oracle não é possível usar executar o datapump usando paralelismo.
- FLASHBACK_TIME: nesse parâmetro sempre deve ser informado o valor "SYSTIMESTAMP". Ele vai garantir a consistência dos dados durante o momento execução do expdp. Ao usar esse parâmetro os registros ficaram retidos na área de UNDO do Oracle durante o expdp e caso não haja área de UNDO suficiente durante o processo, será retornada a mensagem "snapshot segment too old" e ocorrerá a falha no processo. Quando se estiver executando o expdp em um banco com a aplicação online o ideal é acompanhar a área de UNDO durante o processo. Em versão anteriores a 12.1, o parâmetro "FLASHBACK_TIME=SYSTIMESTAMP" deve ser substituído pelo parâmetro "CONSISTENT=Y", que tem exatamente a mesma função em versões anteriores a 12.1 do Oracle.
Geração do arquivo .csv
Junto com os arquivos de backup e o arquivo de log gerados no step anterior, deverá ser gerado um arquivo .csv com algumas informações da estrutura do banco que serão interpretadas pela orquestração no momento do import do backup no ambiente de destino, na Cloud TOTVS.
Para gerar esse arquivo .csv basta copiar o script "migrador_oracle_totvs_winthor.sql" abaixo para o servidor onde está sendo executado o banco que será migrado, conectar no banco com um usuário que tenha privilégio de leitura nos objetos v$instance, dba_segments e dba_users, que são views e tabelas do dicionário do Oracle, e executar o script de acordo com anexo abaixo: Migrador.
Para executar o script basta se conectar no banco via sqlplus e passar o o caractere "@" mais o diretório onde está o script e o nome do script, como no exemplo abaixo:
Durante a execução do script será solicitado informar o nome do schema usado pelo Winthor.
Após a execução do script, será gerado um arquivo .csv chamado "migrador_totvs_winthor.csv" no mesmo diretório onde o sqlplus foi executado para se conectar ao banco e executar o script.
Esse arquivo "migrador_totvs_winthor.csv" obrigatoriamente deve ser enviado junto com os arquivos de backup e log do datapump.
Envio dos arquivos
Para enviar os arquivos gerados nos steps anteriores, deve ser gerado um arquivo chamado BACKUP.zip em que todos os arquivos obrigatoriamente devem estar na raiz.
No linux esse arquivo pode ser gerado usando o comando zip, como mostra o exemplo abaixo:
No Windows, basta criar a pasta, clicar com o botão direito do mouse e mandar comprimir com o formato .zip.
Para envio do arquivo BACKUP.zip, basta acessar o passo a passo do documento T-Cloud - Migrador
Saiba Mais
0 Comentários