SQL Azure - Максимальный размер строки превысил ошибку в стандартном DTU 50, но тот же запрос не имеет ошибки в Premium 150 DTU

Question

Заинтересованы, если кто-нибудь знает о том, что может происходить под капотом, чтобы один и тот же запрос не работал на одном уровне производительности Azure SQL, но работал на более высоком уровне?

Запрос делает сервер максимально загруженным для100% на стандартном уровне, но я ожидал бы получить исключение, связанное с нехваткой памяти, если бы это было проблемой.Но вместо этого я получаю

Невозможно создать строку размером 8075, которая превышает максимально допустимый максимальный размер строки 8060

Я знаю, что запрос должен бытьоптимизирован, но что меня интересует для целей этого вопроса, так это то, что при повышении до Premium 150DTU вдруг эти данные не превысят максимальный размер строки?

Answer 1

Я могу сделать обоснованное предположение относительно вашей проблемы.При переходе с одного размера резервирования на другой ресурсы, доступные оптимизатору, изменяются.Он считает, что у него больше памяти, в частности.Память является ключевым компонентом в запросах калькуляции в оптимизаторе запросов.Выбор плана при меньшем размере резервирования, скорее всего, имеет спул или сортировку, которая пытается создать объект в базе данных tempdb.Тот, что в более высоком размере бронирования не является.Это накладывает ограничение на механизм хранения, поскольку промежуточная таблица не может быть материализована.

Без рассмотрения плана невозможно с уверенностью сказать, является ли это требованием выбранного плана запроса или простооптимизация.Тем не менее, вы можете попробовать использовать подсказку NO_PERFORMANCE_SPOOL в запросе, чтобы проверить, работает ли он при меньшем размере резервирования.(Учитывая, что у него меньше памяти, я думаю, что это не проблема).

https://docs.microsoft.com/en-us/sql/t-sql/queries/hints-transact-sql-query?view=sql-server-2017

(Теперь я думаю с общими советами, так как я не знаюкакое приложение у вас есть, но оно основано на обычных шаблонах, которые я вижу регулярно): если ваша схема действительно широка или плохо определена, рассмотрите возможность пересмотра определения таблицы, чтобы уменьшить размер столбцов до нужного минимума.Для приложений хранилищ данных, пожалуйста, рассмотрите возможность использования таблиц измерений + суррогатных ключей.Если вы сбрасываете файлы текстового журнала в SQL, а затем пытаетесь различить их, обратите внимание на то, что различение часто подразумевает сортировку, которая может привести к такого рода проблемам, если строка слишком широка (поскольку вы пытаетесь использовать все столбцы включ).

Желаем удачи в работе вашего приложения.SQL имеет тенденцию работать очень хорошо для реляционных приложений, где вы продумываете детали своей схемы и немного индексируете.В будущем, пожалуйста, опубликуйте немного больше информации о ваших шаблонах запросов, схемах и планах запросов, чтобы другие могли помочь вам более точно.