当表空间大小受限时,即便通过delete带条件删除部分数据,被删除数据所使用的空间,依然不会被释放。此时想要再添加新的数据可能会得到“磁盘空间不足”的报错。
一.创建实验场景(注:数据页的大小16k)
1. 删除测试环境中的表和表空间(确保数据库中TEST表空间及TEST_CLOB表仅为本实验所用)
2. 创建test表空间,大小为64M,并且关闭表空间自动扩展功能
3. 创建表
4. 构建一个往test_clob表中增加大量数据匿名块
等待匿名块执行完成,会收到如下报错:
5. 查看插入了多少条记录
6. 删除500条记录
再插入数据,看看是否报错?
truncate好用,然而不能带条件删除,表空间大小本身又有局限,怎么才能将尚未释放的存储空间用起来?
二.解决方法:
7. 以DBA身份创建存储过程
以DBA身份调用上述存储过程
8. 再插入500条试试,看是否报错?
查一下总记录数
问题解决。
三.原理描述:
执行完第6步,添加数据时,依然收到“磁盘空间不足”的报错,因为这时候应用回滚段还未清理,磁盘空间并未释放。
未清理原因:由于需要根据回滚记录回溯、还原物理记录的历史版本信息,而不能在事务提交时立即清除当前事务产生的回滚记录。但是,如果不及时清理回滚段,可能造成回滚段空间的不断膨胀,占用大量磁盘空间。
DM基于上述原因提供了自动清理、回收回滚段空间的机制。采取保留回滚段一段时间,然后自动清理回滚段空间的方式。这个保留回滚段的时间长度由UNDO_RETENTION参数指定,默认数值是900,单位是秒。
这个参数是系统级动态参数,修改后即时生效,dm.ini 文件里可以查到它的值。
通过第7步,调整UNDO_RETENTION为1秒,并预留10秒给进程清理回滚段,之后将UNDO_RETENTION恢复为900秒。
以上便是关于如何通过调整UNDO_RETENTION参数值,迅速解决delete数据后不能及时释放表空间的问题的方法了。