January 25, 2017 at 8:51 pm
Comments posted to this topic are about the item Broken tempdb
January 26, 2017 at 2:01 am
I would have opened the Windows drive management console and changed the drive letter from t: to something else and added t: as additional letter to the d:-drive... (+ maybe created the necessary directories if you placed the TempDB in a special folder as t:\TempDB)
God is real, unless declared integer.
January 26, 2017 at 6:31 am
Steve Jones - SSC Editor - Wednesday, January 25, 2017 8:51 PMComments posted to this topic are about the item Broken tempdb
I actually had this issue yesterday. I had to connect using the DAC after starting SQL with the -f option. When trying to connect with just a trusted connection or the "sa" login, I would get login failures. DAC went right in. I haven't seen anything in the documentation about needing DAC but if someone runs into this, don't forget it's available.
MG
"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies."
Tony Hoare
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
January 26, 2017 at 7:38 am
You can also start up SQL Server using the -T3608 and -T3609 flags, then open SQLCMD and run the ALTER DATABASE tempdb MODIFY FILE...
Be still, and know that I am God - Psalm 46:10
January 26, 2017 at 8:53 pm
I had a discussion about this sort of scenario with my boss a while back when we started getting some odd disk errors. Luckily it was on our test server and not a production box. Hopefully I won't have to test this method out anytime soon!
January 27, 2017 at 1:28 am
This was removed by the editor as SPAM
January 27, 2017 at 5:48 am
Stewart "Arturius" Campbell - Friday, January 27, 2017 1:28 AMNice one, thanks Steve - had such a situation recently, where the SAN malfunctioned.
We had our SAN go off the rails once - it was a bit scary. Thankfully, it was just the backup volume, so the data and log volumes were fine. We recovered what we needed, but ended up partitioning a new SAN volume. I'm was very happy we have a network team. 😛
January 27, 2017 at 6:26 am
Ed Wagner - Friday, January 27, 2017 5:48 AMWe had our SAN go off the rails once - it was a bit scary. Thankfully, it was just the backup volume, so the data and log volumes were fine.
I hope, it was not your only backup copy (and you had mirrors / tape backups) on another media too (otherwise you would have a bad stand, if both, backup and data were corrupt).
God is real, unless declared integer.
January 27, 2017 at 6:34 am
t.franz - Friday, January 27, 2017 6:26 AMEd Wagner - Friday, January 27, 2017 5:48 AMWe had our SAN go off the rails once - it was a bit scary. Thankfully, it was just the backup volume, so the data and log volumes were fine.I hope, it was not your only backup copy (and you had mirrors / tape backups) on another media too (otherwise you would have a bad stand, if both, backup and data were corrupt).
Oh no - the backups were also replicated to another SAN (different physical hardware in a different location) and we also had tape backups. And yes, they've both been tested so we know they're good. 😉
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply