Есть сервак: ОС Сервер 2008 SP2, процессор 2,4 Xeon, Оперативной памяти 8 Гиг. Винт скоростной FDD (твердотельный накопительный)
Пока база работала в файловом варианте, месяц перепроводился быстро (условно за 4 часа), но как только базу перевел в SQL (всё на этом же серваке) - это же проведение стало занимать 40 часов. (разница в скорости в SQL с FDD и HDD где то в 2-3 раза)
Поскажите, как ещё можно ускорить проведение?

Переписать алгоритмы в узких местах (через отладчик посмотреть). Ну и само собой запускать перепроведение на сервере, а не удаленно.
А вообще бы я на винт в файловый вариант выгружал на время проведения, там перепроводил, и потом обратно загружал - всё быстрее бы было в файловом варианте (это не для ленивых).

(1) База слишком большая (таблица продаж достигла размера, при котором уже невозможно выгрузить в файловый вариант). Перепись алгоритма - самое последнее (нет времени пока что на это)

(2) Тогда только пригласить специалиста.

(3) Хирурга ?

Кто знает, если оперативной памяти добавить до 32 или 64 Гиг. На сколько увеличится время проведения ?

(0) Задания для обслуживание баз на SQL сделаны (статистика, индексы и пр.)?

(2) Ну тогда только задания на обслуживание (как тут верно написали - статистики, индексы, лог) могут немного ускорить процесс. Плюс темповую таблицу скуля и лог занести на супербыстрый рейд (не ссд, естесвенно).
(5) Размер памяти не поможет.

отказаться от партионного учета

(0)комплекс мер
1. докрутка СКЛя
2. наращивание/оптимизация железа
3. поиск узких мест
4. переписывать/оптимизировать код

что у вас из этого списка уже сделано?

Была тема про это на форуме (v8: v8: Ускорение восстановления последовательности документов в УПП.. Идей там много люди высказали.

(10)радикальненько

я бы сначало выполнил п1-3 из (9)

(11) Согласен. Но эффекта в разы скорее всего не будет. только если база запущенная.

посмотреть не включено ли версионирование. Если включено то отключить на время проведения

Дожились! SQL базы на FDD опять хранят!
(0) Конечно переноси на HDD  - значительно быстрей будет!!!

(14) SSD винты ... перепутал

(15) + В два раза быстрее чем на HDD

(9) Получается что, остался пункт 4 :(

Чего то не верится что время замедлилось аж в 10-ть раз. Смотри в первую очередь в сторону настроек.

(18)  перепроверял, ... а я и забыл, что кластер на другом серваке ... похоже от него так тормозит

В случае таких расхождений обычно все лежит на поверхности. Вот если бы в 2-а раза... Тогда да - это возможно проблема.

(18) Кстати, вопрос: на практике хоть иногда разделение серверов SQL и 1С давало выигрыш в скорости? (при условии, что памяти хватает и для их совместной жизни).

Ну да, может не только от апликейшн сервера тормозить, могут и от клиентского места(хоть бы и терминала) быть тормоза.

Конечно давало, тут зависит от распределения нагрузки а также от сетевого трафика(сетевого соединения соответсвенно).

(21) Хотя бывали и обратные ситуации. Когда под апликейшн сервер давали совсем дохлую машинку. (возможно это случай сабжа)

Сегодня вечером подниму второй кластер, завтра сообщу, что изменилось
(24) Там нормальный сервак и с сеткой порядок (но всё равно надо пробовать)

(21) >> разделение серверов SQL и 1С давало выигрыш в скорости? (при условии, что памяти хватает и для их совместной жизни).

А разве должно (при условии, что памяти хватает и для их совместной жизни)?

Разделение как раз и делают тогда, когда серверы (приложения и СУБД) начинают конфликтовать за ресурсы. А пока всем всего хватает, целесообразнее их вместе держать.

Кстати! Может быть глюк в настройках сетевых интерфейсов (даже если всё это живет на одном серваке). Проверить дрова сетевых карт и обновить до последних версий.

(26)Написано только про память. А ведь есть еще ЦПУ, есть еще дисковая подсистема.

(0) Переставь сервер. На 2003. SQL можно оставить 2008. Работа реально ускорится. У меня машины реально покруче твоей - а тормоза были жуткие. Откат к 2003 серверу увеличил скорость в разы...

(28) тормоза в какой момент начались?
PS просто сейчас планируется переход как раз на 2008 сервак и скл