DROP TENANT tenant_name PURGE是不是很多余，直接DROP TENANT tenant_name FORCE不就好了
1 个赞
主要还是考虑了租户是否进回收站，purge是不进回收站，force要进回收站。。如果没开回收站，那么这两个参数其实就没区别
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002015472
2 个赞
force是不进回收站吧
好问题，我也有此疑惑。
从文字描述上看，感觉开了回收站，好像也没啥区别吧？有空儿了可以做个实验试试~
1 个赞
感觉这里的文档内容可能有些问题。@OceanBase文档
文档里的 “延迟删除” 应该是物理备份恢复中的相关技术。大概意思是说备份 A 时间点的数据，在 B 时间点备份完成，如果有个数据库对象，在 A 之前创建，在 A 到 B 之间被删除，那么不能真正删除，而是需要假删除（延时删除，或者叫标记删除。可以做到不占用命名空间，但是没有被真删除），否则没办法顺利完成备份。不过到了 B 时间点之后，还是会被后台线程删除。
这个 “延迟删除” 的概念可能不应该在文档里暴露给用户的~
1 个赞
等一个大佬解答
个人猜测应该是说 purge 表示不进回收站；force 表示既不进回收站，也不延迟删除。
不过大家对 “延迟删除” 这四个字可能都没啥概念……
1 个赞
是的，延迟的意义是什么，为什么要延迟，还有个问题就是回收站的东西是不是只能全部清空不能部分清除，如果是这样，好像延迟删除是不是为了补充部分清除的情况。
看我在五楼的回复吧，印象中延迟删除是和备份恢复、主备库相关的东西，和回收站没有直接关系。
回收站里的东西可以通过指定 object name 或者 original name 去定向清除，官方文档之前有疏漏，现在不知道有没有改过来，推荐去看下 DBA 入门教程的 6.4 小节吧。
1 个赞
–租户延迟闪回参数
schema_history_recycle_interval = 10m --回收schema元数据的间隔时间
schema_history_expire_time = 7d 可用于设置需要保留的完整元数据历史数据的范围，也可用于设置延迟删除的租户的保留时间
外加两个参数？ 哪位老师能详情介绍下 延迟删除是个什么鬼！
2 个赞
这个purge是不是仅用于oracle租户
又想来下可能是一样的，我做个实验试一下
1 个赞
又想来下可能是一样的，我做个实验试一下
不是，什么租户都支持。
schema_history 是一类元数据系统表，用于存放数据库对象的所有历史变更记录，例如 oceanbase.__all_table_history。
select gmt_create, table_name, is_deleted
from oceanbase.__all_table_history
where table_id = 500006;
+----------------------------+--------------------------------+------------+
| gmt_create | table_name | is_deleted |
+----------------------------+--------------------------------+------------+
| 2024-12-20 11:45:02.385774 | t1 | 0 |
| 2024-12-26 09:51:32.237306 | __recycle_$_1_1735177892152232 | 0 |
| 2025-01-19 17:32:58.236961 | | 1 |
+----------------------------+--------------------------------+------------+
3 rows in set (0.02 sec)
例如上面这个例子里，可以通过 oceanbase.__all_table_history 看到 table_id = 500006 的表的所有变更记录。这张表的变更比较简单，就三次，一次是创建，一次是被删除进回收站，一次是从回收站中被清空。
history 表对应的是非 history 表，也就是 oceanbase.__all_table，这张表只能看到数据库对象当前的元信息，如果对象被从回收站清空了，就啥也看不到了。
-- 清空回收站，500006 就看不到了。
obclient> select gmt_create, table_name
from oceanbase.__all_table where table_id = 500006;
Empty set (0.01 sec)
-- 还活着的表，只能看到最新状态。
obclient> select gmt_create, table_name
from oceanbase.__all_table where table_id = 500008;
+----------------------------+------------+
| gmt_create | table_name |
+----------------------------+------------+
| 2024-12-26 09:51:34.078919 | t1 |
+----------------------------+------------+
1 row in set (0.01 sec)
history 表存在一个比较恶心的问题，就是只增不减。为了解决这个问题，OB 可以根据你说的这两个参数，定期回收不会再被系统消费的 history 数据。
什么时候 history 数据会被系统消费？我知道的可能不全：一个是 DDL 变更会通过中心节点（RS 服务所在的节点）上的 history 表的历史变更信息，向多个节点进行 DDL 变更信息的同步；一个是备份恢复的时候；一个是主备库同步的时候。
延迟删除看我在五楼的回复吧，是和备份恢复、主备库相关的实现相关的东西，和回收站没有直接关系。
嗯嗯，大概率是一样的。
1 个赞