Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
#056<< #057 |
СОВЕТ
Особенности не регистрируемых и минимально регистрируемых операций при резервировании и восстановлении transaction log Некоторые операции, которые не регистрируются, минимально регистрируются или предполагают удаление неактивной части transaction log, могут влиять на начатую последовательность резервирований записей transaction log. Эта статья посвящена таким операциям и их воздействию на последующие резервирования или восстановления transaction log. SQL Server 7.0 В зависимости от типа не регистрируемой операции, SQL Server 7.0 может вести себя тремя различными способами при попытке исполнить резервное копирование transaction log после таких операций:
Сценарий 1: Server: Msg 4213, Level 16, State 1, Line 1
Cannot allow BACKUP LOG because file 'dbname' has been subjected to nonlogged updates and cannot be rolled forward. Perform a full
database, or differential database, backup.
-and- Backup or restore operation terminating abnormally. (Резервное копирование или операция восстановления, закончились неверно).
Незарегистрированные операции, которые ведут к этим ошибкам могут быть следующие: Все предшествующие операции подразумевают изменение данных или вставку новых данных. Поскольку новые данные полностью не журналируются, журнал регистрации транзакций не может использоваться для восстановления данных, если после этих операций произойдёт отказа. Полное или разностное резервное копирование базы данных должно быть выполнено прежде, чем возобновится резервное копирование transaction log. Сценарий 2: Попытка выполнить резервное копирование приводит к получению предупреждающего сообщения, и затем исполняется непосредственно резервное копирование transaction log:
There is no current database backup. This log backup cannot be used to roll forward a preceding database backup. (Не найдены
приемлемые резервные копии базы данных. Эта резервная копия записей журнала не может использоваться для отката совместно
с предшествующими резервными копиями базы данных).
- BACKUP LOG WITH TRUNCATE_ONLY Эти операции усекают неактивную часть transaction log без резервирования записей журнала. После усечения журнала, последующие попытки резервирования transaction log возвращают предупреждающее сообщение. SQL Server позволяет продолжать создание резервных копий transaction log. Однако, эти резервные копии transaction log не корректны и не могут быть использованы для восстановления. Следующие сообщения об ошибках возвращаются при попытке восстановить такие резервные копии: Server: Msg 4305, Level 16, State 1, Line 1 This backup set cannot be restored because the database has not been rolled forward far enough. You must first restore all earlier logs before restoring this log. (Этот резервный набор не может быть восстановлен, потому что база данных не была прокручена вперед достаточно далеко. Вы сначала должны восстановить все более ранние файлы регистрации транзакций перед восстановлением этого файла регистрации транзакций).
-and- Backup or restore operation terminating abnormally. (Резервное копирование или операция восстановления, закончилась неправильно) Это поведение полностью соответствует дизайну СУБД. Пользователь, который выполняет любую из предшествующих операций, должен быть уверен в природе операции и последствиях её исполнения. Полное или разностное резервное копирование базы данных должно быть выполнено после запуска любой из указанных выше операций. Сценарий 3:
Резервирование transaction log проходит без предупреждений и других сообщений. SQL Server 2000
В полной recovery model, регистрируется каждое изменение в базе данных. Так, ни в одном из представленных выше сценариев
ошибок не произойдёт. Server: Msg 4208, Level 16, State 1, Line 1 The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE. (инструкция BACKUP LOG не допустима, в то время когда установлена простая recovery model. Используйте BACKUP DATABASE, или измените recovery model, используя ALTER DATABASE).
-and- BACKUP LOG is terminating abnormally. (BACKUP LOG закончился неправильно)
В Bulk-logged модели, минимальная регистрация может быть выполнена для следующих операций, чтобы сэкономить место в
transaction log:
Основное отличие от SQL Server 7.0 в том, что в SQL Server 2000 фактически transaction log можно резервировать после таких,
минимально регистрируемых операций. Резервное копирование журналов не только резервирует журнал, но и резервирует
экстенты, распределённые предшествующими операциям. Поэтому, такие резервные копии могут использоваться для более
позднего восстановления. Однако, Bulk-Logged recovery model позволяет восстанавливать базу данных только до того участка
резервной копии transaction log, когда начнутся записи, относящиеся к оптовым изменениям. Восстановление на заданный момент
времени (Point-in-time) не поддерживается. Кроме того, резервируя журнал, который содержит Bulk-Logged операции, требуется
доступ ко всем файлам данных в базе. Если файлы данных не доступен, окончание transaction log не может быть резервировано, и
все завершённые операции в этом журнале будут потеряны. Последующие операции восстановления, использующие такое резервирование transaction log вызовут сбой со следующими сообщениями об ошибках: Server: Msg 4305, Level 16, State 1, Line 1 The log in this backup set begins at LSN LSNnumber, which is too late to apply to the database. An earlier log backup that includes LSN LSNnumber can be restored. (Журнал этого резервного набора начинается в LSN "LSNnumber", который предполагает слишком позднее обращение к базе данных. Более ранние записи резервного копирования, которые включают LSN "LSNnumber" могут быть восстановлены)
-and- RESTORE LOG is terminating abnormally. Сценарий 3, описанный для SQL Server 7.0 также относится и к SQL Server 2000.
ГОТОВИМСЯ К ТЕСТУ ПО 70-028
ШПАРГАЛКА #10 Продолжение (обзор официального курса Microsoft) Репликация слиянием
В ходе репликации слиянием в схему вносятся изменения в целях предотвращения или разрешения конфликтов. Чтобы репликация
слиянием протекала нормально, SQL Server вносит в схему публикуемой базы данных три важных изменения:
Поскольку сервер поддерживает в базовой таблице несколько триггеров одного типа, триггеры репликации слиянием не мешают
работе триггеров, определяемых приложением, т.е. и те, и другие могут сосуществовать одновременно. Продолжение следует. ПОЛЕЗНОСТИ
Физическая структура данных в SQL Server 7.0
С 1 января 2001 года в издательстве "Русская
редакция" начал выходить журнал
для профессиональных программистов "SQL для профессионалов". Журнал не перенасыщен рекламой и
рассказывает о конкретных методах решения сложных задач.
Подписавшись на журнал, можно собрать хорошую базу знаний.
Журнал содержит также фрагменты программного кода. Более обширные фрагменты кода можно бесплатно скачать с Web-сайта журнала http://newsletter.narod.ru/ Список статей, опубликованный в майском номере журнала "SQL для профессионалов" за 2001 год.
1. И у меня есть .Net! Майкл Оути (Michael Otey)
2. Оптимизация SQL-сервера для полнотекстового поиска. Тони Бэйн (Tony Bain)
3. Анализ качества обслуживания пользователей. Рэнди Рейтер (Randy Reiter)
4. Эффективное применение транзакций. Барри Фридли (Barry Fridley)
5. Портирование журнала в SQL Server 7.0. Рон Толмэйдж (Ron Talmage)
6. Настройка параметров SQL Server 2000. Брайан Найт (Brian Knight)
Информацию о том, где можно приобрести журнал смотрите на: Новые технические статьи Microsoft
Q273813 -
FIX: "Incorrect Syntax near the Keyword 'by' " Error Message with
Column Names of "C", "CA" or "CAS" ФОРУМ SQL.RU: САМЫЕ ПОПУЛЯРНЫЕ ТОПИКИ НЕДЕЛИ
По
поводу "А как же тогда" собственно по теме ФОРУМ SQL.RU: ВОПРОСЫ ОСТАЛИСЬ БЕЗ ОТВЕТА
процедуры ненутрят.
Информация автора рассылки: |
#056<< #057 |
|
http://subscribe.ru/
E-mail: ask@subscribe.ru | Отписаться | Рейтингуется SpyLog |
В избранное | ||