Oracle 项目实施中的若干问题及注意事项
一. 数据库规划首先应该估计大致的数据库物 理尺寸,以便规划磁盘的分区及大小。表及索引的存储容量估算是根据其记录长度及估算 的最大记录数确定的。数据库表如何分布,规划相应的表空间注意: 1. 把频繁访问的表 尽量放置到不同的表空间中
2. 把索引和表数据分开放置到不同的表空间中
3. 高频率 insert 的对象分成一组,存在对应的 tablespace 中
4. 数据和 redo log 分开放。
5. 同一 个 tablespace 中的表(或索引)的 extent 大小最好成倍数关系,有利于空间的重利用和 减少碎片。
6. 回滚段建在专用表空间中, initial 及 next 存储参数的值是相等的,同时还 是 DB BLOCK SIZE 的倍数。每个回滚段的 minextents 设为 20,optimal 参数的值保证回 滚段缩小时不低于 20 个 extents。
二. 内存规划 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 中 reloads 比率(应小于 1%) select sum(reloads)/sum(pins) from v$librarycache; --查看数据字典命中 率(应小于 15%,因为刚 startup 时 no data 故要 applicatin 运行一段时间再查看,不可能 为 0) select sum(getmisses)/sum(gets) from v$rowcache;
三. 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 没什么特别的问题,而我的 idle 值为零,说明我的 cpu 已经 满负荷运行了。
当你的系统存在 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 的语句。你也以用 alter system kill session 'sid,serial#';把这个 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.操作系统备份:之前使用 alter tablespace begin backup,之后 alter tablespace end backup
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> release channel dev1; 9> } Level 1 RMAN> run { 2> allocate channel dev1 type disk; 3> backup 4> incremental level 1 5> filesperset 4 6> format '/oracle/backups/sunday_level1_%t' 7> (database); 8> release channel dev1; 9> } Level 2 RMAN> run { 2> allocate channel dev1 type disk; 3> backup 4> incremental level 2 5> filesperset 4 6> format '/oracle/backups/sunday_level2_%t' 7> (database); 8> release channel dev1; 9> }
六. 常见错误解决
· 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 库中的不足、操作 系统某些资源利用的不合理是一个比较好的办法,以上是我的一点实践经验与大家分享, 欢迎批评指正。