Как бы просмотров & amp; procs, ссылающийся на другую базу данных, вызывает рост журнала?

Question

У меня есть 2 базы данных на одном сервере; давайте назовем их db A и B. База данных A имеет размер около 11 ГБ, база данных B очень мала (155 МБ). База данных B имеет несколько представлений и процедур, которые постоянно обращаются и обновляют данные в базе данных A.

Интересно то, что журнал для базы данных B быстро увеличивается до огромных размеров, я думаю, он вырос до 12 ГБ менее чем за неделю. База данных А не так быстро растет.

Что может стать причиной увеличения моего журнала? Есть ли что-то, что происходит, когда вы выбираете данные из другой базы данных, что приведет к такому росту моего журнала?

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

SQL2000 SP4, версия STD
Модель полного восстановления

Заранее спасибо, Джон

Кстати, я понимаю, что изменение моей модели восстановления на Simple может помочь, но я хотел бы знать, почему это происходит в первую очередь.

Answer 1

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

Однако вы говорите, что «База данных B имеет некоторые представления и процедуры, которые постоянно обращаются к данным в базе данных А. и обновляют их», поэтому даже если базовые данные существуют в базе данных А, поскольку ваше новое приложение подключается к базе данных В и использует его объекты, кажется разумным, что эти операции записаны в журнале B.

Но это только предположение с моей стороны. Почему бы вам просто не проверить журнал транзакций напрямую и не посмотреть, кажется ли он разумным? RedGate имеет бесплатный проводник журналов, работающий с SQL 2000 (см. http: // www .red-gate.com / продукты / SQL_Log_Rescue / index.htm ); Я использовал его только один раз, но, похоже, он работал хорошо, и это действительно спасло мой бекон в этом конкретном случае.

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

Кроме того, Годеке сделал хороший вывод о резервном копировании. Если ваш файл журнала становится слишком большим, делайте резервные копии чаще. Резервное копирование сокращает журнал, но только внутри; то есть процент используемого файла журнала будет уменьшаться, но фактический размер файла на диске не изменится, пока вы не используете для этого DBCC SHRINKFILE.