2

We are trying to partition a large history table. Being new to partitioning, I was trying to understand the concept of files and file groups. File groups can be set up in following three ways :

1. Each file group on different disk 
2. File groups on same disk
3. One file group on one disk with all files

MSDN says that you can take advantage of parallel I/O access in first method, if the disk has RAID set up, thus enhancing performance. Second method does not have additional performance benefit, however, maintenance is faster as each file group separates out the file from rest of the database. I searched for performance benefits of the third method. I did not get the definite picture. For the third method, since the files are not divided in file groups, will it affect maintenance, thereby increasing downtime? Does it have any performance gain over the second method?

Community
  • 1
kanu
  • 117
  • 1
  • 2
  • 8

2 Answers2

1

There shouldn't be a performance gain by the third option over the second. When you think about it, it's almost the same as having all your user objects in the PRIMARY filegroup. One performance advantage you can achieve with the second option is to flag the older historical filegroups as read-only once you've confirm no additional data modifications are expected, indexes are rebuilt and statistics updated. Once read-only has been implemented, locking doesn't become an issue when querying data in those filegroups.

MattyZDBA
  • 1,955
  • 3
  • 20
  • 32
1

The 3rd method does not have performance advantages. There are two reasons I can think of that one would be doing this:

  1. You plan to spread files to multiple disks later (move to option 1)
  2. You would have allocation contention with just one file. This is a common problem with high-load tempdb's. It is rare with user databases.

Multiple files on the same disk are detrimental to performance because they cause more random and less sequential IO. This is because a single partition can easily become spread (fragmented) across files.

usr
  • 7,390
  • 5
  • 33
  • 58