- •1.2.2Типы представлений — до 5 мин.
- •1.2.3Создание представлений — до 25 мин.
- •1.2.4Использование представлений — до 10 мин.
- •1.2.5Изменение и удаление представлений — до 5 мин.
- •1.2.6Индексированные представления — до 5 мин.
- •2.2.2Создание хранимых процедур — до 15 мин.
- •2.2.3Использование параметров — до 15 мин.
- •2.2.4Использование локальных переменных внутри хранимой процедуры — до 15 мин.
- •2.2.5Использование return для возвращаемых значений — до 10 мин.
- •2.2.6Использование select для возвращаемых значений — до 10 мин.
- •2.2.7Управление хранимыми процедурами с помощью t-sql — до 10 мин.
- •3.2.2Когда использовать триггеры —до 10 мин.
- •3.2.3Создание триггеров — до 10 мин.
- •3.2.4Создание триггера типа delete — до 10 мин.
- •3.2.5Создание триггера типа insert — до 5 мин.
- •3.2.6Создание триггера типа update — до 10 мин.
- •3.2.7Создание триггера instead of — до 10 мин.
- •3.2.8Использование триггеров after — до 5 мин.
- •3.2.9Использование вложенных триггеров — до 10 мин.
- •3.2.10Управление триггерами с помощью операторов t-sql — до 5 мин.
- •4.2.2Уровни изолированности — до 10 мин.
- •4.2.3Поведение параллельных транзакций — до 10 мин.
- •4.2.4Режимы транзакций — до 20 мин.
- •4.2.5Вложенные транзакции — до 15 мин.
- •4.2.6Откаты транзакций — до 15 мин.
- •4.2.7Точки сохранения — до 10 мин.
- •5.2.2Уровни блокировок — до 15 мин.
- •5.2.3Режимы блокировки — до 20 мин.
- •5.2.4Блокирование и взаимоблокировки — до 20 мин.
- •5.2.5Подсказки блокировки — до 20 мин.
- •6.2.2Логическая оптимизация запросов — до 20 мин.
- •6.2.3Оптимизация плана исполнения запроса — до 15 мин.
- •6.2.4Подсказки оптимизатору запросов — до 15 мин.
- •6.2.5Оптимизация с использованием sql Server 2000 Index Tuning Wizard и sql Server 2005 Database Tuning Advisor — до 30 мин.
- •7.2.2Режимы аутентификации — до 15 мин.
- •7.2.3Учетные записи и пользователи — до 20 мин.
- •7.2.4Администрирование полномочий доступа к базам данных — до 20 мин.
- •7.2.5Администрирование ролей баз данных — до 10 мин.
- •7.2.6Делегирование учетной записи безопасности — до 15 мин.
- •8.2.2Внедрение sql кода (sql Injection) — до 20 мин.
- •8.2.3Защита sql Server в Интернет — до 20 мин.
- •8.2.4Пример организации системы безопасности приложений — до 40 мин.
- •9.2.2Журнальное протоколирование в sql Server — до 20 мин.
- •9.2.3Контрольные точки — до 15 мин.
- •9.2.4Методы резервного копирования — до 25 мин.
- •10.2.2Слежение за резервным копированием — до 10 мин.
- •10.2.3Планирование резервного копирования — до 25 мин.
10.2.2Слежение за резервным копированием — до 10 мин.
При выполнении резервного копирования (с помощью Enterprise Manager, T-SQL или мастера Create Database Backup Wizard) сохраняется запись об этом резервном копировании. Эта запись сохраняется в виде строки в таблице backupfile базы данных msdb. Во время восстановления данная информация используется, чтобы определить, когда было выполнено последнее резервное копирование для базы данных. Кроме того, сохраняется такая информация, как идентификатор набора резервной копии и имена файлов, сохраненных при резервном копировании. Поэтому важно выполнять периодическое резервное копирование системных баз данных, чтобы можно было при необходимости восстановить эту информацию.
10.2.3Планирование резервного копирования — до 25 мин.
Составление расписаний резервного копирования является весьма субъективной задачей. При разработке расписания требуется учитывать многочисленные факторы. Поскольку во время резервного копирования падает производительность системы, оно должно выполняться только в нерабочее время. Возможно, у вас будет лишь небольшое временное "окно", когда вы можете выполнять резервное копирование. В этом разделе мы предложим несколько советов, которые могут помочь вам в составлении расписания резервного копирования. Не забывайте, что хотя резервное копирование влияет на производительность системы, это критически важная операция, которая должна выполняться для защиты вашей системы от потери данных.
Следующие рекомендации могут помочь вам в составлении "идеального" расписания резервного копирования для вашей системы.
Планируйте выполнение полного резервного копирования в нерабочее время. Если ваша компания не поддерживает непрерывный цикл работы (по 24 часа 7 дней в неделю), то нерабочее время наиболее подходит для резервного копирования.
Разбейте расписание резервного копирования на несколько дней. Если у вас большая база данных и вы не успеваете выполнить резервное копирование в заданное время, разбейте операцию резервного копирования на части. Вы можете за один раз выполнить резервное копирование файла или группы файлов определенной части базы данных. Через несколько дней у вас будет выполнено резервное копирование всех данных.
Используйте разностное резервное копирование. Если у вас нет времени, чтобы выполнять полное резервное копирование каждую ночь, создавайте разностные резервные копии в течение недели, а полную резервную копию – в выходные дни.
Выполняйте настройку плана резервного копирования. Каждая система отличается от других систем, и каждая компания – от других компаний. Разрабатывайте расписание резервного копирования, наиболее отвечающее вашим требованиям.
Вот несколько планов резервного копирования, которые могут помочь вам в разработке ваших собственных расписаний резервного копирования.
Небольшая система в условиях "8 на 5" (8-часовой рабочий день 5 дней в неделю). Этот тип системы обычно позволяет выполнять полное резервное копирование каждый вечер. Журнал транзакций, видимо, нужно копировать только раз в день (в зависимости от размера журнала транзакций и количества выполненных транзакций).
Система среднего масштаба в условиях "24 на 7". Система среднего масштаба, работающая в условиях "24 на 7" не позволяет выделить слишком много времени для резервного копирования. Однако в системе такого масштаба у вас, скорее всего, есть возможность выполнения резервного копирования в выходные дни. В следующей таблице показано, как может выглядеть расписание резервного копирования для компании среднего масштаба.
Понедельник |
Разностное резервное копирование базы данных |
Вторник |
Разностное резервное копирование базы данных |
Среда |
Разностное резервное копирование базы данных |
Четверг |
Разностное резервное копирование базы данных |
Пятница |
Разностное резервное копирование базы данных |
Суббота |
Разностное резервное копирование базы данных |
Воскресенье |
Полное резервное копирование базы данных |
Все дни |
Резервное копирование журнала транзакций по необходимости |
Крупная система в условиях "24 на 7" В очень крупных системах может не оказаться возможности полного резервного копирования хотя бы в один из дней недели. Компромиссное решение – разбить полное резервное копирование на несколько дней, как это показано в следующей таблице. (В приведенном расписании полное резервное копирование выполняется за два дня – в субботу и воскресенье.)
Понедельник |
Разностное резервное копирование базы данных |
Вторник |
Разностное резервное копирование базы данных |
Среда |
Разностное резервное копирование базы данных |
Четверг |
Разностное резервное копирование базы данных |
Пятница |
Разностное резервное копирование базы данных |
Суббота |
Полное резервное копирование базы данных |
Воскресенье |
Полное резервное копирование базы данных |
Все дни |
Резервное копирование журнала транзакций по необходимости |
Эта информация дает вам представление о том, как планировать резервное копирование. Поскольку все системы и требования этих систем отличаются друг от друга, только вы сами можете решить, как наилучшим образом спланировать расписание вашего резервного копирования.
Следующие рекомендации по выполнению резервного копирования, возможно, применимы, а возможно, неприменимы к вашим условиям.
Сохраняйте резервные копии вне рабочего места. Если вы храните резервные копии вне рабочего места, то они, возможно, останутся целы после таких катастроф, как пожар или затопление водой. Данные резервных копий намного важнее, чем сами компьютерные системы.
Проверяйте резервную копию. Резервная копия не будет вечно в хорошем состоянии. Ленты могут портиться, особенно если вы многократно используете одни и те же ленты. Проверяя резервную копию (хотя бы время от времени), вы будете знать, что лента в хорошем состоянии.
Не используйте один и тот же носитель каждый день. Используя один и тот же носитель каждый день, вы не сможете восстановить данные, удаленные за несколько дней до вашей попытки восстановления. Чередуйте ленты с резервными копиями, чтобы иметь возможность восстановления информации хотя бы за несколько дней.
Ведите запись того, как происходит резервное копирование. Вы должны документировать, как выполняется резервного копирования и как восстановить систему при необходимости. Помните, вы не всегда будете на месте, чтобы самому восстановить систему.
Создавайте резервные копии системных таблиц. Не забывайте периодически выполнять резервное копирование системных баз данных, таких как master и msdb.
Эти рекомендации помогут вам в разработке вашей собственной стратегии резервного копирования. Каждая система имеет свои отличия, и потребности каждой компании тоже отличаются. И снова скажем, что вы должны разрабатывать стратегию, которая подходит именно для вас.
