<\/HEAD>
Estamos atualmente na fase de desenvolvimento e teste da implementação do Parcel Fabric para nosso condado, e encontramos problemas EXTREMOS de desempenho para os quais ninguém parece ter uma resposta.<\/P>
<\/P>
Como um breve histórico: Já concluímos (há meses) um longo processo de limpeza dos nossos lotes – simplificando as linhas ao remover vértices excessivos e planarizando a maioria deles para linhas de 2 pontos (exceto por uma minoria das fronteiras dos lotes que seguem características naturais como hidrografia, etc., que foram mantidas como linhas). Essa limpeza removeu mais de 10 milhões de vértices desnecessários. Nossos dados limpos de lotes e subdivisões foram então processados e carregados no esquema de preparação fornecido pela ESRI (FGDB), onde todos os erros/problemas de topologia foram corrigidos, e finalmente carregados em um novo Fabric (FGDB). Este FGDB fonte do Fabric foi subsequentemente carregado em nosso SDE de Desenvolvimento (ArcSDE 10.3.1 | Oracle 11.2.0.3) via a ferramenta Copy Parcel Fabric.<\/P>
<\/P>
Nosso primeiro problema de desempenho foi encontrado ao tentar registrar o Fabric como versionado. Porque o processo de versionamento executa uma série de "análises" em todos os objetos/tabelas do Fabric antes do registro propriamente dito, o processo parece travar – quando na realidade, simplesmente leva muito tempo para completar. No nosso caso, "muito tempo" significa que tanto as classes de feição "Parcels" quanto "Lines" levaram 4-5 horas cada para concluir. Uma olhada rápida nas tabelas (e seus vários índices criados) revelou que a classe de feição "Lines" sozinha tem 2,9 milhões de linhas/registros. Embora isso me pareça alarmante, ninguém na ESRI sugeriu que isso seja algo fora do comum, per se.<\/P>
<\/P>
Depois de finalmente registrá-lo, comecei alguns testes rudimentares de edição, focando principalmente em fluxos simples do Parcel Fabric como a divisão de um lote. Imediatamente, no ponto do fluxo onde a ferramenta Construction é ativada, o cursor/cruzeta apresenta uma latência enlouquecedora, transformando-se em um ponteiro com ampulheta quando movido pela janela do mapa (como se uma operação intensa estivesse em andamento). Se deixado parado (parando o movimento do mouse), a cruzeta retorna após 10-15 segundos... mas volta a virar ampulheta assim que você tenta movê-la novamente. Se você mover o ponteiro não responsivo dentro da distância de snap de uma linha de construção e esperar, ele se comportará como se tivesse encaixado assim que a cruzeta retornar. A partir desse ponto, se você mover LENTAMENTE o cursor ao longo da feição já encaixada, ele permanecerá como cruzeta ativa. Se, no entanto, você mover rápido demais ou ultrapassar a tolerância pegajosa do ambiente snap (10 pixels), a cruzeta voltará a ser uma ampulheta. Se for paciente o suficiente para realmente começar a construir uma linha durante esse tempo, o mesmo comportamento continuará durante todo o tempo em que adicionar vértices e encaixar nas linhas correspondentes. Quando terminar, você pode Construir as feições construídas normalmente.<\/P>
<\/P>
Após testes adicionais, descobri que se eu ativar o ambiente 'Classic Snapping' que permite controlar quais camadas e tipos de feição no seu TOC estão disponíveis para snap (ao contrário do ambiente padrão mais novo onde todas as camadas estão habilitadas para snap o tempo todo), e DESATIVAR todas as camadas para snap, o problema de desempenho desaparece. Neste ponto, o Fabric ainda impõe snap nele mesmo (o que é necessário), mesmo quando todas as camadas estão configuradas para não encaixar. O momento em que você ativa a FC Lines, entretanto, é quando o desempenho cai drasticamente.<\/P>
<\/P>
Curiosamente, esse comportamento NÃO ocorre em um FGDB. Isso me leva a inferir que há alguma interação única entre ArcMap, SDE e o banco Oracle quando se trata da FC Lines intensiva em dados. Apesar da ESRI ter fornecido várias maneiras adicionais de re-analisar diretamente (via SQL) as tabelas do Fabric e regenerar índices espaciais etc., nenhuma melhoria foi alcançada, nem ninguém identificou (via interceptação SDE e arquivos trace Oracle) algum gargalo aparente... Isso NÃO é um problema de I/O, nem parece ser um problema de processamento SQL também.<\/P>
<\/P>
Retorno à minha preocupação sobre o grande número de registros na classe de feição Lines, mas não tenho como comprovar como/porquê/se isso é uma preocupação válida. O ArcMap aparentemente está travando na capacidade de interagir com os dados Lines em tempo real, mas não há explicação funcional que eu possa oferecer além das minhas observações. Claramente, o FGDB cria seu próprio tipo de índices espaciais nessa grande classe de feição, mas roda suavemente mesmo assim. Em contraste, Oracle deveria ser ainda mais robusto, basicamente ignorando uma tabela com meros 3 milhões de registros – porém o desempenho neste caso é péssimo. Assim, continuo voltando à algo que a aplicação está fazendo e não simplesmente ao banco em si.<\/P>
<\/P>
Se alguém tiver experiências similares ou insights sobre este problema, agradeceríamos muito!<\/P>
<\/P>
Gavin<\/P><\/BODY><\/HTML>
