ITPub博客

一直以来只是听说裸设备如果能提高性能，如果没有文件系统管理方便等等，昨天看了一篇文章后，终于明白什么叫裸设备了，下面的例子是在一个3节点的rac环境下的一个节点测试的，盯着一个节点做是为了避免过多的cache fusion而影响性能测试。环境如下：存储：emc cx500主机：dell 1950OS:redhat as4u4 64bitDB:oracle 10.2.0.2[@more@]在存储上划出一块空间10G，然后把这个lun分配到已经存在的三个节点共享的STORGE GROUP中，依次重启每个节点（据说不重启也可以的，不过我一般选择重启，因为是rac环境，所以每次启动一个也不会使得数据库宕

一个应用，突然出现响应缓慢，查看一下等待时间，发现有很多的数据读取的等待，而且每次执行读取的BLOCK数量明显比之前多，看看SQL的执行计划，发 现跟之前的执行计划不一样，多了一个MERGE JOIN CARTESIAN 的过程，把这些进程杀掉，刷新下SHARED POOL，然后等SQL重新请求进来被解析，执行计划已经正确了，下面来看看这个MERGE JOIN CARTESIAN 是何方神圣[@more@]先来看看SQL：SELECT /*+ USE_NL(store) INDEX(store EI_ATTRSTORE) INDEX(dn EP_DN) FIRST_ROWS */ STORE.ENTRYID, STORE.ATTRNAME, NVL(STORE.ATTRVAL, ' '), NVL(STOR

一台DB今天负载一直很高，而且主要资源是消耗在CPU，其中有几个进程，对CPU资源的使用一直是100％。查看等待情况，基本都是在等待latch free事件。看看SHARED_POOL，还有很多空闲的空间，根据V$SESSION_WAIT的P2参数去V$LATCHNAME中查询，发现是一个simulator lru latch的LATCH，这抓瞎了，没思路了。拿这咚咚去搜索下吧，到METALINK上就发现一个很明显的BUG－－5918642。[@more@]大意思就是说，如果打开了DB_CACHE_ADVICE参数，就可能撞上这个BUG：DescriptionHigh simulator lru latch contention can occur when db_cache_advice isset

基于DATAGUARD的RMAN备份，每天晚上自动进行，今天早上发现昨天的备份有点异常，alert.log中记录了备份的时候发现一个数据文件中有坏块，可是重新读取的时候坏块却又好了，记录一下。[@more@]当时的alert日志中的记录如下：Fri Mar 7 05:14:08 2008Hex dump of (file 7, block 578668) in trace file /u01/app/oracle/admin/billdb/udump/billdb_ora_7287.trcCorrupt block relative dba: 0x01c8d46c (file 7, block 578668)Fractured block found during backing up datafileData in bad block: type: 6 format: 2 rdba: 0x01c8d46c las

之前的NETAPP存储一直使用的是默认的MOUNT协议，也就是NFS3的协议，因为一个应用需要使用NFS4的协议，于是开始了苦难之旅。 首先默认情况下NFS4协议在NETAPP存储上是没有打开的，这个打开很容易，基于WEB的图形界面没有配置的地方的，只能通过命令行进行配置。登录进 去，然后使用options nfs.v4.enable on命令打开NFS4协议，这时候会提示说在冗余机头的情况下，那边机头也要搞，否则发生FAILOVER的时候那边就不能提供NFS4服务了，于是把两 边都搞好，在VOL上划了个QTREE，把QTREE EXPORT出去，然后就开始在客户端折腾。[@more

国庆期间重新整理了机房，一堆机器移行换位，估计oracle没有关闭就直接拔电源了。到今天开发人员报告一台测试的db连不上，于是处理开始。[@more@]因为这台机器的数据库是开机自动启动的，直接登陆上去查看listener状态，正常，然后登陆到数据库中查看数据库状态：SQL> select open_mode from v$database;OPEN_MODE----------MOUNTED奇怪，于是先把数据库关闭，然后重新启动，报错如下：SQL> startupORACLE instance started.Total System Global Area 1375731712 bytesFixed Size 1260780 bytesVariable Size

转载自：http://www.linuxdiyf.com/viewarticle.php?id=89776很多人会遇到在操作系统上rm掉一个大的文件，以解决文件系统超标的问题，可是有的时侯文件删除掉了，而空间却未释放出来。论坛上也常常见这样贴子，为什么会这样，如何解决呢？本文只局限于Hp unix的操作系统。原因其实很简单，主要是因为被删除的文件在删除的时侯还是进程在操作(打开、访问等)的缘故，rm只完成了在磁盘上文件实体的释放，而类似free list结构中相应的文件系统因进程的操作相应的inode并未释放。[@more@]这样的问题解决起来也很简单，找到操作的进程，kill掉就

问题提出：一个三表链接，其中都是通过主键来链接的，而且查询条件只有一个，而且这个列的选择性非常高，基本上99.9的数据都不相同。其中一个表数据量在千万，其他在百万，这个sql一天会执行几十万次，占用了大量的系统资源。[@more@]查看后得知千万级的表是分区表，根据时间进行分区，10天一个分区。其中查询条件上也建立了索引，不过建立的时候因为在分区表上建立索引，所以建立的缺省是LOCAL的索引。因此导致sql运行的时候，虽然可以正确的使用索引来查找，但是却要跨越多个分区才能找到正确的值，并得到ROWID再得到表中的数据。因为开

一个应用上线后发现一个使用SEQUENCE值来生成的主键经常出现断号，而且断号不是一两个，而是每次几十个几十个的跳。而一般能想到的导致这种跳号的 基本就是事务ROLLBAK了导致取出的SEQUENCE没有被插入到表中去，或者就是数据库关闭或者宕掉，导致已经CACHE的SEQUENCE的值丢 失，导致的跳号。而在这个场景下，这两种情况都被一一排除了。那么到底什么原因导致的SEQUENCE跳号呢？[@more@]一般为了提高从SEQUENCE取值的效率，我们都会对SEQUENCE设置CACHE，而且取值越频繁的，CACHE值设置的越大。那么这个CACHE的值是保存在SHARED POOL

为生产系统扩容，准备把两台rac的机器的内存全部从8G升级到16G，凌晨3点开始实施，方案如下：首先应用全部切换到节点1，然后停节点2，加内存，然后节点2起来，不幸发生，节点2的ASM实例启不来，本来实例是自动启动的，手工去启动也启不来，磁盘不能被MOUNT，报错如下：Errors in file /u01/app/oracle/admin/+ASM/udump/+asm2_ora_11560.trc:ORA-00600: internal error code, arguments: [kfgFinalize_2], [], [], [], [], [], [], [][@more@]打开trace文件，错误如下：ksedmp: internal or fatal errorORA-00600: internal error code, a

很多人都知道ORA_ROWSCN可以表示表中某行记录的SCN号，从这个SCN号可以大致推算出这行记录最后修改的时间是什么时候。不过创建表的时候如 果没有显示的指定表的rowdependencies属性，那么这里的ORA_ROWSCN就是指这个BLOCK中的所有行的最后修改时间，这个时候使用 ORA_ROWSCN来判断单条记录的修改时间就不那么靠谱了（不过标题里的不靠谱并不是指这个），但如果应用比较特殊，比如是记录日志，表中数据不停的 插入，没有更改和删除，那这个ORA_ROWSCN还是可以基本判断每条记录的大致插入时间的，所以这要具体情况具体分析，不能一棍

ORACLE 10G中，对于空间的回收利用已经有了很大的提高，这里讨论的只限于在线系统的空间回收，而对于应用可以停的回收方法，比如CTAS然后TRUNCATE原表，然后再把表RENAME回来这样类似的方法不做讨论。对于但表的回收技巧，比如MOVE、SHRINK等也不错过多的描述，只需要提醒大家注意的是MOVE会锁表，所以在线系统请谨慎使用，而且MOVE后，表上相关的索引会失效。虽然表的MOVE有ONLINE选项可以使用，但这个ONLINE只能用在IOT的表上，而普通表不能使用。另外使用SHRINK的时候，表的第一个EXTENT很重要，如果这个EXTENT在数据文件中的位置很靠后

问题的提出：在并发的环境下，每个sql先执行的不一定先提交，因此想如何才能按照事务提交的顺序来对记录进行排序而不是按照sql执行的时间。[@more@]先来说说sysdate或者systimestamp，如果系统中使用这样的列来记录每个记录最后提交的时间，那是错误的。而且很多人认为这个时间如果设置为default值，那么记录的就是sql执行的时间，其实也是错误的。oracle 10.2 版本的concept第388页有这样一句话“Default values are included as part of an INSERT statement before the statement is parsed.”因此可以看到，把列的default值设置为缺省

很早之前给开发建了两套环境，今天有同事提出说两套环境经过长时间的折腾，两边很多不一致，于是决定从一个库来同步另一个库。首先想到的最简单的办法就是把源库宕下来，然后冷备过去，然后得到两个完全一致的库。等做完了，目标数据库起来，登陆进去，一切正常。结果在执行最简单的sql查询的时候报错，ORA-06553: PLS-801: internal error [56319]，执行多个不同的sql反复报这个错误。[@more@]网上搜了下，看到有人碰到过类似的情况，结果被我也撞上了。源库是64位的OS，目标库是32位的，晕！公司32位的机器都是老爷机，只有那么两三台还

一个使用ASM的单机数据库，重启后发现ASM起不来，报错说无法跟CSSD通信。CSSD应该是系统启动的时候自动启动的，LINUX系统，启动的脚本 就写在/etc/inittab文件最后的，查查后台的/var/log/messages，发现有报错信息： Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.16546，这个错误太熟悉了，捣鼓RAC的时候碰到很多次，无非就是设备找不到啦、权限不对啦等等，而且更详细的信息一般都在 /tmp/crsctl.16546里面，明确告诉你是什么问题。于是查看/tmp/crsctl.16546文件，发现居然是空的！这下傻眼了，

很多人都说成功是被逼的，不是别人逼你，就是自己逼自己。我自己就被逼无奈充当了次山寨版800。 SUN的NAS存储因为机房温度过高没有响应了，以前也发生过类似故障，都是温度降下来后重启就好了，这次温度下来后，重启，启不来了，再重启，还是起不 来，可是存储这种高级货除了重启我也没啥招啊，只好打800报修，800给我开了个CASE，说一会会有工程师联系我。在等待工程师的过程中，经过反复重 启，串口连上去发现了点报错信息，如下：[@more@]Oct 11 03:47:44 svc.startd[45]: svc:/appliance/kit/akd:default: Method "exec

问题描述： 一个压力测试环境，需要模拟大量数据，于是写了个job在周末跑，结果今天来看结果的时候，发现由于产生大量的归档日志，导致磁盘空间耗尽，job已经停了。看看数据也造的差不多，也没在意。于是QA开始做压力测试，但是压了一段时间去看AWR报表的时候，却发现最新的报表只到周末为止，没有新的自动收集的报表产生？？？[@more@] 这样的问题是第一次碰到，首先到DBA_HIST_SNAPSHOT查询最新的记录，结果确实没有最新的记录产生。接下来手工的去创建一次信息统计：SQL> exec dbms_workload_repository.create_snaps

如果/VAR/LOG/MESSAGE中出现了上面的错误，那就是因为某些进程因为内存不够而被系统自动杀掉了，系统自动杀掉某些进程主要是出于对系统整体的保护，避免整个系统HANG掉。下面转载的文章中详细描述了这种问题发生的原因和避免的办法[@more@]http://www.redaht.com/archives/redhat-list/2007-August/msg00060.htmlSince this problem seems to popup on different lists, this message has been cross-posted to the general Red Hat discussion list, the RHEL3 (Taroon) list and the RHEL4 (Nahant) list. My apologies for not havi

这个报错其实跟上一篇的ORA-00600是连在一起的，当时只顾着看600了，等7445再次报出来才发现这也是一个BUG。这个错误的 ML:462440.1，是一个未公开的BUG，BUG ID:4085252。这样的错误也没太多可分析和学习的，转贴下ML的文档玩完吧。[@more@]Applies to:Oracle Server - Enterprise Edition - Version: 10.2.0.3.0This problem can occur on any platform.SymptomsThe following errors are encountered:ORA-07445: exception encountered: core dump [kksIsNLSEqual()+72] [SIGSEGV] [Address not mapped to obj

当初第一次做rac安装测试的时候，找了一个免费版本的vmware server 1.0.3，因为公司的服务器都是64位的，而且也都是安装64位的os和oracle，所以就想当然的去创建一个64位的操作系统，结果发现不行，说我的cpu不支持64位的虚拟系统。开始以为是免费的vmware的限制，也没多想，就直接下载32位的oracle和cluster开始安装。今天才发现了一个官方的解释，记录一下。[@more@]http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1901vmware上的官方链接上介绍了支持64位虚拟系统需要的cpu