Размер файловой базы 6,7 ГБт
Я озаботился этим и нашел какую-то из версий tool_1cd.exe которая выдала такую картинку

Вопрос в том, что там максимальный процент якобы 1,7 (% ???)
И типо мне можно спать спокойно?
---
до 8.3.8 размер таблицы ограничен был 4 ГБ.
Если базу создавать на свежей платформе, то там размер таблицы уже больше.
Читайте про изменения.

А судя по скрину у вас ограничение в 32 ГБ стоит.
---
до 8.3.8 размер таблицы ограничен был 4 ГБ.
Если базу создавать на свежей платформе, то там размер таблицы уже больше.
Читайте про изменения.

А судя по скрину у вас ограничение в 32 ГБ стоит.
---
т.е. мне можно не беспокоиться за 4ГБт ???
---
можно не беспокоиться. Но если не будет грамотного админа с бекапами, то без скуля не обойтись. Поставьте постгри. бесплатная. Ну да минисервер 1С еще.
Если нужна тема со скидкой на работы пишите.
---
Вы находите мнение программы "tool_1cd" авторитетным?
6,7 ГБ для файловой базы - очень много. Даже если Вас устраивает быстродействие и параллельность работы пользователей, то должно озаботиться вопросом сохранности базы.
По личным многолетним наблюдениям за базами самых разных клиентов могу сказать: такого размера базы склонны самопроизвольно по непонятным причинам рассыпаться. Поначалу помогает "chdbfl.exe", входящая в дистрибутив платформы, но после какого-то раза - не помогает. Помогает уже только поиск и подъем крайнего бэк-апа :((
При таких размерах стоит задуматься об установке переводе базы в серверный режим, благо цена вопроса с "1С-сервер МИНИ" невелика.
---
попробую донести ваш совет до начальства нищебродской конторы
---
Просто надо взвесить: на одной чаше потеря базы, на другой 14,4 тыр. Что перевесит?
В современных условиях непонятно. И слово "нищебродская контора" какой-то новый смысл приобретает.
---
И слово "нищебродская контора" какой-то новый смысл приобретает.

Легко пояснить смысл: это когда конторе жалко 15 тыр на прибамбас для 1С но не жалко 2 млн для красивого забора вокруг конторы.
а 1Сник он на окладе - он починит. :)
---
жалко 15 тыр на прибамбас для 1С но не жалко 2 млн для красивого забора
Это прямо в точку :)
---
Все-таки ограничения накладываются на всю базу или на каждую таблицу?
---
не всё ли равно, если базы больше 3 гб уже опасно юзать в файловом режиме.
---
не всё ли равноДумаю не все.
---
на таблицу
---
И все-таки ограничения накладываются на всю базу или на каждую таблицу?
---
ограничения накладываются на всю базу или на каждую таблицу

Логически - все таки на размер таблицы.
---
"Приведенное описание соответствует платформе «1С:Предприятие» версии 8.3.4.

Устройство файла *.1CD
На самом нижнем уровне файл *.1CD или файл базы данных содержит внутри своего рода файловую систему, включающую в себя так называемые внутренние файлы. Файл *.1CD имеет страничную организацию, то есть состоит из страниц размером 4096 байт (4 К). Размер файла *.1CD всегда кратен 4 К.

Страницы адресуются их номерами. Номер страницы представлен 4-байтовым целым числом без знака. Следовательно, файл *.1CD может содержать не более чем 4 294 967 296 страниц.

Страница с номером 0 содержит служебные данные файла *.1CD, такие как версия формата файла базы данных, общее число страниц в файле и т. п.

Страница с номером 1 используется менеджером свободных страниц.

Каждая из остальных страниц может либо принадлежать какому-либо из внутренних файлов, либо находиться в списке свободных страниц.

Внутренние файлы
Страницы, относящиеся к внутреннему файлу, бывают трех видов:

*корневая страница,
*индексные страницы,
*страницы данных.

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

Корневая страница содержит служебную информацию внутреннего файла, такую как длина файла, номер версии данных файла и т. п. Кроме того, на корневой странице содержится до 1018 номеров индексных страниц.

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

Страница данных содержит только данные.

Из сказанного выше следует, что внутренний файл может включать не более чем 1 041 414 (1018 * 1023) страниц данных. Следовательно, максимальный размер внутреннего файла не может превышать 4 265 631 744 (1018 * 1023 * 4096) байта. Для адресации отдельных байтов внутреннего файла используются 4-байтовые целые числа без знака.

Для представления внутреннего файла нулевой длины достаточно одной только корневой страницы. Если размер внутреннего файла составляет от 1 до 4096, то он представляется тремя страницами: одной корневой, одной индексной и одной страницей данных. При дальнейшем росте размера файла добавляются новые страницы данных, и их номера помещаются в индексную страницу. Как только индексная страница перестает вмещать номера страниц данных, добавляется новая индексная страница и ее номер добавляется в корневую страницу. И так далее.

Внутренние файлы не имеют имен. Для идентификации внутренних файлов используются номера их корневых страниц.
"

Некоторые особенности устройства и работы файловой базы данных "1С:Предприятия 8"

+
"
8.2. Файловая база данных
● Файл базы данных (.1CD) внутри организован как множество так называемых внутренних файлов. Каждой из таблиц базы данных соответствует до четырех внутренних файлов:

● Файл описания таблицы – в нем находится описание таблицы.

● Файл записей данных – содержит данные всех записей таблицы, за исключением данных, содержащихся в полях неограниченной длины.

● Файл индексов – размещены все индексы, определенные для таблицы. Если не определено ни одного индекса, то этот файл отсутствует.

● Файл значений неограниченной длины – хранятся значения неограниченной длины, содержащиеся в полях таблицы.

● Размер каждого из вышеперечисленных внутренних файлов не может превышать:

● для формата версии 8.2.14 – 4 Гбайта.

● для формата версии 8.3.8 с размером страницы 4096 байт – 4 Гбайта.

● для формата версии 8.3.8 с размером страницы 8192, 16384, 32768 и 65536 байт – 6 Гбайт.

● Длина ключа в индексе не может превышать 1920 байт."

Приложение 8. Особенности работы с различными СУБД
---
Смотря что за конфигурация. УПП с самого начала создает 5.5 Гб.
У клиента после очередного обновления 1CD распух до 14 Гб. Так как работает в ней несколько человек, то единственное неудобство - это бэкапирование. Архив на флешку целиком не записывается из-за ограничения файловой системы.

Я считаю, что если нет проблем с быстродействием - то на SQL переходить вам не нужно.
---
У клиента после очередного обновления 1CD распух до 14 Гб.Может быть нужно было сжать таблицы базы (ТиИ)? УТ тоже после обновления почти в два раза распухает
---
да, на копии это уменьшило размер раза в 2. Но на размер бэкапа это не влияет - ведь ТИИ убирает пустые области. Бэкап (архив zip с быстрейшей скоростью сжатия) - около 5 Гб. Вот это единственное неудобство, поэтому буду обрезать базу.
---
если 1CD 7 гиг , то dt примерно 1,2 гига должен быть
---
Вот свежий пример с проблемой разрушения файловой базы
https://forum.infostart.ru/forum86/topic240457/
---
База может разрушиться из неисправной сетевой карты, из-за пропадания интернета, из-за сбоя(поломки) в компьютере.
У меня был случай: загружает юзер БД из DT-файла через малое время файл базы поврежден.....оказалось вирус буянил. А на компе стоял супер лицензионный каспер и сисадмин божился что это 1Ска глюкавая.
---
Да, да, совершенно верно, может быть масса причин. Чаще всего - аварийное пропадание питания.
---
База SQL тоже может разрушиться. Сколько раз бывало.
---
Это, конечно, тоже бывает, но куда реже.
За счет избыточности хранения - вероятность ниже.
При правильно настроенном плане обслуживания / резервного копирования такую вероятность можно приблизить к нулю.
А самое главное - чтобы забэкапить базу не надо никого выгонять.
---
некоторые поправки внесу:
1. Избыточность хранения - здесь не причём (практически). У SQL (любой) - другие принципы (гораздо более важные - по-большинству) работы.
2. План обслуживания - настроить можно везде.
Это факт (странно мне - если Вам, это неизвестно).
Другое дело - у SQL, инструменты настройки (большая часть, да) - уже идут, в комплекте. (ну - исключая всякие Express...).
У файловой же - приходится выкручиваться (и порою, да - далеко невсегда, получается догнать SQL)
3. "Для бекапа, выгонять". Ну - здесь Вы вообще - застряли в прошлом веке.
Реально.
И в 7-рке (и в 6-рке!) - без проблем (и без выгоняния пользователей), копировались, все файлы (без индексов). И - на скопированных - можно было работать.
В 8-рке - это уже 1с, сама однозначно обозначило - копируйте файл 1Cv8.1CD. Этого - достаточно.
(здесь только один момент отрицательный есть - нет одномоментного снимка базы. Но, я очень сильно подозреваю, что и в SQL - это, тоже не на 100% (хоть и декларируется так!)
---
Разрушиться может всё.
Абсолютно!
Это факт.
Другое дело - вероятность разрушения, у каждого решения - различна.
И отрицать это - просто глупо.
---
Я не большо спец в 1с Администрировании. Но насколько я знаю, если юзать файловую базу через веб-сервер Apache на пример, то вероятность повредить ее сильно снижается.
---
вопрос (в Вашем ответе) только (для начала) - что входит в Ваше "сильно".
---
отвечу так. Из практики своей, был клиент база 4-5Гб файловая. Часто база билась. Чинил при помощи "chdbfl.exe" .
Поставил ему Apache. С тех пор уже больше года жалоб нету. Таких примеров парочку. Поэтому я и сделал такой вывод, чисто эмпирически.
---
с Файловой базой (на 6,7 ГБ) - это конечно ужос.
(наверняка - повторюсь, с кем-то)

Её - же нельзя скопировать одномоментно.
(это - только один, из самых значительных минусов)
---
http://forum.infostart.ru/forum9/topic240442/message2437351/#message2437351
"Поставил ему Apache. С тех пор уже больше года жалоб нету. Таких примеров парочку. Поэтому я и сделал такой вывод, чисто эмпирически."

Полностью согласен, аналогично!