SQL-запрос куба для отчётов по расходу блюд

[bromi]

Добрый день.
Преамбула:
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]

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

[Hendehog]

Коллеги со свежей версией, может, покажете всё-таки свой запрос?
Достаточно нажать на "кубе для отчетов по расходу блюд" правой кнопкой и выбрать "Действия -> Просмотреть 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]

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

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

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

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

Визуально проблема выглядит так
Ssms_2017-02-21_16-45-11.png

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

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

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

[sibgaba]

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

[Leon44]

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

[Hendehog]

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

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

[bromi]

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

Спасибо, но, к сожалению, я вообще очень базово разбираюсь в sql, пришлось повчитываться недельку. Думаю, любой профессионал может посмотреть и очень быстро привести в порядок имеющиеся запросы на конкретной базе, для меня пока главный вопрос в том, сделана ли оптимизация в скриптах создания базы более свежих версий, вполне вероятно, что у UCS вполне уже дошли руки.
Что касается общей идеи -- могу отдельно ответить на какие-то вопросы в личке, ну или в треде, сложно предсказать, с какими вещами комфортно работать, с какими незнакомо конкретно вам -- поэтому такое описание возможно неудачно.

[SH]

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

[yuferevm]

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