Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...

Serg
Дата: 02.02.2001 18:44:29
There is DB, size of .DAt file ~6Gb, but used just ~3.5Gb. I started "dbcc shrinkdatabase" but size keep the same . Do you have any ideas? Thanks...
Александр Гладченко
Дата: 02.02.2001 19:21:31
Насколько я понимаю, это штатная ситуация для сервера. Сжатие базы происходит до первого заполненного экстента. Если у Вас удаление записей из таблиц - не редкая операция, то вероятность того, что страницы сильно фрагментированы повышается. Выход достаточно простой, перестройте кластерные (а впрочем и другие) индексы.
Serg
Дата: 02.02.2001 19:35:37
I've made "dbcc dbreindex" for all tables in DB and made "dbcc shrinkdatabase" after it - nothing happend! More ideas PLZ !!!
Garya
Дата: 02.02.2001 21:45:51
Выдержка из рассылки MS SQL Server - дело тонкое, возможно, имеет к этому отношение:
...
Существенное значение имеет только полная длина строки:

create table t1 (v char(4000))
create table t2 (v char(4040))

Таблица t1, после загрузки 10,000 строк, заняла 5000. Длина строки для таблицы t2 - только на один процент больше, чем длина t1, так что Вы могли бы ожидать что таблица t2 будет занимать на один процент большее страниц, но в действительности оказывается, что она занимает в двое больше, чем t1. Причина этого в том, что SQL сервер 7 может хранить по 8060 байт данных на одной странице, так что на каждой странице таблицы t1 хватает места для размещения двух строк. Однако, когда мы расширяем длину строки до 4040, тогда только одна строка будет помещаться на странице. Следовательно, для размещения того же количества строк потребуется в два раза больше страниц. Это происходит потому, что SQL сервер не умеет разбивать строку на две страницы.
Serg
Дата: 02.02.2001 22:27:03
But in this case Enterprise Manager will show this pages as used, but in my case I have 50% unused pages in DB. Or am I wrong?
SergSuper
Дата: 05.02.2001 10:26:34
Что-то у меня эта рассылка вызывает всё меньше доверия. Это ж надо такое написать...

Неужели кто-то делает таблицы с полем char(4000)? Ну я еще понимаю char(10), но зачем 4000? Для такой длинной строки обычно используется поле varchar, а оно занимает места столько, сколько символов в записываемой строке. Далее делаются совершенно странные выводы: "Следовательно, для размещения того же количества строк потребуется в два раза больше страниц. Это происходит потому, что SQL сервер не умеет разбивать строку на две страницы."
Интересно, автор представляет чтобы было, если б "умел"? Наверное тогда смысла в страничной организации не было бы.
А смысл страничной организации в том, чтобы упростить доступ к данным и за это приходиться платить некоторой потерей эффективности хранения. И это проблемма не только MS SQL. Можно было взять например систему FAT и написать:
"создадим файл F1 размером 32768 ,байт и файл F2 размером 32769. Файл F2 всего на 0.003% больше чем F1, однако он занимает в 2 раза больше места!"

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

Извиняюся за резкость, но это же не просто чьё-то мнение, а статья, претендующая на авторитетность, на которую вот даже ссылаются.

К сожалению Serg-у я помочь ничем не могу. Может он ошибается насчет того, как база используется? Откуда цифра 3.5Г? Может она неправильно считается? Если уж ничего не поможет, можно сделать Data Transformation, но это если уж совсем...
Александр Гладченко
Дата: 05.02.2001 10:29:39
Уважаемый Serg, More informations PLZ !!! Нужно же нам хоть за что - либо зацепиться... Обычно, dbcc shrinkdatabase работает прекрасно, особенно, если запускать её с правами владельца базы. Может, хоть сообщения об ошибках какие - нибудь есть?
Serg
Дата: 05.02.2001 16:56:28
Hi, guys! There weren't any error messages , I used SA account. The digit 3.5 Gb was taken from Enterprise Manager (also I have practicaly the same DB in production ~3.5 Gb).

I've solved it by creating full backup, recreating DB and restore it from backup. It's not "IZYASHNOE" solution, but it has worked .

Thanks a lot for your help!!!
Александр Гладченко
Дата: 05.02.2001 19:36:03
Уважаемый SergSuper!
Спасибо Вам огромное, Вы первый, кто решился критически отозваться о рассылке, автором которой я являюсь. Действительно, я с Вами абсольюно согласен, если автор не будет иметь обратной связи с подписчиками, рассылка будет нравится всё меньше и меньше. Очень Вас прошу, как и всех других подписчиков, не стесняйтесь, критикуйте. Я ведь тоже хочу приблизится к истине и надеюсь, что она где то рядом...
По поводу приведённой Garya выдержки, также согласен, что
create table t1 (v char(4000)) - сплошная дикость!!! Особенно, если рассматривать это не в контексте статьи. Настоящим автором переведённой в рассылке статьи (откуда и был взят кусок текста) - является очень уважаемый мной Neil Boyle. Убедительно рекомендую Вам прочитать его статьи на сайте WWW.SWYNK.COM
А мой (может быть, кстати, и неудачный) перевод одной из его статей, явившейся причиной Вашей справедливой критики, можно найти тут:
http://mssqlhelp.com.ru/031.shtml#1
Garya
Дата: 05.02.2001 21:40:55
Ребята, давайте не будем тренироваться в том, кто в кого тяжелее кирпич кинет. Как я понимаю, смысл данной конференции - помогать друг другу. По поводу же рассылки, о которой сказано выше, позвольте с вами, Serg, не согласиться. Рассылка очень даже приличная. Лично я из нее (не из приведенного отрывка, а вообще...) очень много почерпнул полезного, что реально применяю на практике. Никакая вообще в мире рассылка не может претендовать на абслоютную всеохваченность и всепонимаемость, как и печатная продукция. Вполне вероятно, что приведенная в отрывке информация лично вам была не принесла ничего нового, зато она принесла новое кому-то из новичков - ибо на них она тоже расчитана. И для профи в рассылке тоже есть чего почерпнуть. - к примеру, недокументированные возможности SQL-сервера.
По поводу того, что никто никогда не будет использовать char(4040) - ё-моё, это же чисто умозрительный пример для наиболее яркой демонстрации особенностей страничной организации. Попробуйте придумать другой, если вы, Serg, такой крутой. И как в этом примере объясняется, ПОЧЕМУ нельзя использовать char(4040) (точнее, одна из причин - главная, естественно, существенная экономия памяти при переменной длине реальных данных с соответствующим ускорением их выборки). Кстати, при использовании VARCHAR, которые могут иметь большую длину, тоже можно получить потери пространства из-за страничной организации.