DB2默认会使用rsh协议，但是ssh有这数据加密和压缩传输的优点，我们往往会选择ssh来代替rsh协议，不管你是单节点还是dpf的数据库的环境。简单的步骤如下:

• Change ownership to db2 instance id on the directory

              chown -R db2inst1:db2grp1 .ssh

•  Add to the known_hosts   

              ssh-keyscan -t rsa dbhost >> known_hosts

•  Set DB2 registry variable

               db2set DB2RSHCMD=/usr/bin/ssh

• Testing:

               db2_all echo hi

IBM最近release了DB2新的New feature:PureScale. 这个功能将为DB2带来所谓”unlimited capacity, application transparency and continuous availability”方面的增强。虽然IBM正在测试中，但是从已有的一些描述来看，这是一个有点类似Z/OS data sharing和Oracle RAC的功能。大家可以去IBM DB2 pureScale web site去了解更多的信息.我们一直期待基于UDB平台的单节点数据库也能有类似Z/OS data sharing的特性，希望这个New feature的推出，能够给我们带来一些惊喜…

简单的测试了一下索引压缩的功能，同时Monitor测试系统WorkLoad。简单步骤如下:

db2 => select INDNAME,COMPRESS_ATTR, INDEX_COMPRESSED, INDEX_OBJECT_L_SIZE, INDEX_OBJECT_P_SIZE from table (admin_get_index_info ('T', 'SAPR3', 'SOC3')) as t

INDNAME COMPRESS_ATTR INDEX_COMPRESSED INDEX_OBJECT_L_SIZE INDEX_OBJECT_P_SIZE
-------------------------------- ------------- ---------------- -------------------- --------------------
SOC3~0 N N 610473 610473

1 record(s) selected.

db2 => alter index "SAPR3"."SOC~0" compress yes
DB20000I The SQL command completed successfully.

1 record(s) selected.

从Nmon收集的数据来看，峰值也就比Normal的时候多2%-3%,基本在可接受范围内。对于Update和Insert的并发影响测试留待以后进行。

提出申请后，很快得到批准。拿到Access Key后，开始下载DB2 V9.7的image文件。最近准备好好看看这个版本。

以下是DB2 V9.7 Release的New Feaure

» Read more: 参加DB2 Cobra Early Access Program

作为成熟数据库产品，备份和恢复的功能基本上是最重要的部分之一。和ORACLE强大的RMAN比起来,DB2在这方面基本上没有什么太闪亮的地方。但是作为一个从DB2 V7就开始使用的老用户而言，DB2在备份和恢复这块随着版本的更新还是不断加强的。对我而言，下面这几个地方的增强，直接对我的工作量有好处:)

备份

对于备份而言Include Logs基本上是最大的一个增强:

这个选项的引入,基本上杜绝了新手们，老是在做恢复的时候 rollforward找不到日志文件的问题。而且比较有意思的是，我们不仅可以Include Logs而且我们还可以从备份文件里面单独retrieve日志文件出来。当然有朋友可能会问，Include Logs选项会让备份文件增长。这是必然，但是我们可以用Compress来明显压缩备份文件大小，一般带上Compress,备份文件将只要以前的1/3-1/4左右。当然有的朋友可能进一步会问，compress会带来Cpu的消耗，这个时候，我们可以用UTIL_IMPACT_PRIORITY在Online的时候来平衡备份的速度，减少资源的消耗.
对于DPF而言，include logs已经很完美的在DPF环境里面得到支持。同时在备份的时候，我们也可以将备份命令简化为:db2 backup database db_name on all dbpartitionnums to “PATH”

恢复

简化前滚的命令,比如:DB2 ROLLFORWARD DATABASE dbname TO END OF BACKUP。当然，你也可以用Recover命令来自动做ROLLFORWARD。在新的版本里面用recover来做PIT的恢复比传统方式还是简单一些。那么在恢复这个部分来讲，引入的新Rebuild这个特性，是一个很大的增强。众所周知,备份和恢复的一个重要应用的场景是数据的迁移，跨DB的数据库迁移一般都会用到重定向恢复，在v9之前的版本，我们需要自己手工来完成重定向恢复的脚本，在v9之后，我们可以使用rebuild的方式来自动生成重定向恢复脚本，相当方便。
在以前的版本里面自己写了一个脚本，来做重定向恢复,现在DB2可以自动帮你生成，做DBA好像越来越简单了.

当然，对于一个完整的软件生命周期管理的解决方案来说，DB2+TSM还是非常不错的选择。

现在DB2V9.7已经Announce，希望新的版本，有新的惊喜。

在一年多以前，我曾经在<<对DB2 V9的疑问>>这篇blog里面提到我对db2v9这个版本的2个feature的疑问。其中一个是在db2v9里面的分区表上如何建立local索引。在和IBM的一些工程师交流的时候，他们好像对这个没啥概念。我也一直觉得这是一个很大的缺陷。在一年多后的今天，参加了一个DB2 9.7 OVERVIEW的conference。我终于在DB2 9.7的release里面看到了DB2 9.7终于有这样一个new feature:”Ability to create local (partitioned) index”

我很欣慰，不容易啊，呵呵。

一个哥们转过来一个问题，一个金融行业的客户在部署应用的时候，发现当应用在作汇总数据的时候，随着数据的增加，处理性能呈非线性的降低，现在在处理到6000万条记录的时候，系统变得停滞，存在大量的I/O Wait.和排序溢出。
接到case后，因为不能直接连接客户的系统上直接察看。所以，我的第一反应是，让系统作一次runstats/reorg。但是客户说，他们每天定时作。于是，我让他们取出”select stats_time, tabname from syscat.tables where tabname = ‘tab_name’，发现果然是比较新的统计结果。没有办法只有让他们发db2support.zip，但是最后客户说他们在内网，大的压缩文件传不出来。晕…，只好让他们先传db/dbm cfg文件过来。发现其中虽然有不合理的地方，但是根据他们的硬件配置来看，不应该导致这样严重的局面。
没有办法，只好让他们把存储过程拿过来看看，发现他们的存储过程，大量的用到游标，然后根据不同的条件，将不同结果集insert到不同的表里面。一个典型的汇总处理过程，没看两眼，我就发现问题所在，客户的存储过程没有用到”临时表”,把这些存储过程改成用到临时表后，把修改后的程序和建立临时表空间的SQL发过去后。让客户重新编译后，客户称将近一亿条的大表处理，都能顺利完成。
可见临时表在大型系统中的数据汇总/排序处理应用中，是相当重要的。
不过，后来这个客户又碰到另外一个问题，也是关于存储过程中对临时表的调用，也蛮有意思的，下次说了。

在Oracle收购Mysql之际，IBM不甘寂寞的推出DB2 9.7 for LUW.虽然这个版本不是一个革命性的升级，但是有一些新的特性，依然值得我们去关注。

从Announce出来的信息来看，在Compress,Partition table，数据库的管理，开发,XML几个方面都有一些新的改进。另外，我们依然在等待SAP对DB29.7的certification.

也许，对我来说，又一个Migration的项目在等待着我(: