博客园_小光的自由天空

单条SQL语句实现复杂逻辑几例(转)

2011-09-21T08:48:00Z

1、按指定规则生成指定商品2002年销售额，其中彩电项值为2001年的销售额加2000年的销售额，微波炉为2000年销售额, 然后汇总彩电+微波炉的2002年总销售额。

表数据如下：
CITY  PRODUCT YEAR  SALES
------  -------------- --------  ---------
北京彩电 1999 3000
北京彩电 2000 2500
北京彩电 2001 4500
北京微波炉 1999 800
北京微波炉 2000 7000
北京微波炉 2001 333
北京冰箱 1999 2323
北京冰箱 2000 1212
北京冰箱 2001 7676
天津彩电 1999 212121
天津彩电 2000 434343
天津彩电 2001 564566
天津微波炉 1999 23432
天津微波炉 2000 232
天津微波炉 2001 34234
天津冰箱 1999 324324
天津冰箱 2000 8987686
天津冰箱 2001 768678

要求用SQL实现如下效果：
CITY  PRODUCT YEAR  SALES
------  -------------- --------  ---------
天津微波炉 1999 23432
天津微波炉 2000 232
天津微波炉 2001 34234
天津微波炉 2002 232
天津冰箱 1999 324324
天津冰箱 2000 8987686
天津冰箱 2001 768678
天津彩电 1999 212121
天津彩电 2000 434343
天津彩电 2001 564566
天津彩电 2002 998909
天津彩电+微波炉 2002 999141
北京微波炉 1999 800
北京微波炉 2000 7000
北京微波炉 2001 333
北京微波炉 2002 7000
北京冰箱 1999 2323
北京冰箱 2000 1212
北京冰箱 2001 7676
北京彩电 1999 3000
北京彩电 2000 2500
北京彩电 2001 4500
北京彩电 2002 7000
北京彩电+微波炉 2002 14000

建表语句如下：
create table tmp1(CITY varchar2(20), PRODUCT varchar2(20), YEAR number,  SALES number);
insert into tmp1 values ('北京','彩电', 1999, 3000);
insert into tmp1 values ('北京','彩电', 2000, 2500);
insert into tmp1 values ('北京','彩电', 2001, 4500);
insert into tmp1 values ('北京','微波炉', 1999, 800);
insert into tmp1 values ('北京','微波炉', 2000, 7000);
insert into tmp1 values ('北京','微波炉', 2001, 333);
insert into tmp1 values ('北京','冰箱', 1999, 2323);
insert into tmp1 values ('北京','冰箱', 2000, 1212);
insert into tmp1 values ('北京','冰箱', 2001, 7676);
insert into tmp1 values ('天津','彩电', 1999, 212121);
insert into tmp1 values ('天津','彩电', 2000, 434343);
insert into tmp1 values ('天津','彩电', 2001, 564566);
insert into tmp1 values ('天津','微波炉', 1999, 23432);
insert into tmp1 values ('天津','微波炉', 2000, 232);
insert into tmp1 values ('天津','微波炉', 2001, 34234);
insert into tmp1 values ('天津','冰箱', 1999, 324324);
insert into tmp1 values ('天津','冰箱', 2000, 8987686);
insert into tmp1 values ('天津','冰箱', 2001, 768678);

解题思路：
本题初看起来一般都会下意识选择通过group by rollup子句生成，但如果你选择直接通过group by rollup的方式：
[php]
JSSWEB> select city, product, year, sum(sales)
   2 from tmp1
   3 group by city, rollup(product, year)
   4  ;

CITY                PRODUCT                   YEAR SUM(SALES)
-------------------- -------------------- ---------- ----------
北京                冰箱                      2000    1212
北京                冰箱                      1999    2323
北京                冰箱                      2001    7676
北京                冰箱                               11211
北京                彩电                      2000    2500
北京                彩电                      1999    3000
北京                彩电                      2001    4500
北京                彩电                               10000
北京                微波炉                   2000    7000
北京                微波炉                   1999       800
北京                微波炉                   2001       333
北京                微波炉                               8133
北京                                                    29344
天津                冰箱                      2000 8987686
天津                冰箱                      1999    324324
天津                冰箱                      2001    768678
天津                冰箱                            10080688
天津                彩电                      2000    434343
天津                彩电                      1999    212121
天津                彩电                      2001    564566
天津                彩电                            1211030
天津                微波炉                   2000       232
天津                微波炉                   1999    23432
天津                微波炉                   2001    34234
天津                微波炉                            57898
天津                                                 11349616

26 rows selected
--
[/php]
这跟预想的结果有不小差距。

这是因为要求的数据是涉及逻辑运算的，比如某些数据需要2001年相加，某些数据由2000+2001汇总，因此我们在group by之前需要先按照条件对sales做些处理，彩电要取2000年和2001年的，而微波炉要取2000年的。

[php]
JSSWEB> select city,
   2       product,
   3       year,
   4       sales,
   5       decode(product,
   6             '彩电',
   7             decode(year, 2000, sales, 2001, sales, 0),
   8             '微波炉',
   9             decode(year, 2000, sales, 0)) ns
10 from tmp1;

CITY                PRODUCT                   YEAR    SALES       NS
-------------------- -------------------- ---------- ---------- ----------
北京                彩电                      1999    3000       0
北京                彩电                      2000    2500    2500
北京                彩电                      2001    4500    4500
北京                微波炉                   1999       800       0
北京                微波炉                   2000    7000    7000
北京                微波炉                   2001       333       0
北京                冰箱                      1999    2323
北京                冰箱                      2000    1212
北京                冰箱                      2001    7676
天津                彩电                      1999    212121       0
天津                彩电                      2000    434343    434343
天津                彩电                      2001    564566    564566
天津                微波炉                   1999    23432       0
天津                微波炉                   2000       232       232
天津                微波炉                   2001    34234       0
天津                冰箱                      1999    324324
天津                冰箱                      2000 8987686
天津                冰箱                      2001    768678

18 rows selected
--
[/php]

然后在做sum的时候，我们只需要判断一下，比如产品为彩电或微波炉的话，sum(ns)，否则sum(sales)，最后按照城市产品和年份排下序即可：
[php]
JSSWEB> select city,
   2       nvl(product, '彩电+微波炉') product,
   3       nvl(year, 2002) year,
   4       decode(product,
   5             '彩电',
   6             nvl2(year, sum(sales), sum(ns)),
   7             '微波炉',
   8             nvl2(year, sum(sales), sum(ns)),
   9             null,
10             sum(ns),
11             sum(sales)) sales
12 from (select city,
13                product,
14                year,
15                sales,
16                decode(product,
17                      '彩电',
18                      decode(year, 2000, sales, 2001, sales, 0),
19                      '微波炉',
20                      decode(year, 2000, sales, 0)) ns
21          from tmp1) a
22 group by city, rollup(product, year)
23  having sum(ns) is not null or year is not null
24 order by 1, 2, 3;

CITY                PRODUCT                   YEAR    SALES
-------------------- -------------------- ---------- ----------
北京                冰箱                      1999    2323
北京                冰箱                      2000    1212
北京                冰箱                      2001    7676
北京                彩电                      1999    3000
北京                彩电                      2000    2500
北京                彩电                      2001    4500
北京                彩电                      2002    7000
北京                彩电+微波炉             2002    14000
北京                微波炉                   1999       800
北京                微波炉                   2000    7000
北京                微波炉                   2001       333
北京                微波炉                   2002    7000
天津                冰箱                      1999    324324
天津                冰箱                      2000 8987686
天津                冰箱                      2001    768678
天津                彩电                      1999    212121
天津                彩电                      2000    434343
天津                彩电                      2001    564566
天津                彩电                      2002    998909
天津                彩电+微波炉             2002    999141
天津                微波炉                   1999    23432
天津                微波炉                   2000       232
天津                微波炉                   2001    34234
天津                微波炉                   2002       232

24 rows selected
--
[/php]

上述实现从技术角度看并不太难，所使用的函数、语法也都比较常见，只是由于业务需求涉及了一些逻辑，因此在实现的时候不少代码都用在了逻辑判断上，这样就造成了代码过长，同时也降低了可读性。

下面再介绍一种更简单也更高效的实现方式，借助model和partition，可以直接指定计算规则：
[php]
JSSWEB> select * from TMP1
   2  MODEL
   3  PARTITION BY (city) DIMENSION BY (product, year)
   4  MEASURES (sales sal)
   5  RULES
   6  (sal['彩电', 2002] = sal['彩电', 2001] + sal['彩电', 2000],
   7  sal['微波炉', 2002] = sal['微波炉', 2000],
   8  sal['彩电+微波炉', 2002] = (sal['彩电',2002]+sal['微波炉',2002]))
   9  ORDER BY 1,2,3
10  ;

CITY                PRODUCT                   YEAR       SAL
-------------------- -------------------- ---------- ----------
北京                冰箱                      1999    2323
北京                冰箱                      2000    1212
北京                冰箱                      2001    7676
北京                彩电                      1999    3000
北京                彩电                      2000    2500
北京                彩电                      2001    4500
北京                彩电                      2002    7000
北京                彩电+微波炉             2002    14000
北京                微波炉                   1999       800
北京                微波炉                   2000    7000
北京                微波炉                   2001       333
北京                微波炉                   2002    7000
天津                冰箱                      1999    324324
天津                冰箱                      2000 8987686
天津                冰箱                      2001    768678
天津                彩电                      1999    212121
天津                彩电                      2000    434343
天津                彩电                      2001    564566
天津                彩电                      2002    998909
天津                彩电+微波炉             2002    999141
天津                微波炉                   1999    23432
天津                微波炉                   2000       232
天津                微波炉                   2001    34234
天津                微波炉                   2002       232

24 rows selected

2、查询字段a的值连续三条以上相同的记录

初始表数据如下：
a b c
- - -
1 2 3
1 4 5
1 3 6
2 3 3
1 5 7
2 5 8
1 6 9
1 2 3
1 4 5
1 3 6

要求用SQL实现如下效果：
a b c
- - -
1 2 3
1 4 5
1 3 6
1 6 9
1 2 3
1 4 5
1 3 6

建表语句如下：
create table tmp2 (a number,b number, c number);
insert into tmp2 values (1,2,3);
insert into tmp2 values (1,4,5);
insert into tmp2 values (1,3,6);
insert into tmp2 values (2,3,3);
insert into tmp2 values (1,5,7);
insert into tmp2 values (2,5,8);
insert into tmp2 values (1,6,9);
insert into tmp2 values (1,2,3);
insert into tmp2 values (1,4,5);
insert into tmp2 values (1,3,6);
commit;

解题思路：
这道题看起来非常简单，我们甚至一眼就能看出来哪些记录是连接3条相同的，但千万不要被其简单的表象迷惑了，特别是那些下意识就能得出结论的问题，这往往会让我们的思维陷入到自我的思维误区中，而不再以计算机的执行模式去理解问题，因此这题核心要解决的问题就是将我们的思维方式转换成sql可以理解的记数方式。
先来理一理我们的逻辑，看看能否转换成对应的SQL操作：

首先肯定是拿上一条与下一条做对比，看看是否相同--->lead,lag分析函数可以实现这一点
计算相同数--->count分析函数可以实现，但是这里面有一个问题，分析函数虽然是逐条对比生成结果，但此处我们的依据是是否相同的字段值，假设该字段值为0或1的话，count() over(partition by )就没有了依照，因此我们需要先将比较的结果字段通过sum() over(order by rownum)计算相加，以便生成分区用的字段。
如果计数>3则这些记录符合我们的需求

OK，思路理清了，下面一步步来试试，首先生成比较是否相同的字段：
[php]
JSSWEB> select a.*,
   2       rownum rn,
   3       decode(a, lag(a, 1, a) over(order by rownum), 0, 1) na
   4 from tmp2 a
   5  ;

      A       B       C       RN       NA
---------- ---------- ---------- ---------- ----------
      1       2       3       1       0
      1       4       5       2       0
      1       3       6       3       0
      2       3       3       4       1
      1       5       7       5       1
      2       5       8       6       1
      1       6       9       7       1
      1       2       3       8       0
      1       4       5       9       0
      1       3       6       10       0

10 rows selected
--
[/php]
*rownum列是为了排序用

然后生成用于partition的列
[php]
JSSWEB> select b.*, sum(na) over(order by rn) so
   2 from (select a.*,
   3                rownum rn,
   4                decode(a, lag(a, 1, a) over(order by rownum), 0, 1) na
   5          from tmp2 a) b
   6  ;

      A       B       C       RN       NA       SO
---------- ---------- ---------- ---------- ---------- ----------
      1       2       3       1       0       0
      1       4       5       2       0       0
      1       3       6       3       0       0
      2       3       3       4       1       1
      1       5       7       5       1       2
      2       5       8       6       1       3
      1       6       9       7       1       4
      1       2       3       8       0       4
      1       4       5       9       0       4
      1       3       6       10       0       4

10 rows selected

--
[/php]

这下就清晰多了，剩下的就没难度了，count() over()生成数量，取数量大于2的记录即可：
[php]
JSSWEB> select a,b,c from(
   2  select c.*, count(so) over(partition by so) ct
   3 from (select b.*, sum(na) over(order by rn) so
   4          from (select a.*,
   5                      rownum rn,
   6                      decode(a, lag(a, 1, a) over(order by rownum), 0, 1) na
   7                   from tmp2 a) b) c
   8  )where ct>=3
   9  ;

      A       B       C
---------- ---------- ----------
      1       2       3
      1       4       5
      1       3       6
      1       6       9
      1       2       3
      1       4       5
      1       3       6

7 rows selected

3、查询员工ID：1000的实际工作月数，注意过滤兼职月份

记录集如下：
ID STATION START_DATE END_DATE
------ ----------- ------------------- ----------------
1000 开发 2000-01-01 2000-04-01
1000 测试 2000-07-01 2000-10-01
1000 副经理 2001-01-01 2001-04-01
1000 DBA 2000-02-01 2000-03-01
1000 兼职经理 2000-03-01 2000-08-01
1000 经理 2001-05-01 2001-08-01

该员工的实际工作月份应为：15

建表语句如下：
create table tmp3 (id number,station varchar2(20),start_date date,end_date date);
insert into tmp3 (ID, STATION, START_DATE, END_DATE)
values ('1000', '开发', to_date('01-01-2000', 'dd-mm-yyyy'), to_date('01-04-2000', 'dd-mm-yyyy'));
insert into tmp3 (ID, STATION, START_DATE, END_DATE)
values ('1000', '测试', to_date('01-07-2000', 'dd-mm-yyyy'), to_date('01-10-2000', 'dd-mm-yyyy'));
insert into tmp3 (ID, STATION, START_DATE, END_DATE)
values ('1000', '副经理', to_date('01-01-2001', 'dd-mm-yyyy'), to_date('01-04-2001', 'dd-mm-yyyy'));
insert into tmp3 (ID, STATION, START_DATE, END_DATE)
values ('1000', 'DBA', to_date('01-02-2000', 'dd-mm-yyyy'), to_date('01-03-2000', 'dd-mm-yyyy'));
insert into tmp3 (ID, STATION, START_DATE, END_DATE)
values ('1000', '兼职经理', to_date('01-03-2000', 'dd-mm-yyyy'), to_date('01-08-2000', 'dd-mm-yyyy'));
insert into tmp3 (ID, STATION, START_DATE, END_DATE)
values ('1000', '经理', to_date('01-05-2001', 'dd-mm-yyyy'), to_date('01-08-2001', 'dd-mm-yyyy'));
commit;

解题思路：
这道题核心的问题在于在岗时间可能存在兼职的情况，因此要求实际工作月份的话就不能单纯sum(end_date-start_date)，如果说你一心想着比较各条记录的start_date,end_date，判断是否存在兼职月的话，黑黑，我不是说这样实现不了，只是。。。。太复杂了！！不妨换一种思路，我们只要遍历出它所有工作过的月份，然后count(distinct date)就是实际工作月份了。
要求出所有工作过的月份，就必须首先构造出足够数据的记录出来，这并不困难，熟悉connect by的朋友一定不陌生这种写法：select level from dual connect by rownum<=n;这里我们也借助这种方式来构造指定数据的记录集：
[php]
JSSWEB> select level - 1 lv
   2 from dual
   3  connect by rownum <=
   4          (select max(Months_between(end_date, start_date)) mb from test)
   5  ;

      LV
----------
      0
      1
      2
      3
      4
--
[/php]
*Level为什么要-1呢，因为我们准备用add_months函数来生成日期，起始月数量当然得是0啊

然后与tmp3表做Cartesian，即能够生成比我们希望数量还要多的结果集(多不怕，别少就行啊)：
[php]
JSSWEB> select a.*,
   2       Months_between(end_date, start_date) mb,
   3       b.lv,
   4       add_months(a.start_date, lv) am
   5 from tmp3 a,
   6       (select level - 1 lv
   7          from dual
   8       connect by rownum <= (select max(Months_between(end_date, start_date)) mb
   9                               from test t)) b
10  ;

      ID STATION             START_DATE  END_DATE          MB       LV AM
---------- -------------------- ----------- ----------- ---------- ---------- -----------
   1000 开发                2000-01-01  2000-04-01          3       0 2000-01-01
   1000 测试                2000-07-01  2000-10-01          3       0 2000-07-01
   1000 副经理             2001-01-01  2001-04-01          3       0 2001-01-01
   1000 DBA                2000-02-01  2000-03-01          1       0 2000-02-01
   1000 兼职经理          2000-03-01  2000-08-01          5       0 2000-03-01
   1000 经理                2001-05-01  2001-08-01          3       0 2001-05-01
   1000 开发                2000-01-01  2000-04-01          3       1 2000-02-01
   1000 测试                2000-07-01  2000-10-01          3       1 2000-08-01
   1000 副经理             2001-01-01  2001-04-01          3       1 2001-02-01
   1000 DBA                2000-02-01  2000-03-01          1       1 2000-03-01
   1000 兼职经理          2000-03-01  2000-08-01          5       1 2000-04-01
   1000 经理                2001-05-01  2001-08-01          3       1 2001-06-01
   1000 开发                2000-01-01  2000-04-01          3       2 2000-03-01
   1000 测试                2000-07-01  2000-10-01          3       2 2000-09-01
   1000 副经理             2001-01-01  2001-04-01          3       2 2001-03-01
   1000 DBA                2000-02-01  2000-03-01          1       2 2000-04-01
   1000 兼职经理          2000-03-01  2000-08-01          5       2 2000-05-01
   1000 经理                2001-05-01  2001-08-01          3       2 2001-07-01
   1000 开发                2000-01-01  2000-04-01          3       3 2000-04-01
   1000 测试                2000-07-01  2000-10-01          3       3 2000-10-01
   1000 副经理             2001-01-01  2001-04-01          3       3 2001-04-01
   1000 DBA                2000-02-01  2000-03-01          1       3 2000-05-01
   1000 兼职经理          2000-03-01  2000-08-01          5       3 2000-06-01
   1000 经理                2001-05-01  2001-08-01          3       3 2001-08-01
   1000 开发                2000-01-01  2000-04-01          3       4 2000-05-01
   1000 测试                2000-07-01  2000-10-01          3       4 2000-11-01
   1000 副经理             2001-01-01  2001-04-01          3       4 2001-05-01
   1000 DBA                2000-02-01  2000-03-01          1       4 2000-06-01
   1000 兼职经理          2000-03-01  2000-08-01          5       4 2000-07-01
   1000 经理                2001-05-01  2001-08-01          3       4 2001-09-01

30 rows selected

--
[/php]
剩下的工作就简单了，去除无效记录，再去重取数量即可：
[php]
JSSWEB> select count(unique am)
   2 from (select Months_between(end_date, start_date) mb,
   3                b.lv,
   4                add_months(a.start_date, lv) am
   5          from tmp3 a,
   6                (select level - 1 lv
   7                   from dual
   8                connect by rownum <=
   9                            (select max(Months_between(end_date, start_date)) mb
10                               from test t)) b) c
11 where c.mb > lv
12 order by am;

COUNT(UNIQUEAM)
---------------
         15

4、将列值为0的列替换为距离它最近列的非0值

记录集如下：
ADDDATE ADDVALUE
-------------- ---------------
2007-03-01 0
2007-03-02 0
2007-03-05 3.64
2007-03-06 3.82
2007-03-07 0
2007-03-08 3.47
2007-03-09 0
2007-03-12 0
2007-03-13 4.01
2007-03-14 4.21
2007-03-15 4.12
2007-03-16 0
2007-03-17 0

用SQL实现如下效果：
ADDDATE ADDVALUE
-------------- ---------------
2007-03-01 3.64
2007-03-02 3.64
2007-03-05 3.64
2007-03-06 3.82
2007-03-07 3.47
2007-03-08 3.47
2007-03-09 4.01
2007-03-12 4.01
2007-03-13 4.01
2007-03-14 4.21
2007-03-15 4.12
2007-03-16 0
2007-03-17 0

建表语句如下：
create table tmp4 (adddate varchar2(20),addvalue number);
insert into tmp4 values ('2007-03-01',0);
insert into tmp4 values ('2007-03-02',0);
insert into tmp4 values ('2007-03-05',3.64);
insert into tmp4 values ('2007-03-06',3.82);
insert into tmp4 values ('2007-03-07',0);
insert into tmp4 values ('2007-03-08',3.47);
insert into tmp4 values ('2007-03-09',0);
insert into tmp4 values ('2007-03-12',0);
insert into tmp4 values ('2007-03-13',4.01);
insert into tmp4 values ('2007-03-14',4.21);
insert into tmp4 values ('2007-03-15',4.12);
insert into tmp4 values ('2007-03-16',0);
insert into tmp4 values ('2007-03-17',0);
Commit;

解题思路：
别想歪了，这道题用lead,lag之类分析函数是不行地，费事又不讨好，最简单的方式，如果不考虑执行效率的话，可以这样：
[php]
JSSWEB> select a.adddate,
   2       decode(a.addvalue,0, nvl((select b.addvalue
   3          from tmp4 b
   4          where b.adddate > a.adddate
   5          and b.addvalue != 0
   6          and rownum = 1),0),a.addvalue) addvalue
   7 from tmp4 a
   8  ;

ADDDATE             ADDVALUE
-------------------- ----------
2007-03-01          3.64
2007-03-02          3.64
2007-03-05          3.64
2007-03-06          3.82
2007-03-07          3.47
2007-03-08          3.47
2007-03-09          4.01
2007-03-12          4.01
2007-03-13          4.01
2007-03-14          4.21
2007-03-15          4.12
2007-03-16          0
2007-03-17          0
--
[/php]

正如前文所说，这种方式效率实在堪忧，尤其是当tmp4记录量较大时，毕竟count(0)+1次tmp4表的扫描所花代价较大。
我们知道，上述形式的语句通常都是可以转换成连接查询的，因此，稍做转换：
[php]
JSSWEB> select ad1, decode(cw, 1, av1, 2, av2, 3, av1) adv
   2 from (select c.*, row_number() over(partition by ad1 order by ad2) rn
   3          from (select a.adddate ad1,
   4                      a.addvalue av1,
   5                      b.adddate ad2,
   6                      b.addvalue av2,
   7                      case
   8                         when a.addvalue != 0 then
   9                         1
10                         when b.adddate > a.adddate and a.addvalue = 0 then
11                         2
12                         when b.adddate is null and a.addvalue = 0 then
13                         3
14                         else
15                         0
16                      end as cw
17                   from tmp4 a, tmp4 b
18                where b.addvalue(+) != 0
19                and b.adddate(+)>a.adddate
20                order by a.adddate) c
21          where cw != 0)
22 where rn = 1
23  ;

AD1                      ADV
-------------------- ----------
2007-03-01                3.64
2007-03-02                3.64
2007-03-05                3.64
2007-03-06                3.82
2007-03-07                3.47
2007-03-08                3.47
2007-03-09                4.01
2007-03-12                4.01
2007-03-13                4.01
2007-03-14                4.21
2007-03-15                4.12
2007-03-16                   0
2007-03-17                   0

--
[/php]

稍加一点难度，如果希望的结果集是这样，又该怎么样实现呢：
ADDDATE ADDVALUE
-------------- ---------------
2007-03-01 3.64
2007-03-02 3.64
2007-03-05 3.64
2007-03-06 3.82
2007-03-07 3.47
2007-03-08 3.47
2007-03-09 4.01
2007-03-12 4.01
2007-03-13 4.01
2007-03-14 4.21
2007-03-15 4.12
2007-03-16 4.12
2007-03-17 4.12

并不困难，只要对我们的sql稍加改动即可
[php]
JSSWEB> select ad1,nav from(
   2  select c.*,row_number() over(partition by ad1 order by ad2) rn from (
   3  select a.adddate ad1,
   4       a.addvalue av1,
   5       b.adddate ad2,
   6       b.addvalue av2,
   7       case
   8          when a.addvalue != 0 then
   9          a.addvalue
10          when a.addvalue = 0 and b.adddate > a.adddate then
11          b.addvalue
12          when a.addvalue = 0 and b.adddate is null then
13          first_value(b.addvalue) over(order by b.adddate desc nulls last)
14          else
15          0
16       end nav
17 from tmp4 a, tmp4 b
18 where b.addvalue(+) != 0
19 and b.adddate(+)>a.adddate
20 order by 1
21  ) c where nav!=0)where rn=1
22  ;

AD1                      NAV
-------------------- ----------
2007-03-01                3.64
2007-03-02                3.64
2007-03-05                3.64
2007-03-06                3.82
2007-03-07                3.47
2007-03-08                3.47
2007-03-09                4.01
2007-03-12                4.01
2007-03-13                4.01
2007-03-14                4.21
2007-03-15                4.12
2007-03-16                4.12
2007-03-17                4.12

转自：http://www.itpub.net/forum.php?mod=viewthread&tid=970868&extra=pageD1%3D&page=1

本文链接

Statspack之十四-"log file sync" 等待事件（转贴）

2011-09-13T07:33:00Z

当一个用户提交(commits)或者回滚(rollback),session的redo信息需要写出到redo logfile中.
用户进程将通知LGWR执行写出操作,LGWR完成任务以后会通知用户进程.
这个等待事件就是指用户进程等待LGWR的写完成通知.

对于回滚操作，该事件记录从用户发出rollback命令到回滚完成的时间.

如果该等待过多，可能说明LGWR的写出效率低下，或者系统提交过于频繁.
针对该问题，可以关注:
log file parallel write等待事件
user commits,user rollback等统计信息可以用于观察提交或回滚次数

解决方案:
1.提高LGWR性能
尽量使用快速磁盘，不要把redo log file存放在raid 5的磁盘上
2.使用批量提交
3.适当使用NOLOGGING/UNRECOVERABLE等选项

可以通过如下公式计算平均redo写大小：

avg.redo write size = (Redo block written/redo writes)*512 bytes

如果系统产生redo很多，而每次写的较少，一般说明LGWR被过于频繁的激活了.
可能导致过多的redo相关latch的竞争,而且Oracle可能无法有效的使用piggyback的功能.

我们从一个statspack中提取一些数据来研究一下这个问题.

1.主要信息

DB Name         DB Id    Instance     Inst Num Release     OPS Host
------------ ----------- ------------ -------- ----------- --- ------------
DB           1222010599  oracle              1 8.1.7.4.5   NO  sun
                Snap Id     Snap Time      Sessions
                ------- ------------------ --------
 Begin Snap:       3473 13-Oct-04 13:43:00      540
   End Snap:       3475 13-Oct-04 14:07:28      540
    Elapsed:                  24.47 (mins)

Cache Sizes
~~~~~~~~~~~
           db_block_buffers:     102400          log_buffer:   20971520
              db_block_size:       8192    shared_pool_size:       600M

Load Profile
~~~~~~~~~~~~                            Per Second       Per Transaction
                                   ---------------       ---------------
                  Redo size:             28,458.11              2,852.03
                  ......

2.等待事件

Event                               Waits   Timeouts  Time (cs)    (ms)   /txn
---------------------------- ------------ ---------- ----------- ------ ------
log file sync                      14,466          2       4,150      3    1.0
db file sequential read            17,202          0       2,869      2    1.2
latch free                         24,841     13,489       2,072      1    1.7 
direct path write                     121          0       1,455    120    0.0
db file parallel write              1,314          0       1,383     11    0.1
log file sequential read            1,540          0          63      0    0.1
....
log file switch completion              1          0           3     30    0.0
refresh controlfile command            23          0           1      0    0.0
LGWR wait for redo copy                46          0           0      0    0.0
....
log file single write                   4          0           0      0    0.0

我们看到，这里log file sync和db file parallel write等待同时出现了.
显然log file sync在等待db file parallel write的完成.

这里磁盘IO肯定存在了瓶颈，实际用户的redo和数据文件同时存放在Raid的磁盘上，存在性能问题.
需要调整.

3.统计信息

Statistic                                    Total   per Second    per Trans
--------------------------------- ---------------- ------------ ------------
....
redo blocks written                         93,853         63.9          6.4
redo buffer allocation retries                   1          0.0          0.0
redo entries                               135,837         92.5          9.3
redo log space requests                          1          0.0          0.0
redo log space wait time                         3          0.0          0.0
redo ordering marks                              0          0.0          0.0
redo size                               41,776,508     28,458.1      2,852.0
redo synch time                              4,174          2.8          0.3
redo synch writes                           14,198          9.7          1.0
redo wastage                             4,769,200      3,248.8        325.6
redo write time                              3,698          2.5          0.3
redo writer latching time                        0          0.0          0.0
redo writes                                 14,572          9.9          1.0
....
sorts (disk)                                     4          0.0          0.0
sorts (memory)                             179,856        122.5         12.3
sorts (rows)                             2,750,980      1,874.0        187.8
....
transaction rollbacks                           36          0.0          0.0
transaction tables consistent rea                0          0.0          0.0
transaction tables consistent rea                0          0.0          0.0
user calls                               1,390,718        947.4         94.9
user commits                                14,136          9.6          1.0
user rollbacks                                 512          0.4          0.0
write clones created in backgroun                0          0.0          0.0
write clones created in foregroun               11          0.0          0.0
          -------------------------------------------------------------


avg.redo write size = (Redo block written/redo writes)*512 bytes
      = ( 93,853 / 14,572 )*512 
      = 3K

这个平均过小了，说明系统的提交过于频繁.

Latch Sleep breakdown for DB: DPSHDB  Instance: dpshdb  Snaps: 3473 -3475
-> ordered by misses desc

                                Get                                  Spin &
Latch Name                    Requests         Misses      Sleeps Sleeps 1->4
-------------------------- -------------- ----------- ----------- ------------
row cache objects              12,257,850     113,299          64 113235/64/0/
                                                                  0/0
shared pool                     3,690,715      60,279      15,857 52484/588/65
                                                                  46/661/0
library cache                   4,912,465      29,454       8,876 23823/2682/2 
                                                                  733/216/0
cache buffers chains           10,314,526       2,856          33 2823/33/0/0/
                                                                  0
redo writing                       76,550         937           1 936/1/0/0/0
session idle bit                2,871,949         225           1 224/1/0/0/0
messages                          107,950         159           2 157/2/0/0/0
session allocation                184,386          44           6 38/6/0/0/0
checkpoint queue latch             96,583           1           1 0/1/0/0/0
          -------------------------------------------------------------

由于过渡频繁的提交，LGWR过度频繁的激活，我们看到这里出现了redo writing的latch竞争.

关于redo writing竞争你可以在steve的站点找到详细的介绍:
http://www.ixora.com.au/notes/lgwr_latching.htm

转引如下:

When LGWR wakes up, it first takes the redo writing latch to update the SGA variable that shows whether it is active. This prevents other Oracle processes from posting LGWR needlessly. LGWR then takes the redo allocation latch to determine how much redo might be available to write (subject to the release of the redo copy latches). If none, it takes the redo writing latch again to record that it is no longer active, before starting another rdbms ipc message wait.
If there is redo to write, LGWR then inspects the latch recovery areas for the redo copy latches (without taking the latches) to determine whether there are any incomplete copies into the log buffer. For incomplete copies above the sync RBA, LGWR just defers the writing of that block and subsequent log buffer blocks. For incomplete copies below the sync RBA, LGWR sleeps on a LGWR wait for redo copy wait event, and is posted when the required copy latches have been released. The time taken by LGWR to take the redo writing and redo allocation latches and to wait for the redo copy latches is accumulated in the redo writer latching time statistic.

(Prior to release 8i, foreground processes held the redo copy latches more briefly because they did not retain them for the application of the change vectors. Therefore, LGWR would instead attempt to assure itself that there were no ongoing copies into the log buffer by taking all the redo copy latches.)

After each redo write has completed, LGWR takes the redo allocation latch again in order to update the SGA variable containing the base disk block for the log buffer. This effectively frees the log buffer blocks that have just been written, so that they may be reused.

转自：http://www.eygle.com/statspack/statspack14-LogFileSync.htm

本文链接

Statspack之十三-Enqueue(转贴)

2011-09-13T07:22:00Z

enqueue是一种保护共享资源的锁定机制。该锁定机制保护共享资源，如记录中的数据，以避免两个人在同一时间更新同一数据。enqueue
包括一个排队机制，即FIFO（先进先出）排队机制。

Enqueue等待常见的有ST、HW 、TX 、TM等

ST enqueue，用于空间管理和字典管理的表空间(DMT)的区间分配，在DMT中典型的是对于uet$和fet$数据字典表的争用。对于支持LMT的
版本，应该尽量使用本地管理表空间. 或者考虑手工预分配一定数量的区(Extent)，减少动态扩展
时发生的严重队列竞争。

我们通过一个实例来看一下:

DB Name         DB Id    Instance     Inst Num Release     OPS Host
------------ ----------- ------------ -------- ----------- --- ------------------
DB       40757346      aaa                 1 8.1.7.4.0   NO    server

                Snap Id     Snap Time      Sessions
                ------- ------------------ --------
 Begin Snap:       2845 31-10月-03 02:10:16      46
   End Snap:       2848 31-10月-03 03:40:05      46
    Elapsed:                  89.82 (mins)


对于一个Statspack的report,采样时间是非常重要的维度，离开时间做参考，任何等待都不足以说明问题。

Cache Sizes
~~~~~~~~~~~
           db_block_buffers:      51200          log_buffer:    2097152
              db_block_size:      16384    shared_pool_size:  209715200
...........
Top 5 Wait Events
~~~~~~~~~~~~~~~~~                                   Wait     % Total
Event                                               Waits  Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
enqueue                                            53,793   16,192,686   67.86
rdbms ipc message                                  19,999    5,927,350   24.84
pmon timer                                          1,754      538,797    2.26
smon timer                                             17      522,281    2.19
SQL*Net message from client                   94,525      520,104   2.18
          -------------------------------------------------------------

在Statspack分析中，Top 5等待事件是我们最为关注的部分。
这个系统中，除了enqueue 等待事件以外，其他4个都属于空闲等待事件，无须关注。我们来关注一下enqueue等
待事件，在89.82 (mins)的采样间隔内，累计enqueue等待长达16,192,686cs,即45小时左右。这个等待已经太过
显著，实际上这个系统也正因此遭遇了巨大的困难，观察到队列等待以后，我们就应该关注队列等待在等待什么
资源。快速跳转的Statspack的其他部分，我们看到以下详细内容:

Enqueue activity for DB: DB  Instance: aaa  Snaps: 2716 -2718
-> ordered by waits desc, gets desc

Enqueue            Gets      Waits
---------- ------------ ----------
ST                1,554      1,554
          -------------------------------------------------------------

我们看到主要队列等待在等待ST锁定，对于DMT，我们说这个等待跟FET$,UET$的争用紧密相关。我们在回过头来
研究捕获的SQL语句:

-> End Buffer Gets Threshold:   10000
-> Note that resources reported for PL/SQL includes the resources used by
   all SQL statements called within the PL/SQL code.  As individual SQL
   statements are also reported, it is possible and valid for the summed
   total % to exceed 100

  Buffer Gets    Executions  Gets per Exec  % Total  Hash Value
--------------- ------------ -------------- ------- ------------
      4,800,073       10,268          467.5    51.0   2913840444
select length from fet$ where file#=:1 and block#=:2 and ts#=:3

        803,187       10,223           78.6     8.5    528349613
delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 a
nd ext#=:4

        454,444       10,300           44.1     4.8   1839874543
select file#,block#,length from uet$ where ts#=:1 and segfile#=:
2 and segblock#=:3 and ext#=:4

         23,110       10,230            2.3     0.2   3230982141
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)

         21,201          347           61.1     0.2   1705880752
select file# from file$ where ts#=:1
....
          9,505           12          792.1     0.1   1714733582
select f.file#, f.block#, f.ts#, f.length from fet$ f, ts$ t whe
re t.ts#=f.ts# and t.dflextpct!=0 and t.bitmapped=0

          6,426          235           27.3     0.1   1877781575
delete from fet$ where file#=:1 and block#=:2 and ts#=:3

我们看到数据库频繁操作UET$,FET$系统表已经成为了系统的主要瓶颈。至此，我们已经可以准确的为该系统定位问题，相应的解决方案也很容易确定，在8.1.7中，使用LMT代替DMT，这是解决问题的根本办法，当然实施起来还要进行综合考虑，实际情况还要复杂得多。

HW enqueue指和段的高水位标记相关等待；手动分配适当区可以避免这一等待。

TX锁（事务锁）是最常见的enqueue等待。TX enqueue等待通常是以下三个问题之一产生的结果。
第一个问题是唯一索引中的重复索引，你需要执行提交（commit）/回滚（rollback）操作来释放enqueue。
第二个问题是对同一位图索引段的多次更新。因为单个位图段可能包含多个行地址（rowid），所以当多个用户试图更新同一段时，可能一个
用户会锁定其他用户请求的记录，这时等待出现。直到获得锁定的用户提交或回滚， enqueue释放。
第三个问题，也是最可能发生的问题是多个用户同时更新同一个块。如果没有足够的ITL槽，就会发生块级锁定。通过增大initrans和/或maxtrans以允许使用多个ITL槽（对于频繁并发进行DML操作的数据表，在建表之初就应该考虑为相应参数设置合理的数值，避免系统运行以后在线的更改，在8i之前，freelists等参数不能在线更改，设计时的考虑就尤为重要），或者增大表上的pctfree值，就可以很容易的避免这种情况。

TM enqueue队列锁在进行DML操作前获得，以阻止对正在操作的数据表进行任何DDL操作(在DML操作一个数据表时，其结构不能被更改)。

转自：http://www.eygle.com/statspack/statspack13.htm

本文链接

Statspack之十二-db file scattered read-DB文件分散读取（转帖）

2011-09-07T08:53:00Z

这种情况通常显示与全表扫描相关的等待。
当数据库进行全表扫时，基于性能的考虑，数据会分散(scattered)读入Buffer Cache。如果这个等待事件比较显著，
可能说明对于某些全表扫描的表，没有创建索引或者没有创建合适的索引，我们可能需要检查这些数据表已确定是否进
行了正确的设置。

然而这个等待事件不一定意味着性能低下，在某些条件下Oracle会主动使用全表扫描来替换索引扫描以提高性能，这
和访问的数据量有关，在CBO下Oracle会进行更为智能的选择，在RBO下Oracle更倾向于使用索引。

因为全表扫描被置于LRU（Least Recently Used，最近最少适用）列表的冷端（cold end），对于频繁访问的较
小的数据表，可以选择把他们Cache到内存中，以避免反复读取。

当这个等待事件比较显著时，可以结合v$session_longops动态性能视图来进行诊断，该视图中记录了长时间（运
行时间超过6秒的）运行的事物，可能很多是全表扫描操作（不管怎样，这部分信息都是值得我们注意的）。

我们通过通过一个案例分析来熟悉一下这个等待事件:

DB Name        DB Id     Instance    Inst Num  Release     OPS   Host         
----------  -----------  ----------  --------  ----------  ----  ----------   
K2        1999167370      k2              1  8.1.5.0.0   NO      k2       


这是一个8.1.5的数据库系统，通过脚本增强，我们可以在8.1.5的数据库上使用statspack来进行数据库诊断。

                                                             Snap Length   
Start Id    End Id       Start Time             End Time         (Minutes)    
--------  --------  --------------------  --------------------  -----------   
     170       176  25-Feb-03 10:00:11    25-Feb-03 15:00:05         299.90   

Cache Sizes                                                                   
~~~~~~~~~~~                                                                   
           db_block_buffers:       64000                                      
              db_block_size:        8192                                      
                 log_buffer:     8388608                                      
           shared_pool_size:   157286400                                      
                                                                              
………………                    
                                                                              
Top 5 Wait Events                                                             
~~~~~~~~~~~~~~~~~                                                     Wait  % Total
Event                                          Waits     Time (cs)  Wt Time
-------------------------------------------- ------------ ----------------------- -------
db file scattered read                         16,842,920             3,490,719   43.32
latch free                                     844,272      3,270,073   40.58
buffer busy waits                               114,421          933,136   11.58
db file sequential read                          2,067,910         117,750    1.46
enqueue                                          464          110,840    1.38
         -------------------------------------------------------------        

这是一个典型的性能低下的系统，几个重要的等待事件都在Top 5中出现，其中，前3个等待极为显著，需要进行
相应的调整。
在5小时的采样间隔内，其中db file scattered read累计等待时间约10小时，已经成为影响系统性能的主要原因。
了解了这些以后我们就可以进一步察看相关SQL看是否存在可以的SQL语句。

SQL ordered by Gets for DB: K2  Instance: k2  Snaps:     170 -    176   
                                                                              
                                Gets       % of                               
   Buffer Gets     Executes   per Exec    Total   Hash Value                  
-------------- ------------ ------------ ------ ------------                  
SQL statement                                                                 
------------------------------------------------------------------------------
     6,480,163           12    540,013.6    2.4   3791855498                  
  SELECT "PROCESS_REQ"."WORK_ID", "PROCESS_REQ"."STOCK_NO",    "PROCESS_R
                                                                              
     3,784,566           16    236,535.4    1.4   2932917818                  
SELECT * FROM FIND_LATER_WO ORDER BY NOTE,ORDER_NO                            
                                                                                
     1,200,976            3    400,325.3     .4   4122791109                  
  SELECT "ITEM_STOCK"."ITEM_NO",              "ITEM"."NOTE",            "ITEM"
                                                                               
       923,944            9    102,660.4     .3   2200071737                  
  SELECT  "ITEM_STOCK"."ITEM_NO" ,           "ITEM_STOCK"."STOCK_NO" ,        
                                                                              
       921,301            3    307,100.3     .3   2218843294                  
  SELECT "ITEM_STOCK"."ITEM_NO",              "ITEM"."NOTE",            "ITEM"
                                                                              
       911,285            3    303,761.7     .3   1769130587                  
  SELECT  "LISTS"."ITEM_NO" ,           "LISTS"."SUB_ITEM" ,           "LISTS"
                                                                              
       831,439            2    415,719.5     .3   1349577999                  
  SELECT  "GROUP_OPER"."ITEM_NO" ,           "GROUP_OPER"."PROCESS_ID" ,      
                                                                              
       802,918            1    802,918.0     .3   3613809507                  
  SELECT  "LISTS"."ITEM_NO" ,           "LISTS"."SUB_ITEM" ,           "ITEM".
                                                                              
       800,548            2    400,274.0     .3   2643788247                  
  SELECT "ITEM_STOCK"."ITEM_NO",              "ITEM"."NOTE",            "ITEM"
                                                                              
       666,085            2    333,042.5     .2   3391363608                  
  SELECT "ITEM_STOCK"."ITEM_NO",              "ITEM_STOCK"."STOCK_NO",        
          ………..                                                               

