GDS（Global Data Services）是跨多RAC集群及数据中心的负载均衡与服务路由层，而SCAN仅在单个RAC集群内分发客户端连接；GDS含GSM、GDS catalog等独有组件，SCAN无此架构。
什么是GDS，它和SCAN有什么区别
global data services（gds）不是scan的升级版，也不是替代品；它是独立部署的、跨多个rac集群甚至跨数据中心的负载均衡与服务路由层。scan只在单个rac集群内做客户端连接分发，而gds能统一管理多个rac集群（包括不同版本、不同地域）、data guard备库、甚至单实例数据库，按策略把应用请求路由到最合适的“目标数据库服务”。你看到的gdsctl命令、gsm（global service manager）进程、gds catalog这些组件，都是scan里完全不存在的。
部署GDS前必须确认的三件事
跳过这三项检查，gdsctl add gsm大概率卡住或后续服务注册失败：
- 所有参与GDS的数据库（含RAC每个节点的实例）必须已启用
GLOBAL_NAMES=TRUE，且DB_DOMAIN一致（例如都设为example.com），否则GDS catalog无法唯一识别服务名 - GDS catalog数据库必须是单实例（不支持RAC作为catalog库），且已创建专用用户（如
gds_catalog）并授GDS_CATALOG_ADMIN角色 - 所有GSM主机（运行
gsm进程的机器）需能直连catalog库的监听端口，并能解析所有目标数据库的SCAN或VIP主机名——DNS或/etc/hosts必须提前配好，不能依赖本地tnsnames.ora
用gdsctl完成最小可行GDS部署
以一个GSM + 一个12c RAC集群（rac1/rac2）为例，核心操作链很短，但顺序不能错：
- 在catalog库执行：
CREATE USER gds_catalog IDENTIFIED BY pwd; GRANT GDS_CATALOG_ADMIN TO gds_catalog; - 在GSM主机启动catalog连接：
gdsctl connect gds_catalog/password@catalog_db - 添加GSM自身：
gdsctl add gsm -gsm gsm1 -gdspassword pwd -catalog gds_catalog/password@catalog_db - 启动GSM：
gdsctl start gsm -gsm gsm1（此时ps -ef | grep gsm应看到进程） - 注册RAC集群：
gdsctl add cdb -cdb racdb -region east -descriptor "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=racdb.example.com)))" - 发布全局服务：
gdsctl add service -service gds_app -role primary -lbal goal -pdb racpdb -failovertype select -failovermethod basic
注意：这里racdb.example.com必须和RAC中srvctl config service -d racdb输出的服务名完全一致，大小写敏感；-lbal goal表示按响应时间动态调度，若要轮询则改用-lbal uniform。
GDS客户端连接串怎么写，为什么tnsnames.ora里不能只写SCAN
客户端连GDS服务，必须用GSM提供的地址，不是原RAC的SCAN。典型tnsnames.ora条目长这样：
GDS_APP =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=gsm1-vip)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=gds_app.example.com))
)
关键点在于：HOST指向GSM的VIP（不是RAC SCAN），SERVICE_NAME是GDS里定义的全局服务名+domain。如果还沿用原来的SCAN地址，请求根本不会经过GSM，也就谈不上跨集群负载均衡。另外，GDS默认不开启SSL，若强制要求加密，得额外配置gsm的wallet和sqlnet.ora中的SSL_SERVER_DN_MATCH=ON，这个细节90%的测试环境会忽略，导致连接时抛ORA-12537: TNS:connection closed。
