Crazy table size after modifiying an index

Mojito

Here is the store, if I modify the SQLIndex option in NAV by choosing more selective fields and compile the table then the table size is increasing enormously. I have the same problem with a table optimize from NAV.
The index size usage is going from +/- 200MB to +/- 18GB for a small table. The number of rows and data size are more or less the same.

The strange thing is if I reindex that table afterwards with a SQL statement than the size is back to normal.

The big problem now is if I do this on a table like item ledger entry than that one table is increasing so enormously that my database size goes from 150GB to 415GB. The disk is running full of course because I haven't foreseen that much free space.

If I do this on our test environment than I don't have the problem. The difference between test and production is x32 vs x64 and 2 SQL hotfixes.

Here the environment for Production:
Windows 2003 SP2
SQL Server 2005 Standard x64 SP2 build 3215
NAV 4.0.3 build 25484
4 CPU's
12GB RAM (SQL Limit 10GB)

Here the environment for Test:
Windows 2003 SP2
SQL Server 2005 Standard x32 SP2 build 3042
NAV 4.0.3 build 25484
2 CPU's
3GB RAM

Anyone seen this phenomenon?

Thanks!

kriki

Sounds like the default fillfactor (SQLServer properties=>database settings=>Default index fill factor) on SQLServer is set to a low value (but not 0). Try to put it to 90% or 95%.

Mojito

The fill factor on the SQL Server is set to 0 both on the test and production environment.

We do a daily reindex with a fill factor of 5% for all the entry tables and sales/purchase order table and the rest once per week also with a fill factor of 5%.

kriki

Mojito wrote:

The fill factor on the SQL Server is set to 0 both on the test and production environment.

We do a daily reindex with a fill factor of 5% for all the entry tables and sales/purchase order table and the rest once per week also with a fill factor of 5%.

5% fillfactor? :shock: :shock: :shock:

This means the pages are mostly empty!
It will definitely increase writing speed, but reading speed will be a lot slower.
My experience is that 90% to 95% is best. It leaves enough spaces for most inserts but not too much to slow down reading.

Mojito

Sorry, I meant 5% empty so a fill factor of 95%.

So the fill factor isn't the issue the fact that tables are growing enormously when a key is changed or you do an optimize.

kriki

BTW: how do you check for the index-size usage?

Mojito

By using the stored procedure SP_SpaceUsed and running this query.

CREATE TABLE #TBLSize
 (Tblname varchar(180), 
 TblRows int,
 TblReserved varchar(80),
 TblData varchar(80),
 TblIndex_Size varchar(80),
 TblUnused varchar(80))

DECLARE @DBname varchar(80) 
DECLARE @tablename varchar(180) 

SELECT @DBname = DB_NAME(DB_ID())
PRINT 'User Table size Report for (Server / Database):   ' + @@ServerName + ' / ' + @DBName
PRINT ''
PRINT 'By Size Descending'
DECLARE TblName_cursor CURSOR FOR 
SELECT NAME 
FROM sysobjects
WHERE xType = 'U'

OPEN TblName_cursor

FETCH NEXT FROM TblName_cursor 
INTO @tablename

WHILE @@FETCH_STATUS = 0
BEGIN
   INSERT INTO #tblSize(Tblname, TblRows, TblReserved, TblData, TblIndex_Size, TblUnused)
   EXEC Sp_SpaceUsed @tablename
      
   -- Get the next author.
   FETCH NEXT FROM TblName_cursor 
   INTO @tablename
END

CLOSE TblName_cursor
DEALLOCATE TblName_cursor

SELECT  CAST(Tblname as Varchar(180)) 'Table',
	CAST(TblRows as Varchar(14)) 'Row Count',
	CAST(LEFT(TblReserved, CHARINDEX(' KB', TblReserved)) as int) 'Total Space (KB)',
        CAST(TblData as Varchar(14)) 'Data Space',
	CAST(TblIndex_Size  as Varchar(14)) 'Index Space',
        CAST(TblUnused as Varchar(14)) 'Unused Space'
FROM #tblSize
Order by 'Total Space (KB)' Desc