Помогите разобраться с SQL #637033

В наличии: УТ        11.0.8.8 Контора сидела на файловом варианте. По причине некоторых проблем решились перейти на скуль. Поднял все это безобразие и повылезли странные чудеса. Все отчеты стали выполняться очень медленно. Тренировался на Движении по складу. Что по одной номенклатурине, что по всему складу время выполнение составляет 6-7 секунд. Ну, думаю, чудеса. Лезу в профайлер а там секунд 5 идет перебор конфиги (ну насколько я понял) запросами Меняется только последний параметр. Запрос отрабатывается за несколько милисекунд, однако таковых несколько тысяч, что и дает тормоза. Настроил технологический журнал по части обращений к СУБД. В логах эти же запросы повылезли, т.е. идут они из 1С. Ну и собственно вопрос, как от этого дела избавиться? Покопался в настройках сервера 1С, конфиги, самой базы, ничего и близко на эту тему не нашел. Да, фоновые задания все застопорил перед тестом.

Через отладку проверил отчет? Именно в запросе застопорился?

спроси у :)

прикольный запрос

я не один это вижу? в запросе есть "href="http://www.forum.mista.ru".. ?

см

чет не могу юмора догнать...

посмотри, в табличке CONFIG есть строка с FILENAME = registered-user

Пардон, на обед убегал. Отчет наистандартейший и работает спокойно с нормальной скоростью в файловом варианте. Это касается и остальных отчетов. Миста прикололась однако :) Запрос выглядит так: exec sp_executesql N'SELECT Creation,Modified,Attributes,DataSize,BinaryData FROM Config WHERE FileName = ', N' nvarchar', N'2914af3c-ad8f-4719-8871-98d1a256b3fb' Посмотрим, как без обрамления запрос Миста отрисует :)

Во, так правильно. В запросах меняется только '2914af3c-ad8f-4719-8871-98d1a256b3fb', все остальное один в один.

Мда, спецсимволы миста таки переварила. Там ессно собачкаP1 :)

это скорее всего установка параметра сеанса пользователя. Не туда копаешь.

Открыл базу. Открыл отчет. Запустил трассировку скуля (окно почти чистое). Нажал "Сформироовать". Дождался окончания формирования. Остановил трассировку. Что я делаю не так? Именно во время формирования отчета появились запросы такого вида. Причем сначала идут они, и только в конце формируется собственно отчет. У меня даже грешным делом появилась мысль, что табличка конфигурации не индексирована.

запусти трасу, войди в базу, останови трасу, увидишь те же запрросы exec sp_executesql N'SELECT Creation,Modified,Attributes,DataSize,BinaryData FROM Files WHERE FileName. Возможно это считывания кэша, параметров сеанса пользователей, его настроек. Лучше  из отладчика сделать замер производительности.

Я видел такие запросы, когда полную трассировку делал, от запуска базы. Но зачем эта хрень при формировании отчета? Откуда она вообще взялась? И как ты из отладчика сделаешь трассировку, если отчет на СКД нарисован?

били такие темы. но без решения поделитесь файлом трассировки и результатом   SELECT Creation,Modified,Attributes,DataSize,BinaryData FROM Config WHERE FileName мне интересно, понять 1c "зацикливается" и сканирует всю конфигурацию или доходит до определеного метаданного и на чинает цикл заново. или сами проанализируйте и поделитесь результатом.

кстати, Вы нашли способ обновлять кофигурацию серверных процессов в любой момент.

Русфолдер какой-то совсем неторопливый... ссылка на файл трассировки скуля. По моим ощущениям он всегда перебирает все метаданные и только потом начинает что-то делать. Это вопрос или утверждение? И не понял малость, об чем речь...

а булочку ?(шутка) а резултат SELECT Creation,Modified,Attributes,DataSize,BinaryData FROM Config иначе не выяснить все или не все. в (16 )речь про обновлении конфигурации в произвольный момент. без остановки работы. те извенили конфигурацию запустили отчет и конфигурация обновилась. понятно, что только на одном рпхост.

