Есть БД. Таблиц порядка 60. общее количество записей порядка 2 миллионов.
Возникла проблема при обновлении большого количества записей: за 1,5 - 2 часа идет обновление 30 тысяч записей. Это приводит к росту размера БД на 2 гига. Из-за чего это происходит и как с этим бороться?

Какую бы конфигурацию сервера Вы бы рекомендовали использовать (объем ОЗУ, CPU, HDD...)

5-10 записей в секунду - это очень небольшая нагрузка.


Мало данных о структуре и наполнении БД. А также об индексах, триггерах и всём остальном.


Ну 32 гига мозгу, 4 четырехголовых пня и 16-терабайтная полка... что тебе это даст?

Akina, 
Так в том то и проблема, что вроде операция небольшая идет. Но происходит довольно существенные рост использования дискового пространства.

Индексы только по первичному ключу. Структура таблиц простейшая. Каждая операция вставки/обновления данных затрагивает строк 30-40 примерно. Там запускается еще 3 триггера (тоже простейшие).

Просто это все запускается на слабенькой довольно тачке (особенно по сравнению с конфигурацией, предложенной выше   ). Раньше имел дело с FireBird, так он на таком железе и более объемные БД поддерживал и все ок.... И не было такого роста занятого под БД дискового пространства при объемных операциях.

Вот в принципе так.... ПРосто может я что не так кручу, что можно посмотреть и покрутить из настроек??? И что порекомендуете почитать?

Смотри свойства самОй базы. Если ей не установлено ограничение скорости роста и процент свободного пространства, то она и будет хавать, т.к. не будет использоваться пространство, высвобождаемое после работы триггера.
А что включено в понятие "размер БД"? лог транзакций часом не там же?

Добавлено через 32 секунды
И создай/настрой для неё нормальный Maintainance Plan.

Akina, 
конечно лог транзакций там же... Но просто после FireBird  очень не радостно видеть такие накладные расходы в плане дискового пространства. В SQlServer, насколько я понял, лог транзакций пишется всегда и пока его не забекапишь он не очищается.ТОгда как часто его надо бекапить??? Проблема в том, что имеем довольно огрнаиченную тачку под сервер...

Это сообщение отредактировал(а) FatherFrost - 10.11.2009, 10:21

MS SQL - это немного не файрбёрд. Другого класса СУБД. И требует иного подхода. Не поленитесь ознакомиться со свойствами базы данных, их достаточно много. В частности, никто не мешает ограничить лог транзакций по скорости роста. Не поленитесь также ознакомиться с понятием обслуживания базы, операциями и свойствами Maintainance Plan. Правильный график обслуживания снимет большинство описанных проблем.
Одним словом, начать следует с ненавистного для всех админов действия - чтения документации.

Akina, 
Так мануал уже курювовсю... Зачем мучать людей знающих, когда сам ничего не пробовал и не читал. В Maintance Plan настроены бекапы логов и фулл бекап. Вроде настройки БД смотрел, но вот как ограничить скорость роста журнала транзакций пока не нашел (но это временно).



Так вот очень сложно определить правильность 

Большое спасибо за советы. Пойду экспериментировать.

Для работы трёх БД 1С (более 260 таблиц каждая) размером 4, 6 и 12 гиг при 10-25 пользователях на каждой БД одновременно мне вполне хватало двухпроцессорного пня-1000 при 4 гигах мозгу под 2000 сервером и MS SQL 2000.

Akina, 
практически тоже самое. Только все три БД от 8 до 10 гигов и MS SqlServer 2005. Так работает вроде все ок, но когда идет объемное заполнение информацией таблиц, пакетами по 200 - 300 записей, начинаются глюки. Ладно буду настраивать и смотреть дальше.

Гм... что-то у вас там неладно, чего-то не видите. Если сервер встаёт... может, всё-таки триггеры не такие уж и простейшие?

Akina, сам сервер вроде работает, но через какоето время получаю в других подключениях обрыв транзакций по таймауту. Да я тут тоже думаю, что просто проблемы в настройках. Сейчас пока ограничил скорость роста файла лога транзакций. Попробую покрутить еще индексы на таблицах.

Это сообщение отредактировал(а) FatherFrost - 10.11.2009, 11:07

Если транзакция обваливается по тайм-ауту, то либо там что-то уж очень объёмное, либо получаются длительные блокировки. И то, и другое, скорее всего, ненормально и быть не должно.