zoukankan      html  css  js  c++  java
  • SQL Server在简单恢复模式下,为什么有时候日志文件还是会增长得很快且很大?(转载)

    关于这个问题,首先建议先看看下面这个帖子的内容:

    Why Does the Transaction Log Keep Growing or Run Out of Space?

    里面有很多专家进行了详细的阐述,特别是这个回答

    这里我把里面比较关键的几个信息贴在下面:

    首先我们要了解在SQL Server中,Simple Recovery Model和Full Recovery Model这两种恢复模式有什么不同:

    Simple Recovery Model
    So with the above introduction, it is easiest to talk about Simple Recovery model first. In this model, you are telling SQL Server: "I am fine with you using your transaction log file for crash and restart recovery..." (You really have no choice there. Look up ACID properties and that should make sense quickly.) "...but once you no longer need it for that crash/restart recovery purpose, go ahead and reuse the log file."
    SQL Server listens to this request in Simple Recovery and it only keeps the information it needs to do crash/restart recovery. Once SQL Server is sure it can recover because data is hardened to the data file (more or less), the data that has been hardened is no longer necessary in the log and is marked for truncation - which means it gets re-used.


    Full Recovery Model
    With Full Recovery, you are telling SQL Server that you want to be able to recover to a specific point in time, as long as your log file is available or to a specific point in time that is covered by a log backup. In this case when SQL Server reaches the point where it would be safe to truncate the log file in Simple Recovery Model, it will not do that. Instead It lets the log file continue to grow and will allow it to keep growing, until you take a log backup (or run out of space on your log file drive) under normal circumstances.

    所以我们看到实际上在简单恢复模式下,SQL Server会重用日志文件的空间,但是这并不意味着日志文件就不会增长了,再来看看下面的阐述:

    Long Running Transactions

    ("My recovery model is fine! The log is still growing!)

    This can also be a cause of uncontrolled and unrestrained log growth. No matter the recovery model, but it often comes up as "But I'm in Simple Recovery Model - why is my log still growing?!"
    The reason here is simple: if SQL is using this transaction log for recovery purposes as I described above, then it has to see back to the start of a transaction.
    If you have a transaction that takes a long time or does a lot of changes, the log cannot truncate on checkpoint for any of the changes that are still in open transactions or that have started since that transaction started.
    This means that a big delete, deleting millions of rows in one delete statement is one transaction and the log cannot do any truncating until that whole delete is done. In Full Recovery Model, this delete is logged and that could be a lot of log records. Same thing with Index optimization work during maintenance windows. It also means that poor transaction management and not watching for and closing open transactions can really hurt you and your log file.

    所以一个超大型的事务(transaction)也会使得在简单恢复模式下的SQL Server日志快速增长,这就是很重要的一个原因。

  • 相关阅读:
    JAVA 读取txt文件内容
    Java中String.valueOf、toString、(String)的区别
    Java中Properties类的操作
    java 常用集合list与Set、Map区别及适用场景总结
    android adb devices offline的解决办法
    Java泛型四:Java泛型总结
    Java泛型三:Java泛型详解
    PHP本地环境搭配——WAMP不能启动, 一直处于红色图标或者橙色图标的解决办法
    利用NPOI开源的读写Excel、WORD等微软OLE2组件读写execl,控制样式或单元格
    Web App和Native App 谁将是未来
  • 原文地址:https://www.cnblogs.com/OpenCoder/p/12168274.html
Copyright © 2011-2022 走看看