一个回滚段可以存放多个事务的回滚信息。回滚段的作用1。事务回滚:当事务修改表中数据的时候,该数据修改前的值(即前影像)会存放在回滚段中,当用户回滚事务(ROLLBACK)时,ORACLE 将会利用回滚段中的数据前影像来将修改的数据恢复到原来的值。2。事务恢复:当事务正在处理的时候,例程失败,回滚段的信息保存在重做日志文件中,ORACLE 将在下次打开数据库时利用回滚来恢复未提交的数据。3。读一致性:当一个会话正在修改数据时,其他的会话将看不到该会话未提交的修改。而且,当一个语句正在执行时,该语句将看不到从该语句开始执行后的未提交的修改(语句级读一致性)。当ORACLE 执行SELECT 语句时,ORACLE 依照当前的系统改变号(SYSTEMCHANGE NUMBER-SCN)来保证任何前于当前SCN 的未提交的改变不被该语句处理。可以想象:当一个长时间的查询正在执行时,若其他会话改变了该查询要查询的某个数据块,ORACLE 将利用回滚段的数据前影像来构造一个读一致性视图。事务级的读一致性ORACLE 一般提供SQL 语句级(SQL STATEMENT LEVEL)的读一致性,可以用以下语句来实现事务级的读一致性。SET TRANSACTION READ ONLY;或:SET TANNSACTION SERIALIZABLE;以上两个语句都将在事务开始后提供读一致性。需要注意的是,使用第二个语句对数据库的并发性和性能将带来影响。回滚段的种类1。系统回滚段:当数据库创建后,将自动创建一个系统回滚段,该回滚段只用于存放系统表空间中对象的前影像。2。非系统回滚段:拥有多个表空间的数据库至少应该有一个非系统回滚段,用于存放非系统表空间中对象的数据前影像。非系统回滚段又分为私有回滚段和公有回滚段,私有回滚段应在参数文件的ROLLBACK SEGMENTS 参数中列出,以便例程启动时自动使其在线(ONLINE)。公有回滚段一般在OPS(ORACLE 并行服务器)中出现,将在例程启动时自动在线。3。DEFERED 回滚段:该回滚段在表空间离线(OFFLINE)时由系统自动创建,当表空间再次在线(ONLINE)时由系统自动删除,用于存放表空间离线时产生的回滚信息。回滚段的使用分配回滚段:当事务开始时,ORACLE 将为该事务分配回滚段,并将拥有最少事务的回滚段分配给该事务。事务可以用以下语句申请指定的回滚段:SET TRANSTRACTION USE ROLLBACK SEGMENT rollback_segment事务将以顺序,循环的方式使用回滚段的区(EXTENTS),当当前区用满后移到下一个区。几个事务可以写在回滚段的同一个区,但每个回滚段的块只能包含一个事务的信息。例如(两个事务使用同一个回滚段,该回滚段有四个区):1、事务在进行中,它们正在使用回滚段的第三个区;2、当两个事务产生更多的回滚信息,它们将继续使用第三个区;3、当第三个区满后,事务将写到第四个区,当事务开始写到一个新的区时,称为翻转(WRAP);4、当第四个区用满时,如果第一个区是空闲或非活动(使用该区的所有事务完成而没有活动的事务)的,事务将接着使用第一个区。回滚段的扩张(EXTEND)当当前回滚段区的所有块用完而事务还需要更多的回滚空间时,回滚段的指针将移到下一个区。当最后一个区用完,指针将移到第一个区的前面。回滚段指针移到下一个区的前提是下一个区没有活动的事务,同时指针不能跨区。当下一个区正在使用时,事务将为回滚段分配一个新的区,这种分配称为回滚段的扩展。回滚段将一直扩展到该回滚段区的个数到达回滚段的参数MAXEXTENTS 的值时为止。回滚段的回收和OPTIMAL 参数OPTIMAL 参数指明回滚段空闲时收缩到的位置,指明回滚段的OPTIMAL 参数可以减少回滚段空间的浪费。V$ROLLSTAT 中的常用列 USN:回滚段标识 RSSIZE:回滚段默认大小 XACTS:活动事务数在一段时间内增量用到的列 WRITES:回滚段写入数(单位:bytes) SHRINKS:回滚段收缩次数 EXTENDS:回滚段扩展次数 WRAPS:回滚段翻转(wrap)次数 GETS:获取回滚段头次数 WAITS:回滚段头等待次数V$ROLLSTAT 中的连接列Column View Joined Column(s)-------------- ----------------------- ------------------------USN V$ROLLNAME USN注意:通过花费时间除以翻转次数,你可以得到一次回滚段翻转(wrap)的平均用时。此方法常用于在长查询中指定合适的回滚段大小以避免'Snapshot Too Old'错误。同时,通过查看extends 和shrinks 列可以看出optimal 是否需要增加。示例:1.查询回滚段的信息。所用数据字典:DBA_ROLLBACK_SEGS,可以查询的信息:回滚段的标识(SEGMENT_ID)、名称(SEGMENT_NAME)、所在表空间(TABLESPACE_NAME)、类型(OWNER)、状态(STATUS)。select * from DBA_ROLLBACK_SEGS 查看回滚段的统计信息:SELECT n.name, s.extents, s.rssize, s.optsize, s.hwmsize, s.xacts,s.statusFROM v$rollname n, v$rollstat sWHERE n.usn = s.usn;3.查看回滚段的使用情况,哪个用户正在使用回滚段的资源:select s.username, u.namefrom v$transaction t, v$rollstat r, v$rollname u, v$session swhere s.taddr = t.addrand t.xidusn = r.usnand r.usn = u.usnorder by s.username;学习动态性能表第16 篇--V$ROWCACHE 2007.6.12本视图显示数据字典缓存(也叫rowcache)的各项统计。每一条记录包含不同类型的数据字典缓存数据统计,注意数据字典缓存有层次差别,因此同样的缓存名称可能不止一次出现。V$ROWCACHE 常用列 PARAMETER:缓存名 COUNT:缓存项总数 USAGE:包含有效数据的缓存项数 GETS:请求总数 GETMISSES:请求失败数 SCANS:扫描请求数 SCANMISSES:扫描请求失败次数 MODIFICATIONS:添加、修改、删除操作数 DLM_REQUESTS:DLM 请求数 DLM_CONFLICTS:DLM 冲突数 DLM_RELEASES:DLM 释放数使用 V$ROWCACHE 数据1>.确认数据字典缓存是否拥有适当的大小。如果shared pool 过小,那数据字典缓存就不足以拥有合适的大小以缓存请求信息。2>.确认应用是否有效访问缓存。如果应用设计未能有效使用数据字典缓存(比如,大数据字典缓存并不有助于解决性能问题)。例如,DC_USERS 缓存在过去某段时期内出现大量GETS,看起来像是数据库中创建了大量的不同用户,并且应用记录下用户频繁登陆和注销。通过检查logon 比率以及系统用户数可以验证上述数据。同时解析比率也会很高,如果这是一个大型的OLTP 系统的中间层,它可能在中间层更有效的管理个别帐户,允许中间层以单用户登陆成为应用所有者。通过保持活动连接来减少logon/logoff比率也同样有效。3>. 确认是否发生动态空间分配。DC_SEGMENTS, DC_USED_EXTENTS, 以及DC_FREE_EXTENTS 大量的类似大小修改将指出存在大量动态空间分配。可行的解决方案包括指定下一个区大小或者使用本地管理表空间。如果发生空间分配的是临时的表空间,则可以为其指定真正的临时表空间(If the space allocation is occurring on the temptablespace, then use a true temporary tablespace for the temp. )。4>.dc_sequences 值的变化指出是否大量sequence 号正在产生。5>.搜集硬解析的证据。硬解析常表现为大量向DC_COLUMNS, DC_VIEWS 以及DC_OBJECTS caches 的gets。示例:1.分组统计数据字典统计项SELECT parameter,sum("COUNT"),sum(usage),sum(gets),sum(getmisses),sum(scans),sum(scanmisses),sum(modifications),sum(dlm_requests),sum(dlm_conflicts),sum(dlm_releases)FROM V$ROWCACHEGROUP BY parameter;2.检查数据字典的命中率select 1 - sum(getmisses) / sum(gets) "data dictionary hitratio" fromv$rowcache;学习动态性能表第17 篇-(1)-V$SEGSTAT 2007.6.13本视图实时监控段级(segment-level)统计项,支持oracle9ir2 及更高版本V$SEGSTAT 中的常用列 TS#:表空间标识 OBJ#:字典对象标识 DATAOBJ#:数据对象标识 STATISTIC_NAME:统计项名称 STATISTIC#:统计项标识 VALUE:统计项值V$SEGSTAT 中的连接列Column View Joined Column(s)-------------- ----------------------- ------------------------TS# V$TABLESPACE TS#OBJ# ALL_OBJECTS OBJECT_ID示例:9. 查询指定对象的统计select * from v$segstat where ts# = 11and obj# = (select object_id from user_objectswhere object_name = 'TMPTABLE1' and wner = 'JSS')第 17 篇-(2)-V$SEGMENT_STATISTICS 2007.6.13这是一个友好的视图,支持Oracle9ir2 及更高版本。实时监测段级(segment-level)统计项,可用于鉴定性能问题源于表或索引V$SEGMENT_STATISTICS 中的列 OWNER:对象所有者 OBJECT_NAME:对象名称 SUBOBJECT_NAME:子对象名称 TABLESPACE_NAME:对象所在表空间 TS#:表空间标识 OBJ#:字典对象标识 DATAOBJ#:数据对象标识 OBJECT_TYPE:对象类型 STATISTIC_NAME:统计项名称 STATISTIC#:统计项标识 VALUE:统计项值基本与上相同,只是信息更加详细,不再赘述。学习动态性能表第18 篇--V$SYSTEM_EVENT 2007.6.13本视图概括了实例各项事件的等待信息。v$session_wait 显示了系统的当前等待项,v$system_event 则提供了自实例启动后各个等待事件的概括。常用于获取系统等待信息的历史影象。而通过两个snapshot 获取等待项增量,则可以确定这段时间内系统的等待项。V$SYSTEM_EVENT 中的常用列1. EVENT:等待事件名称2. TOTAL_WAITS:此项事件总等待次数3. TIME_WAITED:此项事件的总等待时间(单位:百分之一秒)4. AVERAGE_WAIT : 此项事件的平均等待用时( 单位: 百分之一秒)(time_waited/total_waits)5. TOTAL_TIMEOUTS:此项事情总等待超时次数示例:1.查看系统的各项等待,按总耗时排序SELECT event,total_waits waits,total_timeouts timeouts,time_waited total_time,average_wait avgFROM V$SYSTEM_EVENTORDER BY 4 DESC;比如,通过checkpoint completed、log file switch(checkpoint incomplete)可以查看检查点进程的性能。通过log file parallel write、log file switch completed 可以查看联机重做日志文件的性能。通过log file switch(archiving needed)事件可以检查归档进程的性能。找出瓶颈:1。通过Statspack 列出空闲事件。2。检查不同事件的等待时间开销。3。检查每条等待记录的平均用时,因为某些等待事件(比较log file switch completion)可能周期性地发生,但发生时却造成了严重的性能损耗。学习动态性能表第19 篇--V$UNDOSTAT 2007.6.14本视图监控当前实例中undo 空间以及事务如何运行。并统计undo 空间开销,事务开销以及实例可用的查询长度。V$UNDOSTAT 中的常用列 Endtime:以10 分钟为间隔的结束时间 UndoBlocksUsed:使用的undo 块总数 TxnConcurrency:事务并发执行的最大数 TxnTotal:在时间段内事务执行总数 QueryLength:查询长度的最大值 ExtentsStolen:在时间段内undo 区必须从一个undo 段转到另一个的次数 SSTooOldError:在时间段内'Snapshot Too Old'错误发生的次数 UNDOTSN:这段时间内最后活动的undo 表空间ID视图的第一行显示了当前时间段的统计,其它的每一条记录分别以每10 分钟一个区间。24 小时循环,一天最多144 条记录。示例:1.本例显示undo 空间从16:27 到之前24 小时内的各项统计。SQL>select * from v$undostat;End-Time UndoBlocks TxnConcrcy TxnTotal QueryLen ExtentsStolen SSTooOldError-------- ---------- ---------- -------- -------- ------------- -------------16:07 252 15 1511 25 2 016:00 752 16 1467 150 0 015:50 873 21 1954 45 4 015:40 1187 45 3210 633 20 115:30 1120 28 2498 1202 5 015:20 882 22 2002 55 0 0在统计项收集过程中,undo 消耗最高发生在15:30-15:40 这个时间段。10 分钟内有1187 个undo 块被占用(基本上每秒钟2 个块)。同时,最高事务并发也是在相同的时间段,45 个事务被并发执行。执行的最长查询(1202 秒)是在15:20-15:30 之间,需要注意的是查询实际上是15:00-15:10 段即开始并直到15:20 这个时间段。学习动态性能表第20 篇--V$WAITSTAT 2007.6.15本视图保持自实例启动所有的等待事件统计信息。常用于当你发现系统存在大量的"buffer busy waits"时据此做出适当调整。V$WAITSTAT 中的常用列 CLASS:块类别 WAITS:本类块的等待次数 TIME:本类块的总等待时间等待发生的原因:1.undo 段头部:没有足够的回滚段2.数据段头部/数据段空闲列:空闲列争夺3.数据块冲突4.缓存存在大量的CR 复制5.range 检索时,索引列存在大量不连续6.全表检索的表有大量被删除记录7.高并发的读写块
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/196700/viewspace-720730/
,如需转载,请注明出处,否则将追究法律责任。