Author: mac

一套HP-UX上的10.2.0.4系统出现ORA-00600[17175] Oracle600内部错误，相关的日志信息如下: Wed Dec 1 01:57:55 2010 Errors in file /u01/app/oracle/admin/xgp2/bdump/xgp21_pmon_3250.trc: ORA-00600: internal error code, arguments: [17175], [255], [], [], [], [], [], [] ORA-00601: cleanup lock conflict Wed Dec 1 01:57:57 2010 Trace dumping is performing id=[cdmp_20101201015757] Wed Dec 1 01:58:05 2010 LGWR: terminating instance due to error 472 Wed Dec 1 01:58:05 2010…

一套Linux x86-64上的11.1.0.7 RAC系统，该RAC使用Netapps NFS作为共享存储。其中一个节点出现ORA-00600: internal error code, arguments: [kccchb_3]内部错误并导致实例意外终止，详细日志如下: Mon Dec 27 00:03:13 2010 Error: Controlfile sequence number in file header is different from the one in memory Please check that the correct mount optionsare used if controlfile is located on NFS Errors in file /d02/oratst/TSMOTEBS/db/11.1.0/admin/TSMOTEBS1_l118464dcss3001/diag/rdbms/tsmotebs/TSMOTEBS1/trace/TSMOTEBS1_ckpt_15907.trc (incident=11353): ORA-00600: internal error code, arguments: [kccchb_3], [555541], [555540],…

Latch cache buffers chains大约是Oracle中child latch数量最多，使用最为频繁的闩锁了。其子闩总数受到初始化参数(8i中的db_block_buffers/4)的影响，Oracle中有大量kernel函数有机会接手持有cache buffer chains latch: col parent_name for a25 col location for a40 SELECT t1.ksllasnam “parent_name”, t2.ksllwnam “location” FROM x$ksllw t2, x$kslwsc t1 WHERE t2.indx = t1.indx AND ksllasnam = ‘cache buffers chains’; parent_name location ————————- —————————————- cache buffers chains kcbw_activate_granule cache buffers chains kcbw_first_buffer_free cache buffers chains kcbwxb cache buffers chains…

2004年7月19日，中国上海，Oracle大中华区董事总经理陆纯初带着他的新高管班子集体亮相于Oracle World会场。对于陆纯初治下的Oracle中国公司来说，这是一次集体兴奋。   不过，更需要陆纯初面对的是，Oracle中国公司的问题并没有因此而平息下来，人事变动只是其中一环，更致命的问题在于Oracle中国公司盲目举起直销大旗，多少有兔死狗烹之嫌。尽管陆纯初并不否认合作伙伴过去在Oracle中国发展中的作用，但这仅仅是过去。   “我们现在连鸡肋都不如！”依着Oracle这棵大树做了两年代理的陈昆，已经开始考虑下一步的走向。   “鸡肋丢掉的话，人家还会有些可惜。对于Oracle和我们，应该是到了双方信任难关的时候。”陈昆的话极具代表性，这个信任，在陈看来，其中包括商业道德的成分。   变革本无可厚非。讲究流程和注重严明纪律的陆纯初这一次入主Oracle中国公司靠走胡伯林、张书恒等之后，开始从渠道入手，清理门 户，充分展示了陆式铁腕手段。其“猛药下沉疴，快刀斩乱麻”的外科手术打法，有如2003年的美国对伊拉克战争，看起来干净利索，最后结果如何还有待考 量。   毕竟，从根本上忽视合作伙伴和客户利益的行为是商业大忌。而这种商业大忌，在过去的10多年里，不断在Oracle中国公司的合作史中上演。   美的Oracle往事   对于张伟来说，1997年进入美的集团是个机会。在这之前，张伟曾在武汉做过一段时间的市场策划，初来到美的也是做跟策划相关的工作。 1996年，美的集团已经确定上线Oracle的系统管理软件，当时ERP的概念还不普及，更多的处于MRP‖阶段。张伟“没想到自己会被抽调到关键用户 的岗位”，并由此开始了IT咨询顾问的职业生涯。 “现在中国做IT咨询资历比较老的人多数是从美的、华为出来的。”——华为跟美的一样，是Oracle在中国的早期客户。1999年，从美的电脑部脱胎而来的美的信息科技有限公司成立，汉普、汉得等一批如今久负盛名的IT咨询公司刚成立不久。 “那时候的汉普是个空架子，除了张后启，没有什么人拿得出手。”而汉普、汉得都是依着Oracle起家，没有客户实施经验是它们的硬 伤，“包括当年的普华永道。”于是，美的仍在进行Oracle系统上线的时候，美的实施队伍和关键用户就开始有人被不断挖走，这在1999年美的信息成立 的时候达到高潮。 “美的100多人的参与队伍，那时候在这些咨询公司看来，是一个现成的金矿。”也是从美的出来，现为某IT咨询公司首席咨询顾问的李宽对几年前业内的这场“挖人运动”仍记忆犹新。 美的、华为被挖走的实施人员和关键用户，多数流入到了中国新近兴起的IT咨询界， 这些早期的Oracle用户也因此帮助Oracle一度占领了中国企业级应用软件的高端市场。 李宽认为，“2000年前后，Oracle在中国市场的火爆很大程度上归功于美的信息、汉普、汉得这些合作伙伴。”这正值SAP在中国 蛰伏4、5年后力推其“灯塔计划”的时候，当时SAP更多是携IBM、德勤等这些国际咨询界巨头在中国打单，而Oracle与中国本土咨询伙伴联合起来， 使得SAP的“灯塔计划”经常被搅和。其中包括哈药和长虹等单子。 2001年，美的信息改名赛意信息。这一年，美的Oracle系统的一期实施已基本完成，之前参与这一项目的实施人员和关键用户都编入了赛意。赛意由此开始了Oracle的渠道角色，并一直持续到现在。 “这一年，也是赛意人走得最多的一年。原来美的那一批人由于待遇等问题在这个时候几乎流失殆尽。” 张伟也是在2001年被一家上线Oracle系统的港资企业挖走，做了内部顾问。今年初，张伟跳到广州科森信息科技公司，再次成为IT咨询顾问。“在科 森，也有不少从美的出来的人，其中包括目前科森的3个首席顾问和我们现在一个项目的顾问经理。” 赛意头上的美的光环随着顾问的流失而逐渐暗淡，加上其市场操作能力的欠缺，Oracle开始将注意力转向扶持其他的合作伙伴，赛意就此沦为一家区域性的二流系统集成商。 伙伴的非Oracle逻辑 对于自己已经脱离近两年的汉普生涯，如今专做瑞典某家系统软件代理的林小兵不愿多说。但谈起Oracle以及当年的“鲲鹏计划”，他明显开始激动。 “除了张后启等人的原因，汉普的起身和衰落，Oracle是一大因素。”自从离开汉普之后，林小兵发誓再也不接触Oracle。 张后启在1997年靠3万块钱创立了汉普，自1999年从美的大规模的挖来咨询顾问，有了较强的实施队伍后，汉普在之后的两年“签单都快签疯了”，“随着单子越来越多，汉普咨询顾问的缺乏越来越成为一个问题。”这两年，林小兵南上北下，“连自己的生日都漏了两次。” 顾问的工资是咨询公司最大的一笔支出。没有顾问，空有单子的局面让张后启开始心头焦虑起来，最简便的方法就是去找投资。2001年底， 联想集团将现金港币5500万元及联想现有IT咨询业务注入汉普，并获得汉普的51%权益。这之后，一直到近期联想卖掉包括原汉普在内的IT服务部门的几 年间，汉普改名叫联想汉普。 一年后的2002年11月25日，Sun公司中国公司总经理薛耀琨、时任Oracle中国区总经理胡伯林和联想集团高级副总裁俞兵共同在北京启动战略联盟，也就是所谓的“鲲鹏计划”。其中，负责Oracle系统咨询服务的就是联想汉普。 当时的Oracle正励精图治，不遗余力推广其渠道策略，打造中国Oracle系，以正面挑战SAP在中国中小企业市场的推广。 组建之初，“梦之队”便发出豪言：“我们想卖的不是十套八套，而是几十套上百套。”而半年后，事实结果恰恰是他们不想卖的“十套八套”。 那时候，林小兵也到了现场。他今日看来，“鲲鹏计划”“有如一场闹剧。” 一年前也是从汉普出来的张凯峰，现在上海自称是“无业游民”，实则做着行业内普遍可见的独立顾问。在这之前，张已经是有4年资历的老汉普人。 对于“鲲鹏计划”，张凯峰的批评直指Oracle。“Oracle对中小企业市场没有战略考虑，更大程度上是一种投机活动，其业务逻辑和管理方式明显不切合中国市场需求。这是‘鲲鹏计划’进展不利的重要原因。” Oracle在与联想合作之初，曾经承诺针对中国的中小企业开发个性化产品，但实际上没有做到，只是将其标准版产品做了重新包装，换汤不换药。所谓的电子商务套件特别版，“其实也就是价格特别一些而已”。 最要命的是，其产品研发团队都不在中国，而是在新加坡，用的是印度工程师，根本不了解中国客户的需求。而且在实际运作过程中，Oracle 也不愿意做出改变。 林小兵曾经做过一个中小企业单子，该企业需要的一些报表，Oracle不愿意提供。联想汉普出面交涉也没有结果，“Oracle会直接告诉你，如果需要的话，必须另外购买。” 事实上，联想汉普打下不少单子，但最后多是因为客户发现产品不过关。为了不失去客户，汉普只能重推标准版，甚至更换其他厂商的产品。 在市场策略方面，Oracle也表现得急功近利。Oracle 曾经声称将和联想汉普一起加强对二级渠道的培养，这一承诺也未履行。“他们并没有培养渠道，而只是在年底跟联想要单。”这和其他公司对中国市场的潜心经营…

以下列出了OGG一些常见的问题与错误及其解答： Note: 966211.1 How To Resync A Single Table With Minimum Impact To Other Tables’ Replication? Note: 966227.1 Troubleshooting TCP/IP Errors In Open Systems Note: 972954.1 What Causes The ‘Bad Column Index(xxxx)’ Error In Replicat? Note: 987379.1 How to recover from Extract ERROR 180 encountered commit SCN that is not greater than the highest SCN…

Oracle在11g中提出了online patching(也可以叫做hot patch)的概念，有效减少了因实施one-off patch而导致的系统停机时间。但我们如何得知哪些Patch是可以online apply的，而哪些Patch是必须关闭实例(shutdown instance)后应用的呢？ 下面我们就介绍一种简单有效地方法来识别这2种Patch: 1. 从MOS下载所需要的Patch文件 2. 解压该Patch文件(一般为zip压缩包)，cd到/$PATCH_ID/etc/config目录，打开inventory.xml文件 3. 检查xml文件中的instance_shutdown选项，如 <instance_shutdown>true</instance_shutdown> 则说明该one-patch要求offline apply,而不能在线实施

这段Merry christmas的查询来源于Gilles Haro的博客，不过看到的时候已经是27号了，呵呵！ with Mx as (select 60 as MaxWidth from dual) select decode (sign(floor(MaxWidth / 2) – rownum), 1, lpad(‘ ‘, floor(MaxWidth / 2) – (rownum – 1)) || rpad(‘*’, 2 * (rownum – 1) + 1, ‘ *’), lpad(‘* * *’, floor(MaxWidth / 2) + 3)) from all_tables, Mx where rownum < floor(MaxWidth…

1. Query the V$FIXED_TABLE to determine the V$ views that provide latch information. a. Execute the following query:> select name from v$fixed_table where name like ‘V$LATCH%’; 2. Remember that there are 14 levels of latches, numbered 0 – 13. a. Take a look at three common latches and their level by executing the following query:>…

Oracle 8i中引入了星型转换(star transformation)的优化器新特性以便更有效地处理星型查询。星型查询语句多用于基于星型模型设计的数据仓库应用中。星型模型的称谓源于该种模型以图形化表现时看起来形似一颗海星。这颗星的中央会由一个或多个事实表(fact tables)组成，而各个触角上则分布着多个维度表(dimension tables)，如下图： 星型转换的基本思路是尽量避免直接去扫描星型模式中的事实表，因为这些事实表总会因为存有大量数据而十分庞大，对这些表的全表扫描会引起大量物理读并且效率低下。在典型的星型查询中，事实表总是会和多个与之相比小得多的维度表发生连接(join)操作。典型的事实表针对每一个维度表会存在一个外键(foreign key)，除去这些键值(key)外还会存在一些度量字段譬如销售额度(sales amount)。与之对应的键值(key)在维度表上扮演主键的角色。而事实表与维度表间的连接操作一般都会发生在事实表上的外键和与之对应的维度表的主键间。同时这类查询总是会在维度表的其他列上存在限制十分严格的过滤谓词。充分结合这些维度表上的过滤谓词可以有效减少需要从事实表上访问的数据集合。这也就是星型转换(star transformation)的根本目的，仅访问事实表上相关的、过滤后精简的数据集合。 Oracle在Sample Schema示例模式中就存有星型模型的Schema，譬如SH: SQL> select * from v$version; BANNER ———————————————————————- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production PL/SQL Release 11.2.0.1.0 – Production CORE 11.2.0.1.0 Production TNS for 32-bit Windows: Version 11.2.0.1.0 – Production NLSRTL Version 11.2.0.1.0 – Production SQL> select * from global_name; GLOBAL_NAME ———————————–…

1. The size of the redo log buffer is determined by the LOG_BUFFER parameter. a.  Determine the size of the LOG_BUFFER by executing the following query:> select * from v$sga; b.  View the LOG_BUFFER setting in the init.ora file. 2.  There are three latches associated with the redo log buffer. a.  Execute the following query…