输出结果如下:[@more@]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 包,使这项任务变得极其微不足道。