Просьба помочь решить ребус.

Серверная версия SQL 1С:Предприятие 8.3 (8.3.20.1674) Бухгалтерия предприятия, редакция 3 (3.0.105.14)

Сразу скажу что я не 1С-к я системный администратор. 1С-ники на аутсорте говорят что просто много
данных. База ведется с 2015 г., но внятно объяснить почему такая разница между SQL и dt-шкой они не могут

Понять почему база стала такой большой.

База весит 164 Гб. При выгрузке в dt файл 5 Гб

Что было проверено:

1. Выгрузка в dt-шку и загрузка в чистую SQL базу результатов не дала, размер базы остался таким же.
2. В SQL-ке к этой базе ежедневно применяются:
    a. Перестроение индекса




Серверная версия SQL 1С:Предприятие 8.3 (8.3.16.1814) Управление торговлей, редакция 11 (11.4.13.103)

(104) А вижу)

Установить минимальный хранимый период итогов регистров бухгалтерии, например, 01.01.2019г. Для верности можно и 01.01.2021г. поставить.
Выполнить пересчет итогов.

Установка минимального хранимого периода итогов регистров доступна через "Функции технического специалиста..." (раньше называлось "Все функции") - "Стандартные" - "Управление итогами", нажать на форме управления итогами внизу гиперссылку "Полные возможности".

(104) Может в каком-то большом регистре у тебя текстовые ресурсы/реквизиты, которые прекрасно сжимаются?

Коллеги я на связи, спасибо ВСЕМ, но меня тут озадачили другими проблемами. Как время появится сразу попробую все ваши советы из последних сообщений.
И соответственно отпишусь о результатах.

(136) Это только для регистров остаточных, для оборотных такого нет.

Может поля НЕОРГАНИЧЕСКОЙ длины )

(139) Да класть что на остаточные, что на оборотные.
А автора ветки, судя по (104), проблема с регистром бухгалтерии.
Сократит период хранения итогов одним-двумя годами, таблицы итогов немного уменьшаться в объёме.

Хотя конечно это не объясняет феномена, когда выгрузка в dt занимает объём в 30 раз меньше, чем сама база. Если бы таблицы итогов регистра бухгалтерии не выгружались бы, то был бы понятно. Но, вроде как, все говорят, что таблицы итогов выгружаются в dt вместе со всеми остальными данными и так же загружаются в базу без дополнительного пересчета.

(141) Что то я сомневаюсь, что итоги выгружаются.

(141) В (104) РБ даже не в первой тройке.

Еще раз обращу внимание на (32). Только на днях разбирался т таким случаем, правда в файловой.

(142) Не сомневайся.

Может у него в этих регистрах 10 измерений и 1кк записей ? Вот вам и раздутые итоги
Количество измерений по самому толстому регистру и количество записей в нем в студию

я верю скулю, который показывает

а) 98% дырка от бублика
б) база никогда не бэкапилась
ну и dt 5 гигов, что похоже на правду, в которой мдф должен 3 гига весить.

(146) > ну и dt 5 гигов, что похоже на правду, в которой мдф должен 3 гига весить.
Похоже на правду? 5 гигов архива без индексов поднимаются в 3 гига mdf? Фига себе, до чего скульная техника дошла. А если еще и компрессию включить - это ж вообще коммунизм настанет.

Если отталкиваться от (18), то индексы занимают как минимум половину базы.

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

(147) ну.. про 5 гигов в dt, это слова автора, а ему веры нет.

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

(151) Скриншоты сделаны с базы развернутом на тестовом сервере. На боевом сервере база бекапится!!!

(152) ага, оно и видно - что размеры разные, где-то 160, где-то 170..

(152) что еще ты забыл упомянуть ?
Что это разные базы ?
:))))))))))))))

(151) И подскажите как вы по (96) понимаете бекапится база или нет, мне для саморазвития надо?

(155) там так-то по -русски написано время последнего бэкапа базы и лога

если че, там указывается дата и время фулл бэкапа (разностный не учитывется)

(153) Мне кажется мы взрослые люди, какой смысл мне обманывать, если я заинтересован в решение своей проблемы и соответственно в предоставлении всей нужной информации для ее локализации.

(158) ну и делай, как в (36) или (78)

(158) а так, ты показываешь картинуи с разных баз и разных серверов..хз, чего там на самом деле.
В той базе, что в (0) и где 98% пустоты..это какая база ?

Так-то я могу тебе любые такие картинки слепить - поднять базу в 300 гигов, показать 1 картинку, сделать truncate table 98% ,базы и показать, что дескать она сейчас 3 гига..
Варинат ? Вариант.
А потом с другого сервера показать другие весёлые картинки.

