-
编辑 删除
自作自受，很好的一个成语！
纵观人的一生，无论悲剧还是喜剧、幸福还是痛苦，基本上都是自作自受！[@more@]
-
编辑 删除
责任、尊严和荣誉
美国西点军校的校训是责任、荣誉、国家，我一直觉得这六个字准确浓缩了军人的终极目标。作为一个普通人，我想我们的终极目标是责任、尊严和荣誉。生活中总是有各种各样的遗憾的，男人不能纠缠在这些遗憾中不能自拔。与我们的崇高的目标相比，一切都是渺小的！让我们骄傲地活着去创造完美的成功！即使失败，也让失败来得酣畅淋漓。[@more@]
-
编辑 删除
10G新特性笔记之AWR,ASH,METRIC,ALERT&ADVISOR
这里对10G的AWR,ASH,METRIC,ALERT&ADVISOR进行下总结[@more@]1、AWR架构包含两个部分，一个是in-memory statistics，存放在内存中，一个是persistent portion2、AWR中存放下面的统计信息：Object statistics，new SQL statistics，The new wait classes interface，The new time-model statistics，V$SYSSTAT and V$SESSTAT，Oracle optimizer statistics，Operating system statistics，Active Session History，Metrics3、ASH中包含最近会话的活动信息，系统每秒对v$session进行抽样，放在SGA中的ASH区，该ASH区采用的是循环使用的机
-
编辑 删除
10G新特性笔记之自动管理
10G的自动管理功能包含ADDM、自动共享内存管理、自动统计信息收集、自动undo retention调整、自动checkpoint调整[@more@]1、ADDM相关进程为MMONADDM默认情况下是起用了的。通常数据库默认情况下每小时会从SGA中抓取统计信息存储在AWR（Automatic Workload Repository）中，每次SNAPSHOT被收集，ADDM被启动对最近的两个SNAPSHOT进行分析。为了让ADDM自动工作，必须设置STATISTICS_LEVEL为typical或者all.ADDM对IO性能的分析倚赖于IO子系统的速度，该速度ORACLE默认为10,000 microseconds，可以手工设置DBIO_EXPECTED的值，具体方式为：SQL&
-
编辑 删除
/etc/hosts文件不可读导致10.2.0.3数据库不能起来
今天客户数据库无法启动，即使是启动到nomount状态，错误信息是：ORA-600 [keltnfy-ldminit][@more@]经查是ORACLE BUG# 5486074：OERI [keltnfy-ldminit] when DNS is not available让/etc/hosts文件可访问后一切正常。
-
编辑 删除
关于错误ora-00064
今天在给用户设置db_keep_cache_size为80G时，数据库无法启动，错误信息为：ORA-00064: object is too large to allocate on this O/S (1,16777216)[@more@]查找相关ORACLE文档，解决方案是：设置隐含参数_ksmg_granule_size=67108864通常对于SGA大于128M的数据库，每个granule的大小是16M，这里是把它设置成了64M了。个人认为出现上面错误的原因是80G对于16M的granule太大，即granule数太多，因此增大granule的大小进而减小granule数。
-
编辑 删除
遭遇BUG 4483368出现ORA-19693错误后的处理办法
客户数据库通过手工脚本实现DATAGUARD，即通过将生产库归档日志定时备份、恢复到备库的方式实现。然而今天却出现了恢复不成功的问题：[@more@]错误信息：RMAN-00571: ====================================RMAN-00569: ====== ERROR MESSAGE STACK FOLLOWS ======RMAN-00571: ====================================RMAN-03002: failure of recover command at 05/23/2008 09:38:48ORA-19693: backup piece /opt/oracle/admin/mnt_new/HERMES_NEW/2008-05-23.00-00-01/jrjh24rf_1_1 already included通过list backupset of archivelog all;
-
编辑 删除
关于ORA-01555
工作中经常会遇到错误ORA-01555，结合工作中的经验，参考几篇ORACLE文档，下面进行一下总结。[@more@]一、ORA-01555错误发生的两个原因原因之一是回滚段太小、回滚段数目少导致回滚段中的相关数据块被overwritten原因之二是延迟块清除如果一个会话对某个表进行了大量更新，oracle并不是马上去回写数据块并清除块的事务信息，而是在下次访问这些块的时候进行这些操作。这样事务信息在延迟清除之前的状态是：在数据块头有未提交事务的相关回滚段、事务槽的信息，而对应回滚段头对应事务槽的状态为committed，当下一次数据块被访问到的时候，
-
编辑 删除
PMON与library cache latch
曾经有个客户数据库出现问题，警告日志文件显示：PMON FAILED TO ACQUIRE LATCH，而TRACE文件中显示PMON在等待某个library cache latch。当时有点疑问：PMON用于清理进程资源或者重新启动DEAD DISPATCHER进程，为什么要获取library cache latch?关于这个问题，METALINK上的答复是：Simply when Pmon cleans up the held resources it has to aquire latches in Library cache to clear that resources. It gets the library cache latch to get the right hash bucket and then knows the exact status of the resource to take the right
-
编辑 删除
汶川地震之殇
2008年注定是个不安定的年份：年初大雪、西藏骚乱、山东火车相撞、手足口病、汶川地震，也许未来还会有很多的类似事件发生。天灾人祸本就不是我们能控制的，可是我们却看到，全国人民因这些事件团结了起来。中国，注定要在苦难中成长！[@more@]
-
编辑 删除
RAC环境下死锁的问题
RAC环境下系统检测死锁的时间间隔由隐含参数_lm_dd_interval决定，缺省值是1分钟，这与单实例数据库是不同的。[@more@]
-
编辑 删除
死锁问题总结
工作中经常会碰到一些ORA-00060的错误，这里给个总结：[@more@]1、如何解读相关TRACE文件a.Current SQL statement for this session指的是接收到ORA-00060错误的会话正在执行的语句，该语句接收到错误后被回滚b.对于TX模式的X锁，下面的信息说明session 10在等待object_id为3062的对象(to_number('BF6','XXXXXX')=3062)的ROWID'AAAAv2AAEAAAAqKAAB'，session 11在等待object_id为3062的对象(to_number('BF6','XXXXXX')=3062)的ROWID 'AAAAv2AAEAAAAqKAAA'Rows waited on:Session 10: obj - rowid = 00000BF6 - AAAAv2AAEAAAAqKAABSession
-
编辑 删除
SHARED POOL总结
本文试图对shared pool的内部机制做一个总结，目的是加强对相关内容的了解。shared pool内存的几个特征：a.以CHUNK为单位，CHUNK大小不等，每个chunk跟x$ksmsp中每条记录有一一对应关系b.当会话结束，相关内存空间并不全部释放，因为无法预知这些信息会不会被后来的会话用到c.不能被PAGE OUT到系统的磁盘交换区，AGE OUT的是一些可重建的信息 [@more@]1、shared pool内存结构及内存分配方式shared pool 包含dictionary & sql区、保留区、永久区保留区存储大对象，大小由shared_pool_reserved_size决定，缺省为shared pool大小的5%，当
-
编辑 删除
呵呵，网上看到这样一段话，说得挺好！
为什么要言论自由? 世界公认的原因有三个:一、任何见解都有可能是正确的，所以某些人要压制任何一个论点的时候都存在可能性把真理压制了。二、所有论点多少都包含了一些对的错的东西，有合理的也有不合理的话，如果压制一种见解的话，就把其中合理的部分一并压制了。三、即使某种见解我们可以确认它是大错特错的，没有任何一点对的地方——虽然这是不可能的，但我们姑且相信这样极端的例子——即使是这样也有其存在的价值。因为它有助于我们分辨正确的见解，有助于我们去澄清正确的见解究竟是什么，以防正确的见解养尊处优失去了生命力和战
-
编辑 删除
给大表增加列的问题
不带default值会很快，仅修改数据字典，对修改之前的每一个ROW，不会有任何改变，对修改之后的每个ROW，会有新列的信息。[@more@]
-
编辑 删除
这个月是怎么了？
感冒+肠炎--->感冒（发烧，头痛）--->感冒（头痛）妈的，到底是怎么回事？突然想大吼一声：要么赶快好起来，要么，就让暴风雨来得更猛烈些吧？[@more@]
-
编辑 删除
IO 速度慢导致全表扫描慢的问题
前几天有个客户说同样一个全表扫描的语句在测试库上运行的速度要大大快于在生产库上的速度，并向我实际演示了一把。当时我也有点蒙，表的大小基本一样，执行计划确实是相同的，为什么会这样？用户说生产库的硬件条件要远远好于测试库......[@more@]经同事提醒，告知客户做IO速度的测试如下：分别在两主机上做下面的测试：$ time dd if=/dev/zero of=bigfile bs=512k count=1000测试库上返回的是：real 0m2.957suser 0m0.004ssys 0m1.960s生产库上返回的是：real 0m10.23suser 0m0.01ssys 0m1.83s显然生产库的IO速度比测试库上要慢得多。呵
-
编辑 删除
这些数据库块可以被重用吗?
前几天看到同事关于删除某些大表数据的方案，看后觉得有些疑问...... [@more@]同事的方案是这样的：首先将要删除的表的数据的rowid记录在某个临时表中，然后根据该临时表的rowid对相关表进行delete，采用批量delete，然后批量提交的方式。该方案对普通大表进行数据删除不失为一个好办法，但是他将要处理的表是分区表，这些分区表是以时间（YYYYMM）进行分区的，而删除的数据也是以时间作为标准的，那么新的数据能够使用这些已经被删除数据的数据块吗？不要忘了，这些数据块是属于那些不需要的分区对应的SEGMENT的。说明：不使用DROP和TRUN
-
编辑 删除
Sskgxp_ip: Primary Interface Down In Alert Log
Note:332517.1[@more@]Applies to: Oracle Server - Enterprise Edition - Version: 9.2.0.4.0This problem can occur on any platform.SymptomsMessage in alert file:SSKGXP_IP: Primary interface downoperation ioctllocation sskgxphypr3error Error 0 CauseThe message is trying to indicate that it was unable to send it's inter-instance communication over the private interconnect.The reason this is not necessarily an error, is because in the absence of the availability of the specified interconnect, inter-ins
-
编辑 删除
监听状态正常，但是数据库不能连接，提示没有监听....
用户反映监听状态正常，但数据库不能连接，提示没有监听，tnsnames.ora配置没有问题。检查listener.log，发现大量ORA-12502错误，推断是网络上有大量扫描监听端口的包导致监听进程无法有效处理用户的连接，因此出现没有监听的错误。后得到用户证实，去掉干扰源后正常。[@more@]
