ITPub博客

客户的系统进行压力测试时发现CPU压力非常大，正常情况下CPU负载在30-40%，而峰值期间CPU基本上100%，以至于事务无法处理完成，甚至无法登陆。经过客户的描述，这个压力测试实际上压力应该不大，仅仅设置了100个客户端的并发，而且单个客户端整个功能模块完成实际上仅需要25秒钟，但并发一多，CPU负载就非常高，以至于单个功能模块完成时间被延长至几百秒。到客户现场，在操作系统级察看，CPU大量消耗在user上，io的CPU等待很少，确定CPU是消耗在应用层面。[oracle@localhost ~]$ sar -u 3 50Linux 2.6.18-92.el5 (localhost.localdomain)

CREATE_TABLE_COST有两种用法，因此包内进行了overload，具体的语法如下：DBMS_SPACE.CREATE_TABLE_COST ( tablespace_name IN VARCHAR2, avg_row_size IN NUMBER, row_count IN NUMBER, pct_free IN NUMBER, used_bytes OUT NUMBER, alloc_bytes OUT NUMBER);DBMS_SPACE.CREATE_TABLE_COST ( tablespace_name IN VARCHAR2, colinfos IN CREATE_TABLE_COST_COLUMNS, row_count IN NUMBER, pct_free IN NUMBER, used_bytes OUT

最近有朋友问到了DBMS_SPACE包的使用，也看了一下，大部分是关于dbms_space.space_usage的使用，space_usage这个过程的例子已经很多了，我也就不再多说了，除了这个过程外，另外还有两个过程也有着特殊的用处，但使用的人不多，我们也来看看这两个过程有什么用。这两个过程为：CREATE_INDEX_COST和CREATE_TABLE_COST，分别用户评估创建索引和创建表的存储开销（空间占用情况）。CREATE_INDEX_COST的语法如下：DBMS_SPACE.CREATE_INDEX_COST ( ddl IN VARCHAR2, used_bytes OUT NUMBER, alloc_bytes OUT

4月20日晚19时40分消息，SUN终于卖了出去，但是买家不是IBM，而是IBM最大的竞争对手之一、全球最大的数据库软件商Oracle公司。收到这条消息已经是晚上10点，在告知其他几个朋友的时候，朋友说他们早就知道啦，看来我还是后知后觉阿。最近IT业好像很繁忙的样子，尤其是Oracle的老larry，就没见消停的，去年大手笔收购了BEA，感觉才有点点尘埃落地的意思，就突然冒出了这么个消息，而且还不像IBM，只是传出个要收购SUN的消息，Oracle直接发布的就是收购成功消息，看来larry不是一般的强势阿。IBM之前才传出60多亿要收购sun，紧接着就冒出个谈

今夜天高云淡，夜色迷人，正跟LP在餐馆吃饭，没事聊聊天，忽然电话响起，美好画面就此打破。。。客户紧急求助，让我立马赶赴现场解决故障，没法，跟LP致歉，然后飞奔出去，打着飞的就奔赴现场。故障情况如下：客户主服务器重大故障，盘阵损坏，暂时无法使用或者修复，不过磁带机上有Rman备份，因此选择了一台备用机进行修复，服务器为AIX4.3，Oracle为10g，单机，所有备份归档都有（这就放心了）。。。客户在做恢复时报错（一颗心立马揪了起来。。。不会备份的文件有问题吧），错误代码为ORA-01119和ORA-27040，也就是说，在restore文件到

早上就接到个电话，说是美国的快件，问我送到哪里，有点紧张的告诉快递公司我的地址，放下电话就开始琢磨，美国。。。。谁给我快递东西了。。。。难道是。。。。她。。。。不可能不可能。。。中午吃饭，又收到电话，DHL送的快递，说快到了，突然一个机灵，想起来会不会是上次Oracle的ACE发东西了，可是寄个衣服还需要从美国寄过来，成本高了点吧，还是有点犹豫。。。收到东西，果然是美国。。。。的Oracle寄来的，一个挺大挺扁的盒子，看上去应该是衣服了，打开一看，果然，好像是抓绒的衣服，夏天是不能穿的了，不然非得被送进安定医院去

周末，夜，放松了一天，周末的夜晚无所事事，本打算吃完了看看片，看完了睡睡觉，晃晃悠悠过周末。时近晚上10点，突然接到一个客户电话，一看号码，心说这可不好，肯定出问题了，希望不是大事。。。电话里，客户看样子还挺着急，原来是数据库起不来了，不过听上去问题不算太严重。客户下午本来要换UPS，结果正在备份呢，突然停电，这还没换掉的UPS再加上停电，结果服务器带存储一起就咔嚓了，等来电了把服务器都起来，结果发现，服务器上的三个库，其中有一个起不来了，故障呢，是open数据库的时候出现了SQL递归调用失败，访问undo表空间的

一直在高强度的运转，突然停下来休息，非常不适应，因此，病了。从初期的身体有点发冷，到后来喉咙痛，眼睛痛，头痛，现在还能动，不过非常的没有精神，看来忙得过度了，也是会得病的。还好，还年轻，熬过这几天，继续为了oracle的事业而奋斗。[@more@]

最近正好有朋友问起了块空间参数对性能的影响，简单写了几句，记录一下。 db_block_size是数据块的大小，也是数据库I/O的最小大小，对数据访问时的I/O性能影响大，而且创建好数据库后就不能修改了，所以最好在创建数据库之前确定 好，通常建议尽量使用较大的块，另外，块的大小也跟经常执行的并发事务数有关，过大的块也可能出现热点块竞争。对数据块的考虑通常从下面这几个方面考虑： 1、对查询来说数据块要足够大以减少I/O 2、对查询来说尽可能在块中放入更多的数据以减少I/O 3、对查询来说尽可能数据在最少的块中得到（减少行链、行迁移

在帮客户进行数据库巡检时发现，客户的库是从8i升级到9i的，因此，很多表空间仍然使用了原有的字典管理表空间模式，而这种模式的空间管理性能很差，因此建议客户将这些表空间全部换成本地管理的表空间，经过沟通，客户也认可此建议，因此，今晚开始实施。实施之前，对整个数据库进行了备份，这是传统，也是本能（希望以后做dba的朋友们也能养成这样的习惯，当然，这次的备份倒是没派上什么用处）丢弃字典管理表空间换成本地管理倒也不难，新创建本地管理表空间，然后把原来字典管理表空间上的存储对象移动过来就是了，对于表可以使用move，

怪事年年有，今年特别多，这不，又碰上件怪事。本来只是去给客户做个巡检，结果巡检顺利完成，客户顺便让我帮他们看个问题，说导出有问题，看看就看看吧。10g的数据库，命令行下作exp果然出错，报了一堆莫名的错误，居然还有600错误，参数值为BqmxtrScalarIsRewritable，查metalink吧，没有这个错误参数，查google吧，只有一个老外的blog提到了，但也只是他遇到了错误，没解决错误。。。啥问题呢，看其他提示信息，有点像数据库系统内部的问题。尝试做dbms_metadata.get_ddl，结果报错，看来的确系统上出问题了。没啥说的，调脚本重建数据

过程篇：今天准备给客户做一个数据库升级，aix5L平台上的9201升级到9206，这种事情做得也多了，本来没觉得会遇到什么问题，结果还是遇到了，幸好，问题不大。客户的数据库不大，不过比较特别的是，这一台主机上运行着多个数据库，所以升级之前需要先关闭所有的数据库。于是以正常的方式shutdown了所有的数据库，然后准备好升级的文件包并且准备好所有的目录。根据建议，打算重起一下主机，以确保彻底释放资源占用。按照我平时的习惯，直接reboot主机。现象篇：等了一会，估摸着主机起来了，连接上去，果然已经成功启动，这就打算动手升级数

上一次，测试了一下reset incarnation的作用，朋友又提出下一个问题，能不能跨多个实体进行恢复呢，理论上是可以的，不过没实践过，还是测试一下吧。--首先在实体5上进行全库备份RMAN> backup database format='c:bak%U.bak';启动 backup 于 26-3月 -08分配的通道: ORA_DISK_1通道 ORA_DISK_1: sid=142 devtype=DISK通道 ORA_DISK_1: 启动全部数据文件备份集通道 ORA_DISK_1: 正在指定备份集中的数据文件输入数据文件 fno=00001 name=E:ORACLEPRODUCT10.2.0ORADATAORCLSYSTEM01.DBF输入数据文件 fno=00002 name=E:ORACLEPRODUCT10.2.0O

上午刚处理完客户的一个问题，正在发呆，一个哥们在msn上跟我发了个链接，问起我Oracle里incarnation的问题，本来也没想那么多，回答了几个问题，后来觉得这么说说不明白，干脆做个演示好了，于是就在这两天，作了一些incarnation的测试。先解释一下我对incarnation的理解吧，incarnation，我把这个叫做数据库实体，不知道其他人怎么个叫法，从含义上看，它指的是一个重置scn后的数据库场景。一个数据库在刚开始被创建出来时，scn号为1，随着运行，scn不断单调递增，Oracle就是根据scn描述数据库的整个发展进程，可以说scn就是数据库的时间

平台：HP-UX B.11.23 ia64数据库：Oracle9i Enterprise Edition Release 9.2.0.2.0 - 64bit Production故障现象：客户SQL语句出现性能问题，本来想收集SQL跟踪信息，发现user_dump_dest无法写入，修改到其他路径下只能产生一次trace文件经过查找，发现background_dump_dest也无法写入trace文件，怀疑权限有问题，决定创建新的目录，并赋予合适属组及权限，将udump和bdump指向新的目录，经过测试，发现只能在每次指定新目录后产生一次trace文件，以后在其他会话启用跟踪也无法产生新的跟踪文件，重新切换新目录后又再次可以产生一个文件，然

今天，天气晴朗，心情也不错早上一大早就赶到客户现场，今天客户的主机终于到了，可以装数据库了，装好了经过验收，俺的那份￥就到手了，想想就觉得兴奋阿来到机房，客户已经上班了，人家比我来得早，已经把小机就位，准备好了网络环境，就等我开装了ok，保持着高度的兴奋感，开始工作。。。[@more@]今天，天气晴朗，心情也不错早上一大早就赶到客户现场，今天客户的主机终于到了，可以装数据库了，装好了经过验收，俺的那份￥就到手了，想想就觉得兴奋阿来到机房，客户已经上班了，人家比我来得早，已经把小机就位，准备好了网络环境，就

很久没有写blog了，最后一次动笔要追溯到04年了，这几年工作上、生活上都发生了一系列变化，事情越来越多，心情越来越浮躁，动笔写点东西就成了一件不可完成的任务。终于有一天，朋友的一句话惊醒了我，让我一下子从每天碌碌的快速奔跑中暂停了下来，停下来想这段时间发生的那些事，也许是该让一切恢复正常了，真正的生活也许应该重新开始了。屈指一算，做DBA已经6年多了，在这六年里，经历了很多事情，认识了很多朋友，逐渐从一个菜鸟成长为一个老鸟，对Oracle数据库的认识也越来越深刻。能够达到现在的水平，跟很多朋友的帮助是分不开的