Tip: 看不到本站引用 Flickr 的图片? 下载 Firefox Access Flickr 插件 | AD: 订阅 DBA notes -- ![]()
2008-08-20 Wed
这几天,在客户处实施Sybase ASE到Oracle 10g的变化数据捕获以及数据转换的前期测试工作,问题此起彼伏,但最终效果圆满,感觉上仿佛遇神杀神,遇鬼杀鬼。不拽了,总结一下遇到的问题以及相应的解决方法。
一. ODI连接数据库阶段
1. JDBC版本 - jConnect 5.5
ODI自带的JDBC驱动无法正常连接Sybase ASE数据库。
解决方法:需要去Sybase站点上下载jConnect 5.5版本,然后将其中的jconn2.jar文件拷贝进ODI安装目录的drivers文件夹中,之后再次选择com.sybase.jdbc2.jdbc.SybDriver,才可以连接。
2. 为什么不选择jConnect 6.05
因为在jConnect 6版本以后,”getColumnName”方法返回的是列的COLUMN Name,而之前的版本都是返回列的ALIAS,而ODI使用的都是列ALIAS,因此如果选用jConnect 6.05,那么在最后执行Interface的时候,将会碰到下面的错误:
com.sunopsis.sql.SnpsMissingParametersException: Missing parameter…
解决方法:使用jConnect 5.5,这也是Oracle lab test时推荐的JDBC驱动版本。
3. JDBC连接串的写法
如果写法如下:
Driver是:com.sybase.jdbc2.jdbc.SybDriver
连接串是:jdbc:sybase:Tds:172.22.224.106:4100/dbemp1
连接时将碰到JZ00L错误,已经确保用户名和密码一定正确:
java.sql.SQLException: JZ00L: Login failed. Examine the SQLWarnings chained to this exception for the reason(s).
解决方法:添加charset属性,修改连接串为 jdbc:sybase:Tds:172.22.224.106:4100/dbemp1?charset=eucgb
最后Physical Schema的设置应该类似如下界面(点击以后放大)。

二. Datastore创建阶段
1. Sun JDBC-ODBC Bridge驱动无法实施反向工程(Reverse Engineering)
因为一开始配置jConnect驱动的时候死活无法连通,因此尝试了Sun JDBC-ODBC Bridge驱动,这种方法需要首先在机器上创建一个ODBC连接,因此也就需要Sybase客户端,所以实际上是不推荐的,而且通过JDBC-ODBC Bridge连接进数据库以后,发现无法执行反向工程。
解决方法:放弃这种方法,换用jConnect连接Sybase ASE。
2. Changed Data Capture
对于创建了唯一聚簇索引的Sybase表也无法启动Journal,必须需要Primary Key。没有主键在启动Journal的时候会碰到如下错误:
com.sunopsis.tools.core.exception.SnpsSimpleMessageException: Journalizing requires a Primary Key on the Table:ODI_TEST
解决方法:在表上创建Primary Key。
三. Interface执行阶段
1. Oracle端表中包含Date或者Timestamp类型的字段时,执行时报ORA-30088错误
如果包含DATE或者TIMESTAMP类型字段的Datastore是由反向工程直接从数据库中reverse生成的,那么对于DAYE字段,默认的Logical Length是7,对于TIMESTAMP字段默认的Logical length是16,那么这样在执行阶段的create work table步骤中,将会按照这些Logical Length来在目标数据库端创建C$_表,而DATE(7)或者TIMESTAMP(16)这样的语法都会报ORA-30088错误。
java.sql.SQLException: ORA-30088: datetime/interval precision is out of range
解决方法:在reverse生成Datastore以后,手工修改DATE和TIMESTAMP类型的字段,将Logical length改为空,Scale也改为空。

2. 执行时,Loading data步骤时报7725错误
在执行Interface的时候,到Loading data这一步,报如下错误:
7725 : ZZZZZ : com.sybase.jdbc2.jdbc.SybSQLException: Cursor ‘jconnect_implicit_2′ was declared with a FOR UPDATE clause. This cursor was found to be read only.
这是花费了最长时间解决的错误,十分感谢Rich Ho何致亿,帮我发邮件到OracleDI的邮件列表中去提问。
解决方法:在Topology Manager中将Data Server的Array Fetch Size和Batch Update Size设置为0,默认是30。
到今天为止,ODI的大致架构和基本功能算是掌握了,更加深入的学习还要看以后这个项目是不是会继续下去了。
Unlike Red Hat Enterprise Linux versions 2.1 and 3, there is no kernel-source package in the Red Hat Enterprise Linux 4 distribution. It was deemed redundant to provide a kernel-source package and a kernel .src.rpm package at the same time. Users that require access to the kernel sources can find them in the kernel.src.rpm file.
In Red Hat Enterprise Linux 4, The kernel-devel package includes the kernel headers files and you no longer require the kernel source package to build a third party kernel module. To install the kernel-devel package run the following command as root user in a terminal:
#up2date kernel-devel
A full source tree is not required in order to build modules against the current kernel you are using. You can simply point your Makefile to /lib/modules/`uname -r`/build. A more detailed explanation can also be found in the Release Notes.
If you require the kernel source package for reasons other than building a kernel module, you can obtain it in Red Hat Enterprise Linux 4 by typing the following as root user in a terminal:
# up2date redhat-rpm-config rpm-build # up2date --get-source kernel # rpm -ivh /var/spool/up2date/kernel*.src.rpm # cd /usr/src/redhat/SPECS # rpmbuild -bp --target=i686 kernel-2.6.spec # cp -a /usr/src/redhat/BUILD/kernel-2.6.9/linux-2.6.9 /usr/src # ln -s /usr/src/linux-2.6.9 /usr/src/linux
Note: This will build the source tree for a x86 based architecture. For different architectures, (i.e. x86_64) pass the appropriate target variable (i.e. rpmbuild -bp –target=x86_64 kernel-2.6.spec )
Once completed, a symlinked directory pointing to the latest Linux 2.6 kernel source should be available:
# ls -lt /usr/src total 28 lrwxrwxrwx 1 root root 12 Mar 2 16:36 linux -> linux-2.6.9/ drwxr-xr-x 20 root root 4096 Mar 2 16:21 linux-2.6.9
Note:The steps are also provided in the Red Hat Enterprise Linux 4 Release Notes: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/release-notes/as-x86/
三年前开始写blog,在大量的阅读以及写blog时的消化和再整理的过程中,感觉对于自己的知识整理有很大的帮助。不过后来发现blog的文章还是太破碎,不利于有条理地整理知识,于是开始尝试使用Wiki。
利用虚拟主机的服务器搭建了一个wiki使用了一段时间,但因为速度原因,一直想换一个桌面版的wiki,让自己更方便地进行知识管理。但我希望这还是一个基于浏览器的Wiki,这样可以方便跨平台的使用,以及进行网络的同步和备份,由于是基于浏览器的桌面使用,我希望最好能够不安装程序、使用环境及数据库。在Wikipedia中研究了一些个人wiki程序后,定位了几个比较适合的程序DokuWiki, Twiki和MoinMoin.
这三个程序都是基于文件的存储,并不需要安装数据库,而且都是基于浏览器使用,方便跨平台使用。DokuWiki和Twiki都分别有无需安装的便携版,其中集成了使用环境,只需要将文件解压缩后就可以直接使用,甚至可以直接放到U盘上随时携带,非常方便。MoinMoin以前也可以直接解压使用的MoinMoin Desktop Edition,不过新版的Desktop Edition要求额外安装一个Python的使用环境。
从三个程序的比较上看,DokuWiki在安装和使用上都最为简单方便,也有很丰富的插件体系和漂亮的模板可以选用,还有我很喜欢的类似维基百科的分节编辑功能,避免在编辑时需要在一长篇文章中找到需要编辑的部分。不过DocuWiki的名字空间稍显复杂,新建条目也不是特别方便,在编辑语法上与其他程序相比较也功能较弱,我也未能在DocuWiki上成功地安装使用所见即所得的编辑器。
TWiki是基于perl的功能强大的Wiki系统,在很多公司中用于内部的企业wiki,界面也很漂亮,页面添加附件功能很方便友好。但是强大的功能同时也使得使用和配置比较复杂,而更糟糕的是Twiki对于中文的支持很差(与桌面版本好像有一定的关系),经常出现有些中文条目无法使用中文作为条目名称的情况,不得不放弃。
MoinMoin基于Python,对中文的支持非常好,代码编辑模式和所见即所得的使用和切换也非常便捷。MoinMoin的宏编辑以及页面模板功能对于提高编辑的效率有非常大的帮助,当然这些宏命令也需要花一些时间去学习。不过新版的桌面版MoinMoin不是一个解压后可以直接使用的版本,还需要额外安装Python。
除了TWiki对于中文的支持有问题而不得不放弃外,MoinMoin和DokuWiki我感觉都比较适合作为一个个人的Wiki工具,进行知识管理。如果只需要简单易用的个人Wiki,可以选择Dokuwiki;如果愿意花些时间学习MoinMoin的宏编辑命令,从而更好地编辑和管理条目的话,可以考虑MoinMoin。而且只要坚持,积少成多,过段时间之后就会发现自己在不知不觉中已经积累了不少的知识,而以前这些知识可能都埋藏在邮件、文章等等各个角落,而得不到很好的组织和利用。
(有关以上三种Wiki工具的更详细的比较可参见WikiMatrix)
据Nielsen Online为美国报业协会(NAA - Newspaper Association of America)所做的用户分析,2008年第二季度,报纸网站平均吸引了近6640万独立访问者(覆盖40.2%的互联网用户),比去年同期增长12.2%。NAA的总裁兼CEO John F. Sturm表示:“最新的受众数据进一步证明,报纸的数字化业务能传递高度精准和高度地方化的内容,而这是消费者在别处找不到的”。
|
Month | ||||||
| Q1 Average |
40.74
|
3,135,005,252
|
47.23
|
44:18
|
8.28
| |
|
Month | ||||||
相比今年Q1的访问统计,Q2的数据并未有明显的增长。


你平常用什么IM工具跟朋友们联系呢,MSN,QQ,yahoo messager 还是gtalk?也或者其中的几个,是不是为每次都要登录几个工具而发愁?既要输入不同的帐号和密码,而且多个工具意味着占用更多的系统资源。今天就给大家隆重推荐一款开源的多协议IM工具-Pidgin
下面是pidgin的一个简单介绍:
介绍
Pidgin(Gaim)是模块化的即时通讯客户程序,同时支持QQ、MSN、Jabber(gtalk)、AIM、Yahoo! 、ICQ、IRC、SILC、Novell GroupWise、Napster、Zephyr 和Gadu-Gadu。
Pidgin(Gaim)基于GTK+,并以GPL 许可协议发行。 支持多平台、多语言、多服务、多插件。
功能
同时登录多个帐户,可以同时登录多个MSN帐号,也可以同时登录MSN和gtalk帐号,不受任何限制。
同时更改状态,已经登录的帐号可以一起改状态,比如一起改为隐身。
好友千里眼的功能,当某好友上线或下线的时候,可以发出问候消息或改为隐身状态,这是可配置的。所有可登录的帐号都拥有这个功能,不再限制于QQ。
同一个窗口放置多个聊天窗口,任务栏上不再有一大片聊天窗口了,当然也可以将聊天窗口分开显示。同样适用于所有的帐号。
多种提醒方式,可以在标题上显示消息数,也可以闪烁窗口,适用于所有的帐号。
好友多种排序方式,可以按字母序,也可以按状态排序,也可以按聊天记录大小排序(独有的功能,明显区分熟悉度),也适用于所有的帐号。
公共分组,所有帐号的好友可以统一管理,QQ和MSN的好友可以放在一个组里,这样方便自己对好友的管理,感觉不到帐号的区别,当然也可以按帐号分组,适用于所有帐号。
隐私设置,可以只让好友聊天,或屏蔽所有对话,分级别设置隐私是独有的功能,同样适用于所有的帐号。
跨平台运行,gtalk、qq等软件没有linux的版本,可以使用Gaim来代替。其它平台也可以兼容。
好了,说了这么多,一定想马上试用一下吧,赶紧下载去吧,Windows版本,如果你想自己进行改进,可以到sourceforge 下载源代码
我自己比较常用MSN,OIC(Oracle Instance Chat),偶尔用下gtalk和qq,下面是我的帐号配置页面。

感谢喷友 书香一隅 的投递
我在一个生物技术企业工作了四年,之前是做市场的,最近一年被老板调到了人力资源部当经理。一年的人事工作经历使我对人性有了更深入的认识,对中国人(包括自己在内)的坏毛病有颇多感慨和无奈。之所以放大说是中国人的劣根性,是因为我相信我下面说的很多特性在国人身上是普遍存在的,发生的几率要高于那些比我们好的国家。我是一个中国人,并不想贬低自己的民族,但我认为我们民族经过这一百年来的动荡,特别是十年文革,教育的确是被歪曲和延误了,国民整体素质处于一个很低的水平。我在下面所发表的言论,既是在揭中国人的伤疤,也是在揭自己的伤疤,但我相信一个人或者一个民族,只有勇于正视自己的缺点和毛病,才有改进和强大的机会。
一、人人相轻
中国人不是文人相轻,而是人人相轻,只要想轻视别人,总有相轻的理由。比如北京人轻视外地人,上海人轻视外地人,城里人轻视农村人,南方人轻视北方人,有钱人轻视穷人,开车的轻视走路的,走路的轻视扫路的,吃饭的轻视做饭的……就是不会相互尊重。
在企业里面,就表现为硕士轻视本科,本科轻视大专,大专轻视中专,名校轻视非名校(靠!中国有什么名校?),干部轻视职员,职员轻视工人。更搞笑的是学理科的轻视学文科的,学文科的轻视学理科的,市场部的轻视技术部的,技术部的轻视市场部的。这不是随口乱掰,我就常听到“他们技术部的水平不行,解决不了什么质量问题”、“他们市场部的人员素质太低了,基本的产品知识都不具备”……这样的废话加屁话。都是一个公司的,别人不行要伸手帮忙,站在那里说风凉话能解决什么问题呢?
说句老实话,在一个公司里面,都是出来打工的,谁比谁高多少呢?何况大家捧着的是一个饭碗。都是中国人,美国人把咱大使馆说炸就炸了,日本人就是不还钓鱼岛,连香港人都说咱们是“大圈仔”,我们还有什么理由去轻视自己的同胞?一个缺乏同情心的民族绝对不会是一个伟大的民族。我每次看见那些吃饱了腆着肚子趾高气昂地骂服务生的人,以及我们公司那些拿着几千块RMB(折合几百美金)的伪白领,以为自己忽然中产了,整个一不知道天高地厚的傻样,就觉得这个国家没什么希望。
我记得以前读书的时候,每次大考,统计总分要精确到小数点后两位,然后依分数排名,根据排名自己挑座位,于是坐前面的就轻视坐后面的,老师还要说“你们坐前面的不要到后面去玩啊!” ,估计中国人爱轻视别人的坏毛病就是那时候养成的。
二、缺乏团队精神
人人相轻,自然学不会相互合作。加之私心重、视野窄、眼光短,所以中国人在企业里面非常缺乏团队精神。
我最近在公司推行绩效考核,有些部门经理不爽了,因为他们一算,自己的奖金要变少,还要被公司考核,于是背后说坏话的也有,开会大吵大闹的也有,不闻不问的也有,种种姿态,不一而足。有同事问我:“不至于那么严重吧,不就是搞绩效考核吗?一个制度而已”。制度本身倒不复杂,但是损害了某些人的个人利益,于是这个事情就变得复杂了。这些经理不会说自己的奖金变少了,而会说本部门的奖金变少了,本部门的风险变大了,或者挑起部门员工对制度的敌意,来对我施加压力。所以一个很简单的事情,就变得非常复杂了。
中国人很少会把团队利益放在个人利益之上。其实在一个企业,团队利益和个人利益是一起的,公司好了大家都好,公司垮了,个人也拿不了几个月薪水。老外很崇尚个人价值,但在企业和组织里面非常遵循个体服从整体的准则,这就是对企业的正确理解。所以中国的职业经理人其实很不职业,就是没有团队精神,把个人或者部门凌驾于整个组织之上。开会讲话都是“我们市场部”、“他们技术部”、“他们物流部”、“他们财务部”,听起来不象是一个公司的,象有仇。我记得有次一个经理为他部门员工薪酬的事情问我“你们公司……”,我当时反问了一句“我们是谁?公司是谁?”他一下子楞住了。
美国人在自家小孩读幼儿园的第一天,回来问的是“你今天为别的小朋友做了什么?”、“你为老师做了什么?”……这就是从小培养合作意识、团队精神。我估计中国的父母可能问的是“你今天喝了牛奶没有?”(担心自家小孩没喝到),“你今天在幼儿园乖吗?”(担心不乖被人打)……所以中国人从小被教育的是强调利己,而不是强调合作。NBA那个嘉得乐饮料的广告语“我有,我可以”被国内企业大肆抄袭,于是“我选择,我喜欢”、“我运动,我快乐”之类的东西到处泛滥,其实这里面就隐含着一种很突出“自我”的思想。我不明白为什么我们中国人老爱做些纠枉过正的事情。一个社会也好,一个企业一个组织也好,应该是我为人人,人人为我。不合作,就是不利己,都强调自己,漠视别人,这个国家不会进步,一打仗大家又要做亡国奴。
缺乏团队精神,企业内耗就多了,在我们公司,有40%的工作时间是去解决内耗的,因为部门间的摩擦太多,个人间的摩擦太多。所以我就感慨,老外几万人的公司都管得好,咱们中国企业百来号人就象一盘散沙,这不是一个管理制度或者管理手段的问题,而是一个文化的问题。中国人的历史就是这样的,老爱自己内部起哄,一跟外人打就完了。私心太重,就不会顾全大局,不顾全大局,就学不会妥协,不会妥协,就天天吵架,你争我斗,企业就在这样的内耗中完蛋了。
三、疑心大,不诚信
做人事经理免不了经常和人沟通,我就发现我们公司的人与人之间特别不坦诚,大家总是相互猜疑,经常听到这样的话“我知道他是这样看我的……”、“他肯定在老板面前说了我的坏话……”、“这个事情我不好说,不想惹麻烦……”,人前不说真话,人后乱说坏话。于是,企业的市场问题、生产问题变成了人际关系的问题,简单的问题搞复杂了。
中国人从小就被教育不要信任别人,到了读中学的时候就会耍政治手腕了,刚才还在一起踢球,转身就找老师打小报告。我的初中班主任就每天轮流安排人写纪律监察报告,中国人活得不阳光,就是这样被教化出来的。
不讲诚信也是从小养成的坏毛病。我妈妈从小教育我不准撒谎,但她自己却没有做到,邻居来借油明明有说没有,答应小学毕业跟我买辆自行车结果没买,经常把公家的电池拿到自己家用……。所以中国人说谎跟玩似的,因为家庭教育跟学校教育都没上好这一课。进了企业,就是对同事不讲诚信,对老板不讲诚信,对客户不讲诚信。我刚做人事经理的时候,很多人跟我说,人事经理就是老板的传声筒,做这个职位只有死路一条,千万不要做啊!我做了一年,发现其实老板没什么大问题,而是他们天生的爱猜疑老板,又不当着老板的面说实话。所以自己营造一个幻象,自己又信得不得了。企业里面的人际关系矛盾都是这样造成的。
我们跟老外打交道,有问题他们会当面指出,不管多难堪,但这并不妨碍他吃饭的时候跟你谈笑风生。所以老外开会,会上可能有10种声音,但会后只有1种声音;中国人开会,会上没人说话,但会后可能有10种声音。我们老板开会结束时通常会问“大家还有什么意见?”全体沉默。一出会议室,跑到自己办公室门一关就开始开部门小会了,靠。
无论在一个社会或是企业里面,诚信度越低,运行成本越高。中国人只信任跟自己有血缘关系的人,很难相信别人,其实是我们社会不够文明的一个表现。
四、蔑视制度
当人事经理的第一天,老板就跟我说:你最大的任务就是把公司的管理制度化。起初还不大理解,后来明白了老板的苦心,公司的各种制度不少,就是基本上没人遵守。这里面有两个问题:一是制度设计本身有缺陷,二是员工意识里根本就没有对制度的概念。
中国人很聪明,但不知怎么把“制度”这个东西(包括制度的设计和遵守)总是搞不好。我是学法律的,我一直认为美国今天之所以这么强大,就是立国时把管理国家的体系和制度设计好了,大家可以安心搞建设。西方人的制度设计有时候是可以用“精妙”形容的,而且对制度的执行在我们看来近乎呆板,而中国人的聪明之处则是在于不管什么制度,都可以把它回避、歪曲、改造,直到这个制度等于没有。
我上任后订了一个考勤制度,规定迟到一次扣10元,第二次40元,累积三次计旷工一天(因为公司的迟到现象很严重)。结果制度出来后,我一看有的员工迟到三次了,想着旷工罚款太重,心一软,就对员工说:“到了第三次迟到就补请一个事假吧,事假总比旷工好,下次不要迟到了”(这是我率先违反制度)。结果有的员工下个月仍然迟到三次,刚开始请迟到后事假,后来请病假(因为病假扣的钱更少),后来每次迟到都请病假,到后来连请假条也没有了,打个电话就完事……我痛定思痛,反思洪水泛滥起因是自己放闸,下了一个通知:“以后迟到一律不准事后补假”。不准事后请假,迟到的员工就把请假条的时间提前一天,反正经理们不管。我那时想到了《鹿鼎记》里面康熙对韦小宝说的一句话:“鳌拜逼朕一步,朕就要退一步,朕实在是退无可退了啊!”。最后实在没辙,宣布“迟到一律不准请假”。实施的当月有个女职员迟到三次,我通知她被记旷工了,她委屈得快要哭起来:“我从小就没有旷过课,现在居然被记旷工,你可以问××经理我那天迟到是因为……”,最后一句是“公司讲不讲人性化管理?!”我坚持不为所动,心想自己就是太讲人性,所以酿成如此大错。
一个考勤制度执行都如此艰难,其它的制度就不用多说了。我上任以来推行制度化管理,其中的辛酸不足为外人道。很多员工暗地里说我是老板的监工,为了讨好老板不惜牺牲群众利益,真是比杜娥还冤。企业从40人变到200人,管理半径变大,价值观的冲突变多,没有统一的制度就会变成一盘散沙。可是我们的经理们凭感觉管理惯了,用制度管理别人不习惯,用制度约束自己不习惯,员工被制度管理更加不习惯,所以上下一心蔑视制度。
我妈妈最小的一个弟弟,就是我的小舅,十八九岁的时候在外面混,经常惹事生非,三年之内被警察抓了9次,平均一年三次,然后我妈妈次次都把他成功地营救出来了。只要他一出事,我妈妈就会到处找关系(我认为她在那个城市简直有一个关系宝库),比如哪个的爱人是刑警队的,哪个的姐夫是爱猫扑,爱生活局的,备好礼送过去,我那个混江湖的小舅就得意洋洋地出来了。所以我很小就有这样一个概念,办什么事都要找关系,有关系犯法了也不怕。
前年我那个小舅被判了7年,出来后40岁,这辈子估计基本废掉了。我想就是他因为以前在我妈妈的包屁下,习惯性地蔑视国家法律制度。所以说,制度决定习惯,习惯决定性格,性格决定命运。
五、政治敏感度太高
我在公司跟员工谈话,结尾通常会说:“今天我跟你谈话的意思只是这个事情本身,没有别的意思”,听起来有点绕口。为什么要这么说?因为他们非常敏感。你说他哪些方面需要改进,他会联想到公司是否想炒他;你问他们部门的工作量是否饱和,他会联想到公司是否想炒他;你问他最近有没有继续进修的打算,他会联想到公司是否想炒他。他可能根本不在意你跟他谈话的内容,而是花很长时间来琢磨为什么要炒他。
中国企业的内耗多,有个原因是说实话的成本太高。大家喜欢猜来猜去,相互间不信任,本来只是工作上的问题,非要上升到政治的高度,所以都不说实话。比如我对一个经理说“你处理这件事情有问题”,他可能会联想到我不喜欢他这个人,有意针对他。然后他会思考我为什么不喜欢他,是不是上次请客没有叫我?最后一定会找出一个理由来,于是误解就造成了。
有个故事说,一个人去找邻居借斧头,可是他觉得邻居与他有些矛盾,不知道会不会借给他,所以边走边想,越想越气,最后跑到邻居的门口说:“你不用借斧头给我了!我才不会求你!”
我就是一个典型的特“含蓄”的人,有事爱闷在心里不直接说,自以为这是顾及别人情绪,是一种修养,其实很误事。我曾经不喜欢我的一个下属到了极点,有段时间我每天都想炒掉他,而且这个想法象条毒蛇一样越缠越紧。但我强迫自己做了两件事:第一是站在他的角度来看我有什么问题;第二是坦诚地跟他交换意见。结果两人一摊开说,就那么点事,大家还有继续合作的机会,结果我们又共事到今天。
所以我现在强迫自己说实话,说出来至少还有消除误解的机会,不说连机会都没有了。
中国人的政治敏感度太高,多半是文革那会遗留下来的,再就是东方人特有的含蓄。不是说含蓄不好,非要学老外在大街上裸奔,但是含蓄得过了头,就显得有些小气和阴暗了。其实相互不信任会活得很累,自己累,别人也累。哪里有那么多的弦外之音?就事论事就完了。
谈恋爱可以把简单的事情搞复杂一点,千转百回都行,办企业也这样,就会影响效率。中国人在企业里面,怕着怕那,提防心太强,往往把简单的事情搞复杂了。其实说穿了,人都很简单,都是吃五谷杂粮长大了,哪有那么可怕?都是你怕我,我怕你,相互间怕出来的。
一个企业里面的政治气味太浓,跟老板也有关系。如果老板的控制欲太强,且以支配比他学历高的职业经理人为乐,那这个企业就极有可能成为清宫戏里的朝廷,明争暗斗,不亦乐乎。中国的民营企业搞着搞着就这样了,所以搞不长。
没有一个环境是完全纯净的,发生政治行为也很正常,有人的地方就会有政治,但要控制在一个适当的程度。政治行为太泛滥了,就会损害诚信。
六、犯“君子”错误
这个世界上真正的坏人不多,就象真正的好人不多一样。但中国人很喜欢把“好人”与“坏人”这个本身就很模糊的道德标准去评判一个人的企业行为。公司要炒人,就会有员工说:“他人很好,公司为什么要炒掉他?”拜托,如果只有“坏人”才能被炒,请告诉我“坏人”在哪里?我从不认为我们公司的员工中有坏人,我只评判他是不是合格的企业人,如果他搞婚外情或者同性恋,那是他的价值观和性取向的问题,并不能以此判断他对公司的价值。如果对公司没有价值,雷锋我也不会要。
我在公司的绩效考核制度中规定,每个部门每年必须有5%的员工被评为不合格,实际上我最初定的是10%,但后来所有的经理都反对,只好降低标准。即使是5%,经理们也不愿执行,他们对我说:“如果我的部门员工都合格,你一定要弄出个5%,怎么办?我只好安排员工轮流做庄了”。他们说得理直气壮,因为觉得自己是君子,对得起身边的兄弟们。我的回答是:“GE公司的淘汰率是20%,你认为我们公司的员工都比GE的员工优秀?”
真正的错事10件中有9件是君子犯的,比如毛泽东与文革,斯大林与大肃反,小人并没有多少犯错的机会。中国人往往给“君子”一个错误的定义,然后用它来掩盖事实真相。如果一个经理在符合组织利益的前提下做“君子”,与员工讲情义,这绝对是一件好事,但如果是违背组织利益去对员工做人情,那么这个“君子”不仅毫无价值,简直形同犯罪。
比如法律是最低的道德标准,但它是一条明确的线,你可以在这条线上做得更好,但你不能在线下。所以老外讲“法理情”,把法律摆在第一位,但并不是我们在中学课本中学到的“腐朽的资本主义社会里,只有赤裸裸的金钱关系,没有温情……”,他们只是先把人性定为“恶”,再用法律和制度来预防;中国人讲“情理法”,先把人性定为“善”,出了事再事后惩罚,结果法律没有遵守,人情味也越来越淡薄,医院可以看着病人死,行人可以站在大街上看着歹徒杀人,老外可以实行弹性的工作时间制,因为他们的员工主动性和自律性比咱们强,“领老板的薪水对老板负责”是基本的职业道德,就象在国外有的街道,红绿灯由司机自己按,因为遵守制度已经融入他们每个人的血脉中;要是在国内企业搞弹性工作时间,我相信90%的企业会死得很惨。中国的司机连红灯都敢闯,你叫他自己按红绿灯,他会一直按绿灯到自己不开车的那一天。
国内企业为什么很难做好绩效考核,因为中国人喜欢做烂好人,不愿对别人作负面评价,所以绩效考核搞不下去。其实在当“君子”的背后,掩藏的本质是我们的经理人缺乏自信,害怕对下属作负面评价会引起下属反击而已。
七、推卸责任
我们公司的经理总抱怨老板不授权,权力太小,无法管理员工。可是遇到真正麻烦的时候,他们会把问题往老板那一交:“你看怎么办?”这些经理不会去想,他拿的薪水比员工多,权力比员工大,那么问题就应该到他为止,不然老板要你做经理干什么?可是他们总是把权力与责任分开,权力就是拿的钱多,管的人多,没想过其实权力和责任是对等的,你有多少权力,就要负起多少责任。
在我们公司,人事和财务工作不好做,因为这两个部门代表公司行使职权,最容易被经理们“转手”责任。当你正常过问他们事务的时候,经理们会很反感,认为你触犯了他的一亩三分地,挑战了他的权力;可是一碰到员工要加薪、预算被削减这样的事情,他们就会说:“你加薪我是同意的,可是人事部不同意!”、“花这个钱我是同意的,可是财务部不同意!”。其实决定是我们跟他们一起下的,但出现问题的时候他们不去与员工沟通,把责任和矛盾推卸到我们头上。
推卸责任的一个潜在心理意识是,看不见自己的问题。中国有句古训:“知天知地知彼易,知己难”,意思是人可以知道除自己以外的任何事情,就是不可自知,说得真好。所以我们公司搞培训的时候,大家群情激昂,有如醍醐灌顶,可是一回到工作中,该犯的错继续犯。因为培训那会老师讲的问题他全分析到别人头上去了,所以出了问题自然是别人的责任。
破坏环境是中国企业最推卸责任的做法。企业以牺牲环境为代价得到1块钱的利润,也许我们后代用100块钱的代价也不能弥补。所以老外推行iso14000(环境管理体系)认证,表面上是一种标准,其实就是企业对保护环境的一种承诺,是企业所应承担的社会责任感。我们的企业自己对社会推卸责任,怎么去要求员工对企业负起责任?
八、缺乏包容性
有句话说一个人的成就有多大,取决于他的胸怀有多大。做了人事经理后,我对这句话的感受尤为深切。
我们公司有个部门经理,在公司创立初期为公司做了很大贡献,公司也一直努力想培养他。但他的心眼特别小,私心特别重,毫无包容精神,这是一个很要命的缺点。他几乎永远站在自己的立场去理解任何事情,比如,他认定他的上级(总监)不如他,但年终奖比他高,令他无法容忍,所以他经常跑到老板那去说上级的坏话。我跟他说,别人能做你的上级,肯定有他的长处,即使别人有问题,你也应该与他达成谅解和共识,原因很简单:你们是为一个目标工作,而且他是你的上级。可是一直到今天,他还在固执地寻找一切机会攻击他的上级。组织行为学里面有句话说“屁股决定大脑”,就是本位主义,他的大脑就完全被他的屁股(个人立场)控制了。
我曾经跟老板开玩笑,评价他为“武功尽失,经脉全废”,意思是基本失去教育意义,无可救药。无论他的工作热情有多高,能力有多强,他不可能走到更高的管理岗位,这就是“性格决定命运”。我甚至断定他在生活中也不会取得成功,至少有一个论据可以证明:他33岁了,至今还没有女朋友。
与自己不喜欢或不喜欢自己的人相处,是对胸怀的一个极大的考验。做大事的人的胸怀都是被反对者撑大的,就象李敖所说“男人的胸怀是被女人撑大的”一样。摩托罗拉的总裁高尔文喜欢驾船航海,万科的总裁王石喜欢登山,那都是练胸怀去了,人面对大海和高山的时候,心胸自然开阔,连心思都要透亮些。所以我总劝员工在工作之外多想想生活,多见见世面,多长长见识。老窝在办公室那点地方,做手头那点事情,怎么大气得起来?有点事就急了。
我们搞计划生育,人口是控制住了,但另一方面,独生子会从小失去考验自己包容性的机会。人要在一个环境中才能碰到矛盾,而人一生中要不断地碰到矛盾,没有包容精神,一碰到不利自己的事情就跳,怎么跟别人合作?怎么解决矛盾?所以中国人缺乏团队精神,也和包容性有关。
九、缺乏文化性
把包容性再延展开来说,就是文化性。人类创造的文化包括科技文化和人文文化,它们分别发展着工具理性和价值理性,我这里说的是后一种。
我曾经看到这样一个案例:一个中国人在一家国内的跨国公司工作,有一个到海外出任分公司ceo的机会,结果公司把机会给了一个他认为专业技能、学历背景都不如自己的老外。他去问老板,老板说:因为公司觉得那个老外有更高的人文修养和更开放的心态,而到一个不同的国家,面临不同的文化和价值观发生冲突的时候,需要他把各种文化和价值观糅合在一起,去实现公司的目标,这远比技能重要。这个案例给了我很深的启示。
我始终认为,中国过了“五四”运动以后就基本没有文化了,到了文革就更加把以前的文化都丢了。其实中国的儒家文化有很多好的东西,结果我们没有发扬,却被新加坡发扬了,被韩国发扬了,最坏的是被小日本发扬了。
也许中国人穷怕了,好不容易赶上改革开放,所以功利得有点过头。我周围的很多职业经理人用各种证书、mba学历把自己武装到牙齿,恨不得一个个都变成经济动物,谈起工作都是专家,就是不会与人相处。前几天我跟一个公司的同事聊天,他说大学毕业后6年时间里,他没有读过一本小说。
中国人喜欢形式主义,以为发扬文化就是上硬件,比如搞几个艺术节,修几座古庙,找几个和尚念念经。人民到了放长假的时候在人山人海里遛一圈,就以为自己文化了。其实文化不是这些物化的东西,它是一种精神的力量,是以人为载体的。穷不是不要文化的借口,因为没有文化会更穷。中国的企业做不长,做不强,技术和管理是表象,真正的原因是缺乏企业家精神和企业文化。别人搞了一百多年市场经济和企业,那种文化传统和底蕴是一种气质,不是画个浓妆就学得会的。现在国内有些企业一进去要军训,要把企业编的文化手册倒背如流,那不是企业文化,是受迫性洗脑。
跟中国的员工谈文化素养,谈人性关爱,他们多半以为你有病。他们会说,公司的氛围不好,沟通不通畅,执行力不强,但不会去想这是文化的原因。中国的企业家一有钱就忘本,就嚣张,要写书,要设论坛,要开名车,住豪宅,包二奶,骂警察,就是没想过回馈社会,也是缺乏文化性。
学历和技能是衡量一个人的硬件标准,但真正决定一个人命运的是他的软件,是一种性格和态度,是文化。所以老外招聘员工的时候,强调“沟通能力”、“团队精神”、“心理承受能力”等这些东西,就是他们更注重一个人内在的素质,这才是决定个人价值的关键。
结束语:本人今年28岁,自己还把自己归于愤青行列,所以行文有偏颇之处,亦可见谅。文章既来自生活,又超越生活,大家不必以此文来质疑我作为一名人事经理的心态。既是网络,大家各取所需,不必望文生义。说到对本文所列问题的解决方案,我想,认识问题是解决问题的第一步,也许答案就隐藏在问题之中。最后,我以我非常喜欢的一段话结尾,与大家共勉:
“谁都不是一座岛屿,自成一体;每个人都是那广袤大陆的一部分。如果海浪冲刷掉一个土块,欧洲就少了一点;如果一个海角,如果你朋友或你自己的庄园被冲掉,也是如此。任何人的死亡都使我受到损失,因为我包孕在人类之中。所以别去打听丧钟为谁而鸣,它为你敲响。”
来源:mop社区
喷嚏网推荐:
触及巅峰(20周年纪念版) | 进入空气稀薄地带--登山者的圣经 | 池莉育女心经:来吧,孩子 |如何说孩子才会听怎么听孩子才肯说 | 人性的弱点全集 | 人生中不可不想的事 | 像艺术家一样思考(白金版) | 悲观主义的花朵 | 乌合之众:大众心理研究(最新版本) | 赢遍全世界--沃尔玛创始人萨姆•沃尔顿10堂课 | 六人行完整视频版(赠DVD和同步MP3)
这两天看了几篇赞美中国金牌的文章,当然赞美中国金牌不能只赞美到运动员头上去,一定要向国家荣誉那边靠,顺带着就连国家培训运动员的制度也一并赞美了。对此,我实在不能苟同。
最常见的说法是,金牌数证明了中国的强大。
这个逻辑跳跃太大了一点,我跟不上思路。中国动用国家财政培养出来的运动员拿到的金牌和这个国家的体育水平有什么关系?体育水平又和国力有什么关系?
拿了一堆金牌后,除了面子上好看,普通大众究竟能够得到什么好处呢?就算吃下一瓶子的伟哥,也不能真的强身健体啊。
有人说金牌可以转移大家的注意力,这个倒是真的,伟哥不就有这个功能吗?不明白这话说出来是真的在赞美中国的精英体育培训制度吗。
有人说金牌可以鼓励大家去运动。据我所知,我们奥运会上拿金牌的都是些由国家培养的专业运动员,这和大众运动有什么关系?如果要增强国家体育水平,政府应该做的是加大全民健身的基础设施投入,而不是恰恰相反地用这笔费用去培养少量精英运动员。众所周知,曲线救国路线是婊子的谎言。
有人说国外的运动员也有很多是职业运动员,例如NBA。说这话的人分得清什么是职业运动员什么是专业运动员吗?一个花的是自己的钱,一个花的是纳税人的钱。而恰恰是越商业化的运动,越能看出中国的实际体育水平,例如男子足球。
甚至还有人搬出前苏联来说事,这是最无脑的说法了。苏联(或者说俄罗斯)在结束了一党的统治后,再也不能随心所欲的动用纳税人的钱,所以只能停止这种精英培训机制,真实的体育水平就体现出来了。现在还有几个国家能够继续这样的机制呢,中国和朝鲜。在这一点上倒是直指问题的核心。
我曾下决心在写文章的时候不做智商歧视,不过真正写起来的时候常常忍不住。所以不详细谈这个问题了。转帖一篇其他人写的文章,点击链接打开:《对scutpump《金牌战略不是这么个挑剔法》的挑剔》

这是一篇讲解初创公司在创立之前需要注意的几个问题。我翻译了其中关于融资的两个小节,因为讲的比较清晰。
原文:Startup, Inc - What You Need to Know Before Starting a Company
作者:Alex Iskold
部分译文:
风险融资(Venture Financing)
要把你的点子实现为一家公司,你很可能需要融资。本质上这等于是把股份卖给投资者。一家典型的公司通常要经历几轮融资,包括天使投资,以及随后的几轮风险投资。天使投资这一轮投的钱通常很小,大约小于100万美元,现在变得更少了(要感谢YCombinator和TechStars)。在天使投资 - 也叫种子投资 - 阶段,创立者可能要付出10-15%的股份以换取可转换贷款(convertible loan)。操作上,往往这时不是直接的卖股份,而是如果今后公司盈利,需要下一轮融资时拥有以折扣价购买股份的权利。
传统的天使投资者是富有的个人,通常是过去在大公司任职的成功的企业家和管理者。每一个天使投资者大约会投入1-10万美元的资金,通常在2.5-5万之间。所以如果你想融50万美元,你需要找10位甚至更多的天使投资者。或者你可以找到专业的机构来使之变得更为简单,比如New York Angels。
下一轮的融资叫做Series A,此时会包括VC。VC通常是以合伙人制的方式来管理一个投资基金。投资基金融到资金投资到初建公司或者是发展了一段时间的公司。
VC的世界很复杂,有必要对他们的运作有所了解。
第一条规则:知道在什么阶段找什么样的VC最适合你。合适的VC是对你所在的行业感兴趣,并且投资的金额也恰当。各地的VC管理着1.5 - 10亿美元不等的基金,其中一个典型的投资于科技领域的基金大约会管理3000万美元。由于VC的合伙人时间有限,所以总的投资数量也就那么多。所以如果是寻找50万的资金,找VC那是找错人了。
一家典型的VC从进入到退出你的公司,一般会寻求占有20 - 30%的股份。当投资者把钱投入你的公司,他们会寻求保护自己的方法以应对你的公司变糟的情况。他们会要求建立优先股(preferred stock),优先股相对于普通股 - 也就是你持有的股份 - 附带有不同的条件。优先股享有优先套现权,并且拥有否决你卖掉公司的权利,当然,有时是强迫你卖掉公司的权利。
VC通常会选一名董事到董事会,通常是和你合作投资事宜的合伙人。在公司的早期,一家VC会扮演辅导CEO的角色,推动公司的发展。当公司逐渐成长,甚至成为一家公共公司时,来自VC的这名董事会退出董事会。
更多的融资(More Funding)
每一轮融资使得参与的VC的数量增多,股份也被稀释。要理解股份稀释,你需要首先理解初创公司的融资机制。每次融资是发行新的股份卖给投资者。通常投资者不会买入你已经拥有的股份,他们买的是新股。
融来的钱不会进入你的口袋,而是进入公司。有些情况下投资者会购买你手中的股票,不过这很少发生。每轮融资后,创立者和雇员拥有的股份的百分比会减少。早先的投资者能够通过优先股赋予他们的权利买入新股,以保持其对公司的所有权。
尽管创业者不愿意把公司的所有权相让于VC是个众人皆知的事实,但这样做是符合经济学规律的。即使你拥有的百分比下降了,整个的股份价值在融资后变大了,因为每份股份的价值变大了。只要公司运行良好,融资就是合理的,并且员工也能从中受益。
The previous post might have given the impression that you shouldn't pay too much attention to the values in the "Time (S)" column of the Top 5 Timed Events section of a Statspack or AWR report*. That's not true, particularly when comparing system workload between two different periods. (I was just building up to this slowly
As Chen pointed out in her comment on the last blog, there's a direct relationship between the number of sessions that were running during the reporting period and the total time values. No matter how busy the system, the total time available can not exceed the maximum number of concurrent sessions * wall clock duration that they were running. That's a hard limit, but there are other relationships, too. If you think about it, as the number of active concurrent sessions increased from one to four so did the database instance's workload as more sessions were either working or waiting for something and, if the database is working on something then that implies the application is waiting for it to complete! In all likelihood on a small laptop with limited resources, the actual time spent waiting on individual events would increase as well, as contention for resources increases. Both an increase in the duration of events and an increase in the number of different sessions running or waiting on events will increase DB Time.
Here's a definition of DB Time that you'll see in various presentations from the Oracle guys who worked on this. (e.g. John Beresniewicz's excellent presentation "Average active sessions: the magic metric?" which is available on Kyle Hailey's website. I've never seen JB give the presentation, but I love the slides.)
Database time is total time spent by user processes either actively working or actively waiting in a database call
The same presentation describes the components of DB Time as
Time spent in the database by foreground sessions
Includes CPU time, IO time and wait time
Excludes idle wait time
In the context of a Statspack or AWR report, the top 5 timed events section is showing you the top 5 contributors to DB Time. (In fact, what I find most interesting about the latest versions of the Statspack report is the increased focus on time. For example, the first section of top SQL statements by resource consumption is ordered by DB CPU, followed by the SQL ordered by Elapsed Time, before we get anywhere near Logical or Physical Reads. Regardless of whether you're licensed for the Diagnostics Pack and have access to ASH, AWR and ADDM, you can still take advantage of some of the instrumentation improvements - Event Histograms, for example - and it's clear that Oracle is increasing its focus on time.)
Note that, although I'm choosing to write about aggregated system-wide values as a performance indicator because it's one convenient use of DB Time (particularly when comparing two different periods of time that might be seperated by months or when you have hundreds of systems to support or, most important, if you're writing a tool like ADDM.), I don't think there is anything inherently system-wide about DB Time. If you insist that the only valid performance analysis is that carried out at the session level then, make no mistake, DB Time is recorded for each individual session. It can be used as the input to response time tuning and is really just the Oracle Servers recording of the R in R=S+W. i.e. it's equally useful for Response Time tuning at the session level. In fact, I wish it had been called DB Response Time but I understand that even mentioning 'Response Time' might have led to the argument that the Database Server is only one component of the user's end-to-end response experience and that Response Time doesn't make sense as a term for data that's going to be aggregated for multiple sessions in some cases. (i.e. Can an entire instance have a aggregated Response Time?)
DB Time is the most important of the various Time Model Statistics, which break down the Service component of R = S + W into more detail. Here are the Time Model statistics from the Statspack report for the single-user test. (Don't forget that, as always, this is just reporting underlying statistics. In this case, these statistics are also exposed via v$sys_time_model and v$sess_time_model)
Time Model System Stats DB/Inst: TEST1020/test1020 Snaps: 22-23
-> Ordered by % of DB time desc, Statistic name
Statistic Time (s) % of DB time
----------------------------------- -------------------- ------------
sql execute elapsed time 282.9 88.0
DB CPU 57.4 17.9
PL/SQL execution elapsed time 7.8 2.4
parse time elapsed 6.2 1.9
hard parse elapsed time 4.6 1.4
hard parse (sharing criteria) elaps 2.3 .7
hard parse (bind mismatch) elapsed 0.6 .2
PL/SQL compilation elapsed time 0.4 .1
connection management call elapsed 0.0 .0
repeated bind elapsed time 0.0 .0
sequence load elapsed time 0.0 .0
DB time 321.5
background elapsed time 249.4
background cpu time 2.3
... and here are the Time Model stats from the Statspack report for the four-user test
Time Model System Stats DB/Inst: TEST1020/test1020 Snaps: 24-25
-> Ordered by % of DB time desc, Statistic name
Statistic Time (s) % of DB time
----------------------------------- -------------------- ------------
sql execute elapsed time 779.5 64.8
DB CPU 107.7 9.0
PL/SQL execution elapsed time 15.7 1.3
parse time elapsed 2.8 .2
hard parse elapsed time 2.2 .2
hard parse (sharing criteria) elaps 1.1 .1
hard parse (bind mismatch) elapsed 1.1 .1
connection management call elapsed 0.1 .0
repeated bind elapsed time 0.0 .0
sequence load elapsed time 0.0 .0
DB time 1,202.4
background elapsed time 408.3
background cpu time 2.7
(For someone who asked me this question recently, DB CPU is just the value you would see in the CPU row of the existing top 5 timed events section although I understand that CPU measurement has been improved significantly in recent versions.)
In this case, there's a relationship between the number of people trying to do something and the total amount of DB Time consumed for a given wall clock duration. If we divide DB Time by the Wall Clock time, we're left with the average number of active sessions during the period. If I apply this first to the single-user test, using the values from the Statspack report :-
Elapsed Time (from report header) = 5.95 minutes = 357 seconds
DB Time (from Time Model Statistics) = 321 seconds
321/357 = 0.89 Average Active Sessions
and, for the four-session test :-
Elapsed Time = 5.5 minutes = 330 seconds
DB Time = 1202 seconds
1202/330 = 3.64 Average Active Sessions
Clearly, the instance was a lot busier during the four session test.
Why weren't the values exactly 1 and 4? Well, for starters, the Statspack reporting periods were slightly longer than the test run period as I executed snapshots manually in a sqlplus session. Therefore there was a period of time in both reports when the server was dead quiet. There is also the application overhead of Swingbench running the benchmarks and submitting the calls to Oracle. Oracle can only sensibly record the time when it's actually doing work on behalf of the application, not when the application is doing it's own thing, processing the results of the last database request. None of the database sessions in this test that were performing many small transactions was active for 100% of the time.
But that's only one part of the relationship. In this case, the instances workload has increased because more users are working at the same time, but there's more to performance problems than that. How about a different example? Imagine a single user is running a single query that takes 2 minutes to complete. The session has been connected for 20 minutes, most of which has been idle, waiting for the user to submit the query. If we look at the session-level information (using v$sess_time_model), we'd see something like this.
DB Time = 120 secondsi.e. DB Time shows us 'the Oracle bit' that we might be able to tune. The goal of the DB Time Performance Method that Graham Wood presented at last year's UKOUG conference (amongst others) is to reduce the amount of DB Time taken to deliver the same results. So, how can we reduce DB Time here? By making the query run more quickly, whether it's through tuning it to do less work, or increasing the efficiency of that work by reducing bottlenecks. Regardless of *how* I improve the performance of the query, let's say I happen to make the query run in 50 seconds.
DB Time = 50 secondsThe end user's experience has improved.
There's a lot more I could say about DB Time. Like all of the best performance concepts or methods (e.g. YAPP, Method-R) it can seem so obvious as to not be worth saying, but contains an enormous amount of common sense and technical rigour. I suppose one important aspect of DB Time that I would highlight is that it's a common currency for ADDM. If you were to write an automatic performance diagnostic tool, what would be your goal? To reduce the time that any particular action takes, whether that's by eliminating a bottleneck at the server level, or in the instance configuration or a particular part of the application code. By combining ASH and AWR data using DB Time as the key measurement, ADDM can focus on the actions that will deliver the most significant response time reductions, whether they be more CPU or disk resource, tuning individual SQL statements or eliminating locking issues. Because DB Time can be aggregated at many levels (e.g. Session, Service, Instance) , it can be used in a number of different ways, depending on what data is available and what the goal of the optimisation exercise is.
DB Time - it's the future
In the meantime, here are the slides from a couple of other presentations that cover DB Time in much more depth than I have here. Until Graham Wood starts that blog of his (hint, hint) these are the next best thing.
http://doug.nl/downloads/OGH20080410_GRAHAM_WOOD.pdf
* Of course, some people would say that you shouldn't pay too much attention to any values in Statspack reports, but they've worked so many times for me that I'll stick to my view that they're not worthless. In any case, you have a balancing contrary view.
根据我最近测试的结果,Red Hat Enterprise Linux(RHEL)AS 5.2 在功能方面远远优于 Ubuntu Server Hardy 8.04.1(LTP 测试结果:RHEL AS 5.2 - 5 fails, Fedora 9 - 7 fails, Ubuntu Server Hardy 8.04.1 - 32 fails),在性能方面也比 Ubuntu Server Hardy 8.04.1、Fedora 9 分别高出 3% 和 20%(同样硬件平台上运行 SPECjvm2008 的综合结果)。由此可见,Fedora 和 Ubuntu Server 相对于 RHEL AS 的唯一优势,只剩下方便的软件包更新功能了(欢迎购买 RHEL AS Subscription:US$1,499 / year) 。
如果既想获得 RHEL AS 的高质量、高性能、高可靠性,又需要方便易用(关键是免费)的软件包更新功能,那么 Fedora Project 推出的 EPEL(Extra Packages for Enterprise Linux)正好适合你。
EPEL(http://fedoraproject.org/wiki/EPEL) 是由 Fedora 社区打造,为 RHEL 及衍生发行版如 CentOS、Scientific Linux 等提供高质量软件包的项目。装上了 EPEL,就像在 Fedora 上一样,可以通过 yum install package-name,随意安装软件。我们前面提到的 Func、Cobbler 等软件都能在 EPEL Repo 中找到。
安装 EPEL 非常简单:
* RHEL 4: su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/4/i386/epel-release-4-9.noarch.rpm'
* RHEL 5: su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm'
安装完毕之后,即可使用 yum 来安装软件,比如 Nagios:
yum install nagios
若要查看 EPEL Repo 中是否存在某个软件包:
yum search package-name
如果找不到,那就提交给 Package wish list,等待软件维护者制作 EPEL rpm 吧: http://fedoraproject.org/wiki/EPEL/WishList
根据我最近测试的结果,Red Hat Enterprise Linux(RHEL)AS 5.2 在功能方面远远优于 Ubuntu Server Hardy 8.04.1(LTP 测试结果:RHEL AS 5.2 - 5 fails, Fedora 9 - 7 fails, Ubuntu Server Hardy 8.04.1 - 32 fails),在性能方面也比 Ubuntu Server Hardy 8.04.1、Fedora 9 分别高出 3% 和 20%(同样硬件平台上运行 SPECjvm2008 的综合结果)。由此可见,Fedora 和 Ubuntu Server 相对于 RHEL AS 的唯一优势,只剩下方便的软件包更新功能了(欢迎购买 RHEL AS Subscription:US$1,499 / year) 。
如果既想获得 RHEL AS 的高质量、高性能、高可靠性,又需要方便易用(关键是免费)的软件包更新功能,那么 Fedora Project 推出的 EPEL(Extra Packages for Enterprise Linux)正好适合你。
EPEL(http://fedoraproject.org/wiki/EPEL) 是由 Fedora 社区打造,为 RHEL 及衍生发行版如 CentOS、Scientific Linux 等提供高质量软件包的项目。装上了 EPEL,就像在 Fedora 上一样,可以通过 yum install package-name,随意安装软件。我们前面提到的 Func、Cobbler 等软件都能在 EPEL Repo 中找到。
安装 EPEL 非常简单:
* RHEL 4: su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/4/i386/epel-release-4-9.noarch.rpm'
* RHEL 5: su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm'
安装完毕之后,即可使用 yum 来安装软件,比如 Nagios:
yum install nagios
若要查看 EPEL Repo 中是否存在某个软件包:
yum search package-name
如果找不到,那就提交给 Package wish list,等待软件维护者制作 EPEL rpm 吧: http://fedoraproject.org/wiki/EPEL/WishList
mysqlslap是一个mysql官方提供的压力测试工具。以下是比较重要的参数:
–defaults-file,配置文件存放位置
–concurrency,并发数
–engines,引擎
–iterations,迭代的实验次数
–socket,socket文件位置
自动测试:
–auto-generate-sql,自动产生测试SQL
–auto-generate-sql-load-type,测试SQL的类型。类型有mixed,update,write,key,read。
–number-of-queries,执行的SQL总数量
–number-int-cols,表内int列的数量
–number-char-cols,表内char列的数量
例如:
shell>mysqlslap –defaults-file=/u01/mysql1/mysql/my.cnf –concurrency=50,100 –iterations=1 –number-int-cols=4 –auto-generate-sql –auto-generate-sql-load-type=write –engine=myisam –number-of-queries=200 -S/tmp/mysql1.sock
Benchmark
Running for engine myisam
Average number of seconds to run all queries: 0.016 seconds
Minimum number of seconds to run all queries: 0.016 seconds
Maximum number of seconds to run all queries: 0.016 seconds
Number of clients running queries: 50
Average number of queries per client: 4
Benchmark
Running for engine myisam
Average number of seconds to run all queries: 0.265 seconds
Minimum number of seconds to run all queries: 0.265 seconds
Maximum number of seconds to run all queries: 0.265 seconds
Number of clients running queries: 100
Average number of queries per client: 2
指定数据库的测试:
–create-schema,指定数据库名称
–query,指定SQL语句,可以定位到某个包含SQL的文件
例如:
shell>mysqlslap –defaults-file=/u01/mysql1/mysql/my.cnf –concurrency=25,50 –iterations=1 –create-schema=test –query=/u01/test.sql -S/tmp/mysql1.sock
Benchmark
Average number of seconds to run all queries: 0.018 seconds
Minimum number of seconds to run all queries: 0.018 seconds
Maximum number of seconds to run all queries: 0.018 seconds
Number of clients running queries: 25
Average number of queries per client: 1
Benchmark
Average number of seconds to run all queries: 0.011 seconds
Minimum number of seconds to run all queries: 0.011 seconds
Maximum number of seconds to run all queries: 0.011 seconds
Number of clients running queries: 50
Average number of queries per client: 1
2008-08-19 Tue
2008-08-18 Mon
AnySQL.net
DBA notes
Oracle & Starcraft
eagle's home
Give you some color to see see!
AnySQL.net English
Oracle Scratchpad
Oracle Life
OracleDBA Blog---Please enjoy the pain which is unable to avoid!
Uploads from Fenng(dbanotes)
Chanel [K]
xzh2000的博客
Oracle Security Blog
ERN空间
Eddie Awad's Blog
MySQL Performance Blog
The Tom Kyte Blog
Delicious/Fenng/oracle
AIXpert
O'Reilly Databases
Red Hat Magazine
DBASupport
DB2 Magazine 中文版
developerWorks 中国 : 技术文章 , 教程 AIX
Pythian Group Blog » Log Buffer
车东[Blog^2]
blue_prince
玉面飞龙的BLOG
此生 今世
人生就是如此
Orange Tiger 木匠 的 移民生活
生活帮-LifeBang
Hey!! Sky!
dba on unix
Oracle Notes Wiki
Brotherxiao's Home
柔嘉维则@life.oracle.eng
Fenng's shared items in Google Reader
jametong's shared items in Google Reader
缥缈游侠-logzgh
Tanel Poder's blog: Core IT for geeks and pros
DBA Tools
ilonng
yangtingkun
Oracle & Unix
Inside the Oracle Optimizer - Removing the black magic
Ricky's Test Blog
DBA@Taobao
存储部落
Think in 88
Alibaba DBA Team

