System procedure sp_spaceused tells you how the data is distributed, and is usually more than accurate enough. Run the following simple TSQL:
DECLARE @R TABLE (TabName sysname, [Row Count] bigint, Reserved varchar(128), Data varchar(128), [Idx Size] varchar(128), Unused varchar(128))
INSERT INTO @R
exec sp_spaceused 'tContactHistory'
SELECT TabName
, [Row Count]
, cast(round(cast(replace(Reserved, ' KB','') as dec(32,2))/1024,2) as dec(32,2)) [Reserved MB]
, cast(round(cast(replace(Data, ' KB','') as dec(32,2))/1024,2) as dec(32,2)) [Data MB]
, cast(round(cast(replace([Idx Size], ' KB','') as dec(32,2))/1024,2) as dec(32,2)) [Idx Size MB]
, cast(round(cast(replace(Unused, ' KB','') as dec(32,2))/1024,2) as dec(32,2)) [Unused MB]
FROM @R
Tell us what you find. If there's a problem with fillfactor, datatypes, or just plain old overzealous indexing, this should give enough of a clue as to where to go next, at least.
Update: the result was:
Well your results are odd. It implies the data is actually used. I also see someone already asked you before how you verified the size of the data, and you replied that you did so by calculating it from the field size. Are you sure you did so correctly? Is it possible that empty strings or special characters were introduced that you can't see, but still take up space? Or that you're dealing with CHAR
as opposed to VARCHAR
fields with the same end result?
See DATALENGTH
function, for instance, to check the length of your variable length columns.
-- For example:
SELECT DATALENGTH(myVarCharColumnName) DLen
FROM tContactHistory
ORDER BY DLen desc
-- Note by checking the column type and storage size from MSDN,
-- you can now use this information to calculate the storage size.
Also, have you tested this hypothesis by for instance copying over part of that data to a new, dummy table and see what happens? Like
SELECT TOP 1000 *
INTO myStorageSizeTest
FROM tContactHistory
WHERE ... -- Insert whatever condition here to only select the new rows where this space problem appeared
Etc. Don't be afraid to test and get creative.
Best Answer
One method to modify SQL scripts is with the
Microsoft.SqlServer.TransactSql.ScriptDom
. Below is a PowerShell script example that changes the file sizes using a TSqlFragmentVisitor implemented in C# that you can extend for your needs. This same technique may be used to change database names, file paths, size, etc.Note that if you are using the PowerShell ISE for script development, you'll need to close and re-open the PowerShell ISE after making changes to the C# code in order to reload the .NET app domain.
Example output: