Вход | Регистрация

  1  2   
1С:Предприятие :: 1С:Предприятие 8 общая

Секционирование регистра накопления

Секционирование регистра накопления
Я
   VitShvets
 
28.05.18 - 15:04
А баловался ли кто-нибудь? Есть регистр накопления, остатки. Секционировал по «_Period» таблицу итогов, по годам. Когда пишу 1Совый запрос:

РегистрНакопления.МойРегистр.Остатки(, [Отбор по одному полю в 50 тысяч строк])
1С это превращает в:

exec sp_executesql('.....
....
FROM dbo._AccumRgT27531 T2 WITH(NOLOCK)
WHERE T2._Period = P1
.....' P1 datetime2(3).... '5999-11-01 00:00:00'

В итоге SQL, из за sp_executesql и не явного указания периодов, не понимает что надо поднимать только одну секцию с периодом '5999-11-01 00:00:00' и поднимает все секции. Хотя если в менеджмент студии переписать запрос на:

FROM dbo._AccumRgT27531 T2 WITH(NOLOCK)
WHERE T2._Period = '5999-11-01 00:00:00'
….

Всё работает! Разница в скорости колоссальная – 1 секунда против 3 минут.

Решение есть - отказаться от запросов 1С против прямых запросов, но уж больно не хочется этого делать. Есть идеи как можно повлиять на
РегистрНакопления.МойРегистр.Остатки ?
 
 
   vde69
 
1 - 28.05.18 - 15:15
правильно спроектировать регистр....

я не понимаю как можно угробить регистр всего в 50тыс строк что-бы он запрос делал 3 минуты....
   impulse9
 
2 - 28.05.18 - 15:19
(0) индекс по полю есть? 3 минуты что-то многовато для 50 тысяч строк
   Вафель
 
3 - 28.05.18 - 15:32
(1) 50 тыщ строк в отборе. а не в таблице
   Wingless
 
4 - 28.05.18 - 15:40
(0) Разделители данных используются?
   vde69
 
5 - 28.05.18 - 16:05
(3) для этого делается ВТ и условие ... В(выбрать Т.* из ВТ1 как Т).

работает на ура...
   VitShvets
 
6 - 28.05.18 - 16:10
(1), (2) В регистре сотни миллионов записей. Конкретно в таблице итогов около 300 миллионов. ОТБОР  по 50 тысячам.
(2) Индекс по полю есть. Запрос попадает в кластерный индекс(сиик).
(4) не используются разделители.
(5) Именно так. Формируется выборка во времянку, индексируется. В отборе виртуальной таблицы указывается "ПолеОтбора В (Выбрать Ссыла ИЗ ВТ)".
   H A D G E H O G s
 
7 - 28.05.18 - 16:16
300 млн. в итогах - это конечно, эпик, даже если дело ведётся с бородатых лет, но я все равно не понял, что хотел сказать автор
   Bober
 
8 - 28.05.18 - 16:16
(0)  Герман Кудяков делал продукт на движке 1с, в котором был механизм секционирования СУБД MS SQL.
PS Нужно помнить, что при реструктуризации регистра все придется делать заново.
   H A D G E H O G s
 
9 - 28.05.18 - 16:16
Вангую итоги от рождества Христова
   ptiz
 
10 - 28.05.18 - 16:17
(6) "Конкретно в таблице итогов около 300 миллионов" - жуть какая. Это только в таблице оперативных итогов _AccumRgT27531 ???
Из интереса: сколько последних месяцев хранится? Там примерно по столько же?
 
 Рекламное место пустует
   H A D G E H O G s
 
11 - 28.05.18 - 16:19
Чем отличается запрос 1с от запроса автора?
   Bober
 
12 - 28.05.18 - 16:20
(6) так может в таблице итогов много нулевых итогов?
В 8.3 можно управлять период рассчитанных итогов, например с 1.1.2010 по 30.04.2018 (до 8.3 нельзя было управлять датой начала расчета итогов)
   vde69
 
13 - 28.05.18 - 16:27
(6) а кто будет указывать первый параметр виртуальной таблицы?


РегистрНакопления.МойРегистр.Остатки(???, [Отбор])
   VitShvets
 
14 - 28.05.18 - 16:28
(7) В курсе что такое секционирование и как это работает?
(8) Спасибо за наводку, пояндексю.
(9) Всего лишь с 2010 года.
(10) AccumRgT27531 это таблица всех итогов, за все года и месяцы. Оперативные итоги, это итоги у которых _Period = '5999-11-01 00:00:00'.
(11) Это один и тот-же кусок запроса, пойманный профайлером. Разница в том, что типовой 1Совый запрос получает условие по дате как параметр, а я устанавливаю условие как константу.
   Timon1405
 
15 - 28.05.18 - 16:29
(13) имеются ввиду текущие остатки, для них период указывать не нужно
   Bober
 
16 - 28.05.18 - 16:30
(14) какая версия СУБД и 1с?
   VitShvets
 
17 - 28.05.18 - 16:33
(12) скорее много не нулевых итогов. С этим боремся, но тут помощь не нужна, вопрос не в этом.
(12) >> В 8.3 можно управлять период рассчитанных итогов, например с 1.1.2010 по 30.04.2018
Гм... А можно поподробнее? Где почитать? Я бы с удовольствием удалил итоги за 2010-2016 годы.
(13) Хочется оперативных, текущих остатков. Отбор по периоду опущен специально.
(15) Именно!
(16) SQL Server 2012 SP4. 1С, древняя ещё толстоформенная КА на 8.3.10.2561 релизе.
   vde69
 
18 - 28.05.18 - 16:34
(15) кто сказал, что не нужно?

кстати интересный вопрос, что будет быстрее работать с датой или без нее....

ихмается мне что дело тут в секционности индекса, то есть в джойне нужно использовать поля соответсвующие основному индексу (при чем в правильном порядке), возможно во ВТ следует добавить несколько полей и подумать над соединением с физ таблицей...
   vde69
 
19 - 28.05.18 - 16:36
(17) >>>Хочется оперативных, текущих остатков. Отбор по периоду опущен специально.

попробуй период поставить такой (граница(конецмесяца(текущаядата())),истина)
   Вафель
 
20 - 28.05.18 - 16:37
(19) ты действительно не понимаешь какой запрос на сервер уходит и почему?
   Bober
 
21 - 28.05.18 - 16:39
(17) РегистрНакопленияМенеджер.УстановитьМинимальныйИМаксимальныйПериодыРассчитанныхИтогов
и еще пара методов для работы с этой возможностью.
   VitShvets
 
22 - 28.05.18 - 16:41
(18) Я говорю. Если не указывать, либо в параметр периода передать пустую дату, 1С интерпретирует это как запрос к оперативным итогам. Т.е. запрос будет ТОЛЬКО к таблице итогов и ТОЛЬКО к данным где _Period = '5999-11-01 00:00:00'. В случае указания любого периода, если не будет посчитанных данных на конец месяца, 1С будет строить запрос и к итогам и к движениям. Т.е. лучше не будет точно.
   Локи-13
 
23 - 28.05.18 - 16:41
(17) может проблема в версии скуля?
Почему отличается поведение по сути одинаковых запросов?
   Bober
 
24 - 28.05.18 - 16:42
(0) те при запросе к остаткам регистра ты получаешь идентичный запрос как если -бы ты сам его делал через студию. Запросы отличаются только в отборе по периоду.
   Локи-13
 
25 - 28.05.18 - 16:43
Опять же, если 
"Разница в скорости колоссальная – 1 секунда против 3 минут. "

То не вижу ничего предосудительного в использовании прямого запроса
   vde69
 
26 - 28.05.18 - 16:47
(25) а я вижу, как ты думаешь, тому кто придет на смену с этим всем разбираться?
   Локи-13
 
27 - 28.05.18 - 16:48
(26) судя по размеру базы абы кто туда не придет
   VitShvets
 
28 - 28.05.18 - 16:51
(21) Гляну, спасибо.
(23) Как я понял по комментариям чистых сиквельщиков, дело в неопрееленности периода. Т.к. запрос не прямой, а  через sp_executesql, отимизатор компилит его на "максимальное покрытие"
(24) Не совсем. Я ловлю запрос, копирую его в менеджмент студию, выполняю, вижу что в плане поднято 14 секций вместо одной. Чуть-чуть модифицирую - указываю дату константой а не параметром, получается тот-же запрос, но поднимающий 1 секцию и работающий на порядки быстрее.
(25) Я всё больше склоняюсь к этому.
(26) Меньше всего меня заботит на тему, что кто-то там придёт. Во первых я сам пока никуда не собираюсь. Во вторых мне зарплату платят за то, чтобы система работала. И работала в устраивающих меня и бизнес границах.
   VitShvets
 
29 - 28.05.18 - 17:24
(21) + (28) Беда-печаль. Семейство методов РегистрНакопленияМенеджер.УстановитьМинимальныйИМаксимальныйПериодыРассчитанныхИтогов работают с 8.3.2, а у меня стоит режим совместимости 8.2.16. А если просто удалить записи итогов, где период меньше, например, 01.01.2017?

И кстати об удалениях, кто-нибудь пробовал чистить периодический регистр сведений методом удаления записей SQL-ем? Вот таким способом:
delete from ТаблицаРегистраСведений where _Period < '2017-01-01'
Натыкались на какие-то последствия?
   ERWINS
 
30 - 28.05.18 - 17:25
А пробывал без регистра остатков?

Иногда на больших выходит быстрее
   VitShvets
 
31 - 28.05.18 - 17:37
(30) в непериодический регистр сведений писать и через group by итоги считать? Или как?
   ERWINS
 
32 - 28.05.18 - 17:41
(31) да
   ERWINS
 
33 - 28.05.18 - 17:42
Запрос проще и оптимизатору сложнее ошибиться
 
 
   VitShvets
 
34 - 28.05.18 - 17:46
В таблице движений х2 количество записей от итогов. Шансов попасть в индекс столько же, как и в секцию по итогам. Тогда уж на прямые запросы переходить, проблем имхо, будет меньше.
   pavig
 
35 - 28.05.18 - 18:15
(30)
Сурово
   ERWINS
 
36 - 28.05.18 - 18:20
(34) а нафиг тебе индекс то?
он по большому счету не используется если есть конструкт "В"
Там почти всегда используется фулскан.
   ERWINS
 
37 - 28.05.18 - 18:23
Остатки хороши для бухрегистров и то только потому, что они сделаны говенно.
   kittystark
 
38 - 28.05.18 - 18:42
(0) пробовал изменить запрос на ЛЕВОЕ соединение с "отборными" полями с последующим ГДЕ ЕСТЬ NULL ?
   ERWINS
 
39 - 28.05.18 - 18:54
(38) зачем?
основной запрос вообще не должен ничего включать кроме примитивного фильтра и группировки
   Bober
 
40 - 28.05.18 - 18:55
(29) тогда лучше всего посмотреть как работает секционирование на новой чистой базе 1с на SQL 2014\2016.
Где база 1с без режима совместимости и база СУБД тоже без режима совместимости.
   Bober
 
41 - 28.05.18 - 18:57
(29) прямым запросом все чистится без проблем. нужно только помнить что в 8.3 у такого регистра появились таблица итогов (текущий срез данных). и в таблице изменений может быть много чего зарегистрировано (но не так критично, как итоги).
   Genayo
 
42 - 28.05.18 - 19:14
Были примерно такие же проблемы с оборотным регистром, перешли на использование агрегатов, и все стало хорошо. А так, оставь только актуальные итоги, и посмотри на быстродействие.
   VitShvets
 
43 - 28.05.18 - 19:20
(36) В индекс оно таки попадает, в кластерный, причём сиком, а не сканом. И лопатит не всю таблицу итогов, а треть от неё. В полной таблице ещё вопрос какой индекс должен быть и как угадать попадание в него оптимизатором. Табле скан будет люто печальным, гораздо тяжелее.
(38) Пробовал join добавлять, разный, не помогает. Соединение отрабатывает после тяжелой выборки.
(40) Видимо не секционирование, а установку минимального периода итогов? Посмотрю профайлером чем он там занимается, была такая идея.
(41) Регистр сведений, что хочу почистить не периодический и флагов "Разрешить итоги: ххх" не стоит. Т.е. Таблиц итогов там нет. И изменения не фиксируются, данный регистр не участвует в планах обмена. Ну по крайней мере таблица регистраций изменений пуста.
   VitShvets
 
44 - 28.05.18 - 19:26
(42) Были бы у остаточных регистров агрегаты... Только актуальные итоги оставить не получится, иногда требуется остатки на какой-то период. Собственно секционированием я и пытался добиться использования только оперативных итогов, сложил их аккуратно в отдельную секцию... Но эта зараза не желает выбирать маленькую порцию данных, упорно читает всю таблицу. В это и вопрос, как обязать сиквел и/или 1С использовать одну секцию и не лезть куда не просят.
   ERWINS
 
45 - 28.05.18 - 20:08
(43) вообще то вначале будет сканировать индекс(есть некоторая не здоровая уверенность что не кластерный), а потом выбирать цифорки уже из полной таблицы, что в принципе может быть намного дольше - 2 последовательных выборок вместо одной но большей?

"Табле скан будет люто печальным, гораздо тяжелее. " попробуй несколько запросов чуть разных подряд. Скорость удивит.
   ERWINS
 
46 - 28.05.18 - 20:09
(44) только если нет строк неограниченной длинны. Иначе печалька.
   VitShvets
 
47 - 28.05.18 - 20:36
(45) Можно попробовать выборку из основной таблицы, без использования виртуальной "Остатки", в принципе должно тоже самое получиться. Я правильно понимаю идею? Делаю выборку по отбору с получением ресурсов и группировкой. При этом будет скорее всего индекс сик по отбору, кей-лукап для получения ресурса. Далее скорее всего будет Hash Match (Aggregate) для получения SUM. И это должно отработать быстрее получения итогов?
   VitShvets
 
48 - 28.05.18 - 20:38
(46) такую ересь первым делом из регистров убрал. Было в одном месте, пока поменял ntext на nvarchar(100), попозже  удалю совсем.
   ERWINS
 
49 - 28.05.18 - 20:47
(47) да. быстрее, но после прогревки кеша. Т.е. если запрос выполняется часто. Проблема именно в том, что сложный запрос к остаткам иногда выбирает неверный план.
 
 Рекламное место пустует
   ERWINS
 
50 - 28.05.18 - 20:49
кроме того запрос прямой. думаю что там даже не будет индекссик, просто табле скан, но это быстрее, чем сложный запрос у меня вышло.

Конечно условие что все отборы должны быть максимально простыми (= или В конкретных значений)
   VitShvets
 
51 - 28.05.18 - 20:56
(49), (50) С горячим кэшем беда. У меня не один такой регистр, есть ещё более тяжелые, бухгалтерские. Кэш хитс болтается между 99% и 99.9% в среднем, но периодически выпадает сильно ниже. Но попробую, завтра уже, отпишусь.
   ERWINS
 
52 - 29.05.18 - 09:39
(51) бухгалтерские отдельная песня. Там Субконто и соотвествено у меня этот финт не работал.
   МихаилМ
 
53 - 29.05.18 - 09:40
(0) нормально будет работать . статистика не построилась.
   МихаилМ
 
54 - 29.05.18 - 09:44
(8) есть защита от неправильного пересоздания - ddl триггеры. http://catalog.mista.ru/public/114634/
   МихаилМ
 
55 - 29.05.18 - 09:45
(51) 80% попадание в кэш считается достаточным результатом.
   ERWINS
 
56 - 29.05.18 - 10:02
(55) если эмуляция инмемори, то  нормальным 100%
   VitShvets
 
57 - 29.05.18 - 16:40
(8) Пояндексил я наработки Германа Кудякова. Есть у него проект, Ei, брошен лет 5 назад, по крайней мере последнее обновление датируется 6 ноября 2013 г. Но такое ощущение, что проект его связан именно с инструментом-генератором SQL запросов. Дабы не в менеджмент студии запросы писать, а в 1С мышкой тыкать.
(52) Попробовал... Что хочу сказать, 1С странная... :) Результаты действительно интересные. На inner join/where отборе с временной таблицей-отбором срабатывает индекс сиик не кластерный, всё отбирается, далее по небольшой выборке проходит кей лукап и соббственно всё. При примерно одинаковом количестве ридсов, нагрузка на ЦПУ в 100 раз меньше, время выполнения в 100 раз быстрее. Буду проверять одинаковость выборок, но... Интересно.
(53) У меня каждую ночь статистика обновляется, не работает почему-то. Нужен какой-то волшебный пендель 1С и/или SQL. Вот какой?
(54) Объекты что сжаты и секционированы меняются крайне редко, руками можно восстановить. Ну в моём случае.
(55), (56) Я у себя заметил, т.к. база большая, если попадание в кэш опускается хотя-бы до 90%, производительность системы сильно падает. Визуально заметно на некоторых операциях.
   МихаилМ
 
58 - 29.05.18 - 17:12
(57)
почитайте https://habr.com/post/330070/

две полседние строчки статьи. похоже на Ваш случай
   ERWINS
 
59 - 29.05.18 - 17:56
(57) будут тесты, выложите плз
   ERWINS
 
60 - 29.05.18 - 18:03
(57) в 2012 скл был прикол - операция где в (2 значения) вызывала индекс скан
а одно значение индекс сик

поэтому приходилось делать запрос с объединением кусков
   VitShvets
 
61 - 29.05.18 - 19:56
(58) Ооочень похоже на parameter sniffing. Только как его победить... Для хранимок рекомендуют использовать локальные переменные. Для самописных sp_executesql рекомендуют OPTION(RECOMPILE). Но для этого надо иметь доступ к "поправить запрос", формируемый сервером 1С, чего не получается...
(59) За выкладывание могут "пожурить" некоторые службы. Но чем смогу, тем поделюсь. Взял за основу запрос 1С, убрал sp_executesql, сформировал "Отбор" как ещё одну времянку, получил примерно в 150-200 раз меньшие затраты по CPU, reads dполовину меньше, время - чуть меньше секунды. против 171(1С .Остатки) и 5-7 секунд 1С перебор физики.
   VitShvets
 
62 - 29.05.18 - 20:00
Есть ещё одна забавная идея, набрел на нее у Германа Кудякова http://main.1c-ei.ru/Articles/TypeQurey/
Но у меня не пока получилось влезть в чужую временную таблицу. Но правда не сильно искал, завтра продолжу.
   ERWINS
 
63 - 29.05.18 - 20:15
(61) все равно спасибо, за что удастся
(61) реальную временную таблицу или материализованную?
(61) идея править запросы 1с? как там после этого с проблемами грязного чтения?
   МихаилМ
 
64 - 29.05.18 - 20:27
(62) в чужую вт можно было влезть на ms sql 2000

в 2005 фичу закрыли
   МихаилМ
 
65 - 29.05.18 - 20:42
(0) у меня ощущение, что поигрались с флагами трассировки
не должно так работать.
   МихаилМ
 
66 - 29.05.18 - 20:50
(0) про отимизирующие флаги трассировки и секционирование
http://www.queryprocessor.ru/enable_query_optimizer_hotfixes/
какая у вас версия скл и уровень совместимости ?
   VitShvets
 
67 - 30.05.18 - 19:24
(63) реальную временную. Но Михаил в (64) прав, такой финт ушами не пройдёт на сиквелах 2005 и старше. По крайней мере я не нашел как это сделать, а "старшие товарищи", они-же чистые сиквельщики (и DBA и прогеры), крутят пальцем у виска.
(63) Править именно запросы 1С не получится. Была идея "подменить" часть алгоритма, как описано у Германа, ссылка в (62). Выполняем часть запроса, подменяем одну из временных таблиц своим содержимым, идём дальше по алгоритму. С грязным чтением всё также как и у 1С. В обработках-отчётах везде поголовно (nolock). Теоретически можно на снапшот поменять, но об этом думать буду если всётаки 100% решу переходить на прямые запросы.
(65), (66) Не игрались флагами, но сегодня попробую:
1. Как рекомендует 1С в https://its.1c.ru/db/metod8dev#content:5904:hdoc включить флаг трассировки 4199.
2. Включу режим совместимости 110, была 100.

Связался на инфостарте с Германом, он ответил. Не ожидал если честно :) Он посоветовал сменить версию SQL. Завтра займусь, на тестовой среде попробую поднять 2016 SQL и поиграться с текущей и последней платформой 1С. Посмотрю что там получится.
Про сервер я писал в (17), у меня SQL Server 2012 SP4.

Попробовал, кстати рецепт по лечению parameter sniffing - OPTION(RECOMPILE). Руками, в менеджмент студии, подсовывая свою времянку. План запроса не поменялся, но быстрее отработал блок Inner Join - стоимость оператора снизилась на 30%. В целом по запросу, ридсы остались те-же, но CPU и время выполнения снизились на 30%. Но это так, больше академическая история, цель выйти на одну секцию.
   МихаилМ
 
68 - 30.05.18 - 23:08
кстати можно попробовать заменить таблицу представлением
и в представлении указать план запроса.
   VitShvets
 
69 - 31.05.18 - 13:50
Включение флаги трассировки и совместимость не сильно, но  помогли. Результат сопоставим с OPTION(RECOMPILE) (67), но задачу секций не решили. Буду тест разворачивать, но это вопрос не одного дня.
(68) Оригинально... Попробую как-нибудь.
   los_hooliganos
 
70 - 01.06.18 - 11:17
(69) В SQL есть условие на секцию в которую пойдет запрос. Если надо брать только 1 секцию, значит на нее и надо ставить условие.
Но судя по (0) проблема в незнании оптимизатора запроса о переменной которую получит итоговый запрос, поэтому план запроса и строится по всем секциям.
Я бы изменил хранимку, которая ставила в запрос секцию или условие на период константой (прямо прописанной в запросе).
   H A D G E H O G s
 
71 - 01.06.18 - 11:40
Ткните меня в "где почитать про секции"
   Мандалай
 
72 - 01.06.18 - 11:57
msdn.com
   Salimbek
 
73 - 01.06.18 - 12:00
РегистрНакопления.МойРегистр.Остатки(, [Отбор по одному полю в 50 тысяч строк])
---
А если попробовать слегка наоборот
---
(Выбрать * ИЗ РегистрНакопления.МойРегистр.Остатки(,))
Соединение
[Отбор по одному полю в 50 тысяч строк]
---
Смысл такой, что первым запросом поднимается только одна секция, а далее соединением на нее накладываем поиск...
   VitShvets
 
74 - 01.06.18 - 13:11
(70) >> Я бы изменил хранимку, которая ставила в запрос секцию.
Я в 1С пишу
Выбрать
[Поля]
ИЗ РегистрНакопления.МойРегистр.Остатки(, [Отбор по одному полю в 50 тысяч строк])

Что где поправить, о какой хранимке речь? [Отбор по одному полю в 50 тысяч строк] это условие вида:
Измерение В (Выбрать ВТ.Ссылка ИЗ ВТ)

(70) Я пробовал в запрос константы простых типов запихивать - дату, строку. 1С упорно добавляет это в параметры.
   VitShvets
 
75 - 01.06.18 - 13:15
   VitShvets
 
76 - 01.06.18 - 13:22
(73) Не получается. Была мысль, проверял, добавить во времянку-отбор константой дату и соединять по Ссылке и дате. Проблема в том, что запрос, порождаемый 1С выглядит так:
select
   [поля]
from ( 
       select
           [измерения]
           SUM([ресурсы])
       from [таблица итогов]
       where _Period = @1 AND [Остальные условия виртуальной таблицы]
       group by [измерения]
       having by SUM([ресурсы]) <> 0
    )
   тарам пам пам
 
77 - 01.06.18 - 13:23
(0) А если запихать пустую дату в текст 1с запроса в виде ДАТАВРЕМЯ(0,0,0,0,0,0)?
   VitShvets
 
78 - 01.06.18 - 13:24
+ к (76). Так вот условия любого join накладываются на внешний запрос. Внутренний как поднимал 14 секций, так и поднимает...
   VitShvets
 
79 - 01.06.18 - 13:30
(77) Пустая дата в 1С, это таки ДАТАВРЕМЯ(1, 1, 1). Но в запрос это также приходит параметром:
exec sp_executesql N'SELECT
... @10
...@P4 datetime2(3)... '2001-01-01 00:00:00'
   los_hooliganos
 
80 - 01.06.18 - 13:42
(79) Попробуй таблицу подменить вьюшкой.
А в запросе вьюшки сделай условие, что берется только секция текущего года.

https://docs.microsoft.com/ru-ru/sql/t-sql/functions/partition-transact-sql?view=sql-server-2017

В. Получение всех строк из одной секции секционированной таблицы или индекса
Следующий пример иллюстрирует получение всех строк, которые содержит секция 5 таблицы TransactionHistory
SELECT * FROM Production.TransactionHistory  
WHERE $PARTITION.TransactionRangePF1(TransactionDate) = 5 ;


Yj ns ukfdyjt gjcnfdm 'nj yf dm.ire
   los_hooliganos
 
81 - 01.06.18 - 13:43
(80) Поставь условие секции на вьюшку.
Раз вьюшка будет брать только актуальную секцию, то и проблем со сканированием всех секций не будет
   VitShvets
 
82 - 01.06.18 - 15:30
(80), (81) Предлагаешь сделать материализованную вьюху? А как 1С отнесется с записи в это безобразие? Ну и остаются всё-таки куча запросов, где период указывается и период приходит не 5999-11-01, а скажем 4018-05-01...
   los_hooliganos
 
83 - 01.06.18 - 15:48
(82) тут по разному можно извратится.
можно измерение Секция с вьюхой сделать.
можно сделать копию РН, а потом в скуле реал таблицу подменить вьюхой секции.
Если надо, сделать столько копий РН сколько нужно
   los_hooliganos
 
84 - 01.06.18 - 15:48
(83) +столько копий, сколько секций
   VitShvets
 
85 - 01.06.18 - 15:58
(83) Тогда уж проще на прямые запросы перейти. По крайней мере в отчетах-обработках, где не нужна блокировка. Пока покручу идею в голове, хочу таки протестировать что покажет sql 2016 + последний релиз 1С.
(84) Регистр 100 гигов весит. Две таблицы с индексами и прочим. :)
   kauksi
 
86 - 01.06.18 - 16:13
Версия 8.3.10 у вас не самая удачная. Хотя может дело и не в ней
   VitShvets
 
87 - 01.06.18 - 20:31
(86) Скорее всего дело вообще не в 1С. Я немного надеюсь на переработанный оптимизатор 2016-го сиквела и его хот-фиксы. Замена релиза 1С я думаю вообще ничего не поменяет. Если только режим совместимости не перевести в "Не использовать" и реструктуризировать всю базу. Но, боюсь я себе не смогу такого позволить, хотя скорее всего попробую на тестовой площадке.
   los_hooliganos
 
88 - 05.06.18 - 11:07
(87) Может достаточно будет выделить таблицы регистра в отдельный файл и хранить на отдельном диске для повышения производительности? :)
   VitShvets
 
89 - 19.06.18 - 21:08
(88) По оборудованию и разнесению файлов всё хорошо...
Оставлю тут, вдруг будет кому интересно-полезно.

Попробовал я на тестовой площадке и разные релизы 1С и сиквел 2016 с разными настройками совместимости и параметрами запуска сиквела. Не помогает, упорно оптимизатор поднимает все секции. Мой вывод - только прямые запросы. Пока правда не решил через что - АДО понятно, думал попробовать внешние источники данных, может там есть какие-то "полезные плюшки", но руки пока не дошли.

Пересчитал я итоги. По очереди, по кусочкам... Не ожидал я конечно ТАКОГО результата. Оказывается 1С ооочень сильно любит оставлять пустые и "несхлопутые" записи, особенно если включено "разделение итогов". Пересчет итогов снизил количество записей в таблице итогов более чем в 2 раза. Плюс повесил индексов несколько мимо 1С. Плюс переписал немного запросы под эти индексы. Как результат, скорость выполнения ряда тяжелых операций снизилась на 30-40%.

Буду ещё бизнес-логику менять, хочу уйти от некоторых тяжелых операций. Плюс прямые запросы. Но это пробовать-экспериментировать. На "послеотпускную пору", на осень.
   Fragster
 
90 - 19.06.18 - 23:41
Сделать свои итоги, с блекджеком и регистрами сведений уже предлагали? А этот регистр превратить в оборотный... Кстати,   кто-нибудь тестировал агрегаты на настоящих задачах? или это технологическое упражнение без реального применения?
   mistеr
 
91 - 20.06.18 - 00:04
(89) >Мой вывод - только прямые запросы.

Поддерживаю.

>Пока правда не решил через что - АДО понятно, думал попробовать внешние источники данных

Отдельная база (не 1С) и внешний источник.
>Оказывается 1С ооочень сильно любит оставлять пустые и "несхлопутые" записи, особенно если включено "разделение итогов"

Кто бы мог подумать! Разве только тот, кто документацию/ИТС писал...
   Genayo
 
92 - 20.06.18 - 05:54
(90) Агрегаты работают, после перехода с итогов на агрегаты размер базы значительно уменьшился, быстродействие точно не хуже.
   hhhh
 
93 - 20.06.18 - 09:39
(90) ну у него 8.2.16. Поэтому применить все эти новшества от платформы 8.3 у него не получится. Правильно он копает в сторону SQL
   Антон Долгов
 
94 - 20.06.18 - 10:26
(0) Когда ты пишешь свой запрос в SSMS, ты не используешь параметры, т.е. пишешь динамический SQL и для этого запроса формируется каждый раз новый план. 1С для запросов с условиями вызывает sp_executesql, для этих запросов если есть план в кэше, используется он.
   Антон Долгов
 
95 - 20.06.18 - 10:39
(0) Но вообще, автор, ты занимаешься херней, а то что тебе предлагают тут (свои итоги, вьюхи, триггеры) - еще большая херня. Таких людей Рупасов расстреливал у стенки.
   VitShvets
 
96 - 20.06.18 - 16:05
(90) Я правильно идею понимаю? Делаем регистр оборотным, вешаем агрегаты, добавляем регламентное заполнение регистра сведений как "итогов". В целевом запросе по остаткам собираем "итоги" + обороты за нужный период. Есть где почитать? Но, имхо, проще тогда уж прямые запросы. Не нужно новые сущности плодить, а запрос по сути тот-же самый - "ближние итоги плюс обороты". А в SQL и индекс можно подобрать и вообще...
(91) >> Кто бы мог подумать!
Вот не надо тут. Я не сомневался, что пересчет итогов поможет, но ожидал сокращения записей не более чем на несколько десятков процентов. То, что количество записей сократились в разы, и приятное и не приятное открытие. Приятное, что помогло быстро решить локальную задачу. Неприятное, что этим надо следить и следить пристально.  Через месяц буду анализировать скорость деградации, видимо писать job'ы/регламенты.
(92), (93) Я что-то пропустил? Агрегаты вроде как можно только для оборотного регистра создать? Я использовал, оборотный регистр "Продажи". Отчёты, если в агрегат попадёшь, строятся очень быстро.
   Fragster
 
97 - 20.06.18 - 16:09
кстати, может быть проще выключить итоги по периодам и оставить только текущие итоги?
   VitShvets
 
98 - 20.06.18 - 16:22
(94) Татычё?! Есть такая штука в составе средств управления сиквелом, профайлер называется. Он позволяет, в том числе "ловить" запросы генерируемые непосредственно 1С, вместе с актуальными их планами. Естественно запрос можно взять и нежно "покрутить" уже в SSMS, посмотреть как меняется его план.
(95) А поведай ка мне Антон Долгов, какие-нибудь есть идеи на тему 2-х терабайтной базы на предмет "обрезать", "ускорить" и всего-вот-этого-вот? При условии что монопольного доступа к базе есть 1-2 часа в сутки и сильно не каждый день. Или только овна на вентилятор вбросить не слабо? Не знаю с какого перепуга какой-то там Рупасов кого-то там расстреливал, это всяко не говорит о его выдающихся умственных способностях, во всяком случае в твоём изложении.
   Genayo
 
99 - 20.06.18 - 16:42
(96) Таки да, для оборотных агрегаты. Мы об этом и говорим :)
   Genayo
 
100 - 20.06.18 - 16:45
(97) Тогда надо делать 2 базы - одну оперативную, только с текущими итогами, а другую отчетную - наоборот без текущих итогов. Ибо если в базе только с текущими итогами задать период хотябы год - помрет нафик с такими объемами, как у ТС...
  1  2   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует