5.2 资源管理
可使用数据库资源管理器（Database Resource Manager）控制数据库用户中系统资源的分配。相对于单独使用操作系统控制，数据库资源管理器为DBA提供了对系统资源分配的更多控制。
5.2.1 实现数据库资源管理器
可使用数据库资源管理器将一定比例的系统资源分配给各类用户和工作。例如，可将75%的可用CPU资源分配给联机用户，将剩下的25% CPU资源分配给批处理用户。为使用数据库资源管理器，需要创建资源计划、资源消费者组和资源计划指令。
在使用数据库资源管理器命令前，必须为工作创建一个“未决区域”。要创建未决区域，可使用DBMS_RESOURCE_MANAGER程序包的CREATE_PENDING_AREA过程。完成变更后，使用VALIDATE_PENDING_AREA过程检查新的计划集、子计划集和指令集的有效性。然后就可以提交变更（通过SUBMIT_PENDING_AREA）或清除变更（通过CLEAR_PENDING_ AREA）。管理未决区域的过程没有任何输入变量，因此，创建未决区域需使用下面的语法：
execute dbms_resource_manager.create_pending_area();
如果没有创建未决区域，则在试图创建资源计划时会收到一条错误消息。
为创建资源计划，必须使用DBMS_RESOURCE_MANAGER程序包的CREATE_PLAN过程。CREATE_PLAN过程的语法如下：
创建计划时，给计划一个名称（在plan变量中）和一条注释。默认情况下，CPU分配方法将使用“强调”方法，根据百分比分配CPU资源。下面的示例显示了如何创建DEVELOPERS计划：
execute DBMS_RESOURCE_MANAGER.CREATE_PLAN -
(Plan => 'DEVELOPERS', -
Comment => 'Developers, in Development database');
注意：
连字符（-）是SQL*Plus中的续行符，允许一条命令分多行完成。
为创建并管理资源计划和资源消费者组，必须针对会话启用ADMINISTER_RESOURCE_ MANAGER系统权限。如果DBA使用WITH ADMIN OPTION，则具有该权限。为将该权限授予非DBA用户，必须执行DBMS_RESOURCE_MANAGER_PRIVS程序包的GRANT_ SYSTEM_ PRIVILEGE过程。下面的示例授予用户LYNDAG管理数据库资源管理器的能力：
execute DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE -
(grantee_name => 'LYNDAG', -
privilege_name => 'ADMINISTER_RESOURCE_MANAGER', -
admin_option => TRUE);
可通过DBMS_RESOURCE_MANAGER程序包的REVOKE_SYSTEM_PRIVILEGE过程取消LYNDAG的权限。
启用ADMINISTER_RESOURCE_MANAGER权限后，可使用DBMS_RESOURCE_MANAGER中的CREATE_CONSUMER_GROUP过程创建资源消费者组。CREATE_CONSUMER_GROUP过程的语法如下：
CREATE_CONSUMER_GROUP
(consumer_group IN VARCHAR2,
comment IN VARCHAR2,
cpu_mth IN VARCHAR2 DEFAULT 'ROUND-ROBIN')
由于将把用户赋给资源消费者组，因此根据用户的逻辑划分来为组提供名称。下面的示例创建了两个组：一个用于联机开发人员，另一个用于批处理开发人员：
execute DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP -
(Consumer_Group => 'Online_developers', -
Comment => 'Online developers');
execute DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP -
(Consumer_Group => 'Batch_developers', -
Comment => 'Batch developers');
建立了计划和资源消费者组后，就需要创建资源计划指令，并将用户赋给资源消费者组。为将指令赋给计划，使用DBMS_RESOURCE_MANAGER程序包的CREATE_PLAN_ DIRECTIVE过程。CREATE_PLAN_DIRECTIVE过程的语法如下：
CREATE_PLAN_DIRECTIVE过程中的多个CPU变量支持创建多层的CPU分配。例如，可分配75%的CPU资源（第1层）给联机用户。在剩余的CPU资源（第2层）中，可分配其中的50%给第二组用户。可将第2层中可用CPU资源的其余50%划分给第3层中的多个组。CREATE_PLAN_DIRECTIVE过程最多支持8层的CPU分配。
下面的示例显示了为DEVELOPERS资源计划中的ONLINE_DEVELOPERS和BATCH_ DEVELOPERS资源消费者组创建计划指令：
execute DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE -
(Plan => 'DEVELOPERS', -
Group_or_subplan => 'ONLINE_DEVELOPERS', -
Comment => 'online developers', -
Cpu_p1 => 75, -
Cpu_p2=> 0, -
Parallel_degree_limit_p1 => 12);
execute DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE -
(Plan => 'DEVELOPERS', -
Group_or_subplan => 'BATCH_DEVELOPERS', -
Comment => 'Batch developers', -
Cpu_p1 => 25, -
Cpu_p2 => 0, -
Parallel_degree_limit_p1 => 6);
除分配CPU资源外，计划指令也限制了由资源消费者组中成员执行的操作的并行化。在前面的示例中，批处理开发人员的并行化程度限制为6，减少了他们使用系统资源的能力。联机开发人员的并行化程度限制为12。
注意：
Oracle Database 12c包括失控查询管理（runaway query management），以主动避免以下情形：查询已到达一个消费者组的极限，会影响可能出现同一查询的其他消费者组。
为将用户赋予资源消费者组，需要使用DBMS_RESOURCE_MANAGER程序包的SET_INITIAL_CONSUMER_GROUP过程。SET_INITIAL_CONSUMER_GROUP过程的语法如下：
SET_INITIAL_CONSUMER_GROUP
(user IN VARCHAR2,
consumer_group IN VARCHAR2)
如果用户从来没有通过SET_INITIAL_CONSUMER_GROUP过程建立初始消费者组集，则自动将用户登记到名为DEFAULT_CONSUMER_GROUP的资源消费者组中。
为在数据库中启用资源管理器，将RESOURCE_MANAGER_PLAN数据库初始参数设置为实例的资源计划的名称。资源计划可具有子计划，因此可在实例中创建多层资源分配。如果未设置RESOURCE_MANAGER_PLAN参数的值，实例就不会执行资源管理。
使用RESOURCE_MANAGER_PLAN初始参数，可动态改变实例，使其使用不同的资源分配计划。例如，可为白天的用户（DAYTIME_USERS）创建一个资源计划，而为批处理用户（BATCH_USERS）创建另一个资源计划。可创建一个作业，在每天早上6:00时执行如下的命令：
alter system set resource_manager_plan = 'DAYTIME_USERS';
然后在晚上的一个设置时间，改变消费者组，使批处理用户受益：
alter system set resource_manager_plan = 'BATCH_USERS';
这样，不需要关闭并重新启动实例就可以改变实例的资源分配计划。
采用这种方式使用多个资源分配计划时，需要确保没有无意中在错误的时间使用错误的计划。例如，如果数据库在调度计划改变时停机，改变计划分配的作业可能就不会执行。这对用户有什么影响？如果使用多个资源分配计划，则需要考虑在错误时间使用错误计划的影响。为避免这种问题，应该努力将使用中的资源分配计划的数量减到最少。
除了本节中显示的示例和命令外，还可以更新已有的资源计划（通过UPDATE_PLAN过程）、删除资源计划（通过DELETE_PLAN），以及级联删除资源计划及其所有子计划和相关的资源消费者组（通过DELETE_PLAN_CASCADE）。可分别通过UPDATE_CONSUMER_ GROUP和DELETE_CONSUMER_GROUP过程更新和删除资源消费者组。可通过UPDATE_ PLAN_DIRECTIVE更新资源计划指令，通过DELETE_PLAN_DIRECTIVE删除资源计划指令。
在修改资源计划、资源消费者组和资源计划指令时，应在实现之前测试这种变化。为测试所做的改动，需要为工作创建一个未决区域。创建未决区域时应可以使用DBMS_RESOURCE_ MANAGER程序包的CREATE_PENDING_AREA过程。完成改动后，使用VALIDATE_PENDING_AREA过程来检查新的计划、子计划和指令集的有效性，然后可以提交改动（通过SUBMIT_ PENDING_AREA）或清除改动（CLEAR_PENDING_AREA）。管理未决区域的过程没有任何输入变量，因此，使用下面的语法验证和提交未决区域：
execute DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
plan => 'DEVELOPERS', -
GROUP_OR_SUBPLAN => 'SYS_GROUP', -
COMMENT => 'System USER SESSIONS AT LEVEL 1', -
MGMT_P1 => 90, -
PARALLEL_DEGREE_LIMIT_P1 => 16);
execute DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
execute DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
1．切换消费者组
CREATE_PLAN_DIRECTIVE过程的3个参数允许会话在满足资源限制时切换消费者组。如5.1节所述，CREATE_PLAN_DIRECTIVE过程的参数包括SWITCH_GROUP、SWITCH_ TIME和SWITCH_ESTIMATE。
SWITCH_TIME值是在将作业切换到另一个消费者组前它可以运行的时间，以秒为单位。默认的SWITCH_TIME值是NULL（表示无限制）。应将SWITCH_GROUP参数值设置为某个组，在达到SWITCH_TIME限制时该会话将切换到这个组。SWITCH_GROUP默认为NULL。如果将SWITCH_GROUP的值设置为CANCEL_SQL，在满足切换标准时，当前的调用将被终止。如果SWITCH_GROUP的值为KILL_SESSION，则在满足切换标准时，会话将被删除。
可使用第三个参数SWITCH_ESTIMATE来告诉数据库，在数据库调用开始执行前切换该操作的消费者组。如果将SWITCH_ESTIMATE设置为TRUE，Oracle将使用它的执行时间估计值自动切换操作的消费者组，而非等待它达到SWITCH_TIME值。
可使用组切换特性来最小化数据库中长期运行作业的影响。可使用不同层次的系统资源访问来配置消费者组，并且定制它们以支持快速作业和长期运行的作业：达到SWITCH_TIME限制的作业将在它们继续执行前重定向到适当的组。
2．使用SQL配置文件
从Oracle 10g开始，可使用SQL配置文件（SQL profile）进一步细化优化器所选择的SQL执行计划。在尝试调整无法直接访问的代码（例如打包的应用程序中的代码）时，SQL配置文件尤为有用。SQL配置文件由针对语句的统计信息组成，该配置文件允许优化器了解更多有关执行计划中的准确选择和步骤成本的信息。
SQL配置文件是第8章中描述的自动调整功能的一部分。一旦接受SQL配置文件的推荐，则将其存储在数据字典中。为控制SQL配置文件的使用率，可使用分类属性。可参阅第8章了解使用自动化工具检测和诊断SQL性能问题的更多细节。
5.2.2 调整数据库对象的大小
为数据库对象选择适当的空间分配非常重要。开发人员应在创建第一个数据库对象之前先估计空间需求。然后，可根据实际的使用率统计信息来细化空间需求。下面将介绍表、索引和群集的空间估计方法，以及为PCTFREE和PCTUSED选择适当设置的方法。
注意：
在创建表空间时可启动自动段空间管理（Automatic Segment Space Management，ASSM），但不能为已有的表空间启用这个特性。如果正在使用自动段空间管理，Oracle将忽略PCTUSED、FREELISTS和FREELIST GROUPS参数。所有新的表空间都应使用ASSM并在本地管理。
1．调整对象大小的原因
调整数据库对象大小主要有以下3个原因：
●预先分配数据库中的空间，从而最小化将来管理对象空间需求所需要的工作量。
●减少由于过多分配空间而浪费的空间。
●提高另一个段重用已删除空闲盘区的可能性。
通过遵循下面介绍的调整大小方法学，可实现所有这些目标。该方法学基于Oracle中分配空间给数据库对象的内部方法。该方法学不依赖于详细的计算，而依赖于近似值，这将极大地简化调整大小的过程，同时简化数据库的长期维护工作。
2．空间计算的黄金规则
保持空间计算简单、普遍适用，并在整个数据库中保持一致性。相对于执行Oracle可能总是会忽略的、特别详细的空间计算，在这些工作时间中总是可以采用更高效的方法。即使执行最严格的调整大小计算，也无法确定Oracle如何将数据加载到表或索引中。
下面将介绍如何简化空间估计过程，从而有时间执行更有用的DBA功能。无论正在为字典管理的表空间生成DEFAULT STORAGE值，还是为本地管理的表空间生成盘区大小，都应该遵循这些过程。
3．空间计算的基本规则
Oracle在分配空间时遵循一些内部规则：
●Oracle只分配整个块，而非块的局部。
●Oracle分配成组的块，而不是单个的块。
●Oracle可能分配较大的或较小的成组块，这取决于表空间中的可用空闲空间。
最终目标应该是使用Oracle空间分配方法，而不是违背它们。如果使用一致的盘区大小，可在很大程度上将空间分配委托给Oracle完成。
4．盘区大小对性能的影响
减少表中盘区的数量不会直接改善性能。有些情况下（例如在并行查询环境中），表中具有多个盘区可以极大地减少I/O争用，并增强性能。无论表中盘区的数量是多少，都需要适当地调整盘区的大小。从Oracle Database 10g开始，如果表空间中的对象大小不同，则应该依赖自动（系统管理的）盘区分配。除非知道每个对象需要的精确空间量，以及盘区的数量和大小，否则在创建表空间时应使用AUTOALLOCATE，如下例所示：
create tablespace users12
datafile '+DATA' size 100m
extent management local autoallocate;
EXTENT MANAGEMENT LOCA子句是CREATE TABLESPACE的默认设置，AUTOALLOCATE是具有本地盘区管理的表空间的默认设置。
Oracle以两种方法从表中读取数据：通过ROWID（通常直接跟在一个索引访问之后）以及通过完整表扫描。如果通过ROWID读取数据，表中的盘区数量就不是影响读取性能的因素。Oracle将从它的物理位置（在ROWID中指定）读取每一行，并且检索数据。
如果通过完整表扫描读取数据，盘区的大小会在很小的程度上影响性能。通过完整表扫描读取数据时，Oracle一次读取多个块。一次读取的块数量通过DB_FILE_MULTIBLOCK_READ_ COUNT数据库设置初始参数进行设置，并受操作系统的I/O缓冲区大小的限制。例如，如果数据库块大小是8KB，操作系统的I/O缓冲区大小为128KB，则可在完整表扫描期间每次最多读取16个块。这种情况下，设置DB_FILE_MULTIBLOCK_READ_COUNT的值大于16不会影响完整表扫描的性能。理想情况下，DB_FILE_MULTIBLOCK_READ_COUNT * BLOCK_SIZE的积应该是1MB。
5．估计表的空间需求
可使用DBMS_SPACE程序包的CREATE_TABLE_COST过程来估计表的空间需求。该过程根据如下属性来确定表的空间需求：表空间存储参数、表空间块大小、行数以及平均的行长度。该过程可用于字典管理的表空间和本地管理的表空间。
提示：
当使用Oracle Cloud Control 12c（或旧版本中的Oracle Enterprise Manager DB Control）创建新表时，单击Estimate Table Size按钮，可以针对给定的估计行数，估计表大小。
有两种版本的CREATE_TABLE_COST过程（重载该过程，从而可以通过两种方法使用相同的过程）。第一个版本有4个输入变量：TABLESPACE_NAME、AVG_ROW_SIZE、ROW_COUNT和PCT_FREE，它的输出变量是USED_BYTES和ALLOC_BYTES。第二个版本的输入变量是TABLESPACE_NAME、COLINFOS、ROW_COUNT和PCT_FREE，它的输出变量是USED_BYTES和ALLOC_BYTES。表5-1列出各个变量的描述。
表5-1 各个变量的描述
例如，如果有一个名为USERS的已有表空间，则可估计此表空间中新表所需要的空间。在下面的示例中，用传递给平均行大小、行计数和PCTFREE等参数的值，执行CREATE_TABLE_COST过程。通过DBMS_OUTPUT.PUT_LINE过程定义并显示USED_BYTES和ALLOC_BYTES变量：
这个PL/SQL块的输出将根据这些变量设置来显示已经使用的和分配的字节。在创建表之前，针对空间设置的多种组合，可方便地计算出期望的空间利用率。下面是前面该例的输出：
Used bytes: 66589824
Allocated bytes: 66589824
PL/SQL procedure successfully completed.
注意：
只有使用SET SERVEROUTPUT ON命令才能在SQL*Plus会话中显示脚本的输出。
6．估计索引的空间需求
同样，可使用DBMS_SPACE程序包的CREATE_INDEX_COST过程来估计索引的空间需求。这一过程根据如下属性来确定表的空间需求：表空间存储参数、表空间块大小、行数以及平均行长度。该过程适用于字典管理的表空间和本地管理的表空间。
对于索引空间估计，输入变量包括创建索引所执行的DDL命令以及本地计划表的名称（如果存在一个这样的表）。索引空间的估计依赖于相关表的统计信息。在开始空间估计过程之前，应该确保这些统计信息是正确的，否则结果就会被曲解。
表5-2描述了CREATE_INDEX_COST过程的参数。
表5-2 CREATE_INDEX_COST过程的参数
因为CREATE_INDEX_COST过程根据表的统计信息获得其结果，所以只有在创建、加载和分析表后才可以使用该过程。下面的示例估计BOOKSHELF表上的新索引所需要的空间。表空间的名称是CREATE INDEX命令的一部分，该命令作为DDL变量值的一部分被传递给CREATE_INDEX_COST过程。
该脚本的输出将为指定的雇员名索引显示已经使用的和分配的字节值。
Used bytes = 749
Allocated bytes = 65536
PL/SQL procedure successfully completed.
7．估计合适的PCTFREE值
PCTFREE值代表每个数据块中保留的用作空闲空间的百分比。当存储在数据块中的行的长度增长时，使用这个空间，数据块中行的长度增长或由于更新以前的NULL字段，或由于将已有的值更新为较长的值。当NUMBER列的精度增加或VARCHAR2列的长度增加时，在更新期间，行的大小会增加（因此需要在数据块中移动行）。
任一个PCTFREE值都不可能适合于所有数据库中的所有表。为简化空间管理，通常选择一组一致的PCTFREE值：
●对于键值很少改变的索引：2
●对于行很少改变的表：2
●对于行频繁改变的表：10~30
在行很少改变的情况下，为什么需要维护表或索引中的空闲空间呢？Oracle需要块中的空间来执行块维护功能。如果没有足够可用的空闲空间（例如，为支持在并发插入期间的大量事务头），Oracle将临时分配块的部分PCTFREE区域。应选择支持这种空间分配的PCTFREE值。为给INSERT密集表中的事务头保留空间，应设置INITRANS参数为非默认值（最小为2）。一般来说，PCTFREE区域应该大到足够保存一些数据行。
注意：
对于任何数据块，Oracle自动允许最多255个并发的更新事务，这取决于块中可用的空间。事务项占用的空间不会超过块的一半。
因为PCTFREE与应用程序中的更新方法紧密联系，所以确定它的设置值是否足够是一个相当简单的过程。PCTFREE设置控制存储在表块中的行数。为查看是否已经正确设置PCTFREE，首先确定块中行的数量。可使用DBMS_STATS包来收集统计信息。如果PCTFREE设置得过低，由于总行数增加，迁移行数将稳定增加。可监控数据库的V$SYSSTAT视图（或自动工作负荷存储库），查看“表读取连续行”动作的增加值，这些表明了数据库针对一行访问多个块的需求。
如果整行不能放入空块，或行中的列数超过255，将出现“链接行（Chained row）”。因此，行的一部分存储在第一个块中，行的其余部分存储在后续的一个或多个块中。
注意：
当由于PCTFREE区域中的空间不够而移动行时，这种移动称为“行迁移”。行迁移将影响事务的性能。
尽管DBMS_STATS过程功能强大，但它并不能收集链接行的统计信息。虽然在其他方面赞成使用DBMS_STATS过程，而不赞成使用ANALYZE命令，但仍然可以使用ANALYZE命令来显示链接行，如下例所示：
analyze table employees list chained rows;
注意：
对于支持大量INSERT的索引，如果INSERT始终在索引的中间，PCTFREE可能需要高达50%。其他情况下，对于数字列增加值上的索引，10%通常便可满足需要。
8．反向键索引
在反向键索引（reverse key index）中，值是反向存储的，例如，2201的值存储为1022。如果使用标准索引，就会彼此靠近存储连续的值。而在反向键索引中，则不会彼此靠近存储连续的值。如果查询没有经常执行范围扫描，并且关注的是索引中的I/O争用（在RAC数据库环境中）或并发争用（ADDM中的buffer busy waits统计信息），反向键索引就是值得考虑的调整解决方案。在调整反向键索引的大小时，遵循的方法与调整标准索引大小所用的方法是相同的，本章前面已经介绍过这种方法。
但反向键索引也有缺点：PCTFREE需要一个很高的值，以便允许频繁地插入，且与标准的B树索引相比，反向键索引常常必须重新构建。
9．调整位图索引的大小
如果创建位图索引，Oracle将动态压缩生成的位图。位图的压缩可能会节省实际的存储空间。为估计位图索引的大小，应使用本章前面提供的方法来估计相同列上标准（B-树）索引的大小。计算B-树索引的空间需求后，需要将这个大小除以10才能确定这些列的位图索引最可能的最大尺寸。一般来说，基数低的位图索引在相当的B-树索引大小的2%~10%之间。位图索引的大小将取决于索引列中不同值的可变性和数量。如果位图索引创建在高基数列上，则位图索引占用的空间可能会超过相同列上B-树索引的大小！
注意：
位图索引只能用于Oracle企业版和标准版1。
10．调整索引组织表的大小
索引组织表按主键的顺序存储。索引组织表的空间需求与所有表列上的索引的空间需求几乎相同。空间估计的差别在于计算每一行所使用的空间，因为索引组织表没有RowID。
下面的程序清单给出了对索引组织表中每一行的空间需求的计算（注意，该存储估计针对整个行，包括它的外部存储）：
Row length for sizing = Average row length
+ number of columns
+ number of LOB columns
+ 2 header bytes
在将CREATE_TABLE_COST过程用于索引组织表时，输入该值作为行长度。
11．调整包含大型对象（LOB）的表的大小
BLOB或CLOB数据类型中的LOB数据通常和主表分开存储。可使用CREATE TABLE命令的LOB子句来指定LOB数据的存储属性，如不同的表空间。在主表中，Oracle存储指向LOB数据的LOB定位器值。在外部存储LOB数据时，控制数据（LOB定位器）的36～86个字节保持在行中内联。
Oracle并非总是将LOB数据与主表分开存储。一般来说，只有在LOB数据与LOB定位器值总共超过4000B时，才将LOB数据与主表分开存储。因此，如果存储较短的LOB值，就需要考虑它们对主表存储的影响。如果LOB值少于32 768个字符，在Oracle Database 12c中，就能使用VARCHAR2数据类型而不是LOB数据类型存储数据；但那些VARCHAR2列作为SecureFile LOB在行外存储。
注意：
在Oracle Database 12c中，如果设置初始参数MAX_STRING_SIZE=EXTENDED，可将VARCHAR2列长最大定义为32 767字符。
如果LOB的大小等于或小于4000B，并要明确地指定LOB驻留在哪里，则使用CREATE TABLE句的LOB存储子句中的DISABLE STORAGE IN ROW或ENABLE STORAGE IN ROW子句。如果LOB内联存储，且LOB的值起初小于4000B，则它将移动到外部。如果外部LOB变得小于4000B，则仍存储在外部。
12．调整分区大小
可创建表的多个分区。在分区表中，多个单独的物理分区组成表。例如，SALES表可能有4个分区：SALES_NORTH、SALES_SOUTH、SALES_EAST和SALES_WEST。应该使用本章前面描述的调整表大小的方法来调整每个分区的大小，并使用调整索引大小的方法来调整分区索引的大小。
5.2.3 使用全局临时表
可创建全局临时表（Global Temporary Table，GTT），在应用程序处理期间保存临时数据。表的数据可以是针对事务的，也可用于某个用户会话期间。当事务或会话完成时，从表中去除该数据。
为创建GTT，可使用CREATE GLOBAL TEMPORARY TABLE命令。为在事务结束时自动删除行，可指定ON COMMIT DELETE ROWS，如下所示：
create global temporary table my_temp_table
(name varchar2(25),
street varchar2(25),
city varchar2(25))
on commit delete rows;
然后，可在应用程序处理期间将行插入MY_TEMP_TABLE。在提交时，Oracle将截取MY_TEMP_TABLE。为在会话持续期间保留这些行，应指定ON COMMIT PRESERVE ROWS。
从DBA的角度看，需要知道应用程序开发人员是否正在使用这种特性。如果正在使用，则应考虑在处理期间临时表所需要的空间。临时表通常用于改进复杂事务的处理速度，因此可能需要权衡性能优点和空间成本。可在临时表上创建索引，进一步改进处理性能，但这是以增加空间使用率为代价的。
注意：
直到第一次在其中插入内容，临时表及其索引才需要空间。当它们不再使用时，则释放分配给它们的空间。另外，如果正在使用PGA_AGGREGATE TARGET，则Oracle试图在内存中创建表，且根据需要只写到临时空间。