- How do I turn off marked suspect on
my database?
- On startup, the transaction log of a database has filled
and recovery has suspended, what can I do?
- Why do my page locks not get escalated to a table lock after 200 locks?
Say one of your database is marked suspect as the SQL Server is coming up. Here are the
steps to take to unset the flag.
Remember to fix the problem that caused the database to be marked suspect after
switching the flag.
System 11
- sp_configure "allow updates", 1
- select status - 320 from sysdatabases where dbid = db_id("my_hosed_db") -- save
this value.
- begin transaction
- update sysdatabases set status = -32768 where dbid =
db_id("my_hosed_db")
- commit transaction
- shutdown
- startserver -f RUN_*
- fix the problem that caused the database to be marked suspect
- begin transaction
- update sysdatabases set status = saved_value where dbid =
db_id("my_hosed_db")
- commit transaction
- sp_configure "allow updates", 0
- reconfigure
- shutdown
- startserver -f RUN_*
System 10
- sp_configure "allow updates", 1
- reconfigure with override
- select status - 320 from sysdatabases where dbid = db_id("my_hosed_db") - save
this value.
- begin transaction
- update sysdatabases set status = -32768 where dbid =
db_id("my_hosed_db")
- commit transaction
- shutdown
- startserver -f RUN_*
- fix the problem that caused the database to be marked suspect
- begin transaction
- update sysdatabases set status = saved_value where dbid =
db_id("my_hosed_db")
- commit transaction
- sp_configure "allow updates", 0
- reconfigure
- shutdown
- startserver -f RUN_*
Pre System 10
- sp_configure "allow updates", 1
- reconfigure with override
- select status - 320 from sysdatabases where dbid = db_id("my_hosed_db") - save
this value.
- begin transaction
- update sysdatabases set status = -32767 where dbid =
db_id("my_hosed_db")
- commit transaction
- you should be able to access the database for it to be cleared out. If not:
- shutdown
- startserver -f RUN_*
- fix the problem that caused the database to be marked suspect
- begin transaction
- update sysdatabases set status = saved_value where dbid =
db_id("my_hosed_db")
- commit transaction
- sp_configure "allow updates", 0
- reconfigure
Return to top
You might find the following in the error log:
00:00000:00001:2000/01/04 07:43:42.68 server Can't allocate space for object
'syslogs' in database 'DBbad' because 'logsegment' segment is full/has no free extents. If
you ran out of space in syslogs, dump the transaction log. Otherwise, use ALTER DATABASE
or sp_extendsegment to increase size of the segment.
00:00000:00001:2000/01/04 07:43:42.68 server Error: 3475, Severity: 21, State: 7
00:00000:00001:2000/01/04 07:43:42.68 server There is no space available in SYSLOGS for
process 1 to log a record for which space has been reserved. This process will retry at
intervals of one minute. The internal error number is -4.
which can prevent ASE from starting properly. A neat solution from Sean Kiely (sean.kiely@sybase.com) of Sybase Technical
Support, that works if the database has any "data only" segments.
Obviously this method does not apply to the master database. The Sybase
Trouble Shooting Guide has very good coverage of recovering the master database.
- You will have to bring the server up with trace flag 3608 to prevent the
recovery of the user databases.
- sp_configure "allow updates",1
go
- Write down the segmap entries from the sysusages table for the toasted database.
- update sysusages
set segmap = 7
where dbid = db_id("my_toasted_db")
and segmap = 3
- select status - 320
from sysdatabases
where dbid = db_id("my_toasted_db") -- save this value.
go
begin transaction
update sysdatabases set status = -32768 where dbid = db_id("my_toasted_db")
go -- if all is OK, then...
commit transaction
go
shutdown
go
- Restart the server without the trace flag. With luck it should now have
enough space to recover. If it doesn't, you are in deeper trouble than before, you do
have a good, recent backup don't you?
- dump database my_toasted_db with truncate_only
go
- Reset the segmap entries in sysusages to be those as saved in 3. above.
- Shutdown ASE and restart. (The traceflag should have gone at step 6., but ensure
that it is not there!)
Return to top
Several reasons why this may be happening.
- Are you doing the updates from within a cursor?
The lock promotion only happens if you are attempting to take out 200 locks in a single
operation ie a single insert, update or delete. If you continually loop over a table
using a cursor, locking one row at time, the lock promotion never fires.
Either use an explicit mechanism to lock the whole table, if that is required, or remove
the cursor replacing it with an appropriate join.
- A single operation is failing to escalate?
Even if you are performing a single insert, update or delete, Sybase
only attempts to lock the whole table when the lock escalation
point is reached. If this attempt fails because there is another
lock which prevents the escalation, the attempt is aborted and individual
page locking continues.
Return to top