Friends Life and Oracle http://www.eygle.com/blog/ eygle的Oracle Blog，提供Oracle技术研究及深入探讨，同时记录个人爱好及生活历程。 Copyright 2006 Sun, 16 Oct 2005 23:08:59 +0800 http://www.movabletype.org/?v=3.33 http://blogs.law.harvard.edu/tech/rss Statspack ORA-00001 错误的解决 Statspack ORA-00001错误。
Errors in file /oracle/app/oracle/admin/shyz/bdump/shyz1_ora_2588734.trc:
ORA-12012: error on auto execute of job 328
ORA-00001: unique constraint (PERFSTAT.STATS$SQL_SUMMARY_PK) violated
ORA-06512: at "PERFSTAT.STATSPACK", line 1361
ORA-06512: at "PERFSTAT.STATSPACK", line 2471
ORA-06512: at "PERFSTAT.STATSPACK", line 91
ORA-06512: at line 1
Sun Oct 16 00:43:39 2005
这个错误此前从未遇到，但是既然是主键冲突，那肯定是存在重复主键的数据。

肯定能暂时解决问题方法就是暂时禁用唯一约束检查:
ALTER TABLE PERFSTAT.STATS$SQL_SUMMARY MODIFY CONSTRAINT STATS$SQL_SUMMARY_PK DISABLE NOVALIDATE;

然后观察数据来发现根本问题，最后彻底解决之。

到Metalink搜索了一下，发现存在一个相关Bug，Bug号为:2784796.
在设置了cursor_sharing为similar或者force之后，可能触发此Bug，导致主键冲突。

此bug据说在Oracle10g中已经修正。
]]> http://www.eygle.com/archives/2005/10/statspack_unique_constraint_violated.html http://www.eygle.com/archives/2005/10/statspack_unique_constraint_violated.html Statspack Sun, 16 Oct 2005 23:08:59 +0800 Statspack专题 Statspack专题

 

]]> http://www.eygle.com/archives/2004/11/statspack_list.html http://www.eygle.com/archives/2004/11/statspack_list.html Statspack Sun, 14 Nov 2004 22:27:55 +0800 Statspack之十四-"log file sync" 等待事件 当一个用户提交(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/archives/2004/10/statspack14-logfilesync.html http://www.eygle.com/archives/2004/10/statspack14-logfilesync.html Statspack Thu, 14 Oct 2004 22:25:37 +0800 Statspack之十三-Enqueue 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/archives/2004/10/statspack13.html http://www.eygle.com/archives/2004/10/statspack13.html Statspack Thu, 14 Oct 2004 22:23:33 +0800 Statspack之十二-db file scattered read-DB文件分散读取 这种情况通常显示与全表扫描相关的等待。
当数据库进行全表扫时，基于性能的考虑，数据会分散(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/archives/2004/10/statspack12.html http://www.eygle.com/archives/2004/10/statspack12.html Statspack Thu, 14 Oct 2004 22:21:26 +0800 Statspack之十一-Statspack报告各部分简要说明
  • 第一部分

数据库概要信息

 

 

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/archives/2004/06/statspack11.html http://www.eygle.com/archives/2004/06/statspack11.html Statspack Fri, 25 Jun 2004 22:19:57 +0800 Statspack之十-调整STATSPACK的收集门限 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/archives/2004/06/statspack10.html http://www.eygle.com/archives/2004/06/statspack10.html Statspack Thu, 24 Jun 2004 22:18:49 +0800 Statspack之九-其它重要脚本 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/archives/2004/06/statspack09.html http://www.eygle.com/archives/2004/06/statspack09.html Statspack Thu, 24 Jun 2004 22:17:39 +0800 Statspack之八-删除历史数据 删除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/archives/2004/06/statspack08.html http://www.eygle.com/archives/2004/06/statspack08.html Statspack Thu, 24 Jun 2004 22:15:20 +0800 Statspack之七-移除定时任务 移除一个定时任务，可以如下操作:

 

 

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/archives/2004/06/statspack07.html http://www.eygle.com/archives/2004/06/statspack07.html Statspack Thu, 24 Jun 2004 22:00:25 +0800 Statspack之四-测试安装好的Statspack 运行statspack.snap可以产生系统快照，运行两次，然后执行spreport.sql就可以生成一个基于两个时间点的报告。

如果一切正常，说明安装成功。

 

SQL>execute statspack.snap

PL/SQL procedure successfully completed.

SQL>execute statspack.snap

PL/SQL procedure successfully completed.

SQL>@spreport.sql

…

 

 

可是有可能你会得到以下错误：

 

SQL> exec statspack.snap;

BEGIN statspack.snap; END;

 

*

ERROR at line 1:

ORA-01401: inserted value too large for column

ORA-06512: at "PERFSTAT.STATSPACK", line 978

ORA-06512: at "PERFSTAT.STATSPACK", line 1612

ORA-06512: at "PERFSTAT.STATSPACK", line 71

ORA-06512: at line 1

 

这是Oracle的一个Bug，Bug号1940915。

该Bug自8.1.7.3后修正。

这个问题只会出现在多位的字符集,需要修改spcpkg.sql脚本，$ORACLE_HOME/rdbms/admin/spcpkg.sql，
将"substr" 修改为 "substrb"，然后重新运行该脚本。

该脚本错误部分：

 

 

select l_snap_id

, p_dbid

, p_instance_number

, substr(sql_text,1,31)

．．．．．．．．．．．

 

 

substr 会将多位的字符, 当作一个byte.substrb 则会当作多个byte。在收集数据时， statpack 会将 top 10
的 sql 前 31 个字节存入数据表中,若在SQL的前31 个字有中文，就会出现此错误。

 

]]> http://www.eygle.com/archives/2004/06/statspack04.html http://www.eygle.com/archives/2004/06/statspack04.html Statspack Thu, 24 Jun 2004 22:00:25 +0800 Statspack之六-生成分析报告

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

