Змініть системний стандарт за замовчуванням для макскурсії

Як змінити загальносистемне значення за замовчуванням MAXRECURSION?

За замовчуванням це 100, але мені потрібно збільшити його на щось на зразок 1000.

Я не можу використовувати підказки щодо запитів, оскільки я використовую програму, яка приймає мій запит і виконує його для мене, і я, на жаль, не можу обійти це обмеження.

Однак у мене є права адміністратора на екземплярі сервера. Я ткнув навколо граней сервера, але я не бачу нічого, що стосується параметрів запиту чи рекурсії. Я припускаю, що десь має бути місце, де я можу оновити системний дефолт.

Будь-які ідеї?

Якщо ваші запити мають загальну форму, ви, можливо, зможете додати необхідний підказку щодо максимальної рекурсії за допомогою одного або декількох настанов плану.

Тут може бути хитрість, щоб їх правильно виправити. Якщо ви додасте конкретні деталі запиту до свого запитання, ми можемо це вирішити для вас. Як правило, ви могли б простежити, як SQL фактично потрапляє на сервер, або отримати параметризовану форму, використовуючи вбудовану процедуру sys.sp_get_query_template , а потім створити посібник з плану TEMPLATE та / або OBJECT / SQL.

Для отримання додаткової інформації дивіться документацію:

• Посібники з плану
• Створіть керівництво нового плану
• Створіть керівництво по плану для параметризованих запитів
• Вкажіть поведінку параметрів запиту за допомогою посібників із плану
• Застосуйте фіксований план запитів до посібника з плану
• Додайте підказки до запитів до посібника з плану
• Переглянути властивості посібника плану
• Використовуйте Профілер SQL Server для створення та тестування посібників із плану
• Затвердити керівництво плану після оновлення

Посібники плану потрібно буде повторно перевірити, коли змінюється код програми та коли патч або оновлення SQL Server буде оновлено. Це просто має бути частиною вашого нормального циклу тестування.

Зауважте, що перевірка керівництва плану за допомогою sys.fn_validate_plan_guide може неправильно повідомити про помилку, якщо керований оператор посилається на тимчасову таблицю. Дивіться це запитання:

Перевірка керівництва плану за допомогою fn_validate_plan_guide дає помилкові позитиви

У Керівництві плану Успішне і Невдалий план Керівництво Profiler і розширені події класи також може бути використані для моніторингу плану напрямних додатків.

Connect було вимкнено, перш ніж було запропоновано пропозиції щодо вдосконалення продукту Дозволити максимальні значення MAXRECURSION, окрім 100 для переглядів та UDF, Стіва Касса . Якщо ви хочете взяти це з Microsoft зараз, перегляньте параметри довідки та відгуки на SQL Server .

Якщо вам абсолютно доведеться використовувати функцію (обмеження вашого інструменту ETL, як ви розумієте), ви можете вказати OPTIONяк частину функції багатозначних операцій з таблицею, наприклад щось подібне:

CREATE FUNCTION dbo.udf_MyFunction ( @StartID INT ) 
RETURNS @tv TABLE
(
id INT
)
AS
BEGIN

    WITH Episodes( xlevel, PersonID, EventID, EpisodeID, StartDT, EndDT ) AS (
    -- Anchor case - the first EventID for each person.
    SELECT 1 AS xlevel, PersonID, EventID, @StartID, StartDT, EndDT 
    FROM dbo.EventTable
    WHERE EventID = @StartID

    UNION ALL

    SELECT xlevel + 1, et.PersonID, et.EventID, c.EventID + 1, et.StartDT, et.EndDT
    FROM Episodes c
        INNER JOIN dbo.EventTable et ON c.PersonID = et.PersonID
            AND et.EventID = c.EventID + 1
    --WHERE c.EventID <= (@StartID + 99)
    )
    INSERT INTO @tv
    SELECT PersonID
    FROM Episodes
    OPTION ( MAXRECURSION 1000 )

    RETURN

END
GO

Це також спрацювало для мене, коли ви переконалися, що ви пропонуєте свої інструменти ETL. Немає можливості змінити цю систему в цілому, але оскільки рекурсія може бути неефективною, це, мабуть, добре. Ви не можете вказати підказку (використовуючи OPTION) в тілі функції вбудованої таблиці, як у вашому прикладі.

Подумайте про зміну свого процесу для проходження ієрархії лише один раз, коли ви отримуєте епізоди та зберігаєте результати у реляційній таблиці. Ви можете використовувати збережений додаток для цього, щоб не стикатися з цим обмеженням.

Я також думаю, що у вашому коді може виникнути помилка: якщо ваш CTE приєднується до personId і повторюється у eventId, eventId 101 відображатиметься двічі, я думаю, як дублікат. Можливо, я неправильно трактував ваш код, дайте мені знати, що ви думаєте.

HTH

Я взяв натхнення з цієї теми .

Ось що я зробив для вирішення проблеми.

CREATE FUNCTION MySchema.udf_MyFunction(@StartID INT) 
RETURNS TABLE 
AS RETURN
WITH
Episodes(PersonID, EventID, EpisodeID, StartDT, EndDT) AS (
  -- Anchor case - the first EventID for each person.
  SELECT PersonID, EventID, @StartID, StartDT, EndDT 
  FROM MySchema.EventTable
  WHERE EventID = @StartID
UNION ALL
  SELECT
    ...
  WHERE
    EventID <= (@StartID + 99)
)
SELECT * FROM Episodes

Тоді я викликаю цю функцію так:

WITH
Episodes AS (
  SELECT * FROM MySchema.udf_MyFunction(1)
UNION ALL
  SELECT * FROM MySchema.udf_MyFunction(101)
UNION ALL
  SELECT * FROM MySchema.udf_MyFunction(201)
-- ...
UNION ALL
  SELECT * FROM MySchema.udf_MyFunction(901)
)
SELECT * FROM Episodes

Таким чином, жодна моя логіка CTE не повинна повторюватися, і я не плачу нічого додаткового з точки зору продуктивності. Прикро, що це потрібно зробити так, але я можу з цим жити.