ArcSDE 10.2 + Oracle 10g/11g：安装配置与高频排错指南

简介：面向Windows平台GIS管理员、开发人员及项目实施者，ArcSDE 10.2 for Oracle 10g/11g安装包用于解决ArcSDE中间件与Oracle数据库集成部署时的软件获取与安装准备问题。ArcSDE是ArcGIS核心组件，负责在关系型数据库中高效存储、访问和管理空间数据，因此这份安装包特别适合正在搭建ArcGIS环境、需要同时适配Oracle 10g或11g的用户。压缩包共14个文件，整体约77.88MB，其中exe与msi为安装主程序，cab为安装数据包，chm为帮助文档，ini与htm分别承担配置和安装说明，文件类型覆盖了安装与查阅所需的主要环节。目前已有992人学习下载，可作为离线安装或环境复现时的参考。资源内按Oracle 10g和11g分设独立目录，并附Setup.chm、Install.htm等说明文件，可帮助核对安装步骤、理解ArcSDE与Oracle的配置要点，减少匹配安装包和排查安装问题的时间成本；对于后续的数据存储、性能优化和故障排查，也能借助官方帮助文档快速上手。

1. ArcSDE 10.2 FOR Oracle10g、11g安装包：企业 GIS 数据入库绕不开的第一道坎

提到 ArcSDE 10.2 FOR Oracle10g、11g安装包，很多从桌面 GIS 单机转向企业级应用的团队，第一反应是“装完就行”。但实际上这一套安装包决定的是 ArcGIS 能不能把点线面写进 Oracle，并让多个终端同时读、同时编辑而不互相踩表锁。对还在用 Oracle 10g/11g 的业务系统来说，10.2 是适配最稳的一代空间数据库引擎。这篇文章只讲能落地的东西：安装包怎么准备、sdesetup 怎么初始化、dbtune 怎么调、连接不上先查哪里。适合正在搭环境或接手旧环境救火的运维、DBA 和 GIS 工程师。不要把 10.2 想得多玄，它的复杂度集中在环境与版本匹配，把匹配表搞清楚，半小时就能跑通。

2. ArcSDE 在 ArcGIS 与 Oracle 之间的真实分工：为什么 10g/11g 还得用它

2.1 ArcSDE 到底做了哪四件事

ArcSDE 常被叫成“空间数据库引擎”，但这个称呼太抽象。拆开看，它落在地上就是下面四件具体工作。

第一，把 ArcGIS 的几何模型翻译成 Oracle 能长期存储的格式。ArcGIS 桌面端在内存里用自己的几何对象，而 Oracle 原生只有 NUMBER、BLOB、SDO_GEOMETRY 这类通用类型。ArcSDE 10.2 提供 ST_Geometry 与二进制两种存储方案，无论哪种，都需要在 Oracle 里注册对应的类型和函数，才能让 SQL 直接读写点线面。第二，维护空间索引。空间查询如果走普通索引，一个县域范围的过滤条件可能把全表扫一遍。ArcSDE 会给 SHAPE 字段维护专门的格网索引，执行时先做一层粗筛，再做精确几何计算，这也是为什么初始化完，Oracle 里会出现名字带 SDE_ 开头的索引对象。第三，管理多用户并发与版本编辑。企业级 geodatabase 的版本化编辑，靠的是添加和修改线表缓冲未提交改动，每个版本对应一组差分表，支撑这套机制的底层结构，全部放在 sde 用户之下。第四，统一空间参考和坐标精度。不同来源的要素类入库时都要注册到一条空间参考记录里，避免出现“图层能进去、图形却偏移”的情况。

很多人以为 SDE 只是驱动，装完就能用。实际上它对标 Oracle 里的一个完整中间层。10.2 时代它已经并入 ArcGIS for Server 的“企业级 geodatabase”功能，不再单独销售。不管当初是从哪个介质里拿到的安装包，只要执行过初始化，Oracle 里就会多出一个 sde 用户，以及一批以 SDE_ 开头的系统表，比如 LAYERS、TABLE_REGISTRY、COLUMN_REGISTRY、GEOMETRY_COLUMNS。如果登录数据库看到用户列表里根本没有 sde，说明之前只装了程序文件，没有建库，后面接业务数据必然出问题。

2.2 Oracle 10g/11g 与 10.2 的适配边界：别拿这版去硬连 12c/19c

安装包名字明确写的是 FOR Oracle10g、11g，这句话不是宣传语，而是支持矩阵的结论。ArcSDE 10.2 官方面向的数据库范围，覆盖 Oracle 10g R2 和 11g R1/R2。在这个范围内，安装、授权、函数注册和后续空间查询的配合是经过完整验证的。出了这个范围，10.2 基本属于“能装上，但没人给你背书”的状态，尤其是 12c 以后的可插拔架构。

我先解释一下为什么会这样。Oracle 12c 引入了 CDB/PDB 多租户结构，SDE 初始化要往数据库里写系统表和注册自定义类型，这些操作在 12c 里涉及容器级别的权限。ArcSDE 10.2 发布时间早于 12c，并未针对这种结构做适配，即使绕过版本检查把库建出来，企业级 geodatabase 也可能落在 CDB 根容器里而不是业务用的 PDB，导致业务库看不到空间元数据。之前某团队一台被升级到 19c 的库，拿着 10.2 包硬上，最后全线回退到 11g。所以我对这条边界的态度很明确：10g/11g 是舒适区，别贪新。

实际操作中，拿到参数之前先确认目标 Oracle 的准确版本。在 SQL*Plus 里执行：

select * from v$version;

看返回的 banner 字段是 10.2.0.x 还是 11.2.0.x。得到版本号后，再决定后面的 sdesetup 参数应该用 ORACLE10G 还是 ORACLE11G。这一步不要凭印象。数据库版本、ArcSDE 补丁版本、Oracle 客户端库版本，三者之间只要有一个跳级，安装日志里往往都是不痛不痒的“无法获取系统表”，真正原因在更早的版本检查阶段就埋下了。我问过几个做过同样方案的开发者，超过一半的返工发生在这一节。

选型还不能只盯版本。Oracle 10g/11g 时代，字符集差异很大，常见的有 AL32UTF8 和 ZHS16GBK。如果目标库是 ZHS16GBK，对 ArcSDE 10.2 来说，中文属性的读写要走一遍字符集转换，很容易在客户端出现乱码。所以这个适配边界还包含字符集项。查法：

select name, value$ from sys.props$ where name like 'NLS_CHARACTERSET';

返回值就是数据库当前字符集。这条信息要记录到安装清单里，第 3 章配置 NLS_LANG 时直接用它。

2.3 服务连接与直接连接：安装前就要拍板的访问方式

ArcSDE 提供两种访问 Oracle 的方式，安装前不拍板，后面会白折腾。

服务连接由中间进程 giomgr 监听一个 TCP 端口（默认 5151），客户端先连中间进程，再由进程连数据库。优点是老客户端兼容性好，ArcGIS Desktop 早期版本只能这么连；缺点也明显，中间进程多一层状态，端口被防火墙挡、进程被杀、hosts 解析异常都会造成“数据库是好的但 GIS 连不上”。直接连接则不需要中间进程，客户端利用安装包里的动态库和 Oracle 客户端库，通过对端的 tnsnames 服务名直达数据库。少了中间层，排查面大幅缩小，官方在 10.2 时代推荐的就是直接连接。

我一般会建议生产环境走直接连接，保留服务模式的初始化只是为了让兼容老版本时随时能拉起。这里有个容易忽视的注意点：同一要素类不能同时被服务和直接连接频繁使用，尤其涉及版本编辑时，两种连接会各自持有锁，等待超时就出现假死。如果团队里既有老桌面端又有新组件，宁可把老桌面端升级，也不要让两条访问链路长期并存。安装包在执行 sdesetup 时会把服务名写进配置，即使你不用服务模式，服务名也最好一次写对，因为后续连接字符串往往会引用它作为标识。

3. 安装前准备：从安装包解压到 Oracle 客户端变量的一次核对清单

3.1 安装包里通常有什么，以及版本核对的三个动作

ArcSDE 10.2 安装包解压后，结构一般分几个子目录：bin 目录放着 sdesetup、sdelayer、sdeconfig 等命令行工具；lib 目录放跨平台调用的动态库；etc 目录放 dbtune 模板和服务端示例配置。具体文件名和数目每套介质不一样，以你手上介质为准，不要照抄网上别人的结构图。拿到包后先别急着解压到生产目录，做三个核对动作。

第一个动作，核对 ArcSDE 与 ArcGIS 版本的匹配。假设你同时安装了 ArcGIS for Server 10.2.2，那 ArcSDE 也用 10.2.2 对应介质，不要让基础版 10.2.0 的 SDE 去给更高补丁的 Server 建库。版本不一致会在创建企业级 geodatabase 的最后一步报“版本不匹配，请运行安装后配置”。第二个动作，核对目标平台的位数。ArcGIS Server 是 64 位，就用 64 位安装包；如果同一套环境里还有 32 位的 ArcGIS Desktop 要连接，还需要单独准备 32 位客户端库。第三个动作，核对数据库底层版本和字符集，执行下面这段 SQL：

sqlplus sys/password@orcl as sysdba select * from v$version; select name, value$ from sys.props$ where name like 'NLS_CHARACTERSET';

代码后面的逻辑是：第一条 SQL 返回 Oracle 数据库的完整版本号，用来确定 sdesetup 的 -d 参数写 ORACLE10G 还是 ORACLE11G；第二条返回数据库字符集，例如 AL32UTF8 或 ZHS16GBK，后面配 NLS_LANG 直接用。连接串 @orcl 是 tnsnames.ora 里定义的服务名，你要替换成自己环境里的实际名称。这一步花五分钟，能挡住后面一半的安装失败。

还要提醒一个解压层面的细节。安装包在 Windows 上可能是自解压 exe，在 Linux 上是 tar.gz 或 ISO。如果在 Windows 上解压后直接拷贝到 Linux，符号链接和可执行权限会失真，sdesetup 一启动就闪退。正确做法是把介质放到目标机器上，用目标平台对应的解包方式解压，例如 Linux 下用 tar -xzf 释放。

3.2 ORACLE_HOME、LD_LIBRARY_PATH 与 Instant Client 位号

ArcSDE 10.2 不是独立运行的程序，它需要调用 Oracle 客户端库与数据库通信。客户端的安装方式很多，最常见的是用 Oracle Instant Client，轻量、不污染系统。关键规则是：位号对齐，版本别跳。ArcGIS for Server 64 位，就装 64 位 Instant Client；ArcGIS Desktop 32 位，就装 32 位。两台机器的客户端各算各的，不要拿一套目录让两边共用。

以 Linux 为例，我一般在 /opt/oracle 下建立一个独立目录，然后通过环境变量把它固定下来：

export ORACLE_HOME=/opt/oracle/instantclient_11_2 export LD_LIBRARY_PATH=$ORACLE_HOME:$LD_LIBRARY_PATH export TNS_ADMIN=/opt/oracle/network/admin export PATH=$ORACLE_HOME:$PATH

这段的解释：ORACLE_HOME 指向 Instant Client 根目录；LD_LIBRARY_PATH 放在最前面，避免系统库里老版本 libclntsh.so 抢先加载；TNS_ADMIN 是 tnsnames.ora 所在目录，改为你自己的网络配置目录；PATH 加上客户端目录，保证 sdesetup、sqlplus 等命令在任意位置都能调起。Windows 环境不需要 export，把同样几个路径写进系统环境变量的 PATH 和 TNS_ADMIN 即可。

