У нас есть процесс, который выполняет следующий шаблон SQL для очень большого объема данных:
INSERT INTO Target
SELECT
Col1,Col2,Col33,Col44, (...) Col30
,SUM(Col31)
,SUM(Col32)
FROM
SOURCE
GROUP BY
1,2,3,4 ...30
Из-за большого количества строк в исходной таблице и большого количества столбцов в группесогласно предложению, это приводит к очень высокому использованию пространства TEMPDB, и в одном случае нам не хватило места.
Учитывая, что бизнес-требования диктуют группирование по обычному количеству столбцов, нам нужно найти способ уменьшитьобъем пространства TEMPDB, которое мы используем, не влияя на производительность результирующей целевой таблицы, которая служит нашей основной отчетной таблицей.
Мы думали получить месяцы отчетности в SourceTable, а затем создать CURSOR, в котороммы выполняем цикл по отдельности и выполняем только вышеприведенный SQL, ГДЕ Source.ReportingMonth = @CurrentReportingMonth из Курсора и делаем это до тех пор, пока все ReportingMonths не будут обработаны.К сожалению, исторические данные могут изменяться, и поэтому все данные за каждый месяц должны проверяться каждый раз, когда мы обрабатываем месячный цикл.Данные за каждый месяц примерно одинакового объема.
Когда мы сказали нашему администратору базы данных, что это было нашим намерением, он ответил: «Я думаю, это очень хорошее начало, однако, если результирующая таблица в основном используется для отчетов, а не для дальнейшей агрегации, мы, вероятно,лучше просто заменить таблицу представлением, поскольку на самом деле выполняется очень мало агрегации. "
Я считаю, что представление все еще приводит к выполнению SQL, а преобразование SQL в представление - производительностьЭто может повлиять, потому что SQL может выполняться много раз в отчетах, для которых нужны данные, которые раньше постоянно хранились в постоянной физической таблице.В SQL Server их представления могут сохраняться по соображениям производительности, чтобы избежать необходимости многократного выполнения SQL?Если у нас есть только один процесс, который выполняется ежемесячно для заполнения целевой таблицы, есть ли какое-то преимущество, если превратить целевую таблицу в представление исходной таблицы?
В1: Является ли наша идея курсора разумным подходом крешить проблему пространства TEMPDB?
Q2: Есть ли здесь какой-нибудь VIEW?
Примечание: мы также предложили пользователям определить, есть ли «достаточно старые» данные для архивирования.