Может с начало через диспетчер глянуть кто как жрет память (предварительно ребутнув сервер).. потом разбираться...
Может с начало через диспетчер глянуть кто как жрет память (предварительно ребутнув сервер).. потом разбираться...
Нет, не может. Система и так даёт предельно четкий ответ по использованию памяти в логе, запись которого я привел выше. Ну и я не настолько глуп чтобы при виде проблемы сразу бежать на форум, а не попытаться найти проблему сначала самому. Факт в том, что на предыдущей версии такой проблемы не было.
Обнаружил в логах бесконечное число попыток обработать файл из retrylis - заглянул вовнутрь и обнаружил, что все 260кБ файла состоят исключительно из нулей и пришлось его удалить. Подумал, что SQL не освобождает кэшированную память, но рестарт службы не привел к ее освобождению. Переименовал логи, сделал рестарт и буду наблюдать.
Еще смущает в repsserv.stk записи
Это нормально?-------------------------------------
15.06 14:21:44
684:Query (D:\UCS\R Keeper 7\default\Rk7Reports\SQLDebug\15062019\sql756D.tmp ) execution exception: EOleException: Недопустимое имя объекта "LOGBOOK"
CREATE VIEW "VRK7CUBEVIEW10927" AS
SELECT
LOGBOOK.DATETIME AS "DATETIME",
CLASSINFOS00.CIUSERPLNAM...
Windows error =183 (B7h). Невозможно создать файл, так как он уже существует.
-------------------------------------
15.06 14:21:44
5250:Cube Куб по истории (10927) SQL View error: Недопустимое имя объекта "LOGBOOK"
CREATE VIEW "VRK7CUBEVIEW10927" AS
SELECT
LOGBOOK.DATETIME AS "DATETIME",
CLASSINFOS00.CIUSERPLNAME AS COLLECTION,
trk7ChangeTypes00.CHANGENAME AS "CHANGENAME",
...
Недопустимое имя объекта "LOGBOOK"
CREATE VIEW "VRK7CUBEVIEW10927" AS
SELECT
LOGBOOK.DATETIME AS "DATETIME",
CLASSINFOS00.CIUSERPLNAME AS COLLECTION,
trk7ChangeTypes00.CHANGENAME AS "CHANGENAME",
EMPLOYEES00.SIFR AS "EMPLOYEESIFR",
EMPLOYEES
-------------------------------------
Последний комент был три дня назад. Хотелось бы услышать чем закончилась эта история. Просто это форум и когда возникают такие ситуации хотелось бы знать результат. Что, как и прочее...
До сих пор продолжает утекать и через 3-4 дня система перестает отвечать. В Сети находил данную проблему данного MS SQL Server 2012, но она была на SP1 и потом вышел хотфикс, а на моем сервере почти сразу был установлен SP4 и до апгрейда версии R-Keeper проблемы не было. Обнаружил странность, что занятая память не освобождается после рестарта службы MSSQL...