Влияние количества дней для журнализации

[vasya_serega]

Кто знает, насколько влияет на производительность сервера Галактики количество дней хранения журнала?

[edward_K]

Влияет. На первасиве особенно - как тока за 2 гига вылезете получите ощутимые тормоза везде где идет запись.
На других СУБД мож не так сильно, но тут уже надо руководствоваться временем необходимым для сжатия журнала.
Если удаление дня будет более часа, то есть повод задуматься что журнал великоват. В идеале 1 час на неделю
Учтите что запись в журнал самое узкое место, и если за счет уменьшение размера запись будет идти на 10% быстрее(меньше перестройка индексов), то и галактика будет быстрее работать по записи хотя бы на %5.

[vasya_serega]

СУБД Oracle 11g, сжатие журнала изменений, если утром первым заходить в Галактику, происходит несколько минут. В таблице X$JOURNAL сейчас 1.1 млн записей, срок хранения дней - 15. Сегодня была поставлена задача увеличить значение этого параметра до 45 дней. Вот и интересно, насколько это повлияет на производительность.

[Шевцов Владимир]

В качестве варианта:
Я отказался от автоудаления журнала. И ждать напрягает, и теряется возможность сохранить архив журнала.
Обычно раз в два месяца делаю архив за два самых старых месяца журнала, Затем удаляю эти месяцы сервисной функцией.
Сейчас журнал с 01.01.2012, 22 млн. записей. Уровень производительности приемлемый. Хотя если почистить журнал до 60 дней (менее 10 млн. записей) - она (производительность) несомненно возрастет.
Оракл 10

[Polimer]

MS Sql, 30дней, >5 млн. записей, проблем нет. Ночью запускается саппорт для обрезания журнала, никто не ждет.

[GoLe]

Oracle, 150 дней, 32 000 000 записей, сжатие от 20 минут до 1 часа (за 1-3 дня)

Вопрос:При снятой галочке в настройке "Блокировка автоматической очистки" журнализации, если запускать Галактику, то заметно зависание системы на примерно 7-10 секунд. В этот момент, я так понимаю, выполняется запрос к журналу БД. Для меня это критично, т.к. в Галактику могу заходить 30-60 раз в день под разными пользователями с правами администратора. Поэтому у меня данная настройка все время стоит в положение "v", а журнализацию запускаю 2-3 раза в неделю вечерком вручную: снимаю блокировку, перезапускаю Support для инициализаци настройки и запуска процесса сжатия. Но на след. день обратно возвращаю настройку в режим блокировки. Я так один заморачиваюсь?

[edward_K]

Я обычно вообще убираю автоматческое сжатие журнала, а сжимаю средствами СУБД.

[vasya_serega]

А кроме увеличения времени очистки журнала как еще скажется увеличение количества дней хранения?

[edward_K]

любая запись ведет к перестройке индексов, чем индексов больше и чем больше записей, тем дольше идет перестройка
Ну опять же время на запись большого файла журнала на диск тоже будет слегка подрастать.
Пробуйте в общем. Увеличивайте ступенькой - пусть это будет дольше, зато надежней.

[VAt]

Я обычно вообще убираю автоматческое сжатие журнала, а сжимаю средствами СУБД.

Можно поинтересоваться технологией?

[AlexMK]

Кто знает, насколько влияет на производительность сервера Галактики количество дней хранения журнала?

для верного ответа на этот вопрос надо бы его уточнить - на какой БД нужно произвести оценку ?

на оракле можно таким образом настроить/переопределить журнальные таблицы, что вообще будет одинаково хоть день храните, хоть год ... правда официального решения такого нет, да и с запуском чеки потом нужно будет осторожно себя вести ... особенно в части проверки структуры таблиц ... но сегментирование журнальных таблиц, например по дате, может массу проблем, связанных с объемом обойти. Место, конечно, на дисковой подсистеме должно присутствовать ... но даже работы по архивированию сегментированной таблички могут вестись более эффективно, чем те же по функциональности работы на простых таблицах.

Правда АБД должен понимать что он делает

относительно прочих СУБД ничего не скажу - ибо не знаю их глубоко.

[edward_K]

Я обычно вообще убираю автоматческое сжатие журнала, а сжимаю средствами СУБД.

Можно поинтересоваться технологией?

Технология взята отсюда же. Приведу еще раз для MS SQL
Вот эту фигню вставляете в step 1, а в step 2 Exec p_integrity_clear_journal 15

Код: Выделить всё

------------------------------------
-- Запуск как 
-- Exec p_integrity_clear_journal  0
------------------------------------
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[AlexFDateToInt]') and xtype in (N'FN', N'IF', N'TF'))
drop function [dbo].[AlexFDateToInt]
GO

CREATE FUNCTION AlexFDateToInt  (@dd datetime)
RETURNS int
AS
BEGIN
   DECLARE @id int
   SET @id = convert(integer,( + convert(binary(2), year(@dd)) + convert(binary(1), month(@dd)) + convert(binary(1), day(@dd)) ))
   RETURN(@id)
END

--End----------------------------------------------------------------------------
GO


if exists (select * from sysobjects where id = object_id('dbo.p_integrity_clear_journal') and sysstat & 0xf = 4)
	drop procedure dbo.p_integrity_clear_journal

GO

-- Процедура для быстрой очистки журнала  LastDate datetime)
CREATE PROCEDURE dbo.p_integrity_clear_journal  ( @dd integer )
AS 
SET NOCOUNT ON 

DECLARE  @TableCode integer, 
   @TableName sysname, 
   @execsql nvarchar(1000) 

DECLARE   @LastDate integer

--SET XACT_ABORT ON 
SET @LastDate = dbo.AlexFDateToInt(dateadd( day, @dd * (-1), getdate()) )

-- SET @LastDate=ISNULL(@LastDate, CAST('99991231' as datetime))  -- очищаем весь журнал, если передан NULL 

--SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 
--BEGIN TRAN 

-- Блокируем удаляемые записи 
--SELECT @TableCode=MAX(TableCode) FROM X$JOURNAL WHERE STATUS IN (0,1,2,3) AND LASTDATE<=@LastDate 
-- begin
--IF @TableCode IS NULL  -- нет записей в журнале 
--  RETURN 
DECLARE JNRecCursor CURSOR LOCAL FAST_FORWARD 
FOR SELECT DISTINCT TableCode FROM X$JOURNAL WHERE STATUS IN (0,1,2,3) AND LASTDATE<=@LastDate group by TableCode

OPEN JNRecCursor 

WHILE 1=1 
BEGIN 
  FETCH NEXT FROM JNRecCursor INTO @TableCode 
  
  IF @@FETCH_STATUS<>0 
    BREAK 

  SET @TableName = 'J$'+CONVERT(VARCHAR(32),@TableCode) 
  SET @execsql = 'DELETE FROM '+@tablename+' WHERE J#NRec IN (SELECT NREC FROM X$JOURNAL WHERE STATUS IN (0,1,2,3) AND LASTDATE<='+str(@LastDate)+' AND TableCode='+str(@TableCode)+')' 
 EXEC sp_executesql @execsql
--, '@LastDate Interger, @TableCode int', @LastDate, @TableCode 
END 

CLOSE JNRecCursor 
DEALLOCATE JNRecCursor 

ALTER TABLE X$JOURNAL DISABLE TRIGGER X$JOURNAL_D 
DELETE FROM X$JOURNAL WHERE STATUS IN (0,1,2,3) AND LASTDATE<=@LastDate 
ALTER TABLE X$JOURNAL ENABLE TRIGGER X$JOURNAL_D 



--end
--COMMIT TRAN 



GO
--End----------------------------------------------------------------------------
GRANT  EXECUTE  ON dbo.p_integrity_clear_journal TO public
GO