您好，穆拉利，

是的，除非您更改了表的压缩设置，否则我也看不出为什么Inplace Reorg应该永久增加表的大小。

Inplace Reorg释放了 桌子末端的空间。 在Inplace Reorg的末尾，将执行截断并将表末尾的空间返回到表空间。 您是否完成了Inplace Reorg或在中间某个地方中止了它？

我不是Inplace Reorg的忠实拥护者，因此如果有必要，始终建议使用DB6CONV来重组表。 Db6CONV使用ADMIN_MOVE_TABLE重建表。 这具有许多优点。 将创建一个新的压缩字典，将重新组织或内联LOB数据……

注意

Frank

Hi Frank，

感谢您的投入。

您完成了Inplace Reorg还是中途取消了它？

是的，由于性能问题，我们已中止/暂停了在线重组活动。

但是现在我担心的是由于此活动导致数据库的增长。

是否可以重新获得空间？ 如果是，请指导我如何实现。

之前，我们使用admin_move_table过程来重建表，但是由于生产系统中的DR设置处于活动状态，因此我们观察到备用数据库中存在不一致（表不可访问）的情况。

感谢和问候，

Murali

嗨，穆拉利，

我不知道如何在不完成任何REORG的情况下重新获得空间。

在ADMIN_MOVE_TABLE测试中使用LOAD？ 当无法在备用数据库上访问LOAD日志文件时，这可以将表置于备用数据库无法访问的模式。

标准的ADMIN_MOVE_TABLE运行显然可以生成更多的日志量，但不应将表置于不可访问的状态 模式。

问候

弗兰克

嗨弗兰克，

我们可以执行重组活动或ADMIN_MOVE_TABLE过程来重新获得空间吗？

来到ADMIN_MOVE_TABLE过程，我们成功使用此过程回收了数据库上的空间，而在生产系统（主系统）中没有任何性能问题，但是在执行故障转移操作时遇到了问题（表不可访问）。

最后，我们已中止故障转移操作，并通过主数据库联机备份和重建灾难恢复站点还原了备用数据库。

这就是为什么我们不选择ADMIN_MOVE_TABLE过程的原因。

感谢和问候，

Murali

您好，穆拉利，

我仍然不明白为什么ADMIN_MOVE_TABLE会引起问题。 我只怀疑LOAD在这里发挥了作用。 我将问题留给ADMIN_MOVE_TABLE/HADR专家解决。

致谢

Frank

我与我们的ADMIN_MOVE_TABLE专家再次确认。 他们同意我的观点。

（1）如果使用得当，ADMIN_MOVE_TABLE应该不会引起任何问题。

如果使用了选项COPY_USE_LOAD并且备用数据库无法访问副本，则可能会出现问题 文件，或者备用数据库无法为ADMIN_MOVE_TABLE创建的表副本提供足够的空间。

（2）如果表的定义未更改，就地重组不应增加表的大小。

请检查表压缩选项是否已更改或表的APPEND MODE是否已激活。

注意事项

弗兰克