本文介绍了Oracle8i中引入的几项新特性，包括本地化管理表空间、FBI索引、在线索引创建与重建及可传输的表空间等。这些特性简化了数据库管理，提高了性能。
4. ORACLE8i与系统管理有关的新特性
Oracle8i 引入了几项崭新的特性，可简化对ORDBMS的管理，并使其更易*作和使用。
4.1 本地化管理表空间
在Oracle8I以前，表空 间的使用状况都是通过数据字典来完成的，称为Dictionary-
Managed Tablespace. 在Oracle8I推出以前，这一直都是唯一的表空间管理方式。自从O
racle8I以后，Oracle又增加了一种新的表空间管理方 式：Locally Managed
Tablespace（本地化管理的表空间）。
在传统的数据字典管理的表空间里，Oracle 在数据字典的表里面记录了每个表空间
的每个区的使用状况：每当一个区被使用或被释放时，Oracle都在数据字典里面更新相
应的信息，并 产生相应的redo 信息。在Oracle8I里，这仍然是默认的表空间管理方式。
在Oracle8I的版本中，Oracle推出了 一种全新的表空间管理方式：本地化管理的表
空间。所谓本地化管理，就是指Oracle不再利用数据字典的表来记录Oracle表空间里面
的 区的使用状况，而是在每个表空间的数据文件的头部加入了一个记录块，在其中记录
每个区的使用状况。每当一个区被使用，或者被释放以供重新使用 时，Oracle都会更新
数据文件头部的这个记录，反映这个变化。
本地化管理的表空间的创建过程：
语法：CREATE TABLESPACE 表空间名字
DATAFILE 数据文件详细信息
[EXTENT MANAGEMENT { DICTIONARY | LOCAL
{AUTOALLOCATE | UNIFORM. [SIZE INTETER [K|M] ] } } ]
解释： 关键字EXTENT MANAGEMENT LOCAL 指定这是一个本地化管理的表空间。对于
系统表空间，只能在创建数据库的时候指定EXTENT MANGEMENT LOCAL，因为它是数据库
创 建时建立的第一个表空间。
若为DICTIONARY,则表明这是一个传统的数据字典管理的表空间，这是个默认选项。
当选择了 LOCAL关键字,即表明这是这是一个本地化管理的表空间后，还可以继续选择更
细的管理方式：是AUTOALLOCATE 还是 UNIFORM.。若为AUTOALLOCATE,则表明让Oracle来
决定区块的使用办法；若选择了UNIFORM，则还可以详细指定每个区 块的大小，若不加指
定，则为每个区使用1M大小。
是本地化管理的表空间还是创建数据字典管理的表空间只能在创建表空间的时候指
定。 在表空间已经创建以后，则不能再把本地化管理的表空间和数据字典管理的表空间
再相互转换。在创建临时表空间时，也可以在CREATE TEMPORARY TABLESPACE 中指定EXT
ENT MANAGEMENT LOCAL来指定这是一个本地化管理的表空间。
本地化管理表空间的优点：
1. 本地化管理的表空间避免了递归的空间管理*作。而这种情况在数据字典管理的
表空间是经常出现的，当表 空间里的区的使用状况发生改变时，数据字典的表的信息发
生改变，从而同时也使用了在系统表空间里的回滚段。
2. 本地化管理的表空间避免了在数据字典相应表里面写入空闲块、已使用块的信息
，从而减少了数据字典表的竞争。
3. 区的本地化管理自动跟踪表空间里的空闲块，减少了手工合并自由空间的需要。
4. 表空间里的区的大小可以选择由Oracle系统来决定，或者由数据库管理员指定一
个统一的大小。
5. 从由数据字典来管理空闲块改为由数据文件的头部记录来管理空闲块，这样避免
产生回滚信息，不再使用系统表空间里的回滚段。因为由数据字典来管理的 话，它会把
相关信息记在数据字典的表里，从而产生回滚信息。
由于这种表空间的以上特性，所以它支持在一个表空间里边进行更多的并发*作， 并减
少了对数据字典的依赖。
当然本地化管理的表空间也不是对所有的数据库和数据库对象都是适用的。首先，它不
能指定存储特性，无 STORAGE子句可供使用。其次，它不适用于存储较小的数据库对象。
总的来说，oracle8I 提供了这种全新的表空间管理方式，给了我们更多的选择。对
于用来存储大对象的表空间和临时表空间来说，用本地化管理的表空间组织方式不失为
一 个较好的选择。
4.2 FBI索引
Oracle8i的很重要的一个新特性就是增加了function-based index这种索引类型（
后面简称为FBI）。有了这个特性后，Oracle DBA就可以在索引中使用函数或者表达式了
。这些函数可以 使Oracle自己的函数，也可以使用户自己的PL/SQL函数等。
DBA在SQL语句调优的过程中遇到的一个很常见的问题就是，如何优化那些 在WHERE子句中
使用了函数的语句。因为在以前，在WHERE子句中使用函数会使在这个表上创建的索引没
法利用，从而难以提高这个语句 的性能。
例子：
使用基于成本的优化器，索引为标准的B树索引，建立在SURNAME列上。
SQL>create index non_fbi on sale_contacts (surname);
SQL>analyze index non_fbi compute statistics;
SQL>:analyze table sale_contacts compute statistics;
SQL>SELECT count(*) FROM sale_contacts
WHERE UPPER(surname) = ELLISON ;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT ptimizer=CHOOSE (Cost=3 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF SALES_CONTACTS (Cost=3 Card=16
Bytes=272)
从SQL*PLUS的 autotrace产生的执行路径可以看到，虽然我们在WHERE子句中用到的S
URNAME列上创建了索引，但是仍然执行的是全表扫描。如果这 张表很大的话，这回消耗
大量的时间。
现在我们试着建立一个FBI索引：
SQL>create index fbi on sale_contacts (UPPER(surname));
SQL>analyze index fbi compute statistics;
SQL>analyze table sale_contacts compute statistics;
SQL>SELECT count(*) FROM sale_contacts WHERE UPPER(surname) =
ELLISON ;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT ptimizer=CHOOSE (Cost=2 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 INDEX (RANGE SCAN) OF FBI (NON-UNIQUE) (Cost=2 Card=381
Bytes=6477)
从SQL*Plus返回的执行计划我们可以看到，这次，Oracle对表 不再全表扫描，而是
先扫描索引，因为优化器可以知道FBI索引得存在。
使用FBI索引所能够带来的性能提升取决于表的大小、表中重复 记录的量、在WHERE
子句中使用的列等因素。
有一点需要清楚，FBI索引并不真正在索引里边存储了表达式的结果，而是使用了一
个" 表达树"（expression tree）。
由优化器来对SQL语句中的表达式进行解析，并且和FBI索引上面的表达式进行对比
。 这里，SQL函数的大小写时敏感的。因此要求SQL语句中使用的函数和创建FBI索引得时
候的那个SQL函数的大小写一致，否则无法利用这个 FBI索引。因此，在编程的时候要有
一个良好的编程风格。
Init.ora里边需要修改的参数
下面这几个参数必须在 init.ora里边指定：
QUERY_REWRITE_INTEGRITY = TRUSTED
QUERY_REWRITE_ENABLED = TRUE
COMPATIBLE = 8.1.0.0.0 (or higher)
授权：
要使一个用户能够创建FBI索引，他必须被授予以下权限：CREATE INDEX和QUERY
REWRITE,或者 CREATE ANY INDEX和GLOBAL QUERY REWRITE这两个权限。
索引的使用者必须能够有那个FBI索引上使用的那 个函数的执行权限。如果没有相应
的权限，那么这个FBI索引得状态将变成DISABLED（DBA_INDEXES）。
如果那个 FBI索引得状态是DISABLED，那么DBA可以这样来处理：
A：删除并重建
B：ALTER INDEX index_name ENABLED。这个Enabled只能对FBI索引使用。
C：ALTER INDEX UNUSABLE;
注意：如果一个查询中使用到了这个索引，但是这个FBI索引的状态是DISABLED，但
是优化器选择了使用这个索引，那么将会返回一个 Oracle错误。
例子：
ORA error:
ERROR at line 1: ORA-30554: function-based index MYUSER.FBI is disabled.
而且，一旦这个FBI索引的状态是 Disabled，那么这张表上所有涉及索引列的DML*
作也将失败。除非这个索引得状态变成UNUSABLE，而且在初始化参数里边指定 SKIP_UNUS
ABLE_INDEXES为TRUE。
一些例子：
SQL>CREATE INDEX expression_ndx
ON mytable ((mycola + mycolc) * mycolb);
SQL>SELECT mycolc FROM mytable
WHERE (mycola + mycolc) * mycolb <= 256;
复合索引的例子：
SQL>CREATE INDEX example_ndx
ON myexample (mycola, UPPER(mycolb), mycolc);
SQL>SELECT mycolc FROM myexample
WHERE mycola = 55 AND UPPER(mycolb) = JONES ;
限制和规则总结：
对于下面这些限制，不能创建FBI索引：
a) LOB 列
b) REF
c) Nested table 列
d) 包含上面数据类型的对象
FBI索引必须遵守下面的规则：
a) 必须使用基于成本的优化器，而且创建后必须对索引进行分析
b) 不能存储NULL值。因为任何函数在任何情况下都不能返回NULL值。
c)如果一个用户定义的PL/SQL例程失效了，而且这个例程被FBI索引用到了，那么相
应的这个FBI索引会变成DISABLED
d)创建FBI索引得函数必须是确定性的。即，对于指定的输入，总是会返回确定的结
果。
e) 索引的属主如果没有了在FBI索引里面使用的函数的执行权限，那么这个FBI索引
会变成DISABLED.
f) 在创建索引得函数里面不能使用SUM等总计函数。
g)要把一个DISABLED了的索引重新变成ENABLED，这个函数必须首先是 ENABLED的才
可以。
4.3 在线索引创建和重建
索引创建与重建在Oracle8i中可联机实现，而不必中断对基表 可能实施插入、更新或删
除*作。创建与重建索引是一件非常耗时的工作，尤其当基表很大时。在Oracle8i之前
，在索引创建与重建期 间，不允许对其基表进行任何DML*作。
在线创建索引：
CREATE INDEX EMP_NO ON EMP (EMPNO)
TABLESPACE INDEX1
PCTFREE 10
STORAGE (INITIAL 1M NEXT 1M PCTINCREASE 0)
ONLINE;
在线重建索引：
ALTER INDEX EMP_NO REBUILD ONLINE;
注： 在线索引构建期间，尽管能UPDATE（更新）基表，但根据Oracle的建议，最好不要
采取会影响到大部分数据行的*作。
4.4 使用可传输的表空间实现数据在数据库间的移动
对于可传输的表空间这一特性来说，允许我们把一个或多个表空间从一个数据库移
动 或复制到另一个数据库。
可传输的表空间有下面几点限制：
源和目标数据库必须处于同一个硬件平台。
源和目标数据库的数据库块大小必须一样，而且必须采用同一个字符集。
如果表空间名和目标数据库上的表空间名雷同，这个表空间就不能被传输到目标数
据库。
数据库表空间迁移的基本过程是：令表空间为只 读，并复制相应的数据文件，然后利用E
XP/IMP，从数据字典中卸载元数据，并把它装载到目标数据库。
表空间迁移前首先要检测 待迁移的表空间是否自包含。我们可以通过执行内置的PL/SQL
过程DBMS_TTS.TRANSPORT_SET_CHECK判断表空间是否自 包含:
EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK( SALEDAT,SALESIDX ,TRUE);
SELECT * FROM TRANSPORT_SET_VOILATIONS;
其中, SALEDAT,SALESIDX是表空间名。若TRANSPORT_SET_VOILATIONS没有记录，则说明
待迁移的表空间是自包含。
以下是表空间迁移的*作步骤，1-5步*作在源数据库表空间*作完成，6、7、8步
在目的数据库表空间*作完成。
1.用数据库管理 员（INTERNAL）身份登录ORACLE，（CONNECT INTERNAL/******）。
2.将源tablsspace_name表 空间置为READ ONLY，使得表空间下的数据文件置为READ
ONLY状态，可以进行*作系统级的拷贝，（ALTER TABLESPACE tablsspace_name READ
ONLY）。如果是生产系统请注意选择好进行此*作的时间。
3.利用 EXP工具进行数据库表空间的迁移，（EXP INTERNAL/******
FILE=filename.DMP LOG=logname.LOG TRANSPORT_TABLESPACE=Y
TABLESPACES=tablsspace_name BUFFER=1024000 ）。
4.将待迁移的表空间下的所有数据文件进行*作系统级的拷贝，复制到目的数据库*作
系统硬盘下。
5. 将源tablsspace_name表空间置为READ WRITE，使得表空间下的数据文件置为READ
WRITE状态，（ALTER TABLESPACE tablsspace_name READ WRITE）。
6.在目的数据库上建立相应的用户user_name并赋予 CREATE SESSION权限。
7.在目的数据库上利用IMP工具进行数据库表空间的迁移，（IMP INTERNAL/******
FILE=filename.DMP LOG=logname.LOG TRANSPORT_TABLESPACE=Y
TABLESPACES=tablsspace_name DATAFILES=datafile_name1,datafile_name2）。
8.在目的数据库上将目的tablsspace_name 表空间置为READ WRITE，使得表空间下的数据
文件置为READ WRITE状态，（ALTER TABLESPACE tablsspace_name READ WRITE）。
Oracle8i 引入了几项崭新的特性，可简化对ORDBMS的管理，并使其更易*作和使用。
4.1 本地化管理表空间
在Oracle8I以前，表空 间的使用状况都是通过数据字典来完成的，称为Dictionary-
Managed Tablespace. 在Oracle8I推出以前，这一直都是唯一的表空间管理方式。自从O
racle8I以后，Oracle又增加了一种新的表空间管理方 式：Locally Managed
Tablespace（本地化管理的表空间）。
在传统的数据字典管理的表空间里，Oracle 在数据字典的表里面记录了每个表空间
的每个区的使用状况：每当一个区被使用或被释放时，Oracle都在数据字典里面更新相
应的信息，并 产生相应的redo 信息。在Oracle8I里，这仍然是默认的表空间管理方式。
在Oracle8I的版本中，Oracle推出了 一种全新的表空间管理方式：本地化管理的表
空间。所谓本地化管理，就是指Oracle不再利用数据字典的表来记录Oracle表空间里面
的 区的使用状况，而是在每个表空间的数据文件的头部加入了一个记录块，在其中记录
每个区的使用状况。每当一个区被使用，或者被释放以供重新使用 时，Oracle都会更新
数据文件头部的这个记录，反映这个变化。
本地化管理的表空间的创建过程：
语法：CREATE TABLESPACE 表空间名字
DATAFILE 数据文件详细信息
[EXTENT MANAGEMENT { DICTIONARY | LOCAL
{AUTOALLOCATE | UNIFORM. [SIZE INTETER [K|M] ] } } ]
解释： 关键字EXTENT MANAGEMENT LOCAL 指定这是一个本地化管理的表空间。对于
系统表空间，只能在创建数据库的时候指定EXTENT MANGEMENT LOCAL，因为它是数据库
创 建时建立的第一个表空间。
若为DICTIONARY,则表明这是一个传统的数据字典管理的表空间，这是个默认选项。
当选择了 LOCAL关键字,即表明这是这是一个本地化管理的表空间后，还可以继续选择更
细的管理方式：是AUTOALLOCATE 还是 UNIFORM.。若为AUTOALLOCATE,则表明让Oracle来
决定区块的使用办法；若选择了UNIFORM，则还可以详细指定每个区 块的大小，若不加指
定，则为每个区使用1M大小。
是本地化管理的表空间还是创建数据字典管理的表空间只能在创建表空间的时候指
定。 在表空间已经创建以后，则不能再把本地化管理的表空间和数据字典管理的表空间
再相互转换。在创建临时表空间时，也可以在CREATE TEMPORARY TABLESPACE 中指定EXT
ENT MANAGEMENT LOCAL来指定这是一个本地化管理的表空间。
本地化管理表空间的优点：
1. 本地化管理的表空间避免了递归的空间管理*作。而这种情况在数据字典管理的
表空间是经常出现的，当表 空间里的区的使用状况发生改变时，数据字典的表的信息发
生改变，从而同时也使用了在系统表空间里的回滚段。
2. 本地化管理的表空间避免了在数据字典相应表里面写入空闲块、已使用块的信息
，从而减少了数据字典表的竞争。
3. 区的本地化管理自动跟踪表空间里的空闲块，减少了手工合并自由空间的需要。
4. 表空间里的区的大小可以选择由Oracle系统来决定，或者由数据库管理员指定一
个统一的大小。
5. 从由数据字典来管理空闲块改为由数据文件的头部记录来管理空闲块，这样避免
产生回滚信息，不再使用系统表空间里的回滚段。因为由数据字典来管理的 话，它会把
相关信息记在数据字典的表里，从而产生回滚信息。
由于这种表空间的以上特性，所以它支持在一个表空间里边进行更多的并发*作， 并减
少了对数据字典的依赖。
当然本地化管理的表空间也不是对所有的数据库和数据库对象都是适用的。首先，它不
能指定存储特性，无 STORAGE子句可供使用。其次，它不适用于存储较小的数据库对象。
总的来说，oracle8I 提供了这种全新的表空间管理方式，给了我们更多的选择。对
于用来存储大对象的表空间和临时表空间来说，用本地化管理的表空间组织方式不失为
一 个较好的选择。
4.2 FBI索引
Oracle8i的很重要的一个新特性就是增加了function-based index这种索引类型（
后面简称为FBI）。有了这个特性后，Oracle DBA就可以在索引中使用函数或者表达式了
。这些函数可以 使Oracle自己的函数，也可以使用户自己的PL/SQL函数等。
DBA在SQL语句调优的过程中遇到的一个很常见的问题就是，如何优化那些 在WHERE子句中
使用了函数的语句。因为在以前，在WHERE子句中使用函数会使在这个表上创建的索引没
法利用，从而难以提高这个语句 的性能。
例子：
使用基于成本的优化器，索引为标准的B树索引，建立在SURNAME列上。
SQL>create index non_fbi on sale_contacts (surname);
SQL>analyze index non_fbi compute statistics;
SQL>:analyze table sale_contacts compute statistics;
SQL>SELECT count(*) FROM sale_contacts
WHERE UPPER(surname) = ELLISON ;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT ptimizer=CHOOSE (Cost=3 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF SALES_CONTACTS (Cost=3 Card=16
Bytes=272)
从SQL*PLUS的 autotrace产生的执行路径可以看到，虽然我们在WHERE子句中用到的S
URNAME列上创建了索引，但是仍然执行的是全表扫描。如果这 张表很大的话，这回消耗
大量的时间。
现在我们试着建立一个FBI索引：
SQL>create index fbi on sale_contacts (UPPER(surname));
SQL>analyze index fbi compute statistics;
SQL>analyze table sale_contacts compute statistics;
SQL>SELECT count(*) FROM sale_contacts WHERE UPPER(surname) =
ELLISON ;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT ptimizer=CHOOSE (Cost=2 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 INDEX (RANGE SCAN) OF FBI (NON-UNIQUE) (Cost=2 Card=381
Bytes=6477)
从SQL*Plus返回的执行计划我们可以看到，这次，Oracle对表 不再全表扫描，而是
先扫描索引，因为优化器可以知道FBI索引得存在。
使用FBI索引所能够带来的性能提升取决于表的大小、表中重复 记录的量、在WHERE
子句中使用的列等因素。
有一点需要清楚，FBI索引并不真正在索引里边存储了表达式的结果，而是使用了一
个" 表达树"（expression tree）。
由优化器来对SQL语句中的表达式进行解析，并且和FBI索引上面的表达式进行对比
。 这里，SQL函数的大小写时敏感的。因此要求SQL语句中使用的函数和创建FBI索引得时
候的那个SQL函数的大小写一致，否则无法利用这个 FBI索引。因此，在编程的时候要有
一个良好的编程风格。
Init.ora里边需要修改的参数
下面这几个参数必须在 init.ora里边指定：
QUERY_REWRITE_INTEGRITY = TRUSTED
QUERY_REWRITE_ENABLED = TRUE
COMPATIBLE = 8.1.0.0.0 (or higher)
授权：
要使一个用户能够创建FBI索引，他必须被授予以下权限：CREATE INDEX和QUERY
REWRITE,或者 CREATE ANY INDEX和GLOBAL QUERY REWRITE这两个权限。
索引的使用者必须能够有那个FBI索引上使用的那 个函数的执行权限。如果没有相应
的权限，那么这个FBI索引得状态将变成DISABLED（DBA_INDEXES）。
如果那个 FBI索引得状态是DISABLED，那么DBA可以这样来处理：
A：删除并重建
B：ALTER INDEX index_name ENABLED。这个Enabled只能对FBI索引使用。
C：ALTER INDEX UNUSABLE;
注意：如果一个查询中使用到了这个索引，但是这个FBI索引的状态是DISABLED，但
是优化器选择了使用这个索引，那么将会返回一个 Oracle错误。
例子：
ORA error:
ERROR at line 1: ORA-30554: function-based index MYUSER.FBI is disabled.
而且，一旦这个FBI索引的状态是 Disabled，那么这张表上所有涉及索引列的DML*
作也将失败。除非这个索引得状态变成UNUSABLE，而且在初始化参数里边指定 SKIP_UNUS
ABLE_INDEXES为TRUE。
一些例子：
SQL>CREATE INDEX expression_ndx
ON mytable ((mycola + mycolc) * mycolb);
SQL>SELECT mycolc FROM mytable
WHERE (mycola + mycolc) * mycolb <= 256;
复合索引的例子：
SQL>CREATE INDEX example_ndx
ON myexample (mycola, UPPER(mycolb), mycolc);
SQL>SELECT mycolc FROM myexample
WHERE mycola = 55 AND UPPER(mycolb) = JONES ;
限制和规则总结：
对于下面这些限制，不能创建FBI索引：
a) LOB 列
b) REF
c) Nested table 列
d) 包含上面数据类型的对象
FBI索引必须遵守下面的规则：
a) 必须使用基于成本的优化器，而且创建后必须对索引进行分析
b) 不能存储NULL值。因为任何函数在任何情况下都不能返回NULL值。
c)如果一个用户定义的PL/SQL例程失效了，而且这个例程被FBI索引用到了，那么相
应的这个FBI索引会变成DISABLED
d)创建FBI索引得函数必须是确定性的。即，对于指定的输入，总是会返回确定的结
果。
e) 索引的属主如果没有了在FBI索引里面使用的函数的执行权限，那么这个FBI索引
会变成DISABLED.
f) 在创建索引得函数里面不能使用SUM等总计函数。
g)要把一个DISABLED了的索引重新变成ENABLED，这个函数必须首先是 ENABLED的才
可以。
4.3 在线索引创建和重建
索引创建与重建在Oracle8i中可联机实现，而不必中断对基表 可能实施插入、更新或删
除*作。创建与重建索引是一件非常耗时的工作，尤其当基表很大时。在Oracle8i之前
，在索引创建与重建期 间，不允许对其基表进行任何DML*作。
在线创建索引：
CREATE INDEX EMP_NO ON EMP (EMPNO)
TABLESPACE INDEX1
PCTFREE 10
STORAGE (INITIAL 1M NEXT 1M PCTINCREASE 0)
ONLINE;
在线重建索引：
ALTER INDEX EMP_NO REBUILD ONLINE;
注： 在线索引构建期间，尽管能UPDATE（更新）基表，但根据Oracle的建议，最好不要
采取会影响到大部分数据行的*作。
4.4 使用可传输的表空间实现数据在数据库间的移动
对于可传输的表空间这一特性来说，允许我们把一个或多个表空间从一个数据库移
动 或复制到另一个数据库。
可传输的表空间有下面几点限制：
源和目标数据库必须处于同一个硬件平台。
源和目标数据库的数据库块大小必须一样，而且必须采用同一个字符集。
如果表空间名和目标数据库上的表空间名雷同，这个表空间就不能被传输到目标数
据库。
数据库表空间迁移的基本过程是：令表空间为只 读，并复制相应的数据文件，然后利用E
XP/IMP，从数据字典中卸载元数据，并把它装载到目标数据库。
表空间迁移前首先要检测 待迁移的表空间是否自包含。我们可以通过执行内置的PL/SQL
过程DBMS_TTS.TRANSPORT_SET_CHECK判断表空间是否自 包含:
EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK( SALEDAT,SALESIDX ,TRUE);
SELECT * FROM TRANSPORT_SET_VOILATIONS;
其中, SALEDAT,SALESIDX是表空间名。若TRANSPORT_SET_VOILATIONS没有记录，则说明
待迁移的表空间是自包含。
以下是表空间迁移的*作步骤，1-5步*作在源数据库表空间*作完成，6、7、8步
在目的数据库表空间*作完成。
1.用数据库管理 员（INTERNAL）身份登录ORACLE，（CONNECT INTERNAL/******）。
2.将源tablsspace_name表 空间置为READ ONLY，使得表空间下的数据文件置为READ
ONLY状态，可以进行*作系统级的拷贝，（ALTER TABLESPACE tablsspace_name READ
ONLY）。如果是生产系统请注意选择好进行此*作的时间。
3.利用 EXP工具进行数据库表空间的迁移，（EXP INTERNAL/******
FILE=filename.DMP LOG=logname.LOG TRANSPORT_TABLESPACE=Y
TABLESPACES=tablsspace_name BUFFER=1024000 ）。
4.将待迁移的表空间下的所有数据文件进行*作系统级的拷贝，复制到目的数据库*作
系统硬盘下。
5. 将源tablsspace_name表空间置为READ WRITE，使得表空间下的数据文件置为READ
WRITE状态，（ALTER TABLESPACE tablsspace_name READ WRITE）。
6.在目的数据库上建立相应的用户user_name并赋予 CREATE SESSION权限。
7.在目的数据库上利用IMP工具进行数据库表空间的迁移，（IMP INTERNAL/******
FILE=filename.DMP LOG=logname.LOG TRANSPORT_TABLESPACE=Y
TABLESPACES=tablsspace_name DATAFILES=datafile_name1,datafile_name2）。
8.在目的数据库上将目的tablsspace_name 表空间置为READ WRITE，使得表空间下的数据
文件置为READ WRITE状态，（ALTER TABLESPACE tablsspace_name READ WRITE）。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25136010/viewspace-683024/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/25136010/viewspace-683024/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