这里有一个我反复看到的翻车点：服务器本机装了完整 Oracle 数据库，就把 ORACLE_HOME 指到了数据库软件的家目录。很多情况下这个目录里的客户端库版本比 GIS 组件低，或者被数据库补丁改动过，sdesetup 初始化到一半就因为 OCI 句柄失败退出。所以我宁可单独装一份 Instant Client，也不让 GIS 去蹭数据库的 ORACLE_HOME。Instant Client 版本选择，跟随 Oracle 数据库版本走，11.2 的库配 11.2 的客户端，版本号落到 11.2.0.x；不要随手拿 19c 的客户端去配，因为 10.2 的动态库调用的是老 OCI 接口，新库虽然在兼容层能工作，但 API 行为变化会在高并发查询时暴露问题。

3.3 sde 用户、表空间与授权文件：建库前的数据库侧准备

在运行 sdesetup 之前，数据库侧要先把壳建好。用 sys 或具备 DBA 权限的账号登录，执行：

CREATE TABLESPACE sde_tbs DATAFILE '/u01/app/oracle/oradata/ORCL/sde_tbs01.dbf' SIZE 5G AUTOEXTEND ON NEXT 500M MAXSIZE 30G; CREATE USER sde IDENTIFIED BY "SdePassword1" DEFAULT TABLESPACE sde_tbs TEMPORARY TABLESPACE temp; GRANT CONNECT, RESOURCE TO sde; ALTER USER sde QUOTA UNLIMITED ON sde_tbs;

参数说明：表空间名 sde_tbs 要和目标命名规范一致；DATAFILE 的路径必须换成你 Oracle 实例实际的数据文件目录，可以先执行 select name from v$datafile 看现有文件路径；SIZE 5G 是初始大小，AUTOEXTEND 保证业务初期不会被空间卡住；sde 用户的密码建议按企业密码策略设置，但注意不要太复杂导致命令行转义出错。GRANT 只给了 CONNECT、RESOURCE，这两个角色包含建表、建视图、建存储过程的基础权限，足够 sdesetup 初始化用。如果企业库已经存在自定义角色策略，可以再补 EXECUTE ON 相关包的权限，但通常初始化阶段不需要。

授权文件也在这里确认。10.2 的企业级 geodatabase 授权跟 ArcGIS for Server 的授权走同一套，在服务管理界面里导入过 ArcGIS for Server 许可之后，SDE 初始化才能通过最后一步检查。常见的误会是以为装了安装包就自动获得建库权限。遇到过几次：前面全对，最后抛“无企业级 geodatabase 授权”，问题都出在许可没配。另一个准备项是建一个专用于 SDE 服务进程的运行账号，不要直接用 root 或 Administrator 跑 giomgr，否则后期日志文件权限混乱，排查也难。

4. 创建 SDE Geodatabase 的关键命令：sdesetup、dbtune 与 sdelayer

4.1 用 sdesetup 在 Oracle 11g 上初始化企业级 geodatabase

到这一步，前面的核对如果都过了，初始化本身并不复杂。进入 bin 目录，执行：

cd /opt/arcgis/sde10.2/bin ./sdesetup -o install \ -d ORACLE11G \ -S esri_sde \ -P SdePassword1 \ -p SysPassword1 \ -u sys \ -H /opt/arcgis/sde10.2/etc/dbtune.sde \ -N

逐项说明：-o install 表示从零安装，如果库已初始化过会进入后续流程提示；-d ORACLE11G 对应于 Oracle 11.2 数据库，如果是 10g 就改为 ORACLE10G；-S esri_sde 是 SDE 服务名，也作为后续连接串的标识；-P 是刚才建的 sde 用户密码；-p 和 -u sys 是 DBA 账号；-H 指向 dbtune 模板文件，-N 关掉交互模式，适合脚本化执行。Windows 下命令同名，路径改成 bin 目录下的 sdesetup.exe 即可。

执行过程中，程序会先用 sys 身份连接 Oracle，创建 sde 用户下的系统表，注册 ST_Geometry 相关类型，最后写服务配置。输出显示 Success 不代表全部完成，建议随后立刻做一件事：登录 Oracle 查 sde 用户下系统表数量。

sqlplus sde/SdePassword1@orcl select count(*) from user_tables where table_name like 'SDE%';

这个 count 值如果为 0，说明初始化实际没生效，可能是脚本中断或权限不足。有一个更为直接的判断法：执行 select count(*) from sde.LAYERS，能出结果说明元数据表可读。如果 sdesetup 报告成功但这里查不到，多半是数据库连接用了错误的服务名，后续 ArcGIS 连上的不是同一实例，这也是多实例环境最容易踩的坑。

注意：同一个 Oracle 实例里只能有一个 sde 用户承载企业级 geodatabase。如果初始化前数据库里已经存在带业务对象的 sde 用户，sdesetup 会转入升级流程，而不是重新创建。

4.2 dbtune 与 ST_Geometry：新图层的空间存储与 SRID 参数

初始化完成之后，决定新图层能用什么方式存几何的，是 dbtune 配置。dbtune 本质是一个模板文件，里面按图层配置块组织，每一块定义该图层采用的空间存储类型、空间索引参数和全局默认值。它不直接作用于已有图层，只影响之后创建的要素类。

默认模板里，几何存储类型常见有两种：SDE_BINARY 是 ArcSDE 传统的二进制存储，兼容性好但空间查询效率一般，SQL 直接读不直观；ST_Geometry 则是把几何注册成 Oracle 空间类型，支持在 SQL 里直接用 MDSYS.ST_GEOMETRY 访问，还能和 Oracle Spatial 的功能互操作。生产库我一般会把默认切到 ST_Geometry，因为后期写查询、做并发访问都更顺。

切换方法通常是用 sdedbtune 导出当前模板，改完再导回：

./sdedbtune -o export -f custom_dbtune.sde -u sde -p SdePassword1

执行后会在当前目录生成一个文本模板，打开把其中 GEOMETRY_STORAGE 的默认值改为 ST_GEOMETRY，保存后用 -o import 导回：

./sdedbtune -o import -f custom_dbtune.sde -u sde -p SdePassword1

参数含义：-o export/import 是方向，-f 是模板文件，-u/-p 是 sde 账号。这里有两个实际提醒。第一，改完模板后，已经存在的要素类存储方式不变，要变只能导出导入数据；第二，如果 Oracle 里已经装了 Oracle Spatial 组件，ST_Geometry 注册会更顺利，否则需要先完成 Oracle Spatial 相关包安装，两者共用一个坐标系字典。新图层默认 SRID 也在这里控制，比如常用 WGS84 经纬度就配 SRID 4326，常用国家平面坐标或地方独立坐标，先查坐标系统对应的 SRID 再写入配置，避免后面手工重复指定。

4.3 sdelayer 快速验证：图层创建、数据写入与返回码

建好库不等于能写数据。最快的验证手段是 sdelayer 命令行，它不需要打开 ArcGIS，就能创建图层和载入点线面。创建一个测试点图层：

./sdelayer -o create \ -l TESTP,SHAPE \ -t POINT \ -g default \ -D ORACLE11G \ -u sde -p SdePassword1

说明：-l 是图层名和几何字段名，两者用逗号分隔；-t 指定几何类型 POINT，线用 LINE，面用 POLYGON；-g 指定使用的 dbtune 配置块名称，一般填 default；-D 是数据库类型，和 sdesetup 的 -d 保持一致；-u/-p 是连接账号。创建成功后，再写几条测试坐标：

./sdelayer -o load \ -l TESTP,SHAPE \ -f test_points.csv \ -D ORACLE11G \ -u sde -p SdePassword1

test_points.csv 的格式按“坐标对 + 属性”排列，比如 x,y,point_id 三列，具体列名要和图层字段顺序对应。载入后通过 sdelayer -o describe 确认记录数：

./sdelayer -o describe -l TESTP,SHAPE -D ORACLE11G -u sde -p SdePassword1