<a string literal with character set specification>

<a number><a single-quoted SQL string>

符号 "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/archives/2004/06/statspack06.html http://www.eygle.com/archives/2004/06/statspack06.html Statspack Thu, 24 Jun 2004 22:00:25 +0800 Statspack之三-安装statspack 安装Statspack需要用internal身份登陆，或者拥有SYSDBA(connect / as sysdba)权限的用户登陆。
需要在本地安装或者通过telnet登陆到服务器。

在Oracle8.1.6版本中运行statscre.sql;在Oracle8.1.7版本中运行spcreate.sql。

 

首先登陆到数据库，最好转到$ORACLE_HOME/RDBMS/ADMIN目录，这样我们执行脚本就可以方便些。

 

D:\oracle\ora81\RDBMS\ADMIN>sqlplus internal

SQL*Plus: Release 8.1.7.0.0 - Production on 星期二 12月 3 16:54:53 2002

(c) Copyright 2000 Oracle Corporation.All rights reserved.

 

请输入口令:

 

连接到:

Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production

With the Partitioning option

JServer Release 8.1.7.0.0 - Production

 

SQL> select instance_name,host_name,version,startup_time from v$instance;

 

INSTANCE_NAMEHOST_NAME VERSIONSTARTUP_TIME

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

eygleAM-SERVER 8.1.7.0.022-11月-02

 

SQL>

 

 

注:在Oracle9i中，不存在internal用户，可以使用sys用户以sysdba身份连接:

 

 

D:\oracle\ora92\rdbms\admin>sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.3.0 - Production on 星期四 7月 10 19:18:54 2003

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

 

连接到: Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production

With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options

JServer Release 9.2.0.3.0 - Production

 

SQL>

 

检查数据文件路径及磁盘空间，以决定创建数据文件的位置：

 

SQL> select file_name from dba_data_files;

FILE_NAME

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

D:\ORACLE\ORADATA\EYGLE\SYSTEM01.DBF

D:\ORACLE\ORADATA\EYGLE\TEMP01.DBF

……

D:\ORACLE\ORADATA\EYGLE\HH_AM01.ORA

 

已选择24行。

 

SQL>

 

创建存储数据的表空间，如果采样间隔较短，周期较长，打算长期使用，那么你可能需要一个大一点的表空间，
如果每个半个小时采样一次，连续采样一周，数据量是很大的。本例创建一个500M的测试表空间。

 

注意:这里创建的表空间不能太小，如果太小创建对象会失败，至少需要建立100M表空间,如果打算
长期使用,可以建立稍大的表空间，本例创建500M LMT表空间。

 

SQL> create tablespace perfstat

2datafile 'd:\oracle\oradata\eygle\perfstat.dbf'

3size 500M

4extent management local;

 

表空间已创建。

SQL>

 

检查是否存在安装所需要的脚本文件(对于不同的版本，脚本有所不同)

 

E:\Oracle\ora92\rdbms\admin>dir /w sp*

驱动器 E 中的卷没有标签。

卷的序列号是 ACC3-4340

E:\Oracle\ora92\rdbms\admin 的目录

 

spauto.sqlspcpkg.sqlspcreate.sqlspctab.sqlspcusr.sqlspdoc.txt

spdrop.sqlspdtab.sqlspdusr.sqlsppurge.sqlsprepins.sqlspreport.sql

sprepsql.sqlsptrunc.sqlspuexp.parspup816.sqlspup817.sqlspup90.sql

18 个文件510,296 字节

0 个目录4,146,565,120 可用字节

 

接下来我们就可以开始安装Statspack了。这期间会提示你输入缺省表空间和临时表空间的位置,输入我们为
perfstat用户创建的表空间和你的临时表空间。

 

SQL> @spcreate

.

.

Specify PERFSTAT user's defaulttablespace

输入 default_tablespace 的值:perfstat

Using perfstat for the default tablespace

 

用户已更改。

 

 

用户已更改。

 

Specify PERFSTAT user's temporary tablespace

输入 temporary_tablespace 的值:temp

 

注意:在statspack创建过程中,当提示输入口令时，你可以输入一个明文口令，但是如果输入口令不符
合规范(如123或以数字开头的口令)，创建会失败。

输入口令时可以暂时输入:perfstat ,稍后可以更改。

 

 

... Creating PERFSTAT user ...

 

Choose the PERFSTAT user's password.

 

Not specifying a password will result in the installation FAILING

Specify PERFSTAT password

输入 perfstat_password 的值: 123

123

 

PL/SQL 过程已成功完成。

 

create user perfstat identified by 123

*

ERROR 位于第 1 行:

ORA-00988: 缺少或无效口令

 

如果安装成功，你可以看到如下的输出信息：

 

….

Creating Package STATSPACK...

 

程序包已创建。

 

没有错误。

Creating Package Body STATSPACK...

 

程序包主体已创建。

 

没有错误。

 

NOTE:

SPCPKG complete. Please check spcpkg.lis for any errors.

 

你可以查看.lis文件查看安装时的错误信息。

 

SQL> host dir *.lis

驱动器 D 中的卷没有标签。

卷的序列号是 5070-5982

 

D:\oracle\ora81\RDBMS\ADMIN 的目录

 

2002-12-0317:25204 spcpkg.lis

2002-12-0317:252,276 spctab.lis

2002-12-0317:253,965 spcusr.lis

2002-12-0317:231,187 spdtab.lis

2002-12-0317:24351 spdusr.lis

5 个文件7,983 字节

0 个目录3,965,304,832 可用字节

 

SQL> host find “ORA-“ *.lis

SQL> host find "err" *.lis

 

---------- SPAUTO.LIS

 

---------- SPCPKG.LIS

SPCPKG complete. Please check spcpkg.lis for any errors.

 

---------- SPCTAB.LIS

SPCTAB complete. Please check spctab.lis for any errors.

 

---------- SPCUSR.LIS

SPCUSR complete. Please check spcusr.lis for any errors.

 

---------- SPDTAB.LIS

 

在UNIX上，你可以通过以下命令查看相应的错误信息

 

$ ls *.lis

spauto.lisspcpkg.lisspctab.lisspcusr.lisspdtab.lisspdusr.lis

$ grep ORA- *.lis

$ grep err *.lis

spcpkg.lis:SPCPKG complete. Please check spcpkg.lis for any errors.

spctab.lis:SPCTAB complete. Please check spctab.lis for any errors.

spcusr.lis:SPCUSR complete. Please check spcusr.lis for any errors.

spdtab.lis:SPDTAB complete. Please check spdtab.lis for any errors.

spdusr.lis:SPDUSR complete. Please check spdusr.lis for any errors.

 

 

在这一步，如果出现错误，那么你可以运行spdrop.sql脚本来删除这些对象。然后重新运行spcreate.sql来创
建这些对象。运行 SQL*Plus, 以具有SYSDBA 权限的用户登陆：

 

 

SQL> @spdrop.sql

.

.

.

同义词已丢弃。off;

 

 

视图已丢掉。

 

 

同义词已丢弃。

 

 

视图已丢掉。

 

 

同义词已丢弃。

 

 

用户已丢弃

 

 

NOTE:

SPDUSR complete. Please check spdusr.lis for any errors.

 

SQL>

 

]]> http://www.eygle.com/archives/2004/06/statspack03.html http://www.eygle.com/archives/2004/06/statspack03.html Statspack Thu, 24 Jun 2004 22:00:25 +0800 Statspack之五-规划自动任务 Statspack正确安装以后，我们就可以设置定时任务，开始收集数据了。可以使用spatuo.sql来定义自动任务。

先来看看spauto.sql的关键内容：

 

 

dbms_job.submit(:jobno, 'statspack.snap;',

trunc(sysdate+1/24,'HH'), 'trunc(SYSDATE+1/24,''HH'')', TRUE, :instno);

 

 

这个job任务定义了收集数据的时间间隔：

一天有24个小时，1440分钟，那么：

1/24 HH每小时一次
1/48 MI每半小时一次
1/144 MI每十分钟一次
1/288 MI每五分钟一次

我们可以修改spauto.sql来更改执行间隔，如：

 

 

dbms_job.submit(:jobno, 'statspack.snap;',

trunc(sysdate+1/48,'MI'), 'trunc(SYSDATE+1/48,''MI'')', TRUE, :instno);

 

 

然后我们执行spauto，这样我们就建立了一个每30分钟执行一次的数据收集计划。你可以查看spauto.lis来获得输出信息：

SQL> @spauto

PL/SQL procedure successfully completed.

 

Job number for automated statistics collection for this instance

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

Note that this job number is needed when modifying or removing

the job:

 

JOBNO

----------

28

Job queue process

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

Below is the current setting of the job_queue_processes init.ora

parameter - the value for this parameter must be greater

than 0 to use automatic statistics gathering:

 

NAMETYPEVALUE

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

job_queue_processesinteger 5

 

 

Next scheduled run

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

The next scheduled run for this job is:

 

JOB NEXT_DATE NEXT_SEC

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

28 15-AUG-0316:00:00

 

关于采样间隔，我们通常建议以1小时为时间间隔，对于有特殊需要的环境，可以设置更短的，如半小时作为采样间隔，
但是不推荐更短。因为statspack的执行本身需要消耗资源，对于繁忙的生产系统，太短的采样对系统的性能会产生较
大的影响（甚至会使statspack的执行出现在采样数据中）。

]]> http://www.eygle.com/archives/2004/06/statspack05.html http://www.eygle.com/archives/2004/06/statspack05.html Statspack Thu, 24 Jun 2004 22:00:25 +0800 Statspack之二-需要更改的系统参数 为了能够顺利安装和运行Statspack你可能需要设置以下系统参数：

    • job_queue_processes

为了能够建立自动任务，执行数据收集，该参数需要大于0。你可以在初试化参数文件中修改该参数(使该参数在重起后以然有效)。

该参数可以在系统级动态修改(重起后失效)。

 

 

SQL> alter system set job_queue_processes = 6;

 

System altered

 

 

在Oracle9i当中，可以指定范围，如 both,这样该修改在当前及之后保持有效(仅当你使用spfile时，如果在9i中仍然使用pfile，
那么更改方法同8i相同):

 

 

SQL> alter system set job_queue_processes = 6 scope=both;

 

系统已更改。

 

 

    • timed_statistics

收集操作系统的计时信息，这些信息可被用来显示时间等统计信息、优化数据库和 SQL 语句。要防止因从操作系统请求时间而引
起的开销，请将该值设置为False。

使用statspack收集统计信息时建议将该值设置为 TRUE，否则收集的统计信息大约只能起到10%的作用，将timed_statistics
设置为True所带来的性能影响与好处相比是微不足道的。

该参数使收集的时间信息存储在在V$SESSTATS和V$SYSSTATS等动态性能视图中。

 

Timed_statistics参数可以在实例级进行更改

 

 

SQL> alter system set timed_statistics = true;

 

System altered

 

SQL>

 

 

如果你担心一致启用timed_statistics 对于性能的影响，你可以在使用statspack之前在system更改，采样过后把该参数动
态修改成false。

 

]]> http://www.eygle.com/archives/2004/06/statspack02.html http://www.eygle.com/archives/2004/06/statspack02.html Statspack Thu, 24 Jun 2004 21:54:09 +0800