home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / sybase / 605 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  2.9 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!caen!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!alpha.ces.cwru.edu!yangying
  2. From: yangying@ces.cwru.edu (Ying Yang)
  3. Newsgroups: comp.databases.sybase
  4. Subject: Re: KILLed Sybase process will not die?
  5. Message-ID: <1ideloINN1bd@usenet.INS.CWRU.Edu>
  6. Date: 6 Jan 93 02:03:36 GMT
  7. References: <1993Jan5.192546.8743@mcm.com>
  8. Organization: Agency Rent-A-Car, Cleveland, OH
  9. Lines: 59
  10. NNTP-Posting-Host: easy.ces.cwru.edu
  11.  
  12. In article <1993Jan5.192546.8743@mcm.com> wall@mcm.com (Steve Wall) writes:
  13. >Several times I've wanted to KILL a Sybase process with the
  14. >equivalent of the UNIX kill -9 (die NOW!, no sig catch, etc.).
  15. >Sybase gives you KILL, but under certain circumstance, the kill
  16. >doesn't seem to take effect until some kind of variable delay
  17. >(seems to be dependent on the type of process). Probably due
  18. >to the Sybase kernel scheduler, resources in use by the proc,
  19. >process run state (blocked or not), etc.
  20. >
  21. >For instance, this morning I have a DBCC process that is running
  22. >later than usual due to delays up the pipeline (yes, I'm aware
  23. >that DBCC in multiuser is not technically correct, and we interpret
  24. >the results with this in mind), And now the DBCC is hogging the
  25. >Server when people are trying to perform typical, daily queries.
  26. >Thus, I want to KILL it since it is not mandatory that we get
  27. >DBCC results every day.
  28. >
  29. >[Actually, the DBCC (spid=1) is blocking all my users due to locking
  30. >on sysobjects (DBCC has a shared page lock on sysobjects
  31. >page 2, my other proc (spid=10) is trying to get an Ex-table on
  32. >sysobjects - see below). Why is DBCC locking sysobjects for so long?]
  33. >
  34.  
  35.  
  36.  
  37. When we kill a Sybase process, we may get (at least) four different
  38. results :
  39.  
  40. 1. The process is a ordinary retrieve transaction, i.e. SELECT, it
  41. dies immediately.
  42.  
  43. 2. The process is an update transaction, it does not die until the
  44. server has rolled back the transaction. The time is directly related to
  45. the size of transaction.
  46.  
  47. 3. The process is a DBCC transaction. Sybase forks a separate process
  48. for the transaction, and the new one is out of users' control. I have
  49. experience to check multi-million row tables(with checktable option).
  50. DBCC checks the tables index by index, we can only kill it when it
  51. finishes one index and ready for the next one. It may take amywhere
  52. from several minutes to four hours to die.  In your case, it seems you
  53. were running checkallec or checkdb, so the process held locks on the
  54. sysobjects, and you could not control the "ghost" Sybase process.
  55.  
  56.  
  57. 4. The process is sleeping. We cannot kill a sleeping process. When an
  58. end-user process gets disconnected, we cannot kill the Sybase process
  59. and release the locks.  To deal with this, we have installed a EBF to
  60. kill disconnected processes when our clients turn off their PCs.  At
  61. last year's User Conference, Sybase said the 5.0 version would provide
  62. unconditional KILL, hope this is true.
  63.  
  64.  
  65.  
  66. Ying Yang
  67.  
  68. MIS 
  69. Agency Rent-A-Car
  70.  
  71.