|
v8: пухнет журнал в SQL 2012 | ☑ | ||
---|---|---|---|---|
0
Adecvator
04.07.14
✎
15:41
|
Поставил ограничение для лог-файла в 8 Гиг, а он вырастает до этих размеров за 2 дня упирается и приходиться чистить в ноль. Как сделать что бы он "самоочищался".
|
|||
1
wanderer_ица
04.07.14
✎
15:42
|
simple mode
или backup базы ежедневный |
|||
2
Господин ПЖ
04.07.14
✎
15:43
|
>backup базы ежедневный
не базы а лога + шринк |
|||
3
Освобожденный
04.07.14
✎
15:45
|
use [base_1c]
BACKUP LOG base_1c WITH TRUNCATE_ONLY GO DUMP TRANSACTION base_1c WITH no_log GO CHECKPOINT GO DBCC SHRINKFILE(base_1c_log,2) GO DBCC SQLPERF (logspace) |
|||
4
Освобожденный
04.07.14
✎
15:46
|
Где "base_1c" - имя базы на SQL сервере. Скрипт ставим в шедулер и запускаем каждую ночь.
|
|||
5
wanderer_ица
04.07.14
✎
15:49
|
(3) Note:
The BACKUP LOG WITH NO_LOG and WITH TRUNCATE_ONLY options have been discontinued |
|||
6
Господин ПЖ
04.07.14
✎
15:51
|
WITH TRUNCATE_ONLY нету с 2008
|
|||
7
Adecvator
04.07.14
✎
15:51
|
мне не понять а зачем тогда, есть возможность определить макс. размер лога?
|
|||
8
Освобожденный
04.07.14
✎
15:56
|
Тогда надо поменять модель восстановления с Full на Simple и обратно.
|
|||
9
ОчкарикСлава
04.07.14
✎
16:00
|
(7) для фиксации максимального размера.
|
|||
10
Йохохо
04.07.14
✎
16:09
|
(7) если не ограничить он звонко шлепнется, когда место кончится. плюс операция приращения файла лога тяжелая, выкусить сразу дает прирост производительности
|
|||
11
Adecvator
04.07.14
✎
17:18
|
use [EB_Test]
DECLARE @pathName NVARCHAR(max) ; DECLARE @dbName NVARCHAR(128) ; DECLARE @bkName NVARCHAR(128) ; SET @dbName = 'EB_Test' SET @pathName = 'G:\1C\EB_Test\daily.bak' SET @bkName = @dbName + N'_full_backup' BACKUP DATABASE @dbName TO DISK = @dbName WITH FORMAT, INIT, NAME = @bkName, COMPRESSION GO DUMP TRANSACTION @dbName WITH no_log GO CHECKPOINT GO DBCC SHRINKFILE(EB_Test_log,2) GO DBCC SQLPERF (logspace) Сообщение 156, уровень 15, состояние 1, строка 1 Неправильный синтаксис около ключевого слова "TRANSACTION". Сообщение 8985, уровень 16, состояние 1, строка 1 Не удалось найти файл "EB_Test_log" для базы данных "EB_Test" в sys.database_files. Файл не существует или был удален. Как правильно определить имя лог файла? |
|||
12
Господин ПЖ
04.07.14
✎
17:25
|
тебе написали где посмотреть можно
|
|||
13
Adecvator
04.07.14
✎
17:35
|
С именем лог файла разобрался, теперь осталось разобраться с ошибкой: - "Неправильный синтаксис около ключевого слова "TRANSACTION"."
|
|||
14
Йохохо
04.07.14
✎
17:38
|
удали его, разницы никакой
|
|||
15
Йохохо
04.07.14
✎
17:38
|
строку всю
|
|||
16
Господин ПЖ
04.07.14
✎
17:38
|
(13) его выпилили в 2008 серваке
|
|||
17
Adecvator
04.07.14
✎
17:58
|
все хорошо, но вот почему то не создается бак-файл - G:\1C\EB_Test\daily.bak
|
|||
18
Adecvator
08.07.14
✎
11:21
|
Через запрос отрабатывает, через План обслуживание пишет (Этот шаг определен неверно и не может быть выполнен (необходимо указать допустимую команду). Шаг завершился с ошибкой.).
GO -- Truncate the log by changing the database recovery model to SIMPLE. ALTER DATABASE EB SET RECOVERY SIMPLE; GO -- Shrink the truncated log file to 1 MB. DBCC SHRINKFILE (EB_Log, 1); GO -- Reset the database recovery model. ALTER DATABASE EB SET RECOVERY FULL; GO |
|||
19
Господин ПЖ
08.07.14
✎
11:24
|
(18) бедная база
ты ее так каждый день насилуешь? |
|||
20
Adecvator
08.07.14
✎
11:28
|
1-2 раза в неделю.
|
|||
21
Adecvator
08.07.14
✎
11:28
|
ни (3), ни (11) не работает.
|
|||
22
Adecvator
08.07.14
✎
11:30
|
После Реорганизации индексов и Обновлении статистики, лог разбухает до 20-30 Гиг.
|
|||
23
SSSSS_AAAAA
08.07.14
✎
11:35
|
(22) Вот и оставь его в таком состоянии и не насилуй сервер совершенно бесполезными действиями.
|
|||
24
Adecvator
08.07.14
✎
11:41
|
(23) а каким объемом ограничить лог файл, а резать я так понимаю в любом случае надо будет лог.
|
|||
25
Йохохо
08.07.14
✎
11:52
|
(24) ограничь его бэкапами, после бэкапа лог помечается как ненужный и начинает перезаписываться
|
|||
26
SSSSS_AAAAA
08.07.14
✎
11:57
|
(24) Ты неправильно понимаешь. НЕ НАДО резать лог, НЕ НАДО считать себя умнее разработчиков сервера. Если лог растет, то это нужно серверу. Но не по прихоти своей его увеличивает. И увеличивать выше того, что ему нужно он не будет. Дай размеру лога устаканиться, не забывай бэкапы лога или переведи базу в режим симпл и забудь про него.
|
|||
27
Adecvator
08.07.14
✎
12:04
|
Вывод: Бэкапим лог каждый день после бэкапа базы и смотрим на размер базы.
|
|||
28
kuromanlich
08.07.14
✎
12:08
|
приклеюс к теме что ли. база в редиме полного восттановления. как урезать журнал? архивирование лог файла не влияет на размер, разностный, полный, шринк... все тзетно. каг?
|
|||
29
SSSSS_AAAAA
08.07.14
✎
12:12
|
(28) ЗАЧЕМ? Что вы все так зациклились на размере файла? Что даст его уменьшение? На каком основании вы так решили?
|
|||
30
Maxus43
08.07.14
✎
12:14
|
(28) сначала бэкап лога, потом Шринк. он не зашринкуется без бэкапа. переведи в симпл и не парь мозг, всё равно не используете возможности журнала транзакций
|
|||
31
Йохохо
08.07.14
✎
12:15
|
(27) сохранится часть лога, нужная для восстановления после последнего бэкапа. чему равна нужная часть лога сразу после бэкапа?
|
|||
32
kuromanlich
08.07.14
✎
12:18
|
(30) делал все, поэтому и пишу сюда
(29) размер лога в 350 гигов грозит заполнить под завязку отдельный SSD на 500 гигов |
|||
33
Sammo
08.07.14
✎
12:22
|
(32) Если скуль периодически увеличивает размер лога до 320 гиг, то значит периодически есть операции, которые вызывают такой рост лога. Значит надо разбираться с ними.
А размер лога уменьшать имеет смысл одноразово после каких-либо существенных действий. Имхо |
|||
34
kuromanlich
08.07.14
✎
15:13
|
(33) это потихоньку, в течение недели
|
|||
35
Господин ПЖ
08.07.14
✎
15:15
|
а наоборот нельзя? перед такими операциями переводить в симпл, а потом в фул?
|
|||
36
kuromanlich
08.07.14
✎
16:07
|
(35) хм... интересно, а восстановление на любую минуту все еще будет работать?
|
|||
37
Господин ПЖ
08.07.14
✎
16:09
|
(36) наструя оно нужно при реорганизации? 1с в этот момент все равно no responded. То что кто-то будет восстанавливать посредине процесса тоже не уверен.
просто надо снизить число журналируемых операций раз все так пухнет, второй момент - получить представление в чем причина |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |