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文件到