Просьба помочь разобраться в основных моментах sql
Всем привет!
Сразу извиняюсь за глупые вопросы:) не доводилсь ранее(как ни странно) работать с sql+1c сразу скажу-гуглил=) но есть нюансы, ответы на которые могу получить только задав вопрос.
из-за чего возник вопрос:
раздувшийся журнал транзакций
Что есть:
sql2008 r2 express
несколько баз с похожими настройками: резерв на базу-5 гигов, резерв на лог 40 гигов. у всего включены возможности расширения.
все базы с полным методом восстановления(его собираюсь оставить)
настроен бэкап 6 дней дифференциально, на 7 день-полное. бэки перезаписываются.
мысли по автоматизации:
1. сделать единоразовый бэкап журналов
2. сделать шринк с реорганизацией на 10 гигов под лог транзакций.
3. оставить бэкап баз как есть
4. настроить бэкап транзакций раз в неделю с усечением(верно понимаю, что делается бэкап, потом удаление закрытых записей\действий до момента бэкапа?)
мучающие вопросы:
1. не наживу ли гемора с восстановлением при такой схеме?
2. я верно понимаю, что чтобы вернуться абсолютно на любое(естественно при условии полной схемы восстановления) состояние\время как раз и нужен лог транзакций, а бэкап бд только по состоянию на определенное время? то есть если что, бэкап бд может жить обособленно без этого журнала?
3. как правильно сделать единоразовый бэкап этих тяжелых логов, чтобы убрать их с сервака на первые полгода, чтобы потом от них избавиться со спокойной душой?=)
4. свежая мысль-не горожу ли огород:
за год не было необходимости восстановления на любое состояние. может тогда мне просто сделать бэкап этих больших логов, вынести их с сервера, сделать шринк с реорганизацией на 10 гигов и запретить расширение-пусть перезаписываются?
5. может я плохо умею пользоваться гуглом?))
В омут с головой в новый для себя вопрос, дайте советов пожалуйста)
Спасибо!
Сразу извиняюсь за глупые вопросы:) не доводилсь ранее(как ни странно) работать с sql+1c сразу скажу-гуглил=) но есть нюансы, ответы на которые могу получить только задав вопрос.
из-за чего возник вопрос:
раздувшийся журнал транзакций
Что есть:
sql2008 r2 express
несколько баз с похожими настройками: резерв на базу-5 гигов, резерв на лог 40 гигов. у всего включены возможности расширения.
все базы с полным методом восстановления(его собираюсь оставить)
настроен бэкап 6 дней дифференциально, на 7 день-полное. бэки перезаписываются.
мысли по автоматизации:
1. сделать единоразовый бэкап журналов
2. сделать шринк с реорганизацией на 10 гигов под лог транзакций.
3. оставить бэкап баз как есть
4. настроить бэкап транзакций раз в неделю с усечением(верно понимаю, что делается бэкап, потом удаление закрытых записей\действий до момента бэкапа?)
мучающие вопросы:
1. не наживу ли гемора с восстановлением при такой схеме?
2. я верно понимаю, что чтобы вернуться абсолютно на любое(естественно при условии полной схемы восстановления) состояние\время как раз и нужен лог транзакций, а бэкап бд только по состоянию на определенное время? то есть если что, бэкап бд может жить обособленно без этого журнала?
3. как правильно сделать единоразовый бэкап этих тяжелых логов, чтобы убрать их с сервака на первые полгода, чтобы потом от них избавиться со спокойной душой?=)
4. свежая мысль-не горожу ли огород:
за год не было необходимости восстановления на любое состояние. может тогда мне просто сделать бэкап этих больших логов, вынести их с сервера, сделать шринк с реорганизацией на 10 гигов и запретить расширение-пусть перезаписываются?
5. может я плохо умею пользоваться гуглом?))
В омут с головой в новый для себя вопрос, дайте советов пожалуйста)
Спасибо!
По теме из базы знаний
Найденные решения
(0) Все не читал, но добавлю от себя:
1) оставить полную схему восстановления (full)
2) если полный бэкап занимает приемлемое время и место, то отключить дифференциальные бэкапы, оставить ежесуточные полные (которые являются полностью самодостаточной штукой).
3) бэкап журнала транзакций - каждый час. Их можно делать чем чаще, тем лучше, они не накопительные. При этом они помечают забэкапленные транзакции в журнале как удаленные (т.е. при "ровной" работе журнал не растет). При этом с полного бэкапа можно восстановится на любой момент в пределах сделанных бэкапов журнала (но нужны все бэкапы журнала с момента полного бэкапа).
Шринки базы и журнала на регулярной основе делать как правило нет смысла.
Только если есть конкретная проблема с размерами базы или журнала, имеет смысл проанализировать распределение места и прикинуть, имеет ли смысл тот или иной шринк. При этом иметь в виду, что шринк с дефолтными настройками освобождает только "хвост" (что редко "лечит"), а шринк с реорганизацией базы - очень затратная операция.
4) если потеря данных дня не смертельна для организации, то можно забить на любые бэкапы кроме полных и включить схему восстановления simple (в этом случае журнал транзакций будет чиститься автоматически, а не бэкапами журнала). Если база не слишком большая, то можно даже дважды в день полный бэкап делать.
1) оставить полную схему восстановления (full)
2) если полный бэкап занимает приемлемое время и место, то отключить дифференциальные бэкапы, оставить ежесуточные полные (которые являются полностью самодостаточной штукой).
3) бэкап журнала транзакций - каждый час. Их можно делать чем чаще, тем лучше, они не накопительные. При этом они помечают забэкапленные транзакции в журнале как удаленные (т.е. при "ровной" работе журнал не растет). При этом с полного бэкапа можно восстановится на любой момент в пределах сделанных бэкапов журнала (но нужны все бэкапы журнала с момента полного бэкапа).
Шринки базы и журнала на регулярной основе делать как правило нет смысла.
Только если есть конкретная проблема с размерами базы или журнала, имеет смысл проанализировать распределение места и прикинуть, имеет ли смысл тот или иной шринк. При этом иметь в виду, что шринк с дефолтными настройками освобождает только "хвост" (что редко "лечит"), а шринк с реорганизацией базы - очень затратная операция.
4) если потеря данных дня не смертельна для организации, то можно забить на любые бэкапы кроме полных и включить схему восстановления simple (в этом случае журнал транзакций будет чиститься автоматически, а не бэкапами журнала). Если база не слишком большая, то можно даже дважды в день полный бэкап делать.
(31) Так я писал вроде... Чем чаще их делаешь, тем на более поздний момент сможешь восстановить базу при ее крахе. Это главный аргумент.
При этом минусов нет, одни плюсы: нагрузки лишней это практически никакой не дает, а журнал транзакций растет более контролируемо.
Если достаточно полных бэкапов, тогда надо сразу ставить модель восстановления simple.
При этом минусов нет, одни плюсы: нагрузки лишней это практически никакой не дает, а журнал транзакций растет более контролируемо.
Если достаточно полных бэкапов, тогда надо сразу ставить модель восстановления simple.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
1. Нет.
2. Полный бэкап - позволяет восстановиться на время бэкапа, лог транзакций - на время между полным бэкапом и текущим временем. Таким образом, бэкап лога транзакций нужен только от времени полного бэкапа до текущего времени.
Правильная схема бэкапа: лог транзакций так часто, как считаешь нужным (у меня каждый час например, таким образом, если база падает - восстановить только последний час работы). Полный бэкап с подрезкой лога и очищением устаревших бэкапов лога. Всё это можно сделать средствами Т-SQL
3. Правильно вообще подрезать все логи, до момента создания бэкапа. Проще всего сделать полный бэкап. Перевести базу в простой режим, подрезать логи, вернуть в полный режим восстановления и настроить правильную схему бэкапа из п.2
4. Не понятно... За много лет работы обычно есть необходимость восстановить базу по состоянию на конец какого то дня. Так чтобы на конкретный час - ни разу не было. Поэтому я просто храню последние несколько полных бэкапов, обеспечивая возможность восстановления на последнюю неделю - любой день; на последние несколько недель на утро понедельника только. Тут каждый сам решает в зависимости от запросов пользователей.
5. ХЗ. Но я готовых скриптов скуля именно под свои задачи например не нашел. Часть рожал из оболочки скуля, часть надстроек гуглил варианты и мастерил из них свои.
2. Полный бэкап - позволяет восстановиться на время бэкапа, лог транзакций - на время между полным бэкапом и текущим временем. Таким образом, бэкап лога транзакций нужен только от времени полного бэкапа до текущего времени.
Правильная схема бэкапа: лог транзакций так часто, как считаешь нужным (у меня каждый час например, таким образом, если база падает - восстановить только последний час работы). Полный бэкап с подрезкой лога и очищением устаревших бэкапов лога. Всё это можно сделать средствами Т-SQL
3. Правильно вообще подрезать все логи, до момента создания бэкапа. Проще всего сделать полный бэкап. Перевести базу в простой режим, подрезать логи, вернуть в полный режим восстановления и настроить правильную схему бэкапа из п.2
4. Не понятно... За много лет работы обычно есть необходимость восстановить базу по состоянию на конец какого то дня. Так чтобы на конкретный час - ни разу не было. Поэтому я просто храню последние несколько полных бэкапов, обеспечивая возможность восстановления на последнюю неделю - любой день; на последние несколько недель на утро понедельника только. Тут каждый сам решает в зависимости от запросов пользователей.
5. ХЗ. Но я готовых скриптов скуля именно под свои задачи например не нашел. Часть рожал из оболочки скуля, часть надстроек гуглил варианты и мастерил из них свои.
Спасибо за быстрый ответ)
походу надо передохнуть от этой темы пару дней- уже мысли сбиваются)
в общем, с точки зрения более опытных людей в этом плане, моя схема, где:
1. сделать единоразовый бэкап журналов
2. сделать шринк с реорганизацией на 10-15(вместо 40) гигов под лог транзакций.
3. оставить бэкап баз как есть(6 дней-дифф, на 7-фулл)
4. настроить полный бэкап транзакций раз в неделю с усечением(добавление новой задачи в расписание) ( в моем случае недели должно хватить)
звучит логично?
походу надо передохнуть от этой темы пару дней- уже мысли сбиваются)
в общем, с точки зрения более опытных людей в этом плане, моя схема, где:
1. сделать единоразовый бэкап журналов
2. сделать шринк с реорганизацией на 10-15(вместо 40) гигов под лог транзакций.
3. оставить бэкап баз как есть(6 дней-дифф, на 7-фулл)
4. настроить полный бэкап транзакций раз в неделю с усечением(добавление новой задачи в расписание) ( в моем случае недели должно хватить)
звучит логично?
Или же и вправду, с учетом того, что не было за год вопросов по восстановлению на период времени конкретный мне сделать так:
1. сделать бэкап логов.
2сделать шринк с реорганизацией.
3. оставить на простой модели восстановления
4. запретить расширение лог файла. он же перезаписываться будет?
5. делать ежедневный полный бэкап
1. сделать бэкап логов.
2сделать шринк с реорганизацией.
3. оставить на простой модели восстановления
4. запретить расширение лог файла. он же перезаписываться будет?
5. делать ежедневный полный бэкап
понял, спасибо.
тогда если по порядку:
есть такая галочка в окне резервирования-только резервное копирование- это... что?)
кстати, стоит ли использовать сжатие при резервировании?
может и правда стоит ограничить расширение файла логов в моем случае? или лучше резервирование с усечением? я тогда не уткнусь снова в ограничение места на диске, но уже не по самим файлам лога, а по их бэкапам?) хотя, конечно, можно и удалять старше 2-х недель.
в итоге, как сделать бэкап этих логов, чтобы их можно было безболезненно вытащить с сервера, тут нет нюансов-просто запустить задачу и перенести?=)
тогда если по порядку:
есть такая галочка в окне резервирования-только резервное копирование- это... что?)
кстати, стоит ли использовать сжатие при резервировании?
может и правда стоит ограничить расширение файла логов в моем случае? или лучше резервирование с усечением? я тогда не уткнусь снова в ограничение места на диске, но уже не по самим файлам лога, а по их бэкапам?) хотя, конечно, можно и удалять старше 2-х недель.
в итоге, как сделать бэкап этих логов, чтобы их можно было безболезненно вытащить с сервера, тут нет нюансов-просто запустить задачу и перенести?=)
(10)Простая схема обычно считается частным случаем модели восстановления 1С для не нагруженных баз.
Если ты делаешь полный бэкап каждый день, то в самом плохом случае тебе придётся восстановить откуда то целые сутки. Если в базе каждый день работает хотя бы 10 человек, отрицательная карма тебе обеспечена надолго...
Если ты делаешь полный бэкап каждый день, то в самом плохом случае тебе придётся восстановить откуда то целые сутки. Если в базе каждый день работает хотя бы 10 человек, отрицательная карма тебе обеспечена надолго...
и еще вопрос. читаю сейчас статью 173494/. "При формировании резервной копии со стандартными параметрами, место в файле журнала транзакций высвобождается (до момента последней открытой транзакции)." это получается не обязательно выставлять пункт "усечение" при формировании sql скрипта, он урезается автоматом? или я чего-то не понял)
Подрезка лога и переиндексация это, можно сказать, сущности не связанные.
Обновления статистик и переиндексация помогают базе работать быстрее за счет того, что со свежими статистиками и индексами составляются более оптимальные планы запросов
Обновления статистик и переиндексация помогают базе работать быстрее за счет того, что со свежими статистиками и индексами составляются более оптимальные планы запросов
(0) Все не читал, но добавлю от себя:
1) оставить полную схему восстановления (full)
2) если полный бэкап занимает приемлемое время и место, то отключить дифференциальные бэкапы, оставить ежесуточные полные (которые являются полностью самодостаточной штукой).
3) бэкап журнала транзакций - каждый час. Их можно делать чем чаще, тем лучше, они не накопительные. При этом они помечают забэкапленные транзакции в журнале как удаленные (т.е. при "ровной" работе журнал не растет). При этом с полного бэкапа можно восстановится на любой момент в пределах сделанных бэкапов журнала (но нужны все бэкапы журнала с момента полного бэкапа).
Шринки базы и журнала на регулярной основе делать как правило нет смысла.
Только если есть конкретная проблема с размерами базы или журнала, имеет смысл проанализировать распределение места и прикинуть, имеет ли смысл тот или иной шринк. При этом иметь в виду, что шринк с дефолтными настройками освобождает только "хвост" (что редко "лечит"), а шринк с реорганизацией базы - очень затратная операция.
4) если потеря данных дня не смертельна для организации, то можно забить на любые бэкапы кроме полных и включить схему восстановления simple (в этом случае журнал транзакций будет чиститься автоматически, а не бэкапами журнала). Если база не слишком большая, то можно даже дважды в день полный бэкап делать.
1) оставить полную схему восстановления (full)
2) если полный бэкап занимает приемлемое время и место, то отключить дифференциальные бэкапы, оставить ежесуточные полные (которые являются полностью самодостаточной штукой).
3) бэкап журнала транзакций - каждый час. Их можно делать чем чаще, тем лучше, они не накопительные. При этом они помечают забэкапленные транзакции в журнале как удаленные (т.е. при "ровной" работе журнал не растет). При этом с полного бэкапа можно восстановится на любой момент в пределах сделанных бэкапов журнала (но нужны все бэкапы журнала с момента полного бэкапа).
Шринки базы и журнала на регулярной основе делать как правило нет смысла.
Только если есть конкретная проблема с размерами базы или журнала, имеет смысл проанализировать распределение места и прикинуть, имеет ли смысл тот или иной шринк. При этом иметь в виду, что шринк с дефолтными настройками освобождает только "хвост" (что редко "лечит"), а шринк с реорганизацией базы - очень затратная операция.
4) если потеря данных дня не смертельна для организации, то можно забить на любые бэкапы кроме полных и включить схему восстановления simple (в этом случае журнал транзакций будет чиститься автоматически, а не бэкапами журнала). Если база не слишком большая, то можно даже дважды в день полный бэкап делать.
(31) Так я писал вроде... Чем чаще их делаешь, тем на более поздний момент сможешь восстановить базу при ее крахе. Это главный аргумент.
При этом минусов нет, одни плюсы: нагрузки лишней это практически никакой не дает, а журнал транзакций растет более контролируемо.
Если достаточно полных бэкапов, тогда надо сразу ставить модель восстановления simple.
При этом минусов нет, одни плюсы: нагрузки лишней это практически никакой не дает, а журнал транзакций растет более контролируемо.
Если достаточно полных бэкапов, тогда надо сразу ставить модель восстановления simple.
Лучше даже не каждый час, а почаще. Чем больше объём записи в базу - тем чаще.
Во-первых, повышается актуальность бэкапа. Во-вторых уменьшается нагрузка на сервер, т.к. порции меньше (при бэкапе логов в full-модели не весь лог целиком бэкапится, а только кусок с последнего бэкапа лога до текущего момента).
Во-первых, повышается актуальность бэкапа. Во-вторых уменьшается нагрузка на сервер, т.к. порции меньше (при бэкапе логов в full-модели не весь лог целиком бэкапится, а только кусок с последнего бэкапа лога до текущего момента).
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот