Results tagged “11g”

这是我的 Oracle 11g 系列的文章之一.

Oracle 11g SQL*Plus 也有不少新功能，这个 Error Logging 的新功能很有趣，也比较实用。当激活该功能后，可以记录 SQL*Plus 操作相关错误信息到具体的数据库表里面，对于以后追查很方便。激活的语法如下：

SQL> set ERRORLOG ON
SQL> desc SPERRORLOG
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 USERNAME                                           VARCHAR2(256)
 TIMESTAMP                                          TIMESTAMP(6)
 SCRIPT                                             VARCHAR2(1024)
 IDENTIFIER                                         VARCHAR2(256)
 MESSAGE                                            CLOB
 STATEMENT                                          CLOB

激活的时候会自动创建这个表。然后即可存储 ORA、PLS 与 SP2 类型的错误信息。

SQL> drop ttt ;
drop ttt
 *
ERROR at line 1:
ORA-00950: invalid DROP option
SQL> select username,timestamp,message from SPERRORLOG;
USERNAME   TIMESTAMP                      MESSAGE
---------- ------------------------------ ----------------------------------------
SCOTT      25-AUG-07 02.22.09.000000 PM   ORA-00950: invalid DROP option

除此之外，亦可自行定制表，进一步定制存储错误信息。

默认情况下该选项是关闭的。另外，为避免递归调用错误记录, internal 错误不被记录.

--EOF--

正当我们为 Oracle 新版本中有的特性稍微感动激动的时候，一瓢凉水浇了下来：想用新特性，拿钱来。

在 Oracle 这篇声明中宣布了 11g 有四个额外的特性是要单独收取 License 费用的。价格呢? 就是一个字，贵! 新的四个收费功能：

* Oracle Real Application Testing -- $10,000 per processor or $200 per named user;
* Oracle Advanced Compression -- $10,000 per processor or $200 per named user;
* Oracle Total Recall -- $5,000 per processor or $100 per named user; and,
* Oracle Active Data Guard -- $5,000 per processor or $100 per named user.

点击查看 Oracle 全部产品价格列表。

一方面四面出击，大手比收购，一方面银子大笔落袋。查看资料显示，Oracle 在整个 2007 财年，"Oracle应用软件新许可证收入增长了32%"。Oracle 的抢钱本领让人赞叹。

--EOF--

这是我的 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--

这是我的 Oracle 11g 系列的文章之一.

在 Oracle 11g 以前的版本，在一个产品环境评估一个有待添加的索引是个麻烦事情。稍有不慎影响该表 SQL 执行计划走错，就可能带来灾难性的影响。这个问题可能也是 Oracle 比较重视的，在 11g 上新推出了 INVISIBLE 索引。这个索引创建后，默认对于 CBO 是不可见的。也就是说不会影响(抛开 DDL 时候的 SQL 重新解析)现有的 SQL 执行计划。如果要在 Session 级别激活这个索引，需要设置初始化参数: OPTIMIZER_USE_INVISIBLE_INDEXES .

创建 INVISIBLE 索引

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--