10202，Media recovery not enabled or manual archival only 0x10000 。BUG-4591936

WINDOWS2003 ORACLE10202

非归档模式，BDUMP目录下出现的TRACE信息：
由LGWR进程的跟踪文件，内容类似：


*** SERVICE NAME) 2007-02-06 19:33:39.265
*** SESSION ID77.1) 2007-02-06 19:33:39.265
Maximum redo generation record size = 382976 bytes
Maximum redo generation change vector size = 370276 bytes
*** 2007-02-07 00:00:06.859
Media recovery not enabled or manual archival only 0x10000
...
Media recovery not enabled or manual archival only 0x10000
*** 2007-02-08 09:00:10.656
Media recovery not enabled or manual archival only 0x10000

ORACLE 的解释：

Cause
Bug 4591936
Abstract: KCCSGA_UPDATE_CKPT,KCCDEBUG_LEVEL,MEDIA RECOVERY MESSAGES ARE LOGGED AT STARTUP
Fixed In Ver: 11.0

Solution

These messages were added for debugging purpose and can be ignored.
Delete these files manually or use some job to clean up diskspace.

At the time of writing this note , there isn't any one-off patch to fix this issue on 10.2.

You can always raise a new SR requesting for a backport fix on top of 10.2 for your platform.

一个小BUG，至多占点磁盘空间，不会危害数据库。

lcm_0090828在itpub上发了贴子:发觉数据库很慢时，如果不用分析工具如statspack等，如何快速找出原因？
lcm_0090828给出自己常用的checklist:
1. 检查表空间资源
2. 归档是否正常（归档空间满时，会等待归档，之后用户进程就死掉了）
3. 检查alert 信息
4. 用vmstat, top命令看看系统i/o, cpu的繁忙程度，以及哪个进程在消耗资源，结合v$process, v$session, v$sqlarea 等视图查找出终端机器，以及其使用的sql 语句等。
5. 有没有死锁
6. 有时用户进程运行的程序会报错，就根据错误提示寻找根源及解决办法，可能是初始化参数设置不合理。

这个是一个方法论的贴子，从它的回复可以看出大家常用的性能调优方法，一般都是从wait events入手，根据wait events表现的特征，然后从最可能的方向去查证，这的确是一个很好的因果关系，不过偶一向都不如此。

偶一直比较喜欢最直接的方式，就是用sql直接去找原因，如果从v$sqlarea中找不到想要的，才会从wait events去求证，有些sql很快就结束了，如果从wait events上去求证，即是看到了特征，然后去查v$sqlarea时可能该sql已经结束了。。。

本人在用合肥局的冷备份做恢复时，启动数据库实例时遇到错误：ORA-01599 failed to acquire rollback segment (string), cache space is full (currently has (string) entries) ，经过分析发现可能是MAX_ROLLBACK_SEGMENTS参数过小造成的，于是修改该参数，改成100，问题得到解决。

环境：省电力公司小机IBM P570双机Oracle9i RAC ＋ AIX5.30

问题：sys登陆有时会报如下错误

ORA-01017: invalid username/password; logon denied

解决方法：经分析可能是其中一节点sys密码错误造成。重新修改密码问题解决。

环境：省电力公司小机IBM P570双机Oracle9i RAC ＋ AIX5.30

问题：修改归档方式报错如下图，

原因分析：是init.ora中群集参数*.cluster_database=true引起。

解决方法：1.停止所有node
2.修改init 文件*.cluster_database=false
3.在一个node 做修改

可以在数据库启动的情况下
alter system set cluster_database = false scope=spfile;
或者 create pfile =... from spfile;
然后编辑 pfile

startup mount;
alter database archivelog ;
SQL> archive log list;
SQL>alter database open;
4.还原 *.cluster_database=true
5.启动所有node进入sqlplus 然后 create spfile = ... from pfile=...;
6.验证：show parameter log_archive_start

环境：省电力公司小机IBM P570双机Oracle9i RAC ＋ AIX5.30

问题：其中有一节点无法通过TNS连接，报错如下图：

TNS服务名配置如下：

ORA921 =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.138.1.15)(PORT = 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = ora921)

)

)

解决方法：经过诊断发现只要把“SERVICE_NAME”改成“SID”即可。

从前有个地主，很多地，找了很多长工来干活。长工们受了很多苦，苦得活不下去了，于是天天喊：“神啊，救救我吧！”
果然，人世间来了一个大先知。先知对长工们说：“你们傻呀，把地主和地主婆杀了，土地不就是你们的了吗？”长工们觉得有道理，于是一起打死了地主和地主婆。先知拿到地主身上的钥匙，打开粮仓教长工们如何煮大锅饭吃，然后又盖了一栋团结楼给他们住。长工们有了房子住，直呼万岁。 [url]www.6park.com[/url]


几年后，长工们的村子慢慢富了起来。这时候，在这群人中间又出现了两位小先知。其中一个，是有权有势的工头，他变成了新的地主；另一个是知识分子，变成了臭老九谋士。
谋士对地主说：“东家，长工们这几年手上有点钱了，他们住的房子，又不是你的，又不是他们自己的。每月只交点租子，不划算。反正他们也要永远住下去，你干脆把房子卖给他们，还可以把他们这几年攒的钱都收回来”
地主听后十分高兴，于是问：“可是怎么卖呢？”
谋士说：“这个简单，起个名堂叫公房出售，告诉他们房子永远归他们了。”
地主点点头，可还是有些疑问：“是不错，可租金怎么办？”
谋士就笑了：“照收不误呀。起个日本名儿，叫物业管理费嘛。”
地主很快照此实行了，赚了好多钱，长工们那个高兴啊！ [url]www.6park.com[/url]

过了几年，地主的村子变成了城市，长工们也大多安居乐业了。
谋士对地主说：“东家，长工们这几年手上又有钱了，咱们盖些新房子卖给他们吧。”
“可是，盖房子的钱从哪儿来呢？”地主疑惑地问。
谋士晃了晃他那灵光的大脑袋，说：“起个名堂叫旧城改造，我们拆了旧房子盖新的，再叫他们自己买回去。等他们把手里的钱给了我们，我们再拆，拆了再盖，钱可以生钱不说，我们还可以多盖一些卖给别人。”
“可是，长工们没地方住要怎么办？”地主担忧地摇了摇头。
“你忘了，咱们村边还有个大猪圈嘛，让他们先暂时住呀，大不了我们少收点房租。”谋士慷慨地说。
地主很快又照做了。可是这次，有些长工不高兴。
地主担心事情闹大，就问谋士怎么办。谋士不慌不忙地说：“给那些闹事的工人安个丁子户的罪名，你的家丁不就派上用场了吗？”
这下，长工们傻眼了，只好打掉牙往肚子里咽。
经过反复倒卖，地主又赚了好多钱。 [url]www.6park.com[/url]


又过了几年，很多有钱人慕名而来，地主的土地更值钱了。
谋士对地主说：“东家，你看最近几年有这么多有钱人来，他们都没好房子住，不如咱们盖些别墅什么的卖给他们吧，还可以把价格卖高点。”
“可是，我们哪里还有地呀？”地主这下不明白了。
谋士拍拍脑门，说：“把那些长工的房子拆了，不就又有地了吗？”
地主吓了一跳：“长工们不干怎么办？”
谋士说：“咱们这次给他们多点儿钱，再到咱们的猪圈旁边随便修点房子便宜卖给他们。长工们只要有房子住，是不会闹事的。”
“可是，猪圈旁边的房子他们愿意住吗？”地主还是很担心。
谋士安慰他说：“没关系的，咱们起个名堂叫经济适用房，再从这里修两条马车道过去。价格便宜交通又方便，长工们抢还来不急呢。”
地主又说：“要是他们钱不够怎么办？”
谋士说：“从咱家的钱庄借钱给他们呀，一年6分利，咱这钱还能生钱崽，又没风险。”
地主又实行了。长工们拿到了钱，可地主的“经济适用房”到现在才建了一间。长工们只好排着长队等房子，一直等…… [url]www.6park.com[/url]

于是长工们开始闹事了。地主有点慌，忙找来谋士商量对策。谋士说：“找几个信得过的工头，放风出去，就说房子要跌价了，别买了，租房了住吧。”
结果，这么多年过去了，长工们的钱全没了，还在租房子住，直到永远。

紧急性能调整的方法和第二章介绍的性能调整方法是一样的，只不过紧急性能调整的目标是快速解决问题，尽快使系统恢复到正常状态。

紧急性能调整方法包括以下步骤：

1.调查性能问题并收集性能问题所表现的症状。根据用户的反馈确定问题是吞吐量太小还是响应时间太长。

