Добрый день, уважаемые. Не приходилось такие большие dt разворачивать, ранее проблем не было.
за 18 часов из dt на 10 гигов получилось 25 гигов mdf и 40 гигов ldf, и висящий конфигуратор.
Конфигуратор прервала, но  база осталась не работоспособной. Отсюда вопросы:

в1. почему в выгрузке ДТ содержатся транзакции, вроде никогда такого не было.
в2. как такую большую базу все таки развернуть, если ничего кроме ДТ нет?
в3. не позорно ли пытаться dt базы из 8.2 разворачиваю на 8.3 ?

о1. ШТА????
о2. Взять сервер помощнее
о3. Обычно прокатывает

Откуда изначально дт выгрузили?

А так, идет пересчет служебных данных и итогов при загркзке из дт. Отсюдаирост лдф

(2) со скуля, из базы wms на последней версии платформы 8.2
(3) спасибо, не знала. я ограничила до 2 гигов лдф и получила ошибку при повторной попытке.удивительно что 40 гигов раздуло

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

(4) "я ограничила до 2 гигов лдф"

За такое в приличном обществе бьют канделябром.
А в неприличном этот канделябр засовывают в ....

(5) "если ничего кроме ДТ нет?"

(4) "вы там кем?" (с)

Короче, скулю нужно дать права для изменения томов диска в локальной политике сервера. Тогда развернется..за минут 10

https://its.1c.ru/db/metod8dev/content/5904/hdoc

(5) ну если, уважаемые люди советуют забить на 10 гиговый дт и спросить скулевый, то так и сделаю
(9) спасибо, пошла гуглить как это

(10) спасибо, попробую и отпишусь

(9) проще задать лдф 2ТБ

(0) мониторить процесс разворачивания надо
по профайлеру ... а не по залипшему конфигуратору.

(9) блин в обслуживании томов уже есть NT SERVICE\MSSQLSERVER, а вот в блокировке страниц не было, добавляю. проверяю... прошло 20 мин не загрузился, буду ждать. я правда не перезагружала службу, потому что работа идет.

(0) 1. Загрузить dt в файловую - проверить что оно работоспособно
2. Сделать ТиИ (с пересчетом и сверткой) и заново выгрузить в dt

А может рост по 512 КБ?

(0)
dt - текст , пожатый deflate.

соответственно из него можно перенести часть таблиц в dt- поменьше . загрузить их с разные базы и затем либо объединить в одну
либо заменить представлением.

(16) превышен допустимый размер 1CD. менять размер страницы не охото
(17) рост опставил по 512 МБ
(18) мсье знает толк)

Скиньте dt на
liveups@yandex.ru
посмотрю

(0) сделай режим восстановления режим simple. Загрузи и обратно верни как было. И вообще пригласи специалиста. 10гб, это вообще не о чем.

(21) Кстати Dt жатый ведь, он гигов в 50-80 развернётся? Или я что то не так помню. С dt лет 13 дел не имел.

(22) во сколько он там развернется, это только один эскуэль сервер знает. После разворачивания shrink делать желательно.

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

Ну вернее. Я когда последний раз боевую базу данных разворачивал и с dt, а это было лет 10 назад.  Переводил базу в simple, загружал дт. Делал шринк файлов, потом дефрагиментацию, реиндексацию средствами эскуэль. Потом переводил в режим фулл или дифференциальных копий.

(0) Диски хотя бы SSD ? Из такого dt можно и 150гб базу получить.

(21) сделал, то же самое, загружается сутками
(20) не могу
(26)(1) 50 GB ECC DDR4, 600 GB SSD, 16 * 3 GHz  Xeon Gold 6154

(22) у нас 25Гб база Бух 3 выгружается в 2,5 гб дт.
соответственно у автора порядка 100 гб будет +/-

На время загрузки можно задать max degree of parallelism равным 0, индексы будут создаваться параллельно, следовательно быстрее.
Памяти мало для такой базы.
(28) За какое время?

(27) сделал или сделала ?

ЗЫ: давно бы уже поднял(а) скулевый архив, раз с дт не выгодит

(29) почти час. но там сервер не супер. в общем, делается сие действие редко так что всех устраивает.

(27) С сервером что-нибудь происходит? Интенсивный обмен с диском, одно или несколько ядер заняты долго на 100%, при нехватке памяти система лезет в своп и застревает там надолго? Или это все у вас на виртуальных машинах?

в общем нужны показатели загруженности серверов 1С и SQL во время загрузки из дт. Так же можно зайти в SQL и посмотреть активные запросы, они там долго должны висеть и можно хотя бы приблизительно смотреть меняются ли они со временем

(33) песполезно.

Миллионы мелких запросов к config там не будут фигурировать, потому что они немного отличаются текстом

(34) шанс есть т.к. медленно отрабатывает, но надо вначале посмотреть кто именно тормозит в свзяке. Да и большие таблицы должны быть и они туда точно вылезут

может там автоприрост размера базы sql установлен по 5 Мб, и лога так же, вот он и дрыгается туда сюда постоянно выделяя место.

(36) +1

(32) На виртуальной, особой движухи нет, но ещё реальные пользователи работают параллельно, просадки производительности не видно.
(36) (37) нет, 512 МБ ставила прирост, в симпле. Получила бак, он 80 гигов, разворачивается на 260 Гигов, машина на виртуальном хостинге

(38) ну вот и ответ - основные данные у вас - таблицы итогов. Можете сами проверить это любым базопузомером.
Видать регистры не закрываются нифига

(39) Как по размеру sql-ного бэкапа .bak (очевидно - сжатого) ты сделал вывод о структуре регистров в 1С?

(40) ве- 10 гигов

+41 *dt

если dt в 10 гигов разворачиваются в 260 в скуле, то очевидно, что бооольшую часть там занимают файло итогов

(43) У меня 20гб dt разворачивался в 400 на SQL. Никаких незакрытых регистров не было, поэтому я бы не был столь категоричен.

(44) и всегда размер файла итогов меньше чем движений ?

(44) и..сжатие таблиц хоть в скуле включено ?

(46) У нас сжатие таблиц не применимо из-за версии SQL. Даже бекапы не сжать.
По самым большим остаточным регистрам итоги составляют 3% от движений.

(47) тогда не понятно, что там у вас 400 гигов место занимает..есть картинка с базопузомера какого нить ?

версионирование включено ?

(49) У нас самописка, всё давно вылизано, лишнего нет. Просто операций много.

ради интереса, выгрузил базу. мдф 142 гига в дт 24 гига. В скуле сжатие на всех табличках

и..у нас 2 плана счетов, двойной учет в регистрах, несколько фирм+алкашка с марками..

да и то, можно еще ужать, если табличку от рс.версионирование объектов свернуть

(48) очевидно что регистр бухгалтерии, значения субконто

(51) и как оно со сжатием бегает? Я бы таким на рабочей базе не баловался

(55) нормально бегает, разницы не видно

(56) и после каждой реструктуризации пережимаете? какая версия платформы?

(57) за сжатие отвечает dll триггер

пока 15, всё лень на 17 перевести, работает и ладно

но сжатие включено еще со времён 8.2

(60) может с версии 8.3.12 пережимать не нужно? надо проверить это

https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/

(54) (48) У нас так: https://yadi.sk/i/2OeFCOokNT9d5A  (вся база уже 1.2Тб)
Регистры сведений больше всего отжирают, но они нужные (цены), версионирования нет.
А бухгалтерские регистры - копейки, 7% от базы.