Oracle10G最佳20位新特性：段管理

　　用 Oracle 数据库 10g 通过回收浪费的空间、联机重组表格和评估增长的趋势，有效地在段中进行存储管理
　　
　　近来，有人要求我评估一个与 Oracle 数据库竞争的 RDBMS。在供应商的演示过程中，观众认为“最棒”的特性是，对联机重组的支持 — 该产品可以联机重新部署数据块，以使段的等价物更简洁，并且不会影响当前的用户。
　　
　　那时，Oracle 还没有在 Oracle9i 数据库中提供这种功能。但是现在，有了 Oracle 数据库 10g，就可以轻松地联机回收浪费的空间和压缩对象—正好适合于起步者。
　　
　　不过，在检验该特性之前，让我们看一看处理这项任务的“传统的”方法。
　　
　　当前惯例
　　考虑让我们看一个段，如一张表，其中填满了块，如图 1 所示。在正常操作过程中，删除了一些行，如图 2 所示。现有就有了许多浪费的空间：(i) 在表的上一个末端和现有的块之间，以及 (ii) 在块内部，其中还有一些没有删除的行。
　　　
　　图" 1：分配给该表的块。用灰色正方形表示行
　　Oracle 不会释放空间以供其他对象使用，有一条简单的理由：由于空间是为新插入的行保留的，并且要适应现有行的增长。被占用的最高空间称为最高使用标记 (HWM)，如图 2 所示。
　　　
　　图" 2：行后面的块已经删除了；HWM 仍保持不变
　　但是，这种方法有两个主要的问题：
　　当用户发出一个全表扫描时，Oracle 始终必须从段一直扫描到 HWM，即使它什么也没有发现。该任务延长了全表扫描的时间。
　　当用直接路径插入行时 — 例如，通过直接加载插入（用 APPEND 提示插入）或通过 SQL*Loader 直接路径 — 数据块直接置于 HWM 之上。它下面的空间就浪费掉了。
　　在 Oracle9i 及其以前的版本中，可以通过删除表，然后重建表并重新加载数据来回收空间；或通过使用 ALTER TABLE MOVE 命令把表移动到一个不同的表空间中来回收空间。这两种处理方式都必须脱机进行。另外，可以使用联机表重组特性，但是这需要至少双倍的现有表空间。
　　
　　在 10g中，该任务已经变得微不足道了；假如您的表空间中支持自动段空间管理 (ASSM),您现在可以缩小段、表和索引，以回收空闲块并把它们提供给数据库以作他用，让我们看看其中的缘由。
　　
　　10g 中的段管理方式
　　设想有一个表 BOOKINGS，它保存有经由 Web 站点的联机登记。当一个登记确认后，就会把它存储在一个存档表 BOOKINGS_HIST 中，并从 BOOKINGS 表中删除该行。登记和确认之间的时间间隔依据客户有很大的不同，由于无法从删除的行获得足够的空间，因此许多行就插入到了表的 HWM 之上。
　　
　　现在您需要回收浪费的空间。首先，准确地查明在可回收的段中浪费了多少空间。由于它是在支持 ASSM 的表空间中，您将不得不使用 DBMS_SPACE 包的 SPACE_USAGE 过程，如下所示：
　　declare
　　
　　l_fs1_bytes number;
　　l_fs2_bytes number;
　　l_fs3_bytes number;
　　l_fs4_bytes number;
　　l_fs1_blocks number;
　　l_fs2_blocks number;
　　l_fs3_blocks number;
　　l_fs4_blocks number;
　　l_full_bytes number;
　　l_full_blocks number;
　　l_unformatted_bytes number;
　　l_unformatted_blocks number;
　　begin
　　dbms_space.space_usage(
　　segment_owner　　　=> user,
　　segment_name　　　 => 'BOOKINGS',
　　segment_type　　　 => 'TABLE',
　　fs1_bytes　　　　　=> l_fs1_bytes,
　　fs1_blocks　　　　 => l_fs1_blocks,
　　fs2_bytes　　　　　=> l_fs2_bytes,
　　fs2_blocks　　　　 => l_fs2_blocks,
　　fs3_bytes　　　　　=> l_fs3_bytes,
　　fs3_blocks　　　　 => l_fs3_blocks,
　　fs4_bytes　　　　　=> l_fs4_bytes,
　　fs4_blocks　　　　 => l_fs4_blocks,
　　full_bytes　　　　 => l_full_bytes,
　　full_blocks　　　　=> l_full_blocks,
　　unformatted_blocks => l_unformatted_blocks,
　　unformatted_bytes　=> l_unformatted_bytes
　　);
　　dbms_output.put_line(' FS1 Blocks = '||l_fs1_blocks||' Bytes = '||l_fs1_bytes);
　　dbms_output.put_line(' FS2 Blocks = '||l_fs2_blocks||' Bytes = '||l_fs1_bytes);
　　dbms_output.put_line(' FS3 Blocks = '||l_fs3_blocks||' Bytes = '||l_fs1_bytes);
　　dbms_output.put_line(' FS4 Blocks = '||l_fs4_blocks||' Bytes = '||l_fs1_bytes);
　　dbms_output.put_line('Full Blocks = '||l_full_blocks||' Bytes = ||l_full_bytes);
　　end;
　　/
　　输出结果如下：
　　FS1 Blocks = 0 Bytes = 0
　　FS2 Blocks = 0 Bytes = 0
　　FS3 Blocks = 0 Bytes = 0
　　FS4 Blocks = 4148 Bytes = 0
　　Full Blocks = 2 Bytes = 16384
　　
　　这个输出结果显示有 4,148 个块，具有 75-100% 的空闲空间 (FS4)；没有其他空闲块可用。这里仅有两个得到完全使用的块。4,148 个块都可以回收。
　　
　　接下来，您必须确保该表支持行移动。如果不支持，您可以使用如下命令来支持它：
　　alter table bookings enable row movement;
　　
　　或通过 Administration 页上的 企业管理器 10g。您还要确保在该表上禁用所有基于行 id 的触发器，这是因为行将会移动，行 id 可能会发生改变。
　　
　　最后，您可以通过以下命令重组该表中现有的行：
　　alter table bookings shrink space compact;
　　
　　该命令将会在块内重新分配行，如图 3 所示，这就在 HWM 之下产生了更多的空闲块 — 但是 HWM 自身不会进行分配。
　　　
　　图" 3：重组行后的表中的块
　　在执行该操作后，让我们看一看空间利用率所发生的改变。使用在第一步展示的 PL/SQL 块，可以看到块现在是如何组织的：
　　FS1 Blocks = 0 Bytes = 0
　　FS2 Blocks = 0 Bytes = 0
　　FS3 Blocks = 1 Bytes = 0
　　FS4 Blocks = 0 Bytes = 0
　　Full Blocks = 2 Bytes = 16384
　　注意这里的重要改变：FS4 块（具有 75-100% 的空闲空间）的数量现在从 4,148 降为 0。我们还看到 FS3 块（具有 50-75% 的空闲空间）的数量从 0 增加到 1。但是，由于 HWM 没有被重置，总的空间利用率仍然是相同的。我们可以用如下命令检查使用的空间：
　　SQL> select blocks from user_segments where segment_name = 'BOOKINGS';
　　
　　BLOCKS
　　---------
　　4224
　　
　　由该表占用的块的数量 (4,224) 仍然是相同的，这是因为并没有把 HWM 从其原始位置移开。可以把 HWM 移动到一个较低的位置，并用如下命令回收空间：
　　alter table bookings shrink space;
　　
　　注意子句 COMPACT 没有出现。该操作将把未用的块返回给数据库并重置 HWM。可以通过检查分配给表的空间来对其进行测试：
　　SQL> select blocks from user_segments where segment_name = 'BOOKINGS';
　　
　　BLOCKS
　　----------
　　8
　　块的数量从 4,224 降为 8；该表内所有未用的空间都返回给表空间，以让其他段使用，如图 4 所示。
　　
　　图" 4：在收缩后，把空闲块返回给数据库
　　这个收缩操作完全是在联机状态下发生的，并且不会对用户产生影响。
　　
　　也可以用一条语句来压缩表的索引：
　　alter table bookings shrink space cascade;
　　联机 shrink 命令是一个用于回收浪费的空间和重置 HWM 的强大的特性。我把后者（重置 HWM）看作该命令最有用的结果，因为它改进了全表扫描的性能。
　　
　　找到收缩合适选择
　　在执行联机收缩前，用户可能想通过确定能够进行最完全压缩的段，以找出最大的回报。只需简单地使用 dbms_space 包中的内置函数 verify_shrink_candidate。如果段可以收缩到 1,300,000 字节，则可以使用下面的 PL/SQL 代码进行测试：
　　begin
　　if (dbms_space.verify_shrink_candidate
　　('ARUP','BOOKINGS','TABLE',1300000)
　　then
　　:x := 'T';
　　else
　　:x := 'F';
　　end if;
　　end;
　　/
　　PL/SQL 过程成功完成。
　　
　　SQL> print x
　　
　　X
　　--------------------------------
　　T
　　如果目标收缩使用了一个较小的数，如 3,000：
　　begin
　　if (dbms_space.verify_shrink_candidate
　　('ARUP','BOOKINGS','TABLE',30000)
　　then
　　:x := 'T';
　　else
　　:x := 'F';
　　end if;
　　end;
　　
　　变量 x 的值被设置成 'F'，意味着表无法收缩到 3,000 字节。
　　
　　推测一下来自索引空间的需要
　　现在假定您将着手在一个表上，或者也许是一组表上创建一个索引的任务。除了普通的结构元素，如列和单值性外，您将不得不考虑的最重要的事情是索引的预期大小 — 必须确保表空间有足够的空间来存放新索引。
　　
　　在 Oracle 数据库 9i 及其以前的版本中，许多 DBA 使用了大量的工具（从电子数据表到独立程序）来估计将来索引的大小。在 10g中，通过使用 DBMS_SPACE 包，使这项任务变得极其微不足道。让我们看一看它的作用方式。
　　
　　我们要求在 BOOKINGS 表的 booking_id 和 cust_name 列上创建一个索引。这个提议的索引需要多少空间呢？您所需要做的全部工作就是执行下面的 PL/SQL 脚本。
　　declare
　　l_used_bytes number;
　　l_alloc_bytes number;
　　begin
　　dbms_space.create_index_cost (
　　ddl => 'create index in_bookings_hist_01 on bookings_hist '||
　　'(booking_id, cust_name) tablespace users',
　　used_bytes => l_used_bytes,
　　alloc_bytes => l_alloc_bytes
　　);
　　dbms_output.put_line ('Used Bytes　　　= '||l_used_bytes);
　　dbms_output.put_line ('Allocated Bytes = '||l_alloc_bytes);
　　end;
　　/
　　The output is:
　　Used Bytes　　　= 7501128
　　Allocated Bytes = 12582912
　　
　　假定您想使用一些参数，而这些将参数潜在地增加了索引的大小，例如，指定 INITRANS 参数为 10。
　　declare
　　l_used_bytes number;
　　l_alloc_bytes number;
　　begin
　　dbms_space.create_index_cost (
　　ddl => 'create index in_bookings_hist_01 on bookings_hist '||
　　'(booking_id, cust_name) tablespace users initrans 10',
　　used_bytes => l_used_bytes,
　　alloc_bytes => l_alloc_bytes
　　);
　　dbms_output.put_line ('Used Bytes　　　= '||l_used_bytes);
　　dbms_output.put_line ('Allocated Bytes = '||l_alloc_bytes);
　　end;
　　/
　　输出结果如下：
　　Used Bytes　　　= 7501128
　　Allocated Bytes = 13631488
　　
　　注意通过指定一个更高的 INITRANS，而导致的分配字节的增加。使用这种方法可以容易地确定索引对存储空间的影响。
　　
　　但是，您应该意识到两个重要的警告。第一，该过程只适用于打开了 SEGMENT SPACE MANAGEMENT AUTO 的表空间。第二，包是依据表上的统计来计算索引的估计大小。因此，对表执行相对新的统计是非常重要的。但请注意：如果没有对表的统计，不会导致使用包时出错，但会产生一个错误的结果。
　　
　　估计表的大小
　　假定有一个名为 BOOKINGS_HIST 的表，它共有 30,000 行，各行长度较为平均，并且 PCTFREE 参数值为 20。如果想把参数 PCT_FREE 增至 30,表格的大小将增加多少？由于 30 是将 20 增长了 10%，表格大小将会按 10% 的比例增长吗？这个问题不要问自己，而要问 DBMS_SPACE 包内的 CREATE_TABLE_COST 过程。下面是您能够估计大小的方法：
　　declare
　　l_used_bytes number;
　　l_alloc_bytes number;
　　begin
　　dbms_space.create_table_cost (
　　tablespace_name => 'USERS',
　　avg_row_size => 30,
　　row_count => 30000,
　　pct_free => 20,
　　used_bytes => l_used_bytes,
　　alloc_bytes => l_alloc_bytes
　　);
　　dbms_output.put_line('Used:'||l_used_bytes);
　　dbms_output.put_line('Allocated:'||l_alloc_bytes);
　　end;
　　/
　　输出结果如下：
　　Used: 1261568
　　Allocated: 2097152
　　
　　要把表的 PCT_FREE 参数从 20 更改为 30，可以通过指定
　　pct_free => 30
　　
　　我们得到了输出结果：
　　Used: 1441792
　　Allocated: 2097152
　　
　　注意：使用的空间已从 1,261,568 增加到 1,441,792，这是由于 PCT_FREE 参数在用户数据的数据块中保留了较少的空间。增量大约有 14%，而不是所预期的 10%。使用这个包可以容易地计算出参数（如 PCT_FREE）对表大小的影响，或把该表移动到一个不同的表空间中的影响。
　　
　　预测段的增长
　　这是一个假日的周末，Acme 酒店期待有如同潮涌般的人群要求入住。作为一名 DBA，您正设法了解这种需求，以使您能够确保有足够的空间可供使用。如何预测表的空间利用率呢？
　　
　　只需询问 10g；您就会惊诧于它能够多么准确和聪明地为您作出预测。只需简单地发出查询:
　　select * from
　　table(dbms_space.OBJECT_GROWTH_TREND
　　('ARUP','BOOKINGS','TABLE'));
　　
　　函数 dbms_space.object_growth_trend() 将以 PIPELINEd 格式返回记录，这种格式可以通过 TABLE() 强制转换将其显示出来。输出如下：
　　
　　TIMEPOINT　　　　　　　　　　　SPACE_USAGE SPACE_ALLOC QUALITY
　　------------------------------ ----------- ----------- ------------
　　05-MAR-04 08.51.24.421081 PM　　　 8586959　　39124992 INTERPOLATED
　　06-MAR-04 08.51.24.421081 PM　　　 8586959　　39124992 INTERPOLATED
　　07-MAR-04 08.51.24.421081 PM　　　 8586959　　39124992 INTERPOLATED
　　08-MAR-04 08.51.24.421081 PM　　 126190859　1033483971 INTERPOLATED
　　09-MAR-04 08.51.24.421081 PM　　　 4517094　　 4587520 GOOD
　　10-MAR-04 08.51.24.421081 PM　　 127469413　1044292813 PROJECTED
　　11-MAR-04 08.51.24.421081 PM　　 128108689　1049697234 PROJECTED
　　12-MAR-04 08.51.24.421081 PM　　 128747966　1055101654 PROJECTED
　　13-MAR-04 08.51.24.421081 PM　　 129387243　1060506075 PROJECTED
　　14-MAR-04 08.51.24.421081 PM　　 130026520　1065910496 PROJECTED
　　输出结果多次清楚显示了 BOOKINGS 表的大小，就像在 TIMEPOINT 列、TIMESTAMP 数据类型中所显示的那样。SPACE_ALLOC 列显示了分配给该表的字节，而 SPACE_USAGE 列显示了已使用了多少字节。该信息是由自动负载存储或 AWR（参阅本系列中的第 6 周）每天进行收集的。在上面的输出中，数据是在 2004 年 3 月 9 日收集好的，就像 QUALITY 列的值 － "GOOD" 所指示的那样。那一天的空间分配和使用数字都是准确无误的。但是，以后的日子，该列的值将是 PROJECTED，这表示空间计算是由 AWR 功能依据收集的数据进行预测的 — 不是直接从段进行收集。
　　
　　注意 3 月 9 日以前的该列中的值 — 全都是 INTERPOLATED。换句话说，该值没有真正收集或预测的值，只是简单地依据适用于任何可用数据的使用图案添加进去的。最有可能的是当时没有数据，因此不得不添加该值。
　　
　　结论
　　有了段级操作，现在就能对段内空间如何使用进行细粒度的控制，可用来回收表内的空闲空间、联机重组表中的行以使之更压缩，以及更多操作。这些功能帮助 DBA 从诸如表重组之类的日常任务中解脱出来。联机段收缩特性在估计内部碎片和降低段的最高使用标记方面特别有用，能显著地减少全表扫描的成本。

原文转自：http://www.ltesting.net