Есть обработина, которая на основании некоих данных создаёт большую тучу документов. Дабы не плодить запросы в цикл было принято решение собирать данные одним запросом, а потом внутри цикла из полученных данных выбирать только необходимые строки. Всё бы ничего, но такая конструкция через несколько часов работы забила темпдб на сервере до 70 гб, после чего благополучно рухнула из-за нехватки свободного места. Подскажите, как можно избежать забивания темпдб?

    ТЧ_Обороты = ПолучитьОборотыВсе(НачалоПериода, КонецПериода, Организация, Договора); // получение данных по всем документам
    ...
    Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
        ОбработкаПрерыванияПользователя();
        Документ = ВыборкаДетальныеЗаписи.Ссылка.ПолучитьОбъект();
        //Документ.ПолучитьОбороты();
        Документ.ТЧ_Обороты = ПолучитьОбороты(ТЧ_Обороты, Документ.Договор); // отбор нужных данных по одному документу



Функция ПолучитьОбороты(ТЧ_Обороты, Договор)
    Отбор = Новый Структура("ДоговорКлюч", Договор);
    Строки = ТЧ_Обороты.НайтиСтроки(Отбор);
    Возврат ТЧ_Обороты.Скопировать(Строки);
КонецФункции

а если порциями?

научитесь пользоваться ТЖ или ms sql profiler.

"дабы не плодить запросы в цикл было принято решение собирать данные одним запросом, а потом внутри цикла из полученных данных выбирать только необходимые строки"

- враньё. напишите 1 запрос.

(0) из приведенного кода не следует, что темпдб забивает именно копирование таблицы значений. Но даже если есть 100% уверенность в этом, то что делает вот эта конструкция:
Документ.ТЧ_Обороты = ПолучитьОбороты(ТЧ_Обороты, Документ.Договор);
Что такое Документ.ТЧ_обороты???

(3) ТаблицуЗначений она возвращает, полученную запросом. Думал, это очевидно. Документ.ТЧ_Обороты - это переменная модуля документа:

Перем ТЧ_Обороты Экспорт;

(0) Можно попытаться не использовать МенеджерВременныхТаблиц или не создавать временные таблицы в запросе.

Ну или удалять временные таблицы в запросе.
А какой размер у самой БД?

Ну или почистить диск на котором хранится темпдб, чтобы все падало после 500 Гб.

(7) проще шринкать темпдб

(8) проживет до следующего запуска обработки

(9) я так понимаю это единичный случай

(10) нет

Ребята, запрос выполняется один раз, до цикла. ТемпДБ разростается при выполнении Функции ПолучитьОбороты(ТЧ_Обороты, Договор)
Там нет запроса, как видите

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

Можно полный путь к файлу темпдб выложить?

(12) в ПолучитьОборотыВсе это и есть, что дальше?

это и есть что дальше* без запятой

темпдб - это файл сервера SQL, как я понимаю. Не может на нем сказываться работа кластера серверов 1С без обращения к СУБД.

(4) я уточнял про левую часть.
Однако вопрос остаётся. Я один наблюдаю, что переменная ТЧ_Обороты в цикле пишется сама в себя?

И почему переменная зовется ТЧ_обороты, если это ТЗ? Похоже на наследование каких-то старых костылей

разбей ТЧ_Обороты на части, и ищи не в одной таблице, а в нескольких

прием

(19) прошу прощения,нет,не пишется.
Темп постепенно растёт или в какой-то момент?

(22) я так понял в цикле, можно шринкать

(19) так и есть, осталось в наследство

Я пока вижу один выход. Необходимо без всяких ТЗ делать заполнение документа при обходе запроса. Но, там слишком много и перемудрено всё. Придётся полностью переписывать модуль проведения документа.

(24) попробуй задание, каждые пять минут шринк

мне кажется у тебя большой своп начинается

(25) Что-то мне не нравится идея чистить скуль при активной работе с базой данных

https://msdn.microsoft.com/ru-ru/library/ms190768(v=sql.120).aspx

(27) это нормально )

>> попробуй задание, каждые пять минут шринк
Парни успокойтесь, сегодня не 1 апреля.

(30) +1

(24) я бы поставил на то, что в алгоритме проведения ТЧ_обороты отправляется во временные таблицы, с чем-то тяжёлым соединяется, и по каким-то причинам не освобождает память.
Ещё можно глянуть, что происходит с этим сеансом в консоли кластера. Колонка "захвачено данных" если не пустая и с растущим значением, значит,не удаляются временные таблицы.

Мне казалось, что любая ТЗ - это и есть временная таблица, создаваемая в tempdb. не?

(33) не уверен в этом.
Ещё: попробуй явно очищать Документ.ТЧ_обороты и сам Документ, когда они не нужны. Т.е. делать Документ.ТЧ_обороты = неопределено; документ=неопределено;

> Есть обработина, которая на основании некоих данных создаёт большую тучу документов. Дабы не плодить запросы в цикл было принято решение собирать данные одним запросом, а потом внутри цикла из полученных данных выбирать только необходимые строки.



какая сложность в написании одного запроса ?

(35) Грубо говоря, при проведении документа, выполняется запрос (на самом деле несколько), который выгружается в ТЗ и эта самая ТЗ используется в нескольких местах, для получения различных данных и формировании проводок. Чтобы как-то без сильного вмешательства ускорить этот процесс, было сделано (0). Но, похоже, всё-таки придётся переписывать всю логику проведения документа :(

(0) Открыта одна транзакция на все время выполнения алгоритма, который работает несколько часов?

(37) да

(37) несколько суток, если быть точным :)

(38) после выяснения такой пикантной особенности, дальше советовать что-нибудь нужно?

(40) Скажи, разве проведение каждого документа не происходит в отдельной транзакции? В 7.7 было так. Со снеговиком не уверен

(41) Нет слов.

(41) ты же только что сказал, что на все время работы алгоритма открываешь явную транзакцию о_О

(39) лицорука....

(43) Да, вот в том-то и дело, что пробовал по всякому и пытался всё сделать в одной транзакции и порциями по 20, по 100 документов. всё-равно, быстрее всего выполнялось без использования каких-либо транзакций

(45) Между ними успевали зафиксироваться транзакии из очереди. Они, нехорошие такие, отъедали время.

(45) Вообще, при проведении документа откырвается неявная транзакция.

"Подскажите, как можно избежать забивания темпдб?" - делать транзакции короче.

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

Пятничная темка, 1Сергей ты сделал мой день :)

(45) дак есть сейчас явная транзакция или нет?

(47) я про это и спрашивал в (41). И я рад, что у тебя появились-таки слова :)

Я еще с (21) сижу жду.

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

Код явно выполняется в толстом клиенте. Следовательно, темпдб может расти за счёт временных таблиц или результатов запросов. ЕМНИП ТаблицыЗначений лежат в оперативе, в данном случае - клиента. Транзакции увеличивают ldf самой базы, но не темпдб.

(53) так чего хочется и что не работает?

(54) Бесполезно, уже объяснял.

(53) правильно, это ещё один аргумент в пользу врем.таблиц и результатов запросов.

(54) хотя не это

(55) хочется ускорить обработку. Всеми доступными средствами

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

(59) т.е. проблема с темпдб уже решилась?
Про ускорение - один рецепт на все времена, "замер производительности".

(60) Не прав. 65% занимает выполнение запроса при провдении. Когда я выполнение запроса вынес за пределы обработки проведения, и сделал один по всем документам, с отбором строк (см(0)), обработка значительно ускорилась. Но, возникла проблема с темпдб. Правда, я не уверен, что темпдб был маленький до выполнения обработки. Просто при выполнении обработки кончилось место на сервере. И всё прервалось. Напоминаю, обработка выполняется несколько суток

(59) Проиндексируй ТЗ. У тебя наверняка там несколько сотен тысяч строк? Вот на этом тупит 1с.

(63) если не миллионов. Хорошо. Про индексацию я как-то забыл, да

(64) после индексации ещё раз прогони обработку с замером производительности на небольшом количестве документов. Скажем, после 1000 выйди из цикла. Может, удастся ещё что оптимизировать. Обычно когда один тормозной кусок приводишь в порядок, выползает следующий, который тоже можно причесать.

