We have a single HA SQL Infrastructure where the server holds multiple databases from various of applications and various degrees of IO. We lean towards a single volume for all the databases (expandable via SAN as needed) and single volume for all the logs (expandable via SAN as needed). To keep things in control you would normally should perform backups of the databases which would normally reclaim the logs and truncate into the databases accordingly. Then on a scheduled (quarterly, semi-annually, or annual) basis, we would compact (shrink) the database. As long as the backend SAN can handle the IO, you should be able to maintain the system. You can utilize it via iSCSI or Fibre. Just make sure you have redundant paths to the volumes. ------------------ OK, first you shouldn't ever be shrinking your databases. If your databases grow to a larger size then need the space. If a single LUN can handle all the IO for your databases, then that is fine. Otherwise you'll need multiple LUNs for the storage. Some other things that you'll need to keep in mind, is that the SQL Server has enough procedure cache, and enough buffer cache for the databases in question. You'll need to ensure that you aren't doing so much context switching that you are slowing down the system by simply switching contexts to much.

We have a single HA SQL Infrastructure where the server holds multiple databases from various of applications and various degrees of IO. We lean towards a single volume for all the databases (expandable via SAN as needed) and single volume for all the logs (expandable via SAN as needed). To keep things in control you would normally should perform backups of the databases which would normally reclaim the logs and truncate into the databases accordingly. Then on a scheduled (quarterly, semi-annually, or annual) basis, we would compact (shrink) the database. As long as the backend SAN can handle the IO, you should be able to maintain the system. You can utilize it via iSCSI or Fibre. Just make sure you have redundant paths to the volumes. ------------------ OK, first you shouldn't ever be shrinking your databases. If your databases grow to a larger size then need the space. If a single LUN can handle all the IO for your databases, then that is fine. Otherwise you'll need multiple LUNs for the storage. Some other things that you'll need to keep in mind, is that the SQL Server has enough procedure cache, and enough buffer cache for the databases in question. You'll need to ensure that you aren't doing so much context switching that you are slowing down the system by simply switching contexts to much.