监控Index注意事项

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:监控Index注意事项

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

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与Oracle数据库恢复的关系

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:SCN与Oracle数据库恢复的关系

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

一、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问题解决

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:诡异dblink问题解决

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

一、诡异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条,证明我的猜想是正确的,更重要的是解决了今天这个让人疑惑的问题

EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS维护

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS维护

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

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用户进行

在线重定义原理探讨

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:在线重定义原理探讨

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

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

利用物化视图刷数据

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:利用物化视图刷数据

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

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结合,实现数据的跨版本迁移

表在线重定义(无主键)

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:表在线重定义(无主键)

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

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

表在线重定义(有主键)

The value (30) of MAXTRANS parameter ignored

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:The value (30) of MAXTRANS parameter ignored

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

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.

Oracle数据文件大小的限制

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:Oracle数据文件大小的限制

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

如果你比较细心,会注意到两件事情:
1、添加一个32g的数据文件会报错
SQL> alter tablespace users add datafile ‘/opt/oracle/oradata/test/user32g.dbf’ size 32g;
alter tablespace users add datafile ‘/opt/oracle/oradata/test/user32g.dbf’ size 32g
*
ERROR at line 1:
ORA-01144: File size (4194304 blocks) exceeds maximum of 4194303 blocks
SQL> !oerr ora 1144
01144, 00000, “File size (%s blocks) exceeds maximum of %s blocks”
// *Cause: Specified file size is larger than maximum allowable size value.
// *Action: Specify a smaller size.
2、添加一个maxsize为unlimited的数据文件
SQL> alter tablespace users add datafile ‘/opt/oracle/oradata/test/user32g.dbf’ size 10M AUTOEXTEND ON maxsize unlimited;
Tablespace altered.
SQL> select MAXBYTES/1024/1024/1024 from dba_data_files where file_name=’/opt/oracle/oradata/test/user32g.dbf’;
MAXBYTES/1024/1024/1024
———————–
31.9999847
你是不是有疑惑,为什么我添加32g的数据文件报错,为什么我添加一个数据文件maxsize设置为unlimited了,还是没有突破32g这个坎
原因分析:
由于Oracle的Rowid中使用22位来代表Block号,这22位最多只能代表2^22-1(4194303)个数据块,而在我们一般情况下使用的数据块大小为8k,所以数据文件的理论大小最大为: 31.9999924G
至于maxsize为unlimited时候,数据文件的大小为什么只有31.9999847G(blocks:4194301.99),比最大块数(4194303)少了一块,也许是和数据库和系统之间的衔接原因导致。
由上面的分析我们可以知道,数据文件大小和db_block_size有关,那我们可以得到这样的数据文件最大理论值

数据块 数据文件
2KB 8GB
4KB 16GB
8KB 32GB
16KB 64GB
32KB 128GB

注:以上规则适用于smallfile tablespace 下的数据文件,bigfile tablespace 下的数据文件不受此限制

performing DML/DDL operation over object in bin错误模拟

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:performing DML/DDL operation over object in bin错误模拟

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

1、alert文件中现象
Thu Jul 21 09:49:38 2011
performing DML/DDL operation over object in bin.
Thu Jul 21 09:51:02 2011
performing DML/DDL operation over object in bin.
2、开始模拟
1)确认回收站功能启用
SQL> show parameter recyclebin;
NAME TYPE VALUE
———————————— ———– ——————————
recyclebin string ON
如果是OFF,使用alter system set recyclebin=on;开启回收站功能
2)创建和删除表
SQL> create table t_drop
2 as
3 select * from tab;
Table created.
SQL> drop table t_drop;
Table dropped.
SQL> show recyclebin;
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
—————- —————————— ———— ——————-
T_DROP BIN$qIuF4JHvDJDgQKjADAsarA==$0 TABLE 2011-07-21:09:46:52
3)查看回收站表中数据
SQL> select * from “BIN$qIuF4JHvDJDgQKjADAsarA==$0”;
TNAME TABTYPE CLUSTERID
—————————— ——- ———-
T TABLE
TAB_CRM_CLIENT TABLE
TEST_COUNT TABLE
V_TEST VIEW
TEST TABLE
T_DROP TABLE
TAB_OLCM TABLE
7 rows selected.
4)对回收站中数据进行dml操作
SQL> delete from “BIN$qIuF4JHvDJDgQKjADAsarA==$0”;
delete from “BIN$qIuF4JHvDJDgQKjADAsarA==$0”
*
ERROR at line 1:
ORA-38301: can not perform DDL/DML over objects in Recycle Bin
5)对回收站中数据进行ddl操作
SQL> drop table “BIN$qIuF4JHvDJDgQKjADAsarA==$0”;
drop table “BIN$qIuF4JHvDJDgQKjADAsarA==$0”
*
ERROR at line 1:
ORA-38301: can not perform DDL/DML over objects in Recycle Bin
6)查看回收站,错误重现
Thu Jul 21 09:56:44 2011
performing DML/DDL operation over object in bin.
Thu Jul 21 09:57:19 2011
performing DML/DDL operation over object in bin.
7)说明
由于对回收站中的对象执行了dml或者ddl操作导致alert报类此做。在回收站中不能执行ddl或者dml操作