空库才能用BR恢复吧，正在使用的不行。
你说的这个是禁止了br恢复所需要进行的DDL和DML操作吧？我的意思是用户连接到数据库进行的insert之类的操作哦。
就比如这种情况：
比如某次br恢复耗时1个小时（假设为9：00 - 10：00），如果我在9：30时向某张表（假设为A表）insert了大量数据，那么是否会对最终的恢复结果造成影响呢？
这里假设一种极端情况：在对A表进行insert操作的同时，br也在对该表做恢复，那等恢复任务完成后，A表的数据会是怎样一种情况呢？会发生错乱吗？
我这里就是想在9：00 - 10：00期间禁止9：30那种insert之类的数据库操作。
你这种根本恢复不了 直接报错
数据异常，报错，各种异常。
要是 备份 就是可以的，恢复 不行
我刚做了个小测试：
可以看到恢复时间为：16.27.45 - 16:28:45
然后我在16:28:05的时候在test库下创建了表并插入了一条数据：
最后恢复任务还是成功了。
所以就有两个问题：
1.恢复并没有报错。
2.恢复并未达到预期效果：恢复成功后test库下应该是空的。但恢复任务完成后还是能在test库下查询到我在恢复任务期间创建的表及插入的数据。
你备份文件里，有 test库tb_courses表么？
没有的 备份文件里test库是空的
由于数据量少，恢复任务执行的比较快。
所以我这里是通过卡read接口来延长恢复任务的执行时间的：
可以看到我是在整个恢复任务的第三次和第四次read之间暂停了50秒。
那有没有可能在第三次read完成后与test库相关的恢复已经完成了，所以我能够成功写入数据。
也就是说我的写入操作与br的恢复操作并没有同时对test库进行操作。
用大点的数据量测试吧
这个设置是只能通过高权限用户连接到数据库才能完成么？有其他的方法么？
拥有 SUPER或 SYSTEM_VARIABLES_ADMIN 权限的用户可以修改该变量
这个是必须得登录数据库么？可以不登录数据库进行修改么？
系统变量应该是只能在数据库里改，不登数据库得想其他办法了
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。