Почему же именно бухгалтерии и почему сотен гигабайт? 1С - это далеко не только бухгалтерия. А сотни гигабайт - это, наверное, тот минимальный размер БД, с которым к нам обращаются. Более того, в своей практике мы все чаще оперируем терабайтными базами с терабайтным приростом в год.
За 1С мы конечно же ответить не можем, но со своей стороны постоянно расширяем функционал мониторинга для анализа работы и производительности систем 1С на PostgreSQL и готовим интересные статьи на эту тематику. Подписывайтесь, чтобы не пропустить.
В целом, почти у любой задачи всегда есть несколько вариантов решения. Но, как вы можете понять из заголовка статьи, основная идея для её написания не в том, как вы говорите – "вылечить базу", а в том, как без прерывания работы пользователей в этой базе, объём данных которой составляет несколько терабайт, повысить версию платформы и без режима совместимости с её архаичными версиями. Учитывая сказанное, и представив, что проблем с хранением данных нет, для терабайтной базы, фактически, без технологического окна, предложенная в статье методика замены платформы 1С вызывает интерес нестандартным подходом?
Если вы имеете в виду rowversion как колонку, показывающую версию изменений, то это не вариант. DB Replication не производит структурных изменений в БД.
Мы (Софтпоинт) не переписывали конфигурацию. Мы обеспечили бесшовный переход и страховочный мостик. Адаптацию кода заказчик взял полностью на себя - см. этап 2.
Приведенная в статье статистика собрана, обработана и выведена в пользовательском интерфейсе с помощью программы мониторинга Perfexpert. Кроме того, эта статистика сразу обогащена данными из 1С:Предприятие - именами пользователей, потреблением ресурсов, строками кода и т.п. В SQL Server Managment Studio в подобном виде статистики нет.
Для того, чтобы проанализировать статистику по блокировкам штатными средствами можно воспользоваться несколькими вариантами:
Точную сумму длительностей ожиданий логических блокировок можно увидеть из стандартного трассировщика MS SQL или с использованием технологии Extended Events.
Природу блокировки и деревья блокировок можно получить из системных представлений MS SQL и системных таблиц. (sysprocesses и прочее).
Блокировки и взаимоблокировки в секунду на сервере MS SQL можно посмотреть из счетчиков MS SQL: locks/s , deadlocks/s. Также из других счетчиков можно увидеть ожидания на "нелогических" блокировках, например на системе ввода вывода, работы с памятью и прочее.
Правильное дополнение, но цель статьи несколько другая - рассказать про виды блокировок, наиболее часто встречающиеся в системах 1С:Предприятие, для помощи в анализе проблем производительности. Если рассматривать методику и ход действий специалистов при анализе проблем блокировок, то одним из первых шагов будет ваше дополнение. Спасибо. Возможно, имеет смысл написать отдельную статью.
Отчего же, используем. Но это уже этап, когда нет возможности увидеть целиком проблему в мониторинге. Кроме того, он требует моделирования конкретных действий пользователя и программы, что не всегда возможно в тестовой среде, например, в силу интеграционных моментов.
Это транзакционная репликация, целостность и консистентность данных в баз-получателе, конечно, обеспечивается. Накатывание очереди может осуществлять как в один поток, так и многопоточно.
Lob-значения, хранящиеся в таблицах 1С, мы успешно передаём. Причем в некоторых системах LOB-трафик занимает очень большую часть всего репликационного трафика.
Если перекидывать это через Dt то я посчитал - у меня получилось где-то сутки для базы 1.7 терабайт в MS SQL, без пересчета итогов.
Вся прелесть использования дальнейшей репликации – это некритичность к отставанию получившейся базы PG от продуктива MSSQL. Двое суток, трое или пять – неважно. Очереди прокачаются. Не мгновенно, но PG догонит MSSQL.
Вопрос «сколько времени DBReplication будет догонять продуктивную базу» конечно правомерен. Тут четкие цифры дать трудно. Зависит от специфики и состава транзакций в конкретной ИС, от производительности оборудования на стороне сервера PG, где обрабатывается и применяется входящая очередь, от особенностей структуры некоторых таблиц 1С и их индексов и распределения данных по ним.
Поэтому в разных случаях скорость прокачки одного и того же объёма изменений может отличаться довольно сильно - в 2-3 раза и более. Здесь можем апеллировать только к конкретным примерам. Например, в нашей практике за 5 суток был синхронизирован объем изменений 1 ТБ.
Таким образом, «держать мораторий» не требуется. Через несколько часов или дней (у кого как) базы будут полностью синхронизированы и можно просто переключить пользователей на другую БД.
Для маленького бизнеса можно использовать бесплатную сборку PG от той же 1С. Для среднего и крупного бизнеса куда важнее вопросы стабильности и безопасности работы СУБД, нежели ее стоимость, а также очень важно наличие поддержки от вендора.
Нужно рассматривать каждый блок или операцию в отдельности, а не всю систему в целом. При этом использовать метрики, позволяющие оценить отдельные операции, отдельные запросы, например, APDEX. И только на основе этого делать какие-то заключения. Субъективное мнение пользователей конечно тоже важно (это не сарказм), но вместе с тем я бы настоятельно рекомендовал сделать замеры по ключевым операциям ДО и ПОСЛЕ, чтобы было к чему апеллировать.
Если вы имеете в виду системы на платформе 1С 8, то там функционал реализован на уровне приложения. Для них функционал на уровне СУБД - это скорее исключительная ситуация и его доля будет незначительной. Поэтому про бизнес-логику речь не идет вообще.
А так-то да. Всё что написано на уровне MS SQL нужно правильно сконвертировать на PG.
Почему же именно бухгалтерии и почему сотен гигабайт?
1С - это далеко не только бухгалтерия. А сотни гигабайт - это, наверное, тот минимальный размер БД, с которым к нам обращаются. Более того, в своей практике мы все чаще оперируем терабайтными базами с терабайтным приростом в год.
Разбиение файлов tempDB конечно должно быть обязательным, здесь противоречий нет. Но оно не поможет при росте лога, а влияет на вероятность появления блокировок. В предыдущей статье как раз разбирал эту ситуацию: Записки оптимизатора (часть 7). «Нелогичные» блокировки MS SQL для систем 1С предприятия.
За 1С мы конечно же ответить не можем, но со своей стороны постоянно расширяем функционал мониторинга для анализа работы и производительности систем 1С на PostgreSQL и готовим интересные статьи на эту тематику. Подписывайтесь, чтобы не пропустить.
В целом, почти у любой задачи всегда есть несколько вариантов решения. Но, как вы можете понять из заголовка статьи, основная идея для её написания не в том, как вы говорите – "вылечить базу", а в том, как без прерывания работы пользователей в этой базе, объём данных которой составляет несколько терабайт, повысить версию платформы и без режима совместимости с её архаичными версиями. Учитывая сказанное, и представив, что проблем с хранением данных нет, для терабайтной базы, фактически, без технологического окна, предложенная в статье методика замены платформы 1С вызывает интерес нестандартным подходом?
Уже.
Прототип готов, включая систему мониторинга. Вот здесь есть раздел, посвященный этой задаче: Миграция с MSSQL Server на PostgreSQL. Предпосылки
Используется режим управляемых блокировок
Платформа 1С не терпит изменений в ее таблицах, а триггеры можно.
Если вы имеете в виду
rowversionкак колонку, показывающую версию изменений, то это не вариант. DB Replication не производит структурных изменений в БД.Да, можно и, наверное, нужно, указать для каждого оператора. Но в этом случае сделано было так.
Мы (Софтпоинт) не переписывали конфигурацию. Мы обеспечили бесшовный переход и страховочный мостик. Адаптацию кода заказчик взял полностью на себя - см. этап 2.
Запустить можно, но все в том же режиме совместимости. Т.е. ничего не изменится.
Ответил ниже, промахнулся с кнопкой.
Приведенная в статье статистика собрана, обработана и выведена в пользовательском интерфейсе с помощью программы мониторинга Perfexpert. Кроме того, эта статистика сразу обогащена данными из 1С:Предприятие - именами пользователей, потреблением ресурсов, строками кода и т.п. В SQL Server Managment Studio в подобном виде статистики нет.
Для того, чтобы проанализировать статистику по блокировкам штатными средствами можно воспользоваться несколькими вариантами:
Точную сумму длительностей ожиданий логических блокировок можно увидеть из стандартного трассировщика MS SQL или с использованием технологии Extended Events.
Природу блокировки и деревья блокировок можно получить из системных представлений MS SQL и системных таблиц. (sysprocesses и прочее).
Блокировки и взаимоблокировки в секунду на сервере MS SQL можно посмотреть из счетчиков MS SQL: locks/s , deadlocks/s. Также из других счетчиков можно увидеть ожидания на "нелогических" блокировках, например на системе ввода вывода, работы с памятью и прочее.
Правильное дополнение, но цель статьи несколько другая - рассказать про виды блокировок, наиболее часто встречающиеся в системах 1С:Предприятие, для помощи в анализе проблем производительности.
Если рассматривать методику и ход действий специалистов при анализе проблем блокировок, то одним из первых шагов будет ваше дополнение. Спасибо.
Возможно, имеет смысл написать отдельную статью.
Отчего же, используем. Но это уже этап, когда нет возможности увидеть целиком проблему в мониторинге. Кроме того, он требует моделирования конкретных действий пользователя и программы, что не всегда возможно в тестовой среде, например, в силу интеграционных моментов.
Это транзакционная репликация, целостность и консистентность данных в баз-получателе, конечно, обеспечивается. Накатывание очереди может осуществлять как в один поток, так и многопоточно.
Lob-значения, хранящиеся в таблицах 1С, мы успешно передаём. Причем в некоторых системах LOB-трафик занимает очень большую часть всего репликационного трафика.
Вся прелесть использования дальнейшей репликации – это некритичность к отставанию получившейся базы PG от продуктива MSSQL. Двое суток, трое или пять – неважно. Очереди прокачаются. Не мгновенно, но PG догонит MSSQL.
Вопрос «сколько времени DBReplication будет догонять продуктивную базу» конечно правомерен. Тут четкие цифры дать трудно. Зависит от специфики и состава транзакций в конкретной ИС, от производительности оборудования на стороне сервера PG, где обрабатывается и применяется входящая очередь, от особенностей структуры некоторых таблиц 1С и их индексов и распределения данных по ним.
Поэтому в разных случаях скорость прокачки одного и того же объёма изменений может отличаться довольно сильно - в 2-3 раза и более. Здесь можем апеллировать только к конкретным примерам. Например, в нашей практике за 5 суток был синхронизирован объем изменений 1 ТБ.
Таким образом, «держать мораторий» не требуется. Через несколько часов или дней (у кого как) базы будут полностью синхронизированы и можно просто переключить пользователей на другую БД.
Для маленького бизнеса можно использовать бесплатную сборку PG от той же 1С. Для среднего и крупного бизнеса куда важнее вопросы стабильности и безопасности работы СУБД, нежели ее стоимость, а также очень важно наличие поддержки от вендора.
Нужно рассматривать каждый блок или операцию в отдельности, а не всю систему в целом. При этом использовать метрики, позволяющие оценить отдельные операции, отдельные запросы, например, APDEX. И только на основе этого делать какие-то заключения. Субъективное мнение пользователей конечно тоже важно (это не сарказм), но вместе с тем я бы настоятельно рекомендовал сделать замеры по ключевым операциям ДО и ПОСЛЕ, чтобы было к чему апеллировать.
Если вы имеете в виду системы на платформе 1С 8, то там функционал реализован на уровне приложения. Для них функционал на уровне СУБД - это скорее исключительная ситуация и его доля будет незначительной. Поэтому про бизнес-логику речь не идет вообще.
А так-то да. Всё что написано на уровне MS SQL нужно правильно сконвертировать на PG.