oracle 调优

bestu

　　Oracle 项目实施中的若干问题及注意事项
一． 数据库规划首先应该估计大致的数据库物 理尺寸，以便规划磁盘的分区及大小。表及索引的存储容量估算是根据其记录长度及估算 的最大记录数确定的。数据库表如何分布，规划相应的表空间注意： 1． 把频繁访问的表 尽量放置到不同的表空间中 2． 把索引和表数据分开放置到不同的表空间中 3． 高频率 insert 的对象分成一组，存在对应的 tablespace 中 4． 数据和 redo log 分开放。 5． 同一 个 tablespace 中的表（或索引）的 extent 大小最好成倍数关系，有利于空间的重利用和 减少碎片。 6． 回滚段建在专用表空间中， initial 及 next 存储参数的值是相等的，同时还 是 DB BLOCK> 二． 内存规划 RAM 内存的分配根据应用的类型不同而 相应调整，留给 unix 系统工作的内存至少 20％。 OLTP: SGA 占 65% PGA 占 15% UNIX 占 20% OLAP: SGA 占 30% PGA 占 50% UNIX 占 20% DB BUFFER 命中率小于 90％考 虑增加 cache 脚本：查看 DB buffer pool 的命中率(应>90%) select 1(phy.value/(cur.value+con.value)) from v$sysstat cur, v$sysstat con, v$sysstat phy where cur.name ='db block gets' AND con.name = 'consistent gets' AND phy.name = 'physical reads'; SHARE POOL 命中率小于 75％考虑增加 cache 脚本： --查看 library cache 的命 中率(应高于 90％) select gethitratio from v$librarycache; --查看 library cache 中> 三． IO 调整数据库最大的调整 就是 IO 调整，这是影响性能最主要的方面。首先通过 UNIX 命令发现是否有 IO 等待。 Rp1#Sar -u 2 10 即每隔 2 秒检察一次，共执行 20 次。 示例返回： 18:26:32 %usr %sys %wio %idle 18:26:34 80 9 12 0 18:26:36 78 11 11 0 18:26:38 78 9 13 1 18:26:40 81 10 9 1 18:26:42 75 10 14 0 18:26:44 76 8 15 0 18:26:46 80 9 10 1 18:26:48 78 11 11 0 18:26:50 79 10 10 0 18:26:52 81 10 9 0 Average 79 10 11 0 其中 的%usr 指的是用户进程使用的 cpu 资源的百分比，%sys 指的是系统资源使用 cpu 资源的 百分比，%wio 指的是等待 io 完成的百分比，这是值得我们观注的一项，%idle 即空闲的百 分比。如果 wio 列的值很大，如在 35%以上，说明你的系统的 IO 存在瓶颈，你的 CPU 花 费了很大的时间去等待 IO 的完成。Idle 很小说明系统 CPU 很忙。像我的这个示例，可以 看到 wio 平均值为 11 说明 io 没什么特别的问题，而我的>当你的系统存在 IO 的问题，可以从以下几个方面解决 ♀联系相应的操作 系统的技术支持对这方面进行优化，比如 HA 在划定卷组时的条带化等方面。 ♀查找 Oracle 中不合理的 sql 语句，对其进行优化 ♀对 Oracle 中访问量频繁的表除合理建索引外， 再就是把这些表分表空间存放以免访问上产生热点，再有就是对表合理分区。  四． 性能 监控首先，如何找到占有机器性能特别大的 Oracle 的 session 及其执行的语句。 IBM AIX 可以用 topas 些外可以使用 ps 的命令。通过这些程序我们可以找到点用系统资源特别大的 这些进程的进程号，我们就可以通过以下的 sql 语句发现这个 pid 正在执行哪个 sql，这个 sql 最好在 pl/sql developer,toad 等软件中执行, 把中的 spid 换成你的 spid 就可以了。 SELECT a.username, a.machine, a.program, a.sid, a.serial#, a.status, c.piece, c.sql_text FROM v$session a, v$process b, v$sqltext c WHERE b.spid= AND b.addr=a.paddr AND a.sql_address=c.address(+) ORDER BY c.piece 我们就可以把得到的这个 sql 分析一下， 看一下它的执行计划是否走索引，对其优化避免全表扫描，以减少 IO 等待，从而加快语句 的执行速度。迅速发现 Oracle Server 的性能问题的成因，我们可以求助于 v$session_wait 这个视图，看系统的这些 session 在等什么，使用了多少的 IO。以下是我 提供的参考脚本：脚本说明：查看占 io 较大的正在运行的 session SELECT se.sid, se.serial#, pr.SPID, se.username, se.status, se.terminal, se.program, se.MODULE, se.sql_address, st.event, st.p1text, si.physical_reads, si.block_changes FROM v$session se, v$session_wait st, v$sess_io si, v$process pr WHERE st.sid=se.sid AND st.sid=si.sid AND se.PADDR=pr.ADDR AND se.sid>6 AND st.wait_time=0 AND st.event NOT LIKE '%SQL%' ORDER BY physical_reads DESC 对检索出的结果的几点说明： 1、我是按每 个正在等待的 session 已经发生的物理读排的序，因为它与实际的 IO 相关。 2、你可以看 一下这些等待的进程都在忙什么，语句是否合理？ Select sql_address from v$session where sid=; Select * from v$sqltext where address=; 执行以上两个语句便可以得到这个 session 的语句。你也以用>3、 应观注一下 event 这列，这是我们调优的关键一列，下面对常出现的 event 做以简要的说 明： a、buffer busy waits，free buffer waits 这两个参数所标识是 dbwr 是否够用的问题， 与 IO 很大相关的，当 v$session_wait 中的 free buffer wait 的条目很小或没有的时侯，说 明你的系统的 dbwr 进程决对够用，不用调整；free buffer wait 的条目很多，你的系统感觉 起来一定很慢，这时说明你的 dbwr 已经不够用了，它产生的 wio 已经成为你的数据库性 能的瓶颈，这时的解决办法如下： a.1 增加写进程，同时要调整 db_block_lru_latches 参 数示例：修改或添加如下两个参数 db_writer_processes=4 db_block_lru_latches=8 a.2 开 异步 IO，即 disk_asynch_io=true。 b、db file sequential read，指的是顺序读，即全表扫 描，这也是我们应该尽量减少的部分，解决方法就是使用索引、sql 调优，同时可以增大 db_file_multiblock_read_count 这个参数。 c、db file scattered read,这个参数指的是通过 索引来读取，同样可以通过增加 db_file_multiblock_read_count 这个参数来提高性能。 d、 latch free,与栓相关的了，需要专门调节。 e、其他参数可以不特别观注。 五． 备份备份前 要作的工作：归档 redo log。四种备份： 1.backup set：备份集合中的文件（是压缩过的） 不可以被 oracle 实例直接使用，需要 rman 恢复到可用的格式。 2.映像拷贝：用 rman 的 copy 命令（不是操作系统程序，是 oracle 的一个进程）拷贝数据文件、控制文件和存档日 志。映像拷贝文件可以被 oracle 立即使用。 3.操作系统备份：之前使用>4.逻辑备份：exp、imp（可以针对某一对 象进行备份）。某项目采用的备份方案（增量备份）：星期天晚上 - level 0 backup performed performed performed performed 星期一晚上 - level 2 backup performed 星期三晚上 - level 1 backup performed 星期五晚上 - level 2 backup performed 星期二晚上 - level 2 backup 星期四晚上 - level 2 backup 星期六晚上 - level 2 backup 星期天晚上 - level 0 backup performed 脚本： Level 0 是增量备份策略的 基础- RMAN> run { 2> allocate channel dev1 type disk; 3> backup 4> incremental level 0 5> filesperset 4 6> format '/oracle/backups/sunday_level0_%t' 7> (database); 8>> 六． 常见错误解决 · ORA-01650:unable to extend rollback segment NAME by NUM intablespace NAME 产生原因：上述 ORACLE 错误为回滚段表空间不足引起的，这也是 ORACLE 数据管理员最常见的 ORACLE 错误信息。当用户在做一个非常庞大的数据操作 导致现有回滚段的不足，使可分配用的回滚段表空间已满，无法再进行分配，就会出现上 述的错误。 · ORA-01652:unable to extend temp segment by num in tablespace name 产 生原因：ORACLE 临时段表空间不足，因为 ORACLE 总是尽量分配连续空间，一但没有 足够的可分配空间或者分配不连续就会出现上述的现象。 · ORA-01628:max # of extents num reached for rollback segment num 产生原因：这种错误通常为一个回滚段和一个表 空间已经达到 MAXEXTENTS 参数设置的极限。要注意的是这个 MAXEXTENTS 不是该回 滚段或表空间的硬件极限，硬件极限取决于数据库创建时在 init.ora 文件中指定的 DB_BLOCK_SIZE 参数的值。 · ORA-01688:unable to extend table name.name partition NAME by NUM in tablespace NAME 产生原因：指定的 tablespace 空间已经被占用满， 无法扩展。 · ORA-00600:internal error code,arguments:[num],[?],[?],[?],[?] 产生原因：这 种错误通常为 ORACLE 的内部错误，只对 OSS 和 ORACLE 开发有用。ORA-600 的错误 经常伴随跟踪文件的状态转储（系统状态和进程状态），系统状态存储将包括 ORACLE RDBMS 持有的当前对象的信息，进程状态转储则将显示特殊进程持有的对象，当进程符 合了某错误条件时，经常是由于一些信息取自它持有的一个块，如果我们知道这些错误进 程持有的块，就容易跟踪问题的来源。 · ORA-01578:Oracle data block corrupted(file # num,block # num) 产生原因：当 ORACLE 访问一个数据块时，由于 1、硬件的 I/O 错误； 2、操作系统的 I/O 错误或缓冲问题；3、内存或 paging 问题；4、ORACLE 试图访问一个 未被格式化的系统块失败；5、数据文件部分溢出等上述几种情况的一种引起了逻辑坏块 或者物理坏块，这时就会报 ORA-01578 的错误。实际中性能优化最根本的出现点也都集 中在 IO，这是影响性能最主要的方面，由系统中的等待去发现 Oracle 库中的不足、操作 系统某些资源利用的不合理是一个比较好的办法，以上是我的一点实践经验与大家分享， 欢迎批评指正。