Полезен ли шринк или нет? Есть ли выигрыш от него в производительности?
А если бы еще ссылочку на описание пользы от него было бы просто великолпено.
ЗЫ: it is possible in English
ЗЫЫ: что такое шринк и с чем его едят рассказывать не нужно ...

единственное что могу точно скзать, что вреда от него никогда не было...

(0) нет уж... ты расскажи...

Выигрыш будет, если после шринка база целиком влезет в память...
Иначе при первом же добавлении ей всё равно придётся расширяться.
Существенно полезней будет полная перестройка индексов...

Да зашел спор с админом. Мое мнение скорость записи должна значительно возрасти, на данные момент его база mdf - 2g, ldf - 11g.

(3) Она и так влезет если размер данных позволяет.
А про индексы ... Я бы добавил обновление статистики...

лучше дефрагментацию ФС да и данных внутри файла данных

(4) Ой какие Вы умные, а?
А скажите, разлюбезнейший  Fynjy, зачем Вам recovery model - full?
Вы и вправду умеете их готовить?

А-а-а-атставить оскорбления!

а зачем вам лдф такой?...

>Мое мнение скорость записи должна значительно возрасти, на данные момент его база mdf - 2g, ldf - 11g.

с чего бы вдруг? Писаться то все равно будет в ldf

(12) к (4)...

другой вопрос если приращение стоит в %, каждый раз будет все больше и больше отъедаться одномоментно

кто мешает настроить job на базе и забыть вообще...

(16) вот так мы и сделали

(7) мну умеет их готовить ... Тем более у человека полный бекап делается каждую ночь ...
(14) это не моя база ...
(13) скорость работы с большим файлом ниже скорости работы с маленьким ...

Так давайте отставим:
"а зачем"
"ламер"
"а вот у нас"
, а ответим аргументированно быстрее или нет ...

>>скорость работы с большим файлом ниже скорости работы с маленьким ...

ты под скоростью работы что понимаешь? Пишет он в конец себе и пишет...

(5) Статистики по индексам после перестройки сами обновятся. А вот если есть отдельные, то да, нужно бы и обновлять. Да почаще

(21) а автообновление статистики тоже можно настроить

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

шринк даст тебе уверенность что у тебя все не посыпется когда место кончится... или если база упадет в суспект то большая часть данных может быть останется в живых в mdf

(21) По индексам, да, обновятся, кстати всё давно описано.
Касательно 1С в "талмуде" ПрофРазработка на последних страницах где-то.

(23) Shrink влияет косвенно, т.е. влияет на очередь обращения к диску.
Да и при таком объеме в чем проблема протестировать. Объем-то слишком маленький.

(24) Там скорее будет переполнение лога транзакций :)))
Кстати, коллеги, вот ведь забавно, как кто чистит лог транзакций в SQL 2k8? :)

у меня каждый час лог шринкуется

(0) От размера таблиц БД скорость работы практически не изменяется

(28) Это Вы погорячились :)))
Влияет и еще как :))

(6) +1
(7) +1

(0) Рестарт сиквела чистит темпы, бекап делает шринк. У нас 250 гигов часа полтора бэкапятся. Зачем фулл рековери? Каждые полчаса бэкапитесь?
Реальный выигрыш производительности - хранилище и по -мелочи: темпы, лог на разные физически диски + дефрагментация и под базой диска и базы с индексами с обновлением статистики по-таблично (хотя бы раз в неделю)

Для не умеющих читать пишу большими буквами:
"А ЗАЧЕМ"
"ЛАМЕР"
"А У НАС"
"А МЫ"
- не в этой ветке.
Четкий вопрос - принесет ли выигрыш шринк или нет.

Пока в тему 2 ответа:
(24) и (25)

(29) Кинь инфу или приведи примеры какие-нибудь

(33) Хочешь сказать, что даже

SELECT * FROM my_table

будет по скорости исполнения не зависеть от размера my_table?

(34) А что за функционал такой может использоваться, которому понадобиться выбрать например 50 млн. записей, ума не приложу? Через Ж да, будет медленней

(33) Что Вы подразумеваете под скоростью работы в таком случае?

(35) + а при грамотной архитектуре разница 0

(36) Это уже другой вопрос, видимо тоже самое что и автор, если такой вопрос ставит

(34) убирается неиспользуемое зарезервированное пространство. Там нет данных.

(35) Например, скармливание исторических данных о продажа нейросети в целях прогнозирования.

(39) Совсем непонятно, что под размером таблицы имеется ввиду?
Размер страницы памяти, общее количество строк используемых/нет ?

(40) Объем / Период = тоже самое выражение при более маленьких таблицах

Еще одна ветка v8: Размер базы SQL

(42) Ты имеешь ввиду количество транзакций?

строк/день?

(41)  РазмерЗарезвировано    РазмерДанные    РазмерИндексированный РазмерНеиспользованный
3 337 872    1 262 192    2 075 016    664

(46) + могу обработку выложить по определению размера таблиц базы 1С на основе sp_spaceused, но там есть пара некрасивых моментов - создание/удаление пользователя 1С например

(47) А зачем обработка? Если можно хранимку написать...

Таки знакомый сделал шринк - Общий размер 1 гиг (900 и 100). Скорость возросла визуально. Сделали замер на перепроведении документа начисление ЗП (1000 человек). Но у человека все равно осталось мнение, что шринк не дает прироста производительности ...

(49) База 77/8?

8

(51) Особого прироста не заметишь. Надо было замер производительности делать.

(52) так и было сделано

И? Ждем-с?

(48) Меня тут спрашщивали зачем тебе плейер в 1С, если winamp есть )

вот мне шринк сегодня пригодился. Жду новый сервер, а на нынешнем сегодня утром осталось свободно 120мб. Шринк - и 4.5гб свободно. Как нибудь дотяну

(0) Лучше всего postgesql

(57) DB2 еще лучше.

(57)(58) Для пивных ларьков сойдет :)))

(59) Ты это IBM расскажи :))

(60) Не, это к 1С.. как онИ это реализовали....

(58) Они специально под 1С подкручивали - причем неудачно )

(62) впрочем как обычно

Постгрес ни на какой мсскуэль никогда не променяю, если руки из того места растут то 1с на постгресине рвёт всех.

(64) ты сначала там построчную блокировку в 1с сделай :-)

(0)
Да.
Не всегда
Гилёв.ру

Я правильно ответил? В соответствии с сабжем?

(64) Как бодались с отображением форм в ВЁБ клиенте на платформе 8.2.8.256?

Что-то я не понял, если "...ЗЫЫ: что такое шринк и с чем его едят рассказывать не нужно ...", тогда зачем ветка то? Автор и так знает.
Ааааа, это наверное других проверить :)

(66) Нет конечно ... Обоснования нет ... На Гилев ру просто говорится о том, что рекомендуется делать шринк, а что он даст или не даст для той же производительности вопрос ... Тот же MSDN ответа на вопрос не дает ...
http://msdn.microsoft.com/ru-ru/library/ms189080(SQL.90).aspx
Причем если зарыться в MSDN можно найти инфу о том, что шринк даже замедляет работу бд ввиду того, что происходит дефрагментация файла ...

(69) эээээ... где в сабже про обоснование???? между строк не вижу. Особенно после (19)
Дальше-больше:
Если утверждение "что такое шринк и с чем его едят рассказывать не нужно" верно, тогда Вам должно быть и так всё ясно. Судя по вопросам Вы даже примерно не представляете с чем его едят, как оно себя ведёт и как использовать свои мегазнания в спорах. Поэтому, прислушайтесь к фразам типа "а зачем", "а у нас" или "а мы" и у Вас всё получится

(70) Если это обоснованные фразы, то прислушиваться к ним имеет смысл, но если это пустозвон наподобие "Вы даже примерно не представляете с чем его едят" и "свои мегазнания в спорах" то просто хочется послать на ... К тому же в 69 просто пример того, что написано в MSDN ... Там написано, как и что произойдет, но не написано будет ли выигрыш ...

(71) Зачем горячиться? Миста не для этого.
Вообще про выигрыш написано, что ни чего не будет, если только шринкать. При чем увеличенная дефрагментация почти не проявляется (проверьте сами, если не верите) и связано с тем, что в нешринкнутом файле тоже все фрагментировано до невозможного.
Реальный прирост наблюдается, когда файл вырос до размеров ХДД и СКЛ пытается вымутить свободное пространство, а тут ты РАЗ! и дал ему 5% от диска :)))
А еще это шриньканье + все рег.процедуры очень сильно увеличивают скорость (визуальное восприятие), по сравнению с месячным зсиранием базы. По отдельности все рег.процедуры ни о чём.
Это личный опыт + Шилёв + маны по СКЛ

P.S. "посылая кого-то помни, что в ответ могут вдвойне послать!"

"Шилёв" --> "Гилёв"

(72) Вот такого ответа я и жду из 72 это 3 аргументированный ответ.

(74) не поверите, я один из самых малознающих. Те кто реально много про это знают, скорее всего, просто мимо прошли.

(74) Да, я крут :-)

...над тем какую вы пользу приносите на пару с одмином надо подумать :)

(65) > ты сначала там построчную блокировку в 1с сделай :-)

Неумеешь работать с управляемыми блокировками? Сочувствую. :0)

(67) У меня 8.1.

(0) Кто-то ваш вопрос Полу Рэндалу, похоже задал (:.
http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(930)-data-file-shrink-does-not-affect-performance.aspx

Процедура служит только для экономии места на винте.

(81) Экономия, только в случае большого объёма удалённой информации.
Кластерный индекс быстрее перестраивается в нешринкнутой базе (это СКЛьщик тут высказался).
Вообще, для многих операций, СКЛ выделяет резервное место, соответственно шринкнув такое место, можно немного тормознуть систему, для того, что бы она опять перевыделела то, что забрали