Есть база УПП 1,7 тб, создал новую базу из выгрузки DT получилось 700гб. Можно ли средствами SQL получить аналогичный результат? Если да, что что там надо настроить или запустить?

модель восстановления простая

Вообще-то 700ГБ из 1.7 ТБ - это ничего особенного.

(2)
Когда диск под базу данных 2тб пора задуматься. В такой ситуации разница есть.

"Когда диск под базу данных 2тб пора" ... бежать.
Если у тебя такие объёмы БД и такой диск - ничего хорошего не светит

Интересно, сколько длился процесс?

(5)
Процесс чего? dt файл создавался 15 часов, прогружался в чистую базу 30 часов, хотя скл-ными средствами база восстанавливается за 2 часа.

А базу данных на заводе 10 лет ведут, никаких обрезаний ни разу не делали, все 10 лет так и доступны

так dt это же архивный формат уже. платформа жмет данные при выгрузке.
а SQL работает с нормальными таблицами.
хотите аналогичный результат берите bak от SQL и архивируйте - получится сравнимого размера файл.
или вам хочется рабочую базу сжать? сомнительная идея.

Ну есть же всякие методы, вроде этого http://catalog.mista.ru/public/114634/
Но там тоже все начинается с выгрузки dt

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

Хм. Я думал есть ограничения на размер dt.

(0) так 700гб это ДТ? или всетаки новая база?

Интересно, скотлько *.ldf весит, может просто надо лог файлы подрезать?

(13) да обычно это настраивают при запуске базы

(0) нет. DT не рассчитан на скоростную выборку, он рассчитан только на хранение и развертывание. За счет этого выигрыш в размере.
Если вам нужна скоростная выборка данных, формат будет другой и размер тоже.

(14) Когда я пришел в новую контору, в которой не я скуль настраивал, логу было отведено все пространство, и он его успешно занимал...

я тоже сначала подумал про размер dt в 700 Гб и слегка охренел. видимо действительно размер базы после развертки.
тогда начать с бэкапа и шринка.
после серьезной реструктуризации БД сильно пухнет.

Сначала посмотреть на место занимаемое таблицами до и после восстановления. Может это нулевые итоги (при разворачивании из ДТ они пересчитываются). Может это индексы.

(0) щринк работает?

(16) "логу было отведено все пространство, и он его успешно занимал..."
Это нормальное поведение скуля.

(9) не угадал, давно есть скрипты, где самим скулем все можно сделать, без выгрузки в dt. Читай там же, на нимфостарте, есть пара решений

(0) Делай периодически шринк на SQL.

Но, в любом случае, проблему нужно решать комплексно:
1. Объем дискового пространства нужно увеличивать.
2. Шринк настроить на автоматическую работу.

(0) Начиная с MS SQL 2016 в Standard редакции доступна опцция сжатия таблиц БД (ранее было доступно только в Enterprise версии).
Данная опеция позволяет прозрачно для приложения сжимать таблицы. ОЧЕНЬ полезный инструмент. Лично я работал с базой 1.5 ТБ и удалось ну очень существенно снизить нагрузку на дисковую подсистему и увеличить про

изводительность.

Одной из особенностью работы со сжатыми таблицами на уровне SQL - это то, что и в буферном пуле данные хранятся в сжатом виде. В моем случае, вместо одной таблицы на 90 ГБ в память стало влезать 6 больших таблиц. Мои тесты показали (в конкретно моем случае, это важно!) снижение нагрузки на дисковую подсистему до 40 (!!) раз. Увеличение производительности по некоторым операциям до 10 раз. Снижение размера базы примерно в 2 раза (не все таблицы сжимал, основаня задача была - работа с производительнстью). Ну и много другого еще. Рекомендую проанализировать возможность использования данного инструмента, если база достаточно большая.

При этом потери на CPU я замерить не смог, все было на уровне статистической погрешности. Для тестов/анализа использовал zabbix, Аннализ длинных запросов Гилева и инструменты MS SQL

(0) >Можно ли средствами SQL получить аналогичный результат?

А зачем, с какой целью? Места на диске жалко?

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

(0)Купите диск и не экономьте на туалетной бумаге.
"Сжатие" базы выйдет дороже. Вообще не вижу смысла сжимать базы, если регламентные процедуры успеваете сделать в отведенное время.

(28) Можно подумать, что несжатую восстанавливать проще...

(3) если диск 2 ТБ а база 1,7 ТБ, пора писать служебку на покупку нового диска/рэйда. Снимай с себя ответственность за будущее падение базы

(25) Это сильно зависит от содержимого таблиц. Если у тебя там сплошные гуйды, то не поможет. Если много длиннннннннных строк - тогда да.

(25) Это работает, если питекантропы вытаскивают все из таблицы сканами. Когда запросы написаны верно, это не работает.

Ну, в принципе, хороший инструмент, если ты не можешь п^&*ить металлической табуреткой утырков.

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

Собственно, в наше время 1.7 Тб это копейки. У школьников-геймеров жесткие диски по 4-8 Тб

(33) Ага. Есть строка "наименование продукта". И поиск по ней идёт по ПОДОБНО. Кого будем табуретками?

(35)
Не все же такие умные, тут критичные проблемы 5-минутного исправления в 1с с 2012 года висят, а вы про диск начинаете. Я вас умоляю )