PDA

Просмотр полной версии : SQL-запрос куба для отчётов по расходу блюд



bromi
22.02.2017, 17:19
Добрый день.
Преамбула:
1) имели версию 7.5.2 самую последнюю очень долго, дилер провёл обновление на 7.5.7.55 через промежуточное 7.5.4.239, без инсталлятора, копирование поверх и запуском рефсервера.
2) Попутно произвели переезд с 2008R2SP3 на 2016SP1 SQL методом восстановления базы из бэкапа и замены коннект строки в менеджере при usesql=0.

Обнаружили, что кубы по расходу блюд считаются безумно долго и вылетают за все разумные пределы. Более плотное расследование показало, что куб и до апгрейда ходил по грани, высчитываясь 3 часа ночами, после апгрейда стал 4 часа. База немаленькая, около 6гб, за 2 года, но это не повод, подумали мы, размер итоговой плоской таблицы из которой собирается Куб, всего 2 мильона строк. Не на 4 часа проблема. На практике время занимает именно выгрузка данных через вьюшку из SQL: (сейчас стоит куб лимитированный по времени, поэтому занимает "всего" 2 часа.
22.02 01:00:02 Cube "Куб для отчетов по расходу блюд" timeout set
22.02 01:00:02 Cube "Куб для отчетов по расходу блюд" struct loaded
22.02 01:00:02 Cube "Куб для отчетов по расходу блюд" -> Load from ADO
22.02 03:04:30 Cube "Куб для отчетов по расходу блюд" <- Load from ADO
22.02 03:04:30 Cube "Куб для отчетов по расходу блюд" cube loaded
22.02 03:04:30 Cube "Куб для отчетов по расходу блюд" building started
22.02 03:05:43 Cube "Куб для отчетов по расходу блюд" cube saved
22.02 03:05:43 Cube "Куб для отчетов по расходу блюд" processed.Ok
22.02 03:05:43 Cube processor stopped, TotalSize=13769368

Я не эксперт по оптимизации SQL, но с профильными коллегами начал копать, обнаружил, что запрос выполняется на сервере весьма неэффективно, джойны происходят странно и вообще. Более простую версию запроса (не по всем таблицам) хинтами по джойнам удалось оптимизировать на пару порядков, то есть реально сократить с 20 минут до 10 секунд (sic!).

Теперь амбула: прежде чем браться за переписывание полного огромного запроса этого куба (кстати, там внутри есть джойн по вьюшке, дублирующей половину используемых столбцов уже внутри, и естественно не имеющей индекса -- LEFT JOIN SaleObjects SaleObjects00) -- коллеги, подскажите, как выглядит у вас запрос этого куба? Может быть, в свежих версиях запрос давно оптимизирован, но очевидно что при таком апгрейде он не изменится?

(По совету дилера я пробовал запустить Refsrv с Upgradeanytime=1, в надежде на перестройку вьюшки, полный лог попыток можно увидеть на http://pastebin.com/YSwsg0Fp, кроме дампов стэка необычного я там нашёл только
>> 158:Too big time from switch 29000. task dump printed (такие стали появляться в логе после апгрейда на 7.5.5 в целом)
>> 381:Item with id 201 already exists: ignored in TFieldedSortCollection for TRK7ColorSchemeDetail
>> 5004:Exception "Exception Exception with message "Недопустимое имя объекта "vrk7CubeView1002""" (code: -1) during cube loading

1002 -- это как раз куб по расходу блюд, не знаю, пытался ли он его пересоздать но зафейлил, или в чём история.

Так или иначе, мой текущий SQL-запрос этого куба выглядит так (в менеджерской части, на практике он дёргает вьюшку в скле):

SELECT
EMPLOYEES00."NAME" AS "WAITER",
SaleObjects00."CODE" AS "CODE",
SaleObjects00."NAME" AS "DISH",
PayBindings."QUANTITY" AS "QUANTITY",
PayBindings."PAYSUM" AS "PAYSUM",
PayBindings."PRICESUM" AS "PRLISTSUM",
CLASSIFICATORGROUPS0000.NAME AS "CATEGORY",
DishDiscounts00."EXCLUDEFROMEARNINGS" AS "EXCLUDEFROMEARNINGS",
UNCHANGEABLEORDERTYPES00."NAME" AS "ORDERCATEGORY",
PrintChecks00."CHECKNUM" AS "CHECKNUM",
GLOBALSHIFTS00."SHIFTNUM" AS "SHIFTNUM",
OrderSessions00."PRINTAT" AS "PRINTAT___13",
GLOBALSHIFTS00."SHIFTDATE" AS "SHIFTDATE",
dbo.propCategPath(MENUITEMS00.SIFR) AS "CATEGPATH",
CASHES00."NAME" AS "CLOSESTATION",
CASHGROUPS00."NETNAME" AS "NETNAME",
CURRENCYTYPES00."NAME" AS "CURRENCYTYPE",
CURRENCIES00."NAME" AS "CURRENCY",
CURRENCIES00."CODE" AS "CURRENCYCODE",
CLASSIFICATORGROUPS0000.SORTORDER AS "SORTORDER",
Shifts00."PRINTSHIFTNUM" AS "CASHSHIFTNUM",
TABLES00."NAME" AS "TABLE",
Orders00."ORDERNAME" AS "ORDERNAME",
PaymentsExtra00."CARDNUM" AS "CARDNUM",
trk7EnumsValues1E00.UserMName AS "OBJKIND",
PayBindings."TAXESADDED" AS "TAXESADDED",
RESTAURANTS00."NAME" AS "RESTAURANTNAME",
EMPLOYEES01."NAME" AS "DISHCREATOR",
CurrLines00."DBKURS" AS "DBKURS",
MENUITEMS01."NAME" AS "COMBODISH",
PrintChecks00."CLOSEDATETIME" AS "CLOSEDATETIME___37",
trk7EnumsValues3600.UserMName AS "STATUS",
CATEGLIST00."NAME" AS "NAME1",
CATEGLIST00."CODE" AS "CODE1",
CLASSIFICATORGROUPS0000.NAME AS "F00000040"
FROM PAYBINDINGS
JOIN CurrLines CurrLines00
ON (CurrLines00.Visit = PayBindings.Visit) AND (CurrLines00.MidServer = PayBindings.MidServer) AND (CurrLines00.UNI = PayBindings.CurrUNI)
JOIN PrintChecks PrintChecks00
ON (PrintChecks00.Visit = CurrLines00.Visit) AND (PrintChecks00.MidServer = CurrLines00.MidServer) AND (PrintChecks00.UNI = CurrLines00.CheckUNI)
JOIN Orders Orders00
ON (Orders00.Visit = PayBindings.Visit) AND (Orders00.MidServer = PayBindings.MidServer) AND (Orders00.IdentInVisit = PayBindings.OrderIdent)
LEFT JOIN EMPLOYEES EMPLOYEES00
ON (EMPLOYEES00.SIFR = Orders00.MainWaiter)
LEFT JOIN SaleObjects SaleObjects00
ON (SaleObjects00.Visit = PayBindings.Visit) AND (SaleObjects00.MidServer = PayBindings.MidServer) AND (SaleObjects00.DishUNI = PayBindings.DishUNI) AND (SaleObjects00.ChargeUNI = PayBindings.ChargeUNI)
LEFT JOIN SessionDishes SessionDishes00
ON (SessionDishes00.Visit = SaleObjects00.Visit) AND (SessionDishes00.MidServer = SaleObjects00.MidServer) AND (SessionDishes00.UNI = SaleObjects00.DishUNI)
LEFT JOIN MENUITEMS MENUITEMS00
ON (MENUITEMS00.SIFR = SessionDishes00.Sifr)
LEFT JOIN DISHGROUPS DISHGROUPS0000
ON (DISHGROUPS0000.CHILD = MENUITEMS00.SIFR) AND (DISHGROUPS0000.CLASSIFICATION = 512)
LEFT JOIN CLASSIFICATORGROUPS CLASSIFICATORGROUPS0000
ON CLASSIFICATORGROUPS0000.SIFR * 256 + CLASSIFICATORGROUPS0000.NumInGroup = DISHGROUPS0000.PARENT
LEFT JOIN DishDiscounts DishDiscounts00
ON (DishDiscounts00.Visit = SaleObjects00.Visit) AND (DishDiscounts00.MidServer = SaleObjects00.MidServer) AND (DishDiscounts00.UNI = SaleObjects00.ChargeUNI)
LEFT JOIN UNCHANGEABLEORDERTYPES UNCHANGEABLEORDERTYPES00
ON (UNCHANGEABLEORDERTYPES00.SIFR = Orders00.UOT)
JOIN GLOBALSHIFTS GLOBALSHIFTS00
ON (GLOBALSHIFTS00.MidServer = Orders00.MidServer) AND (GLOBALSHIFTS00.ShiftNum = Orders00.iCommonShift)
LEFT JOIN OrderSessions OrderSessions00
ON (OrderSessions00.Visit = SaleObjects00.Visit) AND (OrderSessions00.MidServer = SaleObjects00.MidServer) AND (OrderSessions00.UNI = SaleObjects00.SessionUNI)
LEFT JOIN CASHES CASHES00
ON (CASHES00.SIFR = PrintChecks00.iCloseStation)
LEFT JOIN CASHGROUPS CASHGROUPS00
ON (CASHGROUPS00.SIFR = PayBindings.Midserver)
LEFT JOIN CURRENCYTYPES CURRENCYTYPES00
ON (CURRENCYTYPES00.SIFR = CurrLines00.iHighLevelType)
LEFT JOIN CURRENCIES CURRENCIES00
ON (CURRENCIES00.SIFR = CurrLines00.Sifr)
LEFT JOIN Shifts Shifts00
ON (Shifts00.MidServer = PrintChecks00.MidServer) AND (Shifts00.iStation = PrintChecks00.iCloseStation) AND (Shifts00.ShiftNum = PrintChecks00.iShift)
LEFT JOIN TABLES TABLES00
ON (TABLES00.SIFR = Orders00.TableID)
LEFT JOIN PaymentsExtra PaymentsExtra00
ON (PaymentsExtra00.Visit = CurrLines00.Visit) AND (PaymentsExtra00.MidServer = CurrLines00.MidServer) AND (PaymentsExtra00.PayUNI = CurrLines00.PayUNIForOwnerInfo)
LEFT JOIN trk7EnumsValues trk7EnumsValues1E00
ON (trk7EnumsValues1E00.EnumData = SaleObjects00.OBJKIND) AND (trk7EnumsValues1E00.EnumName = 'tSaleObjectKind')
LEFT JOIN RESTAURANTS RESTAURANTS00
ON (RESTAURANTS00.SIFR = CASHGROUPS00.Restaurant)
LEFT JOIN EMPLOYEES EMPLOYEES01
ON (EMPLOYEES01.SIFR = SaleObjects00.iAuthor)
LEFT JOIN SessionDishes SessionDishes01
ON (SessionDishes01.Visit = SessionDishes00.Visit) AND (SessionDishes01.Midserver = SessionDishes00.Midserver) AND (SessionDishes01.UNI = SessionDishes00.ComboDishUNI)
LEFT JOIN MENUITEMS MENUITEMS01
ON (MENUITEMS01.SIFR = SessionDishes01.Sifr)
LEFT JOIN trk7EnumsValues trk7EnumsValues3600
ON (trk7EnumsValues3600.EnumData = GLOBALSHIFTS00.STATUS) AND (trk7EnumsValues3600.EnumName = 'TRecordStatus')
LEFT JOIN CATEGLIST CATEGLIST00
ON (CATEGLIST00.SIFR = MENUITEMS00.PARENT)
WHERE
((PrintChecks00."STATE" = 6))
AND (GLOBALSHIFTS00."SHIFTDATE" BETWEEN CONVERT(DATETIME, '2016.01.01', 102) AND CONVERT(DATETIME, '2100.01.01', 102))
AND ((GLOBALSHIFTS00.STATUS = 3))

Поможете?

bromi
28.02.2017, 20:42
Коллеги со свежей версией, может, покажете всё-таки свой запрос?
Достаточно нажать на "кубе для отчетов по расходу блюд" правой кнопкой и выбрать "Действия -> Просмотреть SQL запрос". Было бы очень полезно.

Hendehog
01.03.2017, 05:57
Коллеги со свежей версией, может, покажете всё-таки свой запрос?
Достаточно нажать на "кубе для отчетов по расходу блюд" правой кнопкой и выбрать "Действия -> Просмотреть SQL запрос". Было бы очень полезно.



SELECT EMPLOYEES00."NAME" AS "WAITER", SaleObjects00."CODE" AS "CODE", SaleObjects00."NAME" AS "DISH", PayBindings."QUANTITY" AS "QUANTITY", PayBindings."PAYSUM" AS "PAYSUM", PayBindings."PRICESUM" AS "PRLISTSUM", CLASSIFICATORGROUPS0000.NAME AS "CATEGORY", DishDiscounts00."EXCLUDEFROMEARNINGS" AS "EXCLUDEFROMEARNINGS", UNCHANGEABLEORDERTYPES00."NAME" AS "ORDERCATEGORY", PrintChecks00."CHECKNUM" AS "CHECKNUM", GLOBALSHIFTS00."SHIFTNUM" AS "SHIFTNUM", OrderSessions00."PRINTAT" AS "PRINTAT___13", GLOBALSHIFTS00."SHIFTDATE" AS "SHIFTDATE", dbo.propCategPath(MENUITEMS00.SIFR) AS "CATEGPATH", CASHES00."NAME" AS "CLOSESTATION", CASHGROUPS00."NETNAME" AS "NETNAME", CURRENCYTYPES00."NAME" AS "CURRENCYTYPE", CURRENCIES00."NAME" AS "CURRENCY", CURRENCIES00."CODE" AS "CURRENCYCODE", CLASSIFICATORGROUPS0000.SORTORDER AS "SORTORDER", Shifts00."PRINTSHIFTNUM" AS "CASHSHIFTNUM", TABLES00."NAME" AS "TABLE", Orders00."ORDERNAME" AS "ORDERNAME", PaymentsExtra00."CARDNUM" AS "CARDNUM", trk7EnumsValues1E00.UserMName AS "OBJKIND", PayBindings."TAXESADDED" AS "TAXESADDED", RESTAURANTS00."NAME" AS "RESTAURANTNAME", EMPLOYEES01."NAME" AS "DISHCREATOR", CurrLines00."DBKURS" AS "DBKURS", MENUITEMS01."NAME" AS "COMBODISH", PrintChecks00."CLOSEDATETIME" AS "CLOSEDATETIME___37", trk7EnumsValues3600.UserMName AS "STATUS", CATEGLIST00."NAME" AS "NAME1", CATEGLIST00."CODE" AS "CODE1"FROM PAYBINDINGSJOIN CurrLines CurrLines00 ON (CurrLines00.Visit = PayBindings.Visit) AND (CurrLines00.MidServer = PayBindings.MidServer) AND (CurrLines00.UNI = PayBindings.CurrUNI)JOIN PrintChecks PrintChecks00 ON (PrintChecks00.Visit = CurrLines00.Visit) AND (PrintChecks00.MidServer = CurrLines00.MidServer) AND (PrintChecks00.UNI = CurrLines00.CheckUNI)JOIN Orders Orders00 ON (Orders00.Visit = PayBindings.Visit) AND (Orders00.MidServer = PayBindings.MidServer) AND (Orders00.IdentInVisit = PayBindings.OrderIdent)LEFT JOIN EMPLOYEES EMPLOYEES00 ON (EMPLOYEES00.SIFR = Orders00.MainWaiter)LEFT JOIN SaleObjects SaleObjects00 ON (SaleObjects00.Visit = PayBindings.Visit) AND (SaleObjects00.MidServer = PayBindings.MidServer) AND (SaleObjects00.DishUNI = PayBindings.DishUNI) AND (SaleObjects00.ChargeUNI = PayBindings.ChargeUNI)LEFT JOIN SessionDishes SessionDishes00 ON (SessionDishes00.Visit = SaleObjects00.Visit) AND (SessionDishes00.MidServer = SaleObjects00.MidServer) AND (SessionDishes00.UNI = SaleObjects00.DishUNI)LEFT JOIN MENUITEMS MENUITEMS00 ON (MENUITEMS00.SIFR = SessionDishes00.Sifr)LEFT JOIN DISHGROUPS DISHGROUPS0000 ON (DISHGROUPS0000.CHILD = MENUITEMS00.SIFR) AND (DISHGROUPS0000.CLASSIFICATION = 0)LEFT JOIN CLASSIFICATORGROUPS CLASSIFICATORGROUPS0000 ON CLASSIFICATORGROUPS0000.SIFR * 256 + CLASSIFICATORGROUPS0000.NumInGroup = DISHGROUPS0000.PARENT LEFT JOIN DishDiscounts DishDiscounts00 ON (DishDiscounts00.Visit = SaleObjects00.Visit) AND (DishDiscounts00.MidServer = SaleObjects00.MidServer) AND (DishDiscounts00.UNI = SaleObjects00.ChargeUNI)LEFT JOIN UNCHANGEABLEORDERTYPES UNCHANGEABLEORDERTYPES00 ON (UNCHANGEABLEORDERTYPES00.SIFR = Orders00.UOT)JOIN GLOBALSHIFTS GLOBALSHIFTS00 ON (GLOBALSHIFTS00.MidServer = Orders00.MidServer) AND (GLOBALSHIFTS00.ShiftNum = Orders00.iCommonShift)LEFT JOIN OrderSessions OrderSessions00 ON (OrderSessions00.Visit = SaleObjects00.Visit) AND (OrderSessions00.MidServer = SaleObjects00.MidServer) AND (OrderSessions00.UNI = SaleObjects00.SessionUNI)LEFT JOIN CASHES CASHES00 ON (CASHES00.SIFR = PrintChecks00.iCloseStation)LEFT JOIN CASHGROUPS CASHGROUPS00 ON (CASHGROUPS00.SIFR = PayBindings.Midserver)LEFT JOIN CURRENCYTYPES CURRENCYTYPES00 ON (CURRENCYTYPES00.SIFR = CurrLines00.iHighLevelType)LEFT JOIN CURRENCIES CURRENCIES00 ON (CURRENCIES00.SIFR = CurrLines00.Sifr)LEFT JOIN Shifts Shifts00 ON (Shifts00.MidServer = PrintChecks00.MidServer) AND (Shifts00.iStation = PrintChecks00.iCloseStation) AND (Shifts00.ShiftNum = PrintChecks00.iShift)LEFT JOIN TABLES TABLES00 ON (TABLES00.SIFR = Orders00.TableID)LEFT JOIN PaymentsExtra PaymentsExtra00 ON (PaymentsExtra00.Visit = CurrLines00.Visit) AND (PaymentsExtra00.MidServer = CurrLines00.MidServer) AND (PaymentsExtra00.PayUNI = CurrLines00.PayUNIForOwnerInfo)LEFT JOIN trk7EnumsValues trk7EnumsValues1E00 ON (trk7EnumsValues1E00.EnumData = SaleObjects00.OBJKIND) AND (trk7EnumsValues1E00.EnumName = 'tSaleObjectKind')LEFT JOIN RESTAURANTS RESTAURANTS00 ON (RESTAURANTS00.SIFR = CASHGROUPS00.Restaurant)LEFT JOIN EMPLOYEES EMPLOYEES01 ON (EMPLOYEES01.SIFR = SaleObjects00.iAuthor)LEFT JOIN SessionDishes SessionDishes01 ON (SessionDishes01.Visit = SessionDishes00.Visit) AND (SessionDishes01.Midserver = SessionDishes00.Midserver) AND (SessionDishes01.UNI = SessionDishes00.ComboDishUNI)LEFT JOIN MENUITEMS MENUITEMS01 ON (MENUITEMS01.SIFR = SessionDishes01.Sifr)LEFT JOIN trk7EnumsValues trk7EnumsValues3600 ON (trk7EnumsValues3600.EnumData = GLOBALSHIFTS00.STATUS) AND (trk7EnumsValues3600.EnumName = 'TRecordStatus')LEFT JOIN CATEGLIST CATEGLIST00 ON (CATEGLIST00.SIFR = MENUITEMS00.PARENT)WHERE ((PrintChecks00."STATE" = 6)) AND ((GLOBALSHIFTS00.STATUS = 3))

bromi
10.03.2017, 14:03
С практической точки зрения победил проблемный куб, расскажу тут тем, кого возможно затрагивает.

После долго осмотра плана выполнения запроса мной было выбрано построение одного конкретного некластеризованного (дополнительного) индекса, на таблице Paybindings (поля Midserver, Visit, CurrUNI в таком порядке) для нормального джойна Paybingings с CurrLines. И я сразу оговорю -- возможно, у вас нет этой проблемы, т.к. сетап какой-нибудь новой версии (после 7.5.2) создаёт более корректную базу. Пока не было времени проверить, как выглядит структура в актуальной версии (хочу ночью пересоздать в чистую базу структуру и посравнивать). Подозреваю, что проблема возникает там, где есть несколько кассовых серверов (midserver) в одном "ресторане". Там вообще странная структура индексов имеющаяся с точки зрения гистограмм, первым полем везде идёт midserver, что вероятно крайне полезно для запросов, отсекающих данные именно под одному конкретному кассовому серверу с точки зрения доступа (через сервер отчетов), но там где отсев происходит через кубы (галочками), это нифига не улучшает работу оптимизатора запроса.

Так вот, опишу в чём именно была проблема. В плане запроса возникали хэш-джойны, умножающие строки. Например, когда хэш берёт таблицу слева на 100 тыщ и справа на 500 и перемножает их, т.к. хэш пробой (операцией объединения) выбирается почему-то один MidServer, которого в базе всего 4, например. То есть Результатом будет будет 100000*500/4 строк насколько я понимаю, что дофига. Наши пара миллионов реальных строк легко превращались в 96 миллионов после нескольких таких кривых джойнов, вот и 4 часа пересчёта куба подъехали. А самое главное -- зависимость квадратичная, то есть время рассчёта росло квадратно от времени реального.

Как проверить у себя: берём запрос из проблемной вьюшки (смотрим через монитор активности SQL, какая вьюшка дёргается при пересчете куба), ставим лимитами небольшой срок, чтоб просчитывалось в пределах минуты, и начинаем разглядывать план запроса (поставить в запросе галочку "показать актуальный план выполнения -- то что на деле произошло). Слишком маленький интервал брать тоже не стоит, т.к. тогда оптимизатор может составить иной план, даже возможно "нормальный".

Визуально проблема выглядит так
5682

(обратите внимание на строки estimated number of rows - 1 миллион и actual number of rows - 96 миллионов). И это при том, что селектом ограничена выборка с 1 января этого года -- в "правильном" плане запроса там и 1 миллиона "ожидаемых" не получилось бы, они бы отсеклись на уровне смен). Но нас не интересует оптимизация запроса смен, т.к. неограниченный куб не имеет лимита. Тем, кто делает кубы интервалами по годам, если после главной оптимизации ещё будет в этом нужда -- не переживайте, лимитированные по времени запросы тоже ускорятся.

Подводя итог, если у вас есть вот такие кривые джойны -- надо искать, какой индекс добавить к базе, чтобы оптимизатору не приходили дурные идеи. Мне помогло упомянутое в начале, запрос после этого не стал идеальным, есть ещё над чем работать, но принципиальную проблему устранило -- вместо 4 часов база 20 касс за 2.25 года стала считаться за 15 минут, а главное, линейно -- за год считается 9 минут, за четверть года - 2,5 минуты и т.д.
Такие дела.

P.S. Те, кто базу создавал сразу в новой версии или апгрейдился через инсталлятор -- возможно, у вас уже есть все нужные индексы. Но проверить исполнение запроса на сервере не помешает.

sibgaba
10.03.2017, 14:28
Снимаю шляпу.
Но такая оптимизация SQL это сильное кунг-фу... Вот я, например, даже с такой подробной инструкцией практически ничего не понял (кроме общей идеи).
Респект и уважуха.
PS Если "Врн" из подписи это Воронеж - не откажите в любезности, у вас там где то рядом должен находиться Центр Разработки Компании UCS. Как снег сойдет - напишите им это все краской на асфальте под окнами. Может кто задумается...

Leon44
10.03.2017, 14:41
Да почитав все это, понял Вам с большой буквы работать в отличной компании, а не подбирать хвосты UCS. Удачи во всем!!!!

Hendehog
10.03.2017, 14:58
Да почитав все это, понял Вам с большой буквы работать в отличной компании, а не подбирать хвосты UCS. Удачи во всем!!!!

Ну если у вас выйдет, вы поделитесь корректным скриптом ? )

bromi
10.03.2017, 15:03
Снимаю шляпу.
Но такая оптимизация SQL это сильное кунг-фу... Вот я, например, даже с такой подробной инструкцией практически ничего не понял (кроме общей идеи).
Респект и уважуха.
Спасибо, но, к сожалению, я вообще очень базово разбираюсь в sql, пришлось повчитываться недельку. Думаю, любой профессионал может посмотреть и очень быстро привести в порядок имеющиеся запросы на конкретной базе, для меня пока главный вопрос в том, сделана ли оптимизация в скриптах создания базы более свежих версий, вполне вероятно, что у UCS вполне уже дошли руки.
Что касается общей идеи -- могу отдельно ответить на какие-то вопросы в личке, ну или в треде, сложно предсказать, с какими вещами комфортно работать, с какими незнакомо конкретно вам -- поэтому такое описание возможно неудачно.

SH
10.03.2017, 15:13
Я думаю, сильно поможет, если подробнее расскажете, какими инструментами пользовались и вообще примерный алгоритм выявления проблем.

yuferevm
29.09.2017, 17:33
Ты гениален, спасибо!
Куб стал считаться за 50 сек. вместо 25 минут

mnekin
04.10.2017, 13:13
У меня не такой впечатляющий результат как у присутствующих здесь коллег, но пересчет кубов улучшен на 20% (данных в базе за 1 год, размер базы 11 гб.)

Куб по расходу блюд
Фильтр на 6 мес.
Пересчет 9 мин.
После создания индекса (таблица Paybindings) пересчет стал 7 минут.

Но здесь наверное сказывается, что я ставил реиндексацию базы раз в два дня (EXEC sp_updatestats; ) перед бекапом базы.

Убрал вообще фильтрацию у куба и куб пересчитался за 9 минут и это хорошо.
Громадное спасибо автору.

Сергей_Бишкек
04.10.2017, 13:25
Если вкратце, то у нас получился такой скрипт:

CREATE NONCLUSTERED INDEX PAYBINDINGS_MIDSERVER_VISIT_CURRUNI_IDX ON dbo.PAYBINDINGS
(
MIDSERVER,
VISIT,
CURRUNI
) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

а потом sp_updatestats в SQL агента и расписание создать.

Старцев Максим
01.10.2018, 12:39
Если вкратце, то у нас получился такой скрипт:

Здравствуйте, у нас присутствуют такие же проблеммы с пересчетом кубов, эсли можно поподробнее описать где и как запустить данный скрипт...

Старцев Максим
03.10.2018, 15:08
Запустили скрипт, поставили sp_updatestats в расписание, не помогло(((
Версия 7.6.0.81
После обновления куб по расходу блюд так и не смог пересчитатся (данные за 6 месяцев)
Есть еще какие-то варианты решения?:wall:

Сергей_Бишкек
18.10.2018, 11:53
Здравствуйте, у нас присутствуют такие же проблеммы с пересчетом кубов, эсли можно поподробнее описать где и как запустить данный скрипт...

непосредственно на базе RK7 (или как она у вас называется) в SQL

kaznarush
04.08.2019, 21:57
Если вкратце, то у нас получился такой скрипт:

CREATE NONCLUSTERED INDEX PAYBINDINGS_MIDSERVER_VISIT_CURRUNI_IDX ON dbo.PAYBINDINGS
(
MIDSERVER,
VISIT,
CURRUNI
) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

а потом sp_updatestats в SQL агента и расписание создать.

Доброго времени суток! Расскажите пожалуйста подробнее про sp_updatestats, как это сделать? заранее благодарю