---
sourceDocument: Criar ou modificar aplicações do Xanadu
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/pt-BR/xanadu/application-development

 Release :

    - xanadu

ft:locale :

    - pt-BR

ft:publication_title :

    - Criar ou modificar aplicações do Xanadu

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Creator


---

# Comparar conjuntos de atualizações locais

# Comparar conjuntos de atualizações locais {#ariaid-title1}

* Versão de lançamento: Xanadu
* 
* Atualizado 1 de ago. de 2024
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 min. de leitura

Os administradores podem visualizar conjuntos de atualizações locais e remotos (recuperados) e comparar os conjuntos entre si para resolver mudanças conflitantes.

## Por Que e Quando Desempenhar Esta Tarefa

Compare conjuntos de atualizações locais para identificar colisões e garantir que as mudanças apropriadas estejam sendo confirmadas. Resolva todos os conflitos antes de mover um conjunto de atualizações entre instâncias.

## Procedimento

1. Navegar até TodosConjuntos de atualizações do sistemaConjuntos de atualizações locais.
2. Marque as caixas de seleção ao lado dos conjuntos de atualizações a serem comparados.
3. Na lista de seleção Ação, selecione Comparar conjuntos de atualizações.  
   A tela de andamento aparece quando ServiceNow gera o relatório de colisão.Figura 1. Relatório de colisão
4. Clique em Ir para o relatório de colisão quando o relatório estiver concluído.  
   A lista Colisões de conjunto de atualizações é exibida, mostrando todas as mudanças nos conjuntos selecionados.
5. Inspecione a lista em busca de colisões localizando Números de Colisão duplicados que mostram a mesma mudança em conjuntos de atualizações separados.  
   Figura 2. Colisões de conjunto de atualizações
6. Resolva a colisão excluindo o registro de atualização indesejado de um dos conjuntos de atualizações.  
   1. Clique no link na coluna Atualização do sistema para a atualização indesejada (`sys_ui_list_incident_null` no exemplo).
   2. Clique em Excluir.  
      Nota:  
      Você deve abrir o registro de atualização para excluir o registro. Você não pode excluir a atualização marcando a caixa de seleção da entrada na lista Colisões do conjunto de atualizações e usando a ação Excluir. Quando você exclui o registro de atualização, a personalização não é revertida da instância. Somente o registro da personalização é excluído.  
      Figura 3. Atualizações do cliente
   {#t_CompareLocalUpdateSets__ol_rs2_rnn_vp}
7. Execute a comparação novamente para garantir que todas as colisões tenham sido resolvidas.

## Resolução de colisão do conjunto de atualizações {#ariaid-title2}

Uma colisão é uma atualização que tem uma atualização local mais recente.
A plataforma detecta colisões comparando os valores nos campos Nome e Atualizado do registro de atualização do cliente de cada conjunto de atualizações. Se o nome corresponder, mas houver valores de data de atualização diferentes, haverá uma colisão.

Quando uma atualização de cliente é movida de uma instância para outra, ela pode ser reescrita para corresponder à instância de destino. A reescrita pode envolver a mudança do nome da atualização do cliente e um ou mais `sys_id`s na atualização. As regravações são feitas quando o registro ou o campo de referência é para uma tabela que usa uma estratégia de aglutinação. Isso garante que a atualização do cliente seja aplicada ao registro correto. Por exemplo, se o registro `sys_dictionary` para `tablename.fieldname` tiver `sys_id` `123456789` na instância A e `sys_id` `987654321` na instância B, quando uma atualização do cliente que se refere a esse registro for recuperada da instância A e registrada na tabela sys_update_xml na instância B, as referências a `123456789` são atualizados para ler `987654321`.

### Aglutinar estratégias

Os conjuntos de atualizações podem detectar colisões entre registros idênticos que você cria independentemente em instâncias separadas. Para detectar essas colisões, o registro deve ter uma estratégia de aglutinação com base em colunas de aglutinação. Como a detecção de colisão depende da exclusividade das tabelas, as tabelas devem ser exclusivas quando as colunas de aglutinação são combinadas. Os registros que não estão listados aqui não colidirão se o mesmo registro for criado separadamente em instâncias diferentes.  

|-|-|
| Tipo | Colunas de aglutinação |
| sys_db_object | nome |
| sys_dictionary | nome, elemento |
| sys_choice_set | nome, elemento, idioma |
| sys_documentation | nome, elemento, idioma |
| sys_properties | nome |
| sys_report_chart_color | nome, elemento, valor |
| sys_ui_form | nome, exibição, sys_domain |
| sys_ui_message | documentkey, idioma |
| sys_ui_list | nome, exibição, sys_domain, elemento, relacionamento, primário |
| sys_ui_section | nome, exibição, legenda, sys_domain |
| sys_ui_related_list | nome, exibição, related_list, sys_domain |
| sys_ui_view | nome |
| sys_user_role | nome |
| sys_user_group | nome |
| sys_wizard | nome |
[ ]

{#update-set-collisions__table_krr_4wp_yq}

### Como os nomes de registro de atualização do cliente afetam as colisões

Para entender a aglutinação, é útil entender como os registros que não são aglutinados funcionam. Para a maioria dos tipos de registro, quando uma atualização de cliente é movida para uma nova instância, o sistema não detecta colisões pelo seguinte motivo:

* Quando você cria um registro, ele recebe um sys_id exclusivo. Para a maioria dos tipos de registro, o sys_id se torna parte do nome do registro de atualização do cliente. Por exemplo: `sysevent_email_template_9e1998c078b71100a92ecacd80df1d39`.
* Criar um registro idêntico na mesma tabela em outra instância produz um nome de registro de atualização de cliente com um sys_id diferente. Por exemplo: `sysevent_email_template_10b958c86533311005840134572f8e020`
{#update-set-collisions__ul_cld_zpz_py}

Como resultado, mesmo que os registros possam ser idênticos, eles têm nomes diferentes para que o sistema não detecte a colisão.  
A aglutinação de registros, por outro lado, usa a seguinte abordagem para nomear registros e determinar colisões: os seguintes tipos de registro de atualização do cliente usam algumas ou todas as colunas de aglutinação em vez do sys_id em seus nomes.

* sys_dictionary
* sys_documentation
* sys_choice_set
* sys_ui_list
* sys_ui_related_list
{#update-set-collisions__ul_bzm_mqz_py}

O nome de registro idêntico resultante em cada instância ajuda o sistema a identificar colisões, mesmo se os registros tiverem sys_ids diferentes.

Quando uma atualização de cliente é movida de uma instância para outra, ela pode ser reescrita para corresponder à instância de destino. A reescrita pode envolver a mudança do nome da atualização do cliente e um ou mais sys_ids na atualização. As regravações são feitas quando o registro ou o campo de referência é para uma tabela que usa uma estratégia de aglutinação. Isso garante que a atualização do cliente seja aplicada ao registro correto. Por exemplo, se o registro sys_dictionary para tablename.fieldname tiver sys_id "123456789" na instância A e sys_id "987654321" na instância B, quando uma atualização do cliente que se refere a esse registro for recuperada da instância A e registrada na tabela sys_update_xml na instância B, as referências a "123456789" são atualizadas para "987654321".

### Impedindo registros duplicados

* Transfira dados com conjuntos de atualizações em vez de recriá-los em instâncias separadas para garantir que os registros tenham o mesmo sys_id.
* Exporte e importe registros como arquivos XML para garantir que os registros tenham o mesmo sys_id. Consulte [Exportação e importação de arquivos XML](https://www.servicenow.com/docs/access?context=c_ExportAndImportXMLFiles&version=xanadu&pubname=xanadu-platform-administration&ft:locale=en-US).
* Habilite um índice exclusivo para a tabela do dicionário do sistema. Consulte [Administração de tabela](https://www.servicenow.com/docs/access?context=c_TableAdministration&version=xanadu&pubname=xanadu-platform-administration&ft:locale=en-US).

{#update-set-collisions__ul_elx_v4n_vp}  
Nota:  
Os registros padrão incluídos no sistema de linha de base sempre terão o mesmo SYS ID porque a instância importa os registros como arquivos XML durante o provisionamento da instância.