Results 1 to 12 of 12
  1. #1
    Join Date
    Aug 2007
    Posts
    59

    Unanswered: Error while dropping user tempdb database

    Hi i am dropping the user tempdb using drop database command.
    Before that i checked that nothing object or login is binded to it.

    when i issue that command , it gives the following message and terminates from the isql prompt

    But the tempdb is dropped.

    The message is follows:

    Msg 834, Level 20, State 4:
    Server 'ELOSYBAE', Line 1:
    Illegal attempt to clean buffer: BUF pointer = '0x0xb3b45280', MASS pointer =
    '0x0xb3b45280', (Buf#: '0'), page ptr = '0x0xb33ea800', dbid = '12', Mass
    virtpage = '352400496', Buffer page = '78960', Mass status = '0x4000009', Buffer
    status = '0x2', size = '16384', cache (id: 0) = 'default data cache', Pinning
    Xdes = '0x(nil)', spid = '0'.
    The SQL Server is terminating this process.


    After that i droped the device for it successfully w/o any error.

    Pl guide me about the message / error .

    Regards

  2. #2
    Join Date
    Sep 2003
    Location
    Switzerland
    Posts
    443
    Did you get any stacktrace along with it? If so can you post it also?

  3. #3
    Join Date
    Aug 2007
    Posts
    59
    i dont know anything abt stacktrace..
    where it will be find?
    is it written in the log?
    pl tell more about stacktrace


    Regards

  4. #4
    Join Date
    Aug 2007
    Posts
    59
    Hi
    i checked my log file, i find this stack trace

    00:00000:00085:2007/12/24 12:59:11.52 kernel ************************************
    00:00000:00085:2007/12/24 12:59:11.52 kernel SQL causing error : drop database tempdbeloofmdevnew

    00:00000:00085:2007/12/24 12:59:11.52 kernel ************************************
    00:00000:00085:2007/12/24 12:59:11.54 server SQL Text: drop database tempdbeloofmdevnew
    00:00000:00085:2007/12/24 12:59:11.57 kernel curdb = 1 tempdb = 2 pstat = 0x10000
    00:00000:00085:2007/12/24 12:59:11.57 kernel lasterror = 834 preverror = 0 transtate = 1
    00:00000:00085:2007/12/24 12:59:11.57 kernel curcmd = 297 program = isql
    00:00000:00085:2007/12/24 12:59:11.59 kernel pc 0x87fc779 ucbacktrace+0x89(0x0,0x1,0x935aef0,0x14,0x4)
    00:00000:00085:2007/12/24 12:59:11.59 kernel pc 0x81b3b29 terminate_process+0xb19(0x0,0xffffffff,0x935aef0,0 xaec38c7c,0x820bc2d)
    00:00000:00085:2007/12/24 12:59:11.60 kernel pc 0x820ba41 close_network+0x19(0x935aef0,0xac5bb640,0xaec38d40 ,0x85054fb,0x8)
    00:00000:00085:2007/12/24 12:59:11.60 kernel pc 0x820bc2d hdl_default+0x49(0x8,0x22,0x14,0x4,0xaec38d8c)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x85054fb s_handle+0xf8f(0x8,0x22,0x14,0x4,0xaec38d8c)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x820b694 ex_raise+0x2f8(0x8,0x22,0x14,0x4,0xb3b45280)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x82616fb cm_dbclean+0x1a7(0x0,0xaf7cf540,0x935aef0,0xaf7cf5 40,0x2)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x8256c4d bufdbclean+0xa9(0xaf7cf540,0x935aef0,0xac5bad80,0x af7cf540,0xaec38e74)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x827768e dbt_removeall+0x2e(0xaf7cf540,0x2,0x935aef0,0xb3b9 8c58,0xaec39110)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x82711dc dbt_dropdb+0x11c(0xaf7cf540,0x935aef0,0x12,0xb2cc8 e38,0x854e581)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x83f795a dropd+0x16ee(0xaec392bc,0x12,0x0,0x0,0x935aef0)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x83facae dropdb+0x8e(0xb2cc8db4,0x935aef0,0xaff1effc,0x1,0x 0)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x84eb234 s_execute+0x387c(0x935aef0,0x0,0xaff1ef00,0x0,0xb0 e609)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x8501a75 sequencer+0xf79(0xb2fb5800,0x935aef0,0x0,0xaff1ef0 0,0x81c6ed2)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x81e2ed9 tdsrecv_language+0x2ed(0x0,0x0,0x0,0x0,0x0)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x81f29b9 conn_hdlr+0x2809(0xbc,0xaec39e4c,0x895eed31,0x0,0x 0)
    00:00000:00085:2007/12/24 12:59:11.61 kernel pc 0x82446c7 ex_cleanup(0x0,0x0,0x0,0xace67900,0x1dd)
    00:00000:00085:2007/12/24 12:59:11.62 kernel pc 0x895eed31 init_dummy+0x80960711(0x0,0xace67900,0x1dd,0x1,0x5 374616b)
    00:00000:00085:2007/12/24 12:59:11.62 kernel end of stack trace, spid 85, kpid 783352284, suid 1

  5. #5
    Join Date
    Sep 2003
    Location
    Switzerland
    Posts
    443
    Can you check how many databases are there in your server and also the configure parameter no. of open databases?

  6. #6
    Join Date
    Aug 2007
    Posts
    59
    Hi

    No of open databases : 30
    Total number of databases in server : 15
    in which number of user tempdb : 2

    Any more information ???

    Can you tell , is these parameters depends on that error ??

    Regards

  7. #7
    Join Date
    Sep 2003
    Location
    Switzerland
    Posts
    443
    No, I thought you could hit the error when actual dbs open is maxing out. But in this case it is not.

    Anyways, only can find this CR for earlier than 12.5.1.

    292767 When a task tries to access a database while the database is undergoing creation through the 'CREATE DATABASE' command, then errors 913 and 834 may be hit with a stack trace reported in the error log showing modules 'dbt_removeall', 'bufdbclean' and 'cm_dbclean'. The same can happen if instead the database is being dropped through the 'DBCC DBREPAIR( < dbname > , DROPDB)' command.

  8. #8
    Join Date
    Aug 2007
    Posts
    59
    ys may be that db was in use. but before dropping it , i have unbinded all objects and login from that db. and i checked sp_who , while no one was connected to db.
    Also i have not used dbcc dbrepair command,
    i used drop database dbname command for dropping it.

    Also what are 'dbt_removeall', 'bufdbclean' and 'cm_dbclean'.
    Pl give the details about it.


    Regards

  9. #9
    Join Date
    Sep 2003
    Location
    Switzerland
    Posts
    443
    Quote Originally Posted by niranjan555
    Also what are 'dbt_removeall', 'bufdbclean' and 'cm_dbclean'.
    Pl give the details about it.
    Regards
    Stacktraces are nothing but the last N no. of function calls (upside down), before the error happened.

    All the above are actually Sybase internal functions, which may indicate sometimes, what is the problem. And if you search the sybase solved case with the function names, you have a better chance of finding a solution. For eg., in the above scenario, when you are dropping the database, its trying to clean the buffer etc (based on the function names). It just gives the support engineers an indication as to where to start looking.

  10. #10
    Join Date
    Sep 2003
    Location
    Switzerland
    Posts
    443
    Quote Originally Posted by niranjan555
    ys may be that db was in use. but before dropping it , i have unbinded all objects and login from that db. and i checked sp_who , while no one was connected to db.
    Also i have not used dbcc dbrepair command,
    i used drop database dbname command for dropping it.
    Regards
    It could be that there may have been ghost processes. If you run dbcc dbtable, it shows the memory structure of the particular database and the dbt_keep value shows exactly how many spids are using it.

    Anyways, you dont have to worry too much in your case, since its tempdb and the db was successfully dropped.

    If it repeatedly happens, maybe you want to run dbcc dbtable and see if dbt_keep is zero.

  11. #11
    Join Date
    Aug 2007
    Posts
    59
    ok trvishi
    thanks for the reply.
    just tell me where can i get details of sybase internal functions


    Regards

  12. #12
    Join Date
    Sep 2003
    Location
    Switzerland
    Posts
    443
    You can only search them in the solved cases.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •