关于材料取舍的一些考虑

材料是越收集越整理就越繁杂, 也难以裁减।

本意是通过由浅入深的去分析深入, 但话题的取舍就很有问题, HA的配置, storage的规划, 全面的性能讨论, XML实用级别的讨论, 这都会占据很大篇幅.

所以这里问题就是取舍। 我想了一早上, 想还是放弃本意中宽泛而又希望都有一定深度的选题, 因为那样不容易控制进度,而为了赶工又可能会造成质量下降. 想听听大家的意见. 我初步的意见是改为按照专题讨论, 从安装,配置,backup&restore,HA,performence tuning,troubleshooting这几个方面进行深入的讨论. 这个范围是我们有把握控制好的--我们绝不敢说什么专家意见,我们只是经验之谈和谨慎讨论的结果了.

pureXML我是很有兴趣加进来的, 毕竟这代表了一定的趋势। 硅谷lab那边做xml开发的有几个team, 这是很重要的资源,希望从他们那里能得到一些in depth的资料। 不过,至于实际应用方面,就需要去了解现有的应用+大量的试验了। 这可以作为一个重要的尝试.

Xiaoyi, input your advice,pls.

db2容灾技术

今天有人在打电话问有关DB2的容灾怎么做，大家来一起考虑一下，他的环境是这样的，一个单节点的数据库，使用两台主机做HACMP实现本地的高可用性，另外想在远程的一台主机上为该数据库实现远程的灾备，由于远程没法共享本地的存储，那么是使用HADR的办法还是使用SQL复制（Q复制），还是有其他更好的办法？希望大家各抒己见，讨论一下各种容灾的技术和遇到的问题，在这个帖子里，我们会逐渐的写一些有关的DB2容灾技术和具体实现的办法。

Oracle Vs. DB2 公正与偏见?

今天从成都回来的飞机上看了一份文档, 大概是07年初Edison发布的一个测试报告Oracle 报告 , 还有IBM的回应IBM Response.

这些中间机构也够尴尬的, 谁sponsor就不得不有些倾向; 想保持中立呢, 那还有别家愿意这么出报告呢; 不过这次搞得, 确实有点说不过去了,呵呵। 这不找骂么?!

不过再琢磨一下, 这样aggressive的风格其实很有用的, 因为, 如果对双方产品不熟悉的人是很难分辨的। 嗯, 不管是不是恶人,先告状一定是有先机的। 在这个市场上, 试图以静制动, 后发制人,只能说是想法不错,实际效果恐怕要差的多了।

double md, 又想起去年被人咬了।

注: 这些消息是从Chris Eaton那里看来的, 他也是前面提到那边书的作者之一।

IBM DB2 9 New Features

http://www.amazon.com/IBM-DB2-9-New-Features/dp/0072264594/ref=pd_bbs_sr_2/103-9869891-2259043?ie=UTF8&s=books&qid=1173834965&sr=8-२
IBM DB2 9 New Features

它的作者都是几个做db2十几年的老手了,号称加起来一个多世纪的经验:) 不过我相信这本书肯定不是一个经验show,虽然偶无比希望能有那样一本书--相信也代表了部分民意吧:)

感兴趣的是它对xml等新feature的论述. 不过不知道能讲多深,either internal or field best practice. 老外的书还是太贵了.

24x7 books上不去,但估计现在也不会收录吧.

DB2脚本收集

感谢高卫明高老的建议, 我们做这样一个专题出来। 便于大家检索।

贴出来的最好是测试好的脚本, 可以是伪码, 或者近似能够运行的脚本।

资料收集贴

我想, 有重要的网上找到的参考资料,我们可以把链接放到这里来, 附上简单的介绍। 方便大家查阅।

先贴一个:

高性能SQL http://www।ibm.com/developerworks/cn/db2/library/techarticles/dm-0411rielau/

developerworks上说这个难度是初级,呵呵,不过,建议大家还是好好看看। 这个初级可是没那么容易搞定的:)

典型问题/案例征集

部分问题和案例进入各章节, 由于各种原因不能编入正文的考虑作一个不完全的Faq।

提纲?内容? 大家来说说啊(请回在贴内)

我们想陆陆续续写一点关于db2的东西, 如果有可能的话,那最终会形成一本书।

能否把您的想法告诉我们呢? 比如您希望看到什么样的内容?希望有什么样的深度? 很可能我们现在还达不到,但是我们准备努力的去做了।

谢谢।

一起努力

听了yonghang同学的一些想法，觉得有必要对以往做一些回顾，也是对这几年学到的东西做一些复习和总结，谢谢yonghang同学搭建的这个平台，希望大家能够多一起沟通一下数据库的知识

Welcome YunYi!

欢迎耘毅加入!

Three Years 三年

在team三年了.

04年的时候几乎什么都不会,年底的时候才出了几次差,都是最简单的事情;第一次操作人家的生产环境手都在发抖.

我是一个不大放得开的人,对说话从来没有自信的,至少刚毕业那时候在大家面前做一个自我介绍都能紧张的声音发颤.

加上对自己不熟悉的东西总保持有一份胆怯和怀疑,并且不能快速的接受所谓sales的风格,这样的我在sales school位列bottom也自然是情理之中了.

05年慢慢上手,在team一般能涉及到的基础工作基本上都做了一遍.技术上不再胆怯.

这一年多里面做过很多次培训, 而且基本上都是没有时间进行充分准备的. 第一次就是给五十几个人讲课,非常忐忑,紧张. 但这种也真锻炼人,有过几次之后再走上讲台就感觉越来越从容了. 林老大那时候找我去做培训的时候大概没想这么多吧:)

06年就比较很从容了. 这一年的注意力更多的放在了数据库相关技术上面. 与前两年不同的是,明白什么才是最值得投入精力的. 数据库以外,把AIX好好学习了一番,顺便也就把222/237考了. 还有关于存储的内容. 越来越觉得需要学习的东西很多,而且恐怕也不是一个人能独力抗下的. 但自信心也在增长,做支持做项目心里有谱了. 这一年开始看项目, 才开始明白service的外部环境是如何艰险. 这一年还和某产品sales吵到过BUE那里一次,还是被人家告了.才知道内部原来也有这样的勾心斗角和利益冲突. 原则上我没犯错误,但是总规是坏事,至少可以归结到和各方面交流不够上. 相信这件事情对我在老板们那里留下的印象是很差的, 但是也没有什么辩白的机会,毕竟这也是工作能力的不足। 吃一堑长一智吧. 不过到现在这方面还不能做到应付自如,要多点sales的天份就好办了:)

这份工作虽然很累,但提供的锻炼机会也是非常有价值的. 而且,我现在开始怀疑,是不是真有原先感觉的那么累? 也许是因为这半年在北京的事情多了出差少了而且也不用再每次去客户那里之前都要紧紧张张的准备的原因吧.

总体上说,这三年,收获颇丰.

这三年花在工作上的时间很多, 因为太多需要学习而压力又往往很大. 这几年亏欠最多的就是女朋友,现在偶家领导. 领导其实是很需要人来陪的性格,这几年受了不少委屈.

三年,是一个路口了.

Pain of Small consulting firm

为什么consulting firm很难上市?

关键就在于人.

一两个好手就可以支撑起一个小consulting firm的运转. 而这样的小公司里面,每个人的角色大概都是一顶一的. 离开一个,就会元气大伤. consulting是对特定人才依赖最严重的一个行业吧.

所以一家貌似比较风光的consulting公司比规模较小的做物流的公司要难上市的多.
大的consulting firm呢?也禁不起太多的折腾吧.

想起前不久在mitbbs上看到的讨论各个大学统计学的强弱. 谈到某个本来很牛的统计学系因为关键人才的流失已经沦为二流.

从这个角度看,麦当劳和肯德基真是世界上最优质的business.

还有人心与士气.

士气啊.