С SDS ошибки есть.
Для запросов его можно использовать, все работает прекрасно ( 11.50.FC5W2 ).
Есть конечно свои ньюансы.

По поводу описанного случая - все так, как и должно быть(не согласен с темой топика).
1. Начинают транзакцию на секондари
2. Запись об изменении данных пошла в лог на праймери сервере
3. Транзакцию не комитят, а сразу запускают селект и имеют результат.

Почему его таким имеют:
1. Какой уровень изоляции используется на секондари? :)
2. Чтобы изменилось значение в буферном пуле на секондари, нужно
чтобы или были перечитаны данные или пришла инструкция с основного.

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

Для того, чтобы избежать подобной ситуации, IBM придется хорошо переделать работу
Updatable Secondary и передачи логов с основного - в ближайшее время вряд ли они это сделают.
Если сделают вообще.



По поводу Updatable Secondary и перераспределинии нагрузки - как по мне миф полнейший.
Проводили тест на вставку данных - просто включение Updatable Secondary тормозит скорость
вставки на основном. Вставка проверялась в пакетном режиме, потому как как правило
в первую очередь замечают проблемы быстродействия на пакетных операциях.

Т.о., за счет использования Updatable Secondary мы не получим желаемого масштабирования системы(может кто-то и получит, спорить не буду).

Кроме того, если смотрите рассылку RSS - там недавно была ссылка на то, что все транзакции в лог пишутся
с секондари от информикса.

Да, если нужен Updatable Secondary -нужно давить на саппорт, даный АПАР будут фиксить долго.

Но в данном случае я не рассчитывал бы на быструю и корректную заплатку.
Решение данной проблемы (чудо что ее кто-то сумел зарегистрировать),
если я правильно понимаю, из области архитектуры и скорее
всего дефект будет исправлен в каком-то конкретном fix pack
и скорее всего не в хс8 а в следующем или позже (Вадим лучше знает расклады IBM,
я токо отталкиваюсь от на опыта общения).
Также, исправление этой проблемы скорее всего будет требовать полного тестирования
работы с SDS, HDR и RSS и не факт что не будет новых ошибок.

Конечно, на ком-то нужно обкатывать новые технологии, но я для себя заморозил вариант использования Updatable Secondary в ближайшие 1-2 года, хотя в свое время строили
под это планы.

victor16zaiets1. Начинают транзакцию на секондари
2. Запись об изменении данных пошла в лог на праймери сервере
3. Транзакцию не комитят, а сразу запускают селект и имеют результат.

Если вместо SDS использовать HDR, результат будет правильный, поскольку там другой механизм управления буферами.


Да, действительно, на HDR все ОК, а это уже навевает вопросы - почему там все ОК?
На SDS передаются указатели на страницы лога, но проблема наверное не в этом.
Скорее в HDR неявно кто-то сделал ошибку, а может просто применили по лени механизм
работы с временными а на SDS перемудрили.

при желании, конечно, можно организовать террор саппорта - всем дружно задать вопрос - почему так работает и когда на SDS будет работать так как и на HDR.