Error: 3475, Severity: 21, State: 7 - There is no space available in SYSLOGS

[Former Member]

Hi Guys,

I seemed to have encountered bug 724987 which was part of the Targeted CR list for 15.7 ESD#4

724987

A 3475 error: "There is no space available in SYSLOGS to log a record for which space has been reserved in database < dbname > " may happen under rare circumstances along with the below message in the errorlog:"ERROR: Can't get a new log page in db < dbid > . num_left= < numlogrecords1 > num_in_plc= < numlogrecords2 >

We are currently at ESD#3 and getting similar errors

There is no space available in SYSLOGS to log a record for which space has been reserved in database '<DB>' (id 18). This process will retry at intervals of one minute.

01:0010:00000:08349:2014/05/26 12:55:02.56 server  ERROR: Can't get a new log page in db 18. num_left=4 num_in_plc=4.

Now I am seeing other databases on the server logs not being truncated either which leads me to believe this issue is affected all databases on the server.

Has anyone encountered this issue before and is there a way to resolve this without upgrading the server. I found something from Jason but I did not quite fully understand the steps to take

http://froebe.net/blog/2014/01/08/sybase-ase-adding-log-to-a-completely-log-full-database-errors-110...

Regards,

[former_member188958 · Accepted solution]

Hi Courtney,

Regarding Jason's workaround:

Does the sysusages.segmap column for this database contain a mix of 3s and 4s or just 7s?

If it is a mix of 3s (data) and 4s (log), you can update the 3s to 7s to allow ASE to use free space on your data devices for log as well.  That would get you past the immediate problem and can be cleaned up later once you get your log truncated.  If you just have 7s, then data and log are already mixed and this workaround can't be used.

But if you have 3s, you can do the following:

use master

go

sp_configure "allow updates", 1

go

update sysusages set segmap = 7 where dbid = 18 and segmap = 3

go

set switch on 3604

go

dbcc dbrepair(<dbname>, remap)

go

You should now be able to do a dump tran with truncate_only on the database.

[Former Member · Accepted solution]

Hi Bret,

Thank you for your response and the steps seems clearer now that it has been explained. There are a few things I did yesterday which might have made this a little more complex.

After trying a series of dump with truncate_only the processes were all stuck in the database and attempts to kill was unsuccessful. I decided late in the day to bounce the server then drop the DB( ASE Cluster Edition) as attempts to drop it came up with DB is use. The recycle caused the DB to be in suspect mode and I will be happy to drop this DB and reload from backup.

select dbid, status from master..sysdatabases where dbid = 18

dbid	status
18	76

The logs and data are separate so this step can be done, however will this still be possible now that the DB is in recovery mode? I also have a drop db command which is hung and cannot be killed

Can I  update sysdatabases set status = 320 and run dbcc dbrepair(RepTest,dropdb) to drop the DB?

[Former Member · Accepted solution]

I was able to get rid of the error by dropping the database(using the bypass recovery step) and restore from backup. Everything is fine with the server now

Thank you Bret