(64) а зачем тебе вообще эти отдельные тз для каждого документа? Может их вообще не создавать, а просто тянуть данные из исходного большого тз?

(66) ТЗ вообще не нужна,нужен один грамотный РезультатЗапроса, но вопрос был не о том))

(67) Запрос составить не проблема. Проблема переписать весь модуль проведения документа под этот Запрос

(68) я имел в виду немного другое. Вместо генерации одной большой ТЗ,как сейчас, можно переписать исходный запрос. На предпоследнем уровне будет Договор+Документ, а в детальных записях - уже сами строки для ТЧ_Обороты. Это вместо НайтиСтроки и необходимости держать всю ТЗ в оперативе. Минус - выборка будет лежать в темпдб до окончания обработки. Но она и сейчас там лежит, а плюсом - большая ТЗ в оперативе на клиенте.

(69) это не отменяет того, что я написал в (68) :)
Я тоже имел в виду такой запрос, без использования излишних ТЗ

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

Во, нашел в тему.
https://habrastorage.org/getpro/habr/post_images/ddc/66f/d60/ddc66fd60747788acc50b4cda7eedfad.jpg

(71) а как ты предлагаешь из детальных записей собирать ТЗ? Перебором чтоли? И чем это лучше "Скопировать"? Уж, не быстрее, это точно

(0) Придется пожертвовать временем и отбирать все более детально, по каждому контрагенту, если нужно по каждому договору в отдельности :)

А так, стоит подумать об добавлении какого либо регистра для заранее подготовки нужных данных :)

(18)>>Перем ТЧ_Обороты Экспорт;
1)А зачем в этом случае вообще передавать эту переменную в качестве параметра? она и так будет доступна в функции
2)Зачем вообще нужна функция?
//Документ.ТЧ_Обороты = ПолучитьОбороты(ТЧ_Обороты, Документ.Договор);// отбор нужных данных по одному документу

//СП
//Вариант синтаксиса: Скопировать по отбору
//Синтаксис:
//Скопировать(<ПараметрыОтбора>, <Колонки>)
Документ.ТЧ_Обороты = ТЧ_Обороты.Скопировать(Новый Структура("ДоговорКлюч", Договор));

*(75) Документ.Договор конечно

(75) Видимо, я не дочитал СП :)
Ну, сути это не меняет

(77) надо переделать получение данных, вернее время получения, для проведения или записи данные уже должны быть готовы

время получения по оси времени*

(78) Андрюха, вот что ты сейчас имел в виду? "данные уже должны быть готовы"... проведение любого документа подразумевает сбор данных (как правило запрос) и запись данных (в регистры и прочие места)

(73) тут куча вариантов. Перебором, скорее всего, будет медленнее, на несколько секунд в твоих условиях (гигантская ТЗ). Зато позволит не уронить процесс, когда объём памяти для выгрузки результата запроса перевалит за 2-3 ГБ.
Ещё можно выгружать все в ДеревоЗначений, и в глобальную переменную документа передавать СтрокаДереваСДоговором.Строки. В зависимости от того, что написано в модуле документа, это может и сработать. Ещё один вариант того же самого :
Документ.ТЧ_Обороты = ТЧ_Обороты.НайтиСтроки(Новый Структура("ДоговорКлюч", Договор));
Т.е. передаем не новую ТЗ, а Массив строк из исходной, сэкономив на выделении памяти под каждую новую ТЗ.
Но можно остановиться и на том, что сейчас, главное, таблицу проиндексировать.

(81) >>Зато позволит не уронить процесс, когда объём памяти для выгрузки результата запроса перевалит за 2-3 ГБ

Проблема как раз в неэфективном использовании памяти. На сервере 16 ГБ, 12 из которых не используются.

Все остальные варианты подразумевают переделывание логики проведения. Если уж её переделывать, то по правильному. Этот вариант я написал здесь и не раз

ладно, тема ушла в пустой трёп. Что мне нужно было, я выяснил

(80) есть короткий сбор данных, а у тебя долгий, сократи это время, кто тебе мешает наплодить дополнительных сущностей, а потом юзать их при проведении?