TAF,透明应用故障转移(Transparent Application Failover),是Oracle数据库提供的一项高可用特性,普遍应用于RAC环境中,当然也可以用于Data Guard和传统的HA实现的主从热备的环境中。

TAF中的Transparent和Failover,点出了这个高可用特性的两大特点:

  • TAF是用于故障转移的,也就是切换。当Oracle连接的会话由于数据库发生故障不可用时,会话能够自动切换到RAC中的其他可用的节点上,或者切换到Standby上面,或者切换到HA方式中的另一个可用的节点上面。
  • TAF的故障转移,对应用来说是透明的,应用系统不需要进行特别的处理就能够自动进行故障转移。

但是,TAF是完美的吗?是不是使用了TAF,应用就能真的无缝地进行切换呢?对应用和数据库有没有其他什么要求?要回答这些问题,我们需要全面地了解、掌握TAF。我始终认为,要用好一个东西,首先得掌握这个东西背后的工作原理与机制。

首先来看看Failover。Failover有两种,一种是连接时Failover,另一种则是运行时Failover。前者的作用在于,应用(客户端)在连接数据库时,如果由于网络、实例故障等原因,连接不上时,能够连接数据库中的其他实例。后者的作用在于,对于一个已经在工作的会话(也就是连接已经建立),如果这个会话的实例异常中止等,应用(客户端)能够连接到数据库的其他实例(或备用库)。

首先,TAF是ORACLE客户端提供的一项特性。使用TAF,对客户端的环境有一定的要求。比如JAVA的JDBC驱动、Oracle客户端的版本等(8i开始支持TAF)。这个问题将在本系统文章的后面部分详细描述。

下面看一个有趣的例子:

Read the rest of this entry

在安装oracle时,oracle会提示输入sysdba用户组名,凡是以操作系统认证方式的连接,如果连接的用户在这个指定的用户组中,就可以用sysdba用户登陆。一般情况下,也是建议的sysdba用户组为dba。

有的时候,也存在这样一种情况,安装oracle软件的时候,输入了错误的sysdba用户组名(主要是由于创建oracle用户时指定到了错误的其他用户组中,现实中这种情况曾经出现过)。这样一来,就会导致不规范的安装,或者oracle后来修改回正确的用户组(dba),将导致oracle用户不能以sysdba权限连接数据库,甚至不能启动数据库)。不规范的安装,如果将安装的oracle软件tar到其他机器,会导致那个机器的oracle也出现oracle不能以sysdba连接的问题(有的人安装oracle时,如果有现成的,他就喜欢用tar的方式)。

如果指定了错误的sysdba用户组名,怎么样快捷修改而又不用重新安装oracle软件呢?既然在安装时可以指定,那么一定会有一个地方,存储了这个配置,这个存储的文件就是$ORACLE_HOME/rdbms/lib/config.c。

我们看看config.c这个文件的内容:
[oracle@xty lib]$ cat config.c

/* SS_DBA_GRP defines the UNIX group ID for sqldba adminstrative access. */
/* Refer to the Installation and User's Guide for further information. */

#define SS_DBA_GRP "dba"
#define SS_OPER_GRP "dba"

char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP};

从这个文件中,可以看到SYSDBA的用户组为"dba",而SYSOPER的用户组也为"dba"。如果我们把#define SS_DBA_GRP "dba"这一行改为#define SS_DBA_GRP "adm",然后执行下面的命令:relink all,再用oracle用户连接数据库时:

[oracle@xty ~]$ sqlplus /nolog

SQL*Plus: Release 10.2.0.3.0 - Production on Sat Jan 10 15:30:17 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

SQL> connect / as sysdba
ERROR:
ORA-01031: insufficient privileges

SQL> connect / as sysoper
Connected to an idle instance

可以看到,oracle用户已经不能够用sysdba权限连接到数据库,也就更谈不上启动数据库了。但是由于sysoper的用户组没有改变,所以oracle仍然是可以用sysoper权限连接数据库并启动数据库的。(不过如果我们不使用操作系统认证,比如通过网络连接的方式用SID连接,并提供sys用户的密码,使用密码文件认证,也一样能够使用sysdba权限连接)

如果修改用户oracle的用户组为adm,则可以使用sysdba用户连接了。
[root@xty ~]# usermod -G adm oracle
oracle用户重新登陆到服务器上

[root@xty ~]# su - oracle
[oracle@xty ~]$ sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.3.0 - Production on Sat Jan 10 15:42:47 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

Connected to an idle instance.

最后,我们把config.c修改回原来的值("dba"),再relink all,再把oracle的用户组修改回dba,oracle也就恢复了原状。

在数据库服务器上,如果采用操作系统认证,而oracle用户又不能以sysdba权限连接(ORA-01031错误),在其他可能都排除后,有必要检查一下config.c,以确认sysdba用户组是正确的。

前面两篇文章简要介绍了db_block_checking和db_block_checksum参数,并提到这两个参数对性能的影响。下面做个测试:

首先建一个测试表,并设置db_block_checking和db_block_checksum为false:

SQL> create table t2 (a int) tablespace test;

表已创建。
SQL> alter system set db_block_checking=false;

系统已更改。

SQL> alter system set db_block_checksum=false;

向测试表T2中四次分别插入100,000行数据:

SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 06.02
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 05.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

Read the rest of this entry

在之前的一篇文章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=0x9200000, Compatibility Vsn=134217728=0x8000000
    Db ID=2968647772=0xb0f1f85c, Db Name='XJ'
    Activation ID=0=0x0
    Control Seq=761=0x2f9, File size=128000=0x1f400
    File Number=1, Blksiz=4096, File Type=3 DATA
Tablespace #0 - SYSTEM  rel_fn:1
Creation   at   scn: 0x0000.00000009 05/12/2002 16:20:42
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0x26ce9ece scn: 0x0000.000a65e0 recovered at 07/19/2008 21:23:10
 status:0x4 root dba:0x00400341 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字段对应一具隐含字段,上面建有索引)。