HiveBrain v1.2.0
Get Started
← Back to all entries
patternsqlMinor

Performance impact of Splitting Table across files

Submitted by: @import:stackexchange-dba··
0
Viewed 0 times
impactsplittingfilesperformanceacrosstable

Problem

EDIT: I think the original question (below) was not worded very well, and probably caused confusion. The basic question is:

If I have a SQL Server 2005 database using a single .mdf file and I change it to use 2 files, should I expect performance to increase, decrease or remain the same?

We have an archive database that stores all reports sent out from our company since the beginning of time. As you can imagine the size of the database is large and grows quite quickly (currently 150GB and a few GB a week).

The only table in this database has a numeric primary key and a varbinary(MAX) column holding the file. All documents are retrieved via the primary key and performance is not currently an issue.

The problem we are facing is from the network team who backup and transfer the .mdf file over to our DR site every night. For them it would be better if we had multiple smaller files, rather than one big file. They are also saying it would make it easier to manage allocating space for future growth from our virtual infrastructure that it is sitting on.

Are there likely to be any performance loss/gain in splitting the table across multiple files on different virtual drives (potentially different physical drives).

I don't want to explore the problems of storing documents in a database, or running SQL Server on a VM, and we don't really want to change the database schema if we can help it, due to the cost in rewriting chunks of multiple apps.

Solution

The problem we are facing is from the network team who backup and
transfer the MDF file over to our DR site every night.

Are they really transferring the mdf file to the DR site? If so, stop, now.

If thankfully backups are being taken, or you can persuade them to start taking backups instead of shifting the mdf, split the backup to multiple files.

BACKUP DATABASE [MyDatabase] 
TO 
    DISK = 'D:\MyDatabase_file1.bak'
    , DISK = 'D:\MyDatabase_file2.bak' 
    , DISK = 'D:\MyDatabase_file3.bak' 
    , DISK = 'D:\MyDatabase_file4.bak' 
WITH
    NAME = 'MyDatabase backup'
    , STATS = 10



They are also saying it would make it easier to manage allocating
space for future growth from our virtual infrastructure that it is
sitting on.

If you want to add additional storage to the database by way of additional files, that is also possible.

ALTER DATABASE [MyDatabase] 
ADD FILE 
(
    NAME = MyDatabase_file2,
    FILENAME = 'D:\MSSQL\Data\MyDatabase_file2.ndf',
    SIZE = 64GB,
    FILEGROWTH = 8GB
)


For this particular situation however, one does wonder why the administrators can't manage storage by way of the (storage) virtualisation layer.

Code Snippets

BACKUP DATABASE [MyDatabase] 
TO 
    DISK = 'D:\MyDatabase_file1.bak'
    , DISK = 'D:\MyDatabase_file2.bak' 
    , DISK = 'D:\MyDatabase_file3.bak' 
    , DISK = 'D:\MyDatabase_file4.bak' 
WITH
    NAME = 'MyDatabase backup'
    , STATS = 10
ALTER DATABASE [MyDatabase] 
ADD FILE 
(
    NAME = MyDatabase_file2,
    FILENAME = 'D:\MSSQL\Data\MyDatabase_file2.ndf',
    SIZE = 64GB,
    FILEGROWTH = 8GB
)

Context

StackExchange Database Administrators Q#31203, answer score: 3

Revisions (0)

No revisions yet.