SQL> shutdown immediate;
Database closed.
Database dismounted.
ORA-00600: internal error code, arguments: [LibraryCacheNotEmptyOnClose], [], [], [], [], [], [], []

看到是LibraryCacheNotEmptyOnClose错误，感觉问题好像不是很严重，就先把归档打开，把数据库启动好再说。幸运的时，在重启到Mount，打开归档，打开数据库这个过程都没有报错。

事后，用Google搜索了一下ora-00600 librarycachenotemptyonclose，发现是一个bug [Bug 4483084 OERI[LibraryCacheNotEmptyOnClose]，Metalink账号过期了，也没办法下载了，测试环境也不打算打补丁。

看了网上一个博客，说建个触发器，在关闭系统时执行“ALTER SYSTEM FLUSH SHARED_POOL”就可以了。没有亲测，再说也是不定期发生。

附触发器脚本

CREATE or replace TRIGGER flush_shared_pool
BEFORE SHUTDOWN ON DATABASE
BEGIN
execute immediate ‘ALTER SYSTEM FLUSH SHARED_POOL’;
EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR (num => -20000, msg => ‘Error flushing pool’);
END;

–The End–

今天有个主机，上面没有安装Zmodem协议。使用rz没法传文件上去。于是打算安装一个Zmodem协议包。安装方法很简单，插入光盘（本人CentOS系统），

rpm -ivh lrzsz-xxx

如果机器连网，使用yum安装就可以了。

yum install lrzsz

安装后，就可以使用sz,rz下载，上传文件了。

–The End–

1、系统权限UNLIMITED TABLESPACE 不能被授予role，可以被授予用户！

2、UNLIMITED TABLESPACE 没有被包括在resource role中，但是UNLIMITED TABLESPACE 随着resource的授出而被授予用户的。

3、UNLIMITED TABLESPACE 不能伴随着resource被授予role而授予用户。

相关数据字典：DBA_SYS_PRIVS,DBA_ROLE_PRIVS

–The End–

后面在一个页面上，有人说安装“米人”后，就不能“以管理员身份运行了”。而我也安装了米人下载工具。卸载掉以后，再在快捷方式上“以管理员身份运行”就正常了。

－The End－

UPDATE 失败，因为下列 SET 选项的设置不正确:’ARITHABORT’。请确保 SET 选项可正确用于计算列和/或查询通知和/或 xml 数据类型方法的索引视图和/或索引。”

报错显示，和ARITHABORT这个参数有关系，查看文档

－－－－－－－－－－－－－－－文档分隔线－－－－－－－－－－－－

SET ARITHABORT

在查询执行过程中发生溢出或被零除错误时终止查询。

语法

SET ARITHABORT { ON | OFF }

注释

如果 SET ARITHABORT 为 ON，则这些错误情况将导致查询或批处理终止。如果在事务内发生错误，则回滚事务。如果 SET ARITHABORT 为 OFF 并且发生了这些错误之一，则显示一条警告消息，并给算术运算的结果赋以空值。

说明  如果 SET ARITHABORT 和 SET ARITHIGNORE 都没有设置，则 Microsoft® SQL Server™ 将在执行查询后返回 NULL 和一条警告信息。

如果 SET ARITHABORT 为 OFF 并且在对表达式的求值过程中 INSERT、DELETE 或 UPDATE 语句遇到算术错误（溢出、被零除或域错误），SQL Server 将插入或更新 NULL 值。如果目标列不可为空，则插入或更新操作失败并且用户收到错误信息。

如果 SET ARITHABORT 或 SET ARITHIGNORE 为 OFF，并且 SET ANSI_WARNINGS 为 ON，则当遇到被零除或溢出错误时，SQL Server 仍返回错误信息。

SET ARITHABORT 的设置是在执行或运行时设置，而不是在分析时设置。

在计算列或索引视图上创建或操作索引时，SET ARITHABORT 必须为 ON。如果 SET ARITHABORT 为 OFF，计算列或索引视图上带索引的表上的 CREATE、UPDATE、INSERT 和 DELETE 语句将失败。有关计算列上的索引视图和索引所必需的 SET 选项设置的更多信息，请参见 SET 中的"使用 SET 语句时的注意事项"。

－－－－－－－－－－－－－－－文档分隔线－－－－－－－－－－－－

看了文档，也想不明白为什么索引重建了，作业就失败。Google了一把，原来这个问题会出现在计算列和索引视图上。而我INCLUDE字段的恰好是计算列，于是问题就出现了。

修改作业里的步骤，在语句前面加入一行

SET ARITHABORT ON

再执行作业，就正常了。

－The End－

看到这个错误，原因很简单，估计是哪个同事打开表被锁定了。站起来吼了一声，没有人应，只好自己去杀进程了。

查杀进程，就要查到进程。

这个语句查看被锁定的对象，找到需要加字段的表
select /*+ rule */ * from dba_objects where object_id in (
select id1 from v$lock where type = ‘TM’);

这个查锁住这个对象的sid,其实可以把上面语句改成关联查询
select * from v$lock where type = ‘TM’;

查询这个sid是哪个人的，当然更主要是看SID,SERIAL#
select * from v$session where sid=126;

杀杀杀，或冲到锁表的同事那里让TA释放锁
alter system kill session ‘126,2154’;

然后就顺利添加字段成功。

–The End–

微软免费广告真是无处不在呀！

–The End–

先看图

对这个服务的介绍就看这里吧。

http://zh.wikipedia.org/wiki/ReCAPTCHA 或　http://baike.baidu.com/view/1944705.htm

官网:http://recaptcha.net/

现在国内新浪也开始搞微博了，搞了个邀请码注册了一个。

我的新浪微博http://t.sina.com.cn/funcc

我现在还没有办法邀请别人注册，想获取邀请码的请点这里

–The End–

安装宽带，首先想到的就是电信ADSL了。本人在上海，之前安装过有线通，那个速度真是太不稳定了，下载ORACLE最快达到过5MB/S，慢时网页打不开。可是跑到电信营业厅，报上小区的名称，电信说我们小区的线用完了，暂时还安装不了，要等一段时间，于是安装电信ADSL搁浅。

前不久，联通来小区打广告，安装宽带比电信的便宜，销售还说是FTTB+LAN方式的，上下行是对等带宽的。还说我们小区是附件第一个安装联通宽带的。我也信以为真了。因为在郊区，郊区版宽带便宜一点，我就申请了4M的宽带，交了钱等安装。终于在周末等到安装上门，看到安装人员手拿ADSL猫，我还纳闷。一问才知道，原来我安装的是联通的ADSL宽带，也就是网通ADSL，有种上当的感觉，不过比电信的便宜，看在价格的份上，我也没有多讲什么。唉，看来小白鼠也不好当。

–The End–

等待了两天，电视终于在周日中午送到家了。本想迫不急待的打开，但看到京东上说建议让厂家来开箱。于是我就打箱子上的400电话，客服告诉我他们只管维修，不管开箱什么的，让我打厂家，问客服厂家电话，也不知道；在网上找到一个长虹的厂家电话，打电话过去，说可以自己拆箱，我说拆开有问题怎么办，又让我打400电话。严重BS一下长虹，售后做的真不怎样。最后自己开箱，还好没磕碰，加电开机也正常。

家里没有买电视之前是用显示器加电视盒看的电视，把电视盒上的有线电视线拔下，接到电视上，搜台，大约一分钟，台搜好了。浏览了几个频道，发现都不怎么清晰，有不少雪花，以前用显示器看时可能屏幕小，没怎么觉得。马上把早就买好了的秋叶原的双磁环有线电视成品线找出来接上，画面立马清晰了。爽！看来秋叶原的线材还真不是盖的，严重建议家里电视不是很清晰的网友换根线试试，最好是带双磁环的。

液晶屏有没有坏点是个重要指标，网友大部分都是接上电脑去测试的。因为这款有USB接口，可以放视频和图片，于是在电脑上用画图制作了5张图片(大小1920*1080，颜色：黑、白、红、绿、蓝)，把图片放在U盘里，插到电视上，看这5张图片，可能眼拙，没找到坏点，窃喜。

另外网上有网友说这款支持1080p，不过我看说明书，里面HDMI信号最佳为1080i，估计只支持1080i吧。

总的来说，这款电视还是不错的，价格便宜，性价比高。

–The End–

后记：最近下载了些RMVB的片子，用移动硬盘连接上去看电影，还真是不错，比较方便。

sudo apt-get install smbfs

安装了samba文件系统的支持后就可以挂载windows共享盘了。

sudo mount -t smbfs //192.168.1.101/e$ /mnt/ -o username=administrator,iocharset=utf8

输入windows的administrator密码，就把//192.168.1.101/的e盘挂载到/mnt/下了。

加iocharset=utf8是可以正常显示windows下的中文文件名，告别乱码。

–The End–

下面是多网上找来的。

S1 硬启(恢复原厂值) S1进入三色屏(工程模式)

S1 硬启方法：
同时按住挂断和接听键，不要放手，然后用笔捅S1的小PP（捅一下就可以了）。（注意：捅完PP后左手不要放开按键）
一直看到黑色屏幕上面出现英文字母，放开挂断和接听键，然后按一下导航键（中间的大方框），这样就完成硬启.

S1进入三色屏方法：
按住相机键和开机键不放（一直不放），然后用用笔捅一下手机下侧的小孔（就是USB插口左侧的那个），然后等几秒钟，就会进入(三色屏 )

S1不捅PP一样能硬启、进三色屏

机器不能正常启动时，建议先试试按键硬启动方法恢复系统，效果同清除内存。
1、同时按住 接听 和 挂断 键后，点按软启动键（电源键）， 按后释放
2、继续按住 接听 和 挂断 键，直到出现硬启动界面
3、按确认键（导航键）执行硬启动，按其他键取消硬启动。

其实就是电脑的系统还原或一键恢复功能。。。

如果无效，则只好看看能否进三色屏刷机了
在关机状态下按住相机键，然后按软启动键（电源键）一下，同时注意不要放开按下的相机键。过几秒就进三色屏

这种方法比捅PP更方便，实际操作中发现，电源键和PP的效果是相同的。

各编码组织所在国家（地区）             前缀码 各编码组织所在国家（地区）
00—13 美国和加拿大                     609 毛里求斯
20—29 店内码（对无条码商品自行编码）   611 摩洛哥
30—37 法国                             613 阿尔及利亚
380 保加利亚                           619 突尼斯
383 斯洛文尼亚                         622 埃及
385 克罗地亚                           625 约旦
387 波黑                               626 伊朗
400—440 德国                           64 芬兰
45、49 日本                            690—695 中国
460—469 俄罗斯联邦                     70 挪威
471 中国台湾                           729 以色列
474 爱沙尼亚                           73 瑞典
475 拉脱维亚                           740 危地马拉
477 立陶宛                             741 萨尔瓦多
479 斯里兰卡                           742、744 洪都拉斯、哥斯达黎加
480 菲律宾                             743 尼加拉瓜
481 白俄罗斯                           745 巴拿马
482 乌克兰                             746 多米尼加
484 摩尔多瓦                           750 墨西哥
485 亚美尼亚                           759 委内瑞拉
486 格鲁吉亚                            76 瑞士
487 哈萨克斯坦                         770 哥伦比亚
489 中国香港                           773 乌拉圭
50 英国                                775 秘鲁
520 希腊                               777 玻利维亚
528 黎巴嫩                             779 阿根廷
529 塞浦路斯                           780 智利
531 马其顿                             784 巴拉圭
535 马耳他                             786 厄瓜多尔
539 爱尔兰                             789 巴西
54 比利时和卢森堡                      80—83 意大利
560 葡萄牙                             84 西班牙
569 冰岛                               850 古巴
57 丹麦                                858 斯洛伐克
590 波兰                               859 捷克
594 罗马尼亚                           860 南斯拉夫
599 匈牙利                             869 土耳其
600—601 南非                           893 越南
87 荷兰                                899 印度尼西亚
880 韩国                               90、91 奥地利
885 泰国                               93 澳大利亚
888 新加坡                             94 新西兰
890 印度                               955 马来西亚

–The End–

SQL> exec dbms_logmnr.add_logfile(’/u02/rman/arch_db1_20090624_29_1′,DBMS_LOGMNR.NEW);
BEGIN dbms_logmnr.add_logfile(’/u02/rman/arch_db1_20090624_29_1′,DBMS_LOGMNR.NEW); END;

*
ERROR at line 1:
ORA-01284: file /u02/rman/arch_db1_20090624_29_1 cannot be opened
ORA-00317: file type 0 in header is not log file
ORA-00334: archived log: /u02/rman/arch_db1_20090624_29_1
ORA-06512: at "SYS.DBMS_LOGMNR", line 68
ORA-06512: at line 1

看来Logmnr是无法识别备文件的，只有把归档文件从备份文件中还原出来才可以。查了下文档，用RMAN是可以搞定的。

RMAN> run
2> {
3> SET ARCHIVELOG DESTINATION TO ‘/u02/archive’;
4> restore archivelog sequence between 65 and 67;
5> }

executing command: SET ARCHIVELOG DESTINATION
using target database control file instead of recovery catalog

Starting restore at 24-JUN-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=142 devtype=DISK

channel ORA_DISK_1: starting archive log restore to user-specified destination
archive log destination=/u02/archive
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=65
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=66
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=67
channel ORA_DISK_1: reading from backup piece /u02/rman/arch_db1_20090624_29_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/u02/rman/arch_db1_20090624_29_1 tag=TAG20090624T154331
channel ORA_DISK_1: restore complete, elapsed time: 00:00:27
Finished restore at 24-JUN-09

这样就在目录/u02/archive里还原了65-67三个序号的归档文件。接着就可以用DBMS_Logmnr分析日志了。

exec dbms_logmnr.add_logfile(’/u02/archive/arch_1_65.dbf’,DBMS_LOGMNR.NEW);
exec dbms_logmnr.add_logfile(’/u02/archive/arch_1_66.dbf’,DBMS_LOGMNR.addfile);
exec dbms_logmnr.add_logfile(’/u02/archive/arch_1_67.dbf’,DBMS_LOGMNR.addfile);

begin
dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
end;

select * from v$logmnr_contents

–The End–

因为站太小，几乎没有外部链接会连进来，为了能想搜索引擎光顾自己的博客，可以自己到搜索引擎上去注册，注册过程是免费的。

Google的注册地址
http://www.google.com/addurl.html

Baidu的注册地址
http://www.baidu.com/search/url_submit.html

–The End–

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of delete command on ORA_DISK_1 channel at 06/19/2009 09:15:55
ORA-19587: error occurred reading 16384 bytes at block number 1
ORA-27091: unable to queue I/O
ORA-27069: attempt to do I/O beyond the range of the file
Additional information: 1
Additional information: 1

看到这个消息，首先想会不会是硬盘有问题了。因不是删除文件，所以不会是空间满了。查看硬盘状况，还有很大的剩余空间。

于是打开trace进入RMAN

$ rman target = / trace rman.trc debug

Recovery Manager: Release 10.2.0.4.0 – Production on Fri Jun 19 14:01:16 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

RMAN-06005: connected to target database: PAYMENT (DBID=938111124)

RMAN> list copy;

RMAN-06009: using target database control file instead of recovery catalog
RMAN-20242: specification does not match any archive log in the recovery catalog
RMAN-06365: List of Control File Copies
RMAN-06366: Key     S Completion Time Ckp SCN    Ckp Time        Name
RMAN-06367: ——- – ————— ———- ————— —-
RMAN-06368: 36      A 19-JUN-09       44248899   19-JUN-09       /u02/oradata/rman/backup/2009-06-19/control.bak
RMAN-06368: 35      A 18-JUN-09       41511256   18-JUN-09       /u02/oradata/rman/backup/2009-06-18/control.bak
RMAN-06368: 34      A 17-JUN-09       39981536   17-JUN-09       /u02/oradata/rman/backup/2009-06-17/control.bak
RMAN-06368: 33      A 16-JUN-09       39213838   16-JUN-09       /u02/oradata/rman/backup/2009-06-16/control.bak

RMAN> crosscheck copy;

RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08605: channel ORA_DISK_1: sid=1134 instance=payment1 devtype=DISK
RMAN-20242: specification does not match any archive log in the recovery catalog
RMAN-06156: validation succeeded for control file copy
RMAN-08516: control file copy filename=/u02/oradata/rman/backup/2009-06-19/control.bak recid=36 stamp=689937350
RMAN-06156: validation succeeded for control file copy
RMAN-08516: control file copy filename=/u02/oradata/rman/backup/2009-06-18/control.bak recid=35 stamp=689850796
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of crosscheck command on ORA_DISK_1 channel at 06/19/2009 14:01:50
ORA-19587: error occurred reading 16384 bytes at block number 1
ORA-27091: unable to queue I/O
ORA-27069: attempt to do I/O beyond the range of the file
Additional information: 1
Additional information: 1

RMAN> exit

发现在查检 /u02/oradata/rman/backup/2009-06-17/control.bak 时中断报错了。打开rman.trc，也的确在检查 /u02/oradata/rman/backup/2009-06-17/control.bak 文件处报ORA-19587

……
DBGPLSQL:   channel ORA_DISK_1:  processing (file/handle=/u02/oradata/rman/backup/2009-06-17/control.bak,recid=34, old_status=A, hdl_isdisk=0, devicetype=DISK) [14:01:49.998] (change)
DBGPLSQL:   channel ORA_DISK_1:  force: 0 [14:01:49.998] (change)
DBGRPC:     krmxrpc: xc=182924940192 kpurpc2 rc=19587 db=target proc=DBMS_BACKUP_RESTORE.VALIDATEDATAFILECOPY
DBGRPC:     krmxrpc: xc=182924940192 chid=ORA_DISK_1 increment rpc count=8
DBGMISC:    krmqexe: unhandled exception on channel ORA_DISK_1 [14:01:50.004]
DBGMISC:    error recovery releasing channel resources [14:01:50.004]
……

查看大小，发现是0字节

$ ls -lh /u02/oradata/rman/backup/2009-06-17/control.bak
-rw-r–r–  1 oracle oinstall 0 Jun 19 14:00 /u02/oradata/rman/backup/2009-06-17/control.bak

把这个文件删除，再执行crosscheck copy;就正常了。

–The End–

–The End–

传统的文件同步方案有rsync(单向) 和 unison(双向)等，它们需要扫描所有文件后进行比对，差量传输。如果文件数量达到了百万甚至千万量级，扫描所有文件将非常耗时。而且正在发生变化的往往是其中很少的一部分，这是非常低效的方式。

之前看了Amazon的Dynamo的设计文档，它们每个节点的数据是通过Hash Tree来实现同步，既有通过日志来同步的软实时特点(msyql, bdb等)，也可以保证最终数据的一致性(rsync, unison等)。Hash Tree的大体思路是将所有数据存储成树状结构，每个节点的Hash是其所有子节点的Hash的Hash，叶子节点的Hash是其内容的Hash。这样一旦某个节点发生变化，其Hash的变化会迅速传播到根节点。需要同步的系统只需要不断查询跟节点的hash，一旦有变化，顺着树状结构就能够在logN级别的时间找到发生变化的内容，马上同步。

文件系统天然的是树状结构，尽管不是平衡的数。如果文件的修改时间是可靠的，可以表征文件的变化，那就可以用它作为文件的Hash值。另一方面，文件的修改通常是按顺序执行的，后修改的文件比早修改的文件具有更大的修改时间，这样就可以把一个目录内的最大修改时间作为它的修改时间，以实现Hash Tree。这样，一旦某个文件被修改，修改时间的信息就会迅速传播到根目录。

一般的文件系统都不是这样做的，目录的修改时间表示的是目录结构最后发生变化的时间，不包括子目录，否则会不堪重负。因为我们需要自己实现这个功能，利用Linux 2.6内核的新特性inotify获得某个目录内文件发生变化的信息，并把其修改时间传播到它的上级目录(以及再上级目录)。Python 有 pyinotify，watch.py的代码如下：

#!/usr/bin/python

from pyinotify import *
import os, os.path

flags = IN_CLOSE_WRITE|IN_CREATE|IN_Q_OVERFLOW
dirs = {}
base = ‘/log/lighttpd/cache/images/icon/u241′
base = ‘tmp’

class UpdateParentDir(ProcessEvent):
    def process_IN_CLOSE_WRITE(self, event):
        print ‘modify’, event.pathname
        mtime = os.path.getmtime(event.pathname)
        p = event.path
        while p.startswith(base):
            m = os.path.getmtime(p)
            if m < mtime:
             print ‘update’, p
                os.utime(p, (mtime,mtime))
            elif m > mtime:
                mtime = m
            p = os.path.dirname(p)
   
    process_IN_MODIFY = process_IN_CLOSE_WRITE

    def process_IN_Q_OVERFLOW(self, event):
        print ‘over flow’
        max_queued_events.value *= 2

    def process_default(self, event):
    pass

wm = WatchManager()
notifier = Notifier(wm, UpdateParentDir())
dirs.update(wm.add_watch(base, flags, rec=True, auto_add=True))

notifier.loop()

在已经有Hash Tree的时候，同步就比较简单了，不停地获取根目录的修改时间并顺着目录结构往下找即可。需要注意的是，在更新完文件后，需要设置修改时间为原文件的修改时间，目录也是，保证Hash Tree的一致性，否则没法同步。mirror.py的代码如下

#!/usr/bin/python

import sys,time,re,urllib
import os,os.path
from os.path import exists, isdir, getmtime

src = sys.argv[1]
dst = sys.argv[2]

def local_mirror(src, dst):
    if exists(dst) and mtime == getmtime(dst):
        return
    if not isdir(src):
        print ‘update:’, dst
        open(dst,’wb’).write(open(src).read())
    else:
        if not exists(dst):
            os.makedirs(dst)
        for filename in os.listdir(src):
            local_mirror(os.path.join(src,filename), os.path.join(dst,filename))
    os.utime(dst, (mtime,mtime))

def get_info(path):
    f = urllib.urlopen(path)
    mtime = f.headers.get(’Last-Modified’)
    if mtime:
        mtime = time.mktime(time.strptime(mtime, ‘%a, %d %b %Y %H:%M:%S %Z’))
    content = f.read()
    f.close()
    return int(mtime), content

p = re.compile(r’([\d.]+?) +([\w/]+)’)

def remote_mirror(src, dst):
    mtime, content = get_info(src)
    if exists(dst) and mtime == int(getmtime(dst)):
        return
    print ‘update:’, dst, src
    if not src.endswith(’/'):
        open(dst,’wb’).write(content)
    else:
        if not exists(dst):
            os.makedirs(dst)
        for mt,filename in p.findall(content):
            mt = int(float(mt))
            lpath = dst+filename
            if not exists(lpath) or int(getmtime(lpath)) != mt:
                remote_mirror(src+filename, lpath)
    os.utime(dst, (mtime,mtime))

if src.startswith(’http://’):
    mirror = remote_mirror
else:
    mirror = local_mirror

while True:
    mirror(src, dst)
    time.sleep(1)
如果源文件不在同一台机器上，可以通过NFS等共享过来。或者可以通过支持列目录的HTTP服务器来访问远程目录，mirror.py 已经支持这种访问方式。server.py 是用webpy做的一个简单的只是列目录的文件服务器。由于瓶颈在IO上，它的性能不是关键。server.py的代码如下：
#!/usr/bin/python

import os,os.path
import web
import time

root = ‘tmp’

HTTP_HEADER_TIME = ‘%a, %d %b %Y %H:%M:%S %Z’

class FileServer:
    def GET(self, path):
        path = root + path
        if not os.path.exists(path):
            return 404
        mtime = time.localtime(os.path.getmtime(path))
        web.header(’Last-Modified’, time.strftime(HTTP_HEADER_TIME, mtime))
        if os.path.isdir(path):
            for file in os.listdir(path):
                if file.startswith(’.'): continue
                p = os.path.join(path,file)
                m = os.path.getmtime(p)
                if os.path.isdir(p):
                    file += ‘/’
                print m, file
        else:
            print open(path,’rb’).read()

urls = (
   “(/.*)”, “FileServer”,
)

if __name__ == ‘__main__’:
    web.run(urls, globals())

为了获得更好性能，以达到更好的实时性，Hash Tree最好是平衡的，比如BTree。如果一个文件发生变化，同步它需要进行的IO操作为N*M，其中N为数的层数，M为每层的文件数目。现在我们N为2，M最大为10000，适当减少它可以获得更好的性能，比如N为4，M为100。在以后创建目录结构时，最好能够考虑这方面的因素。

之前hongqn推荐过一个利用inotify的文件同步方案，同步方式类似于mysql和bdb等，由于过于复杂导致不可靠而没有采用。上面这个方案只用了一百多行Python代码就基本解决问题了，是不是很帅？:-)

http://www.google.com/chrome/thankyou.html?standalone=1

–The End–

15.3 How Imports Work
The module search path:

1> The home directory of the top-level file.
2> PYTHONPATH directories (if set).
3> Standard library directories.
4> The contents of any .pth files (if present).

—From <<Learning Python, 2E.chm>> 15.3 How Imports Work

也可以使用sys.path.append()来手动添加路径

–The End–

http://code.svnspot.com/

–The End–

http://watchthatpage.com/

http://scheduler.webgrid.com/default.aspx

–The End–

更新：升级到5.00M33-4还是会出来兼容性问题。

–The End–

今天在用VBS写个脚本去执行其它程序时，发现如果程序的路径里含有空格就不能运行，会报错。经过尝试几次后，发现把执行脚本用双引号引起来就行了。

例：

set wshshell=wscript.createobject(”wscript.shell”)

wshshell.run “”"c:\program files\internet explorer\iexplore.exe”" www.baidu.com”

–The End–

–The End–

CREATE PROCEDURE sp_Test1
AS
BEGIN
        WAITFOR DELAY ‘00:01:30′   –等待1分30秒
END

然后建一个作业，每分钟执行一次。

假设第一次执行时间是：12:00:00，执行完作业后显示下次执行时间是12:02:00
假设第二次执行时间是：12:02:00，执行完作业后显示下次执行时间是12:04:00

依次类推。。。

结论：感觉SQL Server把所有执行的时间点事先都计算出来了，当作业执行完后，就把大于当前时间的最近一个时间点作为下次执行的时间。

PS:完全是个人猜测，没看到官方文档。

–The End–

         用了几天也看了下VirtualBox自带的说明文挡加上到网上查到地一些资料。汇下总吧

        VirtualBox历史(转自http://zh.wikipedia.org/wiki/VirtualBox)

         Sun xVM VirtualBox 是由德國InnoTek(已被Sun併購) 這家軟體公司出品的軟體，它提供使用者在32或64位元的 Windows、Solaris 及 Linux 作業系統上虛擬另外的機器執行其它x86的作業系統，使用者可以在 VirtualBox 上安裝並且執行 Solaris、Windows、Linux、OS/2 Warp、OpenBSD 及 FreeBSD 等系統作為客戶機操作系統^[1]。在2007年1月，InnoTek以GNU通用公共许可证 (GPL)釋出VirtualBox，並提供二進位版本及開放源碼版本的程式碼。

和同性質的VMware及Virtual PC比較下，VirtualBox獨到之處包括Remote Desktop Protocol(RDP)、iSCSI及USB的支援，VirtualBox在客戶機操作系統上已可以支援USB 2.0的硬體裝置。

        在VirtualBox里复制VDI文件(转自http://blog.sina.com.cn/bobbyworm)   

         在VirtualBox的快速修复界面里，可以随时生成当前状态的备份。当生成了备份之后，会在Snapshots目录下创建一个新的VDI文件，之后对当前状态所做的一切操作都将针对最新的VDI文件，而VDI目录下的初始VDI文件就不会再改变了。

我一般在装好Guest OS并做完打补丁、安装常用软件等操作后就创建一个备份，如果Guest OS发生了问题可以随时恢复到干净的系统。但是有时需要在不同的软件环境下做不同的事情，开始时我希望能用一个VDI文件生成两个不同的备份并分别配置成不同的环境，但是发现VirtualBox的备份是线性的，也就是说只能针对当前状态做一个备份，而恢复备份时也只能恢复到上一个备份的状态，不能同时存在两个不同的当前状态。

没有办法，只能把初始的VDI文件复制出来一份用于另外的环境。但是很快发现，复制出来的VDI文件无法在虚拟介质管理器中注册，因为每个VDI文件都有一个唯一的uuid，而VirtualBox不允许注册重复的uuid。

看了帮助文件后，发现VBoxManage有一个clonevdi方法可以克隆VDI文件，并赋予它一个新的uuid。具体用法是在命令行里执行：

VBoxManage clonevdi 原始VDI文件名 新的VDI文件名

直接写VDI文件名即可，不用指明VDI文件所在路径，新的文件会在全局设定中指定的VDI目录下创建。如果VDI文件名里带有空格，应该在两端加上双引号。VBoxManage命令位于VirtualBox安装目录下，缺省路径是C:\Program Files\Sun\xVM VirtualBox。

用这个方法创建了新的VDI文件后，就可以正常注册并在另一个虚拟机中使用了。

        收缩虚拟机磁盘文件大小(转自http://blog.sina.com.cn/bobbyworm)

         由于经常要测试一些软件，我在VirtualBox虚拟机中安装了一套Windows。使用过虚拟机的朋友都知道，为了节省硬盘空间，一般都使用动态扩展映像。它不会在一开始就占用指定大小的硬盘空间，而是随着实际使用的需要动态扩展。但是在虚拟系统里删除了文件，使用过的空间并不会自动收回。虚拟系统使用久了以后，磁盘映像文件会变得越来越大。

我以前使用过VMware，在VMware Tools里有一个很方便的Shrink功能可以收回未使用的硬盘空间，但是在VirtualBox里没有看到这样的选项。经过上网查找资料，终于找到了在VirtualBox（我用的是2.0.0版）里Shrink的方法，只需要三个步骤：

第一步：在Guest OS中整理磁盘碎片。可以使用Windows自带的碎片整理工具，不过更推荐使用Defraggler。这是一款免费的磁盘碎片整理工具，使用简单，整理速度很快。

Defraggler下载地址：http://www.filehippo.com/download_defraggler/

第二步：将Guest OS的磁盘剩余空间清零，也就是把0值写入磁盘未使用空间的每一个字节。这一步是关键，因为在下一步里，所有只包含0值的磁盘空间将被收回。可以用Sysinternals出品的一个命令行工具SDelete来完成这一步。在Guest OS的命令行里执行：

sdelete -c c:\

其中c:\是要清零的磁盘分区，应依次对所有虚拟磁盘分区执行这一步，如d:\、e:\等等。

SDelete下载地址：http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx

第三步：使用VirtualBox提供的VBoxManage工具收缩磁盘映像文件。在Host OS的命令行中进入VirtualBox的安装目录（缺省为C:\Program Files\Sun\xVM VirtualBox），执行：

VBoxManage modifyvdi “Windows XP.vdi” compact

其中Windows XP.vdi是要收缩的磁盘映像文件名，请根据实际名称修改，不用指定路径。

经过这三个步骤以后，我的vdi文件从2.5G收缩到了1.2G，效果非常明显。以上介绍的前两个步骤所使用的工具是针对Windows的，如果Guest OS是Linux或其它系统，可以找一找相同功能的工具软件，原理都是一样的。

转自：http://blog.csdn.net/devfan/archive/2008/11/23/3354886.aspx

–The End–

本页内容

	概述
	Profiler trace文件性能分析的传统方法以及局限
	Read80trace工具介绍以及它的Normalization 功能
	使用存储过程分析Normalize后的数据
	使用usp_GetAccessPattern的一些技巧
	蛇足：哪个是HOT 数据库？

概述

当你的SQL Server数据库系统运行缓慢的时候，你或许多多少少知道可以使用SQL Server Profiler（中文叫SQL事件探查器）工具来进行跟踪和分析。是的，Profiler可以用来捕获发送到SQL Server的所有语句以及语句的执行性能相关数据（如语句的read/writes页面数目，CPU的使用量，以及语句的duration等）以供以后分析。但本文并不介绍如何使用Profiler 工具，而是将介绍如何使用read80trace（有关该工具见后面介绍）工具结合自定义的存储过程来提纲挈领地分析Profiler捕获的Trace文件，最终得出令人兴奋的数据分析报表，从而使你可以高屋建瓴地优化SQL Server数据库系统。

本文对那些需要分析SQL Server大型数据库系统性能的读者如DBA等特别有用。在规模较大、应用逻辑复杂的数据库系统中Profiler产生的文件往往非常巨大，比如说在Profiler中仅仅配置捕获基本的语句事件，运行二小时后捕获的Trace文件就可能有GB级的大小。应用本文介绍的方法不但可以大大节省分析Trace的时间和金钱，把你从Trace文件的海量数据中解放出来，更是让你对数据库系统的访问模式了如指掌，从而知道哪一类语句对性能影响最大，哪类语句需要优化等等。

返回页首

Profiler trace文件性能分析的传统方法以及局限

先说一下什么是数据库系统的访问模式。除了可以使用Trace文件解决如死锁，阻塞，超时等问题外，最常用也是最主要的功能是可以从Trace文件中得到如下三个非常重要的信息：

本文提到的访问模式就是上面三个信息。我们知道，数据库系统的模块是基本固定的，每个模块访问SQL Server的方式也是差不多固定的，具体到某个菜单，某个按钮，都是基本不变的，所以，在足够长的时间内，访问SQL Server的各类语句及其占用的比例也基本上是固定的。换句话说，只要Profiler采样的时间足够长（我一般运行2小时以上），那么从Trace文件中就肯定可以统计出数据库系统的访问模式。每一个数据库系统都有它自己独一无二的访问模式。分析Profiler Trace文件的一个重要目标就是找出数据库系统的访问模式。一旦得到访问模式，你就可以在优化系统的时候做到胸有成竹，心中了然。可惜直到目前为止还没有任何工具可以方便地得到这些信息。

传统的Trace分析方法有两种。一种是使用Profiler工具本身。比如说可以使用Profiler的Filter功能过滤出那些运行时间超过10秒以上的语句，或按照CPU排序找出最耗费CPU的语句等。另一种是把Trace文件导入到数据库中，然后使用T-SQL语句来进行统计分析。这两种方法对较小的Trace文件是有效的。但是，如果Trace文件数目比较多比较大（如4个500MB以上的trace文件），那么这两种方法就有很大的局限性。其局限性之一是因为文件巨大的原因，分析和统计都非常不易，常常使你无法从全局的高度提纲挈领地掌握所有语句的执行性能。你很容易被一些语句迷惑而把精力耗费在上面，而实际上它却不是真正需要关注的关键语句。局限性之二是你发现尽管很多语句模式都非常类似（仅仅是执行时参数不同），却没有一个简单的方法把他们归类到一起进行统计。简而言之，你无法轻而易举地得到数据库系统的访问模式，无法在优化的时候做到高屋建瓴，纲举目张。这就是传统分析方法的局限性。使用下面介绍的Read80trace工具以及自定义的存储过程可以克服这样的局限性。

返回页首

Read80trace工具介绍以及它的Normalization 功能

Read80Trace工具是一个命令行工具。使用Read80Trace工具可以大大节省分析Trace文件的时间，有事半功倍的效果。Read80Trace的主要工作原理是读取Trace文件，然后对语句进行Normalize (标准化)，导入到数据库，生成性能统计分析的HTML页面。另外，Read80trace可以生成RML文件，然后OSTRESS工具使用RML文件多线程地重放Trace文件中的所有事件。这对于那些想把Profiler捕获的语句在另外一台服务器上重放成为可能。本文不详细介绍Read80trace或OStress工具，有兴趣的读者请自行参阅相关资料，相关软件可以从微软网站下载（注：软件名称为RML，http://www.microsoft.com/downloads/）。

我要利用的是Read80Trace的标准化功能。什么是标准化？就是把那些语句模式类似，但参数不一样的语句全部归类到一起。举例说Trace中有几条语句如下：

select * from authors where au_lname = 'white'
select * from authors where au_lname = 'green'
select * from authors where au_lname = 'carson'

经过标准化后，上面的语句就变成如下的样子：

select * from authors where au_lname = {str}
select * from authors where au_lname = {str}
select * from authors where au_lname = {str}

有了标准化后的语句，统计出数据库系统的访问模式就不再是难事。运行Read80trace 的时候我一般使用如下的命令行：

Read80trace –f –dmydb –Imytrace.trc

其中－f开关是不生成RML文件，因为我不需要重放的功能。生成的RML文件比较大，建议读者如果不需要重放的话，也使用－f开关。

－d开关告诉read80trace把trace文件的处理结果存到mydb数据库中。我们后面创建的存储过程正是访问read80trace在mydb中生成的表来进行统计的。－I开关是指定要分析的的trace文件名。Read80trace工具很聪明，如果该目录下有Profiler产生的一系列Trace文件，如mytrace.trc,mytrace1.trc,mytrace2.trc等，那么它会一一顺序读取进行处理。

除了上面介绍的外，Read80trace还有很多其它有趣的开关。比如说使用－i开关使得Read80trace可以从zip或CAB文件中读取trace文件，不用自己解压。所有开关在Read80trace.chm中有详细介绍。我最欣赏的地方是read80trace的性能。分析几个GB大小的trace文件不足一小时就搞定了。我的计算机是一台内存仅为512MB的老机器，有这样的性能我很满意。

你也许会使用read80trace分析压力测试产生的trace文件。我建议还是分析从生产环境中捕获的Trace文件为好。因为很多压力测试工具都不能够真正模拟现实的环境，其得到的trace文件也就不能真实反映实际的情况。甚至有些压力测试工具是循环执行自己写的语句，更不能反映准确的访问模式。建议仅仅把压力测试产生的trace作为参考使用。

返回页首

使用存储过程分析Normalize后的数据

有了标准化后的语句就可以使用存储过程进行统计分析了。分析的基本思想是把所有模式一样的语句的Reads，CPU和Duration做group by统计，得出访问模式信息：

存储过程的定义以及说明如下：

/*************************************************************/
Create procedure usp_GetAccessPattern 8000
@duration_filter int=-1 --传入的参数，可以按照语句执行的时间过滤统计
as begin

/*首先得到全部语句的性能数据的总和*/
declare @sum_total float,@sum_cpu float,@sum_reads float,@sum_duration float,@sum_writes float
select @sum_total=count(*)*0.01,--这是所有语句的总数。
@sum_cpu=sum(cpu)*0.01, --这是所有语句耗费的CPU时间
@sum_reads=sum(reads)*0.01, --这是所有语句耗费的Reads数目，8K为单位。
@sum_writes=sum(writes)*0.01,--这是所有语句耗费的Writes数目，8K为单位。
@sum_duration=sum(duration)*0.01--这是所有语句的执行时间总和。
from tblBatches --这是Read80Trace产生的表，包括了Trace文件中所有的语句。
where duration>=@duration_filter --是否按照执行时间过滤

/*然后进行Group by，得到某类语句占用的比例*/
Select ltrim(str(count(*))) exec_stats,''+ str(count(*)/@sum_total,4,1)+'%' ExecRatio,
ltrim(str(sum(cpu)))+' : '++ltrim(str(avg(cpu))) cpu_stats,''+str(sum(cpu)/@sum_cpu,4,1)+'%' CpuRatio,
ltrim(str(sum(reads) ))+' : '+ltrim(str(avg(reads) )) reads_stats,''+str(sum(reads)/@sum_reads,4,1)  +'%' ReadsRatio ,
--ltrim(str(sum(writes) ))+' : '+ltrim(str(avg(writes) )) --writes_stats,''+str(sum(writes)/@sum_writes,4,1) +'%)',
ltrim(str(sum(duration) ))+' : '+ltrim(str(avg(duration))) duration_stats,''+str(sum(duration)/@sum_duration,4,1)+'%' DurRatio ,
textdata,count(*)/@sum_total tp,sum(cpu)/@sum_cpu cp,sum(reads)/@sum_reads rp,sum(duration)/@sum_duration dp
into #queries_staticstics from
/* tblUniqueBatches表中存放了所有标准化的语句。*/
(select reads,cpu,duration,writes,convert(varchar(2000),NormText)textdata from tblBatches
 inner join tblUniqueBatches on tblBatches.HashId=tblUniqueBatches.hashid where duration>@duration_filter
) B group by textdata --这个group by很重要，它对语句进行归类统计。

print 'Top 10 order by cpu+reads+duration'
select top 10 * from #queries_staticstics order by cp+rp+dp desc
print 'Top 10 order by cpu'
select top 10 * from #queries_staticstics order by cp desc
print 'Top 10 order by reads'
select top 10 * from #queries_staticstics order by rp desc
print 'Top 10 order by duration'
select top 10 * from #queries_staticstics order by dp desc
print 'Top 10 order by batches'
select top 10 * from #queries_staticstics order by tp desc

End
/*************************************************************/

考虑到输出结果横向较长，存储过程中把writes去掉了。这是因为大部分的数据库系统都是Reads为主的。你可以轻易的修改存储过程把write也包括进去。

存储过程并不复杂，很容易理解。可以看到统计的结果放在queries_staticstics表中，然后按照不同的条件排序后输出。举例说：

select top 10 *  from #queries_staticstics order by cp desc

上面的语句将把queries_staticstics表中的记录按照某类语句占用总CPU量的比例cp（即sum(cpu)/@sum_cpu）进行排序输出。这让你在分析服务器CPU性能问题的时候快速定位哪一类语句最耗CPU资源，从而对症下药。

现在让我们看一个实例的输出：

/********************/
Use mydb
Exec usp_GetAccessPattern
/*你可以输入一个执行时间作为过滤参数，毫秒为单位。如usp_GetAccessPattern 1000*/
/********************/

输出结果如图 1所示（是部分结果，另外，因为原输出结果横向很长，为方便阅读，把结果从中截断为两部分）：

图 1：输出结果采样一

上面的例子采样于一家大型公司的业务系统。该系统的问题是应用程序运行缓慢，SQL Server 服务器的CPU高居不下（8个CPU都在90%～100%间波动）。我使用PSSDIAG工具采样2小时左右的数据，然后运行read80trace和usp_GetAccessPattern得出上面的结果。报表一目了然。存储过程DBO.x_DEDUP_PROC在两小时内共运行75次，却占用了90.8％的CPU资源，94.6%的Reads，从访问模式的角度，该存储过程正是导致CPU高和系统性能慢的关键语句。一旦优化了该存储过程，系统的性能问题将迎刃而解。你也许有疑问，两小时内共运行75次,不是很频繁啊。其实你看看这条存储过程的平均CPU时间是681961毫秒，大概11分钟左右。也就是说一个CPU两小时内最多可以执行（60*2）/11＝10条左右，该系统总共有8个CPU，即使全部CPU都用来运行该语句，那么最多也就是10*8＝80条左右。上面执行总数是75，说明该存储过程一直在连续不断地运行。

那么该系统运行最频繁的语句是什么呢？我从结果中摘取另外一部分如下（图 2）：

图 2：输出结果采样二

从上表可以看出，最频繁运行的语句是

USE xb SET QUOTED_IDENTIFIER,ANSI_NULL_DFLT_ON…

显然这是一条执行环境配置语句，没有参考价值。倒是另外两条占用语句总数8.2%的语句值得关注：

SELECT COUNT(*) FROM x_PROCESS_STATS WHERE PROCESS……
SELECT COUNT(*) FROM x_PROCESS_STATS WHERE PROCESS……

在这个例子中，因为关键语句DBO.x_DEDUP_PROC非常突出，甚至上面的两条语句都可以忽略了。

让我们再多看一个例子（图 3）：

图 3：输出结果采样三

从上面的例子中, 可以得出关键的语句是:

SELECT COUNT(*) FROM GTBL7MS
SELECT CaseNO FROM PATIENTDATA_sum WHERE MRN = @P1

后续的检查发现相关的表没有有效的索引，加上索引后性能立即整体地提高了不少.。解决了这两个语句，需要使用同样的手段继续分析和优化，直到系统的性能能够接受为止.。注意性能调优是一个长期的过程，你不太可能一两天就可以把所有的问题都解决。也许一开始可以解决80%的问题，但是后面20%的问题却需要另外80%的时间。

返回页首

使用usp_GetAccessPattern的一些技巧

usp_GetAccessPattern的输出报表包含了非常丰富的信息。分析报表的时候需要有大局观。你也可以有目的性地选择你需要的信息。如果是CPU性能瓶颈的系统，那么你需要关注CPU占用比例高的那类语句。如果是磁盘IO出现性能瓶颈那么你需要找到那些Reads占用比例大而且平均reads也很高的语句。需要注意的是有时候运行频繁的语句未必就是你需要关注的关键语句。一个最理想的情况是关键语句正好就是最频繁的语句。有时候即使最频繁语句占用的资源比例不高，但如果还可以优化，那么因为放大效应，微小的优化也会给系统带来可观的好处。

在使用usp_GetAccessPattern的时候多结合@duration_filter参数使用。因为参数以毫秒为单位，建议参数不要小于1000，而应该是1000的倍数 如3000，5000等。该参数常常会给出非常有意思的输出。该输出和不带参数运行的结果会有某些重叠。重叠出现的语句通常正是需要关注的语句。要注意运行最多最密的语句未必有超过1000毫秒的执行时间，所有带参数运行的结果有可能不包括最频繁语句。我常常同时交叉分析四个结果，一个是不带参数运行得到的，另三个分别是使用1000，3000和5000毫秒为参数运行的结果。比较分析这四个结果往往使我对数据库系统的访问模式有非常清晰透彻的理解。

运行存储过程时你也许会碰到int整数溢出的错误。这是因为表tblBatches 中的reads,cpu 和writes字段是int而不是bigint。可以运行如下语句进行修正：

alter table tblBatches  alter column  reads bigint
alter table tblBatches  alter column  cpu bigint
alter table tblBatches  alter column  writes bigint

修正后溢出问题就会解决。

返回页首

蛇足：哪个是HOT 数据库？

本文到这里就基本上结束了。你已经知道如何使用Read80Trace和usp_GetAccessPattern得到数据库系统的访问模式，以及如何从全局的高度去分析访问模式报表，从而在优化系统的时候做到提纲挈领，胸有成竹。

除此之外，你还可以应用类似的分析思想得到每个数据库的占用资源比例。这对于SQL Server有多个数据库的情况非常有用。从报表中你可以立即知道哪个数据库是最HOT最消耗系统资源的数据库。语句如下：

print 'group by dbid'
declare @sum_total float,@sum_cpu float,@sum_reads float,@sum_duration float,@sum_writes float
select @sum_total=count(*)*0.01,@sum_cpu=sum(cpu)*0.01,@sum_reads=sum(reads)*0.01,@sum_writes=sum(writes)*0.01,
@sum_duration=sum(duration)*0.01 from tblBatches

select dbid,
ltrim(str(count(*))) exec_stats,''+ str(count(*)/@sum_total,4,1)+'%' ExecRatio,
ltrim(str(sum(cpu)))+' : '++ltrim(str(avg(cpu))) cpu_stats,''+str(sum(cpu)/@sum_cpu,4,1)+'%' CpuRatio ,
ltrim(str(sum(reads) ))+' : '+ltrim(str(avg(reads) )) reads_stats,''+str(sum(reads)/@sum_reads,4,1)  +'%' ReadsRatio ,
ltrim(str(sum(duration) ))+' : '+ltrim(str(avg(duration))) duration_stats,''+str(sum(duration)/@sum_duration,4,1)+'%' DurRatio ,
count(*)/@sum_total tp,sum(cpu)/@sum_cpu cp,sum(reads)/@sum_reads rp,sum(duration)/@sum_duration dp
into #queries_staticstics_groupbydb from

(select reads,cpu,duration,writes,convert(varchar(2000),NormText)textdata,dbid from tblBatches
inner join tblUniqueBatches on tblBatches.HashId=tblUniqueBatches.hashid
) b group by dbid order by sum(reads) desc

select dbid,ExecRatio batches,CPURatio CPU,ReadsRatio Reads,DurRatio Duration
from #queries_staticstics_groupbydb

下面是一个上面语句结果的一个例子：

dbid    batches   CPU        Reads       Duration
------  -------   -----   -------       --------
37      21.1%     18.7%      29.1%       27.1%
33      12.7%     32.4%      19.5%       24.8%
36       5.6%     28.3%      15.6%       26.1%
20      53.9%      2.9%      14.2%        2.1%
22       0.8%      7.2%      13.2%        6.6%
25       1.0%      3.6%       5.4%        3.5%
16       0.0%      1.5%       1.9%        0.7%
35       2.0%      2.7%       1.8%        5.7%
7        0.1%      0.1%       1.1%        0.3%

上面的结果明确地告诉我们ID为37，33和36的数据库是最活跃的数据库。一个有趣的事实是数据库20发出的语句总数比例是53.9%，但是其占用的系统资源比例却不高。

作者注：可能这个文章写的较早，read80trace已经下载不到，也可能是M$的网站有问题，不过可以下载RML工具，里面包含这个工具，名称叫readtrace.exe
http://www.microsoft.com/downloads/details.aspx?FamilyID=7edfa95a-a32f-440f-a3a8-5160c8dbe926&DisplayLang=en

–The End–

方法：
cd $pshome
move-item en-US zh-CN

这样操作以后，get-help就可以用了，不过帮助文件是英文的。

–The End–

　　对于非系统库而言，移动文件比较简单，只需要先分离数据库，然后移动数据库对应的数据文件，最后再附加数据库就可以了。

　　master库的数据文件和日志文件位置是记录在启动参数里的，只需要在企业管理器里点属性->常规->启动参数，修改-d.-l参数，然后停止数据库；移动master库文件；再启动数据库就可以了。

　　tempdb数据库相对简单，可以使用ALTER DATABASE命令在新位置重建即可。
ALTER DATABASE tempdb MODIFY FILE(name=tempdev,filename=’d:\mssqldb\tempdb.mdf’)
go
ALTER DATABASE tempdb MODIFY FILE(name=templog,filename=’d:\mssqldb\templog.ldf’)
go
　　执行完上面两个命令，重启数据库即启动新的tempdb数据文件。

　　移动msdb,model这两个系统库的数据文件需要使用跟踪标记。在启动参数里加入-T3609(添加方法同移动master库,跟踪标记3608的作用是跳过除master库外所有的库的自动恢复)，然后就可以像普通非系统库一样分离，附加这两个系统库了，启动在重启之前去掉启动参数里的跟踪标记(T3608)

–The End–

        因为我是从Oracle过来的，知道在Oracle里可以通过DBMS_JOB定时的执行STATSPACK，或者写个脚本，通过crontab定时的去执行就行了，难道在Windows上就没有类似的功能吗。

       我知道Windows里可以使用计划任务来定时的执行任务，只要找到一个可以通过命令行执行的工具就可以了。先想到的是使用sqlcmd命令行工具，想了想不行，因为不能保存trace文件到本机。所在到网上搜了一下，在微软的MSDN里看到profiler90.exe可以用。在自己电脑上试了一下，就是那个窗口版的SQL Server Profiler工具，只是通过命令行启动罢了。试验了一下，可以执行，再加入到执行任务，就成了定时去执行跟踪了。

命令如下：
profiler90 /U sa /P passwd /S 127.0.0.1 /T “standard” /O “d:\abc.trc” /M “2008-10-21 15:00:00″
或
profiler90 /E /T “standard” /O “d:\abc.trc” /M “2008-10-21 15:00:00″

通过profile90 /? 也可以查看参数帮助。

MSDN帮助:http://msdn.microsoft.com/zh-cn/library/ms162808(SQL.90).aspx

注意：日期格式不是文档里的，而是服务器上的日期格式。

—-The End—-

PSPKVM(PSP上的KVM，JAVA虚拟机，可运行J2ME程序)
http://sourceforge.net/projects/pspkvm/

Lightmp3(音乐播放器，支持FLAC，可降频播放，省电)
http://sakya.altervista.org/new/index.php
或http://code.google.com/p/lightmp3/

一个开发小组，有不少软件
http://www.noobz.eu/

以后会更新

–The End–

在网上看到有PSP版的KVM，下载了安装，真不错，以后那些手机里用的JAVA程序都可以在PSP里安家了。

现在只安装了一个UCWeb，看网页很不错。

PSPKVM官方地址：
http://sourceforge.net/projects/pspkvm/

–The End –

PostgreSQL
http://ftp2.uk.postgresql.org/sites/ftp.postgresql.org//binary/v8.2.6/win32/postgresql-8.2.6-2.zip

openNMS
http://internap.dl.sourceforge.net/sourceforge/opennms/opennms-installer-1.5.92.jar

安装文档
http://www.opennms.org/index.php/Installation:Windows

未完

–The End–

网盘地址:http://www.brsbox.com/

–The End–

–The End–

查找破解补丁(注意防网页病毒)
http://astalavista.box.sk/

测试浏览器的并发连接数
http://stevesouders.com/hpws/parallel-downloads.php

–The End–

把gcc降级之后，重新编译了Oracle，发现还是启动不了。最后想起Linux系统时新安装的，不知道安装的人有没有调整系统内核参数，打开/etc/sysctl.conf,看见内核参数只是随便在网上找了一个更新的，不适合现在的系统。把/etc/sysctl.conf修改以后，执行sysctl -p使之生效，再启动就成功了。

–The End–

到了下面，很多人已经出了大楼了。只是马路上的人不知道怎么回事，看来地震的不是很严重，可能我工作在高楼感觉明显一点。但愿不要再震了。

另听说四川发生7点几级地震。

–The End–

我查看了下alter日志，发现是CKPT进程写控制文件失败后，数据库挂起。

error 220 detected in backgroud process
ORA-00200 control file not mounted by first instance, check alert log for more info
ORA-00202 controlfile ‘xxxxxxxxxxxxxxxx/control02.ctl’

本地为这事完了，下午的时候，RMAN备份脚本运行失败了，提示

RMAN-06004 : ORACLE error from recovery catalog database : target : RMAN-20003 incarnation not found in database recovery catalog

以前一直是使用这个恢复目录，现在怎么不能用了，查了一下， 原来是之前挂起后，启动数据库时使用resetlogs，需要在RMAN中执行reset database;

-The End-

STACK TRACE:

Dump file /ora/app/oracle/admin/textdb/udump/textdb_ora_9641.trc

*** SESSION ID:(9.3332) 2000-08-16 15:00:21.962

*** 2008-03-25 15:00:21.962

ksedmp: internal or fatal error

ORA-00600: internal error code, arguments: [4080], [1], [131], [], [], [], [],

[]

Current SQL statement for this session:

SELECT oldest, youngest+1/86400 FROM sys.snap_loadertime$ WHERE tableobj# = :1

FOR UPDATE

—– Call Stack Trace —–

ksedmp kgeriv kgeasi ktuchg ktbchg2 kddchg kddlok kddlkr qerfuStart

selexe opiexe opiefn0 opiall0 opikpr opiodr rpidrus skgmstack rpidru

rpiswu2 kprball kkzlglstmp kkzlllu kkzflbsu kkzfrsh kkzfroc2 kkzfroc

ktcrcm ktdcmt k2lcom k2send xctctl xctcom opiexe opiall0 kpoal8 opiodr

ttcpip opitsk opiino opiodr opidrv sou2o main start

在Google上搜索了一下，好像说是个Bug，Metalink上面的描述是

Distributed transactions are not allowed to update
tables which have “ON COMMIT” snapshots / materialized
views on them. In Oracle9i and ORA-600 [4080] is
signalled at commit time. In Oracle8i the materialized
view is not updated and so becomes out of sync with
the master table.

Workaround:
Use ON DEMAND materialized views instead.

最后的解决方法就是把这个物化重建一个，把ON COMMIT方式改为ON DEMAND

-The End-

等以后下载了11g的文档，再把相应的地址帖出来吧，现在也懒得去OTN上找了，Oracle官网的速度真的不怎么样。

补：

Oracle11g的下载地址：http://download.oracle.com/docs/cds/B28359_01.zip

-The End-

再查看参数

SQL> show parameter open_links

NAME                                 TYPE    VALUE
———————————— ——- ———————–
open_links                           integer 4

Oracle默认是4,因为表上有一个触发器，会把数据分发到其它库，使用超过４个DBLINK了，所以报错了。数据库是Oracle9i，这个参数还不能动态修改(不知道新版本的Oracle能否动态修改这个参数)，需要重启数据库，因为是生产库，不能随便重启。

想来想去没想到好的方法，最后只好把触发器修改了，把直接触发到基中一个库改为从别一个库触发过去，级连了一下触发器，虽然是糗主意，但在不能重启Oracle的情况，总算把事解决了。另外赶紧把这个参数改大一点(scope=spfile)，以免下次再出来这样的问题。

-The End-

ftp updates.oracle.com
使用Metalink的用户名和密码作为FTP的用户名和密码。
FTP服务器使用补丁号作为目录名，所以下载那个补丁，要知道相应的补丁号，然后用cd命令切换到那个目录下，使用ls或dir查看你要下载的平台的文件名。
注意：根目录可能是目录太多，没有list权限，不要以为服务器没有数据。

Oracle patch补丁号列表
9.2.0.4 = 3095277
9.2.0.5 = 3501955
9.2.0.6 = 3948480
9.2.0.7 = 4163445
9.2.0.8 = 4547809
10.1.0.3 = 3761843
10.1.0.4 = 4163362
10.1.0.5 = 4505133
10.2.0.2 = 4547817
10.2.0.3 = 5337014
10.2.0.4 = 6810189

oracle 9.2.0.8 patch
-r–r–r–   1 root     other    1011302810 Aug 22 2006 p4547809_92080_AIX64-5L.zip
-r–r–r–   1 root     other    301383322 May 22 2007 p4547809_92080_AXP.zip
-r–r–r–   1 root     other    614741565 Aug 22 2006 p4547809_92080_HP64.zip
-r–r–r–   1 root     other    915111254 Oct 4 2006 p4547809_92080_HPUX-IA64.zip
-r–r–r–   1 root     other    382660178 Aug 25 2006 p4547809_92080_LINUX.zip
-r–r–r–   1 root     other    650429665 Aug 22 2006 p4547809_92080_Linux-IA64.zip
-r–r–r–   1 root     other    487245960 Aug 22 2006 p4547809_92080_Linux-x86-64.zip
-r–r–r–   1 root     other    173812249 Aug 22 2006 p4547809_92080_MVS.zip
-r–r–r–   1 root     other    369346915 Aug 24 2006 p4547809_92080_SOLARIS.zip
-r–r–r–   1 root     other    435868682 Aug 24 2006 p4547809_92080_SOLARIS64.zip
-r–r–r–   1 root     other    1018459573 Mar 4 2007 p4547809_92080_TRU64.zip
-r–r–r–   1 root     other    257710303 Aug 21 2006 p4547809_92080_WINNT.zip
-r–r–r–   1 root     other    378323336 Aug 22 2006 p4547809_92080_WINNT64.zip

oracle 10.1.0.5 patch
-r–r–r–   1 root     other    1088290360 Feb 4 2006 p4505133_10105_AIX64-5L.zip
-r–r–r–   1 root     other    1113494903 Feb 5 2006 p4505133_10105_HP64.zip
-r–r–r–   1 root     other    1284399515 Jun 6 2006 p4505133_10105_HPUX-IA64.zip
-r–r–r–   1 root     other    846975135 Aug 26 2006 p4505133_10105_LINUX-S390.zip
-r–r–r–   1 root     other    846975135 Sep 1 2006 p4505133_10105_LINUX-zSer.zip
-r–r–r–   1 root     other    671870763 Jan 31 2006 p4505133_10105_LINUX.zip
-r–r–r–   1 root     other    948537380 Apr 30 2006 p4505133_10105_Linux-IA64.zip
-r–r–r–   1 root     other    729894889 Feb 24 2006 p4505133_10105_Linux-x86-64.zip
-r–r–r–   1 root     other    795332324 Mar 4 2006 p4505133_10105_MVS.zip
-r–r–r–   1 root     other    681257061 Jan 8 2007 p4505133_10105_Mac-OS.zip
-r–r–r–   1 root     other    767273383 Feb 5 2006 p4505133_10105_SOLARIS64.zip
-r–r–r–   1 root     other    676386907 Jun 19 2006 p4505133_10105_SOLARISx86.zip
-r–r–r–   1 root     other    1095126782 Oct 17 2006 p4505133_10105_TRU64.zip
-r–r–r–   1 root     other    601712906 Feb 13 2006 p4505133_10105_WINNT.zip
-r–r–r–   1 root     other    811043147 Jan 30 2006 p4505133_10105_WINNT64.zip

oracle 10.2.0.3 patch
-r–r–r–   1 root     other    1604896973 Feb 22 2007 p5337014_10203_AIX64-5L.zip
-r–r–r–   1 root     other    1424057924 Feb 22 2007 p5337014_10203_HP64.zip
-r–r–r–   1 root     other    1641826103 May 2 2007 p5337014_10203_HPUX-IA64.zip
-r–r–r–   1 root     other    1443790237 Mar 15 2007 p5337014_10203_IBMPower.zip
-r–r–r–   1 root     other    1103539895 Jun 13 22:09 p5337014_10203_LINUX-zSer.zip
-r–r–r–   1 root     other    944121770 Feb 21 2007 p5337014_10203_LINUX.zip
-r–r–r–   1 root     other    1209745348 Feb 22 2007 p5337014_10203_Linux-IA64.zip
-r–r–r–   1 root     other    1082086597 Feb 22 2007 p5337014_10203_Linux-x86-64.zip
-r–r–r–   1 root     other    937018969 Feb 23 2007 p5337014_10203_MSWIN-x86-64.zip
-r–r–r–   1 root     other    881471858 Feb 26 2007 p5337014_10203_MVS.zip
-r–r–r–   1 root     other    1254311329 Feb 22 2007 p5337014_10203_SOLARIS64.zip
-r–r–r–   1 root     other    1811431410 Aug 13 05:23 p5337014_10203_Solaris86-64.zip
-r–r–r–   1 root     other    1393733954 Oct 15 04:50 p5337014_10203_TRU64.zip
-r–r–r–   1 root     other    893831865 Feb 21 2007 p5337014_10203_WINNT.zip
-r–r–r–   1 root     other    1122786231 Feb 23 2007 p5337014_10203_WINNT64.zip

没有Metalink的用迅雷试试吧.

oracle 9208 patch:
ftp://updates.oracle.com/4547809/p4547809_92080_AIX64-5L.zip
ftp://updates.oracle.com/4547809/p4547809_92080_HP64.zip
ftp://updates.oracle.com/4547809/p4547809_92080_HPUX-IA64.zip
ftp://updates.oracle.com/4547809/p4547809_92080_LINUX.zip
ftp://updates.oracle.com/4547809/p4547809_92080_Linux-IA64.zip
ftp://updates.oracle.com/4547809/p4547809_92080_Linux-x86-64.zip
ftp://updates.oracle.com/4547809/p4547809_92080_MVS.zip
ftp://updates.oracle.com/4547809/p4547809_92080_SOLARIS.zip
ftp://updates.oracle.com/4547809/p4547809_92080_SOLARIS64.zip
ftp://updates.oracle.com/4547809/p4547809_92080_WINNT.zip
ftp://updates.oracle.com/4547809/p4547809_92080_WINNT64.zip
oracle 10.2.0.4 patch:
ftp://updates.oracle.com/6810189/p6810189_10204_AIX5L.zip
ftp://updates.oracle.com/6810189/p6810189_10204_HPUX-IA64.zip
ftp://updates.oracle.com/6810189/p6810189_10204_LINUX.zip
ftp://updates.oracle.com/6810189/p6810189_10204_Linux-x86-64.zip
ftp://updates.oracle.com/6810189/p6810189_10204_Linux-x86.zip
ftp://updates.oracle.com/6810189/p6810189_10204_Win32.zip
ftp://updates.oracle.com/6810189/p6810189_10204_Win64.zip

–The End–