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

вопрос : как объединить два файла журнала регистрации?

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

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

(2) даже в среду случилось, если на то пошло)

а по существу вопроса есть что сказать?

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

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

Copy File1.log+File2.log File3.log

(0) Начало напомнило: Здравствуйте, меня зовут Вася и я алгоголик ;)
Без обид.

По теме - нельзя, журнал состоит из двух частей - лога события и файла описаний событий. Так вот, второй создается и дописывается динамически, по мере появления новых "объектов", пользоветелей и тп. Т.е., файлы логов между собой несовместимы. Даже если удастся заставить показывать базу оба сразу, в одно из ник будет совем не то, что было на самом деле.
Единственный вариант - (4) - это если удастся запустить 2 отдельных сервера (или в файловом режиме), кажды из которых настроен на соответветствующую папку.

Я бы рекомендовал из двух ваших кусков выбрать бОльший или болеее ценный, по вашему мнению, а второй похоронить.

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

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

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

к сожалению, (4) тоже не вариант, тк
Глобальный контекст (Global context)
ЗаписьЖурналаРегистрации (WriteLogEvent)

...
Средствами встроенного языка *не могут* записываться системные события, записываемые при записи объектов, удалении и т.д.

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

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

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

вариант*

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

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

(17) можно поподробнее?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(29) >>Разные у них "коды" событий, объектов метаданных, пользователей

Это же одна и та же база. Или я не так понял(0)?

(33) одна база.

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

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

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

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