今天清理业务库数据的时候,开发人员说可以使用truncate table把两个表的所有数据清理掉
这两个表都有自增ID,都做了表分区,单表200GB,使用SELECT IDENT_CURRENT('')的时候两个表
的当前自增值是3000012,这两个表几乎是一模一样的,除了一两个字段不一样
我执行两个SQL语句把两个表都truncate掉,然后就忘记了收缩数据库和重置种子值
由于分区函数的最后一个值是2000000,那么后插入的数据都会积聚在最后一个文件组
1、重置种子值,让数据重新利用第一个文件组
2、修改分区方案,使用 split range,向分区函数添加新值
虽然不重置也可以,但是如果使用split range,向分区函数添加新值工作量就大了,为了不增加工作量当然重置种子值最好
因为当时太忙,继续搬数据库去了
下班回来才想起这件事,还需要收尾工作,马上远程到业务数据库的机器,使用下面的SQL语句查看分区情况
--分区情况SELECT pat.* , fg.[groupname] AS '分区方案对应的文件组名称' , patsch.name '当前分区函数对应的分区方案'FROM sys.destination_data_spaces AS dds INNER JOIN sysfilegroups AS fg ON dds.[data_space_id] = fg.[groupid] INNER JOIN ( SELECT $PARTITION.Fun_New_PostLog_Id(id) AS 分区编号 , MIN(id) AS Min_value , MAX(id) AS Max_value , COUNT(id) AS 记录数 FROM dbo.PostLog GROUP BY $PARTITION.Fun_New_PostLog_Id(id) ) AS pat ON pat.[分区编号] = dds.[destination_id] INNER JOIN sys.partition_schemes AS patsch ON dds.[partition_scheme_id] = patsch.data_space_idORDER BY pat.[分区编号]
发现两个表的新插入的数据都放在第一个文件组,并且自增id又从1开始了
马上测试一下,结果发现truncate table真的重置了种子,以前是知道的,不过以前用到truncate的情况很少
USE [test]GOCREATE TABLE truncatetabletestidentity (id INT IDENTITY(1,1),NAME NVARCHAR(20))GOINSERT [dbo].[truncatetabletestidentity]SELECT 'ni' UNION ALLSELECT 'we' UNION ALLSELECT 'pp'SELECT * FROM [dbo].[truncatetabletestidentity]GOTRUNCATE TABLE [dbo].[truncatetabletestidentity]
接下来收缩数据库,磁盘空间又“多出“了450GB空间,磁盘预警消失了~
如有不对的地方,欢迎大家拍砖o(∩_∩)o
2014-4-7补充:
在MSDN里面提到
DBCC CHECKIDENT (Transact-SQL)
DBCC CHECKIDENT (table_name, RESEED,new_reseed_value) | 将当前标识值设置为new_reseed_value。如果自从创建表以来未在表中插入任何行,或者已使用 TRUNCATE TABLE 语句删除所有行,则在运行 DBCC CHECKIDENT 之后插入的第一行将使用new_reseed_value作为标识。否则,插入的下一行将使用new_reseed_value+当前增量值。 如果该表不为空,那么将标识值设置为小于标识列中的最大值的数字时,将会出现下列情况之一:
|
新闻热点
疑难解答