Read ERN

一般的中断进程，当然Ctrl-C就搞定了，但只能要Break键的理由很简单，破解Cisco路由器密码需要Ctrl-Break（为了进入ROMMON）。上午需要用，结果发现自己的MacBook不能用来干这个，郁闷……还好当时带多了一台IBM的本子，把工作搞定了。回来研究这个问题，花了两三个小时，终于搞明白，似乎不大可能直接解决。关键在于，Break键并不是一个字符，其实是串口帧错误的信号，不能直接映射到某个组合键。据说扩展的Apple键盘可以定义到F16，但要随身带个大键盘似乎也不合理，另外也看到不少帖子说这样也无效。

还好，搜索过程中，找到了Cisco的官方解决方案，提及了MAC OS X上Z-Terminal可以用Command+B代替，不过没能找到这个软件，最终用了替代解决方法，虽然Cisco写了一大段，其实也很简单：

1. 用1200bps连接串口，也就是screen /dev/tty.usbserial 1200，这时中断提示都是乱码或者没有提示，请无视；
2. 重启路由器，按住空格键，保持15秒，仍然是乱码，继续无视；
3. 关闭你的终端窗口，然后进进程管理器把screen进程杀掉；
4. 开个终端，现在正常连接，也就是screen /dev/tty.usbserial 9600。此时应该提示进入ROMMON了，继续你的破解进程吧。

早晨上班，婚姻登记中心外面已经是一长队人，这才知道原来09年09月09日到了。选择个“长长久久”也不容易啊，下一个更好的机会得90年以后了。
09.09.09确实是个不错的日子，至少Apple、Leica都喜欢。这一天，它们都会有新品发布会，Apple发布什么还是个迷，但是大家都期盼着新iPod、Apple TV，以及传说中的Apple平板电脑；Leica则基本确定要发布全画幅的M9和X1。另外一个振奋人心的消息是，The Beatles的所有专辑要发布2009重制作限量全集，另外还要发布The Beatles RockBand音乐互动游戏，支持XBox360、PS3、Wii等平台。
要我说，最好的组合是，出一个套装，包含64G iPod Touch，灌录好The Beatles2009重制作版的AIFF，然后加一套CD+DVD。只是不知道这样一套得多少钱，呵呵，最好是买CD、DVD送iPod Touch，哈哈。
先口水吧，等出了，估计最心仪的还是The Beatles的全集，不是天价的话就考虑考虑。Apple的东西嘛，越惊艳越买不起。

旧文重发，原文刊载于2006年6月8日。

近日工作需要，要大批量导出数据，开始用SQL*Plus的SPOOL功能。结果老是提示“xrealloc: cannot reallocate XXX bytes”。而且每次发生的时间还不同，有时候是到文件1G就出错，有时候是2G多出错。怀疑是32位Linux问题，换到Solaris 8上还是如故。客户端都是9201的，到Metalink上搜索没有结果。郁闷之余到Oracle-l上发了个邮件，收到一位高手的指点，说可能是内存泄露问题，SQL*Plus的开发人员估计也不会想到有人会导出如此大量数据。在邮件往复之间，那位高手提醒可以用UTL_FILE来导出。忽然想起Tom的两本书里都有提到用PL/SQL来导出，于是翻出书里的那个网址http://asktom.oracle.com/~tkyte/flat/index.html，进去一看，PL/SQL的效率比SQL*Plus要高，缺点是生成的文件必须在主机上。SQL*Plus可以调整arraysize来提高效率（当然经我实践大数据量时还有内存泄露之虞）。Pro*C是高效的方法，缺点是需要写程序、编译。
硬着头皮看Pro*C咯，好在Tom给了原始代码，抓下来放到一台Linux的机器上proc报错，应该是proc配置include库的问题，找到一个makefile，倒是没啥问题了，但是最后链接失败，报无法识别’sqlca’。到网上一搜，和我一样晕的人还有，要修改代码，多include进，但是看Tom的帖子似乎没提到这个问题，不知道为什么。
下面是修改后的源代码，我顺便在里面修改了会话的一些参数，以处理中文和时间格式：

阅读全文…

旧文重发，原文发表于2007年2月1日。

从前几天bigboar要做一个大表更新的项目引发的讨论，CTAS还是INSERT产生redo多。后来在fsm启发下又复习了遍Tom的结论。具体内容就不翻译了，转贴一下：
Table Mode    Insert Mode     ArchiveLog mode      result
———–   ————-   —————–    ———-
LOGGING       APPEND          ARCHIVE LOG          redo generated
NOLOGGING     APPEND          ARCHIVE LOG          no redo
LOGGING       no append       “”                   redo generated
NOLOGGING     no append       “”                   redo generated
LOGGING       APPEND          noarchive log mode   no redo
NOLOGGING     APPEND          noarchive log mode   no redo
LOGGING       no append       noarchive log mode   redo generated
NOLOGGING     no append       noarchive log mode   redo generated

简单来讲，就是表的模式和归档模式具有优先决定权，当表本身NOLOGGING时，指定了APPEND的hint才不产生redo（direct模式的sqlldr应该是一样的），另外就是非归档下则无论表状态只要APPEND总会生效。
其实也就是一个规律，具体的测试就不做了。呵呵。
BTW：在后来的讨论中其实还涉及到UNDO，CTAS产生UNDO方面还是有优势的，INSERT毕竟要记录rowid作为UNDO信息，而CTAS是DDL，立即提交，应该只是在涉及修改数据字典的地方产生UNDO而已。所以Tom在他的帖子里也是推荐用CTAS代替大量UPDATE。当然啦，CTAS也是有弱点的，毕竟表结构不能自定义，这样如果原表设计并不合理的时候就无法顺便改表结构了。
CTAS+PARALLEL（如果可以并行的话）是目前我能想到的最快速度了。

旧文新发，原文发表于2007年4月6日。

4030的错误往往也挺吓人的，一看就涉及内存问题啊。今天在一个内部使用的数据库上遇到了。往往4030的解决方法都是增加PGA，或者反之，减少SORT_AREA_SIZE/HASH_AREA_SIZE。根本原因其实就是当Oracle试图向OS申请会话内存（session memory）时，OS返回错误，一般是内存不足之类。所以上来就提高PGA_AGGREGATE_TARGET也是不合适的。今天就是这个情况。

在客户端跑一个稍微复杂点的查询时候，出现了ORA-04030，其它同事也反映这个情况出现几天了，即便程序可以运行也慢得像头牛。今天我是忍无可忍了，决心花点时间了解一下。连上服务器，alert.log里果然不少报错。show parameter pga一看，600M，作为这个数据库倒也挺合适。再查询V$PGASTAT，真正花费的内存空间都是150M左右，并不大啊。仔细查查V$SESSTAT，只有三四个占内存超过10M的会话，实时统计总共也就是120M。看来并不是PGA设置太小。忽然想到这台服务器是Win2000 32bit，配置8G内存，联想到了1.7G的限制。不过当初装机器的同事已经设置了AWE，应该可以用到3G啊。

又是一阵show parameter，终于发现了问题，猜想是对的。DB_BLOCK_BUFFERS设置了307000+，也就是2.4G的DB_CACHE，然后SHARED_POOL_SIZE=100M，这加起来都3.1G，突破限制了，居然还不知道为什么设置了JAVA_POOL_SIZE=100M。赶紧改……于是将DB_CACHE调整到了2G（调低DB_BLOCK_BUFFERS），由于没有Java程序或过程，所以JAVA_POOL_SIZE=0，顺手又将SGA_MAX_SIZE降到2.2G，这样数据库就不会盲目相信参数，突破OS进程限制申请空间了。通知同事重新启动数据库，果然再没出现错误了，查V$PGASTAT果然可以分配更多空间了，一般都稳定在200-300M了，程序运行快了不少。

又翻了一把，顺便转自己文章一篇过来。原文发表于2007年6月20日
共享一个Oracle技巧吧。在以前一篇blog里我写过自定义聚集函数——一条语句将多行的列中字符串连接起来，技术总是在进步的。在这一期的Oracle Magazine中的AskTom，学到了一个不错的方法。从8i开始Oracle增加了分析函数，从9iR1开始，又有了SYS_CONNECT_BY_PATH函数，于是，产生了下面一个更加简单的方法。

阅读全文…

激动啊，经过昨晚几个小时和今早一个小时的努力，离线版Wikipedia在我的MacBook上终于实现了！现在，除掉iPhone/iPod Touch上有离线版Wikipedia，咱们的MAC OS X也能离线浏览最新的Wikipedia备份啦！

下面简单说说实现方法。

方法来源：http://users.softlab.ece.ntua.gr/~ttsiod/buildWikipediaOffline.htm。这里的方法原本是面对Linux的，不过我在MAC OS X上同样实现了。所以大家需要移植到其他Linux/UNIX的同样可以借鉴。

说明：以下教程需要较多命令行指令，涉及开发包编译、安装……所以，请大家要么有一定开发或者LINUX/UNIX维护基础，要么心细胆大

实现方面，本帖采用的离线法主要是重新索引和切割Wikipedia的镜像包，通过将文字内容重新格式显示为HTML页面而达到阅读的目的。另一种离线方法是直接镜像Wikipedia，即在本地Apache、MySQL等架站，将镜像包重新倒回到本地数据库。相比较而言，后者功能更全面，你可以修改本地的内容，但是速度非常慢，使用时也需要打开数据库，相对比较麻烦。我这里实现的方法，对查询浏览已经足够了。

阅读全文…