Скорость работы с диском на сервере супермага : Железо

SQL> set timing on
SQL> exec dbms_stats.gather_table_stats('SUPERMAG','FFMAPREP',degree=>16,cascade=>true);

Процедура PL/SQL успешно завершена.

Затрач.время: 00:00:42.65
SQL> select sum(bytes)/1024/1024/1024 from dba_segments where segment_name='FFMAPREP';

SUM(BYTES)/1024/1024/1024
-------------------------
,024902344

Затрач.время: 00:00:00.27

тогда не понимаю, что для чего не хватает :( Или аналитика очищена?

exec dbms_stats.gather_table_stats('SUPERMAG','FFMAPREP',degree=>16,cascade=>true);SQL>

PL/SQL procedure successfully completed.

Elapsed: 00:15:15.29

Около 10Гб.

всё в рабочем режиме. не хватает скорости обмена с вениками.
мне не нравится.

Это субъективно. И не отвечать на вопросы - признак дурных манер.
Почему именно диски виноватыми назначены? Какие именно операции долгие? Разнесена ли аналитика с оперативными таблицами?

всё разнесено. и индексы на отдельном зеркале и аналитика.
загрузка процессора небольшая и всё упирается в винты.

Это может быть и следствием неправильных планов запросов. Кроме того, "небольшая" это не одно ядро в потолке? "Упирается", это значит, что в момент проблем они выдают 150Мб/сек? Сколько памяти? Тема достаточно обширная, чтобы решать эту проблему исключительно увеличением пропускной способности винтов.

на серванте два ксеона, 16 гигов памяти (доступно 5)
средняя общая нагрузка на процы 15%

Это не то... "Общая нагрузка на процы" в данном случае, как и общая температура по больнице, ничего не дает. Большинство операций не параллелятся и тут решает быстродействие одного ядра. Смущает "доступно 5".

ага. не стал больше памяти ораклу отдавать.