В целом, почти у любой задачи всегда есть несколько вариантов решения. Но, как вы можете понять из заголовка статьи, основная идея для её написания не в том, как вы говорите – "вылечить базу", а в том, как без прерывания работы пользователей в этой базе, объём данных которой составляет несколько терабайт, повысить версию платформы и без режима совместимости с её архаичными версиями. Учитывая сказанное, и представив, что проблем с хранением данных нет, для терабайтной базы, фактически, без технологического окна, предложенная в статье методика замены платформы 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.
Оценивать в среднем по больнице тут будет неверно. Есть пример, когда в первое время после перехода значительно просела производительность одного-двух функциональных блоков, при этом остальной функционал системы прекрасно работал на том же уровне, что и до миграции. Но PG уже не такой черный ящик как MS SQL и там есть что подкрутить, дописать. В этом его большой плюс. Главное правильно увидеть причину.
DB Replication - это не совсем про бэкапы. Цели у программы другие. Она помогает решать задачи: оперативного обмена между распределенными БД, создания и поддержки в актуальном состоянии консолидирующей БД, архивной БД, или БД с каким-то контуром учета. Помогает без остановки пользователей обрезать огромную БД, помогает бесшовно перейти с MSSQL v1 на MSSQL v2 или на PostgreSQL или с одной платформы 1С на другую. Да много кейсов еще. А восстановление баз из приведенных примеров - это просто использование технологии репликации в нужном месте и в нужное время.
В целом, почти у любой задачи всегда есть несколько вариантов решения. Но, как вы можете понять из заголовка статьи, основная идея для её написания не в том, как вы говорите – "вылечить базу", а в том, как без прерывания работы пользователей в этой базе, объём данных которой составляет несколько терабайт, повысить версию платформы и без режима совместимости с её архаичными версиями. Учитывая сказанное, и представив, что проблем с хранением данных нет, для терабайтной базы, фактически, без технологического окна, предложенная в статье методика замены платформы 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.
Оценивать в среднем по больнице тут будет неверно. Есть пример, когда в первое время после перехода значительно просела производительность одного-двух функциональных блоков, при этом остальной функционал системы прекрасно работал на том же уровне, что и до миграции. Но PG уже не такой черный ящик как MS SQL и там есть что подкрутить, дописать. В этом его большой плюс. Главное правильно увидеть причину.
DB Replication - это не совсем про бэкапы. Цели у программы другие. Она помогает решать задачи: оперативного обмена между распределенными БД, создания и поддержки в актуальном состоянии консолидирующей БД, архивной БД, или БД с каким-то контуром учета. Помогает без остановки пользователей обрезать огромную БД, помогает бесшовно перейти с MSSQL v1 на MSSQL v2 или на PostgreSQL или с одной платформы 1С на другую. Да много кейсов еще. А восстановление баз из приведенных примеров - это просто использование технологии репликации в нужном месте и в нужное время.
Админ может всё, в том числе остановить SQL.