Настроил на SQL 2008 регламентные процедуры:
1. Проверка целостности 2.Перестроение индекса 3.Обновление статистики 4.Очистка процедурного кеша 5.Полное резервное копирование с сжатием файлов 6.очистка файлов бекап с определенной периодичностью 7.очистка истории sql по задачам.
Модел восстановления: simple
Вопрос: нужна ли процедура shrink или при простой модели восстановления бд в этом нет необходимости в 2008 sql? если нужен shrink то какой - базы данных или журнала транзакции и куда поставить по очереди эту процедуру?

есть знатоки по данной теме?

нет, не нужна.

(2)если однозначно, то спасибо

Я бы даже спросил, а нужны ли процедуры 1-7, кроме 5?

(4) gthdst 4 jlyjpyfxyj

(5) Однозначно нужны?

мозговой штурм

каким тогда образом выполняется shrink в той модели, которую я описал? в момент создания полное бекапа или ещё как-то?

(8)
ни каким.

(8) Зачем вообще тебе нужен shrink, для начала?

(10)На сколько я понимаю, чтобы освобождать свободное пространство.

5 должно быть 1, 4 только для чсв и тормозов, чтоб утром кофе выпить, 3 надо просто разрешить, 6 какой то бред, 7 рулит для отчетности

(11) "Освобождать свободное" - это 5. Пояснить можешь?

(13) Дефрагментация и упаковка вообще-то.

В таблицах баз данных бывает неиспользуемое свободное пространство-его то и освобождает shrink, поэтому интересуюсь в 2008 скуле его нужно подключать или нет.

(15) OK, идем дальше.
1) почему оно возникает
2) зачем его освобождать

(16) Никогда не пробовал делать по сети бекап ста-гиговых баз?
И сверять разницу в быстродействии работы упакованной базы и нет, при явной нехватке оперативки?

(17) Не ответы на мои вопросы, но...
Никогда не слышал про differential и compression?

Насчет разницы, не сверял, а ты? С чего бы ей быть?

Вообщем сделаю шринк раз в неделю и баста, так как убедился, что база от 200 гб сразу становится 70 гб.

(18) А я сверял. И разница есть.
Если у тебя дифференциальные бэкапы делаются раз в час, то раз в сутки хотя бы нужно делать полный. И копируется он по сети почти сутки.

Копрессию мне не попробовать - мой SQL не поддерживает. Но что-то я не уверен что с ней всё настолько радужно, тем более это новая возможность.

шринк скуль делает и все,архивация другая програмулина по часам,и заливает по сети в хранилище,все остальное раз в месяц,места дофига

(19) Ну через полгода все равно эти 200 забьют данными, и что?

Пойми, SQL Server резервирует место под будущие данные. И правильно делает. Если ты постоянно делаешь shrink, ему придется это делать в тот момент, когда пользователь ждет проведения документа. Зачем ему мешать?

Тебе места жалко(0)? купи винты! 8тр,б в рэйде и не парюсь)

(23) А при чем тут место? Например в моем случае проблема со временем копирование бекапа по сети.
(22) Можно поподробней про резервирование места?
Впервые слышу про ускорение от резервирования. Резервировать можно чтоб нехватки не случилось, но ускорение то откуда?

И впервые слышу о более медленной работы после дефрагментации.
Дефрагментация и упаковка как минимум не замедляют.

Баян )))
Shrink MS SQL. Быть или не быть.

(26) Там обсуждали шринк лога при модели full

(27) Там есть в 80 посте ответ на главный вопрос мироздания ...
http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(930)-data-file-shrink-does-not-affect-performance.aspx

(28) Один маленький вопрос - как эту ссылку открыть, и вообще с какого места её копировать в браузер.

(24) 100 гиг в хранилище за 10 мин и пофиг , ночью делает

хранилище по сети 1гиг напрямую с сервака

(30) ночью это конечно отлично, только есть фирмы которые работают в режиме 365/7/24. И когда у тебя сервак будет копировать 100 Гигов в хранилище за 10 минут - пользователи будут сосать. И некоторые делают бекап в достаточно удаленное место, куда такая скорость в принципе невозможна.
По гигабиту за 10 минут 100 гигов не скопировать.

sql пофиг работают нет , делает слепок и вперед

аналогично у нас работают 24 часа ,в сутки идет 4 архива  через каждые 6 часов , последний полный , там есть разница смен приходят уходят

(33) При чем тут SQL? когда у тебя идет копирование (быстрое) с сервака - пользователи отдыхают. Я сейчас посмотрел - у меня бэкап (.bak) 81 Гиг - копируется около 20 часов (используется разряженное копирование с помощью спецутилиты)

ипать 20 часов по диалапу ?

(36) 20 часов по 100 мегабитам. Но используется разряженное копирование, иначе пользователи повесятся.

у меня акроникс образ делает системы за 15 мин 1 терабайт и скидывает в хранилище,так как там есть всякая фигня типа мусора,для бухов

иппать.... У меня, когда я 2 недели архивов с сервера на сторедж переношу - таки никто даже и не замечает...

(38) ты скуль акронисом снимаешь?

(38) Нам не надо в хранилище. Нам надо на удаленный резервный сервак.

КАК 100 мег за 20 часов ???????

(40) да sql крутится на  системе , базы в рейде

(42) Еще раз повторю другими словами - копирование с паузами, чтоб не вешать сеть и сервак.

отдельно

(43) и как? После восстановления база цела?

(46) канечно

(41) у нас тоже бекап скидывается ежедневно по тырнету на удалёнку... Таки об этом даже никто не задумывается, кроме админа... Работает - и ладно.

(47) У меня был опыт... 7ку скуль акронисом снимали в моменты активности... Половину изменений прое....
С тех пор только штатный скулёвый бекап...

(48) Если у тебя ежедневный архив не успеет скопироваться за 24 часа, тогда произойдет коллапс.

система крутится на диске С: вместе с sql + всякий мусор, база на 2 рэдах каждый по 4терабайта , на D: data на Е: log

(50) у меня ежедневный архив выносится наружу за 49 минут...

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

(52) По тырнету 100 гигов за 49 минут?

(52) а на внешний носитель не айс ?

(54) почему 100 г? База компируется, с неё удаляется всё лишнее, типа индексов и прочего, получается около 20. Оно потом в те же 80 разворачивается.

(55) неа. С ним не успеешь убежать из нашей дыры.

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

(58) долго :-( Около часа.

(59) Не верю. Ну не может за час индексироваться стогиговая база.

(60) Jedem das seine. Не веришь - не надо.

(58)мин 10 и все , хранилище еще найти надо , и легально лицухи на все есть ,маски шоу было приходили как раз на мой ДР , я сказал им ищете что хотите , просмотрели все и ушли

(60) вы на чем там работаете ? плят

)))))))))))

(59) А что за база такая? Какой формат, какая версия 1С? Самый большой файл сколько занимает?

Не понял проблемы бэкапа. средствами SQL делается бэкап на диск SQL сервера. Потом, если требуется, другими утилитами этот готовый бэкап копируется в другое место. Как это может мешать пользователям?

restore data base и все вперед дальше ,в случае ахтунга ,а  ахтунг наступает в случае отказа техники или форс мажора ,вспышки на солнце влияние космоса ,полная луна метеориты))))

(66)средствами SQL делается бэкап , можно и не только им делать !

(66) Создай файл на 100 гигов, и с работающего сервака запусти его копирование по сети. Увидишь как это может помешать пользователям. Достаточно караул-веток уже было по этому поводу.

(65) 77, пуб, регистр партий, размер не помню

(70) Ты случайно насчет размеров не привираешь? 100 гиговый Пуб вообще не жилец.

(69) павтарйу (с) Ежедневно такое делается, никто не замечает. У тебя или с сетьюЮ или с дисками проблемы.

(66)есть программулина которая все делает  бэкап и льет по сети куда укажешь !

(71) У кого как. У нас он (был) жив. Сейчас на 8ке работаем, но та база пока ещё в действии. Просто нужно его уметь готовить :-)
Кстати, там данные за 4 года... Производство, по 2000 выпусков за сутки...

(72) Либо у тебя мало пользователей, либо бекап не 100 гиговый.

все понятно ,проблемы с сетью и с оборудованием !

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

а все из за нехватки места ,дай больше , что так народ жмется на винты ?

(77) www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(930)-data-file-shrink-does-not-affect-performance.aspx

Вторая проблема просто при копировании - тормоза не настолько серьезные, но тоже чувствительные. Тут уже неважно включено кеширование или нет. Решается копированием с паузами.

(78) Не понял, а при чем тут винты? Винтов как раз достаточно.

кеш чем забивается ?  нуликами ?

сеть ?

не ну почему у нас работает + ДенисЧ у тебя нет ?

(82) Системный кеш? Бекапом твоим забивается.

(84) У меня всё работает как часы. У вас нет такой проблемы, потому что SQL и терминал разделены.

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

