У нас есть большой журнал транзакций (1,3 ГБ) для относительно простой базы данных SQL Server 2008 (30 МБ). Он (журнал) содержит все обновления с момента первого запуска db в производство и (теперь мы его видим) представляет собой ценный источник временных данных, которые были бы нам интересны.
Можно ли каким-то образом "воспроизвести" весь этот журнал на аналогичной базе данных (например, в оригинале, но с добавленными таблицами истории и триггерами)?
Таким образом, мы могли восстановить ту же базу данных, но с временными данными, «извлеченными» из журналов. Это ценное знание, которое мы упустили в первый раз, и оно не должно зависеть от файлов журнала сервера.
ОБНОВИТЬ
я НЕ возникли проблемы с "большими" журналами транзакций. Я НЕ хочу обрезать журнал. Содержащаяся в нем временная информация очень ценна. (Я искренне надеюсь, что теперь это будет ясно, так как я повторяю это ТРЕТИЙ раз).
«Самым быстрым стрелкам запада», пожалуйста, продолжайте читать после «У нас большой журнал транзакций ...» выше. Я начинаю думать, что на самом деле это МОЯ ОШИБКА, чтобы начать вопрос с этих слов, поскольку, похоже, 80% читателей думают, что вопрос касается усечения журнала.
И всем, кто может пожелать «предложить» другое резервное копирование и усечение журнала в качестве «решения» (кстати, совершенно не учитывается суть), прочтите это.
Журналы транзакций содержат двоичные дельты изменений, примененных к базе данных с момента последнего усечения журнала; ключевое слово здесь - «двоичный»: они не содержат SQL-запросов или чего-то подобного, но на самом деле больше похожи на двоичные исправления, применяемые к программе.
По этой причине их можно воспроизвести только в тех физических файлах базы данных, с которыми они были изначально связаны; воспроизведение их в другой базе данных (даже с той же схемой) было бы точно так же, как применение патча к другому исполняемому файлу, отличному от того, для которого он был написан: невозможно вообще.
Вы также не можете воспроизвести их на тем же база данных, если она будет изменена; т.е. вы не можете восстановить базу данных из старой резервной копии, перевести ее в оперативный режим, внести в нее какие-либо изменения, а затем воспроизвести журналы против нее; вы фактически теряете любую возможность воспроизведения журнала, как только полностью переводите базу данных в оперативный режим (для этого есть даже специальный флаг в операциях восстановления SQL Server).
Вот они говорят:
Обратите внимание, что вы можете сбросить содержимое ток log с помощью недокументированной команды DBCC:
DBCC LOG('<dbname>', [<option>])где
<option>- целое число от 1 до 4, которое контролирует уровень детализации информации, отображаемой DBCC LOG.
Если я сделаю это с одним из моих БД, я получу много информации, но, думаю, недостаточно, чтобы воспроизвести журнал.
В других сообщениях они упоминали эти продукты, которые могут решить ваши проблемы:
Перечитав ваше сообщение несколько раз ... Я бы сказал, вам следует поискать сторонние инструменты анализа журналов.
Если у вас есть Sql Server 2000, Инструмент восстановления журнала RedGate SQL это бесплатно. Я не искал других инструментов, но уверен, что они есть.
Купите стороннее программное обеспечение, чтобы получать транзакции, поскольку RESTORE LOG очевидно, несовместимо с вашими изменениями (как предлагалось изначально).
Кроме того, вам следует использовать SQL Server Profiler, если вы действительно хотите перезапустить кучу транзакций. Однако вы плохо это спланировали, так что вы окажетесь без средств.
Я проголосовал за то, чтобы переместить это на serverfault.com. Они должны сказать вам, что вы неправильно прочитали журнал резервного копирования с помощью Truncate_Only: Like a Bear Trap. Обратите внимание на часть "только с усечением".
См. Раздел «Сокращение баз данных», ссылка на который есть в первой статье, прочтите и поймите. Дело не в том, что вы никогда не должны обрезать свои журналы: вы должны только усекать их вместе с правильным расписанием полных резервных копий, резервных копий журналов транзакций и, возможно, дифференциальных резервных копий.
После надежного резервного копирования журнала больше нет необходимости хранить его на диске. Однако я не администратор баз данных, и я думаю, что вам, возможно, придется послушать экспертов, чтобы понять это, поэтому я голосую за переезд.