Otimizar o sistema de origem - avançado
Divisão da tabela Oracle Row ID
A SAP lançou o SAP Note #1043380, que contém um script que converte a cláusula WHERE em um arquivo WHR em um valor ROW ID. Como alternativa, as versões mais recentes do SAPInst geram automaticamente arquivos WHR divididos por ID de linha se o SWPM estiver configurado para migração Oracle para Oracle R3load. Os arquivos STR e WHR gerados pelo SWPM são independentes do sistema operacional e do banco de dados (assim como todos os aspetos do processo de migração do sistema operacional/banco de dados).
A nota OSS contém a instrução "ROWID table splitting CANNOT be used if the target database for um banco de dados não-Oracle". Tecnicamente, os arquivos de despejo R3load são independentes do banco de dados e do sistema operacional. Há uma restrição, no entanto, a reinicialização de um pacote durante a importação não é possível no SQL Server. Nesse cenário, a tabela inteira precisa ser descartada e todos os pacotes para a tabela reiniciados. É sempre recomendável matar tarefas R3load para uma tabela dividida específica, TRUNCATE a tabela e reiniciar todo o processo de importação se uma divisão R3load abortar. A razão para isso é que o processo de recuperação incorporado ao R3load envolve a execução de instruções DELETE linha por linha para remover os registros carregados pelo processo R3load que aborta. Isso é lento e geralmente causará situações de bloqueio/bloqueio no banco de dados. A experiência mostrou que é mais rápido iniciar a importação desta tabela específica desde o início, portanto, a limitação mencionada no SAP Note #1043380 não é uma limitação.
O ID DE LINHA tem uma desvantagem, pois o cálculo das divisões deve ser feito durante o tempo de inatividade – consulte a Nota SAP #1043380.
Crie vários "clones" do banco de dados de origem e exporte em paralelo
Um método para aumentar o desempenho de exportação é exportar de várias cópias do mesmo banco de dados. Se a infraestrutura subjacente, incluindo servidores, rede e armazenamento, for escalável, essa abordagem tende a ser linearmente escalável. Exportar de duas cópias do mesmo banco de dados é duas vezes mais rápido, quatro cópias é quatro vezes mais rápido. O Monitor de Migração está configurado para exportar em um número selecionado de tabelas de cada "clone" do banco de dados. No caso a seguir, a carga de trabalho de exportação é distribuída aproximadamente 25% em cada um dos quatro servidores de banco de dados.
- Servidor de banco de dados 1 & servidor de exportação 1 – dedicado às maiores tabelas de 1 a 4 (dependendo de quão distorcida é a distribuição de dados no banco de dados de origem)
- Servidor de banco de dados 2 & servidor de exportação 2 – dedicado a tabelas com divisões de tabela
- Servidor de banco de dados 3 & servidor de exportação 3 – dedicado a tabelas com divisões de tabela
- Servidor de banco de dados 4 & servidor de exportação 4 – todas as tabelas restantes
Deve-se tomar cuidado para garantir que os bancos de dados sejam sincronizados com precisão, caso contrário, podem ocorrer perda ou inconsistências de dados. Se as etapas fornecidas forem seguidas com precisão, a integridade dos dados será preservada.
A técnica é simples e barata com hardware Intel commodity padrão, mas também é possível para clientes que executam hardware UNIX proprietário. Recursos de hardware substanciais ficam livres no meio de um projeto de migração de SO/DB quando os sistemas Sandbox, Desenvolvimento, QAS, Treinamento e DR já foram movidos para o Azure. Não há nenhum requisito estrito de que os servidores "clonados" tenham recursos de hardware idênticos. Com desempenho adequado de CPU, RAM, disco e rede, a adição de cada clone aumenta o desempenho.
Se ainda for necessário um desempenho de exportação adicional, abra um incidente SAP no BC-DB-MSS para obter etapas adicionais para aumentar o desempenho da exportação (somente consultores avançados).
As etapas para implementar uma exportação paralela múltipla são as seguintes:
- Faça backup do banco de dados primário e restaure em "n" número de servidores (onde n = número de clones). Para este exemplo, suponha n = 3 servidores, totalizando quatro servidores de banco de dados.
- Restaure o backup em três servidores.
- Estabeleça o envio de logs do servidor de banco de dados de origem primária para três servidores "clonados" de destino.
- Monitore o envio de logs por vários dias e garanta que o envio de logs esteja funcionando de forma confiável.
- No início do tempo de inatividade, desligue todos os servidores de aplicativos SAP, exceto o PAS. Verifique se todo o processamento em lote foi interrompido e todo o tráfego de RFC foi interrompido.
- Na transação SM02, digite o texto "Checkpoint PAS em execução". Esta tabela de atualizações TEMSG.
- Pare o servidor de aplicativos primário. A SAP está encerrada. Nenhuma atividade de gravação pode ocorrer mais no banco de dados de origem. Certifique-se de que nenhum aplicativo não-SAP esteja conectado ao banco de dados de origem (nunca deve haver, mas verifique se há sessões não-SAP no nível de banco de dados).
- Execute esta consulta no servidor de banco de dados primário:
SELECT EMTEXT FROM [schema].TEMSG; - Execute a instrução de nível DBMS nativa:
INSERT INTO [schema].TEMSG “CHECKPOINT R3LOAD EXPORT STOP dd:mm:yy hh:mm:ss”(a sintaxe exata depende do DBMS de origem. INSERIR em EMTEXT) - Interrompa os backups automáticos do log de transações. Execute manualmente um backup final do log de transações no servidor de banco de dados primário. Verifique se o backup de log foi copiado para os servidores clonados.
- Restaure o backup final do log de transações nos três nós.
- Recupere o banco de dados nos 3 nós "clonados".
- Execute a seguinte instrução SELECT em todos os quatro nós:
SELECT EMTEXT FROM [schema].TEMSG; - Capture os resultados da tela da instrução SELECT para cada um dos quatro servidores de banco de dados (o primário e os três clones). Certifique-se de incluir cuidadosamente cada nome de host – para servir como uma prova de que o banco de dados clonado e o primário são idênticos e contêm os mesmos dados do mesmo ponto no tempo.
- Inicie export_monitor.bat em cada servidor de exportação Intel R3load.
- Inicie a cópia do arquivo de despejo para o processo do Azure (AzCopy ou Robocopy).
- Inicie import_monitor.bat nas VMs do Azure R3load.
O diagrama a seguir mostra um envio de log do servidor de banco de dados de produção existente para bancos de dados "clonados". Cada servidor de banco de dados tem um ou mais servidores Intel R3load.
