Solução de problemas de desempenho do conjunto de importação
Revise esses problemas de desempenho para solucionar problemas e melhorar o desempenho dos trabalhos de conjunto para importação.
Execução de regras de negócio durante a transformação
A execução de regras de negócio durante a transformação pode fazer com que a transformação demore mais do que o esperado ou fazer com que a instância fique mais lenta.
Torna-se um problema: ao importar uma quantidade muito grande de dados. Por exemplo, importar todos os dados de um sistema antigo.
Sinais: a transformação demora muito mais do que o esperado. Além disso, a instância inteira pode estar lenta durante esse tempo.
Scripts de transformação lenta
O uso de várias consultas GlideRecord ou loops grandes pode tornar os scripts de transformação mais lentos.
Torna-se um problema: quando os scripts de transformação estão usando várias consultas GlideRecord ou percorrendo grandes coleções de objetos para cada linha. Esse problema pode aparecer quando o script de transformação não é eficiente. Na maioria dos casos, os objetivos de script podem ser realizados usando a funcionalidade interna na aplicação Conjunto para importação. Por exemplo, você pode criar scripts de aglutinação que diferenciam maiúsculas de minúsculas em vez de escrever scripts que usam consultas GlideRecord. As consultas GlideRecord normalmente tornam a importação mais lenta.
Sinais: a transformação leva muito mais tempo do que o esperado. Dependendo do script, a instância inteira pode ficar lenta durante esse tempo.
Como evitar isso: use a funcionalidade do sistema de base sempre que possível em vez de escrever scripts personalizados e, se você escrever scripts, evite escrever scripts complicados que usam consultas GlideRecord.
Importando dados que não mudaram
A importação repetida de dados que não foram alterados resulta em muitas linhas ignoradas.
Torna-se um problema: quando você está importando dados de uma tabela muito grande e a maioria dos registros não é atualizada regularmente.
Problemas: o conjunto de importação demora mais do que o esperado. Em , espere ver uma importação com uma Contagem total muito alta com uma Contagem ignorada que também é muito alta - isso é encontrado na coluna Mensagem. Indicando que a maioria dos registros importados não foi realmente alterada. Esses registros não precisaram ser importados.
Como evitar isso: se você estiver executando uma importação JDBC, use a opção de data/hora da última execução na fonte de dadosdo conjunto de importação. Para um tipo de importação de arquivo, certifique-se de que o que quer que esteja gerando seus arquivos esteja adicionando somente dados novos ou que foram alterados.
Aglutinação em campos não indexados
A aglutinação em campos não indexados com uma grande quantidade de dados pode fazer com que as transformações sejam mais lentas.
Torna-se um problema: ao corresponder em campos que não estão indexados, isso faz com que a fase de transformação de uma importação seja executada lentamente. No entanto, isso só se torna um problema se houver uma quantidade grande de dados. Em casos extremos, isso causa problemas de desempenho com o banco de dados devido à carga adicional.
Problemas: o tempo gasto na fase de transformação da importação é grande em relação ao tempo necessário para carregar os dados. Espere ver tempos de transformação altos.
Como evitar isso: se possível, você deve aglutinar em um campo exclusivo e já indexado. Para determinar se um campo já está indexado, navegue até e localize a tabela. Na lista de colunas dessa tabela, uma coluna indexada terá um ícone azul com um i ao lado se estiver indexada. Para obter assistência na indexação de um campo, entre em contato com o ServiceNow Suporte técnico.
Executando importações simultaneamente
Executar importações simultaneamente pode causar carga excessiva no banco de dados.
Torna-se um problema: a importação de grandes quantidades de dados coloca uma carga adicional no banco de dados. Por exemplo, importar 500.000 usuários e 200.000 itens de configuração ao mesmo tempo. Isso pode ter um impacto significativo no desempenho em todas as consultas no sistema devido ao aumento da carga no banco de dados. Esse problema é especialmente grave quando duas importações estão sendo importadas para a mesma tabela. Nesse caso, há um possível problema de contenção para a tabela. Além disso, dependendo de qual tabela está envolvida no processamento, isso pode prejudicar gravemente o desempenho da importação e da instância.
Problemas: várias importações simultâneas em execução combinadas com carga no banco de dados. Você vê um grande número de inserções e atualizações; e se houver carga ou contenção suficiente, tempos de espera de E/S altos.
Como evitar isso: escalone suas importações para que elas não se sobreponham.
Tabelas de conjunto de importação grande
A falha na limpeza das tabelas de conjunto de importação pode fazer com que essas tabelas fiquem desordenadas e lentas.
Torna-se um problema: quando o trabalho de exclusão do conjunto de importação não está em execução.
Sinais: trata-se de um problema de tamanho. Se os conjuntos para importação não forem limpos regularmente (uma limpeza é recomendada após sete dias de dados), a tabela será preenchida, fazendo com que as importações sejam interrompidas.
Como evitar isso: verifique se o trabalho de exclusão do conjunto de importação está em execução. Se ele não estiver em execução no momento, entre em contato com Suporte e atendimento ao cliente, pois eles truncarão todas as tabelas de conjunto de importação antes de habilitar este trabalho.
Como alterar o esquema da tabela durante a importação
Alterar o esquema da tabela, por exemplo, importando uma nova coluna, bloqueia a tabela de conjunto de importação.
Torna-se um problema: sempre que uma nova coluna é importada, toda a tabela de conjunto de importação é bloqueada durante essa mudança de esquema e, dependendo do tamanho da tabela, pode levar entre cinco e dez minutos. Durante esse tempo, nenhum dado pode ser selecionado ou inserido. Se essa tabela não for usada com frequência, isso poderá não causar problemas. No entanto, se essa tabela for usada com frequência, por exemplo, a tabela de importação LDAP, poderão surgir problemas.
Sinais esintomas: os sintomas deste problema podem variar. Em nosso exemplo da tabela de importação LDAP, todas as transações que exigem uma consulta da tabela de importação LDAP terão que aguardar até que a mudança de esquema seja concluída.
Como evitar isso: truncar a tabela de importação antes de importar com uma nova coluna.
Importação de conjuntos de dados muito grandes
Importar um conjunto de dados muito grande leva mais tempo do que importar vários conjuntos de dados menores.
Torna-se um problema: quando conjuntos de dados muito grandes são importados em um único trabalho.
Problemas: o trabalho de importação leva muito tempo para ser concluído.
Como evitar isso: divida um conjunto de dados muito grande em vários trabalhos menores para obter resultados mais rápidos. Considere como diretriz os conjuntos para importação com menos de 100.000 registros. Por exemplo, a importação de 10 conjuntos de 100.000 registros é concluída mais rapidamente do que uma importação de 1 milhão de registros, embora o total de dados importados seja o mesmo.
Importações de dados grandes com muitos campos de referência
A importação de um alto volume de dados com muitas referências para resolver pode demorar mais do que o esperado ou fazer com que o banco de dados fique mais lento.
Torna-se um problema: ao usar um mapa de transformação para importações de dados de alto volume com muitos campos de referência.
Sinais: a transformação demora muito mais do que o esperado. Durante a importação, o banco de dados inteiro fica mais lento.
Como evitar isso: use armazenamento secundário para pesquisar referências. O armazenamento secundário usa um banco de dados secundário para resolução de referência. Ele permite que algumas consultas de leitura sejam redirecionadas para o banco de dados secundário, reduzindo a carga no banco de dados primário.
- Ative o plug-in Pools de bancos de dados secundários [com.glide.secondary_db_pools]. Para obter mais informações, consulte Request a plugin.
- Confirme se a categoria import_reference_resoultion na tabela Categorias de banco de dados secundários [sys_db_category] foi configurada e habilitada. Quando você solicita o plug-in, o suporte ServiceNow configura essa categoria para você.
Depois que o plug-in for ativado e sua categoria de armazenamento secundário tiver sido configurada e habilitada, haverá uma caixa de seleção Usar armazenamento secundário para referências no formulário para Crie um mapa de transformação. Use esta caixa de seleção para habilitar ou desabilitar o armazenamento secundário.
Ao usar o armazenamento secundário, defina o campo Ação de opção no mapa de campos para ignorar ou rejeitar. Definir a ação Opção como criar pode fazer com que várias cópias de um registro sejam criadas porque a resolução de referência não detecta registros recém-criados imediatamente. Para obter mais informações sobre ações de escolha, consulte Crie um mapa do campo.
Um banco de dados secundário está sempre um pouco desatualizado em comparação com o banco de dados primário. Se a importação exigir dados totalmente atualizados, não use o armazenamento secundário.