Тормозит база

Вариантов много, а что сделано?
Для начала можно
обрезать логи в скуле,
переиндексировать базу средсвами 1с или скуля, кому как нравится,
Поставить увеличение файла базы скуля не в мегабайтах (по умолчанию), а в процентах
Перевести базу из FULL в Simple (у меня так сделано, но это тоже на вкус и цвет)

Операционная система, какая установлена?
Сервер SQL какой версии используете?

в смысле 1 документ проводится 6 минут?

Нет, группа документов проводится 6 минут
Поигравшись с энергопотреблением, созданием 10 tempdb фиксированного размера без увеличения время проведения уменьшилось до 4,5 минут

А как организован SQL у вас? Система должна быть физически на одном жёстком диске, SQL (сама база) на другом, желательно SCSI (если), т.е. разделить SQL базу Master и вашу базу - заметное ускорение должно наблюдаться.

В дополнение к оптимизации SQL сервера, можно еще поковырять проведение документов если конфигурация сильно кастомизированная. Может в самих документах быть затык.

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

Камрады, думаю попал в нужную тему. Требуются советы бывалых... попробую описать имеющуюся проблему.
Имеется база УТ 10.3 Агент+ (релиз 14.4 на данный момент) в файловом варианте, размер базы 15+ Гбт. Платформа 8.2.14 Работает одновременно 15 человек менеджеров + 5 "карманников" (торговые представители). Работают все в терминальном режиме. Сама база крутиться на мощном серваке WinServ 2008R2, RAM 12 Gb, 2 XEON E5530 (8 физ. ядер), 2 SAS винта в RAID (но насколько мог судить в единичке). Собственно база тормозит... причем как правило в начале рабочего дня всегда, потом по воле случая. При проведении по партиям возникают проблемы блокировок. Само проведение идет очень долго. Зависания могут быть как минуту, так и пять-шесть.
Брали копии базы с товарищем домой для тестирования. При подключении базы и загрузке в нее, база подвисла, шурша бедным винтом, через 5 минут отмерла и можно было продолжать работать. Тестирование ошибок не выявило, сжатие таблиц базы дало в сумме 1,5 Гбт места. Проведение по партиям за один день делалось 1,5 часа на достаточно мощном компе. Собственно после этого в однопользовательском режиме особо глюков не замечено. (ну оно и понятно)

Итак посоветуйте, что можно предпринять для увеличения производительности базы?
Даст ли выйгрыш отключение полнотекстового поиска, очистка его индекса, отключение пользовательского журнала регистрации, сжатие таблиц на самом сервере?
Один из франчей говорит переходите на "скуль", но руководство настроено отрицательно, выкладывать еще 170 штук не будет.
Если все таки переходить на серверное взаимодействие, то кто что может сказать про DB2, Oracle, Postgres... какова их производительность по сравнению со мелкософтовой скулей. По интернетам информация разная... но в целом говорят, что они проигрывают. Но я так понимаю главное разрулить блокировки.
Кто что может сказать про вариант публикации базы на веб-сервер (Apache предпочтительнее). Реально испытывал вариант только до 5 пользователей, да и база была Гиг с небольшим УТ 11.
Извиняюсь за многобукав еще раз, если кому не сложно помочь откликнитесь.

может в проблеме виноваты медленные жесткие диски?

Была аналогичная проблема, решилась заменой ЖД на SAS...

Кстати вдогонку, может кому пригодится - вышел MS SQL 2012, для бесплатной экспресс версии размер базы увеличили до 10Гб. так что для небольших организаций можно пробовать.

Попробуйте выгрузить и загрузить базу обратно.

Свертка базы, Поставьте винты SSD, слышал что на win 2003 serv и SQL 2005 Работает быстрее чем на 2008 Serv И SQL 2008.

Спасибо за советы, "выгрузить и загрузить назад" клиент в силах, по неведомым ему и мне причинам сервер не может сделать ни выгрузку, ни тестирование и исправление. Даже за ночь.
Свертку в крайнем случае попробуем. Ставить ССД винт пока тоже смысла не вижу, да и умрет быстро (1-2 года) при таких обьемах транзакций. Да и если проблемы с блокировками остануться, то винт не поможет.
Пока думаю взять базу домой и прогнать/твикнуть ее у себя, затем просто принести готовый результат. Но клиент пока что-то не хочет говорит мол сам попробую.

В общем камрады... проблема сохраняется. Пробовали с товарищем прогнать базу у себя, ставили специально 16Гб RAM результат нулевой. ТиИ всегда затыкается. Размер базы из-за этих тестирований уже дорос до 17Гб. Теоритечески размер базы может быть очень большим, поэтому на размер пока не смотрим.
Еще один интересный нюанс, когда базу подключаем у себя, то консольФоновыхЗаданий показывает 5-6 заданий. А на самом сервере видит только одно ФормированиеПоздравленийСотрудников. Кто-то с этим сталкивался? Что можно предпринять? Выгрузка/загрузка кстати уменьшает размер БД на 1-1,5Гб (как раз видимо размер индексов), но на самом сервере пока не делали, юзверей просто так не заставишь временно работать в другой базе.

Буду благодарен за любые советы.

уж лучше postgres, db2 с ним намучился достаточно, когда программил под эту штуку. как не крути но туповатая db2, клиенты с нее убегают, хотя проработали много лет

На таком количестве горячий пользователей думаю мало что можно сделать, или это всего пользователей?
От тормозов можно уходить через СКУЛЬ

Конфа какая ?
Какой документ проводится 6 минут ?
Релиз 1с какой ?
Если заинтересует расскажу как в MSSQL докрутить индексы необходимые - порой это спасает положение и производительность повышается. На некоторых операция можно получить прирост скорости 20%.
+ можно покрутить индексирование в самой 1с-ке в некоторых конфах они крайне криво используются !!!