Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#155<< #156 |
СОДЕРЖАНИЕ
Сокращение времени восстановления баз данных с помощью дифференциальных резервных копий
По материалам статьи Neil Boyle:
Speedy Database Recovery with Differential Backups Дифференциальное (разностное) резервное копирование появилось в MS SQL Server 7.0 и позволяет сократить время восстановления базы данных и журналов транзакций. Что такое дифференциальное копирование?
Дифференциальная копия это запись всех страниц, в которых были сделаны изменения с момента последней, полной копии.
Отличие от резервного копирования журнала транзакций в том, что в разностную копию всегда включаются все изменения
произошедшие с момента создания последней, полной копии базы данных. Таким образом, если у Вас имеется две
дифференциальные копии, одна из которых сделана позже второй, то последняя копия содержит первую и все последующие
изменения. Разработка эффективной стратегии резервирования
Самый простой путь для обеспечения возможности восстановления базы данных на любой момент времени - это регулярное
создание копий журнала транзакций. При этом нужно будет восстановить копию базы данных и последовательность копий
журнала транзакций до заданного момента времени. Технически это правильно, но тогда придется восстановить 11 файлов копий журнала и базы. Можно сделать это значительно проще, используя дифференциальные копии. В следующем примере мы добавим создание дифференциальной копии в 8 часов. Теперь для восстановления базы данных на состояние в 9:30, нам придется восстановить только 4 файла: полную копию базы, дифференциальную и затем копии журналов транзакций, сделанные в 9 и 10 часов.
Дифференциальные копии можно создавать и чаще, т.ч. для восстановления понадобиться только исходный полный бэкап базы,
самый последний разностный бэкап и последующие копии журнала транзакций, позволяющие восстановить базу на любой момент
времени после последнего разностного бэкапа. В приведенном выше примере нам пришлось восстановить только 3 файла. Без использования дифференциальной копии, мы вынуждены были бы восстанавливать все копии журнала транзакций, созданные с 1:00 до 18:00, итого 19 файлов. Расписание бэкапов Я выбрал значения 8:00 и 17:00 для дифференциального копирования в вышеприведенном примере, потому что они более или менее определяют обычный рабочий день. Разумеется, время выполнения резервного копирования у Вас должно быть продиктовано Вашими собственными условиями. Запомните - Вам по прежнему всегда нужно делать копии журнала транзакций! Дифференциальное копирование не дает возможности восстановить базу до состояния на определенный момент времени, таким образом, в вышеприведенных примерах, если мы хотим восстановить базу на 4:00 , нужно восстановить копию базы данных и последовательность журналов транзакций до 4 часов. Дифференциальная копия, созданная в 5 часов содержит нужные нам данные, но поскольку ее внутренняя структура отличается от журнала транзакций, невозможно ее использовать для восстановления базы на определенный момент времени.
Порядок и беспорядок строк в таблице Автор: Александр ДЕНИСЕНКО aden@online.ru, aledin@academy.ru
Говоря о таблице как основном объекте базы данных, зачастую упускается такая подробность, как упорядоченность строк
или отсутствие таковой. Это уточняет семантику операции сравнения таблиц. Равны ли две таблицы, если их состав по
строкам одинаков? Такие вопросы редко задают себе программисты, чаще с этой проблемой сталкиваются дотошные
администраторы (после восстановления базы из архива или перед ним хочется узнать, одинаковы ли две таблицы - в архиве
и базе, двух базах или на двух машинах, участвующих в репликации. Разъяснение
Порядок строк в таблице отслеживается в операциях с курсорами и в сеансовых протоколах сетевых компонент. Передавая
по сети таблицу из десяти строк, машина фактически передаёт (или не передаёт) порядок этих строк. Обычный оператор
выборки строк из таблицы (SELECT) этого порядка не отслеживает. Порядок не отслеживается и обычными протоколами
транспортного уровня операционных систем (например, TCP/IP), хотя на принимающей стороне воссоздаётся порядок пакетов,
хранящихся на передающей стороне - в составе заголовка каждого пакета есть его номер в исходном варианте, так что
принимающая сторона восстанавливает порядок, имевшийся на передающей стороне). А где информация о фактическом порядке
при передаче? При использовании стандартного стека протоколов она уничтожается в момент сборки пакетов принимающей
стороной. Но если воспользоваться сеансовым уровнем протоколов (так называемой семиуровневой модели OSI), то порядок
на принимающей стороне совпадёт с порядком на стороне передающей. А это означает, что можно извлечь достаточно много
информации (например, 5! = 120 вариантов перестановок из пяти пакетов или строк), не искажая и не шифруя содержимого
строк (тем самым не нарушая режима открытой передачи информации). Достаточно лишь знать базовый порядок элементов и
фактически переданный. Статьи на русском языке
Восстановление баз данных Microsoft SQL Server
Новые и обновлённые технические статьи Microsoft
"String Data, Length
Mismatch" Error Message with ODBC Driver for SQL Server If Application
Inserts More Than 400 KB of Text Data
Самые популярные темы недели
Вопрос про оптимизацию запроса к большой таблице
SP3a при установке не принимает пароль sa....в чем фигня..
|
http://subscribe.ru/
E-mail: ask@subscribe.ru |
Отписаться
Убрать рекламу |
В избранное | ||