Имя: Пароль:
1C
1С v8
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. То что кто-то будет восстанавливать посредине процесса тоже не уверен.

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