由于目前还处于ERP系统选型阶段，所以一切未知，一切也不便多说，但是一些通用的，依旧存在于那里。在工作变换的简短假期中有所憧憬，也有所忧虑，对之前走过的路和将来要走的路都有一些不算深入的思考。一些经验和体会零零碎碎的，整理出了下面几点：

• 对待变化不忧虑，迎接它。
• 面对现实，不逃避。
• 预估风险，面对风险，承担风险。
• 质量往往和时间成正比。
• 关键部分坦然面对。
• 不捣浆糊，有帐迟早要还的。
• 学好一门语言，其他的，可以在用到时再学——你不是程序员。
• 了解一些技术，有助于深入吃透功能本身。
• 愿意花一部分工作时间在其他需要你的地方，尽管它不属于本职工作。
• 多读官方文档。
• 沉得下去，浮得上来。

纯属个人体会和感触，不具有任何其他意义。一旦选型结束，将重新投入到实施和技术分享中来，自然会忙，会觉得辛苦，但值得。

面对变化，迎接变化。

• Oracle 11g R2 的所需内存至少1G
• 磁盘空间至少要达到10G
• 一些额外的特性，比如ASM和Oracle Restart需要额外的1G内存

很多名不副实的所谓Oracle专家，他们的知识可能仅仅来源于个人电脑上的单用户的Oracle系统，很多人甚至没有接触过真正的上规模的企业环境。Oracle将会继续贯彻这种政策来减少越来越多的半吊子和没有资格认证的外行人士，以避免行业陷于低水平境地。

我的看法是，今后所有企业版所需内存至少2G，ASM之类则需要额外的1G内存，这样效果会更好一些。 Joke

(注：本消息可信度自行判断 )

会议9:15分开始，我从杭州出发，坐了最早一班的动车，大概9:30左右到达会议地点。这种时间安排本身，就带着一点点的莫名其妙，因为这貌似不欢迎上海以外的客户。然后有了如下一些体验：

• 会议室很小，或者说人数太多，竟然没有足够的位子。
• 于是去外面找椅子，是自己动身去找了并推过来的。
• 坐下来后，发现主持人没用话筒，声音很轻。
• 体验时，网速超慢，打开首页要4、5分钟。
• 所谓的午餐，就是盒饭，没有位子的人需要自己找地方，不过地方不够。

因为体验不佳，所以我直接走人。

印象中，所有Oracle相关会议都是在五星级饭店举行的，即便不是如此，至少也有足够的位子；如果要体验，至少有足够的网速；如果要吃饭，至少不用手捧着盒饭吃。这次的组织者，显然没有上心。不过这是不是也说明，其他的会议都是交给专门的公司安排的，这是专业性的体现啊。

当然，最主要的问题还是在于自己，没事瞎凑热闹。

iTunes 上有很多免费学习资料(视频广播)，有大学课程，有电视节目，很多公司都提供了自己录制的视频材料，比如Oracle。目前，Oracle 提供的podcasts包括以下内容：

1. Oracle Author Podcasts 一些技术专家的观点
2. Oracle Buzz 各类新闻、趋势和话题
3. Oracle Database PodCasts Oracle 数据库学习
4. Oracle Fusion Middleware Radio 中间件产品
5. Oracle Green Enterprise 帮助客户更好了解Oracle产品
6. Oracle Intellicasts 商务智能之类的企业管理优化话题
7. Oracle Keynotes 企业新闻，产品和服务升级等
8. Oracle Magazine Oracle 杂志的编辑、作者等的会话节目
9. Oracle Technology Network TechCasts 了解Oracle最近的技术研发相关信息
10. Oracle’s AppCast 了解客户如何使用Oracle应用产品，以及最新的产品特性
11. Oracle@Work 三年不更新了，不看也罢

更多有用信息可以访问 http://blogs.oracle.com/databaseinsider/

有些人喜欢在功能设计文档中描述功能主要逻辑，界面则另行以黑板或白纸绘画，和开发人员当面细述。此类顾问多数初出茅庐，往往在开发过程中乃至上线后，提供许多修改需求，甚至有些时候界面由开发人员根据功能意图自行设计。也有一些人会使用Visio等工具绘制界面，但是需要耗费较多时间，所以如果开发过程中需要调整界面时，文档通常就懒得更新了。待得数月后回头来对应功能和文档，已经面目全非了。

