| 
			
			 | 
		#1 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
			
			
			shrink журнал логов транзакций и backup
			 
			
			Axapta 2009, Microsoft SQL Server 2012 (SP4)  
		
		
		
		
		
		
		
	База данных в режиме full. Журналы логов транзакций бекапяться каждый час. На базе данных настроены 2 задачи {ежедневно и еженедельно} пересчет и реорганизация индексов. В последнее время журнал логов стал расти и и иногда не стал успевать сохраняться в резервной копии. Анализ ситуации показал, что журнал транзакций занят на 10 -15 процентов и сильно растет только после реорганизации индексов и по итогу может стать больше самой базы. В итоге назревает план по совмещению трех событий: 1. Еженедельная реогранизация индексов (лог вырос) 2. Бекап (появилась возможность shrink журнал логов транзакций) 3. Shrink журнал логов транзакций (лог уменьшился) Имеем опять маленький журнал логов, бекап успевает - все хорошо. Вопрос -есть из опыта другие способы решения проблемы? Подводные камни в предложенном варианте? На simple переходить нельзя.  | 
| 
	
 | 
| 
			
			 | 
		#2 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Насколько велика БД? Есть ли цель восстанавливать данные по состоянию на какое-то время, например на неделю назад, на месяц. 
		
		
		
		
		
		
			У нас БД маленькая - 150 гиг, и нет цели хранить бэкапы на 100 лет назад. Максимум 2 дня. Поэтому план такой: 1. Раз в сутки полный бэкап. 2. Раз в час - дифференциальный. в 00 минут 3. Раз в 5 минут - логи транзакций. 4. Реиндексация каждый час в чч:20минут, но там схема хитрая, реиндексируются только индексы с большим процентом фрагментации. 5. Обновление статистики каждый час в чч:40 минут. После выполнения 1 пункта удаляются дифференциальные бэкапы и логи - они уже не нужны. А также позавчерашний полный. Вчерашний переименовывается в позавчерашний. После выполнения 2 пункта удаляются промежуточные логи. Ну и все бэкапы по FTP копируются на резервный сервер. 
				__________________ 
		
		
		
		
	Я прибыл к вам из Кантемировской дивизии. А там, как известно, дураков не держат!  
			 | 
| 
	
 | 
| 
			
			 | 
		#3 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			1. Делать дополнительный бэкап логов после каждой операции переиндексации. 
		
		
		
		
		
		
		
	2. Для больших таблиц проводить переиндексацию для каждого индекса, а не всей таблицы, включая п.1.  | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: Logger (1). | |
| 
			
			 | 
		#4 | 
| 
			
			 Участник 
		
			
	 | 
	
	|
| 
	
 | 
| 
			
			 | 
		#5 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Сорри за оффтоп, но реально кто-то будет восстанавливать ERP на "3:15 позавчера"?
		 
		
		
		
		
		
		
			
				__________________ 
		
		
		
		
	Ivanhoe as is..  | 
| 
	
 | 
| 
			
			 | 
		#6 | 
| 
			
			 Участник 
		
			
	 | 
	
	|
| 
	
 | 
|
| За это сообщение автора поблагодарили: NetBus (3), БАХ43 (2). | |
| 
			
			 | 
		#7 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
Ну и кто мешает хранить 7 суточных полных за последнюю неделю. У меня они весят при сжатии 8-10гиг 
				__________________ 
		
		
		
		
	Я прибыл к вам из Кантемировской дивизии. А там, как известно, дураков не держат!  
			 | 
| 
	
 | 
| 
			
			 | 
		#8 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Не запускать реиндексацию или запускать пореже(раз в месяц/полгода) https://www.youtube.com/watch?v=iEa6_QnCFMU
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: NetBus (3). | |
| 
			
			 | 
		#9 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
2. после каждого индекса добавить проверку размера лога, если больше положенного, либо засыпать, либо запускать внеочердной бэкап лога, а затем шринк  | 
| 
	
 |