2.全面检查应用系统中所有硬件的使用情况。检查CPU使用率是否过高、内存的使用、磁盘的情况以及网络的性能。将问题定位到数据库服务器或者应用程序程序上。

3.确定是由数据库服务器上CPU的使用率过高还是由于等待事件造成的问题。

如果是CPU使用问题，进行下列检查：

在操作系统上检查大量消耗CPU资源的会话；

在数据库上查询消耗buffer gets过多的会话，可以通过V$SESSTAT, V$SQL进行查询；

执行计划改变造成的低效的SQL语句（比较困难）；

不正确的初始化参数设置；

版本发行造成的代码的改变或者部件的升级。

如果是等待事件造成的问题，可以通过查询视图V$SESSION_WAIT找到问题产生的根源。

4.使用应急手段是系统恢复稳定。可能的操作包括屏蔽部分应用程序的使用或者限制应用的负荷，也可能包括中止正在执行的任务甚至是重起系统。

5.验证系统是否已经稳定。系统稳定后应根据第二章中介绍的严格的性能调整方法来诊断并解决性能问题。

统计信息分为三部分：

1.操作系统统计信息：包括CPU、内存、磁盘和网络四部分。

2.数据库统计信息：包括Buffer Cache、Shared Pool和Wait Events三部分。

3.应用程序统计信息

收集统计信息：

收集操作系统统计信息的工具：sar、vmstat、mpstat、iostat和netstat等。

收集数据库统计信息的工具：Statspack、OEM和BSTAT/ESTAT脚本（推荐用statspack代替）。

应当在系统刚建立时和系统工作正常时收集统计信息，为系统保留历史统计信息和性能基线。

V$SYSSTAT视图中的USER COMMITS和REDO SIZE统计项可以给出数据库中的事务数和数据的改变量。另外‘session logical reads’可以在一定程度上表示系统查询的负载。但是当这个值发生变化并不一定意味着查询负载发生变化，还有很大可能是由于执行计划的改变导致了逻辑读发生了变化。

Oracle改进性能方法的步骤：

1.从客户得到公正的反馈。

2.收集操作系统、数据库和应用程序处于性能良好和性能较差两种状态的统计信息。如果无法收集到所有状态的统计信息，那么收集所有能收集到的。统计信息的缺失会给诊断问题带来很大的困难。

3.全面检查和当前性能问题有关的所有计算机的操作系统。检查硬件问题和系统资源的使用情况。

4.检查是否发生了Oracle数据库中10个最可能发生的一般性错误。

5.根据目前的症状作为线索，构造一个概念上的模型，来推断导致性能问题的原因。

6.给出一系列补救措施，并将它们按照有效性大小的顺序应用到系统中。最好的方法是每次只修改一个地方，然后观测修改后有什么不同。然而，现实中诸多限制可能无法允许多次的系统重新和过长的停机时间。那么如果同时修改多个地方，应该保证这些修改是彼此独立的。

7.验证这些改变是否能达到预期的效果，用户是否能感受到性能的提升。如果没有达到的话，继续寻找其他瓶颈并重定义概念模型，直到你对应用程序的理解更加的准确。

8.重复上面最后三步，知道性能问题解决或确认所要求的目标无法实现。

如何检查操作系统：

检查整个系统和每个CPU在user和kernel项上的CPU使用率；

确认没有分页和交换存在；

检查不同计算机间的网络延迟是否可接受；

检查磁盘是否存在较长的响应时间和队列；

确认不存在硬件错误。

一个性能概念模型的例子：

1.单用户模式在空闲服务器上运行任务，响应时间是否满足要求？

如果这种情况下都无法满足相应时间，则说明应用程序的设计存在问题，这时无论如何调优，在多用户模式下也不可能满足要求。这种情况应该收集应用程序内部统计信息，进行SQL TRACE检查SQL语句的执行计划。这时问题可能出在数据、索引、事务和SQL语句的设计上。

2.是否所有的CPU被使用？

如果kernel超过了40%，那么检查网络传输、分页、交换或进程瘫痪等。如果CPU的使用主要集中在user上，检查是否存在ORACLE数据库以外的其他进程消耗CPU资源。之后检查最消耗CPU资源的SQL语句。如果应用程序已经是优化的，不存在低效的SQL语句，考虑将部分工作放到非高峰时期或更换系统硬件。

3.如果性能没有达到要求，且CPU没有被重复利用。

检查等待事件，找出导致系统串行化的关键。如果不存在这种问题导致系统串行化，那么问题很有可能出在数据库之外。

Oracle系统中10个最容易犯的错误：

1.连接管理问题

2.没有重复利用游标、没有使用绑定变量导致的无法重用共享池的问题

3.数据库I/O配置错误

4.重做日志文件设置太小的问题

5.由于free lists、free list groups、transaction slots、rollback segment的设置较小导致cache中的data block串行使用问题。

6.长时间的全表扫描

7.磁盘排序

8.大量的系统递归SQL调用

9.方案移植时缺少索引或统计信息的错误和优化问题

10.使用非标准初始化参数的问题

性能问题应该从系统设计时期开始考虑，并延续到系统的生命期终止之时。

具有可伸缩性的系统是指当系统的负载增加一倍，系统需要的资源也同样增加一倍。说起来简单，但在现实环境中确难以做到。由于管理并发用户的开销的增长、锁事务的增长、一致性读负载的增加、操作系统负载的增加、低效的SQL或索引设计导致的过高的I/O等等因素，会导致系统资源的消耗的增长远大于一倍。

破坏可伸缩性的因素：

1.低效的应用程序设计、实施和配置

2.硬件部分的规模不合适

3.软件部分的限制

4.硬件部分的限制

系统的结构可分为硬件和软件两部分：

硬件部分包括：CPU、内存、I/O子系统和网络模块。

软件部分包括：管理用户接口、实现商业逻辑、管理用户请求和资源分配、管理数据和事务。

在设计系统时，应该考虑以下几个问题：

系统将支持多少用户？

用户的交互方式是什么？

用户所处的位置？

网络的速度怎样？

用户将访问多少数据？有多少数据是只读访问？

用户对响应时间的要求？

用户是否需要24小时服务？

是否所有的修改需要实时完成？

应用程序设计原则：

设计简单性原则：

1.如果表的设计复杂到没有人能够完全的理解，那么表的设计可能是比较差的。

2.如果SQL语句过长以致于优化程序无法优化该语句，那么SQL语句的设计、事务和表的设计一定存在问题。

3.如果表的相同列上被重复索引，那么索引的设计可能是有问题的。

4.如果提交的查询没有限定，以致无法迅速的将结果返回给在线用户，那么用户接口或事务的设计是有问题的。

5.如果数据库的调用被许多层软件从应用逻辑中抽象出来，那么，软件开发的方法可能存在问题。

数据建模：应当注意，不要在非核心数据单元上花费过多的时间。

表和索引的设计：选择合适的列进行索引、选择索引类型、注意索引的代价、关注索引中列的顺序。

一个表上如果有3个索引，那么当进行INSERT/UPDATE/DELETE操作时，会比不带索引的表慢大约10倍。

组合索引中，选择性高的列在前查询时需要的I/O更少。选择性低的列在前，有助于代排序操作的查询。

SQL执行效率：

数据库连接管理：应避免没有必要的过多连接。

数据库游标管理：使用cursor和绑定变量，尽量避免硬分析，较少软分析。

硬分析：sql语句第一次提交，并在共享池中无法找到。

软分析：sql语句第一次提交，但是可以在共享池中找到相同的语句。

实施新的应用程序：

切换方式包括两种：Big Bang Approach（所有用户一次性转移到新的系统上）和Trickle Approach（用户分多次转移到新的系统上）。

性能清单列表：

1.设置MAXINSTANCES, MAXDATAFILES，MAXLOGFILES，MAXLOGMEMBERS和 MAXLOGHISTORY的值高于预期值。避免系统的增长导致必须重建控制文件。

2.设置BLOCK SIZE和优化模式与开发环境中相同。如果测试环境中的所有SQL语句的执行计划都是正确的，可以测试环境中的统计信息导入到正式库中。

3.尽量少修改初始化参数。除了SGA的组成部分和归档目录的设置，其他初始化参数尽量保持默认值，可以为以后性能优化留下一定的余地。

4.通过设置数据库对象的存储参数来管理BLOCK的争用。

5.所有的sql语句应该被优化。

6.验证中间层软件和程序采用高效的方式连接数据库。

7.验证sql语句有效的利用游标。

8.确认所有方案的对象从开发环境移植到了产品数据库中。

9.一旦完成系统的切换，建立数据库和操作系统统计信息的基线。

10.发现最先出现的瓶颈。

查找运行系统里bad sql是一个古老的话题, 我们要根据自己的实际情况来分析。绝不能教条的运用下面介绍的这些方法。使用这些SQL语句时，会对系统表产生分组操作，当然也增大了系统的负载。建议大家在系统启动了一段时间后，在半夜负载较轻的时间定时(例如:一个月)来查一查。一定要具体问题具体分析。

下面是我收藏的一些查找bad sql的方法:

    column sql_text format a80;
    select
    substr(to_char(s.pct, '99.00'), 2) || '%' load,
    s.executions executes,
    p.sql_text
    from
    (
    select
    address,
    disk_reads,
    executions,
    pct,
    rank() over (order by disk_reads desc) ranking
    from
    (
    select
    address,
    disk_reads,
    executions,
    100 * ratio_to_report(disk_reads) over () pct
    from
    sys.v_$sql
    where
    command_type != 47
    )
    where
    disk_reads > 50 * executions
    ) s,
    sys.v_$sqltext p
    where
    s.ranking <= 5 and
    p.address = s.address
    order by
    1, s.address, p.piece
    /

-- 逻辑读多的SQL

    select * from (select buffer_gets, sql_text
    from v$sqlarea
    where buffer_gets > 500000
    order by buffer_gets desc) where rownum<=30;

-- 执行次数多的SQL

    select sql_text,executions from
    (select sql_text,executions from v$sqlarea order by executions desc)
    where rownum<81;

-- 读硬盘多的SQL

    select sql_text,disk_reads from
    (select sql_text,disk_reads from v$sqlarea order by disk_reads desc)
    where rownum<21;

-- 排序多的SQL

    select sql_text,sorts from
    (select sql_text,sorts from v$sqlarea order by sorts desc)
    where rownum<21;

--分析的次数太多，执行的次数太少，要用绑变量的方法来写sql

    set pagesize 600;
    set linesize 120;
    select substr(sql_text,1,80) "sql", count(*), sum(executions) "totexecs"
    from v$sqlarea
    where executions < 5
    group by substr(sql_text,1,80)
    having count(*) > 30
    order by 2;

-- 游标的观察

    set pages 300;
    select sum(a.value), b.name
    from v$sesstat a, v$statname b
    where a.statistic# = b.statistic#
    and b.name = 'opened cursors current'
    group by b.name;
    select count(0) from v$open_cursor;
    select user_name,sql_text,count(0) from v$open_cursor
    group by user_name,sql_text having count(0)>30;

--查看当前用户&username执行的SQL

    select sql_text from v$sqltext_with_newlines where (hash_value,address) in
    (select sql_hash_value,sql_address from v$session where username='&username')
    order by address,piece;

所谓职业生涯，是一个人一生的工作经历，特别是职业、职位及工作理想实现的过程。规划和管理职业生涯，就是要根据自身的实际情况设计和实现个人合理的职业生涯计划。按规划的时间长短分长期、中期、短期规划，长期规划一般是5-10年的规划，主要设定较长远的目标，比如规划30岁成为一家中型企业的CIO或者经理等;中期规划一般是3-5年，比如规划到不同部门去担任部门经理等；短期规划是3年以内的规划,主要确定近期目标，规划近期完成的任务,如对专业知识和技能的提高等,职业规划对个人的前途和职业生涯具有重要的作用。

规划与管理职业生涯的作用主要表现在以下几个方面：

1.以既有的成就为基础，确立人生的方向，找到奋斗的目标。

2.突破并充实自我。

3.准确定位职业方向。

4.重新认识自己的价值并使其增值。

5.发现新的职业机遇。

6.增强职业竞争力。

个人职业生涯规划必须要跟理想和现实想结合，在“衡外情，量己力”的情形下，设计出合理且可行的职业发展方向，只有把自身因素和社会条件做最大程度的契合，才能在现实生活中趋利避害，使得自己的价值得到更好的体现。

首先要对自己进行分析与诊断，自我分析从以下几个方面着手：

1.个人部分

健康状况：身体是否有病痛？是否有不良习惯？是否有影响健康的活动？生活是否正常？有没有养生之道？

自我充实：是否有专长？经常阅读和收集资料吗？是否正在培养其他技能？是否有时时充电？

休闲管理：是否有固定的休闲活动？有利于身心和工作吗？是否有休闲计划？

2.事业部分

财富所得：薪资多少？有储蓄吗？有动产、有价证券吗？有不动产吗？价值多少？有外快吗？

社会阶层：现在的职位是什么？还有升迁的机会吗？是否有升迁的准备？在公司内外的人际关系怎样？

