2007年9月26日星期三

胡思乱想

本篇为乱文,不喜误入。

15年是个什么概念?6年又是个什么概念?如果我能活到80岁,大概能有5个15年,13个6年。从现在算起,大概还有3个15年,9个6年。有两个人,15年前在一起,最近的一次见面是6年前,其中一个,以后再也见不到了。

15年前,我们算是互相了解,而现在,虽然可以通过电话联系,声音也没有改变,但一种陌生和恐惧却油然而生。陌生是因为不知道他现在是什么状态?什么性格?作什么?想什么?喜欢什么?别人怎么看待他?由这种陌生产生的恐惧,在电话中提现不出来,可真有一天面对面坐下喝酒的时候,会在沉默中冲击心灵。

真是有些"物是人非",虽然树都砍光了,可路还在;以前的教室虽然从3层扩建成了4层,可样子没变;以前的平房都变成了楼房,可地名没变;以前的人还是那个人,可却已不再熟悉。

人能作的无非就是改变世界和改变自我,在良性循环体系中,天平平衡的两边,一旦天平倾斜,就像水车一样,把水倒了出来,稀里哗啦,天平的指针没有倾斜的概念,一下就到底了,从楼顶到地面。

我们很熟么?未必吧?但15-6=9年的时间并没有改变什么,再次聚会反而觉得更亲近了,大概是上学和工作之后的自由导致的后遗症,毕竟在老家憋的时间太长了,尤其是初中,回头看看和封建社会差不多。那个时代留到现在的,除了成为档案中的几页纸,学习工作的垫脚石之外,就是对朋友的感觉了。

感觉这东西很奇妙,有点像白酒或者普洱茶,怎么放也不变味,反而更纯了,就像一幅画,当你离的很近的时候,一切都能看仔细,会发现很多毛刺、花边和瑕疵,而当距离稍微远一些,这些不好的东西都看不到了,转而欣赏画的整体美,从而赞不绝口。人会很主动的"忘记"不好的记忆,残留的对很久以前的感觉自然是越发的美好。

提问,是要这种模糊的美好,还是要清晰的缺陷?

七百多公里不算远,开车一天,坐火车也是一天,坐飞机估计2小时就到了,可惜家里没飞机场,以前的所谓"飞机场"(记忆中只停过直升飞机,还是极其破旧,不知道是开走还是被汽车拖走的那种,放风筝的好地方)现在早就变小区了,我姐姐就在那里住,另外一个人在地势最低的地方,哦,那地方太黑了,以至于第二天我就忘记具体在哪个胡同里了,也许是酒和太多了的缘故,好在没说错话,也后悔没多说几句,其实也不敢,也不是不敢,是怕说了没用。

就这么点距离,就能让人生产生巨大的变异,时间是散射的催化剂,分道扬镳用在这里再合适也不过了,不过这条条道路并不都是通向罗马的。

如果真的有时间旅行,那么我想逆向运动,生命在于运动,岁数大点无所谓,能回到那个年代就好,比现在的环境好多了。现在的烦你比楼还多,以前的房子稀稀拉拉,烦恼也是稀稀拉拉。

宁愿相信宇宙中存在平行时空,更希望家里有一只机器猫,逼它拿一只望远镜出来,看看另外一个时空的人都在作什么。呃,如果是现在,应该是睡觉呢,不知道会作什么梦。再让机器猫拿个装备出来,到梦里去搅和搅和。除此之外,还能作什么呢。呆头鹅,痴人说梦,不知道眼不见心不烦么。

想什么就写什么,写什么就想什么,这种感觉真不错,只是难为看官了,如果你能逐字看到这里,还真是强人。

清楚的记得一些事,我给你看的东西,现在已经成为现实,我给你说的话,可能当时被你当作笑话,也没有达成传声筒的作用,不过都无所谓了,这些所谓秘密,现在一半在我这里,一半已在地下,永远的绝版了。关于传声筒,还是那句话,物是人非。有一点我望了,是你猜中的,还是我自己说的?实在记不清了。

那个谁,发什么呆呢,说的就是你,就是你,知道不?呆头鹅,不过鹅现在正痛苦并快乐着,岁月的枷锁已经深入骨髓了,可怜啊,谁又不可怜了啊,想起来有些事确实挺郁闷的,郁闷这个词用再这里太合适了,发明这个词的人我很崇拜。

