Нет свободного места на диске С (WWALMDB_log.LDF, LogFiles)

[engineer_ua]

Стлолкнулся с проблемой нехватки свободного места на диске С... (всего объем 66Gb).
система IDE 3.0 + Historian Server (Windows Server 2003), система работает 2 года...

посмотрел что можно почистить...
ну файлы Historian Server (базы трендов) из C:\InSQL\Data\Circular понятно...
а вот наткнулся на такой файл WWALMDB_log.LDF весит аж 19 Gb, причем на точно таком же севрере (работает пара независимых серверов) такого файла нет, только WWALMDB.mdf - я так понимаю это файл алармов....
- вопрос: что за файл [b]WWALMDB_log.LDF ? можно ли его просто удалить? и как вообще очистить базу алармов?[/b]




потом есть еще папочка ...\Application Data\ArchestraA\LogFiles
она тоже весит около 4.5Gb
ее можно удалить?

[Генератор зла]

Утилита AlarmDBPurgeArchive (wwalmpurge.exe) в помощь.

[Basilio]

1. Про ldf файл. Выполните "урезание" файла логов БД WWALMDB по инструкции http://windowsnotes.ru/database/urezani ... rver-2012/
* Запись/чтение алармов на время выполнения процедуры нужно остановить.
2. Про LogFiles. Идем по пути SMC -> Log Viewer -> раскрываем дерево, Local -> пр. клик по Local -> Messages -> Purge -> выбираем удалить все сообщения или задаем дату ДО которой будут очищены лог-сообщения -> ОК

[engineer_ua]

по поводу свойств базы...что Вы устанавливаете Full или Simple...

в рекомендациях от Wonderware есть рекомендация Simple!!!

Under the “Recovery Model”, set the value to Simple. This will prevent the database log from growing too large.
https://insource.mindtouch.us/Wonderwar ... Management

[engineer_ua]

по поводу Alarm DB Purge-Archive Utility
у кого на сколько дней установлена запись?
у меня сейчас на 120 дней + каждый день арзивирование...хочу поставить на 60 дней....сейчас база весит 10GB (WWALMDB)

[Генератор зла]

У нас по ТЗ глубина архива аварий = 30 дней. Так и настроено. Чистка - ежедневно.
Архивировать там нечего, ибо через месяц вся эта инфа - никому не нужный мусор.
При возникновении нештатных ситуаций с журнала аварий делается распечатка.

[engineer_ua]

У нас по ТЗ глубина архива аварий = 30 дней. Так и настроено. Чистка - ежедневно.
Архивировать там нечего, ибо через месяц вся эта инфа - никому не нужный мусор.
При возникновении нештатных ситуаций с журнала аварий делается распечатка.

сколько у Вас весит база WWALMDB.mdf?

[Генератор зла]

Доходит и до 10 Гб в удачные дни, когда местная эксплуатация умудряется несколько раз перезапустить контроллеры и сервера, в результате чего каждый раз срабатывает по паре тысяч аварий, которые затем квитируются, приходят в норму,...
А так, при нормально настроенных пределах количество аварийных сообщений в сутки исчисляется единицами-десятками - копейки для БД.

[engineer_ua]

очистил WWALMDB_log.LDF через SQL->Shrink->Reorganize page before releasing unused space...Shrink file to : 0 Mb...
отлично.....
перегрузил компьютер...
поменял в свойствах базу WWALMDB Recovery model Full->Simple...
перегрузил комп...

теперь думаю очищу базу архивов (раньше был архив на 120дней...поставил 60)...нажал Purge Now...
и смотрю лог файл за 4 часа "чистки" из 0 вырос до 30 Gb.... на диске C выдало Low Disk Space....
оставил наначь посмотрю сможет ли он закончить процедуру....

почему так вырос LOG во время чистки базу??? Как мне очистить базу если во время чистки LOG файл растет с 0 Mb до 30 Gb и занимает все свободное место на диске С?

[Генератор зла]

почему так вырос LOG во время чистки базу???

Для очистки создаётся копия БД. Фактически для успешной очистки, ИМХО, требуется двойной текущий размер БД на диске.

Как мне очистить базу если во время чистки LOG файл растет с 0 Mb до 30 Gb и занимает все свободное место на диске С?

1. Перенести файлы БД на диск XXX, где свободно 100500 Гб, зацепить их в MSSQL, и почистить. Вернуть всё на диск C.
2. Чистить с 120 дней на 115, со 115 на 110, ...

[engineer_ua]

Фактически для успешной очистки, ИМХО, требуется двойной текущий размер БД на диске.

согласен...но у меня база весит 10Gb а лог вырос с 0 до 30 Gb... т.е. в три раза...

Как мне очистить базу если во время чистки LOG файл растет с 0 Mb до 30 Gb и занимает все свободное место на диске С?

1. Перенести файлы БД на диск XXX, где свободно 100500 Гб, зацепить их в MSSQL, и почистить. Вернуть всё на диск C.
[/quote]

не это технически сложно, на серверах два диска на каждом по 30 Gb свободного места (которых, как оказывается не достаточно для очистки базы в 10 Gb)...

2. Чистить с 120 дней на 115, со 115 на 110, ...

а это хорошее предложение....буду пробовать так!

[engineer_ua]

нам вообщето эти данные не нужны...
что если просто удалить базу через Alarm DB Logger Manager ->Delete Database...и потом создать новую (с тем же именем WWALMDB)...
вопрос у нас клиент/сервере (галактика), нужно будет ли повторно деплоить галактику?

[Генератор зла]

ИМХО, это самое простое решение.
Деплоить заново ничего не потребуется.
Только убедитесь, что пароль для пользователя sa Вам известен.
Перед удалением базы DB Logger необходимо остановить.

[engineer_ua]

и снова история с большим размером файла WWALMDB_log.LDF - повторилась!

так же обратил внимание что в проводнике Windows дата модификации файл WWALMDB.mdf указана 5 месяцев назад, получается 5 месяцев в базу аварий не было записи?
но лог файл WWALMDB_log.LDF дата модификации указана актуальным числом, получается что данные о авариях были записаны в WWALMDB_log.LDF?



обратил внимание что в SQL база WWALMDB в состоянии suspect,
в интернете есть рекомендации ... попробовал выполнить запрос:

ALTER DATABASE WWALMDB SET EMERGENCY
ALTER DATABASE WWALMDB SET SINGLE_USER
DBCC CHECKDB (WWALMDB, REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE WWALMDB SET MULTI_USER

этот запрос выполнялся более 2х часов и не помог...
что еще можно попробовать?
самое простое удалить эту базу и создать новую, и в принципе не проблема это сделать (но хотелось бы разобраться в этом вопросе)

P.S.
после перезагрузки файл WWALMDB_log.LDF был уменьшен в размере, с 3Gb до 9Mb, и ушел статус suspect...!!!

[NewOrdered]

1. Удалить старые записи с помощью утилиты Alarm DB Purge Archive
2. Выполнить Shrink базы через Management Studio.

Если есть проблемы с вышеперечисленным, то проще сделать бэкап старой базы средствами Management Studio и создать новую

[engineer_ua]

1. Удалить старые записи с помощью утилиты Alarm DB Purge Archive

какая у Вас "глубина" журнала аварий, 30 дней?
после этих дней Вы просто удаляете или архивируете старые записи?

Как потом можно восстановить старые записи?
при архивировании утилита Alarm DB Purge Archive создает текстовые файлы, но они мягко говоря не читабельны,
можно ли их импортировать обратно в SQL, и уже в InTouch простотреть нужные аварии (используя фильтры в InTouch)?

[NewOrdered]

какая у Вас "глубина" журнала аварий, 30 дней?
после этих дней Вы просто удаляете или архивируете старые записи?

Конкретно в моем случае глубина архива редко была более 90 дней. Старые сообщения удалялись утилитой Alarm DB Purge Archive.
В общем случае это будет зависеть от многих факторов:
- количества сообщений в единицу времени
- доступного места на диске
- версии SQL сервера
и т.д.

Как потом можно восстановить старые записи?
при архивировании утилита Alarm DB Purge Archive создает текстовые файлы, но они мягко говоря не читабельны,
можно ли их импортировать обратно в SQL, и уже в InTouch простотреть нужные аварии (используя фильтры в InTouch)?

сделать бэкап старой базы средствами Management Studio

[engineer_ua]

сделать бэкап старой базы средствами Management Studio

т.е. Вы не пользуетесь архивированием средствами утилиты Alarm DB Purge Archive? только функция чистки?
и текстовые файлы (которые получаются после архивирования Alarm DB Purge Archive стандартными средствами обратно в базу SQL не импортировать?
получается что они в принципе бесполезны? не думаю что кто-нибудь захочет искать аварии в текстовом документе...