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

将完成AUL最后一个心愿, 支持Compress表

    通过二十分钟的发呆, 进入了研究Oracle压缩(Compress)表的大门, 随之而来的这几天, 研究得很顺利, AUL 5的测试版发布了. 知道Oracle DUL 10版本支持压缩表后, 心中一直就有一个结, 如今这结已经打开, 剩下的只是多做些测试去发现Bug并解决Bug了. 在对Oracle文件格式的研究中, 我找到了自已的DBA激情, 那就是研究Oracle的兴趣, 给平静的DBA生活增加了一些特有的颜色.     由于程序设计当初没有考虑压缩表的需求, 这一次的变动很大, 处理一个数据块内记录的函数(如printDataRows函数), 已经全部重写. 因此在最近一段时间内, AUL 5还不适合作为正式数据恢复的版本, 除非你需要恢复Compress表. 当然欢迎大家来对AUL 5进行测试, 测试方法如下: 1, 创建一个压缩表T_COMPRESS 2, 用AUL 5进行恢复(恢复步骤) 3, 将恢复出来的记录装载到非压缩表T_NOCOMPRESS中 4, SELECT...

Posted on November 6, 2007 3:59 PM

发呆, 是研究Oracle的有效方法

    上一次在火车上发呆是在研究Log文件格式时, 想了好久都没有想清楚, 于是将一段Log的二进制代码打了张纸, 终于在火车上发呆时想出来了. 今天同样发呆了一次, 不在火车上, 也没有打印出纸来, 而是对着屏幕发呆, 而结果则是快要搞清楚Oracle压缩块的格式了.     上一次研究压缩块已经是一年多以前的事了. 在过去的一年中, 没有为此事着急, 因为压缩块存在很多的Bug, 有的已经修正, 但有的则因为用得人少可能还没有发现, 因此没有压缩表支持的AUL还是得到了大家的欢迎. 不过从Oracle 11g大力推广压缩功能来看, 应当是改进了不少. 根跨版本使用新功能的原则, 在Oracle 11g中应当会有正式开始应用的例子了. 为了让AUL活得更久, 就得支持它.     qiuyb版主最近在写DUL的文档, 并确认DUL 10已经支持压缩块了, 看来AUL已经落后一步了. 这也是今天发呆的原因, 没想到还真管用. 预计支持压缩表的AUL 5将会在明年上半年推出.    ...

Posted on October 30, 2007 8:17 PM

Oracle 11g新特性 -- DG压缩传送日志

    用DataGuard做远距离的容灾时, 日志的传送也会成关键的问题. 面对这个问题, 首先会想到将Archive Log先缩压一下, 再进行传送, 或者用rsync(现在用得越来越广了)加上压缩选项来处理, 可以说Oracle的这个功能来得太晚了, 应当在9i时就加上.     通过LOG_ARCHIVE_DEST_n中的一个参数可以控制是否启用压缩功能, 默认值是禁用的. 如下所示: LOG_ARCHIVE_DEST_n='SERVICE=... COMPRESSION={ENABLE|DISABLE}'     Oracle自身带的这个功能可以大大简化DBA的编程工作. 需要注意的是, 压缩数据是很耗CPU的一件事情, 需要考虑源端的CPU的使用情况, 尤其是你用LGWR传送日志时, 更要慎重考虑. 你可以在本地建一个中转节结点, 然后利用这个压缩功能将日志传送到远距离的DataGuard节点.     DBA又可以多花点时间喝茶看报了!...

Posted on September 4, 2007 10:00 PM

计划AUL 5, 需要解决压缩表的支持问题

    这几天, 没有比Oracle 11g更让大家关心了, 从白皮书中看出, Oracle对于压缩技术的支持又上升了一个台阶. 从9i版本引入压缩表以来, 经过10g到11g, 按Oracle历来的表现, 尤其是宣称OLTP级的压缩技术, 这一次应当可以广泛应用了.     因为压缩技术在目前用得很少, 因此当初先考虑LOB的支持而实现了第4版本, 接下来要考虑的是对压缩的支持, 而发布到第5版本, 要以11g中的压缩功能为基础去开发. 在过去的一段时间中, AUL真真实实地帮人解决了一些极端情况下的数据恢复问题, 因此感觉还有继续开发的必要.     另外还要考虑的是对于ASM的支持, 越来越多的系统已经开始使用ASM了. 以及BigFile的支持, 虽然这个功能目前很少人使用. 个人认为, 这个BigFile不如改成一个表空间由最多256个文件组成, 而每个文件的最大大小是现在的4倍, 比如8KB的块大小, 最大的文件大小为256GB, 这样更实用.     不过是越来越搞不动这种研究了, 不知道还能跟上11g这条大船吗?...

Posted on July 13, 2007 9:39 PM

Oracle的压缩块的初步研究之一

    Oracle Compress是一种在DW中节约空间的有效方式, 虽然在Oracle 9i中有些bug, 但相信在以后的版本中会比较强壮的, 因为在MYDMP中不支持Compress 的表,我想在以后的版本中增强一些, 所以先做了一些简单的研究, 下面是我偶然在火车上发现的规律.    Compress需要一些额外的信息. 在Oracle中Compress是以块为单位的, 也就是说一个表的所有数据块中有的块可能是Compress的, 而有的却不是. 根据块中的信息就可以解压的, 而不需要查询数据字典.   我建了一张测试表, 只有两个字段(col1和col2), col1的值为"Compress1"和"Compress2", col2的值为"Compress Row1"和"Compress Row2", 我用不同的组合插入了很多记录, 发现一个块中存贮了709条记录. 这说明数据是压缩了(block_size=8192).   Compress块的结构有点类似于Cluster的块, 在块中显示的表数为2个, 其中Table 0为单词列表,或组合, 如对于上述值, 则有如下值组合:...

Posted on August 17, 2006 11:28 PM