Oracle锁与DB2锁的比较

前几天，有个做BOSS的朋友问起这个问题，说DB2的锁机制用起来很不习惯。因为Oracle现在主要在操作型系统中应用比较多，对高并发度上要求很高。据我了解，在国内还没有在电信业务支撑系统上使用DB2数据库的，是不是DB2做不到高并发度呢？
我们就从锁出发，请大家各抒己见，比较一下两者的区别。：）

db2icrt error

Just now,met with a DBI1703E error when issuing db2icrt command.
I checked the db2nodes.cfg, hostname, /etc/hosts, /etc/services and found no problem.
after a short difficult time, customer said they changed the host name...
then, reboot, everything is OK...
some material I get from Internet, also FYI in comments...

DB2 LOGRETAIN

I think most of you is familiar with the ON/OFF/RECOVERY/CAPTURE, but do you know the difference?

OFF --- circular logging, no log retain, no rollforward, no online backup
|
\ /
CAPTURE -- line logging, log retain, no rollforward, no online backup
|
\ /
ON/RECOVERY -- line logging, log retain, no rollforward, no online backup


Jone Casey gives a summary as below:
"let's quickly review the LOGRETAIN options to make sure you understand the functions and requirements of each option. This discussion is intended to help you determine whether the LOGRETAIN value of CAPTURE is appropriate for your environment. Also, a good understanding of SQL replication is assumed (see the Resources section).

The default value for the LOGRETAIN parameter is NO. The NO option provides support for logical unit of work backout, but does not provide support for roll-forward recovery. The log files are managed in a circular manner. This option can be set by either the UPDATE DATABASE CONFIGURATION command or through the DB2 Control Center.

The other documented option for LOGRETAIN is RECOVERY. The RECOVERY option provides support for both logical unit of work backout and roll-forward recovery. The log files are retained to support roll-forward recovery, and you must manage the storage and disposition of the log files. This option can be set by either the UPDATE DATABASE CONFIGURATION command or through the DB2 Control Center. When you change the LOGRETAIN option to RECOVERY, you must take a database backup before the database is usable.

The third and undocumented option for the LOGRETAIN parameter is CAPTURE. The CAPTURE option provides support for logical unit of work backout, but does not provide support for roll-forward recovery. The difference between the NO and CAPTURE options is in how the log files are managed. With the CAPTURE option, the log files are retained so that the DB2 SQL replication Capture program can read changes from the log files. This option does not require a database backup, and the log files need only be retained until the SQL replication program Capture finishes processing the changes contained in the log files. Also, you can only set this option with the UPDATE DATABASE CONFIGURATION command."
by Jone Casey, "Manage DB2 log files in an SQL replication environment"

新上海滩

最近在看新上海滩,看到25集,感觉不错।

这一版里感觉最喜欢的还是孙mm扮演的冯程程,可爱,其实也没甚么大小姐架子,不过也许是因为碰到克星了吧:) 程程在上海滩是个可怜角色.

最认可的是丁力,把这个人物的成长刻画的非常清楚,这样的丁力才比较服众,其实到后期丁力的表现比许文强要好太多了। 不过刚出场够ws,想到后面程程要嫁给这么个角色,真t दौब्लें d不爽। 到后面就开始觉得其实嫁给丁力要幸福多了। 可惜程程心里还要一个酷酷的许文强।

许文强这个人物,当初发哥那一版酷弊,前无古人后无来者। 这一版的黄小明同学倒也够酷,可惜更多是貌似很酷,抬着眼皮看人让你想痛扁之,不过mm们可能更喜欢?:) 前期牛劲冲天,后期优柔寡断还有些妇人之仁। 至于他的感情,太墨迹了,愚蠢透顶। btw他开始出场的时候我怎么看怎么觉得有点象在模仿古天乐। 呵呵। 相比之下,还是丁力让人放心। 许开始的一点匪气在扮酷赚够了mm们的眼光后就消失殆尽,能力消失了,只剩下"吊"了। 死原则,该死的家伙। 开始的时候打天下的时候怎么不说呢? 再说,也没有象他这样替人办事的।要不是有大小姐的原因,我宁愿相信他早就被干掉了!

冯敬尧刻画的我觉得也比上一部成功, 黑道老大,一个不错的父亲, 非常真实।

gloomy day!

such a gloomy day! just like what I am feeling!
sorry to my customer, sorry to my manager and others, I owe you। Thanks to your understanding!

