分区表的数据删除

问题:堆表按天做了分区,表中只保留最近7天的数据。最近发现此表的数据空间明显比之前大,之前2G:现在6G,持续关注几天表中记录数保持平衡,但数据空间却在进一步增长。对应表所在的文件组也不停在自增长。

分析:使用sys.dm_db_index_physical_stats查看表的碎片情况,发现在已删除记录的分区中堆的区碎片(avg_fragmentation_in_percent)、数据页总数(page_count)不为零。


查看另一个库下此表的备份表(同为分区表,保留最近30天的数据),表的数据空间才4G。30天前对应的分区中没有任何碎片、数据页信息。它们唯一的不同就是对历史数据处理方法:一个是每天通过delete的方式将7天前的数据删除;另一个是通过switch交换分区,然后truncate交换出去的数据。
解决:创建用于交换分区的Trun表(字段、压缩选项与原表一致),尝试将已删除数据的旧分区switch出来,报错表已分区,但索引XX没有分区。表上一个索引没有创建在分区上,查看索引使用情况,查找/扫描次数均为0,删除索引。再次switch partition成功。
交换部分分区后查看原表数据空间下降,Trun表碎片信息与切换前原表保留一致,交换后占用空间也增上去,truncate Trun表,再进行后续操作。


总结:一个问题往往要从多方面分析,对于空间问题可以从以下方面入手。查看数据文件使用情况(dbcc showfilestats)、查看自动增长情况(默认跟踪)、查找库下占用空间前N的表、查看表占用/剩余空间情况(sp_spaceused)、查看表碎片情况(sys.dm_db_index_physical_stats)、查看索引使用情况(sys.dm_db_index_usage_stats)

 1 --数据文件使用情况
 2 dbcc showfilestats
 3 select 174634*8*8/1024,(174634-169743)*8*8/1024
 4 --日志文件使用情况
 5 dbcc sqlperf(logspace)
 6 dbcc loginfo()
 7
 8 --查看自动增长情况
 9 select * from sys.trace_events
10 DECLARE @tracefile NVARCHAR(MAX)
11 SET @tracefile = (SELECT LEFT([path],LEN([path])-CHARINDEX(‘\‘,REVERSE([path])))+ ‘\log.trc‘ FROM sys.traces WHERE [is_default] = 1)
12 SELECT TOP 1000
13  gt.[HostName]
14 ,gt.[ServerName]
15 ,gt.[DatabaseName]
16 ,gt.[SPID]
17 ,gt.[ObjectName]
18 ,gt.[objecttype] [ObjectTypeID]
19 ,sv.[subclass_name] [ObjectType]
20 ,e.[category_id] [CategoryID]
21 ,c.[Name] [Category]
22 ,gt.[EventClass] [EventID]
23 ,e.[Name] [EventName]
24 ,gt.[LoginName]
25 ,gt.[ApplicationName]
26 ,gt.[StartTime]
27 ,gt.[TextData]
28 FROM fn_trace_gettable(@tracefile, DEFAULT) gt
29 LEFT JOIN sys.trace_subclass_values sv ON gt.[eventclass] = sv.[trace_event_id] AND sv.[subclass_value] = gt.[objecttype]
30 INNER JOIN sys.trace_events e ON gt.[eventclass] = e.[trace_event_id]
31 INNER JOIN sys.trace_categories c ON e.[category_id] = c.[category_id]
32 WHERE gt.[spid] > 50  --50以内的spid为系统使用
33   AND gt.[DatabaseName] = ‘TraceDB‘  --根据DatabaseName过滤
34   --AND gt.[ObjectName] = ‘Trace_log‘  --根据objectname过滤
35   --AND e.[category_id]  = 5  --category 5表示对象,8表示安全
36   AND e.[trace_event_id] = 92 --sp_trace_setevent(20Audit Login Failed、46Object:Created、47Object:Deleted、92DataGrow、93LogGrow、94DataShrink、95LogShrink、164Object:Altered)
37 ORDER BY [StartTime] DESC
38
39 --查找库下占用空间前N的表
40 select object_name(a.object_id) tablename,a.row_count,a.space_in_M,a.space_in_G
41 ,isnull(b.space_in_M,0) index_in_M,isnull(b.space_in_G,0) index_in_G
42 ,g.groupname,i.indid from(
43 select top 200 a.object_id,sum(row_count) row_count
44 ,sum(a.reserved_page_count)*8/1024 space_in_M,sum(a.reserved_page_count)*8/1024.00/1024 space_in_G
45 from sys.dm_db_partition_stats a(nolock) JOIN sys.all_objects b(NOLOCK)
46 ON a.object_id=b.object_id
47 where a.index_id<=1
48 AND b.type=‘U‘ AND b.is_ms_shipped=0
49 group by a.object_id
50 order by space_in_M desc
51 )a
52 left join(
53 select a.object_id,sum(row_count) row_count
54 ,sum(a.reserved_page_count)*8/1024 space_in_M,sum(a.reserved_page_count)*8/1024.00/1024 space_in_G
55 from sys.dm_db_partition_stats a(nolock) JOIN sys.all_objects b(NOLOCK)
56 ON a.object_id=b.object_id
57 where a.index_id>1
58 AND b.type=‘U‘ AND b.is_ms_shipped=0
59 group by a.object_id
60 )b
61 on a.object_id=b.object_id
62 left join (select id,indid,groupid from sysindexes where indid<=1) i
63 on a.object_id=i.id
64 left join sysfilegroups g
65 on i.groupid= g.groupid
66 --where i.groupid is null
67 order by (a.space_in_M) desc
68
69 --查看表占用/剩余空间情况
70 sp_spaceused ‘TradeDetail‘
71
72 --查看表碎片情况
73 select [object_id],partition_number,index_type_desc,alloc_unit_type_desc,index_depth
74       ,avg_fragmentation_in_percent,fragment_count,avg_fragment_size_in_pages,page_count
75   from sys.dm_db_index_physical_stats(DB_ID(),OBJECT_ID(‘TradeDetail‘),NULL,NULL,‘LIMITED‘)
76
77 --查看索引使用情况
78 SELECT o.name,i.name,i.index_id,ddius.user_seeks,ddius.user_scans,ddius.user_lookups,ddius.user_updates
79 ,ddius.last_user_seek,ddius.last_user_scan,ddius.last_user_lookup,ddius.last_user_update
80   FROM sys.dm_db_index_usage_stats ddius
81 INNER JOIN sys.objects o
82 ON ddius.[object_id]=o.[object_id]
83 INNER JOIN sys.indexes i
84 ON ddius.[object_id]=i.[object_id]
85 AND ddius.index_id=i.index_id
86 WHERE database_id = DB_ID()
87 AND ddius.object_id=OBJECT_ID(‘TradeDetail‘)

当然在处理的过程中还会遇到一些其他问题,问题又可以衍生出其他话题,往往接触得越多,把知识点进行整理归类,就可以融会贯通。

时间: 2024-12-24 18:29:52

分区表的数据删除的相关文章

Windows 8.1 重复数据删除——规划部署(二)

一.规划部署目标   Windows 8.1&Server 2012 的重复数据删除设计为安装到主要数据卷上,而无需添加任何附加的专用硬件.这意味着你可以安装和使用该功能,而不会影响服务器上的主要工作负载.默认设置为非侵入性的,因为它们允许在处理特定文件之前数据"存留时间"达到五天,默认的最小文件大小为 32 KB.该实现是为低内存和 CPU 利用率而设计的.如果内存利用率变高,则重复数据删除功能将等待可用的资源.管理员可以根据所涉及数据的类型以及该卷或特定文件类型的更改频率和

mbr分区表备份、删除和恢复

磁盘分区表备份.删除和恢复 简要说明 MBR分区磁盘的分区表信息存放在硬盘0磁道第0个扇区内总共512字节 前446字节为bootloader. 中间64位为磁盘分区表信息,每个分区信息占16个字节,总计存放4个分区.(这段就是需要备份出来的数据) 最后的aa55为结束标志位. 一.分区表的备份 首先先查看下硬盘前512字节,从2080开启时至aa55前的64字节就是我们需要备份的磁盘分区表 [root@centos7 ~]# hexdump -n 512 /dev/sda 0000000 63

