|
1
4
在很大程度上,我认为你一直在做删除。 您对在您的案例中使用分区的困难的评论可能会阻止它们被有效地使用(根据记录的类型使用不同的删除日期),但是您可以在您可以分区的记录上创建一个“delete date”列吗?这样做的缺点是更新成本很高,因为更改删除日期可能会导致行迁移,所以您的更新实际上是作为delete和insert实现的。 由于引用完整性问题,即使这样,您也不能使用DDL分区操作来删除旧数据,但是分区仍然可以用于对要删除的行进行物理群集,以便需要修改的块更少,以便删除它们,减轻对缓冲区缓存的影响。 |
|
|
2
0
删除也没那么糟, 如果重新生成索引 . Oracle将恢复不再包含数据的页面。 但是,从8i开始(很可能仍然如此),它将无法正确恢复不再包含有效引用的索引页。更糟糕的是,由于索引叶是链接的,您可能会遇到这样的情况:它将开始遍历叶节点以查找行。这将导致性能显著下降:通常需要几秒钟的查询可能需要几分钟。下降也很突然:有一天会好,第二天不会。 我在一个使用了增加密钥和定期删除数据的应用程序中发现了这种行为(甲骨文有一个bug,其他人也有)。我们的解决方案是反转部分密钥,但这对日期没有帮助。 |
|
|
3
0
如果临时停用索引,执行删除操作,然后重新生成索引,会怎么样?它会提高删除的性能吗?当然,在这种情况下,必须确保脚本正确,并确保正确的删除顺序和引用完整性。 |
|
|
4
0
我们有同样的问题,使用同样的策略。 如果情况变得非常糟糕(索引、表的分配非常零碎,…),我们将尝试应用空间回收操作。 表必须允许行移动(类似于闪回): alter table ttt启用行移动; 改变表ttt缩小空间; 然后重建所有索引。 我不知道你对维护窗口是怎么看的,如果应用程序必须一直可用,那就更难了,如果不是,你可以在离线时做一些“重新打包”。alter table ttt move tablespace sss“在重写表时,会做很多工作来清理混乱。您还可以指定新的存储参数,如数据块管理、大小…看一下文件。 我使用这样的脚本为整个数据库创建脚本:
|