Досталась в наследство ASE 15.0 десятилетней давности установки.
Столкнулся с проблемой. Пару месяцев назад в логе всплыло сообщение:
"server The transaction log in database master is almost full. Your transaction is being suspended until space is made available in the log."
Далее с тех пор каждую минуту в лог спамилось:
...
server 1 task(s) are sleeping waiting for space to become available in the log segment for database master.
server 1 task(s) are sleeping waiting for space to become available in the log segment for database master.
server 1 task(s) are sleeping waiting for space to become available in the log segment for database master.
...
итд

Как я понимаю, забился лог базы master.
На работоспособность это никак не влияло, я администатор неопытный, решил не обращать внимания.
Но спустя где-то месяц, видимо лог все же как-то "окончательно" переполнился (или как это правильно назвать), и к базе перестали проходить соединения.
Получил я т.е. вот такое:
-----------------------
CT-LIBRARY error:
ct_connect(): user api layer: internal Client Library error: Read from the server has timed out
-----------------------

Проблема решилась перезагрузкой сервера.

С тех пор прошел месяц, проблема снова повторилась сегодня.
Поискал здесь на форуме, нашел такое решение:
dump tran master with truncate_only
Это вроде как опять решило проблему, лог как я понял почистился. Только не перезагрузкой, как в тот раз, а командой дамп.
Но как я подозреваю, это ведь снова какое-то временное решение?

Вопрос: как это исключить в принципе?

Вот результаты команд sp_helpdevice и sp_helpdb
---------------------------------
1> sp_helpdevice master
2> go
device_name physical_name description status cntrltype vdevno vpn_low vpn_high
----------- --------------------------- --------------------------------------------------------------------------------------------------------- ------ --------- ------ ------- --------
master /opt/sybase/data/master.dat file system device, special, dsync on, directio off, default disk, physical disk, 30.00 MB, Free: 7.00 MB 3 0 0 0 15359

(1 row affected)
dbname size allocated vstart lstart
----------- ------------- ------------------- ------ ------
master 13.00 MB Jan 14 2010 3:39PM 4 0
model 3.00 MB Jan 14 2010 3:39PM 6660 0
tempdb 4.00 MB Jan 14 2010 3:39PM 8196 0
sybsystemdb 3.00 MB Jan 14 2010 3:39PM 10244 0

(1 row affected)
(return status = 0)


1> sp_helpdb master
2> go
name db_size owner dbid created status
------ ------------- ----- ---- ------------ ------------------
master 13.0 MB sa 1 Jan 14, 2010 mixed log and data

(1 row affected)
device_fragments size usage created free kbytes
------------------------------ ------------- -------------------- ------------------------- ----------------
master 13.0 MB data and log Jan 14 2010 3:39PM 6806
device segment
------ ----------
master default
master logsegment
master system
(return status = 0)

---------------------------------

Если я правильно разобрался, у меня есть резерв в 7Мб и я могу расширить master на 7Мб максимум. Но решит ли это проблему?

Теперь собственно сам главный вопрос: как расширить master, больше чем изначально было выделено на master.dat ?
Первой мыслью было выделить доп диск через "disk init" и потом через alter туда подцепить master. Но прочитал, что таким образом можно расширять только обычные базы, а master нельзя. Так ли это? Есть ли какие-то еще способы?
Как вариант: я вижу что лог у меня пишется в этот же master. Может как-то под лог хотя бы сделать отдельный девайс, его уже сделать пошире, и чтоб туда все валилось? Какие для этого дать команды?
Или еще как-то может быть решить проблему?

Спасибо! Примерно ясно, но все же уточню.

1. Почему расширился лог master-а, если никакие изменения в структуре СУБД за этот период не происходили? Т.е. не было добавлено/удалено никакиих БД, пользователей, таблиц, не менялась структура таблиц итд. Разумеется, происходили изменения в СОДЕРЖИМОМ таблиц (обычных, пользовательских, не системных). Но разве это затрагивает лог master-а?

2. Правильно ли я понимаю, что никаких других решений, кроме как "время от времени чистить лог командой dump" - не существует? Т.е. периодическое переполнение диска master.dat этим логом - это "не баг, а фича", и просто требует время от времени, эдакой, профилактической очистки?

.