Comments 23
Метрики по ключевым операциям (APDEX)
Времена порядка секунд. Время выполнения его самых тяжелых методов вообще от 4х дней до недели. Интересно что такого оно под капотом делает, что всё так медленно?
А что дала 8.3 по сравнению с 8.1?
И разве нельзя просто запустить старую конфигурацию на 8.3 вместо 8.1?
Обычно в регламентных скриптах параметр 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С.
И если верно увидел, то два фейла было из-за регламентных скриптов.
Вот интересный проект: https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html (хотя, вы, наверное, знаете и так).
Софтпоинт лечит падение сервера 1С переустановкой платформы. Ну что тут скажешь...
Про maxdop позабавило.
А УПП оставили на автоматических блокировках?
Теперь полученную конструкцию можно и на отечественный клон Postgre переводить. 8о)
Уже.
Прототип готов, включая систему мониторинга. Вот здесь есть раздел, посвященный этой задаче: Миграция с MSSQL Server на PostgreSQL. Предпосылки
При остатках в 500млн, очень велик шанс того что там просто не закрываются какие то остатки, отсюда и размер базы пухнет, я понимаю если бы обороты были огромные за несколько лет при активной деятельности, но остатки, это верный признак того что что то не так в системе. Вместо того чтобы разобраться с проблемами хранения данных, уменьшить объём базы на порядок и спокойно перенести, раздувают проблему на ровном месте. Это как онкологию травками лечить, вместо того чтобы делать операцию. Сегодня тебе будет лучше, а завтра ты умрешь. Так и с базой сегодня она стала работать быстрее и лучше, а через месяц/год она умрет, потому что это не лечение, а видимость.
В целом, почти у любой задачи всегда есть несколько вариантов решения. Но, как вы можете понять из заголовка статьи, основная идея для её написания не в том, как вы говорите – "вылечить базу", а в том, как без прерывания работы пользователей в этой базе, объём данных которой составляет несколько терабайт, повысить версию платформы и без режима совместимости с её архаичными версиями. Учитывая сказанное, и представив, что проблем с хранением данных нет, для терабайтной базы, фактически, без технологического окна, предложенная в статье методика замены платформы 1С вызывает интерес нестандартным подходом?
Миграция терабайтной базы 1С: УПП с платформы 1C 8.1 на 8.3