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

Откуда: Kiev
Сообщений: 6794
Serg58
TaPaK
и скорее всего в индексы в не попадаете

Вот эту фразу не совсем понял.

fullscan статистики в ночь включу.

если не смотрите в конкретные запросы, то начните например
https://blog.sqlauthority.com/2011/01/03/sql-server-2008-missing-index-script-download/

с фильтром на ваши основные объекты
21 май 18, 12:09    [21425420]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Щукина Анна
Member

Откуда:
Сообщений: 1466
TaPaK
если не смотрите в конкретные запросы, то начните например
https://blog.sqlauthority.com/2011/01/03/sql-server-2008-missing-index-script-download/

с фильтром на ваши основные объекты
нужно предупредить - что все рекомендации, выдаваемые такими скриптами, требуют тщательной проверки! Возможно, в системе уже есть подобные индексы, у которых всего лишь не хватает поля-другого в секции include. Слепо плодить индексы - не стОит, они - не бесплатные. Индексы нужно хранить, индексы нужно поддерживать в актуальном состоянии (и сейчас речь не за пользовательские манипуляции, а про "подкапотную" работу сервера, связанную с поддержанием целостности и актуальности индексов и с вязанной с ними информацией).
21 май 18, 12:16    [21425452]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
Щукина Анна
TaPaK
если не смотрите в конкретные запросы, то начните например
https://blog.sqlauthority.com/2011/01/03/sql-server-2008-missing-index-script-download/

с фильтром на ваши основные объекты
нужно предупредить - что все рекомендации, выдаваемые такими скриптами, требуют тщательной проверки! Возможно, в системе уже есть подобные индексы, у которых всего лишь не хватает поля-другого в секции include. Слепо плодить индексы - не стОит, они - не бесплатные. Индексы нужно хранить, индексы нужно поддерживать в актуальном состоянии (и сейчас речь не за пользовательские манипуляции, а про "подкапотную" работу сервера, связанную с поддержанием целостности и актуальности индексов и с вязанной с ними информацией).


чукча не читатель?
автор
Please note, if you should not create all the missing indexes this script suggest. This is just for guidance. You should not create more than 5-10 indexes per table. Additionally, this script sometime does not give accurate information so use your common sense.


автор
Индексы нужно хранить

кхм
21 май 18, 12:20    [21425468]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Щукина Анна
Member

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

почитайте, с каким рвением и, практически, без проверок ТС пускает решения с форума в продакт (и его можно понять - база "тормозит", работа стоит, сроки срываются - тут нет времени на обдумывания и глубокое погружение во всё и сразу)...
Вам станет понятно - что это не такое уж и бесполезное замечание....
21 май 18, 12:26    [21425484]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Щукина Анна
Member

Откуда:
Сообщений: 1466
Щукина Анна,

я к тому, что стОит делать акценты на очевидные (не для новичка), но критичные в ситуации ТС моменты...
21 май 18, 12:27    [21425489]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
Щукина Анна,

охх сколько бессмысленного текста...
21 май 18, 12:28    [21425492]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Щукина Анна
Member

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

вас никто не заставляет его читать... ;)
можете просто игнорировать посты с моим авторством...
в конце концов - я же не вам помогаю ;)
21 май 18, 12:31    [21425500]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Serg58
Member

Откуда:
Сообщений: 65
Щукина Анна,
Щукина Анна
TaPaK,
почитайте, с каким рвением и, практически, без проверок ТС пускает решения с форума в продакт (и его можно понять - база "тормозит", работа стоит, сроки срываются - тут нет времени на обдумывания и глубокое погружение во всё и сразу)...
Вам станет понятно - что это не такое уж и бесполезное замечание....


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


А можно вопрос? А то запутались совсем...
- Разностное резервное копирование (Differential backup) BACKUP DATABASE WITH DIFFERENTIAL;
- Резервное копирование журнала транзакций (Transaction Log Backup) BACKUP LOG;

это взаимоисключащие вещи или нет? То есть, если мы делаем разностное копирование надо ли нам делать второе?
21 май 18, 14:33    [21425971]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Владислав Колосов
Member

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

если не хотите терять данные между разностными копими, то надо.
21 май 18, 14:47    [21426050]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Щукина Анна
Member

Откуда:
Сообщений: 1466
Serg58
А можно вопрос? А то запутались совсем...
- Разностное резервное копирование (Differential backup) BACKUP DATABASE WITH DIFFERENTIAL;
- Резервное копирование журнала транзакций (Transaction Log Backup) BACKUP LOG;

это взаимоисключащие вещи или нет? То есть, если мы делаем разностное копирование надо ли нам делать второе?

[SET "Captain Obvious" = ON]

Гораздо правильнее будет сказать - "взаимодополняющие".

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

2) Разностный бэкап, как и алгебраическая "разность", представляет собой разницу между "уменьшаемым" и "вычитаемым" - то есть, по сути, это копия тех страниц, что претерпели изменения с момента последнего бэкапа. И так как это "разность", то сама по себе, без исходного состояния базы, он не представляет никакой ценности. Для восстановления с разностной копии требуется "уменьшаемое" - стартовая ПОЛНАЯ копия базы + все промежуточные "разности". Восстановление возможно лишь на момент выката любой из разностных копий. При наличии только разностной копии, без полной - восстановиться невозможно.

3) Копия транзакт-лога. Журнал, он и в африке - журнал. Содержит все ЛОГИРУЕМЫЕ операции, применяемые к базе. Сам по себе - малоинтересен и бесполезен. Но при наличии исходной полной копии и промежуточных копий журнала позволяет восстановиться на любой момент времени.

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

[SET "Captain Obvious" = OFF]
21 май 18, 16:08    [21426455]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Serg58
Member

Откуда:
Сообщений: 65
Щукина Анна
Гораздо правильнее будет сказать - "взаимодополняющие"...

Вооот! У вас очень просто и понятно написано, откуда вы цитируете если не секрет?
И у меня несколько уточняющих вопросов:
1.если делать только полный бекап по понедельникам и каждый следующий день недели разностный, то что будет с лог файлом? Он будет расти и расти? Надо ли его как-то чистить? Вот этот момент мне не понятен. Или вообще я не должен беспокоится о его размере, сколько он будет весить, столько и должен, а попытки его уменьшить негативно отразятся на работе БД?

2. Если делать полный бекап по понедельникам, разностный ежедневно в 02:00, а бекап транзакт-лога в полдень. То как выглядит восстановление? Сначала восстанавливаем последний полный бекап, потом последний разностный и потом последний транзакт-лог?

я думаю, надо мне проще создать тестовую бд и поиграться с различными вариантами.
21 май 18, 16:22    [21426506]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
felix_ff
Member

Откуда: Moscow
Сообщений: 1172
Serg58,

усвойте уже простую истину: в полной модели восстановления единственно возможный способ сделать так что бы журнал транзакций не рос до бесконечности это сделать его бэкап {инструкция backup log}

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

вся информация есть в официальной справке: https://docs.microsoft.com/ru-ru/sql/relational-databases/backup-restore/transaction-log-backups-sql-server?view=sql-server-2017

https://docs.microsoft.com/ru-ru/sql/relational-databases/backup-restore/back-up-and-restore-of-sql-server-databases?view=sql-server-2017
21 май 18, 16:41    [21426554]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Щукина Анна
Member

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

1) В общем случае, транзакт-лог - это "бесконечная лента", размер которой ограничен либо заданным на уровне базы лимитом, либо (в отсутствии лимита) - доступным размером свободного места на диске. Как вам уже отвечали ранее другие ораторы - размер лога (занятое место внутри LDF-файла) уменьшается (штатно) только механизмом его резервного копирования. Ни полный бэкап, ни разностный бэкап - размер транзакт-лога не уменьшают. Есть "нештатный" способ уменьшения лога - перевод базы в режим восстановления "simple" с последующим шринком лога. Почему "нештаный"? Потому что есть ограничения на его применения. Если в базе используются вещи, требующие режима "full" или "bulk" (к примеру, лог-шиппинг), то перевод базы в "simple" "ломает" эти вещи и требует дальнейшей их повторной настройки. Более того - сервер будет всячески сопротивляться переводу в simple в этом случае. Поэтому, сначала придется "сломать" лог-шиппинг, после - перевести базу в симпл, урезать лог, а затем - всё вернуть в исходное состояние. Поверьте - по количеству телодвижений и потенциальных мест для факапа - это сильно сложнее, чем банальный бэкап транзакт-лога.

2) Если есть набор разных вариантов бэкапа, то и варианты восстановления будут разные. Можно восстановить полный бэкап и накатить на него все доступные копии журнала транзакций, без промежуточного наката разностных копий. Можно восстановиться с полной копии, "догнаться" всеми промежуточными разностными до какой-то точки, после чего "шлифануть" всё копией журнала. Тут главное помнить - движемся от большего к меньшему. Накатили полный - (опционно) накатили разностные - накатили журнал.
21 май 18, 16:54    [21426579]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
Serg58
Щукина Анна
Гораздо правильнее будет сказать - "взаимодополняющие"...

Вооот! У вас очень просто и понятно написано, откуда вы цитируете если не секрет?
И у меня несколько уточняющих вопросов:
1.если делать только полный бекап по понедельникам и каждый следующий день недели разностный, то что будет с лог файлом? Он будет расти и расти? Надо ли его как-то чистить? Вот этот момент мне не понятен. Или вообще я не должен беспокоится о его размере, сколько он будет весить, столько и должен, а попытки его уменьшить негативно отразятся на работе БД?

2. Если делать полный бекап по понедельникам, разностный ежедневно в 02:00, а бекап транзакт-лога в полдень. То как выглядит восстановление? Сначала восстанавливаем последний полный бекап, потом последний разностный и потом последний транзакт-лог?

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

для ваших объёмов вы можете спокойно делать full раз в сутки + log (15- 60 минут) и хранить эту вакаханалию на -7 дней(или как душа желает). Дифференциальный вам не ясно зачем
21 май 18, 16:59    [21426602]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Щукина Анна
Member

Откуда:
Сообщений: 1466
Serg58
Вооот! У вас очень просто и понятно написано, откуда вы цитируете если не секрет?
Это - вольный, адаптированный и упрощенный пересказ документации ;). Хотя, некоторые считают, что это всего лишь "охх сколько бессмысленного текста..." :)
21 май 18, 17:15    [21426665]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
Щукина Анна
...+ все промежуточные "разности" .... + накат разностных копий за неделю

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

В SQL Server есть только дифференциальные бэкапы, поэтому использовать необходимо один разностный бэкап - самый последний перед датой, на которую вы желаете восстановиться.
21 май 18, 18:24    [21426885]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Щукина Анна
Member

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

верное замечание... видимо, в голове "сварилась каша" из Oracle/PostgreSQL/MS SQL...
В целом, понятно, что общие стратегии и подходы - везде если не одинаковы, то схожи...
Нужно будет вспомнить СУБД-зависимые нюансы и разложить всё по полочкам... :)
21 май 18, 20:11    [21427053]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30712
TaPaK
для ваших объёмов вы можете спокойно делать full раз в сутки + log (15- 60 минут) и хранить эту вакаханалию на -7 дней(или как душа желает). Дифференциальный вам не ясно зачем
+1
Классический простой вариант, позволяет восстановить данные на любую секунду, прост в управлении.
Диффами многие заморачиваются, видимо, из за названия, а зря. Они сложнее, и неоптимальны по месту хранения.
Притом они не прощают ошибок - сделанным каким то внешним средством бакапом можно их запороть, и получить отсутствие бакапов в самый ответственный момент, причём узнать про это получится именно тогда.
21 май 18, 20:26    [21427080]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
alexeyvg
TaPaK
для ваших объёмов вы можете спокойно делать full раз в сутки + log (15- 60 минут) и хранить эту вакаханалию на -7 дней(или как душа желает). Дифференциальный вам не ясно зачем
+1
Классический простой вариант, позволяет восстановить данные на любую секунду, прост в управлении.
Диффами многие заморачиваются, видимо, из за названия, а зря. Они сложнее, и неоптимальны по месту хранения.
Притом они не прощают ошибок - сделанным каким то внешним средством бакапом можно их запороть, и получить отсутствие бакапов в самый ответственный момент, причём узнать про это получится именно тогда.


Таки позволю себе немного дополнить уважаемых коллег.

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

Перефразирую. Есть таблица 10 Гбайт с кластерным индексом (условно). На нее можно навесить 3 некластерных индекса еще по 5 Гбайт. Итого получаем вместо базы в 10 новый размер в 25 - в 2.5 раза больше предыдущего.

Подобрали железо такое, что бэкап делается 10 минут, а восстанавливаем из него базу в случае ее повреждения - 8 минут. База обслуживает учетную систему, в которую вносятся первичные документы (ну или продажи/заказы по интернет-магазину). И главный директор говорит так - "12 минут простоя мы можем себе позволить, а свыше 12 - уже нет. Некуда будет вбивать первичные документы или факты, а на бумаге записывать и потом в базу вбивать невозможно никак".

Отсюда вывод - делать бэкап 10 минут и разворачивать 8 минут можно. Делать 15 и разворачивать 12 минут - уже на грани фола. Поэтому один некластерный индекс в 5 Гб мы можем себе позволить и использовать его - а вот три индекса таки никак нельзя. Не соответствует целям ЗАКАЗЧИКА и по факту главного владельца и распорядителя всей этой базы.

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

Надеюсь, понятно разъяснил автору темы...
22 май 18, 00:32    [21427468]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36686
Andy_OLAP
И поэтому когда разработчики говорят "а вот бы еще парочку кошерных индексов создать, чтобы 99% тяжелых отчетов ускорить раз в 10" - DBA отвечает - "стоп, извините, делайте асинхронную реплику, обвешивайте ее индексами, а на первичную реплику/базу я больше ничего не дам создать".
Тема создания индексов только на вторичной асинхронной реплике (на основной-то DBA запрещает!) раскрыта не полностью.
22 май 18, 02:19    [21427494]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
aleksrov
Member

Откуда:
Сообщений: 948
Гавриленко Сергей Алексеевич
Andy_OLAP
И поэтому когда разработчики говорят "а вот бы еще парочку кошерных индексов создать, чтобы 99% тяжелых отчетов ускорить раз в 10" - DBA отвечает - "стоп, извините, делайте асинхронную реплику, обвешивайте ее индексами, а на первичную реплику/базу я больше ничего не дам создать".
Тема создания индексов только на вторичной асинхронной реплике (на основной-то DBA запрещает!) раскрыта не полностью.


Тема интересная. Берешь read-only реплику, навешиваешь на нее кучу индексов, все запросы на выборку направляешь туда, а на primary оставляешь одни кучи, ну или где надо добавляем класт. индекс и парочку обычных, чтоб update всю таблицу не сканил, и все, во красота та какая! :)
22 май 18, 07:05    [21427551]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
982183
Member

Откуда: VL
Сообщений: 3349
Есть другая практика - развернутая и проиндексированная "вчерашняя" база для формирования отчетов на втором сервере.
Дабы не мешать оперативному вводу, и не тормозить им отчетность.
22 май 18, 07:33    [21427579]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Serg58
Member

Откуда:
Сообщений: 65
Всем огромное спасибо за ответы, ссылки, рекомендации. Очень много почерпнул.

Вчера сделал на основную базу полное (fullscan) обновление статистики, выполнилась за 1ч40м.

Продолжаю расчищать базу данных, на это уйдёт ещё примерно 20 суток.

И на бекапы скорее всего перейдём ночью полностью, днём несколько раз бекап лога транзакций
22 май 18, 10:39    [21427983]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Гавриленко Сергей Алексеевич
Andy_OLAP
И поэтому когда разработчики говорят "а вот бы еще парочку кошерных индексов создать, чтобы 99% тяжелых отчетов ускорить раз в 10" - DBA отвечает - "стоп, извините, делайте асинхронную реплику, обвешивайте ее индексами, а на первичную реплику/базу я больше ничего не дам создать".
Тема создания индексов только на вторичной асинхронной реплике (на основной-то DBA запрещает!) раскрыта не полностью.

И я таки не стану эту тему раскрывать. Хотя бы потому, что процитировал злобного DBA, который хочет запугать наивных и глуповатых разработчиков.
Разумеется, термин "асинхронная реплика" никак не связан с AlwaysOn и прочими механизмами самого MSSQL.

Но поскольку Вы, Сережа, работаете в конторе довольно успешной и имеете под рукой таких же молодых и талантливых разработчиков - я Вам лично могу хороший рецепт дать.
Берете исходники MSSQL Server, смотрите механизм накатки журнала на вторичную реплику, пишете сетевой драйвер, который перехватывает и модифицирует пакеты с нужными транзакциями - типа на первичной отыграла insert 1 строка into ненужная таблица, подменили на вторичной create нужный индекс на нужной таблице, а далее delete 1 строка from ненужная таблица на drop нужный индекс на нужной таблице.

Если драйверы под Windows будет написать сложно - поставьте 2017-й на кошерную корпоративную сборку типа RedHat. Под Linux намного проще драйверы писать, API меняется относительно небыстро для нужного направления.
А мои гвардейцы проследят, чтобы при всем стратегическом союзе между красношапочными и микромягкими индусы из Редмонда не переходили в Роли и ничего не испортили.
22 май 18, 11:38    [21428221]     Ответить | Цитировать Сообщить модератору
 Re: подскажите по расчистке БД и последующему обслуживанию  [new]
aleksrov
Member

Откуда:
Сообщений: 948
Это он о чем вообще?
22 май 18, 11:47    [21428258]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить