gds不是scan的替代品，而是独立部署、跨多rac集群及数据中心的负载均衡与服务路由层；它含gsm、gds catalog等独有组件，scan无此架构，且gds catalog必须为单实例数据库，不支持rac或adg备库。
gds不是scan的替代品，它必须独立部署、跨集群管理，且不支持rac作为catalog库——跳过这三点，gdsctl add gsm大概率卡住或静默失败。
GLOBAL_NAMES=TRUE 和 DB_DOMAIN 必须全局一致
所有参与GDS的数据库（含RAC每个节点、ADG备库、单实例）必须满足两个硬性条件：
- GLOBAL_NAMES=TRUE 已启用（SELECT * FROM global_name 返回值形如 ORCL.EXAMPLE.COM）
- DB_DOMAIN 参数完全相同（如都设为 example.com），否则服务名无法全局唯一识别
- RAC节点间、主备库之间、catalog库与目标库之间，三者域名必须对齐，差一个字符都会导致 gdsctl add service 失败或路由错乱
GDS catalog 库只能是单实例，且需专用用户
GDS catalog 是整个架构的配置中枢，但它明确不支持RAC或ADG备库作为后端：
- 必须部署在单实例Oracle 12c+数据库上（不能是RAC、不能是DG备库）
- 创建专用用户（如 gds_catalog），并授予 GDS_CATALOG_ADMIN 角色
- gdsctl connect 使用的连接串必须能直连catalog监听器——DNS或 /etc/hosts 必须提前解析通，不能依赖本地 tnsnames.ora
- 检查命令：SELECT * FROM global_name 确认返回值包含正确域名，否则后续所有注册操作都不可靠
GSM 启动前必须配通所有网络路径
gdsctl start gsm 表面成功不代表真正可用，常见卡点都在网络层：
- GSM主机必须能直连catalog库的监听端口（通常是1521），防火墙、SELinux、监听状态都要验证
- 所有目标数据库的SCAN名称（如 rac-scan）或VIP主机名必须能被GSM主机DNS解析，不能只靠 tnsnames.ora 临时补救
- 注册RAC集群时，gdsctl add cdb 中的descriptor必须用SCAN地址，且端口与实际监听一致；写单节点VIP会导致DG切换后路径失效
- ps -ef | grep gsm 看到进程只是第一步，还要确认 gdsctl config 能列出catalog和已注册cdb，否则GSM未真正接入
客户端 LOAD_BALANCE=on 必须嵌套在 ADDRESS_LIST 内
即使GSM和catalog全通，客户端连不上负载均衡，90%概率是这个参数位置错了：
- 错误写法：(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=...)(ADDRESS=...)) —— 无效
- 正确写法：(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=...)(ADDRESS=...)) —— 必须包一层
- Java JDBC Thin驱动只认小写 &load_balance=true（URL中），&load_balance=ON 或大写会被忽略
- LOAD_BALANCE=on 只影响新建连接的地址选择，不改变已有长连接的路由；多个 ADDRESS_LIST 之间不会轮询，只在各自list内生效
最易被忽略的是：GDS本身不转发流量，它只做决策；真正的连接分发依赖底层SCAN Listener + 客户端驱动协同。一旦SCAN不可达、REMOTE_LISTENER未指向SCAN、或 ALTER SYSTEM REGISTER 没手动触发，GSM就收不到实例负载指标，所有动态策略（如 -lbal goal SERVICE_TIME）自动退化为静态轮询。
