ВасилийОПолный: проверка бд->переход с full на bulk-logget ->ребилдинг -> возврат на full-> бэкап-> очистка старых логов.
Дифференциальный: все тоже самое только вместо ребилда идет реорганизация
простите, а речь точно о бэкапах?
люди традиционной ориентации под полным бэкапом понимают

а под дифференциальным

а вто реорг, ребилд, -- это НЕ бэкапы

да блин, не после фулл бэкапа, а после вашего reorganize, наверное?
ALTER INDEX REORGANIZE = fully logged operation

зачем переводить базу из FULL в BULK LOGGED для реорга?
при ребилде еще понятно: в BULK LOGGED ребилд минимально логируется.
а реорг всегда FULLY LOGGED.
ну бэкапьте вы лог чаще во время реорга, раз место жалко для лога

ВасилийОно ведь проблема только в понедельник после воскресного full, во вторник все проходит даже без добавления
во сколько заканчивается ваш полный бэкап
и во сколько начинается понедельниковое обслуживание?
проходит ли между ними бэкап лога?

все время, пока идет ваш полный бэкап (А ЭТО САМЫЙ ДОЛГИЙ ИЗ БЭКАПОВ),
лог не очищается.
да, бэкапы лога могут параллельно идти,
но все то время, что длится полный, лог не усекается.

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

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

ВасилийОПотому что после ребилда для реорганизации больше данных? Даже не смотря на то, что ребилд при bulk-logget делается ?

ваше bulk-logget в 10ый раз глаза режет, может, надо уже прочесть о том,
что за модель восстановления bulk logged ?

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

ВасилийОПолный начало в воскресенье в 19:00 конец в 20:47

Дифференциальный все дни кроме воскресенья начало в 21:00 конец (в промежутке 22:33-22:53)
это мы сейчас про время бэкапа или время всего вашего плана обслуживания?
если ваш дифф.бэкап длится ровно столько, сколько и полный, нафига же делать дифф?
уж проще делать полный, затраченное время одинаково,
а зато ресторить дифф это сперва ресторить фулл, и получается, ваше время рестора увеличивается в 2 раза

ВасилийОo-o,

Так при такой модели минимальное протокооирование или проще сказать не полное
ну и?
какое это оказывает влияние на результат ?
в чем разница кроме как в затраченном времени и объемe заполнения журнала?

2 человека моют 2 одинаковые горы посуды, один записывает свои действия после каждой вилки-ложки-тарелки:
"вымыта ложка номер 5" и тд,
а второй закончил все ложки, написал: "вымыто 100 ложек".
что, кто-то из них гарантированно хуже сделает свою работу?
просто один бумаги и чернил больше переведет и упарится записывать

Владислав КолосовЕсли в базе данных используется простая модель восстановления или модель восстановления с неполным протоколированием, некоторые DDL-операции с индексом протоколируются в минимальном объеме при их выполнении как режиме «вне сети», так и в режиме «в сети». Минимально протоколируются следующие операции с индексами.

Операции CREATE INDEX (включая индексированные представления).

Операции ALTER INDEX REBUILD или DBCC DBREINDEX.

Примечание Примечание
Инструкция DBCC DBREINDEX является устаревшей, поэтому следует избегать ее использования в новых приложениях.

Перестроение новой кучи DROP INDEX (если применимо).

Примечание Примечание
Освобождение страниц индекса в ходе выполнения операции DROP INDEX всегда протоколируется полностью.
это все прекрасно.
но где тут написано, что ребилд в полной модели отребилдит лучше/хуже, чем в simple/full?
он же пишет
авторПотому что после ребилда для реорганизации больше данных? Даже не смотря на то, что ребилд при bulk-logget делается?
после ребилда у него больше работы для реорг привалило(!),
и даже в bulke logged(!)
я вот интересуюсь, а если бы он отребилдил в full или в simple,
то как там с работой для реорга, ему бы больше или меньше пришлось трудиться?

ВасилийОНачало плана в 21:00 время от старта до финиша 1 час 33 минуты или 1час 53 минуты, каждый день время разное.
ваши планы друг на друга не влияют в смысле сколько они в лог написали.
потому что, если вам верить, между ними еще туча бэкапов лога.
а интересует вас то, что непосредственно перед реоргом в лог пишет,
либо сам реорг.
найдите время переполнения лога (t2),
найдите ближайший по времени бэкап лога до этого (время его окончания - t1).
в промежутке времени t1..t2 именно в понедельник у вас идет больше записи в лог,
чем в другие дни.
выясняйте, это только реорг или еще что-то с ним одновременно пишет.

слушайте, а может там у вас еще и шринк выполяется по воскресеньям?

ВасилийОПолучается, что в плане для дифференциального переход с фул на булк и обратно перед и после реорганизации не имеет смысла?
да, не имеет.
логирование будет все равно полное.
но реорг не выполняется в одной транзакции,
так что если во время реорга бэкапить лог,
лог будет усекаться