CRITICAL PROBLEM - Tempdb detached

  • SQL server 2K started with -T3608 parameter.

    tempdb detached.

    ...

    Now tempdb can't be attached because model not activated, model not activated because of -T3608 switch. Try start SQL w/o the -T3608 paramter and SQL fails to start - can't find DB id 2 (i.e. tempdb!).

    What now ??

  • What do you mean Model database is not activated? Is it detached too? Satrt SQL Server with -T3608 and try to attach Model database back first, remove -T3608 and stop and restart SQL Server.

  • OK ... it worked !!!!

    KIDS - do not try this at home, and NOWHERE near your prod boxes (or as in our case, your busy-implementing, soon-to-be, prod server).

    In summary, this is what went on

    ****************************************

    Problem :

    TempDB was detached instead of Modified

    Effect :

    -------------

    Problem is that when you re-attach tempdb it gets the next available dbid.

    However, the tempdb dbid is hardcoded as (2).

    This means we need to get it reset to 2.

    However, without TempDB its impossible to change data. (Or for that matter to get SQL Server up - without using the -T3608 flag)

    Solution :

    ----------

    1. Stop SQL, copy away ALL original databases (model, msdb, master, tempdb remains)

    2. Procure a copy of master from another SQL2k db.

    3. Get this running normally (detach other db's, move files around etc)

    4. Attach broken master on another name.

    5. Since box is now working normally (albeit with other server's settings etc) you can edit and change parameters

    6. Configure 'Allow updates' to 1 and reconfigure with override

    7. Update master copy's sysdatabases to make tempdb dbid 2 again, update status while you're at it (just in case)

    8. Stop the server

    9. Copy away the other server's files thats working to a safe place (JIC)

    10. Copy the edited datafiles back into the original master location with rename

    11. Start SQL

    12. Make a Wish

    13. SQL Should come up normally.

    **************************

    Now the reason we're still kinda ok with this is, tempdb get's re-created (almost) everytime SQL starts, so the fact that we ran for 1 SQL start with a hacked tempdb is ok. Next SQL start will re-create tempdb from model, and then your smiling (so far, anyway).

    PS - in case your wondering, SQL started after a server re-boot with no issues. And the crowd went WILD !!!!

    *#&#* *#&#* *#&#* *#&#*

    Chaos, Disorder and Panic ... my work is done here!

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply