Management Studio появился в 2005-м, до этого он не был похож на студию и назывался Enterprise (но не как известная серия звездолётов Стартрека а с припиской Manager), собственно, это на вашем скриншоте и видно. Если честно, я не припоминаю, что-бы EM был на четвёрке, на шестёрке точно и поддерживал старые версии. С Сайбейзом вроде последняя версия была 7.
Тут дело даже не в синтаксисе, который действительно у Грега простоват, эта серия статей о том, как разработчики реализовали операторы языка, и продемонстрировано всё с примерами планов запросов, объясняя, как это всё работает на уровне сервера. Статьи маленькие и трудно увидеть всю картину в целом, к тому же, некоторые темы у Грега расползаются на несколько статей и без контекста не очень понятно, для чего статья. Начинающие разработчики не знают, кто стоял у истоков того, с чем они работают, потому и возмущаются, но с годами до них дойдёт :)
Как то больше похоже на то, какую ОС и СУБД авторы лучше научились настраивать под данную нагрузку... Описания конфигруации, какой всегда сопровождаются TPC-тесты, не увидел.
Цитата: Historically, transaction log files could not be initialized instantaneously. However, starting with SQL Server 2022 (16.x) (all editions) and in Azure SQL Database, instant file initialization can benefit transaction log autogrowth events up to 64 MB. The default auto growth size increment for new databases is 64 MB. Transaction log file autogrowth events larger than 64 MB cannot benefit from instant file initialization.
Такое поведение с 2019 вполне ожидаемо, Майкрософт обещало, что нагрузка на tempdb вырастет. Проблема не в самой операции TRUNCATE, а в блокировках на метаданных, которые трудно диагностировать без специальных средств. Например, если для временной таблицы в 1С не указали создание индекса по предикатам соединений, не только TRUNCATE не будет "летать", но и запросы к dmv будут ждать высвобождения блокировок на метаданных. Там всё в tempdb в кучу сейчас свалено, нужно разгружать эту базу или давать для неё больше ресурсов (больше файлов и конечно SSD).
На метаданные, которые живут в tempdb, много чего влияет и добавляет нагрузки. Есть копоненты - "чёрные ящики", которые любят включать, не осозновая, что это может стать причиной повышения вероятности блокировок на метаданных. Поэтому, не торопитесь с внедрением CDC, AlwaysON, QS и FTS если в этом нет насущной необходимости, можно нарваться на проблемы, как в этой статье.
Часто ещё для пользовательских баз включают версионность, забывая, что если в запросе идёт соединение с временной таблицей, изоляция будет как у худшей базы, а tempdb версионность не поддерживает. Зато включение версионности значительно повышает нагрузку на TEMPDB.
Высоконагруженные базы требуют соответствующего железа и не терпят задержек к дискам. Также важен грамотный сайзинг на NUMA, без перекосов по памяти, это тоже направление для снижения влияния подобных проблем.
В оригинале написано так: Note: The maximum number of ADR Cleaner threads is capped at the number of cores used by the SQL Server instance. Однако, я подозреваю, что это простая оговорка... В документации пока не видел про это ограничение.
SSD в массиве мрут одновременно, об этом пишут пострадавшие, погуглите. Этому есть объективные причины, нагрузка в массиве одинаковая на все диски. Enterprise диски не просто дороже, они сильно дороже, многие вендоры предлагали раньше (не знаю, как сейчас) ставить диски попроще, но с бесплатной заменой в рамках поддержки до того, как счётчик циклов исчерпается. Следить за состоянием дисков нужно обязательно, только вот не все контроллеры это дают сделать :( В общем, HADR наше всё! А у рекомендации размещать журналы на отдельном массиве появляется новый смысл ;)
ИМХО - транкейтит времянки есть плохая идея, проще логику поменять... и весь головняк от временных таблиц уйдёт. С ними же не только эта беда.
Да уж... вообще, функции ранжирования где-то сбоку от реляционной теории, прикручено на потребу желающим всё впихнуть в SQL...
Могу дать права писать в моём ;) https://t.me/mssqlhelp
Management Studio появился в 2005-м, до этого он не был похож на студию и назывался Enterprise (но не как известная серия звездолётов Стартрека а с припиской Manager), собственно, это на вашем скриншоте и видно. Если честно, я не припоминаю, что-бы EM был на четвёрке, на шестёрке точно и поддерживал старые версии. С Сайбейзом вроде последняя версия была 7.
Тут дело даже не в синтаксисе, который действительно у Грега простоват, эта серия статей о том, как разработчики реализовали операторы языка, и продемонстрировано всё с примерами планов запросов, объясняя, как это всё работает на уровне сервера. Статьи маленькие и трудно увидеть всю картину в целом, к тому же, некоторые темы у Грега расползаются на несколько статей и без контекста не очень понятно, для чего статья. Начинающие разработчики не знают, кто стоял у истоков того, с чем они работают, потому и возмущаются, но с годами до них дойдёт :)
До этого была серия статей и переводов про 2022, это тоже уже паутиной заросло?
Я в курсе, и спасибо, что попросил про оконные функции - будет сделано.
В Русском языке нет слова "партиционирование", для этого принято использовать термин "секционирование".
Спасибо!
Как то больше похоже на то, какую ОС и СУБД авторы лучше научились настраивать под данную нагрузку... Описания конфигруации, какой всегда сопровождаются TPC-тесты, не увидел.
Лучше ориентироваться на первоисточники: https://learn.microsoft.com/en-us/sql/relational-databases/databases/database-instant-file-initialization?view=sql-server-ver16
Цитата: Historically, transaction log files could not be initialized instantaneously. However, starting with SQL Server 2022 (16.x) (all editions) and in Azure SQL Database, instant file initialization can benefit transaction log autogrowth events up to 64 MB. The default auto growth size increment for new databases is 64 MB. Transaction log file autogrowth events larger than 64 MB cannot benefit from instant file initialization.
Такое поведение с 2019 вполне ожидаемо, Майкрософт обещало, что нагрузка на tempdb вырастет. Проблема не в самой операции TRUNCATE, а в блокировках на метаданных, которые трудно диагностировать без специальных средств. Например, если для временной таблицы в 1С не указали создание индекса по предикатам соединений, не только TRUNCATE не будет "летать", но и запросы к dmv будут ждать высвобождения блокировок на метаданных. Там всё в tempdb в кучу сейчас свалено, нужно разгружать эту базу или давать для неё больше ресурсов (больше файлов и конечно SSD).
На метаданные, которые живут в tempdb, много чего влияет и добавляет нагрузки. Есть копоненты - "чёрные ящики", которые любят включать, не осозновая, что это может стать причиной повышения вероятности блокировок на метаданных. Поэтому, не торопитесь с внедрением CDC, AlwaysON, QS и FTS если в этом нет насущной необходимости, можно нарваться на проблемы, как в этой статье.
Часто ещё для пользовательских баз включают версионность, забывая, что если в запросе идёт соединение с временной таблицей, изоляция будет как у худшей базы, а tempdb версионность не поддерживает. Зато включение версионности значительно повышает нагрузку на TEMPDB.
Высоконагруженные базы требуют соответствующего железа и не терпят задержек к дискам. Также важен грамотный сайзинг на NUMA, без перекосов по памяти, это тоже направление для снижения влияния подобных проблем.
Принято говорить "секционирование"
В оригинале написано так: Note: The maximum number of ADR Cleaner threads is capped at the number of cores used by the SQL Server instance. Однако, я подозреваю, что это простая оговорка... В документации пока не видел про это ограничение.
Ну и флаг им в руки, мы же в облаках не летаем :)
https://learn.microsoft.com/ru-ru/sql/relational-databases/databases/revert-a-database-to-a-database-snapshot?view=sql-server-ver16
Нет, не правильно. Как и раньше, это дамп страниц, а не снапшот. Из снапшота тоже можно восстановиться, но это и раньше было. https://learn.microsoft.com/ru-ru/sql/relational-databases/backup-restore/create-a-full-database-backup-sql-server?view=sql-server-ver16
И как и раньше ничего небыло связано с Православием.
До SQL Server 2022 параметра AUTO_DROP не было, поэтому обновление статистики могло блокировать изменение схемы.
SSD в массиве мрут одновременно, об этом пишут пострадавшие, погуглите. Этому есть объективные причины, нагрузка в массиве одинаковая на все диски. Enterprise диски не просто дороже, они сильно дороже, многие вендоры предлагали раньше (не знаю, как сейчас) ставить диски попроще, но с бесплатной заменой в рамках поддержки до того, как счётчик циклов исчерпается. Следить за состоянием дисков нужно обязательно, только вот не все контроллеры это дают сделать :( В общем, HADR наше всё! А у рекомендации размещать журналы на отдельном массиве появляется новый смысл ;)
Самые первые NVMe от Intell