Добрый день. Подскажите, как узнать что именно занимает много места в файловой базе данных? Папка с базой весит 10 Гб.

а без базы (чистая) скока?
А то у мен БП 3 с данными 9, без 7

Зайти в папку и посмотреть или речь про 1сд файл?

(0) если сняли с поддержки, это еще мало

А так перевести на скуль и средствами скулы глянуть размер таблиц

(0) Кто и почему решил что 10 Гб - это много ?

База файловая. Перевести на скул - да вариант, но я пока не умею. У нас работает 3 человека в базе, небольшая компания. Конфа не снята с поддержки. Может есть вариант проще?

(2) да, про файл этот

10 гигов это не много, даже для файловой базы.
А по теме - Была обработка под названием "базопузомер"

(6)[ Может есть вариант проще?]
скачать с инфостарта прузометр для файловой базы, их там десятка 2

(9) не поможет

(0) Что за конфигурация? Сколько лет базе?

(6) Никакой скуль для 3 челов не нужен, за глаза хватит терминала. Ну ессесно должны быть SSD диски, как для ОС, так и для баз.
Оперативки: по 1 Гб(даже много) под терм. сессию, итого 3; под ОС сервера 2 Гб; под каждую конфу 1,5-2 ГБ, итого 4,5-6Гб. В сумме 16 гигов будет даже с запасом.
Сверхмощного и дорогого процессора не нужно.

Итого по деньгам выйдет 200 тыс. за железо и 100 за софт, всего 300 тыс. руб.

(12) это тут причем?

(12) Не в тему. SQL упомянули только из-за того, что там можно узнать размер таблиц без танцев с бубном.

точнее, 10Гб это размер всей папки с базой или файла с базой 1Cv8.1CD?
а то на днях клиент тоже прибежал с выпученными глазами, типа база 20Гб
оказалось, что 90% места занимал ЖР

Вероятно, а это только предположение, что в файловой базе много присоединённых файлов в хранилище данных. Но, опять таки имхо, - более правильно если судить о размере базы после ТиИ и/или (косвенно) по размеру *.DT

У меня база развернута, БП Корп, поддержка с редактированием, настроена с историей изменения на некоторые документы (косячили и сваливали друг на друга, пришлось сделать), файлы прикрепляют на файловую папку. База с 16 года.
Так вот, сейчас она = 9.4 Гб.

там же встроеная команда есть по метаданым показать размер

(14) А покупать скуль только чтобы узнать размер таблиц - это в тему ?

Пусть делает свёртку

(17) У меня выгрузка dt около 10 гиг; 1CD - около 40 гиг. Примерно 200 видов документов, основных видов - чуть более двух десятков и каждом виде примерно 30-60 тысяч документов... sorry, вся эта информация - это информация "ни о чём".

(21) Пока автор не озвучит, что за конфа? Смысла не вижу мерить у кого больше.

(0)
1. Глянуть файл ЖР.
2. Временно копию перенести в скуль и там глянуть размеры таблиц. Найди просто место где есть скуль временно на час хватит.
3. Как вариант напиши отчет по подсчету количества записей спр док РС РН итп через метаданные для каждого объекта будет хотя бы ориентир.

(19) зачем покупать?
есть же бесплатная комьюнити-лицензия

Кстати у меня база весила 220 ГБ ЗУП2 найдя мусор и удалив их база стала размером 90 ГБ

Почему-то никто Инструменты разработчика не упомянул, там же есть обработка Структура хранения БД.

(19) А про "покупать" - ни слова, никто и не предлагал. Есть много законных способов временно воспользоваться SQL.
(22) +1 у автора три калеки :) набивают базу - ясно/понятно, что не в документах и справочниках проблема.

(19) зачем покупать? скуль для разработчиков - бесплатно, 1с (серверная часть + клиентская часть) для разработчиков бесплатно
Развернул дом скуль поставил и посморел. никто не говорит пор переход для работы

Папка с базой - 9,4 GB
Файл 1СV8.1CD - 9,1 GB
Файл выгрузки 1Сv8.dt - 2,3 GB

Управление торговлей. Базе лет 5. Компания у нас не большая, 2-3 человека работаю с базой.

(0) Поди замеры производительности включены и вот эти регистры всякой статистики со временем распухли.

(29) начни с (26)
Может кто то кладр по всей России загрузил

(29) Конечная цель какая ? Наверняка же не просто любопытство, узнать что из таблиц в базе больше весит
Цель - решение проблем с тормозами. Или нет ?

Ну может место на телефоне где база лежит закончилось, вот и думает что удалить

(29) На первый взгляд мусора не видно. Я бы попытался загрузить базу в Microsoft SQL Server Express - вдруг прокатит.

предлагаю не долбиться в голову и просто развернуть Автономный сервер в постгре - это бесплатно. 3 юзера влезет. проблем с размером файла БД не будет.

(33) файловый блоб больше 4 гб без специальной СУБД - это всегда медленно и мучительно.

(29) ты деревянный что ли? ПолучитьРазмерДанныхБазыДанных()

(32) разумеется хочется убрать тормоза. Железо норм, ssd, 16gb ОЗУ. 1с лицензия. Понятно что есть другие способы ускорения, и их я тоже прорабатываю.


Про SQl, ну говорят что для 3х пользователей ну никак не нужна SQL.

(38) Начни с организации терминального доступа

Сжать базу не пробовали? В ТИИ?

УТ какая?
Включена ли там версионирование?

(0) это не большой размер для БП 3.0

переведи базу в режим web и убедись что на сервере у тебя диски ssd и памяти более 8гб


https://infostart.ru/1c/articles/691604/

(42) и да забыл платформа 1с на сервере обязательно x64

(0) https://infostart.ru/public/1765490/
https://infostart.ru/public/1083992/

на вскидку

(0) https://infostart.ru/public/176476/

(29) >Файл выгрузки 1Сv8.dt - 2,3 GB

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

(44) буду пробовать спасибо!
Платформа у меня как раз х32 к сожалению куплена.
Про конфиг сервера писал, ssd и озу 32 гб

(41) последняя, версионирование не трогал, полагаю по умолчанию выкл
(40) базу сжимал как раз перед созданием темы здесь
(46) когда говорят "10 гб много для файловой базы", подразумевают же не dt, верно?

(47) раньше было много. Сейчас один cf больше гига может весить? Плюс конфига поставщика плюс куча служебных данных. Ещё чуть чуть и 10 гигов будет пустая база весить

(47) Разрядность только для сервера покупается. Для платформы, тем более файловой можно использовать как 32 так и 64

Проверить регистры сведений ЗамерыВремени - их несколько.
И не стоит ли галка в Администрировании - оценка производительности.
При каких то обновлениях включается.
У одних клиентов там было на 10 гигов, когда сама база 17

(47) Размер базы в файловой условно по разному может быть большой или маленький.
Бывают случаи что объем 5-6 ГБ и уже ужасные тормоза. А бывает и что 15-20 ГБ и вроде все норм работает.
Все зависит от железа, от организации работы с базой, от некоторых алгоритмом самой базы.

Как обычно улучшают?

1. Стараются железо улучшать.
2. надо ухаживать за базой. Следить за мусором в базе ЖР резать, Индексация пересчет итогов итп.
3. Вместо сети иногда веб помогает. Иногда РДП помогает.
4. В критичных случаях приходится резать (сворачивать) базу.

Но прежде надо всегда понять где у тебя горлышко. И потом действовать. Иначе любые старание дадут мелкий прирост
скорости например 2-3 % и все.

(51) плюс сильно зависит от наличия бух регистров. Т.е. для бухии уже на "маленькой" базе все плохо, а УТшка и с большими базами справляется неплохо

(52) + 1

(47) платформа не зависит от покупки 1с можно ставит ту что вам удобна
если  конечно у вас не сервер 1с

Да. В ИР отличная структура хранения БД. Бесплатна и всеядна (файловая, MSSQL, Postgre)
http://devtool1c.ucoz.ru/index/struktura_khranenija_bd/0-48

(52) Бухкомпонента всегда нормально работала, без тормозов особых. Тормозят не бухитоги, а неоптимальные алгоритмы в документаэю

(52) ут изначально тормозит на мелких базах - куча не нужных движений и функционала - самая паршивая конфа из семейства.

Что-то разные мнения на счет тормознутости типовых конф.
Так все-таки что более тормознутее УТ БП или ЗУП?

+(58) Или все таки под тормозами разное понимают. И поэтому такие диаметрально разные отценки?

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

УТ тормозная из-за перегруженного функционала. Например, мне нужны только штуки. Я не могу отключить просто так запросы по 3000 строк, связанные с упаковками. Хоть в настройках я и не включаю наборы, комплектацию и прочее, запросы-то ведь продолжают формироваться полноценные. Да, на мощных серверах она работает терпимо, но не во всех ларьках это надо.
БП и ЗУП работают вполне приемлемо.

Как мне кажется если не брать типовые еще со времен 1с77 самые шустрые регистры накопление (или как их называли оперативного учета)
Самая тормознутая была бух регистры. Потом регистры зарплаты.

Если реализовать простые конфы на этих регистрах простые учеты бух, торговля и зарплата самая шустрая окажется торговля потом бух потом зарплата.
Но типовые так реализованы что Ут громоздкая. И поэтому медленная а бух более проще реализван. А ЗУП зависит от объема обрабатываемых сотруников кажется.

(62) Семерочные регистры шустрые только в очень узком диапазоне применимости - в получении итогов на точку актуальности. А как только дело начинает касаться "временного расчета", всё становится намного медленнее и печальнее. В восьмерке регистры накопления намного лучше реализованы.

(10) 10 Гб, вы что до сих пор в нулевых? Это такой малый размер ИБ, что даже смешно. Сейчас даже флешку с таким размером не найти.
ДО 100 ГБ я бы вообще не парился.

(64) Все же ведь относительно.
1. база файловая
2. Сервер так себе сервер.
3. Юзеров 2-3
5. БАза за 5-6 лет.

10 ГБ вполне себе приличная база в таких условиях.

А вот у меня база:
1. Весит 900 ГБ
2. Пользаков 250-350
3. Скульная
4. Куда доработок и куча интеграций
Вот для него уже другие услвия. И это база тоже большая.

Короче файловая база в разных условиях по разному оценивается.

(64) запарился, сразу как первая таблица бы уперлась в максимальный размер
https://its.1c.ru/db/metod8dev/content/5710/hdoc

(26) +1. ИР наше всё.

(29) (0)
И все таки самое вероятное - загружен классификатор адресов по всей России.

Чтобы формы быстро открывались,нужно как у Microsoft, сначала открыть и отрисовать форму,а потом наполнить ее данными.
Если же в форме несколько вкладок,то неактивные заполнять при переключении на них.
Это даже несложно сделать.
Плюс повыкидывать все большие списки и грузить изначально элементы только на один экран.