对于原型图，在经历中我也曾尝试过多种方式，最初是用Word自带图形工具，简单方便，但是没有控件模板，全部手绘。后来尝试Visio，界面倒是可以很精致了，有现成控件，但是颇费功夫，一旦绘制后调整起来比较麻烦。去年也尝试过用Excel来画界面，由于Form界面往往有棱有角，所以在表格中涂抹些颜色倒也似模似样。

我眼中的绘图工具应当具备以下几个特点：

• 适合推广，不能只是一个人用。
• 能够准确描述心中所想，有现成控件可用，如果什么都自己画，显然影响效率。
• 能够方便的调整界面。虽然只是原型图，但是有些时候，开发过程中针对特定界面快速调整结构也是有需求的。
• 上手容易。如果需要一个礼拜甚至一个月才能上手的工具，这适合专业工作者，不是用来打草稿的。
• 工具本身要足够轻便。
• 价格低，最好免费。

花了一段时间对比各种软件，针对工作特点，最后找到了Balsamiq Mockups。关于Mockups的介绍有很多，我最中意的一点是可以和Confluence、JIRA集成，并且画图非常迅捷，基本上两三分钟内就可以完整画出整幅图了。

国内的ERP实施顾问比不得国外，半路出家的多，技术功底不够扎实，所以很多新潮的工具，并不会推而广之。但是从团队建设角度而言，有一款大家都用的趁手工具还是很能提高协作效率的。当工作时间达到一定程度后，就会对各种工作中所需要的小工具有了更高的要求，比如文档模板、流程图、原型图、课件工具等。Mockups花费10分钟即可上手，将来有更好的工具时，放弃它也不会有什么遗憾。

之前我很少谈及Oracle之外的产品，今后或许会涉及一些，毕竟，这也是用于Oracle相关工作中，不是吗？

Ref: 10 Excellent Tools for Creating Web Design Wireframes

在Oracle ERP实施领域，我们习惯将人员分为两种，一种是提供软件或者实施服务的所谓“乙方”，一种是上ERP项目的所谓“甲方”。相对而言，甲方的实施顾问更像是培训专员和客服，甲方的技术顾问更像是乙方致仕还乡的小官儿，只在小地儿谈论小道。在整体平均薪资上来讲，甲方要逊上一筹，但也稳定轻松了些许，不需要整年里出差漂流外乡。

在招聘人手时，往往面临几个困境：

• 如果从乙方招聘，则薪资可能难以谈拢，但是水平有保证。当然，这也不是绝对的，我就见过很多例外。
• 如果从甲方招聘，则薪资或可谈拢，但是水平多数都是高估的。由于环境的因素，很多人往往得过且过，所以工作多年，却并不见得水平渐长的，多数人干的活只值2000块。
• 如果招聘新手，看着用功成本不高，但是培训也是件烦事儿，而且无法保证学成后跳往他方。

虽然自己就处在“甲方”，我却对甲方有点偏见。他们做开发却不懂数据库，设计功能却不了解系统功能和技术实现，全是些忽悠之辈。但是换个角度来讲，这却是在甲方的工作内容之一，尤其是在实业企业，技术是次要的，精通业务才是首要的，所以基础薄弱了些倒也无可厚非。

定位问题有时候是一个非常重要的问题。信息化绝对是一项与时俱进的工作，软件的升级换代非常迅速，如果因循固守，即便在企业里稳坐不动，但是对于个人而言，其知识也趋于淘汰之列。但是若过度跟进时势，却往往力有不逮，任何工作都是需要人力物力投入的，在一个注重投资回报率的时代里，企业不可能轻率地做出变更。这也是个人知识更新和企业信息化平稳升级的矛盾之一。基于这个考虑下，很多有心上进的人，便不乐意到这边来死守一方。

几年前注册orafans这个域名时，还有点念想，期望中国也能出现个地域性的Oracle ERP实施顾问的小圈子。后来渐渐发现，该圈子人员极少，而且从业人员往往半路出家专业功底不深，在现有的杭州地区从业人员来看，对技术兴趣缺乏，上进心极弱，这种大环境下，很难形成一种party似的氛围。

我觉得Oracle ERP从业人员至少应当具备以下几点：

• 了解系统技术架构，最好了解数据库和应用基本知识。不要求能自己做二次开发、性能调优，但是至少要知道想要的功能能够通过哪些方式去实现。
• 深入了解标准功能本身，不要一知半解。至少，要通读过所负责模块的官方文档。
• 有持续跟进、学习的兴趣，保持升级的冲动。随着ERP的推进，不论从规模上看，还是从功能上看，肯定会出现平台扩展和升级的需求。

在这个行业，找一可聊之人，难哪！也只在此牢骚几句而已。

任何一名实施顾问，首要的经验就是要学会明确自己和普通用户的不同。一种业务，或者一个功能，绝对不能完全站在用户的立场来看待问题。如果用户说没有做过更改，那是从功能使用角度来讲的，作为系统和功能之间起到桥梁作用的ERP实施人员，还应当关注系统本身的变化。首先，克隆本身就是一种变化，比如硬件平台的变化、文件路径的变化、访问方式的变化，甚至系统参数（数据库或应用）也可能变化。任何一种变化，都可能导致用户体验的不同。一个新克隆的系统，第一次访问就发现速度变慢（或者变快），实施顾问应当事先就预料到各种可能的情况。从我的经验来看，没有做过变动的可能性非常小，那就通过一些简单的技术手段来找到这种变化。

先对该功能启用诊断后发现，有一段执行任务列表查询的SQL存在明显的性能问题。

克隆环境检查该SQL的执行计划：

SQL> set linesize 1000
SQL> set pagesize 1000
SQL> explain plan for SELECT *
  2    FROM (SELECT * FROM pa_task_progress_v) qrslt
  3   WHERE (task_manager_person_id = 126)
  4   ORDER BY project_name ASC,
  5            task_name    ASC
  6  ;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
| Id  | Operation                                    |  Name                         | Rows  | Bytes | Cost  |
----------------------------------------------------------------------------------------------------
……
|* 14 |               HASH JOIN                      |                               |     1 |   239 |  5274 |
|* 15 |                TABLE ACCESS BY INDEX ROWID   | PA_PROJ_ELEMENT_VERSIONS      |     2 |    86 |     3 |
|  16 |                 NESTED LOOPS                 |                               |   381 | 84201 |  5253 |
|* 17 |                  HASH JOIN                   |                               |   252 | 44856 |  4497 |
|* 18 |                   TABLE ACCESS BY INDEX ROWID| PA_PROJ_ELEMENTS              |   445 | 65860 |  4492 |
|* 19 |                    INDEX RANGE SCAN          | PA_PROJ_ELEMENTS_N1           | 81751 |       |   357 |
|* 20 |                   TABLE ACCESS FULL          | PA_TASK_TYPES                 |     9 |   270 |     4 |
|* 21 |                  INDEX RANGE SCAN            | PA_PROJ_ELEMENT_VERSIONS_N1   |     2 |       |     2 |
|* 22 |                TABLE ACCESS FULL             | PA_PROJ_ELEM_VER_STRUCTURE    |  1732 | 31176 |    20 |
|* 23 |               TABLE ACCESS BY INDEX ROWID    | PA_PROJ_ELEM_VER_SCHEDULE     |     1 |    34 |     2 |
|* 24 |                INDEX UNIQUE SCAN             | PA_PROJ_ELEM_VER_SCHEDULE_U2  |     1 |       |     1 |
……
----------------------------------------------------------------------------------------------------

