Defrag on SAN disk ?

I ran the standard Windows Disk Defrag analyzer on my SQL Servers, and wow is
there lots of fragmentation, BUT, they are all on SAN disk, so my question
is, will there be any value in running the defrag ?
I do plan to run it when SQL is not running, that sounds like a good idea.
Jim,
Interesting question. Who is the SAN vendor? SANs store data differently
to "normal" file systems. Blocks do not get overwritten (usually), but a
new block gets written when data changes. So, I'm not entirely sure what
would happen if you ran a disk defrag tool on a SAN volume.
I would first of all make sure that you don't have any SQL Server
fragmentation using DBCC SHOWCONTIG. If this is all OK, then consider
talking to your infrastructure team about this, failing that speak to
the SAN vendor.
I don't think I would want to defrag a SAN, but I'm not 100% sure.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602m.html
Jim Trowbridge wrote:
> I ran the standard Windows Disk Defrag analyzer on my SQL Servers, and wow is
> there lots of fragmentation, BUT, they are all on SAN disk, so my question
> is, will there be any value in running the defrag ?
> I do plan to run it when SQL is not running, that sounds like a good idea.
>
|||I agree. FWIW, our EMC/Dell Engineer told us defragging was not necessary
on our CX series.
Mark Allison wrote:[vbcol=seagreen]
> Jim,
> Interesting question. Who is the SAN vendor? SANs store data
> differently to "normal" file systems. Blocks do not get overwritten
> (usually), but a new block gets written when data changes. So, I'm
> not entirely sure what would happen if you ran a disk defrag tool on
> a SAN volume.
> I would first of all make sure that you don't have any SQL Server
> fragmentation using DBCC SHOWCONTIG. If this is all OK, then consider
> talking to your infrastructure team about this, failing that speak to
> the SAN vendor.
> I don't think I would want to defrag a SAN, but I'm not 100% sure.
>
> Jim Trowbridge wrote:
|||Tell your engineer he is full of sxxx<g>. While a large amount of cache may
abstract some aspects of data being read and written to disk there is always
the fact fragmentation can lead to pages that are not as full as you would
like. If the page is half empty on disk it will be half empty when read
into the sql server data cache as well. This means you can only have half
the amount of data or indexes in cache at any one time. It also means lots
more I/O's (even if they are logical) and that means lots more cpu ect.
Andrew J. Kelly SQL MVP
"Eric Sabine" <mopar41@.mail_after_hot_not_before.com> wrote in message
news:ehM3E8ioEHA.2784@.TK2MSFTNGP14.phx.gbl...[vbcol=seagreen]
> I agree. FWIW, our EMC/Dell Engineer told us defragging was not necessary
> on our CX series.
>
> Mark Allison wrote:
a
>
|||I was answering the file-system fragmentation question, not the data and
index fragmentation question. I did not mean to imply one shouldn't handle
the database fragmentation if the data stores are on a SAN. OK, that being
said, I shot an email to our Engineer and asked again about running a
windows defragmentation on our SAN and he said absolutely keep it defragged
with hard disk defragmentation tool, so regardless of _what_ I was talking
about, I was still wrong. :-O
Thanks Andrew. It's probably beer-thirty for me anyway.
Eric
Andrew J. Kelly wrote:[vbcol=seagreen]
> Tell your engineer he is full of sxxx<g>. While a large amount of
> cache may abstract some aspects of data being read and written to
> disk there is always the fact fragmentation can lead to pages that
> are not as full as you would like. If the page is half empty on disk
> it will be half empty when read into the sql server data cache as
> well. This means you can only have half the amount of data or
> indexes in cache at any one time. It also means lots more I/O's
> (even if they are logical) and that means lots more cpu ect.
>
> "Eric Sabine" <mopar41@.mail_after_hot_not_before.com> wrote in message
> news:ehM3E8ioEHA.2784@.TK2MSFTNGP14.phx.gbl...
|||Have one for me too<g>.
Andrew J. Kelly SQL MVP
"Eric Sabine" <mopar41@.mail_after_hot_not_before.com> wrote in message
news:%230lCGploEHA.868@.TK2MSFTNGP10.phx.gbl...
> I was answering the file-system fragmentation question, not the data and
> index fragmentation question. I did not mean to imply one shouldn't
handle
> the database fragmentation if the data stores are on a SAN. OK, that
being
> said, I shot an email to our Engineer and asked again about running a
> windows defragmentation on our SAN and he said absolutely keep it
defragged
> with hard disk defragmentation tool, so regardless of _what_ I was talking
> about, I was still wrong. :-O
> Thanks Andrew. It's probably beer-thirty for me anyway.
> Eric
>
> Andrew J. Kelly wrote:
>
|||"Eric Sabine" <mopar41@.mail_after_hot_not_before.com> wrote in message
news:%230lCGploEHA.868@.TK2MSFTNGP10.phx.gbl...
> I was answering the file-system fragmentation question, not the data and
> index fragmentation question. I did not mean to imply one shouldn't
handle
> the database fragmentation if the data stores are on a SAN. OK, that
being
> said, I shot an email to our Engineer and asked again about running a
> windows defragmentation on our SAN and he said absolutely keep it
defragged
> with hard disk defragmentation tool, so regardless of _what_ I was talking
> about, I was still wrong. :-O
>
Not necessarily.
Windows defrag may do nothing on the SAN. Oh, the SAN will report it done,
etc, but it may virtualize away the actions and no real difference will
happen.
Again, it depends a lot on the SAN.

> Thanks Andrew. It's probably beer-thirty for me anyway.
> Eric