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

Откуда: Ленинградская область
Сообщений: 128
Подскажите, пожалуйста правильный набор команд для сжатия базы и лога с убиванием всего лишнего, что занимает место. Спасибо.
22 окт 15, 18:09    [18313533]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
Integrator2, для убивания "всего лишнего" - delete, truncate, drop - критерии "лишнести" вы определяете сами.
Для очистки лога - бэкап лога (можно в nil бэкапить, если нет небходимости в сохранении лога).
для сжатия: dbcc shrinkdatabase.
22 окт 15, 18:32    [18313648]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
Integrator2
Member

Откуда: Ленинградская область
Сообщений: 128
Аналог Access COMPACT DATABASE хочу.

Вот это подойдет?
use db
go
BACKUP LOG db WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE (db_Log , 10)
go
22 окт 15, 18:37    [18313665]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
Integrator2, сжатие лога не может быть аналогом Compact database потому, что в Access нет лога.

Вам бы для начала разобраться, из чего состоит база MS SQL, как определить, что вы хотите сжать, и можно ли это сжимать, и только потом уже писать команды.
23 окт 15, 09:59    [18315287]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
Shrink - вредная операция.
Лучше определиться с моделью восстановления и бэкапом логов, если необходимо.
23 окт 15, 10:14    [18315373]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
gang
Member

Откуда:
Сообщений: 1394
Ozerov
Shrink - вредная операция.

Для лога похфиг.
23 окт 15, 10:34    [18315500]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
gang
Ozerov
Shrink - вредная операция.

Для лога похфиг.


Не всегда. Бывают ситуации, когда роль играет колличество виртуальных логов журнала транзакций.
Если ТС не понимает работу шринка и его последствий, лучше не играться с этим на проде\, а разобраться с причиной роста объема и т.п.
23 окт 15, 10:41    [18315539]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
Integrator2
Member

Откуда: Ленинградская область
Сообщений: 128
Я удалил большое количество записей в тч с содержимом поля типа image. А также создавал таблицы такими же полями, наполнял данными, затем удалил таблицы. Хочу сжать БД, чтобы произошло физическое удаление и размер файла-бакапа вернулся к прежнему, комппактному размеру. Что написать?
23 окт 15, 11:09    [18315678]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
o-o
Guest
gang
Ozerov
Shrink - вредная операция.

Для лога похфиг.

фигасебе.
именно лог и будет зануляться при расширении обратно,
от этого никуда не уйти, а ждать прилично
23 окт 15, 11:14    [18315700]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
Glory
Member

Откуда:
Сообщений: 104751
Integrator2
Я удалил большое количество записей в тч с содержимом поля типа image. А также создавал таблицы такими же полями, наполнял данными, затем удалил таблицы. Хочу сжать БД, чтобы произошло физическое удаление и размер файла-бакапа вернулся к прежнему, комппактному размеру. Что написать?

Для начала узнать, если в действительности то, что сжимать.
А то "удалил много", но из середины таблицы - не сжимается, а дефрагментируется.
23 окт 15, 11:15    [18315707]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
o-o
gang
пропущено...

Для лога похфиг.

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

Уйти можно :)
Perform volume maintenance task
23 окт 15, 11:19    [18315729]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
o-o
Guest
Integrator2
Хочу сжать БД, чтобы произошло физическое удаление и размер файла-бакапа вернулся к прежнему, комппактному размеру. Что написать?

вы думаете, что бэкап пустое место бэкапирует?
он только данные берет вообще-то.
если у меня база в 100Мб, но пуста, бэкап 221Кб весит
23 окт 15, 11:19    [18315730]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
o-o
Guest
Ozerov
o-o
пропущено...

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

Уйти можно :)
Perform volume maintenance task

та ссылка
If Instant File Initialization is enabled, then you will see SQL Server zeroing out only the ldf (log) files.

не уйдут они от зануления файлов лога никогда,
это им придется вообще революцию в логостроении проводить.
на этом завязано обнаружение текущего конца лога
23 окт 15, 11:23    [18315749]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
o-o
Ozerov
пропущено...

Уйти можно :)
Perform volume maintenance task

та ссылка
If Instant File Initialization is enabled, then you will see SQL Server zeroing out only the ldf (log) files.

не уйдут они от зануления файлов лога никогда,
это им придется вообще революцию в логостроении проводить.
на этом завязано обнаружение текущего конца лога

Да, извиняюсь, чуток потерял нить, что именно про лог идет речь.
23 окт 15, 11:28    [18315777]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
gang
Member

Откуда:
Сообщений: 1394
Ozerov, o-o
То о чем вы говорите эффекты не от сжатия, а от последующего роста лога.
Необходимость последующего увеличения лога - это вопрос размера, до которого выполняется шринк и соответствия модели восстановления и схемы обслуживания БД профилю нагрузки.
Количество же VLF-оф определяется параметрами автороста и к самому шринку отношения тоже не имеет.
Вот на данных, в отличие от лога, шринк уже гадит в полный рост, увеличивая фрагментацию. И делает это самостоятельно, независимо от гипотетической последующей активности.
23 окт 15, 14:34    [18317032]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
gang
Ozerov, o-o
То о чем вы говорите эффекты не от сжатия, а от последующего роста лога.

Мне кажется, что понятно было, что мы имели в виду.
Росту предшествует сжатие, если ТС будет шринковать постоянно.
23 окт 15, 14:47    [18317147]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
o-o
Guest
gang
То о чем вы говорите эффекты не от сжатия, а от последующего роста лога.

но ведь последующий рост -- это побочный эффект сжатия.
транзитивность

хотя, если он собрался базу куда-то нести и там восстанавливать и делать read only, то конечно, лог надо урезать.
мы-то предполагаем дальнейшую работу с исходной базой
23 окт 15, 14:52    [18317202]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
gang
Member

Откуда:
Сообщений: 1394
Ozerov
Мне кажется, что понятно было, что мы имели в виду.

Мне тоже кажется, что понятно было что я имел в виду.
Ozerov
Росту предшествует сжатие, если ТС будет шринковать постоянно.

Есть такая классическая ошибка в формальной логике. По русски звучит примерно как "после не значит вследствие", да еще и "если" у вас присутствует.
23 окт 15, 16:57    [18318208]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3637
gang,

Тро ло ло ?
23 окт 15, 17:05    [18318263]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
o-o
Guest
[quot gang]
Ozerov
Есть такая классическая ошибка в формальной логике. По русски звучит примерно как "после не значит вследствие", да еще и "если" у вас присутствует.

оooo,
я так понимаю, вы намекаете, что если далее базой не пользоваться,
то и лог не вырастет, правильно?
ведь рост лога -- это логическое следствие write-деятельности в базе.
и шринк как бы и ни при чем.
ну так мы с Озеровым вам скажем: да и данным абсолютно фиолетово.
подумаешь, переместились.
зато компактно теперь.
или будет не все равно, если потом эти данные начнут читать?
ну так задумчивость сервера -- это следствие запросов , т.е. read-деятельности в базе,
а вовсе и никакого не шринка.
так что и вы в силу той же самой логики формально неправы ("если" и "потом" тоже присутсвуют!!!)
23 окт 15, 17:37    [18318432]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
gang
Member

Откуда:
Сообщений: 1394
o-o
я так понимаю, вы намекаете, что если далее базой не пользоваться,
то и лог не вырастет, правильно?
ведь рост лога -- это логическое следствие write-деятельности в базе.

Нет неправильно понимаете. Я не намекаю, а абсолютно ясно говорю, что лог растет не из-за шринка, не из-за "пользования" базой и даже не из-за записи в БД, а из-за того, что
текущий размер лога, модель восстановления и/или регламент резервного копирования не соответствует интенсивности этой записи.
Это в идеальном случае, не беря во внимание аномалии типа незакоммиченных транзакций, привставших реплик, зеркал и пр.
o-o
и шринк как бы и ни при чем.

Шринк ни при чем, см. выше. Более того, оптимизация количества VLF-ов, о которой говорил коллега Ozerov начинается именно со шринка лога с последующим ручным расширением до нужного размера при адекватных параметрах автороста. Конечно, если на террабайтной OLTP БД, которой под нормальную работу лога нужно гигов 100, зажать лог под ноль, выставить какой-нибудь бредовый авторост и под кофеек наблюдать что будет дальше, то хорошего таки ничего не будет. Но только сценарий применения шринка лога не исчерпывается таким неадекватным вариантом. А так-то логика очень понятна: если ёbнYть по пальцу молотком, то виноват конечно же молоток.
o-o
и данным абсолютно фиолетово.
подумаешь, переместились.
зато компактно теперь.
или будет не все равно, если потом эти данные начнут читать?
ну так задумчивость сервера -- это следствие запросов , т.е. read-деятельности в базе,
а вовсе и никакого не шринка.
так что и вы в силу той же самой логики формально неправы ("если" и "потом" тоже присутсвуют!!!)

Сами написали ерунду, сами объяснили что это ерунда. Не понятно только я здесь причем, ни одной моей фразы тут нет. Почему я-то в итоге неправ =)
26 окт 15, 11:41    [18326055]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
gang
Member

Откуда:
Сообщений: 1394
Ozerov
gang,

Тро ло ло ?

Вовсе нет. Изначально имел в виду только, что последствия шринка в виде фрагментации для данных наступают необратимо в результате самого шринка. Для лога такого эффекта нет. Необходимость же последующего роста лога обратно, которую стали обсуждать затем, далеко не обязательна и даже не очевидна при наличии доли здравого смысла у шринкующего. Эмоции же - плоды резких по форме, но не всегда точных по сути формулировок. Ваш первый комментарий, кстати, был весьма корректным и содержательным. Далее пошли споры о словах.
26 окт 15, 11:51    [18326148]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
o-o
Guest
gang
оптимизация количества VLF-ов, о которой говорил коллега Ozerov начинается именно со шринка лога с последующим ручным расширением до нужного размера при адекватных параметрах автороста.

