这是我的 Oracle 11g 系列的文章之一.
用压缩的方式备份，这其实是一个 Oracle 早就应该有的功能。在 10g 中，终于看到 Oracle 实现了这个特性。而 11g 中，又提供了新的可选压缩方式:
RMAN> show all;
......
CONFIGURE COMPRESSION ALGORITHM 'BZIP2'; # default
默认的压缩是 BZIP2。另外一种支持的压缩方式是 ZLIB。相比前者, ZLIB 压缩率不高，不过处理速度快。
做了一个简单的测试，无论是用BZIP2 方式还是 ZLIB 方式， 备份当前的控制文件，压缩与未压缩比率接近为 1:10.
对于海量数据的备份，节省的空间将是惊人的。
要注意的是，COMPATIBLE 初始化参数必须设置 11.0 或者更高。
–EOF–
最近看到几则新闻，都是和网站运营维护有关的，一个比一个离谱。
第一个是云网主站点不可访问。看新闻是从上午折腾到下午还没有修复。有趣的是出了故障之后云网居然把 IP 指向了 127.0.0.1。这是 8 月 9 号的事情。好像找不到云网任何官方对这次故障的说明，至少我没有找到。
第二个是关于工行的。8 月 15 号到 16 号，工行个人银行服务出现故障。据说是”由于15日是存款利息税下调、系统升级改造、新基金发行和拆分、养老金和工资的发放等业务集中所致”，更具体一点是什么原因，恐怕永远不得而知。要说起银行的 IT 系统建设，那可是天文数字啊。可以不夸张的说，硬件只挑贵的买。业务流程，什么标准化的东西，也都是早早建立起来的，但是，但是，但是，但是，还是不管用。
第三个，”当当当”, 当当网的数据库账户泄漏事件。程序出错页面居然把数据库连接串和密码什么的都打印出来了。不得不佩服一下。
当当用的是 SQL Server.
网站的运维是个高精度而高复杂度的事情，远非弄一堆所谓的花哨流程、买一堆昂贵的机器所能解决一切问题的。
当然类似的事情也不止国内有，Facebook 不也出了个源代码泄漏的事故么。总算和国际接轨了。
最让人晕死的事情是今天 Dreamhost DNS 服务出现问题，导致我这个 Blog 10 来个小时不能访问。
–EOF–
关于 Oracle Open World 的最后一篇。记录一些比较有趣的事情。
第一天下午刚到会场的时候展厅还没有开放，偷着溜了进去。在 ITpub 的展台旁边停留了一会儿。偶然注意到登记簿上第一个会员签名居然是 Mugen。巧的是，转了一圈就看到了他。Mugen 告诉我，他上次考 OCM 就差一道题没有过，很是惋惜。线下的 Mugen, 一点都不向以前网络上的那个 Mugen 那么搞笑，他在 ITpub 上的经典句式”人才啊”让无数人笑倒。Mugen 的 Blog 写的还是挺好玩的，最近买房子那一篇很好看，真情实感。在杭州和他一起吃过饭的，但是总感觉还没有见过他。怪哉。
IT168 请会员吃饭，几十人的大聚餐。我和 Anysql(d.c.b.a) 两个人早早就出发了，出了地铁站走了好远，一身汗。可我们到了好久 Biti 他们才到。原来，他们开车找不到路，在他手里好好的 GPS，交给了 Kamus 就不管用，也不知道是不是盗版的问题，汗一个，在浦东绕了两圈还找不到地下通道入口，不得已开车回了宾馆，打了一辆出租车…
美国那边 Oracle 和 SAP 视同水火，口水仗打的不可开交。可在中国好像不是那么一回事。SAP 在 Oracle Open World 有个展位的。大家看了都笑。
应该是 Sun 的展台。因为送的 T-shirt 是 Sun 的，可那件 T-shirt 是 2005 年活动剩下的，可真够节省的。
–EOF–
这是我的 Oracle 11g 系列的文章之一.
在 Oracle 11g 以前的版本，在一个产品环境评估一个有待添加的索引是个麻烦事情。稍有不慎影响该表 SQL 执行计划走错，就可能带来灾难性的影响。这个问题可能也是 Oracle 比较重视的，在 11g 上新推出了 INVISIBLE 索引。这个索引创建后，默认对于 CBO 是不可见的。也就是说不会影响(抛开 DDL 时候的 SQL 重新解析)现有的 SQL 执行计划。如果要在 Session 级别激活这个索引，需要设置初始化参数: OPTIMIZER_USE_INVISIBLE_INDEXES .
注意新的关键字
SQL> CREATE INDEX emp_ename ON emp(ename)
2 TABLESPACE users
3 INVISIBLE;
Index created
USER_INDEXES 视图的新列 VISIBILITY
SQL> select INDEX_NAME ,VISIBILITY from user_indexes;
INDEX_NAME VISIBILITY
------------------------------------------------------------ ------------------
PK_DEPT VISIBLE
PK_EMP VISIBLE
EMP_ENAME INVISIBLE
SQL> select count(*) from emp where ename='ADAMS';
COUNT(*)
----------
1
Execution Plan
----------------------------------------------------------
Plan hash value: 2083865914
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 7 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 7 | | |
|* 2 | TABLE ACCESS FULL| EMP | 1 | 7 | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------
告诉优化器使用 INVISIBLE 索引
SQL> alter session set OPTIMIZER_USE_INVISIBLE_INDEXES=true;
Session altered.
SQL> select count(*) from emp where ename='ADAMS';
COUNT(*)
----------
1
Execution Plan
----------------------------------------------------------
Plan hash value: 1569421590
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 7 | 1 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 7 | | |
|* 2 | INDEX RANGE SCAN| EMP_ENAME | 1 | 7 | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------
值得注意的是 VISIBILITY 索引在 Rebuild 后会变成可见索引：
SQL> select INDEX_NAME ,VISIBILITY from user_indexes;
INDEX_NAME VISIBILITY
------------------------------------------------------------ ------------------
PK_DEPT VISIBLE
PK_EMP VISIBLE
EMP_ENAME INVISIBLE
SQL> alter index EMP_ENAME rebuild;
=Index altered.
SQL> select INDEX_NAME ,VISIBILITY from user_indexes;
INDEX_NAME VISIBILITY
------------------------------------------------------------ ------------------
PK_DEPT VISIBLE PK_EMP VISIBLE
EMP_ENAME VISIBLE SQL>
这算是个 Bug 么? 还是本身的特性 ?
对于 INVISIBLE 索引，可以修改属性为 VISIBLE。正常的索引也可以修改为 INVISIBLE 状态。如果修改后仍然要使用这个索引，在语句中使用 HINT 即可。我就不一一演示了。
很多人都知道 Oracle 在 OEM 中早就实现了一个类似的功能：Virtual index(虚拟索引)。但是差别也是比较明显的。虚拟索引，真的是虚拟的，并不占用实际的磁盘空间。而 Invisible 索引需要占用磁盘空间。虚拟索引不可以 Alter ，而 Invisible 可以象正常索引那样进行一些维护工作。Invisible 索引的实现思路有些类似 Quest 以前的优化建议，也是直接会在数据库里面创建建议的索引，但是却不能屏蔽对 CBO 的影响。另外一个需要考虑的是 Virtual index 是 OEM 优化包 的功能，需要额外的 License (当然也可以用命令行创建)。
Invisible 对 DBA 来说，对 DBA 调优的时候多了一个更好的可选方法。
–EOF–
