AnySQL.net

    9i中mts_dispatchers和mts_max_dispatchers虽已过时, 但还保留. 通过SYSMOD一列可以看出, MAX_DISPATCHERS参数和MAX_SHARED_SERVERS参数不能在SYSTEM一级动态修改. 另外在9i中DISPATCHERS参数不能改成空的值.

ASQL> ora parameter dispatchers

NAME                ISDEFAULT SESMOD SYSMOD    VALUE
------------------- --------- ------ --------- -----
dispatchers         TRUE      FALSE  IMMEDIATE
mts_dispatchers     TRUE      FALSE  IMMEDIATE
max_dispatchers     TRUE      FALSE  FALSE     5
mts_max_dispatchers TRUE      FALSE  FALSE     5

4 rows returned.

ASQL> ora parameter shared_servers

NAME               ISDEFAULT SESMOD SYSMOD    VALUE
------------------ --------- ------ --------- -----
shared_servers     TRUE      FALSE  IMMEDIATE 0
max_shared_servers TRUE      FALSE  FALSE     20

2 rows returned.

SQL> alter system set dispatchers='';
alter system set dispatchers=''
*
ERROR at line 1:
ORA-00101: invalid specification for system parameter DISPATCHERS

    10g中mts_dispatchers和mts_max_dispatchers已经看不到了. 通过SYSMOD一列可以看出, MAX_DISPATCHERS参数和MAX_SHARED_SERVERS参数也可以动态修改了. DISPATCHERS参数也可以改成空值了. 说明在10g上转成MTS模式就不需要重启数据库了.

ASQL> ora parameter shared_servers

NAME               ISDEFAULT SESMOD SYSMOD    VALUE
------------------ --------- ------ --------- -----
shared_servers     TRUE      FALSE  IMMEDIATE 5
max_shared_servers TRUE      FALSE  IMMEDIATE 20

2 rows returned.

ASQL> ora parameter dispatchers

NAME            ISDEFAULT SESMOD SYSMOD    VALUE
--------------- --------- ------ --------- -----------------
dispatchers     FALSE     FALSE  IMMEDIATE (PROTOCOL=TCP)...
max_dispatchers TRUE      FALSE  IMMEDIATE 5

SQL> alter system set dispatchers='';

System altered.

    在并发连接数很多的数据库上, MTS模式也可以列入考虑.

    问题从ITPub.net而来:

    我两张表, 分别各600m数据, 有相同得PK，每张表表只有两个字段, 然后建立聚簇, 这个居然有4G多了? 晕!

    当然晕的肯定是你了, 不是Oracle, 这个问题, 我的第一反应是你没有指定SIZE参数, 先来看一段说明吧.

    SIZE

    specifies the amount of space in bytes to store all rows with the same cluster key value or the same hash value. You can use K or M to specify this space in kilobytes or megabytes. The value of this parameter cannot exceed the size of a data block. If you omit this parameter, Oracle reserves one data block for each cluster key value or hash value.

    因此可以推算, 你的表大约有50万个不同的cluster key值, 假定你的块大小是8k. 不知道我猜的对不对?

    当我们创建一个LOCAL的索引时, 这个索引各个分区的名称和表的相应分区的名称是相同的, 但LOB分区及LOB Index分区的名称则是系统产生的. 不知道Oracle为什么顺道改一下?

    下面的查询结果是在10g上进行的, 创建了一个有CLOB字段的分区表, 然后到OBJ$中去查询:

SQL> select obj#,name, subname from obj$
  2  where owner#=25  and obj# > 10000 order by obj#;

      OBJ# NAME                           SUBNAME
---------- ------------------------------ ---------------
     10006 T_PRTLOB
     10007 T_PRTLOB                       SYS_P21
     10008 T_PRTLOB                       SYS_P22
     10009 SYS_LOB0000010006C00002$$
     10010 SYS_LOB0000010006C00002$$      SYS_LOB_P23
     10011 SYS_LOB0000010006C00002$$      SYS_LOB_P24
     10012 SYS_IL0000010006C00002$$
     10013 SYS_IL0000010006C00002$$       SYS_IL_P25
     10014 SYS_IL0000010006C00002$$       SYS_IL_P26

9 rows selected.

    不过按对象号排序, 则很容易对号上座的.

    绝对地来说Oracle在更新表时肯定会自动维护索引的, 不过由于程序的Bug(4258825, 4000840)在有些条件下Insert/Delete/Update表的记录后, Oracle没有维护索引, 就好象是这样的情况, 表中有5条记录(ID=1,2,3,4,5), 这时索引是好的, 现在删除ID=5的记录留下四条, 然后Oracle没有维护这个索引还是保留了5条, 当我们发出WHERE ID=5这样的查询时, 就出现问题了啊, 因为根据ROWID找出来的记录是不对的, 这个称为Orphan ROWID.

    这样的信息其实在alert_sid.log中会有记录的, 还会报出ROWID的, 验证的方法就是如下所示:

select /*+ full(t) */ count(*) from table t where id is not null
select /*+ index(t,id列上的索引名) */ count(*) from table t where id is not null

    如果发现这两个查询出来的结果不一样(请在没有应用向这个表作更改时查询), 就表示有问题了, 你可以选择重建索引来解决这个问题. 一般遇到的是Index上的记录数比表的多, 反过来的可能是观察不到的.

    今天有朋友遇到了这样的经历, 所以写一下, 虽然Oracle说这两个Bug都在10.2.0.1版本上修复了, 不过很多Bug不是说修复了就修复了, 还是会遇到的.

    在Oracle中遇到这样的错误, 是什么含义呢?

ORA-00604: 递归 SQL 层 1 出现错误
ORA-14450: 试图访问已经在使用的事务处理临时表

    首先要查一下错误信息, 可以从手册中查:

Cause: An attempt was made to access a transactional temporary table that has been already populated by a concurrent transaction of the same session.

Action: Do not attempt to access the temporary table until the concurrent transaction has committed or aborted.

    可见是Global Temporary Table上的问题, 我们来模拟一下这个错误:

session 1 (Do not exit)

SQL> create global temporary table t_temp
  2  (
  3    col1 varchar2(200)
  4  )
  5  on commit preserve rows;

Table created.

SQL> insert into t_temp values ('temp');

1 row created.

SQL> commit;

Commit complete.


session 2
SQL> drop table t_temp;
drop table t_temp
           *
ERROR at line 1:
ORA-14452: attempt to create, alter or drop an index on temporary table alreadyin use

SQL> alter table t_temp add col2 varchar2(200);
alter table t_temp add col2 varchar2(200)
*
ERROR at line 1:
ORA-14450: attempt to access a transactional temp table already in use

    而ORA-00604则是因为这段代码是在sys下跑的原因吧.