none
Размер первого лога транзакций после полного резервного копирования. RRS feed

  • Вопрос

  • Доброго времени!

    Исходные данные. Запланоровано ночное обслуживание в следующей последовательности:

    1. DBCC CHECKDB для всех баз,
    2. Rebuild Index Task
    3. Update Statistics Task 
    4. DBCC FREEPROCCACHE
    5. Back Up Database Task - полный бэкап баз данных
    6. maintenаnce clenup для старых баз

    Это все дело завершаетя примерно в 4.00. C 6.00 до 23.00 каждые 30 минут запланоровано задание Back Up Database Task - копия журнала транзакций.

    Имеется такая проблема... Первая копия журнала транзакций имеет размер равный размеру полной копии базы данных.

    Поэтому есть пару вопросов:

    1. Почему такое происходит? На сколько я знаю, при полной копии базы создается CHECKPOINT и изменения из лога транзакций должны записаться в базу данных.

    2. Как избавиться от такого размера логов?

    Заранее спасибо!

     

    13 февраля 2012 г. 7:51

Ответы

  • Зачем Вам понадобилось так "издеваться" над сервером и данными?

    готов выслушать ваши рекомендации :)

    по факту вопроса:

    1. проверяем, целостность баз данных, если все цело - выполняем пункты 2-6, если нет - сообщаем админу о проблемах.
    2-6. Как уже сказал Eugene Lobanov - рекомендации 1С. Тем не менее, работоспособность с помощью данных заданий держится на должном уровне. Ну и бэкап выполняется довольно удобно без помех для работы пользователей, за исключением проблемы о которой спрашиваю. 


    Я тут как то помогал админам после падения производительности 1С.

    Читал рекомендации 1С. Смотрел на то что 1С генерирует.

    В зависимости от интенсивности работы с базой я бы обновлял

    Статистику по выходным и ребилд/реорганайз индексов в зависимости от их дефрагментации.

    Ну само собой бэкап в начале недели фулл, днем дифф или транзакшен лог (в зависимости от того как база быстро растет, какие объемы бэкапов, какое время доступно для рестора)

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

    сколько размер баз сейчас? и как быстро вырастает журнал транзакций?

    • Предложено в качестве ответа Naomi N 13 февраля 2012 г. 18:10
    • Помечено в качестве ответа Dmitry Davydov 15 февраля 2012 г. 14:13
    13 февраля 2012 г. 12:49
  • Я тут как то помогал админам после падения производительности 1С.

    Читал рекомендации 1С. Смотрел на то что 1С генерирует.

    В зависимости от интенсивности работы с базой я бы обновлял

    Статистику по выходным и ребилд/реорганайз индексов в зависимости от их дефрагментации.

    Ну само собой бэкап в начале недели фулл, днем дифф или транзакшен лог (в зависимости от того как база быстро растет, какие объемы бэкапов, какое время доступно для рестора)

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

    сколько размер баз сейчас? и как быстро вырастает журнал транзакций?

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

    Чек ДБ - как подстраховка перед ребилдом/реорганаизом, чтобы итак больную базу не порушить окончательно.

    Базы занимают не очень много 3 базы по 6 Гб и пару по 30 Гб. В сумме базы без логов не более 90 Гб. Лог у самой большой базы растет не более 20 Гб.

    вот как-то так.

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

    • Помечено в качестве ответа mc-sim 13 февраля 2012 г. 18:44
    13 февраля 2012 г. 13:28
  • Зачем Вам понадобилось так "издеваться" над сервером и данными?

    готов выслушать ваши рекомендации :)

    по факту вопроса:

    1. проверяем, целостность баз данных, если все цело - выполняем пункты 2-6, если нет - сообщаем админу о проблемах.
    2-6. Как уже сказал Eugene Lobanov - рекомендации 1С. Тем не менее, работоспособность с помощью данных заданий держится на должном уровне. Ну и бэкап выполняется довольно удобно без помех для работы пользователей, за исключением проблемы о которой спрашиваю. 


    Если Вы понимаете смысл прелагаемых 1С тасков, тогда нет смысла следовать этим рекомендациям, которые расчитаны на бухгалтера.
    • DBCC CHECKDB для всех баз - Лишнее действие, следите лучше за ошибками контрольных сумм. Делайте проверку реже, и в отдельном задании.
    • Rebuild Index Task - Пересоздавать нужно только те индексы, которые сильно фрагментированы.
    • Update Statistics Task - Обновляйте только ту статистику, которая устарела. Включите автоматическое обновление и -T2371.
    • DBCC FREEPROCCACHE - А это зачем?!
    • Back Up Database Task - полный бэкап баз данных - включайте сжатие копии, заведомо выигрышный во всех аспектах вариант.
    • maintenаnce clenup для старых баз - Лучше делайте до бэкапа, вдруг места не хватит...

    • Помечено в качестве ответа Dmitry Davydov 15 февраля 2012 г. 14:13
    15 февраля 2012 г. 9:40

Все ответы

  • Имеется такая проблема... Первая копия журнала транзакций имеет размер равный размеру полной копии базы данных.

    Скрипт создания бэкапа лога покажите

    http://www.t-sql.ru

    13 февраля 2012 г. 8:33
    Отвечающий
  • Ну для начала

    CHECKPOINT (Transact-SQL)

    Записывает все «грязные» страницы в текущей базе данных на диск. «Грязными» страницами являются страницы данных, введенные в буферный кэш и измененные, но еще не записанные на диск.

    Under the full recovery model or bulk-logged recovery model, the inactive part of the log cannot be truncated until all its log records have been captured in a log backup. This is needed to maintain the log chain—a series of log records having an unbroken sequence of log sequence numbers (LSNs). The log is truncated when you back up the transaction log, assuming the following conditions exist:

    • A checkpoint has occurred since the log was last backed up. A checkpoint is essential but not sufficient for truncating the log under the full recovery model or bulk-logged recovery model. After a checkpoint, the log remains intact at least until the next transaction log backup.

      For more information, see Checkpoints and the Active Portion of the Log.

    • No other factor is preventing log transaction.

      Generally, with regular backups, log space is regularly freed for future use. However, various factors, such as a long-running transaction, can temporarily prevent log truncation. For more information, see Factors That Can Delay Log Truncation.

    • The BACKUP LOG statement does not specify WITH COPY_ONLY.

    Собственно почему логу транзакций быть маленьким? Первый раз ты бэкапишь лог что накопился с 23 00. Возможно после ребилда лог вырастает.

    Видимо надо пересмотреть стратегию бэкапирования.

    13 февраля 2012 г. 8:44
    1. DBCC CHECKDB для всех баз,
    2. Rebuild Index Task
    3. Update Statistics Task 
    4. DBCC FREEPROCCACHE
    5. Back Up Database Task - полный бэкап баз данных
    6. maintenаnce clenup для старых баз
     

    Зачем Вам понадобилось так "издеваться" над сервером и данными?
    13 февраля 2012 г. 9:10
    1. DBCC CHECKDB для всех баз,
    2. Rebuild Index Task
    3. Update Statistics Task 
    4. DBCC FREEPROCCACHE
    5. Back Up Database Task - полный бэкап баз данных
    6. maintenаnce clenup для старых баз
     

    Зачем Вам понадобилось так "издеваться" над сервером и данными?

    1C рекомендации?
    13 февраля 2012 г. 9:30
  • Всем спасибо за ответы.

    Скрипт создания бэкапа лога покажите

    Показываю скрипт создания копии лога:

    EXECUTE master.dbo.xp_create_subdir N'\\files\backup$\Transact\sag8_bp_2011'
    GO
    EXECUTE master.dbo.xp_create_subdir N'\\files\backup$\Transact\sag8_bp_comp_dt'
    GO
    EXECUTE master.dbo.xp_create_subdir N'\\files\backup$\Transact\sag8_bp_dt'
    GO
    EXECUTE master.dbo.xp_create_subdir N'\\files\backup$\Transact\sag8_zup_dt'
    GO
    EXECUTE master.dbo.xp_create_subdir N'\\files\backup$\Transact\sag82-dt'
    GO
    BACKUP LOG [sag8_bp_2011] TO  DISK = N'\\files\backup$\Transact\sag8_bp_2011\sag8_bp_2011_backup_201202131316.trn' WITH NOFORMAT, NOINIT,  NAME = N'sag8_bp_2011_backup_20120213131624', SKIP, REWIND, NOUNLOAD,  STATS = 10
    GO
    BACKUP LOG [sag8_bp_comp_dt] TO  DISK = N'\\files\backup$\Transact\sag8_bp_comp_dt\sag8_bp_comp_dt_backup_201202131316.trn' WITH NOFORMAT, NOINIT,  NAME = N'sag8_bp_comp_dt_backup_20120213131624', SKIP, REWIND, NOUNLOAD,  STATS = 10
    GO
    BACKUP LOG [sag8_bp_dt] TO  DISK = N'\\files\backup$\Transact\sag8_bp_dt\sag8_bp_dt_backup_201202131316.trn' WITH NOFORMAT, NOINIT,  NAME = N'sag8_bp_dt_backup_20120213131624', SKIP, REWIND, NOUNLOAD,  STATS = 10
    GO
    BACKUP LOG [sag8_zup_dt] TO  DISK = N'\\files\backup$\Transact\sag8_zup_dt\sag8_zup_dt_backup_201202131316.trn' WITH NOFORMAT, NOINIT,  NAME = N'sag8_zup_dt_backup_20120213131624', SKIP, REWIND, NOUNLOAD,  STATS = 10
    GO
    BACKUP LOG [sag82-dt] TO  DISK = N'\\files\backup$\Transact\sag82-dt\sag82-dt_backup_201202131316.trn' WITH NOFORMAT, NOINIT,  NAME = N'sag82-dt_backup_20120213131624', SKIP, REWIND, NOUNLOAD,  STATS = 10

    13 февраля 2012 г. 9:39
  • Именно этот абзац мне трудно поддавался к пониманию :)

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

    A checkpoint has occurred since the log was last backed up. A checkpoint is essential but not sufficient for truncating the log under the full recovery model or bulk-logged recovery model. After a checkpoint, the log remains intact at least until the next transaction log backup.

    For more information, see Checkpoints and the Active Portion of the Log.

  • No other factor is preventing log transaction.

    Generally, with regular backups, log space is regularly freed for future use. However, various factors, such as a long-running transaction, can temporarily prevent log truncation. For more information, seeFactors That Can Delay Log Truncation.

  • The BACKUP LOG statement does not specify WITH COPY_ONLY.

  • правильно?
    13 февраля 2012 г. 9:46
  • 1C рекомендации?


    в точку :)
    13 февраля 2012 г. 9:49
  • Зачем Вам понадобилось так "издеваться" над сервером и данными?

    готов выслушать ваши рекомендации :)

    по факту вопроса:

    1. проверяем, целостность баз данных, если все цело - выполняем пункты 2-6, если нет - сообщаем админу о проблемах.
    2-6. Как уже сказал Eugene Lobanov - рекомендации 1С. Тем не менее, работоспособность с помощью данных заданий держится на должном уровне. Ну и бэкап выполняется довольно удобно без помех для работы пользователей, за исключением проблемы о которой спрашиваю. 


    • Изменено mc-sim 13 февраля 2012 г. 9:53
    13 февраля 2012 г. 9:53
  • Показываю скрипт создания копии лога:

    Почему у вас в скрипте NOINIT !?


    http://www.t-sql.ru

    13 февраля 2012 г. 10:07
    Отвечающий
  • Почему у вас в скрипте NOINIT !?

    Видимно, потому что задание создавалось через Management Studio, а там это значение по умолчанию.

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

    имя_базы_backup_метка_веремени.trn

    13 февраля 2012 г. 10:17
  • Зачем Вам понадобилось так "издеваться" над сервером и данными?

    готов выслушать ваши рекомендации :)

    по факту вопроса:

    1. проверяем, целостность баз данных, если все цело - выполняем пункты 2-6, если нет - сообщаем админу о проблемах.
    2-6. Как уже сказал Eugene Lobanov - рекомендации 1С. Тем не менее, работоспособность с помощью данных заданий держится на должном уровне. Ну и бэкап выполняется довольно удобно без помех для работы пользователей, за исключением проблемы о которой спрашиваю. 


    Я тут как то помогал админам после падения производительности 1С.

    Читал рекомендации 1С. Смотрел на то что 1С генерирует.

    В зависимости от интенсивности работы с базой я бы обновлял

    Статистику по выходным и ребилд/реорганайз индексов в зависимости от их дефрагментации.

    Ну само собой бэкап в начале недели фулл, днем дифф или транзакшен лог (в зависимости от того как база быстро растет, какие объемы бэкапов, какое время доступно для рестора)

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

    сколько размер баз сейчас? и как быстро вырастает журнал транзакций?

    • Предложено в качестве ответа Naomi N 13 февраля 2012 г. 18:10
    • Помечено в качестве ответа Dmitry Davydov 15 февраля 2012 г. 14:13
    13 февраля 2012 г. 12:49
  • Я тут как то помогал админам после падения производительности 1С.

    Читал рекомендации 1С. Смотрел на то что 1С генерирует.

    В зависимости от интенсивности работы с базой я бы обновлял

    Статистику по выходным и ребилд/реорганайз индексов в зависимости от их дефрагментации.

    Ну само собой бэкап в начале недели фулл, днем дифф или транзакшен лог (в зависимости от того как база быстро растет, какие объемы бэкапов, какое время доступно для рестора)

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

    сколько размер баз сейчас? и как быстро вырастает журнал транзакций?

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

    Чек ДБ - как подстраховка перед ребилдом/реорганаизом, чтобы итак больную базу не порушить окончательно.

    Базы занимают не очень много 3 базы по 6 Гб и пару по 30 Гб. В сумме базы без логов не более 90 Гб. Лог у самой большой базы растет не более 20 Гб.

    вот как-то так.

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

    • Помечено в качестве ответа mc-sim 13 февраля 2012 г. 18:44
    13 февраля 2012 г. 13:28
  • Зачем Вам понадобилось так "издеваться" над сервером и данными?

    готов выслушать ваши рекомендации :)

    по факту вопроса:

    1. проверяем, целостность баз данных, если все цело - выполняем пункты 2-6, если нет - сообщаем админу о проблемах.
    2-6. Как уже сказал Eugene Lobanov - рекомендации 1С. Тем не менее, работоспособность с помощью данных заданий держится на должном уровне. Ну и бэкап выполняется довольно удобно без помех для работы пользователей, за исключением проблемы о которой спрашиваю. 


    Если Вы понимаете смысл прелагаемых 1С тасков, тогда нет смысла следовать этим рекомендациям, которые расчитаны на бухгалтера.
    • DBCC CHECKDB для всех баз - Лишнее действие, следите лучше за ошибками контрольных сумм. Делайте проверку реже, и в отдельном задании.
    • Rebuild Index Task - Пересоздавать нужно только те индексы, которые сильно фрагментированы.
    • Update Statistics Task - Обновляйте только ту статистику, которая устарела. Включите автоматическое обновление и -T2371.
    • DBCC FREEPROCCACHE - А это зачем?!
    • Back Up Database Task - полный бэкап баз данных - включайте сжатие копии, заведомо выигрышный во всех аспектах вариант.
    • maintenаnce clenup для старых баз - Лучше делайте до бэкапа, вдруг места не хватит...

    • Помечено в качестве ответа Dmitry Davydov 15 февраля 2012 г. 14:13
    15 февраля 2012 г. 9:40
  • Зачем Вам понадобилось так "издеваться" над сервером и данными?

    готов выслушать ваши рекомендации :)

    по факту вопроса:

    1. проверяем, целостность баз данных, если все цело - выполняем пункты 2-6, если нет - сообщаем админу о проблемах.
    2-6. Как уже сказал Eugene Lobanov - рекомендации 1С. Тем не менее, работоспособность с помощью данных заданий держится на должном уровне. Ну и бэкап выполняется довольно удобно без помех для работы пользователей, за исключением проблемы о которой спрашиваю. 


    Если Вы понимаете смысл прелагаемых 1С тасков, тогда нет смысла следовать этим рекомендациям, которые расчитаны на бухгалтера.
    • DBCC CHECKDB для всех баз - Лишнее действие, следите лучше за ошибками контрольных сумм. Делайте проверку реже, и в отдельном задании.
    • Rebuild Index Task - Пересоздавать нужно только те индексы, которые сильно фрагментированы.
    • Update Statistics Task - Обновляйте только ту статистику, которая устарела. Включите автоматическое обновление и -T2371.
    • DBCC FREEPROCCACHE - А это зачем?!
    • Back Up Database Task - полный бэкап баз данных - включайте сжатие копии, заведомо выигрышный во всех аспектах вариант.
    • maintenаnce clenup для старых баз - Лучше делайте до бэкапа, вдруг места не хватит...

    Тема уже долгое время не активна, но надеюсь увидят мой пост :)

    Александр, рекомендации 1С по обслуживанию базы вот здесь: http://1cexpo.ru/instrukczii/22-reglamentnye-operaczii-na-urovne-subd-dlya-ms-sql-server.html

    А вот по твоим рекомендациям хотелось бы дополнительные комментарии специалиста (для неспециалистов :) ):  

    • Rebuild Index Task - Пересоздавать нужно только те индексы, которые сильно фрагментированы.
    • Update Statistics Task - Обновляйте только ту статистику, которая устарела. Включите автоматическое обновление и -T2371.

    Где можно почитать про то как эффективно определять фрагментированные индексы и устаревшую статистику ? Дело в том, что стурктура таблиц базы 1С УПП наверное до конца известна только самим парням из 1С. Более того, 1С в лицензионном соглашении, запрещает не1Сными средствами лезть в свои базы.


    Andy Mishechkin

    3 сентября 2012 г. 6:53
  • По ссылке чётко сказано, что даны ПРИМЕРЫ настройки плана обслуживания. Эти примеры упрощены донельзя... В таком виде применять их не рекомендую, тем более, без явных причин для подобного обслуживания. Тот же процедурный кэш может понадобиться чистить только, например, при завершении отчётного периода. В обычных условиях стстистика при автообновлении должна быть свежей (не забудьте включить указанный флаг).

    Если индексы быстро фрагментируются (как это видеть подробно в BOL), попробуйте уменьшить процент заполнения страниц. В интеренете есть примеры сценариев, которые по текущим метаданным отбирают индексы для пересоздания или реорганизации, например: http://ola.hallengren.com/

    Ни одна из перечисленных мной операций не меняет схему даных и набор созданных объектов.

    3 сентября 2012 г. 8:26
  • В итоге, вот что у меня родилось в качестве решения:

    1. Настройка Microsoft SQL Server для 1С Предприятие (Maintenance Plans)

    2. Настройка Database Mail в MS SQL 2005 для уведомления об ошибках

    Вроде все работает без проблем )

    База почти 60Гб. и куча мелких по 2-10 Гб

    3 сентября 2012 г. 12:20
  • В итоге, вот что у меня родилось в качестве решения:

    1. Настройка Microsoft SQL Server для 1С Предприятие (Maintenance Plans)

    2. Настройка Database Mail в MS SQL 2005 для уведомления об ошибках

    Вроде все работает без проблем )

    База почти 60Гб. и куча мелких по 2-10 Гб

    Кому то ваши рекомендации могут подойти, у кого то это станет источником бесконечных проблем, а для кого то это станет катастрофой... Подумайте о том, что бы перевести статью в категорию очень упрощённых рекомендаций.

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

    За много лет администрирования я усвоил две вещи - нельзя быть уверенным в применимости чужого алгоритма, и нельзя браться за поддержку 1С :)))

    3 сентября 2012 г. 12:28