关于DBMS_SCHEDULER基础

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

标题:关于DBMS_SCHEDULER基础

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

长期以来,一直对DBMS_SCHEDULER包比较模糊,今天抽一点时间,通过一点试验,理清自己的思路,分清楚各个函数大概作用.不至于在以后使用该包的时候一片空白.
1.通过DBMS_SCHEDULER.CREATE_JOB直接创建job

SQL> create table t_xifenfei (x_type varchar2(10),x_date date);
表已创建。
SQL> begin
  2  DBMS_SCHEDULER.create_job (
  3  job_name => 'f_create_job',
  4  job_type => 'PLSQL_BLOCK',
  5  job_action => '
  6   begin
  7   insert into t_xifenfei values(''job'',sysdate);
  8   commit;
  9   end;
 10  ',
 11  enabled => true,
 12  start_date => SYSTIMESTAMP,
 13  repeat_interval => 'SYSTIMESTAMP + 1/1440',
 14  comments => 'xifenfei_create_job');
 15  END;
 16  /
SQL> select x_type,to_char(x_date,'yyyy-mm-dd hh24:mi:ss') from t_xifenfei;
X_TYPE     TO_CHAR(X_DATE,'YYY
---------- -------------------
job        2012-06-19 19:52:11
job        2012-06-19 19:53:11
job        2012-06-19 19:54:11

这里的使用方法和dbms_jobs有几分类此,不过这个提供了加灵活的使用方法,比如可以执行匿名块,执行操作系统命令等

2.CREATE_JOB结合CREATE_PROGRAM

SQL>  create or replace procedure p_xifenfei(in_type in varchar2)
  2   is
  3   begin
  4   insert into t_xifenfei values(in_type,sysdate);
  5   commit;
  6   end;
  7   /
过程已创建。
SQL> begin
  2  DBMS_SCHEDULER.CREATE_PROGRAM(
  3  program_name => 'x_program',
  4  program_action => 'p_xifenfei',
  5  program_type => 'STORED_PROCEDURE',
  6  number_of_arguments => 1,
  7  comments => 'xifenfei_PROGRAM',
  8  enabled => false);
  9  end;
 10  /
PL/SQL 过程已成功完成。
SQL> begin
  2  DBMS_SCHEDULER.define_program_argument(
  3  program_name => 'x_program',
  4  argument_position => 1,
  5  argument_type => 'VARCHAR2',
  6  default_value => 'program');
  7  END;
  8  /
PL/SQL 过程已成功完成。
SQL>  exec DBMS_SCHEDULER.enable('x_program');
PL/SQL 过程已成功完成。
SQL> begin
  2  DBMS_SCHEDULER.create_job(
  3  job_name => 's_xifenfei_job',
  4  program_name => 'x_program',
  5  comments => 's_xifenfei_job',
  6  repeat_interval => 'SYSTIMESTAMP + 1/1440',
  7  auto_drop => false,
  8  enabled => true);
  9  end;
 10  /
PL/SQL 过程已成功完成。
SQL> select x_type,to_char(x_date,'yyyy-mm-dd hh24:mi:ss') from t_xifenfei;
X_TYPE     TO_CHAR(X_DATE,'YYY
---------- -------------------
job        2012-06-19 20:27:11
program    2012-06-19 20:27:09
program    2012-06-19 20:28:09
job        2012-06-19 20:28:11

这里可以看出来CREATE_PROGRAM是把CREATE_JOB中的部分参数给独立出来,使得更加灵活的控制,比如这里的使用从参数

3.CREATE_JOB结合CREATE_PROGRAM和CREATE_SCHEDULE

SQL> exec DBMS_SCHEDULER.drop_job('s_xifenfei_job');
PL/SQL 过程已成功完成。
SQL> truncate table t_xifenfei;
表被截断。
SQL> begin
  2  DBMS_SCHEDULER.create_schedule(
  3  repeat_interval => 'FREQ=MINUTELY;INTERVAL=1',
  4  start_date => sysdate,
  5  comments => 'xifenfei_sch',
  6  schedule_name => 'X_SCH');
  7  end;
  8  /
PL/SQL 过程已成功完成。
SQL> begin
  2  DBMS_SCHEDULER.create_job(
  3  job_name => 't_xifenfei_job',
  4  program_name => 'x_program',
  5  comments => 't_xifenfei_job',
  6  schedule_name => 'X_SCH',
  7  auto_drop => false,
  8  enabled => true);
  9  end;
 10  /
PL/SQL 过程已成功完成。
SQL> select x_type,to_char(x_date,'yyyy-mm-dd hh24:mi:ss') from t_xifenfei;
X_TYPE     TO_CHAR(X_DATE,'YYY
---------- -------------------
job        2012-06-19 20:39:11
job        2012-06-19 20:37:11
job        2012-06-19 20:38:11
program    2012-06-19 20:39:01
program    2012-06-19 20:40:01

CREATE_SCHEDULE是把执行计划部分从CREATE_JOB独立处理,使得控制力度更大,更加灵活

补充说明:
1.还可以通过创建JOB_CLASS更加灵活的控制资源的使用情况,必须通过修改JOB_CLASS中的resource_consumer_group实现资源控制,service对应到数据库的service可以实现rac中在哪个节点执行等等
2.使用DBMS_SCHEDULER.set_attribute来修改相关属相如:

EXEC DBMS_SCHEDULER.set_attribute('GATHER_STATS_JOB','JOB_CLASS', 'AUTO_TASKS_JOB_CLASS2');
exec dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','REPEAT_INTERVAL','freq=daily;
byday=MON,TUE,WED,THU,FRI;byhour=2;byminute=0;bysecond=0');

ORACLE在线切换undo表空间

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

标题:ORACLE在线切换undo表空间

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

切换undo的一些步骤和基本原则

查看原undo相关参数
SHOW PARAMETER UNDO;
创建新undo空间
create undo tablespace undo_x datafile 'E:\ORACLE\ORADATA\XIFENFEI\undo_xifenfei.dbf' size 10M
autoextend on next 10M maxsize 30G;
查询历史undo是否还有事务(包含回滚事务)
SELECT a.tablespace_name,a.segment_name,b.ktuxesta,b.ktuxecfl,
b.ktuxeusn||'.'||b.ktuxeslt||'.'||b.ktuxesqn trans
FROM dba_rollback_segs a, x$ktuxe b
WHERE a.segment_id = b.ktuxeusn
AND a.tablespace_name = UPPER('&tsname')
AND b.ktuxesta <> 'INACTIVE';
--因为有undo_retention参数,所以不能简单的通过确定该sql无事务就可以删除原undo
切换undo表空间(无论是否有事务,均可以切换[最好是无事务时切换],但是不能直接删除原undo表空间)
alter system set undo_tablespace='undo_x';
alert日志现象,表明原undo还有事务
Sun Jun 17 20:10:45 2012
Successfully onlined Undo Tablespace 7.
[36428] **** active transactions found in undo Tablespace 2 - moved to Pending Switch-Out state.
[36428] active transactions found/affinity dissolution incompletein undo tablespace 2 during switch-out.
ALTER SYSTEM SET undo_tablespace='undo_xifenfei' SCOPE=BOTH;
Sun Jun 17 20:11:38 2012
[36312] **** active transactions found in undo Tablespace 2 - moved to Pending Switch-Out state.
Sun Jun 17 20:16:15 2012
[36312] **** active transactions found in undo Tablespace 2 - moved to Pending Switch-Out state.
--只能表明有事务,就算长时间未出现类似记录,不能证明一定可以删除原undo,因为undo_retention
查询回滚段情况(原undo表空间的回滚段全部offline,可以删除相关表空间)
select tablespace_name,segment_name,status from dba_rollback_segs;
离线原undo表空间
alter tablespace undotbs1 offline;
确定原undo回滚段全部offline,直接删除
drop tablespace undotbs1 including contents and datafiles;

切换undo表空间一句话:新建undo几乎是任何时候都可以执行切换undo表空间命令,如果要删除历史undo需要等到该undo空间所有回滚段全部offline.千万别在尚有回滚段处于online状态,强制删除数据文件.

利用flashback database实现部分对象回滚

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

标题:利用flashback database实现部分对象回滚

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

flashback database功能在生产库中,很少被直接使用,因为没有多少业务可以承受整个数据库级别的回滚.但是如果发生一些让人意想不到的误操作时候,想回滚该操作,我们不得不使用历史的备份来进行不完全恢复.如果没有历史备份,那简直是人生一个悲剧的发生.这里通过使用结合flashback database,实现flashback table级别不能完成的恢复,而且确保整个数据库的其他数据还是最新.这些操作比如:修改表结构,删除数据库用户等操作.这里通过修改表列的处理思路来展示该功能的使用方法,其他处理方法类此
1.确定启用flashback database功能

SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
YES
SQL>  show parameter flash
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_flash_cache_file                  string
db_flash_cache_size                  big integer 0
db_flashback_retention_target        integer     1440

2.模拟表结构被修改

SQL> create table t_xifenfei
  2  as
  3  select object_id,object_name from dba_objects;
表已创建。
SQL> alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS';
会话已更改。
SQL>  select sysdate from dual;
SYSDATE
-------------------------
17-6月 -2012 15:25:24
SQL> ALTER TABLE t_xifenfei drop column object_name;
表已更改。

3.尝试flashback query功能

SQL> SELECT * FROM t_xifenfei as of timestamp to_timestamp('2012-06-17 15:25:24','yyyy-mm-dd hh24:mi:ss');
SELECT * FROM t_xifenfei as of timestamp to_timestamp('2012-06-17 15:25:24','yyyy-mm-dd hh24:mi:ss')
              *
第 1 行出现错误:
ORA-01466: 无法读取数据 - 表定义已更改
--这个证明因为ddl操作发生在表上,无法使用flashback table/query等操作

4.尝试flashback database

SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> STARTUP MOUNT;
ORACLE 例程已经启动。
Total System Global Area  535662592 bytes
Fixed Size                  1385840 bytes
Variable Size             390072976 bytes
Database Buffers          138412032 bytes
Redo Buffers                5791744 bytes
数据库装载完毕。
SQL>  flashback database to timestamp to_date('2012-06-17 15:25:24','yyyy-mm-ddhh24:mi:ss');
闪回完成。
SQL> alter database open read only;
数据库已更改。
SQL> DESC CHF.T_XIFENFEI
 名称                                      是否为空? 类型
 ----------------------------------------- -------- ----------------------------
 OBJECT_ID                                          NUMBER
 OBJECT_NAME                                        VARCHAR2(128)

5.导出需要回滚对象

C:\Users\XIFENFEI>EXP chf/xifenfei tables=t_xifenfei file=d:\t_xifenfei.dmp
>log=d:\t_xifenfei.log
Export: Release 11.2.0.3.0 - Production on 星期日 6月 17 15:40:37 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
已导出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集
即将导出指定的表通过常规路径...
. . 正在导出表                      T_XIFENFEI导出了       75270 行
成功终止导出, 没有出现警告。

6.恢复数据库至最新状态

SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL>  startup mount
ORACLE 例程已经启动。
Total System Global Area  535662592 bytes
Fixed Size                  1385840 bytes
Variable Size             390072976 bytes
Database Buffers          138412032 bytes
Redo Buffers                5791744 bytes
数据库装载完毕。
SQL> recover database;
完成介质恢复。
SQL> alter database open;
数据库已更改。
SQL> desc chf.t_xifenfei
 名称                                      是否为空? 类型
 ----------------------------------------- -------- ----------------------------
 OBJECT_ID                                          NUMBER

7.导入正确数据

SQL> drop table chf.t_xifenfei purge;
表已删除。
SQL> host imp chf/xifenfei tables=t_xifenfei file=d:\t_xifenfei.dmp
>log=d:\t_xifenfei.log
Import: Release 11.2.0.3.0 - Production on 星期日 6月 17 15:45:53 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
经由常规路径由 EXPORT:V11.02.00 创建的导出文件
已经完成 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集中的导入
. 正在将 CHF 的对象导入到 CHF
. 正在将 CHF 的对象导入到 CHF
. . 正在导入表                    "T_XIFENFEI"导入了       75270 行
成功终止导入, 没有出现警告。
SQL> desc chf.t_xifenfei
 名称                                      是否为空? 类型
 ----------------------------------------- -------- ----------------------------
 OBJECT_ID                                          NUMBER
 OBJECT_NAME                                        VARCHAR2(128)

OPTIMIZER_INDEX_CACHING和OPTIMIZER_INDEX_COST_ADJ参数说明

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

标题:OPTIMIZER_INDEX_CACHING和OPTIMIZER_INDEX_COST_ADJ参数说明

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

OPTIMIZER_INDEX_COST_ADJ参数说明
OPTIMIZER_INDEX_COST_ADJ lets you tune optimizer behavior for access path selection to be more or less index friendly—that is, to make the optimizer more or less prone to selecting an index access path over a full table scan.
The default for this parameter is 100 percent, at which the optimizer evaluates index access paths at the regular cost. Any other value makes the optimizer evaluate the access path at that percentage of the regular cost. For example, a setting of 50 makes the index access path look half as expensive as normal.
这个数反映执行多块IO(全表扫描)的成本与执行单个IO(索引读取)的成本。保持为100,则多块IO与单块IO成本相同。设为50优化程序认为访问单块IO的成本为多块IO的一半。

OPTIMIZER_INDEX_COST_ADJ参数试验

SQL> create table t_xifenfei
  2  as
  3   select object_id,object_name from dba_objects where rownum<101;
Table created.
SQL> create index ind_t_xifenfei on t_xifenfei(object_id);
Index created.
SQL> EXEC DBMS_STATS.gather_table_stats(user,'T_XIFENFEI',CASCADE=>TRUE);
PL/SQL procedure successfully completed.
SQL>  show parameter OPTIMIZER_INDEX;
NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
optimizer_index_caching              integer                0
optimizer_index_cost_adj             integer                100
SQL> set linesize 150
SQL> set autot trace ext
SQL> select object_name from t_xifenfei where object_id>100;
Execution Plan
----------------------------------------------------------
Plan hash value: 2444553208
----------------------------------------------------------------------------------------------
| Id  | Operation                   | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                |     1 |    11 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T_XIFENFEI     |     1 |    11 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IND_T_XIFENFEI |     1 |       |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("OBJECT_ID">100)
SQL> alter session set OPTIMIZER_INDEX_COST_ADJ=1000;
Session altered.
SQL> select object_name from t_xifenfei where object_id>100;
Execution Plan
----------------------------------------------------------
Plan hash value: 548923532
--------------------------------------------------------------------------------
| Id  | Operation         | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |            |     1 |    11 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T_XIFENFEI |     1 |    11 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("OBJECT_ID">100)

通过试验证明修改OPTIMIZER_INDEX_COST_ADJ会导致执行计划走index还是全表扫描

OPTIMIZER_INDEX_CACHING参数说明
OPTIMIZER_INDEX_CACHING lets you adjust the behavior of cost-based optimization to favor nested loops joins and IN-list iterators.The cost of executing an index using an IN-list iterator or of executing a nested loops join when an index is used to access the inner table depends on the caching of that index in the buffer cache. The amount of caching depends on factors that the optimizer cannot predict, such as the load on the system and the block access patterns of different users.You can modify the optimizer’s assumptions about index caching for nested loops joins and IN-list iterators by setting this parameter to a value between 0 and 100 to indicate the percentage of the index blocks the optimizer should assume are in the cache. Setting this parameter to a higher value makes nested loops joins and IN-list iterators look less expensive to the optimizer. As a result, it will be more likely to pick nested loops joins over hash or sort-merge joins and to pick indexes using IN-list iterators over other indexes or full table scans. The default for this parameter is 0, which results in default optimizer behavior.
这个表明的是在nested loops joins and IN-list iterators的时候,如果使用了OPTIMIZER_INDEX_CACHING参数,表明两个表关联的时候优化器考虑index cache的比例,从而选择不同的执行计划.而不是网上所说的优化器考虑所有情况下的index的cache情况(这个参数只有在nested loops joins and IN-list iterators表关联的时候的index才会被优化器考虑[index cache的比例]).进一步说明:这个参数影响两个表关联的时候是选择hash jion还是nested loops joins/sort-merge joins

总结说明
1.关于OPTIMIZER_INDEX_CACHING的参数效果我未试验出来(可能方法不正确)
2.根据网上建议在oltp系统中设置
optimizer_index_caching = 0 optimizer_index_cost_adj = 100 的默认值,一般时候数据仓库报表系统。
optimizer_index_caching = 90 optimizer_index_cost_adj = 25-50 一般时候事务处理/OLTP系统
3.设置这些参数可能存在bug

autotrace显示Statistics很多信息为0

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

标题:autotrace显示Statistics很多信息为0

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

一朋友使用autotrace查看数据库执行计划发现结果如下,Statistics中很多信息为0,这个肯定是不正常现象,什么都可以为0,consistent gets也不可能为0.

SQL> set autot on
SQL> select count(*) from RACV_DATA.PARTY_DUMMY;
  COUNT(*)
----------
        47
Elapsed: 00:00:00.00
Execution Plan
----------------------------------------------------------
Plan hash value: 3621440939
--------------------------------------------------------------------------
| Id  | Operation          | Name        | Rows  | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |             |     1 |     3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |             |     1 |            |          |
|   2 |   TABLE ACCESS FULL| PARTY_DUMMY |    47 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
          0  bytes sent via SQL*Net to client
          0  bytes received via SQL*Net from client
          0  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

解决方法

SQL>  select owner,object_name from dba_objects where object_name='PLAN_TABLE';
no rows selected
SQL> @?/rdbms/admin/utlxplan.sql
Table created.

重新查看Statistics信息

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          7  consistent gets
          0  physical reads
          0  redo size
        522  bytes sent via SQL*Net to client
        524  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

DEFERRED_SEGMENT_CREATION 参数相关说明

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

标题:DEFERRED_SEGMENT_CREATION 参数相关说明

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

DEFERRED_SEGMENT_CREATION specifies the semantics of deferred segment creation. If set to true, then segments for tables and their dependent objects (LOBs, indexes) will not be created until the first row is inserted into the table.
这句话的意思是 DEFERRED_SEGMENT_CREATION 参数的作用是:创建表的时候延迟创建这个表相关的segment(包括lobs,indexes),直到第一次插入数据的时候才创建segment.补充说明:DEFERRED_SEGMENT_CREATION 参数从11.2.0.1引进,默认值为true;如果要使其恢复老版本功能,设置该参数为false.

DEFERRED_SEGMENT_CREATION默认值

SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') "WWW.XIFENFEI.COM" FROM DUAL;
WWW.XIFENFEI.COM
--------------------------------------
2012-06-01 05:31:03
SQL> show parameter DEFERRED_SEGMENT_CREATION;
NAME                                 TYPE       VALUE
------------------------------------ ---------- --------
deferred_segment_creation            boolean    TRUE

DEFERRED_SEGMENT_CREATION效果验证

SQL> create table t_xifenfei (id number,name varchar2(30));
Table created.
SQL> create index ind_t_xifenfei on t_xifenfei(id);
Index created.
SQL> select segment_name,segment_type from dba_segments where
  2   segment_name in('T_XIFENFEI','IND_T_XIFENFEI') AND OWNER='CHF';
no rows selected
--未创建segment
SQL> INSERT INTO T_XIFENFEI VALUES(1,'WWW.XIFENFEI.COM');
1 row created.
SQL> commit;
Commit complete.
SQL> select segment_name,segment_type from dba_segments where
  2  segment_name in('T_XIFENFEI','IND_T_XIFENFEI') AND OWNER='CHF';
SEGMENT_NAME         SEGMENT_TYPE
-------------------- ------------------------------------
IND_T_XIFENFEI       INDEX
T_XIFENFEI           TABLE
--创建segment
SQL> alter session set deferred_segment_creation=false;
Session altered.
SQL> create table t_xifenfei_2 (id number,name varchar2(30));
Table created.
SQL> select segment_name,segment_type from dba_segments where segment_name='T_XIFENFEI_2';
SEGMENT_NAME         SEGMENT_TYPE
-------------------- ------------------------------------
T_XIFENFEI_2         TABLE
--创建segment

问题1(朋友疑惑为什么它没有给相关表空间分配配额但是创建表成功)

SQL> create user xifenfei identified by xifenfei default tablespace users;
User created.
SQL> grant connect,resource to xifenfei;
Grant succeeded.
SQL> revoke unlimited tablespace from xifenfei;
Revoke succeeded.
SQL> alter user xifenfei quota unlimited on users;
User altered.
SQL> conn xifenfei/xifenfei
Connected.
SQL> create table t_xifenfei (id number,name varchar2(30)) tablespace system;
Table created.
--在system表空间无配额,但是创建表成功
SQL> insert into t_xifenfei values(1,'www.xifenfei.com');
insert into t_xifenfei values(1,'www.xifenfei.com')
            *
ERROR at line 1:
ORA-01950: no privileges on tablespace 'SYSTEM'
--插入数据库失败,因为在system上创建segment失败
SQL> alter session set deferred_segment_creation=false;
Session altered.
SQL> create table t_xifenfei_2 (id number,name varchar2(30)) tablespace system;
create table t_xifenfei_2 (id number,name varchar2(30)) tablespace system
*
ERROR at line 1:
ORA-01950: no privileges on tablespace 'SYSTEM'
--deferred_segment_creation设置为false后,创建表直接失败

问题2(exp未导segment不存在表)
该问题帮朋友解决过.因为暂时无11.2.0.1版本数据库,直接摘录MOS

In 11.2 the deferred storage segment feature is enabled by default.
Conventional export (exp) silently skips tables with deferred segment
creation if no segment has yet been created. ie: If the table does
not yet contain any rows. In some cases "exp" will report EXP-11 for
the table.
eg:
 create table t(c1 int) tablespace sysaux;
 select segment_created from user_tables where table_name='T';
  SEG
  ---
  NO
 Table level export:
   exp scott/tiger file=/tmp/scott.dmp tables=t
   ^
   EXP-11 SCOTT.T does not exist
 Schema level export:
   exp scott/tiger file=/tmp/scott.dmp owner=scott statistics=none
   ^
   Export completes successfully but silently does not export
   table "T".
Rediscovery Notes:
  Tables that may be affected by this can be found thus:
    select owner, table_name from dba_tables
     where segment_created='NO';
  EXP-11 on export for tables with no data.
  Tables missing after exp/imp
Workaround
  Re-create the missing table at the export site from DDL.
  (the table did not contain rows otherwise it would have
   had a segment created for it)
In 11.2 the deferred storage segment feature is enabled by default.
Conventional export (exp) silently skips tables with deferred segment
creation if no segment has yet been created. ie: If the table does
not yet contain any rows. In some cases "exp" will report EXP-11 for
the table.
eg:
 create table t(c1 int) tablespace sysaux;
 select segment_created from user_tables where table_name='T';
  SEG
  ---
  NO
 Table level export:
   exp scott/tiger file=/tmp/scott.dmp tables=t
   ^
   EXP-11 SCOTT.T does not exist
 Schema level export:
   exp scott/tiger file=/tmp/scott.dmp owner=scott statistics=none
   ^
   Export completes successfully but silently does not export
   table "T".
Rediscovery Notes:
  Tables that may be affected by this can be found thus:
    select owner, table_name from dba_tables
     where segment_created='NO';
  EXP-11 on export for tables with no data.
  Tables missing after exp/imp
Workaround
  Re-create the missing table at the export site from DDL.
  (the table did not contain rows otherwise it would have
   had a segment created for it)
This issue is fixed in
•12.1 (Future Release)
•11.2.0.2 (Server Patch Set)

找出dbv相关dba值在数据文件中对应位置

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

标题:找出dbv相关dba值在数据文件中对应位置

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

一个朋友数据库因异常断电,数据库不能正常启动,使用dbv检测错误如下:

C:\Users\XIFENFEI\Downloads>dbv file=users01.dbf end=5
DBVERIFY: Release 11.2.0.3.0 - Production on 星期二 6月 5 18:17:27 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
DBVERIFY - 开始验证: FILE = C:\USERS\XIFENFEI\DOWNLOADS\USERS01.DBF
页 1 标记为损坏
Corrupt block relative dba: 0x00000001 (file 0, block 1)
Bad header found during dbv:
Data in bad block:
 type: 11 format: 2 rdba: 0x00000000
 last change scn: 0x0000.00000000 seq: 0x1 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x00000b01
 check value in block header: 0x2f1f
 computed block checksum: 0x0
页 2 标记为损坏
Corrupt block relative dba: 0x00000002 (file 0, block 2)
Bad header found during dbv:
Data in bad block:
 type: 29 format: 2 rdba: 0x01000002
 last change scn: 0x0000.0018c7fa seq: 0x2 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xc7fa1d02
 check value in block header: 0x82ca
 computed block checksum: 0x0
页 3 标记为损坏
Corrupt block relative dba: 0x00000003 (file 0, block 3)
Bad header found during dbv:
Data in bad block:
 type: 30 format: 2 rdba: 0x01000003
 last change scn: 0x0000.0018c7fa seq: 0x1 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xc7fa1e01
 check value in block header: 0x32c9
 computed block checksum: 0x0
页 4 标记为损坏
Corrupt block relative dba: 0x00000004 (file 0, block 4)
Bad header found during dbv:
Data in bad block:
 type: 30 format: 2 rdba: 0x01000004
 last change scn: 0x0000.00004adc seq: 0x1 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x4adc1e01
 check value in block header: 0x8199
 computed block checksum: 0x0
页 5 标记为损坏
Corrupt block relative dba: 0x00000005 (file 0, block 5)
Bad header found during dbv:
Data in bad block:
 type: 30 format: 2 rdba: 0x01000005
 last change scn: 0x0000.00004ade seq: 0x1 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x4ade1e01
 check value in block header: 0xc190
 computed block checksum: 0x0
DBVERIFY - 验证完成
检查的页总数: 5
处理的页总数 (数据): 0
失败的页总数 (数据): 0
处理的页总数 (索引): 0
失败的页总数 (索引): 0
处理的页总数 (其他): 0
处理的总页数 (段)  : 0
失败的总页数 (段)  : 0
空的页总数: 0
标记为损坏的总页数: 5
流入的页总数: 0
加密的总页数        : 0
最高块 SCN            : 0 (0.0)

对于这样的错误,特别是Corrupt block relative dba出现奇怪的提示(file 0),我第一反应就是数据文件header出现了问题.在eygle的耐心帮忙和提示下,使用bbed重现了该错误,并且找出了dbv中两个dba(Corrupt block relative dba和rdba)和bbed中相对应的值.通过实验重现相关结果.

dbv检查无坏块

[oracle@xifenfei tmp]$ dbv file=/u01/oracle/oradata/ora11g/xifenfei02.dbf blocksize=8192
DBVERIFY: Release 11.2.0.3.0 - Production on Fri Jun 1 03:34:46 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/oracle/oradata/ora11g/xifenfei02.dbf
Block Checking: DBA = 25179275, Block Type = KTB-managed data block
data header at 0xb526707c
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=3
Page 13451 failed with check code 6101
Block Checking: DBA = 25179287, Block Type = KTB-managed data block
data header at 0xb527f064
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 13463 failed with check code 6101
DBVERIFY - Verification complete
Total Pages Examined         : 15360
Total Pages Processed (Data) : 12932
Total Pages Failing   (Data) : 2
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 291
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 2137
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 1551567 (0.1551567)

修改数据块rdba_kcbh

BBED> set block 150
        BLOCK#          150
BBED> map
 File: /u01/oracle/oradata/ora11g/xifenfei02.dbf (1)
 Block: 150                                   Dba:0x00400096
------------------------------------------------------------
 KTB Data Block (Table/Cluster)
 struct kcbh, 20 bytes                      @0
 struct ktbbh, 96 bytes                     @20
 struct kdbh, 14 bytes                      @124
 struct kdbt[1], 4 bytes                    @138
 sb2 kdbr[71]                               @142
 ub1 freespace[910]                         @284
 ub1 rowdata[6994]                          @1194
 ub4 tailchk                                @8188
BBED> p kcbh
struct kcbh, 20 bytes                       @0
   ub1 type_kcbh                            @0        0x06
   ub1 frmt_kcbh                            @1        0xa2
   ub1 spare1_kcbh                          @2        0x00
   ub1 spare2_kcbh                          @3        0x00
   ub4 rdba_kcbh                            @4        0x01800096
   ub4 bas_kcbh                             @8        0x00131e6f
   ub2 wrp_kcbh                             @12       0x0000
   ub1 seq_kcbh                             @14       0x01
   ub1 flg_kcbh                             @15       0x04 (KCBHFCKV)
   ub2 chkval_kcbh                          @16       0x4aae
   ub2 spare3_kcbh                          @18       0x0000
BBED> m /x 00000000 offset 4
 File: /u01/oracle/oradata/ora11g/xifenfei02.dbf (1)
 Block: 150              Offsets:    4 to  515           Dba:0x00400096
------------------------------------------------------------------------
 00000000 6f1e1300 00000104 ae4a0000 01000000 01280100 6f1e1300 00000000
 03003200 90008001 ffff0000 00000000 00000000 00000000 00800000 6c781200
 09001d00 05030000 8c02c000 b4000500 00800000 b0191300 02000900 fc020000
 b011c000 0b011400 00800000 6c1e1300 00000000 00000000 00014700 ffffa000
 2e048e03 8e030000 4700e90b 540cb30c 120d710d d00d2f0e 8e0eed0e 4c0fab0f
 0a106910 c8102711 8611e711 4812aa12 0c136713 c2131f14 7c14df14 4115a015
 ff156416 c9162517 8117de17 3b18a118 07196119 bb19191a 771ad61a 351b941b
 f31b521c b11c101d 6f1dd71d 3f1eaa1e 151f2e04 99040405 6f05da05 4506b006
 1b078607 f1075c08 c7082c09 9109f609 5b0ac00a 250b870b 48004900 4a004b00
 4c004d00 4e004f00 5000ffff 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 2c000e03 53595308 565f245f 4c4f434b
 ff03c20f 5eff0456 49455707 786f0912 12230407 786f0912 12230413 32303131
 2d30392d 31383a31 373a3334 3a303305 56414c49 44014e01 4e014e02 c1022c00
 0e065055 424c4943 0756245f 4c4f434b ff03c20f 5fff0753 594e4f4e 594d0778
 6f091212 23040778 6f091212 23041332 3031312d 30392d31 383a3137 3a33343a
 30330556 414c4944 014e014e 014e02c1 022c000e 03535953 07565f24 4c4f434b
 <32 bytes per line>
BBED> sum apply
Check value for File 1, Block 150:
current = 0x4bb8, required = 0x4bb8

dbv检测数据文件
发现提示坏块文件的rdba就是我们刚刚修改的rdba_kcbh值

[oracle@xifenfei tmp]$ dbv file=/u01/oracle/oradata/ora11g/xifenfei02.dbf blocksize=8192
DBVERIFY: Release 11.2.0.3.0 - Production on Fri Jun 1 03:40:44 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/oracle/oradata/ora11g/xifenfei02.dbf
Page 150 is marked corrupt
Corrupt block relative dba: 0x01800096 (file 6, block 150)
Bad header found during dbv:
Data in bad block:
 type: 6 format: 2 rdba: 0x00000000
 last change scn: 0x0000.00131e6f seq: 0x1 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x1e6f0601
 check value in block header: 0x4bb8
 computed block checksum: 0x0
Block Checking: DBA = 25179275, Block Type = KTB-managed data block
data header at 0xb52a807c
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=3
Page 13451 failed with check code 6101
Block Checking: DBA = 25179287, Block Type = KTB-managed data block
data header at 0xb52c0064
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 13463 failed with check code 6101
DBVERIFY - Verification complete
Total Pages Examined         : 15360
Total Pages Processed (Data) : 12931
Total Pages Failing   (Data) : 2
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 291
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 2137
Total Pages Marked Corrupt   : 1
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 1551567 (0.1551567)

修改datafile header的kcvfhrfn值

BBED> set block 1
        BLOCK#          1
BBED> map
 File: /u01/oracle/oradata/ora11g/xifenfei02.dbf (1)
 Block: 1                                     Dba:0x00400001
------------------------------------------------------------
 Data File Header
 struct kcvfh, 860 bytes                    @0
 ub4 tailchk                                @8188
BBED> p kcvfhrfn
ub4 kcvfhrfn                                @368      0x00000006
BBED> m /x 00000000
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /u01/oracle/oradata/ora11g/xifenfei02.dbf (1)
 Block: 1                Offsets:  368 to  879           Dba:0x00400001
------------------------------------------------------------------------
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 e3b38c2e 04a91100 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 797c1900 00000000 3e3bba2e
 01000000 11000000 b40e0000 1000ba8a 02000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 0a000a00 0a000100 00000000
 00000000 00000000 02008001 bb050c00 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 <32 bytes per line>
BBED> sum apply
Check value for File 1, Block 1:
current = 0x1daf, required = 0x1daf

dbv验证数据文件
这里如果验证所有数据文件快,会发现所有类此Corrupt block relative dba: 0x00000001 (file 0, block 1)提示.这里证明datafile header 的kcvfhrfn 影响dbv检查数据文件坏块的一个标准之一

[oracle@xifenfei tmp]$ dbv file=/u01/oracle/oradata/ora11g/xifenfei02.dbf blocksize=8192 start=1 end=4
DBVERIFY: Release 11.2.0.3.0 - Production on Fri Jun 1 03:43:27 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/oracle/oradata/ora11g/xifenfei02.dbf
Page 1 is marked corrupt
Corrupt block relative dba: 0x00000001 (file 0, block 1)
Bad header found during dbv:
Data in bad block:
 type: 11 format: 2 rdba: 0x01800001
 last change scn: 0x0000.00000000 seq: 0x1 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x00000b01
 check value in block header: 0x1daf
 computed block checksum: 0x0
Page 2 is marked corrupt
Corrupt block relative dba: 0x00000002 (file 0, block 2)
Bad header found during dbv:
Data in bad block:
 type: 29 format: 2 rdba: 0x01800002
 last change scn: 0x0000.0017accf seq: 0x1 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xaccf1d01
 check value in block header: 0x2626
 computed block checksum: 0x0
Page 3 is marked corrupt
Corrupt block relative dba: 0x00000003 (file 0, block 3)
Bad header found during dbv:
Data in bad block:
 type: 30 format: 2 rdba: 0x01800003
 last change scn: 0x0000.0017accf seq: 0x1 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xaccf1e01
 check value in block header: 0x4ef4
 computed block checksum: 0x0
Page 4 is marked corrupt
Corrupt block relative dba: 0x00000004 (file 0, block 4)
Bad header found during dbv:
Data in bad block:
 type: 30 format: 2 rdba: 0x01800004
 last change scn: 0x0000.00119bf4 seq: 0x1 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x9bf41e01
 check value in block header: 0x810a
 computed block checksum: 0x0
DBVERIFY - Verification complete
Total Pages Examined         : 4
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 0
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 0
Total Pages Marked Corrupt   : 4
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 0 (0.0)

总结说明
1.dbv检测数据文件坏块的时候会读取数据文件头的kcvfhrfn值,如果这个值出现问题,可能导致数据文件中的所有数据块都异常,具体表现就是Corrupt block relative dba项异常
2.dbv检查数据文件坏块中显示的rdba对应于数据块的rdba_kcbh值

ORACLE最大可以存储多少数据量

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

标题:ORACLE最大可以存储多少数据量

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

今天有朋友在群里面讨论oracle数据库最大可以存储的数据大小,下面根据官方文档提供的相关限制,大概估算出来oracle数据库最多可以存储的数据量

Physical Database Limits(11.2)

Item

Type of Limit

Limit Value

Database Block Size

Minimum

2048 bytes; must be a multiple of operating system physical block size

Database Block Size

Maximum

Operating system dependent; never more than 32 KB

Database Blocks

Minimum in initial extent of a segment

2 blocks

Database Blocks

Maximum per datafile

Platform dependent; typically 222 – 1 blocks

Controlfiles

Number of control files

1 minimum; 2 or more (on separate devices) strongly recommended

Controlfiles

Size of a control file

Dependent on operating system and database creation options; maximum of25,000 x (database block size)

Database files

Maximum per tablespace

Operating system dependent; usually 1022

Database files

Maximum per database

65533

May be less on some operating systems

Limited also by size of database blocks and by the DB_FILES initialization parameter for a particular instance

Database extents

Maximum per dictionary managed tablespace

4 GB * physical block size (with K/M modifier); 4 GB (without K/M modifier)

Database extents

Maximum per locally managed (uniform) tablespace

2 GB * physical block size (with K/M modifier); 2 GB (without K/M modifier)

Database file size

Maximum

Operating system dependent. Limited by maximum operating system file size; typically 222 or 4 MB blocks

MAXEXTENTS

Default value

Derived from tablespace default storage or DB_BLOCK_SIZE initialization parameter

MAXEXTENTS

Maximum

Unlimited

Redo Log Files

Maximum number of logfiles

Limited by value of MAXLOGFILES parameter in the CREATE DATABASE statement

Control file can be resized to allow more entries; ultimately an operating system limit

Redo Log Files

Maximum number of logfiles per group

Unlimited

Redo Log File Size

Minimum size

4 MB

Redo Log File Size

Maximum Size

Operating system limit; typically 2 GB

Tablespaces

Maximum number per database

64 K

Number of tablespaces cannot exceed the number of database files because each tablespace must include at least one file

Bigfile Tablespaces

Number of blocks

A bigfile tablespace contains only one datafile or tempfile, which can contain up to approximately 4 billion ( 232 ) blocks. The maximum size of the single datafile or tempfile is 128 terabytes (TB) for a tablespace with 32 K blocks and 32 TB for a tablespace with 8 K blocks.

Smallfile (traditional) Tablespaces

Number of blocks

A smallfile tablespace is a traditional Oracle tablespace, which can contain 1022 datafiles or tempfiles, each of which can contain up to approximately 4 million (222) blocks.

External Tables file

Maximum size

Dependent on the operating system.

An external table can be composed of multiple files.

通过这里的相关限制可以大概的技术出来oracle数据库在传统数据文件和大数据文件情况下最大大小分别是:

传统数据文件(Smallfile)

32*1024(数据块大小)* (222–1)(一个数据文件的数据块数)*65533

(数据库中最多数据文件个数)= 9006784790495232(byte)/1024/1024/1024/1024=8191.6P
如果按照我们常用的block_size=8k,那么我们的数据库可以存储大小为2047.9P
大数据文件(Bigfile)

32*1024(数据块大小)* (232– 1)(一个数据文件的数据块数)*65533

(数据库中最多数据文件个数) = 9222949822242324480 (byte)/1024/1024/1024/1024 =8589541374P
如果按照我们常用的block_size=8k,那么我们的数据库可以存储大小为2147385343.5P
参考:http://docs.oracle.com/cd/E11882_01/server.112/e25513/limits002.htm

kewastUnPackStats(): bad magic 1 (0x0000000036407DFA, 0)

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

标题:kewastUnPackStats(): bad magic 1 (0x0000000036407DFA, 0)

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

alert日志错误kewastUnPackStats(): bad magic 1 (0x0000000036407DFA, 0)
该错误是出现在win 2008 + 11.2.0.1的数据库中

Sun Jun 03 01:00:05 2012
kewastUnPackStats(): bad magic 1 (0x0000000036407DFA, 0)
kewastUnPackStats(): bad magic 1 (0x0000000036407DFA, 0)
kewastUnPackStats(): bad magic 1 (0x0000000036407DD8, 0)
kewastUnPackStats(): bad magic 1 (0x0000000036407DD8, 0)
kewastUnPackStats(): bad magic 1 (0x0000000036407DD8, 0)
kewastUnPackStats(): bad magic 1 (0x0000000036407DD8, 0)
kewastUnPackStats(): bad magic 1 (0x0000000036407DF0, 0)
kewastUnPackStats(): bad magic 1 (0x0000000036407DF0, 0)
kewastUnPackStats(): bad magic 1 (0x0000000036407DD8, 0)
kewastUnPackStats(): bad magic 1 (0x0000000036407DD8, 0)
Sun Jun 03 02:00:18 2012
kewastUnPackStats(): bad magic 1 (0x0000000035387DD4, 0)
kewastUnPackStats(): bad magic 1 (0x0000000035387DD4, 0)
kewastUnPackStats(): bad magic 1 (0x0000000035387DDC, 0)
kewastUnPackStats(): bad magic 1 (0x0000000035387DDC, 0)
kewastUnPackStats(): bad magic 1 (0x0000000035387DDC, 0)
kewastUnPackStats(): bad magic 1 (0x0000000035387DDC, 0)
kewastUnPackStats(): bad magic 1 (0x0000000035387DDC, 0)
kewastUnPackStats(): bad magic 1 (0x0000000035387DDC, 0)
kewastUnPackStats(): bad magic 1 (0x0000000035387DDC, 0)
kewastUnPackStats(): bad magic 1 (0x0000000035387DDC, 0)
Sun Jun 03 03:00:32 2012
kewastUnPackStats(): bad magic 1 (0x000000001D8F7DD4, 0)
kewastUnPackStats(): bad magic 1 (0x000000001D8F7DD4, 0)
kewastUnPackStats(): bad magic 1 (0x000000001D8F7DDC, 0)
kewastUnPackStats(): bad magic 1 (0x000000001D8F7DDC, 0)
kewastUnPackStats(): bad magic 1 (0x000000001D8F7DDC, 0)
kewastUnPackStats(): bad magic 1 (0x000000001D8F7DDC, 0)
kewastUnPackStats(): bad magic 1 (0x000000001D8F7DD4, 0)
kewastUnPackStats(): bad magic 1 (0x000000001D8F7DD4, 0)
kewastUnPackStats(): bad magic 1 (0x000000001D8F7DD4, 0)
kewastUnPackStats(): bad magic 1 (0x000000001D8F7DD4, 0)
kewastUnPackStats(): bad magic 1 (0x000000001D8F7DDC, 0)

错误原因:
出现该问题是 Bug:8967729/unpublished bug 8730312
Active Session History中某些数据(the moduile, action program, etc. information)未被正确存储,然后awr程序在整点(默认配置)的时候访问V$ACTIVE_SESSION_HISTORY 视图失败,从而出现了该错误.出现该问题可能导致ash和awr使用异常或不准确

问题解决:
1.在Oracle12c release and the 11.2.0.2 and higher patchsets中被修复
2.打上one-off Patch:8730312(one-off补丁没有经过oracle的严格测试,在打该补丁前可能需要进行测试)

系统中数据文件第一个数据块和oracle 中第一个数据块关系

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

标题:系统中数据文件第一个数据块和oracle 中第一个数据块关系

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

数据文件第一个数据块到底有没有纳入数据块的数据块计算中,也就是我们通常所说的rdba(file#,block),是否真的是从数据文件的第一个数据块开始计算的?下面通过实验验证
相关信息和准备工作

SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
PL/SQL Release 9.2.0.4.0 - Production
CORE    9.2.0.3.0       Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') "www.xifenfei.com" from dual;
www.xifenfei.com
-------------------
2012-05-29 19:39:48
SQL> select name,block_size from v$datafile where file#=9;
NAME                                                         BLOCK_SIZE
------------------------------------------------------------ ----------
/u01/oracle/oradata/xifenfei/users01.dbf                           8192
--dd出来数据文件第一和第二个数据块
[oracle@xifenfei ~]$ dd if=/u01/oracle/oradata/xifenfei/users01.dbf of=user.01 bs=8192 count=1
1+0 records in
1+0 records out
[oracle@xifenfei ~]$ dd if=/u01/oracle/oradata/xifenfei/users01.dbf of=user.02 bs=8192 count=1 skip=1
1+0 records in
1+0 records out
[oracle@xifenfei ~]$ ll user.*
-rw-r--r--  1 oracle oinstall 8192 May 26 04:43 user.01
-rw-r--r--  1 oracle oinstall 8192 May 26 04:44 user.02

bbed验证

[oracle@xifenfei ~]$ bbed password=blockedit blocksize=8192  listfile=/home/oracle/bbed_new.file mode=edit
BBED: Release 2.0.0.0.0 - Limited Production on Sat May 26 04:56:49 2012
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
BBED> info
 File#  Name                                                        Size(blks)
 -----  ----                                                        ----------
     1  /u01/oracle/oradata/xifenfei/users01.dbf                             0
     2  /home/oracle/user.01                                                 0
     3  /home/oracle/user.02                                                 0
--users01.dbf(完整数据文件,第一个数据块)
BBED> set file 1
        FILE#           1
BBED> set block 1
        BLOCK#          1
BBED> d /v count 128
 File: /u01/oracle/oradata/xifenfei/users01.dbf (1)
 Block: 1       Offsets:    0 to  127  Dba:0x00400001
-------------------------------------------------------
 0b020000 01004002 00000000 00000104 l ......@.........
 7f4b0000 00002009 00000008 cdb41453 l .K.... ........S
 58494645 4e464549 c7010000 800c0000 l XIFENFEI........
 00200000 09000300 00000000 00000000 l . ..............
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 47180000 00000000 cf4d851e l ....G........M..
 8f40512e 78ab0200 00000000 00000000 l .@Q.x...........
 <16 bytes per line>
--直接设置file 2错误(后续提供其他方法)
BBED> set file 2
BBED-00307: incorrect blocksize (8192) or truncated file
--查看users01.dbf(第二个数据块)
BBED> set file 3
        FILE#           3
BBED> set block 1
        BLOCK#          1
BBED> d /v count 128
 File: /home/oracle/user.02 (3)
 Block: 1       Offsets:    0 to  127  Dba:0x00c00001
-------------------------------------------------------
 0b020000 01004002 00000000 00000104 l ......@.........
 7f4b0000 00002009 00000008 cdb41453 l .K.... ........S
 58494645 4e464549 c7010000 800c0000 l XIFENFEI........
 00200000 09000300 00000000 00000000 l . ..............
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 47180000 00000000 cf4d851e l ....G........M..
 8f40512e 78ab0200 00000000 00000000 l .@Q.x...........
 <16 bytes per line>
--查看users01.dbf(真正第一个数据块)
BBED> set filename 'user.01'
        FILENAME        user.01
BBED> d /v count 128
 File: user.01 (0)
 Block: 1       Offsets:    0 to  127  Dba:0x00000000
-------------------------------------------------------
 00020000 00200000 800c0000 5d5c5b5a l ..... ......]\[Z
 00000000 86280000 00000000 00000000 l .....(..........
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 <16 bytes per line>

通过这个对比可以知道:当我们直接使用bbed查看数据块内容的时候,自动屏蔽了数据文件上真正的第一个数据块.其实block 1是数据文件上的第二个数据块

hexdump验证

--users01.dbf(完整文件)
[oracle@xifenfei ~]$ hexdump -C /u01/oracle/oradata/xifenfei/users01.dbf|head -20
00000000  00 02 00 00 00 20 00 00  80 0c 00 00 5d 5c 5b 5a  |..... ......]\[Z|
00000010  00 00 00 00 86 28 00 00  00 00 00 00 00 00 00 00  |.....(..........|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002000  0b 02 00 00 01 00 40 02  00 00 00 00 00 00 01 04  |......@.........|
00002010  7f 4b 00 00 00 00 20 09  00 00 00 08 cd b4 14 53  |.K.... ........S|
00002020  58 49 46 45 4e 46 45 49  c7 01 00 00 80 0c 00 00  |XIFENFEI........|
00002030  00 20 00 00 09 00 03 00  00 00 00 00 00 00 00 00  |. ..............|
00002040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002060  00 00 00 00 47 18 00 00  00 00 00 00 cf 4d 85 1e  |....G........M..|
00002070  8f 40 51 2e 78 ab 02 00  00 00 00 00 00 00 00 00  |.@Q.x...........|
00002080  00 00 00 00 00 00 00 00  00 00 04 00 58 0d 0b c0  |............X...|
00002090  2c 0b 00 00 5a ea be 2e  01 00 aa bd 15 00 00 00  |,...Z...........|
000020a0  02 00 00 00 10 00 ff bf  02 00 00 00 00 00 00 00  |................|
000020b0  5a 00 00 00 4f ea be 2e  59 00 00 00 00 00 00 00  |Z...O...Y.......|
000020c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000020f0  00 00 00 00 09 00 00 00  05 00 55 53 45 52 53 00  |..........USERS.|
00002100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
--users01.dbf(第一个数据块文件)
[oracle@xifenfei ~]$ hexdump -C user.01
00000000  00 02 00 00 00 20 00 00  80 0c 00 00 5d 5c 5b 5a  |..... ......]\[Z|
00000010  00 00 00 00 86 28 00 00  00 00 00 00 00 00 00 00  |.....(..........|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002000
--users01.dbf(第二个数据块文件)
[oracle@xifenfei ~]$ hexdump -C user.02|head -20
00000000  0b 02 00 00 01 00 40 02  00 00 00 00 00 00 01 04  |......@.........|
00000010  7f 4b 00 00 00 00 20 09  00 00 00 08 cd b4 14 53  |.K.... ........S|
00000020  58 49 46 45 4e 46 45 49  c7 01 00 00 80 0c 00 00  |XIFENFEI........|
00000030  00 20 00 00 09 00 03 00  00 00 00 00 00 00 00 00  |. ..............|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000060  00 00 00 00 47 18 00 00  00 00 00 00 cf 4d 85 1e  |....G........M..|
00000070  8f 40 51 2e 78 ab 02 00  00 00 00 00 00 00 00 00  |.@Q.x...........|
00000080  00 00 00 00 00 00 00 00  00 00 04 00 58 0d 0b c0  |............X...|
00000090  2c 0b 00 00 5a ea be 2e  01 00 aa bd 15 00 00 00  |,...Z...........|
000000a0  02 00 00 00 10 00 ff bf  02 00 00 00 00 00 00 00  |................|
000000b0  5a 00 00 00 4f ea be 2e  59 00 00 00 00 00 00 00  |Z...O...Y.......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000f0  00 00 00 00 09 00 00 00  05 00 55 53 45 52 53 00  |..........USERS.|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  09 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 f9 e9 be 2e  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

通过hexdump对三个文件的对比可以知道users01.dbf的头两个数据文件确实是由第一和第二个数据块组成.然后结合上面bbed dump出来的结果.可以再次证明数据文件第一个数据块,不能被bbed识别(从第二个数据文件开始)

实验总结
我们的数据文件其实是从文件的第二个数据块开始记录起(该数据块为block 1).也就是说系统的数据块和oracle中的rdba标示的数据块不是一致.而是系统数据块比oracle数据块多1.
因这个原因解释了以前的一个疑问:Oracle数据文件大小的限制为什么指定数据文件最大值为(2^22-1*block_size),而不是根据rowid的2^22*block_size
关于类此问题在windows验证请见:在UltraEdit中定位数据文件内容