SQL Server清空日志及所有表的数据

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS SQL Server,基础系列 2核4GB
日志服务 SLS,月写入数据量 50GB 1个月
简介:
在查询分析器中顺序执行以下三步,其中   databasename   为你的数据库文件名 
1.清空日志:DUMP   TRANSACTION   databasename   WITH   NO_LOG   

2.截断事务日志:BACKUP   LOG   databasename   WITH   NO_LOG   

3.收缩数据库:DBCC   SHRINKDATABASE(databasename)   


--////////////////////////////////////////////////////////////////// 

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

方法二: 

清空日志: 

------------------------------------------ 
  BACKUP   LOG     库名   WITH   NO_LOG 

  DBCC   SHRINKFILE(   '日志文件名 ',新的大小数值型如1) 

日志文件名是这样的: 

select   name   from   sysfiles 
如: 
mastlog 

--------------------------------------------- 
backup   log     DATABASENAME 
  with   truncate_only 
  dbcc   shrinkdatabase   (DATABASENAME,SIZE)   
  若每天有whole   back   up   的话可以设置一job, 
  每隔三天或一个星期清空一次 
  这样的话日志就不会长大了哦 


------------------------------------- 
1:   删除LOG 
1:分离数据库 
2:删除LOG文件 
3:附加数据库 
此法生成新的LOG,大小只有500多K 
      再将此数据库设置自动收缩 
2:清空日志 
DUMP     TRANSACTION     库名     WITH     NO_LOG         

再: 
企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 

方法三:   
第一步:   
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,具体意思看帮助。   


