#0
by e053nk
Здраствуйте. База Альфа авто ред.5, работает под платформой 8.2, на SQl 2012. Ситуация следующая: в одно прекрасное утро (несколько месяцев назад) стали долго заполнятся новые документы при вводе на основании.Время ожидания может достигать 5-7минут. Обычно в течении максимум пары секунд-документ уже сформирован. Так как В Альфе Кусок ода закрыт от просмотра, диагностировать до конца отладчиком причину не получается. Выходом (что бы не перезагружать сервак SQl или 1с) является только запуск перестроения индекса и обновления статистики средствами SQL (Причем именно последовательно и вместе-в другом варианте не срабатывает). Поисходит обработка всех таблиц базы данных- а это довольно длительный процесс и в момент выполнения -база 1с подтормаживает. Хватает этого на разные отрезки времени от нескольких часов до нескольких суток. Причем чем дальше-тем короче период возникновения сабжа (примерное наблюдение). Для ускорения работы этогомеханизма хочу отловить таблицу(-ы) которая наиболее нужны в обработке и написать задание в SQL именно обработки этих таблиц-должно быстрее обновляться . Кто знает, каким скриптом SQl можно получить таблицы -котрые наимболе нуждаются в обработке?
#3
by ДемонМаксвелла
ты лучше посмотри, какие запросы на SQL сервере выполняются, когда ты проводишь докуменнт
#4
by Вафель
А неэффективные индексы - это индексы, которые места занимают много, а используются мало раз. Но они никак не скорость выполнения запросов не влияют. Разве что на запись
#6
by e053nk
Проблема не в процессе проведения, а в процессе ввода на основании. Запросы я пытаюсь поймать -пока каша какая та...
#9
by Ц_У
Можно я тут спрошу быстренько? :) В окне показателей производительности: Вызовов 1 время 0.02 отправлено 200 получено 300 Сам вопрос: отправлено НА сервер или ОТ сервера, получено сервером или клиентом? Исходя из контекста что это серверные вызовы, то, думаю, что сервер получил 300 и вернул 200. Или нет?
#10
by SSSSS_AAAAA
"Выходом (что бы не перезагружать сервак SQl или 1с) является только запуск перестроения индекса и обновления статистики средствами SQL (Причем именно последовательно и вместе-в другом варианте не срабатывает)." Поставьте выполнение сего в ночной джоб/задачу планировщика винды.
#11
by e053nk
Ночью набор регламентов выполняется -проблема может возникнуть через пару часов работы
#12
by МимохожийОднако
Замер производительности делал? Видно какая процедура или строка кода больше всех кушает? ТИИ?
#13
by dubraver
Есть несколько способов которые я использовал на практике для поиска "тяжелых" запросов: 1. Чтобы поймать в sql profiler'e длительные по времени запросы, необходимо создать трассировку с фильтром по показателю duration (в миллисекундах больше или равно), а события выбрать RPC:Completed и SQL: BatchCompleted. Мне таким образом удалось поймать все длительные запросы к базе, и понять какие механизмы требуют оптимизации. 2. Также в Вашем случае вполне возможно что возникают блокировки таблиц, их можно поймать выполнив процедуру sp_locks на базе, в которой Вы работаете, в тот момент когда "подвисает создание докуменов на основании".Процедура Вам вернет заблокированные объекты БД. Через DBID с помощью функции DB_Name Вы найдете наименование таблицы в БД, а через обработку "ПосмотрМетаданных.epf" вы найдете наименование таблицы в конфигурации 1С.
#15
by e053nk
Самый долгий вызов процедуры-уходит в защищенный модуль, и собственно посмотреть что там дальше происходит-почти не получается..
#16
by e053nk
Подниму тему. Ситуацию поймал при зависании ввода на основании. Профайлером Sql снял информацию ,что происходит в этот момент. нашел самый длительный запрос-71сек. (фильтр по длительности более 2сек поставил, остальные запросы от 2 сек до 10 сек по времени и их очень много). Сам пока не очень разобрался в записях профайлера-может кто поможет из более опытных людей-что там в этом самом длинном запросе тормозит?
#17
by Йохохо
надо поискать обработку которая гуглится по "1с получить структуру хранения метаданных"
#18
by e053nk
Таблицы 1с , участвующие в запросе , я нашел. Не пойму что дальше делать. Один и тот же запрос 1с отрабатывает по времени по разному до перестроения индексов и после. Как проанализировать на чем спотыкается и тормозит запрос?
#19
by Йохохо
хз, мб кто поправит смотрим на запрос из 5 и видим (раз) два условия на НеРавно не по кластерному индексу и (два) соединение потом по не ссылочному типу. Из (раз) получаем два скана долгих по не кластеру и потом цикл по кластеру. Из (два) в довесок получаем тяжелую сортировку для соединения
#21
by Йохохо
а перестроение вероятно дает сортировку как бонус. И пока не испортится во время работы распределение индекса, то есть статистика, все шуршит
#24
by H A D G E H O G s
Оперативный СрезПоследних там у вас, без Итогов. Но могу ошибаться. Добавьте галочку "итоги по срезу последних" или избавьтесь от необходимости срезапоследних по методике Ненавижу1С
#25
by H A D G E H O G s
Но лучше найти наименование регистра сведений с помощью обработки структуры таблиц 1С и глобальным поиском по конфе найти все запросы по срезам последних(первых, но вряд ли), проставить точки останова и дождаться воспроизведения. И прислать текст запроса и структуру регистра сюда.
#32
by e053nk
Сейчас опять попал на тормоза ввода на основании документа. Методом перебора попробовал отобрать таблицу из которой притормаживает. Начал с самого длинного запроса и сразу угадал. текст запроса: Самыйдлинныйзапрос 71271мс РегистрСведений.РегистрацияВремениРабот exec sp_executesql N'SELECT T1.Q_001_F_000RRef, T3.Q_002_F_001RRef, T3.Q_002_F_002_ FROM (SELECT T2._Fld7406RRef AS Q_001_F_000RRef, MAX(T2._Period) AS Q_001_F_001_, T2._Fld7411 AS Q_001_F_002_ FROM _InfoRg7405 T2 WITH(NOLOCK) WHERE (T2._Fld7408RRef = ) AND (T2._Fld7407RRef <> @P2) GROUP BY T2._Fld7406RRef, T2._Fld7411) T1 LEFT OUTER JOIN (SELECT T4._Fld7406RRef AS Q_002_F_000RRef, T4._Fld7407RRef AS Q_002_F_001RRef, T4._Fld7411 AS Q_002_F_002_, MAX(T4._Period) AS Q_002_F_003_ FROM _InfoRg7405 T4 WITH(NOLOCK) WHERE (T4._Fld7408RRef = @P3) AND (T4._Fld7407RRef <> @P4) GROUP BY T4._Fld7406RRef, T4._Fld7407RRef, T4._Fld7411) T3 ON (((T1.Q_001_F_000RRef = T3.Q_002_F_000RRef) AND (T1.Q_001_F_001_ = T3.Q_002_F_003_)) AND (T1.Q_001_F_002_ = T3.Q_002_F_002_))',N' varbinary,@P2 varbinary,@P3 varbinary,@P4 varbinary',0x00000000000000000000000000000000,0xA4A10D6407153BC548BAFB0D700F8CFA,0x00000000000000000000000000000000,0xA4A10D6407153BC548BAFB0D700F8CFA" Поставил в SQL пересоздание индекса только по этой таблице,отработало быстро-сек 5 наверное. После этого документ стал вводится достаточно быстро. Приведенный запрос отработал за 258 мс-и он самый длительный из цепочки запросов. Поэтому пока поставлю в планы обслуживания SQL задание на перестроение индекса этой таблицы раз 3 часа -понимаю,что это костыль, но пока времени нет плотнее заниматься. Вызов это запроса формируется (как я понял) где то в закрытом модуле, я его расположение примерно увидел,но переделывать пока не придумал как.
Тэги: 1С 8
Ответить:
Комментарии доступны только авторизированным пользователям
Похожие вопросы 1С
- Не подскажите, где на сайте 1С посмотреть сертифицированных специалистов?
- 1cv8 SQL: Имя SQL сервера и имя SQL базы данных
- Где посмотреть соответствие имен таблиц SQL и 1С
- Как посмотреть фрагментацию индексов в sql 2000?
- Видел обработку под 77, где можно было скачать с сайта 1С список спецов,Где ее найти?
- УПП : Где посмотреть базу закрытия 25 счета?
- Счет УСН 01 при реализации где то выходит где то нет
- v7: Как в 7-ке при обновлении увидить,где были изменения поставщика где других прог
В этой группе 1С
- Ошибка выполнения отчета СКД
- УФ. Как передать выбранные строки с учетом отбора на клиент?
- Атол 11Ф Операция запрещена в таблице настроек
- Сведения о распределении численности работников по размерам з/п за 2017 ЗУП 2.5
- Условное оформление группы колонок СКД
- УТ 10.3 Не списано по партиям
- УТ11.2 - Помощник оформления складских актов
- ЗУП 3: отмена отпуска
- Связь по типу данных
- Работа с ФИАС на обычных формах 1с 8
- Детализация на СКД
- Порядок вызова процедур в расширении... Не порядок
- Нумерация строк группировки СКД
- В "Рознице" 2.2 не работают Скидки в Чеке в РМК и в обычном режиме
- Ввод остатков по 68.04 и 68.02, УПП
- SQL. Обновление. SDBL
- v7: Дополнительный глобальный модуль
- КА 2.2 Ввод начальных остатков по счетам 60.21, 60.22, 62.31 и 62.32 (валютки)
- УПП Учет спецодежды, временная разница
- Как поменять ГУИД у документа?