dph,

Очередная сказка про то, что Оракл не масштабируется, "поэтому мы быстренько нафигачим тут на С++\Java свои кэши, свои джойны и все у нас будет"
Одно из наименее эффективных решений с точки зрения бизнеса - это иметь дело с дилетантами, которые пытаются решать любые задачи единственным известным им способом. Вот с чего вы взяли, что задача автора может быть эффективно решена с помощью "перенести на нормальный application layer"? Вы ж даже не знаете о какой системе идет речь.

Ну а это вообще шедевры:
mikkriСейчас мы задачу масштабирования решаем покупкой более мощного железа (SUN E2900 -> SUN M5000), но это тупиковый путь.
dphПросто вместо того, что бы наращивать БД, можно оптимизировать приложение, которое с ним работает. По сути, RAC - это масштабирование памяти под не слишком эффективный кэш и масштабирование процессора. И то, и другое - можно перенести на нормальный application layer и масштабировать как хочется.
Есть такой термин, применительно к информационным системам - масштабиру емость . Масштабиру емость - это адекватно увеличение производительности ИС при увеличении аппаратной мощности. Система считается хорошо масштабируемой, если производительность возрастает прямо пропорционально увеличению аппаратной мощности. Оракл как СУБД масштабируется очень эффективно, но приложения написанные под него, могут масштабироваться плохо. Точно так же, как и WebLogic - сам по себе этот сервер приложений масштабируется хорошо, но всегда найдутся криворукие му**ки, которые насоздают ботлнеков на ровном месте. И СУБД, и AppServer в обоих случаях не при чем.
Теперь про RAC. RAC - это альтернативное, более дешевое средство повышения производительности. Альтернативное покупке более дорогого железа. Т.е. грубо: если есть 8-х процессорный сервер и два варианта: либо купить один 16-ти процессорный, либо еще один 8-ми процессорный и лицензию на RAC. При это следует понимать, что масштабируемость у RAC ХУЖЕ , чем просто за счет покупки одного более мощного сервера. Т.е. повышать производительность за счет увеличения числа нод нельзя так же эффективно как и за счет более мощных серверов, но зато дешевле и во многих ситуациях может быть весьма выгодным решением. И еще, если приклад написан особенно криво, то RAC может не увеличить производительность ИС вообще.

mikkriРабота приложений с БД сейчас весьма не эффективна, так как на уровне приложения не делается кеширование. В результате если нужны данные транзакции, то они грузятся заново каждый раз. Из-за того, что несколько приложений могут поменять данные в одной и той же таблице, реализация кеширования весьма затруднительна и потребует серьезной переработки приложений.
Вы в этом уверены? Т.е. все возможные способы оптимизировать это на уровне БД уже точно исчерпаны?
mikkriреализация кеширования весьма затруднительна и потребует серьезной переработки приложений
Именно, по сути вам приедтся сделать почти тоже самое, что сделал Оракл: т.е. разводить конкурирующие потоки, согласовывать их по чтению и т.д.

Yo.!
не точная формулировка ;) как раз хохма в том, что масштабируемость RAC сегодня уже "лучше" чем у большой железяки. а если быть точнее то RAC масштабируется дальше, чем железяка .
Не, ну понятное дело, если взять саму большую железяку, котору на данный момент способны произвести и поставить рядом РАК из двух таких же железяк - то РАК конечно выиграет