Showing posts with label san. Show all posts
Showing posts with label san. Show all posts

Sunday, February 26, 2012

databases on SAN will not reattach @ SQL server reboot

Hello. I have a SQL 2000 server running on server 2003. The databases are located on a lefthand networks SAN. At SQL server reboot, the databases will not automatically reattach. You can however manually attach them.

Hi Nick,

What error is recorded in the mssql errorlog upon attempting to startup the databases following a reboot? Is there anything recorded in the system/app even logs?

|||The error log states Cannot find E:\%PATH to SAN%|||

Hi

That error may due to SAN storage is not ready at start of Server booting.

Be sure that SAN storage is powered before start of Server.

Review /test SAN configuration.

Thanks

|||

Lefthand Networks SANs are iSCSI, so you should check the start order of the services/drivers.

If SQL tries to start before the iSCSI service is running, you won't be able to access the disks.

Within Service Control Manager, you can add a dependency between SQL and iSCSI so that SQL won't start until iSCSI is up and running.

|||

Nick,

We have seen this frequently on our SQL Server instances connected to our Lefthand SAN. In every instance of the problem, restarting the SQL Server instance/service after the boot had completed fixed the problem (rather than going through and manually attaching each database). As others have mentioned in replies, it is just a matter of the SAN Volumes not getting finished mounting before SQL Server tries to bring the databases online.

|||

Have you found anyway to automate this? Generally @. server reboot the building is unnocupied. Do to the fact that this is connected to live traffic lights the server really cannot be restarted during normal work hours.

edit - the dependancies are already set. I do believe that it is starting the services in order but taking into effect drive spinup and initialization...i think the SQL service is beating it to the punch....anyway to make the SQL service start dead last?

|||

No, I haven't tried to automate the restart of SQL Server after the failure.

If you're up to modifying registry settings, you could try to modify the service start order using ServiceGroupOrder settings to try and get SQL Server to start dead last. Here are some links that talk about it:

http://support.microsoft.com/kb/115486

http://download.sysinternals.com/Files/WindowsInternals-Chapter4.pdf

Databases on different storage

I am newbie in SQL server and have one, maybe dumb question.
I have SQL2000 cluster on Windows 2003 with shared storage on SAN.
Cluster operates with one database only.
I need to temporary attach second database to SQL server, but problem is
that I do not have enought free space on shared storage to place both
databases. It is possible to attach another database in cluster
environment from local one node drive ? No fail-over needed. Problem is
that SQL server in cluster see only shared drives. It should look like
one database in cluster environment and one in not.
Maybe with two instances or virtual servers ?
Thanx.
Short answer is no.
Longer explanation is that in a cluster, all SQL data files must be on a
cluster disk resource that the SQL server is dependant on. YOu cannot use
local storage in a SQL 2000 cluster implementation.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"zycha" <zycha@.NOT_FOR_SPAM.COM> wrote in message
news:OnDuY9v8EHA.2196@.TK2MSFTNGP11.phx.gbl...
> I am newbie in SQL server and have one, maybe dumb question.
> I have SQL2000 cluster on Windows 2003 with shared storage on SAN.
> Cluster operates with one database only.
> I need to temporary attach second database to SQL server, but problem is
> that I do not have enought free space on shared storage to place both
> databases. It is possible to attach another database in cluster
> environment from local one node drive ? No fail-over needed. Problem is
> that SQL server in cluster see only shared drives. It should look like
> one database in cluster environment and one in not.
> Maybe with two instances or virtual servers ?
> Thanx.
|||Hello.
It may be possible to use a mount point. I've done this with two shared physical disk resources that were in the same resource group. That is: I created a folder in a formatted partition on physical disk 1 (let's call it "I:\NDF") and mounted a formatted partition from physical disk 2 on I:\NDF.
I was able to create SQL server data files on the mounted volume, even though the physical disk resource (2) was not in the SQL server resource dependancy list. Apparently SQL server doesn't know that the filesystem has a mount point, but why would it care?
Now, I'm not sure if it will work with a "local" disk, but you may try if you are feeling adventurous. Also, this was on Win2KAS, not 2.003K
Interestingly, and despite warnings against doing this (warnings which I did not read until after it had been operational in a production environment for months), the SQL server worked fine and even went through failovers without a hitch.
It will definitely not survive a failover if you use a local disk, however.
Anyway, I would not normally "suggest" doing this, because it is not supported, but it may be a viable option if you just need a few rows out of a table somewhere.
Goog Luck
jg|||Geoff N. Hiten wrote:
> Short answer is no.
> Longer explanation is that in a cluster, all SQL data files must be on a
> cluster disk resource that the SQL server is dependant on. YOu cannot use
> local storage in a SQL 2000 cluster implementation.
>
thanx