В Аксапте можно использовать хинты (подсказки) для sql-сервера. Вадим Гончаренко рассказывает о использовании эти хинтов.
Вадим Гончаренко, vgoncharenko@rabota-na-rezultat.ru
IndexHints.zip (5Kb, проект и таблица с результатами, для загрузки требуется регистрация на форуме у Mazzy)
Index hints и MSSQL
Здесь я уже показывал, как с помощью хинтов (англ. hint – подсказка, намек) можно влиять на формируемый запрос из кода X++. В этой статье я систематизировал то, что удалось выяснить экспериментальным путем.
Любой отсылаемый на SQL сервер запрос может содержать в себе те или иные хинты, влияющие на его выполнение. То, какие хинты будут использованы, зависит:
- от параметров таблиц, участвующих в запросе
- от настроек ядра системы
- от программиста, использующего хинты в запросе X ++
В действительности эти параметры зависят друг от друга: так, например, настройки ядра могут управлять тем, будут ли применяться конкретные хинты, используемые разработчиком в коде или нет.
С хинтами в X ++ все относительно просто: они задокументированы в руководстве разработчика. А вот поведение ядра при формировании запроса, как правило, понять довольно сложно. Тем не менее, на него можно влиять, используя параметр Hint flags конфигурационный утилиты. Это целое число со значениями от 0 до 255, вычисляемое сложением следующих параметров:
- HINT_INDEX (1) – если параметр включен, будут работать операторы INDEX HINT из X ++ кода. Кроме того, при использовании FORCELITERALS имеет побочное действие – при использовании SELECT по одной таблице с условиями в части WHERE по индексированному полю использование этого индекса будет указано в запросе автоматически;
- HINT_FASTFIRST (2) – в условии SELECT будет автоматически добавляться хинт OPTION ( FAST n ). Значение n будет вычисляться как Buffer size / длина записи в таблице, где Buffer size – это размер пакета данных, которыми обмениваются Аксапта и SQL Server. Значение по умолчанию для Buffer size – 24 KB;
- HINT_FIRSTONLY (4) – используется совместно с параметром HINT_TOP;
- HINT_NOLOCK (8) – при обращении к таблице со свойством CacheLookup не ниже Found будет использоваться «грязное чтение» (хинт NOLOCK);
- HINT_FASTFORWARDONLY (16) – заявлено, что при его включении используются forward - only курсоры;
- HINT_FORCE_SELECT_ORDER (32) – будут работать хинты FORCESELECTORDER из X ++ кода (в запрос попадает текст OPTION (FORCE ORDER));
- HINT_TOP (64) – совместно с параметром HINT_FIRSTONLY разрешают инструкцию SELECT TOP 1 при использовании оператора FIRSTONLY в X ++. Самое интересное, что при использовании вместе с FORCELITERALS при выполнении запроса вообще не используется Prepared execution;
- HINT_FORCE_NESTED_LOOP (128) – при его включении будут работать операторы FORCENESTEDLOOP из X++.
Проведенное расследование показало, что по умолчанию для Microsoft SQL Server 2000 включены не совсем те параметры, которые указаны в документации. Так, параметр HINT_FIRSTONLY явно выключен, а HINT_FORCE_NESTED_LOOP – включен, хотя в документации утверждается обратное. Ошибка ли это документации или что-то изменилось в ядре с версии 2.5, неизвестно.
К статье приложен архив с проектом (одна таблица и job) используемым при тестировании, а также таблица с его результатами. Для загрузки требуется регистрация на форуме у Mazzy.
Желающие получить более подробную информацию могут обратиться к документу Performance Enhancements Using the Cost-Based Optimizer.
Вадим Гончаренко, vgoncharenko@rabota-na-rezultat.ru
