Author: mac

以下脚本可以用于收集介质恢复诊断信息(recovery_info.sql)： — begin [recovery_info.sql] — define spoolfile = &1 spool &spoolfile alter session set nls_date_format = ‘YYYY-MM-DD HH24:MI:SS’; alter session set timed_statistics = true; alter session set max_dump_file_size = UNLIMITED; set feedback on set term on set wrap on set trimspool on set pagesize 1000 set linesize 100 set numwidth 10 select to_char(sysdate) start_time from…

转自小荷的博客：http://www.oracleblog.org/its-my-life/ibm-gdc-you-are-unable-to-innovate/   说IBM不会有创新，可能有不少IBMer要跳出来了：什么？IBM不会有创新？那沃森的人机问答大战是什么？IBM的蓝云战略是什么？IBM的创新实验 室是干什么吃的？——老大，别急，我说的是IBM GDC，你说的IBM是美国IBM公司的嫡系子孙，我说的IBM GDC是美国IBM的庶出后代罢了。 IBM GDC的GDC全称是Global Delivery Centre，工卡上印的是IBM solution & services（xxxx某地） co.,LTD。这在工卡上就能体现了，和嫡系的IBM China不是一回事。既然是solution & services，那么主要做的就是服务的项目，大致的讲，主要就是做服务了，通俗的讲，也就是做外包了。 在金融海啸之后，全球的IT产业都不景气，各个产业的IT预算都在缩减，唯独IBM GDC的业务量却在蒸蒸日上的增长。为什么？这和IBM GDC的服务模式分不开。在金融海啸的影响下，各个产业的IT部门付不出那么多钱来维持原来的IT服务，IT部门纷纷裁员，缩减IT经费，或者将IT的维 护外包给价格便宜的IT服务公司。可IT服务的外包公司那么多，为什么选IBM GDC？ 因为GDC的服务模式是利用IBM这块全球性的大牌子，在全球范围内接下各种客户的服务的单子。由于当地的人力成本高，IBM又是一个全球性的公司，他接 下单子后，可以进行全球服务资源的整合，将单子转给人力成本相对低廉的国家。因此，你就可以看到为什么IBM　GDC会出现在中国、印度、巴西、阿根廷这些发展中国家，而不是出现在英国、美国、日本这些发达国家。据和日本的IBM聊天得知，同样的活，他们那边的人力成本是我们这边的3～5 倍。 ok，人力成本低了，但是这还不是最惨的，因为单子不是直接过来，而且是一层一层的去油水过来，举例来说，比如一个德国客户的项目，那么德国的IBM要先 抽一层水，然后转给大中华区的IBM再抽一层水，最后的一点油水才给GDC（当然中间可能还有我不知道的抽水阶层）。蛋糕分到公司的头上已经是一小小块 了，再分到部门，分到个人，自然也不会太大。在分蛋糕的过程中，也会有各种角逐，如我这篇《办公室政治》。 蛋糕不大，当然不能吸引牛人们过来，已经跳入火坑的人自然也不会有太大的动力去创新。 当然，蛋糕只是影响创新的一个因素，在我看来是一个很小的因素。影响其创新因素的是其企业文化，是企业的基因。 在IBM GDC，最重要的是什么？是流程！是process！每一件事情都是遵照着流程去做。你在这个流程中不需要是思考什么，不需要去研究什么，只需要按照流程 做就可以了。如遇到一个故障，参照工作文档，先根据脚本做一次health check，如果我们的团队没有问题，那么工单就转到下一个团队去。——这就造成了，最后所有的团队都检查了一次，自己的层面内都没有问题，但是用户那边 却严重的有故障现象。——没有一个站在架构层面的，熟悉整体应用的人来领导故障处理。 什么？你说不是有CSM，SDM么？那些人只是负责资源调配，根本不懂技术，根本没有在技术层面的判断能力。你可以去看看，在IBM，项目经理不需要懂技术，只需把握项目进度，在milestone之前完成进度即可。 由于没有站在架构层面，熟悉整体应用的人来领导，因此各个团队只是被框在了很小的一个范围内，数据库只是负责纯数据库层面的，主机只是负责主机层面的，甚 至监控团队，都再划分成2个，一个负责部署监控，一个负责“看”监控。每个人犹如井底之蛙，看不到外面整体的一个系统。很明显的一点，你要一个应用的网络 拓扑图，没一个团队可以给的出来，大家有的，只是db list，server list，monitor parameter list。要个list有屁用！ 记得有一次db遇到故障，应用那边明显感觉很慢，db端也查到了大量的log file sync的等待，查io情况非常空闲，压力不大，但是在awr report中看到log file sync的avg wait time在10ms以上了，根据经验，应该是log file所在的存储可能出现问题，如存储没电，导致写cache缓慢，或者光纤交换机通信出现问题。但是根据流程，我们做不到什么，我们只能把工单传给下 一个团队去检查。 于是，有这样一个笑话，DBA的分类，传统意义上有维护DBA和开发DBA，现在在IBM多了一种，叫“流程”DBA。 遇到的问题不是我们团队的，转到下一个团队；如果是我们问题的，那就解决掉它，解决的方式是开change，这又是一个痛苦的事情，一会再说。如果没办法…

不了解Oracle软件Lifetime Support支持生命周期的朋友可以直接参阅Expect Lifetime Support http://www.oracle.com/us/support/lifetime-support/index.html页面。   我们知道Oracle软件的支持周期可以分为Premier Support 和 Extended Support， 在Premier Support 时期只要是购买了Oracle PS服务的用户都可以申请 创建或合并补丁(create or merge patch) ， 当支持周期进入Extended Support后 只有购买了扩展服务包的用户才能申请 新的补丁。   具体各Release 版本的Database的Support 周期如下：       如上图所见 版本10.2的Premier Support 已在2010年过期，实际10.2已经过度到了Extended Support时期，且会在2013年进入Sustainging Support。 但是实际My Oracle Support并没有在2010年立即限制仅购买Premier Support的用户下载July 2010 后发布的一些PSU/CPU补丁，例如Patch 12419392: DATABASE PSU 10.2.0.5.4 (INCLUDES CPUJUL2011) 是在2011年7月发布的 ， 仅购买了Premier Support的用户同样可以下载该Patch set Update。…

使用 SQL 应用的滚动版本升级 从 Oracle Database 10.1.0.3 开始以及在其后的更高版本中，在使用 SQL 应用来执行滚动数据库升级时，逻辑备用数据库可以在比主数据库更高的 Oracle 发行版中运行。例如，使用 SQL 应用和逻辑备用数据库，可以将 Oracle DB 软件从补丁程序集版本 10.2.0 n 升级到下一个数据库补丁程序集版本 10.2.0 (n+1)。本幻灯片中的第一个步骤显示了开始升级前的 Data Guard 配置，此时主数据库和逻辑备用数据库都运行相同的 Oracle 软件版本。在第二步中，您停止了 SQL 应用并在逻辑备用数据库上将 Oracle DB 软件升级为版本 n+1。在升级过程中，重做数据将在主系统上进行累积。在第三步中，您重新启动了 SQL 应用，在主系统上累积的重做数据会自动进行传送，并应用到新升级的逻辑备用数据库。Data Guard 配置可以在任意期间运行混合版本。在第四步骤中，您执行了切换。接下来在新的主数据库上激活用户应用程序和服务。在再次启用 SQL 应用之前，需要升级新的备用站点。这是因为新的备用站点不能理解新的重做信息。最后，提高每个数据库的兼容性级别。 注：SQL 应用并不支持所有数据类型。可能会禁止您使用此方法。在此情况下，使用 Oracle Streams 是一种可能的替代方法。   数据库高可用性：最佳方法 使用 SPFILE。 创建两个或多个控制文件。 设置足够长的 CONTROL_FILE_ RECORD_KEEP_TIME。 多路复用生产和备用重做日志 将检查点记录到预警日志中。 使用自动优化…

一套Linux x86-64上的11.2.0.1数据库出现ORA-00600:[pfri.c: pfri8: plio mismatch ]，日志如下 ：   ORA-00600: internal error code, arguments: [pfri.c: pfri8: plio mismatch ], [], [], [], [], [], [], [], [], [], [], [] ORA-04061: existing state of package body “APPS.OE_ORDER_UTIL” has been invalidated ORA-04065: not executed, altered or dropped package body “APPS.OE_ORDER_UTIL”   经过和MOS沟通，确认为Bug: 9691456 11.2.0.2, 12.1.0.0 ORA-600 [pfri.c:…

Warning: lio_listio returned EAGAIN Performance degradation may be seen. WARNING:Oracle process running out of OS kernel I/O resources (1) 出现以上信息一般代表AIX 的AIO参数配置不是最佳，可能导致Oracle IO性能下降， 建议参考文档AIX: DBWR trace warning: LIO_LISTIO RETURNED EAGAIN [ID 265491.1]来调优AIX AIO参数，一般在AIX 版本4、5上才需要调优该AIO参数，在AIX 6上默认配置即可。

Script:以下脚本可以用于诊断segement space usage问题： set serveroutput on; declare v_unformatted_blocks number; v_unformatted_bytes number; v_fs1_blocks number; v_fs1_bytes number; v_fs2_blocks number; v_fs2_bytes number; v_fs3_blocks number; v_fs3_bytes number; v_fs4_blocks number; v_fs4_bytes number; v_full_blocks number; v_full_bytes number; begin dbms_space.space_usage (‘&OWNER’, ‘&TABNAME’, ‘TABLE’, v_unformatted_blocks, v_unformatted_bytes, v_fs1_blocks, v_fs1_bytes, v_fs2_blocks, v_fs2_bytes, v_fs3_blocks, v_fs3_bytes, v_fs4_blocks, v_fs4_bytes, v_full_blocks, v_full_bytes); dbms_output.put_line(‘Unformatted Blocks = ‘||v_unformatted_blocks); dbms_output.put_line(‘FS1 Blocks =…

同学们大概偶尔也会在事务繁忙的Oracle数据库的LGWR日志进程的TRACE里找到如下的内容： Warning: log write time 1730ms, size 155KB *** 2011-09-12 22:56:05.407 Warning: log write time 810ms, size 1KB *** 2011-09-12 22:56:06.990 Warning: log write time 1590ms, size 154KB *** 2011-09-12 22:56:07.670 Warning: log write time 600ms, size 109KB *** 2011-09-12 22:56:09.903 Warning: log write time 1790ms, size 190KB *** 2011-09-12 22:56:11.704 Warning: log write time…

11g中对于LOB对象引入了securefile特性，相对应的对于securefile的统计信息也被大量加入，例如对于旧的oldfile LOB大对象的CHUNK分配是没有具体的STATISTICS来统计的（到11.2.0.3都没有这样的STATISTICS来统计传统LOB的CHUNK分配、回收等等操作)，而对于SECUREFILE则有很详尽的STATISTICS:     1* select name,value from v$sysstat where upper(name) like ‘%CHUNK%’ or upper(NAME) LIKE ‘%SECUREFILE%’ SQL> / NAME VALUE ————————————————– ———- segment chunks allocation from disepnser 0 segment total chunk allocation 0 securefile allocation bytes 0 securefile allocation chunks 0 securefile direct read bytes 0 securefile direct write bytes 0 securefile direct read…

一套Linux x86-64 上的11.2.0.2逻辑备库因为出现ORA-26786: A row with key exists but has conflicting column(s) “导致APPLIER  进程无法继续工作，详细信息如下:   1) ### Primary OS Details ### Hostname – vrh6 OS details – [oracle@vrh6 ~]$ uname -a Linux vrh6 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux 2) ### Standby OS Details ### Hostname – vrh7…