(161) Какой смысл мне предоставлять искаженную информацию?

(162) откуда я знаю ? Зачем ты нам показывал картинки не соответствующие действительности ?

Покажи все картинки с одного сервера и одной базы.

А лучше с той, где при шринке база в 3 гига должна быть

И я верю скулю.

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

https://d.radikal.ru/d34/2202/a0/5d837cf01c86.jpg

https://b.radikal.ru/b00/2202/12/e7a83859ab6e.jpg

(164) (165) :)) Не может база с миллионом строк документа весить 3 ГБ. Видимо криво учет ведется и регистры не закрываются, вот итоги и висят и обороты.

(163) Скриншоты с реальной базы на реальном сервере. Какую еще информацию нужно предоставить?

(166)
ну вот видишь, тут уже не 98% пустоты. Значит в (0) - полная дизинформация была.

И покажи еще картинку сжатия лога - выбери там журнал в сжатии

(100) место на диске осталось 100 гигов, боюсь на боейвом сервере не хватит для выполнения ваших рекомендаций. Если только на тестовом серваке

(171) нужно получить соответствие таблиц через (выводит названия таблиц в терминах SQL и 1С)
ПолучитьСтруктуруХраненияБазыДанных()
чтобы понять какие это регистры накопления топ 4 по размерам и итогам

(170) https://b.radikal.ru/b40/2202/e6/f972a053cb09.jpg

(173) ты издеваешься что -ле ? Это другая база

И скуль смотрю, 2008 чегой то стал..

:))

Хотя, Ssms можно и последний поставить и к старым версиям бегать

(173) и опять другая база на картинке.
(0) даже тут упоминается Бухгалтерия, а ниже - УТ и платформы разные
Два предположения:
1. банально путаешь базы - делаешь выгрузку в ДТ из маленькой, загружаешь фиг знает куда, смотришь на третью
2. у вас в базе есть злодейский регламент - пишет огромную таблицу и очищает ее, в разные моменты времени ты видишь разный результат

(178) Я везде писал про Бухгалтерию. Про УТ - я нигде не писал!!!

(179) то есть последняя строка в шапке не относится к делу?

(175) Нет. SQL 2012 на боевом сервере на тестовом 2019

(180) Нет. Она случайно попала в пост, когда его писал. А редактировать посты здесь нельзя!

(174) Извиняюсь. Действительно скриншот журнала не правильный.

Вот верный https://d.radikal.ru/d09/2202/6e/595c4ee9bd7f.jpg

(183) ну вот эта база, в 5 гигов в dt ну никак не выгрузится.
Каков реальный размер dt ?

Интересно а зип бомбу из dt можно сделать?

(183) теперь покажи для этой базы, ПКМ на базе - отчеты-стандартные отчеты - количество памяти занимаемое верхними таблицами

(0) тут уже кажется говорили
MSSQL резервирует под себя место, чтобы файлы потом меньше по кускам на диске были и не тратить время на увеличение файла при добавлении строк. Когда много добавлений/удалений, то файл только растет. Чтобы убрать резерв (реально он такой большой не нужен), есть сжатие базы (освобождение пустого места). В (11) на скрине видно, что уменьшить базу можно чуть более, чем до 3х гб. Потом она опять начнет расти. Лучше уменьшать не до 3х гб, а до 5 например, тогда это не скажется на производительности. Плюс поставить автоувеличение не в процентах, а в мегабайтах, например по 500мб.

(184) 5 Гб. Не знаю как вам доказать.

(187) он уже исправился, то что  в(11) - вообще непонятно откуда, реальная база в (166)

(188) выложи на файлопомойку, ссылку сюда..

(186) https://b.radikal.ru/b39/2202/2e/2459ff377923.jpg

(190) При всем уважении к Вам, как то не хочется отдавать базу в общий доступ.

(191) ага, интересная база.. Это точно бухня ? Открой структуру хранения базы, и скажи нам, что там за оборотный регистр из №1 в рейтинге ?
и еще один, останоковый с незакрытыми остатками.

(192) да кому она нужна то ? На мыло кинь ссылку [email protected]

(191) оочень интересно посмотреть на регистр оборотов, у которого итоги на 13Гб, а основная таблица даже в топ не попала. Что за регистр 19965?

Вот регистр бухгалтерии на 2 гига, еще туда сюда, но вот всё что выше - загадка.

(195) ага, я не помню зха структуру бп.. там точно есть оборотные и останковые регистры ?...

(197) да там куча оборотных - КУДИРы, НДС, НДФЛ и т.д. Но они не такого размера должны быть. И их итоги никак не будут больше бух регистров

(193) Как и чем открыть обработкой какой-то специальной?

Любой обработкой, которая структуру хранения показывает
Например, вот этим https://github.com/alexkmbk/1CDBStorageStructureInfo/releases

(199) https://www.upload.ee/files/13896123/________________1__SQL___________20200723_2005.erf.html
Вот базопузомер. Показывает полную информацию по таблицам в 1С.

(195) Вот https://d.radikal.ru/d13/2202/02/003380d5a8ce.jpg

(202) Покажи отчетом из (201)

(202) О_о, ИПшник с базой на 160Гб
Сдается мне, что 1С не особо оптимизирует Буху под ИПшников. Ибо обычно это 10 операций в месяц.
А у вас, судя по всему куча номенклатуры и документов поступления/реализации.
Надо показать базу специалисту и, скорее всего, просто свернуть на начало года

(203) При запуске вот что пишет:
{ВнешнийОтчет._СвойстваОбъектов1СВSQL.МодульОбъекта(112)}: Ошибка при вызове метода контекста (Open): Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): При входе в систему пользователя "sa" произошла ошибка.

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

Ну так пароль правильный для sa  нужно указывать.

(205) Да и нечего там смотреть. У вас ИП с большим количеством поступлений/реализаций. В бухе регистры под ИП сделаны не особо хорошо, т.к. у большинства ИП не так много операций в месяц. База получается большая. Либо расширять сервер, либо сворачивать базу. Если проблема только с местом - расширить его дешевле, чем заморачиваться со сверткой. В свернутой базе эти регистры будут расти такими же темпами.

(208) Допустим вы правы, как логически объяснить почему dt-шка базы весит 5 Гб?

Все че-то забыли про 5 гигов а dt, ну и ладно..

(209) её никто не видел, это миф.

(209) тебе уже обьясняли. Итоги и обороты в dt не хранятся. Когда из dt разворачиваеш, итоги рассчитываются.

(211) Можно верить или не верить но dt-шка 5 Гб

(212) Если это действительно так, то возможно это объясняет малый размер dt-шки

(209) Я выше уже пытался объяснить. Во-первых, индексы больше половины места у тебя занимают занимают (в dt выгрузка без индексов, ессно). Плюс в mdf есть свои доп-издержки на место, ибо упор на максимальную производительность. Остальное - архивирование. Базы жмутся ОЧЕНЬ хорошо. dt - это АРХИВИРОВАННАЯ выгрузка данных.

(212) итоги как раз хранятся

(210) Ну, теоретически - в таблицах ИПМПЗ все измерения, кроме Партия и ДокументОплаты одинаковые. Вот они и сжимаются хорошо. Ну и индексы - там же по 10 измерений.

+ Там же получается, что по сумме эти три регистра и их индексы занимают больше 130Гб.

(217) как объяснить 1 млн строк в ТЧ документа (максимальный какой увидел) и 43 млн в регистре накопления (основной)?
Все через корректировки гоняют?

КУДиР разве что лопатит так, может ошибки в настройках или учете.
Интересно было бы динамику посмотреть, сколько таблицы занимали и сколько записей 3 мес назад. Возможно, по геометрической прогрессии пошло.

(219) "По фотографии" сложно диагноз ставить. Возможно там поступления/реализации оплачиваются 10 частями в разных месяцах, а может косяки в партионном учете или настройки учета кривые. Не держа в руках базу можно только гадать.

(220) А что бы не посмотреть
(0) Вот результат запроса нам покажи по первым, 6 самым большим, таблицам регистров.
SELECT        _Period, COUNT(*) AS Kolichestvo
FROM            _AccumRgTn4251
GROUP BY _Period
ORDER BY _Period

(213) если средствами SQL сделать бэкап (со сжатием) то там тоже не 170, а гигов 15 будет.

включил полнотекстовый поиск- база в 2 раза больше.
правильно говорят, отключи ненужные фишки.

(222) Если сделать запрос по регистру  _AccumRgTn19965 т.к. _AccumRgTn4251 такого нет.

Вот сохраненный результат запроса в формате csv
https://dropmefiles.com/kC5kI

(223) Да. Размер SQL архива примерно 15 Гб

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

(226) Покажи структуру нескольких _AccumRgT*, которые в топе.

(228) из конфигуратора или как?

(229) Нет, из SSMS

(223) Фига себе, у тебя глаз-алмаз!

(231) это опыт.. который с одной стороны не пропьешь, ибо завязал давно, а с другой стороны - не особо релевантный, поэтому работодатели за него особо не хотят платить.
им всем молодых да с спецами по ЕРП/ЗУП/БП/УТ/КА всеми вместе подавай.

(232) БитФинанс+Битрикс и сертификаты Эксперт будут вашим преимуществом

(233) тонко)