Destinado a administradores de banco de dados, como recomendações para estabelecer os espaços de trabalho dos produtos em um geodatabase corporativo (Oracle®, SQL Server®, PostgreSQL®).
_______________________________________________________________
Sumário
________________________________________________________________________________________________
Boas práticas para bancos de dados corporativos do MCS - versões anteriores
________________________________________________________________________________________________
Esri MCS
Mapping and Charting Solutions (MCS) da Esri é usado por organizações de todos os tipos para aprimorar os fluxos de trabalho e atender às necessidades mais exigentes de produção cartográfica.
Sites de referência importantes | community.esri.com - Estratégias de design de sistemas
Uma referência técnica da Esri ® Setembro• 2026
________________________________________________________________________________________________
Extensões do ArcGIS para Esri MCS
________________________________________________________________________________________________
Boas práticas para bancos de dados corporativos do MCS
Os guias destinam-se a administradores de banco de dados e apresentam recomendações para estabelecer os espaços de trabalho dos produtos em um geodatabase corporativo (Oracle®, SQL Server®, PostgreSQL®).
* uma implantação bem-sucedida de um aplicativo ArcGIS corporativo começa com um projeto físico de banco de dados sólido e boas práticas de administração de banco de dados
________________________________________________________________________________________________
Observações sobre geodatabases
Crie um geodatabase para cada espaço de trabalho de produto.
• pm - banco de dados de produção
Production Mapping e Defense Mapping
Cartografia topográfica - MGCP, TDS etc.
seus dados GIS - crie um geodatabase separado para cada
escala cartográfica, por exemplo, pm50 (1:50 mil); pm250 (1:250 mil)
—
• pl - espaço de trabalho da biblioteca de produtos - Product Library* (* somente ArcMap)
—
• rev - espaço de trabalho do Data Reviewer - Data Reviewer
—
• wmx - espaço de trabalho do Workflow Manager - Workflow Manager
—
• mar1 - banco de dados de cartografia náutica - Náutico
seus dados GIS - crie um geodatabase separado para cada
escala cartográfica, por exemplo, mar500k (1:500.000); mar1m (1:1.000.000)
—
• mar2 - banco de dados batimétricos - Náutico
—
• aero1 - banco de dados de cartografia aeronáutica - Aviação
seus dados GIS - crie um geodatabase separado para cada
escala cartográfica, por exemplo, aero500k (1:500.000); eaero1m (1:1.000.000)
—
• aero2 - banco de dados de aeroportos - Aviação
—
• lr - banco de dados de referenciamento linear - Rodovias e estradas / Referenciamento de dutos
—
• ind - banco de dados de interiores - Interiores
Para uma classe de feição muito grande, crie uma palavra-chave dbtune separada que aponte para tablespaces e arquivos de dados próprios no armazenamento do banco de dados. Isso reduz a contenção de disco e melhora a E/S.
________________________________________________________________________________________________
UN - Observações sobre a Utility Network
1. Cada Utility Network (UN) deve ser mantida em seu próprio geodatabase separado.
—
2. Isso mantém o banco de dados funcionando sem problemas, reduzindo a contenção e melhorando o desempenho.
—
3. Também facilita o gerenciamento das tarefas de manutenção do banco de dados, como recriar índices e coletar estatísticas.
—
4. É fácil clonar esse banco de dados específico da UN usando backups do banco de dados, quando for necessária uma cópia para testes.
—
5. Além disso, fica mais fácil mover o banco de dados da UN para outro servidor de banco de dados, se necessário.
—
6. Se algo der errado e houver perda de dados devido a erros do usuário, você poderá recuperar apenas esse banco de dados específico da UN para um determinado momento.
—
7. Isso é especialmente útil quando não é possível recuperar os dados perdidos usando versões do geodatabase.
—
8. Essa configuração ajuda a cumprir metas importantes de recuperação de dados, chamadas RPO (objetivo de ponto de recuperação) e RTO (objetivo de tempo de recuperação), garantindo uma recuperação rápida e perda mínima de dados.
—
9. Por exemplo, imagine dois geodatabases UN separados: um para gás e outro para água.
—
10. Se alguém excluir dados do banco de dados de água em uma versão filha do geodatabase e, em seguida, reconciliar e publicar as edições na versão sde.default do geodatabase, não será mais possível recuperar esses dados excluídos da versão sde.default.
—
11. Mas, se o erro for percebido a tempo, o administrador do banco de dados poderá restaurar o banco de dados de água para um momento anterior.
—
12. Isso não afeta em nada as edições do banco de dados de gás.
—
13. Se, em vez disso, todas as UNs fossem armazenadas em um único geodatabase, excluir ou perder dados de uma UN poderia colocar em risco as edições de todos os conjuntos de dados desse geodatabase.
Uma referência técnica da Esri ® Setembro• 2026
________________________________________________________________________________________________
FAQ - Perguntas frequentes
- Carregamento de dados
- Oracle
- Backup e restauração
- Cliente de banco de dados
- PostgreSQL
- Workflow Manager
_________________________________________________________
________________________________________________________________________________________________
Guias do ArcGIS Pro
Os guias destinam-se a administradores de banco de dados e ajudam a estabelecer os espaços de trabalho dos produtos em um geodatabase corporativo.
ArcGIS Pro 3.x - 21 de outubro de 2025
- Cartografia topográfica
- Data Reviewer (Classic) - Obsoleto! Última versão com suporte: ArcGIS Pro 3.6
Funcionalidade do ArcGIS Data Reviewer
Descontinuação de funcionalidades no ArcGIS Data Reviewer
Última versão com suporte: O ArcGIS Pro 3.6 (lançado em outubro de 2025) é a última versão com suporte para
ferramentas legadas, como Reviewer Batch Jobs, Reviewer Sessions e
a tabela Reviewer.
Versão de remoção: A partir do ArcGIS Pro 3.7 (previsto para abril de 2026),
esses componentes clássicos serão completamente removidos e não estarão mais disponíveis.
Motivo da alteração: Isso está alinhado com a descontinuação definitiva do ArcMap 10.8.x em março de 2026,
pois o espaço de trabalho clássico foi projetado principalmente para interoperabilidade com o ArcMap.
Alternativa moderna: Os usuários devem migrar para fluxos de trabalho baseados em regras de atributo,
que usam o Error Inspector para gerenciar erros, em vez da tabela Reviewer
legada.
- Workflow Manager (Classic) - Obsoleto! Última versão com suporte: ArcGIS Pro 3.4
- Aviação - Cartografia aeronáutica / Aeroportos
- Náutico - Cartografia náutica
- Náutico - Batimetria
- Referenciamento linear - Rodovias e estradas / Referenciamento de dutos
- Interiores
Versões anteriores do ArcGIS Pro
________________________________________________________________________________________________
Ciclo de vida do ArcMap - Descontinuação em 1º de março de 2026
Versões anteriores do ArcMap 10.8 / 10.7 / 10.6 / 10.5 / 10.4 / 10.3 / 10.2 / 10.1 / 10.0 .
________________________________________________________________________________________________
Versões anteriores - ArcGIS Pro 2.x - ArcMap 10.8 / 10.7 / 10.6 / 10.5 / 10.4 / 10.3 / 10.2 / 10.1 / 10.0 .
________________________________________________________________________________________________
Scripts de modelos de bancos de dados corporativos MCS
Como instalar, configurar, fazer backup e manter bancos de dados corporativos MCS muito grandes (VLMCSEDB), instruções detalhadas para carregamento de dados, backup e recuperação e gerenciamento de vários logins de usuários.
*Para administradores profissionais de bancos de dados; exige experiência avançada em RDBMS e Geodatabase.
Para uma feature class muito grande, crie uma palavra-chave dbtune separada que aponte para tablespaces e arquivos de dados separados no armazenamento do banco de dados. Isso reduz a contenção de disco e melhora a E/S.
Uma referência técnica da Esri ® Setembro• 2026
________________________________________________________________________________________________
Scripts de modelos de bancos de dados
- os scripts abrangem as práticas recomendadas dos guias
- os scripts também incluem práticas recomendadas muito avançadas de RDBMS e
práticas recomendadas avançadas de geodatabase para
VLMCSEDB que vão além das recomendações dos guias
________________________________________________________________________________________________
Oracle 26ai / 23ai / 21c / 19c / 18c / 12c (12.2, 12.1)
- Para consolidação futura, adote a arquitetura multitenant da Oracle:
1 CDB (banco de dados contêiner):
"mcs" hospeda PDBs (bancos de dados conectáveis):
"pm", "pl", "rev", "wmx", "mar", "aero", "lr", "ind"
cada banco de dados conectável é um geodatabase independente, com apenas
o repositório mestre sde instalado
- Descontinue o uso de geodatabases no esquema de usuário da Esri
(1 banco de dados Oracle - vários geodatabases)
Oracle 11gR2
- Para consolidação, use geodatabases no esquema de usuário da Esri
(1 banco de dados Oracle - vários geodatabases)
________________________________________________________________________________________________
- SQL Server
- SQL Server 2025 / 2022 / 2019 / 2017 / 2016 (Windows/Linux)
________________________________________________________________________________________________
- PostgreSQL
- ArcGIS Pro 3.x e ArcMap 10.8.x
- ArcGIS Pro 2.3 / 2.4 e ArcMap 10.7 / 10.8
- ArcGIS Pro 2.2 e ArcMap 10.6 / 10.5 / 10.4 / 10.3 / 10.2 / 10.1
________________________________________________________________________________________________
Práticas recomendadas para conexões de banco de dados
1. O servidor de aplicativos ArcSDE ("serviço SDE") foi descontinuado; use a "conexão direta"
—
2. Nunca use a conexão do usuário "sde" em: mapas (por exemplo, arquivos MXD), ferramentas de GP, serviços de mapa, serviços de feição etc.
—
3. O usuário "sde" serve apenas para administrar o geodatabase (por exemplo, compactação do sde); o usuário sde é o proprietário do repositório do geodatabase.
—
4. Nunca use conexões de usuários "proprietários dos dados" em: mapas (por exemplo, arquivos MXD), ferramentas de GP, serviços de mapa, serviços de feição etc.
• A menos que seja realmente necessário criar novas feature classes ou tabelas no geodatabase
• Mas é preciso entender as implicações
• Para ferramentas de geoprocessamento, prefira sempre geodatabases de arquivos como espaços de trabalho temporários; é muito mais rápido!!!
• O problema com várias conexões de usuários "proprietários dos dados" é que isso causa bloqueios de tabelas no banco de dados
• Isso pode causar impasses e fazer com que as conexões do ArcGIS Desktop (ArcMap/Pro) e do ArcGIS Server "parem" / "travem"
• A exceção é o Branch Versioning: somente o proprietário dos dados pode publicar o Feature Service
—
5. Então, como evitar o problema de "impasse"?
• Se você não estiver editando dados no ArcGIS, use uma conexão de usuário "visualizador" para criar o mapa
• Se estiver editando dados no ArcGIS, use uma conexão de usuário "editor" para criar o mapa
• A conexão do usuário "visualizador" tem permissão somente de leitura (seleção) nas feature classes e tabelas do usuário "proprietário dos dados"
• A conexão do usuário "editor" tem permissões de leitura e gravação (seleção, inserção, atualização e exclusão) nas feature classes e tabelas do usuário "proprietário dos dados"
• Para criar serviços de mapa do ArcGIS Server, use uma conexão de usuário "visualizador" para criar o mapa antes de publicá-lo
• Para criar serviços de feição do ArcGIS Server, use uma conexão de usuário "editor" para criar o mapa antes de publicá-lo
• Para criar serviços de geoprocessamento do ArcGIS Server: se editar dados, use "editor"; caso contrário, use a conexão de usuário "visualizador"
—
6. Mais detalhes sobre a explicação de "impasse"
• Impasses no Oracle-Base | Documentação da Oracle sobre impasses
• Documentação do SQL Server sobre impasses
• Documentação do PostgreSQL sobre impasses
________________________________________________________________________________________________
Links para a documentação de bancos de dados
________________________________________________________________________________________________
Práticas recomendadas de armazenamento de bancos de dados
Por que usar vários tablespaces e RAID 10
• Sistemas de geodatabase corporativo de produção de grande porte devem usar uma solução de distribuição de dados por hardware. As melhores estratégias de organização de discos e dados envolvem distribuir seus dados entre vários discos.
—
• Com os dados distribuídos entre vários discos, mais cabeçotes de leitura buscam os dados simultaneamente. Isso pode aumentar a velocidade de leitura dos discos e reduzir a contenção de disco.
—
• Há duas maneiras principais de distribuir os dados: tablespaces e matrizes redundantes de discos independentes (RAID).
—
• Você também pode combinar os dois criando tablespaces em matrizes de discos. É possível usar estratégias de segregação de dados; separar tabelas de índices ou certos tipos de tabelas de outras tabelas melhora o desempenho e reduz a carga administrativa.
—
• As recomendações padrão de armazenamento GIS favorecem manter os arquivos de índice e de log separados das tabelas de negócios vetoriais e tabulares.
—
• Por motivos de desempenho, é melhor posicionar separadamente as tabelas de negócios, de feições e de índices espaciais e posicionar os arquivos de dados dos tablespaces de acordo com seu padrão de uso.
—
• Em um geodatabase multiversionado com edição intensa, os arquivos do banco de dados do tablespace VERSIONS podem ser separados e distribuídos entre os discos disponíveis para evitar contenção de E/S.
—
• Como regra geral, crie arquivos de banco de dados tão grandes quanto possível, considerando o volume máximo de dados que você estima que o banco de dados conterá, para acomodar o crescimento futuro.
—
• Criar arquivos grandes ajuda a evitar a fragmentação de arquivos e melhora o desempenho do banco de dados.
—
• Em muitos casos, você pode permitir que os arquivos de dados cresçam automaticamente; basta limitar o crescimento automático especificando um tamanho máximo que ainda deixe algum espaço disponível no disco rígido.
—
• Ao colocar tablespaces diferentes em discos diferentes, você também pode ajudar a eliminar a fragmentação física dos arquivos à medida que crescem.
• Artigo técnico famoso!!!
—
• O striping de granularidade fina pode ser uma má escolha para tablespaces nas quais o Oracle Server grava segmentos de classificação, caso muitos processos de aplicativos realizem classificações simultaneamente. O striping de granularidade fina também pode gerar resultados surpreendentemente ruins para aplicativos que usam o recurso de otimização de consultas paralelas do Oracle (PQO), pois o uso de vários processos escravos de consulta pelo PQO cria um nível elevado de concorrência até mesmo em uma única sessão de usuário.
—
• Se o banco de dados contiver um ou mais tablespaces pequenos para os quais fatias brutas grandes seriam um desperdício, talvez você queira selecionar um ou dois tamanhos de fatia bruta mais convencionais para esses tablespaces. Se usar mais de um tamanho de fatia bruta, escolha tamanhos que sejam múltiplos e divisores inteiros uns dos outros.
—
• Desempenho de E/S—Cada tablespace deve conter segmentos com características semelhantes de concorrência de E/S e tamanho de E/S, para facilitar a seleção do tamanho do array de discos e do tamanho do stripe. Agrupar segmentos somente leitura em tablespaces somente leitura reduz o volume de transferência de dados em backups e recuperações e diminui a manutenção de bloqueios PCM.
—
• Resiliência a interrupções—Tablespaces pequenos permitem realizar manutenção off-line em tablespaces com interrupção mínima dos aplicativos. O tablespace do sistema não pode ficar off-line nem ser descartado e recriado; portanto, manter o menor número possível de segmentos nele minimiza a necessidade de indisponibilidade do banco de dados. Isolar segmentos de rollback no menor número possível de tablespaces reduz a frequência de interrupções, pois qualquer tablespace que contenha um segmento de rollback on-line não pode ficar off-line. Armazenar segmentos relacionados referencialmente em pequenos grupos de tablespaces maximiza sua capacidade de aproveitar o recurso de recuperação pontual de tablespace.
—
• Gerenciamento de espaço—Isolar segmentos com ciclos de vida curtos minimiza o impacto da fragmentação do espaço livre dos tablespaces, que pode impedir a alocação de extensões pelo Oracle Server. Os administradores de VLDB se beneficiam do uso dos parâmetros de armazenamento padrão dos tablespaces, em vez de manter parâmetros de dimensionamento no nível dos segmentos.
—
• Gerenciamento de cotas—As cotas de espaço do Oracle Server são administradas por tablespace para cada usuário. Portanto, você deve atribuir grupos de segmentos de um mesmo esquema a um pequeno grupo de tablespaces.
—
• Se você estiver usando striping de granularidade fina para arquivos de dados, não será necessário separar os índices dos dados para distribuir a carga de E/S entre os discos. No entanto, se seus procedimentos operacionais incluírem reconstruções periódicas de índices, talvez você queira considerar isolar os índices em seus próprios tablespaces para minimizar o possível impacto da fragmentação do espaço livre dos tablespaces causada pelo descarte do índice.
• Essa metodologia atribui uma carga específica a vários subconjuntos do banco de dados, como arquivos de log, segmentos de rollback, tablespaces de índices, tablespaces de dados etc., e atribui discos a esses subconjuntos com base em seu perfil de carga.
________________________________________________________________________________________________
Uma referência técnica da Esri ® Setembro• 2026
________________________________________________________________________________________________
