• Hi there. We experienced a very similar problem you did. Our primary SQL server was a physcial box using multiple LUNs for the database storage (1 LUN for the system dbs, 2 LUNs for Application DBs, and a 4th for the SnapInfo LUN. We were getting sporadic disconnects across multiple servers connecting to the SAN over iSCSI. This brought the SQL Service down when the LUN holding the system dbs got disconnected. I ended up reverting the system db's back to local disk which the physical box. As stop gap i write out a daily SQL backup of the system dbs to a share that is replicated to our DR site. The problem ended up being a bug in the OS for the NetApp. When we upgraded to the newer OS the problem disappeared. I am going to give it a few more months to show any problems before I put the system dbs back on LUNs.

    To answer your question. If you have moved the system db's back to locally attached storage on the physical box then the lun's becoming disconnected will have no affect on the SQL Service. You applications databases may get throw suspect. If you using a single LUN for all your application databases and you have a significant number as we do I would recommend just cycling the SQL service once you have confirmed the LUN is available again. This will let the engine bring the dbs back online and verify they are ok. A simple refresh of MGMT Studio will tell you quickly if any of the dbs got damaged which can also be confirmed by the logs.