如果你有iPhone，那就可以在手机上随时收看Oracle的学习视频。如果你没有iPhone，也可以通过iTunes在电脑上收看，或者在其他支持MP4的移动设备上收看。
iTunes 上有很多免费学习资料(视频广播)，有大学课程，有电视节目，很多公司都提供了自己录制的视频材料，比如Oracle。目前，Oracle 提供的podcasts包括以下内容：
- Oracle Author Podcasts 一些技术专家的观点
- Oracle Buzz 各类新闻、趋势和话题
- Oracle Database PodCasts Oracle 数据库学习
- Oracle Fusion Middleware Radio 中间件产品
- Oracle Green Enterprise 帮助客户更好了解Oracle产品
- Oracle Intellicasts 商务智能之类的企业管理优化话题
- Oracle Keynotes 企业新闻，产品和服务升级等
- Oracle Magazine Oracle 杂志的编辑、作者等的会话节目
- Oracle Technology Network TechCasts 了解Oracle最近的技术研发相关信息
- Oracle’s AppCast 了解客户如何使用Oracle应用产品，以及最新的产品特性
Oracle@Work 三年不更新了，不看也罢
更多有用信息可以访问 http://blogs.oracle.com/databaseinsider/
每次项目实施时都会有大量的客户化功能，自然也有很多功能设计出炉。我一直认为合格的实施顾问是懂一点技术的，应当会用最趁手的工具来表达自己的意图。在功能设计中，如果已经有了特定的界面构思，则需要将界面示之于开发人员。
有些人喜欢在功能设计文档中描述功能主要逻辑，界面则另行以黑板或白纸绘画，和开发人员当面细述。此类顾问多数初出茅庐，往往在开发过程中乃至上线后，提供许多修改需求，甚至有些时候界面由开发人员根据功能意图自行设计。也有一些人会使用Visio等工具绘制界面，但是需要耗费较多时间，所以如果开发过程中需要调整界面时，文档通常就懒得更新了。待得数月后回头来对应功能和文档，已经面目全非了。
对于原型图，在经历中我也曾尝试过多种方式，最初是用Word自带图形工具，简单方便，但是没有控件模板，全部手绘。后来尝试Visio，界面倒是可以很精致了，有现成控件，但是颇费功夫，一旦绘制后调整起来比较麻烦。去年也尝试过用Excel来画界面，由于Form界面往往有棱有角，所以在表格中涂抹些颜色倒也似模似样。
我眼中的绘图工具应当具备以下几个特点：
- 适合推广，不能只是一个人用。
- 能够准确描述心中所想，有现成控件可用，如果什么都自己画，显然影响效率。
- 能够方便的调整界面。虽然只是原型图，但是有些时候，开发过程中针对特定界面快速调整结构也是有需求的。
- 上手容易。如果需要一个礼拜甚至一个月才能上手的工具，这适合专业工作者，不是用来打草稿的。
- 工具本身要足够轻便。
- 价格低，最好免费。
花了一段时间对比各种软件，针对工作特点，最后找到了Balsamiq Mockups。关于Mockups的介绍有很多，我最中意的一点是可以和Confluence、JIRA集成，并且画图非常迅捷，基本上两三分钟内就可以完整画出整幅图了。
国内的ERP实施顾问比不得国外，半路出家的多，技术功底不够扎实，所以很多新潮的工具，并不会推而广之。但是从团队建设角度而言，有一款大家都用的趁手工具还是很能提高协作效率的。当工作时间达到一定程度后，就会对各种工作中所需要的小工具有了更高的要求，比如文档模板、流程图、原型图、课件工具等。Mockups花费10分钟即可上手，将来有更好的工具时，放弃它也不会有什么遗憾。
之前我很少谈及Oracle之外的产品，今后或许会涉及一些，毕竟，这也是用于Oracle相关工作中，不是吗？
我其实并不喜欢这活儿，看看事儿还可以，看人就差远了。但是有时候却不得不看，尤其是你的团队需要增加人手的时候。
在Oracle ERP实施领域，我们习惯将人员分为两种，一种是提供软件或者实施服务的所谓“乙方”，一种是上ERP项目的所谓“甲方”。相对而言，甲方的实施顾问更像是培训专员和客服，甲方的技术顾问更像是乙方致仕还乡的小官儿，只在小地儿谈论小道。在整体平均薪资上来讲，甲方要逊上一筹，但也稳定轻松了些许，不需要整年里出差漂流外乡。
在招聘人手时，往往面临几个困境：
- 如果从乙方招聘，则薪资可能难以谈拢，但是水平有保证。当然，这也不是绝对的，我就见过很多例外。
- 如果从甲方招聘，则薪资或可谈拢，但是水平多数都是高估的。由于环境的因素，很多人往往得过且过，所以工作多年，却并不见得水平渐长的，多数人干的活只值2000块。
- 如果招聘新手，看着用功成本不高，但是培训也是件烦事儿，而且无法保证学成后跳往他方。
虽然自己就处在“甲方”，我却对甲方有点偏见。他们做开发却不懂数据库，设计功能却不了解系统功能和技术实现，全是些忽悠之辈。但是换个角度来讲，这却是在甲方的工作内容之一，尤其是在实业企业，技术是次要的，精通业务才是首要的，所以基础薄弱了些倒也无可厚非。
定位问题有时候是一个非常重要的问题。信息化绝对是一项与时俱进的工作，软件的升级换代非常迅速，如果因循固守，即便在企业里稳坐不动，但是对于个人而言，其知识也趋于淘汰之列。但是若过度跟进时势，却往往力有不逮，任何工作都是需要人力物力投入的，在一个注重投资回报率的时代里，企业不可能轻率地做出变更。这也是个人知识更新和企业信息化平稳升级的矛盾之一。基于这个考虑下，很多有心上进的人，便不乐意到这边来死守一方。
几年前注册orafans这个域名时，还有点念想，期望中国也能出现个地域性的Oracle ERP实施顾问的小圈子。后来渐渐发现，该圈子人员极少，而且从业人员往往半路出家专业功底不深，在现有的杭州地区从业人员来看，对技术兴趣缺乏，上进心极弱，这种大环境下，很难形成一种party似的氛围。
我觉得Oracle ERP从业人员至少应当具备以下几点：
- 了解系统技术架构，最好了解数据库和应用基本知识。不要求能自己做二次开发、性能调优，但是至少要知道想要的功能能够通过哪些方式去实现。
- 深入了解标准功能本身，不要一知半解。至少，要通读过所负责模块的官方文档。
- 有持续跟进、学习的兴趣，保持升级的冲动。随着ERP的推进，不论从规模上看，还是从功能上看，肯定会出现平台扩展和升级的需求。
在这个行业，找一可聊之人，难哪！也只在此牢骚几句而已。
案例：ERP系统中项目数量非常多，在项目管理模块，有个WEB界面是用于调整任务信息的。克隆环境后，用户发现该功能的访问速度和正式环境有明显差异。经询问各方面人员（包括用户和实施顾问），都说没有做过任何特殊变动。
任何一名实施顾问，首要的经验就是要学会明确自己和普通用户的不同。一种业务，或者一个功能，绝对不能完全站在用户的立场来看待问题。如果用户说没有做过更改，那是从功能使用角度来讲的，作为系统和功能之间起到桥梁作用的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 ERP的操作手册怎么写？
我联想到一个很小的例子。过完年回来后，很多中餐馆都还没有营业，哪怕已经营业的餐馆里菜式也非常少，老板解释说厨师还没上班。再回头看肯德基、麦当劳之类的洋快餐，什么时候会说因为某人没来上班而不能吃某样食物？在每个营业员都可以做厨师的餐厅里，我们甚至没进去就可以先想好吃什么，而中餐馆里却不行，甚至很多时候，因为某厨师的离职而导致我们再也不去某家餐馆。
在很长的时间里，以及绝大多数的企业里的，操作手册就是一个文档，里面配以相关截图和简单的说明，花哨一点的可能会录制屏幕配以简单解说，而更规范的企业里或许直接以SOP来代替。基本上，如果没有规范的制定，每个人的操作手册肯定是五花八门，更多时候彼此都很难看懂对方写的手册，而没有经验的用户则更是看得云里雾里。
我心目中标准的操作手册应当包含以下几个要素：
- 具备明确的目标，该手册将让用户掌握什么功能的操作？
- 要直观，简洁。
- 对于关键点，应该有适当的说明。
- 导航要清晰、明确。
用户在看到操作手册之前，应当已经接受过初步培训。很多人拿着操作手册想了解背后的数据模型，拿着功能介绍想看操作细节，结果一个手册变成了大杂烩，什么都有，搞到最后则是连用户都不想看了。操作手册不是功能设计，更不是用户需求说明书，它只是让用户明白某个功能是如何运作的，要正常工作中应当如何规范操作。用户和实施顾问的角色是完全不同的，用户看的文档和实施顾问看的文档也完全不同。所以在操作手册中配以复杂的理论说明是非常应当避免的，我的看法是，连流程图都没有存在的必要。
一个规范的格式化的文档永远比个性化的文档更有价值。有时候，写手册也是一种艺术，哪怕已经制定了规范，不同的人写出的手册还是区别很大，比如用于习惯，比如符号表示，比如章节划分，这些细节上的区别往往很容易造成阅读上的障碍。
行业范围的标准和规范有时候比团队内部甚至企业内部的规范要有力的多，而且这种规范会更得人心。习惯也可以成为一种竞争力，团队协作经验有时候和个人能力一样重要。如果某一天因工作需要进入另一个团队，结果发现其管理方式迥异，转变的过程也会是非常痛苦的。在Oracle ERP领域，UPK的使用或许就是一种每个从业人员都应当掌握的技能。
Oracle UPK的上手非常容易，通过简单的设置，甚至只需要重复一遍操作过程就能形成一套非常棒的培训方案。它可以生成屏幕回放，对于每步操作都配以解释，有需要的话，可以按章节用HTML附上一段说明。若有需要，也可以直接发布成Word格式的操作手册，其质量丝毫不逊于以前手工截图的手册。也可以发布到网站上，并且和EBS系统进行菜单集成，直接从EBS跳转到操作手册。目前，Oracle EBS R12、PeopleSoft、JD Edwards等应用都已用UPK做培训文档，相信今后Oracle会有越来越多的产品的培训文档采用该种方式发布。
对于Oracle ERP操作手册编写，希望今后能有更多的企业采用UPK。这种工具和规范，对每一位从业人员都是有利无害的。
Oracle UPK 官方站点：http://www.oracle.com/applications/tutor/user-productivity-kit.html
尽管你可能经常碰到一些看上去很糟糕的DBA，尽管你可能觉得DBA的工作其实蛮简单，甚至有时候根本不知道他们的工作有什么意义，但是无可否认的是，在这个行业中，Oracle DBA的薪水还是可以排得上号的。在中国，高级DBA可以获得10~15万的年薪，而对于某些特别出色的专家而言，年薪20~30万的也不乏其人。
Oracle 发布了全球2009年度DBA薪水统计报告，基本上可以看出，DBA依然是一份越老越吃香的职业：
在国内不乏有一些人认为，认证的获取无关紧要，关键是看实际工作能力和经验。Oracle 就专门做了这么一番统计：
暂且不论该统计数据从何而来，但是那些未取得认证的人看过后是否有一种异样的冲动？其实，把认证和工作能力等同起来讨论本身就是毫无意义的，就好比去说一个博士比一个本科生人品更好一样。在中国，估计没有哪个专职DBA未获得认证的，剩下的，可能以兼职居多。
在该报告中，可以按地区（没有中国），按公司规模，甚至按认证数目来进行统计。总而言之，对于职业发展毫无目标的人，这是一个不错的参考。
