September 23, 2001 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/achigrik/fileoptimtips.asp
February 6, 2003 at 12:56 pm
This article, like many others on the topic, seems to perpetuate a very common misconception regarding the use of multiple files and filegroups.
The misconception is that there is no performance benefit to creating multiple files on the same disk or array. This is simply not true. SQL Server creates a single I/O thread per physical file. With only one data file, there is no way to have SQL Server perform parallel reads. It can be seen by watching disk queue length in perfmon, that often when it appears that SQL Server is I/O bound, the physical disk queue is often very low or even zero. This occurs because SQL Server is bound by the fact that it is only reading data through a single I/O thread and therefore not taking advantage of all the physical I/O bandwidth provided by the disk subsystem. The solution is to create multiple files and use filegroups to place objects on other files to ensure parallel reads.
Also, the argument that separating indexes is a bad idea because it does not allow you to backup a table as a unit is really an inadequate argument. By separating indexes and table data on separate filegroups you speed up the processing of bookmark lookups when a non-clustered index is used. In the 7 years I've been doing database consulting, I have yet to see anyone really use the feature of filegroup backup. Usually, anyone who would need to backup the database in parts is already at the point where they are employing other fault tolerance techniques such as BCV's.
April 30, 2003 at 3:03 pm
From MSDN -
"Note In SQL Server 2000, the number of asynchronous I/Os is now managed dynamically inside the database engine, and is not influenced by the number of files or filegroups used, as was the case in SQL Server 7.0. "
Have you found this behavior to be different than stated?
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply