在过去的几天里,我读了很多关于这个的文章,但是没有一个是专门针对主数据库的。
如果我从完全切换到简单,它会冲洗出任何计划,统计等吗?有表演成功吗?
我知道怎么继续,只是以前从没见过师父完全康复。
提亚
发布于 2020-04-02 17:13:04
让主数据库完全恢复是没有意义的。安装过程使数据库处于简单的恢复状态,因此这意味着有人在之后更改了数据库,因为他们可以。
我不认为您在主数据库上执行需要实时恢复的操作,如果您执行了,我强烈建议您重新考虑这个策略。此外,要考虑到数据库在完全恢复时需要定期备份日志,以避免填充日志文件。会发生这种事吗?您打算如何恢复这些日志备份以防止?
话虽如此,我还是会把它改回简单的,而不用担心太多的性能问题。
发布于 2020-04-03 09:29:24
我记得在SQL Server的beta阶段(我认为是2005年)研究过这个问题。我很惊讶你居然能为师父改变恢复模式。
而且,为了使事情更有趣,日志备份不允许主人使用。
回到过去,SQL Server的行为就像主服务器处于简单模式,也就是说它会自动截断日志。
但下面的测试表明,这种自动截断现在并不发生(SQLServer2019)。
注意:下面将填写主数据库的日志,ldf将自动增长。如果你觉得不舒服就别跑。
ALTER DATABASE MASTER SET RECOVERY FULL
BACKUP DATABASE MASTER TO DISK = 'nul'
DROP TABLE IF EXISTS t
CREATE TABLE t(c1 int identity, c2 char(80))
INSERT INTO t (c2) VALUES ('a')
DECLARE @i int = 1
WHILE @i < 100000
BEGIN
IF @i % 20000 = 0
BEGIN
SELECT counter_name, instance_name, cntr_value FROM sys.dm_os_performance_counters WHERE counter_name = 'Log File(s) Used Size (KB)' AND instance_name = DB_NAME()
CHECKPOINT
END
SET @i += 1
UPDATE t SET c2 = REPLICATE(SUBSTRING(CAST(@i AS varchar(20)), 1, 1), 70)
END
--Below result in error
--BACKUP LOG master TO DISK = 'nul'
https://dba.stackexchange.com/questions/264179
复制相似问题