SQL Server: Файл журнала растет все больше, и не становитесь объединенными с файлом MDF
Это кажется, что у Вас есть слишком многие *.jpg файлы в том каталоге для помещения их всех на командную строку сразу. Вы могли попробовать:
find /home/ftpuser/public_html/ftparea1 -name '*.jpg' | xargs -I {} cp -uf {} /home/ftpuser/public_html/ftparea2/
Вы, возможно, должны проверить man xargs чтобы Ваша реализация видела ли -I переключатель корректен для Вашей системы.
На самом деле Вы действительно намереваетесь скопировать те файлы в то же местоположение, где они уже?
Вы берете периодические резервные копии журнала? Как каждые 30 минут? Или начните брать резервное копирование журнала или измените модель восстановления на простой.
Можно всегда видеть reaosn, который содержит журнал resuse в sys.databases, log_reuse_wait_desc столбце:
Описание повторного использования пространства журнала транзакций в настоящее время ожидает на одном из следующего:
- Ничего
- КОНТРОЛЬНАЯ ТОЧКА
- LOG_BACKUP
- ACTIVE_BACKUP_OR_RESTORE
- ACTIVE_TRANSACTION
- DATABASE_MIRRORING
- РЕПЛИКАЦИЯ
- DATABASE_SNAPSHOT_CREATION
- LOG_SCAN
- OTHER_TRANSIENT
Для получения дополнительной информации посмотрите Факторы, Которые Могут Задержать Усечение Журнала.
LDF отслеживает все транзакции, выполненные на файле MDB, не только фактических данных. В результате файл журнала продолжит расти, даже если Вы не вставите новые данные (обновление, и операторы удаления зарегистрированы также), пока Вы не делаете Полное резервное копирование на рассматриваемой базе данных. После того как Вы делаете полное резервное копирование, SQL не должен продолжать все те неактивные транзакции на грани резервного копирования, так как можно просто восстановить от резервного копирования. Затем Вы могли смочь уменьшиться, файл отступают к размеру. Регулярные резервные копии будут препятствовать тому, чтобы Вы имели, чтобы сделать этот последний шаг.
Вот некоторые статьи MS KB для заполнения Вас на некоторых точных шагах, которые можно сделать.
Кроме того, если это - важные данные, прочитайте несколько статей о том, почему Вы не должны делать вещей как усеченный файл журнала или делать резервную опцию no_log. По существу, если Вы не сделали резервного копирования и выполняете одну из этих функций, Вы выбрасываете не имеющие поддержки данные, которые могли использоваться, чтобы помочь восстановить Вашу базу (базы) данных.
Ответить на Ваше первое беспокойство:
Ваш файл базы данных (MDF), вероятно, все еще имеет свободное пространство от, он - начальный размер по умолчанию. База данных обычно имеет свободное пространство в файле, который это использует. В конечном счете это заполнится, и затем Вы будете видеть, что он становится больше (предположение, что Вам включили это). Пока это не достигнет той точки, размер не изменится, даже при том, что данные сохраняются к нему.
Насколько файл журнала идет:
То, что Вы задаете этот вопрос, говорит мне, что Вы не очень знакомы с понятиями восстановления SQL. Вам нужно до мелкого восстановления? Если у Вас будет катастрофический отказ, то Вы будете восстанавливать последнее полное резервное копирование, или Вы будете повторно применять журналы транзакций?
Простое решение Вашей проблемы, если у Вас нет способности правильно управлять или применить журналы транзакций, состоит в том, чтобы установить Вашу базу данных на ПРОСТОЙ режим восстановления. Можно затем в основном забыть о файле журнала (он прекратит выходить из-под контроля).