我们使用Oracle 19 c数据库。客户希望我们在线重新组织一些表，这些表中的CLOB字段存储在安全文件中。没有“低负载”时间框架，因此每次联机重新组织都会失败，并显示ORA-1555.在DBA_LOBS视图中，PCTVERSION、RETENTION字段为空。所以问题是我们怎样才能增加在线重组成功完成的机会？你好，达克伍德
gxwragnw1#
只有当你删除了在没有被重用的块中打开空间的时候，或者有行链接，或者使用压缩并且一些行已经被解压缩的时候，reorg才会释放空间，或者在同一块中的行上进行大量并发更新，（不太可能）。对于大多数表来说，除非要实现更改，否则重新组织段实际上没有任何好处（移动到一个新的文件夹，压缩，减少PCTFREE，等等..）.正常的删除和常规的插入使用空间足够好，你挤出的东西很快就会回到它的当前状态。如果释放空间的目标是 * 性能 *（而不是节省空间），那么唯一有帮助的情况是，如果你的查询正在进行全表扫描，并且上述情况之一已经显著地扩大了表（或者你有大量的行链接）。如果你的查询使用索引，那么表的大小不会有什么区别。如果你决定你真的需要做一个重组，一个简单的片段重组是用ALTER TABLE MOVE命令完成的：ALTER TABLE mytable MOVE个这将移动表段以及它所拥有的任何LOB。“move”的意思是将它移动到新的扩展区，到新的分区。这样做将重新创建物理表和LOB段，这是在块级别完成物理重组的原因。它不必涉及将其移动到不同的分区（如果需要，可以）。现在，上面的裸命令将是单线程的，因此在大型表上运行速度很慢，会阻止应用在运行时对其执行任何DML，并且会使索引无法使用，需要在之后手动重建索引。所有这些对于大型、忙碌的表来说都是一个问题。因此，在您的情况下，我们需要添加一些额外的选项。您可以使用并行性来加快速度（和NOLOGGING，如果可以接受的话，它通常不在生产数据库中）。您可以使用UPDATE INDEXES让它自动为您重建索引，您也可以在DML发生时使用ONLINE选项进行重建，这听起来像是在您的情况下您可能需要它）：ALTER TABLE mytable MOVE PARALLEL (DEGREE 8) ONLINE UPDATE INDEXES个如果你采用这样的并行性，你可能能够足够快地完成工作，以避免ORA-1555。如果你有很多可用的CPU内核，增加并行性到任何你可以摆脱的程度。16，32，64，无论什么，只要留下足够的CPU，让你的其他工作负载不受影响。
ALTER TABLE MOVE
ALTER TABLE mytable MOVE
NOLOGGING
UPDATE INDEXES
ONLINE
ALTER TABLE mytable MOVE PARALLEL (DEGREE 8) ONLINE UPDATE INDEXES
g0czyy6m2#
同时我找到了答案。如果还原表空间中有可用空间，Oracle会自动优化还原保留时间，因此UNDO_RETENTION参数在技术上已过时，不应修改。但是...这对LOB无效。在并发DML查询的情况下：即使DML修改了LOB，时间短于“UNDO_RETENTION秒”的DML查询也不会因ORA-1551快照太旧而失败。持续时间长于“UNDO_RETENTION秒”的查询可能会失败。如果你想要不同的行为，你需要增加“N秒”。https://docs.oracle.com/en/database/oracle/oracle-database/23/adlob/automatic-securefiles-shrink1.html#GUID-9294F4FB-FFB4-4586-8376-BFB145EEDC40因此，解决方案是将UNDO_RETENTION从默认的900秒增加到BIG值，并确保有足够的空间。此致，达沃。
o75abkj43#
我猜你正在使用DBMS_REDEFINITION？在任何情况下，在线重组的第一阶段都是当前数据的“快照”，它提供了一个基础，我们可以在以后应用增量来保持流程的最新状态，同时仍然在线。所以实际上你需要一个撤销保留（和类似大小的撤销保留），只要它在你的表上做一个“选择表”。您可以使用数据的子集对副本进行实验，并从那里进行推断-它应该是合理的线性。还值得研究一下LOB的一些缓存/日志选项，看看调整这些选项是否能提高CTAS的性能。
3条答案
按热度按时间gxwragnw1#
只有当你删除了在没有被重用的块中打开空间的时候，或者有行链接，或者使用压缩并且一些行已经被解压缩的时候，reorg才会释放空间，或者在同一块中的行上进行大量并发更新，（不太可能）。对于大多数表来说，除非要实现更改，否则重新组织段实际上没有任何好处（移动到一个新的文件夹，压缩，减少PCTFREE，等等..）.正常的删除和常规的插入使用空间足够好，你挤出的东西很快就会回到它的当前状态。
如果释放空间的目标是 * 性能 *（而不是节省空间），那么唯一有帮助的情况是，如果你的查询正在进行全表扫描，并且上述情况之一已经显著地扩大了表（或者你有大量的行链接）。如果你的查询使用索引，那么表的大小不会有什么区别。
如果你决定你真的需要做一个重组，一个简单的片段重组是用
ALTER TABLE MOVE命令完成的：ALTER TABLE mytable MOVE个这将移动表段以及它所拥有的任何LOB。“move”的意思是将它移动到新的扩展区，到新的分区。这样做将重新创建物理表和LOB段，这是在块级别完成物理重组的原因。它不必涉及将其移动到不同的分区（如果需要，可以）。
现在，上面的裸命令将是单线程的，因此在大型表上运行速度很慢，会阻止应用在运行时对其执行任何DML，并且会使索引无法使用，需要在之后手动重建索引。所有这些对于大型、忙碌的表来说都是一个问题。因此，在您的情况下，我们需要添加一些额外的选项。您可以使用并行性来加快速度（和
NOLOGGING，如果可以接受的话，它通常不在生产数据库中）。您可以使用UPDATE INDEXES让它自动为您重建索引，您也可以在DML发生时使用ONLINE选项进行重建，这听起来像是在您的情况下您可能需要它）：ALTER TABLE mytable MOVE PARALLEL (DEGREE 8) ONLINE UPDATE INDEXES个如果你采用这样的并行性，你可能能够足够快地完成工作，以避免ORA-1555。如果你有很多可用的CPU内核，增加并行性到任何你可以摆脱的程度。16，32，64，无论什么，只要留下足够的CPU，让你的其他工作负载不受影响。
g0czyy6m2#
同时我找到了答案。
如果还原表空间中有可用空间，Oracle会自动优化还原保留时间，因此UNDO_RETENTION参数在技术上已过时，不应修改。
但是...这对LOB无效。在并发DML查询的情况下：
即使DML修改了LOB，时间短于“UNDO_RETENTION秒”的DML查询也不会因ORA-1551快照太旧而失败。持续时间长于“UNDO_RETENTION秒”的查询可能会失败。
如果你想要不同的行为，你需要增加“N秒”。
https://docs.oracle.com/en/database/oracle/oracle-database/23/adlob/automatic-securefiles-shrink1.html#GUID-9294F4FB-FFB4-4586-8376-BFB145EEDC40
因此，解决方案是将UNDO_RETENTION从默认的900秒增加到BIG值，并确保有足够的空间。
此致，
达沃。
o75abkj43#
我猜你正在使用DBMS_REDEFINITION？在任何情况下，在线重组的第一阶段都是当前数据的“快照”，它提供了一个基础，我们可以在以后应用增量来保持流程的最新状态，同时仍然在线。
所以实际上你需要一个撤销保留（和类似大小的撤销保留），只要它在你的表上做一个“选择表”。
您可以使用数据的子集对副本进行实验，并从那里进行推断-它应该是合理的线性。
还值得研究一下LOB的一些缓存/日志选项，看看调整这些选项是否能提高CTAS的性能。