再在正式环境中检查同一句SQL的执行计划：

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
| Id  | Operation                                 |  Name                         | Rows  | Bytes | Cost  |
----------------------------------------------------------------------------------------------------
……
|* 14 |               HASH JOIN                   |                               |     1 |   239 |  3793 |
|* 15 |                TABLE ACCESS BY INDEX ROWID| PA_PROJ_ELEMENT_VERSIONS      |     2 |    86 |     3 |
|  16 |                 NESTED LOOPS              |                               |   393 | 86853 |  3787 |
|* 17 |                  HASH JOIN                |                               |   253 | 45034 |  3028 |
|* 18 |                   TABLE ACCESS FULL       | PA_PROJ_ELEMENTS              |   446 | 66008 |  3025 |
|* 19 |                   TABLE ACCESS FULL       | PA_TASK_TYPES                 |     9 |   270 |     2 |
|* 20 |                  INDEX RANGE SCAN         | PA_PROJ_ELEMENT_VERSIONS_N1   |     2 |       |     2 |
|* 21 |                TABLE ACCESS FULL          | PA_PROJ_ELEM_VER_STRUCTURE    |  1883 | 33894 |     5 |
|* 22 |               TABLE ACCESS BY INDEX ROWID | PA_PROJ_ELEM_VER_SCHEDULE     |     1 |    35 |     2 |
|* 23 |                INDEX UNIQUE SCAN          | PA_PROJ_ELEM_VER_SCHEDULE_U2  |     1 |       |     1 |
……
----------------------------------------------------------------------------------------------------

从两者对比上看，可以发现正式环境中该SQL并没有用到PA_PROJ_ELEMENTS的索引，基本上可以确定两个环境同一个功能访问速度不同的原因。同样的语句，在克隆环境和正式环境中的执行计划不一样。两个环境分别重新收集统计信息后，依旧如此。

从用户角度看，问题出在系统方面；从实施顾问角度看，此类系统问题应当寻求技术人员尤其是DBA的帮助，为什么会出现这种差异。经过进一步的诊断，发现正式环境中 db_file_multiblock_read_count 参数被设置为100，而克隆环境中该参数被设置为8。在克隆环境中尝试调整该值，可以确定正是该参数导致了执行计划的不同。

这里不对db_file_multiblock_read_count做探讨，这应该交给专业的性能调优人员去分析。回到开始，我们在发现问题后询问各方人员，为什么都回答没有做任何特殊变动呢？这其实是个非常有趣的话题，我想，最大的问题还是出在“习惯”二字上面。做了几十上百次同样的操作，当某一天发现这种方式出现问题时，我们条件反射的把这种习惯性操作排除在外，而把问题原因归咎于某些未知的可能性上面。

一个有经验的实施人员，和一个没有经验的实施人员，其生产力差别可见一斑。

Oracle 发布了全球2009年度DBA薪水统计报告，基本上可以看出，DBA依然是一份越老越吃香的职业：

在国内不乏有一些人认为，认证的获取无关紧要，关键是看实际工作能力和经验。Oracle 就专门做了这么一番统计：

暂且不论该统计数据从何而来，但是那些未取得认证的人看过后是否有一种异样的冲动？其实，把认证和工作能力等同起来讨论本身就是毫无意义的，就好比去说一个博士比一个本科生人品更好一样。在中国，估计没有哪个专职DBA未获得认证的，剩下的，可能以兼职居多。

在该报告中，可以按地区（没有中国），按公司规模，甚至按认证数目来进行统计。总而言之，对于职业发展毫无目标的人，这是一个不错的参考。

数日之前，Oracle宣布解除和Prometric的合作关系，转之以Pearson VUE。原先Prometric的数据需要自行转移到CertView。相对于之前更加方便的一点是：它提供了认证历史查看和证书外发功能。记得寻找第一份工作时，面试要带上所有的证书复印件，真是麻烦。虽然好多年没经历过了，但是那种拿着文件夹傻兮兮的样子，真是终生难忘。

基本上，有个OCP和OCE认证，除非真想做个Oracle数据库大师级人物，一般来讲，是不会去升级认证的了。不过，花点时间把Prometric数据转移到CertView还是值得的，至少也是职业生涯中的一段历史，保留一下也好。

Prometric Testing ID将转换到Oracle Testing ID，同时，原Hand-On Course的表单提交也将于今年9月份终止使用，将会另行启用新的课程提交系统。回想起我当初提交OCP的课程信息时，如果不按照指南，根本就无法顺利提交。新的课程提交系统还是很值得期待的。

在中国，Prometric的考场已经遍地开花了，不知道新的考试服务提供商（我是指中国的），会不会依旧会给广大考生提供如此大的便利。

公告原文见：

http://www.oracle.com/global/us/education/certification/exam_vendor.html