Author: mac

ORA-600[4194]内部错误一般由重做记录与回滚记录不匹配引发。Oracle在验证Undo record number时，会对比redo change 和回滚段中的undo record number，若发现2者存在差异则报该4194错误。其错误argument[a][b]，a代表回滚块中的最大undo record number，b代表重做日志中记录的undo record number。这个错误可能由回滚段或者redo log日志文件讹误引起。 ORA-00600[4194]错误的根本原因是 redo记录与回滚段(rollback/undo)记录之间的不一致。当ORACLE在验证undo记录时相对应的变化需要应用到undo数据块的最大undo记录上，此时若检验出错则会报ORA-00600[4194]       此错误不像ORA-600[2662]或ORA-600[4000]错误那样必然导致数据库无法打开，因为它很少出现在前滚阶段；当数据库被打开，smon开始执行事务恢复或一些回滚段的管理工作时则很有可能触发该错误。   ORA-600[4194]的2个的含义： Arg [a] Maximum Undo record number in Undo block Arg [b] Undo record number from Redo block   这个ORA-600[4194] 报错属于ORACLE内核从cache层到事务undo处理，可能的影响是进程失败或者可能的回滚段坏块。   可能的bug 包括：   8240762  10.2.0.5, 11.1.0.7.10, 11.2.0.1 Undo corruptions with ORA-600 [4193]/ORA-600 [4194] or…

数据泵工具expdp/impdp是10g中引发的服务器端导入导出外部工具，虽然是外部的binary，但是实际expdp/impdp都依赖于内部的PL/SQL package主要是(dbms_datapump)，在很多情况下我们需要修复或重新加载Datapump工具，方法如下：   对于版本10.1:   1. Catdp.sql orders the installation of all its components including the Metadata API which was previously installed separately. By default catproc.sql invoke this script. SQL >@ $ORACLE_HOME/rdbms/admin/catdp.sql 2. dbmspump.sql will create DBMS procedures for dataPUMP SQL >@ $ORACLE_HOME/rdbms/admin/dbmspump.sql     对于版本10.2:   1. Catdph.sql will Re-Install DataPump types and views…

10g引入ASMM后SGA_TARGET取代shared_pool_size,db_cache_size等参数，成为DBA关注的主要SGA内存管理参数；有不少情况下SGA_TARGET参数会设置为一个小于SGA_MAX_SIZE的值(这样做在多实例情况下更具灵活性)。但不少人会问，这样岂不是要浪费一部分物理内存吗？Oracle会为实例分配SGA_MAX_SIZE大小的内存的，SGA_TARGET要设得和SGA_MAX_SIZE一样大才合理啊！ 让我们来看看实际的情况: SQL> select * from v$version; BANNER —————————————————————- Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bi PL/SQL Release 10.2.0.4.0 – Production CORE 10.2.0.4.0 Production TNS for Linux: Version 10.2.0.4.0 – Production NLSRTL Version 10.2.0.4.0 – Production /* linux上的10.2.0.4 */ SQL> show parameter sga NAME TYPE VALUE ———————————— ———– —————————— lock_sga boolean FALSE pre_page_sga…