(87) Ты похоже не читаешь ветку. Проблема не только в копировании.
И зачем ты предлагаешь решать несуществующую у нас проблему?
У нас проблемы нет. Ибо копирование разряженное и без кеширования.
Естественно в серваке и так две сетевые платы. Но провести вторую, отдельную сеть только для бекапа в удаленный офис мы не готовы.

А шринк раз в месяц позволяет избежать раздутия базы и бэкапа.

тут была тема я писал скрипт на шринк

(90) А чем он отличается от стандартного? Тему что-то не нашел.

(24) Я не говорил про ускорение, я говорил про замедление, от постоянного шринка.
Когда ты пишешь в таблицу 1 строку (INSERT),  SQL Server выделяет место в файле данных не ровно на одну строку, а больше, может даже несколько Мб (от настроек зависит). Чтобы не заниматься этим при следующем INSERT. Так (в основном) образуется "неиспользуемое свободное пространство" (15). Сделав shrink, ты это место забираешь и отдаешь файловой системе. После этого при следующих вставках сервер забирает его обратно, отсюда замедление.

(35)(44) Хорошие утилиты позволяют ограничивать скорость копирования, сетевой трафик, а в современных ОС - и нагрузку на диск. Это вместо того, чтобы паузы делать.

(77) Да у тебя XP наверное или 2003 непатченный? Проблемы такие были, но они давно исправлены. Нормальные утилиты, опять же, работают так, чтобы кэш не забивать (есть API соответствующий).

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

(92) Никакого замедления при выделении места естественно не происходит.
Естественно не XP. И повторюсь - это глюк любой винды.
Паузы - ты видимо не понял. Это утилита медленного копирования.
Насчет работы системного кеша - готов поспорить на деньги, и просто показать тебе системный монитор, и показать что происходит при копировании. Хоть в nul.

(92) Просто возьми 100 гиговый файл, и запусти его копирование. Параллельно включи системный монитор. И посмотри что происходит с ситемным кешем и свободной физической памятью. Можешь помочь системе с помощью CacheSet или другими утилитами - которые ей тоже не помогут. И если у тебя нет терминальных пользователей - то просто представь что с ними произойдет когда у тебя физическая память уйдет в ноль. А если есть (желательно сотня) - то просто посмотри на их реакцию.

"Никакого замедления при выделении места естественно не происходит. "

Хм... Чудеса.... Место резервируется моментально и с нулевыми затратами... Ну, точно MISTика...

(96) Написать тебе программульку, которая в цикле будет увеличивать размер файла? Увеличение файла в SQL идет кусками, и занимает времени ну никак не секунду, а значительно быстрее. О каких тормозах ты говоришь?

(95) Уточни версию Windows, сервис-пак и патчи, и чем копируешь. Если проводником, такое может быть, согласен. Если, например, Total Commander, он лишней памяти не съест.

(97) Я? О тормозах?

(97) Я думаю ты понимаешь, что в SQL это не просто увеличение размера файла. Там будет обнуление страниц, запись служебных структур, обновление системных таблиц и т.д. С сопутствующими блокировками.

(99) За секунду не увеличит. Но для примера я сейчас запустил увеличение базы при ста работающих пользователях - никаких тормозов...
(100) Я это понимаю. Но когда Шринк режет базу в два раза - иметь двухкратный запас необходимо.
(98) Любая винда. Проблема известная, и практически не имеющая нормального решения. (например в случае использования шахматных программ, которые читают с кешированием ЭБ) Зачем мне копировать тотал командером, если у меня написана своя утилита копирования? Я еще раз повторю - нет у меня проблем, а рассуждаю о преимуществах эпизодического шринка.

Блин - когда шринк режет базу в два раза - нафига иметь столько свобдного, тем более фрагментированного места?

За 20 секунд 10 гигов добавил (как раз 10 процентов) - все в это время спокойно работали.

(101) у тебя копирование файла тормозит, а увеличение не тормозит... Явно проблемы с сетью.

(95)  какие-то странные примеры. )) извиняюсь, опять не успел всю ветку прочтиать ))
Если есть ресурсы на 100 терминальных пользователей, то должны быть ресурсы и на остальное. Например, проектирование всей системы. Терминальный сервер занимается только обслуживанием пользователей, sql  обеспечивает работу базы данных. бэкапами занимается отдельный компьютер, который стягивает откуда угодно что угодно, сжимает если нужно и отправляет дальше. Для передачи 100Гб данных проектируеюся отдельные каналы толстые и тонкие, можно даже другого провайдера, который является резервным для основного. и т.п.  Нужно отделить мухи от котлет и всем будет хорошо. ))

(104) У меня (еще раз повторю) - ничего не тогрмозит.
Если у тебя уделенный офис соединен одним каналом, и в нем сидит толпа народу, то естественно копирование файла по сети на полной скорости будет тормозить их работу.
(105) Где ты видишь проблемы? Сделав два сервака вместо одного (SQL+терминал)Ты получишь замедление работы. Про Бекап я тебя не понял. Речь и идет про бекап на удаленный резервный отдельный сервер.

Памяти (и ресурсов) при использовании виндового копирования у тебя не может хватить. Причина описана выше - виндовое копирование все ресурсы (физическую память) съест подчистую под системный кеш. И получишь своп. Который SQL не затронет (ибо он резервирует память под свои нужды, и не отдает), а вот терминальных пользователей подвесит.

(101)
>Любая винда. Проблема известная, и практически не имеющая нормального решения.
Понятно. Ты любитель распространять страшилки с ламерских форумов, а не разобраться в проблеме.

(108) Укажи способ решения. Тебе многие будут благодарны.
Все мучаются с Рыбкой, которая при чтении ЭБ забивает системный Кеш, и винда перестает отвечать. Давай свой метод решения. Под какую ось, что ставить. Какие настройки. Ограничивать системный кеш можешь не предлагать - при копировании ограничение не работает.

+ (109) Заодно сам докажешь что ты не ламер, а то как-то легко бросаешься словами. Знаток системного кеша блин.

Для крутков, специалистов по системному кешу, которые вообще оказывается не в курсе что это такое - могу накидать кучу ссылок типа.
http://www.rsdn.ru/forum/life/4719252.1.aspx

(111) Родная компрессия файлов SQL  - это хоть и новый, но очень удобный механизм.
Если сравнивать RAR и SQL, на порядок быстрее. Лучше отказываться от сжатия RARом архивных файлов для хранения. SQL жмет чуть хуже чем RAR, но по скорости это небо и земля. Благодаря компрессии, понятно дело и по сети файлы быстрее пойдут.
Третий плюс компрессии  - она абсолютно прозрачна для sql. Сжатые файлы восстанавливает без вопросов. Скорость восстановления конечно слегка меньше, но опять же - не критично.
Сравнивая скорость реиндексации и перестроения индексов. Реиндексация - это очень быстро, перестроение наоборот.   ДенисЧ похоже говорит о быстрой реиндексации.

Шринковать нужно не mdf, а ldf  да и то при режиме full.
Для mdf - это нежелательно

(112) к сожалению на 2000 сжатия нет.
Реиндексация у меня явно за час не пройдет, правда индексов много.

(109) Про "Рыбку" я не в курсе даже, что это такое, тем более как она работает с файлами. Если хочешь, создай новую тему с описанием, там обсудим. Да и про копирование тоже, нечего тут зас**ать.

(115) общее решение проблемы скажи. Ты же его знаешь. Решение проблемы беспредельного роста системного кеша при чтении файлов с использованием виндового кеширования на чтение. Ты ведь сказал что вообще такой проблемы нет.

А насчет засирания темы - чего тут заси.ать?
Ежу понятно что если хочется уменьшить файл базы, то из-за еженедельного шринка ничего страшного не случится.

(116) Общего для всех случаев решения нет. Зависит и от системы и от приложения.

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

(116) >Ты ведь сказал что вообще такой проблемы нет.
Не ври. Я сказал "если проводником, такое может быть, согласен". Проблема есть, ее пытались решать в разных версиях по-разному. Вот пара хороших ссылок:
http://blogs.msdn.com/b/ntdebugging/archive/2007/11/27/too-much-cache.aspx
http://support.microsoft.com/kb/976618/en
http://blogs.msdn.com/b/ntdebugging/archive/2009/02/06/microsoft-windows-dynamic-cache-service.aspx

(118) это не решение. Такое "решение" было описано выше - например написать свое копирование, как я и сделал. Решение которое например решит проблему штатного виндового копирование - точно так же решит и проблему рыбки.
Зачем говорить о ламерах, об отсутствии общевиндового глюка, о том что кто то не понимает что такое системный кеш, приплетать сюда XP, если даже в суть глюка не въехал?

Видимо последнюю часть поста (92) писал кто-то другой.

слушал я слушал, интересно было))вспомнил, что сегодня суббота, вечер - уехал русскую водку пить!