вот как раз в ерунде про зависимость числа vlf-ов от шринка я не участвую.
более того, я подозреваю, откуда Озеров это притащил на форум.
ровно это самое, оказывается, сообщил товарищ Костылев на недавнем мероприятии в Мск,
и это записано, и можно это наблюдать на соответствующем сайте.
как раз он и говорит
1) с какой-то версии сервера достаточно выдать Perform volume maintenance tasks,
все будет в шоколаде, лог не станет зануляться -- сие неверно (см. выше, как это проверяется выставлением флага,
вынуждающего писать в еррорлог события зануления)
2) куча vlf-ов препятствует быстрому recovery.
-- с этой фразой все ок, но далее:
"вот если бы был 1 vlf, время незначительное" -- уже ерунда, т.к. менее 2-ух vlf-ов вообще не может быть,
иначе у лога не будет циклической структуры,
"а при шринковании/разрастании" будет куча vlf-ов"
вот тут именно что никакой шринк ни при чем.
конечное число vlf-ов зависит только от конечного размера логов и выставленного приращения.
если приращение выставлено в 500Мб, а размер лога 20Гб, то лог приращивается этими кусками по 500
с соответствующим числом vlf-ов, определенным этими самыми 500Гб (тут цифра меняется в зависимости от версии сервера)
и если мы нарастили лог за 40 приращений, потом шринканули до 1Гб, а потом он сам растет до 20Гб снова,
то все равно кусков добавится 38, каждый по 500Мб, и vlf-ов станет ровно сколько и было
26 окт 15, 12:11    [18326281]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
o-o
Guest
gang
o-o
и данным абсолютно фиолетово.
подумаешь, переместились.
зато компактно теперь.
или будет не все равно, если потом эти данные начнут читать?
ну так задумчивость сервера -- это следствие запросов , т.е. read-деятельности в базе,
а вовсе и никакого не шринка.
так что и вы в силу той же самой логики формально неправы ("если" и "потом" тоже присутсвуют!!!)

Сами написали ерунду, сами объяснили что это ерунда. Не понятно только я здесь причем, ни одной моей фразы тут нет. Почему я-то в итоге неправ =)

нет.
вы формально придрались, ну так и я тоже.
давайте придерусь подробнее, раз так непонятно.

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

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

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

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

но и это скорее исключение.
хотя, согласитесь, "безоговорочность" оказалась не такой безоговорочной
26 окт 15, 12:26    [18326374]     Ответить | Цитировать Сообщить модератору
 Re: Сжатие БД  [new]
gang
Member

Откуда:
Сообщений: 1394
gang
оптимизация количества VLF-ов, о которой говорил коллега Ozerov начинается именно со шринка лога с последующим ручным расширением до нужного размера при адекватных параметрах автороста.

o-o
+
вот как раз в ерунде про зависимость числа vlf-ов от шринка я не участвую.
более того, я подозреваю, откуда Озеров это притащил на форум.
ровно это самое, оказывается, сообщил товарищ Костылев на недавнем мероприятии в Мск,
и это записано, и можно это наблюдать на соответствующем сайте.
как раз он и говорит
1) с какой-то версии сервера достаточно выдать Perform volume maintenance tasks,
все будет в шоколаде, лог не станет зануляться -- сие неверно (см. выше, как это проверяется выставлением флага,
вынуждающего писать в еррорлог события зануления)
2) куча vlf-ов препятствует быстрому recovery.
-- с этой фразой все ок, но далее:
"вот если бы был 1 vlf, время незначительное" -- уже ерунда, т.к. менее 2-ух vlf-ов вообще не может быть,
иначе у лога не будет циклической структуры,
"а при шринковании/разрастании" будет куча vlf-ов"
вот тут именно что никакой шринк ни при чем.
конечное число vlf-ов зависит только от конечного размера логов и выставленного приращения.
если приращение выставлено в 500Мб, а размер лога 20Гб, то лог приращивается этими кусками по 500
с соответствующим числом vlf-ов, определенным этими самыми 500Гб (тут цифра меняется в зависимости от версии сервера)
и если мы нарастили лог за 40 приращений, потом шринканули до 1Гб, а потом он сам растет до 20Гб снова,
то все равно кусков добавится 38, каждый по 500Мб, и vlf-ов станет ровно сколько и было

Вот же не лень Вам столько текста набивать. И все мимо того, что из меня процитировали. Не знаю какое у Вас сложилось впечатление и почему вместо меня Вы начали спорить с неким Костылевым, которого где-то услышали, но о том что я имел в виду можно прочесть например тут и тут. Это никак не идет вразрез с тем что Вы написали, но рассматриваете вы опять какие-то неадекватные примеры. Ну да, фразы которые Вы процитировали мягко говоря нелогичны, ваши контраргументы против них справедливы, но их здесь опубликовали Вы. Зачем же со мной или коллегой Озеровым разводить спор по поводу того, что написали Вы сами?
26 окт 15, 13:33    [18326905]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить