Теоретически, есть (был?) для этого такой хороший продукт как DB2 (IBM InfoSphere) Capture and Replay. https://learning.oreilly.com/library/view/getting-started-with/0738440396/
Были, вроде, и success story по нему. По идее, для сайзинга совершенно убойная вещь (учитывая возможность проигрывания с заданной скоростью).

А смысл? Мне кажется, Вы придумываете что-то не то.
Если есть необходимость оптимизировать стоимость лицензий DB2, можно много чего сделать (начиная с прямых переговоров с IBM; покупки лицензий, но отказа от renewal (== поддержки и апгрейдов); ...).
Закладывать заранее хитро-вывернутую архитектуру приложения, где часть нагрузки идёт на Read Only серверы... RO - это всё-таки удел вынесенных отчётов.

Что на HADR будет только один (!) честный главный Standby, и то на 99% не в полностью синхронном режиме (иначе он и сеть подсадят производительность изменений на Primary). Что 1000 других способов сделать копии основного сервера (репликации различных видов) на чтение - они не дадут полностью синхронного состояния. Для OLTP приложения это добавит огромное количество "чудес".
Селекты, опять же, не в воздухе сами по себе висят. Даже если какая-то большая часть транзакций Read Only, приложению в какой-то момент потребуется сделать update. И чего, менять соединение?

Надо также не забывать, что HADR - это всё-таки HA и DR решение. И когда Primary накернится, нужно будет как-то держать полную нагрузку.

На базу какого объема хватит этих 16 гиг + 4ядра в режиме OLTP мастера и балансира запросов на три асинхронных стэндбая?Очевидно, "it depends". Хотя у IBM и есть некоторый официальный sizing, но...

Три стэндбая - это предел , все верно?С помощью HADR без PureScale - да.

Можно ли сделать один синхронный standby и остальные 2 асинхронные?Только так и можно. Точнее 1 основной standby (principal) - это как правило NEARSYNC (крайне редко ставят полностью SYNC - он не бесплатен по части задержек на Primary). А дополнительные два - они вообще в режиме auxiliary (==SUPERASYNC режим).

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

А насколько кривой получился бы pureScale на обычных недорогих X86 железках, 10 гбитном Ethernet и т.п.? Внедрений pureScale ведь почти нет? Вакансий нет? Что ни так?Почему кривой. Делайте в соответствии с рекомендациями. Помните, что этот 10Gb Ethernet должен быть честным switch'ем с минимальными задержками, чтобы RDMA не тормозил.
Инсталляции - есть. Не знаю, есть ли в России, но у нас по факту и рынка как позиций DB2'шных, так и специалистов по большому счёту нет.
Другой вопрос необходимо ли вообще огород с PureScale городить.

Ответьте на вопрос "зачем":
1) защита от сбоев железа;
имеет смысл, когда не хватает HA части HADR технологии, но в определённой степени "поддержка" со стороны приложения всё равно требуется (понимание, что делать с прервавшейся по техническим причинам транзакцией).
2) ускорение;
один фиг выгодней наращивать память и ядра на одном сервере, пока это возможно. Современные конфигурации достаточно мощные, их банально будет хватать на подавляющее большинство задачь.
кроме того, хотя лично я вижу DB2 как отличную "молотилку", чисто исторически (если мы не говорим про mainframe'ы) часто на OLTP используют Oracle (тот же Oracle RAC), а DB2 пускают на хранилища/аналитику (к вопросу, почему мало инсталляций).
3) разделение нагрузки и мониторинга;
PureScale даёт отличную возможность развести нагрузку от разных приложений (особенно, если база - своеобразная точка интеграции данных и приложений) на разные узлы и просто физически их отдельно контролировать/мониторить; прилетевшая 100% нагрузка на второстепенном приложении не затронет основных и сразу будет видна без поисков "кто бросил валенок на "Пуск"".
Но надо, чтобы было кому этим плотно заниматься. До определённой степени можно подобное на Workload Management съэмулировать (кроме физического разнесения).
4) Комбинация 1 и 2.
Ну... сначала найдите такую задачу (задачу == чтобы выхлоп в денежном исчислении соответствовал).
Найдёте, уверяю, вопросов о покупке лицензий и правильного железа не возникнет.

Та инсталляция PureScale, с которой я лично имел дело (Европа, Скандинавия, поддержка во время нагрузочного тестирования по мелочи на время отпуска другого админа) была переходом с Db2/zOS на Db2 for LUW PureScale.
Марк, огромный поклон за помощь! (PureScale строится на TSA, и хотя с TSA много имел дела напрямую, включая хитрые варианты upgrade'ов, там у них была полная чехарда с зарегистрированными ресурсами, сам не справился)

Можно было бы что-то выиграть по сравнению с 3мя standbys по схеме пары серверов только для OLTP: master + principal, когда на них не идет отчетная нагрузка, а только для набивалок данных? Сколько такое недожелезо осилит дополнительных pureScale "share all" узлов для разбрасывания на них отчетной нагрузки?
Чтобы не было недопонимания, на всякий случай изложу.
1) В HADR изменения идут только на один узел. Все standby большей или меньшей степени синхронность - только на чтение.
2) HADR standby - отличное место для запуска отчётов (но, например, вы можете захотеть увеличить время задержки наката изменений, чтобы иметь быстродоступную "недавнюю" копию данных; надо смотреть, для каких отчётов это подходит)
3) PureScale - это не "Shared memory + Shared disks" вот прям так напрямую. Общий пул памяти (на CF) живёт как бы следующим уровнем кэша над локальными буфферпулами. Быстрый обмен между ними через RDMA - крайне важен. Shared диски организуются через GPFS, но, очевидно, на физическом уровне это может быть сделано тысячей разных способов и от этого (и от того, как вы разбросаете нагрузку) будет зависеть, как быстро каждый конкретный узел будет писать/читать и будет ли он мешать остальным.
Пара источников по GPFS - http://www.redbooks.ibm.com/redbooks/pdfs/sg248254.pdf, http://www.redbooks.ibm.com/redpapers/pdfs/redp3945.pdf
Я бы вообще никак не сравнивал HADR с Read Only Standby с PureScale конфигурациями. На пару порядков разница в степени потенциального геморроя и необходимых компетенций.

Хотя в целом, PureScale - отличная проверенная временем технология, просто снятая калькой с IBM Parallel Sysplex под z/OS.

Кстати, как называется "share nothing" решение от IBM для шардинга? Data-warehouse?
Database Partitioning Feature. Входит в различные редакции/offerings (включая облачные или on-premise инсталляции). Первое название на моей памяти (в 1996) - DB2 EEE (Extended Enterprise Edition).
Честная Share nothing. Конкретные пользовательские таблицы по желанию или реплицируются, или размазываются по узлам.
Очевидно, крайне важна быстрая внутренняя сеть на честном свиче для коммуникации "каждый-с-каждым" для обмена данными на объединениях/агрегациях.
С этой же точки зрения (аналитика) крайне интересна "теперешняя" технология BLU-Acceleration. Хотя тоже со своими сложностями и хитростями.

На уровне таблиц Partitioning - это уже другое. От обычного Range, продолжая, к примеру структурой, идентичной просто "массиву" с пропусками и с прямым доступом по id (фактически по offset).
Там много чего крайне эффективного можно навертеть, если к месту применять.

Не нравится, не ешьте :)

Если серьёзно, то
а) Вы говорите про блокировочник так, как буд-то это плохо.
б) Смысл говорить про единственность точки отказа CF, когда их всегда два (пока один не сломался)?
в) Обмен страницами локальных буффер-пулов с глобальным достаточно интеллектуален. Да, CF должны быть в достаточной степени мощными. Ну так они и не лицензируются :P
По факту, Вы встречали, чтобы на живой системе и рабочей нагрузке CF оказалась узким местом? Ну или ссылку на то, что у кого-то в них всё упёрлось (по выводу от MON_GET_CF_WAIT_TIME() и агрегированных CF_WAITS, CF_WAIT_TIME от MON_GET_PKG_CACHE_STMT())?

Главная причина малого количества инсталляций - место на рынке занято, всё, проехали. Хотя за последние лет 5 количество упоминаний в требованиях на вакансии увеличилось.
Ну а так - всегда чем-то за что-то приходится платить. Скажите ещё, что у Oracle RAC потенциальных узких мест нет.