Jan*_*ich 4 sql-server transaction-log
好的,这是事实.我不是数据库大师或管理员.事实上,除了一些偶尔的索引/查询调优之外,我不会经常在数据库中搜索.我经常遇到的一件事是SQL Server事务日志.我知道它是什么,它包含什么以及它是如何工作的(至少在概念上),但我想我不明白为什么SQL Server似乎如此依赖于事务日志.
这是第一个问题.如果我错了,请纠正我,但在我看来,默认情况下,事务日志将只包含数据库中所有更改的完整历史记录.有两种迹象表明情况可能确实如此.当我创建一个新数据库时,其日志的最大大小设置为"不受限制的增长".第二个原因是我经常处理具有巨大事务日志的小型数据库,无论我做什么都无法缩小.这似乎很奇怪我无法相信这是真的.为什么我默认需要整个历史记录？我所关心的只是处于一致状态的最新数据版本.好吧,我怀疑在某些情况下可能有正当理由,但我认为这是一个额外的选择.
我的第二个问题是为什么摆脱过渡日志这么复杂？它只是我,还是没有直接的方法呢？就在最近,我试图摆脱100MB + 5MB数据库的日志,我找到的最简单的方法是分离数据库,删除日志并重新连接它(甚至SQL服务有点抱怨).我尝试了收缩命令以及我能找到的所有可能的选项,但我只能收缩到约50%.数据库没有被使用(没有活动连接),老实说,我根本不关心任何过去的转换.我注意到可能还有其他"方法"如何做到这一点; 一些涉及备份和恢复.
我努力尝试阅读MSDN文档并学习更多关于过渡的内容,但是大约15分钟之后感觉就像在泥泞中走路一样,我放弃了.我知道对于数据库管理员和专家来说,我的问题听起来很傻.我感谢任何反馈.
编辑:在第一个答案之后,我意识到我可能不够清楚.我知道事务日志在事务期间如何工作,以及它为什么重要,并且它可以用于备份目的.我想我想从开发人员的角度提出更多问题.大多数时候我处理暂存/测试临时数据库,这些数据库不需要任何备份,除了我之外没有人使用,我经常发现自己需要传输它并且拥有一个巨大的过渡日志在这种情况下是不必要的不便.
Rem*_*anu 10
数据库日志不是事实历史记录之后的一些,如IIS日志.在具有预写日志记录的数据库中,日志是主要还原,重做和撤消源,并且出于所有目的,是权威的数据源.删除或替换日志是管理数据库的人可以做的最糟糕的决定之一.此时您的数据库可能已损坏.
截断日志的正确方法是执行完整数据库备份,然后执行数据库日志备份,然后执行定期日志备份.这将释放日志中的空间并允许其重用.它不会缩小物理LDF文件.
另一种途径是将恢复模型更改为SIMPLE,这将允许服务器在其认为合适时自动回收日志文件.将恢复模型更改为SIMPLE会影响数据库的可恢复性,因为您无法应用某些灾难恢复方案(如时间点恢复),也无法恢复自上次备份以来的任何数据更改.
了解SQL Server中
的日志记录和恢复日志和日志备份的误解:如何说服自己
内部存储引擎:有关日志循环特性的更多信息
| 归档时间： |
|
| 查看次数： |
943 次 |
| 最近记录： |