Making a good Tuning Specification

1. Identify the user actions that the business needs you to optimize, and identify the contexts in which those actions are important.

识别那些业务所需要的用户操作，判断这些操作的上下文关系很重要
2. Prioritize these user actions into buckets of five.

将这些用户操作分为不同类别，每种类别不少于5个问题。比如有10个问题，那么最好分为2组，第一组是最重要的急需解决的问题，第二组是比较重要的问题。当然，每个用户可能都会认为自己的问题最重要，那么要进行甄选，做出正确的选择。

3. For each of the actions in your top bucket, determine whom you can observe executing the action in its suboptimal context and when you can make the observation.

 

因此，不能迷信v$视图，虽然那里面可能蕴含问题，但你会在“花1天的时间来修复v$视图里面发现的问题”和“花1小时来解决用户关心的问题”中，选择哪一个呢？

一个例子：
公司生产硬盘，目前有一整个仓库的硬盘都被订购准备发货。不过现在每天都接到用户的抱怨：都好几个星期了，我订的货怎么还没到？！
再看看公司仓库门口停的几辆“SFEXPRESS“货车，司机们正休闲的坐那儿打麻将呢。为嘛这么悠闲，客户都快等疯了，他们还有心情打麻将？仔细一打听，原来他们还在等着核对装货单呢，不幸的是打印装货单的程序跑的慢的要死，半天都打不出一张来。
so，什么是关键的性能问题？

 

如何得到关键的影响性能的用户操作，通过下面几个手段引导用户来回答你关心的问题：

• Actions that are business critical
• Actions that run a long time
• Actions that are run extremely often
• Actions that consume a lot of capacity of a resource you’re trying to conserve

通过下面几个问题，获取问题产生的前后联系：

• Is the action always slow?
• Is it slow only at a particular time of day (week, month, or year)?
• Is it slow only when it runs at the same time as some other program(s)?
• Is it slow only when the number of connected users exceeds some threshold?
• Is it slow only after some other program runs (upload, delete, etc.)?

 对发现的问题进行优先级排序，当然，那个用户最关心且最有经济价值的问题将放在首要位置来优化