Installing SQL Server on a SAN - any special requirements?

Once the SAN is setup and the server can see the SAN drives as local drives,
there is nothing else that you need to do from SQL Server point of view. The
installation is the same.
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"dondiego" <erite@.yahoo.com> wrote in message
news:FC5149EF-716A-4BA4-BBC5-B89E3B59EE67@.microsoft.com...
Hello,
I'll be installing SQL Server on a SAN at a customer site for the 1st time
and would like to know if the installation is any different from a standard
SQL Server installation?
Thanks in advance
Don DiegoThanks for that!
"Narayana Vyas Kondreddi" wrote:

> Once the SAN is setup and the server can see the SAN drives as local drive
s,
> there is nothing else that you need to do from SQL Server point of view. T
he
> installation is the same.
> --
> HTH,
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "dondiego" <erite@.yahoo.com> wrote in message
> news:FC5149EF-716A-4BA4-BBC5-B89E3B59EE67@.microsoft.com...
> Hello,
> I'll be installing SQL Server on a SAN at a customer site for the 1st time
> and would like to know if the installation is any different from a standar
d
> SQL Server installation?
> Thanks in advance
> Don Diego
>
>|||SAN attached disks are never as fast as locally attached disks. So if
you have the option put your transaction logs on local disks. If not
make sure that your transaction logs are on their own SAN disk.
*** Sent via Developersdex http://www.codecomments.com ***|||Hello,
I'll be installing SQL Server on a SAN at a customer site for the 1st time
and would like to know if the installation is any different from a standard
SQL Server installation?
Thanks in advance
Don Diego|||Once the SAN is setup and the server can see the SAN drives as local drives,
there is nothing else that you need to do from SQL Server point of view. The
installation is the same.
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"dondiego" <erite@.yahoo.com> wrote in message
news:FC5149EF-716A-4BA4-BBC5-B89E3B59EE67@.microsoft.com...
Hello,
I'll be installing SQL Server on a SAN at a customer site for the 1st time
and would like to know if the installation is any different from a standard
SQL Server installation?
Thanks in advance
Don Diego|||Thanks for that!
"Narayana Vyas Kondreddi" wrote:

> Once the SAN is setup and the server can see the SAN drives as local drive
s,
> there is nothing else that you need to do from SQL Server point of view. T
he
> installation is the same.
> --
> HTH,
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "dondiego" <erite@.yahoo.com> wrote in message
> news:FC5149EF-716A-4BA4-BBC5-B89E3B59EE67@.microsoft.com...
> Hello,
> I'll be installing SQL Server on a SAN at a customer site for the 1st time
> and would like to know if the installation is any different from a standar
d
> SQL Server installation?
> Thanks in advance
> Don Diego
>
>|||SAN attached disks are never as fast as locally attached disks. So if
you have the option put your transaction logs on local disks. If not
make sure that your transaction logs are on their own SAN disk.
*** Sent via Developersdex http://www.codecomments.com ***|||> SAN attached disks are never as fast as locally attached disks.
This is too broad a statement to be generally true. It all depends on the
configuration. I supposed, for a given SAN disk, you could in theory
configure a locally attached disk (e.g. with sufficient number of spindles)
to outperform it. But the other way is also true. For some workloads, it is
almost impossible to configure a locally attached disk to outperform a SAN
disk because you may not be able to find as large amount of cache on a local
controller as you may find on a SAN.
Linchi
"Kevin Hayward" wrote:

> SAN attached disks are never as fast as locally attached disks. So if
> you have the option put your transaction logs on local disks. If not
> make sure that your transaction logs are on their own SAN disk.
>
> *** Sent via Developersdex http://www.codecomments.com ***
>|||> SAN attached disks are never as fast as locally attached disks.
This is too broad a statement to be generally true. It all depends on the
configuration. I supposed, for a given SAN disk, you could in theory
configure a locally attached disk (e.g. with sufficient number of spindles)
to outperform it. But the other way is also true. For some workloads, it is
almost impossible to configure a locally attached disk to outperform a SAN
disk because you may not be able to find as large amount of cache on a local
controller as you may find on a SAN.
Linchi
"Kevin Hayward" wrote:

> SAN attached disks are never as fast as locally attached disks. So if
> you have the option put your transaction logs on local disks. If not
> make sure that your transaction logs are on their own SAN disk.
>
> *** Sent via Developersdex http://www.codecomments.com ***
>|||"dondiego" <erite@.yahoo.com> wrote in message
news:FC5149EF-716A-4BA4-BBC5-B89E3B59EE67@.microsoft.com...
> Hello,
> I'll be installing SQL Server on a SAN at a customer site for the 1st time
> and would like to know if the installation is any different from a
> standard
> SQL Server installation?
> Thanks in advance
> Don Diego
SQL installation is no different. There are some things you can do to get
the most out of the SAN:
For best performance, after attaching the disks to the server, you should
create your SAN partition using diskpart.
Run this command to create it:
create partition primary align=64
Changing the partition alignment setting prevents I/O operations from being
split across multiple sectors, which causes unnecessary overhead. The
recommended setting varies from vendor to vendor, but 64 is good.
Also, you should have separate physical disks for the data and log files.
When you format the data partition, set the cluster size to 64K.