sqlserver 日志截断
截断事务日志 1:截断事务日志: BACKUP ? LOG ? 数据库名 ? WITH ? NO_LOG 2:清空日志 DUMP ? ? TRANSACTION ? ? 库名 ? ? WITH ? ? NO_LOG ? ? ? ? 再: 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 3: ? 删除LOG 1:分离数据库 ? ? ? 企业管理器->服务器->数据库->右键->分离数据库 2:删除LOG文件 3:附加数据库 ? ? 企业管理器->服务器->数据库->右键->附加数据库 此法生成新的LOG,大小只有500多K ? ? ? 再将此数据库设置自动收缩 ? 或用代码: ? 下面的示例分离 ? pubs,然后将 ? pubs ? 中的一个文件附加到当前服务器。 EXEC ? sp_detach_db ? @dbname ? = ? 'pubs ' EXEC ? sp_attach_single_file_db ? @dbname ? = ? 'pubs ',? ? ? ? @physname ? = ? 'c:Program ? FilesMicrosoft ? SQL ? ServerMSSQLDatapubs.mdf ' 4: ? 如果想以后不让它增长 企业管理器--服务器--右键数据库--属性--事务日志--将文件增长限制为xM(x是你允许的最大数据文件大小) --SQL语句的设置方式: alter ? database ? 数据库名 ? modify ? file(name=逻辑文件名,maxsize=20) 5.设置为自动收缩 企业管理器--服务器--右键数据库--属性--选项--选择 "自动收缩 " 逻辑日志是日志的记录.物理日志是记录日志的文件. 联机帮助上有说明: 日志收缩操作依赖于最初的日志截断操作。日志截断操作不减小物理日志文件的大小,但减小逻辑日志的大小,并将没有容纳逻辑日志任何部分的虚拟日志标记为不活动。日志收缩操作会删除足够多的不活动虚拟日志,将日志文件减小到要求的大小。 减小大小的单位是一个虚拟日志文件。例如,如果有个 ? 600 ? MB ? 的日志文件被分成了 ? 6 ? 个 ? 100 ? MB ? 的虚拟日志,则该日志文件的大小只能按 ? 100 ? MB ? 递减。比如,文件可以减小到 ? 500 ? MB ? 或 ? 400 ? MB,但不能减小到 ? 433 ? MB ? 或 ? 525 ? MB。 不能释放容纳逻辑日志部分的虚拟日志。如果某个日志文件中的所有虚拟日志都容纳了逻辑日志部分,则不能收缩该文件,直到截断操作在物理日志的末端将一个或更多的虚拟日志标记为不活动。 当收缩任何文件时,必须从文件的末端开始释放空间。当收缩事务日志文件时,从文件的末端开始释放足够的虚拟日志以将日志减小到用户所要求的大小。用户指定的 ? target_size ? 四舍五入为下一个最大的虚拟日志边界大小。例如,如果用户为包含 ? 6 ? 个 ? 100 ? MB ? 虚拟日志文件的 ? 600 ? MB ? 文件指定 ? 325 ? MB ? 的 ? target_size,则删除最后两个虚拟日志文件,因此新的文件大小为 ? 400 ? MB。 在 ? SQL ? Server ? 2000 ? 中,DBCC ? SHRINKDATABASE ? 或 ? DBCC ? SHRINKFILE ? 操作试图立即将物理日志文件收缩到所要求的大小(以四舍五入的值为准): ? 如果虚拟日志中的逻辑日志部分没有超出 ? target_size ? 标记,则释放 ? target_size ? 标记之后的虚拟日志,并且成功完成 ? DBCC ? 语句,不出现任何信息。 如果虚拟日志中的逻辑日志部分超出 ? target_size ? 标记,则 ? SQL ? Server ? 2000 ? 释放尽可能多的空间并发出一条信息。该信息告诉您需要执行什么操作以获得文件末端超出虚拟日志的逻辑日志部分。执行完该操作后,可以重新发出 ? DBCC ? 语句以释放剩余的空间。 ? 例如,当执行 ? target_size ? 为 ? 275 ? MB ? 的 ? DBCC ? SHRINKFILE ? 语句时,假设有一个包含 ? 6 ? 个虚拟日志的 ? 600 ? MB ? 日志文件,其逻辑日志从第 ? 3 ? 个虚拟日志开始,到第 ? 4 ? 个虚拟日志结束: 将立即释放第 ? 5 ? 个和第 ? 6 ? 个虚拟日志,因为它们没有容纳逻辑日志部分。然而,为达到指定的 ? target_size,还应释放第 ? 4 ? 个虚拟日志,但无法释放,因为它容纳了逻辑日志的末端部分。在释放第 ? 5 ? 个和第 ? 6 ? 个虚拟日志之后,SQL ? Server ? 2000 ? 用虚记录填充第 ? 4 ? 个虚拟日志部分。这将日志文件的末端强制为第 ? 1 ? 个虚拟日志。在大多数系统中,起始于第 ? 4 ? 个虚拟日志的所有事务将在几秒钟内提交,这意味着日志的所有活动部分都移动到了第 ? 1 ? 个虚拟日志,并且日志文件现在看起来像下面这样: DBCC ? SHRINKFILE ? 语句还发出一条信息,指出它不能释放所要求的全部空间,并告诉您可以执行 ? BACKUP ? LOG ? 语句以便释放剩余的空间。一旦日志的活动部分移动到第 ? 1 ? 个虚拟日志,BACKUP ? LOG ? 语句将截断第 ? 4 ? 个虚拟日志中的整个逻辑日志: 因为第 ? 4 ? 个虚拟日志不再容纳逻辑日志的任何部分,如果现在执行同一个 ? target_size ? 为 ? 275 ? MB ? 的 ? DBCC ? SHRINKFILE ? 语句,则会释放第 ? 4 ? 个虚拟日志,并且物理日志文件的大小会减小到所要求的大小。 ? (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |