Производительность запросов Providex
Я выполняю запрос к базе данных Provider, которую мы используем в MAS 90. Запрос состоит из трех таблиц, объединенных вместе, и был медленным, но не невыносимым, занимая около 8 минут на запуск. Запрос имеет достаточное количество условий в предложении where:
Я собираюсь опустить часть запроса select, поскольку она длинная и простая, это просто список полей из трех таблиц, которые будут использоваться в результатах.
Но таблицы и предложения where в 8-минутной версии времени выполнения:
(Первый параметр - это нижняя граница выбранного пользователем диапазона дат, второй - верхняя граница.)
FROM "AR_InvoiceHistoryDetail" "AR_InvoiceHistoryDetail",
"AR_InvoiceHistoryHeader" "AR_InvoiceHistoryHeader", "IM1_InventoryMasterfile"
"IM1_InventoryMasterfile"
WHERE "AR_InvoiceHistoryDetail"."InvoiceNo" = "AR_InvoiceHistoryHeader"."InvoiceNo"
AND "AR_InvoiceHistoryDetail"."ItemCode" = "IM1_InventoryMasterfile"."ItemNumber"
AND "AR_InvoiceHistoryHeader"."SalespersonNo" = 'SMC'
AND "AR_InvoiceHistoryHeader"."OrderDate" >= @p_dr
AND "AR_InvoiceHistoryHeader"."OrderDate" <= @p_d2
Однако оказывается, что другое поле даты в той же таблице должно быть тем, с которым сравнивается диапазон дат. Поэтому я изменил даты заказа в конце предложения WHERE на InvoiceDate. У меня еще не было успешного выполнения запроса. И я ждал больше 40 минут. У меня нет контроля над индексацией, потому что это база данных MAS 90, и я не верю, что могу напрямую изменить характеристики базы данных.
Что могло вызвать такую большую (как минимум 5-кратную) разницу в производительности. Может быть, OrderDate был проиндексирован, а InvoiceDate - нет? Я пробовал предложения BETWEEN, но, похоже, это не работает на диалекте Provider. Я использую интерфейс ODBC через .NET в моем модуле настраиваемых отчетов. Я отлаживал отчет, и он работал в точке выполнения базы данных, когда я попросил VS сломать все, в том же месте, где ожидал 8-минутный отчет, так что это почти наверняка либо что-то в моем запросе, либо что-то в базе данных это облажалось.
Если это просто случай, когда InvoiceDates не индексируются, что еще я могу сделать на диалекте Provider SQL для оптимизации производительности этих запросов? Следует ли мне изменить порядок моих критериев? Этот отчет содержит результаты для конкретного продавца, поэтому существует пункт SMC. Предыдущие предложения предназначены для внутренних объединений, а последнее предложение - для диапазона дат.
Я использовал один и тот же диапазон дат в версиях OrderDate и InvoiceDate, прогнал их все несколько раз и получил одинаковые результаты.
Индексы МОГУТ быть проблемой, но только если у вас довольно большая база данных или сервер с очень низкой производительностью. Может быть, вычисляется столбец даты счета-фактуры, а не столбец значений? Можете ли вы посмотреть в диспетчере задач / Perfmon на сервере, чтобы узнать, не простаивает ли он, перегружает диск или сжигает процессор?
В бухгалтерском программном обеспечении MAS 90/200 от Sage Software помимо версии SQL Server используется providex. Я проверю. Никогда не задумывался о тестировании потребления ресурсов. Это система бухгалтерского учета среднего размера, поэтому в затронутых таблицах содержится значительное, но не огромное количество записей.
Я позвонил одному из наших консультантов, который много работает с Sage / Providex, поэтому, если у него будет ответ завтра, я поделюсь им здесь. Некоторое время у нас были проблемы с производительностью запросов в Providerx, так что, возможно, платформа db все-таки не так хороша.
Думаю, метка ProvideX нужна. Я пытался добавить это, но не смог добавить из-за меньшей репутации. Будет хорошо, если кто-нибудь с репутацией 1500+ сможет это добавить. Спасибо!
Ответы 3
Я никогда раньше не пользовался Providex.
Поиск показал эта справочная статья синтаксиса для создания индекса.
Просматривая ваш запрос, есть три таблицы и пять критериев. Два критерия являются «критериями присоединения», а три критерия - критериями фильтрации:
AND "AR_InvoiceHistoryHeader"."SalespersonNo" = 'SMC'
AND "AR_InvoiceHistoryHeader"."OrderDate" >= @p_dr
AND "AR_InvoiceHistoryHeader"."OrderDate" <= @p_d2
Я не знаю, насколько хорош SalespersonNo для ограничения результатов возврата, но было бы неплохо добавить индекс по этому поводу.
К сожалению, у меня нет возможности добавлять индексы в системы MAS 90. Однако проблема исчезла, подумал, что до сих пор остается загадкой, почему это вообще было так медленно.
Похоже, они сняли статью, упомянутую Дэвидом Б.
Я до сих пор не знаю, почему это было так медленно, но у нас была еще одна проблема с результатами, полученными из запроса (мы снова переключились на использование OrderDate). Мы не получали некоторых результатов из-за характера таблицы IM1.
Поэтому я добавил левое внешнее соединение, как только разобрался с синтаксисом Providex для этого. И по какой-то причине, хотя у нас все еще есть 3 стола, теперь он работает намного быстрее.
Новые критерии запроса:
FROM "AR_InvoiceHistoryHeader" "AR_InvoiceHistoryHeader",
{OJ "AR_InvoiceHistoryDetail" "AR_InvoiceHistoryDetail"
LEFT OUTER JOIN "IM1_InventoryMasterfile" "IM1_InventoryMasterfile"
ON "AR_InvoiceHistoryDetail"."ItemCode" =
"IM1_InventoryMasterfile"."ItemNumber" }
WHERE "AR_InvoiceHistoryDetail"."InvoiceNo" =
"AR_InvoiceHistoryHeader"."InvoiceNo" AND
"AR_InvoiceHistoryHeader"."SalespersonNo" = 'SMC'
AND "AR_InvoiceHistoryHeader"."InvoiceDate" >= ?
AND "AR_InvoiceHistoryHeader"."InvoiceDate" <= ?
Странно, но, по крайней мере, я узнал больше о мире Providex Sql в процессе.
Я не использовал .NET, поэтому мой вопрос может показывать незнание, но в Access вы должны использовать сквозной запрос SQL для получения любых результатов из ProvideX, если задействовано более одной таблицы.
Удачи! Возможно, я просто плохо осведомлен, но я не слышал о ProvideX. С таким конкретным вопросом о не слишком широко распространенной базе данных вам, возможно, будет лучше найти форумы, предоставленные поставщиком. Может быть, я ошибаюсь, и есть сотни пользователей SO, которые могут помочь. Я в этом немного сомневаюсь.