Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Рост журналов транзакций  [new]
Nitro Gear
Member

Откуда:
Сообщений: 19
Тема избитая - извиняюсь заранее, но просьба не отправлять в поиск, а прочитать ее и, если сможете, помочь. Спасибо.
В базе SQL 2008 Std есть база 1С 8.2, для которой ночью каждый день выполняются регламентные задачи:
1. обновление статистики
2. дефрагментация индексов (раз в неделю вместо этого задания запускается полная перестройка индексов)
После этого выполняется резервное полное копирование базы и журналов транзакций.
Проблема в том, что при размере базы под 30Гб, после дефрагментации индексов журнал транзакций увеличивается на 30-40Гб (см. скриншот).
Сейчас сразу после дефрагментации выполняется резервное копирование базы и журналов, а спустя несколько часов запускается повторное резервное копирование базы и журналов с командой shrink, что уменьшает размер логов до вменяемых размеров. В течении дня рост журналов транзакций плавный и без скачков.
База и журналы находятся на разных дисках.
Что посоветует специалисты и какие бест практикс существуют по этому вопросу?
Можно ли как-то избежать подобной ситуации? Замечено, что если логи занимают 50-60Гб это негативно отражается на быстродействии работы 1С.

К сообщению приложен файл. Размер - 42Kb
17 июл 13, 12:15    [14577289]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Nitro Gear,

так смысл не отправлять в поиск,вчера только такая же тема 1 к 1 обсуждалась ,неужели вы думаетет что всем так прикольно каждый день писать одно и тоже ?
17 июл 13, 12:17    [14577303]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Knyazev Alexey
Member

Откуда: Екб -> Мск
Сообщений: 10233
Блог
https://www.sql.ru/articles/mssql/2007/051403extentusageandbehaviourswhenusingdbreindexandshrinkfile.shtml
17 июл 13, 12:18    [14577313]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Knyazev Alexey
Member

Откуда: Екб -> Мск
Сообщений: 10233
Блог
Knyazev Alexey
https://www.sql.ru/articles/mssql/2007/051403extentusageandbehaviourswhenusingdbreindexandshrinkfile.shtml

упс, думал вы сами файлы с данными шринкаете после дефрагментации
17 июл 13, 12:21    [14577322]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Nitro Gear
2. дефрагментация индексов

каждую ноч ? Вы уверены что ето так необходимо ?
17 июл 13, 12:24    [14577344]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Nitro Gear
Member

Откуда:
Сообщений: 19
Maxx
Nitro Gear
2. дефрагментация индексов

каждую ноч ? Вы уверены что ето так необходимо ?

По советам от 1С настоятельно рекомендуется это делать каждый день, а в некоторых случаях и несколько раз в день.
17 июл 13, 12:33    [14577406]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Nitro Gear
По советам от 1С

Фигасе... можно ссылку на эти советы?
17 июл 13, 12:39    [14577448]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
gang
Member

Откуда:
Сообщений: 1394
Nitro Gear,

Какой именно ситуации вы хотите избегать? Все что вы делаете допустимо.
Бест практисы же такие:
1) Перестраивать только те индексы, которые в этом нуждаются (на основании статистики о фрагментации)
2) Если периодическая операция требует некого роста файла (данных и/или лога), то ужимать его в промежутках
особого смысла не имеет.
3) По вопросу производительности лога поизучайте статейку

Если есть жесткая установка не растить лог при реиндексации, возможно, следует рассмотреть вариант переключения БД на модель simple перед обслуживанием и возвратом full по завершении. Размер лога будет в основном определяться размером наибольшей таблицы (индекса). Если есть такая что занимает, скажем 80% БД, то переключение модели ощутимого эффекта не даст.
17 июл 13, 12:46    [14577489]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Nitro Gear
Member

Откуда:
Сообщений: 19
Гость333
Nitro Gear
По советам от 1С

Фигасе... можно ссылку на эти советы?

немного переврал - не реже раза в неделю, а при большой изменчивости данных - каждый день
http://1cexpo.ru/instrukczii/22-reglamentnye-operaczii-na-urovne-subd-dlya-ms-sql-server.html
17 июл 13, 13:48    [14577983]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Nitro Gear
Гость333
Nitro Gear
По советам от 1С


Фигасе... можно ссылку на эти советы?

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

Это разве официальный сайт фирмы 1С? Зарегистрирован на частное лицо. В статье даже не указан автор. Видимо, стырили откуда-то и копирайты потёрли. В общем, не надо пользоваться источниками, не заслуживающими доверия.
17 июл 13, 14:22    [14578194]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Nitro Gear
Member

Откуда:
Сообщений: 19
Гость333
Nitro Gear
пропущено...
немного переврал - не реже раза в неделю, а при большой изменчивости данных - каждый день
http://1cexpo.ru/instrukczii/22-reglamentnye-operaczii-na-urovne-subd-dlya-ms-sql-server.html

Это разве официальный сайт фирмы 1С? Зарегистрирован на частное лицо. В статье даже не указан автор. Видимо, стырили откуда-то и копирайты потёрли. В общем, не надо пользоваться источниками, не заслуживающими доверия.

http://www.interface.ru/home.asp?artId=31174
если поискать, то в сети множество статей и во всех упоминаются ежедневные задачи по обслуживанию
17 июл 13, 15:43    [14578804]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Nitro Gear
http://www.interface.ru/home.asp?artId=31174

Автор статьи — Necro_KOT с хабра. Ну то есть опять это не рекомендации от 1С.
Я статью не смотрел и против автора ничего не имею, скорее всего, он пишет хорошие и правильные вещи.

Но я против того, чтобы статьи из неофициальных источников называть официальными рекомендациями производителя софта ;-(
Так и рождаются всякие мифы.
17 июл 13, 15:53    [14578869]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
1) Перестраивать только те индексы, которые в этом нуждаются (на основании статистики о фрагментации)
В помощь. http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
18 июл 13, 00:13    [14581016]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
BusyMan
Member

Откуда: Москва
Сообщений: 4927
Если вы 100% уверены что дефрагментация индексов и есть причина роста лога - это уже значит что вы везучий человек, ибо иметь стопроцентную уверенность в чем либо есть истинное счастье. Но если вы все же хотите выяснить причину наверняка, то я могу посоветовать запускать запросик приложенный ниже - чтобы отловить те запросы которые жруг лог. Я этот запросик запускаю каждую минуту. собрав эту статистику - я вижу какие запросы очень много пишут в лог. Очень часто так можно узнать много интересного о себе и своей базе данных. К сожалению, насколько я знаю это нет вохзможности сделать в профайлере.


		INSERT INTO dbo.LogFileUsage
		(
		 SPID, transaction_id, Name, StartTime, TransactionType, [State], DistributedState, [Database], DBBeginTime, DBType
		 , DBState, LogRecords, LogKBUsed, LogKBReserved, LogKBUsedSystem, LogKBReservedSystem, ReplicationRecords, CommandType
		 , ElapsedTime, CPUTime, WaitType, WaitTime, WaitResource, Reads, LogicalReads, Writes, OpenTransactions, OpenResultSets
		 , RowsReturned, NestLevel, QueryMemory, query_text, ObjectName, IsLogActive
		)
		-- This query returns log file space used by all running transactions.
		OUTPUT INSERTED.LogFileUsageId, INSERTED.SPID, INSERTED.transaction_id, INSERTED.[database] 
		INTO @O (LogId, SPID, transaction_id, [database])
		select
			SessionTrans.session_id as [SPID],
		   -- enlist_count as [Active Requests],
			DBTrans.transaction_id as transaction_id,
			ActiveTrans.name as [Name],
			ActiveTrans.transaction_begin_time as [Start Time],
			case transaction_type
				when 1 then 'Read/Write'
				when 2 then 'Read-Only'
				when 3 then 'System'
				when 4 then 'Distributed'
				else 'Unknown - ' + convert(varchar(20), transaction_type)
			end as [Transaction Type],
			case transaction_state
				when 0 then 'Uninitialized'
				when 1 then 'Not Yet Started'
				when 2 then 'Active'
				when 3 then 'Ended (Read-Only)'
				when 4 then 'Committing'
				when 5 then 'Prepared'
				when 6 then 'Committed'
				when 7 then 'Rolling Back'
				when 8 then 'Rolled Back'
				else 'Unknown - ' + convert(varchar(20), transaction_state)
			end as 'State',
			case dtc_state
				when 0 then NULL
				when 1 then 'Active'
				when 2 then 'Prepared'
				when 3 then 'Committed'
				when 4 then 'Aborted'
				when 5 then 'Recovered'
				else 'Unknown - ' + convert(varchar(20), dtc_state)
			end as 'Distributed State',
			DB.Name as 'Database',
			database_transaction_begin_time as [DB Begin Time],
			case database_transaction_type
				when 1 then 'Read/Write'
				when 2 then 'Read-Only'
				when 3 then 'System'
				else 'Unknown - ' + convert(varchar(20), database_transaction_type)
			end as 'DB Type',
			case database_transaction_state
				when 1 then 'Uninitialized'
				when 3 then 'No Log Records'
				when 4 then 'Log Records'
				when 5 then 'Prepared'
				when 10 then 'Committed'
				when 11 then 'Rolled Back'
				when 12 then 'Committing'
				else 'Unknown - ' + convert(varchar(20), database_transaction_state)
			end as 'DB State',
			database_transaction_log_record_count as [Log Records],
			database_transaction_log_bytes_used / 1024 as [Log KB Used],
			database_transaction_log_bytes_reserved / 1024 as [Log KB Reserved],
			database_transaction_log_bytes_used_system / 1024 as [Log KB Used (System)],
			database_transaction_log_bytes_reserved_system / 1024 as [Log KB Reserved (System)],
			database_transaction_replicate_record_count as [Replication Records],
			command as [Command Type],
			total_elapsed_time as [Elapsed Time],
			cpu_time as [CPU Time],
			wait_type as [Wait Type],
			wait_time as [Wait Time],
			wait_resource as [Wait Resource],
			reads as [Reads],
			logical_reads as [Logical Reads], 
			writes as [Writes],
			ExecReqs.open_transaction_count as [Open Transactions],
			open_resultset_count as [Open Result Sets],
			row_count as [Rows Returned],
			nest_level as [Nest Level],
			granted_query_memory as [Query Memory],
			SUBSTRING(SQLText.text,ExecReqs.statement_start_offset/2,(CASE WHEN ExecReqs.statement_end_offset = -1 then LEN(CONVERT(nvarchar(max), SQLText.text)) * 2 ELSE ExecReqs.statement_end_offset end - ExecReqs.statement_start_offset)/2) AS query_text,
			db_name(SQLText.dbid)+'.'+object_name(SQLText.objectid, SQLText.dbid) AS ObjectName
		,	1 AS IsLogActive
		-- SELECT *     
		-- SELECT * FROM sys.dm_tran_active_transactions
		from sys.dm_tran_database_transactions DBTrans (nolock)
		LEFT join sys.dm_tran_active_transactions ActiveTrans (nolock) on DBTrans.transaction_id = ActiveTrans.transaction_id
		join sys.databases DB (nolock) on DB.database_id = DBTrans.database_id
		left join sys.dm_tran_session_transactions SessionTrans (nolock)  on SessionTrans.transaction_id = DBTrans.transaction_id
		left join sys.dm_exec_requests ExecReqs (nolock)on ExecReqs.session_id = SessionTrans.session_id and ExecReqs.transaction_id = SessionTrans.transaction_id
		outer apply sys.dm_exec_sql_text(ExecReqs.sql_handle) AS SQLText
		where SessionTrans.session_id is not null -- comment this out to see SQL Server
		AND (	database_transaction_log_record_count > 40
			OR	database_transaction_log_bytes_used > 1024
			OR	database_transaction_log_bytes_reserved > 1024
			OR	database_transaction_log_bytes_used_system > 0--5000 
			OR	database_transaction_log_bytes_reserved_system > 1024
		)
18 июл 13, 04:09    [14581192]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Nitro Gear
Member

Откуда:
Сообщений: 19
BusyMan
Если вы 100% уверены что дефрагментация индексов и есть причина роста лога - это уже значит что вы везучий человек, ибо иметь стопроцентную уверенность в чем либо есть истинное счастье. Но если вы все же хотите выяснить причину наверняка, то я могу посоветовать запускать запросик приложенный ниже - чтобы отловить те запросы которые жруг лог. Я этот запросик запускаю каждую минуту. собрав эту статистику - я вижу какие запросы очень много пишут в лог.

Уверенность есть на 98% - ведь есть поминутный график роста логов каждый день, который по времени совпадает с заданием на дефрагментацию индексов. Больше в это время никаких заданий не выполняется, с базой никто не работает.
Я не спец по SQL, но мне казалось, что в журнал транзакций пишутся события, изменяющие данные, а дефрагментация индексов не вносит изменения в данные - она лишь располагает их по порядку. Но, выходит, что это мое заблуждение.
Или может можно настроить какие события попадают в журнал транзакций и можно отключить события дефрагментации индексов?
18 июл 13, 14:41    [14584062]     Ответить | Цитировать Сообщить модератору
 Re: Рост журналов транзакций  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35836
Блог
1) дефрагментировать/перестраивать индексы с учетом степени их фрагментации
2) обновлять статистику тех объектов, где статистика не обновлялась "давно" (что у вас значит "давно" сможете определить только вы сами)

порядок действий должен быть именно такой,

без изменения модели восстановления больше ничего не сделать
18 июл 13, 15:50    [14584687]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить