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

[Former Member]

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.

[former_member188958]

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?

-bret

[Former Member]

Morning Bret,

just one or two processes are killed.

There are no cross DB joins between Assassin and victim. 😞

Colin

[former_member188958]

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

[Former Member]

Cheers Bret, plenty to keep me busy there.