- 个人理解闪回，只能闪回到undo_rentension 时间段内的数据。比如undo_rentension 设置为1800秒，那么就只能闪回到过去半小时的操作数据。
但在实际操作过程中，我用闪回恢复了一个小时delete 的数据，就询问闪回能够恢复多久之后的数据。 - 操作过程，下午1点30 删除一张表的数据 delete from table_name
- 两点五十后，发现有问题，就需要恢复，使用SELECT * FROM table_name as of timestamp TO_TIMESTAMP(‘2025-01-15 13:29:00’,‘yyyy-mm-dd hh24:mi:ss’); 恢复了删除的数据。
此时已经远大于undo_rentension 时间，所以询问闪回能够恢复多久之后的数据？
1 个赞
理论上是可以恢复设置参数时间段的数据，但是如果多版本的数据还没有被回收是可以查询更久时间的数据的，还有就是转储会影响对版本数据的回收
1 个赞
这个参数控制的是最小保证时间吧，不是严格控制这个时间范围内。
1 个赞
1、undo_retention 是一个租户级配置项，用于指定历史数据的保留时间。
默认值为 1800 秒（即 30 分钟），表示历史数据至少保留 30 分钟。
用户可以通过调整 undo_retention 的值来延长或缩短历史数据的保留时间。
闪回查询的时间范围：
闪回查询可以查询从当前时间 T 到 T - undo_retention 时间范围内的任意历史版本数据。
例如，如果当前时间是 2025-01-16 10:00:00，undo_retention 设置为 3600 秒（1 小时），则可以通过闪回查询获取 2025-01-16 09:00:00 到 2025-01-16 10:00:00 之间的历史数据。
2、闪回查询的限制
对 undo_retention 设置之前的数据无效：
如果 undo_retention 设置为 T0，则闪回查询只能对 T0 之后的数据生效，对 T0 之前的数据无效。
例如，如果 undo_retention 在 2025-01-16 09:00:00 设置为 3600 秒，则闪回查询只能查询 2025-01-16 09:00:00 之后的数据。
3、DDL 操作的影响：
如果在 T - undo_retention 时间段内有 DDL 操作（如添加列、删除列、删除表等），闪回查询的行为会受到影响：对于添加列操作，闪回查询会为新添加的列填充默认值。
对于删除列或删除表操作，闪回查询会报错，无法查询到被删除的列或表。
4、存储空间的影响：
闪回查询需要额外的存储空间来保留历史数据。如果调大 undo_retention，会导致存储空间的放大，因此需要留意存储空间的变化。
1 个赞
谢谢你的回复，但是用户使用delete 之前，没有设置 set global undo_retension的值，而默认1800 秒，却能够恢复到一小时之前的一张表，还是不知道事什么原因，可能就是用户使用delete 语句后，用户没有执行新的操作，不知道有没有关系哈
如果 undo_retention 设置为 30 分钟，但在过去 1 小时内没有发生转储，闪回查询可能仍然可以查询到 1 小时前的数据。