Давно не обновляли ЛЭРС учёт. Работали на на версии 3.38.2, так было нужно чтобы все кто работали с ЛЭРСом в городе могли использовать сервера друг друга. Договорились обновиться. У нашей организации получается самая жирная база данных, размер около 9 ГБ. Бесплатная версия MS SQL Express, близок предел. Судя по отчёту “Состояние системы” больше всего занимала база “интеграторов по воде” около 4,5 ГБ. Я занялся удалением уже не действующих точек учёта и очисткой базы данных в системных параметрах как говорится вот здесь: через https://docs.lers.ru/docs/pages/viewpage.action?pageId=28868631 . Я понижал значения времени хранения всех параметров, в ужимании базы дошел до хранение часовых данных по интеграторам до 2-х месяцев, ставил галочку “Выполнить очистку БД после сохранения параметров”, каждый раз после того как нажимал “ОК” судя по диспетчеру задач база обрабатывалась, но размер базы “интеграторов по воде” всё-равно оставался около 4,5 ГБ. Я открыл наугад несколько точек учёта и увидел там часовые и текущие интеграторы за 2016 год. То есть не работает на сервере функция очистки базы от старых интеграторов. Часовые потребления удаляет исправно. Получается у нас заблокирована возможность обновления. Как быть? Может SQL скрипт для базы данных поможет?
В статье "При обращении к базе данных произошла ошибка “Could not allocate space…” говорится: “Так же можно удалить старые данные по точкам учёта, воспользовавшись операцией группового удаления.” со ссылкой на несуществующую страницу http://support.lers.ru/manual/deletemeasurepointdata.html - не нашёл такйо функции в своём ЛЭРСе 3.38.2
Коммерческая лицензия активна, но дата окончания обновления уже поджимает.
Обновление ЛЭРС УЧЕТ
При установке обновления произошла ошибка.
Не удалось обновить базу данных. Could not allocate space for object ‘dbo.WaterTotals’.‘PK_MeasurePointWaterTotals’ in database ‘LERS’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
После того как вы удалили из БД ненужные данные, размел файла останется точно таким же, и SQL Server всё равно будет считать, что вы превышаете разрешённый в бесплатной редакции размер.
После того как очистка завершена, нужно выполнить процедуру сжатия БД. Для этого на компьютере с сервером БД откройте командную строку и введите команду
sqlcmd -E -S (local)LERS
В открывшейся консоли наберите команды, разделяя их кнопкой Enter
DBCC SHRINKDATABASE(Lers);
Дождитесь окончания сжатия БД. После этого файл станет меньше.
Это описано в статье https://docs.lers.ru/docs/pages/viewpage.action?pageId=819309 , я написал что делал это. “После того как вы удалили из БД ненужные данные” - так не удаляются данные получается, раз я вижу их в таблице потребления. Интеграторы не удаляются. Потребления удаляются. По отчёту о состоянии системы размер таблицы интеграторов по воде в базе данных самый большой и не убывает после очистки.
Суть в том, что когда данных очень много операция очистки БД скорее всего будет останавливаться по таймауту. Дело в том, что Сервер ЛЭРС УЧЕТ удаляет данные блоками по несколько записей, посылая на СУБД SQL Server соответствующий запрос удаления, который должен быть отработан в течении времени ожидания ответа от БД (по умолчанию 60 секунд). Если SQL Server не успел выполнить запрос удаления блока данных за это время, Сервер останавливает операцию удаления по выбранному типу данных (суточные данные, часовые данные, интеграторы и т.д.), выводя в журнале работы Сервера ошибку обслуживания БД, и переходит к следующему типу. Но при этом SQL Server такой запрос отрабатывает даже в случае несвоевременной отправки ответа на такой запрос. А значит даже в случае возникновения ошибок обслуживания БД при каждом запуске операции обслуживания размер БД должен немного уменьшаться.
Исходя из этого, если после выполнения обслуживания БД данные не удалились, необходимо запускать операцию обслуживания БД до тех пор, пока все данные не удаляться, проверяя при этом посредством рассматриваемого отчета о состоянии системы, что данные постепенно удаляются.
Ну… пока я убавлял и убавлял срок хранения архивных записей, часовых интеграторов в том числе, я уже эту операцию запустил пару десятков раз и именно этот архив убавился может на сотню мегабайт. Временами он даже как будто прибавлял в весе. Сейчас Вы написали пробовать еще я еще пять раз запустил эту операцию, размер не сдвинулся ни на десятую долю мегабайта. Поэтому и попросил может можно написать какой-то скрипт c запросами SQL в котором будет выставлен либо цикл, либо повышенный таймаут на запрос, либо что. Живых у нас 674 точки учёта, открывать их и в ручную удалять интеграторы через ручной ввод данных - ну это такое себе развлечение.
Можно открыть точки учёта, отметить галочками необходимые точки, ПКМ → удалить данные. Задаёте период и типы архивов. Удаляться данные из отмеченных точек учета. Возможно поможет вам такой вариант
Однако вариант. Спасибо! Вот значит где спряталась эта “операция группового удаления”. Жаль только что работает она не так гибко как очистка базы данных - нет возможности удалить только часовые интеграторы, оставив суточные и месячные, удалят всё. Разработчики, есть ещё пути удаления часовых интеграторов?
Архив Интеграторов всегда был общим архивом. В нем нет как такового разделения на часовые, суточные и месячные.
В таблице с данными просто есть возможность просматривать интеграторы на начало часа, суток и месяца, но на самом деле это один архив, поэтому удалить отдельно только часовые интеграторы не представляется возможным.
