AnySQL.net

在10g中不能将Optimizer_features_enable设成10.2.0, 而9i中则可以不带第四个版本号.

    上一次发现访问X$KSLEI时, 用这个Hint很有效, 后来在更多的机器上测试, 发现有的数据库上这个Hint并不工作, 如下所示:

SQL> SELECT /*+ USE_CONCAT */ * FROM X$KSLEI WHERE INDX IN (1,2);

----------------------------------------------------
| Id  | Operation        | Name    | Rows  | Bytes |
----------------------------------------------------
|   0 | SELECT STATEMENT |         |    20 |  1680 |
|*  1 |  FIXED TABLE FULL| X$KSLEI |    20 |  1680 |
----------------------------------------------------

    最后只好化简为繁, 改成用UNION ALL来实现, 这下Oracle没得选择了.

SQL> SELECT * FROM X$KSLEI WHERE INDX = 1 UNION ALL
  2  SELECT * FROM X$KSLEI WHERE INDX = 2
  3  /

----------------------------------------------------
| Id  | Operation                | Name            |
----------------------------------------------------
|   0 | SELECT STATEMENT         |                 |
|   1 |  UNION-ALL               |                 |
|*  2 |   FIXED TABLE FIXED INDEX| X$KSLEI (ind:2) |
|*  3 |   FIXED TABLE FIXED INDEX| X$KSLEI (ind:2) |
----------------------------------------------------

    很多人动不动就想用Direct SGA Access的方法来写数据库监控程序, 其实好好调一下SQL, 可以不用那么复杂.

    充分利用X$表上的特殊索引, 可以加快对性能视图的访问速度, 从而编译高效的性能监控程序. Oracle提供了一个视图可以用来查询在X$表的那些列上有这样的索引存在, 如下所示:

SQL> DESC V$INDEXED_FIXED_COLUMN
Name                 Null?    Type
-------------------- -------- -------------
TABLE_NAME                    VARCHAR2(30)
INDEX_NUMBER                  NUMBER
COLUMN_NAME                   VARCHAR2(30)
COLUMN_POSITION               NUMBER

    有时我感觉查询V$SYSSTAT中的记录都有些慢, 看看它上面有没有索引进技术, 先用AUTOTRACE看一下这个视图的X$表是那一个.

SQL> SELECT * FROM V$SYSSTAT;

-------------------------------------------------------
| Id  | Operation        | Name       | Rows  | Bytes |
-------------------------------------------------------
|   0 | SELECT STATEMENT |            |     1 |    99 |
|*  1 |  FIXED TABLE FULL| X$KSUSGSTA |     1 |    99 |
-------------------------------------------------------

    在9i中这个基表是有一个索引存在的, 对应于STATISTIC#这一列, 不过在10g中没有了, 不知道为什么取消了?

SQL> SELECT * FROM V$INDEXED_FIXED_COLUMN WHERE TABLE_NAME='X$KSUSGSTA';

no rows selected

    否则我又想要化简为烦, 来进行UNION ALL了.

    在本地建Standby时会遇到下面这个错误. 有几个库是从同一个源库拷贝出来, 今天在为他们在同一台机器上建Standby也遇到了这个问题, 这几个库拷出来后就没有改更过DB_NAME, 因此他们都是相同的, 只是实例名不同而已.

SQL> alter database mount standby database;
alter database mount standby database
*
ERROR at line 1:
ORA-01102: cannot mount database in EXCLUSIVE mode

    其实这个问题和一个文件有关, Oracle数据库在运行着时会锁定生成或锁定一个文件. 发现在数据库运行着时, 用fuser可以看到有Oracle的进程在打开这个文件, 而在Windows中则不能删除这个文件. 如数据库PROD.

C:\oracle\product\10.2.0\database\hc_PROD.dat
/app/oracle/product/10.2.0/dbs/lkPROD

    这个文件默认是从DB_NAME来生成的, 但是如果设了LOCK_NAME_SPACE值, 如改成PRODSTBY, 则这个文件名就变成了从LOCK NAME SPACE的值来生成. 如:

C:\oracle\product\10.2.0\database\hc_PRODSTBY.dat
/app/oracle/product/10.2.0/dbs/lkPRODSTBY

    另外一个猜测想, 如果我们用一个Perl角本或其他程序锁定这个文件名, 也可以模拟出这个错误的, 还没有去验证这一点.

    用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又可以多花点时间喝茶看报了!