ТанSergey L.Есть Informix 9.40.UC6 под Linux. Достаточно активно идет запись новых данных, при этом быстро запроняются logical logs - около 3-4х минут на один лог. Сейчас размер лога - 2048, 50 штук.
CKPTINTVL 300, при этом продолжительность чекпоинтов - 0 секунд (иногда 1).

Есть ли какие-то рекомендации для размера логов? Мне кажется, что 4минуты/лог - это слишком быстро. Повлияет ли увеличение размера на что-то еще, кроме увеличения времени бекапа лога?
если сервер умрет и придется восстанавливаться из бэкапа, то вы потеряете транзакции, которые находятся в незабэкапленных логах
Не всегда. Только в случае потери dbspace, на котором лежалт активный (последний) лог.

А при такой скорости заполнения я бы все таки рекомендовал увеличить размер лога хотя бы до 10М.
Посмотрите еще размер буфера лог.журнала - если у вас есть не буферизованная запись транзакций. то в журнал будут сбрасываться полностью буфера при каждой транзакции, а значит множество пустых страниц, увеличивая скорость заполнения на порядок. Т.е. размер буферов логжурнала можно часто уменьшить до законных 32 (а то иногда стоит 128 - 256, а спросишь зачем - не знают...)

Sergey L.Судя по документации :
rtfmWhen the database server flushes the buffer, only the used pages are written to disk. Used pages include pages that are only partially full, however, so some space is wasted.

Думаю, что документация не врет, а я многое уже забыл :)
Возможно, что буфер сбрасывался целиком в каких-то старых версиях Informix.
Но даже если принять то обстоятельство, что страницы сбрасываются полупустыми (или заполненными вообще на 10-20%), то сразу становится ясно, почему журнал заполняется значительно быстрее при хотя бы одной активной unbuffered БД на сервере.

zaietsН-да.
Вопрос относительно размера файла лог. журнала достаточно спорный.
Например я приверженец того, чтобы файл заполнялся где-то раз в 10 сек. +- 5 сек
Т.е. лишний раз перестраховываюсь.

Хотя вот 11.50 уже на мой размер - 2 метра, начинает ругаться, что типа м.б. мало для к.т.

В пользу большого размера файла(когда он заполняется минутами) я даже не найду аргументов.
Разве что на системах не особо требовательных к отказоустойчивости, либо само дисковое устройство зеркалируется аппаратно между основным и резервным датацентром.

В оракле да, там можно писать сразу на несколько устройств, у нас же каждый файл только в одном экземпляре. И если важна отказоустойчивость, то смысла в больших файлах (просто чтоб большой) я не вижу.
Нужно подбирать размер файлов из требоний по возможной потере данных. Конечно все хотят не потерять ни одной транзакции, но это недостежимо и никто не гарантирует что та же репликация будет работать 100% без збоев. Хотя в случае репликации ХДР, теоретически потери д.б. = 0.
Но в жизни часто бывает, что если задница, то полная. Поэтому лучше лишний раз страховаться.
Перестраховываться, конечно, можно, но не всегда целесообразно (например, иногда на голову падают кирпичи. Перестраховаться - это одеть каску. Если ходить по улице - будет смешно (вероятность все же маленькая), а если ходить по стройке - очень даже полезно и смешно будет ходить без каски).
Ты все правильно написал и я даже спорить не буду. просто для полноты картины приведу все же некоторые аргументы в пользу бОльших файлов (не для тебя, а для остальных читателей :)
- один из них уже упомянул - пространство с логами зазеркалировано или лежит на RAID
- переключение между журналами, насколько помню, относительно медленная процедура, поэтому тратить это время каждые 10 секунд в тяжело нагруженной системе, не всегда полезно
- время на старт-останов процесса архивирования маленького журнала также будет уже сопоставимо с временем заполнения
- некоторые советы из статьи "Неблокирующие контрольные точки в Informix Dynamic Server" (11.05.2007)
- С небольшим числом больших файлов журнала работать проще, чем с большим числом малых файлов журнала...
- Для приложений, генерирующих небольшой объем данных журнала , достаточно десяти файлов журнала объемом по 10 МБ каждый. Для приложений, генерирующих большой объем данных журнала, рекомендуется иметь 10 файлов журнала объемом по 100 МБ каждый.

- помню тут рассматривали очень хитрый баг даже в новых версиях, который проявлялся при переключении логов и при определенном стечении обстоятельств не давал нормально восстановиться из архива (с уменьшением числа переключенией вероятность бага ниже).
- для многих систем требуется довольно большой общий размер лога (2-4 Гб) и делать тысячу файлов по 2М в данном случае ...
- во многих пром.системах (но без особых требований к надежности :) логи даже не архивируются. В данном случае тоже нет смысла делать множество маленьких файлов