Backup Undo Optimization是11g的新特性之一，RMAN将避免备份撤销表空间上那些已提交事务的撤销数据。且该特性无法被禁用(You can enable and disable backup optimization, but backup undo optimization is built-in behavior.)。 我们在11.2.0.1版本上具体测试一下这个新特性: SQL> select * from v$version; BANNER ——————————————————————————– Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – 64bit Production PL/SQL Release 11.2.0.1.0 – Production CORE 11.2.0.1.0 Production TNS for Linux: Version 11.2.0.1.0 – Production NLSRTL Version 11.2.0.1.0 – Production /*…

在pre10g的很长时间内，Oracle仅提供exp/imp导入导出工具，虽然这2个实用程序十分有效(现在也是如此)，但因为它们受限于client/server模式工具自身的限制，以普通用户程序的身份来运转数以TB计的数据，其才不堪大用！DataPump是10g以后主推的数据抽取/导入工具，不同于exp/imp工具，DataPump是一个服务器端的实用程序，因为运行在服务器上故而DataPump进程可以直接访问数据文件与SGA(无需借shadow进程之手)，与exp/imp工具相比使用DataPump可以获得显著的性能改善。DataPump可以通过直接路径或外部表路径这两种方法导出数据；其中直接路径避开了数据库高速缓存。当使用直接路径模式抽取数据时，DataPump从磁盘直接读取数据文件，抽取和格式化文件内容，最后将内容写出到转储文件。该种模式和SGA交互等待少，其导入导出速度直接取决于数据库所在磁盘速度和cpu;因此，直接路径极为快速。 外部表路径模式将使用到数据库的高速缓存buffer cache，通过外部表路径方法导出数据时，DataPump使用普通的SELECT操作将数据块从数据文件中读入buffer cache，为了写出转储文件，数据会在缓存中被格式化。通过外部表路径导入数据时，DataPump根据转储文件的内容构造标准的插入语句，并且通过将数据块从数据文件读至缓存来执行这些语句，插入操作按照标准的样式在缓存中完成；如同任何普通DML操作一样，外部表路径也会同时产生撤销和重做。 DataPump自身会根据对象的复杂性作出使用直接路径还是外部表路径的选择；对于较复杂的对象(后文将列出)而言，为了分解复杂性而必须同SGA进行交互，此情况下Data Pump只能采用外部表模式。我们还可以通过使用access_method参数来控制其行为，当然这仅在我们确认Data Pump作出了错误选择时才有必要。 若满足右列条件EXPDP将采用direct_path即直接路径模式 表结构允许使用直接路径模式,举例而言： 表上没有启用针对SELECT操作的fine-grained access control 非队列表(queue table) 表上没有BFILE和opaque类型的列，或包含有opaque列的对象类型 表上没有加密列 表上没有被废弃的旧类型列 若表上存在LONG或LONG RAW类型列，则此列只能是最后一列 使用Expdp执行导出任务时没有为相关表指定QUERY, SAMPLE, or REMAP_DATA等参数 需要导出的表或分区相对较少(多达250M)，亦或者表或分区其实很大，但导出任务无法工作在并行模式(未指定parallel参数，或parallel参数设置为1) 若满足右列条件EXPDP将采用external_table即外部表模式 数据结构不满足在直接路径模式下抽取的条件，举例而言: 表上启用了针对SELECT操作的精细粒度控制 队列表 表上包含了BFILE或opaque类型列，或者包含有opaque列的对象类型 表上存在加密列 表上存在被废弃的旧类型列 表上存在LONG或LONG RAW类型列，且不是最后列 数据结构满足使用直接路径模式的条件，但执行导出任务时相关表上指定了QUERY, SAMPLE, or REMAP_DATA等参数 数据结构满足使用直接路径模式的条件，但相关的表或分区相对较大(大于250M)，此时并行SQL可以用来加速数据抽取 若满足右列条件IMPDP将采用direct_path即直接路径模式 数据结构满足使用直接路径模式的条件，举例而言: 当导入某单一表分区时该分区表上没有建立全局索引，这一点也包括分区的对象表 没有基于LOB列建立的域索引(domain index) 非cluster表 表上没有BFILE列或opaque类型列 表上没有嵌入了opaque类型的VARRAY列 表上没有加密列 没有启用补全日志(Supplemental logging)且表上没有LOB类型列 若导入表已预先建立了表建构，则需满足以下条件: 表上没有激活的触发器 并且 若是分区表则应有索引 并且 表上上没有启用针对INSERT操作的精细粒度控制…

这个问题发生在今年的1月，用户以操作系统认证形式登陆RAC中的主用实例时发现登陆挂起，但不出现错误。之后应用人员陆续手动杀死服务进程，杀死进程后发现实例可以登录了，应用人员在没有做任何信息转储的情况下重启了数据库，这就造成了我们后期诊断时缺乏必要的信息，也是这个case变成悬案的主要原因。 在实例hang住的一个半小时中告警日志没有任何信息；仅有的有用信息是该实例中diag，pmon，lmd后台进程的trace文件。以下为trace文件: lmd0 trace: *** 2010-01-16 11:02:58.106 DUMP LOCAL BLOCKER/HOLDER: block level 5 res [0x10b0005][0xeb5],[TX] ———-resource 0x70000044a76e1a0———————- resname : [0x10b0005][0xeb5],[TX] Local node : 1 dir_node : 1 master_node : 1 hv idx : 25 hv last r.inc : 0 current inc : 20 hv status : 0 hv master : 0 open options : dd…

真正出现脑裂的几率并不高，但确实让我们碰上了。2个月前为一套AIX6.1上的10.2.0.4双节点RAC系统做故障测试，主要内容是拔除RAC interconnect网线，测试CRS能否正确处理私有网络挂掉的情况。   正式测试时发现2台主机都没有重启，而两端的CSS都认为对方节点已经down了。这就造成2个节点都以为自身是幸存者，也就是我们说的脑裂(brain split)，此时实例一般会因为LMON进程的缘故而hang住。   我们来比对当时2个节点上的日志进一步分析:   STEP 1 :20:41:19物理拔出网线后，节点间无法正常通信，进入misscount倒计时600s 节点1: [ CSSD]2010-06-22 20:41:21.465 [3342] >TRACE: clssnmPollingThread: node gis2 (2) missed(2) checkin(s) [ CSSD]2010-06-22 20:41:22.465 [3342] >TRACE: clssnmPollingThread: node gis2 (2) missed(3) checkin(s) ……… [ CSSD]2010-06-22 20:51:17.956 [3342] >TRACE: clssnmPollingThread: node gis2 (2) missed(598) checkin(s) [ CSSD]2010-06-22 20:51:18.963 [3342] >TRACE: clssnmPollingThread: node gis2 (2)…

一套Linux x86-64上的11.2.0.1系统，alert日志中出现ORA-00600: internal error code, arguments: [kdsgrp1]错误，相关trace的部分内容如下： Dump file /u01/app/oracle/diag/rdbms/utdw016/utdw016b/incident/incdir_276035/utdw016b_ora_5756_i276035.trc Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options ORACLE_HOME = /u01/app/oracle/product/112utdw016 System name: Linux Node name: x42k601 Release: 2.6.18-164.el5 Version: #1 SMP Tue Aug 18 15:51:48…

有这样一个问题，平台为HP-UX(B.11.31 U ia64)，Oracle版本为10.2.0.4 single instance，RMAN自动备份autobackup controlfile时出现hang症状，等待事件为SQL*Net message from client， 这还仅仅是使用最简单的NOCATALOG+ Disk Device的情况，没有MML层面的活动。 针对该问题对RMAN服务进程做了后台TRACE，发现stack call总是hang在_read_sys=>KERNEL内核态函数上，感觉与ORACLE的关系不大，应当是HP-UX C函数调用造成的问题，例如： 10046 trace: PARSING IN CURSOR #3 len=278 dep=0 uid=0 oct=3 lid=0 tim=9513124502191 hv=3071086789 ad=’bd7447d0′ select sofar, context, start_time from v$session_longops where (start_time > nvl(:1, sysdate-100) or start_time = nvl(:2, sysdate+100)) and sid = :3 and serial# = :4 and opname…

如何trace Oracle PMON进程动态注册过程？这个问题我想到2个答案，对PMON做event trace或者采用Oracle Network Server因该都可以达到目的。 让我们来实践一下! Oracle Network Server Trace模式 1. 启用Oracle SqlNet服务器端trace,这需要我们修改sqlnet.ora配置文件 [maclean@rh2 ~]$ echo “TRACE_LEVEL_SERVER = 16 > TRACE_FILE_SERVER = SERVER > TRACE_DIRECTORY_SERVER= /home/maclean/ntrc” > $ORACLE_HOME/network/admin/sqlnet.ora [maclean@rh2 ~]$ cat $ORACLE_HOME/network/admin/sqlnet.ora TRACE_LEVEL_SERVER = 16 TRACE_FILE_SERVER = SERVER TRACE_DIRECTORY_SERVER= /home/maclean/ntrc 2. 触发trace SQL> conn / as sysdba Connected. SQL> select spid from V$process, V$session…