Enqueue 有 3 个参数： 1. P1 表示 Lock type 、 mode 比如， P1RAW 的值为 54580006 ，其中， 54 表示的是 T ， 58 表示的为 X ， 6 表示的专用锁； 也可以用 SELECT chr(to_char(bitand(p1,-16777216))/16777215)|| chr(to_char(bitand(p1, 16711680))/65535) "Lock", to_char( bitand(p1, 65535) ) "Mode" FROM v$session_wait WHERE event = 'enqueue' ； 来查询当前发生 enqueue 等待事件的 Lock mode ，该值对应着 V$lock 中的 lock type 2. P2 、 P3 代表 Enqueue name 的 ID1 和 ID2 ，分别对应着 V$Lock 中的 ID1 和 ID2 大多数情况下， Enqueue 的等待时间为 3 秒 在 v$Lock 中， request ＝ 0 表示的是 Holder ， >0 表示的是 waiter 确定 Enqueue 的性能： 1. 可以查询 v$sysstat 来查看 enqueue 等待 select * from v$sysstata where class = 4 2. 对于 9i ，可以查询： SELECT eq_type "Lock", total_req# "Gets", total_wait# "Waits", cum_wait_time FROM V$enqueue_stat WHERE Total_wait# > 0 ; 3. 对于 8i ，可以查询： SELECT ksqsttyp "Lock", ksqstget "Gets", ksqstwat "Waits" FROM X$KSQST where KSQSTWAT > 0; 根据这两个 sql ，确定整个系统中的 enqueue 的等待情况 几个普遍存在的 Lock mode ： TX ：事务锁 Note 62354.1 ； 在以下情况下发生： 1) Another session is locking the requested row. 2) When two sessions tries to insert the same unique key into a table (none of them has done a COMMIT), then the last session is waiting for the first one to COMMIT or ROLLBACK. 3) There are no free ITL (Interested Transaction List) in the block header (increase INI_TRANS och PCT_FREE for the segment). TM ： DML enqueue ， 一般当外键没有建立索引的时候产生， Note 38373.1 ， Note 33453.1 ST ： space management enqueue ，当系统存在小碎片，或者存在大量的 sort 的时候产生 Note 33567.1 JQ ： Job queue UL ： user lock ，当用户 DBMS_LOCK.REQUEST 时产生 SQ ： sequence enqueue, 检查 sequence 的 cache size 是否过小 SS ： sort segment enqueue, 检查 temp 表空间太小，是否有查询需要使用大量的 temporary 空间 HW enqueue 指和段的高水位标记相关等待；手动分配适当区可以避免这一等待 TX 是最常见的 enqueue 等待。 TX enqueue 等待通常是以下三个问题之一产生的结果： 第一个问题是唯一索引中的重复索引，你需要执行提交（ commit ） / 回滚（ rollback ）操作来释放 enqueue 。 第二个问题是对同一位图索引段的多次更新。因为单个位图段可能包含多个行地址（ rowid ），所以当多个用户试图更新同一段时，可能一个用户会锁定其他用户请求的记录，这时等待出现。直到获得锁定的用户提交或回滚， enqueue 释放。 第三个问题，也是最可能发生的问题是多个用户同时更新同一个块。如果没有足够的 ITL 槽，就会发生块级锁定。通过增大 initrans 和 / 或 maxtrans 以允许使用多个 ITL 槽（对于频繁并发进行 DML 操作的数据表，在建表之初就应该考虑为相应参数设置合理的数值，避免系统运行以后在线的更改，在 8i 之前， freelists 等参数不能在线更改，设计时的考虑就尤为重要），或者增大表上的 pctfree 值，就可以很容易的避免这种情况。 TM enqueue 队列锁在进行 DML 操作前获得，以阻止对正在操作的数据表进行任何 DDL 操作 ( 在 DML 操作一个数据表时，其结构不能被更改 select * from V$ENQUEUE_STAT; enqueue 类型 : BL, Buffer Cache Management CF, Controlfile Transaction CI, Cross-instance Call Invocation CU, Bind Enqueue DF, Datafile DL, Direct Loader Index Creation DM, Database Mount DR, Distributed Recovery DX, Distributed TX FS, File Set IN, Instance Number IR, Instance Recovery IS, Instance State IV, Library Cache Invalidation JQ, Job Queue KK, Redo Log “Kick” L[A-P], Library Cache Lock MR, Media Recovery N[A-Z], Library Cache Pin PF, Password File PI, Parallel Slaves PR, Process Startup PS, Parallel Slave Synchronization Q[A-Z], Row Cache RT, Redo Thread SC, System Commit Number SM, SMON SQ, Sequence Number Enqueue SR, Synchronized Replication SS, Sort Segment ST, Space Management Transaction SV, Sequence Number Value TA, Transaction Recovery TM, DML Enqueue TS, Temporary Segment (also TableSpace) TT, Temporary Table TX, Transaction UL, User-defined Locks UN, User Name US, Undo Segment, Serialization WL, Being Written Redo Log XA, Instance Attribute Lock XI, Instance Registration Lock
Statspack Installation of the Statspack Package Installing the Statspack utility creates the perfstat user, who owns all PL/SQL code and database objects created (including the Statspack tables, the constraints, and the Statspack package). During the installation you will be prompted for the perfstat user’s default and temporary tablespaces. The Statspack package has been available with Oracle Database from Oracle8.1.6. When initially installed roughly 80 MBs of the perfstat user’s default tablespace is used. This may grow later with the tables storing snapshot information. Collecting Statistics To take a snapshot of performance data, log on to SQL*Plus as the perfstat user, and then execute the statspack.snap procedure. This stores the current performance statistics in the Statspack tables, which can be used as a baseline snapshot for comparison with another snapshot taken at a later time. Automatically Collecting Statistics To compare performance from one day, week, or year to the next, there must be multiple snapshots taken over a period of time. The best method to gather snapshots is to automate the collection at regular time intervals. The spauto.sql script makes use of the dbms_job package to provide an automated method for collecting statistics. The supplied script schedules a snapshot every hour, on the hour. This can be changed to suit the requirements of the system. Producing a Report To examine the change in statistics between two time periods, execute the spreport.sql file while being connected to the perfstat user. The user is shown a list of collection periods and selects a start and end period. The difference between the statistics at each end point is then calculated and put into a file named by the user.
First Page of the Statspack Report The first page summarizes the report. The items found on this page include most of the information that the DBA requires to enhance performance. Each of these areas will be covered in greater depth during the course. • Cache Sizes The current size of the buffer cache, shared pool, and log buffer are shown here in KB. Also included here is the value of the primary block size. • Load Profile One value given here is per second and the other is per transaction. What is shown includes the redo size and the physical reads and physical writes performed during the snapshot period. • Instance Efficiency Percentages The items listed here are ones that are most often used for tuning a database. These statistics are used to indicate that workloads have changed on the database. • Top Five Wait Events The full list of wait events appears later in the report and will be dealt with later in the course. The top contention items are listed under this heading.
![主要议题 ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)