Есть Core i7 3770k/32gb, SSD Скорость 600/600Мб/С
Размер базы 4Gb.
На файловой переход с БП 2.0 на 3.0 занимает 8 часов.
Как думаете если поставить 1с сервер и постгре быстрее дело пойдет?

нет

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

тем более, в монопольном режиме (однопользовательском) обращение к диску кэшируется, даже если это ссд.

Кстати, а проблема в чем? у тебя случайно шара к этому диску поднята? Так отломай ее нах!

(2) А вот тут спорно
Можно же взять чистую базу БП3 и перенести в много потоков данные из старой базы БП2

(4) если бы он написал, что база 400 гб - я бы ещё задумался, что ему посоветовать - оператива _локального_ компа 32 и база 4 гб - о чем тут спорить?!

(0) Быстрее было бы свернуть базу БП2 (удалить лишние старые документы) что можно делать в фоне при текущей работе
А затем маленькую базу БП2 сконвертить в БП3

(3) Шары нет

(4) Это как?

Причем, если у него в базе, допустим на минуточку, разрешено изменение конфигурации с сохранением поддержки, то только на конфигурацию уйдет что-то более 1,5 гб от всей его базы, которые никак в многопоточку не раскроются

(5) Базу 400 гб задолбаешься переносить данные )) Хотя конечно смотря что там, если прикрепленные файлы то фигня вопрос

(7) ну если шар к ссд твоему нет 100% , то файловый режим однозначно самый быстрый на таком объеме данных

(8) Если у вас подобный вопрос возник то это не ваш вариант

(5) 400 гб - таких файловых баз не бывает

(13) :-)

(13) кстати, повторю еще раз мысль - база исходная в каком режиме подвергается переносу? там разрешено изменение конфиграции с сохранением поддержки? Это может быть причиной сильного замедления и ошибок при переходе из 2.0 в 3.0 через специальный дистрибутив для перехода.

(12) Я переношу загрузкой конфигурации БП 3.0. БП 2.0 и 3.0 структура данных не очень совпадает и там много выполняется кода для изменения данных. Во много потоков это я понимаю как загрузка данных из XML, но для этого нужны правила переноса БП 2.0 - 3.0. Насколько я понимаю официальных правил нет. Свои делать, как и чужие покупать и тестировать не вижу смысла.
Схема перехода отработана.
Хочется ее ускорить.

(12) И все таки это как?
Вопрос не в том как физически это сделать, вопрос в том что там данные пересекаться, и их трудно паралелить (это же не 2 организации паралельно грузить)
Ну разделим мы ТМЦ и зарплату, но это капля в море, Остальное время будут блокировки

(13) Бывают.
У 1С упирается в размер одной таблицы 4-6 гб, а таблиц в базе можно много понаделать и 400 гигов файловую теоретически получить

(15) В конфигурации минимальные изменения, типа добавлено поле в табличной части Реализации, добавлены новый роли с правами на свой вкус. Перед переносом, я возвращаю конфигурации к оригинальной 1с.

(16) А зачем такая цель? Процедура один раз делается. Нужно уложиться в какое-то конкретное время?

(16) Подожди что ты делаешь?
Ты вместо типового обновления конфы БП2>БП3 делаешь именно перенос данных через XML?

(21) Я делаю типовое обновление. Ты говоришь что можно грузить в несколько потоков. Я спрашиваю как это делать. Ты говоришь, что если я такое спрашиваю, то я нуб. Я тебе говорю, что я это понимаю как перенос через XML.

(19) (16) пишешь, что конфигурация _перед_ переносом установлена в абсолютно типовую, т.е. "под замок" ?

Но тогда для перехода из 2.0 в 3.0 используют специальный дистрибутив этого перехода. Не установку какой-то 3.0 из файла поставки, а именно специальный дистрибутив для перехода

"переход с БП 2.0 на 3.0 занимает 8 часов" это нужно каспера в параноидальном режиме включить, чтоб 8 часов. и чтобы еще 4гб не 1цд весил а дт

Вообщем, всем спасибо, буду переезжать через файловый вариант. Если будет скучно, параллельно запущу перенос через 1с сервер и буду смотреть кто победит.

(23) Именно его и использую.

В этом случае, с использованием перехода специальным дистрибутивом, файловый режим на локальном доступе будет всегда самый быстрый, если только сама база не слишком большая, а 4 гб - это очень маленькая база.

(24) Каспер это из какого то мультфильма? Не смотрел

(23) Какая разница, время похоже едят процедуры после первого запуска, а не действия в конфигураторе

(29) :-)

(29) и чего там есть-то на 4 гб одного 1цд-файла?! :-)))))
з.ы. он даже еще не начинал, а всего лишь только предварительно задумался

(22) >Я тебе говорю, что я это понимаю как перенос через XML

не обязательно XML, есть множество способов
в случае sql там даже на прямую запросами между базами можно

4 Гб, 8 часов на нормальном железе - что то больно долго.

(29) Тогда сначала в файловой в конфигураторе, затем базу в sql и первый запуск!

(34)+ но 32 оперативки слишком мало для sql нормальной работы

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

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

(37) и эти обе причины не имеют ничего общего с кодом типовой

да, что-то с базой похоже. Обычно обновление такой базы около часа. А тут 8 часов. Да еще какие-то xml.

(39) +1, или у тс темп на хдд

(38) В типовых типа идеальный код? Я с чем-то подобным (не помню уже, кажется там запрос в цикле был) сталкивался при переводе редакций розницы года три назад. Переписал процедуру получил ускорение на несколько порядков.

Код может быть и оптимальным и выполняться сотые доли секунды, например разбор марок в подсистеме для работы с ЧЗ. Только если поставка с 130тыс марок, то это уже занимает 22 минуты.

(0) Я думаю, что на MS SQL будет быстрее. Попробуй.
На постгре - не готов ответить.

(41) мне как-то безразлично, насколько он оптимален в типовой.
Есть базы на типовой, а большинство из них небольшие и как раз болтаются в пределах до 10 гб.
Есть переходы с бп 2.0 на бп 3.0. Практика, а не теория.
На практике подтверждается, что на файловом режиме это гораздо быстрей работает и никогда не занимает много времени,
при условии, что сама исходная база в порядке и там установлена типовая "под замком".

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

Про "файловая быстрее" для этих целей в большинстве случаев - согласен.

(45) а твое упрямство показывает что?!

(46) Мои версии в (37). Чтобы проверить достаточно ТСу открыть в обновленной копии отчет об обновлении. Время выполнения процедур фиксируется.

В отчете 1:22 минуты.
8 Часов уходит на
1. Свертку,
2. Загрузку конфигурации
3. Обработка при первом старте.

(48) я про отчёт который как раз 3. расшифровывает.
1. Ну и про свёртку ты забыл упомянуть)))
2. Если этот пункт со всеми реструктуризациями на 4Гб базе занял больше получаса, возможно у тебя действительно проблемы с железом