На СКЛ сервере уже достиг 500 гига. Терпимо или что то надо делать?
Как у вас обстоять дела?

так

524 272 ТБ
https://docs.microsoft.com/ru-ru/sql/sql-server/maximum-capacity-specifications-for-sql-server

(0) если данные все нужны - ничего не делай, если в базе к примеру 10 лет и реально нужны только последние 3 года - отрежь первые 5 лет (свёртка)

(3) Базе всего 3 года

5 ТБ полет нормальный

(5) можно спросить что за конфигурация и что за контора?

При росте больше 600Gb скорость работы с базой становится некомфортной, делает свертку обработкой
http://catalog.mista.ru/public/139651/

(4)если внутри базы блобы не храните - да пусть так, в чем вопрос.

(7) а почему 600 а не 400 или 1024?

(9) наверно это связано с мощностью сервера :)

(5) Сдается мне у вас сет супермаркетов. И чеки храните в базе?

(10) сервера разные бывают

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

(13)и плевать в колодец можно и запросы в цикле тоже можно но вот нужно-ли?

Но к терабайту резать будем

(15) Сакральные причины?

больше психологические и скорость закачки копии этой базы в другой филиал по инету

зачем вы храните блобы в рабочем экземпляре базы?

Нужно смотреть по размерам таблиц и количествам обращений к ним.
Если часто используемая таблица больше 600 ГБ, то можно уже и порезать её. А объём всей базы не показатель к каким-либо действиям.

(5) пока летит, нормально. а как упадет, замучаетесь поднимать. ахах.

51гб, самописка, 3 года, 200 юзеров... пока летим ровно

Было до свертки 1.3Тб.
Всё-таки размер имеет значение, когда запросы сваливаются в скан таблиц. И бэкапы делать неудобно. И копию для тестов разворачивать - неудобно.
После свертки маленькая стала - 500гб.
Лишних данные нет, всё почищено что можно.

SSD - обязательно. На hdd 15к база помирала когда достигла 400гб.

"зачем вы храните блобы в рабочем экземпляре базы?", sorry, навеяло: автор не уточнил о каких базах речь и, имхо, без этого вопрос - не вопрос.
"О чем этот фильм? Да ни о чем!"(цы)
Все так привыкли к типовых конфигурациям, к вопросам "по умолчанию" по типовым конфигурациям, что многие делают круглые глаза, глядя на банальные электронные архивы документации.

(0) А какая конфигурация у вас? И какие таблицы самые большие?

(23) ССД что бы табле сканы быстрее отрабатывали? Попробуйте код получше писать.

(26) Обычные формы. Список в журнале документов - запрос формируется платформой. Сваливается в скан. Как предлагаете его переписать?

(24) пока ни разу в жизни не встречал реальных причин хранить блобы в базе.

+
ну и SSD не для сканов, а для любой работы, когда вводится по 15 тыс накладных в день.

(27)не обычные а старые как дерьмо мамонта

(27) добавить индексов что бы без сканов обходилось. если нельзя изменить запрос.

(31) К сожалению, не помогло
Спецам SQL. Тормоза в списке документов (обычные формы, 8.2, SQL)

Решили сменой режима совместимости с 8.1 на 8.2. Списки победили, но 80% остальных запросов стали медленнее. Некоторые практически перестали работать - пришлось переписать. Но по производительности 8.1 догнать всё равно не удалось.

(32) Открыл план запроса и тут же закрыл. Он же на русском. Как вы его читаете???