Замечание. В зависимости от того, когда Вы запустили нагрузку, Вы можете увидеть различающиеся результаты.
После того, как пик прошел, выполните скрипт lab_12_09.sql. (Скрипт lab_12_09.sql идентичен скрипту lab_12_05.sql). Этот скрипт форсирует создание нового снимка и сбор статистики на Вашей ADDM таблицы.
10. Проанализируйте раздел Performance Analysis на странице Database Home. Используйте для этого информацию из последней ADDM задачи.
Вы увидите, что какие-либо относящиеся к схеме рекомендации отсутствуют. Переместив таблицу ADDM в локально управляемое табличное пространство TBSADDM2, которое использует возможности Automatic Autoextend Segment, Вы очевидно устранили причину, вызвавшую проблему.
11. Не переходите к выполнению следующих заданий, не выполнив скрипт lab_12_11.sql для очистки Вашего окружения.
Описание ситуации. Пользователи жалуются на более медленную, чем обычно, работу приложений "Кадры" (human resources - HR) и "Ведение заказов" (оrdег entry - ОЕ). После консультаций с другими администраторами выяснилось, что недавно проводились работы по сопровождению таблиц схемы HR. Вам необходимо обнаружить и устранить причины проблем производительности.
Задачи:
• Выявите и восстановите в нормальное состояние непригодные индексы.
• Вручную соберите статистики для схем HR и ОЕ.
• Автоматизируйте сбор статистик с использованием планировщика.
• Просмотрите полностью данные о производительности экземпляра.
1. Подключитесь в SQL*PLUS как пользователь DBA1 и выполните обслуживание таблиц в схеме HR, запустив скрипт lab_13_01.sql.
2. Вы получаете отклик от пользователей приложения HR, который говорит, что запрос занимает больше времени, чем при обычном выполнении. Этот запрос находится в скрипте lab_13_02.sql. Выполните его.
3. Используя Enterprise Manager, выберите сессию HR, в которой выполнялась команда, и просмотрите для этой команды план выполнения (Performance > Search Sessions).
4. Используя Enterprise Manager, проверьте статус индекса на столбце EMPLOEEE_ID таблицы EMPLOYEES. Индекс может находиться или в состоянии или VALID, или INVALID. (Administration > Indexes).
5. Теперь, увидев, что один индекс не находится в состоянии VALID, Вы решаете проверить все индексы. Используя SQL*PLUS, Вы как пользователь HR решаете найти все индексы в схеме HR, которые не имеют статус VALID. Для того, чтобы решить эту задачу, сделать запрос к представлению словаря данных с условием на колонку статус.
6. Используя Enterprise Manager, реорганизуйте все индексы, которые отмечены как UNUSABLE.
7. Вернитесь к сеансу SQL*PLUS, в котором Вы подключены как пользователь HR, и запустите скрипт lab_13_07.sql для того, чтобы выполнить аналогичный запрос. Затем повторите шаги для того, чтобы увидеть план выполнения последней команды в сессии. Обратите внимание на изменение в плане.
8. Какие изменения произошли в плане выполнения и почему?
9.Промоделируйте рабочую нагрузку на Ваш экземпляр, запустив скрипт lab_13_09.sql как пользователь DBA1. Запишите величину SID для задачи 10.
Скрипт будет выполняться минут 20. Так что запустите его в отдельном окне и продолжайте выполнение заданий, пока он работает.
Замечание: Поскольку этот скрипт генерирует тяжелую нагрузку на процессор и операции ввода/вывода, Вы можете заметить, что Database Control работает медленнее.
Используя Enterprise Manager, посмотрите показатели производительности, дождавшись пика на графике Average Active Session, и ответьте на следующие вопросы.
Вопрос 1: Какие две главные категории находятся в состоянии ожидания, судя по графику Average Active Session?
Вопрос 2: Что является одной из причин ожидания в категории Configuration? Щелкните по ссылке Configuration для того, чтобы увидеть график.
Вопрос 3: Просмотрите параметр Physical Writes на графике Instance Disk I/O. Определите, какой процесс выполняет больше всего записей на диск.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.