Когда эта статья обсуждалась в комьюнити около года назад, общее мнение, насколько я помню, состояло в том, что статья написана не очень аккуратно. Закрывая глаза на то, как автор именует и пропорционально увеличивает log buffer, а также многие другие несуразицы, что можно сказать по поводу raw devices:

===
I personally had a very hard time with RAW devices doing so poorly. So for the TPC-C benchmarks, I added another benchmarking test scenario, giving the RAW device-based database twice the memory allocation as its cooked filesystem counterparts. I did this because I thought that the Linux filesystem buffer cache might be skewing my test results.
===

Неясно, как автор распределял дополнительную память под базу. Очень похоже на то, как он это делал в Part1. Т.е. пропорционально увеличивая data buffer cache, shared pool and log buffer. Очень похоже на то. Тогда как по понятным причинам нужно увеличивать только data buffer cache. Автор в 2 раза увеличил память "под базу" и получил около 1% увеличения производительности в целом. Очевидно, что характер нагрузки протестированный автором направлен в основном на запись данных и слабо учитывает чтение, что достаточно странно для OLTP. В этом случае практически не работает data buffer cache и видно, что от него практически нулевая отдача. Опять же не ясно какой объем памяти был изначально отведен на базу от общего объема памяти.

Хорошая статья, спасибо за ссылку.
Что касается выдержки из статьи (сорри, выделить не могу, в мозилле кнопочки не работают):

In DSS and large reporting environments, where a large data cache can actually have a negative impact to performance (due to the constant memory management overhead associated with flushing and reading blocks into memory) it is also highly recommended that buffered I/O not be used.

Здесь, насколько я понимаю, автор совершенно правильно говорит о том, что в силу природы запросов с большим объемом чтения данных в DSS, кэш файловой системы будет очень сильно размываться постоянным чтением большого объема блоков с диска. Если кэш-буфер Оракла "знает" о шаблоне доступа к данным (и следовательно защищен от размывания от FTS-операций), то кэш файловой системы просто кэширует поток данных с подсистемы ввода/вывода. Именно по этому твой тест (как мне кажется) не будет отражать реальной картины. Вывод: если есть возможность, лучше сознательно отдать больше памяти под кэш Оракла, чем ОС без спроса заберет у тебя под кэш файловой системы. Далее, я как-то говорил, что у Линукса достаточно слабенькие файловые системы, по сравнению с Unix-системами. 1) Макс. размер блока (и буфера) ФС = 4К. Для Оракла в наши дни 4К видится маленьким блоком даже для _чистой_ОЛТП_ Вопрос как поведет себя система при db_block_size=16К ? Кстати никто не знает, где подкручивается кол-во блоков упреждающего чтения (read ahead) в ext2? Асинхронный и прямой ВВ пока не поддерживается.

Какой был db_file_multiblock_read_count? Для варианта на raw devices в DSS лучше читать операциями с max I/O size, а для варианта на файловой системе все что выше read ahead не даст выигрыша. Да и любая "большая" операция ВВ будет терять на буферизации по 4К.

Я по-прежнему за raw devices, хотя у меня нет тестов, чтобы подтвердить этот выбор, все доводы только теория.