Оптимизация БД и(или) сервера

[Ramzes]

Есть у мну БД не сильно большая 11 ГБ. С этой базой постоянно работыет около 35-ти пользователей.
Сервер стоит не ахти, всех подробностей не знаю, но проц там Intel P IV 3.5 ГГц с включенным Hyper Threading, 3 Гб ОЗУ.
Windows 2k3 sp1 x86, MS SQL Server 2000 sp3

При всем при этом, у пользователей все жутко тормозит, и остро стал вопрос оптимизации, вплоть до того, что нужно ставить новый сервак, но есть одно но!

Так, как наш новый админ, говорит, что win2k3 x86 не видит больше 4 гб ОЗУ, а евсли и видит, то терят производительность (в его квалификации я не сомниваюсь, поэтому склонен ему верить на слово), то надо ставить win2k3 x64, но не факт, что на x64 станет sql Server 2k sp3, а если и станет, что сможет выжать все из новой операционки и памяти. Вариант по переходу на SQL Server 2005 рассматривается, но крайне не желателен.

Какие будут предложения и идеи?

[tyomitch]

Так, как наш новый админ, говорит, что win2k3 x86 не видит больше 4 гб ОЗУ, а евсли и видит, то терят производительность (в его квалификации я не сомниваюсь, поэтому склонен ему верить на слово), то надо ставить win2k3 x64

Видит. Теряет. Надо.

но не факт, что на x64 станет sql Server 2k sp3, а если и станет, что сможет выжать все из новой операционки и памяти. Вариант по переходу на SQL Server 2005 рассматривается, но крайне не желателен.

Станет х86 (версии х64 не существует). Не сможет. Рассмотрите.

[Ramzes]

Коротко и лаконично Спасибо.

А может есть еще какие предложения по оптимизации самой БД?

[alibek]

Сколько объектов в базе и какого они размера? Какой на сервере HDD?
11Гб не такой размер, чтобы причина тормозов была однозначно в железе.
Гораздо вероятнее, что БД не оптимизирована.
Смотреть планы запросов, расход памяти, строить правильные индексы, корректировать файловые группы и журналы транзакций.

[Ramzes]

Сколько объектов в базе и какого они размера? Какой на сервере HDD?
11Гб не такой размер, чтобы причина тормозов была однозначно в железе.
Гораздо вероятнее, что БД не оптимизирована.
Смотреть планы запросов, расход памяти, строить правильные индексы, корректировать файловые группы и журналы транзакций.

Обьектов ~ 14000
Винт саташный 250 с 8-ми метровым кешем, seagate наверное, больше ничего по этому поводу неизвесно
Планы всх запросов посмотреть нереально, их немеряное кол-во.
Индексы построены, надеюсь правильно
Файловая група всего одна, что в ней можно корретировать?
автоматическое сжатие отключено, размер увеличивается на 1 гб при необходимости
журнал транзакций 100 метров, увеличивается на 10 при необходимости

[alibek]

Обьектов ~ 14000
Винт саташный 250 с 8-ми метровым кешем, seagate наверное, больше ничего по этому поводу неизвесно
Планы всх запросов посмотреть нереально, их немеряное кол-во.

14000 объектов? Что-то это странно.
Сколько таблиц в БД? И сколько записей в основных рабочих таблицах?
Про HDD я имел ввиду IDE/SATA/SCSI, и имеется ли RAID.
Планы надо посмотреть если не всех, то хотя бы наиболее часто используемых запросов.

[Ramzes]

Обьектов ~ 14000
Винт саташный 250 с 8-ми метровым кешем, seagate наверное, больше ничего по этому поводу неизвесно
Планы всх запросов посмотреть нереально, их немеряное кол-во.

14000 объектов? Что-то это странно.
Сколько таблиц в БД? И сколько записей в основных рабочих таблицах?
Про HDD я имел ввиду IDE/SATA/SCSI, и имеется ли RAID.
Планы надо посмотреть если не всех, то хотя бы наиболее часто используемых запросов.

Таблиц почти 3000.
В основных таблицах (документооборот, бухгалтерия) от 500 тыс. до 1 млн записей.
SATA, RAID 5 уровня.
Так вот этих самых частоиспользуемх запросов по приблезительным подсчетам около тысячи, а у меня кроме оптимизации БД есть еще много других интересных и не мение срочных задач поэтом проанализировать даже часть запросов я не в силах, да и толку, оптимизировать их все равно не смогу, доступа к исходникам у меня нет

[alibek]

Зачем RAID5? Для СУБД было бы логичнее RAID10.
По основным таблицам смотреть статистику использования индексов, профайлером посмотреть, как выполняются запросы при некоторых типовых операциях.
Общих решений по оптимизации все-равно нет, надо рассматривать конкретный случай.

Но тут какие-то нестыковки.
Допустим, основных таблиц 200, а количество записей принять за 700 тысяч. При размере базы в 11Мб это выходит примерно по 80-100 байт на запись. Даже меньше, если учесть, что есть и другие таблицы, помимо основных, а размер собственно данных будет куда меньше размера базы. Довольно странная база данных получается, почти исключительно из чисел.

И оптимизация относится не к переписыванию запросов (хотя это было бы неплохо), а к перестроению индексов, если выяснится, что не все из них оптимальны.

[Antonariy]

Таблиц почти 3000

Фигасе. Это документооборот и бухгалтерия вселенной?

[Ramzes]

Алибек, основных таблиц не 200 (ну я не двести таблиц просматривал) такое кол-во записей есть в десятке таблиц.

Antonariy, это http://www.virtuoso.com.ua/

[HandKot]

как вариант:
- как минимум разнести файл базы данных и файл лога на отдельные вины -> снижение очереди винта
- создать секционированные вьюхи -> снижение выборок
-добавить еще одну файловую группу (или не одну) на другом винте и перенести туда часть таблицю Определить, с какими таблицами более всего работают пользователи, те и перенести, возможно по одной файловой группе на таблицу -> снижение очереди винта
- по профайлеру отследить возникают или нет блокировки. При положительном ответе избавится по возможности от них