В Solaris при недостатке памяти запускается page scanner (тред ядра), который выбрасывает на диск малоиспользуемые страницы памяти. Ему, в целом, фиолетово до того, какому процессу (или процессам) страницы принадлежат, т.ч. сложно сказать, кому первому станет плохо. При достаточно большом количестве пейджинга плохо будет всем, вплоть до невозможности залогиниться в ОС. При переходе пейджинга в своппинг, а это случится при прогрессирующем дефиците свободной оперативной памяти, т.е., в случае если пейджинг освобождает память медленнее, чем она потребляется, ОС будет совершенно недоступна ни по одному из каналов управления.

Большие страницы памяти в Solaris выпейдживаются точно так же замечательно, как и маленькие. Насчёт именно Solaris 11.2 сейчас не скажу (VM 2.0 и всё такое), а более ранние варианты выпейдживали большие страницы не целиком, а по одной странице стандартного размера, что приводило ещё и к фрагментации физической памяти и затрудняло выход системы, в которой были большие страницы и начался пейджинг, в нормальное состояние даже после устранения причины нерасчётного потребления памяти.

SGA не отображается на своп (и не выпейдживается), если используется ISM (это будет при ручном управлении SGA) и замечательно выпейдживается в иных случаях. PGA и иные прикладные части памяти выпейдживаются замечательно. Гарантированного лечения нет. Следите за системой, не доводите дело до цугундера, всегда имейте процентов 10 или пару гигабайт свободной памяти запаса для прикладных задач и еще процентов 10 или пару гигабайт - для диагностических средств (DTrace, мой любимый lockstat и т.п.).

UDW, как же это решается на 12g? Я догадываюсь, что Вы ответите, поэтому отвечу наперёд: память процессов Oracle - это не только SGA и PGA, а ещё в системе есть ядро и другие задачи, которым память тоже нужна и которые эту память могут скушать, причём - очень быстро, гигабайтами в секунду.

Располагать своп на SSD - пожалуй, самый бесполезный способ освоения бюджета на модернизацию оборудования. Причин тому несколько:

во-первых, в нормальном режиме работы (пока пейджинг не начался) никакого ввода-вывода на swap-устройства не производится от слова "совсем" и абсолютно всё равно какие диски этот swap обслуживают ибо на них будет ровно 0 операций в единицу времени;
во-вторых, пейджинг негативно влияет на производительность системы не только потому, что диск сильно медленнее памяти, а и потому, что процесс переноса страницы из памяти на диск и, при некотором невезении - сразу обратно, сам по себе требует вычислительных ресурсов, и сопровождается блокировками перемещаемых страниц и списков этих страниц, а, в случае больших страниц, - дефрагментацией физической памяти или же, если она выключена, - разбиением больших страниц на маленькие с последующей перманантной, хотя и обычно небольшой, потерей производительности;
в-третьих, просто люди засмеют.

Нужно просто не допускать попадания системы в состояние memory pressure, и у большинства тех, кто понимает и принимает реальность, нас окружающую, это получается, хотя требует приложения определённых усилий - разово и постоянно. А бюджет лучше потратить не на SSD для свопа, а на хорошую книжку .

UDW, "другие задачи" - это не обязательно что-то постороннее, это, условно, всё, что "ps -ef | grep -v ora". И за всем этим хозяйством нужно приглядывать.

Что же касается предложения забрасывать своп не SSDхами, а ажно сразу экзадатами - я искренне завидую Вашему бюджету :) Как фанат спарков, я б ещё предложил суперкластерами позабрасывать (и пофиг что там тоже своп надо тюнить :)). Но есть один нюанс (с). Экзадата тоже легко встаёт колом при отсутствии должного внимания на системном уровне. Самый, наверное, весёлый пример из личного опыта - остановка compute node из-за исчерпания свободных инодов (!) в ФС, а исчерпание, в свою очередь, произошло из-за каких-то чисто оракловых проблем, вызвавших откладывание маленьких трейсов на каждый чих.

UDW, со свопом в солярисе делается всё просто - на этапе инсталляции системы делаем swap=RAM и закрываем тему до тех пор, пока конфигурация оборудования не поменяется. Это почти избавит от проблем нехватки свопа и от поползновений использовать "свободную" виртуальную память. Бьём по рукам всех, кто хочет писать в /tmp гигабайты, ибо /tmp отображается на своп. Дальше калькулятор в руки и считаем, сколько, исходя из потребностей приложения, нужно делать SGA и PGA, сколько процессов будет в экземпляре (-ах). project.max-shm-memory=суммарной SGA всех экземпляров СУБД, работающих в этом проджекте плюс ещё немного. process.max-sem-nsems - по доке или по уму . Не стоит ограничивать память процессов, ибо если что, то лучше система в глубоком свопе (в который она придёт, скорее всего, не моментально!), чем рухнувший по ошибке выделения памяти LGWR. Ограничьте размер ZFS ARC. Запускаетесь, смотрите насколько раздувается ядро (echo '::memstat' | mdb -k), GOTO 10 :). Добиваетесь наличия в системе пары всегда свободных гигабайт (или процентов 10) RAM под нормальной нагрузкой, и ещё пары гигабайт (или ещё процентов 10).

Далее мониторинг по вкусу (лично мне милее всех icinga) - тут важен не движок, а "начинка", т.е. собственно скрипты мониторинга, которые придётся писать самостоятельно, ибо в интернете только котики и порнуха.

Гарантированного решения нет. Задачи системного администрирования на нынешнем уровне развития технологий автоматизируются очень плохо, разве только примитивные операции типа массового деплоймента фиксированных конфигураций.