下达到我们身上。到现场后，首先了解应用系统的大致情况。此应用是夜间抽取数据，分析形成报表，白天大部分是查询，有部分业务是接收上传包，解析后入库。因此来看，这个系统也是个混合型。

其次，实际观察系统的运行状况，情况确实不太好，仅一个WEB系统上的用户登录，就需要大约2分钟，进去以后的查询更是目不忍睹。习惯性地配置服务链接数据库，打开PL/SQL登录，又是等了好久才进去！进去以后，随便查了几个表，响应速度还行。看看还没有安装perfstat；尝试TELNET，等了半天才进去，ls一下没反应，topas还没出结果，连接中断了。

找小机的管理员，了解其上的应用，才知道除了这个系统的数据库和JAVA应用之外，另外还有一个数据库。系统管理员重启了AIX。TELNET可以登录进去了。

开始收集AIX的一些信息。

系统内存8G，我们的三个JAVA应用计用内存3G，我们的数据库用了1.8G ，NND另外一个刚安装的综合办公模拟库用了3.6内存

vmstat的部分信息如下：

$ r

vmstat 2 30

System configuration: lcpu=4 mem=8192MB

kthr memory page faults cpu

----- ----------- ------------------------ ------------ -----------

r b avm fre re pi po fr sr cy in sy cs us sy id wa

1 0 1280279 2968 0 9 3 64 76 0 70 426 272 46 1 52 2

0 0 1280292 2953 0 1 0 0 0 0 33 172 189 18 0 82 0

2 0 1280372 2954 0 24 1 65 69 0 57 931 482 1 0 96 2

0 0 1280254 3292 0 23 2 133 229 0 71 621 283 3 1 93 3

0 1 1280363 3004 0 25 0 0 0 0 81 498 295 2 1 87 10

2 1 1280363 2914 0 20 29 1233 1793 0 527 1312 1159 9 3 63 26

0 1 1280363 2974 0 9 20 1623 2397 0 555 847 1106 2 3 71 24

1 1 1280432 2892 0 40 75 2465 3876 0 815 1467 1455 3 4 70 23

0 1 1280432 2885 0 38 85 1624 17225 0 583 998 1159 3 3 70 24

0 1 1280496 2968 0 1 93 905 8175 0 434 674 951 4 2 71 23

1 1 1280496 2900 0 0 23 650 4663 0 369 559 857 3 2 72 24

0 1 1280496 2944 0 0 17 520 2069 0 280 384 676 3 1 72 24

0 1 1280560 2932 0 1 91 1041 4185 0 499 655 1057 3 2 71 24

1 1 1280560 2953 0 0 148 2145 10274 0 735 1556 1272 5 4 69 22

0 1 1280623 2962 0 1 161 2467 18023 0 857 1357 1445 3 5 69 23

0 1 1280624 2908 0 2 383 1303 4597 0 891 1136 1328 6 3 69 22

1 1 1280624 2976 0 2 215 391 1977 0 272 2429 524 31 2 58 9

kthr memory page faults cpu

----- ----------- ------------------------ ------------ -----------

r b avm fre re pi po fr sr cy in sy cs us sy id wa

0 1 1276622 3108 0 80 3 712 1395 0 381 312 1140 9 2 60 29

1 110 1276650 2888 0 287 0 972 1602 0 1174 365 3804 15 4 52 29

1 1 1276733 2908 0 0 0 455 751 0 233 347 594 17 1 65 17

1 1 1276768 2956 0 0 0 521 662 0 269 437 667 24 1 61 13

2 1 1276832 2937 0 42 0 64 67 0 71 345 275 41 1 54 5

2 0 1276847 2902 0 9 0 0 0 0 39 273 208 34 0 65 1

0 0 1276847 2902 0 0 0 0 0 0 30 29 201 0 0 99 0

1 0 1276911 2923 0 22 1 65 69 0 56 334 238 1 0 97 2

0 1 1277055 3060 0 117 1 258 654 0 159 1116 690 4 1 82 13

0 0 1276831 3183 0 51 0 0 0 0 121 366 384 1 2 91 6

再看看topas，发现几个oracle进程占用CPU较高，也不是一直占用居高不下；另外JAVA进程虽然CPU占用不高，但换页不少；找进程代码去数据库查查看在运行什么SQL语句。

找了几个SQL语句，查看后，加索引进行调整（此类应用系统的特点是不能更改应用的SQL语句），再次在模块中测试，有改善，但不明显。

安装perfstat ，隔20分钟后，打个报告看看，部分内容如下：

Snap Id Snap Time Sessions Curs/Sess Comment

--------- ------------------ -------- --------- -------------------

Begin Snap: 1 28-Oct-08 17:50:09 42 18.0

End Snap: 2 28-Oct-08 18:11:05 43 17.8

Elapsed: 20.93 (mins)

Cache Sizes (end)

~~~~~~~~~~~~~~~~~

Buffer Cache: 512M Std Block Size: 8K

Shared Pool Size: 512M Log Buffer: 512K

Load Profile

~~~~~~~~~~~~ Per Second Per Transaction

--------------- ---------------

Redo size: 1,153.53 724,418.00

Logical reads: 10,035.20 6,302,104.50

Block changes: 2.06 1,295.00

Physical reads: 95.16 59,760.00

Physical writes: 7.55 4,741.50

User calls: 3.92 2,461.00

Parses: 0.91 571.00

Hard parses: 0.12 75.00

Sorts: 0.52 329.00

Logons: 0.00 1.00

Executes: 1.43 898.50

Transactions: 0.00

% Blocks changed per Read: 0.02 Recursive Call %: 56.77

Rollback per transaction %: 0.00 Rows per Sort: 6843.77

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Buffer Nowait %: 100.00 Redo NoWait %: 100.00

Buffer Hit %: 99.11 In-memory Sort %: 99.70

Library Hit %: 93.52 Soft Parse %: 86.87

Execute to Parse %: 36.45 Latch Hit %: 100.00

Parse CPU to Parse Elapsd %: 12.90 % Non-Parse CPU: 99.57

Shared Pool Statistics Begin End

------ ------

Memory Usage %: 90.02 89.94

% SQL with executions>1: 4.01 4.48

% Memory for SQL w/exec>1: 4.11 4.90

Top 5 Timed Events

~~~~~~~~~~~~~~~~~~ % Total

Event Waits Time (s) Ela Time

-------------------------------------------- ------------ ----------- --------

CPU time 103 50.63

db file sequential read 98,390 94 46.40

latch free 180 3 1.61

db file scattered read 1,608 2 .95

control file parallel write 418 0 .18

接着看了一些后面的SQL语句，因为程序是由经验丰富的程序员做的开发，所以也没有找出明显的不妥之处。db file sequential read读较大Logical reads也较大。为什么呢？（分析往往是走马观花）当时机器上没有安装Spotlight，上网当了一个，安装配置，连接上就报了很多警告，最多的是如下的告警：

真高呀！意识到可能是row chain问题。找几个主要的业务表做个抽样分析，然后再查，发现问题很严重。部分表的统计如下：

教程上说1%就比较严重,现在窜到67了，不让人活了！

和主管技术人员进行了沟通，等到晚上找两表先做了再看效果。

出去吃个饭休息休息。

天黑了，夜深了，开始行动，停应用，将表做好备份，修改存储参数pctfree改为50，（被主管技术人员建议降低为40），再恢复数据。

再次进行分析，好了，chains_cnt消失为0;

进入应用，查询，速度飞快。可是问题并没有就此结束。

次日再次进行查询，部分地市的数据查询速度快，部分地市的数据查询仍然很慢？Y ？

难道链接行又出现了，分析查询，果然， 一个表的链接率又升至1.3 !

找出早上8点之前运行过的与此表相关的SQL语句，发现有以下特征：

先删除本月数据

再插入本月数据的前几列

再更新本表的后几列

而后几列的数据长度占行长的70%

看来预留的40不够用。怎么办？

再来一次，折腾，这几年一直在折腾数据，不是导入导出，就是改来改去。人生就是如此，痛并快乐着，一入O门深似海。搞完后再来查询，恢复正常。

其它的随后再说吧，先解决主要矛盾。

-- 纯属娱乐，如有不妥之处，请阅者多指教。