РЕКОМЕНДАЦИИ ПО ОПТИМИЗАЦИИ РАБОТЫ СИСТЕМЫ

Выполнение следующих рекомендаций по настройке операционной системы, SQL сервера и пользовательских запросов позволит увеличить быстродействие МИС МЕДИАЛОГ и избежать блокировок работы системы, связанных с медленным выполнением запросов.

Рекомендации по настройке операционной системы Windows 7

1.Замедление работы может вызывать постоянно включенная служба поиска. Ее отключение повышает производительность.

2.Автоматическая настройка TCP в гетерогенных сетях часто приводит к замедлению работы в сети. Она отключается следующей командой:

netsh interface tcp set global autotuninglevel=disabled

netsh interface tcp set global rss=disabled

После выполнения команд требуется перезагрузка.

3.Следует проверить что происходит в системе в момент зависания: возможно, другие программы в этот момент занимают все ресурсы.

4.Проверить работу антивируса. Проблемы может вызывать отсутствие антивируса или постоянная проверка антивирусом каталога МИС МЕДИАЛОГ, который содержит множество файлов, из-за чего его проверка может существенно замедлять работу.

Рекомендации по настройке SQL сервера

1.Должна быть разрешена работа по протоколу TCP/IP и запрещена работа по протоколу NETPIPE.

2.Правильно установить параметр max degree of parallelism. Проверить значение параметра можно следующим запросом:

sp_configure "show advanced options", 1

sp_configure "max degree of parallelism"

В графе config_value должно стоять значение равно количеству ядер сервера, поделенному на 2. Если стоит значение 0, то при долгих запросах сервер может не отвечать некоторое время.

Выставить нужное значение можно запросом

sp_configure "max degree of parallelism", x

где x - нужное значение.

Рекомендации по настройке табличных объектов и пользовательских запросов

1.При настройке полей поиска и сортировки в табличных объектах (гриды, лукапы, n-line и т.п.) рекомендуется включать поиск и сортировку только по индексированным полям. Часто при поиске и выборе данных используются запросы типа SELECT TOP 50 из каких-либо таблиц (например, пациенты или талоны), и затем идет ORDER BY PRENOM (или какое-либо другое неиндексированное поле). В результате серверу приходится выбирать все данные, затем сортировать их по этому полю и только после этого урезать результат в соответствии с ограничением TOP 50. В результате, когда условие фильтра не задано, такая сортировка приводит к резкому замедлению работы сервера. Это часто происходит при выборе пациента. Там не должно быть сортировок по неиндексированным полям.

2.Желательно запретить пользователям доступ к изменениям настроек гридов. Пользователи могут включать сортировку локально, кликая по заголовкам колонок, но в следующий раз будет снова загружена сортировка из настроек. Если пользователю не требуется изменять сортировку, в табличном объекте рекомендуется выставить опцию Отключить быструю сортировку, чтобы сортировка не происходила при случайном клике по заголовку.

3.Для уменьшения нагрузки на сервер рекмендуется выставить опцию Сортировать на клиенте: в этом случае сортировка данных будет выполняться на клиентской машине.
Данная опция может быть включена по умолчанию для всех гридов: для этого в файле Automedi.ver в секции [Troubles] нужно прописать параметр ClientSort=1. Опция включается только для тех гридов, настройки которых не были сохранены ранее.
Кроме того, опция может быть включена для всех аптечных гридов: для этого, в файле Automedi.ver в секции [Troubles] нужно прописать параметр MedsServerSort=0. В этом случае опция включена всегда, независимо от настроек, заданных непосредственно в гриде.

4.Не злоупотреблять поиском по выражениям. Распространен случай, когда в запросе формируется выражение (например, ФИО), а затем по нему настраивается поиск. При этом формируется следующее условие в запросе:
WHERE (cast(case when PATIENTS.NOM<>'' then PATIENTS.NOM + ' ' + PATIENTS.PRENOM + ' ' + PATIENTS.PATRONYME else FM_PATIENTS.NOM + ' ' + FM_PATIENTS.PRENOM + ' ' +FM_PATIENTS.PATRONYME end AS VARCHAR(100))) like 'pa%')
В результате сервер не может использовать индексы и ему приходится перебирать все записи. Лучше в таких случаях искать по одному полю Фамилия.

5.Не злоупотреблять использованием в запросах сложных подзапросов и хранимых процедур.

6.Сделать обязательными условия фильтров в больших запросах. Если пользователь случайно выполнит их без фильтра по датам или другим ключевым полям, то запрос будет выполняться медленно и блокировать работу других пользователей. Это в первую очередь касается талонов и счетов, а также пользовательских статистических запросов.

7.В некоторых гридах включена опция Показывать кол-во записей, при этом системе приходится при каждом открытии такого грида выполнять запрос SELECT count(*) CNT по всей таблице, что может замедлять работу пользователей (особенно часто это встречается в талонах). Следует отключить эту настройку.
Для настроек гридов реализована возможность принудительного обновления настроек у всех пользователей (кнопка Обновить на форме настроек грида на закладке Поиск).

8.Ограничить права доступа на запуск наиболее ресурсоемких запросов, либо выполнять подобные запросы на копии базы или на отдельном сервере.

9.В свойствах запроса поставить признак Пустой результат без основных фильтров.

10.В запросах периодичной отчетности рекомендуется выставлять опцию SELECT NOLOCK в параметрах запроса, чтобы таблицы, участвующие в запросе, не блокировались для модификации на время выполнения запроса.

11.В запросах финансовой отчетности по возможности исключить использование фильтров по полям таблицы Оплата за оказанные услуги (FM_BILLDET_PAY). Если без подобных фильтров не обойтись, рекомендуется ограничить доступ пользователей к данному запросу, либо обеспечить выполнение этого запроса только на копии базы – для получения отчетов, так как наверняка подобные отчеты будут выполняться медленно. Эти меры позволят избежать простоев в работе пользователей в периоды сдачи отчетности.

12.В запросах финансовой отчетности (например, запрос "Организация, аналитика") удалить, если имеется, подобное условие на таблицу Оказанные услуги (FM_BILLDET):

FM_BILLDET.FM_BILLDET_ID IN

(select FM_BILLDET_ID from FM_BILLDET_pay

where (FM_BILLDET_pay.blocked>0 and :blocked='БЛОКИРОВАННЫЕ') or

(FM_BILLDET_pay.blocked=0 and :blocked='НЕБЛОКИРОВАННЫЕ') or

( :blocked='ВСЕ'))

Вместо параметра :blocked нужно использовать фильтр по полю Заблокирована таблицы Оказанные услуги (FM_BILLDET.BLOCKED).

13.Для отчетов, содержащих параметры типа Дата, включить опцию Преобразование параметров в переменные в свойствах запроса или использовать вместо параметров SQL переменные. SQL переменные декларируются также свойствах запроса на вкладке Переменные запроса.

Остальные способы оптимизации должны подбираться индивидуально в соответствии случаям. По этим вопросам необходимо обращаться на адрес технической поддержки support@medialog.ru или форум http://forum.medialog.ru (для авторизованных пользователей).