Цитата:
Сообщение от
3oppo
Есть ли смысл скажем в перенесении больших таблиц (таких как InventTrans, LedgerTrans ) в отдельный BD файл, на уровне SQL сервера
делали, помогало.
Цитата:
Сообщение от
3oppo
Ну или может кто ещё что посоветует?
Вообще, если вопрос в производительности, может, сначала посмотреть на саму Аксапту и АОСы? А именно:
- формы с большим кол-вом строк - ограничить число строк фильтрами
- формы с дисплейными методами - перевести на временные таблицы
- lookup'ы с перекрытым Lookup - упростить
- раскидать пользователей по АОСам (кластер, но лучше развести работающих с разными данными (кэш АОСа!))
И уже потом по SQL-серверу:
- отследить профайлером самые нагружающие запросы и оптимизировать (в частности, с помощью дополнительных индексов)
- аналогично, отследить с помощью sys.dm_db_missing_index_group_stats, каких индексов не хватает
- с помощью sys.dm_db_index_usage_stats отследить неиспользуемые индексы (т. е. отсутствующие в этом представлении), на поддержание к-рых тратятся ресурсы
(2 предыдущих пункта лучше за большой период времени работы сервера без перезагрузок)
- получить статистику по блокировкам/deadlock'ам, отследить и устранить причины (часто причина в кодах, либо связано со следующим пунктом)
- минимизировать внешнее влияние на работу Аксапты (конкурирующие SQL-задания/SSIS-пакеты, пользователи, подключающиеся к таблицам БД напрямую)
- отдельный standby-сервер для отчётов и пользователей, подключающихся к таблицам БД напрямую
- отдельные дисковые массивы для самых нагруженных таблиц
- убрать возможное влияние резервного копирования, в т. ч. Windows, и антивирусов
- увеличить autogrow, отключить autoshrink, включить автостатистику, регулярно перестраивать важные индексы
- тестировать и применять к инсталляции SQL-сервера совместимые сервис-паки и CU.
И т. д...
А вообще по оптимизации SQL - в конкретном случае надо смотреть очереди к дискам, навешивать другие счётчики, разбираться с ожиданиями. А может, причина проседания производительности - вообще сеть...