Помещение журналов отката Oracle на DRAM SSD для тяжелой базы данных записи?

Сначала - я предполагаю, что у Вас есть очень немного дисков в массиве. 1200IOPS может легко поддерживаться быть 12 вращающими дисками (100 IOPS на диск очень разумно). Если кэш не может обработать его, это означает, что Ваш длительный уровень записи 1200 IOPS является путем больше, чем Ваши диски могут поддерживать.

Так или иначе SSD для журналов отката, вероятно, не поможет. Во-первых, Ваша сессия, ожидают главным образом на операторе COMMIT? Проверьте главные события ожидания в statspack / AWR для проверки. Я предположил бы, что ~95% Вашего ввода-вывода не к журналам отката вообще. Например, одна строка вставляют в таблицу с 5 индексами, может сделать 1 ввод-вывод для чтения блока таблицы (который имеет пространство для строки), считайте 5 индексных блоков (для обновления их), запишите 1 блок данных, 1 блок отмены и 5 индексных блоков (или больше, если нелистовые блоки обновляются), и 1 блок восстановления. Так, проверьте statspack и посмотрите Ваши события ожидания, Вы, вероятно, ожидаете много из ЧТЕНИЙ и ЗАПИСЕЙ для данных / индексы. Ожидание чтений замедляет ВСТАВКУ, и действие ЗАПИСИ делает ЧТЕНИЯ еще медленнее - это - те же диски (BTW - Вам действительно нужны все индексы? отбрасывание тех, кто не, должно иметь, ускорит вставки).

Другой вещью проверить является определение RAID - это RAID1 (зеркально отражающий - каждая запись является двумя записями), или RAID 5 (каждая запись является 2 чтениями и двумя записями для вычисления контрольной суммы). RAID 5 является путем медленнее в интенсивной записью загрузке.

BTW - если диски не могут hanlde загрузка записи, DBWR будет узким местом. Ваш SGA будет полон грязных блоков, и Вы не будете иметь пространство оставленные считать новые блоки (как индексные блоки, который должен быть обработан / обновленный), пока DBWR не может записать некоторые грязные блоки в диски. Снова, проверьте, что statspack / awr сообщают, что/addm диагностирует то, что является узким местом, обычно на основе лучших 5 ожидают события.

dd - ничто по сравнению с блоком i/o.

Для некоторых других представлений проверьте вокруг, anandtech.com сделал тест exaustive (предоставленный с SQL-сервером MS) с SAS, вращающимся по сравнению с SSD в различных комбинациях, и мир Соляриса имеет ZFS с SSD, составляющим различные части (журналы, кэш, и т.д.).

Но да, если RAID 5 по сравнению с RAID 10 является тем же (для записей), Вы делаете что-то не так. С линейными записями heck RAID 5 мог быть быстрее (т.е. он может сделать четность в памяти, затем записать дорожки и четность внезапно), но со случайным маленьким (4-8k) блоком, Вы уничтожаетесь путем обновления дорожек (как отмечено другими), набег 10 должен быть больше, чем 2x быстрее, в противном случае что-то неправильно.

Необходимо вырыть глубже, прежде чем Вы потратите деньги на аппаратные средства.

Если бы это поле только было x86/64 полем под управлением Linux, то я счастливо рекомендовал бы одну из карт диска FusionIO PCIe - они удивительно быстры и не 'умирают' с тяжелыми записями как SSD, делают. К сожалению, они не поддерживаются или с Sparc или с Солярисом, Вы могли бы хотеть связаться с ними для обсуждения этого все же.

Карта F20e PCIe подобна Fusion ввод-вывод в функции. Это - в основном просто присоединенный Flash PCIe SSD. С записью тяжелая рабочая нагрузка необходимо будет взволновать обоих по поводу поддержания достаточного количества свободных блоков (через основанную на диске сборку "мусора" некоторого вида), таким образом, Вы приведете в порядок не ветер со Стиранием/Циклом программы на SSD, становящемся узким местом, а также ограниченными циклами записи, доступными на основанном на Flash SSD. Это определенно быстро, но не могло бы быть лучшим набором для этого задания.