A reconciliação de uma versão é lenta ou eige muito tempo para ser concluída

Descrição

Ao realizar uma reconciliação, ocasionalmente o processo de reconciliação é lento ou eige muito tempo para ser concluído.

Ao realizar uma reconciliação, é importante entender o processo de como a reconciliação é executada internamente e o motivo do fluxo de trabalho de uma organização possa ter um impacto significativo no desempenho de uma reconciliação.

Nota: Este artigo refere-se às versões do ArcGIS 8.x e 9.x. Versões posteriores do ArcGIS podem conter diferentes funcionalidades, bem como diferentes nomes e locais para menus, comandos e ferramentas de geoprocessamento.

Causa

Durante uma reconciliação, todas as edições realizadas na versão de origem, a versão sendo editada e reconciliada com uma versão de destino, sendo a versão de destino a versão primária ou a versão DEFAULT, são copiadas para a versão de destino e quaisquer conflitos são detectados e apresentados por meio da caixa de diálogo de resolução de conflitos.

O tempo que leva para executar a reconciliação depende do número de edições. Para entender melhor o motivo disto depender do número de edições, entenda a árvore de estados do geodatabase versionado.

Cada edição que ocorre em um geodatabase versionado é identificada exclusivamente por um state_id. A coleção de estados em um geodatabase versionado é denominada árvore de estado, e cada estado participa de uma linhagem de estados que se origina do estado 0, o estado básico. Cada linhagem na árvore de estado representa diferentes sessões de edição ou diferentes versões.

O único relacionamento da árvore de estado com uma versão é o estado ao qual a versão faz referência. No entanto, a hierarquia de versões influencia quais versões podem ser reconciliadas entre si. A reconciliação pode ser realizada somente em uma versão para um predecessor direto, como a versão primária ou a versão anterior à primária, etc.

Isso não mostra, no entanto, a história completa de como as versões se relacionam aos estados de geodatabase. No seguinte exemplo, observe que a versão Editor2 é uma versão secundária, criada a partir da versão Trans_mnt, mas a estrutura da árvore de estado e como as versões correspondem a estados específicos não são visíveis.

Nesta hierarquia, Editor1 pode reconciliar com Trans_mnt ou DEFAULT.

Ao reconciliar uma versão com uma versão de destino, todas as edições na linhagem da versão de origem, que não são comuns à linhagem da versão de destino, são copiadas para um novo estado na linhagem da versão de destino. No seguinte exemplo, Trans_mnt e Editor1 têm um estado predecessor comum, o estado 40.

Aqui podemos verificar que as linhagens para as versões são:

• Trans_mnt: 0, 40, 41, 52
• Editor1: 0, 40, 78, 92, 97
• Editor2: 0, 40, 56

O estado mais alto é comum na linhagem de ambas as versões. As edições não conflitantes para os estados 78, 92 e 97 são cada uma copiadas para a linhagem da versão de destino. Os estados exclusivos da linhagem do Editor1 (78, 92 e 97) são copiados para um novo estado na linhagem do Trans_mnt. O novo estado no geodatabase é o estado 99.

O diagrama acima não indica quantas edições existem nos estados 78, 92 e 97. Se houver apenas uma edição para uma classe de feição por estado, então o estado de reconciliação, 99, conterá apenas as três edições realizadas nos estados 78, 92 e 97, resultando em 3 novas linhas nas classes de feição adicionando e excluindo tabelas.

No entanto, se as 50.000 feições forem atualizados para o estado 92, então, durante o processo de reconciliação, todas as 50.000 edições deverão ser copiadas para o estado 99 e inseridas nas classes de feição, adicionndoa e excluindo tabelas. Portanto, haveria 50.000 edições para o estado 92 e outras 50.000 edições para o estado 99.

Além disso, o geodatabase deve identificar alterações entre as duas linhagens da versão para identificar conflitos durante uma reconciliação. Os conflitos são categorizados nos seguintes grupos:

• Atualizações/Atualizar conflitos.
• Atualizar/Excluir conflitos.
• Excluir/Atualizar conflitos.

As edições que não são conflitantes ou relacionadas aos objetos que estão em conflito são copiadas para o estado de reconciliação da versão de destino. As edições que estão em conflito são exibidas na caixa de diálogo da resolução de conflito.

O número de edições na linhagem da versão de origem afeta o desempenho da reconciliação.

Os fluxos de trabalho devem levar em conta adequadamente essas situações.

Solução ou Solução Provisória

Ao trabalhar com um geodatabase versionado, o fluxo de trabalho para criar e reconciliar versões é muito importante. Com várias versões secundárias de uma versão primária, a ordem de reconciliar e postar as versões secundárias na versão primária também é importante.

Se a versão de destino não foi modificada desde que a versão de origem foi criada e editada, o processo de reconciliação não precisa copiar nenhuma modificação, pois cada versão compartilha a mesma linhagem. Nesses casos, se o usuário postar após executar a reconciliação, as versões de origem e destino serão atualizadas para fazer referência ao mesmo estado do banco de dados.

No seguinte exemplo, a versão Trans_mnt, ou a versão primária, não foi modificada desde que as versões Editor1 e Editor2 foram criadas. A versão Trans_mnt está referenciando o estado 40, que é o estado predecessor comum para as versões Editor1 e Editor2.

A seguir está um exemplo da árvore de estado antes da reconciliação. Note que as linhagens para as versões são:

• Trans_mnt: 0, 40
• Editor1: 0, 40, 78, 92, 97
• Editor2: 0, 40, 56

Note que a versão Trans_mnt faz referência ao estado 40. A linhagem da versão Editor1 é: 0, 40, 78, 92, 97.

Quando Editor1 é reconciliado com a versão Trans_mnt, não há necessidade de copiar todas as edições da linhagem atual do Editor1 para um novo estado para a versão Trans_mnt.

A seguir está um exemplo da árvore de estado após a reconciliação. A versão Editor1 é reconciliada com a versão Trans_mnt. Nesse caso, a versão Trans_mnt está se referindo a um estado que está na mesma linhagem do Editor1, portanto, não há necessidade de copiar as edições para o estado de reconciliação.

Se 50.000 atualizações foram realizadas no estado 92, as edições não serão copiadas para o estado 99 pois já existem na linhagem da versão. Nesse caso, a reconciliação é muito rápida, pois não há conflitos a serem descobertos e não há edições a serem copiadas para o estado de uma versão de destino.

Quando o comando Post é clicado, as versões Editor1 e Trans_mnt fazem referência ao mesmo estado: estado 99.

Conforme o fluxo de trabalho continua, a versão Editor2 é reconciliada e postada no Trans_mnt.

Para essa reconciliação, a versão Trans_mnt ou primária foi modificada e faz referência a um novo estado, por exemplo, o estado 99, que está em uma linhagem diferente da versão Editor2. Para reconciliar as edições da versão Editor2, todas as edições do estado 56 são copiadas para um novo estado na linhagem Trans_mnt.

Quando há várias versões secundárias criadas a partir da mesma versão primária, as operações de reconciliação invariavelmente resultam nas edições de uma linhagem sendo copiadas para outra linhagem. Para minimizar a quantidade de dados sendo copiados, reconcilie e publique a versão com o maior número de edições primeiro, o que reduz o número de registros que são copiados e armazenados nas tabelas de adição e exclusão das classes de feição.

Compreender as considerações do fluxo de trabalho para reconciliar é especialmente importante ao executar um grande número de edições em uma versão secundária ou edição em massa. Para uma versão usada para edição em massa, sempre tente reconciliar essa versão com seu destino antes que a versão de destino seja modificada.