中文：并发：提交每个请求后显示请求摘要
英文：Concurrent: ShowRequests Summary After Each Request Submission
说明：设置为“是”以使 SRS 表单 (FNDRSRUN) 在每次提交新请求时显示当前提交请求的摘要。
使用场景：
在使用EBS提交请求后，总要弹出“是否提交另一项请求”的提示，而我们往往选择“否”，这个提示就显得多余。
为了减轻这“多一步”的负担，取消“是否提交另一项请求”的提示，设置方法如下：默认：否(No)，修改为是(Yes)，可以在User Level上修改。
作者托尼-施瓦茨的新书《我们的工作方式不起作用：被遗忘的四大促进表现的需求》一书在媒体上掀起了不小的轰动。最主要的是，他唤起了那些我们早已熟知的事情：这种现代化的时刻在线保持联络的久坐方式对我们的工作有多方面的损害。但是，对于远程团队，和我们这些劳心劳力为团队谋福利的管理者来说，这些问题非常棘手。针对他的文章《拿回你的项目》，我最近写过一篇评论。最近，我有机会向他请教一些有关管理远程团队的问题。很多人的公司都是虚拟的，他也在管理这样的公司。以下是他的一些观点：
管理者：要非常明确的跟你的远程员工们解释清楚什么叫做成功。重要的不是他们工作的时间（反正你也不能真正的核查这一点），最重要的是他们所产出的价值。关键是要像对待成年人那样对待他们：说清楚你的预期，给他们自由去决定去选择最好的方法，最后要保证他们对自己的工作成绩负责。管理者不同花时间和雇员们来讨论和交流，来界定成功的定义，这一点对远程工作人员意义尤其重大。
员工：需要找到一种方法，在缺乏外部监管组织的情况下进行自我管理。对于施瓦茨来说，这意味着要制定一个长期的时间表，每天一清早要开始做最重要的事情，不受干扰的工作90分钟，然后休息片刻。这样的话，每天的开始效率会非常高，可以帮助员工抵挡其他诱惑，去干那些不是很紧要的比较容易做的事情——例如答复电子邮件。
管理者：要承认那些远程上班的人，可能需要一些压力才能集中注意力。施瓦茨的书中勾画出一张非常清晰的蓝图，告诉你最有效的办法，同时照顾到你的长期需要。他说：“那些读我书的经理们首先需要从自己身上总结经验教训，然后，他们需要帮助大家来创造一种结构，使人们有可能从中取得成果——包括鼓励他们真的去重新安排时间顺序。如果你明确的定义什么是成功，而且规定好具体的办法定期检查远程工作人员的工作进度。那么，真的有人出现问题的时候，其标志就是他们什么也没贡献。你几乎可以肯定的是，其关键就是没有建立明确的责任界限，也没有明确的工作态度。记住要保持这样的对话。
管理者：不要低估经常接触的重要性。 “人类是群居动物，我们都渴望交流，”施瓦茨说，“如果你是在管理远程工作者，你必须投入额外的精力去和他们保持联系，并对他们出色的工作表示赞赏，因为那些单枪匹马干活的人很容易感到孤独和不被尊重。你不能只依靠电子邮件——这种形式太单一了，作为沟通方式很单调。重要的是要找到时间来和他们保持联络。”
有人苛责我说，我一直没有考虑过远程团队是可持续的，这不仅对企业不利，而且这也是不对的。我相信，和施瓦茨一样，我们必须考虑如何使人们最大程度的发挥潜能，然后有意识地创造一种环境，在这种环境下他们可以充分发展，而不是只靠运气。
转载自网络文件。
转载自：http://www.sohu.com/a/154074135_403607
每五个远程团队中，就有一个团队的创始人会离开。
编者按：随着科技的进步，很多工作已由传统上的上下班，变成了远距离的工作。这为人们提供了很多便利，但另一方面，远程工作减少了大家与同事间的社会交流，增加了冲突的机会。根据著名的Y Combinator 的保守统计，每五个远程团队中，就有一个团队的创始人会离开。Zapier 创始人Wade Foster发表了题为“how manage remote team”的文章，给出了他的建议。
过去几年来，人们对有关远程工作之优点的争论上，耗费了大量精力。 不幸的是，关于如何设置远程工作，以便你和你的团队能取得成功，却没有太多可以共享的信息。过去三年来，Zapier是由一支远程队伍来运作的。 我们已经由最初的三个创始人增长到二十多人。 我们已经收到了很多关于我们如何运作的问题。以下让我做一下说明:
我们的旅程
从第一天起，（2011年10月）Zapier一直是分布式团队。 即使布赖恩，迈克和我住在同一个城市，但由于学习和工作的原因，我们有不同的时间表。 每个人一有空就在Zapier工作，但这种分配，并无法奇迹般地将我们安排在同一时间，同一个房间里工作，所以我们必须成为一支远程队伍。2012年6月，我们被Y Combinator接受，并搬到加利福尼亚州山景城的一个共享公寓。 接下来的三个月是我们公司历史上唯一一个，大家都在一个时间，同一个城市的时期。2012年8月，当迈克的女友毕业于法学院，他搬回密苏里州。2012年10月，我们开始招聘。 既然我们已经是一个分布式团队，那么继续这样做是合乎情理的，因为我们知道，我们可以聘请很棒的人，他只是跟我们住不同的地方。在41个月的时间里，我们学到了一些关于构建和管理远程团队的知识。 还有其他人比我们有更多的经验。 虽然GitHub，Automattic，Citrix等公司已经证明，分布式团队可以取得成功，但我不确定这样的团队可以扩大到何种规模。 但如果你只是一个小团队，并希望加入到远程工作的队伍中，请考虑这个crash course。
设置成功远程工作的三个要素
你不可能期望，在历史上任何时刻，采取任何随机的方式，把分散在全球各地人们放在一起就能期望他们创立一些惊人的东西，并取得成功。我们发现要做好远程工作，有三个重要组成部分：团队，工具和步骤。 团队到目前为止，最重要的成分是团队。 不是每个人都可以在远程环境中工作。也不是每个人都可以管理一个远程团队（虽然我怀疑过一段时间，我了解到很多经理可以找出成功运作的方法）。 因此，组建一个能够在远程环境中工作的团队很重要。 这是我们总结出的一些最好办法:
1. 雇用有效率的人员有效率的人员即使身处马里，也会完成任务。 你不必跟他们布置必须完成哪些工作。 你只需对最重要的事情指明方向并提供指导就好了。但是即使什么都没有的话，有效率的员工也会尽全力去实施。
2.雇用你可以信任的人当你不能信任另一端的人时，远程工作将无法进行。 如果你不断地发现自己在担心某人正在做什么，那么你将损耗大量精力去关注一些别的事情而不是产品。记住，信任是关键。
3.信任你雇用的人另一方面，你也需要与你雇用的人员保持信任。 作为经理，你需要学习通过期望而不是对号入座的方式来管理人员，因此请确保你能够对你所雇用的人给以信任。
4. 聘请擅长写作的人在同一个办公室里的工作环境中，很多信息是亲自分享的。 在远程情况下，大量的内容都需要通过书面通信的方式来共享。 沟通是远程团队最重要的部分之一。 因此，好的写作水平是很重要的。
5. 雇用那些能适应没有社交工作场所的人尝试在远程团队中创建一些社交活动是很重要的。 但事实真相是，远程工作的社交接触通常比在同一地方工作的人要少。团队的成员要能适应这一点。 最好的远程工作人员能在这种环境中茁壮成长。
工具
工具在远程工作中很重要，因为它们可以让你更好地组织团队，并将所有人都保留在同一页面上。在近距离工作中，你可以随时把团队组织起来，开全方位的会议，以使每个人都不掉队。 在远程团队中，你需要使用正确的工具，以确保每个人都能在身旁无人的情况下执行任务。
当我们的团队有20个成员的时候，我们使用了以下工具:
1. SlackSlack是我们的虚拟办公室。 如果你在Slack，那么你在上班。 像Slack这样的团体聊天室, 也是创造友情的好地方。根据你团队的规模，你还可以在Slack中使用”频道”这个功能。 有些时候，大家都在一起发言，会使它变得十分嘈杂，所以如果把聊天室分成诸如“工程”，“营销”不同频道的话，是十分方便的。在我们大约有10人左右的时候，开始使用多个频道。 我们现在有23个频道（一些需要被存档）。 活跃的频道包括#市场，#支持和#创客以及像#min，#价格这样跟项目有关的专门频道。
2. AsyncAsync是我们构建的内部工具。 这有点像一个博客遇到reddit。 以前我们使用了WordPress的P2主题，但后来发现我们想要更多。有时候Slack的节奏太快了，以致有人会迷失方向。Async是一个我们可以查找出重要对话的地方。 它取代了内部电子邮件，并且作为一个伟大的档案，团队中的任何人都可以参考以前的讨论。
3. TrelloTrello是我们的默认路线图。 每当有一些我们想要做的事情，就将其添加到Trello的待办事项列表中。 在大多数情况下，你会发现自己创建了太多的卡片，去尝试做过多的事情。为避免这一情况，卡片创建人还必须编写一个详细的特征描述，以说明为什么它很重要，以及成功实现这个功能后的结果将是怎样的。我们还使用Trello来跟踪我们编辑的日历，支持文档和真正需要完成的任何项目。这对远程团队来说非常有用，因为如果公司里有任何人想要找点事儿做的话，他们可以从Trello那里选一张卡片，并且知道完成后，这对产品/公司来讲，有什么积极作用。
4. GitHub在Zapier，议题(Issues) 和从远程取回请求(pull)是有特殊目的的。 就像GitHub使用GitHub来构建GitHub，我们使用GitHub来创建Zapier。 GitHub包含所有与代码相关的项目管理。取回请求是有关功能的操作。议题限定使用在跟Bug相关的。 特色会在Trello和/或计划文档中涉及到。
5. LastPass由于我们已经登录了数百项服务，所以对于任何进入公司的人来说，无需登陆即时消息或等待电子邮件回复，即可访问它们，将会非常方便。 使用LastPass，任何队友都可以登录我们使用的任何服务，而无需知道登录密码。
6. Google Docs & HackpadGoogle文档很棒。 我们通过分享电子表格，来对关键指标进行分析。 我们分享含有团队和其他重要信息的电子文档，以备以后使用。 我们共享合同和记录的文件。 任何可能多次使用的内容都应记录在案，Google文档为快捷方便地共享文件，提供了便利条件。不过，Google文档无法被用来进行组织和协作。 我们发现Hackpad非常适合作为内部文档使用。 任何需要教别人如何做一些事情的文档，都可以被添加到Hackpad中的一个便笺本和收藏之中，必要时，其他人可以快速地访问Zapier的集体智慧。
7. GoToMeeting有大量很酷的视频会议工具。 GoToMeeting不是其中之一。 它很笨重，但GoToMeeting的音频和视频质量比任何其他应用都要好。 我们也尝试过很多工具。 有时我们会通过Google环聊或Skype进行一次通话，但是当你需要与10多人进行团队聊天时，GoToMeeting是你的朋友。
8. HelloSign你和你的员工不时要签署一些文件。使用HelloSign，可以免去自己将文档打印出来，签上名，将其扫描回机器上传，并与下一个签名者进行文档共享的繁琐程序。 步骤建立一支强大的远程队伍的第三个成分是步骤。 我知道大多数人不喜欢步骤的问题, 它使人感到无聊和僵硬。 但是，如果你将步骤视为“我们的工作方式”，它将开始变得非常强大。设计优良的步骤能为执行任务提供结构和方向，它可以帮你顺利地完成工作。这并不意味着步骤应该是僵硬的，不变的或没有意义的。 在一家小的公司中，步骤可以有利于提供反馈，以便你衡量公司和公司人员的进度。
以下是使用Zapier运行的一些步骤。我还喜欢叫它们：我们如何工作
1. 大家都参与客户支持服务客户是我们的命脉。 我们每天努力解决客户的问题，帮助他们更轻松地工作。 当团队中的每个人都对客户提供支持时，就都能听到客户的声音。此外，构建产品的人也最终提供产品支持服务。 如果一个客户对一个bug很生气的话，那么这个人在听到直接反馈后，会立即修复它。
2. 专心文化由于每个人都做客户支持，我们制定了专门的开发计划，以便使Zapier团队中的每个开发人员能轮流花费一周时间做支持服务。 其他周这些工程师们将100％致力于功能开发。 这样可以给开发人员足够的时间来专心作出一番事业。 同样，这也确保了新功能开发的良好节奏。
3.每周环聊每个星期四上午9点太平洋时区，我们聚在一起进行闪电会谈，演示和/或采访。 既然现在有20多人，有时很难每周都见到每个人。 这些环聊有机会对你经常看不到的人说声“你好”。这些环聊也是学习新东西的好机会。 每个星期，团队内有人会对有趣的事情做一个敏捷地讲话或演示，再或者有人跑过来加入队伍中，我们会让他做一个快速地介绍。之所以会议定在星期四的上午9点召开，是因为这是一个地理上分布式团队的最佳时间，所以没有人会在周末受到太多的打扰。
4. 结伴活动随着我们的发展，认识你的所有队友变得更难了。一个简单地解决方法就是让队友们每周随机地与另外一个队友配对，并进行短暂的10-15分钟对话。 我们用这个机会聊聊生活，工作或其他任何感兴趣的事情。 有时，很酷的新产品功能就是通过这些聊天聊出来的，其他时候，它只是很好玩。 无论如何，这有助于每个人更好地了解他们的队友。
5. 每月一对一在我曾经做过的每一份工作中（甚至是近距离的工作），我和我的主管之间没有足够的回馈机制。 所以在Zapier，我和每一个团队成员在Skype或者Google环聊上设置一个，每个月的定期活动，聊聊四件事情：你感到兴奋的是什么，你担心的是什么？ 我可以怎样更好地帮你完成你的工作，你可以做些什么事情来改善你的工作。这些问题具有一致性，所以它很容易去准备，而且也能够随着时间的变化去衡量。 我们特别将其限制为每个问题只涉及一个项目。这样可以比较轻松去实现。 但随着时间的推移，被解决的问题就会积少成多。每个月对话的答案都会被记录在Google文档中，以便下一次会话时，可以参考上一个月的信息并帮助我们检查工作进度。过去我和每个人都做一对一会谈。 然而，当团队扩大到大约15人左右时，这有些太难了。所以现在我专注于支持和营销团队，而Bryan和Mike（我的共同创始人）分别专注于工程和产品团队。这些审核非常好地反映了我们这个远程团队是否在良好地运作，因为它让我得到了大大小小，各方面的反馈，使我们知道哪些方面需要改善，能使工作起来更加愉快。 例如，我发现库克西和詹姆斯偶尔在哥伦比亚市中心共同工作，最后他们在自己淘腰包付停车费。 因此，我们设置了一个简单的报销计划，以确保队员在为公司支出后，可以报销这笔费用。
6.责任感的文化一个经常被问到的问题是“你如何知道人们是否在做工作？” 我们的简单方法是每周五做一次更新。 每个星期五，团队中的每个人都会向Async发送一份有关本周他们做了什么，下一周他们计划做什么的的工作报告。这样可以轻松地保持项目的进度，让Zapier里的每个人都有责任感，并尽其所能。
7. 亲身体验文化团队成员间的互动，对任何团队来说都是有价值的。 当队友们在一起，亲自做某件事的时候，肯定会有一些特别的经历。 因此，我们力争将团队一年两次聚在一起，这让人感觉很酷。我们公司特别安排了访问华盛顿，科罗拉多州，阿拉巴马州和犹他州。除了全公司聚会之外，我们有些小组，在协调一个重大项目/功能时，还会安排见面活动。 通常这只是一个人跳上飞机去探望另一个人。这似乎看起来很破费，事实也确实如此。 但是不要忘了，其实你已经省下了一大笔办公室租赁费。
8.自动化任何可以自动控制的工作Zapier的核心是自动控制。 这里有几个原因。 一是，它允许我们保持小规模团队，因为我们不需要人员来执行重复，平凡和无聊的任务。 二是，它让队友可以大部分时间都专注于做一些影响深远的工作，而不是被一些无足轻重的繁琐细节而困扰。
从别人那里学习
有很多知识是由其他人发掘的。 不幸的是，没有多少人写了有关远程工作的，以及如何管理它的材料。 大多数文章非常肤浅，譬如只是建议人们“使用Google环聊”，这不是超级有用的。最后，了解远程工作的最佳方式是询问那些在做远程工作的人。 我从Lance Walley，Buffer的Joel Gascoigne，整个Basecamp（以前的37Signals）团队，GitHub的Zach Holman和一些其他创始人及远程工作人员那里学到了很多。希望本文能够帮你深入了解如何管理远程团队。 但请不要把它当成普遍真理。最大的赢家不是从网上找到线索的人，而是那些通过亲身实践并发现答案的人。
在 Oracle 官方支持站点 MOS 上，最近发布了两篇告警文章
官方给出了如下声明
对于database link带来影响的原因如下
官方给出的建议如下：
关于两篇文档内容总结如下
1、 通过 DB Link 的查询会同步数据库的 SCN，也就是这个原理会导致很多 SCN 耗尽的 Headroom 问题
2、 如果都是未应用补丁的低版本数据库互访，不会出现问题；但是如果是未应用补丁的低版本和应用了补丁的高版本之间互访，就可能出问题。
3、 如果低版本和高版本互访，在2019年4月之后，跨 DB Link 的访问不一定会出现问题，尤其是 SCN 的增长率维持低位的数据库；但是由于算法的改变，很可能会出现问题，而且概率很高；
4、 引入这样的修改和补丁，是因为 SCN 是 Oracle 的核心机制，过去遇到的 Headroom问题必须获得彻底消除，所以算法需要调整，这是非常核心的改变。
5、 如果数据库全部维持在低版本，或者不通过 DB Link 互访，则无所谓; Oracle 也提供禁用该特性的功能，但是不保证之后不改变。
在 MOS 上文档 1393360.1中，就有各种已知的描述，如果低版本的数据库 SCN 不能抬升，那么就可能遭遇：ORA-19706: invalid SCN 的错误（详情见附件）。
对于Oracle官方给出的该声明，整体建议如下：
方案一：对于低版本和高版本互访的dblink链接进行应用改造，如非必要，请尽可能采用客户端连接的方式进行交互
方案二：对dblink的源端以及目标端数据库进行补丁升级，以符合官方要求版本太低的可进行跨版本升级，但需要先对稳定性以及性能进行调整测试，如SPA等。
不建议：关闭scn新特性
因为当前关闭新特性是为了向下兼容，那么今后新数据库部署，就都需要关闭该功能，但是Oracle 虽然现在提供禁用该特性的功能，却不保证之后不改变，以后也会有诸多功能基于此特性开发，越往后进行应用，覆盖面约广，所以建议在过渡期内升级打patch，而不是等该特性运行后，大面积实行。
一． CPU（Critical Patch Update）
一个CPU内包含了对多个安全漏洞的修复，并且也包括相应必需的非安全漏洞的补丁。CPU是累积型的，只要安装最新发布的CPU即可，其中包括之前发布的所有CPU的内容。事实上，在CPU之前的安全漏洞修改除去个别例外也被包括在CPU中。Oracle公司只对处于标准技术支持和延长支持期间的产品提供CPU更新，对处于维持支持范围的产品不提供新的CPU.（对于9.2以前的版本，只对处于ECS和EMS期间的版本提供CPU更新。）
一般对当前补丁发行版及前一个版本提供CPU，但也有只限于当前补丁发行版的例外情形。也就是说，一般需要先安装最新PSR后才可能安装CPU.由于是累积型的定期发布，所以对于某一平台的某一版本，如果两次CPU发布期间没有发现新的安全漏洞，则新发布的CPU与前一版本完全相同。
可以在以下网址中可以找到CPU发布的信息，只要在Oracle 免费注册一个用户，就可以收到这些补丁的信息。但是，只有技术支持签约用户才可以从metalink下载补丁文件。
http://www.oracle.com/technology/deploy/security/alerts.htm
Oracle公司制定的CPU的发布日期大约在一月、四月、七月和十月的最接近15的星期二。
Critical Patch Updates
Critical Patch Updates are the primary means of releasing security fixes for Oracle products to customers with valid support contracts. They are released on the Tuesday closest to the 15th day of January, April, July and October. Starting 2011, the scheduled dates for the release of Critical Patch Updates will be on the Tuesday closest to the 17th day of January, April, July and October. The next four dates are:
12 October 2010
18 January 2011
19 April 2011
19 July 2011
对于每一个CPU，附有相应的说明文档（Critical Patch Update Note），其中介绍安装过程和注意事项，在安装之前应认真阅读此文档。同样也存在文档“Oracle Critical Patch Update MM YYYY Known Issues for Oracle Database”，其中列出了说明文档中没有给出的新信息。
二．PSR（Patch Set Release） 和 PSU（Patch Set Update）
8i,9i,10g,11g这是其主要版本号，每一版本会陆续有两至三个发行版，如10.1，10.2,和 11.1，11.2分别是10g和11g的两个发行版。对于每一个发行版软件中发现的BUG，给出相应的修复补丁。每隔一定时期，会将所有补丁集成到软件中，经过集成测试后，进行发布，也称为PSR（Patch Set Release）。以10.2为例，10.2.0.1.0是基础发行版，至今已有三个PSR发布，每个PSR修改5位版本号的第4位，最新10.2的PSR为10.2.0.4.0。(11.1.0.6.0是11.1的基础发行版，11.1.0.7.0是第一次PSR) 。
在某个PSR之后编写的补丁，在还没有加入到下一个PSR之前，以个别补丁（Interim Patch）的形式提供给客户。某个个别补丁是针对Oracle公司发现的或客户报告的某一个BUG编写的补丁，多个个别补丁之间一同安装时可能会有冲突，即同一个目标模块分别进行了不同的修改。另外，即便在安装时没有发现冲突，由于没有进行严格的集成测试，运行过程中由于相互作用是否会发生意外也不能完全排除。
除去修改功能和性能BUG的补丁，还有应对安全漏洞的安全补丁。Oracle公司定期（一年四期）发布安全补丁集，称之为CPU（Critical Patch Updates）。
由于数据库在信息系统的核心地位，对其性能和安全性的要求非常高。理应及时安装所有重要补丁。另外一个方面，基于同样的理由，要求数据库系统必须非常稳定，安装补丁而导致的系统故障和性能下降同样不可接受。DBA经常面临一个非常困难的选择：对于多个修复重要BUG的个别补丁是否安装。不安装，失去预防故障发生的机会，以后故障发生时，自己是无作为；安装，如果这些补丁中存在着倒退BUG，或者相互影响，以后发生由于安装补丁而造成的故障时，自己则是无事生非！而等待下一个PSR，一般又需要一年时间。因此，出现了PSU（Patch Set Update）。
PSU解决以下几个问题：
1. 减轻PSR周期长而带来的不能及时更新的影响；
2. 解决多个个别补丁冲突和相互影响的问题；
3. 减轻DBA安装补丁的负担：补丁安装次数，不定期检查补丁发布。
PSU具有如下特点：
第一、PSU是PSR的补充，在两次PSR发布之间发布多个PSU，加快更新速度。每个PSU修改5位版本号的第5位。例如，安装此次发布的 PSU后，11.1版本“升级”为11.1.0.7.1；10.2版本为10.2.0.4.2。
第二、每个PSU中包含25至100个重要补丁，作为一个整体进行严格测试，解决冲突问题，保证系统的稳定性。PSU不仅包括对功能、性能修复的一般补丁，也包括安全补丁。
第三、PSU定期发布，计划一年分布四次，发布日期与CPU发布日期相同。由于PSU包括同期发布的CPU，只要安装PSU即可。（对部分平台，仍提供单独的CPU，供客户选择）
第四、如同PSR和CPU一样，PSU是累积型的，即只要安装最新的PSU就自动包括以前所有PSU的内容。
第五、使用DBA已经熟悉的Opatch工具安装/删除PSU，命令仍是apply和rollback。一个PSU可视作一个个别补丁，安装和删除操作都很简便。
第六、现有的个别补丁与PSU的关系分为三类：完全独立；是PSU的一部分；与PSU冲突。第一类的个别补丁与PSU相互没有影响，可以独立的安装或删除。对于第二类，在安装PSU之后，自然没有必要安装。若在PSU之前已安装，则在安装PSU时会被自动删除。对于第三类个别补丁，如在PSU之前已安装，必须在安装PSU时删除。客户可以向Oracle公司技术支持部门提出申请，由Oracle负责提供与PSU不冲突的，在PSU之上安装的相应的新的版本。
PSU的限制：必须是在正常技术支持范围之内的版本（11.2、11.1和10.2），并且PSU只能在最新PSR之上安装。
三．OPatch 命令
先看一个官网的Oracle OPatch 的说明：
Oracle Software Patching Using Opatch
http://download.oracle.com/docs/cd/B19306_01/em.102/b16227/oui8_opatch.htm
从9.2版开始，Oracle公司实现了个别补丁安装工具opatch. opatch使用一个称为inventory的系统数据结构（严格说是与oui共享inventory），集中管理所有已安装的个别补丁；个别补丁的安装和卸载都使用opatch命令完成，冲突检测也由opatch在安装时自动完成；提供列表命令可以很方便得到已安装个别补丁的信息。
10g（10.1和10.2）版本中，opatch作为一个标准工具，在安装时自动安装。（安装在$ORACLE_HOME/OPatch下。）而对于9.2版，需要从metalink下载opatch.无论是哪一个版本，系统中是否已经安装opatch，在使用之前，应从metalink下载最新版本的opatch.很遗憾，由于系统实现的问题，10.2使用的opatch与之前版本（10.1和9.2）使用的opatch不兼容，不能混用，这一点必须注意。
opatch是使用perl编写的脚本程序（其中也使用JAVA API）。使用的perl版本是5.6版，虽然在5.6之前的版本中也可运行，但应尽可能安装5.6或以上的版本的perl. 对于DBA来说一个好消息是，如果安装9.2版软件时保留了HTTP服务器，则在$ORACLE_HOME/Apache下会自动安装perl.（10g会自动安装配置perl和opatch.）
3.1 opatch命令存放位置
该命令的存放位置在$ORACLE_HOME下的OPatch目录下。
-bash-3.2$ pwd
/u01/oracle/oracle/product/10.2.0/db_1/OPatch
-bash-3.2$ ls
docs emdpatch.pl jlib opatch opatch.ini opatch.pl
-bash-3.2$ ls -lrt
total 44
-rw-r–r– 1 oracle oinstall 18107 Apr 18 2005 emdpatch.pl
-rw-r–r– 1 oracle oinstall 2193 Jun 1 2005 opatch.pl
-rwxr-xr-x 1 oracle oinstall 5672 Jun 1 2005 opatch
drwxr-x— 2 oracle oinstall 4096 Apr 21 13:24 jlib
drwxr-x— 2 oracle oinstall 4096 Apr 21 13:24 docs
-rw-r–r– 1 oracle oinstall 49 Apr 21 13:24 opatch.ini
3.2 使用“-help”参数可以获得opatch命令的帮助信息
-bash-3.2$ ./opatch –help
Invoking OPatch 10.2.0.1.0
Oracle interim Patch Installer version 10.2.0.1.0
Copyright (c) 2005, Oracle Corporation. All rights reserved..
Oracle Home : /u01/oracle/oracle/product/10.2.0/db_1
Central Inventory : /u01/oracle/oraInventory
from : /u01/oracle/oracle/product/10.2.0/db_1/oraInst.loc
OPatch version : 10.2.0.1.0
OUI version : 10.2.0.1.0
OUI location : /u01/oracle/oracle/product/10.2.0/db_1//oui
Log file location : /u01/oracle/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch-2010_Aug_09_03-05-40-CST_Mon.log
Usage: opatch [ -help ] [ -r[eport] ] [ command ]
command := apply
lsinventory
query
rollback
version
<global_arguments>:= -help Displays the help message for the command.
-report Print the actions without executing (deprecated).
example:
'opatch -help'
'opatch apply -help'
'opatch lsinventory -help'
'opatch rollback -help'
OPatch succeeded.
这个是10.2.0.1版本的opatch. 在10.2.0.4 版本的opatch命令与之前的又不同，它有添加了几个命令。
-bash-3.2$ ./opatch –help
Invoking OPatch 11.1.0.6.6
Oracle Interim Patch Installer version 11.1.0.6.6
Copyright (c) 2009, Oracle Corporation. All rights reserved.
Usage: opatch [ -help ] [ -r[eport] ] [ command ]
command := apply
lsinventory
napply
nrollback
rollback
query
version
prereq
util
<global_arguments>:= -help Displays the help message for the command.
-report Print the actions without executing.
example:
'opatch -help'
'opatch apply -help'
'opatch lsinventory -help'
'opatch napply -help'
'opatch nrollback -help'
'opatch rollback -help'
'opatch prereq -help'
'opatch util -help'
OPatch succeeded.
官网上对命令的一些解释：
apply
Installs an interim patch. Refer to "apply Command" for more information.
napply
Installs n number of patches (hence napply). Refer to "napply Command" for more information.
auto
Applies Oracle Clusterware patches. Refer to "auto Command" for more information.
lsinventory
Lists what is currently installed on the system. Refer to "lsinventory Command" for more information.
query
Queries a given patch for specific details. Refer to "query Command" for more information.
rollback
Removes an interim patch. Refer to "rollback Command" for more information.
nrollback
Removes n number of patches (hence nrollback). Refer to "nrollback Command" for more information.
version
Prints the current version of the patch tool. Refer to "version Command" for more information.
在$ORACLE_HOME/OPatch/docs目录下，用指南文件（Users_Guide.txt），其中有详细的命令格式和使用示例，可以参考。
Opatch执行操作时，除在屏幕输出结果外，还生成日志文件。日志文件的路径和文件名格式如下：
$ORACLE_HOME/.patch_storage/< patch_id >/< action >-< patch_id >_< mm-dd-yyyy_hh-mi-ss>.log
其中“patch_id”是Oracle技术支持部门为个别补丁分配的编号。
3.3 opatch安装个别补丁示例：
以Patch 5689937 为例。
3.3.1 patch下载
从metalink下载补丁的压缩文件p5689937_10201_LINUX.zip.将此文件解压缩至某一目录中。解压缩后，这一补丁的所有文件都在子目录5689937下，目录名就是个别补丁的补丁号，opatch依据目录名获得信息，所以一定不要重命名子目录。
3.3.2 安装patch
进入patch文件5689937 目录，在patch的目录下面有一个readme的安装文档，里面有安装步骤和一些问题的处理方法。
3.3.2.1 关闭数据库和监听
Shut down all instances and listeners associated with the Oracle home that you are updating.
3.3.2.2. 进入patch目录，运行opatch apply命令
-bash-3.2$ cd p5689937_10201_LINUX/
-bash-3.2$ ls
5689937 patchmd.xml README.html
-bash-3.2$ cd 5689937/
-bash-3.2$ ls
custom etc files README.txt
-bash-3.2$ pwd
/mnt/p5689937_10201_LINUX/5689937
-bash-3.2$ export PATH=$PATH:/usr/ccs/bin
-bash-3.2$ $ORACLE_HOME/OPatch/opatch apply
3.3.2.3 启动实例，运行相关脚本
-bash-3.2$ cd $ORACLE_HOME/cpu/CPUJan2007/ — 要进入这个目录才能找到脚本
-bash-3.2$ sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 – Production on Mon Aug 9 04:48:19 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 281018368 bytes
Fixed Size 1218968 bytes
Variable Size 83887720 bytes
Database Buffers 192937984 bytes
Redo Buffers 2973696 bytes
Database mounted.
Database opened.
SQL> @catcpu.sql
如果catcpu.sql 脚本报任何无效对象，执行如下脚本：
SQL> @?/rdbms/admin/utlrp.sql
可以用如下SQL 检查无效对象：
SQL> SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE STATUS= 'INVALID';
3.3.3 用inventory 命令查看已经安装的patch
-bash-3.2$ $ORACLE_HOME/OPatch/opatch lsinventory
Invoking OPatch 10.2.0.1.0
Oracle interim Patch Installer version 10.2.0.1.0
Copyright (c) 2005, Oracle Corporation. All rights reserved..
Oracle Home : /u01/oracle/oracle/product/10.2.0/db_1
Central Inventory : /u01/oracle/oraInventory
from : /u01/oracle/oracle/product/10.2.0/db_1/oraInst.loc
OPatch version : 10.2.0.1.0
OUI version : 10.2.0.1.0
OUI location : /u01/oracle/oracle/product/10.2.0/db_1//oui
Log file location : /u01/oracle/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch-2010_Aug_09_04-55-55-CST_Mon.log
Lsinventory Output file location : /u01/oracle/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/lsinv/lsinventory-2010_Aug_09_04-55-55-CST_Mon.txt
——————————————————————————–
Installed Top-level Products (1):
Oracle Database 10g 10.2.0.1.0
There are 1 products installed in this Oracle Home.
Interim patches (1) :
Patch 5689937 : applied on Mon Aug 09 04:43:27 CST 2010
Created on 8 Jan 2007, 11:48:31 hrs US/Eastern
Bugs fixed:
4671216, 4925103, 4604970, 4616376, 5689937, 4288876, 5225798, 5694720
4754888, 4750469, 4369235, 4751931, 4966716, 5049080, 5242648, 4348230
5490846, 4630549, 5490936, 5049088
——————————————————————————–
OPatch succeeded.
或者用$ORACLE_HOME/OPatch/opatch lsinventory –detail 命令查看详细。
3.4 卸载 opatch
3.4.1 关闭实例和监听
SQL> shutdown immediate
3.4.2 执行opatch命令
-bash-3.2$ cd $ORACLE_HOME/OPatch/
-bash-3.2$ ./opatch rollback -id 5689937
3.4.3 启动实例，执行catcpu_rollback.sql脚本
-bash-3.2$ cd $ORACLE_HOME/cpu/CPUJan2007/
-bash-3.2$ sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 – Production on Mon Aug 9 05:04:19 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 281018368 bytes
Fixed Size 1218968 bytes
Variable Size 109053544 bytes
Database Buffers 167772160 bytes
Redo Buffers 2973696 bytes
Database mounted.
Database opened.
SQL> @catcpu_rollback.sql — 这个脚本在patch的安装目录里也有
如果在运行中出现无效对象，运行如下脚本：
SQL> @?/rdbms/admin/utlrp.sql
检查无效对象：
SQL> SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE STATUS = 'INVALID';
关于Patch的说明就到此。 在后说明一点。 有时我们的生产库遇到一个问题，但是又不能十分确定是否是某个bug的时候，可以先考虑打patch看一下，如果解决了更好，如果不能解决，把patch删掉即可。 这样可以把问题控制在可控的范围内，避免把问题扩大化。
