У меня есть запланированное задание, которое обрабатывает документы, хранящиеся в таблицах базы данных SQL. Он обрабатывает документы «по 10 за раз», перемещает данные двоичных документов в другую базу данных и работает непрерывно около недели. (требуется много документов)
Сегодня задание получило тайм-аут, и я пытался выяснить причину. Сначала я подозревал, что это может быть какой-то большой файл, но, похоже, проблема не в этом.
Вместо этого я заметил, что, похоже, возникла проблема с определенным столбцом, и это, похоже, столбец «имя файла». Этот столбец представляет собой просто тип «nvarchar», поэтому это так странно.
Я обнаружил, что если я просто прокомментирую столбец «имя файла», чтобы он не был частью выбора, тогда запрос будет работать. Если я добавлю его (а оно мне нужно!), то получу таймаут. Кроме того, даже если я не добавляю его в список выбора, а вместо этого добавляю его в «упорядочение по имени файла» или «группировку по имени файла», я также получаю тайм-аут.
Мой запрос, который возвращает около 3600 записей, приведен ниже. В примере, который я разместил ниже, я удалил «10 лучших». Однако результат тот же: при добавлении «имя файла» я получаю тайм-аут.
select
att.AttachmentId,
att.FileSize,
att.MimeType,
att.FileName
from Attachment att
join ActivityMimeAttachment ama on att.AttachmentId = ama.AttachmentId
join ActivityPointerBase apb on apb.ActivityId = ama.ObjectId
where apb.CreatedOn < (GETDATE() - 1095)
and att.Body is not null
order by att.FileSize desc
--option (recompile)
Просто кажется таким странным, что это начало происходить. Мне бы очень хотелось узнать имя потенциального файла, вызывающего тайм-аут, но ирония в том, что я не могу его увидеть, потому что добавление имени файла вызывает проблему. Но моя программа на данный момент без проблем обработала 1,8 миллиона файлов, и теперь внезапно это происходит..
Любые идеи и предложения приветствуются. Также стоит упомянуть, что я использую «Dynamics 365 Linq» для выполнения выбора, который преобразуется в этот SQL-запрос. Поэтому создание хранимой процедуры не вариант. Однако, возможно, я мог бы сделать некоторый индекс в базе данных, но, как я уже упоминал, до сих пор я без проблем обработал огромное количество файлов.
@jarlh Не совсем понимаю, о чем вы спрашиваете, но базы данных размещены на Microsoft SQL Server Enterprise. Я использую Sql Server Management Studio для написания кода sql.
Похоже, проблема в плохой индексации. Пожалуйста, поделитесь планами быстрых и медленных запросов через brentozar.com/pastetheplan, а также покажите таблицы и определения индексов.
Мне бы очень хотелось знать имя потенциального файла, который вызывает тайм-аут, но ирония в том, что я не вижу этого, потому что добавление имени файла вызывает проблему.
В JOB попробуйте получить выходные данные этого конкретного шага, используя «Выходной файл» на вкладке «Дополнительно» этого шага. Допустим, всего предполагается 3600 записей. Но имя файла не удалось с 1000 записями, тогда 1001-я запись будет причиной проблемы.
Сервер является производственным сервером. Несколько дней назад на сервере возникли проблемы, поэтому администраторы базы данных перезапустили его, добавили немного дискового пространства для файлов журналов и, возможно, сделали что-то еще. Самое странное, что после этой проблемы проблема с выбором данных исчезла. Запросы теперь выполняются без проблем, и написанный мною код работает так, как задумано. Я не знаю, что и почему проблема была действительно решена, но проблема, очевидно, заключалась в каком-то крайнем случае обстоятельств, о которых я никогда не узнаю.
Какие СУБД вы используете?