Объединить журналы регистрации #648818

Здравствуйте. у нас скульная база и нет бэкапа. журнал регистрации хранится на винте Е, не в месте по умолчанию, поэтому при обновлении платформы нужно прописывать путь и всё ок. админ забыл прописать путь и журнал начал копироваться в папку по умолчанию на диск С, место кончилось и недокопировался. журнал не разбивался по датам, велся одним большим файлом около 30гб соответственно сейчас записи разбиты на два файла не ровно друг за другом по датам. вопрос : как объединить два файла журнала регистрации?

вернее началось перемещение журнала и не закончилось успешно из за нехватки места.

"журнал не разбивался по датам, велся одним большим файлом около 30гб" пятничная ветка в четверг?

даже в среду случилось, если на то пошло) а по существу вопроса есть что сказать?

читаем файл журнала - пишем в нужный, правда пипец как долго будет

+4 а если просто закинуть файлы в папку - не подтянет? при детализации в день может и прокатит

Copy File1.log+File2.log File3.log

Начало напомнило: Здравствуйте, меня зовут Вася и я алгоголик ;) Без обид. По теме - нельзя, журнал состоит из двух частей - лога события и файла описаний событий. Так вот, второй создается и дописывается динамически, по мере появления новых "объектов", пользоветелей и тп. Т.е., файлы логов между собой несовместимы. Даже если удастся заставить показывать базу оба сразу, в одно из ник будет совем не то, что было на самом деле. Единственный вариант - - это если удастся запустить 2 отдельных сервера (или в файловом режиме), кажды из которых настроен на соответветствующую папку. Я бы рекомендовал из двух ваших кусков выбрать бОльший или болеее ценный, по вашему мнению, а второй похоронить.

Вместо похоронить можно попробовать сохранение журнала в файл *.elf, которой при необходимости потом открывать отдельно.

топорный метод) за 3 года писать инфу руками...ммм заманчиво... но пожалуй не буду :) я писал что нет разбивался файл(сокращение не делалось), так бы да, прокатило. скопировать всё в один можно было бы если бы по порядку шло спасибо. пока этот вариант и оставил. просто думал может что то получше можно сделать.

это тоже уже сделано на всякий случай. только будет крайне не удобно объяснять каждому из 100+ пользователей  где посмотреть...порой по нескольку раз.

к сожалению, тоже не вариант, тк Глобальный контекст (Global context) ЗаписьЖурналаРегистрации (WriteLogEvent) ... Средствами встроенного языка *не могут* записываться системные события, записываемые при записи объектов, удалении и т.д.

Поэтому только внешними ср-вами, а это "пипец как непросто"

или быть может я не понял того что вы написали?..

Нет, варинт из не прокатит ;)

вариант*

в семерке прокатил бы :)

А так, можно поиграться с архивированием журнала. Думаю, взлетит

можно поподробнее?

архивировать в другую базу журнал или о чем речь?

ну а выбросить этот журнал и начать новый, не судьба? Ну зачем может вообще может вообще понадобиться в жизни этот ваш журнал на 30 гигабайт, кроме как распечатать его на бумаге и подтирать им задницу? Как вы планируете его использовать?

Администрирование - Настройки журнала - [Сократить]

+ ну, или разбить по дням, потом слить воедино файлики

лично мне он не нужен. а вот руководство порой радуется от того что может узнать кто изменял документ год назад созданный.

спасибо. идею понял, попробую.

если не секрет, за сколько лет лог разбух до 30 гб?

с 2008 года. торговая контора.

сверток еще не делалось тоже...

у мну за три месяца всего журнал, но тормозит жутко. полтора гига

Не удастся вам слить воедино файлики, не помогут шаманские танцы. Разные у них "коды" событий, объектов метаданных, пользователей. Максимум чего добъетесь - кучи надписей типа "журнал регистрации поврежден" (я не помню точно сообщения). Хотя дерзайте конечно, любой опыт полезен. Для этого и можно было использовать отдельный внешний файл.

У нас 200 примерно пользователей за год набивают 15+Gb

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

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

>>Разные у них "коды" событий, объектов метаданных, пользователей Это же одна и та же база. Или я не так понял?

одна база.

>журнал не разбивался по датам, велся одним большим файлом около 30гб забейте - за разумное время из него толком все равно ни чего уже не получишь

Оно даже для одной базы разное может быть. То есть сначала он (файл определений lgf)пустой условно, потом заходит в базу пользователь А; появляется запись вида ПользовательА - код "1", потом пользователь ПользовательБ - код "2". А в другом случае первым зайдет Б и получит "код" 1. Соотв, в логах(lgp) в событиях будет разночтение - как интерпретировать пользователя "1". То самое с метаданными,  событиями etc. Я, вероятно, слишком катерично высказался что точно ничего не получится, учитывая что я разбирался с этим подробно пару дет назад и что-то могло поменятся.

если найдется время, поковыряюсь. что то притихли все, значит итак пока норм :)

тему можно закрыть