通过vmstat的简单分析数据库操作

　　首先看看全表扫描的情况。
　　我们对于一个170万数据的表进行查询。可以看到
　　从设备收到的块数是急剧增加，效果跟文件的拷贝有些类似，但是buffer，cache基本没有变化。我想这也是数据库级别的操作和系统级别的根本区别吧。数据库的buffer_cache应该是起这个作用的。
SQL> select count(*)from test where object_id<>1;
COUNT(*)
----------
1732096
[ora11g@rac1 arch]$ vmstat 3
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r  b     swpd   free   buff       cache   si   so    bi    bo   in   cs us sy id wa st
1  0      0 166520 399680 1023292    0    0    17    20    6    5  1  1 98  1  0
0  0      0 175800 399680 1023292    0    0    53    11  680 1308  0  0 100  0  0
1  0      0 175800 399680 1023292    0    0 18021    24 1451 1826  2  7 66 25  0
0  0      0 175800 399680 1023292    0    0    53    53  812 1577  0  0 98  2  0
0  0      0 166256 399680 1023292    0    0     0    16  881 1614  1  1 98  0  0
1  0      0 175908 399680 1023292    0    0    21    11  866 1605  0  0 99  0  0
　　接着来做一个更为消耗资源的操作，这个sql不建议在正式环境测试，因为很耗费资源
　　对一个170多万的表进行低效的连接。vmstat的情况如下。运行了较长的时间，过了好一段时间都没有结束，可以看到cpu的使用率已经达到了40~50%，在开始的时候，从设备中得到的块数急剧增加，然后基本趋于一个平均值，buffer，cache基本没有变化。
SQL> select count(*)from test t1，test t2 where t1.object_id=t2.object_id;
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0  0      0 176024 399688 1023292    0    0    43    11  655 1284  0  0 99  1  0
1  0      0 171420 399688 1023292    0    0     0    16  671 1302  1  1 98  0  0
0  0      0 176164 399688 1023292    0    0     0    11  735 1331  0  1 99  0  0
0  0      0 176164 399688 1023292    0    0    21    25  678 1291  0  0 99  0  0
1  0      0 173452 399688 1023292    0    0 15643  5256 1835 2178  6 12 76  6  0
2  0      0 163048 399688 1023292    0    0 15179  5748 2166 2271  7 12 67 14  0
1  0      0 172072 399688 1023292    0    0  5541  2432 2226 1860 32  6 59  3  0
1  0      0 169964 399688 1023292    0    0   656    24 2322 1656 46  1 50  4  0
1  0      0 169848 399688 1023292    0    0   485    11 2335 1637 48  1 50  2  0
1  0      0 159576 399692 1023288    0    0   448   115 2442 1738 49  1 48  2  0
1  0      0 169344 399692 1023292    0    0   712    11 2351 1701 47  1 50  3  0
1  0      0 169352 399696 1023288    0    0   619    24 2332 1649 48  1 49  2  0
1  0      0 169360 399696 1023292    0    0   467    11 2339 1623 47  1 50  2  0
1  0      0 159848 399700 1023288    0    0   693    16 2318 1673 48  1 48  3  0
1  0      0 169368 399700 1023292    0    0   467    11 2309 1660 47  1 50  3  0
2  0      0 169368 399700 1023292    0    0   467    28 2329 1624 48  1 50  2  0
　　来看看并行的效果。后返回的条数有近亿条，这也是这个连接低效的原因所在，但是在vmstat得到的信息来看和普通的数据查询还是有很大的差别。
　　首先是急剧消耗io，同时从内存中也取出了一块内存空间。然后io基本趋于稳定，开始急剧消耗cpu资源。可以看到cpu的使用率达到了90%以上。
SQL> select count(*)from test t1，test t2 where t1.object_id=t2.object_id;
COUNT(*)
----------
221708288
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0  0      0 175048 399748 1023292    0    0     0    20  665 1274  0  0 100  0  0
0  0      0 175048 399748 1023292    0    0    21    11  657 1286  0  0 100  0  0
0  0      0 165644 399748 1023292    0    0     0    16  715 1310  1  1 98  0  0
0  0      0 175056 399748 1023292    0    0     0    11  664 1284  0  0 99  0  0
0  0      0 175056 399748 1023292    0    0    21    24  640 1289  0  0 99  0  0
0  4      0 142364 399748 1025408    0    0  5957   988 1407 1869 10  8 64 18  0
0  0      0 132092 399748 1025444    0    0 12520  4939 1903 2556 14 11 32 43  0
0  2      0 140248 399748 1025444    0    0 10477  3973 1728 2427 11  7 29 53  0
2  0      0 136776 399748 1025444    0    0  7987  4125 1536 2248 11  6 24 60  0
2  0      0 136776 399748 1025444    0    0   971    20 2427 1663 98  1  0  1  0
2  0      0 121404 399748 1025456    0    0  1160    11 2422 1730 96  3  0  1  0
2  0      0 134528 399748 1025460    0    0  1195    17 2399 1695 97  2  0  2  0
3  0      0 134520 399748 1025460    0    0  1325    19 2443 1693 96  1  0  3  0
2  0      0 134536 399748 1025460    0    0  1176    16 2405 1674 99  1  0  0  0
2  0      0 125108 399748 1025460    0    0  1139    11 2418 1647 97  2  0  1  0
2  0      0 134628 399752 1025460    0    0  1235    16 2391 1653 98  1  0  1  0
3  0      0 134644 399752 1025460    0    0  1197    21 2392 1640 97  2  0  1  0
2  0      0 134652 399756 1025460    0    0  1400    16 2433 1670 97  1  0  3  0
2  0      0 125116 399756 1025460    0    0  1008    11 2199 1564 97  2  0  1  0
　　看来并行的实现还是有很多的细节，相比普通的查询来说更加复杂，而且消耗的资源更多，这个也是在使用并行的时候需要权衡的一个原因。