Здравствуйте.

Столкнулся с проблемой выполнения запроса (по времени) к таблице, открытой в общем доступе.
Размер таблицы - 25 Mb

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

1. Приложение открыто только у меня - 0:23
2. Приложение открыто у 3-х пользователей - 8:35
3. Приложение открыто только у меня (без перезапуска) - 8:50
4. Приложение открыто только у меня (с перезапуском) - 0:24

Время работы с тремя и более пользователями возрастает в 20-25 раз.
И почему-то в 3-м варианте, хоть все остальные пользователи вышли - время показано примерно такое же. Помог только перезапуск приложения.

Может кто-то сталкивался с аналогичной проблемой?
Есть какие-то варианты оптимизации?

Спасибо.

Ffffffffffffffff,

в главной програме стоит "ON"
но таблици открываются: USE table1.dbf SHARED IN 1 ALIAS table1

Ffffffffffffffff,

Результаты практически такиеже, даже в некоторых случаях больше.

При открытии таблицы одним пользователем запрос выполняется в считанные секунды, а если откроет ещё дотя бы один пользователь - время увеличивается до 7 - 8 минут... Это как раз очень и напрягает.

Dima T,

На другой комп перенести не могу. Это корпоративный сервак и туда прописаны права у пользователей.
Пробовал данную таблицу перед тем, как выполнить к ней запрос, скопировать к себе на комп.
Время с 8 минут сократилось до 2,5-3, но это потому что в запросе такжу участвуют и другоие общие таблицы.
Запос выполняется в двойном цикле: выборка по квартально (4 вкартала) и внутри каждой выборки данные по 7-ми подразделениям.
Естественно, если включать в выборку только 1 квартал - время будет в 4 раза меньше.
ОС у пользователей - Винда 2000 и ХР. На серваке сокрее всего тоже Винда.

alextashk,

ОС у пользователей - Винда 2000 и ХР. На серваке сокрее всего тоже Винда.

Dima T,

А что это за особенность системы блокировок винды?

Людмila,

Да запрос вроде простой.

Пример открыьтя таблиц:
USE pcBdSchedulesPath+"_put_list.dbf" SHARED IN 4001 ALIAS bd_schedules_apl_loc


Пример запроса (выполняется в цикле по периодам и внутри каждого периода по отделам)
SELECT;
bd_schedules_apl_loc.apl_id,;
bd_schedules_apl_loc.apl_stats,;
bd_schedules_apl_loc.apl_numb,;
bd_schedules_apl_loc.apl_name,;
bd_schedules_apl_loc.apl_datetm,;
bd_schedules_apl_loc.apl_datego,;
bd_schedules_apl_loc.rep_ocens,;
bd_schedules_apl_loc.kol_banks,;
(IIF(bd_schedules_apl_loc.kol_banks>0,bd_schedules_apl_loc.kol_banks,cur_sum_clnt.sum_clnt))sum_clnt,;
bd_schedules_otdels.otdel_code,;
bd_schedules_otdels.work_srok,;
bd_schedules_otdels.work_id,;
nsi_type_work.group_name,;
cur_lost_requery.max_daterq,;
({..})date_norm,;
(0)isp_stats,;
cur_lost_query.no_requer;
FROM ;
bd_schedules_apl_loc;
INNER JOIN bd_schedules_otdels;
ON bd_schedules_apl_loc.apl_id = bd_schedules_otdels.apl_id ;
INNER JOIN nsi_type_work ;
ON bd_schedules_otdels.work_id = nsi_type_work.id_work;
left OUTER JOIN cur_sum_clnt;
ON bd_schedules_apl_loc.apl_id = cur_sum_clnt.apl_id ;
left OUTER JOIN cur_lost_requery;
ON bd_schedules_apl_loc.apl_id = cur_lost_requery.apl_id ;
left OUTER JOIN cur_lost_query;
ON bd_schedules_apl_loc.apl_id = cur_lost_query.apl_id ;
WHERE bd_schedules_apl_loc.apl_stats = "закрыто";
AND bd_schedules_apl_loc.apl_datego BETWEEN pdDateRepStart AND pdDateRepFinish;
AND bd_schedules_otdels.otdel_stat = 1;
AND bd_schedules_otdels.otdel_base = "1";
AND bd_schedules_otdels.otdel_code = ALLTRIM(lcOtdelCode);
AND bd_schedules_apl_loc.wiev_code # "1";
INTO CURSOR cur_stat1 READWRITE


Комментарий:
bd_schedules_apl_loc - основная таблица со списком дел
bd_schedules_otdels - таблица со списком отдлов-исполнителей
nsi_type_work - таблица НСИ с видами работ
cur_lost_query, cur_lost_requery - курсоры с датами запросов и ответов по делам
cur_sum_clnt - курсос с кол-вом клиентских записей для каждого дела

Dima T,

Оптимизатор выдаёт следующее:
--------------------------------------------------------------------------------------
Rushmore optimization for table bd_schedules_apl_loc: none
Rushmore optimization for table bd_schedules_otdels: none
Rushmore optimization for table nsi_type_work: none
Rushmore optimization for intermediate result: none
Rushmore optimization for intermediate result: none
Rushmore optimization for intermediate result: none
Joining table nsi_type_work and table bd_schedules_otdels using temp index
Joining intermediate result and table bd_schedules_apl_loc using temp index
Joining intermediate result and intermediate result using temp index
Joining intermediate result and intermediate result using temp index
Joining intermediate result and intermediate result using temp index
--------------------------------------------------------------------------------------

Число записей в основной таблице - около 15 тыс.
В результирующем запросе - 5 - 9 (в зависимости от одела)

Запрос выполняется в 4х7 цикла, каждый примерно по 6-7 секунд (при запуске приложения несколькими пользователями)
В итоге и набегает около 3 минут.

Dima T,

Индексы я не ставил по двум причинам: 1. в индексированных таблицах замедляются операции ввода и редактирования данных, 2 - при добавлении новых записей необходима повторная переиндексация, что подразумевает отключение от базы всех пользователей.
В данном варианте исполнения приложения это не совсем удобно. В дальнейшем возможно база будет разделена на текущую (куда добавляются и редактируются новые записи) и архивную (закрытые дела, по которым редактирование осуществляется крайне редко). Быть может тогда стоит применить индексирование к архивной части базы, т.к. данный запрос формируется именно по закрытым делам.

Согласен, что процес запроса "цикл в цикле" не совсем удачное решение. К сожаленю, так построена структура формирования отчёта. С другой стороны, при одиночном использовании приложения этот запрос выполняется за 20-25 секунд (от момента запуска до открытия готового отчёта в excel). Это нормально по сравнению с 3-8 минутами (при коллективном использовании приложения).
Т.е. сам запрос отрабатывает относительно быстро (понятно, что при индексации будет ещё быстрее). Не понятна причина, по которой разница по времени возрастает раз в 20, когда подключается хотябы ещё 1 пользователь.

Dima T,

по WHERE меняется сначала период (1 квартал, 2, 4 или 4), а внутри код отдела, для которого формируется отчёт.

например,
выбрали 1-й квартал.
для периода с 01/01 по 31/03 в цикле для каждого отдела выгружаются данные и записываются на разные листы в excel в столбец А

Выбрали 2-й квартаол
для периода с 01/01 по 31/03 в цикле для каждого отдела выгружаются данные и записываются на разные листы в excel в столбец А
для периода с 01/04 по 30/06 в цикле для каждого отдела выгружаются данные и записываются на разные листы в excel в столбец B

и т.д.

Dima T,

Да, читал. Просто на столько явное расхождение по времени и неужеди всё уходит на сеть...

Изначально индексирование не рассматривалось. Были несколько другие задачи и объёмы. + слышал не очень-то лестные отзывы о работе с индексированными таблицами: периодически индексы падали... А так, да. Но скорее для варианта с разделёнными базами.

В любом случае, Dima T, спасибо.

AndreTM,

В книгах по Фоксу читал, но сейчас уже не помню в каких именно.

AndreTM,

Спасибо за совет.

Dima T,

Но основная проблема, как я понял, связанна с сеткой?
Да пусть сейчас таблица непроиндексирована, но и в 20 раз быстрее выполняется запрос в одиночном режиме.
Допускаю, что с индексами будет работать гораздо быстрее... Вот интересно проверить сколько покажет тестирование по времени в многопользовательском режиме... (меньше 8 минут?)

Ещё раз спасбо за советы.

Dima T,

с проиндексорованной таблицей получилось 1:28 вместо 2:35

Dima T,

походу сначала придётся перепроектироваться всю структуру БД и понять, что индексировать

возможно даже какие-то постоянные данные (например, НСИ "ОКАТО" или "Формы собственности") единажды переносить с сервера на станцию пользователя и открывать их с неё...