Вопрос или проблема
У нас есть большой журнал транзакций (1,3 ГБ) для относительно простой базы данных SQL Server 2008 (30 МБ). Журнал содержит все обновления с момента, когда БД впервые была введена в эксплуатацию, и (как мы теперь видим) представляет собой ценный источник временных данных, которые будут интересны для нас.
Существует ли способ “воспроизвести” весь этот журнал на аналогичной базе данных (как оригинальная, но с добавленными историческими таблицами и триггерами)?
Таким образом, мы могли бы реконструировать ту же базу данных, но с временными данными, “извлеченными” из журналов. Это ценное знание, которое мы упустили в первый раз, и не следует полагаться на серверные журналы.
ОБНОВЛЕНИЕ
У меня НЕТ никаких проблем с “большими” журналами транзакций. Я НЕ ХОЧУ обрезать журнал. Временная информация, содержащаяся в нем, ценна.
Журналы транзакций содержат бинарные дельты изменений, примененных к базе данных с последнего обрезания журнала; ключевое слово здесь – “бинарный”: они не содержат SQL-запросов или что-то подобное, а на самом деле более сродни бинарным патчам, которые необходимо применять к программе.
По этой причине их можно воспроизвести только на тех физических файлах базы данных, к которым они изначально были связаны; воспроизведение их на другой базе данных (даже с той же схемой) было бы точно таким же, как применение патча к другому исполняемому файлу, для которого он был написан: совершенно невозможно.
Вы также не можете воспроизвести их на той же базе данных, если она изменяется; т.е. вы не можете восстановить базу данных из старой резервной копии, запустить ее, произвести любую модификацию и затем воспроизвести журналы против нее; вы фактически теряете любую возможность воспроизведения журнала, как только полностью запускаете базу данных (даже существует специфический флажок в операциях восстановления SQL Server для этого).
Здесь они говорят:
Обратите внимание, что вы можете сбросить содержимое текущего файла журнала, используя не документированную команду DBCC:
DBCC LOG('<dbname>', [<option>])где
<option>– это целое число от 1 до 4, которое контролирует уровень детализации информации, отображаемой командой DBCC LOG.
Если я сделаю это с одной из моих баз данных, я получу много информации, но не думаю, что этого достаточно для воспроизведения журнала.
В других постах они упоминали эти продукты, которые могут решить ваши проблемы:
После того, как я несколько раз перечитал ваше сообщение… я бы сказал, что вам следует поискать сторонние инструменты анализа журналов.
Если у вас Sql Server 2000, инструмент RedGate SQL Log Rescue бесплатен. Я не искал другие инструменты, но я уверен, что они есть.
Идите и покупайте стороннее программное обеспечение, чтобы получить транзакции, так как RESTORE LOG явно несовместим с вашими изменениями (как было изначально предложено).
Кроме того, вам следовало использовать SQL Server Profiler, если вы действительно хотели бы повторно выполнить множество транзакций. Однако вы плохо спланировали это, так что придется понести расходы.
Вопрос переписан после уточнения
Я проголосовал за то, чтобы перенести это на serverfault.com. Им нужно сказать, что вы неправильно прочитали Backup Log с Truncate_Only: Как медвежья ловушка. Обратите внимание на часть о “только с обрезкой“.
Смотрите “Сжатие баз данных”, которое связано с первой статьей, прочитайте это и поймите. Дело не в том, что вам никогда не следует обрезать свои журналы: дело в том, что вы должны обрезать их только в совокупности с правильным графиком полных резервных копий, резервных копий журналов транзакций и, возможно, дифференциальных резервных копий.
Как только журнал будет надежно сохранен, больше не нужно держать его на диске. Однако я не DBA, и думаю, что вам стоит послушать экспертов, чтобы понять это, поэтому я голосую за перенос.
Ответ или решение
Восстановление данных из транзакционных журналов SQL Server с изменённой схемой базы данных
Введение
Вопрос о восстановлении данных из транзакционных журналов SQL Server, особенно в случае изменений в схеме базы данных, представляет собой сложную задачу. На первый взгляд, возможность воспроизведения изменений, хранящихся в журнале, кажется заманчивой. Однако важно понимать технологии и ограничения, с которыми вы имеете дело.
Понимание транзакционных журналов
Транзакционный журнал в SQL Server является неотъемлемой частью системы управления базами данных. Он хранит все изменения, которые были применены к базе данных с момента последнего резервного копирования или обрезки журнала. Однако данные в журнале записываются в бинарном формате, что усложняет их использование для восстановления или анализа.
Проблема заключается в том, что транзакционные журналы могут быть воспроизведены только на том же экземпляре базы данных, к которому они относятся. Перенос их на базу с изменённой схемой будет эквивалентно попытке применить бинарную патч-образную запись к совершенно иной программе — это просто невозможно.
Ограничения воспроизведения
Важно понимать несколько ключевых ограничений:
- Точная привязка: Логи привязаны к конкретному набору данных и структуры базы данных. Любые изменения в схеме (например, добавление триггеров или таблиц истории) сделают невозможным успешное применение старых журналов.
- Изменение базы данных: Если вы попробуете изменить восстановленную базу данных после её развертывания, а затем применять к ней транзакционные журналы, это также приведет к невозможности воспроизведения данных.
- Недоступность команд: Стандартные команды восстановления, такие как
RESTORE LOG, могут не работать корректно, если база данных была изменена.
Альтернативные методы восстановления
Чтобы извлечь временные данные из транзакционных журналов с учетом действий, изменяющих схему базы данных, рекомендуется рассмотреть использование сторонних инструментов. Некоторые из таких инструментов включают:
- ApexSQL Log: Этот инструмент позволяет анализировать и извлекать транзакционные журналы, что может помочь в извлечении нужных временных данных.
- Redgate SQL Log Rescue: Подходит для старых версий SQL Server и может предоставить информацию о транзакциях, хотя не всегда гарантирует полное восстановление.
Рекомендуемые шаги
- Планирование: Прежде всего, правильно спланируйте стратегию резервного копирования и управления транзакционными журналами, чтобы избежать потерь данных в будущем.
- Использование инструментов: Ищите инструменты, которые могут предоставить доступ к данным в журнале и помочь в их анализе без необходимости прямого нарушения целостности базы данных.
- Обучение и документирование: Убедитесь, что все члены команды осведомлены о наличии и использовании временных данных и транзакционных логов. Это поможет избежать недоразумений в будущем.
Заключение
Хотя желание восстановить данные из трансакционных журналов может быть обоснованным, важно соблюдать осторожность и понимать ограничения данной технологии. Использование подходящих инструментов, тщательное планирование и понимание архитектуры SQL Server – это ключевые элементы успешного восстановления данных.