什么时候应该使用完整的恢复模型,什么时候应该对数据库使用简单的恢复模型?
我总是使用完整的恢复模型,因为它是默认的,但是今天我遇到了以下错误:
(0x80040E14)数据库“数据库名称”的事务日志已满。若要了解日志中空间不能重用的原因,请参阅sys.databases中的sys.databases列。
具体的数据库实际上是我的服务器上最小和最不活跃的数据库之一,所以我不知道日志如何能满在这个数据库上,而不知道其他的数据库。
为了缩小日志并使数据库再次可访问,我将恢复模型从完整更改为简单,并使用以下命令缩小了逻辑文件日志
alter database myDbName SET recovery
有一个数据库,它与它一起工作之前知道。知道此数据库(ms sql数据库)处于InRecovery模式。在此模式下,当我可以在SQL Server Management Studio中看到它,但我无法执行其他任何操作时。这意味着我看不到表,我看不到每个表的数据,...抽象地说,数据库名称旁边的加号按钮不存在。你还可以猜到我做不到的其他事情。这个问题是从哪里来的?以及我如何解决这个问题。(注意:我没有此数据库的任何备份)
我需要知道如何将10个数据表从一个数据库导出为csv格式,每天使用cron作业?
我知道这个剧本:
SELECT *
FROM TABLE NAME
INTO OUTFILE '/var/lib/mysql-files/BACKUP.csv'
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n';
但是,如何在同一行中添加另外9个表呢?
诚挚的问候!
关于恢复模式,我知道如果您想要时间点恢复,我们应该使用完全恢复模式。如果不需要这样做,则可以使用简单的恢复模式。
但是,我读到了简单的恢复模式,它说,如果时间点恢复不是重要的and if your data is static,我们应该使用它。
这里我们不需要日志备份,我们只使用Full backups and Diffs,我认为这对性能和磁盘空间都有好处,可以使用简单的恢复数据库。但正如我所说,我们没有静态数据。有很多插入、更新和开发更新(是的,我不明白为什么它们不需要时间点恢复,但是无论如何.)。
我的问题是,使用简单的恢复仍然是个好主意,还是因为没有静态数据,日志还会增长等等?