verificator.log нужен совет

[Васо]

Приветствие всем!
verificator.log выдает следующее:
-----------------------------------------------------------------------------
-- Verificator
-- Backup db with mysqldump -uASDF -pASDF UTM5
-- Affected tables list at the end of file

-- ERROR Account 8 linked to discount period 1 which not exists
-- SQL DESC delete brocken account (NOT RECOMMENDED)
-- UPDATE accounts SET is_deleted=1 WHERE id='8';

-- ERROR Account 11 linked to discount period 1 which not exists
-- SQL DESC delete brocken account (NOT RECOMMENDED)
-- UPDATE accounts SET is_deleted=1 WHERE id='11';

-- ERROR Account 14 linked to discount period 1 which not exists
-- SQL DESC delete brocken account (NOT RECOMMENDED)
-- UPDATE accounts SET is_deleted=1 WHERE id='14';

-- ERROR Account 16 linked to discount period 1 which not exists
-- SQL DESC delete brocken account (NOT RECOMMENDED)
-- UPDATE accounts SET is_deleted=1 WHERE id='16';
...
...
...
------------------------------------------------------------------------------
как все поняли - все дело в отстутвии расчетного периода с id=1. Как лучше с такой ошибкой бороться? Дописать расчетный период? Не подвергнуться ли изменениям последующие расчетные периоды?

[Васо]

Еще вопрос, в каком порядке должны стартовать rfw, radius и core для нормального запуска, а то получается иногда так, что после перезапуска всего этого авторизация не проходит радиус сервером. Также с периодичностью в несколько дней радиус перестает авторизовывать пользователей, просто как-то подвисает, думаю что это из-за ошибки в предыдущем посту в verificator.log. Видно будет...
Уже на форуме много читал подобных тем. В дополнение скажу, что на серваке клиентов около 350, ресурсов очень много у железа.

[Lex]

------------------------------------------------------------------------------
как все поняли - все дело в отстутвии расчетного периода с id=1. Как лучше с такой ошибкой бороться? Дописать расчетный период? Не подвергнуться ли изменениям последующие расчетные периоды?

Очень интересно, куда это расчетный период делся. Учитывая то, что система его закрыть не может и не позволяет его редактировать, на лицо правка базы, причем при полном отсутствии понимания того, как отреагирует на это система. И бороться с этим очень просто - восстанавливать данные из бэкапа на момент до правки базы пока не стало хуже. Если бэкапа нет - заказывать работы по восстановлению целостности базы данных, хотя, сразу предупрежу, они недешевы.

[cjcrazy]

а вот можно было его в 5-лохматой версии отредактировать и завершить (это в последних, видимо, нельзя). у самого такая байда была.
пришлость "править базу" и возвращать этот расчетный период к жизни.
а затем снова править базу, дабы перевести юзверей с этого расчетного периода.

[Васо]

я так понял, что попал...
Все равно вопрос, я же в биллинге при подключении пользователей использовал совершенно другие расчетные периоды - львиная часть пользователей "сидит" на одном созданном в ручную расчетном периоде, остальная небольшая часть индивидуально каждый на своем вновь созданном. Какая тут связь с первым расчетным периодом? При подключении юзверей я в расчетных периодах нажимал "Добавить" и создавал новый... А verificator.log вышеуказанные ошибки выводит на всех пользователей.
Если я просто создам в базе расчетный период с id=1 - пипец учету?

[Васо]

посоветуйте хотя бы что-нибудь, народ
просто достало уже что утмка перестает со временем подрубать пользователей

[cjcrazy]

возвратите 1-й расчетный период к жизни. прописав ему в таблице is_deleted=0

[Васо]

с удовольствием, но его нет