<转>oracle性能调整读书笔记(5)

 

第六章 调整SGA的其它区域 7.Java池的概念 DoFe :+_U3 0Yq_B + IC e q%cRd] u Java池的概念 ~D }fy · 在Oracle中配置Java环境时有以下一些参数： h _P [B Ø SHARED_POOL_SIZE JVM缓存在共享池中； k ZG; \ Ø JAVA_POOL_SIZE 缓存与JAVA相关的会话数据，默认值20M，取值范围是1M到1G；（Oracle推荐，对于有JAVA的应用，将这个值设到50M或者更大） * rw 6?u9I Ø JAVA_SOFT_SESSIONSPACE_LIMIT 当某个JAVA进程请求的内存超过这个限制时，会写一条消息到用户跟踪文件，默认值是0，最大值是4G； ! :5 'MI@ Ø JAVA_MAX_SESSIONSPACE_LIMIT 当JAVA进程请求的内存超过这个参数的限制时，返回ora-29554的错误，默认值是0，最大值是4G； & L? ]w=* · 测量JAVA池的性能有下面两种方法： > O? Ø Select * From V$sgastat Where Pool = 'java pool'; 观察这个查询，如果发现未使用内存很大或者不断增加，表示JAVA池可能分配了太多的内存，如果未使用内存很小或者不断减少，表示可能需要加大JAVA池的内存。 @ | "K"j# Ø 观察Statspack中的SGA breakdown difference，里面有JAVA池free memory的起始值和终止值，如果终止值总是很小或者接近零，表示JAVA池可能太小了； 1>\ V>g 9 · 改进JAVA池的性能主要是增大JAVA_POOL_SIZE这个参数，这个参数不能动态调整。 @N Oh10X.) i 2{B S `f 第七章 调整日志机制 1. 理解Oracle的日志机制 / 3hY[#e Y c6. v8a kd"nBb= 理解Oracle的日志机制 { Dm@_& · Oracle的日志是用来记录用户对数据库的改变，这样，当出现服务器硬件故障或者用户错误而丢失数据时，可以通过重做这些日志来恢复已提交的事务，Oracle日志机制包含以下组件： 3HcduJnt l Ø 日志缓存 SGA的一部分，用于缓存服务器进程产生的日志，包括DML和DDL； .)bNi *& Ø LGWR进程 这个后台进程负责将日志缓存的数据写到联机日志文件，每个实例只有一个； E8 nj_ ^ Z Ø 数据库检查点 检查点用于同步数据文件和日志文件，一个检查点事件的完成，代表在这个事件开始之前发生的所有对数据文件的改变都已实际记录到了数据文件，数据库在这个时间点是一致的，在实例恢复的时候，只有在最后一个检查点之后的日志才需要重做； ' xnI N u Ø 联机日志文件 用于存放从日志缓存中写出的日志数据，每个数据库最少需要两个日志文件，当前日志文件填满以后，发生日志切换，然后才可以继续写下一个日志文件； YjL'GmL < Ø 日志归档 LGWR写满所有组的联机日志文件以后，会回头再写第一个组的日志文件，在非归档模式下，被重用的日志文件中的日志会被丢弃，在归档模式下，日志文件被重用前会被ARC0进程复制到归档日志文件； b]xoXC6@t · 一些可选的日志机制，如归档和Standby，因为附加的I/O会降低系统的性能，同时提供了可靠的灾难恢复能力，不建议因这些性能的下降而关闭生产系统的归档功能。 七章 调整日志机制 2.调整日志缓存 ! {G 0' y F/> \ uzu 调整日志缓存 p 2t0 4p! · 日志缓存的管理机制可以类似理解成一个漏斗，日志数据不断地从漏斗上方加入，然后偶尔打开漏斗下方的开关将加入的数据清空，这个开关就是LGWR进程，为了日志缓存有空间容纳不断加进来的日志数据，LGWR在下面列出的任何一个条件下都会执行写出日志缓存的操作： Yukn Z&Q Ø 应用程序发出Commit命令时； =N C?? e{ Ø 三秒间隔已到时； Ta?}n^V?; Ø 日志缓存三分之一满时； ` Ø 日志缓存达到1M时； { P~r f&Ee Ø 数据库检查点发生时； ; n(f?RO3X · 测量日志缓存的性能 通过服务器进程放置日志条到日志缓存时发生等待的次数和时间来测量； qD> ^aEd@4 Ø Select Name, Value n A b~ From V$sysstat z&d.YO _W Where Name In ('redo entries', 'redo buffer allocation retries', U; oXX 'redo log space requests'); @s-P!uCaT redo entries 服务器进程放进日志缓存的日志条的总数量； l6 HtZ ( redo buffer allocation retries 服务器放置日志条时必须等待然后再重试的次数； t(*n[7 e redo log space requests LGWR进程写出日志缓存时等待日志切换的次数； LQPQ !) :; MZh . Xo Select Retries.Value / Entries.Value "Redo log Buffer Retry Ratio" jJiuq# ;T3 From V$sysstat Entries, V$sysstat Retries Y0,{ f w< Where Entries.Name = 'redo entries' V X. LL 5 And Retries.Name = 'redo buffer allocation retries' _9lMa 7i 这个查询用于计算日志缓存重试率，这个比率应该小于百分之一； ,V9qiu=m Ø Select s.Username, Sw.Wait_Time, Sw.Seconds_In_Wait, Sw.State jV *10 kM< From V$session_Wait Sw, V$session s tjtvO @?1- Where Sw.Sid = s.Sid And Sw.Event Like '%log buffer space%'; n}Z% D -b$ 这个查询用来显示哪些会话的LGWR正在进行写等待； rwj+ N %N State有四个取值：WAITING(会话正在等待),WAITED UNKNOWN TIME(等待时间未知),WAITED SHORT TIME(等待时间小于百分之一秒),WAITED KNOWN TIME(等待时间已知，为wait_time栏位所示的时间); .c]>*/(+ Ø Statspack中有两个地方存有与日志缓存性能相关的数据： yGtTD 9j 实例命中率（Instance Efficiency Percentages）中的Redo NoWait%，这个值与日志缓存重试率之和等于1； s*g qKQ; 实例活动统计（Instance Activity Stats）中的redo entries, redo buffer allocation retries, redo log space requests； [ G8 EX 3 ` $ju n · 改进日志缓存的性能 bh5 D } w 改进日志缓存的性能就是减少或者消除服务器进程读取日志缓存及放置日志条到日志缓存时发生的等待，可以从下面两个方面入手： n32"cFPpT Ø 增大日志缓存 ')q4d0 B`" ü 日志缓存由初始参数LOG_BUFFER指定，最小值是64K，默认值是greatest(512k , 128k * CPU数); *C Xc{ { ü 当你指定的日志缓存小于最小值时，会以默认值来生效； b |.Cqsb ü 日志缓存的最大值由操作系统来指定，考虑到LGWR写出日志缓存的特点，大于3M的日志缓存已没有多大实际意义； e bp t/q [ Ø 减少日志的产生：UNRECOVERABLE，NOLOGGING RdD>& D$I ü UNRECOVERABLE 这个关键字用在下面的语法中：create table table_a as select * from table_b unrecoverable; 在表创建的过程可以尽可能少地产生日志，但对该表的后续DML操作没有影响，也不能用于分区表，索引组织表，含有大对象的表的创建，这个关键字的功能已被nologging取代； %C`P7&8m=O ü NOLOGGING是表的一个属性，可以在表创建时指定，也可以在表创建以后用alter命令进行更改，这个属性可以从许多字典表（DBA_TABLESPACES， DBA_TABLES， DBA_INDEXES，DBA_LOBS等）的logging字段查到； ! dwZ` D ü 启用该属性，可以在表创建，表上的索引创建及重建时产生较少的日志（DDL）； ( / $-2.@ ü 启用该属性，针对表上的数据插入，在以下两种情形下可以产生较少的日志（DML）：用SQL*Loader进行Direct Path Loads ，用append提示进行的Direct Load Inserts； EGgw#JAi#t ü 启用该属性后，用direct path方法装入的数据将会在媒体恢复的过程中丢失，如果这些数据装载发生在最近一次备份操作之后的话。 3}s] F/e v) *M gf S ?=4oxP e 第七章 调整日志机制 3.调整检查点 7 +f6? \:Tq0 |]Px @~s 5 { 4 调整检查点 Q e+;BE-H · 检查点事件代表在那个时刻数据库处于一致的状态，检查点之所以重要，是因为在实例失败后，只有发生在最后一个检查点之后事务需要恢复；有两种类型的检查点：增量检查点和完全检查点； ,nL~?h -Zh · 增量检查点是从ORACLE 8开始引入的，之前的版本只存在完全检查点，这个时候，所有的脏数据都要写回磁盘，巨大的I/O对系统性带来很大影响，而且在写出所有脏块的过程中会锁定数据缓存，写出完成之前再不能够产生新的脏块；和增量检查点相关的一个新的结构是检查点队列，这个队列中存放了所有按low RBA(第一次对此块修改对应的Redo Block Address)排序的脏块，每三秒，增量检查点去更新控制文件，记录当前检查点队列的最小的low RBA以及on-disk RBA(LGWR进程已经写入到日志文件的最后的日志位置)等信息，实例恢复的时候将从控制文件的low RBA开始，而不是从数据文件的Checkpoint SCN开始； `q]' ^EzJ · 完全检查点发生时，会执行下面的动作： W=A0+t% XC Ø 通知DBWn进程将所有的脏块写回磁盘； Su jEF ` " Ø DBWn在写出脏块时如果发现对应的日志还在日志缓冲区，就触发LGWR写出日志条； ' fK=;mM Ø 检查点进程更新控制文件和数据文件头； D Z L(G [ · 检查点的触发条件有下面一些： cd ,'37pZ Ø 实例关闭（ABORT方式除外）； > CKa ?N; Ø 日志切换； Y Ø 用户触发：Alter System Checkpoint; Alter Tablespace … Begin Backup; M 6MxY\uM Ø 初始参数FAST_START_MTTR_TARGET指定的值已超过（增量检查点）； XdIno }pN Ø 日志文件长度的90%（增量检查点）； l] DR J Ø 每三秒（增量检查点）； k Kbbs B · 完全检查点发生时，必须等到要求DBWn完成的任务完成后，检查点才能结束，增量检查点（FAST_START_MTTR_TARGET以及日志文件长度的90%）也会去建议DBWn应该尽快完成的任务，但不会强制触发DBWn，更不会等待其完成（看http://asktom.oracle.com/pls/ask ... 5023372后的理解）； 5C *Zb3VG4 · 监控检查点的活动很重要，因为太多的检查点会增加不必要的I/O，太少的检查点会使数据库在实例恢复时经历过长的时间； ]igCV · 测量检查点性能有下面一些方法： .-s!} P" Ø Select n.Name, Se.Total_Waits, Se.Average_Wait { 3 vm ] From V$system_Event Se, V$event_Name n z}5'TV = ^ Where n.Name = Se.Event(+) 2 ( ux And n.Name In c:z}$DK&' ('checkpoint completed', 'log file switch (checkpoint incomplete)'); Qw % 0 z9#jXC#OdN checkpoint completed等待检查点的完成; =g@hh)3wP log file switch (checkpoint incomplete) 如果紧接着的一个日志切换检查点发生，前面日志切换检查点尚未完成，这时，前面的检查点会终止，后面的检查点得从头再来，导致更多的I/O操作却不能缩短实例恢复的时间； G Eb)nHQq Ø Select * x i\uLu?i From V$sysstat V |0 UwS\n Where Name In ^h|' \- d\ ('background checkpoints started', 'background checkpoints completed')； naB[0I& N 0$ 4 9 X background checkpoints started 自实例启动以来开始过的检查点； /L[: C=u background checkpoints completed自实例启动以来已经成功完成的检查点； veE8 N~0N. 这两个值的差异值或者差异值减一等于未完成的日志切换检查点； +~/zCJ; F Ø Statspack中与检查点性能相关的数据有：实例活动统计（Instance Activity Stats）的background checkpoints started 和background checkpoints completed； Ox 43 (S0~ Ø 当出现日志切换检查点未完成事件时，报警日志文件中会有记录，大致的描述如下：Thread x cannot allocate new log, sequence y Checkpoint not complete; C"mb-n 7s Ø 初始参数LOG_CHECKPOINTS_TO_ALERT置为TRUE时，每一个检查点的性息都可以在报警日志文件中找到； q{JD] A: · 调整检查点性能有下面两种方法（加大日志文件，调整初始参数）： mg;AcAS.o, Ø 每个日志切换时会发生完全检查点，加大日志文件可以使检查点的间隔更大些，以减少检查点未完成这个事件发生频率； nMbV{h , Ø 增大日志文件方法是，先增加新的更大日志文件组，再删除小的日志文件组； u1k bWbHu( Ø 为了在实例恢复性能以及检查点活动负担间达到平衡，调整日志文件大小，使日志切换的发生间隔在20到30分钟之间为宜； 6% xl} z]o Ø 在9i中，ORACLE建议只需调整FAST_START_MTTR_TARGET这个参数，含义是实例失败时的平均恢复时间（秒），取值范围为0~3600，这个参数可以用Alter System语句动态改变，为零时取消这个功能，这个参数通常是用另两个参数来实现的：FAST_START_IO_TARGET（实例失败时的平均赃块数）, LOG_CHECKPOINT_INTERVAL（实例失败时的平均日志OS块数）； sR0nY8 @F Ø 设置上面的参数后，可以用V$INSTANCE_RECOVERY这个视图观察效果：TARGET_MTTR（平均恢复时间，通常等于上面参数指定的值，如果因为服务器资源的限制可能稍大于上面的参数值） ESTIMATED_MTTR（评估的当前时刻实例失败后的恢复用时）； 第七章 调整日志机制 4.调整在线日志文件 >j?u I6Uw 5*r6#[S \ g s 3}rW 调整在线日志文件 {mQJ6 G'ny · 所有的日志条最后都由LGWR写到在线日志文件，在线日志文件的损坏可能导致丢失已提交的事务，因此通常都需要给每个日志组安排两个或更多个成员，调整在线日志文件一方面要优化运行性能，另一方面要优化恢复性能； SOL=3hfb ^ · 有两种测量在线日志文件的性能的方法：系统事件，OS工具： , L;vN6 ~ Ø Select Event, Total_Waits, Average_Wait 11sW$@xs 9 From V$system_Event 4#w^P M8} Where Event In ('log file switch completion', 'log file parallel write'); Ul Iw&U ?r log file switch completion LGWR等待日志切换的完成 * zWn4BckN log file parallel write LGWR等待日志条从日志缓存写到在线日志文件操作的完成 [ \ 1 l4C 这两个等待事件的数量和平均时间很高时，表明在线日志文件存在性能瓶颈； K oJG! Rm Ø 一些OS工具可以查看到磁盘IO的活动情况，如UNIX下的SAR和IOSTAT命令，WINDOWS下的任务管理器；（可用V$LOGFILE查到在线日志文件的对应位置）； * lAdS] I · 改进在线日志文件相关的性能： P;&p[ [ 7 Ø 减少磁盘竞争：将在线日志文件与其它文件（数据文件，控制文件，归档日志文件）放在不同的磁盘上 ( $> 0&w Ø 最大化日志产能：将在线日志文件移到更快的设备，如裸设备上，尽量避免使用RAID设备存放在线日志文件； >i N % Uz jqWvLBU! [u QZD1 七章 调整日志机制 5.调整归档 LB7I` W 4 CT9-2 UC )% w8>1 }c 调整归档 B R j KV · 归档进程用来将在线日志文件的内容复制到归档目录，归档日志文件用于媒体失败或用户错误时执行恢复；归档机制是备份与恢复的重要组成部分，也是IO性能问题的一个重要来源； ^ ) ^|;C\` · 测量归档的性能（归档目录空间不足，归档进程太慢） b I6wE'h Ø 当归档目录所在磁盘没空间时，整个系统会被挂住，系统写一条出错信息进报警日志，描述类似于：ORA-16038 log x sequence# y cannot be archived; 这时管理员可以手工临时改变归档目录（Alter system archive log all to …）或者移出部分归档以增加归档目录所在磁盘的可用空间； 00 a Ø 在归档模式下，日志切换成功前，LGWR不仅可能要等待即将要被重写的日志文件上的检查点的完成，还可能要等待针对这个文件的归档的完成，后面这个等待事件可以通过下面的语句查询得到： B\ >}X_ \4 Select n.Name, Se.Total_Waits, Se.Average_Wait _XN R u m4 From V$system_Event Se, V$event_Name n )w zs~ Fn/ Where n.Name = 'log file switch (archiving needed)' !X A% [u And Se.Event(+) = n.Name; Z 6( [/ n · 改进归档的性能 EJ;0ypbG Ø 当确定归档是一个性能瓶颈时，可以考虑用下面的方法来处理（加多日志组，加大日志文件，选择多个归档目标，启动更多的归档进程）； C\ ^< v& Ø 加多日志组可以减少LGWR在日志切换时对归档的等待，在一般的OLTP系统中，5~20个日志组是比较合适的； 4OZ 5hH h Ø 加大日志文件也能达到减少日志切换时LGWR对归档的等待这个目标，加大日志文件会使日志切换的间隔变得更长，这种类型的检查点间隔也变得更长，前面曾提到，Oracle推荐检查点间隔在20~30分钟为宜，为解决这个矛盾，可以通过适当设置FAST_START_MTTR_TARGET这个参数来达到这个目标； VO;UV $ $ Ø 为了减少因归档目标磁盘已满而使系统被挂起的可能性，以及使用归档日志的多个冗余备份，可以通过下面的初始参数指定多个归档目标和归档最小成功个数； BOi z ~h6 LOG_ARCHIVE_DEST 首选的归档目标 h[ZN >T LOG_ARCHIVE_DUPLEX_DEST 第二个归档目标 0.B U fuuh LOG_ARCHIVE_DEST_n 指定最多可到十个的冗余归档目标（企业版才有，标准版中没有，和上面的参数互相排斥） LOG_ARCHIVE_DEST_STATE_n 同上面的参数相对应，可选值有enable与defer F2PLy q LOG_ARCHIVE_MIN_SUCCEED_DEST 在多个归档目标的配置下用于指定归档最小成功的个数，默认值是1，取值范围是：1-2（LOG_ARCHIVE_DUPLEX_DEST生效时）或1-5（LOG_ARCHIVE_DEST_n生效时）； _ [ {:!?-? 上面的n的取值在1~10之间； qv0 DrL ,3 相关的视图有V$ARCHIVE_DEST, V$ARCHIVE_DEST_STATUS, V$ARCHIVED_LOG; DNW2;i Ø 如果出现LGWR等待归档时，LGWR可以启动更多的ARCn进程来处理归档任务； Hr 也可以通过更改初始参数LOG_ARCHIVE_MAX_PROCESSES（默认值为1，取值范围2~10）来指定实例启动时就开始运行的归档进程的个数（通常这个值应该等于归档目标的个数）； ^QXw[th!d 可以通过V$ARCHIVE_PROCESSES查看到归档进程的状态以及它正在处理的日志序号； L'\/)!cEd

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/119501/viewspace-609379/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/119501/viewspace-609379/