Мое почтение!

Привели клиентов, пожаловались неприемлемо низкую производительность
при обработке больших массивов. Причина - повсеместные вызовы
НайтиПоНаименованию() без указания режима поиска по точному
совпадению, при этом никакой необходимости поиска по совпадению
начала строк нет.
Трассировка показала, что вызовы вида

select * from SC1234(NOLOCK INDEX=DESCR) where DESCR>='абвгд' and substring(DESCR,1,5)='абвгд' order by DESCR,ROW_ID

очевидно, в разы медленее поиска по точному совпадению.
Кроме того, хинт на индекс создаёт очень затратный план,
в котором букмаркинг пожирает 90%!

Увы, написано скверно - невозможно централизованно
и оперативно поправить код; вместо процедурной реализации
он тупо многократно дублируется, при этом ещё обитает во внешних
обработках; вызовы направлены к 4 линейным справочникам, содержащим
миллионы записей. Короче, быстрый и надежный рефакторинг
невозможен :( Решение, севствено, именно сейчас сособенно нужно
быстрое.

Сам экземпляр сервера содержится в порядке, статистика,
дефраги регулярно, железка достойная.
Пр анализе плана замечено, как писал выше, что
букмаркинг пожирает 90%. Поискал, есть ли возможность принудительно
отключить подсказки на оптимизацию - оказалось, таки да!

Depending on your circumstances, there is quick and dirty way to turn off hints for a single user connection, or for an entire SQL Server. This is done without changing any code. Here’s how:

DBCC TRACEON(8602)

This above command is used to turn off all index hints for the current connection. So after running this command, any Transact-SQL code run will ignore any index hints.

Сделали DBCC TRACEON(8602, -1)

Сервер позволяет, выделен только под 7.7

На тестовом экземпляре включили - производительность в разы выше по
"родным" планам сервера. Другие пробные нагрузки как минимум не хуже.
Хочу уточнить - никто не пробовал такой трюк?

Что за черт?! Я точно, я уверен - я выбрал раздел v7!?
Модераторы, плз - перенесите тему, я признаюсь, что я балбес.

Правь код, не выеживайся

(0) Если этот запрет затрагивает только индексные хинты то все ок,
ну а если уберет и nolock то не взлетит.

правда на мой взгляд именно этому запросу из (0) это не поможет,
а в целом даже нехило поднимется производительность
за счет немешения выбора самому sql серверу нужного индекса.


"вместо процедурной реализации
он тупо многократно дублируется, при этом ещё обитает во внешних
обработках; вызовы направлены к 4 линейным справочникам, содержащим
миллионы записей."
так перепиши на 1с++

"Хочу уточнить - никто не пробовал такой трюк?"
если будешь делать на боевом сервере то отпишись  please

(3) - ну. риторические выступления на тему как и почему до такой жизни дошли, уже были - и 1с++ обсуждали, и переход
на 8, и много чего ещё :)
Но всё это вопросы месяцев, а "вот сейчас особенно нужно".

Указано, что данный флаг действует только на хинты по индексам, по локам - отдельный.
В том-то и дело, что по этому запросу помог - хронометраж
не обманешь. Потестируем ещё день, и попробуем на проме.
Что получиться - сообщу.

(4) помогает потому что по кластерному индексу запрос бежит
быстрее чем по индексу DESCR а просматривать придеться практически всю таблицу.
вот на букве 'я' descr может и обгонит но когда хинта нет
то sql сервер сам разберется на основе статистики когда какой индекс лучше взять.

я же имел ввиду что сам запрос в целом "плохой".

мне очень интересна эта тема, ждем продолжений

(6) ИХМО думаю что взлетит и очень нехило,
что видно даже по запросу из (0)

запускать экземпляр сразу с отключением в командной строке ?

(8) в 0 написано что дейстует для теущего соеденения.
т.е. загрузил 1с++ и сразу выполнил.

(9) предлагаю отключать сразу при запуске сервера в строке запуска

http://msdn.microsoft.com/ru-ru/library/ms162819.aspx

(9) действует, в зависимости от вызова, на уровне экземпляра сервера. параметр -1

You can set traceflag 8602 globally in a couple of different ways. One is to use a second parameter of -1:

DBCC TRACEON(8602, -1)

Now when you run the following, you should see that 8602 is set globally:

DBCC TRACESTATUS(-1)

(The -1 for this command means to show the status of all enabled traceflags.)

You can also set a traceflag globally through the SQL Server Configuration Manager. Right click your SQL Server service and choose Properties. Then go to the Advanced tab. There will be a text box for startup parameters, and you can add a semicolon to the end of what's already there, and then add -T8602. Do not leave any spaces between the semicolon and the dash. You'll then have to restart your SQL Server service

ну и конечно предупреждение о том, что фича может не поддерживаться в следующих патчах и тем более версиях.

(12) и еще есть оговорка -T и -t разные ключи

вопрос "монстрам" - а поиск в справочниках то же будет скорее быстрее ?

+(14) И где еще станет быстрее. А то я из описания не понял. И безопасно ли все это

А то я с будуна "БыстрыеИтоги" подключил, и левые остатки получил

(14) без sql запроса трудно что либо сказать.

http://x-romix.narod.ru/vk_hook1C.rar

поможет автору

"а запрет хинтов" - выдает непрофесионала.

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

если идет постоянное обращение в этим справочникам, то они должны были закешироваться давно уже
может тупо оперативки добавить скулю для кеширования

(18) Расскажешь ?

(20)так секретный релиз же

(21) не смотрел его т.к.  используем легальный sql2000.
Вроде subj и секретный релиз могут дополнять друг друга.

(21) все еще запрещены или отказался по каким то причинам ?

(19)дело не только влезет таблица  или нет в память,
а в том что subj снимает нагрузку(часть нагрузки) с самого sql сервера.
смотри например статью
Примеры «тяжелых» запросов в системе 1С 7.7.
Автор Владимир Сердюк
http://www.sql.ru/articles/mssql/2005/101904hardqueryin1c.shtml
вот для таких запросов и запроса из 0
subj очень поможет.

(24) а когда ищешь в справочнике набирая, запросы валятся такие же (почти) как в сабже + на каждое нажатие кнопки

+ к тому - сабж снизит нагрузку при поиске в справочнике штатным механизмом ?

(25) Ну значит тебе это поможет.
(26) да снизит

(23)что запрещены?

(28) подсказки

(29)не, вырезаются хинты напрочь. Зачем отказываться от вырезания? В них смысла особого нет.

(30) т.е. хинты таки вырезаны в твоих базах ?

(30) Могу сказать как еще можно в sql2008 поднять производительность.
сам проверить  не могу т.к. нет sql2008

(31)ну

+33 индексные хинты, блокировочные на месте остаются

(0)
извиняюсь за непрофесионала
думал нинты к блокировкам

(32) Как ?

+(36)
Твои посты про "1с++ sql Native Client " читал

(36)для sql2008 и выше в таблицах rg для поля PERIOD
заменяем тип datetime  на тип  date.
---------------------------
для sql2000 , sql2005  rg для поля PERIOD
заменяем тип datetime  на тип  smalldate.
это успешно работает и есть моя статья об этом на 1cpp.ru

(37) это можно-нужно делать на любом sql начиная с sql2000

(38) Спасибо, почитаем

в 38 вместо  smalldate надо  smalldatetime

(38) пожалуй да

(38) "это успешно работает и есть моя статья об этом на 1cpp.ru"

Можешь дать ссылку. Загуглить не удалось

ну еоли речь по такие тонкости, то

можно еще collation поменять на регистро зависимый
тоже дает эффект быстродействия

(43) статья Ускоряем регисты v77 для базы MS SQL
http://www.1cpp.ru/forum/YaBB.pl?num=1291788964

(43)
Нашел
http://www.1cpp.ru/forum/YaBB.pl?num=1291788964/0

(45) Благодарю

Провели включение режима на проме, всё пока работает.
По целевым задачам - да, заметное ускорение.
Остальная функциональность, что ожидаемо, остались примерно
на прежнем - ну, если только транзитный эффект от высвобождения мощностей :)
Собственно, хинты на индексы - в 1С нечастое явление,
судя по трассе. На выборке справочников по наименованиям,
кое-где на отборах.
Кстати, от построения курсора через индекс+закладки
сервер, понятно, вовсе не отказываетя, просто в нашем случае
ожидаемые большие звездные (*) выборки, например, тащит из
кластерного индекса.
В очередной раз убеждаюсь, что, в общем случае, хардкодить
хинты просто категорически нельзя. Обязательно хотя бы
опциональная возможность использование или отказа от
рекомендуемых.

Я тут подумал и пришел к выводу что запросы из 0
когда идет работа под sql2005 или выше - это и есть причина основных "тормозов" ( независимо от выставленного уровня совместимости бд).

Дело в том что в  sql2005 и выше  более "умные" оптимизаторы запросов и на такой "тупой" ( из 0) запрос  тратится очень много времени (точнее ресурсов) чтобы составить оптимальный план выполнения запроса.

Вывод для sql2005 2008 2012 эта тема еще более актуальней
и надо применять или (0) или (30)

(49) вопрос по смене типа поля period - при смене на date все конечно вполне работает, но пока не выйдет последний - т.е. до верификации, при старте не проходит проверку на целостность.
При смене на smalldatetime - все ок, это конечно вполне объяснимо.
Да и всегда ли операции сравнения между типами date и datetime выполняются ?
И еще smalldatetime и datetime вполне неявно преобразуются в char, date нужно преобразовывать только явно.
smalldatetime диапазоном от 1900 до 2079, а datetime от 1753 - эта дата часто в 1с используется как дата отсчета и пустая.

Как это все (по наблюдениям) не повлияло на верность работы 1с ?

(50) Просто у меня все критические отчеты по rg ( где нужна скорость)
переписаны
через прямые запросы и там уже стоит нужный тип данных.

про неявное преобразование к char по моему Вы не правы -
но это не критично если Вам легче представлять что работает так
то считайте что это так.

да ошибка, не к чару а наоборот, преобразование к датетайму при сложении с интом

select 100+cast(CURRENT_TIMESTAMP as smalldatetime)

select 100+cast(CURRENT_TIMESTAMP as datetime)

select 100+cast(CURRENT_TIMESTAMP as date)