Skip to Content

dbcc reboot(reboot, DB_A) also shoots DB_B processes too

Sep 13, 2017 at 08:55 PM


avatar image

I have a situation. I have a dataserver (ASE 15.7.0) on a SOLARIS 10 box. I have 25 databases. In the past we had overnight DB load failures of some DB due to the kill process not killing all of the DB attached process. To get around this I started using dbcc reboot which did the job perfectly! However, lately we have noticed that the dbcc reboot command will not only stop process attached to the given DB but will also shoot process associated with other DB. The innocent DB process are part of a massive EOD job which ideally we'd like to survive the dbcc onslaught of it's neighboring DB. I'd like to know if :-

a) anyone else out there has come across this 'feature'

b) why does it do this

c) how can I stop it doing this

Thanks in advance for even glancing at this frustration.

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Bret Halford
Sep 13, 2017 at 09:04 PM

Hi Colin,

Are all processes in the other database being killed, or just some?

Is there any possibility that the killed spids based in the other database were doing cross-database joins involving objects in the database you were running dbcc reboot on?


Show 5 Share
10 |10000 characters needed characters left characters exceeded

Morning Bret,

just one or two processes are killed.

There are no cross DB joins between Assassin and victim. :-(



Keep in mind that cross-database references could occur in queries, procs, triggers, views, user-defined functions, encryption key access (when stored in 'other' db) and ... last but not least ... run-time validation of cross-db RI constraints.


Hi Mark,

there is no cross-referencing between DB. Each instance is defined as in independent entity within the DS. They are copies of a single DB that has been cloned a dozen times into the DS.



Ok. Have you been able to figure out what kind of activity (reorg? update stats? bulk inserts? general dml?) the processes were doing when they got killed? Any commonalities or patterns?

Do the two databases share any resources? (allocations on the same disk, named cache?)

Are any messages being sent to the clients when they are killed?

It would need to be worked through a support incident, but one way to look at this would be to take a manual shared memory dump immediately before the dbcc dbreboot, then note which spids were unexpectedly killed. Support could then look in the memdump to see what those spids had been doing and whether they were attached to any resources of the rebooted database.

A quick and dirty (but much less robust) version of that would be to select the contents of sysprocesses and syslocks into permanent tables just before the dbreboot and use that to see what the killed spids were doing and to verify they at least held no locks in the rebooted database. The MDA monitoring tables, if set up, may also tell more (look up the killed spids in monOpenObjectActivity, monSysSQLText, ...)



Cheers Bret, plenty to keep me busy there.