_devel wrote:

> Не могу, понят, для чего нужен кэш для журнала транзакций? На что это
> влияет?

Видишь ли, может быть это довольно трудно понять, но ВСЯ работа с
файлами БД в ASE идёт через кэши. Без кэшей работа с данными не
производится. Поскольку журнал транзакций -- это файл на диске,
работа с ним также ведётся через кэш.

Просто нужно понять, что кэш -- это базовый механизм работы
ASE с данными, мимо которого пройти невозможно.

Я все время думал, что страницы лога постоянно сбрасываются на
> диск, чтоб в случае отключения питание, сервер мог накатить транзакции.
> Зачем ему(логу) кэш нужен?

Да, но при этом они остаются в памяти. Это write-through cache.
Зачем -- вопрос сложный, частично я ответил на него выше, ещё можно
добавить, что иногда кэширование лога не нужно, а иногда -- наоборот.

Ещё раз:
Кэш - базовый механизм работы с данными, который используется
ВЕЗДЕ. Без него доступа к данным нет. В том числе и к логу.

Иногда кэширование лога полезно, поскольку позволяет не читать
с диска уже устаревшие страницы лога. Это полезно для конфигураций
с репликацией, когда лог не только пишется, но и читается тоже.
Posted via ActualForum NNTP Server 1.4

_devel wrote:

> Т.е, вначале заполняется некий "user log cache", если он полностью

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

> заплнен, или транзакция завершилась(или еще что нибудь, типа смены
> контекста бд), он копируется в обычный кэш, или если есть то в logonly
> кэш. потом в зависимости от пула в кэше, пишется на диск. Если это
> logonly кэш, то надо установить sp_logiosize равным размеру пула в
> logonly кэше.


Всё более-менее правильно. Хочу добавить про назначение ULC.
При работе ВСЕ пользователи пишут ВСЕ свои комманды в лог, в его
последнюю страницу (или несколько страниц). Они должны при этом
синхронизировать доступ к этой страницые, т.е. вести его
строго посделовательно, друго за другом. Т.е. работа всех
пользователей в таких условиях ведётся ровно со сторостью записи
в этот лог. Чтобы хоть как-то рассинхронизировать и распараллелить
работу пользователей и придумали ULC. ULC выделяется в структуре
серверного процесса, т.е. он для каждого коннекшена свой, поэтому
к нему не нужно синхронизировать доступ. При работе транзакция
пишет сначала в ULC до тех пор, пока это возможно, потом,
при заплнении ULC, конце транзакции или при других условиях,
записи из ULC переносятся в последние страницы лога, с синхронизацией
доступа. При этом вместо много маленьких записей производится одна
большая.

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

Какой есть в кэше этом. Чаше всего 2k.

И зависит ли размер user log cache и размер пула в обычном кэше?

Нет.

> Для улучшения их размеры не должны быть равны, т.е user log cache size
> 4К, то и в обычном кэше должен быть четырех килобайтный кэш размером N?

нет. ULC может быть как больше, так и меньше размера пулов в кэше для
лога. На сколько я помню, ULC кратен 2k и ставится отдельным
параметром.
Posted via ActualForum NNTP Server 1.4

_devel wrote:

> Перемещается ли страница найденная в кэше до отмытия(до вош маркера) в к
> конец MRU?
> В документации написано что при стратегии MRU, так и
> происходит(перемещается), а вот про LRU-стратегию не чего не сказано.

Я так вот на вскидку точно не скажу, но вот пока мысль одна
только: если страница не будет перемещаться, то это значит,
что статистика использования страницы не будет обновляться,
поскольку она только положением в цепочке и определяется.

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

Я не очень понял, почему она должна перемещаться в
"в к конец MRU", что такое этот конец ( это MRU или LRU ?)
и при чём тут wash marker, который по идее не дожен влиять
вообще на положение страницы в кэше.
Posted via ActualForum NNTP Server 1.4

_devel пишет:
> это терминалогия у Сайбейса такая, "конец MRU", это и есть голова кеша.


Там закольцованная очередь, одна сторона MRU, другая LRU, я к такому привык.

На картинках кстати тоже описано два конца очереди: MRU и LRU, но слово
"конец" относитсся к слову "очередь", в общем лучше их просто
звать MRU & LRU, я так считаю.

Ну и я не понял, что там можно было не понять.
Posted via ActualForum NNTP Server 1.4

merphy9 wrote:

> А можно спросить "не только пишется, но и читается тоже" это только для
> издателя или для подписчиков тоже?

Для издателя, конечно. Т.е. для источника репликации.

Репагент, читая лог БД на сервере-источнике репликации,
формирует очередь репликации.
Posted via ActualForum NNTP Server 1.4