|
Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...
|
|||
---|---|---|---|
#18+
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, 18:44 |
|
Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...
|
|||
---|---|---|---|
#18+
Насколько я понимаю, это штатная ситуация для сервера. Сжатие базы происходит до первого заполненного экстента. Если у Вас удаление записей из таблиц - не редкая операция, то вероятность того, что страницы сильно фрагментированы повышается. Выход достаточно простой, перестройте кластерные (а впрочем и другие) индексы. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2001, 19:21 |
|
Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...
|
|||
---|---|---|---|
#18+
I've made "dbcc dbreindex" for all tables in DB and made "dbcc shrinkdatabase" after it - nothing happend! More ideas PLZ !!! ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2001, 19:35 |
|
Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...
|
|||
---|---|---|---|
#18+
Выдержка из рассылки 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 сервер не умеет разбивать строку на две страницы. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2001, 21:45 |
|
Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...
|
|||
---|---|---|---|
#18+
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? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2001, 22:27 |
|
Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...
|
|||
---|---|---|---|
#18+
Что-то у меня эта рассылка вызывает всё меньше доверия. Это ж надо такое написать... Неужели кто-то делает таблицы с полем char(4000)? Ну я еще понимаю char(10), но зачем 4000? Для такой длинной строки обычно используется поле var char, а оно занимает места столько, сколько символов в записываемой строке. Далее делаются совершенно странные выводы: "Следовательно, для размещения того же количества строк потребуется в два раза больше страниц. Это происходит потому, что SQL сервер не умеет разбивать строку на две страницы." Интересно, автор представляет чтобы было, если б "умел"? Наверное тогда смысла в страничной организации не было бы. А смысл страничной организации в том, чтобы упростить доступ к данным и за это приходиться платить некоторой потерей эффективности хранения. И это проблемма не только MS SQL. Можно было взять например систему FAT и написать: "создадим файл F1 размером 32768 ,байт и файл F2 размером 32769. Файл F2 всего на 0.003% больше чем F1, однако он занимает в 2 раза больше места!" Вообщем, пример совершенно надуманный и небольшая вероятность что такое(небольшое увеличение данный и резкое увеличение занимаемого места) встретиться в жизни, а с тем, что некоторое место в базе будет пропадать - приходиться смириться. Извиняюся за резкость, но это же не просто чьё-то мнение, а статья, претендующая на авторитетность, на которую вот даже ссылаются. К сожалению Serg-у я помочь ничем не могу. Может он ошибается насчет того, как база используется? Откуда цифра 3.5Г? Может она неправильно считается? Если уж ничего не поможет, можно сделать Data Transformation, но это если уж совсем... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2001, 10:26 |
|
Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...
|
|||
---|---|---|---|
#18+
Уважаемый Serg, More informations PLZ !!! Нужно же нам хоть за что - либо зацепиться... Обычно, dbcc shrinkdatabase работает прекрасно, особенно, если запускать её с правами владельца базы. Может, хоть сообщения об ошибках какие - нибудь есть? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2001, 10:29 |
|
Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...
|
|||
---|---|---|---|
#18+
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, 16:56 |
|
Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...
|
|||
---|---|---|---|
#18+
Уважаемый SergSuper! Спасибо Вам огромное, Вы первый, кто решился критически отозваться о рассылке, автором которой я являюсь. Действительно, я с Вами абсольюно согласен, если автор не будет иметь обратной связи с подписчиками, рассылка будет нравится всё меньше и меньше. Очень Вас прошу, как и всех других подписчиков, не стесняйтесь, критикуйте. Я ведь тоже хочу приблизится к истине и надеюсь, что она где то рядом... По поводу приведённой Garya выдержки, также согласен, что create table t1 (v char(4000)) - сплошная дикость!!! Особенно, если рассматривать это не в контексте статьи. Настоящим автором переведённой в рассылке статьи (откуда и был взят кусок текста) - является очень уважаемый мной Neil Boyle. Убедительно рекомендую Вам прочитать его статьи на сайте WWW.SWYNK.COM А мой (может быть, кстати, и неудачный) перевод одной из его статей, явившейся причиной Вашей справедливой критики, можно найти тут: http://mssqlhelp.com.ru/031.shtml#1 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2001, 19:36 |
|
Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...
|
|||
---|---|---|---|
#18+
Ребята, давайте не будем тренироваться в том, кто в кого тяжелее кирпич кинет. Как я понимаю, смысл данной конференции - помогать друг другу. По поводу же рассылки, о которой сказано выше, позвольте с вами, Serg, не согласиться. Рассылка очень даже приличная. Лично я из нее (не из приведенного отрывка, а вообще...) очень много почерпнул полезного, что реально применяю на практике. Никакая вообще в мире рассылка не может претендовать на абслоютную всеохваченность и всепонимаемость, как и печатная продукция. Вполне вероятно, что приведенная в отрывке информация лично вам была не принесла ничего нового, зато она принесла новое кому-то из новичков - ибо на них она тоже расчитана. И для профи в рассылке тоже есть чего почерпнуть. - к примеру, недокументированные возможности SQL-сервера. По поводу того, что никто никогда не будет использовать char(4040) - ё-моё, это же чисто умозрительный пример для наиболее яркой демонстрации особенностей страничной организации. Попробуйте придумать другой, если вы, Serg, такой крутой. И как в этом примере объясняется, ПОЧЕМУ нельзя использовать char(4040) (точнее, одна из причин - главная, естественно, существенная экономия памяти при переменной длине реальных данных с соответствующим ускорением их выборки). Кстати, при использовании VARCHAR, которые могут иметь большую длину, тоже можно получить потери пространства из-за страничной организации. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2001, 21:40 |
|
Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...
|
|||
---|---|---|---|
#18+
2 Garya Я не собираюсь ни в кого кидать кирпичи. Но повторюсь - к рассылке должны предъявляться более строгие требования чем к простому высказыванию в конференции. Может не стоило предъявлять претензии публично, но может давайте будем реалистичней относиться ко всему написанному в рассылке и не принимать это за догму. Чем мне не понравился приведенный пример, так это: 1. весьма маловероятные условия для его осуществления в жизни. Я привел пример (я ж крутой ) с FAT-ом - считаю что это не менее яркий пример "демонстрация особенностей страничной организации" в ДОСе . Оба примера одинаково маловероятны. 2. фраза "SQL сервер не умеет разбивать строку на две страницы" Т.е. это получается не "демонстрация особенностей страничной организации", как Вы пишите, а демонстрация какого-то недостатка, с чем я и не был согласен. 2 Александр Гладченко create table t1 (v char(4000)) - вовсе не дикость, для демонстрации чего-либо это может быть оправдано. Я с выводами не согласен. С приветом Сергей PS. Я надеюсь, мы пришли к конценсусу ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2001, 10:52 |
|
Can't shrink .DAT file (dbcc shrinkdatabase doesn't work)...
|
|||
---|---|---|---|
#18+
Со всеми вами согласен... НО! Рассылку всётаки критикуйте, особенно в том, что относится не столько к вопросам DBA, сколько к программированию БД. Мало того, поскольку львиную долю в ней занимают переводы наших англоязычных "братьев", здоровая полемика даже (мне так кажется) к месту. Давайте я, для пробы, буду размещать советы из рассылки отдельными темами в конференции, и мы вместе будем их обсуждать. Возможно, кроме ляпов авторов и переводчика, у вас возникнут свои интересные идеи и предложения. Что же касается публикаций на тему программирования, я тут из кожи вон лезу, но, пардон, я не программист. Иначе я бы подобрал вам для перевода намного больше и интересней. Почему я взялся за то, чем владею не достаточно хорошо? Увы, мои призывы к "крутым" программерам об участии в рассылке пока остались без ответа... А на счёт рассылок из проекта городского кота (subscribe.ru) прошу не обольщаться, подовляющее их большинство "варят" не профессионалы. Сделать рассылку действительно полезной, востребованной, точной и интересной без вашей критики просто не возможно. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2001, 20:45 |
|
|
start [/forum/topic.php?fid=46&msg=32001943&tid=1827391]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 146ms |
0 / 0 |