Как стать автором
Обновить

Комментарии 24

Метрики по ключевым операциям (APDEX)

Времена порядка секунд. Время выполнения его самых тяжелых методов вообще от 4х дней до недели. Интересно что такого оно под капотом делает, что всё так медленно?

А что дала 8.3 по сравнению с 8.1?

И разве нельзя просто запустить старую конфигурацию на 8.3 вместо 8.1?

Запустить можно, но все в том же режиме совместимости. Т.е. ничего не изменится.

Не понимаю. Вы переписали конфигурацию, используя фишки 8.3?

Мы (Софтпоинт) не переписывали конфигурацию. Мы обеспечили бесшовный переход и страховочный мостик. Адаптацию кода заказчик взял полностью на себя - см. этап 2.

Обычно в регламентных скриптах параметр MAXDOP действительно выставляют в ноль (не ограничивают параллелизм) – это значительно ускоряет процессы пересчета индексов и статистик, а потом возвращают на исходное значение. 

Это как? В index rebuild и update statistics вы сами можете указывать MAXDOP для каждого оператора. И не надо ничего возвращать

Да, можно и, наверное, нужно, указать для каждого оператора. Но в этом случае сделано было так.

Не очень понял принцип работы DB Replication.

Оно на триггерах?
А почему не на rowversion?

Если вы имеете в виду rowversion как колонку, показывающую версию изменений, то это не вариант. DB Replication не производит структурных изменений в БД.

DB Replication не производит структурных изменений в БД.

А обмазывание триггерами всех таблиц тогда что?

Не очень понял принцип работы DB Replication.

Если это коммерческий секрет, то так и скажите.¯\_(ツ)_/¯

Платформа 1С не терпит изменений в ее таблицах, а триггеры можно.

Если опустить все детали, то принцип работы такой: триггеры пишут слепок изменений в таблицу очереди, транспортный Агент читает эту очередь и передаёт ее в базу назначения, а в базе назначения транспортный Агент применяет входящую очередь уже к таблицам 1С. Несколько подробнее про этом можно на сайте Софтпоинт почитать в ветке про продукт DB Replication.

Уточню: DB Replication не производит структурных изменений в таблицах 1С. Это критически важно для работоспособности 1С. Если добавлять колонки типа rowversion  , то это не совместимо с 1С.

Софтпоинт лечит падение сервера 1С переустановкой платформы. Ну что тут скажешь...

Это было сделано не Софтпоинтом, а сисадмином заказчика. Так получилось, что в ту ночь дежурил помощник системного администратора.

Про maxdop позабавило.

А УПП оставили на автоматических блокировках?

Используется режим управляемых блокировок

Теперь полученную конструкцию можно и на отечественный клон Postgre переводить. 8о)

При остатках в 500млн, очень велик шанс того что там просто не закрываются какие то остатки, отсюда и размер базы пухнет, я понимаю если бы обороты были огромные за несколько лет при активной деятельности, но остатки, это верный признак того что что то не так в системе. Вместо того чтобы разобраться с проблемами хранения данных, уменьшить объём базы на порядок и спокойно перенести, раздувают проблему на ровном месте. Это как онкологию травками лечить, вместо того чтобы делать операцию. Сегодня тебе будет лучше, а завтра ты умрешь. Так и с базой сегодня она стала работать быстрее и лучше, а через месяц/год она умрет, потому что это не лечение, а видимость.

И вправду, такое количество остатков очень подозрительно!

Неужели никто не посмотрел ни разу, что там такое?

В целом, почти у любой задачи всегда есть несколько вариантов решения. Но, как вы можете понять из заголовка статьи, основная идея для её написания не в том, как вы говорите – "вылечить базу", а в том, как без прерывания работы пользователей в этой базе, объём данных которой составляет несколько терабайт, повысить версию платформы и без режима совместимости с её архаичными версиями. Учитывая сказанное, и представив, что проблем с хранением данных нет, для терабайтной базы, фактически, без технологического окна, предложенная в статье методика замены платформы 1С вызывает интерес нестандартным подходом?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий