So here's what happened:
I was running out of space on my DB partition (there was a sudden surge in
DB size due to a lot of scanned documents being attached in a short period
of time). To free up space for a day or two while I waited for an
additional drive to add to the RAID set, I decided to temporarily move an
older, infrequently-accessed database to another volume. Here's what I did:
- I stopped the server and server agent services for the database I was
moving -- I'll call it Old-DB -- , then simply copied its entire MSSQL
folder, lock stock and barrel, to a network share on another server.
- When the new drive arrived a day later, I added it to the RAID set and
increased the size of the volume.
- I rebooted the SQL server for reasons unrelated to this issue. On
startup, it reported that a driver or service had failed because the Old-DB
had tried to start, but of course it's MSSQL folder wasn't there.
- I copied the MSSQL folder for Old-DB back to its original location on the
SQL server.
Now I get a 1053 error when trying to start the SQL Server, and a 1068 error
when trying to start the SQL Server Agent. Enterprise Manager now shows a
(local) database that's not started, with the message (Connection failed,
check SQL Server Registration Properties) under it.
If I understand correctly, my big worry shouldn't be about the data (which
is probably fine), but about the user logins. Is that right?
What's my next step to getting this DB back online? It's not urgent, but it
IS important that we retain or regain access to the historical data in this
DB.
Thanks in advance!
BJYou should perform a full system restore to recover to the state you were in
before you started moving files.
Then start again and do the job "correctly" i.e. by following the documented
procedures (see Books Online) for moving databases.
"Bryan L" <blinton.nospam@.connellinsurance.nospam.com> wrote in message
news:e3%235claNHHA.2232@.TK2MSFTNGP02.phx.gbl...
> So here's what happened:
> I was running out of space on my DB partition (there was a sudden surge in
> DB size due to a lot of scanned documents being attached in a short period
> of time). To free up space for a day or two while I waited for an
> additional drive to add to the RAID set, I decided to temporarily move an
> older, infrequently-accessed database to another volume. Here's what I
> did:
> - I stopped the server and server agent services for the database I was
> moving -- I'll call it Old-DB -- , then simply copied its entire MSSQL
> folder, lock stock and barrel, to a network share on another server.
> - When the new drive arrived a day later, I added it to the RAID set and
> increased the size of the volume.
> - I rebooted the SQL server for reasons unrelated to this issue. On
> startup, it reported that a driver or service had failed because the
> Old-DB had tried to start, but of course it's MSSQL folder wasn't there.
> - I copied the MSSQL folder for Old-DB back to its original location on
> the SQL server.
> Now I get a 1053 error when trying to start the SQL Server, and a 1068
> error when trying to start the SQL Server Agent. Enterprise Manager now
> shows a (local) database that's not started, with the message (Connection
> failed, check SQL Server Registration Properties) under it.
> If I understand correctly, my big worry shouldn't be about the data (which
> is probably fine), but about the user logins. Is that right?
> What's my next step to getting this DB back online? It's not urgent, but
> it IS important that we retain or regain access to the historical data in
> this DB.
> Thanks in advance!
> BJ
>|||I have a full disk image of the SQL server that was taken just prior to
retiring the database and migrating to the new version of the application.
I'll restore that image to temporary hardware, verify that I can access the
DB, and then use Books Online to lookup and follow an accepted procedure for
moving or restoring that database to a new server.
Thanks for cutting to the chase. :-)
BJ
"Mark Yudkin" <DoNotContactMe@.boingboing.org> wrote in message
news:uwx0LO8NHHA.4172@.TK2MSFTNGP04.phx.gbl...
> You should perform a full system restore to recover to the state you were
> in before you started moving files.
> Then start again and do the job "correctly" i.e. by following the
> documented procedures (see Books Online) for moving databases.
> "Bryan L" <blinton.nospam@.connellinsurance.nospam.com> wrote in message
> news:e3%235claNHHA.2232@.TK2MSFTNGP02.phx.gbl...
>> So here's what happened:
>> I was running out of space on my DB partition (there was a sudden surge
>> in DB size due to a lot of scanned documents being attached in a short
>> period of time). To free up space for a day or two while I waited for an
>> additional drive to add to the RAID set, I decided to temporarily move an
>> older, infrequently-accessed database to another volume. Here's what I
>> did:
>> - I stopped the server and server agent services for the database I was
>> moving -- I'll call it Old-DB -- , then simply copied its entire MSSQL
>> folder, lock stock and barrel, to a network share on another server.
>> - When the new drive arrived a day later, I added it to the RAID set and
>> increased the size of the volume.
>> - I rebooted the SQL server for reasons unrelated to this issue. On
>> startup, it reported that a driver or service had failed because the
>> Old-DB had tried to start, but of course it's MSSQL folder wasn't there.
>> - I copied the MSSQL folder for Old-DB back to its original location on
>> the SQL server.
>> Now I get a 1053 error when trying to start the SQL Server, and a 1068
>> error when trying to start the SQL Server Agent. Enterprise Manager now
>> shows a (local) database that's not started, with the message (Connection
>> failed, check SQL Server Registration Properties) under it.
>> If I understand correctly, my big worry shouldn't be about the data
>> (which is probably fine), but about the user logins. Is that right?
>> What's my next step to getting this DB back online? It's not urgent, but
>> it IS important that we retain or regain access to the historical data in
>> this DB.
>> Thanks in advance!
>> BJ
>
