sql 写日志，清理日志

create database hufang
on primary --默认就属于Primary 主文件组，可省略
(
/*--数据文件的具体描述--*/
Name='hufang_data', --主数据库的物理名称
Filename='F:\project\hufang_data.mdf' ,--主数据库的物理名称
size=5MB , --主数据库的初始大小
Maxsize=100Mb,  --主数据库文件增长最大文件增长
Filegrowth =15%
)

Log on
(
/*--日志文件具体描述同上--*/
name='hufang_log',
Filename='F:\project\hufang_data.ldf',
Size=2MB,
MaxSize=10MB,
FIleGrowth=15%

)

Go --和后续的Sql语句分开

=============================================================

清理和删除日志

方法1：
第一步：
backup log database_name with no_log
或者 backup log database_name with truncate_only --no_log和truncate_only是在这里是同义的，随便执行哪一句都可以
第二步：
1.收缩特定数据库的所有数据和日志文件，执行 dbcc shrinkdatabase (database_name,[,target_percent])--database_name是要收缩的数据库名称；target_percent是数据库收缩后的数据库文件中所要的剩余可用空间百分比
2.收缩一次一个特定数据库中的数据或日志文件，执行 dbcc shrinkfile(file_id,[,target_size]) --file_id是要收缩的文件的标识 (ID) 号,若要获得文件 ID，请使用 FILE_ID 函数或在当前数据库中搜索 sysfiles；target_size是用兆字节表示的所要的文件大小（用整数表示）。如果没有指定，dbcc shrinkfile 将文件大小减少到默认文件大小

两个dbcc都可以带上参数notruncate或truncateonly，具体意思看帮助。


方法2
（这个方法在sqlserver2000的环境下做一般能成功，在sqlserver7及以下版本就不一定了）：
第一步：
先备份整个数据库以备不测
第二步：
备份结束后，在Query Analyzer中执行如下的语句：
exec sp_detach_db yourDBName,true --卸除这个DB在MSSQL中的注册信息
第三步：
到日志的物理文件所在的目录中去删除该日志文件或者将该日志文件移出该目录
第四步：
在Query Analyzer中执行如下的语句：
exec sp_attach_single_file_db yourDBName,'d:\mssql7\data\yourDBName_data.mdf'
--以单文件的方式注册该DB，如果成功则MSSQL将自动为这个DB生成一个500K的日志文件。

以上方法在清除log日志中均有效。
但，能否让sql server 不产生log日志呢？以上方法好像均无效。
我这儿正好有个case：
我客户的sql server每天都会产生4，500M的log日志，每天都清除一下，非常不便。有没有办法实现不产生log日志呢？

我分析了一下客户产生log日志的原因，并且做了相应测试。
客户是每天将数据库清空，从总系统中将数据导入到sql server里。我感决sqlserver在插入时产生log不大，在delete整个库时产生log极大。
比如：
SELECT * into test_2 from b_bgxx
共45000条记录，产生十几M log，如果
delete from test_2
产生80多M log ，这明显存在问题。

虽然可以换成：
truncate table test_2
但我还是希望能找到不产生log的方法。就如oracle不产生归档一样

==============================================================

事务日志文件Transaction Log File是用来记录数据库更新情况的文件，扩展名为ldf。
在 SQL Server 7.0 和 SQL Server 2000 中，如果设置了自动增长功能，事务日志文件将会自动扩展。
一般情况下，在能够容纳两次事务日志截断之间发生的最大数量的事务时，事务日志的大小是稳定的，事务日志截断由检查点或者事务日志备份触发。
然而，在某些情况下，事务日志可能会变得非常大，以致用尽空间或变满。通常，在事务日志文件占尽可用磁盘空间且不能再扩展时，您将收到如下错误消息：
Error:9002, Severity:17, State:2
The log file for database '%.*ls' is full.
除了出现此错误消息之外，SQL Server 还可能因为缺少事务日志扩展空间而将数据库标记为 SUSPECT。有关如何从此情形中恢复的其他信息，请参见 SQL Server 联机帮助中的“磁盘空间不足”主题。

另外，事务日志扩展可能导致下列情形： 
· 非常大的事务日志文件。 
· 事务可能会失败并可能开始回滚。 
· 事务可能会用很长时间才能完成。 
· 可能发生性能问题。 
· 可能发生阻塞现象。

原因
事务日志扩展可能由于以下原因或情形而发生： 
· 未提交的事务 
· 非常大的事务 
· 操作：DBCC DBREINDEX 和 CREATE INDEX 
· 在从事务日志备份还原时 
· 客户端应用程序不处理所有结果 
· 查询在事务日志完成扩展之前超时，您收到假的“Log Full”错误消息 
· 未复制的事务

解决方法
日志文件满而造成SQL数据库无法写入文件时，可用两种方法：
一种方法：清空日志。
1．打开查询分析器，输入命令
DUMP TRANSACTION 数据库名 WITH NO_LOG
2.再打开企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了。

另一种方法有一定的风险性，因为SQL SERVER的日志文件不是即时写入数据库主文件的，如处理不当，会造成数据的损失。
1: 删除LOG
分离数据库 企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库
2：删除LOG文件
附加数据库 企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库
此法生成新的LOG，大小只有500多K。

注意：建议使用第一种方法。

如果以后,不想要它变大。
SQL2000下使用：
在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。
或用SQL语句：
alter database 数据库名 set recovery simple

 
另外，如上图中数据库属性有两个选项，与事务日志的增长有关：
Truncate log on checkpoint
(此选项用于SQL7.0，SQL 2000中即故障恢复模型选择为简单模型)
当执行CHECKPOINT 命令时如果事务日志文件超过其大小的70% 则将其内容清除在开发数据库时时常将此选项设置为True
Auto shrink
定期对数据库进行检查当数据库文件或日志文件的未用空间超过其大小的25%时，系统将会自动缩减文件使其未用空间等于25% 当文件大小没有超过其建立时的初始大小时不会缩减文件缩减后的文件也必须大于或等于其初始大小对事务日志文件的缩减只有在对其作备份时或将Truncate log on checkpoint 选项设为True 时才能进行。


注意：一般立成建立的数据库默认属性已设好，但碰到意外情况使数据库属性被更改，请用户清空日志后，检查数据库的以上属性，以防事务日志再次充满。

----------------------------------------------------------------------------------------------

SQL Server里的templog.ldf文件超大,已经10G了,我要怎么样安全的删除它呀? 悬赏分：5 - 解决时间：2006-2-27 10:14 今天系统提示d盘空间不够,看在SQL SERVER的Data目录下,templog.ldf文件占了接近十G空间了. 我想知道怎么样才能安全删除它.或者说是清空它. 问题补充：好不容易我在网上找了一条命令 backup log 数据库名 with NO_LOG 删除了，希望不会有什么不良后果。呵呵。 提问者： splaybow - 试用期 一级 最佳答案 建议更改数据库的事务日志，限制文件增长的最大值和定期备份日志和数据。在以下处理之前，最好整体备份整个数据库： 1：由小的事务引起日志溢出，系统能正常启动。 解决办法： 扩大数据库日志空间： alter database 数据库名 on 设备名=数量（M为单位） sp_logdevice 数据库名，设备名 清除日志 dump transaction 数据库名 with no_log(no_truncate) 2：由大的事物引起日志溢出，系统较长时间内无法正常启动或数据库无法恢复 解决办法： 强行清空日志。 在实在无法恢复数据库或有近期备份的情况下，可采用强行清空日志的方法。采取这种方法的后果有可能彻底破坏数据库。执行步骤如下： Ⅰ 以-v 方式启动SQL SERVER(不检测日志) Ⅱ 修改数据库状态为-32768（阻塞状态） update sysdatabases set status=-32768 where name=数据库名 Ⅲ 授权sybase_ts_role权限(sybase_ts_role为SQL SERVER特殊管理员权限，在日常的数据库管理中，不需要这个角色） sp_role “grant”,”sybase_ts_role”,sa set role “sybase_ts_role” Ⅳ 清除日志 dbcc rebuild_log(数据库名，1，1) 完成以上步骤后，重新启动SQL SERVER即可。如果数据库能正常启动，数据库就恢复完成；如果无法启动，只能重新创建数据库。 ================================================================= 压缩日志 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 Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf' 4: 如果想以后不让它增长 企业管理器--服务器--右键数据库--属性--事务日志--将文件增长限制为xM(x是你允许的最大数据文件大小) --SQL语句的设置方式: alter database 数据库名 modify file(name=逻辑文件名,maxsize=20) 5.设置为自动收缩 企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩"

-------------------------------------------------------------------------------------------------------

恢复完全备份、差异备份和事务日志备份

题目如下：
有一数据库管理员对数据库设计了这样一个备份策略：在每个星期一的00：00对数据库做一次完全备份；从星期二到星期日，每天的1：00对数据库做一次差异备份；每天以30分钟的间隔对数据库做一次事务日志备份（开始时间是06：00，结束时间是22：00），假设数据库在某个星期三10：50崩溃了，请写出恢复数据库的步骤

解答如下：
--1、恢复最近一次 完全备份
Restore Database dbtest From FullBackUp With NoRecovery
--2、恢复最近一次 差异备份
Restore Database dbtest From DiffBackUp With NoRecovery
--3、从最近一次差异备份后，开始依次恢复事务日志
Restore Log dbtest From LogBackUp With NoRecovery,File=1--假如所有日志使用Logbackup备份设备
Restore Log dbtest From LogBackUp With NoRecovery,File=2
Restore Log dbtest From LogBackUp With NoRecovery,File=3
。。。。
Restore Log dbtest From LogBackUp With File=n --最后一个 不能加 NoRecovery,其他必须加

http://topic.csdn.net/u/20100702/20/534b9600-bc88-45ba-85c3-58b6608210ff.html?seed=1849987175&r=66686874#r_66686874

转载于:https://www.cnblogs.com/neru/archive/2011/04/22/2024702.html