May 12, 2009 at 11:33 am
Windows Server 2000
MS iSCSI Initiator 2.08
Equallogic SAN
Currently my DB's reside on the local C: drive of the server. I want to move the DB's to another drive with more storage.
If I detach/move/attach the DB's to another location on the C: drive, upon opening Enterprise Mananger, the DB's are fine.
If I detach/move/attach the DB's to the S: drive (newly added iSCSI Target), upon opening Enterprise Mananger, the DB's are listed as Suspect.
Any ideas what could cause this? Or what additional steps I should be taking to move these DB's to an iSCSI storage location?
Thanks,
Kerry
May 12, 2009 at 11:40 am
kerry.corcoran (5/12/2009)
Windows Server 2000MS iSCSI Initiator 2.08
Equallogic SAN
Currently my DB's reside on the local C: drive of the server. I want to move the DB's to another drive with more storage.
If I detach/move/attach the DB's to another location on the C: drive, upon opening Enterprise Mananger, the DB's are fine.
If I detach/move/attach the DB's to the S: drive (newly added iSCSI Target), upon opening Enterprise Mananger, the DB's are listed as Suspect.
Any ideas what could cause this? Or what additional steps I should be taking to move these DB's to an iSCSI storage location?
Thanks,
Kerry
But if you move it back from the S: drive to the C: drive after attaching/detatching, it works fine? Are you sure you are moving all of the data and log files to the new S: drive and not leaving some behind by mistake?
The Redneck DBA
May 12, 2009 at 11:53 am
Jason Shadonix (5/12/2009)
But if you move it back from the S: drive to the C: drive after attaching/detatching, it works fine? Are you sure you are moving all of the data and log files to the new S: drive and not leaving some behind by mistake?
Once they are suspect I can not detach them as they are 'grayed out'; attemptting to detach (via GUI or CLI) errors out.
I have verified I can successfully detach/move/attach the DB's - this proves to work when I only move the files (it's only 6 files total - 3 mdf's and 3 ldf's) to another folder on the C:
I have attached a screen shot of the log in hopes this will shed some light.
The odd thing is it works fine as long as I stay on the local drive.
May 12, 2009 at 12:04 pm
Are you validating that the permissions for the files / folders move over as well. I would verify that really well prior to attaching. Looks like a potential permission issue.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
May 12, 2009 at 12:06 pm
The other thing that shows up in a search for that error is that a virus scan may be actually locking the log file. Virus scan should be disabled for all database files (create an exclusion for those files). A post to help on this... - http://www.sqlservercentral.com/Forums/Topic370798-5-1.aspx#bm370799
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
May 12, 2009 at 12:10 pm
David Benoit (5/12/2009)
Are you validating that the permissions for the files / folders move over as well. I would verify that really well prior to attaching. Looks like a potential permission issue.
I checked the permissions, and EVERYONE has full rights. Long term I would adjust this, but for now I am trying to make the process work. So at this point rights should be out of the equation.
May 12, 2009 at 12:12 pm
David Benoit (5/12/2009)
This makes sense, however I am able to successfully detach/move/attach the files if I stay on the local C: drive.
This should rules out a anti virus software.
May 12, 2009 at 12:14 pm
Was hoping that it was scanning the new drive differently. 😉
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
May 12, 2009 at 1:23 pm
Have you run a DBCC on the database prior to detatching just to make sure all is OK?
Also, can you create a dummy database on that S: drive to make sure that works?
The Redneck DBA
May 12, 2009 at 1:51 pm
Issue resolved.
The problem was the MS SQL service was starting prior to the MS iSCSI service; thus the iSCSI target wasn't getting mapped until the SQL server was running.
For infomation on working with service dependencies:
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply