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

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

Oracle 11g系列测试 -- MyLOG

    象Log文件格式这样的研究,　是非常怕新版本的发布的. Oracle 11g的发布给我有点压力, 因为Oracle肯定会或多或少地对它作一些修改, 而象我这样没有官方支持的研究, 就比较难办了, 只能多作些测试了. 下午稍稍测试了一下MyLOG对Oracle 11g版本日志文件支持性.     原来以为什么都不用改的想法是落空了, 不过从目前看来, 我所关心的部份改动不会很大, 因为我稍稍修改了一下程序后, 已经可以解出SQL了, 基本上应当达到了对10g的研究水平. LOG> extract table t_11glog start 2 Start extract redo SQL ... RBA=0x000006.00017662.0010,  XID=0x0001.01c.000000a7   RID=AAAC7bAAEAAAAPQAAA   INSERT INTO T_11GLOG ( COL1...

Posted on September 4, 2007 7:47 PM

修正AUL恢复ASSM表空间数据时的一个问题

    eagle_fan在Linux机器上装了一个Oracle 11g, 今天在测试AUL对Oracle 11g的支持时, 发现了一个ASSM表空间上的问题, 会导致恢复的记录数偏少, 原因是因为ASSM下每一个Extent的第一个数据块不一定是表的数据.     在Free List管理的模式下, 一个Extent中只有两种块, 数据块和没有被使用的块, 并且数据块总在最低端, 为了程序性能, 当AUL检测到第一个非数据块的块时, 就不处理这个Extent了.　然尔在ASSM的情况下, 一个Extent中可能有三种块, bitmap块(type=32), 数据块以及没有使用的块. 当bitmap块在头部时, 就导致了整个Extent中的数据都被跳过了. 不知道有没有朋友遇到这个问题?     通过SCAN EXTENT命令来生成Extent信息时, 则恢复是完全准确的. 这个问题仅限于ASM表空间及没有运行SCAN EXTENT的情况, 对于Free List管理的表空间则没有影响. 以往经历的正式数据恢复都不是ASSM类型的, 这也是这个问题没被早些发现的原因.     对于11g还要进行更详细的测试, 支持11g是没有问题的,...

Posted on September 4, 2007 2:45 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 11g性能提升 -- 其他地方

    看白皮书上这么多的功能, 如果在11g中能很成熟, 那真是一个变化比较大的改进, 来看一下关于性能方面的其他改进吧.     1, RAC节点通信协议的改进.     11g中的协议比较智能, 可以根据节点的负荷作出动态的调整, 大大减少节点之间的消息传递量. 说老实话不知道是如何工作的.     2, 边恢复边Open的Physical Standby -- Highly Available Reader Farms     这个功能肯定很受大公司的欢迎, 因为以前的Data Guard不能做到这样, 当Open时同主库的延迟会越来越大, 而在11g中则不存在这样的延迟, 因此可以建几个这样的Standby来分担读操作, 估计Shareplex或Realsync这样的软件市场要受到一定的影响了, 我对Log的研究也变得越来越没有价值了.     3, 面向OLTP的压缩表...

Posted on July 13, 2007 11:03 AM

Oracle 11g性能提升 -- Server Connection Pool

    在应用服务器这一层, 我们已经使用Connection Pool了, 可以有效地降低服务器上的连接的数量, 不过还是有不足之处的. 当你的访问量达到一定的规模时, 你会发现一台或几台应用服务器根本就解决不了问题, 在有些世界级的网站中, 应用服务器的数量可能是上千台的, 当每个应用服务器产生4-5个连接时, 你会发现Oracle服务器端便有了4-5千个物理连接. 象PHP程序, 要求每一个Web Server进程都至少有一个连接. 因此Oracle在11g中引入了Database Resident Connection Pool的功能, 这样客户端就可以不管连接池了, 由Oracle在服务器端进行连接共享控制.     通过增加一个后台进程CMON(Connection Monitor)来管理连接, 应用发出连接请求时, 实际上是连接到CMON进程, 然后由CMON进程分配一个已经连接好的后台进程, 当客户端连接关闭后, 这个后台进程又交由CMON进程管理. 估计PHP这类的Web程序要有福气了, 不需要去实现连接池的代码了.     但还有两个问题需要问, 可能会在正式的文档中有详细的说明: 1, 如果我连上去后, 一直不关闭连接,...

Posted on July 12, 2007 3:34 PM

Oracle 11g性能提升 -- Consistent Client Cache

    10g几乎没有关心, 现在都现11g了, 得关心一下了, 要不然就落伍了. Cache始终是提升性能的重要技术. 除了在前面讲的Server Result Cache, Oracle 11g还增加了一种Client Cache. 第一眼看到时, 我猜测可能和在程序中用数组保存一些查找表差不多, 不过仔看白皮书, 还是要比自已写程序来得方便许多.     这是一种在Oracle Client端的缓冲技术, 通过将中间结果或整个表缓冲在客户端, 当客户端发出查询请求时, Oracle可以直接在这个缓冲区中返回记录, 而不需要去和数据库打交道, 可以大大地着少和服务器端的网络来回, 降底服务器上的SQL调用, 根据Benchmarks测试, 对于只读或极少更新的表, 总的消耗时间可以降低500%, 而服务器上的CPU时间可以降低200%.     要使用这个Cache功能, 也很简单, 首先要使用Oracle 11g的OCI客户端, 如: JDBC-OCI, ODBC,...

Posted on July 12, 2007 3:12 PM

Oracle 11g性能提升 -- Server Result Cache

    10g几乎没有关心, 现在都现11g了, 得关心一下了, 要不然就落伍了. Cache始终是提升性能的重要技术, 在Oracle 11g中增加了一种Server Result Cache, 第一眼看到这个名字, 我觉得和MySQL的Query Cache是差不多的技术, 不过仔看白皮书, 还是要比MySQL进步多了.     谁可以共享这些数据? MySQL的Query Cache是根据SQL的文本来匹配的, 只有Query的文本一模一样时才可以共享, 而Oracle的Server Result Cache则只要执行计划一样或部份一样, 并且生命周期一样, 则就可以共享了. 当下面的表数据改变了, Oracle会自动清除这个Cache, 以确保查询结果的正确性. 在以读为主要的系统中, 宣称性能可以提升一倍.     这块内存从SGA中分配, 由RESULT_CACHE_MAX_SIZE控制. Oracle允许你在系统, 会话, 表和语句级(Hint:result_cache)控制是否使用Server Result...

Posted on July 12, 2007 2:53 PM

测试11g的AUL数据恢复, 好象块格式没有变.

    热心网友上传了一个Oracle 11g的数据文件, 我就用AUL去测试了一下AUL能不能恢复11g的数据文件, 解开压缩文件后, 创建一个配置文件db.txt, 包括如下行: 1 1 users01.dbf     接下来运行AUL, 并打开配置文件, 用ORADUMP命令查看一下文件头的属性, 从ver的值可以看出数据库是11g的(十六进制0x0b等于十进制11), 而从fmt的值来看, 0xa2表示还是10g的格式, 0xa等于十进制的10. 如下所示: AUL> open db.txt *  ts#  fno  rfn ver bsize     blocks filename - ---- ---- ---- --- ----- ---------- ----------------------- Y    4    4    4 a2   8192        640...

Posted on June 20, 2007 5:07 PM

Oracle 11g中有INDEX_COL这个Hint吗?

    当我们进行索引的联机维护(重命名, 改结构, 或删除)时, 会让现有的SQL走了错误的路径, 因为在现有的索引的HINT中一般都直接指明了索引的确切名字, 为了让SQL走新的索引, 你可能不得不去更改SQL中的HINT, 或用Outline来实现, 这样其实并不方便. 另外对于开发人员来说, 他们或许不知道那个索引更好, 但他们一般知道这个表上那个列的可选择性(Selectivity)好一些. 如果有方法能让Oracle的优化器选择某些列或以某些列前导的索引, 对DBA及开发人员都将十分有利. 一年多以前我就想让Oracle加一个INDEX_COL的HINT, 在用时我们只需要指定"index_col(表名, 列, ...)"就行了.     为此我在Google讨论组上发了这个点子, 有人提示我Oracle已经有一个没有公开的HINT来实现这个功能了, 是Jonathan Lewis在10g版本中发现的, 对于这个用法, 我个人十分喜欢, 想不出大师是如何发现这个的? Oracle有内鬼和他相通?     下面是这个HINT的一个用法, 将让Oracle选择以COL1或COL1+COL2列开头的索引(需要做实验验证一下), 但不会选择以COL2列开始的索引, 这一点要注意了, 不过不同的版本中, Oracle会有所更改. 不知道这个功能在Oracle 11g中有没有作出改进?...

Posted on February 6, 2007 12:55 PM

RMAN Copy加上Rsync, 在Oracle 11g中实现了吗?

    去年有一段时间经常要为很忙的系统重建Standby, 因为归档生成量很多, 而存放归档日志的卷空间却不是很多, 给重建Standby带来很大的难处. 将表空间置为Begin Backup状态后, 生成的归档日志量更是加倍, 因此我们不得不用RMAN的Copy功能来进行数据文件拷贝, 但是没有办法直接拷贝到远程的机器上, 而用RMAN的Copy功能来拷贝文件的话则日志量不会增大, 但必须先拷到本地, 然后拷贝过去. 为什么不用NFS, 在不同的Data Center之间, 做NFS不是很简单的事, 在我们这儿, DBA只做DBA的事情.     Rsync是很好的在Linux/Unix主机间拷贝文件的好工具, 还具有压缩功能, 可以适应网络条件不是很好的情况, 而不同的数据中心之间, 就是一个很合适的场合. 如何将两者结合起来, 这样的话将是一个完美的组合. 不少的刚入门的DBA, 拷出来的文件总是Online Fuzzy的, 说明RMAN Copy和Hot Backup还是比较难的.     于是我就想到了一个osync的程序, 将这两个结合起来, 直接"osync...

Posted on February 5, 2007 5:32 PM