July 1, 2009 at 10:09 am
SQL Server 2005
I have moved all user tables and indexes out of the primary filegroup. I have verified that only system objects reside in that filegroup.
The primary filegroup is still 11+ GB used with 8GB free (19GB total size).
Question: How can i find out what is consuming 11GB (since nothing besides system objects reside there)?
My query to find objects and indexes per filegroup:
select 'table_name'=object_name(i.id) ,i.indid
,'index_name'=i.name ,i.groupid
,'filegroup'=f.name ,'file_name'=d.physical_name
,'dataspace'=s.name from sys.sysindexes i
,sys.filegroups f ,sys.database_files d
,sys.data_spaces s
where f.data_space_id = i.groupid
--and objectproperty(i.id,'IsUserTable') = 1
and f.data_space_id = d.data_space_id
and f.data_space_id = s.data_space_id
--and i.indid = 1
and s.name = 'Primary'
order by object_name(i.id),f.name,groupid
go
Script to find Filegroup Size
CREATE TABLE #FileDetails (
FileId int , FileGroupId int , TotalExtents int , UsedExtents int ,
"Name" nvarchar( 128 ) , "FileName" nvarchar( 500 ) ,
TotalSize AS ( ( TotalExtents * 64.0 ) / 1024 ) ,
UsedSize AS ( ( UsedExtents * 64.0 ) / 1024 )
)
--Data File Details
INSERT INTO #FileDetails (
FileId , FileGroupId , TotalExtents , UsedExtents , "Name" , "Filename"
)
EXECUTE( 'dbcc showfilestats with tableresults' )
SELECT FILEGROUP_NAME( FileGroupID ) AS FileGroupName ,
FileId ,
"Name" ,
"FileName" ,
(CONVERT(decimal(38,2),TotalSize)) AS FileSizeMB ,
(CONVERT(decimal(38,2),UsedSize)) AS CurrentSizeMB ,
(CONVERT(decimal(38,2),((UsedExtents*1.)/TotalExtents)*100)) AS "%Usage"
FROM #FileDetails
DROP TABLE #FileDetails
I have also defragged all indexes and updated stats (that gave me back about 1GB).
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 1, 2009 at 10:20 am
At this point I'd say shrink the Primary file group. If all you have there now are system objects, no user objects, you can reclaim the unused space.
July 1, 2009 at 10:29 am
shrinking only brings me back to the 11GB though. Total size of the filegroup is 19GB and all it will let me reclaim is the 8GB free space.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 1, 2009 at 10:32 am
I would like to get this filegroup down to a reasonable size (500MB seems very large but is what I was able to get my Dev and QA environments down under quite easily).
I just see no valid reason at this point for the size of the primary group to be so big.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 1, 2009 at 10:34 am
Make sure you are doing the shrink the correct way, and that you really have free space in the files. The script on the link below will tell you how much free space you have in each file, and do an incremental shrink.
Shrink DB File by Increment to Target Free Space
July 1, 2009 at 10:51 am
Thanks for the script suggestion. I like the proposed script and concept.
Shrinking the file is of lesser concern to me right now.
The heart of the matter seems to be finding out what is inside that filegroup that I can't seem to locate that is chewing up all of that space.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 1, 2009 at 12:20 pm
Did you run the script to see how much space is actually used in each datafile? What were the results?
July 1, 2009 at 1:54 pm
After shrinking the primary filegroup (1 file in it), I have no free space. It is currently sitting at 11583 total size and 11572 Used (the used is still increasing with each refresh of the script).
Primary Filegroup is no longer the default, I created a new filegroup to take over for that in the event some table gets created without my knowledge - I don't want it in the primary filegroup.
That said, the fact that the file usage continues to grow in Size also concerns me.
Thanks for the help.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 1, 2009 at 2:00 pm
jason brimhall (7/1/2009)
After shrinking the primary filegroup (1 file in it), I have no free space. It is currently sitting at 11583 total size and 11572 Used (the used is still increasing with each refresh of the script).Primary Filegroup is no longer the default, I created a new filegroup to take over for that in the event some table gets created without my knowledge - I don't want it in the primary filegroup.
That said, the fact that the file usage continues to grow in Size also concerns me.
Thanks for the help.
Why does it concern you? You may have moved all the user database objects out of the Primary filegroup, but that is where the system database objects reside, and they grow as well as there is activity on those objects, it should be expected. Having removed the user database objects, however, it shouldn't experience as much growth.
July 1, 2009 at 2:16 pm
I finally pinned it down.
Thanks to the following articles
http://blogs.msdn.com/duncand/archive/2007/01/27/datadude-and-the-text-filegroup.aspx
I have several of these still in the primary filegroup.
Working on a solution now to get the LOB Columns moved to a different filegroup
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 1, 2009 at 4:27 pm
Why does it concern you? You may have moved all the user database objects out of the Primary filegroup, but that is where the system database objects reside, and they grow as well as there is activity on those objects, it should be expected. Having removed the user database objects, however, it shouldn't experience as much growth.
The concern is with the size of the filegroup. All of the system objects combined (though they will grow) should not be 11GB in our environment. But since I found that: though I had moved the tables, moved constraints using the with move option, and moved all of the indexes - it wasn't moving the LOBs (or is it SOB) columns. And in the timeframe of my first post to the point that I had found the LOB issue - the primary filegroup had grown by 20MB. Sure 20MB is not much, but if it is only procs and system tables that under normal circumstances would be hard-pressed to reach 100MB - I wanted to get it fixed.
Thanks for the help.
As a reference point - I moved one of the LOB (create new table on correct filegroup, import all data, drop old table, rename new table to correct name, and recreate the indexes) off of the Primary and into it's correct home and freed up 1GB out of the Primary filegroup.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 1, 2009 at 4:33 pm
jason brimhall (7/1/2009)
Why does it concern you? You may have moved all the user database objects out of the Primary filegroup, but that is where the system database objects reside, and they grow as well as there is activity on those objects, it should be expected. Having removed the user database objects, however, it shouldn't experience as much growth.
The concern is with the size of the filegroup. All of the system objects combined (though they will grow) should not be 11GB in our environment. But since I found that: though I had moved the tables, moved constraints using the with move option, and moved all of the indexes - it wasn't moving the LOBs (or is it SOB) columns. And in the timeframe of my first post to the point that I had found the LOB issue - the primary filegroup had grown by 20MB. Sure 20MB is not much, but if it is only procs and system tables that under normal circumstances would be hard-pressed to reach 100MB - I wanted to get it fixed.
Thanks for the help.
As a reference point - I moved one of the LOB (create new table on correct filegroup, import all data, drop old table, rename new table to correct name, and recreate the indexes) off of the Primary and into it's correct home and freed up 1GB out of the Primary filegroup.
Can still get bigger. I have a database where my primary file group is over 200MB. But your right, 11GB is pretty big for just system tables. I am glad you figured out what was causing the issue.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply