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 库中的不足、操作 系统某些资源利用的不合理是一个比较好的办法，以上是我的一点实践经验与大家分享， 欢迎批评指正。
