34,588
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
zxszx 2001-09-01
- 打赏
- 举报
关于怎样截数据据日志。
1、用dbcc checktable(syslogs)检查断点。
2、然后在enterprise manager中对数据库进行'truncate'。
3、这时如果还不能'truncate'短。则再次dbcc checktable(syslogs)，后再次'truncate'.
4、如果还不能则stop database。（这种情况仅出现在非常大的事务引起log is over）.
5、如果没有采用备份日志的方案的话，笔者建议选用truncate log on checkpoint选项。
6、反对采用detach database，然后delete ldf file。这种做法非常danger.
以上为一家之言，不妥之处请指正
1、用dbcc checktable(syslogs)检查断点。
2、然后在enterprise manager中对数据库进行'truncate'。
3、这时如果还不能'truncate'短。则再次dbcc checktable(syslogs)，后再次'truncate'.
4、如果还不能则stop database。（这种情况仅出现在非常大的事务引起log is over）.
5、如果没有采用备份日志的方案的话，笔者建议选用truncate log on checkpoint选项。
6、反对采用detach database，然后delete ldf file。这种做法非常danger.
以上为一家之言，不妥之处请指正
leonfu 2001-09-01
- 打赏
- 举报
应该先detach database，然后delete ldf file，然后再attach database
leonfu 2001-09-01
- 打赏
- 举报
直接把ldf文件删了
leeyoong 2001-08-31
- 打赏
- 举报
1、首先，dbcc checkdb (数据库名)
2、然后，在enterprise manager中对该数据库进行‘Truncate’!
2、然后，在enterprise manager中对该数据库进行‘Truncate’!
lovesong 2001-08-31
- 打赏
- 举报
在enterprise manager里面右键点中数据库节点，选择truncate log
swordmanli 2001-08-31
- 打赏
- 举报
进行数据库的 log 备份
执行
backup log 数据库名 with no_log
swordmanli 2001-08-31
- 打赏
- 举报
Truncating the Transaction Log
If log records were never deleted from the transaction log, the logical log would grow until it filled all the available space on the disks holding the physical log files. At some point in time, old log records no longer necessary for recovering or restoring a database must be deleted to make way for new log records. The process of deleting these log records to reduce the size of the logical log is called truncating the log.
The active portion of the transaction log can never be truncated. The active portion of the log is the part of the log needed to recover the database at any time, so must have the log images needed to roll back all incomplete transactions. It must always be present in the database in case the server fails because it will be required to recover the database when the server is restarted. The record at the start of the active portion of the log is identified by the minimum recovery log sequence number (MinLSN).
The recovery model chosen for a database determines how much of the transaction log in front of the active portion must be retained in the database. Although the log records in front of the MinLSN play no role in recovering active transactions, they are required to roll forward modifications when using log backups to restore a database to the point of failure. If you lose a database for some reason, you can recover the data by restoring the last database backup, and then restoring every log backup since the database backup. This means that the sequence of log backups must contain every log record that was written since the database backup. When you are maintaining a sequence of transaction log backups, no log record can be truncated until after it has been written to a log backup.
The log records before the MinLSN are only needed to maintain a sequence of transaction log backups.
In the simple recovery model, a sequence of transaction logs is not being maintained. All log records before the MinLSN can be truncated at any time, except while a BACKUP statement is being processed. NO_LOG and TRUNCATE_ONLY are the only BACKUP LOG options that are valid for a database that is using the simple recovery model.
Note The tempdb database always uses the simple recovery model, it cannot be switched to another recovery model. Log truncation always occurs on a checkpoint in tempdb.
In the full and bulk-logged recovery models, a sequence of transaction log backups is being maintained. The part of the logical log before the MinLSN cannot be truncated until those log records have been copied to a log backup.
Log truncation occurs at these points:
At the completion of any BACKUP LOG statement.
Every time a checkpoint is processed, provided the database is using the simple recovery model. This includes both explicit checkpoints resulting from a CHECKPOINT statement and implicit checkpoints generated by the system. The exception is that the log is not truncated if the checkpoint occurs when a BACKUP statement is still active. For more information about the interval between automatic checkpoints, see Checkpoints and the Active Portion of the Log..
Transaction logs are divided internally into sections called virtual log files. Virtual log files are the unit of truncation. When a transaction log is truncated, all log records before the start of the virtual log file containing the MinLSN are deleted. For more information about virtual log files, see Transaction Log Physical Architecture.
The size of a transaction log is therefore controlled in one of these ways:
When a log backup sequence is being maintained, schedule BACKUP LOG statements to occur at intervals that will keep the transaction log from growing past the desired size.
When a log backup sequence is not maintained, specify the simple recovery model.
This illustration shows a transaction log that has four virtual logs. The log has not been truncated after the database was created. The logical log starts at the beginning of the first virtual log and the part of virtual log 4 beyond the end of the logical file has never been used.
This illustration shows how the log looks after truncation. The rows before the start of the virtual log containing the MinLSN record have been truncated.
Truncation does not reduce the size of a physical log file, it reduces the size of the logical log file. For information on shrinking the size of a physical log file, see Shrinking the Transaction Log.
If log records were never deleted from the transaction log, the logical log would grow until it filled all the available space on the disks holding the physical log files. At some point in time, old log records no longer necessary for recovering or restoring a database must be deleted to make way for new log records. The process of deleting these log records to reduce the size of the logical log is called truncating the log.
The active portion of the transaction log can never be truncated. The active portion of the log is the part of the log needed to recover the database at any time, so must have the log images needed to roll back all incomplete transactions. It must always be present in the database in case the server fails because it will be required to recover the database when the server is restarted. The record at the start of the active portion of the log is identified by the minimum recovery log sequence number (MinLSN).
The recovery model chosen for a database determines how much of the transaction log in front of the active portion must be retained in the database. Although the log records in front of the MinLSN play no role in recovering active transactions, they are required to roll forward modifications when using log backups to restore a database to the point of failure. If you lose a database for some reason, you can recover the data by restoring the last database backup, and then restoring every log backup since the database backup. This means that the sequence of log backups must contain every log record that was written since the database backup. When you are maintaining a sequence of transaction log backups, no log record can be truncated until after it has been written to a log backup.
The log records before the MinLSN are only needed to maintain a sequence of transaction log backups.
In the simple recovery model, a sequence of transaction logs is not being maintained. All log records before the MinLSN can be truncated at any time, except while a BACKUP statement is being processed. NO_LOG and TRUNCATE_ONLY are the only BACKUP LOG options that are valid for a database that is using the simple recovery model.
Note The tempdb database always uses the simple recovery model, it cannot be switched to another recovery model. Log truncation always occurs on a checkpoint in tempdb.
In the full and bulk-logged recovery models, a sequence of transaction log backups is being maintained. The part of the logical log before the MinLSN cannot be truncated until those log records have been copied to a log backup.
Log truncation occurs at these points:
At the completion of any BACKUP LOG statement.
Every time a checkpoint is processed, provided the database is using the simple recovery model. This includes both explicit checkpoints resulting from a CHECKPOINT statement and implicit checkpoints generated by the system. The exception is that the log is not truncated if the checkpoint occurs when a BACKUP statement is still active. For more information about the interval between automatic checkpoints, see Checkpoints and the Active Portion of the Log..
Transaction logs are divided internally into sections called virtual log files. Virtual log files are the unit of truncation. When a transaction log is truncated, all log records before the start of the virtual log file containing the MinLSN are deleted. For more information about virtual log files, see Transaction Log Physical Architecture.
The size of a transaction log is therefore controlled in one of these ways:
When a log backup sequence is being maintained, schedule BACKUP LOG statements to occur at intervals that will keep the transaction log from growing past the desired size.
When a log backup sequence is not maintained, specify the simple recovery model.
This illustration shows a transaction log that has four virtual logs. The log has not been truncated after the database was created. The logical log starts at the beginning of the first virtual log and the part of virtual log 4 beyond the end of the logical file has never been used.
This illustration shows how the log looks after truncation. The rows before the start of the virtual log containing the MinLSN record have been truncated.
Truncation does not reduce the size of a physical log file, it reduces the size of the logical log file. For information on shrinking the size of a physical log file, see Shrinking the Transaction Log.
