TempDB фиксированного размера (800 ГБ), MERGE в очень большую таблицу не удается из-за нехватки места, является ли это ограничением слияния?

Спасибо за чтение, я немного смущен этим, думаю, что это связано с размером TempDB, но не знаю, почему это происходит в этом случае:

У меня есть оператор MERGE:

DECLARE @LastUpdate DATETIME
SELECT @LastUpdate = ISNULL(MAX(LastUpdate),'1900-01-01') FROM dbo.StatusTable

DECLARE @CurTime DATETIME = GETDATE()

BEGIN TRANSACTION

    MERGE dbo.TableName AS targ
    USING
        (
            SELECT
                <fieldlist>
            FROM 
                JoinTablesEtc
            WHERE UpdateDateTime > @LastUpdate
        ) AS src
    ON
        src.JoinFields = targ.JoinFields
    WHEN MATCHED AND ISNULL(src.RemData,0) <> 1 THEN
        UPDATE
        SET
            fieldtoupdate = src.fieldtoupdate
    WHEN NOT MATCHED BY TARGET THEN
        INSERT
            (
                FieldList
            )
        VALUES
            (
                src.FieldList
            )
    WHEN MATCHED AND src.RemData = 1 THEN
        DELETE
    OUTPUT $action INTO @MergeOutput;
COMMIT

Очевидно, что источником является подмножество основной таблицы (обычно небольшой процент таблицы, скажем, 80-100 Гб [таблица имеет размер ТБ]). TempDB выделено 800Gb и находится на собственном диске без автоматического увеличения. Я получаю следующую ошибку:

Не удалось выделить место для объекта "dbo.SORT временное хранилище запуска: 140962158870528" в базе данных "tempdb", так как файловая группа "PRIMARY" заполнена. Освободите место на диске, удалив ненужные файлы, отбросив объекты в файловой группе, добавив дополнительные файлы в файловую группу или включив автоматический рост для существующих файлов в файловой группе.

Означает ли это, что он пытается поместить всю целевую таблицу в TempDb? Если это так, мне, очевидно, придется прекратить использовать слияние и написать отдельные операторы Insert/update/delete. Я искал ответ на этот вопрос во всех технических аспектах MERGE, но ничего не могу найти по этому поводу, поэтому любая помощь очень ценится.

Спасибо


person Rickd43    schedule 13.01.2021    source источник
comment
Если вы делаете все за один раз, то да, он попытается выполнить весь синтаксический анализ за один раз, что (по крайней мере) приведет к увеличению журнала транзакций в вашей базе данных и, вероятно, к большой обработке. будет счастлив в tempdb. Если вы работаете с огромным набором данных, то частое выполнение операций в пакетном режиме является лучшим решением.   -  person Larnu    schedule 13.01.2021
comment
Кажется, план выполнения включает оператор сортировки для всех строк в основной таблице. Убедитесь, что для объединенных столбцов существует уникальный индекс.   -  person Dan Guzman    schedule 13.01.2021
comment
Спасибо, Ларну, я не беспокоился о TLog, так как место на диске не является проблемой. Я делаю это как слияние из-за дизайна системы, хочу разделить его только в том случае, если мне действительно нужно, и нет другого выбора. Мой вопрос был больше о том, загружается ли Target в TempDb (что, как я думаю, происходит), а не о подмножестве, которое соответствует источнику, и если да, то при каких условиях я могу убедиться, что это не так (индексы, структура запроса и т.д).   -  person Rickd43    schedule 13.01.2021
comment
Спасибо Дэн, это может оказаться так (нужно еще немного проверить) и очень полезная информация. Только что читал об оптимизации слияния (хотя я могу странно найти только версию 2008 R2), так что это совпадает с тем, что я нашел. :)   -  person Rickd43    schedule 13.01.2021
comment
Есть ли в плане выполнения Spools (Lazy или Eager)? Это указывает на то, что данные загружаются в базу данных tempdb, возможно, несколько раз. SQL Server может создать копию целевой таблицы, новые данные и различные дополнительные прерывистые рабочие объекты, чтобы иметь возможность обрабатывать оператор слияния. Эта проблема может исходить от анализатора запросов, а не от самого оператора слияния.   -  person Knut Boehnert    schedule 13.01.2021


Ответы (1)


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

Спасибо за комментарии.

person Rickd43    schedule 18.01.2021