SQL 2000 running on a Network Appliance 820 filer

SQL 2000 running on a Network Appliance 820 filer

Post by Mark Winkle » Wed, 30 Jan 2002 10:59:10



We have a server running windows 2000 service pack 2 and
SQL 2000 standard on the same machine. We also have a
network appliance 820 filer where the database resides.
The problem is that the SQL Server is getting error 823
severity 24 state 2 SQL I/O 64 network name not available
issues and crashes the application. Is the Network
Appliance 820 filer supported to run SQL 2000? If so How
do we fix this issue? Thank you
 
 
 

SQL 2000 running on a Network Appliance 820 filer

Post by Neil Pik » Wed, 30 Jan 2002 17:11:10


 Mark,  

 I don't believe it is.  MS supported them with SQL 7, but I don't think they
officially do with SQL 2000

 You need to pin Network Appliance down on this one.....

Quote:> We have a server running windows 2000 service pack 2 and
> SQL 2000 standard on the same machine. We also have a
> network appliance 820 filer where the database resides.
> The problem is that the SQL Server is getting error 823
> severity 24 state 2 SQL I/O 64 network name not available
> issues and crashes the application. Is the Network
> Appliance 820 filer supported to run SQL 2000? If so How
> do we fix this issue? Thank you

Q.     Can I create SQL Server databases on network drives?

A.  First ask yourself what your reason is for doing this?  Your performance
will almost certainly be degraded and any network glitches (which are far more
common than SCSI/fibre bus glitches) will cause a database corruption.  Putting
i/o's across a network (even a fast, switched, network) is typically slower
than via SCSI/fibre and the latency is a lot longer.  Network packet sizes are
much smaller than scsi packets giving less throughput and more cpu utilization
by the device drivers on the host.

If you do use a network drive then make sure you have a dedicated cross-over or
switched connection between the SQL Server box and the network drive machine
otherwise your performance will be further affected by contention with other
network traffic.

SQL Server currently has no concept of sharing a database that is held on
another server.  Only one server can access the database file at any one time -
the exception being that multiple SQL Servers could probably open a read-only
database on a shared-drive.  Therefore there is no advantage to having it on a
"network drive" - it can only be backed-up/accessed from the server running SQL
Server anyway.

If the reason for wanting SQL databases on a network drive is to keep all your
storage central, then you can't completely achieve that result this way as you
can't boot NT from a network drive, so you would still need disks in local
servers for NT, pagefiles etc.  And these should be protected via hardware raid
as the loss of an NT disk will prevent users getting at your databases just as
much as the loss of a disk containing the database itself.

Now saying that it IS possible to store databases on network drives as long as
SQL is fooled into thinking they are in fact local drives.  Under 6.5 you must
map a drive letter to a network share - UNC paths will not work.  With SQL 7.0
UNC paths will work as long as you use trace flag 1807.

There is more information on this in Q196904.  This describes the support being
allowed in SQL 7.0 for use against Network Appliance networked raid units only.
 Note that these will suffer the same performance penalties as if you were
accessing a network share on an NT box, as effectively that is what they are.  
These boxes run a proprietary operating system on an embedded Alpha chip that
talks the SMB protocol required to handle NT-style network file-io.  They can
be connected to almost any LAN/WAN infrastructure as they support all the
standard network types.

If you want centralised storage another method is to use a shared-SCSI/fibre
disk array - these can be attached to servers via SCSI or fibre connectors and
can achieve distances of up to 20Km using optical extenders.  These arrays can
support up to 64 or so separate servers and are sold by Digital (Compaq)
Storageworks and EMC amongst others.  Although it is a "single raid unit", each
server sees a physically separate set of "disks" - the partitioning logic in
the raid array can allow different servers to use the same physical disks but
they are logically partitioned and the different servers cannot see this and
see their storage as dedicated.  There is no sharing of data at the
partition/file/database level.

Another method is to use a SAN - storage area network.  These are fibre or
copper based "networks" of storage and/or backup devices.  The "network" is
dedicated for data access. Each attached device is usually fibre-channel based,
or is SCSI with an appropriate connector.  Each device may be able to be
partitioned into sets of available resources (disk/tape), but each resource can
currently only be allocated to a single server attached to the "network".  
Servers attach to a SAN with a SAN "nic" card.  As SAN technology matures it
may be possible to share resources between multiple servers, but this needs
changes to the NT kernel as well as the SAN/fibre drivers.

===

v1.07 2000.05.25
Applies to SQL Server versions  : All
FAQ Categories                  : Database Administration
Related FAQ articles            : n/a
Related Microsoft Kb articles   : Q196904 "Support for Network Database Files"
Other related information       : n/a
Authors                         : Neil Pike

 Neil Pike MVP/MCSE.  Protech Computing Ltd
 Reply here - no email
 SQL FAQ (484 entries) see
 http://forumsb.compuserve.com/gvforums/UK/default.asp?SRV=MSDevApps
 (faqxxx.zip in lib 7)
 or www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
 or www.sqlserverfaq.com
 or www.mssqlserver.com/faq

 
 
 

SQL 2000 running on a Network Appliance 820 filer

Post by John Gose [M » Sun, 03 Feb 2002 04:26:59


Mark,

I have not been able to find the device on the HCL list.  What does Network
Appliance have to say?  Maybe I am looking in the wrong spot.

www.microsoft.com/hcl

John Gose
MCDBA
Microsoft SQL Server Support

This posting is provided "AS IS", with no warranties, and confers no rights

Are you secure? For information about the Microsoft Strategic Technology
Protection Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.

--------------------
| Date: Tue, 29 Jan 2002 08:11:10 GMT
| Mime-Version: 1.0
| Content-Type: text/plain; charset=iso-8859-1
| Content-Transfer-Encoding: 8bit
| X-Newsreader: Virtual Access by Atlantic Coast PLC,
http://www.atlantic-coast.com/va
| Organization: Protech Computing Ltd

| Subject: Re: SQL 2000 running on a Network Appliance 820 filer

|
<Snip of Header Stuff>
|
|  Mark,  
|  
|  I don't believe it is.  MS supported them with SQL 7, but I don't think
they
| officially do with SQL 2000
|
|  You need to pin Network Appliance down on this one.....
|  
| > We have a server running windows 2000 service pack 2 and
| > SQL 2000 standard on the same machine. We also have a
| > network appliance 820 filer where the database resides.
| > The problem is that the SQL Server is getting error 823
| > severity 24 state 2 SQL I/O 64 network name not available
| > issues and crashes the application. Is the Network
| > Appliance 820 filer supported to run SQL 2000? If so How
| > do we fix this issue? Thank you
|
| Q.     Can I create SQL Server databases on network drives?
|
| A.  First ask yourself what your reason is for doing this?  Your
performance
| will almost certainly be degraded and any network glitches (which are far
more
| common than SCSI/fibre bus glitches) will cause a database corruption.  
Putting
| i/o's across a network (even a fast, switched, network) is typically
slower
| than via SCSI/fibre and the latency is a lot longer.  Network packet
sizes are
| much smaller than scsi packets giving less throughput and more cpu
utilization
| by the device drivers on the host.
|
| If you do use a network drive then make sure you have a dedicated
cross-over or
| switched connection between the SQL Server box and the network drive
machine
| otherwise your performance will be further affected by contention with
other
| network traffic.
|
| SQL Server currently has no concept of sharing a database that is held on
| another server.  Only one server can access the database file at any one
time -
| the exception being that multiple SQL Servers could probably open a
read-only
| database on a shared-drive.  Therefore there is no advantage to having it
on a
| "network drive" - it can only be backed-up/accessed from the server
running SQL
| Server anyway.
|
| If the reason for wanting SQL databases on a network drive is to keep all
your
| storage central, then you can't completely achieve that result this way
as you
| can't boot NT from a network drive, so you would still need disks in
local
| servers for NT, pagefiles etc.  And these should be protected via
hardware raid
| as the loss of an NT disk will prevent users getting at your databases
just as
| much as the loss of a disk containing the database itself.
|
| Now saying that it IS possible to store databases on network drives as
long as
| SQL is fooled into thinking they are in fact local drives.  Under 6.5 you
must
| map a drive letter to a network share - UNC paths will not work.  With
SQL 7.0
| UNC paths will work as long as you use trace flag 1807.
|
| There is more information on this in Q196904.  This describes the support
being
| allowed in SQL 7.0 for use against Network Appliance networked raid units
only.
|  Note that these will suffer the same performance penalties as if you
were
| accessing a network share on an NT box, as effectively that is what they
are.  
| These boxes run a proprietary operating system on an embedded Alpha chip
that
| talks the SMB protocol required to handle NT-style network file-io.  They
can
| be connected to almost any LAN/WAN infrastructure as they support all the
| standard network types.
|
| If you want centralised storage another method is to use a
shared-SCSI/fibre
| disk array - these can be attached to servers via SCSI or fibre
connectors and
| can achieve distances of up to 20Km using optical extenders.  These
arrays can
| support up to 64 or so separate servers and are sold by Digital (Compaq)
| Storageworks and EMC amongst others.  Although it is a "single raid
unit", each
| server sees a physically separate set of "disks" - the partitioning logic
in
| the raid array can allow different servers to use the same physical disks
but
| they are logically partitioned and the different servers cannot see this
and
| see their storage as dedicated.  There is no sharing of data at the
| partition/file/database level.
|
| Another method is to use a SAN - storage area network.  These are fibre
or
| copper based "networks" of storage and/or backup devices.  The "network"
is
| dedicated for data access. Each attached device is usually fibre-channel
based,
| or is SCSI with an appropriate connector.  Each device may be able to be
| partitioned into sets of available resources (disk/tape), but each
resource can
| currently only be allocated to a single server attached to the "network".

| Servers attach to a SAN with a SAN "nic" card.  As SAN technology matures
it
| may be possible to share resources between multiple servers, but this
needs
| changes to the NT kernel as well as the SAN/fibre drivers.
|
| ===
|
| v1.07 2000.05.25
| Applies to SQL Server versions  : All
| FAQ Categories                  : Database Administration
| Related FAQ articles            : n/a
| Related Microsoft Kb articles   : Q196904 "Support for Network Database
Files"
| Other related information       : n/a
| Authors                         : Neil Pike
|
|  Neil Pike MVP/MCSE.  Protech Computing Ltd
|  Reply here - no email
|  SQL FAQ (484 entries) see
|  http://forumsb.compuserve.com/gvforums/UK/default.asp?SRV=MSDevApps
|  (faqxxx.zip in lib 7)
|  or www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
|  or www.sqlserverfaq.com
|  or www.mssqlserver.com/faq
|
|