自我实现：喜欢现在的工作和职业吗？理由是什么？有完成人生理想的准备吗？有确定人生理想的目标吗？

3.家庭部分

生活品质：居家环境怎样？有没有计划换房子？家庭的布置和设备怎样？有心灵和精神文化的生活吗？小孩、夫妻、父母有学习计划吗？

家庭关系：夫妻关系和谐吗？是否拥有共同的奋斗目标和发展计划？是否有个人的创业计划？父母、子女与家人的关系如何？是否常与家人相处、沟通、活动、旅游？

家人健康：家里有小孩吗？小孩多大？健康吗？需要托人照顾吗？配偶的健康如何？家里有老人吗？有需要照顾你的家人吗？

其次，对外界的环境进行分析，主要从如下几方面着手：

1.友伴关系：朋友要多样化、多量化，且有能力。

2.行业条件：注意社会当前及未来需要的行业。

3.企业条件：企业需要什么样的人才。

4.地区条件：根据企业与行业条件来定。

5.社会条件：主要社会潜在的市场条件

最后，从关键成功因素分析：

1.人脉：家庭关系、婚姻关系、同事（同学）关系、社会关系，对此要与他们进行沟通和自我推销。

2.金脉：工资状况、财产、储蓄，要善于理财，夫妻合作，努力提高自己的能力条件与职位。

3.知脉：做好时间管理，安排学习计划，上课、听讲座、进修，反复联系，掌握专业技能，提高自身水平与能力。

原文作者：John Weeg

当一个用户坐在的终端前的提交了一个查询却等不出结果,这很是让人恢心的。他们很希望语句运行正常,但他们却不知道实际上是怎么样的。因些让我们找出一个办法来消除他们的担心。

你是谁？

第一个问题当然指的是我们正在提及的是哪个会话？用户可以在做其它事情前用如下的语句得它：

Select sid from v$mystat where rownum=1;

实际上，直到你提交的语句运行很正常时这个问题才不会被提出，如果用户有一个唯一的用户名,那么你可以用如下语句得到那个SID,比如查用户JOHN的SID.

select sid,machine,osuser,module from v$session where username='JOHN';

SID MACHINE OSUSER MODULE
----- -------------------- ------------------------------ ----------
150 MSHOMEJOHN-LAPTOP John?Weeg SQL*Plus

我用其它的一些信息校验这恰恰是我的会话

糟糕一点的是共享用户名被使用的状况，因些我们将需要看一下哪些会话正在运行：

break on sid skip 1
column sid format 99999
column sql_text form a64

select a.sid, a.last_call_et ,b.sql_text
from v$session a
,v$sqltext b
where a.username is not null
and a.status = 'ACTIVE'
and a.sql_address = b.address
order by a.last_call_et,a.sid,b.piece;

这给出了我们正在目前正在运行的语句和多长时间，你应该就能能够看出哪一个会话你需要检查一下。

因些，接着应做什么？

我们知道通常在语句执行这段时间伴随着等待,正在执行CPU操作，或正在执行IO操作。通过v$sessstat,v$sessio,v$session_wait这三张表我们可以得到我们想知道的一些信息，可以通过SID去单查我们观注的一个表，但我发现很被容易把这些信息结合在一起。

Column event format a30
Column sid format 9999
Column session_cpu heading "CPUused"
Column physical_reads heading "physicalreads"
Column consistent_gets heading "logicalreads"
Column seconds_in_wait heading "secondswaiting"

select a.sid, a.value session_cpu, c.physical_reads,
c.consistent_gets,d.event,d.seconds_in_wait
from v$sesstat a,v$statname b, v$sess_io c, v$session_wait d
where a.sid=150
and b.name = 'CPU used by this session'
and a.statistic# = b.statistic#
and a.sid=c.sid
and a.sid=d.sid;

我执行这个语句几次，因为我们需要找出哪些项在变化。

CPU physical logical seconds
SID used reads reads EVENT waiting
--- ----- --------- -------- ------------------------------ ----------
150 1159 0 117476 SQL*Net message from client 5

/

CPU physical logical seconds
SID used reads reads EVENT waiting
--- ----- --------- -------- ------------------------------ ----------
150 1970 0 204484 SQL*Net message from client 4

因些我们可以看到这个会话在我们检查时正在等待客户端的信息。在我们两次检查的期间它执行了逻辑读的操作并消耗了CPU资源，这说明会话运行是正常的。

什么情况下我们需要进一步检查?

通常有这么几个事件(event)标识潜在存在问题:'buffer busy waits','db file sequential read','db file scattered read','free buffer waits','latch free',对于前4上事件，我们可以找出相关的是哪个对象，如下语句：

select owner,segment_name,segment_type
from (select p1 file#, p2 block# from v$session_wait
where sid = 150
and event in ('buffer busy waits'
,'db file sequential read'
,'db file scattered read'
,'free buffer waits')) b
,dba_extents a
where a.file_id = b.file#
and b.block# between a.block_id and (a.block_id+blocks-1);

这里我们能够发现IO等待是由于大量的数据访问引起的，还是由有些东西不对比如索引丢失引起的，我们也可以去掉SID子句那行找出那些正在经历等待的对象。

对于最后一个潜在的问题我们可以查正在等待什么栓(latch):

select name
from (select p2 latch# from v$session_wait
where sid = 150
and event in ('latch free')) b
,v$latchname a
where a.latch# = b.latch#;

我们可以看到是不是会话经历栓的冲突，这个冲突是不是经常发生的

使你的用户轻松下来

因此,你现在要可以告诉那些不安的用户他们执行的语句在等待一些其它的资源。我最终的做法是帮助他们优化那些语句，以使语句不至于执行得太慢使用户不安。

并不是所有的项目经理都是生来平等的。本文讲的就是优秀的项目经理和非常优秀的项目经理之间的区别。

　　有三种类型的项目经理。第一种类型是"意外型"的项目经理。通常，这种类型的项目经理都是通过排资论辈升上来的。例如，一个能力很强的程序员通过一个开发项目成为项目经理。或者一个能力出众的网络技术员通过一次大型的网络升级成为项目经理。这些人都了解他们正在管理的项目的类型，他们能够制定工作计划，也能够给其他的小组成员分配工作。但是，他们并不了解项目管理的很多准则。

　　第二种类型的项目经理知道成功的项目管理需要你来应付问题、范围、沟通、风险等内容。问题是你是否是一个足够厉害的项目经理，是否能够理解项目管理的准则需要具有积极主动性。

　　第三种类型是积极主动的项目经理，他已经完成了意识上的转换，提前或者持续应用他或者她的准则。通过下面的例子我们可以看到它是如何起作用的。

　　一个优秀的项目经理……

　　* 会完成最初的项目定义（Project Definition），即章程，因为这是组织的要求。一个积极主动的项目经理知道必须提前定义项目，否则，小组就不会对必须完成的工作有一个清晰的认识。

　　* 会为赞助方和经理提供一个月度状态报告。积极主动的项目经理会完成同样的状态报告，但是知道状态报告只是沟通所需要的最低要求。积极主动的项目经理会在整体沟通计划（Communication Plan）的指导下管理好沟通。这就让项目经理可以预先确定和满足项目利益相关人的各种沟通需要。

　　* 会在项目一开始就看到存在的风险。而积极主动的项目经理会在项目的开始预见到项目的风险，并在项目实施过程中管理和监测这些风险。

　　* 会判断如何解决他们所碰到的问题。而积极主动的项目经理会有一个问题管理流程，以便在问题发生的时候来预先处理所有的重要问题。

　　* 会因为自尊心的缘故而创建一个质量解决方案，并知道这是要做的正确事情。而一个积极主动的项目经理会确定客户对质量的预期，并制订计划来达到所要求的质量水平。

　　你看到了不同之处吗？那些仅仅是"优秀的"项目经理知道项目经理最基本的职责。而那些非常优秀的、积极主动的项目经理已经将这些项目经理的职责内质化了，并让它们成为了项目工作里的日常部分。积极主动的项目经理不会因为需要做这些日常工作而去做这些工作。他们行使自己的职责是因为他们知道这些项目管理的流程让他们获得了更高的成功率。

大多数软件开发人员本能地认为，项目经理所要确保的项目按时完工与实现高质量的软件是矛盾的。这并不是因为项目经理们不想要高质量的软件，他们只是想在质量的基础之上，能够按时完工和低于或等于预算的情况下，实现这个软件。他们的努力可以成功地在降低成本和开发时间的同时不会对质量造成影响，然而，他们有可能过度地使用了这些技巧。

尽管以下的这些项目管理技巧至少是很有意义的，在某些情况下，它们甚至是受到尊敬的技巧，但是它们都有造成灾难的潜在可能。

