Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Catwoof Member Откуда: Москва Сообщений: 13 |
Приветствую! Имеется сервер 2012 с кучей баз, которые то добавляются, то выводятся из боевого режима. Выполняется всё через Агента. План, который достался мне по наследству: Шаг 1 BACKUP DATABASE [BASE1] TO [BASE1_Monday] WITH INIT, NOFORMAT, SKIP, NOUNLOAD, COMPRESSION Шаг 2 BACKUP LOG [BASE1] TO [BASE1_Monday] WITH COMPRESSION GO USE [BASE1]; GO -- Truncate the log by changing the database recovery model to SIMPLE. ALTER DATABASE [BASE1] SET RECOVERY SIMPLE; GO -- Shrink the truncated log file to 1 MB. DBCC SHRINKFILE ([BASE1_Log], 1); GO -- Reset the database recovery model. ALTER DATABASE [BASE1] SET RECOVERY FULL; GO Шаг 3 XCOPY B:\Backups\BASE1_Monday.bak \\server\Backups\BASE1\*.* /Y Всё это не позволяет откатывать базы по журналу и занимает кучу места. Некоторым базам лог нужно обрезать каждый день, переполняется. Получается простыня 100+ шагов в которой постоянно запутываешься. Для небольших баз сделал схему с ручным удалением старых бэкапов Два раза в неделю: Шаг 1 BACKUP DATABASE [BASE2] TO [BASE2_Wednesday] WITH INIT, NOFORMAT, SKIP, NOUNLOAD, COMPRESSION Шаг 2 BACKUP LOG [BASE2] TO [BASE2_Wednesday] WITH COMPRESSION GO USE [BASE2]; GO -- Truncate the log by changing the database recovery model to SIMPLE. ALTER DATABASE [BASE2] SET RECOVERY SIMPLE; GO -- Shrink the truncated log file to 1 MB. DBCC SHRINKFILE ([BASE2_Log], 1); GO -- Reset the database recovery model. ALTER DATABASE [BASE2] SET RECOVERY FULL; GO Шаг 3 COPY B:\Backups\BASE2_Wednesday.bak \\server\Backups\server2\BASE2\%date:~6,4%.%date:~3,2%.%date:~0,2%_BASE2_Wednesday.bak /Y В другие дни: Шаг 1 BACKUP DATABASE [BASE2] TO [BASE2_Monday] WITH DIFFERENTIAL , NOFORMAT, INIT, SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO Шаг 2 BACKUP LOG [BASE2] TO [BASE2_Monday] WITH NOFORMAT, NOINIT, SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO USE [BASE2]; GO -- Truncate the log by changing the database recovery model to SIMPLE. ALTER DATABASE [BASE2] SET RECOVERY SIMPLE; GO -- Shrink the truncated log file to 1 MB. DBCC SHRINKFILE ([BASE2_Log], 1); GO -- Reset the database recovery model. ALTER DATABASE [BASE2] SET RECOVERY FULL; GO Шаг 3 COPY B:\Backups\BASE2_Monday.bak \\server\Backups\server2\BASE2\%date:~6,4%.%date:~3,2%.%date:~0,2%_BASE2_Monday.bak /Y Как это можно всё оптимизировать и сократить шаги? |
28 янв 19, 20:19 [21796230] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37143 |
Переведите базы в simple и не страдайте фигней. |
28 янв 19, 20:28 [21796238] Ответить | Цитировать Сообщить модератору |
Catwoof Member Откуда: Москва Сообщений: 13 |
Гавриленко Сергей Алексеевич, Часто нужен откат по времени |
28 янв 19, 20:34 [21796241] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37143 |
|
||
28 янв 19, 20:36 [21796243] Ответить | Цитировать Сообщить модератору |
felix_ff Member Откуда: Moscow Сообщений: 1695 |
Catwoof,
для "некоторых баз" бэкапьте чаще лог, и тогда не нужна будет это ваша свистопляска с переключением моделей восстановления. при этом у вас "шикарная технология" переключения которая с случае поломки бд, не даст вам восстановить данные которые были записаны после последнего бекапа лога. с таким порядком операторов вы собственно говоря сидите на "симпл" модели восстановления. |
||
28 янв 19, 20:46 [21796248] Ответить | Цитировать Сообщить модератору |
SERG1257 Member Откуда: Сообщений: 2828 |
|
||
28 янв 19, 21:00 [21796263] Ответить | Цитировать Сообщить модератору |
Catwoof Member Откуда: Москва Сообщений: 13 |
Эта схема - наследство (работает уже 5 лет). Я только начал изучать SQL, опыта в составлении планов обслуживания нет и взять неоткуда. felix_ff, Раз в неделю делать FULL и каждый день лог? BACKUP LOG [Base1] TO [Base1] WITH NOFORMAT, NOINIT, SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO |
||||
28 янв 19, 22:04 [21796315] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31782 |
1. Базы, для которых нужен откат по времени, переводите в FULL 2. Базы, для которых не нужен откат по времени, переводите в SIMPLE 3. Базы, для которых нужен откат по времени, включаете в джоб бакапа лога (скажем, раз в 30 минут). 4. Все базы включаете в джоб полного бакапа (скажем, раз в сутки).
У вас старый и новый скрипт допускает восстановление на момент времени, если всё нормально, если ничего не сломалось. А если сломалось? Это не очень хорошая концепция резервного копирования. |
||||
28 янв 19, 22:05 [21796316] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31782 |
|
||||||
28 янв 19, 22:07 [21796317] Ответить | Цитировать Сообщить модератору |
Catwoof Member Откуда: Москва Сообщений: 13 |
У вас старый и новый скрипт допускает восстановление на момент времени, если всё нормально, если ничего не сломалось. А если сломалось? Это не очень хорошая концепция резервного копирования.[/quot] Угу, восстановить возможно только полную копию благодаря технологии шринка лога |
||
28 янв 19, 22:14 [21796326] Ответить | Цитировать Сообщить модератору |
Catwoof Member Откуда: Москва Сообщений: 13 |
Нужно место занимаемое сократить. Если делать раз в 3 дня FULL, лог каждые 30 минут и дифференциальный раз в день (он вообще тут нужен, если лог имеется)? |
||||||
28 янв 19, 22:20 [21796332] Ответить | Цитировать Сообщить модератору |
Catwoof Member Откуда: Москва Сообщений: 13 |
Это база данных со скриптами создания планов? Не понимать |
||||
28 янв 19, 22:41 [21796348] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31782 |
Но вообще для экономии места можно просто стирать старые полные бакапы. Скажем, храните за неделю бакапы за каждый день, а из более старых оставляете только воскресный. То есть, и логически, и по месту для хранения, стирание бакапа совершенно тождественно тому, что его не делают, а удобство и надёжность выше.
Он удобен, если база очень большая, а изменения редкие - тогда можно делать FULL реже, и при этом не трогать всю цепочку бакапов лога при восстановлении. Но для обычных баз это лишнее. |
||||
28 янв 19, 23:14 [21796362] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31782 |
|
||||
28 янв 19, 23:15 [21796363] Ответить | Цитировать Сообщить модератору |
Catwoof Member Откуда: Москва Сообщений: 13 |
Это решает все мои задачи. |
||||
29 янв 19, 02:22 [21796404] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
Человека, который это написал нельзя назвать компетентным. Но при серьезном сбое крайним станете вы. Если лог растет, надо разбираться почему, а не делать танцы с бубном. ALTER DATABASE [BASE1] SET RECOVERY SIMPLE; Информации полно https://www.youtube.com/results?search_query=mssql backup |
||
29 янв 19, 13:04 [21796749] Ответить | Цитировать Сообщить модератору |
Catwoof Member Откуда: Москва Сообщений: 13 |
База 1эССная и не маленькая, это первый способ что можно найти. Теперь главный вопрос, как ужимать лог? Бэкап будет каждые пол часа EXECUTE [dbo].[DatabaseBackup] @Databases = 'Base', @Directory = NULL, @BackupType = 'LOG', @Compress = 'Y', @CheckSum = 'Y', @AvailabilityGroupDirectoryStructure = 'NULL', @CleanupTime = 168, @FileName = '{DatabaseName}_{BackupType}_{Year}{Month}{Day}.{FileExtension}', @DirectoryStructure = '{DirectorySeparator}{DatabaseName}{DirectorySeparator}{BackupType}_{Partial}_{CopyOnly}' |
||||
29 янв 19, 17:54 [21797178] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37143 |
|
||||
29 янв 19, 17:58 [21797183] Ответить | Цитировать Сообщить модератору |
Catwoof Member Откуда: Москва Сообщений: 13 |
А куда он девается? Кажется он растёт пока есть место... |
||||||
29 янв 19, 18:08 [21797195] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8317 |
Catwoof, если делать резервные копии журнала, то место в нем будет переиспользовано базой. Вы говорите: "ОК, я перенес записи в безопасное место, можешь затирать". |
29 янв 19, 18:22 [21797205] Ответить | Цитировать Сообщить модератору |
Catwoof Member Откуда: Москва Сообщений: 13 |
Владислав Колосов, Значит я иду в правильном направлении |
29 янв 19, 19:24 [21797245] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
Может есть причина, по которой он растет.
|
||||||
29 янв 19, 19:26 [21797246] Ответить | Цитировать Сообщить модератору |
Catwoof Member Откуда: Москва Сообщений: 13 |
a_voronin, В моём случае это из-за специалистов делавших скрипт в сотню строк. |
29 янв 19, 19:36 [21797250] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
Это да, вот тысячи это нормально |
||
29 янв 19, 21:15 [21797295] Ответить | Цитировать Сообщить модератору |
Catwoof Member Откуда: Москва Сообщений: 13 |
TaPaK, Тысяча - не предел. Я знаю, многие способы и на большее! |
29 янв 19, 21:58 [21797312] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |