ITPub博客

流量，咦，这个月的流量怎么又用完了。这个可能就是大家都有经历过的事，那么怎么知道流量用去那里。看我们来说说怎么防止流量无形中消耗。 方法/步骤 1 打开360手机卫士，点击流量监控，在这里设置你一个月有多少流量。这不是我们要多说的 2 点击联网防火墙，这里我们可以看到一些软件的使用情况，一般你可以对一些不在数据流量下联网或者wife下联网。当然这里还是需要获取权限的 3 其次本月流量排行中，

客户的系统进行压力测试时发现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、对查询来说尽可能数据在最少的块中得到（减少行链、行迁移

我捐了，捐的不多，1000元，但这是第一次，以后，还会有第二次，第三次，第四次。。。。每天打开电视，看得第一个节目，就是地震灾区的救灾直播，打开电脑，关注的第一个页面，就是地震救灾中又救了多少人，与朋友的聊天，第一句话，就是，你捐了了嘛。。。看着灾区那么多受灾的人，尤其是那一个个受伤的孩子，废墟中伸出的一双双手，心很难受。。。捐吧，捐了的钱我们还能挣，而这些钱对于灾区的人民，也许就是他们温饱的饭，避寒的衣，挡雨的伞，或者是减少他们痛苦的药，对于生命和享受，你还有什么可选择的，捐。。。震灾晚会在进行着

这两天最关心的莫过于数字——一个大地震的伤亡数字，一个在不断递增，不断在人们心上、身上刻着、刺着、划着，带来巨大伤痛的数字，从7000到8000多，到11000多，现在，已经12000多，而从报道的情况看，可能还会有更多，也许是2万，或者。。。看着心疼，尤其是看到那些照片，原本还天真活泼的孩子，没有了可爱的笑容，只剩下一本书放在脸上，遮盖着已经没有任何生气地脸，而那些父母，哭天喊地的悲痛欲绝，这不是人间惨剧，还是什么。为什么倒塌了那么多学校，为什么伤亡了那么多孩子，为什么这么大的地震居然一点前期预报都没有，只剩下心

今天，最大的事情看来就是地震了正在上网，一个消息从朋友的MSN发了过来，说西安地震了，而且在震中，让我赶紧跟家里联系一下。。。开始并没有太在意，在网上看了一下，震中不是在西安，而是在四川汶川县，不过地震等级确实挺高的。想了想，四川离西安还是有一定距离的，应该没事。没过多久，突然发现几乎所有的QQ群里都出现了大量的地震信息，北京地震。。。重庆地震。。。杭州地震。。。山西地震。。。连大老远的上海都有地震了，靠，那西安肯定也会震阿，赶紧打个电话吧。这一打不要紧，结果我们家3个手机没一个能打通的，从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

郁闷阿，这次飞行又在我悲惨飞行史中记录了一笔，上海虹桥飞太原，晚上8点45的飞机，由于上海下雨，在上海耗到晚上0点20才起飞，这还是好的，有个别航班等到晚上11点了，告诉说停飞。。。 飞到太原是晚上3点，这大半夜的，下来也没个大巴，只有少量出租车，而且坐地起价，原本打车到市里也就20多，结果晚上一个人就要至少30，还得搭4个人才走，不愿意被宰，心理上承受不了，犹豫之间，已经被一堆急于回家的人挤满了车，想坐也没得坐了。旁边几个人说不行往外走吧，也许外面有车，心想机场反正也没人，干脆跟他们一起走吧，于是步行走向太原

天上，又下起了细雨，虽然不大，确足以寒了路人们的衣衫和心情，每个人都缩着脖子，在雨中快步的行走，昨天这里还是大太阳晒着，而现在，已经阴雨密 布了。上海，时尚之都，我又一次来到这里，这一次，还是来得匆匆，去的一样匆匆。。。不知道是怎么得，好像天生八字跟上海不是很和，每次来的都匆匆，而走的总是不顺，已经好几次了，航班的延误似乎已经成了惯例，这次，也继续保持着一 如既往的优良传统，心情，也随着这延误的航班，重重的沉入谷底。身边人来人往，每个人都看上去表情沉重，焦虑的走来走去，或者哭丧着脸跟亲戚或者朋友打