ISC не зря советует журналировать всё (в документации об этом есть, да и Портал ругается при попытке создать нежурналируемую БД).

Если временное отключение журнала действует по отношению к глобалу, журналируемому "в мирное время", то это добавляет проблем с т.з. эксплуатации, т.к. в одном глобале могут оказать данные обеих категорий: записанные в журнал и нет. Как его восстанавливать, случись что? Ведь запись в глобал могла идти и во время бэкапа, и элементарно могут появиться незакрытые транзакции (а журнала в помощь не будет).

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

Кстати, когда активно "зеркало" (mirroring), DISABLE^%NOJRN игнорируется.

Для снижение нагрузки на дисковую подсистему рекомендуется отвести для журналов отдельный физический диск (в случае СХД: отдельный LUN в отдельной дисковой группе) с достаточно высокой производительностью по последовательной записи. Об этом тоже сказано в документации . ISC даже приводит некоторые цифры в качестве ориентиров, см. на коммьюнити .

Если в облаке, аптайм должен быть огромным у сервера (если только вы сами его не завесите))), поэтому я хранил бы все сырые данные во временных глобалах, которые в cachetemp, не заморачиваясь с включением-выключением журнала.

Блок А.Н.(документация говорит Disabling journaling using DISABLE^%NOJRN does not affect mirrored databases.).Собственно, и я о том же :)
Проверить, что данный вызов ничего не делает в зеркале, вполне могу, хотя на 100% уверен в результате, иначе вышло бы противоречие с идеологией зеркала: часть данных из зеркалируемой БД "отзеркалилась", а часть - нет.
Блок А.Н....риск потерять все данные в случае сбоя ненулевой, так что я бы не рекомендовал нужные данные хранить во временных глобалах.Согласен, но ТС намекнул, что не сильно опасается потерять сырые данные. А если опасается, то надо журналировать. Тот, кто хоть раз ремонтировал незажурналированные глобалы, меня поймёт :(

P.S. На облаке обычно есть разные виды бэкапов, в том числе и бэкап образа VM. Интересно, можно ли из такого бэкапа вытащить сохранённую БД CACHETEMP и подсунуть в работающую Cache под другим именем, после чего, используя ^GBLOCKCOPY, восстановить нужные глобалы?

Блок А.Н.С этой Cachetemp есть такая проблема, что глобалы могут в нее тупо не записываться, оставаться только в кэше.Могут, если они короткоживущие: у WD отдельная очередь буферов для CACHETEMP, она просто более длинная, чем для остальных баз.

При старте Cache БД CACHETEMP всегда чистится, но если делать внешний бэкап с заморозкой (недавно здесь обсуждалось), то WD сбросит грязные буфера перед заморозкой, поэтому CACHETEMP в сохранённом образе будет полностью комплектен на заданный момент времени.

Блок А.Н.Но и использовать объекты при миллионах записей в час странновато. Мне кажется, там лишние накладные расходы присутствуютМиллионы в час - это не миллионы в секунду... К тому же ТС, похоже, не жалуется на производительность.

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

Блок А.Н.... И с инкрементальными бэкапами в облаке тоже придется что-то делать.Это уже проблемы ТС :)
- возможно, существует более дешёвый тарифный план с более медленной скоростью доступа к СХД (где-то читал, что такое бывает, именно для архивации данных),
- к тому же, если не бэкапить ту БД, куда пишутся 10 млн. записей в час, inc-файлы будут скорее всего весьма скромного размера,
- наконец, можно удалять эти файлы неким внешним (или внутренним) скриптом, который несложно написать.

AlexKB,

Добрый день, Алексей. Прощаю наглую лесть, но только первый раз :)

Если речь о Cache, то журнал не совсем правильно называть "журнал после записи", т.к. запись в журнал обычно попадает раньше, чем в БД.

По поводу меток даты-времени в журнале: мне когда-то объясняли, что это время записи блока журнала в файл. Демон журнала просыпается очень часто: 1 раз в 2 сек, и при отсутствии ECP пишутся лишь полные буфера (всего их 128*64KB); по ссылке, которую приводил ранее, утверждается, что за 1 раз может писаться от 4K до 4M. Могу предположить, что при небольшом потоке записи порой пишутся и неполные буферы, иначе возник бы риск, что информация, записанная в БД, отсутствует в журнале, а насколько помню, существует гарантия, что всё, что сохранено в БД, должно быть уже в журнале, причём физически.

Подробностей алгоритмов не знаю, но из объяснений саппорта ISC помню главное: не стоит искать логику в журнальных временных метках, и тем более делать далеко идущих выводов.

Своё мнение о метках я высказал. Ещё вспомнил, что во новом файле [иногда] дублируется последний недозаполненный блок из предыдущего файла (со старыми метками, естественно).

Насчёт того, сколько можно потерять, вопрос более интересный. Начиная с какой-то версии Cache (кажется, 2013.1), если от демона журнала нет ответа в течение 10 сек, формируется предупреждение (оно пишется в console log), если же нет ответа в течение 30 секунд, формируется ошибка и запись в журнал замораживается. Если в конфигурации системы (... -> Настройка журнала ) активна опция "Замораживать систему при ошибках журнала", работа пользователей будет приостановлена. В таких условиях можно потерять журнальные записи за последние 30 сек перед аварийной остановкой Cache, если она всё же произойдёт. Если же опция не активна, и ошибка фатальна (журнал остановился), то работа пользователей продолжится, но уже без журнала.