извенили = изменили

Вечером еще погоняю, с работы не подключиться.

сколько записей в таблице Config ?

Я по базе только вечером смогу отписаться, сейчас к ней доступа нет.

традиционно нагрузка на сервер какая? на сервере режим электропитания выставлен в максимальную производительность?

Все нормально там. Однако чудесны дела твои, Господи... Вопщем причину подобных грабель я нашел. Вернее не причину, а действие, которое порождает подобные тормоза. Выключаю полнотекстовый поиск и о, чудо! Все начинает летать! Блин... Что же я опять сделал не так??? Или что надо было сделать с базой, чтобы включенность полнотекстового поиска так на ней сказывалась...

ТиИ помогло... Все-таки что-то у меня неправильно понимается в этой 1С блин.

Помогло оно не надолго. После перезагрузки машины все вернулось на круги своя... И ТиИ уже не помогает. Самое интересное, что при каждом ТиИ вываливаются все объекты конфигурации с надписью "Объект изменен: ПланОбмена.ОбменВнешнимиЗаданиями" Уже не пойму в какую сторону копать. Такое ощущение, что SQL какую-то информацию упорно не желает сохранять и поэтому возникают такие переборы данных.

"Такое ощущение, что SQL какую-то информацию упорно не желает сохранять "   Все вопросы к .... масштабируемому серверу приложений. Продукт коммерческий и закрытый.

+ Из аннотаций к серверу СУБД MSSQL 2005 . "Сервер расширен на функционал позволяющий ..... делать оценки блаааа блааа  что "посылает" приложение (в данном случае сервер приложений 1С) серверу СУБД и ..... на этом основании можно предъявлять вопросы  к разработчикам приложений о качестве его работы. Ну в таком духеееееее

сколько рабочих процессов запущено ?

4 штуки. Сдается мне надо будет попробовать сменить версию 1С, может в ней трабла.

Кстати вопрос. Ключ сервера программный. Если сменю версию следующий пин придется использовать или старый подхватится?

я-бы начал с полной реиндексации средствами 1с а потом скуля, и запустить чекдб на скуле. сдается мне что тут или задвоение ключа или что-то с индексированым поиском

Реиндексацию через 1С делал, ибо именно на индексацию грешу. Вечерком поковыряю сам скуль. План работ то есть, только вот результат блин не прогнозируется... Не люблю так :)

к сабжу скорее всего не относится но все-же почитай

Да, похоже не то, но полезная инфа :) Жаль с работы к той косячной базе подключиться не могу. Чувствую выходные удадутся.

установил УТ 11.0.8.8 в файле трассировки в указан отбор ~4500 записей из таблицы конфиг а в УТ 11.0.8.8 в таблице конфиг ~9600 записей

Жутко извиняюсь, там 11.0.8.11 версия, только вот сдается мне, что от релиза конфигурации ничего не зависит. Последние вести с полей: Воткнул платформу 8.2.16.368. Опыт показал, что поведение не изменилось. Все работает до тех пор, пока не построишь индекс полнотекстового поиска. Как только строю индекс - происходит что-то необратимое, и удаление индекса уже ничего не дает. Одно занятное наблюдение. Методом научного тыка, при повторно отключенных индексах ПП (т.е. отчеты тормозили), решил попробовать сменить кодировку базы из SQL. Менялось без проблем, только вот конфигуратор естественно нехорошо ругался. Ну и не пускал. Когда вернул родную кодировку отчеты опять заработали нормально. Но индексация ПП опять все сломала. В таблице Config 9770 записей на данный момент (база малость допилена). Да, из предыдущих советов. CheckDB ошибок не нашел. Реиндексация ни та, ни другая не помогла. Самое противное в описанном то, что я даже какой-нибудь идиотской гипотезы о связи индекса ПП и поведением отчетов не могу придумать. Сегодня попрошу админов перевоткнуть SQL сервер, ибо больше не знаю что попробовать изменить. Конечно, есть ощущение, что это не поможет, но больше вариантов придумать не смог. В SQL реиндексировал, обновлял статистику, паковал таблички, чистил процедурный кэш. Все бестолку. Думал почистить журнал транзакций, но в 2008R2 при простой модели восстановления это делать не надо. Во, осенило, сейчас попробую демку 8.11 воткнуть чистую, только даже если заработает - непонятно что это мне даст...

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

Рекструктуризацию ИБ делал? Вроде бы рекомендуюется при смене СУБД.

Там в той таблице чудеса, там леший бродит. Но посмотрю, может пойму, что за объекты сканирует. Да, естественно, прогонял не один раз.

при построении индекса 1с натыкается на ошибку потока в метаданных не обрабатывает её. при этом индекс по метаданным остается помеченным как не обновленный. при обращении пытается перестоить и так по кругу.

А как можно выключить полнотекстовый поиск по объектам конфигурации? А оно при реиндексации при ошибке разве ничего не должна писать?

Да, еще, а если средствами SQL строить индекс эта проблема разве не должна уходить?

+ последний объект в трассировке Справочник.НаборыДополнительныхРеквизитовИСведений проверте его.

Нормально открывается, все данные видно. Основная масса предопределенные элементы... В конфигураторе тоже ничего особенного в нем не вижу.

+ модуль менеджера

Ну там три процедуры, ничего необычного не вижу.

Хм... База опять стала работать нормально, но поиск отключен. Попробую включить.

Вот еще забавный момент. Поставил галку использования полнотекстового поиска, но индекс не строил - реакция та же, тормоза.

Поставил галку, очистил индекс - заработало нормально...

по-моему там "битый" поток. в нем упоминается Справочник.Партнеры но понять где - не могу. при поиске ссылок на Справочник.Партнеры находится ссылка на Справочник.НаборыДополнительныхРеквизитовИСведений   но как увидеть эту связь в конфигураторе ?

Ну они некоторым образом связаны эти справочники. Увидеть просто. Открываем Партнеры двойным кликом, выбираем вкладку Данные, жмем кнопку Характеристики.

Справочник.НаборыДополнительныхРеквизитовИСведений он вообще много с кем завязан через план видов характеристик.

ну у меня 2 предположения 1. не та кодировка, где не знаю, вероятно в скуле, или в винде сервера... 2. зацикливание метаданных по которым строится индекс ПП для понимания проблеммы 1. ищи контору где все нормально, тащи туда свою базу и разворачивай там, если там все нормально - то это к админам, если нет к программистам 1с. После отделения зоны прог/админ начинай задовать вопросы дальше...

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

Вообще кодировку надо правильную выбирать при установке, попытки изменить что-то после установки влекут за собой проблемы, т.к. для базы tempdb все равно используется кодировка выбранная при установке. Видел видео Гилева, где он говорил, что из-за этого на каком-то предприятии произошла ошибка при расчете зп. Так что лучше переустановить sql.

Ну я ребят как раз и попросил перевоткнуть скуль. Скажу им про этот нюанс. Спасибо.

не факт что переустановка скуля поможет, например знаю контору где сервер в германии, так вот пока не поменяли их внешний IP на российский - нифига не ставилось нормально. Потом вернули немецкий и сейчас все пашет... Хотя конечно нужно читать про установку ДО самой установки :)

Ну установка скуля не на мне, там сертифицированные ребята вроде как, именно по скулю. Так что нехай оне и читают струкции :) Я только по 1С да операционкам малость разбираюсь. Впрочем пока буду решать эту проблему поневоле начитаюсь...

+ поток не битый. cd_tool не верно отображал. так что проблема не в этом