sql 2008, win 2008, база УПП 1.3, simple mode ~ 300 документов в день.
Буквально позавчера делал шринк.
Смотрю в менеджере:
сейчас размер 18793,06 МБ, доступное место 430,60 МБ
До этого доступного места было больше 20 гигов.

В другой организации те же параметры, только УТ 10.3 и ~ 800 документов в день. Шринк вроде ни разу не делал или было это очень давно. Сейчас там: размер 7720,69 МБ, доступное место 13,89 МБ.

От чего такая разница доступного места?
PS и может кто-нибудь напомнить, почему нежелательно делать шринк в simple mode

вот неожиданно от тебя такую тему увидеть
замер таблиц в базе что показывает?

размер файлов не зависит от занимаемого места, все дело в настройках базы

итоги по регистрам заказов сильно пухнут, если регистр не закрывается

(0) Непонятно размер чего? Лога или данных? Доступно места в файле лога, файле данных, на диске? опухает что лог или данные?

(1) в УПП основная часть приходится на:
НДС по партиям запасов
Затраты на выпуск продукции (БУ, НУ)
Партии товаров на складах (БУ, НУ)
Версии объектов
в УТ:
Заказы покупателей
НДС расчеты с покупателями
НДС по партиям запасов

(2) в каких именно настройках?

(3) в УТ заказы используются на много больше и естественно их там гораздо больше незакрытых

(4) simle mode - лог не ведется

+(5) ну и разумеется в УПП самый "толстый" РБ

(4) "опухает" сам файл с базой, причем в той части, который в менеджере указывается как "доступное место" - вот и хотелось узнать, что именно там хранится?

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

(10) В скуле есть отчет Использование дисковой памяти верхними таблицами (правой кнопкой на базе, отчеты, стандартные) Что он показывает?

В современных версиях скуля есть отчёт по наиболее крупным таблицам.
Построй его и сравни с ПолучитьСтруктуруХраненияДанных. Увидишь

(11) и там и там рост не ограничен

(8) Это не означает что его не существует :)
Что такое "доступное место", можно перевести?

(0) Я бы не сказал что шринк делать не желательно. Его нет смысла делать, если нет удаления объектов.
Может у тебя в базе какие-то документы или элементы справочника сначала создаются, а потом удаляются? В таком случае база увеличивается но не уменьшается.

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

EXEC sp_spaceused @updateusage = N'TRUE'
go

select o.id,OBJECT_NAME(o.id),i1.dpages as dpages, i1.rowcnt as rows,
cast((ISNULL(SUM(i1.reserved), 0) + ISNULL(SUM(i2.reserved), 0)) * 8./1024 as decimal (18,2)) as reserv_mb,
cast((ISNULL(SUM(i1.dpages), 0) + ISNULL(SUM(i2.used), 0)) * 8./1024 as decimal (18,2)) as data_mb,
cast(((ISNULL(SUM(i1.used), 0) + ISNULL(SUM(i2.used), 0)) - (ISNULL(SUM(i1.dpages), 0) + ISNULL(SUM(i2.used), 0))) * 8./1024 as decimal (18,2)) as index_size,
cast(((ISNULL(SUM(i1.reserved), 0) + ISNULL(SUM(i2.reserved), 0))
- (ISNULL(SUM(i1.used), 0) + ISNULL(SUM(i2.used), 0))) * 8./1024 as decimal (18,2)) as unused_mb,
data =(convert(char (8),getdate(),112))
FROM sysobjects o
LEFT OUTER JOIN sysindexes i1 ON i1.id = o.id AND i1.indid < 2
LEFT OUTER JOIN sysindexes i2 ON i2.id = o.id AND i2.indid = 255
WHERE OBJECTPROPERTY(o.id, N'IsUserTable') = 1
OR (OBJECTPROPERTY(o.id, N'IsView') = 1 AND OBJECTPROPERTY(o.id, N'IsIndexed') = 1)
GROUP BY o.id, i1.dpages,i1.rowcnt
order by data_mb desc

+17 соответственно с получитьструктурухранениябд() или как ее там зовут

(13) тебя уже амнистировали ?

(15) открываем свойства базы и там такая строка

Та на нимфостарте полно поделок-базопузомеров.

Мот картинки активно пихают ?
Или проводят доки 01.01.1001 годом ? Или до нашей эры, или в космосе ?...
Тогда таблички итогов того - подрастут мальца :)

а какой % установлен на увеличения?  а то может подходит к концу место. а там стоит 100% увеличить файл.

(19) А как ты думаешь? ))
(21) Нафига всякие поделки, если всё делается штатно?

(12) тоже самое, что я писал в (5)
или что именно нужно назвать?

(23) данные строк 1М
лог 10%

(21) нафига?
просто хочу понять, почему файл "обрастает" поверх основного размера базы?

(27) см (23)
все что угодно может быть

(26) а дата файл. он же % для каждого устанавливается

(28) ну вот может и придем к истине :)

(25) Там ответ на твой вопрос? Какая таблица и почему пухнет в базе.

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

(29) ээ... не совсем понял

(32) А что опухает то, данные или пустое место в файле данных? Если данные, то открываем базу и смотрим что набили пользователи. Если пустое место, то смотрим в какой таблице много пустого места. Далее анализируем почему возникает такая большая дефрагментация данных или индексов и т.д. и т.п.

(16) да не...
вроде ничего такого нет

(34) тогда придется ждать до следующего "опухания"..

(36) Ну ясен пень что надо анализировать по факту, ну или можешь позавать гадалку на кофейной гуще.

(34) + 100 какой-то мега отчет вполне мог на какое-то время раздуть нехило темп табличку какую и несколько раз

(8) В простой модели лог ведётся и даже можно делать разностные копии, только записи в нем становяться не уникальными не при бэкопировании логфайла как в полной моделил, а при бэкапировании данных или разностной копии. Или при достижении 70% занятости.

"уникальные" -> "актуальные"