时间盒（Time boxing）
在破坏软件质量的事件列表上，时间盒的应用排在第一位，当您告诉某人在任务必须移交之前，他拥有多长时间来完成这项工作，我说“移交”而不是“完成”，因为在极端情况下，这经常意味着代码并不完善，仅仅是抓紧时间去完成这项工作。

在大多数情况下，时间盒是有效的，因为它可以做到四件事：

1. 它迫使开发者能够富有创造性地在他们的预算之内发现解决方案。
2. 它排除了经常添加在软件中不必要的虚饰，而这些虚饰往往并不能增加软件的价值。
3. 它防止开发者过度测试。
4. 目的只是要得到这件产品，在完整的质量评价（QA）阶段将会有详细的测试，希望在此阶段中能够发现代码中存在的问题。

当存在未知问题，或技术没有经受检验，或没有正确的方法来检验结果的时候，时间盒就无能为力了；当时间盒很小，而且在分配的时间之内并没有可能的办法来实现目标时，这种方法也是无效的。换句话说，时间盒可以很好地解决一些问题，比如充分理解、谨慎评估和执行类的任务；然而，也确实存在时间盒方法不能很好解决的问题，比如研究和发展，还有解决问题等等。

如果时间盒是正确使用的，那么不应当导致测试到很糟糕的代码，这些糟糕的代码可能会导致数百个小时的诊断和返工。时间盒应当适度使用来确保最低的成本、最快和最高质量的软件。

误期
所有人都要有奋斗的目标，里程碑是一种受到尊敬的方法，它用来激发人们向同一个目标前进，这种动力可以在很短的时间内得到重大成果。然而，每个人都必须承认里程碑所界定的时间并不是每次都能实现，这时就必须要做出新的决定。

项目经理们必须要在团队中树立里程碑的目标，以此来激励他们前进，但是，当里程碑确立的日期并不现实，而且队员们一再出错，那就应该重新评估这个计划了。如果因为某种特殊情况可以使这个日期不再重要，那么当这个重要日期真正来临的时候，整个团队就只有很小的动力来实现这个里程碑日期。当整个团队连续错过了10个日期，那么第11个日期还重要么？这就像喊着“狼来了”的孩子一样。

如果在设定的时间线之后并没有任何处罚，那么当错过这个时间的时候就应该强制执行或者移动整个时间线。

长远来看，不断创造持续的压力和令人迷惑的环境并不能创造出好的软件，开发人员需要能够专心工作的环境。完成项目的日期和关于里程碑日期是否真实的混乱，经常会导致开发人员在开发过程中跳过关键步骤或者造成难以发现的问题。

假装没有错误 在项目管理中，忽视并不是一种幸福。为了成功地完成项目，除了不可阻挡的政治压力，向公司其他的员工介绍项目的风险也是必需的。几乎每个软件开发项目都有延期或超出预算或同时出现这两种情况的风险。

问题在于，当最终某一时间，这些风险真正变为现实的时候将会引起恐慌，每个人都在混乱中将项目其余的部分组装在一起，整个项目的质量将因为最终轻率的装配而遭受损失。

当然，当整个项目还没有落后于计划之前，这一问题还不会充分暴露出来，然而，大多数项目都有办法只让项目的某些部分落后一点点，而几乎每个项目都有过于仓促的风险，这是因为管理层在很长一段时间之内都在项目没有任何问题之后得知项目的真实状态。

忽视相关性
在软件开发中，我们有很多技巧可以用来延迟相关性，我们可以停用一些函数、移动相连的基本架构，或者绕开众多的错误处理，在正确使用的情况下，所有这些技巧都可以帮助推进一个项目，然而，当为了完成项目，而这些技巧的成本因素又没有被考虑到整个计划当中时，就埋下了烦恼的种子。

很多时候，在项目中排列软件开发的顺序是非常具有挑战的事情，相关性并不容易被发现，因此也就不可避免地有很多相关性因素没有被安排到计划当中。为这些不可预见的相关性安排日程表可以让人变得疯狂，因此，压制相关性的方法是经常使用的，但是，如果过度使用了这些技巧，这些费用可能经常会占据项目总成本中很重要的一部分，而且直到项目的最后才会被发现。

所以要确信您现在所做的对于管理相关性是必需的，不会添加过多的成本，而且是整个软件开发项目中必不可少的一部分。当项目经理不能在成本与降低相关性的便利中取得平衡，那么他们草率地组装的代码将会展示出质量问题。