Author: mac

  • ORA-00600[kjpsod1]&ORA-44203错误一例

    一套HPUX-Itanium平台上版本为10.2.0.2 的系统出现ORA-00600: internal error code, arguments: [kjpsod1], [], [], [], [], [], [], [],并伴随有”ORA-44203: timeout waiting for lock on cursor”.错误,详细的日志如下:   Database get error Errors in file /s01/admin/udump/prod_ora_14084.trc: ORA-00600: internal error code, arguments: [kjpsod1], [], [], [], [], [], [], [] ORA-44203: timeout waiting for lock on cursor ORA-44203: timeout waiting for lock on cursor…

  • ORA-00600[kglhdunp2_2]错误一例

    一套 AIX上的10.2.0.3 数据库出现了ORA-00600: internal error code, arguments: [kglhdunp2_2]错误,详细日志如下:   ORA-00600: internal error code, arguments: [kglhdunp2_2], [0x7000007A061F8A0], [ 3], [0x7000007F4AEC160], [0x7000007A061F990], [0x7000007A06639A8], [1000], [18] Sat Aug 20 05:11:26 2011 Fatal internal error happened while SMON was doing Unpin KGL handles with depend ency. Sat Aug 20 05:11:26 2011 Errors in file /u01/app/oracle/product/10.2.0/admin/bdump/prod_smon_4915426.trc: ORA-00600: internal error code,…

  • ORA-00600:[1112]内部错误&ROW CACHE ENQUEUE LOCK一例

    一套AIX 上的9.2.0.6 2节点RAC系统出现了ORA-00600: internal error code, arguments: [1112], [], [], [], [], [], [], []内部错误伴随有ROW CACHE ENQUEUE LOCK并引发clusterware split-brain resolution,详细的日志及ass.awk输出如下:   ALERT LOG ============= Sun Jun 19 09:06:24 2011 >>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=24 Sun Jun 19 09:06:29 2011 Errors in file /s01/admin/prod/udump/prod2_ora_1061088.trc: ORA-00600: internal error code, arguments: [1112],…

  • dbms_logmnr Unsupported SQLREDO

    Question: Try Testing Oracle Logminer   SQL> create table maclean (t1 varchar2(100)) tablespace users; Table created. SQL> insert into maclean values (‘MACLEAN’); 1 row created. SQL> commit; Commit complete. after start logmnr: sql> …add log file …. sql> exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog + dbms_logmnr.committed_data_only); sql> select sql_redo from v$logmnr_contents; create table maclean (t1 varchar2(100)) tablespace users; Unsupported…

  • 如何绕过ORA-00701错误和降低bootstrap对象的高水位

    如何绕过ORA-701错误来实施对数据库自举对象bootstrap object的一些修改呢?   [oracle@mlab1 ~]$ oerr ora 701 00701, 00000, “object necessary for warmstarting database cannot be altered” // *Cause: Attempt to alter or drop a database object (table, cluster, or // index) which are needed for warmstarting the database. // *Action: None.     首先需要说明的是,这纯粹为了技术教学,在实际的产品环境中不要使用如下手段!!!   SQL> alter index SYS.I_H_OBJ#_COL# rebuild; alter index SYS.I_H_OBJ#_COL#…

  • 贴几张我们的婚纱照

    10月初在only photo 拍的,花了2天时间,总共换10套衣服,拍到最后实在太累了,简直笑不动 🙂 外景地跑得挺远的,要开2个多小时的车,不过确实是很漂亮,马场、游艇之类的景致应有尽有。                  

  • 利用Oracle在线重定义Online Redefinition清理历史数据

    我在<了解Oracle在线重定义Online Redefinition>一文中介绍了Oracle在线重定义的特点及其使用步骤,Online Redefinition的适用场景很多,包括:   Modify the storage parameters of a table or cluster Move a table or cluster to a different tablespace Add, modify, or drop one or more columns in a table or cluster Add or drop partitioning support (non-clustered tables only) Change partition structure Change physical properties of a single table partition, including…

  • Know more about AWR Parse Statistics

    Parse CPU to Parse Elapsed%是一个我们在分析AWR报告时常会看到的解析性能指标,该指标反映了 快照内解析CPU时间和总的解析时间的比值(Parse CPU Time/ Parse Elapsed Time); 若该指标水平很低,那么说明在整个解析过程中 实际在CPU上运算的时间是很短的,而主要的解析时间都耗费在各种其他非空闲的等待事件上了(如latch:shared pool,row cache lock之类等), 通过该指标我们可以了解是否有必要来调优Oracle的优化器Optimizer的解析(parse)工作, 调优的对象包括软、硬解析(soft and hard parse),理论上我们的目标是有极少的硬解析,少量的软解析,以及Parse CPU to Parse Elapsed% 接近于100% 相当于解析时都是在CPU上运算 而不等待, 所以Parse CPU to Parse Elapsed%也同时给我们以调优方向的启示。   Soft Parse %是AWR中另一个重要的解析指标,该指标反应了快照时间内 软解析次数 和 总解析次数 (soft+hard 软解析次数+硬解析次数)的比值,若该指标很低,那么说明了可能存在剧烈的hard parse硬解析,大量的硬解析会消耗更多的CPU时间片并产生解析争用(此时可以考虑使用cursor_sharing=FORCE); 理论上我们总是希望 Soft Parse % 接近于100%, 但并不是说100%的软解析就是最理想的解析状态,通过设置 session_cached_cursors参数和反复重用游标我们可以让解析来的更轻量级,即通俗所说的利用会话缓存游标实现的软软解析(soft soft parse)。   其他一些对于tuning SQL parse调优SQL解析有帮助的指标信息:…

  • 【Oracle数据恢复】对被truncated表的恢复

    【Oracle数据恢复】对被truncated表的恢复   1、 使用普通备份恢复机制恢复 2、

  • Know more about RAC GES STATISTICS

    GES 全称为Global Enqueue Services是RAC中重要的全局队列锁服务,V$GES_STATISTICS 动态性能视图汇聚了主要的GES STATISTICS 统计信息。为了更好地理解GES STATISTICS ,我们可以通过下表理解这些统计项的含义:   V$GES_STATISTICS Reference (10.2.0.1.0)   0 messages sent directly            Incremented when any process successfully sends a message to a remote instance without being blocked and without flow control.   1 messages flow controlled                    Incremented when any process could not send a message directly because…