AnySQL.net

Oracle 11G OLTP Compress支持的含义

    在Oracle 11g之前, 普通的Insert不能使数据以Compress方式存贮, 你可以做实验对它进行验证, 只能通过将表移动一下, 或用CTAS或Bulk Insert的方式来进行表压缩. 最近也开始用Compress表存放一些几年前的数据了.     虽然有触目惊心的Bug, 但空间的节约却是可观的, 有时也得挺而走险(没有这么严重)一下.     在Oracle 11g中, 号称支持OLTP的Compress表, 并不是算法有什么改进(我用AUL 5去恢复11g中的压缩表, 也能恢复出来, 就说明了这一点), 也只是修复了一些Bug, 并且在普通的Insert语句下, 也可以进行压缩(还没有装11g进行验证). 如果这个功能安全可靠的话, 到是可以用于存放什么Log信息的表, 一个系统中总是不关键的数据占据了大多数存贮.     11g安装软件太大了, 我还没有下载Windows的版本呢? 谁下载了去拷一下算了....

Posted on November 16, 2007 11:39 AM

少量记录内存排序的成本好象很底......

    前面遇到一个排序的问题后, 昨天在数据库中做一了下调优, 将数据库的内存排序的次数从每秒的550次减少到330次左右, 并临控数据库的负荷, 很失望地发现对于降底数据库的负荷并没有什么作用, 甚至于还变高了一些, 由于没有发现明显的效果, 因此马上取消了所有的调优操作, 返回到原来的状态.     今天早上一来, 就做了以下测试, 首先是不需要排序时的情况: ASQL> @TEST.SQL ASQL> BEGIN /* Test no sorting */     2  FOR I IN 1..10000 LOOP     3      FOR REC...

Posted on August 30, 2006 11:35 AM

OLTP系统中避免不必要的排序的重要性

    就前一篇中的例子, 来作一下10046的跟踪, 看看排序倒底占据了多少的CPU. 我一直是认为就算几条记录的排序也是有代价的, 至少它需要去准备一块排序区, 并运行排序的算法. 有时数据库系统中每秒种会有上千次的内存排序, 这时如果将排序的次数减少到一半, 机器的负荷会下降多少呢? 对于排序没有直接的印象, 不象对于逻辑读那么熟悉. 就等着一步一步研究吧?     先来看一下分区列上用绑定变量(有排序)时的情况: SELECT * FROM TEST_SORT   WHERE COL2=:p_co1 AND PKEY=:p_key AND COL1 IN (810,510,210)   ORDER BY COL1 Rows    Row Source Operation ------- ...

Posted on August 21, 2006 11:13 AM