DB2的联邦数据库能力允许本地实例连接并访问其他DB2、Oracle、SQL Server等数据源。直接使用远程表的四段式名称（例如server_name.remote_schema.remote_table）虽然可行，但在复杂查询中会让SQL变得难以阅读，也会让应用层过度依赖远程对象的物理命名。CREATE NICKNAME语句可以在本地模式中创建一个昵称，把远程表包装成一个本地化的逻辑名称。应用代码、报表工具和存储过程只需要针对昵称编写SQL，后续即使远程表结构或数据源位置发生变化，也只需要调整昵称映射，而不必改动业务逻辑。
一、CREATE NICKNAME的语法结构与参数解析
CREATE NICKNAME的基本语法并不复杂，核心是定义本地昵称、关联的远程服务器以及远程对象的完整位置。它的标准形式可以概括为：在指定本地模式下创建一个昵称，指向某个远程服务器上的模式、表或视图。下面是一个简化后的语法示例：
CREATE NICKNAME local_schema.local_nickname FOR remote_server.remote_schema.remote_table;
这里local_schema是本地模式名，local_nickname是应用程序在本地使用的名称，remote_server必须已经通过CREATE SERVER语句注册到本地联邦环境。remote_schema.remote_table则是远程数据源中的实际模式名和表名。创建昵称后，在本地执行SELECT * FROM local_schema.local_nickname就等价于访问远程表。
昵称还支持通过OPTIONS子句指定额外映射选项。例如当远程表名与本地昵称不同，或者需要指定远程表所在的特定分区、数据链路选项时，可以在语句末尾追加OPTIONS参数。不过在日常使用中，大多数场景只需要基础语法即可完成映射。需要注意的是，昵称创建后不会自动复制远程表的索引、约束或触发器信息，它只是一个逻辑指针，实际数据仍然存储在远程数据源中。
二、创建昵称前的必要准备：启用联邦与注册远程对象
直接执行CREATE NICKNAME通常会失败，因为本地数据库必须先启用联邦支持，并完成对远程数据源的注册。联邦支持由实例级参数FEDERATED控制，如果该参数处于NO状态，需要先执行db2 update dbm cfg using federated yes并重启实例。启用后，本地数据库才具备创建wrapper、server和user mapping这些联邦对象的能力。
接下来需要创建一个wrapper来指定访问远程数据源所使用的通信协议和库文件。以连接远程DB2数据库为例，通常使用DRDA协议。wrapper创建完成后，再通过CREATE SERVER语句把远程数据库实例注册到本地联邦环境，并指定连接认证信息。最后使用CREATE USER MAPPING为本地用户映射远程登录凭据。完整流程如下：
-- 1. 创建DRDA通信包装器 CREATE WRAPPER drda_wrapper LIBRARY 'libdb2drda.so'; -- 2. 注册远程DB2服务器 CREATE SERVER remotedb_server TYPE DB2/UDB VERSION 11.5 WRAPPER drda_wrapper AUTHORIZATION "remote_admin" PASSWORD "remote_password" OPTIONS (DBNAME 'REMOTEDB'); -- 3. 建立本地用户到远程用户的认证映射 CREATE USER MAPPING FOR "local_user" SERVER remotedb_server OPTIONS (REMOTE_AUTHID 'remote_admin', REMOTE_PASSWORD 'remote_password');
上述代码中的库文件在Linux或Unix环境下为libdb2drda.so，Windows环境通常为db2drda.dll。wrapper负责完成本地SQL到远程数据源SQL方言的翻译和传输，server则代表一个具体的远程数据源实例。如果没有建立USER MAPPING，本地用户在访问昵称时可能因为缺少远程认证信息而报错。因此，创建昵称之前一定要把这三层联邦对象配置完整。
完成联邦配置后，可以通过查询系统视图SYSCAT.WRAPPERS、SYSCAT.SERVERS和SYSCAT.USEROPTIONS来确认配置是否已经生效。只有server状态正常且当前用户拥有相应权限时，CREATE NICKNAME才能成功执行。权限方面，本地用户通常需要具备模式上的CREATEIN权限，或者拥有DBADM权限。
三、实际创建昵称的完整示例与验证
假设本地数据库为LOCALDB，远程数据库REMOTEDB中有一个模式HR，模式内有一张员工表EMPLOYEE。业务系统希望在本地的APP模式中使用employee_nick来访问这张远程表，而不需要关心远程服务器名称。此时可以执行下面的语句：
CREATE NICKNAME app.employee_nick FOR remotedb_server.HR.EMPLOYEE;
语句执行成功后，app.employee_nick就成为一个本地可查询的对象。可以在本地数据库中使用普通SQL访问它：
SELECT emp_id, emp_name, dept_id FROM app.employee_nick WHERE dept_id = 'D01';
这条查询会被DB2联邦引擎解析，转换成针对远程数据库REMOTEDB的请求，并将结果返回本地。从应用开发角度看，这与查询本地表几乎没有区别。如果需要确认昵称是否创建成功，可以查询系统目录表SYSCAT.NICKNAMES：
SELECT nick_name, server_name, remote_schema, remote_table FROM SYSCAT.NICKNAMES WHERE nick_name = 'employee_nick';
系统目录中会记录昵称名称、对应的server名称以及远程模式名和远程表名。通过这些信息，数据库管理员可以快速排查昵称映射是否正确。需要注意的是，SYSCAT.NICKNAMES中显示的是远程对象的逻辑信息，并不包含远程数据量大小或统计信息，因为实际数据并不存储在本地。
四、昵称的维护与常见使用误区
昵称创建之后并不是永久不变的。如果远程表发生结构变更，例如增加列、删除列或修改列类型，本地昵称可能会暴露出不匹配的问题。此时需要评估是否需要重建昵称，或者重新收集昵称的统计信息，以保证查询优化器能够生成合适的访问计划。删除昵称使用DROP NICKNAME语句，执行后本地对象被移除，但不会影响远程表本身。
DROP NICKNAME app.employee_nick;
常见的误区之一是把昵称当作本地物理表来管理，试图在昵称上直接创建索引或主键。实际上昵称指向远程对象，不支持像本地表那样添加本地索引。另一个误区是忽略了远程认证配置。即使nickname创建成功，如果USER MAPPING中的远程用户密码被修改或远程账户被锁定，访问昵称时仍会出现认证失败。
此外，在频繁访问远程大表时，查询性能高度依赖联邦引擎的下推能力。如果WHERE条件、聚合操作能够下推到远程数据库执行，就可以减少网络传输量，提高响应速度。如果发现昵称查询缓慢，应该查看访问计划，确认哪些操作在本地执行、哪些操作被下推。必要时可以调整wrapper选项或改写SQL，尽量让过滤和聚合逻辑在远程端完成。
最后需要强调一点，昵称只是联邦体系中的一个便捷访问入口，不能替代对整个联邦环境的安全管理。创建昵称时应当遵循最小权限原则，只把必要的远程表和视图暴露给本地用户。对于包含敏感数据的远程表，可以通过本地视图、权限控制或列级映射进一步限制用户可见的数据范围。
DB2CREATE NICKNAME联邦数据库修改时间：2026-09-29 19:39:17