Yasha123,

Логи, базы и бэкапы на разных дисках.
Просто ваша фраза " куда сложены логи баз " сбивает с толку.

И да, 2 раза написали и это понятно, но я отвечал на ваш же вопрос о связи логов с бэкапами, и ни слова не сказал что что то не понятно про бэкап лога и сам лог в режиме bulk logged.

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

В общем как я понял нет в MSSQL адекватного способа обслуживать большие базы.

Так же интересная статья попалась, в которой немного говорилось по этой теме https://infostart.ru/public/1081863/
Приведу кусок оттуда:
1С просто и незатейливо советует sp_msforeachtable N'DBCC DBREINDEX (''?'')' (или уже есть более свежая статья?). Microsoft настойчиво рекомендует схему "avg_fragmentation_in_percent > 5% and < = 30% - REORGANIZE, > 30% - REBUILD". На infostart.ru светится "10%-30%", "5%-30%".

И практически на всех рабочих серверах, кои мне доводилось видеть - работает то самое 5%-30% - в виде версии от Микрософт, или скрипты шведского товарища Ola Hallengren, или что-то самописное на том же принципе. Реже встречается sp_msforeachtable. На тестовых серверах, как правило, чаще метод "мы забили на регламентное обслуживание"..

Для мелких баз с хорошими технологическими окнами - Ola Hallengren самое то. Работает по ночам, есть не просит.
Но вот для террабайтных высоконагруженных, работающих "24/7/почти 365" - все далеко не так радужно.
Вот с чем сталкивался:
- Само обращение к sys.dm_db_index_physical_stats даже с ''LIMITED'' - весьма неплохо съедает память (буферпул) sql-сервера. Далее возможны задержки непричастных запросов на физ чтениях, пока буферпул опять наполняется "нормальными" данными
- Ошибки вида Msg 9002, The transaction log for database '...' is full due to 'ACTIVE_TRANSACTION'. - иной раз не лезет индекс в данное админом пространство под лог
- Ошибки вида Msg 9002, The transaction log for database '...' is full due to 'LOG_BACKUP' - и, соответственно, реплики на резервных серверах могут становиться сильно неактуальными... Даже без данных завалов из-за массивных переиндексаций может быть отставание реплик в AlwaysOn

- И, самое болезненное - собственно, блокировки на REBUILD. Особенно для редакций Standart - нет with(online = on) и тем более WAIT_AT_LOW_PRIORITY, сам ребилд идет в один поток (и коль заблокирует кого - то надолго). И даже в версии Enterprise с with(online = on) - блокировки все равно в наличии! Будили ночью, любовался. Собственно, в документации оно вполне отражено.

Обычный сценарий блокировок под для Standart - некий кривоватый запрос (даже вне транзакции, с хинтами with(nolock)) блокирует alter index..rebuild , далее alter index блокирует всех. Пробовал бороться с теми самыми "кривоватыми запросами" - легион их. Пробовал писать джоб, убивающий "кривоватые запросы", мешающие переиндексации - работает.. но однажды оно убило весьма важный процесс - отключил. Перенастроил джоб для "самых важных баз", чтобы он убивал саму реиндексацию - аналог WAIT_AT_LOW_PRIORITY ( MAX_DURATION = 1 MINUTES, ABORT_AFTER_WAIT = SELF ) - работает... но, понятное дело - не идеал.

Т.е. стандартная модель переиндексации понемногу перестает устраивать.
Вот и Brent Ozar еще в 2012 сомневался - а тогда еще не было широкого распространения ssd.
В настоящий момент думаю в сторону "реиндексации того, что в текущий момент сидит в оперативке (в буферпуле) - с целью минимизации размера индекса (и память освободим, и чтений меньше)".. также понемногу задираю пороги ("5-30" веду к "40-50") и отслеживаю изменение скорости типовых запросов - посмотрим, что будет..

Опять-таки, Микрософт тоже ощущает, видимо, данную проблему.. Появление WAIT_AT_LOW_PRIORITY в MS SQL Server 2014 и RESUMABLE=ON в MS SQL Server 2017 как бы намекает. Жаль только, что все это не для standart (enterprise дорогой и в наличии далеко не на всех серверах).

Тему можно закрыть.
Вывод: большая база? - добро пожаловать в оракл
Если я не прав, то с радостью выслушаю как обслуживать большие базы (от 1Tb) не тратя при этом большие деньги на аренду в ДЦ места с 10-ками терабайт.
Модератор: Для сравнения СУБД есть отдельный раздел форума, тут разводить не надо.

komradВладислав КолосовЕвгений.,

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

Подозрения беспочвенны, компрессия включена.

Владислав КолосовЕвгений.,

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

Используется, отчасти поэтому и не столь критична данная проблема.