SQL DB disconnecting from Isilon

So the error message is calling out a direct UNC path to a network location - and I'm guessing when you authenticate, you are probably getting a 48 hour session token from AD, meaning you don't need to re-authenticate for a couple days.  This isn't the same as mapping a directory to the cluster - as that adds additional authentication caching on the client system that may hold the connection longer, especially if your desktop systems are exhibiting that behavior. 

So first step - I'd make sure you are mapping a drive to the target network location, not just using the UNC name to that .mdf file. 

Second step - I'm not sure if this fits the exact problem, but I did find this blog entry covering a similar topic that suggests another change that could be made here:  https://dirkhondong.wordpress.com/2012/01/27/the-specified-network-name-is-no-longer-available-sql-backup-problem-solved/

Lastly to your question about using the local Admin account - I admit this raises some goosebumps in my mind that there are security implications here.  I'm no DBA nor security expert, however I know this scenerio isn't unique, so I'm certain there are some established best practices around having a SQL DB server with a mounted connection to a storage back-end.  This will be more on the SQL side then on the Isilon side of the equation here, so I'd look around at technet documents or other MS sources for those recommendations. 

Thanks for taking time in answering this one.

I have no idea if SQL server initiates and nightly disconnect and refreshed something we experience this issue on the daytime as well.

SQL server operating system? MSSQL 2008R2 enterprise

Isilon cluster OS version?  v7.1.0.3 Isilon OneFS v7.1.0.3

What kind of authentication?  AD environment? Yes it uses AD authentication

Can the disconnect be tracked to an exact 48 hours or other pattern? We have windows files share mapped to our desktops and they never get disconnected its just we are experiencing the issue on the SQL DB which are mounted through CIFS shares.

SQL Error message

The operating system returned error 64(The specified network name is no longer available.) to SQL Server during a read at offset 0x000000040d0000 in file '\\asp-archive\Archive\xxx\xxx1\xxxa\xxxxxx.mdf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

I beleive the SQL team is mounting the DB using local administrator account which on AD is it recommended to mount the databases with the service accounts in AD ?

Awesome thanks for quick response, I am going to try this right away and let you know by monday. Thank you once again.

Hello,

We mapped a drive to the UNC path and when we try to go and attach an MDF file the drive letter doesnt show up as it is a network drive, so we mounted that UNC path with a drive letter and attached the mdf and ldf file using UNC path.. after like 10 hours the Database is disconnected again. We didn't do the reg edit part yet but the first step you suggested us didnt help us.

At least this is a change in the behavior and on a smaller timeline that might be easier to test.  Previously there was an error message calling out the UNC path - was there a different error in this instance?

At this point I do not have a clear answer to the situation.  It does appear that something is coming in and interrupting stable connections on your network.  Whether this is an expected situation based on your network, I cannot say.  There may be firewall rules, token expirations, or other security settings in place to prevent a long-term connection like this.  The only solution I would use at this point would be a series of trial and error tests in this connection to try and establish a stable connection based on the environment rules, or catch the disconnection in a packet capture to identify the source of the disconnection. 

You may also want to contact Isilon technical support for more direct attention to resolving the issue, as they may have different suggestions and can offer assistance in testing and examining network packet captures. 

is that even a supported configuration to run SQL of a network drive on Isilon ? I am trying to remember one presentation from last EMC World, it was about VNX but it talked about how SMB 3.0 supported multi-channel connectivity so customers could run SQL/Hyper-V directly from a UNC path.

Not that it is helpful, but we are also receiving the same error writing SQL natively-compressed backups to an SMB share on the Isilon. On the most frequently failing backup, it fails after 33 minutes. We have had some other one-offs that are failing, as well, but haven't been able to notice any trends like this one.

We were starting to look into maybe SMB version negotiation or something along those lines. They DBAs were previously writing to Data Domains and just recently migrated their backups to the Isilon, and that's when these issues appeared.

Are you still having your issue? I know this post is now four months old.

Alexandra,

We are experiencing the same issue as you described.  Our SQL VMs are backing up to an Isilon SMB share and randomly failing.  Did you find any resolution?

Thanks!