Всем привет!

Записей в журнале документов (Поступление ТМЗ) около 20 000 поднимаюсь наверх делаю быстрый поиск на нижнею. Поиск занимает 8 минут.

Где копать что делать для ускорения поиска?



1С + SQL

База: 15 Gb (Бухгалтерия)

Активных пользователей до 40

Сервер:
Проц E5-2420 (2x)
ОЗУ 32 Gb

Sql выделено 15 Gb, ежедневно идут обновления статистики и дефрагментация индексов, еженедельно перестроение индексов.

какой именно поиск делаешь? по какому полю?
З.ы. в шапке сделать свой поиск например можно, там запросом быстро пробежать и отбор поставить. Как в справочнике Сотрудники например, в УПП, ЗУП

начни с
http://wiki.mista.ru/doku.php?id=it:analiz_sql_block

Быстрый поиск в верхней панели, поиск делаю по контрагенту

(3) замер производительности сделай, найди узкое место

RAID5? :-)

Вроде 1 0

поле контрагент Индексируется в журнале?

LAZYWRITER_SLEEP    2655851.0    17.9
CHECKPOINT_QUEUE    1507582.0    10.2
XE_DISPATCHER_WAIT    1200018.0    8.1
SP_SERVER_DIAGNOSTICS_SLEEP    1200049.0    8.1
HADR_FILESTREAM_IOMGR_IOCOMPLETI    1140577.0    7.7
LOGMGR_QUEUE    1140662.0    7.7
REQUEST_FOR_DEADLOCK_SEARCH    1139057.0    7.7
XE_TIMER_EVENT    1141707.0    7.7
SQLTRACE_INCREMENTAL_FLUSH_SLEEP    1138592.0    7.7
DIRTY_PAGE_POLL    1140702.0    7.7
SLEEP_TASK    570411.0    3.8
BROKER_TO_FLUSH    570384.0    3.8
CXPACKET    185164.0    1.2
LCK_M_U    43738.0    0.3
LCK_M_X    23644.0    0.2
BROKER_TASK_STOP    10006.0    0.1

Кто можен на вскидку проанализировать проблему?

(2) А как связаны ожидания на блокировках и чтение с nolock?

Правильное решение - пользоваться отбором, а не поиском.

(11)
Это понятно.
8 минут поиска в таблице с 20 000 записями это нормально?

(12) Это смотря как искать. Если на сервере, то долго, а если например данные выкачиваются на клиент вместе с представлениями, а потом в этой таблице, обернутой в объектную оболочку, идет поиск...

Быстрый поиск долго работает, например при вводе с клавиатуры в справочнике

Вообще тормоза связанные с поиском по базе

(14) Открой на клиенте диспетчер задач во время долго работающего поиска и посмотри на загрузку сети. Может понятнее станет о чем я толкую в (13).

(8) для затравки :)

1. параллелизм для 7.7 бывает злом.... попробуйте установить его = 1
2. лог у вас долго пишется
3. явных сетевых проблемм вроде нет, по этому после решения пункта 1 и 2 можно уже смотреть профайлером конкретный запрос (и его план) при поиске.

(17)
1. База 8.2
2. Лог стоит "Simple"

Все просто - запускаешь SQL Profiler, ловишь долгий запрос, смотришь план запроса, исправляешь проблему.