Интересный документ про CERN и Oracle.
1) Oracle рекомендован в связи с наличием опыта (ну здесь на форуме этот ключевой момент любого проекта уже не раз обсасывался)
2) На текущий момент (20 June 2005) 16 нод работают на другом Oracle сайте (слухи действительно есть, а кто видел/повторил? сведения не от Oracle где?),
в самом CERN работают над прототипом системы с чилом нод от двух до восьми.
Какой век на дворе?????? Восемь нод???? Да даже если шестнадцать.......
Хм, но у конкурентов сотни.....
2) Верно указана основная проблема RAC, его "limiting factor" - inter-node network communications (cache coherency), и решать эту проблему предполагается "правильным" дизайном приложения (что уже противоречит основному постулату Oracle в случае RAC - не требуется изменения дизайна приложения и все такое прочее)
3) Но не затронута проблема скорости перераспределения "зон ответсвенности" в случае выхода из строя ноды. Время должно быть довольно таки большим, чтобы иметь стопудовую гарантию, что засбоившая нода мертва, иначе если она блин внезапно оживет, когда уже другая нода отвечает за данные - катастрофа становится очень реальной. Oracle Real Applications Administration Guide демонстрирует, что в тепличных условиях время "замерзания" приложений достигает 20 секунд. (http://www.bwbug.org/docs/BWBUG-May2004.ppt о том же)
4) Не затрагивается проблема overhead'a GCS (Global Cahe Service) который запущен на каждой ноде (сервис, ответственный за синхронизацию/сериализацию доступа к общим данным, чудес не бывает - синхронизация/сериализация должна быть). В тестах SAP SD Parralel Benchmark в конфигурации с 4 нодами overhead GCS достигал 12% на каждой ноде (Nov 9 2004)

PS.
-Стоимость решения сознательно пропущена.
-Ну а высказывание о Oracle 10g 'service' концепте, позволяющим структурировать большой кластер на группы нод , выделяемых для индивидуальных приложений, в совокупности с проблемой когерентности кэшей и GCS нагрузкой, заставляют задуматся о "кризисе жанра"