Разрастание базы

Максим, добрый день.

Практически по каждой таблице вы можете найти информацию на комьюнити, если вобьете в поиск название. Дальше уже можно принимать решение, нужны ли данные из нее или нет.

Все таблицы, имеющие название Sys...Rights - это информация о правах доступа по записям, их очищать нельзя.

SysUserSession - история входов пользователей, если информация не нужна, можно очистить. В случае, если информация совсем не нужна, рекомендую воспользоваться командой TRUNCATE. Всех активных пользователей выкинет из системы.

SysProcessLog, SysProcessElementLog - Журнал процессов и элементов процесса соответственно. Хранят исторические данные о времени запуска, длительности выполнения, состояниях процессов.

В таблице SysPrcPersistentStore хранится исполняемая схема процесса для интерпретируемых процессов (Flow Shema). Чем больше процессов, тем больше места будет занимать таблица.  

=> https://community.terrasoft.ru/questions/zacem-nuzna-tablica-sysprcpers…

Активности типа "Автогенерируемая страница" и "Преднастроеная страница" хранятся в 2 таблицах: SysProcessData и  SysProcessLog. В первой таблице они сохраняются пока находятся в работе, во второй они сохраняются всё время.

=>https://community.terrasoft.ru/questions/tehniceskie-aktivnosti

Таблицы, которые начинаются на SysProcess и SysPrc отвечают за выполнения бизнес процессов. Часть из них хранит историю выполнения, часть данные для работы.

Пащенко Александр Сергеевич,

Добрый день. Давайте считать, что второго вопроса не было. Меня интересует ответ на первый вопрос: "Мне, пожалуйста, список всех таблиц с логами, которые носят информационный характер и записи которых можно безболезненно для работоспособности системы периодически удалять."

Вы можете увидеть список таблиц, занимающих больше всего места, построив стандартный отчёт «Disk Usage by Top Tables»:

Кроме почты и логов, много места могут занимать таблицы файлов каждого раздела.

Добрый день, Максим!



Обычно больше всего места "кушают" логи из таблиц:

SysProcessData

SysProcessElementData

SysProcessLog

SysProcessElementLog

SysUserSession

IntegrationLog



В первых 4 таблицах хранятся экземпляры и записи  "Журнала процессов", в SysUserSession - записи о сессиях пользователей, в IntegrationLog - логи всех интеграций (почта, телефония, facebook и т.д., а также записи об импорте/экспорте из excel). Если в Ваших пакетах нет завязанной на этих таблицах логики и Вы уверены, что эти логи не понадобятся - можно их почистить. Для очистки есть специальные процедуры (скачать по ссылке). Необходимо:

1. Выполнить скрипты во вложении в БД (создают хранимые процедуры).

2. Запустить процедуру:



exec [dbo].[tsp_DeleteSysProcessDataByStartDate] '2015-11-01' -- будут удалены все экземпляры процессов, дата начала которых (StartDate в таблице SysProcessLog) меньше указанной в переменной



Время выполнения процедуры зависит от количества экземпляров. Для решение этой задачи ввели ограничение на количество удаляемых экземпляров. Процедура удаляет 50 000 экземпляров за одно выполнение (можно изменить количество в процедуре) начиная с самого старого экземпляра (по колонке StartDate в таблице SysProcessLog). Приблизительное время удаления 50 000 экземпляров ~ 40 - 50 минут. Процедура удаляет экземпляры как родительских процессов, так и подпроцессов.

3. После удаления экземпляров необходимо удалить записи в журнале процессов (SysProcessLog). Необходимо выполнить поочередно tsp_DeleteSysProcessLog.sql и tsp_DeleteSysProcessLogByStartDate.sql. Процедура удаляет все записи из журнала процессов, которые удовлетворяют условию фильтрации. Данные экземпляров запущенных процессов остаются в системе. Перед выполнением необходимо сделать резервную копию БД.

4. Далее процедуру необходимо зарегистрировать и вызывать скриптом:



exec [dbo].[tsp_DeleteSysProcessLogByStartDate] 'Завершен', '2019-05-01', 100000

--где 'Завершен' - состояние процессов, которые нужно удалить

--'2019-05-01' - дата, до которой нужно удалить устаревшие данные

--100000 - количество удаляемых записей



Процедуры рекомендуется проводить в нерабочее время. Ее длительность зависит от количества удаляемых записей и общего количества записей в таблице.



5. В SysUserSession хранятся записи сессий пользователей - можете удалять неактуальные записи по колонке SessionEndDate:



DELETE FROM [dbo].[SysUserSession] WHERE [SessionEndDate] < '2019-05-01' -- удалит все сессии, которые закончились до 1 мая

DELETE FROM [dbo].[SysUserSession] WHERE [SessionStartDate] < '2019-04-30' AND [SessionEndDate] IS NULL -- удалит все сессии, которые начались до 1 мая и до сих пор висят в таблице, как активные.



6. В IntegrationLog хранятся логи всех интеграций. Почистить их можно скриптом:



DELETE FROM [dbo].[IntegrationLog] WHERE [Date] < '2019-05-01' AND [IntegrationSystemId] = (SELECT [Id] FROM IntegrationSystem WHERE [Name] = '1С')

-- '2019-05-01' - дата, до которой чистим лог

-- где '1С' - имя интеграции, их список можно посмотреть в таблице IntegrationSystem

 

Также можно воспользоваться стандартным функционалом SQL Management Studio по сжатию БД: Сжатие базы данных



Все процедуры рекомендуется проводить в нерабочее время, так как они значительно повышают нагрузку на БД.

 

Мотков Илья,

>>2. Запустить процедуру:

>>exec [dbo].[tsp_DeleteSysProcessDataByStartDate] '2015-11-01'

Запустил. Скрипт поработал. Этот шаг должен был очистить таблицу SysProcessLog? В этой таблице осталось всё без изменений.

Судя по названию, из она удаляет из SysProcessData, а не SysProcessLog.

Из SysProcessData ничего не удалено. Может потому-что в полях есть значения NULL, а в скрипте вроде как есть ссылки на них?

Наоборот, там выбираются только с Null:

WHERE SysProcessData.ParentId IS NULL

Зверев Александр,

Тогда тем более странно почему не удаляется ни одна запись.

Видимо, потому, что они созданы после 2015 года.

Зверев Александр,

))) 

exec [dbo].[tsp_DeleteSysProcessDataByStartDate] '2018-01-01'

С параметром даты всё в порядке

Зверев Александр,

Спасибо, вопрос снят. Было потому, что до этих скриптов часть базы удалил вручную. Восстановил исходную, удаляется. Но за исключением некоторых записей.

Мотков Илья,

3. После удаления экземпляров необходимо удалить записи в журнале процессов (SysProcessLog). Необходимо выполнить поочередно tsp_DeleteSysProcessLog.sql

Не получается запустить хранимую процедуру. Выдаёт ошибку:

сообщение: 208, уровень: 16, состояние: 0, процедура: tsp_DeleteSysProcessLog, строка: 9 [строка начала пакета: 0]
Недопустимое имя объекта "#SysProcessLogId".

Может, версия MS SQL неподходящая для таких названий.

Зверев Александр,

Версия MS SQL:

Microsoft SQL Server 2012 - 11.0.2100.60 (X64) 
	Feb 10 2012 19:39:15 
	Copyright (c) Microsoft Corporation
	Standard Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)

В такой версии должны нормально создаваться. Видимо, запускаете хранимки не в том порядке и временная таблица ещё не создана.

Зверев Александр,

Скачал три файла со скриптами: 

DeleteSysProcessDataByStartDate.sql, tsp_DeleteSysProcessLog.sql и tsp_DeleteSysProcessLogByStartDate.sql.

По очереди взял код из каждого файла, скопировал его в окно где пишут код в sql management studio и нажимал F5. Хранимые процедуры появилась в Программирование -> Хранимые процедуры.

Далее запустил код exec [dbo].[tsp_DeleteSysProcessDataByStartDate] '2019-06-01'. Он отработал. Оставил в базе 80 000 записей. Я нашёл в sql management studio в списке хранимых процедур похожую по названию tsp_DeleteSysProcessData. Откуда она там, не знаю. Может была изначально, может её добавляли предыдущие разработчики. Запустил её, она всё почистила. Вот её код:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
 
ALTER PROCEDURE [dbo].[tsp_DeleteSysProcessData]
	@SysWorkspaceName varchar(100)
AS
BEGIN
 
	SET NOCOUNT ON
 
	DECLARE @sysProcessDataRecordsToDelete TABLE (Id uniqueidentifier )
	DECLARE @sysProcessElementDataRecordsToDelete TABLE (Id uniqueidentifier )
 
	INSERT INTO @sysProcessDataRecordsToDelete ([Id])
	SELECT SysProcessData.Id FROM SysProcessData WHERE SysProcessData.SysSchemaId IN
		(SELECT SysSchema.Id FROM SysSchema
			INNER JOIN SysPackage on SysPackage.Id = SysSchema.SysPackageId
			INNER JOIN SysWorkspace on SysWorkspace.Id = SysPackage.SysWorkspaceId
			WHERE SysWorkspace.Name = @SysWorkspaceName)
 
	INSERT INTO @sysProcessElementDataRecordsToDelete ([Id])
		SELECT SysProcessElementData.Id FROM SysProcessElementData
		INNER JOIN @sysProcessDataRecordsToDelete processData ON processData.Id = SysProcessElementData.SysProcessId
 
	DELETE FROM SysActivityPrcEl WHERE ProcessElementId IN (SELECT Id FROM @sysProcessElementDataRecordsToDelete)
	DELETE FROM SysEntityCommonPrcEl WHERE ProcessElementId IN (SELECT Id FROM @sysProcessElementDataRecordsToDelete)
	DELETE FROM SysProcessIntermediateEvent WHERE SysProcessElementId IN (SELECT Id FROM @sysProcessElementDataRecordsToDelete)
	DELETE FROM SysProcessData WHERE Id IN (SELECT Id FROM @sysProcessDataRecordsToDelete)
 
END

Далее в инструкции сказано:

3. После удаления экземпляров необходимо удалить записи в журнале процессов (SysProcessLog). Необходимо выполнить поочередно tsp_DeleteSysProcessLog.sql и tsp_DeleteSysProcessLogByStartDate.sql. Процедура удаляет все записи из журнала процессов, которые удовлетворяют условию фильтрации. 

Нужно файлы эти выполнить? Я, как писал ранее, копировал код из этих файлов и запускал по F5. А потом запускаю хранимую процедуру с помощью кода:

exec tsp_DeleteSysProcessLog

на что выдаётся ошибка

сообщение: 208, уровень: 16, состояние: 0, процедура: tsp_DeleteSysProcessLog, строка: 9 [строка начала пакета: 0]
Недопустимое имя объекта "#SysProcessLogId".

Значит, не нашли и не запустили ту из процедур, которая создаёт эту временную таблицу #SysProcessLogId.

.

Зверев Александр,

Я всё делал по инструкции, подробно описал все свои шаги. В каком шаге тогда ошибка?

Учитывая, что первый скрипт не смог удалить 80 000 записей, есть все основания полагать, что есть и другие ошибки, как эта. Или ошибка в инструкции.

Здравствуйте, Максим!

 Прилагаю ещё один вариант скриптов.

Для очистки журнала процессов необходимо:

1. Выполнить скрипт DeleteSysProcessDataByStartDate.sql (во вложении) в БД создает хранимую процедуру.

2. Запустить процедуру (скрипт запуска ниже):

DECLARE @date date = '2015-11-01' -- будут удалены все экземпляры процессов, дата начала которых (StartDate в таблице SysProcessLog) меньше указанной в переменной

exec [dbo].[tsp_DeleteSysProcessDataByStartDate] @date

3. После удаления экземпляров необходимо удалить записи в журнале процессов (SysProcessLog):

Выполнить скрипт DeleteSysProcessLogByStartDate.sql (во вложении) в БД создает хранимую процедуру.

4. Запустить процедуру (скрипт запуска ниже):

DECLARE @date date = '2015-11-01' - -- будут удалены все записи в журнале процессов, дата начала которых (StartDate в таблице SysProcessLog) меньше указанной в переменной

exec [dbo].[tsp_DeleteSysProcessLogByStartDate] @date

Мотков Илья пишет:

Здравствуйте, Максим!  Прилагаю ещё один вариант скриптов.

Почти получилось, но не все SysProcessData удалились. Для некоторых  остались записи в SysProcessElementData. И потому вопрос - почему вы не удаляете записи из SysProcessElementData?

Вообще, в 7.15.3 добавили механизмы отмены, архивирования и удаления старых экземпляров процессов. Если есть возможность, лучше обновиться и использовать стандартный механизм.

Добавить комментарий

Мотков Илья,

А можно ссылку актуальную на процедуры, пожалуйста ?

Саид, тут и тут.

Зверев Александр,

Большое спасибо

Зверев Александр пишет:

Саид, тут и тут.

Эти процедуры для MS SQL? А есть аналогичные для PostgreSQL? 

Владимир Соколов,

Для PostgreSQL можно скачать архив тут.

Коломыцева Екатерина Александровна,

Да, можно скачать здесь.

Roman Yashchuk,

Добрый день,



В упомянутых таблицах хранится информация журнала процессов.



Мы рекомендуем использовать базовый фунционал, чтобы уменьшить размер таблиц.



Creatio автоматически архивирует завершенные и отмененные процессы, которые остаются в списке раздела [Журнал процессов] более установленного периода. Период архивации по умолчанию составляет 30 дней.



Дополнительную информацию можно найти здесь.



Если у вас есть дополнительный вопросы, мы будем рады помочь. 

Hello, cause this problem is still actual, but all the links to the archive are broken, could you please provide the community with an actual links?