Была база данных в sql и она росла и пухла... до 40 гб...
Исправили партионный учет, вынесли логи из регистров сведений в mysql
и база стала 19гб и 18гб свободного места....
Настройки автоматически расти на 10%


Я методами SQL server enterprise manager делаю shrink базы данных с остатком свободного места 10% и переносом строк вверх....
Итог:
База данных в закладке
general   = 16 696 mb свободного места 0%
datafiles = 16 694 mb
==================================================================
Работали 2 дня нечего не изменилось...
в день около 5000 доков  строк в них мало от 1 - 20.
Тестирование логической  и ссылочной целостности говорит что всё нормально!
==================================================================
Вопрос это нормально?

(забыл указать)
Была база данных в sql и она росла и пухла... до 40 гб...
Исправили партионный учет, вынесли логи из регистров сведений в mysql
и база стала 19гб и 18гб свободного места.... 48%

Поставить симпле мод епробовали?

надо то чего? Журнал транзакций усекай

(2) Стоит симпле..
(3)Нало понять почему не меняется ?
general   = 16 696 mb свободного места 0%
datafiles = 16 694 mb

Это в базе есть ещё место которое я не вижу которое заполняется ?
Или скоро придет пи....

у тебя верхний предел для базы не задан случайно? Или автоприрост не включен

До 40 Гб - пухлая?
"Ваша Галя балована", однако

(6) Дело не в 40 гб ... а в том что из них реально использовалось 52% ...

(7) В Квери шринк сделай. Тока про копию не забудь.
==
Выбираешь базу и:
backup log ctf_test with truncate_only
DBCC SHRINKFILE(ctf_log,0)

(0) Megas, какая версия SQL Server'а у вас установлена?

А вообще - если не боитесь фрагментации - выполните:

use [YOUR_DATABASE]
DBCC SHRINKFILE (file_name, 0, NOTRUNCATE)
DBCC SHTINKFILE (file_name, 0, TRUNCATEONLY)

Первая инструкция сожмет вашу БД, а вторая - отдаст ОС освободившееся в файле место (просто так SQL Server этого не делает). Если размер не изменится - увличивайте размер файла в ручную, или ставьте автоприращение.

file_name - не обязательно реальное имя файла, для того чтобы его получить - посмотрите в sys.database_files (для SQL Server 2005, не уверен, что в 2000 это есть):

use [YOUR_DATABASE]
select name, physical_name from sys.database_files

(9)
(10)
Ещё раз =)
sql server 2000
Я сделал Shrink с дефрагментацией.. методами sql manager!

Ещё раз повторю я это сделал!!! средствами СКЛ манагер
это тоже что и средствами T-sql...

Поставил 10% в базе оставить свободного места... при этом есть автогров = 10%

Теперь:

Раньше в sql манагере писалось 40 гб 56 % свободно теперь пишут 16 гб 0% свободно но прироста не происходит... На самом деле скорее всего есть 10% свободности корые не видны.

Вы уверены, что это тоже самое? Просто у 2005-го скуля, например, в job'ах есть пакет shrink, который делает shrinkfile, но с параметром truncateonly.
А вообще, если есть сомнения - попробуйте найти десять-пятнадцать самых больших таблиц и посмотреть их размеры с помощью sp_spaceused (+параметр updateusage=true). А можно и для всех таблиц посмотреть.. Потом сравните сколько реально занимают записи в таблицах с размером файла.

Всё нашёл где смотреть .... Размер файла 16.6 гб из них 15гб занято 1.6 гб свободно (чуть больше 10%) так что всё ок =)