ArcGIS Server里头数据库怎么管才算靠谱，数据存储和管理那些事儿要点讲讲

关于ArcGIS Server里头数据库怎么管才算靠谱，这事儿说白了就是把数据和服务器当成一个重要的家当来打理，不能瞎折腾，核心思想就一条：让专业的（数据库）干专业的事，让ArcGIS Server轻装上阵，只管画图和分析。

下面我就把数据存储和管理的那些要点,掰开揉碎了讲讲。

第一，最根本的一条：数据别放SDE里，要放数据库里。

这话听起来有点矛盾，得解释一下，很多人以为在ArcGIS里创建了一个“数据库连接”，数据就存在ArcGIS自己的某个地方了，其实不是，这里的“SDE”更像是一个管理员或者一个翻译官，它负责告诉ArcGIS怎么去读写真正的数据库（比如Oracle, SQL Server, PostgreSQL），靠谱的管理第一步是，你得有一个正经的关系型数据库软件（DBMS）在运行，比如在公司服务器上装一个SQL Server，再用ArcGIS的工具在这个SQL Server里面创建一个叫“Geodatabase”的库（这个过程叫“Enable Geodatabase”），你的所有空间数据表，最终都是存在这个SQL Server的数据库里的，这样做的好处是，你能享受到数据库自带的所有好处：强大的备份恢复、权限控制、事务处理能力，ArcGIS Server只是通过SDE这个“翻译官”来访问和操作这些数据。（来源：Esri关于企业级Geodatabase的官方概念文档）

第二，用户账号要分家，不能一个账号打天下。

这是最容易出问题的地方，连接数据库需要账号密码，这里至少要有三种账号,权限要分开：

1. 所有者账号（Owner User）： 这个账号权力最大，用来创建新的数据集（比如新的图层、拓扑关系等），这个账号的密码要牢牢管住，平时不应该给ArcGIS Server用，只有需要创建新数据的时候,才用这个账号连一下。
2. 数据读写账号（Data User）： 这个是给ArcGIS Server日常使用的账号，它应该只有对现有数据的“增删改查”权限，但没有“创建新表”或“删除表”的权限，这样即使服务器被攻击或者有错误操作，最多是数据被改乱，但不会把整个表删掉,损失可控。
3. 只读账号（Read-Only User）： 用于那些只需要地图浏览、查询的场景，比如公开的地图服务，用这个账号连接，绝对安全,想改也改不了。

（来源：Esri技术文档中关于数据库连接和权限管理的最佳实践）

第三，备份是命根子，但不能只备份数据。

数据库本身（比如SQL Server）有非常完善的备份机制，一定要定期做全量备份和事务日志备份，这样不仅能恢复数据，还能恢复到某个时间点，光备份数据库还不够，ArcGIS Server还有它自己的一套东西，

• 服务定义文件（.sd文件）： 你发布一个地图服务，会生成一个.sd文件，这个文件包含了地图长什么样、用什么数据、有哪些功能等配置信息，这东西也得备份！想象一下，数据库完好无损，但成百上千个地图服务怎么发布的你全忘了,一个个重新配会累死。
• Server的站点配置： 如果你配置了集群、设置了安全策略、自定义了日志级别等,这些系统设置也需要定期导出备份。

靠谱的备份策略是：数据库备份 + Server配置备份 + 服务定义文件归档,三管齐下。

第四，日常维护要像打扫房间一样。

数据库用久了，会产生“垃圾”，比如频繁编辑数据，会导致数据在硬盘上存储得零零碎碎（碎片化），查询速度就会变慢，还有，数据库统计信息过时了，它就不会选择最快的路径来找数据,所以需要定期做维护：

• 压缩数据库（Compress）： 特别是使用了版本化编辑之后，必须定期压缩，清理掉不再需要的编辑历史，否则数据库会变得巨大无比,性能急剧下降。
• 更新数据库统计信息（Analyze）： 告诉数据库：“喂，数据的样子变了，你重新认识一下。”这样它才能制定高效的查询计划。
• 重建索引（Rebuild Indexes）： 索引就像书的目录，目录乱了，找内容就慢,定期重建索引能保持查询速度。

这些工作可以写成脚本，让数据库在半夜自动完成。（来源：Esri白皮书《企业级Geodatabase性能优化建议》）

第五，心里要有个“谱”：监控和记录。

不能等到用户抱怨地图打不开了，你才知道出问题了,要主动去看着点：

• 看日志： ArcGIS Server有详细的日志，设置好日志级别，经常看看有没有错误或警告信息,数据库自己也有运行日志。
• 看性能： 监控一下服务器的CPU、内存占用情况，看看地图服务响应时间是不是在正常范围内，如果某个服务特别慢，就要去查原因，是不是数据没索引？还是查询语句写得太烂？
• 记录变更： 什么时候发布了新服务？什么时候修改了重要数据？谁干的？最好有个简单的记录本（比如一个共享文档或Wiki），写上一笔,出了问题好追溯。

再说两个务实的点。

一个是关于数据来源的，尽量保证“单一数据源”，一个土地利用图层，最好只在一个数据库里维护一份，然后所有相关的地图服务都来调用这一份，不要A服务用数据库里的，B服务却用本地硬盘上的一个拷贝，否则一更新，两边就不一致了,会出大乱子。

另一个是关于版本的，如果数据需要多人同时编辑，一定要用好Geodatabase的版本化功能，它能很好地处理冲突，保证数据质量，但这又回到了前面说的，版本化编辑后,压缩工作就变得更加重要。

管好ArcGIS Server的数据，核心就是尊重数据库的规则，通过分账号保证安全，通过定期备份和维护保证稳定和速度，通过监控做到心中有数，把这些事儿当成日常习惯,这个系统就算管得比较靠谱了。