Практические занятия

по дисциплине
Администрирование Oracle Database 11g I
(10-13)

САНКТ-ПЕТЕРБУРГ
2017
 2

ОГЛАВЛЕНИЕ

ПРАКТИЧЕСКОЕ ЗАНЯТИЕ ПО ТЕМЕ 10 ............................................................................................ 3

ПРАКТИЧЕСКОЕ ЗАНЯТИЕ ПО ТЕМЕ 11 ............................................................................................ 6
11-1: Использование возможностей стандартного аудита .................................................................. 6
11-2: Другие виды аудита ....................................................................................................................... 7
ПРАКТИЧЕСКОЕ ЗАНЯТИЕ ПО ТЕМЕ 12 .......................................................................................... 10
ПРАКТИЧЕСКОЕ ЗАНЯТИЕ ПО ТЕМЕ 13 .......................................................................................... 13
 3
ПРАКТИЧЕСКОЕ ЗАНЯТИЕ ПО ТЕМЕ 10
Управление информацией отмены
Новая версия приложения содержит несколько отчетов, которые используют очень долго
выполняемые запросы. Сконфигурируйте систему для поддержки этих отчетов.
Задачи:
● Подсчитать размер пространства отмены, требуемого для поддержки отчета, который
выполняется два дня.
● Изменить размер табличного пространства типа undo так, чтобы поддерживался период
удержания, требуемый новыми отчетами.
1. В EM перейдите на вкладку Server > Database Configuration > Automatic Undo Management >
System Activity и просмотрите информацию о текущей активности системы, связанной с
использованием пространства отмены (в том числе графики).
A. Были ли замечены ошибки в течение анализируемого периода? Если да, то какие и
сколько?
0

B. Какова длительность наиболее долго выполняющегося запроса?

8,930.0
C. Сколько графиков отображается. Что показывает каждый из них?
Использование табличного пространства UNDO

Время выполнения запроса

Возможности флешбека
 4

D. Может ли система восстановить данные (flashback) на момент времени раньше, чем

был начат наиболее длительный из известных (см. ответ на вопрос B) запросов?
Достаточно ли текущих настроек периода удержания (undo retention) для поддержки
отчёта, выполняемого в течение двух дней? Какой график может помочь ответить
на этот вопрос?
Да
да
Undo retention auto-tuning

2. Перейдите на вкладку General и с помощью консультанта (Undo Advisor) определите размер

пространства отмены, требуемый для поддержки отчета, выполняемого в течение двух дней,
на основе анализируемого периода в последние семь дней.
109МБ
Просмотрите и запишите SQL-команду, которую необходимо выполнить для изменения
периода удержания и затем примените (apply) изменения.
 5

3. Увеличьте размер табличного пространства undo так, чтобы поддерживался период

удержания, требуемый для построения заданных отчётов (к примеру, сделайте 200Мб, если
текущий размер 100Мб). Просмотрите и запишите соответствующую SQL-команду.
A. Какими двумя способами можно увеличить размер табличного пространства?
Увеличить размер файла или настроить авто увеличение файла
B. На результаты каких операций восстановления данных (flashback) могут повлиять
произведённые изменения?
Не записвнные в файл
C. Будут ли доступны имеющиеся данные отмены после перезагрузки экземпляра?

да
 6

ПРАКТИЧЕСКОЕ ЗАНЯТИЕ ПО ТЕМЕ 11

Безопасность БД

11-1: Использование возможностей стандартного аудита

Вас информировали о подозрительной активности в таблице HR.JOBS. Максимальные
зарплаты странным образом меняются. Вы решили провести аудит базы и мониторинг DML-
операций для этой таблицы.
Задачи:
● Настроить аудит базы.
● Настроить мониторинг DML таблицы HR.JOBS.
1. С помощью EM включите стандартный аудит БД: установите XML в качестве значения
параметра AUDIT_TRAIL (Server > Security > Audit Settings > Configuration > Audit Trail).
Запишите соответствующую команду SQL.

Поскольку был изменён статический параметр, перезапустите базу.

2. Перелогиньтесь в EM и сделайте HR.JOBS объектом аудита операций DELETE, INSERT,
UPDATE. Должна записываться сводная информация за сессию.
Запишите соответствующую команду SQL.

3. Создайте пользователя AUDIT_USER, выполнив в SQL*Plus следующий скрипт:

drop user audit_user cascade;
create user audit_user identified by audit_user;
grant connect to audit_user;
grant all on hr.jobs to audit_user;

4. Соединитесь с базой под учётной записью созданного пользователя (AUDIT_USER) и

выполните следующий скрипт:
PROMPT As Audit_user
select * from hr.jobs;
update hr.jobs
set max_salary = max_salary * 10;
commit;
select * from hr.jobs;
 7
5. Теперь подключитесь как HR и выполните следующий скрипт:
PROMPT as HR user
update hr.jobs
set max_salary = max_salary / 10;
commit;
select * from hr.jobs;

6. Наконец, подключитесь как пользователь DBA1 и удалите пользователя AUDIT_USER:

drop user audit_user cascade;

7. Вернитесь в EM просмотрите информацию по объектам аудита (Audit Trails > Audited

Objects).
Можно ли на основе этой информации узнать, какой пользователь увеличил, а какой
уменьшил значение зарплат?
нет

8. С помощью EM удалите настройки аудита для HR.JOBS.

Запишите соответствующую команду SQL.

9. С помощью EM установите значение DB для параметра AUDIT_TRAIL.

Запишите соответствующую команду SQL.

Поскольку Вы изменили статический параметр, перезапустите базу.

Что случится, если поставить для параметра AUDIT_TRAIL значение NONE?

Аудит будет отключен
10. Поскольку Вы закончили аудит, переместите сгенерированные файлы аудита в папку
E:\labs\adump.

11-2: Другие виды аудита

Вы подозреваете, что кто-то просматривает и возможно изменяет оклад сотрудников
(salary) без соответствующих полномочий. Сконфигурируйте базу данных так, чтобы
регистрировать неавторизованный доступ к данным о заработной плате и фиксировать сделанные
в ней изменения.
Задачи
● Проводить аудит запроса столбца SALARY таблицы EMPLOYEES
● Проводить аудит изменений столбца SALARY таблицы EMPLOYEES, регистрируя:
- старое и новое значения; пользователя, сделавшего изменения;
 8
- с какого места было сделано изменение.
1. Необходимо регистрировать доступ пользователей только к столбцу SALARY таблицы
employees. Поэтому следует использовать дифференцированный аудит, а не стандартный
аудит базы данных.
Примечание: для продолжения команды SQL*Plus на следующей строчке используется
символ "-" .
a. В SQL*Plus соединитесь с базой данных как SYS и с помощью пакета DBMS_FGA
добавьте политику дифференцированного аудита для таблицы EMPLOYEES пользователя
HR. Регистрируйте только что кто-то читал столбец SALARY.

b. Проверьте, что записи аудита создают только команды SELECT, содержащие столбец
SALARY.

2. Необходимо регистрировать старое и новое значение столбца SALARY таблицы employees, а

не только операцию изменения. Поэтому следует использовать аудит по значениям, а не
стандартный аудит базы данных. Он производится с помощью триггеров базы данных.
a. Для хранения данных аудита создайте в схеме SYSTEM обычную таблицу
AUDIT_EMPLOYEES с четырьмя столбцами:
who VARCHAR2(25) --Учетная запись пользователя, сделавшего изменения
event_date DATE --Дата и время изменения
ipaddress VARCHAR2(16) --IP-адрес пользователя
what VARCHAR2(2000) --Старое и новое значение в столбце SALARY
 9

b. Создайте триггер для регистрации изменений в столбце SALARY:

--Create a value-based audit trigger to capture changes to the
--salary column of HR's EMPLOYEES table.
--
--Russ Lowenthal, Oracle Server Technologies
--(russ.lowenthal@oracle.com)
CREATE OR REPLACE TRIGGER SYSTEM.HRSALARY_AUDIT
AFTER UPDATE OF SALARY
ON HR.EMPLOYEES
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
--Only capture changes if a change has been made
--to the salary column
IF :OLD.salary != :NEW.salary THEN
--
--Insert information about the change
--into a pre-created holding table. Capture
--The operating system username of the person who made the change
--The IP address the change was made from
--(to trace it back to a particular workstation)
--The primary key (employee ID) of the record that was changed
--The original and changed value for SALARY
insert into system.audit_employees
values (sys_context('USERENV','OS_USER'), sysdate,
sys_context('USERENV','IP_ADDRESS'),
:NEW.employee_id ||' Salary changed from '||:OLD.salary||' to
'||:NEW.salary);
END IF;
END;
/

c. Проверьте, что теперь собирается информация аудита об изменениях в столбце SALARY.

 10

ПРАКТИЧЕСКОЕ ЗАНЯТИЕ ПО ТЕМЕ 12

Раннее обнаружение проблем в ходе эксплуатации системы
Вы хотите выполнять мониторинг базы данных, чтобы устранять типовые проблемы,
прежде чем они окажут неблагоприятное влияние на работу пользователей. Это занятие
моделирует некоторые проблемные ситуации, чтобы Вы могли ознакомиться с инструментами для
их устранения.
Задачи:
1. Создайте новое локально управляемое табличное пространство TBSSPC, содержащее файл
spc1.dbf размером 50MB. Табличное пространство TBSSPC не должно использовать
автоматическое управление пространством сегментов (ASSM).
Для решения этих задач выполните следующий скрипт под учётной записью администратора
(остальные скрипты выполняйте из-под неё же, если не будет сказано иное):
set echo on
drop tablespace TBSSPC including contents and datafiles;
CREATE SMALLFILE TABLESPACE "TBSSPC"
DATAFILE 'spc1.dbf' SIZE 50M
AUTOEXTEND ON NEXT 10M MAXSIZE 200M
LOGGING
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT MANUAL;

2. Создайте нового пользователя SPCT с паролем spct. Установите ему по умолчанию табличное
пространство TBSSPC, а табличное пространство TEMP как временное табличное
пространство. Предоставьте пользователю SPCT роли CONNECT, RESOURCE и DBA.
Выполните следующий скрипт для решения этих задач:
set echo on
drop user spct cascade;
create user spct identified by spct
default tablespace TBSSPC
temporary tablespace temp;
grant connect, resource, dba to spct;

3. Используя пакет DBMS_ADVISOR установите время активности базы данных 30 мин.

Выполните следующий скрипт для решения этих задач:
set echo on
exec dbms_advisor.set_default_task_parameter('ADDM','DB_ACTIVITY_MIN',30);

4. Создайте таблицу SPCT и соберите статистику для неё. При помощи Automatic Workload
Repository (AWR) создайте снимок статистики (snapshot).
Для решения этих задач выполните следующий скрипт под учётной записью SPCT:
drop table spct purge;
create table spct(id number, name varchar2(2000));
exec DBMS_STATS.GATHER_TABLE_STATS(-
 11
ownname=>'SPCT', tabname=>'SPCT',-
estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE);
exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

5. Создайте активность, которая будет проанализирована:

a. создайте файл E:/labs/lab_12_04.bat со следующим содержимым:
FOR /L %%a IN (0,1,14) DO start sqlplus spct/spct @lab_12_04.sql exit
b. сохраните файл и запустите на выполнение.

6. Как пользователь SYSDBA просмотрите страницу Performance в EM. Просмотрите

информацию по производительности в реальном времени с 15-секундным периодом
обновления. Через некоторое время Вы должны увидеть пик на графике “Average Active
Session”, примерно такой как показано на рисунке ниже:

Эта та активность, которую надо проанализировать. Глядя на график, Вы уже можете

определить, что основные проблемы вызывает параллельный доступ к данным (concurrency).
После того, как пик полностью закончится, выполните следующий скрипт под учётной
записью SPCT - для сброса нового снимка статистики (snapshot) в AWR и сбора статистики по
таблице:
set echo on
exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();
exec DBMS_STATS.GATHER_TABLE_STATS(-
ownname=>'SPCT', tabname=>'SPCT',-
estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE);

7. Перейдите по ссылке Advisor Central в нижней части странице. В секции Advisor Tasks
найдите задачу с типом ADDM, которая была выполнена после создания снэпшота на
предыдущем шаге. Нажмите на имя задания (или на кнопку View Result) для просмотра
результатов анализа производительности (Performance Analysis) в порядке степени их
воздействия на систему.

8. Просмотрите рекомендации по результатам анализа (findings), оказавшим наибольшее

влияние на систему и попробуйте сделать вывод о причинах проблем с производительностью.
 12
Если при выполнении п.5 была создана достаточная нагрузка, Вы должны среди прочих
увидеть результаты со следующими названиями: “Top SQL Statements”, “Buffer Busy - Hot
Objects” и “Buffer Busy - Hot Blocks” в столбце Findings.
В рекомендациях для результата с названием “Buffer Busy - Hot Objects” Вы должны увидеть,
что он относится к категории Schema, а также увидеть предложение использовать
возможности Automatic Segment Space Management (ASSM) для табличного пространства,
содержащего таблицу SPCT.
Замечание: если Вы не видите предложенных результатов, скорректируйте количество
запусков скрипта (итераций цикла) в файле lab_12_04.bat (например, до 20) и/или количество
итераций PL/SQL-цикла в файле lab_12_04.sql (например, до 40000). Будьте осторожны, чтобы
не сгенерировать слишком большую нагрузку.

9. Для осуществления рекомендаций Вы должны пересоздать табличное пространство. Создайте

новое локально управляемое табличное пространство TBSSPC2 c файлом данных spc2.dbf
размером 50MB. Убедитесь, что пространство TBSSPC2 использует возможности ASSM.

Затем под учётной записью SPCT выполните следующий скрипт для того, чтобы удалить
таблицу SPCT , пересоздать ее в новом табличном пространстве, собрать по ней статистику и
сбросить новый снимок (snapshot) в AWR:
set echo on
drop table spct purge;
create table SPCT(id number, name varchar2(2000)) tablespace TBSSPC2;
exec DBMS_STATS.GATHER_TABLE_STATS(-
ownname=>'SPCT', tabname=>'SPCT',-
estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE);
exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

10. Создайте нагрузку, снова запустив скрипт lab_12_04.bat.

11. Повторите п.6-7 для просмотра результатов анализа ADDM. Вы увидите, что какие-либо
относящиеся к схеме рекомендации отсутствуют. Переместив таблицу SPCT в локально
управляемое табличное пространство TBSSPC2, которое использует возможности Automatic
Autoextend Segment, Вы, очевидно, устранили проблемы производительности, связанные с
параллельным доступом к данным.

12. Не переходите к выполнению следующих заданий, не выполнив следующий скрипт для

очистки Вашего окружения:
drop user spct cascade;
drop tablespace tbsspc including contents and datafiles;
drop tablespace tbsspc2 including contents and datafiles;
 13

ПРАКТИЧЕСКОЕ ЗАНЯТИЕ ПО ТЕМЕ 13

Мониторинг производительности
Пользователи жалуются на более медленную, чем обычно, работу приложений "Кадры"
(human resources - HR) и "Ведение заказов" (оrdег entry - ОЕ). В ходе консультаций с другими
администраторами выяснилось, что недавно проводились работы по сопровождению таблиц
схемы HR. Вам необходимо обнаружить и устранить причины проблем производительности.
Задачи:
● Выявить и восстановить в нормальное состояние непригодные индексы.
● Вручную собрать статистику для схем HR и ОЕ.
● Автоматизировать сбор статистики с использованием планировщика.
● Ознакомиться с полной информацией о производительности экземпляра.
1. В SQL*Plus подключитесь к базе как пользователь DBA1 и выполните обслуживание таблиц в
схеме HR, запустив скрипт E:/labs/lab_13_01.sql.

2. После проведения обслуживания Вы получили обратную связь от пользователей приложения

HR, которые сообщили, что один из запросов теперь занимает больше времени, чем при
обычном выполнении. Этот запрос находится в скрипте E:/labs/lab_13_02.sql. Выполните его
под учётной записью HR.

3. В EM найдите сессию HR, в которой выполнялась команда (Performance > Additional

Monitoring Links > Search Sessions), в информации о сессии найдите информацию о последней
выполненной команде и просмотрите план её выполнения (в виде таблицы). Вы должны
обнаружить, что для получения данных использовался полный просмотр таблицы, несмотря
на то, что поиск производился по значению первичного ключа.

4. Используя EM, проверьте статус индекса для столбца EMPLOYEE_ID таблицы EMPLOYEES
(Schema > Database Objects > Indexes).

5. Обнаружив, что по крайней мере один из индексов таблицы не находится в состоянии VALID,
Вы решаете проверить все индексы. Используя SQL*Plus, как пользователь HR выполните
запрос к представлению словаря данных, содержащему информацию об индексах: выведите
имена таблиц, а также имена и статусы их индексов, которые не имеют статус VALID.

Почему все эти индексы находятся в таблице EMPLOYEES?

6. Используя EM, реорганизуйте все индексы, которые отмечены как UNUSABLE (значения на
странице “Reorganize Objects: Options” оставьте по умолчанию).
После создания задания просмотрите информацию по нему (ссылка View Job Details в
информационном сообщении о создании задания). Обновляйте страницу пока не увидите, что
задание выполнено успешно.

7. Вернитесь к сеансу SQL*Plus, в котором Вы подключены как пользователь HR, и запустите

 14
скрипт lab_13_07.sql для того, чтобы выполнить аналогичный запрос. Затем повторите пункт 3
для того, чтобы увидеть план выполнения последней команды в сессии. Обратите внимание на
изменение в плане.
Какие изменения произошли в плане выполнения и почему?

8. Сгенерируйте рабочую нагрузку на Ваш экземпляр, запустив скрипт lab_13_09.sql как

пользователь DBA1.
Запишите SID _________________

Скрипт может выполняться около 20-ти минут, запустите его в отдельном окне и продолжайте
выполнение заданий, пока он работает.
Замечание: Поскольку этот скрипт генерирует тяжелую нагрузку на процессор и операции
ввода/вывода, Вы можете заметить, что Database Control работает медленнее.

9. Используя EM, посмотрите показатели производительности, дождавшись пика на графике

Average Active Session, и ответьте на следующие вопросы.
Каковы основные категории событий ожидания, судя по графику Average Active Session?

Что является одной из причин ожидания в категории Configuration? Щелкните по ссылке

Configuration для того, чтобы увидеть график.

Вернитесь на предыдущую страницу и нажмите на кнопку Settings. В секции Detail Chart

Settings выберите I/O для Default View и I/O Function для I/O Chart Settings. Нажмите OK.

Определите, какой процесс выполняет больше всего записей на диск.

Просмотрите Top Activity в разделе Additional Monitoring Links. Какая SQL-команда

вызывает наибольшую задержку?

10. Убейте сессию, которая генерировала нагрузку. Используйте значение SID, которое Вы
записали в п.8 на странице Performance > Additional Monitoring Links > Search Session для того,
чтобы определить и убить сессию. После завершения сессии Вы можете заметить резкий спад
активности на графике на странице Top Activity.

11. Соберите статистики для схем HR и ОЕ (Server > Query Optimizer > Manage Optimizer
Statistics).

12. Автоматизируйте сбор статистик так, чтобы статистики для схем ОЕ и HR собирались каждый
вечер. Не забудьте на следующее утро проверить выполнение работы.