Oracle rac进阶管理专家指导系列文档
Oracle恢复目录的管理使用简要
I. 使用恢复目录存储RMAN备份记录
- Oracle 官方建议把恢复目录建议于独立的数据库中。如果把恢复目录与其他一些数据混杂在某库中,若该库失败则恢复目录一起丢失,这将导致恢复异常困难。
- 在恢复目录中登记某个库被称作注册(registration).可以在恢复目录中注册多个目标库。举例来说,你可以注册数据库 prod1,prod2,和prod3在一个单独的由用户catowner拥有的目录中,而该目录位于一个叫catdb的数据库中。 因为RMAN通过DBID即数据库的身份证来分辨各个库。每个在恢复目录中注册过的目标库都有一个唯一的DBID.
- 恢复目录主要包括以下RMAN的使用情况信息:
l 数据文件和归档日志的备份集和备份片
l 数据文件的拷贝
l 归档日志及其拷贝
l 目标库中的表空间和数据文件
l 储存的脚本
l RMAN的永久性配置
- 恢复目录保存了目标库控制文件中重要的RMAN操作原数据。同步恢复目录保证与控制文件中当前信息同步。
- RMAN 创建快照控制文件,即临时控制文件,当每次需要做全局同步时。快照临时文件保证了RMAN同步时的一致性读。数据库服务进程保证同时只有一个快照临时文件的存在,这对于保证RMAN操作不受其他进程干扰是必要的。
- 丢失恢复目录将导致严重的恢复问题。如何备份恢复目录可参考一般数据库的备份方式。
- 关于恢复目录的兼容性,可以通过查询恢复目录用户模式下的rcver表了解参与恢复目录使用端的版本号,示例:
SQL> SELECT * FROM rcver;
VERSION
------------
08.01.05.00
09.00.01.00
10.02.01.00
只要是8i之后版本一般不存在兼容性问题。
II 管理恢复目录
创建恢复目录
管理恢复目录中的目标库记录
同步恢复目录
恢复目录模式下的控制文件管理
备份恢复目录
导入和导出恢复目录
增强恢复目录可用性
查询恢复目录视图
更新恢复目录
删除恢复目录
- 创建恢复目录,创建恢复目录分成三步:
- 配置恢复目录所在数据库
- 创建恢复目录拥有者
- 创建恢复目录本身
配置恢复目录数据库
若使用恢复目录,RMAN要求维护恢复目录所在模式。恢复目录储存在当前模式的默认表空间中,注意SYS不能是恢复目录的拥有者。我们强烈建议恢复目录数据库使用归档模式。同时必须分配足够的空间给恢复目录所在模式,恢复目录所占用的空间取决于使用恢复目录的目标数据库的数量。适当地为恢复目录库规划容量是必要的。应当保证恢复目录库和目标数据库的不占用同一磁盘。
创建目录拥有者
在合理配置恢复目录库后,我们来创建目录拥有者
使用目录库上的SYS帐号登录
假定当前有一个tool表空间来保存目录
使用temp临时表空间为用户默认临时表空间
如下步骤:
CONNECT SYS/oracle@catdb AS SYSDBA
SQL> CREATE USER rman IDENTIFIED BY cat
TEMPORARY TABLESPACE temp
DEFAULT TABLESPACE tools
QUOTA UNLIMITED ON tools;
同时我们要授予 recovery_catalog_owner 权限给用户,该角色拥有管理创建恢复目录的权限。
SQL> GRANT RECOVERY_CATALOG_OWNER TO rman;
创建恢复目录
在创建恢复目录用户后,使用RMAN建立恢复目录,操作如下:
$ rman
RMAN> CONNECT CATALOG rman/cat@catdb --以目录用户连接恢复目录库
RMAN> create catalog — 建议恢复目录
当然也可以指定使用的表空间:
RMAN> create catalog tablespace users;
成功建立恢复目录后,可以查询目录下已经存在的目录使用的基表。
SQL>select table_name from user_tables;
2. 管理恢复目录中的目标库记录
ü 在恢复目录中注册目标数据库
ü 在恢复目录中注销目标数据库
ü 在恢复目录中重置数据库
ü 在恢复目录中移除已删除的记录
在恢复目录中注册目标数据库
首先确定恢复目录库已经打开,从目标库主机登录:
$ rman TARGET / CATALOG rman/cat@catdb
若目标库未启动,首先启动到加载模式:
RMAN> STARTUP MOUNT;
注册目标库:
RMAN> REGISTER DATABASE;
RMAN会自动在恢复目录中记录目标库的各种信息,将目标库控制文件中的
元信息复制到恢复目录中,可以使用以下命令确认注册情况:
RMAN> REPORT SCHEMA;
Report of database schema
File Size(MB) Tablespace RB segs Datafile Name
---- ---------- ---------------- ------- -------------------
1 307200 SYSTEM NO /oracle/oradata/trgt/system01.dbf
2 20480 UNDOTBS YES /oracle/oradata/trgt/undotbs01.dbf
3 10240 CWMLITE NO ...
在恢复目录中登记备份文件
若有备份文件未在控制文件或恢复目录中存在对应的记录,则需要登记该文件,此处的(control file 为目标数据库control file)。
示例:
RMAN> CATALOG DATAFILECOPY '/disk1/old_datafiles/01_01_2003/users01.dbf';
RMAN> CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.dbf',
'/disk1/arch_logs/archive1_732.dbf';
RMAN> CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp';
在恢复目录中登记多个目标库
可以在一个恢复目录中注册多个目标库,前提是目标库的DBID唯一。
在恢复目录中注销目标库
可以使用命令: unregister database 在RMAN中注销目标数据库。当数据库被
注销,所有的RMAN记录都会丢失,所以要小心操作。
在恢复目录中移除已经删除的记录
在9i之后版本,RMAN在删除备份文件的同时会删除在恢复目录中的对应物记
录,而9i以前版本则只将对应物记录标志为delete.可以通过运行脚本
prgrmanc.sql来删除对应物记录,该脚本储存在($ORACLE_HOME/rdbms/admin)
目
录下。示例如下:
% sqlplus rman/cat@catdb
SQL> @?/rdbms/admin/prgrmanc.sql删过期备份信息
同步恢复目录
当恢复目录当前状态晚于数据库控制文件中的备份信息时,则需要使用同步恢复
目录,这种情况只会出现在一段时间使用恢复目录而一段时间不使用恢复目录的
情况下,造成的时间段差异。RMAN会在您做某些操作时自动完成同步,例如
Backup命令,当然你也可以手动同步: resync catalog .
管理控制文件
数据库参数CONTROL_FILE_RECORD_KEEP_TIME
决定了控制文件中记录可能被复
用的最短自然天数,因此你保证恢复目录在此期间完成同步,否则可能控制文件
中的记录丢失,则需要手动登记备份文件。CONTROL_FILE_RECORD_KEEP_TIME有
效期内需要定期同步。
备份恢复目录
备份恢复目录数据库十分重要,若恢复目录数据库丢失则所有的备份信息将丢
失,导致恢复十分困难。
备份恢复目录数据库与一般的数据库没有大的区别,以下为注意事项:
恢复目录数据库因该运行在归档模式下
使用备份策略冗余量大于一
在不同的介质上备份
不使用恢复目录记录备份信息
使用控制文件自动备份,rman中可以自动完成
结构图:
更新恢复目录
若您使用的恢复目录版本低于使用的客户端,则您需要更新恢复目录。举例来说
当前您使用了8.1版的客户端RMAN,而恢复目录是8.0版本的,则需要更新。
当恢复目录版本高于您使用的客户端,则upgrade catalog报错。更新操作实例如
下:
sqlplus> connect sys/oracle@catdb as sysdba;
sqlplus> grant TYPE to rman;
% rman TARGET / CATALOG rman/cat@catdb
UPGRADE CATALOG;
recovery catalog owner is rman
enter UPGRADE CATALOG command again to confirm catalog upgrade
UPGRADE CATALOG;
recovery catalog upgraded to version 09.02.00
DBMS_RCVMAN package upgraded to version 09.02.00
DBMS_RCVCAT package upgraded to version 09.02.00
删除恢复目录
当恢复目录不在需要时可以在所在数据库中彻底删除目录结构和数据,删除将丢
失所有注册过的备份信息,操作要小心。示例操作:
% rman TARGET / CATALOG rman/cat@catdb
Issue the DROP
CATALOG
command twice to confirm:
DROP CATALOG;
recovery catalog owner is rman
enter DROP CATALOG command again to confirm catalog removal
DROP CATALOG;
延迟块清除介绍
在Oracle中数据锁(这里主要指TX类型行锁)实际上是数据的属性,存储在块首部,称之为事务槽(ITL)。COMMIT操作的职责包括释放块上的锁,实际的释放方式即清除块上相应的事务槽,但这里存在一个性能的考量。设想一个UPDATE大量数据的操作,因为执行时间较长,一部分已修改的块已被缓冲池flush out写至磁盘,当UPDATE操作完成执行COMMIT操作时,则需要将那些已写至磁盘的数据块重新读入,这将消耗大量I/O,并使COMMIT操作十分缓慢;为了解决这一矛盾,Oracle使用了延迟块清除的方案,对待存在以下情况的块COMMIT操作不做块清除:
在更新过程中,被缓冲池flush out写至磁盘的块
若更新操作涉及的块超过了块缓冲区缓存的10%时,超出的部分块。
虽然COMMIT放弃对这些块的块清除(block cleanout)操作,但COMMIT操作仍会修改回滚段的段头,回滚段的段头包括了段中的事务的字典,COMMIT操作将本事务转化为非ACTIVE状态。
当下一次操作如SELECT,UPDATE,INSERT或DELETE访问到这些块时可能需要在读入后完成块清除,这样的操作称之为块延迟清除(deferred block cleanout);块延迟清除通过事务槽上的回滚段号,槽号等信息访问回滚段头的事务字典,若事务不再活跃或事务过期则完成清除块上的事务槽,事务槽清除后继续执行相应的操作。
块延迟清除的影响在SELECT操作过程中体现的最为明显。总结来说块延迟清除是COMMIT操作的一个延续,始终是一种十分轻微的操作,且该种操作是行级的,不会使段(Segment)的属性有所改变。
绑定变量介绍
Oracle在执行SQL语句时,普遍存在以下几个步骤:
- 当SQL语句首次执行,Oracle将确认该句语句的语法是否正确(语法解析Syntax parse)并进一步确认语句相关表和列的存在性等因素(语义解析semantic parse)以及优化器决定执行计划等步骤。整个过程称之为硬解析,硬解析消耗大量的CPU时间和系统资源。硬解析过多会有效降低系统性能。
- 若之前已进行过硬解析,且解析后的分析树和执行计划仍存在于共享池中,则同样的SQL仅需要软解析。软解析将输入的SQL语句转换为哈希代码,同共享池内哈希链表上的已有记录进行对比,找出对应的游标信息,使用已有的执行计划执行。
- 绑定变量,将实际的变量值代入SQL语句中。
- 执行SQL语句,查询语句将返回结果集。
不使用绑定变量的SQL语句,Oracle无法将它们视为相同的,如以下两句语句:
select * from emp where empno=1234
select * from emp where empno=5678 |
因为自由变量的不同,Oracle认为以上是2句不同的语句,则当第一条被硬解析后,第二条SQL执行时仍无法避免硬解析。实际在以上不使用绑定变量的情况中,只要自由变量有所改变则需要一次硬解析。这是强烈建议使用绑定变量的主要原因,使用绑定变量的语句变量的实际值仅在SQL执行的最后阶段被代入。如以下语句:
select * from emp where empno=:x |
该语句使用绑定值:x替代自由变量,在应用中语句可能以预编译或普通编译的方式存在,仅在执行阶段代入变量值,多次执行仅需要一次硬解析,较不使用绑定变量情况性能大大提升。
同时过多的硬解析还会引发共享池碎片过多的问题。因为每当需要硬解析一个SQL或者PLSQL语句时,都需要从shared pool中分配一块连续的空闲空间来存放解析结果。Oracle首先扫描shared pool查找空闲内存,如果没有发现大小正好合适的空闲chunk,就查找更大的chunk,如果找到比请求的大小更大的空闲chunk,则将它分裂,多余部分继续放到空闲列表中。因为过多的硬解析加剧了内存段分配的需求,这样就产生了碎片问题。系统经过长时间运行后,就会产生大量小的内存碎片。当请求分配一个较大的内存块时,尽管shared pool总空闲空间还很大,但是没有一个单独的连续空闲块能满足需要。这时,就可能产生 ORA-4031错误。
通常我们可以通过以下SQL语句将系统中非绑定变量的语句找出:
SELECT substr(sql_text,1,40) “SQL”,
count(*) , sum(executions) “TotExecs” FROM v$sqlarea WHERE executions < 5 –-语句执行次数 GROUP BY substr(sql_text,1,40) HAVING count(*) > 30 –-所有未共享的语句的总的执行次数 ORDER BY 2; |
以上语句在实际使用中substr函数截取到的字符串长度需要视乎实际情况予以变化。
对于非绑定变量且短期内无法修改的应用,Oracle存在参数cursor_sharing可以改善其表现。cursor_sharing默认为exact,对使用自由变量的语句不做额外处理;当设为force时,非绑定变量的SQL语句被进一步处理以达到共享SQL的目的,但以上处理步骤同样要消耗一定的CPU时间;当设为similar时,若数据库存在语句相关统计信息则其表现如exact,若无统计信息则表现为force。cursor_sharing参数是Oracle针对无法修改的非绑定变量应用所提出的折中方案,但cursor_sharing为force值时存在一定SQL引发bug或语句无效的情况,且额外的处理操作同样需要消耗一定量的CPU时间和系统资源。故针对系统性能的最优方案往往是直接修改应用代码,使用绑定变量特性。
UNDO表空间监控说明
在Oracle 10g版本中可以使用V$UNDOSTAT视图用于监控实例中当前事务使用UNDO表空间的情况。视图中的每行列出了每隔十分钟从实例中收集到的统计信息。每行都表示了在过去7*24小时里每隔十分钟UNDO表空间的使用情况,事务量和查询长度等信息的统计快照。
UNDO表空间的使用情况会因事务量变化而变化,一般我们在计算时同时参考UNDO表空间的平均使用情况和峰值使用情况。
以下SQL语句用于计算过去7*24小时中UNDO表空间的平均使用量:
select ur undo_retention, dbs db_block_size, ((ur * (ups * dbs)) + (dbs * 24)) / 1024 / 1024 as “M_bytes” from (select value as ur from v$parameter where name = ‘undo_retention’), (select (sum(undoblks) / sum(((end_time – begin_time) * 86400))) ups from v$undostat), (select value as dbs from v$parameter where name = ‘db_block_size’) |
以下SQL语句则按峰值情况计算UNDO表空间所需空间:
select ur undo_retention, dbs db_block_size, ((ur * (ups * dbs)) + (dbs * 24)) / 1024 / 1024 as “M_bytes” from (select value as ur from v$parameter where name = ‘undo_retention’), (select (undoblks / ((end_time – begin_time) * 86400)) ups from v$undostat where undoblks in (select max(undoblks) from v$undostat)), (select value as dbs from v$parameter where name = ‘db_block_size’) |
需要注意因RAC情况下一般存在2个UNDO表空间,视乎实际情况分别在2个实例中执行以上查询。
一般来说为了尽可能维护日常业务的正常运行,我们建议按照峰值情况估算和分配UNDO表空间的大小,虽然这样存在存储空间上的浪费,但是可以避免UNDO表空间不足所带来的问题。
同时我们也可以使用DBA_UNDO_EXTENTS视图实时监控UNDO表空间的使用情况:
select sum(bytes / 1024 / 1024), status, tablespace_name from dba_undo_extents group by status, tablespace_name; |
该查询将返回以STATUS分组的各状态回滚信息所使用的空间量,一般存在三种STATUS状态:EXPIRED,UNEXPIRED,ACTIVE。ACTIVE表示目前仍活跃的事务相关回滚信息,UNEXPIRED表示虽然事务已经结束但回滚信息保留的时间仍未超过实例参数UNDO_RETENTION所设定的值,EXPIRED表示回滚信息保留时间已超过UNDO_RETENTION所设定的值。
在UNDO表空间未启用guarantee选项的情况下(当前使用情况),新事务的回滚空间分配遵循以下依据:
a) 寻找不存在ACTIVE区间的回滚段,若没有则创建一个新的回滚段,若空间不允许生成新段,则返回错误。
b) 如果有一个回滚段被选中,但是其中空闲的空间并不足以存储该事务的回滚信息,那么它将尝试创建区间,如果表空间上没有空间,那么将会进入下一步。
c) 如果创建新区间失败,它将会搜索其他回滚段中的EXPIRED区间并重用。
d) 如果其他回滚段中没有EXPIRED区间可使用,那么它会继续搜索其他回滚段中UNEXPIRED区间并重用,注意事务不会重用本回滚段中的UNEXPIRED区间,故UNEXPIRED的回滚空间仅部分可以为Oracle重用;若仍得不到所需则返回错误。
当我们观察到ACTIVE回滚信息所占用空间很大时,说明系统目前运行的事务繁忙。因目前未启用UNDO表空间的guarantee选项,故EXPIRED的全部回滚空间与UNEXPIRED的部分回滚空间可以为Oracle复用,在实时监控时主要观察ACTIVE状态回滚信息使用的空间即可。
在系统相关业务不变的情况下,我们通过计算UNDO表空间的峰值使用情况即可最大程度完善UNDO表空间的配置;而当系统处于业务调整阶段,如新的业务加入或业务时段调整情况下,则需要进一步实时监控UNDO表空间使用情况,以满足动态调整需求。
undo自动调优介绍
Oracle 10gr2的后续版本中添加了撤销(UNDO)信息最短保留时间段自动调优的特性,不再仅仅依据参数UNDO_RETENTION的设定,其调优原则如下:
l 当撤销表空间(UNDO TABLESPACE)大小固定,Oracle将根据表空间的大小和实际的系统负载动态调整撤销信息保存时间,该最短保存时间的具体长短基于撤销表空间大小的一定比例值公式换算后获得;它总是比设定的UNDO_RETENTION大,当撤销表空间大量空闲情况下可能远远大于UNDO_RETENTION。
l 当撤销表空间设定为自动扩展空间情况下,Oracle将动态调整撤销信息最短保留时间为该时段最长查询时间(MAXQUERYLEN)加上300秒或参数UNDO_RETENTION间的较大者,即MAX((MAXQUERYLEN+300),UNDO_RENTION);同样的,该最短保存时间可能远远大于设定的UNDO_RETENTION。
在自动调整情况下,实际的撤销信息最短保留时间可以通过查询V$UNDOSTAT视图上的TUNED_UNDORETENTION列获得。
在无法就撤销表空间做相应修改的情况,我们可以通过修改隐式参数” _UNDO_AUTOTUNE”为FALSE关闭该自动调优特性。以上设定生效后,V$UNDOSTAT视图上TUNED_UNDORETENTION列不再更新,且撤销信息最短保留时间固定为参数UNDO_RETENTION的设定值。该参数可以不用重启数据库而动态设置生效。
Oracle Supplemental 补全日志介绍
Oracle补全日志(Supplemental logging)特性因其作用的不同可分为以下几种:最小(Minimal),支持所有字段(all),支持主键(primary key),支持唯一键(unique),支持外键(foreign key)。包括LONG,LOB,LONG RAW及集合等字段类型均无法利用补全日志。
最小(Minimal)补全日志开启后可以使得logmnr工具支持链式行,簇表和索引组织表。可以通过以下SQL检查最小补全日志是否已经开启:
SELECT supplemental_log_data_min FROM v$database; |
若结果返回YES或IMPLICIT则说明已开启最小补全日志,当使用ALL,PRIMARY,UNIQUE或FOREIGN补全日志时最小补全日志默认开启(即检查结果为IMPLICIT)。
一般情况下我们在使用逻辑备库时启用主键和惟一键的补全日志,而有时表上可能没有主键,惟一键或唯一索引;我们通过以下实验总结这种情况下Oracle的表现。
首先建立相关的测试表:
alter database add supplemental log data (primary key,unique index) columns ;
create table test (t1 int , t2 int ,t3 int ,t4 int ); alter table test add constraint pk_t1 primary key (t1); –添加主键 随后使用循环插入一定量的数据 update test set t2=10; commit; — 更新数据 |
使用LOGMNR工具分析之前的操作,可以看到REDO中记录的SQL形式如下:
update “SYS”.”TEST” set “T2” = ’10’ where “T1” = ’64’ and “T2” = ’65’ and ROWID = ‘AAAMiSAABAAAOhiAA/’; |
其中where字句后分别记录了主键值,被修改字段的值和原行的ROWID。
现在我们将原表上的主键去掉来观察。
alter table test drop constraint pk_t1 ;
update test set t2=11; commit; — 更新数据 使用LOGMNR分析可以发现,REDO中的SQL记录如下: update “SYS”.”TEST” set “T2” = ’11’ where “T1” = ‘1’ and “T2” = ’10’ and “T3” = ‘3’ and “T4” = ‘4’ and ROWID = ‘AAAMiSAABAAAOhiAAA’; |
当没有主键的情况下,where子句后记录了所有列值和ROWID。
以下实验在存在唯一索引情况下的表现
create unique index pk_t1 on test(t1); update test set t2=15; commit; 使用LOGMNR分析可以发现,REDO中的SQL记录如下: update “SYS”.”TEST” set “T2” = ’15’ where “T1” = ‘9’ and “T2” = ’11’ and “T3” = ’11’ and “T4” = ’12’ and ROWID = ‘AAAMiSAABAAAOhiAAI’; 以上是t1列有唯一索引但不限定not null的情况,下面我们加上not null限制 alter table test modify t1 not null; update test set t2=21; commit; 使用LOGMNR分析可以发现,REDO中的SQL记录如下: update “SYS”.”TEST” set “T2” = ’21’ where “T1” = ‘2’ and “T2” = ’15’ and ROWID = ‘AAAMiSAABAAAOhiAAB’; |
如以上SQL所示,在存在唯一索引的情况下where子句后仍记录了所有列和ROWID;在存在唯一索引和非空约束的情况下表现与存在主键的情况一致。
当某个表上的列数量较多时且没有主键或唯一索引和非空约束的情况下,开启补全日志可能导致重做日志总量大幅提高。
首先建立一个存在250列的表:
Drop table test; create table test ( t1 varchar2(5), t2 varchar2(5), t3 varchar2(5), t4 varchar2(5), …t250 varchar2(5))
insert into test values (‘TEST’,’TEST’ ……); commit; –将255个列填入数据 alter database drop supplemental log data (primary key,unique index) columns; –关闭补全日志 set autotrace on; update test set t2=’BZZZZ’ where t1=’TEST’; commit; 可以从自动跟踪信息中看到,本条更新产生了516的重做量。 alter database add supplemental log data (primary key,unique index) columns; –重新开启补全日志 update test set t2=’FSDSD’ where t1=’TEST’; 跟踪信息显示产生了3044的重做量。 |
补全日志因作用域的不同又可分为数据库级的和表级的。表级补全日志又可以分为有条件的和无条件的。有条件限制的表级补全日志仅在特定列被更新时才会起作用,有条件限制的表级补全日志较少使用,这里我们不做讨论。
下面我们来观察无条件限制表级补全日志的具体表现:
alter database drop supplemental log data (primary key,unique index) columns;
alter table test add supplemental log data (primary key,unique index) columns; update test set t2=’ZZZZZ’; commit; 使用LOGMNR工具查看redo中的SQL: 可以发现where子句之后包含了所有列值。 delete test; commit; 使用LOGMNR工具查看redo中的SQL: delete from “SYS”.”TEST” where “T1” = ‘TEST’ and “T2” = ‘ZZZZZ’ and “T3” = ‘TEST’ and “T4” = ‘TEST’ and “T5” …… delete操作同样在where子句之后包含了所有列值。 又我们可以针对表上字段建立特定的补全日志组,以减少where子句后列值的出现。 alter table test drop supplemental log data (primary key,unique index) columns; –关闭表上原先的补全日志 alter table test add supplemental log group test_lgp (t1 ,t2,t3,t4,t5,t6,t12,t250) always; –创建补全日志组 update test set t2=’XXXXX’ ; commit; 使用LOGMNR工具查看redo中的SQL: update “SYS”.”TEST” set “T2” = ‘XXXXX’ where “T1” = ‘TEST’ and “T2” = ‘TEST’ and “T3” = ‘TEST’ and “T4” = ‘TEST’ and “T5” = ‘TEST’ and “T6” = ‘TEST’ and “T12” = ‘TEST’ and “T250” = ‘TEST’ and ROWID = ‘AAAMieAABAAAOhnAAA’; 如上所示重做日志中正确地显示了UPDATE操作中用户指定的字段值。 delete test; 使用LOGMNR工具查看redo中的SQL: delete from “SYS”.”TEST” where “T1” = ‘TEST’ and “T2” = ‘XXXXX’ and “T3” = ‘TEST’ …… delete操作在重做日志中仍然保留了所有列值。 |
针对字段较多的表,我们在能够以多个列保证数据唯一性且非空的情况下(即应用概念上的主键)来指定表上的补全日志组,以减少update操作时所产生的重做日志,而对于delete操作则无法有效改善。
PMON: TERMINATING INSTANCE DUE TO ERROR 600 on 8i
Alert logfile reported as below:
********************* Wed May 27 13:11:47 2009 Errors in file /u01/app/oracle/admin/proa021/udump/proa021_ora_9533.trc: ORA-07445: exception encountered: core dump [memset()+116] [SIGSEGV] [Address not mapped to object] [0] [] [] From Trace file ******************** Dump file /u01/app/oracle/admin/proa021/udump/proa021_ora_9533.trc Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production With the Partitioning option JServer Release 8.1.7.4.0 - Production ORACLE_HOME = /u01/app/oracle/product/817proa021 System name: SunOS Node name: v08k01 Release: 5.8 Version: Generic_117350-38 Machine: sun4u Instance name: proa021 Redo thread mounted by this instance: 1 Process Info ****************** Oracle process number: 117 Unix process pid: 9533, image: oracle@v08k01 (TNS V1-V3) Error ********* 2009-05-27 13:11:47.847 ksedmp: internal or fatal error ORA-07445: exception encountered: core dump [memset()+116] [SIGSEGV] [Address not mapped to object] [0] [] [] Current SQL(Current SQL statement for this session) *********************************************************************** : SELECT COUNT(PO_LINE_ID) FROM PO_LINES_INTERFACE WHERE PO_HEADER_ID = :b1 Call Stack functions ************************* ksedmp <- ssexhd <- sigacthandler <- memset ##################################################################################### From Alert logfile ********************* Wed May 27 13:18:39 2009 Errors in file /u01/app/oracle/admin/proa021/bdump/proa021_pmon_9584.trc: ORA-00600: internal error code, arguments: [1115], [], [], [], [], [], [], [] Wed May 27 13:18:56 2009 Errors in file /u01/app/oracle/admin/proa021/bdump/proa021_pmon_9584.trc: ORA-00600: internal error code, arguments: [1115], [], [], [], [], [], [], [] From Tracefile ******************* Dump file /u01/app/oracle/admin/proa021/bdump/proa021_pmon_9584.trc Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production With the Partitioning option JServer Release 8.1.7.4.0 - Production ORACLE_HOME = /u01/app/oracle/product/817proa021 System name: SunOS Node name: v08k01 Release: 5.8 Version: Generic_117350-38 Machine: sun4u Instance name: proa021 Redo thread mounted by this instance: 1 Process Info **************** Oracle process number: 2 Unix process pid: 9584, image: oracle@v08k01 (PMON) Error ******** 2009-05-27 13:18:39.766 ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [1115], [], [], [], [], [], [], [] Call Stack Functions: **************************** ksedmp <- kgeriv <- kgesiv <- ksesic0 <- kssdch <- ksuxds <- kssxdl <- kssdch <- ksudlp <- kssxdl <- ksuxdl <- ksuxda <- ksucln <- ksbrdp <- opirip <- opidrv <- sou2o <- main <- start CURRENT SESSION'S INSTANTIATION STATE ********************************************************* current session=8c8fdfbc ---- Cursor Dump ------ Current cursor: 0, pgadep: 0 Cursor Dump: End of cursor dump END OF PROCESS STATE ******************** Cursor Dump ************************ Current cursor: 0, pgadep: 0 Cursor Dump: End of cursor dump ksedmp: no current context area
ERROR: ORA-600 [1115]
VERSIONS: versions 6.0 to 10.1
DESCRIPTION: We are encountering a problem while cleaning up a state object.
The State Object is already on free list or has the wrong parent State Object.
FUNCTIONALITY: Kernal Service State object manager
IMPACT:
POSSIBLE INSTANCE FAILURE
PROCESS FAILURE
NON CORRUPTIVE - No underlying data corruption.
SUGGESTIONS: This error may be reported as a direct result of another earlier problem.
Lot of bugs reported
Bug 3837965 : Abstract: ORA-7445'S AND 600'S LEADING UP TO DB CRASH
Comp Version: 8.1.7.4.0
Fixed In Version: 9.2.0.
-------------------------------------------------------------
Bug 3134843 : Abstract: ORACLE PROCESSES CRASHING WITH ORA-7445 SEGVIO ON A NUMBER OF DATABASES
Comp Version: 8.1.7.4
Status: Closed, could not be reproduced
----------------------------------------------------------------
Bug 2760836: Abstract: PMON cleanup of dead shared servers/dispatchers can crash instance(OERI:26599 / OERI 1115)
--------------------------------------------------------------
Note 2760836.8 PMON cleanup of dead shared servers/dispatchers can crash instance (OERI 26599 / OERI 1115)
----------------------------------------------------------------
PROPOSED SOLUTION JUSTIFICATION(S)
==================================
1. One-off patch for Bug 2760836 has fixed this issue...so after customer apply the one-off patch...then this issue will be solved.
OR
2. 9.2.0.4 or later version has fixed this issue...so after customer upgrade to at least 9.2.0.4 version...then this issue will be solved.
The solution can be justified by the followings:
Note 2760836.8 PMON cleanup of dead shared servers/dispatchers can crash instance (OERI 26599 / OERI 1115)
Network Interface No Longer Operational?
Solaris平台上的Oracle数据库,Alert日志偶尔会出现”Network Interface No Longer Operational”的相关记录:
ospid 11223: network interface with IP address 192.4.1.22 no longer operational requested interface 192.4.1.22 ioctl get mtu. Check output from ifconfig command
该错误一般是由Solaris操作系统Bug 6546482引起的,该错误一般可以忽略。
Script to Detect Tablespace Fragmentation
create table SPACE_TEMP ( TABLESPACE_NAME CHAR(30), CONTIGUOUS_BYTES NUMBER) / declare cursor query is select * from dba_free_space order by tablespace_name, block_id; this_row query%rowtype; previous_row query%rowtype; total number; begin open query; fetch query into this_row; previous_row := this_row; total := previous_row.bytes; loop fetch query into this_row; exit when query%notfound; if this_row.block_id = previous_row.block_id + previous_row.blocks then total := total + this_row.bytes; insert into SPACE_TEMP (tablespace_name) values (previous_row.tablespace_name); else insert into SPACE_TEMP values (previous_row.tablespace_name, total); total := this_row.bytes; end if; previous_row := this_row; end loop; insert into SPACE_TEMP values (previous_row.tablespace_name, total); end; . / set pagesize 60 set newpage 0 set echo off ttitle center 'Contiguous Extents Report' skip 3 break on "TABLESPACE NAME" skip page duplicate spool contig_free_space.lis rem column "CONTIGUOUS BYTES" format 999,999,999,999 column "COUNT" format 999 column "TOTAL BYTES" format 999,999,999,999 column "TODAY" noprint new_value new_today format a1 rem select TABLESPACE_NAME "TABLESPACE NAME", CONTIGUOUS_BYTES "CONTIGUOUS BYTES" from SPACE_TEMP where CONTIGUOUS_BYTES is not null order by TABLESPACE_NAME, CONTIGUOUS_BYTES desc; select tablespace_name, count(*) "# OF EXTENTS", sum(contiguous_bytes) "TOTAL BYTES" from space_temp group by tablespace_name; spool off drop table SPACE_TEMP /
example output:
SQL> @TFSTSFRM Table created. PL/SQL procedure successfully completed. Contiguous Extents Report TABLESPACE NAME CONTIGUOUS BYTES ------------------------------ ---------------- EXAMPLE 32,768,000 Contiguous Extents Report TABLESPACE NAME CONTIGUOUS BYTES ------------------------------ ---------------- SYSAUX 3,211,264 Contiguous Extents Report TABLESPACE NAME CONTIGUOUS BYTES ------------------------------ ---------------- SYSTEM 371,130,368 SYSTEM 393,216 Contiguous Extents Report TABLESPACE NAME CONTIGUOUS BYTES ------------------------------ ---------------- UNDOTBS1 13,500,416 UNDOTBS1 524,288 UNDOTBS1 458,752 UNDOTBS1 458,752 UNDOTBS1 327,680 UNDOTBS1 262,144 UNDOTBS1 196,608 UNDOTBS1 131,072 UNDOTBS1 131,072 UNDOTBS1 131,072 UNDOTBS1 65,536 UNDOTBS1 65,536 UNDOTBS1 65,536 UNDOTBS1 65,536 UNDOTBS1 65,536 UNDOTBS1 65,536 UNDOTBS1 65,536 Contiguous Extents Report TABLESPACE NAME CONTIGUOUS BYTES ------------------------------ ---------------- USERS 10,995,367,936 USERS 1,048,576 USERS 393,216 USERS 262,144 USERS 196,608 26 rows selected. Contiguous Extents Report TABLESPACE_NAME # OF EXTENTS TOTAL BYTES ------------------------------ ------------ ---------------- EXAMPLE 1 32,768,000 UNDOTBS1 17 16,580,608 USERS 7 10,997,268,480 SYSAUX 1 3,211,264 SYSTEM 2 371,523,584 Table dropped.