Мой файл журнала является слишком большим

Решение под рукой и уже несколько лет, как ясно показывает этот POC . К сожалению, W3C и лоббисты, такие как Джейк Арчибальд, боролись изо всех сил, чтобы препятствовать тому, чтобы это стало доступным :-(

Почему? Я не знаю. Аргумент «cui bono» указывает на поставщиков плагинов, таких как Ionic весь смысл которого, кажется, является фоновой геолокацией.

См. эту ссылку для полной истории.

5
задан Steve Jones 30 January 2009 в 16:34
поделиться

8 ответов

В самых занятых системах необходимо посмотреть на планирование резервных копий журнала в течение дня и затем ночного полного резервного копирования. Это - довольно обычная практика.

4
ответ дан 13 December 2019 в 19:37
поделиться

В некоторых случаях Вы могли бы найти, файл журнала правильно не усечет даже при том, что резервное копирование журнала выполняется. Можно сделать резервное копирование с TRUNCATE_ONLY для проверки его. При выполнении этого, это должно усечь журнал транзакций:

BACKUP LOG dbname WITH TRUNCATE_ONLY

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

DBCC SQLPERF (LOGSPACE)

Информация о длительных транзакциях может быть найдена с помощью:

DBCC OPENTRAN 

Или:

select * from sys.dm_tran_database_transactions 
4
ответ дан 13 December 2019 в 19:37
поделиться

Необходимо скопировать журналы, а также основную базу данных

1
ответ дан 13 December 2019 в 19:37
поделиться

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

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

Стратегия резервного копирования полного восстановления состоит из:

* Database backups.

* Differential backups (optional).

* Transaction log backups.

Я предлагаю, чтобы Вы консультировались со следующей ссылкой Microsoft.

http://msdn.microsoft.com/en-us/library/aa173551 (SQL.80) .aspx

3
ответ дан 13 December 2019 в 19:37
поделиться

Вы могли использовать некоторое вращение журнала, и сохранить только журнал фиксированного количества времени, сказать прошлые 7 дней. Это должно быть более чем достаточно. Или Вы могли сбрасывать журнал каждую ночь, потому что у Вас должен быть он в Вашем резервном копировании.

0
ответ дан 13 December 2019 в 19:37
поделиться

Это должно уменьшить его:

dbcc shrinkfile('databasename_log', 0)
0
ответ дан 13 December 2019 в 19:37
поделиться

Удалить файл журнала?

Править: По-видимому, удаление файла журнала плохо, это - просто просто журнал к SQL-серверу. Я оставляю на виду это для повторения, что не сделать.

-1
ответ дан 13 December 2019 в 19:37
поделиться

попробуйте это:

dump transaction <dbname> with no_log

и затем уменьшите файл журнала путем установки опции автоуменьшения в настройках SQL-сервера или.

Я думаю, что можно использовать dbcc для уменьшения его также, но я не помню синтаксис.

0
ответ дан 13 December 2019 в 19:37
поделиться
Другие вопросы по тегам:

Похожие вопросы: