Резервное копирование журнала транзакций перестало работать, если никакое полное резервное копирование не существует
Выполненный как обычный пользователь, как всегда - и части использования контроля учётных записей для легкого изменения на более высокого привилегированного пользователя при необходимости.
Это не должно несколько отличаться, чем в NT4-XP, работающих как обычный пользователь и использующих руны для изменения на администратора при необходимости - только, что контроль учётных записей делает это намного легче и безаварийным...
Я не вижу, почему Вы выполнили любой корпоративный рабочий стол как администратор значением по умолчанию и использованием контроль учётных записей, чтобы попытаться снизить полномочия, запрашивающие повышение - эта часть контроля учётных записей походит на потребительскую кокетку, пытающуюся сделать что-то о тех потребителях, всегда работающих как администратор без подсказки.
Но уверенный, если Ваша корпоративная политика требует, чтобы они работали как администраторы по некоторым причинам - наличие контроля учётных записей на не причинит боль, на самом деле это поможет таким же образом как с потребителями..., таким образом, на этом лучше всего оставили бы в любом случае.
Тестирование приложений как обычные пользователи является чем-то, что я просто изобразил, всегда делается независимо начиная с NT4...
Да, это - ожидаемое поведение. Для журналов транзакций, чтобы быть полезным, должно быть полное резервное копирование для использования в качестве начальной точки для того, чтобы продвинуться вперед.
Не волнуйтесь об этом слишком много. При создании новой базы данных первый день, Вы получите ту ошибку. Резервные копии журнала для другого DBS успешно выполнятся, как Вы видели, но та ошибка просто заставит его Быть Похожим на шаг, отказавший когда в действительности только тот отказавший DB. Затем той ночью (или каждый раз, когда), это сделает полное резервное копирование. После этого резервные копии журнала сделки будут успешны для нового DB. В основном у Вас были бы один день или ошибки при создании нового DB до прогонов задания полного резервного копирования.
-
1I' ll пытаются не забыть делать резервное копирование сразу - я могу вообразить сценарий, где я игнорирую резервное электронное письмо отказа, думая it' s из-за нового DB - только, чтобы найти по моей стоимости, что была подлинная проблема в другом месте. – CJM 14 October 2009 в 15:51
Я поместил флаг в свой список DBS для резервного копирования, который указывает, что был сохранен. Резервный сценарий не сделает резервных копий Txn, пока он не будет равняться 1. В моем сценарии полного резервного копирования я установил флаг на 1. Престо, больше никаких отказов.