在报表数据库的后台alert文件中发现了这个错误，简单记录一下问题的诊断和解决过程。数据库版本9204 for Solaris sparc64。继续寻找源数据库和目标数据库执行计划不同的原因。一次ORA-4030问题诊断及解决（一）：http://yangtingkun.itpub.net/post/468/469922在前面的文章中，已经解决了问题，但是事情并没有结束。还没有找到导致问题的原因。上文以及提到，导致问题的三种可能性分别是本地设置问题、版本问题和迁移问题。现在通过第一篇文章的诊断，基本上排除了本地设置的问题，那么只有两种可能性了，版本问题和迁移问题。首先，9201到...

An anonymous tipster wrote to us this morning to tell us that Cuil, the ill-fated “Google Killer,” has unleashed its Twiceler indexing bot on websites across the globe and in the process, has brought many sites down.

“I don’t know what spawned it, but when Cuil attempts to index a site, it does so by completely hammering it with traffic,” the tipster wrote. “So much, that it completely brings the site down. We’re 24 hours into this “index” of the site, and I’ve had to restrict traffic to the site down to 2 packets per second, while discarding the rest, or otherwise it makes the site unusable.”

The Admin Zone forums are abuzz over Cuil’s overzealous method for indexing. Countless posters on the site have said that their websites have been brought down because of the Twiceler robot and one user said it “leeched enormous amounts of bandwidth — nearly 2GB this month until it was blocked. It visited nearly 70,000 times!”

Website owners are also saying that the way Cuil indexes sites isn’t scientific in any way and is actually quite “amateurish.” According to those who experienced the Twiceler onslaught, the bot seems to “randomly hit a site and continue to guess and generate pseudo-random URLs in an attempt to find pages that aren’t accessible by links. And by doing this, they completely bring a site down to where it’s not functional.”

Upset site owners contacted Cuil to see why Twiceler was hitting sites so often. James Akers, Cuil’s Operational Engineer responded to the issue by saying that “Twiceler is an experimental crawler that we are developing for our new search engine. It is important to us that it obey robots.txt, and that it not crawl sites that do not wish to be crawled. If you wish I will glad to add your site to our list of sites to exclude, but I need you to tell the site name to block as email return addresses frequently from the domains that wish to be blocked.”

Akers also claims that Cuil has seen a “number of crawlers” that pretend to be Twiceler, and site owners should consult the company’s IP addresses page to determine if it’s really Cuil causing all the trouble.

Cuil has yet to respond to a request for comment, but it doesn’t look like the pelting of sites by the company’s Twiceler bot is an isolated incident. And if it’s true that Twiceler is trying to find pages on sites that don’t even exist to simply increase the index size, Cuil should work quickly to modify the bot before it receives even more negative publicity.

Crunch Network: CrunchGear drool over the sexiest new gadgets and hardware.

这两天发现一个很好玩的现象。由于之前贴出重新启航的日记，颇有一些热心的朋友通过Gtalk、MSN向我询问并推荐工作。但无一例外，这些工作都是技术岗位。这时我才发现，由于使用被人认为较为技术化的Movable Type搭建独立Blog，并且涉足Movable Type的中文化，在众多朋友的心目中，我俨然成了一个互联网方面的技术能手。

但真实情况并非如此。实际上，从05年开始，我的主要工作就转到了互联网和软件的产品管理上，相继担任的都是公司产品经理、总监。只是出于惯性或工作的需要，一直保持着对互联网新技术的关注与追踪。不过随着工作角色的转变，我的Blog并没有发生明显变化，Movable Type中文化包照常更新，对互联网的观察与分析还是老样子，不过由于工作原因变得越来越少。这一切，给人造成了一个假象：我还是以前那个从事技术开发和平台支撑的我，虽然我从未单纯的专注于这样的工作。

这就是互联网！不管你使用的是昵称还是实名，他都可以为你造就一个与众不同的人格。互联网中的每个ID都是鲜活有生命的，这个ID要成为什么样的人，全由你的双手去创造，并进而影响你的本体。

所以，不要纠缠于真实与虚拟了，不管你有多少马甲，他/她都是你人格中的一部分。神仙的化身能力，在互联网中得以实现。不过要当心化身过多，造成人格分裂，嘿嘿。

2008年9月1日晚随想

呃，别会错意，我的意思不是说 MySQL 开始 filesort 就会不稳定，而是说他的排序算法不是 stable 的。

某表中有两个字段，一个是 log_time, DATETIME 类型， 一个是 user_id , BIGINT 类型。 SQL 是 SELECT XXX FROM xx_table WHERE user_id = 111 ORDER BY log_time DESC 。

一开始表上的索引建错了，建成了 user_id,log_time 的联合索引，于是上面的 SQL 用上这个索引以后，就做了 filesort ， 这时候发现所有 log_time 相同的列顺序是乱的，有的按照插入顺序，有的不是。而当重新建立 log_time,user_id 的索引之后，结果中 log_time 相同的就都是按照插入顺序来排序的了。

这个发现有啥用？似乎也没啥太大用处倒是。如果为了严格保持插入顺序，那么设计时候就应该用精度更高的 log_time 。不过如果对插入顺序的要求不是非常严格的要求，那么正确建立索引直接利用它的特性也还算省事。

系统管理员始终需要了解系统的性能。本文将深入探讨应该如何对 AIX 的各个方面进行优化，以运行 Oracle。我们将了解虚拟内存管理器 (VMM，Virtual Memory Manager)、CPU、内存和 I/O（磁盘以及网络）。我们将研究一些可用于分析瓶颈问题的工具，同时还将对系统进行某些更改。最后，我们还将回顾一些可用于帮助您进行性能优化的 Oracle 工具。

周末去了一趟香港，450D到手。

现在去香港还真是方便，从我家打车到西部通道20分钟不到，过关之后大巴40分钟到九龙塘。算上过关的时间，也就一个小时多点。10:30左右跟香港的同事在九龙塘地铁会合，直奔目的地旺角。

因为这事准备的充分，所以基本没浪费什么时间，同行的同事也早就准备好了攻略，先去几个比较大的店铺询价，百老汇和丰泽的价钱基本相同，港币6200左右，折成人民币跟深圳价钱一样。后去西洋菜街的久城大厦，结果碰壁，11点了都没开张，香港的夜生活比较丰富，所以店铺开张也一般较晚。路过电梯间的时候发现几个招聘广告，洗碗工/勤杂工等 月薪6500-7000，^_^

午饭之后，经过一番比较，发现久诚大厦9楼的恒康数码价钱最厚道，套机港币5880，另外送4G SD卡，相机包，电池一块，贴膜，三脚架。折成RMB也就5200多点，性价比比较高，当即入手。Canon这两个型号（450D & 40D）在香港和澳门地区的保修值的一提，一般国内的店都是全国联保1年，这两款机器在港澳地区购买，全国联保两年，而且还有一个附加意外条例，大致是说发生跌落，水浸，雷击盗窃之类的意外事件，第一年只需花600港币（40D是800港币）即可重新购置一台，第二年只需要花市价的一半即可购置一台。比较人性化哈。店铺老板在我买的过程中，反复强烈给我推荐Nikon的D60，看来也是不折不扣的Nikon的粉丝。后来我抵制住了便宜1000块的诱惑，还是入手了450，不知道日后会不会后悔

去香港购物的话，付款有三种方法：1. 直接拿现金，RMB在香港很受欢迎 2. 用刷卡，我咨询过银行，如果你走Master或visa线路的话，是要收大概1.5%的手续费，如果走银联的话，不用手续费，不过店家给的汇率可能没那么高。

PS: 发文的时候，发现Ningoo老兄这两天也新入手450D

Share This

今天遇到一个问题，同事来说归档目录已经全部删除了，但是归档目录的大小还是100%，且执行shutdown immediate挂死。

同时alertlog中也在不断的报错：

引起该问题的主要原因，就是在/arch目录下，使用了rm *命令来删除归档，但是当前正好有归档进程（arch）正在写出，rm后文件系统的句柄无法释放，因此空间也没有释放。

此时我们用shutdown immediate命令无法关闭数据库，这是因为，在现在的状态下，arch已经被撑爆，所有组的redolog均为非inactive状态，shutdown immediate需要做checkpoint，checkpoint会将dirty buffer中的东西写入到db buffer，lgwr的触发条件之一就是dbwr进程写db file，此时，lgwr发现所有的redolog都是非inactive状态，都不能写，继续寻求arch切出，以期待能写redolog。而此时arch目录爆满，因此就报上述的错了。

我们用shutdown abort关闭数据库后，空间就释放了。

我们在删除归档的时候，一定不能全部删除，一定要留最后一个归档，以防万一。最安全的方法，当然是在rman中用delete input删除了。

This week I’ve worked with the customer doing certain work during maintenance window which involved a lot of data copying around between MySQL boxes. We had prepared well and had measured how fast we could copy the data between servers of these kind connected to the same network, and we did the same thing before. Using simple tar+netcat based copy we can get 80-90MB/sec on 1GigE assuming RAID is powerful enough. This applies to large Innodb tables with not overly fragmented tablespace, or it is easy to become IO bound rather than network bound.

As I mentioned you can get even better with using fast parallel compression like LZO or QuickLZ but there was no need in this case.

So estimates were great but once we had started the real copy process we saw the copy speed about 20MB/sec instead of projected 80MB/sec. The IO and CPU usage both on source and target servers was low so it must have been network. Though there was no other traffic between the servers.

The mystery could be easily resolved while looking at network topology. Some database servers were connected to Switch A others to Switch B which had only 1Gbit connection in between.

During the maintenance window multiple tasks concerning different servers made this connection to be the bottleneck.

What does this tell us ? Even if you’re the DBA you better to understand network topology to understand what kind of performance availability and failure scenarios you should expect. If your network is too complicated it is at least worth to know the numbers.

It does not only apply to network but to any resource indeed. For example what if you have the catastrophic event and now would like to restore all 50 servers from backup… in parallel. Will you backup system will be able to restore these in parallel efficiently ? Will there be enough network bandwidth to pipe them through. These and similar questions are what you should be asking yourself.

---

Entry posted by peter | 3 comments

Add to: | | | |