Оптимизация производительности Navision под SQL, рецепты, лежащие на поверхности
...
Сразу хочу заметить, что я не пытаюсь взять проблему глубоко.
Просто некий ‘надерганный’ набор общих знаний.
Постараюсь представить некое свое понимание.
Информация относится к текущим версиям Navision 3.70-5.00; SQL Sever 2000,2005.
Про надвигающуюся версию Navision 6.00, содержащую множество новинок, и про уже приближающийся SQL Server 2008 говорить пока рано. Так же умолчим о наиболее сейчас близком 5.0 SP1.
Примечание:
Первые первичные тесты говорят о росте производительности SQL Option после применения 5.0 SP1 -
https://blogs.msdn.com/microsoft_dynamics_nav_sustained_engineering/archive/2008/04/04/my-experiences-with-microsoft-dynamics-nav-5-0-sp1.aspx
О выходе 5.0 SP1 -
https://blogs.technet.com/alexef/archive/2008/03/26/50SP1IndexedViews.aspx
В тексте будут встречаться ссылки на документы.
Если ссылка вида ‘https://mbs.microsoft.com’, то это ссылка на сайт доступный только партнерам (Partnersource).
Если ссылка вида ‘https://www.mibuso.com’, то это ссылка на общедоступный сайт.
Поехали…
Не открою, конечно, Америки, но проблема оптимизации Navision под SQL в существующей документации расписана во многих местах. Хороший сборник линков: https://mbs.microsoft.com/partnersource/sales/salestools/productfactsheets/NAV_SQLSvrOption.htm
Так же полезен наиболее свежий (November 2007) сейчас собирательный 'Kit':
SQL Server Technical Kit for Microsoft Dynamics NAV:
https://mbs.microsoft.com/partnersource/downloads/supplements/mdnavsqltechkit.htm?printpage=false
Разобью информацию на две части: про HARDWARE и про SOFTWARE. Для SQL.
HARDWARE
1)
Если говорить о RAID, то для Navision рекомендуют RAID 1 (10) и не рекомендуют RAID 5. Просмотр истории сервисных запросов показывает улучшение производительности после смены RAID 5 на RAID 1(10). Смотрите так же kb article 857894 “What are the Differences Between RAID 1 and RAID 5 and Why is RAID 1 Recommended” https://mbs.microsoft.com/knowledgebase/KBDisplay.aspx?WTNTZSMNWUKNTMMYMXTYYKSWTLKQNNOXMSXVRSXNXNZRTUVXKLUVYYRUZSWLVQPP
2)
Держите файл данных (Data) и файл транзакций (Log) на разных дисках (наборах дисков RAID), т.е. конфигурация рекомендуется такая:
C: - RAID 1 [OS]
D: - RAID 10 [Primary and Secondary Filegroups (Data)]
E: - RAID 1 or RAID 10 [Logs]
Смотрите также файл по “Hardware Sizing”
NAV 4.00 (August, 2007):
https://mbs.microsoft.com/partnersource/documentation/whitepapers/hardware+sizing+guide+for+microsoft+dynamics+nav.htm?printpage=false
https://www.mibuso.com/dlinfo.asp?FileID=587 (mibuso.com)
NAV 5.00 (October, 2007):
https://mbs.microsoft.com/partnersource/documentation/whitepapers/hardware+sizing+guide+for+dynamics+nav+5.0.htm?printpage=false
3)
Про 64-bit системы. Navision это “толстый” клиент (по крайней мере, для текущих версий), т.е. система использует SQL Client Side cursors которые генерит некий .dll, по сути идет просто трансляция C/AL кода в TSQL. Использование именно серверной части при работе не очень велико (выбор и вставка данных). Navision не получит реального преимущества в случае использования 64-bit платформы. 64-bit платформа не дает особого выигрыша в производительности для этих самых SQL Client Side cursors. Выигрыш в производительности может быть получен за счет мощности процессора, оперативной памяти, дисковой подсистемы, не за счет версии и битности (32,64) SQL Server. Т.е. более мощный, с точки зрения битности, 64-битный сервер проиграет на Navison своему 32-битному конкуренту, имеющему просто более высокую тактовую частоту процессора.
4)
Так же помните о “толстом” клиенте в плане клиентских машин и сети, т.е. мощность наиболее используемых для учета документов клиентских машин так же важна для хорошей общей производительности.
...
У Navision клиент "толстый". Т.е. клиентский курсор вытягивает набор данных на машину пользователя и там уже идет 'пробежка' по данным.
В Navision в учетных codeunit-ах первым делом идет блокирование таблиц операций (LOCKTABLE). И пока учет не пройдет таблица вся заблокирована. Такая уж у Navision базовая идеология.
Что бы сократить время 'локировки' и как следствия снизить вероятность всяких lock/deadlock. Необходимо быстрее производить учет на клиентской машине. Т.е. мощная клиентская, 'учетная' машина и отсутствие проблем с сетью это плюc для производительности на NAV.
SOFTWARE
Попробую ответить, опираясь на некие базовые условные вопросы. Основные, конечно, данные по рассматриваемой теме вы можете найти в документации, на которую я буду ссылаться ниже
1)
Как методами Navision можно решить проблемы быстродействия?
- Первый шаг это поставить максимально возможно свежие клиентские файлы (build) Navision.
Т.е. если лицензия клиентская позволяет запускать оболочку от 3.70, то надо ставит оболочку (папка Сlient, finsql.exe; ndbc.dll …) от 3.70. Если есть возможность запускать 4.00, то соответственно надо ставить 4.00 + самый свежий service pack по оболочке + Rollup + hotfix и т.п.
У меня сейчас стоит, к примеру, build 4.0.3.25638
Примечание:
Так же про свежие update (service pack) SQL Server (в частности 2005) так же забывать не стоит.
Приведу ссылку на свой же блог,
Обзор обновлений SQL Server 2005 SP2 в контексте Navision:
https://blogs.technet.com/alexef/archive/2008/02/04/OverviewSQL2005SP2andNav.aspx
Почему это важно.
Только в эпоху 3.70 MS/Navision задумалась реально о вопросе производительности Navision именно для SQL базы. Ядро системы начали постепенно “корежить”, так что бы и SQL Server было хорошо.
Какие-то улучшения попали в оболочку 3.70.B. Более существенные вещи проникли в 4.00 SP1 (в частности SIFT tables triggers по заявлениям убыстрились на 70%; появились новые, оптимизированные под SQL, C/SIDE функции FINDFIRST, FINDLAST,FINDSET; новые настройки свойств БД "Lock timeout", "Always rowlock"; Появилась возможность ставить кластерный индекс на не Primary Key …). И процесс идет…
Примечание:
Если у вас версия скажем только 3.60, то по производительности предпочтительно использовать Native (.fdb) формат БД (если конечно у вас база не будет стремительно расти сверх 128 GB).
Кстати последние тесты https://mbs.microsoft.com/partnersource/documentation/benchmarks/MSDYNAV_SQL_benchmark_results.htm на 4.00 SP1 SQL 2005 не показывают убедительной победы SQL БД над Native (.fdb) БД.
…
Хотя, конечно, реально избавиться от наследия ориентации бизнес-логики на Native (.fdb) базу удалось в какой-то степени только в 5.00. Именно в 5.00 во всем стандартном коде стали использоваться новые C/SIDE функции FINDFIRST, FINDLAST,FINDSET (В 4.00 SP1 функции появились, но стандартный C/SIDE код объектов переписан под них не был….).
- Второе.
Если версия 3.70 и ниже и для 4.00 это также актуально я думаю что основной фактор ухудшающий производительность, и на большой базе особенно, это большое кол-во вновь созданных и не только (нужны ли вообще реально все SIFT поля? ) SIFT полей. SIFT полям, по возможности, надо убрать их проекцию на SQL. Т.е. снять в свойствах ключей галочку MaintainSIFTIndex. Вычисляемые поля будут считаться дольше и обычными sql-запросами, зато лавина дополнительных SIFT табличек перестанет заполняться на каждой транзакции. Все это подробно расписано много где. Да хотя бы в w1w1adg.pdf на Product CD.
- Третье.
Убрать из таблиц все неиспользуемые ключи и для ключей, что созданы для целей только каких-то удобных сортировок используемых списков, убрать их проекцию на SQL. SQL и так данные пересортирует. Т.е. снять галочку MaintainSQLIndex в свойствах ключей.
Все это и много чего еще другого расписано в SQL Server Resource Kit.pdf (базируется на 3.70):
https://mbs.microsoft.com/partnersource/products/navision/documentation/benchmarks/navisionsqlresourcekit.htm?printpage=false
https://www.mibuso.com/dlinfo.asp?FileID=561 (mibuso.com)
И более свежий (c учетом изменений 4.00 SP1) но в целом с той же информацией
Database Resource Kit.pdf: https://mbs.microsoft.com/partnersource/downloads/supplements/databaseresourcekit.htm ). ...
2)
Как работает функция оптимизация таблиц в БД? Что она выполняет?
Вычищает “дырки” (записи имеющие отношение к данным уже удаленным из основной таблице) в SIFT таблицах. Т.е. дефрагментация. Т.е. база должна поджаться по размеру не очень сильно после этих операций. Смотри про это Database Resource Kit.pdf
3)
Какие возможны методы оптимизации SIFT таблиц для SQL Server?
Смотри про это Database Resource Kit.pdf. Собственно можно их не оптимизировать, а просто убрать. Ну хотя бы убрать SIFT таблицы (MaintainSIFTIndex = No) построенные на основных таблицах что маленькие по размеру и промежуточные (постоянно что-то приходит из них и уходит) Sales Line, Purchase Line. На этих таблицах вычисляемые поля и с отсутствием проекции на SQL быстро просчитаются.
4)
Смотри Database Resource Kit.pdf (4.00); SQL Server Resource Kit.pdf (3.70)
Так же смотри наиболее свежий (November 2007) сейчас собирательный 'Kit':
SQL Server Technical Kit for Microsoft Dynamics NAV:
https://mbs.microsoft.com/partnersource/downloads/supplements/mdnavsqltechkit.htm?printpage=false
И конечно по теме производительности/оптимизации читайте форумы и другие on-line ресурсы: https://forum.mazzy.ru/; https://www.mibuso.com/forum/index.php .....