Database Snapshot Disk IO considerations and Best Practices

I understand the concept of database snapshots, however, I'm unsure how to tackle this from disk utilization point of view.

First off I'll explain how I want to use database snapshots, then the configurations at the disk level I was considering.

Currently in 2005 we can also find Snapshot Isolation whcih helps with concurrency but it will use the tempdb heavily. Since I have enough things hammering the tempdb I was considering using database snapshots to help with the reporting functionality.

Since a database snapshot creates sparse files there will not be a lot of space being consumed (I'll have a question on this one later). Since creating a database snapshot is pretty light weight I was considering creating a job that will snapshot the database every minute (don't freak out yet let me explain). Then I will have another job to drop snapshots that do not have an active transaction in them. I've created a function that will return the latest available snapshot and using some dynamic SQL I can use that in my reporting code.

I've created all the code for this to happen, but now comes the fun part... where do I put the database snapshots?

Currently my databases have seperated array for Log files, seperate array for the clustered indexes, and a seperate array for non-clustered indexes (as well as partitioned tables, BLOB, etc...). So all together my IO is split up across about 32 spindles. I have 3 spindles in a RAID 5 available. Do I created the database snapshot in the same location as the files (because creating a db snapshot is just like creating a real database). Or to I lump them up on the small array, data and logs and all?

Also, if my database is let say 75GB and I want to snapshot it to a 36GB partition I know that the sparse files will be small and it show actual space on disk to be small but logically it will show at 75GB will SQL or the OS have an issue with that?

Thanks

Rich

If there is a possibility to create another drive then use that to store the backup/snapshot files. I'm not sure if you are using EMC then it will be easy to store them inspite of any issue. Why you want to compress the snapshot in this case.|||I'm not looking to compress anything. I'm not sure if I'm being clear but I'm talking about SQL 2005 new ability to create database snapshots, which automatically creates sparse files. We are using an EMC CX3-20 SAN if that helps.