![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
| 免费下载：IBM® Informix® 11.7 试用版（包括 Ultimate Edition、Developer Edition 和 Innovator-C Edition） |
|---|
| 下载更多的 IBM 软件试用版，并加入 IBM 软件下载与技术交流群组，参与在线交流。 |
Informix 11 与之前版本的 Informix 相比，新增了很多特性，如 SQL 语句跟踪、非阻断的检查点、SDS 辅节点、星型连接、自动存储扩展、图形界面的管理工具 OAT 等，并且在性能上有了很大的提升。另外，由于 Informix 版本 7、9、10 已进入 EOS (End Of Support) 状态，所以很多 Informix 用户纷纷选择将 Informix 升级到版本 11。
Informix 数据库升级是指把使用的 Informix 数据库从低版本转化为高版本。对 Informix 数据库进行升级是一项系统工程，包括升级前的测试、升级前的检查、升级操作过程、升级后的测试、升级后的调优等。
Informix 数据库升级有两种类型：in-place 和 non-in-place。In-place 升级中，新版本的 Informix 使用的数据文件与旧版本的 Informix 相同，数据库管理员无需导出导入数据。Non-in-place 升级中，新版本的 Informix 使用的数据文件与旧版本的 Informix 不同，数据库管理员需要导出导入数据。
In-place 升级比较简单，升级操作时间短。non-in-place 升级比较复杂，升级操作时间长，所需的硬件资源多，风险较小。在一些情况下我们只能使用 non-in-place 升级，例如改变了硬件或操作系统。
两种类型的 Informix 数据库升级的示意图如图 1 所示。
图 1. 两种类型的 Informix 数据库升级的示意图
在升级前和升级后，我们需要对 Informix 数据库进行测试，然后比较升级前的测试结果和升级后的测试结果，以确保现有的数据库应用程序在新版本数据库上运行的结果与在旧版本数据库上运行的结果相同，在新版本数据库上运行的性能好于在旧版本数据库上运行的性能。
于是，我们必须预先制定周密的测试计划。测试计划中应收集的信息主要包括以下这些方面：
- 升级前后每个数据库的 schema
我们可以使用 dbschema 命令得到升级前后每个数据库的 schema，并比较它们。我们需要验证升级前后数据库的 schema 没有被改变。
- 升级前后磁盘空间的分配情况，如 dbspace、chunk、extent 等的情况
可使用 onstat -d 查看 dbspace 和 chunk 的情况。可使用 oncheck -pe 查看 extent 的情况。
- 升级前后每个数据表的行数
我们需要验证升级前后数据表的行数是一样的。可使用如下的 SQL 语句：
select count(*) from <table>;
- 升级前后一些列的总和或平均值
可使用如下的 SQL 语句：
select sum( <column> ) from <table>; select avg( <column> ) from <table>;
- 升级前后一些 SQL 语句的结果
我们可以挑选出一些较复杂（比如涉及到多表查询）的 SQL 语句，然后在升级前后运行这些 SQL 语句。我们需要验证升级前后这些 SQL 语句的运行结果是一样的。
- 升级前后一些重要 SQL 语句的查询计划 (query plan) 和运行时间
在某一个 session 中运行如下 SQL 语句后，Informix 将把该 session 中后续的 SQL 语句的查询计划记录在 sqexplain.out 文件中。
SET EXPLAIN ON;
可使用如下方式得到 SQL 语句的运行时间：
1. 将 SQL 语句写在一个后缀名为 sql 的文件中，例如 my.sql
2. 在 shell 上运行如下命令：
time dbaccess <database> <sqlFile> 例如 : time dbaccess crmdb my.sql
- 升级前后数据库（不包括应用程序）关于典型事务的吞吐量
在 dbaccess 中使用存储过程产生大量典型事务，测试数据库（不包括应用程序）在单位时间内最多能处理多少典型事务。
- 升级前后业务系统（包括数据库和应用程序）关于典型业务的吞吐量
测试业务系统在单位时间内最多能处理多少典型业务。
- 升级前后正常负载下系统资源（CPU、内存、硬盘等）的使用情况
可使用 onstat、iostat 等命令。
- 升级前后较大负载下系统资源（CPU、内存、硬盘等）的使用情况
可使用 onstat、iostat 等命令。
在对生产系统进行升级前，我们应在模拟系统中对“Informix 数据库升级”进行演练。在对模拟系统、生产系统进行升级的前后，我们都应执行测试计划。
在对生产系统进行升级前，我们还应在模拟系统中对“数据库升级失败时的应对方案”进行演练。如果在“数据库升级失败时的应对方案”中使用“onmode -b”的数据库回退方案，那么我们还需制定“验证数据库回退的正确性”的测试计划并在模拟系统中执行。
如果是 non-in-place 升级，一般应使新的存储空间比旧的存储空间大 10% 以上。
如果是 in-place 升级，应确保：
- Root Chunk (Chunk 0) 至少要有 10% 的空间是可用的。
- 足够的逻辑日志空间以重建 sysmaster、sysadmin、sysutils 数据库。
- Partition header pages 必须有一些可用空间。( 这些可用空间供 Informix 11 中的某些描述符或新特性使用。)
- 如果一个 dbspace 上有 n 个 database，则这个 dbspace 还需要 (n * 2000) KB 的可用空间。
可用下面的 SQL 语句计算每个数据库空间 (dbspace) 需要多少空间。(free_space_req 的单位是 KB。)
DATABASE sysmaster; SELECT partdbsnum(partnum) dbspace_num, trunc(count(*) * 2000) free_space_req FROM sysdatabases GROUP BY 1 ORDER BY 1;
可用下面的 SQL 语句计算每个数据库空间 (dbspace) 还有多少可用空间。(free_space_avail 的单位是 page。)
DATABASE sysmaster; SELECT dbsnum dbspace_num, sum(nfree) free_space_avail FROM syschunks GROUP BY 1 ORDER BY 1;
为了使升级更顺利的进行，如果一个数据表的 extent 数目大于 200，那么我们最好重建该数据表。在重建时为该数据表选择更大的 extent size，从而使该数据表的 extent 数目小于 200。
可用下面的 SQL 语句查找 extent 数目大于 200 的数据表：
DATABASE sysmaster;
SELECT dbsname, tabname, nextns
FROM systabnames t, sysptnhdr p
WHERE t.partnum = p.partnum
AND p.nextns > 200
ORDER BY 3 DESC; |
在对数据库进行升级前，管理员应先检查数据库的 schema 中和数据库应用程序的 SQL 语句中是否含有新版本数据库中新增的关键词 (keyword)。例如要将 Informix 9.40 数据库升级到 Informix 11.50，管理员应先检查 Informix 9.40 数据库中是否含有 Informix 10.00、Informix 11.00、Informix 11.50 数据库中新增的关键词。如果含有的话，应先将 Informix 9.40 数据库中的这些“新增关键词”进行修改，直到 Informix 9.40 数据库中不含有这些“新增关键词”。“新增关键词”的列表请参阅 Informix Migration Guide。
检查是否有“outstanding in-place table alters”
检查数据库中是否有“outstanding in-place table alters”，如果有则需要先消除“outstanding in-place table alters”。（具体过程请参见“Download”中的“检查和消除 OutstandingInPlaceTableAlters.doc”）
Informix 数据库升级有两种类型：in-place 和 non-in-place。下面将分别介绍这两种类型升级的具体操作过程。
in-place 升级操作过程主要包括：
- 安装配置新版本 Informix 数据库服务器
- 检查旧版本 Informix 数据库的正确性
- 备份旧版本 Informix 数据库
- 对 Informix 数据库里的数据结构等进行转换
- 检查新版本 Informix 数据库的正确性
下面通过一个 in-place 升级操作过程的示例使读者对 in-place 升级操作过程有更好的掌握。在这个示例中，我们将 Informix 数据库从版本 9.40 升级到版本 11.50。
- 将 Informix 9.40 数据库服务器的各个配置文件（如 onconfig、sqlhosts 等）拷贝到备份文件夹。假设初始时 Informix 9.40 数据库服务器的一些配置如下：
操作系统的环境变量 INFORMIXSERVER 为 bankserver 操作系统的环境变量 INFORMIXDIR 为 /opt/informix940 onconfig.bank 文件里的三个参数： SERVERNUM 33 DBSERVERNAME bankserver DBSERVERALIASES bankserverdr,bankservershm sqlhosts.bank 文件： bankserver onsoctcp localhost 6784 bankserverdr drsoctcp localhost 6785 bankservershm onipcshm localhost 6786
- 安装 Informix 11.50 数据库服务器。
- 配置 Informix 11.50 数据库服务器。管理员可参考 Informix 9.40 数据库服务器的配置参数，来对 Informix11.50 数据库服务器进行配置。（特别要注意的是：如果一些配置参数是文件路径，由于 Informix 9.40 数据库服务器和 Informix 11.50 数据库服务器的 INFORMIXDIR 不同，这些配置参数有可能需要修改。）为了避免应用程序在 Informix 升级过程中连接上 Informix 11.50 数据库服务器，我们可对 Informix 11.50 数据库服务器采取“切断网络连接”或“修改数据库实例的名字和端口号”等措施。（“修改数据库实例的名字和端口号”指将 Informix 11.50 数据库实例的名字和端口号修改得与 Informix 9.40 数据库实例不同。）（在后面的步骤中，Informix 9.40 数据库服务器是以 oninit -s 的方式启动的，启动后处于 quiescent 模式，在这种模式下应用程序是无法连接上 Informix 9.40 数据库服务器的。）
如果对 Informix 11.50 数据库服务器执行“切断网络连接” （由于 Informix 9.40 数据库服务器和 Informix 11.50 数据库服务器位于同一个服务器上，所以 Informix 9.40 数据库服务器的网络连接也被切断了），那么 Informix 11.50 数据库服务器的一些配置如下：
操作系统的环境变量 INFORMIXSERVER 为 bankserver 操作系统的环境变量 INFORMIXDIR 为 /opt/informix1150 onconfig 文件里的三个参数： SERVERNUM 33 DBSERVERNAME bankserver DBSERVERALIASES bankserverdr,bankservershm sqlhosts 文件： bankserver onsoctcp localhost 6784 bankserverdr drsoctcp localhost 6785 bankservershm onipcshm localhost 6786
如果对 Informix 11.50 数据库服务器执行“修改数据库实例的名字和端口号”，那么执行修改操作后 Informix 11.50 数据库服务器的一些配置如下：
操作系统的环境变量 INFORMIXSERVER 为 bankserver_t 操作系统的环境变量 INFORMIXDIR 为 /opt/informix1150 onconfig.bank 文件里的三个参数： SERVERNUM 33 DBSERVERNAME bankserver_t DBSERVERALIASES bankserverdr_t,bankservershm_t sqlhosts.bank 文件： bankserver_t onsoctcp localhost 9784 bankserverdr_t drsoctcp localhost 9785 bankservershm_t onipcshm localhost 9786
- 断开 Informix 9.40 所有的连接并关闭 Informix 9.40。 具体过程如下：
(1) 运行 onmode -sy 命令使 Informix 9.40 数据库服务器处于 quiescent 模式。
(2) 等到所有连接断开后，运行 onmode -l 命令将逻辑日志移动到下一个。
(3) 运行 onmode -c 命令产生一个检查点 (checkpoint)。
(4) 运行 onmode -yuk 命令关闭 Informix 9.40 数据库服务器。
- 使用 oninit -s 将 Informix 9.40 启动为 quiescent 模式，并查看 online.log 文件中与这次启动相关的内容，特别是查看在这次启动中“是否有错误信息”和“事务的情况”。查看“事务的情况”如图 2 的最后一行所示。
图 2. Informix 启动过程中“事务的情况”
(1) 如果没有错误信息，Open 的事务的数目、Committed 的事务的数目、Rolled Back 的事务的数目都为 0，则可以开始操作步骤 6。
(2) 如果查看到错误信息，则针对错误信息做相应的处理，接着使用“onmode -yuk”关闭 Informix 9.40。然后重复操作步骤 5。
(3) 如果 Open 的事务的数目不为零，则使用 onstat -x 检查还有哪些 Open 的事务，再使用适当的方法将这些 Open 的事务清除，接着使用“onmode -yuk”关闭 Informix 9.40。然后重复操作步骤 5。
(4) 如果 Committed 的事务的数目或 Rolled Back 的事务的数目不为零，则根据实际情况进行适当的操作，接着使用“onmode -yuk”关闭 Informix 9.40。然后重复操作步骤 5。
- 使用 oncheck 命令检查 Informix 9.40 数据库的一致性。如果遇到问题，则针对具体情况使用适当的办法解决遇到的问题。下面列出了 oncheck 命令的一些选项的作用：
(1) oncheck -cr 命令可检查数据库的保留页
(2) oncheck -ce 命令可检查数据库的 extent
(3) oncheck -cc 命令可检查数据库的 catalog 表
(4) oncheck -cD 命令可检查数据库的数据
(5) oncheck -cI 命令可检查数据库的索引
- 备份 Informix 9.40 数据库。管理员可使用 ontape 或 onbar 命令对数据库进行备份。管理员还可考虑是否在存储系统层面上对数据库进行一次拷贝。
- 使用 onmode -ky 命令关闭 Informix 9.40 数据库服务器。
- 使用 oninit -vy 启动 Informix 11.50 数据库服务器。注意不要使用 oninit -i 命令来启动 Informix 11.50 数据库服务器。在这次启动中，Informix 数据库服务器将对数据结构等进行从版本 9.40 到版本 11.50 的转换。在启动过程中，管理员应打开一个新的 shell 窗口，用 tail -f online.log 命令实时监控 online.log 文件新增的内容。如果监控到“Conversion from version 9.40 Started”，说明数据库版本的转换开始了。如果监控到错误信息，应及时采取适当的措施。如果监控到“Conversion Completed Successfully”的信息，说明数据库版本的转换被成功完成了。
- 更新 Informix 11.50 数据库的统计数据。过程如下：
(1) 对每个数据库运行“update statistics low drop distributions”。
(2) 对每个数据库的这些 system catalog 表运行“update statistics high”：
sysblobs syscolauth syscolumns sysconstraints sysdefaults sysdistrib sysfragauth sysfragments sysindices sysobjstate sysopclstr sysprocauth sysprocedures sysroleauth syssynonyms syssyntable systabauth systables systriggers sysusers
例如：
update statistics high for table sysblobs; update statistics high for table syscolauth; … … update statistics high for table sysusers;
(3) 对每个数据库的普通的数据表和索引运行它们所需级别 (low、medium、high) 的更新统计数据命令。一般情况下运行“update statistics medium”即可。
- 使用 oncheck 命令检查 Informix 11.50 数据库的一致性。
- 备份 Informix 11.50 数据库。管理员可使用 ontape 或 onbar 命令对数据库进行备份。
- 使用 onmode -ky 命令关闭 Informix 11.50 数据库服务器。
- 如果步骤 3 对 Informix 11.50 使用了“修改数据库实例的名字和端口号”，则步骤 14 对 Informix 11.50 执行“恢复数据库实例的名字和端口号”。如果步骤 3 对 Informix 11.50 使用了“切断网络连接”，则步骤 14 对 Informix 11.50 执行“恢复网络连接”。
无论在步骤 14 执行哪个操作，执行操作后 Informix 11.50 数据库服务器的一些配置都如下：
操作系统的环境变量 INFORMIXSERVER 为 bankserver 操作系统的环境变量 INFORMIXDIR 为 /opt/informix1150 onconfig.bank 文件的三个参数： SERVERNUM 33 DBSERVERNAME bankserver DBSERVERALIASES bankserverdr,bankservershm sqlhosts.bank 文件： bankserver onsoctcp localhost 6784 bankserverdr drsoctcp localhost 6785 bankservershm onipcshm localhost 6786
- 使用 oninit -vy 启动 Informix 11.50 数据库服务器。
non-in-place 升级操作过程主要包括：
- 安装配置新版本 Informix 数据库服务器
- 检查旧版本 Informix 数据库的正确性
- 备份旧版本 Informix 数据库
- 使用工具将数据从旧版本 Informix 数据库复制到新版本 Informix 数据库
- 检查新版本 Informix 数据库的正确性
下面通过一个 non-in-place 升级操作过程的示例使读者对 non-in-place 升级操作过程有更好的掌握。在这个示例中，我们将 Informix 数据库从版本 9.40 升级到版本 11.50。
- 将 Informix 9.40 数据库服务器的各个配置文件（如 onconfig、sqlhosts 等）拷贝到备份文件夹。
- 安装 Informix 11.50 数据库服务器。
- 配置 Informix 11.50 数据库服务器。管理员可参考 Informix 9.40 数据库服务器的配置参数，来对 Informix 11.50 数据库服务器进行配置。（特别要注意的是：如果一些配置参数是文件路径，由于 Informix 9.40 数据库服务器和 Informix 11.50 数据库服务器的 INFORMIXDIR 不同，这些配置参数有可能需要修改。）（在后面的步骤中，Informix 11.50 数据库服务器启动后处于 single-user 模式，在这种模式下应用程序是无法连接上 Informix 11.50 数据库服务器的。）
- 断开 Informix 9.40 所有的连接并关闭 Informix 9.40。具体过程如下：
(1) 运行 onmode -sy 命令使 Informix 9.40 数据库服务器处于 quiescent 模式。
(2) 等到所有连接断开后，运行 onmode -l 命令将逻辑日志移动到下一个。
(3) 运行 onmode -c 命令产生一个检查点 (checkpoint)。
(4) 运行 onmode -yuk 命令关闭 Informix 9.40 数据库服务器。
- 修改 Informix 9.40 数据库实例的“名字和端口号”，防止应用程序连接上 Informix 9.40 数据库实例。（我们在步骤 9 将 Informix 9.40 改为了 on-line 模式，所以我们要修改 Informix 9.40 数据库实例的“名字和端口号”来防止应用程序连接上 Informix 9.40 数据库实例。）
- 使用 oninit -s 将 Informix 9.40 启动为 quiescent 模式，并查看 online.log 文件中与这次启动相关的内容，特别是查看在这次启动中“是否有错误信息”和“事务的情况”。查看“事务的情况”如图 2 的最后一行所示。
(1) 如果没有错误信息，Open 的事务的数目、Committed 的事务的数目、Rolled Back 的事务的数目都为 0，则可以开始操作步骤 7。
(2) 如果查看到错误信息，则针对错误信息做相应的处理，接着使用“onmode -yuk”关闭 Informix 9.40。然后重复操作步骤 6。
(3) 如果 Open 的事务的数目不为零，则使用 onstat -x 检查还有哪些 Open 的事务，再使用适当的方法将这些 Open 的事务清除，接着使用“onmode -yuk”关闭 Informix 9.40。然后重复操作步骤 6。
(4) 如果 Committed 的事务的数目或 Rolled Back 的事务的数目不为零，则根据实际情况进行适当的操作，接着使用“onmode -yuk”关闭 Informix 9.40。然后重复操作步骤 6。
- 使用 oncheck 命令验证 Informix 9.40 数据库的一致性。如果遇到问题，则针对具体情况使用适当的办法解决遇到的问题。
- 备份 Informix 9.40 数据库。管理员可使用 ontape 或 onbar 命令对数据库进行备份。在 non-in-place 升级中，一般不需要再在存储系统层面上对数据库进行一次拷贝。
- 使用 onmode -m 将 Informix 9.40 改成 on-line 模式。
- 使用 oninit -ivy 启动 Informix 11.50 数据库服务器。
- 使用 onmode -j 将 Informix 11.50 改成 single-user 模式。
- 使用工具将数据从 Informix 9.40 中导出，并将导出的数据导入到 Informix 11.50 中。下面以工具 dbexport、dbimport 为例来介绍数据的导出导入过程：
(1) 使用如下命令将数据从 Informix 9.40 导出到 <exportdir> 文件夹：
dbexport <database> -o <exportdir>
(2) 将 <exportdir> 文件夹下的 <database>.exp 文件夹拷贝到 <importdir> 文件夹下。
(3) 根据需要设置环境变量。例如：原始数据库的 DB_LOCALE 是 en_us.8859-1，而管理员要使“使用 dbimport 命令生成的新数据库”的 DB_LOCALE 是 zh_cn.gb18030-2000，则需要设置环境变量 DB_LOCALE 为 zh_cn.gb18030-2000，设置环境变量 CLIENT_LOCALE 为 zh_cn.gb18030-2000。
(4) 使用如下命令将数据从 <importdir> 文件夹下导入到 Informix 11.50：
dbimport <database> -d <dbspace> -i <importdir>
- 更新 Informix 11.50 数据库的统计数据。
- 使用 oncheck 命令检查 Informix 11.50 数据库的一致性。
- 备份 Informix 11.50 数据库。管理员可使用 ontape 或 onbar 命令对数据库进行备份。
- 使用 onmode -m 命令将 Informix 11.50 数据库服务器改为 on-line 模式。
- 使用 onmode -ky 命令关闭 Informix 9.40 数据库服务器
当数据库升级成功后，Informix 管理员可以利用 Informix 11 的新特性来提高数据库的性能。例如：Informix 管理员可通过设置 VP_MEMORY_CACHE_KB 配置参数来设定 CPU VP 的私有内存，从而提高 CPU VP 的性能；Informix 管理员可通过设置 SQLTRACE 配置参数对 SQL 语句进行跟踪，根据跟踪结果对 SQL 语句进行调优。
- 当 in-place 类型的数据库升级失败时，管理员可采取两种方案：
- 使用先前的备份来进行数据库的恢复。
- 使用 onmode -b 命令将数据库从新版本回退到旧版本。例如要将 Informix 数据库从 11.50 版本回退到 9.40 版本，可使用 onmode -b 9.40 命令。管理员可从数据库的 online.log 文件看到数据库回退的详细过程。
- 当 non-in-place 类型的数据库升级失败时，管理员只要关掉新版本的数据库服务器，并使旧版本的数据库服务器处于 on-line 模式就行了。
当数据库处于旧版本时，管理员可仔细检查数据库升级失败的原因（一般情况下可从数据库的 online.log 文件中找到数据库升级失败的原因）。在消除了导致数据库升级失败的因素后，管理员可选择一个合适的时段再对数据库进行升级。
如果 Informix 数据库的版本是 11.10、10.00、9.40、9.30、9.21、7.31，那么 Informix 数据库可以直接被升级到版本 11.50。如果是其它版本要升级到版本 11.50，那么需先升级到中间版本。例如我们要将版本 9.20 升级到版本 11.50，那么需先将版本 9.20 升级到版本 9.21 或 9.30，再将版本 9.21 或 9.30 升级到版本 11.50。
如果 Informix 数据库的版本是 11.10、10.00、9.40、7.31，那么 Informix 数据库可以直接被升级到版本 11.70。如果是其它版本要升级到版本 11.70，那么需先升级到中间版本。
详细的升级路径请参阅 Informix Migration Guide。
在 Informix 数据库升级前后，我们需要考虑与 Informix 数据库相关的软硬件（CPU、操作系统、存储系统、网络、应用服务器、数据抽取软件、系统监控软件、应用程序）是否需要变动。例如：操作系统需要打哪些补丁？是否需要将 Informix CSDK 从版本 2.7 升级到版本 3.5 ？应用程序是否需要重新编译？
升级前的测试和检查时间、升级操作时间、升级后的测试和调优时间
在对数据库进行升级前，我们需要计算：升级前的测试和检查时间、升级操作时间、升级后的测试和调优时间。不同的升级类型（in-place 和 non-in-place）和不同的升级工具会导致数据库升级所需的各项时间不同。我们需要就数据库升级所需的各项时间（特别是升级操作时间）与各有关部门（特别是使用了该数据库的业务部门）进行沟通，尽量使数据库升级对业务运营的影响降到最低。
我们需要研究数据库升级过程中存在的风险，如操作失误、电力中断、磁盘空间不够、操作系统故障等。我们需要针对这些风险预先制定应对方案，从而将这些风险带来的损失降到最小。
本文主要阐述了如何将 Informix 升级到版本 11。
Informix 用户将 Informix 升级到版本 11 后，不仅可从 Informix 11 改进的性能中受益，而且可使用 Informix 11 的各种新特性，如 SQL 语句跟踪、非阻断的检查点、星型连接、自动存储扩展等。
读者如果想对 Informix 数据库升级有进一步的了解，请参阅 Informix Migration Guide。
| 描述 | 名字 | 大小 | 下载方法 |
|---|---|---|---|
| 检查和消除 OutstandingInPlaceTableAlters 示例！ | Alters.zip | 26KB | HTTP |
学习
- 阅读 Informix Migration Guide，获得更多关于 Informix Migration 的知识
- How and why to migrate to Informix Dynamic Server 11：关于 Informix Migration 的幻灯片。
- 在 developerWorks 中国网站 Information Management 专区 了解关于信息管理的更多信息。查找技术文档、how-to 文章、培训、下载、产品信息以及更多内容。
- developerWorks 技术活动 和 网络广播：随时关注这些活动中的技术。
- 在 Twitter 上关注 developerWorks。
获得产品和技术
- 使用可以直接从 developerWorks 下载的 IBM 产品评估试用版软件 构建您的下一个开发项目。
讨论
- 参与 developerWorks 博客 并加入 developerWorks 中文社区，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
内容
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。