Описание: KB5073031
Скачать: SQLServer2022-KB5073031-x64.exe
SQL Server 2022 — Версия: 16.0.1165.1
Дата выпуска: 13 января 2026г.
14.1.26
Исправление безопасности для SQL Server 2022 CU22 - KB5072936
Описание: KB5072936
Скачать: SQLServer2022-KB5072936-x64.exe
SQL Server 2022 — Версия: 16.0.4230.2
Дата выпуска: 13 января 2026г.
Исправление безопасности для SQL Server 2025 GDR - KB5073177
Описание: KB5073177
Скачать: SQLServer2025-KB5073177-x64.exe
SQL Server 2022 — Версия: 17.0.1050.2
Дата выпуска: 13 января 2026г.
13.1.26
Почему не стоит сжимать файлы данных
Одна из моих самых больших «болевых точек» — это сжатие файлов данных. Хотя, когда я работал в Microsoft, я отвечал за код сжатия, я не писал его (так что не вините меня! :-)), и это никогда не считалось достаточно серьёзной проблемой для клиентов, чтобы её исправлять. Но мне действительно не нравится процесс сжатия файлов данных.
Важно, не путайте сжатие журнала транзакций со сжатием файлов данных. Сжатие журнала может быть необходимо, если ваш журнал вышел из-под контроля, или как часть процесса устранения чрезмерной фрагментации VLF (см. отличные посты Кимберли здесь и здесь). Однако сжатие журнала должно быть редкой операцией и не должно быть частью какого-либо регулярного обслуживания, которое вы выполняете.
В любом случае, я не говорю об использовании параметра TRUNCATEONLY — всё, что он делает, — это отсекает неиспользуемое пространство в конце файлов — это совершенно нормально. Я говорю о фактическом запуске алгоритма сжатия.
Примечание переводчика: статьи Пола и Кимберли были написаны в те времена, когда доминировали HDD. Сейчас это уже больше экзотика и основу составляют диски SSD. Такие диски значительно превосходят жёсткие диски по производительности и времени доступа, что снижает негативные последствия сжатия данных. Однако, если сжимать данные часто, это может заметно снизить число циклов перезаписи ячеек памяти, которое ограничено, и приблизить срок исчерпания ресурса диска. Это ещё один аргумент, почему не стоит этим злоупотреблять.
12.1.26
Тестирование ограничений tempdb в Resource Governor SQL Server 2025 с запросом, вызывающим переполнение на терабайт
SQL Server 2025 представляет новую возможность Resource Governor для управления использованием tempdb, а также делает Resource Governor доступным в Standard Edition.
Мне стало интересно: может ли новая функция tempdb в Resource Governor помочь сдержать запросы, которые не используют временные таблицы, но вызывают массовое переполнение данных в tempdb? В документации говорится «да», но я всегда предпочитаю получить практический опыт, когда это возможно.
У меня есть ужасный запрос, который «переливается через край», как автомат с мягким мороженым, объявивший войну. Давайте протестируем новые функции управления tempdb в SQL Server 2025.
10.1.26
Заблуждения о выполнении DMV для баз данных с меньшими уровнями совместимости
У моего класса перерыв на обед — время для записи в блоге! Это интересный вопрос, который возникает периодически (буквально час назад на SQL Server Central) и не очень широко известен.
Существует заблуждение, что вы не можете выполнять динамические административные представления (DMV) в базах данных с уровнем совместимости 80 или ниже. Это не так.
6.1.26
Заблуждения относительно журнала и резервных копий журнала: как самому проверить
До сих пор широко распространено заблуждение, что при корректной работе в моделях восстановления FULL или BULK_LOGGED полные или дифференциальные резервные копии могут усекать журнал. Нет. Это НИКОГДА не происходит. Это одна из причин, по которой я посвящаю целый доклад этой теме на конференции PASS в этом году — поведение журнала транзакций, по моему скромному мнению, является одной из самых неправильно понимаемых частей SQL Server.
5.1.26
Заблуждения относительно восстановления базы данных
На этой неделе на форумах и в Twitter было оживлённо: люди сталкиваются с множеством интересных проблем. Я заметил, что существует много заблуждений относительно запуска восстановления (repair), поэтому, чтобы завершить пятницу, я пройдусь по их списку для вас. Вот эти заблуждения, по поводу некоторых из которых мне приходилось спорить с людьми несколько раз и в конце концов прибегать к фразе «Слушайте, я писал код восстановления, мне жаль, но вы не правы», что я ненавижу делать:
4.1.26
Заблуждения относительно добавления столбцов в таблицу
Это короткое продолжение моей статьи «Заблуждения вокруг размера null bitmap».
Битовая карта NULL всегда присутствует в записи данных (т.е. в записях в куче или на конечном уровне кластерного индекса), за исключением случаев, когда в SQL Server 2008 и новее все столбцы определены как SPARSE, но она необязательна в записях индексов, если все столбцы в записях индексов не допускают значения NULL. Заблуждение связано с тем, что происходит при добавлении нового столбца в таблицу. Распространённое заблуждение заключается в том, что если у вас есть 8 столбцов в таблице (и, следовательно, 8 битов в битовой карте NULL), и вы добавляете девятый столбец, то SQL Server должен обновить каждую запись, чтобы все битовые карты NULL содержали 9 битов. (Такое же заблуждение применяется к добавлению 17-го, 25-го, 33-го и т.д. столбцов).
3.1.26
Заблуждения относительно хранилища FILESTREAM
Эта короткая статья вызвана вопросом, поступившим через Twitter, (перефразированный) вопрос звучит так: «Могут ли данные FILESTREAM храниться удалённо?». Это сбивало с толку многих, и ни документация BOL по FILESTREAM, ни мой технический документ по FILESTREAM (см. здесь) прямо не отвечают на этот вопрос.
2.1.26
Заблуждения относительно повреждений: могут ли они исчезать?
Этот вопрос возникал уже несколько раз, совсем недавно — сегодня утром в письме: последующие запуски DBCC CHECKDB показывают разное количество повреждений, а иногда и вовсе их не находят — что происходит? Ещё более странно: задание обслуживания запускает DBCC CHECKDB, который показывает ошибки, но затем утром — никаких ошибок согласованности. Как?
29.12.25
Заблуждения о перестроении индексов (распределение, режим BULK_LOGGED, блокировки)
Я обнаружил (и помог исправить) довольно много мифов и заблуждений об операциях перестроения индексов. Их достаточно, чтобы стоило написать об этом статью в блоге (да и здесь, в Орландо, слишком жарко, чтобы идти сидеть у бассейна, так что мы оба сидим здесь и пишем в блогах)…
Подписаться на:
Комментарии (Atom)