MSSQL 2012 быстрее просматривается после выполнения «alter»

Question

У меня ситуация/контекст, где конкретный вид занимает 120 секунд перед возвратом результата. При выполнении простого ALTER (или drop/create) вид занимает от 1 до 2 секунд. Как это возможно и как мы можем это исправить - поскольку у нас нет выделенного администратора баз данных, который может помочь нам. Создание индексированных представлений не является вариантом из-за связанной настройки сервера, которую мы имеем (MSSQL Server 2012 жалуется на это).

Ниже приведена информация о настройке.

TL; DR View_MAIN занимает 120 секунд после определенного количества времени. Когда мы выполняем представление ALTER на View_X, View_Y и View_MAIN, ничего не меняя, производительность снова нормальна к 1 - 2 секундам.

---

View_MAIN

SELECT 
    column1, column2, column3, column4, column5 
FROM View_X 

UNION ALL 

SELECT 
    column1, column2, column3, column4, column5 
FROM View_Y 

View_X

SELECT 
    LTRIM(RTRIM(table1.a)) as column1, 
    table2.b COLLATE Latin1_General_CI_AS as column2, 
    table1.c as column3, 
    CAST(table3.d AS DATETIME) as column4, 
    'XXXXXX' as column5 
FROM 
    [linkedserver01].[DATABASE_IDN].[dbo].[dataForX] table1 
    LEFT OUTER JOIN [linkedserver02].[DATABASE_INFM] as table2 
    ON table2.id = table1.id 
    LEFT OUTER JOIN [linkedserver02].[DATABASE_PIK] as table3 
    ON table3.id = table1.id 

View_Y

SELECT 
    LTRIM(RTRIM(table1.a)) as column1, 
    table2.b COLLATE Latin1_General_CI_AS as column2, 
    table1.c as column3, 
    CAST(table3.d AS DATETIME) as column4, 
    'YYYYY' as column5 
FROM 
    [linkedserver01].[DATABASE_IDN].[dbo].[dataForY] table1 
    LEFT OUTER JOIN [linkedserver02].[DATABASE_INFM] as table2 
    ON table2.id = table1.id 
    LEFT OUTER JOIN [linkedserver02].[DATABASE_PIK] as table3 
    ON table3.id = table1.id 

Answer 1

Изменив или воссоздав представление, вы очистите план выполнения кэширования, который существует для этого, и воссоздайте его на основе текущего набора данных.

Вы можете достичь того же эффекта, выполнив sp_recompile 'View_Main'

https://technet.microsoft.com/en-us/library/ms181055(v=sql.105).aspx

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

Answer 2

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

EXEC sp_updatestats 

, прежде чем запрашивать мнение или вы можете попробовать Query Hints Recompile, если на самом деле ничего не помогает или еще лучше вариант быстро. Если вы можете оценить количество строк вид обычно возвращается, скажем, его 50.000 строк, вы можете попробовать:

SELECT * FROM View_MAIN OPTION (FAST 50000); 

EDIT:

Почему я предлагаю избавиться от связанных серверов:

1. Вам не хватает общего журнала регистрации, статистики, планов выполнения и т. Д.
2. Как только у вас нет dbo или подобных разрешений, вы не сможете использовать статистику, что приведет к плохой производительности соединений связанных серверов.
3. Вы в основном получаете полные результаты, и объединение данных организовано впоследствии. Поэтому попробуйте присоединиться к минимально возможному набору результатов с удаленного сервера.
4. Вы не знаете, был ли ваш запрос заблокирован на целевом сервере, если у вас нет доступа к нему.

Если вы вынуждены использовать связанные серверы, рассмотрите OPENQUERY. Таким образом, агрегации будут выполняться на вашем SQL-сервере.