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

Серверная версия 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)

(0) если база в фул моде и не транкован лог
если база в любой моде и не делается шринк


[В SQL-ке к этой базе ежедневно применяются:
    a. Перестроение индекса]
это 1/5 стандартных регламентов, прописанных в документации на 1С

(0) Нормальное сжатие SQL базы, если там нет картинок 1 к 10. То есть 164 Гб база, должна весить примерно 15-17Гб.
Скорее всего не настроено shrink в SQL, данные мусорные копятся.

b. Обновление статистики
c. https://1cers.ru/
d. DBCC FREEPROCCACHE

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

b. Обновление статистики
c. DBCC FREEPROCCACHE

1-к 10 обычно, посмотри размеры таблиц для начала

(4) ещё раз, чей размер приведён в сообщении - mdf или ldf
в какой моде база
когда последний раз сделан шринк, с какими настройками

(0) А что мешает посмотреть размер таблиц в SQL.
С учетом "выгрузка в dt-шку и загрузка в чистую SQL базу результатов не дала" главный подозреваемый - итоги регистров. Но 170ГБ это очень много

В MSQL SMS не дает сжать базу через интерфейс:

[url=https://radikal.ru][img]https://b.radikal.ru/b20/2202/a0/67824beb7ba5.png[/img][/url]

(8) сжимай командой

В MSQL SMS не дает сжать базу через интерфейс:

https://b.radikal.ru/b20/2202/a0/67824beb7ba5.png

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

(8) ясен пень, шрин даст только после бэкапа сделать

Как смотришь "база весит" - на размеры mdf/ldf?

(11) сжимай не базу, а ФАЙЛ

Да нифига не надо сжимать, если кушать не просит. А без предварительного анализа на потенциал "сжатия" - и подавно.

(13) размер mdf - 164 Гб

Размер таблиц:

Размер таблиц:
https://a.radikal.ru/a07/2202/e7/020c72527952.png

А если включить сжатие таблиц.. там не 3гига база будет, а все 500 метров

(11) я вижу 98% свободного места

(20) то есть база может сжатья примерно на 2 Гб. Сами понимаете это очень мало

(21) это нормально, в реальности, метров 500 или меньше

(0) А в чем проблема с размером? База плохо работает или что?

А разница между SQL и dt объясняется тем, что dt сжатый.

(21) Нет! Там же написано минимум 3072 - это прогноз конечного размера базы при максимальном сжатии

AccumRg19932

РегистрНакопления.ИПМПЗОтгруженные

Размер данных 10 429 512
Размер индекса 8 376 680
Общий размер 18 806 512
Количество строк данных 49 540 167

может итоги какого нибудь регистра?

(18) Хм... Странно...
Да, много занимают итоги регистров. И из них много занимают их индексы (возможно есть "лишние").
Причем мне недавно убедительно доказывали, что выгрузка в dt происходит вместе с итогами. Что косвенно подтверждает тот факт, что загрузка dt в пустую базу результатов не дала.
Получается, что просто хорошо жмется все это дело при выгрузке в dt. Можно попробовать полный пересчет итогов, но неизвестно сколько он займет и вряд ли будет такой уж большой эффект от удаления лишних записей таблиц итогов. Короче от тебя как от админа тут мало что зависит. Нужно анализировать ситуацию из прикладной части.

(0) Покажи свойства FILES системной базы model
(25)Посмотри регистр вручную, с сортировкой по самой ранней даты - может там типа дата 1800 ...

можно установить период итогов.
Наверняка где то есть записи с ошибочными периодами а ля 01-01-0222

А когда разворачиваешь базу из DT какой размер?

(30) получается такой же большой как и в реальной базе

(27) Возможно, итоги распухли из-за разделителей.

(21) то есть база может сжаться на 159816MB

(27) да, это так. в dt в 8.3 с итогами выгрузка.

Если учесть, что таблицы движений регистров тоже много места занимают, то похоже что одинэсники могут быть правы. "Просто много данных".
А разница просто на эффективном сжатии.

Короче, автор.
Сделай бэкап базы, потом шринк, потом это
EXEC sp_MSforeachtable 'ALTER TABLE ? REBUILD WITH (DATA_COMPRESSION = PAGE)'
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)'

потом еще раз шринк.
И твоя база будеи весить метров 300.

(36) Вы мне предлагаете сжать таблицы в БД, я верно понимаю, но как это повлияет на производительность, то есть нагрузка на сервер при работе с данной базой увеличится?

(23) Большая база, тяжело северу. И мне как технарю не понятно почему такая разница в размере между dt-шкой и SQL ной базой

(37) никак не повлияет.
Для такой детской базы это не заметно

(38) А как проявляется это "тяжело"? И точно ли это связано с размером?

(38) большая база в 3 гига ? Серьёзно ?

авторасширение какой хоть стоит в свойствах базы ? Поди 10% , да ? :)

(36) Ага, и вместо "тяжело" ей станет "очень тяжело". Аккуратнее с такими советами.

(41) ну если "гигантская" - 6, то почему бы не быть "большой" в 3 ?

(28) https://b.radikal.ru/b43/2202/41/38e78ceca8d9.png
(28) Посмотрел - дата 2016 г.

(45) да уж..еще и на системном диске база валяется..

(41) Почему 3 Гига. SQL база весить 164 Гб !!!!

Вообще выгружать в ДТ базу размером 170 ГБ моветон.
Не выгружайте и не будет знать разницу.
В скуле луче проведите работу с базой как настойщий админ. быть может база уменьшится.
И еще Пусть 1С спец проанализирует базу на аредмет раскер таблиц и где может подссократит.

Недавно я базу в 170 ГБ сделал в 120 ГБ. Абазу 270 ГБ в 220 ГБ.
Просто убрал не нужный мусор из базы.

(46) опередил!
там же наверняка и темпдб...

(47) 98% пустого места. Тебе там же указано реальный размер базы.
Всё остальное - пустое место

(47) а данных там на 3 гига. в эих 164Г - 98% пустого пространства

*  аредмет раскер =  предмет размера

(38) В чем выражается "тяжело серверу"? Если упираешься в i/o, то сжатие таблиц в самом деле может помочь (если твоя версия сиквела его поддерживает и по cpu есть резерв). А разница в размерах - на сжатии (базы 1С обычно очень хорошо жмутся) плюс сиквел держит данные несколько размашисто. Всегда больше занимает, чем файловая версия.

(49) не, это модель, база может и где еще, хотя, сумневаюсь.

(46) Чем это плохо?

(48) выдыхай!
(54) база на  d:

(50) Нет вы не правы. По вашему утверждению база сожмется до 3 Гб?

(57) да.
Но реально можно сжать до 300-500 метров.

если включищь сжатие таблиц в скуле

У меня не складываются скриншоты из (11) и (18)
В (11) показывает 3 гига данных.
В (18) - что заняты почти все 160 гиг
В чем прикол?

При этом не забываем, что загрузка из dt в пустую базу не дала эффекта. То есть все варианты со шринками в пролете.

(60) А где на (11) скриншоте вы видите 3 Гига. Там - выделенные данные 162888,00 (МБ) то есть база занимает 162 Гб. Что не так?

(62) ну ты тугой.. минимум - 3072 Мб, до этого размера может сжать прям щас.
Если включить сжатие и сделать ребилд, будет метров 300-500.

Тока он шринк тебе не даст сделать, пока бэкап не сделаешь.
Вы бэкапы хоть делаете, иногда ? ?)))

(61) ТИИ полное перед выгрузкой dt сделать

(64) каждую ночь

(62) Сравни с моей базой http://pics.rsh.ru/img/0001_jztwwkx2.png
Свободное место - 0%

(62) Выделенное всегда включает в себя и свободное, которое ниже. Разница как раз три гига, до которых он и позволяет якобы ужать (еще ниже - минимальный размер файла после сжатия). Выделяется всегда заранее (потому что каждый раз у операционки выпрашивать - дорого). После объемных реорганизаций базы может много свободного места внутри выделенного остаться.

(63) если сжимать таблицы, возможно во и правы, а если без сжатия то согласно моему скриншоту база уменьшится до 159816,13

Но на скриншоте из (18) показывает совсем небольшое количество свободного места. Поэтому у меня когнитивный диссонанс.

(68) еще раз, до 3 гигов.

(71) Еще раз. Как ты объяснишь данные со скриншота в (18)?

(72) показывает тебе размер, который в данный момент имеют все странички

и.. в dt база всего 5 гигов.

(73) Там отдельная колонка для свободного места

(74) Да!

(74) Если в скуле можно ужать до 3 гигов, то в dt оно бы весило мегабайты.

(0)
на вот, запусти это на ночь


USE IC_buh
GO

DECLARE @FileName sysname = N'IC_buh';
DECLARE @TargetSize INT = (SELECT 1 + size*8./1024 FROM sys.database_files WHERE name = @FileName);
DECLARE @Factor FLOAT = .999;

WHILE @TargetSize > 0
BEGIN
    SET @TargetSize *= @Factor;
    DBCC SHRINKFILE(@FileName, @TargetSize);
--    DECLARE @msg VARCHAR(200) = CONCAT('Shrink file completed. Target Size: ',
   --      @TargetSize, ' MB. Timestamp: ', CURRENT_TIMESTAMP);
    DECLARE @msg VARCHAR(200) = 'Shrink file completed. Target Size: '
    +cast( @TargetSize as VARCHAR(20))+' MB.'+ cast(CURRENT_TIMESTAMP as varchar(20));
       --  @TargetSize+ ' MB. Timestamp: '+ CURRENT_TIMESTAMP;
      
    RAISERROR(@msg, 1, 1) WITH NOWAIT;
    WAITFOR DELAY '00:00:01';
END;

Можно и увеличить степень шринка, но, этот скрипт можно и на работающих пользаках запускать, не заметят

(79) Как твое зацикливание на шринке объясняет неизменный размер после загрузки из dt?

(77) в старый версиях платформы, так и было, когда итоги регистров не выгружались в dt. Щас не так, и размер почти сопоставим с mdf

(80) где автор говорил, что он загружал что-то из dt?

(82) В (0): Что было проверено: 1. Выгрузка в dt-шку и загрузка в чистую SQL базу результатов не дала, размер базы остался таким же.

+ он так и не показал свойства базы и размер авторасширения.
Возможно, у него изначальный размер базы стоит в 150 гигов+ авторасширение 10 %

(82) Да я пробовал загружать из dt в чистую базу SQL

(82) В нулевом посте.

(85) покажи свойства базы.

И запусти, наконец, уже (78).

+ бэкап, надеюсь, средствами скуля делаете ?
Или считаете, что бэкап - это выгрузка в dt средствами 1с ?

(87) https://a.radikal.ru/a04/2202/5e/d8c988e5a2ed.png

(89) Да, средствами SQL

(0)
ТИИ (реструктуризация, пересчет итогов, переиндексация) + шринк + ТИИ (пересчет итогов, переиндексация)

(91) покажи вкладку общее для этой базы

(91) из скриншота в (11) выбери 2. пункт для сжатия файла (реорганизация) и укажи минимальный размер руками.
Желательно, чтобы с базой никто не работал - операция SHRINKFILE может блокироваться активными транзакциями.

EXEC sp_spaceused

(93) https://a.radikal.ru/a17/2202/72/454e622cb402.png

(45) Итоги по какую дату рассчитаны? Может намного вперед рассчитали?

(92) Что за культ ТИИ? Нафига оно в данном случае, можешь объяснить.

(95) https://a.radikal.ru/a32/2202/af/9735cca318e8.png

(98) реструктуризация, сжатие, пересчет итогов

(100) И? Цель каждой из этих операций, в данном конкретном случае?

(100) Разве при загрузке из dt-шки не проходит процесс реструктуризации?

(97) Рассчитаны на 31.01.2022

Еще раз хочу обратить внимания - если смотреть отчет SQL ника по размерам таблицы, то таблицы с "регистрами накопления" и создают основной размер БД

Вот: https://d.radikal.ru/d16/2202/97/03a2099850b7.png

Мне кажется как то в этом направлении надо двигаться

(72) >Еще раз. Как ты объяснишь данные со скриншота в (18)?
У меня тоже пишет ерунду при шринке на MSSQL 2019 + SSMS 18.10:
Сжать дает до 2.9Гб, а таблицы все весят 29Гб. После шринка никаких 2.9Гб нет, так и 29Гб остается.

(96) ага, резервного копирование не делаешь, значится..

а говоришь, каждый день..

(103) А если так?
SELECT  MAX(_Period), MIN(_Period)
  FROM _AccumRgTn19965

(104) Ты так и не объяснил, нафига куда-то двигаться, какие конкретно проблемы с текущим размером БД. И как они решатся, если размер уменьшить.

Были ли эти проблемы, когда размер был на 10 Гб меньше? На 50 Гб меньше*

(99) Это согласуется с (18). Только с (11) непонятки. У меня данные в мастере сжатия согласуются с данными sp_spaceused
Попробуй еще раз открыть диалог (11).

(104)
>2. В SQL-ке к этой базе ежедневно применяются:
>    a. Перестроение индекса
В этом суть, регламент не анализирует какие таблицы надо обслуживать, а какие нет. Из-за этого после регламента база весит в 2 раза больше. По картинке это как раз и остлеживается.

Да что вы спорите, не со скулем у него проблемы.

(109) Тяжело серверу работать с этой базой, много места она занимает. Много оперативки нужно для такой базы. У меня массив из SSD дисков 400 Гб и место заканчивается.

(111) и ? у меня там есть и другие базы обслуживаемы так же и у них с размером все нормально

Покажи сжатие файла и выбери журнал.

И архив, наконец, сделай в этой базе.

(114) Видимо, не так активно используют регистры накопления.
Первые 4 - это какие регистры? Типовые или дописанные под заказчика.

(114) И нормально это как? Размер БД также в 2 раза больше чем отчет по размерам таблиц?

(108) https://b.radikal.ru/b00/2202/42/df39eef2be55.png

(118) Ты видел, что он писал? Выгрузку - загрузку через ДТ произвел и результат не поменялся.

(120) ага, а еще написал, что архивы за каждый день, а по факту их нет..

Одна из черепашек врёт

(119) Попробуй еще раз посмотреть на данные мастера сжатия (11). Только они выбиваются из общей картины и смущают народ.

И покажи, что кажет (115)

(120) так загружали в новую чистую БД, по отчету таблиц вижу что размер БД с индексами ~80Гб и увеличение до 160Гб нормально если каждый день полностью перестраивать таблицы без разбора. Есть скрипты, которые перестраивают только нужные таблицы (какие-то дефрагментируются, какие-то полностью перестраиваются).
Итоги тоже непричем, как и регистр бухгалтерии. Что-то активно пишется в регистры накопления (Меркурий, ЕГАИС или свой оперативный учет).

(96) Что у тебя происходит? Откуда ты скриншотишь? В (18) совсем другие данные. Куда делись таблицы итогов? С такой подачей инфы и уровнем анализа мы далеко не уедем.

(125) Да и самый большой документ с 1 млн строк в ТЧ, а в регистрах накопления записано 118млн записей. Проблема в архитектуре конфигурации.

(119) Кстати нафига хранить рассчитанные итоги за все периоды.
В рабочей практике за глаза и за уши хватает двух-трёх последних лет (например, с января 2019).
А для текущей "оперативной" работы бухгалтерии (проведение документов) так и вообще - только последний год.

(119) Ну вот значит у вас столько оборотов и остатков. Только обрезать.

(126) было к (104)

(126) Видимо, второй скриншот без итогов сделан, а я на него опирался. Тогда вариант с х2 размером отпадает при обслуживании, надо регистры смотреть.

Ну вот, теперь никогда и не узнаем, сделал там тс шринк после бэкапа, или нет.

прибили тапком

(0) SQL запросом можно найти большие таблицы, а дальше по ситуации.

(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) тонко)