Коллеги добрый день!
Мы столкнулись с проблемой длительной реструктуризации информационной базы при обновлении 1C:Бухгалтерии(Бит:Финанс) 2.0 на 3.0.
1С:Предприятие 8.3.10
MS SQL Server 2008 R2
Размер базы 230 Гб
Количество записей в регистре бухгалтерии 10 000 000. Значения субконто 46 000 000.
Уже 3-е суток ms sql работает над запросом:
видим соединение таблиц регистра бухгалтерии хозрасчетный со значениями субконто.
Прилагаю также план запроса. В плане наблюдается NESTED LOOPS.
Есть ли мысли как оптимизировать/ускорить процедуру реструктуризации?
Мы столкнулись с проблемой длительной реструктуризации информационной базы при обновлении 1C:Бухгалтерии(Бит:Финанс) 2.0 на 3.0.
1С:Предприятие 8.3.10
MS SQL Server 2008 R2
Размер базы 230 Гб
Количество записей в регистре бухгалтерии 10 000 000. Значения субконто 46 000 000.
Уже 3-е суток ms sql работает над запросом:
SELECT TOP 1
T1._RecorderTRef,
T1._RecorderRRef
FR OM dbo._AccRgED479NG T1 WITH(NOLOCK)
LEFT OUTER JOIN dbo._AccRg443NG T2 WITH(NOLOCK)
ON T1._RecorderTRef = T2._RecorderTRef AND T1._RecorderRRef = T2._RecorderRRef AND T1._LineNo = T2._LineNo
WHERE T2._RecorderTRef IS NULL AND T2._RecorderRRef IS NULLвидим соединение таблиц регистра бухгалтерии хозрасчетный со значениями субконто.
Прилагаю также план запроса. В плане наблюдается NESTED LOOPS.
Есть ли мысли как оптимизировать/ускорить процедуру реструктуризации?
Прикрепленные файлы:
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) известная проблема для эксперта.
Исправить это никак!
Можно только обойти!
Если собирайтесь обходить, то легко найдете на ИС материал.
Но если не хотите, то тут 2 пути!
1. Удалить мусор / сделать свертку базы. Тогда процесс пойдет быстрее!
2. Ждать выхода новой платформы 8.3.11 насколько помню там анонсировали новый метод работы с MS SQL.
Исправить это никак!
Можно только обойти!
Если собирайтесь обходить, то легко найдете на ИС материал.
Но если не хотите, то тут 2 пути!
1. Удалить мусор / сделать свертку базы. Тогда процесс пойдет быстрее!
2. Ждать выхода новой платформы 8.3.11 насколько помню там анонсировали новый метод работы с MS SQL.
Не завершится никогда, скорее всего.
Столкнулись тоже с таким явлением - при обновлении БП2.0 Корп на БП3.0 Корп.
Проявляется при обновлении конфигурации БД на платформе 8.3.10.
Для себя решили проблему следующим образом:
1) обновление конфигурации БД запустили на платформе 8.3.8.2442.
2) затем первый вход в систему уже на платформе 8.3.10.
Столкнулись тоже с таким явлением - при обновлении БП2.0 Корп на БП3.0 Корп.
Проявляется при обновлении конфигурации БД на платформе 8.3.10.
Для себя решили проблему следующим образом:
1) обновление конфигурации БД запустили на платформе 8.3.8.2442.
2) затем первый вход в систему уже на платформе 8.3.10.
(6) В чем причина непонятно - в платформе 1С или в SQL?
Однако вот некоторые подробности, которые удалось выяснить - методом научного тыка, так сказать.
Дело в том, что такой запрос генерируется платформой 1С 8.3.10 по завершении реструктуризации регистра бухгалтерии.
И SQL2008R2 на нем зависает.
Да, на SQL2016 не виснет. И на SQL2014 тоже.
А вот платформой 8.3.8. такой запрос просто не генерируется, поэтому обновление благополучно завершается.
Однако вот некоторые подробности, которые удалось выяснить - методом научного тыка, так сказать.
Дело в том, что такой запрос генерируется платформой 1С 8.3.10 по завершении реструктуризации регистра бухгалтерии.
И SQL2008R2 на нем зависает.
Да, на SQL2016 не виснет. И на SQL2014 тоже.
А вот платформой 8.3.8. такой запрос просто не генерируется, поэтому обновление благополучно завершается.
(7)
Жирная и очевидная мораль: разработка и тестирование функционала платформы идет в ногу с развитием СУБД. Не следует обновлять платформу и при этом оставаться на бородатых версиях SQL. Никто не будет проверять работу свежего функционала на sql2008/2012.
Пусть это всем послужит уроком.
Считайте это злобной пасхалкой от 1с. Нужно рубить концы в прошлое, беспощадно. )
такой запрос генерируется платформой 1С 8.3.10 по завершении реструктуризации регистра бухгалтерии.
Спасибо за проверку. Это было очевидно, но если бы вы это не проверили, то я полез бы сам проверять )))
Жирная и очевидная мораль: разработка и тестирование функционала платформы идет в ногу с развитием СУБД. Не следует обновлять платформу и при этом оставаться на бородатых версиях SQL. Никто не будет проверять работу свежего функционала на sql2008/2012.
Пусть это всем послужит уроком.
Считайте это злобной пасхалкой от 1с. Нужно рубить концы в прошлое, беспощадно. )
(8)
Тут, пожалуй, Вы не правы - версии SQL2008/2012 официально поддерживаются 1С.
Поэтому эту ситуацию можно однозначно оценивать как серьезный "глюк" от 1С, который желательно бы и исправить, в разумные сроки.
Это версии платформ 1С 8.3. плодятся с ненормальной частотой, к сожалению.
Кстати, мы так и не смогли найти для себя объяснение, зачем нужен такой запрос после реструктуризации регистра бухгалтерии? В чем смысл этой проверки?
Да и не только после реструктуризации регистра бухгалтерии это происходит, оказывается.
Такой же запрос 8.3.10. генерирует после реструктуризации регистров накопления, как выяснилось. Однако, в этом случае, зависания SQL2008 не происходит.
Жирная и очевидная мораль: разработка и тестирование функционала платформы идет в ногу с развитием СУБД. Не следует обновлять платформу и при этом оставаться на бородатых версиях SQL. Никто не будет проверять работу свежего функционала на sql2008/2012.
Пусть это всем послужит уроком.
Считайте это злобной пасхалкой от 1с. Нужно рубить концы в прошлое, беспощадно. )
Пусть это всем послужит уроком.
Считайте это злобной пасхалкой от 1с. Нужно рубить концы в прошлое, беспощадно. )
Тут, пожалуй, Вы не правы - версии SQL2008/2012 официально поддерживаются 1С.
Поэтому эту ситуацию можно однозначно оценивать как серьезный "глюк" от 1С, который желательно бы и исправить, в разумные сроки.
Это версии платформ 1С 8.3. плодятся с ненормальной частотой, к сожалению.
Кстати, мы так и не смогли найти для себя объяснение, зачем нужен такой запрос после реструктуризации регистра бухгалтерии? В чем смысл этой проверки?
Да и не только после реструктуризации регистра бухгалтерии это происходит, оказывается.
Такой же запрос 8.3.10. генерирует после реструктуризации регистров накопления, как выяснилось. Однако, в этом случае, зависания SQL2008 не происходит.
(9) Конечно, в пост я вложил порцию сарказма ))
Исполняют его разные версии субд по разному лишь потому, что оптимизатор СУБД тоже имеет развитие и какие-то баги устраняются. 1с не должна при разработке ориентироваться на mssql 2000.
Другой вопрос, что 1с при обнаружении таких "особенностей" СУБД должна информировать всех и выраборать какие-то шаги: то ли отката функционала, то ли отказа от поддержки 2012 с такой-то версии. Хорошо ли это с точки зрения денег, лицензий и т.п. - не берусь судить. А вот с точки зрения технологий - я однозначно за прогресс и за использование всех передовых достижений.
Вы противник обновлений СУБД? У меня здесь пробел знаний: какие причины не обновляться?
Например, ни у кого не возникает вопросов по обновлению PG. На любой вопрос по производительности первый ответ - обновляй, без вариантов. В PG пытаются вывести оптимизацию запросов на должный уровень. Все движется семимильными шагами. Здорово. И PG тоже официально поддерживается, но огромная часть запросов имеют ту же проблему в планировщике и усердно испоьзуют нестед лупс. И это проблема в первую очередь построения плана запроса, а не написания запросов.
Почему же принято считать, что работа по улучшению MS остановилась 10 лет назад и нужно продолжать пользоваться устаревшими технологиями???
версии SQL2008/2012 официально поддерживаются 1С.
однозначно оценивать как серьезный "глюк" от 1С
Вот тут палехче... 1с тут условно не при чем. Запрос нормальный. Идеологически верный. Чистая ошибка планировщика.
однозначно оценивать как серьезный "глюк" от 1С
Исполняют его разные версии субд по разному лишь потому, что оптимизатор СУБД тоже имеет развитие и какие-то баги устраняются. 1с не должна при разработке ориентироваться на mssql 2000.
Другой вопрос, что 1с при обнаружении таких "особенностей" СУБД должна информировать всех и выраборать какие-то шаги: то ли отката функционала, то ли отказа от поддержки 2012 с такой-то версии. Хорошо ли это с точки зрения денег, лицензий и т.п. - не берусь судить. А вот с точки зрения технологий - я однозначно за прогресс и за использование всех передовых достижений.
Вы противник обновлений СУБД? У меня здесь пробел знаний: какие причины не обновляться?
Например, ни у кого не возникает вопросов по обновлению PG. На любой вопрос по производительности первый ответ - обновляй, без вариантов. В PG пытаются вывести оптимизацию запросов на должный уровень. Все движется семимильными шагами. Здорово. И PG тоже официально поддерживается, но огромная часть запросов имеют ту же проблему в планировщике и усердно испоьзуют нестед лупс. И это проблема в первую очередь построения плана запроса, а не написания запросов.
Почему же принято считать, что работа по улучшению MS остановилась 10 лет назад и нужно продолжать пользоваться устаревшими технологиями???
Идёт выборка из нового объекта регистра бухгалтерии.
Его создала платформа при применении конфигурации.
Так как индекс по регистратору не является покрывающим, то запрос выбирают все номера записей по регистратору. Данных не так много, но постоянное обращение в таблицу за _LineNo очень подкашивает скорость выполнения.
Можно сделать просто - переименовать оригинальную таблицу dbo._AccRg443 во временную под другим именем. Создать такую же по имено - dbo._AccRg443, но уже без данных. Провести реструктуризацию(мгновенно на этом регистре пройдёт) и написать в SQL запрос для переноса данных из резервной таблицы в реструктуризированную.
Его создала платформа при применении конфигурации.
Так как индекс по регистратору не является покрывающим, то запрос выбирают все номера записей по регистратору. Данных не так много, но постоянное обращение в таблицу за _LineNo очень подкашивает скорость выполнения.
Можно сделать просто - переименовать оригинальную таблицу dbo._AccRg443 во временную под другим именем. Создать такую же по имено - dbo._AccRg443, но уже без данных. Провести реструктуризацию(мгновенно на этом регистре пройдёт) и написать в SQL запрос для переноса данных из резервной таблицы в реструктуризированную.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот