Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Планирование обслуживания базы данных.  [new]
Alan008
Member

Откуда: г. Иваново
Сообщений: 52
2 DeColo®es:

DeColo®es
shrink только осовобождает место на диске, занятое файлом данных, естественно, уменьшая свободное место ВНУТРИ файла данных
.

Я все это знаю и именно этого и добиваюсь - чтобы файл на диске занимал меньше места. Автогроу естественно стоит, когда надо файл сам растет.
29 окт 12, 16:41    [13392272]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
автор
А зачем тогда вообще может понадобиться SHRINK, если все освобожденные страницы SQL Server всегда сам эффективно использует? Желат-но дать ссылку на BOL, где это явно прописано. Шринк кстати еще и файл лога шринкает, что в SIMPLE модели вроде актуально (т.к. никаких специальных операций по бэкапу лога и т.п. не делается).


Если грубо, то как раз для таких ситуаций, к примеру (я уже писал), когда от балды ставят full model или типа того. Короче для экстренных случаев. Скальпель тоже в природе существует, н овы же им не режете хлеб....

Для Simple - опять же не нужен. Когда проходит чекпоинт, то место в логе начинается использоваться на запись заново. Т.е. в нормальной ситуации Сервер держит под лог места столько, сколько ему необходимо.
29 окт 12, 16:43    [13392282]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Alan008
Member

Откуда: г. Иваново
Сообщений: 52
Мы не ставим "от балды Full model", тем не менее лог может значительно вырасти и уменьшаться без шринка он не хочет. Допускаю, может нужно выставить какой-то параметр сервера, чтобы лог сжимался (не копа\л эту тему).

Но все-таки, чтобы хоть как-то аргументировать допустимость SHRINK'а с последующим ребилдом индексов, приведу цитату из MSDN:

MSDN
Данные, перемещаемые в процессе сжатия файла, могут быть разбросаны по любым доступным местам в файле. Это вызывает фрагментацию индекса и может увеличить время выполнения запросов, выполняющих поиск в диапазоне индекса. Чтобы устранить фрагментацию, предусмотрите возможность перестроения индексов файла после сжатия.
29 окт 12, 16:47    [13392320]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
Alan008
Мы не ставим "от балды Full model", тем не менее лог может значительно вырасти и уменьшаться без шринка он не хочет. Допускаю, может нужно выставить какой-то параметр сервера, чтобы лог сжимался (не копа\л эту тему).

Но все-таки, чтобы хоть как-то аргументировать допустимость SHRINK'а с последующим ребилдом индексов, приведу цитату из MSDN:

MSDN
Данные, перемещаемые в процессе сжатия файла, могут быть разбросаны по любым доступным местам в файле. Это вызывает фрагментацию индекса и может увеличить время выполнения запросов, выполняющих поиск в диапазоне индекса. Чтобы устранить фрагментацию, предусмотрите возможность перестроения индексов файла после сжатия.

Вы ребилдом сделаете это и без шринкования.
29 окт 12, 16:52    [13392352]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Alan008
Member

Откуда: г. Иваново
Сообщений: 52
2 Ozerov:
Т.е. вы хотите сказать, что инструкции
EXEC sp_msforeachtable N'ALTER INDEX ALL ON ? REBUILD'
должно быть достаточно для того, чтобы файлы базы (mdf/ndf) и лога (ldf) не разрастались в размерах в ходе частых вставок и удалений данных? (т.е. общий размер базы всегда примерно одинаковый, но данные часто добавляются/удаляются)
29 окт 12, 16:58    [13392384]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
Alan008
чтобы файл на диске занимал меньше места
И какая с Вашей точки зрения от этого польза?
29 окт 12, 16:58    [13392385]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
Alan008
2 Ozerov:
Т.е. вы хотите сказать, что инструкции
EXEC sp_msforeachtable N'ALTER INDEX ALL ON ? REBUILD'
должно быть достаточно для того, чтобы файлы базы (mdf/ndf) и лога (ldf) не разрастались в размерах в ходе частых вставок и удалений данных? (т.е. общий размер базы всегда примерно одинаковый, но данные часто добавляются/удаляются)


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

Если у Вас модель восстановления Simple, сервер сам будет поддерживать необходимое ему место под базу, он лучше Вас знает сколько ему надо. Ну если без форсмажера.
29 окт 12, 17:02    [13392413]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Alan008
Member

Откуда: г. Иваново
Сообщений: 52
Хорошо бы, если так. Но явных подтверждений этому я пока не видел (ни в документации, ни на практике). Имею в виду подтверждений тому, чтобы после ребилда индексов файлы базы стали вдруг меньше.

>>он лучше Вас знает сколько ему надо
Он знает, но по-моему он никогда не отдает операционке свободное место в файлах "добровольно". Т.е. отдать может только в результате шринка. Поправьте меня, если я вру. Желат-но со ссылкой на какой-нибудь авторитетный источник.
29 окт 12, 17:06    [13392437]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Glory
Member

Откуда:
Сообщений: 104751
Alan008
Он знает, но по-моему он никогда не отдает операционке свободное место в файлах "добровольно".

А зачем ? Вам за свободное место на дисках надбавки к зарплате дают ?
Или вы не считаете затраты на операции расширения файлов существенными ?
29 окт 12, 17:09    [13392449]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
Вы издеваетесь ? Где я писал, что он отдает ? База имеет свойство расти. И даже если какое либо место освободилось в ней, оно потом будет занято новыми данными. И нет смысла высвобождать его каждый раз шринком. Это место не критично, а сервер начинает напрягаться в момент прироста файла, падает производительность. Но сервер все равно забрал, то что Вы освободили. Так что Вам принесла та операция сжатия базы ?...
29 окт 12, 17:11    [13392464]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Alan008
Member

Откуда: г. Иваново
Сообщений: 52
>>База имеет свойство расти
Для баз, имеющих свойство расти, согласен. Шринкать смысла нет.

Я же описывал ситуацию, когда база не растет, но сильно обновляется. Т.е. размер данных в базе всегда 10 ГБ (к примеру), но каждый день из нее 200 МБ данных удаляется и 200 МБ новых данных добавляется. В этих условиях шринк ох как полезен.
29 окт 12, 17:16    [13392492]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Alan008
Member

Откуда: г. Иваново
Сообщений: 52
2 Glory:

>>Или вы не считаете затраты на операции расширения файлов существенными ?
Считаю. Там стоит в процентах (например, 10%). Для файла размером 10 ГБ это 1 ГБ. База не так часто вырастает на эту величину (благодаря шринку в том числе).
29 окт 12, 17:18    [13392510]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
Alan008
>>База имеет свойство расти
Для баз, имеющих свойство расти, согласен. Шринкать смысла нет.

Я же описывал ситуацию, когда база не растет, но сильно обновляется. Т.е. размер данных в базе всегда 10 ГБ (к примеру), но каждый день из нее 200 МБ данных удаляется и 200 МБ новых данных добавляется. В этих условиях шринк ох как полезен.


Шринк, МОЖЕТ быть полезен, если резко удалилось БОЛЬШОЕ кол-во данных и не планирует увеличиваться.

В Вашем случае полезно иметь достаточно места и не насиловать сервер.
29 окт 12, 17:21    [13392532]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Glory
Member

Откуда:
Сообщений: 104751
Alan008
Считаю. Там стоит в процентах (например, 10%). Для файла размером 10 ГБ это 1 ГБ. База не так часто вырастает на эту величину (благодаря шринку в том числе).

Офигеть. Оказывается, удаляя из базы свободное место, я уменьшаю вероятность операции расширения файла для следующих команд. Ноу комментс.
29 окт 12, 17:25    [13392552]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Alan008
Member

Откуда: г. Иваново
Сообщений: 52
Шринк выполняю с опцией резервирования 10% свободного места.
29 окт 12, 17:28    [13392573]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
Alan008
Шринк выполняю с опцией резервирования 10% свободного места.

а чего не 20%
29 окт 12, 17:29    [13392576]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Centraloff
Member

Откуда: Екатеринбург
Сообщений: 138
Alan008,

Если вы говорите что база не растет с течением времени, добавьте 3-5 Гб (немного больше дельты которую вы озвучили) к размеру базы и забудьте вобще про это шринк и не насилуйте уже жесткие диски у них тоже есть свой предел работы. а 3-5Гб в современных дисках это капля в море. Данные будут внутри этого файла перемещаться, но файл расти не будет, а если будет то очень незначительно.
29 окт 12, 18:11    [13392837]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Alan008
Но все-таки, чтобы хоть как-то аргументировать допустимость SHRINK'а с последующим ребилдом индексов, приведу цитату из MSDN:
MSDN
Данные, перемещаемые в процессе сжатия файла, могут быть разбросаны по любым доступным местам в файле. Это вызывает фрагментацию индекса и может увеличить время выполнения запросов, выполняющих поиск в диапазоне индекса. Чтобы устранить фрагментацию, предусмотрите возможность перестроения индексов файла после сжатия.
Вы сейчас аргументировали только то, что шринк плохая операция, которая имеет большой побочный эффект, а также описание как это исправить. Но если можно изначально не делать ширинк, то и проблем не будет, не? Я бы вас уволил, чес-слово. За отутствие логики и понимания причинно-следственных связей.

Вот вам ссылка на авторитетный источник, авторитетнее уже не куда.
http://www.sqlskills.com/blogs/paul/post/why-you-should-not-shrink-your-data-files.aspx
Data file shrink should never be part of regular maintenance, and you should NEVER, NEVER have auto-shrink enabled. I tried to have it removed from the product for SQL 2005 and SQL 2008 when I was in a position to do so - the only reason it's still there is for backwards compatibility.

Alan008
Я вам поясняю: через базу проходит в день, допустим 200 МБ данных (т.е. 200 МБ - это дельта, столько удаляется старых данных и приходит новых, примерно 50/50). За 2 недели соответственно 200 МБ*14=2.7 ГБ примерно. 2.7 ГБ дельты! Если SHRINK позволит мне хотя бы 1 ГБ из них освободить, я уже буду рад.
Вы это проверяли? про 2.7 гига? Или научно-дедуктивно-математическом методом выяснили? У вас зарплата в гигибайтах?

+ перефразируя известный анекдот
Поймал ДБА золотую рыбку. Взмолилась рыбка:
-Отпусти меня, ДБА, я исполню три твоих желания!
-Хочу, чтоб база стала занимать меньше места.
Исполнила рыбка его желание.
-Говори второе желание!
Хочу, чтобы в базе не было фрагментации!
Исполнила рыбка его желание и выполнила ребилд всех индексов.
-Говори третье желание!
-Хочу, чтоб база стала занимать меньше места.
Исполнила рыбка третье желание и спрашивает:
-Слушай, ДБА, а зачем тебе это?
-Люблю, когда данные тусуются.
29 окт 12, 22:36    [13393729]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Centraloff
Alan008,

Если вы говорите что база не растет с течением времени, добавьте 3-5 Гб (немного больше дельты которую вы озвучили) к размеру базы и забудьте вобще про это шринк и не насилуйте уже жесткие диски у них тоже есть свой предел работы. а 3-5Гб в современных дисках это капля в море. Данные будут внутри этого файла перемещаться, но файл расти не будет, а если будет то очень незначительно.
Может расти для 2008 и 2008R2, если много удалений. Исправлено в CU4 for SP3 http://support.microsoft.com/kb/2622823
29 окт 12, 22:43    [13393751]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Idol_111
Member

Откуда:
Сообщений: 633
Yacudzer,

1. Выносить индексы и разбивать таблицу имеет смысл только если собираетесь физически поместить эти файлы на другие диски. Однако, исходя из вашей информации и при правильно построенных индексах, Вам еще минимум года два не нужно об этом париться.
2. Recovery model не может быть обусловленно никаким прикладным ПО. Нам мой взгляд бэкап раз в сутки слишком мало, но это вашему бизнесу решать каким количеством данных они готовы рискнуть. Если Вы имеете доступ к БД и юридически Вы не ограничены в обслуживании вашей БД, Я бы на вашем месте поставил FULL и делал один полный бекап, пару DIFF в течении дня и 10-20 мин лог бекап. Только в одном случае разработчики предпочитают Simple, (адекватные разработчики), если они пихают в базу много и сразу. Однако, в вашем случае похоже, что 10минутного лог бекапа и 10Гб лог файла хватить за глаза, чтобы подстраховать на такой случай. Большой лог файл в любом случае будет нужен при перестройке индексов такой большой таблицы.
2.1. Ребилд/реорганизацию индексов (при фрагментации 30/10% соответственно)(скрипт в инете), CHECKDB и статистику один раз в неделю достаточно.

16Гб, исходя из вашего описания, более чем достаточно. Быстро и грубо можно соориeнтироваться понаблюдая счетчик page life expectancy.

Про шринк товарища Alan не слушайте, о грубо заблуждается :(.
30 окт 12, 05:50    [13394261]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
kain111
Member

Откуда:
Сообщений: 227
добавлю про вероятность использования шринк. Я встречал ситуацию когда он был необходим. Новый начальник не знал как выбить деньги на расширение сервера, который имел ограничение по объему жестких дисков. потому после загрузки данных и перестройки индексов ночью производился шринк, чтобы высвободиь место на бэкап и его архивацию для дальнейшего отправления по сети. ~200гб база.
НО ситуация была не нормальная!
30 окт 12, 08:57    [13394562]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Alan008
Member

Откуда: г. Иваново
Сообщений: 52
Давайте уже закроем эту тему про шринк.
Подытоживаю:
1) Шринк не рекомендуется для частого применения, т.к. приводит к фрагментации, которую можно устранить только перестройкой индексов (которая в некоторых случаях может вновь увеличить размер базы)
2) Шринк не рекомендуется для частого применения, т.к. по мнению большинства это ресурсоемкая операция (хотя на моей практике шринк выполняется не более чем за несколько минут для баз в несколько десятков гигабайт).
3) Шринк позволяет уменьшить размер физических файлов базы данных за счет уплотнения страниц в них и передаче освободившегося зарезервированного пространства операционной системе.
4) Шринк - это единственный "прямой" способ уменьшения размера физических файлов после удаления значительной порции данных из базы, т.к. SQL Server самостоятельно не возвращает зарезервированное место внутри файлов базы операционной системе.
На основе приведенных фактов каждый homo sapience сам способен решить, нужна ему операция шринк в плане регулярного обслуживания его базы или нет.
30 окт 12, 09:02    [13394589]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Centraloff
Member

Откуда: Екатеринбург
Сообщений: 138
Alan008,

Дело то в том, что вы сами заблуждаетесь да еще и других учите этому...
30 окт 12, 09:17    [13394633]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Alan008
Member

Откуда: г. Иваново
Сообщений: 52
2 Centraloff:
В чем конкретно заблуждение? В предыдущем моем посте одни сухие факты.
30 окт 12, 09:33    [13394692]     Ответить | Цитировать Сообщить модератору
 Re: Планирование обслуживания базы данных.  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
Alan008
Давайте уже закроем эту тему про шринк.
Подытоживаю:

2) Шринк не рекомендуется для частого применения, т.к. по мнению большинства это ресурсоемкая операция (хотя на моей практике шринк выполняется не более чем за несколько минут для баз в несколько десятков гигабайт).
.

О, Господи.... Вы как читаете ?... Приращение файлов затратная операция, которая будет происходит после ужатия (шринка) базы.

автор
1) Шринк не рекомендуется для частого применения, т.к. приводит к фрагментации, которую можно устранить только перестройкой индексов (которая в некоторых случаях может вновь увеличить размер базы)

Он рекомендуется только для экстренного применения. если нет места и деваться УЖЕ НЕКУДА. А освободить пару гигов, когда на схд хватает места, это бесполезная операция для Вас и вредная для сервера.

3,4 - в общих чертах - да.
30 окт 12, 09:49    [13394749]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить