其实object_id和data_object_id同样是表示数据库对象的一个唯一标志，但是object_id表示的是逻辑id，data_object_id表示的是物理id。如果一些object没有物理属性的话那它就不存在data_object_id，例如procedure,function,package,data type,db link,mv定义,view定义,临时表,分区表定义等等这些object都是没有对应着某个segment，因此它们的data_object_id都为空。

当表刚创建的时候它的object_id和data_object_id都是相等的，但是如果表经过move或truncate等，涉及到segment发生改变后data_object_id将会有变化。

DATA_OBJECT_ID was introduced in 8.0 to track versions of the same segment (certain operations change the version). It is used to discover stale ROWIDs and stale undo records.

SQL> create table xff as select * from dba_objects where rownum<100;
Table created
SQL> select object_id,data_object_id from user_objects where object_name='XFF';
 OBJECT_ID DATA_OBJECT_ID
---------- --------------
    211325         211325
SQL> alter table xff move;
Table altered
SQL> select object_id,data_object_id from user_objects where object_name='XFF';
 OBJECT_ID DATA_OBJECT_ID
---------- --------------
    211325         211326
SQL> truncate table xff;
Table truncated
SQL> create index ind_xff on xff(object_id);
Index created
SQL>  select object_id,data_object_id from user_objects where object_name='IND_XFF';
 OBJECT_ID DATA_OBJECT_ID
---------- --------------
    211328         211328
SQL> ALTER INDEX IND_XFF REBUILD;
Index altered
SQL>  select object_id,data_object_id from user_objects where object_name='IND_XFF';
 OBJECT_ID DATA_OBJECT_ID
---------- --------------
    211328         211329

1、监控语句
ALTER INDEX owner.index_name MONITORING USAGE;
2、查看监控情况
select * from v$object_usage;
3、使用sys用户无法查询到监控对象问题解决
3.1）查询建立v$object_usage的语句

CREATE OR REPLACE FORCE VIEW v$object_usage (index_name,
table_name,
MONITORING,
used,
start_monitoring,
end_monitoring
)
AS
SELECT io.NAME, t.NAME, DECODE (BITAND (i.flags, 65536), 0, 'NO', 'YES'),
DECODE (BITAND (ou.flags, 1), 0, 'NO', 'YES'), ou.start_monitoring,
ou.end_monitoring
FROM SYS.obj$ io, SYS.obj$ t, SYS.ind$ i, SYS.object_usage ou
WHERE io.owner# = USERENV ('SCHEMAID')
AND i.obj# = ou.obj#
AND io.obj# = ou.obj#
AND t.obj# = i.bo#;

3.2）从该语句中发现，只有当前用户才可以查询到index的监控情况，即使sys也不能查看到
3.3）解决sys可以查询到index监控情况可以除掉io.owner# = USERENV (‘SCHEMAID’)即可

SELECT *
  FROM (SELECT USERNAME OWNER,
               IO.NAME INDEX_NAME,
               T.NAME TABLE_NAME,
               DECODE(BITAND(I.FLAGS, 65536), 0, 'NO', 'YES') MONITORING,
               DECODE(BITAND(OU.FLAGS, 1), 0, 'NO', 'YES') USED,
               OU.START_MONITORING START_MONITORING,
               OU.END_MONITORING END_MONITORING
          FROM SYS.OBJ$         IO,
               SYS.OBJ$         T,
               SYS.IND$         I,
               SYS.OBJECT_USAGE OU,
               DBA_USERS        U
         WHERE I.OBJ# = OU.OBJ#
           AND IO.OBJ# = OU.OBJ#
           AND T.OBJ# = I.BO#
           AND U.USER_ID = IO.OWNER#)
--USED='YES'--表示有使用
--USED='NO'--表示没使用
 WHERE USED = 'YES';

如果想查询方便，可以创建sys下面的下个视图
4、停止监控
ALTER INDEX owner.index_name NOMONITORING USAGE;

一、SCN类型
1).System Checkpoint SCN
当checkpoint完成后，ORACLE将System Checkpoint SCN号存放在控制文件中。
我们可以通过下面SQL语句查询：
select checkpoint_change# from v$database;
2).Datafile Checkpoint SCN
当一个检查点动作完成之后，Oracle就把每个数据文件的scn单独存放在控制文件中.
我们可以通过下面SQL语句查询所有数据文件的Datafile Checkpoinnt SCN号。
select name,checkpoint_change# from v$datafile;
3).Start SCN (启动SCN)
checkpoint完成后，将产生的checkpoint SCN 写入数据文件头(称之为start scn).这个SCN用于检查数据库启动过程是否需要做media recovery.
我们可以通过以下SQL语句查询：
select name,checkpoint_change# from v$datafile_header;
注意：数据文件头中的检查点SCN(start SCN) 与控制文件中记录的数据文件检查点SCN号含义是一样的。 也就是说，一旦发生全局范围以及文件级别的检查点时，不仅会将这时的检查点SCN号记录到控制文件，还会记录在检查点作用的数据文件头部。
4).End SCN号(stop scn, 终止SCN)
这个SCN号用于检查数据库启动过程是否需要做instance recovery.
我们可以通过以下SQL语句查询：
select name,last_change# from v$datafile;
在正常的数据库操作过程中，所有正处于联机读写模式下的数据文件的终止scn都为null.
二、各SCN之间关系
1）数据库运行期间的scn值
在数据库打开并运行之后，控制文件中的系统检查点、控制文件中的数据文件检查点scn和每个数据文件头中的启动scn都是相同的。控制文件中的每个数据文件的终止scn都为null.
2）数据库正常关闭的scn值
在安全关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn都会设置成数据文件头中的那个启动scn的值。
3）数据库重启过程中scn作用
在数据库重新启动的时候, Oracle将文件头中的那个启动scn与数据库文件检查点scn(控制文件中)进行比较，如果这两个值相互匹配，那么不需要Media Recovery， oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn, 如果这两个值也一致，就意味着所有对数据库的修改都没有在关闭数据库的过程中丢失，因此这次启动数据库的过程也不需要任何恢复操作(即不需要实例恢复)，此时数据库就可以打开了。当所有的数据库都打开之后，存储在控制文件中的数据文件终止scn的值再次被更改为null，这表示数据文件已经打开并能够正常使用了。
还需要注意的是:
在数据库重新启动的时候, Oracle首先比较(每个)文件头中的那个启动scn (start SCN) 与控制文件中记录的 (每个) 数据库文件检查点scn， 如果他们都相互匹配，那么不需要Media Recovery. 但是如果只是控制文件中记录的数据文件检查点(多个数据文件，对应多个SCN), 与 (对应的) 数据文件头中的启动SCN (start scn) 相同 , 而在每个在线的可读可写的数据文件“之间”，他们的检查点SCN不相同， 那么也要求Media Recovery .

一、诡异dblink起源
今天开发拿过来一条sql，说有诡异现象，sql如下

INSERT INTO TAB_CS_CALLLOG
select c.user_logon,/*工号*/c.user_name,/*姓名*/a.call_id,/*通话id*/
      a.caller_nbr,/*主叫号码*/a.called_nbr,/*被叫号码*/d.start_time,/*呼入时间*/
      b.call_time,/*接听时间*/b.end_time,/*结束时间*/b.call_dura,/*时长*/
      to_number(b.call_time-d.start_time)*24*3600,/*等待时长*/
      decode(c.user_logon,null,0,1),/*类型*/
case
        when substr (a.CALLED_NBR,7, 2) = '00'
          then '广东移动'
        when substr (a.CALLED_NBR,7, 2) = '01'
          then '浙江移动'
        when substr (a.CALLED_NBR,7, 2) = '02'
          then '福建'
        when substr (a.CALLED_NBR,7, 2) = '03'
          then '四川'
        when substr (a.CALLED_NBR,7, 2) = '04'
          then '河南'
        when substr (a.CALLED_NBR,7, 2) = '05'
          then '湖北'
        when substr (a.CALLED_NBR,7, 2) = '06'
          then '北京CSIP'
        when substr (a.CALLED_NBR,7, 2) = '07'
          then '陕西'
        when substr (a.CALLED_NBR,7, 2) = '08'
          then '吉林'
        when substr (a.CALLED_NBR,7, 2) = '09'
          then '江西'
        when substr (a.CALLED_NBR,7, 2) = '10'
          then '宁夏'
        when substr (a.CALLED_NBR,7, 2) = '11'
          then '太原'
        when substr (a.CALLED_NBR,7, 2) = '12'
          then '江苏移动'
        when substr (a.CALLED_NBR,7, 2) = '13'
          then 'e掌管'
        when substr (a.CALLED_NBR,7, 2) = '15'
          then 'e多商'
        when substr (a.CALLED_NBR,7, 2) = '18'
          then '江苏联通'
      end 区域
from cscnew.a@cs a,cscnew.b@cs b,cscnew.c@cs c,cscnew.d@cs d
where a.call_serial=b.call_serial(+)
and b.call_serial=d.call_serial(+)
and b.user_id=c.user_id(+)
and substr(a.CALLED_NBR,1, 6) = '951654'
and  length (a.CALLED_NBR) = 15
and b.fail_reason is null
and a.end_time>=to_date('20110822000000','yyyymmddhh24miss')
and a.end_time<to_date('20110823000000','yyyymmddhh24miss');

然后我进行了测试，证实了她所说的诡异：
1、直接执行select语句需要1.7S左右，但是加上insert inot后，执行时间需要6分钟
2、直接select结果集为602条，加上insert into后，结果集为598条（少4条），如果直接执行select，除掉and b.fail_reason is null限制条件也刚好602条
二、查询相关资料，得到dblink的一些解释
1、dblink执行有两种方式，一种是在远处数据库执行完，然后结果返回，另一种是把远程的表下载到本来，然后执行
2、如果把远程的表下载到本地，空值或者null可能会发生变化（怀疑是空值转化为null，未证实）
三、根据这些解释，进行猜想
1、只执行select的时候，应该是在远程执行完，传输结果回来；而执行insert into的时候，是把远程的表全部下载到本地，然后执行出结果，而数据量本身比较大，所以比较慢
2、在把表从远程下载到本地的过程中，fail_reason 列的null值可以发生了变化，或者空值变为了null，所以数据多了4条
四、事实证明猜想
1、查询远程表大小，发现a表50m，b表400m，c表10m，d表100m左右，传输过来需要一定的时间
2、既然猜测是由于要把表传输到本地而导致这样的结果产生，那么处理方法就是让程序在远程计算出结果，然后传输到本地，查询了一些资料，上面说insert into会导致driving_site提示无效，那么我想到一个用视图的办法解决这个问题：在目标端建立一个关于本查询中无参数的视图，然后在本地通过dblink调用视图，这样总该先在远程执行出结果传输到本地了吧。
2.1）建立目标端视图

create or replace view v_tab
select c.user_logon,/*工号*/c.user_name,/*姓名*/a.call_id,/*通话id*/
      a.caller_nbr,/*主叫号码*/a.called_nbr,/*被叫号码*/d.start_time,/*呼入时间*/
      b.call_time,/*接听时间*/b.end_time,/*结束时间*/b.call_dura,/*时长*/
      to_number(b.call_time-d.start_time)*24*3600,/*等待时长*/
      decode(c.user_logon,null,0,1),/*类型*/
case
        when substr (a.CALLED_NBR,7, 2) = '00'
          then '广东移动'
        when substr (a.CALLED_NBR,7, 2) = '01'
          then '浙江移动'
        when substr (a.CALLED_NBR,7, 2) = '02'
          then '福建'
        when substr (a.CALLED_NBR,7, 2) = '03'
          then '四川'
        when substr (a.CALLED_NBR,7, 2) = '04'
          then '河南'
        when substr (a.CALLED_NBR,7, 2) = '05'
          then '湖北'
        when substr (a.CALLED_NBR,7, 2) = '06'
          then '北京CSIP'
        when substr (a.CALLED_NBR,7, 2) = '07'
          then '陕西'
        when substr (a.CALLED_NBR,7, 2) = '08'
          then '吉林'
        when substr (a.CALLED_NBR,7, 2) = '09'
          then '江西'
        when substr (a.CALLED_NBR,7, 2) = '10'
          then '宁夏'
        when substr (a.CALLED_NBR,7, 2) = '11'
          then '太原'
        when substr (a.CALLED_NBR,7, 2) = '12'
          then '江苏移动'
        when substr (a.CALLED_NBR,7, 2) = '13'
          then 'e掌管'
        when substr (a.CALLED_NBR,7, 2) = '15'
          then 'e多商'
        when substr (a.CALLED_NBR,7, 2) = '18'
          then '江苏联通'
      end 区域
from cscnew.a a,cscnew.b b,cscnew.c c,cscnew.d d
where a.call_serial=b.call_serial(+)
and b.call_serial=d.call_serial(+)
and b.user_id=c.user_id(+)
and substr(a.CALLED_NBR,1, 6) = '951654'
and  length (a.CALLED_NBR) = 15
and b.fail_reason is null

2.2）本地调用远程视图

INSERT INTO TAB_CS_CALLLOG
select * from v_tab@cs a where
a.end_time>=to_date('20110822000000','yyyymmddhh24miss')
and a.end_time<to_date('20110823000000','yyyymmddhh24miss');

2.3）执行结果2.3S完成数据插入，而且条数也是598条，证明我的猜想是正确的，更重要的是解决了今天这个让人疑惑的问题

1、建立
1.1）emd_maintenance包
exec sysman.emd_maintenance.submit_em_dbms_jobs;
commit;
1.2）创建job

DECLARE
  X NUMBER;
BEGIN
  SYS.DBMS_JOB.SUBMIT
  ( job       => X
   ,what      => 'EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS();'
   ,next_date => to_date('18/08/2011 21:59:17','dd/mm/yyyy hh24:mi:ss')
   ,interval  => 'SYSDATE + 1 / (24 * 60)'
   ,no_parse  => FALSE
  );
  SYS.DBMS_OUTPUT.PUT_LINE('Job Number is: ' || to_char(x));
COMMIT;
END;

2、停止和启动
2.1）停止
EXEC DBMS_JOB.BROKEN(job#,TRUE);
commit;
2.2）启用
EXEC DBMS_JOB.BROKEN(job#,FALSE);
commit;
3、删除
2.1）emd_maintenance包
exec sysman.emd_maintenance.remove_em_dbms_jobs;
commit;
3.2）删除job
dbms_job.remove(job#);
commit;
注：因为EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS是sysman用户下面用于收集em相关信息，如果要进行操作，最好使用sysman用户进行

1、准备测试表

SQL> create table t_d as select * from all_objects;
Table created
SQL> alter table t_d add primary key(object_id);
Table altered
SQL> create table t_d_t as select * from t_d where 1=0;
Table created
SQL> alter table t_d_t add primary key(object_id);
Table altered
SQL> select count(*) from T_D;
  COUNT(*)
----------
     48945
SQL> select count(*) from T_D_T;
  COUNT(*)
----------
     0

2、执行在线同步

SQL> EXEC DBMS_REDEFINITION.CAN_REDEF_TABLE(user, 'T_D', DBMS_REDEFINITION.CONS_USE_PK);
PL/SQL procedure successfully completed
SQL> EXEC DBMS_REDEFINITION.START_REDEF_TABLE(USER, 'T_D', 'T_D_T');
PL/SQL procedure successfully completed
 

3、查询相关物化视图

SQL> select owner,mview_name from user_mviews;
OWNER                          MVIEW_NAME
------------------------------ ------------------------------
CHF                            T_D_T
SQL> select log_owner,master,log_table from user_mview_logs;
LOG_OWNER                      MASTER                         LOG_TABLE
------------------------------ ------------------------------ ------------------------------
CHF                            T_D                            MLOG$_T_D
CREATE MATERIALIZED VIEW T_D_T
ON PREBUILT TABLE
REFRESH FAST ON DEMAND
AS
SELECT "T_D"."OWNER" "OWNER","T_D"."OBJECT_NAME" "OBJECT_NAME",
"T_D"."SUBOBJECT_NAME" "SUBOBJECT_NAME","T_D"."OBJECT_ID" "OBJECT_ID",
"T_D"."DATA_OBJECT_ID" "DATA_OBJECT_ID","T_D"."OBJECT_TYPE" "OBJECT_TYPE",
"T_D"."CREATED" "CREATED","T_D"."LAST_DDL_TIME" "LAST_DDL_TIME",
"T_D"."TIMESTAMP" "TIMESTAMP","T_D"."STATUS" "STATUS",
"T_D"."TEMPORARY" "TEMPORARY","T_D"."GENERATED" "GENERATED",
"T_D"."SECONDARY" "SECONDARY" FROM "CHF"."T_D" "T_D";

4、结束物化视图

SQL> EXEC DBMS_REDEFINITION.FINISH_REDEF_TABLE(USER, 'T_D', 'T_D_T');
PL/SQL procedure successfully completed

5、继续查询相关物化视图

SQL>  select log_owner,master,log_table from user_mview_logs;
SQL> select * from user_mviews;
SQL> select owner,mview_name from user_mviews;
OWNER                          MVIEW_NAME
------------------------------ ------------------------------
SQL> select log_owner,master,log_table from user_mview_logs;
LOG_OWNER                      MASTER                         LOG_TABLE
------------------------------ ------------------------------ ------------------------
SQL> select count(*) from T_D_T;
  COUNT(*)
----------
     48945

6、由试验可以得出
6.1)在线重定义本质就是利用物化视图刷新实现数据迁移
6.2)DBMS_REDEFINITION.START_REDEF_TABLE实现功能：
6.2.1)创建含on prebuilt table的物化视图和物化视图日志
6.2.2)实现通过物化视图刷新当前表中数据进入中间表
6.3)dbms_redefinition.sync_interim_table实现物化视图刷新在执行5.2）操作过程中变化数据
6.4)DBMS_REDEFINITION.FINISH_REDEF_TABLE将锁定原表，防止表上的DML,物化视图执行刷新，完成刷新后，将删除物化视图和对应的日志，将中间表rename成目标表

7、如果表无主键时，区别有
7.1）执行在线定义语句，具体见表在线重定义(无主键)
7.2）创建物化视图语句上

create materialized view T_D_T
on prebuilt table
refresh fast on demand
with rowid
as
select OWNER OWNER,
OBJECT_NAME OBJECT_NAME,
 SUBOBJECT_NAME SUBOBJECT_NAME,
 OBJECT_ID OBJECT_ID,
 DATA_OBJECT_ID DATA_OBJECT_ID,
 OBJECT_TYPE OBJECT_TYPE,
 CREATED CREATED,
 LAST_DDL_TIME LAST_DDL_TIME,
 TIMESTAMP TIMESTAMP,
 STATUS STATUS,
 TEMPORARY TEMPORARY,
 GENERATED GENERATED,
 SECONDARY SECONDARY
 from "CHF"."T_D"   "T_D";

1、创建测试表
SQL> CREATE TABLE t_M
2 AS
3 SELECT * FROM all_objects;
Table created
2、查询测试表中记录
SQL> select count(*) from t_m;
COUNT(*)
———-
48941
3、创建中间表
SQL> create table t_m_n as
2 select * from t_m where 1=0;
Table created
4、查询中间表记录
SQL> select count(*) from t_m_n;
COUNT(*)
———-
5、创建刷新物化视图
SQL> CREATE MATERIALIZED VIEW t_m_n
on prebuilt TABLE WITH REDUCED PRECISION
REFRESH FORCE
ON DEMAND
AS
SELECT * FROM t_m;
Materialized view created
6、执行物化视图刷新
SQL> exec dbms_mview.refresh(‘T_M_N’);
PL/SQL procedure successfully completed
7、查询物化视图中记录数
SQL> select count(*) from t_m_n;
COUNT(*)
———-
48941
8、删除物化视图
SQL> DROP MATERIALIZED VIEW T_M_N;
Materialized view dropped
9、查询中间表中条数
SQL> select count(*) from t_m_n;
COUNT(*)
———-
48941
10、后续可能操作
1）t_m和t_m_n相互重命名，实现在线修移动表的位置、改表结构、降低高水位等操作，同（shrink）
2）和dblink结合，实现数据的跨版本迁移

1、T2表结构

SQL> desc t2
Name           Type          Nullable Default Comments
-------------- ------------- -------- ------- --------
OWNER          VARCHAR2(30)  Y
OBJECT_NAME    VARCHAR2(128) Y
SUBOBJECT_NAME VARCHAR2(30)  Y
OBJECT_ID      NUMBER        Y
DATA_OBJECT_ID NUMBER        Y
OBJECT_TYPE    VARCHAR2(19)  Y
CREATED        DATE          Y
LAST_DDL_TIME  DATE          Y
TIMESTAMP      VARCHAR2(19)  Y
STATUS         VARCHAR2(7)   Y
TEMPORARY      VARCHAR2(1)   Y
GENERATED      VARCHAR2(1)   Y
SECONDARY      VARCHAR2(1)   Y

2、创建中间表

CREATE TABLE T2_1
AS
SELECT * FROM t2 WHERE 1=0;

3、验证T2是否用于重定义（因没有主键，采用rowid实现）

EXEC DBMS_REDEFINITION.CAN_REDEF_TABLE(user, 'T2', DBMS_REDEFINITION.cons_use_rowid);

4、执行表的在线重定义

EXEC DBMS_REDEFINITION.START_REDEF_TABLE(USER, 'T2', 'T2_1','OWNER OWNER, OBJECT_NAME OBJECT_NAME, SUBOBJECT_NAME  SUBOBJECT_NAME, OBJECT_ID OBJECT_ID, DATA_OBJECT_ID DATA_OBJECT_ID, OBJECT_TYPE OBJECT_TYPE, CREATED CREATED, LAST_DDL_TIME LAST_DDL_TIME, TIMESTAMP TIMESTAMP, STATUS STATUS, TEMPORARY TEMPORARY, GENERATED GENERATED, SECONDARY SECONDARY',DBMS_REDEFINITION.cons_use_rowid);

说明：
1）采用单引号列出T2与T2_1表列的对应关系
2）列与列之间采用单引号分割，单引号后面要有空格
5、同步数据（可选）

exec dbms_redefinition.sync_interim_table(user, 'T2', 'T2_1');

6、执行结束在线定义过程

EXEC DBMS_REDEFINITION.FINISH_REDEF_TABLE(user, 'T2', 'T2_1');

7、删除中间表

drop table t2_1 purge;

8、处理T2表（删除隐藏列）

SQL> select col#,name,type# from SYS.COL$ WHERE OBJ#=(select object_id from dba_objects where object_name='T2');
      COL# NAME                                TYPE#
---------- ------------------------------ ----------
         1 OWNER                                   1
         2 OBJECT_NAME                             1
         3 SUBOBJECT_NAME                          1
         4 OBJECT_ID                               2
         5 DATA_OBJECT_ID                          2
         6 OBJECT_TYPE                             1
         7 CREATED                                12
         8 LAST_DDL_TIME                          12
         9 TIMESTAMP                               1
        10 STATUS                                  1
        11 TEMPORARY                               1
        12 GENERATED                               1
        13 SECONDARY                               1
         0 SYS_C00014_11081015:39:40$              1
--发现一个多余隐藏列SYS_C00014_11081015:39:40$，我们需要删除
SQL>  alter table t2 set unused ("SYS_C00014_11081015:39:40$");
Table altered
SQL>  alter table t2 drop unused columns;
Table altered

表在线重定义（有主键）

1、现象
Mon Aug 8 08:16:07 2011
The value (30) of MAXTRANS parameter ignored.
kupprdp: master process DM00 started with pid=91, OS id=21125
to execute – SYS.KUPM$MCP.MAIN(‘SYS_EXPORT_TABLE_01’, ‘YDZJ’, ‘KUPC$C_1_20110808081609’, ‘KUPC$S_1_20110808081609’, 0);
kupprdp: worker process DW01 started with worker id=1, pid=57, OS id=21127
to execute – SYS.KUPW$WORKER.MAIN(‘SYS_EXPORT_TABLE_01’, ‘YDZJ’);
kupprdp: worker process DW02 started with worker id=2, pid=95, OS id=21502
to execute – SYS.KUPW$WORKER.MAIN(‘SYS_EXPORT_TABLE_01’, ‘YDZJ’);
2、原因
这个时间段正在使用expdp进行数据库导出，当然从错误描述也可以看出和导出操作有关，不过当时导出是成功，没有报任何错误。 在metalink查询 ，发现这是Version: 10.1.0.2 to 11.1.0.7 (任何平台) 的一个bug，Bug号为：6347775
这是由于在创建备份主表时使用了如下语句：
CREATE TABLE table_name (columns_list) INITRANS 10 MAXTRANS 30
而Maxtrans参数在10gR1时已经废弃，所以在告警日志中就提示：
The value (30) of MAXTRANS parameter ignored. ， 此bug没有什么影响，所以可以忽略。
3、重现
SQL> create table xff(xifenfei varchar2(100)) initrans 10 maxtrans 20;
Table created.
查看alert日志
Mon Aug 8 16:11:28 2011
The value (20) of MAXTRANS parameter ignored.