如果返回错误码 -97，多是表空间或磁盘空间不足；-100 表示图层名与数据库里已有对象冲突；2048 通常提示几何类型或空间参考不匹配。看到这类码不要急着重装，先处理对应的底层资源问题。这套命令验证通过后，再进 ArcGIS Catalog 建正式要素类，几乎不会卡壳。

5. ArcSDE 10.2 安装连接中的高频踩坑与逐条排查

5.1 sdesetup 中途报 OCI 客户端版本不匹配

现象：执行 sdesetup -o install，输出走到连接 Oracle 检查时中断，提示“OCI environment handle”或“客户端版本不支持”。有时甚至直接提示找不到 libclntsh.so。

原因：系统里有多个 Oracle 客户端，动态库加载顺序不对；ArcSDE 10.2 需要的老 OCI 接口被新版客户端覆盖。另一个常见原因是只装了完整数据库客户端，但位号与 ArcGIS Server 不一致。之前遇到过一台 Linux 服务器，PATH 里先加载了 32 位客户端目录，sdesetup 是 64 位，加载 32 位库直接段错误。

解决：先定位 sdesetup 实际加载的库文件。Linux 上执行 ldd sdesetup | grep clntsh，看输出指向哪个路径。然后把 LD_LIBRARY_PATH 里那个路径替换为与 ArcGIS Server 位数一致的 Oracle Instant Client 11.2.0.x 目录。修改后重开终端，确认 echo $LD_LIBRARY_PATH 生效再执行安装。经验是：宁可少配几个系统环境变量，也别让多个版本客户端目录堆在 PATH 里。

5.2 ArcGIS 客户端连不上 esri_sde 或直接连接超时

现象：在 ArcGIS Catalog 新建数据库连接，测试连接报“无法连接到服务器”或“ORA-12170：TNS 连接超时”。服务模式下，默认 5151 端口始终不通。

原因：分两类。服务模式下是 giomgr 进程没起来，或者防火墙挡了 5151；直接连接模式下是 tnsnames.ora 里的服务名解析错误。很多团队把两类问题混在一起查，查了半天端口发现根本没在用服务模式。

解决：先分路径。第一步 telnet 主机 5151 看端口是否监听；第二步用 sqlplus 直接登录 Oracle，验证 tnsnames 服务名；第三步再看 ArcGIS 的连接字符串。我自己的排查顺序永远是“先 sqlplus 连库，再谈 SDE”。sqlplus 都连不上的话，SDE 层的报错只是对底层问题的二次包装。还有一种容易忽略的情况：两台服务器 hosts 文件里写了两条相同的机器名指向不同 IP，ArcGIS 在局域网轮询时随机挑了一个不通的地址，需要把 hosts 收敛成明确一条。

5.3 图层建好了，写数据却提示空间参考无效

现象：sdelayer 创建图层成功，ArcGIS 里也能建要素类，但加载数据时弹“空间参考无效”，或者图形位置明显偏移。

原因：dbtune 里配置的 SRID 与数据源坐标系 SRID 不一致。例如模板默认用了 4326，业务数据实际是 3857，ArcGIS 在入库时想按默认 SRID 做转换，转换参数又没定义，只能报错。另一部分原因是 dbtune 里的空间参考缓存与 Oracle 坐标系表不同步，尤其新旧客户端交替连接后容易出现。

解决：先确认业务数据坐标系。如果是经纬度，在 dbtune 中把 GEOMETRY_STORAGE 对应的图层块 SRID 放到 4326；如果是投影坐标，把 SRID 换成对应 EPSG 编码。对已有图层，通过 ArcGIS 的重投影工具重新注册，或者用 sdeconfig 清理空间参考缓存后重建图层。不要试图手动改 LAYERS 表里的空间参考记录，直接改表会把元数据写乱，回头更难定位。

5.4 中文属性在 ArcGIS 正常、用 Oracle SQL 查出来是乱码

现象：ArcGIS 属性表显示中文完好，DBA 用 SQL*Plus 直接查询 sde 表，中文变成问号或乱码。

原因：客户端 NLS_LANG 与数据库字符集不一致。数据库是 ZHS16GBK，客户端却设成了 AL32UTF8，两边转换时出现字符丢失。ArcGIS 组件内部有自己的转换逻辑，掩盖了问题；跳过 ArcGIS 直接用 SQL 查询时，问题就暴露了。

解决：在运行 SQL*Plus 的机器上把 NLS_LANG 设置成与数据库一致：

export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

Windows 上在注册表或环境变量里同样设置。如果数据库本身是 AL32UTF8，客户端就用 AMERICAN_AMERICA.AL32UTF8。这里要注意一个方向性：不要为了让 SQL*Plus 显示好看，去修改已经稳定运行的数据库字符集，字符集变更风险远大于几次查询乱码。更稳妥的做法是统一所有访问入口的 NLS_LANG，包括 ArcGIS Server 所在机器的服务进程环境变量。

5.5 空间查询越来越慢，清理 SDE 进程后短暂恢复

现象：库刚建好时空闲查询飞快，业务试运行一两周后，同一范围查询慢到几秒甚至几十秒。强制杀掉 giomgr 或重启数据库后，速度会短暂恢复，但很快又变慢。

原因：典型问题不是 SDE 本身坏了，而是 Oracle 侧的空间索引失效和统计信息过期。业务持续写入后，索引统计长期不更新，优化器判断全表扫描比走索引便宜，于是空间查询就退化了。重启后统计信息临时变化，速度恢复，随后又被打回原形。

解决：先收集表统计信息，再检查索引状态。

exec dbms_stats.gather_table_stats('SDE','TESTP'); select index_name, status from dba_indexes where table_owner='SDE';

第一条命令让 Oracle 重新计算表的数据分布；第二条确认空间索引处于 VALID 而不是 UNUSABLE。如果索引状态异常，执行重建常用语法。平时还要把定期统计任务加进维护计划，不要等慢了才处理。空间索引重建在 ArcGIS 端可以操作，但更推荐在数据库侧用 dbms_stats 和索引维护命令完成，因为业务高峰期数据库运维更熟悉这组工具。

6. 装完先别急着上线：用 4 个检查点给这套 Oracle 10g/11g 环境做体检

6.1 体检清单与验证命令

安装成功不等于可以上线。我一般会在交付前跑一套四步体检，全部通过才把连接串交给业务方。

第一步，验证 sde 用户与系统表完整。第二步，验证空间参考表能读。第三步，验证空间索引状态正常。第四步，用 sdelayer 做一次真实的图层读写。把它们合成一个脚本片段：

select count(*) from sde.LAYERS; select srname, srtext from sde.SPATIAL_REFERENCES; select index_name, status from dba_indexes where table_owner='SDE';

在 SQL*Plus 里依次把这三条查出来。LAYERS 返回 1 个以上的表，说明 geodatabase 元数据表和业务图层注册结构都在；SPATIAL_REFERENCES 能看到 srname 与 EPSG 编码对应的文本描述；索引状态全部是 VALID，说明空间索引可以支撑后续查询。第四步就调用第 4 章的 sdelayer -o describe 完成一次读写验证。如果四步全通过，我再把 tnsnames 服务名、sde 用户密码和 ArcGIS 连接字符串登记到运维手册。

这套体检是我装完 10.2 的固定动作。早期在一个演示环境里，我跳过最后一步，直接接业务数据，结果生产配置下第一笔编辑就卡了半个多小时。后来查了一圈，是建库后空间索引被维护脚本误删，ArcGIS 端看不到任何报错，只能通过索引状态发现。那次之后我的习惯变成：安装日志说成功不算数，元数据有行、空间函数能调、索引存在且有效，这三样才说明安装包真正落了地。每次需要救旧环境时，我也只信自己的检查输出，不轻信别人口里的“装好了”。希望帮到你。

本文还有配套的精品资源，点击获取