注意到以上很多查询导致的Buffer Gets都非常庞大，我们非常有理由怀疑索引存在问题，甚至缺少必要的索引。
以上记录的是SQL的片段，通过Hash Value值结合v$sql_text我们可以获得完整的SQL语句。

在这次诊断中，我紧接着去查询的是v$session_longops数据表，一个分组查询的结果如下:

TARGET                                  COUNT(*)
---------------------------------------------------------------- ----------
SA.PPBT_GRAPHOBJTABLE                  418
SA.PPBT_PPBTOBJRELATTABLE              53

我们发现这些问题SQL的全表扫描(结合v$session_longops视图中的OPNAME)主要集中在PPBT_GRAPHOBJTABLE和
PPBT_PPBTOBJRELATTABLE两张数据表上。
进一步研究发现这两个数据表上没有任何索引，并且有相当的数据量:

SQL> select count(*) from SA.PPBT_PPBTOBJRELATTABLE;

  COUNT(*)
----------
   1209017
　SQL> select count(*) from SA.PPBT_GRAPHOBJTABLE;

   COUNT(*)
----------
      2445

在创建了合适的索引后，系统性能得到了大幅提高!

转自：http://www.eygle.com/statspack/statspack12.htm

本文链接

Statspack之十一-Statspack报告各部分简要说明（转帖）

2011-09-07T08:42:00Z

第一部分

数据库概要信息

DB Name         DB Id    Instance     Inst Num Release     Cluster Host
---------- ----------- ------------ --------   -----------  ------------
GLOB         188430914   glob              1  9.2.0.4.0   NO    b02

第二部分

数据库采样时段，这一部分记录了数据库采样的时间，以及采样点数，这部分信息对于report来说是十分重要。

任何统计数据都需要通过时间纬度来衡量，离开了时间，任何数据都失去了意义。

我们在论坛上经常看到有人贴出Top 5等待事件寻求分析，我们的回答是:

无法分析，如果没有时间纬度!

Snap Id     Snap Time      Sessions Curs/Sess Comment
            ------- ------------------ -------- --------- -------------------
Begin Snap:   508    10-Nov-03 15:27:29       76      39.4
End Snap:     511    10-Nov-03 15:57:42       66      35.4
   Elapsed:                               30.22 (mins)

第三部分

主要性能指标说明:

Execute to Parse %执行分析比率

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:  100.00       Redo NoWait %: 100.00
            Buffer  Hit   %:   99.81    In-memory Sort %: 100.00
            Library Hit   %:   98.75        Soft Parse %:  97.05
         Execute to Parse %:   44.21         Latch Hit %:  94.79
Parse CPU to Parse Elapsd %:   11.74     % Non-Parse CPU:  96.08

执行分析比率计算公式如下:

100 * (1 - Parses/Executions) = Execute to Parse

所以如果系统Parses > Executions,就可能出现该比率小于0的情况.

该参数计算来自以下部分:

Instance Activity Stats for DB: ORA9  Instance: ora91  Snaps: 30 -32

Statistic                              Total     per Second    per Trans
--------------------------------- ------------------ -------------- ------------
exchange deadlocks                       481            0.2          0.0
execute count                      4,873,158        1,968.2         94.4

……………

parse count (failures)                   542            0.2          0.0
parse count (hard)                    80,281           32.4          1.6
parse count (total)                2,718,643        1,098.0         52.6
parse time cpu                        44,009           17.8          0.9
parse time elapsed                   374,902          151.4          7.3

…………………….

通过公式及以上两个数值：

100 * (1 - Parses/Executions) = Execute to Parse

100 * (1 - 2,718,643/4,873,158) = 0.44211884777797067117462 * 100 = 44.21

该值<0通常说明shared pool设置或效率存在问题

造成反复解析，reparse可能较严重,或者可是同snapshot有关

如果该值为负值或者极低,通常说明数据库性能存在问题

Parse CPU to Parse Elapsd %

来自parse time cpu和parse time elapsed

100*（parse time cpu / parse time elapsed）= Parse CPU to Parse Elapsd %

100*（44,009 / 374,902）= 11.7388010733471680599196590% = 11.74%

Rollback per transaction 平均事务回滚率

% Blocks changed per Read:    0.37    Recursive Call %:    1.14
   Rollback per transaction %:   38.22       Rows per Sort:   11.83


如果回滚率过高，可能说明你的数据库经历了太多的无效操作
过多的回滚可能还会带来Undo Block的竞争

该参数计算公式如下:


     Round(User rollbacks / (user commits + user rollbacks) ,4)* 100%

…………….
user commits                             31,910           12.9          0.6
user rollbacks                           19,740            8.0          0.4
…………….

对于本例:

     Round(19740 / (31910 + 19740),4) = .3822

这一部分的内容还没有写完,在继续进行中...

转自：http://www.eygle.com/statspack/statspack11.htm

本文链接

Statspack之十-调整STATSPACK的收集门限（转帖）

2011-09-07T08:26:00Z

Statspack有两种类型的收集选项：

级别（level）：控制收集数据的类型

门限（threshold）：设置收集的数据的阈值。

1．级别（level）

Statspack共有三种快照级别，默认值是5

a.level 0: 一般性能统计。包括等待事件、系统事件、系统统计、回滚段统计、行缓存、SGA、会话、锁、缓冲池统计等等。

b.level 5: 增加SQL语句。除了包括level0的所有内容，还包括SQL语句的收集，收集结果记录在stats$sql_summary中。

c.level 10: 增加子锁存统计。包括level5的所有内容。并且还会将附加的子锁存存入stats$lathc_children中。在使用这个级别时需要慎重，建议在Oracle support的指导下进行。

可以通过statspack包修改缺省的级别设置

SQL>execute statspack.snap(i_snap_level=>0,i_modify_parameter=>’true’);

通过这样的设置，以后的收集级别都将是0级。

如果你只是想本次改变收集级别，可以忽略i_modify_parameter参数。

SQL>execute statspack.snap(i_snap_level=>10);

2．快照门限

快照门限只应用于stats$sql_summary表中获取的SQL语句。

因为每一个快照都会收集很多数据，每一行都代表获取快照时数据库中的一个SQL语句，所以stats$sql_summary很快就会成为Statspack中最大的表。

门限存储在stats$statspack_parameter表中。让我们了结一下各种门限：

a. executions_th这是SQL语句执行的数量(默认值是100)

b. disk_reads_tn这是SQL语句执行的磁盘读入数量（默认值是1000）

c. parse_calls_th这是SQL语句执行的解析调用的数量（默认值是1000）

d. buffer_gets_th这是SQL语句执行的缓冲区获取的数量（默认值是10000）

任何一个门限值超过以上参数就会产生一条记录。

通过调用statspack.modify_statspack_parameter函数我们可以改变门限的默认值。

例如：

SQL>execute statspack.modify_statspack_parameter(i_buffer_gets_th=>100000,i_disk_reads_th=>100000;

转自：http://www.eygle.com/statspack/statspack10.htm

本文链接

Statspack之九-其它重要脚本（转帖）

2011-09-07T08:23:00Z

1．通过导出保存及共享数据

在诊断系统问题时，可能需要向专业人士提供原始数据，这时我们可以导出Statspack表数据，其中我们可能用到：spuexp.par

其内容主要为：

file=spuexp.dmp log=spuexp.log compress=y grants=y indexes=y rows=y constraints=y owner=PERFSTAT consistent=y

我们可以导出如下：

exp userid=perfstat/my_perfstat_password parfile=spuexp.par

2．删除数据

spdrop.sql在执行时主要调用两个脚本: spdtab.sql 、spdusr.sql

前者删除表及同义词等数据，后者删除用户

3．Oracle92中新增加的脚本

1．用于升级statspack对象的脚本,这些脚本需要以具有SYSDBA权限的用户运行, 升级前请先备份存在的Schema数据:

SPUP90.SQL: 用于升级9.0版本的模式至9.2版本。
SPUP817.SQL: 如果从Statspack 8.1.7升级,需要运行这个脚本
SPUP816.SQL: 从Statspack 8.1.6升级,需要运行这个脚本，然后运行SPUP817.SQL.

2．sprepsql.sql 用于根据给定的SQL Hash值生成SQL报告

转自：http://www.eygle.com/statspack/statspack09.htm

本文链接

Statspack之八-删除历史数据（转帖）

2011-09-07T08:03:00Z

删除stats$snapshot数据表中的相应数据，其他表中的数据会相应的级连删除：

SQL> select max(snap_id) from stats$snapshot;

MAX(SNAP_ID)

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

166

SQL> delete from stats$snapshot where snap_id < = 166;

143 rows deleted

你可以更改snap_id的范围以保留你需要的数据。

在以上删除过程中，你可以看到所有相关的表都被锁定。

SQL> select a.object_id,a.oracle_username ,b.object_name
from v$locked_object a,dba_objects b
where a.object_id = b.object_id
/

OBJECT_ID ORACLE_USERNAMEOBJECT_NAME

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

156 PERFSTATSNAP$

39700 PERFSTATSTATS$LIBRARYCACHE

39706 PERFSTATSTATS$ROLLSTAT

39712 PERFSTATSTATS$SGA

39754 PERFSTATSTATS$PARAMETER

39745 PERFSTATSTATS$SQL_STATISTICS

39739 PERFSTATSTATS$SQL_SUMMARY

39736 PERFSTATSTATS$ENQUEUESTAT

39733 PERFSTATSTATS$WAITSTAT

39730 PERFSTATSTATS$BG_EVENT_SUMMARY

39724 PERFSTATSTATS$SYSTEM_EVENT

39718 PERFSTATSTATS$SYSSTAT

39715 PERFSTATSTATS$SGASTAT

39709 PERFSTATSTATS$ROWCACHE_SUMMARY

39703 PERFSTATSTATS$BUFFER_POOL_STATISTICS

39697 PERFSTATSTATS$LATCH_MISSES_SUMMARY

39679 PERFSTATSTATS$SNAPSHOT

39682 PERFSTATSTATS$FILESTATXS

39688 PERFSTATSTATS$LATCH

174 PERFSTATJOB$

20 rows selected

Oracle还提供了系统脚本用于Truncate这些统计信息表，这个脚本名字是: sptrunc.sql (8i、9i都相同)

该脚本主要内容如下，里面看到的就是statspack相关的所有系统表：

truncate table STATS$FILESTATXS;

truncate table STATS$LATCH;

truncate table STATS$LATCH_CHILDREN;

truncate table STATS$LATCH_MISSES_SUMMARY;

truncate table STATS$LATCH_PARENT;

truncate table STATS$LIBRARYCACHE;

truncate table STATS$BUFFER_POOL_STATISTICS;

truncate table STATS$ROLLSTAT;

truncate table STATS$ROWCACHE_SUMMARY;

truncate table STATS$SGA;

truncate table STATS$SGASTAT;

truncate table STATS$SYSSTAT;

truncate table STATS$SESSTAT;

truncate table STATS$SYSTEM_EVENT;

truncate table STATS$SESSION_EVENT;

truncate table STATS$BG_EVENT_SUMMARY;

truncate table STATS$WAITSTAT;

truncate table STATS$ENQUEUESTAT;

truncate table STATS$SQL_SUMMARY;

truncate table STATS$SQL_STATISTICS;

truncate table STATS$SQLTEXT;

truncate table STATS$PARAMETER;

delete from STATS$SNAPSHOT;

delete from STATS$DATABASE_INSTANCE;

commit;

如果采样了大量的数据，直接Delete是非常缓慢的，可以考虑使用上述SQL截断所有表。

转自：http://www.eygle.com/statspack/statspack08.htm

本文链接

Statspack之七-移除定时任务（转贴）

2011-09-07T07:55:00Z

移除一个定时任务，可以如下操作:

SQL> select job,log_user,priv_user,last_date,next_date,interval from user_jobs;

JOB LOG_USERLAST_DATENEXT_DATEINTERVAL

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

22 PERFSTAT 2002-12-5:14:33:26 2002-12-5 14:43:00 trunc(SYSDATE+1/144,'MI')

SQL> execute dbms_job.remove('22')

PL/SQL procedure successfully completed

当你完成了一个采样报告，你应该及时移除这个job任务，在生产环境中，遗漏一个无人照顾的job是非常危险的，
如果statspack运行一个星期，采样的数据量是非常惊人的。有的生产企业因疏忽而当机！

转自：http://www.eygle.com/statspack/statspack07.htm

本文链接

Statspack之六-生成分析报告(转贴)

2011-09-07T07:46:00Z

Statspack之六-生成分析报告

调用spreport.sql可以生成分析报告：

SQL> @spreport

DB Id DB Name Inst Num Instance
----------- ------------ -------- ------------
1277924236 EYGLE 1 eygle

Completed Snapshots

Snap Snap
Instance DB Name Id Snap Started Level Comment
------------ ------------ ----- ----------------- ----- ----------------------
eygle EYGLE 1 04 12月 2002 14:30 5
eygle EYGLE 2 04 12月 2002 15:00 5

………………

eygle EYGLE 98 05 12月 2002 04:10 5
eygle EYGLE 99 05 12月 2002 04:20 5
eygle EYGLE 100 05 12月 2002 04:30 5

....

Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
输入 begin_snap 的值: 1
Begin Snapshot Id specified: 1

输入 end_snap 的值: 100
End Snapshot Id specified: 100

Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is sp_1_100. To use this name,
press <return> to continue, otherwise enter an alternative.
输入 report_name 的值: rep1205.txt

Using the report name rep1205.txt

这样就生成了一个报告，可是如果中间停过机，那么你可能收到以下错误信息：

ERROR: Snapshots chosen span an instance shutdown: RESULTS ARE INVALID

STATSPACK report for

DB NameDB IdInstanceInst Num ReleaseOPS Host

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

EYGLE1277924236 eygle1 8.1.7.0.0NOAM-SERVER

:ela:=;

ERROR 位于第 4 行:

ORA-06550: 第 4 行, 第 17 列:

PLS-00103: 出现符号 ";"在需要下列之一时：

(-+modnotnull<an identifier>

<a double-quoted delimited-identifier><a bind variable>avg

countcurrentexistsmaxminpriorsqlstddevsumvarianceexecute

foralltimetimestampintervaldate

符号 "null" 被替换为 ";" 后继续。

ORA-06550: 第 6 行, 第 16 列:

PLS-00103: 出现符号 ";"在需要下列之一时：

(-+modnotnull<an identifier>

<a double-quoted delimited-identifier><a bind variable>avg

countcurrentexistsmaxminpriorsqlstddevsumvarianceexecute

foralltimetimestampintervaldate

<a stri

一个statspack的报告不能跨越一次停机，但是之前或之后的连续区间，收集的信息依然有效。你可以选择之前或之后的采样声称report。

转自： http://www.eygle.com/statspack/statspack06.htm

本文链接