Ну если после обновления остальные ресторы прошли без ошибок, то бекап битый

Видимо просто совпадение )

Я думал может на файл бэкапа как то наложились версии, но это фантастика какая то, у нас же FORMAT опция. В общем спс, помучаю сисадмина, проверим СХД.

+ опция INIT

Используйте скрипты Ola Hallengren, они умеют бекапить правильно

Ничего волшебного в них нет, просто они (бэкап скрипты) удобные, когда допилишь по месту.

Всем привет
Ломаю голову (и Гугл меня не понимает)
Как сделать вывод в sql
Не
Id
1
2
3
А в строку
id 1 2 3

база какая? но вообще гуглить надо pivot unpivot

T sql

Все правильно сказали гугли пивот

Я уже читаю
спасибо

Всем привет
SQL Server 2019, Win Server 2019, включена in memory temp db metadata, in-memory таблиц нету.
Внезапно заканчивается память для скуля, то есть он упирается в выделенный лимит, и начинают появляться ошибки в логах:
1. Disallowing page allocations for database 'tempdb' due to insufficient memory in the resource pool 'default'.
2. XTP failed page allocation due to memory pressure: FAIL_PAGE_ALLOCATION 8
3. There is insufficient system memory in resource pool 'default' to run this query. - на каждый запрос
Еще в лог выдаются счетчики памяти, судя по всему, и самые большие - MEMORYCLERK_XTP (15 гб) и MEMORYCLERK_SQLBUFFERPOOL (14 гб), OBJECTSTORE_LOCK_MANAGER (9 гб)
Всего выделено памяти на sql server 40 гб
Ничего сделать не получается после того как это всё начинает происходить и приходится перезагружать службу скуля.
Попытался включить Resourse Governor (не настраивая) - всё равно произошло.
Подозреваю, что также как-то связано с обслуживанием, которое происходит ночью (update statistics. reorganize index, rebuild index), но оно происходит на другой базе данных, не на tempdb.
Память заканчивается примерно в момент когда должно было происходить обслуживание.
И обслуживание зависает, да, судя по логу sql agent

отключите in memory temp db metadata чтобы исключить его фактор (эта функция довольно багованная) и дайте больше информации из логов после этого, еще по хорошему посмотрите дефолтный трейс и Query Store

отключать максимально не хочется, без нее много ожиданий на pagelatch и падает производительность
как бы дело в том, что две недели всё было норм, а потом бах - и не норм

а что есть "дефолтный трейс" ?

ну и если заинтересует, то вот как его можно затюнить под свои нужды https://sqlperformance.com/2020/03/extended-events/removing-default-trace-1

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

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

в трейсе сейчас ничего нет, кроме Sort Warnings (возникают от пользовательских запросов)