磁盘分区表备份、删除和恢复

磁盘分区表备份.删除和恢复 分区表的备份  MBR分区表存放在硬盘0磁道第0个扇区内,总共512字节,前446字节为bootloader,中间64位为磁盘分区表信息,每个分区信息占16个字节,总共存放在4个分区.  查看硬盘的十六进制文件,在硬盘前512字节中,从2080开始至aa55前的64字节就是我们需要备份的磁盘分区表 备份 使用 dd 命令将硬盘分区表的信息进行备份 查看备份出来的数据,确保正确性. 将备份的文件传至远程主机上,或者将其复制到U盘进行备份. 登陆远程主机,并查看数据,确保

mongo数据删除和游标

数据删除 db.集合.remove(删除条件,是否只删除一个数据);默认删多条(false)true删除一条db.集合.remove({}) 删除所有元素但集合还在db.集合.drop() 删除集合 游标指数据可以一行行的进行操作,类似ResultSet数据处理在mongo里是需要使用find()就可以返回游标了对于操作返回的游标,可使用函数操作1.判断是否有下一行数据:hasNext()2.取当前数据: next() var cur=db.web.find();cur.hasNext();cu

SQL从入门到基础 - 04 SQLServer基础2(数据删除、数据检索、数据汇总、数据排序、通配符过滤、空值处理、多值匹配)

一.数据删除 1. 删除表中全部数据:Delete from T_Person. 2. Delete 只是删除数据,表还在,和Drop Table(数据和表全部删除)不同. 3. Delete 也可以带where子句来删除一部分数据:Delete from T_Person where FAge>20. 二.数据检索 1. 执行备注中的代码创建测试数据表. 2. 简单的数据检索:select *from T_Employee(*表示所有字段) 3. 只检索需要的列:select FNumber

数据删除:delete

--数据删除:在删除的时候需要询问是否真的需要删除?同时在之后的项目中,删除往往不是真的删除,而是做删除标记--语法:--delete from 表名 where 条件 delete from Teacher--删除指定的人员信息delete from Teacher where Id=26--使用delete删除的特点:--1.它是一条条记录进行删除.每一次的删除都需要将操作记录到日志文件中,效率不高.--2.它不会让标识列重新从标识种子计算,而是继续之前的最后一条记录的标识列 --trunc

Windows Server 2012R2之重复数据删除实战

Windows 8.1重复数据删除理论与windows server 2012R2重复数据删除理论相似,相关理论信息请参考: Windows 8.1 重复数据删除--概念(一)and Windows 8.1 重复数据删除--规划部署(二) 相关理论信息不再赘诉,具体请参考相应官网信息.需提前申明,如系统奔溃或磁盘更换等因素导致数据不完整情况请重新开启对应操作系统上重复数据删除功能以保证数据的完整与可用性(注:Windows 7上暂时还未在官网收到支持相关信息).启用及配置步骤如下: 一.启用wi

Windows 8.1 重复数据删除——概念(一)

功能描述 重复数据删除指的是在数据中查找和删除重复内容,而不会影响其保真度或完整性.其目标是通过将文件分割成大小可以改变 (32-128 KB) 的小区块.确定重复的区块,然后为每个区块保留一个副本,从而在更小的空间中存储更多的数据.区块的冗余副本由对单个副本的引用所取代.区块会进行压缩,然后以特殊的容器文件形式组织到 System Volume Information 文件夹中. 针对卷启用了重复数据删除而且对数据进行优化之后,卷中会包含以下内容: 未优化的文件:例如,未优化的文件可以包括:无

重复数据删除(dedup)技术介绍 1

重复数据删除(de-duplication)是存储领域,尤其是数据备份领域的一个非常重要的概念.其目的是删除重复的数据块,从而减少对存储空间的使用. 这种想法的出发点是非常自然的.通常情况下,每次备份的数据总是会有一部分跟上一次备份的数据重合. 比如,每次备份都要包含一个100MB的文件,那么这个文件就会重复出现在所有的备份数据中. 经过多次备份操作之后,重复的数据块就会占用可观的存储空间,而实际上,这些重复的数据块保留一份就足够了. dedup就是为了解决这种问题而产生的. dedup和数据压