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

Откуда: AB
Сообщений: 7673
Проблема такая. Есть база, размером 2.3ГБ в "Simple Recovery". Ночью делается бекап "Database Differential". Размер бекапа 24.46ГБ!!! При этом лог трансакций расширяется до 53ГБ, происходит за ~40 минут. Да, бекап делается Semantic BackupExec, виндовым администратором, кооторый про сиквел знает "0". Что это могло бы быть? Незавершенные транзакции?
27 янв 15, 19:17    [17178950]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Вы предлагаете угадать, что делает ваш виндовый администратор посредством Semantic BackupExec с вашей базой?
27 янв 15, 19:22    [17178971]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
komrad
Member

Откуда:
Сообщений: 5919
Relic Hunter
Проблема такая. Есть база, размером 2.3ГБ в "Simple Recovery". Ночью делается бекап "Database Differential". Размер бекапа 24.46ГБ!!!


ну а полный бекап-то когда делался?

https://technet.microsoft.com/en-us/library/ms181092(v=sql.105).aspx
A differential database backup records only the data that has changed since the last full database backup.
...
To save time and disk space, you can follow a full database backup with a series of differential backups. Each successive differential database backup is larger than its predecessor, requiring more backup time, space, and restore time. Therefore, we recommend that you take a new full backup at an appropriate interval to provide a new differential base.
27 янв 15, 19:30    [17178986]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7673
komrad
ну а полный бекап-то когда делался?
Вот...

К сообщению приложен файл. Размер - 92Kb
27 янв 15, 19:43    [17179039]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7673
Гавриленко Сергей Алексеевич
Вы предлагаете угадать, что делает ваш виндовый администратор посредством Semantic BackupExec с вашей базой?
Ежеднево - "diff", еженедельно "full" бекап.
27 янв 15, 19:48    [17179053]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7673
Как дифференциальный бекап может быть в 10 раз больше базы - 24.46ГБ, а полный - в 4 раза меньше, всего 500МБ?
27 янв 15, 19:50    [17179065]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Есть база, размером 2.3ГБ в "Simple Recovery".
При этом лог трансакций расширяется до 53ГБ, происходит за ~40 минут.

Получается, что у Вас на базе не слабые активности идут в плане длительности и количества транзакций в это время.
27 янв 15, 20:23    [17179159]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7673
Павел-П
Есть база, размером 2.3ГБ в "Simple Recovery".
При этом лог трансакций расширяется до 53ГБ, происходит за ~40 минут.

Получается, что у Вас на базе не слабые активности идут в плане длительности и количества транзакций в это время.
Там есть два мейтененс-джоба (индексы, статистика). Но они по времени не совпадают, оба - после полуночи, а бекап завершен "до", это ясно видно из отчета. Другого ничего ночью не происходит.
27 янв 15, 20:32    [17179175]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Glory
Member

Откуда:
Сообщений: 104751
Relic Hunter
Что это могло бы быть? Незавершенные транзакции?

Зачем незавершенные ?
Просто запустил кто-то полную дефрагментацию/перестройку всех индексов, например
27 янв 15, 20:32    [17179176]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7673
Glory
Зачем незавершенные ?
Просто запустил кто-то полную дефрагментацию/перестройку всех индексов, например
А это, что не транзакции?
27 янв 15, 20:41    [17179203]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Glory
Member

Откуда:
Сообщений: 104751
Relic Hunter
Glory
Зачем незавершенные ?
Просто запустил кто-то полную дефрагментацию/перестройку всех индексов, например
А это, что не транзакции?

А она что незавершенная ?
27 янв 15, 20:42    [17179210]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32173
Relic Hunter
Как дифференциальный бекап может быть в 10 раз больше базы - 24.46ГБ, а полный - в 4 раза меньше, всего 500МБ?
Непонятно, что происходило с базой в промежутке. Может, были активности, база выросла, а потом её шринканули? И бакап делался как раз перед шринком?

Самый простой способ выяснить - восстановить этот дифф бакап.

Как я понимаю механизм дифф бакапа, содержимое лога не может повлиять на размер полного или дифф. бакапа, так что действительно, парадокс.
28 янв 15, 01:16    [17180152]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7673
alexeyvg,

Размер дата-файла стабильный. Если-бы были у него "shrink"/"grow" когда-либо, это-бы легко было-бы увидеть в отчете "Disk Usage", Autogrow/Autoshrink Events.
28 янв 15, 01:30    [17180175]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7673
Я с MSSQL интерналс не очень знаком, то так понимаю, когда идет "живой" бекап, дата-файл "замораживается" и все изменения БД пишутся в лог, а использованные страницы дата-файла копируются в бекап. Потом в этот-же бекап "доливаются" необходимые страницы из лога, необходимые для рекавери. Если лог был 54ГБ, то, в общем-то, не удивительно, что бекап получился в 24ГБ.
28 янв 15, 01:38    [17180194]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32173
Relic Hunter
Я с MSSQL интерналс не очень знаком, то так понимаю, когда идет "живой" бекап, дата-файл "замораживается" и все изменения БД пишутся в лог, а использованные страницы дата-файла копируются в бекап. Потом в этот-же бекап "доливаются" необходимые страницы из лога, необходимые для рекавери. Если лог был 54ГБ, то, в общем-то, не удивительно, что бекап получился в 24ГБ.
А, если бакап делался, пока данные ещё не были зачекпойтены в файл данных? Ну да, наверное, тогда из лога дерёт...

Да восстановите его и посмотрите, что получится. А то будут потом неожиданности.
28 янв 15, 01:41    [17180201]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7673
alexeyvg,

Дык востанавливали и не раз. На выходе получали маленький дата-файл в 2ГБ и "офигенный" лог в 10-ки ГБ. И рекавери шло часами. Поэтому решили с этим разобраться.
28 янв 15, 01:45    [17180208]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
o-o
Guest
alexeyvg
Как я понимаю механизм дифф бакапа, содержимое лога не может повлиять на размер полного или дифф. бакапа

очень даже может.
потому что пока бэкапите, бэкап захватывает все, что может.
и если он захватит страницы с данными, к-ые еще не закоммичены к концу бэкапа* (за подробностями по ссылке. там не совсем "конец бэкапа"),
то все это надо отменять. по записям лога, к-ые включаются в бэкап

Myth 1: A full database backup only contains the transaction log from the start of the backup to the end of the backup
---
а по теме топика еще такое:
раз модель простая, то по идее ребилд индексов минимально логируется.
только на деле, если одновременно идет бэкап, то то ли он все начинает полно логировать
(видели в БОЛ фразу:
Minimal logging involves logging only the information that is required to recover the transaction without supporting point-in-time recovery. This topic identifies the operations that are minimally logged under the bulk-logged recovery model (as well as under the simple recovery model, except when a backup is running).
?
Operations That Can Be Minimally Logged)
то ли это все потому, что при минимальном логировании все измененные страницы данных обязаны лечь на диск до коммита
(именно сами данные, а не только записи лога)
но в общем и лог растет, и время увеличивается, и размер бэкапа увеличивается

завтра если время будет, посмотрю, чего это он лишнее в лог валит и отчитаюсь
---
по мне, так искать надо, что они там еще в базе ночью делают.
время "огромных" бэкапов на картинке -- неизменные 11:35 ночи.
ну повесьте DDL-триггер на базу на одну ночь хотя бы, узнаете, кто там что еще делает
28 янв 15, 01:52    [17180223]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
o-o
Guest
alexeyvg
Relic Hunter
Я с MSSQL интерналс не очень знаком, то так понимаю, когда идет "живой" бекап, дата-файл "замораживается" и все изменения БД пишутся в лог, а использованные страницы дата-файла копируются в бекап. Потом в этот-же бекап "доливаются" необходимые страницы из лога, необходимые для рекавери. Если лог был 54ГБ, то, в общем-то, не удивительно, что бекап получился в 24ГБ.
А, если бакап делался, пока данные ещё не были зачекпойтены в файл данных?

не замораживается в базе ничего,
а первое, что делает полный бэкап, так это именно чекпойнт.
и именно для того, чтобы как можно больше сразу на диск записалось, чтобы захватить побыстрее,
а то же еще навалят
28 янв 15, 01:58    [17180228]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7673
o-o
по мне, так искать надо, что они там еще в базе ночью делают.
время "огромных" бэкапов на картинке -- неизменные 11:35 ночи.
ну повесьте DDL-триггер на базу на одну ночь хотя бы, узнаете, кто там что еще делает
Да не происходит в базе ничего в это время. Диффиренциальный бекап запускается в 10:30 до 11:30, и идет около часа. В это самое время растет лог (это видно из отчета "Disk Usage", Autogrow/Autoshrink Events). Но мы с вами знаем, что диффиренциальный бекап - на самом деле кумулятивный, а не инкрементальный, т.е. все изменения страниц с момента полного дописываются в его конец. И если полный делается 1 раз в неделю, то последний диффиренциальный ежедневный бекап будет включать шесть полных бекапов, если все страницы поменялись полностью (экстремальный сценарий). Ночью происходит только "Maintenance (index rebuild, update statistics)", который может приводить к массированному изненению страниц дата-файла (не лога). И тут уже не суть важно, когда это происходит, все измененные страницы должны быть дописаны в диффиренциальный бекап, что провоцирует его рост. Тут вопрос в другом: само создание диффиренциального бекапа провоцирует рост лога, это очевидно. Почему? Видимо сам SQL SERVER как-то использует лог для этой процедуры.
28 янв 15, 02:22    [17180254]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7673
В Оракле при дифеференциальном бекапе можно указать его LEVEL 0,1,2. T.e. будут архивироваться изменения страниц относительно предыдущего уровня. В сиквеле - дифеференциальный бекап всегда LEVEL 0, неосилили еще. Непонятно, зачем оно вообще нужно.
28 янв 15, 02:29    [17180258]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Relic Hunter
o-o
по мне, так искать надо, что они там еще в базе ночью делают.
время "огромных" бэкапов на картинке -- неизменные 11:35 ночи.
ну повесьте DDL-триггер на базу на одну ночь хотя бы, узнаете, кто там что еще делает
Да не происходит в базе ничего в это время. Диффиренциальный бекап запускается в 10:30 до 11:30, и идет около часа. В это самое время растет лог (это видно из отчета "Disk Usage", Autogrow/Autoshrink Events). Но мы с вами знаем, что диффиренциальный бекап - на самом деле кумулятивный, а не инкрементальный, т.е. все изменения страниц с момента полного дописываются в его конец. И если полный делается 1 раз в неделю, то последний диффиренциальный ежедневный бекап будет включать шесть полных бекапов, если все страницы поменялись полностью (экстремальный сценарий). Ночью происходит только "Maintenance (index rebuild, update statistics)", который может приводить к массированному изненению страниц дата-файла (не лога). И тут уже не суть важно, когда это происходит, все измененные страницы должны быть дописаны в диффиренциальный бекап, что провоцирует его рост. Тут вопрос в другом: само создание диффиренциального бекапа провоцирует рост лога, это очевидно. Почему? Видимо сам SQL SERVER как-то использует лог для этой процедуры.
Феерический бред почти в каждом предложении.
28 янв 15, 02:47    [17180266]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7673
Гавриленко Сергей Алексеевич
Relic Hunter
пропущено...
Да не происходит в базе ничего в это время. Диффиренциальный бекап запускается в 10:30 до 11:30, и идет около часа. В это самое время растет лог (это видно из отчета "Disk Usage", Autogrow/Autoshrink Events). Но мы с вами знаем, что диффиренциальный бекап - на самом деле кумулятивный, а не инкрементальный, т.е. все изменения страниц с момента полного дописываются в его конец. И если полный делается 1 раз в неделю, то последний диффиренциальный ежедневный бекап будет включать шесть полных бекапов, если все страницы поменялись полностью (экстремальный сценарий). Ночью происходит только "Maintenance (index rebuild, update statistics)", который может приводить к массированному изненению страниц дата-файла (не лога). И тут уже не суть важно, когда это происходит, все измененные страницы должны быть дописаны в диффиренциальный бекап, что провоцирует его рост. Тут вопрос в другом: само создание диффиренциального бекапа провоцирует рост лога, это очевидно. Почему? Видимо сам SQL SERVER как-то использует лог для этой процедуры.
Феерический бред почти в каждом предложении.
Слова "почти к каждом предложении" исключает только ваше?
28 янв 15, 03:08    [17180277]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
invm
Member

Откуда: Москва
Сообщений: 9913
Relic Hunter
Дык востанавливали и не раз. На выходе получали маленький дата-файл в 2ГБ и "офигенный" лог в 10-ки ГБ. И рекавери шло часами. Поэтому решили с этим разобраться.
Relic Hunter
Да не происходит в базе ничего в это время. Диффиренциальный бекап запускается в 10:30 до 11:30, и идет около часа. В это самое время растет лог
Relic Hunter
И если полный делается 1 раз в неделю, то последний диффиренциальный ежедневный бекап будет включать шесть полных бекапов, если все страницы поменялись полностью

1. Дифф. бекап не может содержать больше страниц, чем в файлах данных. И не важно, когда был сделан полный бекап.
2. Бекап не может провоцировать рост журнала транзакций.
3. Дифф. бекап, как и полный, содержит активную часть журнала транзакций.
4. В нормальных условиях дифф. бекап БД в 2ГБ не должен длится около часа.

Чтобы убедиться в вышеперечисленном, достаточно сделать бекап штатными средствами.
А убедившись, отказаться от заклинания "не происходит в базе ничего в это время" и начать разбираться что же на самом делает с БД ваш BackupExec или еще кто.
28 янв 15, 06:41    [17180398]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Relic Hunter
o-o
по мне, так искать надо, что они там еще в базе ночью делают.
время "огромных" бэкапов на картинке -- неизменные 11:35 ночи.
ну повесьте DDL-триггер на базу на одну ночь хотя бы, узнаете, кто там что еще делает
Да не происходит в базе ничего в это время. Диффиренциальный бекап запускается в 10:30 до 11:30, и идет около часа. В это самое время растет лог (это видно из отчета "Disk Usage", Autogrow/Autoshrink Events). Но мы с вами знаем, что диффиренциальный бекап - на самом деле кумулятивный, а не инкрементальный, т.е. все изменения страниц с момента полного дописываются в его конец. И если полный делается 1 раз в неделю, то последний диффиренциальный ежедневный бекап будет включать шесть полных бекапов, если все страницы поменялись полностью (экстремальный сценарий). Ночью происходит только "Maintenance (index rebuild, update statistics)", который может приводить к массированному изненению страниц дата-файла (не лога). И тут уже не суть важно, когда это происходит, все измененные страницы должны быть дописаны в диффиренциальный бекап, что провоцирует его рост. Тут вопрос в другом: само создание диффиренциального бекапа провоцирует рост лога, это очевидно. Почему? Видимо сам SQL SERVER как-то использует лог для этой процедуры.


ну если все так очевидно как Вы говорите, то воспроизведите это поведение на какой-нибудь обычной созданной БД.
Приложите скрипты создания и воспроизведения и я думаю сообщество будет с Вами это все разгребать.
28 янв 15, 10:44    [17181124]     Ответить | Цитировать Сообщить модератору
 Re: Backup Database Differential?  [new]
человек_ниоткуда
Guest
Semantec BackupExec, насколько я понял, (я с SBE и одним тупоголовым и одним нормальным его админом сталкивался), делает fracture при full/diff бекапе. Проще говоря, он блокирует запись в файл данных (есть такие API), и копирует своими средствами в себя содержимое файла данных. Лог, при этом, будет расти, только если в БД, в этот момент, что-то делают. Включите трассировку или extended event session на ночь и посмотрите какие запросы в базу приходили.

invm вам правильно написал про бекап, а вы какую-то несуразицу написали, поверьте.
Добавлю, к тому что invm написал, что каждая страница данных в БД, содержит метку изменялась-ли она после последнего full бекапа, по этой метке diff определяет, надо-ли эту страницу в бекап поместить.
28 янв 15, 10:45    [17181137]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить