由该表占用的块的数量 (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 从诸如表重组之类的日常任务中解脱出来。联机段收缩特性在估计内部碎片和降低段的最高使用标记方面特别有用，能显著地减少全表扫描的成本。
么获取关于 SHRINK 操作的更多信息，请参阅 Oracle 数据库 SQL 参考 中的这部分的内容。可以在 PL/SQL 包和类型参考的第 88 章中了解到有关 DBMS_SPACE 包的更多信息。为了对 Oracle 数据库 10g中的所有新的空间管理特性作一个全面的回顾，可以阅读技术白皮书自我管理的数据库：积极的空间和模式对象管理。最后，在线提供了一个 Oracle 数据库 10g 空间管理的演示。
下一周：可传输的表空间
返回系列索引
书签
