DB - Suspect Mode

  • Hai,

    We had a problem with SQL Server 2K (2 node Cluster). Yesterday night we changed the system time at Domain controller, SQL Server automatically failed over to second node.

    After this one of my database went into suspect mode.

    I have issued the followin queries

    update sysdatabasesset status = status & ~256where name = 'MySuspectDatabase'

    go

    update sysdatabases

    set status = status | -32768

    where name = 'MioSuspectDatabase'

    both the queries executed successfully. Database went to Emergency mode.

    I have stopped the sql server service and started -- still in emergency mode

    I have detached the database, stopped the sql server and started

    Restored the recent full backup - Now db is working fine

    But in sysdatabases it is showing the status=4194320 and  status2=1090650112. what this mean ?

    Is there anyproblem still pending with the DB ?

    Please help


    subban

  • On more thing, it was showing "Error Recovering Database" at SQL server logs. when i restarted the service .

    Now the DB is working without any problem.. but let me know any issue with those status and status2


    subban

  • I'm not sure what happened, though I suspect the time change precipitated it. If you have any doubt about things being ok, especially on a cluster, I'd call MS to determine the root case.

  • Steve,

    Any idea what this status=4194320 and  status2=1090650112

    is it an indication of database is in critical state ?


    subban

  • I can't speak to the status flags, but I have to wonder what is going on with Cluster Services.  What I  have seen at my present employer is that Cluster Services controls node failovers.  I assume that any stopping & restarting of SQL Service services is being done via the Cluster Administrator...

  • Follow up this status codes:

     

    status

    int Status bits, some of which can be set by the user with sp_dboption (read only, dbo use only, single user, and so on):

    1 = autoclose; set with sp_dboption.

    4 = select into/bulkcopy; set with sp_dboption.

    8 = trunc. log on chkpt; set with sp_dboption.

    16 = torn page detection, set with sp_dboption.

    32 = loading.

    64 = pre recovery.

    128 = recovering.

    256 = not recovered.

    512 = offline; set with sp_dboption.

    1024 = read only; set with sp_dboption.

    2048 = dbo use only; set with sp_dboption.

    4096 = single user; set with sp_dboption.

    32768 = emergency mode.

    4194304 = autoshrink.

    1073741824 = cleanly shutdown.

    Multiple bits can be on at the same time.

    status2

    int 16384 = ANSI null default; set with sp_dboption.

    65536 = concat null yields null , set with sp_dboption.

    131072 = recursive triggers, set with sp_dboption.

    1048576 = default to local cursor, set with sp_dboption.

    8388608 = quoted identifier, set with sp_dboption.

    33554432 = cursor close on commit, set with sp_dboption.

    67108864 = ANSI nulls, set with sp_dboption.

    268435456 = ANSI warnings, set with sp_dboption.

    536870912 = full text enabled, set with sp_fulltext_database.

    The primary node made fail-over for the other node, therefore internally the service of cluster uses one timestamp to validate the status of nodes, when the time alteration will be very great, it recommended to effect stop with Cluster Administrator of the SQL, to modify the time and to effect start they tambem way Cluster Administrator.

     

    regards

Viewing 6 posts - 1 through 5 (of 5 total)

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