Archive for December, 2007

Dec 15 2007

Planet Terror

Published by kamus under Misc

不再普及电影知识，如果还不知道什么是Cult Film，什么是Grindhouse Film，谁是Robert Rodriguez，谁是Quentin Tarantino，那么请自行Google。

任何一个喜欢《杀死比尔》或者喜欢《罪恶之城》的朋友都不应该错过这部《恐怖星球》。

Planet Terror由罗伯特·罗德里格斯（罪恶之城的导演）导演，他的哥们儿昆汀·塔伦蒂诺（低俗小说，落水狗，杀死比尔的导演）在其中客串一个最后被病毒感染成满身肉浆的大兵，僵尸 + 暴力 + 血腥 + 幽默 + 情色，这是Planet Terror带来的感觉。

享受充满欢笑的鲜血吧。

2 responses so far

Dec 15 2007

RMAN Compressed Backupset

Published by kamus under Oracle RDBMS

在Oracle10g就已经推出了Compressed Backupset。

There is some CPU overhead associated with compressing backup sets. If the database being backed up is running at or near its maximum load, you may find the overhead from using AS COMPRESSED BACKUPSET unacceptable. In most other circumstances, compressing backupsets saves enough disk space to be worth the CPU overhead.

今天在自己机器上的Oracle 11.1.0.6版本中测试了一下，压缩效果还是很让人满意的，不但存储空间变小，甚至备份所需要的时间也有所加快。

不使用压缩的备份：
backup database plus archivelog delete all input;

Size       Elapsed Time
---------- ------------
652.77M    00:01:25

使用压缩的备份：
backup AS COMPRESSED BACKUPSET database plus archivelog delete all input;

Size       Elapsed Time
---------- ------------
84.87M     00:00:48

在CPU并不是主要瓶颈的系统中，建议启动压缩备份。

Update：
Oracle11g中新增的zlib压缩算法和之前bzip2压缩算法之间的测试比较可以参看Oracle11g新特性：RMAN压缩备份 from Ningoo 。

One response so far

Dec 15 2007

coComment reborn

Published by kamus under Webs

很早以前，大概是在2006年2月份的时候，coComment这个比较有趣的服务出现了，记录你在各个网站的留言，在coComment站点统一进行管理。

在2006年的时候我在kDoliphin的站上说过：

始终觉得操作步骤有些繁琐，因为添加了一道点击 coComment标签的手续，也就是要求改变人们的操作习惯，这个恐怕是coComment发展的一大阻碍，如果可以做到对用户透明就狂放了。
并且还要有等待连接coComment站点的时间，有时候网络问题会导致等待很久。

之后，就没再继续关注这个新生的服务，果然，coComment也没有再有什么大的动静。

今天，忽然在gmail的信箱里面收到coComment的来信，说是升级了2.0版。

1. 推出了Firefox的插件，不再需要像以前那样点击coComment标签，这是必须的。
2. 更加Web2.0，推出了Community，包括创建兴趣组，创建好友，分享Comment等等。
3. 添加了Tag功能。

在安装完了coComment插件以后，任何一个网站留言输入框的下面都会出现一个小横条。

mwsnap237.jpg

默认状态不需要去管它，只要像平常一样写留言，然后Commit就可以。

之后，就可以登陆coComment网站，在自己的用户下统一管理自己的所有留言了。

也许，现在coComment可以有更大的发展了吧。
欢迎大家使用本文测试coComment。

5 responses so far

Dec 14 2007

Oracle 11g new feature - Virtual Column

Published by kamus under Oracle RDBMS

在之前的一篇 - Oracle 11g New Feature - Partition 文章中曾经提到虚拟列的概念，但是当时自己也有些疑问，今天在Oracle 11.1.0.6 上简单测试了一下。

  1. CREATE TABLE tb_v
  2. (col_1 number(6) not null,
  3. col_2 number not null,
  4. col_v as (col_1+col_2));
  5.  
  6. -- 由于虚拟列的存在，所以即使指定了全部的实际列的值也会报值不足的错误
  7. SQL> insert into tb_v values(1,2);
  8.  
  9. insert into tb_v values(1,2)
  10.  
  11. ORA-00947: not enough values
  12.  
  13. -- 虚拟列中不允许显示插入值
  14. SQL> insert into tb_v values(1,2,4);
  15.  
  16. insert into tb_v values(1,2,4)
  17.  
  18. ORA-54013: INSERT operation disallowed on virtual columns
  19.  
  20. --必须明确指定列名，才能正常插入数据
  21. SQL> insert into tb_v(col_1,col_2) values(1,2);
  22.  
  23. 1 row inserted
  24.  
  25. --检索表，已经自动计算虚拟列的值
  26. SQL> select * from tb_v;
  27.  
  28.   COL_1      COL_2      COL_V
  29. ------- ---------- ----------
  30.       1          2          3
  31.  
  32. --选取该行ROWID
  33. SQL> select rowid from tb_v;
  34.  
  35. ROWID
  36. ------------------
  37. AAAEdcAAEAAAC3/AAA
  38.  
  39. -- 获得该行数据存放得到数据文件号
  40. SQL> select dbms_rowid.rowid_relative_fno(row_id => 'AAAEdcAAEAAAC3/AAA') from dual;
  41.  
  42. DBMS_ROWID.ROWID_RELATIVE_FNO(
  43. ------------------------------
  44.                              4
  45.  
  46. --获得该行数据存放的block号                            
  47. SQL> select dbms_rowid.rowid_block_number(row_id => 'AAAEdcAAEAAAC3/AAA') from dual;
  48.  
  49. DBMS_ROWID.ROWID_BLOCK_NUMBER(
  50. ------------------------------
  51.                          11775
  52.  
  53. -- Dump这个数据块
  54. SQL> alter system dump datafile 4 block 11775;
  55.  
  56. System altered

下面是dump内容的节选，可以看到确实只保存了两个字段，也就是虚拟列的值并没有存储在block中

block_row_dump:
tab 0, row 0, @0x1f8f
tl: 9 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 2]  c1 02
col  1: [ 2]  c1 03
end_of_block_dump

继续在虚拟列上创建索引，然后再看看索引的存储是否有不一样的地方。

  1. SQL> create index idx_v on tb_v (col_v);
  2.  
  3. Index created
  4.  
  5. -- 获得索引存储的文件号和block号
  6. SQL> exec show_space(p_segname_a => 'idx_v',p_type_a => 'INDEX');
  7.  
  8. Total Blocks............................8
  9. Total Bytes.............................65536
  10. Unused Blocks...........................4
  11. Unused Bytes............................32768
  12. Last Used Ext FileId....................4
  13. Last Used Ext BlockId...................11777
  14. Last Used Blocks........................4
  15. Last Used BlockId.......................11780
  16. FIRST LEVEL BITMAP BLOCK................11777
  17. SECOND LEVEL BITMAP BLOCK...............11778
  18. PAGETABLE SEGMENT HEADER................11779
  19. FIRST Trans Data BLOCK..................11780
  20. Dump SQL: alter system dump datafile 4 block 11780;

Dump 索引块，下面是Dump内容的节选，c1 04就是3，因此可见在创建索引的时候，Oracle会先去计算虚拟列的值，然后再根据结果创建索引。

row#0[8024] flag: ------, lock: 0, len=12
col 0; len 2; (2):  c1 04
col 1; len 6; (6):  01 00 2d ff 00 00
----- end of leaf block dump -----

实际上基于虚拟列的索引就是一个函数索引，可以从DBA_INDEXES.FUNCIDX_STATUS=’ENABLED’这个条件得到验证。

其它的一些测试可以参看Oracle11g新特性：虚拟列virtual column from Ningoo。

下一篇计划测试虚拟列的性能。

3 responses so far

Page 4 of 6« First...«23456»