Доброго времени суток.
Помогите разобраться.
Дано: база на Access 2010. База разделена (данные+клиент). На каком-то этапе база стала медленно работать - поиск в основной форме стал работать 20 секунд (а это наиболее востребованная функция).
Механизм поиска и ошибки в коде не принципиальны так-как:
При запуске на локальном компе под Windows 10 (i5+6RAM) поиск занимает от 1 до 3 сек
При запуске на локальном компе под Windows Server (i3+6RAM) поиск занимает 2 до 5 сек
При запуске на сервере (двухпроцессорный Xeon+16RAM) поиск занимает от 8 до 20 (иногда и более) сек.

Подскажите в какую сторону копать. Спасибо

upd: Один из разработчиков утверждает, что в процессе поиска у него подключается второе ядро (это машина с i3 процессором)

На других машинах я этого не увидел

Аллюр Д.1. Посмотрите размер файла с данными - если файл заметно распух, то это может стать причиной "тормозов". Сделайте копию, на всякий случай, и выполните сжатие базы
Под рукой нет Access'а 2010, поэтому точное название пункта не скажу, но там в настройках есть галка - Сжимать при закрытии
2. Если сжатие и уменьшение размера не привело к ожидаемому повышению скорости поиска, по посмотрите наличие индексов в полях, по которым выполнятся поиск

Предполагаю, что поиск выполняется штатными средствами Access'а, а не бэйсиковским Find или проверкой recordset'а в цикле

Первые два пункта мимо. Сжатие есть, индексы есть. Более того - по условиям задачки у нас база одинаковая на 3 машины

Поиск выполняется путём изменения параметра в запросе - источнике данных подчинённой формы.

Да куда уж подробнее?
У меня на локальном компе всё летает. (1)
У второго программиста на локальном компе всё летает. (2)
Запускам локально на сервере - всё тормозит. (3)

Дело не в программе - она одинаковая!
Дело не в серверной винде - на 2ой машине поставили серверную винду.
Дело в Ксеонах?

Аллюр Д.Safich,

Теперь телепатам надо угадать конфигурации этих компьютеров?

Никто из присутствующих не видел этой базы и этих компьютеров, и если Вы будете продолжать отбрыкиваться от вопросов, то вероятность нахождения правильного ответа будет стремиться к нулю.

1. что Вы подразумеваете под запуском на локальном компе? Оба файла - с программой и с данными, находятся на этом компьютере?
2. Какой размер файла с данными? На сколько он уменьшается после сжатия?
Если открыть файл с программой, то при закрытии сожмётся только файл с программой, а файл с данными так и останется несжатым
3. была версия про индексы - Вы сами проверяли их наличие или верите на слово разработчику?
4. слова i5, i3, xeon не значат ничего! Например, у нас, i3, купленные в начале этого года, заметно быстрее, чем i5, которые были куплены пару лет назад. А старенький сервер на Xeon'е, думаю, будет в 10 раз медленнее, чем эти, двухгодичной давности, i5

Конфиги описаны в первом посте, от вопросов не отбрыкиваюсь, просто наверно пропустили, читайте внимательнее.

1) В обычной работе пользователи (10-15 человек) работают по сети (VPN+RDP), поэтому первое что было исключено - скорость работы сети или глюки RDP(или VPN). И файл с базой и файл с клиентом физически находятся на той машине, с которой всё запускается. При этом к этому компьютеру подключена клавиатура, мышь, монитор и человек, в том числе и к серверу.
2) База данных. Примерно 300 мегабайт. Сжимается незначительно, автосжатие стоит, перед тестом сжималась принудительно.
3) Базу местами писал и я - индексы там есть, но поскольку в той форме запрос объединяет кучу таблиц, проверить всё долго.
4) У меня i5, купленный 5 лет назад. i3 - 2-3 года назад, ксеонов 2: один 3ёхлетний (E3-1220 v2), другой 4летний (просто Xeon - 2 процессора).

Ещё раз, клиент и база абсолютно идентичны, запускаются одинаково. Но на серверных машинах база тормозит.

Аллюр Д.Вы невероятно упорны

Допустим, что выполняется на одной и той же версии Access, с одинаковыми сервис-паками и всеми обновлениями Офиса и Виндоуз.
Вы не указали разрядности ОС, ну допустим, они все 64-разрядные.
Скорее всего, влияние дефрагментированности файла с данными вряд ли так сильно сказывается на производительности Access'а, но я бы выполнил дефрагментацию, чтобы привести все файлы "к одному знаменателю"
Дальше запустил бы поиск и посмотрел в Диспетчере задач нагрузку на процессор и использование памяти, заодно может быть выяснилось, что какая-то сторонняя задача нагружает процессор.
Дальше, запустил бы программу тестирования производительности железа (кажется у Windows 7 есть и какая-то всроенная тестилка) и может быть выясилось бы, что произволительность железа находится в таких же пропорциях как и скорость поиска в базе

Поскольку проверять индексы Вы категоричеси не ходите, то можно проверить косвенно план выполнения запроса - сохранить самый медленный запрос и поверить по времени, столько же будет выполняться или больше/меньше. Сделайте несколько запусков, чтобы усреднить влияние кэширования. Если не путаю, то Access по-разному строит планы выполнения для сохранённых запросов и для запросов формируемых "на лету"

Вы игнорирете не только мои вопросы, товарищ Ы написал про условия - используются символы подстановки?
И вообще, есть разница в скорости выполнения запроса на всех трёх компах, если нет условий отбора?

Наверное, завтра выйдут на работу настоящие сильные экстрасенсы и они махом всё решат

Упорствуете тут только вы)
Допустим индексы кривые, допустим базу не сжимали, допустим используются символы подстановки...
Это НЕ ВАЖНО, так-как базы ОДИНАКОВЫЕ! Файлы с данными тоже ОДИНАКОВЫЕ (Ctrl+C, Ctrl+V)

Винда конечно x64, другие уже наверно никто не ставит, офис тоже одинаковый.
7ой винды, если вы внимательно посмотрите тред, нет ни на одной из машин.

Посмотреть в диспетчере задач - смотрели. Ничего лишнего, только Access. Собственно и вопрос насчёт второго ядра вылез отсюда (из диспетчера). На сервере (двухпроцессорном) поиск загружает 1 ядро на 100% (общая загрузка 15%).
На компьютере под номером 2 - тоже с серверной виндой, но с i3 процессором, вроде загружается несколько ядер.

Разница в выполнении запроса "без условий" такая же.

Сообщение тов. "Ы" не было проигнорировано, а частично отвечено моим следующим постом. Тем более оно тоже "мимо": предположение, что виновата сеть или блокировки ошибочно... а предложение "переделать на SQL сервер" слишком ресурсозатратно

ROISafichНа каком-то этапе база стала медленно работать - поиск в основной форме стал работать 20 секунд (а это наиболее востребованная функция).
Поиск в форме это гадкое зло.
РекордСет вас спасет.
С уважением.
Поиск - условие в "источнике данных формы" = рекордсет

Predeclared1-я машина: Win XP (32) на 2-х ядерном Athlon-е, 2 гига озу.
2-я машина: Win Server 2008 R2 (64) на 2-х процессорном Xeon, 4 гига озу.

1-я машина заметно шустрее, даже на глаз.
В причинах не разбирался, ибо по барабану. :)
То есть даже не пытались? Жаль, проблема-то, судя по всем, идентичная.

vmagВаш сервер отрабатывает на ура только как файловый сервер (на все вопросы дает быстрые ответы),
по сему видно, что на это он и заточен, когда программа на нем работает локально, то акцесу уже приходится
делить ресурсы (приоритет, память, процессор) со всем тем, что на нем запущено + если вы запускаете еще
и исходник проекта - то антивирус еще и проверяет весь код vba (c касперским mdb точно заметно тормозит
по сравнению с mde). Попробуйте сделать простой эксперимент - выдерните после работы сервак из LAN,
перезагрузите, подождите минут 5 и потом подергайте локально базу - каков будет результат ?
Не совсем понял. Сервер "на ура" не отрабатывает никак (ни по сети, ни локально).
Есть боевой сервер (тот что E3-1220 v2) - там много чего крутится: SQL, антивирус, 10-15 пользователей и базы Access.
И есть сервер тестовый. Вот там голая винда, без антивируса и всего прочего. Только Windows Server 2008 и Access 2010. И ни одного пользователя, кроме меня.