世界上最远的距离大概就是电信和网通吧,不过这是在第一宇宙,在第二宇宙,是两个猪头之间的距离,因为一头并不知道另外一头是怎么想的,唉,希望在第三宇宙能有所改观。相信我,人是一个思维体,其它的都是在matrix中的虚无,都素浮云。思维体之间的沟通就像磁铁,对味儿了就相吸,不对口味就排斥,最痛苦的就是中间路线,上不去下不来,还吃不到茴香豆,百年孤独。

铁路还有换轨、错轨的时候,岁月却是单行道,即使兜个大圈子能回到原地了,却发现其实不在一个时空,不兼容。

突然又有一种更不好的感觉,觉得死去的人还活着,而活着的人已死亡。死亡,是美好事务永保青春的最好方式,so,本文就在这里太监了吧,8月16的月亮值班,我去睡觉了。

Source: http://www.fwolf.com/blog/post/356

索引的问题(未解决)

服务器环境:windows2000,sybase ASE 11.9.2

一个表,里面的三个字段A B C均为字符串类型(varchar或者char),其中C的实际数据为c1, c2, c3等有限的几种。表的主键和索引都不是ABC三个字段。下面的sql语句:

SELECT * FROM tbl_name WHERE A='a' AND (C='c1' OR (C='c2' AND B='b'))

是能够正常执行,得到数据的。但是当在字段C是创建索引:

CREATE INDEX idx_name ON tbl_name(C)

之后,上面的SELECT sql语句也能正常执行,但却无法得到数据了。而在创建索引前后,符合WHERE条件的数据是肯定存在的,所以可以理解为这个索引导致了sql的执行结果无数据;在删除索引之后,马上就又能取到数据了。

这是索引有问题?还是索引损坏?还是其它的什么问题?

Source: http://www.fwolf.com/blog/post/355

2007年9月21日星期五

触发器的教训

触发器是高级dbms的特性之一,可以在数据insert、delete或者update的时候,自动的进行处理,比如根据变化的数据内容对其他数据进行适应性调整。但今天我却因为这个遇到了一点小麻烦。

我的数据库是sybase 11.9.2,这个版本不支持ALTER TABLE tbl_name MODIFY col_name datatype语法,所以只能采取变通的方式,比如要把col从decimal(8,2)更改为decimal(14,2)类型:

  1. 新建colA,类型为decimal(14,2)
  2. UPDATE table SET colA=col
  3. ALTER table DROP col
  4. sp_rename "table.colA", col

但过程中,接二连三的遇到问题,首先进行SET colA=col的时候,由于表含有一个非主键索引,所以很慢,这个只能忍,下次记得先删除索引,好在数据不多。

然后是锁类型,为了提高并发性我更改成了DATAROWS,而这种锁类型下是不允许DROP column的,所以要变更回ALLPAGES,DROP列之后再变回来。

然后是sp_rename存储过程出了莫名其妙的错误(忘记具体内容了,反正不能用),所以上面的第4步变成了再新建列col,然后SET col=colA把值再写回来,然后再删除colA。

最后,也是最致命的问题,就是这个表上还有update和delete的触发器,我太大意了,以至于在第二次UPDATE的时候才发现,但这时已经晚了,整表的UPDATE,还有其它的一些实时处理,让整个数据库系统几乎瘫痪,虽然进程不多,但由于表之间的关联和sybase的加锁机制,很多进程都成了send sleep或者sleeping状态,再过一会儿,日志满了,又多了一些等待日志空间释放的sleep进程。这个时候, drop trigger操作已经无法执行了,一方面是drop trigger和这个表的其它进程锁冲突,另一方面是当事务正在进行的过程中无法truncate日志。最后,只能中止客户端操作,并重启数据库服务。

真正的噩梦才刚刚开始,drop trigger之后,所有update操作都完成了,col类型更改的任务完成了,再重新把trigger建上,但很快发现,只要有针对这个表的update操作,即使操作的对象集为空,数据库服务器也立刻陷入一种死循环状态,update操作永远执行不完,并且进程无法kill,用户越连越多,最后不仅日志很快又满了,而且用户连接数也用完了。找了一下午原因,发现还是drop掉这个update的trigger之后就没问题了,猜测可能是由于某种客户端操作的中止,使这个表的为触发器预留的inserted和deleted数据缓存滞留在系统中,并随着trigger的触发再次被处理,进入死循环,重启服务之后,依然存在,然后再被触发,再造成死循环。

最终,新建了一个同结构的表,把数据全部导过去,然后重建索引、触发器,最后再删除旧表,把新表的名称改成现在用的这个,问题终于解决了。同时也从侧面证实了我的猜想,问题就出在这个表上。按说sybase应该不会出现这样的问题的。

总结一下,再更改字段类型的时候,应该按照这样的顺序操作:

  1. 删除触发器和索引
  2. 添加新字段colA
  3. col的值赋给colA
  4. 更改锁类型为ALLPAGES
  5. 删除字段col
  6. 更改锁类型为DATAROWS
  7. 添加新字段col
  8. colA的值再赋给col
  9. 更改锁类型为ALLPAGES
  10. 删除字段colA
  11. 更改锁类型为DATAROWS
  12. 重建索引和触发器

重复更改锁类型的原因是在ALLPAGES锁类型的情况下,进行update的操作比较慢,影响其它同时进行着的操作。并且在高版本的sybase,比如ASE 15下,就不用这么麻烦了,可以使用"ALTER TABLE tbl_name MODIFY col_name datatype"这样的SQL来直接实现。

Source: http://www.fwolf.com/blog/post/354

2007年9月10日星期一

更加混乱的yahoo id

Yahoo!和中文雅虎虽然形式上已经分了家,但在技术上还没有,比如登录的时候依然是一个账号通用,所以我就当是一个网站来说了。

Yahoo!虽然现在已经不比当年风光了,可依然还是大哥级别的,在中国的分铺也算是国内的一大门户,但就我个人直接或间接使用Yahoo!服务的体会来说,Yahoo!的用户id是越来越乱了。

  1. 挑个好名字暴难

    从我开始上网那时(1999年吧)算起,yahoo id就已经很难注册了,稍微顺口一点的不带上数字根本申请不到,经过近几年的发展,估计中文拼音的组合也用得差不多了,很多朋友都在用拼音+数字的id,可怜,更不幸者,会在id中带上一个经常被小白们输成中文符号的-或者_。

  2. 你的邮箱后面到底有没有".cn"?

    goodboy@yahoo.com邮箱和goodboy@yahoo.com.cn邮箱是一个么?打电话询问别人邮箱地址时,一定要问清楚,不然你的信不定会到谁手里呢。

  3. @yahoo.cn邮箱搅局

    嗯,这个新邮箱我照例"抢注"了个id,不是真的想去用它,而是怕被别人注了冒我的名来作坏事,不好的一面是,下次打电话问别人邮箱地址的时候,不仅要确认后面有没有".cn",还要问问带不带".com"才行。

  4. @yahoo.cn邮箱居然整体就是一个雅虎id

    雅虎的@yahoo.cn邮箱上线之后,邮箱登录界面就不再是只输入id就行了,要输入整个邮箱地址(比如goodboy@yahoo.cn)才行,这说明邮箱地址成为了雅虎的用户名,虽然现在用邮箱作为id的网站不少,可是,你知道你注册的@ yahoo.cn邮箱同名的@yahoo.com.cn邮箱是谁的么?

所以,@yahoo.cn邮箱除了是一次炒作之外,我还真看不出有什么实际的作用,在现在邮箱普遍上G的环境下,把空间用尽的肯定不多,但常忘记注册名的人肯定不少。

还好,这些都是雅虎中国在折腾,英文Yahoo!依然是有一个id就通行了,不知道@yahoo.cn的id去英文Yahoo!登录是怎样的?我试了一下,居然还能够自动进入中文界面的邮箱(和直接在中文雅虎登录是一样的啦),不过在"我的账户"中无法更改语言,这一点和@yahoo.com.cn不同,看来是一个更本地化的阉割版本了。

Source: http://www.fwolf.com/blog/post/353

2007年9月5日星期三

让numlock开机就亮的方法

numlock开机就亮,输入数字的时候就不用再按一下NumLock键了,有时候总是忘,所以事虽然小但很不方便。从网上我一共找到3种方法:

1、在/etc/rc.d/rc.local中加入:

for t in 1 2 3 4 5 6 7 8
do
setleds –D +num
$t>/dev/null
done

不过setleds在我这里怎么用也不行。

2、在/etc/console-tools/config这个文件靠近最后的几行:

# Turn on numlock by default
#LEDS=+num

去掉第二行的注释就可以了,不过好像只能用于纯控制台,对图形界面无效。

3、先安装numlockx这个小工具:

sudo apt-get install numlockx

然后编辑/etc/X11/gdm/Init/Default这个文件(注意备份),在最后一行exit 0前面添加:

if [ -x /usr/bin/numlockx ]; then
/usr/bin/numlockx on
fi

然后再重启就可以了,在我的Ubuntu 7.04,xfce桌面环境下成功。

参考:

Source: http://www.fwolf.com/blog/post/352