We have a new SQL2000 SP3a server built that replaced an
old SQL2000 SP3a server. The only difference between the
2 is that the new one has Win2003 instead of Win2000 and
SAN drives instead of local drives. This new server is
horribly slow. This server runs 8 SQL instances (the onld
one didi too). I ran a comparison backup job and the SAN
took 28 min and the old server with local drives took 12
min. Not too bad, but on one instance we restore prod
backups to it each night. This restore process used to
take about 1 to 1.5 hrs on the local drives. Now it runs
for 4.5 hrs on the SAN drives and isn't even half way
done. The issue is that it's now interferring with
another Prod job that forces me to have to stop the
restore job because it takes so long. It's a Zyotec
(spelling) SAN. Our network admin is looking into it, but
isn't having much luck. Can anybody shed some light on
this for me? Thanks,
Van JonesUnless your SAN people totally botched the configuration of the device, my
guess is that your bottleneck is network. Are you running on fiber or
ethernet? Gig+, 100 MB, 10 MB? HBAs, switches, firewalls, etc?
--
Please post DDL, sample data and desired results.
See http://www.aspfaq.com/5006 for info.
"Van Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:19ab01c53149$19fe0a60$a601280a@.phx.gbl...
> We have a new SQL2000 SP3a server built that replaced an
> old SQL2000 SP3a server. The only difference between the
> 2 is that the new one has Win2003 instead of Win2000 and
> SAN drives instead of local drives. This new server is
> horribly slow. This server runs 8 SQL instances (the onld
> one didi too). I ran a comparison backup job and the SAN
> took 28 min and the old server with local drives took 12
> min. Not too bad, but on one instance we restore prod
> backups to it each night. This restore process used to
> take about 1 to 1.5 hrs on the local drives. Now it runs
> for 4.5 hrs on the SAN drives and isn't even half way
> done. The issue is that it's now interferring with
> another Prod job that forces me to have to stop the
> restore job because it takes so long. It's a Zyotec
> (spelling) SAN. Our network admin is looking into it, but
> isn't having much luck. Can anybody shed some light on
> this for me? Thanks,
> Van Jones|||Here's what our network admin says...
The Network is Gigabit ethernet but the slow down of the
data isn't across the network its on the SAN drives, the
connection to the SAN from the server is 1GB fiber.
>--Original Message--
>Unless your SAN people totally botched the configuration
of the device, my
>guess is that your bottleneck is network. Are you
running on fiber or
>ethernet? Gig+, 100 MB, 10 MB? HBAs, switches,
firewalls, etc?
>--
>Please post DDL, sample data and desired results.
>See http://www.aspfaq.com/5006 for info.
>
>
>"Van Jones" <anonymous@.discussions.microsoft.com> wrote
in message
>news:19ab01c53149$19fe0a60$a601280a@.phx.gbl...
>> We have a new SQL2000 SP3a server built that replaced an
>> old SQL2000 SP3a server. The only difference between
the
>> 2 is that the new one has Win2003 instead of Win2000 and
>> SAN drives instead of local drives. This new server is
>> horribly slow. This server runs 8 SQL instances (the
onld
>> one didi too). I ran a comparison backup job and the
SAN
>> took 28 min and the old server with local drives took 12
>> min. Not too bad, but on one instance we restore prod
>> backups to it each night. This restore process used to
>> take about 1 to 1.5 hrs on the local drives. Now it
runs
>> for 4.5 hrs on the SAN drives and isn't even half way
>> done. The issue is that it's now interferring with
>> another Prod job that forces me to have to stop the
>> restore job because it takes so long. It's a Zyotec
>> (spelling) SAN. Our network admin is looking into it,
but
>> isn't having much luck. Can anybody shed some light on
>> this for me? Thanks,
>> Van Jones
>
>.
>|||Well, who configured your SAN? Did they configure it for SQL Server? It is
not as simple as, "just get a SAN, and SQL Server will be faster." It has
to be configured correctly, both on the SAN side and the OS/SQL Server side,
in order to make it worth the investment...
Have a look at the thread "Running SQL database off of SAN -- is it feasible
?" in this group, started on 3/14. There should be plenty of reading there
for you, with some pointers to finding the smoking gun(s) causing your
performance issues.
--
Please post DDL, sample data and desired results.
See http://www.aspfaq.com/5006 for info.
"Van Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:19d001c5314d$163f57e0$a601280a@.phx.gbl...
> Here's what our network admin says...
> The Network is Gigabit ethernet but the slow down of the
> data isn't across the network its on the SAN drives, the
> connection to the SAN from the server is 1GB fiber.
>
> >--Original Message--
> >Unless your SAN people totally botched the configuration
> of the device, my
> >guess is that your bottleneck is network. Are you
> running on fiber or
> >ethernet? Gig+, 100 MB, 10 MB? HBAs, switches,
> firewalls, etc?
> >
> >--
> >Please post DDL, sample data and desired results.
> >See http://www.aspfaq.com/5006 for info.
> >
> >
> >
> >
> >"Van Jones" <anonymous@.discussions.microsoft.com> wrote
> in message
> >news:19ab01c53149$19fe0a60$a601280a@.phx.gbl...
> >> We have a new SQL2000 SP3a server built that replaced an
> >> old SQL2000 SP3a server. The only difference between
> the
> >> 2 is that the new one has Win2003 instead of Win2000 and
> >> SAN drives instead of local drives. This new server is
> >> horribly slow. This server runs 8 SQL instances (the
> onld
> >> one didi too). I ran a comparison backup job and the
> SAN
> >> took 28 min and the old server with local drives took 12
> >> min. Not too bad, but on one instance we restore prod
> >> backups to it each night. This restore process used to
> >> take about 1 to 1.5 hrs on the local drives. Now it
> runs
> >> for 4.5 hrs on the SAN drives and isn't even half way
> >> done. The issue is that it's now interferring with
> >> another Prod job that forces me to have to stop the
> >> restore job because it takes so long. It's a Zyotec
> >> (spelling) SAN. Our network admin is looking into it,
> but
> >> isn't having much luck. Can anybody shed some light on
> >> this for me? Thanks,
> >>
> >> Van Jones
> >
> >
> >.
> >|||Zyotec SAN's are not the best when it comes to high volume or sustained
loads compared to other SANs such as EMC, EVA etc. They usually don't have
much cache in relation to others as well. If they did not configure the
SAN's drives properly you can get a bit hit over dedicated direct attached
storage. Sounds like they did a really poor job of configuring it for your
intended workload.
--
Andrew J. Kelly SQL MVP
"Van Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:19ab01c53149$19fe0a60$a601280a@.phx.gbl...
> We have a new SQL2000 SP3a server built that replaced an
> old SQL2000 SP3a server. The only difference between the
> 2 is that the new one has Win2003 instead of Win2000 and
> SAN drives instead of local drives. This new server is
> horribly slow. This server runs 8 SQL instances (the onld
> one didi too). I ran a comparison backup job and the SAN
> took 28 min and the old server with local drives took 12
> min. Not too bad, but on one instance we restore prod
> backups to it each night. This restore process used to
> take about 1 to 1.5 hrs on the local drives. Now it runs
> for 4.5 hrs on the SAN drives and isn't even half way
> done. The issue is that it's now interferring with
> another Prod job that forces me to have to stop the
> restore job because it takes so long. It's a Zyotec
> (spelling) SAN. Our network admin is looking into it, but
> isn't having much luck. Can anybody shed some light on
> this for me? Thanks,
> Van Jones|||Van -
Do you know how the drive sets were configured (e.g. RAID level, etc) ?
This can effect performance.
Where are you restoring from ? tape or disk backup ? If tape, channel
speed and cache could be a problem.
Where is this backup located, on the SAN, if so what drive set ?
Reading and Writing to/from the same physical drive could be a problem?
"SANs are great but require a lot of up front care and feeding to deliver on
promises"
"Van Jones" wrote:
> We have a new SQL2000 SP3a server built that replaced an
> old SQL2000 SP3a server. The only difference between the
> 2 is that the new one has Win2003 instead of Win2000 and
> SAN drives instead of local drives. This new server is
> horribly slow. This server runs 8 SQL instances (the onld
> one didi too). I ran a comparison backup job and the SAN
> took 28 min and the old server with local drives took 12
> min. Not too bad, but on one instance we restore prod
> backups to it each night. This restore process used to
> take about 1 to 1.5 hrs on the local drives. Now it runs
> for 4.5 hrs on the SAN drives and isn't even half way
> done. The issue is that it's now interferring with
> another Prod job that forces me to have to stop the
> restore job because it takes so long. It's a Zyotec
> (spelling) SAN. Our network admin is looking into it, but
> isn't having much luck. Can anybody shed some light on
> this for me? Thanks,
> Van Jones
>|||I missed that detail. There is definitely some truth in the statement, "not
all SANs are created equal." Configuration is just as important. Quality
of the drives themselves can be a large factor as well.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:O4VqdJVMFHA.3352@.TK2MSFTNGP10.phx.gbl...
> Zyotec SAN's are not the best when it comes to high volume or sustained
> loads compared to other SANs such as EMC, EVA etc. They usually don't
have
> much cache in relation to others as well. If they did not configure the
> SAN's drives properly you can get a bit hit over dedicated direct attached
> storage. Sounds like they did a really poor job of configuring it for
your
> intended workload.
