Сервер под Oracle - оцените конфигурацию

[fk]

Планируется замена сервера под Oracle на примерную следующую конфигурацию.
2*2.80GHz XEON
Плата Intel SE7501BR2.
2 Gb памяти
Диски SCSI Seagate ST336607LC 36 Gb и ST373307LW 72 Gb
Диски IDE ST3120026A  120 Gb 2 шт.
Корпус Chieftec Dragon Series SC-901DS ATX 2.03, 2x400w
Операционка, backup и возможно archive log наверное будет на IDE дисках.
Интересуют вопросы:
1. Сколько дисков SCSI можно подключить на один канал (Ораклу чем больше, тем лучше  :) )
2. Сильно ли упадет производительность от использования IDE ? Возможно имеет смысл взять плату SE7501HG2 и только SCSI диски
3. Пойдет ли такой корпус ?

[Dmitry]

Intel платы вставлять лучше всего только в интел корпуса (типа SC5200), на крайняк в список сомместимых с сайта интела.

HG2 лучше чем BR2, но дороже. Кстати если вы будете использовать аппаратный RAID то необходимости в наборотовом SCSI нету.

Посмотрите в сторону новых решений на базе процессоров Xeon-64 (Nocona) - всеже решение более новое.

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

В сторону Supermicro не смотрели?, а то с новыми интелами пока засада, либо отсутствуют на складах в Росии либо сборщики пока не научились грамотно их конфигурировать и заказывать по компонентам в своих каналах.

[Dmitry]

Дисков чем больше - тем лучше - скорость выше.

Но конфигурация ооочень зависит от задачи - апро нее известно только то что у вас Oracle.

[fk]

RAID использоваться скорее всего не будет. Сохранность данных будет сделана срдествами самого Oracle.
Решения на базе процессоров Xeon-64  будут слишком дорогими.
Какие решения от Supermicro можно использовать?
Бюджет ~4500$

[Dmitry]

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

Это не правильно. RAID дает кроме надежности еще и скорость, а именно процесс насыщения сервера с RAID отодвинут гораздо дальше чем на простых SCSI адаптерах. - клиентов меньше держит.

Сохранность данных будет сделана срдествами самого Oracle.

Лучше комплексно, т к обеспечивается непрерывная работа. + мониторинг всего + возможность перестраивать узкие места дисковой системы и много др.

Решения на базе процессоров Xeon-64  будут слишком дорогими.

Заблуждение. Цены практически сравнялись. Максимум 10% разницы.

Какие решения от Supermicro можно использовать?

Мы так и не услышали какая задача - какая нагрузка?

Бюджет ~4500$

отличный бюджет. ждем задачу - сделаем оптимальную конфигурацию.

[fk]

База в данный момент ~30 Gb. Intranet сервер c БД под Oracle. В течении дня в основном небольшие транзакции, количество одновременно активных пользователей ~ 10. Ночью большие транзакции и расчет отчетов по собранным днем данным.

[fk]

Пока рассматривается такой вариант
2*Xeon 2800Mhz 512kb 533MHz
Плата Intel SE7501HG2
5 дисков SCSI Seagate 36Gb с базой без RAID
2 диска  -  SCSI Seagate  72 Gb - система, backup, archive log
(вроде бы их можно закрепить в корпус без доп.корзины ?)
корпус SC-5200 KHD3HSRP650 - нужен корпус башня
2 Гб. памяти KINGSTON

Или стоит обратить внимание на супермикру X5DP8-G2 например (тогда какой к ней корпус) ?

[a_shats]

X5DPE-G2 и корпус 742S-600, если надо не более 7 винтов. Если надо до 10 - 942S-600.
Винты рекомендую взять все одного размера, доставить SRCU42X или LSI 320-2X (почти одно и то же, только у 42Х некоторые фичи 2Х вырезаны), в идеале - добить 512 МБайт кэша, все винты - в RAID5, получившийся массив порезать на logical drives под сегменты и ОС.
Весьма шустрее будет . Один винт, кстати, заранее оставить в hot-spare.
Что до ОЗУ - если Windows, то более 2-4 ГБ (до 3 ГБ макс. для Оракла, afaik) действительно мало толку будет, если linux - можно на эту маму до 8 модулей ОЗУ посадить, под Вашу базу я бы вообще-то рекомендовал все-таки 4 ГБ.

[fk]

все винты - в RAID5, получившийся массив порезать на logical drives под сегменты и ОС.

На опыте предыдущего сервера скажу что (Compaq ML-570 2*700Mhz с RAID-5 на Smart Array 221) RAID-5 сильно тормозил работу базы. При выведении оперативного лога и индексов Оракла на отдельный SCSI диск производительность базы увеличилась.

[gs]

Рэйд5 под базой при слабом контроллере - далеко не образец быстродействия. Но кто запрещал рэйд10? Кроме того, настройками контроллера можно убить производительность - например выключив кэш.
Зато в случае отказа винта Вы ничего не заметите, в отличие от софтового варианта. Да и даже в случае более сурьезного отказа (более чем одного винта) в большинстве случаев есть возможность по крайней мере спасти информацию.

В общем, не принимайте как наезд, но неумение обращаться с рэйд контроллерами совсем не означает их тормознутости.

[a_shats]

Могу Вам с полной ответственностью сказать - производительность RAID-контроллеров с тех пор весьма и весьма выросла В частности, упомянутый 320-2Х выдает на-гора до 25К IOps из кэша. Опять же, и размеры оного кэша тоже очень выросли

[Stranger03]

А 2-х процессорной конфигурации с 2-мя гигами оперативки под базу размером более 30-ти гигов хватит? Что-то я очень сильно сомневаюсь. Я бы как минимум рассматривал вариант с 8-мью или больше гигами.

[a_shats]

Может. Из всех SQL Oracle наиболее аккуратно обращается с кэшем . По сути, 5% от объема  при правильной структуре БД для него может быть достаточно Тем не менее - почти согласен: почти потому, что Oracle AWE не знает (afaik не знал), потому - 3 ГБ под Win для него предел. Если же не Win, то...

[exLH]

Вроде как 9i, так и, тем паче, 10g знают про существование AWE и умеют им пользоваться для кэширования.

[a_shats]

Верно, я сам проглядел. Но - тем не менее:

Registry parameter AWE_WINDOW_MEMORY must be created and set in the appropriate key for your Oracle home. This parameter is specified in bytes and has a default value of 1 GB. AWE_WINDOW_MEMORY tells Oracle9i release 2 (9.2) how much of its 3 GB address space to reserve for mapping in database buffers.

This memory comes from the 3 GB virtual address space in Oracle9i release 2 (9.2), so its value must be less than 3 GB. Setting this parameter to a large value has the effect of using more of the address space for buffers and using less AWE memory for buffers. However, since accessing AWE buffers is somewhat slower than accessing virtual address space buffers, Oracle recommends that you tune these parameters to be as large as possible without adversely limiting database operations.

In general, the higher AWE_WINDOW_MEMORY is set, the fewer connections and memory allocations will be possible for Oracle9i release 2 (9.2). The lower AWE_WINDOW_MEMORY is set, the lower the performance.