Post reply

After shrinking the master database

  • October 16, 2010 at 10:21 am

    #230531

    This morning, it was discovered that the objects for a new application had been installed in the master database instead of the user database, resulting in the master datafile growing to 4Gb.

    I dropped all the user objects and then shrank the master database to a more reasonable size.

    Unfortunately, running DBCC SHRINKFILE with the TRUNCATEONLY to not perform any page movement did not result in the data file shrinking, so I had to omit this option to shrink the file.

    I am now concerned that the system tables could be highly fragmented, which might cause performance problems. But as system tables cannot be analyzed to determine fragmentation levels and indexes on system tables cannot be rebuilt, I have no way of determining if there could be a problem with fragmentation.

    Any suggestions ?

    SQL = Scarcely Qualifies as a Language

  • October 16, 2010 at 10:33 am

    #1238042

    I wouldn't worry. The tables shouldn't be large enough for there to be a major concern around fragmentation.

    Master database on my desktop has the largest system table with just 2500 rows in it (spt_values)

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply