Страница 1 из 2 12 ПоследняяПоследняя
Показано с 1 по 10 из 16

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

  1. #1
    Новичок
    Регистрация
    17.02.2017
    Адрес
    Врн
    Сообщений
    29
    Поблагодарил(а)
    0
    Благодарностей: 21 (сообщений: 4)

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

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

  2. #2
    Новичок
    Регистрация
    17.02.2017
    Адрес
    Врн
    Сообщений
    29
    Поблагодарил(а)
    0
    Благодарностей: 21 (сообщений: 4)
    Коллеги со свежей версией, может, покажете всё-таки свой запрос?
    Достаточно нажать на "кубе для отчетов по расходу блюд" правой кнопкой и выбрать "Действия -> Просмотреть SQL запрос". Было бы очень полезно.

  3. #3
    Banned
    Регистрация
    03.01.2014
    Адрес
    Россия
    Сообщений
    958
    Поблагодарил(а)
    4
    Благодарностей: 9 (сообщений: 6)
    Цитата Сообщение от bromi Посмотреть сообщение
    Коллеги со свежей версией, может, покажете всё-таки свой запрос?
    Достаточно нажать на "кубе для отчетов по расходу блюд" правой кнопкой и выбрать "Действия -> Просмотреть 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))

  4. #4
    Новичок
    Регистрация
    17.02.2017
    Адрес
    Врн
    Сообщений
    29
    Поблагодарил(а)
    0
    Благодарностей: 21 (сообщений: 4)
    С практической точки зрения победил проблемный куб, расскажу тут тем, кого возможно затрагивает.

    После долго осмотра плана выполнения запроса мной было выбрано построение одного конкретного некластеризованного (дополнительного) индекса, на таблице 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. Те, кто базу создавал сразу в новой версии или апгрейдился через инсталлятор -- возможно, у вас уже есть все нужные индексы. Но проверить исполнение запроса на сервере не помешает.
    Последний раз редактировалось bromi; 10.03.2017 в 14:19.

  5. 4 пользователей сказали cпасибо bromi за это полезное сообщение:

    SH (29.09.2017),sibgaba (29.09.2017),SLion (29.09.2017),yuferevm (29.09.2017)

  6. #5
    Разбирающийся
    Регистрация
    18.10.2012
    Адрес
    Новосибирск, Омск
    Сообщений
    5,362
    Поблагодарил(а)
    188
    Благодарностей: 461 (сообщений: 364)
    Снимаю шляпу.
    Но такая оптимизация SQL это сильное кунг-фу... Вот я, например, даже с такой подробной инструкцией практически ничего не понял (кроме общей идеи).
    Респект и уважуха.
    PS Если "Врн" из подписи это Воронеж - не откажите в любезности, у вас там где то рядом должен находиться Центр Разработки Компании UCS. Как снег сойдет - напишите им это все краской на асфальте под окнами. Может кто задумается...
    Ильин Александр, Компания "Соттос"
    г Новосибирск +7 (383) 373-96-98; +7 (909) 533-93-92; nsk@sottos.ru
    г Омск +7 (3812) 377-902; +7 (905) 098-92-06; abc@sottos.ru
    www.sottos.ru | vk.com/sottos | fb.com/sottosru
    Продажа и установка ПО R-Keeper, обучение, техническая поддержка 24/7

  7. #6
    Разбирающийся
    Регистрация
    14.08.2008
    Сообщений
    299
    Поблагодарил(а)
    64
    Благодарностей: 36 (сообщений: 32)
    Да почитав все это, понял Вам с большой буквы работать в отличной компании, а не подбирать хвосты UCS. Удачи во всем!!!!

  8. #7
    Banned
    Регистрация
    03.01.2014
    Адрес
    Россия
    Сообщений
    958
    Поблагодарил(а)
    4
    Благодарностей: 9 (сообщений: 6)
    Цитата Сообщение от Leon44 Посмотреть сообщение
    Да почитав все это, понял Вам с большой буквы работать в отличной компании, а не подбирать хвосты UCS. Удачи во всем!!!!
    Ну если у вас выйдет, вы поделитесь корректным скриптом ? )

  9. #8
    Новичок
    Регистрация
    17.02.2017
    Адрес
    Врн
    Сообщений
    29
    Поблагодарил(а)
    0
    Благодарностей: 21 (сообщений: 4)
    Цитата Сообщение от sibgaba Посмотреть сообщение
    Снимаю шляпу.
    Но такая оптимизация SQL это сильное кунг-фу... Вот я, например, даже с такой подробной инструкцией практически ничего не понял (кроме общей идеи).
    Респект и уважуха.
    Спасибо, но, к сожалению, я вообще очень базово разбираюсь в sql, пришлось повчитываться недельку. Думаю, любой профессионал может посмотреть и очень быстро привести в порядок имеющиеся запросы на конкретной базе, для меня пока главный вопрос в том, сделана ли оптимизация в скриптах создания базы более свежих версий, вполне вероятно, что у UCS вполне уже дошли руки.
    Что касается общей идеи -- могу отдельно ответить на какие-то вопросы в личке, ну или в треде, сложно предсказать, с какими вещами комфортно работать, с какими незнакомо конкретно вам -- поэтому такое описание возможно неудачно.

  10. #9
    ТВОРЕЦ СЧАСТЬЯ Аватар для SH
    Регистрация
    29.11.2006
    Сообщений
    18,069
    Поблагодарил(а)
    481
    Благодарностей: 192 (сообщений: 165)
    Я думаю, сильно поможет, если подробнее расскажете, какими инструментами пользовались и вообще примерный алгоритм выявления проблем.
    Алексей Аркадьев

    Когда заказчик ищет волшебника, то чаще всего он находит сказочника.
    Если у Вас есть вопрос по поддержке - напишите его на форуме, я обязательно отвечу, если знаю ответ.
    Если Вам нужны какие-то файлы, пишите на почту: support@carbis.ru, но вначале посмотрите в разделе для скачивания.
    Для коммерческих вопросов:
    +7 (495) 740-49-91, или на почту: sales@carbis.ru

  11. #10
    Новичок
    Регистрация
    12.01.2015
    Адрес
    сочи
    Сообщений
    1
    Поблагодарил(а)
    1
    Благодарностей: 0 (сообщений: 0)
    Ты гениален, спасибо!
    Куб стал считаться за 50 сек. вместо 25 минут

Похожие темы

  1. Сгорание бонусов , SQL Запрос
    от Hendehog в разделе GameKeeper
    Ответов: 10
    Последнее сообщение: 09.02.2016, 01:55
  2. SH4 - при попытке открыть документ по расходу блюд ошибка 503
    от SH в разделе SH: Технические вопросы
    Ответов: 4
    Последнее сообщение: 12.05.2013, 11:17
  3. Как составить запрос SQL для SH3
    от SH в разделе Старые версии: Storehouse 2 и 3
    Ответов: 1
    Последнее сообщение: 01.02.2011, 22:21
  4. Разница сумм в выручке по дням и расходу блюд.
    от sars в разделе RK: Базы данных, ошибки, проблемы
    Ответов: 3
    Последнее сообщение: 22.03.2010, 12:18

Метки этой темы

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •