老熊的三分地-Oracle、UNIX、数据恢复

在之前的一篇文章db_block_checking和db_block_checksum，简要地描述了db_block_checking和db_block_checksum这两个参数的作用以及性能方面的影响。在10gR1及这前的版本中，这两个参数可以设置为false和true。而在10gR2版本中，这两个参数发生了一点变化。

先来看看db_block_checking，这个参数现在有四个可能的设置：

• OFF - 与原来的FALSE一样，对非SYSTEM表空间的块关闭检查，这个值在设置时仍然可以用false。
• LOW - 只检查块头。这个检查发生在当块的内容在内存中发生改变时，比如UPDATE、INSERT、DELETE等，以及将块从磁盘读入、RAC结点间块的传输。
• MEDIUM - 比LOW更高一级，还包括了非IOT的表的块内部检查（即不仅仅是块头）。
• FULL - 与原来的TRUE一样，与MEDIUM相比，还包括了索引块的检查。

再看看db_block_checksum这个参数有什么变化：

• OFF - 与原来的FALSE一样，只会给SYSTEM表空间的块计算checksum值。
• TYPICAL - 与原来的TRUE一样，Oracle在向磁盘写入块时计算checksum值，下次读入时进行校验。
• FULL - 这是新增的值，Oracle不关在写入块时计算checksum值，而且在更改块（比如执行UPDATE语句等）之前对checksum值进行校验，同时在更改块之后对checksum值进行重新计算。另外Oracle也会在写入日志块时，计算块的checksum。这个设置大大增加了系统负荷，大约带来了4-5%的负荷。而TYPICAL值会带来1-2%的负荷。

Oracle数据库的global_name，在Database Link与GLOBAL_NAMES参数一文中提到了，设置global_names初始化参数为true后，本地的数据库链接名称必须与远程数据库的global_name相同，才能正常使用数据库链接。那么怎么查询数据库的global_name呢？

SQL> col global_name for a30
SQL> select * from global_name;

GLOBAL_NAME
------------------------------
DMDB

那么怎么样修改global_name？

ALTER DATABASE
RENAME GLOBAL_NAME TO NEW_NAME;

注意不要直接用update global_name set global_name=”将global_name设置为空，否则数据库不能启动，会报ORA-00600[18061] 或 ORA-00600[18062]这样的错误。 只有用备份进行恢复后才能打开。（参见metalink note 743676.1）。

那么global_name到底是个什么对象呢？

SQL> select owner,object_name,object_type from dba_objects where object_name=’GLOBAL_NAME’;

OWNER OBJECT_NAME OBJECT_TYPE
---------- -------------------- --------------------
SYS GLOBAL_NAME VIEW
PUBLIC GLOBAL_NAME SYNONYM

SQL> select text from dba_views where view_name=’GLOBAL_NAME’;

TEXT
----------------------------------------------------------------
select value$ from sys.props$ where name = ‘GLOBAL_DB_NAME’

Read the rest of this entry »

如果一个表的外键引用的是另一个用户的表，需要特别的权限吗？答案就是refrences权限。虽然一个schema（用户）下表的外键引用的是其他schema（用户）的表，是一种不太好的设计。但现实中仍然会有这种情况。下面来看看reference的作用：

测试环境：
Oracle 10.2.0.1
Redhat Linux AS4
数据库里用于测试的两个用户test1和test2，只有connect角色权限和表空间使用权限。

SQL> connect / as sysdba
Connected.
SQL> create table test1.t1 as select * from dba_objects where rownum< =1000;

Table created.

SQL> create table test2.t2 as select * from dba_objects where rownum< =1000;

Table created.

SQL> alter table test1.t1 add constraint pk_t1 primary key(object_id);

Table altered.

现在，我们用用户test2连接到数据库，在表test2.t2的object_id字段上增加一个外键，外键引用test1.t1表的object_id字段：

SQL> connect test2/test
Connected.
SQL> alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id);
alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id)
*
ERROR at line 1:
ORA-00942: table or view does not exist

我们将test1.t1表的查询权限赋给test2：

SQL> grant select on test1.t1 to test2;

Grant succeeded.

再次增加外键：

SQL> alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id);
alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id)
*
ERROR at line 1:
ORA-01031: insufficient privileges

可以看到报权限不足。我们再看看如果将DBA权限给test2会怎么样：
Read the rest of this entry »

Oracle的监听(Listener)在缺省情况下，会在文件中记录日志，记录数据库实例注册操作、客户端的连接等。缺省（没有设置log_file参数时）的文件是$ORACLE_HOME/network/log/listener.log。对于一些使用短连接的，频繁的连接数据库的应用，listener.log增长很快。有的可以在比较短的时间内（十几天）就可以超过2GB。对于一些平台的某些版本的Oracle，在监听日志增大到2GB以后会导致监听不能正常工作（我没遇到过，不过感兴趣的朋友可以在网上搜索一下，有这样的案例）。

对于这种listener.log增长非常迅速的系统，可以关闭监听日志，不让监听写日志到文件。也可以写个job定期清理。本文主要描述怎么样关闭监听日志：

可以在监听命令行接口中使用命令：
D:\>lsnrctl

LSNRCTL for 32-bit Windows: Version 9.2.0.1.0 - Production on 15-10月-2008 20:52:11

Copyright (c) 1991, 2002, Oracle Corporation. All rights reserved.

欢迎来到LSNRCTL，请键入”help”以获得信息。

LSNRCTL> set log_status off
正在连接到 (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dreamf)(PORT=1521)))
LISTENER 参数 \log_status\ 被设为 OFF
命令执行成功
LSNRCTL> save_config
正在连接到 (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dreamf)(PORT=1521)))
未保存对LISTENER所作的更改
命令执行成功
LSNRCTL>

我们可以在listener.ora文件中可以看到增加了下面的内容：

#----ADDED BY TNSLSNR 15-10月-2008 10:05:43---
LOGGING_LISTENER = OFF
#---------------------------------------------

所以我们也可以在listener.ora文件增加上面的内容来关闭监听日志。但是只有在监听重启后才会生效，而通过lsnrctl 这个命令接口设置，可以立即生效，Windows平台上的文件会立即关闭。因此可以利用这个特性，用来删除WINDOWS平台上的监听日志文件，因为不这样，在监听运行时监听日志是不能删除的。

在Oracle的备份恢复过程中，需要注意数据文件的unrecoverable，不适当的操作很容易造成恢复后有大量的坏块。在视图v$datafile中，UNRECOVERABLE_CHANGE#和UNRECOVERABLE_TIME分别表示数据文件最后一个unrecoverable操作的change#和时间。unrecoverable通常就是指不记录日志的操作（nologging），这样当用一个旧的数据文件还原后，用日志进行恢复时，由于日志文件没有记录unrecoverable的操作时的日志，导致那些操作的数据块为逻辑坏块（实际上在日志文件中为这样的操作产生了一些重做日志项，在恢复时，根据这些重做日志项，直接将相应的数据块标记为坏块）。常见的以下几种情况：
1. 非归档模式下的create table as 操作和直接路径插入（如加了append hint的insert语句和直接路径装载）
2. 归档模式下的create table xxx nologging（即创建表时为表指定了nologging）和nologging表的直接路径插入。
在数据库（或表空间）为force logging时，任何操作都会记录日志。不会有unrecoverable操作。

下面先做个实验（数据库版本为9.2.0.1）来看看这两列：

数据库当前处于非归档模式;

SQL> select name,checkpoint_time,unrecoverable_time from v$datafile where file#=10;

NAME CHECKPOINT_TIME UNRECOVERABLE_TIME
---------------------------------------- ------------------- -------------------
D:\ORACLE\ORADATA\XJ\TEST01.DBF 2008-09-23 09:28:22

SQL> create table t tablespace test nologging as select * from dba_objects where rownum< =10;

表已创建。
SQL> select name,checkpoint_time,unrecoverable_time from v$datafile where file#=10;

NAME CHECKPOINT_TIME UNRECOVERABLE_TIME
---------------------------------------- ------------------- -------------------
D:\ORACLE\ORADATA\XJ\TEST01.DBF 2008-09-23 09:28:22

可以看到，unrecoverable_time为空。想一想就可以理解，unrecoverable操作都是将数据直接写入了数据文件，没有经过SGA的缓存，非归档模式下的物理备份都是一致的冷备份，不需要日志来进行恢复，因此对于非归档模式下并不存在unrecoverable操作。unrecoverable只是针对归档模式的。下面将数据库置为归档模式后，重复上述过程，进行验证：

SQL> create table t tablespace test nologging as select * from dba_objects where rownum< =10;

表已创建。

SQL> select name,checkpoint_time,unrecoverable_time,unrecoverable_change# from v$datafile where file#=10;

NAME CHECKPOINT_TIME UNRECOVERABLE_TIME UNRECOVERABLE_CHANGE#
---------------------------------------- ------------------- ------------------- ---------------------
D:\ORACLE\ORADATA\XJ\TEST01.DBF 2008-09-23 09:45:03 2008-09-23 09:45:41 1298047

可以看到，v$datafile视图中unrecoverable_time和unrecoverable_change#已经有了值。

下面来看看unrecoverable_time是最后一次unrecoverable操作的开始时间还是结束时间？
创建一个具有延时功能的函数：

create or replace function f_cdate return date
as
begin
dbms_lock.sleep(10);
return sysdate;
end;

SQL> create table t (d date) nologging tablespace test;

表已创建。

SQL> begin
2 dbms_output.put_line(’start test:’||sysdate);
3 insert /*+ append */ into t select f_cdate from dba_objects where rownum< =10;
4 dbms_output.put_line('after insert:'||sysdate);
5 dbms_lock.sleep(60);
6 commit;
7 dbms_output.put_line('end test:'||sysdate);
8 end;
9 /
start test:2008-09-23 10:31:50
after insert:2008-09-23 10:33:33
end test:2008-09-23 10:34:34

PL/SQL 过程已成功完成。

SQL> select name,checkpoint_time,unrecoverable_time,unrecoverable_change# from v$datafile where file#=10;

NAME CHECKPOINT_TIME UNRECOVERABLE_TIME UNRECOVERABLE_CHANGE#
---------------------------------------- ------------------- ------------------- ---------------------
D:\ORACLE\ORADATA\XJ\TEST01.DBF 2008-09-23 09:45:03 2008-09-23 10:33:33 1299032
SQL> begin
2 dbms_output.put_line(’start test:’||sysdate);
3 insert /*+ append */ into t select f_cdate from dba_objects where rownum< =10;
4 dbms_output.put_line('after insert:'||sysdate);
5 dbms_lock.sleep(60);
6 rollback;
7 dbms_output.put_line('end test:'||sysdate);
8 end;
9 /
start test:2008-09-23 10:37:59
after insert:2008-09-23 10:39:42
end test:2008-09-23 10:40:43

PL/SQL 过程已成功完成。

SQL> select name,checkpoint_time,unrecoverable_time,unrecoverable_change# from v$datafile where file#=10;

NAME CHECKPOINT_TIME UNRECOVERABLE_TIME UNRECOVERABLE_CHANGE#
---------------------------------------- ------------------- ------------------- ---------------------
D:\ORACLE\ORADATA\XJ\TEST01.DBF 2008-09-23 09:45:03 2008-09-23 10:39:42 1299157

可以看到unrecoverable_time为unrecoverable操作完成的那个时间，不管事务是否提交。

对于数据库备份后的恢复，需要注意查询v$datafile视图中关于unrecoverable操作时间，如果unrecoverable操作时间在数据文件备份之后（更精确的比较是通过change#，比较文件的checkpoint_change#和unrecoverable_change#），则恢复会产生坏块。

建议重要的数据库，将数据库置为force logging（当然数据库应当是归档模式），避免无意的产生了unrecoverable操作。或者在做了unrecoverable操作之后立即进行数据文件的备份。

PS：关于不产生日志的操作，请参见metalink NOTE:269274.1 CHECK FOR LOGGING/NOLOGGING ON DB OBJECT(S)

大家在管理ORACLE数据库时，通常使用PROFILE对用户密码设置期限，但是需要注意应用系统连接的用户，对于密码期限设置，应谨慎处理。

首先我们看看怎么样为用户设置密码有效期：

在测试例子中，我们使用TEST用户进行测试，密码为TEST，先看看用户的状态。

SQL> select account_status,lock_date,expiry_date,created,profile from dba_users where username=’TEST’;

ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE CREATED PROFILE
-------------- ---------- ----------- ------------------- -------
OPEN 2008-03-27 15:29:18 DEFAULT

SQL> select ctime,ptime,exptime,ltime,spare6 from user$ where name=’TEST’;

CTIME PTIME EXPTIME LTIME SPARE6
------------------- ------------------- ------------------- ------------------- -------------------
2008-03-27 15:29:18 2008-03-27 15:29:18

在user$数据字典中，有几个字段是dba_users中看不到的。比如PTIME（应该就是密码设置或修改的时间），这里PTIME=CREATED（因为用户创建后没有改变过密码）

下面我们将创建profile，将密码有效期设置为10天，并将用户TEST的PROFILE设置为创建的test_profile：

SQL> create profile test_profile limit password_life_time 10 password_grace_time 0;
配置文件已创建
SQL> alter user test profile test_profile;
用户已更改。

再看看用户数据：

SQL> select account_status,lock_date,expiry_date,created,profile from dba_users where username=’TEST’;

ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE CREATED PROFILE
------------------------------ ------------------- ------------------- ------------------- ------------
OPEN 2008-04-06 15:29:18 2008-03-27 15:29:18 TEST_PROFILE

SQL> select ctime,ptime,exptime,ltime,spare6 from user$ where name=’TEST’;

CTIME PTIME EXPTIME LTIME SPARE6
------------------- ------------------- ------------------- ------------------- -------------------
2008-03-27 15:29:18 2008-03-27 15:29:18

注意到除了PROFILE列从DEFAULT变为了TEST_PROFILE，EXPIRY_DATE改变了，正好是PTIME+10。注意在USER$表中，EXPTIME为空，DBA_USERS中的EXPIRY_TIME是通过PTIME和PROFILE计算出来的。因此EXPIRY_TIME为密码将要到期的时间。

现在为用户设置好了PROFILE，新开一个SQLPLUS会话，用TEST用户登录：

SQL> connect test/test
ERROR:
ORA-28001: the password has expired

更改test的口令
新口令:

这个时候可以修改用户的密码。但是如果是应用软件没有对ORA-28001错误进行处理，则不能进行连接。这个时候我们看看用户的状态：

SQL> select account_status,lock_date,expiry_date,created,profile from dba_users where username=’TEST’;

ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE CREATED PROFILE
------------------------------ ------------------- ------------------- ------------------- ------------
EXPIRED 2008-03-27 15:29:18 TEST_PROFILE
SQL> select account_status,lock_date,expiry_date,created,profile from dba_users where username=’TEST’;

ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE CREATED PROFILE
------------------------------ ------------------- ------------------- ------------------- ------------
EXPIRED 2008-03-27 15:29:18 TEST_PROFILE

可以看到用户状态为EXPIRED。这个状态是记录在数据字典USER$中的，如果此时把用户的PROFILE改回为DEFAULT，这个状态仍然不会改变。

SQL> alter user test profile default;

用户已更改。

SQL> select account_status,lock_date,expiry_date,created,profile from dba_users where username=’TEST’;

ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE CREATED PROFILE
------------------------------ ------------------- ------------------- ------------------- ------------
EXPIRED 2008-03-27 15:29:18 DEFAULT

用户状态仍然为EXPIRED。这个时候，如果应用连接不上数据库，只有DBA手工干预了。对于状态为LOCKED的用户，使用alter user user_name account unlock即可。对于EXPIRED状态的用户，没有UNEXPIRE的命令，只有通过修改用户密码来重设状态：

SQL> alter user test identified by test;

用户已更改。

SQL> select account_status,lock_date,expiry_date,created,profile from dba_users where username=’TEST’;

ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE CREATED PROFILE
------------------------------ ------------------- ------------------- ------------------- ------------
OPEN 2008-03-27 15:29:18 DEFAULT

可以看到用户状态已经恢复正常。

SQL> select ctime,ptime,exptime,ltime,spare6 from user$ where name=’TEST’;

CTIME PTIME EXPTIME LTIME SPARE6
------------------- ------------------- ------------------- ------------------- ------------------
2008-03-27 15:29:18 2008-08-13 23:16:42

用户的密码设置时间也发生了变化。

如果在某些情况下，不知道用户的密码，可以通过下面的办法来设置密码：

SQL> select password from dba_users where username=’TEST’;

PASSWORD
------------------------------
7A0F2B316C212D67

SQL> alter user test identified by values ‘7A0F2B316C212D67′;

用户已更改。

总结：对于为用户设置了密码有效期限的用户，应用软件应能够处理ORA-28001错误，或者DBA应定期对密码进行重设。否则不要为用户密码设置期限，当然对于DBA帐号，为安全起见，通过PROFILE强制要求用户定期修改密码，并且可以要求每次使用的密码不能使用以前使用的密码。

 在上一篇文章（Oracle的段类型 Part I）中，我们得到了Oracle9i中所有的段类型，下面我们将对每一种段类型进行一个简单的说明：
TABLE：这是最常见的段类型，普通表（即非CLUSTER），没有分区，则每个表有一个类型为TABLE的段。
INDEX：这是除了TABLE之外最常见的段类型，表的普通索引，没有分区，则每个索引有一个类型为INDEX的段。除了表上的普通索引之外，INDEX CLUSTER上的索引也是INDEX段，并且在INDEX CLUSTER上必须有一个索引（HASH CLUSTER不要求建索引）。注意IOT表的段类型为INDEX段，而不是TABLE段：
SQL> create table t2 ( object_id number primary key,object_name varchar2(100))
  2  organization index;
SQL> select owner,segment_type,segment_name,header_file,header_block from dba_segments where segment_name=’T2′;

未选定行

SQL> select index_name from user_indexes where table_name=’T2′;

INDEX_NAME
------------------------------
SYS_IOT_TOP_29668

SQL> select owner,segment_type,segment_name from dba_segments where segment_name=’SYS_IOT_TOP_29668′;

OWNER      SEGMENT_TYPE    SEGMENT_NAME
---------- --------------- ----------------------------------------
SYS        INDEX           SYS_IOT_TOP_29668
注意IOT表的溢出段是TABLE类型的段：
SQL> create table iot
  2    (  x    int,
  3       y    date,
  4      z    varchar2(2000),
  5      constraint iot_pk primary key (x)
  6   )
  7   organization index
  8   pctthreshold 10
  9   overflow;

表已创建。
SQL> select owner,segment_type,segment_name from dba_segments where  owner=’TEST’;

OWNER      SEGMENT_TYPE    SEGMENT_NAME
---------- --------------- ----------------------------------------
TEST       TABLE           SYS_IOT_OVER_29670
TEST       INDEX           IOT_PK
 

TABLE PARTITION和TABLE SUBPARTITION：表分区，每个分区或子分区都有一个段。
INDEX PARTITION和INDEX SUBPARTITION：索引分区，每个分区或子分区都有一个段。
CLUSTER：每个CLUSTER有一个CLUSTER段。一个CLUSTER中可以存储一个或多个表。由于CLUSTER不能分区，所以没有CLUSTER PARTITION这样的段。
LOBINDEX：表的每个LOB字段，有一个LOBINDEX段。注意对于分区表的LOB字段，每个分区上的LOB字段均会有LOBINDEX段，但是段类型为INDEX PARTITION或INDEX SUBPARTITION，这是一个特殊情况（不知道ORACLE为什么这样，从视图定义上看sys.indpart$和sys.indsubpart$没有type#字段）。
LOBSEGMENT、LOB PARTITION、LOB SUBPARTITION：表中的每个LOB字段，有LOBSEGMENT字段，如果表进行了分区，则在每个分区上相应有LOB PARTITION和LOB SUBPARTITION：
SQL> create table t
  2  ( id int primary key,
  3    txt clob
  4  )
  5  /
SQL> select owner,segment_type,segment_name from dba_segments where  owner=’TEST’;

OWNER      SEGMENT_TYPE    SEGMENT_NAME
---------- --------------- ----------------------------------------
TEST       TABLE           T
TEST       LOBINDEX        SYS_IL0000029682C00002$$
TEST       INDEX           SYS_C002632
TEST       LOBSEGMENT      SYS_LOB0000029682C00002$$

注意：虽然BFILE可以作为LOB类型进行处理，但存储没有LOBINDEX和LOBSEGMENT字段：
SQL> create table t
  2  ( id int primary key,
  3    thefile bfile
  4  )
  5  /
SQL> select owner,segment_type,segment_name from dba_segments where  owner=’TEST’;

OWNER      SEGMENT_TYPE    SEGMENT_NAME
---------- --------------- ----------------------------------------
TEST       TABLE           T
TEST       INDEX           SYS_C002633
可以看到没有任何与BFILE相关的单独的段。

ROLLBACK：就是8i及以前的回滚段，在9i以及以后的版本中，即使使用了自动撤销段管理，仍然会有一个SYSTEM回滚段。
TYPE2 UNDO：这就是9i及以后的“撤销段”，跟ROLLBACK段类似。我们仍然习惯于叫回滚段。
DEFERRED ROLLBACK：延迟回滚段。如果一个表空间OFFLINE时，表空间上的对象存在活动事务，则会在SYSTEM表空间中创建延迟回滚段，以便在表空间ONLINE能够回滚：
SQL> insert into t select * from dba_objects where rownum<=10;

已创建10行。
SQL> alter tablespace tools offline;

表空间已更改。
SQL> select owner,segment_type,segment_name from dba_segments where  segment_type like ‘%DEF%’;

OWNER      SEGMENT_TYPE                   SEGMENT_NAME
---------- ------------------------------ ----------------------------------------
SYS        DEFERRED ROLLBACK              1.84337

TEMPORARY：临时段。除了磁盘排序产生临时段之外，临时表也会有临时段。另外，在CTAS过程中，如果SQL还没有最终完成，这个时候的表对应的段为TEMPORARY表，只有在SQL执行的最后将TEMPORARY段改为TABLE段。比如：
SQL> create table t2 as select * from dba_objects;
在执行上面语句的同时，执行：
SQL> select segment_type,owner,segment_name from dba_segments where segment_type=’TEMPORARY’;

SEGMENT_TYPE       OWNER                          SEGMENT_NAME
------------------ ------------------------------ --------------------------------------------
TEMPORARY          SYS                            1.84337
可以看到临时段，在CTAS执行完之后，我们可以看到：

SQL> select segment_type,owner,segment_name from dba_segments where segment_type=’TEMPORARY’;

未选定行
SQL> select header_file,header_block from dba_segments where owner=USER and segment_name=’T2′;

HEADER_FILE HEADER_BLOCK
----------- ------------
          1        84337
可以看到，之前的临时段（其段名为一个特别的名字1.84337，段头的文件号和块号），与CTAS后的表的段头一致。
另外在表和索引的MOVE、REBUILD阶段也会有临时段。所以临时段不一定是在临时表中，在普通的表空间中也可能会存在。
 注意在排序段和临时表的段在并没有在DBA_SEGMENTS视图，而是在V$TEMPSEG_USAGE视图中。

CACHE：这是一个特殊的段，为Oracle的自举（bootstrap）段。
SQL> select owner,segment_type,segment_name,header_file,header_block from dba_segments where segment_type=’CACHE’;

OWNER      SEGMENT_TYPE    SEGMENT_NAME    HEADER_FILE HEADER_BLOCK
---------- --------------- --------------- ----------- ------------
SYS        CACHE           1.833                     1          833
我们通过DUMP数据文件头可以发现：
 FILE HEADER:
    Software vsn=153092096=0×9200000, Compatibility Vsn=134217728=0×8000000
    Db ID=2968647772=0xb0f1f85c, Db Name=’XJ’
    Activation ID=0=0×0
    Control Seq=761=0×2f9, File size=128000=0×1f400
    File Number=1, Blksiz=4096, File Type=3 DATA
Tablespace #0 - SYSTEM  rel_fn:1
Creation   at   scn: 0×0000.00000009 05/12/2002 16:20:42
Backup taken at scn: 0×0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0×26ce9ece scn: 0×0000.000a65e0 recovered at 07/19/2008 21:23:10
 status:0×4 root dba:0×00400341 chkpt cnt: 272 ctl cnt:271
root dba转换为文件号和块号则为1.833，正好是类型为CACHE的段头。Oracle通过文件号为1的文件头的root dba定位到自举对象，然后得到obj$等核心对象所在位置，来进行启动。
NESTED TABLE：嵌套表的段，以面举例子说明：
SQL> create or replace type emp_type
  2  as object
  3  (empno       number(4),
  4   ename       varchar2(10),
  5   job         varchar2(9),
  6   mgr         number(4)
  7   );
  8  /

类型已创建。

SQL> create or replace type emp_tab_type
  2   as table of emp_type;
  3  /

类型已创建。
SQL> create table dept_and_em
  2  (deptno number(2) primary key,
  3   dname     varchar2(14),
  4   loc       varchar2(13),
  5   emps      emp_tab_type,
  6   emps2      emp_tab_type
  7  )
  8  nested table emps store as emps_nt
  9  nested table emps2 store as emps_nt2;

表已创建。
SQL> select owner,segment_type,segment_name from dba_segments where  owner=’TEST’;

OWNER      SEGMENT_TYPE    SEGMENT_NAME
---------- --------------- ----------------------------------------
TEST       NESTED TABLE    EMPS_NT
TEST       NESTED TABLE    EMPS_NT2
TEST       TABLE           DEPT_AND_EM
TEST       INDEX           SYS_C002629
TEST       INDEX           SYS_C002630
TEST       INDEX           SYS_C002631
这里看到有两个类型为NESTED TABLE的段。另外除了主键之外，每个NESTED TABLE字段上还有一个索引（实际上是每个NESTED TABLE字段对应一具隐含字段，上面建有索引）。
 

Oracle数据库中有多少类型的段，除了常见的TABLE、INDEX之外还有哪些？下面通过Oracle9i的数据字典来探讨Oracle的段类型。

SQL> select distinct segment_type from dba_segments;

SEGMENT_TYPE
------------------
CACHE
CLUSTER
INDEX
INDEX PARTITION
LOBINDEX
LOBSEGMENT
NESTED TABLE
ROLLBACK
TABLE
TABLE PARTITION
TYPE2 UNDO

然而在DBA_SEGMENTS视图中，不一定包含了所有的段类型，我们从DBA_SEGMENTS的定义中去寻找Oracle的段类型。

SQL> select text from dba_views where view_name=’DBA_SEGMENTS’;

TEXT
----------------------------------------------------------------------------------------------------
select owner, segment_name, partition_name, segment_type, tablespace_name,
       header_file, header_block,
       dbms_space_admin.segment_number_blocks(tablespace_id, relative_fno,
       header_block, segment_type_id, buffer_pool_id, segment_flags,
       segment_objd, blocks)*blocksize,
       dbms_space_admin.segment_number_blocks(tablespace_id, relative_fno,
       header_block, segment_type_id, buffer_pool_id, segment_flags,
       segment_objd, blocks),
       dbms_space_admin.segment_number_extents(tablespace_id, relative_fno,
       header_block, segment_type_id, buffer_pool_id, segment_flags,
       segment_objd, extents),
       initial_extent, next_extent, min_extents, max_extents, pct_increase,
       freelists, freelist_groups, relative_fno,
       decode(buffer_pool_id, 0, ‘DEFAULT’, 1, ‘KEEP’, 2, ‘RECYCLE’, NULL)
from sys_dba_segs

 SQL> select text from dba_views where view_name=’SYS_DBA_SEGS’;

TEXT
--------------------------------------------------------------------------
select u.name, o.name, o.subname,
       so.object_type, s.type#,
       ts.ts#, ts.name, ts.blocksize,
       f.file#, s.block#,
       s.blocks * ts.blocksize, s.blocks, s.extents,
       s.iniexts * ts.blocksize,
       decode(bitand(ts.flags, 3), 1, to_number(NULL),
                                      s.extsize * ts.blocksize),
       s.minexts, s.maxexts,
       decode(bitand(ts.flags, 3), 1, to_number(NULL),
                                      s.extpct),
       decode(bitand(ts.flags, 32), 32, to_number(NULL),
              decode(s.lists, 0, 1, s.lists)),
       decode(bitand(ts.flags, 32), 32, to_number(NULL),
              decode(s.groups, 0, 1, s.groups)),
       s.file#, s.cachehint, NVL(s.spare1,0), o.dataobj#
from sys.user$ u, sys.obj$ o, sys.ts$ ts, sys.sys_objects so, sys.seg$ s,
     sys.file$ f
where s.file# = so.header_file
  and s.block# = so.header_block
  and s.ts# = so.ts_number
  and s.ts# = ts.ts#
  and o.obj# = so.object_id
  and o.owner# = u.user#
  and s.type# = so.segment_type_id
  and o.type# = so.object_type_id
  and s.ts# = f.ts#
  and s.file# = f.relfile#
select u.name, un.name, NULL,
       decode(s.type#, 1, ‘ROLLBACK’, 10, ‘TYPE2 UNDO’), s.type#,
       ts.ts#, ts.name, ts.blocksize, f.file#, s.block#,
       s.blocks * ts.blocksize, s.blocks, s.extents,
       s.iniexts * ts.blocksize, s.extsize * ts.blocksize, s.minexts,
       s.maxexts, s.extpct,
       decode(bitand(ts.flags, 32), 32, to_number(NULL),
         decode(s.lists, 0, 1, s.lists)),
       decode(bitand(ts.flags, 32), 32, to_number(NULL),
         decode(s.groups, 0, 1, s.groups)),
       s.file#, s.cachehint, NVL(s.spare1,0), un.us#
from sys.user$ u, sys.ts$ ts, sys.undo$ un, sys.seg$ s, sys.file$ f
where s.file# = un.file#
  and s.block# = un.block#
  and s.ts# = un.ts#
  and s.ts# = ts.ts#
  and s.user# = u.user#
  and s.type# in (1, 10)
  and un.status$ != 1
  and un.ts# = f.ts#
  and un.file# = f.relfile#
union all
select u.name, to_char(f.file#) || ‘.’ || to_char(s.block#), NULL,
       decode(s.type#, 2, ‘DEFERRED ROLLBACK’, 3, ‘TEMPORARY’,
                      4, ‘CACHE’, 9, ‘SPACE HEADER’, ‘UNDEFINED’), s.type#,
       ts.ts#, ts.name, ts.blocksize,
       f.file#, s.block#,
       s.blocks * ts.blocksize, s.blocks, s.extents,
       s.iniexts * ts.blocksize,
       decode(bitand(ts.flags, 3), 1, to_number(NULL),
                                      s.extsize * ts.blocksize),
       s.minexts, s.maxexts,
       decode(bitand(ts.flags, 3), 1, to_number(NULL),
                                      s.extpct),
       decode(bitand(ts.flags, 32), 32, to_number(NULL),
         decode(s.lists, 0, 1, s.lists)),
       decode(bitand(ts.flags, 32), 32, to_number(NULL),
         decode(s.groups, 0, 1, s.groups)),
       s.file#, s.cachehint, NVL(s.spare1,0), s.hwmincr
from sys.user$ u, sys.ts$ ts, sys.seg$ s, sys.file$ f
where s.ts# = ts.ts#
  and s.user# = u.user#
  and s.type# not in (1, 5, 6, 8, 10)
  and s.ts# = f.ts#
  and s.file# = f.relfile#

SQL> select text from dba_views where view_name=’SYS_OBJECTS’;

TEXT
--------------------------------------------------------------------------------------
select decode(bitand(t.property, 8192), 8192, ‘NESTED TABLE’, ‘TABLE’), 2, 5,
       t.obj#, t.file#, t.block#, t.ts#
from sys.tab$ t
where bitand(t.property, 1024) = 0               /* exclude clustered tables */
union all
select ‘TABLE PARTITION’, 19, 5,
       tp.obj#, tp.file#, tp.block#, tp.ts#
from sys.tabpart$ tp
union all
select ‘CLUSTER’, 3, 5,
       c.obj#, c.file#, c.block#, c.ts#
from sys.clu$ c
union all
select decode(i.type#, 8, ‘LOBINDEX’, ‘INDEX’), 1, 6,
       i.obj#, i.file#, i.block#, i.ts#
from sys.ind$ i
where i.type# in (1, 2, 3, 4, 6, 7, 8, 9)
union all
select ‘INDEX PARTITION’, 20, 6,
       ip.obj#, ip.file#, ip.block#, ip.ts#
from sys.indpart$ ip
union all
select ‘LOBSEGMENT’, 21, 8,
       l.lobj#, l.file#, l.block#, l.ts#
from sys.lob$ l
union all
select ‘TABLE SUBPARTITION’, 34, 5,
       tsp.obj#, tsp.file#, tsp.block#, tsp.ts#
       from sys.tabsubpart$ tsp
union all
select ‘INDEX SUBPARTITION’, 35, 6,
       isp.obj#, isp.file#, isp.block#, isp.ts#
from sys.indsubpart$ isp
union all
select decode(lf.fragtype$, ‘P’, ‘LOB PARTITION’, ‘LOB SUBPARTITION’),
       decode(lf.fragtype$, ‘P’, 40, 41), 8,
       lf.fragobj#, lf.file#, lf.block#, lf.ts#
from sys.lobfrag$ lf

因此，从以上几个视图的定义中可以看到，Oracle9i中有如下的段类型：
NESTED TABLE
TABLE
TABLE PARTITION
CLUSTER
LOBINDEX
INDEX
INDEX PARTITION
LOBSEGMENT
TABLE SUBPARTITION
INDEX SUBPARTITION
LOB PARTITION
LOB SUBPARTITION
ROLLBACK
TYPE2 UNDO
DEFERRED ROLLBACK
TEMPORARY
CACHE
SPACE HEADER
UNDEFINED

在Oracle 10g 的database concepts上提到，Oracle 10g的最大容量是8exabytes（EB），1EB=1024PB=1048576TB，这是一个相当大的数据了。还没有听说过单个库的容量达到这么大的。（虽然现实中有达到EB级别的数据量的，但那是很多个库的数据量的合计，而不是单个库。）

我们看看这8EB是怎么计算来的：

Oracle 10g的数据文件最多可以有64K个，对于单个数据文件来说，BigFile表空间的数据文件可以达到2的32次方个块，也就是4G块（因为rdba为32位）。每个块的最大大小为32K，因此一个BigFile表空间数据文件的最大大小为4G*32K=128T。整个库的最大大小即为64K（数据文件数）* 128T（单个文件最大容量）=8192PB=8EB

先看看Oracle文档上对db_block_checking参数的说明：

DB_BLOCK_CHECKINGcontrols whether Oracle performs block checking for data blocks. When this parameter is set totrue, Oracle performs block checking for all data blocks. When it is set tofalse, Oracle does not perform. block checking for blocks in the user tablespaces. However, block checking for theSYSTEMtablespace is always turned on.

Oracle checks a block by going through the data on the block, making sure it is self-consistent. Block checking can often prevent memory and data corruption. Block checking typically causes 1% to 10% overhead, depending on workload. The more updates or inserts in a workload, the more expensive it is to turn on block checking. You should set

DB_BLOCK_CHECKING to true

if the performance overhead is acceptable

从文档中可以看到，DB_BLOCK_CHECKING参数主要是用于数据块的逻辑（一致）检查（但只是块内，不包括块间的逻辑检查，比如索引项目的ROWID指向的是不存在的行等）。主要用于防止在内存中损坏或数据损坏。由于是逻辑检查，因此引起的额外负荷比较高，甚至可以达到10%，因此对于一个繁忙的系统，特别是插入或更新操作很多的系统，性能影响是比较明显的。

该参数对SYSTEM表空间始终是处于“打开”状态，而不管该参数是否设置为FALSE。

下面再看看db_block_checksum参数的说明：

DB_BLOCK_CHECKSUMdetermines whether DBWnand the direct loader will calculate achecksum(a number calculated from all the bytes stored in the block) and store it in the cache header of every data block when writing it to disk. Checksums are verified when a block is read-only if this parameter istrueand the last write of the block stored a checksum. In addition, Oracle gives every log block a checksum before writing it to the current log.

If this parameter is set tofalse, DBWncalculates checksums only for theSYSTEMtablespace, but not for user tablespaces.

Checksums allow Oracle to detect corruption caused by underlying disks, storage systems, or I/O systems. Turning on this feature typically causes only an additional 1% to 2% overhead. Therefore, Oracle Corporation recommends that you setDB_BLOCK_CHECKSUM to true

可以看到，DB_BLOCK_CHECKSUM只是在写入（DBWn常规写法或用户进程直接路径写入），根据一个CHECKSUM算法，计算数据块的校验和。然后写入数据块的一个特定位置（CACHE HEADER，具体是块的16-17字节，以0字节起算）。在读取块时，再进行检验。主要是防止IO硬件和IO子系统的错误。

CHECKSUM的算法只是根据块的字节值计算一个效验和，因此算法比较简单，引起的系统额外负荷通常在1%-2%

实际上，即使将该参数设为TRUE，将数据块（包括SYSTEM表空间）的16-17字节清0，同时将15字节（flag），第3位（即值为16进制 0×04）清为0，则在块读取时也不会做CHECKSUM检查。如果该参数为FALSE，对于除SYSTEM的其他表空间，如果原来有CHECKSUM 值，将15-16字节清0也不会做CHECKSUM检查。