[niranjan555]

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

[trvishi]

Did you get any stacktrace along with it? If so can you post it also?

[niranjan555]

i dont know anything abt stacktrace..
where it will be find?
is it written in the log?
pl tell more about stacktrace


Regards

[niranjan555]

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

[trvishi]

Can you check how many databases are there in your server and also the configure parameter no. of open databases?

[niranjan555]

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

[trvishi]

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.

[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.

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


Regards

[trvishi]

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.

[trvishi]

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.

[niranjan555]

ok trvishi
thanks for the reply.
just tell me where can i get details of sybase internal functions


Regards

[trvishi]

You can only search them in the solved cases.