Alexey Pechnikov wrote:
Да, клиентская сторона преимущественно на яве. Клиентов ~30. Процентов 80-90 - инсерты в схему + процедуры их обработки. База обсчитывает телематические услуги ~1000 пользователей. При обработке данных за месяц (билинговании) возникают как раз те проблемы, от которых желаем избавиться - сейчас на обсчёт уходит несколько часов. С половины суток это время снизили до 3х часов примерно. Узкое место сейчас io_wait, доступ к винтам (они 7200, sata, raid-5, аппаратный на LSI ). Смотрим в сторону внешнего сановского сториджа c FC интерфейсом и сановского сервака.В сообщении от Monday 12 November 2007 12:14:26 Max V. Kotov написал(а):Alexey Pechnikov wrote:Утр добрый! У нас ситуация похожая: прирост ~800Мб/мес. База пока 32Гб. Oracle 9. По началу не планировали тоже ни базу пересматривать, ни железо. IBM 3U, 4 двухядерных камня, 8Гб оперативки. В итоге часть процедур переработали+оптимизировали часть селектов и ко всему прочему вынуждены переползать на SUN сервера. Так что если база действительно серьёзная, думаю, вопрос не в выборе базы данных.А если _хорошо_ оптимизировать, то этого железа хватит. У вас в ОЗУ четверть базы можно разместить или все данные за год, это немало. Конечное, многое зависит от специфики приложения, но, имхо, железо менять рано вы надумали. Если у вас более 1000 одновременных пользователей, тогда возможно, и стоит. P.S. Если вас не затруднит привести дополнительные показатели, это будет весьма интересно.Какие конкретно?Количество одновременных пользователей, число запросов в секунду, метод подключения к базе (на java, наверно, раз речь идет о серваке ibm и работе с oracle), тип задач, соотношение запросов insert/update/select.