Timeline for How to rename logical file names in recovery pending database that cannot be recovered?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 8, 2022 at 12:46 | comment | added | J.D. | @evilmandarine Gotcha, yea I've been there. Usually a few minutes of downtime trumps risk of data loss and longer downtime, at least when explained to sensible people lol. All in all, the above process should be accomplishable in about 10 minutes, but obviously ask for a longer maintenance window just in case. Also this is where things like Availability Groups are nice because you can failover to a secondary server, and fix the previous primary, then fail back over if needed, etc. | |
| Mar 8, 2022 at 12:39 | comment | added | evilmandarine | Yep, I think I'll need the maintenance window. I was trying to avoid that at all costs because this is a different, not technical kind of issue now (tight production schedule). | |
| Mar 8, 2022 at 12:35 | comment | added | J.D. |
@evilmandarine The thing I'm unsure of / worried about is if you try dropping A_old if it'll remove the MDF / LDF of the production A database (which is why my precautionary step 2 says to move / copy both databases' files). I believe it'll try (because that's the logical path). It may error out if A is currently connected to / in use, or it may succeed, I'm not sure. So I'd try to get a maintenance window off-hours from production, so you could follow the steps I mentioned. Of course once you have A_old database successfully dropped, you don't have to re-attach it to the same server.
|
|
| Mar 8, 2022 at 12:29 | comment | added | evilmandarine |
A is live in production. Is there a way to do this without getting it offline? Also they don't need to co-exist, if I could access A_old on another (dev) server it would be enough.
|
|
| Mar 8, 2022 at 12:20 | history | answered | J.D. | CC BY-SA 4.0 |