b)iChecker™;
c)iSwift™;
d)iFolder™.
5.Если в файле обнаружен код, который похож на вредоносный, то этот файл:
a) удаляется;
b) подвергается лечению;
c) проходит повторную проверку; d) отправляется в карантин;
e) сразу же становится доступным для работы; f) нет верного ответа.
6.Если тело или вложение письма содержит вредоносный код, Почтовый Антивирус:
a) передает письмо пользователю; b) удаляет письмо;
c) помещает копию зараженного объекта в резервное хранилище и пытается обезвредить объект;
d) блокирует письмо; e) нет верного ответа.
7.Почтовый Антивирус имеет специальные модули для работы с почтовыми клиентами:
a) «Microsoft Office Outlook»; b) «The Bat!»;
c) «DreamMail»;
d) «Mozilla Thunderbird».
8.Пользователь может настроить ряд параметров WebАнтивируса, направленных на повышение скорости работы компонента, а именно:
a) определить алгоритм проверки; b) определить скорость проверки;
c) сформировать список адресов, содержанию которых пользователь не доверяет;
d) сформировать список адресов, содержанию которых пользователь доверяет;
e) нет верного ответа.
9.Если Web-страница или объект, к которому обращается пользователь, содержат вредоносный код, то Web-Антивирус:
a) разрешает доступ к нему;
466
b)разрешает ограниченный доступ к нему;
c)блокирует доступ к нему;
d)лечит его.
10. Сразу после запуска компьютера Проактивная защита анализирует следующие аспекты:
a)целостность программных модулей установленных на компьютере приложений;
b)каждую попытку изменения файловой системы;
c)действия каждого запускаемого на компьютере приложения;
d)каждую попытку изменения системного реестра;
e)нет верного ответа.
467
Работа 19
КОНТРОЛЬ ВОССТАНОВЛЕНИЯ БАЗЫ ДАННЫХ ПРИ РАЗНЫХ СЦЕНАРИЯХ ПОТЕРИ/ПОВРЕЖДЕНИЯ ФАЙЛОВ, ФИЗИЧЕСКОГО КОПИРОВАНИЯ
И АРХИВИРОВАНИЯ ДАННЫХ
Цель: получение навыков практического решения конкретных задач восстановления базы данных с использованием физических копий и архивированных данных.
ПЛАН ПРОВЕДЕНИЯ РАБОТЫ
1.База данных переведена в режиме noarchivelog (не архивируется). Имеется «холодная» резервная копия файла users01.dbf базы данных. После формирования «холодной» копии выполняется транзакция в схеме пользователя, данные которого находятся в файле users01.dbf. В ходе работы с БД (после выполненной завершенной транзакции) «утерян» файл данных users01.dbf. Требуется восстановить утерянный файл.
2.База данных находится в режиме archivelog (архивируется). Формируем «горячую» резервную копию файла users01.dbf базы данных. После формирования «холодной» копии выполняется транзакция в схеме пользователя, данные которого находятся в файле users01.dbf. В ходе работы с БД (после выполненной завершенной транзакции) «утерян» файл данных users01.dbf. Требуется восстановить утерянный файл.
3.База данных находится в режиме archivelog (архивируется). Выполняется длинная транзакция, в ходе выполнения которой формируется несколько файлов журнализации. Затем происходит внезапная остановка базы данных (shutdown abort), после которой «теряются» незаархивированные оперативные файлы журнализации. Требуется восстановить базу данных с созданием новых файлов журнализации.
ПОРЯДОК ПРОВЕДЕНИЯ РАБОТЫ
1. База данных переведена в режиме noarchivelog (не архивируется). Имеется «холодная» резервная копия файла users01.dbf базы
468
данных. После формирования «холодной» копии выполняется транзакция в схеме пользователя, данные которого находятся в файле users01.dbf. В ходе работы с БД (после выполненной завершенной транзакции) «утерян» файл данных users01.dbf. Требуется восстановить утерянный файл.
Лабораторная работа выполняется копированием нижеприводимых команд и выполнением их в окне SQL*Plus.
Остановим БД, чтобы потом смонтировать ее (startup mount) для обеспечения возможности перевода ее в режим noarchivelog
connect sys/admin1 as sysdba shutdown immediate
startup mount
alter database noarchivelog;
Вот теперь откроем БД alter database open;
Получим справку о режиме архивации archive log list;
Теперь видно, что нет log файла для архивациии. Восстановим к первоначальному «эталонному» виду таблицу
dept, которая могла быть изменена предыдущим выполнением archive_mod.sql;
delete from scott.dept where deptno=1; select * from scott.dept;
commit;
Теперь сформируем «холодную» копию файлa users01.dbf. Копию именно этого файла мы сделаем потому, что далее именно этот файл будет «испорчен» (на самом деле − удален), имитируя неисправность БД, требующую восстановления с использованием «холодной» (полученной в остановленной БД) копии БД. С этим файлом связана tablespace users, которая установлена для пользователя scott при его создании (здесь надо проверить этот факт и пересоздать пользователя scott с default tablespace users, если он был создан с другим по умолчанию табличным пространством).
На самом деле, в эксплуатируемых системах неизвестно заранее, какой файл «откажет», поэтому копируют всю базу целиком (все файлы БД).
Shutdown immediate
469
Далее средствами ОС Windows копируем все файлы в папку d:\cool_copy из папки d:\oracle\product\10.2.0\oradata\orcl на диск с наибольшим объемом свободной памяти. Еще раз запустим базу данных, чтобы затем выполнить в ней изменения. Здесь и далее при выполнении лабораторной работы, возможно, придется учитывать факт другого расположения home_directory Oracle. В этом случае указанные здесь пути необходимо скорректировать.
startup
Выполним новую транзакцию – добавим в таблицу scott.dept новую запись и заФиксируем ее.
insert into scott.dept values(1,'Publication','Moscow'); commit;
select * from scott.dept;
Теперь БД отличается от «холодной» копии, так как добавилась новая транзакция.
shutdown immediate
Сымитируем неисправность файлов с данными, удалим USERS01.DBF средствами ОС Windows из папки
…:\oracle\product\10.2.0\oradata\orcl.
После «порчи» файла данных USERS01.DBF восстанавливаем его из «холодной» копии простым копированием из папки
…:\cool_copy в папку …:\oracle\product\10.2.0\oradata\orcl. Отме-
тим, что мы скопировали файл, в котором нет новой строки в таблице dept пользователя scott.
Мы не стали здесь стартовать БД, чтобы не тратить время. Ясно, что при попытке старта нам будет выдано сообщение об отсутствии файла данных users01.dbf, после чего нам надо будет останавливать БД и копировать резервную копию файла Users01.dbf. Будем полагать, что мы прошли все эти стадии.
Вот теперь, после такого восстановления файла данных
USERS01.DBF стартуем БД. startup
База данных смонтирована, но не открыта. Oracle зарегистрировал расхождение в номере последней транзакции в файле данных из «холодной» копии и в управляющем файле БД, зарегистрировавшем последнюю транзакцию − добавление записи в scott.dept. Из-за этого расхождения Oracle требует восстановления базы данных.
470