wish everything goes OK soon!

blogspot又被封?

昨天晚上到现在blogspot无法访问। 看来是又被封锁了। 国外的blog服务要在国内发展真是困难重重।
http://www.pkblogs.com/db2miner可以暂时通过这个地址访问blogspot服务।
看来真得找个在国内不会被封的blog服务了

or
add to your hosts file then everything is OK:
72.14.219.190 db2miner.blogspot.com

C++ gurus

Attendees at the C++ Concepts meeting came from both industry and academia. Left to right: Martin Sebor (Rogue Wave), Chris Lattner (Apple), John Spicer (EDG), Herb Sutter (Microsoft), Andrew Lumsdaine (Indiana University), Michael Wong (IBM), Bjarne Stroustrup (Texas A&M;), Gabriel Dos Reis (Texas A&M), Thomas Witt (Zephyr Associates), Mat Marcus (Adobe), Steve Clamage (Sun), Sean Parent (Adobe), Lawrence Crowl (Google), Nathan Myers (Aspera Software), Doug Gregor (Indiana University), Jaakko Jaarvi (Texas A&M), Matt Austern (Google).

曾经的C++ Fans,
还记得这些如雷贯耳的名字么
...

paging space是置于rootvg还是放在盘阵上好呢?

我先来扔块砖, 想听听大家的意见।

----------------

我的考虑

paging space是置于rootvg上好呢还是放在盘阵上呢?
一个前提,我们考虑的情况是,由于某种原因---比如部署了一个新的未经充分调优的应用,甚至只是个别巨大的ad-hoc查询---从而导致较大的paging space使用,如果要说一个数字的话,那么我们考虑30%以上... 当然,这种情况是我们必须极力避免的,我们这里只是考察在这种极端情况下的能够争取的一点点性能.
业务的性质决定paging space的访问模式.我们先考虑BI等olap应用.
使用paging的时候一般伴随着较大数据块的换入换出,对paging的要求和数据空间类似是要求大的数据带宽. 从这一点讲使用盘阵就有比较大的优势.
还有一个考虑, 现在盘阵一般实现为raid5,对写入操作的写惩罚也是必须考虑的. 但是应该记得盘阵上的电池和缓存. 系统对盘阵的写操作应该是以写到盘阵缓存为准,一般不用等待寻道和写入的时间, 这样盘阵的写入IO相比本地盘就又有了额外的优势.
很多时候,我们会对rootvg做mirror,这会给使用rootvg做paging space减分.
一般情况下单台server需要配置的paging space达到128G就几乎是顶点了. 即使是两台server的群集,加起来也没有实际两块硬盘大.
所以,对olap应用,个人倾向于使用盘阵作为paging space,即使没有raid10। raid5相对本地盘,尤其是做过mirror的本地盘应该是有比较明显的优势的।

------------------
HDS的建议

1） HDS存储支持将Paging Space空间摆放在HDS AMS1000存储阵列上。
2） 从HDS 有关HDLM技术文档描述上看，Paging Space的磁盘卷不可以通过HDLM进行管理。这样存在单链路故障导致Paging Space不可访问的风险。
3） 综合考虑，最佳的摆放方法是将Paging Space空间摆放在服务器的内置硬盘上。
--------------------
<---

只有结论,没有分析啊.
1. HDLM为什么不支持? 或者说为什么支持不好? 这是否是因为有什么特殊的设计以至于对特定类型的IO支持不好?
2. 即使使用单链路,盘阵io的优点仍然不可以否认. 交换机与光纤故障的几率就比作为paging的内置盘高? 有数据?
3. 使用内置盘,即使使用mirror仍然不能避免单点. 在运行的时候任何一块盘的损伤都会造成因为数据不一致而虚地址访问故障.
我承认采用内置盘是"传统"上最"安全"的"决策"।但是我希望能够借此机会来澄清也学习一下. 我觉得从paging和盘阵的技术特定以及相关软件的限制来讨论比较好.

恭喜Kimmy和郑智

Kimmy夺冠,ZZ进球,这个周末属于红色:)

AJAX印象

来源

简单的说,就是交互। 客户端从手动档升级到了自动档।

昨天弄blog的模板, 开始觉得做前端技术其实挺幸福的, 因为技术不是大问题, 水平高下恐怕在于谁更有想象力了吧।

现在web和java都到了非常成熟的阶段,来摘点果子吧:)