贴出Troubleshooting Oracle Performance 一书第一章《性能问题》的翻译稿的部分节录(初稿)。排版有点差。请多提意见。翻译的过程得到了很多朋友的大力协助，最后我会单独一一致谢!
(此书中文名字还未敲定)
如何解决性能问题？
简单而言，一个应用的目标是为使用它的业务提供便利。所以，优化一个应用性能的理由就是要最大化这种便利。这并不意味着性能的最大化，而是找到成本与性能之间的最佳平衡点。实际上，优化任务包括的努力总要从你期望获得的好处得到补偿。这意味着从商业的角度看，性能优化不总是有意义的。
业务视角 vs. 系统视角
优化一个应用的性能是为了给一个业务提供好处。所以当你着手接近(approaching)性能问题的时候，必须先理解业务问题和需求。然后才跳入应用的细节。图1-2演示了一个具有业务视角的人（一个用户）和一个具有系统视角的人（一个工程师）之间的典型不同。
图 1-2. 不同的观察者有不同的角度
认识到两种视角之间的因果关系是重要的，虽然结果必须从业务视角来识别，其原因必须从系统视角来确定。所以，如果你不想去诊断不存在或不相干的问题（强迫调优失调症），理解从业务视角看问题就变得更重要 — 即使这需要更多精细的工作。
把问题分类
对付性能问题的第一步是要从业务视角确定它们并为每个问题设定一个优先级和目标。如图1-3所示。
从业务视角来确定问题 > 设定每个问题的优先级 > 设定每个问题的优化目标
业务问题不能通过观察系统统计发现，而必须从业务视角来确定。如果代之以监控服务等级协议，很明显，可以从没有满足期望的操作来确定性能问题。否则，除了询问用户或者负责的人之外没有其他可能性。这种讨论将涉及一系列操作。例如：注册一个新用户，运行一个报告或加载一批可能很慢的数据。
你知道哪些是有问题的操作，就该给他们排个优先级了。考虑类似这样的问题：如果我们只能处理5个问题，应该如何做呢？当然，最好是全部解决它们。但有时候时间或预算是有限的。此外，缺乏必要措施的情况下，不可能解决不同问题的相互冲突。要强调的是在设定优先级时，当前的性能可能是不相干的。例如，如果你处理一整套报告，不一定最慢的那个具有最高的优先级。可能最快的那个也是执行最频繁的那个，因此有可能具有最高优先级并需要首先优化。再说一次，是业务需求在驱动你。
对每项操作，你应当为优化设定一个可量度的目标。诸如”当创建用户按钮按下以后，处理时间最多2秒”。如果性能需求甚至服务等级协议可以得到，可能目标已经知道了。否则，再强调一次，必须考虑业务需求去确定目标。注意，没有目标就不知道何时停止研究一个更好的解决方案。换言之，优化可以是无止境的。记住，努力永远要和获利取得平衡。
解决问题
诊断整个系统比诊断一个单独的组件要复杂得多。因此，任何可能的时候，你应当一次只解决一个问题，简单地从问题列表按照优先级从高到低的顺序解决。
对每个问题，如图1-4所示，必须回答3个问题：
-
时间花在哪里了？首先，你必须确定时间花在哪里了。例如，如果一个特定操作用时10秒，你必须找到这10秒里绝大部分花在哪个模块或组件。
- 时间是如何耗费的？一旦你知道时间花在哪里了，你必须找到时间是如何耗费的。例如，你发现应用用了4.2秒在CPU上，0.4秒做I/O操作，5.1秒等待另一个组件发出队列出队消息。
- 如何减少时间耗费？最后，才是找出怎样使操作更快的时候。要做到这个，重要的是聚焦到处理中最大时间消费的部分。例如，如果I/O操作占整个处理时间的4%，那么即使它很慢也没必要对他进行调整。
时间花在哪里了？ > 时间是如何耗费的？ > 如何减少时间耗费？
要注意由于副作用的益处，有时候修复一个特定问题的同时也会修复另一个问题。当然，相反的情况也会发生。采取的措施可能引入新的问题。所以，很有必要认真考虑修复过程中可能引起的所有副作用。显然，所有改变在应用到生产环境前都要经过仔细测试。
–EOF–
翻译有硬伤. 不再继续找了.
s/所以当你接近性能问题的时候/所以当你遇到性能问题的时候/
s/不同的观察者有不同的角度/不同的观察者有完全不同的角度/
s/不可能解决不同问题的相互冲突/不可能忽略那些用于解决不同问题的指标间相互冲突的情况/
@fcicq
第一条，修改了，那句行文的确不符合汉语语法，但不是你说的那个”遇到“。
至于后两条，您还是看过原文再说吧
anyway , 多谢第一时间冲出来！
“简单而言，一个应用的目标是为使用它的业务提供便利。所以，优化一个应用性能的理由就是要最大化这种便利。这并不意味着性能的最大化，而是找到成本与性能之间的最佳平衡点”
这句话说的非常好，优化就是一种平衡，优化也是一门艺术！
@fcicq
s/所以当你接近性能问题的时候/所以当你遇到性能问题的时候/
这里的替换纯粹是扯淡…
来凑个热闹。
第一条，我建议译作 着手(解决)。
第二条，完全是个人风格差异，无所谓对错。
第三条，解决不同问题的手段有时会有冲突，这种情况是不能忽略的。
过来学习着。。
时间管理里面也讲得不错,这个也很好.
仅供参考：
业务视角，系统视角 – 业务角度，系统角度？
理解从业务视角看问题就变得更重要 — 从业务视角理解问题（是什么）就变得很重要
业务问题不能通过观察系统统计发现 — 业务问题不能通过观察系统统计资料(或者信息?)发现
如果代之以监控服务等级协议 — 这里原文用的是in place 而不是 in place of. In place 有适当的,各就其位的意思，所以可否考虑译成：如果已经能够监控服务等级协议，很明显……
你知道哪些是有问题的操作 — 一旦你知道哪些是有问题的操作 (原文这里有个Once)
此外，缺乏必要措施的情况下，不可能解决不同问题的相互冲突 — 这就话我对原文的理解是：某些情形下，需要一些特别的措施来解决不同问题之间的相互冲突，不可能扔下这些情形不管。 原文句子太长，不知道怎么翻译好。
如果性能需求甚至服务等级协议可以得到 — 如果有性能需求甚至服务等级协议，
所有改变在应用到生产环境前都要经过仔细测试。 — 改变换成改动？
感觉Fenng采用的是直译的方法。所以译文读起来英文味道很重。如果能适当的采用意译，可能读起来会更顺。
如果能达到你写博客的水准，就完美了。:-)
@Trevor
感谢您的反馈，前几章涉及通用知识，翻译起来的确捉襟见肘
Troubleshooting Oracle Performance 是本好书。
Fenng你们能够翻译出来是造福大家的好事! 绝对的支持！
期待ing
Trevor说的对, 读起来有点硬. 知错就改, 希望下次下本书意译的效果更上一层楼.
翻译的过程学到不少东西,从自己的错误中学习. 而且对中英文能力都有提高,特别是语言融合能力,快速中英互译,自我感觉,比那些老移民强很多. 一位老兄(.Net大师)说出”灵敏”(Agile)软件开发,令我当场爆笑不止.
译得太直了些，很多“是…的”这样的句式。其实只要养成了习惯，要译得更符合中文习惯并不难。
比如：
认识到两种视角之间的因果关系是重要的/认识到两种视角之间的因果关系很重要
当前的性能可能是不相干的/当前的性能可能毫不相干
我建议把大多数“一个”去掉。
哈哈, 被我找到这本书的原版, 找时间好好看下才行….
对 TOP 第一章校正了网友提出的大部分问题，暂时冻结这一章的稿件。
意见在这里给出了： [图灵beta]如何解决Oralce的性能问题？
我还没有买呢，有空一定要读读