База 1с ТИС переделанный на 7.7 , скуль 2005.

неожиданно при работе одного отчета ( универсальный по докам выбирает разные доки по продажам с фильтрами по ка, манагерам, собирает суммы и кг отгрузки. В общем а ля олап) стал расти на скуле темп дб, да так, что при базе 120 гиг становится 140 и более..

от чего место на дисках заканчивается и все нафик валится.

Что с этим можно сделать?
очищать как-то темп дб. или настроить скуль чтобы этого не делал. от чего все это?

(0) очевидно исправить отчет

(0) Не знаю как в 77, но думаю так же как и в 8:
- Переписать запрос - где то слишком большая выборка во ВТ.
- Запретить запуск отчета без отборов
- Убедится что отборы накладываются туда куда надо

(2) Как показала практика пока этого было достаточно при подобной проблеме в 8

(2) ВТ?
- какие обороты в запросе по докам? отчет по полям доков

(1) так он 8 лет работал а счас стал работать непоймикак

(4) Я про обороты ничего не говорил.
ВТ - временная таблица.

(5) В какой то момент при накоплении данных такие вещи происходят, отчет который работал годами ломается.
Пока помогала только переписка.
Но я не спец по 7.7

Боюсь надо лезть в профайлер и смотреть что реально творится в SQL

Да здравствует ОЛАП на 77

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

для начала общую статистику глянуть, когда начинает пухнуть (а лучше в лог писать, каждые n минут)
типа
SELECT
    (SUM(unallocated_extent_page_count)*1.0/128) FreeSpace ,
        
    sum(user_object_reserved_page_count) * 8 / 1024 UserObjects,
    sum(internal_object_reserved_page_count) * 8 / 1024 InternalObjects,
    sum(version_store_reserved_page_count) * 8 / 1024 VersionStore,
    sum(mixed_extent_page_count) * 8 / 1024 MixedExtent
FROM
    tempdb.sys.dm_db_file_space_usage


Если 99% - InternalObjects, то я не знаю что делать :)
Боролись тут не так давно... как появилось, так и пропало, ничо не поняли...
Разве что версию SQL повысить.

lazy table spool приветствует вас, идущие на бой.

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

Сумма(ПолучитьСуммуПродаж(СуммаЗаяв,СуммаВклНДС,НДСЗаяв)) Когда (ФлагСписания <> 1)

(12) Не исключено.
(13) Попробуйте удалите этот код и проверьте, возможно оно

ну да

(14) Любопытства ради, можно код функции?

(4) все временные данные что не поместились в память могут быть сброшены в темпы.

(12) гы-гы-гы, ага

(14) жесть жёсткая... скорее всего 1с постоянно дёргает эту функцию... возможно там за кадром просто Содом и Гомора.... с темпами неявными...

может как-то можно выгрузить например в ТЗ а потом всё это обработать кодом?

(20) я не хочу лезть в этот отчем... это франями написанный инструмент для тиса еще 10 лет назад..

(20) она дергает эту функцию на каждой строке документа, которых 3000 в день, за период 2 месяца. при среднем числе строк в доке 30. вот посчитай.

но эту доработку без моего контроля сделал другой прог а я теперь этот караул разгребаю

Если не дорабатывать... только если темпы на более емкий диск пересилить.

Во-первых размер tempdb нужно ограничивать, уменьшить стоимость запроса в mssql. Посмотреть - какой размер tempdb песле перезагрузки сервера. Бывает, что эта проблема появилась после некорректного перезапуска сервера и описание такой проблемы и ее решение есть на официальном сайте Microsoft.

https://social.technet.microsoft.com/Forums/ru-RU/95a6c5a1-cf72-4c7d-9dce-0b85474f236b/108810721079108410771088-tempdb?forum=sqlru

И Гилев http://www.gilev.ru/forum/viewtopic.php?f=15&p=5032

(25) ограничение темп дб приводит к вылету 1с со скулевой ошибкой

(23) кросс-джойн какой-нить наверняка получился

(29) запросы в клюшках - вещь в себе. Без трассировки ничего определенного сказать нельзя

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

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

т.е. когда и сложные отчеты и текущая работа..


как-то модно понять, какие запросы в какое время эту базу разнесли?

В процессе работы 1С:Предприятия 8 возможно значительное увеличение размера базы данных TEMPDB.
Причина

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

    "Большие" транзакции, использующие TEMPDB, выполнение которых занимает большой промежуток времени.
    Сетевые ошибки, из-за которых Microsoft SQL Server не получает уведомление о потере сетевого подключения. Если клиентская рабочая станция зависает, перезагружается, или будет выключена во время исполнения определяемой пользователем транзакции, то Microsoft SQL Server будет считать, что клиент продолжает работу, и выполняющаяся клиентская транзакция будет по-прежнему активна. Время обнаружения подобной ситуации зависит от настроек параметров сетевого протокола, используемого Windows . Например, при использовании протокола TCP/IP это время составляет 2 часа.

Если для завершения активных транзакций не хватает места в базе данных, Microsoft SQL Server автоматически увеличивает размер TEMPDB на величину, заданную в параметрах этой базы данных (по умолчанию - 10% от текущего размера).

https://its.1c.ru/db/metod8dev#content:2374:hdoc

реконнект нативе?

(33) тут 7.7 (34) ??

(35) а там что-то про 8.Х?

(36) В процессе работы 1С:Предприятия 8 возможно