August 9, 2010 at 3:14 pm
I would consider grouping content databases on seperate mount points instead of splitting databases on secondary files. This will spread out your IO and provide flexibility in addressing IO concerns for particular databases.
The other thing to consider is often larger volumes perform far better than small. So lets say you request 30 GB and that ends up on one hyper (actual number of disks depends on raid config) the performance is going to be horrible compared to 120 GB made up of 4 hypers. You may find that grouping ten content databases together will increase your number of spindles and improve performance of the really active database(s).
The best approach is to work closely with your SAN team and verify performance with SQLIO prior to installing SQL.
Dan
August 9, 2010 at 3:42 pm
On the Temp Db more then likely you will not need a spindle for each core. my guess is the SAN admin already has an array created and he will slice a LUN out of the array. Its going to have many spindle within already, as along as that is the case you should be good to go.
http://technet.microsoft.com/en-us/library/cc966545.aspx
"Divide tempdb into multiple data files of equal size. These multiple files don’t necessarily be on different disks/spindles unless you are also encountering I/O bottlenecks as well. The general recommendation is to have one file per CPU because only one thread is active per CPU at one time. SQL Server allocates pages for tempdb objects in a round-robin fashion (also referred to as proportional fill) so that the latches on PFS and SGAM pages are distributed among multiple files. This is supported both in SQL Server 2000 and SQL Server 2005. There are improvements to the proportional fill algorithm in SQL Server 2005."
August 9, 2010 at 4:23 pm
On the Temp Db more then likely you will not need a spindle for each core. my guess is the SAN admin already has an array created and he will slice a LUN out of the array. Its going to have many spindle within already, as along as that is the case you should be good to go.
http://technet.microsoft.com/en-us/library/cc966545.aspx
"Divide tempdb into multiple data files of equal size. These multiple files don’t necessarily be on different disks/spindles unless you are also encountering I/O bottlenecks as well. The general recommendation is to have one file per CPU because only one thread is active per CPU at one time. SQL Server allocates pages for tempdb objects in a round-robin fashion (also referred to as proportional fill) so that the latches on PFS and SGAM pages are distributed among multiple files. This is supported both in SQL Server 2000 and SQL Server 2005. There are improvements to the proportional fill algorithm in SQL Server 2005."
Viewing 3 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply