Hi sorry I should have been more clear. These tests were actually run on an Azure virtual machine.

I added four VHDs to the virtual machine and tested with SQLIO...

How come there's no benefit?

I ask because I carried out testing on striping disks by starting with one disk and moving up to four disks. Using SQLIO, sequential reads...

Hi thanks for the response,

Take a look at this: http://instadba.com/azure-vm-sql-server-disk-configuration/

and look at the section that says the following:

"Split your tables and indexes into separate database filegroups and...

Sorry I am being stupid. I have run perfmon on both disks measuring disc bytes write and monitored the activity.

My endless insert statement doesn't cause any disk activity until...

Hi sorry,

I meant more along the lines of

FILEGROUP 1 (2 files) -> File 1 Disk 1, File 2 Disk 2

FILEGROUP 2 (2 files) -> File 1 Disk 1,...

Hi thanks for your response.

Could I spread each of those file groups over the 2 disks in the same way I currently have my primary spread over the 2...

yes this is a virtual machine and it is a large machine (quad core 7gb ram)

8 separate individual disks. I have then split the primary file group up into 8 files and each of those 8 files gets its own individual single disk.

Hi thanks for the response.

In this article for Azure: http://instadba.com/azure-vm-sql-server-disk-configuration/ it says the following: "For OLTP type loads (many small reads and writes) performance will scale linearly as...

Hi thanks for the response.

I added ran CHECKPOINT as well before the first query before the backup and both queries before and after the backup now take the same length...

Hi again,

I have found out what the problem was. Basically it boils down to me now using CHECKPOINT. I think that the following is what was happening:

1) INSERT DATA

2) PAGES...

Yes that is right. This is for performance testing. Originally I was trying to run this query on a database with just one file, and run the exact same query...

That is correct. I run it every time I run the query. The query speeds only go back to normal once I drop and recreate the database, table and days.

OK no problem. I will grab the script off my machine at work tomorrow and post it up for all to see.

It doesn't. It stays at the new speed no matter how many times I run it after the backup