方法四:   
(这个方法在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  


 

近来发现数据库过大,空间不足,因此打算将数据库的数据进行全面的清理,但表非常多,一张一张的清空,实在麻烦,因此就想利用SQL语句一次清空所有数据.找到了三种方法进行清空.使用的数据库为MS SQL SERVER.
1.搜索出所有表名,构造为一条SQL语句

declare  @trun_name  varchar ( 8000 )
set  @trun_name = ''
select  @trun_name = @trun_name  +  ' truncate table  '  +  [ name ]  +  '  '  from  sysobjects  where  xtype = ' U '  and  status  >  0
exec  ( @trun_name )

该方法适合表不是非常多的情况,否则表数量过多,超过字符串的长度,不能进行完全清理.
2.利用游标清理所有表

declare  @trun_name  varchar ( 50 )
declare  name_cursor  cursor  for
select  ' truncate table  '  +  name  from  sysobjects  where  xtype = ' U '  and  status  >  0
open  name_cursor
fetch  next  from  name_cursor  into  @trun_name
while  @@FETCH_STATUS  =  0
begin
  
exec  ( @trun_name )
 
print  ' truncated table  '  +  @trun_name
 
fetch  next  from  name_cursor  into  @trun_name
end
close  name_cursor
deallocate  name_cursor

这是我自己构造的,可以做为存储过程调用, 能够一次清空所有表的数据,并且还可以进行有选择的清空表.
3.利用微软未公开的存储过程

exec  sp_msforeachtable " truncate  table  ?"

 

该方法可以一次清空所有表,但不能加过滤条件.

 

转载请注明出处[ http://samlin.cnblogs.com/] 
作者赞赏
 


刚做的招标网: 八爪鱼招标网 请大家多意见


本文转自Sam Lin博客博客园博客,原文链接:http://www.cnblogs.com/samlin/archive/2012/09/03/Sql_truncate_data.html,如需转载请自行联系原作者
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
7天前
|
SQL 安全 数据处理
揭秘数据脱敏神器:Flink SQL的神秘力量,守护你的数据宝藏!
【9月更文挑战第7天】在大数据时代,数据管理和处理尤为重要,尤其在保障数据安全与隐私方面。本文探讨如何利用Flink SQL实现数据脱敏,为实时数据处理提供有效的隐私保护方案。数据脱敏涉及在处理、存储或传输前对敏感数据进行加密、遮蔽或替换,以遵守数据保护法规(如GDPR)。Flink SQL通过内置函数和表达式支持这一过程。
28 2
|
9天前
|
SQL 人工智能 运维
在阿里云日志服务轻松落地您的AI模型服务——让您的数据更容易产生洞见和实现价值
您有大量的数据,数据的存储和管理消耗您大量的成本,您知道这些数据隐藏着巨大的价值,但是您总觉得还没有把数据的价值变现出来,对吗?来吧,我们用一系列的案例帮您轻松落地AI模型服务,实现数据价值的变现......
63 3
|
10天前
|
SQL 安全 数据库
基于SQL Server事务日志的数据库恢复技术及实战代码详解
基于事务日志的数据库恢复技术是SQL Server中一个非常强大的功能,它能够帮助数据库管理员在数据丢失或损坏的情况下,有效地恢复数据。通过定期备份数据库和事务日志,并在需要时按照正确的步骤恢复,可以最大限度地减少数据丢失的风险。需要注意的是,恢复数据是一个需要谨慎操作的过程,建议在执行恢复操作之前,详细了解相关的操作步骤和注意事项,以确保数据的安全和完整。
26 0
|
14天前
|
Java 网络架构 数据格式
Struts 2 携手 RESTful:颠覆传统,重塑Web服务新纪元的史诗级组合!
【8月更文挑战第31天】《Struts 2 与 RESTful 设计:构建现代 Web 服务》介绍如何结合 Struts 2 框架与 RESTful 设计理念,构建高效、可扩展的 Web 服务。Struts 2 的 REST 插件提供简洁的 API 和约定,使开发者能快速创建符合 REST 规范的服务接口。通过在 `struts.xml` 中配置 `<rest>` 命名空间并使用注解如 `@Action`、`@GET` 等,可轻松定义服务路径及 HTTP 方法。
30 0
|
14天前
|
测试技术 Java
全面保障Struts 2应用质量:掌握单元测试与集成测试的关键策略
【8月更文挑战第31天】Struts 2 的测试策略结合了单元测试与集成测试。单元测试聚焦于单个组件(如 Action 类)的功能验证,常用 Mockito 模拟依赖项;集成测试则关注组件间的交互,利用 Cactus 等框架确保框架拦截器和 Action 映射等按预期工作。通过确保高测试覆盖率并定期更新测试用例,可以提升应用的整体稳定性和质量。
28 0
|
14天前
|
数据库 Java 监控
Struts 2 日志管理化身神秘魔法师,洞察应用运行乾坤,演绎奇幻篇章!
【8月更文挑战第31天】在软件开发中,了解应用运行状况至关重要。日志管理作为 Struts 2 应用的关键组件,记录着每个动作和决策,如同监控摄像头,帮助我们迅速定位问题、分析性能和使用情况,为优化提供依据。Struts 2 支持多种日志框架(如 Log4j、Logback),便于配置日志级别、格式和输出位置。通过在 Action 类中添加日志记录,我们能在开发过程中获取详细信息,及时发现并解决问题。合理配置日志不仅有助于调试,还能分析用户行为,提升应用性能和稳定性。
33 0
|
14天前
|
Java 测试技术 容器
从零到英雄:Struts 2 最佳实践——你的Web应用开发超级变身指南!
【8月更文挑战第31天】《Struts 2 最佳实践:从设计到部署的全流程指南》深入介绍如何利用 Struts 2 框架从项目设计到部署的全流程。从初始化配置到采用 MVC 设计模式,再到性能优化与测试,本书详细讲解了如何构建高效、稳定的 Web 应用。通过最佳实践和代码示例,帮助读者掌握 Struts 2 的核心功能,并确保应用的安全性和可维护性。无论是在项目初期还是后期运维,本书都是不可或缺的参考指南。
25 0
|
20天前
|
Kubernetes Ubuntu Windows
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
|
2天前
|
Java
日志框架log4j打印异常堆栈信息携带traceId,方便接口异常排查
日常项目运行日志,异常栈打印是不带traceId,导致排查问题查找异常栈很麻烦。