Нужен ли Shrink БД 1С8 в sql 2008? файла данных или журнала транзакций? #624589

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

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

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

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

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

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

gthdst 4 jlyjpyfxyj

Однозначно нужны?

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

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

ни каким.

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

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

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

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

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

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

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

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

Не ответы на мои вопросы, но... Никогда не слышал про differential и compression? Насчет разницы, не сверял, а ты? С чего бы ей быть?

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

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

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

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

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

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

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

Баян )))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

отдельно

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

канечно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

)))))))))))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

сеть ?

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

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

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

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

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

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

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

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

Я не говорил про ускорение, я говорил про замедление, от постоянного шринка. Когда ты пишешь в таблицу 1 строку (INSERT),  SQL Server выделяет место в файле данных не ровно на одну строку, а больше, может даже несколько Мб (от настроек зависит). Чтобы не заниматься этим при следующем INSERT. Так (в основном) образуется "неиспользуемое свободное пространство" . Сделав shrink, ты это место забираешь и отдаешь файловой системе. После этого при следующих вставках сервер забирает его обратно, отсюда замедление. Хорошие утилиты позволяют ограничивать скорость копирования, сетевой трафик, а в современных ОС - и нагрузку на диск. Это вместо того, чтобы паузы делать. Да у тебя XP наверное или 2003 непатченный? Проблемы такие были, но они давно исправлены. Нормальные утилиты, опять же, работают так, чтобы кэш не забивать (есть API соответствующий). Вообще про работу системного кэша лучше не рассуждай, если не знаешь. А то некоторые поверят и дальше разнесут.

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

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

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

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

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

Я? О тормозах?