/
ISBN: 0-07-223145-9
Текст
ORACLG
ORACLE PRESS™ — ЭКСКЛЮЗИВНО ОТ McGRAW-HILL/OSBORNE
ORACL^lOg
Настольная книга
администратора баз данных
Управление надежной
и высокопроизводительной базой данных
КЕВИН ЛУНИ
Старший консультант по техническому управлению в компанииTUSC, атакжеавтор бестселлеров издательства Oracle Press
БОБ БРИЛА
Аналитик баз данных в Интернете, а также АБД Oracle в компании Land's End
и
ORIGINAL • AUTHENTIC
Oracle Press1
ONLY FROM OSBORNE
Oracle Press
Oracle Database 10g andbook
4.
Kevin Loney
Bob Bryla
and the experts at TUSC
McGraw-Hill/Osborne
New York Chicago San Francisco
Lisbon London Madrid Mexico City Milan
New Delhi San Juan Seoul Singapore Sydney Toronto
Oracle Database 10g Настольная книга администратора баз данных
Кевин Луни
Боб Брила и эксперты TUSC
Издательство «Лори»
Oracle Database 1Og
DBA Handbook
Kevin Loney
Bob Bryla
and the experts at TUSC
Copyright © 2005 by The McGraw-Hill Companies, Inc. (Publisher)
All rights reserved
ISBN 0-07-223145-9
Oracle Database 1Од Настольная книга администратора баз данных
Кевин Луни
Боб Брила и эксперты TUSC
Переводчик М, Горелик
Научный редактор А. Головко
Корректор Л. Белая
Верстка Ю. Кунашовой
© Издательство “Лори”, 2008
Изд. № : OAI (03)
ЛР№: 07612 30.09.97 г.
ISBN 978-5-85582-293-9
Подписано в печать 10.01.2008 Формат 70 х 100/16
Гарнитура Баскервиль Печать офсетная
Печ. л. 47 Тираж 1000 Заказ № 06
Цена договорная
Издательство “Лори”
123100, Москва, Шмитовский пр., д. 13/6, стр. 1
Телефон для оптовых покупателей: (495)256-09-83
Размещение рекламы: (495)259-01-62
www.lory-press.ru
Отпечатано в типографии ООО “Тиль-2004” 107023, Москва, ул. Электрозаводская, д. 21
Сью, Эмили, Рэйчел и Джейн за их любовь и поддержку.
-К. Л.
Моей домашней банде: наконец-то в этом году нам хватило снега, чтобы слепить снеговика... будем ждать следующего.
-Б. Б.
5
Об авторах
Содержание
Благодарности ...................................................
XIX
Кевин Луни, главный консультант в области технического управления компании TUCS, является признанным во всем мире экспертом в области проектирования, разработки, администрирования и настройки баз данных Oracle. Являясь разработчиком и администратором баз данных Oracle с 1987 г., он занимался реализацией как транзакционных систем, так и хранилищ данных. Он обеспечивает экспертную помощь компаниям в реализации и настройке приложений Oracle, стратегически важных для ведения их бизнеса.
Луни является автором многочисленных технических статей и ведущим автором таких бестселлеров, как “Oracle 10g: Полный справочник”. Он регулярно участвует в конференциях групп пользователей Oracle в Северной Америке и в Европе, а в 2002 г. журнал Oracle Magazine назвал его лучшим консультантом года.
Боб Брила является сертифицированным профессионалом в области баз данных Oracle (версии 8,8i, 9i и 10g) с более чем 15-летним опытом проектирования и администрирования баз данных, а также разработки приложений баз данных. Он является основным проектировщиком базы данных для Интернета и АБД Oracle в компании Land’s End в городе Доджвилль, шт. Висконсин.
В свободное время он занимается техническим редактированием книг издательств Oracle Press и Sybex и, кроме того, является автором нескольких учебных пособий по сертификации для Огас1е9г и OraclelOgB издательстве Sybex.
Введение .......................................
ЧАСТЬ I АРХИТЕКТУРА БАЗЫ ДАННЫХ
Глава 1. Знакомство с архитектурой Oracle ............................
Обзор баз данных и экземпляров...............................
Базы данных.............................................
Экземпляры . . ................-........................
Логические структуры памяти Oracle...........................
Табличные пространства..................................
Блоки ...............................................
Экстенты................................................
Сегменты ...............................................
Логические структуры базы данных Oracle......................
Таблицы..............................................
Ограничения целостности.................................
Индексы...............................................
Представления...........................................
Пользователи и схемы ...................................
Профили........................................
Последовательности ...................................
Синонимы...............................
PL/SQL.................... ... . ........... ..
Доступ к внешним файлам.................................
Связи баз данных и удаленные базы данных................
Структуры физического хранения Oracle........................
Файлы данных...............................
Файлы журнала...........................
Управляющие файлы.............................
Архивные файлы журналов базы данных Файлы параметров инициализации Сигнальный файл ALERT и файл трассировки
2
3
3
4
4
4
6
6
6
8
8
17
20
23
26
26
26
27
27
29
30
31
31
32
33
33
34
35
Содержание
•
VIII
Файлы резервных копий........................................... 36
Файлы, управляемые сервером Oracle.............................. 36
Файлы паролей................................................... 36
Мультиплексирование файлов базы данных............................... 37
Автоматизированное управление памятью........................... 37
Ручное мультиплексирование...................................... 38
Структуры памяти Oracle.............................................. 40
Системная глобальная область.................................... 41
Программная глобальная область.................................. 44
Область программного кода....................................... 44
Фоновые процессы................................................ 45
Обзор средств резервного копирования и восстановления информации . . 48
Экспорт/Импорт.................................................. 48
Автономное копирование.......................................... 49
Оперативное резервное копирование............................... 49
RMAN............................................................ 49
Средства безопасности................................................ 50
Привилегии и роли .............................................. 50
Аудит........................................................... 51
Детальный аудит ................................................ 52
Виртуальная приватная база данных............................... 52
Label Security ................................................. 52
Real Application Clusters............................................ 52
Oracle Streams ...................................................... 53
Oracle Enterprise Manager ........................................... 54
Параметры инициализации Oracle....................................... 54
Основные параметры инициализации................................ 54
Дополнительные параметры инициализации.......................... 60
Инсталляция программного обеспечения................................. 60
Обзор опций лицензирования и инсталляции ....................... 63
Использование OUI для инсталляции программного обеспечения Oracle................................................... 63
Применение DBCA для создания базы данных ....................... 64
Создание базы данных вручную.................................... 80
Глава 2. Апгрейд до Oracle Database 10g....................... 85
Выбор метода апгрейда................................................ 86
Перед переходом...................................................... 88
Использование DBUA................................................... 88
Выполнение прямого «ручного» апгрейда................................ 90
Использование утилит Export и Import................................. 93
Версии утилит Export и Import, которыми надлежит пользоваться .• 93
Содержание
ix
Выполнение апгрейда.......................................... 94
Использование метода копирования данных........................... 95
После перехода.................................................... 96
Глава 3. Планирование табличных пространств и управление ими .............. 97
Архитектура табличного пространства............................... 97
Типы табличных пространств................................... 98
Оптимальная гибкая архитектура.............................. 104
Табличные пространства инсталляции Oracle........................ 109
SYSTEM ..................................................... 110
SYSAUX ..................................................... 110
TEMP........................................................ 110
UNDOTBS1.................................................... 110
USERS....................................................... 111
EXAMPLE..................................................... 111
Разделение сегментов............................................. 111
Глава 4. Физическая компоновка базы данных и управление хранением..... 115
Традиционноехранение дисковой памяти............................. 115
Изменение размеров табличных пространств и файлов данных . . 116
Перемещение файлов данных................................... 131
Перемещение оперативных файлов журналов базы данных .... 135
Перемещение управляющих файлов.............................. 137
Среда автоматического управления хранением данных................ 139
Архитектура ASM............................................. 139
Создание экземпляра ASM..................................... 140
Компоненты экземпляра ASM .................................. 142
Динамические представления производительности ASM....... 144
Форматы имен файлов ASM..................................... 145
Типы файлов и шаблоны ASM................................... 147
Администрирование дисковых групп ASM........................ 150
ЧАСТЬ II УПРАВЛЕНИЕ БАЗОЙ ДАННЫХ
Глава 5. Разработка и реализация приложений............................... 160
Преднамеренная настройка: практические советы.................... 160
Делайте как можно меньше ................................... 161
Делайте все как можно проще................................. 165
Укажите базе данных, что ей необходимо знать................ 167
Максимизируйте пропускную способность среды ................ 168
Разделяйте свои данные и властвуйте над ними................ 171
Тестируйте правильно........................................ 172
X
Содержание
Стандартный комплект поставки.............................. 175
Управление ресурсами и хранимые схемы плана выполнения .......... 178
Реализация диспетчера ресурсов базы данных................. 178
Реализация хранимых схем плана выполнения.................. 183
Определение размера объектов базы данных................... 187
Использование временных таблиц............................. 196
Поддержка таблиц, основанных на абстрактных типах данных....... 196
Использование объектных представлений...................... 197
Вопросы безопасности для абстрактных типов данных........ 201
Индексирование атрибутов абстрактных типов данных........ 203
«Замораживание» и «подвешивание» базы данных..................... 204
Поддержка итеративной разработки ................................ 206
Итеративные описания столбцов.............................. 206
Принудительное разделение курсоров......................... 208
Управление разработкой пакетов................................... 208
Генерация диаграмм ........................................ 208
Требования к дисковому пространству ....................... 209
Задачи настройки........................................... 209
Требования безопасности.................................... 209
Требования к данным . . ................................... 210
Требования к версии ....................................... 210
Планы выполнения........................................... 210
Процедуры приемочных испытаний............................. 210
Среда тестирования......................................... 211
Глава 6. Мониторинг использования дискового пространства.................. 213
Часто встречающиеся проблемы управления дисковым пространством.................................................... 214
Недостаток свободного места в табличном пространстве..... 214
Недостаток места для временных сегментов................... 215
Выделено слишком много или слишком мало места для пространства отката..................................... 215
Фрагментированные табличные пространства и сегменты данных...................................................... 216
Сегменты, экстенты и блоки Oracle................................ 217
Блоки данных............................................... 217
Экстенты................................................... 219
Сегменты................................................... 220
Представления словаря данных и динамические представления производительности .............................................. 221
DBA_TABLESPACES ........................................... 221
DBA_SEGMENTS............................................... 222
Содержание
xi
DBA_EXTENTS................................................ 223
DBA_FREE_SPACE............................................. 223
DBA_LMT_FREE_SPACE......................................... 224
DBA_THRESHOLDS ........................................... 224
DBA_OUTSTANDING_ALERTS..................................... 225
DBA_ALERT_HISTORY.......................................... 225
V$ALERT_TYPES.............................................. 225
V$UI\IDOSTAT .............................................. 226
V$OBJECT_USAGE............................................. 226
V$SORT_SEGMENT ............................................ 226
V$TEMPSEG_USAGE............................................ 226
Методики управления дисковым пространством...................... 227
Локально управляемые табличные пространства................ 227
Использование OMF для управления дисковым пространством . . 229
Табличные пространства типа Bigfile........................ 230
Среда автоматического хранения данных...................... 232
Анализ управления пространством отката..................... 234
Мониторинг и использование табличного пространства SYSAUX.... 236
Управление файлами архивных журналов базы данных................ 238
Встроенные инструменты управления дисковым пространством..... 238
Консультант по сегментам................................... 239
Утилита Undo Advisor и Automatic Workload Repository.... 242
Использование индексов . . г............................... 246
Уровни предупреждений об использовании дискового пространства .............................................. 247
Возможность продолжения операций после устранения проблем с ресурсами................................................ 250
Управление дисковым пространством средствами операционной системы.................................................... 252
Сценарии управления дисковым пространством...................... 253
Сегменты, в которых не могут быть выделены дополнительные экстенты .................................................. 253
Использованное и свободное пространство в табличных пространствах и файлах данных.............................. 254
Автоматизация и упрощение процесса уведомления.................. 255
Использование DBMS_SCHEDULER .............................. 255
Управление заданиями и мониторинг в OEM ................... 255
Глава?. Управление транзакциями с помощью табличных пространств отката . . . 263
Основные сведения о транзакциях................................. 264
Основные сведения о пространствах отката........................ 265
Откат...................................................... 265
Содержание
XII
Согласованность чтения ...................................... 265
Восстановление базы данных .................................. 266
Ретроспективные операции..................................... 266
Управление табличными пространствами отката........................ 266
Создание табличных пространств отмены........................ 267
Динамические представления производительности для табличного пространства отката............................ 274
Параметры инициализации табличного пространства отката. . . . 274
Множественные табличные пространства отката.................. 276
Определение размера табличного пространства отката и его мониторинг.............................................. 279
Согласованность чтения против успешности DML ................ 282
Flashback-опции ................................................... 283
Flashback Query.............................................. 283
DBMS_FLASHBACK .............................................. 285
Flashback Table............................................. 287
Flashback Version Query...................................... 293
Flashback Transaction Query.................................. 296
Миграция в среду автоматического управления пространством отката. . 299
Глава 8. Настройка базы данных.............................................. 300
Проектирование настройки приложения................................ 301
Эффективное проектирование таблиц............................ 301
Распределение требований к центральному процессору........ 302
Эффективное проектирование приложения........................ 305
Настройка SQL...................................................... 306
Влияние упорядоченности на скорость загрузки................. 307
Дополнительные возможности индексирования.................... 308
Генерация планов выполнения.................................. 310
Настройка использования памяти..................................... 313
Определение размера SGA...................................... 316
Использование оптимизатора по стоимости...................... 317
Настройка доступа к данным ........................................ 318
Локально управляемые табличные пространства.................. 318
Идентификация расщепленных строк............................. 319
Увеличение размера блока Oracle.............................. 321
Использование индекс-таблиц.................................. 322
Настройка манипулирования данными.................................. 323
Массовые вставки: использование в SQL*Loader опции загрузки в прямом режиме .............................................. 323
Пересылки больших массивов данных — использование внешних таблиц ............................................... 325
Содержание
XIII
Массовые вставки: распространенные ловушки и успешные трюки....................................................... 326
Массовые удаления: команда усечения (truncate)............. 328
Использование разделов..................................... 329
Настройка физического хранения................................... 330
Использование “чистых" дисков............................. 330
Снижение сетевого трафика........................................ 331
Тиражирование данных....................................... 331
Использование удаленных вызовов процедур................... 333
Использование пакета STATSPACK и автоматически управляемого репозитория рабочей нагрузки..................................... 334
Управление мгновенными снимками............................ 335
Управление опорными планами................................ 335
Генерация отчетов AWR...................................... 336
Выполнение отчетов автоматического диагностического монитора базы данных................................................. 336
Решения по настройке............................................. 337
Глава 9. Применение пакета STATSPACK...................................... 339
Инсталляция STATSPACK ........................................... 339
Безопасность учетной записи PERFSTAT....................... 340
После установки............................................ 340
Сбор статистических показателей.................................. 341
Генерация отчета о статистических показателях.................... 345
Управление данными утилиты STATSPACK............................. 350
Деинсталляция утилиты STATSPACK.................................. 351
Глава 10. Защита и аудит базы данных...................................... 352
Защита вне базы данных........................................... 353
Методы аутентификации базой данных............................... 355
Аутентификация базой данных................................ 355
Аутентификация администратора базы данных.................. 355
Аутентификация операционной системой....................... 358
Сетевая аутентификация................................... 359
Трехуровневая аутентификация .............................. 361
Аутентификация на клиентской стороне....................... 362
Oracle Identity Management................................. 362
Учетные записи пользователей............................... 364
Методы авторизации базы данных................................... 369
Управление профилями....................................... 369
Системные привилегии....................................... 376
Объектные привилегии....................................... 379
Создание, назначение и обслуживание ролей.................. 384
xiv
Содержание
Использование VPD для реализации правил разграничения доступа в приложении (Application Security Policies).............. 392
Аудит....................................................... 411
Местоположение информации аудита............................ 412
Аудит операторов............................................ 413
Аудит привилегий............................................ 417
Аудит объектов схемы . . ................................... 418
Детальный аудит ............................................ 419
Связанные с аудитом представления словаря данных......... 421
Защита журнала аудита....................................... 422
Методы кодирования данных......................................... 422
ЧАСТЬ III
ВЫСОКАЯ ДОСТУПНОСТЬ
Глава 11. Real Application Clusters........................................ 424
Обзор Real Application Clusters................................... 425
Аппаратная конфигурация..................................... 425
Софтверная конфигурация..................................... 426
Конфигурация сети........................................... 426
Дисковая память ............................................ 427
Инсталляция и настройка........................................... 428
Конфигурация операционной системы .......................... 429
Инсталляция программного обеспечения........................ 433
Характеристики базы данных RAC.................................... 457
Характеристики файла параметров сервера..................... 457
Параметры инициализации, относящиеся к RAC.................. 458
Динамические представления производительности .............. 458
Обслуживание RAC.................................................. 460
Запуск базы данных RAC...................................... 460
Журналы базы данных в среде RAC............................. 461
Табличные пространства отката в среде RAC................... 461
Сценарии восстановления после сбоя и TAF.................... 462
Сценарий выхода из строя узла RAC........................... 463
Создание нового экземпляра Oracle........................... 468
Настройка базы данных узла RAC.............................. 470
Управление табличными пространствами........................ 470
Глава 12. Опции резервного копирования и восстановления.................... 472
Возможности....................................................... 472
Логическое резервное копирование.................................. 473
Процесс Data Pump Export/lmport............................. 473
Физическое резервное копирование.................................. 473
Содержание
XV
Автономное резервное копирование........................... 474
Оперативное резервное копирование.......................... 474
Использование утилит Data Pump Export и Data Pump Import....... 476
Создание каталога.......................................... 476
Опции Data Pump Export..................................... 477
Запуск задания Data Pump Export............................ 479
Опции Data Pump Import........................................... 484
Запуск задания Data Pump Import ........................... 487
Сравнение Data Pump Export/lmport c Export/lmport.......... 491
Реализация автономного резервного копирования.............. 491
Реализация оперативного резервного копирования ............ 493
Интеграция процедур резервного копирования ...................... 497
Интеграция логического и физического резервного копирования . 497
Интеграция процедур резервного копирования базы данных и операционной системы ..................................... 499
Глава 13. Использование диспетчера восстановления (RMAN) ................. 500
Возможности и компоненты RMAN.................................... 501
Компоненты RMAN............................................ 501
RMAN против традиционных методов резервного копирования . . 503
Типы резервных копий....................................... 505
Обзор команд и опций RMAN........................................ 507
Часто используемые команды................................. 507
Настройка репозитория...................................... 509
Регистрация базы данных.................................... 510
Сохранение настроек RMAN .................................. 512
Параметры инициализации.................................... 516
Представления словаря данных и динамические представления производительности ......................................... 517
Операции резервного копирования.................................. 519
Полное резервное копирование базы данных................... 519
Табличное пространство..................................... 523
Файлы данных............................................... 525
Копии-отображения.......................................... 525
Резервное копирование управляющего файла и SPFILE........ 526
Архивные журналы базы данных............................... 528
Инкрементальное резервное копирование...................... 528
Инкрементально обновляемые резервные копии................. 531
Отслеживание изменения блоков при инкрементальном резервировании ............................................. 534
Компрессирование резервной копии........................... 536
Использование Flash Recovery Area ......................... 537
xvi
Содержание
Проверка достоверности резервных копий..................... 538
Операции восстановления.......................................... 539
Восстановление носителя на уровне блоков................... 540
Восстановление управляющего файла.......................... 541
Восстановление табличного пространства..................... 541
Восстановление файла данных................................ 544
Восстановление всей базы данных............................ 545
Проверка допустимости операций восстановления.............. 549
Восстановление на определенный момент в прошлом.......... 551
Разнообразные операции........................................... 552
Каталогизация других резервных копий....................... 553
Обслуживание каталога восстановления ...................... 553
Команды REPORT и LIST...................................... 556
Глава 14. Технология Oracle Data Guard.................................... 558
Архитектура Oracle Data Guard.................................... 558
Физические резервные базы данных в сравнении с логическими . 559
Режимы защиты данных....................................... 560
Атрибуты параметра LOG_ARCHIVE_DEST_n............................ 561
Создание конфигурации резервной базы данных...................... 563
Подготовка основной базы данных ........................... 564
Создание логических резервных баз данных................... 568
Применение real-time Apply....................................... 571
Управление пропусками в последовательности архивных журналов.................................................... 572
Управление ролями — плановые и внеплановые переключения........ 573
Плановые переключения...................................... 573
Плановое переключение к физической резервной базе данных . . 574
Плановые переключения к логическим резервным базам данных. . 575
Внеплановые переключения к физической резервной базе данных ................................................ 576
Внеплановые переключения к логической резервной базе данных ................................................ 577
Администрирование баз данных..................................... 578
Запуск и остановка физической резервной базы данных ....... 578
Управление файлами данных в среде Data Guard............... 579
Выполнение DDL для логической резервной базы............... 580
Глава 15. Различные опции повышения доступности........................... 582
Команда flashback table ......................................... 582
Требующиеся привилегии .................................... 583
Восстановление удаленных таблиц............................ 583
Ретроспективный откат до SCN или отметки времени........... 585
Содержание
xvii
Команда flashback database.................................. 586
Использование LogMiner............................................ 589
Как работает LogMiner ...................................... 590
Извлечение словаря данных................................... 590
Анализ одного или нескольких журнальных файлов.............. 592
Возможности LogMiner, впервые появившиеся в Oracle Database 10g . 594
Оперативная реорганизация объектов ............................... 595
Оперативное создание индексов............................... 595
Оперативная перестройка индексов............................ 595
Оперативное объединение индексов............................ 596
Оперативная перестройка индекс-таблиц....................... 596
Оперативное переопределение таблиц.......................... 596
ЧАСТЬ IV ORACLE В СЕТЯХ
Глава 16. Oracle Net....................................................... 600
Обзор Oracle Net.................................................. 600
Дескрипторы соединений...................................... 603
Имена служб................................................. 604
Замена файла tnsnames. ora на Oracle Internet Directory.. 605
Прослушивающие процессы..................................... 605
Использование Oracle Net Configuration Assistant.................. 609
Конфигурирование прослушивающего процесса................... 610
Использование Oracle Net Manager.................................. 615
Запуск серверного прослушивающего процесса........................ 617
Управление серверным прослушивающим процессом..................... 618
Oracle Connection Manager................................... 620
Использование Connection Manager............................ 621
Именование каталогов с помощью Oracle Internet Directory .... 625
Использование простого именования соединений...................... 627
Использование связей баз данных................................... 628
Настройка Oracle Net.............................................. 630
Ограничение использования'ресурсов.......................... 631
Отладка проблем при соединении.............................. 632
Глава 17. Управление большими базами данных................................ 634
Создание табличных пространств в средах VLDB ..................... 635
Основы табличных пространств типа Bigfile................... 636
Создание и модификация табличных пространств типа Bigfile . . . 637
Формат R0WID для табличных пространств типа Bigfile...... 638
DBMS_ROWID и табличные пространства типа Bigfile............ 638
Г
Содержание
xviii
Использование DBVERIFY с.табличными пространствами типа Bigfile................................................ 641
Анализ параметров инициализации для табличных пространств типа Bigfile............................................. 643
Изменения в словаре данных для табличных пространств типа Bigfile................................................ 644
Расширенные типы таблиц Oracle................................... 644
Индекс-таблицы.............................................. 645
Глобальные временные таблицы................................ 646
Внешние таблицы............................................. 648
Секционированные таблицы.................................... 650
Материализованные представления............................. 678
Использование битовых индексов................................... 679
Осмысление битовых индексов ................................ 679
Применение битовых индексов................................. 680
Применение битовых индексов соединения...................... 680
Oracle Data Pump................................................. 681
Data Pump Export ........................................... 682
Data Pump Import............................................ 683
Применение переносимых табличных пространств................ 684
Глава 18. Управление распределенными базами данных........................ 688
Удаленные запросы ............................................... 689
Манипулирование удаленными данными: двухфазная фиксация транзакции....................................................... 690
Динамическое тиражирование данных............................. 691
Управление распределенными данными............................... 692
Инфраструктура: Обеспечение прозрачности местонахождения . . 693
Управление связями баз данных............................... 698
Управление триггерами базы данных........................... 700
Управление материализованными представлениями............... 701
Использование DBMSJVMEW и DBMSjADVISOR...................... 706
Какого рода обновления могут быть выполнены? ............... 718
Применение материализованных представлений для изменения путей выполнения запросов................................ 722
Управление распределенными транзакциями ......................... 724
Разрешение сомнительных транзакций.......................... 725
Приоритет точки фиксации.................................... 726
Мониторинг распределенных баз данных............................. 726
Настройка распределенных баз данных.............................. 727
Приложение. Функция верификации паролей................................... 730
Благодарности
Данная книга — это результат деятельности двух авторов, большого числа помощников, и вы даже не можете себе представить, сколько у нее было редакторов. Особая благодарность Бобу Брила — в значительной степени благодаря его преданности и знаниям мне удалось завершить этот проект с требующимся качеством и своевременно.
Я благодарю также помощников и редакторов из TUSC, включая Брэда Брауна, Тони Каталано, Майка Киллоха, Рича Нимика, Дэна Норриса, Криса Островски и Джо Треззо. Спасибо TUSC за их поддержку в процессе написания книги.
Спасибо команде McGraw-Hill/Osborne, и в частности Лайзе Уолтерс-Бродер и Лайзе МакКлейн. Спасибо читателям, которые предлагали свои темы, изменения или исправления. Отдельное спасибо Эйал Аронофф и Рэйчел Кармайкл за их советы, комментарии и исправления. Спасибо Марлен Терьо за ее помощь при подготовке последнего издания.
Спасибо друзьям, которые помогали мне на всем пути, в том числе Роберту Мейсснеру, Деклану Кейну, Уильяму Гриффину, Карен Рейнольдс, Мари Паретти, Крису О’Нейлу, Черил Биттпер, Джоан Хэнлон и Биллу Флемингу.
Если у вас есть комментарии по поводу книги, если вы ищете дополнительный материал по этой книге, зайдите на сайт http://www.kevinloney.com.
— Кевин Лупи
Многие технические книги нуждаются в опыте более чем одного автора, и эта книга не является исключением. Спасибо Кевину за его гибкость и советы во время наших размышлений о новом плане для этой книги — многократное спасибо! Для меня было честью работать с таким прославленным автором, и я рад, что смог помочь ему написать эту книгу.
Выражаю благодарность Лайзе Уолтерс-Бродер и Лайзе МакКлейн, помогавшим восполнить недостатки моего английского языка, а также спасибо Скотту Госсетту, который дал мне много хороших советов о том, как совместить теорию с практикой.
Многие из моих коллег по профессии из компаний Land’s End и Greenbrier & Russel были для меня и источником вдохновения, и руководителями: Джой Джонсон, Брук Свенсон, Стивен Дойч и Джули Краузе. Это и есть тот случай, когда целое и в самом деле больше, чем сумма составляющих его частей.
Если у вас есть вопросы или комментарии относительно любой из частей настоящей книги, пожалуйста, свяжитесь со мной по адресу электронной почты ijbryla@centurytel.net.
— Боб Брила
Введение
Кем бы вы ни были — опытным или начинающим администратором баз данных или разработчиком приложений — вы должны знать, как использовать новые характеристики OraclelOg, чтобы наилучшим образом удовлетворять запросы заказчиков. В этой книге рассматриваются все новейшие средства, а также способы их внедрения в управление базой данных Oracle. Основное внимание уделяется успешному и эффективному управлению функциональными возможностями базы данных, что позволяет получить качественный продукт. В результате ваша база данных станет гибкой, надежной, безопасной и расширяемой.
Для достижения этой цели особенно важны несколько компонентов, и в книге им будет уделено особое внимание посохе того, как в Части I мы познакомимся с архитектурой Oracle, вопросами апгрейда до Oracle 10g и планирования табличных пространств. Хорошо спроектированная логическая и физическая архитектура базы данных повысит ее производительность и облегчит администрирование благодаря надлежащему распределению ее объектов. В Части II будет рассказано о стратегиях мониторинга, безопасности и настройки автономных и сетевых баз данных. Здесь же описаны процедуры, обеспечивающие выполнение резервного копирования и восстановления базы данных. Все разделы сфокусированы на создании правильных методов планирования и управления для каждой области.
Вопросы высокой доступности рассматриваются во всех своих разновидностях: технологии Real Application Clusters (RAC), Recovery Manager и Oracle Data Guard — вот только некоторые из тем, которые глубоко раскрываются в Части III.
Подробно рассматриваются" вопросы, связанные с работой в сети и с управлением распределенными базами данных и базами, созданными в архитектуре клиент/сервер. В Части IV описываются Oracle Net, сетевые конфигурации, материализованные представления, прозрачность местонахождения и все необходимое для успешной работы распределенной базы данных и базы, работающей в архитектуре клиент/сервер. Приводятся реальные примеры для всех наиболее значимых конфигураций.
Помимо команд, необходимых для выполнения задач администратора баз данных, вы ознакомитесь с экранами Oracle Enterprise Manager — инструмента, помогающего выполнять сходные с командами функции. Следуя описанным в этой книге методам, вы спроектируете и реализуете свои системы настолько хорошо, что их настройка сведется к минимуму. Администрирование базы данных станет проще, пользователи получат более качественный продукт, а база данных будет работать — причем работать хорошо.
асть
Архитектура базы
анных
Г1ЙО 1
ЗНАКОМСТВО С АРХИТЕКТУРОЙ ORACLE
Oracle Database 10g является эволюционным, если не сказать революционным шагом по сравнению с предыдущим выпуском — Огас1е9г. Она не только более богата функциями — ею значительно легче управлять, что позволяет АБД Oracle “установить и забыть” о ней. В части I данной книги содержится обзор архитектуры Oracle и закладывается фундамент для развертывания успешной инфраструктуры Oracle, а также даются практические советы, как по инсталляции новой системы, так и по апгрейду к Oracle 10g с предыдущих версий. Чтобы обеспечить надежность фундамента программного обеспечения Oracle 10g, в соответствующих разделах предлагаемой книги рассматриваются вопросы, относящиеся к аппаратным средствам сервера и используемым операционным системам.
В части II рассматриваются несколько областей, связанных с повседневным сопровождением и функционированием баз данных Oracle 10g. В главе 5 обсуждаются требования, о выполнении которых АБД должен позаботиться еще задолго до того, как на сервере будет загружен первый установочный диск. В последующих главах речь идет о том, какими способами АБД может управлять дисковой памятью и использованием центрального процессора (ЦП), а также настраивать параметры Oracle таким образом, чтобы оптимизировать ресурсы сервера, используя множество инструментальных средств, имеющихся в распоряжении АБД для мониторинга производительности базы данных. Управление транзакциями значительно упрощается благодаря использованию AUM (технологии автоматического управления отменами транзакций) — опции базы данных Oracle, впервые появившейся в Огас1е9г и значительно усовершенствованной в Oracle 10g.
В части III внимание будет сфокусировано на вопросах обеспечения повышенной готовности Oracle 10g. Сюда включено использование диспетчера восстановления Oracle (RMAN) для выполнения и автоматизации создания резервных копий базы данных и ее восстановления, а также некоторых других возможностей Oracle (например, технологии Oracle ------------------------------ « способов восстановления
с архитектурой Oracle
3
co
базы данных после выхода из строя. И, наконец, будет рассмотрено, как с помощью технологии Oracle Real Application Clusters можно в одно и то же время обеспечить среде базы данных отличную масштабируемость и возможности прозрачного восстановления после сбоев.
В части IV описывается использование Oracle в сетевой среде. Здесь будет рассказано, как можно конфигурировать Oracle Net в N-уровневой среде и управлять большими и распределенными базами данных, которые могут быть физически размещены в близлежащих городах или даже в разбросанных по всему миру точках.
Обзор баз данных и экземпляров
Хотя довольно часто термины “база данных” и “экземпляр” используются как взаимозаменяемые, на самом деле, они имеют совершенно разные значения. Как будет показано в дальнейшем, в центре обработки данных Oracle они представляют очень различающиеся сущности.
Базы данных
г
База данных— это совокупность (collection) данных надиске, хранящаяся в одном или нескольких файлах на сервере базы данных, в которых осуществляется сбор и сопровождение связанной информации. База данных состоит из логических и физических структур. Наиболее важной из всех логических структур базы данных является таблица. Таблица содержит столбцы и строки, в которых хранятся родственные данные. База данных должна иметь в своем составе, как минимум, таблицы для хранения полезной информации. На рис. 1.1 приведен пример таблицы, содержащей четыре строки и три столбца. Данные в каждой строке таблицы являются связанными: каждая строка содержит информацию о конкретном служащем компании.
В дополнение к этому база данных предлагает уровень защиты, позволяющий предотвратить несанкционированный доступ к данным. Oracle Database 10g предлагает много механизмов для облегчения установления защиты, необходимой для того, чтобы конфиденциальные данные тако-
Строки данных
TABLE: HR_EMPLOYEE ------------имя таблицы
Имена столбцов
EMPLOYEE_NUMBER LAST_NAME FIRST-NAME
1 KRAUSE JULIE
2 PYEATT JOHN
3 TYLER LIV
5 MUMM KELLYk
Столбцы
Рис. 1.1. Пример таблицы базы данных
4
Глава 1
выми и оставались (подробнее об Oracle Security и управление доступом см. главу 10).
Файлы, из которых состоит база данных, можно разделить на две категории: файлы базы данных и файлы, не относящиеся к файлам базы данных. Они различаются хранящимися в них данными. Файлы базы данных содержат данные и метаданные; файлы, не относящиеся к базе данных, — параметры инициализации, информацию о регистрации (протоколировании) и т. п. Файлы базы данных являются критичными для ежедневного непрекращающегося функционирования базы данных (подробнее физические структуры памяти обсуждаются ниже в данной главе).
Экземпляры
Главными компонентами типичного корпоративного сервера являются один или несколько ЦП, дисковая память и оперативная память. В то время как база данных Oracle хранится на дисках сервера, экземпляр Oracle хранится в оперативной памяти сервера. Экземпляр Oracle состоит из большого блока памяти, выделенного в области System Global Area (SGA — системная глобальная область), а также из некоторого числа фоновых процессов, осуществляющих интерактивное взаимодействие между SGA и файлами базы данных на дисках.
В Oracle Real Application Clusters (RAC) несколько экземпляров могут использовать одну базу данных. Хотя экземпляры, совместно использующие базу данных, могут находиться на одном сервере, более вероятно, что эти экземпляры будут размещены на различных серверах, соединенных так называемым высокоскоростным межузловым соединением (interconnect), и будут обращаться к базе данных, которая размещена на специализированной дисковой подсистеме, поддерживающей RAID (дисковый массив) (подробнее о конфигурировании инсталляции RAC см. главу 11).
Логические структуры памяти Oracle
Файлы данных в базе данных Oracle объединяются в одно или несколько табличных пространств (tablespaces). Внутри каждого табличного пространства такие логические структуры базы данных, как, например, таблицы и индексы, являются сегментами, которые далее делятся на экстенты и блоки. Такое логическое подразделение памяти позволяет Oracle иметь более эффективный контроль над использованием дисковой памяти. На рис. 1.2 показано отношение между логическими структурами памяти в базе данных.
Табличные пространства
Табличное пространство Oracle состоит из одного или нескольких файлов базы данных; файл базы данных может быть частью одного и только одного табличного пространства. При инсталляции Oracle 10g должно быть создано не менее двух табличных пространств: табличное пространство SYSTEM и табличное пространство SYSAUX.
Знакомство с архитектурой Oracle
5
База данных
Рис. 1.2. Логические структуры памяти
Сегмент
Экстент 1
Блоки
Oracle 10gпозволяет создавать особый вид табличных пространств, называемых табличными пространствами вида BIGFILE (с большим файлом данных), которые могут достигать размера в 8 экзабайт (или 8 млн терабайт). При использовании табличных пространств такого вида управление табличными пространствами становится для АБД совершенно прозрачным; другими словами, АБД может управлять табличным пространством как неким целым, совершенно не вникая в размеры и структуру файлов данных, из которых онсхостоит.
Использование Oracle Managed Files (OMF — управляемые Oracle файлы) позволяет сделать управление файлами данных табличных пространств еще более легким. С помощью OMF АБД определяет одно или несколько мест в файловой системе, где будут размещены файлы данных, а также управляющие и журнальные файлы, и Oracle автоматически назначает этим файлам имена, а затем управляет ими (подробнее об OMF см. главу 4).
Если табличное пространство является временным (temporary), то, несмотря на название, само по себе табличное пространство является постоянным; временными являются только сегменты, хранящиеся в этом табличном пространстве. Временное табличное пространство можно использовать для операций сортировки и как рабочую область при построении индексов. Выделение для подобных операций табличного пространства помогает сократить число конфликтных ситуаций ввода/вывода между временными сегментами и постоянными сегментами, хранящимися в другом табличном пространстве, например, с таблицами.
Табличные пространства могут быть либо управляемыми по словарю, либо локально управляемыми. В табличном пространстве, управляемом по словарю, все операции по управлению экстентами записываются в таблицах словаря данных. Следовательно, даже если таблицы приложения раз
6
Глава 1
мещены в табличном пространстве USER, к табличному пространству SYSTEM все равно будут обращения для управления операциями DML над таблицами приложения. Получается, что все пользователи и все приложения должны использовать для управления экстентами табличное пространство SYSTEM. Это создает потенциальное узкое место для приложений с высокой интенсивностью операций записи. В локально управляемом табличном пространстве для каждого файла данных табличного пространства Oracle заводит битовую карту для отслеживания доступности памяти. Через словарь данных осуществляется только управление квотами, что существенно сокращает число конфликтных ситуаций для словаря данных.
Начиная с Огас1е9г, если табличное пространство SYSTEM является локально управляемым, то и все остальные табличные пространства должны быть локально управляемыми, если только для них разрешены и операции чтения, и операции записи. В базах данных с локально управляемым табличным пространством SYSTEM табличные пространства, управляемые по словарю, должны быть открыты только для чтения.
Блоки
Минимальной единицей хранения для базы данных Oracle является блок базы данных. Размер блока представляет собой конкретное число байтов памяти внутри заданного табличного пространства в базе данных.
Блок обычно кратен размеру блока операционной системы. Это делается для повышения эффективности дискового ввода/вывода. Используемый по умолчанию размер блока определяется параметром инициализации DB_BLOCK_SIZE. Кроме того, для других табличных пространств базы данных может быть определено до четырех других размеров блока, хотя блоки в табличных пространствах SYSTEM, SYSAUX и во всех временных табличных пространствах должны иметь размер DB_BLOCK_ SIZE.
Экстенты
Следующим уровнем логического группирования ь базе данных являются экстенты. Экстент состоит из одного или нескольких блоков базы данных. При увеличении размера объекта базы данных добавляемое объекту пространство выделяется в виде экстента.
Сегменты
Следующим уровнем логического группирования в базе данных является сегмент. Сегментом называется группа экстентов, из которых состоит объект базы данных, рассматриваемый как единое целое, например таблица или индекс. В результате сегмент становится самой малой единицей памяти, с которой приходится иметь дело конечному пользователю базы данных. В базах данных Oracle можно найти четыре типа сегментов: сегменты данных, индексные сегменты, временные сегменты и сегменты отката.
Знакомство с архитектурой Oracle
7
Сегменты данных
Каждая таблица базы данных размещается в одном сегменте данных, который состоит из одного или нескольких экстентов. Более одного сегмента назначается таблице, если она является секционированной или кластеризованной таблицей (подробнее см. ниже в данной главе).
Индексные сегменты
Каждый индекс хранится в собственном индексном сегменте. Как и в случае с секционированными таблицами, каждый раздел секционированного индекса хранится в собственном сегменте.
Временные сегменты
Когда для завершения работы SQL-оператора конечного пользователя требуется дисковая память, как это происходит, например, с операциями сортировки, которые не умещаются в отведенной длл них памяти, происходит выделение временного сегмента. Временные сегменты существуют только во время выполнения SQL-оператора.
Сегменты отката
Начиная с Oracle 10g, сегменты отката продолжают существовать только для табличного пространства SYSTEM, причем обычно АБД не требуется обязательно обслуживать сегмент отката SYSTEM. В предшествующих выпусках Oracle сегменты отката создавались для сохранения “предыдущих” значений операций DML над базой данных, если для таких операций будет выполнен откат. Еще одно применение сегментов отката — показ исходного вида информации (до начала обновления) с целью предоставления согласованного по чтению представления данных другим пользователям, обращающимся к таблице. Кроме того, сегменты отката использовались при восстановлении базы данных для отката всех незавершенных транзакций, которые были активны в момент возникновения аварийной ситуации с экземпляром базы данных или его непредвиденного завершения.
В Oracle К^для автоматического выделения сегментов отката и управления ими в табличных пространствах отката используется автоматическое управление пространством отката (Automatic Undo Management — AUM). Внутри табличного пространства отката управляемые автоматически сегменты отката (undo segments) структурированы вполне аналогично сегментам отката, управляемым вручную (rollback segments), за исключением той “мелочи”, что управление первыми, как это следует из названия, осуществляется самой системой Oracle, в то время как вторыми вручную управляет АБД (причем, далеко не всегда эффективно). Управляемые автоматически сегменты отката впервые появились в Oracle9i, но в Oracle 10g можно по-прежнему пользоваться управляемыми вручную сегментами отката. Однако их использование в Oracle 10gyжe не приветствуется, а в последующих выпусках их поддержка будет полностью прекращена (о технологии Automatic Undo Management см. главу 7).
8
Глава 1
Логические структуры базы данных Oracle
В этом разделе рассматриваются основные моменты всех главных логических структур базы данных, начиная с таблиц и индексов, а также типы данных, которые можно использовать при определений столбцов таблицы. После создания таблицы со столбцами можно ввести для столбцов таблицы ограничения (restrictions) или ограничивающие условия (constrants).
Одной из множества причин для применения Relational Database Management System (RDBMS — система управления реляционными базами данных) для управления данными является широкое использование возможностей аудита и защиты данных базы данных Oracle. Ниже рассматриваются способы, посредством которых можно разделить доступ к базе данных для различных пользователей или для тех объектов, к которым они обращаются.
Кроме того, будут затронуты другие логические структуры, которые могут быть определены либо АБД, либо пользователем, в том числе синонимы, связи с внешними файлами и ссылки на другие базы данных.
Таблицы
Таблица — это собой базовый механизм сохранения информации в базе данных Oracle. Без таблиц база данных не имела бы никакой ценности для предприятия. Безотносительно типа таблицы, данные в ней содержатся в строках и столбцах, подобно тому, как хранятся данные в электронных таблицах. Но на этом сходство и заканчивается. Надежность таблицы базы данных, гарантируемая распространяющейся на всю окружающую таблицу среду базы данных Oracle надежностью, целостностью и масштабируемостью, делает электронные таблицы всего лишь слабым вторым вариантом при выборе решения о том, где именно хранить стратегически важную информацию.
В этом разделе рассматриваются различные таблицы базы данных Oracle и то, как они могут удовлетворить почти каждой потребности хранения данных в вашей организации (подробнее о выборе между этими различными типами таблиц для конкретного грг-дожения и управлении ими см. главы 5 и 8).
Реляционные таблицы
Реляционная таблица является наиболее распространенным типом таблиц базы данных. Эта таблица организована по принципу “кучи”; другими словами, для хранения строк таблицы не существует никакого определенного порядка. В команде create table можно специфицировать фразу organization heap, посредством которой определяется организованная по принципу “кучи” таблица, но так режим “кучи” является режимом по умолчанию, эта фраза обычно опускается.
Каждая строка таблицы содержит один или несколько столбцов; у каждого столбца есть тип данных и длина. Начиная с Огас1е8, в столбцах могут также содержаться определенные пользователем типы данных — вложенные таблицы или массивы VARRAY. Кроме того, таблица может быть определена как объектная таблица. Объекты и объектные таблицы будут рассмотрены ниже. Встроенные типы данных Oracle перечислены в таблице 1.1.
Знакомство с архитектурой Oracle
9
Таблица 1.1. Встроенные типы данных Oracle
Встроенный тип данных Oracle Описание_________________________________________
VARCHAR2 (размер) [BYTE I CHAR] Символьное поле переменной длины с максимальной длиной до 4000 байт, минимальная длина 1 байт. Модификатор CHAR означает, что для определения длины строки используется так называемая символьная семантика; BYTE означает, что для этой цели используется байтовая семантика.
NVARCHAR2 (размер)
NUMBER (p,s)
LONG
DATE %
BINARY-FLOAT
BINARY-DOUBLE
TIMESTAMP (точностЬ-Секунд)
TIMESTAMP (точность-секунд)
WITH TIMEZONE
TIMESTAMP (точность_секунд) WITH LOCAL TIME ZONE
INTERVAL YEAR (разрядность.года) TO MONTH
INTERVAL DAY (разрядность_дней) TO SECOND (точность_секунд)
RAW (размер)
Поле переменной длины с максимальным размером 4000 байт.
Числовой столбец с заданными разрядностью (р) и масштабом (s). Разрядность может изменяться в диапазоне от 1 до 38, а масштаб — от-84 до 127.
Поле данных переменной да.-:, размер поля до 2 Гбайт (2**31-1).
Значения дат, начиная с 1 января 4712 г. до н.э. и заканчивая 31 декабря 9999 г.
32-битовое число с плавающей точкой.
64-битовое число с плавающей точкой.
Представляет дату и время (год, месяц, число, часы, минуты, секунды и доли секунд). Значение точности секунд может изменяться от 0 до 9; другими словами, обеспечивается точность до одной миллиардной доли секунды. Значение по умолчанию равно 6 (одна миллионная доля секунды).
Содержит значение TIMESTAMP, к которому добавлено смещение, связанное с часовым поясом. Часовой пояс может отсчитываться от UTC (всемирное время), например ‘-6:00’ или указываться названием региона, например ‘US/Central’.
Этот тип данных похож на TIMESTAMP WITH TIMEZONE за исключением того, что: (1) <.ри сохранении в базе данных дата приводится к часовому поясу базы данных и (2) при выборке данных пользователь будет видеть эти данные в пересчете на часовой пояс сеанса.
Хранит значение интервала времени, выраженное в годах и месяцах. Значение разрядность_года определяет число цифр в поле YEAR даты.
Хранит значение интервала времени, выраженное в днях, часах, минутах, секундах и долях секунды. Значение разрядность_дней лежит в интервале от 0 до 9. Значение по умолчанию равно 2. Значение точность-секунд аналогично значению точность_секунд для типа данных TIMESTAMP. Оно также лежит в интервале от 0 до 9, а значение по умолчанию равно 6.
Поле переменной длины (до 2000 байт).
10
Глава 1
Таблица 1.1. (Продолжение)
Встроенный тип данных Oracle Описание
LONG RAW Поле переменной длины (до 2 Гбайт), используемое для хранения двоичных данных.
ROWID Представление (в кодировке base-64)B виде строки уникального адреса строки соответствующей таблицы. Этот адрес должен быть уникальным для всей базы данных.
UROWID [{размер)] Строка (в кодировке base-64), представляющая логический адрес строки индекс-таблицы; длина до 4000 байт.
CHAR (размер) [BYTE 1 CHAR] Символьное поле фиксированной длины, определяемой значением размер. Минимальное значение длины равно 1 байт, а максимальное — 2000 байт. Параметры BYTE и CHAR указывают на применение байтовой или символьной семантики, в VARCHAR2.
NCHAR {размер) Поле для размещения символов фиксированной длины (состоящих из нескольких байтов). Максимальный размер поля — 2000 байт. Значение по умолчанию — 1 байт.
CLOB Символьный большой объект, содержащий однобайтовые или многобайтные символы; поддерживает как однобайтные, так и многобайтные наборы символов. Максимальный размер объекта равен (4 Гбайт -1)*DB_ BLOCK_SIZE.
NCLOB Аналогичен CLOB за тем исключением, что в базу данных вместо символов из наборов символов фиксированной или переменной длины записываются символы Unicode. Максимальный размер объекта равен (4 Гбайт -1)*DB_BL0CK_SIZE.
BLOB Двоичный большой объект. Максимальный размер объекта равен (4 Гбайт -1)*DB_BL0CK_SIZE.
BFILE Указатель на большой двоичный файл, хранящийся вне базы данных Двоичные Файлы должны быть доступны с сервера, на котором выполняется экземпляр Oracle. Максимальный размер объекта равен 4 Гбайт.
Кроме того, Oracle поддерживает типы данных, сопоставимые с типами данных ANSI. Соответствие между типами данных Oracle и типами данных ANSI показано в таблице 1.2.
Временные таблицы
Начиная с Огас1е8г, в базе данных Oracle появились временные таблицы. Временными они являются в том смысле, что сохраняется описание временной таблицы, но не хранящиеся в ней данные. Создается временная таблица с помощью команды create global temporary table.
Знакомство с архитектурой Oracle
11
При условии, что все прочие пользователи также имеют полномочия на эту таблицу, они могут выполнять над временной таблицей операторы select или такие команды языка манипулирования данными (Data Manipulation Language — DML), как, например, insert, update или delete. Однако каждая строка данных в таблице видна только для того пользователя, который вставил эту строку. Когда пользователь удаляет временную таблицу, будут удалены только ранее вставленные им самим строки.
Данные, содержащиеся во временной таблице, относятся либо к сеансу, либо к транзакции. Продолжительность жизни временной таблицы зависит от ключевых слов, которые используются в конструкции on commit для этой временной таблицы. Если указано on commit delete rows, то при появлении команд commit или rollback, будут удалены все строки временной таблицы, а в случае задания on commit preserve rows, строки таблицы будут сохранении и после окончания транзакции. Но по окончании сеанса пользователя все строки временной таблицы будут удалены.
Табл ица 1.2. Типы данных Oracle, эквивалентные типам данных ANSI
Тип данных SQL ANSI Тип данных Oracle
CHARACTER(n) CHAR(n)
CHAR(n)
CHARACTER VARYING(n) VARCHAR(n)
CHAR VRYING(n)
NATIONAL CHARACTER(n) NCHAR(n)
NATIONAL CHAR(n)
NCHAR(n)
NATIONAL CHARACTER VARYING(n) NVARCHAR2(n)
NATIONAL CHAR VARYING(n)
NCHAR VARYING(n)
NUMERIC(p.s) NUMBER(p,s)
DECIMAL(p,s)
INTEGER NUMBER(38)
INT
SMALLINT
FLOAT(b) NUMBER
DOUBLE PRECISION REAL
Есть еще несколько моментов, которые следует иметь в виду при использовании временных таблиц. Хотя и можно создать индекс для временной таблицы, все записи индекса будут удалены вместе со строками данных, так же, как и для обычной таблицы. К тому же, вследствие
12
Гпава 1
временности данных из временной таблицы в журнале не будет сгенерировано никакой информации об операциях DML над временными таблицами; однако, информация в табличном пространстве отката все-таки создается.
Индекс-таблицы
Создание индекса делает поиск конкретной строки таблицы более эффективным. Однако, при этом возникают дополнительные накладные расходы, так как теперь база данных должна помимо сопровождения строк самой таблицы осуществлять и сопровождение записей индекса таблицы. А что, если в таблице не так уж много столбцов и обращения к таблице происходят преимущественно по одному из столбцов? В таком случае правильным решением может оказаться так называемая индекс-таблица (ЮТ — index organized table). В ЮТ строки таблицы хранятся в индексе со структурой В-дерева, где в каждом узле этого индекса содержится ключевой (индексированный) столбец вместе с одним или несколькими неиндексированными столбцами.
Одним из наиболее очевидных преимуществ ЮТ является то, что теперь необходимо поддерживать и сопровождать всего одно представление данных в памяти вместо двух; аналогично, значения первичного ключа таблицы в ЮТ будут сохранены только один раз, в то время как в обычной таблице это происходит дважды.
Однако, при применении индекс-таблиц обнаруживаются и некоторые недостатки. Некоторым таблицам, например таблицам для протоколирования событий, может не требоваться для этой цели первичный (или любой другой подходящий) ключ; ЮТ же обязательно должна иметь первичный ключ. Кроме того, ЮТ не может быть членом кластера. И, наконец, ЮТ может оказаться далеко не лучшим решением для таблицы, если в ней имеется много столбцов, и при выборке из этой таблицы информации (строк) обращения к ней производятся по многим столбцам.
Объектные таблицы
Начиная с Огас1е8, база данных Oracle поддерживает многие объектно-ориентированные возможности. С помощью определенных пользователем типов и методов можно добиться прозрачной реализации в Oracle объектно-ориентированного прикладного проекта.
У объектных таблиц имеются строки, которые сами являются объектами или инстанциями (экземплярами реализации) определений типов. На строки объектной таблицы можно ссылаться, используя для этой цели объектные идентификаторы (object identifier — OID), в противоположность первичному ключу обычной (реляционной) таблицы; однако, объектная таблица может продолжать иметь оба ключа — и первичный, и уникальный, как и обычная таблица.
Предположим, что нужно создать кадровую систему “нуля”, так что есть все возможности для создания полностью стоящего на объектно-реляционной точке зрения проекта. Первым шагом должно стать определение объекта (или типа) служащий (employee). Это можно сделать следующим образом:
Знакомство с архитектурой Oracle
13
□ create type PERS_TYP as object
(Last_Name varchar2(45),
First_Name varchar2(30),
Middle_Initial char(1),
Surname varchar2(10),
SSN varchar2(15));
В этом конкретном случае для типа PERS_TYP не создается ни один метод, но по умолчанию Oracle создает для типа метод конструктора, который получает то же самое имя, что и сам тип (в данном случае, PERS_ TYP). Для создания объектной таблицы как коллекции объектов типа PERS_TYP можно использовать хорошо известный синтаксис create table, а именно:
□ create table pers of pers_typ;
Для добавления объекта к объектной таблице необходимо указать в команде insert метод конструктора:
□ insert into pers
values (pers_typ(‘Judd\ ‘Dawn’, ‘R’, ‘Dr.’, ‘123-45-6789’));
Ссылки на экземпляры объекта PERS_TYP могут быть сохранены в других таблицах как объекты типа REF (ссылки), а данные из таблицы PERS могут быть выбраны без прямых ссылок на саму таблицу PERS.
Новые примеры того, как можно использовать объекты для реализации объектно-ориентированных проектов можно найти в главе 5.
Внешние таблицы
Внешние таблицы были впервые введены в Огас1е9г. Коротко говоря, внешние таблицы (external tables) позволяют пользователю получать доступ к источнику данных, например, к текстовому файлу, как если бы он был таблицей базы данных. Метаданные таблицы хранятся в словаре данных Oracle, но содержимое таблицы хранится вне базы.
Определение внешней таблицы содержит две части. В первой и наиболее хорошо известной части содержится определение таблицы с точки зрения пользователя базы данных. Это определение выглядит так же, как и любое другое типичное определение, с которым приходится сталкиваться в операторе create table.
Во второй части содержится то, что отличает внешнюю таблицу от обычной. Именно здесь хранится отображение столбцов внешней таблицы на данные из внешнего файла — с какого столбца начинаются элементы данных, какова ширина (размер) столбца, а также — является ли формат внешнего столбца символьным или цифровым. Синтаксис ORACLE LOADER, используемый для типа по умолчанию внешней таблицы, в конечном счете, идентичен синтаксису управляющего файла утилиты SQL* Loader. В этом состоит одно из преимуществ внешних таблиц; чтобы получить доступ к внешнему файлу, пользователю необходимо знать только, как осуществляется доступ к таблицам базы данных.
Как всегда, наряду с преимуществами, при использовании внешних таблиц есть и несколько недостатков. Для внешних таблиц нельзя создавать индексы; кроме того, для внешних таблиц нельзя использовать
14
Гпава 1
команды вставки (insert), обновления (update) и удаления (delete). Но эти недостатки являются незначительными по сравнению с преимуществами от использования внешних таблиц для загрузки “родных” таблиц базы данных, например в средах хранилищ данных.
Кластеризованные таблицы
Если с двумя (или с большим числом) таблиц часто работают совместно (как, например, в случае таблицы заказов и детальной таблицы элементов заказа), неплохим решением для повышения производительности запросов, обращающихся к этим таблицам, может оказаться создание кластеризованной таблицы. В случае таблицы заказов и ассоциированной с ней детальной таблицы элементов заказа информация из заголовка документа может храниться в том же блоке, что и информация записей с деталями заказа, что позволит уменьшить число операций ввода/вывода, необходимых для выборки всей информации о заказе.
Кластеризация таблиц позволяет также сократить объем памяти, необходимой для хранения столбцов, являющихся общими для обеих таблиц, совокупность которых называют значением кластерного ключа. Значение кластерного ключа хранится и в так называемом кластерном индексе. Кластерный индекс работает во многом похоже на обычный традиционный индекс, так как он повышает эффективность запросов к кластеризованным таблицам при доступе к ним по значению кластерного ключа. В примере с заказами и элементами заказа номера заказов будут сохранены только один раз, вместо того, чтобы повторяться в каждой строке с элементами заказа.
Преимущества кластеризованных таблиц существенно сокращаются, когда для них часто приходится выполнять операции вставки, обновления и удаления. Кроме того, частые запросы к отдельным таблицам, входящим в состав кластера, также приводят к сокращению преимуществ кластеризованных таблиц перед некластеризованными таблицами.
Хеш-кластеры
Особый тип кластеризованных таблиц — хеш-кластеры — работает во многом аналогично обычной кластеризованной таблице, но вместо использования обычного кластерного индекса в хеш-кластерах для определения физической локализации того места, где строку следует сохранить (или откуда ее следует выбирать), используются функции хеширования кластерного ключа строки. Вся память, необходимая для таблицы, выделяется при ее создании при условии, что известно число хеш-ключей, указываемое при создании кластера. В условиях данного примера (заказ и его элементы), предположим, что базе данных Oracle необходимо отобразить унаследованную систему ввода данных, в которой номера заказов периодически повторяются. Кроме того, номера заказов в обязательном порядке обязаны быть шестизначными числами. В таком случае можно создать кластер для заказов следующим образом:
□ create cluster order_cluster (order_number (6)) size 50
hash is order_number hashkeys 1000000;
Знакомство с архитектурой Oracle
create table cust_order ( order_number number(6) primary key,
order_date date,
customer_number number)
cluster order_cluster(order_number);
Наибольшие преимущества хсш-кластеров связаны с запросами, использующими операции сравнения по равенству, как показано в следующем листинге:
select order_number, order_date from cust_order where order_number = 196811; *
Как правило, такой тип запроса будет находить требующуюся строку, используя всего одну операцию ввода/вывода, если число hashkeys достаточно велико, а фраза hash is, содержащая функцию хеширования, продуцирует равномерно распределенные ключи хеширования.
Сортированные хеш-кластеры
Сортированные хеш-кластеры стали Новинкой Oracle 10g. Они похожи на обычные хеш-кластеры тем, что для нахождения строки в таблице используется функция хеширования. Однако в дополнение к этому сортированные хеш-кластеры позволяют хранить строки таблицы упорядоченными (в порядке возрастания) по значениям одного или нескольких столбцов таблицы. Это позволяет быстрее обрабатывать данные для приложений, которые отдают предпочтение обработке типа “первый пришел, первым обслужен” (FIFO).
Для создания сортированных хеш-кластеров используется тот же самый синтаксис, что и для обычных кластеризованных таблиц, но с добавлением после описания столбцов кластера позиционного параметра SORT. Ниже приведен пример создания таблицы в составе сортированного хеш-кластера:
create table order_detail ( order_number number, order_timestamp timestamp sort, customer_number number) cluster order_detail_cluster ( order_number, order_timestamp);
Благодаря FIFO природе сортированного хеш-кластера, когда обращения к заказам осуществляются по столбцу order number, самые старые заказы будут выбраны первыми, для чего будет использовано значение столбца order_timestamp.
Секционированные таблицы
Секционирование таблицы (или индекса; см. следующий раздел) помогает повысить управляемость больших таблиц. Таблица может быть разбита на разделы, которые, в свою очередь, могут быть разбиты на подразделы, т. е. на более мелкие части. С точки зрения приложения секциопирова-
16
Глава 1
ние остается прозрачным (это означает, что ни в каких из задаваемых конечным пользователем операторах SQL не должно появиться никаких явных ссылок на разделы таблицы). Единственный эффект, который может обнаружить конечный пользователь, заключается в том, что запросы к секционированным таблицам, использующие критерии во фразе where, которые соответствуют схеме секционирования, выполняются намного быстрее.
С точки зрения АБД в секционировании таблиц обнаруживается множество преимуществ. Если один из разделов секционированной таблицы размещен на испортившемся дисковом томе, другие разделы этой таблицы по-прежнему останутся доступными для запросов пользователей на время восстановления поврежденного тома. Можно делать резервные копии таблицы по разделам, по одному разделу за раз, вместо того чтобы создавать единую резервную копию для всей таблицы.
Разделы могут быть одного из трех видов: секционированные по диапазонам ключей, хеш-секционированные или, что началось с Огас1е9г, секционированные по списку значений ключа. Каждая строка в секционированной таблице может принадлежать одному, и только одному, разделу. Ключ раздела служит для направления строк таблицы в соответствующий раздел; этот ключ может быть составным ключом, состоящим не более чем из 16 столбцов таблицы. Есть несколько несущественных ограничений на типы таблиц, которые можно секционировать; например, нельзя секционировать таблицы, содержащие столбцы типов LONG или LONG RAW.
Совет Корпорация Oracle настоятельно рекомендует тщательно рассмотреть вопрос о секционировании всех таблиц, размер которых превышает 2 Гбайт.
Неважно, какой из типов схемы секционирования используется, каждый член (участник) секционированной таблицы должен иметь те же самые логические атрибуты, например имена столбцов, типы данных, ограничивающие условия и так далее. Физические атрибуты для каждого из разделов могут отличаться в зависимости от размеров и места нахождения дискового устройства. Все дело в том, что секционированная таблица не должна быть логически противоречивой с точки зрения приложения или конечного пользователя.
Раздел по диапазону ключей
Это раздел (range partition) для которого значение ключа раздела попадает в определенный диапазон. Например, посещения корпоративного web-сайта электронной торговли можно относить к определенному разделу на основании даты посещения сайта, причем будет создаваться по одному разделу в квартал. Посещение web-сайта, состоявшееся 25 мая 2004 г., будет зафиксировано в разделе FY2004Q2, в то время как посещение, состоявшееся 2 декабря 2004 г., — в разделе FY2004Q4.
Раздел по списку значений ключа
Это раздел (list partition), ключ которого попадает в одну из групп, состоящих из различных значений. К примеру, при обработке продаж по различным регионам США может быть создан один раздел для штатов NY,
Знакомство с архитектурой Oracle
CN, МА и VT и второй раздел для IL, WI, IA и MN. Все продажи из всех остальных регионов (США и всего остального мира) будут попадать в отдельный раздел, если для них не указан код штата.
Хеш-разделы
Алгоритм хеш-раздела относит строку к тому или иному разделу в зависимости от значения функции хеширования, в которой специфицирован столбец (или столбцы), используемый функцией хеширования, но не назначает раздел явно, а всего лишь указывает, сколько различных разделов возможно. Oracle будет назначать разделу строку и обеспечивать сбалансированное распределение строк в каждом разделе.
Хеш-разделы оказываются полезными, когда отсутствует четкий список или схема разбиения на разделы по диапазону ключей при заданных типах столбцов таблицы или когда относительные размеры разделов часто изменяются, требуя повторяющегося раз за разом усовершенствования схемы разбиения на разделы (вручную).
Композитные разделы
Дальнейшее усовершенствование процесса разбиения на разделы становится возможным при использовании композитных разделов. Так, например, можно разбить таблицу на разделы по диапазону ключей, а внутри каждого диапазона разбить на подразделы по списку значений ключа или с помощью хеширования.
Секционированные индексы
Индексы для таблицы также можно секционировать либо в соответствии со схемой секционирования индексируемой таблицы (локальное индексирование), либо независимо от схемы секционирования таблицы (глобальное индексирование). Преимущество локально секционированных индексов состоит в том, что их применение повышает доступность индекса при выполнении операций над разделами; например, архивирование и удаление раздела FY2004Q4 и его локального индекса не повлияет на доступность индекса для других разделов таблицы.
Ограничения целостности
Ограничением целостности (constraint) в Oracle называется правило или правила, которые могут быть определены для одного или нескольких столбцов таблицы, чтобы помочь принудительному выполнению бизнес-правил. Так, например, ограничение целостности может провести в жизнь выполнение бизпес-правила, гласящего, что стартовая зарплата служащего не может быть меньше $25000,00 долларов в год. Другим примером ограничения целостности, проводящего в жизнь бизнес-правило, является требование, чтобы, если вновь принятому сотруднику был назначен отдел (хотя он и не должен быть сразу же приписан к какому-то отделу), назначенный номер отдела должен быть допустимым и присутствовать в таблице DEPT (таблица отделов).
К столбцам таблицы могут быть применены шесть типов правил целостности данных (data integrity): правило применения значений NULL, уникальные значения столбцов, значения первичных ключей, значения
18
Глава 1
ссылочной целостности, сложная встроенная целостность и целостность на базе триггеров.
Все ограничения целостности для таблицы определяются либо во время создания таблицы, либо при изменении таблицы на уровне столбцов за исключением триггеров, которые определяются на основании того, какие операции DML выполняются над таблицей. Ограничения целостности могут быть активированы или деактивированы при создании или в любой последующий момент времени. Когда ограничение целостности активируется или отключается (для этого используются ключевые слова enable и disable), имеющиеся в таблице данные с помощью ключевых слов validate и novalidate могут быть подвергнуты или не подвергнуты проверке на достоверность относительно ограничения целостности, зависящего от действующих бизнес-правил.
Например, для таблицы, входящей в состав базы данных производителей автомобилей, которая называется CARJNFO и содержит сведения о новых автомобилях, требуется новое ограничение для столбца AIRBAG_ QTY, в соответствии с которым этот столбец не может иметь пустого (NULL) значения, а его значение не может быть меньше 1 для всех новых автомобилей. Однако в этой таблице содержатся и данные о моделях автомобилей для тех лет, когда пневмоподушки для автомобилей еще не требовались, и в результате в этом столбце будет стоять либо 0, либо NULL. Одним из решений для такого случая будет создание ограничения целостности для столбца AIRBAG_QTY, обеспечивающего проведение в жизнь нового правила для вновь вводимых в таблицу строк, но не проверка выполнения этого правила для уже имеющихся в таблице строк.
Ниже приводится пример создания таблицы со всеми типами ограничений целостности. Каждый из типов ограничений будет затем рассмотрен в соответствующем подразделе.
create table OUST ORDER (Order_Number Order_Date Delivery_Date Warehouse_Number Customer_Number Order_Line_Item_Qty UPS_T racking_Numbe r
foreign key (Customer_Number) references CUSTOMER(Customer_Number));
NUMBER (6) DATE DATE, NUMBER NUMBER NUMBER VARCHAR2
PRIMARY KEY, NOT NULL,
DEFAULT 12,
NOT NULL,
CHECK (Order_Line_Item_Qty < 100),
UNIQUE,
Правило применения значений NULL
Ограничения целостности NOT NULL не позволяют ввести в базу данных пустые значения столбцов Order_Date или Customer_Number. С точки зрения бизнес-правил в этом заключен глубокий смысл: у каждого заказа должна быть известна дата заказа, и заказ не имеет никакого смысла, пока он не будет размещен заказчиком.
Значение NULL в столбце вовсе не означает, что это значение пробельное или нулевое; точнее будет сказать, что значение не существует. Значение NULL не равно ничему, даже другому значению NULL. Эта концепция оказывается важной при применении SQL-запросов к столбцам, в которых имеются значения NULL.
Знакомство с архитектурой Oracle
19
Уникальные значения столбцов
Ограничение целостности UNIQUE (уникальное значение) гарантирует, что столбец или группа столбцов (в композитных ограничениях) является уникальным в таблице. В предыдущем примере столбец UPS_Tracking_ Number не будет содержать повторяющихся значений.
Для принудительного выполнения этого ограничения целостности Oracle создаст для столбца UPS_Tracking_Number так называемый индекс UNIQUE (индекс по уникальному ключу). Oracle будет использовать этот индекс для принудительного обеспечения выполнения ограничений целостности.
Столбец с ограничением UNIQUE может быть также объявлен как NOT NULL. Если же столбец не объявляется как NOT NULL, любое количество строк может содержать значения NULL до тех пор, пока оставшиеся строки данного столбца буду!' иметь уникальные значения.
В композитном ограничении по уникальности, которое разрешает иметь значение NULL в одном или нескольких столбцах, именно имеющие не пустое (not NULL) значение столбцы определяют, будет ли выполнено ограничение. Столбцы NULL всегда удовлетворяют ограничению, поскольку значение NULL не равно ничему.
Значения первичных ключей
Ограничение целостности PRIMARY KEY относится к числу наиболее распространенных ограничений, которые можно найти в базах данных. Для таблицы может существовать только одно ограничение первичного ключа. Столбец или столбцы, составляющие первичный ключ, не могут иметь значение NULL.
В предыдущем примере первичным ключом является столбец Order-Number. Для выполнения этого ограничения создается индекс по уникальному ключу; если пригодный к использованию индекс для этого столбца уже существует, в ограничении первичного ключа будет использован именно этот индекс.
Значения ссылочной целостности
Ограничения ссылочной целостности FOREIGN KLEY являются более сложными, чем ранее рассмотренные, так как они связаны с другой таблицей, определяющей, какие значения можно ввести в столбец, на который наложено ограничение ссылочной целостности.
В предыдущем примере ограничение FOREGN KEY объявлено для столбца Customer_Number; любые значения, вводимые в этот столбец, должны существовать и в столбце Customer_Number другой таблицы (в данном случае таблицы Customer).
Как и в случае с другими ограничениями, допускающими значения NULL, столбец с ограничением по ссылочной целостности может быть NULL, не требуя при этом, чтобы в том столбце, на который делается ссылка, содержалось значение NULL.
Более того, ограничение FOREIGN KEY может быть рефлексивным (self-referential, т. е. ссылающимся само на себя). В таблице EMPLOYEE, первичным ключом которой является столбец Employee_Number, для
20
Глава 1
столбца с именем Manager_Number может быть объявлено ограничение FOREIGN KEY по столбцу Employee_Number в той же самой таблице. Это позволяет создать в таблице EMPLOYEE иерархию подчиненности.
Для повышения производительности рекомендуется всегда создавать индексы для столбцов, объявленных с ограничением FOREIGN KEY; единственным исключением из этого правила является ситуация, когда столбец, на который делается ссылка, является первичным или уникальным ключом в родительской таблице и никогда не подвергался удалению или обновлению.
Сложная встроенная целостность
Для принудительной реализации более сложных бизнес-правил на уровне столбца может быть использовано ограничение CHECK. В предыдущем примере значение столбца OrderJLine_Item_Qty не должно превосходить 99.
В ограничении CHECK для вычисления значения ограничения могут использоваться другие столбцы этой (обновляемой или вставляемой) строки. Например, ограничение на столбец STATECI) разрешает использовать в нем значения NULL только в том случае, если в столбце COUNTRY. CD указано не USA. Помимо значений столбцов в ограничении могут использоваться литеральные значения и встроенные функции, например, TO_CHAR или TOJDATE, при условии, что аргументами этих функций являются литералы или столбцы таблицы.
Для столбца разрешается использовать несколько ограничений CHECK. Для разрешения включения вводимого значения в столбец необходимо, чтобы при вычислении каждого из ограничений CHECK было получено значение TRUE. Например, можно модифицировать предыдущее ограничение CHECK, введя в него в дополнение к уже имеющемуся условию еще одно условие: чтобы Order Line. Item__Qty было больше нуля.
Целостность на базе триггеров
Если бизнес-правила являются слишком сложными для реализации их с помощью ограничений уникальности, можно создать для таблицы так называемый триггер базы данных, используя команду create trigger и блок кода PL/SQL для проведения в жизнь этого бизнес-правила.
Триггеры требуются для принудительного выполнения ограничений ссылочной целостности, когда таблица, на которую делаются ссылки, находится в другой базе данных. Полезны триггеры л для множества других действий, лежащих далеко от области проверки выполнения ограничений (например, для аудита доступа к таблице). Подробнее о триггерах базы данных см. главу 18.
Индексы
Индекс Oracle позволяет обеспечить более быстрый доступ к строкам таблицы, когда из таблицы должно быть отобрано всего лишь небольшое подмножество входящих в нее строк. В индексе хранится значение столбца или столбцов, по которым он строится, а также физическое значение RowID строки, где содержится индексируемое значение, за исключением
Знакомство с архитектурой Oracle
21
индекс-таблиц (ЮТ), использующих первичный ключ в качестве логического RowID. Как только в индексе будет найдено совпадение, RowID из индекса непосредственно укажет на точное положение (адрес) строки таблицы: в каком файле, в каком блоке внутри этого файла и в какой строке внутри блока.
Индексы создаются по одному или по нескольким столбцам. Записи индекса Oracle хранятся в структуре В-дерева, так что для обхода индекса, требующегося для нахождения ключевого значения для строки, затрачивается очень мало операций ввода/вывода. Кроме того, уникальные индексы могут служить для еще одной цели: они не только увеличивают скорость поиска строки, но и могут (при желании) обеспечивать выполнение ограничения уникального или первичного ключа для индексируемого столбца. Записи индекса автоматически обновляются при выполнении над содержимым таблицы любой операции вставки, обновления или удаления. При удалении таблицы все созданные для нее индексы также автоматически удаляются.
В Oracle есть несколько типов индексов, каждый из которых наилучшим образом подходит для определенного вида таблиц, метода доступа к ним или от прикладной среды.
Индексы по уникальному ключу
Индексы по униксстьному ключу (или индексы UNIQUE) являются наиболее распространенной формой индексов со структурой В-дерева. Они часто используются, чтобы обеспечить выполнение для таблицы ограничения первичного ключа. Использование индексов по уникальному ключу служит гарантией того, что в индексируемом столбце (или столбцах) не встретятся повторяющиеся (дублирующие друг друга) значения. Например, индекс UNIQUE для таблицы EMPLOYEE может быть создан для столбца Social Security Number (SSN — номер системы социального обеспечения), так как в этом поле ни в коем случае не должно быть повторений (дубликатов). Однако некоторые из служащих могут не иметь SSN, поэтому для этого столбца следует разрешить значение NULL.
Индексы по не уникальному ключу
Индексы понеуниксстьномуклнлиу (индексы non-UNIQUE) помогают ускорить доступ к таблице, не обеспечивая при этом уникальности. Можно создать индекс non-UNIQUE для столбца Last_Name таблицы EMPLOYEE, чтобы ускорить поиск по фамилиям сотрудников, но в этом случае в столбце может встречаться сколько угодно дубликатов для любой фамилий.
Если в команде CREATE INDEX не задано никакого другого ключевого слова, для столбца автоматически создается индекс по неуникальному ключу в структуре В-дерева.
Индекс по реверсированному ключу
Индекс по реверсированному ключу (reverse key index) является особым видом индекса, который, как правило, применяется в средах OLTP (оперативной обработки транзакций). В таком индексе порядок данных ключа перед сохранением меняется на противоположный (реверсируется). Клю
22
Глава 1
чевое слово reverse определяет реверсированный порядок ключа индекса в команде create index. Ниже приводится пример создания индекса с реверсированным ключом:
□ create index IE_LINE_ITEM_ORDER_NUMBER on LINE_ITEM(Order_Number) REVERSE;
Если размещается заказ с номером 123459, индекс с реверсированным ключом сохранит этот номер как 954321. Вставки записей с такими индексами будут распределены по всем ключам-листьям в индексе, сокращая число конфликтов между несколькими пользователями, пытающимися записать данные (вставить новые строки) в таблицу. Кроме того, индекс по реверсированному ключу уменьшает количество так называемых “горячих точек” в средах OLTP, если заказы модифицируются (или к ним делаются запросы) вскоре после того, как они были размещены.
Индекс по ключу-функции
Индексы на базе функций похожи на стандартные индексы со структурой В-дерева с тем лишь отличием, что в этом индексе хранится некоторое преобразование столбца или столбцов, на основе определенных пользователем выражений (функций), а не значение из самого столбца.
Индексы по ключу-функции могут быть полезны, например, когда какие-то названия или адреса хранятся в базе данных как смесь прописных и строчных букв (верхнего и нижнего регистров). Обычный индекс по столбцу, содержащему значение ‘SmiTh’ не возвратит никакого значения, если критерий поиска задан как ‘Smith’. С другой стороны, если фамилии в индексе хранятся полностью в верхнем регистре (SMITH), то и для всех поисков придется задавать фамилию в верхнем регистре. Ниже приводится пример создания индекса по ключу-функции для столбца Last_Name таблицы EMPLOYEE:
□ create index up_name on employee (upper(Last_Name));
В результате для поисков с использованием запросов типа приведенного ниже, вместо полного просмотра таблицы будет использоваться только что созданный нами индекс:
□ select Employee_Number, Last_.Name, First_Name from employee
where upper(Last_Name) = ‘SMITH’;
Битовые индексы
Битовые индексы имеют структуру, значительно отличающуюся от индекса со структурой В-дерева в узлах индекса. В этом индексе хранится по одной строке битов для каждого возможного значения (кардинальности) подлежащего индексации столбца. Длина строки битов равна числу строк в подлежащей индексации таблице.
Помимо очень существенной экономии памяти по сравнению с традиционными индексами, битовый индекс может обеспечить значительное сокращение времени отклика, так как Oracle может быстро удалять потенциальные строки из запроса, содержащего несколько фраз where, задолго до того, как потребуется организовать доступ к самой таблице.
Знакомство с архитектурой Oracle
23
В многочисленных битовых картах могут использоваться логические операторы and или or для определения того, какие строки должны быть отобраны из таблицы.
Хотя битовые индексы могут быть созданы для любого столбца таблицы, их применение наиболее эффективно, когда подлежащий индексации столбец имеет низкую кардинальность (число возможных значений). Для столбца Gender (пол) таблицы PERS возможными являются три значения: NULL (нет значения), F (женский) или М (мужской). Поэтому в битовом индексе по столбцу Gender будет храниться всего три битовые карты. С другой стороны, битовый индекс для столбца Last_Name будет содержать практически столько же строк (битовых карт), сколько строк в самой таблице. Вероятнее всего, запросы па получение конкретной фамилии из таблицы с использованием битового индекса потребуют столько же, если не больше, времени, чем при полном просмотре таблицы. В этом случае имеет смысл создать традиционный индекс по неуникальному ключу со структурой В-дерева.
В вариации битовых индексов, которая называется битовым индексом соединения (bitmap join index), битовый индекс создается для столбца таблицы, по которому часто производится соединение данной таблицы с одной или несколькими другими таблицами. Это приводит к огромным преимуществам в средах хранилищ данных, где битовые индексы соединения создаются для таблицы фактов и одной или нескольких таблиц измерений, по сути дела, обеспечивая предварительное соединение этих таблиц и экономя ресурсы ЦП и ввода/вывода при выполнении фактического соединения.
Примечание Битовые индексы доступы только для версии Enterprise Edition базы данных Oracle 10#.
Представления
Представления позволяют пользователям видеть специально подготовленное в соответствии с требованиями заказчика представление данных из одной или даже из нескольких (используя соединение) таблиц. Представление известно также под именем хранимого запроса (stored query) — детали определяющего представление запроса обычно скрыты от пользователей представления. Однако обычное представление не содержит данных, а только определение запроса, и лежащий в основе представления запрос выполняется всякий раз, когда происходит обращение к представлению. Расширение обычных представлений, которое называется материализованным представлением (materialized view), позволяет для ускорения обработки вместе с определением запроса сохранить и его результаты. Помимо уже названного ускорения обработки у материализованных представлений есть и другие преимущества. Объектные представления, подобно традиционным представлениям, скрывают детали лежащих в их основе соединений таблиц и обеспечивают объектно-ориентированную разработку и обработку даже в тех случаях, когда самые главные таблицы остаются в традиционном реляционном формате.
24
Гпава 1
Обычные представления
Для обычных представлений не требуется выделения какой-либо памяти. В словаре данных сохраняется только определение представления, или запрос. Таблицы запроса, составляющего основу представления, называются базовыми таблицами; каждая базовая таблица представления может быть впоследствии определена как представление.
Представление имеет множество преимуществ, например, они скрывают сложность данных: старший аналитик может определить представление, в котором будут объединены данные из таблиц EMPLOYEE, DEPARTMENT и SALARY. Это делается для того, чтобы облегчить высшему руководству компании выборку информации о зарплатах служащих с помощью оператора select из объекта, который будет казаться руководству таблицей, но на самом деле будет представлением, содержащим запрос, в котором выполняется объединение таблиц EMPLOYEE, DEPARTMENT и SALARY.
Представления могут быть использованы для обеспечения безопасности. Например, представление таблицы EMPLOYEE, которое называется EMP_INFO, может содержать все столбцы таблицы, за исключением столбца с зарплатой, причем это представление может быть реализовано в режиме “только для чтения”; это делается для предотвращения обновления таблицы:
□ create view EMP_INFO as
select Employee Number, Last. Name, First-Name, Middle_Initial, Surname from EMPLOYEE
with READ ONLY;
Без фразы read only стало бы возможным обновление представления или добавление строк к представлению, в том числе, к представлению, содержащему несколько таблиц. В представлении есть несколько конструкций, которые предотвращают возможность его модификации, например, включение оператора distinct, агрегатной функции или фразы group by.
Когда Oracle обрабатывает запрос, содержащий представления, он заменяет лежащее в основе представления определение запроса оператором select и обрабатывает получившийся в результате запрос, как будто никакого представления не существует. В результате при использовании представлений получается так, что не теряются никакие преимущества, связанные с наличием у базовых таблиц ранее определенных индексов.
Материализованные представления
В некотором смысле материализованные представления очень похожи на обычные: определение представления хранится в словаре данных, и представление скрывает от пользователей всю сложность лежащего в основе представления запроса. Но на этом сходство заканчивается. Для материализованного представления выделяется память в сегменте базы данных для хранения результатов выполнения базового запроса.
Материализованные представления могут быть использованы для создания копии таблиц “только для чтения” в других базах данных (по-другому говоря, для тиражирования). Это простейшая реализация мате
Знакомство с архитектурой Oracle
25
риального представления. Для сокращения времени отклика, когда необходимо обновить материализованное представление, можно создать так называемый журнал материализованного представления. В противном случае потребуется полное обновление материализованного представления — придется полностью повторить выполнение базового запроса. Журнал материализованного представления облегчает проведение инкрементальных обновлений материализованных представлений.
В средах хранилищ данных в материализованных представлениях могут храниться агрегированные данные из запросов group by rollup или group by cube. Если установлены соответствующие значения таких параметров инициализации, как QUERY_REWRITE_ENABLED, и сам запрос приспособлен для перезаписи запросов (посредством фразы query rewrite), то любой запрос, который, по-видимому, выполняет тот же самый тип агрегации, что и материализованное представление, автоматически будет использовать вместо исходного запроса материализованное представление.
Независимо от типа материализованное представление может быть обновлено автоматически, когда в базе данных происходит фиксируемая транзакция, либо оно может быть обновлено по запросу.
У материализованных представлений есть много схожего с индексами в том плане, что и те, и другие непосредственно привязаны к таблице и требуют для своего хранения дополнительной памяти. Их необходимо обновлять при обновлении базовых таблиц, само их существование, в конечном счете, прозрачно для пользователей, и, наконец, они могут помочь в оптимизации запросов за счет использования альтернативных путей доступа для возврата результатов запроса.
Подробнее об использовании материализованных представлений в распределенных средах см. главу 18.
Объектные представления
Разработка объектно-ориентированных (ОО) прикладных сред становится все более превалирующей, и база данных Oracle 10§полностью поддерживает реализацию объектов и методов “напрямую” в базе данных. Однако, миграция от полностью реляционных баз данных к чисто ОО средам — дело вовсе на простое; лишь немногие организации располагают достаточным временем и ресурсами для построения полностью новой системы. В Oracle 10g подобный переход облегчается с помощью объектных представлений. Объектные представления позволяют объектно-ориентированным приложениям видеть данные как совокупность объектов, обладающих атрибутами и методами, хотя в унаследованных системах по-прежнему могут выполняться пакетные задания относительно таблицы INVENTORY. Объектные представления могут имитировать абстрактные типы данных, объектные идентификаторы (OID) и ссылки, которые обеспечивает чисто ОО среда базы данных.
Как и в случае с обычными представлениями, в определении представления можно использовать триггеры instead of, чтобы разрешить выполнение блока кода PL/SQL вместо фактического оператора DML, предлагаемого пользователем или приложением.
26
Глава 1
Пользователи и схемы
Доступ к базе данных предоставляется учетной записи базы данных (database account), известной также как пользователь (user). Пользователь может существовать в базе данных, даже не владея никакими объектами. Но если пользователь создает в базе данных объекты и владеет ими, эти объекты становятся частью схемы (schema), которая носит то же самое имя, что и пользователь базы данных. Схема может владеть в базе данных любым типом объектов: таблицами, индексами, последовательностями, представлениями и т. д. Владелец схемы или АБД могут предоставить доступ к этим объектам другим пользователям базы данных. У пользователя всегда имеются полные привилегии и контроль над объектами в схеме пользователя.
Когда пользователь создается АБД (или любым другим пользователем с системной привилегией create user), ему может быть присвоено некоторое количество других характеристик, например, какие табличные пространства доступны пользователю для создания объектов, а также истек ли срок действия пароля.
В базе данных пользователи могут быть аутентифицированы одним из трех способов: с помощью аутентификации базы данных, аутентификации операционной системы или сетевой аутентификации. При аутентификации базы данных зашифрованный пароль пользователя хранится в базе данных. При аутентификации операционной системы делается предположение, что пользователь, который уже аутентифицирован подключением к операционной системе, имеет те же самые привилегии, что и пользователь с тем же самым или похожим именем (в зависимости от значения параметра инициализации OS__AUTENT_PREFIX). Сетевая аутентификация использует решения, основанные на Public Key Infrastructure (PKI — инфраструктуре открытых ключей). Для применения методов сетевой аутентификации требуется программное обеспечение Oracle 10g Enterprise Edition с опцией Oracle Advanced Security.
Профили
Ресурсы базы данных не являются неограниченными, следовательно, АБД должен управлять ресурсами и распределять их между пользователями базы данных. Примерами ресурсов базы данных являются время ЦП, параллельно выполняющиеся сеансы, операции логического чтения и время подключения.
Профилем базы данных называется именованный набор ресурсных ограничений, который может быть присвоен пользователю. После инсталляции Oracle существует профиль DEFAULT, и он присваивается любому пользователю, которому не будет явно присвоен профиль. Чтобы удовлетворить требованиям предприятия, АБД может создавать новые профили или изменять профиль DEFAULT. Первоначальные значения профиля DEFAULT подразумевают неограниченное использование всех ресурсов базы данных.
Последовательности
Последовательности Oracle (Oracle sequences) предоставляют последовательный список номеров, гарантирующий уникальность списка до тех пор, пока последовательность не будет создана заново или сброшена.
Знакомство с архитектурой Oracle
27
В многопользовательской среде опа продуцирует ряд уникальных чисел без накладных расходов на дисковые блокировки или какие-то специальные вызовы ввода/вывода, кроме связанных с загрузкой последовательности в разделяемый пул.
Последовательности могут генерировать числа с разрядностью до 38 цифр; эти числа могут быть упорядочены в возрастающем или убывающем порядке, интервал значений может быть любым заданным пользователем числом, и Oracle может кэшировать блоки чисел этой последовательности в памяти для дополнительного повышения производительности.
Числа из последовательности гарантированно являются уникальными, но не обязательно последовательными. Если кэшируется блок чисел, а после этого осуществляется перезапуск экземпляра, или если будет откачена транзакция, в которой используется число из последовательности, следующее обращение к последовательности не даст числа, которое не было использовано ранее при первоначальном обращении к последовательности.
Синонимы
Синоним Oracle является просто псевдонимом для объекта базы данных, используемым для упрощения ссылок на объекты базы данных и для сокрытия деталей источника объектов базы данных (например, чтобы при обращении к объекту можно было не указывать имя его владельца. — Прим. пер.}. Синонимы могут быть назначены таблицам, представлениям, материализованным представлениям, процедурам, функциям и пакетам. Как и для представлений, память в базе данных для синонимов не выделяется за исключением памяти для хранения определения синонима в словаре данных.
Синонимы могут быть публичными (public) или приватными (private). Приватный синоним определяется в схеме пользователя и доступен только в этой схеме (т. с. только этому пользователю. — Прим. пер.). Публичный синоним обычно создается АБД и автоматически становится доступным для использования любым пользователем базы данных.
Совет После создания публичного синонима нужно убедиться в том, что пользователи этого синонима имеют соответствующие полномочия на объект, на который ссылается синоним.
При ссылке на объект базы данных Oracle сначала проверяет, существует ли этот объект в схеме пользователя. Если объекта не существует, Oracle начинает искать приватный синоним. Если нет приватного синонима, Oracle проверяет наличие публичного синонима. Если отсутствует и публичный синоним, возвращается сообщение об ошибке.
PL/SQL
Язык PL/SQL Oracle - это процедурное расширение SQL. PL/SQL оказывается полезен в тех случаях, когда не удается достаточно просто достичь требующихся результатов с помощью операторов select и стан
28
Глава 1
дартных операторов DML, что связано с отсутствием процедурных элементов, которые можно найти, например, в таких традиционных языках программирования третьего поколения, как C++ и Ada. Начиная с Огас1е9г, для обработки SQL и PL/SQL стала использоваться одна и та же машина обработки, что означает, что все новые опции, появившиеся в SQL, будут автоматически доступны и в PL/SQL.
Процедуры/функции
Процедуры и функции PL/SQL являются примерами так называемых именованных блоков PL/SQL. Блок PL/SQL — это последовательность операторов PL/SQL, рассматриваемая в целях выполнения как модуль. Блок состоит из нескольких (до трех) секций: секция объявления переменных (variable declaration section), секция выполняемых команд (executable section) и секция исключительных ситуаций (exception section).
Различие между процедурами и функциями состоит в том, что функции возвращают одиночные значения вызвавшей их программе, например, оператору select языка SQL. Процедуры же не возвращают вызвавшей их программе никаких значений, а только код статуса. Однако процедуры также могут иметь одну или несколько переменных, которые можно установить и возвратить как часть списка аргументов процедуры.
В средах баз данных процедуры и функции имеют много преимуществ. Процедуры компилируются и сохраняются в словаре данных всего один раз; если более чем одному пользователю потребуется вызвать процедуру, она будет уже скомпилирована и в разделяемом пуле будет присутствовать только одна копия хранимой процедуры. Сюда следует добавить и сокращение сетевого трафика, даже если процедурные опции PL/SQL не используются. Для одного вызова PL/SQL может потребоваться намного меньшая полоса пропускания, чем для нескольких операторов select и insert, отдельно посылаемых по сети, не говоря уже о повторных разборках, происходящих для каждого посылаемого по сети оператора.
Пакеты
Пакеты PL/SQL группируют вместе родственные функции и процедуры, а также общие переменные и курсоры. Пакеты (packages) состоят из двух частей: спецификации пакета и тела пакета. В спецификации пакета предъявляются методы и атрибуты пакета; реализация методов, а также любые приватные методы и атрибуты оказываются скрытыми в теле пакета. Использование пакета вместо автономной процедуры или функции позволяет изменять встроенные процедуры или функции, не делая недействительным никаких объектов, обращающихся к элементам спецификации пакета, что позволяет избежать перекомпиляции объектов, ссылающихся на пакет.
Триггеры
Триггеры являются специализированным типом блоков кода PL/SQL или Java, который выполняется, или, как еще говорят, срабатывает, если происходит определенное событие. События могут быть одного из следую
Знакомство с архитектурой Oracle
29
щих типов — оператор DML для таблицы или представления, операторы DDL и даже такие события базы данных, как ее запуск или остановка. Указанный триггер может быть определен для выполнения в случае конкретного события для конкретного пользователя как часть стратегии аудита.
Триггеры оказываются исключительно полезными в распределенных средах для моделирования отношения внешнего ключа между таблицами, существующими в разных базах данных. Они также очень полезны при реализации сложных бизнес-правил, которые невозможно реализовать, используя встроенные типы ограничений Oracle.
Об использовании триггеров в устойчивой распределенной среде см. главу 18.
Доступ к внешним файлам
Помимо описанных выше внешних таблиц у Oracle есть много других способов получения доступа к внешним файлам:
Из SQL*Plus — либо получая доступ к внешнему сценарию, содержащему команды SQL для выполнения, либо посылая выходные данные SQL*P1us-koманды spool в файл файловой системы операционной системы компьютера.
Можно прочесть или записать текстовую информацию из процедуры PL/SQL, используя для этой цели встроенный пакет UTLJFILE; вызовы процедуры dbms__output внутри процедуры PL/SQL могут генерировать текстовые и диагностические сообщения, которые могут быть перехвачены другим приложением и сохранены в текстовом поле.
На внешние данные может иметься ссылка из типа данных BFILE. Тип BFILE является указателем на внешний двоичный файл. Прежде чем BFILE можно будет использовать в базе данных, необходимо создать псевдоним каталога (directory alias) с помощью команды create directory, где указывается префикс, содержащий полный путь к каталогу, в котором хранится объект BFILE.
Пакет DBMSJPIPE может связаться с любым языком третьего поколения (3GL language), поддерживаемым Oracle, например C++, Ada, Java или COBOL, и обменяться с ними информацией.
Новый пакет Oracle 10g UTL_MAIL позволяет приложению PL/SQL посылать сообщения электронной почтой, ничего не зная о том, как использовать базовый стек протоколов SMTP.
Когда внешний файл используется как источник данных (входных или выходных), вполне уместен целый ряд предосторожностей. Вот что необходимо тщательно рассмотреть, прежде чем использовать внешний источник данных:
Данные из базы данных и данные из внешнего источника часто могут быть несинхронизованными, если один из источников был изменен без синхронизации с другим.
30
Глава 1
Очень важно убедиться в том, что резервные копии этих двух источников были сделаны примерно в одно и то же время, чтобы быть уверенными в том, что при восстановлении одного из источников данных их синхронизация не будет нарушена.
Файлы сценариев могут содержать пароли; во многих организациях запрещено использование незашифрованного представления учетных записей пользователей в сценарных файлах. В такой ситуации подтверждение подлинности операционной системой может оказаться хорошей альтернативой аутентификации пользователя.
Необходимо проверить безопасность файлов, размещенных в каталоге, на который ссылаются все объекты DIRECTORY. Экстремальные меры безопасности для объектов базы данных смягчаются нестрогой защитой для файлов операционной системы, на которые делаются ссылки.
Связи баз данных и удаленные базы данных
Связи баз данных позволяют базам данных Oracle ссылаться на данные, находящиеся вне локальной базы данных. Команда create database link создает путь к удаленной базе данных, который в свою очередь позволяет обеспечить доступ к объектам в удаленной базе данных. Связь базы данных объединяет вместе имя удаленной базы данных, метод подключения к удаленной базе данных и комбинацию имя пользователя/пароль для аутентификации подключения к удаленной базе данных. В каком-то смысле связь баз данных похожа на синоним базы данных. Связь базы данных может быть либо публичной, либо приватной. Она обеспечивает удобную “скоропись” для доступа к еще одному набору ресурсов базы данных. Главное отличие между ними состоит в том, что ресурс, о котором идет речь, размещен вне базы данных, и поэтому для разрешения ссылки требуется больший объем информации. Еще одно различие состоит в том, что синоним является ссылкой на конкретный объект, в то время как связь базы данных является определенным путем, используемым для доступа к произвольному числу объектов в удаленной базе данных.
Для начала работы связей между базами данных в распределенной среде, необходимо чтобы глобальные имена обеих баз данных в домене были различными. Следовательно, необходимо корректно назначить параметры инициализации DB_NAME и DBJDOMAIN.
Чтобы еще более упростить использование связей баз данных, можно назначить связи баз данных синоним, чтобы сделать доступ к таблицам еще более прозрачным; пользователь не знает, осуществляется ли доступ с помощью синонима локально или к распределенной базе данных. Объект может быть перемещен в другую удаленную базу данных или в локальную базу данных, а имя синонима останется прежним, в результате чего доступ к объекту делается для пользователя прозрачным (об использовании связей баз данных с удаленными базами данных в распределенных средах см. главу 18).
Знакомство с архитектурой Oracle
31
Структуры физического хранения Oracle
Для хранения данных из транзакций пользователей и управления ими база данных Oracle использует целый ряд структур надиске. В некоторых из этих структур, например в файлах данных, журнальных файлах и в архивных журнальных файлах хранятся реальные данные пользователей. Другие структуры, например управляющие файлы, используются для поддержания состояния объектов базы данных, тогда как текстовые файлы предупреждений и трассировки содержат протокольную информацию как об обычных (рутинных) событиях, так и об ошибочных ситуациях в базе данных. На рис. 1.3 изображено отношение между этими физическими структурами и логическими структурами памяти, рассмотренными выше.
Файлы данных
Каждая база данных состоит из одного или нескольких файлов данных. Каждый файл данных соответствует одному файлу операционной системы на диске и в базе данных Oracle может принадлежать одному и только одному табличному пространству; однако табличное пространство может состоять из нескольких файлов данных.
Файл данных Oracle может быть автоматически расширен, если вы вышли за пределы емкости диска, а АБД создал файл данных с параметром AUTOEXTEND. АБД может ограничить пределы расширения памяти для заданного файла данных, используя параметр MAXSIZE. В любом случае,
Рис. 1.3. Структуры физического хранения Oracle
32
Гпава 1
размер файла данных в конечном счете ограничен объемом дискового тома, на котором он размещается.
Совет Часто АБД приходится принимать решение, что лучше: выделить память под один файл данных, который может авторасширяться до бесконечности, или выделить память для большого числа меньших по размеру файлов данных, и задать для них максимальный размер, до которого (но не более) они могут быть расширены. Хотя производительности этих решений, скорее всего, будут близки друг к другу, вероятно, более удачным будет решение с большим числом файлов данных, размер каждого из которых не превосходит 2 Гбайт. Намного легче перемещать относительно небольшие по размеру файлы, к тому же, некоторые файловые системы ограничивают размер индивидуальных файлов 2 Гбайт. Кроме того, если возникает необходимость временно переместить все файлы данных, образующие табличное пространство, на другой сервер, часто оказывается проще найти несколько дисковых томов, на каждом'из которых можно разместить один из файлов данных, чем один том, на котором достаточно свободного места, чтобы разместить один файл данных размером в 25 Гбайт.
Именно файл данных является окончательной “посадочной площадкой” для всех данных в базе данных. Блоки файлов данных, к которым имеются частые обращения, кэшируются в памяти; аналогично, новые блоки данных не записываются немедленно в файлы данных, точнее будет сказать, что они записываются в файлы данных, когда становится активным процесс записи в базу данных (database writer). Однако прежде чем транзакцию пользователя можно будет считать завершенной, произведенные транзакцией изменения записываются в файлы журналов.
Файлы журнала
Всякий раз, когда в таблицах, индексах или других объектах Oracle добав-ляются, удаляются или изменяются данные, производится соответствующая запись в текущий файл Э!сурнала базы данных. Каждая база данных Oracle должна иметь не менее двух таких файлов, так как Oracle использует файлы журнала циклически. После заполнения журнальными записями (redo log entries) первого файла текущий журнальный файл помечается как ACTIVE, если он продолжает оставаться необходимым для восстановления экземпляра, или как INACTIVE, если он более не требуется для восстановления экземпляра; следующий журнальный файл используется повторно с самого начала файла и помечается как CURRENT.
В идеале, информация из файла журнала базы данных не должна быть использована никогда. Однако, если происходит отключение электроэнергии или какие-либо другие отказы сервера, которые приводят к прекращению работы экземпляра Oracle, может оказаться, что новые или недавно обновленные блоки данных из кэша буферов базы данных еще записаны в соответствующие файлы данных. При повторном запуске экземпляра Oracle записи из файлов журналов базы данных применяются к файлам базы данных в рамках операции так называемой прокрутки вперед (roll forward, или — па профессиональном жаргоне — накат. — Прим, пер.),
Знакомство с архитектурой Oracle
33
целью которой является восстановление состояния базы данных на момент, предшествующий отказу экземпляра.
Чтобы иметь возможность восстановления в случае потери одного из файлов журнала базы данных, входящих в группу журнальных файлов, можно создать несколько копий этого файла на различных физических дисках. Ниже в данной главе будет показано, как можно мультиплексировать файлы журналов базы данных, архивные файлы журналов базы данных и управляющие файлы, чтобы быть уверенными в доступности базы данных Oracle и целостности хранящихся в ней данных.
Управляющие файлы
У каждой базы данных Oracle имеется хотя бы один управляющий файл (control file), в котором поддерживаются метаданные базы данных (другими словами, данные о физической структуре самой базы данных).
Наряду с другими вещами, в нем содержится имя базы данных, дата (и время) создания базы данных, а также имена и места размещения всех файлов данных и журнальных файлов. Помимо этого в управляющем файле поддерживается информация, используемая диспетчером восстановления (RMAN — Recovery Manager); например все постоянные настройки и типы резервных копий, которые были созданы для базы данных (подробнее о RMAN см. главу 13). Всякий раз, когда в структуру базы данных вносятся какие бы то ни было изменения, информация об этих изменениях немедленно отражается в управляющем файле.
Поскольку управляющие файлы имеют огромное значение для базы данных, они также могут быть подвергнуты мультиплексированию. Однако неважно, сколько именно копий управляющего файла связаны с экземпляром, только один из управляющих файлов выделяется как основной файл для целей выборки метаданных о базе данных.
Команда alter database backup control file to trace является еще одним способом копирования управляющего файла. Она продуцирует сценарий SQL, который может быть использован для повторного создания управляющего файла базы данных на тот случай, если все мультиплексированные двоичные версии управляющего файла утеряны вследствие катастрофического отказа.
Этот трассировочный файл может быть также использован, например, для повторного создания управляющего файла, если базу данных необходимо переименовать или изменить какие-то лимиты базы данных, изменение которых невозможно без полного пересоздания всей базы данных.
Архивные файлы журналов базы данных
База данных Oracle может функционировать в одном из двух режимов — archivelog или noarchivelog. Когда база данных находится в режиме noarchivelog, циклическое (по кругу) повторное использование файлов журналов базы данных (которые также известны под названием оперативных журнальных файлов) означает, что записи журнала (содержимое предыдущих транзакций) перестают быть доступными в случае отказа ДИСКОВОГО носителя ИЛИ любой Л ПУГОЙ ——......-
34
Гпава 1
носителями информации. Работа в режиме noarchivelog не обеспечивает целостности базы данных при выходе из строя экземпляра или аварийной ситуации с системой, так как все завершенные к моменту аварии, но еще не записанные в файлы данных транзакции, могут уже не присутствовать в оперативных журнальных файлах.
Напротив, режим archivelog посылает заполненные файлы журналов базы данных по одному (или нескольким) адресам, и они становятся доступными для реконструкции базы данных в любой момент времени, если с носителями информации базы данных что-то произойдет. Так, например, если дисковое устройство, содержащее файлы данных будет выведено из строя, содержимое базы данных может быть восстановлено по состоянию на момент времени непосредственно перед этим прискорбным событием, если доступны недавно сделанная резервная копия файлов данных и файлы журналов базы данных, сгенерированные после этого копирования.
Использование нескольких адресов для архивации заполненных журналов очень важным для одной из возможностей обеспечения высокой доступности Oracle, известной под названием Oracle Data Guard (раньше она называлась Oracle Standby Database — резервная база данных Oracle) (подробнее об Oracle Data Guard см. главу 14).
Файлы параметров инициализации
При запуске экземпляра базы данных выделяется память для экземпляра Oracle и открывается один их двух типов файла параметров инициализации: либо текстовый файл, который называется init.ora (известен под родовым именем init.ora или PFILE), либо файл параметров сервера (известен под именем SPFILE). Сначала экземпляр ищет SPFILE по используемому по умолчанию адресу операционной системы (например, $ORACLE_HOME/dbs для Unix), причем использует имя spfile.ora или spfile.ora. Если ни один из названных выше файлов по этому адресу пе обнаружен, экземпляр переходит к поиску файла PFILE с именем init.ora. Можно непосредственно указать в команде startup PFILE, чтобы использовать при запуске именно его.
Файлы параметров инициализации — независимо от их формата — определяют места размещения трассировочных файлов, управляющих файлов, заполненных файлов журналов базы данных и так далее. Кроме того, они устанавливают предельные значения размеров различных структур в системной глобальной области (SGA) и максимальное число одновременно разрешенных подключений пользователей к базе данных.
До появления Огас1е9г единственным способом задания параметров инициализации экземпляра было использование файла init.ora. Хотя он легко редактируется с помощью текстового редактора, у него есть некоторые недостатки. Если динамический параметр системы изменяется из командной строки с помощью команды alter system, АБД должен не забыть изменить файл init.ora, чтобы новое значение параметра вступило в силу при следующем перезапуске экземпляра.
Применение SPFILE значительно упрощает управление параметрами и делает его более эффективным для АБД. Если для рабо х ающсго экземпляра используется SPFILE, любая команда alter system, изменяющая пара
Знакомство с архитектурой Oracle
35
метр инициализации системы, может автоматически изменить параметр инициализации в SPFILE, изменить его только для работающего экземпляра или сделать и то, и другое. Не Только не требуется никакого редактирования SPFILE, оно попросту невозможно, так как в результате редактирования SPFILE будет разрушен.
Хотя невозможно создать “зеркало” файла параметров или SPFILE как таковых, можно создать резервную копию SPFILE в файле init.ora, а оба файла — и init.ora, и SPFILE — должны копироваться с использованием либо традиционных команд операционной системы, либо RMAN в случае SPFILE.
Если для создания базы данных используется DBCA, по умолчанию создается SPFILE.
Сигнальный файл ALERT и файл трассировки
Когда дела начинают идти не так, Oracle часто делает записи (записывает сообщения) в так называемый файл сигнального журнала (alert log), а в случае фоновых процессов или сеансов пользователей и в файл трассировочного журнала (trace log). С
В файле сигнального журнала ALERT, размещенном в каталоге, на который указывает параметр инициализации BACKGROUND_DUMP_ DEST, содержатся как обычные сообщения о состоянии (status messages), так и сообщения о нештатных ситуациях. Когда база данных запускается или останавливается, в файл сигнального журнала делаются соответствующие записи, вместе со списком параметров инициализации, отличающихся от своих значений по умолчанию. Кроме того, фиксируется любая команда alter database или alter system, выданная АБД. Здесь также фиксируются операции, где участвуют табличные пространства и входящие в них файлы данных, например, добавление или удаление табличного пространства, добавление файла данных к табличному пространству. Кроме того, здесь также фиксируются такие исключительные ситуации, как переполнение табличного пространства, разрушение файлов журналов базы данных и т. п.
Трассировочные файлы для фоновых процессов экземпляра Oracle также содержатся в BACKGROUND-DUMPJDEST. Например, в трассировочные файлы для процессов PMON и SMON будут сделаны записи, если происходит ошибка или если процессу SMON необходимо провести восстановление экземпляра; файлы трассировки для процесса QMON содержат информационные сообщения, когда он порождает новый процесс.
Кроме того, трассировочные файлы создаются и для сеансов индивидуальных пользователей или подключений к базе данных. Эти файлы размещены в каталоге, на который указывает параметр инициализации USER DUMP-DEST. Трассировочные файлы для процессов пользователей создаются в двух ситуациях: во-первых, когда некоторые типы ошибок происходят в сеансе пользователя вследствие проблемы с привилегиями, выходом за пределы отведенного пространства и тому подобных. Во второй ситуации трассировочный файл может быть создан явно, с помощью команды alter session set sql_trace~true Трассировочная информация генерируется для каждого оператора SQL, выполняемого пользователем, что может оказаться полезным при настройке оператора SQL.
36
Гпава 1
Сигнальный файл alert может быть удален или переименован в любой момент времени; он будет повторно создан, как только будет сгенерировано новое сообщение в сигнальный файл. Часто АБД создает пакетное задание (используя для этого либо средства операционной системы, либо планировщик Oracle Enterprise Manager) для ежедневного переименования и архивации сигнального файла alert.
Файлы резервных копий
Файлы резервных копий могут происходить из многих источников, например, их можно получить с помощью команд копирования операционной системы или с помощью RMAN. Если АБД выполняет так называемое “холодное” резервное копирование (“cold” backup), о чем будет рассказано подробнее в разделе “Обзор резервного копирования/восстановления”. Там речь пойдет о различных разновидностях резервного копирования, то файлы резервных копий являются просто созданными операционной системой копиями файлов данных, журнальных файлов, управляющих файлов, архивированных журнальных файлов и тому подобного.
Помимо побитовых копий образов файлов данных (этот режим является режимом RMAN по умолчанию), RMAN способен генерировать полные и инкрементальные резервные копии файлов данных, контрольных файлов, журнальных и архивных журнальных файлов и SPFILE, которые получаются в специальном формате, получившем название набора резервных копий (backupset), читать который в состоянии только RMAN. Сделанные в формате набора резервных копий резервные копии RMAN, как правило, меньше исходных файлов данных, потому что RMAN не копирует неиспользованные блоки.
Файлы, управляемые сервером Oracle
Управляемые сервером Oracle файлы (Oracle Managed Files — OMF), впервые появившиеся в версии 9 г Oracle, значительно облегчают задачу АБД, позволяя автоматизировать задачу создания и удаления файлов данных, из которых состоят логические структуры базы данных.
Если OMF не используется, то при удалении из базы данных табличного пространства АБД может забыть удалить базовые файлы операционной системы, используемые для поддержки данного табличного пространства. Это делает неэффективным использование ресурсов дисков и необоснованно увеличивает время создания резервных копий для файлов данных, которые больше не требуются базе данных.
OMF хорошо подходит для малых баз данных с небольшим числом пользователей и работающим неполный рабочий день АБД, т. е. в ситуации, когда не обязательна оптимальная конфигурация промышленной версии базы данных.
Файлы паролей
Файлом паролей Oracle (password file) называется файл, размещенный внутри административной или софтверной структуры каталогов Oracle на диске, используемой для аутентификации администраторов системы Oracle в случае задач типа создания базы данных или запуска и остановки
Знакомство с архитектурой Oracle
37
базы данных. Привилегии, предоставляемые посредством этого файла, называются привилегиями SYSDBA и SYSOPER. Аутентификация всех остальных типов пользователей выполняется внутри самой базы данных; поскольку база данных может быть выключена или не смонтирована, для этих случаев требуется иная форма аутентификации администратора.
Утилита orapwd командной строки Oracle создает файл паролей, если он не существует или поврежден. В связи со слишком большими привилегиями, предоставляемыми посредством этого файла, он должен храниться в защищенном каталоге, который недоступен ни для кого, за исключением АБД и администраторов операционной системы. После того как этот файл создан, параметр инициализации REMOTE_LOGIN_PASSWORDFILE должен быть установлен на EXCLUSIVE, чтобы позволить другим пользователям, кроме пользователя SYS, использовать файл паролей.
Совет Создайте, по крайней мере, еще одного пользователя, кроме пользователей SYS или SYSTEM, у которого имеются привилегии АБД для ежедневных административных задач. Если у базы данных есть несколько АБД, занимающихся ее администрированием, каждый из них должен иметь свою собственную учетную запись с привилегиями АБД.
Аутентификация привилегий SYSOPER и SYSDBA может быть выполнена с помощью аутентификации операционной системы; в этом случае нет необходимости создавать файл паролей, и параметр инициализации REMOTEJLOGINJPASSWORDFILE должен быть установлен на NONE.
Мультиплексирование файлов базы данных
Для сведения к минимуму возможности потери управляющего или файла журналов базы данных применяется мультиплексирование файлов базы данных, призванное сократить или полностью устранить проблемы потери данных, вызванные отказами носителей. Мультиплексирование может отчасти быть автоматизировано путем использования экземпляра Automated Storage Management (ASM — автоматизированное управление памятью), ставшего доступным в Oracle 10g. Для предприятий, вынужденных экономить средства, мультиплексирование управляющих и файлов журналов базы данных может быть выполнено вручную.
Автоматизированное управление памятью
Применение автоматизированного управления памятью (Automatic Storage Management—ASM) представляет собой решение мультиплексирования,
которое автоматизирует компоновку файлов данных, управляющих и файлов журналов базы данных, распределяя их по всем доступным дискам. Когда к кластеру ASM добавляются новые диски, файлы базы данных автоматически перераспределяются по всем дисковым томам для обеспечения оптимальной производительности. Опции мультиплексирования кластера ASM сводят к минимуму возможности потери данных и обычно являются более эффективными, чем ручная схема, размещающая критичные файлы и резервные копии на различные (Ьизичегкмт- vcmniir
38
Глава 1
Ручное мультиплексирование
Даже без решений RAID и ASM мы можем обеспечить некоторые меры предосторожности для критичных файлов базы данных, устанавливая значения некоторых параметров инициализации и предоставляя дополнительные адреса для управляющих файлов, файлов журналов базы данных и архивных файлов журналов базы данных.
Управляющие файлы
Управляющие файлы можно мультиплексировать сразу же при создании базы данных, либо они могут быть мультиплексированы позже путем включения дополнительных шагов для ручного копирования их в различные пункты назначения. Может быть создано до восьми различных копий управляющего файла.
Независимо от того, когда мультиплексируется управляющий файл — при создании базы данных или позже, значение параметра инициализации CONTROL-FILES должно быть одним и тем же. В следующем примере мультиплексируются три копии управляющего файла:
□ Alter system
set control_files = ‘/u01/oracle/whse2/ctrlwhse1.ctl’, ‘/u01/oracle/whse2/ctrlwhse2.ctl’, */u03/oracle/whse2/ctrlwhse3.ctl’, scope = spfile;
Если база данных создается с такими значениями параметров, буду!' созданы три управляющих файла и никаких дополнительных шагов не потребуется.
Если желательно добавить другое мультиплексированное место хранения, необходимо отредактировать параметр инициализации и добавить к параметру CONTROL-FILES еще одно место хранения файлов. Если вместо файла init.ora используется SPFILE, то для изменения параметра ' CONTROL-FILES следует использовать что-то вроде:
□ alter system
set control-files = ‘/u01/oracle/whse2/ctrlwhse1.ctl’, ‘/u01/oracle/whse2/ctrlwhse2.ctl’, ‘/u03/oracle/whse2/ctrlwhse3.ctl’, scope = spfile;
Другими возможными значениями параметра SCOPE в команде alter system являются MEMORY и BOTH. При указании их в качестве значения параметра SCOPE, будет получено сообщение об ошибке, поскольку параметр CONTROL-FILES не может быть изменен для работающего экземпляра. Изменения могут вступить в силу только при следующем запуске экземпляра. Следовательно, будет изменен только SPFILE.
В любом случае, следующим шагом должна быть остановка базы данных. Скопируйте управляющие файлы в новые пункты назначения, специфицированные в параметре CONTROL-FILES, и перезапустите базу данных. Проверить имена и места расположения управляющих файлов с помощью одного из следующих представлений словаря данных:
П qpipct values from v$spparameter-where name = control-files';
Знакомство с архитектурой Oracle
39
Этот запрос возвратит одну или несколько мультиплексированных копий управляющих файлов. В дополнение к сказанному выше, представление V$CONTROLFILE содержит одну строку для каждой копии управляющего файла и его состояния. •
Файлы журналов базы данных
Мультиплексирование файлов журналов базы данных осуществляется путем превращения набора журнальных файлов в так называемую группу журнальных файлов (redo lig file group). В проводимой по умолчанию инсталляции Oracle создается набор из трех файлов журналов базы данных. После того как будет заполнен первый журнал, автоматически начинается заполнение следующего по очереди (т. е. второго, а затем третьего). После того как будет заполнен третий журнал, система перейдет к повторному заполнению первого. Чтобы превратить набор из трех файлов журналов базы данных в группу, можно добавить один или не^голько идентичных файлов “в напарники” существующим файлам. После создания группы файлов журналов базы данных записи журнала будут параллельно записываться во все файлы группы журналов. После заполнения первой группы журналов начинается заполнение следующей группы. На рис. 1.4 показано, как можно мультиплексировать набор из четырех файлов журналов базы данных в четыре группы, каждая из которых содержит по три члена группы.
Добавление члена в группу файлов журналов базы данных очевидно. В команде alter database указываются имя нового файла и та группа, в которую он должен быть добавлен. Размер вновь создаваемого файла совпадает с размерами всех остальных членов группы:
□ alter database
add logfile member ‘u05/oracle/dc2/log_3d.dbf ’ to group 3;
Файлы журналов Файлы журналов Файлы журналов Файлы журналов базы данных: базы данных: базы данных: базы данных: группа 1 группа 2 группа 3 группа 4
Рис. 1.4. Мультиплексирование файлов журналов базы данных
Физический ДИСК1
Физический диск 2
Физический дискЗ
40
Глава 1
Если файлы журналов базы данных заполняются быстрее, чем они могут быть архивированы, одним из возможных решений может стать добавление еще одной группы журналов. Ниже приводится пример, как можно добавить пятую группу файлов к набору групп журналов на рис. 1.4:
□ alter database
add logfile group 5
(‘u02/oracle/dc2/log_3a.dbf’,
‘u03/oracle/dc2/log_3b.dbf ’,
‘u04/oracle/dc2/log_3c.dbf’) size 10m;
Все члены журнальной группы должны иметь один и тот же размер. Однако файлы журналов базы данных из разных групп могут иметь разные размеры. Кроме того, в журнальных группах может быть разное количество членов. В предыдущем примере мы начали с четырех журнальных групп, добавили дополнительный член в журнальную группу номер 3 (чтобы в ней стало 4 члена), а затем добавили пятую журнальную группу, состоящую из трех членов.
Начиная с Oracle 10g, для помощи при определении оптимальных размеров файлов журналов базы данных можно использовать утилиту Redo Logfile Sizing Advisor, позволяющую избежать избыточной деятельности ввода/вывода или заторов (подробнее об использовании Redo Logfile Sizing Advisor см. главу 8).
Архивные файлы журналов базы данных
Если база данных функционирует в режиме archivelog, файлы журналов базы данных копируются в специально указанные места (на диске), прежде чем их можно будет повторно использовать в цикле переключения этих файлов.
Структуры памяти Oracle
Oracle использует физическую (оперативную) память сервера для хранения множества различных вещей для экземпляра Oracle: самого выполняемого кода, информации о сеансе, индивидуальных процессов, ассоциируемых с базой данных, и информации, совместно используемой всеми процессами (типа блокировок объектов базы данных). Помимо этого, структуры памяти содержат пользовательские операторы SQL и операторы SQL словаря данных совместно с кэшированной информацией, которая, в конечном счете, будет записана на диск для постоянного хранения, например блоки данных сегментов базы данных и информация о завершенных транзакциях базы данных. Область данных, выделенная для экземпляра Oracle, называется системной глобальной областью (System Global Area — SGA). Выполняемые коды Oracle размещаются в области программного кода. В дополнение к сказанному, для каждого серверного или фонового процесса выделяется специальная область, которая называется глобальной программной областью (Program Global Area — PGA); для каждого процесса выделяется собственная PGA. На рис. 1.5 показаны взаимоотношения между структурами памяти Oracle.
Знакомство с архитектурой Oracle
41
SGA
Разделяемая память
Кэш буферов базы данных (размер по умолчанию)
Удерживающий (KEEP) буферный пул
Рециклирующий (RECYCLE) буферный пул
Кэш буферов базы данных (размер пКбайт)
Кэш буферов базы данных (размер пКбайт) .. -________________________.....
Большой пул
Пул Java
Потоковый пул
Кэш буферов журналов
Разделяемый пул
Резервируемый пул
Библиотечный кэш
Кэш словаря данных
Разделяемая область SQL
Управляющие Стру^;рЬ!
Процедуры и пакеты PL/SQL
Постоянная SGA
Область программного кода
PGA
Неразделяемая память
Область стека Информация сеанса Область сортировки, хеширования и слияния 5
Рис. 1.5. Логические структуры памяти Oracle
Системная глобальная область
Системной глобальной областью (SGA) называется группа разделяемых структур памяти для экземпляра Oracle, совместно используемых всеми пользователями экземпляра базы данных. Когда запускается экземпляр Oracle, память для SGA выделяется на основании значений, специфицированных в файле параметров инициализации или жестко закодированных в программном обеспечении Oracle. Многие из параметров, управляющих размерами различных частей SGA, являются динамическими; однако, если будет специфицирован параметр SGA_MAX_SIZE, суммарный размер всех областей SGA не должен превышать значения SGA_ MAX SIZE. Если же значение SGA_MAX_SIZE не указано, но указан параметр SGA__TARGET, Oracle автоматически подгоняет размеры компонентов SGA, чтобы получающийся в итоге суммарный объем выделенной памяти был равен SGA.TARGET. Параметр SGA_TARGET является Динамическим; он может быть изменен при работающем экземпляре.
Память в SGA выделяется блоками, или гранулами (granules). Размер гранулы может быть равен либо 4 Мбайт, либо 16 Мбайт в зависимости от оощего размера SGA. Если SGA не превосходит 128 Мбайт, гранула устанавливается равной 4 Мбайт; в остальных случаях она равна 16 Мбайт.
Буферные кэши
Буферный кэш (buffer cache) базы данных содержит блоки данных с диска, оторые были недавно прочитаны-для удовлетворения оператора select, ли которые содержат модифицированные блоки, измененные или до
42
Глава 1
бавленные в результате выполнения операторов DML. Начиная с Огас1е9г, эта область памяти в SGA стала динамической. Это очень хорошо, особенно если учесть, что в базе данных могут быть табличные пространства с размерами блоков, отличающимися от принятых по умолчанию; для табличных пространств, имеющих до пяти различных размеров блоков данных (один размер блока, используемый по умолчанию, и еще четыре других размера блока), требуются собственные буферные кэши. При изменении потребностей в обработке и транзакционных потребностей на протяжении суток (или недели), значения параметров DB_ CACHEjSIZE и DB_nK_CACHE_SIZE могут изменяться динамически, не требуя перезапуска экземпляра для повышения его производительности для табличного пространства с заданным размером блока данных.
Oracle может использовать два дополнительных кэша с тем же размером блока, что и размер блока по умолчанию (DB_CACHE_SIZE): удерживающий буферный пул и рециклирующий буферный пул. Начиная с Огас1е9г, для обоих этих пулов память выделяется независимо от прочих кэшей в составе SGA.
При создании таблицы для нее можно указать пул, в котором будут храниться блоки данных таблицы, специфицировав во фразе STORAGE либо фразу BUFFERJWOL-KEEP, либо фразу BUFFERJ3ACHE_RECYCLE. Для таблиц, которые часто используются на протяжении одного дня, предпочтительнее хранить блоки данных в удерживающем (KEEP) буферном пуле, чтобы свести к минимуму количество операций ввода/вывода, необходимых для выборки блоков таблицы.
Разделяемый пул
В области разделяемого пула сохраняются данные из словарного и библиотечного кэша. Размер разделяемого пула устанавливается значением параметра инициализации SHARED_POOL_SIZE. Это еще один динамический параметр, значение которого может быть изменено, если общий размер SGA меньше, чем SGA_MAX_SIZE или SGA_TARGET.
Библиотечный кэш
Библиотечный кэш хранит информацию об операторах SQL и PL/SQL, выполняемых в базе данных. Поскольку библиотечный кэш совместно используется всеми пользователями, много различных пользователей получают возможность совместно использовать одни и те же операторы SQL.
Вместе с самими операторами SQL в библиотечном пуле содержатся планы выполнения и дерево грамматического разбора операторов SQL, хранящихся в библиотечном пуле. При повторном использовании того же оператора SQL тем же самым или другим пользователем, оказывается, что план выполнения и информация о результатах грамматического разбора уже вычислены, что позволяет ускорить выполнение запроса или любого другого оператора DML.
Если библиотечный пул слишком мал, планы выполнения и деревья грамматического операторов будут постоянно выталкиваться из кэша, требуя частой перезагрузки операторов SQL в библиотечный кэш (о спО' собах мониторинга эффективности библиотечного кэша см. главу 9).
Знакомство с архитектурой Oracle
43
Словарный кэш
Словарем данных называется совокупность таблиц базы данных, которыми владеют схемы SYS и SYSTEM, и в которых содержится метаданные о самой базе данных, ее структуре, а также о привилегиях и ролях пользователей базы данных. В словарном кэше (data dictionary cache) сохраняются кэшированные блоки словаря данных. Блоки данных таблиц словаря данных постоянно используются для помощи при обработке запросов пользователей и других команд DML.
Если размер словарного кэша очень мал, запросы информации из таблиц словаря вызывают “лишние” операции ввода/вывода; эти запросы, с ограничениями ввода/вывода называются рекурсивными (recursive calls), и их можно избежать, если правильно выбрать размер словарного кэша.
Буфер журналов базы данных
В этом буфере хранятся самые последние изменения, вносимые в блоки данных файлов данных. Когда буфер журналов базы данных становится заполненным на треть (или через каждые три секунды), записи журнала записываются в журнальные файлы. Записи из этого буфера, после того как они записываются в файлы журналов базы данных, становятся критичными для восстановления базы данных при отказе экземпляра как раз перед тем, как измененные блоки данных будут записаны из буферного кэша в файлы данных. Зафиксированные (committed) транзакции пользователя не считаются завершенными, пока записи журнала не будут успешно переписаны в файлы журналов базы данных.
Большой пул
Большой пул — это необязательная (опциональная) область SGA. Он ис-пользуется для транзакций, взаимодействующих с более чем одной базой данных, для буферов сообщений для процессов, выполняющих параллельные запросы и для операций параллельного резервного копирования/ восстановления RMAN. Как следует из имени пула, большой пул делает доступными большие блоки памяти для операций, которым единовременно требуются большие блоки памяти.
Параметр инициализации LARGE__POOOL_SIZE контролирует размер большого пула; начиная с Огас1е9г release 2, этот параметр стал динамическим.
Пул Java
Пул Java используется Oracle JVM (Java Virtual Machine — виртуальная машина Java) для всего кода Java и данных сеанса пользователя. Сохранение кода Java и данных в пуле Java аналогично кэшированию в разделяемом пуле кода SQL и PL/SQL.
Потоковый пул
Новинкой Oracle 10g является так называемый потоковый пул (streams
Для заДания его размера используется параметр инициализации 1REAMS_POOL_SIZE. В потоковом пуле хранятся данные и управляю
44
Глава 1
щие структуры для поддержки опции Oracle Streams (потоки) для Oracle Enterprise Edition (среда Oracle для больших предприятий, корпоративная среда). Технология Oracle Streams управляет разделением данных и событий в распределенных средах. Если параметр инициализации STREAMS_POOL_SIZE не был проинициализирован или если его значение было установлено равным нулю, используемая для операций Streams память выделяется из разделяемого пула и может использовать до 10% общего пула (подробнее об Oracle Streams см. главу 18).
Программная глобальная область
Программная глобальная область (Program Global Area — PGA) — это область памяти, используемая одним пользовательским процессом Oracle. Память в PGA не является разделяемой. Конфигурация PGA зависит от конфигурации соединения (connection configuration) базы данных Oracle: разделяемый (shared) или выделенный (dedicated) сервер.
В конфигурации разделяемого сервера несколько пользователей разделяют (совместно используют) подключение к базе данных, сводя к минимуму использование памяти на сервере, но потенциально влияя при этом на время отклика на запросы пользователя, В среде разделяемого сервера информация о сеансе пользователя хранится в SGA, а не в PGA. Среды разделяемого сервера являются идеальными для большого числа одновременных подключений к базе данных с нечастыми или с быстро выполняющимися запросами.
В среде выделенного сервера каждый процесс пользователя получает свое собственное подключение к базе данных; для такой конфигурации вся память сеанса содержится в PGA.
В PGA включена также область сортировки. Она используется всякий раз, когда запросу пользователя требуется провести операцию сортировки, слияния битовых индексов или хеш-соединение.
Начиная с Огас1е9г, параметр инициализации PGA_AGGREGATE_ TARGET в сочетании с параметром инициализации WORKAREA_SIZE_ POLICY может облегчить администрирование системы, разрешив АБД выбирать общий размер всех рабочих областей и позволив Oracle выделять память для всех процессов пользователя и управлять ею.'
Область программного кода
В областях программного кода хранятся файлы выполняемых модулей Oracle, выполняющиеся как часть экземпляра Oracle. Эти области кода являются статичными по природе, и могут быть изменены только после инсталляции нового релиза (выпуска) программного обеспечения. Как правило, коды программного обеспечения Oracle размещаются в привилегированной области памяти отдельно от других программ пользователей.
Программный код Oracle можно использовать только для чтения (режим read-only), и он может быть инсталлирован либо как разделяемый, либо как неразделяемый. При инсталляции кода программного обеспечения Oracle как разделяемого будет сэкономлено много памяти в том случае, если на одном сервере выполняется несколько экземпляров Oracle, использующих один и тот же релиз программного обеспечения.
Знакомство с архитектурой Oracle
45
Фоновые процессы
При запуске экземпляра Oracle запускается множество так называемых фоновых процессов (background processes). Фоновым процессом называется блок исполняемого кода, разработанный для выполнения некоторой задачи. На рис. 1.6 изображены взаимоотношения между фоновыми процессами, базой данных и SGA Oracle. В противоположность процессам переднего плана, примером которого может служить сеанс SQL*Plus или web-браузер, фоновый процесс работает, так сказать, “за кулисами”. Совокупность SGA и фоновых процессов и составляет экземпляр Oracle.
SMON
SMON означает процесс системного монитора (System Monitor — SMON). При катастрофическом сбое системы или выходе из строя (отказе) экземпляра вследствие отключения питания или отказа ЦП процесс SMON вы-
RECO
•PMON
SMON
Системная глобальная область
Кэш буферов базы данных
Журнальный буфер
Процесс пользователя
Процесс разделяемого сервера
Процесс выделенного сервера
Процессы пользователей
--1-
D000
Пояснения к рисунку:
ПЕСО Процесс восстановления
PM0N Монитор процессов SMON Системный монитор СКРТ Процесс выполнения контрольных точек
СО Процесс архивирования
OB jo Процесс записи в базу данных
LGWH Процесс записи вжурнал
0000 Диспетчерский процесс
СКРТ
____
DBW0
Процесс пользователя
ARCO
LGWR
Автономное запоминающее устройство
Управляющие файлы
Журнальные файлы
Рис. 1.6. Фоновые процессы Oracle
46
Гпава 1
полняет восстановление, применяя записи оперативных журнальных файлов. Кроме того, во время перезапуска системы он удаляет временные сегменты во всех табличных пространствах.
Одной из обычных задач SMON является объединение расположенных рядом свободных областей в табличных пространствах на регулярной основе, если табличное пространство является управляемым по словарю.
PM0N
Если подключение пользователя удалено или процесс пользователя закончился неудачей по любой другой причине, PMON, известный также как монитор прогрессов, уничтожает результаты работы таких процессов. Он очищает кэш буферов базы данных вместе с любыми другими ресурсами, использовавшимися подключением пользователя. Например, сеанс пользователя может обновлять некоторые строки таблицы, помещая блокировку на одну или несколько строк. Из-за грозы отключилось электричество в настольном компьютере пользователя, и из-за обесточивания компьютера “слетел” сеанс SQL*Plus. В считанные мгновения PMON обнаружит, что соединения больше не существует, и выполнит следующие задачи:
Откатит транзакцию, выполнявшуюся в момент отключения электроэнергии
Пометит блоки транзакции в буферном кэше, как доступные
Снимет блокировки с задействованных строк таблицы
Удалит идентификатор (process ID) отсоединенного процесса из списка активных процессов
Кроме того, PMON взаимодействует с прослушивающими процессами, предоставляя информацию о состоянии экземпляра для входящих запросов на подключение.
DBWn
Процесс записи в базу данных, известный в предыдущих версиях Oracle как DBWR, записывает новые или измененные блоки данных (известные также под названием грязные блоки [dirty blocks]) из кэша буфера в файлы данных. Используя алгоритм LRU, процесс DBWn в первую очередь записывает самые старые, наименее активные блоки. В результате наиболее часто запрашиваемые блоки, даже если они являются грязными, остаются в оперативной памяти.
Может быть запущено до 20 процессов DBWn с именами от DBW0 до DBW9 и от DBWa до DBWj. Количество процессов DBWn управляется параметром DB_WRITER_PROCESSES.
LGWR
Фоновый процессЪО\/\Г&, или процесс записи в журнал (Log Writer) отвечает за управление буфером журнала. Процесс LGWR является одним из самых активных процессов в экземпляре, имеющем высокую активность
Знакомство с архитектурой Oracle
47
DML. Транзакция не считается завершенной до тех пор, пока LGWR успешно не запишет информацию, включая зафиксированную запись, в файлы журналов базы данных. Кроме того, грязные буферы в буферном кэше не могут быть записаны в файлы данных с помощью процесса DBWn, пока LGWR не запишет информацию.
Если файлы журналов базы данных объединены в группы и один из мультиплексированных журнальных файлов окажется поврежденным, процесс LGWR запишет информацию в оставшиеся члены группы и зарегистрирует ошибку в сигнальном файле. Если все члены группы окажутся непригодными для использования, процесс LGWR завершится неудачей и весь экземпляр “подвиснет”, пока проблема не сможет быть разрешена.
ARCn
Если база данных работает в режиме ARCHIVELOG, прогресс архивирования (archiver process) или ARCn делает копию файлов журналов базы данных в один или несколько целевых каталогов, устройств или сетевых адресов (объектов сети) после того, как они заполняются, а информация начинает записываться в новый файл. Оптимальный вариант — это когда процесс архивирования заканчивается прежде, чем заполненный журнал потребуется снова. В противном случае могут возникнуть серьезные проблемы с производительностью — пользователи не могут завершить начатые транзакции, пока их информация не будет записана в файлы журналов базы данных, а эти файлы не готовы принимать новые записи, потому что они все еще перезаписываются в архивные файлы. Есть, по крайней мере, три решения этой проблемы путем увеличения либо размеров файлов журналов базы данных, либо числа групп журнальных файлов, либо числа процессов архивирования (ARCn). Для каждого экземпляра может быть запущено до десяти процессов ARCn, достаточно соответствующим образом увеличить значение инициализации LOG_ARCHIVE_MAX_PROCESSES.
для чего параметра
помогают
СКРТ
Процессы выполнения контрольных точек (checkpoint processes) сократить время, требующееся для восстановления экземпляра. Во время выполнения контрольных точек процесс СКРТ обновляет заголовки файлов данных и управляющих файлов, чтобы зарегистрировать последний успешный SCN (System Change Number — системный номер изменений). Контрольные точки проставляются автоматически при каждом переключении журнальных файлов. Процесс DBWn регулярно записывает грязные °Уферы, чтобы продвинуть вперед тот момент, с которого может начаться восстановление экземпляра, сокращая тем самым так называемое среднее время восстановления (Mean Time То Recovery - MTTR).
RECO
Процесс RECO, или процесс восстановления (recoverer process) используется для ликвидации сбоев в работе распределенных транзакций (т. е. транзакций, в которых участвуют таблицы из нескольких баз данных). Если Та лица в базе данных CTTR изменяется вместе с таблицей из базы дан
48
Гпава 1
ных WHSE и сетевое соединение между этими базами данных вышло из строя еще до того, как было произведено обновление таблицы в базе данных WHSE, процесс RECO откатит эту завершившуюся неудачей транзакцию.
Обзор средств резервного копирования и восстановления информации
База данных Oracle поддерживает много различных форм резервного копирования и восстановления информации. Некоторыми из них можно управлять на уровне пользователя, например экспортом и импортом; но большинство этих средств рассчитано на АБД, например создание оперативных или автономных резервных копий и использование команд операционной системы или утилиты RMAN.
Подробнее о конфигурировании и использовании этих методов резервного копирования и восстановления см. главы 12 и 13.
Экспорт/Импорт
Команда экспорта является автономной утилитой для всех видов аппаратных и программных платформ Oracle и запускается при выполнении команды ехр из строки приглашения операционной системы или с консоли Oracle Enterprise Manager в графическом интерфейсе пользователя (GUI). Экспорт рассматривается как логическое резервное копирование, поскольку базовые характеристики хранения таблиц не записываются — только метаданные таблицы, привилегии пользователя и сами данные таблицы. В зависимости от подручных задач и от того, есть ли у пользователя привилегии АБД или нет, команда ехр может экспортировать либо все таблицы базы данных, либо все или некоторые таблицы для одного или нескольких пользователей или заданный набор таблиц.
Для восстановления информации из файла экспорта базы данных необходимо использовать утилиту импорта^ запускаемую при выполнении команды imp. Эта утилита принимает на входе файл в двоичном формате, созданный утилитой экспорта, и импортирует его в базу данных в предположении, что пользователи экспортированных таблиц базы данных существуют и в той базе данных, для которой осуществляется команда импорта.
Одним из преимуществ применения команд экспорта и импорта является то, что так называемые “продвинутые” пользователи базы данных в состоянии управлять своими собственными резервными копированиями и восстановлениями, особенно в так называемых средах разработки (development environment). Кроме того, оказывается, что генерируемые командой экспорта двоичные файлы обычно можно прочесть с помощью самых разных версий Oracle, что делает перенос небольшого набора таблиц из старой версии Oracle в новую несложным.
Экспорт и импорт являются по сути своей резервными копиями, делаемыми по состоянию на определенный момент времени, и, следовательно, экспорт и импорт наиболее полезны при копировании не слишком изменчивых данных.
Появившаяся в Oracle 10g утилита Oracle Data Pump (помпа данных Oracle) возводит операции экспорта и импорта на новый уровень произ
Знакомство с архитектурой Oracle
49
водительности. Экспорт во внешние источники данных может стать значительно (до двух раз) быстрее, а операции импорта могут стать быстрее в 45 раз. Это обусловлено тем, что Data Pump Import, в отличие от традиционного импорта, использует прямой режим загрузки. Кроме того, экспорт их базы данных источника может быть в то же самое время импортирован в целевую базу данных без использования промежуточного файла дампа, что позволяет сэкономить силы и административные усилия. Утилита Oracle Data Pump реализована с использованием пакета DBMS_ DATAPUMP и команд expdb и impdb и включает в себя многочисленные другие опции управляемости, типа детального отбора объектов (подробнее об Oracle Data Pump см. главу 17).
Автономное копирование
Одним из способов создания физических резервных копий базы данных является выполнение автономного резервного копирования. Для выполнения автономного резервного копирования прежде всего нужно остановить работу базы данных. Затем все составляющие ее файлы — файлы данных, управляющие файлы, SPFILE, файлы паролей и т. д. — можно скопировать на другие устройства хранения. После завершения процесса экземпляр базы данных можно запустить снова.
Автономное копирование похоже на резервное копирование с помощью экспорта, поскольку они оба обеспечивают резервные копии базы данных по состоянию на определенный момент времени и не слишком помогут при восстановлении самого последнего состояния базы данных, если база данных работала не в режиме archivelog. Еще одной “оборотной стороной медали” при автономном копировании является величина времени простоя, связанного с отключением базы данных для выполнения резервного копирования. Любая многонациональная компания, для которой требуется постоянная (24 часа в сутки и семь дней в неделю) доступность базы данных, скорее всего не сможет позволить себе часто делать автономные резервные копии.
Оперативное резервное копирование
Если база данных работает в режиме archivelog, то возможно выполнить ее оперативное резервное копирование. База данных может быть открыта и доступна для пользователей даже во время резервного копирования. Процедура для выполнения оперативного копирования состоит в следующем: табличные пространства временно переводятся в состояние копирования с помощью команды alter tablespace users begin backup, затем выполняется резервное копирование файлов данных табличного пространства с помощью команд операционной системы, после чего они восстанавливаются до нормального состояния с помощью команды alter tablespace users end backup.
RMAN
Инструментальное средство резервного копирования Recovery Manager (диспетчер восстановления), более известное как RMAN, находится в обращении, начиная с версии Огас1е8. По сравнению с другими формами
50
Глава 1
резервного копирования RMAN предлагает множество преимуществ. Он позволяет выполнять инкрементальное физическое копирование, когда копируются только изменившиеся в промежутке между двумя полными копированиями блоки, и при этом на протяжении всего резервного копирования база данных остается в онлайновом (оперативном) состоянии.
RMAN отслеживает резервные копии с помощью одного из двух методов: либо с помощью каталога восстановления, хранящегося в другой базе данных, либо располагая требуемую информацию в управляющем файле копируемой базы данных. Использование для RMAN управляющих файлов целевой базы данных является довольно простым делом, но это отнюдь не самое лучшее решение для надежной методологии корпоративного резервного копирования. Хотя для хранения каталога восстановления требуется отдельная база данных, в которой будут храниться метаданные для целевой базы данных, а также записи обо всех выполненных резервных копированиях, все затраты с лихвой окупаются, например, когда все управляющие файлы целевой базы данных оказываются утерянными в случае катастрофического отказа. Помимо этого, в каталоге восстановления сохраняется архивная информация о резервных копиях, которая может быть перезаписана в управляющих файлах целевой базы данных, если значение параметра CONTROL_FILE_RECORD_KEEP_ TIME было установлено слишком низким.
Подробнее о RMAN см. в главе 13.
Средства безопасности
В нескольких последующих разделах приводится краткий обзор различных способов, с помощью которых Oracle 10g Database контролирует и проводит в жизнь действия по обеспечению безопасности в базе данных. Средства обеспечения безопасности учетных записей на базе объектов пользователей и схем будут подробно рассмотрены в разделе об объектах базы данных; все другие вопросы, относящиеся к обеспечению безопасности, будут рассмотрены здесь.
Подробное рассмотрение всех этих и некоторых других возможностей обеспечения безопасности можно найти в главе 10.
Привилегии и роли
В базах данных Oracle привилегии (privileges) управляют доступом как к тем действиям, которые пользователь может произвести в базе данных, так и к объектам базы данных. Привилегии, управляющие доступом к действиям в базе данных, принято, называть системными привилегиями, в то время как привилегии, управляющие доступом к данным и другим объектам системы, называются объектными привилегиями.
Чтобы сделать назначение привилегий и управление ими более легким для администраторов баз данных делом, роль (role) базы данных группирует отдельные привилегии. Иными словами, ролью называется именованная группа привилегий. Помимо привилегий, в группу могут быть включены и другие роли.
Привилегии и роли предоставляются и отзываются с помощью команд grant и revoke. Группа пользователей PUBLIC не является ни поль
Знакомство с архитектурой Oracle
51
зователем, ни ролью, а также не может быть удалена, однако, если привилегия назначена группе PUBLIC, это означает, что она назначена всем пользователям базы данных, как тем, кто работает сегодня, так и тем, которые появятся в будущем.
Системные привилегии
Системные привилегии предоставляют пользователю право выполнять в базе данных определенные типы действий, например, создание пользователей, изменение табличных пространств или удаление любых (ANY) представлений. Ниже приводится пример предоставления системных привилегий:
□ grant DROP ANY TABLE to SCOTT WITH GRANT OPTION;
Пользователю SCOTT предоставляется право удалять таблицы любого пользователя любой схемы. Фраза with grant option позволяет пользователю SCOTT предоставлять полученную привилегию другим пользователям.
Объектные привилегии
Объектные привилегии предоставляются на конкретные объекты базы данных. Наиболее часто встречающимися объектными привилегиями являются привилегии SELECT, UPDATE, DELETE и INSERT для таблиц, EXECUTE для хранимых объектов PL/SQL и INDEX для предоставления возможности создания индексов для таблиц. В следующем примере пользователь RJB может выполнять любые операции DML над таблицей5ОВ8, которой владеет схема HR:
□ grant SELECT, UPDATE, INSERT, DELETE on HR.JOBS to RJB;
Аудит *
Для проведения аудита доступа пользователей к объектам базы данных можно создать журнал аудита (audit trail) для конкретного объекта или действия, используя для этого команду audit. К числу действий, подлежащих аудиту, относятся доступ к объектам базы данных и операторы SQL; результаты аудита (успех или неудача, или и то, и другое) могут быть записаны в таблице журнала аудита, SYS.AUD$.
Для каждой подвергаемой аудиту операции Oracle создает запись аудита, куда включены имя пользователя, тип выполненной операции, участвующие в операции объекты и отметка времени. Различные представления словаря данных, например DBA_AUDIT_TRAIL и DBA_FGA_AUDIT_ RAIL, делают интерпретацию необработанных результатов аудита из таблицы SYS.AUD$ значительно более легким делом.
Предупреждение Избыточный аудит объектов базы данных может отрицательно влиять на производительность. Нужно начать с базового аудита ключевых привилегии и объектов и расширять аудит при обнаружении потенциальных проблем.
52
Глава 1
Детальный аудит
В Oracle 10g возможности детального аудита значительно расширены. Можно сказать, что аудит поднялся на еще одну ступень: при стандартном аудите можно обнаружить, что над таблицей EMPLOYEE был выполнен оператор select; теперь же детальный аудит зарегистрирует запись аудита, содержащую конкретные столбцы таблицы EMPLOYEE, к которым при этом производился доступ, например к столбцу SALARY.
Детальный аудит реализован с помощью пакета DBMSJFGA, а также представлений словаря данных DBA_FGA_AUDIT_TRAIL. В словарном представлении DBA_COMMON__AUDIT_TRAIL объединяются стандартные записи аудита из DBA_AUDIT_TRAIL с записями детального аудита.
Виртуальная приватная база данных
Опция Virtual Private Database (VPD — виртуальная приватная база данных), впервые появившаяся в Oracle8i, объединяет детальный контроль доступа с защищенным контекстом приложения. Защитные стратегии прилагаются к данным, а не к приложениям; это гарантирует, что правила безопасности будут применены безотносительно к методу доступа к ним (т. е. независимо от того, осуществляется ли доступ через приложение или с помощью запроса SQL. — Прим. пер).
Например, контекст медицинского приложения может возвратить предикат, базирующийся на идентификационном номере пользователя, обращающегося к данным; возвращаемый предикат будет использован во фразе WHERE и поможет гарантировать, что из таблицы будут выбраны только записи, ассоциируемые с пациентом.
Label Security
Технология Oracle Label Security предлагает решение “готовая к эксплуатации VPD”, которое позволяет ограничить доступ к строкам любой таблицы на основании метки запрашивающего доступ пользователя и метки строки таблицы. Администраторам Oracle Label Security не требуется никаких специальных навыков программирования, чтобы они смогли назначить пользователям и строкам таблицы метки политики защиты.
Этот весьма детализированный подход к безопасности данных может, например, позволить АБД у провайдера приложений (Application Service Provider — ASP) создать только один экземпляр приложения для расчета дебиторской задолженности и использовать Label Security, чтобы ограничить строки в каждой таблице информацией о дебиторской задолженности отдельных компаний.
Real Application Clusters
Опция Real Application Clusters (RAC), известная в предыдущих версиях Oracle как опция Oracle Parallel Server (параллельный сервер Oracle), позволяет нескольким экземплярам Oracle, размещенным на разных серверах, одновременно получать доступ к одним и тем же файлам базы данных.
Знакомство с архитектурой Oracle
53
Память
Системная глобальная область
Высокоскоростное межузловое соединение
Память
Системная глобальная область
Рис. 1.7. Двухузловая конфигурация Real Application Clusters (RAC)
Инсталляция RAC может обеспечить чрезвычайно высокую доступность, как относительно плановых, так и внеплановых выходов системы из строя. Один из экземпляров может быть перезапущен с новыми параметрами инициализации, в то время как второй экземпляр продолжает обслуживать запросы к базе данных. Если один из физических серверов системы выйдет из строя вследствие какого-либо отказа, экземпляр Oracle на другом сервере продолжит обработку транзакций даже от тех пользователей, которые были подключены к вышедшему из строя серверу, прозрачно и с минимальным временем простоя.
Однако RAC является не только софтверным решением. К аппаратным средствам для реализации RAC предъявляются особые требования. Разделяемая база данных должна быть размещена на дисковой подсистеме с реализованным RAID. Это будет являться гарантией того, что каждый элемент этой подсистемы будет отказоустойчивым. В дополнение к этому для RAC требуется высокоскоростное межузловое соединение или приватная сеть между узлами кластера, чтобы можно было поддерживать обмен сообщениями и передачу блоков от одного экземпляра к другому с использованием механизма Cache Fusion (слияние кэшей).
На рис. 1.7 изображена схема инсталляции двухузлового RAC (о создании и конфигурировании Real Application Clusters см. главу 11).
Oracle Streams
Как компонент Oracle Enterprise Edition технология Oracle Streams (потоки) является компонентом инфраструктуры Oracle более высокого уровня, который завершает Real Application Clusters. Технология Oracle treams позволяет обеспечить плавное течение и разделение данных и событий как в одной базе данных, так и из одной базы данных в другую. Эта технология является еще одной ключевой частью обширного списка высокодоступных решений Oracle, в которой объединены и усовершенствованы функции организации очередей сообщений, репликации данных и управления событиями (о реализации Oracle Streams см. главу 18).
54
Глава 1
Oracle Enterprise Manager
Oracle Enterprise Manager (OEM) является очень полезным набором инструментальных средств, который облегчает исчерпывающее управление всеми компонентами инфраструктуры Oracle, включая экземпляры баз данных Oracle, серверы приложений Oracle и web-серверы. Если существует так называемый агент управления (management agent) для приложений от третьих фирм, OEM может управлять приложениями от третьих фирм в той же самой инфраструктуре, что и для любых поставляемых Oracle объектов.
OEM полностью совместим со средой Web посредством Netscape или Internet Explorer, поэтому для запуска консоли OEM может быть использована любая операционная система, поддерживающая Netscape или IE.
Одно из ключевых решений, принимаемых при использовании OEM с Oracle Grid Control, является решение о выборе места для хранения управленческого репозитория. Репозиторий управления OEM хранится в отдельной базе данных, не перекрывающейся с базами данных управляемых или подвергающихся мониторингу узлов. Метаданные из узлов и сервисов централизуются и помогают администрированию этих узлов. База данных управленческого репозитория должна подвергаться частому резервному копированию, причем независимо от управляемых баз данных.
При инсталляции OEM предлагается огромное количество “готовых к работе” ценностей. После завершения инсталляции OEM создается система электронного уведомления, готовая посылать сообщения учетной записи SYSMAN или любой другой учетной записи обо всех критических условиях, и автоматически завершается первоначальное обнаружение целей.
Параметры инициализации Oracle
В базах данных Oracle параметры инициализации используются для конфигурирования параметров и установок памяти, местоположения дисков и т. п. Есть два способа хранения параметров инициализации: с использованием редактируемого текстового файла и с использованием хранящегося на сервере двоичного файла. Безотносительно к тому, какой метод храпения параметров инициализации используется, начиная с Oracle 10g, существует определенный список основных параметров инициализации, с которым должен быть знаком каждый АБД, когда он создает новую базу данных.
Начиная с Oracle 10g, все параметры инициализации могут быть отнесены к одной из двух широких ^категорий: основные и дополнительные (или расширенные. — Прим. пер.}. По мере того как Oracle все больше и больше становится “самоуправляемым”, число параметров, о которых должен помнить и ежедневно регулировать их АБД, сокращается.
Основные параметры инициализации
В таблице 1.3 приводится список основных параметров инициализации вместе с их кратким описанием. В последующих разделах будут даны некоторые дополнительные объяснения и советы относительно того, как должны задаваться эти параметры в зависимости от аппаратного и программного окружения, типов приложений и числа пользователей базы данных.
Знакомство с архитектурой Oracle 55
Таблица 1.3. Основные параметры инициализации
Описание
Параметр инициализации
CLUSTER-DATABASE
COMPATIBLE
CONTROL-FILES
Делает возможным участие этого узла в кластере.
Позволяет установить новую версию базы данных, но гарантировать при этом совместимость с релизом, заданным в этом параметре.
Указывает местоположение управляющих файлов экземпляра.
DB.BLOCK.SIZE
DB.CR EATE.FI LE.DEST
DB.CREATE_ONLINE_LOG_DEST.fl
DB.DOMAIN
DB.NAME
DB_RECOVERY_FILE_DEST
DB.RECOVERY_FILE_DEST.SIZE
INSTANCE-NUMBER
JOB.QUEUE.PROCESSES
LOG_ARCHIVE_DEST_fl
LOG.ARCHIVE.DEST.STATE n
NLS.LANGUAGE
Указывает размер блоков Oracle. При создании базы данных этот размер блока будет использован для табличных пространств SYSTEM, SYSAUX и временных табличных пространств.
Используемое по умолчанию местоположение файлов OMF. Также указывает на местоположение управляющих файлов и файлов журналов базы данных, если не задан параметр DB_CREATE_ONLINE_LOG_DEST_fl.
Используемое по умолчанию местоположение управляющих файлов OMF и онлайновых файлов журналов базы данных.
Имя логического домена, в котором размещена база данных в системе распределенных баз данных (например, us.oracle.com).
Идентификатор базы данных (не более 8 символов). Присоединяется в начало значения DB.DOMAIN для образования полностью квалифицированного имени (например, marketing.us.oracle.com).
Местоположение по умолчанию области восстановления. Должен быть задан вместе с параметром DB_ RECOVERY_FILE.DEST.SIZE.
Максимальный размер (в байтах) файлов, используемых для восстановления в определенной только что области восстановления.
В инсталляции RAC — номер экземпляра для этого узла в кластере.
Максимальное число процессов, разрешенных для выполнения заданий. Находится в диапазоне о О до 1000.
Для режима ARCHIVELOG — вплоть до десяти местоположений, в которые можно посылать архивные журнальные файлы.
Задает состояние доступности соответствующего узла LOG.ARCHIVE_DEST.fl.
Определяет используемый по умолчанию язык базы данных, в том числе сообщения, названия месяцев и дней и правила сортировки ^напоимер, ‘AMERICAN’).
56
Глава 1
Таблица 1.3. (Продолжение)
Параметр инициализации
NLS.TERRITORY
OPEN-CURSORS
PGA_AGGREGATE_TARGET
PROCESSES
REMOTE_LISTENER
REMOTE_LOGIN_PASSWORDFILE
ROLLBACK-SEGMENTS
SESSIONS
SGA.TARGET
SHARED_SERVERS
STAR_TRANSFORMATION_ENABLED
UNDO_MANAGEMENT
UNDO-TABLESPACE
Описание
Название территории, используемое для нумерации дней и недель (например, ‘SWEDEN’, ‘TURKEY’nnn ‘AMERICA’).
Максимальное число курсоров, открытых в одном сеансе.
Общий размер памяти, выделяемой в этом экземпляре для всех серверных процессов.
Максимальное число процессов операционной системы, которые могут быть одновременно подключены к Oracle. Значения SESSIONS и TRANSACTIONS также выводятся из этого значения.
Сетевое имя, разрешающееся в имя удаленного прослушивающего процесса Oracle Net.
Указывает, как Oracle использует файлы паролей. Используется в RAC.
Имена приватных сегментов, которые должны быть приведены в оперативное состояние, если для отката транзакций не используется управление откатами (undo management).
Максимальное количество сеансов и, следовательно, одновременно подключенных пользователей, для экземпляра. По умолчанию используется значение 1.1 * PROCESSES + 5.
Определяет общий размер памяти для всех компонент SGA; этот параметр автоматически определяет параметры DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE-POOL-SIZE и JAVA-POOL-SIZE.
Число процессов разделяемого сервера, выделяемых при запуске экземпляра.
Управляет оптимизацией запросов при выполнении запросов типа звезды.
Указывает, является ли управление откатом автоматическим (AUTO) или ручным (MANUAL). Если указано MANUAL, для управления откатами используются сегменты отката.
Имя табличного пространства, используемого в том случае, если параметр UNDO.MANAGEMENT установлен на AUTO.
Некоторые из этих параметров будут рассматриваться в разделе “Инсталляция программного обеспечения”; там будут установлены первоначальные параметры для SGA, мест расположения файлов и другие предельные значения.
Знакомство с архитектурой Oracle
57
COMPATIBLE
Параметр COMPATIBLE позволяет устанавливать более новые версии Oracle, но при этом так ограничивать набор возможностей новой версии, как если бы была установлена прежняя, более старая версия Oracle. Это прекрасный способ двигаться вперед по пути апгрейда базы данных, сохраняя при этом совместимость с приложениями, которые могут прекратить работать, если запустить их с новыми версиями программного обеспечения. Впоследствии значение параметра COMPATIBLE может повышаться параллельно процессу переделки или замены приложений, обеспечивающих их работу с новой версией базы данных.
“Оборотной стороной медали”, связанной с использованием этого параметра, является то, что новые приложения для базы данных не могут в полной мере воспользоваться преимуществами новых опций базы данных, пока параметр COMPATIBLE не будет установлен на номер текущего релиза.
DB.NAME
Параметр DB_NAME определяет, так сказать, “локальную часть” имени базы данных. Он должен быть не длиннее 8 символов и обязан начинаться с буквенно-цифрового символа. Если он был задан, изменить его можно только при повторном создании базы данных; параметр DB_NAME фиксируется в каждом файле данных, управляющем и журнальном файле базы данных. При запуске базы данных это значение должно соответствовать значению DB_NAME, записанному в управляющем файле.
DBJ)0MAIN
Параметр DBJDOMAIN специфицирует имя сетевого домена, в котором будет находиться база данных. Комбинация параметров DB_NAME и DB__ DOMAIN должна быть уникальной внутри системы распределенных баз данных.
DB_RECOVERY_FiLE_DEST и DB.RECOVERY_FILE_DEST_SIZE
Когда происходят операции восстановления базы данных, будь то в связи со сбоем экземпляра или в связи со сбоями носителей, бывает удобно иметь транзитную область восстановления (flash recovery area) для хранения файлов, относящихся к операциям восстановления или резервного копирования, и для управления ими. Начиная с Oracle 10g, параметр DB_ COVERY_FILE_DEST может быть местом размещения каталога на локальном сервере, сетевым каталогом или дисковой областью ASM utomatic Storage Management — среда автоматического управления хранением данных). Параметр DB_RECOVERY_FILE_DEST_SIZE устанавливает предел того, сколько дисковой памяти может быть отведено для файлов восстановления или для файлов резервных копий.
Эти параметры являются опциональными, но, если сгс ундине, петчер восстановления (RMAN) может автоматически управлять ф МИ’ требующимися для операций резервного копирования и восстановления. Размер этой области восстановления должен быть достаточно ольшим, чтобы хранить две копии файлов базы данных, ипкременталь-
если это указано, дис-
•айла-
йия. Размер этой области восстановления должен быть достаточно
58
Гпава 1
ные резервные копии RMAN, оперативные журналы, архивные журнальные файлы, еще не скопированные на ленту, SPFILE и управляющие файлы.
CONTROLFILES
Параметр CONTROLJFILES не является необходимым. Если он не специфицирован, Oracle создает управляющий файл в используемом по умолчанию для этой цели месте, или, если сконфигурирована опция OMF, в местоположении, специфицированном либо параметром DB_CREATE FILEJDEST, либо параметром DB_CREATE_ONLINE_LOG_DEST_?z.
Однако настоятельно рекомендуется создавать несколько копий управляющего файла, причем на различных физических томах. Управляющие файлы до такой степени критичны для целостности базы данных и настолько малы, что нужно создать не менее трех мультиплексированных копий управляющего файла на различных физических дисках. В дополнение, должна быть выполнена команда alter database backup controlfile to trace для создания копии управляющего файла в текстовом формате в случае значительной катастрофы.
В следующем примере специфицируются три местоположения для копий управляющего файла:
□ CONTROL—FILES = (/uOI/оraclelO^z/test/controlOl. ctl, /u03/oracle10g/test/control02.ctl, /u07/oracle10g/test/control03.ctl)
DB_BLOCK_SIZE
Параметр DB BLOCK_SIZE специфицирует используемый по умолчанию размер блока Oracle в базе данных. При создании базы данных табличные пространства SYSTEM, SYSAUX и TEMP создаются с таким размером блока. В идеале этот параметр должен быть таким же, как и размер блока операционной системы (или кратен ему), так как это повышает эффективность ввода/вывода.
До появления Огас1е9г можно было специфицировать меньший размер блока (4 Кбайт или 8 Кбайт) для систем OLTP и блок большего размера (вплоть до 32 Кбайт) для систем DSS. Однако теперь, когда для одной базы данных можно иметь до пяти различных размеров блока и не слинг-ком большое значение параметра DB_BLOCK_SIZE. Наиболее предпоч тигельным минимальным размером блока для любой базы является 8 Кбайт, до тех пор пока не будет строго доказано, что применение блока размером 4 Кбайт не приведет к возникновению проблем с производи тельностью.
SGA_TARGET
Еще одним способом в Oracle 10gоблегчить достижение цели “установи И забудь об этом” для базы данных является указание общего размера памЯ ти для области SGA и всех ее компонентов. Если специфицирован пара метр SGA TARGET, значения параметров DB_CACHE__SIZE, SHARED-POOL_SIZE, LARGE_POOL_SIZE и JAVA__POOL_SIZE устанавливаются автоматически средством автоматического управления разделяемой
Знакомство с архитектурой Oracle
59
мятью (ASMM). Если любой из четырех названных выше параметров установлен вручную (при установленном значении параметра SGA_ TARGET), ASMM будет использовать заданные вручную значения как минимальные.
После запуска экземпляра автоматически заданные параметры будут динамически увеличиваться или уменьшаться при условии, что при этих изменениях не будет превышен параметр SGA_MAX_SIZE. Значение этого параметра специфицирует жесткий верхний предел общего размера области SGA, который не может быть превзойден или изменен, пока экземпляр не будет перезапущен.
Вне зависимости от того, каким был установлен размер SGA, нужно убедиться в том, что па сервере есть достаточное количество физической памяти для хранения всех компонентов SGA и всех фоновых процессов; в противном случае будет иметь место избыточный страничный обмен, отчего будет страдать производительность системы.
DB_CACHE_SIZE и DB_nK_CACHE_SIZE
Параметр DB_CACHE_SIZE специфицирует размер области в SGA, в которой хранятся блоки используемого по умолчанию размера, в том числе блоки табличных пространств SYSTEM, TEMP и SYSAUX. Кроме того, может быть определено до четырех других кэшей, если есть табличные пространства с друтим размером блока (т. е. не с тем размером, что у табличных пространств SYSTEM и SYSAUX). Значение п может быть равно 2, 4, 16 или 32; если значение и обеспечивает тот же самый размер блока, что и по умолчанию, соответствующий параметр DB_nK__CACHE_SIZE является недопустимым. Хотя этот параметр не относится к числу основных параметров, он становится основным, если в базу данных переносится табличное пространство с размером блока, отличающимся от DB BLOCK_
У баз данных, содержащих блоки различных размеров, есть очевидные преимущества. Табличное пространство, обрабатывающее транзакции OLTP, может иметь меньший размер блока, а табличное пространство для таблиц, содержащих информацию из хранилищ данных, может иметь блоки большего размера. Однако следует быть внимательным при выделении памяти для каждого из этих размеров кэшей, с тем чтобы не выделить слишком много памяти для одного из них за счет другого. Начи-А^1 С ^гас^е^г» ОПЦИЯ Oracle Buffer Cache Advisory (механизм Buffer Cache visory или консультативная справка по кэшу буферов) выполняет мони-использования кэша для всех размеров кэшей в представлении
—CACHE-ADVICE при задании размеров этих областей памяти (под-ро нее об использовании опции Buffer Cache Advisory см. главу 8).
SHARED_POOL_SIZE, LARGE_POOL_SIZE и JAVA_POOL_S1ZE
Параметры SHARED_POOL_SIZE, LARGE_POOL_SIZE и JAVA POOL_ o ’ заДа1°Щие размеры разделяемого пула, большого пула и пула Java соме етственн°, автоматически устанавливаются Oracle, если задан пара-но? инициализации SGA__TARGET (дополнительная информация о руч-1 наст. ройке этих параметров приводится в главе 8).
60
Глава 1
PROCESSES
Значение параметра инициализации PROCESSES представляет общее число процессов, которые могут одновременно подключаться к базе данных. В это число включены как фоновые процессы, так и процессы пользователей; хорошим отправным значением для PROCESSES будет 15 для числа фоновых процессов плюс максимальное ожидаемое число одновременно работающих(сопсштеп!) пользователей. Для небольших баз данных можно положить PROCESSES равным 50, поскольку накладные расходы, связанные с завышением этого параметра, практически отсутствуют.
UNDO .MANAGEMENT и UNDO.TABLESPACE
Автоматическое управление пространством отката (Automatic Undo Management) впервые появившееся в Огас1е9г, устраняет или, по крайней мере, значительно ослабят головную боль, связанную с выделением правильного числа и размера сегментов отката, требующихся для обработки информации для отката транзакций. Вместо этого определяется единое табличное пространство отката для всех операций отката (за исключением сегментов отката для табличного пространства SYSTEM), и все управление откатом будет осуществляться автоматически, если параметр UNDO_MANAGEMENT установлен на AUTO.
Задача АБД — установить размер табличных пространств отката. Помочь АБД настроить размер табличного пространства отката могут представления словаря данных (например, V$UNDOSTAT) и утилита Undo Advisor (консультант по откату). Можно создать несколько табличных пространств отката. Например, в дневное время в онлайновом режиме будет табличное пространство меньшего размера, обрабатывая относительно небольшие объемы транзакций; а табличное пространство большого объема будет переведено в онлайновый режим в ночную смену, чтобы справляться с пакетными заданиями и долго выполняющимися запросами, для которых загружается хранилище данных, но при этом требуется транзакционная согласованность. В любой момент времени активным может быть только одно табличное пространство отката.
Дополнительные параметры инициализации
Дополнительные параметры инициализации включают в себя все остальные параметры инициализации, не вошедшие в число основных. Их общее количество в Oracle Database 10gRelease 1 приближается к 255. Боль шинство этих параметров может быть автоматически задано и настроено экземпляром Oracle при установке основных параметров.
Инсталляция программного обеспечения
Несмотря на то, что подробное изложение вопросов инсталляции про граммного обеспечения Oracle Database 10g выходит далеко за рамки н&' стоящей книги, мы коснемся основ инсталляции Oracle с использованИ ем утилиты Oracle Universal Installer (OUI — универсальный инсталлятор Oracle), а также основных шаблонов для выполнения “ручной” инсталл# ции базы данных с использованием команды create database. В любоМ
Знакомство с архитектурой Oracle 61
случае, вторым ключом к успеху развертывания базы данных Oracle является тщательное изучение руководства по инсталляции для вашей конкретной платформы. Ниже приводится контрольный список вопросов, над которыми следует задуматься или которые должны быть разрешены, прежде чем начнется процесс инсталляции:
Примите решение о локальном имени базы данных и о том, в каком домене она будет содержаться. Эти имена задаются параметрами инициализации DB_NAME и DBJDOMAIN.
Для первого проекта с использованием баз данных оцените число таблиц и индексов, а также их размеры, чтобы можно было спланировать оценку дискового пространства, требующегося помимо табличного пространства SYSTEM и программного обеспечения и инструментальных средств Oracle.
Спланируйте размещение физических файлов данных на дисках сервера, при котором обеспечивалась бы максимальная производительность и восстанавливаемость. Чем больше физических дисков, тем лучше. Если для хранения файлов будет использован RAID-массив или сетевое устройство хранения данных (NAS-устройство), рассмотрите вопрос об использовании для размещения файлов средства OMF (управляемые Oracle файлы).
Прежде чем запустить реальную базу данных, рассмотрите основные параметры инициализации и разберитесь с ними, а также спланируйте использование SPFILE, если SPFILE не использовался с самого начала.
Выберите набор символов базы данных, а также альтернативный набор символов. Хотя достаточно просто оставить при инсталляции используемый по умолчанию набор символов, может понадобиться принять во внимание, где именно проживают пользователи базы данных, и учесть их языковые требования. После инсталляции изменить набор символов можно только в том случае, если новый набор символов будет надмножеством существующего набора символов.
Примите решение о наилучшем используемом по умолчанию размере блока базы данных. Определенный параметром DB_BLOCK_ SIZE размер блока базы данных не может быть изменен впоследствии без полной повторной инсталляции базы данных. Хотя это решение и не является критичным для последующих расширений базы данных, так как Oracle может поддерживать табличные пространства с различными размерами блоков данных, неправильный выбор размера блока по умолчанию может привести к снижению производительности операций с использованием табличных пространств SYSTEM, TEMP и SYSAUX.
Убедитесь, что никому из неадминистративных пользователей в качестве их табличного пространства по умолчанию не назначено табличное пространство SYSTEM. В табличном пространстве SYSTEM не должны также никогда храниться никакие объекты пользователей.
62
Гпава 1
Для облегчения администрирования информации об откате для транзакций обязательными элементом является использование средства автоматического управления пространством отката (AUM). Дополнительная дисковая память, необходимая для размещения табличных пространств отката, с лихвой окупается приростом продуктивности как для АБД, так и для пользователей.
Спланируйте стратегию резервного копирования и восстановления. Примите решение о том, как часто следует создавать резервные копии базы данных; при этом используйте различные методы резервного копирования базы данных. Одним из ключевых вопросов, которые следует задать себе при определении стратегии резервного копирования, является вопрос о том, насколько долгий простой базы данных может себе позволить ваша организация? Если эта база данных обрабатывает только пакетные задания по ночам, то, вероятно, для нее будет вполне достаточно одного полного резервного копирования в неделю и ежедневных инкрементальных резервных копий. Если же фасадом для базы данных компании, которая 24 часа в сутки и 7 дней в неделю продает для заказчиков изо всех стран мира какие-либо “штучки”, является web-сайт, а стоимость минуты простоя измеряется шестизначными числами, то будут полностью оправданы инвестиции в среду Oracle Real Application Clusters (RAC) вместе c Data Guard для обеспечения восстановления после аварий.
Обязательным является и знакомство с несколькими ключевыми web-сайтами. На сайте Oracle Technology Network (OTN — технологическая сеть Oracle), находящемся по адресу http://otn.oracle.com, хранится огромный объем информации, в том числе так называемые “Белые книги” (официальные документы корпорации Oracle. — Прим, пер.), бесплатные инструментальные средства, типовые программы, а также онлайновая версия популярного в среде разработчиков и пользователей Oracle журнала Oracle Magazine. За пользование этим сайтом не взимается никакой платы, кроме одноразового платежа за регистрацию на сайте.
Покупка лицензии на программное обеспечение базы данных Oracle — это хорошее начало, но ключом к успеху инсталляции программного обеспечения и развертывания системы является заключение контракта па поддержку Oracle через Web. Если используются средства web-сайта технической поддержки Oracle, MetaLink (http://metalink.oracle.com), может быть, вам никогда не придется покидать уютных и дружественных границ своего web-браузера, чтобы поддерживать свою базу данных в рабочем состоянии. С помощью MetaLink можно разместить запрос на под-держку (support request), рыться в других запросах, загружать “заплатки (от английского patch — заплата, вставка в программу. — Прим, пер.), загружать “белые книги” и вести поиск в базах данных ошибок.
Первым шагом является удачная инсталляция программного обеспечения. Среда базы данных растет и развивается с каждым новым бизнес-требованием и с каждым приложением, встречающимися на вашем пути. Дополнительную информацию о том, как успешно спланировать реализацию проекта разработки большой базы данных, можно найти в главе 5.
Знакомство с архитектурой Oracle
63
Обзор опций лицензирования и инсталляции
Независимо от программной и аппаратной платформ, для которых производится инсталляция Oracle, типы инсталляций остаются одними и теми же:
Enterprise Edition Это наиболее богатая опциями и возможностями и самая расширяемая версия базы данных Oracle. В нее включены такие опции, как Flashback Database; кроме того, она позволяет добавлять дополнительные фрагменты лицензионных функциональных возможностей типа Oracle Spatial, Real Application Clusters, Oracle OLAP, Oracle Label Security и Oracle Data Mining.
Standard Edition Эта редакция предлагает хорошее подмноже-
ство Enterprise Edition, включая Real Application Clusters, содержащее до четырех ЦП, но некоторые дополнительные элементы, например Oracle Label Security, в Standard Edition добавить нельзя.
Standard Edition One Эта редакция обеспечивает те же функциональные возможности, что и Standard Edition, за исключением Real Application Clusters, и ограничена одним сервером с не более чем двумя ЦП.
Personal Edition Обеспечивает среду разработки приложений, которые будут выполняться либо в Standard, либо в Enterprise Edition. Эта редакция не может быть использована в промышленно эксплуатируемых средах.
Начиная с Oracle 10g, лицензирование Oracle Database ведется только по числу именованных пользователей или по количеству ЦП в системе. Опции лицензирования по количеству одновременно работающих пользователей больше не существует. Следовательно, АБД должен использовать параметр инициализации LICENSE_MAX_USERS для специфицирования числа пользователей, которые могут быть созданы в базе данных. В результате в Oracle ^параметры LICENSEJ\1AX_SESSIONS и LICENSE_SESSIONS_WARNING исключены из числа рекомендованных к употреблению.
Использование 0UI для инсталляции программного обеспечения Oracle
Утилита Oracle Universal Installer (OUI — универсальный инсталлятор Oracle) используется для инсталляции всех компонентов Oracle и управ-ления ими как для серверной, так и для клиентской стороны. Кроме того, начальные экраны OUI могут быть также использованы для деинсталляции продуктов Oracle.
Во время инсталляции сервера можно выбрать тип базы данных racle Database 10g из приведенного в предыдущем разделе списка: Enterprise Edition, Standard Edition или Personal Edition.
Настоятельно рекомендуется создать стартерную базу данных (starter atabas , когда это будет предложено во время инсталляции. Создание этой базы данных является хорошим способом убедиться в правильности создания среды сервера, а также полезно для знакомства с новыми возможностями Oracle 10g. Стартерная база данных может быть также кандидатом на роль репозитория Grid Control либо для Enterprise Manager, либо для Recovery Manager.
64
Глава 1
В какой-то момент инсталляции программного обеспечения вступает в работу утилита Database Configuration Assistant (DBCA — помощник по конфигурированию сервера базы данных) и начинает подсказывать параметры, необходимые для задания размеров и определения конфигурации базы данных. В шагах инсталляции предлагаемого ниже сеанса предполагается, что процесс инсталляции программного обеспечения был успешно завершен и что при этом была создана стартерная база данных; далее будет создана и сконфигурирована вторая база данных на том же самом сервере с помощью DBCA.
Примечание Начиная с Oracle 1Од, утилита ОВСА может конфигурировать узлы среды Real Application Clusters.
Применение DBCA для создания базы данных
Из командной строки операционной системы нужно запустить утилиту DBCA, для чего следует ввести в нее dbca. В последующих подразделах даны дополнительные советы и руководства для большинства экранов, с которыми приходится иметь дело при создании базы данных.
Опции ОВСА
После запуска DBCA появляется приветствие, а затем окно, в котором предлагается сделать выбор одной из четырех опций:
Create a Database (Создать новую базу данных) Эта опция достаточно очевидна; “с нуля” создается новая база данных; в качестве отправной точки используется шаблон.
Configure Database Options in a Database (Конфигурировать опции базы данных в базе данных) Могут быть изменены некото-
рые из параметров системы для существующей инсталляции базы данных, например, можно заменить конфигурацию выделенного сервера на разделяемый сервер.
Delete a Database (Удалить базу данных) Эта опция также доста-
точно очевидна и очень опасна. В результате ее выполнения база данных будет остановлена, а все связанные с ней файлы данных и управляющие файлы удалены. Для выполнения этой опции необходимо иметь пароль SYS или SYSTEM, если только не используется аутентификация через операционную систему.
Manage Templates (Управление шаблонами) Эта опция позволяет добавлять, модифицировать или удалять шаблоны. Во время сеанса DBCA, после того как были собраны все параметры базы данных, пользователю предоставляется возможность запомни ь (сохранить) созданные им настройки как шаблон. Во многих случаях предлагаемые Oracle предварительно определенные шаблоны оказываются не совсем подходящими для данной среды, поэтому возможность сохранения сделанных выборов настроек базы данных в виде шаблона позволяет сэкономит ь много времени в последующих сеансах DBCA.
Знакомство с архитектурой Oracle
65
Выбор шаблона базы данных
На рис. 1.8 предлагается список имеющихся поддерживаемых Oracle шаблонов. Если в одном из предыдущих сеансов DBCA были созданы собственные шаблоны, они также будут представлены на этом экране.
Есть следующие варианты выбора шаблона:
Custom Database (база данных с учетом требований заказчика) Используйте эту опцию, если вы уже производили достаточно много инсталляций и наперед знаете значения для всех опций, которые потребуются для базы данных. Эта опция хороша в тех случаях, если новый шаблон создается “с нуля” или имеются весьма специфические требования к конфигурации вашей базы данных.
Data Warehouse (хранилище данных) Этот шаблон используется для сред баз данных, в которых пользователи выполняют многочисленные сложные запросы, где происходит соединение больших таблиц для целей отчетности, прогнозирования и аналитики.
General Purpose (универсальная, или общецелевая база данных) Если вы не уверены в том, как будет использоваться создаваемая база данных, или если необходимо обслуживать пользователей как с транзакционными, так и с аналитическими требованиями к обработке данных, советуем выбрать именно этот шаблон.
Рис- 1.8. Выбор шаблона базы данных
66
Гпава 1
Transaction Processing (система обработки транзакций) В круглосуточно работающих средах с высоким числом пользователей, где транзакции являются тяжелыми (т. е. с интенсивной обработкой), но короткими, а основной объем активности приходится на создание и обновление, советуем выбрать этот шаблон.
Для этой инсталляции мы выбрали шаблон General Purpose. Он объединяет опции хранилища данных и сред OLTP; используйте эту опцию, если необходимо использовать базу данных в обеих средах. Однако в идеале каждая создаваемая база данных должна быть сконфигурирована и настроена для типов пользователей и транзакций в базе данных.
Идентификация базы данных
На шаге 3 утилиты DBCA необходимо идентифицировать имя экземпляра, а также глобальное имя базы данных. Если будет введено полностью квалифицированное имя базы данных, в качестве имени экземпляра или идентификатора системы (Oracle System Identifier — SID) будут использованы все символы этого имени до первой точки. На рис. 1.9 изображен экран идентификации базы данных.
Отметьте отличие между SID, именем экземпляра и базой данных. На сервере может иметься несколько баз данных; у каждой базы данных может быть один или несколько экземпляров, открывающих эту базу дан-
?.дп Oracle database is urrcuely identified by a Global^ itabase- IW,.-IVpicaHy of-the for rn ‘'name, dem ahf
Gict»a( Database Narne: tdbalOl.rjbdba co.T
A datatasejs referenced by at least cneJOrade instance which is
• .uniquely identified from airy ether instance on тгехотршег by Grade tem 1ce ntiпeг (ЯD)
SID: dbalOl '
< '• ' У’;Г' X- * . A-’: . • 1
Рис. 1.9. Экран идентификации базы данных
З^комствосархитектурой Oracle
67
ных. Имена экземпляров, использующих одну и ту же базу данных, должны быть уникальными. На сервере, если есть более одного экземпляра с одним и тем же именем (но открывающего различные базы данных), SID, ассоциируемые с экземпляром, должны быть уникальными.
Совет Если глобальное имя базы данных потребуется изменить в будущем, то для этого в дополнение к изменению имени в файле параметров инициализации следует использовать команду alter database. При создании базы данных ее глобальное имя записывается в словарь данных.
Если у вас пока нет существующего домена, используйте принятое по умолчанию имя домена, .world. Проконсультируйтесь у своего системного администратора, чтобы быть уверенным в том, какое конкретное глобальное имя базы данных следует использовать.
Опции управления
На следующем экране (см. рис. 1.10), специфицируются доступные для базы данных опции управления. Если нужно создать для управления базой данных web-сервисы с помощью имеющего возможности для работы в Web средства Oracle Enterprise Manager, нужно сделать отметку в первом окне. Если есть выполняемый в сети управленческий сервис Grid
Each Oracle database maybe managed centrally using the rade Enterprise Manager Grid Control or locally usi g the Oracle Enterprise Manager Database Control Choose the management option that you would like to use to manage this database
ly1 Configure the Database with Enterprise Manager
т Dalal?’
nan
Use Database Control for Database Management * Enable Email Notifications
Outgoing Mail (SMTP) Server mail rjbdoa com
Email Address
Enable Daily Backup
bcb@rjbdba com
и
К I
Г
I
г га;
Рис. 1.1 о. Экран Database Management Options (опции управления базой данных)
68
Гпава 1
Control (управление Oracle Grid), который в предыдущих версиях Oracle был известен под названием Enterprise Manager Repository agent (агент репозитория Enterprise Manager), появляется возможность указать, какие именно сервисы управления будут управлять этой базой
данных.
Если управленческий сервис Grid Control недоступен, базой данных можно управлять локально с помощью Database Control. Если выбран Database Control, можно указать, куда должны посылаться сигналы, предупреждения и прочие уведомления базы данных, указав для этого адрес электронной почты и адрес почтового сервера, который будет пересылать сообщения электронной почты. Если необходимо создавать ежедневные автоматизированные резервные копии, можно задать время, когда они должны создаваться.
В данном примере агенты управленческого сервиса Grid Control отсутствуют, так что мы выбираем для управления интерфейсом Enterprise Manager средство Database Control. Кроме того, мы указываем адрес электронной почты, куда мы желаем отправлять предупреждения сервера (в нашем случае, bob@rjdba.com).
Верительные данные базы данных
На рис. 1.11 предлагается первоначальный пароль для учетных записей (accounts) административного пользователя. Не забудьте после
Рис. 1.11. Экран верительных данных (Database Credentials) базы данных
Cancel Help
For security reasons you must spec fy passwords for the foliowing user accounts m the nevv database
* Use the Same Password for Ail Accounts
—Т-»-fir'll--;
Password. «•********«•
Confirm Password I*—***-**-
r Use Different Passwords d£*f
•’ <?> i
-
» <-
Back
Знакомство
с архитектурой Oracle
инсталляции завести хотя бы одну учетную запись с полномочиями администратора базы данных (DBA), которая будет использоваться для решения каждодневных административных задач вместо записей SYS и SYSTEM.
Если вы хотите использовать для учетных записей SYS, SYSTEM, DBSNMP и SYSMAN, это можно сделать именно на данном экране; позднее при инсталляции, когда будет создана база данных, вам будет предоставлена возможность изменить все пароли, созданные для примерно 30 учетных записей пользователей, которые обычно создаются при типовой инсталляции.
Опции хранения
База данных может использовать несколько различных методов для хранения файлов данных, управляющих и файлов журналов базы данных. Если ресурсов достаточно, чтобы выделить для управления дисковым пространством специальный экземпляр базы данных, выберите ASM. Экземпляр для управления ASM достаточно “легковесный”; как правило, для него требуется не более 64 Мбайт оперативной памяти. Если вы работаете со средой Real Application Clusters, но вам недоступна кластерная файловая система (например, OCFS), выберите Raw Devices (диски без файловой системы). На рис. 1.12 эти опции показаны на экране Storage Options (опции хранения).
i
г
Next
ack
Finish
Рис. 1.12. Экран опций хранения
5
4
Select the storage rnechan sm you would I ke to. use for the databa e
** File System
Use the F le System for Database storage • . • > ft« •
{ Automatic Storage Management (ASM)
Automatic Storage Management simplifies database storage administrat on and optimizes database layout for I/O performance To use th s option you must either specify a set of disks to create an ASM disk group or specify an existing ASM disk group
Raw De ces
Raw partitions or volumes can provide the required shared storage tor Real Application Clusters (RAC) databases if you do not use Automatic Storage Management and a Cluster Fl e System is not available You need to have created one raw cev.ce for each dataf le. control file, and iog file you are planning to create in the database
70
Гпава 1
Местоположение файлов
На следующем экране (см. рис. 1.13) можно выбрать места расположения файлов данных, управляющих и журнальных файлов, а также места раз-мещения архивных журналов и резервных копий, которые могут быть ио пользованы для восстановления. Можно использовать для этих целей значения, указанные в шаблонах, расположить все файлы в одном месте (использовать для всех файлов один адрес), либо сконфигурировать для своей базы данных OMF (управляемые Oracle файлы). Во всех перечисленных выше случаях впоследствии вам будет предоставлена возможность настроить эти места расположений файлов.
Новинкой для Oracle 10g является использование концепции Flash Recovery Area (область группового flash-восстановления). Это выделенное место на диске, отделенное от мест размещения операционных файлов базы данных, содержит файлы резервных копий из RMAN. Настоятельно рекомендуется использовать Flash Recovery Area, чтобы RMAN было легче управлять операциями резервного копирования и восстановления. Нужно убедиться в том, что область flash-восстановления достаточно велика, чтобы в ней можно было хранить две копии всех файлов базы данных, инкрементальные резервные копии, управляющие файлы, файлы SPFILE и архивные журнальные файлы, все еще остающиеся на диске. На рис. 1.14 изображен экран, на котором можно указать местоположение области flash-восстановления и ее размер по умолчанию.
Spe if/la aliens tor th .Database file? tojbeJcreated
* Use Database FHeWatfens from Template
c use Common Loe a*, ton for AH Database Files
i i • .. •' •
Cancel Help
Use Oracle Managed Files *
If you went tm pecjfy diff -rent locaxfons fo* an datiaba ;e files, . .. * pic.K either of'the above pitons and* use the S’craje:page tp spe иу each location
F e L" ration Variables. •• 1
Рис. 1.13. Экран местоположения файлов базы данных (Database File Locations)
З^кпмствос^архитектурой Oracle
Back | Next
Cancel
Рис. 1.14. Экран конфигурирования и расположения восстановления (Recovery Configuration and Locations)
Choose the recovery options for the database
Specify Flash Recovery Area
This is used as the defaut for all backup and recovery operations, and is also required for automatic backup using Enterprise Manager Oracle recommends that the database files and recovery files be located on physically different d sks for data protection and performance
Flash Rec every Area
{ORACLE_BASE)/flash_rec Browse J
Flash Recovery Area Size
2048
M Bytes
Enable Arc hiving
File Location variables
О
Кроме того, можно использовать режим archivelog, а также указать место (или места) расположения-архивных журналов. Рекомендуется, чтобы в процессе создания базы данных режим архивирования был отключен (off). Значение параметра инициализации для режима archivelog может быть с легкостью изменено в файле init.ora или SPFILE сразу же после того, как база данных будет приведена в рабочее состояние.
Компоненты базы данных ЛЛировать демонстра-
На девятом шаге сеанса DBCA пре^У™1'^)вать демонстрационные схе-ционные схемы. Рекомендуем иНСТ™Р^Хых пособий строится на мы; множество обучающих материал частьЮ базы данных. Кроме том, что демонстрационные схемы лемонстрируют практически вс
того, они полезны тем, что °^Разц^ я в базе данных, в диапазоне от
типы данных и конструкции, содерж таблиц и объектных типов, к
битовых индексов до кластеризованн специфицировать инсталля
ран, изображенный на рис. 1.15, позв адка на этом экране дает
цию демонстрационных схем, тор н ии> КОторые будет неоохо возможность специфицировать дру псле ее создания, например сц димо выполнить для этой базы данных существующих приложении, нарии создания табличных пРос^Ра™й пользователей и т. п. специализированных учетных з
Гпава 1
%<
Рис. 1.15. Выбор режима инсталляции демонстрационных схем
Cancel Help
Sample Schemas Custom Scripts
Sample Schemas illustrate the use of a layered approach to complexity and are used by some demonstration programs Installing this will give you the following schemas m your database Human Resources, Order Entry Online Catalog, Product Media, Queued Shipping, Sales History. It will also create a tablespace called EXAMPLE. The tablespace will be about 130 MB.
Specify whether or not to add the Sample Schemas to your database ^Sample Schemas
Примечание По соображениям безопасности и производительности не следует инсталлировать демонстрационные схемы в промышленно эксплуатируемые базы данных.
Если в этот момент режим инсталляции демонстрационных схем не будет выбран, их можно будет создать позже, используя для этого сценарии из каталога $ORACLE_HOME/demo/schema, после того как будет создана база данных.
Параметры инициализации
Экраны, изображенные на рис. с 1.16 по 1.19, позволяют администратору настроить ключевые параметры инициализации для базы данных. В пре дыдущих разделах этой главы были описаны многие основные парам ры, которые необходимо понимать АБД. В нескольких следующих пар графах эти параметры будут связаны со значениями, которые моЖ ввести на предлагаемых экранах.
На рис. 1.16 изображена вкладка Memory экрана параметров иниП11^ лизации (Initialization Parameters). Если выбрать один из вариант^ Typical (типичный) или Custom (заказной) с Shared Memory ManagenieI Automatic (автоматическое управление разделяемой памятью), ОгаС сделает предположения о том, какой размер памяти доступен для
Знакомство
с архитектурой Oracle
73
Рис. 1.16. Параметры инициализации, закладка Memory (память)
фоновых процессов. Даже при тех значениях по умолчанию, которые принимаются при выборе конфигурации Typical, у вас все еще остается возможность специфицировать, сколько физической памяти может быть использовано для Oracle. Это зависит объема физической памяти, используемого операционной системой, а также от того, планируется ли на этом сервере работа других приложений, кроме Oracle.
Поскольку Java Pool и Large Pool являются опциональными, можно задать их значения равными 0 и выделить больше памяти для Shared Pool и Buffer Cache; однако, если в базе данных используется хотя бы опция Java Stored Procedures (хранимые процедуры Java), значение Java Pool должно быть равно по крайней мере одной грануле базы данных — 4 или 16 Мбайт, но рекомендуется задать хотя бы 20 Мбайт.
На экране, изображенном на рис. 1.17, можно задать используемый по умолчанию размер блока базы данных, а также общее число процессов, которые смогут одновременно подключаться к Oracle, соответствующее параметру инициализации PROCESSES.
Подходящим значением параметра Block Size (размер блока) может ыть 4 Кбайт или (что предпочтительнее) 8 Кбайт при условии, что этот Размер будет кратен размеру блока данных операционной системы. Сего-я точный выбор размера блока данных базы данных не настолько кри-т КаК ЭТ° было в предыдущих версиях Oracle, поскольку для других личных пространств могут быть заданы размеры блока, отличающие-я От заданного по умолчанию размера блока.
74
Глава 1
A block is the smallest unit of storage for allocation and for I/O. it cannot be changed once the database is created
Block Size ;p~
Specify the maximum number of operating system user processes that can be simultaneously connect to this database. The value of this parameter must be 6 or greater (5 for the background processes plus 1 for each user process)
Processes: 250
Memory Sizing CharacterSets Connection Mede
Finish
r,
Cancel Help
Back:
Рис. 1.17. Инициализация параметров, закладка Sizing (задание размеров)
Ail Initialization Parameters
Если Oracle Server (сервер Oracle) работает не в режиме Shared Server (разделяемый сервер) и, следовательно, каждое подключение пользователя будет выделенным подключением, убедитесь, что значение параметра PROCESSES задано достаточно большим, чтобы учесть все ожидающиеся подключения пользователей базы данных и дополнительно не менее 15 для учета фоновых процессов.
На следующем экране DBGA специфицируются языковые параметры для базы данных. Если ваша организация не является многонациональной и в ней нет каких-либо специального рода языковых требований к конечным пользователям базы данных, достаточно удачным будет выбор используемых по умолчанию Database Character Set (набор символов базы данных) и National Character Set (набор символов национального языка) в соответствии с установками сервера. На рисунке 1.18 показаны парамет ры, связанные с NLS (поддержкой национальных языков).
На следующем экране можно специфицировать способ подключения пользователей к базе данных — через выделенные подключения к базе данных или в среде разделяемого сервера. Если выбран режим разделяй мого сервера, можно редактировать некоторые специфические особен ности этой среды, например, какие протоколы используются и сколько соединений будет назначено для каждого процесса диспетчера. На рис. 1.19 выбран режим разделяемого сервера и есть два разделяемых сер верных процесса (shared server process) для обработки запросов на поД ключение, поступающих от диспетчеров.
Знакомство с архитектурой Oracle
75
Memory Sizing Character Sers Connection Mode
Database Character Set
• Use the default
The default character set for this database is based on ?he language setting of this operating system. WE8lSp8859PJ.,
Г Use Unicode (AL32UTF8)
Setting character set to Unicode (AL32UTF8) enables you to store multiple language groups.
r Choose from the list of character sets
Рис. 1.18. Параметры инициализации, закладка Character Sets (наборы символов)
All Initialization Parameters.
Help
Memory Sizing Character Sets Connection Mode
Select the mode in which you want your database to operate bydefauf
r Dedicated Server Mode
For each client connection the database will allocate a resource dedicated to serving only that client Use this mode when the number of total client connections is expected to be small or when clients will be making persistent, long-running requests to the database.
* Shared Server Mode
Several diem connections share a database-allocated pool of resources Use this mode when a large number of users need to connect to the database simultaneously while efficiently utilizing s\-stem resources The Oracle shared server feature will oe enabled
Shared Servers specifies the number of server processes that you want to create when an instance is started up
Shared Server : 2
Edit Shared Server Parameters..
.г
Cancel
Back
Finish
1J g. Параметры инициализации, вкладка Connection Morin (пр HfUU ППП¥1НЛЧЛННл\
76
Гпава 1
1 АП Initialization Parameters г *v •>’ К" - 1 4 5Г 'VAi** Яz , вj , — vr:1.. -Г.1 Л1
у * “ -. b.' • - Name Value Override Default Category
- Л log. archive._de st _ st at e_7 log_archive_dest-State-8 .ЛАЛгг AZ***FS 4**.-+Jt**f4 «ИAZ ► V V V -Z-AZZ Z VM - log_archive_dest_state_9 log.archive_duplex.dest ! enable j enable enable 1 — r*. W ... ЧЛ. A ••--. •• -.4.I • L....- A Archive Archive r«**^ZA4A‘./VAv/»V6r-V - * /.VA* AA^zz* Archive ... i .... ..... . ... Archive w ^>3
.<• nlsjanguage w». a ... ЛЛ»ЛЛ SAVA V4..«AV> АЪЛЛ nl$_territory open.cursors pga_ aggregate-target processes AMERICAN AMERICA 300 25165824 250 ~ ' r— " — 1 jNLS NLL Cursors and Library Cache Son, Hash Joins, Bitmap Indexes Processes and Sessions T i s! ’h : /л rfe ft
- V 1 - V? Ч;- remoteji.stener remote Jogin.passwordfile EXCLUSIVE ^.^.4 Network Registration •"•H* - 1 ! Security and Auditing p; Mi ' • 4 J> i ' •
rollback-segments sessions — sga_target shared.sen/ers star .transformation-enabled 38 A V 'A/VVAVA» 2 FALSE t"»r.-sW,', v.w*v --vwj / i 1 System Managed Undo and Rollba Processes and Sessions V • •—». ** VW. . VW.VXVXVV/. .-XWM wv. .v^ SCA Memory 'O'Ayx^V* . .A.a vfxzx» — • «V «"W WvAA WWJ.VAV/MWV W/rxv.VWWZVW Shared Server X».». . .Л»м V*»V|VXM *4^>> .• V4V--wWA « ZAVVWV^. jVx w A ^Optimizer j; я 7i :-ii i a
... >. undo.management undo.tablespace .ЛЛГл_ rnP1V/ AUTO UND0TBS1 i ! •.I •.4AIV* A**»A*A*> System Managed Undo and Rollba . .V'*^'VXVwAi^-WX-WWVXW*V4 .. .Z/ V'W*’ •— /XVVVW iWWVS..-XV,,. . •» . xX ,..V .Л(V ,4,4, ’4/..Л Л < ( System Managed Undo and Rollba. . Ф! • s f
-v/. » ' 'how Advanced Parameters j » \ ’ *. P • v L a xj:... - l Close! Show Description Help J
4<'-r.2L - ж? • Л- • • -<£ . ' '
Рис. 1.20. Редактирование списка параметров инициализации
Продолжая оставаться в экране инициализации параметров, можно настроить значения всех параметров инициализации, для чего достаточно щелкнуть на кнопке All Initialization Parameters (все параметры инициализации). На рис. 1.20 показано, как можно модифицировать значение параметра SGATARGET или другие параметры, даже если они были неявно определены в одном из предыдущих экранов.
Хранение базы данных
На экране DBCA Database Storage (хранение базы данных) просмотреть и подвергнуть ревизии места расположения управляющих файлов, файлов базы данных и файлов журналов базы данных, а также мультиплексиро ванных управляющих файлов и создать группы журнальных файлов.
На рис. 1.21 показано, как можно мультиплексировать управляю щие файлы по трем различным адресам на диске. Имена и места распо ложения управляющих файлов на этом экране определяют значение параметра CONTROLJFILES в файле параметров инициализации ил в SPFILE.
Варианты создания
На рис. 1.22 показана готовность к созданию базы данных. В дополнен^ можно использовать информацию, предоставленную на предыдущих
тх i-ovnaTirrTb ее в виде шаблона. Если остаются какие-то сомнений»
3! 1?мтвосархитектурой Oracle
":?т\
mromte
1
4
II
-□Datafiles
©□Redo Log Group!
contrciOl. al
real
Help
; ; Cancel
9-_JStorage
General * Options ;
Controlfile Mirror Images
File Name
contrclO2 сП
controlO3. ctl
Fie Directory
(ORACLE. BASE)/oradata/{D8_UNIQUE_NAME}/
{ORACLE.BASE}/oradata/(DB_UNIQUE.NAME}/ (
:(ORACLE_BASE)/oradata/{D8_UNlQUE_NAME}/ I
File Location Variables
6ack; yext
Рис. 1.21. Экран хранения базы данных (Database Storage)
22. Варианты создания базы данных и шаблона
78
Гпава 1
The following operations wll be performed A database called “dbaior will be created
4
Database Details:
General Purpose
:»ase template to create a pre-configured database optimized for genera? purpose usage.
Common Options
Opuuh Seieaed
. r.S J.A, . -s- A-.* •** '•.****--** f .• -,W-' . ЛЛЛ/Л Д'ГЛ/Аг/, yv'.-/» .V -,T* * • ?-• «А • - I
Oracle JVM ’ true
L
I
L
Oracle intermedia
true
Oracle Text
true
Oracle XML DB
true
Orscle OLAP
true
Oracle Spatial
true
Oracle Data Mining
true
OK
Cancel )
Help |
&i
I
1
J
-
«4 ft.;-л ; ! * •
S ' • ‘ >:?< -4; ->
Рис. 1.23. Краткое резюме инсталляции в формате HTML
нужно сохранить эту конфигурацию как шаблон; память, требующаяся для хранения шаблона, минимальна, к тому же шаблон можно легко удалить при последующих запусках DBCA.
Прежде чем будет создана база данных, будет показана краткая сводка (в формате HTML) для создаваемого шаблона типа показанной на рис. 1.23. Эту сводку можно сохранить как файл HTML для последующего доку* ментирования.
Завершение инсталляции
После того как на экране HTML-резюме инсталляции будет нажата кнопка OK, DBCA предпринимает действия по созданию базы данных и запуску экземпляра. При первом запуске базы данных выполняется стан дартный набор сценариев, куда включен сценарий создания демонстра ционных схем, а также любые созданные по заказу (заказные) сценарии» специфицированные ранее. На рис. 1.24 показано, как протекает проЦ^сС выполнения DBCA задач по инициализации.
После завершения выполнения сценариев инициализации и создай#* пользователю предъявляется завершающий (итоговый) экран (с^‘ рис. 1.25), в котором приводится путь к файлу протокола этой инсталД*'
3119кпмствосархитектурой Oracle
Рис. 1.24. Создание и запуск экземпляра Oracle
ции. Рекомендуется ознакомиться с содержимым этого файла, чтобы убедиться в том, что во время инсталляции не было никаких неожиданных ошибок. Этот протокол можно сохранить надиске вместе с другими документами, имеющими отношение к созданной базе данных; Эта информация может впоследствии оказаться полезной в качестве основы для будущих инсталляций.
I Database creation complete. Check the fogfiles
sistan
I Database Information:
J Global Database Name dbalOlrjbdba.com
I System ldentifier(SID): dbalOl <
! Server Parameter Filename? /uOl/app/oracie/product/10.1 O/dbs/spfiledbalOl ora
* The Enterprise Manager URL is http://racO 5500/em
i ?
' Note-Aj| database accounts except SYS, SYSTEM, DBSNMP, and SYSMAN are locked d . select the Password Management button to view a complete list of:locked accounts or to manage the database accounts. From the Password Management window, unlock only
e? courts you will use Oracle Corporation strongly recommends changing the default ‘ if passwords immediately after unlocking the account
f Password Management.
Ifc- . EXit I i
Рис 1.25. Резюме DBCA
80
Гпава 1
Только что созданный экземпляр Oracle запущен и находится в работоспособном состоянии. Теперь можно разблокировать все прочие учетные записи, созданные в процессе инсталляции, и назначить им пароли.
Создание базы данных вручную
В некоторых ситуациях оказывается предпочтительнее создать базу данных вручную, вместо того чтобы использовать для ее создания DBCA. Например, АБД нужно создать одну и ту же базу данных на 20 различных серверах, либо при создании базы данных указать в команде create database такой параметр, который нельзя задать (или настроить) в среде DBCA. Oracle предлагает демонстрационный сценарий создания базы данных, который может быть специально настроен для “ручной” инсталляции. АБД следует использовать DBCA для сохранения сценария создания базы данных в файле, который можно будет позже отредактировать и запустить на выполнение из командной строки SQL*Plus.
Ниже приводятся основные шаги, требующиеся для создания базы данных вручную. Некоторые из этих шагов могут изменяться в зависимости от операционной системы или используемой платформы, и эти различия будут особо подчеркиваться. Прежде чем приступить к попыткам ручной инсталляции, не забудьте познакомиться с руководством по инсталляции для конкретной платформы. Так, например, в среде Windows для создания фонового процесса необходимо выполнить утилиту oradim.exe и задать соответствующие значения в системном реестре (Registry).
1. Примите решение о структуре каталога базы данных; рекомендуется, чтобы при размещении файлов базы данных на дисках имело место соответствие этой структуры стандартам Oracle Optimal Flexible Architecture (OFA — оптимальная гибкая архитектура Oracle) (подробнее об OFA см. главы 3 и 4).
2. Чтобы можно было отличить создаваемый экземпляр базы данных от всех других выполняемых на этом сервере экземпляров базы данных, нужно выбрать для него SID Oracle. Часто для SID используется то же самое имя, что и указанное в параметре инициализации DB_NAME. В строке приглашения Windows для этого следует ввести
set ORACLE_SID = rjbdb
В средах Unix для этого нужно ввести либо
export ORACLE_SID = rjbdb
либо
setenv ORACLE_SID = rjbdb
в зависимости от используемого по умолчанию командного проПеС сора.
3. Установите метод аутентификации для подключения к базе даннЫ^ привилегированных пользователей. Используйте утилиту комаНД ной строки orapwd для создания файла паролей, если вы хотИТе
ЗНАКОМСТВО
с архитектурой Oracle
81
использовать для аутентификации привилегированных пользователей Oracle, а параметр инициализации REMOTE_LOGIN_ PASSWORDFILE был ранее установлен на EXCLUSIVE. Если используется аутентификация привилегированных пользователей операционной системой, необходимость в файле паролей отпадает; установите параметр инициализации REMOTE_LOGIN_ PASSWORDFILE на NONE.
4. Создайте файл параметров инициализации и поместите его в используемое по умолчанию на вашей платформе местоположение на диске, по крайней мере, первоначально, на время инсталляции. В Unix таким местом является $ORACLE_HOME/dbs, а в средах Windows — $ORACLE_HOME\database. Ниже предлагается образец поставляемого с Oracle файла параметров инициализации:
# Кэш и ввод/вывод
DB_BL0CK_SIZE=4096
DB_CACHE_SIZE=20971520
# Курсоры и библиотечный кэш
CURSOR._SHARING~SIMILAR
OPEN_CURSORS= 300
й Диагностика и статистика
BACKGR0UND_DUMP_DEST=/u01/oracle10g/admin/rjbdb/bdump
C0RE_DUMP_DEST=/u01/oracle10g/admin/rjbdb/cdunip
TIMED_STATISTICS=TRUE
USER_DUMP_DEST=/u01/oracle10g/admin/rjbdb/udump
# Конфигурация управляющего файла
C0NTR0L_FILES=(u01/oracle10(?/prod/rjbdb/control01. ctl, u02/oracle10p/prod/rj bdb/control02.ctl, u03/oracle10g/prod/rjbdb/control03.ctl) й Архив
L0G_ARCHIVE_DEST_1=’L0CATI0N=/u06/oracle10g/oradata/rjbdb/archive’
# Новый формат архивного журнала. Если поддерживается совместимость
# с 10.0 и более поздними версиями, он используется в обязательном порядке. LOG_ARCHIVE_FORMAT=%t_%s_%r.dbf
# Следующий параметр в 101R1 не рекомендован к использованию
й LOG_ARCHIVE__START=TRUE
# Разделяемый сервер
й Запускается разделяемый сервер, если установлено значение больше нуля SHARED_SERVERS=2
й Раскомментируй е и используйте первый из приведенных ниже параметров
й DISPATCHER, если прослушивающий процесс сконфигурирован для SSL
й (listener.ога и sqlnet.ora)
й DISPATCHERS = ,,(PROTOCOL=TCPS)(SER=MODOSE)”I
й “(PROTOCOL=TCPS)(PRE=oracle.aurora.server.SGiopServer)” DISPATCHERS = ,,(PR0T0C0L=TCP)(SER=M0D0SE),’1
‘ (PROTOCOL=TCP)(PRE=oracle aurora.server.SGiopServer)”, (PR0T0C0L=TCP)
82
Гпава 1
it Разное
й СОМРАТ1В1_Е=1О.О О
DB_NAME=rjbdb
# Распределенная среда, тиражирование и моментальные снимки
DB_DOMAIN=гjbdba.com
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
й Сетевая регистрация
INSTANCE_NAME=rjbdb
й Пулы
JAVA_POOL_SIZE= 31457280
LARGE_P00L_SIZE=1048576
SHARED_P00L_SIZE=52428800
ti Процессы и сеансы
PROCESSES^ 50
й Файлы журналов базы данных и восстановление
FAST_START_MTTR_TARGET=300
й Диспетчер ресурсов (Resource Manager)
RESOURCE_MANAGER_PLAN=SYSTEM_PLAN
й Сортировки, хеш-соединения и битовые индексы
S0RT_AREA_SIZE=524288
й Автоматическое управление пространством отката
UNDO_MANAGEMENT=AUTO
UNDO_TABLESPACE=undotbs
5. Подключитесь к экземпляру с помощью SQL*Plus, как показано ниже:
sqlplus / nolog
connect SYS/пароль as sysdba
Обратите внимание на то, что, хотя экземпляр, как таковой, и существует, пока мы не слишком много можем с ним сделать, так как пока еще не запущена база данных.
6. Создайте файл параметров сервера (server parameter file — SPFILE)' Если файл параметров инициализации находится в назначенном по умолчанию месте, следующая команда создаст SPFILE:
create spfile from pfile;
7. Запустите экземпляр, используя для этого следующую команду.
startup nomount
Заметьте, что, так как к настоящему моменту еще не создана база данных, это единственный вариант, который может быть испоДЬ зован в команде startup.
Знакомство
с архитектурой Oracle
Задайте оператор create database. Пример такой команды приводится ниже:
CREATE DATABASE rjbdb
USER SYS IDENTIFIED BY paris703
USER SYSTEM IDENTIFIED BY tyler12
LOGFILE GROUP 1(‘/u02/oracle10g/oradata/rjbdb/redo01.log ) SIZE 100M, GROUP 2(‘/u04/oracle10g/oradata/rjbdb/redo02 log’) SIZE 100M, GROUP 3(‘/u06/oracle10g/oradata/rjbdb/redo03.log’) SIZE 100M
MAXLOGFILES 5
MAXLOGMEMBERS 5
MAXLOGHISTORY 1
MAXDATAFILES 100
MAXINSTANCES 1
CHARACTER SET US7ASCII
NATIONAL CHARACTER SET AL16UTF16
DATAFILE '/u01/oracle10g/oradata/rjbdb/system01.dbf’ SIZE 325M REUSE EXTENT MANAGEMENT LOCAL
SYSAUX DATAFILE '/u01/oracle10g/oradata/rjbdb/sysaux01.dbf ’
SIZE 325M REUSE
DEFAULT TABLESPACE tbs_1
DEFAULT TEMPORARY TABLESPACE temptsl
TEMPFILE '/u01/oracle10g/oradata/rjbdb/temp01.dbf’
SIZE 20M REUSE
UNDO TABLESPACE undotbs
DATAFILE ‘/u02/oracle10g/oradata/rjbdb/undotbs01.dbf’
SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
9. Стоит отметить в этом примере еще два момента. Мы явно установили пароли для пользователей SYS и SYSTEM; если не указать их в этот момент, им по умолчанию будут присвоены значения change^ oninstall (изменить после завершения инсталляции) и manager (менеджер), соответственно.
Ю. Группы файлов журналов базы данных имеют в своем составе только по одному члену каждая; когда наша база данных перейдет в стадию промышленной эксплуатации, нам придется мультиплексировать их. Так как мы с помощью параметра UNDO_TABLESPACE в файле параметров инициализации задали табличное пространство отката транзакций, нам необходимо создать его именно сейчас; в противном случае, не удастся запустить экземпляр.
11 • После успешного завершения команды create database база данных будет смонтирована и открыта для использования.
12. Создайте дополнительные табличные пространства для пользователей, индексов и приложений.
13. Постройте представления словаря данных (их часто еще называют словарными представлениями. — Прим, пер.} с помощью прилагаемых сценариев catalog.sql и catproc.sql. Сценарий catalog.sql создает представления таблиц словаря данных, динамические представле
84
Гпава 1
ния производительности и публичные синонимы (public synonyms) для большинства представлений. Группе PUBLIC предоставляется доступ “только для чтения” к этим представлениям. Сценарий catproc.sql создает PL/SQL.
14. Создайте резервную копию базы данных, используя для этого либо “холодное” резервное копирование, либо Recovery Manager (диспетчер восстановления). При аварийном завершении работы базы данных на ранних стадиях развертывания у вас будет иметься полная и работоспособная база данных, к которой можно будет отступить, и, скорее всего, вам уже не потребуется повторно создавать базу данных “с нуля”.
апгрейд ДО ORACLE DATABASE 10б
Если прежде вы уже устанавливали более ранние версии сервера базы данных Oracle, можно обновить вашу базу данных до Oracle Database 10g. Поддерживается много различных путей обновления. Правильный выбор пути обновления зависит от таких факторов как номер версии имеющегося программного обеспечения Oracle и размер базы данных.
Если более ранние версии Oracle, предшествующие Oracle Database 10g, отсутствуют, можно на данном этапе пропустить эту главу. Однако, скорее всего, к ней придется вернуться, когда понадобится переходить от Oracle Database 10g к более поздним версиям, или когда придется переносить в свою базу данных данные (мигрировать. — Прим, пер.) из другой базы данных.
Перед началом апгрейда необходимо прочесть документ «Руководство по инсталляции Oracle Database 10g» (Oracle Database 10g Installation Guide) для соответствующей операционной системы. Успех инсталляции зависит от того, насколько правильно сконфигурирована среда — включая номер патча (исправления) операционной системы и установки системных параметров. Планируйте с первого раза довести инсталляцию и апгрейд до успешного завершения. Это лучше, чем пытаться совершить рестарт после первой «частично удачной» попытки. Сконфигурируйте систему таким образом, чтобы она могла поддерживать как инсталляцию программного обеспечения Oracle, так и создания пригодной к использованию стартерной базы данных.
В этой главе делается предположение, что инсталляция программного обеспечения Oracle Database 10g (см. главу 1) завершилась успешно, и что имеется база данных Oracle, использующая более раннюю версию программного обеспечения Oracle на том же сервере. Для обновления этой базы данных есть четыре возможности:
Используйте Database Upgrade Assistant (утилита-помощник по обновлению базы данных) для руководства и помощи при обновлении. По завершении процесса обновления старая база данных станет базой данных Oracle 10g.
86
Гпава 2
Выполните ручное обновление базы данных. Старая база данных в результате этого процесса станет базой данных Oracle 10g.
Используйте утилиты Export и Import для переноса данных из более ранней версии Oracle в базу данных Oracle 10g. Будет использовано две базы данных — старая база данных, как источник данных для экспорта, и новая база данных — как целевая база данных для импорта.
Скопируйте данные из более ранних версий Oracle в базу данных Oracle 10g. Будет использовано две базы данных — старая база данных как источник для копирования, и новая база данных — как целевая база данных для копирования.
Выполнение апгрейда базы данных «по месту» — будь то с помощью Database Upgrade Assistant или вручную — называется прямым апгрейдом (direct upgrade). Поскольку при прямом апгрейде не требуется создавать для обновляемой (старой) базы еще одну (новую), такой апгрейд может закончиться быстрее и для него потребуется меньше дисковой памяти, чем для непрямого апгрейда.
Примечание Прямой апгрейд базы данных к версии 10tj поддерживается только в том случае, если используемая в настоящее время база данных использует один из следующих релизов Oracle: 8.0.6, 8.1.7, 9.0.1 или 9.2. Если используется любой другой релиз, необходимо сначала провести апгрейд до одного из перечисленных выше релизов, либо воспользоваться какой-то другой опцией апгрейда. Для некоторых версий (как правило, 64-битовых) единственным пригодным для прямого апгрейда является релиз Oracle 8.0.6, так что обязательно отыщите свой релиз в онлайновых матрицах сертификации, найти которые можно на сайте Oracle Metalink.
Примечание Тщательно планируйте апгрейд; может быть, придется выделять время на несколько последовательных апгрейдов и (например, с 8.1.6 на 8.1.7), прежде чем перейти к Oracle Database 10g.
Выбор метода апгрейда
Есть два пути прямого апгрейда и два пути непрямого.
Прямые пути апгрейда выполняют переход быстрее всего, так как база данных обновляется «по месту»; Для других способов требуется копире вание данных либо в файл дампа утилиты Export в файловой системе, либо через связь базы данных. Для очень больших баз данных (very ge databases — VLDB) время, требующееся для полного повторного создания базы данных с помощью непрямых методов, может практически исклю чить эти методы как жизнеспособный вариант.
Первый прямой метод опирается на использование Database Vpgr^ Assistant (DBUA — утилита-помощник по обновлению базы данных). Она является интерактивным инструментальным средством, которое будет руководить вами в процессе апгрейда. DBUA оценивает конфигурацию существующей в данный момент времени базы данных и рекомендует МО дификации, которые могут' быть реализованы в процессе перехода. ЭтИ
даре®Database 10д
87
екомендации могут включать в себя определение размеров файлов и спецификации для нового табличного пространства SYSAUX. После того как эти рекомендации будут приняты, DBUA начинает выполнение апгрейда в фоновом режиме, при этом на консоли можно видеть панель прогресса этого процесса. Утилита DBUA очень похожа по подходу на утилиту-помощника по конфигурированию базы данных (DBCA). DBCA является графическим интерфейсом для шагов и параметров, требующихся для успешного апгрейда (см. главу 1).
Второй прямой метод называется ручным апгрейдом {manual upgrade). В то время как DBUA выполняет сценарии в фоновом режиме, в ручном способе апгрейда участвуют администраторы базы данных, которые собственноручно выполняют сценарии. Подход с ручным апгрейдом дает очень высокий уровень контроля, но одновременно с этим возрастает и уровень риска при апгрейде, так как шаги должны выполняться в надлежащем порядке.
Для апгрейда базы данных можно использовать утилиты Export и Import. В этом методе данные экспортируются из старой версии базы данных, а затем импортируются в базу данных, которая использует новую версию программного обеспечения Oracle. Такой процесс может потребовать много дисковой памяти для хранения нескольких копий данных — в исходной базе данных, в файле дампа Export и в целевой базе данных. В обмен на эти «дополнительные расходы» этот метод дает нам большую гибкость при выборе данных, подвергаемых миграции. Для экспорта можно выбрать конкретные табличные пространства, схемы, таблицы и даже строки.
В методе Export/Import исходная база данных не обновляется; ее данные извлекаются (экстрагируются) и перемещаются, а сама база данных после этого может быть либо удалена, либо эксплуатироваться параллельно с новой базой данных до тех пор, пока не будет завершено тестирование новой базы данных. В процессе выполнения экспорта/импорта каждая строка базы данных сначала выбирается (select) из старой базы данных, а затем вставляется (insert) в новую базу данных. Если база данных большая, для процесса импорта может понадобиться очень много времени, что, в свою очередь, может помешать своевременно предложить новую версию базы данных пользователям (подробнее об утилитах Export и Import см. главу 12).
римечание в зависимости от версии исходной базы данных может потребо-аться использовать определенную версию утилит Export и Import (см. ниже в раз-е «Использование различных версий утилит Export и Import» данной главы).
ere't е,Т°Де копирования данных задается последовательность команд Данн 6 as se^ect или insert as select, которые переходят по связи баз лицьЬ1Х СМ ДЛЯ выб°Рки данных из исходной базы данных. Таб-
в д 1 с°3Даютс в базе данных Oracle 1 Ogna основании запросов к данным исх°Дн°п базе данных. Такой метод позволяет переносить дан-п Инхрементально (постепенно) и позволяет ограничить количество тель НОС“ СТРОК и столбцов. Однако необходимо быть весьма внима-ьным и постоянно следить за тем, чтобы копируемые данные поддер
88
Гпава 2
живали все необходимые отношения между таблицами. Как и в случае метода экспорта/импорта, для больших баз данных этот метод может потребовать большого количества времени.
Примечание Если параллельно с переходом к Oracle IO17 изменяется и операционная платформа, для перемещения данных из одной базы данных в другую можно использовать так называемые переносимые табличные пространства (transportable tablespaces). Для больших баз данных такой метод может оказаться быстрее, чем прочие методы копирования данных (подробнее о переносимых табличных пространствах см. главу 17).
При выборе надлежащего метода апгрейда необходимо правильно оценить техническую эрудицию команды АБД, объем и номенклатуру подлежащих переносу данных, а также допустимое время недоступности исходной базы данных, в течение которого и должен быть произведен апгрейд. Для очень больших баз данных наилучшим вариантом выбора является DBUA, в то время как для баз данных меньших размеров можно использовать и прямые методы.
Перед переходом
Перед началом миграции необходимо создать резервную копию исходной (существующей) базы данных и ее программного обеспечения. Если по какой-либо причине миграция закончится неудачей, и вы окажетесь не в состоянии возвратить базу данных и ее программное обеспечение к ее первоначальной версии, можно будет по сделанной резервной копии провести процесс восстановления и повторного создания базы данных.
Необходимо разработать и протестировать сценарии, которые позволят оценить производительность и функциональные возможности базы данных после перехода (апгрейда). Эта оценка должна включать производительность конкретных операций с базой данных, а также производительность базы данных в целом под значительной пользовательской нагрузкой.
Перед тем как выполнить процесс перехода для промышленно эксплуатируемой базы данных, необходимо попытаться обновить тестовую базу данных, чтобы можно было обнаружить отсутствующие компоненты (например, патчи операционной системы), а также оценить время, требующееся для перехода.
Перед выполнением прямого апгрейда нужно проанализировать таб лицы словаря данных. Во время процесса перехода к Oracle 10g словарь данных будет проанализирован, если он не был проанализирован к этому моменту, так что упреждающее выполнение этого шага позволит увели чить производительность апгрейда.
Использование DBUA
Для использования DBUA достаточно набрать в командной строке команду
□ dbua
10д
89
( спецах UNIX) либо выбрать Database Upgrade Assistant из опции меню Oracle Configuration and Migration Tools (в средах Windows). Если исполь-ся среда UNIX, то для того, чтобы запустить DBUA потребуется акти-вировать дисплей Xwindows.
После запуска DBUA будет отображен экран приветствия (Welcome). На следующем экране нужно из списка доступных баз данных выбрать базу данных, которую необходимо подвергнуть апгрейду. Для апгрейда отбирается по одной базе данных за раз.
После того как будет сделан выбор, запускается процесс апгрейда. Утилита DBUA приступает к выполнению предапгрейдных проверок (например, на наличие устаревших параметров инициализации или слишком малых файлов). После этого DBUA создает табличное пространство SYSAUX — стандартное табличное пространство во всех базах данных Oracle 10g. Можно изменить используемые Oracle по умолчанию местоположения и размеры файлов данных, используемых табличным пространством SYSAUX.
Затем DBUA предложит перекомпилировать ставшие недействительными объекты PL/SQL. Если после апгрейда вы не хотите перекомпилировать эти объекты, первый пользователь этих объектов будет вынужден ждать, пока Oracle выполнит рекомпиляцию во время выполнения.
Затем DBUA предложит (как часть процесса апгрейда) скопировать базу данных. Если перед запуском DBUA была создана рабочая копия базы данных, этот шаг можно пропустить. Если же будет выбран вариант с копированием базы данных из DBUA, утилита закроет базу данных и выполнит автономное резервное копирование файлов данных в указанный каталог. Кроме того, DBUA создаст в этом каталоге пакетный файл для автоматизации восстановления этих файлов на их прежние места.
На следующем шаге определяется, будет ли использоваться для управления базой данных утилита Oracle Enterprise Manager (OEM). Если активируется Oracle Enterprise Manager Agent, подвергнутая апгрейду база данных будет автоматически доступна через OEM.
Будет предложено завершить конфигурирование системы защиты обновленной базы данных. Как и в случае с процессом создания базы данных, можно специфицировать пароли для каждой привилегированной учетной записи или создать единый пароль, применимый для всех учетных записей OEM.
Наконец, будут предложены детали размещения области flash-восста-сет^ы™ (см* главУ 15), установок архивного журнала и конфигурации НЬ1 и* а ^заключительном итоговом экране будут отображены все выбрап-ВЬ1б опВДи апгрейда, и апгрейд начнется только после подтверждения Upg^d р Осле завершения апгрейда DBUA выведет экран Checking все вь е eSU^ts (пРоверка результатов апгрейда), где будут изображены пРоцеШ°Л1п^НЬ1е шаги’ сгенерированные файлы протоколов и статус (управлСа* °ЛаС1Ь экРана’ которая называется Password Management вать/т^е^Ие паРолями)> позволяет управлять паролями и блокиро-гпейтг локировать состояния учетных записей в подвергнувшейся ап-реW оазе данных. Н 7
°пциюрВЫ Не УдовлетвоРепЬ1 результатами апгрейда, можно выбрать estore (восстановить). Если для создания резервной копии была
90
Гпава 2
использована утилита DBUA, восстановление будет выполнено автоматически; в противном случае восстановление придется выполнять вручную.
Когда вы выйдете из DBUA после успешного завершения апгрейда базы данных, DBUA удалит записи, соответствующие старой версии базы данных, из конфигурационного файла сетевого прослушивающего процесса, вставит в него запись для обновленной базы данных и перезагрузит этот файл.
Выполнение прямого «ручного» апгрейда
При «ручном» апгрейде необходимо выполнить те же шаги, которые выполняет DBUA. Результатом этого процесса должен стать прямой апгрейд базы данных, в котором ответственность (и контроль) за каждый шаг процесса апгрейда возложена на вас.
Перед тем как приступить к апгрейду базы данных, вам нужно воспользоваться инструментальным средством Pre-Upgrade Tool (пред-апгрейд-ный инструмент) для ее анализа. Это инструментальное средство предлагается в виде сценария SQL, поставляемого вместе с программным обеспечением Oracle Database 10g. Данный сценарий следует выполнить для базы данных, которой предстоит апгрейд. Файл сценария, который называется utlulOli.sql, размещен в подкаталоге /rdbms/admin домашнего каталога программного обеспечения Oracle 10g. Этот файл должен быть выполнен для базы данных, подлежащей апгрейду, от имени пользователя с привилегиями SYSDBA, а результаты его выполнения записаны в файл протокола. В результатах будут показаны потенциальные проблемы, которые должны быть разрешены до начала апгрейда.
Если вопросов для разрешения не обнаружено, прежде чем продолжить процесс апгрейда, нужно остановить базу данных и выполнить процесс автономного копирования.
Если есть резервная копия базы данных, с которой при необходимости можно будет восстановить базу данных, то можно продолжить процесс апгрейда. Этот процесс детализирован и базируется на сценариях, но нужно проконсультироваться с документацией по инсталляции и апгрейду Oracle для вашей среды и версии. Процесс апгрейда разбит на следующие шаги:
1. Скопируйте конфигурационные файлы (init.ora, spfile.ora, файлы паролей) из их старого местоположения в домашний каталог новой версии программного обеспечения Oracle. По умолчанию конфигурационные файлы можно найти в подкаталоге /dbms на платформах UNIX и каталоге /database на платформах Windows.
2. Удалите из конфигурационных файлов устаревшие и более нс рекомендуемые к употреблению параметры. Обновите параметр COMPATIBLE для Oracle 10. Убедитесь, что для параметра SHARED-POOL_SIZE установлено значение, превышающее 96 Мбайт для 32-битовых платформ и 144 Мбайт для 64-битовых плач форм. Установите PGA_ AGGREGATE-TARGET, по крайней мере, на ^4 Моайт, LARGE,. POOL_SIZE GJ по крайней мере, на 8 Мбайт, a J — OL_SIZE — на
Апгрейд до Oracle Database 10g
91
48 Мбайт. В параметрах Windows установите BACKGROUND_DUMP_ DEST на \oradata\^^_62z3tc^HW?)4x\bdunip и USERJDUMPJDEST на \oradata\t4Wi_6o3?j4_^HHbix\udump под каталогом базового программного обеспечения Oracle. В файлах параметров следует указывать полные пути к файлам.
3. Если выполняется апгрейд кластерной базы данных, установите параметр инициализации CLUSTER DATABASE на FALSE. После апгрейда необходимо снова установить этот параметр на TRUE.
4. Остановите экземпляр базы данных.
5. Если вы используете Windows, остановите сервис, связанный с экземпляром, и удалите сервис Oracle из командной строки приглашения. Для Oracle 8.0 используйте команду ORADIM80 -DELETE-SID имя_экземпляра. Для Oracle 8.1 и более высоких версий используйте команду ORADIM -DELETE -SID имя_экземпляра. Затем, используя ORADIM, создайте новый сервис Oracle Database 10g, как показано ниже:
С:\> ORADIM -NEW -SID SID -INTPWD PASSWORD -MAXUSERS USERS -STARTMODE AUTO -PFILE ORACLE_HOME\DATABASE\INITSID.ORA
Для этой команды можно использовать следующие переменные:
Переменная Описание
SID Имя SID (идентификатора экземпляра) базы данных, подвергаемой апгрейду.
PASSWORD Пароль является новинкой релиза 10.1 для экземпляра базы данных. Это пароль для пользователя, подключенного с привилегиями SYSDBA. Если параметр INITPWD не специфицирован, используется аутентификация операционной системы и никакого пароля не требуется.
USERS Максимальное число пользователей, которым могут быть предоставлены привилегии SYSDBA и SYSOPER.
ORACLE-HOME Домашний каталог для Oracle 10.1. Убедитесь, что вы специфицировали полный путь в опции -PFILE, включая буквенное обозначение дисковода (имя диска), на котором находится домашний каталог Oracle.
6. Если вашей операционной системой является UNIX, убедитесь, что следующие переменные окружения указывают на каталоги нового релиза 10.1: ORACLE_HOME, PATH, ORACLE_NLS33 и LD„ LIBRARY_PATH.
7. Войдите в систему как владелец программного обеспечения Oracle Database 10g.
8. Измените текущий каталог на подкаталог /rdbms/admin под домашним каталогом программного обеспечения Oracle.
9. Подключитесь к SQL"'Plus как пользователь с привилегиями SYSDBA.
10. Выполните команду startup upgrade.
92
Гпава 2
11. Используйте команду spool для фиксирования результатов следующих шагов.
12. Создайте табличное пространство SYSAUX с помощью команды create tablespace. Для этого табличного пространства в зависимости от количества объектов пользователей необходимо выделить от 500 Мбайт до 5 Гбайт дисковой памяти. Табличное пространство SYSAUX должно быть создано со следующими фразами: online, permanent, read write, extent management local и segment space management auto. Все эти фразы, за исключением segment space management auto, являются значениями по умолчанию. Ниже приводится пример:
create tablespace SYSAUX
datafile ‘/u01/oradata/db1/sysaux01.dbf’
size 500m reuse
extent management local
segment space management auto
online;
13. Выполните сценарий для старого релиза. Например, если вы переходите с релиза 8.0.6, выполните только сценарий u080060.sql, а затем перейдите к следующему шагу процесса апгрейда. В приведенной ниже таблице указано соответствие имен сценариев и номеров версий:
Переходим с: Выполнить сценарий:
8.0.6 u0800060.sql
8.1.7 u0801070.sqi
9.0.1 u0900010.sql
9.2 u0902000.sql
14. Остановите спулинг (с помощью команды spool off) и просмотрите spool-файл на предмет наличия ошибок. Примите меры к разрешению всех обнаружившихся на этом этапе проблем.
15. Выполните файл utillOls.sql, используя в качестве входного параметра значение TEXT:
@util101s TEXT
После этого Oracle выведет па экран статус процесса апгрейда. Бу-дут перечислены все обновленные элементы со статусом «Normal successful completion» (Нормальное успешное завершение).
16. Остановите экземпляр и запустите его снова.
17. Выполните сценарий utlrp.sql для рекомпиляции ставших недействительными пакетов. После этого можно проверить, что все пакеты и классы стали действительными:
select distinct Object_Name from DBA_OBJECTS where Status = ‘INVALID’;
Апгрейд до Oracle Database 10g
93
18. Выйдите из SQL*Plus.
19. Остановите базу данных и выполните автономное копирование базы данных; затем перезапустите базу данных. Апгрейд (переход к новой версии) завершен.
Примечание После апгрейда никогда больше нельзя запускать базу данных Oracle 10ff с программным обеспечением предыдущих релизов Oracle.
Использование утилит Export и Import
Утилиты Export и Import предлагают непрямой метод апгрейда. Можно параллельно с действующей базой данных создать новую базу данных Oracle 10gи использовать утилиты Export и Import для перемещения данных из старой базы данных в новую. Когда перемещение данных будет завершено, потребуется переключить все приложения системы со старой базы на новую базу данных. Кроме того, потребуется обновить все конфигурационные файлы, зависящие от номера версии (и релиза) сценарии, а также сетевые конфигурационные файлы (tnsnames.ora и listener.ora), чтобы в них появились указания на новую базу данных.
Версии утилит Export и Import, которыми надлежит пользоваться
Когда создается файл дампа утилиты Export, его можно будет впоследствии импортировать во все последующие релизы Oracle. Файлы дампа Export не обладают свойством обратной совместимости, так что если вам когда-нибудь потребуется вернуться к более ранней версии Oracle, вам придется очень тщательно изучить использующиеся версии утилит Export и Import. Приведенная ниже таблица показывает версии исполняемых файлов утилит Export и Import, которые должны использоваться при переходе между различными версиями Oracle:
Экспорт из: Импорт в: Используйте утилиту Export для: Используйте утилиту Import для:
Release 9.2 Release 10.1 Release 9.2 Release 10.1
Release 8.1.7 Release 10.1 Release 8.1.7 Release 10.1
Release 8.0.6 Release 10.1 Release 8.0.6 Release 10.1
Release 7.3.4 Release 10.1 Release 7.3.4 Release 10.1
Release 10.1 Release 8.0.6 Release 8.0.6 Release 8.0.6
Release 10.1 Release 8.1.7 Release 8.1.7 Release 8.1.7
Release 10.1 Release 9.0.1 Release 9.0.1 Release 9.0.1
Release 10.1 Release 9.2 Release 9.2 Release 9.2
Release 10.1 Release 10.1 Release 10.1 Release 10.1
94
Гпава 2
Обратите внимание на то, что при выполнении экспорта, для того чтобы понизить версию (downgrade) базы данных, нужно использовать более старую версию утилиты Export, чтобы свести к минимуму проблемы совместимости. Все-таки можно столкнуться с проблемой совместимости, если в более новой версии базы данных будут использоваться новые возможности (например, новые объектные типы), которые не поддерживаются старой версией.
Выполнение апгрейда
Экспортируйте данные из исходной базы данных, используя для этого версию утилиты Export, выбранную на основании таблицы из прошлого раздела. Выполните так называемый согласованный экспорт или выполните экспорт в то время, когда база данных недоступна для обновлений (причем как во время экспорта, так и после него).
Примечание Если в вашем распоряжении мало свободной дисковой памяти, можно сделать резервную копию существующей (исходной) базы данных, а затем удалить ее, после чего приступить к инсталляции программного обеспечения Oracle Database 10д и создать новую (целевую) базу данных для импорта. Если это возможно в принципе, постарайтесь осуществить параллельное сопровождение старой и новой (исходной и целевой) баз данных во время апгрейда. Единственное преимущество от сохранения на сервере только одной базы данных в каждый момент времени состоит только в том, что они могут разделить (т. е. использовать совместно. — Прим, пер.) одно и то же имя базы данных.
Инсталлируйте программное обеспечение Oracle Database 10g и создайте целевую базу данных. В целевой базе данных заново создайте пользователей и табличные пространства, необходимые для хранения исходных данных. Если исходная и целевая база данных будут сосуществовать на сервере, потребуется быть очень внимательным, чтобы не затереть файлы данных одной базы данных файлами другой. Утилита Import будет пытаться выполнить команды create tablespace, обнаруженные ей в файле дампа Export, а в этих командах будут записаны имена файлов данных из исходной базы данных. По умолчанию данные команды должны завершиться аварийно, если эти файлы уже существуют (хотя это препятствие можно преодолеть с помощью параметра DESTROY утилиты Import). Чтобы избежать подобной проблемы, предварительно создайте табличные пространства с надлежащими именами файлов данных.
Примечание Можно экспортировать конкретные табличные пространства, пользователей, таблицы и строки.
После того как база данных будет подготовлена, используйте для загрузки данных из файла дампа Export в целевую базу данных утилиту Import или Data Pump Import. Проверьте файл протокола импорта, чтобы получить информацию об объектах, которые не были успешно импортированы.
Апгрейд до Oracle Database 10g
95
Использование метода копирования данных
Метод копирования данных требует параллельного сосуществования исходной и целевой баз данных. Этот метод является наиболее подходящим, когда подлежащие переносу таблицы достаточно малы и их количество также не слишком велико. Как и для метода Export/Import, на время переноса данных (и на какое-то время после него) следует защититься от транзакций, происходящих в исходной базе данных. В этом методе данные выделяются посредством запросов через связи баз данных.
Создайте целевую базу данных, используя программное обеспечение Oracle Database 10g, а затем предварительно создайте табличные пространства, пользователей и таблицы, которые должны быть заполнены данными из исходной базы данных. Создайте связи баз данных (см. главу 16) в целевой базе данных, которые и будут получать доступ к учетным записям исходной базы данных. Используйте команду insert as select для переноса данных из исходной базы данных в целевую.
Метод копирования позволяет переносить в целевую базу данных только необходимые вам строки и столбцы; миграция данных определяется (и ограничивается) вашими запросами. Потребуется быть очень осторожными с отношениями между таблицами исходной базы данных, чтобы эти отношения можно было надлежащим образом воспроизвести в целевой базе данных. Если в вашем распоряжение имеется длительное технологическое окно в работе приложения (запланированный перерыв в работе для производства модернизации программного обеспечения приложения или каких-либо технологических операций. — Прим, пер.), пригодное для выполнения апгрейда и модификации структуры данных во время их переноса, метод копирования данных может оказаться вполне пригодным для ваших нужд. Этот метод требует, чтобы данные одновременно хранились в нескольких местах, тем самым увеличивая потребность в дисковой памяти.
Для повышения производительности этого метода можно рассмотреть следующие варианты:
Заблокировать все индексы и ограничения, пока не будут загружены все данные. ,
Запустить параллельно несколько заданий на копирование данных.
Использовать опцию параллельных запросов для усовершенствования производительности индивидуальных запросов и операций вставки.
Использовать подсказку APPEND для повышения производительности операций вставки.
Начиная с Oracle 10g, появилась возможность использовать так называемые переносимые табличные пространства. При переносе табличных пространств фактически экспортируются и импортируются только метаданные для табличного пространства, в то время как файлы данных просто физически перемещаются со старой платформы на новую. Для очень больших баз данных время, требующееся для переноса файлов данных, может оказаться значительно меньше, чем время, требующееся для вы
96
Глава 2
борки и повторной вставки строк (подробнее об использовании переносимых табличных пространств см. главу 17).
Дополнительные советы по настройке производительности приводятся в главе 8.
После перехода
После перехода необходимо перепроверить файлы конфигурации и параметров, относящиеся к базе данных, особенно когда в процессе миграции было изменено имя экземпляра. К числу проверяемых файлов следует отнести:
Файл tnsnames.ora
Файл listener.ora
Программы, в которых имя экземпляра может быть жестко запрограммировано
Примечание Если для выполнения апгрейда не используется DBUA, необходимо вручную перезагрузить модифицированный файл listener.ora.
Необходимо также проверить файл параметров инициализации, чтобы убедиться в том, что из него полностью исключены не рекомендованные к употреблению и устаревшие параметры. Такие параметры должны быть идентифицированы во время процесса миграции. Не забудьте перекомпилировать все написанные вами программы, в которых используются библиотеки программного обеспечения базы данных.
После завершения обновления нужно выполнить функциональные тесты и тесты производительности, идентифицированные еще до начала апгрейда. Если появятся вопросы относительно функциональных возможностей базы данных, попытайтесь идентифицировать любые установки параметров или отсутствующие объекты, которые могут повлиять на результаты теста. Если проблема не может быть разрешена, возможно, придется возвратиться к прежнему релизу.
ПЛАНИРОВАНИЕ ТАБЛИЧНЫХ ПРОСТРАНСТВ И УПРАВЛЕНИЕ ИМИ
Планирование компоновки табличных пространств базы данных напрямую влияет на ее производительность и на простоту управления. В этой главе рассматриваются различные типы табличных пространств, а также как использование временных табличных пространств может управлять размером и количеством табличных пространств базы данных, усиливая опцию группы временных пространств, ставшую новинкой в Oracle 10g.
Будет показано, как оптимальная гибкая архитектура Oracle (Optimal Flexible Architecture — OFA), поддерживаемая начиная c Oracle 7, помогает стандартизировать структуру каталога как для выполняемых модулей Oracle, так и для файлов самой базы данных.
Стандартная (или используемая по умолчанию) инсталляция Oracle предлагает АБД хорошую отправную точку, не только создавая соответствующую OFA структуру каталогов, но и автоматически разделяя сегменты на некоторое количество табличных пространств, отталкиваясь от функций сегментов. Будут рассмотрены требования к дисковой памяти для каждого из этих табличных пространств и предложены некоторые советы, как настроить характеристики этих табличных пространств.
В конце главы представлены некоторые руководящие принципы, призванные помочь распределить сегменты по различным пространствам. Такое распределение проводится на основании типа и размера сегментов, а также частоты обращений к ним. Кроме того, мы расскажем, как идентифицировать «горячие точки» (так называются участки программы или файла, обращения к которым происходят наиболее часто. — 11рим. Пер.) в одном или нескольких табличных пространствах.
Архитектура табличного пространства
Необходимым предварительным условием полного создания всех табличных пространств для базы данных является понимание различных типов табличных пространств и того, как они испопк'зх/т^т-г’гг « ~-
98
Гпава 3
Oracle. Ниже рассматриваются различные типы табличных пространств и даны примеры того, как ими можно управлять.
В дополнение предлагается обзор оптимальной гибкой архитектуры Oracle (OFA) и обеспечение каркаса для хранения файлов данных табличных пространств, а также выполняемых файлов Oracle и других его компонентов, например файлов журналов базы данных и управляющих файлов и т. д. Будут рассмотрены типы табличных пространств по категориям — табличные пространства SYSTEM, SYSAUX, временные табличные пространства, табличные пространства отката и табличные пространства типа bigfile — и описаны их функции.
Типы табличных пространств
Основными типами табличных пространств в базах данных Oracle являются постоянные и временные табличные пространства, а также табличные пространства отката. В постоянных табличных пространствах содержатся сегменты, существование которых не ограничено текущим сеансом или транзакцией (т. е. они существовали до и будут, возможно, существовать после этого сеанса или транзакции. — Прим. пер.).
Хотя табличные пространства отката также могут содержать сегменты, которые будут сохранены и после окончания сеанса или транзакции, они обеспечивают согласованность по чтению (read consistency) для операторов выборки данных (select), которые обращаются к модифицируемым таблицам, а также данные отката для значительного количества ретроспективных (flashback) возможностей базы данных. Однако главным назначением сегментов отката является сохранение старых значений модифицируемых (обновляемых и удаляемых) столбцов, или указание па то, что не существует строки для вставки, так что, если сеанс пользователя аварийно закончится еще до того, как пользователь задаст команду commit или rollback, все обновления, вставки или удаления будут автоматически отменены. Прямой доступ к сегментам отката из сеанса пользователя всегда запрещен, и в табличных пространствах отката могут' содержаться только управляемые автоматически сегменты отката (undo segments).
Как следует из их названия, во временных табличных пространствах содержатся только переменные (динамические) данные (transient data), которые существуют исключительно во время сеанса, например дисковое пространство, необходимое для завершения операции сортировки, которая не умещается целиком в оперативной памяти.
Табличные пространства типа bigfile могут' быть использованы для любого из трех упомянутых выше типов табличных пространств, и они упрощают управление табличными пространствами, перенося точку приложения усилий по сопровождению с файлов данных на табличные пространства. Табличные пространства типа bigfile состоят из одного и только одного файла данных.
Постоянные табличные пространства
Двумя примерами постоянных табличных пространств являются табличные пространства SYSTEM и SYSAUX. Любой сегмент, который должен быть сохранен в памяти пользователем или приложением вне граНИц сеанса ------я r постоянном га ли том пространстве.
Планирование табличных пространств и управление ими
99
Табличное пространство SYSTEM
Сегменты пользователей никогда и ни в коем случае не должны храниться в табличном пространстве SYSTEM. Начиная с Oracle 10g, появилась возможность объявлять по умолчанию постоянные табличные пространства, а не только временные, как это имело место в Огас1е9г.
Если для создания базы данных используется Oracle Universal Installer (OUI — универсальный инсталлятор Oracle), создается еще одно табличное пространство, отделенное от SYSTEM, которое будет использоваться для хранения как постоянных, так и временных сегментов. Если же база данных создается вручную, обязательно нужно создать как постоянное подразумеваемое (т. е. используемое по умолчанию) табличное пространство, так и временное подразумеваемое табличное пространство, как это сделано в приводимом ниже примере.
□ CREATE DATABASE rjbdb
USER SYS IDENTIFIED BY paris703
USER SYSTEM IDENTIFIED BY tyler12
LOGFILE GROUP 1 (7u02/oracle10p/oradata/rjbdb/redo01. log’) SIZE 100M,
GROUP 2 (‘/u04/oracle10g/oradata/rjbdb/redo02.log’) SIZE 100M, GROUP 3 (Vu06/oracle10g/oraciata/rjbdb/redo03.log’) SIZE 100M
MAXLOGFILES 5
MAXLOGMEMBERS 5
MAXLOGHISTORY 1
MAXDATAFILES 100
MAXINSTANCES 1
CHARACTER SET US7ASCII
NATIONAL CHARACTER SET AL16UTF16
DATAFILE 7u01/oracle10p/oradata/rjbdb/system01.dbf’) SIZE 325M REUSE EXTENT MANAGEMENT LOCAL
SYSAUX DATAFILE 7u01/oracle10g/oradata/rjbdb/sysaux01.dbf’
SIZE 325M REUSE
DEFAULT TABLESPACE USERS
DATAFILE 7u03/oracle10^/oradata/rjbdb/users01 .dbf’
SIZE 50M REUSE
DEFAULT TEMPORARY TABLESPACE tempsl
TEMPFILE 7u01/oracle10^/oradata/rjbdb/temp01.dbf’
SIZE 20M REUSE
UNDO TABLESPACE undotbs
DATAFILE ‘/u02/oracle10p/oradata/rjbdb/undotbs01.dbf’
SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
Начиная c Oracle 10g, по умолчанию табличное пространство SYSTEM является управляемым локально (locally managed); другими словами, всем использованием пространства управляют с помощью сегмента с битовой картой (bitmap), помещенного в первой части первого файла данных табличного пространства. В базе данных, для которой табличное пространство SYSTEM является локально управляемым, остальные табличные пространства также должны быть локально управляемыми, либо их можно будет открывать только для чтения. Использование локально управляемых табличных пространств в какой-то степени понижает конкуренцию
100
Гпава 3
за табличное пространство SYSTEM, поскольку для операций выделения и освобождения памяти для табличного пространства более не требуется получать доступ к таблицам словаря данных (подробнее об управляемых локально табличных пространствах см. главу 6).
Табличное пространство SYSAUX
Как и в табличном пространстве SYSTEM, в табличном пространстве SYSAUX не должны содержаться никакие сегменты пользователей. Представление о содержимом табличного пространства SYSAUX с разбивкой по приложениям можно получить, используя ЕМ Database Control (управление базой данных с помощью ЕМ). Табличное пространство SYSAUX можно редактировать, если щелкнуть на ссылке Tablespaces (табличные пространства) на вкладке Administration (администрирование). На рис. 3.1 приводится графическое представление использования памяти в SYSAUX.
Если использование дискового пространства каким-то конкретным приложением, размещенным в SYSAUX, становится чрезмерным или создает узкие места для ввода/вывода вследствие высокой конкуренции с другими приложениями, также использующими табличное пространство SYSAUX, можно переместить одно или несколько таких приложений в другое табличное пространство. Прокручивая экран рис. 3.1 вниз, можно выбрать одного их «жильцов» SYSAUX и переместить его в другое таб-
Рис. 3.1. Содержимое табличного пространства SYSAUX, показанное ЕМ Database Control
Планирование табличных пространств и управление ими
101
Г -^Ofacte fnteyprrve Manager Tablespace: SySAUX - Microsoft Internet er a a
pje Edt View Favorites Tools Help Я
’ .. .... . > - ' a - - • . ,...... Favorites . . . ' i3 a g
http://l 92.168.2,170:5&J0/em/con5ole/database/stora5e/t^jfespdce?target««rdc0.workiatype=ord<:le_clatdba5e«<canceLJRL«/err v g a =0
Occupants of SYSAUX Zv
Л ; .J Change Tablespace)
fc 1 ИБВ 11. - • ; Space Hied
SeteclHam» << .... Schema Spate Шхч! д'ММ . Л. ' (M
0 Server Manageability - Automatic Workload SYS 98 63 29 48 *
I Repository
О other 91 81 27 44
О enterprise Manager Repository SYSMAN 68.13 20 38
Q Server Manageability Optimizer Statistics SYS 24 B3 7 44
| History
О Server Manageability - Advisor Framework SYS 8 44 252 I •.
0 LogMiner SYSTEM 7 31 2 19
О Oracle Ultra Search WKSYS 7 13 213
О Workspace Manager WMSYS - 6.50 1 94
О Oracle Spatial MDSYS 5.94 1 77 .
О Oracle Data Mining DMSYS 5.39 1.61 -
О Oracle Text CTXSYS 4.63 1.38
О Server Manageability - Other Components SYS 300 090
О Analytical Workspace Object Table SYS 0.94 0.28
: О OLAP API History Tables SYS 0.94 028 Yr-
*. Lf.'?: ' 1 I. ' ' , 4 : Ф Internet
Рис. 3.2. Использование ЕМ Database Control для перемещения «жильца» из SYSAUX
личное пространство, как показано на рис. 3.2 (о перемещении «жильца» SYSAUX в другое табличное пространство см. главу 6).
Мониторинг табличного пространства SYSAUX можно вести точно так же, как мониторинг любого другого табличного пространства. Ниже в данной главе показано, как ЕМ Database Control может помочь идентифицировать «горячие точки» табличного пространства.
Табличное пространство отката
В базе данных может быть несколько табличных пространств отката, но в каждый момент времени активным может быть только одно из них. Табличные пространства отката используются для отката (rolling back) транзакций, для обеспечения согласованности по чтению для команд select, которые выполняются одновременно с операторами DML для той же самой таблицы (или набора таблиц), а также для поддержки некоторых возможностей Oracle Flashback, например Flashback Query (ретроспективный запрос).
Необходимо правильно задать размер табличных пространств отката, чтобы избежать появления ошибки типа «Snapshot too old» (моментальный снимок слишком устарел), и обеспечить достаточное количество дисковой памяти для поддержки таких параметров инициализации, как UNDO RETENTION (подробнее о том, как вести мониторинг, определять размер и создавать табличные пространства, см. главу 7).
102
Гпава 3
Временные табличные пространства
В базе данных в любой момент времени может быть более одного активного и находящегося в оперативном режиме временного табличного пространства. Но до появления Oracle 10g несколько сеансов одного и того же пользователя должны были использовать одно и то же временное табличное пространство, так как пользователю могло быть назначено только одно используемое по умолчанию временное табличное пространство. Для разрешения этого потенциального узкого места с производительностью Oracle теперь поддерживает так называемые группы временных табличных пространств. Группа временных табличных пространств — это просто синоним списка временных табличных пространств.
Группа временных табличных пространств не может быть пустой и должна состоять, по крайней мере, из одного временного табличного пространства. Если в группе временных табличных пространств не остается ни одного члена, она перестает существовать.
Одно из больших преимуществ использования групп временных табличных пространств состоит в том, что пользователю, одновременно использующему несколько сеансов, предоставляется возможность использовать для каждого из сеансов собственное временное табличное пространство. На изображенной на рис. 3.3 диаграмме у пользователя Е есть два активных сеанса, каждому из которых для выполнения операций сортировки требуется временная дисковая память.
Вместо того чтобы назначить каждому пользователю по одному временному табличному пространству, назначается группа табличных пространств; в данном примере пользователю ОЕ назначается группа временных табличных пространств TEMPGRP. Однако, поскольку в группе временных табличных пространств TEMPGRP фактически содержится три временных табличных пространства, первый сеанс пользователя ОЕ может использовать временное табличное пространство TEMPI, а оператор select, выполняемый вторым сеансом пользователя ОЕ, может параллельно использовать оставшиеся два временных табличных пространства—ТЕМР2 и ТЕМРЗ. До появления Oracle 10g оба сеанса были обязаны использовать одно и то же временное табличное пространство, что потенциально могло привести к возникновению проблем с производительностью.
Рис. 3.3. Гоуппа временных табличных пространств TEMPGRP
Планирование табличных пространств и управление ими
103
Создание группы временных табличных пространств — очень простое дело. После создания индивидуальных табличных пространств TEMPI, ТЕМР2 и TEMPS можно следующим образом построить группу временных табличных пространств и присвоить ей имя TEMPGRP:
□ SQL> alter tablespace tempi tablespace group tempgrp, Tablespace altered.
SQL> alter tablespace temp2 tablespace group tempgrp; Tablespace altered.
SQL> alter tablespace temp3 tablespace group tempgrp; Tablespace altered.
Для изменения подразумеваемого временного табличного пространства на TEMPGRP используется та же самая команда, что и при назначении фактического временного табличного пространства по умолчанию; в логическом отношении группы временных табличных пространств рассматриваются точно так же, как и временные табличные пространства:
□ SQL> alter database default temporary tablespace tempgrp; Database altered.
Чтобы удалить группу временных табличных пространств, необходимо сначала удалить все ее члены. Удаление члена труппы табличных пространств сопровождается назначением группе временного табличного пространства с пустой строкой имени (другими словами, удалением пространства из группы): # *
□ SQL> alter tablespace temp3 tablespace group Tablespace altered.
Назначение группы временных табличных пространств пользователю идентично назначению пользователю временного табличного пространства; это назначение может быть сделано либо при создании пользователя, либо в некоторый момент времени в будущем. В следующем примере новому пользователю JENWEB назначается временное пространство TEMPGRP:
J SQL> create user jenweb identified by pi4001
2 default tablespace users
3 temporary tablespace tempgrp;
User created.
Если во время создания пользователя не назначить ему табличное пространство, пользователю JENWEB все равно будет назначено в качестве временного табличного пространства TEMPGRP, потому что именно оно является значением по умолчанию из предыдущего примера с командой create database.
В словарные представления, поддерживающие группы временных табличных пространств, были внесены некоторые изменения. В словарном представлении DBA_USERS по-прежнему имеется столбец EMPORARY—TABLESPACE, как в предыдущих версиях Oracle, но теперь в этом столбце может содержаться либо имя временного табличного
104
Гпава 3
пространства, назначенного пользователю, либо имя группы временных табличных пространств.
□ SQL> select username, default_tablespace, temporary_tablespace
from dba_users where username = ‘JENWEB’;
USERNAME
DEFAULTTABLESPACE TEMPORARY_TABLESPACE
JENWEB
USERS
TEMPGRP
1 row selected.
Новое словарное представление DBA_TABLESPACE_GROUPS показывает членов каждой группы временных табличных пространств:
□ SQL> select group_name, tablespace_name from dba_tablespace_groups;
GROUP-NAME
TABLESPACE NAME
TEMPGRP
TEMPGRP
TEMPGRP
TEMPI
TEMP2
TEMP3
3 rows selected.
Как и для большинства других возможностей и опций Oracle, которые могут быть выполнены из командной строки, назначение членов группы временных табличных пространств (или удаление из нее членов) может быть выполнено с использованием ЕМ Database Control. На рис. 3.4 видно, как можно добавить члены в группу временных табличных пространств (или удалить их из нее).
Bigfiles
Табличное пространство типа bigfile упрощает администрирование базы данных, так как это пространство состоит всего из одного файла данных. Этот единственный файл данных может иметь размер до 8 экзабайт. Многие команды, которые ранее были доступны только для сопровождения файлов данных, теперь стали доступны и на уровне табличных пространств, если это табличное пространство принадлежит к типу bigfile (о создании и обслуживании таких табличных пространств см. главу 6).
Оптимальная гибкая архитектура
Оптимальная гибкая архитектура Oracle (Optimal Flexible Architecture
OFA) предлагает руководящие указания по облегчению сопровождения программного обеспечения и файлов данных Oracle, а также для повышения производительности базы данных за счет такого размещения файлов базы данных, при котором сводятся к минимуму узкие места ввода/вывода.
Хотя использование OFA не является строго обязательным при инсталляции и сопровождении среды Oracle, тем не менее, применение
Планирование табличных пространств и управление ими
105
Рис. 3.4. Использование ЕМ Database Control для редактирования групп временных табличных пространств
OFA значительно облегчает эти действия для любого, кто понимает, как организована база данных на диске. Благодаря OFA удается избежать большинства ночных телефонных звонков как раз, когда вы находитесь в отпуске!
OFA бывает разной в зависимости от используемых опций хранения — будет ли это среда автоматического управления хранением данных (Automatic Storage Management — ASM) или стандартная файловая система операционной системы, в которой может использоваться (или не использоваться) менеджер логических томов (Logical Volume Manager — LVM) от третьих фирм или дисковые подсистемы с RAID.
Среда без ASM
В среде без ASM на Unix-сервере, чтобы удовлетворить рекомендациям OFA, требуются, по крайней мере, три файловые системы на отдельных оизических устройствах. Если идти сверху вниз, то рекомендованным форматом для точки монтирования будет /<строковая_константа><число-вой__ключ>, где <строковая_константа> может состоять из одной или нескольких букв, а <числовой^ключ> — из двух или трех цифр. Так, например, для одной из систем точки монтирования могут иметь следующий вид: /и01, /и02, /иОЗ и /и04, после чего в распоряжении АБД остается достаточно места для размещения еще 96 точек монтирования, прежде чем потребуется изменить так называемое соглашение об именовании файлов
106
Гпава 3
Рис. 3.5. Структура каталогов, соответствующая 0FA
(file-naming convention). На рис. 3.5 изображена компоновка типичной файловой системы Unix с соответствующей OFA структурой каталогов.
На этом сервере есть два экземпляра: экземпляр с ASM для управления группами дисков и стандартный экземпляр СУРБД.
Выполняемые файлы программного обеспечения
Выполняемые файлы программного обеспечения для каждого продукта должны находиться в каталоге, имя которого выглядит следующим образом: /<строковая^кстстанта><числовой_ключ>/<тип_каталога>/ <владелец_продукта>, где <строковая_константа> и <чимовай^ключ> были определены ранее, <тип_каталога> означает тип файла, инсталлированного в этом каталоге, а <владелец^продукта> — это имя пользователя, который владеет файлами с программным обеспечением и инсталлировал их в этом каталоге. Например, в каталоге /и01 /арр/oracle/ должны содержаться имеющие отношение к приложению файлы (выполняемые файлы), инсталлированные на сервере пользователем oracle. В каталоге /и01/app/apache будут храниться исполнимые файлы web-сервера промежуточного слоя, инсталлированного из прежней версии Oracle.
Начиная с Oracle 10g, стандарт OFA делает инсталлирование нескольких версий программного обеспечения базы данных и клиентского программного обеспечения в рамках одного каталога высшего уровня значительно более легким для АБД. Соответствующий OFA путь к домашнему каталогу Oracle, содержащийся в переменной окружения ORACLE^ НОМЕ, содержит суффикс, соответствующий типу и инкарнации инстал
Планирование табличных пространств и управление ими
107
ляции. Например, две различные инсталляции Oracle 10g и одна инсталляция Огас1е9г могут размещаться в следующих трех каталогах:
□ /u01/app/oracle/product/9.2.0.1
/и01/арр/оracle/product/10.1.O/db_1 /u01/app/oracle/product/10.1.0/db_2
В то же самое время и в том же самом родительском каталоге могут храниться и выполняемые, и конфигурационные файлы клиентского обеспечения Oracle:
□ /и01/арр/оracle/product/10.1.0/client_1
В некоторых инсталляционных каталогах никогда не может быть более одного экземпляра для данного продукта; например, Oracle Cluster Ready Services (CRS — сервисы Oracle для кластеров) может быть установлен в данном каталоге всего один раз с учетом предыдущей инсталляции:
□ /и01/арр/оracle/product/10.1.0/crs
Поскольку CRS может быть инсталлирован в системе только один раз, необходимость в числовом суффиксе для обозначения номера экземпляра отпадает.
Файлы базы данных
Любые файлы базы данных Oracle без ASM должны постоянно находиться в каталоге /<точка_монтг1ирования>/<гьмя_бозы_данных>, где <тпоч-ка_м(мтирования> — это одна из точек монтирования, обсуждавшихся ранее, а <имя_базы_данных> — значение параметра инициализации DB_ NAME. Например, в /u02/oradata/rac0 и /иОЗ/oradata/racO будут содержаться (без ASM) управляющие файлы, журнальные файлы и файлы данных базы данных экземпляра гасО/, в то время как в /иОб/oradata/devl — те же самые файлы для экземпляра devl на том же самом сервере. Соглашение об именовании для различных типов файлов в каталоге oradata приведено в таблице 3.1.
Хотя имена табличных пространств Oracle могут иметь длину до 30 символов, рекомендуется в средах Unix не называть их именами длиннее 8 символов. Поскольку переносимые имена файлов в Unix ограничены 14 символами, а суффикс имени файла данных в OFA имеет вид <n>.dbf, где п~ двузначное число, получается, что для записи суффикса требуется 6 цифр, а на само имя файла остается не более 8 символов.
В каталоге /<точка_монтпирован11Я>/отг.бгХ.л/ <гсмя_базы данных> должны храниться только управляющие файлы, файлы журналов базы данных и файлы данных, ассоциированные с базой данных <имя_базы_данных>. Для базы данных ord, управляемой без ASM, имена файлов данных должны иметь следующий вид:
О SQL> select file#, name from v$datafile;
FILE# NAME
1 /u05/oradata/ord/system0l.dbf
2 /u05/oradata/ord/undotbs01.dbf
108
Глава 3
z
3 /u05/oradata/ord/sysaux01.dbf
4 /u05/oradata/ord/users01.dbf
5 /u09/oradata/ord/example01.dbf
6 /u09/oradata/ord/oe_trans01.dbf
7 /u05/oradata/ord/users02.dbf
8 /u06/oradata/ord/logmnr_rep01.dbf
9 /u09/oradata/ord/big_users.dbf
10 /u08/oradata/ord/idx01.dbf
11 /u08/oradata/ord/idx02.dbf
12 /u08/oradata/ord/idx03.dbf
13 /u08/oradata/ord/idx04.dbf
14 /u08/oradata/ord/idx05.dbf
15 /u08/oradata/ord/idx06.dbf
16 /u08/oradata/ord/idx07.dbf
17 /u08/oradata/ord/idx08.dbf
17 rows selected.
Все файлы данных базы ord, за исключением файлов 9, подчиняются OFA и разнесены по двум различным точкам монтирования. Имя табличного пространства для файла № слишком длинное, а у файла № нет двузначного числового счетчика для представления новых файлов данных для того же самого табличного пространства.
Среда ASM
В среде ASM выполняемые файлы хранятся в каталоге со структурой типа описанной ранее; однако в каталоге /и02/oradata на рис. 3.5 нет файлов. Все управляющие файлы, файлы журналов базы данных и файлы данных для этого экземпляра управляются ASM-экземпляром +ASM на этом же сервере.
Таблица 3.1.
Соглашение об именовании для соответствующих OFA управляющих файлов, файлов журналов базы данных и файлов данных
Тип файла Формат имени файла Переменные
Управляющие файлы control.ctl Нет
Журнальные файлы redo<n>.log п является двузначным числом
Файлы данных <to>.dbf t—это имя табличного пространства Oracle, а л — двузначное число
\
Для большинства административных функций не требуется знание реальных имен файлов данных, поскольку файлы ASM являются управляемыми Oracle файлами (OMF). Это уменьшает общий объем административных усилий, требующихся для сопровождения базы данных. В рамках системы хранения ASM для дальнейшего разделения файлов по типам поллеоживается похожий на OFA синтаксис:
Планирование табличных пространств и управление ими
109
□ SQL> select file#, name from v$datafile;
FILE# NAME
1 +DATA1/racO/datafile/system.256.1
2 +DATA1/racO/datafile/undotbs1.258.1
3 +DATA1/racO/datafile/sysaux.257.1
4 +DATA1/racO/datafile/users.259.1
5 WATA1/racO/datafile/example.269.1
6 +DATA2/racO/datafile/users3.256.1
6 rows selected.
SQL> select name from v$controlfile;
NAME
+DATA1/racO/controlfile/current.261.3 +DATA1/racO/controlfile/ current.260.3 2 rows selected.
SQL> select member from v$logfile;
MEMBER
+DATA1/racO/onlinelog/group_3.266.1
+DATA1/racO/onlinelog/group_3.267.1
+DATA1/racO/onlinelog/group_2.264.1
+DATA1/racO/onlinelog/group_2.265.1
+DATA1/racO/onlinelog/group_1.262.1
+DATA1/racO/onlinelog/group_1.263.1
6 rows selected.
В дисковых группах +DATA1 и +DATA2 видно, что для каждого типа файлов базы данных, например у файлов данных, управляющих и журнальных файлов, есть собственный каталог. Полностью квалифицированнее имена файлов ASM имеют следующий формат:
+<группа>/<имя_базы_данных>/<тип_файла><тэг_файла>.<файл>.<инкарнация>
где <группа> — это имя группы дисков, <имя_базы_данных> — это имя базы данных, которой принадлежит файл, <тип_файла> — это тип файла Oracle, <тэг__файла> — это информация, специфичная для файлов этого типа, а пара <файл>.<инкарнация> гарантирует уникальность имени в каждой группе дисков.
Технология ASM рассматривается в главе 6.
Табличные пространства инсталляции Oracle
В таблице 3.2 перечислены все табличные пространства, создаваемые в процессе стандартной инсталляции Oracle с использованием универсального инсталлятора Oracle (OUI).
110
Г.лава 3
Таблица 3.2. Табличные пространства для стандартной инсталляции Oracle
Табличное пространство Тип Управление пространством в сегментах Выделенный первоначально размер (Мбайт)
SYSTEM Постоянное Авто (Auto) 450
SYSAUX Постоянное Авто 350
TEMP Временное Ручное (Manual) 20
UND0TBS1 Постоянное Ручное 30
USERS Постоянное Авто 5
EXAMPLE Постоянное Авто 150
SYSTEM
В табличном пространстве SYSTEM никогда не должно храниться никаких сегментов пользователей. Новая фраза default tablespace команды create database помогает избежать этого за счет автоматического назначения постоянного табличного пространства всем пользователям, которым табличные пространства не были назначены явно. При выполнении инсталляции Oracle с помощью OUI всем пользователям в качестве постоянного табличного пространства по умолчанию автоматически назначается табличное пространство USERS.
Табличное пространство SYSTEM будет расти тем быстрее, чем больше у вас становится процедурных объектов типа функций, процедур, триггеров и тому подобного, так как такие объекты должны размещаться в словаре данных. То же самое относится и к абстрактным типам данных и объектно-ориентированным возможностям Oracle.
SYSAUX
Как и в случае табличного пространства SYSTEM, в табличном пространстве SYSAUX никогда не должны храниться никакие сегменты пользователей. Если один конкретный «оккупант» табличного пространства SYSAUX начинает занимать в нем слишком много места или существенно влиять на производительность других приложений, использующих табличное пространство SYSAUX, необходимо рассмотреть вопрос о его перемещении в другое табличное пространство.
TEMP
Вместо наличия большого временного табличного пространства стоит рассмотреть вопрос о создании нескольких меньших по размеру временных табличных пространств и о создании группы временных табличных пространств, в которой все они.будут содержаться. В результате для приложения, создающего много сеансов с одним и тем же именем пользователя, может сократиться время отклика
UND0TBS1
Даже когда в базе данных есть более одного табличного пространства отката, в каждый момент времени только одно из них может быть активным. Если для пространства отката потребуется больше дисковой памя
Планирование табличных пространств и управление ими
111
ти, а опция AUTOEXTEND (авторасширение) не была активизирована, можно добавить еще один файл данных. В средах Real Application Clusters (RAC) должно быть по одному пространству отката для каждого узла кластера, поскольку каждый узел управляет своим пространством отката самостоятельно.
USERS
Табличное пространство USERS предназначено для различных сегментов, создаваемых каждым пользователем базы данных, по причине чего оно не годится для использования в промышленно эксплуатируемых базах данных и приложениях. Для каждого приложения и типа сегментов должно создаваться отдельное табличное пространство; ниже в данной главе будут представлены дополнительные критерии, которые можно использовать для принятия решения, когда следует разделять сегменты по отдельным табличным пространствам.
EXAMPLE
В промышленно эксплуатируемых средах табличное пространство EXAMPLE должно быть удалено; оно занимает до 150 Мбайт дискового пространства и содержит примеры всех типов сегментов и структур данных Oracle. Для целей обучения следует создать отдельную базу данных с этими примерами и схемами; для существующей базы данных демонстрационные схемы можно включить, используя для этого сценарии из каталога $ORACLE_HOME/ demo /schema.
Разделение сегментов
В соответствии с общим эмпирическим правилом желательно разносить сегменты по различным табличным пространствам на основании их типа, размера и частоты обращения к ним. Каждое из этих табличных пространств выиграет от того, что оно окажется в своей дисковой группе или на своем диске; однако, на практике у большинства организаций не хватает ресурсов, чтобы хранить каждое табличное пространство на собственном устройстве. Приведенный ниже маркированный список иллюстрирует условия, которые можно использовать для определения, как сегменты должны быть разделены между табличными пространствами. Среда автоматического управления хранением данных (ASM) устраняет многие из перечисленных в этом списка вопросов, связанных с конкуренцией, не требуя никаких дополнительных усилий со стороны администратора (Подробнее о ASM см. главу 4).
Большие и малые сегменты должны попадать в разные табличные пространства.
Сегменты таблицы и соответствующие им индексные сегменты должны попадать в разные табличные пространства.
Для каждого приложения должно использоваться отдельное табличное пространство.
Редко используемые сегменты должны быть отделены от часто используемых.
112
Гпава 3
Статические (редко изменяемые. — Прим, пер.) сегменты должны быть отделены от сегментов с высокой интенсивностью операций DML.
Табличные пространства только для чтения должны находиться в собственных табличных пространствах.
Промежуточные таблицы для хранилища данных должны находиться в собственном табличном пространстве.
Табличные пространства должны создаваться с подходящим размером блока, в зависимости от того, обращаются ли к сегментам строка за строкой, или осуществляется полное сканирование таблицы.
Материализованные представления и базовая таблица должны храниться в различных табличных пространствах.
Каждый раздел секционированных таблиц и индексов должен храниться в собственном табличном пространстве.
Используя ЕМ Database Control, можно идентифицировать общую конкуренцию за любое табличное пространство путем идентификации «горячих точек» либо на файловом уровне, либо на уровне объектов. Находясь на домашней странице, нужно щелкнуть на вкладке Performance (производительность) и выбрать на диаграмме Sessions (сеансы) User I/О (пользовательский ввод/вывод), как показано на рис. 3.6.
На рис. 3.7 мы передвинули бегунок к тому периоду времени, в котором, как кажется, содержится большое количество ожиданий; на рис. 3.8
Рис. 3.6. Страница Performance интерфейса ЕМ Database Control
Планирование табличных пространств и управление ими
113
Рис. 3.7. Интерфейс ЕМ Database Control: ожидания активных сеансов
Рис. 3.8. Интерфейс Е ' Database Control: обзор главных ожиданий
114
Гпава 3
Рис. 3.9. Интерфейс ЕМ Database Control: наиболее «ожидаемые» файлы
мы спустились вниз и выбрали вкладку Top Files (главные файлы), где проводится анализ, изображенный на рис. 3.9.
Во время анализа обнаруживается, что двумя файлами, показавшими наивысшую степень конкуренции, являются файлы данных табличных пространств SYSTEM и SYSAUX. Хотя снижение конкуренции за табличное пространство SYSTEM может оказаться очень непростым делом, особенно если уже проведены такие мероприятия, как создание всех новых табличных пространств с локальным управлением дисковым пространством, можно попытаться поправить дело с табличным пространством SYSAUX, переместив приложения, которые интенсивно используют SYSAUX, в собственные табличные пространства. Например, если эта база данных используется в качестве репозитория для каталога восстановления утилиты RMAN для всех остальных баз данных, можно рассмотреть вопрос о переносе метаданных RMAN из SYSAUX.
j-АВя 4
ФИЗИЧЕСКАЯ КОМПОНОВКА
БАЗЫ ДАННЫХ
И УПРАВЛЕНИЕ ХРАНЕНИЕМ
Весь излагаемый в данной главе материал построен на предположении, что используются локально управляемые табличные пространства с автоматическим управлением пространством в сегментах. В дополнение к снижению нагрузки на табличное пространство SYSTEM за счет использования битовых карт, хранящихся в самом табличном пространстве вместо списков свободной памяти, хранящихся в блоке заголовка таблицы или индекса, автоматическое управление пространством в сегментах (с автоматическим или унифицированным выделением сегментов) делает более эффективным использование пространства (памяти) в табличном пространстве. Начиная с Oracle 10g, табличное пространство SYSTEM создается как локально управляемое. Отсюда вытекает требование: все табличные пространства для чтения-записи также должны быть локально управляемыми.
Традиционное хранение дисковой памяти
Вместо того чтобы использовать диспетчеры логических дисков или ASM Oracle (о которых речь будет идти ниже в данной главе), необходимо иметь возможность управлять физическими файлами данных базы данных, чтобы гарантировать ей высокий уровень производительности, доступности и восстанавливаемости. Вообще говоря, это подразумевает распределение файлов данных по различным устройствам (дискам). В дополнение к повышению доступности системы за счет зеркалирования (создания зеркальных копий) файлов журналов базы данных и управляющих файлов на разных дисках, производительность ввода/вывода улучшается в связи с тем, что пользователи начинают получать доступ к таблицам, помещенным в табличные пространства на нескольких физических дисковых устройствах, а не на одном физическом диске. Идентификация узких мест ввода/вывода или дефицита памяти на конкретном дисковом
116
Гпава 4
томе — это только половина дела; после того как узкое место обнаружено, необходимо иметь в своем распоряжении инструменты и знания для того, чтобы перенести эти файлы данных на другие диски. Обычной задачей АБД является изменение размера файла, когда файл занимает слишком большой объем памяти либо ему не хватает памяти.
Изменение размеров табличных пространств и файлов данных
В идеальной базе данных все табличные пространства и созданные в них объекты создаются с идеальными размерами. Превентивное изменение размера табличного пространства или создание автоматически расширяющегося табличного пространства могут потенциально помочь избежать падения производительности (performance hit) при расширении табличного пространства и при аварийном-завершении приложения, если файл(ы) данных внутри табличного пространства невозможно расширить (подробнее о мониторинге использования пространства см. главу 6).
Процедуры и методы, доступные для изменения табличного пространства, слегка различаются в зависимости от того, является ли изменяемое табличное пространство пространством с небольшими или большими файлами. Табличное пространство с небольшими файлами является единственным типом табличных пространств, существовавших до появления Oracle 10g; в нем может содержаться несколько файлов данных. Табличное пространство с большими файлами может состоять только из одного файла данных, но этот файл данных может иметь значительно большие размеры, чем в табличном пространстве с небольшими файлами: в табличном пространстве с большими файлами и размером блока 64 Кбайт может храниться файл размером до 128 Тбайт. Кроме того, табличные пространства с большими файлами могут быть только локально управляемыми.
Изменение размера табличного пространства с небольшими файлами с использованием команды ALTER DATABASE
В следующих примерах делается попытка изменить размер табличного пространства USERS, которое содержит один файл данных с начальным размером 5 Мбайт. Сначала мы увеличим его размер до 15 Мбайт, а затем, поняв, что это слишком много, уменьшим размер табличного пространства до 10 Мбайт. Затем мы попытаемся урезать его слишком сильно.
О SQL> alter database
2 datafile */u01/app/oracle/oradata/rmanrep/users01.dbf’ resize 15m; Database altered.
SQL> alter database
2 datafile */u01/app/oracle/oradata/rmanrep/users01.dbf’ resize 10m; Database altered.
SQL> alter database
2 datafile '/u01/app/oracle/oradata/rmanrep/users01.dbf' resize 1m; alter database
ERROR at line 1:
0RA-03297: file contains used data beyond requested RESIZE val e (Ошибка в строке 1:
физическая компоновка базы данных и управление хранением
117
0RA-03297: файл содержит используемые данные за пределами запрошенного значения RESIZE) SQL> alter database
2 datafile ‘/uOI/app/oracle/oradata/rmanrep/usersOI.dbf’ resize lOOt; alter database *
ERROR at line 1:
0RA-00740: datafile size of (13421772800) blocks exceeds maximum file size
(Ошибка в строке 1:
0RA-00740: размер файла (13421772800 блоков) превосходит максимальный размер файла)
SQL> alter database
2 datafile '/u01/app/oracle/oradata/rmanrep/users01.dbf’ resize 50g; alter database ★
ERROR at line 1:
0RA-01144: File size (6553600 blocks) exceeds maximum of 4194303 blocks
(Ошибка в строке 1:
0RA-01144: размер файла (6553600 блоков) превосходит максимальный размер (4194303 блока)
Если запрос на изменение размера не может быть поддержан достаточным количеством доступного дискового пространства или фактический размер файла превышает запрашиваемый уменьшенный размер, или будет превышен разрешенный размер файла Oracle, будет возвращено сообщение об ошибке.
Чтобы избежать ситуации «реактивного» ручного изменения размеров табличного пространства, можно быть «проактивным» (упреждать события — реагировать на возможное событие еще до того, как оно произошло. — Прим, пер.) и при создании или модификации файла данных использовать фразы autoextend, next и maxsize. В таблице 4.1 перечислены связанные с хранением фразы для модификации или создания файлов данных в командах alter datafile и alter tablespace.
В следующем примере autoextend будет установлен на ON (вкл.) для файла данных /и01/арр/oracle/oradata/rmanrep/userOl.dbf и указано, что каждое расширение файла равно 20 Мбайт и что общий размер файла не должен превышать 1 Гбайт:
О SQL> alter database
2 datafile ‘/u01/app/oracle/oradata/rmanrep/users01.dbf’
3 autoextend on
4 next 20m
5 maxsize 1g;
Database altered.
Если на дисковом томе, содержащем файл данных, недостаточно свободного места для расширения файла данных, нужно либо перенести этот файл на другой дисковый том, либо создать для этого табличного пространства еще один файл данных на другом дисковом томе. В этом примере мы собираемся добавить в табличное пространство USERS еще один файл данных на другом дисковом томе с начальным размером эО Мбайт и позволить ему автоматически расширяться, добавляя к файлу при каждом расширении по 10 Мбайт, а максимальный размер файла ограничить 200 Мбайт:
118
Гпава 4
□ SQL> alter tablespace users
2 add datafile ‘/u03/oradata/users02.dbf’
3 size 50m
4 autoextend on
5 next 10m
6 maxsize 200m;
Tablespace altered.
Следует обратить внимание на разницу в операциях: при модификации существующего файла данных в табличном пространстве используется команда alter database, а при добавлении к табличному пространству нового файла — команда alter tablespace. Применение табличных пространств с большими файлами упрощает эти типы операций.
Таблица 4.1. Фразы расширения файлов данных
Фраза Описание
autoextend Когда эта фраза установлена на 0N, файлу данных разрешено расширяться.
next <размер> Размер в байтах каждой следующей порции дискового пространства, выделяемой для файла данных, если необходимо его расширить; значение <размер> может быть уточнено (квалифицировано) одной из букв К, М, G или Т, что будет служить указанием на единицы измерения размера: килобайты, мегабайты, гигабайты или терабайты соот-
maxsize <размер> ветственно. Если в этой фразе специфицировано значение unlimited, размер файла в среде Oracle не лимитирован вплоть до максимального размера 8 экзабайт (в противном случае размер файла ограничивается файловой системой, содержащей этот файл). В противном случае maxsize устанавливается равным максимальному количеству байтов в файле данных. При этом используются те же самые квалификаторы, что и для фразы next: К, М, G или Т.
Изменение размера табличного пространства с небольшими файлами с использованием ЕМ Database Control
Используя ЕМ Database Control, можно применять любой из методов, описанных в предыдущем разделе: увеличить размер и включить опцию авторасширения для единственного файла данных табличного пространства либо добавить второй файл данных.
Изменение размера файла данных в табличном пространстве с небольшими файлами
Для изменения размера файла данных в интерфейсе ЕМ Database Control нужно щелкнуть на вкладке Administration, находясь на домашней странице базы данных, а затем — на Tablespaces под заголовком Storage. На рис. 4.1 выбрано табличное пространство EXAMPLE. Вместо того, чтобы позволить файлам данных табличного пространства авторасширяться, мы изменим размер файла со 150 Мбайт до 200 Мбайт.
Если щелкнуть на кнопке Edit (редактирование), можно увидеть характеристики табличного пространства EXAMPLE (см. рис. 4.2). Оно яв-
физическая компоновка базы данных и управление хранением
119
Г..............................................” *'*'*’"'....................................... г-.... — —..........ж-.,,...,.....------------------------— — .. . .....
%Огм> Fnutrprfae Manager (SVSMAN) hityrret Ixphtr/_______________________________________________________________
Ffe Edt View Favorites Totfs Help
: 0S«* ' © ' 4 IS Й pS««b Й ' Q ii Л
:: g]http//l?2 166 Z !66:55CC/em/ccmcle/^dbMe/ddtaba$e<^}ecl55earch^ever4«^ed6plav^ype*TA&XS₽ACE&tarQe<»£rd V? &j£c
zzjtf4^4xzzMtSzzz*>z>>vvw*zzjzz>v~zvX*z»zvrVz~v»^'*-za»'>'z^.xk^vz.<-zzvzvvvAzv^v^v>vzzvzA* >x.z»zCv»<-rv.
Of^ACLH" Enterprise Manager Wg tMg УмйМ
Cnutjr
a&.
> Tablespaces Lsaoey t. As S¥&MAhi f
I Tablespaces
Search
• •.» s. .“••••••• * • • •••••••• •* • . . • • Q • iff
* ...«л. > • *. . -•• *M> _•*'**
Name 4Co)
l.v -** >.. W,*V WVi.lv. '* A*A«»ZA. V. Av, ,1 ,, .. mill. .
To I'.m sn ex Kt rr’Mch search or ta run я о?* auote in* H&ch txrt^si ir*? v»ifca?d (v«? > n«bos ttii я ио^гЬ?
quoted ^fing
Results
<9: < / ' • • ' • ' •' ' • • • • Create)
Ecm ) view , : «< - • . 4rpj^/ fi.oin >t Delete)ACtlons Add Datafile . '***^»*****»*«F^ . -• r^r -,VAJ.V.1a‘.VA-'VVi»iV, лу-г-а- v *. , Л’ Ыг
<-< Svkd 1Ш i« ;-. <ч ;>-• '' ;:f\5vX lat Ек»еп! MAn.igamtnf e \ / I Sejntvm I Maua t/*; № e u фл -tfuv ^17 U e 1 • • ж Uu-t! * \ '• • •• >• ••^ ‘ T ; ‘ :
.0 О ipx 1 PERMANENT LOCAL AUTO ONLINE 150 OCO 80 625ШЙЙИЙ» PERMANENT LOCAL AUTO ONLINE 5 COO 1861 53JJ
0 |£д_2 PERMANENT LOCAL AUTO ONLINE 5 COO 5881 1ZS
О IPX.J PERMANENT LOCAL AUTO ONLINE 5 0G0 188 > •UH Hr
О ЮХ * PERMAMENT LOCAL AUTO ONUNE 5 000 188S 1Z5 V
b~2 166 SS(Xi/^corb^fdarab3j:e/datdOdgeQb;ec^ySearch?event»fed5pl3yBbPtype*"rA8L£SPAC£^ Internet
Рис. 4.1. Использование EM Database Control для редактирования табличного пространства
Рис. 4.2. Характеристики табличного пространства
120
Глава 4
рг^и^яЙУ>УЙ fayfoggr jjtbteKpape; £ХАЦМ»Т?И IHladfe Mig^aft Internet Explorer
Ffc Edit View twites Tod* Heb
f ' A
Search Favcrtes
• Г "'/*” ’* '***'** •'*' V~ '•-* • ................. .....................;.;..v -,..**•• *-•-» X£X*|
Ad<^?” gjhttp;//l92 16S.2 l66:$SOC/enVconw>^/6atafca$e/$tcfd9eAable^Ace?tar9et*Ofd.wo!k^zpe»oracle_ddtabap:F<or^ne*E<A v <»
- - - > H- --n"--- - *<^r'ittjtjv--'-'-“i j. j^.jit «лд- »it «пгл/ч ititi и: и -j-»-»* ] n ttt :n,ri>titc il~i 1~-1. - ii'tl -^-z-.s... .. л..-(1, ... ,:,_ - . - , _ _*, —y.»> ..-.г.ч :.•->—♦ «»< to »«»
ОПАСЕН Enterprise Manatpr 1lJ<j I»3tar>4ss C.ehfrot
s**y’ ^нмииж ай Uas*t j
рэГаЬ»^* ^|
1л
Vf.l * > Edit Tablespace EXAMPLE: Edit Datafile
Edit Tablespace: EXAMPLE: Edit Datafile
Loosed in
ЛА
♦ Fie Name exampleOl dbl
* File Directory /u09/oradaia/ord/' Tablespace EXAMPLE
Status ® Online О Offline
MB vj
File Sue 200
Storage
Ej Automatically extend datafile when full (AUTOEXTEND)
Increment 5120 KB У<
\
Maximum File Size OUnlimited
<*/Veluej32767 |mB
u*’
^Cancel) i Continue) ^Internet ,
л
<
Рис. 4.3. Редактирование табличного пространства
ляется локально управляемым, постоянным табличным пространством с небольшими файлами. В нижней части таблицы изображен единственный файл данных этого табличного пространства (EXAMPLE) — / u09/oradata/ ord/exampleOl.dbf.
Выбрав этот (единственный) файл данных табличного пространства EXAMPLE, нужно щелкнуть на кнопке Edit или непосредственно на имени файла; после этого появится экран Edit Tablespace (редактирование табличного пространства) — страница Edit Datafile (редактирование файла данных), изображенная на рис. 4.3. Находясь на этой странице, можно будет изменить размер файла данных. Итак, измените размер файла данных со 150 Мбайт до 200 Мбайт и щелкните на кнопке Continue (продолжить).
На рис. 4.4 можно вернуться назад к странице Edit Tablespace. В этот момент можно подтвердить изменения в файле данных, щелкнув на кнопке Apply (применить), отменить эти изменения, щелкнув на кнопке Revert (возвратить), или показать подлежащий выполнению оператор SQL, щелкнув па кнопке Show SQL.
Прежде чем зафиксировать изменения, часто бывает полезно проверить подлежащие выполнению команды SQL, щелкнув на кнопке Show SQL — это хороший способ освежить свои познания в синтаксисе SQL. Ниже приводится команда, которая будет выполнена, если будет нажата кнопка Apply:
П ALTER DATABASE
DATAFILE ‘/u09/oradata/ord/example01.dbf RESIZE 200M;
физическая компоновка базы данных и управление хранением
121
Рис. 4.4. Подтверждение изменений файла данных
После щелчка на кнопке Apply изменения будут внесены в файл данных. Страница Edit Tablespace: EXAMPLE отражает успешное выполнение операции и новый размер файла данных (см. рис. 4.5).
Добавление файла данных к табличному пространству с небольшими файлами
При использовании ЕМ Database Control добавление файла данных к табличному пространству с небольшими файлами столь же просто, как и изменение размера файла данных. В предыдущем примере был расширен файл данных для табличного пространства EXAMPLE до 200 Мбайт. Так как файловая система (/и09), содержащая файл данных для табличного пространства EXAMPLE, заполнена до предела, необходимо отключить опцию AUTOEXTEND для существующего файла данных, а затем создать новый файл данных в другой файловой системе. На рис. 4.6 опция AUTOEXTEND для имеющегося файла данных отключена путем снятия отметки в окошке метки в секции Storage (хранение). Ниже приводится команда SQL, выполняемая для этой операции при нажатии на Continue, а затем на Apply:
О ALTER DATABASE
DATAFILE 1/u09/oradata/ord/example01. dbf ’
AUTOEXTEND OFF;
122
Г.пава 4
Рис. 4.5. Результаты изменения размера файла данных
Рис. 4.6. Edit Tablespace: редактирование характеристик табличного
пространства EXAMPLE
физическая компоновка базы данных и управление хранением
123
Рис. 4.7. Edit Tablespace: редактирование характеристик табличного пространства EXAMPLE
Следующий шаг на вкладке General (общая) экрана Edit Tablespace состоит в том, чтобы прокрутить экран вниз до секции Datafiles и щелкнуть на кнопке Add, чтобы добавить второй файл данных.
На странице Edit Tablespace: Add Datafile на рис. 4.8 указывается имя файла и место нахождения каталога с новым файлом данных. Поскольку известно, что в файловой системе /и06 имеется, по крайней мере, 100 Мбайт свободного пространства, в качестве каталога указывается /и06/oradata и example02.dbf в качестве имени файла, хотя имя файла само по себе не должно включать имени табличного пространства. Кроме этого, размер файла устанавливается равным 100 Мбайт, и не нужно делать отметок в окошке метки для AUTOEXTEND.
После того как будут последовательно нажаты кнопки Continue и Apply, будет показано сообщение об обновлении (Update Message) и новый размер файлов данных табличного пространства EXAMPLE (см. рис. 4.9).
Удаление файла данных из табличного пространства
В предыдущих версиях Oracle удаление файла данных из табличного пространства было весьма проблематично; не было одной команды, которую можно было бы задать, чтобы удалить не требующийся файл данных, если только вы не хотели удалить разом все табличное пространство. Вместо этого имелись три альтернативы:
Оставить этот файл данных в покое
Сжать его и отключить опцию AUTOEXTEND
124
Гпава 4
ЬА*. ^Жйййг?.
J| Oracle Enterprise. Мэпадег ,EdH Tables pare: EXAMtHE: AdtfUataHle Miurusah Internet Fxptorrr
He £d< View voices Took Help
; J Вас* ’ ^-Search Favorites Media
A&i*&< http://192.160.2.166.Б500/ет/соп$а»е/с1аГ<й>а5е/^огадеДЫ>е$рйсе^дг9е1:»огд./кх^уре«огдс1е_(1^аЬа5е8лпдтевЕХА v
O-'vAQ.L Enterprise Manager 10y n«Ut>^sc Conn©!
гг
LnuKfcd in
Pfiiiafom qpl/wyltf > * Edit Tablespace. EXAMPLE Add Datafile
Edit Tablespace: EXAMPLE: Add Datafile
^Cancel) . ConnrueJ
» File Name exampleCC dbf ••.%-. •• . — •- ... . .. .. 4 «vs
* File Directory 7u06/o<adata/
Tablespace EXAMPLE
File Size JOOT ПЙИв О Refee Existing File
U;
Storage
OAutomaticaHy extend datafile when full (AUTOEXTEND)
Increment
KB v
3
Maximum File Size G Unlimited G Value
—,SC
MB ^..
~.,.Лда
$ Internet
Рис. 4.8. Edit Tablespace: EXAMPLE - добавление файла данных
Рис. 4.9. Табличное пространство после добавления файла данных
физическая компоновка базы данных и управление хранением
125
Создать новое табличное пространство, перенести в него все требующиеся объекты, а затем удалить исходное (старое) табличное пространство.
Хотя создание нового табличного пространства является наиболее удобным решением с точки зрения сопровождения и метаданных, выполнение всех требующихся для подобного решения шагов подвержено ошибкам и требует значительного времени простоя изменяемого табличного пространства, что отрицательно влияет на доступность базы данных.
Используя ЕМ Database Control, можно удалить файл данных с минимальным временем простоя, причем сценарии удаления будут сгенерированы самой ЕМ Database Control. Возвращаясь к предыдущему примеру, где было расширено табличное пространство EXAMPLE путем добавления в него файла данных, мы шаг за шагом пройдем по аналогичному примеру, показывающему, как можно удалить файл данных путем реорганизации табличного пространства. На странице Tablespace нужно сначала выбрать табличное пространство, которое нужно реорганизовать, а потом в поле вода с раскрывающимся списком (drop-down box) Actions — значение Reorganize (реорганизовать); после этого следует щелкнуть на Go (см. рис. 4.10).
На рис. 4.11 показано, как на странице Reorganize Objects (реорганизовать объекты) можно подтвердить, что табличное пространство EXAMPLE будет подвергнуто реорганизации, и щелкнуть на Next (далее).
Как можно понять из рис. 4.12, следующая страница является тем местом, где можно задать некоторые параметры реорганизации, например,
Рис. 4.10. Табличное пространство: реорганизовать
126
Г.пава 4
H^wclc CntcrprtoUanagi.r Heor«ariU« Objects. Ubjeds Mf'.m&ft Internet fxphrcr
Fie Ed* Vew Favo’tes Tods Help
Search Favorses
*- i Htp://1^2.16$.2.16fc:SSOO/erriiCcnsoh!/dAtdt>a5e/rewg/rsc*9?e,»ent«»l»jnch&«wne-6XAf-1₽tESJtype«recr50bject^3if ancebRl«».'efn/a '
гш^<е
в
QFLACX.E tnie*prise Manager №<? fjStaha$e Conhvji
':i'.
УЙ
Reorganize Objects: Object
Database ofd.woihl
Logged In As SYSMAN
4 Cancel 4Back j S*ap 2 o. G -Next
Select the tablespace to be reo garnzed
.... ......................
t Ihtmo jlvp»? |f t гл M u-.otp tniutt
' |$C;}iugni Mana ttr eta
PERMANENT
LOCAL
AUTO
X* WAW/«*U’*«*<’?»yAWzr Л ._
Set Attributes JL
?f 6 j Nexf)
Database | &L& | I blip I
Copyright Ф1996» 20CM, Orecie. AH rights reserved
si£) http;//l92.l6S 2 166 550D/em/con4de/ditabase-reorg/rea'g>eve'iit«launc.,-i6crame«=EXAMPLEeiftype«recwgOb)ectj
*£) Incerwt
Рис. 4.11. Реорганизация объектов: объекты
Рис. 4.12. Реорганизация объектов: опции
физическая компоновка базы данных и управление хранением
127
Рис. 4.13. Обработка: генерация сценария реорганизации
что является более важным для реорганизации: ее скорость или доступность табличного пространства. В дополнение можно воспользоваться опцией переименования табличного пространства, вместо того чтобы использовать в качестве рабочей области рабочее табличное пространство, что может привести к потенциальной экономии дискового пространства или времени, необходимого для реорганизации. Среди других параметров на этой странице можно назвать специфицирование параллельного выполнения, перестройку индексов (без журнализации) и уровень сбора статистических данных, требуемый после завершения реорганизации.
На рис. 4.13 показан статус создания сценария. Требующееся на генерацию сценария время приблизительно пропорционально числу объектов в табличном пространстве.
После этого будет показан итоговый экран со всеми предупреждениями и ошибками, выявившимися в процессе генерации сценария (см. рис. 4.14).
После нажатия кнопки Next будет показана страница Schedule (планирование), изображенная на рис. 4.15. В этом сценарии, для того чтобы двигаться далее, необходимо определить верительные данные хоста (host credentials) для сервера, но задание не будет запущено (в пакетную обработку) до окончания работы мастера, так как нам необходимо внести в сценарий одно редакционное изменение.
Щелкнув на Next, мы попадаем на страницу Review (просмотр) (см. рис. 4.16). В текстовом окне будут приведены выдержки из сгенерированного сценария. Вместо передачи задания в пакетную обработку здесь следует щелкнуть на кнопке Save Full Script (сохранить полный сце-
128
Глава 4
Рис. 4.14. Реорганизация объектов: отчет о влиянии
Рис. 4.15. Реорганизация объектов: планирование
физическая компоновка базы данных и управление хранением
129
3b Oracle Manager* ftaxgenire Object». ftarirw • Internet Explorer J.
Fie £(K vie** Favour* Took Kelp ?>
y. 3wrch Fevtrt?s П1Й :i
•' •* •iflhttPj/l9<.^68-2.168wcrd^ype^<*^de^tAb<^ftonanx>-rXAM>tE v
Of^ACLjS'tnterptise Mandtjet 10'/ j*g;
ГОл>..'.. .'. . .. . ......' ..._ ...... ''. .- _ • Л . .,
Reorganize Objects Review
Dstaoase iHhiiirep.woilci Tablespace EXAMPLE
Logged In As RJB
Job Name REORGAN1ZE-RMANREP«WORLD_15 Job Schedule Run Immediately
£canceQ t Back 13}e« 6 Submit jotQ
Script
The jcnpt summary is a list of the database commands ihal will be used to reorganize the selected objects. Save Pull Script j The full scrip! is a PL/SQL senpx that includes functions. procedures, and other commands needed dur nc the reorganization The till script will be created when you submit the job and will be executed by the job to perform the reorganization
View Ф Script Summary C Full Scrip!
’* Taiger database: rmanrep world <3
— Script generated at: OMUL-2004 00 19
CREATE SMALLFILE TABLESPACE ’EXAMPLE REORGO’ DATAFILE 7uO2<oradalaZexample34= reorgD dbf SIZE 2CCM
REUSE . 7u05/orad3t^exomple02 reorgO cbf SIZE 100M REUSE LOGGING EXTENT MANAGEMENT LOCAL :SEGMENT SPACE MANAGEMENT AUTO
jEcGINDBMS SERVER ALERT SET THRESHOLD(9000,NULL.WLL,NULLNULL.1,1.NIJLL.5.EXAK1PLE REORGO).
•END
Walter table -sys* ’employees- move tablespace -example reorgo’
ALTER TABLE -SYS-.-DEPARTMEKTS' MOVE TABlESPACE ’EXAMPLE_REORG0‘
ALTEP TABLE ’SYS' 'COUNTRES* MOVE TABLESPACE ',EXAMPLE_REOPG0*
jmgml$reo?g dropTbspf’EXAMPLE*')
ALTER TABLESPACE 'EXAMPLE REORGO’ RENAME TO ’EXAMPLE*
r fl
Cone Ю Internet
h£. ....... ,, , —..............-____________________— Mil „ - > ........----------------------
Рис. 4.16. Реорганизация объектов: просмотр
нарий), чтобы перед запуском задания внести в сценарий одно незначительное изменение.
На рис. 4.17 можно указать место, в котором требуется сохранить сценарий.
Перед началом редактирования полного сценария нужно нацелить команду execute immediate на тот каталог, в котором было создано табличное пространство:
□ EXECUTE IMMEDIATE 'CREATE SMALLFILE TABLESPACE «EXAMPLE_REORGO" DATAFILE 7u02/oradata/example01_reorg0.dbf’ SIZE 200M REUSE, “ /u06/oradata/example02_reorg0.dbf ‘ ‘ SIZE 100M REUSE LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO’;
Поскольку мы хотим удалить файл данных, нужно удалить выделенную полужирным шрифтом строку сценария, а затем либо изменить место нахождения второго файла данных, либо заново создать первый файл данных с большим размером. В этом примере нужно не только создать новое табличное пространство с большим размером, но и поместить его на другой дисковый том:
О EXECUTE IMMEDIATE ‘CREATE SMALLFILE TABLESPACE «EXAMPLE_REORGO"
DATAFILE ‘’/u04/oradata/exaraple0l.dbf”
SIZE 300M REUSE
LOGGING EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO’;
130
Гпава 4
Рис. 4.17. Просмотр: сохранить полный сценарий
После того как сценарий будет отредактирован, его нужно запустить из SQL*Plus, используя учетную запись с привилегиями АБД. Во многих случаях можно избежать применения сценариев реорганизации, если использовать табличные пространства с большими файлами, потому что они состоят всего из одного файла данных.
Изменение табличного пространства с большими файлами с использованием команды ALTER TABLESPACE
Табличное пространство с большими файлами состоит из одного и только одного файла данных. В данном разделе говорится о том, как может быть изменен размер такого табличного пространства (подробнее о табличных пространствах с большими файлами см. главу 6). Большинство имеющихся в наличии параметров для изменения характеристик файла данных табличного пространства — например его максимального размера или размера его экстентов — теперь являются модифицируемыми на уровне табличного пространства. Начнем с создания табличного пространства с большими файлами и сделаем это следующим образом:
П create bigfile tablespace dmarts
datafile '/u05/oradata/dmarts.dbf’ size 250m
autoextend on next 50m maxsize unlimited extent management local segment space management auto;
физическая компоновка базы данных и управление хранением
131
Операции, которые для табличных пространств с небольшими файлами были доступны только на уровне файлов данных, для табличных пространств с большими файлами могут быть использованы на уровне табличного пространства:
□ SQL> alter tablespace dmarts
2 resize 1000m;
Tablespace altered.
Хотя будет работать и команда alter database, использованная со спецификацией файла данных из табличного пространства DMARTS, преимущества использования синтаксиса alter tablespace очевидны: не нужно знать, где именно хранится файл данных. Как вы, наверное, и подозревали, попытка изменить параметры файла данных на уровне табличного пространства для табличного пространства с небольшими файлами будет запрещена:
□ SQL> alter tablespace users resize 100m;
alter tablespace users resize 100m *
ERROR at dine 1:
ORA-32773: operation not supported for smallfile tablespace USERS (Ошибка в строке:
ORA-32773: операция не поддерживается для табличного пространства USERS с небольшими файлами)
Если табличное пространство с большими файлами оказывается переполненным, потому что его единственный файл данных не может быть расширен на диске, необходимо переместить этот файл данных на другой дисковый том (см. ниже). Использование среды автоматического управления памятью (ASM) может потенциально устранить всякую необходимость в ручном перемещении файлов: вместо перемещения вручную файла данных можно просто добавить еще один диск в группу хранения (storage group) ASM.
Перемещение файлов данных
Для улучшения управления изменением размера файла данных ил д повышения общей производительности ввода/вывода азь жет потребоваться переместить один или несколько фаило табличного пространства в другой адрес. Есть три метода файлов данных: с помощью команд alter database и a ter а е Р с помощью ЕМ Database Control, хотя ЕМ Database Contro и не р ляет все команды, необходимые для перемещения файла данных.
Метод перемещения с помощью alter tablespace применим к ф данных, размещенным во всех табличных пространствах, кроме: SYS 1 и SYSAUX, к табличным пространствам отката или к временным табли ным пространствам. Этот метод работает с файлами ^нных и;. Л табличных пространств, так как во время выполнения переноса файлов экземпляр должен быть остано^^|ц^|^^ ;
132
Гпава 4
Перемещение файлов данных с помощью команды ALTER DATABASE
Процесс перемещения одного или нескольких файлов данных с использованием метода alter database состоит из следующих шагов:
1. Подключение к базе данных как SYSDBA и останов экземпляра.
2. Использование команды операционной системы для перемещения файла(ов) данных.
3. Открытие базы данных в режиме MOUNT.
4. Использование команды alter database для изменения ссылок на файл в базе данных.
5. Открытие базы данных в режиме OPEN.
6. Инкрементальное или полное резервное копирование базы данных, включая управляющие файлы.
В следующем примере будет показано, как перенести первый файл данных табличного пространства USERS на другой дисковый том. Сначала нужно подключиться к базе данных с привилегиями SYSDBA:
□ [oracle@util oracle] $ sqlplus / as sysdba
SQL*Plus: Release 10.1.0.2.0 - Production on Sun Jun 13 20:40:15 2004
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL>
Затем следует использовать запрос к динамическим представлениям производительности V$DATAFILE и V$TABLESPACE для подтверждения имен файлов данных в табличном пространстве USERS:
□ SQL> select d.name from
2 v$datafile d join v$tablespace t using(tsfl)
3 where t.name = ‘USERS’;
NAME
/u01/app/oracle/oradata/rmanrep/users01.dbf
/u03/oradata/users02.dbf
>SQL
Чтобы завершить шаг 1, надо остановить базу данных:
□ SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
физическая компоновка базы данных и управление хранением
133
Для выполнения шага 2 следует остаться в SQL*Plus и использовать символ начала управляющей последовательности «!», чтобы выполнить команды операционной системы для переноса файлов данных:
□ SQL> I mv /u01/app/oracle/oradata/rmanrep/users01.dbf /u02/oradata
На шаге 3 нужно запустить базу данных в режиме MOUNT, так чтобы были доступны только управляющие файлы, но база данных не была открыта:
□ SQL> startup mount
ORACLE instance started.
Total System Global Area Fixed Size Variable Size Database Buffers Redo Buffers Database mounted.
188743680 bytes
778036 bytes
162537676 bytes
25165824 bytes
262144 bytes
На шаге 4 нужно изменить ссылки в имени пути в управляющем файле, чтобы он указывал на новое местоположение файла данных:
□ SQL> alter database rename file
2 ‘/u01/app/oracle/oradata/rmanrep/users01.dbf’ to
3 */u02/oradata/users/01.dbf’;
Database altered.
На шаге 5 следует открыть базу данных, чтобы сделать ее доступной пользователям:
□ SQL> alter database open;
Database altered.
И, наконец, на шаге 6 можно произвести резервное копирование обновленных управляющих файлов:
О SQL> alter database backup controlfile to trace;
Database altered.
SQL>
Для выполнения инкрементального резервного копирования, включающего резервное копирование управляющих файлов, можно использовать RMAN.
Перемещение файлов данных с помощью команды ALTER TABLESPACE
Если файл данных, который необходимо переместить, не является ча-с гью табличного пространства SYSTEM или SYSAUX, активного табличного пространства отката или временного табличного пространства, для переноса табличного пространства предпочтительным становится использование метода alter tablespace. Для этого есть одна основная причина. база данных, за исключением того табличного пространства, файл из которого должен быть перемещен, остается доступной для всех пользователей на время всей операции по переносу.
134
Гпава 4
Ниже приводятся шаги процесса по переносу одного или нескольких файлов данных с помощью команды alter tablespace:
1. Используя учетную запись с привилегией ALTER TABLESPACE, перевести табличное пространство в автономный режим.
2. Для перемещения файла использовать команды операционной системы.
3. Для изменения ссылок на файл данных в базе данных использовать команду alter tablespace.
4. Вернуть табличное пространство в оперативный режим.
Предположим, что в примере с alter database второй файл данных был ошибочно перемещен не в ту файловую систему. В этом примере он будет перемещен из /и02/oradata в /u04/oradata:
□ SQL> alter tablespace users offline;
Tablespace altered.
SQL> ! mv /u02/oradata/users01.dbf /u04/oradata/users01.dbf
SQL> alter tablespace users rename datafile
2 ‘/u02/oradata/users01.dbf’ to ‘/u04/oradata/users01.dbf’;
Tablespace altered.
SQL> alter tablespace users online;
Tablespace altered.
Обратите внимание, насколько этот метод более доступен для понимания и менее разрушителен, чем метод с командой alter database. Единственным временем простоя для табличного пространства является время, требующееся для переноса файла данных с одного дискового тома на другой.
Перемещение файлов данных с помощью ЕМ Database Control
В релизе 1 версии Oracle Database lOgy утилиты ЕМ Database Control отсутствует явная функция для перемещения файлов данных, за исключением выполнения реорганизации табличного пространства (см. выше в данной главе). Но для перемещения файла данных с одного дискового тома на другой — это то же самое, что стрельба из пушек по воробьям. При редактировании файла данных в ЕМ Database Control и простом изменении адреса File Directory Location (место размещения файла), как показано на рис. 4.18, продуцируется следующий сценарий SQL:
□ ALTER DATABASE RENAME FILE
‘/u01/app/oracle/oradata/rmanrep/users01 dbf’ TO
1u02/oradata/users01.dbf’;
К сожалению, такой сценарий не завершится удачей, так как в нем отсутствуют команды для перевода табличного прос р с гва в автономный режим, команды операционной системы для перс оса файла и команда для возврата табличного пространства в оперативный режим.
'физическая компоновка базы данных и управление хранением
135
Рис. 4.18. ЕМ Database Control: редактирование места размещения
файла данных
Перемещение оперативных файлов журналов базы данных
Хотя возможно непрямое перемещение оперативного файла журналов базы данных путем удаления всех групп журналов и последующего их добавления в другом месте на диске, это решение не сможет работать, если есть всего две группы таких файлов, так как невозможно открыть базу данных всего с одной группой этих файлов. Выходом из положения может стать временное открытие третьей группы журналов базы данных с последующим удалением первой или второй группы журналов, если есть необходимость оставить базу данных открытой на время выполнения перемещения. Показанное ниже альтернативное решение состоит в том, чтобы перемещать файлы журналов базы данных при остановленной базе данных.
В следующем примере есть три группы файлов журналов базы данных с двумя членами в каждой. Один член каждой группы размещен на том же томе, что и программное обеспечение Oracle, и их необходимо переместить на другой том для устранения конкуренции между заполнением файлов журналов базы данных и получением доступа к компонентам программного обеспечения Oracle. Метод, который будет при этом использован, очень похож на метод, использовавшийся для перемещения файла Данных с помощью метода alter database.
136
Гпава 4
□ SQL> select group#, member from v$logfile 2 order by group#, member;
GROUP# MEMBER
1 /u01/app/oracle/oradata/rmanrep/redo01.log
1 /u05/oradata/redo01.log
2 /u01/app/oracle/oradata/rmanrep/redo02.log
2 /u05/oradata/redo02.log
3 /u01/app/oracle/oradata/rmanrep/redo03.log
3 /u05/oradata/redo03.log 6 rows selected.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> ! mv /u01/app/oracle/oradata/rmanrep/redo0[1-3].log /u04/oradata
SQL> startup mount
ORACLE instance started.
Total System Global Area 188743680 bytes
Fixed Size 778036 bytes
Variable Size 162537676 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
Database mounted.
SQL> alter database rename file */u01/app/oracle/oradata/rmanrep/redo01.log’ 2 to ‘/u04/oradata/redo01.log’;
Database altered.
SQL> alter database rename file ‘/u01/app/oracle/oradata/rmanrep/redo02.log’ 2 to ‘/u04/oradata/redo02.1og’;
Database altered.
SQL> alter database rename file" ‘/u01/app/oracle/oradata/rmanrep/redo03.log’ 2 to ‘/u04/oradata/redo03.1og’;
Database altered.
SQL> alter database open;
Database altered.
SQL> select group#, member from v$logfile 2 order by group#, member;
физическая компоновка базы данных и управление хранением
137
GROUP# MEMBER
1 /u04/oradata/redo01.log
1 /u05/oradata/redo01.log
2 /u04/oradata/redo02.1og
2 /u05/oradata/redo02.log
3 /u04/oradata/redo03.log
3 /u05/oradata/redo03.log
6 rows selected.
SQL>
Теперь операции ввода/вывода для файлов журналов базы данных больше не вступают в конфликт с операциями ввода/вывода для программного обеспечения Oracle; кроме того, эти файлы мультиплексированы между двумя различными точками монтирования, /и04 и /и05.
Перемещение управляющих файлов
Чтобы переместить управляющий файл, если используется файл параметров инициализации, необходима процедура, аналогичная тем, что использовались для перемещения файлов данных и файлов журналов базы данных: закройте экземпляр, переместите файл командами операционной системы, а затем повторно перезапустите экземпляр.
Однако, если используется файл параметров сервера (SPFILE), процедура становится слегка другой. Параметр CONTROL-FILES из файла параметров инициализации изменяется при помощи команды alter system ... scope=spfile, когда экземпляр либо находится в рабочем состоянии, либо он был остановлен, а потом открыт вновь в режиме NOMOUNT. Поскольку параметр CONTROL_FILES не является динамическим, экземпляр в любом случае должен быть остановлен и запущен вновь.
В данном примере обнаруживается, что в базе данных есть три копии управляющего файла, но они не мультиплексированы на различных томах. Отредактируем SPFILE с новыми местами расположения файлов, остановим экземпляр, чтобы можно было переместить управляющие файлы на новые места на разных дисках, а затем перезапустим экземпляр.
П SQL> select name, value from v$spparameter
2 where name = ‘control files’;
NAME VALUE
control-files /u01/app/oracle/oradata/rmanrep/control01.c
control-files /uOI/app/oracle/oradata/rmanrep/controlOZ.ct
control-files /u01/app/oracle/oradata/rmanrep/control0J.ct
SQL> show parameter control-files
NAME TYPE VALUE
control"files string /u01/app/oracle/oradata/rmanrep/control01.ctl,
/u01/app/oracle/oradata/rmanrep/control02.ctl, /u01/app/oracle/oradata/rmanrep/cont rol03.ctl
138
Гпава 4
SQL> alter system set control-files =
2 1/u02/oradata/control01.ctl’,
3 ‘/u03/oradata/control02.ctl’,
4 ‘ /u04/o radata/cont rol03.ct1’
5 scope = spfile;
System altered.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> I mv /u01/app/oracle/oradata/rmanrep/control01.ctl /u02/oradata
SQL> ! mv /u01/app/oracle/oradata/rmanrep/control02.ctl /u03/oradata
SQL> ! mv /u01/app/oracle/oradata/rmanrep/control03.ctl /u04/oradata
SQL startup
ORACLE instance started.
Total System Global Area 188743680 bytes
Fixed Size 778036 bytes
Variable Size 162537676 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
Database mounted.
Database opened.
SQL> select name, value from v$spparameter 2 where name = ‘control-files’;
NAME VALUE
cont rol-files /u02/oradata/cont rol01.ctl control-files /u03/oradata/control02.ctl cont rol_flies /u04/oradata/cont rol03.ctl
SQL> show parameter control-files
NAME
TYPE
VALUE
cont rol-files st ring
SQL>
/u02/oradata/control01.ctl, /иОЗ/oradata/cont rol02.ctl, /u04/oradata/control03.ctl
Теперь три управляющих файла перенесены в различные файловый системы, они более не находятся на одном томе с программным обеспе^с нием Oracle и образуют более высоко доступную конфигурацию (есЛ# том, содержащий один из управляющих файлов, выходит из строя, двух других томах останутся его актуальные копии;.
физическая компоновка базы данных и управление хранением
139
Среда автоматического управления хранением данных
При создании нового табличного пространства или другой структуры базы данных, например управляющего или файла журнала базы данных, можно в качестве области хранения структуры базы данных указать не файл операционной системы, а дисковую группу. ASM берет простоту использования управляемых Oracle файлов (OMF) и объединяет ее с возможностями зеркалирования (mirroring) и рассредоточения (striping) для обеспечения живучей файловой системы и диспетчера логических томов, которые даже способны поддерживать несколько узлов в архитектуре Oracle Real Application Clusters (RAC). ASM делает ненужной покупку подобного программного обеспечения у третьих фирм.
ASM не только повышает производительность путем автоматического рассредоточения объектов базы данных по большому количеству устройств, но и увеличивает доступность базы данных, так как позволяет добавлять в базу данных новые дисковые устройства, не останавливая ее; ASM автоматически, с минимальным вмешательством в работу производит выравнивание распределения файлов по устройствам.
Архитектура ASM
Для увеличения производительности и надежности ASM делит файлы данных и другие структуры базы данных на экстенты и распределяет эти экстенты по всем дисковым устройствам, входящим в дисковую группу. Вместо зеркалирования всего дискового тома ASM подвергает зеркалированию объекты базы данных для придания зеркалированию гибкости или рассредоточению объектов базы данных способом, наиболее подходящего для их типа. По желанию объекты могут быть не рассредоточены по всем аппаратным дискам, для которых включена поддержка RAID, а стать частью устройств Storage Attached Network (SAN — сеть хранения данных) или устройств Network Attached Storage (NAS - сетевое устройство хранения данных).
Автоматическая регулировка нагрузки является еще одной ключевой характеристикой ASM. Когда требуется увеличение объема дискового пространства, к дисковой группе могут быть добавлены новые дисковые устройства, a ASM перенесет пропорциональное количество файлов с одного или с нескольких имевшихся ранее дисков на новые диски для поддержания общего баланса ввода/вывода для всех имеющихся дисков. Если влияние, оказываемое во время выполнения операций по перенастройке на подсистему ввода /вывода, велико, скорость перенастройки может быть уменьшена за счет применения параметров инициализации.
Для ASM необходим особый экземпляр Oracle, который предназначается для поддержки взаимодействия между традиционным экземпляром Oracle и файловой системой. Компоненты программного обеспечения ASM поставляются вместе с программным обеспечением базы данных Oracle и всегда доступны в тех случаях, когда при создании базы данных Для табличных пространств SYSTEM, SYSAUX и для других табличных пространств был выбран тип хранения ASM.
Однако использование ASM не избавляет от необходимости смешивать дисковые группы ASM с «ручными» методами управления сЪяйпяхлтл
140
Гпава 4
данных, описанными выше. Тем не менее, простота использования и высокая производительность ASM становятся веским доводом в пользу применения ASM для всех потребностей хранения.
Для поддержки экземпляров ASM появились два новых фоновых процесса Oracle: RBAL и ORBn. Процесс RBAL координирует всю дисковую активность для дисковых групп, в то время как ORBn, где п может быть числом от 0 до 9, выполняет фактическое перемещение экстентов между дисками, входящими в дисковую группу.
Для баз данных, использующих ASM, также появились два новых фоновых процесса: OSMB и RBAL. Процесс OSMB осуществляет взаимодействие между базой данных и экземпляром ASM, в то время как RBAL от имени базы данных выполняет открытие и закрытие дисков в составе дисковой группы.
Создание экземпляра ASM
Для ASM требуется выделенный экземпляр Oracle для управления дисковыми группами. Обычно экземпляр ASM требует очень немного места в оперативной памяти — в диапазоне от 60 до 120 Мбайт. При специфицировании ASM как способа хранения файлов данных во время инсталляции программного обеспечения Oracle этот экземпляр конфигурируется автоматически, если к этому моменту экземпляра ASM еще не существовало, как это показано на изображенном на рис. 4.19 экране OUI.
Рис. 4.19. Специфицирование ASM в качестве метода хранения базы данных
физическая компоновка базы данных и управление хранением
141
В качестве примера дисковых устройств, используемых для создания дисковых групп ASM, предположим, что у Linux-сервера есть некоторое число «чистых» (т. е. без файловой системы. — Пргсм. пер.) дисковых устройств с емкостями, указанными в таблице 4.2.
Первая дисковая группа будет конфигурироваться с помощью универсального инсталлятора Oracle (см. рис. 4.20).
Присвоим первой дисковой группе имя DATA1, а для создания обычной избыточности дисковой группы используем /dev/raw/rawl и /dev/raw/raw2. Если для создания желаемого уровня избыточности дисковых групп выбрано недостаточное количество «чистых» дисков, OUI сгенерирует сообщение об ошибке. После создания базы данных будут запущены и обычный экземпляр, и экземпляр ASM.
У экземпляра ASM есть несколько других уникальных характеристик. Хотя у него имеется файл параметров инициализации и файл паролей, у него нет словаря данных, и, следовательно, все подключения к экземпляру ASM должны проводиться только через пользователей SYSTEM и SYS с использованием аутентификации операционной системы. Команды дисковой группы типа create diskgroup, alter diskgroup и drop diskgroup разрешены только для экземпляра ASM. И, наконец, экземпляр ASM может функционировать только в режимах NOMOUNT или MOUNT; он никогда не может быть в режиме OPEN.
Mre Automata Storage Management
*
' 'У''
Configure Automatic Storage Management
ЛЧ1
1 К У
'.\4.
ft t
Specify Disk Croup Characteristics and select p Required Storage Space
Member Disks. Data File Storage:
Recovery Area Storage:
Redundancy:
Existing Free Space in Disk Group
Size of New Disks Selected
Additional Space Needed:
Disk Group Name: r Redundancy
I High '» Normal c External г Add Member Disks —...~—-.3
datal
И 50 MB
+_________MA MB
X 2 (Norm)
0 MB
16378 MB
-14078 MB j
- • • • . ,
,4 «/« . •
Select Disk Path
I? /dev/raw/rawl
P -j /dev/raw/raw2
Size (MB)
8189
8189
• /dev/raw/rawB
? Ed /dev/raw/raw4
8 .. __________
i-
I
к . . ....>» i.rv и ir.im ... . . . амжаяанмммвяампм*я>жааааяячя1имр*йнг ss. k-
Note f you don't see disks which yuu believe should be available, you may need to change the Disk Discovery Path.
I
Help / installed Products... }
Back
Next
Change Disk Discovery Path ’
Cancel
-..... " —"
J ________________
r
r Мф
i
6143
_ 16*143
1
ж
Рис. 4.20. Конфигурирование первоначальной дисковой группы ASM с помощью OUI
142
Г.пава 4
Таблица 4.2. «Чистые» диски для дисковой группы ASM
Имя устройства Емкость
/dev/raw/raw1 8 Гбайт
/dev/raw/raw2 8 Гбайт
/dev/raw/raw3 6 Гбайт
/dev/raw/raw4 6 Гбайт
/dev/raw/raw5 6 Гбайт
/dev/raw/raw6 6 Гбайт
Компоненты экземпляра ASM
К экземплярам ASM нельзя получить доступ, используя многообразие методов, доступных для традиционных баз данных. В этом разделе мы поговорим о привилегиях, позволяющих вам подключиться к базе данных с привилегиями SYSDBA или SYSOPER. Мы также различаем экземпляры ASM по новым и расширенным параметрам инициализации, доступным только для экземпляров ASM. В конце этого раздела мы предложим процедуры для запуска и остановки экземпляра ASM, а также зависимости между экземплярами ASM и теми экземплярами баз данных, которые они обслуживают.
Получение доступа к экземпляру ASM
У экземпляра ASM нет словаря данных, так что доступ к экземпляру ограничен и возможен только для пользователей, которые могут быть аутентифицированы операционной системой, другими словами, которые могут подключаться как SYSDBA или SYSOPER через пользователя операционной системы из группы dba.
Пользователи, подключившиеся к экземпляру ASM как SYSDBA, могут выполнять все операции ASM, например, создание и удаление дисковых групп, а также добавление и удаление дисков из дисковых групп.
У пользователя SYSOPER есть значительно более ограниченный набор команд, доступных для использования с экземпляром ASM. Вообще говоря, команды, доступные для пользователя SYSOPER, дают достаточно привилегий для выполнения рутинных операций для уже сконфигурированного и стабильного экземпляра ASM. Ниже приводится список операций, доступных пользователю SYSOPER:
з Запуск и остановка экземпляра ASM
Монтирование и размонтирование дисковой группы
Изменение статуса диска, входящего в дисковую группу, с ONLINE на OFFLINE, или наоборот
Перенастройка (ребалансировка) дисковой группы
Выполнение проверки целостности дисковой группы
Доступ к динамическим представлениям производительности V$ASM_*
физическая компоновка базы данных и управление хранением
143
Параметры инициализации ASM
Некоторое количество параметров инициализации является либо индивидуальными для конкретных экземпляров ASM, либо имеют в экземпляре ASM новые значения. Для экземпляров ASM настоятельно рекомендуется применять вместо файла параметров инициализации SPFILE (файл параметров сервера). В таком случае при добавлении или удалении дисковой группы будут автоматически поддерживаться параметры типа ASM_ DISKGROUJPS, так что, скорее всего, вам даже не придется вручную изменять их значения.
INSTANCE-TYPE
Для экземпляра ASM параметр INSTANCE-TYPE принимает значение ASM. Значением по умолчанию, используемым для традиционных экземпляров Oracle, является RDBMS.
DB_UNIQUE_NAME
Значение по умолчанию параметра DB_UNIQUE_NAME равно +ASM и является уникальным именем группы экземпляров ASM для кластера или одиночного узла; значение по умолчанию должно быть модифицировано, только если делается попытка эксплуатировать на одном узле несколько экземпляров ASM.
ASM_POWER_LIMIT
Чтобы гарантировать, что операции по перенастройке не оказывают влияния на текущие действия пользователя по вводу/выводу, параметр ASM_POWER_LIMIT управляет тем, как быстро происходят операции по перенастройке. Значения этого параметра лежат в диапазоне от 1 до 11, причем 11 является максимальным возможным значением, а 1 — значением по умолчанию (обеспечивающим низкие накладные расходы для ввода/ вывода). Поскольку этот параметр является динамическим, в рабочее время (в дневные часы) его значение можно изменять на более низкое, а в ночное время, когда можно выделять больше времени па операции по перенастройке дисковых групп, задав для него более высокое значение.
ASM-DISKSTRING
Параметр ASM_DISKSTRING специфицирует одну или несколько строк (в зависимости от операционной системы) для ограничения количества дисковых устройств, которые могут быть использованы для создания дисковых групп. Если это значение есть NULL, потенциальными кандидатами на включение в состав создаваемой дисковой группы являются все видимые ASM дисковые устройства. Для используемого в этой главе примера с тестовым сервером, значение параметра ASM_DISKSTRING равно /dev/raw/*:
SQL> select name, type, value from v$parameter
2 where name = ‘asm_diskstring’;
NAME
TYPE VALUE
asm_diskstring 2 /dev/raw/*
144
Гпава 4
ASM_DISKGROUPS
Параметр ASM JDISKGROUPS специфицирует список, содержащий имена дисковых групп, которые должны быть автоматически смонтированы экземпляром ASM при запуске или командой alter diskgroup all mount. Даже если в момент запуска экземпляра этот список пуст, любые имеющиеся в наличии дисковые группы могут быть смонтированы вручную.
LARGE_POOL_SIZE
Параметр LARGE_POOL_SIZE полезен как для обычных экземпляров, так и для экземпляров ASM; однако для экземпляров ASM этот пул используется по-другому. Из этого пула выполняются внутренние пакеты ASM, так что этот параметр должен быть равен, по меньшей мере, 8 Мбайт.
Запуск и остановка экземпляра ASM
Запуск экземпляра ASM во многом похож на запуск обычного экземпляра, за тем исключением, что значением по умолчанию для команды startup является startup mount. Поскольку для этого экземпляра отсутствуют управляющий файл, база данных или словарь данных, которые можно было бы смонтировать, вместо базы данных монтируются группы дисков ASM. Команда startup nomount запускает экземпляр, но при этом не монтирует никаких дисков ASM. Помимо этого можно указать startup restrict, чтобы временно запретить экземплярам базы данных подключаться к экземпляру ASM для монтирования дисковых групп.
При выполнении команды shutdown для экземпляра ASM, та же самая команда выполняется и для всех экземпляров баз данных, использующих экземпляр ASM; прежде чем экземпляр ASM закончит операцию остановки, он будет ожидать, пока не окажутся остановленными все зависимые базы данных. Единственным исключением из этого правила является использование для экземпляра ASM команды shutdown abort, которая, в конечном счете, вынуждает все зависимые базы данных также выполнить команду shutdown abort.
Когда несколько экземпляров ASM разделяют дисковые группы, как, например, в средах Real Application Clusters (RAC), выход из строя одного экземпляра ASM не вызывает выхода из строя экземпляров базы данных. Напротив, другой экземпляр ASM будет выполнять операции восстановления для вышедшего из строя экземпляра.
Динамические представления производительности ASM
С экземплярами ASM связано несколько новых динамических представлений производительности. В таблице 4.3 перечислены наиболее часто употребляемые динамические представления производительности ASM (подробнее о некоторых представлениях см. ниже в данной главе).
физическая компоновка базы данных и управление хранением
145
Таблица 4.3. Динамические представления производительности, связанные с ASM
Имя представления Используется ли в стандартной базе данных? Описание
V$ASM_DISK Да По одной строке для каждого диска, обнаруженного экземпляром ASM, вне зависимости от того, используется ли он в дисковой группе или нет. Для экземпляра базы данных — одна строка для каждой дисковой группы, используемой экземпляром.
V$ASM_DISKGROUP Да Для экземпляра ASM — одна строка для каждой дисковой группы, содержащая общие характеристики этой группы. Для экземпляра базы данных — одна строка для каждой используемой дисковой группы, неважно, смонтирована она или нет.
V$ASM_FILE Нет Одна строка для каждого файла в каждой смонтированной дисковой группе.
V$ASM_OP ERATION Нет Одна строка для каждой выполняющейся длительное время операции в экземпляре ASM.
V$ASM_TEMPLATE Да Одна строка для каждого шаблона в каждой смонтированной дисковой группе для экземпляра ASM. Для экземпляра базы данных — одна строка для каждого шаблона для каждой смонтированной дисковой группы.
V$ASM_CLIENT Да Одна строка для каждой базы данных, использующей дисковые группы, управляемые экземпляром ASM. Для экземпляра базы данных — одна строка для экземпляра ASM, если имеются отрытые экземпляры.
V$ASM_ALIAS Нет Одна строка для каждого псевдонима в каждой смонтированной дисковой группе.
Форматы имен файлов ASM
Файлы ASM являются управляемыми Oracle файлами (OMF), так что для оольшинства административных функций подробные сведения о фактическом имени файла внутри диско„вой группы не требуются. Когда удаляется объект из дисковой группы ASM, соответствующий файл удаляется автоматически. Для определенных команд требуется знание реальных имен файлов, как, например, для команд alter database backup controlfile to trace, а также для некоторых представлений словаря данных и динамических представлений производительности. Так, например, динамическое представление производительности V$DATAFILE выводит на экран фактические имена файлов в составе каждой дисковой группы:
146
Глава 4
□ SQL> select file#, name, blocks from v$datafile;
FILE# NAME
BLOCKS
1 +DATA1/racO/datafile/system.303.1 57600
2 +DATA1/racO/datafile/undotbs1.302.1 3840
3 +DATA1/rac0/datafile/sysaux. 304.1 44800
4 +DATA1/racO/datafile/users.3O5.1 640
5 +DATA1/rac0/datafile/example. 306.1 19200
6 +DATA2/racO/datafile/users.311.1 12800
6 rows selected.
Имена файлов ASM могут иметь один из шести различных форматов. Ниже будет приведен обзор этих различных форматов и контекстов, в которых они могут быть использованы либо как ссылки па существующие файлы во время операции повторного создания одиночного файла, либо во время операции множественного создания файлов.
Полностью квалифицированное имя
Полностью квалифицированные имена файлов ASM используются только при ссылке на существующий файл. Полностью квалифицированное имя файла ASM имеет следующий формат:
□ +группа/имя_базы_данных/тип_файла/тэг.номер_файла.инкарнация
где группа — это имя дисковой группы; имл_базы_данных — это имя базы данных, которой принадлежит файл; тип_файла — это тип файла Oracle; тэг содержит информацию, зависящую от типа файла, а пара номер_фай-ла.ипкарнация— это пара, служащая для обеспечения уникальности. Ниже приводится пример имени файла ASM для табличного пространства USERS3:
П +DATA2/racO/datafile/users3.311.1
Дисковая группа называется +DATA2, имя базы данных — гасО, это файл данных табличного пространства USERS3, а пара номер_файла/инкарнация (311.1) гарантирует уникальность, если вы решите создать для табличного пространства USERS3 другой файл данных ASM.
Числовые имена
Числовые имена используются только при ссылках на существующие файлы ASM. Они позволяют ссылаться на существующий файл ASM, используя только имя дисковой группы и пару но мер_файл а. инкарнация. Числовое имя файла ASM для файла из предыдущего раздела:
П +DATA2.311.1
Имя-псевдоним
Псевдоним может быть использован либо при ссылке па существующий файл, либо при создании одиночного файла ASM- помощи команды
alter diskgroup add alias, можно создать более удооочитаемое имя для существующего или для нового файла ASM, и оно будет отличаться от обыч
физическая компоновка базы данных и управление хранением
147
ного имени файла ASM тем, что оно не закапчивается разделенной точками парой чисел (номер файла.инкарнация):
□ SQL> alter diskgroup data2
2 add directory ‘+data2/purch’;
Diskgroup altered
SQL> alter diskgroup data2
2 add alias *+data2/purch/users.dbf’
3 for ‘+data2/rac0/datafile/users3.311.1’;
Diskgroup altered.
SQL>
Имена-псевдонимы с шаблонами
Псевдоним с шаблоном может быть использован только при создании нового файла ASM. Шаблон обеспечивает краткую запись для специфицирования типа файла и тэга при создании нового файла ASM. Ниже приводится пример псевдонима, использующего шаблон для нового табличного пространства в дисковой группе +DATA2:
□ SQL> create tablespace users4 datafile ‘+data2/user_spare(datafile)’; Tablespace created.
Неполные имена
Формат с неполным именем файла может быть использован при операциях по созданию либо одиночного файла, либо нескольких файлов ASM. Специфицируется только имя дисковой группы, а используемый по умолчанию шаблон применяется в зависимости от типа файла:
□ SQL> create tablespace users5 datafile ‘+data1’; Tablespace created.
Неполные имена с шаблонами
Как и в случае с неполными именами файлов ASM, неполное имя файла с шаблоном может быть использовано для операций по созданию либо одиночного файла, либо нескольких файлов. Независимо от фактического типа файла, имя шаблона определяет характеристики файла. Несмотря на то, что в следующем примере создается постоянное табличное пространство, в качестве атрибутов файла данных будут использованы характеристики временного файла:
SQL> create tablespace users6 datafile ‘+data1 (tempfile)’;
Tablespace altered
Типы файлов и шаблоны ASM
ASM поддерживает все типы файлов, используемых в базах данных, за исключением выполняемых файлов операционной системы. В таблице 4.4 приведен полный перечень типов файлов ASM; столбцы «Тип файла ASM» и «Тэг» означаю! то же, что и в приведенных ранее соглашениях об именовании файлов ASM.
148
Гпава 4
Таблица 4.4. Типы файлов ASM
Тип файла Oracle Тип файла ASM Тэг Шаблон по умолчанию
Управляющие файлы controlfile cf (управляющий файл) или bcf (резервный управляющий файл) CONTROLFILE
Файлы данных datafile имя_табличного_про-странства.номер_файла DATAFILE
Оперативные журналы onlinejog номер_потока_журнала ONLINELOG
Архивные журналы archivejog параметр ARCHIVELOG
Временные файлы temp имя_табличного_про-странства.номер_файла ТЕМ PFILE
Файл данных с фрагментами резервных копий RMAN backupset Определяется клиентом BACKUPSET
Файл данных с инкрементальными фрагментами резервных копий RMAN backupset Определяется клиентом BACKUPSET
Архивный журнал с фрагментами резервных копий RMAN backupset Определяется клиентом BACKUPSET
Копия файла данных RMAN datafile имя_табличного про-странства.номер_файла DATAFILE
Параметры инициализации init spfile PARAMETERFILE
Конфигурация брокера drc drc DATAGUARDCONFIG
Ретроспективные (flashback) журналы rlog номер_потока_номер_ журнала FLASHBACK
Битовая карта для отслеживания изменений ctb bitmap CHANGETRACKING
Автоматическое резервное копирование autobackup Определяется клиентом AUTOBACKUP
Набор файлов дампа Data Pump dumpset dump DUMPSET
Кросс-платфор- - — — — XTRANSPORT
менные файлы данных
физическая компоновка базы данных и управление хранением
149
Используемые по умолчанию шаблоны файлов ASM, упомянутые в последнем столбце таблицы 4.4, представлены в таблице 4.5.
При создании новой дисковой группы вместе с ней сохраняется набор шаблонов файлов ASM, скопированных из шаблонов по умолчанию таблицы 4.5; в результате характеристики индивидуальных шаблонов могут быть изменены и применены только к тем дисковым группам, где они хранятся. Другими словами, для системного шаблона DATAFILE в дисковой группе +DATA1 по умолчанию может применяться крупноблочное чередование (coarse striping), в то время как в дисковой группе +DATA2 может быть использовано мелкоблочное чередование (fine striping). При необходимости можно для каждой дисковой группы создавать собственные шаблоны.
Когда создается файл данных ASM с шаблоном DATAFILE, по умолчанию для этого файла данных выделяется 100 Мбайт дисковой памяти, он является автоматически расширяемым, а его максимальный размер неограничен.
Таблица 4.5. Используемые по умолчанию шаблоны файлов ASM
Системный шаблон Внешняя избыточность Обычная избыточность Высокая избыточность Рассредоточение
CONTROLFILE Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Мелкоблочное
DATAFILE Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Крупноблочное
ONLINELOG Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Мелкоблочное
ARCHIVELOG Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Крупноблочное
TEMPFILE Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Крупноблочное
BACKUPSET Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Крупноблочное
XTRANSPORT Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Крупноблочное
PARAMETERFILE Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Крупноблочное
DATAGUARDCONFIG Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Крупноблочное
FLASHBACK Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Мелкоблочное
CHANGETRACKING Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Крупноблочное
AUTOBACKUP Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Крупноблочное
DUMPSET Незащищенный Двукратное зеркалирование Трехкратное зеркалирование Крупноблочное
150
Г.пава 4
Администрирование дисковых групп ASM
Использование дисковых групп ASM оказывается выгодным по нескольким причинам: повышается производительность ввода/вывода, увеличивается доступность, а простота, с которой можно добавить диск в дисковую группу или добавить абсолютно новую дисковую группу, позволяет за то же самое время справляться с управлением большим числом баз данных. Понимание компонент дисковой группы, а также ее соответствующее конфигурирование являются весьма важными задачами для успешного АБД.
Архитектура дисковых групп
Дисковой группой называется совокупность (collection) физических дисков, управляемая как единый элемент. У каждого диска ASM как у части дисковой группы имеется имя диска ASM, которое либо назначается АБД, либо присваивается ему автоматически при включении в дисковую группу.
Файлы в дисковой группе рассредоточены по дискам с применением либо крупноблочного, либо мелкоблочного расщепления. При крупноблочном расщеплении (coarse striping) файлы рассредоточиваются по всем доступным дискам блоками по 1 Мбайт. Такое расщепление оказывается подходящим для системы с высокой степенью одновременно выполняющихся небольших по объему запросов на ввод/вывод, например для сред OLTP. При мелкоблочном расщеплении файлы разбиваются на блоки размером 128 Кбайт. Такое расщепление более всего подходит для традиционных сред хранилищ данных или для систем OLTP с не слишком высоким конкурентным доступом, так как при этом минимизируется время отклика на индивидуальные запросы ввода/вывода.
f
Зеркалирование дисковых групп и групп отказа
Прежде чем определить тип зеркалирования в дисковой группе, необходимо сгруппировать диски в так называемые группы отказа. Группой отказа называется один или несколько входящих в состав дисковой группы дисков, разделяющих некоторый общий ресурс, например контроллер дисков, выход которого из строя делает недоступным для дисковой группы весь этот набор дисков. В большинстве случаев экземпляр ASM не знает об аппаратных и программных зависимостях для данного диска. Следовательно, если только специально не приписать диск к группе отказа, каждому диску будет назначена собственная группа отказа.
После определения группы отказа можно определить зеркалирование для дисковых групп; тип зеркалирования, доступный для дисковой группы, может быть ограничен числом имеющихся в дисковой группе групп отказа. Есть всего три типа зеркалирования: внешняя, обычная и высокая избыточность.
Внешняя избыточность
Для внешней избыточности требуется наличие только одной группы отказа. Предполагается, что дисковая группа не является критичной для продолжения функционирования базы данных или чю диск является
физическая компоновка базы данных и управление хранением
151
управляемым внешним образом с помощью специализированного программного обеспечения, гарантирующего высокую доступность, например с помощью контроллера RAID.
Обычная избыточность
Обычная избыточность обеспечивает двукратное зеркалирование и требует, чтобы в группе дисков было, по крайней мере, две группы отказа. Выход из строя одного из дисков в группе отказа не вызывает никакого простоя дисковой группы и не приводит к потере данных, разве что к небольшой потере производительности запросов к объектам из этой дисковой группы.
Высокая избыточность
Для обеспечения высокой избыточности предлагается трехкратное зеркалирование, для чего требуется, чтобы в группе дисков было не менее трех групп отказа. Выход из строя дисков в двух группах отказа из имеющихся трех в большинстве случаев останется прозрачным для пользователей базы данных, как и в случае зеркалирования с обычной избыточностью.
Управление зеркалированием осуществляется на очень низком уровне. Зеркалируются не диски, а экстенты. Кроме того, на каждом диске должна храниться смесь первичных и зеркалированных (вторичных и третичных) экстентов. И хотя для управления зеркалированием на уровне экстентов не обойтись без небольших накладных расходов, зеркалирование обеспечивает преимущества рассредоточения нагрузки с вышедшего из строя диска на все оставшиеся диски, а не на один диск.
Динамическая перенастройка дисковой группы
Всякий раз, когда конфигурация дисковой группы изменяется — если вы добавляете в нее или удаляете из нес группу отказа или диск, в составе группы отказа автоматически производится динамическая перенастройка для пропорционального перераспределения данных с других дисков, являющихся членами дисковой группы, на новый ее член. Перенастройка происходит в то время, когда база данных находится в оперативном состоянии и доступна для пользователей; любое влияние на непрекращаю-щиеся операции ввода/вывода пользователей может быть взято под контроль посредством настройки значения параметра инициализации ASM_POWER_LIMIT в сторону более низких значений.
Динамическая перенастройка не только освобождает от утомительной и зачастую подверженной ошибкам процедуры определения «горячих точек» для дисковой группы, по и предлагает способ автоматического переноса всей базы данных с набора более медленных дисков на набор оолее высокоскоростных дисков без остановки базы данных. Более высокоскоростные диски добавляются как новая группа отказа в существующую дисковую группу наряду с имеющимися «медленными» дисками, после чего происходит автоматическая перенастройка. После завершения этой перенастройки группы отказа, в которые входят медленные диски, удаляются, так что будут оставлены только группы отказа, состоящие из высокоскоростных дисков. Чтобы сделать эту операцию еще более быстрой, обе операции add (добавить) и drop (удалить) могут быть инициированы внутри одной команды alter diskgroup (изменить дисковую группу).
152
Гпава 4
Предположим, что требуется создать новую дисковую группу с высокой избыточностью, где будут храниться табличные пространства с данными для нового приложения по авторизации кредитных карт. С помощью представления V$ASMJDISK можно, применив параметр инициализации V$ASMJDISKSTRING и статус диска, просмотреть все обнаруженные диски (друтими словами, выяснить, был ли этот диск назначен существующей дисковой группе или остался нераспределенным):
□ SQL> select group_number, disk_number, name,
2 failgroup, create_date, path from v$asm_disk;
GROUP.NUMBER DISK NUMBER NAME FAILGROUP CREATE.DA PATH
0
0
0
0
1
1
0
1
2
3
/dev/raw/raw6 /dev/raw/raw5 /dev/raw/raw4 /dev/raw/raw3
1 DATA1.0001 DATA1_OOO1 13-JUN-04 /dev/raw/raw2 0 DATA1_OOOO DATA1_OOOO 13-JUN-04 /dev/raw/raw1
6 rows selected. SQL>
Из шести доступных для ASM дисков только два назначены для одиночной дисковой группы, причем каждый из них образует собственную группу отказа. Имя дисковой группы может быть получено из представления V$ASM JDISKGROUP:
П SQL> select group_number, name, type, totaljnb, freejnb
2 from v$asm_diskgroup;
GROUP_NUMBER NAME TYPE TOTAL_MB FREE_MB
1 DATA1 NORMAL 16378 14024
SQL>
Если есть некоторое количество дисков и дисковых групп ASM, можно объединить эти два представления по столбцу GROUP_NUMBER и отфильтровать результаты запроса по этому же столбцу. Кроме того, из V$ASM_DISKGROUP можно видеть, что дисковая группа DATA1 является состоящей из двух дисков группой с обычной избыточностью (NOR REDUNDANCY).
На первом шаге создадим дисковую группу:
□ SQL> create diskgroup data2 high redundancy
2 failgroup fgi disk ‘/dev/raw/raw3’ name d2a
3 failgroup fg2 disk ‘/dev/raw/raw4’ name d2b
4 failgroup fg3 disk ‘/dev/raw/raw5’ name d2c
5 failgroup fg4 disk */dev/raw/raw6’ name d2d;
Diskgroup created.
SQL>
физическая компоновка базы данных и управление хранением
153
Взглянув на динамические представления производительности, из представления V$ASM_DISKGROUP можно увидеть ставшую доступной новую дисковую группу, а из представления V$ASMJDISK ознакомиться с группами отказа:
□ SQL> select group_number, name, type, totaljnb, freejnb
2 from v$asm_diskgroup;
GROUP .NUMBER NAME TYPE T0TAL_MB FREE_MB
1 DATA1 2 DATA2 NORMAL 16378 14024 HIGH 24572 24420
SQL> select group_number, diskjiumber, name,
2 failgroup, create_date, path from v$asm_disk;
GROUP_NUMBER DISK_NUMBER NAME FAILGROUP CREATE_DA PATH
2 3 D2D FG4 14-JUN-04 /dev/raw/raw6
2 2 D2C FG3 14-JUN-04 /dev/raw/raw5
2 1 D2B FG2 14-JUN-04 /dev/raw/raw4
2 0 D2A FG1 14-JUN-04 /dev/raw/raw3
1 1 DATA1 _0001 DATA1. _0001 13-JUN-04 /dev/raw/raw2
1 0 DATA1 _0000 DATA1 _0000 13-JUN-04 /dev/raw/raw1
6 rows selected.
SQL>
Однако, если дискового пространства маловато, можно отказаться от четырех членов; для дисковой группы с высокой избыточностью достаточно трех групп отказа, так что можно удалить эту дисковую группу и заново создать ее только с тремя членами:
О SQL> drop diskgroup data2;
Diskgroup dropped.
Если в дисковой группе есть какие-либо объекты базы данных, кроме метаданных дисковой группы, необходимо специфицировать в команде drop diskgroup фразу including contents. Это является дополнительной мерой предосторожности, позволяющей убедиться, что дисковые группы с объектами базы данных не будут случайно удалены:
SQ > create diskgroup data2 high redundancy
2 failgroup fg1 disk ‘dev/raw/raw3’ name d2a
3 failgroup fg2 disk ‘dev/raw/raw4’ name d2b
4 failgroup fg3 disk ‘dev/raw/raw5’ name d2c;
Diskgroup created.
SQL> select group_number, disk_number, name,
2 failgroup, create_date, path from v$asm_disk;
154
Гпава 4
GROUP_NUMBER DISK-NUMBER NAME FAILGROUP CREATE_DA PATH
0 3 15-JUN-04 /dev/raw/raw6
2 2 D2C FG3 15-JUN-04 /dev/raw/raw5
2 1 D2B FG2 15-JUN-04 /dev/raw/raw4
2 0 D2A FG1 15-JUN-04 /dev/raw/raw3
1 1 DATA1-0001 DATA1_0001 13-JUN-04 /dev/raw/raw2
1 0 DATA1_0000 DATA1 0000 13-JUN-04 /dev/raw/raw1
6 rows selected.
SQL> * ь
Теперь, когда конфигурирование новой дисковой группы закончено, в новой дисковой группе можно создать табличное пространство (из экземпляра базы данных):
□ SQL> create tablespace users3 datafile ‘+DATA2’;
Tablespace created.
Поскольку файлы ASM являются управляемыми Oracle файлами, при создании табличного пространства не требуется задавать никаких других его характеристик.
Изменение дисковых групп
В дисковую группу можно добавлять диски и удалять их оттуда; кроме того, многие характеристики дисковой группы могут быть изменены без повторного ее создания и не оказывая влияния на транзакции пользователей над объектами из дисковой группы.
Когда диск добавляется к дисковой группе, после того как диск будет отформатирован для использования в дисковой группе, выполняется операция перенастройки. Скорость перенастройки контролируется параметром инициализации ASM_POWER_LIMIT.
Продолжая пример, предположим, что принято решение улучшить характеристики ввода/вывода дисковой группы DATA1, добавив в нее последний из оставшихся в наличии «чистых» дисков:
□ SQL> alter diskgroup datal
2 add failgroup d1fg3 disk ‘/dev/raw/raw6’ name die;
Diskgroup altered.
Немедленно осуществляется выход из команды, а форматирование и перенастройка продолжаются в фоновом режиме. После этого можно проверить статус операции перенастройки, проверив представление V$ASM OPERATION:
□ SQL> select group_number, operation, state, power, actual,
2 sofar, est_work, est_rate, est_minutes from v$asm_operation;
GROUP.NUMBER OPERA STAT POWER ACTUA SOFAR EST.W0RK EST_RATE EST_MINUTES
1 REBAL RUN 1 1 3 964 60 16
физическая компоновка базы данных и управление хранением
155
Поскольку оценочное время завершения операции перенастройки составляет 16 мин, принимается решение выделить для этой операции больше ресурсов и изменить предельную «мощность» этой конкретной операции перенастройки:
П SQL> alter diskgroup datal rebalance power 8;
Diskgroup altered.
Проверка статуса операции перенастройки подтверждает, что оценочное время до завершения операции сократилось с 16 до 4 минут:
□ SQL> select group_number, operation, state, power, actual,
2 sofar, est_work, est_rate, estjninutes from v$asm_operation;
GROUP.NUMBER OPERA STAT POWER ACTUA SOFAR EST_WORK EST RATE EST MINUTES
1 REBAL RUN 8 8 16 605 118 4
Спустя четыре минуты проверим статус задания еще раз:
□ SQL> /
no rows selected.
И, наконец, подтвердим конфигурацию нового диска из представлений V$ASM_DISK и V$ASM JDISKGROUP:
□ SQL> select group_number, disk_number, name,
2 failgroup, create_date, path from v$asm_disk;
GROUP_NUMBER DISK_ NUMBER NAME FAILGROUP CREATE-DA PATH
1 2 D1C D1FG3 15-JUN-04 /dev/raw/raw6
2 2 D2C FG3 15-JUN-04 /dev/raw/raw5
2 1 D2B FG2 15-JUN-04 /dev/raw/raw4
2 0 D2A FG1 15-JUN-04 /dev/raw/raw3
1 1 DATA1- 0001 DATA1_0001 13-JUN-04 /dev/raw/raw2
1 0 DATA1_ 0000 DATA1.0000 13-JUN-04 /dev/raw/raw1
6 rows selected.
SQL> select group- number, name, type, total_mb, f reejnb
2 from v$asm .diskgroup;
GROUP_NUMBER name TYPE TOTAL_MB FREE_MB
** — — — —. —-
1 DATA1 NORMAL 22521 20116
2 DATA2 HIGH 18429 18279
SQL>
Избыточность дисковой группы остается нормальной, несмотря на то, что в ней есть три группы отказа. Однако производительность вво-Да/вывода оператора select относительно объектов из этой дисковой
156
Глава 4
группы возрастает благодаря наличию дополнительных копий экстентов, ставших доступными для дисковой группы.
Другие команды alter для дисковых групп приведены в таблице 4.6.
Табл ица 4.6. Команды AL TER для дисковых групп
Описание
Команда alter diskgroup
alter diskgroup... drop disk Удаляет диск из группы отказа в составе дисковой группы и выполняет автоматическую перенастройку
alter diskgroup... drop... add Удаляет диск из группы отказа и добавляет (в той же команде) вместо него другой диск
alter diskgroup... mount Делает дисковую группу доступной для всех экземпляров
alter diskgroup... dismount Делает дисковую группу недоступной для всех экземпляров
alter diskgroup... check all Проверяет внутреннюю согласованность дисковой группы
Дисковые группы ASM и ЕМ Database Control
Для администрирования дисковых групп может быть также использована утилита ЕМ Database Control. Для базы данных, в которой используются дисковые группы, ссылка Disk Groups, размещенная под закладкой Administration, отсылает на страницу входа в систему для экземпляра ASM, изображенную на рис. 4.21. При аутентификации для экземпляра ASM используется только аутентификация операционной системы.
Рис. 4.21. Страница входа в экземпляр ASM утилиты ЕМ Database Control
физическая компоновка базы данных и управление хранением
157
Рис. 4.22. Страница администрирования ASM утилиты ЕМ Database Control
После аутентификации экземпляра ASM можно выполнить те же самые операции, которые выполнялись в этой главе ранее из командной строки — монтирование и размонтирование дисковых групп, добавление дисковых групп, добавление и удаление членов дисковых групп и так далее. На рис. 4.22 изображена страница администрирования ASM, а на рис. 4.23 — статистика и опции для дисковой группы DATA1.
Другие связанные с ASM страницы ЕМ Database Control показывают время отклика запроса ввода/вывода для дисковой группы, действующие параметры инициализации для этого экземпляра ASM и многое другое.
Миграция базы данных в среду ASM
Поскольку к файлам ASM нельзя получить доступ средствами операцион-ной системы, для перемещения в дисковую группу ASM объектов базы данных, хранящихся не в среде ASM, необходимо использовать диспетчер восстановления (RMAN). Для перемещения таких объектов нужно выполнить следующие шаги:
1. Записать имена файлов для управляющих файлов и оперативных журналов.
2. Остановить базу данных, используя режимы NORMAL, IMMEDIATE или TRANSACTIONAL.
3. Создать резервную копию базы данных.
4. Отредактировать SPFILE, чтобы для всех целевых файлов использовались OMF.
158
Глава 4
w*L
Г-7
view go £ook marks Tods yvindow Help
g^4'
. jr. • J L
N,fi^.LBJxk;rjrl, HIc Edit
Back
, ji hhpv/devSSOOzem/cor.sciefdau'ibase/Gsnvdisdv-'
Reload I—i
........., Э
LA. Search n J Peel
J ’’
-ft Home ..^Bookmarks ^RedHat. inc. ^Rc-d Hat Network TjSnppcrt jjShop Lj Products .^TMirung
Gen . rn• Р^сипапсе
Terrtp;q!q$ PtAg
Disk Group Usckis ((Ж
State MOUNTED
Ll%
Hi
\ UtGU
Name DATAi
ne
.J
,,, # _.f,
Q1Q
D1FG3
dez гал.га-лб
DATA I 0000
dev tavvrawi
Redundancy NORMAL
Total (GSj 21.99 GB
DAT Al 0001.
Fiee^GBi 19.47 GB
Pending
Operations
*
L5-f?mb»r Disks
;i2J-ALL
No data is currenwawfcUa.
vWbMA’AiV.y^Arv.V.V.W **V-V ЛбЧ'/Л1'
\ c. ASM Disk Nan
I 06
| Til 0'1
Рис. 4.23. Статистика дисковых групп ASM утилиты ЕМ Database Control
Delete 3 Check
0 NORMAL
0NORMAL
0NORMAL
о 00 Ж
0.42
S.OOissa
1.05
3
5. Отредактировать SPFILE, чтобы удалить из него параметр CONTROLJFTLES.
6. Выполнить следующий сценарий RMAN, при необходимости заменив имена файлов на имена, использующиеся в вашей системе:
STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM ‘<место_размещения_управляющего_файла>’;
ALTER DATABASE MOUNT-
BACKUP AS COPY DATABASE FORMAT
‘+<место_нахождения_дисковой_группы>;
SWITCH DATABASE TO COPY;
SQL «ALTER DATABASE RENAME <файл_журнала_базы_данных_1> TO ‘+<место_нахождения_дисковой_группы>’ «;
# повторить для всех членов журнала
ALTER DATABASE OPEN RESETLOGS;
7. Удалить или заархивировать файлы старой базы данных.
Несмотря на то, что теперь все файлы в этом примере являются файлами ASM, можно по-прежнему создать табличное пространство, не принадлежащее ASM, если, например, требуется переместить табличное пространство в базу данных, не использующую ASM.
Часть I
Управление базой данных
РАЗРАБОТКА И РЕАЛИЗАЦИЯ ПРИЛОЖЕНИЙ
1
Управление разработкой приложения — это трудный процесс. Поэтому администратору базы данных лучше всего войти в состав команды, участвующей в разработке, чтобы стать неотъемлемой ее частью. В данной главе описываются действия, необходимые для переноса приложений в среды баз данных, и технические подробности реализации этого процесса, в частности, формулы для определения размеров объектов БД.
Основное внимание здесь уделено проектированию и созданию приложений, использующих базы данных. Эти действия должны быть интегрированы с деятельностью по планированию базы данных, описанной в главах 3 и 4. В последующих главах обсуждаются действия по мониторингу и настройке базы данных, следующие за ее созданием.
Реализации приложения в базе данных путем простого выполнения последовательности команд create table недостаточно для интеграции процесса создания объектов с другими сферами деятельности разработчика (планирование, мониторинг и настройка). Администратор БД должен участвовать в разработке приложения, чтобы правильно спроектировать базу данных, которая будет поддерживать конечный продукт. Описанные в данной главе методы содержат также важную информацию о мониторинге и настройке базы данных.
Преднамеренная настройка: практические советы
По крайней мере, 50% проблем с производительностью закладываются на стадии проектирования приложения. В процессе проектирования приложения и связанных с ним структур базы данных архитекторы приложения могут не знать обо всех способах, посредством которых на предприятии будут использоваться данные этого приложения спустя некоторое время. В результате у приложения могут оказаться компоненты, производительность которых неудовлетворительна с первого релиза, но в то же самое время некоторые проблемы могут проявляться позже, по мере того как будет изменяться бизнес-применение приложения.
разработка и реализация приложений
161
В некоторых случаях исправление может оказаться относительно очевидным — изменение параметра инициализации, добавление индекса или перенос времени выполнения длительных операций. В других случаях проблема не может быть разрешена без изменения архитектуры приложения. Например, приложение могло быть спроектировано с интенсивным повторным использованием функций для всех операций доступа к данным — т. е. функции вызывают другие функции, которые вызывают дополнительные функции, даже в тех случаях, когда выполняются простейшие операции с базой данных. В результате один вызов базы данных из приложения может превратиться в десятки тысяч вызовов функций и обращений к базе данных. Как правило, такие приложения не способны хорошо масштабироваться; по мере того как все больше пользователей подключаются к системе, увеличивающаяся нагрузка на процессор от большого числа выполнений в пересчете на одного пользователя будет приводить к снижению производительности для индивидуальных пользователей. Настройка индивидуальных операторов SQL, выполняющихся как часть приложения, может дать лишь небольшой выигрыш в производительности; операторы сами по себе могли быть уже достаточно хорошо настроены. Скорее, речь идет о том, что проблемы с производительностью вызываются слишком большим числом выполняемых операций.
Приводимые ниже практические рекомендации могут показаться чрезмерно упрощенными, но они раз за разом нарушаются при проектировании приложений баз данных, и эти нарушения непосредственно приводят к проблемам с производительностью. Всегда есть и исключения из правил — последующее изменение программного обеспечения или операционной среды могут позволить нарушить правила, не влияя при этом на производительность. Однако следование этим правилам позволит удовлетворить всем требованиям к производительности приложения при расширении его применения.
Делайте как можно меньше
Конечным пользователям безразлично, являются ли базовые структуры базы данных нормализованными к третьей нормальной форме (ТНФ) или они представлены в соответствии с объектно-ориентированными стандартами. Пользователи хотят выполнять свой бизнес-процесс, а приложение должно быть инструментом, который помогает выполнить этот процесс как можно скорее. Целью действий по проектированию должно быть вовсе не достижение технического совершенства проекта, а возможность выполнения целей, поставленных пользователем. Следовательно, задача АБД состоит в упрощении процессов, используемых на каждом шаге приложения.
Ваша требовательность может стать камнем преткновения в отношениях с командой разработчиков приложения. Если команда разработчиков настаивает на применении полностью нормализованных моделей Данных, АБД должен обратить их внимание на количество шагов базы Данных, используемых в каждой транзакции. Так, например, при вставке Для сложной транзакции (скажем, вставка строки заказа) может потребоваться выполнить просмотр многих кодовых таблиц (классификато-
162
Глава 5
ров) и несколько операций вставки. Для одного пользователя это может и не составить проблемы, но для множества одновременно работающих пользователей это может привести к возникновению проблем с производительностью или с взаимными блокировками. С точки зрения планирования производительности в операциях вставки должно быть задействовано как можно меньше таблиц, а запросы должны осуществлять выборку данных, которые были ранее сохранены в формате, максимально близком к конечному формату, который будет запрашиваться пользователями. При выполнении сложных запросов у полностью нормализованных баз данных и у объектно-ориентированных проектов есть тенденция требовать большого числа соединений (joins). Хотя необходимо бороться за поддержание управляемых моделей данных, в первую очередь усилия должны быть направлены на повышение как функциональности приложения, так и его возможности удовлетворять требованиям предприятия к производительности.
Постарайтесь устранить из проекта приложения операции логического чтения
Раньше было модно делать упор на устранение операций физического чтения, и хотя эта идея остается полезной и до сих пор, следует отметить, что никакого физического чтения не произойдет, пока его не потребует логическое чтение.
Рассмотрим простой пример. Выберем из фиктивной таблицы DUAL текущее время. Если осуществлять выборку с точностью до второго уровня, значение будет изменяться 86 400 раз в сутки. Но есть такие разработчики приложений, которые многократно — по несколько миллионов раз в сутки — выполняют этот запрос. Такой запрос, вероятно, в течение суток выполняет довольно мало операций физического чтения с диска. Следовательно, если ограничиться только настройкой физического вво-да/вывода, мы полностью пренебрежем этим оператором. Однако он может оказать существенное влияние на производительность всего приложения. Как? Очень просто: путем использования доступных ресурсов ЦП. Каждое выполнение запроса вынуждает Oracle работать, используя вычислительную мощность для нахождения и возврата правильных данных. Когда все больше и больше пользователей станут раз за разом выполнять эту команду, то обнаружится, что число логических операций чтения для этого запроса превосходит потребности всех других запросов. В некоторых случаях получается, что несколько процессоров сервера Пс' ликом выделяются для обслуживания многократно повторяемых малых запросов подобного сорта. Если многим пользователям требуется читать одни и те же данные, их нужно сохранить в таблице или в переменно па кета.
Рассмотрим пример из реальной жизни. Программисту необходим0 реализовать паузу в программе, вынудив ее ожидать 30 сек между зав< р шенисм одного шага и началом другого. Поскольку производительность среды не является одинаковой в разные моменты времени, програМ мист кодирует эту процедуру в следующем формате (показано в псевдокоде):
разработка и реализация приложений
163
□ perform Step 1
select SysDate from DUAL into a StartTime variable begin loop
select SysDate from DUAL in a CurrentTime variable;
Compare CurrentTime with the StartTime variable value.
If 30 seconds have passed, exit the loop;
Otherwise repeat the loop, calculating SysDate again, end loop
Perform Step 2.
(выполнить шаг 1
выбрать SysDate из DUAL в переменную StartTime начать цикл
выбрать SysDate из DUAL в переменную CurrentTime;
Сравнить переменную Currentlime со значением переменной StartTime. Если прошло 30 сек, выйти из цикла;
В противном случае выполнить цикл вычисления SysDate снова, конец цикла Выполнить шаг 2).
Разумен ли подобный подход? Конечно, нет! Разумеется, то, чего хо тел программист, будет выполнено, но это дорого обойдется приложению. Более того, здесь нет ничего, чем АБД мог бы помочь в повышении производительности приложения. В этом случае стоимость обусловливается не действиями по вводу/выводу (таблица DUAL постоянно хранится в области оперативной памяти экземпляра) а, скорее, активностью ЦП. При каждом выполнении этой программы каждым ее пользователем база данных будет затрачивать 30 сек, потребляя столько ресурсов ЦП, сколько может выделить ей система. В данном конкретном случае запрос select SysDate from DUAL отвечает за 40% времени ЦП, затрачиваемого приложением. Все это процессорное время можно считать потерянным. Эту проблему невозможно разрешить путем настройки параметров инициализации базы данных. Настройка индивидуального оператора SQL также не поможет; необходимо пересмотреть проектное решение приложения, чтобы устранить это бесполезное выполнение команд. Например, в данном случае разработчик мог бы использовать команду sleep на уровне операционной системы или внут ри программы, чтобы вызвать аналогичное поведение приложения, не делая вызовов базы данных.
Для тех, кто предпочитает настраивать систему, опираясь на коэффициент попадания в кэш буферов, — у этой базы данных коэффициент попадания в кэш буферов будет равен практически 100%. Это связано с неоправданно большим количеством полностью бесполезных логических чтений без связанных с ними операций физического чтения. Коэффициент попадания в кэш буферов определяется через отношение числа логических чтений к числу физических чтений; если на 10 логических чтений требуется одно физическое, коэффициент попадания в кэш буферов будет равен 90%. Низкие значения коэффициента попадания свидетельствуют о том, что база данных выполняет большое количество физических считываний; экстремально высокие значения коэффициента попадания, как в данном примере, говоря! о том, что база данных выполняет чрезмерно большое количество логических считываний. Следует смотреть дальше коэффициента попадания в кэш буферов и искать команды, гене рирующие логические и физические считывания.
164
Глава 5
Постарайтесь устранить из проекта приложения «путешествия» в базу данных
Помните, что настраивается приложение, а не запрос. При настройке операций с базой данных может потребоваться объединить несколько запросов в одну процедуру, чтобы можно было ограничиться однократным получением доступа к базе данных, вместо того чтобы несколько раз обращаться к ней для получения каждого экрана с выходными данными. Такой подход «связанных запросов» особенно уместен для приложений типа «тонкий клиент» (thin client), которые используют несколько слоев приложения. Ищите запросы, взаимосвязанные по возвращаемым ими результатам, и исследуйте возможность объединения их в единые блоки кода. Задача заключается не в том, чтобы создать монолитный запрос, который никогда не сможет закончиться; необходимо избежать выполнения работы, которую вообще не следует делать. В данном случае мишенью для настройки должно стать постоянное общение (пересылки туда-сюда) между сервером базы данных, сервером приложений и компьютерами конечных пользователей.
Подобные проблемы часто встречаются в сложных формах ввода данных, где каждое отображаемое на экране поле генерируется отдельным запросом. Каждый из этих запросов — это отдельное путешествие в базу данных. В этом случае база данных вынуждена выполнять большое число взаимосвязанных запросов. Даже если каждый из этих запросов настроен, нагрузка от количества команд, умноженная на количество пользователей, поглотит доступные на сервере ресурсы ЦП. Подобное проектирование может оказать влияние и на использование сети, но причины данной проблемы редко бывают связаны с самой сетью — все дело в количестве обращений к базе данных.
Внутри пакетов и процедур также следует прилагать усилия для устранения необязательных обращений к базе данных. Часто используемые величины нужно хранить в локальных переменных, а не извлекать их раз за разом из базы данных. Если «путешествие» в базу данных для получения информации не является необходимостью, не совершайте его. Это простое правило, но при разработке приложений оно часто упускается из виду.
Нет параметра инициализации, который мог бы сделать так, чтобы подобные изменения вступили в силу. Это задача проектирования, и для ее решения требуется активное вовлечение разработчиков, проектировщиков, АБД и пользователей приложений в процесс планирования производительности и настройки.
Для систем отчетности старайтесь хранить данные именно так, как их будет запрашивать пользователь
Если известно, какие запросы будут выполняться (например, через паря метризованные отчеты), следует приложить максимум усилий для хране ния данных таким образом, чтобы Oracle с легкостью преобразовывала формат данных в таблицах в формат, предлагаемый пользователю. Для этого может понадобиться создать и сопровождать материализованный представления таблиц отчетности. Это сопровождение является допоЛ'
разработка и реализация приложений
165
нительной работой, выполнять которую приходится базе данных, но она выполняется в пакетном режиме и не оказывает прямого влияния на конечных пользователей. С другой стороны, конечный пользователь выигрывает от возможности быстрее выполнять запросы. База данных в целом будет выполнять меньшее количество логических и физических считываний, поскольку обращения к базовым таблицам для заполнения и обновления материализованных представлений выполняются гораздо реже, чем запросы конечных пользователей к этим представлениям.
Избегайте повторных подключений к базе данных
Открытие подключения к базе данных может занять больше времени, чем выполняемые в рамках этого подключения команды. Если необходимо подключиться к базе данных, нужно сохранить подключение открытым и использовать его повторно. Для поддержания подключений на то время, пока выполняется обработка, в базе данных можно использовать хранимые процедуры, пакеты и прочие методы.
Один проектировщик приложений довел нормализацию до крайности, поместив все кодовые таблицы в собственную базу данных. В результате при выполнении большинства операций в системе обработки заказов (order-processing system) приходилось многократно открывать связи баз данных для получения доступа к кодовым таблицам, что значительно снижало производительность приложения. Настройка параметров инициализации базы данных в этом случае не в состоянии обеспечить значительный выигрыш в производительности; «торможение» приложения заложено на стадии проектирования.
Используйте «правильные» индексы
Пытаясь устранить физические считывания, некоторые проектировщики приложений создают множество индексов для каждой таблицы. Это отрицательно влияет на время загрузки данных, вдобавок, многие из этих индексов никогда не потребуются для поддержки запросов. В приложениях OLTP не следует использовать битовые (bitmapped) индексы; если в столбце содержится мало различных значений, стоит подумать, а не оставить ли этот столбец неиндексированным. Оптимизатор поддерживает доступ «skip-scan» к индексу, так что можно выбрать индекс по набору столбцов, даже если ведущий столбец индекса не является ограничивающим условием запроса.
Делайте все как можно проще
После устранения расходов на ненеобходимые логические считывания, не требующиеся походы в базу данных, неуправляемые подключения и не соответствующие делу индексы, всмотритесь попристальней в оставшиеся команды.
Упрощайте все «до атомов»
Для объединения многих шагов в один большой запрос можно использовать SQL. В некоторых случаях это приводит к выигрышу для приложения: можно создать хранимые процедуры и повторно использовать код,
166
Глава 5
что приведет к сокращению количества «пр ошествий» в базу данных. Од нако при этом можно зайти слишком далеко и создать чересчур большие запросы, которые не смогут завершиться за разумное время. Такие запросы, как правило, содержат несколько наборов операций группировки, встроенные представления (inline view) и сложные многострочные вычисления над миллионами строк.
Если выполняются пакетные операции, то сложный запрос можно разбить на атомарные компоненты и создать временные таблицы для хранения данных, полученных на каждом шаге запроса. Если приходится иметь дело с операцией, для завершения которой требуется несколько часов, то почти всегда можно найти способ разбить се на более мелкие компоненты. Разделяйте проблемы с производительностью, и вы получите над ними власть.
Например, пакетная операция может объединять данные из нескольких таблиц, выполнять соединения и сортировки, а затем вставлять результаты в таблицу. При небольших объемах обрабатываемой информации это может выглядеть вполне удовлетворительно. Но при переходе к большим объемам может понадобиться разделить эту операцию на несколько шагов:
1. Создайте рабочую таблицу, вставьте в нее строки из одной из исходных таблиц запроса, выбирая только те строки и столбцы, которые будут нужны впоследствии в процессе.
2. Создайте вторую рабочую таблицу для столбцов и строк второй таблицы.
3. Создайте любые требующиеся индексы для рабочих таблиц. До этого момента все предыдущие шаги могут быть выполнены параллельно — вставки, запросы к исходным таблицам и создание индексов.
4. Выполните соединение — снова параллельно. Выходные данные соединения могут быть помещены в другую рабочую таблицу.
5. Выполните все необходимые сортировки. Сортируйте как можно меньше данных.
6. Вставьте отсортированные данные в целевую таблицу.
Зачем нужны все эти шаги? Поскольку их можно настраивать индивН' дуально, появляется возможность настроить их таким образом, чтобы ка* ждый шаг завершался быстрее, чем Oracle могла бы завершить их как едИ' ное целое. Для пакетных операций следует попытаться сделать шаги как можно более простыми. Конечно, придется управлять дисковым пр° странством, выделяемым для рабочих таблиц, но этот подход может пр1^ вести к существенному выигрышу в производительности пакетной оора ботки.
Устраняйте необязательные сортировки
В последней части примера из предыдущего раздела выполнялись опер^ ции сортировки. Эти операции не годятся для приложений OLTP. Они тэгл^пятпятот пользователю никаких результатов до iex пор, пока не буДе^
разработка и реализация приложений
167
отсортирован весь набор строк. Но строковые операции возвращают пользователю строки, как только эти строки становятся доступны.
Рассмотрим следующий простой тест: выполним полное сканирование таблицы для большой таблицы. Как только запрос начнет выполняться, на экран будут выведены первые строки результата. А теперь выполним то же самое полное сканирование таблицы, добавив в запрос фразу order by для неиндексированного столбца. Пока не будут отсортированы все строки, па экран не будет выведено ни одной строки. Почему так происходит? Это связано с тем, что во втором запросе Oracle выполняет операцию SORT ORDER BY над результатами полного сканирования таблицы. Поскольку это операция над множествами (set operation), множество должно быть заполнено, прежде чем будет выполнена следующая операция.
Представим теперь приложение, в котором внутри процедуры выполняется много запросов. В каждом из запросов имеется фраза order by. Это превращается в ряд вложенных сортировок — ни одна из операций не может быть начата, пока не будет завершена одна из предыдущих операций.
Операции union выполняют сортировки. Если это не противоречит бизнес-логике, можно выполнять операцию union all вместо операции union, так как union all не выполняет сортировок (потому дубликаты не удаляются).
Примечание Операция union all не удаляет из результирующего множества повторяющиеся строки, так что в результате могут быть сгенерированы результаты, отличающиеся от результатов union.
Устраняйте необходимость в запросах к управляемым автоматически сегментам отката
Во время выполнения запроса Oracle требуется поддерживать согласованный по чтению образ строк, к которым делается запрос. Если строка модифицирована другим пользователем, базе данных придется сделать запрос к управляемому автоматически сегменту отката, чтобы увидеть строку в том виде, в котором она существовала к моменту начала запроса. Проекты приложений, где требуются запросы к данным частого доступа, которые могут быть в то же самое время изменены другими пользователями, вынуждают базу данных проделать даже еще больший объем работы — для получения одного фрагмента информации ей придется заглядывать в несколько различных мест. И снова все дело в проектировании. АБД могут сконфигурировать области автоматических сегментов отката так, чтобы уменьшить вероятность столкновения запросов с ошибочными ситуациями, но для корректировки фундаментальной проблемы требуется изменить проектное решение приложения.
Укажите базе данных, что ей необходимо знать
Работа оптимизатора Oracle, когда он оценивает тысячи возможных путей выполнения запроса, зависит от сооранных статистических показателей. Способ осуществления управления статистическими показателями может существенно повлиять на производительность запросов.
168
Гпава 5
Поддерживайте актуальность накапливаемых статистических показателей
Как часто необходимо вести сбор статистики? При каждом существенном изменении данных в таблицах следует проводить повторный анализ таблиц. Если таблица была разбита на разделы (секционирована), анализ можно проводить для каждого раздела по отдельности. Начиная с Oracle Database 10g, можно использовать опцию Automatic Statistics Gathering, обеспечивающую автоматическое накопление статистических данных. По умолчанию этот процесс собирает статистические показатели во время технологического окна каждую ночь в рабочие дни (от 6 ч вечера до 10 ч утра) и круглосуточно в выходные дни.
Поскольку обычно анализ является пакетным заданием, выполняемым в нерабочие часы, его можно настроить, повысив производительность сортировок и полных сканирований таблицы на уровне сеанса. Если анализ выполняется вручную, перед началом сбора статистических данных нужно увеличить установки параметров DBFILE MULTIBLOCKJREAD_COUNT и PGA_AGGREGATE_TARGET для вашего сеанса. Если параметр PGA_AGGREGATE_TARGET не используется, вместо него следует увеличить параметр SORT_AREA_SIZE. В результате будет улучшена производительность для всех сортировок и полных сканирований таблиц, выполняемых во время анализа.
Делайте подсказки там, где это требуется
В большинстве случаев основанный на стоимости оптимизатор (costbased optimizer — СВО) выбирает для запросов наиболее эффективный путь выполнения. Однако у вас может иметься информация о лучшем пути. Можно дать Oracle подсказку, оказывающую влияние на операции соединения, общую цель запроса, конкретные используемые индексы или на степень параллелизма запроса.
Максимизируйте пропускную способность среды
В идеальной среде никогда не возникает необходимости запрашивать информацию, не находящуюся в данный момент в буферном кэше; все данные постоянно остаются в оперативной памяти. Если только вы не работаете с очень маленькой базой данных, такой подход не является реалистичным. Ниже показано, как максимизировать пропускную способность среды.
Используйте кэширование дисков
Если Oracle не может найти требующиеся данные в кэше буферов илй в PGA, она выполняет физическое чтение. Но как много физических итс ний фактически доходит до обращения к диску? Если используется кэп* рование дисков, можно сделать так, чтобы 90% (или даже больше) запр сов на доступ к наиболее часто используемым блокам не приводив к обращению к диску. Если коэффициент попадания в кэш буферов баз!’ данных равен 90%, обращения к дискам составят всего 10% от общего личества запросов, а если кэширование дисков экономит еще 90% от это* ----------------------------------л, »,./-'кс\гКгЬ1ипиент попадания составит 99^’
разработка и реализация приложений
169
Внутренние статистические данные Oracle не отражают этого усовершенствования; для конфигурирования и мониторинга дисковых кэшей вам придется работать совместно с администраторами дисков.
Используйте больший размер блока базы данных
Есть всего одна причина, по которой не следует использовать для новой базы данных максимально допустимый в вашей среде размер блока данных: при этом становится невозможно поддерживать большое число пользователей, одновременно выполняющих операции обновления и вставки для одного и того же блока. Во всех остальных случаях увеличение размера блока базы данных должно привести к увеличению производительности почти всего приложения. Большие размеры блоков базы данных помогают не допустить расщепления уровней индексов и сохранить в (оперативной) памяти больше данных в течение большего времени. Если вы часто находитесь в состоянии активного ожидания (busy wait) освобождения буфера, увеличьте установки для параметра freelists на уровне объекта (если используется среда автоматического управления памятью, параметр freelists неприменим).
Эффективно храните данные на уровне блоков
В Oracle блоки данных хранятся в памяти. Нужно добиться того, чтобы эти блоки были максимально плотно «набиты» данными. Если хранение данных на уровне блоков неэффективно, не удастся получить того выигрыша, на который можно было бы рассчитывать для имеющихся в базе данных кэшей.
По умолчанию параметр pctused для всех блоков базы данных устанавливается равным 40, a pctfree —10. Если используются значения по умолчанию, то по мере добавления строк в таблицу они будут добавляться к блоку до тех пор, пока этот блок не станет полон на 90%; в этот момент блок будет удален из списка свободных блоков (freelist), а для последующих вставок будут использоваться другие блоки таблицы. При обновлении строк в блоке используется пространство, зарезервированное с помощью параметра pctfree. Строки могут быть удалены из блока, но в этом случае блок не будет возвращен в список свободных блоков до тех пор, пока использование пространства в блоке не упадет ниже значения pctused. Это означает, что если в приложении используется много операций insert и delete для строк, то достаточно часто приходится сталкиваться с ситуацией, когда в большом количестве блоков используется чуть-чуть больше пространства, чем задано в параметре pctused для каждого блока. В этом случае каждый блок используется всего на 40%, каждый блок из буферного кэша используется ровно на столько же, что приводит к существенному увеличению числа блоков, требующихся для завершения каждой команды. Если приложение выполняет много операций delete и insert, необходимо рассмотреть вопрос об увеличении значения pctused, чтобы можно было как можно скорее возвратить блоки в список свободных блоков.
Примечание Если используется технология Automatic Segment Space Management, значение pctused контролируется базой данных.
170
Гпава 5
Если установка pctused слишком низка, при обновлениях может получиться так, что Oracle будет вынуждена переносить строку (этот процесс называется миграцией строк). В некоторых случаях расщепление строк на несколько блоков (row chaining) может оказаться неизбежным, например, когда длина вставляемой строки превышает размер блока базы данных или когда в таблице оказывается более 254 столбцов. Когда происходит расщепление строк на несколько блоков и миграция строк, при каждом обращении к строке придется выполнить несколько обращений к блокам, что отразится на количестве логических считываний, требующихся для выполнения каждой команды. Обнаружить расщепление строк на несколько блоков можно путем анализа таблицы с последующей проверкой собранных статистических данных через представление USER_ TABLES.
Проектируйте пропускную способность, а не дисковую память
Возьмем приложение, которое выполняется на восьми 9-гигабайтных дисках, и перенесем его на один 72-гигабайтный диск. Станет ли от этого приложение работать быстрее или медленнее? Вообще говоря, оно должно начать работать медленнее^ маловероятно, что пропускная способность одного диска будет равна объединенной пропускной способности восьми отдельных дисков. Вместо того чтобы проектировать компоновку дисков, отталкиваясь от доступного пространства (общепринятая методика), проектируйте ее, базируясь на доступной пропускной способности дисков. Можно принять решение использовать только часть каждого диска. Оставшееся на диске пространство не будет использовано эксплуатируемым в промышленном режиме приложением до тех пор, пока не будет улучшена пропускная способность этого диска.
Избегайте использования временных сегментов
При каждой возможности выполняйте все сортировки в памяти. Любая операция, которая выполняет запись во временные сегменты, приводи r r L спвт арРА
к потенциально потерянным ресурсам. Когда параметр
SIZE (или PGA AGGREGATE TARGET, если он используется) не выдел* ет достаточно оперативной памяти для поддержки требований к сорт# ровке операций, Oracle использует временные сегменты. Операции сор тировки применяются при создании индексов, во фразах order by, сборе статистических данных, в операциях group by и при некоторых единениях. Необходимо постараться сортировать как можно меньшее личество строк. Сортировку того, что осталось, следует проводить в ративной памяти.
Выбирайте меньшее количество более быстрых процессоров
Если есть возможность выбора, предпочтительнее использоват ь шее число быстрых процессоров, чем большее число более медлен** процессоров. У операционной системы будет меньше очередей, коТ°Р ------------------------------.ПпрНис будет лучше выполняться.
разработка и реализация приложении
171
разделяйте свои данные и властвуйте над ними
Если не удается избежать выполнения дорогих операций с базой данных, можно попытаться разделить работу на несколько более управляемых частей. Часто удастся существенно ограничить число строк, на которые воздействует операция, что значительно повышает производительность.
Используйте разделы
Разделы могут обеспечить конечному пользователю, АБД и персоналу, занимающемуся поддержкой приложения, большой выигрыш. Для конечных пользователей наиболее важны два преимущества: повышение как производительности запроса, так и степени доступности базы данных. Производительность запроса может увеличиться благодаря так называемому устранению разделов (partition elimination). Оптимизатору известно, в каких именно разделах могут содержаться данные, затребованные запросом. В результате все остальные разделы, не участвующие в процессе, из него исключаются. Поскольку теперь требуется меньшее количество логических и физических считываний, запрос будет завершен быстрее.
Примечание Опция секционирования (разбиения на разделы — Partitioning Option) является приобретаемой за дополнительную плату опцией программного обеспечения базы данных для предприятий в целом (Enterprise Edition).
Доступность возрастает благодаря преимуществам, которые разделы генерируют для АБД и обслуживающего приложение персонала. Многие административные функции могут выполняться для отдельных разделов, что позволяет не оказывать никакого влияния на остальную часть таблицы. Например, можно провести очистку одного из разделов таблицы, расщепить раздел, перенести его в другое табличное пространство или подключить его к существующей таблице (т. е. сделать так, чтобы ранее независимая таблица стала считаться разделом). Можно по очереди собирать статистические данные для каждого из разделов. Все эти возможности сужают круг административных функций, уменьшая их влияние на доступность базы данных в целом.
Используйте материализованные представления
Для разделения типов операций, выполняемых пользователями над таблицами, можно использовать материализованные представления. При создании материализованного представления можно непосредственно предложить пользователю задать запрос к этому представлению или воспользоваться для этого имеющейся в Oracle возможностью перезаписи запроса. В результате мы имеем дело с двумя копиями данных, одна из которых обслуживает ввод новых транзакционных данных, а вторая (материализованное представление) — запросы. В результате появляется возможность перевести одну из них в автономный режим, не влияя на Доступность другой. Кроме того, с помощью материализованных представлений можно проводить предварительные соединение таблиц и генерирование агрегаций, чтобы запросы пользователей выполняли как можно меньше работы.
172
Гпава 5
Используйте параллелизм
Почти каждая основная операция — запросы и операции вставки, созда-ния объектов и загрузки данных — может быть распараллелена. Опции параллельного выполнения позволяют привлекать к участию в выполнении одной команды несколько процессоров, эффективно подразделяя эту команду на некоторое количество меньших по размеру скоординированных команд. В результате команда начинает выполняться лучше. Можно задать степень параллелизма на уровне объекта, и «перекрыть» (т. е. под-менить) ее с помощью включаемых в запросы подсказок.
Тестируйте правильно
В большинстве методологий разработки тестирование приложения разбивается на несколько фаз, к числу которых относится тестирование модулей (автономное), полное тестирование системы и тестирование производительности в предельных (стрессовых) режимах. Вследствие острой нехватки времени зачастую полное тестирование системы и тестирование производительности в предельных режимах выполнялись неадекватно, так как приложение было опасно близко к предельной дате его сдачи в эксплуатацию. В результате приложение сдается без каких бы то ни было гарантий того, что функциональные возможности и производительность приложения в целом будут удовлетворять потребностям пользователей. Это очень серьезный и существенный дефект разработчиков, и с ним не мирится ни один пользователь приложения. Пользователям недостаточно, чтобы удовлетворительно работал только какой-то один компонент приложения; им требуется, чтобы все приложение функционировало надлежащим образом. Если они не смогут за день выполнить намеченный объем работы, значит, приложение провалилось.
Таков основной принцип определения потребности в настройке приложений: если приложение уменьшает скорость бизнес-процесса, его необходимо настраивать. Выполняемые тесты должны быть в состоянии обнаружить, когда приложение становится препятствием к выполнению бизнес-прО' цесса в условиях прогнозируемой промышленной нагрузки.
Тестируйте на больших объемах данных
По прошествии времени объекты базы данных начинают функциониро' вать несколько по-другому. Например, установки параметров pctuse и pctfree могут сделать весьма вероятной ситуацию, когда блоки окажу1, ся используемыми только наполовину или когда строки будут расщепу ны между блоками. Каждая подобная ситуация приводит к проблемам производительностью, которые становятся заметными только п°с' того, как приложение будет использовано на протяжении некоторо времени.
Еще одна проблема с данными касается индексов. По мере роста ра мера индекса со структурой В-дерева он может претерпевать внутренН6^ расщепление — возрастает уровень входов внутри индекса. В результат можно показывать эти новые уровни как индекс внутри индекса. ДоП° нительные уровни индекса увеличивают негативный эффект влияния —„о чягпузки данных. Этот эффект нельзя обнаружить до
разработка и реализация приложений
173
пор, пока расщепление индекса не произойдет в реальности. Приложения, которые вполне удовлетворительно работали в промышленном режиме одну-две недели, вдруг начинают спотыкаться, когда объем данных достигает некоторого критического уровня, и перестают поддерживать производственные нужды. При тестировании ничем нельзя заменить реальные данные, загружаемые с реальными скоростями в таблицы, уже содержащие достаточно большой объем данных.
Тестируйте с большим числом одновременно работающих пользователей
Для большинства приложений баз данных тестирование при одном работающем пользователе не отражает ожидаемого использования приложения в промышленном режиме. Необходимо определить, сталкиваются ли одновременно работающие пользователи с такими явлениями, как взаимные блокировки (deadlocks), вопросы согласованности данных или проблемы с производительностью. Предположим, что модуль приложения использует рабочую таблицу при обработке данных. Строки вставляются в таблицу, с ними выполняются некоторые манипуляции, а затем к ним делается запрос. Другой модуль приложения выполняет аналогичную обработку и при этом использует ту же самую таблицу. Если эти два процесса будут использоваться в одно и то же время, они будут пытаться использовать принадлежащие друг другу данные. Если не проводить тестирование в среде, где множество пользователей одновременно выполняют многие функции приложения, эту проблему будет невозможно обнаружить, а вместе с ней и те ошибки в данных, которые она порождает.
Кроме того, тестирование в среде множества одновременно работающих пользователей помогает идентифицировать области приложения, где пользователи часто используют управляемые автоматически сегменты отката для завершения своих запросов, оказывая тем самым влияние на производительность.
Протестируйте влияние индексов на время загрузки
Каждая операция insert, update или delete, выполняемая над проиндек-сированным столбцом, может быть более медленной, чем аналогичная операция, выполняемая над неиндексированной таблицей. Имеются некоторые исключения — так, отсортированные данные оказывают меньшее влияние на время загрузки, но, вообще говоря, это правило справедливо. Степень влияния зависит от операционной среды, участвующих структур данных и степени упорядоченности данных.
Как много строк в секунду можно вставить в вашей среде? Выполните ряд простых тестов. Создайте таблицу без индексов и вставьте в нее большое количество строк. Повторите тесты для уменьшения влияния физических считываний на результаты хронометража. Вычислите количество вставленных за секунду строк. Для большинства сред за одну секунду в базу данных можно вставить десятки тысяч строк. Выполните тот же самый эксперимент с другими средами баз данных, чтобы можно было выделить среду, значительно отличающуюся от всех остальных.
Теперь рассмотрим приложение. Сможете ли вы вставлять строки в таблицы с помощью приложения со скоростью, близкой к только что вычисленной? Многие приложения работают со скоростью, не превы
174
Гпава 5
шающей 5% скорости, поддерживаемой средой. Приложения «вязнут» в не являющихся обязательными индексах или в описанных выше в этой главе вопросах проектирования кода. Если скорость загрузки приложения уменьшается (например, от 40 до 20 строк в секунду), то при настройке необходимо выяснить не только то, почему происходит снижение скорости загрузки, но и то, как приложение умудрялось загружать только по 40 строк в секунду в среде, которая способна поддерживать вставку нескольких тысяч строк в секунду.
Сделайте все тесты воспроизводимыми
У наиболее «зарегулированных» отраслей имеются стандарты тестирования. Эти стандарты настолько разумны, что буквально все усилия по тестированию должны им следовать. Чтобы соответствовать требованиям стандартов, необходимо иметь возможность повторно создавать используемый тестовый набор данных, повторять выполняемые действия, точно воспроизводить, показывать и записывать ожидаемые результаты. Тесты, предшествующие промышленной эксплуатации, должны выполняться на том же аппаратном обеспечении, которое будет применяться в промышленной среде. При переносе приложений на другое оборудование требуется заново протестировать его. Все эти тесты должны быть подписаны тестерами и конечными бизнес-пользователями.
Большинство читателей, узнав об этих ограничениях, согласятся, что это хорошие шаги, которые должны быть предприняты в рамках любого процесса тестирования. Конечно, бизнес-пользователи могут ожидать, что люди, разрабатывавшие приложение, следуют таким стандартам, даже если они и не являются обязательными в их отрасли. Но выполняются ли они на самом деле? А если нет, то почему? Двумя наиболее часто повторяемыми причинами, из-за которых такие стандарты не соблюдаются, называют нехватку времени и расходы. Для подобных тестов требуется планирование, кадровые ресурсы, вовлечение в тестирование бизнес-пользователей и время на его проведение и документирование. Тестирование на оборудовании промышленного масштаба тдожет потребовать приобретения дополнительного оборудования. Это только наиболее очевидные расходы, но во сколько обойдется неудачное проведение таких тестов? Требования к тестированию для так называемых «подтвержденных» (validated) систем в некоторых областях здравоохранения были внедрены по той причине, что эти системы непосредственно влияют на целостность таких важных продуктов, как безопасность кровоснабжения, ли у бизнеса имеются критичные компоненты, обслуживаемые вашим приложением (а если их нет, то зачем тогда строить приложение?), необходимо рассмотреть расходы на недостаточное быстротечное тестирование и сообщить их бизнес-пользователям приложения. В оценке рисков от исполь зовапия некорректных данных или от неприемлемо низкой производи телыюсти должны участвовать и бизнес-пользователи. В свою очередь» они могут добиться переноса даты сдачи приложения на более поздниИ срок, чтобы поддержать проведение надлежаще о тестирования.
Во многих случаях слишком короткий цикл тестирования связан с тем, что к моменту запуска проекта стандарты тестирования отсутствовали-Если бы в то время, когда проект еще только запускался, был в наличии
разработка и реализация приложений
непротиворечивый, тщательный и хорошо документированный стандарт тестирования для предприятия в целом, выполнение цикла тестирования потребовало бы меньше времени, чем тогда, когда о тестировании заходит речь в самом конце проекта. Тогда тестеры заранее знали бы о том, что им для работы потребуется воспроизводимый набор исходных данных. Имелись бы в наличии шаблоны для тестов. Если бы возникла проблема с результатами какого-то теста или если бы приложению понадобилось бы повторить тестирование вследствие внесения в пего изменений, тест мог бы быть всегда воспроизведен. Кроме того, пользователи приложения знали бы, что тестирование достаточно надежно в плане эмуляции промышленного использования приложения. Если система не справляется с тестами с точки зрения производительности, проблема может оказаться связанной с вопросами проектирования (см. выше) или с индивидуальным запросом.
Стандартный комплект поставки
Как узнать, готово ли приложение к переносу в промышленную среду? Методология разработки приложений должна четко определять (как по формату, так и по уровню детализации) требующиеся результаты для каждой стадии цикла жизни приложения. Сюда должны быть включены спецификации по каждому из следующих вопросов:
Диаграмма отношений логических объектов
Диаграмма физической базы данных
Требования к дисковому пространству
Задачи настройки для обработки запросов и транзакций
Требования безопасности
Требования к данным
Планы выполнения запросов
Процедуры приемочных испытаний
Диаграмма отношений логических объектов
Диаграмма отношений логических объектов (Entity Relationship Diagram — E-R) иллюстрирует отношения, идентифицированные между сущностями, из которых построено приложение. Диаграммы E-R критичны для обеспечения понимания целей системы. Кроме того, они помогают идентифицировать точки интерфейса с другими приложениями и гарантировать согласованность определений в рамках предприятия.
Диаграмма физической базы данных
Диаграмма физической базы данных отобиажает физические таблицы, сгенерированные из сущностей, и столбцы, сгенерированные из атрибутов логической модели. Инструменты для построения диаграмм физической базы данных обычно имеют возможность генерировать DDL, необходимые для создания объектов приложения.
Эту диаграмму можно использовать для идентификации таблиц, которые с наибольшей вероятностью будут участвовать в транзакциях. Кроме
176
Гпава 5
того, необходимо идентифицировать, какие таблицы будут обычно использоваться вместе во время операций ввода данных или запросов. Эту информацию можно использовать для эффективного планирования распределения таблиц (и их индексов) по всем имеющимся физическим устройствам для уменьшения количества встречающихся при работе конфликтов ввода/вывода.
В приложениях для работы с хранилищами данных диаграмма физической базы данных должна показывать агрегации и материализованные представления, к которым обращаются запросы пользователей. Хотя они содержат выводимые (производные) данные, они являются критичными компонентами пути доступа к данным и должны быть документированы.
Требования к дисковому пространству
Формулирование требований к дисковому пространству должно отражать первоначальные требования к этому пространству для каждой таблицы или индекса базы данных. (О рекомендациях по выбору надлежащего размера таблиц, кластеров и индексов см. ниже в разделе «Определение размера объектов базы данных».)
Задачи настройки для обработки запросов и транзакций
Изменения в проекте приложения могут оказать существенное влияние на его производительность. Выбор проектного решения приложения может также непосредственно влиять на возможности его настройки. Поскольку выбор проектного решения приложения оказывает такое огромное влияние на возможности^ АБД настраивать производительность приложения, АБД должен быть привлечен к работе над приложением еще на стадии проектирования.
Требования к производительности системы необходимо выяснить еще до передачи приложения в промышленную эксплуатацию. При этом нельзя переоценить роль ожиданий в оценке системы. Например, если пользователи ожидают, что система будет работать так же быстро, как и существующая, то все более медленное будет неприемлемо. Необходимо определить и утвердить ожидаемое время ответа для каждого компонента приложения, используемого чаще всего.
При этом следует определить цели двух типов: реальные и возможные. Возможные задачи отражают результат концентрации усилий на преодолении программных и аппаратных ограничений, сдерживающих производительность системы. Определение двух типов задач по повышению производительности позволяет сфокусировать усилия на достижении целей, которые по-настоящему критичны, а не тех, что находятся за пределами возможностей компонентов системы. Относительно этих задан нужно установить границы управления для производительности запросов и транзакций: при выходе за эти границы производительность приложения будет считаться «неуправляемой».
Требования безопасности
Команда разработчиков должна определить структуру учетных записей, которую будет использовать приложение. При этом необходимо установить владельцев всех объектов и способ предоставления привилегий.
разработка и реализация приложений
177
Нужно четко определить все роли и привилегии. Ожидаемые результаты этого этапа буду!' использоваться для генерации структуры учетных записей и привилегий промышленного приложения (полный обзор возможностей по обеспечению безопасности, предоставляемых Oracle, см. в главе 10).
Для некоторых приложений нужно определять по отдельности способы использования пакетных и оперативных учетных записей. Например, в пакетных учетных записях может использоваться возможность автоматической регистрации, а онлайновые пользователи должны делать это вручную. Планы по обеспечению безопасности приложения должны иметь возможность поддерживать оба типа пользователей.
Как и при планировании дискового пространства, участие администратора БД в планировании ее безопасности чрезвычайно важно. Он должен иметь возможность спроектировать реализацию, отвечающую требованиям приложения, вписываясь вместе с тем в план обеспечения безопасности баз данных всего предприятия.
Требования к данным
Необходимо четко определить методы ввода и извлечения данных. Методы ввода данных следует проверить на этапе тестирования. Нужно документировать все специальные требования к архивированию данных приложения, поскольку они специфичны для конкретного приложения.
Определив требования по резервному копированию и восстановлению данных приложения, их можно затем сравнить с планами по резервному копированию базы данных сайта (см. главу 12). Любые требования по восстановлению базы данных, превосходящие стандарты сайта, должны привести к изменению этих стандартов или добавлению модуля, учитывающего потребности приложения.
Планы выполнения запросов
Планы выполнения — это последовательность действий базы данных при обработке запросов. Они генерируются с помощью команд explain plan или set autotrace (см. главу 8). Регистрация планов выполнения наиболее важных для базы данных запросов позволяет спланировать использование индексов и задачи настройки приложения. Генерация этих планов до ввода системы в промышленную эксплуатацию упростит работу по настройке системы, а возможные проблемы производительности будут определены до выпуска приложения. Генерация планов объяснения облегчает также анализ кода приложения.
При внедрении приложений сторонних производителей АБД может не иметь доступа ко всем командам SQL, которые генерирует данное приложение. Для мониторинга наиболее интенсивных (в отношении ресурсов) запросов, выполняемых между двумя моментами времени, можно использовать утилиту STATSPACK (см. главу 9). Можно сделать моментальный снимок STATSPACK перед началом периода тестирования и после его окончания, а затем оценить пути исполнения для наиболее распространенных и наиболее интенсивных запросов. Подробнее о пакете STATSPACK см. главу 9; там же рассказывается об использовании репозитория, впервые появившегося в Oracle Database 10g.
178
Гпава 5
Процедуры приемочных испытаний
До передачи системы в производство разработчики и пользователи должны четко определить, какая функциональность и производительность системы должна быть достигнута. Эти цели лежат в основе процедур, которые необходимо провести, пока приложение еще находится в тестовой среде.
Процедуры должны также описывать, что делать с невыполненными задачами. В этих процедурах должны быть очень четко определены функциональные цели, которые должны быть решены, прежде чем система сможет двигаться дальше. Следует разработать и список некритичных задач. Такое разделение функциональных возможностей позволит решить конфликты при планировании и структурировать соответствующие тесты.
Примечание В качестве части процедуры приемочных испытаний все интерфейсы приложения должны быть протестированы, а их входные и выходные данные проверены.
Управление ресурсами и хранимые схемы плана выполнения
Можно использовать хранимые схемы планов выполнения для переноса путей выполнения между экземплярами. Кроме того, можно использовать диспетчер ресурсов базы данных (Database Resource Manager) с целью контроля распределения системных ресурсов между пользователями базы данных. Хранимые схемы планов выполнения и управление ресурсами являются важными компонентами в управляемой среде разработки. Диспетчер ресурсов базы данных позволяет администратору распределять системные ресурсы эффективнее, чем только с помощью средств операционной системы.
Примечание Начиная с Oracle 10ff, для дальнейшего уточнения выбранных путей выполнения можно использовать профили SQL.
Реализация диспетчера ресурсов базы данных
С помощью диспетчера ресурсов базы данных г.ожнс выделять классам пользователей и заданиям системные ресурсы (в процентах). Например, 75% доступных ресурсов центрального процессора можно предоставить онлайновым пользователям, а 25% — пакетным. Для того чтобы можно было воспользоваться диспетчером ресурсов БД, нужно создать планы ресурсов, группы потребителей ресурсов и директивы плана ресурса.
Перед использованием команд диспетчера ресурсов базы данных нужно создать «область задержки» с помощью процедуры CREATE^. PENDING_AREA, входящей в состав модуля DBMSRESOURCE^ MANAGER. После завершения сделанных изменений с помощью процедуры VALIDATE-PENDING-AREA следует проверить допустимость новых наборов планов, подпланов и директив. Затем с помощью процедуры
разработка и реализация приложений
179
SUBMIT-PENDING-AREA можно отправить изменения па выполнение, а с помощью CLEAR_PENDING_AREA — отменить их. Процедуры управления областью задержки не требуют каких-либо переменных, так что синтаксис создания такой области будет следующим:
□ execute DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA ();
Если область задержки не была создана ранее, при попытке создать план ресурса будет получено сообщение об ошибке.
Для создания плана ресурса нужно воспользоваться процедурой CREATE_PLAN пакета DBMS_RESOURCE_MANAGER. Ниже приведен синтаксис процедуры CREATE_PLAN:
□ CREATE_PLAN
(plan IN VARCHAR2,
comment IN VARCHAR2,
cpujnth IN VARCHAR2 DEFAULT
‘EMPHASIS’ ,
active_sess_pool_mth IN*VARCHAR2 DEFAULT
‘ ACTIVE_SESS_POOL_ABSOLUTE’,
parallel_degree_limit__mth IN VARCHAR2 DEFAULT
‘ PARALLEL_DEGREE_LIMIT_ABSOLUTE’,
queueing_mth IN VARCHAR2 DEFAULT
‘ FIFOJTMEOUT’ )
При создании плана ресурса нужно задать плану имя (в переменной plan) и комментарий. По умолчанию при распределении ресурсов центрального процессора используется метод «выделения» («emphasis»); при этом распределение задается в процентах. В следующем примере показано создание плана с именем DEVELOPERS:
□ execute DBMS_RESOURCE_MANAGER.CREATE_PLAN -
(Plan => 'DEVELOPERS’, -
Comment => ‘Разработчики, в базе данных для разработки’);
Примечание Знак дефиса (-) в SQL*Plus является символом продолжения и позволяет размещать одну команду на нескольких строках.
Для того чтобы можно было создавать планы ресурсов и управлять ими, а также группами потребителей ресурсов, для сеанса должна быть активизирована привилегия ADMINISTERJIESOURCEJ4ANAGER. У администраторов есть такая привилегия с возможностью администрирования (with admin option). Чтобы назначить эту привилегию кому-либо другому, выполните процедуру GRANT_SYSTEM_PRIVILEGE из модуля DBMS-RESOURCE. MANAGER PRIVS. В следующем примере пользователю MARTHA назначается право управления инструментом Database Resource Manager:
о execute DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE -(grantee_name => ‘Martha’, -
privilege_name => ‘ADMINISTER_RESOURCE_MANAGER’, -admin_option => TRUE);
180
Гпава 5
Затем привилегии пользователя MARTHA можно отменить с помощью процедуры REVOKE_SYSTEM__PRIVILEGE из пакета DBMS-RESOURCEJVIANAGER.
Имея привилегию ADMNISTER_RESOURCE_MANAGER, можно создать группу потребителей ресурсов с помощью процедуры CREATE-CONSUMER_GROUP пакета DBMS_RESOURCE_MANAGER. Синтаксис этой процедуры описан в приведенном ниже листинге:
П CREATE_CONSUMER_GROUP
(consumer_group IN VARCHAR2,
comment IN VARCHAR2,
cpujnth IN VARCHAR2 DEFAULT ‘ROUND-ROBIN’)
Поскольку в группы потребителей ресурсов будут включены пользователи, нужно дать этим группам имена, основанные на логическом разделении пользователей предприятия. В следующем примере описано создание двух групп — одной для онлайновых, а другой для пакетных пользователей:
П execute DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP -(Consumer_Group => ‘Online_devblopers’, -
Comment => ‘Онлайновые разработчики’);
execute DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP -(Consumer_Group => ‘Batch_developers’, -
Comment => ‘Пакетные разработчики’);
После установления плана и группы потребителей ресурсов нужно создать директивы плана ресурсов и включить пользователей в группы потребителей ресурсов. Для назначения директив плану следует воспользоваться процедурой CREATE_PLAN_DIRECTIVE пакета DBMS-RESOURCE-MANAGER. Ниже приводится синтаксис этой процедуры:
П CREATE_PLAN_DIRECTIVE
(plan
group_or_subplan
comment
cpu_p1
cpu_p2 cpu_p3 cpu_p4 cpu_p5 cpu_p6 cpu_p7 cpu_p8 active_sess_pool_p1 queueing_p1
parallel_degree_limit_p1 switch_group
switch_time switch_estimate max_est_exec_time
IN VARCHAR2,
IN VARCHAR2,
IN VARCHAR2,
IN NUMBER DEFAULT NULL,
IN NUMBER DEFAULT NULL,
IN NUMBER DEFAULT NULL,
IN NUMBER DEFAULT NULL,
IN NUMBER DEFAULT NULL,
IN NUMBER DEFAULT NULL,
IN NUMBER DEFAULT NULL,
IN NUMBER DEFAULT NULL,
IN NUMBER DEFAULT UNLIMITED,
IN NUMBER DEFAULT UNLIMITED,
IN NUMBER DEFAULT NULL,
IN VARCHAR2 DEFAULT NULL,
IN NUMBER DEFAULT UNLIMITED
IN BOOLEAN DEFAULT FALSE,
IN NUMBER DEFAULT UNLIMITED,
разработка и реализация приложений
181
undo_pool IN NUMBER DEFAULT UNLIMITED,
max_idle_time IN NUMBER DEFAULT NULL,
max_idle_time blocker IN NUMBER DEFAULT NULL,
switch_time_in_call IN NUMBER DEFAULT NULL);
В процедуре CREATE_PLAN_DIRECTIVE несколько переменных CPU поддерживают создание различных уровней выделения ресурсов процессора. Например, 75% этих ресурсов (уровень 1) можно назначить онлайновым пользователям. Половину оставшихся ресурсов (уровень 2) можно назначить второй группе пользователей, а остаток выделить нескольким группам на третьем уровне. Процедура CREATE_PLAN_DIRECTIVE поддерживает до восьми уровней выделения ресурсов процессора.
Следующий пример иллюстрирует создание директив плана для двух групп потребителей ресурсов — онлайновых разработчиков (Online_ developers) и пакетных разработчиков (Batch_developers) в плане ресурсов DEVELOPERS:
□ execute DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE -
(Plan => ‘DEVELOPERS’, -
Group_or_subplan => ‘Online_developers’, -
Comment => ‘Онлайновые разработчики’, -
Cpu_p1 => 75, -
Cpu_p2 => 0, -
Parallel_degree_limit_p1 => 12);
execute DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE -
(Plan => ‘DEVELOPERS’, -
Group_or_subplan => ‘Batch_developers’, -
Comment => ‘Пакетные разработчики’, -
Cpu_p1 => 25, -
Cpu_p2 => 0, -
Parallel_degree_limit_p1 => 6);
Помимо выделения ресурсов процессора, директивы плана ограничивают параллелизм операций, выполняемых участниками групп потребителей ресурсов. В предыдущем примере степень параллелизма пакетных разработчиков ограничена числом 6, что уменьшает их возможность потреблять ресурсы системы. Степень параллелизма онлайновых разработчиков равна 12.
Для включения пользователя в группу потребителей ресурсов используется процедура SETJNITIAL_CONSUMER_GROUP пакета DBMS_ RESOURCEJMANAGER. Ее синтаксис описан в следующем листинге: SET_INITAL_CONSUMER_GROUP
(user IN VARCHAR2,
consumergroup IN VARCHAR2)
Если пользователь никогда не был включен в первоначальную группу потребителей с помощью процедуры SET_INITALCONSUMER_GROUP, он по умолчанию будет входить в группу DEFAULT CONSUMER_GROUP.
Для активизации диспетчера ресурсов нужно задать параметр инициализации базы данных RESOURCE_MANAGER_PLAN для имени плана ре
182
Гпава 5
сурса экземпляра. Поскольку планы ресурсов могут иметь подпланы, есть возможность создавать уровни выделений ресурсов впугри экземпляра. Если значение параметра RESOURCE_MANAGER_PLAN не определено, в этом экземпляре управление ресурсами не осуществляется.
Конструкция set initial_consumer_group команды alter system позволяет динамически изменить экземпляр, используя другой план выделения ресурса. Например, можно создать план ресурса для дневных пользователей (DAYTIME_USERS) и для пакетных пользователей (BATCH USERS). Затем можно создать задание, которое каждый день в шесть часов утра будет выполнять следующую команду:
□ alter system set initial_consumer_group = ‘DAYTIME_USERS’;
В заданное вечернее время можно сменить группу потребителей на группу пакетных пользователей:
□ alter system set initial_consumer_group = ‘BATCH_USERS’;
Таким образом, план выделения ресурсов для экземпляра будет изменяться динамически без необходимости остановки и перезапуска экземпляра.
При подобном использовании нескольких планов выделения ресурсов необходимо следить за тем, чтобы в нужное время активизировать нужный план. Если в момент запланированного изменения плана база данных не работает, задание, осуществляющее это изменение, может оказаться невыполненным. При использовании нескольких планов выделения ресурсов необходимо учитывать последствия применения не того плана не в то время. Чтобы избежать проблем, постарайтесь уменьшить до минимума количество используемых планов.
Помимо описанных здесь команд и примеров, можно обновлять имеющиеся планы ресурсов (процедура UPDATE. PLAN), удалять их (DELETE, PLAN), а также «каскадно» удалять план ресурса со всеми его подпланами и связанными с ним группами потребителей ресурсов (DELETE_PLAN, ' CASCADE). Группы пользователей ресурсов обновляются и удаляются с помощью процедур UPDATE_CONSUMER_GROUP и DELETE_CONSUMER__ GROUP соответственно. Для обновления директив плана ресурсов используется процедура UPDATE_PLAN_DIRECTIVE, а для удаления — DELETE, PLANJDIRECTIVE.
Изменив план ресурса, группу пользователей ресурса и его директивы, нужно перед реализацией изменений проверить их. Для этого надо создать область задержки с помощью процедуры CREATE_PENDING_AREA из пакета DBMS_RESOURCE_MANAGER. Завершив изменения, следует проверить допустимость нового набора планов, подпланов и директив с помощью процедуры VALIDATE_PENDING_AREA. Затем можно либо от править изменения на выполнение (SUBMIT_PENDING_AREA), либо очистить область задержки (CLEAR_PENDING_ AREA). Процедуры рабо ты с областью задержки не требуют никаких параметров, так что провер ка на допустимость или отправка на выполнение используют следующий синтаксис:
П execute DBMS_RESOURCE_MANAGER VALIDATE_PENDING_AREA (); ovoph+p ORMS RESOURCE MANAGER.SUBMIT_PENDING_AREA ();
разработка и реализация приложений
183
Переключение групп потребителей
Три параметра процедуры CREATE_PLAN_DIRECTIVE позволяют работающим сеансам переключать группы потребителей ресурсов, когда достигаются предельные значения ресурсов. В число параметров процедуры CREATE_PLAN_DIRECTIVE входят Switch_Group, Switch_Time и Switch-Estimate.
Значение Switch_Time представляет время (в секундах), в течение которого задание может выполняться, прежде чем оно будет переключено в другую группу потребителей. По умолчанию значением Switch-Time является NULL (т. е. неограниченное время). Параметр Switch_Group устанавливается на номер группы, в которую будет включен сеанс после того, как будет достигнут предел времени выполнения сеанса. По умолчанию Switch_Group устанавливается на NULL. Если Switch_Group будет установлен на значение ‘CANCEL_SQL’, при выполнении критерия переключения текущий вызов будет аннулирован. Если значение Switch_Group равно ‘KILL_SESSION’, при выполнении критерия переключения сеанс будет «убит».
Параметр Switch-Estimate можно использовать для указания базе данных, что группу потребителей для базы данных нужно переключить перед выполнением операции. Если установить Switch Estimate на TRUE, Oracle будет использовать для автоматического переключения группы потребителей оценочное время выполнения операции, вместо того чтобы ожидать, пока будет превзойдено пороговое значение, установленное значением Switch_Time.
Можно использовать опции переключения групп потребителей для минимизации влияния долго выполняющихся в базе данных заданий. Можно сконфигурировать группы потребителей с различными уровнями доступа к системным ресурсам и настроить их для поддержки «быстрых» заданий, а также для поддержки долго выполняющихся заданий; задание, достигшее порога переключения, будет автоматически перенаправлено в соответствующую подходящую группу, даже еще не начав выполняться.
Реализация хранимых схем плана выполнения
При миграции из одной базы данных в другую пути выполнения запросов могут измениться по следующим причинам:
В разных базах данных могут быть использованы различные опции оптимизатора.
В разных базах данных статистические данные для таблиц, к которым делается запрос, могул' быть различными
В разных базах данных может различаться частота сбора статистических данных.
В базах данных могут выполняться различные версии ядра Oracle.
Эти различия могут оказывать чрезвычайно сильное влияние на пути выполнения запросов, а также отрицательное влияние на производительность запросов при переходе к новому приложению или при модернизации существующего. Чтооы свести к минимуму эффект влияния подобных различий на производительность, можно использовать опцию, получившую название «хранимые схемы планов выполнения».
184
Гпава 5
В хранимых схемах плана выполнения содержатся подсказки (реко-мендации — hints) по обработке запросов. Эти подсказки будут использо-ваться при каждом выполнении запроса. Применение хранимых подсказок повысит вероятность того, что путь выполнения запроса во всех случаях останется прежним. Рекомендации позволяют уменьшить влияние перехода к другой базе данных на производительность обработки запроса. Схемы и связанные с ними рекомендации можно просмотреть с помощью представлений USER_OUTLINES и USER_OUTLINE_HINTS.
Чтобы можно было начать создавать рекомендации по обработке запросов, следует создать свои собственные пользовательские категории схем и использовать их имена как значение параметра CREATE STORED_OUTLINES файла инициализации базы данных:
□ CREATE_STORED_OUTLINES = development
В этом случае хранимые схемы плана выполнения запросов будут сохраняться в категории DEVELOPMENT.
Для создания хранимого плана выполнения запроса нужно иметь привилегию CREATE ANY OUTLINE. Схема запроса создается с помощью команды create outline:
□ create outline YTD_SALES for category DEVELOPMENT on
select Year_to Date_Sales from SALES
where region = ‘SOUTH’ and period = 1;
Примечание Если имя схемы не определено, оно будет сгенерировано системой.
Если значение параметра CREATE_STORED__OUTLINES в файле инициализации установлено равным имени категории, Oracle создаст хранимые планы выполнения запросов; использование команды create outline дает больше контроля над создаваемыми схемами.
Примечание Можно создавать схемы для команд DML и create table as select.
Созданный хранимый план выполнения можно изменить. Такая необходимость возникает, например, из-за значительных изменений в объеме и распределении данных. Для регенерации рекомендаций, применяемы при исполнении запросов, используется фраза rebuild команды alter outline:
□ alter outline YTD_SALES rebuild;
Хранимый план выполнения можно также переименовать с помощь10 фразы rename команды alter outline:
□ alter outline YTD_SALES rename to YTD_SALES_REGION,
разработка и реализация приложений
185
Категорию хранимого плана выполнения можно изменить с помощью фразы change category:
□ alter outline YTD_SALES_REGION change category to DEFAULT;
Для управления хранимыми схемами плана выполнения используется пакет DBMS_OUTLN. Он позволяет:
Удалять неиспользуемые хранимые планы выполнения
в Удалять хранимые планы выполнения из указанной категории
и Перемещать хранимые планы выполнения из одной категории в другую
Создавать хранимые планы выполнения для конкретных операторов
Обновлять хранимые планы выполнения до сигнатуры текущей версии
Для реализации каждой из этих возможностей в пакете DBMS_ OUTLN существует соответствующая процедура. Например, неиспользуемые схемы удаляются с помощью процедуры DROP_UNUSED:
□ execute DBMS OUTLN.DROP UNUSED;
Для хранимого плана выполнения можно использовать установку «used» для процедуры CLEAR_USED. Передайте имя хранимого плана выполнения как входную переменную для процедуры CLEAR_USED:
□ execute DBMS_OUTLN.CLEAR_USED(1YTD_SALES_REGION’);
Для удаления всех хранимых планов выполнения из категории выполняется процедура DROP_BY_CAT. В качестве своего единственного параметра она принимает имя категории. В следующем примере показано удаление всех хранимых планов выполнения из категории DEVELOPMENT:
П execute DBMS_OUTLN.DROP BY_CAT(‘DEVELOPMENT’);
Для переназначения хранимых планов выполнения из старой катего-рии в новую нужно использовать процедуру UPDATE_BY_CAT:
о execute OUTLNPKG.UPDATE-BY_CAT -
(Oldcat => ‘DEVELOPMENT’, -
newcat => ’TEST’);
Для удаления конкретного хранимого плана выполнения использует-ся команда drop outline.
Если хранимые планы выполнения были импортированы из одного из предыдущих релизов, нужно использовать процедуру UPDATE_
GNATURES из пакета DBMS_OUTLN; это гарантирует, что сигнатуры совместимы с алгоритмами вычисления текущего релиза.
Редактирование хранимых схем плана выполнения
Для редактирования хранимых схем плана выполнения можно использовать пакет DBMS—OUTLN—EDIT. Процедуры из этого пакета перечисля-ются в следующей таблице:
186
Гпава 5
Процедура
CHANGE-JOIN—POS
CREATE_EDIT_TABLES
DROP_EDIT_TABLES
GENERATE.SIGNATURE
REFRESH_PRIVATE_OUTLINE
Описание
Изменяет позиции соединения для подсказок, идентифицируемых именем хранимого плана выполнения и номера подсказки, в указанную позицию. Входные параметры —имя, номер_подсказки и нов_поз.
Создает таблицы редактирования хранимого плана выполнения в схеме пользователя.
Удаляет таблицы редактирования хранимого плана выполнения из схемы пользователя.
Генерирует сигнатуру для конкретного текста SQL
Обновляет находящуюся в оперативной памяти копию хранимого плана выполнения, синхронизируя ее с внесенными изменениями.
Примечание Начиная с Oracle 10ff, более не требуется выполнять процедуру CREATE_EDIT_TABLES, потому что редактируемые таблицы доступны как временные таблицы в схеме SYSTEM. Однако процедура по-прежнему остается доступной для обеспечения обратной совместимости.
Можно использовать приватные хранимые планы выполнения, которые будут видны только текущему сеансу. Изменения, внесенные в приватный хранимый план выполнения, не влияют па других конечных пользователей. Для активации редактирования приватных хранимых планов выполнения нужно установить параметр инициализации USE_PRIVATE__ OUTLINES на TRUE. Чтобы сделанные изменения вошли в силу для хранящихся в оперативной памяти хранимых планов выполнения, следует использовать процедуру REFRESH JPRIVATE_OUTLINE.
Использование профилей SQL
Начиная с Oracle 10g, стало возможно использовать профили SQL для дальнейшего уточнения выбранных оптимизатором планов выполнения операторов SQL. Профили SQL особенно полезны при попытках настроить код, к которому нет прямого доступа (например, из пакетированного приложения). Профиль SQL состоит из статистических данных, которые являются индивидуальными для оператора и позволяют оптимизатору больше узнать о точной избирательности и стоимости шагов плана вы полнения.
Профилирование SQL является частью описивгемой в главе 8 опций автоматической настройки. После того, как будет принята рекомендация профиля SQL, он сохраняется в словаре данных. Как и в случае хранимы-схем планов выполнения, для контроля использования этого профиЯ ~ можно использовать атрибут категории (подробнее об использовании ав томатических инструментальных средств для обнаружения и диагност ки вопросов производительности SQL см. главу 8).
разработка и реализация приложений
187
Определение размера объектов базы данных
Чрезвычайно важно правильно выделить место для объектов базы данных. Разработчики должны оценить требования к дисковому пространству еще до создания первого объекта. Впоследствии эти требования необходимо обновлять, основываясь на статистике фактического использования.
Примечание При создании табличного пространства можно активировать средство автоматического управления пространством в сегментах; для уже существующих табличных пространств это средство активировать нельзя. Если это средство используется, то Oracle берет на себя управление параметрами pctused, freelists и freelist groups. х
_____________________________________________________________________________
Зачем нужно определять размеры объектов
Размеры объектов базы данных нужно определять по трем причинам:
Для предварительного выделения места в базе данных, уменьшая тем самым объем будущей работы, необходимой для управления требованиями к пространству для объектов
Для уменьшения объема пространства на диске, растрачиваемого впустую из-за избыточного выделения места
Для повышения вероятности повторного использования удаленных свободных экстентов другим сегментом
Для достижения этих целей нужно следовать методике определения размеров (см. ниже). Эта методика основывается на внутренних способах, с помощью которых Oracle выделяет дисковое пространство объектам базы данных. Она использует не подробные вычисления, а приближение (аппроксимацию), что чрезвычайно упрощает процесс определения размеров и в то же самое время упрощает управляемость базы данных в долгосрочном аспекте.
Золотое правило вычисления дискового пространства
В базах данных нужно применять просты?, универсальные и последовательные вычисления,. Можно гораздо продуктивнее потратить рабочее время, нежели производить скрупулезные вычисления пространства, которые racle может и проигнорировать. Даже при следовании самым строгим вычислениям размера нельзя быть уверенным в том, как именно Oracle загрузит данные в таблицу или индекс.
Ниже будет показано, как упростить процесс оценки размера и освободиться для выполнения намного более полезных для АБД функций. Этот процесс следует выполнять независимо от того, генерируются ли значения default storage для табличных пространств, управляемых с помощью словаря, или размеры экстентов для локально управляемых табличных пространств.
188
Гпава 5
Примечание В базе данных Oracle 10# следует использовать локально управляв мые табличные пространства. Если был сделан апгрейд одного из предыдущих релизов, где использовались управляемые с помощью словаря табличные пространства, необходимо заменить их локально управляемыми табличными пространствами.
Основные правила вычисления дискового пространства
При выделении места Oracle использует следующие внутренние правила:
Пространство выделяется только блоками, а не частями блоков.
Блоки выделяются группами, а не поодиночке.
В зависимости от доступного места в табличном пространстве могут быть выделены большие или меньшие группы блоков.
Ваша задача — работать согласно принятым в Oracle методам выделения пространства, а не против них. Если используются согласованные размеры экстентов, можно в значительной степени делегировать Oracle полномочия по выделению пространства.
Влияние размера экстента на производительность
Уменьшение количества экстентов в таблице не всегда приводит к выигрышу в производительности, В некоторых случаях (например, в среде параллельных запросов) наличие нескольких экстентов в таблице может существенно уменьшить конкуренцию ввода/вывода и повысить производительность. Однако, независимо от количества экстентов, их размеры нужно определять правильно.
Oracle считывает данные из таблиц двумя способами: по идентификатору строки (RowID) (обычно сразу после доступа к индексу) и посредством полного просмотра таблицы. В первом случае количество экстентов в таблице не влияет на производительность чтения. Oracle читает строки по их физическому расположению (указанному в идентификаторе RowID) и извлекает данные.
Если данные считываются посредством полного просмотра, размер экстентов может в незначительной степени повлиять на производительность. При этом Oracle обращается к большому количеству блоков одновременно. Их количество определяется параметром инициализаций базы данных DB_FILE_MULTIBLOCK_READ_COUNT и ограничено размером буфера ввода/вывода операционной системы. Например, если размер блока базы данных равен 8 Кбайт, а размер буфера ввода/вывода —128 Кбайт, за одну операцию чтения при полном просмотре таблицы может быть прочитано до 16 блоков. В этом случае, если задать значение параметра DB_FILE_MULTIBLOCK_READ_COUNT больше 16, производительность полного просмотра таблицы не изменится.
Размеры экстентов должны вычисляться с учетом способности Oracl выполнять считывание нескольких блоков за одну операцию при полном просмотре таблицы. Если размер буфера ввода/вывода операционной системы равен 128 Кбайт, размеры экстентов должны быть кратны этой величине.
Допустим, в таблице есть 10 экстентов по 128 Кбайт каждый. Размер буфера ввода/вывода операционной системы также равен 128 Кбай'Г-
разработка и реализация приложений 189
Это означает, что для полного просмотра таблицы Oracle нужно выполнить 10 операций чтения. Если собрать данные в один экстент размером 1280 Кбайт, Oracle все равно следует выполнить 10 операций чтения, чтобы просканировать таблицу. Уменьшение числа экстентов не приведет к выигрышу в производительности.
Если размер экстента таблицы не кратен размеру буфера ввода/вывода, число операций чтения, требующихся для полного просмотра, может возрасти. Например, для такой же таблицы в 1280 Кбайт можно создать 8 экстентов по 160 Кбайт каждый. Чтобы прочитать первый экстент, Oracle должна выполнить две операции чтения: одну для первых 128 Кбайт, а вторую для оставшихся 32 (операция чтения не может охватить несколько экстентов). Таким образом, чтобы прочитать всю таблицу, нужно выполнить по две операции чтения на каждый экстент, т.е. 16 операций. Уменьшение количества экстентов с 10 до 8 увеличивает число операций чтения на 60%.
Поэтому во избежание проблем с размерами экстентов надо следовать одной из предлагаемых ниже стратегий:
Создавайте экстенты, размеры которых значительно превышают размер буфера ввода/вывода. Для очень больших экстентов, даже если их размер не кратен размеру буфера ввода/вывода, потребуется выполнить очень немного дополнительных операций чтения.
Задайте параметр DB_FILE_MULTIBLOCK_READ_COUNT, чтобы полностью использовать преимущества, обусловливаемые размером буфера ввода/вывода операционной системы. Следует учесть: при задании слишком большого значения параметра оптимизатор решит, что операции полного просмотра таблиц более эффективны, чем на самом деле, а это приведет к изменению существующих планов исполнения.
Создавайте небольшие экстенты, но так, чтобы их размеры были кратны размеру буфера ввода/вывода операционной системы.
Если размер буфера ввода/вывода операционной системы равен 128 Кбайт, в вашем распоряжении могут быть экстенты размером 128, 256, 512 Кбайт, 1 Мбайт и т.д. Можно еще уменьшить пул доступных для выбора размеров экстентов.
Используйте пул размеров экстентов, удовлетворяющий следующему критерию: каждый размер экстента должен содержать цел ое, кратное каждому меньшему размеру экстента. Самый простой способ применения этого правила — создать удваивающиеся размеры экстентов: 1, 2, 4, 16 и 32 Мбайт. Чтобы уменьшить число размеров экстентов, можно не удваивать их размеры, а учетверять: 1,4, 16 Мбайт и т.д. Используйте такие значения размеров для локально управляемых табличных пространств или доверьтесь опции автоматического определения размеров.
Определение размеров объектов
Для эффективного управления дисковым пространством необходимо только выбрать набор значений пространств, который удовлетворял бы приведенному выше критерию. Завершив выделение пространства, нужно разделить его по табличным пространствам:
190
Гпава 5
П create tablespace DATA_1M
datafile ‘/u01/oracle/VLDB/data_1m.dbf’
size 1000M
extent management local uniform size IM;
create tablespace DATA_MEDIUM
datafile ‘/u01/oracle/VLDB/data_4m.dbf’
size 4000M
extent management local uniform size 4M;
create tablespace DA1A_LARGE
datafile ‘/u01/oracle/VLDB/data_16m.dbf’
size 16000M
extent management local uniform size 16M;
В этом примере создаются три отдельных табличных пространства DATA с размерами экстентов в 1,4 и 16 Мбайт. Если необходимо создать таблицу размером 3 Мбайт, можно сделать это с помощью либо трех экстентов по 1 Мбайт в DATA_1M, либо одного экстента из 4 Мбайт в DATA_4M. Таблицу, которая может вырасти до 10 Мбайт, можно поместить в DATA_4M.
По мере увеличения размера таблиц будут расти значения параметра хранения по умолчанию в конструкциях, что соответствует правилам выделения пространства и стандартам размеров экстентов. Следующим может стать DATA_64M, за которым пойдут DATA_256M и DATA_1G. Применение одних и тех же размеров во всех базах данных облегчит управление дисковым пространством всего окружения баз данных.
По мере роста размеров экстентов их распределение по табличным пространствам обычно приводит к разделению типов таблиц: небольшие статические таблицы будут изолированы в табличных пространствах с небольшими размерами экстентов, а большие таблицы для обработки транзакций (или их разделы) будут выделены в таблицы с большим размером экстента, что упростит последующее управление и настройку.
В следующих разделах приводятся рекомендации по оценке использования дискового пространства для объектов. Поскольку целевые размеры (1,4,16 Мбайт и т.д.) идут не вплотную, для такой оценки не придется производить слишком подробные вычисления.
Примечание Можно установить размер блока базы данных на уровне табличного пространства. Этот размер необходимо установить во время создания табличного пространства, и к этому моменту должен быть уже создан кэш буферов для данного размера блока. Следует убедиться в том, что выбранные размеры экстентов согласуются с применяемым в базе данных максимальным размером блока. Ограничение использования нестандартных размеров блоков упростит сопровождение базы данных и процедуры определения размеров.
Оценка пространства, требующегося для таблиц
Начиная с Oracle 10g, стало возможно использовать процедуру CREATE^ TABLE COST из пакета DBMS_SPACE, чтобы оцепить требующееся ДЛ* таблицы дисковое пространство. Процедура определяет требующееся для таблицы дисковое пространство, основываясь на таких атрибутах,
разработка и реализация приложений
191
как параметры хранения для табличного пространства, размер блока, число строк и средняя длина строки. Процедура подходит и для локально управляемых табличных пространств, и для табличных пространств, управляемых с помощью словаря.
Есть две версии процедуры CREATE_TABLE_COST (фактически она является перегруженной, и ее можно использовать обоими способами). В первой версии содержатся четыре входные переменные: имя _таблично-го_пространства, средн_разм_стгроки, счетч_строк и pct__free. Кроме того, есть две выходные переменные: исп_байтов и выдел_байтов. Входные переменные для второй версии — имя_табличного_ пространства, опис_столб-цов, сметч_стр(укирс1_/гее', выходные переменные — исп_байтовп видел_бай-тов (см. приведенную ниже таблицу).
Параметр Описание
имя_табличного_пространства Табличное пространство, в котором будет создан объект.
средн_разм_строки опис_столбцов счетч_строк pctjree исп_байтов
выдел_байтов
Средняя длина строки таблицы
Описание столбцов.
Ожидаемое число строк таблицы.
Установка параметра pctfree для таблицы
Дисковое пространство, использованное данными таблицы. В это значение включены «накладные расходы», вызванные установкой pctfree и других опций блока.
Дисковое пространство, выделенное для данных таблицы на основании характеристик табличного пространства. В этом значении учтена установка размера экстента табличного пространства.
Если есть табличное пространство USERS, можно вычислить размер пространства, требующегося для размещения в этом табличном пространстве новой таблицы. В приведенном ниже примере выполняется процедура CREATE_TABLE_COST, в которую передаются значения средней длины строки, числа строк и установка pctfree. Определяются переменные исп_байтов и выдел_баитов, и их значения выводятся посредством процедуры DBMS_OUTPUT.PUT_LINE:
О declare
calc_used_bytes NUMBER; calc_alloc_bytes NUMBER; begin
DBMS_SPACE.CREATE_TABLE_COST ( имя_табличного_пространства -> ‘USERS’ средн_разм^строки => 100, счетч_строк => 5000, pct_free => 10, исп_байтов => calc_used_bytes, выдел-байтов => calc_alloc_bytes
);
192
Гпава 5
DBMS_OUTPUT.PUT_LINE( ‘ Used bytes: ‘ || calc_used_bytes);
DBMS_OUTPUT.PUT_LINE(‘Allocated bytes: * || calc, alloc.bytes); end;
В выходных данных блока будет показано вычисленное для этих установок переменных количество использованных и выделяемых байтов. Не составит труда перед созданием таблицы вычислить ожидаемое использование дискового пространства для множест ва различных комбинаций параметров хранения.
Примечание Для активации показа выходных данных сценария в сеансе SQL*Plus необходимо использовать команду set serveroutput on.
Оценка пространства, требующегося для индексов
Начиная с Oracle 10g, стало возможно использовать процедуру CREATE-INDEX_COST из пакета DBMS_SPACE, чтобы оценить дисковое пространство, требующееся для индекса таблицы. Процедура определяет данное пространство, основываясь на таких атрибутах, как параметры хранения для табличного пространства, размер блока, число строк и средняя длина строки. Процедура подходит и для локально управляемых табличных пространств, и для табличных пространств, управляемых с помощью словаря.
Для оценки требующегося индексного пространства нужны входные переменные, содержащие команды DDL для создания индекса, и имя локальной таблицы плана (если таковая имеется). Оценки индексного пространства основываются на статистических данных для родственной таблицы. Перед началом процесса оценки индексного пространства необходимо быть уверенным в том, что эти статистические данные корректны; в противном случае результаты будут искажены. Переменные для процедуры CREATE_INDEX_COST описаны в приведенной ниже таблице.
Параметр
Ddl исп_байтов выдел_байтов таблица_плана
Описание
Команда create index
Число байтов, использованное данными индекса
Число байтов, выделенное для элементов индекса
Используемая таблица плана (значение по умолчанию NULL)
Поскольку процедура CREATE_INDEX COST основывает свои результаты на статистических данных базовой таблицы, ее нельзя использовать до тех пор, пока таблица нс будет создана, загружена и проанализир на. В приведенном ниже примере оценивается пространство, требующее-ся для создания нового индекса таблицы BOOKSHELb. Обозначение табличного пространства является частью команды create index, передаваемой в процедуру CREATE—INDEX_COST как час гь значения переменной ddl.
разработка и реализация приложений
193
□ declare
calc_used_bytes NUMBER;
calc_alloc_bytes NUMBER, begin
DBMS_SPACE.CREATE_INDEX_COST (
ddl => ‘create index BOOK_CAT on BOOKSHELF ‘ || (CategoryName) tablespace BOOKS_INDEX’, исп_байтов => calc_used_bytes, выдел_байтов -> calc_alloc_bytes
);
DBMS_OUTPUT.PUT_LINE(‘Used bytes: ‘ || calc_used_bytes);
DBMS_OUTPUT PUT_LINE(‘Allocated bytes: ‘ || calc_alloC-bytes); end;
В выходных данных этого блока будет показано вычисленное для этих установок переменных количество использованных и выделяемых байтов.
Оценка подходящего значения pctfree
Значение pctfree (в процентах) показывает, какая часть каждого блока зарезервирована как свободное пространство. Это пространство используется, если увеличилась длина строки, сохранявшейся в этом блоке данных, а также если введены значения в поля, ранее содержавшие NULL и существующие значения заменены более длинными.
Нельзя дать рекомендации по какому-то одному значению pctfree, которое было бы адекватно для всех таблиц во всех базах данных. Чтобы упростить управление пространством, нужно выбрать следующий непротиворечивый набор значений pctfree:
Для индексов, у которых значения ключей меняются редко: 2
Для таблиц, у которых строки меняются редко: 2
Для таблиц, у которых строки меняются часто: от 10 до 30
Почему следует поддерживать свободное пространство в таблице или индексе, даже если строки не меняются? Дело в том, что Oracle нуждается в свободном пространстве внутри блоков для осуществления функций по их поддержке. Если свободного пространства недостаточно (например, Для поддержки большого числа заголовков транзакций во время параллельных вставок), Oracle временно выделит часть области pctfree для этого блока. Значение pctfree должно поддерживать такое выделение пространства. Чтобы зарезервировать пространство для заголовков транзакций в таблицах с интенсивными вставками, нужно задать параметр initrans, чтобы он не был равен значению по умолчанию. Область pctfree должна быть достаточно большой, чтобы в ней можно было сохранять несколько строк данных.
Примечание В зависимости от доступного в блоке пространства, Oracle автоматически позволяет иметь до 255 одновременно выполняющихся транзакций обновления для любого блока данных.
194
Гпава 5
Поскольку параметр pctfree связан со способом осуществления обновлений для приложения, его вычисление сравнительно просто. Этот параметр показывает число записей, сохраняемых в блоке таблицы. Чтобы узнать, правильно ли задано значение параметра pctfree, нужно сначала определить количество строк в блоке. Для сбора статистических данных можно использовать пакет DBMS_STATS. Если значение pctfree слишком мало, число расщепленных строк будет неуклонно возрастать. Можно провести мониторинг представления базы данных V$SYSSTAT на предмет повышения значений для статистики «table fetch continued row» (в таблице выбрана продолжающаяся (расщепленная) строка); это означает, что для получения одной строки базе данных необходимо обратиться к нескольким блокам.
Примечание Перемещение строк, вызванное неадекватностью пространства в области pctfree, называется миграцией строк. Оно влияет на производительность транзакций.
Примечание Для индексов, которые будут поддерживать многочисленные вставки, значение pctfree может принимать значения до 50%.
Определение подходящего значения pctused
Значение pctused показывает, когда использованный блок данных будет снова добавлен к списку блоков, в которые можно вводить строки. Рассмотрим таблицу, параметр pctfree которой равен 20, а параметр pctused — 50. При введении строк в таблицу Oracle будет оставлять свободными 20 о каждого блока (для последующего обновления введенных строк). Если теперь начать удалять записи из блоков, Oracle не станет автоматически повторно использовать освобождающееся пространство. Новые строки не будут вставляться в блок, пока объем занятого пространства в нем не станет меньше процента, определенного в параметре pctused, т.е. 50%.
По умолчанию значение pctused равно 40. Если приложение часто удаляет записи из таблиц и для этого параметра используется значение по умолчанию, много блоков в таблицах будет загружено только на 40%.
В большинстве систем можно задавать pctused так, чтобы pctused плюс pctfree было равно 80. Если значение pctfree равно 20%, пусть pctused будет 60%. При этом будет использовано не менее 60% каждого блока, а 20% сохранится для обновлений и расширений строк.
При создании табличных пространств можно активировать автоматы ческое управление пространством в сегментах. В этом случае Oracle будог управлять списком свободных блоков динамически. Если активировано автоматическое управление пространством в сегментах, не требуется ис пользовать установку pctused.
Индексы по реверсированному ключу
В индексе по реверсированному ключу значения сохраняются в обратно*1 порядке: например, число 2201 запишется как 1022. При использований1 стандартного индекса последовательные значения сохраняются Друг другом. В индексе по реверсированному ключу это не так. Если ваши за'
разработка и реализация Приложений
195
просы редко выполняют просмотр диапазонов таблиц и вас беспокоит конкуренция ввода/вывода среди индексов, индексы по реверсированному ключу могут стать решением проблемы. Размеры индексов по реверсированному ключу определяются так же, как и размеры стандартных индексов (см. предыдущий раздел).
Определение размеров битовых индексов
При создании битового индекса Oracle динамически сжимает создаваемые битовые карты. Это сжатие может привести к существенной экономии дискового пространства. Чтобы определить размер битового индекса, нужно оценить размер стандартного индекса со структурой В-дерева для тех же столбцов, используя формулы из предыдущих разделов. Определив размер такого индекса, разделите его на 10, и вы получите наиболее вероятный размер битового индекса для этих столбцов. Обычно размер битового индекса составляет от 2 до 10% от размера стандартного индекса со структурой В-дерева. Размер битового индекса зависит от изменчивости и количества различных значений в индексируемых столбцах.
Определение размеров индекс-таблиц
Ипдекс-таблицы сохраняются отсортированными по их первичному ключу. Требования таких таблиц к месту на диске очень напоминают аналогичные требования индекса по всем столбцам таблицы. Различие связано с вычислением только места, занимаемого строкой, поскольку индекс-таблицы не имеют псевдостолбца RowID.
В следующем листинге приводится вычисление необходимого пространства на строку для индекс-таблиц. Эта оценка памяти производится для всей строки, включая те ее фрагменты, что хранятся вне таблицы:
П Длина строки для определения размера = средняя длина строки
+ число столбцов
+ число длинных столбцов
+ 2 байта для заголовка
Введите это значение в качестве длины строки, когда будете использовать для индекс-таблицы процедуру CREATE_TABLE_COST.
Определение размеров таблиц, содержащих большие объекты
Данные больших объектов (Large Objects, LOB), относящиеся к типам BLOB или CLOB, обычно сохраняются отдельно от главной таблицы. Для описания размещения данных LOB можно использовать фразу lob команды create table. В главной таблице Oracle сохраняет значение локатора ob, который и указывает па данные LOB. Когда данные хранятся вне строки, от 36 до 86 байт управляющих данных (их называют локатором lob) остаются в составе этого фрагмента строки.
Однако Oracle не всегда сохраняет данные LOB отдельно от главной таблицы. Обычно они сохраняются в самой таблице, пока размер этих Данных не превысит 4000 байт. Поэтому, сохраняя небольшие значения LOB, следует учитывать их влияние на место, занимаемое главной таблицей. Если длина значения LOB меньше 4000 символов, для храпения этих Данных можно использовать тип данных VARCHAR2, а нс LOB.
196
Гпава 5
Определение размеров разделов
Для таблицы можно создать несколько отдельных разделов. В так называемой секционированной (partitioned) таблице несколько отдельных физических разделов составляют таблицу. Например, таблица SALES может содержать четыре раздела: SALES_NORTH, 3ALES_SOUTH, SALES_ EAST и SALES_WEST. Размер каждого раздела определяется с помощью методов вычисления размеров таблиц (см. выше), а размеры индексов разделов — с помощью методов определения размеров индексов.
Использование временных таблиц
Для хранения временных данных во время работы приложения можно создавать временные таблицы. Данные таблицы могут зависеть от транзакции или поддерживаться во время сеанса пользователя. По завершении транзакции или сеанса происходит усечение этих данных.
Для создания временной таблицы нужно использовать опцию create global temporary table команды create table. Чтобы удалить строки по окончании транзакции, следует задать on commit delete rows:
□ create global temporary table MY_TEMP_TABLE (Name VARCHAR2(25),
Street VARCHAR2(25), City VARCHAR2(25))
on commit delete rows;
Затем можно вставлять строки в MY_TEMP_TABLE во время работы приложения. Если результаты транзакции фиксируются (commit) Oracle усечет (truncate) таблицу MY__TEMP_TABLE. Чтобы сохранить строки на протяжении всего сеанса, нужно указать on commit preserve rows.
Как администратору вам следует знать, используют ли разработчики приложения эту средство. Если да, то необходимо учесть пространство, которое потребуется для временных таблиц во время обработки. Обычно временные таблицы используются для повышения скорости обработки сложных транзакций, поэтому, возможно, придется сбалансировать требования производительности и пространства. Для дальнейшего повышения производительности обработки можно создавать индексы для временных таблиц и опять-таки за счет увеличения используемого пространства.
Примечание Временные таблицы и их индексы не требуют пространства, пока в них не произведена первая вставка. Когда они больше не используются, выделение им пространства отменяется.
Поддержка таблиц, основанных на абстрактных типах данных
Определенные пользователями типы данных, известные также как пбс#2 рактные типы данных, являются очень важной частью объектгю-реляциоН ных приложений баз данных. Каждый абстрактный т ип данных имеет св# занные с ними методы конструктора, которые пользователи выполняют Д^Я манипулирования хранящимися в таблицах данными. Абстрактные типЫ
разработка и реализация приложений
197
данных определяют структуру данных, например, тип данных ADDRESS_TY может содержать атрибуты для данных адреса, а также методы работы с этими данными. При создании типа данных ADDRESS_TY Oracle автоматически создаст метод конструктора под названием ADDRESS_TY. Этот метод содержит параметры, соответствующие атрибутам типа данных, что облегчает ввод новых значений в формате типа данных.
Можно создавать таблицы, для описания столбцов которых используются абстрактные типы данных. Например, можно создать абстрактный тип данных для адресов:
□ create type ADDRESS—TY as object
(Street VARCHAR2(50),
City VARCHAR2(25),
State CHAR(2),
Zip NUMBER);
После создания типа данных ADDRESS_TY можно использовать его для создания таблиц:
□ create table CUSTOMER
(Name VARCHAR2(25),
Address ADDRESS_TY);
При создании абстрактного типа данных Oracle создает метод конструктора, используемый при выполнении операций вставки. Имя метода конструктора совпадает с названием типа данных, а в качестве параметров используются атрибуты типа данных. При вставке записей в таблицу CUSTOMER необходимо использовать метод конструктора типа данных ADDRESS_TY для ввода значений поля Address:
□ insert into CUSTOMER values
(‘Joe’, ADDRESS_TY(‘My Street’, ‘Some City’, ‘ST’, 10001));
В этом примере команда insert обращается к методу конструктора ADDRESSTY, чтобы вставить значения в атрибуты типа данных address_ty.
При использовании абстрактных типов данных повышаются требования к занимаемому таблицами пространству — на 8 байт для каждого используемого типа. Если какой-то тип данных содержит еще один тип данных, нужно добавить по 8 байт для каждого из них.
Использование объектных представлений
Использование абстрактных типов данных повышает сложность среды разработки. Выполняя запрос к атрибутам абстрактного типа данных, нужно применять синтаксис, не используемый при работе с тяб пипами, которые не содержат абстрактных типов. Если не реализовать абстрактные типы данных для всех таблиц, то для некоторых таблиц придется использовать один синтаксис, а для остальных-другой, и нужно будет наперед знать, какие запросы работают с абстрактными типами данных.
Например, таблица CUSTOMER использует тип данных ADDRESS_ TY, описанный в предыдущем разделе:
198
Гпава 5
□ create table CUSTOMER
(Name VARCHAR2(25),
Address ADDRESS_TY);
Тип данных ADDRESS_TY, в свою очередь, содержит четыре атрибута: Street, City, State и Zip. Чтобы получить значение атрибута Street из столбца Address таблицы CUSTOMER, нужно составить запрос:
□ select Address.Street from CUSTOMER;
Однако такой запрос не будет работать. Обращаясь к атрибутам абстрактных типов данных, необходимо использовать коррелирующие переменные (correlation variables) для имен таблицы, иначе может возникнуть неопределенность относительно того, какой конкретно объект должен быть выбран. Чтобы обратиться к атрибуту Street, нужно воспользоваться коррелирующей переменной (в данном случае «С») для таблицы CUSTOMER:
□ select С.Address.Street from CUSTOMER C;
Коррелирующие переменные используются для обращений к атрибутам абстрактных типов данных даже в том случае, когда обращение происходит только к одной таблице. Таким образом, с запросами атрибутов абстрактных типов данных связаны две нестандартные особенности: нотация, применяемая для обращения к атрибуту, и коррелирующая переменная. Чтобы согласованно реализовать абстрактные типы данных, необходимо изменить стандарты SQL, включив в них полную поддержку коррелирующих переменных. Даже в этом случае нотация, используемая для обращений к атрибутам, может вызвать проблемы, поскольку нельзя использовать аналогичную нотацию для таблиц, не содержащих абстрактные типы данных.
Объектные представления являются эффективным компромиссным решением этого несоответствия. В предыдущем примере таблица CUSTOMER была создана, исходя из предположения, что тип данных ADDRESS_TY уже существует. Но что если таблица также уже существует? Что если раньше вы уже разработали приложение по ведению реляцион-ной базы данных и хотите реализовать в нем объектно-реляционные кон-цепции без его полной перестройки и воссоздания заново? Для этого по-требуется иметь возможность наложить объектно-ориентированные (ОО) структуры на существующие реляционные таблицы. В качестве спо соба описания объектов, используемых имеющимися реляционными тао лицами, Oracle предлагает так называемые объектные представления.
Если таблица CUSTOMER уже существует, можно создать тип данных ADDRESS_TY и с помощью объектных представлений соотнести его с эт _ таблицей. В следующем листинге описано создание таблицы CUSTOM как реляционной таблицы, использующей только обычные типы данных-
□ create table CUSTOMER
(Name VARCHAR2
Street VARCHAR2
City State Zip
VARCHAR2(25) primary key, VARCHAR2(50), VARCHAR2(25), CHAR(2), NUMBER);
разработка и реализация приложений 199
Создавая другую таблицу или приложение, сохраняющие информацию о людях и адресах, можно предпочесть тип данных ADDRESS_TY. Тогда для обеспечения согласованности этот тип данных следует применить и к таблице CUSTOMER. В примерах, приведенных ниже, используется тип данных ADDRESS_TY.
Можно создать объектное представление, основанное на таблице CUSTOMER, используя любой определенный тип данных. Для этого используется команда create view. В этой команде нужно определить запрос, который будет формировать основу представления. В следующем листинге показан код, создающий объектное представление CUSTOMER_OV:
□ create view CUSTOMER OV (Name, Address) as select Name,
ADDRESS_TY (Street, City, State, Zip)
from CUSTOMER;
Представление CUSTOMER_OV содержит два столбца: имя и адрес (последний определен как имеющий тип данных ADDRESS_TY). В команде create view нельзя указать опцию object.
В данном примере отражено несколько важных особенностей синтаксиса. Если таблица создается на основе существующего абстрактного типа данных, значения столбцов выбираются из нее по ссылке на имена (такие, как Name), а не на их методы конструктора. Но при создании объектного представления нужно ссылаться именно на методы конструктора (такие, как ADDRESS_TY). Кроме того, в запросах, формирующих объектное представление, можно использовать фразу where. Это позволяет ограничить число строк, доступных для объектного представления.
Если используются объектные представления, вы как АБД будете администрировать реляционные таблицы точно гак же, как делали это раньше. По-прежнему придется управлять привилегиями для типов данных (см. ниже), но таблицы и индексные структуры останутся теми же самыми, какими они были до создания абстрактных типов данных. Использование реляционных структур приводит к упрощению задач администрирования и в то же время позволяет разработчикам обращаться к объектам через объектные представления таблиц.
С помощью объектных представлений можно также имитировать ссылки, используемые объектными строками. Объектные строки представляют собой строки в объектной таблице. Для создания объектного представления, поддерживающего объектные строки, нужно прежде всего создать тип данных, использующий ту же структуру, что и таблица:
О create or replace type CUSTOMER_TY as object
(Name VARCHAR2(25),
Street VARCHAR2(50),
City VARCHAR2(25),
State CHAR(2),
Zip NUMBER);
200
Гпава 5
Теперь нужно создать объектное представление, основанное на типе CUSTOMER_TY, назначив при этом записям таблицы CUSTOMER объектные идентификаторы (object identifier, OID):
□ create view CUSTOMER_OV of CUSTOMER_TY with object identifier (Name) as select Name, Street, City, State, Zip from CUSTOMER;
В первой части команды create view представлению дается имя (CUSTOMER_OV) и сообщается, что структура представления основывается на типе данных CUSTOMER_TY. Объектный идентификатор, известный также как OID, идентифицирует объектную строку. В данном объектном представлении в качестве OID используется столбец Name.
Если есть вторая таблица, ссылающаяся на таблицу CUSTOMER с помощью отношений «первичный ключ/внешний ключ», можно создать объектное представление, содержащее ссылки на представление CUSTOMER_OV. Например, таблица CUSTOMER-CALL содержит внешний ключ к таблице CUSTOMER:
□ create table CUSTOMER-CALL
(Name VARCHAR2(25),
Call-Number NUMBER,
Call_Date DATE,
constraint CUSTOMER_CALL_PK
primary key (Name, Call_Number),
constraint CUSTOMER_CALL_FK foreign key (Name)
references CUSTOMER(Name));
Столбец Name таблицы CUSTOMER-CALL ссылается на одноименный столбец таблицы CUSTOMER. Поскольку были имитированы объектные идентификаторы (так называемые pkOID), основанные на первичном ключе таблицы CUSTOMER, на них нужно создать ссылки. Для этого в среде Oracle существует специальный оператор MAKE_REF, создающий ссылки (которые называются pkREF). В следующем листинге этот оператор используется для создания ссылок из объектного представления таблицы CUSTOMER-CALL на объектное представление таблицы CUSTOMER:
□ create view CUSTOMER_CALL_OV as select MAKE_REF (CUSTOMER_OV, Name) Name, Call_Number, Call_Date
from CUSTOMER-CALL;
В представлении CUSTOMER_CALL_OV для Oracle указывается йЫ представления для ссылки, а также столбцы, составляющие ccbI^n pkREF. Теперь, применив оператор DEREF к столбцу CUSTOMERS & можно обратиться к данным представления CUSTOMEROV из предел ления CUSTOMER_CALL_OV:
П select DEREF(CCOV.Name) from CUSTOMER_CALL_OV CCOV lA/hPrp Call Date = TRUNC(SysDate);
разработка и реализация приложений
201
Таким образом, запрос может вернуть данные таблицы CUSTOMER, не обращаясь к ней непосредственно. В данном примере столбец Са11_ Date используется как ограничивающее условие для возвращаемых запросом строк.
Неважно, используются ли объектные строки или объектные столбцы — с помощью объектных представлений вы защищаете свои таблицы от объектных отношений. Таблицы не изменяются и управляются так же, как и раньше. Разница заключается только в том, что теперь можно получить доступ к строкам таблицы CUSTOMER, как если бы они были объектными строками.
С точки зрения АБД объектные представления позволяют продолжить создание и поддержку стандартных таблиц и индексов, несмотря на то, что разработчики приложений реализуют продвинутые объектно-реляционные характеристики, как верхний уровень по отношению к этим таблицам.
Вопросы безопасности для абстрактных типов данных
Примеры предыдущего раздела были основаны на предположении, что типом данных ADDRESS_TY и таблицей CUSTOMER владеет один пользователь. Но что делать, если владелец типа данных не является владельцем таблицы? Что если другой пользователь хочет создать тип данных, основанный на типе, созданном вами? В среде разработки следует установить правила владения абстрактными типами данных и их использования.
Рассмотрим ситуацию, когда типом данных ADDRESS_TY владеет учетная запись DORA, а пользователь GEORGE пытается создать тип данных PERSON_TY. Этот пользователь выполняет следующую команду:
□ create type PERSON_TY as object
(Name VARCHAR2(25),
Address ADDRESS TY);
Если абстрактный тип данных ADDRESS_TY не принадлежит пользователю GEORGE, Oracle ответит на команду create type следующим сообщением:
Warning; Type created with compilation errors.
(Предупреждение: тип создан с ошибками компиляции.)
Ошибки компиляции связаны с проблемами вызова метода конструктора созданного типа данных. Oracle не может разрешить ссылку на тип Данных ADDRESS_TY, поскольку пользователь GEORGE им не владеет.
GEORGE не сможет создать тип данных PERSON_TY (включающий F’ пока DORA не предоставит (grant) ему привилегию
XECUTE на свой тип. Этот оператор grant показан ниже:
° grant EXECUTE on ADDRESS_TY to George;
Примечание Кроме того, необходимо предоставить привилегию EXECUTE на тип любому пользователю, который будет выполнять с таблицей операции DML.
202
Гпава 5
Теперь все в порядке — GEORGE может, наконец, создать тип данных, основанный на типе данных ADDRESS_TY, принадлежащем записи DORA:
□ create or replace type PERSON_TY as object
(Name VARCHAR2(25),
Address Dora. ADDRESSJTY);
Теперь тип данных PERSON_TY, принадлежащий GEORGE, будет успешно создан. Однако использование типов данных, основанных на типах данных других пользователей, — это сложная задача. Например, при выполнении операций insert необходимо полностью указывать имена владельцев каждого типа. Пользователь GEORGE может создать таблицу, которая основана на его типе PERSON_TY (он включает в себя тип ADDRESS_TY, принадлежащий пользователю DORA):
□ create table GEORGE_CUSTOMERS (Customer_ID NUMBER,
Person PERSON JFY);
Если бы пользователю GEORGE принадлежали оба типа данных -и PERSON_TY, и ADDRESS_TY-^ операция вставки в эту таблицу имела бы следующий формат:
□ insert into GEORGE_CUSTOMERS values (1, PERSON.TY (‘SomeName’,
ADDRESS_TY('St reetValue’, ‘CityValue’,
‘ST’, 11111)));
Однако эта команда выполнена не будет, поскольку при ее выполнении используется конструктор ADDRESS_TY, а им владеет пользователь DORA. Следовательно, команду insert необходимо изменить, чтобы указать в ней владельца типа данных ADDRESS_TY. В следующем примере эта команда выполнена корректно; ссылка на пользователя DORA выделена полужирным шрифтом:
□ insert into GEORGE_CUSTOMERS values (1, PERSONJTY (‘SomeName’,
Dora.ADDRESS_TY(‘StreetValue’, ‘CityValue’, ‘ST’, 11111)));
Примечание В Oracle Database 100 можно использовать синоним для типа даН' ных другого пользователя.
По возможности следует ограничить способность создавать абстра ные типы данных теми пользователями, которые будут владеть осталы ми объектами схемы приложения.
Примечание При создании синонима Oracle не проверяет допустимость объект^ для которого этот синоним создается. Когда выполняется команда create synony^ for у, Oracle не проверяет, является ли «у» допустимым именем или типом объект • Эта проверка осуществляется только при обращении к объекту через синоним.
разработка и реализация приложений
203
В только реляционной реализации Oracle привилегия EXECUTE назначается таким процедурным объектам, как процедуры и пакеты. В объектно-реляционной реализации эта привилегия расширяется, охватывая также и абстрактные типы данных. При этом используется именно привилегия EXECUTE, так как абстрактный тип данных может содержать методы: функции и процедуры PL/SQL, выполняемые над типом данных. Предоставляя кому-либо привилегию использовать ваш тип данных, вы тем самым даете ему право выполнять методы, определенные в типе данных. Хотя пользователь DORA не определил еще ни одного метода типа данных ADDRESS_TY, среда Oracle автоматически создает специальные процедуры, называемые методами конструктора и применяемые для доступа к данным. Любой объект (например, PERSON_TY), использующий тип данных ADDRESS_TY, применяет также и ассоциированный с ним метод конструктора.
Нельзя создавать публичные типы и публичные синонимы для своих типов. Следовательно, необходимо либо ссылаться на владельца типа, либо создавать тип в каждой учетной записи, использующей таблицы базы данных. Ни один из этих подходов не является простым решением проблемы управления типами данных.
Индексирование атрибутов абстрактных типов данных
В предыдущем примере на основе типов данных PERSON_TY и ADDRESSJTY была создана таблица GEORGE_CUSTOMERS. Как показано в следующем листинге, эта таблица содержит обычный столбец Customer_ID и столбец Person, определяемый абстрактным типом данных PERSON_TY:
□ create table GEORGE_CUSTOMERS
(Customer ДО NUMBER,
Person PERSON_TY);
Из определения типа данных (см. предыдущий раздел) видно, что тип PERSON_TY имеет один столбец Name, за которым следует столбец Address, определенный типом данных ADDRESS_TY.
Ссылаясь на столбцы внутри абстрактного типа данных при выполнении запросов, удалений и обновлений, нужно указывать полные пути к атрибутам типов данных. Например, следующий запрос возвращает столбцы Customer_ID и Name. Последний является атрибутом типа данных, определяющего столбец Person, так что на него нужно ссылаться как на Eerson.Name:
select С. Customer__ID, С.Person.Name
from GEORGE_CUSTOMERS C;
204
Гпава 5
На атрибуты типа данных ADDRESS_TY можно ссылаться, указывая полный путь через соответствующие столбцы. Например, столбец Street следует определить как Person.Address.Street, что полностью описывает его расположение в структуре таблицы. В следующем примере дважды происходит обращение к столбцу City: один раз в списке столбцов для выбора и еще раз в конструкции where:
□ select С.Person.Name,
С.Person.Address.City
form GE0RGE_CUST0MER8 C
where C.Person.Address.City like ‘C%’;
Поскольку столбец City используется в конструкции where, осуществляющей поиск в диапазоне, оптимизатор Oracle может использовать индекс для разрешения запроса. Если для столбца City имеется индекс, Oracle быстро найдет все строки, в которых значения City начинаются с буквы ‘С’, как это определено в запросе.
Чтобы создать индекс для столбца, входящего в состав абстрактного типа данных, необходимо в команде create index определить полный путь к этому столбцу. Например, чтобы проиндексировать столбец City (в составе столбца Address), надо выполнить следующую команду:
□ create index I_GEORGE_CUSTOMERS$CITY
on GEORGE_CUSTOMERS(Person.Address.City);
Эта команда создает индекс с именем I_GEORGE_CUSTOMER$CITY для столбца Person.Address.City. Теперь, когда произойдет обращение к этому столбцу, оптимизатор оценит используемую для доступа к данным команду SQL и определит, может ли новый индекс улучшить производительность доступа.
При создании таблиц с абстрактными типами данных нужно учитывать способ доступа к столбцам в этих типах. Если некоторые столбцы (как столбец City в предыдущем примере) будут часто использоваться в составе ограничивающего условия в запросе, они должны быть проиндексированы. В этом отношении представление нескольких столбцов в оД' ном абстрактном типе данных может снизить производительность приложения, так как может скрыть необходимость индексирования кон кретных столбцов типа данных.
Работая с абстрактными типами данных, вы вскоре станете рассмат ривать группу столбцов как один объект (как, например, столбЦ Address или Person). Важно помнить, что, оценивая пути доступа при работке запроса, оптимизатор рассматривает все столбцы индивидуал но. Следовательно, требования по индексированию должны относить к столбцам, даже если используются абстрактные типы данных. Кр°ь того, нужно помнить, что индексирование столбца City в одной таблиП ’ использующей тип данных ADDRESS_TY, не влияет на столбец City в Др)* гой таблице, использующей тот же тип данных. Например, если втор4 таблица, BRANCH, также использует тип данных ADDRESS_TY, ее с1° бец City не будет проиндексирован, пока для него не будет создан И
леке.
разработка и реализация приложений
205
«Замораживание» и «подвешивание» базы данных
Во время выполнения операций обслуживания можно временно перевести базу данных в состояние покоя («заморозить», quiesce) или ожидания («подвесить», suspend). Эти возможности позволяют не закрывать базу данных на время обслуживания, сэкономить время на ее закрытие и избежать воздействий, связанных с этим процессом.
Пока база данных заморожена, новые транзакции могут быть разрешены только для учетных записей SYS и SYSTEM. Новые запросы или попытки входа в систему будут находиться в состоянии ожидания, пока база данных не будет выведена из состояния покоя. Опция перевода в состояние покоя полезна при обслуживании таблиц и сложном обслуживании данных. Чтобы воспользоваться ей, сначала необходимо активировать диспетчер управления ресурсами базы данных (см. выше в данной главе). Вдобавок, параметр инициализации RESOURCE-MANAGEMENT при запуске базы данных должен быть установлен на TRUE, а после запуска он не должен быть дезактивирован.
Войдя в систему как SYS или SYSTEM (другие учетные записи с привилегией SYSDBA не могут выполнять эти команды), переведите базу данных в состояние покоя:
□ alter system quiesce restricted;
Все сеансы с базой данных, кроме осуществляемых администратором, будут продолжать работу до завершения текущей команды и с этого момента станут неактивными. В конфигурациях Real Application Clusters все экземпляры перейдут в состояние покоя.
Чтобы проверить, находится ли база данных в состоянии покоя, нужно войти в систему как SYS или SYSTEM и выполнить следующий запрос:
□ select Active_State from V$INSTANCE;
Значением столбца Active_State будет NORMAL (не заморожен), QUIESCING (активные сеансы, проводимые не администратором, еще выполняются) или QUIESCED (заморожен).
Для вывода базы данных из состояния покоя применяется команда:
О alter system unquiesce;
Вместо перевода базы данных в состояние покоя (замораживания) можно перевести ее в состояние ожидания. В этом состоянии база данных не выполняет операций ввода/вывода для файлов данных и управляющих файлов, что позволяет проводить ее резсрь_1Сс копирование без помех со стороны ввода/вывода. Для перевода базы данных в состояние ожидания нужно выполнить команду:
О alter system suspend;
Примечание Не используйте эту команду, если только база данных не переведена в режим горячего резервного копирования.
206
Гпава 5
Хотя команда alter system suspend может выполняться из любой учетной записи с привилегией SYSDBA, нормальные операции можно возобновить только из учетных записей SYS и SYSTEM. Их использование поможет избежать потенциальных ошибок при возобновлении работы базы данных. В конфигурациях Real Application Clusters все экземпляры перейдут в состояние ожидания. Для проверки текущего статуса используется команда:
□ select Database_Status from V$INSTANCE;
База данных будет находиться в состоянии SUSPENDED или ACTIVE. Чтобы возобновить ее работу, нужно войти в систему как SYS или SYSTEM и выполнить команду:
□ alter system resume;
Поддержка итеративной разработки
Методология итеративной, или повторяющейся, разработки, как правило, заключается в быстрой разработке последовательности прототипов. Прототипы используются для описания требований к системе по мере ее разработки. Привлекательность такой методологии обусловлена возможностью показать заказчику что-то ощутимое уже в процессе работы над приложением. Однако при этом часто встречаются недостатки, существенно влияющие на ее эффективность.
Во-первых, не всегда работа с версиями осуществляется надлежащим образом. С появлением новых версий приложения некоторые его особенности будут «заморожены», а другие изменены. Возможно также, что некоторые части приложения будут в стадии разработки, а другие проходить тестирование. Слишком часто одна и та же версия приложения используется для каждой итерации каждой особенности, а полученный продукт не будет адекватно гибким, чтобы соответствовать изменяющимся потребностям (что является целью всякой итеративной разработки).
Во-вторых, прототипы не всегда удаляются. Их разрабатывают только для того, чтобы потребитель мог получить представление о готовом продукте; их нельзя считать фундаментом конечного продукта. Использование прототипов в качестве такого фундамента не приведет к созданию наиболее стабильной и гибкой системы. При выполнении итеративной разработки прототипы следует рассматривать как временно используемые унаследованные системы.
В-третьих, часто процессы разработки/тестирования/производства четко не разделены между собой. Методология итеративной разрабо ки должна очень ясно определить, какие условия выполнить, чтобы версия приложения перешла на следующий этап своего развития. Лучше вс< ] » если разработка прототипа будет происходить отдельно от разработки полного приложения.
Наконец, часто устанавливаются совершенно нереальные временны^ рамки. В итеративной методологии применяют те же самые промежуточные продукты, что и в структурной. Ускоренная разработка приложения не означает их более быстрой генерации.
разработка и реализация приложений
207
Итеративные описания столбцов
В процессе разработки описания столбцов могут часто меняться. Можно удалять столбцы из имеющихся таблиц тотчас же или пометить их, как неиспользуемые, и удалить впоследствии в удобное время. Если столбцы удаляются немедленно, это действие может повлиять на производительность. Если же столбцы просто помечаются, как неиспользуемые, влияния на производительность не отмечается. Помеченный столбец лучше удалить впоследствии, когда база данных будет использоваться не очень интенсивно.
Для удаления столбца используется фраза set unused или drop команды alter table. Нельзя удалить псевдостолбец, столбец вложенной таблицы или столбец, являющийся ключом раздела.
В следующем примере из таблицы TABLE1 удаляется столбец Со12:
□ alter table TABLET drop column Col2;
Можно также пометить столбец как неиспользуемый:
□ alter table TABLET set unused column Col3;
Маркировка столбца как неиспользуемого не приводит к освобождению занимаемого им пространства. Любой неиспользуемый столбец также может быть удален:
□ alter table TABLE1 drop unused columns;
Чтобы увидеть все таблицы со столбцами, помеченными как неиспользуемые, обратитесь к представлениям USER_UNUSED_COL_TABS, DBA_ UNUSED.COL и ALL_UNUSED_COL_TABS.
Примечание Если столбец помечен как неиспользуемый, обратиться к нему уже невозможно. При экспорте таблицы столбец, помеченный как неиспользуемый, экспортироваться не будет.
Несколько столбцов можно удалить одной командой:
О alter table TABLE1 drop (Со14, Со15);
Примечание При удалении нескольких столбцов ключевое слово column команды alter table не используется; это приведет к появлению синтаксической ошибки. Имена нескольких столбцов следует заключать в скобки, как показано в предыдущем листинге.
Если удаляемые столбцы входят в состав первичных ключей или ограничении уникальности, в состав команды alter table следует включить также фразу cascade constrains. При удалении столбца, принадлежащего первичному ключу, удаляется также и индекс первичного ключа.
208
Гпава 5
Если нет возможности организовать «технологическое окно», во время выполнения которого можно удалить эти столбцы, нужно пометить их как неиспользуемые. Когда база данных будет находиться в состоянии покоя, можно завершить обслуживание из учетной записи SYS или SYSTEM.
Принудительное разделение курсоров
В идеале разработчики приложения должны использовать в программах переменные связывания, чтобы максимально обеспечить повторное использование в разделяемой области SQL своих команд, ранее прошедших синтаксический анализ. Если не использовать переменные связывания, в библиотечном кэше можно будет увидеть много очень похожих операторов, т.е. запросов, которые отличаются только значением литерала во фразе where.
Операторы, являющиеся идентичными за исключением значений литералов, называются сходными. Такие операторы могут использовать предварительно проанализированные команды в разделяемом пуле SQL, если параметр инициализации CURSOR-SHARING задан как SIMILAR или FORCE. Вообще говоря, предпочтительнее использовать параметр SIMILAR, так как он позволит сгенерировать новый план выполнения, отражающий все данные гистограммы о значении этого литерала.
Задание параметра CURSOR-SHARING как EXACT приведет к повторному использованию команд, прошедших ранее синтаксический анализ, когда значения литералов идентичны.
Чтобы использовать хранимые схемы плана выполнения с параметром CURSOR JSHARING, заданным как SIMILAR или FORCE, необходимо сначала сгенерировать схемы с действующей настройкой CURSOR_ SHARING.
Примечание Команды динамического SQL всегда разобраны, что позволяет существенно понизить роль разделяемой области SQL.
Управление разработкой пакетов
Представьте себе среду разработки со следующими характеристиками:
Не обеспечено выполнение стандартов.
Все объекты создаются под управлением учетных записей SYS или SYSTEM.
Вопросы размещения и определения размеров таблиц и индексов рассматриваются только частично.
Каждое приложение проектируется так, как если бы оно было единственным, которое будет запускаться в этой базе данных.
Какими бы противоречащими ни были эти условия, время от времени они встречаются при реализации покупных пакетов приложений.
Правильное управление реализацией пакетов предполагает решение тех же вопросов, которые обсуждались в предыдущих разделах.
разработка и реализация приложений
209
Генерация диаграмм
Большая часть инструментальных средств CASE позволяет осуществлять реинжиниринг (reverse engineering) пакетов в диаграммы физической базы данных. Этот процесс состоит из анализа структуры таблиц и генерации диаграммы физической базы данных, которая соответствовала бы такой структуре. При этом осуществляется анализ имен и индексов столбцов для определения ключевых столбцов. Обычно не существует однозначной корреляции между физической диаграммой базы данных и диаграммой отношений объектов. Как правило, диаграммы отношений объектов для пакетов могут быть получены от разработчика пакета; они помогают в планировании интерфейсов для пакетной базы данных.
Требования к дисковому пространству
Большинство основанных на Oracle пакетов предоставляет достаточно точные оценки использования ресурсов базы данных при их промышленном использовании. Однако часто при этом не учитываются ресурсы, требуемые при загрузке данных и модернизации программного обеспечения. Следует осуществлять тщательный мониторинг требований пакета по откату (undo) во время загрузки больших объемов данных. Может понадобиться и запасное табличное пространство DATA, если при модернизации пакет копирует все свои таблицы.
Задачи настройки
Настраивать нужно не только пользовательские приложения, но и пакеты. Определение и отслеживание соответствующих управляющих значений поможет выяснить, какие части пакета необходимо настраивать (см. главы 8 и 9).
Требования безопасности
К сожалению, большая часть пакетов, использующих базы данных Oracle, относится к одной из двух категорий: либо они были переведены на Oracle из другой системы, либо предполагается, что учетные записи владельцев их объектов имеют все привилегии администратора.
Если пакеты были сначала созданы в другой системе баз данных, скоро е зего, их порт (перенос) в Oracle не использует всех преимуществ функциональных возможностей Oracle. Эти возможности включают блокировку на уровне строк, а также использование последовательностей, триггеров и методов. Настройка такого пакета в соответствии с потребностями может означать внесение изменений в исходный код.
Если предполагается, что пакет использует полные привилегии администратора Б , не следует размещать его в той же базе данных, что и остальные критические приложения. Большинство пакетов, нуждающихся в привилегиях администратора, используег их для добавления в базу данных новых пользователей. Следует точно определить, какие системные привилегии действительно нужны учетной записи администратора пакета (обычно это только CREATE_SESSION и CREATE_USER).
210
Гпава 5
Для предоставления такого ограниченного набора системных привилегий администратору пакета можно создать специальную системную роль.
Пакеты, впервые разработанные в другой системе управления базами данных, могут требовать использования той же учетной записи, что и другие пакеты, портированные в Oracle. Например, многие приложения требуют для себя учетную запись SYSADM. Единственным решена ем этого конфликта является создание двух пакетов в различных базах данных.
Требования к данным
Необходимо четко определить все требования, выдвигаемые пакетами к обработке данных, особенно на этапе ввода данных. Обычно они хорошо описаны в документации пакета.
Требования к версии
Поддерживаемые вами приложения могут зависеть от конкретных версий и возможностей Oracle. Если используются пакетированные приложения, планы по модернизации ядра версии следует основывать на поддержке поставщиком различных версий Oracle. Более того, поставщик может переключать поддерживаемые им режимы оптимизатора, например, он может потребовать, чтобы параметр COMPATIBILITY был установлен на конкретную версию. Для поддержки ьс^х этих изменений среда базы данных должна быть предельно гибкой.
Поскольку эти ограничения не поддаются вашему контролю, следует попытаться изолировать пакетированное приложение в отдельном экземпляре. При частом обращении к данным приложения его изоляция повысит надежность связей баз данных. Следует сравнить цену обеспечения поддержки нескольких экземпляров и цену поддержки нескольких приложений в одном экземпляре.
Планы выполнения
Для генерации планов выполнения требуется доступ к операторам SQL, выполняемым в базе данных. Эти операторы SQL (они становятся доступ' ными посредством представления V$SQL_PLAN) обслуживает раздел#6 мая область SQL в составе SGA. Соотнесение операторов SQL с различны ми частями приложения требует времени. Лучше всего установить конкретные области, функциональность и производительность которые критичны для успеха приложения, и совместно с командой поддержки па кета решать проблемы производительности. Можно использовать утйЛ 1 ту STATSPACK или автоматизированный репозг-Л г ий нагрузок (см. гЛа ву 9) для сбора всех команд, сгенерированных в периоды тестирований’ а затем определить планы выполнения для тех запросов из этого набору которые наиболее интенсивно используют ресурсы. Если команды еще находятся в разделяемой области SQL, можно ознакомиться с их сТ^ тистическими данными с помощью представления V$SQL и с планами ВЬ1 полнения с помощью представления V$SQLJPLAN.
разработка и реализация приложений 211
Процедуры приемочных испытаний
Покупные пакеты должны соответствовать тем же функциональным требованиям, что и пользовательские приложения. Следовательно, процедуры приемки необходимо разработать до того, как будет выбран пакет; они могут быть сгенерированы на основе критериев этого выбора. Поступая так, вы будете проверять требуемую вам функциональность, а не то, что важно, по мнению разработчиков пакета.
Необходимо также выяснить свои возможные действия, если пакет не пройдет процедуру приемки по причинам функциональных возможностей или производительности. Не следует забывать о факторах, критичных для успеха приложения, только потому, что это приложение было куплено.
Среда тестирования
Среду тестирования необходимо определять в соответствии со следующими правилами. Она должна:
Быть крупнее среды промышленной эксплуатации. Необходимо учитывать, какая производительность понадобится в будущем.
и Содержать известные наборы данных, планы выполнения, результаты производительности и наборы данных результатов.
Использоваться для проверки каждой новой версии базы данных и инструментов, а также для проверки новых опций.
Поддерживать генерацию нескольких условий тестирования, чтобы можно было выяснить стоимость реализации новых возможностей. Не следует полагаться на точечный анализ результатов; идеально было бы определить кривую цена/производительность новой возможности с учетом расширения базы данных.
Быть достаточно гибкой, чтобы дать возможность оценить различные варианты условий лицензирования.
Активно использоваться в составе методологии реализации технологий.
При тестировании производительности транзакций необходимо отслеживать инкрементальную скорость загрузки во времени. Индексы таблицы начинают понижать производительность загрузки, когда появляется второй внутренний уровень. Об индексах и производительности загрузки см. в главе 8.
Во время тестирования образцы запросов должны представлять каждую из следующих групп:
Запросы, выполняющие соединения, включая соединения слияния, вложенные циклы, внешние соединения и хеш-соединения
Запросы, использующие связи баз данных
Операторы DML, использующие связи баз данных
212
Гпава 5
Все типы операторов DML (операторы вставки, обновления, уда-ления)
и Все основные типы команд DDL, включая создание таблиц, перестройку индексов и назначение привилегий
Запросы, использующие опцию параллельных запросов, если она применяется в вашей среде
Тестовый набор данных не должен быть «придуманным» — он должен представлять ваши операции и при этом быть воспроизводимым. Поэтому при генерации тестового набора данных необходимо рассмотреть основные группы операций, а также операций оперативной обработки транзакций, выполняемых пользователями. Полученный результат не будет отражать каждое действие в вашей базе данных, но позволит понять цели модернизации и, следовательно, уменьшить риск и упростить принятие решений по реализации новых возможностей.
(
МОНИТОРИНГ ИСПОЛЬЗОВАНИЯ
ДИСКОВОГО ПРОСТРАНСТВА
Хороший АБД всегда должен иметь набор инструментов для мониторинга работы базы данных, в том числе упреждающий мониторинг различных аспектов баз данных (например, транзакционной нагрузки, проверки безопасности, управления дисковым пространством) и мониторинг производительности, а также эффективное реагирование на любые крайне серьезные для системы проблемы. Управление транзакциями, настройка производительности, управление памятью и обеспечение безопасности и аудита базы данных будут рассмотрены в главах 7, 8, 9 и 10. В данной главе будет показано, как АБД может рационально и эффективно управлять дисковым пространством, используемым объектами базы данных в различных типах табличных пространств: в SYSTEM, SYSAUX, во временных табличных пространствах, табличных пространствах отката и в табличных пространствах различного размера.
Если администратор базы данных не хочет непрестанно заниматься управлением пространством, ему нужно понимать, как приложения будут использовать базу данных, а также обеспечить свое участие в процессе проектирования приложений базы данных. Проектирование и реализация приложений базы данных, включая вопросы компоновки табличных пространств и ожидаемого роста базы данных, были рассмотрены в главах 3, 4 и 5.
В данной главе будут предложены сценарии, для интерпретации результатов выполнения которых не требуется ничего, кроме знания SQL*Plus. Эти сценарии хороши для быстрого ознакомления с состоянием базы данных на конкретный момент времени; например, для того что-ы узнать, имеется ли в базе данных достаточно места для выполнения сегодня вечером большого задания по загрузке данных (SQL*Loader) или Для диагностирования некоторых проблем, связанных со временем отклика тех запросов, которые обычно выполняются достаточно быстро.
Для помощи в управлении дисковым пространством и диагностике вечно загруженным АБД Oracle предлагает большое количество встроенных пакетов. Например, пакет Oracle 10g Segment Advisor (консультант
214
Гпава 6
Oracle lOgno сегментам) помогает определять, имеется ли у объекта базы данных достаточно доступного пространства для повторного использова-ния, основываясь на том, насколько сильна фрагментация для этого объ-екта. Другие возможности Oracle, например Resumable Space Allocation, позволяют приостановить долго выполняющиеся операции, которые вы-шли за пределы отведенного им пространства до тех пор, пока АБД не сможет вмешаться и выделить достаточное количество дискового пространства для завершения операции. В результате, устраняется необходимость перезапуска длительно выполняющегося задания с самого начала.
Кроме того, будут рассмотрены некоторые ключевые представления словаря данных и динамические представления производительности, дающие возможность поближе познакомиться со структурой базы данных и способами оптимизации использования дискового пространства. Такие представления используются во многих рассматриваемых в этой главе сценариях.
В конце главы описываются два различных метода автоматизации некоторых сценариев и инструментальных средств Oracle: использование встроенного в Oracle 10g пакета DBMSJSCHEDULER, а также применение инфраструктуры Oracle Enterprise Manager (OEM).
Основной темой данной главы будет использование дисковой памяти табличными пространствами, а также содержащиеся в табличных пространствах объекты. Прочие файлы данных, например управляющие файлы и файлы журналов базы данных, также требуют для себя дискового пространства, но их процентная доля от общей дисковой памяти, занимаемой базой данных, очень мала. Будет рассмотрен вопрос о том, как управлять архивными журнальными файлами, так как количество архивных файлов журналов базы данных может бесконечно увеличиваться со скоростью, прямо пропорциональной активности операций DML для рассматриваемой базы данных. Следовательно, хороший план управления архивными файлами журналов поможет сохранить контроль над использованием дискового пространства.
Часто встречающиеся проблемы управления дисковым пространством
Как правило, все проблемы управления дисковым пространством попадают в одну из трех категорий: недостаток свободного места в обычном тао личном пространстве, выделение слишком большого/малого места для пространства отката для выполняющихся длительное время запросов’ для которых требуется сохранить непротиворечивый исходный (до нача ла выполнения запроса. — Прим, пер ) вид таблиц и недостаток места ДлЯ временных сегментов. Хотя по-прежнему могут иметься некоторые во просы, связанные с фрагментацией таких объектов базы данных, как а лицы и индексы, локально управляемые табличные пространства помога ют разрешить проблему фрагментации для табличных пространств.
Недостаток свободного места в табличном пространстве
Если табличное пространство не было определено с атрибутов AUTOEXTEND, то общее место надиске, занимаемое всеми файлами эт°' го табличного пространства, ограничивает количество данных, которЫе
Мониторинг использования дискового пространства
215
могут храниться в этом табличном пространстве. Если же атрибут AUTOEXTEND определен, то один или несколько файлов из числа тех, что составляют это табличное пространство, будет увеличиваться в размерах, чтобы обеспечить запросы на выделение новых экстентов или расширение (увеличение размеров) существующих сегментов. Даже при наличии атрибута AUTOEXTEND количество дискового пространства в табличном пространстве будет ограничено объемом дискового пространства, имеющегося на физическом дисковом устройстве или в группе храпения.
Поэтому можно прийти к выводу о том, что следует проводить мониторинг свободного и использованного места в табличных пространствах, чтобы определить тенденции использования дискового пространства в зависимости от времени и научиться удовлетворять потребность в дисковом пространстве в будущем.
Недостаток места для временных сегментов
Во временных сегментах сохраняются промежуточные данные в таких операциях базы данных, как операции сортировки, создание индексов, запросы с фразой distinct, запросы union или любые другие операции, требующие выполнения операции сортировки/слияния, которую невозможно выполнить в оперативной памяти. Временные сегменты должны выделяться во временном табличном пространстве (см. главу 1). Ни при каких обстоятельствах нельзя использовать для хранения временных сегментов табличное пространство SYSTEM; при создании базы данных в качестве временного табличного пространства по умолчанию для всех пользователей, которым табличное пространство не выделялось специально, должно быть специфицировано какое-то другое (не SYSTEM) табличное пространство. Если табличное пространство SYSTEM является локально управляемым, при создании базы данных должно быть определено отдельное временное табличное пространство.
Когда в используемом по умолчанию табличном пространстве пользователя становится недостаточно места, а также либо табличное пространстве не может быть автоматически расширено далее, либо опция AUTOEXTEND отключена, операция (запрос пользователя или оператор DML) завершится неудачно.
Выделено слишком много или слишком мало места для пространства отката
Начиная с Огас1е9г, табличные пространства отката позволяют упро-стить управление информацией об откатах за счет переноса управления этой информацией внутрь табличных пространств. От АБД более не тре-уется определять количество и размер сегментов отката для различных видов деятельности, осуществляемых базой данных. Более того, начиная С rac^e 10g, ручное управление откатом перешло в разряд не рекомендуемых параметров.
Сегменты отката не только позволяют откатить незавершенную транзакцию, но и обеспечивают согласованность чтения для выполняющихся Длительное время запросов, которые были начаты перед тем, как для таблицы были выполнены операции вставки, изменения или удаления. Раз
216
Гпава в
мер пространства отката (транзакций), требующегося для обеспечения согласованности чтения, находится под контролем АБД и определяется как количество секунд, в течение которых Oracle будет пытаться гарантц-ровать, что исходный (до обновления) вид данных будет оставаться доступным долго выполняющимся запросам.
Как и для временных табличных пространств, нужно быть уверенными в том, что для пространств отката транзакций в табличном пространстве отката выделено достаточно места для удовлетворения пиковых запросов, но при этом мы не хотим выделять больше дискового пространства, чем это на самом деле необходимо. Как и для всех других табличных пространств, при их создании можно использовать опцию AUTOEXTEND, по-зволяющую автоматически обеспечивать рост табличного пространства, не резервируя для него слишком много места авансом.
Подробнее об управлении сегментами отката см. в главе 7, а инструменты, помогающие определить размер табличного пространства отката, будут обсуждаться ниже в данной главе.
Фрагментированные табличные пространства и сегменты данных
Начиная с Огас1е8г, локально управляемое табличное пространство использует для отслеживания свободного места так называемые битовые карты (bitmaps). Эти карты не только снижают конкуренцию за доступ к словарю данных, но и устраняют напрасные потери дискового пространства, так как все выделяемые экстенты имеют либо один и тот же размер (при выделении однородных экстентов), либо являются кратными минимальному размеру (при автоматическом выделении памяти). Для миграции от табличных пространств, управляемых с помощью словаря данных, нужно рассмотреть пример, в котором происходит конвертирование табличного пространства, управляемого с помощью словаря данных, в локально управляемое табличное пространство. В выполняемой по умолчанию инсталляции Oracle 10g с использованием Database Creation Assistant (DBCA — помощник по созданию базы данных) все табличные пространства, включая табличные пространства SYSTEM и SYSAUX, создаются как локально управляемые табличные пространства.
Для создания локально управляемого табличного пространства требуется добавить к оператору create tablespace одну фразу:
□ SQL> create tablespace USERS2
2 datafile ‘F:\0RACLE\0RADATA\0EMREP\USER02. DBF’
3 size 25M autoextend on next 25M maxsize 100M
4 extent management local uniform size 4M
5 segment space management auto;
Tablespace created.
Табличное пространство будет создано с начальным размер0* 25 Мбайт, и его размер можно будет увеличить до 100 Мбайт; экстент табличного пространства будут локально управляемыми посредством 01 товых карт, и каждый экстент этого табличного пространства иметь размер 4 Мбайт. Пространство внутри каждого сегмента (таблийь
Мониторинг использования дискового пространства
217
или индекса) будет управляться не списками свободной памяти, а с помощью все тех же битовых карт.
Сегменты таблиц и индексов могут содержать значительное количество свободного места, что связано с операциями обновления и удаления. В результате можно возвратить (т. е. сделать пригодным для повторного использования. — Прим, пер.) много неиспользуемого дискового пространства, применяя некоторые из тех сценариев, о которых пойдет речь в данной главе, или используя для этой цели утилиту Oracle Segment Advisor (помощник по сегментам Oracle).
Сегменты, экстенты и блоки Oracle
Чтобы иметь возможность эффективно управлять дисковым пространством базы данных, требуются глубокие знания вопросов организации табличных пространств и файлов данных, а также компонентов сегментов, хранящихся в табличных пространствах, например таблиц и индексов. На самом нижнем уровне сегмент состоит из одного или нескольких экстентов, а каждый экстент — из одного или большего количества блоков данных. На рис. 6.1 показаны отношения между сегментами, экстентами и блоками в базе данных Oracle.
Блоки данных
Блок данных (data block) является наименьшей единицей хранения в базе данных. В идеале блок данных Oracle должен быть кратен блоку операционной системы, чтобы быть уверенным в эффективности операций ввода/ вывода. Используемый по умолчанию размер блока данных базы данных определяется значением параметра инициализации DB_BLOCK_
Рис. 6.1. Сегменты, экстенты и блоки Oracle
<b
Экстент 72 Кбайт
<ь
ZKD 2KD “ZKb
2Kb 2Kb 2Kb
2Kb 2Kb 2Kb
2Kb 2Kb 2Kb
2Kb 2Kb 2Kb
2Kb 2Kb 2Kb
2Kb 2Kb 2Kb
2Kb 2Kb 2Kb
Блоки данных
218
Гпава 6
Блок базы данных
[Ц Общий заголовок и заголовок переменных g] Список указателей таблицы
□ Список указателей строк в блоке данных
□ Свободное пространство
□ Данные строк
Рис. 6.2. Содержимое блока данных Oracle
SIZE; этот размер блока применяется для табличных пространств SYSTEM, TEMP и SYSAUX при создании базы данных и не может быть изменен без повторного создания базы данных.
Формат блока данных приведен на рис. 6.2.
В каждом блоке данных есть заголовок (header), который определяет, какие именно данные хранятся в блоке — данные или индексы. В разделе со списком указателей таблиц (table directory) содержится информация относительно строк таблицы в этом блоке; в блоке могут содержаться строки или элементы индекса только из одной таблицы, за исключением случаев кластеризованных таблиц, когда в списке указателей идентифицируются все таблицы, строки которых попали в этот блок. Список указателей строк в блоке данных (row directory) предлагает подробности относительно конкретных строк таблицы или элементов индекса, хранящихся в блоке.
Дисковое пространство для заголовка, списка указателей таблицы и списка указателей строк составляет очень малый процент от пространства, выделенного для блока, поэтому мы сосредоточим свое внимание на свободном пространстве (free space) и данных строк (row data) в блоке.
В новом только что выделенном блоке данных имеется свободное пространство для записи новых и обновления существующих (ранее записанных. — Прим, пер.) строк; обновления могут как увеличивать, так и уменьшать размер выделенного для строки пространс /ва в тех случаях, когда в строке есть столбцы переменной длины или не пустое значение (nonNULL) было заменено пустым (NULL) или наоборот. Пространство для новых вставок будет доступно в блоке до тех пор, пока не будет превышен процент доступного в блоке пространства, определяемый параметром PCTFREE, который устанавливается при создании сегмента. Если размер свободного пространства в блоке оказывается меньшим, чем PCTFREF, вставки в этот блок более не разрешаются. Если для управления про странством в блоках сегмента используются списки свободной памяти, новые вставки в таблицу будут разрешены только после того, как размер свободного пространства в блоке упадет ниже PCTUSED.
Если размер строки превышает размер блока или если обновленная стро ка более не умещается в первоначальном блоке (т. е. в том блоке, где она раз мещалась до обновления. — Прим, пер.), строка может занимать более одного
Мониторинг использования дискового пространства
219
блока. В первом случае слишком большая для данного блока строка сохраняется в цепочке (chain) блоков; это может оказаться неизбежным, когда строка содержит столбцы, размер которых превосходит самый большой разрешенный в Oracle 10gразмер блока (для Oracle 10g— 32 Кбайт).
Во втором случае строка может перестать укладываться в первоначальный блок после обновления, в результате чего Oracle будет вынуждена осуществить миграцию (перенос) данных для всей строки в новый блок, а в первом блоке оставить указатель, чтобы показать место размещения второго блока, в котором теперь хранятся данные обновленной строки. Нетрудно догадаться, что у сегмента с большим количеством перемещенных строк могут возникнуть проблемы с производительностью, поскольку число блоков, к которым необходимо получить доступ, чтобы выполнить запрос, может возрасти чуть ли не вдвое. В некоторых случаях настройка значения PCTFREE или перестройка таблицы могут привести к улучшению использования дискового пространства и повышению производительности ввода/вывода (советы по повышению производительности ввода/вывода см. в главе 8).
Экстенты
Экстент (extent) является следующим уровнем логического выделения пространства в базе данных; это определенное количество блоков, выделенное для конкретного типа объектов, например для таблицы или для индекса. Экстент представляет собой минимальное количество блоков, выделяемое за один раз; когда все пространство в экстенте заполнено, выделяется другой экстент.
При создании таблицы для нее выделяется экстент initial (первоначальный). После того как все пространство в первоначальном экстенте израсходовано, будут выделены экстенты incremental (дополнительные). В локально управляемых табличных пространствах эти последующие экстенты могут быть либо того же самого размера (если при создании табличного пространства было использовано ключевое слово UNIFORM), или же Oracle выберет для него оптимальный размер (AUTOALLOCATE). Если размер экстентов был выбран оптимальным образом, Oracle начнет с минимального размера экстента в 64 Кбайт и будет постепенно увеличивать размер последующих экстентов, чтобы они были кратными первоначальному. При таком сценарии развития событий фрагментация табличного пространства сводится к нулю.
Если размеры экстентов автоматически устанавливаются Oracle, параметры INITIAL, NEXT, PCTINCREASE и MINEXTENTS используются только как “руководящие указания”, с учетом которых по внутренним алгоритмам Oracle определяются наилучшие размеры сегментов. В приводимом ниже примере для таблицы, создаваемой в табличном пространстве, для которого включена опция AUTOALLOCATE, не будут использоваться параметры, заданные в операторе create table:
SQL> create table aalc (c1 char(2000))
2 storage (initial 1m next 2m pctincrease 50);
Table created.
220
Гпава о
SQL> begin
2 for I in 1 .. 3000 loop
3 insert into aalc values (‘a’);
4 end loop;
5 end;
6 /
PL/SQL procedure successfully completed.
SQL> select segment-name, extent_id, bytes, blocks
2 from user_extents where segment_name = ‘aalc’;
SEGMENT-NAME EXTENT.ID BYTES BLOCKS
aalc 0 65536 8
aalc 1 65536 8
. • • • aalc 15 65536 8
aalc 16 1048576 128
• » aalc 22 1048576 128
23 rows selected.
Если только таблица не будет удалена или для нее не будет выполнена операция усечения, все выделенные экстенту блоки останутся выделенными для таблицы, даже если из таблицы будут удалены все строки. Максимальное количество блоков, когда-либо выделенных для таблицы, известно как High Water Mark (HWM — дословно “отметка уровня полной воды”, маркер максимального заполнения экстента).
Сегменты
Группы экстентов выделяются для одного сегмента. Сегмент должен полностью содержаться в одном табличном пространстве. Каждый сегмент представляет один и только один тип объектов базы данных, например таблицу, раздел секционированной таблицы, индекс или временный сегмент. Для секционированных таблиц каждый раздел должен храниться в собственном сегменте; однако, кластер, состоящий из двух или больше' го числа таблиц, может храниться в одном сегменте. Секционированный индекс состоит из одного сегмента для каждого раздела индекса.
Временные сегменты выделяются по множеству сценариев. Когда опера ция сортировки не может быть выполнена в оперативной памяти, как это, например, происходит в операторе select, в котором необходимо от сортировать данные, чтобы выполнить операции distinct, group by илй union, для хранения промежуточных результатов сортировки выделяет ся временный сегмент. Поскольку выделение и освобождение временны^ сегментов происходит часто, было бы в высшей степени желательно соЗ дать табличное пространство, специально предназначенное для хранС' ния временных сегментов. Это помогает распределить запросы на
Мониторинг использования дискового пространства 221
ввод/вывод, необходимые для этой операции, а также сократить возможность фрагментации в других табличных пространствах, обусловленной постоянным выделением и освобождением временных сегментов. При создании базы данных можно для каждого нового пользователя, которому не назначено явно конкретное временное табличное пространство, создать используемое по умолчанию временное табличное пространство; если табличное пространство SYSTEM сделано локально управляемым, для хранения временных сегментов должно быть создано отдельное табличное пространство.
Метод управления дисковым пространством внутри сегмента зависит от того, как было создано табличное пространство, управляющее этим блоком. Если это табличное пространство управляется с помощью словаря, сегмент использует для управления пространством в блоках списки свободной памяти; если табличным пространством управляют локально, дисковым пространством в сегментах можно управлять как посредством списков свободной памяти, так и с помощью битовых карт. Oracle настоятельно рекомендует создавать все новые табличные пространства как локально управляемые, и чтобы управление свободным пространством в сегментах осуществлялось автоматически, с помощью битовых карт. Автоматическое управление свободным пространством в сегментах позволяет осуществить более конкурентный доступ к битовым спискам сегмента по сравнению со списками свободной памяти; вдобавок, для таблиц с сильно различающимися по размеру строками значительно более эффективным используется пространство в автоматически управляемых сегментах.
Если сегмент создается с автоматическим управлением пространством в сегментах, для управления этим пространством используются битовые карты. В результате ключевые слова pctused, freelist и freelist groups в операторах create table и create index игнорируются. Трехуровневая структура битовой карты внутри сегмента указывает, являются ли размещенные ниже HWM блоки полными (заполненными более чем на pctfree), свободными: от 0 до 25%, от 25 до 50%,- от 50 до 75%, от 75 до 100%, или не отформатированными.
Представления словаря данных и динамические представления производительности
Некоторое количество представлений словаря данных и динамических представлений производительности является критичным для понимания того, как в базе данных используется дисковое пространство. Представления словаря данных, имена которых начинаются с DBA_, имеют более статичную природу, в то время как ожидается, что представления V$ являются более динамичными и дают самые свежие статистические данные об использовании дискового пространства в базе данных.
DBA_TABLESPACES
I Представление DBA_TABLESPACES содержит по одной строке для каж* дого табличного пространства, будь то собственное или перенесенное из Другой базы данных представление. В этой строке содержатся используе
222
Гпава 6
мые по умолчанию параметры экстентов для создаваемых в таблично^ пространстве объектов базы данных, для которых не задаются значения initial и next. Столбец EXTENT JMLANAGEMENT указывает на то, являет-ся ли табличное пространство локально управляемым или управляемым с помощью словаря данных. Начиная с Oracle 10g, столбец BIGFILE указывает, относится ли табличное пространство к типу BIGFILE или нет (о табличных пространствах типа BIGFILE см. ниже в данной главе).
В следующем запросе извлекаются типы табличного пространства и управления экстентами для всех табличных пространств, входящих в базу данных:
□ SQL> select tablespace_name, block_size,
2 contents, extentjnanagement from dba_tablespaces;
TABLESPACE_NAME BLOCK_SIZE CONTENTS EXTENT_MAN
SYSTEM TOOLS TEMP USERS DATA01
DATA02 INDX01
INDX02 DATA03 UNDO
8192 PERMANENT DICTIONARY
8192 PERMANENT DICTIONARY
8192 TEMPORARY DICTIONARY
8192 PERMANENT DICTIONARY
8192 PERMANENT DICTIONARY
8192 PERMANENT DICTIONARY
8192 PERMANENT DICTIONARY
8192 PERMANENT DICTIONARY
16384 PERMANENT LOCAL
8192 UNDO LOCAL
В этом примере все табличные пространства, за исключением UNDO и DATA03, взяты из предыдущих версий Oracle (еще до выхода Огас1е8г), которые не поддерживают локально управляемые табличные пространства и поэтому являются управляемыми с помощью словаря данных. Кроме того, табличное пространство DATA03 имеет больший размер блока, чтобы улучшить время отклика для таблиц в так называемых витринах данных (data marts).
DBA_SEGMENTS
Представление словаря данных DBAJSEGMENTS содержит по одной строке для каждого сегмента в базе данных. Это представление хорош0 подходит не только для получения размера сегмента (в блоках или в баи тах), но и для идентификации владельца объекта и табличного простран ства, где размещен объект:
□ SQL> select tablespace_name, count(*) NUM_OBJECTS,
2 sum(bytes), sum(blocks), sum(extents) from dba_segments
3 group by rollup (tablespace_name);
TABLESPACE_NAME NUM-OBJECTS SUM(BYTES) SUM(BLOCKS) SUM( X 'EN S)
DATA01 104 140378112 17136
DATA02 70 206045184 25152 79
DATA03 4 41943040 2560 4
^онит°Ринг использования дискового пространства
223
INDX01 153 128974848 15744 258
INDX02 158 104071168 12704 331
SYSTEM 961 337141760 41155 2900
TEMP 1 269484032 32896 1028
TOOLS 379 228065280 27840 415
UNDO 10 21151744 2582 39
USERS 172 224395264 27392 466
2012 1701650432 205161 5638
dba.extents
Представление DBA_EXTENTS похоже на представление DBA
SEGMENTS, за тем исключением, что DBA_EXTENTS обеспечивает более глубокую детализацию каждого объекта базы данных. В представлении DBA_EXTENTS есть по одной строке для каждого экстента каждого сегмента базы данных, в которой содержатся также FILEJD и BLOCKJD для файла данных, которому принадлежит этот экстент:
□ SQL> select owner, segment_name, tablespace_name,
2 extent_id, file_id, block_id, bytes from dba_extents
3 where segment_name = ‘AUD$’;
OWNER SEGMENT.NAM TABLESPACE EXTENT.ID FILE.ID BLOCK-ID BYTES
SYS AUD$ SYSTEM 3 1 32407 196608
SYS AUD$ SYSTEM 4 1 42169 262144
SYS AUD$ SYSTEM 5 2 289 393216
SYS AUD$ SYSTEM 2 1 31455 131072
SYS AUD$ SYSTEM 1 1 30303 65536
SYS AUD$ SYSTEM 0 1 261 16384
В этом примере таблица AUD$, владельцем которой является пользователь SYS, имеет экстенты в двух различных файлах данных, из которых и состоит табличное пространство SYSTEM.
dba_free_space
Представление DBA_FREE_SPACE разбивается на части по номеру файла данных в табличном пространстве. Используя приводимый ниже запрос, можно легко определить объем свободного дискового пространства в каждом табличном пространстве:
О SQL> select tablespace_name, sum(bytes) from dba_free_space group by tablespace_name;
TABLESPACE_NAME
SUM(BYTES)
0ATA01 DATA02 DATAO3 INDXO1 INDX02 SYSTEM
279044096
213377024
157286400
395394960
420208640
14123008
224
Гпаваq
TEMP TOOLS UNDO USERS
1084219392
296214528
327876608
299884544
При подсчете свободного пространства не принимается во внимание пространство, которое может стать доступным при автоматическом рас~ ширении табличного пространства. Кроме того, любое дисковое пространство, выделенное таблице для строк, которые впоследствии были удалены, становится доступным для последующих вставок в таблицу, Но оно нс учтено в результатах предыдущего запроса как пространство, дос. тупное для других объектов базы данных. Когда происходит усечение таблицы, это пространство становится доступным для других объектов базы данных.
DBA_LMT_FREE_SPACE
Представление DBA_LMT_FREE_SPACE предлагает количество свободного пространства в блоках для всех локально управляемых табличных пространств. Для получения имен табличных пространств это представление должно быть соединено с представлением DBA_DATA_FILES.
DBAJTHRESHOLDS
Являющееся новинкой в Oracle 10g представление DBAJTHRESHOLDS содержит активный в настоящее время список различных показателей (метрик), которые оценивают состояние базы данных и определяют условия, при выполнении которых должно быть опубликовано предупреждение, если величина показателя превысит определенное значение.
Фигурирующие в этом приложении величины обычно поддерживаются через интерфейс OEM; дополнительно к этому встроенный пакет PL/SQL для Oracle 10g, который называется DBMS_SERVER_ALERT, может устанавливать и получать значения порогов с помощью процедур SET_ THRESHOLD и GETJTHRESHOLD соответственно. Чтобы прочесть сообщения о предупреждениях из очереди предупреждений, можно использовать пакеты DBMS_AQh DBMS_AQADM. Кроме того, можно сконфигурировать OEM таким образом, чтобы при превышении порогового значения посылать сообщение на пейджер или по адресу электронной почты.
Для выполняемой по умолчанию инсталляции Oracle К^конфигури руется множество различных порогов, включая следующие:
По меньшей мере один сеанс пользователя блокируется каждую ми нуту в течение трех последовательных минут.
Ни один сегмент не может быть расширен-йо какой бы то ни был0 причине.
Общее число одновременно выполняющихся процессов составляв не более 80% от значения параметра инициализации PROCESSES-
Более двух недействительных объектов у какого-либо индивидуаЯЬ ного пользователя базы данных.
Мониторинг использования дискового пространства
225
Общее число одновременно выполняющихся сеансов пользователей составляет не более 80% от значения параметра инициализации SESSIONS.
Более 1200 одновременно открытых курсоров.
Более 100 входов в систему за 1 сек.
Табличное пространство заполнено более чем на 85% (предупреждение) или более чем на 97% (критическая ситуация).
Время входа в систему для пользователя превысило 1000 миллисекунд (1 сек).
DBA_OUTSTANDING_ALERTS
Представление для Oracle 10g DBA_OUTSTANDING_ALERTS содержит по одной строке для каждого активного предупреждения в базе данных, пока оно не будет очищено или сброшено. В одном из полей этого представления, SUGGESTED_ACTION, содержится рекомендация по разрешению этой аварийной ситуации.
DBA_ALERT_HISTORY
После того как предупреждение из DBA_OUTSTANPING_ALERTS было разрешено в Oracle 10gи очищено, запись этого очищенного предупреждения может быть получена из представления DBA_ALERT_HISTORY.
V$ALERT_TYPES
В динамическом представлении производительности V$ALERT_TYPES, впервые появившемся в Oracle 10g, перечислено 113 аварийных ситуаций (для Oracle 10g, Release 1), которые могут быть подвергнуты мониторингу. В столбце GROUP_NAME аварийные ситуации разделены на категории по типам. Так, например, если вас интересуют вопросы управления дисковым пространством, вам необходимо использовать предупреждения с GROUP_NAME, равным ‘Space’:
О SQL> select reason_id, object-type, scope, internal_metric_category,
2 internal_metric_name from v$alert_types
3 where group_name = ‘Space’;
REASON_ID OBJECT TYPE
11 ROLLBACK-SEGMENT
13 ROLLBACK-SEGMENT
0 SYSTEM
1 SYSTEM
9 TABLESPACE
10 TABLESPACE
12 TABLESPACE
14 DATA OBJECT
15 QUOTA
123 RECOVERY AREA
SCOPE INTERNAL_METRIC_CATE INTERNAL_METRIC_
Database 8nap_Shot_Tco_Cld Rollback-Segment Database Suspended-Session Rollback-Segment Instance
Instance
Database problemTbsp pctUsed
Database Snap-Shot_Too_01d Tablespace
Dai abase Suspended-Session Tablespace Database Suspended-Session Data_Object Database Suspended-Session Quota
Database Recovery_Area Free_Space
226
Гпава 6
Используя в качестве примера предупреждение с REASONJD = 123, можно инициировать предупреждение, когда размер свободного пространства в области восстановления базы данных упадет ниже определенной процентной доли.
V$UNDOSTAT
Проблемой является и слишком большой, и слишком малый размер пространства отката. Хотя, когда пространство отката оказывается не в состоянии обеспечить достаточный объем истории транзакций для удовлетворения ретроспективных запросов (flashback queries) или данных об исходном виде записей, чтобы избежать появления сообщения об ошибке “Snapshot Too Old”, АБД может взять инициативу в свои руки. Для этого достаточно провести мониторинг представления динамической производительности V$UNDOSTAT в периоды интенсивного использования базы данных.
Представление V$UNDOSTAT отражает данные о предыстории процесса потребления пространства отката с десятиминутными интервалами. Анализируя результаты из этой таблицы, АБД может принимать информационно подтвержденные решения при настройке размеров табличного пространства для отката транзакций или изменении значения параметра инициализации UNDO_RETENTION.
V$OBJECT_USAGE
Если индекс не используется, он не только занимает в табличном пространстве место, которое можно было бы использовать для других объектов, но и приводит к напрасной трате времени, расходуемого на обслуживание индекса при выполнении операций insert, update и delete (так называемые накладные расходы). В результате применения команды alter index... monitoring usage, представление V$OBJECT_USAGE будет изменяться при каждом непрямом обращении к индексу вследствие выполнения команды select.
V$SORT_SEGMENT
Представление V$SORT_SEGMENT может быть использовано для знакомства с выделением и освобождением дискового пространства в сегментах сортировки временных табличных поостранств. Столбец CURRENT_USERS показывает, сколько различных пользователей ис пользует заданный сегмент. В V$SORT_SEGMENT заносится только ин формация о временных табличных пространствах.
V$TEMPSEG_USAGE
С точки зрения пользователей, делающих запросы к временным сегмеН там, представление V$TEMPSEG_USAGE определяет адреса размещения» типы и размеры временных сегментов, к которым в данный момент йМе ются обращения. В отличие от V$SORT_SEGMENT, представлений V$TEMPSEG_USAGE будет содержать информацию относительно вре' менпых сегментов как во временных, так и в постоянных табличных при странсгвах.
МоНИторинг использования дискового пространства
227
Методики управления дисковым пространством
Локально управляемые табличные пространства предлагают АБД множество преимуществ, повышающих производительность объектов в базе данных и облегчающих администрирование табличного пространства — фрагментацию табличного пространства можно считать оставшейся в прошлом. Опция Oracle Managed Files (управляемые Oracle файлы), впервые появившаяся в Огас1е9г, упрощает обслуживание файлов данных за счет автоматического удаления файлов на уровне операционной системы при удалении табличного пространства или какого-то другого объекта базы данных. Табличные пространства типа Bigfile, введенные в Oracle 10g, упрощают управление файлами данных, так как в таком табличном пространстве может содержаться только один файл данных. Это переносит обслуживание на один уровень выше — с уровня файла данных на уровень табличного пространства. Ниже в данной главе будут рассмотрены две другие возможности, появившиеся в Огас1е9г — табличные пространства отката и несколько размеров блоков.
Локально управляемые табличные пространства
До выхода Огас1е8г существовал только один способ управления свободным пространством в табличных пространствах — использование таблиц словаря данных в табличном пространстве SYSTEM. Если в базе данных отмечалась высокая активность действий по вставке, обновлению и удалению, появлялась потенциальная возможность возникновения так называемой “горячей точки (hot spot) в табличном пространстве SYSTEM, где происходит управление пространством. Сегодня Oracle устранил это потенциальное ’’узкое место", введя так называемые локально управляемые табличные пространства {Locally Managed Tablespaces - LMT). В локально управляемом табличном пространстве отслеживание свободного пространства ведется с помощью битовых карт (см. главу 1). Этими битовыми картами можно управлять весьма эффективно, так как они очень компактны по сравнению со списками свободной памяти для имеющихся в наличии блоков. Поскольку они хранятся в самом табличном пространстве, а не в таблицах словаря данных, конкуренция За обладание табличным пространством SYSTEM снижается.
Начиная с Oracle 10g, по умолчанию подразумевается, что все табличные пространства создаются как локально управляемые, в том числе, и табличные пространства SYSTEM и SYSAUX. Если табличное пространство SYSTEM является локально управляемым, становится невозможно создавать в базе данных какие-либо управляемые с помощью словаря данных табличные пространства, которые были бы открыты на чтение/запись. Управляемые с помощью словаря данных табличные пространства можно вставить в базу данных, но они будут открыты только для чтения.
Ооъекты в LMT могут иметь экстенты только какого-то одного из двух возможных типов: либо автоматически присваиваемый размер, либо только один общий размер экстентов. Если для выделения экстентов при создании табличного пространства было использовано ключевое слово UNIFORM, все экстенты, как и следует ожидать, будут иметь один и тот же размер. Так как все экстенты имеют одинаковый размер, фрагмента
228
Гпава 6
ции в таком табличном пространстве быть не может. Ушел в прошлое классический пример с сегментом размером в 51 Мбайт, который невозможно разместить в табличном пространстве, состоящем из двух свобод-ных экстентов размером 50 Мбайт, так как эти 50-мегабайтные экстенты не являются смежными.
С другой стороны, при автоматическом управлении сегментами и экстентами в локально управляемом табличном пространстве пространство выделяется автоматически на основании размера объекта. Первоначально выделяемые экстенты (initial) малы по размеру, и, если объект остается маленьким, оказывается, что и потери пространства тоже невелики. Если после того, как для нее был выделен первоначальный экстент, таблица начинает расти, последующие выделяемые экстенты будут иметь больший размер. Экстенты в LMT с автоматическим выделением пространства имеют размеры 64 Кбайт, 1 Мбайт, 8 Мбайт и 64 Мбайт, и размер выделяемого экстента растет вместе с увеличением размера сегмента до 64 Мбайт. Другими словами, Oracle специфицирует, что значения параметров INITIAL, NEXT и PCTINCREASE являются автоматически регулируемыми и зависят от того, как растет размер. Хотя кажется, что в табличных пространствах с автоматическим выделением памяти возможна фрагментация, на практике фрагментация будет минимальной. Это связано с тем, что новый объект с первоначальным размером сегмента в 64 Кбайт будет прекрасно “укладываться” в предварительно выделенные для всех других объектов блоки размером в 1 Мбайт, 4 Мбайт, 8 Мбайт или 64 Мбайт с первоначальным размером экстента 64 Кбайт.
Если есть LMT с однородными или с автоматически управляемыми экстентами, управление свободным пространством внутри самого сегмента может быть либо автоматическим (AUTO), либо ручным (MANUAL). При автоматическом управлении свободным пространством в сегменте для указания того, сколько свободного пространства имеется в сегменте, используются битовые карты. При создании сегмента больше не требуется задавать параметры PCTUSED, FREELISTS и FREELIST GROUPS. Вдобавок, повышается производительность одновременно выполняющихся операций DML, так как к битовой карте сегмента возможен параллельный (concurrent) доступ. Когда кто-то из пользователей начинает поиск свободного блока в сегменте, то в сегменте, управляемом с помощью списка свободной памяти, блок данных в заголовке сегмента, в котором содержится список свободной памяти, блокируется для всех других пользователей, пытающихся что-то записать в него. Хотя выделе ние нескольких списков свободной памяти для особо активных сегмен тов до некоторой степени решает проблему, это приводит к создан#* еще одной структуры, которой необходимо управлять АБД.
Другое преимущество LMT состоит в том, что при выполнении or ера ции, связанной с выделением памяти в LMT, сокращается или полностью устраняется информация для откат?. Поскольку обновление битовой кар ты в табличном пространстве не фиксируется в таблицах словаря Да* ных, для этой транзакции не генерируется никакой информации Д^ отката.
Если не считать приложений от третьих фирм, например SAP, для К° торых требуются управляемые с помощью словаря данных табличны6
Мониторинг использования дискового пространства
229
пространства, в Oracle 10gполностью исчезли причины для создания новых табличных пространств, управляемых с помощью словаря данных. Поддерживается частичная совместимость, призванная разрешить включать в базы данных Oracle 10g табличные пространства, управляемые с помощью словаря данных, из более старых версий Oracle. Но если табличное пространство SYSTEM было создано локально управляемым, любое табличное пространство, управляемое с помощью словаря данных, может быть открыто только для чтения. Ниже приводится несколько примеров, где производительность и использование пространства можно оптимизировать с помощью перемещения табличного пространства из одной базы данных в другую и выделением дополнительных буферов данных для табличных пространств разного размера.
Перемещать управляемое с помощью словаря данных табличное пространство в локально управляемое пространство очень просто, если воспользоваться встроенным пакетом DBMS_SPACE_ADMIN:
□ execute sys.dbrns_space_admin.tablespacejnigrate_to_local(‘USERS’)
После проведения апгрейда базы данных до Огас1е9гили Oracle 10gMO-жет возникнуть желание перевести табличное пространство SYSTEM в LMT. В таком случае необходимо выполнить следующие действия:
•
Перед запуском процедуры переноса (миграции) следует остановить базу данных и выполнить процедуру холодного (т. е. при неработающей базе данных. — Прим, пер.) резервного копирования базы данных.
Все табличные пространства за исключением SYSTEM, которые должны остаться работающими в режиме чтения/записи, следует перевести в LMT.
Используемое по умолчанию временное табличное пространство не должно совпадать с SYSTEM.
Если используется автоматическое управление пространством отката, табличное пространство отката должно быть в онлайновом состоянии.
На протяжении всего процесса конвертирования все табличные пространства за исключением табличного пространства отката должны быть переведены в режим только для чтения.
На протяжении всего процесса конвертирования база данных должна быть запущена в режиме RESTRICTED.
Если любое из этих условий не будет выполнено, процедура TABLESPACE_MIGRATE_TO_LOCAL не выполнит процесс миграции.
Использование 0MF для управления дисковым пространством
OMF (Oracle Managed Files—управляемые Oracle файлы) упрощают администрирование базы данных Oracle. Во время создания базы данных (или Позже) путем изменения пары параметров в файле параметров инициализации АБД может определить некоторое количество используемых по умолчанию адресов размещения таких объектов базы данных, как файлы
230
Гпава 6
данных, а также журнальные и управляющие файлы. До появления Огас1е9г АБД приходилось вспоминать, где именно хранятся файлы данных, задавая запрос к представлениям DBA_DATA_FILES и DBA_TEMP_ FILES. Во многих случаях АБД мог удалить табличное пространство, но при этом забыть удалить составлявшие его файлы данных; при этом понапрасну терялись дисковое пространство и время, которое требуется для резервного копирования тех файлов, которые более не используются базой данных.
С помощью OMF Oracle не только автоматически создает и удаляет файлы в конкретных каталогах, но и гарантирует, что каждый такой файл будет иметь уникальное имя. Это позволяет избежать разрушения и простоя базы данных, которые имели место в средах, где не применялись OMF, потому что существующие файлы непреднамеренно перезаписывались администраторами, которые создавали новые файлы данных с тем же именем, что и у существующего файла данных, и использовали фразу REUSE.
В среде разработки или тестирования OMF сокращает количество времени, которое АБД должен потратить на управление, и позволяет ему сосредоточиться на приложениях и прочих аспектах тестовой базы данных. У OMF имеются дополнительные преимущества для “коробочных” приложений, которым требуется создавать табличные пространства: сценарии, создающие новые табличные пространства, не нуждаются в модификации для включения имени файла данных, что увеличивает вероятность успешного развертывания приложения.
Переходить от сред, не использующих OMF, к средам с OMF просто. Переход можно завершить через длительный промежуток времени. Файлы OMF и обычные файлы могут неопределенно долгое время сосуществовать в одной базе данных. Если заданы подходящие параметры инициализации, все новые файлы данных, управляющие и журнальные файлы могут создаваться как OMF-файлы. В то же самое время все существовавшие к этому моменту файлы могут продолжать быть управляемыми вручную до тех пор, пока они не будут конвертированы в OMF, если это вообще будет когда-либо сделано.
Связанные с OMF параметры инициализации приведены в таблице 6.1.
Путь операционной системы, указанный для любого из этих параметров инициализации, должен уже существовать, так как Oracle не создает каталогов. Кроме того, эти каталоги должны быть доступны для той учетной записи операционной системы, которая владеет программны^ обеспечением Oracle (для большинства платформ это учетная запись oracle).
Табличные пространства типа Bigfile
Табличные пространства типа Rigfile, впервые появившиеся в Oracle 10$ поднимают OMF-файлы на новый уровень; в табличном простри* стве выделяется место только “для одного файла данных и оно моЖ иметь размер до 8 экзабайт.
Мониторинг использования дискового пространства
231
Таблица 6.1. Параметры инициализации, относящиеся к OMF
Параметр инициализации
Описание
DB_CREATE_FILE_DEST
DB_CREATE_ONL!NE_LOG_DEST_n
DB_RECOVERY_FILE_DEST
Используемый по умолчанию каталог операционной системы, в котором создаются файлы данных, если в команде create tab’nsp?-ce не указано имя пути. Этот же адрес используется для хранения журнальных и управляющих файлов, если не специфицирован параметр DB_CREATE_ONLINE_LOG_ DESTjr
Определяет используемый по умолчанию адрес хранения журнальных и управляющих файлов, если при создании базы данных для них не было указано имя пути. С помощью этого параметра может быть указано до пяти пунктов назначения, что позволяет иметь до пяти мультиплексированных управляющих файлов и до пяти членов для каждой группы файлов журналов базы данных.
Определяет используемое по умолчанию имя пути в файловой системе сервера, в котором сохраняются резервные копии RMAN, архивные журналы и журналы ретроспекции. Кроме того, он может использоваться для журнальных и управляющих файлов, если не указаны параметры DB_CREATE_ FILE_DEST и/или DB_CREATE_ONLINE_LOG_DEST_n X •
Табличные пространства типа Bigfile могут быть только локально управляемыми с автоматическим управлением пространством в сегментах. Если табличное пространство типа Bigfile используется для автоматического отката или для хранения временных сегментов, то управление пространством в сегментах должно быть установлено на MANUAL.
Табличные пространства типа Bigfile могут экономить место в системной глобальной области (SGA) и в управляющих файлах, так как требуется отслеживать меньшее число файлов данных. Во всех командах alter tablespace для табличных пространств типа Bigfile не требуются ссылки на файлы данных, поскольку с каждым таким табличным пространством связан один и только один файл данных. В результате точка обслуживания переносится с физического уровня (уровень файлов данных) на логический уровень (табличные пространства), упрощая администрирование.
Для создания табличного пространства типа Bigfile достаточно добавить в команду create tablespace ключевое слово bigfile:
SQL> create bigfile tablespace whs01
2 datafile ‘f:\asm\orcl02.dbf’ size ‘10p;
Tablespace created.
Если используется OMF, фраза datafile может быть опущена. Для определения размера табличного пространства типа Bigfile можно использовать фразу resize:
232
Гпава 6
□ SQL> alter tablespace whsO1 resize 80g; Tablespace altered.
В этом сценарии даже 80 Гбайт оказывается недостаточно для разме щения табличного пространства, так что для него разрешается автомати ческое расширение “порциями” по 20 Гбайт:
□ SQL> alter tablespace whs01 autoextend on next 20g; Tablespace altered.
Обратите внимание на то, что в обоих случаях нам не приходится указывать имя файла данных; имеется всего один файл данных, и после того как табличное пространство создано, нам более не требуется углубляться в детали образующих табличное пространство файлов данных и того, как ими управлять.
Табличные пространства типа Bigfile предназначаются для использования со средой автоматического хранения данных (ASM).
Среда автоматического хранения данных
Использование Automatic Storage Management (ASM— среда автоматического хранения данных) может значительно сократить административные накладные расходы на управление дисковым пространством в базе данных, так как при выделении памяти для табличного пространства или другого объекта базы данных администратору достаточно только специфицировать дисковую группу ASM. Файлы базы данных будут автоматически распределены межу всеми доступными дисками, входящими в дисковую группу, и такое распределение будет автоматически обновляться при каждом изменении конфигурации дисков Например, если к имеющимся дисковым группам экземпляра ASM будет добавлен новый дисковый том, все файлы данных в составе этой дисковой группы будут перераспределены, чтобы был задействован и новый том.
Поскольку ASM автоматически размещает файлы данных по нескольким дискам, производительность запросов и операторов DML возрастает, так как ввод/вывод разделяется между несколькими дисками. При желании входящие в состав ASM диски могут быть зеркалированы, чтобы обеспечить дополнительную избыточность данных и выигрыш в производительности.
Использование ASM дает множество и других преимуществ, зачастую вместо покупного диспетчера томов от третьих фирм или вместо подсис темы сетевого хранения данных (Network Attached Storage, NAS) могу1 быть использованы экземпляр ASM и определенное количество физике ских дисков. Дополнительное преимущество ASM перед диспетчерам** томов состоит в том, что для выполнения операций обслуживания АЬ не требуется остановки базы данных даже в тех случаях, когда необхоД** мо добавить или удалить диск в/из дисковой группы.
Избыточность дисковой группы
Дисковая группа в ASM представляет собой совокупность одного или скольких дисков ASM, управление которыми осуществляется как единЫ^ объектом. Диски могут добавл.чться в дисковую группу или удаляться 113
Мониторинг использования дискового пространства 233
нее без остановки базы данных. При каждом добавлении или удалении диска ASM автоматически выполняет балансировку файлов данных на дисках, чтобы довести до максимума избыточность и производительность ввода / вывода.
В дополнение к преимуществам высокой избыточности дисковая группа может быть использована более чем одной базой данных. Это помогает максимизировать инвестиции в физические дисковые накопители, позволяя легко изменять выделение дискового пространства различным базам данных, потребности которых в дисковой памя i и могут изменяться в течение дня или года.
Три типа дисковых групп — это группы с нормальной, высокой и внешней избыточностью. Группы с нормальной и высокой избыточностью требуют, чтобы ASM обеспечивала избыточность для хранящихся в группе файлов. Различие между группами с нормальной и с высокой избыточностью состоит в количестве требующихся для них так называемых групп отказов (failure group — наборов дисков, разделяющих общие ресурсы, для которых требуется защита от сбоя. — Прим. пер.}. Дисковая группа с нормальной избыточностью обычно имеет две группы отказа, а у группы дисков с высокой степенью избыточности есть не менее трех групп отказов. Можно сказать, что группе отказов в ASM соответствует член группы файлов журналов базы данных в случае использования традиционного управления файлами данных Oracle. Для обеспечения внешней избыточности требуется, чтобы избыточность предоставлялась посредством механизма, не являющегося частью ASM (например, с помощью RAID-массива). Дисковая группа может также содержать незеркалированный дисковый том, используемый ддя открытых только для чтения табличных пространств, которые нетрудно создать заново при выходе дискового тома из строя.
Экземпляр ASM
Для ASM требуется выделенный экземпляр Oracle, как правило, на том же самом узле, что и база данных, использующая эту группу ASM. В среде Oracle Real Application Clusters (RAC) у каждого узла базы данных RAC имеется собственный экземпляр ASM.
Экземпляр ASM никогда не монтируется с базой данных, он всего лишь координирует дисковые тома для других экземпляров баз данных. В дополнение весь ввод/вывод от экземпляра базы данных идет непосредственно к дискам в составе дисковой группы Однако, все обслуживание дисковой группы проводится в экземпляре ASM; в итоге, размер оперативной памяти, требующейся для поддержки работы экземпляра ASM, может быть сокращен до 64 Мбайт.
Подробнее о конфигурировании ASM для работы в среде RAC см. гла-
Фоновые процессы
в экземпляре ASM можно найти два новых фоновых процесса. Фоновый Процесс RBAL координирует автоматические дейс гвия дисковой группы По восстановлению баланса (перебалансировке) для дисковой группы. Фоновый процесс ORBO в параллельном режиме выполняет все фактические действия по перебалансировке.
234
Гпава. 6
Создание объектов с использованием ASM
Прежде чем база данных сможет начать использовать дисковую группу ASM, опа должна быть создана с помощью экземпляра ASM. В следующем примере создается новая дисковая группа KJM68 для управления диско* выми томами Unix /dev/hdal, /dev/hda2, /dev/hdbl, /dev/hdcl и /dev/hdd4:
□ SQL> create diskgroup kjm68 normal redundancy
2 failgroup mir1 disk ‘/dev/hda1’, ‘/dev/hda2’f
3 failgroup mir2 disk ‘/dev/hdb1’,.‘/dev/hdc1’, ‘/dev/hdd4’;
Когда специфицируется дисковая группа с нормальной избыточно* стью, должны быть указаны как минимум две группы отказа, чтобы можно было обеспечить двукратное зеркалирование для любых файлов, создаваемых в дисковой группе.
В экземпляре базы данных, использующем дисковую группу, для создания файлов данных для логических структур базы данных применяется OMF в сочетании с ASM. В приведенном ниже примере устанавливается значение параметра инициализации DB_CREATE_FILE_DEST, использующее дисковую группу, чтобы любые табличные пространства, созданные с использованием OMF, автоматически получали имена и размещались в дисковой группе KJM68:
□ db_create_file_dest = ‘+kjm68’
Теперь создадим в этой дисковой группе табличное пространство. Это очень просто:
□ SQL> create tablespace lob_video;
После того как был создан файл ASM, автоматически сгенерированное для него имя можно найти в представлениях V$DATAFILE и V$LOGFILE, там же, где и сгенерированные вручную имена файлов-С использованием ASM можно создавать все типовые файлы базы ДаН' ных за исключением административных, к числу которых относятся трассировочные файлы, сигнальные файлы ALERT, файлы резервны* копий, файлы экспорта и дампа ядра.
Анализ управления пространством отката
Создание табличного пространства отката обеспечивает много nPeILN^ ществ как для АБД, так и для типичного пользователя базы данных- Д' АБД остаются в прошлом проблемы, связанные с управлением сегмо ми отката, — всеми сегментами отката в табличных пространствах от теперь автоматически управляет Oracle. В дополнение к обеспечены10 гласованных по чтению представлений объектов базы данных для телей” базы данных во время выполнения длительной транзакции ь этими объектами, табличное пространство отката способно обеспе пользователю механизм для восстановления строк таблицы. {1-
Достаточно большое табличное пространство отката сводит к муму возможность появления ставшего уже классическим сообщений опти^ке: “Snapshot too old” (Слишком старый моментальный снимок)»
Мониторинг использования дискового пространства
235
каким должен быть достаточный размер пространства отката? Если оно слишком мало, то так называемое окно доступности (availability window) для ретроспективных запросов (flashback queries) будет слишком коротким; а если сделать его слишком большим, будет напрасно израсходовано дисковое пространство, а операции по резервному копированию могут занимать больше времени, чем это необходимо.
Для управления выделением и использованием табличных пространств отката используются несколько параметров инициализации. Параметр UNDOJMANAGEMENТ указывает, используется ли автоматическое (AUTOMATIC) управление пространством отката, а параметр UNDO_TABLESPACE специфицирует само табличное пространство. После изменения любого из этих параметров необходимо остановить и снова запустить экземпляр, чтобы внесенные изменения вступили в силу. Параметр UNDOJRETENTION, задаваемый в секундах, определяет минимальное время, в течение которого информация об откатах будет сохранена для использования ее в ретроспективных запросах. Однако при слишком малом размере пространства отката и высокой интенсивности операций DML часть требующейся информации об откате может оказаться затертой новой информацией еще до истечения периода времени, заданного параметром UNDO_RETENTION.
Впервые появилась в Oracle 10g фраза RETENTION GUARANTEE команды CREATE UNDO TABLESPACE. Действие этой фразы сводится к тому, что в созданном с ее использованием табличном пространстве информация об откате с не истекшим сроком хранения не будет затерта новой информацией, даже если это будет достигнуто ценой аварийного завершения операторов DML, если для их выполнения в табличном пространстве отката окажется недостаточно места (подробнее об этой фразе см. главу 7).
Следующие параметры инициализации делают возможным автоматическое управление пространством отмены для табличного пространства UNDO04 с использованием периода сохранения данных в нем не менее 24 часов:
П undojnanagement = auto undo_tablespace = undo04 undo_retention = 86400
Динамическое представление производительности V$UNDOSTAT может помочь в правильном определении размера табличного пространст-^а_°тката ДЛЯ тРанзакционн°й нагрузки в пиковые периоды обработки.
VSUNDOSTAT каждые 10 минул' вставляется новая строка, представляющая моментальный снимок использования табличного пространства отмены:
° SQL> select to_char (end.time, ‘yyyy-mm-dd hh24:mi’) end_time, г undoblocks, ssolderrcnt from v$undostat;
end_time undoblks ssolderrcnt
2004-01-23 10:28 522 о
2004-01-23 10:21 1770 о
236
Г.пава 6
2004-01-23 10:11 857 0
2004-01-23 10:01 1605 0
2004-01-23 09:51 2864 3
2004-01-23 09:41 783 0
2004-01-23 09:31 1543 0
2004-01-23 09:21 1789 0
2004-01-23 09:11 890 0
2004-01-23 09:01 1491 0
В этом примере пик в пространстве отката имел место в интервале от 9 ч 41 мин утра до 9 ч 51 мин, в результате чего ситуация “Snapshot too old” была зафиксирована для трех запросов. Чтобы избежать подобных ошибок, необходимо либо вручную установить больший размер табличного пространства отката, либо предоставить ему возможность автоматического расширения.
Мониторинг и использование табличного пространства SYSAUX
Табличное пространство SYSAUX, впервые появившееся в Oracle 10g, является дополнительным к табличному пространству SYSTEM, и в нем хранятся данные для нескольких компонентов базы данных Oracle, которые в предыдущих версиях Oracle либо использовали для этой цели собственные табличные пространства, либо пользовались табличным пространством SYSTEM. В число таких компонентов входит Enterprise Manager Repository, который ранее хранился в табличном пространстве OEM-REPOSITORY, а также LogMiner, Oracle Spatial и Oracle Text, которые для хранения конфигурационной информации ранее использовали табличное пространство SYSTEM. Узнать о том, какие именно компоненты в данный момент заполняют табличное пространство SYSAUX, можно, сделав запрос к представлению V$SYSAUX_OCCUPANTS:
□ SQL> select occupant-name, occupant_desc, space_usage_kbytes
2 from v$sysaux_occupants;
OCCUPANT_NAME
OCCUPANT_DESC
SPACE_USAGE_KBYTES
LOGMNR LOGSTDBY STREAMS A0 XSOQHIST SM/AWR SM/Advisor SM/OPTSTAT SM/OTHER STATSPACK ODM SDO WM
LogMiner
Logical Standby
Oracle Streams
Analytical Workspace Object Table
OLAP API History Table
Server Manageability - Automatic Workload Repository
Server Manageability - Advisor Framework
Server Manageability - Optimizer Statistics History
Server Manageability - Other Components
Statspack Repository
Oracle Data Mining
Oracle Spatial
Workspace Manager
7488 0
192 960
960 73216 6144 15SO0 3776
0
608° бб56
Мониторинг использования дискового пространства
237
ORDIM Oracle interMedia ORDSYS Components 512
ORDIM/PLUGINS Oracle interMedia ORDPLUGINS Components 0
ORDIM/SQLMM Oracle interMedia SI_INFORMTN_SCHEMA Components 0
EM Enterprise Manager Repository 61376
TEXT Oracle Text 4736
ULTRASEARCH Oracle Ultra Search 7296
JOB-SCHEDULER Unified Job Scheduler 256
20 rows selected.
Если табличное пространство SYSAUX переведено в автономный режим или почему-то оказалось разрушенным, недоступными становятся только эти компоненты базы данных Oracle; основная функциональность базы данных окажется незатронутой. В любом случае табличное пространство SYSAUX помогает снять нагрузку с табличного пространства SYSTEM при нормальном функционировании базы данных.
Для мониторинга использования табличного пространства SYSAUX можно задать запрос к столбцу SPACE_USAGE_KBYTES, как это обычно делается, в результате чего АБД будет предупрежден, если использование пространства станет больше определенного уровня. Если потребление пространства конкретным компонентом становится таким, что требуется выделить для него отдельное табличное пространство, например для репозитория ЕМ, то процедура, указанная в столбце MOVE-PROCEDURE представления V$SYSAUX-OCCUPANTS, перенесет такое приложение в другое табличное пространство:
□ SQL> select occupant_name, move_procedure from v$sysaux_occupants
2 where occupant_name = ‘EM’;
OCCUPANT_NAME MOVE-PROCEDURE
EM emd_maintenance. rnove_em_tblspc
В следующем сценарии известно, что в ближайшем будущем понадобится добавить в управляющий репозиторий несколько сот узлов. Поскольку нежелательно, чтобы табличное пространство SYSAUX выросло слишком сильно, мы принимаем решение о создании нового табличного пространства для хранения данных только для утилиты Enterprise Manager. В следующем примере создается новое табличное пространство и утилита Enterprise Manager переносится в это новое табличное пространство:
О SQL> create smallfile tablespace EM_REP
2 datafile ‘f:\oem\orcl05.dbf’ size 10g
3 autoextend on next 5g;
Tablespace created.
SQL> execute sysman.emd_maintenance.move_em_tblspc(‘EM_REP’);
PL/SQL procedure successfully completed.
SQL> select occupant_name, occupant_desc, space_usage_kbytes
2 from v$sysaux_occupants
3 where occupant_name = ‘EM’;
238
Гпава 6
OCCUPANT NAME OCCUPANT_DESC
SPACE_USAGE_KBYTES
EM Enterprise Manager Repository (репозиторий EM)
1 row selected.
Строка для Enterprise Manager по-прежнему находится в V$SYSAUX OCCUPANTS; хотя она и не занимает никакого места в табличном пространстве SYSAUX, в какой-то момент времени в будущем может потребоваться переместить ее метаданные обратно в SYSAUX. Следовательно, необходимо повторно сделать запрос к V$SYSAUX_OCCUPANTS и получить из него процедуру перемещения. Одна и та же процедура используется для перемещения приложения в (и из) SYSAUX:
□ SQL> execute sysman.emd_maintenance.move_em_tblspc(‘SYSAUX’); PL/SQL procedure successfully completed.
Если какой-то компонент (например, Ultra Search) вообще не используется базой данных, то в табличном пространстве SYSAUX используется очень незначительный объем пространства.
Управление файлами архивных журналов базы данных
Важно рассмотреть вопросы управления дисковым пространством для объектов, существующих вне базы данных, например, для файлов архивных журналов базы данных. В режиме ARCHIVELOG онлайновый файл журнала базы данных копируется по адресу (адресам), указанному в ^OG_ ARCHIVE_DEST_n (где п является целым числом от 1 до 10).
Копируемый журнал должен быть успешно скопирован, по крайней мере, по одному из указанных адресов, прежде чем он снова сможет быть использован базой данных. Параметр LOG_ARCHIVE_MIN_SUCCEED„ DEST по умолчанию имеет значение 1 и не должен быть меньше 1. Если ни одна из операций копирования не оказалась успешной, база данных приостанавливает свою деятельность до тех пор, пока файл журнала базы данных не будет скопирован хотя бы по одному из указанных адресов. Одной из возможных причин подобной неудачи может быть нехватка места на диске.
Если адрес размещения файла архивного журнала базы данных является локальным, провести мониторинг использования пространства в этом каталоге может основной сценарий операционной системы, либо та] ои мониторинг может быть спланирован с помощью пакета DB SCHEDULER или OEM.
Встроенные инструменты управления дисковым пространством
В версии Oracle 10g предлагается значительное число встроенных инс'1 рументов для АБД, с помощью которых он может при желании увидеть, есть ли в базе данных какие бьцто ни было проблемы с использованием дискового пространства. Большинство этих инструментов, если не все они, могут быть сконфигурированы вручную и выполняться в результате вызова соответствующего пакета.
Мониторинг использования дискового пространства
239
Консультант по сегментам
В результате частого выполнения операций вставки, изменения и удаления для таблицы, занимаемое таблицей дисковое пространство с течением времени может оказаться сильно фрагментированным. Программное обеспечение Oracle может выполнять для таблиц и индексов так называемое сжатие сегментов (segment shrink). Освободившееся при сжатии сегмента пространство становится дос тупным другим сегментам, что потенциально является основой улучшения операций DML над сегментом после его сжатия, так как после сжатия для выполнения операции DML требуется прочесть меньшее число блоков с диска. Сжатие сегментов очень напоминает онлайновое переопределение таблицы, при котором восстанавливается пространство. Однако сжатие сегментов может быть выполнено “по месту” без выдвижения таких требований к дополнительному дисковому пространству, какие выдвигаются при онлайновом переопределении таблицы.
Для определения сегментов, которые получат выигрыш от сжатия сегментов, можно вызвать утилиту Segment Advisor (консультант по сегментам) для выполнения анализа трендов роста указанных сегментов. В этом разделе будет вызван Segment Advisor для нескольких специально отобранных сегментов, которые могут оказаться наиболее поверженными фрагментации.
В следующем примере Segment Advisor настраивается для мониторинга таблицы HR.EMPLOYEES. В последние месяцы для этой таблицы была отмечена высокая активность; кроме того, в нее был добавлен новый столбец WORK_RECORD, который кадровая служба использует для ведения комментариев о служащих:
□ SQL> alter table hr.employees add (work_record varchar2(4000));
Table altered.
SQL> alter table.employees enable row movement;
Tab e altered.
Мы активировали для этой таблицы ROW MOVEMENT (перемещение строк), так что теперь над таблицей могут быть проведены операции сжатия сегментов, если они будут рекомендованы Segment Advisor.
После того вызова утилиты Segment Advisor для выдачи рекомендаций эти самые рекомендации можно обнаружить в представлении словаря данных DBA_ADV1SOR_FINDINGS. Чтобы показать потенциальные преимущества сжатия сегментов в тех случаях, когда Segment Advisor рекомендует выполнить операцию сжатия сегментов, представление DBA ADVISOR_RECOMMENDATIONS предлагает рекомендуемую операцию сжатия сегментов вместе с потенциальным выигрышем для этой операции в байтах.
Для настройки Segment Advisor для анализа таблицы HR.EMPLOYEES используется анонимный блок PL/SQL:
а а ь анализ таблицы HR.EMPLOYEE утилитой Segment Advisor ~ rev. 1.0 RJB 1/06/2004
Переменная SQL*Plus для выборки номера задания из Segment Advisor variable task_id number
- далее следует блок PL/SQL
240
Гпава 6
declare
name varchar2(100);
descr varchar2(500);
obj_id number;
begin
name := ‘’; - уникальное имя, генерируемое из create_task descr := ‘Check HR.EMPLOYEE’;
dbms_advisor.create_task
(‘Segment Advisor’, :task_id, name, descr, NULL); dbms_advisor.create_object
(name, ‘TABLE’, ‘HR’, ‘EMPLOYEES’, NULL, NULL, obj_id); dbms advisor_set_task_parameter(name, ‘RECOMMEND_ALL’, ‘TRUE’); dbms_advisor.execute_task(name);
end;
PL/SQL procedure successfully completed.
SQL> print task_id
TASK_ID
6
SQL>
Процедура DBMS_ADVISOR.CREATE_TASK определяет тип консультанта; в данном случае, это консультант Segment Advisor. Процедура возвращает уникальный идентификатор задачи и автоматически генерирует имя для вызывающей программы; мы сами должны дать задаче соответствующее описание.
Внутри задачи, идентифицируемой уникальным сгенерированным именем, которое возвращено из предыдущей процедуры, мы идентифицируем подлежащий анализу с помощью DBMS_ADVISOR.CREATE__ OBJECT объект. В зависимости от типа объекта, аргументы со второго по шестой могут изменяться. Для таблиц необходимо задать только имена таблицы и схемы.
Используя процедуру DBMS_ADVISOR.SET_TASK_PARAMETER, мы даем указание утилите Segment Advisor дать все возможные рекомендации, относящиеся к таблице. Если мы хотим отключить рекомендаций для этой задачи, то нужно специфицировать для последнего параметра значение ‘FALSE’ вместо значения ‘TRUE’.
И, наконец, мы инициируем задачу Segment Advisor с помощью процедуры DBMS_ADVISOR.EXECUTE_TASK. После ее выполнения на экран выводится идентификатор задачи, так что можно задать запрос к результатам в соответствующем представлении словаря данных.
Теперь, когда есть номер задачи из вызова Segment Advisor, можно задать запрос к DBA_ADVISOR_FINDINGS, чтобы увидеть, что можно сделать для улучшения использования пространства для таблицы HR.EMPLOYEES:
мониторинг использования дискового пространства
241
□ SQL> select owner, task_id, task_name, type,
2 message, more_info from dba_advisor_dfindings
3 where task_id = 6;
OWNER TASK_ID TASK_NAME TYPE
RJB 6 TASK_00003 INFORMATION
MESSAGE
Perform shrink, estimated savings is 107602 bytes. (Выполнить сжатие, оценочная экономия 107602 байт)
M0RE_INF0
Allocated Space: 262144: Used Space: 153011: Reclaimable Space: 107602. (Выделенное пространство: 262144: Использованное пространство: 153011: Возвращаемое пространство: 107602)
Результаты говорят сами за себя. Можно выполнить для таблицы операцию сжатия сегментов для возврата пространства после многочисленных операций вставки, обновления и удаления для таблицы HR.EMPLOYEES. Поскольку столбец WORK_RECORD был добавлен уже после заполнения таблицы, в ней могли возникнуть расщепленные строки. Кроме того, так как столбец WORK-RECORD может иметь длину до 4000 байт, при обновлениях или удалениях строк с большими столбцами WORK_RECORD в таблице могут возникнуть блоки со свободным пространством, которое может быть возвращено. Представление DBA_ ADVISOR_RECOMMENDATIONS предлагает аналогичную информацию:
□ SQL> select owner, task_id, task_name, benefit-type
2 from dba_advisor-recommendations 3 where task-id = 6;
OWNER TASK_ID TASK_NAME
RJB 6 TASK_00003
BENEFIT_TYPE
Perform shrink, estimated savings is 107602 bytes.
(Выполнить сжатие, оценочная экономия 107602 байт)
Во всяком случае, можно сжать сегмент HR.EMPLOYEE, чтобы возвратить свободное пространство. Как дополнительное преимущество, связанное с экономией времени для АБД, в представлении DBA_ADVISOR_ содержится необходимый для выполнения сжатия оператор
О SQL> select owner, task_id, task_name, command, attrl
2 from dba-advisor_actions where task_id = 6;
242
Гпаваq
OWNER TASK_ID TASK.NAME COMMAND
RJB
6 TASK.00003 SHRINK SPACE
ATTR1
alter table HR.EMPLOYEES shrink space
1 row selected.
SQL> alter table HR.EMPLOYEES shrink space;
Table altered.
Для операции сжатия не требуется дополнительного дискового пространства, и она не прекращает доступ к таблице во время проведения операции, за исключением очень короткого промежутка времени в конце процесса освобождения свободного пространства. Во время операции сжатия все индексы для таблицы продолжают обслуживаться.
В дополнение к освобождению дискового пространства для использования другими сегментами в сжатии сегментов имеются и другие преимущества: улучшается использование кэша, поскольку оператору SELECT или другим операторам DML для сегмента требуется прочесть меньшее число блоков. Кроме того, так как данные в сегменте хранятся более компактно, повышается производительность полного сканирования таб лицы.
В сказанном выше есть несколько подводных камней и незначительных ограничений. Во-первых, сжатие сегментов не работает для LOB-сегментов. В этом случае более предпочтительным является метод онлайновой реорганизации таблиц. Кроме того, сжатие индексов не разрешено для таблиц, содержащих индексы по ключу-функции (function-based indexes).
g 1
Утилита Undo Advisor и Automatic Workload Repository
Впервые появившаяся в Oracle 10gутилита Undo Advisor (консультант по откатам) предлагает информацию по табличным пространствам отка та. С се помощью можно узнать, не являются ли их размеры слишком болыпими/слишком малыми, оптимально ли установлено время сохране ния информации в пространстве отката (посредством параметра UN13 -RETENTION) для транзакций, типичных для этой базы данных.
Использование Undo Advisor похоже на использование
Advisor тем, что снова вызываются процедуры из пакета DBMS_ADV1^> и осуществляются запросы к представлениям словаря данных Db ADVISOR-*, чтобы ознакомиться с результатами анализа.
Однако Undo Advisor базируется на другой повой возможности О га 10g— Automatic Workload Repository (AWR — автоматически управляемый p позиторий рабочей нагрузки). Он встраивается в каждый экземпляр < а3 данных Oracle, содержит моментальные снимки всех ключевых статис*1 ческих данных и рабочих нагрузок для базы данных, собираемые 4CP;g 30-минутные интервалы. Статистические данные сохраняются в А™
Мониторинг использования дискового пространства
243
в течение семи дней, после чего наиболее старые из них удаляются. Как период сохранения информации, так и величина интервала ее сбора могут быть изменены в соответствии с потребностями среды. AWR поддерживает хронологические записи о том, как использовалась база данных в разные моменты времени, и помогает диагностировать и предсказывать проблемы задолго до того, как они могут привести к выходу базы данных из строя.
Для настройки Undo Advisor для анализа использования пространства отката будет использоваться анонимный блок PL/SQL, похожий на тот, что был использован для Segment Advisor. Но прежде чем можно будет применить Undo Advisor, необходимо определить временные рамки для анализа. В представлении словаря данных DBA_HIST/SNAPSHOT содержатся номера и временные отметки моментальных снимков; мы будем искать номера моментальных снимков, сделанных между 20:00 и 21:30 в субботу 24 января 2004 г.
□ SQL> select snap_id, begin_interval_time, end_interval_time
2 from DBA_HIST_SNAPSHOT
3 where begin_interval_time > ‘24-Jan-04 08.00.00 PM’ and
4 end_interval_time < ‘24-Jan-04 09.31.00 PM’
5 order by end_interval_time desc;
SNAP_ID BEGIN_INTERVAL_TIME END_INTERVAL_TIME
8 24-JAN-04 09.00.30.828 PM 24-JAN-04 09.30.14.078 PM
7 24-JAN-04 08.30.41.296 PM 24-JAN-04 09.00.30.828 PM
6 24-JAN-04 08.00.56.093 PM 24-JAN-04 08.30.41.296 PM
Имея в своем распоряжении такие результаты, при вызове Undo Advisor мы будем использовать значения SNAP ID в диапазоне от 6 до 8. Ниже приводится анонимный блок PL/SQL:
- начать анализ с помощью утилиты UNDO Advisor
- rev. 1.0 RJB 1/09/2004
временная SQL*Plus для выборки номера задания из Segment Advisor variab е task id number
declare
task-id number;
name varchar2(100);
descr varchar2(500);
obj_id number; • *
begin
name := ; - уникальное имя, генерируется из create-task
descr : = ‘Check Undo Tablespace’;
dbms_advisor.create_task
(‘Undo Advisor’, :task_id, name, descr);
dbms_advisor.create_object
(name, ‘UNDO_TBS’, NULL, NULL, NULL, ‘null’, obj.id);
244
Гпава с
dbms_advisor_set_task__parameter(name) ‘TARGET-OBJECTS’, obj_id);
dbms_advisor_set_task_parameter(name, ‘START-SNAPSHOT’, 6);
dbms_advisor_set_task_parameter(name, ‘END_SNAPSHOT’, 8);
dbms_advisor_set_task_parameter(name, ‘INSTANCE’, 1);
dbms_advisor.execute_task(name); /
end;
PL/SQL procedure successfully completed.
SQL> print task_id
TASK ID
16
Как и в случае с Segment Advisor, можно задать запрос к DBA-ADVISOR_FINDINGS, чтобы увидеть проблемы и рекомендации.
□ SQL> select owner, task_id, task.name, type,
2 message, more-info from dba_advisor_findings
3 where task-id = 16;
OWNER TASK_ID TASK-NAME TYPE
RJB 16 TASK_00003 PROBLEM
MESSAGE
The undo tablespace is OK. (Табличное пространство отката в полном порядке)
MORE-INFO
В этом конкретном сценарии Undo Advisor указывает, что в табличном пространстве отката выделено достаточно места для того, чтобы справ' ляться с типами и объемами запросов, выполняющихся к базе данных.
Для генерации текстового или HTML-отчета из AWR необходимо вы полнить SQL-сценарий swrfrpth.sql, который можно найти в каталоге $ORACLE_HOME/RDBMS/Admin:
□ SQL> @%oracle_home%\rdbms\admin\swrfrpth.sql
Current Instance
DB Id DB Name Inst Num Instance
3207671131 OEMREP 1 oemrep
Instances in this Workload Repository schema
Мониторинг использования дискового пространства
245
DB Id Inst Num DB Name Instance Host
3207671131 1 OEMREP
Using 3207671131 for database
Using 1 for instance
oemrep ATH2600
Id number
Specify the number of days of
snapshots to choose from
Entering the number of days (n) will result in the most recent (n) days of snapshots being listed. Pressing <return> without specifying a number lists all completed snapshots.
Enter value for numjjays: 2
Listing the last 2 days of Completed Snapshots
Instance DB Name Snap Id Snap Started Snap Level
oemrep OEMREP 1 24 Jan 2004 18:01 1
2 24 Jan 2004 18:30 1
3 24 Jan 2004 19:00 1
26 25 Jan 2004 06:30 1
27 25 Jan 2004 07:00 1
28 25 Jan 2004 07:30 1
29 25 Jan 2004 08:00 1
30 25 Jan 2004 08:30 1
31 25 Jan 2004 09:00 1
Specify the Begin and End Snapshot Ids
Enter value for begin, snap: 1
Enter Snapshot Id specified: 1
Enter value for end_snap: 29
End Snapshot Id specified: 29
Specify the Report Name
The default eport file name swrf_1_29.html. To use this name, press <return> to continue, otherwise enter an alternative.
Enter value for report_name: swrf_1_29.html
on РИС* 6,8 показана часть выходных данных HTML-отчета swrf 1 ^y.ntml. ---
Обратите внимание, мы по-прежнему продолжаем получать сообщения об ошибке “Snapshot too old” (Слишком старый моментальный снимок), с которым мы уже сталкивались ранее в этой главе при просмотре представления V$UNDOSTAT. 1
246
Гпаваq
Рис. 6.3. Отчет HTML из репозитория рабочей нагрузки
Использование индексов
Хотя благодаря значительному ускорению выполнения запросов индексы обеспечивают потрясающие преимущества, они могут оказывать влияние на использование базой данных дискового пространства. Если созданный индекс совсем не используется, занимаемое им дисковое пространство можно было бы использовать с большей пользой где-нибудь в другом месте, кроме того, если индекс реально не нужен, можно было бы также сэкономить время обработки при выполнении операций вставки, обновления и удаления, которые оказывают влияние на индекс. Мониторинг использования индекса можно выполнить с помощью динамического представлю ния производительности V$OBJECT_USAGE. Мы подозреваем, что в на шей схеме HR индекс по столбцу JOBJD таблицы EMPLOYEES является неиспользуемым. Попробуем включить мониторинг для этого индекса.
□ SQL> alter index hr.emp_job_ix monitoring usage;
Index altered.
Обратимся к представлению V$OBJECT_USAGE, чтобы быть уверю*1 ными, что мониторинг индекса ведется:
□ SQL> select * from v$object_usage;
INDEX_NAME TABLE_NAME MON USED S ART_MONITORING
гтмп mo tv pmpi (T/PFS YES NO 01/25/2004 10:04:55
Мониторинг использования дискового пространства
247
Столбец USED подскажет, есть ли обращения к индексу при выполнении запросов. По истечении полных суток типичной активности пользователей мы снова проверили представление V$OBJECT_USAGE, а затем отключили мониторинг:
□ SQL> alter index hr.emp_job_ix nomonitoring usage;
Index altered.
SQL> select * from v$object_usage;
INDEX.NAME TABLE.NAME MON USED START.MONITORING END.MONITORING
EMP.JOB.IX EMPLOYEES NO YES 01/25/2004 10:04:55 01/26/2004 11:39:45
Достаточно убедительно показано, что за истекшие типичные сутки индекс был использован, по крайней мере, один раз.
На другом конце спектра находится ситуация, когда обращения к индексу становятся слишком частыми. Если значения ключа часто вставляются, обновляются или удаляются, индекс становится менее эффективным с точки зрения использования дискового пространства. Приведенные ниже команды могут быть использованы как базис для индекса, после того как он был создан, а затем периодически выполняться, чтобы заметить, не стало ли использование пространства неэффективным:
□ SQL> analyze index hr.emp.job.ix validate structure;
Index analyzed.
SQL> select pct_used from index_stats where name = ‘EMP.JOB.IX'; PCT_USED
78
Столбец PCT_USED содержит процентную долю используемого дискового пространства по отношению к выделенному. По прошествии некоторого времени оказывается, что таблица EMPLOYEES была интенсивно использована, благодаря высокой текучести сотрудников компании, и этот индекс, как и другие, использует отведенное ему пространство неэффективно, на что указывает базовый запрос, так что мы принимаем решение, что необходима перестройка:
П SQL> analyze index hr.emp_job_ix validate structure;
Index analyzed.
SQL> select pct_used from index_stats where name = ‘EMP_JOB_IX’;
PCT-USED
26
SQL> alter index hr.emp_job_ix rebuild;
Index altered.
Уровни предупреждений об использовании
Дискового пространства
Выше рассматривалось представление словаря данных DBA_ 1HRESHOLDS, которое содержит список активных показателей для измерения состояния базы данных. При выполнении инсталляции Oracle
248
Гпава 6
10g с используемыми по умолчанию значениями параметров применяют ся следующие пороги:
CJ SQL> select metrics_name, warning_operator, warning_value, 2 critical_operator, critical_value, consequtive_occurences 3 from dba_thresholds;
METRICS-NAME WARNING.OPER WARNING-VALUE
Blocked User Session Count Process Limit % Session Limit % Tablespace Space Usage User Limit % GT 11 GT 80 GT 90 GT 85 GT 90
CRITICAL_OPER CRITICAL-VALUE CONSEQUTIVE_OCCURENCES
NONE 3
NONE 3
NONE 3
GT 97 1
NONE 3
Если говорить о потреблении пространства, то уровень предупреждения для данного табличного пространства устанавливается, когда табличное пространство будет заполнено на 85%, а отсчет критического уровня начинается с 97% заполнения. Вдобавок, это условие должно встречаться только один раз в течение отчетного периода, который по умолчанию считается равным одной минуте. Для других условий из этого списка условие должно быть истинным в течение, по крайней мере, трех последовательных отчетных периодов, после чего может быть возбуждено предупреждение об опасности.
Для изменения уровня, при котором генерируется предупреждение об опасности, можно использовать процедуру DBMS_SERVER_ALERT.SEТ-THRESHOLD. В данном примере нужно заблаговременно известить о том, что табличное пространство близко к переполнению, так что мы о новим (снизим) порог предупреждения с 85 до 60%:
-- Анонимная процедура PL/SQL для обновления порога
-- использования пространства в табличном пространстве
declare
/* Выходные переменные */ warning_operator number; warning_value varchar2(100);
critical_operator number;
critical_value varchar2(100);
observation_period number;
.-nn^poiitive occurences number;
Мониторинг использования дискового пространства 249
metrics_id instance_name object_type object_name
new_warning_value
/* Входные переменные */
number;
varchar2(50);
number;
varchar2(50);
vatchar2(100) := ‘60’; begin
I metrics_id : = 9000; /* Из V$METRICNAME */
object_type := DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE; instance_name := ‘b2r7seed’; /* Из DBA_THRESHOLDS */ object_name := NULL;
-- Выберите текущие значения с помощью процедуры get_threshold dbms_server_alert.get_threshold(
metrics_id, warning_operator, warning_value, critical_operator, critical_value, observation_period, consequtive_occurences, instance_name, object_type, object_name);
-- Обновите значение порога предупреждения с 85 до 60% d bms_se rve r_ale rt.set_threshold(
metrics_id, warning operator, new_warning_value, critical_operator, critical_value, observation_period, consequtive_occurences, instance_name, object_type, object_name);
end;
PL/SQL procedure successfully completed.
Проверив DBA_THRESHOLDS еще раз, мы увидим, что уровень предупреждения был снижен с 85 до 60%:
О SQL> select metrics_name, warning_operator, warning_value
2 from dba_thresholds;
METRICS_NAME WARNING. OPER WARNING VALUE
Blocked User Session Count GT 11
Process Limit % GT 80
Session Limit % GT 80
Tablespace Space Usage GT 60
Oser Limit % GT 90
Подробный пример того, как можно использовать Oracle Advanced Queuing для подписки на сообщения из очереди предупреждений, не укладывается в рамки этой книги. Ниже приводятся примеры использования Enterprise Manager для создания асинхронного оповещения об аварийных ситуациях с помощью электронной почты, пейджера или процедуры PL/SQL.
250
Г.пава 6
Возможность продолжения операций после устранения проблем с ресурсами
Начиная с Огас1е9г, база данных Oracle предлагает способ приостановки длительное время выполняющихся операций в случае невозможности выделения для них пространства. После того, как об этой ситуации станет известно АБД и проблема с выделением памяти будет исправлена, длительное время выполняющаяся операция может быть продолжена и завершена. При этом длительное время выполняющуюся операцию не нужно будет перезапускать с самого начала.
С помощью Resumable Space Allocation можно разрешить три типа проблем управления дисковым пространством:
Переполнение табличного пространства
и Достигнуто максимальное число экстентов в сегменте
и Для пользователя превышена квота выделения дискового пространства
Установив значение параметра инициализации RESUMABLE.. TIMEOUT отличным от нуля, АБД может придать операторам способность к такому продолжению работы. Значение параметра RESUMABLE_ TIMEOUT задается в секундах. Разрешить продолжение операций на уровне сеанса пользователь может с помощью команды ALTER SESSION ENABLE RESUMABLE:
□ SQL> alter session enable resumable timeout 3600;
В этом случае любая операция, выполняющаяся длительное время, для которой не хватило места на диске, будет приостановлена па срок, не превышающий 3600 сек (60 мин), чтобы дать возможность исправить ситуацию с дисковым пространством. Если за отведенное время ситуация исправлена не будет, операция завершится аварийно.
В приводимом ниже сценарии кадровая служба пытается перевести личные данные сотрудников из таблицы EMPLOYEES одного из филиалов в таблицу EMPLOYEEJSEARCH, в которой содержатся данные всех сотрудников компании. Когда средство Resumable Space Allocation не использовалось, пользователями кадровой службы было получено следую* щее сообщение об ошибке:
□ SQL> insert into employee_search
2 select * from employees;
insert into employee_search
ERROR at line 1:
0RA-01653: unable to extend table HR.EMPLOYEE SEARCH by 128
in tablespace USERS9
(ОШИБКА в строке 1:
0RA-01653: невозможно расширить таблицу HR.EMPLOYEE_SEARCH на 128 в табличном пространстве USERS9)
После того, как им неоднократно пришлось столкнуться с этой пр° блемой, пользователи кадровой службы приняли решение: чтобы избе
Мониторинг использования дискового пространства 251
жать большого объема повторно выполняемых работ при каждом возникновении в базе данных проблем с нехваткой дискового пространства, следует использовать Resumable Space Allocation. Вот что теперь получилось:
□ SQL> alter session enable resumable timeout 3600;
Session altered.
SQL> insert into hr.employee_search
2 select * from hr.employees;
Пользователь не получил никакого сообщения, и остается совершенно неясным, что выполнение операции приостановлено. Однако, в журнале оповещений (alert log) можно прочесть следующее сообщение:
□ Sun Jan 25 14:44:29 2004
statement in resumable session ‘User HR(66), Session 39, Instance 1’ was suspended due to
0RA-01653: unable to extend table HR.EMPLOYEE-SEARCH by 128
in tablespace USERS9
ORA-12899 encountered when generating server alert SMG-2004
(Воскресенье 25 января 2004 г. 14:44:29
оператор в сеансе с возможностью продолжения ‘Пользователь HR(66), сеанс 39, экземпляр 1’ был приостановлен вследствие возникновения ошибки
0RA-01653: не удается расширить таблицу HR.EMPLOYEE-SEARCH на 128 в табличном пространстве USERS9
При генерации уведомления на сервере (SMG-2004) возникла ошибка 0RA-12899)
АБД получает сообщение на пейджер, созданное утилитой OEM, и проверяет представление словаря данных DBA_RESUMABLE: ✓
О SQL> select user_id, instance_id, status, name, error_msg
2 from dba_resumable;
USER_ID INSTANCE_ID STATUS NAME ERROR_MSG
66 1 SUSPENDED User HR(66), Session 0RA-01653: unable to
39, Instance 1 extent table HR.EMP
LOYEE SEARCH by 128
in tablespace USERS9
АБД обнаруживает, что для табличного пространства USERS9 не разрешено автоматическое расширение, и модифицирует его, чтобы разрешить автоматическое расширение:
SQ > alter tablespace users9
2 add datafile ‘F:\OEM\USERS09a.DBF’
3 size 5M autoextend on;
Tablespace altered.
Команда insert сеанса пользователя заканчивается успешно, и статус возобновляемой операции отражается в представлении DBA RESUMABLE:
252
Гпава 6
□ USER_ID INSTANCE_ID STATUS NAME
ERROR.MSG
66
1 NORMAL
User HR(66), Session
39, Instance 1
Журнал оповещений также указывает на успешное возобновление этой операции:
□ Sun Jan 25 15:24:32 2004
statement in resumable session ‘User HR(66), Session 39,
Instance 1’ was resumed
(Воскресенье 25 января 2004 г. 15:24:32
Оператор в возобновляемом сеансе ‘Пользователь HR(66), сеанс 39,
экземпляр 1’ был возобновлен)
С точки зрения пользователя для выполнения операции потребовалось больше времени, чем ожидалось, но все-таки она была успешно завершена. Еще один способ предложить пользователю больше информации заключается в том, чтобы создать специальный вид триггера, впервые введенный в Oracle 9 г, который называется системным триггером. Системный триггер похож на все остальные триггеры, за исключением того, что он реагирует не на события, связанные с операторами DML для таблиц, а на определенные типы системных событий. Ниже приводится образец системного триггера, срабатывающего от системного события AFTER SUSPEND:
□ create or replace trigger resumable_notify
after suspend on database - срабатывает при событии восстановления памяти declare
- - переменные
begin
- - дайте АБД 2 часа на разрешение проблемы
dbms_resumable.set_timeout(7200);
- - найдите в DBA_RESUMABLE идентификатор пользователя, а затем отправьте
- - ему письмо электронной почтой:
utljnail.send (‘dba@rjb.com’, . . .);
end:
Управление дисковым пространством средствами операционной системы
За пределами операционной среды Oracle мониторинг пространства д@л жен вести системный администратор, которому АБД должен досконально объяснить все, что имеет отношение к установленными им парамет рам, обеспечивающим автоматическое расширение файлов ДаигФ*^ Установка для табличного пространства значения AUTOEXTEND О в сочетании с большими значениями NEXT позволит табличному пр° странству расти, чтобы аккомодироваться к большому количеству BCia вок и обновлений, но все закончится аварийно, если на физических мах сервера не будет достаточного количества доступного пространства-
Мониторинг использования дискового пространства
253
Сценарии управления дисковым пространством
В этом разделе рассматриваются сценарии, которые можно выполнять в случае необходимости или запланировать их регулярное выполнение для упреждающего мониторинга базы данных.
Эти сценарии работают с представлениями словаря данных и предлагают более детализированное отображение конкретной структуры, функциональность некоторых предлагаемых сценариев может перекликаться с результатами, обеспечиваемыми некоторыми из инструментов (см. выше в данной главе), но они могут быть более сфокусированными и в некоторых случаях обеспечивать больше подробностей о возможных проблемах с дисковым пространством в базе данных.
Сегменты, в которых не могут быть выделены дополнительные экстенты
В приведенном ниже сценарии мы хотим идентифицировать сегменты (скорее всего, таблицы и индексы), в которых невозможно выделить дополнительные экстенты:
□ SQL> select s.tablespace_name, s.segment_name,
2 s.segment-type, s.owner
3 from dba_segments s
4 where s.next_extent >=
5 (select max(f.bytes)
6 from dba_free_space f
7 where f.tablespace_name = s.tablespace_name)
8 or s.extents = s.max_extents
9 order by tablespace_name, segment_name;
TABLESPACE_NAME SEGMENT_NAME SEGMENT-TYPE OWNER
SYSTEM SYSTEM ROLLBACK SYS
USERS9 EMPLOYEE-SEARCH TABLE HR
В этом примере коррелированный подзапрос используется для сравнения размера следующего экстента со свободным пространством, оставшимся в табличном пространстве. Еще одно проверяемое условие состоит в том, чтобы выяснить, не закончится ли аварийно запрос на выделение следующего экстента, так как сегмент уже состоит из максимально возможного числа экстентов.
Причина возникновения проблем у этих объектов, скорее всего, одна из следующих: в табличном пространстве недостаточно места для размещения следующего экстента сегмента или текущий сегмент имеет макси-малкиый номер. Для разрешения этой проблемы АБД должен расширить та личное пространство, добавив в него еще один файл данных, либо экспортировать из него все данные и заново создать с параметрами хранения, более соответствующими модели роста сегмента. Начиная с Огас1е9г, использование локально управляемых табличных пространств вместо табличных пространств, управляемых с помощью словаря данных, решает проблему в том случае, если дело не в месте надиске, — максимальное число сегментов в LMT неограниченно.
254
Гпаваq
Использованное и свободное пространство в табличных пространствах и файлах данных
Приведенный ниже сценарий SQL*Plus производит разбивку использования дискового пространства по табличным пространствам, а внутри ка-ждого табличного пространства — по файлам данных. Это хороший способ увидеть, как используется и расширяется дисковое пространство в каждом файле данных табличного пространства. Такой сценарий может оказаться полезным при балансировке нагрузки, если не используются ASM или высокодоступные запоминающие устройства.
- - Свободное пространство внутри постоянных табличных пространств.
- - Сгруппировано по табличным пространствам.
- - Аргументы отсутствуют.
- - 1024 * 1024 * 1000 = 1048576000 = 1 Гбайт по правилам OEM
column free_space_gb format 9999999.999
column allocated_gb format 9999999.999
column used_gb format 9999999.999
column tablespace format a12
column filename format a20
I
select ts.name tablespace, trim(subsfr(df. name, 1,100)) filename,
df.bytes/1048576000 allocated_gb,
((df.bytes/1048576000) - nvl(sum(dfs.bytes)/1048576000,0)) used.gb,
nvl(sum(dfs.bytes)/1048576000,0) free_space_gb
from v$datafile df_left outer join dba_free_space dfs
on df.file# = dfs.file_id join v$tablespace ts
on df.ts# = ts.ts#
group by ts.name, dfs.file_id, df.name, df.file#, df.bytes
order by filename;
TABLESPACE FILENAME ALLOCATED_GB USED_GB FREE_SPACE^B
WHSO1 F:\ASM\0RCL02.DBF 10.240 .000 10-240 ГЛ олО
EM.REP F:\0EM\0RCL05.DBF 10.240 .000 10. nOO
USERS9 F:\0EM\USERS10.DBF .005 .005 071
EXAMPLE F:\ORACLE\ORADATA\OEMREP\EXAMPLEO1.DBF .150 .079 .U' Ol0
SYSAUX F:\0RACLE\0RADATA\0EMREP\SYSAUX01.DBF .330 .320 O01
SYSTEM F:\0RACLE\0RADATA\0EMREP\SYSTEM01.DBF .440 .439 978
UND0TBS1 F:\ORACLE\ORADATA\OEMREP\UNDOTBS01.DBF .310 .032 020
USERS F:\0RACLE\0RADATA\0EMREP\USERS01.DBF 2.265 2.245 500
USERS F:\ORACLE\ORADATA\OEMREP\USERS02.DBF .500 .000
Только в табличном пространстве USERS есть более одного файла Д I ных, и использование пространства еще не распространилось на в р । файл данных. Для включения в этот отчет временных табличных #Р J странств можно использовать запрос с union, чтооы объединить этоГ^ лплг г аналогичным запросом На базе представления V$TEMPFILE. ,
Мониторинг использования дискового пространства
255
Автоматизация и упрощение процесса уведомления
Хотя любой из представленных в этой главе сценариев и пакетов может быть выполнен по требованию, некоторые из них можно и нужно автоматизировать. Это нужно не только для экономии времени АБД, но и для того, чтобы держать инициативу в своих руках и справляться с проблемами задолго до того, как они приведут к остановке системы.
Два основных метода автоматизации сценариев и пакетов — это, несомненно, пакет DBMS-SCHEDULER и Oracle Enterprise Manager. У каждого из этих методов имеются свои преимущества и недостатки. Так, например, DBMS_SCHEDULER может предоставить дополнительный контроль над планированием задания и создается только с использованием интерфейса командной строки. С другой стороны, Oracle Enterprise Manager использует полностью построешгую на web-тсхнологиях среду, которая позволяет АБД наблюдать за средой базы данных из любой точки, где он может получить доступ к web-браузеру.
Использование DBMS_SCHEDULER
Новинкой Oracle 10g стал пакет DBMS_SCHEDULER. Он предлагает новые возможности и функциональности по сравнению с предыдущим пакетом-планировщиком — DBMS_JOB. Хотя DBMSJOB по-прежнему продолжает оставаться доступным и в Oracle 10g, Oracle настоятельно рекомендует конвертировать все задания в DBMS_SCHEDULER, поскольку в следующем релизе пакет DBMS_JOB может оказаться в числе не рекомендуемых к использованию.
Пакет DBMS_SCHEDULER содержит многие процедуры, которые было бы естественно ожидать увидеть в пакете-планировщике: CREATE-JOB, DROP JOB, DISABLE, STOP JOB и COPYJOB. Вдобавок DBMS-SCHEDULER облегчает автоматический повтор выполнения заданий с помощью процедуры CREATE_SCHEDULE и разделение заданий по категориям на базе использования ресурсов с помощью процедуры CREATE JOB_CLASS.
Управление заданиями и мониторинг в OEM
Oracle Enterprise Manager не только предлагает выполнять большую часть административных задач базы данных в графической среде, полностью построенной на web-технологиях, но и может автоматизировать некоторые рутинные задачи, которые АБД выполняет ежедневно.
Консультант по сегментам
На рис. 6.4 изображена домашняя страница OEM. Многие функции управления дисковым пространством доступны непосредственно с этой стра-
В верхней части домашней страницы представлена общая информация о доступности для экземпляра, в том числе, имя экземпляра, имя хоста, использование ЦП и информация о сеансе. Внизу домашней страницы перечислены несколько гиперссылок для управления пространством, которые могут помочь при управлении пространством в базе данных. На рис. 6.5 изображена нижняя часть домашней страницы с рис. 6.4.
256
Г.пава 6
ЭOfacH* (nterprfie Магодп {$У$,ТШ) - DjUbaie; регпгерлуагМ Mfcmrft Internet JxpiWer
Fjie Ede
Favorites Tooh he.p
OBdCk ’ $Й i^Z*5***- P*w*es t^Neoa Ygrt . | > X3;il
Acze-;s ^http;;73tl'2600:SSfiO/em/ccnsol?,iddtaba5e^n$tafx:eMefrcp?ever««d!)Ccao'2oa3e\Vft«'l&terget“Oenrep.wc?y34ype»o^!| Go
Er terprise Manager
Luagi-j к.- А SYSTEM
Database: oernrep.world
Home I rictoijfig S^jggup v-V-
Lai«st D«ut-wdscl Г*’’ЖТм^ё» Jan 25,2004 8:2&13 PM ^Refresh}
View O&la Time Manual Refresh у
General
~*SMr|F .,g<>
Stalua
Up Since
Time Zeng Availability (%)
Instance Name
Version
Hast
Listener
L Shutdown J
Up
Jan 24.2004 5:31:31 PM
oeniiep
10.1.0.1.0
Host CPU
Active Sessfcnj
c%o%
Run Queue I..Q
Active Ses$ v
Рис. 6.4. Домашняя страница Oracle Enterprise Manager
Рис. 6.5. Ссылки OEM, связанные с дисковым пространством
Мониторинг использования дискового пространства
257
Рис. 6.6. Анализ, проведенный Segment Advisor
Из столбца Space Usage (использование пространства) можно сделать вывод, что у нас нет проблем с табличными пространствами и фрагментацией, но область дампа — выделенная область на диске для хранения резервных копий RMAN и других файлов, связанных с резервным копированием, — заполнена на 73%, и эта ситуация должна быть проконтролирована. Есть два других предупреждения (они конфигурируются автоматически при инсталляции Oracle 10g), которые также имеют отношение к дисковому пространству: три объекта в схеме HR могут быть разрушены или иметь какие-то проблемы с дисковой памятью; кроме того, в файловой системе хоста остается мало доступного дискового пространства. Системный администратор Windows может и не знать о проблеме со свободной памятью на томе М:, и у любых объектов, файлы данных которых размещены на этом томе, могут возникнуть проблемы, если в будущем объекты базы данных попробуют добавить в них экстенты.
Чтобы глубже погрузиться в вопросы фрагментации, можно щелкнуть на цифре “6й, размещенной рядом с заголовком Fragmentation Issues (проблемы фрагментации), после чего можно будет сконфигурировать или провести анализ фрагментации. В эту функциональность входят инструменты (см. выше в данной главе), которые вызывают DBMS_ ADVISOR.CREATEJTASK, чтобы создать Segment Advisor. На рис. 6.6 показаны несколько первых проблем с фрагментацией, обнаруженных Segment Advisor.
Например, у таблицы HR.EMPLOYEES слишком много расщепленных строк. Щелкнув на ссылке Reorganize Segment, можно легко реконсЬигу-
258
Гпава 6
Рис. 6.7. Реорганизация объекта
рировать характеристики хранения таблицы HR.EMPLOYEES, как мы это сделали ранее вручную, используя команды SQL из представления DBA_ADVISOR_ACTIONS. В окне, изображенном на рис. 6.7, мы запускаем процесс реорганизации таблицы HR.EMPLOYEES. Можно перенести ее в другое табличное пространство или указать, что во время реорганизации объект будет оставаться в онлайновом режиме. Прежде чем начнется фактическая реорганизация, печатается так называемый отчет о влиянии. Это позволяет быть уверенными в том, что вы ознакомлены с влиянием, которое предстоящая реорганизация окажет на базу данных и ее пользователей. Наконец, есть возможность передать задание на ре' организацию для немедленного выполнения или запланировать его вы
полнение на более позднее время.
На странице Fragmentation Issues принимается решение о том, чТ° табличное пространство EXAMPLE не используется в промышление экс плуатируемой системе и, вполне вероятно, что в какой-то последуют момент времени оно будет исключено. А до тех пор можно исключить это табличное пространство из анализа, как показано в нижней части стра цы, изображенной на рис. 6.8. Обратите внимание на то, что анализирУ ются только пять табличных пространств и ищутся как потерянное пр странство, так и избыточное расщепление строк.
В окне на рис. 6.9 удаляется табличное пространство EXAMPLE из ла задач анализа. Мы выбираем это табличное пространство и нажима^ на кнопку Remove (удалить). В верхней части этой же страницы можно И3 менить тип анализа, которому подвергаются таоличные пространства-
Мониторинг использования дискового пространства
fCf 4b /.'Tf <’ -
259
EXAMPLE SH
COUNTRIES
TABLE
EXAMPLE
CR$SUP_TEXTJDX$R
TAELE
PROMOTIONS
TABLE
Problem Detection Configuration
(Configure^
I Heb | Ljhjjiu
* J Local intranet
Рис. 6.9. Удаление табличных пространств из анализа
Excessive Wasted Space Check Excessive Row Chaining Check Number of tablespaces checked
Jan 25 2004 8 2631 PM
Jan 4'5 2004 8 26:31 PM,
2004
8.26 31 PM
EXAMPLE SH
•\86% of space below HWM is unused
(0.054-13 063MB)
•\76% of space below HWM is unused p 338/0 445MB)
/П-25 of 26
Fte Edit View Favorites Tools Help
X 9
f
(td ^P //<3fri2600:SSOD/!?cn/cansote/d34eba5e/$tgAdv/proder»s<eveDt»doLoac^ype«orecle_63teta$e^.arQet«oenvep-vt’Cj
!j68% of space below HWM is unused
(0.021/0 031MB)
Enabled Enabled 5
Database I ЗДср I P
Copyright © J996.2903. Oracle AS rajlU reserved
Рис. 6.8. Обнаружение проблем конфигурирования
260
Гпава 6
Консультант по откатам
На рис. 6.10 выбирается вкладка Administration (администрирование) ца главной странице OEM. Отсюда можно сконфигурировать Undo Advisor (консультант по откатам), щелкнув на Undo Management (управление пространством отката) в столбце Instance (экземпляр).
Верхняя половина страницы Undo Management (управление пространством отката), показанная на рис. 6.11, предлагает большое количество вариантов. По умолчанию количество сохраняемой информации об откатах вычисляется автоматически, но если нужно точно указать, как долго должна сохраняться информация об откатах, можно щелкнуть на гиперссылке, расположенной рядом с Undo Retention.
На рис. 6.12 можно указать, как много информации об откатах желательно сохранить в табличном пространстве для запросов, выполняющихся длительное время, или для поддержки ретроспективных запросов. После введения периода сохранения Undo Advisor предложит анализ, показывающий, сколько дискового пространства потребуется для поддержки этого периода. В дополнение будет показан график, демонстрирующий отношение между продолжительностью сохранения и размером табличного пространства отката.
На рис. 6.13 Undo Advisor дает логическое обоснование рекомендациям для пространства отката при заданной активности системы и периоде времени, указанном при конфигурировании Undo Advisor. В данном случае самый длительный запрос выполнялся более 40 мин, но среднее вре-
Dvnantca nxtahase Administration
Мониторинг использования дискового пространства 261
Рис. 6.11. Общая конфигурация Undo Management
Рис. 6.12. Настройка сохранения в Undo Advisor
262
Гпава 6
Update Analysts j
40
258.0
15884.0
U^Q.AdyiSflt J
r,-----------------r—----5----------.------------....... ............. . ;
Э Uc<»cle f ftterpri^e Manner • Undo Мдлй^лпеМ : Migrosof| Interpel Exjpbrer
fie Edt favor A:es tools help
2г Sea» ch F^vct^es
.j • TJ
A - " : f‘j Htp://athC6tX) SS>X/*ni/ronso?e/dtrt^a>e/instar<e/unc<?Advisory?e¥ent»r6$e?&jti=r2$iafget>’oefr.'fcp .wcrd&type»o»«l» v
—uuru?nont4Hr!uorrivrnjm ьгггупчь raciieVpatv—
Analysis Time Period Last Seven Days
Selected Ап%уш ,кпе 1 04 w.oo pM . । ?5 04 10 00 PM Pencd
!
*
Potential Problems Recommendations
No Pioblem Found
No Recommendation
t
! i i
System Activity and Tablespace
The recommendations are based on system activity and undo tablespace usage for the selected analysis time period
Longest Running Query (minutes) Average Undo Generation Pale (КЗ/rnrnute) Maximum Undo Generation Rale (KB'minute)
Database
Cop/ight Ф1996, 7003. Oracle A3 rights reserved
L .... .- - . Л. - >* И* .... - --- '* '-у- ••
http?//4Hh2600;5500/*J^.fccn5ole/«boutAppi»<Ation
Рис. 6.13. Рекомендации Undo Advisor
мя использования пространства отката значительно меньше максимума, который способно поддерживать имеющееся пространство отката. Это совпадает с результатами, полученными из примера с пакетом DBMS_ ADVISOR (см. выше в данной главе).
ГЛАВА 7
УПРАВЛЕНИЕ ТРАНЗАКЦИЯМИ С ПОМОЩЬЮ ТАБЛИЧНЫХ ПРОСТРАНСТВ ОТКАТА
В главе 6 кратко говорилось о том, как в табличных пространствах отката осуществляется управление дисковым пространством, а также о представлениях типа V$UNDOSTAT, которые могут помочь АБД вести мониторинг и определять размер пространств отката. В этой главе будут более подробно рассматриваться конфигурирование и мониторинг табличных пространств отката; будет показано, как можно разрешать иногда конфликтующие требования предоставления достаточного количества пространства отката для согласованности чтения и в то же время не дать аварийно закончиться операторам DML только из-за того, что было задано слишком большое значение параметра сохранения.
Сначала будет дан краткий обзор транзакций с точки зрения пользователя базы данных, чтобы стало более понятно, как поддерживать транзакции пользователя с помощью надлежащим образом выбранного размера табличного пространства отката. Далее будут рассмотрены основы того, как, используя известную команду create tablespace, создавать табличные пространства отмены — во время создания базы данных либо позже. Сегменты отката выполняют многие требования пользователей базы данных; все эти требования будут перечислены и объяснены в деталях.
В Oracle предлагается большое число способов ведения мониторинга И, в конечном счете, более точного определения размера табличных пространств отката. Для анализа использования табличных пространств можно использовать пакет dbms_advisor (см. главу 6). Этот пакет будет Детально исследован; будет также показано, как опция Database Control (управление базой данных) утилиты Oracle Enterprise Manager может значительно упростить проведение анализа.
В последнем разделе этой главы рассматриваются различные типы опции Oracle Flashback (средства ретроспекции Oracle), которые опираются на адекватным образом выбранный размер табличного пространства отката для разнообразных сценариев восстановления после ошибок
264
Гпава 7
пользователей. Все основные возможности Oracle Flashback на уровне запроса, таблицы или транзакции будут рассмотрены в этом разделе-о Flashback Database см. главу 15.
Сегментами отката в предыдущих выпусках Oracle было трудно управ-лять. К тому же большинство АБД выбирали для них либо слишком большой, либо слишком маленький размер; Oracle настоятельно рекомендует, чтобы для всех новых баз данных использовалось средство автоматического управления пространством отката (Automatic Undo Management) и чтобы базы данных, модернизированные по сравнению с одной из предыдущих версий Oracle, были конвертированы в среду AUM. Здесь не будр5 рассматриваться аспекты ручного управления пространством отката, за исключением того, как перейти от сегментов отката к автоматическому пространству отката.
Основные сведения о транзакциях
Транзакцией называется совокупность операторов DML SQL, которая рассматривается как логический блок; аварийное завершение любого из операторов транзакции означает, что ни одно из других изменений, внесенных в базу данных в рамках этой транзакции, не должно быть сохранено для постоянного хранения в базе данных. После того как все операторы DML в транзакции закончатся успешно, приложение (или пользователь SQL*Plus) должно задать команду commit (зафиксировать изменения), чтобы сделать эти изменения постоянными. В классическом банковском
примере будет успешной транзакция, которая переводит некоторую сум
му в долларах с одного банковского счета на другой, если окажутся успешными обе операции: дебетование одного счета (операция обновления (update) депозитного счета) и кредитование другого счета (операция обновления (update) текущего счета). Аварийное завершение какой-либо одной операции или обеих операций делает недействительной всю транзакцию. Если приложение или пользователь SQL*Plus выдаст команду commit, даже если успешным был только один из операторов обновле-
ния, у банка появятся глубоко несчастные клиенты!
Транзакция инициируется неявно. После того как будет завершена команда commit для предыдущей транзакции и будет вставлена, обновлена или удалена хотя бы одна строка таблицы, неявно создается новая транзакция. Кроме того, каждая команда DDL, например create table и alter index, будут фиксировать активную транзакцию и начинать новую. С помощью команды set transaction ... name ‘имя_транзакции^ можно присвоить траЯ закции имя; хотя это не дает приложению никаких преимуществ, присво енное транзакции имя присутствует в динамическом представлении пр^ изводительности V$TRANSACTION и позволяет АБД вести мониторив длительное время выполняющихся транзакций. Команда set transaction’
если она используется, должна быть первым оператором транзакции.
Внутри заданной транзакции можно определить контрольную ) (savepoint). Контрольная точка позволяет разбить последовательности к манд DML в составе транзакции па части, с тем чтобы можно было вып° нить откат одной или нескольких команд DML после контрольной точЮ ’ а впоследствии еще раз передать на выполнение оставшиеся невыпоЛН^ ными дополнительные команды DML транзакции или зафиксировав
265
управление транзакциями с помощью табличных пространств отката
команды, выполненные перед контрольной точкой. Контрольные точки создаются при помощи команды savepoint 1шя_контрольной_точки. Для отмены команд, выполненных после последней контрольной точки, используется команда rollback to savepoint имя_контрольной_точки.
Транзакция фиксируется неявно, если пользователь нормально отключается от Oracle; если же процесс пользователя был завершен аварийно, последняя выполнявшаяся транзакция будет откачена.
Основные сведения о пространствах отката
Табличные пространства отката облегчают откат логических транзакций. В дополнение к этому табличные пространства отката поддерживают множество других возможностей, в том числе согласованность чтения, разнообразные операции восстановления базы данных и ретроспективные функции (Flashback functions).
Откат
Любую команду DML в составе транзакции — неважно, состоит транзакция из одной этой команды или из ста команд — может понадобиться откатить (roll back). Если команда DML вносит в таблицу изменения, то измененные командой старые данные записываются в табличное пространство отката в управляемый системой сегмент отката (undo segment) или в управляемый вручную сегмент отката (rollback segment).
Когда назад откатывается вся транзакция (т. е. транзакция без контрольных точек), Oracle отменяет все изменения, сделанные командами DML с момента начала транзакции, используя для этого соответствующие записи отката и освобождая блокировки на задействованных в изменении строках (если такие имеются), и транзакция заканчивается.
Если откатывается часть транзакции до контрольной точки, Oracle отменяет все изменения, сделанные командами DML после указанной контрольной точки. Все последующие контрольные точки теряются, все блокировки, установленные после контрольной точки, снимаются, И транзакция остается активной.
Согласованность чтения
Откат обеспечивает согласованность чтения для пользователей, которые читают строки, затронутые транзакцией DML, выполняемой другим пользователем. Другими словами, все пользователи, которые читают затронутые строки, не увидят никаких изменений в строках до тех пор, пока они не зададут новый запрос уже после того, как пользователь, являющийся владельцем DML, не зафиксирует транзакцию. Управляемые автоматически сегменты отката используются для обратной реконструкции блоков данных до согласованной по чтению версии и в результате обеспечивает предыдущие значения строк для любого пользователя, задавшего оператор select до фиксации результатов транзакции.
Например, пользователь CLOLSEN начинает транзакцию с многочисленными обновлениями и вставками над таблицей EMPLOYEES. Про транзакцию известно, что она начинается в 10:00, а ее завершение плани
266
Гi~iqqq у
руется на 10:15. Как только над таблицей EMPLOYEES выполняется дый из операторов insert, update или delete, старые значения из таблиц^ запоминаются в табличном пространстве отката. Когда пользователь SUSANP задает в 10:08 команду select относительно той самой таблицы EMPLOYEES, пи одно из изменений, внесенных в таблицу EMPLOYE^ пользователем CLOLSEN, не будет видно никому, кроме самого пользой^ теля CLOLSEN. Табличное пространство отката обеспечивает предыду. щие (по отношению к внесенным пользователем CLOLSEN изменениям) значения для пользователя SUSANP и для всех остальных пользователей Даже если запрос от SUSANP не будет завершен к 10:20, таблица по-прежнему будет представляться для этого запроса неизмененной до тех пор, пока не будет задан новый запрос — уже после того, как результаты транзакции будут зафиксированы. Пока в 10:15 CLOLSEN не выполнит команду commit, данные из таблицы будут казаться неизмененными, т. е. такими, какими они были по состоянию на 10:00.
Если в управляемом автоматически пространстве отката недостаточно места для хранения всех предыдущих значений измененных строк, пользователь, задавший оператор select, может получить сообщение об ошибке “ORA-01555: Snapshot Too Old” (слишком старый моментальный снимок).
Восстановление базы данных
Управляемые автоматически пространства отката являются ключевым компонентом восстановления экземпляра. Оперативные журналы помогают провести прокрутку вперед до того момента, когда произошла аварийная ситуация с экземпляром (как для зафиксированных, так и для незафиксированных транзакций); данные для отката используются для отката тех транзакций, которые не были зафиксированы к моменту аварийной ситуации или отказа в работе экземпляра.
Ретроспективные операции
Данные в автоматически управляемом табличном пространстве отката используются для того, чтобы поддерживать различные типы ретроспеь тивных опций (Flashback options): Flashback Table (ретроспекция та л цы), Flashback Query (ретроспективный запрос) и пакет Db -FLASHBACK. Опция Flashback Table восстанавливает состояние табли | на какой-то момент времени в прошлом, Flashback Query позволяет лать запросы к таблице по состоянию на какой-то момент времени в г шлом или для какого-то определенного SCN, а пакет DBMS_FLASH предлагает программный интерфейс для Flashback-операций (подр° о Flashback-опциях см. ниже в данной главе).
Управление табличными пространствами отката
Создание и обслуживание табличных пространств отката является цией, про которую можно сказать: “создать и забыть ”, если стали И ° 0 ны предъявляемые к пространствам отката требования. В табличном С странстве отката Oracle автоматически создает сегменты °?
транзакциями с помощью
странств отката
267
определяет их размер и управляет ими. В этом состоит главное отличие от предыдущих версий Oracle, где администратор должен был вручную определя ь размер и постоянно вести мониторинг управляемых вручную сегментов отката. г 7
Создание табличных пространств отмены
Табличные пространства отмены можно создавать двумя способами: при создании базы даны или с помощью команды create tablespace после ее создания. Как и многие другие табличные пространства в Oracle 10g, табличное пространство отката может быть табличным пространством типа Bigfile, что еще более упрощает обслуживание пространств отката.
Создание табличного пространства отката при помощи команды
CREATE DATABASE
В базе данных может быть более одного табличного пространства отката, хотя активным в каждый момент времени будет только одно такое табличное пространство. Ниже показано, как создать табличное пространство во время создания базы данных:
О create database ord
user sys identified by ds88dkw2
user system identified by md78s233
sysaux datafile ‘/uo2/oradata/ord/sysaux001.dbf’ size 100m default temporary Tablespace tempOl
tempfile ‘/u03/oradata/ord/temp001.dbf’ size 25m
undo tablespace undotbsOI datafile ‘/u01/oradata/ord/undo001.dbf size 50m;
Если невозможно успешно создать табличное пространство отката в команде create database, вся операция заканчивается аварийно. Необходимо исправить ошибку, после чего удалить все уже созданные к моменту возникновения ошибки файлы и повторить выполнение команды.
Фраза undo tablespace в команде create database является необязательной, но, если она оказывается опущенной, активируется средство автоматического управления пространством отката (Automatic Undo Management) и табличное пространство отката создается с автоматически расширяемыми файлами данных, имеющими первоначальный размер 10 Мбайт и присваиваемое по умолчанию имя SYS_UNDOTBS.
Создание табличного пространства отката при помощи команды
CREATE TABLESPACE
В любой момент после создания базы данных можно создать новое табличное пространство отката. Оно создается точно так же, как и все остальные табличные пространства, но с добавлением ключевого слова undo:
Т create undo tablespace undotbs02
datafile ‘/u01/oracle/rbdb1/undp0201.dbf’
size 25m reuse autoextend on;
268
Г/jqbq у
В зависимости от изменчивости базы данных или от ожиданий, что требности базы данных в пространстве отката могут существенно возрас> ти в будущем, мы начинаем работу с этим табличным пространство^ с 25 Мбайт и позволяем ему расти.
Экстенты в автоматически управляемом табличном пространстве от ката должны быть управляемыми автоматически; другими словами, опция extent management может быть специфицирована только как local autoallocate.
Создание автоматически управляемых табличных пространств отката с использованием ЕМ Database Control
При использовании ЕМ Database Control создание автоматически управляемого табличного пространства отката становится простым делом. Из вкладки Administration выберите Tablespaces. Вам будет предложен список существующих табличных пространств; щелкните на кнопке Create. На рис. 7.1 создается новое табличное пространство отката с именем UNDOJBATCH.
В нижней части экрана определяется имя файла данных для использования в качестве табличного пространства отмены (см. рис. 7.2).
Щелчок на вкладке Storage позволяет специфицировать выделение экстентов, хотя для табличного пространства отката это должно делаться автоматически. Если поддерживаются несколько размеров блоков, можно указать размер блока для табличного пространства отката. На рис. 7.3
Рис. 7.1. Специфицирование общих характеристик табличного пространс 3 отмены
управление транзакциями с помощью табличных пространств отката 269
- , a:. . л - д-т > ---• Г : - • • '
Э-Oraclej&tterprhe Manager - Gca/e Т«ф|е$раи» - Micnwfl hlernr.l Hepler’
F4e Ed*t View Favorites
Tools Help
Back
Search Fevories
vRead Only C Offline
а уж gfj http./Jl92.160.2 ^66:S500/ern;con5cfe/da^ba$e/$torage/tabk?e$pace?Ur^t^crd.wDfldadype“Ora€lej3atdba5e8^anceURL«^ У
О Dictionary Managed
TjSeTas default permanent tablespace
’Temporary
О Set as default temporary tablespace
® Undo
Datafiles
L Use big'ile tablespace
Tafetejpx* has;»5 алЬ- «ал* ^ihr-.o rmtieer «ад «ай
Shew SQl) Cancel^ ok)
Database | SUMS. I ElgM!£St I tkll I 1жШ
Copyright © 1996,200< Oracle AH right: reserved
>-кеч***'-1 - м< *• ' *-* x >.$... .-.«г+г wft&.-oc f> . >. ixtOv-jy, . ,w ...^ \5
internet if............................................................................................................................................ iiH**w»iMeMMMiHiiiiiiiiHiMii-o»iri i i
Рис. 7.2. Определение файла данных табличного пространства отката
Рис. 7.3. Выделение экстентов и размер блока табличного пространства отмены
270
Глава 7
Рис. 7.4. Пороговые значения табличного пространства отката
показано, что специфицируется автоматическое (Automatic) выделение экстентов и размер блока, равный 8192 — размер блока по умолчанию и
единственный определенный для базы данных размер блока.
На третьей вкладке мы можем установить процентные значения для предупреждений (warning) и критических ситуаций (critical), при достижении которых АБД должен быть уведомлен о потенциальной проблеме с дисковым пространством в табличном пространстве отката. Можно использовать установленное по умолчанию пороговое значение 85% для предупреждения и 97% для критических ситуаций либо можно указать
для них свои собственные значения.
Как и для большинства экранов обслуживания ЕМ Database Control, можно посмотреть фактические команды SQL, которые будут выполне' ны, когда мы будем готовы создать табличное пространство. На рис. 7. предложен предварительный просмотр команд SQL для создания табли^ ного пространства, а также создания для него порогов предупреждения
на сервере.
После щелчка на ОК новое табличное пространство отката будет Ус пешно создано (см. рис. 7.6). -
ЕМ Database Control, хотя и является средством, экономящим для АЬД много времени, не в состоянии охватить каждый возможный сценарии, а также не может не позволить АБД создать табличное пространс °т ката с неверными параметрами. На рис. 7.3 можно специфицировать вЫ деление экстентов Uniform (одного размера), но если попытаться соЗ
транзакциями с помощью табличных пространств отката
271
’ ............
Э Oracle EnlcrfoUc 5hpMfSQE Mrcroegft Internet Bpbre;
Fi’e Eot view Favorites Tools Heto
Of^ACUG Enterprise Mtmagei 10<j Canitnl
> Create Tablespace» SQL
CREATE SMALLFILE UHDO TABLESPACE "UNDO-BATCH" DATAFILE
* /uG5/tir«d‘St-5i/-.>rd/uxvjo_bst.chrjl«fthf * SIZE 50M
BEGIH DEMS_3ERVER_ALERT. SET_THP.E SHOLD
(9000, NULL, WLL, HULL, HULL, 1,1, HULL, 5, ’ UNDOESATOM’) ; EHD;
lilted SYSTEM
Return)
1
Return)
Database I £gn& I Plfeill££S I Hgfe | loc&ifl Copyright *51998.2CCM Ctscte Ав rights reserved.
s
j Done internet
Р^11нИ1)ш>.вИ.,>1.шт и.м^.1<>>1|1.11|1>1„|.................................. в ш.^.м ................
Рис. 7.5. Предварительный просмотр SQL-оператора для создания табличного пространства отката
Рис. 7.6. Итоговая страница создания табличного пространства отката
272
Г.пава 7
Search
r • < > • t' • • >> 1 • ' у • , r * * Л • •* * ; 5i < 7< : *
3 Oraclepltc/prise Menagc-r Create Tablespace Microsoft Internet f x^farur ' ‘
File Edit View Favo?Re$ Toots Help
Л . A
£1 .».A > Л
,.J :'f -' —.................................. • * • - ............................ • ”
Add;* ^http;//l92460.2.l66:55QO/e»r/con«3le/d4rtdbdW5/st<Xd9eAable^^e?td<9e!t«(xdAMoild^ype«eHacte^ciat4!base&c6r<eMRle/ftm X Go
I
I
ORACLE Enterprise Manager 10g Database Control
101
U№№se
;.
> Creale Tablespace
ijr.
L<?yg<?d in As SYSTEM
м&да»« >
:
Л ' • s., - I
- .; •< < < > *4 <* ? ’ :-- <,<-
"Г-*-*—~**
4
fj
дм»г.&лс; * ktf< / . . > > >’• "? : S’: 4.. i
: . . - . < - . •- • t, .: ’•.
&МЙ131 Sto t a g e I IhiisS.A
Extent Allocation
spw^cat>c>r» for CREATE
. % • • ч' К ’ ;C: v М/J < j 7
»«
?
O Automatic
0 Uniform
Size lOOOj
КЗ
*
Block information
Plr^t C ™ r'PA 0103
£ Inrernet
rr 4*ч'*: ’ <<:'-
Рис. 7.7. Недопустимые параметры для табличных пространств отката
дать это табличное пространство, эта попытка завершится аварийно (см. рис. 7.7).
Табличные пространства отката должны иметь автоматически выделяемые экстенты.
Удаление автоматически управляемых табличных пространств отката
Удаление автоматически управляемого табличного пространства отката похоже на удаление любого другого табличного пространства; единственное ограничение состоит в том, что подлежащее удалению табличное пространство отката не должно быть активным пространством отката или не должно содержать данные отката для незафиксированных транзакций. Однако можно удалить табличное пространство отката, в котором содержится информация для отката с не истекшим сроком хранения, что может привести к аварийному завершению длительное время выпол нявшегося запроса. Для удаления табличного пространства отката, соз данного в предыдущем сценарии, используется команда drop tablespace.
П SQL> drop tablespace undo_batch;
Tablespace dropped.
SQL>
Фраза including contents при удалении табличных пространств отка та является подразумеваемой. Однако для удаления файлов данных оп^ рационной системы при удалении табличного пространства необходим0
управление транзакциями с помощью табличных пространств отката
273
специфицировать including contents and datafiles. Попытка удаления активного табличного пространства отката не разрешается:
CJ SQL> drop tablespace undotbsl;
drop tablespace undotbsl
ERROR at line 1:
0RA-30013: undo tablespace ‘UNDOTBS1’ is currently in use
SQL>
(ОШИБКА в строке 1:
0RA-30013: табличное пространство отката ‘UNDOTBS1’ в настоящее время используется)
Для удаления активного табличного пространства отката нужно сначала переключиться с него на другое табличное пространство отката (подробнее о переключении табличных пространств отмены см. ниже в данной главе).
Модификация табличных пространств отката
Для табличных пространств отката разрешены следующие операции:
Добавление файла данных к табличному пространству отката
Переименование файла данных в табличном пространстве отката
Перевод файла данных в табличном пространстве отката в оперативное (online) или автономное (offline) состояние
Начало или окончание резервного копирования открытого табличного пространства (команда alter tablespace undotbs begin backup)
Активация или отключение гарантии сохранения информации для отката
Всем остальным автоматически управляет Oracle
Использование 0MF для табличных пространств отката
В дополнение к использованию табличных пространств типа Bigfile для табличных пространств отката можно также использовать OMF для автоматического именования и размещения табличных пространств отката; параметр инициализации DB_CREATE_FILE_DEST содержит адрес, по которому будет создаваться табличное пространство отката, если в команде create undo tablespace не специфицирована фраза datafile. В следующем примере создается табличное пространство отката с помощью OMF:
О SQL> show parameter db_create_file_dest
NAME TYPE VALUE
db_create_file_dest string /u09/oradata/ord
SQL> create undo tablespace undo_batch;
Tablespace created.
274
SQL> Ils -1 /u09/oradata/ord/0RD/datafile total 102512
-rw-r----- 1 oracle oinstall 104865792 Apr 11 21:54
o1 jnf undo_bat_07n16p1c_.dbf SQL>
Поскольку размер файла данных не специфицирован, в качестве раз. мера табличного пространства по умолчанию для него будет выбран раз-мер 100 Мбайт; кроме того, файл данных является автоматически расщи. ряемым с неограниченным максимальным размером, который на самом деле ограничивается только файловой системой.
Динамические представления производительности для табличного пространства отката
Большое количество динамических представлений производительности и представлений словаря данных содержит информацию о табличных пространствах отката, пользовательских транзакциях и управляемых автоматически сегментах отката. В таблице 7.1 приводятся имена представлений и их описания (подробнее см. ниже в данной главе).
Таблица 7.1. Представления табличных пространств отката
Представление
Описание
DBA_TABLESPACES
DBAJJNDO_EXTENTS
V$UNDOSTAT
V$ROLLSTAT
V$TRANSACTION
Имена и характеристики табличных пространств, в том числе столбец CONTENTS, который может принимать значения PERMANENT, TEMPORARY или UNDO; столбец RETENTION (сохранение отката) со значениями NOT APPLY (неприменимо), GUARANTEE (гарантировано) или NOGUARANTEE (не гарантировано).
Все сегменты отката в базе данных, включая их размер, экстенты, табличные пространства, в которых они выделены, и текущий статус (EXPIRED или UNEXPIRED) — истекший или не истекший.
Количества использований пространства отката в базе данных с 10-минутными интервалами; содержит не более 1008 стро (7 дней).
Статистические данные об управляемых вручную сегментах отката, включая размер и статус.
Для каждого экземпляра содержит одну строку для каждой активной транзакции.
Параметры инициализации табличного пространства отката
UNDOJVIANAGEMENT
Значением по умолчанию для параметра UNDO_MANAGEMEN ся MANUAL. При установке параметра UNDO_MANAGEMENT на А # база данных переводится в режим среды автоматического управ-71
управление транзакциями с помощью табличных пространств отката
275
пространством отката. Чтобы этот параметр был действительным, в базе данных должно иметься, по крайней мере, одно табличное пространство отката вне зависимости от того, специфицирован ли параметр UNDOTABLESPACE или нет. UNDO_MANAGEMENT не является динамическим параметром; следовательно, необходимо перезапускать экземпляр всякий раз, когда UNDO_MANAGEMENT изменяется с AUTO на MANUAL или наоборот.
UNDO.TABLESPACE
Параметр UNDO_TABLESPACE специфицирует, какое табличное пространство отката будет использоваться в среде автоматизированного управления пространством отката. Если UNDO_MANAGEMENT не специфицирован или установлен на MANUAL, а параметр UNDOTABLESPACE специфицирован, экземпляр будет невозможно запустить.
Примечание Параметр UNDOJTABLESPACE используется в средах Real Application Clusters (RAC) для назначения конкретных табличных пространств отката экземплярам, где общее число табличных пространств отката в базе данных больше или равно числу экземпляров кластера.
Если же параметр UNDO_MANAGEMENT установлен на AUTO и в базе данных отсутствуют табличные пространства отката, экземпляр можно запустить, но тогда сегмент отката SYSTEM будет использоваться во всех операциях отмены, а сообщение запишется в журнал оповещений. Если пользователь попытается внести какие-либо изменения в табличное пространство, не содержащее сегмент SYSTEM, он получит сообщение об ошибке: “ORA-01552: cannot use system rollback segment for nonsystem tablespace ‘USERS’” (“Нельзя использовать сегмент отката system в табличном пространстве ‘USERS’, в котором нет этого сегмента”), и оператор не сработает.
UNDO_RETENTION
Параметр UNDO_RETENTION специфицирует минимальный промежуток времени, в течение которого информация об откате сохраняется в запросах. В автоматическом режиме этот параметр по умолчанию составляет 900 сек. Эта величина подходит только в том случае, если в табличных пространствах отката достаточно пространства для поддержания согласованных по чтению запросов. Если же для действующей транзакции нужно дополнительное пространство отката, еще действующий откат может подействовать на данную транзакцию и выдать сообщение об ошибке: ORA-01555: Snapshot Too Old” (“ORA-01555: Моментальный снимок устарел”).
\7СыхтТОЛ^Це TUNED_UNDORETENTION динамического представления Ф DOST АТ приводится настроенное время удержания отката для каж-
дого временного периода, а статус табличного пространства отката обновляется в этом представлении каждые 10 мнн.
276
Гпава 7
□ SQL> show parameter undo_retention
NAME TYPE VALUE
undo_retention integer 43200
SQL> select to_char(begin_time, ‘yyyy-mm-dd- hh24:mi’),
2 undoblks, txncount, tuned_undoretention
3 from v$undostat where rownum = 1;
T0_CHAR (BEGIN_TI UNDOBLKS TXNCOUNT TUNED_UNDORETENTION
2004-04-11 22:59 206 253 43200
1 row selected.
SQL>
Поскольку загрузка транзакции в самое последнее время минимальна, а экземпляр только что запущен, настроенное время удержания отката равно минимальному для инициализации параметра UNDO JRETENTION, т.е. 43 200 сек, или 12 ч.
Совет Не нужно специфицировать параметр UNDO_RETENTION, если только вам не нужно выполнить требования Flashback или LOB; параметр UNDO_ RETENTION не применяется для отмены транзакций.
Множественные табличные пространства отката
База данных может содержать несколько табличных пространств отката, но только одно из них является в данный момент активным для конкретного экземпляра. Ниже показывается, как при открытой базе данных можно подключиться к различным табличным пространствам отката.
Примечание В среде Real Application Clusters (RAC) для каждого экземпляра кластера нужно свое табличное пространство отката.
В базе данных ord есть два табличных пространства отката:
□ SQL> select tablespace_name, status from dbs_tablespaces
2 where contents = UNDO’;
TABLESPACE_NAME STATUS
UND0TBS1 ONLINE
UNDO_BATCH ONLINE
2 rows selected.
Но только одно табличное пространство отката является активным*
управление транзакциями с помощью табличных пространств отката
277
□ SQL> show parameter undo_tablespace
NAME TYPE VALUE
undo_tablespace
string
UNDOTBS1
При ночной обработке данных нужно заменить табличное пространство отката UNDOTBS1 на UNDOJBATCH, которое лучше поддерживает работу DML. Диск, на котором помещено табличное пространство для работы днем, больше, но работает медленнее. В результате использовать меньшее табличное пространство оката для поддержания OLTP нужно днем, а ночью применять табличные пространства отката большего объема для загрузки хранилища данных и других агрегированных действий, ведь ночью время отклика не так важно.
Примечание Oracle предлагает вам создать единое табличное пространство оката для каждого экземпляра, причем достаточно большое, чтобы можно было осуществлять все загрузки транзакций. Другими словами, “сделать и забыть”.
Пользователь SCOTT выполняет некоторые операции с таблицей HR.EMPLOYEES в то время, когда должно подключиться табличное пространство оката, и в текущем пространстве отката у него есть активная транзакция.
□ SQL> connect scott/tiger@ord;
Connected.
SQL> set transaction name ‘Employee Maintenance’;
Transaction set.
S QL> update hr.employees set commission_pct = commission_pct * 1.1;
107 rows updated.
SQL>
Проверив представление V$TRANSACTION, мы обнаруживаем у пользователя SCOTT незафиксированную транзакцию:
П SQL> select t.status, t.start_time, t.name
2 from v$transaction t join v$session s on t.ses_addr = s.saddr
3 where s.username - ‘SCOTT’;
STATUS STARTJIME NAME
ciiVE 04/12/04 21:56:53 Employee Maintenance 1 row selected.
Таоличное пространство отката изменяется следующим образом:
SQL> alter system set undo_tablespace=undo_batch* System altered.
Транзакция пользователя SCOTT по-прежнему остается активной и поэтому в старом табличном пространстве отката все еще содержится информация для отката для транзакции SCOTT, а этот его сегмент по-
278
Гпава 7
прежнему остается доступным со следующим статусом до тех пор, пока транзакция не будет зафиксирована или откачена:
□ SQL> select г.status
2 from v$rollstat r join v$transaction t on r.usn = t.xidusn
3 join v$session s on t.ses_addr = s.saddr
4 where s.username - ‘SCOTT1;
STATUS
PENDING OFFLINE
1 row selected.
Даже несмотря на то, что текущим табличным пространством отката является UNDO_BATCH, дневное табличное пространство UNDOTBS1 нельзя перевести в автономный режим или удалить, пока не будет зафиксирована или откачена транзакция пользователя SCOTT:
□ SQL> show parameter undo_tablespace
NAME TYPE . VALUE
undo_tablespace string UNDO_BATCH
SQL> alter tablespace undotbsl offline;
alter tablespace undotbsl offline *
ERROR at line 1:
ORA-30042: Cannot offline the undo tablespace
(ОШИБКА в строке 1:
0RA-30042: нельзя перевести в автономный режим табличное пространство отката)
Сообщение об ошибке ORA-30042 применяется при попытке перевести в автономный режим используемое в данный момент табличное пространство отката — будь то текущее табличное пространство отката, или табличное пространство отката, в котором имеются незавершенные транзакции. Если переключиться назад, на табличное пространство для дневных операций, прежде чем SCOTT зафиксирует или откатит свою транзакцию, то сегменты откату пользователя SCOTT снова получат ста тус ONLINE:
□ SQL> alter system set undo_tablespace=undotbs1;
System altered.
SQL> select r.status
2 from v$rollstat r join v$transaction t on r.usn - t.xidusn
3 join v$session s on t.ses_addr - s.sadd
4 where s.username = ‘SCOTT’;
STATUS
ONLINE
1 row selected.
управление транзакциями с помощью табличных пространств отката 279
Определение размера табличного пространства отката и его мониторинг
В табличном пространстве отката присутствуют три типа данных для отката: активные данные (или данные с не истекшим сроком хранения), данные с истекшим сроком хранения и неиспользуемые данные. Активные данные (или данные с не истекшим сроком хранения) — это данные для отката, которые все еще требуются для обеспечения совместимости чтения даже после фиксации транзакции. После того, как будут завершены все запросы, которым требуются активные данные для отката, и истечет период хранения данных для отката, активные данные для отката становятся истекшими или данными с истекшим сроком хранения. Такие данные для отката могут все еще использоваться для поддержки других возможностей Oracle, например Flashback-опций, но они более не требуются для обеспечения согласованности чтения для транзакций, выполняющихся длительное время. Неиспользуемые данные для отката — это те данные в табличном пространстве отката, которые больше никогда не будут использоваться.
В результате минимальный размер табличного пространства отката — это объем памяти, достаточный для хранения всех исходных (т. е. до обновления) версий всех данных из активных транзакций, которые еще не зафиксированы или не откачены. Если объем дисковой памяти, выделенный для табличного пространства отката, недостаточен даже для поддержки изменений из незафиксированных транзакций, которые требуются для поддержки операции отката, пользователь получит сообщение об ошибке “ORA-30036: unable to extend segment by space_qty in undo tablespace tablespace_name' (ORA-30036: невозможно расширить сегмент на размер_пространства в табличном пространстве отката имя_таблично-го_пространства). В такой ситуации АБД может увеличить размер табличного пространства отката, либо, в качестве временной меры, пользователь может расщепить большую транзакцию на несколько более мелких при условии соблюдения всех требующихся бизнес-правил.
Ручные методы
Для правильного определения размеров табличного пространства отката АБД может использовать много ручных методов. Чтобы получить информацию об использовании сегментов отката с интервалом в десять минут, можно просмотреть содержимое представления V$UNDOSTAT (см. главу б). В дополнение к этому столбец SSOLDERRCNT указывает, сколько за-^Р°1(Г’В было завеРшено аварийно с сообщением об ошибке “Snapshot
О SQL> select to_char(end_time, ‘yyyy-mm-dd hh24:mi’) end_time undoblks, ssolderrcnt from v$undostat;
END_TIME UNDOBLKS SSOLDERRCNT
2004-04-13 08:12 2114 0
2004-04-13 08:09 4569 0
2004-04-13 07:59 7403 0
2004-04-13 07:49 2341 0
280
Гпава 7
2004-04-13 07:39 8338 0
2004-04-13 07:29 1483 0
2004-04-13 07:19 1548 0
2004-04-13 07:09 61950 2
2004-04-13 06:59 4433 0
2004-04-13 06:49 5658 0
2004-04-13 06:39 757 0
В период между 6:59 и 7:09 наблюдался резкий скачок использования пространства отката, что привело к аварийному завершению некоторых запросов. В качестве эмпирического правила можно воспользоваться следующими вычислениями:
П размер_табличного_пространства_отката = UR * UPS + накладные_расходы
В этой формуле UR соответствует времени сохранения (в секундах) информации для отката (из параметра инициализации UNDORETENTION), UPS равняется числу блоков (максимальному) пространства отката в секунду, а накладные расходы определяются метаданными пространства отката (обычно это очень маленькое число в сравнении с общим размером). Так, например, база данных ord имеет размер блока 8 Кбайт, а параметр UNDO_RETENTION равен 43200 (12 ч). Если каждую секунду генерируется 500 блоков пространства отката, каждый из которых должен быть сохранен в течение, по крайней мере, 12 ч, то общий размер пространства отката вычисляется следующим образом:
П размер_табличного_пространства_отката = 43200 * 500 * 8192 - 177 Гбайт с*
Сюда нужно добавить от 10 до 20% для различных непредвиденных ситуаций. Можно также разрешить автоматическое расширение файлов данных в табличном пространстве отката. Хотя подобные вычисления полезны в качестве отправной точки, встроенные консультанты Oracle 10g, используя анализ тенденций, могут дать более точную общую картину и рекомендации по использованию пространства отката.
Консультант по пространству отката
Undo Advisor из Oracle 10g автоматизирует множество задач, необходи мых для точной настройки количества дискового пространства, которое требуется для табличного пространства отката. В главе 6 рассматри^ лись два примера использования Undo Advisor — из интерфейса Database Control и с использованием пакета PL/SQL DBMS_ADVlb в автоматическом репозитории рабочей нагрузки (AWR) для програ* ного выбора периода времени для анализа и выполнения самого анализ&
Экран графического интерфейса пользователя Undo Advisor пока на рис. 7.8. d0
Хотя UNDOJRETENTION установлен на 43200 (720 мин), из Advisor видно, что период сохранения информации в пространстве о та для поддержки согласованности чтения представлений подлежат изменению таблиц не должен быть больше или меньше 720 мин при Ус вии сохранения текущего использования сегментов отката. |
Когда выше в данной главе создавалось пространство отката (Cj рис. 7.4), для него были установлены некоторые пороговые значеН^
ххо __ . — - ЕГЛ
PL/SQL DBMsJm)VISOe
управление транзакциями с помощью табличных пространств отката
281
Рис. 7.8. Консультант по пространству отката ЕМ Database Control
Опираясь на эти автоматические предупреждения, можно в упреждающем режиме изменять размеры табличного пространства отката, как только потребление пространства отката выйдет за указанные пороговые значения прежде, чем появятся аварийно завершившиеся операторы DML или запросы и чем у вас зазвонит телефон!
Контроль использования пространства отката
Начиная с Огас1е9г, диспетчер ресурсов базы данных Oracle может помочь при контроле использования пространства отката в разрезе пользователей (или групп пользователей) в составе группы потребителей ресурсов посредством директивы UNDO_POOL. Каждая группа потре-ителей ресурсов может иметь собственный пул пространств отката; когда суммарный объем пространства отката, сгенерированного группой, превзойдет установленный предел, текущая транзакция, генерирующая ДЛЯ отката» прекращается и генерирует сообщение об ошибке ann^30027: Und° quota violati°n - failed to get number (bytes)” (ORA-27. нарушение квоты в пространстве отката — не удалось получить ко-личество_байтов (байтов)). Сеанс будет ожидать, пока АБД не увеличит размер пула пространств отката, или пока не завершатся транзакции Других пользователей, принадлежащих к той же самой группе потребления ресурсов.
282
Гпава 7
В следующем примере для пользователей, входящих в группу потреби' телей ресурсов LOW_GROUP, изменяется используемое по умолчанию значение UNDOJPOOL с NULL (неограниченное) до 1000 Кбайт:
□ begin
dbms_resourcejnanager.create_pending_area();
dbms_ resourcejnanager. update. plan_directive(
plan => ‘system_plan’<,
group or_subplan => ‘low_group’,
new_comment => ‘Limit undo space for low priority groups’, new_undo_pool => 1000);
dbms_resourcejnanager.validate_pending area();
dbms..resourcejnanager.submit_pending_area();
end;
Подробнее о диспетчере ресурсов Oracle и других директивах ресурсов см. главу 5.
Согласованность чтения против успешности DML
Для баз данных OLTP нужно, как правило, обеспечить успешность выполнения команд DML даже ценой согласованности запросов по чтению. Однако для сред DSS мы вправе желать, чтобы длительное время выполняющиеся запросы завершались без ошибки “Snapshot too old”. Хотя увеличение параметра UNDO_RETENTION или размера табличного пространства отката помогает сохранять уверенность в том, что блоки пространства отката будут доступны для согласованных по чтению запросов, табличные пространства отката имеют другую характеристику, используемую для гарантированного успешного завершения запросов, — установку RETENTION_GUARANTEE.
Гарантии сохранения пространства отката устанавливаются на уровне табличного пространства и могут быть в любой момент изменены. Установка гарантий сохранения для табличного пространства отката гарантирует, что данные для отката с не истекшим сроком действия в табличном пространстве отката должны сохраняться, даже если для успешного выполнения транзакции DML может оказаться недостаточно места в про странстве отката. По умолчанию табличное пространство отката создает ся со значением установки NOGUARANTEE, если при создании та лип ного пространства отката только не будет указано ключевое GUARANTEE. Это же можно сделать позднее с помощью команды AL 1 TABLESPACE:
□ SQL> alter tablespace undotbsl retention guarantee, Tablespace altered.
SQL> select tablespacejiame, retention
2 from dba.tablespaces
3 where tablespace_name = ‘UNDOTBST;
управление транзакциями с помощью табличных пространств отката
283
TABLESPACE_NAME
RETENTION
UNDOTBS1
GUARANTEE
1 row selected.
Для всех прочих табличных пространств значение RETENTION всегда равно NOT APPLY.
Flashback-опции
В этом разделе обсуждаются так называемые Flashback-опции, поддерживаемые табличными пространствами отката: Flashback Query (ретроспективные запросы), Flashback Table (ретроспекция таблиц), Flashback Version Query (ретроспективный запрос версий) и Flashback Transaction Query (ретроспективные запросы на уровне транзакций). Кроме того, рассматриваются “избранные места”, связанные с использованием пакета DBMS_FLASHBACK.
Опции Flashback Database (ретроспекция базы данных) и Flashback Drop (ретроспекция удалений, или корзина для мусора) будут рассмотрены в главе 15. Опция Flashback Database использует журналы Flashback во Flash Recovery Area (область группового flash-восстановления) вместо данных для отката в табличных пространствах отката, чтобы обеспечить функциональность Flashback. Опция Flashback Drop помещает удаленные таблицы в виртуальную корзину для мусора в некотором табличном пространстве, где они и остаются, пока пользователь не извлечет их оттуда с помощью команды flashback table... to before drop. Эта опция или очистит корзину для мусора, или пространство корзины не понадобится для хранения новых постоянных объектов в этом табличном пространстве.
Для дальнейшего расширения возможностей самообслуживания в Oracle 10gАБД может предоставить пользователям системные и объектные привилегии, позволяющие им разрешать проблемы самостоятельно, не обращаясь за помощью к АБД. В следующем примере пользователю SCOTT разрешается выполнять Flashback-операции над конкретными таблицами и получать доступ к метаданным для всей базы данных:
О SQL> grant insert, update, delete, select on hr.employees to scott; Grant succeeded.
SQL> gra t insert, update, delete, select on hr.departments to scott; Grant succeeded.
SQL> g ar flashback on hr.employees to scott;
Grant succeeded.
SQL> gra t ashback on hr.departments to scott;
Grant succeeded.
SQL> grant select any transaction to scott;
Grant succeeded.
Flashback Query
Начиная c Oracle 9Й, в операторе select стала доступна фраза as of предназначенная для получения того состояния таблицы, которое она имела В заданный момент времени или для заданного SCN. Эту фразу можно ис
284
Гпава 7
пользовать, например для определения того, какие строки были удалены из таблицы после полуночи, или просто для сравнения “сегодняшних” и “вчерашних” строк таблицы.
В следующем примере пользователь SCOTT выполняет очистку табли-цы HR.EMPLOYEES и удаляет из нее двух служащих, которые более не работают на компанию:
□ SQL> delete from hr.employees
2 where employee_id in (195, 196);
2 rows deleted.
SQL> commit;
Commit complete.
SQL>
Обычно SCOTT сначала копирует такие строки в таблицу HR.EMPLOYEES_ARCHIVE, но в этот раз он забыл выполнить эту операцию; ему не нужно возвращать эти строки обратно в таблицу HR.EMPLOYEES, но необходимо получить эти две удаленные строки и поместить их в архивную таблицу. Поскольку SCOTT знает, что эти две записи были удалены не более чтем один час тому назад, мы можем для получения этих строк использовать во Flashback-запросе относительное значение метки времени:
□ SQL> insert into hr.employees_archive
2 select * from hr.employees
3 as of timestamp systimestamp - interval ‘60’ minute
4 where hr.employees.employee_id not in
5 (select employee_id from hr.employees);
2 rows created.
SQL> commit;
Commit complete.
Поскольку известно, что EMPLOYEEJD является первичным ключом таблицы, его можно использовать для выборки записей служащих, кото рые существовали час тому назад, но не существуют сейчас. Заметьте так же, что неизвестно, какие именно записи были удалены; мы, по сути просто сравнили таблицу в ее теперешнем виде с тем, какой она была тому назад, и вставили более не существующие в ней записи в архивну таблицу.
Совет Использование в Flashback-запросе системного номера изменений (S предпочтительнее использования отметки времени: SCN являются точными, в время как значения отметок времени для поддержки Flashback-операций сохра ются только каждые пять минут. В результате при активации Flashback с исполь ванием отметок времени можно сбиться на целых 150 сек.
управление транзакциями с помощью табличных пространств отката 285
Хотя можно использовать опцию Flashback Table для восстановления всей таблицы и последующей архивации и удаления тех строк, что стали виновниками переполоха, в этом случае намного проще получить удаленные строки и непосредственно вставить их в архивную таблицу.
Еще один вариант использования Flashback Table — это использовать оператор Create Table As (CTAS) с подзапросом, являющимся ретроспективным запросом:
□ SQL> delete from hr.employees where employee_id in (195, 196);
2 rows deleted.
I
SQL> commit;
Commit complete.
SQL> create table hr.employees deleted as
2 select * from hr.employees
3 as of timestamp systimestamp - interval ‘60’ minute
4 where hr.employees.employee_id not in
5 (select employe_id from hr.employees);
Table altered.
SQL> select employee_id, last_name-from hr.employees deleted;
EMPLOYEE_ID LAST NAME
195 Jones
196 Walsh
2 rows selected.
Такая практика известна как out-of-place restore (восстановление в другом месте), или восстановление таблицы или ее подмножества не в том месте, где расположен оригинал таблицы. При таком подходе появляется возможность при необходимости манипулировать потерянными строками, прежде чем они будут вставлены обратно в таблицу; например, после изучения восстановления в другом месте, имеющиеся ограничения ссылочной целостности могут потребовать, чтобы в родительскую таблицу была вставлена строка, прежде чем восстановленная строка будет возвращена в дочернюю таблицу.
Одним из недостатков восстановления в другом месте с использованием CTAS следует считать то, что ни ограничения, ни индексы для таблицы ав оматически не восстанавливаются.
DBMS_FLASHBACK
Альтернативой ретроспективным запросам является пакет DBMS_ LASHBACK. Одно из ключевых различий между пакетом DBMS_ FLASHBACK и Flashback Query состоит в том, что DBMS FLASHBACK работает на уровне сеанса, в то время как Flashback Query действует на уров-не объектов.
286
Гпава 7
В рамках процедуры PL/SQL или сеанса пользователя может быть ак-тивирован пакет DBMS_FLASHBACK, а все последующие операции, включая существующие приложения, могут быть реализованы без добавляемой в операторы select фразы as of. После активации пакета DBMS FLASHBACK по состоянию на конкретный SCN или на конкретную отметку времени база данных начинает выглядеть так, как если бы часы Bej -нулись к той отметке времени или к этому SCN. И закончится все это только после отключения пакета DBMS_FLASHBACK. Хотя в промежуток времени действия пакета DBMS. FLASHBACK операции DML не разрешены, можно открыть курсор в процедуре PL/SQL, чтобы позволить вставить (или обновить) данные из предыдущего момента времени в базу данных текущего момента времени.
Процедуры, активирующие и отключающие режим Flashback, относительно просто использовать. Вся сложность обычно кроется в процедуре PL/SQL, например в процедуре, которая создает курсоры для поддержки команд DML.
В следующем примере мы снова вернемся к удалению пользователем SCOTT строк из таблицы HR.EMPLOYEES восстановлению их в таблице, используя пакет DBMSJFLASHBACK. В этом сценарии SCOTT помещает строки удаленных служащих обратно в таблицу, а вместо удаления записей добавляет в таблицу столбец даты окончания службы, в который заносится дата ухода служащего из компании:
□ SQL> delete from hr.employees where employee_id in (195, 196);
2 rows deleted.
SQL> commit;
Commit complete.
Примерно через 30 минут SCOTT принимает решение возвратить эти строки, используя DBMS_FLASHBACK, и активирует для этого сеанса Flashback:
I
□ SQL> execute dbms_flashback.enable at_time(
2 to timestamp(sysdate - interval ‘45’ minute));
PL/SQL procedure successfully completed.
Tаблица 7.2. Процедуры пакета DBMSJFLASHBACK
Процедура Описание
DISABLE EN АВ LE_AT_SYSTEM_GH ANG E_N UMBER Отключает режим Flashback для сеанса Активирует режим Flashback для сеанса, указывая SCN
EI\IABLE_AT_T!ME Активирует режим Flashback для сеанса, указывая SCN, ближайший к заданной отметке времени
GETSYSTEM-CHANGE NUMBER SCN-TCLTIMESTAMP TIMESTAMP_TO_SCN Возвращает текущий SCN Конвертирует TIMESTAMP Oracle и возвращает SCN, ближайший к заданному значению TIMESTAMP
управление транзакциями с помощью табличных пространств отката
287
Затем он подтверждает, что две удаленные строки существовали 45 мин тому назад:
□ SQL> select employee_id, last_name from hr.employees
2 where employee_id in (195, 196);
EMPLOYEE_ID LAST.NAME
195 Jones
196.Walsh
SQL>
Чтобы вернуть строки обратно в таблицу HR.EMPLOYEES, SCOTT пишет анонимный блок PL/SQL, создающий курсор для хранения удаленных строк, отключает Flashback Query и затем снова вставляет эти строки:
□ declare
- - курсор для хранения удаленных строк перед закрытием cursor del_emp is
select * from hr.employees where employee_id in (195, 196);
del. emp .rec del emp%rowtype, -- все столбцы строки employee begin
- - открыть курсор, по-прежнему находясь в режиме Flashback open del_emp;
- - выключить режим Flashback, чтобы можно было использовать DML
- - для обратного помещения строк в таблицу HR.EMPLOYEES dbms_flashback.disable;
loop
fetch del_emp into del_emp_rec;
exit when del emp%notfound;
insert into hr.employees values del_emp_rec;
end loop;
commit;
close del.emp;
end; -- конец анонимной процедуры PL/SQL
Заметьте, что SCOTT мог бы активировать Flashback внутри процедуры; в этом случае он активировал его вне процедуры для выполнения некоторых нерегламентированных запросов, затем использовал процедуру для создания курсора, отключил Flashback и повторно вставил строки.
Flashback Table
пция Oracle 10gFlashback Table (ретроспекция таблиц) восстанавлива-ст не только состояние строк в таблице на какой-то прошедший момент времени, но и индеь ы, триггеры и ограничения таблицы, в то время как сама база данных остается в онлайновом состоянии, что увеличивает полную дос гупность б ы данных. Таблица может быть восстановлена по состоянию на определенный момент времени или определенный SCN. Оп
288
Гпава 7
ция Flashback Table представляется более предпочтительной, чем другие Flashback-методы, если область ошибок пользователя невелика и огранц-чена одной или несколькими таблицами. Кроме того, этот метод удобнее и проще других методов, если известно, что таблицу следует восстановить в состоянии на какой-то прошедший момент времени без каких бы то ни было условий (безусловное восстановление). Для восстановления состояния большего числа таблиц более удачным выбором может оказаться опция Flashback Database. Опция Flashback Table не может быть использована для резервной (standby) базы данных. С ее помощью нельзя реконструировать операции DDL, например добавление и удаление столбцов.
Чтобы использовать Flashback Table для таблицы или таблиц, прежде, чем выполнять Flashback-операции, необходимо активировать для таблицы так называемое перемещение строк (row movement), хотя перемещение строк не должно действовать в то время, когда происходят ошибки пользователя. Кроме того, перемещение строк требуется также для поддержки функциональной возможности сжатия сегментов Oracle; так как при сжатии сегментов изменяется ROWID строки таблицы, не активируйте перемещение строк, если ваше приложение зависит от того, остается ли ROWID для данной строки постоянным до тех пор, когда строка будет удалена из таблицы. Так как ни одно из приложений не ссылается на используемые таблицы по ROWID, можно без опаски активировать для наших таблиц перемещение строк:
□ SQL> alter table hr.employees enable row movement;
Table altered.
SQL> alter table hr.departments enable row movement;
Table altered.
На следующий день SCOTT случайно удаляет все строки в таблице HR.EMPLOYEES, что было связано с непреднамеренной ошибкой при редактировании (вырезать и вклеить) существующего сценария:
□ SQL delete from hr.employees
2 /
107 rows deleted.
SQL> commit
2 ;
Commit complete.
SQL> where employee_id = 195
SP2-0734: unknown command beginning “where empl...” -- остаток строки игнорируется.
(SP2-0734: неизвестная команда, начинающаяся с “where empl...” — оста1 строки игнорируется.)
Поскольку табличное пространство отката достаточно велико и пер1 од сохранения информации рарен 12 час, SCOTT может, не обращая к АБД, вернуть назад всю таблицу:
управление транзакциями с помощью табличных пространств отката
289
□ SQL> flashback table hr.employees
2 to timestamp systimestamp - interval ‘15 minute; Flashback complete.
SQL> select count(*) from hr.employees; COUNTS)
107
Если между двумя или большим количеством таблиц имеется отношение родитель/потомок с ограничениями внешнего ключа, и строки были непреднамеренно удалены из обеих таблиц, они могут быть возвращены обратно той же самой командой Flashback:
□ SQL> flashback table hr.employees, hr.departments
2 to timestamp sysstimestamp - interval ‘15’ minute; Flashback complete.
Пользователь SCOTT может также использовать для возвращения назад одной или нескольких таблиц ЕМ Database Control. На рис. 7.9 он выбрал ссылку Perform Recovery (выполнить восстановление) под заголовком Backup/Recovery (Резервное копирование/восстановление) во вкладке Maintenance (обслуживание).
Выбрав в качестве типа объекта Tables (таблицы), SCOTT имеет возможность возвратить назад существующие или удаленные таблицы.
Рис. 7.9. Резервное копирование/восстановление в ЕМ Database Control
290
Гпава 7
Рис. 7.10. Ретроспекция существующих таблиц
В этом случае он желает возвратить назад существующую таблицу (см. рис. 7.10).
После щелчка на кнопке Next он узнает точное время суток, на которое была действительна таблица, так что он-указывает это на экране рис. 7.11.
На рис. 7.12 SCOTT выбирает таблицу, которую он собирается возвратить назад (в данном случае это HR.EMPLOYEES). На экране отображается выбранная метка времени и эквивалентный SCN.
ЕМ Database Control идентифицирует любые зависимости, например, ограничения внешнего ключа, и предупреждает пользователя SCO 11 (см. рис. 7.13). Если только нет хорошей причины разорвать любые отно шения родитель/потомок между таблицами, рекомендуем оставить ис пользуемую по умолчанию опцию Cascade (каскад).
Щелчок на Show Dependencies (показать зависимости) делает именно то, что от него ожидается: показывает зависимости между внешним ключами таблицы, подлежащей возобновлению, и родительскими тао-Я цами. Вся иерархия зависимостей изображена на рис. 7.14.
На рис. 7.15 SCOTT может еще раз взглянуть на выбранные им опции•
Как и для большинства экранов ЕМ Database Control, он может пр смотреть сгенерированные команды SQL:
П FLASHBACK TABLE HR.EMPLOYEES, HR.JOBS, HR.DEPARTMENTS TO TIMESTAMP to timestamp(‘2004-04-15 06:15:12 PM’, ‘YYYY-MM-DD HH:MI:SS AM’)
Щелкнув на кнопке Submit, мы запускаем команду на выполнение.
транзакциями с помощью табличных пространств отката
291
Эfal p:7/137.16tf.?-166:^500(em/cont>&k7dalab^/tu<//l4$^|>ack?vdlue lUe*enp£al?labjcctlype-t.ibIe M... h»_
Fite Edrf. View Fax'Ctites Took .‘teip
s’ Search Favontev
CRACXC imerpiise Manager 10г/ IhUbase Control
< i
> /Л
poiht-hi tlHV;
Ch-yjSk* 3CH
7-xb t'j'
О«рл».»псу
iyependsruies Me»-
PachdrkS'VeiSiCDS
li
Perform Recovery: PoinHMime
Object Type Tables
Operation Type Flashback Existing Tables
Specify me point in time tc which to recover
OEvaiuate row change and transactions to decide on a point in time
* Table
Ф Flashback Io a timestamp
Date r 'T- a 13 :cs3
О Flashback to a known SCN
Time 06
ЧЭ Intern* ........
r-
йй
Рис. 7.11. Выбор даты и времени для Flashback Table
Рис. 7.12. Выбор Flashback Table
292
Глава
Рис. 7.13. Опции зависимостей ЕМ Database Control
Рис. 7.14. Иерархия зависимостей Flashback
транзакциями с помощью табличных пространств отката
293
Э h«? ЩM Ш?-166: W00/H ifca0>ate/<l<«tjib4iehfecyiatf»>^saufMr_ UbUNav^v^U1* J . V 7.
ЭД
Fde Edit View Favorites Teo's Help
«Ь. >> : V. ’
Swadi 4 Favorites
OOACL.ts; Емкчргйи» Manage» 10g DMabasa Cefiiru!
«Ф<Х*Х<ЛЧ*'
RfMSW
Perform Recovery: Review
(Баск I Step 7 of7 ^Submit)
Object Type Tables
, Operation Type Flashback Existing Tables
The following tables will be flashed beck All these tables wfil be locked while the flashback operation is in progress.
SCN
Timestamp
Tables Dependent Tables
1667880
Apt 15. 2004 06:15 PM
HR.EMPLOYEES
HRJOBS, HR.OEPARTMEMTS
(Cancel) kShow Row Changes) ., Show SQl) ( Sack | Step
Database I | E^feiencgA I Н&Ш I UfliUil
Copyright © 1996,20C4. Oracta Ali rights reserved
MOM
:-
МММНШМ11
4) Internet
(i . ;
Рис. 7.15. Проверка опций Flashback Table
В примере с пользователем SCOTT использование командной строки потребовало бы меньшего времени и было бы, вероятно, более очевидным; но если имеются неизвестные зависимости, или если вы не слишком хорошо знакомы с синтаксисом командной строки, то ЕМ Database Control является лучшим выбором.
Flashback Version Query
Еще одной Flashback-опцией является Flashback Version Query, которая использует данные пространства отката и обеспечивает более мелкий Уровень детализации, чем запросы as of. В то время как методы Flashback возвращают строки таблицы или всю таблицу целиком на какой-то конкретный момент времени, Flashback Version Query возвращает нам всю историю для заданной строки в интервале между двумя SCN или между Двумя отметками времени.
Специально для примеров в этом и следующем разделах пользователь SCOTT делает некоторое количество изменений в таблицах HR.EMPLOYEES и HR.DEPARTMENTS:
SQL> select dbms_flashback.get_system_change_number from dual;
gET__SYSTEM_CHANGE_NUMBER
1673333
294
Гпава
SQL> update hr.employees set salary = salary *1.2 where employee_id = ig5. 1 row updated.
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
1673349
SQL> delete from hr.employees where employee_id = 196;
1 row deleted.
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
1673406
SQL> insert into hr.departments values (660, ‘Security’, 100, 1700); 1 row created.
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
1673433
SQL> update hr.employees set manager_id = 100 where employee_id = 195;
1 row updated.
SQL> commit;
Commit complete.
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
1673455
SQL> update hr.employees set department-id = 660 where employee_id = 195 1 row updated.
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
1673602
. . - 195’
SQL> update hr.employees set salary = salary * 1.2 where employee_ia
1 row updated.
SQL> commit;
Commit complete.
управление транзакциями с помощью табличных пространств отката
295
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
1674188
SQL>
На следующий день пользователя SCOTT не было в офисе, а сотрудникам кадровой службы понадобилось узнать, какие строки и таблицы были изменены. Используя Flashback Version Query, пользователь HR может не * только увидеть значения столбцов в определенные моменты времени, но и всю хронологию изменений в интервале между заданными временными метками или SCN.
В опции Flashback Version Query для задания диапазона отметок времени или SCN для анализа таблицы (в данном случае HR.EMPLOYEES) используется фраза versions between. Если используется эта фраза, становятся доступными большое число псевдостолбцов, призванных помочь при идентификации SCN и отметок времени модификаций, а также идентификатора транзакции и типа операции, выполнявшейся над таблицей. В таблице 7.3 показаны все псевдостолбцы, доступные при работе с Flashback Version Query.
Таблица 7.3. Псевдостолбцы Flashback Version Query
Псевдостолбец
Описание
VERSIONS_START{SCNITIME}
Начальный SCN или отметка времени, когда было сделано изменение строки.
VERSIONS_END{SCNITIME} Завершающий SCN или отметка времени, когда изменение для строки перестало действовать. Если это значение NULL (пусто), это означает, что либо изменение продолжает действовать, либо строка была удалена.
VERSIONS_XID Идентификатор той транзакции, которая создала вер-
сию строки.
VERSIONS.OPERATION Выполненная над строкой операция (l=lnsert, D=Delete,
U=Update).
Пользователь HR выполняет Flashback Version Query, чтобы увидеть изменения любого ключевого столбца таблицы HR.EMPLOYEES для двух служащих с учетными номерами 195 и 196:
SQL> select versions_startscn startsen, version_endscn endsen,
Jr version_xid xid, versions_operation oper, employee_id empid, last_name name, manager_id mgrid, salary sal
4 from hr. employees
5 versions between sen 1673333 and 1674188
6 where employee^id in (195, 196);
^STARTSCN ENDSCN XID OPER EMPID NAME MGRID SAL
^74182 0400240098030000 U 195 Jones 'l00 ~~~4032
1°'3453 1674182 0400160098030000 U 195 Jones 100 3360
296
Гhqbq?
1673368 1673453 04000F0098030000 U 195 Jones 123 З3бо
1673368
1673368
04000F0098030000 D
1673368
195 Jones
196 Walsh
196 Walsh
123
124
124
2800
3100
3100
6 rows selected.
Представление строк начинается с самых последних изменений. Кадровая служба может фильтровать запрос по значениям отметки времени (TIMESTAMP) или выводящимся на экран значениям TIMESTAMP, Но в операциях Flashback Query или Flashback Table может быть использован любой из этих двух вариантов, если это потребуется впоследствии. Из этих выходных данных видно, что один служащий был удален, а для второго были проведены две корректировки заработной платы вместо одной. Кроме того, некоторые из транзакций содержат всего одну команду DML, в то время как другие — по две.
Flashback Transaction Query
После того как были идентифицированы какие-то ошибочные или неверные изменения, внесенные в таблицу, для идентификации любых других изменений, произведенных содержащей эти ошибочные изменения транзакцией, можно использовать Flashback Transaction Query (ретроспективный запрос на уровне транзакции). После их идентификации все изменения, сделанные в рамках этой транзакции, могут быть “обращены” как единая группа, как правило, для сохранения, в первую очередь, ссылочной целостности бизнес-правил, используемых для обработки транзакции.
В отличие от Flashback Version Query, Flashback Transaction Query не ссылается на таблицу, используемую в транзакции DML; вместо этого пользователь обращается с запросом к представлению словаря данных FLASHBACK_TRANSACTION_QUERY (см. таблицу) 7.4.
Для дальнейшего исследования изменений, внесенных в таблицу HR.EMPLOYEES, нужно сделать запрос к представлению FLASHBACK. TRANSACTION-QUERY, указав в нем номер самой “старой” транзакции из предыдущего раздела:
□ SQL> select start_scn, commit_scn, logon_user,
2 operation, table_name, undo_sql
3 from flashback_transaction_query
4 where xid = hextoraw(‘04000F0098030000’);
START_SCN COMMIT_SCN LOGONJJSER OPERATION TABLE_NAME
UNDO_SQL
1673366 1673368 SCOTT DELETE EMPLOYEES
insert into “HR”."EMPLOYEES"(“EMPLOYEE_ID”, “FIRST-NAME”, “LAST_NAMt “EMAIL”, “PHONE_NUMBER”, “HIRE_DATE”, “JOB_ID’, “SALARY”, “COMMISS1U/ PCT”, “MANAGER_ID”, “DEPARTMENT-ID”) values (‘196 ‘ , ‘Alana’, ‘Walsn* ‘AWALSH’, ‘650.507.9811’, TO_DATE(‘24-APR-98’, DD-MON-RR’), ‘ SH_CLEH^ ‘3100’, NULL, ‘124’, ‘50’);
управление транзакциями с помощью табличных пространств отката 297
1673366 1673368 SCOTT UPDATE EMPLOYEES
update “HR”."EMPLOYEES" set “SALARY” = ‘2800’ where ROWID = 1AAAMAeAAFAAAABYABc’ ;
1673366 1673368 8С0П
3 rows selected.
BEGIN
Таблица 7.4. Столбцы представления FLASHBACK_TRANSACTION_QUERY
Имя столбца
XID
START-SCN STARTTIMESTAMP COMMIT_SCN COMMIT_TIMESTAMP LOGOI\l_USER UNDO_CHANGE# OPERATION
TABLE-NAME TABLE-OWNER ROWJD
UNDO-SQL
Описание
Номер идентификатора транзакции
SCN для первого оператора DML в транзакции
Отметка времени для первого оператора DML в транзакции SCN, при котором транзакция была зафиксирована Отметка времени, когда транзакция была зафиксирована Пользователь, являющийся владельцем транзакции SCN отката
Выполненная операция DML: DELETE, INSERT, UPDATE, BEGIN или UNKNOWN
Таблица, изменяемая операторами DML
Владелец изменяемой таблицы
Псевдостолбец R0WID для модифицируемой оператором DML строки
Оператор SQL для отмены операции DML
Этим подтверждается то, что ожидалось заранее, — пользователь SCOTT выполнил удаление и обновление заработной платы. Столбец UNDO_SQL содержит код SQL, который можно использовать для достижения обратного эффекта. В данном примере это будет первая транзакция в интересующем нас диапазоне SCN. Если другие транзакции вносили в столбец дальнейшие изменения, придется исследовать и другие обновления, прежде чем выполнить корректирующий оператор SQL. Взглянув На самую последнюю транзакцию в последовательности, мы увидим, что это было последнее обновление столбца SALARY для служащего:
° SQL> select start_scn, commit_scn, logon_user,
2 operation, table_name, undo__sql
3 from flashback_transaction_query
4 where xid = hextoraw(‘04000F0098030000’);
START_SCN COMMIT-SCN LOGONJJSER OPERATION TABLE_NAME
undo_sql
1673386 1674182 SCOTT UPDATE EMPLOYEES
^date “HR". “EMPLOYEES” set “SALARY” = ‘3360’ where ROWID = AAAMAeAAFAAAABYABc’ ;
298
Гпава 7
1673386 1674182 SCOTT INSERT JOB_HISTORY
delete from “HR”."JOB_HISTORY" where ROWID = ‘AAAMAiAAFAAAAB tAAB’;
1673386 1674182 SCOTT UPDATE EMPLOYEES
update “HR.’’EMPLOYEES” set “DEPARTMENT_ID” = ‘50’ where ROW ID = ‘AAAMAeAAFAAAABYABc’;
1673386 1674182 SCOTT BEGIN
4 rows selected.
Первое обновление зарплаты было правильным, в то время как второе (самое последнее) является дублем (повторением) первого и по этой причине должно быть признано недействительным. Кроме того, в той же самой транзакции SCOTT изменил для служащего значение столбца DEPARTMENT_ID и занес запись (insert) в таблицу HRJOB_HISTORY. Этот оператор insert не был результатом в явном виде записанной команды DML, но, скорее всего, результатом выполнения триггера для таблицы HR.EMPLOYEES, который протоколирует изменения таблицы HR.EMPLOYEES в таблице HRJOBS_HISTORY при каждом изменении столбцовJOBJD или DEPARTMENT-ID. Отменить (инвертировать) следует самое последнее изменение зарплаты:
□ SQL> update “HR’.’’EMPLOYEES"
2 set “SALARY” = ‘3360’ where ROWID = ‘AAAMAeAAFAAAABYABc’;
1 row updated.
SQL> commit;
Commit complete.
Взглянув на вторую (с конца) транзакцию, можно увидеть оператор вставки (insert) в таблицу HR.DEPARTMENTS, а также повторное отнесение служащего к этому новому отделу:
□ SQL> select start_scn, commit_scn, logon_user,
2 operation, table_name, undo_sql
3 from flashback_transaction_query
4 where xid = hextoraw(‘0400160098030000’);
START_SCN COMMIT „SCN LOGON_USER OPERATION TABLE_NAME
UNDO_SQL
1673449 1673453 SCOTT UPDATE EMPLOYEES
update “HR”."EMPLIYEES” set “MANAGER_ID” = ‘123’ where ROWID = ‘AAAMAeAAFAAAABYABc’;
1673449 1673453 SCOTT INSERT DEPARTMENTS
delete from “HR”.“DEPARTMENTS" where ROWID = ‘AAAMAZAAFAAAAA 1AAB’
1673449 1673453 SCOTT BEGIN
3 rows selectea.
управление транзакциями с помощью табличных пространств отката
299
Поскольку столбец DEPARTMENTJD не был включен в Flashback Versions Query, то сразу не было очевидно, что имели место другие изменения в других столбцах таблицы HR.EMPLOYEES, а также были вставлены новые строки в таблицу HR.DEPARTMENTS.
Миграция в среду автоматического управления пространством отката
Для переноса (миграции) среды с управляемых вручную сегментов отката (rollback segments) в среду автоматически управляемого пространства отката (AUM) необходимо знать, насколько большим следует сделать табличное пространство отката, если основываться на использовании “ручных” сегментов отката при откате в ручном режиме. Когда все сегменты отката (ручные) будут в онлайновом режиме, нужно выполнить процедуру DBMS_UNDO_ADV.RBU_MIGRATION, чтобы получить размер в мегабайтах, соответствующий текущему использованию сегментов:
□ SQL> variable undo_size number
SQL> begin
2 :undo_size := dbms_undo__adv. rbu.migration;
3 end;
4 /
PL/SQL procedure successfully completed.
SQL> print :undo_size
UNDO SIZE
2840
SQL>
В этом примере табличное пространство отката, создаваемое для замены сегментов отката, должно иметь размер не менее 2840 Мбайт, или 2.84 Гбайт, чтобы поддержать требования отката, соответствующие требованиям, которые поддерживаются в настоящее время “ручными” сегментами отката.
настройка базы данных
С точки зрения производительности каждая система спроектирована так, что обязательно наступит момент, когда она выйдет из строя. Целью
проектирования производительности является достижение уверенности в том, что физические ограничения приложения — пропускная способность ввода/вывода, размеры памяти, производительность запросов и тому подобные вещи — не оказывают влияния на производительность предприятия в целом. Если производительность приложения ограничивает бизнес-процесс, который оно, как предполагалось, должно было поддерживать, это означает, что приложение необходимо настроить. В процессе проектирования приложения должны быть оценены пределы среды приложения — в том числе аппаратное обеспечение и проектирование взаимодействия приложения с базой данных. Никакая среда не обеспечивает бесконечных вычислительных возможностей, поэтому для любой среды наступает момент, когда она перестает справляться с требованиями производительности. В процессе проектирования приложения необходимо бороться за то, чтобы потребности пользователей в произво дительности были поддержаны возможностями системы.
Настройка производительности является частью жизненного цикла каждого приложения базы данных, и чем раньше на эти проблемы буД обращено внимание, тем больше вероятность того, что они будут УсП^ но разрешены. Как отмечалось в предыдущих главах, большинство занных с производительностью проблем являются не изолировании симптомами, а скорее результатом проектирования системы. Поэ все усилия по настройке должны быть направлены на идентификац исправление глубинных дефектов, которые и приводят к неприемле производительности.
Настройка является заключительным этапом процесса, включаю еще три этапа: планирование, реализация и мониторинг, которые пр шествуют настройке. Если настройка осуществляется только ради 116 мой, вам не удастся охватить полный цикл деятельности, и, скорее вС будет невозможно докопаться до базовых проблем, вызвавших снйЖе производительности.
^стройка базы данных
301
Большинство объектов базы данных, которые можно настраивать, уже обсуждались выше в данной книги — например, управляемые сегменты отката были рассмотрены в главе 7. В настоящей главе будут обсуждаться только связанные с настройкой действия, тогда как в их “собственных” (посвященных им) главах рассматриваются действия по планированию и мониторингу.
Начиная с Oracle 10g, стало возможным использовать преимущества новых инструментальных средств настройки и новых возможностей Oracle, в том числе, Automatic Workload Repository. Усовершенствованы средства, знакомые по предыдущим версиям, например, пакет STATSPACK (подробнее о реализации и использовании этого пакета см. главу 9).
В последующих разделах рассматриваются операции по настройке в следующих областях:
Проектирование приложения
SQL
Использование памяти
Хранение данных
Манипулирование данными
Физическое хранение
Логическое хранение
Сетевой трафик
Проектирование настройки приложения
Почему в руководство по настройке для администратора БД должен быть включен раздел, посвященный проектированию приложения? И почему этот раздел должен идти первым? Дело в том, что по своему влиянию на производительность системы ни одно действие администратора не может сравниться с проектированием приложения (о необходимости участия администратора в процессе разработки приложения см. главу 5). Проектируя приложение, нужно предпринять некоторые шаги для эффективного и правильного использования доступных технологий.
1!1и
ективное проектирование таблиц
Независимо от того, насколько хорошо спроектирована база данных, плохое проектирование таблиц приведет к низкой производительности системы. Причем производительность снижается также и из-за чересчур строгого следования принципам проектирования реляционных таблиц. Дело в том, что, хотя полностью реляционные таблицы (в так называемой третьей нормальной форме) логически вполне приемлемы, физически они нежелательны.
Проблемы подобного проекта связаны с тем, что, хотя эти таблицы точно отражают способы взаимодействия данных приложения с другими Данными, они не показывают обычных маршрутов доступа, применяемых пользователями для обращений к этим данным. Если определить тре
302
Гпава 8
бования, предъявляемые к способу доступа пользователей, полностью реляционный проект окажется неработоспособным для больших запросов. Как правило, проблемы начинаются с появления запросов, возвращающих большое число столбцов. Обычно такие столбцы рассеяны по таблицам, что заставляет объединять таблицы в ходе обработки запроса. Если одна из объединяемых таблиц окажется слишком большой, пострадает производительность всей системы.
Таким образом, проектируя таблицы для приложения, разработчики должны сначала создавать таблицы в третьей нормальной форме, а затем рассмотреть возможность денормализации данных, чтобы удовлетворить конкретные требования, например создание небольшой суммарной таблицы из больших статических таблиц. Могут ли данные быть динамически извлечены из больших статических таблиц по требованию пользователей? Безусловно, но, если пользователям часто требуются такие данные (а они в основном не меняются), разумно было бы сохранять их в том формате, в котором они нужны пользователям.
Например, некоторые приложения сохраняют предыдущие и текущие данные в одной и той же таблице. Каждая запись может иметь столбец типа Timestamp (отметка времени), и текущей записью набора будет та, у которой самая свежая отметка времени. Каждый раз, когда пользователь обращается к таблице за текущей записью, ему необходимо выполнить подзапрос, например, следующего вида:
□ where timestamp_col =
(select max(timestamp_col) from table
where emp_name=’какое_то_имя’)
Если две такие таблицы объединяются, будет два подзапроса. В небольшой базе данных проблема производительности может и не возникнуть, но когда число таблиц и строк возрастает, тогда и начинаются такие проблемы. Отделение предыдущих данных от текущих (или сохранение их в отдельной таблице) создаст дополнительную работу для администратора и разработчиков, но повысит долгосрочную производительность
приложения.
Если проектирование таблиц ориентировано на запросы пользовате лей, а не на строгое следование теории, вся система будет в большей степе ни соответствовать запросам. При этом возможности проектирования будут включать как разделение одной таблицы на несколько, так и объеди нение нескольких таблиц в одну. Особое внимание следует уделить тому» чтобы предоставить пользователю наиболее прямой возможный маршр) к нужным ему данным и в том формате, в котором они ему нужны.
Распределение требований к центральному процессору
При условии эффективного проектирования и предоставления кого аппаратного обеспечения приложение базы данных Oracle б уДеТ рабатывать запросы ввода/вывода без избыточных ожиданий, испоЛ** вать выделенные области памяти без свопинга и подкачки стра с диска, а также применять центральный процессор (ЦП), не генеР?*д0 при этом высоких значений средней нагрузки. Данные, которые бь
Настройка базы данных
303
считаны в память одним процессом, должны быть сохранены в памяти, чтобы их могли повторно использовать многие процессы, прежде чем эти данные будут вытеснены из памяти. Команды SQL используются посредством разделяемой области SQL, что еще больше снижает нагрузку на систему.
Если нагрузка ввода/вывода снижается, может возрасти нагрузка на ЦП. У разработчиков есть несколько способов управления его ресурсами:
Нагрузку на процессор нужно планировать: оставляйте выполняющиеся длительное время пакетные запросы или программы обновления на нерабочие часы. Вместо того чтобы назначать им низкую приоритетность на уровне операционной системы в то время, когда пользователи выполняют оперативную обработку транзакций, лучше запускать их в удобное время с нормальными приоритетами. Это уменьшит возможность возникновения потенциальных конфликтов блокировок, откатов и ЦПУ.
Шире используйте возможности физического переноса нагрузки на центральные процессоры с одного сервера на другой. Старайтесь изолировать сервер базы данных от требований к процессору со стороны приложения. Технология распределения данных (см. часть IV), позволяет сохранять данные в наиболее удобном для этого месте, а требования к ресурсам процессора со стороны приложения отделить от требований к системе ввода/вывода со стороны базы данных.
Рассмотрите использование-технологии Real Application Clusters (RAC), предоставляемой Oracle в целях распределения потребностей в доступе к базе данных для одной базы данных по нескольким экземплярам.
Используйте возможности управления ресурсами базы данных. С помощью утилиты Database Resource Manager (диспетчер ресурсов базы данных) можно создать планы выделения ресурсов и группы потребителей ресурсов. Затем, используя утилиты Oracle, можно изменять ресурсы, назначенные группам потребителей (подробнее об использовании утилиты Database Resource Manager см. главу 5).
Используйте утилиту Parallel Query (PQ) для распределения требований по обработке команд SQL между несколькими процессорами. Параллелизм может быть использован практически в каждой команде SQL, включая select, create table as select, create index, recover и средства загрузки данных в режиме SQL*Loader Direct Path.
Степень распараллеливания транзакции зависит от установленной Для нее степени параллелизма. Каждая таблица характеризуется определенной степенью параллелизма. Принятую по умолчанию степень параллелизма запрос может переопределить с помощью подсказки PARALLEL. Для того чтобы определить степень параллелизма по умолчанию, Oracle определяет количество процессоров, доступных на сервере, и число дисков, на которых сохраняются данные таблицы.
Максимально доступный параллелизм устанавливается на уровне экземпляра. Параметр инициализации PARALLEL_MAX_SERVERS определяет
304
Гпава 8
максимальное количество серверных процессов параллельных запросов, которые могут в любой момент времени использоваться всеми процессами в базе данных. Например, если в экземпляре установлено значение параметра PARALLEL_MAX_SERVERS, равное 32, и запускается запрос, использующий для своих операций запроса и сортировки 30 серверных процессов параллельных запросов, всем остальным пользователям базы данных будет доступно только два таких процесса. Поэтому внимательно относитесь к управлению параллелизмом, задаваемым для запросов и пакетных операций. Параметр PARALLEL_ADAPTIVE_MULTI_USER, если он установлен на TRUE, активирует адаптивный алгоритм, разработанный для повышения производительности в многопользовательском окружении за счет использования параллельного исполнения. Он автоматически ограничивает запрашиваемую степень параллелизма, основываясь на нагрузке в системе на момент запуска запроса. Эффективная степень параллелизма основывается на используемой по молчанию степени параллелизма, или на степени параллелизма для таблицы, или на подсказке, поделенной на используемый коэффициент уменьшения.
Степень параллелизма по умолчанию для каждой таблицы можно установить с помощью фразы parallel команд create table и alter table. Степень параллелизма (degree of parallelism) указывает системе Oracle, сколько серверных процессов параллельных запросов можно использовать для каждой части операции. Например, если степень параллелизма запроса, выполняющего одновременно операции сканирования таблиц и сортировки данных, равна 5, можно использовать одновременно 10 серверных процессов параллельных запросов — 5 для сканирования и 5 для сортировки. При создании индекса можно определить степень параллелизма и для него — с помощью фразы parallel команды create index.
Минимальное количество запускаемых серверных процессов параллельных запросов определяется с помощью параметра инициализации PARALLEL_MIN_SERVERS. В общем случае ему следует присваивать очень небольшое значение (не более 5), если только система не используется активно в любое время суток. В результате Oracle будет неоднократно запускать на сервере новые процессы, но это существенно уменьшит объем памяти, удерживаемый при простаивании серверных процессов параллельных запросов. При высоком значении этого параметра процессы параллельных запросов на сервере будут часто простаивать, удерживая память, которую они приобрели, но они не используют для выполни ния каких-либо функций.
Распараллеливание операций приводит к распределению их обраоот ки по нескольким процессорам, однако эту возможность следует исполь зовать внимательно. Если для большого запроса степень параллельности равна 5, к данным будут обращаться 5 отдельных процессов. При этом мо жет возникнуть конкуренция за диск, на котором эти данные хранятся, что снизит производительность системы. Поэтому нужно применять оП цию параллельных запросов только к тем таблицам, данные которых раС пределены по нескольким физическим устройствам. Не следует приМ^ нять его для всех таблиц, поскольку один запрос может использовать вс доступные серверные процессы параллельных запросов, что сведет нет параллелизм всех остальных транзакций в оазе данных.
Настройка базы данных 305
Эффективное проектирование приложения
В дополнение к вопросам проектирования приложений, которые будут описаны в последующих разделах этой главы, для всех приложений Oracle можно дать несколько общих указаний.
Во-первых, необходимо уменьшить количество запросов данных из базы данных. Для этого можно использовать последовательности, блоки PL/SQL и денормализацию таблиц. Чтобы помочь сократить общее число запросов к базе данных, можно использовать и такие распределенные объекты базы данных, как материализованные представления.
Примечание Даже в умеренной степени неэффективный SQL может оказать воздействие на производительность базы данных, если он выполняется достаточно часто.
Во-вторых, различные пользователи одного приложения должны обращаться к базе данных как можно более единообразно. Такая согласованность доступа повышает вероятность разрешения их запросов с помощью информации, уже имеющейся в SGA. Совместное использование данных распространяется не только на считывание таблиц и строк, но также и на фактически используемые запросы. Если запросы идентичны, проанализированная (грамматически разобранная) версия запроса уже может находиться в разделяемом пуле SQL, что уменьшает количество времени, необходимого для его обработки. Улучшение совместного использования курсора в оптимизаторе повышает вероятность повторного использования команды в разделяемом пуле, но возможность такого повторного использования должна быть заложена при проектировании приложения.
В-третьих, следует ограничить использование динамического SQL. Команды динамического SQL всегда повторно анализируются, даже если идентичный запрос уже имеется в разделяемом пуле SQL. Динамический SQL — это полезная возможность, но не следует использовать ее для большинства обращений приложения к базе данных.
В-четвертых, следует ограничить количество раз, когда пользователи открывают и закрывают сеансы в базе данных. Если приложение многократно открывает сеанс, выполняет всего несколько операций и закрывает его, производительность SQL может оказаться лишь незначительной составляющей общей производительности. Затраты на управление сеансом могут оказаться больше, чем для любого другого шага приложения.
Использование хранимых процедур при разработке приложений повысит вероятность выполнения одного и того же кода несколько раз, что делает особенно выгодной работу с разделяемым пулом SQL. Чтобы избежать компиляции во время выполнения, процедуры, функции и пакеты можно компилировать вручную. При создании процедуры Oracle компилирует ее автоматически. Если позже процедура стала недействительной, аза данных должна перекомпилировать ее перед выполнением. Чтобы избежать компиляции во время работы, можно использовать команду alter procedure:
alter procedure MY_RAISE compile;
306
Главаs
С помощью столбца Text представления DBAJSOURCE можно просмотреть коды SQL всех процедур базы данных. Представление USERJSOURq? содержит все процедуры, принадлежащие пользователю, который выполняет запрос. В этих представлениях также доступны тексты модулей, функций и тел пакетов (с помощью представлений DBAJSOURq? и USER_SOURCE), причем все они обращаются к таблице SYS.SOURCE$.
Два рассмотренных правила проектирования — ограничение числа обращений пользователей и координация их запросов — требуют от разработчика приложений максимально возможного знания используемых данных и путей доступа к ним. По этой причине важно привлекать пользователей к участию в разработке приложения, как и к созданию таблиц. Если пользователи затратят многие часы, рисуя схемы таблиц совместно с разработчиками моделей данных, но очень немного времени будут обсуждать (опять-таки, совместно с разработчиками приложений) пути доступа к ним, то, скорее всего, получившиеся в итоге приложения не будут удовлетворять их запросам. Пути доступа должны обсуждаться как часть процесса моделирования данных.
Настройка SQL
Как и при проектировании приложений, на первый взгляд кажется, что настройка операторов SQL очень далека от обязанностей администратора БД. Тем не менее, администратор должен принимать участие в написании и проверке команд SQL, являющихся частью приложения. Хорошо спроектированное приложение может все-таки столкнуться с проблемами производительности, если используемый в нем код SQL плохо настроен. Даже в хорошо спроектированных базах данных проектирование приложения и проблемы языка SQL*Plus являются причиной большей части проблем с производительностью.
Ключом к настройке SQL является сведение к минимуму пути поиска, выбираемого базой данных для нахождения данных. В большинстве таблиц Oracle с каждой строкой связан идентификатор RowID. Он содержит информацию о физическом расположении строки — файл, где она расположена, блок внутри файла и строка в блоке базы данных.
При выполнении запроса без фразы where база данных, как правило» полностью сканирует таблицу, считывая из нее каждый блок. В этом сл) чае она находит первый блок таблицы и затем последовательно читает все остальные блоки. Для больших таблиц такой процесс может потреоо
вать много времени.
Для ускорения извлечения конкретных строк база данных может пользовать индекс. Индекс приводит логические значения таблицы в ответствие их идентификаторам RowID, которые, в свою очередь, с ветствуют конкретному физическому расположению. Индексы & быть либо уникальными (тогда для каждого его значения уставов только одно соответствие), либо нет. Индексы сохраняют значения . тификаторов RowID только для не пустых (NOT NULL) значений инД сируемых столбцов. „ &
Можно совместно проиндексировать несколько столбцов. Такой деке называется сцепленным (конкатенированным) и применяется, еелй ведущий столбец используется во фразе запроса where. Оптимизатор
Застройка базы данных
307
жет также применять метод skip-scan (метод доступа Oracle, когда данные читаются в порядке их логической связи. — Прим, пер.'), при котором сцепленный индекс используется, даже если его ведущий столбец не включен во фразу where запроса.
Индексы должны быть связаны с необходимым маршрутом доступа к информации. Рассмотрим, например, сцепленный индекс, основанный на трех столбцах. Как показано в следующем листинге, индекс создается для столбцов City, State и Zip в таблице EMPLOYEE:
□ create index CTIY_ST_ZIP_NDX
on EMPLOYEE(City, State, Zip)
tablespace INDEXES;
Если будет выполнен запрос вида:
О select * from EMPLOYEE
where State=’NJ’;
то его ведущий столбец (City) во фразе where не используется. Для выборки строк Oracle может использовать два метода доступа с участием индексов — метод skip-scan или метод полного сканирования индекса. Оптимизатор выберет путь исполнения, основываясь на статистических показателях индекса — его размере, размере таблицы и избирательности (селективности) индекса. Если пользователи часто запускают запросы такого типа, следует изменить порядок следования столбцов индекса, расположив впереди название штата (State), чтобы этот порядок отражал фактический способ его использования.
Важно также, чтобы данные таблицы были упорядочены, насколько это возможно. Если пользователи часто выполняют запросы по диапазону (range queries) — отбирают значения, лежащие в определенном интервале, для упорядоченных данных потребуется считывание меньшего числа блоков данных, что повышает производительность системы. Упорядоченные элементы индекса будут указывать на группу соседних блоков в таблице, а не на блоки, рассеянные по файлу (файлам) данных.
Рассмотрим, например, запрос по диапазону:
О select *
from EMPLOYEE
where Empno between 1 and 100;
Выполнение этого запроса потребует считывания меньшего количества блоков данных, если физические записи таблицы EMPLOYEE упорядочены по столбцу Empno. Чтобы гарантировать правильный порядок строк в таблице, извлеките ее записи в простой неструктурированный файл (или в другую таблицу), отсортируйте их там, удалите старые записи, а затем из этого файла загрузите их снова в таблицу.
Влияние упорядоченности на скорость загрузки
Индексы оказывают влияние как на производительность запросов, так и на производительность загрузки данных. Во время вставок порядок строк Оказывает существенное влияние на производительность загрузки. Даже
308
Гпава в
в насыщенных индексами окружениях правильное упорядочение строк перед вставкой может улучшить производительность загрузки на 50%.
По мере увеличения размера индекса Oracle выделяет для него новые блоки. Если новый элемент индекса добавляется после последнего предыдущего (выходит за пределы имеющихся значений), он будет добавлен к последнему блоку в индексе. Если из-за нового элемента Oracle выходит за пределы имеющегося в этом блоке места, данный элемент будет перемещен в новый блок, а все исходные элементы останутся нетронутыми. Выделение нового блока незначительно повлияет на производительность.
Если вставляемые блоки не упорядочены, новые элементы индекса будут записываться в существующие блоки узлов индексов. Если в узле больше нет места для добавления нового значения, он будет разделен пополам. 50% полей индексов останется в исходном узле, а 50% будет перемещено в новый узел. В результате пострадает производительность во время загрузок (из-за необходимости управления дополнительным пространством) и во время запросов (поскольку индекс содержит больше неиспользуемого места и приходится считывать больше блоков).
Примечание Значительное снижение производительности загрузки происходит, когда индекс увеличивает число своих внутренних уровней. Чтобы узнать число уровней, нужно проанализировать индекс, а затем выбрать значение столбца В level из представления DBAJNDEXES.
Из-за способа, которым Oracle осуществляет внутреннее управление своими индексами, скорость загрузки будет подвергаться воздействию каждый раз, когда будет добавляться новый индекс (поскольку маловероятно, чтобы строки вставлялись с правильно отсортированными данными для нескольких столбцов). Исходя из перспектив скорости загрузки, следует отдавать предпочтение меньшему числу индексов по нескольким столбцам, а не нескольким индексам по одному столбцу.
Дополнительные возможности индексирования
Если данные не слишком селективные, нужно рассмотреть возможность использования битовых индексов (bitmap indexes). Такие индексы наибо лее эффективны при обращениях к большим статическим наборам дан ных, очень немногие из которых различаются между собой (см. глав; 1 /• Можно создать как битовые, так и обычные (B*tree) индексы для одной таблицы, и при обработке запроса Oracle динамически выполнит все не обходимые преобразования индекса. Однако нельзя создать оба инден для одного столбца в таблице (подробнее об использовании битовых дексов см. главу 17).
Примечание Избегайте создания битовых индексов для таблиц, модифицирУ6 мых онлайновыми транзакциями.
Если запросы к двум таблицам часто осуществляются совместно, Д^ повышения производительности запросов эти таблицы можно объеД
Застройка базы данных
309
нить в кластеры, где строки различных таблиц сохраняются в одних и тех же физических блоках данных на основе их логических значений (кластерный ключ).
Запросы, в которых значения столбца сравниваются с конкретным числом (а не с диапазоном значений), называются запросами эквивалентности. В хеш-кластерах строка сохраняется в определенном месте — в зависимости от ее значения в столбце кластерного ключа. При вводе новой строки с помощью значения ее кластерного ключа определяется, в каком блоке ее нужно сохранить. Такая же логика применяется при обработке запросов для быстрого поиска необходимых блоков данных. Хеш-класте-ры предназначены для повышения производительности запросов эквивалентности; при обработке запросов по диапазонам они неэффективны.
Еще одну возможность оптимизации запросов эквивалентности предоставляют так называемые индексы с реверсированным ключом (reverse indexes). Байты такого индекса сохраняются в обратном порядке. В традиционном индексе два последовательных значения всегда находятся рядом друг с другом. В обратном индексе это не так, и, например, числа 2004 и 2005 сохраняются как 4002 и 5002, соответственно. Использование индексов с реверсированным ключом неприемлемо в запросах по диапазонам, но они уменьшают конкуренцию за блоки индекса при выполнении запросов эквивалентности.
Примечание Битовый индекс реверсировать нельзя.
Имеется возможность создавать индексы по ключу-функции. Приводимый ниже запрос не может использовать индекс для столбца Name:
□ select * from EMPLOYEE
where UPPER(Name) = 'JONES’;
но запрос
□ select * from EMPLOYEE
where Name = 'JONES’;
мог бы, потому что он не выполняет функцию над столбцом Name. Теперь, вместо того чтобы создавать индекс для столбца Name, можно создавать индекс для выражения UPPER(Name):
а create index EMP_UPPER_NAME on
EMPLOYEE(UPPER(Name));
Хотя функциональные индексы могут быть полезны, при их создании следует рассмотреть несколько вопросов:
® Можно ли ограничить число функций, применяемых к столбцам? Если да, то можно ли не допустить выполнения над столбцами всех функций?
Достат очно ли места на диске для дополнительных индексов?
310
Гпава 8
При удалении таблицы придется удалять больше индексов (и, следовательно, больше экстентов), чем раньше. Как это повлияет время, необходимое для удаления таблицы?
Индексы по ключу-функции полезны, но создавать их следует не слишком часто. Чем больше индексов создано для таблицы, тем больше времени потребуется для выполнения операций insert, update и delete. Чтобы создать индекс по ключу-функции, необходимо иметь системную привилегию QUERY REWRITE, а в файле параметров инициализации должны быть заданы следующие параметры:
П QUERY_REWRITE_ENABLED-TRUE
QUERY_REWRITE_INTEGRITY=TRUSTED
Текстовые индексы (text indexes) используют текстовые опции Oracle для создания и управления списками слов и их вхождений — примерно так же, как работает индекс в книге. Чаще всего текстовые индексы используются для поддержки приложений, выполняющих поиск частей слов с так называемыми групповыми символами.
Секционированные таблицы могут иметь индексы, диапазоном действия которых являются все разделы (так называемые глобальные индексы), или индексы, поделенные на разделы в соответствии с разделами основной таблицы (так называемые локальные индексы). С точки зрения настройки запросов локальные индексы могут оказаться предпочтительнее, так как они содержат меньшее количество элементов, чем глобальные индексы.
Генерация планов выполнения
Чтобы узнать, какой путь доступа база данных будет использовать для выполнения запроса, применяется команда explain plan. Она оценивает путь и помещает результаты своего выполнения в таблицу базы данных PLAN_TABLE. Пример использования команды explain plan показан в следующем листинге:
□ explain plan
for
select *
from BOOKSHELF
where Title like ‘M%’;
Первая строка этой команды говорит базе данных, что она должна о 'Ь яснить план выполнения запроса, не выполняя этот запрос фактически-По желанию в этом операторе можно использовать фразу set Statei ie ID, которая помечает оператор explain plan в таблице PLAN_TABLE. еле ключевого слова for приводится сам анализируемый запрос.
В схеме учетной записи, выполняющей эту команду, должна иметь в наличии таблица PLAN_TABLE. Oracle предоставляет необходимую ДД создания этой таблицы команду create table. Файл utlxplan.sql обычно И ходится в подкаталоге /rdbms/admin домашнего каталога программно1, обеспечения Oracle. С помощью этого сценария пользователи могут соз дать таблицу в своих схемах.
Застройка базы данных 311
Примечание Каждый раз после апгрейда Oracle следует удалить и заново создать таблицу планов, поскольку сценарии апгрейда могут добавлять к таблицам новые столбцы.
Задайте запрос к таблице плана, используя процедуру DBMS_XPLAN:
□ select * from table(DBMS_XPLAN.DISPLAY);
Этот запрос вернет информацию о типах операций, которые база данных должна осуществить для выполнения запроса. Выходные данные в иерархическом виде отображают шаги выполнения запроса и иллюстрируют отношения между этими шагами. Например, может иметься опирающийся на индексы шаг, который имеет своим родителем шаг TABLE ACCESS BY INDEX ROWID, указывающий, что индексный шаг выполняется первым и что возвращенные из индекса значения RowID используются для выборки из таблицы конкретных строк.
Для автоматической генерации выходных данных команды explain plan и трассировочной информации каждого запроса можно использовать команду set autotrace on языка SQL*Plus. Генерируемые при использовании автотрассировки выходные данные не будут отображаться до завершения запроса, хотя выходные данные команды explain plan генерируются без запуска этой команды. Для активизации вывода результатов автотрассировки таблица PLAN_TABLE должна быть создана либо в схеме, где используется утилита автотрассировки, либо в схеме SYSTEM, доступ к которой осуществляется с помощью этой утилиты. Сценарий plustrce.sql, размещенный в подкаталоге sqlplus/admin домашнего каталога программного обеспечения Oracle, также должен быть выполнен от имени пользователя SYS, прежде чем можно будет выполнить команду set autotrace on. У пользователей перед выполнением команды set autotrace on должна быть активизирована роль PLUSTRACE.
Примечание Чтобы показать результаты выполнение команды explain plan, нужно использовать команду set autotrace on trace explain.
Если используются опции параллельных запросов или делаются запросы к удаленным базам данных, то в дополнительном разделе выходных данных set autotrace on будет показан текст запросов, выполняемых процессами сервера параллельных запросов, или запросов, выполняемых в удаленной базе данных.
Для отключения опции автотрассировки используется команда set autotrace off.
В следующем листинге показано, как включается автотрассировка и генерируется план выполнения:
set autotrace on trace explain
select *
from BOOKSHELF
where Title like M%’;
312
Гпава 8
Execution Plan
О SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=2 Bytes-80)
1 О TABLE ACCESS (BY INDEX ROWID) OF ‘BOOKSHELF’ (TABLE) (Cost =3 Card=2 Bytes=80)
2 1 INDEX (RANGE SCAN) OF ‘SYS_C004834’ (INDEX (UNIQUE))
(Cost=1 Card=2)
Чтобы понять план выполнения, нужно прочесть порядок операций в иерархии в обратном порядке (изнутри наружу), пока вы не дойдете до группы операций одного уровня отступа, а затем прочесть эту группу сверху вниз; следовательно, вы будете читать порядок операций изнутри наружу. Первой выполняемой операцией будет сканирование индекса по диапазону, вслед за ней последует доступ к таблице; операция SELECT STATEMENT выводит выходные данные. У каждой операции имеется значение идентификатора (ID, первый столбец) и значение идентификатора родительской операции (второй столбец; для самой верхней по уровню операции это значение равно пробелу). В более сложных планах выполнения для определения порядка выполнения операций может понадобиться использовать значения идентификатора родительской операции.
Этот план показывает, что возвращаемые пользователю данные получаются в результате выполнения операции TABLE ACCESS BY INDEX ROWID. Значения RowID (идентификаторов строк) поступают из операции сканирования индекса по диапазону для уникального индекса.
Каждому шагу приписывается определенная “стоимость”, которая является кумулятивной и отражает стоимость самого шага и всех его дочерних шагов. Эти значения стоимости можно использовать для идентифи-
кации шагов, которые вносят наибольший вклад в общую стоимость запроса, чтобы затем приложить к этим шагам определенные усилия по настройке.
Анализируя выходные данные команды explain plan, нужно убедиться, что в запросе использованы наиболее селективные (т.е. наиболее близкие к уникальным) индексы. В противном случае может получиться так, что база данных будет осуществлять необязательные считывания информации для выполнения запроса. Полное обсуждение вопросов оптимизации команд SQL выходит за рамки данной книги, но следует позабо титься о том, чтобы в наиболее требовательных к ресурсам операторах SQL были использованы наиболее селективные возможные индексы.
Обычно ориентированные на обработку транзакций приложения (на пример, многопользовательские системы, используемые для ввода даН^ ных), определяют производительность на основе времени, необходимо го для возвращения первой строки запроса. Для таких приложении следует сосредоточить усилия по оптимизации на использовании инД
сов для уменьшения времени реакции базы данных на запрос.
Если приложение ориентировано на обработку пакетов (с больший транзакциями и отчетами), основное внимание необходимо удел!1 уменьшению времени, необходимого для завершения транзакции, а Н
тельности транзакции может потребоваться полное сканирование табл!1
бработку пакетов (с большим11
,____________________,_____________ _ t [, а яе
для возвращения ее первой строки. Для повышения общей произвол1^
Настройка базы данных
313
цы, а не доступ по индексу, и в результате может повыситься общая производительность приложения.
Если приложение распределено по нескольким базам данных, внимание следует уделить сокращению числа использований в запросах связей баз данных. При каждом обращении к удаленной базе данных за доступ к ней приходится расплачиваться. Даже если “цена” однократного обращения невелика, повтор таких обращений тысячи раз может существенно повысить нагрузку на производительность приложения (подробнее о настройке распределенных баз данных см. ниже в данной главе).
Настройка использования памяти
В главе 9 будет показано, как использовать имеющийся в Oracle набор инструментов STATSPACK для получения резюме по статистике базы данных за указанный период. Утилиты пакета STATSPACK и запросы к таблицам словаря данных можно также использовать для определения областей, которым выделено недостаточное количество системных ресурсов в области выделения памяти для базы данных. Начиная с Oracle 10g, можно использовать набор инструментов Automatic Workload Repository (AWR) для сбора статистических данных и управления ими (как это будет описано в этой главе далее).
Для управления кэшем буфера блоков данных и разделяемым пулом SQL используется алгоритм LRU (least recently used — дольше всего неиспользуемые данные). Для хранения значений резервируется заранее выделенная область памяти. Когда она заполняется, дольше всего неиспользуемые данные удаляются о ттуда и записываются на диск. Область памяти адекватных размеров содержит данные, обращения к которым осуществляются чаще всего; доступ к остальным данным требует их физического считывания с диска.
Запросы, выполняющие логические и физические операции чтения в базе данных, можно просмотреть с помощью представления V$SQL. В нем сообщается совокупное число таких операций, выполненных для каждого запроса в разделяемом пуле SQL, а также число выполнений каждого запроса. Сценарий, приведенный в следующем листинге, представляет текст SQL для запросов в разделяемом пуле SQL, причем сначала перечисляются наиболее требовательные к ресурсам ввода/вывода запросы. Запрос также показывает число операций логического чтения (обращения к буферу) за одно выполнение:
О select Buffer_Gets,
Disk_Reads,
Executions,
Buffer_Gets/Executions B_E,
SQL_Text
from V$SQL
order by Disk_Reads desc;
Если разделяемый пул SQL был сброшен на диск, выполненные до этого запросы перестают быть доступными с помощью V$SQL. Однако влияние этих запросов может ощущаться и дальше при условии, что пользователи еще зарегистрированы. Представление V$SESS_IO записывает
314
Гпава 8
кумулятивные операции логического и физического чтения, выполненные в течение сеанса каждого пользователя. Чтобы узнать коэффициент попаданий (hit ratio) каждого сеанса, можно задать запрос к V$SESS_IO:
□ select SESS.Username,
SESS_IO.Block_Gets,
SESS_IO.Consistent_Gets,
SESS_IO.Physical-Reads,
round(100*(SESS_IO.Consistent_Gets
+ SESS-IO.Block_Gets-SESS_IO.Physical-Reads)/ (decode(SESS_IO.Consistent_Gets,0,1,
SESS_IO.Consistent_Gets+SESS_IO.Block_Gets)),2) session_hit_ratio
from V$SESS_IO sess_io, V$SESSION sess
where SESS.Sid = SESS_IO.Sid
and SESS.Username is not null
order by Username;
Чтобы увидеть объекты, блоки которых в настоящее время находятся в кэше буфера блоков данных, обратитесь к таблице Х$ВН в схеме SYS, как показано в следующем запросе. В приведенном листинге объекты SYS и SYSTEM исключены из выходных данных, чтобы администратор мог сосредоточиться на таблицах и индексах приложения, находящихся в SGA:
□ select Object_Name, Object_Type, count (*) Num_Buff
from X$BH a, SYS.DBA.OBJECTS b
where A.Obj = B.Object_Id
and Owner not in (‘SYS’, ‘SYSTEM’) group by Object-Name, Object_Type;
Примечание Аналогичные данные можно увидеть, задав запрос к столбцам Name и Kind представления V$CACHE.
В кэше буферов блоков данных есть несколько областей кэша:
Кэш DEFAULT Это стандартный кэш для объектов, использующих применяемый по умолчанию размер блока базы данных.
Кэш KEEP Этот кэш выделен для объектов, которые желатель но постоянно хранить в оперативной памяти. Как правило, эта оо ласть используется для хранения маленьких таблиц с небольшим числом транзакций.
Кэш RECYCLE Этот кэш выделяется для объектов, которь^ нужно быстро вытеснить из памяти. Подобно кэшу KEEP, к RECYCLE изолирует в памяти объекты так, чтобы они не оказьш ли влияния на нормальное функционирование кэша DEFAULT.
Кэши для различных размеров блоков Oracle поддерживав? для базы данных несколько размеров блоков данных; для каЖД°г размера блока данных (естественно, кроме используемого по у&° чанию блока данных) необходимо завес! и собственный кэш.
s
растроика базы данных
315
При работе с областями SGA — буферами блоков данных, словарным кэшем и разделяемым пулом SQL — особое внимание следует уделять совместному использованию данных пользователями. Каждая из этих областей должна быть достаточно большой, чтобы вместить информацию, чаще всего запрашиваемую из базы данных. В частности, разделяемый пул должен быть достаточно большим, чтобы вместить проанализированные версии наиболее распространенных запросов. Если области памяти SGA определены адекватно, они позволяют резко повысить производительность индивидуальных запросов и базы данных в целом.
Размеры буферных пулов KEEP и RECYCLE не приводят к уменьшению доступного пространства в кэше буферов блоков данных. Для того чтобы таблица использовала один из новых буферных пулов, нужно указать во фразе storage для таблицы имя этого пула в параметре bufferpool. Например, если требуется, чтобы таблица быстро удалялась из памяти, ее следует приписать к пулу RECYCLE. Используемый по умолчанию пул получил название DEFAULT, так что можно использовать команду alter table для последующего перенаправления таблицы в этот пул.
Параметр инициализации LARGE_POOL_SIZE можно использовать для задания размера выделяемой динамической памяти большого пула в байтах. Выделяемая динамическая память большого пула используется в системах разделяемых серверов для памяти сеансов, при параллельном выполнении операций для буферов сообщений и в качестве буферов ввода/ вывода для процессов резервного копирования. По умолчанию большой пул не создается.
Начиная с Oracle 10g, можно использовать область Automatic Shared Memory Management (ASMM — область автоматического управления разделяемой памятью). Для активации ASMM нужно установить ненулевое значение параметра инициализации базы данных SGA_TARGET. После того как SGA-TARGET будет установлен равным желательному размеру SGA (то есть, равным суммарному размеру всех кэшей), можно установить значения всех остальных связанных с кэшем параметров (DB_CACHE_ SIZE, SHARED_POOL_SIZE, JAVA_POOL_SIZE и LARGE_POOL_SIZE) равными 0; если для любого из этих пулов будет задано отличное от 0 значение, оно будет рассматриваться как нижняя граница для алгоритма автоматической настройки. Остановите и снова запустите базу данных, чтобы сделанные изменения могли вступить в силу. После этих действий база данных будет активно управлять размером раз чичных кэшей. В любой момент можно провести мониторинг размера этих кэшей с помощью динамического представления производительности V$SGASTAT.
По мере изменения рабочей нагрузки для базы данных, последняя будет изменять размеры кэшей, чтобы те отражали потребности приложения. Например, если в базе данных сосуществует интенсивная пакетная обработка (и, соответственно, рабочая нагрузка от нее) в ночные часы и более интенсивная нагрузка от онлайновых транзакций в дневное время, то база данных может изменять размеры кэшей при изменении характера нагрузки. Такие изменения будут выполняться автоматически без участия АБД. Если для какого-то пула в файле параметров инициализации будет указан его размер, Oracle использует его в качестве минимального размера пула.
316
Гпава 8
Примечание АБД могут создать пулы KEEP и RECYCLE в буферном кэше. На размер этих пулов не влияет изменение размеров динамических пулов, и они не являются частью буферного пула DEFAULT.
Находясь в OEM, можно проверить, активировано ли автоматическое управление разделяемой памятью. Для этого достаточно щелкнуть на опции Memory Parameters (параметры памяти); после этого кнопка Automatic Shared Memory Management может быть установлена на одно из двух значений — “Enabled” или “Disabled”.
Кроме того, можно селективно “прикрепить” пакеты к определенному участку в разделяемом пуле. Прикрепление пакетов к памяти сразу после запуска базы данных повышает вероятность того, что в памяти будут доступны достаточно большие разделы непрерывного свободного пространства. Как показано в следующем листинге, процедура KEEP пакета DBMS SHARED__POOL указывает на пакеты, которые должны быть прикреплены в разделяемом пуле:
□ execute DBMS_SHARED_POOL.КЕЕР(‘APPOWNER.ADD_CLIENT’,1Р’);
Прикрепление пакетов в большей степени связано с вопросами управления приложениями, чем с вопросами их настройки, но оно также может иметь влияние и на производительность. Если вы сумеете избежать динамического управления фрагментированными областями памяти, вы тем самым уменьшите объем работы, которую должен выполнить Oracle при управлении разделяемым пулом.
Определение размера SGA
Для обеспечения возможности автоматического управления кэшами нужно задать параметр инициализации SGA_TARGET равным размеру SGA.
Если будет выбрано ручное управление кэшами, можно задать значение параметра инициализации SGA_MAX_SIZE равным размеру SGA. Затем можно задать размеры индивидуальных кэшей; во время работы оазы данных их можно будет динамически изменять, применяя команду alter system.
Параметр
SGA_MAX_SIZE
SHARED_POOL_SIZE
DB_BLOCK_SIZE
DB_CACHE_SIZE
DB_flK_CASHE_S!ZE
Описание
Максимальный размер, до которого может расти SGA
Размер разделяемого пула
Используемый по умолчанию размер блока базы данных
Размер кэша, задаваемый в байтах
Если использовать в одной базе данных несколько размеров бло ков данных, необходимо задать значение параметра DB_CACHE-SIZE и как минимум одно значение DB_nK_CACHE_S!ZE. НапримI Р^ если стандартный размер блока базы данных равен 4 Кбайт, моЖ также задать кэш для табличного пространства размером 8 КбаИ с помощью параметра DB_8K_CACHE_SIZE.
Настройка базы данных
317
Например, можно задать:
□ SGA_MAX_SIZE-5OOM
SHARED_P00L_SIZE=80M
DB_BL0CK_SIZE=8192
DB_CACHE_SIZE=160M
DB_4K_BL0CK_SIZE=4M
При таком задании параметров в SGA 4 Мбайт будут доступны для данных, запрошенных из объектов табличного пространства с размером блоков 4 Кбайт. Объекты, использующие стандартный размер блоков в 8 Кбайт, будут использовать кэш в 160 Мбайт. При открытой базе данных можно изменить значения параметров QHARED_POOL_SIZE и DB_CACHE_SIZE с помощью команды alter system.
Параметр SGA_TARGET является динамическим, и его можно изменить через Database Control или посредством команды alter system.
Можно увеличить SGA TARGET до значения SGA_MAX_SIZE. Уменьшать этот параметр можно до тех пор, пока любой из автоматически настраиваемых компонентов не достигнет своего минимального размера — будь то минимум, указанный пользователем, или минимум, определяемый внутренним образом. Оба эти параметра могут быть использованы для настройки SGA.
Использование оптимизатора по стоимости
С каждой новой версией программного обеспечения Oracle добавляет в свой оптимизатор новые возможности и совершенствует уже имеющиеся. Эффективное использование стоимостной оптимизации требует регулярного анализа таблиц и индексов приложения. Частота анализа объектов зависит от скорости их изменений. Необходимо повторно анализировать объекты после завершения работы каждого большого набора пакетных транзакций. При работе с приложениями OLTP это желается по контроли- -руемому по времени графику (например, еженедельно или по ночам).
Статистические показатели для объектов собираются путем выполнения процедур из пакета DBMS_STATS. При анализе таблицы автоматически анализируются и связанные с ней индексы. Можно проанализировать схему (с помощью процедуры GATHER_SCHEMA_STATS) или конкретную таблицу (с помощью процедуры GATHER_TABLE_STATS). Кроме того, можно анализировать только индексируемые столбцы, ускоряя тем самым процесс анализа. Как правило, всякий раз при анализе таблицы необходимо анализировать и ее индексы. В следующем листинге анализируется схема PRACTICE:
° execute DBMS_STATS.GATHER_SCHEMA_STATS('PRACTICE’, ‘COMPUTE’);
Для просмотра статистических данных по таблицам и индексам можно использовать представления DBA_ TABLES, DBA_TAB__COL_STATISTICS и DBAJNDEXES. Некоторые статистические данные уровня столбцов можно по-прежнему получить посредством DBA_TAB_COLUMNS, но это сделано исключительно для обеспечения обратной совместимости. Статистические данные для столбцов секционированных таблиц можно найти в представлении DBA_PART_COL_STATISTICS.
318
Гпава 8
При выполнении команды из этого листинга все принадлежащие схеме PRACTICE объекты будут проанализированы с использованием опции compute statistics. Можно также выбрать оценивание статистических показателей на основании конкретной процентной доли строк таблицы.
Последствия применения опции compute statistics
В примерах предыдущего раздела для сбора статистики об объектах использовалась опция compute statistics. Кроме того, в Oracle существует опция estimate statistics, которая основывает статистические показатели объекта на случайным образом выбранной порции (части) данных. Если выбран именно этот режим, нужно проанализировать настолько большую часть таблицы, насколько возможно. Можно определить процент анализируемых строк — обычно бывает вполне достаточно проанализировать 20% строк.
Для анализа данных может потребоваться много места па диске для пространства сортировки. Поскольку для анализа может потребоваться выполнить полный просмотр таблицы, необходимо непосредственно перед выполнением анализа изменить установки сеанса. По окончании анализа нужно либо завершить сеанс, либо восстановить действовавшие до анализа установки сеанса. Изменению подлежат следующие установки сеанса: SORT_AREA_SIZE и DB_FILE_MULTIBLOCK_READ_COUNT. Чем больше размер области сортировки, тем меньше вероятность того, что для сегментов сортировки потребуется использовать временное табличное пространство. Чем выше значение счетчика многоблочного чтения, тем большее число блоков может быть считано за одну операцию физического считывания (это количество ограничено требованиями операционной системы компьютера). Для увеличения этих значений для сеанса используется команда alter session.
Настройка доступа к данным
Даже если таблицы должным образом конфигурированы и индексированы, производительность может страдать из-за событий ожидания, вы званных доступом к файлам.
Вообще говоря, следует избегать помещения файлов Oracle на RA1 системы с распределенной четностью типа RAID 5. Накладные расходы, связанные с записью в подобные файловые системы, обычно привод^ к возникновению “узких мест” производительности при увеличении пользования системы, особенно, для последовательно записанных Ф лов, например, для оперативных журнальных файлов. Предпочтитель использовать RAID 0+1, чтобы одновременно поддерживать зеркалир вание и расщепление данных и не допускать возникновения узких n производительности.
Локально управляемые табличные пространства
Локально управляемые табличные пространен. можно использов^ для управления экстентами в самих табличных пространствах. В та# 1 случае локально управляемое табличное пространство управляет саМ°
Застройка базы данных
319
бой (точнее, собственным пространством), поддерживая в каждом файле данных битовую карту для свободных и занятых блоков или наборов блоков в файле данных. Каждый раз, когда экстент выделяется или освобождается для повторного использования, база данных обновляет битовую карту, чтобы отразить новый статус.
Если используются локально управляемые табличные пространства, то при создании экстента словарь данных не обновляется, а операция отката не генерируется. Локально управляемые табличные пространства автоматически отслеживают смежные свободные места, поэтому не требуется объединять смежные экстенты. В локально управляемых табличных пространствах все экстенты могут иметь одинаковый размер, или же система определяет размер экстентов автоматически.
Для осуществления локального управления пространством во фразе extent management команды create tablespace задается опция local. Ниже приводится пример команды create tablespace, в которой объявляется локально управляемое пространство:
□ create tablespace CODES. TABLES
datafile ‘/u01/oracle/VLDB/codes_tables.dbf’
size 10M
extent management local uniform size 256K;
Предположим, что размер блока для базы данных, в которой создается это табличное пространство, равен 8 Кбайт. Табличное пространство в этом примере создается с управлением экстентами, объявляемым как local, и с единым размером в 256 Кбайт. Каждый бит в битовой карте описывает 32 блока (256/8). Если опустить фразу uniform size, по умолчанию будет задано autoallocate. Размер (size) по умолчанию для параметра uniform равен 1 Мбайт.
Примечание Если в команде create tablespace задан параметр local, то нельзя специфицировать фразы default storage, minextent или temporary. Если для задания табличного пространства используется команда create temporary tablespace, необходимо задавать extent management local.
Начиная с Огас1е9г, по умолчанию табличные пространства создаются как локально управляемые, так что фраза extent management local является необязательной.
Примечание Если табличное пространство SYSTEM создано локально управляемым, все остальные табличные пространства в базе данных также могут быть только локально управляемыми.
Идентификация расщепленных строк
При создании сегмента данных определяется значение параметра pctfree. Оно показывает, сколько места в каждом блоке данных должно оставаться свободным. Ci об дное пространство используется, если со
320
Гпава в
держащиеся в блоке данных строки увеличиваются в размерах в результа-те выполнения операций обновления (update).
Если обновленная строка больше не помещается в один блок данных она может быть перенесена в другой блок или сцеплена с ним (расщеплена), Если длина сохраняемой строки превышает размер блока Oracle, расщепление вызывается автоматически и от него нельзя избавиться.
Расщепление влияет на производительность, поскольку в этом случае система Oracle вынуждена искать одну логическую строку в нескольких физических местах. Избавляясь от избыточного расщепления, вы уменьшаете количество операций физического чтения, необходимых для возврата данных из файла.
Устанавливая при создании сегмента данных правильное значение параметра pctfree, можно избежать расщепления. Значение по умолчанию (оно равняется 10) должно быть увеличено, если приложение часто выполняет обновления пустых (NULL) данных, превращая их в не пустые (non-NULL) данные, или если приходится часто обновлять длинные текстовые значения.
Команда analyze позволяет собрать статистические показатели использования различных объектов базы данных. Оптимизатор, основанный на стоимости, может использовать эти статистические показатели для определения наилучшего пути выполнения. Команда analyze позволяет также находить и записывать расщепленные строки таблиц. Ее синтаксис таков:
□ analyze table TABLE_NAME list chained rows into CHAINED_ROWS;
Данная команда записывает результаты своей работы в таблицу CHAINEDJROWS локальной схемы. Создающий эту таблицу оператор SQL находится в файле utlchain.sql подкаталога /rdbms/admin каталога с программным обеспечением Oracle. Следующий запрос выбирает наиболее значимые столбцы из таблицы CHAINED_ROWS:
□ select
Owner_Name: /*Владелец сегмента данных*/
Table_Name, /*Имя таблицы с расщепленными строками*/
Cluster_Name, /*Имя кластера, если таблица кластеризована*/
Head.RowID /*Идентификатор Rowid первой части строки*/
from CHAINED_ROWS;
В результате этого запроса получаются идентификаторы RowID всех расщепленных строк, и таким образом становится известно, сколь строк в таблице расщеплено. Если расщепленные строки в таблице пре лируют, таблицу следует перестроить, применив более высокие значе параметра pctfree. 0
Влияние расщепления строк на производительность таблицы увидеть, задав запрос к представлению V$SYSSTAT. Его элемент для тистического показателя table fetch continued row (выборка расще ной строки) будет увеличиваться при каждом извлечении данных из р щепленной строки. Этот показатель будет возрастать также, к данные извлекаются из так называемой сцепленной строки (sf аП row) — строки, которая расщепляется, поскольку ее длина больше ра ✓ ра блока. С большой вероятностью такие сцепленные строки будут в лицах, содержащих данные типов LONG, BLOB, CLOB и NCLOB.
Настройка базы данных
321
Помимо расщепления строк, Oracle будет время от времени перемещать их. Если размер строки превышает доступное в блоке место, она может быть вставлена в другой блок. Процесс перемещения строки из одного блока в другой называется миграцией строк (row migration), а сама перемещенная строка — мигрирующей. В ходе этого процесса Oracle динамически управляет местом в нескольких блоках, а также обращается к списку свободных блоков. Мигрирующая строка не является расщепленной, но влияет на производительность транзакции.
Увеличение размера блока Oracle
Эффект от увеличения размера блоков просто поражает. Удвоение размера блока для базы данных может повысить производительность операций, интенсивно использующих запросы, вплоть до 50%.
Выгода в производительности достигается за счет некоторых затрат. Поскольку в блоке базы данных будет содержаться больше строк, возрастет вероятность конкуренции на уровне блока во время выполнения команд обработки данных. Чтобы избежать конкуренции, нужно увеличить значения настроек для freelists и initrans на уровне таблицы и индекса. Как правило, установка freelists, превышающая 4, не даст дополнительных преимуществ. Настройка initrans должна отражать предполагаемое число параллельно выполняющихся транзакций в блоке.
Примечание Теперь Oracle автоматически позволяет иметь до 255 одновременно выполняющихся транзакций по обновлению данных для одного блока в зависимости от доступного в блоке свободного пространства.
При создании табличного пространства размер блока базы данных для табличного пространства можно специфицировать явно; по умолчанию табличное пространство будет использовать размер блока базы данных, ранее специфицированный в параметре инициализации DB_ BLOCK_SIZE. Если используется явно специфицированный размер блока базы данных, то для таких блоков потребуется создать собственный кэш. Например, если размер блока базы данных равен 8 Кбайт и понадобилось создать табличное пространство с размером блока базы данных 4 Кбайт, необходимо сначала присвоить значение DB_4K_CACHE_SIZE.
Для увеличения размера блока базы данных нужно перестроить ее всю и удалить все ее старые файлы. На их месте можно создать новые файлы того же размера, но более эффективно управляемые базой данных. Такое повышение производительности связано со способом работы Oracle с информацией заголовка блока. Для данных используется больше места, что повышает возможность обращения к одному и тому же блоку данных сразу нескольких пользователей. Удвоение размера блока Oracle практически не влияет на его заголовок; это значит, что в процентном отношении Для заголовка расходуется меньше места.
Для установки размера блока базы данных следует перед созданием новой базы данных модифицировать параметр инициализации DB BLOCK_SIZE.
322
Гпава 8
Использование индекс-таблиц
Индекс-таблица (index-organized table, ЮТ) является индексом, в кото ром сохраняется вся строка, а не только значения ключей для нее. Логическим идентификатором строки здесь является не RowID, а первичный ключ строки. Строки в таблицах ЮТ не имеют идентификаторов RowID.
Строки индекс-таблицы сортируются по значениям своих первичных ключей, значит, производительность любого запроса по диапазону, основанного на первичном ключе, повышается, поскольку строки расположены рядом друг с другом (о действиях, необходимых для упорядочения данных в нормальных таблицах, см. выше в данной главе). Производительность запросов эквивалентности, основанных на первичном ключе, также повышается, так как все данные таблицы содержатся в индексе. В традиционной конфигурации “таблица/индекс” обращение, основанное на индексе, требует доступа сначала к индексу, а затем к таблице. В таблицах ЮТ обращение происходит прямо к таблице, поскольку сопровождающего индекса нет.
Тем не менее, в результате обращения только к одному индексу, а не к обычной комбинации “индекс/таблица” выигрыш в производительности может быть минимальным, так как любой основанный на индексе доступ к данным должен быть быстрым. Для дальнейшего повышения производительности в таблицах ЮТ предлагаются следующие дополнительные возможности:
Область переполнения Если установить при создании I Т параметр pctthreshold, данные первичного ключа можно сохранять отдельно от данных строки. Если данные строки превышают порог доступного в блоке места, они динамически перемещаются в область переполнения. Эту область можно расположить в другом табличном пространстве, что увеличивает возможность распределять ввод/вывод, ассоциированный с таблицей.
Вторичные индексы В таблицах ЮТ можно создавать вторичные индексы. В качестве логических идентификаторов RowID используются первичные ключи для каждой строки.
Уменьшенные требования к хранению В традиционных ком бинациях “таблица/индекс” одни и те же значения ключа сохраня_ ются в двух местах. В таблицах ЮТ они сохраняются только однаж ды, что уменьшает требования к месту на диске.
Для создания таблиц ЮТ следует воспользоваться фразой organization index команды create table. При создании ЮТ нужно определить: Рв1 ный ключ. В ЮТ можно удалять столбцы и помечать их как неактив! с помощью фразы set unused команды alter table.
Вопросы настройки для индекс-таблиц
Как и индексы, ЮТ могут со временем с«н= »=
Застройка базы данных
323
table. В следующем примере перестраиваются таблица EMPLOYEEJOT и се область переполнения:
П alter table EMPLOYEE JOT move tablespace DATA overflow tablespace DATA_OVERFLOW;
He следует сохранять в ЮТ длинные строки данных. Вообще, всегда нужно стараться избегать использования таблиц этого типа, если данные занимают больше 75% от размера блока базы данных. Если, например, размер блока БД равен 4 Кбайт, а строка превышает 3 Кбайт, следует рассмотреть возможность использования не ЮТ, а обычных таблиц или индексов. Чем длиннее строка, тем больше транзакций выполняется по отношению к ЮТ и тем чаще эти таблицы придется перестраивать.
Примечание В ЮТ нельзя использовать типы данных ’ ONG, но можно использовать LOB.
Индексы оказывают воздействие на скорость загрузки данных. Для достижения наилучших результатов индекс первичного ключа иидекс-таблицы должен быть загружен последовательными значениями, чтобы минимизировать расходы на управление индексами.
Настройка манипулирования данными
Несколько задач манипулирования данными, обычно связываемые с манипулированием большими объемами данных, также могут потребовать участия администратора БД. При загрузке и удалении больших объемов данных у администратора есть несколько возможностей, которые будут описаны ниже.
Массовые вставки: использование в SQL*Loader опции загрузки в прямом режиме
При работе в обычном режиме (Conventional Path) утилита SQL*Loader читает из файла записи, генерирует команды insert и передает их ядру Oracle. Затем Oracle находит в свободных блоках таблицы места для этих записей и обновляет все связанные с ними индексы.
При загрузке в прямом режиме (Direct Path) утилита SQL*Loader создает отформатированные блоки данных и записывает их непосредственно в файлы данных. Это требует периодической сверки с БД для получения новых мест для блоков данных, но не требует новых операций ввода/вывода в ее ядро. В результате процесс загрузки данных происходит значительно быстрее, чем в режиме Conventional Path.
Если таблица проиндексирована, во время загрузки индексы переводятся в режим DIRECT PATH. По завершении загрузки новые ключи (значения столбцов индексов) будут отсортированы и объединены в индексе с существующими ключами. Для работы с этим временным набором ключей в процессе загрузки создается сегмент временных индексов, по крайней мере, такого же размера, что и самый большой индекс табл ины
324
Гпава 8
Пространственные требования можно уменьшить, если заранее отсорти-ровать индекс и воспользоваться фразой SORTED INDEXES управляющего файла SQL*Loader.
Для уменьшения объема, динамически выделяемого во время загрузку дискового пространства, должен быть уже создан сегмент данных, в который загружается информация, и необходимое для него место должно быть уже выделено. Следует также заранее отсортировать данные в столбцах самого большого индекса таблицы. Сортировка данных и сохранение индекса в таблице в ходе загрузки в режиме Direct Path, как правило, приводит к более высокой производительности, чем удаление индексов до начала загрузки и воссоздание их после ее завершения.
Чтобы можно было воспользоваться преимуществами этого режима таблица не должна быть кластеризованной и над ней не должно выполняться никаких других активных транзакций. В процессе загрузки можно оставить включенными только ограничения NOT NULL, UNIQUE и PRIMARY KEY; после завершения загрузки можно автоматически повторно активизировать ограничения CHECK и FOREIGN KEY. Для этого в управляющем файле утилиты SQL*Loader нужно использовать фразу:
□ REENABLE DISABLED—CONSTRAINTS
Единственным исключением в этом процессе повторной активизации является то, что табличные триггеры вставки при повторной активизации не срабатывают для каждой новой строки таблицы. Команды, которые должны были выполнить триггеры этого типа, нужно выполнить
вручную в отдельном процессе.
Режим прямой загрузки утилиты SQL*Loader позволяет существенно повысить производительность по сравнению с обычным режимом загрузки (Conventional Path), поскольку при загрузке данных в таблицы Oracle удается избежать обработки команд SQL, работы с кэшем буфера и необязательных операций считывания блоков данных. Режим параллельной загрузки данных (Parallel Data Loading) этой утилиты обеспечивает работ}' нескольких процессов загрузки в одну и ту же таблицу, используя свооод-ные ресурсы системы и за счет этого обеспечивая меньшее время загруз ки. При наличии достаточных ресурсов процессора и ввода/вывода это
позволяет существенно ускорить загрузку.
Для использования режима параллельной загрузки с помощью чевого слова parallel нужно запустить несколько сеансов оцн (в противном случае SQL*Loader наложит на таблицу эксклюзивную кировку). Каждый сеанс является независимым и требует своего УПР ляющего файла. В следующем листинге отражены три отдельные за^Р^т ки в режиме Direct Path; все они в командной параметр PARALLEL=TRUE:
строке использу Ф
□ sqlload USERID=ME/PASS CONTROL=PART1.CTL DIRECT=TRUE PARALLEL=TRUE sqlload USERID=ME/PASS C0NTR0L=PART2.CTL DIRECT=TRUE PARALLEL=TRU sqlload USERID=ME/PASS C0NTR0L=PART3.CTL DIRECT=TRUE PARALLEL=TRUE
Каждый сеанс по умолчанию создает свои собственные файлы лов, ошибок и отвергнутых записей (partl.log, part2.log, part ’
ЬизН nart2.bad и т.д.). Поскольку загрузку в одну и ту же таблиц А
Застройка базы данных 325
ных выполняют несколько сеансов, для режима параллельной загрузки разрешен только параметр APPEND. Параметры REPLACE, TRUNCATE и INSERT утилиты SQL*Loader не разрешены. Если перед началом загрузки необходимо удалить данные таблицы, это нужно сделать вручную (с помощью команд delete или truncate). При работе в режиме параллельной загрузки с помощью утилиты SQL*Loader нельзя удалять записи автоматически.
Примечание При работе в режиме параллельной загрузки сеанс SQL*Loader не поддерживает индексы. Перед началом процесса загрузки необходимо удалить в таблице все индексы и отключить все ее ограничения PRIMARY KEY и UNIQUE. После завершения загрузки индексы таблицы можно создать заново.
При последовательной загрузке в режиме Direct Path Loading (PARALLEL= FALSE) утилита SQL*Loader загружает данные в экстенты таблицы. Если до окончания загрузки происходит сбой, данные, внесенные до сбоя, все же останутся в таблице. В ходе параллельной загрузки данных каждый процесс загрузки создает временные сегменты, которые впоследствии объединяются с таблицей. Если процесс параллельной загрузки преждевременно закончится аварийно, то временные сегменты не будут слиты с таблицей, в которую ведется загрузка. Если слияния временных сегментов с загружаемой таблицей не произошло, то никаких загружаемых данных в таблице не будет (не будет выполнена операция commit).
С помощью параметра FILE утилиты SQL*Loader каждый сеанс загрузки данных можно направить в свой собственный файл данных. Это позволит сбалансировать нагрузку ввода/вывода. Загрузка данных связана с очень интенсивным использованием ввода/вывода и должна распределяться по нескольким дискам в целях ее распараллеливания, что существенно повышает производительность по сравнению с последовательной загрузкой.
После завершения параллельной загрузки каждый сеанс может попытаться повторно активизировать ограничения таблицы. Пока хотя бы один сеанс продолжает работу, все попытки повторно активизировать ограничения будут неудачными. Только после успешного завершения последнего сеанса загрузки следует еще раз попытаться повторно активизировать ограничения таблицы, и эта попытка будет успешной. После завершения загрузки необходимо проверить статус ограничений. Если загружаемая таблица имеет ограничения PRIMARY KEY и UNIQUE, перед активизацией ограничений можно в параллельном режиме создать ассоциированные с ней индексы.
Пересылки больших массивов данных — использование внешних таблиц
Можно запрашивать данные внешних файлов, находящихся вне базы дан-НЬ1Х» используя для этой цели объекты, которые называются внешними ъшблицами (external tables). Структура внешней таблицы определяется Фразой organization external команды create table. Синтаксис этой фра-зы весьма похож на синтаксис управляющего файла утилиты SQL*Loader.
326
Гпава 8
Нельзя выполнять манипулирование строками внешней таблицы Кроме того, ее нельзя проиндексировать — каждой доступ к такой таблц-це приводит к полному просмотру таблицы (т. е. к полному просмотру файла на уровне операционной системы). В результате производительность запросов к внешним таблицам оказывается хуже, чем у таблиц, хра. нящихся внутри базы данных. Однако внешние таблицы предлагают два потенциальных преимущества для систем, в которых приходится загружать большие объемы данных:
Поскольку данные не хранятся внутри базы данных, они записываются только один раз (вне базы данных, а не в базе данных и вне нее), экономя тем самым дисковое пространство.
Так как данные никогда не загружаются в базу данных, исключается время, требующееся для загрузки данных.
Внешние таблицы нельзя индексировать, поэтому они могут стать наиболее полезными для операций, в которых пакетные программы должны получать доступ к большим объемам данных. Например, во многих системах, реализующих хранилища данных, есть так называемая промежуточная область хранения (staging area), где данные загружаются во временные таблицы перед тем, как строки будут вставлены в таблицы, к которым будут впоследствии делать запросы пользователи. Вместо загрузки данных в такие временные таблицы можно с помощью внешних таблиц непосредственно обращаться к файлам операционной системы, экономя при этом время и дисковое пространство.
С архитектурной точки зрения внешние таблицы позволяют сосредоточиться на той части контента базы данных, которая наиболее часто используется пользователями базы данных, — небольшие кодовые таблицы, итоговые и транзакционные таблицы, — оставив большие наборы данных за пределами базы данных. В любой момент можно заменить файлы, реализующие внешние таблицы, не обременяя при этом базу данных никакими накладными расходами.
Массовые вставки: распространенные ловушки и успешные трюки
J1! С*'
Если данные вводятся не из простого неструктурированного файда, пользование утилиты SQL*Loader перестает быть приемлемым PeUieebIf ем. Например, при перемещении данных из одной таблицы в другу1^ скорее всего, не захотите записывать их в файл, а потом считывать °°г но в базу данных—проще сделать это, не выходя в операционную си
При перемещении данных из одной таблицы в другую есть несК°оцес-распространенных методов, повышающих производительность пр са миграции данных:
Настройка структур (удаление индексов и триггеров)
Отключение ограничений на время миграции данных
Использование подсказок и опций для повышения производи1 ности транзакции
Застройка базы данных
327
Первый метод — настройка структур — предполагает отключение триггеров и индексов таблицы, в которую осуществляется загрузка данных. Если, например, для целевой таблицы есть триггер уровня строки, он будет выполняться при вводе в таблицу каждой строки. По возможности следует отключать триггеры перед загрузкой данных. Если триггер необходимо выполнить для каждой вводимой строки, это можно сделать сразу для всех строк после завершения ввода, а не для каждой строки по отдельности во время процесса ее вставки. Такая общая операция потребует меньше времени, чем повторяющееся выполнение триггеров. Нужно убедиться в том, что эта операция будет выполняться для всех строк, не обработанных триггером.
Кроме триггеров, до начала загрузки данных следует отключить и индексы целевой таблицы. Если их оставить, Oracle будет динамически работать с ними по мере ввода каждой строки. Поэтому их нужно удалить до начала загрузки и воссоздать после ее завершения.
Примечание Отключение индексов и триггеров решает большинство проблем с производительностью, связанных с миграцией больших объемов данных между таблицами.
Помимо отключения индексов, нужно рассмотреть возможность отключения ограничений. Если исходные данные уже находятся в какой-либо таблице базы данных, можно проверить их на соответствие ограничениям (таким, как внешние ключи и CHECK) до начала загрузки в целевую таблицу. После завершения загрузки ограничения можно будет активизировать повторно.
Если описанные действия не повышают производительность, как было задумано, нужно воспользоваться опциями Oracle, появившимися для настройки миграции данных. К числу таких опций относятся:
Подсказка append для команд insert Как и при режиме Direct Path Loader, подсказка APPEND загружает в таблицу блоки данных, но начинает это с маркера уровня максимального заполнения таблицы (high water mark). Поэтому использование данной подсказки может повлиять на расход свободного места на диске.
Опция nologging При выполнении команды create table as select эта опция позволяет отказаться от записи в оперативные журналы. Средство распараллеливания Режим параллельных запросов (Parallel Query Option) использует для выполнения одной задачи несколько процессов. Для команды create table as select можно параллельно и создавать таблицу, и выполнять запрос. При работе со средством распараллеливания необходимо также применять параметр nologging, иначе параллельные операции должны будут ждать своей очереди на последовательную запись в оперативные файлы журналов базы данных.
Перед использованием любой из этих опций сначала нужно исследовать структуру целевых таблиц, что позволит избежать общих проблем, указанных выше.
328
Гпава 8
Для вызова обработки команд ввода данных в отдельных массивах а не во всей группе данных сразу можно использовать логику языков про граммирования. Так, ввод массивов поддерживают языки программно вания COBOL и С; это уменьшает размер транзакций, необходимых ддя обработки больших объемов данных.
Массовые удаления: команда усечения (truncate)
Иногда возникает необходимость одновременно удалить из таблицы все записи. Если в ходе этого процесса возникают ошибки, появляется сообщение, что размер сегмента отката слишком мал, хотя на самом деле слишком велики транзакции.
Вторая проблема возникает после удаления записей. Несмотря на то, что сегмент больше не содержит их, он по-прежнему занимает все выделенное для них место на диске. Таким образом, удаление записей не освобождает ни одного байта выделенного дискового пространства.
Обе эти проблемы решаются с помощью команды truncate. Она относится к языку DDL, а не DML, так что нельзя произвести ее откат. После использования команды truncate все записи таблицы удаляются и ни один ее триггер delete не активизируется. Однако при этом сохраняются все зависимые от таблицы объекты — предоставление привилегий, индексы и ограничения.
Команда truncate — это самый быстрый способ удаления больших объемов данных. Поскольку она удаляет из таблицы все записи, возможно, придется изменить структуру приложения, чтобы защищенные и не защищенные от удаления записи находились в разных таблицах. Командой truncate можно также удалить один раздел таблицы, не затрагивая остальных (см. главу 17).
Вот пример команды truncate для таблицы:
□ truncate table EMPLOYEE drop storage;
В этом примере удаляются записи таблицы EMPLOYEE и демонстрируется одна из мощных возможностей команды truncate. Конструкция drop storage позволяет отменить выделение дискового пространства для всех дополнительных экстентов таблицы (это предлагается по умоляя нию). Таким образом, не удаляя саму таблицу, можно удалить все ее стр0 ки и освободить все занимаемое ей дисковое пространство, кроме места, выделенного для первоначального экстента.
Указанная команда работает и для кластеров. В этом случае с помо параметра reuse storage место, выделенное для сегмента (к котор применяется эта команда), остается пустым:
П truncate cluster EMP_DEPT reuse storage;
При выполнении этой команды все записи кластера EMP_DEPT буД) немедленно удалены.
Для того чтобы отсечь раздел, нужно знать его имя. В следующем ПР мере с помощью команды alter table отсекается раздел PARTS таоЛИ EMPLOYEE:
^астр°йка базы данных
329
□ alter table EMPLOYEE
truncate partition PART3 drop storage;
Остальные разделы таблицы EMPLOYEE остаются незатронутыми применением данной команды (подробнее о создании разделов и управлении ими см. главу 17).
Кроме того, можно написать программу на языке PL/SQL, которая с помощью динамического SQL разделит большие операции удаления на несколько более мелких транзакций.
Использование разделов
Разделы позволяют изолировать данные физически. Например, данные о транзакциях одного месяца можно сохранять в отдельном разделе таблицы ORDERS. При выполнении для таблицы операций загрузки или удаления больших объемов данных можно оптимизировать разделы таким образом, чтобы настроить операции манипулирования данными. Например, можно:
Провести усечение раздела и его индексов, не влияя на остальную часть таблицы
Удалить раздел с помощью фразы drop partition команды alter table
Удалить локальный индекс раздела
Переключить раздел в режим nologging, что ослабит влияние больших транзакций
Что касается производительности, то основное преимущество разделов связано с возможностью управлять ими независимо от остальной части таблицы. Так, возможность провести усечение раздела позволяет удалить большое количество данных таблицы (но не все), не генерируя информацию для журналов. В краткосрочном аспекте от этого повышения производительности выигрывает администратор БД. В долгосрочном же аспекте — в выигрыше остается все предприятие (подробнее о реализации разделов и подразделов см. главу 17).
Для значительного уменьшения влияния процессов загрузки данных на Доступность системы можно использовать опцию exchange partition, ачать нужно с создания пустой таблицы, у которой есть те же самые столбцы, что и у секционированной таблицы, загрузить данные в новую таолицу, а затем проанализировать ее. Для новой таблицы надо создать индексы, соответствующие индексам секционированной таблицы. После ^вершения этих шагов нужно изменить (alter) секционированную табли-ИУ, используя фразу exchange partition, чтобы обменять пустой раздел с Новой, только что заполненной таблицей. Ко всем загруженным данным доступ будет обеспечен как к секционированной таблице. При выполнении этого шага на доступность системы будет оказано лишь небольшое Влияние, так как это операция DDL.
330
Г.пава s
Настройка физического хранения
Физический ввод/вывод в базе данных должен быть распределен равно-мерно по как можно большему числу устройств. Стандартное решение этой проблемы называется моделью конфигурации SAME (что означает Stripe And Mirror Everything—расщепление и зеркалирование всех данных). Основными ограничениями, которые необходимо преодолеть, являются пределы пропускной способности ввода/вывода дисков, так что распределение потребностей во вводе/выводе по различным дискам позволяет воспользоваться всеми преимуществами суммарной пропускной способности многих устройств. Рассредоточение информации улучшает пропускную способность, что может повысить производительность; зеркалирование обеспечивает поддержку в случае выхода диска из строя.
Использование “чистых” дисков
В большинстве вариантов операционной системы UNIX доступны так называемые “чистые” устройства (raw devices — устройства (диски) без файловой системы. — Прим. пер.). При их использовании Oracle обходится без буферного кэша UNIX и исключается дополнительный расход ресурсов, связанный с файловой системой. Если приложение интенсивно работает с вводом/выводом, это может привести к повышению производительности на 20% по сравнению с традиционными файловыми системами. Реализованные за последнее время усовершенствования файловых систем в значительной степени сократили эту разницу в производительности.
“Чистыми” устройствами нельзя управлять с помощью тех же команд, что и файловыми системами. Так, для резервного копирования отдельных файлов нельзя применять команду tar — вместо этого используется команда dd. Эта команда является значительно менее гибкой и ограничивает возможности восстановления информации.
Примечание Файлы Oracle не следует помещать на те же физические устройства, что и файлы, не относящиеся к Oracle, в особенности если используются ^истые” устройства. Смешивание активной файловой системы UNIX и активных чи' тых” устройств Oracle приведет к проблемам с производительностью операм ввода/вывода.
Большинство операционных систем, которые поддерживают тые” устройства, также обеспечивают слой логического управления ми, позволяющий администраторам применять команды ФаИ^°пре' системы для “чистых” устройств. Такой подход позволяет сочетать имущества управления системой с преимуществами производитель “чистых” устройств. Если планируется использовать “чистые Устг ва, для упрощения управления системой следует использовать инстр) тальное средство управления логическими томами.
---------------------------------------------' gaiH Примечание Начиная с Oracle 10ij, для управления областью хранен^ базы данных можно использовать Automatic Storage Management — среДУ а тического управления хранением данных.
^стройка базы данных
331
Снижение сетевого трафика
По мере того как приложения и использующие их базы данных становятся все более и более распределенными, сеть, обеспечивающая взаимодействие серверов, все больше становится узким местом в процессе доставки данных пользователю. Поскольку администраторы БД, как правило, имеют небольшой контроль над сетью, важно максимально задействовать все возможности самой базы данных для уменьшения числа сетевых пакетов, требующихся для доставки данных. Снижение сетевого трафика уменьшает зависимость от сети и, следовательно, предотвращает возникновение потенциальной причины проблем с производительностью.
Тиражирование данных
Информацией, содержащейся в удаленных базах данных, можно манипулировать и запрашивать ее оттуда. Однако постоянно обмениваться большими объемами информации между базами данных нежелательно. Для уменьшения объема передаваемой по сети информации следует рассмотреть различные возможности тиражирования данных.
В полностью распределенном окружении каждый элемент данных физически существует только в одном месте. При обращениях к данным доступ к ним из удаленной базы данных осуществляется через связи баз данных. Такой строгий подход (когда каждый элемент данных содержится только в одном месте) напоминает реализацию приложения в третьей нормальной форме, и его не смогут поддерживать большинство промышленно эксплуатируемых приложений. Модификация таблиц приложений, приводящая к повышению производительности извлечения данных, предполагает их денормализацию. При этом накапливаются избыточные данные, назначение которых состоит в упрощении путей доступа пользователей к данным.
В распределенном окружении эта цель достигается путем тиражирования данных. Вместо того чтобы заставить приложение путешествовать по сети, пытаясь разрешить запросы пользователей, избранные данные с удаленных серверов тиражируются на локальный сервер. Для этого существует много разнообразных способов (см. ниже).
Тиражированные данные становятся устаревшими сразу же после своего создания. По этой причине тиражирование данных, продиктованное соображениями производительности, будет наиболее эффективным, если источник данных изменяется не слишком часто или когда бизнес-процессы могут поддерживать использование старых данных.
Использование материализованных представлений/моментальных снимков для тиражирования данных
Распределенные возможности Oracle предоставляют способы управле-Ния тиражирования данных в базе данных. При этом так называемые ма-^риализованные представления (materialized views) позволяют тиражировать данные из одного главного источника в несколько целевых систем. Кроме того, Oracle предлагает инструменты для обновления данных и обновления целевых объектов через определенные интервалы времени.
332
Гпава в
Материализованные представления могут быть предназначены толь. ко для чтения или быть обновляемыми. Вопросы управления моментальными снимками рассматриваются в главе 18, а в данном разделе показаны только аспекты материализованных представлений, связанные с настройкой производительности.
Перед разработкой материализованного представления для тиражирования следует создать связь баз данных с БД источника. В следующем примере создается приватная связь базы данных HRJLINK; при этом используется имя службы LOC:
□ create database link HR_LINK
connect to HR identified by PUFFINSTUFF using ‘loc’;
Как показано в этом примере, команда create database link имеет несколько параметров:
Имя связи (в данном случае это HRJLINK)
Учетная запись для соединения с ней
Имя службы удаленной базы данных (как оно записано в файле tnsnames.ora для сервера). В данном случае имя службы — LOC.
Материализованные представления автоматизируют процессы тиражирования и обновления данных. При создании материализованных представлений создается интервал обновления (refresh interval) для планирования обновлений тиражированных данных. Можно предотвратить локальные обновления и использовать их на базе транзакций. Обновления на базе транзакций, доступные для многих типов материализованных представлений, посылают с главной (master) базы данных только те строки, которые были изменены для материализованных представлении. Такая возможность (см. ниже в данной главе) может значительно повысить производительность обновлений данных.
Синтаксис, используемый для создания материализованного пред ставления на локальном сервере, представлен в следующем примере, где ему дается имя LOCALJEMP и определяются параметры его хранения-Назначаются базовый запрос и интервал обновления. В данном случае на териализованному представлению дается задание немедленно получ данные с основного сервера, а затем повторить эту операцию чер 7 дней (SysDate+7):
□ create materialized view LOCALJEMP
pctfree 5
tablespace data_2
storage (initial 100K next TOOK pctincrease 0) refresh fast
start with SysDate
next SysDate+7
as select * from EMPLOYEE@HR LINK;
Фраза refresh fast просит базу данных использовать журнал лизованных представлений для обновления локального материал ного представления. Возможность использования материализова
Застройка базы данных 333
представлений для обновления этих журналов доступна только в тех случаях, когда базовый запрос для материализованных представлений достаточно прост, так что Oracle может определить, какая строка в материализованном представлении будет изменена при изменении строки в исходных таблицах.
Когда используется журнал материализованного представления, в целевую базу данных направляются только изменения, сделанные в главной таблице. При работе со сложными материализованными представлениями вместо фразы refresh fast нужно использовать refresh complete. При этом в ходе полного обновления обновленные данные полностью заменяют существующие данные в базовых для материализованных представлений таблицах.
Журналы материализованных представлений создаются в главной базе данных с помощью команды create materialized view log, например:
□ create materialized view log on EMPLOYEE tablespace DATA
storage (initial 10K next 10K pctincrease 0);
Журнал материализованного представления всегда создается в той же схеме, что и главная таблица.
С помощью простых материализованных представлений и их журналов можно уменьшить объем сетевого трафика, вовлеченного в процесс управления тиражируемыми данными. Поскольку благодаря журналам по сети переправляются только измененные данные, для простых материализованных представлений требуется меньше сетевых ресурсов, чем для сложных представлений. Это особенно верно для больших статических главных таблиц (master tables). Если основная таблица не является статической, объем транзакций, направляемых с помощью журнала материализованных представлений, может быть не меньше, чем объем таблицы, посылаемой при полном обновлении (подробнее о возможностях обновления для материализованных представлений см. главу 18).
Безотносительно к выбранной опции обновления, базовые таблицы материализованных представлений должны быть проиндексированы, чтобы оптимизировать запросы к материализованным представлениям. С точки зрения производительности нашей целью является представить пользователям требующиеся данные в нужном формате настолько быстро, насколько это вообще возможно. Путем создания материализованных представлений для удаленных данных при выполнении запроса удается избежать обхода связей баз данных. При создании материализованных представлений для локальных данных можно помочь пользователям из-ежать неоднократного агрегирования больших объемов представляемых им данных путем создания предварительно агрегированных данных, отвечающих на наиболее часто задаваемые ими запросы.
Использование удаленных вызовов процедур
При работе с процедурами в среде распределенной базы данных стоит следующий выбор, создать либо локальную процедуру, которая ссылается На удаленные таблицы, либо удаленную процедуру, вызываемую локальным приложением.
334
Гпав$q
Нахождение правильного расположения для этой процедуры зависит от распределения данных и способа их использования. Основное внимание следует уделить минимизации объема данных, пересылаемых по сети для разрешения запроса. Процедура должна находиться в базе данных которая содержит большую часть данных, используемых при операциях с участием этой процедуры.
Рассмотрим, например, такую процедуру:
□ create procedure MY_RAISE (My_Emp_No IN NUMBER, Raise IN NUMBER) as begin
update EMPLOYEE@HR_.LINK
set Salary = Salary+Raise.
where Empno = My_Emp_No;
end;
В данном случае процедура обращается только к одной таблице (EMPLOYEE) на удаленном узле (на что указывает связь баз данных HR_ LINK). Чтобы уменьшить объем передаваемых по сети данных, нужно переместить эту процедуру в удаленную БД, идентифицируемую связью баз данных, и удалить ссылку на эту связь из фразы from данной процедуры. Затем с помощью связи баз данных можно вызывать процедуру из локальной ЁД:
□ execute MY_RAISE@HR_LINK(1234,2000);
В данном случае в процедуру передаются два параметра: My_Emp_No задается равным 1234, a Raise — 2000. Для обращения к процедуре используется связь баз данных, которая указывает ей, где искать процедуру.
Преимущества настройки, связанные с удаленными вызовами процедур, заключаются в том, что вся относящаяся к процедуре обработка выполняется в той базе данных, где находятся сами данные. Обращение к удаленной процедуре позволяет минимизировать объем сетевого трафика, необходимого для довершения обработки этой процедуры.
Чтобы обеспечить прозрачность местонахождения данных, можно создать локальный синоним, указывающий на удаленную процедуру- В синониме нужно определить имя связи баз данных, чтобы запросы пользе вателя автоматически направлялись в удаленную БД.
□ create synonym MY.RAISE for MY_RAISE@HR_LINK;
Теперь пользователь может ввести команду:
□ execute MY_RAISE(1234,2000);
Эта команда выполнит удаленную процедуру, определенную синониме MY_RAISE.
Использование пакета STATSPACK и автоматически управляемого репозитория рабочей нагрузки
Использование пакета Statspack для сбора статистических данных о данных и создания отчета об этих показателях будет показано в главе Пакет Statpack полезен, если приходится иметь дело с несколькими
Настройка базы данных
335
сиями Oracle. Начиная с Oracle 10g, автоматически управляемый репозиторий рабочей нагрузки (AWR) предлагает усовершенствования концепции пакета STATSPACK.
Подобно STATSPACK, AWR собирает и сопровождает статистические данные о производительности для целей обнаружения проблем и самонастройки. Можно генерировать отчеты по данным AWR и получать к ним доступ через представления. Можно создавать отчет об активности текущего сеанса, равно как и об итоговых статистических показателях системы и об использовании SQL.
В AWR собирается системная статистика на почасовой основе (путем получения “моментальных снимков” базы данных), после чего данные сохраняются в таблицах репозитория. Как и в случае со STATSPACK, требования к дисковому пространству для репозитория AWR будут возрастать при росте периода сохранения архивных данных или при сокращении интервала между созданием последовательных моментальных снимков. По умолчанию в репозитории сохраняются данные за последние семь дней. Можно ознакомиться с моментальными копиями, хранящимися в репозитории AWR, используя для этого представление DBA_HIST_ SNAPSHOT.
Для активации AWR нужно установить параметр инициализации STATISTICS_LEVEL на TYPICAL или ALL. Если этот параметр будет установлен на BASIC, можно будет делать моментальные снимки данных AWR вручную, но они не будут такими исчерпывающими, как выполняемые AWR в автоматическом режиме.
Управление мгновенными снимками
Для создания вручную моментального снимка используется процедура CREATE-SNAPSHOT из пакета DBMS_WORKLOAD_REPOSITORY:
□ execute DBMS_WORKLOAD__REPOSITORY.CREATE_SNAPSHOT ();
Для изменения установок моментального снимка нужно использовать процедуру MODIFY_SNAPSHOT_SETTINGS. В приведенном ниже примере для текущей базы данных величина интервала изменяется до 30 мин:
□ execute DBMS_WORKLOAD_REPOSITORY.MODIFY SNAPSHOT-SETTINGS ( interval => 30);
Для удаления моментальных снимков в заданном интервале используется процедура DROP_SNAPSHOT_RANGE с заданными начальным и конечным значением удаляемых идентификаторов моментальных снимков:
° execute DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE
( low_snap_id => 1, high_snap-id => 10);
Управление опорными планами
Можно выделить набор моментальных снимков как опорный план производительности системы. Данные из базовых планов должны быть сохранены для последующего сравнения с моментальными снимками. Для специфицирования начального и конечного моментальных снимков для опорного плана нужно использовать процедуру CREATE_BASELINE:
336
Гпава 8
□ execute DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE (start_snap_id => 1, end_snap_id => 10, baseline_name => Monday baseline’);
Когда создается опорный план, Oracle назначает ему идентификатор; увидеть последние опорные планы можно, используя для этого представление DBAJHISTJBASELINE. Специфицированные моментальные снимки для начала и окончания опорного плана будут поддерживаться до тех пор, пока он не будет удален. Для удаления опорного плана следует использовать процедуру DROP JBASELINE:
□ execute DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => ‘Monday baseline’, cascade => FALSE);
Если параметр CASCADE процедуры DROP_BASELINE будет установлен на TRUE, при удалении опорного плана будут удалены и связанные с ним моментальные копии.
Данные AWR можно просмотреть с помощью OEM или через перечислявшиеся ранее в этом разделе представления словаря данных. К числу дополнительных представлений, поддерживающих AWR, относятся V$ACTIVE_SESSION_HISTORY (выборка данных производится каждую секунду), DBA_HIST_SQL_PLAN (планы выполнения) и DBA_HIST_WR_ CONTROL (для установок AWR).
Г енерация отчетов AWR
Отчеты из AWR можно генерировать либо через OEM, либо с помощью предлагаемых сценариев отчетов. Сценарий awrrpt.sql генерирует отчет на основании различия статистических показателей из начального и конечного моментальных снимков для указанных базы данных и экземпляра. Второй отчет, awrrpti.sql, выводит отчет, основанный на начальном и конечном моментальных снимках для конкретных базы данных и экземпляра.
Оба этих отчета размещаются в подкаталоге /rdbms/admin домашнего каталога с программным обеспечением Oracle. При запуске отчета (от имени любой учетной записи с правами АБД) предлагается выбрать тип отчета (HTML или текстовый), диапазон дат, для которого будут перечисляться моментальные снимки, идентификаторы начального и ко нечного моментальных снимков и имя выходного файла.
Выполнение отчетов автоматического диагностического монитора базы данных
Вместо того чтобы вручную запускать отчеты по таблице AWR, можно нс пользовать автоматический диагностический монитор базы дани (Automatic Database Diagnostic Monitor—ADDM). Поскольку он основыв ется на данных AWR, для работы ADDM требуется, чтобы параметр STATISTICSJLEVEL был установлен (либо на TYPICAL, либо на ALL, было рекомендовано ранее). Обратиться к ADDM можно из раздел Performance Analysis (анализ производительности) OEM. Кроме того» можно запустить отчет ADDM вручную.
Застройка базы данных
337
Для запуска ADDM для набора моментальных снимков нужно использовать сценарий addmrpt.sql, который можно найти в подкаталоге /rdbms/admin домашнего каталога с программным обеспечением Oracle.
—----------— ----------------—_——------------------------------
Примечание Для выполнения этого отчета необходимо иметь системную привилегию ADVISOR.
Находясь в SQL*Plus, выполните сценарий addmrpt.sql. Вам будет предложено указать начальный и конечный идентификаторы моментальных снимков, используемых для анализа, и имя выходного файла.
Для просмотра данных ADDM можно использовать OEM или “консультантские” представления словаря данных. К их числу относятся представления DBA_ADVISOR_TASKS (существующие задания), DBA_ADVISOR_ LOG (статус и прогресс заданий), DBA_ADVISOR_RECOMMENDATIONS (завершенные диагностические задания и рекомендации) и DBA_ ADVISORJFINDINGS. После этого можно реализовать рекомендации, сделанные по результатам работы ADDM.
Решения по настройке
В данной главе не были охвачены все потенциальные решения по настройке. Однако, при работе с методами и инструментами, описанными здесь, можно придерживаться определенного подхода. Прежде чем затратить время и ресурсы на реализацию новой возможности, стабилизируйте свое окружение и архитектуру—сервер, базу данных и приложение. В стабильном окружении можно быстро добиться двух целей:
1. Успешно воспроизвести проблемы производительности
2. Успешно изолировать источник этих проблем
Для достижения этих целей понадобится среда тестирования, позволяющая выполнить тесты производительности. Успешно определив и изолировав проблему, можно перейти к действиям по настройке, описанным выше. Обычно подход к настройке должен отражать порядок разделов этой главы:
1. Оценка проекта приложения
2. Настройка SQL
3. Настройка использования памяти
4. Настройка хранения данных?
5. Настройка манипулирования данными
6. Настройка физического и логического хранения
7. Настройка сетевого трафика
В зависимости от природы приложения может быть выбран другой порядок действий или объединены некоторые шаги.
338
Гпава 8
Если нельзя изменить ни проект приложения, ни команды SQL, мо^-но настроить память и используемые приложением дисковые области Изменив эти настройки, изучите еще раз проект приложения и команды SQL и убедитесь, что сделанные изменения не повлияют отрицательно ца само приложение. Это особенно важно, если вы собираетесь использовать методы тиражирования данных, поскольку своевременность этих данных может вызвать проблемы для бизнес-процесса, обслуживаемого приложением.
ПРИМЕНЕНИЕ ПАКЕТА STATSPACK
Для мониторинга производительности базы данных можно применять утилиту STATSPACK.
Начиная с Oracle 10g, для сбора и анализа статистических показателей можно использовать автоматический репозиторий рабочих нагрузок (Automatic Workload Repository). Утилита STATSPACK также предлагает гибкие возможности для анализа статистических показателей базы данных путем создания моментальных снимков статистических показателей базы данных в разные моменты времени и генерации отчетов, основываясь на различиях в них.
Инсталляция STATSPACK
Утилита STATSPACK должна быть инсталлирована в каждой базе данных, подлежащей мониторингу. Сценарий инсталляции spcreate.sql находится в подкаталоге /rdbms/admin каталога программного обеспечения Oracle. Этот сценарий создает пользователя PERFSTAT и ряд объектов в схеме с тем же именем.
Примечание Под первоначальное создание объектов схемы PERFSTAT следует выделять минимум 100 Мбайт.
Для запуска сценария spcreate.sql нужно перейти из своего каталога в каталог ORACLEJHOME/rdbms/admin и зарегистрироваться в SQL*Plus в учетной записи с привилегией SYSDBA.
П SQL> connect system/manager as SYSDBA
SQL> @spcreate
Во время процесса инсталляции будет предложено ввести пароль для пользователя PERFSTAT и табличное пространство по умолчанию для этого же пользователя (список имеющихся табличных пространств будет выведен на экран вместе с приглашением на ввод). Вас также попросят задать временное табличное пространство для этого пользователя. После выделения для учетной записи PERFSTAT требуемых табличных про
340
Гпава д
странств (по умолчанию и временного) она будет создана, а сценарий инсталляции будет зарегистрирован как PERFSTAT и продолжит создание требуемых объектов. Если в заданном пространстве по умолчанию не хватает места для создания объектов PERFSTAT, сценарий выдаст сообще-ние об ошибке.
Примечание Хотя вы запускаете сценарий инсталляции, будучи зарегистрированным как пользователь с привилегией SYSDBA, по завершении этого сценария вы окажетесь зарегистрированным как пользователь PERFSTAT.
Если позднее потребуется удалить пользователя PERFSTAT, можно выполнить сценарий spdusr.sql, находящийся в каталоге ORACLE^ HOME/rdbms/admin.
Безопасность учетной записи PERFSTAT
Учетная запись PERFSTAT создается с паролем по умолчанию, специфицированным во время инсталляции STATSPACK. После завершения про
цесса инсталляции можно сменить пароль.
Учетной записи PERFSTAT предоставляются роль SELECT_ CATALOG_ROLE и доступ SELECT к большому количеству представлений V$ словаря данных вместе с несколькими системными привилегиями (CREATE/ALTER SESSION, CREATE TABLE, CREATE/DROP PUBLIC SYNONYM, CREAE SEQUENCE и CREATE PROCEDURE). Любой пользователь, имеющий возможность получить доступ к учетной записи
PERFSTAT, может производить выборку из всех словарных представлений. Например, этот пользователь может сделать из V$SESSION запрос ко всем пользовательским именам учетных записей из DBA_USERS, ко всем владельцам сегментов из DBA_SEGMENTS и ко всем, кто в настоя-
щее время зарегистрирован в сеансах. Если оставить учетную запись PERFSTAT незащищенной, она может стать источником бреши в системе защиты, что позволит вторгающимся просматривать словарь данных
и выбирать в нем цели для последующих вторжений.
Помимо привилегий, получаемых во время процесса инсталляции, учетная запись PERFSTAT получит также любые привилегии, которые были предоставлены группе PUBLIC. Если вместо ролей для привилегии приложения используются назначения PUBLIC, необходимо защитить учетную запись PERFSTAT. Можно заблокировать учетные записи базь данных и разблокировать их при необходимости (подробнее оо это см. главу 10).
После установки
После завершения процесса установки учетная запись PERFSTAT буД владеть таблицами, индексами, последовательностями и пакетами. Пак с именем STATSPACK будет использоваться для управления процесс0 сбора статистических показателей, а также данными в таблицах. Тао-Л цы сбора, имена которых начинаются со STAT$ \ будут иметь столбе
Применение пакета STATSPACK
341
базирующийся на определениях представления V$. Например, столбцы STATS$WAITSTAT являются столбцами, найденными в V$WAITSTAT с тремя добавленными в верхней части столбцами идентификации:
□ desc stats$waitstat
Name Null? Type
SNAP_ID NOT NULL NUMBER(6)
DBID NOT NULL NUMBER
INSTANCE-NUMBER NOT NULL NUMBER
CLASS NOT NULL VARCHAR2(18)
WAIT.COUNT NUMBER
TIME NUMBER
Столбцы Class, Wait_Count и Time основаны на столбцах Class, Count и Time из V$WAITSTAT. Пакет STATSPACK добавил три столбца идентификации:
SNAP JD Идентификационный номер для набора данных. Каждый набор
называется моментальным снимком, и ему присваивается целочисленное значение.
DBID Числовой идентификатор для базы данных.
INSTANCE_NUMBER Числовой идентификатор для экземпляра, для установок Real Application Clusters.
Каждый собранный набор информации получает новое значение Snap_ID, согласованное во всех таблицах сборов. При выполнении статистических отчетов, поддерживаемых STATSPACK, вам будет показываться список имеющихся моментальных снимков.
бор статистических показателей
Каждый набор собранной информации называется моментальным снимком. Моментальные снимки собранной статистики являются набором со-оранных в определенный момент времени статистических показателей, который становится доступным благодаря представлениям V$ и получают значения Snap_ID, идентифицирующие конкретные моментальные копии. Можно генерировать отчеты об изменениях статистических показателей в промежутке между двумя моментальными снимками.
Примечание Как и в отчетах UTLBSTAT/UTLESTAT, отчет STATSPACK будет достоверен, только если в период между оцениваемыми моментальными снимками база данных не закрывалась и не запускалась повторно.
в промежутке между моментальными снимками STATSPACK не выполняет никакой обработки и не ложится дополнительным бременем на производительность системы. Влияние STATSPACK па производительность
342
Гпава 9
проявляется только в моменты создания моментальных снимков и гене-рирования отчетов по изменениям статистических показателей за время между двумя моментальными снимками.
Примечание Убедитесь, что перед сбором статистических данных параметр инициализации базы данных TIMED_STATISTICS задан как TRUE.
Чтобы сгенерировать моментальный снимок статистических данных, нужно выполнить процедуру SNAP из пакета STATSPACK, как показано в следующем листинге. Для выполнения этой процедуры необходимо зарегистрироваться как пользователь PERFSTAT.
□ execute STATSPACK.SNAP;
PL/SQL procedure successfully completed. (Процедура PL/SQL успешно завершена.)
Во время выполнения процедуры SNAP Oracle заполняет таблицы SNAP$ текущими статистическими показателями. Затем можно обратиться непосредственно к этим таблицам или же использовать стандартный отчет STATSPACK (чтобы просмотреть изменения в статистических данных между моментальными снимками).
Есть две причины для создания моментальных копий:
Для оценки производительности во время определенных тестов системы. Для этих тестов можно выполнить процедуру SNAP вручную (как показано в предыдуще?' примере).
Для оценки изменений в производительности за продолжительный период времени. Для установления базового уровня производительности системы можно генерировать моментальные снимки статистических показателей на плановой основе. Для этих моментальных снимков следует составить график выполнения процедуры SNAP посредством имеющегося в Oracle внутреннего планировщика DBMSJOB или посредством планировщика операционной системы. Для составления графика выполнения моментальных снимков можно использовать сценарий spauto.sql из каталога $ORACLE_HOME/rdbms/admin.
Для моментальных снимков, связанных с определенными тестами, можно повысить уровень набора, что позволит собирать больше стаги стических показателей. Каждый моментальный снимок имеет стоимость, выражаемую в показателях использования пространства и производи телыюсти запроса. Старайтесь не генерировать по несколько ть1С^е строк статистических данных в каждом моментальном снимке, если вы собираетесь их использовать. т
Для поддержки разных уровней наборов STATSnACK предоставля^ параметр уровня (level). По умолчанию значение level задается равным Прежде чем изменять значение level, нужно выполнить несколько моме1^ тальных снимков и оценить сгенерированные отчеты. Значение level И умолчанию соответствует большинству отчетов. Другие значения при#0 дятся в следующей таблице:
Применение пакета STATSPACK
343
Уровень Описание
О Общие статистические данные о производительности по всем областям па-
I мяти, защелкам (внутренним блокировкам), пулам и событиям.
5 Те же статистические показатели из более низких уровней плюс команды
SQL, наиболее интенсивно использующие ресурсы.
6 Те же статистические показатели из более низких уровней плюс планы SQL
и данные об использовании планов SQL.
7 Те же статистические показатели из более низких уровней плюс статистиче-
ские данные уровня сегментов, в том числе о логических и физических считываниях, блокировках строк и событиях ожидания занятых буферов (bufferbusy waits).
10 Те же статистические показатели из более низких уровней плюс данные
о блокировках родитель/потомок.
Чем выше уровень набора, тем больше времени занимает создание моментального снимка. Значение по умолчанию (5) обеспечивает значительную гибкость во время выполнения запросов для команд SQL, наиболее интенсивно использующих ресурсы. Параметры, используемые для того раздела моментального снимка, где находятся эти команды, хранятся в таблице STATS$.STATSPACK_PARAMETER. Можно задать запрос к этой таблице, чтобы проверить настройки разных пороговых значений во время сбора информации по командам SQL. Ее столбцы включают SnapJLevel (уровень моментального снимка), Executions_Th (пороговое значение числа выполнений), Disk_Reads_Th (пороговое значение числа операций считывания с диска) и Buffer_Gets_Th (пороговое значение числа операций считывания из буфера).
Для моментального снимка 5-го уровня команды SQL сохраняются, если они удовлетворяют любому из следующих критериев:
Команда SQL выполнялась минимум 100 раз.
Число выполненных операций считывания с диска превышает 1000.
Число обращений к синтаксическому анализу, выполненных командами SQL, превышает 1000.
Число обращений к буферу, выполненных командами SQL, превышает 10000.
Разделяемая память, используемая командами SQL, превышает 1 Мбайт.
Счетчик версии для команды SQL превышает 20.
При оценке данных моментального снимка и отчета производительности помните, что пороговые значения параметра SQL являются кумулятивными. Очень эффективный запрос (если он выполняется достаточное число раз) даст свыше 10000 обращений к буферу. Сравните число обращений к буферу и число операций считывания с диска с числом выполнений, и вы сможете определить активность при каждом выполнении этого запроса.
344
Гпава 9
Для изменения настроек по умолчанию используйте процедуру MODIFY_STATSPACK„PARAMETER из пакета STATSPACK. Задайте ур0, вень моментальной копии посредством параметра i_snap_level, а также па-раметры, подлежащие изменению. В таблице 9.1 приводится перечень параметров, доступных для процедуры MODIFY_STATSPACK_PARAMETER.
Таблица 9.1. Модифицируемые параметры
Имя параметра Диапазон значений По умолчанию Описание
Lsnapjevel 0, 5, 6, 7,10 5 Уровень моментального снимка
Lucomment Любой текст Пусто Комментарии к моментальному снимку
i_executions_th Целое число >=0 100 Пороговое значение для совокупного числа выполнений
i_disk_reads_th Целое число >=0 1000 Пороговое значение для совокупного числа операций считывания с диска
Lparse_calls_th Целое число >=0 1000 Пороговое значение для совокупного числа проведений синтаксического анализа
i_buffer_gets_th Целое число >=0 10000 Пороговое значение для совокупного числа обращений к буферу
Lsessionjd Допустимый SID из V$SESSION 0 ID сеанса Oracle, если нужно собрать статистические данные на уровне сеанса
i_modify_parameter True или False False Задается как True, если нужно сохранить изменения для последующих моментальных снимков
Чтобы для уровня 5 увеличить пороговое значение Buffer_Gets Д° 100000, нужно ввести команду:
□ STATSPACK.MODIFY STATSPACK PARAMETER -(i snap_level=>5, i_buffer_gets_th=>100000);
Если планируется выполнять процедуру SNAP чаще, чем один раз в час, при запуске базы данных следует “прикрепить” пакет STATSPACK в Ра3^ ляемом пуле. В следующем листинге показан триггер, который буд т подняться при каждом запуске базы данных. Процедура KEEP из SHARED_POOL “прикрепляет” этот пакет в разделяемом пуле SQL.
□ create or replace trigger PIN_ON_STARTUP after startup on database begin
DBMS .SHARED POOL.KEEP (‘PERFSTAT.STATSPACK , P’):
end;
Применение пакета STATSPACK
345
Генерация отчета о статистических показателях
Если было создано более одного моментального снимка, можно генерировать отчет по статистическим показателям в течение периода между двумя моментальными снимками. В этот период базу данных нельзя закрывать. При создании отчета необходимо знать значения Snap_ID для этих моментальных снимков. Если отчет создается з интерактивном режиме, Oracle представит список имеющихся моментальных снимков и время их создания.
Чтобы сгенерировать отчет, нужно войти в подкаталог /rdbms/admin в домашнем каталоге программного обеспечения Oracle, зарегистрироваться в SQL*Plus как пользователь PERFSTAT и запустить файл spreport.sql, который там находится.
□ SQL> @spreport
Oracle покажет идентификационную информацию о базе данных и экземпляре из V$INSTANCE и V$DATABASE, а затем вызовет второй файл SQL, называемый sprepins.sql. Эго г файл генерирует отчет об изменениях в статистических показателях за промежуток времени между моментальными снимками. Все они будут приведены в перечне, и вы получите приглашение ввести идентификаторы начальной и конечной моментальных копий. Если не определено иное, выходные данные будут записываться в файл sp_beginning_ending.lst (sp_l_2.Lst для отчета со значениями SnapJD от 1 до 2).
Первая часть выходных данных отчета представляет обзор областей кэша и их использования. В следующем листинге показан пример выхода для этого раздела с указанием размеров кэша и профиля загрузки.
П Cache Sizes (end)
Buffer Cache: 1.536M Std Block Size: 8K
Shared Pool Size: 1,648M Log Buffer: 10.240K
Load Profile
Per Second Per Transaction
Redo size: 85,921.59 1,924.45
Logical reads: 23,431.10 524.80
Block changes: 520.99 11.67
Physical reads: 457.96 10.26
Physical writes: 61.19 1.37
User calls: 2,000.92 44.82
Parses: 430.78 9.65
Hard parses. 0.04 0.00
Sorts: 57.11 1.28
Logons: 0.53 0.01
Executes: 699.70 15.67
Transactions' 44.65
% Blocks changed per Fead: 2.22
Rollback per transaction %• 0.06
Recursive Call %. 31.02
Rows per Sort: 64.62
346
Гпавад
Профиль нагрузки помогает идентифицировать тип выполняемой деятельности. В этом примере записанная деятельность изначально представляла собой выполнение как запросов, так и транзакций. Эта база данных, в среднем, поддерживает 44.65 транзакций в секунду и в то же самое время поддерживает операции логического считывания и сортировки. База данных активно выполняет операции физического чтения и записи. В интенсивно использующем операции чтения приложении число операций физической записи в секунду должно быть намного меньше, чем число операций физического считывания в секунду.
Заметьте, что в профиле нагрузки показаны средние значения в базе данных за одну секунду; однако, если интервалы отчетности в пакете STATSPACK слишком велики, то может получиться так, что для базы данных не существует такого понятия, как “средняя секунда”. Например, если в интервал отчетности попадают и процессы загрузки данных, и деятельность онлайновых пользователей, то средние значения будут отражать комбинированное влияние обоих типов использования, скрывая истинный профиль нагрузки для каждого отдельного вида деятельности.
Примечание При использовании статистических показателей профилей нагрузки помните, что они представляются как показатели “в секунду” — остальные значения отчета STATSPACK представлены как значения для полной продолжительности моментальной копии.
В следующих разделах отчета показана эффективность экземпляра (в %): число попаданий в буфер и число попаданий s библиотечный кэш, а затем статистика по разделяемому пулу SQL. Статистика по разделяемому пулу SQL показывает процентные доли используемой части пула и команд SQL, которые выполнялись несколько раз (при необходимости). Следующий листинг представляет собой пример статистических показателей разделяемого пула SQL из данного отчета:
□ Shared Pool Statistics
Memory Usage %:
% SQL with executions>1: % Memory for SQL w/exec>1:
Begin End
100.00 100.00
71.68 70.60
64.63 62.85
Как следует из данных этого листинга, во время выполнения второ го моментального снимка использовалось 100% памяти разделяемой пула SQL. Из команд этого пула только 70% выполнялось более °ДП°Г раза, что говорит о потенциальной необходимости улучшить ра3<д ление курсора в приложении. Поскольку разделяемый пул исполь^ ется полностью, необходимо рассмотреть вопрос об увеличении размера. й
В следующем разделе генерируемого отчета показаны пять сооы ожидания с самым высоким рангом, полный список событий ожидая1 и фоновые события ожидания. Идентификация главных событий ожИД ния может помочь в выборе целей оптимизации.
г
Применение пакета STATSPACK
347
Рассмотрим общие события ожидания: событие ожидания db file scattered read (ожидания, возникающие при многоблочных считываниях, например, при полном сканировании таблицы) и событие ожидания db file sequential read (последовательное чтение из файлов базы данных для одноблочных считываний). Для той же самой базы данных эти статистические показатели (здесь приводится только часть показателей) имеет следующий вид:
□ Event Waits Timeouts Time (s)
db file sequential read 1,410,528 0 3
db file scattered read 20,503 0 36
Просуммировав их, мы обнаруживаем, что для изучаемого интервала имелось 1,431,031 ожиданий во время считываний из файлов данных — одноблочных считываний индексов и таблиц плюс многоблочные считывания. Как много ожиданий получится в пересчете на одну секунду? Интервал для этого отчета был равен одному часу (3600 секунд), так что число ожиданий в секунду равно
□ 1,431,031 ожидание / 3600 сек = 397.5 ожиданий в сек
Как это число сопоставляется с числом считываний? Из профиля нагрузки уже известно число физических считываний в секунду:
□ Per Second Per Transaction
Physical reads: 457.96 10.26
Сколько же событий ожидания происходит на одно физическое считывание (за “среднюю” секунду)? Для ответа на этот вопрос нужно разделить число ожиданий за одну секунду на число физических считываний за одну секунду:
397.5 ожиданий в сек / 457.96 физических считываний в сек = 0.868
Исходя из такой статистики, примерно в 87% всех считываний для. рассматриваемого интервала пришлось столкнуться с событиями ожидания. Это очень высокий процент ожидания на одно чтение, и необходимо исследовать среду ввода/вывода, чтобы понять, пет ли возможности повысить ее производительность. Не следует считать виновниками всех бед операции полного просмотра таблицы — вспомните про источник ожиданий:
^vent Waits Timeouts Time (s)
db file sequential read 1,410,528 0 3,631
db file scattered read 20.503 0 36
Одноблочпые считывания отвечают за 98,5% — т. е. 1 410 528/
(1 410 528 + 20 503) — всех ожиданий. Поищите неэффективные индексы, которые приходится неоднократно просматривать. Если удастся устпа-
348
Гпава 9
нить все полные просмотры таблицы в базе данных, вам удастся сокра-тить число физических считываний самое большее на 1,5%.
Наиболее интенсивно поглощающие ресурсы операторы SQL перечисляются в следующем разделе отчета в порядке убывания числа обращений к буферу. Поскольку статистические показатели обращения к буферу являются кумулятивными, запрос с наибольшим числом обращений к буферу, возможно, не является запросом с наихудшей производительностью в базе данных; возможно, он просто выполнялся столько раз, что получил самый высокий ранг. Нужно сравнить совокупное число обращений к буферу с совокупным числом операций считывания с диска для запросов; если расхождение между этими числами небольшое, следует оценить план объяснения для этого запроса.
Примечание Если разделяемый пул SQL в период между выполнением двух моментальных снимков оказывается полностью заполненным и сбрасывается на диск, порция операторов SQL, которая попадет в выходной отчет, не обязательно будет содержать команды SQL, наиболее интенсивно потребляющие ресурсы в течение этого периода.
Операторы SQL перечисляются три раза — упорядоченными по числу обращений к буферу, затем по числу физических считываний и, наконец, по числу выполнений оператора. Стало общепринятым отыскивать сначала наиболее интенсивно потребляющие ресурсы операторы SQL, которые появляются в одном, в двух или даже во всех трех списках. Например, если приложение часто выполняет запрос типа
□ select TRUNC(SYSDATE) from DUAL;
то в приложении не будет генерироваться много операций физического считывания. Однако число выполнений этой команды может стать причиной того, что этот оператор сделается одним из самых “дорогих” запросов в базе данных. Некоторые приложения выполняют запросы, подобные приведенному выше, миллионы раз за день, в результате чего может получиться так, что один (или даже несколько) центральных процессоров многопроцессорной машины окажутся полностью занятыми возвра щением пользователю системной даты. Даже если команды сами по сеое эффективны с точки зрения физического ввода/вывода, следует раС смотреть количество их выполнений, число их обращений к буферу и текающую из этого числа обращений нагрузку на ЦП.
В следующем листинге показан перечень изменений статистически^ показателей из представления V$SYSSTAT, озаглавленный Instan Activity Stats (Статистические показатели деятельности экземпляре Статистические показатели из V$SYSSTAT полезны для идентификаП^ вопросов производительности, не показанных выше. Например, след)' сравнить число операций сортировки, выполненных на диске, с чи операций, выполненных в памяти; чтобы сократить сортировку на ди нужно увеличить значение PGA AGGREGATE-TARGET. Если есть зпа
операций, выполненных в памяти; чтобы сократить сортировку на Д1 нужно увеличить значение PGA_AGGREGATE_TARGET. Если есть 3Iiaz^ тельное число полных просмотров больших таблиц, надо оценить лее часто используемые запросы. В следующем листинге приведены тыре строки из этого раздела отчета:
Применение пакета STATSPACK
349
□ Statistic Total per Second per Trans
sorts (disk) 13 0.0 0.0
sorts (memory) 205,651 57.1 1.3
table scans (long tables) 23 0.0 0.0
table scans (short tables) 602,813 167.4 3.8
В этом случае имеются полные просмотры длинных (т. е. с большим числом строк; состоящих более чем из пяти блоков. — Прим, пер.) таблиц, но они составляют лишь незначительную часть всех выполняемых полных просмотров таблиц. Необходимо проверить, надлежащим ли образом организовано кэширование малых таблиц в памяти (например, в пуле KEEP). Сортировок с использованием дисковой памяти мало по количеству, но каждая из них — это напрасно потраченные усилия. Необходимо увеличить размер области сортировки (в оперативной памяти — Прим, пер.) и стараться избегать записи во временное табличное пространство, пока это не станет абсолютно необходимым.
В следующем разделе отчета представлены статистические показатели ввода/вывода по табличному пространству и файлу данных. Если операции ввода/вывода распределены по файлам неправильно, в периоды высокой активности можно столкнуться с проблемой “узких мест” в производительности. Этот раздел отчета можно использовать для идентификации таких мест и измерения эффективности решений подобных проблем (подробнее о распределении ввода/вывода по файлам см. главу 4).
Вслед за статистикой ввода/вывода идут статистические показатели кэша буфера по пулам (DEFAULT, KEEP и RECYCLE), показатели восстановления экземпляра (число блоков отката) и консультативная справка по буферным пулам. Эта справка отображает оценку фактора физического чтения, так что вы получаете возможность судить о том, насколько сильно влияет увеличение кэша буферов блоков данных (data block buffer cache) на требующееся количество физических считываний. Вслед за разделом буферных пулов идет раздел консультативной справки по значениям параметра PGA Aggregate.
Следующие разделы отчета отражают статистические показатели буферов, связанные с ожиданиями во время событий записи:
Class Waits Tot Wait Avg Time (s) Time ( ms)
data Mock 119 0 1
undo header 86 0 0
undo block 6 0 0
Использование среды автоматического управления откатом (AUM) позволяет сократить или вообще устранить ожидания для заголовков и блоков отката. Ожидания блоков данных могут быть сокращены с помощью асинхронного ввода/вывода или повышения эффективности среды ввода/вывода. В этом примере на ожидание блоков данных теряется несколько миллисекунд.
В следующем разделе отчета перечисляются ожидания типа enqueue (блокировка с очередью), в том числе блокировки ТХ для отдельных
350
Гпава 9
строк, блокировки ТС для контрольных точек потоков (нитей) и др. Ожидания типа блокировок с очередями могут быть вызваны архитектур ними решениями приложения и вопросами конфигурирования базы данных, так что для определения их причин может потребоваться дополнительное тестирование.
После этих разделов отчет предоставляет статистику по сегментам отката. Сначала перечисляется деятельность в сегментах отката — операции записи (writes), автоматические переходы к началу (wraps), сжатия (shrinks), расширения (extends) и встретившиеся ожидания. Вслед за этим идет информация о количестве сегментов отката, записанных за временной интервал.
Затем представлена статистика деятельности iiu внутренним блокировкам (latches) и словарного кэша, а после них — статистика деятельности библиотечного кэша. Если значение “Pct Miss” высоко, следует усовершенствовать разделение курсора в приложении или увеличить размер разделяемого пула.
Консультативная справка по разделяемому пулу выводится в следующем разделе отчета. В ней Oracle оценивает ожидаемое количество удачных попаданий библиотечных объектов при каждом инкрементальном увеличении размеров разделяемого пула.
Следом за сводкой о памяти SGA (из V$SGA) и листингом изменений в памяти в течение интервала между моментальными снимками идут параметры инициализации, используемые в начале и в конце этого отчета.
В целом отчет генерирует значительный объем данных, что позволяет разработать профиль базы данных и ее использования. На основании инициализации, файловых операций ввода/вывода и данных SGA можно выработать понимание основных компонентов конфигурации базы данных. Поскольку отчет генерирует так много данных, следует проявлять осторожность и не генерировать больше статистических показателей, чем вы собираетесь использовать.
Управление данными утилиты STATSPACK
Данными, собранными утилитой STATSPACK, необходимо управлять -это гарантирует, что использование пространства и производительность приложения будут соответствовать вашим потребностям по мере роста объема данных в приложении. Управление данными STATSPACK включа ет следующие этапы:
1. Регулярный анализ данных STATSPACK. Как минимум, следует ан лизировать таблицу STATSPACK перед выполнением отчет spreport.sql:
execute DBMS-UTILITY.ANALYZE_SCHEMA(‘PERFSTAT’,’COMPUTE’),
2. Удаление старых данных. Поскольку нельзя генерировать править ные отчеты в те интервалы, в течение которых происходит закр тие/запуск базы данных, то данные, предшествующие последне / запуску, не могут быть столь же полезны, как и текущие данные, гда данные уже не нужны, их следует удалять из таблиц. Для °оЛе чения удаления ставших ненужными данных Oracle предлагает ей
Применение пакета STATSPACK
351
нарий sppurge.sql. Этот сценарий, расположенный в подкаталоге /rdbms/admin каталога программного обеспечения Oracle, дает перечень хранящихся в данное время моментальных снимков и предлагает ввести два параметра: номера начального и конечного моментальных снимков для удаления. Соответствующие записи в таблице STATS$ будут удалены. Сценарий sppurge предлагает сделать резервную копию старых статистических показателей, прежде чем удалить их. Это можно сделать посредством экспорта схемы PERFSTAT. Старые статистические показатели могут потребоваться для измерений опорных значений.
3. Усечение таблицы STATSPACK, когда данные перестанут быть нужными. Старые статистические данные могут уже не соответствовать действительности или быть импортированы во время перемещения или создания базы данных. Для усечения старых таблиц нужно выполнить сценарий SQL*Plus sptrunc.sql из учетной записи PERFSTAT. Сценарий находится в подкаталоге /rdbms/admin каталога программного обеспечения Oracle.
Деинсталляция утилиты STATSPACK
Поскольку STATSPACK содержит публичные синонимы, а также приватные объекты, деинсталлировать приложение следует с помощью учетной записи с привилегией SYSDBA Oracle предоставляет сценарий spdrop.sql, автоматизирующий процесс удаления. Из подкаталога /rdbms/admin в каталоге программного обеспечения Oracle нужно зарегистрироваться в SQL*Plus и выполнить сценарий, как показано в следующем листинге:
□ SQL> connect system/manager as SYSDBA
SQL> @spdrop
Этот сценарий вызовет сценарии, которые удалят таблицы, пакет, публичные синонимы и пользователя PERFSTAT. Чтобы заново инсталлировать STATSPACK, надо выполнить сценарий spcreate.sql, как показано выше.
ЗАЩИТА И АУДИТ БАЗЫ ДАННЫХ
Для защиты одного из наиболее важных активов любой компании — ее данных — администратор должен хорошо знать, как Oracle может защищать корпоративные данные и какие инструменты имеются в его распоряжении. Предлагаемые Oracle инструментальные средства и механизмы можно отнести к одной из трех довольно широких категорий: аутентификация, авторизация и аудит.
Аутентификация (authentication) включает в себя методы, используемые для идентификации того/ кто именно пытается получить доступ к базе данных, а также для проверки, является ли это лицо тем, за кого оно себя выдает, безотносительно того, какие ресурсы базы данных при этом запрашиваются. Даже если вы всего лишь пытаетесь узнать меню завтрака в обычном кафетерии, очень важно, чтобы правильно идентифицировали себя для базы данных. Если, например, работающее через Web-приложение базы данных предлагает настроенный для конкретного пользователя контент, используя для этого учетную запись пользователя, вы все равно хотите быть уверены в том, что вам будет предложено меню для завтрака в вашем филиале офиса в Хьюстоне, шт. Техас, а не меню для головного офиса в Буффало, шт. Нью-Йорк.
Авторизация (authorization) обеспечивает доступ к различным обтек там базы данных после того, как вы будете аутентифицированы базой ДаН ных. Некоторые пользователи могут быть авторизованы для выполнения отчета по таблице ежедневных продаж, другие могут быть разрабо гчика ми, и им необходимо иметь разрешение на создание таблиц базы дани и отчетов, в то время как кому-то может быть позволено просматрив только меню завтрака. Некоторые пользователи вообще никогда не в дят в базу данных, но их схема при этом может владеть некоторым коли ством таблиц для конкретного приложения базы данных, например, Д платежной ведомости или дебиторских счетов. Вследствие исключит ных полномочий, которыми обладают АБД (скажем, они могут запуск и останавливать базу данных), им могут' быть предложены дополните ные методы авторизации.
Авторизация идет намного дальше простого доступа к таблице или чета: она включает права на использование в базе данных системны* Р
Защита и аудит базы данных
353
сурсов, а также привилегии на выполнение в ней определенных действий. Некоторому пользователю базы данных может быть разрешено использовать за сеанс не более 15 сек времени центрального процессора, либо ему может быть разрешено не более 5 мин простоя, после чего он будет отключен от базы данных. Другому пользователю базы данных может быть предоставлена привилегия создавать и уничтожать таблицы в схеме любого другого пользователя, но при этом ему не разрешено создавать синонимы или представления таблиц словаря данных. Детальный контроль доступа (Fine-Grained Access Control — FGAC) дает АБД дополнительный контроль над тем, как происходит доступ к объектам базы данных. Например, стандартные объектные привилегии либо дают пользователю доступ ко всей строке таблице, либо не разрешают его вообще. При использовании детального контроля доступа АБД может создать реализуемую в хранимой процедуре стратегию, которая может ограничить доступ, исходя из времени суток либо места, откуда был задан запрос, либо из столбца таблицы, к которому требуется обратиться, либо из всех трех критериев сразу.
В конце раздела, посвященного авторизации базы данных, будет представлен короткий пример так называемой виртуальной приватной базы данных (Virtual Private Database—VPD), чтобы предложить методы для определения, установки и обращения к атрибутам приложения вместе с предикатами (обычно, во фразе WHERE). Эти методы позволяют контролировать, к каким данным производился доступ или какие данные были возвращены пользователю приложения.
Аудит (auditing) в базах данных Oracle включает в себя множество различных уровней мониторинга. При использовании высокого уровня аудит может фиксировать как успешные, так и неудачные попытки входа (log in) в базу данных, обращения к объекту или выполнение действия. Начиная с Огас1е9г, при детальном аудите (FineGrained Auditing — FGA) не фиксируется только, к какому объекту произошло обращение, но и то, к каким столбцам таблицы производились обращения при выполнении над данными столбцов операций вставки, обновления или удаления. Детальный аудит по отношению к обычному аудиту представляет то же самое, что и детальный контроль доступа по отношению к стандартной авторизации: более точный контроль и информацию об объектах, к которым выполняется доступ, или о подлежащих выполнению действиях.
АБД должны быть благоразумны при выполнении аудита, так чтобы не оказаться ошеломленными огромным количеством записей аудита или не допустить непомерных накладных расходов при реализации сплошного аудита. С другой стороны, аудит может помочь защитить активы компании посредством мониторинга того, кто какой ресурс использует, и как часто, а также того, были ли эти обращения успешными или нет. Следовательно, аудит является еще одним средством, которое АБД должен постоянно использовать для мониторинга состояния безопасности базы данных.
^эщита вне базы данных
Все методологии, которые будут представлены в данной главе, являются оесполезными, если не защищен доступ к операционной системе или если физическое оборудование не установлено в защищенном месте.
l В следующем списке перечисляются некоторые моменты, которые Должны быть рассмотрены за пределами базы данных:
354
Гпава ю
Защита операционных систем Если только база данных Oracle не выполняется на своей собственной специально для этого выделенной машине, на которой активированы только учетные записи пользователей root и oracle, необходимо рассмотреть и реализовать вопрос об организации защиты операционной системы. Следует убедиться в том, что программное обеспечение инсталлировано от имени учетных записей root и oracle. Можно также рассмотреть вопрос об использовании вместо учетной записи oracle какой-то другой учетной записи как владельца программного обеспечения и файлов базы данных, чтобы устранить легкую мишень для хакера. Убедитесь в том, что программное обеспечение и файлы базы данных могут быть прочитаны только из учетной записи oracle и той группы, к которой принадлежит учетная запись oracle. Для всех файлов, кроме исполняемых файлов Oracle, где это требуется, отключите бит SUID (установите UID, или выполните с корневыми привилегиями). Не посылайте пароли (Oracle или операционной системы) пользователям по электронной почте в незашифрованном виде. И, наконец, удалите все системные службы, которые не используются сервером для поддержки базы данных, например, telnet и ftp.
Защитите носители с резервными копиями Убедитесь, что носители с резервными копиями базы данных — будь то лента, диск или CD/DVD-ROM — доступны только для ограниченного круга лиц. Защищенная операционная система и надежные, зашифрованные пароли для базы данных мало чего стоят, если хакеры могут получить резервные копии базы данных и загрузить их на другом сервере. То же самое относится и к любому серверу, на котором хранятся данные, тиражированные из вашей базы данных.
Проверки на отсутствие правонарушений в прошлом Отбор сотрудников, которые будут иметь дело с так называемыми уязвимыми данными базы данных — будь то АБД, аудитор или администратор операционной системы — является обязательным условием.
Образование в области защиты данных Убедитесь в том, что все пользователи базы данных понимают стратегии защиты да*' ных и их использования, применяемые в инфраструктурах И Требование, чтобы пользователи понимали стратегии защиты ДаН ных и следовали им, подчеркивает критическую природу и значп мость данных для компании, включая хранящуюся в базе данню информацию. Хорошо образованный пользователь с бодып вероятностью сможет противодействовать попыткам проникн ния в систему со стороны хакеров, владеющих навыками сои техники (искусство обмана пользователей, используемое зл0Ум я ленниками с целью выведывания паролей, необходимых проникновения в защищенную систему. — Прим. пер.).
Контролируемый доступ к оборудованию Все компьютер*^ оборудование, на котором размещается база данных, должно установлено в защищенном месте, доступ в которое разрешав только при наличии идентификационной карты или защит#
Защита и аудит базы данных
355
Методы аутентификации базой данных
Прежде чем база данных сможет позволить человеку или приложению получить доступ к объектам или привилегиям в базе данных, это лицо или приложение должны быть аутентифицированы; другими словами, должна быть подтверждена личность того, кто пытается получить доступ к базе данных.
Аутентификация базой данных
В среде, где сеть защищена от внешнего мира посредством межсетевых экранов (брандмауэров), а сетевой трафик между клиентом и сервером базы данных использует некоторые методы шифрования, аутентификация базой данных является наиболее распространенным и самым простым способом аутентификации пользователя средствами базы данных. Вся информация, необходимая для аутентификации пользователя, хранится в таблице в табличном пространстве SYSTEM.
Для очень “специальных” операций базы данных, например для запуска или остановки базы данных, требуется другая (и более защищенная) форма аутентификации с использованием либо аутентификации операционной системой, либо файлов паролей.
Сетевая аутентификация использует сервисы аутентификации от третьих фирм, например Distributing Computer Environment (DCE), Kerberos, Public Key Infrastructure (РКТ)и Remote Authentication Dial-In User Service (RADIUS). Трехуровневая аутентификация, хотя на первый взгляд она и кажется методом сетевой аутентификации, отличается тем, что промежуточный уровень, например Oracle Application Server, аутентифицирует пользователя, сохраняя при этом на сервере сведения о личности клиента (client’s identity). Вдобавок, промежуточный уровень предлагает сервисы по организации пулов подключений, а также реализует для клиента бизнес-логику.
7
Аутентификация администратора базы данных
База данных не всегда доступна для аутентификации администратора базы данных, например, когда она выведена из рабочего состояния вследствие незапланированного выхода из строя или для создания автономной резервной копии базы данных. Для разрешения этой ситуации Oracle использует файл паролей, содержащий список пользователей базы данных, которым разрешается выполнять такие функции, как запуск и выключение базы данных, инициирование резервного копирования и т. д.
Администратор базы данных может воспользоваться аутентификацией операционной системой (см. ниже). Изображенная на рис. 10.1 блок-> схема идентифицирует возможности для администратора базы данных при принятии решения о юм, какой из методов будет работать лучше в его среде.
При локальном подключении к серверу основным соображением является удобство использования одной и той же учетной записи и для операционной системы, и для сервера Oracle в сравнении с пеобхппимпгтчл
356
Гпава 1о
Администрирование удаленной базы данных
Администрирование локальной базы данных
Рис. 10.1. Блок-схема метода аутентификации
ведения файла паролей. Для удаленного администратора ведущим фактором при выборе метода аутентификации должна быть защита подключения. Без защищенного соединения хакер может легко сыграть роль пользователя с той же самой учетной записью, что и у администратора на сервере, и воспользоваться полным доступом к базе данных с помощью аутентификации ОС.
Примечание При использовании для аутентификации файла паролей следует убедиться в том, что сам файл паролей размещен в каталоге, доступ к которому возможен только администраторам операционной системы и пользователям группы, владеющей инсталляцией программного обеспечения Oracle.
Необходимо знать, что в базе данных есть две конкретные системные привилегии, дающие администраторам особую аутентификацию в базе данных: SYSDBA и SYSOPER. Администратор с привилегией SYSOP ER м°' жет запускать и останавливать базу данных, выполнять оперативное или автономное резервное копирование, архивировать текущие файлы жур налов базы данных и подключаться к базе данных, когда она работает в ре жиме RESTRICTED SESSION. Привилегия SYSDBA содержит все прав3 SYSOPER, а также право создавать базу данных и предоставлять привил^ гии SYSDBA и SYSOPER другим пользователям базы данных. t
Для подключения к базе данных из сеанса SQL*Plus в команду соппе добавляется фраза AS SYSDBA или AS SYSOPER:
□ D:\TEMP> sqlplus /nolog
SQL*Plus: Release 10.1.0,1,0 - Production on Sun Feb 15 20:52:10 2004 I
Copyright (c) 1982, 2004, Oracle Corporation. All rights reserved.
SQL> connect rjb/rjb999@dw as sysdba
Connected.
Защита и аудит базы данных
357
Помимо дополнительных привилегий, доступных пользователям, подключившимся как SYSDBA или SYSOPER, для этих двух пользователей при подключении к базе данных по умолчанию используются разные схемы. Пользователь, который подключался с системной привилегией SYSDBA, оказывается подключенным к схеме SYS; привилегия же SYSOPER устанавливает пользователя на PUBLIC:
□ SQL> show user
USER is “SYS”
Как и для любого запроса на подключение к базе данных, можно специфицировать имя пользователя и пароль в той же строке, что и команда sqlplus, вместе с ключевым словом SYSDBA или SYSOPER:
□ D:\TEMP> sqlplus гjb/rjb999@dw as sysdba
Хотя при применяемой по умолчанию инсталляции Oracle Database с использованием Oracle Universal Installer и начальной базы данных или при использовании Database Creation Assistant будет автоматически создан файл паролей, бывают случаи, когда приходится создавать его повторно, например, если он был случайно удален или поврежден. Команда orapwd создаст файл паролей с одним элементом для пользователя SYS и с другими опциями, если команда orapwd будет выполнена без каких бы то ни было опций:
□ [oracle@dw10<? oracle]$ orapwd
Usage: orapwd file=<fname> password=<password> entries=<users> force=<y/n> where
fname - имя файла паролей (обязат.),
password - пароль для пользователя SYS (обязат.),
entries - максимальное число различных АБД (DBA) и операторов (OPER) (необязат.), force - перезаписывать ли существующий файл (необязат.)
There are no spaces around the equal-to (=) character.
(Перед символом знака равенства (=) и после него не должно быть пробелов.) [oracle@dw10g oracle]$
После того как будет повторно создан файл паролей, привилегии SYSDBA и SYSOPER будут снова предоставлены тем пользователям базы Данных, которые обладали ими раньше. Вдобавок, если предложенный в команде orapwd пароль не совпадает с паролем, который был ранее в базе данных у учетной записи SYS, при первом подключении к базе данных после выполнения этой операции придется изменить пароль учетной записи SYS, чтобы пароль в базе данных и пароль в файле паролей остались синхронизованными.
Параметр инициализации системы REMOTEJLOGIN JPASSWORDFILE контролирует, как для экземпляра базы данных используется файл паролей. У него есть три возможных значения: NONE, SHARED и EXCLUSIVE.
Если значение этого параметра равно NONE, Oracle будет игнорировать любой существующий файл паролей. Все привилегированные пользователи будут должны аутентифицироваться с помощью других средств, например средствами аутентификации операционной системы (см. ниже).
358
Гпава 1 о
Если значение этого параметра равно SHARED, один и тот же файл паролей может быть использован для нескольких баз данных, но только пользователь SYS может быть аутентифицирован с этого файла, а пароль пользователя SYS не может быть изменен. В результате, этот метод не является наиболее защищенным, но он позволяет АБД вести несколько баз данных с помощью всего одной учетной записи SYS.
Совет Если должен быть использован разделяемый файл паролей, убедитесь в том, что пароль для SYS содержит не менее 8 символов и является комбинацией буквенных, цифровых и специальных символов, чтобы отразить атаку “в лоб”.
Значение EXCLUSIVE привязывает файл паролей только к одной базе данных, и в файле паролей могут существовать учетные записи других пользователей базы данных. Как только файл паролей будет создан, нужно использовать это значение для максимального повышения защиты подключений SYSDBA или SYSOPER.
Динамическое представление производительности V$PWFILE_USERS перечисляет всех пользователей базы данных, имеющих привилегии SYSDBA или SYSOPER, как показано ниже:
□ SQL> select * from v$pwfile_users;
USERNAME SYSDBA SYSOPER
SYS TRUE TRUE
RJB TRUE FALSE
SYSTEM TRUE FALSE
Аутентификация операционной системой
Если АБД выберет аутентификацию операционной системой, пользователь базы данных будет автоматически подключен к базе данных при условии, что он использует следующий синтаксис SQL*Plus:
□ SQL> sqlplus /
Этот метод очень похож на подключение как администратора базы данных без фраз as sysdba или as sysoper. Основное отличие состоит в том, что вместо генерируемого и сопровождаемого Oracle файла пар0 лей используются методы аутентификации учетных записей операций ной системы.
На самом деле администраторы могут использовать аутентификаН операционной системой для подключений as sysdba или as sysoper. J атрибуты администратора для входа в операционную систему account) попали в группу dba для Unix (или в группу ORA_DBA Д Windows), администратор может подключиться к базе данных, исп°л^^ фразу as sysdba. Аналогично, если атрибуты администратора для в> в операционную систему (login account) попали в группу sysoper для (или в группу ORA_OPER для Windows), администратор может п°Д читься к базе данных, используя фразу as sysoper, не используя при эТ файла паролей Oracle.
Защита и аудит базы данных
359
Сервер Oracle делает предположение о том, что если пользователь аутентифицирован учетной записью операционной системы, то он аутентифицирован также и для базы данных. При использовании аутентификации операционной системой Oracle не требуется хранить и вести в базе данных пароли, но там продолжают находиться имена пользователей. Они по-прежнему необходимы для определения используемых по умолчанию схемы и табличных пространств, а также для предоставления информации для аудита.
При выполняемой по умолчанию инсталляции Oracle 10g так же, как и в предыдущих выпусках Oracle, аутентификация операционной системой разрешена для учетных записей пользователей базы данных, созданных с фразой identified externally. Префикс имени пользователя базы данных должен совпадать со значением параметра инициализации OS__ AUTHENT_PREFIX; значение по умолчанию равно OPS$. Ниже приводится пример:
□ SQL> create user ops$corie identified externally;
Когда этот пользователь входи! в операционную систему через учетную запись CORIE, он автоматически аутентифицируется и для базы данных Oracle, как будто бы учетная запись OPS$CORIE была создана средствами аутентификации базы данных.
Установка значения параметра OS_AUTHENT PREFIX на пустую строку позволяет администратору базы данных и администратору учетных записей операционной системы использовать идентичные имена пользователей при использовании внешней аутентификации.
Использование фразы identified globally аналогично использованию identified externally в том плане, что аутентификация производится вне базы данных. Однако для глобально идентифицированного пользователя аутентификация выполняется корпоративной службой каталога, например Oracle Internet Directory (OID). OID способствует упрощению ведения учетных записей администраторами базы данных и удобству использования средства однократной регистрации (входа в систему) для пользователей базы данных, которым необходимо получить доступ к нескольким базам данных или сервисам.
Сетевая аутентификация
Аутентификация сетевым сервисом является еще одной доступной для АБД опцией, используемой для аутентификации пользователей в базе Данных. Хотя полная трактовка этого вопроса выходит за пределы данной книги, ниже кратко описываются методы и их гомлоненты.
Протокол SSL
вровень защищенных гнезд (Secure Sockets Layer - 55Ь)является протоколом, который первоначально был разработан Netscape Development corporation для использования в web-браузерах. Поскольку этот стандарт является общедоступным стандартом и открытым (open source) программным обеспечением, он постоянно находится в зоне пристального внимания программистов, желающих удостовериться, что в нем нет бре
360
Глава Ю
шей или “черных ходов”, которые могли бы дискредитировать его надежность.
Для аутентификации требуется, по меньшей мере, сертификат на серверной стороне. Аутентификация клиента для подтверждения личности также производится с помощью SSL, но создание сертификатов может вылиться в серьезную административную проблему, требующую многих усилий.
Для использования SSL поверх TCP/IP требуются всего лишь небольшие изменения в конфигурации прослушивающего процесса: добавление еще одного протокола (TCPS) для другого адреса порта в файле listener.ora. В приведенном ниже отрывке сконфигурированный с помощью Oracle Net Configuration Assistant (netca) прослушивающий процесс LISTENER на сервере dwl0g6y3eT принимать трафик через TCP на порте 1521, а трафик SSL TCP — на порте 2484:
□ # listener.ora Network Configuration File:
/u01/app/oracle/product/10.1.O/network/admin/listener.ora
# Генерируется средствами конфигурирования Oracle.
SID_LIST_LISTENER =
(SID.LIST =
(SID-DESC =
(SID-NAME = PLSExtProc)
(ORACLE_HOME = /u01/app/oracle/product/10.1.0)
(PROGRAM = extproc)
(SID_DESC =
(GLOBAL.DBNAME = dw.world)
(ORACLE_HOME = /u01/app/oracle/product/10.1.0)
(SID_NAME = dw)
LISTENER =
(DESCRIPTION-LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP) (HOST = dw10p) (PORT = 1521)) )
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP) (HOST = dw10p) (PORT = 2484)) )
Среда распределенных вычислений
Среда распределенных вычислений (Distributed Computing Environrnen, DCE) обеспечивает множество сервисов, например вызовы удале f процедур, распределенные файловые сервисы и распределенные серв , (службы) времени в дополнение к сервису защиты. Для всех основных с тверных и аппаратных платформ DCE поддерживает распределенные г ложения в гетерогенной среде.
Защита и аудит базы данных
361
DCE является одним из протоколов, поддерживающих единую точку входа (single sign-on — SSO); после того как пользователь был аутентифицирован для DCE, он может защищенно получать доступ к любой базе данных Oracle, сконфигурированной для DCE, не специфицируя при этом ни имени пользователя, ни пароля.
Kerberos
Kerberos — это еще одна надежная (trusted) система аутентификации от третьих фирм, которая, как и DCE, обеспечивает возможности SSO. Oracle полностью поддерживает Kerberos версии 5 с Oracle Advanced Security для Oracle Database 10gEnterprise Edition.
Как и в случае других решений для аутентификации на промежуточном уровне, основным является требование, чтобы пароль никогда не посылался по сети; вся аутентификация пересылается только сервером Kerberos. В терминологии Kerberos пароль принято называть “общим секретным ключом” (shared secret).
Инфраструктура открытых ключей
Инфраструктура открытых ключей (Public Key Infrastructure — PKI) состоит из некоторого числа компонентов. Она реализуется с использованием протокола SSL и базируется на концепции секретных приватных ключей и связанных с ними открытых ключей для облегчения защищенных коммуникаций между клиентом и сервером.
Для обеспечения сервисов идентификации и аутентификации PKI использует сертификаты и центры сертификации (Certificate Authorities — СА). Сертификат является открытым ключом сущности, подтвержденным “признанными авторитетами” (центрами сертификации), и содержит имя пользователя сертификата, дату истечения его годности, открытый ключ и т. п.
RADIUS
Служба идентификации удаленных пользователей (Remote Authentication Dial-In User Service — RADIUS) является облегченным протоколом, используемым для сервисов аутентификации, также как и для сервисов авторизации и учета. В среде Oracle роль клиента для сервера RADIUS играет Oracle Server, когда с клиента Oracle посылается запрос на авторизацию.
К серверу RADIUS в качестве нового метода аутентификации может быть добавлен любой метод, поддерживающий стандарт RADIUS, будь то карта с переменным паролем (token card), смарт-карта (smart card) или ecurlD АСЕ, при этом не требуется вносить никаких изменений в конфи-курационные файлы клиента или сервера, например в sqlnet.ora.
Трехуровневая аутентификация
® трехуровневой или многоуровневой среде сервисы аутентификации Для клиента могут быть предоставлены сервером приложений, который УДет предоставлять и общий интерфейс для сервера базы данных, даже если клиенты используют множество различных браузеров или “тол
362
Гпава 1q
стых” клиентских приложений. Сервер приложений, в свою очередь аутентифицируется базой данных и демонстрирует, что клиенту позволено подключиться к базе данных, тем самым сохраняя идентификацию клиента во всех уровнях.
В многоуровневых средах и пользователям, и промежуточным уровням предоставляются минимально возможные привилегии, достаточные для выполнения работы. Промежуточному уровню предоставляется раз-решение выполнять действия от имени пользователя, для чего используется следующая команда:
□ alter user kmourgos grant connect through oes_as with role all except ordmgmt;
В этом примере сервису сервера приложений OES_AS предоставляется разрешение выполнять действия от имени пользователя базы данных KMOURGOS. Этому пользователю было назначено множество ролей, и все они могут быть активированы через сервер приложений за исключением роли ORDMGMT. В результате, когда пользователь KMOURGOS подключается через сервер приложений, ему разрешается получать через Web доступ ко всем таблицам и пользоваться всеми привилегиями, предоставленными ему через роли, за исключением функций управления заказами. Как следствие бизнес-правил, действующих в данной компании, весь доступ к приложениям для управления заказами выполняется через прямое подключение к базе данных (подробнее о ролях см. ниже в данной главе).
Аутентификация на клиентской стороне
Аутентификация на клиентской стороне (client-side authentication) является одним из способов аутентификации пользователей в многоуровневых средах, но Oracle решительно рекомендует не использовать этот метод, если только все клиенты не находятся в надежно защищенной сети, внутри межсетевых экранов, в ситуации, когда все подключения к базе данных извне этих межсетевых экранов запрещены. Пользователи не должны также иметь никаких административных привилегий на любой рабочей станции, которая может быть подключена к базе данных.
Если пользователь Oracle создается с атрибутом IDENTIM EXTERNALLY и параметр инициализации REMOTE_OS_AUTHENTjc^ новлен на TRUE, то атакующий может легко аутентифицировать сеоя рабочей станции с учетной записью локального пользователя, совпал щей с учетной записью пользователя Oracle, и в результате получить Д туп к базе данных.
Настоятельно рекомендуется устанавливать параметр REMOl^-AUTHENT на FALSE. Чтобы такое изменение вступило в силу, неоо* мо остановить и снова запустить базу данных.
Oracle Identity Management
Oracle Identity Management (IM) является компонентом сервера a жений Oracle 10gn обеспечивает полную сквозную среду для центра д0 ванного управления учетными записями — от создания учетной запИс
Защита и аудит базы данных
363
авторизации ресурсов и удаления учетных записей. Этот компонент централизует управление учетными записями, а также устройствами, приложениями, web-сервисами или любыми другими сетевыми сущностями, использующими аутентификацию и авторизацию.
IM экономит время и деньги. Поскольку учетные записи пользователей и ассоциированные с ними ресурсы являются централизованными, администрирование будет одинаковым вне зависимости от сопровождаемого приложения.
Помимо этого, IM повышает защищенность компании. Поскольку пользователи используют для доступа ко всем корпоративным ресурсам одно имя пользователя и один пароль, у них становится меньше причин записывать свои пароли или забывать их. Когда пользователь покидает компанию, весь его доступ к приложениям и сервисам может быть легко и быстро аннулирован.
Хотя полная трактовка Oracle Identity Management выходит за рамки данной книги, администратору важно понимать, как компоненты IM влияют на производительность и защищенность базы данных Oracle. Информация учетной записи пользователя и другие метаданные должны избыточно храниться где-то в базе данных Oracle. Кроме того, запросы па сервисы аутентификации и авторизации должны быть обработаны за разумный промежуток времени, который, скорее всего, определяется в соглашении об уровне обслуживания (Service Level Agreement — SLA), действующем для одного или нескольких приложений.
Например, Oracle Internet Directory (OID) — один из основных компонентов Oracle Identity Management — требует настройки базы данных, в чем-то похожей на настройку системы OLTP с множеством коротких транзакций, поступающих от большого количества пользователей и с заметно изменяющимися нагрузками, зависящими от времени суток. Но на этом сходство заканчивается! В таблице 10.1 приводятся некоторые общие правила задания различных параметров инициализации системы для базы данных, в которой будет вестись информация каталога LDAP (Lightweight Directory Access Protocol) — облегченного протокола службы каталогов). к
Табл ица 10.1. Определение значений параметров инициализации для 010
Параметр базы данных 500 одновременно работающих пользователей 2000 одновременно работающих пользователей
OPEN_CURSORS 200 200
SESSIONS 445 1655
OB-BLOCK-SIZE 8K 8K
OB-CACHE-SIZE 250MB 250MB
SHARED_POOL_SIZE 40MB 40MB
PROCESSES 400 1500
SORT_AREA_SIZE 256KB 256KB
LOG BUFFER 512KB 512KB
364
Гпава 1q
Предполагается, что единственной задачей этой базы данных являет-ся обслуживание информации каталога OID. В дополнение к настройке параметров базы данных, общая пропускная способность будет зависеть от таких факторов, как ширина полосы пропускания сети между серве. ром и сообществом пользователей, место нахождения разделяемых дисковых ресурсов, производительность диска и т. п. Типовое развертывание IM с 500 000 элементов каталога будет требовать для своей работы приблизительно 3 Гбайт дискового пространства, и то, насколько быстро или как медленно будут элементы записываться в каталог или считываться из него, может легко стать “узким местом” для пропускной способности.
Учетные записи пользователей
Для получения доступа к базе данных пользователь должен представить имя пользователя, чтобы можно было обратиться к ресурсам, ассоциированным с этой учетной записью. Каждое имя пользователя должно иметь пароль и быть ассоциированным с одной и только одной схемой в базе данных; для некоторых учетных записей в схеме может не быть объектов, но вместо них этой учетной записи должны быть предоставлены привилегии для доступа к объектам в других схемах.
Создание пользователей
Команда create user достаточно проста. В ней есть некоторое количество параметров (см. 10.2, где приводятся их краткие описания).
В следующем примере создается пользователь (SKING), который соответствует пользователю Стивену Кингу (Steven King) и имеет табельный номер служащего 100 в таблице HR.EMPLOYEES из демонстрационных схем, инсталлируемых вместе с базой данных:
□ SQL> create user sking identified by sking901
2 account unlock
3 default tablespace users
4 temporary tablespace temp;
User created.
Пользователь SKING аутентифицируется базой данных с перво*# чальным паролем SKING901. Вторая строка не является обязательно^’ все учетные записи по умолчанию создаются ^заблокированными, пользуемые по умолчанию постоянное и временное табличные простр ства определяются на уровне базы данных. Поэтому последние две с ки команды не являются необходимыми, если только не ТРе^е^ое определить для этого пользователя другое постоянное или времен табличное пространство.
Несмотря на то, что пользователю SKING было явно или неявно^ значено применяемое по умолчанию постоянное табличное простри во, он не может создавать в базе данных никаких объектов, пока ДЛЯ Н будут представлены квоты и привилегии на создание объектов в с° венной схеме.
даШита и аУДит базы данных
365
Табл ица 10.2. Опции команды CREA ТЕ USER
Параметр
имя_пользователя
IDENTIFIED { BY пароль I EXTERNALLY I GLOBALLY AS ' внешнее _имя'}
DEFAULT TABLESPACE табличное_пространство
TEMPORARY TABLESPACE табличное-Пространство
QUOTA {размер I UNLIMITED) ON табличноепространство
PROFILE профиль
PASSWORD EXPIRE
ACCOUNT {LOCK I UNLOCK}
Использование
Имя схемы и, следовательно, пользователя, которые будут созданы. Имя пользователя может иметь длину до 30 символов и не может быть зарезервированным словом, если только оно не заключено в кавычки (кстати, это не рекомендуется).
Определяет, как будет аутентифицирован пользователь: базой данных с паролем, операционной системой (локальной или удаленной) или с помощью сервиса (типа Oracle Internet Directory).
Табличное пространство, в котором создаются постоянные объекты, если только табличное пространство не будет явно определено во время создания.
Табличное пространство, в котором создаются временные сегменты при создании индексов, операциях сортировки и тому подобных операциях.
Количество пространства, разрешенного для объектов, которые создаются в специфицированном табличном пространстве. Размер задается в килобайтах (К) или мегабайтах (М).
Профиль, назначенный данному пользователю (о профилях см. ниже в данной главе). Если профиль не определен, используется профиль DEFAULT.
При первом входе в систему пользователь обязан сменить пароль.
Определяет, будет ли учетная запись создана заблокированной или незаблокированной. По умолчанию учетная запись создается незаблокированной.
Квота — это просто лимит пространства (по табличным пространствам) для заданного пользователя. Пока пользователю не будет явно назначена квота или ему будет предоставлена привилегия UNLIMITED TABLESPACE (о привилегиях см. ниже в данной главе), пользователь не может создавать объекты в своей собственной схеме. В следующем примере учетной записи пользователя SKING дается квота 250 Мбайт в табличном пространстве USERS:
О SQL> alter user sking quota 250M on users;
User altered.
Можно предоставить эту квоту пользователю во время создания учетной записи вместе почти со всеми опциями команды create user. Однако используемая по умолчанию роль может быть назначена только после создания учетной записи (об управлении ролями см. ниже в данной главе.)
Если не предоставить вновь созданной записи некоторых базовых привилегий, учетная запись не сможет даже зарегистрироваться в базе Данных. Следовательно, нужно предоставить ей, по крайней мере, приви
366
Гпава !q
легию CREATE SESSION или роль CONNECT. В роль CONNECT включена привилегия CREATE SESSION, а также некоторые другие базовые привилегии, например CREATE TABLE и ALTER SESSION. В приведенном ниже примере пользователю sking предоставляется привилегия CONNECT:
□ SQL> grant connect to sking;
Grant succeeded.
Теперь у пользователя SKING есть квота в табличном пространстве USERS, а также привилегии для создания объектов в этом табличном пространстве.
Все эти опции для команды create user доступны в построенном на web-технологиях интерфейсе Enterprise Manager (см. рис. 10.2).
Как для любой операции Enterprise Manager, кнопка Show SQL показывает фактические команды SQL, например create или grant, которые будут выполнены при создании пользователя. Это прекрасная возможность воспользоваться преимуществами простоты использования web-интерфейсов и в то же самое время усовершенствовать свои знания синтаксиса команд SQL. На рис. 10.3 показано, что очень просто выбрать существующего пользователя и создать на его базе нового пользователя с теми же самыми характеристиками (за исключением пароля).
К числу других опций, доступных в интерфейсе Enterprise Manager, относятся истечение срока годности учетной записи пользователя, генерация команд DDL, используемых для создания учетной записи, и блокировка или разблокирование учетной записи.
Рис. 10.2. Создание пользователей в Enterprise Manager
Защита и аудит базы данных
367
” « г—— г *1 Chicle Enterprise " 1 " 0 - Osers - Mi crosoft Interne t Explorer у
File Edt View Fawntes Tools Hdp
1 fej ! Search Favorites □J S3.
Ac.! http //192 163.2. . . . - - . • - - l69:S500/entfcon£Qle/databdse»databa$eOt)ect$Seardi?e¥ent^ed5playeotype»USER&tefQet“dw wprkj& v ь J Go
Results
ч Create)
• г 4 г/ ? * . Edit) view) Delete) Actions Create Like ^Kfto)
C -'VW г: 1-25 of 33 Y = NexlS^
Acx<M|ni Shuts С>'|Я dfeftth : Bate » fanit ГаЫезрйЫ?; Г*. lop taiy Profile л/ < i • iteU
O EXPIRED & 2004-02-15 SYSAUX TEMP DEFAULT 2004-02-05
LOCKED 10 19 47 13 25 26
c a EXPIRED £ 2004-02-15 USERS TEMP DEFAULT 2004-02 15
LOCKED 10.19 46 10 13 31
О ClZixS EXPIRED & 2004-02 15 SYSAUX TEMP DEFAULT 2004-02-05
LOCKED 10 19 47 13 24 32
О D3SNMP OPEN SISALS ТЕМЕ MONITORING PROFILE 2004-02-05 13.07 19
О DOPANT OPEN TEMP DEFAULT 2004-02-15
1030 17
0 OJP EXPIRED & LOCKED IS.MP DEFAULT 2004 02-05 12 58 53
: О EXPIRED & LOCKED 2004-02-15 .10 19 47 SYSAUX 1£M£ DEFAULT 2004-02-05 13 23 30
О EXFSYS EXPIRED & LOCKED 2004-02-15 10 19 47 SYSAUX temp DEFAULT 2004-02-05 13 17 18
ТГ-* f\r-r M . aa V m о л
Рис. 10.3. Копирование пользователей в Enterprise Manager
Изменение пользователей
Изменение характеристик пользователя осуществляется с помощью команды alter user. Синтаксис этой команды практически идентичен синтаксису команды create user, за исключением того, что команда alter user позволяет назначать роли и предоставлять привилегии для приложений промежуточного уровня, что дает им возможность выполнять функции от имени пользователя.
В следующем примере пользователь SKING изменяется так, чтобы он по умолчанию использовал другое постоянное табличное пространство:
О SQL> alter user sking
2 default tablespace users2
3 quota 500M on users2;
User altered.
Пользователь SKING может создавать объекты в табличном пространстве USERS, но он должен явно специфицировать USERS в любой команде create table или create index.
Удаление пользователей
Удаление пользователей — очень простая операция, выполняемая с помощью команды drop user. Параметрами команды являются имя подлежащего удалению пользователя и опция cascade. Если не используется опция cascade, любой объект, которым владеет пользователь, должен быть явно удален или перемещен в другую схему. В следующем примере удаля
368
Гпава ю
ется пользователь QUEENB, и, если в базе данных имеются какие-то объекты, которыми владел этот пользователь, они также будут автоматически удалены:
□ SQL> drop user queenb cascade;
User dropped.
Если объекты какой-то другой схемы, например представления или пакеты, зависят от объектов, удаленных при удалении пользователя, такие объекты в другой схеме будут помечены как INVALID (недействительные) и должны быть перепрограммированы (чтобы в них стали использоваться другие объекты), а затем перекомпилированы. Кроме того, все объектные привилегии, которые были предоставлены первым пользователем второму посредством фразы with grant option, будут автоматически отозваны у второго пользователя при удалении первого.
Как стать другим пользователем
При отладке приложения АБД иногда для воспроизведения проблемы требуется подключиться как другому пользователю. Не зная точно незашифрованного пароля пользователя, АБД может выбрать из базы данных зашифрованный пароль пользователя, изменить пароль для этого пользователя, подключиться с измененным паролем, а затем вернуть его обратно, используя так называемую недокументированную опцию команды alter user. Предполагается, что АБД имеет доступ к таблице DBA_USERS, а также привилегию ALTER USER. Если у АБД есть роль DBA, оба эти условия являются выполненными.
На первом шаге необходимо получить для пользователя зашифрованный пароль, который хранится в таблице DBA_USERS:
П SQL> select password from dba_users
2 where username = ‘SKING’;
PASSWORD
83C7CBD27A941428
1 row selected.
В среде с графическим пользовательским интерфейсом нужно сохра нить этот пароль, используя операции копирования и вставки, либо втек стовом файле, чтобы им можно было воспользоваться впоследствии. Сде дующий шаг заключается во временной замене пароля пользователе и последующем входе в базу данных с использованием временно изменен ного пароля:
□ SQL> alter user sking identified by temp_pass;
User altered
SQL> connect sking/temp_pass@dw;
Connected.
Теперь можно приступить к отладке приложения от имени пользой*1 теля SKING и с его “точки зрения”. После завершения отладки надо снов*1
ЗаШита и аудит базы данных
369
изменить пароль, используя недокументированную фразу by values команды alter user:
□ SQL> alter user sking identified by values 183C7CBD27A941428’;
User altered.
Tаблица 10.3. Представления и таблицы словаря данных, относящиеся
к пользователям
Представление словаря данных Описание
DBAJJSERS Содержит имена пользователей, зашифрованные пароли, статусы учетных записей и -используемые по умолчанию табличные пространства.
DBA_TS_QUOTAS Использование дискового пространства и предельные значения в разрезах по пользователям и табличным пространствам для пользователей, имеющих нормальные (не UNLIMITED) квоты.
DBA_PROFILES Профили, которые могут быть назначены пользователям, с лимитами ресурсов, назначенными профилю.
USER_H1STORY$ История паролей с именами пользователей, зашифрованными паролями и отметками времени. Используется для принудительного выполнения правил повторного использования паролей.
Представления словаря данных, относящиеся к пользователям
Некоторое количество представлений словаря данных содержит информацию, относящуюся к пользователям и характеристикам пользователей (см. таблицу 10.3).
Методы авторизации базы данных
После того как пользователь был аутентифицирован для базы данных, следующий шаг заключается в том, чтобы определить, какие типы объектов, привилегий и ресурсов разрешены для доступа и использования.
Управление профилями
Создается впечатление, что для выполнения запросов пользователей никогда не будет хватать вычислительной мощности процессора или дисковой памяти, или полосы пропускания ввода/вывода. Поскольку все эти ресурсы ограничены по своей природе, Oracle предоставляет механизм Для контроля объема ресурсов, который может расходовать пользователь. Профиль Oracle — это именованный набор ограничений ресурсов, предлагаемый этим механизмом.
Кроме того, профили могут быть использованы как механизм авторизации для контроля того, как создаются, повторно используются и подтверждаются пароли пользователей. Можно, например, принудительно установить минимальную длину пароля, а также выдвинуть требование, чтобы в пароле имелся хотя бы один буквенный символ в верхнем или нижнем регистрах.
370
Гпава iq
Команда CREATE PROFILE
Команда CREATE PROFILE выполняет две обязанности: можно создать профиль для ограничения для пользователя времени подключения (к базе данных) 120 минутами.
□ create profile lim_connect limit connect_time 120;
Можно ограничить максимальное число следующих подряд неудач-ных попыток регистрации в системе (входа в систему), после чего учетная запись блокируется:
□ create profile lim_fail_login limit failed_login_attempts 8;
Или же можно объединить два этих профиля в один:
□ create profile lim_connectime faillog limit connect_time 120
failed_login_attempts 8;
To, как Oracle будет реагировать на превышение одного из лимитов ресурса, зависит от типа лимита. Если превышенным окажется либо максимальное время подключения, либо лимитированное (например, CPU_PER_SESSION), выполняющаяся транзакция будет откачена (roll back), пользователю будет возвращено сообщение об ошибке, после чего сеанс будет отключен. Для большинства других лимитов ресурсов (например, PRIVATE_SGA) выполняющаяся транзакция будет откачена, пользователю будет возвращено сообщение об ошибке, и у него появится выбор: зафиксировать (commit) транзакцию или откатить ее. Если транзакция превосходит установленный пример для одиночного вызова (например, LOGICAL_READS_PER_CALL), операция завершается аварийно, текущий оператор откатывается, а пользователю возвращается сообщение об ошибке. Оставшаяся часть транзакции остается неактивной; пользователь может затем откатить, зафиксировать или попытаться завершить транзакцию без превышения лимитов оператора.
Предлагаемый Oracle профиль DEFAULT применяется к любому ново му пользователю, если для него не был явно специфицирован никакой ДрУ гой профиль. Запрос к представлению словаря данных DBAJPROFlb раскрывает лимиты для профиля DEFAULT:
□ SQL> select * from dba_profiles
2
where profile = ‘DEFAULT’;
PROFILE RESOURCE_NAME RESOURCE LIMIT
DEFAULT COMPOSITE_LIMIT KERNEL UNLIMITED
DEFAULT SESSIONS-PER-USER KERNEL UNLIMITED
DEFAULT CPU.PER-SESSION KERNEL UNLIMITED
DEFAULT CPU PER CALL KERNEL UNLIMITED
DEFAULT LOGICAL READS PER SESSION KERNEL UNLIMITED
DEFAULT LOGICAL READS PER_CALL KERNEL UNLIMITED
DEFAULT IDLE TIME KERNEL UNLIMITED
Зашита и аудит базы данных
371
DEFAULT CONNECT_TIME KERNEL UNLIMITED
DEFAULT PRIVATE_SGA KERNEL UNLIMITED
DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10
DEFAULT PASSWORD_LIFE-TIME PASSWORD UNLIMITED
DEFAULT PASSWORD_REUSE. TIME PASSWORD UNLIMITED
DEFAULT PASSWORD_REUSE_MAX PASSWORD UNLIMITED
DEFAULT PASSWORD-VERIFY-FUNCTION PASSWORD NULL
DEFAULT PASSWORD_LOCK_TIME PASSWORD UNLIMITED
DEFAULT PASSWORD GRACE TIME PASSWORD UNLIMITED
16 rows selected.
Единственное реально действующее ограничение в профиле DEFAULT ограничивает количество следующих подряд неудачных попыток входа в систему десятью, прежде чем учетная запись будет заблокирована. Кроме того, не активирована ни одна функция верификации пароля.
Профили и управление паролями
В таблице 10.4 приводятся относящиеся к профилям параметры. Все временные единицы указываются в сутках (для перевода этих показателей, например, в минуты, достаточно умножить их на 1440):
□ SQL> create profile limJLock limit password_lock_time 5/1440; Profile created.
В этом примере после заданного количества неудачных попыток входа в систему учетная запись будет заблокирована на 5 мин.
Значение параметра unlimited означает, что какие-либо ограничения на то, сколько именно данного ресурса будет использовано, отсутствуют; default означает, что значения этого параметра берутся из профиля DEFAULT.
Параметры password_reuse__time и password_reuse_max должны использоваться только вместе; установка одного из них без установки другого не даст никакого полезного эффекта. В следующем примере создается профиль, для которого значение параметра password_reuse_time будет установлено на 20 суток, а значение параметра password__reuse_max — на 5:
П create profile lim_reuse_pass limit password_reuse time 20 password_reuse_max 5;
Для пользователей с таким профилем их пароль может быть снова использован через 20 суток, если пароль за это время был изменен, по крайней мере, пять раз. Если для одного из этих параметров будет определено значение, а второй по-прежнему будет иметь значение UNLIMITED, пользователь никогда не сможет использовать пароль повторно.
Как большинством других операций, профилями можно с легкостью управлять из Oracle Enterprise Manager. На рис. 10.4 показан пример изменения профиля DEFAULT, чтобы пользователя можно было отключить от базы данных после 15 мин простоя.
372
Глава 1о
Таблица 10.4. Параметры профиля, связанные с паролями
Параметр пароля Описание
FAILED_LOGIN_ATTEMPTS Количество неудачных попыток входа в систему, прежде чем учетная запись будет заблокирована.
PASSWORD_LIFE_TIME Количество суток возможного использования пароля, прежде чем он должен быть изменен. Если пароль не будет изменен в течение PASSWORD_GRACE_TIME, он должен быть изменен, прежде чем можно будет повторить попытку входа в систему.
PASSWORD_REUSE_TIME Число суток ожидания пользователем, прежде чем он сможет еще раз использовать старый пароль; этот параметр должен использоваться вместе с параметром PASSWORD_REUSE_MAX.
PASSWOWRD_REUSE_MAX Число изменений, которое должен претерпеть пароль, прежде чем можно будет использовать его старое значение; этот параметр должен использоваться вместе с параметром PASSWORD_REUSE_TIME.
PASSWORD_LOCK_TIME Число суток, в течение которых будет заблокирована учетная запись после превышения FAILED_LOGIN_ ATTEMPTS попыток. По истечении этого промежутка времени учетная запись будет автоматически разблокирована.
PASSWORD_GRACE_TIME Число суток, по истечении которых истекший пароль должен быть изменен. Если он не будет изменен в течение этого периода, учетная запись считается истекшей и пароль должен быть изменен, прежде чем пользователь сможет успешно войти в систему.
PASSWORD-VERIFY-FUNCTION Сценарий PL/SQL, позволяющий обеспечить продвинутую процедуру верификации пароля. Если (по умолчанию) задано значение NULL, верификация пароля не производится.
Если требуется обеспечить более жесткий контроль над тем, как создаются и повторно используются пароли (например, используется ли в каждом пароле смесь символов верхнего и нижнего регистров), необходимо активировать в каждом применяемом профиле функцию верификации пароля (PASSWORD__VERIFY_FUNCTION). Для принудительного проведения в организации политики паролей Oracle предлагает шаблон. О** размещается по адресу $ORACLE_HOME/rdbms/admin/utlpwdmg«sql-Сокращенная версия этого сценария приводится в Приложении А.
Сценарий обеспечивает следующие функциональные возможности для придания дополнительной сложности паролям:
Проверка того, что пароль не совпадает с именем пользователя
Проверка длины пароля (не менее 4 символов)
Проверка, не является ли пароль простым (обыкновенным) сЛ° вом, например ORACLE или DATABASE
Возвращение пароля, содержащего букву, цифру и знак пунктуаций
Проверка того, отличается ли предлагаемый пароль от использо вавшегося перед ним пароля хотя бы тремя символами
Защита и аудит базы данных
373
Private Interconnect Enforcement
Use this page tc identify the interfaces to use as private interconnects
If there is more than one subnet associated with an interface, then activate t.ne drop down menu by clicking m tne subnet cell Select a subnet for which you want to modify tne interface type Mark the global network interfaces that are available across ail ire cluster nodes as either Private, Public, or Do f iot Use
, •• ♦ Л.Л •• •• z. • . f •. . Г . .. -ф* v* • • •. z* z* ->4v * - zuv*%* . • л- > r «
Interface Name Subnet interface Type
ethO 192 168 2 0 Public
ethi 19216810 Private'
—ч><>.
41
Help Installed Products.. Back Next Cancel
Рис. 10.4. Изменение лимитов пароля в Oracle Enterprise Manager
Первый из шагов при использовании этой политики — это внесение в сценарий требующихся изменений. Например, заказчик может попросить использовать для верификации несколько различных функций — по одной для каждой страны или для каждого бизнес-подразделения. Это необходимо для обеспечения совпадения требований к сложности паролей с требованиями операционных систем, применяемых в конкретной стране или в бизнес-подразделении. Следовательно, необходимо переименовать эту функцию, например в VERIFY_FUNCTION__US_MIDWEST. Вдобавок можно пожелать изменить используемый список простых слов, с которыми не должен совпадать пароль, с целью включения в него названия подразделений этой компании.
После успешной компиляции функции можно либо с помощью команды alter profile изменить существующий профиль, чтобы в нем использовалась новая функция, либо создать новый профиль, в котором она будет использована. В приведенном ниже примере изменен профиль DEFAULT, чтобы теперь в нем была использована функция VERIFY FUNCTION US MIDWEST: “ ” -
Q SQL> alter profile default limit
2 password_verify_function verify_function_us_midwest;
Profile altered.
Для всех пользователей, использующих профиль DEFAULT, или для всех новых пользователей, которые также используют его, пароли будут верифицироваться с помощью вызова функции VERIFY_FUNCTION_ US_MIDWEST. Если эта функция возвратит отличное от TRUE значение,
374
Гпава 1q
пароль будет признан недопустимым и пользователь будет должен ука. зать другой пароль. Если текущий пароль пользователя не соответствует действующим в организации правилам, он будет считаться действитель ным до момента своего изменения, но, начиная с этого момента, новый пароль будет обязательно верифицирован используемой функцией.
Профиле и контроль ресурсов
Перечень опций контроля ресурсов, которые могут быть использованы после фразы CREATE PROFILE имя_профиля LIMIT, приводится в таблице 10.5. Каждый из этих параметров либо может быть целым числом, либо принимать значения UNLIMITED или DEFAULT.
Таблица 10.5. Связанные с ресурсами параметры профиля
Параметр ресурса Описание
SESSIONS_PERJJSER Максимальное число сеансов, одновременно разрешенных пользователю
CPU_PER_ SESSION Максимальное время ЦП, выделяемое сеансу, в сотых долях секунды
CPU_PER_CALL Максимальное время ЦП, выделяемое для синтаксической разборки, выполнения или операций выборки оператора в сотых долях секунды
CONNECTJIME IDLE_TIME Максимальное общее затраченное время в минутах Максимальное время непрерывной неактивности сеанса (в минутах), в течение которого не велась обработка никакого запроса или другие операции
LOGICAL_READS_PER_SESSION Общее число блоков данных, прочитанных в течение сеанса либо из памяти, либо с диска
LOGICAL_READS_PER_CALL Максимальное число блоков данных, прочитанных за время синтаксической разборки, выполнения или операций выборки для отдельного оператора
COMPOSITEJJMIT Полная стоимость ресурса в сервисных единицах (service units) как композитная взвешенная сумма CPU_PER_SESSION, CONNECT TIME, LOGICAL READS_PER_SESSION и PRIVATE_SGA
PRIVATE_SGA Максимальный размер памяти, которую сеанс может выделить в разделяемом пуле, в байтах, килобайтах или мегабайтах .
Как и для параметров, относящихся к паролям, UNLIMITED означав» что отсутствуют какие бы то пи было ограничения на то, какой объем Д ного ресурса может быть использован, a DEFAULT означает, что этот раметр получает свое значение из профиля DEFAULT.
Параметр COMPOSITEJLIMIT позволяет контролировать группу митов ресурсов, когда обычно используемые ресурсы изменяются по нам; он позволяет пользователю расходовать много времени ЦП, но слишком много операций ввода/вывода в течение одного сеанса, и Н
375
г
Зашита и аУДит базы данных
оборот — во время другого сеанса, и при этом не быть отключенными благодаря этой политике.
По умолчанию все ресурсы получают нулевые “стоимости”:
О SQL> select * from resource_cost;
RESOURCE-NAME UNIT.COST
CPU_PER_SESSION 0
LOGICAL_READS_FOR_SESSION 0
CONNECT_TIME 0
PRIVATE-SGA 0
4 rows selected.
Чтобы изменить веса “стоимостей”, нужно использовать команду ALTER RESOURCE COST. В этом примере весовые коэффициенты изменяются таким образом, чтобы параметр CPU_PER_SESSION обеспечивал предпочтительность использования ЦП по сравнению со временем подключения в отношении 25:1; другими словами, чтобы пользователь значительно чаще отключался из-за расходования ЦП, чем из-за превышения времени подключения:
□ SQL> alter resource cost
2 cpu_per_session 50
3 connect-time 2;
Resource cost altered.
SQL> select * from resource_cost;
RESOURCE-NAME UNIT_COST
CPU.PER-SESSION 50
LOGICAL_READS_FOR_SESSION 0
CONNECT_TIME 2
PRIVATE_SGA 0
4 rows selected.
На следующем шаге необходимо создать новый профиль или модифицировать существующий профиль, чтобы он использовал композитный (составной) лимит:
П SQL> create profile lim_comp_cpu_conn limit
2 composite_limit 250;
Profile created.
В результате у пользователей, приписанных к профилю LIM_COMP_ CPU_CONN, ресурсы сеансов будут ограничиваться в соответствии со следующей формулой вычисления затрат:
О составные_затраты = (50 * CPU_PER_SESSION) + (2 * CONNECT_TIME);
376
Глава 1о
В таблице 10.6 предложено несколько вариантов использования ре. сурсов, чтобы увидеть, когда будет превышен составной лимит использования ресурсов (250).
Таблица 10.6. Сценарии использования ресурсов
ЦП (секунды) Подключение (секунды) Составные затраты Превышены?
0.05 100 (50*5) + (2*100) = 450 Да
0.02 30 (50*2) + (2*30) = 160 Нет
0.01 150 (50*1)+ (2*150) = 350 Да
0.02 5 (50*2)+ (2*5) = 110 Нет
В этом конкретном примере не были использованы параметры PRIVATE_SGA и LOGICAL_READS_PER__SESSION, так что, до тех пор пока они не будут специфицированы в определении профиля по-другому, их значениями по умолчанию будут назначенные в профиле DEFAULT. Цель использования композитных лимитов заключается в том, чтобы дать пользователям некоторую свободу в типах выполняемых ими запросов и команд DML. В какие-то дни они могут выполнять много запросов, использующих большие объемы вычислений, но не могут обращаться к большому количеству строк таблиц; в другие дни они могут выполнять много полных просмотров таблиц, по не могут слишком долго оставаться подключенными к базе данных. В подобных ситуациях не следует ограничивать пользователя одним параметром, нужно ввести ограничение на общее использование ресурсов, взвешенное пропорционально доступности каждого из ресурсов на сервере.
Системные привилегии
Системной привилегией называется право выполнения определенного действия над любым объектом базы данных, а также другие привилегии, которые вообще не затрагивают объекты, а касаются выполнения пакетных заданий, изменения параметров системы, создания ролей и даже подклю чения к базе данных. В выпуске 1 Oracle lOg-насчитывается 173 системные привилегии. Все эти привилегии можно найти в таблице словаря данных SYSTEM JPRIVILEGEJMAP:
□ SQL> select * from system_privilege_map;
PRIVILEGE NAME
- 3 ALTER SYSTEM
- 4 AUDIT SYSTEM
- 5 CREATE SESSION
- 6 ALTER SESSION
- 7 RESTRICTED SESSION
- 10 CREATE TABLESPACE
- 11 ALTER TABLESPACE
- 12 MANAGE TABLESPACE
PROPERTY
0
0
0
0
0
0
0
0
Защита и аудит базы данных
377
- 13 DROP TABLESPACE О
- 15 UNLIMITED TABLESPACE О
- 20 CREATE USER О
- 21 BECOME USER 0
- 22 ALTER USER 0
- 23 DROP USER 0
- 271 ALTER ANY SQL PROFILE 0
- 272 ADMINISTER SQL TUNING SET 0
- 273 ADMINISTER ANY SQL TUNING SET 0
- 274 CREATE ANY SQL PROFILE 0
- 275 EXEMPT IDENTITY POLICY 0
173 rows selected.
В таблице 10.7 перечислены некоторые из самых распространенных системных привилегий и их краткие описания.
Предоставление системных привилегий
Привилегии предоставляются пользователю, роли или группе PUBLIC при помощи команды grant; для отзыва привилегий используется команда revoke. Группа PUBLIC — это особая группа, в которую входят все пользователи базы данных и которая является удобным сокращением для предоставления привилегий каждому пользователю базы данных.
Для предоставления пользователю SCOTT привилегии создавать хранимые процедуры и синонимы можно использовать следующую команду:
□ SQL> grant create procedure, create synonym to scott;
Grant succeeded.
Отзыв привилегий столь же прост:
О SQL> revoke create synonym from scott;
Revoke succeeded
Если необходимо предоставить пользователю, получающему разрешение (grantee), право предоставлять те же самые привилегии кому-то еще, можно включить в команду предоставления привилегии фразу with admin option. Допустим, мы хотим, чтобы пользователь SCOTT имел возможность предоставлять привилегию CREATE PROCEDURE другим пользователям. Для этого необходимо передоверить ему привилегию CREATE PROCEDURE:
SQL> grant create procedure to scott with admin option;
Grant succeeded.
Теперь Скотт может сам издавать команду grant create procedure. Если разрешение Скотту на предоставление привилегий другим пользователям будет отозвано, пользователи, которым эти привилегии были предоставлены ранее, сохранят их.
378
Гпава ю
Таблица 10.7. Часто встречающиеся системные привилегии
Системная привилегия Возможности
ALTER DATABASE Вносить изменения в базу данных, например изменять статус базы данных с MOUNT на OPEN или восстанавливать базу данных.
ALTER SYSTEM Выдавать операторы ALTER SYSTEM: переключаться на следующую группу файлов журналов базы данных и изменять системные параметры в файле SPFILE.
AUDIT SYSTEM Выдавать операторы AUDIT.
CREATE DATABASE LINK Создавать связи баз данных с удаленными базами данных.
CREATE ANY INDEX Создавать индексы в любой схеме; эта привилегия предоставляется вместе с привилегией CREATE TABLE для схемы пользователя.
CREATE PROFILE Создавать профиль ресурса/пароля.
CREATE PROCEDURE Создавать функции, процедуры или пакеты в собственной схеме.
CREATE ANY PROCEDURE Создавать функции, процедуры или пакеты в любой схеме.
CREATE SESSION Подключаться к базе данных.
CREATE SYNONYM Создавать приватный синоним в собственной схеме.
CREATE ANY SYNONYM Создавать приватный синоним в любой схеме.
CREATE PUBLIC SYNONYM Создавать публичный синоним в собственной схеме.
DROP ANY SYNONYM Удалять приватный синоним из любой схемы.
DROP PUBLIC SYNONYM Удалять публичный синоним из любой схемы.
CREATE TABLE Создавать таблицу в собственной схеме.
CREATE ANY TABLE Создавать таблицу в любой схеме.
CREATE TABLESPACE Создавать табличное пространство в базе данных.
CREATE USER Создавать учетную запись/схему пользователя.
ALTER USER Делать изменения в записи/схеме пользователя.
CREATE VIEW Создавать представления в собственной схеме.
SYSDBA Создавать элемент во внешнем файле паролей, если он активирован; выполнять запуск/остановку, изменять базу данных, создавать базу данных, восстанавливать базуд ных, создавать SPFILE и подключаться к базе данных, к она работает в режиме RESTRICTED SESSION.
SYSOPER Создавать элемент во внешнем файле паролей, если он активирован; выполнять запуск/остановку, изменять базу данных, восстанавливать базу данных, создавать SPFIL и подключаться к базе данных, когда она работает в реж ме RESTRICTED SESSION.
Защита и зудит базы данных
379
Представления словаря данных, связанные с системными привилегиями
В таблице 10.8 содержатся представления словаря данных, связанные с системными привилегиями.
Таблица 10.8.
Представления словаря данных, связанные с системными привилегиями
Представление словаря данных Описание
DBA_SYS_PRIVS Системные привилегии, приписанные ролям и пользователям
SESS!ON_PRIVS Все системные привилегии, действующие для этого пользователя в данном сеансе, предоставленные непосредственно или через роли
ROLE_SYS_PRIVS Привилегии текущего сеанса, предоставленные пользователю через роли
Объектные привилегии
В отличие от системных привилегий, объектная привилегия — это право на выполнение определенного типа действий над конкретным объектом (например, над таблицей или последовательностью), который не находится в собственной схеме пользователя. Как для системных привилегий, для предоставления и отзыва привилегий для объектов используются команды grant и revoke соответственно.
Объектные привилегии, и системные, могут быть предоставлены • PUBLIC, и пользователь с объектной привилегией может передать ее другим, используя для этого фразу with grant option.
Пользователь, в схеме которого имеются объекты, автоматически получает все объектные привилегии для этих объектов и может передать любую объектную привилегию любому пользователю или роли с фразой with grant option или без нее.
В таблице 10.9 перечисляются объектные привилегии, доступные для различных типов объектов; некоторые привилегии применимы только Для определенных типов объектов. Например, привилегия INSERT имеет смысл только для таблиц, представлений и материализованных представлений; с другой стороны, привилегия EXECUTE применима только к функциям, процедурам и пакетам, ио не к таблицам.
Привилегии DELETE, UPDATE и INSERT нельзя предоставить материализованным представлениям, если только они не являются обновляемыми. Некоторые из этих объектных представлений перекрываются с системными представлениями; если у пользователя нет объектной привилегии FLASHBACK для таблицы, он, тем не менее, может выполнять ретроспективные запросы, если у него есть системная привилегия flashback any table.
380
Гпава iq
Объектные привилегии
Таблица 10.9.
Объектная привилегия Возможности
ALTER Можно изменять определение таблицы или последовательности.
DELETE Можно удалять строки из таблицы, представления или материализованного представления.
EXECUTE Можно выполнять процедуру или функцию (автономные или в составе пакета)
DEBUG Разрешено просматривать код PL/SQL в триггерах, определенных для таблицы или для операторов SQL, ссылающихся на таблицу. Для объектных типов эта привилегия позволяет обращаться ко всем публичным и приватным переменным, методам иъипам, определенным для объектного типа.
FLASHBACK Допускает ретроспективные запросы к таблицам, представлениям и материализованным представлениям, используя сохраненную информацию для отката.
INDEX Можно создавать индекс для таблицы.
INSERT Можно вставлять строки в таблицу, представление или материализованное представление.
ON COMMIT REFRESH Можно создавать на базе таблицы материализованные представления типа "обновить при фиксации” (refresh-on-commit).
QUERY REWRITE Можно создавать материализованные представления на базе таблицы для переписывания запроса.
READ Можно читать содержимое каталога операционной системы, используя определение Oracle DlKECTORY.
REFERENCES Можно создавать ограничение внешнего ключа, которое ссылается на первичный или уникальный ключ другой таблицы.
SELECT Можно читать строки из таблицы, представления или материализованного представления в дополнение к чтению текущего или следующего значения последовательности.
UNDER Можно создавать представление на базе существующего представления.
UPDATE Можно обновлять строки в таблице, представлении или материализованном представлении.
WRITE Можно записывать информацию в каталог операционной системы, используя определение Oracle DIRECTORY. t
В следующем примере АБД предоставляет пользователю SCOTT по ный доступ к таблице HR.EMPLOYEES, но при этом разрешает ему пер давать другим пользователям только объектную привилегию SELEC
□ SQL> grant insert, update, delete on Grant succeeded.
SQL> grant select on hr.employees to Grant succeeded.
hr.employees to scott;
scott with grant option;
ЗаШита и аУДит базы данных
381
Если привилегия SELECT на таблицу HR.EMPLOYEES будет отозвана у пользователя SCOTT, она будет отозвана и у всех пользователей, которым он предоставил эту привилегию.
Табличные привилегии
Типы привилегий, которые могут быть предоставлены для таблиц, делятся на две категории: операции DML и DDL. К операциям DML относятся delete, insert, select и update, в то время как операции DDL включают в себя операции добавления, удаления и изменения столбцов таблицы, а также создание индекса для таблицы.
При предоставлении операций DML над таблицей, возможно ограничить эти операции только определенными столбцами. Например, можно пожелать разрешить пользователю SCOTT видеть и обновлять все строки и столбцы таблицы HR.EMPLOYEES за исключением столбца SALARY. Для этого сначала требуется отозвать привилегию UPDATE для этой таблицы:
□ SQL> revoke update on hr.employees" from scott;
Revoke succeeded.
Теперь нужно сделать так, чтобы SCOTT мог обновлять все столбцы таблицы за исключением столбца SALARY:
□ SQL> grant update (employee_id, first_name, last.name, email,
2 phone_number, hire_date, job_id, commission_pct,
3 manager_id, department-id)
4 on hr.employees to scott;
Grant succeeded.
Теперь SCOTT имеет возможность обновлять все столбцы таблицы HR.EMPLOYEES за исключением столбца SALARY:
□ SQl_> update hr. employees set first_name = ‘Stephen’ where employee.id = 100;
1 row updated.
SQL> update hr.employees set salary = 50000 where employee_id = 203;
update hr.employees set salary = 50000 where employee_id = 203 *
ERROR at line 1:
0RA-01031: insufficient privileges
(ОШИБКА в строке 1:
ORA-0 031: недостаточно привилегий)
Эту операцию легко выполнить, также с помощью работающего через Web инструментального средства OEM (см. рис. 10.5).
Привилегии на представления
Привилегии на представления похожи на привилегии, предоставляемые Для таблиц. Строки представления можно просматривать, обновлять, удалять или вставлять, конечно, в предположении, что представление яв-
382
Глава !q
3 Add Table CotnmnpbjeciPrWkgcs * Mlcroeoff Jnlgrj^jwplar'er
Fde Edit Viev> Favorites Too.s Hefc>
&
z Search Favorites
htto7/l 92-163.2.169:5500/enVconsde/ddtabase/security/u5fff>taryet«dv/.world8dtype««orade_database8£ancellJPL«/em/cc V
I OfPr'vCUe Enterprise ГЛапауег 1U<?
I OaUbaae Gmtnil
Cw? abase dtr/wrid > IhMfcs > Edit User; SCOTT
Add Table Column Object Privileges
* Select Column Objects ihremployeesemployeejd. hr employees first_name.
hr employees last_name, hr.employees.email hr employees phone_number,
’hr employees.hire_date, hr employeesjobjd,
A
(Schem’irvne CdutnrNwre,.. i
Select object choose orMe/je? Ю fcsskjn
Available Privileges
1 (INSERT
REFERENCES
Selected Privileges
UPDATE
Move ал
QarrtpyA
i i
i
Рис. 10.5. Предоставление привилегий над столбцами в Oracle Enterprise Manager
ляется обновляемым. Для создания представления необходимо сначала иметь системную привилегию CREATE ANY VIEW (для создания представления в любой схеме). Но даже для создания этого представления необходимо также иметь, по крайней мере, объектные привилегии SELECT на все базовые для этого представления таблицы, а также привилегии INSERT, UPDATE и DELETE, если требуется выполнять над представлением эти операции, а представление является обновляемым. Если базовые таблицы представления не входят в вашу схему, необходимо иметь привилегии SELECT ANY TABLE, INSERT ANY TABLE, UPDATE ANY TABLE или DELETE ANY TABLE.
Чтобы позволить другим использовать ваше представление, необходимо, как и в предыдущем случае, иметь на базовые для представления таблицы привилегии с опцией ADMIN. Например, если создается пред ставление для таблицы HR.EMPLOYEES, необходимо предоставить объ ектную привилегию SELECT на таблицу HR.EMPLOYEES с фразой Т GRANT OPTION иметь системную привилегию SELECT ANY TAB с фразой WITH ADMIN OPTION.
Привилегии на процедуры
Для процедур, функций и пакетов, содержащих процедуры и фУнК ции, привилегия EXECUTE является единственной применимой об'Ь ектной привилегией. Начиная с Огас1е8г, процедуры и функции мог/1* выполняться либо с точки зрения их владельца (definer) — т. е. того,
дащита и аудит базы данных
383
кто создал эту процедуру или функцию, или с точки зренгия вызывающего (invoker), т. е. пользователя, который выполняет процедуру или функцию.
Процедура с правами владельца выполняется так, как будто бы ее выполняет сам ее создатель, т. е. со всеми теми правами и привилегиями, которыми обладает создатель относительно объектов, на которые делаются ссылки в процедуре. Это хороший способ введения принудительных ограничений на приватные объекты базы данных: остальным пользователям предлагается привилегия EXECUTE на процедуру, но не предоставляется никаких прав на все ссылочные объекты. В результате владелец может контролировать то, как другие пользователи обращаются к объектам.
Процедура с правами вызывающего требует, чтобы вызывающий процедуру пользователь имел прямые права (например, SELECT или UPDATE) на любые объекты, на которые в процедуре есть ссылки. Процедура может ссылаться на неквалифицированную таблицу с именем ORDERS, и если у всех пользователей базы данных есть таблица с таким именем, то одна и та же процедура (без каких бы то пи было изменений. — Прим, пер.) может быть использована любым пользователем, у которого также есть таблица ORDERS. Еще одно преимущество применения процедур с правами вызывающего состоит в том, что в них разрешены роли (подробнее о ролях см. ниже в данной главе).
По умолчанию процедура создается с правами владельца. Чтобы указать, что процедура использует права вызывающего, необходимо включить в определение процедуры ключевые слова authid current_user:
П create or replace procedure process_orders (order_batch_date date) authid current_user as begin
-- обработка таблицы ORDERS пользователя с использованием прав вызывающего,
-- все роли остаются в силе end;
Для создания процедуры пользователь должен иметь системную привилегию CREATE PROCEDURE или CREATE ANY PROCEDURE. Для корректной компиляции процедуры пользователь должен иметь прямые привилегии на все объекты, на которые в теле процедуры имеются ссылки, даже в тех случаях, когда в процедуре с правами вызывающего разрешены роли времени исполнения, предоставляющие те же самые привилегии. Для разрешения другим пользователям обращаться к процедуре необходимо предоставить им привилегию EXECUTE на процедуру или пакет.
Представления словаря данных, связанные с объектными привилегиями
Информация об объектных привилегиях, предоставляемых пользовате-лям, содержится в целом ряде представлений словаря данных. В таблице 10.10 перечисляются наиболее важные представления словаря данных, содержащие информацию об объектных привилегиях.
384
Гпава !q
Таблица 10.10. Представления словаря данных, связанные с объектными
привилегиями
Представление словаря данных Описание
DBA_TAB_PRIVS
DBA_COL_PRIVS
SESSION.PRIVS
ROLE_TABS_PRIVS
Привилегии на таблицы, предоставляемые ролям и пользователям. Включена информация о пользователе, предоставившем эту привилегию роли или пользователю с опцией WITH GRANT OPTION или без нее.
Привилегии на столбцы, предоставленные ролям или пользователям, а также имена столбцов и типы привилегий для них.
Все действующие в текущем сеансе для этого пользователя системные привилегии, предоставленные как непосредственно, так и через роли.
Для текущего сеанса — привилегии над таблицами, предоставленные через роли.
Создание, назначение и обслуживание ролей
Ролью называется именованная группа привилегий — системных или объектных (или их комбинации), помогающая облегчить администрирование привилегий. Вместо того чтобы предоставлять системные или объектные привилегии непосредственно каждому пользователю, можно предоставить группу привилегий (системных или объектных) роли, а затем предоставлять пользователям эту роль. Это чрезвычайно сокращает размер “накладных расходов”, связанных с обслуживанием привилегий пользователей. На рис. 10.6 показано, как использование ролей может сократить число команд grant (в конечном счете, и команд revoke), которые должны быть выполнены, когда вместо привилегий используются роли.
Если для группы лиц необходимо изменить привилегии, авторизованные через роли, то фактическому изменению необходимо подвергнуть только предоставляемые роли привилегии, после чего все пользователи, которым была назначена эта роль будут автоматически использовать все новые или изменившиеся привилегии. Роли для пользователя могут селективно активироваться и отключаться; некоторые роли для пользова теля могут автоматически включаться при его входе в систему. Kpo*ie того, для защиты роли может быть использован пароль, что добавляет еще один уровень аутентификации к возможностям базы данных.
В таблице 10.11 перечислены наиболее распространенные роли,авТ^ матически предоставляемые базой данных, а также краткое описани привилегий, которые приобретаются вместе с каждой из них.
Роли CONNECT, RESOURCE и DBA предоставляются, в основном, ДЛ обеспечения совместимости с предыдущими версиями Oracle; в нов ' версиях Oracle они могут перестать существовать. Используя привил гии, предоставляемые этими ролями в качестве отправной точки, аД^ нистратор базы данных может создавать так называемые “заказнЫе роли, отвечающие требованиям конкретных групп пользователей.
дащита и аудит базы данных
385
Назначение привилегий без ролей
Пользователи
Назначение привилегий с использованием ролей
Пользователи
Привилегии
Рис. 10.6. Использование ролен для управления привилегиями
Создание и удаление ролей
Для создания роли используется команда create role, и для ее применения необходимо иметь системную привилегию CREATE ROLE. Обычно эта роль предоставляется только администраторам базы данных или приложений:
П SQL> create role hr_admin not identified;
Role created.
По умолчанию для назначаемой роли не требуется активировать пароль или аутентификацию, поэтому фраза not identified не является обязательной.
386
г
1Q
Таблица 10.11. Предварительно определенные роли Oracle
Название роли
CONNECT
RESOURCE
DBA
DELETE_CATALOG_ROLE
EXECUTE_CATALOG_ROLE
SELECT_CATALOG_ROLE
EXP_FULL_DATABASE
IMP_FULL_DATABASE
AQ_USER_ROLE
AQ_ADMINISTRATOR_ROLE
SNMPAGENT
RECOVERY_CATALOG_OWNER
HS_ADMIN_ROLE
SCHEDULER_ADMIN
Привилегии__________________________________ ‘
ALTER SESSION, CREATE CLUSTER, CREATE DATABAsT^ LINK, CREATE SEQUENCE, CREATE SESSION, CREATE SYNONYM, CREATE TABLE, CREATE VIEW. Это типовой и бор привилегий, предоставляемых обычному пользова-' телю базы данных, который позволяет им подключаться к базе данных и создавать в ней таблицы, индексы и представления.
CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE ’ CREATE TRIGGER, CREATE TYPE. Этот набор привилегий * обычно используется для разработчиков приложений, которые могут кодировать процедуры и функции PL/SQL.
Все системные привилегии с опцией WITH ADMIN OPTION. Позволяет лицу с ролью DBA предоставлять системные привилегии другим пользователям.
Не обладает никакими системными привилегиями, а всего лишь объектными привилегиями на удаление (DELETE) таблиц SYS.AUD$ и FGA_LOG$. Другими словами, эта роль позволяет пользователю удалять записи аудита (для обычного или детального аудита) из журнала аудита (audit trail).
Привилегии на выполнение для различных системных пакетов, процедур и функций, например DBMS.FGA и DBMS-RLS.
Объектные привилегии SELECT для 1638 таблиц словаря
данных.
EXECUTE_CATALOG_ROLE, SELECT_CATALOG_ROLE и системные привилегии типа BACKUP ANY TABLE и RESUMABLE. Пользователи с этой ролью имеют возможность экспортировать все объекты базы данных. Аналогична роли EXP_FULL_DATABASE, но с гораздо большим количеством системных привилегий, наприм Р CREATE ANY TABLE; позволяет выполнить импорт ране экспортированной полной базы данных.
Выполняет доступ к программным единицам, необход мым для Advanced Queuing, например к DBMS-AQ-
I
Диспетчер для очередей в Advanced Queuing. Используется интеллектуальным агентом (Intelligen Agent) интерфейса Enterprise Manager. I
Используется для создания пользователя, владею^^ каталогом восстановления для резервного копир и восстановления RMAN. $
Обеспечивает доступ к таблицам HS_* и пакету HS для администрирования гетерогенных серви Oracle (Oracle Heterogeneous Services). таК.
Обеспечивает доступ к пакету DBMS_SCHEDULER> же привилегии для создания пакетных заданшт^
и аудит базы данных
387
Как и при создании пользователей, можно авторизовать использование роли паролем (авторизация базой данных с помощью фразы identified Ъу пароль), операционной системой (identified externally), или в сети или с помощью службы каталога (identified globally).
Помимо этих известных методов можно активировать роль с помощью пакета: этот способ известен как защищенная роль приложения (secure application role). Такой тип роли использует для своей активации процедуру из пакета. Обычно роль активируется при выполнении некоторого условия (или условий): пользователь подключается через web-интерфейс или через конкретный IP-адрес, или же подключение происходит в определенное время суток. Ниже приводится пример роли, которая активируется с использованием процедуры:
SQL> create role hr_clerk identified using hr_clerk_verif;
Role created.
В момент создания роли процедура HR_CLERK_VERIF может не существовать; однако ее надо скомпилировать, и она должна быть действительной в тот момент, когда пользователь, которому предоставлена эта роль, захочет ее активировать. Обычно в случае защищенной роли приложения эта роль не активируется для пользователя по умолчанию. Чтобы указать, что по умолчанию активируются все роли, за исключением защищенных ролей приложения, используется следующая команда:
SQL> alter user wgietz default role all except hr_clerk;
User altered.
Таким образом, при запуске приложения HR можно активизировать роль, выполнив команду set role hr_clerk и тем самым вызвав процедуру HR.CLERK_VERIF. Пользователю не нужно ничего знать о роли или о процедуре, активирующей эту роль; следовательно, никакой доступ к объектам и привилегиям, предоставляемым ролью для пользователей, за пределами приложения невозможен.
Удаление роли нисколько не сложнее ее создания:
SQL> drop role keypunch_operator;
Role dropped.
Любой пользователь, приписанный к этой роли, при следующем своем подключении к базе данных будет лишен привилегий, ассоциированьях с удаленной ролью. Если в момент выполнения команды пользова-ель зарегистрирован в базе данных, привилегии останутся за ними до момента их отключения.
Предоставление привилегий ролям
л^азначить привилегии ролям очень просто: команда grant используется я назначения роли привилегии, точно так же, как если бы назначалась ривилегия пользователю:
$QL> grant select on hr.employees to hr clerk;
rant succeeded.
grant create trigger to hr_clerk;
brant succeeded.
388
I
Гпава jq
Ed* View Favorites tools Help
Search Favorites- Media /p
Back
Ж
\ Mtp77l92.168*2469:55<;0/ern/consote/databa$e/$ecurity/ro!e?tdrQet»dv;.v*o(ideJ:ype*cor3ce_d4tdb55e&Cdncel5^l=«/em/co( v
OPACL.G Enterprise Manager 10р О НъЬгож Сшгло!
S&p E?tff^£]0b Jjgte косим
OtUbait
J
UWAi-HS»?- Фу >¥#!•* > Role^ > Edit Role: HR_CLERK
Modify System Privileges
Legged in A?.
Available System Privileges
^рШе АТТУ S^IENCE^"^ ГCREATE ANY SQL PROFILE
CREATE ANY TABLE
CREATE ANY TRIGGER
CREATE ANY TYPE
CREATE ANY VIEW
CREATE CLUSTER iCREATE DATABASE LINK ^CREATE DIMENSION
.CREATE EVALUATION CONTEXT
Selected System Privilege
CREATE TRIGGER
Move Al!
R^mr-vs
«
R$rno/e All
i
V
Database | Setop | Preferences | Нек I Logout
Рис. 10.7. Предоставление привилегий ролям с помощью OEM
Cancel}
В этом примере роли HR_CLERK были назначены одна объектная и одна системная привилегии. На экране, изображенном на рис. 10.7, можно использовать OEM, приспособленный к работе в Web, для добавления роли дополнительных объектов или системных привилегий.
Назначение и отзыв ролей
После приписания роли нужных системных и объектных привилегии можно назначить эту роль пользователю, используя для этого вполне аналогичный синтаксис:
□ SQL> grant hr_clerk to smavris;-
Grant succeeded.
HR
Любые другие привилегии, впоследствии добавленные к роли п -CLERK, могут быть автоматически использованы пользовател SMAVRIS, так как ему была предоставлена эта роль.
Роли могут быть предоставлены другим ролям, что позволяет иметь иерархию ролей и еще более упрощает их администрирован Так, например, можно иметь роли DEPT30, DEPT50 и DEPT100, при4 , каждая из них содержит объектные привилегии на 1 владеют соогг значена роль DEPT30 и т. д. Президент компании хочет ность просматривать таблицы всех отделов; но, вместо того сваивать индивидуальные объектные привилегии роли S можно присвоить роли ALL_DEPTS индивидуальные роли отделов:
администрирование-' и DEPT100, приче-'гяб ЯИПЫ КОТОрН
ветствующие отделы. Служащему отдела 30 должна и чтобы пр? all_depTs’
дащита и аудит базы данных 389
□ SQL> create role all_depts;
Role created.
SQL> grant dept30, dept50, deptlOO to all_depts;
Grant succeeded.
SQL> grant all_depts to sking;
Grant succeeded.
В роль ALLJDEPTS можно также включить и индивидуальные системные и объектные привилегии, которые не могут быть применимы к индивидуальным отделам, например объектные привилегии для таблиц для ввода заказов или дебиторской задолженности.
Отзыв роли у пользователя очень похож на отзыв привилегий у пользователя:
□ SQL> revoke all_depts from sking;
Revoke succeeded.
Отозванные роли более не будут доступны для пользователя, когда он в следующий раз захочет подключиться к базе данных. Однако следует отметить, что, если привилегии над теми же самыми объектами, что и у удаленной роли, содержатся в другой роли или предоставлены пользователю явно, пользователь сможет продолжить пользоваться ими до тех пор, пока эти предоставления привилегий не будут явно отозваны.
Роли по умолчанию
По умолчанию при подключении пользователя к базе данных активируются все предоставленные ему роли. Если предполагается использовать какую-то роль только в контексте приложения, то при регистрации пользователя роль может стартовать как заблокированная; впоследствии она может быть активирована и снова заблокирована уже в приложении. Если у пользователя SCOTT есть роли CONNECT, RESOURCE, HR_ CLERK и DEPT30 и мы хотим указать, что роли HR_CLERK и DEPT30 не Должны быть активированы по умолчанию, можно использовать нечто типа следующей конструкции:
SQL> alter user scott default role all
2 except hr_clerk, dept30;
User altered.
Когда SCOTT подключается к базе данных, он автоматически обладает всеми привилегиями, предоставленными ему всеми ролями, кроме ролей
—CLERK и DEPT30. Пользователь SCOTT может явно активировать роль в сеансе, используя команду set role:
SQL> set role dept30;
Role set.
Когда доступ к таблицам отдела 30 перестанет быть ему нужным, он мо-^ст заблокировать эту роль в сеансе:
set role all except dept30;
Role set.
390
Гпава iq
Примечание Параметр инициализации MAX_ENABLED_ROL.ES не рекомендован для использования в Oracle 10g. Он оставлен исключительно для обеспечения совместимости с предыдущими версиями.
Роли с паролями
Для активации защиты в базе данных АБД может назначить при создании роли пароль:
□ SQL> create role dept99 identified by d99secretpw;
Role created.
SQL> grant dept99 to scott;
Grant succeeded.
SQL> alter user scott default role all except hr_clerk, dept30, dept99;
User altered.
Когда пользователь SCOTT подключается к базе данных, приложение, которое он использует, предложит ему ввести пароль, либо он сам введет этот пароль, когда будет активировать роль:
□ SQL> set role dept99 identified by d99secretpw;
Role set.
Представления словаря данных, связанные с ролями
Таблица 10.12. Представления словаря данных, связанные с ролями
Представление словаря Описание
данных
DBA_ROLES DBA_ROLE_PRIVS ROLE_ROLE_PRIVS ROLE_SYS_PRIVS ROLE_TAB_PRIVS
SESSION_ROLES
Все роли с указанием, требуется ли для них пароль.
Роли, предоставленные пользователям или другим ролям.
Роли, предоставленные другим ролям.
Системные привилегии, предоставленные ролям.
Привилегии над таблицами и отдельными столбцами, предоставленные ролям.
Роли, действующие для сеанса в настоящий момент. Применимы для сеансов каждого пользователя.
Представление DBA__ROLE_JPRIVS — это хороший способ выясн^^ какие роли предоставлены пользователю, а также узнать, может ли редавать их другим пользователям (ADMIN_OPTION) и является л роль активированной по умолчанию (DEFAULT_ROLE):
□ SQL> select * from dba_role_privs
2 where grantee = ‘SCOTT’;
GRANTEE GRANTED_ROLE ADMIN_OPTION DEFAULT_ROLE
SCOTT DEPT30 NO NO пгптсп NO Yes
Защита и аудит базы данных
391
SCOTT DEPT99 NO YES
SCOTT CONNECT NO YES
SCOTT HR_CLERK NO NO
SCOTT RESOURCE NO YES
SCOTT ALL_DEPTS NO YES
SCOTT DELETE CATALOG ROLE NO YES
8 rows selected.
Можем также найти, какие роли приписаны роли ALLJDEPTS: □ SQL> select * from dba_role_privs
2 where grantee = ‘ALL.DEPTS’;
GRANTEE GRANTED_ROLE ADMIN_OPTION DEFAULT.ROLE
ALL_DEPTS
ALL_DEPTS
ALL_DEPTS
DEPT30
DEPT50
DEPT1OO
NO YES
NO YES
NO YES
3 rows selected.
Для получения этой информации можно также использовать представление словаря данных ROLE_ROLE_PRIVS; оно содержит только информацию о ролях, приписанных ролям, и не содержит информации DEFAULT_ROLE.
Чтобы найти привилегии, предоставленные пользователям для таблиц и столбцов таблиц, можно составить два запроса: один для выборки привилегий, предоставленных непосредственно, и второй — для выборки привилегий, предоставляемых через роли. Выборка непосредственно назначаемых привилегий очевидна:
О SQL> select dtp.grantee, dtp.owner, dtp.table-name,
2 dtp.grantor, dtp.privilege, dtp.grantable
3 from dba-tab-privs dtp
4 where dtp.grantee = ‘SCOTT’;
GRANTEE OWNER TABLE_NAME GRANTOR PRIVILEGE GRANTABLE
SCOTT HR EMPLOYEES HR SELECT YES
SCOTT HR EMPLOYEES HR DELETE NO
SCOTT HR EMPLOYEES HR INSERT NO
3 rows selected.
Для выборки табличных привилегий, предоставляемых через роли, необходимо соединить DBA_ROLE_PRIVS и ROLE_TAB_PRIVS. Ь DBA-ROLE-PRIVS содержатся" роли, приписанные пользователю, а в ROLE_TAB_PRIVS — привилегии, приписанные ролям:
$QL> select drp.grantee, rtp.owner, rtp.table_name,
2 rtp.privilege,rtp.grantable, rtp.role
3 from role tab_privs rtp
392
Глава 1q
4 join dba_role_privs drp on rtp.role = drp.granted_role
5 where drp.grantee = ‘SCOTT’;
К GRANTEE OWNER TABLE_NAME PRIVILEGE GRANTABLE ROLE
SCOTT HR EMPLOYEES SELECT NO HR.CLERK
SCOTT HR JOBS SELECT NO JOB.MAINT
SCOTT HR JOBS UPDATE NO JOB_MAINT
SCOTT SYS AUD$ DELETE NO DELETE_CATALOG_ROLE
SCOTT SYS FGA.LOGS DELETE NO DELETE_CATALOG_ROLE
5 rows selected.
Следует обратить внимание на то, что у пользователя SCOTT есть привилегия SELECT на таблицу HR.EMPLOYEES как через прямую команду grant, так и через роль. Отзыв только одной из привилегий оставит в силе его право доступа к этой таблице до тех пор, пока не будет отозвана и вторая привилегия.
Использование VPD для реализации правил разграничения доступа в приложении (Application Security Policies)
Виртуальная приватная база данных (VPD) объединяет принудительно применяемый на сервере детальный контроль доступа с защищенным контекстом приложения. Имеющие возможности для работы с контекстом функции возвращают предикат — фразу where, который автоматически присоединяется в конец оператора select или других операторов DML. Другими словами, оператор select для таблицы, представления или синонима, которые контролируются VPD, возвратит подмножество строк, базирующееся на фразе where. Эта фраза автоматически генерируется функцией политики безопасности, действующей для контекста приложения. Главным компонентом VPD является Row Level Security (безопасность на уровне строк — RLS), известный также как детальный контроль доступа (Fine-Grained Access Control — FGAC).
Поскольку VPD прозрачно генерирует предикаты во время синтакси ческой разборки операторов, политика защиты последовательно ф°Рс1* руется безотносительно того, выполняет ли пользователь нерегламенти рованные запросы, выбирая данные из приложения, или просматрива ? данные с помощью Oracle Forms. Поскольку сервер Oracle примени предикат к оператору на стадии грамматического разбора, для РеаЛЙ ции политики приложению не требуется использовать специаль таблицы, представления и тому подобное. В результате Oracle может тимизировать запрос, применяя индексы, материализованные nP^S Qll ления и параллельные операции там, где в противном случае (без Vr не смог бы этого сделать. Следовательно, применение VPD может пр ти к снижению накладных расходов по сравнению с запросами, резг ты которых фильтруются с помощью средств приложения или как-то другому. с
С точки зрения обслуживания политика защиты может быть опред на внутри функции правил, которую трудно создать, используя р0^
-1
Oracle может 0
и аудит базы данных
393
1
привилегии. Провайдеру приложений (Application Server Provider —ASP) может потребоваться создать для обслуживания нескольких заказчиков одного и того же приложения только одну базу данных, использующую стратегию VPD для гарантированного обеспечения того, что служащие каждого из заказчиков могут видеть только собственные данные. АБД могут обслуживать одну большую базу данных с несколькими стратегиями VPD, вместо того чтобы заводить индивидуальную базу данных для каждого заказчика.
Новинкой Oracle 10gявляются операции VPD на уровне столбцов. Используя “столбцовые” VPD, АБД может ограничивать доступ к конкретным столбцам базы данных. Запрос возвращает то же самое количество строк, но если контекст пользователя не разрешает доступ к столбцу (или столбцам), то для этого столбца (столбцов) будут возвращены пустые (NULL) значения.
Стратегии VPD могут быть статическими, контекстно-чувствительными или динамическими. Статические и контекстно-чувствительные стратегии — это новинки в Oracle 10g, они могут заметно повысить производительность, так как им не требуется вызывать соответствующую функцию правил при каждом выполнении запроса, потому что она кэшируется для последующего использования сеансом. До Oracle 10g все стратегии были динамическими; другими словами, функция правил выполнялась каждый раз при разборе оператора SQL, содержащего целевую таблицу SQL. Статические стратегии вычисляются один раз при входе в систему и остаются кэшированными на протяжении всего сеанса безотносительно контекста приложения. Для контекстно-чувствительных стратегий функция правил вызывается во время грамматического разбора оператора, если изменяется контекст приложения, например стратегия, когда принудительно проводится в жизнь бизнес-правило “служащие видят статистические данные только о своей заработной плате, но менеджеры могут видеть все обо всех сотрудниках”. Если запрос выполняет тот же служащий, нет необходимости еще раз выполнять функцию правил, что уменьшает потери времени, связанные с принудительным проведением стратегии VPD.
Контекст приложения создается при помощи команды create context, а пакет DBMS_RLS управляет стратегиями VPD. Функция, используемая для возврата предикатов для принудительного выполнения стратегии, создается точно так же, как и другие функции, с тем исключением, что у функции есть два обязательных параметра и она возвращает значение типа VARCHAR2. Ниже в данной главе эти функции рассматриваются более детально и описывается каждый шаг примера VPD; при этом используется демонстрационные схемы, предлагаемые при инсталляции базы Данных Oracle.
Контекст приложения
С помощью команды create context можно создать имя определенных Приложением атрибутов, которые‘будут использованы для принудительного применения стратегии защиты, а также имени пакета для функций И процедур, используемых для установки контекста защиты сеанса пользователя:
394
Гпава iq
□ create context hr_security using vpd.emp_access;
create or replace package emp_access as procedure set_security_parameters;
end;
В этом примере контекст называется HR_SECURITY, а используемый для задания характеристик или атрибутов пользователя во время сеанса пакет — EMP_ACCESS. В триггере входа в систему (logon trigger) бу. дет вызвана процедура SET_SECURITY_PARAMETERS. Так как контекст HR_SECURITY привязан только к EMP_ACCESS, никакие другие процедуры не могут изменить атрибуты сеанса. Это обеспечивает защищенный контекст приложения, который после подключения к базе данных не может быть изменен пользователем или любым другим процессом.
В типичном пакете, используемом при реализации контекста приложения, для выборки информации о самом сеансе применяется встроенный контекст USERENV. В таблице 10.13 перечисляются некоторые из наиболее распространенных параметров в контексте USERENV.
Таблица 10.13. Часто используемые параметры контекста USERENV
Параметр
Возвращаемое значение
CURRENT-SCHEMA
DB_NAME
HOST IP_ADDRESS OS_USER
SESSION-USER
Используемая по умолчанию схема сеанса
Имя базы данных, специфицированное в параметре DB.NAME
Имя хост-машины, с которой подключился пользователь
Адрес IP, с которого подключился пользователь
Учетная запись операционной системы, инициировавшая сеанс базы данных
Имя аутентифицированного пользователя базы данных
Следующие вызовы SYS_CONTEXT обеспечат выборку имени пользо-вателя и IP_ADDRESS сеанса базы данных:
□ declare
username varchar2 (30);
ip_addr varchar2 (30);
begin
username := SYS_CONTEXT(‘USERENV’, ‘SESSION_USER’);
ip_addr := SYS_CONTEXT(‘USERENV’, ‘ IP_ADDRESS’);
-- далее следует конкретная обработка end;
Функция SYS-CONTEXT легко может быть использована и вну^Р SQL-оператора select:
□ SQL> select SYS_CONTEXT(‘USERENV’, ’SESSION_USER’) username from dual'
USERNAME
Защита и аудит базы данных
395
Используя некоторые комбинации контекста USERENV и информацию авторизации из базы данных, можно применить DBMS_SESSION_ SET_CONTEXT для назначения значений параметрам в созданном нами контексте приложения:
□ dbms.session,set. context (‘HR SECURITY’, ‘SEC_LEVEL’, ‘HIGH’);
В этом примере переменная контекста приложения SECJLEVEL устанавливается на HIGH в контексте HR_SECURITY. Значение может быть назначено на основании некоторого количества условий, включая таблицу отображения, которая назначает уровни защиты на основании идентификатора пользователя.
Чтобы быть уверенными в том, что контекстные переменные установлены для каждого сеанса, для вызова процедуры, ассоциированной с контекстом, можно использовать триггер входа в систему. Переменные в контексте могут быть установлены или изменены только внутри назначенного пакета. Ниже приводится пример триггера входа в систему, который вызывает процедуру установки контекста:
□ create or replace trigger vpd.set_security_parameters after logon on database
begin
vpd.emp_access.set_security_parameters;
end;
В этом примере процедура SET_SECURITY_PARAMETERS делает все необходимые вызовы DBMS_SESSION.SET_CONTEXT.
В Oracle Enterprise Manager можно использовать Policy Manager (диспетчер стратегий) для создания контекстов и групп стратегий (см. рис. 10.8).
Реализация стратегии защиты
После создания инфраструктуры для настройки среды защиты на следую-щем шаге определяется функция (функции), используемая для генерации предиката, который будет присоединен к каждому оператору select или команде DML для защищаемых таблиц. У функции, используемой для реализации генерации предикатов, есть два аргумента: владелец подлежащего защите объекта и имя объекта в схеме владельца. Одна функция может выполнять генерацию предикатов только для одного типа операций, например для select, или обрабатывать все возможные команды DML, что зависит от того, как эта функция ассоциирована с защищаемой таблицей.
следующем примере приводится тело пакета, содержащего две функции: одна будет использована для контроля доступа из операторов select, а вторая — для всех остальных команд DML:
create or replace package body get_predicates is
1 - *
function emp_seject_restrict (owner varchar2, object_name varchar2) return varcbar2 is
ret_predicate varchar2 (1000); -- часть фразы WHFRF
396
Г.пава 1Q
(jXJFlne Grained Access Control Policies
Policy groups
&®SYS_DEFAULT
tOApplication contexts
&ODRJAPPCTX
EM_GLOBAL_CONTEXT
S>^ EM_USER_CONTEXT
yr Ш ХЗИГ/** *($>-rrli.otwct
§3 Oracle РоЦру Manager
Bi
KRjSECURriYi
3JOLT..CTX S^REGISTRYSCTX i^WKSCONTEXT 6>OwKSCTX_LDAP
Context name:
General ©gjgt
r»
Browse
ta
/
HR SECURITY
Trusted package name iEMP_ACCESS
•:' % 1
Trusted.package schema/VPD
Access methods
Hf* Accessed locally
Г Accessed globally
У Initialized externally
У initialized globally
w
Рис. 10.8. Диспетчер стратегий Oracle
begin
-- позволяет видеть строки в таблице только определенным пользователям . проверка контекстных переменных и построение предиката
return ret_predicate;
end emp_select_restrict;
function emp_dml_restrict (owner varciiar2, object_name varchar2)
return varchar2 is
ret_predicate varchar2 (1000); -- часть фразы WHERE
begin
-- позволяет делать изменения в таблице только определенным пользователям . проверка контекстных переменных и построение предиката
return ret_predicate;
end emp_dml_restrict;
end; -- тело пакета
о К^0'
Каждая функция возвращает строку, содержащую выражение, рое добавляется к фразе where для оператора select или команды Пользователь приложения никогда не видит значения этой ФР' ? WHERE; она автоматически добавляется к команде на стадии грамма^ rvnrn па.чПопа.
и аудит базы данных
397
Разработчик должен обеспечить, чтобы функция всегда возвращала допустимое выражение. В противном случае любое обращение к защищаемой таблице всегда будет неудачным:
□ SQL> select * from hr.employees;
select * from hr.employees
*
ERROR at line 1:
ORA-28113: policy predicate has error
(ОШИБКА в строке 1:
ORA-28113: в предикате защиты имеется ошибка)
В сообщении об ошибке не говорится о том, каков этот предикат, и все пользователи “отлучаются” от таблицы до тех пор, пока не будет исправлена предикативная функция (о том, как можно отладить предикативную функцию, см. ниже в данной главе).
Применение DBMS_RLS
Встроенный пакет DBMS_RLS содержит некоторое количество подпрограмм, которые АБД могут использовать для обслуживания стратегий защиты, связанных с таблицами, представлениями и синонимами. В таблице 10.14 приведены подпрограммы, имеющие привилегии EXECUTE, предоставленные им для работы с пакетом SYS.DBMS_RLS.
Таблица 10.14. Подпрограммы пакета DBMS_RLS
Подпрограмма
Описание
ADD-POLICY
DROP_POLICY
REFRESH_POLICY
EI\IABLE_POLICY
CREATE-POLICY-GROUP ADD_GROUPED_POLICY ADD_POLICY_CONTEXT DELETE-POLICY-GROUP drop_grouped_policy DROP-POLICY-CONTEXT enable_grouped_policy disable_grouped_policy refresh_grouped_policy
Добавляет к объекту стратегию детального контроля доступа
Удаляет из объекта стратегию детального контроля доступа
Подвергает повторному разбору хранящиеся в кэше операторы, связанные со стратегией
Активирует или блокирует стратегию детального контроля доступа
Создает группу стратегий
Добавляет стратегию в группу стратегий
Добавляет контекст к текущему приложению
Удаляет группу стратегий
Удаляет стратегию из группы стратегий
Удаляет контекст для активного приложения
Активирует группу стратегий
Блокирует группу стратегий
Подвергает повторному разбору все кэшированные операторы, ассоциированные с группой стратегий
398
Гпава iq
Подпрограмма ADD, POLICY имеет следующий синтаксис:
DBMS_RLS ADD_POLICY
object_schema object_name policy_name function_schema policy_function statement-types update_check enable
static,policy policy_type long_predicate sec_relevant_cols sec relevant_cols_opt
);
IN varchar2 null,
IN varchar2,
IN varchar2,
IN varchar2 null,
IN varchar2,
IN varchar2 null,
IN boolean false,
IN boolean true,
IN boolean false,
IN binary_integer null,
IN Boolean false,
IN varchar2,
IN binary_integer null
Некоторые параметры имеют логические (BOOLEAN) значения по умолчанию, а менее часто используемые параметры перенесены в конец списка аргументов. Это в большинстве случае делает более простым для записи и понимания синтаксис, любого конкретного вызова процедуры DBMS_RLS.ADD_POLICY. Описание и применение каждого параметра приводятся в таблице 10.15.
Таблица 10.15. Параметры DBMS_RLSADD_POUCY
Параметр Описание
object-schema Схема, содержащая таблицу, представление или синоним, которые подлежат защите с помощью стратегии. Если это значение установлено на NULL, используется схема пользователя, вызывающего процедуру.
object_name Имя таблицы, представления или синонима, защищаемых этой стратегией.
policy_name Название стратегии, которая будет добавлена к объекту. Оно должно быть уникальным для каждого защищаемого объекта.
function_schema Схема, владеющая функцией правил; если значение установлено на NULL, будет использована схема пользователя, вызывающего процедуру.
policyjunction Имя функции, генерирующей предикат для стратегии относитель но object_name. Если эта функция является частью пакета, то здесь же должно быть специфицировано и имя паке га дл ва фикации имени функции правил.
statementJypes Типы операторов, к которым применима функция правил. Дс п тимыми значениями для этого параметра являются любые нации операторов SELECT, INSERT, UPDATE, DELETE и INDEX, P деленных запятыми. По умолчанию применяемыми считаются в типы за исключением INDEX.
даШита и аУДит базы данных
399
Таблица 10.15. (Продолжение)
Параметр Описание
update_check Для типов INSERT и UPDATE этот параметр является необязательным и по умолчанию принимает значение FALSE. Если он установлен на TRUE, стратегия также проверяется для операторов INSERT и UPDATE при проверке операций SELECT или DELETE.
enable Этот параметр по умолчанию устанавливается на TRUE и указывает, будет ли стратегия активирована непосредственно после своего добавления.
static_policy Если этот параметр равен TRUE, стратегия продуцирует одну и ту же строку предиката для любого пользователя, пытающегося обратиться к объекту, за исключением пользователя SYS или любого пользователя с привилегией EXEMPT ACCESS POLICY. Значение по умолчанию FALSE.
policyjype Если значение этого параметра не пустое (not NULL), перекрывается параметр static_policy. Разрешенными значениями этого параметра являются STATIC, SHARED-STATIC, CONTEXT-SENSITIVE, SHARED_CONTEXT_SENSITIVE и DYNAMIC.
long_predicate По умолчанию устанавливается на FALSE. Если задано значение TRUE, строка предиката может иметь длину до 32 Кбайт. В противном случае длина строки предиката не должна превышать 4000 байт.
sec_relevant_cols Форсирует VPD на уровне отдельных столбцов. Параметр впервые появился в Oracle 10g. Применим только к таблицам и представлениям. Защищаемые столбцы перечисляются в списке. В качестве разделителей используются запятые или пробелы. Стратегия применяется только в том случае, если указанные чувствительные столбцы присутствуют в запросе или в операторе DML. По умолчанию защищены все столбцы.
sec_relevant_cols_opt В результирующем множестве (result set) отфильтрованного на уровне строк запроса VPD разрешено появляться строкам, где вместо чувствительных столбцов возвращаются пустые (NULL) значения. Значение по умолчанию NULL; в противном случае необходимо задать DBMS_RLS.ALL_ROWS, чтобы показать все столбцы со значениями NULL для чувствительных столбцов.
Использование параметра sec_relevant_cols удобно, когда АБД не возражает, чтобы пользователи видели часть строки за исключением столбцов, которые могут содержать конфиденциальную информацию типа номера карты системы социального обеспечения или зарплаты служащего. В примере, который будет приведен ниже в данной главе, будет построена первая стратегия защиты, определенная для фильтрации уязвимых Данных для большинства служащих компании.
В следующем примере к таблице HR.EMPLOYEES применяется стратегия EMP_SELECT_RESTRICT. Схема VPD владеет функцией правил get predicates.emp__s slect_restrict. Эта стратегия явно применяется к операторам SELECT для таблицы; но, если параметр UPDATE CHECK установ
400
Гпава iq
лен на TRUE, команды update или delete будут также проверяться, когда в таблицу вставляются или обновляются строки.
□ dbms.rls.add_policy ( object_schema => ‘HR’,
object_name => ‘EMPLOYEES’,
policy_name => ‘ EMP_SELECT_RESTRICT’,
function_schema => ‘VPD’, policy_function => ‘get_predicates.emp_select_restrict’, statement-types => ‘SELECT’, update_check => TRUE,
enable => TRUE
);
Поскольку не было задано значение static_policy, по умолчанию этот параметр принимает значение FALSE; это означает, что стратегия является динамической и что она будет проверяться при каждом разборе оператора select. До появления Oracle 10£такая стратегия была единственно возможной.
Использование подпрограммы ENABLE_POLICY является самым легким способом временной блокировки стратегии, при котором не требуется впоследствии заново связывать стратегию с таблицей:
□ dbms_rls.enable_policy (
object schema => ‘HR’,
object_name => ‘EMPLOYEES’,
policy.name => ‘EMP_SELECT_RESTRICT’,
enable => FALSE
);
Если для одного объекта специфицированы несколько стратегий, между каждым предикатом вставляется условие AND. Если при наличии нескольких стратегий между предикатами требуется вставить условие OR, то, скорее всего, придется пересмотреть стратегии. Логика для каждой стратегии должна быть объединена в одну общую стратегию, в которой между каждой частью предиката имеется условие OR.
Создание VPD
В этом разделе показан весь путь реализации VPD. Пример базируется на демонстрационной схеме, которая была инсталлирована вместе с 10g. Будет реализована стратегия FGAC для таблицы HR.EMPLOYE » чтобы ограничить доступ к ней, базируясь на статусе менеджера и на но мере отдела, в котором работает служащий. Если вы являетесь служат ’ вы можете видеть собственную строку в таблице HR.EMPLOYEES, ос же вы менеджер, вы можете видеть строки всех подчиненных непоср ственно вам сотрудников.
Совет Если в вашей базе данных не инсталлированы демонстрационные схе > их можно создать, используя для этого сценарии, которые можно найти в ка ал $ORACLE_HOME/demo/schema.
Защита и аудит базы данных
401
После того как демонстрационные схемы буду!' в наличии, необходимо создать в базе данных несколько пользователей, которые хотят просматривать строки таблицы HR.EMPLOYEES.
□ create user smavris identified by smavris702;
grant connect, resource to smavris;
create user dgrant identified by dgrant507;
grant connect, resource to dgrant;
create user kmourgos identified by kmourgos622;
grant connect, resource to kmourgos;
Пользователь KMOURGOS является менеджером для всех биржевых маклеров, a DGRANT одним из служащих менеджера KMOURGOS. Пользователь SMAVRIS является HR_REP (представителем отдела кадров) для всей компании.
На последующих трех шагах всем в базе данных будут предоставлены привилегии SELECT для таблицы HR.EMPLOYEES и создана просмотровая таблица, отображающая идентификационные номера служащих на их учетные записи базы данных. Процедура, устанавливающая контекстные переменные для сеанса пользователя, будет использовать эту таблицу для присвоения идентификационного номера пользователя контекстной переменной, которая будет использована в функции правил для генерации предиката.
□ grant select on hr.employees to public,
create table hr.emp_loginjnap (employee_id, login_acct) as select employee_id, email from hr.employees;
grant select on hr.empJLoginjnap to public;
Затем будет создана учетная запись пользователя с именем VPD, который имеет привилегию создавать контексты и обслуживать функцию правил:
create user vpd identified by vpd439;
grant connect, resource, create any “context, create public synonym to vpd;
Подключаясь к схеме VPD, мы создаем контекст, который называется HR SECURITY, и определяем пакет и процедуру, используемые для установки контекста для приложения:
° connect vpd/vpd439@dw;
connect context hr_security using vpd.emp_access;
create or replace package vpd.emp_access as
procedure set_security_parameters;
end;
402
Следует помнить, что процедуры в пакете VPD.EMP_ACCESS явлЯ10т
ся единственными процедурами, устанавливающими контекстные менные. Тело пакета VPD.EMP_ACCESS имеет следующий вид:
□ create or replace package body vpd.emp_access is
-- При входе пользователя в систему выполните set_security_parameters
- - для выборки регистрационного имени пользователя (login name),
- - которое соответствует столбцу EMAIL таблицы HR.EMPLOYEES.
- - Контекст USERENV является предварительно определенным
- - для характеристик пользователя, например для имени пользователя,
- - адреса IP, с которого выполняется соединение, и т. д.
<
- - Для этой процедуры используется только SESSION_USER
- - из контекста USERENV.
procedure set_security_parameters is emp_id_num number;
emp_login varchar2 (50);
begin
- - Имя пользователя базы данных соответствует адресу электронной
- - почты в таблице HR.EMPLOYEES
empjlogin := sys.context (‘USERENV’, ‘SESSION-USER’);
dbms_session.set_context (‘HR_SECURITY’, ‘USERNAME’, emp_login);
- - Получить идентификационный номер служащего, чтобы можно было
- - установить права менеджера, не затрагивая при этом других
- - пользователей БД, которых нет в таблице EMPLOYEE begin
select employee_id into emp_id_num
from hr.emp_login_map where login_acct = empjlogin;
dbms_session.set_context (‘HR_SECURITY’, ‘EMP_ID’, empj-dj^)’ exception
when no_data_found then
dbms_session.set_context (‘HR_SECURITY’, *EMP_ID’, 0).
end;
-- Последующие запросы будут ограничивать отбираемые стро и
-- на основании emp_id
end; -- конец процедуры
end; -- конец пакета ,
Имя схемы пользователя выбирается путем просмотра в кс USERENV, который по умолчанию активируется для каждого пользе
Защитга и аудит базы данных
403
ля, и присвоения ее переменной USERNAME во вновь созданном контексте HRJSECURITY. Еще одна переменная контекста HR_SECURITY, EMPJD, определяется путем просмотра в таблице отображения HR.EMP_LOGIN_MAP.
Мы не хотим, чтобы процедура заканчивалась ошибкой, если зарегистрированного пользователя не оказалось в таблице отображения; вместо этого, переменной EMP_ID присваивается значение 0, что приведет к отсутствию доступа к таблице HR.EMPLOYEES, если в функции правил будет сгенерирован предикат.
На следующих шагах всем пользователям базы данных предоставляются привилегии EXECUTE на этот пакет, а также создается для него синоним, чтобы нажимать меньше клавиш каждый раз, когда его будет нужно вызвать:
□ grant execute on vpd.emp_access to PUBLIC;
create public synonym emp_access for vpd.emp_access;
Чтобы убедиться в том, что при регистрации каждого пользователя для него создается контекст, нужно подключиться как пользователь SYS и создать триггер входа в систему для установки переменных в контексте:
П connect sys/sys727@dw as sysdba;
create or replace trigger vpd.set_security_parameters
after logon on database '
begin
vpd.emp_access.set_security_parameters;
end;
Поскольку этот триггер срабатывает для каждого пользователя, подключающегося к базе данных, крайне необходимо, чтобы этот код был протестирован для каждого класса пользователей, если не для каждого пользователя базы данных! Если триггер завершится аварийно с сообщением об ошибке, то обычные (не SYSDBA) пользователи не смогут войти в базу данных.
К этому моменту определены контекст, процедура, используемая для задания контекстных переменных, и триггер, который автоматически вызывает процедуру. Войдя в систему как один из трех ранее определенных пользователей, можно сделать запрос к содержимому контекста:
П SQL> connect smavris/smavris702@dw
Connected.
SQL> select * from session_context;
namespace attribute value
HR_SECURITY USERNAME SMAVRIS
HRJSECURITY EMP_ID 203
2 rows selected.
404
Гпава iq
Обратите внимание, что произойдет в том случае, если SMAVRIS пытается выдать себя за другого служащего:
□ SQL> begin
2 dbms_session.set_context (‘HR.SECURITY’, ‘EMP.ID’, 100);
3 end;
begin
ERROR at line 1:
0RA-01031: insufficient privileges
0RA-06512: at “SYS.DBMS_SESSION\ line 82
0RA-06512: at line 2
(ОШИБКА в строке 1:
0RA-01031: недостаточно привилегий
0RA-06512: в строке 82 “SYS.DBMS_SESSION”
0RA-06512: в строке 2)
Только пакету VPD.EMP_ACCESS разрешено устанавливать и изменять переменные в контексте.
На заключительных шагах определяются процедуры, которые будут генерировать предикат, и присваивается одна или несколько таких процедур таблице HR.EMPLOYEES. Как пользователь VPD, уже владеющий контекстными процедурами, мы создадим пакет, определяющий предикаты:
□ connect vpd/vpd439@dw;
create or replace package vpd.get_predicates as
- - Примечание: у функции защиты всегда два параметра -- имя владельца
- - таблицы и имя таблицы
function emp_select_restrict
(owner varchar2, object_name varchar2) return varchar2;
- - Далее могут быть записаны остальные функции для операций INSERT, — DELETE и т. д.
end get_predicates;
create or replace package body vpd.get_predicates is
function emp_select„restrict
(owner varchar2, object_name varchar2) return varchar2 is
ret_predicate varchar2 (1000); -- часть фразы WHERE
begin
- - Позволяет служащему видеть только собс венную строку или стро k1
- - своих непосредственных подчиненных
Защита и аУДит базы данных
405
ret_predicate := ‘EMPLOYEE.ID = ‘ ||
sys.context (‘HR SECURITY’, ‘EMP_ID’ || ‘ OR MANAGER.ID = ‘ ||
sys.context (‘HR.SECURITY , ‘EMP.ID’);
return ret_predicate;
end emp_select _restrict;
end; -- конец тела пакета
После того как с помощью пакета DBMS_RLS функция прикреплена к таблице, она будет генерировать текстовую строку, которую можно будет использовать во фразе WHERE при каждом обращении к таблице. Сгенерированная строка при этом может выглядеть примерно так:
□ EMPLOYEE_ID = 124 OR MANAGER.ID = 124
Как и для пакета, устанавливающего среду контекста, необходимо разрешить пользователям получать к нему доступ:
□ grant execute on vpd.get_predicates to PUBLIC;
create public synonym get.predicates for vpd.get_predicates;
И, наконец, последний по списку, но отнюдь не по значению шаг: к таблице подключается функция правил (разграничения доступа) с помощью процедуры DBMS_RLSADD_POLICY:
□ dbms_rls.add_policy ( object_schema => ‘HR’,
object_name => ‘EMPLOYEES’,
policy.name => ‘EMP_SELECT_RESTRICT’,
function_schema => ‘VPD’, policy_function => ‘get_predicates.emp_select_restrict’, statement-types => ‘SELECT’, update_check => TRUE,
enable => TRUE
);
Служащий может, как и раньше, обращаться к таблице HR.EMPLOYEES, но теперь он сможет увидеть только собственную строку и строки своих подчиненных, если таковые имеются. Если, зарегистрировавшись как KMOURGOS, попытаться получить все строки в таблице HR.EMPLOYEES, то мы получим только строку про KMOURGOS и строки непосредственно подчиненных ему служащих:
SQL> connect kmourgos/kmourgos622/@dw;
Connected.
SQL> select employee.id, first_name, last_name, email, job_id, salary, manager_id from hr.employees;
employee_id FIRST_NAME LAST_NAME EMAIL JOB_IO SALARY MANAGER_ID
124 Kevin Mourgos KMOURGOS ST_MAN 5800 100
141 Trenna Rajs TRAJS ST.CLERK 3500 124
142 Curtis Davies CDAVIES ST CLERK 3100 124
406
Гпава iq
143 Randall Matos RMATOS ST-CLERK 2600 124
144 Peter Vargas PVARGAS ST_CLERK 2500 124
196 Alana Walsh AWALSH SH_CLERK 3100 124
197 Kevin Feeney KFEENEY SH_CLERK 3000 124
198 Donald OConnell DOCONNEL SH_CLERK 2600 124
199 Douglas Grant DGRANT SH_CLERK 2600 124
9 rows selected.
Для пользователя DGRANT все будет по-другому:
□ SQL> connect dgrant/dgrant507@dw;
Connected.
SQL> select employee_id, first_name, last_name,
2 email, job_id, salary, manager_id from hr.employees;
EMPLOYEE-ID FIRST_NAME LAST_NAME EMAIL JOB_ID SALARY MANAGER_ID
199 Douglas Grant DGRANT SH_CLERK 2600 124
1 row selected.
Служащему DGRANT дано увидеть только собственную строку, поскольку у него нет подчиненных.
В случае со служащим SMAVRIS мы увидим абсолютно аналогичные результаты выполнения запроса:
□ SQL> connect smavris/smavris702@dw;
Connected.
SQL> select employee_id, first_name, last_name,
2 email, job-id, salary, manager-id from hr.employees;
EMPLOYEE_ID FIRST-NAME LAST.NAME EMAIL JOB_ID SALARY MANAGER_ID
203 Susan Mavris SMAVRIS HR_REP 6500
1 row selected
Ho SMARVIS работает в отделе кадров и должна иметь возможность видеть все строки из таблицы. Кроме того, SMARVIS должна быть единс венной, кто может видеть информацию о зарплате всех служащих. В р зультате придется изменить функцию правил, чтобы предостав SMARVIS и другим служащим отдела кадров полный доступ к табл! HR.EMPLOYEES; в дополнение при назначении стратегии можно исП°^е зовать ограничения на уровне столбцов, чтобы было возвращено то самое количество строк, но с заменой чувствительных данных пуст (NULL) значениями.
Для облегчения сотрудникам отдела кадров доступа к табл HR.EMPLOYEES сначала необходимо изменить таблицу отображен1 включив в нее столбец JOB_ID. Если столбец JOB _ID имеет значение В REP, это означает, что служащий относится к отделу кадров. Сначала Н)
ЗаШита и аУДит базы Данных 407
но заблокировать действующую стратегию и создать новую таблицу отображения:
□ SQL> begin
2 dbms_rls.enable_pollcy (
3 object_schema => ‘HR’,
4 object_name => ‘EMPLOYEE’,
5 policy.name => ‘EMP-SELECT.RESTRICT’,
6 enable => FALSE
7 );
8 end;
PL/SQL procedure successfully completed.
SQL> drop table hr.emp_login_map;
Table dropped;
SQL> create table hr.emp-loginjnap (employee_id, login-acct, job_id)
2 as select employee.id, email, job.id from hr.employees;
Table created.
SQL> grant select on hr.emp_login_map to public;
Grant succeeded.
В процедуру, которая используется для создания и установки контекстных переменных, VPD.EMP_ACCESS, требуется добавить еще одну контекстную переменную, указывающую на уровень безопасности обращающегося к таблице пользователя. Нужно изменить оператор SELECT и сделать другой вызов процедуры DBMS_SESSION.SET_CONTEXT:
□ . . .
emp_job_id varchar2 (50);
select employee_id, job_id into emp. id .num, emp_job_id from hr.emp_login_map where login_acct - emp_login;
dbms_session.set_context (‘HR_SECURITY’, ‘SEC_LEVEL’,
case empjob.id when “HR_REP’ then ‘HIGH’ else ‘NORMAL’ end; );
Всякий раз, когда должность служащего называется HR_REP, контекстной переменной SEC_LEVEL вмео о значения NORMAL присваивается значение HIGH. В данной функции правил нужно проверить это условие следующим образом:
create or replace package body vpd.get_predicates is
function emp_select_restrict
(owner varchar2, object_name varchar2) return varchar2 is
ret_predicate varchar2(1000); — часть фразы WHERE
begin
408
- - позволяет служащему видеть только свою строку или строки своих
- - непосредственных подчиненных, за исключением случая, если
- - у него высшая (HIGH) степень допуска
if sys_context(‘HR_SECURITY’, *SEC_LEVEL’) = ‘HIGH’ then
ret_predicate := -- во фразе WHERE ограничения отсутствуют
else
ret_predicate : = ‘EMPLOYEE_ID = ‘ ||
sys_context(‘HR_SECURITY’, ‘EMP_ID’) ||
1 OR MANAGER_ID = ‘ | |
SYS_CONTEXT(‘HR_SECURITY’, * EMP_ID’);
end if;
return ret_predicate;
end emp_select_restrict;
end; -- тело пакета
Поскольку стратегия является динамической, предикат будет генерироваться при каждом выполнении оператора SELECT, так что не потребуется выполнять обновление стратегии. Теперь, когда запрос будет выполнять пользователь SMAVRIS, представитель кадровой службы, она увидит все строки таблицы HR.EMPLOYEES:
□ SQL> connect smavris/smavris702@dw;
Connected.
SQL> select employee.id, first_name, last_name,
2 email, job_id, salary, manager_id from hr.employees;
EMPLOYEE_ID FIRST_NAME LAST-NAME EMAIL JOB_ID SALARY MANAGER_ID
100 Steven King SKING AD-PRES 24000
101 Neena Kochhar NCOCHHAR AD_VP 17000 100
204 Hermann Baer HBAER PR_REP 10000 101
205 Shelley Higgins SHIGGINS AC_MGR 12000 101
206 William 107 rows selected. Gietz WGIETZ AC_ACCOUNT 8300 205
Однако пользователь DGRANT по-прежнему может видеть в V только свою строку:
□ SQL> connect dgrant/dgrant507@dw;
Connected
SQL> select employee_id, first_name, last-name,
2 email, job_id, salary, manager_id from hr.employees;
EMPLOYEE-ID FIRST_NAME LAST_NAME EMAIL JOB.ID SALARY MANAGER,!0
199 Douglas Grant DGRANT SH-CLERK 2600
1 row selected.
За^ита и аудит базы данных
409
Для форсирования (принудительного выполнения) требования о том, чтобы только сотрудники кадровой службы могли видеть информацию о заработной плате, нужно внести легкое изменение в функцию правил и активировать стратегии с ограничениями на уровне столбца:
□ dbms_rls.add_policy (
Б* object_schema => ‘HR’,
object_name => ‘EMPLOYEES’,
policy_name => 'EMP_SELECT_RESTRICT4,
1 function_schema => ‘VPD’,
policy_function => get_predicates.emp_select_restrict’, statement-types => ‘SELECT’, update_check => TRUE,
enable^ > TRUE,
sec_relevent_cols => ‘SALARY’, sec_relevant_cols_opt => dbms_rls.all_rows );
Последний параметр, SEC_RELEVANT_COLS_OPT, специфицирует константу пакета DBMS_RLS.ALL_ROWS, чтобы указать, что мы по-прежнему хотим видеть все строки в результатах нашего запроса за исключением релевантных (относящихся к ограничению) столбцов (например, SALARY), где вместо результата возвращаются пустые значения (NULL). В противном случае мы не увидим строк, которые содержат столбец SALARY.
Отладка стратегии VPD
Даже если возвратятся сообщения “ORA-28113: policy predicate has error” (ORA28113: в предикате стратегии содержится ошибка) или “ORA-00936: missing expression’ (ORA-00936: пропущено выражение"), может оказаться очень полезно видеть фактический предикат, сгенерированный в процессе разбора оператора. Есть два метода отладки предикатов, каждый из которых имеет свои преимущества и недостатки.
Первый метод используется для динамических представлений производительности V$SQLAREA и V$VPD_POLICY. V$SQLAREA содержит операторы SQL, находящиеся в данное время в разделяемом пуле, а также статистические данные о текущем выполнении. Представление V$VPD_ POLICY перечисляет все стратегии, которые в настоящее время применяются в эазе данных, вместе с их предикатами. Соединение этих двух таблиц, ( м. следующий пример) дает информацию, необходимую для помощи в адке любой проблемы, возникшей в связи с результатами запроса:
SQ1_> select s.sql__text, v.object_name, v. policy, v. predicate
2 from v$sqlarea s, v$vpd_policy v
3 where s.hash_value = v.sql_hash;
410
Гпава iq
SQL_TEXT
OBJECT_NAME POLICY
PREDICATE
select employee_id, EMPLOYEES EMP_SELECT_RESTRICT first_name, last_name, email, job_id, salary, manager_id from hr employees
select employee_id, first_name, last_name, email, job_id, salary, manager_id from hr.employees
EMPLOYEES EMP_SELECT_RESTRICT EMPLOYEE_ID = 124
OR MANAGER-ID = 124
select employee_id, first_name, last_name, email, job_id, salary, manager_id from hr employees
EMPLOYEES EMP-SELECT-RESTRICT EMPLOYEE_ID = 199
OR MANAGER_ID = 199
3 rows selected.
Если в этом запросе добавить соединение с V$SESSION, можно будет идентифицировать, какие именно пользователи выполняют операции SQL. У этого метода имеется и оборотная сторона: если база данных очень сильно загружена, команды SQL могут оказаться сброшенными из разделяемого пула на диск для размещения в пуле других команд SQL, прежде чем удастся выполнить этот запрос.
Во втором методе для генерации трассировочного файла в свободной форме, содержащего много информации о предыдущем запросе, используется команда alter session. Ниже приводятся команды для создания трассировки:
□ SQL> begin
2 dbms_rls.refresh_policy;
3 end;
PL/SQL procedure successfully completed.
SQL> alter session set events ‘10730 trace name context forever, level 12 (10730 всегда трассировать контекст имен, уровень 12);
Session altered.
Событие 10730 определено для трассировки предикатов стратег RLS. Другими часто встречающимися событиями являются собы 10029 и 10030 для начала/конца сеанса, 10710 для трассировки ооР^ер ний к битовым индексам и 10253 для имитации ошибок записи в °} журналов базы данных. После изменения сеанса пользователь выполняет свой запрос:
да1цита и аудит базы данных
411
□ SQL> select employee_id, first_name, last_name,
2 email, job_id, salary, manager_id from hr.employees;
EMPLOYEE_ID FIRST-NAME LAST_NAME EMAIL JOB_ID SALARY MANAGER_ID
199 Douglas Grant DGRANT SH_CLERK 2600 124
1 row selected.
Ниже приводится то, что можно увидеть в нижней части трассировочного файла, который размещен в каталоге, определенном параметром инициализации USER_DUMP_DEST:
□ /u01/app/oracle/admin/dw/udump/dw_ora_32530.trc
* ** MODULE NAME: (SQL*Plus) 2004-02-19 20:50:38.132
* ** SERVICE NAME: (SYSSUSER) 2004-02-19 20'50:38.132
* ** SESSION ID: (265.44) 2004-02-19 20:50:38.132
Logon user: DGRANT
Table/view: HR.EMPLOYEES
Policy_name: EMP_SELECT_RESTRICT
Policy function: VPD.GET.PREDICATES.EMP_SELECT_RESTRICT
RLS view:
SELECT “EMPLOYEE_ID”, ''FIRST_NAME”, "LAST_NAME", "EMAIL”,
UPHONE_NUMBER”, ’’HIRE-DATE”, "JOB_ID”, "SALARY”, ”COMMISSION_PCT”, “MANAGER_ID”,”DEPARTMENT-ID"
FROM “HR”."EMPLOYEES" “EMPLOYEES”
WHERE (EMPLOYEE_ID = 199 OR MANAGERJLD =199)
В трассировочном файле четко показан исходный SQL-оператор пользователя и добавленный в его конец предикат. Обратной стороной использования этого метода является то, что, хотя пользователь может получить доступ к динамическим представлениям производительности, разработчик может перестать получать доступ к пользовательскому каталогу с дампами на самом сервере. В результате при попытках отладки проблем с предикатами может потребоваться вмешаз ельство АБД.
Обязательно нужно отключить трассировку при выполнении отладки, чтобы можно было уменьшить накладные расходы и сократить дисковое пространство, используемое для операций трассировки:
SQL> alter session set events *10730 trace name context off’;
Session altered.
Аудит
Для мониторинга используемых видов привилегий и объектов, к которым выполняется доступ, Oracle использует много различных методов аудита. Аудит не метает использованию этих привилегий, но он может предоставить полезную информацию для обнаружения фактов злоупотребления привилегиями или неправильного их использования.
412
Гпава !q
В таблице 10.16 мы суммировали различные типы аудита в базе данных Oracle.
Таблица 10.16. Типы аудита
Тип аудита
Аудит операторов
Аудит привилегий
Аудит объектов схемы
Детальный аудит
Описание
Выполняется аудит операторов SQL по типам операторов безот-носительно конкретных объектов схемы, к которой производится доступ. Кроме того, в базе данных может быть указан один или несколько пользователей, которые и будут подвергнуты аудиту для конкретного оператора.
Аудиту подвергаются системные привилегии CREATE TABLE или ALTER INDEX. Как и аудит операторов, аудит привилегий может быть специфицирован для одного или нескольких пользователей, выступающих в роли объекта аудита.
Аудиту подвергаются конкретные операторы, выполняющиеся для конкретных объектов схем (например, для операторов UPDATE для таблицы DEPARTMENTS). Аудит объектов схемы всегда применяется ко всем пользователям базы данных.
Аудиту подвергается доступ к таблице и привилегии на основании содержимого объектов, к которым осуществляется доступ. Для создания стратегии для конкретной таблицы применяется пакет DBMS_FGA.
Местоположение информации аудита
Записи аудита могут быть посланы либо в таблицу базы данных SYS.AUD$, либо в файл операционной системы. Для активации аудита и специфицирования места, куда будет записана информация аудита, параметр инициализации AUDIT_TRAIL устанавливается на одно из следующих четырех значений:
Значение параметра
NONE, FALSE
OS
DB, TRUE
DB_EXTENDED
Действие
Блокировка аудита.
Активация аудита. Записи аудита посылаются в файл операционной системы.
Активация аудита. Записи аудита посылаются в таблицу
SYS.AUD$ базы данных.
Активация аудита. Записи аудита посылаются в таблицу SYS.AUD$ базы данных. Кроме того, дополнительная инфор ция записывается в столбцы типа CLOB SQLBIND и SQLTEX -
Параметр AUDIT_TRAIL не является динамическим; для того измененное значение этого параметра вступило в силу, нужно остане и перезапустить базу данных. При занесении результатов аудита в та цу SYS.AUD$ необходим тщательный мониторинг размера этой табл^ чтобы не оказать влияния на требования к дисковому пространству ДР ,
ЗаЩита и аудит базы данных
413
гих объектов в табличном пространстве SYS. Рекомендуется периодически архивировать строки таблицы SYS.AUD$, после чего очищать (truncate) таблицу. Роль DELETE_CATALOG_ROLE предлагается Oracle для использования со специальной учетной записью в пакетном задании для архивирования и очистки таблицы аудита.
Аудит операторов
При аудите любого типа для его включения используется команда audit, а для отключения — noaudit. Для аудита операторов применяется следующий формат команды audit:
□ AUDIT фраза_оператора_5р1 BY { SESSION | ACCESS }
WHENEVER [NOT] SUCCESSFUL;
Фрагмент фраза_опершпора_$ц1 содержит различные куски информации, например тип оператора SQL, который нужно подвергнуть аудиту, и кого именно мы собираемся ему подвергнуть.
В дополнение можно либо подвергать аудиту каждое выполнение аудируемого действия (by access), либо делать это один раз за сеанс (by session). По умолчанию подразумевается режим by session.
Иногда нужно подвергнуть аудиту только успешные действия — т. е. операторы, при выполнении которых не генерируется сообщение об ошибке. В таком случае надо добавить фразу whenever successful. В другой раз мы хотим обращать внимание только на ситуации, когда команды, использующие подвергаемые аудиту операторы, завершаются аварийно либо вследствие нарушения привилегий, либо из-за нехватки места в табличном пространстве, либо из-за синтаксической ошибки. В таких случа-. ях используется фраза whenever not successful.
Для большинства категорий методов аудита вместо типов индивидуальных операторов или объектов можно специфицировать all, если желательно, чтобы аудиту были подвергнуты все типы доступа к таблице или любые привилегии для конкретного пользователя.
Типы операторов, которые можно подвергнуть аудиту, и краткое описание операторов, рассматриваемых в каждой из категорий, перечисляются в таблице 10.17. Если будет специфицировано all, аудиту будут подвергнуты все операторы.
Таблица 10.17. Поддающиеся аудиту операторы, включенные в категорию ALL
Опция оператора______Операция SQL
CLUSTER Создать (CREATE), изменить (ALTER), удалить (DROP) или усечь
(TRUNCATE) кластер.
CONTEXT Создать (CREATE) или удалить (DROP) контекст.
DATABASE LINK Создать (CREATE) или удалить (DROP) связь баз данных.
DIMENSION Создать (CREATE), изменить (ALTER) или удалить (DROP) изме-
рение.
DIRECTORY Создать (CREATE) или удалить (DROP) каталог.
414
Гпава ю
T аблица 10.17. (Продолжение)
Опция оператора Операция SQL
INDEX Создать (CREATE), изменить (ALTER) или удалить (DROP) индекс.
MATERIALIZED VIEW Создать (CREATE), изменить (ALTER.) или удалить (DROP) материализованное представление.
NOT EXISTS Аварийное завершение оператора SQL из-за отсутствия ссылочных объектов.
PROCEDURE Создать (CREATE) или удалить (DROP) FUNCTION, LIBRARY, PACKAGE, PACKAGE BODY или PROCEDURE.
PROFILE Создать (CREATE), изменить (ALTER) или удалить (DROP) профиль.
PUBLIC DATABASE LINK Создать (CREATE) или удалить (DROP) публичную связь баз данных.
PUBLIC SYNONYM Создать (CREATE) или удалить (DROP) публичный синоним.
ROLE Создать (CREATE), изменить (ALTER), удалить (DROP) или установить (SET) роль.
ROLLBACK SEGMENT Создать (CREATE), изменить (ALTER) или удалить (DROP) сегмент отката.
SEQUENCE Создать (CREATE) или удалить (DROP) последовательность.
SESSION Начало и завершение сеансов.
SYNONYM Создать (CREATE) или удалить (DROP) синонимы.
SYSTEM AUDIT Режимы AUDIT или NOAUDIT для системных привилегий.
SYSTEM GRANT Присвоить (GRANT) или отозвать (REVOKE) системные привилегии и роли.
TABLE Создать (CREATE), удалить (DROP) или усечь (TRUNCATE) таблицу.
TABLESPACE Создать (CREATE), изменить (ALTER) или удалить (DROP) табличное пространство.
TRIGGER Создать (CREATE), изменить (ALTER, активировать/блокиро-вать) или удалить (DROP) триггеры; изменить (ALTER) TABLE либо с ENABLE ALL TRIGGERS, либо с DISABLE ALL TRIGGERS.
TYPE Создать (CREATE), изменить (ALTER) или удалить (DROP) типы и тела типов.
USER Создать (CREATE), изменить (ALTER) или удалить (DROP) поль-зователя.
VIEW Создать (CREATE) или удалить (DROP) представление.
Не все типы операторов из таблицы 10.18 попадают в категорию, при активации аудита; они должны быть явно специфицированы в люо команде audit.
Зашита и аудит базы данных
415
Таблица 10.18. Явно специфицируемые типы операторов
Опция оператора
Операции SQL
ALTER SEQUENCE
ALTER TABLE COMMENT TABLE
DELETE TABLE EXECUTE PROCEDURE
GRANT DIRECTORY
GRANT PROCEDURE
GRANT SEQUENCE
GRANT TABLE
GRANT TYPE
INSERT TABLE
LOCK TABLE
SELECT SEQUENCE
SELECT TABLE
UPDATE TABLE
Любая команда ALTER SEQUENCE.
Любая команда ALTER TABLE.
Добавить комментарий к таблице, представлению, материализованному представлению или к любым их столбцам.
Удалить строки из таблицы или представления.
Выполнить функцию, процедуру или любые переменные или курсоры из пакета.
Предоставить (GRANT) или отозвать (REVOKE) привилегию для объекта DIRECTORY.
Предоставить (GRANT) или отозвать (REVOKE) привилегию для процедуры, функции или пакета.
Предоставить (GRANT) или отозвать (REVOKE) привилегию для последовательности.
Предоставить (GRANT) или отозвать (REVOKE) привилегию для таблицы, представления или материализованного представления.
Предоставить (GRANT) или отозвать (РС'.'ОКЕ) привилегию для TYPE.
Вставить (INSERT INTO) в таблицу или представление.
Команда LOCK TABLE (блокировка таблицы) для таблицы или представления.
Любая команда, ссылающаяся на значения CURVAL или NEXTVAL последовательности.
SELECT FROM (отобрать из) для таблицы, представления или материализованного представления.
Выполнение UPDATE для таблицы или представления.
Несколько примеров помогут сделать более ясными все эти опции. В демонстрационной базе данных у пользователя SCOTT имеются все привилегии над таблицами для схемы HR и для других схем. Пользователю SCOTT разрешается создавать индексы для некоторых из этих таблиц, но мы хотим знать, когда были созданы индексы, если возникли какие-то проблемы с производительностью, связанные с изменением планов выполнения. Можно подвергнуть аудиту создание пользователем SCOTT индексов, используя для этого следующую команду:
П SQL> audit index by scott whenever successful;
Audit succeeded.
Позже в этот же день SCOTT создает индекс для таблицы HR.JOBS:
П SQL> create index job_titleJLdx on hr jobs (job_title);
Index created.
Выполнив проверку журнала аудита в представлении словаря данных DBA_AUDIT_TRAIL, мы видим, что SCOTT действительно создал индекс в 9:21 вечера 24 февраля:
416
Гпава 1 о
□ SQL> select username, to_char(timestamp, ‘MM/DD/YY НН24:МГ) Timestamp,
2 obj_name, action_name, sql.text from dba_audit_trail
3 where username = ‘SCOTT’;
USERNAME TIMESTAMP OBJ.NAME ACTION_NAME SQL_TEXT
SCOTT 02/24/04 21:24 JOB_TITLE_IDX CREATE INDEX create index job_title_idx on hr.jobs(job_title)
1 row selected.
Для отключения аудита для Пользователя SCOTT по таблице HR.JOBS можно использовать команду noaudit:
□ SQL> noaudit index by scott;
Noaudit succeeded.
Кроме того, можно регулярно проверять как успешные, так и неудачные попытки входа в систему. Для этого требуются две команды audit:
CJ SQL> audit session whenever successful;
Audit succeeded.
SQL> audit session whenever not successful;
Audit succeeded.
При просмотре журнала аудита обнаруживается одна неудачная попытка входа в систему пользователем RJB:
□ SQL> select username, to_char(timestamp, ‘MM/DD/YY НН24:МГ) Timestamp,
2 obj_name, returncode, action_name, sql_text from dba_.audit._trail
3 where action_name in (‘LOGON’, ‘LOGOFF’)
4 order by timestamp desc;
USERNAME TIMESTAMP OBJ_NAME RETURNCODE ACTION_NAME SQLJEXT
DBSNMP 02/24/04 21:55 0 LOGOFF
SYSMAN 02/24/04 21:54 0 LOGOFF
RJB 02/24/04 21:52 1017 LOGON
RJB 02/24/04 21:52 0 LOGON
DBSNMP 02/24/04 21:52 0 LOGOFF
SCOTT 02/24/04 21:52 0 LOGON
DBSNMP 02/24/04 21:51 0 LOGOFF
RJB 02/24/04 21:51 0 LOGOFF
SCOTT 02/24/04 21:38 0 LOGOFF
SCOTT 02/24/04 21:24 0 LOGOFF
10 rows selected.
Столбец RETURNCODE представляет сообщение об ошибке с # фиксом ORA. Сообщение ORA-1017 означает, что был введен невер пароль. Если бы нас интересовали только операции начала и конца с е. са, то вместо этого представления можно было использовать предела ние DBA_AUDIT_SESSION.
Защита и аудит базы данных
417
Аудиту операторов подлежат также и операции запуска и остановки базы данных. Хотя можно вести аудит команды shutdown immediate в таблицу базы данных SYS.AUD$, нельзя провести в нее аудит команды startup, поскольку, для того чтобы запись строк в таблицу SYS.AUD$ стала возможной, база данных должна быть уже запущена. В подобных случаях следует обратиться к каталогу $ORACLE_HOME/rdbms/audit/, где можно найти запись операции запуска базы данных, выполненного АБД. Ниже приводится пример текстового файла, создаваемого при запуске базы данных с помощью команды startup:
□ Audit file /u01/app/oracle/product/10.1.0/rdbms/audit/ora_2788.aud Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production With the Partitioning, OLAP and Data Mining options ORACLE_HOME - /u01/app/oracle/product/10.1.0 System name: Linux Node name: dw10g Release: 2.4.21-9.0.1.EL Version: #1 Mon Feb 9 22:26:52 EST 2004 Machine: 1686 Instance name: dw
Redo thread mounted by this instance: 0 <none> Oracle process number: 0 2788
Tue Feb 24 17:26:01 2004
ACTION: ‘STARTUP’
DATABASE USER: 7’
PRIVILEGE: SYSDBA
CLIENT USER: oracle
CLIENT TERMINAL: Not Available
STATUS: 0
В этом примере база данных была запущена пользователем, подключившимся на хост-системе как oracle и у экземпляру с помощью аутентификации операционной системы.
Аудит привилегий
Базовый синтаксис аудита системных привилегий такой же, как и для аудита операторов, с тем исключением, что системные привилегии специфицируются в конструкции $pa3a_system_privilege вместо операторов.
Например, нужно предоставить привилегию ALTER TABLESPACE всем АБД, и при этом генерировать записи аудита каждый раз, когда это происходит. Команда для активации аудита для этой привилегии выглядит очень похожей на аудит операторов:
SQL> audit alter tablespace by access whenever successful;
Audit succeeded.
Каждый раз, когда будет происходить успешное использование привилегии ALTER TABLESPACE, в таблицу SYS.AUD$ будет добавляться соответствующая строка.
418
Гпава 1о
Для системных администраторов, использующих привилегии SYSDBa и SYSOPER, доступен особый аудит Для активации этого дополнительного уровня аудита следует установить параметр инициализации AUDITSYS OPERATIONS на TRUE. Записи аудита будут посылаться в то же самое сто, что и записи аудита операционной системы; следовательно, это место зависит от используемой операционной системы. Все операторы SQL, выполняемые с использованием одной из этих привилегий, так же, как и любые операторы SQL, которые выполняются от имени пользователя SYS, будут посланы в место расположения данных аудита операционной системы.
Аудит объектов схемы
Аудит доступа к различным объектам схемы похож на аудит операторов и аудит привилегий:
□ AUDIT фраза_объект_схемы BY { SESSION | ACCESS }
WHENEVER [NOT] SUCCESSFUL;
Фрагмент фраза_объекш_схемы специфицирует тип доступа к объекту и объект, к которому совершается доступ. Аудиту могут быть подвергнуты тринадцать различных типов операций над конкретными объектами (см. таблицу 10.19).
Таблица 10.19. Опции аудита объектов
Опции объекта Описание
ALTER Изменяет таблицу, последовательность или материализованное представление
AUDIT COMMENT Подвергает аудиту команды для любого объекта Добавляет комментарии к таблицам, представлениям или к материализованным представлениям
DELETE Удаляет строки из таблиц, представлений или материализованных представлений
FLASHBACK Выполняет ретроспективные (flashback) операции над таблицей или представлением
GRANT INDEX INSERT Предоставляет привилегии для любого типа объектов ** Создает индекс для таблицы или материализованного представления Вставляет строки в таблицы, представления или материализованные представления
LOCK Блокирует таблицу, представление или материализованное представление
READ RENAME Выполняет операцию чтения для содержимого объекта DIRECTORY Переименовываем" таблицу, представление или материализованное представление
SELECT Выбирает строка чзтабпииы, представления, последовательности или материализованного представления
UPDATE Обновляет таблицу, представление или материализованное представление
ЗаШита и аУДит базы данных
419
Если нужно провести аудит всех команд insert и update для таблицы HR JOBS, безотносительно того, кто именно выполняет эти изменения, и каждый раз, когда такое изменение будет произведено, можно использовать следующую команду audit:
□ SQL> audit insert, update on hr.jobs by access whenever successful;
Audit successfue.
Пользователь TAMARA решила добавить в таблицу HRJOBS две новые строки:
□ SQL> insert into hr.jobs (job_id, job_title, min_salary, max_salary)
2 values (‘IN.CFO’, ‘Internet Chief Fun Officer’, 7500, 50000);
1 row created.
SQL> insert into hr.jobs (job_id, job_title, min_salary, max_salary)
2 values (‘OE_VLD’, ‘Order Entry CC Validation’, 5500, 20000);
1 row created.
В представление DBA_AUDIT_TRAIL в записях, относящихся к сеансу TAMARA, видны две команды insert:
П USERNAME TIMESTAMP OWNER OBJ_NAME ACTION_NAME SQL.TEXT
TAMARA 02/24/04 22:54 HR JOBS INocRГ
insert into hr.jobs (job_id, job_title, min_salary, max_salary) values (‘IN_CFO’, ‘Internet Fun Officer', 7500, 50000);
TAMARA 02/24/04 22:53 HR JOBS INSERT
insert into hr.jobs (job_id, job_title, min_salary, max_salary) values (‘OE_VLD’, 'Order Entry CC Validation’, 5500, 20000);
TAMARA 02/24/04 22:51 LOGON
3 rows selected.
Детальный аудит
Начиная с Огас1е9г, благодаря появлению детального аудита объектов (Fine-Grained Audit — EGA) аудит стал более целенаправленным и точным. Реализуется FGA с помощью пакета PL/SQL, который называется DBMS_FGA.
При стандартном аудите можно легке найти, к каким объектам ыли обращения и кто их делал, но нельзя узнать, к каким именно строкам и столбцам делались эти обращения Детальный аудит разрешает эту проблему не только с помощью введения предикат? (или фразы where), но и специфицируя столбец (или столбцы) таблицы, к которым ыли обращения. Эго может существенно сократить число записей в таблице аудита, так как аудиту подвергаются только те обращения к таблице, которые затрагивают определенные пользователем строки и столбцы.
420
Гпава 1о
В пакете DBMS_FGA есть четыре процедуры:
ADD-POLICY DROP-POLICY DISABLE_POLICY
ENABLE_POLICY
Добавляет стратегию аудита, испопь^я предикаты и аудит столбца
Удаляет стратегию аудита
Блокирует стратегию аудита, но при этом сохраняет связь стратегии с таблицей или представлением
Активирует стратегию
Обычно пользователь TAMARA ежедневно обращается к таблице HR.EMPLOYEES для поиска в ней адресов электронной почты сотрудников. Системный администратор подозревает, что TAMARA просматривает информацию о зарплатах менеджеров, так что он создает стратегию FGA для аудита любого доступа к столбцу SALARY для любого, кто является менеджером:
□ begin
dbms_fga.add_policy (
object_schema => ‘HR’, object_name => 'EMPLOYEES’, policy_name => ‘ SAL_SELECT_AUDIT’ audit_condition => ‘instr(job_id, audit_column => ‘SALARY’
"_MAN”) > O’,
end;
Обратиться к записям детального аудита можно с помощью представления словаря данных DBA_FGA_AUDIT_TRAIL. Если обычно требуется изучать строки и стандартного аудита, и детального аудита, в представлении словаря данных DBA_COMMON_AUDIT_TRAIL строки обоих типов аудита будут объединены.
Пользователь TAMARA выполняет два следующих запроса SQL:
□ SQL> select employee_id, first_name, last-name, email from hr.employees 2 where employee-id = 114;
EMPLOYEE ID FIRST NAME LAST_NAME EMAIL
114 Den Raphaely DRAPHAEL
1 row selected.
SQL> select employee-id, first_name, last-name, salary from hr.employeeS 2 where employee_id = 114;
EMPLOYEE,ID FIRST NAME
LAST_NAME
114 Den
Raphaely
SALARV
11000
1 row selected.
дб‘
Первый запрос обращается к информации о менеджере, но не к с г° цу SALARY. Второй запрос похож на первый, но в нем выполняется о V щение к столбцу SALARY, поэтому он запускает стратегию FGA, теМ мым, генерируя одну и только одну строку в журнале аудита:
ЗаШита и аудит базы данных
421
□ SQL> select to_char(timestamp, ‘mm/dd/yy hh24:mi’) timestamp,
2 object_schema, object_name, policy_name, statement-type
3 from dba_fga_audit_trail
4 where db_user = ‘TAMARA’;
TIMESTAMP OBJECT-SCHEMA OBJECT.NAME POLICY-NAME STATEMENT-TYPE
02/25/04 00:04 HR EMPLOYEES SAL_SELECT_AUDIT SELECT
1 row selected.
Поскольку выше в данной главе в примере VPD уже создавался детальный контроль доступа для предотвращения неавторизованного доступа к столбцу SALARY, необходимо перепроверить функции правил, чтобы убедиться в том, что информация SALARY все еще продолжает оставаться должным образом ограниченной. Детальный аудит вместе с обычным аудитом — это хороший способ убедиться, что стратегии авторизации в первый раз были установлены правильно.
Связанные с аудитом представления словаря данных
В таблице 10.20 содержатся связанные с аудитом представления словаря данных.
Таблица 10.20. Представления словаря данных, связанные с аудитом
Представление Описание
словаря данных______________________________________________________________
AUDIT-ACTIONS Содержит описания кодов типов действий с журналом
аудита, например INSERT, DROP VIEW, DELETE, LOGON и LOCK.
DBA_AUDIT_OBJECT
DBA_AUDIT_POLICIES DBA_AUDIT_SESSION
dba_audit_statement
DBA-AUDIT-TRAIL
DBA_FGA_AUDIT_TRAIL dba_common_audit_trail
DBA-OBJ-AUDIT-OPTS dba_priv_audit_opts dba_stmt_auditopts
Записи журнала аудита, связанные с объектами в базе данных.
Стратегии детального аудита в базе данных.
Записи журнала аудита, связанные с операциями CONNECT и DISCONNECT.
Записи журнала аудита, связанные с командами GRANT, REVOKE, AUDIT, NOAUDIT и ALTER SYSTEM.
Содержит записи журнала стандартного аудита. Представление USER_AUDIT_TRAIL содержит только строки для подключенного пользователя.
Записи журнала аудита для стратегий детального аудита.
Объединяет в одном представлении строки стандартного и детального аудита.
Действующие опции аудита для объектов базы данных.
Действующие опции аудита для системных привилегий.
Действующие опции аудита для операторов.
422
Гпава ю
Защита журнала аудита
Журнал аудита также нуждается в защите, особенно если требуется предок тавить доступ к таблице SYS.AUD$ несистемным пользователям. Встроенная роль DELETE_ANY_CATALOG является одним из способов, с помощью которых несистемные (т. е. не обладающие полномочиями пользователя SYS. — Прим, пер.) пользователи могут получить доступ к журналу аудита (например, архивировать и очищать журнал аудита, чтобы быть уверенными в том, что его размер не оказывает влияния на требования к дисковому пространству для других объектов в табличном пространстве SYS).
Для задания аудита самого журнала аудита следует подключиться как SYSDBA и выполнить следующую команду:
□ SQL> audit all on sys.aud$ by access;
Audit succeeded.
Теперь все действия по отношению к таблице SYS.AUD$, включая select, insert, update и delete, будут записываться в самой таблице SYS.AUD$. Но что будет, если кто-то удалит записи аудита, относящиеся к обращениям к таблице SYS.AUD$? Строки таблицы будут удалены, но после этого будет добавлена новая строка, фиксирующая удаление этих строк. Следовательно, всегда будет иметься какое-то доказательство действий, случайных или преднамеренных, по отношению к таблице SYS.AUDS. Если параметр AUDIT_SYS_OPERATIONS установлен на TRUE, то все сеансы, использующие подключение as sysdba, венно от имени SYS, будут регистрироваться в
системы, в который, как предполагается, не имеют доступа даже АЬД Oracle. В результате получается, что у есть множество защитных мер, позволяющих быть уверенными, что все действия с привилегиями в базе данных, наряду с любыми попытками скрыть эти действия зарегистрированы.
as sysoper или непосредст-файле аудита операционной
Методы кодирования данных
Кодирование данных может повысить защиту как внутри, так и вне базы данных. Пользователь может быть заинтересован в доступе к большей части столбцов таблицы, но, если один из столбцов закодирован и ноль зователь не знает ключа к этому шифру, информация перестает ^ыть^е3 лезной. То же самое относится и к информации, которая должна быть
риска передана по сети.
Впервые появившийся в Oracle lOgnaneT DBMS„CRYPTO заменяет i струментальное средство DBMS_OBFUSCATION_TOOLKIT. В н включен алгоритм кодирования Advanced Encryption Standard (AES вершенствованный стандарт шифрования), заменивший Data Encryp Standard (DES — стандарт шифрования данных).
Процедуры, входящие в состав DBMS_CRYPTO, могут генерир0^^ приватные ключи, либо можно специфицировать и хранить эти чи самостоятельно. В отличие от DBMS_OBFUSCATION_TOOLK торое может кодировать только типы данных RAW или VARC^t DBMS CRYPTO может также кодировать типы данных BLOB и CLO
DBMS_OBFUSCATION_TOOLK1 1 шки пи-. ----~ ZvAyy' ~ЛИ
кодировать типы данных BLOB и CLO
REAL APPLICATION CLUSTERS
В главе 4 был представлен обзор среды автоматического управления хранением данных (Automatic Storage Management — ASM) и управляемых Oracle файлов (Oracle Managed Files — OMF) и было показано, как с их помощью можно облегчить администрирование, повысить производительность и увеличить доступность системы. Можно добавить в быстро растущую VLDB один или несколько дисковых томов, даже не останавливая экземпляра.
В главе 6 говорилось о табличных пространствах типа Bigfile и о том, что они могут не только позволить базе данных иметь намного больший размер, чем в предыдущих версиях Oracle, но и облегчить администрирование за счет переноса точки обслуживания с файлов данных на табличное пространство. В главе 16 будет описываться Oracle Net и даны базовые знания, достаточные для того, чтобы быть уверенными в том, что клиенты смогут достигать серверов базы данных эффективным и адекватным образом. В главе 17 будет расширено знакомство с табличными пространствами типа Bigfile, а также предложены другие инструменты для облегчения управления большими базами данных, например под держка секционированных (разбитых на независимые разделы) таблиц (partitioned tables), переносимых табличных пространств (transporta tablespaces) и впервые появившийся в Oracle 10g инструмента Огас Data Pump (помпа данных Oracle).
По мере того как база данных становится все больше и увеличивае число ее пользователей, потребность в доступности базы данных ст вится все более и более важной. Опция Real Application Clusters ( объединяет OMF, табличные пространства типа Bigfile, надежную тойчивую инфраструктуру сети и ASM, делая их ключевыми элемен архитектуры RAC. де
В этой главе основное внимание будет сосредоточено на целок р> относящихся к RAC вопросов, в том числе, на вопросе о том, как CJie создавать окружение операционной системы — параметры ядра, сет 7 конфигурацию и учетные записи пользователей. Для создания клас ной среды нужно выполнить все необходимые для поддержки RAC сталляции, например инсталлировать сервис Cluster Ready Sen1
peal Application Clusters
425
(CRS), а также использовать в универсальном инсталляторе Oracle (Oracle Universal Installer) различные опции инсталляции для конфигурирования сети, разделяемой памяти и программного обеспечения как для CRS, так и для самой базы данных Oracle 10g.
Во время инсталляции RAC можно сконфигурировать агент Enterprise Manager и Enterprise Manager Database Control для управления кластером. ЕМ Database Control расширяет функциональные возможности, имеющиеся для управления единственным экземпляром, предоставляя готовый к работе в кластерной среде уровень; можно управлять как экземплярами Oracle, так и лежащей в их основе кластерной конфигурацией через единый web-интерфейс.
Обзор Real Application Clusters
База данных Real Application Clusters является высокодоступной и масштабируемой. Выход из строя одного из узлов кластера не влияет на сеансы клиентов или на доступность самого кластера, пока не выйдет из строя последний узел кластера (и если за это время не удастся восстановить работоспособность ни одного из вышедших ранее из строя узлов кластера. — Прим. пер.). Единственное влияние, которое способен оказать на кластер вышедший из строя узел, — это незначительная деградация времени отклика, зависящая от общего количества узлов в кластере.
У базы RAC есть и некоторые недостатки. Более высокой является стоимость лицензирования, так как каждый входящий в кластер узел должен иметь собственную лицензию Oracle. Непосредственная физическая близость узлов кластера, обусловленная требованиями высокоскоростных межузловых соединений в кластере (существуют ограничения на максимальную длину соединения. — Прим пер.), означает, что в случае естественного природного бедствия может выйти из строя весь кластер; использование дистанционно удаленной резервной базы данных может помочь смягчить некоторые из этих опасений. Необходимо взвесить стоимость обеспечения высокой доступности (или ее отсутствия) для обычной системы и сравнить ее с более высокой стоимостью и слегка увеличивающимися расходами на обслуживание базы данных Real Application Clusters.
Аппаратная конфигурация
Полное обсуждение всех возможных аппаратных конфигураций базы Данных Real Application Clusters выходит за рамки данной книги. Для азы данных Real Application Clusters желательно иметь кластер, состоящий, по крайней мере, из двух узлов, хотя предпочтительнее иметь кластер с тремя узлами. У каждого из узлов кластера должны быть избыточные ис очники питания, сетевые карты, сдвоенные центральные процессоры и оперативная память с коррекцией ошибок; таковы желаемые характеристики для любого типа сервера, а не только для сервера racle! Чем больше узлов сконфигурировано для кластера, тем меньшее Падение производительности будет зафиксировано при выходе из строя одного из узлов кластера.
426
Гпава ij
Совместно используемая (разделяемая) дисковая подсистема так^е должна обладать встроенной аппаратной избыточностью — несколько источников питания, диски с возможностями RAID и т. п. Можно сбалансировать избыточность, встроенную в разделяемую дисковую подсистему с типами дисковых групп, которые создаются для RAC. Более высокая из-быточность, встроенная в разделяемую дисковую подсистему, может потенциально понизить объем специфицируемой при создании дисковых групп базы данных софтверной избыточности.
Софтверная конфигурация
Хотя кластерные решения Oracle стали доступными еще в шестой версии, вплоть до выхода версии 10g не было прямого (или, как его часто называют, “родного”. — Прим, пер.) решения для программного обеспечения кластера, которое более тесно связывало бы базу данных с решением для управления томами. Сервис Cluster Ready Sendees (CRS) является кластерным решением, которое может быть использовано на всех основных платформах вместо программного обеспечения кластера, предлагаемого поставщиком ОС или третьими фирмами.
Сервис CRS должен быть инсталлирован раньше, чем СУРБД, и должен быть размещен в собственном домашнем каталоге, который далее будет называться CRS_HOME. Если в настоящее время используется всего один экземпляр, но в будущем планируется перейти к использованию кластера, то будет полезно инсталлировать CRS, чтобы компоненты CRS, необходимые для ASM и RAC, присутствовали в структуре каталогов СУРБД. Если CItS не будут инсталлированы в первую очередь, впоследствии придется выполнить несколько дополнительных шагов для удаления из домашнего каталога СУРБД выполнимых модулей процессов, связанных с CRS.
После инсталляции CRS в домашний каталог, который принято называть ORACLE_HOME, инсталлируется программное обеспечение базы данных. Для некоторых платформ, например для MicrosoftWindows, этот каталог может быть общим для всех узлов, в то время как на других платформах (типа Linux) требуется OCFS версии 2.x или более поздней. В противном случае в каждом узле должна иметься собственная копия двоичных исполняемых модулей.
Конфигурация сети
У каждого узла в RAC есть минимум три IP-адреса: один для публ сети, один для приватного сетевого межузлового соединения и в tpT) ный IP-адрес для поддержки быстрого восстановления после сбоев выходе узла из строя. В результате для поддержки RAC требуется не нее двух физических сетевых карт; дополнительные сетевые карты пользуются для обеспечения избыточности в публичной сети и, тельно, дополнительного сетевого пути для входящих подключена И-приватной сети дополнительные сетевые карты могут повысить прой дительность за счет получения большей полосы пропускания для Мс ) левого трафика. На рис. 11.1 показан двухузловои RAC с одной сетей
aeal Application Clusters
427
Рис. 11.1. Сетевая конфигурация RAC
картой на каждом узле для приватного межузлового соединения и одной сетевой картой на каждом узле для подключения к публичной сети.
Публичная сеть используется для всех обычных подключений к серверу (и отключений от него); сеть межузловых соединений, или приватная сеть, поддерживает коммуникации между узлами кластера типа обмена информацией о статусе узлов и о блоках данных, совместно используемых несколькими узлами. Интерфейс должен быть как можно более быстрым, и по этому интерфейсу не должны выполняться никакие другие типы обмена данными между узлами, так как в противном случае может пострадать производительность базы данных RAC.
Виртуальный IP-адрес является адресом, назначаемым процессу прослушивания Oracle, и поддерживает быстрое преодоление последствий сбоя во время подключения (rapid connect-time failover), в результате чего можно переключить сетевой трафик и подключение Oracle на другой экземпляр в базе данных RAC намного быстрее, чем с помощью обеспечивающих высокую доступность решений от третьих фирм.
Дисковая память
Чтобы поддерживать избыточность, разделяемый дисковый накопитель может быть, а может и не быть RAID-устройством. Намного важнее, чтобы дисковые контроллеры и соединения с разделяемой памятью были мультиплексированы для обеспечения высокой доступности. Если диски в разделяемом накопителе не зеркалированы, для обеспечения выгод в производительности и доступности можно воспользоваться возможностями зеркалирования ASM.
Для примеров, приводимых в этой главе, будет использоваться Linux-сервер с конфигурацией “чистых” (без файловой системы. — Прим, пер.) дисковых устройств (см. таблицу'11.1). Эти чистые диски размещены на разделяемом запоминающем устройстве с интерфейсом SCSI и имеют одно и то же имя устройства в каждом узле кластера.
Два чистых диска по 100 Мбайт каждый резервируются для так называемого голосующего диска (voting disk) и диска с OCR (об использовании этих дисков см. ниже в данной главе).
428
Гпава 11
Таблица 11.1.
“Чистые” диски для дисковых групп ASM, голосующий диск и диск с OCR
Имя чистого диска Имя физического устройства Емкость Назначение
/dev/raw/raw1 /dev/sda1 10 Гбайт Диск ASM № 1: +DATA1
/dev/raw/raw2 /dev/sdb1 10 Гбайт Диск ASM № 1: +DATA1
/dev/raw/raw3 /dev/sdc1 10 Гбайт Диск ASM № 2: +REC0V1
/dev/raw/raw4 /dev/sdd1 10 Гбайт Диск ASM № 2: +REC0V1
/dev/raw/raw5 /dev/sde1 100 Мбайт Диск с OCR
/dev/raw/raw6 /dev/sdf1 100 Мбайт Голосующий диск
Инсталляция и настройка
В приводимых в этой главе примерах для инсталляции базы данных RAC и демонстрации ее возможностей будет использоваться платформа Red Hat Linux. Однако большинство, если даже не все советы по инсталляции, методики и методы, о которых пойдет речь в этой главе, будут применимы к другим Unix-подобным платформам и даже к инсталляциям на базе Windows.
Будет показано, как создать трехузловую базу данных RAC. Это связано с тем, что, хотя большую часть свойств базы данных RAC можно продемонстрировать на двухузловой базе данных RAC, для того чтобы увидеть, как “оставшиеся в живых” узлы кластера продолжают функционировать именно как кластерная база данных и как они восстанавливаются после потери одного из узлов кластера, потребуется именно трехузловая база данных RAC. На практике, чем больше узлов имеется в кластере, тем меньшее влияние на общую пропускную способность оказывает выход из строя одного из узлов кластера.
Программное обеспечение Oracle в каждом узле кластера должно быть размещено в собственном локальном каталоге ORACLE_HOME; для фай лов базы данных и файлов для ее восстановления будет использоваться ASM, а для диска с OCR и голосующего диска — “чистые” дисковые устрой ства.
Примечание В качестве альтернативы ASM и “чистым” дискам можно пред жить кластерную файловую систему Oracle (Oracle Cluster File System — OCFS) bp сии 2.x, найти которую можно на сайте http://oss.oracle.com. OCFS можно исполь> вать для хранения как файлов базы данных, так и исполняемых модулей or в общей, разделяемой файловой системе. ..
И, наконец, предположим, что разделяемый диск доступен через и то же имя узла в каталоге /dev и что каждый узел может одновремен обратиться к разделяемому диску; экземпляр ASM йа каждом узле будет тематически координировать доступ к разделяемому диску.
al Application Clusters
429
Конфигурация операционной системы
Первым шагом станет подготовка операционной системы. Следует инсталлировать Red Hat 3.0 ES или AS и при этом инсталлировать каждую их опцию! То небольшое количество дискового пространства, которое может быть сэкономлено при инсталляции, может оказаться потерянным, если позже обнаружится, что при инсталляции был пропущен какой-то компонент, и придется разыскивать инсталляционные компакт-диски для инсталляции пропущенных компонентов. После того как все необходимое инсталлировано, необходимо применить все имеющиеся патчи (заплатки) из Red Hat Network, чтобы можно было воспользоваться всеми усовершенствованиями в системе защиты и производительности. Правда, было неоднократно заявлено, что Oracle 10g будет работать и в средах Red Hat 3.0 ES или AS Service Pack 2 без каких бы то ни было патчей.
Требования к памяти и дискам
Для каждого узла кластера рекомендуется использовать, как минимум, 512 Мбайт. Пространство для свопинга должно иметь, по крайней мере, вдвое больший размер, т. е. 1 Гбайт. Для успешной инсталляции в файловой системе /tmp должно иметься не менее 400 Мбайт.
Для самого программного обеспечения Oracle требуется примерно 2,5 Гбайт дискового пространства, а для размещения используемых по умолчанию файлов базы данных — еще 1,2 Гбайт; последующий рост базы данных, конечно, зависит от эксплуатируемых приложений.
В разделяемой дисковой подсистеме должны быть использованы два особых раздела: один для голосующего диска и другой для Oracle Cluster Registry (OCR — реестр кластера Oracle). Голосующий диск используется программным обеспечением кластеризации Oracle (Cluster Ready Services — CRS) для арбитража прав владения кластером в случае выхода из строя приватной сети. Диск с OCR используется для обслуживания всех метаданных о кластере: конфигурации кластера и конфигурации базы данных кластера.
Параметры ядра
Большинство параметров ядра, про которые говорят, что они не нуждаются в настройке, установлены вполне приемлемо для Oracle, за исключением очень немногих; нужно убедиться в том, что все перечисленные в таблице 11.2 параметры ядра имеют указанные в этой же таблице значения.
Используя следующую команду, можно получить подтверждение, что Действуют именно эти значения:
[root@rhes30]# /sbin/sysctl -а | egrep ‘sem|shm|file-max|ip_local’ net.ipv4.ip_local_port_range = 1024 65000
kernel.sem = 250 32000 100 128
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmax = 2147483648
fs.file-max - 65536
[root]@rhes30]#
430
В выполняемой по умолчанию инсталляции Red Hat Linux 3.0 некОт рые из этих параметров уже установлены. Для параметров, значенця к ' торых отличаются от значений из таблицы 11.2, нужно просто ДобавцТЕ имя параметра и указанное выше значение параметра в конец фа^ /etc/sysctl.conf, а затем выполнить команду /sbin/sysctl -р, которая медленно изменит их значения. После следующей загрузки новые значе ния, специфицированные в /etc/sysctl.conf, будут установлены автоматически.
Таблица 11.2. Минимальные значения параметров ядра Oracle Database 10g
Параметр ядра Значение
kernel.shmall 2097152
kernel.shmmax 2147483648
kernel.shmmni 4096
kernel.sem 250 32000100128
fs.file-max 65536
net.ipv4_local_port_range 1024 65000
Сетевая конфигурация
Для каждого узла RAC требуется, по меньшей мере, две сетевые карты: одна для подключения к публичной сети для клиентских коммуникации и вторая, которая используется для трафика в приватной сети между узлами кластера. В данной главе будет использоваться следующий файл /etc/hosts:
□ # Не удаляйте следующую строку, иначе многие программы, для которых # требуются функциональные возможности сети, закончатся аварийно.
#
127.0.0.1 localhost.localdomain localhost
192.168.2.99 192.168.2.166 192.168.2.167 rhes30 oltp mw
192.168.2.101 oc1 tfpublicl
192.168.1.101 pod #private1
192.168.2.176 voc1 #virtual1
192.168.2.102 oc2 #public2
192.168.1.102 poc2 #private2
192.168.1.177 voc2 #virtual2
192.168.2.103 oc3 #public3
192.168.1.103 poc3 #pnvate3
192.168.2.178 voc3 #virtual3
fle^ Application Clusters
431
Если используется сервер DNS, эти имена и адреса должны быть размещены и там.
Здесь стоит отметить пару моментов. Для каждого сервера требуются только две сетевые карты; зачем же понадобился “виртуальный” адрес для каждого узла? Виртуальные адреса поддерживают быстрое преодоление последствий сбоя во время подключения (эта концепция будет более подробно исследована ниже в данной главе). Все клиентские подключения используют эти виртуальные адреса для своих подключений, и процесс прослушивания каждого узла RAC будет вести прослушивание на виртуальных узлах, а не на публичных именах узлов. Каждый виртуальный адрес должен принадлежать той же подсети, что и публичный адрес; сеть приватных межузловых соединений, однако, находится в своей собственной приватной подсети.
Совет Прежде чем приступить к любым инсталляциям программного обеспечения Oracle, нужно убедиться в том, что с любого узла кластера можно подключиться к любому другому узлу, используя ssh без подсказок для пароля в случае обоих пользователей — root и oracle.
Учетные записи пользователей
Помимо учетной записи root, единственной необходимой учетной записью пользователя на сервере Linux является учетная запись oracle. В реальной жизни в промышленно эксплуатируемой среде лучше не иметь на сервере учетных записей других пользователей, чтобы предотвратить непреднамеренный или умышленный доступ к критичным файлам базы данных, управляющим файлам, выполняемым модулям или к файлам паролей.
На каждом узле кластера помимо пользователя oracle должны существовать группы oinstall и dba. Если их пока не существует, для их создания можно использовать следующие команды и приписать пользователя oracle к обеим группам, a oinstall сделать первичной группой:
[root@rhes30 root]# /usr/sbin/groupadd oinstall
[root@rhes30 root]# /usr/sbin/groupadd dba
[root@rhes30 root]# /usr/sbin/useradd -g oinstall -G dba oracle
[root@rhes30 root]# passwd oracle
Changing password for user oracle.
New password:
Retype new password:
Passwd: all authentication tokens updated successfully. [root@rhes30 root]#
Для пользователя Oracle нужно создать подразумеваемое (используемое по умолчанию) окружение в сценарии входа в систему; приведенный ниже образец сценария входа в систему предполагает использование оболочки bash (Bourne Again Shell - еще одна оболочка Борна) для Red Hat:
432
Гпава
□ # ,bash_profile
4 Получите псевдонимы и функции if [ -f bashrc ]; then
. "/.bashrc
fi
it Зависящая от пользователя среда и программы запуска
PATH=$PATH:$HOME/bin
export РА ГН
unset USERNAME
umask 022
0RACLE_BASE=/u01/app/oracle
# ORACLE_HOME устанавливается после инсталляции с 0UI.
tt 0RACLE_H0ME=$0RACLE_BASE/product/10.1.0/DB10g Home
it ORACLE_SID различный на каждом из узлов;
it одна база данных, различные экземпляры.
0RACLE_SID=rac1
LD_ASSUME_KERNEL=2.4.19
PATH=$ORACLE_HOME/bin:$РАТН
export ORACLE-BASE ORACLE_HOME ORACLE_SID PATH LD.ASSUME .KERNEL
Следует убедиться в том, что значение ORACLE_SID уникально для каждого узла! Когда инсталлируются дополнительные продукты типа CRS и создаются экземпляры RAC, в сценарий входа в систему вносятся необходимые изменения. Нужно также убедиться в том, что параметр LD_ ASSUME_KERNEL в профиле .bash_profile для пользователя root установлен на 2.4.19; эта установка требуется для инсталляции Oracle на платформе Red Hat 3.0.
Примечание Если используется Oracle 10ff update 1 или более поздние варианты, необходимость в установке параметра LD ASSUME KERNEL отпадает.
Чтобы установить эквивалентность пользователей между узлами кла стера, надо использовать для поддержки команд rsh и гср файлы .гпо или /etc/hosts.equiv; однако лучше (и более безопасно) убедиться в то » что для всех узлов кластера сконфигурированы ssh и scp. ^аЧйй0 с Oracle 10g, OUI будет, если это возможно, использовать ssh и scp, ’ если потребуется, возвращаться к использованию rsh и гср. КонфигуР рование ssh с использованием утилиты ssh-keygen выходит за рамки ной книги; надо проконсультироваться с системными администратор Unix или Linux относительно того, как следует конфигурировать и scp.
Каталоги программного обеспечения
Поскольку в этих примерах для запоминающих устройств RAC исп° ется ASM, на локальных запоминающих устройствах необходимо соз только один каталог, /uOl/app/oracle, в котором будет храниться
pe^l Application Clusters
433
граммное обеспечение базы данных Oracle и CRS. Дисковый том, на котором помещается этот каталог, должен иметь размер не менее 2,5 Гбайт для размещения на нем программного обеспечения CRS и базы данных. Для создания этого каталога нужно использовать следующие команды и назначать правильные права доступа:
□ [root@rhes30 root]# mkdir -р /u01/app/oracle
[root@rhes30 root]# chown -R oracle:oinstall /u01/app/oracle [root@rhes30 root]# chmod -R 775 /u01/app/oracle
Инсталляция программного обеспечения
Неважно, создается ли двухузловой кластер или кластер с 16 узлами, процедура остается одной и той же. Если серверы сконфигурированы так, как было описано выше, инсталляции, выполняющиеся в последующих разделах, будут автоматически проталкиваться до каждого узла, который указан в конфигурационных экранах для Cluster Ready Services и для самой базы данных Oracle.
Вследствие этого последующее обсуждение будет разделено на три части: сервис CRS для подготовки кластеризованной среды, инсталляция программного обеспечения базы данных Oracle 10g и создание экземпляра базы данных на каждом узле кластера. По мере того как мы будем изучать каждый экран для каждой инсталляции, мы будем получать все требующиеся предпосылки и объяснения, так что после того как будут завершены все инсталляции, мы будем готовы внести в среду все требующиеся изменения.
Во многих случаях шаги для инсталляции программного обеспечения базы данных, самой базы данных и ASM оказываются аналогичными или идентичными шагам, описанным в главах 1 и 4; в последующих разделах мы сосредоточимся на тех отличиях, с которыми нам приходится столкнуться при инсталляции RAC.
Cluster Ready Services
CRS должен быть инсталлирован в собственный домашний каталог, кото-рый называется CRS_HOME. Как часть инсталляции CRS нужно сконфигурировать два отдельных адреса, которые не связаны с каким-либо экземпляром, а используются самим кластером: это реестр кластера Oracle (Oracle Cluster Registry — OCR) и голосующий диск (voting disk). Реестр кластера Oracle — это место, в котором хранятся метаданные кластера; и 100 Мбайт дискового пространства — это более чем достаточно для хранения метаданных для очень большого кластера. Голосующий диск используется кластером для разрешения ситуаций, когда один или несколько узлов кластера теряют контакт с другими узлами кластера по приватному межузловому соединению. Таким образом, появляется возможность изолировать один узел (или группу узлов) от записи информации в файлы разделенных дисковых устройств, поскольку он предполагает, что находится под контролем разделяемого запоминающего устройства. Как и для диска с OCR, для голосующего диска не требуется более 100 Мбайт.
434
Гпава /1
Диск с OCR и голосующий диск должны размещаться на отдельны “чистых” устройствах, даже когда для других файлов базы данных исподь зуется ASM; но, если используется OCFS, диск с OCR и голосующий диск могут существовать как файлы на томе OCFS. В приведенных ниже приые рах для диска с OCR и для голосующего диска будут использоваться “чис тые” устройства — таковы рекомендации Oracle.
Программное обеспечение CRS поставляется на одном CD-ROM. По. еле того как он будет смонтирован, от имени пользователя Oracle нужц0 запустить сценарий ./runinstaller. Первый появившийся после экрану приветствия и экрана местонахождения Oracle Inventory экран изображен на рис. 11.2.
Инсталляция CRS похожа на инсталляцию базы данных; следует указать домашний каталог для размещения выполняемых модулей. В этом случае будет использоваться домашний каталог CRSlOgHome, который не должен совпадать с домашним каталогом для базы данных Oracle.
После выбора языка инсталляции необходимо предложить имя кластера, а также публичные и приватные имена узлов. Как видно на рис. 11.3, указываются имя кластера led и те публичные и приватные имена узлов, что были ранее определены в файле /etc/hosts.
На следующем экране инсталляции (см. рис. 11.4), указывается, какое из сетевых устройств будет использовано в качестве публичного интерфейса (для подключения к публичной сети), а какое — в качестве приватного межузлового соединения для поддержки механизма Cache Fusion (синхронизации кэшей экземпляров) и передачи сообщений, подтверждающих нормальное функционирование узла. Можно иметь более одного публичного и приватного интерфейсов; на этом же экране
Рис. 11.2. Местонахождение выполняемых файлов
pe^l Application Clusters
435
J
Cluster Configuration
Specifythe cluster name For earn node in me cluster, specify the public name (the host name}, and tlx» private name, to be used to interconnect tne nodes within the cluster The private name cannot be the same as the pubhc name, bx can toe an ip address.
Cluster Name : ler.1
Ouster Nodes
Public Node Name * '
Private Node Name
ocl
oc2
0(3
cocl P0C2 рос?
installed Products
Hep
ga:k
Cancel
Уек!
i
Рис. 11.3. Конфигурация кластера
Private Interconnect Enforcement
Use this page to identify the interfaces to use as prtvaie interconnects
If there is more than one subnet associated with ал interface, then activate the drop down menu by clicking in me subnet cell Select a subnet for which wu want to modify the ’nterface type Mark the global network interfaces that are available across ali the cluster nodes as either Private, Public, or Do Not use.
«I
Interface Name
UAs- j» «едм;
jethO
Subnet
Interface Type
jethl
’i
192 168 2 0
192.163 10
: Public
Private
4
>
Help
Installed products
Sack yext
Cancel
Рис. 11.4. Принудительное применение приватного межузлового соединения
436
Гпава 11
Рис. 11.5. Реестр кластера Oracle
можно также отметить, что интерфейс вообще не должен использоваться CRS.
На рис. 11.5 нужно указать /dev/raw/raw5 как “чистый” диск для реестра кластера Oracle. OCR является репозиторием метаданных для конфигурации кластера, отслеживающим такие моменты, как место выполнения того или иного конкретного сервиса, выполняется ли он вообще и т. п.
Аналогичным образом указывается местоположение голосующего диска для CRS. На рис. 11.6 указывается /dev/raw/raw6 как “чистый диск для голосующего диска. Процесс, известный как Cluster Synchronization Services (CSS — сервис синхронизации кластера), использует голосующий диск для арбитража прав владения кластером и для межпроцессных коммуникаций в кластерной среде. В среде, где есть только один экземпляр, CSS облегчает коммуникации между экземпляром ASM и эк земпляром СУРБД.
Следующий экран, изображенный на рис. 11.7, предписывает выпол нить на каждом из узлов кластера сценарий orainstRoot.sh для создан каталогов и установления прав доступа к ним; такой сценарий должен вЫ полняться от имени пользователя root.
После появления экрана подведения итогов перед инсталляцией (р installation summary), показанного на рис. 11.8, нужно щелкнуть накно Install (приступить к инсталляции), после чего и начинается процесс сталляции. Вдобавок к инсталляции программного обеспечения на узле, где инсталляция была инициирована, оно будет инсталлировано на всех остальных узлах кластера.
После завершения инсталляции еще раз поступит предложение в полнить на каждом узле кластера сценарий от имени пользователя го
peal Application Clusters
Рис. 11.6. Место нахождения голосующего диска
Certain actions need to be performed with root privileges before the install can continue. These actions are stored in a shell script named /uOl/app/orade/orainventory/orainstRoot sh
Please execute the
/uOl/app/oracle/oralnventory/oramstRoot sb script now from another window on all cluster nodes, then dick 'Continue" to continue the install <
• 'Л ' ,?'X' v •. : !
h’S ' ’ -
Cancel
Рис. 11.7.
Сценарий, выполняемый от имени пользователя root
438
Гпава if
Summary
Cluster Ready Services 10,1.0.2.0
i'„'f Л"*&ЧЛ’^Л * • Jy’i'e'S" ** -• •*глл' .. .. . kuV/^.->" ». . v-.v»-, АЧМ^* .... ••<. . . j.Л.»•».--
S Global Settings
Source /InttaiUcrslCg/Diskl/stage/producis *ml
*- Oracle Home /uCl/app/orade/proauci/10 1 O/CRSlOgHome (CRSlCsHome;
r Ouster Nodes
ocl
; кз
। CC2
Installation Type Complete
1 Э Product Languages
English
к Spate Requirements
/ Required 335M8 (includes 2 2 MB temporary Available 9 12G9
к Remote Nodes
z New Installations (24 products)
Рис. 11.8. Подведение итогов перед инсталляцией
Ниже приводятся выходные данные выполнения команды па первом узле:
□ [root@oc1 mnt]# /u01/app/oracle/product/10.1.0/CRS10p Home/root.sh Checking to see if Oracle CRS stack is already up . . .
(Проверка, чтобы убедиться, что стек Oracle CRS уже работает . . .) /etc/oracle does not exist. Creating it now.
Setting the permissions on OCR backup directory
(Установка разрешений на каталог резервного копирования OCR) Oracle Clusters Registry configuration upgraded successfully (Конфигурация Oracle Clusters Registry успешно обновлена)
WARNING: directory ‘/u01/app/oracle/product/10.1.0 is not owned by root
WARNING: directory ‘/u01/app/oracle/product’ is not owned by root WARNING: directory ‘/u01/app/oracle/’ is not owned by root assigning default hostname oc1 for node 1.
(назначение используемого по умолчанию имени хоста ос1 для узла 1) assigning default hostname ос2 for node 2.
(назначение используемого по умолчанию имени хоста ос2 для узла £) assigning default hostname осЗ for node 3.
(назначение используемого по умолчанию имени хоста осЗ для узла 3; Successfully accumulated necessary OCR keys.
(Успешно накоплены необходимые ключи OCR.)
Using ports: CSS=49895 CRS=49896 EVMC=49898 and EVMR-49897.
(Используем порты: CSS=49895 CRS-49896 EVMC=49898 и EVMR=49897.) node <nodenumber>: <nodename><private interconnect namexhostna e> (узел <номер_узла>: <имя_узла> <имя_приватного_межузлового_соединени <имя_хоста>)
al Application Clusters
439
node 1: od pod od node 2: oc2 poc2 oc2 node 3: осЗ росЗ осЗ Creating OCR keys for user ‘root’, privgrp ‘root’.. Operation successful.
Now formatting voting device: /dev/raw/raw6 Successful in setting blockO for voting disk. Format complete.
Adding daemons to inittab
Preparing Oracle Cluster Ready Services (CRS):
Expecting the CRS daemons to be up within 600 seconds.
(Создание ключей OCR для пользователя ‘root’ privgrp ‘root’.. Операция успешна.
Теперь форматируем голосующий диск: /dev/raw/raw6
Успешно создан блок 0 для голосующего диска.
Форматирование завершено.
Добавление демонов к inittab
Подготовка Oracle Cluster Ready Services (CRS):
Предполагается, что демоны CRS будут в рабочем состоянии не позднее, чем через 600 сек.)
CSS is active on these nodes.
(CSS активна на следующих узлах.) od
CSS is inactive on these nodes.
(CSS неактивна на следующих узлах.)
ос2
осЗ
Local node checking complete.
Run root.sh on remaining nodes to start the CRS daemons.
(Локальная проверка узлов завершена.
Выполните root.sh на остальных узлах, чтобы запустить демоны CRS.) [root@oc1 mnt]#
Голосующий диск и диск с OCR инициализируются при самом первом выполнении этого сценария. Когда сценарий будет выполняться на остальных двух узлах, вы увидите похожие результаты, за исключением инициализации диска с OCR и голосующего диска; здесь приводятся результаты для второго узла, ос2:
[root@oc1 etc]# ssh ос2
Last login: Thu Oct 14 19:32:44 2004 from od
[root@oc2 root]# /u01/app/oracle/product/10.1.0/CRS10g Home/root.sh
6 ecking to see if Oracle CRS stack is already up . . .
(Проверка, ч обы убедиться, что стек Oracle CRS уже работает . . .) • •
clscfg: EXISTING configuration version 2 detected.
(clscfg: обнаружена существующая конфигурация версии 2.)
clscfg: version 2 is Юр G Released
(clscfg: версия 2 - это Юр G Released) assigning default hostname od for node 1.
(назначение используемого по умолчанию имени хоста od для узла 1)
440
Глав$
assigning default hostname ос2 for node 2.
(назначение используемого по умолчанию имени хоста ос2 для узла 2) assigning default hostname осЗ for node 3.
(назначение используемого по умолчанию имени хоста осЗ для узла 3) Successfully accumulated necessary OCR keys.
(Успешно накоплены необходимые ключи OCR.)
Using ports: CSS=49895 CRS-49896 EVMC-49898 and EVMR-49897 (Используя порты: CSS-49895 CRS-49896 EVMC-49898 и EVMR-49897.) node <nodenumber> <nodename><private interconnect name><hostname> (узел <номер_узла>: <имя_узла> <имя_приватного_межузлового_соединения> <имя_хоста>) node 1: od pod od node 2: ос2 рос2 ос2 node 3: осЗ росЗ осЗ
clscfg: Arguments check out successfully.
NO KEYS WERE WRITTEN. Supply -force parameter to override.
-force is destructive and will destroy any previous cluster configuration.
Oracle Cluster Registry for cluster has already been initialized
Adding daemons to inittab
Preparing Oracle Cluster Ready Services (CRS):
Expecting the CRS daemons to be up within 600 seconds.
(clscfg: Проверка аргументов проведена успешно.
КЛЮЧИ НЕ БЫЛИ ЗАПИСАНЫ. Предоставьте параметр -force для переопределения. Параметр -force является деструктивным и приведет к разрушению любой ранее имевшейся конфигурации кластера.
Oracle Cluster Registry уже был проинициализирован.
Добавление демонов к inittab.
Подготовка Oracle Cluster Ready Services (CRS):
Предполагается, что демоны CRS будут в рабочем состоянии не позднее, чем через 600 сек.)
CSS is active on these nodes.
(CSS активен на следующих узлах.) od
ос2
CSS is inactive on these nodes.
(CSS неактивен на следующих узлах.) осЗ
Local node checking complete.
Run root.sh on remaining nodes to start CRS daemons.
(Локальная проверка узлов завершена.
Выполните root.sh на остальных узлах, чтобы запустить демоны CRSJ [root@oc2 root]#
Для третьего и последнего узла трехузлового кластера видны ан ные сообщения с подтверждением, что запущены процессы CRSD и
□ [root@oc2 root]# ssh осЗ
Last login: Thu Oct 14 20:40:15 2004 from oc2
[root@oc2 root]# /u01/app/oracle/produc /10.1.0/CRS10gHome/root.sh
I Application Clusters
441
Checking to see if Oracle CRS stack is already up . . . /etc/oracle does not exist. Creating it now.
(Проверка, находится ли стек Oracle CRS в рабочем состоянии. . . /etc/oracle не существует. Создайте его сейчас.)
Adding daemons to inittab
Preparing Oracle Cluster Ready Services (CRS):
Expecting the CRS daemons to be up within 600 seconds.
(Добавление демонов к inittab
Подготовка Oracle Cluster Ready Services (CRS):
Предполагается, что демоны CRS будут в рабочем состоянии не позднее, чем через 600 сек.)
CSS is active on these nodes.
(CSS активен на следующих узлах.)
od
ос2
осЗ
CSS is active on all nodes. (CSS активен на всех узлах.) Waiting for the Oracle CRSD and EVMD to start Oracle CRS stack installed and running under init (1M) (Ожидаем запуска Oracle CRSD и EVMD
Стек Oracle CRS инсталлирован и выполняется в режиме инициации (1М)) [root@oc3 root]#
Примечание Обсуждение демонов CRSD и EVMD выходит за рамки данной книги; см. книгу Харта и Джесси издательства Oracle Press Oracle Database 10д High Availability with RAC, Flashback & Data Guard (“Высокодоступные базы данных Oracle 10j с опциями RAC, Flashback и Data Guard”).
Можно убедиться в том, что инсталляция CRS завершилась успешно, сделав текущим каталог с исполняемыми модулями CRS (в домашнем каталоге CRSlOgHome) на любом из узлов, а затем выполнив эту команду: [oracle@od oracle] $ cd /u01/app/oracle/product/10.1.0/CRS10g Home/bin [о acle@oc1 bin]$ olsnodes -n od 1
oc2 2
осЗ з
[oracle@oc1 bin]$
Выходные данные команды olsnodes отображают имена и номера узлов, на которых выполняются CRS.
Инсталляция программного обеспечения базы данных
После того как кластерное программное обеспечение начало успешно работать на каждом узле кластера, можно инсталлировать программное обеспечение базы данных в один и тот же каталог на каждом узле.
442
Хотя можно создать базу данных одновременно с инсталляцией пп граммного обеспечения Oracle, сначала только инсталлируется програ^ ное обеспечение, а затем используется утилита Database Configurate Assistant (DBCA — помощник по конфигурированию сервера базы данные для создания базы данных. Из корневого каталога CD с инсталляцией базь{ данных нужно выполнить сценарий ./runinstaller как пользователь oracle точно так же, как при инсталляции CRS. Первый экран, который появится после экрана приветствия и экрана определения места нахождения Oracle Inventory, показан на рис. 11.9.
Хотя программное обеспечение можно инсталлировать в любой каталог, следует убедиться в том, что этот каталог доступен для пользователя oracle на всех узлах кластера и что инсталляция производится не в тот каталог, в который производилась инсталляция CRS.
Если инсталлятор обнаруживает, что на этом узле выполняется кластерное программное обеспечение, он дает возможность либо инсталлировать программное обеспечение на всем кластере, либо выполнить инсталляцию одного экземпляра (см. рис. 11.10). В этом случае выбирается инсталляцию для всех узлов, сконфигурированных ранее как части кла-
стера.
Как и при инсталляции единственного экземпляра, можно сделать выбор между средой для разработки корпоративных приложений (Enterprise Edition) и стандартной версией (Standard Edition). Нужно выбрать вариант, совместимый с имеющимися возможностями лицензирования. После этого инсталлятор подтверждает, что среда программного обеспечения базы данных Oracle сконфигурирована правильно (см. рис. 11.11).
Specify File Locations
Source
Enter the full oath of the file representing the produces) you want to install path /instali/dblCg/OisKi/siage/produas xml
Browse.
Destination
Enter or select a name for the installation and the ful path where you want to install the product
Name: .DBlOgHome
P3’h /'jOl/appfo'acle/product/lO 1 0/D310gHuine
About Q*"acie Universal Installer
installed Products gacH
Next
Cancel
а.
Рис. 11.9. Места нахождения файлов базы данных Oracle
Clusters
443
Specify Hardware Cluster Installation Mode
* Cluster Installation
Select nodes (in addition to the local node) и rhe hardware cluster where the installer should install products tnai you select in this installation.
Node Name
V*. .. Xv> zvz.Av.OZ/-»'- • -.4» >v*s.X‘MvsA-A>'a,a<>
CC1
> cc2
'«> ocS
. I
*
deselect Ail
Local Installation
Select this option if you want to perform a single node non-clu«ier mstaliation even though the local node is pan of a hardware cluster
Рис. 11.10. Места нахождения аппаратного обеспечения узлов кластера
The installer wH now verity that the system meets all the minimum requirements for instating and configuring the chosen product You are required to manually venty and confirm the Herns that are flagged as warnings or manual checks. For details on performing these checks, dick on the item and see the details at the bottom
Check Type Status
x.tjttxjriy'0peidiiitv:$yitv:incetim<.auOH' — .... ‘
Checking kernel parameters Automahc : Succeeded
— -----' ............. u II Uiim»№1 ..I 1*1 II ...
ChecKfr^^cohyn^n j pitku :t; A*jtemat;c: • "JS UsfirVenuei i
; Checking recommended snt>c version Automatic "Succeeded
Yai dating ORACLE. BASE location (>f set) Automatic П: Succeeded
• -i • .... -
Retry.
О requirements to be -verified
* * .4 *s >\._ z . * - J • » * . ...'/:
Checking for cpenmctMfio-liTfound Not touncL~ Faffed <<<<*"' Check complete. The overall result of this check is; Failed < c < < Problem. Seme recommended packages are missing (see above) Recommendation. You may actualiy have installed packages which have obsoieted these, in which case you can successfully continue with the install If \ou have not, it Is recommenced that you do
Рис. 11.11. Проверки конфигурации платформы
444
'’’'/"FT"—TT
Summary
Oracle Database 10g 10.1.0.2.0
^Global Settings
I
Source /insiail/dblOg/Dlskl/stage/producis xml
Oracle Horne /uOl/app/oracie/produci/10 1 o/D810gHorne (DBlOgHome)
Cluster Nodes
« * ocl
i
осЗ
| j Installation Type Enterprise Edition
IA Product Languages i *
/. i i
English
Space Requirements
/ Required 985МБ (includes 128MB temporary Available 8.69СБ
(♦'Remote Nodes
г1 New Installations Ц51 products)
•
bep
installed Products
Back
Cancel
|n$tai!
Рис. 11.12. Сводка итогов для базы данных перед инсталляцией
В процессе инсталляции можно получить сообщения или предупреждения о пропущенных или имеющих неверные версии пакетах или отдельных продуктах; так, на рис. 11.11 инсталлятор вообще не обнаружил пакета openmotif. Убедиться в том, что пакет был инсталлирован, можно с помощью команды примерно следующего вида:
□ [root@oc1 root]# rpm -q openmotif openmotif -2.2.3-3.RHEL3 [root@od root]#
Поскольку в системе есть более поздняя версия пакета openmotif, м°ж но без опаски указать, что пакет имеется в наличии, и щелкнуть на Next-На следующем экране база данных стартеров (starter database)ne выбира ется; она будет создана позже с помощью DBCA.
Итоговый экран (см. рис. 11.12) практически идентичен экрану, кот^ рый мы уже видели при инсталляции единственного экземпляра, за исключением, что программное обеспечение устанавливается сразу
несколько узлов кластера. ядИ#-
Последующие экраны детализируют прогресс процесса инсталл После завершения будет предложено выполнить новый сценарии i на каждом из узлов кластера. Ниже приводятся результаты выпо. сценария на первом узле (для выполнения этого сценария необх у быть зарегистрированным как привилегированный (root) пользова
□ [root@od root]# /u01/app/oracle/product/10.1.o/DB1Og Home/root.sh
Running OraclelO root.sh script . •
\nThe following environment variables are set as:
peal Application Clusters
445
ORACLE_OWNER = oracle
ORACLE_HOME = /u01/app/oracle/product/10.1.O/DBIOg Home
Enter the full pathname of the local bin directory: [/usr/local/bin]:
Copying dbhome to /usr/local/bin . . .
Copying oraenv to /usr/local/bin . . .
Copying coraenv to /usr/local/bin ...
\nCreating /etc/oratab file. . .
Adding entry to /etc/oratab file. . .
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
[root@oc1 root]#
(Выполняется сценарий Oracle 10 root.sh. . .
\Приведенные ниже переменные окружения установлены как:
0RACLE_0WNER = oracle
ORACLE-HOME = /и01/арр/оracle/product/10.1.0/DB10gr Home
Введите полное путевое имя для локального каталога двоичных модулей [/usr/local/bin]: :
Копируем dbhome в /usr/local/bin . . .
Копируем oraenv в /usr/local/bin . . .
Копируем coraenv в /usr/local/bin . . .
\пСоздаем файл /etc/oratab. . .
Добавляем элементы в файл /etc/oratab. . .
При создании базы данных записи будут по мере необходимости добавляться в файл /etc/oratab утилитой Database Configuration Assistant Закончено выполнение общей части сценария root.sh.
Теперь будут выполнены привилегированные действия, зависящие от продуктов. [root@od root]#)
Только для первого узла в кластере этот сценарий порождает процесс Virtual IP Configuration Assistant (VIPCA) для конфигурирования виртуальных IP-адресов, которые будут использоваться для восстановления последствий сбоя приложения, и процесс агента Enterprise Manager. После экрана приветствия VIPCA предлагается экран сетевых интерфейсов (NetworkInterfaces), показанный на рис. 11.13, со списком физических сетевых интерфейсов, доступных для этого сервера. Нужно выбрать публичный интерфейс и щелкнуть на Next.
На рис. 11.14 вводится одно из виртуальных имен узлов IP, специфицированных ранее в файле /etc/hosts (в данном случае vocl). Инсталлятор автоматически заполняет все другие имена псевдонимов и адреса из / etc/hosts.
После того как будет показан итоговый предынсталляционный экран, нужно щелкнуть на Next; представленный па рис. 11.15 экран отображает прогресс процесса инсталляции для всех трех узлов.
После завершения инсталляции необходимо открыть сеансы на каждом из остальных узлов кластера и-выполнить сценарий root.sh на оставшихся узлах. Сценариями будут продуцированы результаты, аналогичные тем, что мы наблюдали на первом узле, но, поскольку они уже были конфигурированы посредством VIPCA, будет получено сообщение
446
Гпава
Рис. 11.13. Сетевые интерфейсы VIPCA
Clear Clear all
Back
Next
Рис. 11.14. Адреса VIPCA для узлов кластера
IP addresses are required for defining virtual IP resource application for each duster node
Node name IP Alias Name ip address Subnet Mask
jod V0C1 192 168 2 17$ 255.255255 .0
|oc2 voc2 192.168.2 177 255 255 255 0 |
осЗ vocB 192 168 2 178 255.255 255.0
peal Application Clusters
447
Рис. 11.15. Прогресс инсталляции VIPCA
□ CRS resources are already configured (Ресурсы CRS уже сконфигурированы)
и VIPCA не будет запущен. Для кластера достаточно сконфигурировать VIPCA всего один раз.
Теперь, когда программное обеспечение инсталлировано, можно приступить к созданию базы данных, а также одного экземпляра базы данных на каждом из узлов кластера. Это будет проделано в следующем разделе. Можно создать базу данных стартеров непосредственно в процессе инсталляции программного обеспечения, но запуск утилиты DBCA дает больше возможностей и обеспечивает большую гибкость при создании базы данных и нового экземпляра.
Создание базы данных RAC с помощью Database Creation Assistant
Запуск Database Creation Assistant (DBCA) для инсталляции базы данных RAC во многом аналогичен запуску DBCA для одиночного экземпляра; если DBCA обнаруживает инсталлированное кластерное программное обеспечение, он дает возможность инсталлировать либо базу данных RAC, либо одиночный экземпляр базы данных (см. рис. 11.16) после запуска DBCA:
[oracle@oc1 oracle] dbca &
После выбора варианта создания базы данных будет предложено изображенное на рис. 11.17 диалоговое окно; необходимо выбрать участвующие в кластере узлы. В нашем случае выбираются все узлы.
На следующем экране необходимо выбрать тип базы данных: хранилище данных, база данных общего назначения, база данных лля обпаботкм
448
Глава
Welcome to the Database Configuration Assistant for Oracle Real Application Clusters
The Database Configuration Assistant enables you co create, configure,-or delete a cluster database ana manage database templates It also enables you to add and delete instances and to add, delete, and modify services of a cluster database
Select the database vpe that you would hke to create or administer
» Oracle Real Application Clusters database
Oracle single instance database
Cancel Help ...................—___
Рис. 11.16. Варианты типов экземпляра в DBCA
Рис. 11.17. Узлы для включения в инсталляцию RAC
peai Application Clusters 449
транзакций или заказная база данных. В случае создания базы данных RAC выбранный тип базы данных не изменит конфигурации кластера.
На четвертом шаге DBCA кластерной базе данных присваивается имя и префикс SID точно так же, как это делается при инсталляции автономной базы данных. На пятом шаге делается запрос, требуется ли конфигурировать RAC для использования ЕМ Database Control (управление базами данных ЕМ), и как следует конфигурировать RAC: с использованием ЕМ Control или Grid Control. Нужно специфицировать почтовый сервер и адрес электронной почты для отправки уведомлений АБД. На шестом шаге следует указать пароль привилегированных учетных записей в базе данных: SYS, SYSTEM, DBSNMP и SYSMAN. На седьмом шаге специфицируется ASM как метод сохранения файлов базы данных. Наконец, на восьмом шаге нужно указать параметры экземпляра ASM, как это было сделано в главе 4.
Экземпляры ASM, хотя они и доступны для управления средой хранения для автономных баз данных, идеально подходят для использования в базах данных RAC. ASM устраняет и необходимость конфигурирования “чистых” устройств (они отображаются один раз на экземпляр ASM и в последующем являются доступными для всех узлов кластера), и необходимость наличия кластерной файловой системы для файлов баз данных. Такие кластерные файловые системы, как кластерная файловая система Oracle (Oracle Cluster File System — OCFS), продолжают оставаться доступными, если нужно иметь общий ORACLEJHOME в кластерной файловой системе вместо того, чтобы иметь его копию па каждом узле кластера. В методических указаниях Oracle рекомендуется иметь собственную локальную копию программного обеспечения Oracle в каждом узле (подробнее о конфигурировании и использовании ASM см. главу 4). Если используется ASM, на протяжении этих шагов ее нужно конфигурировать всего один раз.
Примечание OCFS версии 2.x поддерживает разделяемый каталог Oracle Home.
На нескольких следующих экранах отслеживается создание экземпляра ASM. После завершения этого процесса будет предложено создать первую дисковую группу ASM (см. рис. 11.18). Нужно выбрать два из числа чистых” устройств, доступных для дисковой группы DATA1, используя обычную избыточность. Кроме того, дисковая группа RECOV1 создается с помощью двух оставшихся дисковых групп; эта дисковая группа будет использована для зеркалирования управляющих и журнальных файлов, а также для размещения области группового flash-восстановления (Flash Recovery Area). На рис. 11.19 DATA1 специфицируется как дисковая группа для хранения базы данных. На рис. 11.20 специфицируется RECOV1 Для области группового flash-восстановления.
На следующем шаге (см. рис.11.21) показана еще одна опция, с которой мы не сталкивались при инсталляции единственного экземпляра: создание заказного сервиса RAC.
Создаваемый на рис. 11.21 сервис добавляет еще один элемент для racsvc в файле tnsnames.ora в дополнение к создаваемому при создании файла tnsnames.ora стандартному элементу (гас), как это видно из следующего листинга:
450
Глава i j
Disk Croup Name. DATA1| Redundancy
High
1 Norma
, < External
Select Member Disks
* Show Candidates Show All
Г Disk Path
Header Status ASM Name Failure Croup Size (MB)
/dev/raw/raw4 CANDIDATE 13236
/dev/raw/'-awS CANDIDATE 10236
/dev/raw/raw2 CANDIDATE 10236
/dev/raw/rawl : CANDIDATE 10236
Note if you don't see disks which you.believe should be available you may need io change the disk discover-/ path
Change Disk Discovery Path
0K: Cancel Help
Рис. 11.18. Создание “чистого" диска Ns 1 ASM
Available Disk Croups
Select Disk Croup Name
t REC0V1
•4
Size -MB)
20472
Create New Add Disks
Select one or more disk groups to be used as storage tor the database You can choose to create a new disk group or add disks to an exiting disk group
Cancel
Help
Sack
Free (MB)
20372
Рис. 11.19. Выбор дисковой группы ASM для хранения
,/ Application Clusters
451
Рис. 11.20. Выбор диска ASM для области группового flash-восстановления
Рис. 11.21. Создание сервиса ВАС
452
Глава 1ч
□ гас =
(description =
(address = (protocol = tcp) (host = voc1) (port = 1521))
(address = (protocol = tcp) (host = voc2) (port = 1521))
(address = (protocol = tcp) (host = voc3) (port = 1521))
(load_balance = yes)
(connect_data =
(server = dedicated)
(service_name = rac.world)
)
)
listener_rac =
(address_list =
(address = (protocol = tcp) (host = vod) (port = 1521))
(address = (protocol = tcp) (host = voc2) (port = 1521))
(address = (protocol = tcp) (host = voc3) (port = 1521))
)
racsvc =
(description =
(address = (protocol = tcp) (host = voc1) (port = 1521))
(address = (protocol = tcp) (host = voc2) (port = 1521))
(address = (protocol = tcp) (host = voc3) (port = 1521))
(load-balance = yes)
(connect_data =
(server = dedicated)
(service-name = racsvc.world)
(failover-mode =
(type = select)
(method = basic)
(retries = 180)
(delay = 5)
)
)
)
rac3 =
(description =
(address = (protocol = tcp) (host = voc3) (port = 1521))
(connect_data =
(server = dedicated)
(service_name = rac.world)
(instance.name = rac3)
)
)
rac2 -
(description =
(address = (protocol = tcp) (host = voc2) (port = 1521))
Clusters
453
(connect_data =
(server = dedicated)
(service_name = rac.world) (instance_name = rac2)
)
)
rad =
(description =
(address = (protocol = tcp) (host = vod) (port = 1521)) (connect_data =
(server = dedicated)
(service_name = rac.world)
(instance_name = rad)
)
)
Для каждого узла в RAC имеется собственный элемент файла, так что при необходимости можно подключиться к конкретному узлу. В именах хостов для каждого узла вместо имен физических узлов используются имена виртуальных узлов.
В элементе для racsvc есть несколько дополнительных параметров для FAILOVER_NODE; эти режимы и их значения определены в приведенном ниже списке:
type Тип преодоления последствий сбоя. Если указано значение session, для клиента создается новый сеанс, но при этом не сохраняется позиция в курсоре, если в момент сбоя выполнялся оператор SELECT. При указании select сохраняется состояние курсора во время выполнения оператора SELECT, но требуются дополнительные “накладные расходы” на клиентской стороне. Используемое по умолчанию значение режима попе блокирует функциональные возможности преодоления последствий сбоя.
method Как быстро происходит преодоление последствий сбоя. При использовании значения basic для преодоления последствий сбоя производится создание соединения, и это не влечет никаких накладных расходов на сервере (серверах) резервного копирования. Задание значения preconnect обеспечивает более быстрое преодоление последствий сбоя, но, как это следует из названия метода, при этом используются ресурсы на сервере (серверах) резервного копирования, даже когда сценарии преодоления последствий сбоя не активны.
retries Число попыток подключения после преодоления послед-
ствий сбоя.
delay Количество времени (в секундах) между попытками соеди-
нения при активном сценарии преодоления послс*Дствий сбоя.
Ниже в данной главе показывается, как подключений к сервису racsvc гарантирует высокую доступность клиентских подклю^ени^» когда клиент подключился к узлу, а затем этот узел вышел тло-*г
454
Следующие несколько экранов являются такими же, как и при инстад, ляции базы данных с единственным экземпляром (о предлагаемых этих экранах опциях см. главу 1). На рис. 11.22 подводятся итоги инстад. ляции кластерной базы данных, в которые включено место нахождения файла SPFILE и дисковой группы DISK1 для базы данных.
После завершения инсталляции ЕМ Database Control автоматически конфигурируется и запускается; как и в случае инсталляции одиночного экземпляра; однако при этом можно управлять всем кластером, а не только его отдельными узлами.
Примечание Инсталляция и конфигурирование Enterprise Manager Grid Control выходит за рамки настоящей книги. Дальнейшую информацию по этим вопросам можно получить в книге Харта и Джесси издательства Oracle Press Oracle Database 10ff High Availability with RAC, Flashback & Data Guard (“Высокодоступные базы данных Oracle 10ff с опциями RAC, Flashback и Data Guard”).
На рис. 11.23 можно видеть, что вход в систему через ЕМ Database Control подключает вас ко всему кластеру в целом, а не к одному из узлов.
Как и для базы данных, имеющей всего один экземпляр, на домашней странице базы данных можно увидеть ее статус. Снова отличие состоите том, что ЕМ Database Control готова к работе в составе кластера. На рис. 11.24 можно видеть статусы экземпляров Oracle в составе кластера, а на рис. 11.25 — статус кластера в целом; CRS управляет кластером как отдельным продуктом в базе данных.
На рис. 11.26 видны характеристики одного из членов группы журналов для кластера; один из членов группы помещен в дисковую группу DATA1, а два других — в дисковую группу RECOV1. Поскольку каждая дисковая групп зеркалируется на двух различных “чистых” устройствах, мы получаем эквивалент четырехкратной избыточности для членов нашей группы журналов.
racworld rac
+DATAl/rac/5pfilerac ora
Database creation complete. Check the logfiles at /uOl/app/orade/admin/rac/create fordetatis
[ Database Information
Global Database Name'
System IdentifierCSID) Prefix л Server Parameter Filename
=. -c—........... , v ....
Note. All database accounts except SYS, SYSTEM, DBSNMP, and SYSMAN are locked. Select the Password Management button to view a complete list of locked accounts or to manage the database accounts From the Password Management window, unlock only the accounts you will use. Oracle Corporation strongly recommends changing the default passwords Immediately after unlocking the account.
Q Password Management. J
r.
’ iv?1 ** *•• V V* •: •
;
И
J \’:j
Exit j
□«г 11 22 Создание базы данных МС с помощью DBCA завершено
fieal Application Clusters
455
Рис. 11.23. Вход в систему через ЕМ DB Control
Рис. 11.24. Статус кластерной базы данных ЕМ DB Control
456
Но ЕЛ N6e** Favorite* Tooh Heb
Гпава 11
; 0В«к • 0 g J2j Й ^Search Favorites ^gj ’ g • £J
• '’^ ' (*jtttp://192 168.2.10l:S5CO/enfcon5ote'cac/durter/recOusterSterriap?tyve«du«erttarQet4ec|&event«dolc 4'-. Go
ОГ5АССЙ UntetffHse Mlimgof Юс Й&Я Рак^к-а? tlst
f1 teb азд-CaM.*u? DdiibasS
Cluster lec I
L>i<s? Ljo Oothztvd For* Ocf M 2Ш Ю:й/*20 PM Refresh^
Hom* 1&2&L
General
Current Status Up Availability (%)
Л.\У
Up Nodes 3 3
Conf!$UI3t&n
Cluslerware Version 1.1
View Hardware
U 51V’ *Г |t » t<t$|
(686AuthenticAMD £86 д
Cluster Databases
'J I. S!iu«^'P | ____________________________________•
'<*«►». Wi |»| .... ;*»>>< я w»«* >>1» »нД.1Мм»«и1я*|»»и.>Ч|Ц|»<«»11|1.чГ111П! . 4> 44Hhui*,.*a«»»jw>*.»*'»iiIii4ii>»ii hi
л 5»Z. ......4... ....... 3-
Рис. 11.25. Статус аппаратного обеспечения кластера ЕМ DB Control
Рис. 11.26. Члены группы журналов RAC ЕМ DB Control
peal Application Clusters
457
Характеристики базы данных RAC
Экземпляр RAC во многом отличается от автономного экземпляра. В этом разделе будут показаны параметры инициализации, которые работают только для экземпляра RAC, а также некоторые представления словаря данных и динамические представления производительности, которые либо используются только в средах RAC, либо имеют столбцы, заполняющиеся только в том случае, если экземпляр является частью RAC.
Характеристики файла параметров сервера
Файл параметров сервера (SPFILE) постоянно хранится в дисковой группе DATA1 и поэтому разделяется (совместно используется) всеми узлами кластера. В SPFILE можно назначать данному параметру различные значения для разных экземпляров; другими словами, значения параметров инициализации могут быть различными для разных экземпляров. Если параметр инициализации имеет одинаковое значение для всех узлов кластера, ему предшествует префикс в противном случае в качестве префикса используется имя узла.
В этом примере физическая память на сервере ос2 кластера временно уменьшена. Следовательно, для сокращения запросов к экземпляру на сервере при последующих перезапусках экземпляра необходимо изменить значение SHARED_POOL_SIZE для экземпляра гас2:
□ SQL> select sid, name, value
2 from v$spparameter where name = ‘shared_pool_size’;
SID NAME
VALUE
shared_pool_size 65614720
SQL> alter system set shared_pool_size=48M 2 scope=spfile sid 1rac2*;
System altered.
SQL> select sid, name, value
2 from v$spparameter whe re name = ‘shared_pool_size';
SID NAME VALUE
* shared_pool_size 65614720 \
rac2 shared_pool_size 50331648
После того как проблемы с памятью будут разрешены, можно восстановить размер разделяемого пула на экземпляре гас2 следующим образом:
О SQL> alter system set shared_pool_size=64M
2 scope=spfile sid=*rac2’;
System altered.
SQL>
458
Гпава 11
Параметры инициализации, относящиеся к RAC
Некоторое количество параметров инициализации используются только в средах RAC. Хотя эти параметры (см. таблицу 11.3) существуют в любом экземпляре, в средах с одним экземпляром они либо являются пустыми (т. е. не имеют значения. — Прим, пер.), либо имеют значение 1 (например параметр INSTANCE-NUMBER).
Таблица 11.3. Связанные с RAC параметры инициализации
Параметр инициализации Описание
INSTANCE-NUMBER Уникальное число, идентифицирующее экзем-
пляр в кластере.
II\ISTANCEJ\IAME Уникальное имя этого экземпляра в кластере;
обычно это имя кластера с цифровым окончанием.
CLUSTER-DATABASE
CLUSTER-DATABASEJNSTANCES
ACTIVE_INSTANCE_COUNT
CLUSTERJNTERCONNECTS
MAX-COMMIT-PROPAGATION-DELAY
Имеет значение TRUE, если данный экземпляр является элементом среды RAC.
Количество экземпляров, сконфигурированное для этого кластера, независимо от того, активен тот или иной экземпляр или нет.
Специфицирует первичный (основной) экземпляр двухузлового кластера; для кластеров с большим числом узлов — число экземпляров в кластере.
Специфицирует сеть, используемую для IPC-трафика кластера.
Контролирует, насколько быстро зафиксированные транзакции передаются на другие узлы.
Динамические представления производительности
В средах, где существуют только одиночные экземпляры, для всех дина мических представлений с именами, начинающимися с V$, имеются со ветствующие представления, начинающиеся с GV$, в которые вклю дополнительный столбец INSTJD; его значение всегда равно 1. Для ср RAC с двумя узлами в представлениях, начинающихся с GVJ >, сод ер вдвое больше строк, чем в соответствующих представлениях V$. Точ так же для RAC с тремя узлами строк становится в три раза больше и • В последующих разделах рассматриваются некоторые динамичес представления производительности V$, которые дают один и тот же тент независимо от того, к какому узлу вы подключены, наряду с предс лениями GV$, которые могут показать контент представлений V$ ня К дом из узлов, не подключаясь явно к этому узлу.
459
г
peal Application Clusters
Общие представления файлов базы данных
Некоторые динамические представления производительности являются одинаковыми, работаете ли вы в среде RAC или в среде с одиночными экземплярами. Прекрасные примеры таких представлений дает конфигурирование ASM. В следующем запросе требуется проверить, что все файлы базы данных хранятся в одной из двух дисковых групп ASM, +DATA1 или +RECOV1:
□ SQL> select name from v$datafile union
2 select name from v$tempfile union
3 select member from v$logfile union
4 select name from v$controlfile union
5 select name from v$flashback_database_logfile;
NAME
+DATA1/rac/controlfile/current.260.3 +DATA1/rac/datafile/example.264.1 +DATA1/rac/datafile/sysaux. 257.1 +DATA1/rac/datafile/system. 256.1 +DATA1/rac/datafile/undotbs1.258.1 +DATA1/rac/datafile/undotbs2.265.1 +DATA1/rac/datafile/undotbs3.266.1 +DATA1/rac/datafile/users.259.1 +DATA1/rac/onlinelog/group_1.261.1 +DATA1/rac/onlinelog/group_2.262.1 +DATA1/rac/onlinelog/group_3.269.1 +DATA1/rac/onlinelog/group_4.270.1 +DATA1/rac/onlinelog/group_5.267.1 +DATA1/rac/onlinelog/group_6.268.1 +DATA1/rac/tempfile/temp.263.1 +REC0V1/rac/controlfile/current. 256.3 +REC0V1/rac/onlinelog/group_1.257.1 +REC0V1/rac/onlinelog/group_2.258.1 +REC0V1/rac/onlinelog/group_3.261.1 +REC0V1/rac/onlinelog/group_4.262.1 +REC0V1/rac/onlinelog/group_5.259.1 +REC0V1/rac/onlinelog/group_6.260.1 22 rows selected
SQL> show parameter spfile
NAME TYPE VALUE
spfrile strin0 +0ATA1/rac/spfilerac.ora
SQL>
460
Глава ц
Динамические представления производительности, рассчитанные на работу в кластере
Представления GV$ облегчают просмотр характеристик всех экземпляров в одном операторе select и в то же самое время отфильтровывают узлы, которые не требуются пользователю; эти же представления облегчают агрегирование итогов по некоторым или по всем узлам кластера:
□ SQL> select nvl(to_char(inst_id), ‘TOTAL’) INST#,
2 count(inst_id) sessions from gv$session
3 group by rollup(inst_id)
4 order by inst_id;
INST# SESSIONS
1 29
2 39
3 26
TOTAL 94
4 rows selected.
Из этого запроса можно узнать число сеансов для каждого экземпляра кластера, используя для этого представление GV$SESSION.
Обслуживание RAC
Большая часть операций по обслуживанию, выполняемая для экземпляров, которые функционируют на одном узле, непосредственно применима и для сред многоузловых баз данных RAC.
Запуск базы данных RAC
Запуск базы данных RAC не очень отличается от запуска автономного экземпляра; узлы базы данных RAC могут быть запущены в произвольном порядке, кроме того, их можно останавливать и снова запускать в любые моменты времени с минимальным воздействием на остальную часть кла стера. При запуске базы данных сначала запускается экземпляр АЬ и монтируются разделяемые дисковые группы; затем запускается экземп ляр СУРБД и объединяется кластер.
В среде Unix можно модифицировать файл /etc/oratab, чтооы с помощью автоматически запускать оба экземпляра (и ASM, и СУРЬД; каждом кластере:
О tt Этот файл используется утилитами ORACLE. Он создается сценарием root sh, J ft а затем обновляется утилитой Database Configuration Assistant при созда ии ft данных it 11 I 1
й В качестве разделителя полей используется символ двоеточия (":”)• Символ # строки используется как разделитель записей. Строки, начинающиеся со знака # фунта (“#”), являются комментариями. #
ae&l Application Clusters
461
# Записи имеют следующий формат:
tt SORACLE_SID:$ORACLE_HOME:<N|Y>:
#
# Первое и второе поле являются идентификатором системы и домашним каталогом
# системы соответственно. Третье поле используется для указания утилите dbstart,
# что база данных должна быть (“Y”) или не должна быть ("N”) приведена
# в рабочее состояние во время загрузки системы.
#
# Несколько записей с одинаковым $ORACLE_SID не разрешаются
# *:/и01/арр/оracle/product/10.1.O/DB1 Об/ Home:N
+ASM1:/и01/арр/оracle/product/10.1.0/DB1Og Home:Y
rac:/u01/app/oracle/product/10.1.O/DB1Og Home:Y
Журналы базы данных в среде RAC
Как и в случае экземпляра, состоящего из одного узла, в средах RAC онлайновые (оперативные) журналы базы данных используются для восстановления экземпляра; у каждого экземпляра в среде RAC имеется свой собственный набор оперативных файлов журналов базы данных, которые используются для наката (прокрутки вперед) базы данных по информации, хранящейся в журналах, и последующего отката любых незафиксированных транзакций, которые были инициированы этим узлом с использованием табличного пространства отката.
Еще до того, как вышедший из строя узел будет перезапущен, один из “выживших” экземпляров обнаруживает факт выхода узла из строя и использует оперативные журналы базы данных для того, чтобы убедиться, что не были потеряны незафиксированные транзакции. Если этот процесс будет завершен прежде, чем вышедший из строя узел будет перезапущен, для перезапущенного экземпляра не будет требоваться восстановление. Даже если из строя выйдет более одного экземпляра, все, что потребуется для восстановления экземпляра, — это один оставшийся работоспособным экземпляр. Если из строя выйдут все экземпляры в RAC, то первый стартовавший после восстановления экземпляр выполнит восстановление экземпляра для базы данных, используя оперативные журналы базы данных для всех экземпляров кластера.
Если требуется восстановление носителей и должна быть восстановлена вся база данных, необходимо остановить все экземпляры, за исключением одного, и выполнить восстановление базы данных с помощью одного экземпляра. Если восстанавливаются некритичные файлы базы данных, в активном состоянии могут быть все узлы, однако, при условии, что табличные пространства, содержащие подлежащие восстановлению файлы, помечены как OFFLINE.
Табличные пространства отката в среде RAC
Как и в случае оперативных журналов базы данных, в среде RAC у каждого экземпляра имеется собственное табличное пространство отката на разделяемом дисковом устройстве или дисковой группе. Это табличное пространство отката используется для отката транзакций во время обычных
транзакционных операций или во время восстановления экземпляр^ Кроме того, табличное пространство отката используется другими узЛа’ ми кластера для поддержки согласованности чтения для транзакций узле гас2, читающих строки из таблицы, в то время как процесс ввода даьь пых на узле racl делает обновления в той же самой таблице, и еще не пел зафиксировать транзакцию. Пользователю на узле гас2 необходим видеть исходный вид (before image) данных, хранящийся в табличном пространстве отката узла racl. Именно по этой причине все табличные пространства отката должны быть видимы со всех узлов кластера.
Сценарии восстановления после сбоя и TAF
Если клиент был правильно сконфигурирован, а экземпляр, к которому клиент был подключен, вышел из строя, клиентское подключение быстро переключается на другой экземпляр в кластере, и обработка может продолжаться всего лишь с небольшой задержкой во времени отклика.
Ниже приводится запись файла tnsnames для сервиса racsvc, созданного ранее:
□ racsvc =
(description =
(address = (protocol = tcp) (host = voc1) (port = 1521))
(address = (protocol = tcp) (host = voc2) (port = 1521))
(address = (protocol = tcp) (host = voc3) (port = 1521))
(load_balance = yes)
(connect_data =
(server = dedicated)
(service_name = racsvc.world) (failover jnode =
(type = select)
(method = basic)
(retries = 180)
(delay = 5) )
)
)
Ниже показывается, что произойдет, если сеанс будет подклю4^ к кластеру, а экземпляр будет потерян, и как об этом можно узнать. Сна ла нужно подключиться к кластеру через сервис racsvc и выяснить, к к му узлу и к какому экземпляру вы прикреплены:
□ SQL> connect rjb/rjb@racsvc;
Connected. I
SQL> select instance_name, host_name, failoveretype,
2 falloverjnethod, failed_over
3 from v$instance
4 cross join
5 (select failover.type, failover_method, failed_over
6 from v$session
7 where username = ‘RJB’);
pe^l Application Clusters
463
INSTANCE-NAME HOST_NAME FAILOVER_TYPE FAILOVER_METHOD FAILED OVER
racl od SELECT ' BASIC NO
SQL>
Чтобы показать имя экземпляра и имя хоста, к которому вы подключены, используются столбцы из V$INSTANCE, а затем они соединяются с V$SESSION и оттуда выбираются столбцы, связанные с преодолением последствий сбоя, которые бывают заполнены только в среде RAC. В этом случае последствия сбоя для сеанса еще не преодолены, а тип преодоления последствий сбоя называется BASIC, что было специфицировано в момент создания сеанса.
Затем экземпляр racl останавливается из другого сеанса, оставаясь при этом подключенными к первому сеансу:
□ SQL> connect system/manager@rac1
Connected.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
Возвратившись в свой сеанс, следует повторить запрос, чтобы узнать, к какому узлу вы подключены теперь:
□ SQL> select instance_name, host_name, failover_type,
2 falloverjnethod, failed.over
3 from v$instance
4 cross join
5 (select failover_type, failoverjnethod, failover_over
6 from v$session
7 where username = ‘RJB’);
INSTANCE.NAME HOST.NAME FAILOVER_TYPE FAILOVER, METHOD FAILED. OVER
гас3 осЗ SELECT BASIC YES
SQL>
Если в то время, когда экземпляр был отключен, выполнялись запросы, запрос приостановится па секунду-другую, а затем продолжит свое выполнение, как будто ничего не произошло.
Сценарий выхода из строя узла RAC
Одним из преимуществ среды RAC является возможность добавлять или Удалять узлы, чтобы уметь удовлетворять изменяющиеся запросы на ре-сУрсы. Сервер, недогруженный работой для одного из бизнес-подраздел е-ний, может быть очень нужен для другого бизнес-под разделения, которое в Данный момент начало испытывать пиковые нагрузки. Добавление или Удаление узлов в среде RAC может быть также стимулировано выходом
464
узла из строя; пока остальные узлы кластера продолжают обслуживать просы, нужно исправить или отремонтировать вышедший из строя y3ejJ и добавить его обратно в кластер, не останавливая остальную его часть
Ниже продемонстрированы шаги, требующиеся для удаления данных узла из кластерного реестра (cluster registry) с последующей ег0 перестройкой и обратным включением в состав кластера. В этом сцена* рии делается следующее допущение: поврежден локальный жесткий диск третьего узла кластера, причем повреждение не поддается ремонту; следовательно, узел должен быть построен “с нуля” и затем добавлен в кластерный реестр. После этого шага необходимо повторно инсталлировать программное обеспечение Oracle и создать экземпляр Oracle как часть кластера базы данных.
Удаление экземпляра
Даже когда экземпляр на вышедшем из строя сервере недоступен, нужно удалить всякие следы этого узла из оставшихся узлов кластера. Для удаления экземпляра из состава кластера можно использовать команду srvctl:
□ [oracle@oc1 oracle]$ srvctl remove instance -d rac -i гасЗ Remove instance гасЗ for the database rac? (y/[nj) у [oracle@oc1 oracle]$
Параметр -d гас специфицирует подлежащий модификации RAC, a -i гасЗ — экземпляр, который должен быть удален из RAC.
Удаление узла из кластера
Для удаления самого сервера из кластера надо выполнить из каталога CRSlOgHome команду rootdeletenode.sh, в которой специфицируются и имя узла, и назначенный с помощью CRS номер узла:
□ [root@od root] # cd /u01/app/oracle/product/10.1.0/CRS10gHome/bin [root@od bin]# ./clsnodes -n oc1 1
oc2 2
oc3 3
[root@oc1 bin]# cd ../install
[root@od install]# ./rootdeletenode.sh oc3,3 clscfg: EXISTING configuration version 2 detected, clscfg: version 2 is 10g Release 1.
Successfully deleted 13 values from OCR.
Key SYSTEM.css.interfaces.nodeoc3 marked for deletion is not there. Ignoring.
Successfully deleted 5 keys from OCR.
Node deletion operation successful. ‘oc3, 3’ deleted successfully [root@oc1 install]# cd ../bin [root@oc1 bin]# ./clsnodes -n oc1 1
oc2 2
[root@od bin]#
peal Application Clusters
465
Кроме того, необходимо удалить узел из списка адресов (мест расположения) узлов, поддерживаемого универсальным инсталлятором Oracle (OUI); в каталоге $ORACLE_BASE/oralnventory/ContentsXML нужно определить любые файлы, которые ссылаются на удаленный узел, как это сделано в рассматриваемом примере в файле inventory.xml:
□ <НОМЕ NAME=”CRS1Og Home'1
LOC='/u01/app/oracle/product/10.1.0/CRS10gHome"
TYPE=,,0” IDX="1" CRS=”true7>
<NODE_LIST>
<NODE NAME=”oc1’7>
<NODE NAME="oc3"/>
<NODE NAME="oc27>
</NODE_LIST>
</HOME>
Примечание В MetaLink Note 269320.1 приводятся другие процедуры (конкретно для данной среды), которые, может быть, потребуется выполнить для удаления узла кластера.
Было специфицировано имя узла сервера, на котором размещается экземпляр. Теперь в среде программного обеспечения CRS есть только два узла.
Инсталляция программного обеспечения операционной системы
На следующем шаге следует инсталлировать программное обеспечение сервера и подготовить среду, как это уже делалось выше в данной главе. В конце этого примера будут получены созданные каталоги Oracle вместе с учетной записью пользователя Oracle, но без CRS и инсталлированного программного обеспечения. Кроме того, необходимо назначить публичные, приватные и виртуальные IP-адреса, используя для них те же самые значения, которые были использованы при первоначальном создании этого узла. В результате таких действий не придется изменять файлы /etc/hosts для остальных узлов кластера.
Добавление в кластер узла с помощью CRS
Узел готов к добавлению к кластеру на уровне программного обеспечения, так чтобы другие узлы кластера снова стали считать его частью кластера. С одного из оставшихся узлов кластера нужно перейти к каталогу $CRS_HOME/oui/bin и выполнить команду addNode.sh, которая запускает OUI и предлагает новый узел (см. рис. 11.27).
После подведения итога по существующим узлам и тому узлу, который необходимо добавить, следует щелкнуть на NEXT, и файлы CSR будут скопированы на новый узел. Для запуска сервиса на этом новом узле будет предложено выполнить команду rootaddnode.sh на активном узле и команду root.sh на новом узле:
466
Глава
----.,^.г,^ ' ' ' '"
Specify Cluster Nodes to Add to Installation
Fxisting Nodes
The following nodes ere already pan of The installation
Existing Nodes
Specify New Nodes
Enter the public node rame eno private node name for nodes that you want to add <o this IpstaliaUon, : . • I ''. 5v:-'C ' 4 •
Public Node Names Private Node Names
.... ...... ........ ..... .;Эч.: . .Л.;. ....... ...-.• - .^c* •• *^c4«-** *• <*> :-•>><- *• i»'W - - * - • . • .
:0C3 PCG
Рис. 11.27. Специфицирование узла для добавления с использованием 0l I
□ [root@oc1 oralnventory]#
/u01/app/oracle/product/10.1.0/CRS10gHome/rootaddnode.sh
clscfg: EXISTING configuration version 2 detected.
clscfg: version 2 is 10g Release 1.
Attempting to add 1 new nodes to configuration
Using ports* CSS=49895 CRS=49896 EVMCM9898 and EVMP = 49897
node <nodenumber>: <nodename> <private interconnect name> <hostname>
node 3: осЗ росЗ осЗ
Creating OCR keys for user ‘roof, privgr ‘root’ ..
Operation successful.
root@od oralnventory]# ssh осЗ
Last login: Sun Oct 31 21:12 08 2004 from oc2
[root@oc3 root]# /u01/app/oracle/product/10.1.0/CRS10g Home/root.sh
Checking to see if Oracle CRS stack is already up . . .
/etc/oracle does not exist Creating it now.
Setting the permissions on OCR backup directory
Oracle Clusters Registry configuration upgraded successfully
WARNING, directory */u01/app/oracle/product/10.1.0’ is no owi e 00
WARNING: directory ‘/u01/app/oracle/product/’ is not owned by root
WARNING: directory ‘/u01/app/oracle’ is not owned by roo
clscfg: EXISTING configuration version 2 detected.
clscfg- version 2 is 10G Release 1.
assigning default hostname ocl for node 1.
assigning default hostname oc2 for node 2.
assigning default hostname осЗ for node 3.
Successfully accumulated necessary OCR ke s
Using ports- CSS=49895 CRSM9896 EVMC=49898 and EVMR=49897.
peal Application Clusters
467
node <nodenumber>: <nodename> <private interconnect name> <hostname> node 1: od poc1 od
node 2: oc2 poc2 oc2
node 3: осЗ росЗ осЗ
clscfg: Arguments check out successfully.
NO KEYS WERE WRITTEN. Supply -force parameter to override.
-force is destructive and will destroy any previous cluster configuration.
Oracle Clusters Registry for cluster has already been initialized
Adding daemons to inittab
Preparing Oracle Clusters Ready Services (CRS):
Expecting the CRS daemons to be up within 600 seconds
CSS is active on these nodes.
od
oc2
осЗ
CSS is active on all nodes.
Waiting for the Oracle CRSD and EVMD to start
Waiting for the Oracle CRSD and EVMD to start
Oracle CRS stack installed and running under init (1M) [root@oc3 root]#
В релизе 10.1.0.2.0, чтобы конфигурировать номер порта службы оповещения Oracle (Oracle Notification Services — ONS), можно использовать утилиту racgons из каталога CRS_HOME:
□ [root@oc3 root]# $CRS_HOME/bin/racgons add_config oc3:4948
Если порт уже сконфигурирован, будет получено следующее сообщение:
О WARNING: осЗ:4948 already configured.
(ПРЕДУПРЕЖДЕНИЕ: осЗ:4948 уже сконфигурирован.)
Инсталляция программного обеспечения Oracle на новом узле
На этом шаге копируется программное обеспечение Oracle с одного из имеющихся узлов кластера на новый узел. Из каталога $ORACLE_ НОМЕ/oui/bin нужно выполнить сценарий addNode.sh. Перед этим следует убедиться в том, что текущим каталогом является $ORACLE_ НОМЕ, а не $CRS_HOME.
OUI будет запущена в режиме Add Node (добавить узел), и после стартового экрана будет показан экран специфицирования узлов кластера (Specify Cluster Nodes), изображенный на рис. 11.28. На этом экране производится добавление нового узла осЗ.
После того как будет показан итоговый экран, похожий на экран, продемонстрированный при инсталляции CRS, нужно щелкнуть па кнопке ext, чтобы скопировать на новый узел программное обеспечение racle. После завершения этого шага будет предложено выполнить на новом узле сценарий root.sh. На заключительном шаге этой процедуры обновленная информация о кластере сохраняется на диске OCR.
468
/пава
Рис. 11.28. Специфицирование узла кластера, добавляемого к инсталляции
Создание нового экземпляра Oracle
Для создания нового экземпляра Oracle на новом узле следует выполнить DBCA с действующего узла и выбрать базу RAC. На следующем экране нужно выбрать Instance Management (управление экземпляром), а затем добавить экземпляр к имеющемуся кластеру (см. рис. 11.29).
На следующем экране вам будет предложено ввести имя нового экземпляра; чтобы не противоречить принятым нами ранее правилам имено
вания, выберите имя гасЗ и щелкните на Next. На шаге 6 будут показаны существующие кластерные сервисы; обновите эти сервисы, включив в них там, где это необходимо, имя нового узла. На последнем шаге (шаг 7) следует специфицировать табличные пространства, файлы данных и группы журналов, которые будут добавлены для этого экземпляра в нашем случае это табличное пространство отката, файл данных для хранения табличного пространства и две группы журналов, как показано на рис. 11.30.
Когда экземпляр будет полностью работоспособен, появится экрая подтверждения — у кластера снова три узла:
□ SQL> select inst__id from gv$instance;
INST ID
1
2
3
peal Application Clusters
469
Рис. 11.29. Добавление экземпляра к имеющемуся кластеру
Рис. 11.30. Специфицирование среды хранения для нового экземпляра
470
Гпава 11
Настройка базы данных узла RAC
На первом шаге настройки базы данных RAC необходимо настроить каждый индивидуальный экземпляр. Если этот экземпляр не будет настроен корректно, производительность всего кластера может оказаться далеко не оптимальной. Для настройки экземпляров можно использовать авто-магически управляемый репозиторий рабочей нагрузки (AWR), какбудТо бы экземпляр не является частью кластера.
Используя ЕМ Database Control, можно воспользоваться статистическими показателями из AWR для продуцирования отчетов для всего кластера. На рис. 11.31 можно видеть, до какой степени ЕМ Database Control облегчает анализ производительности разделяемого глобального кэша, а также кэшей отдельных экземпляров.
Управление табличными пространствами
Управление табличными пространствами в среде RAC во многом анало гично управлению табличными пространствами для одиночного экземпляра: для управления есть всего одна база данных и один набор таблич-
©
1*
Sftdrch
Favorites
•Kij -.v^»
Fte Edit View Favcntes Tools
ные
Back
http //192.168.2.101 ;5S00/en/con$ole/rac/racHe<3lth’t'-pe«rac_da!:abase8ddrget«rac.wcrld&eYent=doLoad
Go
qet Wti
I
a
3.
i
> Cluster Cache Coherency
r J
View Data Real Time: 15 Second Refresh
Globo's (
t
‘ . .
Transfer Per Second O.b8
Logical Reads Per $ I8
Second
Buffered Physical Reads n f n Per Second U’VU
View Data
Average Current Block
Request Time (ms)
Current Blocks Requested 5.00
View Data
Average CP Block
Request Time (rns)
CR Blocks Requested 13.00
View v
Z 02 t 50
1 CC
D <2
D 23
it:’ Sp m
I t '/CRH? 23
r
I
>
L
*-»*****,
Internet
Рис. 11.31. Статистические показатели кэша RAC в CM Database Control
peal Application Clusters 471
ных пространств. Все дело в том, что к этом}7 одному набору табличных пространств может получать доступ несколько экземпляров.
Опция Automatic Segment Space Management (ASSM — автоматическое управление пространством в сегментах), впервые появившаяся в Огас1е9г, делает более удобным и простым использование табличных пространств в средах RAC. Поскольку отпадает необходимость заботиться о дополнительных списках свободных блоков памяти, о группах таких списков для поддержки нескольких экземпляров и, следовательно, о дополнительных конкурирующих процессах записи в таблицы, при добавлении в кластер дополнительных экземпляров реорганизация таблиц перестает быть обязательной.
ОПЦИИ РЕЗЕРВНОГО КОПИРОВАНИЯ И ВОССТАНОВЛЕНИЯ
В Oracle предлагается большое количество процедур и возможностей резервного копирования, помогающих защитить базу данных. При правильной реализации эти возможности позволяют эффективно делать резервные копии БД, а также легко и быстро с их помощью выполнять восстановление БД.
К числу способов резервного копирования Oracle относится как логическое, так и физическое копирование, причем для обоих вариантов существует множество различных опций. В данной главе не рассматриваются подробно все возможности и сценарии восстановления. Внимание здесь уделяется использованию наилучших возможностей самым эффективным способом.
озможности
JEc
Oracle: экспорт, автономноебрезервноН°Г° копиРования базы данных и оперативное резервное копил™? , копирование (offline backup) ставдяет собой логгигсскоскопированиеТ ^°nIine backuP)- Экспорт пред-а это физическое копирование <+> - базы данных’Два остальных спосо-?n£°ABaims является применен№И^В‘ СтандаРтом Для физического ко-( IAN — диспетчер восстанови Утилиты Oracle Recovery Manager и применении RMAN см. главу 1 Л”™ Огас1е) (подробнее о реализации
Надежная стратегия резеовпл™
кое, и на логическое пезелв?™ копирования опирается и на физиче-
иые базы данных используют п копирование. Как правило, промышлен-резервное копирование алогии качестве основного метода физическое Для баз данных, находящихся в ^скоеслужт вспомогательным методом-ботки с перемещением небол^ЖТТ’ И Некоторых операций обра-смысл и исХСКОГ° ре3еРВ11ого копированиТ Не^ббОЛЬШе П°ЛХОДЯТ ------„Sfьзовать оба эти вида, чтобы найти родимо понимать их "" „п„„пжеиия Решение, которое лучШе
основного метода физическ
разработке, и некоторых операций ООР^ понимать
Опцин резервного копирования и восстановления
473
Логическое резервное копирование
Логическое резервное копирование базы данных предполагает чтение ее записей и внесение их в файл. Записи считываются независимо от их физического расположения. В Oracle этот тип копирования выполняет утилита Data Pump Export (помпа данных экспорта). Для восстановления БД из полученного таким образом файла используется утилита Data Pump Import (помпа данных импорта).
Примечание Утилиты Oracle Export и Oracle Import, которые использовались до появления версии Oracle Database 10g, по-прежнему предлагаются как часть инсталляции Oracle 10д. Однако пользователям старых утилит Export и Import предлагается перейти к использованию утилит Data Pump Export и Data Pump Import.
Процесс Data Pump Export/lmport
Утилита экспорта Oracle Data Pump Export делает запрос к базе данных, в том числе к словарю данных, и записывает результат в файл XML, называемый файлом дампа экспорта. Можно экспортировать всю базу данных, конкретных пользователей или конкретные таблицы. В процессе экспорта можно решить, следует ли экспортировать связанную с таблицами информацию словаря данных, такую как привилегии, индексы и ограничения. Созданный утилитой экспорта Data Pump Export файл будет содержать команды, необходимые для полного воссоздания всех выбранных объектов и данных.
Экспортированные с помощью Data Pump Export данные можно потом импортировать, используя утилиту импорта Data Pump Import. Она читает созданный файл дампа экспорта и выполняет найденные там команды. Например, в этих командах может содержаться команда create table, за которой следует команда insert, обеспечивающая загрузку данных в таблицу.
Экспортированные данные не обязательно должны быть импортированы в ту же самую базу данных или в ту же схему, которая использовалась для генерации файла дампа экспорта. С помощью этого файла можно создать копию экспортированных объектов в другой схеме или в другой базе данных.
Импортировать можно все экспортированные данные или только их часть. При импорте целого файла дампа, созданного в результате операции полного экспорта, все объекты базы данных будут созданы заново, включая табличные пространства, файлы данных и пользователей. Однако часто бывает полезно создать табличные пространства и пользователей заранее, чтобы определить физическое расположение объектов в базе данных.
Если импортируются не все данные из файла дампа экспорта, табличные пространства, файлы данных и пользователи, которым будут принадлежать эти данные, должны быть созданы заранее.
IP %
Физическое резервное копирование
Под физическим резервным копированием понимается копирование к файлов данных, из которых состоит база данных. Эти копии также называются резервными копиями файловой системы, посклпыл/ гтпрттпп тга тгэ-
474
Глава 1g
ют участие команд резервного копирования операционной системы Oracle поддерживает два типа физического копирования файлов: авщ. номноеи оперативное (называемые также горячим и холодным копирование^ соответственно). Для выполнения всех операций физического резервно, го копирования можно использовать утилиту RMAN (см. главу 13). При желании можно выбрать режим написания собственных сценариев выполнения физического копирования, но при этом вы лишаетесь многих преимуществ, предоставляемых подходом с использованием RMAN.
Автономное резервное копирование
Непротиворечивое (согласованное) автономное резервное копирование выполняется после нормальной остановки базы данных (т.е. не из-за сбоя в работе экземпляра). После ее отключения (база данных переведена в “автономный” режим) копируются следующие файлы:
и Все файлы данных
Все управляющие файлы
и Все оперативные журналы базы данных
Файл init.ora (по желанию) и файл параметров сервера, spfile.ora, если он используется
Проще всего копировать базу данных, если архитектура ее файлов использует согласованную структуру каталогов.
Копирование всех этих файлов во время остановки базы данных позволяет получить ее полный образ па тот момент, когда она была остановлена. Все файлы впоследствии можно извлечь из резервной копии, и база данных снова будет готова к работе. Недопустимо выполнять резервное копирование файловой системы, когда база данных открыта (если не считать оперативного копирования). Автономное резервное копирование, которое происходит после аварийного завершения работы базы данных, также может оказаться несогласованным и может потребовать дополнительных действий во время операций восстановления — если они воооше окажутся годными к употреблению.
Оперативное резервное копирование
Оперативное резервное копирование можно осуществлять для лЮ0°’_ базы данных, работающей в режиме ARCHIVELOG. В этом режиме арх вируются все оперативные журналы базы данных, что позволяет п чить полный журнал всех транзакций базы данных.
Запись в оперативные файлы журналов базы данных Oracle осупх запись во втор ’ овЫ11
ЛИШИМ HUWIV/V vz ----- 1
__,_______х___о ____,_______ перезаписывать содержание пер файла (при этом старое его содержимое теряется безво TI
ляет циклически: заполнив первый файл, он начинает
а заполнив его — в третий. После заполнения последнего файла фон процесс LGWR (Log Writer) начинает перезаписывать содержание пер го файла (при этом старое его содержимое теряется безво TI Прим. пер.). ~ еСс
Когда Oracle работает в режиме ARCHIVELOG, фоновый про ARCH (Archiver) делает копию каждого файла оперативного жур* базы данных, прежде чем перезаписать его. Обычно эти архивные к° гЬяйлов этих жуоналов записываются на диск. Их можно записать та
Опции резервного копирования и восстановления
475
и на ленточное устройство, но это потребует значительных дополнительных усилий со стороны оператора.
Примечание Большинство производственных баз данных, в особенности те, что поддерживают приложения обработки транзакций, должны работать в режиме ARCHIVELOG.
При условии, что база данных работает в режиме ARCHIVELOG, копирование файловой системы можно выполнить, пока база данных открыта. В процессе оперативного резервного копирования каждое табличное пространство переключается в режим резервного копирования, затем осуществляется копирование его файлов, после чего оно переводится в обычное состояние.
Примечание Если используется поставляемая совместно с Oracle утилита Recovery Manager (RMAN), переводить вручную табличные пространства в состояние резервного копирования не нужно. Утилита считывает блоки данных таким же образом, как Oracle делает это для запросов.
База данных может быть полностью восстановлена из оперативной резервной копии, а с помощью архивных журналов базы данных ее можно вернуть к состоянию на любой момент времени. После ее последующего открытия все завершенные на этот момент транзакции будут восстановлены, а все незавершенные — откачены.
Когда база данных открыта, могут быть скопированы следующие файлы:
Все файлы данных
и Все архивные файлы журналов базы данных
Один управляющий файл — с помощью команды alter database
Процедуры оперативного резервного копирования чрезвычайно эффективны по двум причинам. Во-первых, они позволяют осуществить полное восстановление на определенный момент в прошлом. Во-вторых, во время копирования файловой системы база данных может оставаться открытой. Это означает, что даже для тех баз данных, которые не могут оыть остановлены из-за требований пользователей, можно получить копии файловых систем. А поскольку база данных открыта, системная гло-оальная область (SGA) не сбрасывается (как в ходе перезапуска базы данных). Это повышает производительность БД, потому что уменьшает количество требуемых операций физического ввода/вывода.
Примечание Для отката состояния базы данных назад во времени, не используя для этого физические резервные копии, можно использовать опцию flashback database, появившуюся в Oracle Database 10^. Чтобы использовать команду flashback database, необходимо работать в режиме ARCHIVELOG и задать команду alter database flashback в тот момент, когда база данных смонтирована, но не открыта. Во время выполнения операции flashback database Oracle использует журналы, записанные в области Flashback Recovery Area.
476
Глава /2
Использование утилит Data Pump Export и Data Pump Import
Появившиеся в Oracle Database 10g утилиты Data Pump обеспечивают средства извлечения и импорта данных с обслуживающими узлами. Сре. ди их возможностей необходимо отметить существенные архитектур, ные и функциональные усовершенствования по сравнению с ранее использовавшимися утилитами Import и Export. Утилиты Data Pump позволяют останавливать и снова запускать задания, видеть статус выполняющихся заданий и ограничивать объем импортируемых и экспор. тируемых данных.
Примечание Файлы Data Pump несовместимы с файлами, которые были сгенерированы использовавшейся ранее утилитой Export.
Утилита Data Pump выполняется как серверный процесс, что по многим причинам оказывается более выгодным для пользователей. Клиентский процесс, запускающий задание, может быть отключен и впоследствии снова подключен к заданию. Производительность повышается (по сравнению с Export/lmport), поскольку данные не должны более обрабатываться клиентской программой. Извлечение и загрузка данных с помощью Data Pump могут выполняться параллельно, что приводит к дополнительному повышению производительности.
Создание каталога
Утилита Data Pump требует от пользователей создания каталогов, в которые она будет записывать файлы данных и журнальные файлы и откуда она будет их читать. Для создания в среде Oracle указателя на используемые внешние каталоги следует воспользоваться командой create directory. У пользователей, которые будут обращаться к файлам Data Pump, должны быть привилегии READ и WRITE на эти каталоги.
Примечание Перед началом работы нужно проверить, существуют ли треб щиеся внешние каталоги и имеется ли у пользователя, который собирается вып нить команду create directory, системная привилегия CREATE ANY DIRECTORY. IS
В следующем примере создается каталог с именем DTPUMP, и с Practice предоставляются для него права доступа READ и WRITE.
П create directory dtpump as ‘e:\dtpump’;
grant read on directory DTPUMP to practice, system;
grant write on directory DTPUMP to practice, system; I
Теперь схемы PRACTICE и SYSTEM могут использовать этот ката^°г для выполнения задании Data Pump каталог DTPUMP.
Опции резервного копирования и восстановления
477
Опции Data Pump Export
В Oracle предлагается утилита expdp, исполняющая роль интерфейса с Data Pump. Если у вас есть некоторый предварительный опыт работы с утилитой Export, то многие из опций Data Pump Export покажутся вам знакомыми. Однако некоторые существенные опции являются доступными только в Data Pump. В таблице 12.1 показаны все входные параметры командной строки для утилиты expdp, используемые при создании задания на экспорт.
Табл ица 12.1. Входные параметры командной строки для expdb
Параметр
ATTACH
CONTENT
DIRECTORY
DUMPFILE ESTIMATE
ESTIMATE-ONLY
EXCLUDE
FILESIZE
FLASHBACK_SCN
FLASHBACK_TIME
FULL
HELP
INCLUDE
JOB_NAME
LOGFILE
NETWORK-LINK
NOLOGFILE
Описание
Подключает клиентский сеанс к выполняющимся в настоящее время заданиям Data Pump Export.
Фильтрует, что именно будет экспортироваться: DATA_ ONLY, METADATA-ONLY или ALL.
Специфицирует целевой каталог для набора журнальных файлов и файлов дампа.
Специфицирует имена и каталоги файлов дампа.
Специфицирует используемый для определения размера файла дампа метод (BLOCKS или STATISTICS).
Флажок Y/N (да/нет), используемый для указания Data Pump, должен ли производиться экспорт данных или только их оценка.
Указывает критерии для исключения объектов или данных из числа экспортируемых.
Специфицирует максимальный размер каждого файла дампа для экспорта.
Номер SCN базы данных, по состоянию на который производится ретроспекция во время экспорта.
Отметка времени для базы данных, по состоянию на которое производится ретроспекция во время экспорта.
При экспорте указывает Data Pump, что необходимо экспортировать все данные и метаданные.
Выводит список возможных команд и опций.
Специфицирует критерии, по которым будут экспортироваться объекты и данные.
Задает имя задания; по умолчанию имя задания генерируется системой.
Имя файла и (необязательно) им^ каталога, в который будет экспортирован журнал.
Специфицирует исходную связь баз данных для задания Data Pump, ведущего экспорт из удаленной базы данных.
Флажок Y/N, используемый для подавления создания журнального файла.
478
Гпава 12
Таблица 12.1 (Продолжение)
Параметр Описание
PARALLEL Устанавливает количество рабочих процессов (обработчиков) для задания Data Pump Export.
PARFILE Имя файла параметров, если он используется.
QUERY SCHEMAS Фильтрует строки таблиц во время экспорта. Именует схемы, которые будут экспортированы при экспорте в режиме Schema.
STATUS Выводит детализированные данные о статусе (состоянии) задания Data Pump.
TABLES Перечисляет подлежащие экспорту в режиме Table таблицы и разделы таблиц.
TABLESPACES TRANSPORT_FULL_CHECK Перечисляет подлежащие экспорту табличные пространства. Специфицирует, требуется ли подвергать подлежащее экспорту табличное пространство проверке на принадлежность к обособленному набору (self-contained set) табличных пространств.
TRANSPORTTABLESPACES Задает режим экспорта переносимых табличных пространств.
VERSION Задает версию подлежащих созданию объектов базы данных, так чтобы набор файлов дампа мог быть совместимым с предыдущими версиями Oracle. Возможные варианты: COMPATIBLE, LATEST и конкретные номера версий базы данных (не ниже чем 10.0.0).
Как следует из таблицы 12 1 для Data P!imr,„„
MOB экспорта. При полном экспорте(Ги1Пиз б^Држиваются пять Режи’ Данные и метаданные. При экспате схем^/S > извлекаются все ные и метаданные е cxeMbI (Schema) извлекаются все дан-
экспорте табличных пространств КОН*ретных пользователей. При
данные для табличнктJ™ (Tablespace) извлекаются данные и мета-
и метаданные да таблиц и «раздел» И™ да ““ <табли“ы>" дан““
крегных табличных пространствах (см. главу 17),_____________
ТаИезрасе^необхолимп 12пП°ЛНЯТЬ ЭКСП°РТ в Режимах Full или Transportable димо иметь системную привилегию EXP_FULL_DATABASE.
——II»—
При запуске пакетного задания Oracle присваивает ему сгеперирова ное системой имя. Если имя задания явно указывается в параметре JU -NAME, необходимо быть уверенным, что имя задания не вступает в к фликт с именами таблиц или представлений данной схемы. Главная т лица будет иметь то же самое имя, что и задание Data Pump, так что ее и* не может конфликтовать с существующими объектами.
Во время выполнения задания пользователь может выполнять коМ^Н ды (см. таблицу 12.2), используя для этого интерфейс Data Pump.
Опции резервного копирования и восстановления
479
Таблица 12.2. Параметры интерактивного режима Data Pump Export
Параметр Описание
ADD_FILE CONTINUE-CLIENT EXIT-CLIENT Добавить файлы дампа. Выити из интерактивного режима и войти в режим регистрации. Выйти из клиентского сеанса, оставив при этом на сервере задание Data Pump выполняющимся.
HELP Вывести на экран оперативную помощь при экспорте.
KILL JO В Уничтожить (или “убить”, как говорят “настоящие” КБ!\.-—Прим. пер.) текущее задание и отсоединить связанные с ним клиентские сеансы.
PARALLEL Изменить число обработчиков для задания Data Pump Export.
STARTJOB STATUS Перезапустить присоединенное задание. Вывести детализированный статус задания Data Pump.
STOPJOB Остановить задание для запуска впоследствии.
Используя интерактивный режим команд, можно изменить многие характеристики выполняющегося задания Data Pump Export. Если область дампа оказывается исчерпанной, можно присоединиться к заданию, добавить для него новые файлы и перезапустить задание с этой же точки. Нет необходимости уничтожать задание, а затем повторно запускать его с самого начала. В любой момент можно вывести статус задания, используя для этого либо параметр STATUS, либо представления словаря данных USERJDATADUMP JOBS и DBA DATADUMP JOBS или представление V$SESSION JLONGOPS.
Запуск задания Data Pump Export
Параметры задания можно сохранить в так называемом файле параметров, на который дается ссылка в параметре PARFILE утилиты expdp. Например, можно создать файл с именем dpi.par со следующими элементами:
0I DIRECTORY=dtpump
DUMPFILE=metadataonly. dmp
CONTENTS ETADATA_ ONLY
После этого можно запустить задание Data Pump Export:
П expdp practice/practice PARFILE=dp1.par
Все элементы dpi.par будут переданы в задание Data Pump Export. Будет выполнено задание Data Pump Export в режиме Schema (применяемый по умолчанию тип экспорта) и выходные данные утилиты (только листинг анных, но не сами данные) будут записаны в файл в ранее определенном каталоге dtpump. При выполнении утилиты expdp выход-ныо данные оудут записямкт « г*ттл*тг«гггатт1глк< /——----------------------
480
Гпава 12
строки для каждого из основных типов объектов — таблиц, разрешений индексов и т.п.):
□ EXPORT: Release 10.1.0.1.0 on Wednesday, 26 May, 2004 17:29
Copyright (c) 2003, Oracle. All rights reserved.
Connected to: OraclelOi Enterprise Edition Release 10.1.0.1.0
With the Partitioning, OLAP and Data Mining options
FLASHBACK automatically enabled to preserve database integrity.
Starting “PRACTICE”.”SYS_EXPORT_SCHEMA_01“: practice/******** parfile=dp1.par
Processing object type SCHEMA,EXPORT/SE_PRE_SCHEMA_PROCOBJACT/PROCACT_SCHEMA
Processing object type SCHEMA,EXPORT/TYPE/TYPE.SPEC
Processing object type SCHEMA,EXPORT/TABLE/TABLE
Processing object type SCHEMA,EXPORT/TABLE/GRANT/OBJECT_GRANT
Processing object type SCHEMA,EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA,EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA,EXPORT/TABLE/COMMENT
Processing object type SCHEMA-EXPORT/VIEW/VIEW
Processing object type SCHEMA,EXPORT/PACKAGE/PACKAGE.SPEC
Processing object type SCHEMA EXPORT/PACKAGE/PACKAGE_BODY
Processing object type SCHEMA_EXPORT/PACKAGE/GRANT/OBJECT_GRANT
Processing object type SCHEMA,EXPORT/TABLE/CONSTRAINT/REF.CONSTRAINT
Processing object type SCHEMA_EXPORT/SE_EV_TRIGGER/TRIGGER
Master table “PRACTICE”."SYS_EXP0RT_SCHEMA_01" successfully loaded/unloaded. ip****************************************************************************** Dump file set for PRACTICE.SYS_EXP0RT_SCHEMA_01 is:
E:\DTPUMP\METADATAONLY.DMP
Job “PRACTICE"."SYS_EXP0RT_SCHEMA_01” successfully completed at 17:30
Как показано в листинге, выходной файл дампа называется METADATAONLY.DMP. Этот выходной файл содержит элементы XML для повторного создания структур для схемы Practice. Во время экспорта Data Pump создала и использовала внешнюю таблицу с именем SYS, EXPORT_SCHEMA_01. - —*
Примечание Файлы дампа не перекрывают существовавшие ранее файлы дампа в этом самом каталоге.
Для одного задания Data Pump Export можно использовать нескольк каталогов и файлов дампа. В составе установки параметра DUMPr нужно перечислить имена каталогов вместе с именами файлов в след) щем формате:
□ 0иМРЕ1ЕЕ=каталог1:файл1.dmp, каталог2:файл2.dmp
Остановка и перезапуск выполняющихся заданий
поТХТ™ задание Data PumP Export запущено, клиентское окно, использовавшееся для запуска задания, можно закрыть. Поскольку процесс „ поодолжит спор „„пппнение. ПоЗ'
Опции резервного копирования и восстановления
481
же можно в любой момент подключиться к заданию, проверить его статус и изменить его. Например, можно запустить задание с помощью expdp:
О expdp practice/practice PARFILE=dp1.par
Чтобы выйти из окна показа протокола выполнения, нужно нажать на клавиши CTRL-C, и Data Pump возвратит вас к приглашению экспорта:
□ Export>
Выйдите в операционную систему, используя для этого команду ЕХ1Т_ CLIENT:
□ Export> EXITJLIENT
Впоследствии можно перезапустить клиента и присоединиться к выполняющемуся в это самое время под вашей схемой заданию:
□ expdp practice/practice attach
Если заданию Data Pump Export было явно присвоено имя, укажите его как часть параметра ATTACH вызова. Если, например, задание было названо PRACTICEJOB, нужно подключиться к заданию по имени:
□ expdp practice/practice attach = PRACTICEJOB
Если происходит подключение к работающему заданию, Data Pump покажет статус этого задания — основные параметры конфигурации и его текущее состояние. После этого можно задать команду CONTINUE-CLIENT, чтобы ознакомиться со сгенерированными элементами протокола или изменить выполняющееся задание:
□ Export> CONTINUEJLIENT
Можно остановить задание с помощью опции STOP JOB:
□ Export> STOP_JOB
При остановленном задании можно, используя команду ADDJFILE, добавить в него новые файлы дампа в новых каталогах, после чего продолжить выполнение задания:
О Export> START JOB
Можно с помощью параметра LOGFILE специфицировать место размещения файла журнала для протокола создания дампа. Если параметр LOGFILE не задан, файл протокола будет записан в тот же каталог, что и файл дампа.
Экспорт из другой базы данных
Для экспорта данных из другой базы данных можно использовать параметр NETWORK_LINK. Если вы зарегистрированы в базе данных HQ и у вас есть связь оаз данных с другой базой данных, Data Pump может использовать эту связь для подключения к базе данных и извлечения из нее данных.
482
Гпава 1g
Примечание Если исходная база является базой данных “только для чтения" пользователь исходной базы данных должен иметь локально управляемое таблин-ное пространство, назначенное как временное табличное пространство; в противном случае задание завершится аварийно.
В файле параметров (или в командной строке команды expdp) нужно задать параметр NETWORK_LINK равным имени связи баз данных. Утилита Data Pump Export будет писать данные из удаленной базы данных в каталог, определенный в локальной базе данных.
Использование опций EXCLUDE, INCLUDE и QUERY
С помощью опций EXCLUDE и INCLUDE можно исключать или включать наборы таблиц из Data Pump Export. Исключать объекты можно по типу и по имени. Опция EXCLUDE имеет следующий формат:
□ ЕХСЕ1ЮЕ=тип_обьекта[ :фраза_имени] [, . . . ]
Примечание Если было специфицировано CONTENT=DATA_ONLY, то опцию EXCLUDE специфицировать нельзя.
Например, для исключения из полного экспорта базы данных схемы PRACTICE формат опции EXCLUDE должен быть следующим:
□ EXCLUDE=SCHEMA:"=’PRACTICE’”
Примечание В одном задании Data Pump Export не должно быть специфицировано более одной опции EXCLUDE.
В предыдущем примере опция EXCLUDE содержит ограничивающее условие (= ‘PRACTICE’), заключенное в пару двойных кавычек. Переменная тип_объекта может быть любым объектным типом Oracle, включая разрешение, индекс или таблицу. Переменная фраза_им,ениограничиваем возвращаемые значения. К примеру, для исключения из экспорта все. файлов, имена которых начинаются с “TEMP”, следует специфицировать следующее:
□ EXCLUDE=TABLE:"LIKE ‘ТЕМР%’"
Когда это вводится в командную строку, может потребоваться при ег нуть к использованию экранирующего символа, чтобы знаки кавыч и прочие специальные символы были правильно переданы в Oracle, манда expdp должна быть задана в следующем формате:
□ expdp practice/practice EXCLUDE=TABLE:\”LIKE \’ТЕМР%\’\”
Примечание Этот пример демонстрирует только часть синтаксических возмог ностей команды.
Опции резервного копирования и восстановления
483
Если не было задано значение фраза_имени, будут исключены все объекты специфицированного типа. Так, например, для исключения всех индексов необходимо задать следующую команду:
□ expdp practice/practice EXCLUDE=INDEX
Для получения листинга объектов, среди которых можно проводить отбор, нужно задать запрос к представлениям словаря данных DATABASEJEXPORT_O EJECTS, SCHEMA_EXPORT_OBJECTS и TABLE_ EXPORT-OBJECTS. Если значение тип_объекта равно CONSTRAINT, окажется невозможно удалить ограничения NOT NULL. Кроме того, нельзя также удалить ограничения, требующиеся для успешного создания таблицы (например, ограничения первичного ключа для индекс-таб-лиц). Если значение тип_объекта равно USER, исключаются определения пользовагеля, но объекты внутри схемы пользователя, тем не менее, буду!'экспортироваться. Нужно использовать тип_объекта SCHEMA, как показано в предыдущем примере, для исключения пользователя и всех его объектов. Если значение тип_объекта равно GRANT, будут исключены все объектные разрешения и все разрешения системных привилегий.
Кроме того, есть еще одна опция — INCLUDE. При использовании этой опции будут экспортированы только объекты, которые прошли сквозь критерии отбора; все прочие объекты будут исключены. Опции INCLUDE и EXCLUDE являются взаимоисключающими. Опция INCLUDE имеет следующий формат:
□ INCLUDE = тип_объекта[:фраза_имени] [,...]
Примечание Если было специфицировано CONTENT=DATA_ONLY, специфицировать INCLUDE нельзя.
Например, для экспорта двух таблиц и всех процедур в файл параметров необходимо включить две следующие строки:
□ INCLUDE=TABLE:"IN ('BOOKSHELF’BOOKSHELF_AUTHOR')" INCLUDE=PROCEOURE
Какие строки будут экспортированы для объекта, который удовлетво-ряет критериям EXCLUDE или INCLUDE? По умолчанию для каждой таблицы будут экспортированы все строки. Для ограничения числа возвращаемых строк можно использовать опцию QUERY. Эта опция имеет следующий формат:
Q Е Y = :схема.][имя_таблицы:] фраза_запроса
Если значения переменных схема и имя_таблицы не будут указаны, выражение фраза_запроса будет применяться ко всем экспортируемым таблицам. Поскольку фраза_запроса обычно включает в себя имена конкретных столбцов, следует быть весьма осторожным при выборе таблиц для включения в экспорт. Можно специфицировать значение QUERY для одной таблицы:
□ QUERY=BOOKSHELF:’ WHERE Rating > 2”’
484
Гпава 12
В результате файл дампа будет содержать только строки, удовлетво ряющие критерию из запроса QUERY, а также критериям из EXCLUDE или INCLUDE. Эти ограничения можно будет применять и в последующих заданиях Data Pump Import (см. ниже).
Опции Data Pump Import
Для импорта файла дампа, экспортированного с помощью Data Pump Export, следует использовать Data Pump Import. Как и для процесса экспорта, задание для процесса импорта запускается на сервере и им можно управлять во время выполнения. Взаимодействовать с Data Pump Import можно с помощью интерфейса командной строки, файла параметров и интерактивного интерфейса.
Таблица 12.3. Параметры командной строки Data Pump Import
Параметр
ATTACH
CONTENT
DIRECTORY
DUMPFILE
ESTIMATE
EXCLUDE FLASHBACK_SCN
FLASHBACK_TIME
FULL
HELP
INCLUDE
JOB_NAME
LOGFILE
NETWORK-LINK
Описание
Подключает клиента к сеансу на сервере и помещает его в интерактивный режим.
Фильтрует то, что будет импортироваться: ALL, DATA_ONLY или METADATA-ONLY.
Специфицирует место нахождения набора файлов дампа и целевой каталог для файлов протокола и файла с командами SQL.
Специфицирует имена и (при желании) каталоги для набора файлов дампа.
Определяет используемый для определения размера файла дампа метод (BLOCKS или STATISTICS).
Исключает объекты и данные из числа импортируемых.
Номер SCN базы данных, по состоянию на который производится ретроспекция во время импорта.
Отметка времени для базы данных, по состоянию на которую производится ретроспекция во время импорта.
Флажок Y/N используется для указания, что необходимо импортировать файл полного дампа.
Выводит список возможных команд и опций для режима импорта.
Специфицирует критерии, по которым будут импортировать ся объекты.
Указывает имя задания; по умолчанию имя задания генери руется системой.
Имя файла и (необязательно) имя каталога для протокола импорта.
Специфицирует исходную связь баз данных для задания Data Pump, ведущего импорт в удаленную базу данных.
Опции резервного копирования и восстановления
485
Таблица 12.3 (Продолжение)
Параметр Описание
N0L0GF1LE Флажок Y/N, Используемый для подавления создания файла протокола.
PARALLEL Устанавливает количество рабочих процессов (обработчиков) для задания Data Pump Import.
PARFILE Устанавливает имя файла параметров, если он используется.
QUERY Фильтрует строки таблиц во время импорта.
REMAP.DATAFILE Во время импорта изменяет в командах create library, create tablespace и create directory имя исходного файла данных в имя целевого файла данных.
REMAP_SCHEMA Импортирует данные, экспортированные из исходной схемы в целевую схему.
REMAP_TABLESPACE Импортирует данные, экспортированные из исходного табличного пространства, в целевое табличное пространство.
REUSE_DATAFILES Указывает, нужно ли использовать повторно существующие файлы данных при выполнении команд create tablespace во время выполнения полного (Full) импорта.
SCHEMAS Имена схем, которые будут импортированы при импорте в режиме Schema.
SKIPJJNUSABLEJNDEXES Флажок Y/N. Если установлен на Y, при импорте данные не будут загружаться в таблицы, индексы которых переведены в состояние Index Unusable (индекс не используется).
SQLFILE Именует файл, в котором записаны команды DDL для выполнения импорта. Данные и метаданные (этого файла. — Прим, пер.) не будут загружены в целевую базу данных.
STATUS Выводит детализированные данные о статусе (состоянии) задания Data Pump.
STREAMS_CONFIGURATION Флажок Y/N используется для указания, должна ли импортироваться информация о конфигурации Streams.
TABLE_EXISTS_ACTION Дает указания заданию импорта, как поступить, если подлежащая импорту таблица уже существует. Имеющиеся значения: SKIP, APPEND, TRUNCATE и REPLACE. По умолчанию используется APPEND при CONTENT=DATA_ONLY; в противном случае значение по умолчанию равно SKIP.
TABLES TABLESPACES Список таблиц для режима импорта Table. Перечисляет табличные пространства, подлежащие импорту в режиме Tablespace.
TRANSFORM Во время импорта направляет изменения в атрибуты сегмента или хранения.
TRANSPORT_DATAFILES Перечисляет файлы данных, подлежащие импорту во время импорта в режиме Transportable Tablespace.
486
Гпава /2
Параметр
TRANSPORTJ4JLL_CHECK
TRANSPORTTABLESPACES
VERSION
Таблица 12.3 (Продолжение)
Описание
Специфицирует, требуется ли подвергать подлежащее импорту табличное пространство проверке на принадлежность к обособленному набору (self-contained set) табличных пространств.
Перечисляет все табличные пространства, подлежащие импорту во время выполнения задания на импорт в режиме Transportable Tablespace.
Задает версию подлежащих созданию объектов базы данных, так чтобы набор файлов дампа мог быть совместимым с предыдущими версиями Oracle. Возможные варианты: COMPATIBLE, LATEST и конкретные номера версий базы данных (не ниже чем 10.0.0). Действителен только для NETWORK-LINK и SQLFILE.
Примечание Каталоги, в которых размещаются файлы дампа и протокола, должны уже существовать; о команде create directory см. выше.
Как и в случае Data Pump Export, Data Pump Import поддерживает пять режимов импорта: Full, Schema, Table, Tablespace и Transportable Tablespace. Если режим импорта не указан, Data File Import пытается загрузить весь файл дампа.
В таблице 12.4 перечисляются параметры, используемые в интерактивном режиме Data Pump Import.
Многие параметры Data Pump Import — это те же самые параметры, которые были доступны и для Data Pump Export.
Таблица 12.4. Параметры интерактивного режима Data Pump Import
Параметр Описание
CONTINUE-CLIENT Выйти из интерактивного режима и войти в режим регистрации. Задание будет перезапущено, если оно свободно.
EXIT-CLIENT Выйти из клиентского сеанса, оставив при этом задание Data Pump Import выполняющимся на сервере.
HELP Вывести на экран оперативную помощь для импорта.
KILL-JOB Уничтожить текущее задание и отсоединить связанные с ним клиентские сеансы.
PARALLEL Изменить число обработчиков для задания Data Pump Import.
STARTJOB Перезапустить присоединенное задание.
STATUS Вывести детализированный статус задания Data Pump.
STOP_JOB Остановить задание для запуска впоследствии.
Опции резервного копирования и восстановления
487
Запуск задания Data Pump Import
Запустить задание Data Pump Import можно с помощью поставляемого в составе Oracle Database 10g выполняемого файла impdp. Для указания режима импорта и мест размещения всех задействованных файлов надо использовать параметры командной строки. Можно сохранить значения параметров в файле параметров и затем ссылаться на пего посредством опции PARFILE.
В первом примере экспорта из этой главы в файле параметров dpi.par содержались следующие элементы:
□ DIRECTORY^dtpump
DUMPFILE=metadataonly.dmp
CONTENT=METADATA_ONLY
В процессе импорта объекты схемы PRACTICE будут созданы в другой схеме. Опция REMAPJSCHEMA позволяет импортировать объекты в схемы, отличающиеся от тех схем, которые были использованы при экспорте.
Если желательно в то же время изменить назначения табличных пространств, нужно использовать опцию REMAP_TABLESPACE. REMAP_ SCHEMA имеет следующий формат:
□ ЯЕМАР_8СНЕМА=исходная_схема:целевая_схема
Затем надо создать новую учетную запись пользователя для хранения объектов:
□ create user Newpractice identified by newp; grant CREATE SESSION to Newpractice;
grant CREATE SESSION to Newpractice;
grant CREATE TABLE to Newpractice;
grant CREATE INDEX to Newpractice;
Теперь можно добавить строку REMAPJSCHEMA в файл параметров dp 1.par:
О DIRECTORY=dtpump
DUMPFILE=metadataonly.dmp
CONTENT=METADATA_ONLY
REMAP_SCHEMA=Practice:Newpractice
Теперь можно запустить задание импорта. Поскольку схема-владелец данных изменяется, нужно иметь системную привилегию IMPJFULL DATABASE. Задания Data Pump Import запускаются через выполняемый файл impdp. В следующем примере показано создание задания Data Pump Import с использованием файла параметров dpi.par:
О impdp system/passwd parfile=dp1.par
Примечание К моменту запуска задания должны быть специфицированы все файлы дампа.
488
Гпава
Затем Oracle приступит к выполнению импорта и будет информцр0, вать о его прогрессе. Поскольку опция NOLOGFILE не была указана файл протокола импорта будет помещен в тот же самый каталог, где находятся файлы дампа, и ему будет присвоено имя import.log. Можно верифицировать (подтвердить) успешность импорта, если войти в схему Newpractice и зарегистрироваться в ней. В схеме Newpractice должны содержаться копии всех действующих объектов, которые были ранее созданы в схеме Practice.
Что будет, если импортируемая таблица уже существует? В этом примере, если опция CONTENT установлена на METADATA_ONLY, то по умолчанию таблица будет пропущена. Если опция CONTENT установлена на DATA_ONLY, то новые данные будут записаны в конец таблицы, после уже содержащихся в ней данных. Чтобы изменись подобное поведение, нужно использовать опцию TABLE_EXISTS_ACTION. Допустимыми значениями для TABLE_EXISTS_ACTION являются SKIP, APPEND TRUNCATE и REPLACE.
Остановка и повторный запуск выполняющихся заданий
После запуска задания Data Pump Import можно закрыть клиентское окно, которое было использовано для запуска задания. Поскольку задание выполняется на сервере, осуществление импорта будет продолжено. После этого можно в любое время подключиться к заданию, проверить его статус и изменить его:
□ impdp system/passwd PARFILE=dp1.par
Чтобы выйти из окна показа протокола выполнения, нужно нажать на клавиши CTRL-C, и Data Pump возвратит к приглашению импорта:
□ Import>
С^Выйдите в операционную систему, используя для этого команду EXIT.
о Import> EXIT_CLIENT
ВДщемум в э“" и соединить к «и
указать как часть параметра ATTACH^0 ЯВН° пРисвоено имя, его нужно щему заданию, Data Punin пока» вызова’ Если подключиться к рабо-параметры конфигурации и его т СТа1ус этого заДания - основные задать команду CONTINUE СОЕМт466 СОСТОя™е. После этого можно иными элементами протокола м ’ Чтобь' ознакомиться со сгенериро-
□ Import> CONTINUE Cl трыт и изменить выполняющееся задание:
Можно остановить залаим»
П т задание с помощью опции егоо тги>
a Import> STOP job ции STOP JOB:
Опции резервного копирования и восстановления
489
При остановленном задании можно увеличить для него степень параллелизма с помощью опции PARALLEL, после чего продолжить выполнение задания:
□ Import> STARTJOB
EXCLUDE, INCLUDE и QUERY
Утилита Data Pump Import, как и Data Pump Export, позволяет ограничить объем обрабатываемых данных за счет применения опций EXCLUDE, INCLUDE и QUERY (см. выше в данной главе). Поскольку можно использовать эти опции как при экспорте, так и при импорте, то результатом становится большая гибкость импорта. Например, можно решить экспортировать всю таблицу целиком, а потом импортировать только ее часть — строки, соответствующие указанному в опции QUERY критерию. Можно решить экспортировать всю схему, но потом при восстановлении базы данных с помощью импорта включить только самые необходимые таблицы, чтобы свести к минимуму время простоя приложения. Опции EXCLUDE, INCLUDE и QUERY обеспечивают разработчикам и администраторам баз данных мощные возможности при выполнении заданий экспорта и импорта.
Трансформация импортированных объектов
В дополнение к изменению или отбору схем, табличных пространств, файлов данных и строк во время импорта, можно изменить атрибуты сегмента или требования к хранению при импорте путем применения опции TRANSFORM. Эта опция имеет следующий формат:
□ TRANSFORM = имя преобразования: значение[ :тип_объекта]
Переменная имя_преобразования может иметь значение SEGMENTATTRIBUTES или STORAGE. Переменную значение можно использовать для включения или исключения атрибутов сегмента (это физические атрибуты, атрибуты хранения, табличные пространства и регистрация). Переменная тип_объекта является опциональной и, если она определена, должна принимать одно из двух значений: TABLE или INDEX.
Например, при экспорте/импорте могут измениться требования хранения объекта — возможно, для сокращения числа импортируемых строк была использована опция QUERY или импортированы только метаданные без данных самой таблицы. Для устранения из импортированных таблиц экспортированных фраз о хранении нужно добавить в файл параметров следующее:
О TRANSFORM=STORAGE:n:table
Для устранения из всех таблиц и индексов экспортированных фраз о табличных пространствах и хранении нужно использовать следующее:
О TRANSFORM=SEGMENT_ATTRIBUTE:п
При импорте объектов они будут назначены в используемые по умолчанию табличные пространства пользователя, а для их хранения будут использованы параметры по умолчанию для хранения
490
Гпава 12
Генерация SQL
Вместо импортирования данных и объектов можно сгенерировать операторы SQL для этих объектов (не для данных) в файле операционной системы компьютера. Этот файл будет записан в тот каталог и с тем именем, которые были специфицированы посредством опции SQLFILE. Эта опция имеет следующий формат:
□ 80ЕЕ1ЕЕ=[объект_каталога:]имя_файла
Примечание Если не было указано значение для переменной объект_каталога, файл будет создан в каталоге для файлов дампа.
Приведенный ниже листинг демонстрирует файл параметров для импорта с использованием опции SQLFILE. Опция CONTENT не специфицирована. Выходные данные будут записаны в каталог DTPUMP.
□ DIRECTORY=dtpump
DUMPFILE=metadataonly.drop
SQLFILE-sql.txt
Чтобы заполнить файл sql.txt, можно выполнить импорт:
□ impdp practice/practice partile=dp1.par
В созданном при импорте файле sql.txt можно увидеть элементы для каждого типа объектов схемы. Формат этого листинга будет похож на приведенный ниже листинг, хотя идентификаторы объектов и SCN в данном случае будут, конечно, другими. Для краткости здесь приводятся не все строки файла:
□ - CONNECT PRACTICE
-- new object type path is: SCHEMA_EXPORT/ SE_PRE__SCHEMA_PROCOBJACT/PROCACT_SCHEMA
BEGIN
sys.dbmS-loprep-imp.instantiate_schema(schema_name=>’PRAC ICE’;
export_db_name=>’ORCL’, inst_scn=>’3377908’);
COMMIT;
END;
-- new object type path is: SCHEMA_EXPORT/TABLE/TABLE
CREATE TABLE "PRACTICE”."STOCK TRX"
( "ACCOUNT” NUMBER (10,0),
"SYMBOL” VARCHAR2 (20),
"PRICE” NUMBER (6,2),
"QUANTITY” NUMBER (6,0),
"TRX FLAG” VARCHAR2 (1) p
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGIA STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 214748364b PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER^POOL DEFAULT)
TABLESPACE "USERS” ;
Опции резервного копирования и восстановления
491
CREATE TABLE “PRACTICE”."STOCK.ACCOUNT"
(“ACCOUNT” NUMBER (10,0),
“ACCOUNTLONGNAME” VARCHAR2 (50)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER.POOL DEFAULT)
TABLESPACE “USERS” ;
-- new object type path is: SCHEMA_EXPORT/TABLE/GRANT/OBJECT_GRANT GRANT SELECT ON “PRACTICE”."STOCK TRX” TO “ADAMS”;
GRANT SELECT ON “PRACTICE”."STOCK.TRX” TO “BURLINGTON”;
GRANT SELECT ON “PRACTICE”."STOCK-ACCOUNT" TO “ADAMS”;
GRANT SELECT ON “PRACTICE”."STOCK-ACCOUNT" TO “BURLINGTON”;
GRANT INSERT ON “PRACTICE”."STOCK-ACCOUNT" TO “ADAMS”;
Выходной файл SQLFILE является файлом в свободной форме, так что его можно редактировать, использовать для SQL*Plus или сохранить для целей документирования структур базы данных приложения.
Сравнение Data Pump Export/lmport с Export/lmport
Оригинальные утилиты Export и Import продолжают оставаться доступными через выполняемые файлы ехр и imp соответственно. Есть множество направлений, по которым Data Pump Export и Import демонстрируют свое превосходство над оригинальными утилитами Export и Import. Структура Data Pump, полностью базирующаяся на использовании сервера базы данных, приводит к выигрышу в производительности и повышению управляемости. Однако, Data Pump не поддерживает возможностей инкрементального фиксирования (incremental commit), предлагавшихся параметрами COMMIT и BUFFER в первоначальной утилите Import. Кроме того, Data Pump не поддерживает автоматическое слияние нескольких экстентов в единый экстент во время выполнения процесса Data Pump Export/lmport; в первоначальных утилитах Export/lmport эта возможность обеспечивалась благодаря параметру COMPRESS. В Data Pump для подавления во время импорта существующих атриб> гов хранения можно использовать опцию TRANSFORM — опцию, которую многие пользователи оригинальных утилит Export/lmport могут предпочесть функциональности COMPRESS.
Если данные импортируются в существующую таблицу с помощью Data Pump и при этом используются установки APPEND или TRUNCATE опции TABLEJEXISTS-ACTION, а строка нарушает активное ограничение, загрузка прерывается и данные не загружаются. В оригинальной утилите Import загрузка была бы продолжена.
Реализация автономного резервного копирования
Автономное резервное копирование представляет собой физическое копирование файлов базы данных, выполняемое после ее остановки с помощью команд shutdown normal, shutdown immediate или shutdown transactional. Пока база данных не функционирует, копируются все ее ак
492
Гпава 12
тивно используемые файлы, содержащие полный образ базы данных на тот момент, когда она была остановлена.
Примечание Не следует полагаться на результаты автономного копирования, выполненного после команды shutdown abort, поскольку они могут быть несогласо* ванными. При необходимости примените эту команду, затем запустите базу данных снова, и выполните обычную команду shutdown или shutdown immediate, или shutdown transactional и только потом выполняйте автономное копирование.
В процессе холодного резервного копирования должны быть скопированы следующие файлы:
Все файлы данных
Все управляющие файлы
Все оперативные журналы базы данных
Можно также дополнительно произвести резервное копирование файла параметров инициализации базы данных, особенно если резервная копия должна послужить основой для процесса восстановления после фатальной ошибки.
Для упрощения процесса резервного копирования нужно использовать согласованную структуру каталогов для файлов данных. В такой архитектуре все файлы данных расположены в каталогах разных устройств, но на одном и том же уровне. В следующем листинге показан пример дерева каталогов для диска данных /dbOl:
□ /db01
/oracle
/CASE
controll.dbf
sysOl.dbf tools.dbf /СС1
controll.dbf
sysOl.dbf tools.dbf /DEMO
controll.dbf
sysOl.dbf
В этом примере все файлы базы данных находятся в подкаталогах э земпляров каталога /oracle устройства. Такие каталоги должны сод г жать файлы данных, файлы журналов базы данных и управляющие <р лы базы данных.
При использовании подобной структуры каталогов команды резеР^ ного копирования существенно упрощаются. В следующем примере с мощью команды tar (Unix) осуществляется копирование файлов ленточный носитель /dev/rmt/Ohc. Поскольку структура каталогов гласована, а логические диски имеют имена от /dbOl до /db09, слеДУ
Опции резервного копирования и восстановления
493
щая команда позволяет осуществить копирование всех файлов данных базы данных СС1, файлов журналов базы данных и управляющих файлов:
□ > tar -cvf / dev/rmt/Ohc /dbO[1-9]/oracle/CC1
Примечание Предоставляемая Oracle утилита RMAN (подробнее о RMAN см. главу 13) упрощает процесс резервного копирования. В примерах этой главы используются процедуры резервного копирования, управляемые пользователем.
Флажок -cvf используется для создания нового набора сохранения (saveset) команды tar. Во многих производственных системах при резервном копировании файлы записываются в отдельную область файловой системы, а затем база данных запускается снова. Метод резервного копирования с диска на диск протекает существенно быстрее, чем с диска на ленту, что позволяет закрывать базу данных на более короткий период времени. После ее перезапуска резервные копии файлов можно записывать на ленту, и это не будет влиять на ее доступность.
Примечание При использовании резервного копирования с диска на диск как части общей стратегии резервного копирования следует отделить эти диски от производственных. В противном случае сбой дисков производственной базы данных может подействовать на самые свежие резервные копии.
Поскольку в процессе резервного копирования база данных становится менее доступной, эту процедуру обычно планируют на ночное время.
В процессе восстановления автономное резервное копирование может восстановить базу данных на тот момент времени, в который она была закрыта. Как правило, автономное резервное копирование играет роль в планировании восстановления после аварийных ситуаций, поскольку резервные копии автономны и восстановление на специализированном сервере восстановления после аварийных ситуаций может быть проще, чем другие типы резервного копирования. Если база данных работает в режиме ARCHIVELOG, можно применить к восстанавливаемым резервным копиям архивные журналы базы данных.
Реализация оперативного резервного копирования
Согласованное автономное резервное копирование может выполняться только после отключения базы данных. Но, если она работает в режиме ARCHIVELOG, можно копировать ее файлы, пока она открыта, и такое копире вание будет выполнено корректно (полученная резервная копия будет непротиворечивой. — Прим. пер.). Такой вариант обычно называется оперативным резервным копированием.
СУРБД Oracle осуществляет запись в файлы оперативных журналов базы данных циклически: заполнив первый файл, начинает запись во второй, после него в третий и т.д. Заполнив последний файл, фоновый процесс LGWR (Log Writer) начинает перезаписывать содержание файла первого журнала базы данных.
494
Гпава 1g
Когда Oracle работает в режиме ARCHIVELOG, фоновый процесс ARCH делает копию каждого файла оперативных журналов сразу после его заполнения. Обычно эти архивные файлы журналов базы данных записываются на дисковое устройство. Их можно записывать и непосредственно на ленточный носитель, но это требует значительных дополнительных усилий со стороны оператора.
Начало работы
Чтобы воспользоваться возможностями режима ARCHIVELOG, нужно сначала перевести базу данных в этот режим. В следующем листинге показано, как это можно сделать.
П SQL> SQL> SQL> SQL>
connect internal as sysdba startup mount cc1;
alter database archivelog;
alter database open;
Примечаний Для просмотра текущего активного оперативного журнала и его последовательного номера следует задать запрос к динамическому представлению V$LOG.
Для обратного перевода базы данных в режим NOARCHIVELOG нужно воспользоваться набором команд:
□ SQL> connect / as sysdba
SQL> startup mount cd;
SQL> alter database noarchivelog;
SQL> alter database open;
База данных, переключенная в режим ARCHIVELOG, останется в нем, пока не будет переведена в режим NOARCHIVELOG.
Расположение архивных файлов журналов базы данных определяется настройками файла параметров базы данных. Достойными упоминания являются следующие параметры (с примерами значений):
□ log_archive_dest_1 = ‘L0CATI0N=”/db01/oracle/arch/CC1/arch”’,
log_archive_dest_state_1 = ENABLE
log_archive_start = TRUE
В данном примере архивные файлы журналов базы данных записыв ются в каталог /dbOl/Oracle/arch/CCl/arch.
Каждый из этих файлов содержит данные одного оперативного жуЕ нала. Они пронумерованы последовательно, в порядке их создания. мер таких файлов бывает разным, но не превышает размера файлов ративных журналов базы данных. J
Если в целевом каталоге с архивными файлами журналов базы дан не хватает места, процесс ARCH прекращает обработку оперативных Д ных этих журналов, а база данных останавливается. Для решения пр° мы нужно добавить дополнительное место на диске с архивными фаИ ми журналов базы данных или сделать архивные копии этих файл а сами файлы удалить из каталога.
Опции резервного копирования и восстановления
495
Примечание Нельзя удалять архивные файлы журналов, пока не сделаны их резервные копии и вы не удостоверитесь, что процесс их восстановления прошел успешно.
В работающей в данный момент базе данных можно запросить текущие настройки параметров из динамического представления производительности V$PARAMETER:
□ select Name,
Value
from V$PARAMETER
where Name like ‘log_arhive%’;
Хотя параметр LOG_ARHIVE_START можно задать как TRUE, база данных не перейдет в режим ARCHIVELOG, пока не будет выполнена команда alter database arhivelog (см. выше). После перехода в этот режим, база данных останется в нем и при последующих процедурах закрытия и запуска, пока она не будет переведена явным образом в режим NOARCHIVELOG с помощью команды alter database noarchivelog.
Примечание Чтобы из Oracle Enterprise Manager (OEM) увидеть, находится ли база данных в режиме ARCHIVELOG, нужно заглянуть в раздел General экрана Instance Manager.
Автоматическое мультиплексирование архивных файлов журналов
Можно дать базе данных указание осуществлять запись в несколько различных областей расположения архивных файлов журналов базы данных одновременно. Это позволит восстановить базу данных, даже если один из дисков с архивными файлами выйдет из строя. Процесс архивирования должен быть в состоянии провести запись как минимум в одно местонахождение, для того чтобы база данных могла продолжать работу; можно задать число успешно произведенных записей.
Примечание Запись в несколько областей расположения архивных файлов журналов Oracle осуществляет одновременно, а не последовательно.
С помощью параметра LOG_ARCHIVE_DEST_7z можно определить до десяти местоположений архивных файлов журналов базы данных (LOG_ ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2 и т.д.). Процесс ARCH будет осуществлять запись файлов во все указанные места одновременно. Для каждого такого места с помощью параметра LOG_ARCHIVEJDEST_ STATE_n определено соответствующее “состояние”. Состояние архива назначения может быть ENABLED (тогда в него осуществляется запись файлов) либо DEFER (тогда архив назначения не является активным). Для каждого элемента LOG_ARCHIVE_DEST_n файла init.ora можно создать элемент LOG_ARCHIVE__DEST_STATE_n (например LOG ARCHIVEJDEST_STATE_1, LOG_ARCHIVE_DEST_STATE_2 и т д.).
496
Гпввв
Выполнение оперативного резервного копирования базы данных
Если база данных работает в режиме ARCHIVELOG, можно осуществить ее резервное копирование, пока она открыта и доступна для пользователей. Это позволяет сделать базу данных доступной круглосуточно и гарантировать возможность ее восстановления.
Хотя оперативное резервное копирование можно выполнять и в рабочее время, лучше запланировать его на время наименьшей активности пользователей. На это имеются две причины. Во-первых, для резервного копирования физических файлов используются команды операционной системы, а они потребляют большую часть доступных системных ресурсов ввода/вывода (что снижает производительность системы для интерактивных пользователей). Во-вторых, во время резервного копирования табличных пространств изменяется способ записи транзакций в архивные файлы журналов базы данных. При переводе табличного пространства в режим “оперативного резервного копирования” процесс DBWR записывает все блоки в кэш буфера, принадлежащий любому файлу, который является частью этого табличного пространства на диске. Когда блоки считываются обратно в память, а затем изменяются, они копируются в буфер журнала при самом первом их изменении. Пока они остаются в кэше буфера, их не копируют повторно в оперативный файл журналов. Это потребует гораздо больше места в целевом каталоге архивированного файла журнала базы данных.
Примечание Можно создать командный файл .для выполнения оперативного резервного копирования, но по нескольким причинам предпочтительнее использовать для этого RMAN: дело в том, что RMAN поддерживает каталог резервных копий, позволяет управлять репозиторием резервных копий и выполнять инкрементальное копирование базы данных.
Если нужно создать собственный командный файл для выполнения оперативного резервного копирования, командный файл должен включать следующие шаги:
1. Установка базы данных в режим резервного копирования (до появ ления Oracle 10g это нужно было делать для каждого табличного пространства в отдельности).
2. Резервное копирование файлов данных
3. Возвращение базы данных в ее нормальное состояние
4. Резервное копирование архивных файлов журналов базы ДаН^ь** При необходимости — сжатие скопированных архивных фаи этих журналов на свободное место в дисковой памяти или их У ление.
5. Резервное копирование управляющих файлов.
Примечание Процесс оперативного резервного копирования может быть авто матизирован с помощью утилиты RMAN (подробнее RMAN см. главу 13).
Опции резервного копирования и восстановления
497
В идеале необходимо поддерживать в области для хранения архивов достаточно свободного места для хранения сжатых архивных журналов базы данных, чтобы избежать необходимости при восстановлении использовать ленточные архивные копии.
Интеграция процедур резервного копирования
Поскольку существуют различные способы резервного копирования баз данных Oracle, нет необходимости, рискуя потерпеть неудачу, полагаться только на один из них. В зависимости от характеристик базы данных нужно выбрать один из них и еще как минимум один использовать в качестве страховочной копии для основного метода резервного копирования.
Примечание При рассмотрении физического резервного копирования следует также оценить использование утилиты RMAN для осуществления инкрементального физического резервного копирования.
В следующих разделах будет показано, как выбрать основной метод резервного копирования для вашей базы данных, как интегрировать логическое и физическое резервное * копирование и как интегрировать резервное копирование средствами базы данных с резервным копированием файловой системы.
Стратегии резервного копирования для очень больших баз данных изложены в главе 17. Детальное изложение RMAN приводится в главе 13.
Интеграция логического и физического резервного копирования
Какие методы резервного копирования доступны для вашей базы данных? Или, точнее, какой метод следует использовать в качестве основного? При решении этого вопроса следует принять во внимание характеристики каждого из методов:
Метод
Data Pump Export
Автономное резервное копирование
Оперативное резервное копирование
Тип Характеристики восстановления
Логический Позволяет восстановить любой объект базы
данных по состоянию на момент экспорта.
Физический Позволяет восстановить базу данных по со-
стоянию на момент ее остановки; если база данных работает в режиме ARCHIVELOG, ее можно восстановить по состоянию на любой момент времени.
Физический Позволяет восстановить базу данных по состоянию на любой момент времени.
Автономное резервное копирование является наименее гибким методом копирования базы данных, если база данных работает в режиме
498
Гпава 1g
NOARCHIVELOG. Создаваемые при автономном резервном копировании копии являются привязанными ко времени моментальными снимками базы данных, и, поскольку они являются физическими копиями, администратор не сможет избирательно восстанавливать из них логические объекты (например, таблицы). Хотя иногда бывает нужен именно такой подход (например, при восстановлении после сбоя), но, как правило, автономные резервные копии можно использовать только как запасной вариант на случай, если основной метод даст сбой. Если база данных работает в режиме ARCHIVELOG, автономные копии можно использовать как основу восстановления носителей, но в этой ситуации обычно больше подходит оперативное резервное копирование.
Выбор метода из двух оставшихся зависит от природы базы данных. Для промышленной среды ответ почти всегда один — оперативное резервное копирование. Если база данных работает в режиме ARCHIVELOG, оно позволяет восстанавливать ее на момент времени, который предшествовал сбою системы или ошибке пользователя. Стратегия, основанная на применении Data Pump Export, неизбежно ограничит вас возможностью вернуться только к данным, существовавшим на мо
мент их последнего экспорта.
Оцените размер базы данных и подумайте, какие объекты, скорее всего, придется восстанавливать. Сколько времени займет восстановление данных в стандартной ситуации, например при поломке диска? Если потерян файл, его проще всего восстановить с физической резервной копии, что опять означает преимущество оперативного копирования по сравнению с экспортом.
Если база данных мала, объем транзакций тоже мал и доступность системы не является проблемой, ващи потребности могут полностью удовлетворить автономное резервное копирование или экспорт. Если вам нужны только одна или две таблицы, для их селективного копирования можно использовать Data Pump Export. Но, если база данных велика, для восстановления может потребоваться слишком много времени. В больших базах данных с незначительным объемом транзакций наиболее приемлемым будет автономное резервное копирование.
Вне зависимости от выбора основного метода резервного копирования окончательная реализация должна включать физическое резервное копирование и какой-либо метод логического резервного копирования с использованием либо Data Pump Export, либо тиражирования. Такая избыточность необходима, так как указанные методы имеют дело с раз личными аспектами базы данных: Data Pump Export свидетельствует о на дежности данных в логическом смысле, а физическое резервное копире вание — о надежности в физическом смысле. Хорошая с за ги резервного копирования интегрирует логическое и физическое копир0 вание базы данных.
При выполнении других действий в базе данных может потребовать ся специальное (нерегламентированное) резервное копирование.
] ± ЛГАЛ A А) ГААГА А> ~ -- А ГТ<1-
ся специальное (нерегламентированное) резервное копирование, пример, автономное копирование необходимо перед модернизаци базы данных, а экспорт — при миграции приложения между базам данных.
Опции резервного копирования и восстановления
499
Интеграция процедур резервного копирования базы данных и операционной системы
Действия администратора БД по созданию резервных копий включают в себя ряд задач, обычно выполняемых группой по управлению системой: мониторинг использования дискового пространства, обслуживание магнитных лент и т.д. Вместо того чтобы дублировать эти работы, лучше интегрировать их и сосредоточиться на балансировке процессов организации. Стратегию резервного,копирования базы данных следует модифицировать так, чтобы с магнитными лентами работал персонал по резервному копированию, а усилия АБД сосредоточили ст. ца централизации процесса управления производством в вашей среде.
Как правило, централизация процессов управления производством осуществляется посредством выделения дисководов для хранения физических резервных копий файлов. Вместо копирования файлов на ленты их можно записывать на диски на том же сервере. Затем с этими дисками будет работать персонал по управлению системой, копируя их так же, как и системные файлы. Администратор не должен заниматься резервным копированием лент, но он должен проверять правильность и успешность завершения процедур резервного копирования, осуществляемых группой по управлению системой.
Если среда базы данных включает в себя файлы, не входящие в базу данных (например, файлы данных для внешних таблиц или файлы, связанные с типами данных BFILE), необходимо определить, как будут копироваться эти файлы, чтобы копии в случае восстановления обеспечили бы согласованные данные. Резервные копии этих плоских файлов должны быть скоординированы с резервными копиями базы данных и интегрированы в любую схему планирования восстановления после чрезвычайных ситуаций.
ГЛАВА 13
ИСПОЛЬЗОВАНИЕ ДИСПЕТЧЕРА ВОССТАНОВЛЕНИЯ (RMAN)
В главе 12 обсуждались несколько различных способов резервного копирования и защиты нашей базы данных от случайного, непреднамеренного или умышленного разрушения. Физические резервные копии базы данных служат гарантией того, что не будет потеряно ни одной незафиксированной транзакции и что можно будет восстановить базу данных с любой предшествующей резервной копии по состоянию на текущий момент времени или на любой другой предшествующий момент. Логические резервные копии помогают АБД или пользователю фиксировать содержимое любого индивидуального объекта базы данных на конкретный момент времени, предлагая тем самым альтернативный вариант восстановления для тех случаев, когда операции восстановления всей базы данных могут оказать чрезмерно большое влияние на остающуюся часть базы данных.
Диспетчер восстановления Oracle (Recovery Manager — RMAN) ставит создание резервных копий и восстановление базы данных на новый урО" вень защиты и простоты использования. С момента появления RMA^ (а произошло это в Oracle версии 8) уже имело место несколько весьма значительных улучшений и усовершенствований, которые могут сделать RMAN единственным привлекательным решением, пригодным практи чески для всех сред баз данных. Помимо сделанных в Oracle lOgycosep шенствований интерфейса командной строки RMAN, функционал нос RMAN была включена в предназначенный для работы в web-средах инт р фейс Oracle Enterprise Manager (OEM), что позволяет АБД вести MOHIiL ринг и выполнять операции резервного копирования в ситуациях, ког под рукой есть только подключение с помощью web-браузера. #
В этой главе будет продемонстрировано много примеров опера RMAN, использующих как интерфейс командной строки, так и е терфейс OEM. е_
В этих примерах будет показана вся гамма действий — от создания ср ды RMAN до резервного копирования, восстановления и подтверЖДей достоверности резервных копий. Будет подробно разобран вопрос о то
Использование диспетчера восстановления (RMAN) 501
как RMAN управляет связанными с базой данных метаданными и их резервными копиями. И, наконец, будут рассмотрены несколько разнообразных вопросов типа использования RMAN для каталогизации резервных копий, сделанных не средствами RMAN.
Вследствие наличия широчайшего спектра ленточных систем управления резервным копированием, обсуждение каких бы то ни было конкретных аппаратных конфигураций остается за пределами тематики данной книги. Вместо этого, здесь внимание будет сосредоточено на использовании Flash Recovery Area — выделенной области, расположенной на диске и предназначенной для хранения дисковых копий всех типов объектов, которые может копировать RMAN. Подобная область является новинкой, впервые появившейся в Oracle 10g.
Для всех примеров этой главы вместе с RMAN используется каталог восстановления. Хотя большая часть функциональности RMAN доступна при использовании только управляющих файлов целевой базы данных, такие преимущества, как возможность сохранения сценариев RMAN и дополнительные возможности восстановления, намного перевешивают относительно небольшие расходы на сопровождение учетной записи пользователя RMAN и репозитория в другой базе данных.
Возможности и компоненты RMAN
с
RMAN представляет собой нечто большее, чем простой выполняемый файл на клиентской стороне, который может выполняться с использованием web-интерфейса. Он состоит из некоторого числа других компонентов, включая подлежащую резервному копированию базу данных (целевая база данных), опциональный (необязательный) каталог восстановления, также опциональную Flash Recovery Area и программное обеспечение управления носителями информации для поддержки ленточных систем резервного копирования.
Многие возможности RMAN не имеют эквивалентов среди методов резервного копирования, представленных в главе 12. Ниже рассматриваются все преимущества и недостатки использования RMAN и противопоставляются более традиционным методам резервного копирования.
Компоненты RMAN
Первым и минимально необходимым компонентом среды RMAN являет-ся выполняемый модуль RMAN. Его вместе с другими утилитами Oracle можно найти в каталоге $ORACLE_HOME/bin, и он автоматически (по умолчанию) инсталлируется для вариантов Standard Edition и Enterprise Edition Oracle 10g. Из приглашения командной строки можно вызвать RMAN с аргументами или без них; в следующем примере запускается RMAN с помощью аутентификации операционной системы без подключения к каталогу восстановления:
О oltp [oracle]$ rman target /
RMAN>
Аргументы командной строки являются необязательными. С таким же успехом можно задать целевую базу данных и каталог восстановления и из
502
Гпава
Л:
Bad
; %
ИЬг
Deployments
Pjich
Clone CAtaba^g
Tools Help
hie edit View Fevur ites
Г onfrgurg free over у ettincs
. П1(Ш R”?£-• =•« . v.Vrn Sen*.
Performance Mi
Maintenance
Utilities
Se
1.^30.i
HprQS Ейййзэж
Maintenance
I
Alert History
П
F
$
Internet
В а с к u p i R о c g v e г у
Schedule баской --**WZW*r-*»-* *** * ЧЖА*
!
Uawnn^^nfig^l^Q
Related Link
Д&Й1£1 ^.rdlsi
•»>>>, лу y/<r, ., ... .. : ♦* :• 1**- 4 : < к -. ... . _ , ,.
t http://l92.163 2 l66:5SOO/eni/ccn5ole/6Mabase/rec/cat^GQ’event-«:stdrtbtarget«=oid.world8dype=crdclej
Рис. 13.1. Получение доступа к функциональным возможностям RMAN из OEM
Search
bttp://19>.16S 2.166;S500/erii/cof>5ale/d3tabdse/r6tarice/$«!:efi'sap7event=dci.o-3dF>i3»Qet»CHdAvotld5type'-aofacte_(f«U^5ei‘C v
А.С f tilfitpnSB Manager Юг?
Svtup Г-SSC*s Her»
►nfpyjraltDn, C&t?ecf lor
строки приглашения: RMAN>. На рис. 13.1 показано, как можно получить доступ к возможностям RMAN из Oracle Enterprise Manager.
От RMAN нс будет большого прока до тех пор, пока не потребуется создать резервную копию базы данных. Одна или несколько целевых оаз данных могут быть внесены в так называемый каталог восстановления (recovery catalog); информация о действиях по резервному копированиях выполненных RMAN, содержится в управляющих файлах подлежащей копированию базы данных. Из клиента RMAN можно также запускать ко манды SQL для операций, которые невозможно выполнить с помощью собственных команд RMAN.
Каталог восстановления RMAN, независимо от того, используется л*1 управляющий файл целевой базы данных или выделенный репозитор ’ содержит местоположения данных для восстановления (recovery йа установки собственной конфигурации и схему целевой базы дань Управляющий файл целевой базы данных, как минимум, содержит данные; чтобы было можно сохранять сценарии и осуществлять сопр ждение копии целевой базы данных, настоятельно рекомендуется пользовать каталог восстановления. Во всех примерах этой главы оу использован каталог восстановления.
Начиная с Oracle 10g, область flash-восстановления значительно упр ет резервное копирование и восстановление с использованием диск°ь памяги за счет выделения па диске специальной области, в которой Гд ня гея все созданные RMAN резервные копии. При выделении места А
^пользование диспетчера восстановления (RMAN)
503
может указать также верхний предел размера области Flash Recovery Area. После того как в RMAN будет определена стратегия сохранения (retention policy), RMAN будет автоматически управлять файлами резервных копий, удаляя устаревшие копии как с диска, так и с ленты (о параметрах инициализации, относящихся к Flash Recovery Area, см. ниже в данной главе).
Для получения доступа к другим носителям информации, не использующим диски (например, к лентам и DVD-ROM), RMAN применяет программное обеспечение управления носителями от третьих фирм для переноса файлов с резервными копиями на эти автономные (offline) и квази-оперативные (near-line) устройства и с них. Монтирование и размонтиро-вание соответствующих носителей для поддержки операций резервного копирования и восстановления запрашивается автоматически. Для управления носителями многие основные производители программного обеспечения разработали специальные драйверы для поддержки RMAN.
RMAN против традиционных методов резервного копирования
Практически пет причин для того, чтобы не использовать RMAN как основное средство для управления резервным копированием. Ниже перечисляются некоторые основные возможности RMAN, недостижимые с помощью традиционных методов резервного копирования или имеющие существенные ограничения, если для них используются традиционные методы:
Пропуск неиспользуемых (пустых) блоков При копировании с помощью RMAN не копируются блоки, в которые никогда не осуществлялась запись данных, например блоки таблицы, расположенные выше маркера максимального заполнения (High water mark — HWM), если резервная копия является резервным набором RMAN. При использовании традиционных методов резервного копирования не существует методов для определения того, какие блоки были использованы.
Сжатие резервной копии В добавление к пропуску никогда не использовавшихся блоков RMAN может также использовать специфический режим двоичного сжатия для экономии места на устройстве записи резервной копии. Хотя методики сжатия, применяющие особенности конкретных операционных систем, являются доступными при традиционных методах копирования, используемый RMAN алгоритм сжатия настроен именно для максимизации сжатия для типичных видов данных, которые можно обнаружить в блоках данных Oracle. Несмотря на то, что при применении компрессированного копирования RMAN наблюдается небольшое увеличение времени использования ЦП, общий размер носителя, используемый для создания резервной копии, может быть существенно сокращен, равно как и требующаяся полоса пропускания, если копирование производится по сети. Для смягчения “накладных расходов”, связанных с резервным копированием, можно сконфигурировать для выполнения RMAN несколько процессоров.
504
Гпава 1$
Резервное копирование открытой базы данных Резервное ко-пирование табличных пространств может быть выполнено в RMAN без использования фразы begin/end backup в команде alter tablespace. Однако и при использовании RMAN, и при применении традиционных методов копирования база данных должна работать в режиме ARCHIVELOG.
Настоящие инкрементальные резервные копии Для любого инкрементального копирования RMAN в выходной файл не будут записаны блоки, которые не подвергались изменению после создания последней резервной копии. Это позволяет сэкономить значительный объем дискового пространства, а также время ввода/вы-вода и ЦП. Для операций выполнения полного восстановления базы данных (restore operations) и осуществления возврата базы данных из несогласованного состояния в рабочее (recovery operations) RMAN поддерживает инкрементально обновленные резервные копии. Блоки данных из инкрементальной резервной копии применяются к предыдущей резервной копии, чтобы потенциально сократить количество времени и число файлов, к которым необходимо обратиться для выполнения операции восстановления базы данных (пример с инкрементально обновляемой резервной копией см. ниже в данной главе).
Восстановление на уровне блоков Чтобы избежать возможного простоя при выполнении операций восстановления, RMAN поддерживает восстановление на уровне блоков (block-level recovery), при котором оказывается необходимо восстановить только небольшое количество блоков; про них известно, что они были повреждены во время операции копирования. Оставшаяся часть табличного пространства и объектов в нем может оставаться в оперативном режиме в то время, пока RMAN осуществляет восстановление поврежденных блоков. Строки таблицы, не затронутые действиями RMAN по восстановлению, остаются доступными для пользователей и приложений.
Несколько каналов ввода/вывода Во время выполнения one раций копирования или восстановления RMAN может для осущост вления конкурентного ввода/вывода использовать несколько капа, лов ввода/вывода (через отдельные процессы операционной системы). Традиционные же методы резервного копирования, на_ пример команда ср для Unix или команда export для Oracle, являют ся типичными однонитевыми (однопроцессными) операциями.
Независимость от платформы Записанные с помощью копии будут синтаксически идентичными вне зависимости от т какие аппаратные или софтверные платформы были использ ны для их создания. Единственным их отличием будет разли в конфигурации канала управления носителями. С другой с горой » сценарий для ОС Unix, содержащий множество команд ср, не cMj жет работать без ошибок, если перенести его на платфор У
Windows.
Использование диспетчера восстановления (RMAN)
505
Поддержка диспетчеров лент В RMAN поддерживаются все основные системы резервного копирования корпоративного уровня. Это достигается путем использования специальных драйверов для управления носителями, предоставляемыми фирмами-производителями.
Каталогизация Перечень всех резервных копий RMAN регистрируется в управляющем файле целевой базы данных и при желании в каталоге восстановления, хранящемся в отдельной базе данных. Это делает операции полного и частичного восстановления базы данных сравнительно простыми по отношению к ручному отслеживанию резервных копий па уровне операционной системы с использованием команд “сору”.
Возможности создания сценариев Сценарии RMAN могут быть сохранены в каталоге восстановления для их выборки во время выполнения копирования. Тесная интеграция языка сценариев, простота обслуживания сценариев в RMAN и средства планирования Oracle делают RMAN лучшим выбором, нежели хранение традиционных сценариев операционной системы в каталоге операционной системы в совокупности с использованием собственных механизмов планирования выполнения операционной системы.
В некоторых случаях (правда, их число ограничено) традиционные механизмы копирования могут иметь преимущества по сравнению с RMAN; так, например, RMAN не поддерживает копирование файлов паролей и других файлов, не являющихся файлами базы данных, например tnsnames.ora, listener.ora и sqlnet.ora. Однако эти файлы довольно статичны по своей природе, и они могут с легкостью быть скопированы (а затем и восстановлены) с помощью традиционных методов копирования, например с помощью команды Unix ср.
Типы резервных копий
В зависимости от требующейся доступности, желаемого размера исполь-зуемого для плановых работ технологического окна и максимально допустимого времени простоя, в течение которого база данных будет участвовать в операциях по восстановлению, RMAN поддерживает множество различных методов резервного копирования.
Согласованные и несогласованные резервные копии
Физические резервные копии могут быть классифицированы как согласо-ванные или несогласованные. В согласованной резервной копии у всех файлов данных есть один и тот же SCN; другими словами, все изменения в файлах журналов базы данных были применены к файлам данных. Поскольку в открытой базе данных, где отсутствуют незафиксированные транзакции, в буферном кэше могут быть так называемые грязные блоки (dirty blocks), ситуация, в которой открытая база данных может считаться согласованной, встречается достаточно редко. В результате согласованные резервные копии могут быть получены только тогда, когда база данных либо нормально остановлена, либо находится в состоянии MOUNT.
506
Гпава 1$
Несогласованная резервная копия выполняется, когда база данных открыта и пользователи могут к ней обращаться. Как правило, при выполнении несогласованной резервной копии, SCN различных файлов данных не соответствуют друг другу. Поэтому выполняемая с использованием несогласованной резервной копии операция восстановления базы данных должна опираться как на архивные, так и на оперативные журнальные файлы, чтобы привести восстановленную базу данных в непротиворечивое (согласованное) состояние перед тем, как она будет открыта. В итоге база данных должна работать в режиме ARCHIVELOG, если нужно использовать метод несогласованного резервного копирования.
Полные и инкрементальные резервные копии
Полные копии включают в себя все блоки всех файлов данных в составе табличного пространства или базы данных; по сути это побитовая копия одного или нескольких файлов данных базы данных. Для создания полной резервной копии может быть использована либо команда RMAN, либо команда операционной системы, хотя резервные копии, созданные без применения RMAN, должны быть каталогизированы в RMAN, прежде чем их можно будет использовать для операций восстановления RMAN.
В Oracle 10g инкрементальные резервные копии могут быть уровня О или 1. Резервная копия уровня 0 — это полная резервная копия всех блоков базы данных, которая может быть использована в соединении с дифференциальными, инкрементальными или кумулятивными инкрементальными резервными копиями уровня 1 в операции частичного восстановления базы данных. Заметным преимуществом использования инкрементальных резервных копий в стратегии восстановления является тот факт, что для восстановления базы данных или табличного пространства до согласованного состояния могут не понадобиться архивные и оперативные журналы; в инкрементальных копиях могут оказаться некоторые или даже все требующиеся блоки (пример использования инкре ментальных резервных копий уровней 0 и 1 см. ниже в данной главе). Ин крементальные копии могут быть созданы только с помощью RMAN.
Копии-отображения
Копии-отображения (image copies) являются полными копиями, с0??^ ными с помощью команд операционной системы или команды к backup сору. Хотя полная резервная копия, созданная с помощью ко ды Unix ср, может быть впоследствии зарегистрирована в кат RMAN как резервная копия базы данных, если такую копию-отображе^ сделать с помощью RMAN, у нее будет заметное преимущество, связа с проверкой на наличие поврежденных блоков по мере того, как ° таются RMAN, и записи информации о плохих блоках в словарь Копии-отображения являются используемым по умолчанию в RMAi матом.
Это прекрасная особенность Oracle 10g и вот по какой причине. к табличному пространству добавляется еще один файл данных, то ну , не забыть добавить этот новый файл в Unix-сцепарий, в котором Ис зуются команды ср. При создании копий-отображений с поМ^ . рал ant r пе.чеовттую копию будут автоматически включены все
Использование диспетчера восстановления (RMAN)
507
данных. Если не добавить в сценарий Unix новый файл данных, это может сделать ситуацию при восстановлении, в лучшем случае, неудобной, а в худшем случае — катастрофичной.
Резервные наборы и фрагменты резервных копий
В отличие от копий-отображений, которые могут быть созданы практически во всех средах резервного копирования, резервные наборы могут быть созданы только с помощью RMAN (соответственно и восстановление посредством этих наборов может быть выполнено только средствами RMAN). Резервный набор (backupset) — это сделанная средствами RMAN резервная копия всей базы данных или какой-то ее части, состоящая из одного или нескольких фрагментов резервных копий (backup pieces). Каждый такой фрагмент может принадлежать только одному резервному набору и содержать резервные копии одного или нескольких файлов данных базы данных. Все фрагменты и резервные наборы регистрируются в репозитории RMAN точно так же, как и многие другие инициированные RMAN резервные копии.
Компрессированные резервные копии
Для любой резервной копии RMAN Oracle 10g, создающей резервный набор, возможно компрессирование с целью уменьшения размера дискового или ленточного пространства, требующегося для хранения резервной копии. Использовать компрессированные резервные копии можно только в среде RMAN. При использовании таких копий для восстановления базы данных не требуется никакой специальной обработки; RMAN автоматически декомпрессирует резервную копию. Для создания компрессированной копии достаточно указать в команде backup фразу as compressed backupset.
Обзор команд и опций КГ/Ш
Ниже рассматривается базовый набор команд, которые используются регулярно, и показывается, как можно сделать работу с ними еще проще, если зафиксировать (сделать постоянными) некоторые установки сеанса RMAN; кроме того, будут созданы стратегия сохранения и репозиторий, который будет использоваться для хранения метаданных RMAN.
В конце этого раздела рассматриваются параметры инициализации, связанные с резервными копиями RMAN и облас гью flash-восстановления.
Часто используемые команды
В таблице 13.1 представлен перечень наиболее часто употребляемых команд RMAN, регулярно используемых вместе с часто используемыми оп-ЦИями и “подводными камнями” для каждой такой команды. Полный список всех команд RMAN с их синтаксисом можно найти в документе Oracle Database Recovery Manager Reference, 10gRelease 1 (“Справочное руководство по диспетчеру восстановления для баз данных Oracle версии 10<г релиз 1”). г 6
508
Гпава
Таблица 13.1. Часто встречающиеся команды RMAN
Команда RMAN
BACKUP
CHANGE
CONFIGURE
CREATE CATALOG
CROSSCHECK
DELETE
FLASHBACK
LIST
RECOVER
Описание____________________________________________
Запускает командный файл RMAN по путевому имени, специфицированному после Если путь не будет указан, то предполагается, что будет выполнен командный файл из того же каталога, из которого был вызван RMAN.
Выполняет резервное копирование RMAN с архивными журналами или без них. Копирует файлы данных, их копии или выполняет инкрементальные копии уровней 0 или 1. Копирует всю базу данных или отдельное табличное пространство, или файл данных. С помощью фразы VALIDATE выполняет проверку достоверности подлежащих копированию блоков.
Изменяет статус резервной копии в репозитории RMAN. Полезна для явного исключения резервной копии из операции частичного либо полного восстановления базы данных или для уведомления RMAN о том, что резервная копия была непреднамеренно или целенаправленно удалена командой операционной системы за пределами RMAN.
Конфигурирует постоянные настройки RMAN. Сконфигурированные параметры будут доступны во всех последующих сеансах RMAN до тех пор, пока их не изменят явно или не сбросят.
Создает каталог репозитория, содержащий метаданные RMAN для одной или нескольких целевых баз данных. Настоятельно рекомендуется не хранить этот каталог в одной из целевых баз данных. Проверяет регистрацию резервных копий в репозитории RMAN, сравнивая ее с фактическим наличием зарегистрированных в репозитории файлов на дисках или на ленте. Проверяемые объекты помечаются флажками EXPIRED, AVAILABLE, UNAVAILABLE или OBSOLETE. Если проверяемый объект недоступен для RMAN, он помечается как UNAVAILABLE.
Удаляет резервные и обычные копии; удаляет из каталога восстановления ссылки на них и изменяет записи о них в управляющих файлах целевой базы данных на статус DELETED.
Выполняет операцию Flashback Database, впервые появившуюся в Oracle 10^. База данных восстанавливается по состоянию на мо мент времени в прошлом по SCN или по порядковому номеру журнального файла (log sequence number) с использованием журналов flashback для отката изменений до SON или порядке го номера журнального файла, а затем применяются архивны журналы для прокрутки базы данных вперед до согласованно состояния.
Выводит подробную информацию о резервных наборах и к0П^ отображениях, зарегистрированных в управляющем файле ц вой базы данных или в репозитории (см. описание команды REPORT).
Выполняет полное/неполное восстановление файла данных, личного пространства или всей базы данных. Может также пр менять инкрементальные резервные копии к копиям-отобра# ниям файлов данных для их накатки вперед по времени.
Использование диспетчера восстановления (RMAN)
509
Таблица 13.1 (Продолжение)
Команда RMAN Описание
REGISTER DATABASE Регистрирует целевую базу данных в репозитории RMAN.
REPORT Осуществляет подробный анализ репозитория RMAN. Например, с помощью этой команды можно идентифицировать файлы, нуждающиеся в резервном копировании для соблюдения принятой стратегии сохранения, или файлы с резервными копиями, которые могут быть удалены.
RESTORE Восстанавливает файлы из копий-отображений или из резервных наборов на диск обычно после отказа носителя. Может быть использована для проверки возможности выполнения операции восстановления без фактического выполнения самой операции (если указана опция PREVIEW).
RUN Выполняет последовательность команд RMAN, которые указываются в команде run в скобках ([ и ]). Позволяет перекрывать используемые по умолчанию параметры RMAN (на время выполнения группы).
SET Задает настройки конфигурации RMAN на уровне сеанса, например выделенные дисковые или ленточные каналы. Постоянные настройки назначаются с помощью команды CONFIGURE.
SHOW Выводит на экран все или индивидуальные настройки, сконфигурированные для RMAN.
SHUTDOWN Останавливает целевую базу данных непосредственно из среды RMAN. Эквивалентна команде SHUTDOWN в SQL*Plus.
STARTUP Запускает целевую базу данных непосредственно из среды RMAN. Эквивалентна команде STARTUP в SQL*Plus.
SQL Выполняет команды SQL, которые не могут быть выполнены прямо или косвенно с использованием стандартных команд RMAN; например, перед выполнением восстановления табличного пространства USERS можно выполнить команду sql ‘alter tablespace users offline immediate’;.
Если при резервном копировании используется Flash Recovery Area, можно сделать резервную копию базы данных без какого-либо другого явного конфигурирования RMAN. Для этого достаточно выполнить следующую команду:
О RMAN> backup database;
Настройка репозитория
Неважно, используется ли репозиторий для хранения метаданных об од-ной базе данных или о нескольких сотнях баз данных, настройка репозитория является достаточно простым делом и должна быть выполнена всего один раз. В следующих примерах предполагается, что мы имеем дело с инсталляцией по умолчанию базы данных Oracle 10g; база данных репозитория можег бьиь использована для выполнения других приложений, если для них не будет о гмечен сильный спад производительности в те моменты, когда RMAN бывает необходимо обновить метаданные репозитория.
510
Гпава 1з
Предупреждение Использование в качестве репозитория целевой базы данных RMAN крайне нежелательно. Потеря целевой базы данных сводит к нулю всякие шансы на успешное восстановление базы данных с помощью RMAN, так как вместе с целевой базой данных будут утеряны все метаданные репозитория.
Показанная ниже последовательность команд создает табличное пространство и пользователя для обслуживания метаданных в базе данных репозитория. В этом и во всех последующих примерах для всех операций с репозиторием используется база данных с SID rmanrep.
П SQL> create tablespace rman
2 datafile ‘/u01/app/oracle/oradata/rmanrep/rman01.dbf’
3 size 10m autoextend on next 5m;
Tablespace created.
SQL> create user rman identified by rmanOOl
2 default tablespace rman;
User created.
SQL> grant resources, connect, recovery_catalog_owner to rman;
Grant succeeded. _
Теперь, когда в базе данных репозитория существует учетная запись пользователя RMAN, можно запустить RMAN, подключиться к каталогу и инициализировать репозиторий с помощью команды create catalog:
□ [oracle@oltp oracle]$ rman catalog rman/rman001@rmanrep
Recovery Manager: Release 10.1.0.2.0 - Production
Copyright (c) 1995, 2004, Oracle. All rights reserved.
I
connected to recovery catalog database recovery catalog is not installed
RMAN> create catalog;
recovery catalog created
RMAN>
Начиная с этого момента, использование репозитория становится совсем простым делом: для этого достаточно указать в командной строке RMAN имя пользователя репозитория и его пароль с параметром catalog или использовать во время сеанса RMAN команду connect catalog. В среде Oracle Enterprise Manager верительные данные для репозитория могут быть постоянными (см. рис. 13.2).
В последующих сеансах OEM в любой операции резервного копирова ния или восстановления RMAN будет автоматически использован ката лог восстановления.
Регистрация базы данных
Каждую базу данных, для которой RMAN будет выполнять резервное ко пирование или восстановление, нужно зарегистрировать в репозиторий RMAN; при этой операции записывается такая информация, как, напри
Использование диспетчера восстановления (RMAN)
511
Рис. 13.2. Постоянные верительные данные репозитория RMAN
мер схема целевой базы данных и уникальный идентификатор базы данных (DBID) для целевой базы данных. Целевая база данных должна быть зарегистрирована всего один раз; все последующие сеансы RMAN, которые подключаются к целевой базе данных, будут автоматически ссылаться на правильные метаданные в репозитории.
О [oracle@oltp oracle]$ rman target/catalog rman@rmanrep
Recovery Manager: Release 10.1.0.2.0 - Production
Copyright (c) 1995, 2004 Oracle. All rights reserved.
connected to target database: ORD (DBID=1387044942) recovery catalog database Password: xxxxxxxxx connected to recovery catalog database
RMAN> register database;
database registered in recovery catalog starting ull resync of recovery catalog Full resync complete
RMAN>
512
Гпава 1з
В предыдущем примере осуществлялось подключение к целевой базе данных с помощью аутентификации операционной системы, а при подключении к репозиторию использовалась аутентификация паролем. Все базы данных, зарегистрированные в репозитории, должны иметь уци, кальные DBID; попытка повторной регистрации базы данных приведет к следующему сообщению об ошибке:
□ RMAN> register database;
RMAN-00571: ======================================================
RMAN-00569: ================ ERROR MESSAGE STACK FOLLOWS =========
RMAN-00571: ======================================================
RMAN-03009: failure or register command on default channel at 03/15/2004 20:58:56
RMAN-20002: target database already registered in recovery catalog
RMAN>
Регистрация базы данных с помощью OEM столь же проста (см. рис. 13.3).
Сохранение настроек RMAN
Чтобы облегчить работу АБД, можно сделать многие настройки RMAN постоянными (persistent). Другими словами, эти установки смогут сохранять свои значения и в промежутках между сеансами RMAN. В следующем
Рис. 13.3. Регистрация базы данных с помощью OEM
Использование диспетчера
восстановления (RMAN)
513
примере используется команда show для показа применяемых по умолчанию установок RMAN:
О RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; it default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK, # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; it default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
1/u01/app/oracle/product/10.1.0/dbs/snapcf_ord.f’; # default
RMAN>
Любые параметры, значения которых установлены равными их значениям по умолчанию, отмечены здесь как # default. Эти параметры можно легко пересмотреть и исправить их с помощью OEM (см. рис. 13.4).
Рис. 13.4. Постоянные параметры RMAN в OEM
514
Гпава 1з
Стратегия сохранения
Резервные копии могут автоматически сохраняться, и ими можно управлять, используя для этой цели один из двух методов: по допустимому интер. валу восстановления (recovery window) или по избыточности (redundancy). Если используется допустимый интервал восстановления, RMAN будет сохранять столько резервных копий, сколько их может потребоваться для восстановления базы данных по состоянию на любой момент времени, попадающий в интервал допустимого восстановления. Например, если допустимый интервал восстановления равен семи суткам, RMAN будет хранить достаточное количество копий-отображений, инкрементальных копий и архивных журналов, чтобы быть уверенными в том, что с их помощью можно будет провести восстановление базы данных по состоянию на любой момент времени за последние семь дней. Любые резервные копии, не требующиеся для поддержки этого интервала восстановления, будут помечены как OBSOLETE и будут автоматически удалены RMAN, если используется Flash Recovery Area и дисковое пространство потребовалось для записи новых резервных копий.
Напротив, стратегия удержания по избыточности указывает RMAN, что необходимо удерживать конкретное заданное количество резервных копий каждого файла данных и каждого управляющего файла. Дополнительные резервные копии, превышающие по количеству заданное в стратегии удерживания число копий, помечаются как OBSOLETE (устаревшие) и, как и в случае с допустимым интервалом восстановления, будут автоматически удалены RMAN, если используется Flash Recovery Area и дисковое пространство потребовалось для записи новых резервных копий. В противном случае можно использовать команду delete obsolete для удаления файлов резервных копий и обновления каталога.
Если стратегия сохранения установлена на NONE, резервные копии никогда не становятся устаревшими и АБД придется удалять ставшие ненужными файлы резервных копий из каталога и с диска вручную.
В следующем примере задается стратегия сохранения, в которой допустимый интервал восстановления равен четырем дням:
□ RMAN> configure retention policy to recovery window of 4 days;
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;
new RMAN configuration parameters are successfully stored starting full resync of recovery catalog
full resync complete
RMAN>
Тип устройства
Если в качестве типа устройства по умолчанию применяется DISK и t указан параметр пул и к устройству, RMAN использует для хранения пС , резервных копий Flash Recovery Area. Как и при решении многих Др^ упрощений административных задач в Oracle Database 10g, нет необхоД мости выделять или освобождать для резервных копий конкретный
Использование диспетчера восстановления
(RMAN)
515
нал, если только не используется ленточное устройство или не нужно переслать резервную копию на диске в какое-то другое место за пределами Flash Recovery Area.
Хотя конфигурирование ленточного устройства зависит от инсталляции, оно выглядит примерно следующим образом:
□ RMAN> configure channel device type sbt
2> parms=’ЕМУ1В0ММЕМТ=(<специфицированные_производителем_аргументы>)’;
Примечание sbt — это тип устройства, используемого для любой ленточной системы резервного копирования, безотносительно к ее производителю.
Хотя можно использовать Flash Recovery Area для частичного и полного восстановления с диска базы данных, в какой-то момент становится неэффективно хранить все резервные копии на диске, особенно когда задан большой допустимый интервал восстановления. Поэтому можно сделать копии файлов с резервными копиями на лентах, a RMAN будет исполнительно отслеживать, где именно находятся резервные копии, если придется полностью или частично восстанавливать базу данных с ленты или восстанавливать архивные журналы для наката (roll forward) копии-отображения во Flash Recovery Area.
Автоматическое резервное копирование управляющих файлов
Вследствие особой важности управляющих файлов для базы данных, нужно делать их резервные копии, по крайней мере, также часто, насколько часто они изменяются при модификации структуры базы данных. Можно сконфигурировать RMAN таким образом, чтобы он автоматически копировал управляющие файлы либо всякий раз, когда в репозитории должно быть зафиксировано успешное резервное копирование либо когда структурное изменение влияет на содержимое управляющего файла. Другими словами, случаи, когда необходимо выполнить резервное копирование управляющего файла, чтобы гарантировать успешное восстановление, имеют место, когда/если требуется операция восстановления.
□ RMAN> configure controlfile autobackup on;
new RMAN configuration parameters are successfully stored
CONFIGURE CONTROLFILE AUTOBACKUP ON;
starting full resync of recovery catalog full resync complete
RMAN>
<
Начиная с этого момента, в каждую сделанную RMAN резервную копию будет автоматически включена копия управляющего файла.
Компрессирование резервной копии
Если дисковое пространство начинает пользоваться очень высоким спросом и в запасе есть некоторые дополнительные вычислительные мощности, имеет смысл для экономии дисковой памяти компрессировать ре
516
Гпава 1з
зервные копии. Файлы будут автоматически декомпрессированы в0 время выполнения операции частичного или полного восстановления.
□ RMAN> configure device type disk backup type to compressed backupset;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO
COMPRESSED BACKUPSET PARALLELISM 1;
new RMAN configuration parameters are successfully stored starting full resync of recovery catalog full resync complete
RMAN>
Компрессирование резервных наборов может оказаться необязательным, если для файловых систем операционной системы разрешено компрессирование или если аппаратные средства ленточного устройства автоматически выполняют компрессирование резервных копий; однако алгоритм компрессирования RMAN настроен для эффективного резервного копирования блоков данных Oracle, и в результате, может оказаться более удобным компрессировать резервные наборы.
Параметры инициализации
Для контроля над резервными копиями RMAN используется ряд параметров инициализации.
CONTROL_FILE_RECORD_KEEP_TIIVIE
Перечень всех резервных копий RMAN хранится в целевом управляющем файле. Этот параметр специфицирует количество дней, в течение которых RMAN будет пытаться сохранить записи о резервных копиях в целевом управляющем файле. По прошествии заданного времени RMAN начинает повторно использовать записи, более старые, чем период удержания. Если RMAN требуется записать новую запись с резервной копией, а период сохранения еще не был достигнут, RMAN будет пытаться расширить управляющий файл. Обычно такая попытка оказывается успешной, потому что размер управляющего файла относительно мал по сравнению с остальными объектами базы данных. Однако, если не удает ся найти места для расширения управляющего файла, RMAN начнет ис пользовать самые старые записи в управляющем файле и запишет сооо щение об этом в журнальный файл оповещений.
Существует эмпирическое правило, согласно которому можно уста вить параметр CONTROL JFILEJRECORD_KEEP_TIME на несколь^ дней большим, чем фактически требующийся допустимый интервал становления, чтобы быть уверенными в том, что записи о резервных пиях будут сохранены в управляющем файле.
DB_RECOVERY_FILE_DEST
Этот параметр специфицирует место размещения Flash Recovery Ахе Она должна быть размещена не в той файловой системе, где хранят файлы данных, управляющие файлы или файлы журналов базы — опера
Использование диспетчера восстановления (RMAN)
517
тивные и архивные. Если диск с файлами данных потерян, Flash Recovery Area тоже уходит в небытие, что уменьшает преимущества использования Flash Recovery Area.
DB_RECOVERY_FlLE_DEST_SIZE
Этот параметр специфицирует верхний предел дискового пространства, используемого для Flash Recovery Area. В базовой файловой системе может быть больше или меньше требующегося объема памяти; АБД должен быть уверен, что есть, по крайней мере, количество памяти, необходимое для размещения резервных копий...
В базе данных для ввода заказов (ord) область Flash Recovery Area определена в каталоге /OraFlash и имеет максимальный размер 15 Гбайт. Когда этот максимальный размер каталога будет достигнут, RMAN начнет автоматически удалять устаревшие резервные копии и генерировать уведомления в журнале уведомлений, когда количество места, занимаемого не устаревшими резервными копиями, станет отличаться от указанного в DB_RECOVERY_FILE_DEST_SIZE меньше, чем на 10%.
Параметры DB_RECOVERY_FILE_DEST и DB_RECOVERY_FILE_ DESTJSIZE являются динамическими; они могут быть изменены непосредственно в процессе работы экземпляра, чтобы реагировать на изменения в доступности дискового пространства.
Представления словаря данных
и динамические представления производительности
Ряд представлений словаря данных Oracle и динамических представлений производительности содержит конкретную информацию для операций RMAN над целевой базой данных и базой данных каталога восстановления. В таблице 13.2 перечисляются ключевые представления, относящиеся к RMAN (подробнее об этих представлениях см. ниже в данной главе).
Представления RC_* существуют только в базе данных, используемой в качестве репозитория RMAN; представления V$ существуют и содержат строки в любой базе данных, которая копируется с помощью RMAN. Чтобы подчеркнуть эту разницу, рассмотрим представление V$RMAN_ CONFIGURATION в целевой базе данных:
Cl SQL> connect system/manager@ord
Connected.
SQL> select * from v$rman_configuration;
CONF# NAME VALUE
1 CONTROLFILE AUTOBACKUP
2 RETENTION POLICY
3 DEVICE TYPE
4 BACKUP OPTIMIZATION
ON
TO RECOVERY WINDOW OF 4 DAYS DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1
ON
4 rows selected.
518
Гпава 13
Таблица 13.2. Представления словаря данных и динамические представления производительности RMAN
Представление Описание
RC_*
V$RMAN_STATUS
V$RMAN_OUTPUT
V$SESSION_LONGOPS
V$DATABASE_BLOCK CORRUPTION
V$RECOVERY_FILE_DEST
V$RMAN_CONFIGURATION
Представления каталога восстановления RMAN. Существуют только в базе данных репозитория RMAN и содержат информацию для восстановления всех целевых баз данных.
.Выводит информацию о завершившихся и работающих заданиях RMAN.
Содержит сгенерированные сеансами RMAN сообщения и каждую команду RMAN, выполненную в этих сеансах.
Содержит статус всех выполняющихся длительное время административных операций, которые продолжаются более шести секунд; представление включает в себя сбор статистических показателей и долго выполняющиеся запросы, а также операции восстановления и резервного копирования RMAN.
Поврежденные блоки, обнаруженные во время сеанса RMAN.
Количество файлов, использованное пространство, пространство, которое может быть возвращено обратно (высвобождено), и предельный размер Flash Recovery Area.
Параметры конфигурирования RMAN для отличающихся от значений, используемых по умолчанию в базе данных.
Все эти параметры являются теми четырьмя постоянными параметрами RMAN, которые были изменены ранее. База данных каталога восстановления сохраняет эти не совпадающие со значениями по умолчанию значения в представлении RC^RMAN_CONFIGURATION для всех баз данных, зарегистрированных в RMAN:
□ SQL> connect rman/rman001@rmanrep
Connected.
SQL> select db_key, db_unique_name, name, value
2 from rman.rc_man_configuration;
DB.KEY DBJJNIQUE_NAME NAME VALUE
1 ord
1
1 ord
1 ord
CONTROLFILE AUTOBACKUP ON .yS
RETENTION POLICY TO RECOVERY WINDOW OF
DEVICE TYPE DISK BACKUP FILE TO
COMPRESSED BACKUPSET
PARALLELISM 1
BACKUP OPTIMIZATION ON
л rnuic qp"! pe.tpfj
Использование диспетчера восстановления (RMAN)
519
Если для копирования другой базы данных используется RMAN, в этом представлении будут содержаться другие значения параметров DB_KEY и DB_UNIQUE_NAME для других целевых баз данных с отличными от используемых по умолчанию значениями параметров RMAN.
Поскольку RMAN не используется для создания резервных копий базы данных rmanrep, представления V$RMAN_* будут пустыми.
Операции резервного копирования
В этом разделе рассматриваются несколько примеров резервного копирования целевой базы данных различными способами. Будут выполнены два полных резервных копирования, созданы копии-отображения выбранных файлов базы данных, исследован вопрос о том, как работает инкрементальное копирование, и будут осуществлены компрессирование резервных копий, оптимизация инкрементального копирования и исследование Flash Recovery Area.
В качестве целевой базы данных будет по-прежнему использоваться база данных ввода заказов ord, а в качестве репозитория RMAN — база данных rmanrep.
Полное резервное копирование базы данных
В первом примере полного резервного копирования базы данных будут использоваться резервные наборы для копирования в область Flash Recovery Area всех файлов базы данных, включая SPFILE,:
П RMAN> backup as backupset database spfile;
Starting backup at 15-Mar-04
allocated channel: ORACLE DISK_1
channel ORA_DISK_1: sid=235 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u05/oradata/ord/system01.dbf
input datafile fno=00003 name=/u05/oradata/ord/sysaux01.dbf
input datafile fno=00005 name=/u05/oradata/ord/example01.dbf
input datafile fno=00002 name=/u05/oradata/ord/undotbs01.dbf
input datafile fno=00004 name=/u05/oradata/ord/users01.dbf
channel ORA_DISK_1: starting piece 1 at 15-Mar-04
channel ORA_DISK_1: finished piece 1 at 15-Mar-04
Piece handle=/0raFlash/0RD/backupset/2003 03_15/
0l_mf_nnndf_TAG20040315T221256_05dzp9nz_.bkp comment=NONE
channel ORAJISK_1: backup set complete, elapsed time : 00:03:44
channel 0RA_DISK_1: starting full datafile backupset
channel 0RA_DISK_1: specifying datafile(s) in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 15-Mar-04
channel 0RA_DISK_1: finished piece 1 at 15-Mar-04
Piece handle=/0raFlash/0RD/backupset/2004_03_15/
0l_mf_nnsnf_TAG20040315T221256_05dzxg62bkp comment=N0NE
channel 0RA_DISK_1: backup set complete, elapsed time : 00’00:02 Finished backup at 15-MAR-04
520
Гпава 13
Starting Control File and SPFILE Autobackup at 15-MAR-04 piece handle=/0raFlash/0RD/autobackup/2004_03_15/
01_mf_s_520899415_05dzxsnn_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 15-MAR-04
RMAN> sql ‘alter system archive log current’;
sql statement: alter system archive log current RMAN>
A
Команда alter system служит гарантией того, что у нас будут иметься архивные журналы для всех транзакций, включая и те, которые произошли во время выполнения резервного копирования; это становится гарантией того, что после выполнения этого резервного копирования можно провести восстановление вышедшего из строя носителя.
SPFILE копируется дважды, причем во второй раз — вместе с управляющим файлом. Поскольку configure controlfile autobackup установлена на on, управляющий файл и SPFILE автоматически копируются всякий раз, когда делается любая другая резервная копия или когда происходит изменение структуры базы данных. В результате не требуется явно специфицировать SPFILE в команде backup.
В Flash Recovery Area можно увидеть целый ряд загадочных имен файлов для текущих архивированных журналов и только что сделанной резервной копии всей базы данных:
□ SQL> connect system/manager@ord
Connected.
SQL> show parameter db_recovery_file_dest
NAME TYPE VALUE
db_recovery_file_dest
db_recovery_file_dest_size
string /OraFlash
big integer 15728640000
SQL> select name from v$database;
NAME
ORD
1 row selected.
SQL> exit
[acle@oltp bdump]# cd /OraFlash/ORD
[oracle@oltp ORD]# Is
archivelog autobackup backupset
[oracle@oltp ORD]# find . -print
/archivelog
/archivelog/2004_03_14
/archivelog/2004_03_14/o1_mf_1_180_059dscwh_.arc
/archivelog/2004_03_14/o1_mf_1_181_059dshjx_.arc
/archivelog/2004_03_14/o1_mf_1_182_059ntxyc_.arc
/archivelog/2004_03_14/o1_mf_1_188_05b7kx3j_.arc
521
г
Использование диспетчера восстановления (RMAN)
./archivelog/2004_03_14/o1_mf_1_189_05bfflq9_.arc . /archivelog/2004_03_15
./archivelog/2004 03_15/o1 _mf_1_190_05bkt6rf_. arc ./archivelog/2004_03_15/o1_mf_1_191_05br7onw_.arc ./archivelog/2004_03_15/o1_mf_1_192_05bwyd93_.arc ./archivelog/2004_03_15/o1_mf_1_193_05c2sssw_.arc
. /archivelog/2004_03_15/o1_mf_1_207_05f1nktm_.arc
. /archivelog/2004_03_15/o1_mf_1_208_05f5wk22_.arc
./archivelog/2004_03_16
./archivelog/2004_03_16/o1_mf_1_209_05f60x1h_.arc
./archivelog/2004_03_16/o1_mf_1_210_05f62opo_.arc
./archivelog/2004_03_16/o1_mf_1_216_05fvwyrb_.arc
./archivelog/2004_03_16/o1_mf_1_217_05g0h4o1_.arc ./backupset
./backupset/2004_03_15
./backupset/2004_03_15/o1_mf_nnndf_TAG20040315T221256_05dzp9nz_.bkp
./backupset/2004_03__15/o1_mf_nnndf_TAG20040315T221256_05dzxg62_.bkp
./autobackup
./autobackup/2004_03_15
. /autobackup/2004_03_15/o1_mf_s_520899415_05dzxsnn_. bkp [oracle@oltp ORD]#
Используя команду RMAN list, мы увидим эти резервные копии в том виде, как они были каталогизированы в управляющем файле целевой базы данных и в репозитории RMAN. Есть три резервных набора: один, содержащий сами файлы данных, один для явной копии SPFILE и еще один для неявной резервной копии управляющего файла и SPFILE.
□ RMAN> list backup by backup;
List of Backup Sets
BS Key Type LV Size Device Type Elapsed Time Completion Time
558 Full 610M DISK 00:03:35 15-MAR-04
BP Key: 561 Status: AVAILABLE Compressed: NO Tag:
TAG20040315T221256
Piece Name: /0raFlash/0RD/backupset/2004_03_15/
o1_mf_nnndf_TAG20040315T221256_05dzp9nz_bkp
List of Datafiles in backup set 558
File LV Type Ckp SCN Ckp Time Name
1 Full 1061186 15-MAR-04 /u05/oradata/ord/system01. dbf
2 Full 1061186 15-MAR-04 /u05/oradata/ord/undotbs01. dbf
3 Full 1061186 15-MAR-04 /u05/oradata/ord/sysaux01.dbf
4 r- Full 1061186 15-MAR-04 /u05/oradata/ord/users01.dbf
5 Full 1061186 15-MAR-04 /u05/oradata/ord/example01.dbf
BS Key Type LV Size Device Type
559 Full 0 DISK
Elapsed Time Completion Time
00:00:02 15-MAR-04
522
Гпава 1з
BP Key: 562 Status: AVAILABLE Compressed: NO Tag:
TAG20040315T221256
Piece Name: /0raFlash/0RD/backupset/2004 03,15/ o1_mf_nnsnf TAG20040315T221256_05dzxg62_bkp
SPFILE included: Modification time: 14-MAR-04
BS Key Type LV Size Device Time Elapsed Time Completion Time
560 Full 2M DISK 00:00:03 15-MAR-04
BP Key: 563 Status: AVAILABLE Compressed: NO Tag:
TAG20040315T221655
Piece Name: /0raFlash/0RD/autobackup/2004_03_15/ o1_mf_s_520899415_05dzxsnn_bkp
Controlfile included: Ckp SCN: 1061328 Ckp Time: 15-MAR-04
SPFILE included: Modification time: 14-MAR-04
RMAN>
Эта полная резервная копия может быть использована в сочетании с архивными журналами (хранящимися по умолчанию в каталоге /OraFlash) для восстановления базы данных по состоянию на любой момент времени вплоть до последней зафиксированной транзакции.
На рис. 13.5 демонстрируется, как сконфигурировать ту же самую резервную копию с помощью OEM.
Г
Г —. -г Я С ’
ЭSrifarriuleReview Mfcvinaff hiler^fst fxpbret
k, Search
Fnwrpfise Manager 10#
Fite Edit View FavcrJtes Toe's Help
Review
Schedule Backup: Review
3t#P 4 о? •*
EdiRMAN Script) Back
Database
Backup Strategy Object Type Recovery Catalog Username Recovery Catalog Database
Backup Type Backup Mode
. Cancel)
<ш|. world Customized Whole Database nnan
titil:1f)21:rtHanre|> Full Backup Online Backup
>etung
Flash Recovery Area
OraFlash
< Back
4 # 4 Submit Jeb
Database |
Copyright © 19S6.2004. Oracle. All rrylis reserved
ль-
Рис. 13.5. Конфигурирование задания на резервирование с помощью OEM
Использование диспетчера восстановления (RMAN)
523
Рис. 13.6. Вывод информации о резервном наборе с помощью OEM
Вывод содержимого каталога в OEM столь же легок. На рис. 13.6 показаны результаты, эквивалентные команде list backup by backup.
Табличное пространство
После добавления в состав базы данных табличного пространства выполнение немедленного резервного копирования этого табличного пространства сократит время, которое в последующем потребуется для его восстановления при выходе из строя носителя. Можно скопировать отдельное табличное пространство базы данных, которая слишком велика для того, чтобы ее можно было сразу же скопировать целиком. Создание резервного набора или копии-отображения для табличного пространства через частые промежутки времени приведет к сокращению количества журналов базы данных, которые было бы нужно применить к более старой резервной копии табличного пространства в случае выхода из строя носителя. Так, например, в среде, состоящей из трех табличных пространств — USERS, USERS2 и USERS3 — вместе с присутствующими по умолчанию табличными пространствами SYSTEM и SYSAUX, можно делать резервную копию табличных пространств SYSTEM и SYSAUX по воскресеньям, табличного пространства USERS — по понедельникам, USERS2 — по средам, a USERS3 — по пятницам. При выходе из строя любого носителя, содержащего файлы данных из одного из этих табличных пространств, для восстановления будет использоваться пезеппнаа тггчтттхст
524
Г.пава 1з
табличного пространства, имеющая давность, не превышающую одной недели, и промежуточные архивные и оперативные журналы база данных.
В следующем примере к нашей базе данных ord добавляется табличное пространство для поддержки ввода заказов:
□ 8QL> create tablespace oe_trans
2 datafile 1/u09/oradata/ord/oe_trans01.dbf’
3 size 10m autoextend on next 5m;
Tablespace created.
Из сеанса RMAN резервируется табличное пространство (т. е. создает' ся его резервная копия) вместе с управляющим файлом, так как в нем содержится определение нового табличного пространства.
□ RMAN> report schema
Report of database schema
File K-bytes Tablespace RB segs Datafile Name
1 460800 SYSTEM YES /u05/oradata/ord/system01. dbf
2 256000 UN00TBS1 YES /u05/oradata/ord/undotbs01.dbf
3 307200 SYSAUX NO /u05/oradata/ord/sysaux01.dbf
4 5120 USERS NO /u05/oradata/ord/users01.dbf
5 153600 EXAMPLE NO /u05/oradata/ord/example01.dbf
6 10240 OE-TRANS NO /u09/oradata/ord/oe_t rans01. dbf
RMAN> backup as backupset tablespace oe. „trans;
Starting backup at 19-MAR-04
allocated channel: 0RA__DISK_1
channel 0RA_DISK_1: sid=271 devtype=DISK
channel 0RA_DISK_1: starting full datafile backupset
channel 0RA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00006 name=/u09/oradata/ord/oe_trans01.dbf
channel 0RA_DISK_1: starting piece 1 at 19-MAR-04
channel 0RA_DISK_1: finished piece 1 at 19-MAR-04 piece
handle=/0raFlash/0RD/backupset/2004_03_19/
o1_mf_nnndf_TAG200403J9T1001418_056jctm_.bkp comment=NONE
channel 0RA_DISK_1: backup set complete, elapsed time: 00:00:16
Finished backup at 19-MAR-04
Starting Control File and SPFILE Autobackup/2004_03_19/ piece
handle=/0raFlash/0RD/autobackup/2004_03_19/
o1_mf_s_521201078_05p6js8r_.bkp comment=N0NE
Finished Control File and SPFILE Autobackup at 19-MAR-04
Использование диспетчера восстановления (RMAN)
525
Рис. 13.7. Файлы резервного копирования табличного пространства в OEM
На рис. 13.7 можно видеть новые записи резервного копирования RMAN в репозитории — одну для табличного пространства (записано как резервный набор для одиночного файла данных) и одну для автоматического резервного копирования управляющего файла /SPFILE.
Файлы данных
Резервное копирование индивидуальных файлов данных представляет не больше трудностей, чем копирование табличных пространств. Если копирование всего табличного пространства оказывается непрактичным в рамках одного сеанса RMAN, можно перейти к резервному копированию индивидуальных файлов данных, входящих в состав этого табличного пространства, за определенное количество дней, а об остальном во время выполнения операции восстановления позаботятся архивные журналы базы данных.
О RMAN> backup as backupset datafile
‘/u09/oradata/ord/oe_trans01.dbf’;
Копии-отображения
До этого момента использовалось резервное копирование через резервные наборы; копии-отображения делают “побитовые” копии специфицированного табличного пространства или даже всей базы данных. Имеет
526
Глава 1$
ся несколько заметных преимуществ в использовании RMAN выполнения резервного копирования с помощью копий-отображений-во-первых, резервная копия автоматически регистрируется в репозит0 рии RMAN. Все блоки по мере того, как они читаются из целевой базы данных и копируются в резервную копию, проходят проверку на наличие повреждений. Еще одно “побочное” преимущество выполнения копий-отображений состоит в том, что эти копии могут быть использованы “как есть” вне среды RMAN, если по каким-то причинам операция восстановления должна быть проведена не средствами RMAN.
В приведенном ниже примере производится еще одно резервное копирование табличного пространства oe_trans — на этот раз как копии-отображения:
□ RMAN> backup as copy tablespace oe.trans;
Starting backup at 19-MAR-04
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile fno=00006 name=/u09/oradata/ord/oe_trans01.dbf
output filename=/0raFlash/0RD/datafile/o1_mf_oe_trans_05qn2bpz_.dbf tag=TAG20040319T230202 recid=2 stamp=521247723
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 19-MAR-04
Starting Control File and SPFILE Autobackup at 19-MAR-04
piece handle=/0raFlash/0RD/autobackup/2004_03_19/
o1. mf_s_521247724_05qn2fbj,_. bkp comment=NONE
Finished Control File and SPFILE Autobackup at 19-MAR-04
RMAN>
Копии-отображения могут быть созданы только с помощью устройств типа DISK. На рис. 13.8 показано то же самое резервное копирование с помощью OEM.
Поскольку ранее был сконфигурирован используемый по умолчанию тип устройства как compressed backupset, для этого резервного копире вания нужно “перекрыть” используемое по умолчанию значение в экране, предшествующем данному.
Резервное копирование управляющего файла и SPFILE
Для создания резервной копии управляющего файла и SPFILE вруч^У10 используются следующие команды RMAN:
П RMAN> backup current controlfile spfile;
Starting backup at 19-MAR-04
allocated channel: 0RA_DISK_1
channel 0RA_DISK_1: sid=246 devtype=DISK
channel ORA_DISK_1. starting compressed full datafile backupset
^пользование диспетчера восстановления (RMAN)
527
Рис. 13.8. Копирование табличного пространства в OEM с помощью копии-отображения
channel 0RA_DISK_1: specifying datafile(s) in backupset including current controlfile in backupset
channel 0RA_DISK_1: starting piece 1 at 19-MAR-04
channel ORA_DISK_1: finished piece 1 at 19-MAR-04 piece handle=/0raFlash/0RD/backupset/2004_03_19/
o1_mf_ncnnf_TAG20040319T213310_05gvqd7_.bkp comment=NONE channel 0RA_DISK_1: backup set complete, elapsed time: 00:00:04 channel 0RA_DISK_1: starting compressed full datafile backupset channel 0RA_DISK_1: specifying datafile(s) in backupset including current SPFILE backupset
channel 0RA_DISK_1: starting piece 1 at 19-MAR-04
channel 0RA_DISK_1: finished piece 1 at 19-MAR-04
Piece handle=/OraFlash/ORD/backupset/2004_03_19/
°1_mf_nr>snf_TAG20040319T213310 05gvx1b_. bkp comment=N0NE channel 0RA_DISK_1: backup set complete, elapsed time: 00:00:05 Finished backup at 19_MAR-04
Starting Control File and SPFILE Autobackup at 19-MAR-04 Piece handle=/0raFlash/0RD/autobackup/2004_03_19/
°l-mf_s_521242402_05qgw3g1_.bkp comment=N0NE Finished Control File and SPFILE Autobackup at 19 MAR-04
RMAN>
528
Гпава /з
Благодаря тому, что ранее autobackup был установлен на on, фактически получаются две резервные копии управляющего файла и SPFILE. Однако вторая резервная копия управляющего файла имеет ту же самую отметку о регистрации, что и первая.
Архивные журналы базы данных
Даже когда архивные журналы базы данных посылаются одновременно по нескольким адресам, включая и Flash Recovery Area, вследствие критичной природы архивных журналов базы данных нужно иметь резервные копии журналов на ленте. После того как резервное копирование журналов базы данных завершено, есть возможность выбора вариантов: оставить журналы на месте, удалить только те журналы, которые RMAN использовал для копирования или удалить все копии архивных журналов, которые были скопированы на ленту.
В приведенном ниже примере копируются все архивные журналы базы данных, находящиеся во F lash Recovery Ai ea, а затем удаляются с диска:
□ RMAN> backup device type sbt archivelog all delete input;
Если архивные журналы были посланы по нескольким адресам, будет удален только один набор архивных журналов базы данных. Если нужно удалить все копии, следует вместо фразы delete input использовать delete all input.
Резервное копирование с удалением только самых старых архивных журналов базы данных можно выполнить путем специфицирования в команде backup archivelog диапазона дат:
□ RMAN> backup device type sbt
2> archivelog from time ‘sysdate-30’ until time ‘sysdate-7’
3> delete all input;
В предыдущем примере все архивные журналы базы данных, хранящиеся от одной до трех недель, копируются на ленту, после чего удаляются с диска. Можно также специфицировать диапазон, используя SCN или порядковые номера журнальных файлов.
Инкрементальное резервное копирование
Альтернативой только что описанной стратегии, когда упор делается на полные резервные копии и архивные журналы базы данных, является ис пользование для восстановления вместе с архивными журналами данных так называемых инкрементальных резервных копий (incremen backups). Первоначальная инкрементальная резервная копия извест как инкрементальная копия уровня 0. Каждая следующая после перво чальной копии инкрементальная резервная копия (известная как ин р ментальная копия уровня 1), содержит только измененные блоки, в Р зультате для ее получения требуется меньше времени, и она заник меньше места. Инкрементальные резервные копии уровня 1 могут ь либо кумулятивными (cumulative), либо дифференгдиалъными (different! В кумулятивных резервных копиях регистрируются все блоки, измен шиеся со времени создания первоначальной инкрементальной копи
Использование диспетчера восстановления (RMAN)
529
в дифференциальных резервных копиях регистрируются только блоки, изменившиеся после последнего инкрементального копирования, независимо от того, было ли это копирование уровня 0 или 1.
Когда в каталоге содержится ряд резервных копий различного типа, например копий-отображений, резервных наборов табличных пространств и инкрементальных резервных копий, RMAN может выбрать наилучшую комбинацию резервных копий для наиболее эффективного восстановления (частичного или полного) базы данных. У АБД по-прежнему есть возможность не дать RMAN использовать ту или иную конкретную резервную копию (например, если АБД полагает, что резервная копия повреждена и это не позволит RMAN выполнить операцию восстановления).
Решение о том, какое резервное копирование использовать — кумулятивное или дифференциальное, — отчасти основывается на том, где именно АБД желает потратить процессорное время и насколько много есть свободного дискового пространства. Применение кумулятивного резервного копирования означает, что каждая последующая инкрементальная резервная копия будет становиться все длиннее и для ее получения будет требоваться все больше времени, пока не будет сделана еще одна резервная копия уровня 0, но зато во время выполнения операций частичного или полного восстановления потребуются всего два резервных набора. С другой стороны, дифференциальные резервные копии регистрируют только изменения, произошедшие со времени выполнения последнего резервного копирования, так что каждый резервный набор может быть меньшего или большего размера, чем предыдущий, и при этом в них не будет совпадающих блоков данных. Однако для операций частичного или полного восстановления может потребоваться больше времени, если придется использовать для восстановления более двух резервных
наборов.
Продолжая пример с базой данных ord, можно обнаружить, что несколько файлов выпадают за границы стратегии сохранения (не дольше четырех дней); другими словами, есть файлы, для восстановления которых потребуется сохранять архивные журналы базы данных дольше четырех дней:
П RMAN> report need backup;
RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 4 days
Report of files whose recovery needs more than 4 days of archived logs
File Days Name
1
2
3
4
5
5
5
5
5
5
/u05/oradata/ord/system0l.dbf /u05/oradata/ord/undotbs01.dbf /u05/oradata/ord/sysaux01.dbf /u05/oradata/ord/users01.dbf /u05/oradata/ord/example01.dbf
RMAN>
530
Гпава 1$
Для исправления сложившейся ситуации необходимо сделать другую полную резервную копию можно или продолжить стратегию инкрементальных резервных копий, которая может оказаться более простой реализации и обслуживания. Для создания инкрементальной стратегии потребуется сначала выполнить инкрементальное резервное копирование уровня 0:
RMAN> backup incremental level О
2> as compressed backupset database;
Starting backup at 20-MAR-04
allocated channel: 0RA_DISK_1
channel 0RA_DISK_1: sid=244 devtype=DISK
channel 0RA_DISK_1: starting compressed incremental level 0 datafile backupset
channel 0RA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u05/oradata/ord/system01.dbf
input datafile fno=00003 name=/u05/oradata/ord/sysaux01.dbf
input datafile fno=00005 name=/u05/oradata/ord/example01.dbf
input datafile fno=00002 name=/u05/oradata/ord/undotbs01.dbf input datafile fno=00006 name=/u09/oradata/ord/oe_trans01.dbf input datafile fno=00004 name=/u05/oradata/ord/users01.dbf channel 0RA_DISK_1: starting piece 1 at 20-MAR-04 channel 0RA_DISK_1: finished piece 1 at 20-MAR-04 piece handle=/0raFlash/0RD/backupset/2004_03_20/
o1_mf_nnnd0_TAG20040320T153801_05gfwf1_.bkp comment=NONE channel 0RA_DISK_1: backup set complete, elapsed time: 00:02:47 Finished backup at 20-MAR-04
Starting Control File and SPFILE Autobackup at 20-MAR-04 piece handle=/0raFlash/0RD/autobackup/2004_03_20/
o1 _mf_s_521307651_05sgni5tv_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 20-MAR-04
RMAN>
В будущем в любой момент после этой инкрементальной резервной ко пии уровня 0 можно будет выполнить дифференциальную инкремент ную резервную копию уровня 1:
□ RMAN> backup as compressed backupset 2> incremental level 1 database;
Значением по умолчанию для типа инкрементальной резер пии является differential; ключевое слово differential не является ни зательным, ни даже разрешенным. Однако для выполнения куму ной резервной копии следует добавить ключевое слово cumulative.
□ RMAN> backup as compressed backupset
2> incremental level 1 cumulative database;
Использование диспетчера восстановления (RMAN)
531
Кроме того, выбор между кумулятивной и дифференциальной копиями может быть продиктован интенсивностью деятельности базы данных. В средах OLTP с высокой интенсивностью вставок и обновлений инкрементальные резервные копии могут оказаться более управляемыми в терминах использования дискового пространства. В средах хранилищ данных с относительно редкими обновлениями более полезной может оказаться стратегия дифференциального резервного копирования. В сравнении с использованием журналов оба типа инкрементального резервного копирования оказываются значительно более быстрыми в пересчете на время, требующееся для восстановления базы данных. В любом случае вопрос о стратегии сохранения RMAN оказывается решенным:
□ RMAN> report need backup;
starting full resync of recovery catalog
full resync complete
RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 4 days
Report of files whose recovery needs more than 4 days of archived logs File Days Name
RMAN>
Инкрементально обновляемые резервные копии
Так называемые инкрементально обновляемые резервные копии (incrementally updated backups) могут потенциально сделать операции частичного или полного восстановления базы данных еще более эффективными за счет переноса изменений из инкрементальной резервной копии уровня 1 в инкрементальную резервную копию уровня 0. Если проводить инкрементально обновляемое резервное копирование ежедневно, то для любой операции восстановления потребуются одна обновленная копия-отображение, одна инкрементальная резервная копия уровня 1 и самые свежие архивные и оперативные журналы базы данных. В следующем примере используется сценарий RMAN, выполнение которого может быть запланировано на одно и то же время каждый день с целью поддержания стратегии инкрементально обновляемого резервного копирования:
О run
{
recovery copy of database with tag 4incr_upd_img’;
backup incremental level 1
for recover of copy with tag kincr_upd_img’ database;
Ключевой частью обеих команд сценария run является фраза recover сору. Вместо того, чтобы выполнять восстановление реальных файлов базы данных, производится восстановление копии файлов данных базы Данных, применяя к ним инкрементальные резервные копии. Использование вместе с резервной копией RMAN тэга (метки) позволяет приме
532
Глав$
нить инкрементальную резервную копию к соответствующей копии-от0 бражению. Тэги позволяют АБД с легкостью обращаться к конкретно^ резервной копии для выполнения операций восстановления или очистки каталога; если команда backup не обеспечивает явно такого тэга, он будет автоматически сгенерирован для резервного набора и будет уникальным среди резервных наборов для целевой базы данных.
Мастера (wizards) резервного копирования OEM облегчают автомату зацию стратегии инкрементально обновляемого резервного копирования. На следующих далее рисунках мы продемонстрируем шаги, необходимые для конфигурирования такой стратегии в среде OEM.
На рис. 13.9 специфицируется стратегия резервного копирования (резервирования) базы данных.
База данных открыта, режим архивирования журналов (archivelog mode) активирован, и резервные копии будут следовать предполагаемым Oracle инструкциям (Oracle-suggested) по резервному копированию. Другим вариантом в ниспадающем меню является Customized (заказной, изготавливаемый по требованиям заказчика). На рис. 13.10 показан следующий шаг процесса конфигурирования резервного копирования: итоговая информация о базе данных, выбранная стратегия, куда будут посланы созданные резервные копии, используемый каталог восстановления и, наконец, краткое объяснение того, как будет производиться резервное копирование.
На рис. 13.11 специфицируется дата запуска резервного копирования и время суток для этого запуска. Хотя задание резервирования может
Рис. 13.9. Выбор стратегии резервирования в OEM
^пользование диспетчера восстановления (RMAN) 533
Тпск
ер 1 of
Internet
MMUM
Setup ac^ecvk
Рис. 13.10. Итоги настройки резервирования в OEM
” (/Г •» j f-V . • : rr-
г backup; $rtrf|V JAiouKfH#enre1 Exp^gK
File Ed»t View Fevwces
: Back
! к ili
.• Seet-.h < Favorites Media
W
• !>np'/, t92.J68 2 l^:55C0/eTi/ccnsote/dat-5ba$e/»ecjb*:kis>?tsmet*»c<d workj&type=<xec«_database
?r?ACLJ™ fchterprise ifor.duef Wr? is««'
hedule Backup: Setup
onl.woild
Oracle-suggested
Disk
linan
iitil:l521:nnanrep
Database Backup Strategy Storage Type Recovery Catalog Username Recovery Catalog Database
Daily Backup
A fj’l database ccpy will be taken during tne first backup Affoi Inal an incremental backup to disk wili be taken everyday Th₽ backups on disk will be retained so that you can always perform a ?u(i database recovery or a poict-in-time recovery to any time within the past 1 day
Flash Recovery Area OraFlash
TIP Disk backups that are necessary for a recovery to any time within the past 1 day are retained
Рис. 13.11. Планирование выполнения резервирования в OEM
534
I
Гпава 1$
. Back
... • ” ....... —---------------------------' ' •....... г
*.4dute Backup; fWew Microsoft Internet Uptorer
e Edit View Fe/ortes lock Help
:Й
? Search Favorites
* / •'
R.rMew
Schedule Backup: Review
** ‘ http:/'j$2.168 2.tfeo S5O€/etr./ccn$cle/databd$e/reCibackij0>tat3et«ord v*crtd&type»><>rsde_datab<S!W
I
Database
Eackup Strategy
Storage Type
ord. wot Id Oracle-sugyested Disk
Recovery Catalog Username, nn an
Recovery Catalog Database util:l521:tmanrep
A full database copy will be taken during the first backup. After that an incremental backup to disk will be taken everyday.
Daily Backup The backups on disk will be retained so that you can always perform a full database recovery or a point-in-iime recovery to any time within the past 1 day.
l>?p ? of ' Submit Job j
Settings
Flash Recovery Area О» л flash
Internet
Рис. 13.12. Итоговая информация OEM
быть выполнено в любое время суток, поскольку выполняется так называемое горячее резервирование (база данных открыта, и пользователи могут посылать транзакции на обработку), желательно свести к минимуму возможное влияние на время отклика для запросов и операций DML. Для этого следует запланировать выполнение задания резервирования на период времени с низкой активностью.
На рис. 13.12 предоставляется еще один шанс ознакомиться с тем, как именно будет выполнено резервное копирование и куда будет помещена результирующая резервная копия.
В нижней части окна браузера приводится фактический сценарии RMAN, который будет запланирован к ежедневному выполнению (с* • рис. 13.13). Он напоминает сценарий RMAN (см. выше в данном разделе).
Отслеживание изменения блоков при инкрементальном резервировании
Другой способ повышения производительности инкрементального Р зервного копирования состоит в том, чтобы разрешить так называек^^ отслеживание изменений блоков (block change tracking). При традицио инкрементальном резервировании RMAN должен инспектировать дый блок табличного пространства или файла данных, подлежащих р зервпому копированию, чтобы узнать, был ли этот блок изменен со^р^ мени последнего резервирования. Для очень больших баз данных вр нужное для такого сканирования блоков базы данных, может превые время, требующееся для реального копирования.
^пользование диспетчера восстановления (RMAN)
535
Fife ЕсЫ View Favorites Tccfc Help <
0 е**- ’ Л’5) Jy ‘i > --Search <£?Favcht« 8 . QJ
•XarJtw* Hip:,7192.168.2. l665500/ern/cocs3:e;d1aldbdse/rec/t*cF4jp?tsr9et«(xd world&type«o'«* le_detdba5e * ^>1 Go
Daily Backup The backups on disk will be retained so that you can always perform a full database recovery or a point in time recovery to any time within the past 1 day.
Settings
Flash Recovery Area OraFlash
RMAN Script ...... -- . .. • ...... .. .... ............. ..... ...... . .. . • . , . ...»• .... . .... Л ... ... ...... As
Daily Script run { allocate charnel oem _disk_backup device type disk; recover copy of database with tag ’ORA$OEM_LEV6L_C, backup incremental level 1 cumulative copies=1 (or recover of copy with tag ’ORA$CEM_LE\ZEL_D’ database.
}
Return to 5&aiegy Type Selection CanceQ (Back | Step 3 3 Submit Job J
Database | StlMP I Preferences | ttehl I Logout
! Copyright Ф1996 2004: Oracle. AX lights reserved
I IQs 64^4$.* f.Wtlroj
I v
^xzzXza*-.* a—• v I W* y>. WW'X+'*<hv4<**^Cv*{z>>.*y";’ '^'x' z .. .rfM»- .-a»-aaa^j м»»*й Y«**«-«• e*>v^/*^'-t*****^^J<*M^*^*A*«-*i*V-' '• ** •
। *£) Internet
L—----------— - ---------------- - --------.........-... -л....-...................... — „ . ... _ ...---------------------------------• ------——
Рис. 13.13. Сценарий резервирования в OEM
За счет разрешения отслеживания изменений блоков RMAN становится известно, какие блоки были изменены. Для этого используется так называемый файл отслеживания изменений блоков (block change tracking file). Хотя при использовании этого файла возникают некоторые дополнительные накладные расходы, связанные с использованием дискового пространства и с обслуживанием этого файла при каждом изменении блока, соотношение выгод и потерь говорит о том, что дело того стоит, если в целевой базе данных выполняются частые инкрементальные резервирования. В следующем примере создается файл отслеживания изменений блоков и активируется отслеживание изменений блоков:
О SQL> alter database enable block change tracking
2 using file ‘/u06/oradata/ord/block_chg.dbf’;
Database altered.
SQL> !ls -rw-r—
SQL>
-1 /u06/oradata/ord/block_chg. dbf
1 oracle oinstall 11600384 Apr 8 21:47
/иОб/oradata/ord/blockchg.dbf
В следующий раз при выполнении резервирования RMAN всего лишь потребуется использовать содержимое файла /u06/oradata/ord/block_ chg.dbf, для того чтобы определить, какие именно блоки должны быть скопированы. Дисковая память, требующаяся для хранения файла отеле-
536
Гпава 1$
живания изменившихся блоков, составляет примерно 1/250000 полноГо размера базы данных.
В представлении динамической производительности V$BLOCR CHANGE_TRACKING содержатся имя и размер файла отслеживания менившихся блоков, а также информация о том, разрешено ли отслеживание изменений блоков:
□ SQL> select filename, status, bytes from v$block_change_tracking;
FILENAME STATUS BYTES
/u06/oradata/ord/block_chg.dbf ENABLED 11599872
SQL>
Компрессирование резервной копии
Можно либо сконфигурировать для резервных наборов компрессирование как режим по умолчанию, либо явно специфицировать компрессирование в команде backup RMAN:
□ RMAN> backup as compressed backupset database;
Сравнивая размеры реальных файлов данных базы данных с размерами резервных наборов, можно понять, насколько значительного компрессирования удается достичь за счет увеличения процессорного времени:
□ [root@oltp root]# cd /OraFlash/ORD
[root@oltp ORD]# Is
archivelog autobackup backupset datafile
[root@oltp ORD]# cd backupset
[root@oltp backupset]# Is
2004_03_15 2004_03_18 2004_03_19 2004_03_20
[root@oltp backupset]# cd *20
[root@oltp 2004_03_20]# Is -1
total 122172
-rw-r----/ -| oracle oinstall 124977152 Mar 20 15:40
o1_mf_nnnd0_TAG20040320T153801_05sgfwf1_. bkp
[root@oltp 2004_03_20]# Is -1 /u05/oradata/ord
total 981072
-rw-r----/ 1 oracle oinstall 157294592 Mar 20 15.38 exa p e0 .
-rw-r----/ 1 oracle oinstall 314580992 Mar 20 15:38 sysauxOI.
-rw-r----/ 1 oracle oinstall 482353152 Mar 20 15:38 systemOI.
-rw-r----/ 1 oracle oinstall 209 9 2 Mar 20 09 56 empOl. b
-rw-r----/ 1 oracle oinstall 26222592 Mar 20 15:38 undo bsOl.U
-rw-r----/ 1 oracle oinstall 5251072 Mar 20 15:38 usersOl.dbf
[root@oltp 2004_03_20]#
Использование диспетчера восстановления (RMAN)
537
Файлы базы данных занимают в файловой системе около 1 Гбайт дискового пространства; компрессированные же наборы занимают чуть меньше 125 Мбайт.
Использование Flash Recovery Area
Выше в данной главе рассматривались параметры инициализации, необходимые для создания Flash Recovery Area: DB_RECOVERY_FILE_DEST и DB_RECOVERY__FILE_DEST__SIZE. Оба этих параметра являются динамическими, что позволяет АБД изменять либо адрес резервной копии в RMAN, либо размер пространства во Flash Recovery Area, отведенный для резервной копии, не требуя для этого перезапуска экземпляра.
Чтобы помочь применению использующих только диск сценариев восстановления, область Flash Recovery Area должна иметь достаточно большой размер, чтобы в ней можно было разместить копии всех файлов данных, файлы инкрементальных резервных копий, оперативные и архивные журналы базы данных (не на ленте), автоматические резервные копии управляющего файла и резервные копии SPFILE. Попытки использования большего или меньшего размера допустимого интервала восстановления или настройка стратегии избыточности потребуют настройки (изменения) размера Flash Recovery Area. Если область Flash Recovery Area ограничена в размере из-за общей нехватки места на диске, в ней, по меньшей мере, должно быть достаточно места для хранения архивных журналов, еще не скопированных на ленту. Динамическое представление производительности V$RECOVERY_FILE_DEST отображает информацию о количестве файлов в Flash Recovery Area о том, как много дисковой памяти используется в данный момент, а также о том, сколько всего дисковой памяти доступно во Flash Recovery7 Area.
В области Flash Recovery Area автоматически применяется OMF. Поскольку это часть упрощенной структуры управления Oracle 10g, то если для размещения архивных журналов базы данных требуется только один адрес, нс нужно явно устанавливать ни один из параметров инициализации LOG_ARCHI\zE_DEST_n. Если база данных находится в режиме archivelog и определена Flash Recovery Area, то параметр LOG_ARCHIVE_ DEST-10 неявно определяется как адрес Flash Recovery Area.
Как было показано во множестве предыдущих примеров, RMAN использует Flash Recovery Area очень “организованным” образом — обеспечивая различные каталоги для архивных журналов базы данных, резервных наборов, копий-отображений и автоматических резервных копий управляющего файла и SPFILE. В дополнение к этому каждый такой подкаталог делится в соответствии с отметками времени, что значительно облегчает нахождение требующегося резервного набора или копии-отображения, когда в этом возникает необходимость.
Несколько баз данных могут совместно использовать одну Flash Recovery Area, даже если это основная и резервная базы данных; даже если у них совпадают значения параметра DB_NAME, достаточно различия в параметре DB_UNIQUE_NAME, чтобы избежать возникновения Конфликтов. Утилита RMAN использует параметр DB UNIQUE_NAME, чтобы различать резервные копии для разных баз данных, использующих общую Flash Recovery Ai ea.
538
Гпава 1$
Проверка достоверности резервных копий
Наличие множества резервных копий-отображений или достаточного количества архивных журналов базы данных для поддержки допустимого интервала восстановления сразу же становится менее важным, если возникают проблемы с “живыми” файлами базы данных или с управляющими файлами. Команда backup validate database утилиты RMAN будет эмулировать резервное копирование, выполняя проверку существования специфицированных файлов и давая гарантии того, что эти файлы не повреждены. При этом не создаются файлы с резервными копиями. Такая команда оказывается полезной в сценарии, где можно превентивно проверить, не возникли ли какие-либо проблемы с базой данных или архивными журналами базы данных. При этом возникает возможность исправить проблемы еще до того, как они реально проявят себя в операциях восстановления, или, по крайней мере, запланировать дополнительное ночное время для избавления от найденных в течение рабочего дня проблем.
В следующем примере проверяется достоверность всей базы данных вместе с архивными журналами базы данных:
□ RMAN> backup validate database archivelog all;
Starting backup at 21-MAR-04
allocated channel: ORA_DISK_1
channel ORA_ DISK__1: sid=246 devtype=DISK
RMAN-00571: ===========================================================
RMAN-00569: ================ ERROR MESSAGE STACK FOLLOWSRMAN===========
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 03/21/2004 10:13:04
RMAN-06059: expected archived log not found,
lost of archived log compromises recoverability
ORA-19625: error identifying file
/u01/app/oracle/flash_recovery_area/0RD/archivelog/2004_03_03/ o1_mf_1_6_04fhy2t_.arc
0RA-27037: unable to obtain file status
Linux error: 2: No such file or directory
Additional information: 3
RMAN>
Команда backup validate идентифицировала файл архивного журн^ базы данных, которого больше нет в Flash Recovery Area. Может оыть, был сброшен на ленту за пределы RMAN или непреднамеренно У#^1 с диска. Изучив отметку времени (создания. — Прим, пер.) этого фаИ можно обнаружить, что этот файл не попадает в заданный допусти* интервал восстановления, равный четырем дням, так что этот файл нс ляется критичным в смысле восстанавливаемости. 0~
Синхронизация Flash Recovery Area и каталога восстановления с по щыо команды crosscheck будет рассмотрена ниже в длиной главе; поел правления всех только что обнаруженных проблем с перекрестными ее ками можно выполнить оставшуюся часть подтверждения достоверное
Использование диспетчера восстановления (RMAN)
539
О RMAN> backup validate database archivelog all;
Starting backup at 21-MAR-04
using channel ORA_DISK 1
channel ORA_DISK_1: starting compressed archive log backupset channel ORA_DISK_1: specifying archive log(s) in backup set input archive log thread-1 sequence=207 recid=202 stamp=520901173
input archive log thread=1 sequence=208 recid=203 stamp=520905522
input archive log thread=1 sequence=209 recid=204 stamp=520905663
input archive log thread=1 sequence=210 recid=205 stamp-520905719
• • •
input archive log thread=1 sequence=316 recid=311 stamp=521364700
input archive log thread=1 sequence=317 recid=312 stamp=521370803
input archive log thread=1 sequence=318 recid=313 stamp=521373610
channel ORA DISK _1: backup set complete, elapsed time:00.01:30
channel 0RA_DISK_1: starting compressed full datafile backupset channel 0RA_DISK_1: specifying datafile(s) in backupset input datafile fno=00001 name=/u05/oradata/ord/system01.dbf input datafile fno=00003 name=/u05/oradata/ord/sysaux01.dbf input datafile fno=00005 name-/u05/oradata/ord/example01.dbf input datafile fno=00002 name=/u05/oradata/ord/undotbs01.dbf input datafile fno=00004 name=/u05/oradata/ord/users01.dbf input datafile fno=00006 name=/u09/oradata/ord/oe_trans01.dbf channel 0RA_DISK_1: backup set complete, elapsed time: 00:01:46 Finished backup at 21-MAR-04
RMAN>
Во время подтверждения достоверности не было обнаружено ошибок; RMAN прочла каждый блок каждого архивного журнала базы данных и каждого файла данных, чтобы убедиться в том, что их можно прочесть и что они не содержат поврежденных блоков. Однако ни через дисковый, ни через ленточный каналы не было записано ни одной реальной резервной копии.
Операции восстановления
В каждый хороший план резервирования должен быть включен так называемый чрезвычайный план (disaster recovery plan), с помощью которого можно выбрать из резервной копии необходимые файлы данных и журналы и восстановить файлы базы данных.
Утилита RMAN может выполнять операции полного и частичного восстановления базы данных с различными уровнями детализации, и оолыная часть таких операций может быть выполнена в то время, когда база данных открыта и доступна для пользователей. Можно восстановить индивидуальные блоки, табличные пространства, файлы данных или даже всю базу данных. Кроме того, в RMAN есть различные методы подтверждения достоверности операции восстановления, при которых операция восстановления над файлами базы данных фактически не выполняется.
540
Гпава 1з
Восстановление носителя на уровне блоков
Когда в базе данных требуется восстановить всего лишь несколько блоков, RMAN может, вместо того чтобы выполнять полное восстановление файла данных, выполнить так называемое восстановление носителя науров, не блоков (block media recovery). Восстановление носителя на уровне бло-ков сводит к минимуму время применения журналов и существенно сокращает объем ввода/вывода, требующегося для восстановления только затронутого блока или блоков. Во время проведения восстановления носителя на уровне блоков затронутые этой операцией файлы остаются в онлайновом состоянии и продолжают быть доступными для пользователей.
Примечание Восстановление носителя на уровне блоков возможно только из приложения RMAN.
Есть много способов обнаружения повреждения блоков (block corruption). Во время выполнения операций чтения или записи в операторах insert или select Oracle может обнаружить, что блок поврежден, записать ошибку в трассировочный файл пользователя и аварийно завершить транзакцию. Команды RMAN backup или backup validate могут зарегистрировать поврежденные блоки в динамическом представлении производительности V$DATABASE_BLOCK_CORRUPTION. Кроме того, выявить поврежденные блоки могут команды analyze table и analyze index.
Для восстановления одного или нескольких блоков RMAN должна знать номер файла данных и номер поврежденного блока в этом файле данных. Эта информация имеется в трассировочном файле пользователя:
□ 0RA-01578 ORACLE data block corrupted (file # 6, block # 403) 0RA-01110: data file 6: ‘/u09/oradata/ord/oe_trans01.dbf’
Этот блок может появиться в представлении V$DATABASE__BLOCK_-CORRUPTION после выполнения команды RMAN backup; столбцы FILE# и BLOCK# предоставляют информацию, необходимую для выпол пения команды blockrecover. Столбец CORRUPTION_TYPE идентифи цирует тип повреждения блока, например FRACTURED (раздроблен), CHECKSUM (контрольная сумма) или CORRUPT (разрушен). Исправь ния в блоке с легкостью выполняются RMAN:
П RMAN> blockrecover datafile 6 block 403;
Starting blockrecover at 21-MAR-04 using channel 0RA_DISK__1
starting media recovery media recovery complete
Finished blockrecover at 21-MAR-04
RMAN>
Использование диспетчера восстановления (RMAN)
541
Поврежденный блок должен быть полностью восстановлен; другими словами, прежде чем блок можно будет снова считать пригодным к использованию, к нему должны быть применены все журнальные операции вплоть до самого последнего SCN.
Восстановление управляющего файла
В тех редких случаях, когда оказываются утерянными все копии управляющего файла, его легко восстановить, если используется каталог восстановления: нужно запустить экземпляр в режиме nomount (так как нет управляющего файла, который должен быть прочитан при запуске в режиме mount) и выполнить следующую команду RMAN:
□ RMAN> restore controlfile;
Если каталог восстановления не используется, можно добавить к этой команде фразу from 6<имя_файла>’, чтобы указать, где именно находится последняя версия управляющего файла:
□ RMAN> restore controlfile from ‘/u11/oradata/ord/bkup.ctl’;
После восстановления управляющего файла следует выполнить полное восстановление носителя для целевой базы данных, а потом открыть ее с опцией resetlogs. Полное восстановление носителя может быть выполнено с помощью RMAN или методами, описанными в главе 12.
Восстановление табличного пространства
Если диск, содержащий файлы данных табличного пространства, выходит из строя или оказывается поврежденным, его можно восстановить таким образом, чтобы табличное пространство во время восстановления оставалось открытым и было доступно пользователям. Исключением из этого правила является табличное пространство SYSTEM. Предположим, что в базе данных ord вышел из строя диск, содержащий файлы данных табличного пространства USERS. После первого телефонного звонка от пользователей (которым “посчастливилось” даже раньше, чем OEM, проинформировать об ошибке), можно проверить динамическое представление производительности V$DATAFILE_HEADER, чтобы увидеть, каким именно файлам данных необходимо восстановление:
О SQL> select file#, status, error, tablespace_name, name
2 from v$datafile_header;
file# status
1 ONLINE
2 ONLINE
3 ONLINE
4 ONLINE
5 ONLINE
6 ONLINE
7 ONLINE
ERROR TABLESPACE NAME
SYSTEM /u05/oradata/ord/system01.dbf
UNDOTBS1 /u05/oradata/ord/undotbs01.dbf
SYSAUX /u05/oradata/ord/sysaux01,dbf
CANNOT OPEN FILE
EXAMPLE /u05/oradata/ord/example01.dbf
OE_TRANS /u09/o rada ta/o rd/oe_t rans01 dbf
CANNOT OPEN FILE
7 rows selected.
542
Гпава 1з
После замены дисковода инициируется сеанс RMAN и обнаруживается, что номера 4 и 7 соответствуют табличному пространству USERS:
□ RMAN> report schema;
Report of database schema
File K-bytes Tablespace RB segs Datafile Name
1 471040 SYSTEM YES /u05/oradata/ord/system01.dbf
2 25600 UND0TBS1 YES /u05/oradata/ord/undotbs01.dbf
3 307200 SYSAUX NO /u05/oradata/ord/sysaux01.dbf
4 10240 USERS NO /u05/oradata/ord/users01.dbf
5 153600 EXAMPLE NO /u05/oradata/ord/example01.dbf
6 10240 OETRANS NO /u09/oradata/ord/oe_trans01.dbf
7 5120 USERS NO /u05/oradata/ord/users02.dbf
RMAN>
Для полного восстановления (restore) табличного пространства и приведения его в согласованное (непротиворечивое) состояние (recover) нужно принудительно перевести табличное пространство в автономное состояние, восстановить его и привести в согласованное состояние, азатем перевести в оперативное состояние:
□ RMAN> sql ‘alter tablespace users offline immediate’;
sql statement: alter tablespace users offline immediate
RMAN> restore tablespace users;
Starting restore at 21-MAR-04 allocated channel: ORA_DISK_1
channel ORA DISKJ: sid=241 devtype^DISK
channel ORA DISK 1: starting datafile backupset restore
channel ORA DISK 1: specifying datafile(s) to restore from backup set restoring datafile 00004 to /u05/oradata/ord/users01.dbf channel 0RA_DISK_1: restored backup piece 1
piece handle=/0raFlash/0RD/backupset/2004_03_20/
o1_mf_nnnd0_TAG20040320T153801_05gfwf1_.bkp tag=TAG20040320T153801
channel 0RA_DISK_1: restore complete
channel 0RA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00007 to /u05/oradata/ord/users02.dbf channel 0RA_DISK_1: restored backup piece 1
piece handle=/0raFlach/0RD/backupset/2004_03_21/
o1_mf_nnnd1_TAG20040321T115355_05ooogb_.bkp tag=TAG20040321T11535b
channel 0RA_DISK_1: restore complete
Finished restore at 21-MAR-04
RMAN> recover tablespace users;
Использование диспетчера восстановления (RMAN)
543
Starting recover at 21-MAR-04
using channel 0RA_DISK_1
channel ORA .DISK 1: starting incremental datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set destination for restore of datafile 00004: /u05/oradata/ord/users01.dbf channel 0RA_DISK_1: restored backup piece 1
piece handle=/OraFlach/ORD/backupset/2004_03_20/
o1_mf nnnd1_TAG20040320T162357_05k3ysx_.bkp tag=TAG20040320T162357
channel ORA DISK_1: restore complete
channel 0RA_DISK_1: starting incremental datafile backupset restore
channel ORA DISK_1: specifying datafile(s) to restore from backup set destination for restore of datafile *00004: /u05/oradata/ord/users01.dbf channel 0RA_DISK_1: restored backup piece 1
piece handle=/0raFlach/0RD/backupset/2004_03_21/
o1_mf_nnnd1_TAG20040321T115355_05ooogb_.bkp tag=TAG20040321T115355
channel ORA_DISK_1: restore complete
starting media recovery
archive log thread 1 sequence 320 is already on disk as file
/0raFlash/0RD/archivelog/2004_03_21/o1_mf_1_320_05vp7k0m_.arc
archive log thread 1 sequence 321 is already on disk as file
/0raFlash/0RD/archivelog/2004_03_21/o1_mf_1_321_05vpj1cq_.arc
archive log thread 1 sequence 322 is already on disk as file
/0raFlash/0RD/archivelog/2004_03_21/o1_mf_1_322_05vtdg2x_.arc
archive log thread 1 sequence 323 is already on disk as file
/0raFlash/0RD/archivelog/2004_03_21/o1_mf_1_323_05vzllqk_.arc
archive log filename=/0raFlash/0RD/archivelog/2004_03_21/ o1_mf_1_320_05vp7k0m_.arc thread=1 sequence=320
archive log filename=/0raFlash/0RD/archivelog/2004_03_21/ o1_mf_1_321_05vpjlcq_.arc
thread=1 sequence=321 media recovery complete Finished recover at 21-MAR-04
RMAN> sql ‘alter tablespace users online’;
sql statement: alter tablespace users online
RMAN>
Команда restore копирует самые свежие копии-отображения или копии резервного набора файлов данных из табличного пространства USERS на места их первоначального расположения. Команда recover применяет накатку (на профессиональном языке так называются действия, противоположные откату. — Прим, пер.} либо по файлам журналов базы данных, либо по инкрементальным резервным копиям, чтобы довести объекты в табличном пространстве до состояния, соответствующего самому последнему SCN. После переведения табличного пространства в оперативное состояние оно снова будет доступно для использования, и
544
Гпава 1з
при этом в табличном пространстве не будет потеряна ни одна зафиксированная транзакция.
Восстановление файла данных
Операция восстановления файла данных очень напоминает операцию восстановления табличного пространства. После того зафиксирован^ потери или разрушения файла данных (для этой цели используется представление V$DATAFILE_HEADER) команды RMAN становятся очень похожими на предыдущий пример; табличное пространство переводится в автономный режим, файл(ы) данных восстанавливаются и накатываются, после чего табличное пространство снова переводится в оперативный режим. Если потерян только файл данных номер 7, команды recover и restore выглядят вот так:
□ RMAN> restore datafile 7;
RMAN> recover datafile 7;
Если используется OEM, процедура остается столь же простой. На рис. 13.14 конфигурируется восстановление файла данных с помощью выбора потерянного файла (#7) в табличном пространстве USERS.
Экран на рис. 13.15 позволяет выбрать, какая из резервных копии должна быть использована для выполнения операции восстановления. За исключением случая, когда заранее известно о том, что последняя резервная копия повреждена или не находится в онлайновом режиме, имеет
Рис. 13.14, Выбор файла данных для восстановления
Использование диспетчера восстановления (RMAN)
545
ВаЛ • (* j : / z> Search f>cr*« Media - Д .
•'168.2 l66;55(X3/en/consc-ie/d8tabdse/reC)’reccvery^arget«o<d.wofkfctype<“0(a:le_63tabase v
(<*v Riip v
Perform Recovery: Backup
Cancel) Баск ] Step 2 of 4 ? Next)
Database Owed Type Operation Type Recovery Catalog Username Recovery C al a eg Database
ord.world Datafiles Restore Only поли util:l521:iniaiue|)
Specify a backup fbm which to restore your files
(r The nr osl recent backup
The backup taken at or right before the specified po<tf-in-time
“Date Mar 21.2004 Гипе 3OAM (‘PM
О SUN О
О Sequence О
С'The backup spatifi&d by a lag i TAG20C49315T22I256 y-
V
gj Оспе 30 Internet
Рис. 13.15. Выбор резервной копии, используемой для операции восстановления
смысл сразу же использовать для восстановления самую свежую резервную копию.
На рис. 13.16 предлагается опция для выбора восстановления файла данных в другом месте; в этом случае выбирается восстановление файла па том же самом месте (по тому же самому адресу). Если вышедший из строя дисковод, на котором хранится файл данных, не может быть отремонтирован, нужно указать для восстановления файла данных новый адрес.
Перед тем, как задание RMAN будет передано в пакетную обработку, есть еще один шанс просмотреть Конфигурацию задания. На рис. 13.17 показаны реальные команды RMAN, которые будут выполняться для осуществления запрашиваемой операции.
Восстановление всей базы данных
Хотя потеря всей базы данных является очень серьезным и катастрофи-ческим событием, наличие надежной стратегии резервного копирования и восстановления, наподобие той, что была ранее описана в этой главе, позволит вернуть базу данных в состояние, в котором будут учтены все самые свежие зафиксированные транзакции, приложив для этого минимум усилий. В приводимом ниже сценарии предполагается, что были п- >-теряны все файлы данных. Однако, поскольку предусмотрительно было применено мультиплексирование управляющего файла и оперативных файлов журналов базы данных на несколько различных дисковых уст-
546
Гпава 1з
•. , <’ ‘ *T1* ^7’^*лт1^5®Зйвж5У’*и5«23у*’'*£<• •
3l Perform. Recovery: 4c mine Microsoft IntcrneLExpforer
Fie Edfc View Favorites Tools Help
Search Favorites Media L * k' • *•* '%*> к •
,.t.: .1^ ; ... «.«A.V - • •--• -.’^--v- *₽*v*vA' • .' . • V- . . »<v :<*Л! ..г -Л'С -v» • vV*/ <va»v .-.. > v •'•>”'’• *•»•- ' •*’’. • •
Ar^es* http //192 168.2 I66:5500/efr/conso;e/ii«t3ba5e/rec/fe<o,^ry’ur3et«<xdv>c<id&type*otette_.d3tebd5e ... > Z . - .< ..V». . . ,.• Z . V .... . % . . , . - -•*>./ • • • A. «• • «' - - --Л . ..Х^влЛ/«. ,e. u... ...z. I , - ^./Я,1 - • • -> -* • - ---- -- • • • • -Z“V —%• •* - • •“ •
Баск
ORACLE Ln ter prise Manager 10g
OaVHs.is’.' Гл; tmT
'. ' >♦ г ч 4 лЛрЗ Л ? 4; •;Y Tj •
Rcniinre Revsww
Perforin Recovery: Rename
4Cancef) v Back | Step 3 of 4 fiNexT)
Catabase Object Type Operation Type Recovery Catalog Username Recovery Catalog Database
oni.worhl
Datafiles
Restore Only iman util:1521:tinanrep
Do you want to restore the files to a different location^
<t>No Restore the files to the default location
О Ves Restore the files to a new. common location
TIP This optiori vdls execute an RMAN жг<е’ operator
Location
Ed Update the control file to use the renamed fi'es
’ h's 1$ or^y я* ’Ves’ above v
Done Internet '
Рис. 13.16. Указание места размещения восстановленного файла данных
Рис. 13.17. Просмотр опций восстановления
Использование диспетчера восстановления (RMAN)
547
ройств, во время операции частичного и полного восстановления RMAN они будут доступны.
Все операции полного (restore) и частичного (recover) восстановления могут быть выполнены в среде RMAN; сначала надо запустить RMAN и открыть базу данных в режиме mount:
□ [oracle@oltp oracle]$ rman target / catalog rman/rman001@rmanrep
Recovery Manager: Release 10.1.0.2.0 - Production
Copyright (c) 1995, 2004, Oracle. All rights reserved.
connected to target database (not started) connected to recovery catalog database
RMAN> startup mount
Oracle instance started database mounted
Total System Global Area 197132288 bytes
Fixed Size 778076 bytes
Variable Size 162537636 bytes
Database Buffers 33554432 bytes
Redo Buffers 262144 bytes
RMAN>
Утилита RMAN подключается к базе данных и идентифицирует ее как недоступную; это то же самое, что при подключении к SQL*Plus увидеть сообщение “Connected to an idle instance” (Подключение к неработающему экземпляру). Для восстановления базы данных используются следующие шаги:
□ RMAN> restore database;
Starting restore at 21-MAR-04
allocated channel: 0RA_DISK_1
channel 0RA_DISK_1: sid=270 devtype-DISK
channel 0RA_DISK_1: starting datafile backupset restore
channel 0RA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00001 to /u05/oradata/ord/system01.dbf restoring datafile 00002 to /u05/oradata/ord/undotbs01.dbf restoring datafile 00003 to /u05/oradata/ord/sysaux01.dbf restoring datafile 00004 to /u05/oradata/ord/users01.dbf
estoring datafile 00005 to /u05/oradata/ord/example01.dbf
restoring datafile 00006 to /u09/oradata/ord/oe_trans01.dbf
channel 0RA_DISK_1: restored backup -piece 1
Piece handle=/0raFlash/0RD/backupset/2004_03_20/
o1_mf_nnnd0_TAG20040320T153801_05sgfwf1_.bkp tag=TAG20040320T153801
channel ORA_DISK_1: restore complete
channel 0RA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00007 to /u05/oradata/ord/users02.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/OraFlash/0RD/backupset/2004_03_21/
o1_mf_nnnd1_TAG20040321 Г115355_05vooogb_.bkp tag=TAG20040321T115355
channel ORA_DISK_1: restore complete
548
Гпава 7з
Finished restore at 21-MAR-04
RMAN> recover database;
Starting recover at 21-MAR-04 using channel: 0RA_DISK_1 channel ORA_DISK 1: starting incremental datafile backupset restore channel ORA_DISK 1: specifying datafile(s) to restore from backup set destination for restore of datafile 00001: /u05/oradata/ord/system01.dbf
destination for restore of datafile 00002: /u05/oradata/ord/undotbs01.dbf
destination for restore of datafile 00003: /u05/oradata/ord/sysaux01.dbf
destination for restore of datafile 00004: /u05/oradata/ord/users01.dbf
destination for restore of datafile 00005: /u05/oradata/ord/example01. dbf
destination for restore of datafile 00006: /u09/oradata/ord/oe_trans01.dbf
channel 0RA_DISK_1: restored backup piece 1 piece handle=/0raFlash/0RD/backupset/2004_03_20/
o1_mf_nnnd1_TAG20040320T162357_05sk3ysx_.bkp tag=TAG20040320T162357 channel 0RA_DISK_1: restore complete channel 0RA_DISK_1: starting incremental datafile backupset restore channel 0RA_DISK 1: specifying datafile(s) to restore from backup set destination for restore of datafile 00001: /u05/oradata/ord/system01. dbf
destination for restore of datafile 00002: /u05/oradata/ord/undotbs01.dbf
destination for restore of datafile 00003: /u05/oradata/ord/sysaux01.dbf
destination for restore of datafile 00004: /u05/oradata/ord/users01.dbf
destination for restore of datafile 00005: /u05/oradata/ord/example01.dbf
destination for restore of datafile 00006: /u09/oradata/ord/oe_trans01.dbf
channel 0RA_DISK 1: restored backup piece 1
piece handle=/0raFlash/0RD/backupset/2004_03_21/
01. mf_nnnd1JAG20040321T115355 05vooogb_.bkp tag-TAG20040321T115355 channel 0RA_DISK_1: restore complete
starting media recovery
archive log thread 1 sequence 320 is already on disk as file
/0raFlash/0RD/archivelog/2004_03_21/o1_mf_1_320_05vp7k0m_.arc archive log thread 1 sequence 321 is already on disk as file
/0raFlash/0RD/archivelog/2004_03 21/o1_mf_1_321_05vpj1cq_.arc archive log thread 1 sequence 322 is already on disk as file
/0raFlash/0RD/archivelog/2004_03 21/o1_mf_1_322_05vtdg2x_.arc archive log thread 1 sequence 323 is already on disk as file
/0raFlash/0RD/archivelog/2004_03_21/o1_mf_1_323_05vzllqk_.arc
archive log filename=/0raFlash/0RD/archivelog/2004_03_21/
o1_mf_320_05vp7k0m_.arc thread=1 sequence=320
archive log filename=/0raFlash/0RD/archivelog/2004_03_21/
o1_mf_321_05vpj1cq_.arc threads sequence=321
media recovery complete
Finished recover at 21-MAR-04
RMAN> alter database open;
database opened
RMAN>
Использование диспетчера восстановления (RMAN)
549
Теперь база данных открыта и доступна для использования. Утилита RMAN выберет наиболее эффективный способ выполнения запрашиваемых операций, сводящий к минимуму число файлов, к которым должен быть получен доступ, или операций дискового ввода/вывода, требующееся для приведения базы данных в согласованное состояние в наикратчайшее возможное время. В предыдущем примере RMAN использует для восстановления баз данных копии-отображения, инкрементальные резервные копии и архивные файлы журналов базы данных.
Во время операции восстановления утилите RMAN может потребоваться восстановить архивные журналы базы данных с ленты; для ограничения количества дискового пространства, используемого во время операции восстановления, в команде recover из предыдущего примера можно использовать следующие опции:
□ RMAN> recover database delete archivelog maxsize 2gb;
Параметр delete archivelog указывает RMAN на необходимость удаления с диска архивных файлов журналов базы данных, которые были восстановлены с ленты для этого варианта восстановления; параметр maxsize 2gb ограничивает количество пространства, которое в любой момент времени может быть занято восстановленными архивными файлами журналов базы данных, двумя гигабайтами. В базе данных ord эти два параметра не требуются; все архивные файлы журналов базы данных, необходимые для восстановления базы данных, хранятся в области Flash Recovery Area на диске в порядке реализации определенной стратегии сохранения.
Проверка допустимости операций восстановления
Выше в данной главе уже проверялась допустимость блоков данных в файлах данных, которые нужно было подвергнуть резервному копированию. В этом разделе будем придерживаться противоположного подхода и вместо этого будем проверять допустимость (пригодность для выполнения своей функции. — Пргсм. пер.) уже сделанных резервных копий. Кроме того, мы узнаем из RMAN, какие именно резервные наборы, копии-отображения и архивные журналы должны быть использованы в операции восстановления, не производя при этом фактического восстановления.
restore preview
Команда restore preview (предварительный просмотр восстановления) обеспечивает перечень файлов, которые RMAN будет использовать для выполнения запрашиваемой операции; предварительный просмотр будет также указывать, например, на то, используются ли при восстановлении ленточные тома. В действительности не будет восстановлен ни один из файлов, будут сделаны только запросы к каталогу восстановления, чтобы определить, какие файлы требуются для восстановления. В следующем примере выясняется, что потребуется RMAN для восстановления табличного пространства USERS:
550
Гпава 1з
□ RMAN> restore tablespace users preview;
Starting restore at 21-MAR-04 using channel 0RA_DISK_1
List of Backup Sets
BS Key Туре LV Size Device Type Elapsed Time Completion Time
— — — — — — — — — —
850 Incr 0 1М DISK 00:02:42 20-MAR-04
BP Key: 853 Status: AVAILABLE Compressed: NO Tag: TAG20040320T153801
Piece Name:
/0raFlash/0RD/backupset/2004_03_20/
o1_mf_nnnd0_TAG20040320T153801_05sgfwf1_bkp
List of Datafiles in backup set 850
File LV Type Ckp SCN Ckp Time Name
4 0 Incr 1353755 20-MAR-04 /u05/oradata/ord/users01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
1173 Incr 1 64K DISK 00:02:03 21-MAR-04
BP Key: 1176 Status: AVAILABLE Compressed: NO Tag: TAG20040321T115355
Piece Name:
/0raFlash/0RD/backupset/2004_03_21/
o1_mf_nnnd1_TAG20040321T115355_05vooogb_bkp
List of Datafiles in backup set 1173
File LV Type Ckp SCN Ckp Time Name
7 1 Incr 1409491 21-MAR-04 /u05/oradata/ord/users02.dbf
Finished restore at 21-MAR-04
RMAN>
Для операции восстановления RMAN потребуется использовать Дв^ резервных набора — по одному для каждого файла данных в пространст USERS. Для “подтягивания” табличного пространства до текущего будут использованы архивные файлы журналов базы данных.
Если операцию восстановления необходимо выполнить немедле ’ а один из файлов, требующихся RMAN для выполнения операции вое новления, находится “вне игры”, можно использовать команду с^аП^е^е, unavailable, чтобы отметить, какой из резервных наборов является доступным. После этого можно еще раз выполнить команду *eSt tablespace ... preview, чтобы увидеть, может ли RMAN использовать Д пт.тпптшрпия вяппоса дисковые резервные наборы.
Использование диспетчера восстановления (RMAN)
551
RESTORE VALIDATE
Команда restore... preview не выполняет чтения фактических резервных наборов, используя только информацию из каталога восстановления; если же нужно выяснить, являются ли резервные наборы пригодными для чтения и не повреждены ли они, необходимо использовать команду restore ... validate. Как и для большинства других команд RMAN, можно выполнить ее для файла данных, для табличного пространства или для всей базы данных. В следующем примере выполняется проверка допустимости для тех же самых резервных наборов, которые были включены в отчет RMAN в предыдущем примере для пространства USERS:
□ RMAN> restore tablespace users validate;
Starting restore at 21-MAR-04 using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: restored backup piece 1 piece
handle=/0raFlash/0RD/backupset/2004_03_20/
o1_mf_nnnd0_TAG20040320T153801_05gfwf1_.bkp tag=TAG20040320T153801 channel 0RA_DISK_1: validation complete channel 0RA_DISK_1: starting validation of datafile backupset channel 0RA_DI8K_1: restored backup piece 1 piece handle=/0raFlash/0RD/backupset/2004_03_21/ <
o1_mf_nnnd1_TAG20040321T115355_05ooogb_.bkp tag=TAG20040321T115355 channel 0RA_DISK_1: validation complete Finished restore at 21-MAR-04
RMAN>
Все блоки обоих резервных наборов были прочитаны, чтобы убедиться в том, что они пригодны для операции восстановления табличного пространства USERS.
Восстановление на определенный момент в прошлом
Утилита RMAN может быть использована для реализации так называемого восстановления на определенный момент в прошлом (point in time recovery — PITR) или полного и частичного восстановления состояния базы данных вплоть до отметки времени или SCN непосредственно перед тем моментом, когда произошел отказ базы данных. Как было показано в главе 12, восстановление на определенный момент в прошлом может быть полезно для восстановления после ошибки пользователя, например, когда вчера была случайно удалена таблица, но эта ошибка была обнаружена только сегодня. Используя PITR, можно восстановить базу данных в ее состоянии на момент времени непосредственно перед тем, когда была удалена таблица.
552
Г.пава 1з
-.4..,,, , • ; . .- f- .• > ,v
a Perfprm jlecowry.- fcpinHo-Ume Mie rowfl Irrtor.oel fxplorer
Fde £cx View Favorites
Tools Help
« ’ * L
vi . . search
*
Favorites
Ди ''S^’-^http ,’/192.165.2 166 SSOC/em/coi^e/datdbase/retAeco^fy'tiirget-crd.v^cfWalYpe^ordikjjdaJaDase
Point ui tune
Perform Recovery: Point-in-time
СапсеГ) Step i J
Database Object Type Opera!:on Type Recovery Catalog Username Recovery Catalog Database
।
oid.woikl
Tnblespaces
Restore and Recover
rman
utii:1521:rmamep
You may recover tablespaces io the current time If you want to recover the tablespaces to a poim-indime in ‘he past, enter a date and time, an SCN. or a log sequence number below
О Recover tc the current lime
0 Recover tc a prior point-in-fime
$ IIP D es not atlcw datafde renaming, co y
that step
Mar 21.2004 \
i Mar : 20t*4
л
SCh
0
C. Sequence
0
Internet
iiihihiihm t wrw.wwHl
Рис. 13.18. Конфигурирование восстановления на определенный момент в прошлом с помощью OEM
Применение PITR связано с одним недостатком: теряются все изменения, произошедшие в базе данных, начиная с момента, на который было проведено восстановление. Необходимо взвесить этот недостаток и сравнить его с последствиями, вызванными удалением таблицы. Если оба варианта нежелательны, следует выбрать другой метод; например, в качестве альтернативы восстановлению при ошибках пользователя подобного рода следует использовать flashback-восстановление таблицы или табличного пространства на определенный момент времени в прошлом (tablespace point in time recovery — TSPITR).
На рис. 13.18 показано, как можно с использованием OEM сконфиП рировать TSPITR для восстановления табличного пространства по со стоянию на 8:00 утра 21 марта 2004 г., предположительно непосредствен но перед тем моментом, когда произошла ошибка пользователя. Вмес момента времени можно указать SCN или порядковый номер журнальн го файла, если точная дата и время этого события неизвестны.
Разнообразные операции
В следующих разделах будут охвачены некоторые другие возможное RMAN, выходящие за рамки операций резервного копирования и полно или частичного восстановления базы данных. Будет показано, как слеД) чяпегистоировать наличие других резервных копий, сделанных вне оаз
Использование диспетчера восстановления (RMAN)
553
данных (например, средствами операционной системы. — Прим, пер.), и выполнять некоторые операции по сопровождению каталога восстановления. Будут приведены примеры использования команд list и report.
Каталогизация других резервных копий
Например, нужно, чтобы в каталог восстановления были включены резервные копии, сделанные не средствами RMAN, например копии-отображения, выполненные с помощью команд операционной системы:
□ # ср /u05/oradata/ord/sysaux01.dbf /u10/oradata/ord/sysaux01_bkup.dbf
Предупреждение Копии-отображения, сделанные с помощью команд операционной системы, должны быть выполнены либо в то время, когда база данных полностью остановлена, либо в то время, когда действуют команды alter tablespace ... begin/end backup.
Эту копию-отображение табличного пространства SYSAUX легко зарегистрировать в каталоге восстановления RMAN, используя команду catalog:
□ RMAN> catalog datafilecopy ‘/u10/oradata/ord/sysaux01_bkup.dbf’;
cataloged datafile copy
datafile copy filename=/u10/oradata/ord/sysaux01J)kup.dbf
recid=26 stamp=521415717
RMAN>
С этого момента копия-отображение зарегистрирована в репозитории RMAN. Теперь она может рассматриваться как претендент на участие в операциях полного и частичного восстановления табличного пространства SYSAUX.
Обслуживание каталога восстановления
Выше в данной главе обсуждалось использование команды backup validate для получения гарантий, что все файлы, которые могут быть использованы в операциях резервного копирования, являются доступными, пригодными для чтения и неповрежденными. В этом примере обнаруживается, что существует несоответствие между тем, что упоминается в отчете каталога, и архивными журналами базы данных на диске; некоторые старые архивные журналы были непреднамеренно удалены с диска во время операций по его очистке. В этом сценарии будут показаны некоторые операции обслуживания, которые могут понадобиться для выполнения приведения каталога в состояние, синхронизированное с реально существующими файлами на диске.
о RMAN> backup validate database archivelog all;
Starting backup at 21-MAR-04
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=246 devtype=DISK
554
Гпава 1з
RMAN-00571: ========================================================= RMAN-00569: ================== ERROR MESSAGE STACK FOLLOWS ========== RMAN-00571: ========================================================= RMAN-03002: failure of backup command at 03/21/2004 10:13:04 RMAN-06059: expected archived log not found, lost of archived log compromises recoverability
ORA-19625: error identifying file
/u01/app/oradata/flash_recovery_area/0RD/archivelog/2004_03_03/ o1_mf_1_6_04f6hy2t_.arc
0RA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
RMAN>
Первая попытка исправить сложившуюся ситуацию — это удаление всех устаревших файлов, не попадающих в допустимый интервал восстановления, равный четырем суткам плюс добавленные на всякий случай дополнительные сутки хранения архивных журналов базы данных, так как в области Flash Recovery Area достаточно свободного места.
□ RMAN> delete obsolete recovery window of 5 days;
using channel 0RA_DISK_1
Deleting the following obsolete backups and copies:
Type Key Completion Time Filename/Handle
Backup Set 559 15-MAR-04
Backup Piece 562 15-MAR-04
/0raFlash/0RD/backupset/2004_03_15/ o1_mf_nnsnf_TAG20040315T221256_05dzxg62_.bkp
Archive Log 292 03-MAR-04
/u01/app/o racle/flash_ recove ry_a rea/ORD/a rchivelog/2004_03_03/
o1_mf_1_6_04f6hy2t_.arc
Archive Log 293 03-MAR-04
/u01/app/oracle/flash_recovery_area/0RD/archivelog/2004_03_03/ o1_mf_1_7_04fxrp4_.arc
Archive Log 491 15-MAR-04
/0raFlash/0RD/archivelog/2004_03_15/o1_mf_1_205_05ds6rqj_-arc
Archive Log 492 15-MAR-04
/0raFlash/0RD/archivelog/2004_03_15/o1_mf_1_206_05dxmk83_.arc
Do you really want to delete the above objects (enter Yes or No)9 yes deleted backup piece
backup piece handle=/0raFlash/0RD/backupset/2G04_03_15/
o1_mf_nnsnf_TAG20040315T221256_05dzxg62_.bkp recid=2 stamp=52089940b
deleted archive log
archive log filename=/0raFlash/0RD/archivelog/2004_03_14/ o1_mf_1_180_059dscwh_.arc recid=175 stamp=520781518
deleted archive log
archive log filename=/0raFlash/0RD/archivelog/2004_03_14/
o1_mf_1_181_059dshjx_. arc recid=176 stamp=520781519
Использование диспетчера восстановления (RMAN)
555
archive log filename=/0raFlash/0RD/archivelog/2004_03_15/
o1_mf_1_206_05dxmk83_. arc recid=201 stamp=520897043
Deleted 28 objects
RMAN-06207: WARNING: 174 objects could not be deleted for DISK channel(s) due
RMAN-06208: to mismatched status. Use CROSSCHECK command to fix
status
RMAN-06210: List of Mismatched objects
RMAN-06211: ==========================
RMAN-06212: Object Type Filename/Handle
RMAN-06213: ----------- --------------------------------------------
RMAN-06214: Archivelog
/u01/app/oracle/flash_recovery_area/0RD/archivelog/2004_03_03/
o1_mf_1_6_04f6hy2t_.arc
RMAN-06214: Archivelog
/u01/app/oracle/flash_recovery_area/0RD/archivelog/2004_03_14/
o1_mf_1_178_0593y15x_.arc
RMAN-06214: Archivelog
/0raFlash/0RD/archivelog/2004_03_14/o1_mf_1_179_059bch2k_.arc
RMAN>
Хотя из области Flash Recovery Area удалено много устаревших файлов, каталог восстановления и содержимое диска все еще не синхронизированы друг с другом; для исправления ситуации RMAN советует использовать команду crosscheck:
□ RMAN> crosscheck archivelog all;
released channel: ORA_DISK_1
allocated channel: 0RA_DISK_1
channel ORA_DISK_1: sid=246 devtype=DISK
validation failed for archived log archive log
filename=/u01/app/oracle/flash_recovery_area/0RD/archivelog/2004_03_0- 3/ o1_mf_1_6_04f6hy2t_.arc recid=1 stamp=519857573
validation failed for archived log
• • *
archive log
filename=/0raFlash/0RD/archivelog/2004_03_21/o1_mf_1_318_05vh0850_.arc
recid=313 stamp=521373610
Crosschecked 286 objects
RMAN>
Теперь пропущенные архивные журналы базы данных будут помечены в каталоге меткой EXPIRED и не будут рассматриваться при подтверждении допустимости резервных копий или для выполнения операций полного или частичного восстановления:
556
Гпава 1з
□ RMAN> backup validate database archivelog all;
Starting backup at 21-MAR-04
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=252 devtype=DISK
channel ORA_DISK_1: starting compressed archive log backupset channel 0RAJ)ISK_1: specifying archive log(s) in backup set input archive log thread=1 sequence=207 recid=202 stamp=520901173
input archive log thread=1 sequence=208 recid=203 stamp=520905522
input archive log thread=1 sequence=209 recid=204 stamp=520905663
input archive log thread=1 sequence=326 recid=321 stamp=521404606
input archive log thread=1 sequence=329 recid=324 stamp=521412412
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:58 channel 0RA_DISK_1: starting compressed full datafile backupset channel 0RA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u05/oradata/ord/system01.dbf
input datafile fno=00003 name=/u05/oradata/ord/sysaux01.dbf
input datafile fno=00005 name=/u05/oradata/ord/example01.dbf
input datafile fno=00002 name=/u05/oradata/ord/undotbs01.dbf
input datafile fno=00004 name=/u05/oradata/ord/users01.dbf
input datafile fno=00006 name=/u09/oradata/ord/oe_trans01.dbf
input datafile fno=00007 name=/u05/oradata/ord/users02.dbf
channel 0RA_DISK_1: backup set complete, elapsed time: 00:02:08
Finished backup at 21-MAR-04
RMAN>
Все файлы данных, которые RMAN может рассматривать в качестве кандидатов для использования в операции резервного копирования, включая архивные журнальные файлы, теперь доступны и читаемы.
Команды REPORT и LIST
В данной главе было представлено много примеров, показывающих, как извлекать информацию из каталога восстановления, независимо от того, размещен он в управляющем файле целевой базы данных или в базе данных каталога репозитория. Для этих целей использовались обе коман ды — list и report. Главное отличие между этими командами заключается их сложности: команда list отображает информацию о резервных на рах и копиях-отображениях в репозитории, а также перечисляет содер жимое сценариев, хранящихся в каталоге репозитория:
□ RMAN> list backup summary;
List of Backups
Key 558 TY В LV F S А Device Туре DISK Completion Time 15-MAR-04 #Pieces 1 #Copies 1 Compressed Tag N° TAGonnlnqi5T22lS
560 657 670 В В В F F F А А А DISK DISK DISK 15-MAR-04 19-MAR-04 19-MAR-04 1 1 1 1 1 1 NO TAG2OO4O315T^ NO TAG20040319T094 NO TAG20040319T10041
1564 1585 В В 1 F А А DISK DISK 21-MAR-04 21-MAR-04 1 1 1 1 YES TAG20040321T18660 NO TAG20040321T185
^пользование диспетчера восстановления (RMAN)
557
В отличие от команды list, команда report выполняет подробный анализ информации в каталоге восстановления; например, в одном из предыдущих примеров команда report использовалась для идентификации того, какие файлы базы данных требуют резервного копирования для достижения соответствия со стратегией сохранения. В следующем примере сначала выясняется, какие файлы данных старше 3/15/04, а затем запрашивается текущий статус этих файлов данных:
□ RMAN> report schema at time=’15-mar-04’;
Report of database schema Datafile Name
File K-bytes Tablespace RB segs
1 471040 SYSTEM YES /u05/oradata/ord/system01. dbf
2 25600 UND0TBS1 YES /u05/oradata/ord/undotbs01. dbf
3 307200 SYSAUX YES /u05/oradata/ord/sysaux01. dbf
4 10240 USERS YES /u05/oradata/ord/users01.dbf
5 153600 EXAMPLE YES /u05/oradata/ord/example01.dbf
RMAN> report schema;
Report of database schema
File K-bytes Tablespace RB segs Datafile Name
1 471040 SYSTEM YES /u05/oradata/ord/system01.dbf
2 25600 UND0TBS1 YES /u05/oradata/ord/undotbs01.dbf
3 307200 SYSAUX NO /u05/oradata/ord/sysaux01.dbf
4 10240 USERS NO /u05/oradata/ord/users01.dbf
5 153600 EXAMPLE NO /u05/oradata/ord/example01.dbf
6 10240 OE_TRANS NO /u09/oradata/ord/oe_t rans01.dbi
7 5120 USERS NO /u05/oradata/ord/users02.dbf
RMAN>
В какой-то момент времени между 3/15/04 и сегодняшним днем было создано табличное пространство OE_TRANS и добавлен еще один файл в табличное пространство USERS.
ТЕХНОЛОГИЯ ORACLE DATA GUARD
Технология Oracle Data Guard предлагает решение для обеспечения высокой доступности, повышенной производительности и автоматического преодоления последствий сбоя. Можно использовать Oracle Data Guard для создания и обслуживания нескольких резервных (standby) баз данных для основной (primary) базы данных. Резервные базы данных можно запустить в режиме “только для чтения”, чтобы поддержать создающих отчеты пользователей^ после чего эти базы снова переводятся в резервный режим. Изменения из основной базы данных могут быть автоматически переданы (relayed) в резервные базы данных с гарантией отсутствия потери данных в процессе передачи. Серверы резервных баз данных могут’ быть физически разнесены с основным сервером.
Архитектура Oracle Data Guard
В реализации Data Guard база данных, работающая в режиме ARCHIVELOG, определяется как основная база данных для приложения. Одна или несколько резервных баз данных Oracle, доступ к которым осу ществляется посредством Oracle Net, обеспечивают возможности пре одоления последствий сбоев. Технология Data Guard автоматически пе редает информацию из журналов основной базы данных в резервн базы данных, где она применяется. В результате, резервные базы ^аИН^аК оказываются транзакционно совместимыми. В зависимости от тогО^аЗЬ1 сконфигурирован прикладной процесс журнализации, резервные данных могут быть синхронизированы с основной базой данных или могут запаздывать по отношению к ней. ь1х
Данные журналов базы данных передаются в резервную базу Да t с помощью сервисов передачи журнальных файлов (Log *ranP ь Services), как это определено в установках параметров инициализ Сервисы применения журнальных файлов (Log Apply Services) ПРЙ^ор ют журнальную информацию к резервным базам данных. Третий * сервисов — сервисы управления ролями (Role Management Services) рощают процесс превращения резервной базы данных в основную.
журналов основной бадьГдадных в резервные v, базы данных
• В зависимости от того, как
Технология Oracle Data Guard
559
Сервисы передачи файлов журналов базы данных
Сервисы применения журналов базы данных
Рис. 14.1. Простая конфигурация Data Guard
Примечание Основные базы данных могут быть одиночными экземплярами или многоэкземплярными реализациями Real Application Clusters.
Физические резервные базы данных в сравнении с логическими
Поддерживаются два типа резервных баз данных — с осуществлением физического и логического резервирования. Физическая резервная база данных содержит те же самые структуры, что и основная. Логическая резервная база данных может иметь другие внутренние структуры (например, дополнительные индексы, используемые для генерации отчетов). Синхронизация основной базы данных с резервными осуществляется путем передачи журнальных данных в через SQL-операторы, выполняемые над резервной базой данных.
Физические и логические резервные базы данных преследуют разные цели. Физическая резервная база данных является поблочной копией первичной базы данных, так что она может быть использована для резервного копирования базы данных вместо основной базы данных. Во время восстановления в аварийных ситуациях резервная база данных в точности похожа на основную базу данных.
В связи с тем, что логическая база данных поддерживает дополнительные структуры данных, она может со значительно большей легкостью быть использована для поддержки конкретных требований отчетности, которые в противном случае легли бы дополнительным бременем на основную базу данных. Помимо этого, при применении логических резервных баз данных для сокращения времени простоя базы данных можно использовать так называемые скользящие обновления (rolling updates) основной и резервных баз данных. Применяемый тип резервирования зависит от преследуемых целей; во многих средах начинают с использования физических резервных баз данных для восстановления в аварийных ситуациях, а затем добавляют логические резервные базы данных для поддержки конкретных требований отчетности и ведения бизнеса.
560
Глава
Примечание Архитектуры операционной системы и платформы для основного и резервных местоположений должны быть идентичными. Структуры каталогов и уровней системных путей могут отличаться, но для облегчения процессов администрирования и преодоления последствий сбоев эти различия должны быть сведены к минимуму. Если резервная база данных размещена на том же сервере, что и основная, для этих двух баз необходимо использовать различную структуру йата. логов, и они не могут разделять каталог для архивных журналов.
Режимы защиты данных
При конфигурировании основной и резервной баз данных, необходимо определить приемлемый для предприятия уровень потери данных. В основной базе данных необходимо определить области для ее архивных журналов, причем, по меньшей мере, одна из этих областей будет ссылаться на удаленные узлы, используемые для резервных баз данных. Атрибуты ASYNC, SYNC, ARCH, LGWR, NOAFFIRM и AFFIRM установок параметра LOG_ARCHIVE_DEST__n (см. таблицу 14.1) для резервной базы данных указывают Oracle Data Guard, что необходимо сделать выбор между различными режимами функционирования:
При режиме максимальной защиты (или “нет потери данных”), по крайней мере, в одном местоположении резервной базы данных запись должна быть выполнена еще до того, как транзакция будет зафиксирована в первичной базе данных. Если отсутствует доступ к месту размещения архивного журнала резервной базы данных, основная база данных останавливается.
В режиме максимальной доступности, по крайней мере, в одном местоположении резервной базы данных должна быть выполнена запись еще до того, как транзакция будет зафиксирована в первичной базе данных. Если место размещения архивного журнала для резервной базы данных недоступно, основная база данных не останавливается. Когда ошибка будет исправлена, журнальная ин формация, которая была сгенерирована после ошибки, будет пере слана в резервную базу данных и применена к ней.
В режиме максимальной производительности (используется по умолчанию) транзакции могут быть зафиксированы еще до тоГ°’ как их журнальная информация будет послана в места располо ния резервных баз данных. Фиксирование транзакций в основ базе данных происходит сразу же после окончания операции си в локальные оперативные журналы базы данных. Записью Б^ет тах размещения резервных баз данных по умолчанию управ процесс ARCH.
После того как для конфигурации будет выбран тип резервирован**3^ режим защиты данных, можно приступить к созданию резервной данных.
Технология Oracle Data Guard
561
Атрибуты параметра LOG_AKCHIVE_DEST_n
Конфигурации Oracle Data Guard опираются на ряд атрибутов параметра LOG_ARCHIVE_DEST_n. В таблице 14.1 представлены возможные для этого параметра атрибуты. Почти во всех случаях атрибуты собраны в пары; в некоторых случаях второй член пары используется просто для обнуления установки.
Таблица 14.1. Атрибуты параметра LOG_flRCHiVE_DEST__n
Атрибут
AFFIRM и NOAFFIRM
ALTERNATE и NOALTERNATE
ARCH и LGWR
DB_UNIQUE_NAME и NODB_UNIQUE_NAME
DELAY и NODELAY
DEPENDENCY
И NODEPENDENCY
Описание
Значение AFFIRM гарантирует, что все дисковые операции ввода/вывода для архивных журнальных файлов или файлов журналов базы данных резервных баз данных в резервном пункте назначения выполняются синхронно и заканчиваются успешно еще до того, как оперативные журнальные файлы основной базы данных можно будет использовать повторно. Для достижения режима “нет потери данных” необходимо использовать AFFIRM.
NOAFFIRM указывает, что все дисковые операции ввода/вывода для архивных журнальных файлов или журнальных файлов резервных баз данных в резервном пункте назначения выполняются асинхронно; оперативные журнальные файлы основной базы данных можно использовать повторно, не дожидаясь завершения дисковых операций ввода/вывода для резервных баз данных.
Значение ALTERNATE указывает на альтернативный пункт назначения LOG_ARCHIVE_DEST_fl для использования при выходе из строя первоначального пункта назначения архивной информации.
Используемое по умолчанию значение ARCH указывает, что ответственность за пересылку журнальных данных в пункты назначения архивации несет процесс ARCH. Значение LGWR указывает, что операции пересылки журналов выполняются процессом LGWR.
Значение DB_UNIQUE_NAME указывает уникальное имя базы данных для пункта назначения.
Значение DELAY указывает на временную задержку между архивированием журнальных данных на резервном узле и их применением к резервной базе данных; может быть использовано для защиты резервной базы данных от поврежденных или ошибочных данных. Если не указано ни DELAY, ни NODELAY, по умолчанию используется значение NODELAY.
Значение DEPENDENCY позволяет передавать журнальные данные в пункт назначения, который потом будет разделять архивные файлы журналов базы данных между несколькими резервными базами данных. Если задано DEPENDENCY, следует обязательно задать REGISTER и SERVICE.
562
гпава 14
Таблица 14.1 (Продолжение)
Атрибут Описание *
LOCATION и SERVICE Для каждого пункта назначения должен быть специфицирован атрибут или LOCATION, или SERVICE. Это делается для идентификации либо локального каталога на диске (посредством LOCATION), либо пункта назначения в удаленной базе данных, где сервисы передачи журнальных файлов могут переслать журнальные данные (через SERVICE).
MANDATORY и OPTIONAL Если пункт назначения объявлен как OPTIONAL, архивирование в него может закончиться аварийно, но оперативный журнальный файл остается доступным для повторного использования и может быть, в конечном счете, перезаписан. Если операция перезаписи для пункта назначения MANDATORY аварийно заканчивается, оперативные файлы журналов базы данных не могут быть перезаписаны.
MAX-FAILURE и NOMAX_FAILURE Атрибут MAX_FAILURE специфицирует максимальное число попыток повторного открытия, прежде чем основная база передаст свои права резервной базе данных.
NETJIMEOUT и NONET_TIMEOUT Атрибут NET_TIMEOUT специфицирует количество секунд, в течение которого процесс записи в журнал для основной системы будет ожидать статуса сетевого серверного процесса, прежде чем завершить сетевое подключение. Значение по умолчанию равняется 180 сек.
QUOTA-SIZE и NOQUOTA-SIZE Атрибут QUOTA_SIZE указывает максимальное количество 512-байтовых блоков физической памяти на дисковом устройстве, которое может быть использовано локальным пунктом назначения.
QUOTA-USED и NOQUOTA_USED Атрибут QUOTA_USED идентифицирует количество 512-байтовых блоков данных, которое было архивировано на указанном пункте назначения.
REGISTER и NOREGISTER Атрибут REGISTER указывает, что место расположения архивных файлов журнала должно быть зарегистрировано на соответствующем пункте назначения.
REOPEN и NOREOPEN Атрибут REOPEN специфицирует минимальное число секунд (значение по умолчанию — 300 сек), прежде чем процесс архиватора (ARC/?) или процесс записи журнального файла (LGWR) снова попытается повторить доступ к ранее вышедше-
му из строя пункту назначения.
SYNC и ASYNC Атрибуты SYNC и ASYNC специфицируют, синхронно или асин-хронно будет выполняться при использовании процесса L сетевой ввод/вывод. Значение по умолчанию — SYNC=PARALLEL — должно быть использовано, если есть много пунктов назначения с атрибутом SYNC. Во всех пун назначения должно использоваться одно и то же значени -
TEMPLATE и NOTEMPLATE Атрибут TEMPLATE определяет спецификацию каталога и лон формата для имен архивных журнальных файлов и/ зервных журнальных файлов в резервном пункте назначе Эти атрибуты можно специфицировать в файле параметр инициализации либо для основной, либо для резервной о данных, но они применимы только к архивированию.
7"ехнология Oracle Data Guard
563
Таблица 14.1 (Продолжение)
Атрибут Описание
VALID.FOR Атрибут VALID_FOR идентифицирует, когда сервис передачи журнальных файлов может переслать журнальные данные в пункт назначения, основываясь на следующих факторах: (1) работает ли база данных в настоящий момент в роли основной или резервной базы данных и (2) архивированы ли для базы данных в этом пункте назначения оперативные журнальные файлы, резервные журнальные файлы или оба типа файлов. Значение по умолчанию для этого атрибута равно VALID_FOR=(ALL_LOGFILES, ALL_ROLES). Другие возможные значения: PRIMARY_ROLE, STANDBY_ROLE, ONLINE_LOGFILES и STANDBY_LOGFILE.
VERIFY и NOVERYFY Атрибут VERIFY указывает, что процесс архиватора должен верифицировать корректность содержимого завершенного архивного журнального файла. Значение по умолчанию NOVERIFY.
Создание конфигурации резервной базы данных
Для конфигурирования и администрирования конфигураций Data Guard можно использовать SQL*Plus, Oracle Enterprise Manager (OEM) или имеющиеся в самой Data Guard инструментальные средства. Устанавливаемые параметры будут зависеть от выбранной вами конфигурации.
Если основная и резервная базы данных размещены на одном и том же сервере, необходимо задать параметр DB_UNIQUE_NAME. Поскольку структуры каталогов для этих двух баз данных должны быть разными, необходимо либо вручную переименовать файлы, либо определить для резервной базы данных значения параметров DB_FILE_NAME_CONVERT и LOG_FILE_NAME_CONVERT. Для основной и резервных баз данных необходимо задать уникальные имена сервисов с помощью параметров инициализации SERVICE_NAMES.
Если основная и резервные базы данных находятся на различных серверах, для каждой из них можно использовать аналогичные структуры каталогов, в результате чего отпадает необходимость в использовании параметров конвертирования имен файлов. Если для файлов базы данных используются различные структуры каталогов, для резервных баз данных будет необходимо определить значения параметров DB_FILE_NAME CONVERT и LOG_FILE_NAME_CONVERT.
В физических резервных базах данных вся журнальная информация получается из основной базы данных. Если физические резервные базы данных открываются в режиме “только для чтения”, в них не генерируется никакой журнальной информации. Однако Oracle Data Guard использует архивные файлы журналов базы данных для поддержки тиражирования данных и команд SQL, используемых для обновления резервных баз данных.
564
Гпава 14
Примечание Для каждой резервной базы данных необходимо создать резервный журнальный файл для хранения журнальных данных, полученных из основной базы данных.
Подготовка основной базы данных
Находясь в основной базе данных, нужно убедиться в том, что установлены значения следующих параметров, которые оказывают влияние на передачу журнальных данных. Перечисленные ниже параметры являются стандартными для большинства баз данных. Для поддержки удаленного доступа пользователей с привилегиями SYSDBA следует установить REMOTE_LOGIN_PASSWORDFILE на EXCLUSIVE.
DB_NAME
DB_UNIQUE_NAME
SERVICE-NAMES
CONTROLJILES
REMOTE_LOGIN_PASSWORDFILE
Имя базы данных. Для основной и для всех резервных баз данных следует использовать одно и то же имя.
Уникальное имя базы данных. Это значение должно быть различным для всех резервных баз данных и должно отличаться от имени основной базы данных.
Имена сервисов для баз данных; для основной и резервных баз данных следует установить различные имена.
Места расположения управляющих файлов.
Устанавливается либо на EXCLUSIVE, либо на SHARED. Устанавливает одинаковые пароли для пользователя SYS в основной и резервных базах данных.
Перечисленные ниже связанные с LOG_ARCHTVE параметры используются для конфигурирования работы сервиса передачи журнальных фйлов:
LOG_ARCHIVE-CON FIG
LOG_ARCHIVE_DESTJ
LOG_ARCHIVE_DEST_2
LOG_ARCHIVE_DEST_STATE_1
LOG_ARCHIVE_DEST_STATE_2
LOG_ARCHIVE_FORMAT
Перечисляет основную и резервную базы данных внутри параметра DB_CONFIG.
Место расположения архивных журнальных ф< илов основной базы данных.
Удаленное место расположения, используемое для архивных журнальных файлов резервных баз данных.
Установить на ENABLE.
Установить на ENABLE, чтобы разрешить пересылку журналов.
Указать формат имен архивных журнальных айлов
Предположим, что для основной базы данных значение параметр DB_UNIQUE_NAME равно ‘headqtr’, а для физической резервной баз
Технология Oracle Data Guard
данных — ‘salesofc’. Значения параметра SERVICE-NAMES будут теми же самыми, что и у DB_UNIQUE_NAME.
Установка параметра LOG_ARCHIVE_CONFIG может выглядеть следующим образом:
□ LOG_ARCHIVE_CONFIG=’DB_CONFIG=(headqtr, salesofc)’
Есть два элемента для LOG_ARCHIVE-DEST_n: один для локальной копии архивных журнальных файлов, а второй — для удаленной копии, которая будет “отгружена” в физическую резервную базу данных:
□ LOG_ARCHIVE_DEST_1=
‘LOCATION=/arch/headqt г/
VALID_FOR-(ALL .LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=headqtr’
LOG_ARCHIVE.DEST-2=
I ‘SERVICE=salesofc
VALID_FOR=(ONLINE LOGFILES, PRIMARY ROLE)
DB_UNIQUE_NAME=salesofc’
Параметр LOG_ARCHIVE_DEST_1 специфицирует размещение архивных журнальных файлов для основной базы данных (как указано в параметре DB_UNIQUE_NAME). В параметре LOG_ARCHIVE_DEST_2 задается значение имя сервиса для физической резервной базы данных как указание на ее размещение. Для каждого из этих пунктов назначения соответствующий параметр LOG_ARCHIVE _DEST_STATE_n должен иметь значение ‘ENABLE’.
К числу связанных с ролью резерва параметров относятся параметры FAL (Fetch Archive Log — передача архивных журнальных файлов в резервную базу), использовавшиеся до Oracle Database 10gдля разрешения разрывов в диапазоне (номеров) архивных журнальных файлов, копируемых в резервную базу данных:
FAL_SERVER
FAL.CUENT
DB_FILE_NAME_CONVERT
LOG_FILE-NAME_CONVERT
STANDBY_FILE_MANAGEMEI\iT
Специфицирует имя сервиса для сервера FAL (обычно, основная база данных).
Специфицирует имя сервиса для клиента FAL (резервная база данных, принимающая журналы).
Если основная и резервная базы данных используют различающиеся структуры каталогов, параметр определяет путевые имена и имена файлов для файлов данных основной базы данных, за которыми следуют те же данные для резервной базы данных.
Если основная и резервные базы данных используют различающиеся структуры каталогов, параметр определяет путевые имена и имена файлов для журнальных файлов основной базы данных, за которыми следуют те же данные для резервной базы данных.
Установите на AUTO.
Ниже приведены примеры установок этих параметров:
566
Гпава 14
□ FAL_SERVER= headqtr
FAL_CLIENT=salofc
LOG_FILE_NAME_CONVERT= ‘/archl/headqtr/’, ‘/arch/salesofc/’, ‘/archl/headqtr/’, ‘/arch/salesofc/’
STANDBY_FILE_MANAGEMENT=AUTO
Если в настоящее время основная база данных не находится в режиме ARCHIVELOG, нужно активировать архивацию, выполнив команду alter database archivelog в тот момент, когда база данных смонтирована, но еще не открыта.
После установки связанных с журналами параметров можно приступить к созданию резервной базы данных.
Шаг 1: Копирование файлов данных основной базы данных
Нужно выполнить физическое резервное копирование основной базы данных. Специалисты из Oracle рекомендуют использовать для этой цели утилиту RMAN; находясь в среде RMAN можно использовать команду duplicate для автоматизации процесса создания резервной базы данных.
Шаг 2: Создание управляющего файла для резервной базы данных
В основной базе данных надо выполнить следующую команду для генерации управляющего файла, который будет использован для резервной базы данных:
□ alter database create standby controlfile as ‘/tmp/salesofc.ctl’;
Следует специфицировать каталог, в котором нужно создать управляющий файл, и имя, которое вы хотите ему присвоить. Кроме того, не надо использовать для них тот же самый каталог и имя, которые были заданы для основной базы данных.
Шаг 3: Создание данных файл инициализации для резервной базы
В основной базе данных создается файл параметров из файла параметров сервера:
□ create pfile=’/tmp/initsalesofc.ora’ from spfile;
Этот файл инициализации нужно отредактировать, чтобы установить в нем соответствующие значения для резервной базы данных. Надо У^1 вите (для резервной базы данных) значения параметров DB_UNIU г-NAME, SERVICE__NAMES, CONTROL-FILES, DB_FILE_NAME_CONVEK ’ LOG_FILE_NAME_CONVERT, LOG_ARCHI\Tl_DEST_n, INSTANCE FAL.SERVER и FAL.CLIENT. Конвертирование имен файлов быть точно таким же, как в основной базе данных, — когда примен журнальная информация, нужно конвертировать имена файлов из ф°г та основной базы данных в формат резервной:
□ LOG_ARCHIVE_DEST_1 =
'LOCATION=/arch/saleofc/
VALID_FOR=(ALL_LOGFILES, ALL ROLES)
Технология Oracle Data Guard
567
DB_UNIQUE_NAME=saleofc’
LOG_ARCHIVE_ DEST_2=
‘SERVICE=headqtr
VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE)
В резервной среде параметр LOG_ARCHIVE_DEST_1 указывает на пункт назначения ее локального архивного журнала, a LOG_ARCHIVE_ DEST_2 — на имя сервиса для основной базы данных. Если роли этих двух баз данных переключены, первоначальная основная база данных будет иметь возможность выступить в роли резервной базы данных. Когда резервная база данных работает в резервном режиме, параметр LOG_ ARCHIVE_DEST_2 игнорируется.
Примечание Нужно установить параметр COMPATIBLE для основной и резервных баз данных на одно и то же значение. Чтобы можно было воспользоваться преимуществами новых возможностей Oracle 10g, следует установить COMPATIBLE на 10.1.0 или на более поздние релизы. После установления COMPATIBLE на 10.1.0 уже нельзя будет установить этот параметр на более ранние релизы.
Шаг 4: Копирование файлов базы данных в место расположения резервной базы данных
Нужно скопировать файлы данных, полученные на шаге 1, управляющие файлы, полученные на шаге 2, и инициализационный файл, полученный па шаге 3, в место расположения резервной базы данных. Следует поместить все файлы в надлежащие каталоги (определенные с помощью параметров CONTROL FILES, DB_FILE_NAME_CONVERT и LOG_FILES_. NAME_CONVERT). Можно использовать RMAN для создания файлов резервной базы данных.
Шаг 5: Конфигурация среды резервной базы данных
К этому моменту все файлы данных уже на месте. Необходимо создать надлежащие переменные окружения (environment variables) и сервисы, чтобы у экземпляра появилась возможность обращаться к файлам. Так, например, в среде Windows для создания нового сервиса следует использовать утилиту ORADIM:
□ ORADIM -NEW -SID saleofc -INTPWD oracle -STARTMODE MANUAL
После этого нужно создать файл паролей для резервной базы данных с помощью утилиты ORAPWD (см. главу 2).
Затем следует создать параметры и сервисы Oracle Net, требующиеся для доступа к резервной базе данных. В файле sqlnet.ora сервера резервной базы данных нужно задать параметр SQLNET.EXITRE TIME равным 1, чтооы акт ивировать обнаружение разорванных соединений по истечении одной минуты (подробнее о подключениях по Oracle Net см. главу 16).
Потом нужно создать в файле tnsnames.ora элемент имени сервиса для резервной базы данных, после чего распространить это обновление на серверы основной и резервной баз данных.
568
Гпава 14
И, наконец, надо создать файл параметров сервера с помощью комащ ды create spfile from pfile, передав на вход этой команды имя и размещу ние файла параметров резервной базы данных.
Шаг 6: Запуск резервной базы данных
Из SQL*Plus нужно запустить резервную базу данных в режиме “только для чтения”:
□ startup open read only;
Примечание Во временных табличных пространствах резервной базы данных можно добавлять новые временные файлы. Добавление этих файлов служит для поддержки операций сортировки, необходимых для формирования отчетов в резервной базе данных.
Запустить процесс применения журналов в резервной базе данных нужно с помощью следующей команды:
□ alter database recover managed standby database disconnect from session;
Шаг 7: Верификация конфигурации
Для тестирования конфигурации следует вернуться к основной базе данных и форсировать переключение журналов с помощью следующей команды alter system:
□ alter system switch logfile;
После этого данные из файлов журналов основной базы данных должны быть скопированы в резервную базу данных.
Находясь в резервной базе данных, можно сделать запрос к представлению V$ARCHIVED JLOG, чтобы узнать, какие архивные журналы должны быть применены к базе данных. По мере того, как из основной базы данных будут получаться новые журналы и применяться к резервной базе данных, к листингу представления V$ARCHI\rED_LOG будут добавляться новые строки.
Создание логических резервных баз данных
Логические резервные базы данных следуют большинству шагов, исП°^ зуемых при создании физических резервных баз данных. Поскольку опираются на повторение выполнения команд SQL, логические Ре^с^р1 ные базы данных имеют больше ограничений при их пРименений' п111е в какой-либо из таблиц основной базы данных используются следу типы данных, они будут пропущены при выполнении процесса при ния журналов (redo application process):
BFILE
ROWID
и UROWID
Технология Oracle Data Guard
569
и Определенные пользователем типы данных
и Объектные типы
и REF
Массивы переменной длины
Вложенные таблицы
и Тип данных XMLtype
В дополнение использующие компрессирование таблицы и инсталлированные с помощью программного обеспечения Oracle схемы также будут пропущены при применении журналов. В представлении DBA_ LOGSTDBY_UNSUPPORTED перечисляются объекты, не поддерживаемые для логических резервных баз данных. В представлении DBA__ LOGSTDBYjSKIP перечисляются пропускаемые схемы.
Логическая резервная база не идентична основной базе данных. Каждая транзакция, выполняемая в логической резервной базе данных, должна быть логическим эквивалентом транзакции, выполняемой в основной базе данных. Следовательно, необходимо быть уверенным, что на таблицы наложены соответствующие ограничения — первичные ключи, ограничения уникальности ключей, цроверочные ограничения целостности и ограничения внешнего ключа — с тем, чтобы надлежащие строки можно сделать мишенями для обновления в логической резервной базе данных. Для получения перечня таблиц основной базы данных, в которых не хватает первичных ключей или ограничений по уникальности, можно воспользоваться представлением DBA__LOGSTDBY_NOT_UNIQUE.
Для создания логической резервной базы данных нужно выполнить следующие шаги.
Шаг 1: Создание физической резервной базы данных
Следуя шагам, описанным в предыдущем разделе, нужно создать физиче-скую резервную базу данных.
Шаг 2: Активизация дополнительной журнализации
Дополнительная журнализация в основной базе данных генерирует до-полнительную информацию в журнале. Затем эта информация используется во время выполнения процесса применения журналов в резервной базе данных, чтобы быть уверенным в том, что сгенерированный SQL затронул только требующиеся строки. Для добавления информации о первичных ключах и ограничениях уникальности к журнальным данным, в основной базе данных нужно выполнить следующую команду:
Biter database add supplemental log data
(primary key, unique index) columns;
Можно проверить, включена ли дополнительная журнализация, задав запрос к столбцам Supplemental_Log_Data_PK и Supplemental Log_Data_ UI представления V$DATABASE. Эти столбцы принимают значения YES/NO и указывают, включена ли журнализация.
570
Гпава 14
Шаг 3: Переход от физического к логическому резервированию
Физические резервные базы данных действуют в режиме “только для чтения”; логические резервные базы данных открыты для записи и генериру. ют собственную журнальную информацию. В файле параметров инициализации для логической резервной базы данных следует указать пункты назначения для журнальных данных логической резервной базы данных (LOG_ARCHIVE_DEST_1) и входящей журнальной информации из основной базы данных (в этом примере будет использован пункт назначения LOG_ARCHIVE_DEST_3, для того чтобы избежать конфликта с ранее использованным значением установки LOG_ARCHIVE_DEST_2). Не нужно, чтобы логическая резервная база данных имела активированный пункт назначения LOG_ARCHIVEJDEST_2, который указывает на основную базу данных.
Надо остановить логическую резервную базу данных. В основной базе данных следует создать логический резервный управляющий файл, как показано в следующем ниже листинге (убедитесь, что в команде alter database использована фраза logical standby):
□ alter database create logical standby controlfile as ‘/tmp/saleofc.ctl’;
Этот файл нужно скопировать на сервер резервной базы данных.
Шаг 4: Запуск логической резервной базы данных
Нужно запустить и смонтировать логическую резервную базу данных, используя файл параметров инициализации. Когда база данных смонтирована, следует подготовить базу данных для выполнения процесса применения журналов с помощью команды alter database. В смонтирован ной логической резервной базе данных надо выполнить следующую команду:
□ alter database recover managed standby database;
В рамках того же самого сеанса нужно активировать логическую ре зервную базу данных:
□ alter database activate standby database;
После этого следует выключить логическую резервную базу даннЫ> а затем запустить и смонтировать базу данных, не открывая се.
Шаг 5: Задание нового имени базы данных для логической резервной базы данных
Для автоматизации процесса изменения имени логической резерв базы данных Oracle предлагает утилиту DBNEWID.
Примечание Эту утилиту следует выполнять только для логической Ре3 базы данных.
Технология Oracle Data Guard
571
Выполняемый модуль утилиты DBNEWID называется nid. Пока логическая резервная база данных смонтирована, но не открыта, нужно выполнить следующее:
О nid TARGET=sys/password@salesofc DBNAME=salesofc
Утилита DBNEWID будет отображать выполняемые ей операции, включая изменение внутреннего идентификатора и имени базы данных. По завершении работы утилиты следует создать новый файл паролей с помощью утилиты ORAPWD.
Для завершения шагов по переименованию базы данных необходимо отредактировать файл параметров инициализации (модифицировать DB_NAME), а затем создать из этого файла новый файл параметров сервера (с помощью команды create spfile from pfile). После этого можно запустить и открыть логическую резервную базу данных:
□ startup nomount;
alter database open resetlogs;
Поскольку база данных была переименована, необходимо заново установить параметр глобального имени с помощью команды alter database:
□ alter database rename global_name to saleofc;
Если ожидается, что в логической резервной базе данных будут выполняться большие сортировки, во временных табличных пространствах резервной базы данных необходимо создать дополнительные временные файлы.
Шаг 6: Запуск процесса применения журналов
В среде логической резервной базы данных можно теперь запустить про-цесс применения журналов:
О alter database start logical standby apply;
Чтобы увидеть, что журналы получены и применены к логической резервной базе данных, нужно сделать запрос к представлению DBA_ LOGSTDBY_LOG. Можно также сделать запрос к представлению V$LOGSTDBY, чтобы увидеть протокол активности процесса применения журналов логической резервной базы данных. Теперь логическая резервная база данных готова к использованию.
Чримеиение r@al-tim@ Apply
По умолчанию журнальные данные не применяются к резервной базе Данных до тех пор, пока не будет архивирован резервный журнал базы Данных. Но если используется опция применения (журналов) в реальном времени (real-time apply), журнальные данные применяются к резервной базе данных сразу же после того, как они были получены, что позволяет сократить временную задержку между базами данных и потенциально сократить время, требующееся для переключения на резервную базу Данных.
572
Гпава у
Для разрешения применения журналов в реальном времени в физике ской резервной базе данных нужно выполнить в ней следующую команду.
□ alter database recover managed standby database using current logfile;
Для логической резервной базы данных команда имеет следующий вид:
□ alter database start logical standby apply immediate; e
Если разрешено применение журналов в реальном времени, то в столбце Recovery_Mode представления V$ARCHIVEJDESTJSTATUS бу дет содержаться значение ‘MANAGED REAL-TIME APPLY’.
Разрешить применение журналов для физической резервной базы данных можно с помощью команды:
□ alter database recover managed standby database disconnect from session;
Фраза disconnect from session позволяет выполнять команду в фоновом режиме после отключения от сеанса Oracle. Если запустить высокоприоритетный сеанс и выполнить ту же самую команду без фразы disconnect from session, управление не будет возвращено в строку приглашения на ввод команды, пока восстановление не будет отменено другим сеансом. Чтобы остановить применение журналов в физической резервной базе данных — неважно, в фоновом или в высокоприоритетном сеансе, нужно использовать следующую команду:
□ alter database recover managed standby database cancel;
Для логической резервной базы данных команда прекращения сервиса применения журналов имеет вид:
□ alter database stop logical standby apply;
Управление пропусками в последовательности архивных журналов
Если резервная база данных не получила один или несколько архивных журналов, сгенерированных основной базой данных, она не будет имет® полного перечня транзакций в основной базе данных. Технология Ога Data Guard автоматически обнаруживает пропуски в последовательное архивных журналов; эта проблема разрешается путем копирования достающих журнальных файлов в резервные пункты назначения. явления Oracle 10g для этой цели использовались клиент и сервер (Fetch Archive Log — передача архивных журнальных файлов в рез нуюбазу). ой
Для определения, имеются ли пропуски в физической Ре3£р£др. базе данных, нужно сделать запрос к представлению V$ARCHIу Для каждого пропуска это представление регистрирует нижнии и пий порядковые номера журнальных файлов, пропущенные в рс пой базе данных. Если обнаруживаются какие-либо причины, по v рым Oracle Data Guard оказывается не в состоянии скопировать .. Файлы, можно вручную скопировать их в среду физической резерв
Технология Oracle Data Guard
573
базы данных и зарегистрировать с помощью команды alter database register logfile имя_файла; после этого можно запустить процесс применения журналов. После применения журналов нужно проверить представление V$ARCHIVE_GAP еще раз, чтобы убедиться, не осталось ли еще каких-то необнаруженных пропусков.
Управление ролями — плановые и внеплановые переключения
Каждая принимающая участие в конфигурации Data Guard база данных имеет роль — она является либо основной, либо резервной базой данных. В некоторые моменты бывает необходимо поменять эти роли. Например, если па сервере основной базы данных произошел отказ оборудования, можно переключиться на резервную базу данных. В зависимости от заложенных при конфигурировании выборов при таком переключении может иметь место некоторая потеря данных.
Второй тип переключения ролей называется плановым переключением (switchover). Оно происходит, когда основная база данных меняется ролями с резервной базой данных, и резервная база данных становится новой основной базой данных. Во время планового переключения не должно быть никакой потери данных. При плановых и внеплановых переключениях требуется ручное вмешательство администратора базы данных.
Плановые переключения
Плановые переключения, или плановые изменения ролей, обычно используются для обслуживания, выполняемого на сервере основной базы данных. Резервная база данных назначается “исполняющей обязанности” основной базы данных, происходит переключение, и приложения начинают записывать данные в новую основную базу данных. В какой-то последующий момент времени можно произвести обратное переключение баз данных, при котором им будут возвращены первоначальные роли.
Примечание Плановые переключения можно производить как с логической, так и с физической резервными базами данных. Предпочтительным является использование физического резервирования.
А что делать, если было определено несколько резервных баз данных? Когда одна из физических резервных баз данных становится основной, остальные базы данных должны быть в состоянии получать журнальные данные из новой основной базы данных. В такой конфигурации необходимо определить параметры LOG__ARCHIVE_DEST_n, чтобы позволить этим резервным узлам получать данные из места размещения новой основной базы данных. **
** О О ЛЧ 1*4 П О • 1 в том, что база данных, которая стала новой
основной базой данных, функционирует в режиме ARCHIVELOG.
574
Глава 14
До начала переключения резервная база данных должна активно применять журнальные данные, так как это позволяет минимизировать время, требующееся для завершения планового переключения.
Плановое переключение к физической резервной базе данных
Плановые переключения инициируются в основной базе данных и завершаются в резервной базе данных. В этом разделе мы покажем шаги для выполнения планового переключения к физической резервной базе данных.
Нужно начать с проверки того, способна ли основная база данных выполнить плановое переключение. Задайте запрос к представлению V$DATABASE, чтобы получить значение столбца Switchover_Status:
П select Switchover_Status from V$DATABASE;
Если значение столбца Switchover_Status любое другое, кроме ТО STANDBY, выполнить плановое переключение невозможно (обычно, из-за проблем, связанных с конфигурацией или оборудованием). Если значение столбца равно SESSION ACTIVE, необходимо сначала закончить все активные сеансы пользователей. Допустимые значения столбца Switchover_status показаны в таблице 14.2.
Таблица 14.2. Значения столбца SwitchoverJStatus
Значения Switchover Status Описание
NOT ALLOWED
PREPARING DICTIONARY
PREPARING SWITCHOVER
RECOVERY NEEDED
SESSIONS ACTIVE
SWITHOVER PENDING
SWITCHOVER LATENT
TO LOGICAL STANDBY
TO PRIMARY
TO STANDBY
Текущая база данных не является основной базой данных с резервной базой данных.
Эта логическая резервная база данных посылает свои журнальные данные в основную базу данных и остальные резервные базы данных для подготовки планового переключения.
Используется в логических резервных конфигурациях, когда журнальные данные принимаются для планового переключения.
Эта резервная база данных не получила запроса на плановое переключение.
В основной базе данных имеются активные сеансы SQL; они должны быть отключены перед продолжением.
Является допустимым для резервных баз данных, в которых запрос на плановое прроиг;ючение из основной базы данных был получен, но не обработан.
Плановое переключение не было завершено и было возвращено к основной базе данных.
Основной базой данных был получен полный словарь из логической резервной базы данных.
Данная резервная база данных может переключаться к роли основной базы данных.
Данная основная база данных может переключаться к роли резервной базы данных.
Технология Oracle Data Guard
575
Находясь в основной базе данных, можно инициировать ее переход к роли физической резервной базы данных с помощью следующей команды:
П alter database commit to switchover to physical standby;
Как часть выполнения этой команды Oracle скопирует управляющий файл текущей основной базы данных в трассировочный файл. В этот момент необходимо остановить основную базу данных и смонтировать ее:
□ shutdown immediate; startup mount;
Основная база данных подготовлена к плановому переключению; теперь необходимо перейти к физической резервной базе данных, которая будет работать в качестве повой основной базы данных.
В физической резервной базе данных надо проверить статус переключения в представлении V$DATABASE; этот статус должен быть равен ТО PRIMARY (см. таблицу 14.2). Теперь можно переключиться к основной базе данных с помощью следующей команды:
□ alter database commit to switchover to primary;
Следует остановить и запустить заново базу данных, и она завершит свой переход к роли основной базы данных. После запуска базы данных нужно форсировать переключение журналов посредством команды alter system switch logfile, а затем запустить сервис применения журналов (redo apply) на резервных базах данных, если только они уже не работают в фоновом режиме.
Плановые переключения к логическим резервным базам данных
Плановые переключения инициируются в основной базе данных, а завершаются в резервной базе данных.
Нужно начать с проверки того, способна ли основная база данных выполнить плановое переключение. Следует задать запрос к представлению V$DATABASE для определения значения столбца Switchover_Status:
□ select Switchover_Status from V$DATABASE;
Для завершения планового переключения статус должен иметь одно из следующих значений: ТО STANDBY, ТО LOGICAL STANDBY или SESSIONS ACTIVE.
В основной базе данных нужно выполнить следующую команду, чтобы подготовить ее к плановому переключению:
□ alter database prepare to switchover to logical standby;
В логической резервной базе данных надо выполнить следующую команду:
О alter database prepare to switchover to primary;
576
Гпава 14
Теперь логическая резервная базе данных начинает передавать свои журнальные данные в текущую основную базу данных и в остальные резервные базы данных конфигурации. В этот момент журнальные данные из логической резервной базы данных посылаются, но не применяются.
Теперь необходимо в основной базе данных проверить, что из логической резервной базы данных получены словарные данные. В столбце Switchover_Status представления V$DATABASE для основной базы данных должно содержаться значение ТО LOGICAL STANDBY. Только при выполнении этого условия можно перейти к следующему шагу. Когда для основной базы данных будет отображено именно это значение столбца, нужно переключить ее на роль логической резервной базы данных:
□ alter database commit to switchover to logical standby;
Нет необходимости останавливать и запускать заново старую основную базу данных. Теперь следует перейти обратно к первоначальной логической резервной базе данных и проверить для нее значение столбца Switchover_Status представления V$DATABASE (там должно быть ТО PRIMARY). После этого можно закончить плановое переключение; в первоначальной резервной базе данных выполните следующую команду:
□ alter database commit to switchover to primary;
Теперь первоначальная резервная база данных становится основной. В новой основной базе данных нужно выполнить переключение журналов:
□ alter system archive log current;
В новой логической резервной базе данных (т. е. в старой основной базе данных) следует запустить процесс применения журналов:
□ alter database start logical standby apply;
На этом плановое переключение завершено.
Внеплановые переключения к физической резервной базе данных
Внеплановые переключения (failovers) происходят, когда основная база данных более не может быть частью конфигурации Data Guard.
Находясь в резервной базе Данных, необходимо сначала попытаться идентифицировать и разрешить все проблемы с пропуском архивнь журнальных файлов (см. выше в данной главе). Возможно, для использо вания резервной базы данных придется вручную копировать и регистр ровать журнальные файлы.
Технология Oracle Data Guard
577
Затем необходимо закончить процесс восстановления в среде резервной базы данных. Если в свое время резервная база данных была сконфигурирована с резервными журнальными файлами, соответствующая команда будет иметь вид:
□ alter database recover managed standby database finish;
Если резервных журнальных файлов нет, нужно выполнить следующую команду:
□ alter database recover managed standby database finish skip standby logfile;
После того как операция восстановления резерва закончена, можно выполнить переключение, используя для этого следующую команду:
□ alter database commit to switchover to primary;
Для завершения переключения следует остановить и снова запустить новую основную базу данных. Старая основная база данных более не является частью конфигурации Data Guard. Если же требуется повторно создать старую основную базу данных ц использовать ее как резервную, необходимо пересоздать ее как резервную базу данных, следуя шагам, описанным выше в данной главе.
Внеплановые переключения к логической резервной базе данных
Внеплановые переключения (failovers) происходят, когда основная база данных более не может быть частью конфигурации Data Guard. В этом разделе будут показаны шаги, требующиеся для переключения логической резервной базы данных на роль основной базы данных в конфигурации Data Guard.
Находясь в резервной базе данных, необходимо сначала попытаться идентифицировать и разрешить все проблемы с пропуском архивных журнальных файлов (см. выше в данной главе). Возможно, для использования резервной базы данных придется вручную копировать и регистрировать журнальные файлы. Нужно задать запрос к представлению DBA_ LOGSTDBY.LOG, чтобы определить детали того, какие журналы еще осталось применить. Если в логической резервной баз^ не был активен процесс применения журналов, его надо запустить, используя следующую команду:
alter database stop logical standby apply nodelay finish;
578
Гпава 14
Затем нужно активировать удаленные места расположения файлов журналов базы данных, которые генерирует логическая резервная база данных. Возможно, придется обновить для логической резервной базы данных установки параметра ARCHIVE__DEST_STATE_n, так чтобы прочие резервные базы данных в конфигурации получали журнальную информацию, сгенерированную первоначальной логической резервной базой данных. Впоследствии можно будет активировать первоначальную логическую резервную базу данных как новую основную базу данных с помощью следующих команд:
П alter database stop logical standby apply;
alter database activate logical standby database;
Если есть другие логические резервные базы данных, являющиеся частью конфигурации Data Guard, может потребоваться заново создать их или использовать для добавления их к новой конфигурации связи баз данных. Сначала нужно создать связь в каждой из баз данных, которые будут играть роль логических резервных баз данных по отношению к новой основной базе данных. Команда alter session disable guard позволит вам обойти процессы Data Guard в рамках сеанса. Учетная запись базы данных, использованная в связи баз данных, должна иметь роль SELECT-CATALOG_ROLE:
□ alter session disable guard; create database link salesofc
connect to имя_пользователя identified by password using salesofc ; alter session enable guard;
Необходимо проверить связь, задав запрос на выборку из представления DBA_LOGSTDBY_PARAMETES из удаленной базы данных (новая основная база данных).
В каждой логической резервной базе данных теперь можно запустить процесс применения журналов на базе новой основной базы данных:
□ alter database start logical standby apply new primary saleso c;
Администрирование баз данных
Ниже будут показаны шаги, необходимые для выполнения стандартных действий по обслуживанию баз данных, являющихся частью конф гуРа ции Data Guard, включая операции запуска и остановки.
Запуск и остановка физической резервной базы данных
Если производится запуск физической резервной базы данных, не0°* димо произвести запуск процесса применения журналов. Во-первых, i) но смонтировать базу данных:
□ startup mount;
Затем надо запустить процесс применения журналов:
□ alter database recover managed standby database disconnect from session;
Технология Oracle Data Guard
579
Для запуска процесса применения журналов в реальном времени (realtime apply) вместо фразы disconnect from session следует использовать фразу using current logfile.
Для остановки резервной базы данных нужно сначала остановить сервис применения журналов. Нужно задать запрос к представлению V$MANAGED_STANDBY; если в нем будет перечислен сервис применения журналов, его надо уничтожить, используя следующую команду:
□ alter database recover managed standby database cancel;
После этого можно остановить базу данных.
Открытие физической резервной базы данных в режиме “только для чтения”
I «
VTTo6bi сделать физическую резервную базу данных открытой для операций чтения, следует сначала отменить в базе данных любые операции по применению журналов:
□ alter database recover managed standby database cancel;
Затем надо открыть базу данных:
□ alter database open;
Управление файлами данных в среде Data Guard
Необходимо установить параметр инициализации STANDBY-FILE-MANAGEMENT на AUTO. Установка этого параметра упрощает администрирование среды Data Guard, потому что файлы, добавленные в основную базу данных, могут быть автоматически скопированы во все резервные базы данных. В тех случаях, когда этот параметр установлен на AUTO, любые новые файлы данных, созданные в основной базе данных, будут автоматически создаваться в резервных базах данных; если же он установлен на MANUAL, придется вручную создавать новые файлы данных в резервных базах данных.
Если параметр STANDBY_FILE_MANAGEMENT установлен на MANUAL, для добавления новых файлов данных к табличным пространствам нужно придерживаться следующих шагов:
Я*
1. Добавьте новый файл данных в основную базу данных.
2. Переведите табличное пространство для этого файла в автономный режим.
3. Скопируйте файл данных в резервное место расположения.
4. Снова переведите табличное пространство для этого файла в оперативный режим.
Для добавления новых табличных пространств с использованием ручного управления файлами нужно следовать тем же самым шагам — сначала создать новое хабличное пространство, перевести его в автономный ре
580
Гпава 14
жим, скопировать входящие в него файлы данных в резервное место раз-мещения, а затем перевести табличное пространство в оперативный режим. Если же используется автоматическое управление файлами, необходимо только создать в основной базе данных табличное пространство, после чего оно будет автоматически распространено во все резервные базы данных.
Для удаления табличного пространства нужно просто удалить его из основной базы данных и форсировать переключение журналов с помощью команды alter system switch logfile. После этого можно удалить файл на уровне операционной системы в средах основной и резервных баз данных.
Изменения в именах файлов данных не распространяются, даже если используется автоматическое управление файлами. Для переименования файла данных в конфигурации Data Guard нужно перевести табличное пространство в автономный режим и переименовать этот файл на уровне операционной системы на основном сервере. Следует использовать команду alter tablespace rename datafile для основной базы данных, чтобы указать на новое место нахождения файла данных. Табличное пространство нужно вернуть в оперативный режим с помощью команды alter tablespace и^^пгабличного_пространства online. В резервной базе данных надо задать запрос к представлению V$ARCHIVEDJLOG для проверки того, все ли журналы были применены, а затем закрыть сервис применения журналов:
□ alter database recover managed standby database cancel;
Остановите резервную базу данных и переименуйте файл на резервном сервере. Затем используйте команду startup mo^nt, чтобы смонтировать резервную базу данных. При смонтированной и открытой базе данных используйте команду alter database rename file, чтобы указать на размещение нового файла на резервном сервере. Наконец, перезапустите процесс применения журналов:
□ alter- database recover managed standby database disconnect from session;
Выполнение DDL для логической резервной базы
Можно временно запретить Data Guard внутри логической резервной базы данных. Когда необходимо выполнить операции DDL (например, создание новых индексов для повышения производительности запр сов), нужно следовать тем же самым основным шагам:
1. Остановите применение журналов в логической резервной оаз данных.
2. Отключите Data Cuard
3. Выполните команды DDL.
4. Включите Data Guard.
5. Перезапустите процесс применения журналов.
Технология Oracle Data Guard
581
Например, для создания нового индекса нужно начинать с отключения возможностей Data Guard:
□ alter database stop logical standby apply; alter session disable guard;
После этого можно выполнить требующиеся операции DDL. Когда они будут выполнены, нужно снова восстановить возможности Data Guard:
□ alter session enable guard;
alter database start logical standby apply;
Логическая резервная база данных после этого перезапустит процесс применения журналов, причем новый индекс будет доступен пользователям запросов.
ГЛАВА 15
РАЗЛИЧНЫЕ ОПЦИИ
ПОВЫШЕНИЯ ДОСТУПНОСТИ
В этой главе будут показаны детали реализации возможностей, которые в значительной степени повышают доступность приложений баз данных. Некоторые из этих возможностей, например опция LogMiner, являются просто усовершенствованиями возможностей, ставших доступными еще в прошлых, более ранних версиях Oracle. Другие же, например применение “Корзины” (recycle bin) и команды flashback database, появились только в Oracle Database 10g. В этой главе рассматриваются следующие опции:
Flashback Table для отмены удаления таблиц или для восстановления их в предшествующем состоянии
Flashback Database (ретроспективный откат базы данных)
LogMiner
Опции оперативной реорганизации объектов
Команда flashback table
Команда flashback table (ретроспективный откат таблицы) восстанавли вает предыдущее состояние таблицы при ошибке оператора или пРи^°е жения. При восстановлении предыдущего состояния таблицы может “перешагнуть” через выполненную над таблицей операцию D которая изменила структуру таблицы.
Примечание Чтобы команда flashback table to timestamp/SCN могла рабе база данных должна применять опцию Automatic Undo Management (AUM — y магическое управление пространством отката). Возможность возврата к прош (именно так переводится английское выражение flash back. —Прим, пер.) —в ном случае к прошлым данным — ограничивается объемом информации для та, сохраняемой в табличном пространстве отката, и заданной установкой знач параметра инициализации UNDO RETENTION. __
Различные опции повышения доступности
583
Оператор flashback table не поддается откату. Однако можно выполнить другой оператор flashback table, указав в нем время, непосредственно предшествующее текущему времени.
Примечание Прежде чем выполнять команду flashback table to timestamp/SCN, # следует зафиксировать системный номер изменений (SCN).
Требующиеся привилегии
Нужно иметь либо объектную привилегию FLASHBACK на таблицу, либо системную привилегию FLASHBACK ANY TABLE. Кроме того, следует иметь объектные привилегии SELECT, INSERT, DELETE и ALTER для таблицы. Для всех таблиц в списке ретроспективы (flashback list) должно быть разрешено перемещение строк (row movement). Для возврата таблицы к состоянию на момент времени перед выполнением операции drop table нужны те же самые привилегии, что и для удаления таблицы.
Восстановление удаленных таблиц
Рассмотрим таблицу AUTHOR:
□ describe AUTHOR
Name
AUTHORNAME COMMENTS
Null? Type
NOT NULL VARCHAR2(50)
VARCHAR2(1OO)
Предположим теперь, что эта таблица случайно удалена. Это обычно происходит, когда привилегированный пользователь намеревается удалить таблицу из среды разработки/тестировапия, но при выполнении команды указывает на промышленно эксплуатируемую базу данных.
О drop table AUTHOR cascade constraints;
Table dropped.
Как может быть восстановлена такая таблица? Начиная с Oracle Database 10g, удаленная таблица не исчезает полностью. Ее блоки продолжают оставаться в том табличном пространстве, где она была размещена, и продолжают засчитываться в квоту дискового пространства для пользователя. Удаленные объекты можно увидеть, если задать запрос к представлению RECYCLEBIN словаря данных. Формат столбца Object_Name может быть разным для различных версий:
О select * from RECYCLEBIN;
OBJECT_NAME ORIGINAL-NAME OPERATION
TYPE TS-NAME CREATETIME
DROPTIME DROPSCN PARTITION-NAME CAN CAN
584
Гпава is
RELATED BASE.OBJECT PURGE_OBJECT SPACE
RB$$48448$TABLE$0
TABLE
2004-02-25:14:30:23 48448 48448
RB$$48449$INDEX$0 INDEX 2004-02-25:14:30:23 48448 48448
AUTHOR
USERS
720519
48448 8
SYS_C004828
USERS
720516
48449 8
DROP 2004-02-23:16:10:58
YES YES
DROP 2004-02-23:16'10’58
NO YES
Имя RECYCLEBIN является публичным синонимом представления словаря данных USER_RECYCLEBIN, показывающего записи корзины для текущего пользователя. Все удаленные объекты можно увидеть с помощью представления словаря данных DBA_RECYCLEBIN.
Как показано в предыдущем листинге, Oracle удалил таблицу AUTHOR и связанный с ней индекс по первичному ключу. Хотя они были удалены, они все еще остаются доступными для ретроспективы. Листинг корзины показывает SCN команды, которая удалила базовый объект. В этом примере у базовой таблицы значение идентификатора объекта (object ID) равно 48448. У связанного с ней индекса по первичному ключу значение идентификатора равно 48449. В столбце Base_Object записи корзины для индекса показан идентификатор объекта (48448) для его (индекса) базового объекта (таблицы AUTHOR). Индекс не может быть восстановлен сам по себе (в его столбце Can_Undrop содержится значение ‘NO’), в то время как значение столбца CanJUndrop для таблицы AUTHOR равно ‘YES’.
Для восстановления таблицы из корзины можно использовать команду flashback table to before drop:
□ flashback table AUTHOR to before drop;
Flashback complete.
Таблица будет восстановлена вместе со всеми своими строками, ин дексами и статистическими показателями.
Что произойдет с таблицей AUTHOR, если удалить ее, создать заново и снова удалить? В корзине будут содержаться два экземпляра таблииьь Каждая запись в корзине будет идентифицироваться своим собственнь SCN и отметкой времени удаления.
Примечание Команда flashback table to before drop не восстанавливает ограни
чения ссылочной целостности. ___
Для очищения корзины от старых записей используется коМ purge. Можно “вычистить” все удаленные объекты пользователя, ₽се екты базы данных (если пользователь — АБД), все объекты из конкре го табличного пространства или все объекты из конкретного табли^н^ пространства для конкретного пользователя. Команду purge можно
г
Различные опции повышения доступности 585
I
В ти в Алфавитном справочнике, где приведен полный синтаксис команды и ее опции.
Для переименования таблицы одновременно с ее ретроспективным В откатом можно использовать фразу rename to команды flashback table.
Ретроспективный откат до SCN или отметки времени
В Для показа данных в их состоянии на какой-то момент времени в про- шлем или какой-то SCN можно использовать так называемый ретроспек- I тивный запрос (flashback query). Фраза as of timestamp команды select ис-
I пользует данные из управляемых автоматически сегментов отката, чтобы показать строки в том виде, какими они были в указанное время.
Результаты ретроспективного запроса можно сохранить в отдельной Я таблице, причем основная таблица останется незатронутой. Кроме того, можно изменять строки таблицы, основываясь на результатах ретроспективного запроса. Команду flashback table можно использовать для преобразования таблицы в ее предыдущую версию — то есть стереть изменения, сделанные после заданного момента ретроспекции.
Во время операции flashback table Oracle запрашивает монопольную блокировку DML на все специфицированные таблицы. Команда выполняется в рамках одной транзакции для всех таблиц; если аварийно заканчивается одна из них, весь оператор считается закончившимся аварийно. Можно ретроспективно откатить таблицу до конкретного SCN или отметки времени.
Примечание При выполнении команды flashback table to sen или to timestamp не сохраняются RowlD.
Приведенная ниже команда update пытается обновить одну строку в таблице AUTHOR. Однако в операторе update не специфицирована фраза where, и в результате все строки таблицы модифицируются одним и тем же комментарием, после чего эти изменения фиксируются.
□ update AUTHOR
set Comments = ‘ILLUSTRATOR OF BOOKS FOR CHILDREN’;
commit; •
В этом случае известно, что почти вся таблица содержит некорректные данные и какая транзакция была ошибочной. Для получения правильных данных можно выполнить ретроспективный откат базы данных к некоторому предшествующему времени, а затем применить новые команды, необходимые для того, чтобы “довести” данные до актуального состояния.
Сначала нужно убедиться в том, что известен текущий SCN на тот случай, если потребуется вернуться к этому моменту:
О commit;
variable SCN_FLASH number;
execute :SCN_FLASH : =DBMS__FLASHBACK. GET_SYSTEM_CHANGE_NUMBER;
586
Глава 15
PL/SQL procedure successfully completed.
print SCN-FLASH
SCN_FLASH
720880
Теперь выполним ретроспективный откат ко времени непосредственно перед обновлением таблицы. Сначала нужно разрешить таблице перемещение строк:
П alter table AUTHOR enable row movement;
Table altered.
После этого можно ретроспективно откатить таблицу до некоторого SCN или отметки времени:
□ flashback table AUTHOR to sen (720000)
Если требуется применять не SCN, а отметку времени, можно использовать фразу to timestamp:
□ flashback table AUTHOR to (systimestamp-5/1440);
Примечание Когда для таблицы выполняется ретроспективный откат, ее статистические показатели не подвергаются ретроспективному откату. Существовавшие для таблицы индексы реверсируются и отображают состояние таблицы на момент ретроспекции. Индексы, созданные после момента ретроспекции, продолжают существовать и также будут обновлены, чтобы они отражали более старые данные.
Команда flashback database
Команда flashback database (ретроспективный откат базы данных) возвращает базу данных к прошедшему времени или SCN, предлагая быструю альтернативу выполнению неполного восстановления базы данных. Вслед за выполнением операции flashback database, чтобы получить быстрый доступ к ретроспективно откаченной (восстановленной) базе дан ных, ее необходимо заново открыть, используя команду alter database open resetlogs. Чтобы выполнить команду flashback database, необходи мо иметь системную привилегию SYSDBA.
Примечание База данных должна быть помещена в режим FLASHBACK с щью команды alter database flashback on. При выполнении этой команды баз д ных должна быть смонтирована в монопольном режиме, но не открыта.
Синтаксис команды flashback database выглядит следующим образов
□ flashback [standby] database [имя_БД]
{ to sen | timestamp} выражение
| to before sen | timestamp } выражение
Различные опции повышения доступности
587
Для задания момента, на который должна быть ретроспективно отображена вся база данных, можно использовать любую из фраз to sen или to timestamp. Можно выполнить откат на момент перед (to before) критической точкой (например, перед транзакцией, вызвавшей непреднамеренные последствия для множества таблиц). Псевдостолбец ORA_ ROWSCN используется для того, чтобы узнать SCN транзакции, которая была последней, воздействовавшей на строки.
Если это не было уже сделано ранее, необходимо остановить базу данных и активировать ретроспекцию во время процесса запуска:
□ startup mount exclusive;
alter database archivelog;
alter database flashback on;
alter database open;
Примечание Перед выполнением команды alter database flashback on необходимо активировать восстановление носителей с помощью команды alter database archivelog.
Две установки параметров инициализации контролируют, как много ретроспективных данных сохраняется в базе данных. Параметр инициализации DB_FI_ASHBACK_RETENTION_TARGET устанавливает верхний предел (в минусах) для того, насколько далеко назад по времени может быть откачена база данных. Параметр инициализации DBJRECOVERY_ FILEJDEST устанавливает размер области Flash Recovery Area. Команда flashback table использует данные, которые уже хранятся в табличном пространстве управления откатом (она не создает дополнительных элементов), в то время как команда flashback database использует в своей работе журналы ретроспекции, хранящиеся в области Flash Recovery Area.
Определить, насколько далеко назад можно “отмотать” базу данных, можно, сделав запрос к представлению V$FLASHBACK_DATABASE LOG. Количество ретроспективных данных, сохраняемых в базе данных, управляется параметром инициализации и размером области Flash Recovery Area. В следующем листинге показаны имеющиеся в V$FLASHBACK_ DATABASEJLOG столбцы и приводится пример их содержимого:
□ desc V$FLASHBACK_DATABASE_LOG
Name
Null?
Type
OLDEST^FLASHBACK^SCN OLDEST.FLASHBACK TIME RETENTION-TARGET FLASHBACK_SIZE
ESTIMATED-FLASHBACK-SIZE
NUMBER DATE
NUMBER
NUMBER
NUMBER
select * from V$FLASHBACK_DATABASE LOG;
588
Гпава 15
OLDEST_FLASHBACK_SCN OLDECT_FL RETENTION-TARGET FLASHBACK.SIZE
ESTIMATED_FLASHBACK_SIZE
722689 25-FEB-04 1440 8192000
0
Задав запрос к V$DATABSE, можно верифицировать статус ретроспекции базы данных; если столбецТ1а5ЬЬаск__Оп имеет значение ‘YES’, ретроспекция базы данных разрешена:
□ select Current_SCN, Flashback_On from V$DATABASE;
CURRENT.SCN FLA
723649 YES
Примерно через час после открытия базы данных нужно провести верификацию доступности ретроспективных данных и затем выполнить ретроспективный откат — при этом будут потеряны все транзакции, выполнявшиеся в этом интервале времени:
□ shutdown;
startup mount exclusive;
flashback database to timestamp sysdate-1/24;
Для выполнения команды flashback database необходимо, чтобы база данных была смонтирована в монопольном режиме, что будет оказывать влияние на ее участие в кластерах RAC (см. главу 11).
При выполнении команды flashback database Oracle выполняет проверку, чтобы быть уверенным, что доступны все требующиеся архивные и оперативные файлы журналов базы данных. Если все журналы доступны, то все находящиеся в оперативном режиме файлы данных будут реверсированы к указанному времени или SCN.
Если же в доступных архивных журналах и в области группового восстановления (flashback area) данных недостаточно, для восстановления данных придется использовать традиционные методы восстановления баз данных. Например, придется использовать метод восстановления системы, продолжив его “накатом” данных.
После окончания ретроспективного отката нужно открыть базу Д ных, используя опцию resetlogs, чтобы получить доступ к базе дани в режиме записи:
□ alter database open resetlogs;
Чтобы отключить опцию ретроспективного отката базы данных, выполнить команду alter database flashback off в тот момент, когда данных смонтирована, но не открыта:
□ startup mount exclusive;
alter database flashback off;
«i-ьли da+ahpsR ooen;
различные опции повышения доступности
589
Опции ретроспективного отката (flashback) можно использовать для выполнения целого спектра действий — восстановления старых данных, возвращения таблицы к ее прежнему состоянию, поддержания истории изменений на уровне строк и быстрого восстановления всей базы данных. Все подобные действия значительно упрощаются, если база данных сконфигурирована с поддержкой AUM. Кроме того, для применения команды flashback database требуется изменение статуса базы данных. Хотя все эти требования ложатся дополнительным грузом на плечи АБД, выгоды, приобретаемые от сокращения числа требующихся восстановлений и повышения скорости, с которой эти восстановления могут быть выполнены, могут оказаться весьма значительными.
Использование LogMiner
Для отслеживания каждого изменения, произведенного над данными пользователя и словарем данных, Oracle использует файлы оперативного журнала базы данных. Хранящаяся в файлах этого журнала информация используется для повторного создания базы данных (частично или полностью) в процессе ее восстановления. Чтобы сделать возможным восстановление базы данных на заданный момент времени, после того как было произведено резервное копирование базы данных, можно вести архивные копии файлов журналов базы данных. Утилита LogMiner предлагает жизненно важное представление всех модификаций, произошедших в базе данных.
При использовании LogMiner становятся видны как сами произведенные изменения (SQL_redo), так и операторы SQL, которые можно использовать для реверсирования этих изменений (SQL_undo). Следовательно, можно просмотреть всю “историю” базы данных, не прибегая к фактическому использованию каких бы то ни было журналов, и получить программный код для реверсирования (фактически для отказа. — Прим, пер.) любой проблематичной транзакции. Используя LogMiner, можно очень точно выяснить, при выполнении какой транзакции произошло повреждение, так что можно определить правильный соответствующий момент времени или системный номер изменений (SCN), которые можно использовать в качестве конечной точки при восстановлении базы данных.
Если число транзакций, требующих отката, невелико, то до появления LogMiner нужно восстановить таблицу в ее предыдущем состоянии и применить к ней файлы архивных журналов базы данных, чтобы “накатить” таблицу до ее состояния непосредственно перед повреждением. При восстановлении таблицы и последующем применении к ней этих файлов всегда существует риск потерять выполненные после повреждения транзакции, которые было бы неплохо сохранить. Теперь же можно использо-Вать LogMiner для выполнения отката только тех транзакций, которые и считаются проблемными, и не потерять при этом последующие, допустимые транзакции.
Утилита LogMiner в своей первоначальной форме имела некоторые I Ограничения, связанные с ее использованием. В рамках первоначального Ж Подхода можно было просматривать только по одному журналу за раз, да
590
/пава 1$
и интерфейс инструментального средства был несколько неуклю^ В Oracle 9г была реализована существенная реконструкция интерфейс^ и была существенно расширена его функциональность; в частности, быд включен компонент LogMiner Viewer для работы с Oracle Enterprise Manager.
Как работает LogMiner
Для выполнения утилиты LogMiner необходимо иметь либо привилегию EXECUTE на пакет DBMS_LOGMNR, либо роль EXECUTEJ3ATALOG ROLE. Для LogMiner требуется, чтобы словарь данных мог полностью транслировать содержимое файлов журналов базы данных и внутренние идентификаторы объектов и типов данных в имена объектов и внешние форматы данных.
Если словарь данных недоступен, LogMiner возвратит данные в шестнадцатеричном формате, а информацию об объектах — как внутренние идентификаторы объектов.
Есть три варианта получения словаря данных для использования LogMiner:
Извлечение информации словаря данных в плоский файл.
Извлечение информации словаря данных в файлы журналов базы данных.
а Использование оперативного словаря данных из текущей базы данных.
Для анализа LogMiner обычно требуется, чтобы используемый словарь данных был сгенерирован той же самой базой данных, которая генерировала журнальные файлы. Но если используется формат с плоским файлом или формат, в котором словарные данные включены в журнал, то можно использовать LogMiner как для анализа файлов журналов той базы данных, где она выполняется, так и для анализа таких журналов Другой базы данных. Если используется оперативный словарь данных текутей базы данных, можно анализировать только файлы журналов текушей базы данных.
Поскольку LogMiner можно эксплуатировать в одной базе данных, применяя в качестве входных данных журналы другой базы данных, пользуемые в обеих базах данных наборы символов должны совпал Также должны совпадать и обе аппаратные платформы.
Извлечение словаря данных
Потенциальная проблема при извлечении словаря данных в пл т файл состоит в том, что, в то время как один из пользователей вы информацию словаря данных, другие пользователи могут выполня раторы DDL. Следовательно, извлеченный словарь данных можс заться не синхронизированным с базой данных. При использован хранения словаря данных плоского файла требуется меньше сист ресурсов, чем при использовании для этой цели файлов журнале0 данных.
различные опции повышения доступности
591
Если словарь данных извлекается в файлы журналов базы данных, в это время запрещается выполнять операторы DDL. Следовательно, словарь данных будет синхронизован с базой данных. Процесс извлечения, хотя и требует большего количества системных ресурсов, зато протекает быстрее.
Для извлечения словаря данных в плоский файл или в файлы журналов базы данных используется процедура DBMS_LOGMNR_D.BUILD. Файл словаря данных помещается в каталог. Следовательно, у вас должны иметься права записи для того каталога, в который этот файл должен быть помещен. Для определения места, куда должен быть помещен этот каталог, используется параметр инициализации UTL_FILE_DIT. Так, например, чтобы указать в качестве места размещения выходных данных LogMiner каталог D:\Oracle\OralO\database, надо сделать в файл параметров такую запись:
П UTL_FILE_DIR = D:\0racle\0ra10\database
Примечание Параметр UTL_FILE_DIR нельзя изменять динамически с помощью команды alter sistem. Для подобного изменения необходимо модифицировать файл инициализации, а затем остановить и снова запустить базу данных.
Для выполнения процедуры DBMS_LOGMNR_D.BUILD необходимо указать имя файла для словаря, путь к каталогу с файлом для словаря, а также указать, должен ли быть словарь записан в плоский файл или в файлы журналов базы данных. Чтобы извлечь словарь данных в плоский файл mydb_dictionary, размещенный в каталоге G:\Oracle\OralO\database, нужно задать следующую команду:
□ executeDBMS_LOGMNR_D.BUILD
(1mydb_dictionary.ora’, ‘G:\0racle\0ra10\database’, options=>DBMS_LOGMNR_D.STORE_IN_FLAT_FILE);
В качестве дополнительной опции можно использовать DBMS_ LOGMNR_D.STORE_IN_FLAT_FILE.
Примечание Хотя здесь команда записана на нескольких строках, вводить ее необходимо как единую строку; в противном случае будет получено сообщение об ошибке.
После того как содержимое словаря данных будет записано в плоский файл, его можно скопировать на любую другую платформу, чтобы запустить на ней LogMiner. Может быть, в другой базе данных предварительно потребуется выполнить dbmslmd.sql для создания надлежащего окружения. Файл dbmslmd. sql можно найти в каталоге $ORACLE_ HOME\rdbms\admin (в системах Unix).
592
Гпава 1s
Анализ одного или нескольких журнальных файлов
Для анализа файлов журналов базы данных с использованием LogMiner нужно следовать приведенным ниже указаниям:
1. Используя V$LOGMNR_LOGS, получите список имеющихся жур. нальных файлов.
2. Запустите утилиту LogMiner, используя для этого процедуру DBMS_LOGMNR.START_LOGMNR (см. таблицу 15.2, где перечислены параметры процедуры STARTJLOGMNR).
3. Чтобы ознакомиться с результатами, задайте запрос к V$LOGMNR CONTENTS.
4. После того как просмотр журналов будет закончен, задайте команду для завершения сеанса:
execute DBMS.LOGMNR.END_LOGMNR;
Имеющиеся в пакете DBMS_LOGMNR подпрограммы перечислены в таблице 15.1. В таблице 15.2 показаны параметры процедуры START__ LOGMNR.
Для создания списка доступных для анализа журнальных файлов надо выполнить процедуру DBMS_LOGMNR.ADD_LOGFILE с опцией NEW:
П execute DBMS_LOGMNR.ADD_LOGFILE(
LogFileName=> ‘/oracle/ora10/redo01.ora’,
Options=> DBMS_LOGMNR.NEW);
execute DBMS.LOGMNR.ADD_LOGFILE(
LogFileName=> ‘/oracle/ora10/redo02.ora’, Options=> DBMSJ-OGMNR.NEW);
Tаблица 15.1. Подпрограммы пакета DBMSJLOGMNR
Подпрограмма Описание
ADD_LOGFILE
START.LOGMNR
END_LOGMNR
ШЕУ^Щфункция)
REMOVEJ_OGFILE
Добавляет файл к списку подлежащих обработке архивных журнальных файлов
Инициализирует утилиту LogMiner
Завершает выполнение утилиты и заканчивает сеанс LogMiner
Возвращает значение столбца отката или журнального столбца, специфицированного параметром COLUM -NAME для любой строки, возвращаемой из предста ния V$LOGMNR_CONTENT
Определяет, существует ли значение столбца откат^ журнального столбца, специфицированного парам ром COLUMN-NAME для любой строки, возвращаем из представления V$LOGMNR_CONTENT
Удаляет журнальный файл из списка подлежащих обр ботке журнальных файлов для LogMiner
Различные опции повышения доступности
Таблица 15.2. Значения опций STARTJLOGMNR
Опции
COMMITTED_DATA_ONLY
SKIP-CORRUPTION
DDL_DICT_TRACKING
DICT_FROM_ONLINE-CATALOG
DICT_FROM_REDO_LOGS
NO_SQL_DELIMITER
NO_ROWIDJN_STMT
PRINT_PRETTY_SQL
CONTINUOUS-MINE
Описание
Если установлена зта опция, будут возвращены только операторы DML, соответствующие зафиксированным транзакциям.
Пропускает любые повреждения, встретившиеся в файле журнала базы данных во время выборки из V$LOGMNR_ CONTENTS. Эта опция работает только в том случае, если поврежден блок журнала, и не работает, если поврежден блок заголовка.
Позволяет LogMiner обновлять внутренний словарь данных, если произошло событие DDL, чтобы можно было быть уверенными в том, что информация SQL_REDO и SQLJJNDO сопровождается и является корректной.
Указывает LogMiner использовать оперативный словарь данных вместо словаря, сохраненного в плоском файле или в файле журнала базы данных.
Указывает LogMiner использовать словарь, сохраненный в одном или в нескольких файлах журналов базы данных.
Указывает LogMiner не помещать в конце реконструированных операторов SQL разделитель SQL (;).
Указывает LogMiner не включать в реконструированные операторы SQL фразу ROWID.
Указывает LogMiner для удобства чтения форматировать реконструированные SQL.
Указывает LogMiner, что для нахождения интересующих вас данных необходимо автоматически добавлять файлы журналов базы данных. Нужно указать начальный SCN, дату или первый журнал, в котором следует начать добычу информации. Утилита LogMiner должна быть подключена к тому же самому экземпляру базы данных, для которого был сгенерирован журнальный файл.
Место нахождения словаря данных можно указать следующим образом:
execute DBMS.LOGMNR.ADD_LOGFILE(
DictFileName=> ‘/oracle/ora10/dictionary.ora’,
После того как LogMiner было указано место нахождения словаря и были добавлены файлы журналов базы данных, можно начинать анализировать эти файлы, используя пакет DBMSJLOGMNR.START_ LOPGMNR. Например, следующая команда анализирует файлы журналов базы данных в заданном диапазоне времени:
execute DBMS_LOGMNR.START LOGMNR(
DictFileName-> /oracle/ora10/dictionary.ora’,
StartTime=> T0_DATE( ‘ 01 -JUNE-2001 12:31:00’, DD-MOIFYYYY HH:MI:SS’),
EndTime=> T0_DATE(‘01-JULY-2001 00:00:00’, DD-MON-YYYY HH:MI:SS’));’
594
Гпава 15
Примечание Использование отметок времени не гарантирует упорядочения журнальных записей. Чтобы дать такую гарантию, необходимо использовать номера SON.
Использовать номера SCN для фильтрации можно следующим образом:
□ execute DBMS_LOGMNR.START_LOGMNR(
DictFileName=> ‘/oracle/dictionary.ora’,
StartScn=> 125,
EndScn=> 300);
Если не введены начальные или конечные значения диапазона времени или номеров SCN, для каждого выполненного оператора select будет читаться весь файл.
Чтобы просмотреть коды пространства отката и файла журнала базы данных, следует выбрать столбцы Sql_Redo и Sql_Undo:
□ select Sql.Redo, Sql_Undo
from V$LOGMNR_CONTENTS;
Для запуска LogMiner Viewer с целью просмотра журнальных и архивных журнальных файлов можно использовать консоль диспетчера сервера OEM. Для запуска LogMiner Viewer на платформах Windows используется опция Start | Programs | Oracle_Home | Oracle Enterprise Manager Console. После того подключения к консоли сервера OEM нужно выбрать ту базу данных, для которой необходимо выполнить LogMiner Viewer. Перед этим следует убедиться в том, что эта база данных запущена.
Для запуска LogMiner Viewer нужно выделить требующуюся базу данных и щелкнуть на ней правой кнопкой мыши, а потом переместить курсор к опции Related Tools и к опции LogMiner Viewer. Когда появится экран консоли LogMiner Viewer, нужно создать объектный запрос, лиоо щелкнув для этого на верхней иконке на панели иконок, либо выбрав Create Query из ниспадающего меню Object. После этого LogMiner Viewer автоматически отыскивает имеющиеся в наличии архивные файлы журналов базы данных, по которым можно создавать запрос. Если подходящих архивных файлов нет, будет выдано сообщение об ошибке. Можно создавать опции фильтрования (с помощью соответствующих критериев запроса), проверять начальные и конечные значения SCN для каждого доступного журнального файла и выбирать столбцы для показа. Исполь зование OEM LogMiner Viewer может упростить процесс просеивания содержимого журнальных файлов. В дополнение можно использовать экраны Grid Control для доступа к выходным данным LogMiner и их про смотра.
Возможности LogMiner, впервые появившиеся в Oracle Database 10д
Если вы использовали LogMiner для предшествовавших Oracle Databas 10g версий Oracle, то сейчас вам представится возможность воспольз
ваться следующими усовершенствованиями:
У пакета DBMS_LOGMNR теперь появилась новая процедура, УД^^ щая файлы журналов из списка подвергаемых анализу файлов (см. табл
Различные опции повышения доступности
595
цу 15.1). Поэтому больше нет необходимости использовать опцию REMOVEFILE процедуры ADD_FILE.
Чтобы отфильтровывать фразу rowid из реконструированных команд SQL (см. таблицу 15.2) можно использовать в процедуре START LOGMNR опцию NOJkOWIS JN.STATEMENTS.
Можно расширить дополнительную журнализацию путем применения команды alter database, включив изменения foreign key или all для строк. Использование таких установок приводит к увеличению количества данных, записываемых в журнальные файлы.
Можно расширить дополнительную журнализацию на уровне таблицы для отслеживания первичных и внешних ключей, уникальных индексов и всех изменений. Кроме того, можно использовать опцию nolog, чтобы не дать возможности журнализировать столбец в определенной пользователем журнальной группе.
Дополнительные детали использования LogMiner и входящих в нее процедур можно найти в руководстве по утилитам Oracle (Oracle Utilities Guide).
перативная реорганизация объектов
Многие объекты базы данных могут быть реорганизованы в оперативном режиме. К их числу относятся:
Оперативное создание индексов
Оперативная перестройка индексов
Оперативное слияние индексов
Оперативная перестройка индекс-таблиц
Использование пакета DBMS_REDEFINITION для оперативного переопределения таблиц
Оперативное создание индексов
Можно создавать и перестраивать индексы, в то время как базовые таблицы продолжают оставаться доступными для конечных пользователей. Во время построения индексов не разрешается выполнение операций DDL. Для оперативного построения индекса следуем использовать фразу online команды create index:
О create index AUTH$NAME on AUTHOR (AuthorName) online;
Оперативная перестройка индексов
При использовании фразы rebuild в команде alter index Oracle использу-ет существующий индекс как источник данных для нового индекса. Из этого следует, что на время проведения операции необходимо иметь достаточно свободного дискового пространства для хранения двух копий индекса. Команду alter index rebuild можно использовать для изменения характерис I ик хранения и назначения табличных пространств для индексов.
596
Глава 15
Для оперативной перестройки индекса используется фраза rebuild index online команды alter table:
□ alter index AUTH$NAME rebuild online;
Оперативное объединение индексов
Индекс можно объединить (coalesce), чтобы высвободить пространство внутри него. Когда индекс объединяется, его нельзя перенести в другое табличное пространство (как это можно было сделать при оперативной перестройке). При объединении не требуется дополнительного пространства для хранения нескольких копий индекса, так что эта процедура может оказаться полезной, если требуется реорганизовать индекс в среде с дефицитом дискового пространства.
Для объединения индекса используется фраза coalesce команды alter index. Все объединения индексов выполняются как онлайновые операции. Ниже приведен пример простого объединения:
□ alter index AUTH$NAME coalesce;-
Оперативная перестройка индекс-таблиц
Команду alter table ... move online можно использовать для оперативной перестройки индекс-таблиц (index-organized tables). Если указано ключевое слово overflow, будет также перестроен сегмент переполнения данных (если он имеется). Так, например, если BOOKSHELF является ин-декс-таблицей, ее можно оперативно перестроить с помощью следующей команды:
П alter table BOOKSHELF move online;
Во время применения подобной команды нельзя использовать параллельные операции DML. Кроме того, опция move online доступна только для несекционированных индекс-таблиц.
Оперативное переопределение таблиц
Можно изменить определение таблицы таким образом, чтобы она при этом оставалась доступной пользователям приложения. Например, мож но разбить на разделы таблицу, которая ранее не была секционирован ной, непосредственно в то время, когда она используется; это весьма су щественная возможность для высокодоступных приложений OLTP.
Примечание Нельзя выполнять- оперативную реорганизацию для таблиц, имеющих первичных ключей, для таблиц, на базе которых созданы материализ ванные представления и журналы материализованных представлений, для базовь таблиц материализованных представлений и для индекс-таблиц с переполнени
В следующем примере приводятся шаги, из которых состоит опер тивное переопределение таблицы. Сначала нужно проверить, может л данная таблица быть переопределена. В данном примере в табличном
Различные опции повышения доступности
597
пространстве пользователя SCOTT будет создана, а затем переопределена таблица CUSTOMER:
□ create table CUSTOMER (Name VARCHAR2(25)
Street VARCHAR2(50),
City VARCHAR2(25),
State CHAR2(2),
Zip NUMBER);
primary key,
Затем следует проверить, может ли эта таблица быть переопределена, используя для этого процедуру CAN_REDEF_TABLE пакета DBMS_ REDEFENITION. Ее входными параметрами являются имя пользователя и имя таблицы:
□ execute DBMS.REDEFINITION.CAN_REDEF_TABLE(‘SCOTT’, ‘CUSTOMER’);
Таблица является кандидатом на оперативное переопределение, если процедура возвратит сообщение
□ PL/SQL procedure successfully completed.
Если же она возвращает сообщение об ошибке, таблица не может быть переопределена оперативно, и текст сообщения об ошибке раскрывает причину этого.
Затем надо создать в той же самой схеме промежуточную таблицу с требующимися атрибутами переопределенной таблицы. Например, можно разбить таблицу CUSTOMER на разделы (для упрощения приводимого примера фразы tablespace и storage не показаны):
□ create table CUSTOMER-INTERIM
(Name VARCHAR2 (25) primary key,
Street VARCHAR2(50),
City VARCHAR2(25),
State CHAR2(2),
Zip NUMBER)
partition by range (Name)
(partition PART1 values less than (‘L’), partition PART2 values less than (MAXVALUE))
Сейчас можно выполнить процедуру START REDEF_TABLE из пакета DBMS_REDEFINITION, чтобы запустить процесс переопределения. Ее входными переменными являются имена владельца схемы, подлежащей переопределению таблицы и промежуточной таблицы, а также список отображения столбцов (аналогичен перечню имен столбцов в запросе select). Если список отображения столбцов не представлен, все имена столбцов в исходной и промежуточной таблице должны быть одинаковыми.
□ execute DBMS-REDEFINITION.START_REDEF_TABLE -(‘SCOTT’, ‘CUSTOMER*, ‘ CUSTOMER. INTERIM’);
598
Гпава 15
Теперь нужно создать все триггеры, индексы, гранты или ограничения, требующиеся для промежуточной таблицы. В данном примере первичный ключ для CUSTOMER^ INTERIM уже был определен; на этом шаге процесса переопределения к нему можно добавить внешние ключи, вторичные индексы и гранты. Создание внешних ключей будет заблокировано до тех пор, пока не будет завершен процесс переопределения.
Примечание Чтобы избежать подобного “ручного” шага, можно использовать процедуру COPY_TABLE_DEPENDENTS для создания всех зависимых объектов для промежуточной таблицы. К числу зависимых объектов, поддерживаемых подобным способом, относятся триггеры, индексы, гранты и ограничения.
После завершения процесса переопределения индексы, триггеры, ограничения и гранты для промежуточной таблицы будут заменять аналогичные объекты для исходной таблицы. Именно в этот момент снова активируются заблокированные ограничения ссылочной целостности.
Чтобы закончить с переопределением, следует выполнить процедуру FINISH_REDEF_TABLE из пакета DBMS_REDEFINITION. Ее входными параметрами являются имена схемы, а также исходной и промежуточной таблиц:
□ execute DBMS_REDEFENITION.FINISH_REDEF_TABLE -
(‘SCOTT’, ‘CUSTOMER’, * CUSTOMER-INTERIM’);
Можно верифицировать переопределение, задав запрос к словарю данных:
□ select Table_Name, High_Value
from DBA_TAB_PARTITIONS
where owner = ‘SCOTT’;
TABLE_NAME HIGH_VALUE
CUSTOMER MAXVALUE
CUSTOMER ‘L’
Для прекращения процесса после выполнения процедуры START REDEF_TABLE нужно выполнить процедуру ABORTJREDEFJTABLE (входные параметры: схема, имя исходной и промежуточной таблицы)-
Oracle в сетях
ORACLE NET
Распределение вычислительных возможностей между несколькими серверами и разделение информации по сети повышают ценность доступных ресурсов. Сервер перестает быть автономным компьютером и становится точкой входа в интранет, Интернет и соответствующие web-сайты.
Для соединения с распределенными базами данных предназначено инструментальное сетевое средство Oracle, которое называется Oracle Net. Оно упрощает распределение информации между базами данных, причем даже тогда, когда эти базы данных находятся на серверах разных типов, имеющих разные операционные системы и коммуникационные протоколы. Кроме того, это средство позволяет создавать приложения типа клиент/сервер, когда сервер обеспечивает в основном ввод/вывод информации из базы данных, а само приложение может быть передано на принадлежащий промежуточному уровню сервер приложений. Кроме того, требования представления данных приложения могут быть перенесены на машины клиентов.
Способы инсталляции и конфигурирования Oracle Net зависят от конкретной аппаратуры, операционной системы и используемых коммуникационных программ.
Обзор Oracle ^et
двухуровневой архитектур0
Использование Oracle Net
связанную с функциониров^т^0™^ РаспРеделить рабочую нагрузку, многие запросы к базам даш™ Г приложения баз данных Поскольку ное приложение заставляет сеов^Т^*01^ Через пРиложения, сервер-ния в ресурсах централт ныу ™ Р °беспечивать потребности приложе-Данных в операциях вволэ /wKri^PO1^eCCOpOP’ а также потребность базы рации клиент/сервер (начьтт°да-РИС’ 16-1а).Использованиеконфигу-позволяет распределить 3tv гг^гт^МО1Г гакже двухуровневой архитектурой) зываемая клиентом (сПешкили Ру31у меж/У Двумя машинами. Первая, наложение, инициирующее обоаш^еШС^°И Сганц'ией, поддерживает при-^рХЩХан а ДаННЫХ’ называется Й"™’ на К°'Г°/ Р, ку, связанную с представлением данных, ’Клиент несет всю на-
• в то время как сервер базы
Oracle Net
601
а) Серверное приложение
Прикладная программа и база данных
b) Приложение клиент/сервер
Сервер
Клиент
Прикладная программа
и Oracle Net
База данных и Oracle Net
Сеть
-
Сервер
Рис. 16.1. Архитектура клиент/сервер
данных предназначен для поддержки запросов, а не приложений. Такое распределение требований к ресурсам показано на рис. 16.1b.
Когда клиент посылает в базу данных запрос к серверу, сервер получает и выполняет переданный ему SQL-оператор. Результат выполнения этого оператора, а также сообщения об ошибках посылаются обратно на клиентскую станцию. Довольно высокие требования к клиентским ресурсам служат причиной того, что конфигурацию клиент/сервер иногда называют архитектурой “толстого” клиента (fat-client). Хотя в последние годы стоимость рабочих станций заметно упала, общие затраты компании могут по-прежнему оставаться значительными.
Более широко распространенная в Oracle Net и более рентабельная архитектура называется конфигурацией “тонкого”клиента (thin client), или трехуровневой архитектурой. Код приложения хранится и выполняется с использованием сценариев Java на специальном сервере, отдельном от сервера базы данных. Требования к ресурсам клиента становятся очень низкими, а цена резко падает. Код приложения становится изолированным от базы данных (см. рис. 16.2).
Клиент соединяется с сервером приложений. После аутентификации клиента на его станцию загружается код в виде Java-апплета, управляющий отображением информации. Запрос к базе данных передается от клиента через сервер приложений к серверу БД; сервер базы данных принимает и выполняет переданный ему SQL-оператор. Результаты выполнения этого оператора, а также сообщения об ошибках посылаются обратно на станцию клиента через сервер приложений. В некоторых вариантах трехуровневой архитектуры на сервере приложений выполняется только часть прикладной программы, а остальные операции выполняет сервер базы данных. К преимуществам архитектуры “тонкого” клиента относятся низкие требования к ресурсам и обслуживанию на стороне клиента, средние требования к ресурсам в сочетании с централизованным обслуживанием на сервере приложений, а также высокие требования к ресурсам при небольшом объеме обслуживания для одного или двух серверов базы данных.
Наряду' с системами клиент/сервер часто используются конфигурации типа сервер/сервер. В такой конфигурации базы данных, размещенные
602
Гпава 16
Рис. 16.2.
Java-апплет
Сервер базы данных
Архитектура “тонкого" клиента
на отдельных серверах, разделяют данные между собой. Кроме того, каждый сервер может быть физически изолирован от другого без их логического разделения. Типичной является конфигурация, когда несколько центральных серверов компании взаимодействуют с серверами удаленных друг от друга подразделений. Каждый сервер поддерживает клиентские приложения и, помимо этого, может взаимодействовать с другими серверами в сети (см. рис. 16.3).
Сервер, посылающий запрос к базе данных другого сервера, выступает в роли клиента. Принимающий сервер выполняет переданный ему Ьч, оператор и возвращает результаты вместе с сообщениями об ошиоках серверу-отправителю. - f
Функционируя как на станции клиента, так и на сервере, Oracle дает возможность обращаться с запросами из одной базы данных приложения) к другой базе, расположенной на отдельном сервер В большинстве случаев машины выполняют как роль клиента, так и р сервера; исключение составляют однопользовательские операцион системы, например сетевые
ны могут работать только в качестве клиентов.
Конечным результатом реализации Oracle Net является возможно взаимодействия со всеми базами данных, доступными по сети.
также создать синонимы, которые обеспечат приложениям реальН}
L XYCIXV —---, -
Ш/llV X однопользовательские операционнь устройства. В подобных случаях такие маШИ
Oracle Net
603
База данных и Oracle Net
База данных и Oracle Net
Сервер Сервер
Рис. 16.3. Архитектура сервер/сервер
прозрачность местонахождения объектов в сети; пользователь, выдающий запрос, не будет знать о расположении данных, выводимых этим запросом. Подробнее об управлении распределенными базами данных см. главу 18.
Для однозначной идентификации каждого объекта базы данных достаточно знать его владельца и имя. Так, может существовать только одна таблица с именем EMPLOYEE, принадлежащая пользователю HR; в одной и той же схеме не может быть двух объектов с одинаковыми именами.
В распределенной базе данных необходимо ввести два новых уровня идентификации объектов. Во-первых, нужно определить имя экземпляра, обращающегося к базе данных, и, во-вторых, идентифицировать имя сервера, на котором размещается этот экземпляр. Если объединить эти четыре части имени объекта — сервер, экземпляр, владелец и имя, — получится так называемое глобальное имя объекта (global object name — GON). Для обращения к удаленной таблице нужно знать ее GON. Администраторы баз данных и приложений могут определять способы доступа к объектам, автоматизирующие выбор всех четырех частей глобального имени объекта (о настройке путей доступа, используемых в Oracle Net, см. ниже в данной главе).
Основой Oracle Net является так называемая прозрачная сетевая среда (Transparent Network Substrate — TNS). С ее помощью разрешаются все вопросы, связанные с соединением на уровне сервера. Управление соединением с базой данных обеспечивается в Oracle Net с помощью конфигурационных файлов на станции клиента и на сервере. Если клиент и сервер используют разные протоколы связи, то соединениями управляет диспетчер соединений Oracle (Oracle Connection Manager), который будет подробно описан ниже в данной главе. Комбинация Oracle Connection Manager и TNS позволяет соединениям Oracle Net оставаться независимыми от операционной системы и протоколов связи, функционирующих на каждом сервере. Кроме того, в Oracle Net можно посылать и получать запросы в асинхронном режиме, что позволяет поддерживать архитектуру так называемого разделяемого сервера (shared server — MTS).
Дескрипторы соединений
В глобальном имени объекта в Oracle Net части, относящиеся к серверу и экземпляру, определяются с помощью так называемых дескрипторов соединения (connect descriptor). В дескрипторе соединения указываются коммуникационный протокол, имя сервера и имя экземпляра, используемые при
604
Гпава iq
выполнении запроса. Поскольку Oracle Net не зависит от применяемы^ протоколов, в дескриптор также включается информация о возможности соединения с помощью аппаратных средств. Общий формат дескриптора соединения для Oracle Net приведен ниже. В этом примере использован протокол TCP/IP, и соединение устанавливается с экземпляром LOC на сервере HQ. Применяемые ключевые слова зависят от протокола.
□ (DESCRIPTION-
(ADDRESS-
(PROTOCOL-TCP)
(HOST-HQ)
(PORT-1521))
(CONNECT DATA-
(SERVICE_NAME=LOC)))
В данном дескрипторе соединения протоколом является TCP/IP, именем сервера (HOST) — HQ, а номером порта хост-машины, который нужно использовать для соединения, — 1521 (это зарегистрированный номер порта для Oracle Net). Имя экземпляра указано в специальном разделе дескриптора как значение параметра SID.
Структура этого дескриптора одинакова для всех протоколов. Кроме того, дескрипторы можно генерировать автоматически с помощью инструмента Net Configuration Assistant. Ключевые слова дескрипторов зависят от протокола. Используемые ключевые слова и присваиваемые им значения содержатся в документации на Oracle Net для конкретной операционной системы.
Имена служб
При обращении к удаленным данным пользователи не обязаны каждый раз вводить дескрипторы соединений. Вместо этого АБД может определить так называемые имена служб (service names), т. е. псевдонимы, которые будут ссылаться на дескрипторы соединений. Имена служб хранятся в файле tnsnames.ora, который следует скопировать на все серверы сети баз данных. Кроме того, копия этого файла должна быть у каждого клиента и сервера приложений.
Файл tnsnames.ora нужно разместить на сервере в каталоге, указанном переменной окружения TNS_ADMIN. Обычно это общий каталог, напри мер $ORACLE_HOME/network/admin в системах UNIX или подкаталог \network\admin домашнего каталога Oracle для Windows NT/200U клиентской станции или на сервере.
Ниже приведен пример записи в файле tnsnames.ora. Здесь дескри ру соединения присваивается имя службы LOG:
□ LOC -(DESCRIPTION-
(ADDRESS-
(PROTOCOL-TCP)
(HOST-HQ)
(PORT-1521))
(CONNECT DATA=
(SERVICE_NAME=LOC)))
Oracle Net
605
Пользователь, желающий соединиться с экземпляром LOC на сервере HQ, может теперь использовать имя службы LOC:
□ sqlplus hr/puffinstuff@LOC;
Знак @ сообщает базе данных о том, что далее следует имя службы, определяющее, в какой базе данных следует регистрироваться. Если указаны корректное имя и пароль пользователя, то открывается сеанс и пользователь может приступить к работе с базой данных.
Имена служб представляют собой псевдонимы для дескрипторов соединений, поэтому нет необходимости, чтобы имя службы совпадало с именем экземпляра. Например, для экземпляра LOC именем службы может быть PROD или TEST, в зависимости от того, какое из них используется в конкретной среде (об использовании синонимов для повышения уровня прозрачности местонахождения объектов см. ниже в данной главе).
Замена файла tnsnames. ora на Oracle internet Directory
Каталог — это специализированная электронная база данных, в которой хранится информация об одном или нескольких объектах. Примером такого каталога может служить адресная книга для адресов электронной почты. В каждом из этих адресов содержится информация об имени контактного лица, адрес электронной почты, домашний и рабочий адреса и т.д. Воспользовавшись этой книгой, можно найти конкретного человека, которому следует отправить почту.
В Oracle есть специальное инструментальное средство электронной базы данных, которое называется Интернет-каталог Oracle (Oracle Internet Directory — OID), с помощью которого решается проблема хранения и определения данных о местонахождении пользователя, сервера, базы данных, а также паролей и другой важной информации. Начиная с Огас1е9г, вместо поддержки нескольких отдельных файлов tnsnames.ora на распределенных машинах, поддерживающих один или несколько каталогов, основной акцент делается на поддержку одного или нескольких каталогов на централизованных машинах (подробнее об OID см. ниже в данной главе).
Прослушивающие процессы
Для каждого сервера сети должен быть создан файл listener.ora. В этом файле содержится список имен и адресов всех прослушивающих процессов машины, а также имен всех поддерживаемых ими экземпляров. С прослушивающими процессами устанавливают соединения клиенты Oracle Net.
Файл listener.ora состоит из четырех частей:
Раздел заголовка
Список адресов протоколов
Определение экземпляров
Рабочие параметры
606
Гпава 16
Этот файл автоматически генерируется инструментом Oracle Net Assistant. Полученный файл можно редактировать, соблюдая установленные для него синтаксические правила. Ниже приведен пример разделов файла listener.ora — описание адресов и экземпляров:
□ LISTENER =
(ADDRESS_LIST =
(ADDRESS=
(PROTOCOL-IPC)
(KEY= loc.world)
)
(ADDRESS=
(PROTOCOL=TCP)
(HOST-HR)
(P0RT=1521)
)
)
SID_LIST_LISTENER =
(SID-DESC =
(GLOBAL.DBNAME = loc.world)
(ORACLE_HOME = D:\oracle\ora10)
(SID_NAME = loc)
В первой части листинга содержится список адресов протоколов — по одному элементу на экземпляр. В этом списке определяются адреса протоколов, по которым процесс прослушивает соединения, включая раздел определения адресов межпроцессных вызовов (IPC). В данном случае процесс прослушивает соединения со службой, идентифицируемой как loc.world, а также все запросы, приходящие с машины HR на PORT 1521, с помощью протокола TCP/IP. Суффикс .world — это имя домена по умолчанию для соединений Oracle Net. До появления Net 8 именем домена по умолчанию была NULL-строка.
Во второй части листинга, начинающейся с конструкции SID_LIST_ LISTENER, определяется глобальное имя, указанное в файле init.ora для этой базы данных, базовый каталог Oracle для каждого экземпляра, обслуживаемого прослушивающим процессом, а также имя экземпляра или SID. В GLOBAL_DBNAME (глобальное имя базы данных) входят имя базы данных и ее домен. Дескриптор SID_LIST сохранен для регистраций ста тической базы данных, обеспечения совместимости с более ранними вер сиями и для использования ут илитой Oracle Enterprise Manager. Базы дай ных динамически регистрируются с помощью прослушиваюШегО процесса при запуске базы данных.
Примечание При изменении домашнего каталога с программным обеспечением Oracle для экземпляра необходимо изменить файл listener.ora для сервера.
Oracle Net
607
Параметры файла listener.ora
В файле listener.ora поддерживается ряд дополнительных параметров. Для каждого параметра в качестве суффикса должно быть указано имя прослушивающего процесса. Например, по умолчанию для прослушивающего процесса используется имя LISTENER, поэтому параметр LOG_ FILE называется LOG_FILE_LISTENER.
Таблица 16.1. Параметры файла listenerxira
Параметр
DESCRIPTION
ADDRESS
QUEUESIZE
RECV-BUF-SIZE
SEND_BUF_SIZE
SID-LIST
SID_DESC
ENVS
GLOBAL_DBNAME
ORACLE-HOME
PROGRAM
SID-NAME
SDU
Описание
Служит контейнером для адресов протоколов прослушивающего процесса.
Указывает адрес протокола одиночного прослушивающего процесса. Встраивается в параметр DESCRIPTION.
Специфицирует число параллельно выполняемых запросов на соединение, которые прослушивающий процесс может принять в конечных точках прослушивания TCP/IP или IPC.
Указывает размер буферного пространства (в байтах) для операций получения сеансов. Встраивается в параметр DESCRIPTION.
Указывает размер буферного пространства (в байтах) для операций отправки сеансов. Встраивается в параметр DESCRIPTION.
Перечисляет описания SID; конфигурирует информацию о службе для прослушивающего процесса; требуется для OEM, Oracle?, Oracle8 релиза 8.0, для вызовов внешних процедур и гетерогенных служб.
Специфицирует информацию о службах для конкретного экземпляра службы. Встраивается в параметр SID-LIST.
Специфицирует переменные окружения, которые должны быть установлены для процесса прослушивания перед выполнением программы выделенного сервера (dedicated server program) или выполняемого модуля, специфицированного посредством параметра PROGRAM. Встраивается в параметр SID_DESC.
Идентифицирует службу базы данных. Встраивается в параметр SID_DESC.
Специфицирует домашний каталог, в котором размещается программное обеспечение Oracle для службы.
Встраивается в параметр SID_DESC.
Именует исполняемый модуль службы. Встраивается в параметр SID-DESC.
Специфицирует для службы имя экземпляра Oracle. Встраивается в параметр SID-DESC.
Определяет размер блока данных сеанса (session data unit — SDU) для передачи пакетов данных. Может принимать значения от 512 до 32768 байт. Встраивается в параметр SID_DESC.
608
Глава 16
Таблица 16.1 (Продолжение)
Параметр Описание
ADMIN_RESTRICTI0NS_KAf^_/7po^cca_ прослушивания Отменяет модификации параметров прослушивающего процесса, сделанные в процессе выполнения. Принимает значения ON и OFF (по умолчанию).
INB0UND_C0NNECT_TIME0UT_^- процесса_прослушивания Указывает время (в секундах), в течение которого клиент должен завершить свои запрос на соединение с прослушивающим процессом после установления сетевого соединения.
L0G_DI RECTORY_#мя_лро4есса_ прослушивания ^_^_имя_процесса_прослушивания Указывает каталог для файла журнала прослушивающего процесса. Указывает имя файла журнала прослушивающего процесса.
1.0(з(з\^_имя_процесса_прослушивания Флажок, разрешающий (ON) или запрещающий (OFF) запись в журнал прослушивающего процесса.
Р^^ЖЗ_имя_процесса_ прослушивания Специфицирует закодированный пароль для прослушивающего процесса. Пароль может быть сгенерирован с помощью утилиты управления прослушивающим процессом (Listener Control Utility — Isnctl) или Oracle Net Manager.
SAVE_CON FI (а_0^_ЗТ0Р_имя_процесса_ прослушивания Параметр co значениями TRUE или FALSE, указывающий, нужно ли сохранять в файле hstener.ora конфигурационные изменения, внесенные в прослушивающий процесс во время его функционирования.
SSL_CLIENT_AUTHENTICATIONjfMff_ процесса_прослушивания Параметр со значениями TRUE или FALSE, указывающий, нужно ли аутентифицировать клиента с использованием SSL.
^Ш[)РУ\1М1_1\^_имя_процесса_ прослушивания TRACE.DI RECT ЪРЧ_имя_процесса_ прослушивания ТРкСЕ_?№_имя_процесса_ прослушивания TRACE_FILELEN_«AW_npoi/ecca_ прослушивания 1РКСЕ_^Ж_имя_процесса_ прослушивания Не рекомендован к использованию; не следует его задавать. Указывает целевой каталог для файла трассировки прослушивающего процесса. Имя файла трассировки прослушивающего процесса. Указывает размер (в килобайтах) файла трассировки прослушивающего процесса. Устанавливает количество файлов трассировки прослушивающего процесса для использования в процессе трассировки; если этот параметр используется вместе с параметром ТНАСЕ_Е!ЕЕЕЕН_имя_процесса_прослуши-вания, файлы используются циклически.
1РкСЕ-ШЕ[__имя_процесса_ прослушивания Активирует трассировку на конкретном уровне. Принимает одно из следующих значений: OFF (значение по умолчанию), USER, ADMIN или SUPPORT.
TR АС Е_Т 1М ESTAM Р_имя_процесса_ прослушивания WALLET_LOCATION Добавляет к каждому событию трассировки отме™Ур ре мени. Принимаемые значения: ON, OFF, TRUE и FALb Указывает размещение сертификатов, ключей и записей достоверных (доверенных) сертификатов, используем SSL для защищенных соединений. Для параметра WALLET_LOCATION могут быть специфицированы подпараметры SOURCE, METHOD, METHOD-DATA, DIRECTORY, KEY, PROFILE и INFILE.
Oracle Net
609
После запуска прослл шивающего процесса можно модифицировать его параметры. Если используется опция SAVE_CONFIG_ON_STOP, то любые сделанные во время работы процесса изменения будут сохранены в файле listener.ora. Примеры управления поведением прослушивающего процесса см. ниже в данной главе.
Испояьзжш Oracle met Configuration Assistant
Инструментальное средство Oracle Net Configuration Assistant выполняет шаги начального конфигурирования сети после инсталляции программного обеспечения Oracle и автоматически создаст используемые по умолчанию базовые конфигурационные файлы. Для администрирования сетевых сервисов можно использовать инструментальное средство Oracle Net Manager. Эти инструменты имеют графический пользовательский интерфейс для конфигурирования следующих элементов:
и Прослушивающий процесс
Методы именования
и Имена локальных сетевых служб
Применение каталогов
На рис. 16.4 показан начальный экран Oracle Net Configuration Assistant. Опцией по умолчанию является конфигурирование прослушивающего процесса (Listener Configuration).
Welcome to the Oracle Net Configuration Assistant This too- takes you through the following common configuration steps
Ch ose the configuration you would like to do
Listener configuration
r J a ini ng M eth о d s co nfi gu rati о n
Local Net Service Name configuraVon
C Directory Ibage Configuration
Рис. 16.4. Начальный экран Oracle Net Configuration Assistant
610
Гпава 16
Конфигурирование прослушивающего процесса
При использовании Oracle Net Configuration Assistant можно легко и быстро сконфигурировать прослушивающий процесс. При выборе опции Listener Configuration появляется возможность добавлять, заново конфигурировать, удалять или переименовывать прослушивающий процесс. После выбора опции Add (Добавить) на первом шаге выбирается имя прослушивающего процесса. На рис. 16.5 показан экран выбора имени прослушивающего процесса (Listener Name) с используемым по умолчанию именем прослушивающего процесса — LISTENER.
После выбора имени прослушивающего процесса необходимо выбрать протокол. По умолчанию этим протоколом будет TCP. Экран выбора протокола показан на рис. 16.6.
После выбора протокола необходимо определить номер порта, на котором будет функционировать новый прослушивающий процесс. Номер порта по умолчанию — 1521, но можно назначить и другой порт. На следующих трех экранах предлагается сконфигурировать другой прослушивающий процесс, запрос для указания прослушивающего процесса, который необходимо запустить, и выдается подтверждение о том, что конфигурирование данного процесса завершено.
Oracle Net tkmfigWaiioni Asmlapt Listener Contrguf iUun, Ustener Name
< gack
Cancel
Рис. 16.5. Экран выбора имени прослушивающего процесса
For remote connections to be made to your Oracle database you must have at least one Oracle Net Hstener Enter the name ot the listener you want to create:
' w
Listener name
{listener
Oracle Net
611
Configuration AssistantLutenor Cnnfigutation, Select Protocols
You can configure the listener to accept connections over one or more protocols. Select which protocols you want to configure for this listener. Keep your configuration as simp'e as possible by configuring only the protocols you need. *
Available Protocols
TOPS
IPC
NMP
Selected Protocols
Рис. 16.6. Конфигурирование прослушивающего процесса, экран выбора протоколов
Конфигурирование методов именования
Опция Naming Methods Configuration (конфигурирование методов именования) Oracle Net Configuration Assistant позволяет сконфигурировать имена сетевых служб. Существует большое число методов именования. Некоторые из них перечислены ниже:
Локальные Файл tnsnames. ora
Имя хоста (host name) Использует службу имен TCP. При применении этой оп-
ции нельзя использовать пул соединений или диспетчер соединений Oracle.
Sun NIS, DCE CDS, Directory Внешние службы имен.
Если выбрать опцию Host Name, в информационном окне будет выведено сообщение, что этот метод именования “в данное время” не требует дополнительной конфигурации. В этом окне также говорится, что, как только будет добавлена служба базы данных, необходимо будет внести запись в систему разрешения имен (name resolution) хоста TCP/IP.
После выбора методов именования Oracle Net Configuration Assistant выводит экран подтверждения.
612
Гпава 16
Конфигурирование имени локальных сетевых служб
Для управления именами сетевых служб используются опции конфигурц. рования имени локальных сетевых служб (Local Net Service Name configuration), имеющиеся в Oracle Net Configuration Assistant. Это инструментальное средство имеет пять опций:
Add (добавить)
Reconfigure (переконфигурировать)
Delete (удалить)
Rename (переименовать)
Test (тестировать)
Для опции добавления (Add) сначала требуется указать версию базы данных, к которой будет осуществляться доступ. После ввода глобального имени службы или SID вы получите приглашение ввести протокол. Нужно будет ввести имя машины хоста и указать порт прослушивающего процесса.
На следующем экране предлагается опция проверки успешности доступа к указанной вами базе данных Oracle. Можно пропустить тестирование соединения или провести его. После того, как будет выбрано тестирование подключения и это тестирование завершится успешно, или после того как вы откажетесь от подобного тестирования, будет получено приглашение ввести имя для новой сетевой службы. По умолчанию используется ранее введенное имя, но можно ввести и другое. И, наконец, будет получено уведомление о том, что новое имя сетевой службы успешно создано, и предложено создать еще одно имя.
Можно выбрать опцию Reconfigure и модифицировать имя существующей сетевой службы. Используются экраны Database Version (версия базы данных), Service Name (имя службы) и Select Protocol (выбор протокола), а также экран TCP/IP Protocol (протокол TCP/IP). Будет предложена опция тестирования соединения с базой данных, а также экран Net Service Name, что позволит переименовать сетевую службу, конфигурация которой изменяется.
Опция Test позволяет проверить правильность информации о конфи гурации, возможность доступа к базе данных, а также успешность уставов ления соединения с ней.
Конфигурирование использования каталогов
Служба каталогов обеспечивает централизованное хранение инфор^ ции о сети (репозиторий информации). Наиболее распространенно формы каталогов поддерживают протокол LDAP (Lightweight Direc Access Protocol — упрощенный протокол доступа к каталогу). Сер LDAP осуществляет следующие функции:
Хранит имена сетевых служб и информацию об их размещении
Предоставляет глобальные связи и псевдонимы баз данных
Действует как центр обмена информацией о конфигурации клие* тов всей сети
Oracle Net
613
Помогает конфигурировать другие клиентские станции
Автоматически обновляет клиентские конфигурационные файлы
Хранит такую информацию о клиентах, как имена пользователей и пароли
Опция конфигурирования использования каталогов поддерживает как Oracle Internet Directory, так и Microsoft Active Directory. Предпринимаемые в этих случаях действия показаны на рис. 16.7.
Выбрав первую опцию, “Select the directory server you want to use...” (Выбрать сервер каталога, который вы хотите использовать...”), вы полу
чите приглашение указать имеющийся у вас тип каталога: или OID, или
Microsoft Active Directory. Если будет выбран OID, вы получите приглаше-
ние ввести имя хоста, на котором находится служба каталогов, порт и порт SSL. По умолчанию порт задается как 389, а порт SSL — как 636. После указания этой информации инструментальное средство попытается соединить вас с репозиторием каталога и проверить, заданы ли уже схема и контекст. Если они еще не заданы, будет получено сообщение об ошибке, предлагающее задать их. На рис. 16.8 приведено сообщение об ошибке в схеме, а на рис. 16.9 — контекстное сообщение об ошибке.
Вторая опция, “Select the directory server you want to use, and configure the directory server for Oracle usage...” (Выбрать сервер каталога, который вы хотите использовать, и сконфигурировать сервер каталога для использования в Oracle...), даст те же исходные приглашения на выбор типа каталога и ввод имени хоста и портов. После проверки информации, если
Г/
-
Я)
Choose the operation you wantto complete
® Select the directory server you wantto use. The directory server must already be configured for Oracle usage.
Г Selectthe directory server you wantto use, and configure the directory serve: for Oracle usage. (Create or upgrade Oracle Schema and Oracle Context as necessary.)
Create add tlona or upgrade existing Orac e Context (Advanced)
Create or upgrade the Oracle Scnerpa (Advanced)
Рис. 16.7. Конфигурирование использования каталогов
614
Гпава 16
No, I wil defer directory usage com guration to another lime
Oracle Net Configm <>Hon As^ittanl: Orrectory Щаце Configwdlinn.Ho Щао|е Schema
q ‘ Ос ЙЖ 7У/' •
For more information pres Help
Gance1
Рис. 16.8. Конфигурирование использования каталогов; схема Oracle отсутствует
The directory doe<?(ho! contain the required Oracle Schema. Directory usage configuration cahnot Coriinue without the correct Oracle Schema
If yr u have auti oration io create directory sche a themyou cah create the required Oracle. Schema how'Would you like toiadd the required Oracle Schema tc the directory?
>’ Ves; want to add therequired Grade Schema ‘.have the authorizationnecess *iry to do о
Oracle Net Configuration Assistant^
The directory has not been configured for this usage. It does not contain at least one Oracle Context, or the version of the Oracle Context is not correct Select how you want to proceed.
* I want to continue without using a directory service.
Г I want to verity the directory service information and try again
ОК
...... Г.-. ......................, , f
Рис. 16.9. Предупреждающее сообщение Служба каталогов не сконфигурирую^
Oracle Net 615
в вашем каталоге отсутствует требуемая схема, вы получите возможность создать схему каталога. Для этого-необходимо иметь соответствующие привилегии. По умолчанию начальным именем учетной записи (пользователя) с соответствующими привилегиями для создания Oracle Internet Directory является “cn=orcladmin”, а паролем — “welcome”. Пароль следует изменить как можно скорее.
Третья и четвертая опции позволяют индивидуально сконфигурировать схему или контекст.
Использование Oracle Net Manager
Функции инструментального средства Oracle Net Configuration Assistant и нового средства Oracle Net Manager (диспетчер Oracle Net) в некоторых случаях дублируют друг друга. Оба инструмента можно использовать для конфигурирования прослушивающего процесса или имени сетевой службы. Оба облегчают конфигурацию службы имен, локального профиля и службы каталогов. Oracle Net Manager не столь удобен, но обеспечивает более детальное конфигурирование.
Как показано на рис. 16.10, на начальном экране Oracle Net Manager представлен список его основных функций:
Naming (именование) — Определяет простые имена, указывающие на местонахождение службы
Рис. 16.10. Экран консоли Oracle Net Manager
616
Гпава 16
Naming Methods (методы именования) — Определяет способ ото-бражения простых имен на дескрипторы соединения
Listeners (прослушивающие процессы) — Поддерживает создание и конфигурирование прослушивающих процессов
Можно применять Oracle Net Manager для управления конфигурационными файлами и тестирования соединений. Используя Oracle Net Manager, можно управлять такими режимами, как Oracle Advanced Security (Расширенная безопасность Oracle). Эта технология обеспечивает сквозное (end-to-end) шифрование данных в распределенной среде. По умолчанию данные передаются по сети открытым текстом, если только не используется шифрование Oracle или аппаратное шифрование.
С помощью мастера имен сетевых служб Oracle (Oracle Net Service Names Wizard) можно создавать новые имена сетевых служб для файла tnsnames.ora. После задания имени сетевой службы мастер предложит ввести сетевой протокол, который вы собираетесь использовать. Имеются следующие возможности:
TCP/IP (Интернет-протокол)
TCP/IP с SSL (защищенный Интернет-протокол)
Named Pipes (сетевой протокол Microsoft)
IPC (локальная база данных)
Oracle Net Manager даст приглашение на ввод параметров, необходимых для установления соединения с базой данных, и изменит локальный файл tnsnames.ora, отразив в нем введенную информацию. В зависимости от версии Oracle будет предложено ввести информацию о хосте, номере порта, имени службы или SID, а также о типе соединения: база данных (по умолчанию), разделяемый или выделенный сервер. Когда конфигурирование нового имени службы будет завершено, Oracle Net Manager предложит его протестировать. Можно также протестировать существующие имена сетевых служб, выбрав имя в списке служб и пункт Test Connection (тестирование соединения) в меню.
При тестировании соединений Oracle Net Manager пробует соеди ниться с базой данных, используя имя пользователя (по умолчанию SCOTT) и пароль (по умолчанию TIGER), после чего сообщает о результа
те этой попытки.
Чем проще конфигурация клиента и сервера и чем меньше отличии значений по умолчанию, тем легче управлять конфигурационными ф лами. Использование Oracle Net Manager упрощает администрирован конфигурационных файлов. Небольшая предосторожность: если пР°р^_ шивающий процесс используется для прослушивания соединении из тернета через межсетевой экран (firewall), следует убедиться в том, этот процесс не оставлен на порте по умолчанию — 1521, поск брешь” в межсетевом экране сделает вас открытым для возможного у ленного переконфигурирования прослушивающего процесса. Бла год незащищенному прослушивающему процессу, в котором использую значения по умолчанию, хакер сможет получить информацию о базе Д ных, что может позволить дискредитировать сайт.
Oracle Net
617
Запуск серверного прослушивающего процесса
Прослушивающий процесс управляется утилитой Listener Control, запускаемой командой Isnrctl. Параметры команды Isnrctl описаны ниже. Для запуска прослушивающего процесса используется команда:
□ Isnrctl start
При этом запускается прослушивающий процесс по умолчанию (с именем LISTENER). Для запуска процесса с другим именем нужно указать это имя в качестве второго параметра команды Isnrctl. Например, если создан прослушивающий процесс MYJLSNR, его можно запустить таким образом:
□ Isnrctl start my_lsnr
После запуска прослушивающего процесса можно убедиться в его функционировании, использовав параметр status утилиты Listener Control. Для выполнения подобной проверки может быть использована следующая команда:
□ Isnrctl status
Если прослушивающий процесс называется в файле listener.ora как-то иначе, чем LISTENER, в команду status необходимо добавить имя процесса. Например, если прослушивающий процесс называется MY_LSNR, команда будет иметь такой вид:
□ Isnrctl status my_lsnr
Выходные данные команды status показывают, запущен ли прослушивающий процесс, и те службы, которые он поддерживает на данный момент, как определено в его файле listener.ora. Кроме того, будет показано расположение файла параметров прослушивающего процесса и файла журнала прослушивающего процесса.
Если нужно узнать, какие процессы уровня операционной системы участвуют в работе прослушивающего процесса, следует воспользоваться приведенными ниже командами. В предлагаемом примере команда ps -ef операционной системы Unix выводит список активных системных процессов. Следующая за ней команда grep tnslsnr исключает строки, не содержащие комбинации “tnslsnr”.
ps -ef | grep tnslsnr
Вот пример выходных данных этой команды:
oracle 4022 1 о 13:36:53 ? 0:00 /oracle/products/102/bin/tnslsnr
LISTENER -inherit
oracle 5469 2419 1 13:56:23 ttypc 0:00 grep tnslsnr
Здесь показаны два процесса: сам прослушивающий процесс и процесс, который его проверяет. Данные первой строки перенесены на следующую строку и могут быть усечены операционной системой.
618
Глава 16
Управление серверным прослушивающим процессом
Утилита управления прослушивающим процессом, Isnrctl, применяется для запуска, остановки и модификации прослушивающего процесса на сервере. Ее командные параметры перечислены в таблице 16.2. Каждая их этих команд может сопровождаться некоторым значением. Для всех команд, за исключением set password, этим значением будет имя прослушивающего процесса. Если оно не указано, используется имя по умолчанию (LISTENER). Находясь в Isnrctl, можно заменить модифицируемый прослушивающий процесс с помощью команды set current_listener.
Примечание С выходом каждой новой версии Oracle Net могут появиться новые или удалены некоторые из имеющихся параметров утилиты Isnrctl.
Можно ввести команду Insrctl саму по себе, чтобы попасть в оболочку (пользовательский интерфейс) утилиты Isnrctl, из которого могут быть выполнены все прочие команды утилиты.
Таблица 16.2. Команды утилиты управления прослушивающим процессом
Команда Описание
CHANGE_PASSWORD Устанавливает новый пароль для прослушивающего процесса. При этом будет предложено ввести старый пароль.
EXIT Выход из Isnrctl.
HELP Выводит список параметров команды Isnrctl. Дополнительные параметры можно увидеть с помощью команд help set и help show.
QUIT Выход из Isnrctl.
RELOAD Позволяет модифицировать службы прослушивающего процесса после его запуска. При этом Oracle Net считывает и использует самый свежий файл listener.ora.
SAVE__CONFIG Впервые появилась в Net8. Создает резервную копию существующего файла listener.ora, после чего обновляет этот файл, используя параметры, измененные посредством Isnrctl.
SERVICES Отображает доступные службы вместе с историей соединений. Для каждой службы будет показано, разрешены ли для нее удаленное администрирование и доступ с авторегистрацией.
SET Устанавливает значения следующих параметров: current—listener — изменяет прослушивающий процесс, параметры которого устанавливаются или отображаются displaymode — изменяет формат и уровень детализации для ко- манд services и status inbdound_connect_timeout — устанавливает время (в секундах),_ отведенное клиенту на завершение соединения с прослушиваю щим процессом до возникновения тайм-аута log_directory — каталог для файла журнала прослушивающего процесса
Oracle Net
619
Команда Таблица 16.2 (Продолжение) Описание
SHOW log Jile — имя файла журнала прослушивающего процесса log_status — разрешает (ON) или запрещает (OFF) запись в журнал password — пароль прослушивающего процесса raw_mode — изменяет формат displaymode, чтобы были показаны все данные; этот режим следует использовать только при взаимодействии с Oracle Support (службой поддержки Oracle) save_config_on_stop — сохраняет изменения конфигурации в файле listener.ora при выходе из Isnrctl startup-waittime — продолжительность (в секундах) бездействия прослушивающего процесса перед ответом на команду Isnrctl start trc_directory — каталог для файла трассировки прослушивающего процесса trcJile — имя файла трассировки прослушивающего процесса trcjevel —- уровень трассировки (ADMIN, USER, SUPPORT или OFF). См. Isnrctl trace Отображает текущие значения параметров. Список параметров тот же, что и для параметра set, за исключением параметра password.
SPAWN Порождает программу, выполняемую под псевдонимом из файла listener.ora.
START Запускает прослушивающий процесс.
STATUS Выводит информацию о состоянии прослушивающего процесса, включая время запуска, имя файла с параметрами, имя файла журнала и поддерживаемые им службы. Команда может быть использована для запроса состояния прослушивающего процесса на удаленном сервере.
STOP Останавливает прослушивающий процесс.
TRACE Устанавливает уровень трассировки прослушивающего процесса. Возможны четыре варианта: OFF, USER (ограниченная трассировка), ADMIN (высокий уровень трассировки) или SUPPORT (для службы поддержки ORACLE).
VERSION Выводит информацию о версиях прослушивающего процесса, TNS и адаптеров протоколов.
Командные параметры, перечисленные в таблице 16.2, обеспечивают высокую степень контроля над прослушивающим процессом (см. примеры ниже). В большинстве примеров сначала вводится команда Isnrctl без параметров. Тем самым пользователь входит в утилиту Isnrctl (что подтверждается появлением приглашения LSNRCTL). Остальные команды вводятся из среды утилиты. В примерах будет показано использование утилиты snrctl для остановки и запуска прослушивающего процесса, а также для выдачи диагностической информации о процессе.
620
Глава 16
Остановка прослушивающего процесса:
О Isnrctl
LSNRCTL> set password naponbj.snr
LSNRCTL> stop
Вывод информации о состоянии прослушивающего процесса:
О Isnrctl status
Для вывода информации о состоянии прослушивающего процесса на другом хосте нужно добавить имя службы этого хоста в качестве параметра команды status. В следующем примере используется имя службы HQ:
□ Isnrctl status hq
Вывод информации о версии прослушивающего процесса:
□ Isnrctl version
Вывод информации о службах, поддерживаемых прослушивающим процессом:
□ Isnrctl
LSNRCTL> set password naponb_lsnr
LSNRCTL> services
Oracle Connection Manager
Диспетчер соединений (Oracle Connection Manager), являющийся частью Oracle Net, действует как маршрутизатор, предназначенный для установления каналов связи между несовместимыми другим способом сетевыми протоколами, а также для использования преимуществ мультиплексирования и управления доступом.
Преимущество Oracle Connection Manager заключается в том, что все серверы не обязательно должны использовать один и тот же коммуникационный протокол. Каждый сервер может использовать протокол, который наилучшим образом подходит к его окружению, и вести обмен данными с другими базами данных. Такое взаимодействие имеет место независимо от коммуникационных протоколов, используемых на удаленных серверах; Oracle Connection Manager учитывает разницу между протоколами. К числу поддерживаемых Oracle Connection Manager протоколов относятся IPC, Named Pipes, SDP, TCP/IP и TCP/IP c SSL.
Для обработки запросов от разных клиентов можно использовать несколько маршрутов доступа. Диспетчер Oracle Connection Manager выби рает наиболее подходящий маршрут с учетом его доступности и сетевой нагрузки. Относительная стоимость каждого пути задается с помощью утилиты Network Manager при настройке Oracle Connection Manager.
В средах интранет можно использовать Oracle Connection Manager в качестве межсетевого экрана для трафика Oracle Net. Можно создать правила фильтрации, которые позволят определенному клиенту осущест влять доступ с помощью Oracle Connection Manager или лишат его такой возможности. Правила фильтрации могут основываться на любом из еле дующих критериев:
Oracle Net
621
и Имена целевых хостов или IP-адреса для серверов
Имена служб целевых баз данных
Имена исходных хостов или IP-адреса для клиентов
Использует ли клиент опцию Oracle Advanced Security
Диспетчер Oracle Connection Manager используется для усовершенствования защиты межсетевым экраном посредством фильтрации доступа клиентов на основе созданных вами правил фильтрации. Например, можно задать, что IP-адресу следует отказывать в доступе, с помощью параметра CMAN_RULES в файле cman.ora.
Для указания дополнительных диагностических параметров, помимо установленных по умолчанию, можно создать вспомогательный файл sqlnet.ora.
Использование Connection Manager
Продукт Oracle Net использует диспетчер соединений для подержания соединений в однородных сетях, что уменьшает число физических соединений, обслуживаемых базой данных. С диспетчером соединений связаны два основных процесса и утилита управления:
CMGW Процесс межсетевого шлюза, который функционирует как концентратор
для диспетчера соединений
CMADMIN Многопоточный процесс, несущий ответственность за все административные задачи и вопросы
CMCTL Утилита, обеспечивающая базовые функции управления для админист-
рирования диспетчера соединений
Процесс CMGW
Процесс межсетевого шлюза диспетчера соединений (Connection Manager Gateway process) регистрируется в процессе CMADMIN и выявляет запросы на установление входящих соединений. По умолчанию этот процесс прослушивает порт 1630, используя для этого протокол TCP/IP. Процесс CMGW инициирует запросы на установление соединений от клиентов к прослушивающим процессам и ретранслирует данные между клиентом и сервером.
Процесс CMADMIN
Многопоточный административный процесс диспетчера соединений (Connection Manager Administrative Process) выполняет множество задач и функций. Он обеспечивает регистрацию процесса CMGW и регистрирует информацию об адресации- маршрута источника, относящуюся к CMGW и прослушивающим процессам. Перед процессом CMADMIN поставлена задача — идентифицировать все прослушивающие процессы, которые поддерживают, как минимум, одну базу данных. Используя Oracle Internet Directory, CMADMIN выполняет следующие задачи:
Определяет локальные серверы
Ведет мониторинг зарегистрированных прослушивающих процессов
622
Гпава 16
и Обслуживает адресную информацию клиентов
в Периодически обновляет кэш диспетчера соединений с информацией о доступных службах
CMADMIN обрабатывает исходную информацию о маршруте, относящуюся к CMGW и прослушивающим процессам.
Конфигурирование диспетчера соединений
Параметры конфигурации для диспетчера соединений находятся в файле сшап.ога, который размещается в каталоге $ORACLE_HOME/network/ admin в системах UNIX или каталоге ORALCE_HOME\net work\admin в системах Windows. Этот файл содержит адреса протоколов прослушивающих процессов межсетевых шлюзов, параметры управления доступом и параметры профиля или управления.
Т аблица 16.3. Параметры CMANjORA
Параметр
ADDRESS
RULE
PARAMETERJJST
ASO_AUTHENTICATION_FILTER
CONNECTION-STATISTICS
EVENT_GROUP
IDLE-TIMEOUT
INBOUND_CONNECT_TIMEOUT
Описание
Указывает адрес протокола (в частности, протокол, хост и порт) для диспетчера соединений.
Определяет перечень правил управления доступом для фильтрации входящих соединений. Подпараметры позволяют организовать фильтрацию по именам исходных и целевых хостов, IP-адресам и именам служб.
Определяет значения атрибутов при переопределении значений по умолчанию. Остальная часть параметров в этом списке представляет подпараметры, используемые для установки значений в параметре PARAMETER-LIST.
Определяет, будет ли использоваться клиентом значение Oracle Advanced Security. Значение по умолчанию OFF.
Указывает, будут ли при выполнении команды SHOW-CONNECTION показаны статистические данные о соединениях. Значение по умолчанию NO.
Специфицирует, какие именно группы событий будут протоколироваться. По умолчанию не протоколируются никакие группы событий.
Специфицирует количество времени (в секундах), в течение которого установленное соединение може оставаться активным, не передавая при этом данны • Значение по умолчанию 0.
Специфицирует (в секундах), как долго прослушивающий процесс диспетчера соединений Oracle ож дает допустимого соединения от клиента или от ДРУ того экземпляра диспетчера соединений Oracle. Зна чение по умолчанию о.
Oracle Net
623
Таблица 16.3 (Продолжение)
Параметр Описание
LOG_DIRECTORY Специфицирует целевой каталог для журнальных файлов диспетчера соединений Oracle. По умолчанию они будут размещены в подкаталоге /network/log домашнего каталога Oracle.
LOG_LEVEL Задает уровень протоколирования (OFF, USER, ADMIN или SUPPORT). Значение по умолчанию SUPPORT.
MAX_CMCTL_SESSIONS Указывает максимальное число одновременно выполняющихся локальных или удаленных сеансов утилиты управления диспетчером соединений Oracle, допустимое для данного экземпляра. Значение по умолчанию 4.
MAX-CONNECTIONS Определяет максимальное число соединений, которое может быть обработано процессом межсетевого шлюза. Значение по умолчанию 256.
MAX_GATEWAY_PROCESSES Определяет максимальное число процессов межсетевого шлюза, которое может поддерживаться экземпляром диспетчера соединений Oracle. Значение по умолчанию 16.
MIN_GATEWAY_PROCESSES Определяет минимальное число процессов межсетевого шлюза, которое может поддерживаться экземпляром диспетчера соединений Oracle. Значение по умолчанию 2.
OUTBOUND_CONNECT_TIMEOUT Специфицирует (в секундах), как долго экземпляр диспетчера соединений Огаг’е ожидает установления допустимого соединения с сервером базы данных или с другим экземпляром диспетчера соединений Oracle. Значение по умолчанию 0.
PASSW0RD_^jWff_3K3ewn/7>/pa Зашифрованный пароль для экземпляра, если он был задан.
REMOTE_ADMIN Указывает, разрешен ли удаленный доступ к диспетчеру соединений Oracle. Значение по умолчанию NO.
SESSION.TIMEOUT Указывает максимальное время (в секундах), отведенное для сеанса пользователя. Значение по умолчанию 0.
TRACE_DIRECTORY Указывает на каталог, в котором должны храниться трассировочные файлы. Значение по умолчанию: подкаталог /network/trace домашнего каталога Oracle.
TRACE_FILELEN Задает (в килобайтах) размер трассировочного файла. Значение по умолчанию 0.
TRACE_FILENO Задает число трассировочных файлов для отслеживания. Эти файлы записываются циклическим методом. Значение по умолчанию 0.
TRACE_LEVEL Задает уровень трассировки, .(OFF, USER, ADMIN или SUPPORT). Значение по умолчанию OFF.
TRACE_T1MESTAMP Добавляет отметку времени к каждому отслеживаемому событию в трассировочном файле. Значение по умолчанию OFF.
624
Гпава 16
Утилита управления диспетчером соединений Oracle (CMCTL)
Утилита управления диспетчером соединений (Connection Manager Control — CMCTL) обеспечивает административный доступ к процессам CMADMIN и CMGW. Диспетчер соединений запускается командой cmctl, имеющей следующий синтаксис:
□ cmctl команда тип__процесса
Команда запуска по умолчанию, выдаваемая в строке приглашения операционной системы, выглядит следующим образом:
□ cmctl start cman
Можно выделить четыре основных типа этих команд:
и Операционные команды, например start
Команды-модификаторы, например set
Информационные команды, например show
Команды, определяющие работу утилиты, например exit
С помощью параметра REMOTE_ADMIN можно управлять удаленными диспетчерами, но не запускать их. В отличие от утилиты Listener (см. выше в данной главе), для диспетчера соединений Oracle пароль нельзя задавать интерактивно. Пароль задается в виде простого текста в файле cman.ora.
Таблица 16.4. Опции команды CMCTL
Опция Описание
ADMINISTER Выбирает экземпляр диспетчера соединений Oracle. Формат команды: administer -с, после чего следует имя экземпляра и (необязательная) фраза using пароль.
CLOSE CONNECTIONS Завершает соединения. Для подлежащих завершению соединений можно указать их источник, назначение, службу, статус и шлюзовой процесс.
EXIT Выход из утилиты управления диспетчером соединений Oracle (CMCTL).
HELP Предоставляет список команд CMCTL.
QUIT Выход из утилиты управления диспетчером соединений Oracle (CMCTL).
RELOAD Динамическое повторное считывание параметров и правил из файла cman.ora.
RESUME GATEWAYS Возобновляет выполнение приостановленных процессов меж сетевых шлюзов.
SAVE PASSWORD Сохраняет текущее значение пароля в файле конфигурационных параметров cman.ora.
Oracle Net
625
Таблица 16.4 (Продолжение)
Опция Описание
SET Выводит список параметров, которые могут быть модифицированы во время работы CMCTL Можно задать значения параметров aso_authentication_tilter, connection_statistics, event, idle. timeout, inbound_connect_timeout, log_directory, log Jevel, outbound_connect_timeout, password, sessionjimeout, trace, directory и tracejevel.
SHOW Выводит список параметров, значения которых могут быть отображены. Можно задать показ индивидуальных значений, указав их после команды SHOW (например, SHOW TRACE-LEVEL).
SHOW ALL Выводит значения всех параметров и правил.
SHOW DEFAULTS Выводит значения параметров по умолчанию.
SHOW EVENTS Выводит события.
SHOW GATEWAYS Выводит текущий статус конкретного процесса межсетевого шлюза.
SHOW PARAMETERS Выводит текущие значения параметров.
SHOW RULES Выводит текущий список контроля доступа.
SHOW SERVICES Выводит информацию о службах диспетчера соединений Oracle, в том числе об обработчиках шлюзов и о количестве соединений.
SHOW STATUS Выводит базовую информацию об экземпляре и о его текущих статистических показателях.
SHOW VERSION Выводит текущую версию и имя утилиты CMCTL.
SHUTDOWN Закрывает конкретные процессы шлюзовые процессы либо весь экземпляр диспетчера соединений Oracle.
STARTUP Запускает диспетчер соединений Oracle.
SUSPEND GATEWAY Не позволяет шлюзовым процессам принимать новые клиентские соединения.
Если диспетчер соединений запущен, его может использовать любой клиент, у которого в файле tnsnames.ora параметр SOURCE_ROUTE имеет значение YES. Диспетчер соединений снижает требования к системным ресурсам, повторно используя физические соединения при установлении логических соединений.
Именование каталогов с помощью Oracle Internet Directory
Средство Oracle Internet Directory позволяет упростить поддержку совместимых с LDAP серверов каталогов в целях централизации управления разрешением сетевых имен в распределенной сети Oracle. Для локализованного управления по-прежнему имеется файл tnsnames.ora.
626
Гпава 16
В файле Idap.ora, находящемся в каталоге $ORACLE_HOME/network/ admin в системах Unix или в каталоге ORACLE_HOME\ network\admin в системах Windows, хранятся параметры конфигурации для доступа к серверу каталога. В Oracle поддерживаются и Oracle Internet Directory, и Microsoft Active Directory.
Для разрешения дескриптора соединений с помощью централизованного сервера каталога необходимо выполнить следующие шаги:
1. Oracle Net от имени клиента контактирует с сервером каталога в целях получения разрешения идентификатора соединения в дескриптор соединения.
2. Сервер каталога должен получить идентификатор соединения, найти соответствующий дескриптор соединения и возвратить дескриптор в Oracle Net.
3. Oracle Net использует разрешенный дескриптор для выполнения запроса на соединение с прослушивающим процессом.
Для хранения своих данных сервер каталога использует древовидную структуру. Каждый узел на дереве является элементом (entry). В данном случае применяется иерархическая структура элементов, называемая информационным деревом каталога (directory information tree — DIT), а каждый элемент идентифицируется уникальным отличительным именем (distinguished name, DN), которое сообщает серверу каталогов точное местонахождение элемента. DIT можно структурировать, чтобы использовать существующую систему имен доменов (Domain Name System — DNS), организационные или географические признаки или схему именования в Интернете.
С помощью DIT, построенного по организационному признаку, DN для сервера HR могло бы выглядеть следующим образом: (dn:cn=HR, cn=OracleContext, dc=us, dc=ourcompany, dc=com). Самый нижний компонент DN занимает в DIT крайнюю позицию слева, перемещение производится постепенно снизу вверх. На приведенном рисунке представлено DIT для данного случая:
dc=com
с!с=<компания>
dc=uk
dc=us
cn=OracleContext
cn=hr
Наиболее часто встречающимися атрибутами LDAP являются
CommonName (сп) Стандартное (общее) имя элемента
Country (с) Название страны
Domain component (de) Доменный компонент
Oracle Net
627
a Organization (о) Название организации
и OrganizationalUnitName (ou) Название подразделения внутри организации
Примечание Значение cn=OracleContext является специальным элементом на сервере каталога, который поддерживает активизируемые каталогом средства, например именование каталогов. Oracle Context создается с помощью Oracle Net Configuration Assistant (см. выше в данной главе).
Настройка Oracle Internet Directory
Для решения задач первоначального конфигурирования можно применять Oracle Net Configuration Assistant или Oracle Net Manager. После задания схемы каталогов и Oracle Context можно приступить к регистрации имен служб с помощью службы каталогов, используя Oracle Net Manager. Область Oracle Context находится в корне поддерева каталога, где хранится вся информация, относящаяся к программному обеспечению Oracle.
После инсталляции Oracle Context создаются два объекта: OracleDBCreators и OracleNetAdmin. Объект OracleDBCreators создается с DN вида (cn= OracleDBCreators, cn=OracleContext). С помощью Oracle Database Configuration Assistant любой пользователь, являющийся членом OracleDBCreators, может зарегистрировать элемент сервера базы данных или элемент клиента каталога. С помощью Oracle Net Manager пользователь, являющийся членом OracleNetAdmins, может создавать, изменять и удалять имена сетевых служб и изменять атрибуты Oracle Net для серверов базы данных. Администратор каталога имеет право добавлять пользователей в эти группы.
Клиенты, которые хотят просматривать информацию в каталоге, должны удовлетворять следующим минимальным требованиям:
Иметь конфигурацию, позволяющую использовать сервер каталога
Иметь доступ к элементам Oracle Net в Oracle Context
и Иметь анонимную аутентификацию на сервере каталога
Для просмотра информации клиенты могут пользоваться стандартными именами серверов базы данных и элементами сетевых служб; в противном случае в строке соединения потребуется дополнительная информация о местонахождении каталога.
Использование простого именования соединений
Начиная с Oracle Database 10g, можно использовать простой метод именования соединений для устранения необходимости наличия файлов с именами служб в средах TCP/IP. Клиенты могут подключаться к серве-I рам баз данных, указывая полную информацию о соединении в представляемых ими строках соединения (connect strings) в формате
□ сог с имя-ПОльзователя/пароль@[//]хост[: порт][/имя службы]
628
Гпава 16
Идентификатор соединения содержит следующие элементы:
Элемент Описание
// Необязательный. Указывает на// перед URL.
хост Обязательный. Специфицирует имя хоста или 1Р-адрес.
порт Необязательный. Специфицирует номер порта или использует значение по умолчанию (1521).
имя_службы Необязательный. Специфицирует имя службы. Значением по умолчанию является имя хоста для сервера базы данных.
К примеру, можно подключиться к службе LOC, используя такой синтаксис:
□ connect имя пользователя/пароль@Ьц:1521/1ос
Для использования простого именования соединений требуется, чтобы на клиенте было инсталлировано программное обеспечение Oracle Net Services 10g. Необходимо применять протокол TCP/IP; не поддерживаются никакие возможности, для реализации которых требуются более “продвинутые” дескрипторы соединения.
Для соединений URL или JDBC в качестве префикса соединения следует использовать двойной слеш (//):
□ connect имя_пользователя/пароль@[//]хост[: порт][/имя_службы]
Простое именование соединений автоматически конфигурируется при инсталляции. Для этого достаточно убедиться в том, что в файле sqlnet.ora в список значений NAME.DIRECTORY_.PATH добавлено EZCONNECT.
Использование связей баз данных
Для поддержки часто используемых соединений с удаленными базами данных нужно создавать так называемые связи баз данных (database links). Эти связи определяют, какой дескриптор должен использоваться для соединения, а также (не обязательно) имя пользователя, с которым устанавливается соединение в удаленной базе данных.
Связь баз данных обычно применяется для создания локальных объек тов (например, представлений или синонимов), которые будут обращать ся к удаленным базам данных по линиям связи сервер/сервер. Локальные синонимы удаленных объектов обеспечивают прозрачность их местона хождения для локальных пользователей. Когда в операторе SQL BCJP^4 ется ссылка на связь баз данных, открывается сеанс в удаленно и оператор выполняется там. Затем данные возвращаются, а удален сеанс может оставаться открытым на тот случай, если он потребуется е раз. Связи баз данных могут создаваться как публичные (public), koi op доступны всем пользователям локальной базы данных, так и приватнь (private).
В следующем примере создается частная связь баз данных с именс HR LINK:
Oracle Net
629
□ create database link HR__LINK connect to HR identified by PUFFINSTUFF using ‘loc’;
Как видно из этого примера, команда create database link имеет три параметра:
и Имя связи (в данном случае HR_LINK)
и Учетная запись, с которой устанавливается соединение
о Имя службы
Для создания публичной связи баз данных в команду create database link нужно добавить ключевое слово public:
□ create public database link HR_LINK
connect to HR identified by PUFFINSTUFF
using ‘loc’;
Примечание Лучшие образцы применения связей баз данных могут значительно выиграть от включения фразы using, но не фразы connect to. Ведь впоследствии можно было бы создать приватную связь баз данных с тем же самым именем, куда будет включена фраза connect to, а не using. Последующие изменения в имени службы потребуют повторного создания только публичной связи, в то время как приватная связь и пароль пользователя останутся неизменными.
Если экземпляр LOC будет перемещен на другой сервер, то связи баз данных можно перенаправить на новое место хранения LOC, просто распространив файл tnsnames.ora, отражающий это изменение, или пересмотрев листинг на сервере каталога. Можно сгенерировать пересмотренный элемент для файла tnsnames.ora или сервера каталога с помощью либо Oracle Net Configuration Assistant, либо Oracle Net Manager (cm. выше в данной главе).
Для использования этих связей-нужно просто добавить их в качестве суффиксов к именам таблиц в командах. В следующем примере создается локальное представление удаленной таблицы с использованием связи баз данных HRJLINK:
□ create view LOCAL_EMPLOYEE_VIEW as
select * from EMPLOYEES .LINK
where Office = ‘ANNAPOLIS’;
Фраза from этого примера ссылается на EMPLOYEE@HR_LINK. Поскольку связь HRJLINK содержит имена сервера, экземпляра и владельца, го имя GON для таблицы известно. Если имя учетной записи не указано, будет применено имя учетной записи пользователя. Если связь HR_ LINK была создана без фразы connect to, для связи с удаленной базой данных оудут использоваться текущее имя пользователя и его пароль.
В данном примере представление было создано для ограничения числа записей, которые могут считываться пользователями. Если такого ог-
630
Гпава
раничения не требуется, вместо представления можно использовать синоним:
□ create public synonym EMPLOYEE for EMPLOYEE@HR_LINK;
Запросы локальных пользователей, обращающихся к локальному общему синониму EMPLOYEE, будут автоматически перенаправляться к таблице EMPLOYEE в экземпляре LOC на сервере HQ. Тем самым достигается прозрачность местонахождения объекта.
По умолчанию в одном операторе SQL можно использовать до четырех связей баз данных. Этот предел можно повысить с помощью параметра OPENJLINKS файла init.ora базы данных.
Настрсйка Oracle Het
Настройка приложений Oracle Net достаточно проста: по мере возможности нужно уменьшать объем данных, передаваемых по сети, особенно в приложениях для оперативной обработки транзакций. Кроме того, нужно сокращать количество запросов к базе данных. Рекомендуются следующие основные действия:
Использование распределенных объектов, например материализованных представлений, для тиражирования статических данных в удаленные базы.
Использование процедур, позволяющих уменьшить объем данных, передаваемых по сети. Вместо пересылки данных в прямом и обратном направлении возвращается лишь сообщение о статусе процедуры.
Использование по возможности серверов одного типа для исключения необходимости в диспетчерах соединений.
Только для приложений OLTP — использование разделяемых серверов для поддержки большего числа клиентов при меньшем числе процессов.
Размер буфера, используемого в Oracle Net, должен быть согласован с размерами пакетов, используемых сетевыми протоколами (например, TCP/IP). Если по сети передаются большие пакеты, они могут оказаться фрагментированными. Поскольку каждый пакет содержит заголовок,
уменьшение фрагментации снижает сетевой трафик.
Можно настраивать размеры буферов сервисного и транспоргног уровней. Спецификация для буфера данных сервисного уровня называе ся SDU (Session Data Unit — блок данных сеанса); если опа изменяется, э должно быть указано в конфигурационных файлах клиента и серверу Oracle Net формирует данные в буферы размера SDU, гак что изменен этого размера может повысить производительность. Размер буфера висного уровня определяется параметром SDU и в данном случае ра 2 Кбайт. Если приходится часто посылать значительно большие по раз* ру сообщения, SDU можно увеличить (максимум до 32 Кбайт).
Для конфигурирования клиента, чтобы он использовал отличаюВХ ся от значения по умолчанию SDU, нужно добавить новое значение S
Oracle Net
631
в конфигурационные файлы клиента. Чтобы применить изменение ко всем соединениям, надо добавить в sqlnet.ora следующий параметр:
□ DEFAULT_SDU_SIZE=32767
Для применения изменений только к определенным именам служб нужно модифицировать соответствующие им элементы в файле tnsnames.ora:
□ LOC -(DESCRIPTION^
(SDU-32767)
(ADDRESS-
(PROTOCOL=TCP)
(HOST-HQ)
(PORT-1521))
(CONNECT DATA=
(SERVICE_NAME=LOC)))
На сервере базы данных следует сконфигурировать настройку значения SDU по умолчанию в файле sqlnet.ora:
□ DEFAULT_SDU_SIZE=32767
Для процессов разделенного сервера нужно добавить установку SDU к установке DISPATCHERS в экземпляре файла параметров инициализации:
□ DISPATCHERS-”(DESCRIPTION-(ADDRESS-(PROTOCOL-tcp))(SDU=32767))"
Для процессов выделенного сервера отредактируйте записи в файле listener.ora:
□ ЫЬ_Х.1^_имя_прослушивающего_процесса-(SID_LIST =
(SID_DESC=
(SDU-8192)
(SID-NAME = loc)
Oracle Net Services обеспечивает поддержку протокола SDP для высокоскоростных сетей Infiniband. Приложения, в которых используется SDP, переносят большую часть нагрузки, связанной с обменом сообщениями, на сетевую интерфейсную карту, тем самым, снижая требования приложения к ЦП. Если используется высокоскоростная сеть Infiniband, например для взаимодействия между различными уровнями приложений, нужно обратиться к документации, где можно найти детали конфигурирования оборудования и программного обеспечения.
Ограничение использования ресурсов
Для ограничения влияния, оказываемого на систему неавторизованными пользователями, можно сократить время, в течение которого ресурсы могут быть заняты до аутентификации. Ограничивающие время параметры (см. выше в данной главе) помогают смягчить проблемы с производи-этими попытками неавторизованного досту-па. В файле listener.ora нужно задать параметр INBOUND_CONNECT
632
Гпава 16
Т1МЪ01]Т_г(мя_прослушива70щего_проу!есса1 чтобы можно было принудительно завершать соединения, которые не были аутентифицированы прослушивающим процессом в течение установленного промежутка времени. Неудачные соединения должны быть зарегистрированы в журнальном файле прослушивающего процесса. В файле sqlnet.ora для сервера следует задать параметр SQLNET.INBOUND_CONNECT_TIMEOUT дЛя прекращения попыток соединения, в результате которых в течение установленного промежутка времени не удается установить и аутентифицировать соединение. Для параметра SQLNET.INBOUND_CONNECT_ TIMEOUT нужно задать более высокое значение, чем для параметра INBOUND_CONNECTJTIMEOUT_ww^_n/)oc/zywmetfra?^o_n/>o^co2 в файле listener.ora.
Отладка проблем при соединении
Для соединений Oracle Net требуется ряд правильно сконфигурированных коммуникационных механизмов. Соединения включают в себя связь между двумя хостами, соответствующую идентификацию служб и баз данных и правильное конфигурирование серверных прослушивающих процессов. При возникновении проблем при использовании Oracle Net необходимо исключить как можно большее число этих компонентов.
Начинать следует с проверки доступности хоста, с которым требуется установить соединение. Это делается с помощью следующей команды:
□ telnet имяусоста
После успешного выполнения этой команды будет получено приглашение ввести имя учетной записи и пароль на удаленном хосте. Если есть доступ к команде ping, можно использовать ее. Приведенная ниже команда проверит доступность удаленного хоста и вернет сообщение о состоянии:
□ ping имя_хоста
Если хост доступен по сети, следующим шагом должна стать проверка работы прослушивающего процесса. Одновременно можно проверить используемые параметры; это важно, если производится попытка удален ного доступа с автоматическим регистрационным именем. Такую инфор мацию можно получить с помощью команды Isnrctl status:
□ Isnrctl status имЯ-Сетевой-Службы
Фраза имя_сетевой_службы относится к имени службы на удаленно^ сервере. Если не использовать эту фразу, команда возвратит состояни (статус) прослушивающего процесса па локальном сервере.
Эти две проверки — досгупности хоста и прослушивающего прои са — на 95% разрешат проблемы Oracle Net при установлении соедин< между двумя серверами. Остальные проблемы вытекают из сложност со спецификацией используемой базы данных. К этим проблемам оТ1^е сятся: неправильное сочетание “имя учетной записи/пароль”, а также функционирующие или требующие восстановления базы данных.
Для проверки Oracle Net на возможность соединения с прослушиваю^ щим процессом удаленной базы данных можно использовать предостав
Oracle Net
633
ляемую Oracle утилиту tnsping. У этой утилиты есть два параметра: имя службы, с которой требуется соединиться, и число попыток соединения. В выходные данные утилиты tnsping включен листинг, показывающий время, требующееся для соединения с удаленной базой данных.
Например, чтобы определить, доступна ли база данных, идентифицированная в локальном файле tnsnames.ora именем службы HQ, нужно использовать следующую команду:
□ tnsping HQ
Для тестирования 10 последовательных соединений с базой данных HQ можно использовать такую команду:
□ tnsping hq 10
Помимо tnsping, для отслеживания маршрута соединения с удаленной базой данных можно использовать утилиту tcroute. Утилита tcroute составляет отчет об адресах TNS для каждого узла, через который проходит сообщение, и сообщает обо всех произошедших ошибках. Команда имеет следующий формат:
□ tcroute имя_сетевого сервиса
В коммуникациях клиент/сервер для отладки проблем при соединении применимы те же самые принципы. Сначала следует проверить, доступен ли удаленный хост; большинство средств связного программного обеспечения для клиентов имеют в своем составе команды telnet или pinj. Если удаленный хост недоступен, проблема может гнездиться на клиентской стороне. Нужно проверить, в состоянии ли другие клиенты получить доступ к хосту, на котором размещается база данных. Если они не могут сделать это, проблема может быть на стороне сервера и необходимо выполнить проверку сервера, его прослушивающих процессов и баз данных.
с
ПРАВЛЕНИЕ БОЛЬШИМИ
БАЗАМИ ДАННЫХ
В главе 6 обсуждались табличные пространства типа Bigfile. В частности, в ней шла речь о том, что эти пространства не только позволяют сделать полный размер базы данных намного превышающим то, что было возможно в предыдущих версиях Oracle, но и значительно облегчают администрирование за счет переноса точки обслуживания с файла данных на табличное пространство.
В главе 4 был представлен обзор среды автоматического управления хранением данных (Automatic Storage Management — ASM) и того, как эта среда упрощает администрирование, улучшает производительность и повышает доступность. АБД могут добавить один или несколько дисковых томов к быстро растущей, очень большой базе данных (Very Large Database — VLDB), не прибегая к остановке экземпляра.
В данной главе мы возвратимся ко многим из названных выше возможностей базы данных, но теперь мы сделаем ударение на том, как можно их использовать в средах VLDB. Эти возможности весьма полезны во всех инсталляциях Oracle, особенно в базах данных, где наиболее интенсивно используемым ресурсом является количество распределенного дискового пространства. Сначала мы пересмотрим концепции, стоящие за табличными пространствами типа Bigfile, и более глубоко погрузимся в то, как они конструируются с использованием нового формата ROWID. Кр° ме того, мы покажем, как переносимые табличные пространства стано вятся ясно выраженным преимуществом в средах VLDB, так как при их использовании удается обойти некоторые шаги экспорта/импорта, гРе бовавшиеся в предыдущих (до Огас1е9г) версиях для переноса контентов табличного пространства из одной базы данных в другую. Когда табли ные пространства в средах VLDB приближаются к экзабайтным разы рам, дисковое пространство, требующееся при традиционных операция-экспорта/импорта, и время, необходимое для выполнения экспорта, превосходят все разумные пределы и превращаются в запретительны факторы. Если же используется Oracle 10g, становится возможным пере носить табличные пространства даже между различными аппаратными
Управление большими базами данных
635
и софтверными платформами с минимальными дополнительными усилиями или вообще без каких бы то ни было усилий.
Затем мы рассмотрим различные типы нетрадиционных (не использующих неупорядоченное распределение памяти) таблиц, которые часто оказываются широко используемыми в средах VLBD. Индекс-таблицы (ЮТ) объединяют лучшие возможности традиционных таблиц с быстрым доступом по индексу в одном сегменте; мы рассмотрим некоторые примеры того, как в Oracle 10g можно секционировать ЮТ. Глобальные временные таблицы существенно сокращают использование дискового пространства в табличных пространствах отката и журнальных файлах для целей восстановления, так как контенты таблиц сохраняются только на время выполнения транзакции или сеанса. Внешние таблицы упрощают доступ к данным, хранящимся не в форматах Oracle, как будто они хранятся в таблицах. Начиная с Oracle 10g, внешние таблицы могут создаваться с применением помпы данных Oracle (Oracle Data Pump). И, наконец, количество дискового пространства, занимаемого таблицей, можно значительно сократить, если использовать внутренние алгоритмы компрессирования, когда строки загружаются с помощью оператора загрузки в прямом режиме SQL*Loader и оператора create table as select.
Секционирование таблиц и индексов повышает не только производительность запросов, по и управляемость таблиц в средах VLDB, позволяя выполнять операции по обслуживанию одного раздела, в то время как пользователи могут получать доступ ко всем остальным разделам таблицы. Ниже будут рассмотрены все различные типы схем секционирования, включая и некоторые новые возможности секционирования Oracle 10g хеш-секционированные глобальные индексы, секционированные по списку ключей ЮТ и LOB поддерживаются во всех типах секционированных ЮТ.
Битовые индексы, доступные с Oracle 7.3, обеспечивают преимущества при запросах не только для таблиц со столбцами с низкой кардинальностью, но и для специальных битовых индексов соединения (bitmap join indexes), которые предварительно объединяют две или большее количество таблиц по одному или нескольким столбцам. В Oracle 10gустранено одно из препятствий для использования битовых индексов в средах с интенсивными вставками (по одной строке), обновлениями и удалениями — уменьшены проблемы с производительностью, обуславливавшиеся вопросами фрагментации битовых индексов.
Помпа данных Oracle, появившаяся в Oracle 10g, “набирает обороты” там, где начинают буксовать традиционные функции и методы экспорта/импорта. Одна из множества опций, поддерживаемых помпой данных Oracle, выполняет экспорт непосредственно в другой экземпляр; кроме того, многие операции помпы данных происходят на сервере базы данных, а не клиентской станции.
Создание табличных пространств в средах VLD
Соображения по созданию табличных пространств в малых базах данных (диапазон до одного терабайта) так же применимы и к VLDB: нужно распределить операции ввода/вывода по множеству устройств, использовать диспетчер логических томов (Logical Volume Manager — LVM)
636
Гпава 17
с возможностями RAID или применить ASM. Поскольку табличные пространства типа Bigfile содержат только один файл данных, формат ROWID для хранящихся в табличных пространствах объектов несколько другой: он позволяет иметь табличное пространство размером до 8 млн терабайт, в зависимости от размера блока табличного пространства.
Табличные пространства типа Bigfile прекрасно подходят для среды, в которой применяется ASM, Oracle Managed Files (OMF) и диспетчер восстановления (RMAN) с Flash Recovery Area. См. главу 4, где дается детальный обзор ASM; главу 13, где представлен диспетчер восстановления с точек зрения командной строки и ЕМ Database Control и предлагается использовать для создания всех резервных копий Flash Recovery Area; и, наконец, главу 6, где описывается OMF с точки зрения управления дисковым пространством.
Основы табличных пространств типа Bigfile
Если использовать табличные пространства типа Bigfile с блоком данных размером 32 Кбайт, то файл данных может иметь размер до 128 Тбайт, а максимальный размер базы данных может достигать 8 Эбайт. Напротив, база данных, использующая только обычные табличные пространства, может иметь файлы данных с максимальным размером, не превышающим 128 Гбайт, и, следовательно, максимальный размер базы данных не может превышать 8 Пбайт. Поскольку табличное пространство типа Bigfile может иметь только один файл данных, перед АБД никогда не встанет вопрос о том, что нужно добавить в табличное пространство еще один файл данных или автоматически расширить единственный файл данных этого табличного пространства. Если используется ASM или OMF, отпадает даже необходимость знать имя этого единственного файла данных. %
При условии, что максимальное число файлов данных в базе данных не превышает 65535, а количество блоков в файле данных табличного пространства типа Bigfile равно 232, можно вычислить максимальное количество дискового пространства (М) в одиночной базе данных Oracle как максимальное количество файлов данных (D), умноженное на максимальное количество блоков в файле данных (F) и на размер блока данных табличного пространства (В):
М = D * F * В
Следовательно, при заданных максимальном размере блока и макси мальном количестве файлов данных максимальный размер базы данных, составляет
65 535 (файлов данных) * 4 294 967 295 (блоков в файле данных)
32 768 (размер блока) = 9 223 231 299 366 420 480 = 8 Эбайт
Для обычных табличных пространств число блоков в файле данных равно всего 222 Следовательно, вычисления дают
65 535 (файлов данных) *4 194 304 (блоков в файле данных) *
32 768 (размер блока) = 9 007 061 815 787 520 = 8 Пбайт
Управление большими базами данных
637
В таблице 17.1 приведены сравнения максимальных размеров файлов данных для табличных пространств типа Bigfile и обычных табличных пространств в зависимости от размера блока табличного пространства.
Создание и модификация табличных пространств типа Bigfile
Ниже приводится пример создания табличного пространства типа Bigfile в среде, где не применяется ASM:
□ SQL> create bigfile tablespace dmarts
2 datafile ‘/u05/oradata/dmarts.dbf’ size 2500g
3 autoextend on next 500g maxsize unlimited
4 extent management local uniform size 50m
5 segment space management auto;
Tablespace created.
В приведенном выше примере можно заметить, что фразы extent management и segment management заданы явно, даже несмотря на то, что для управления пространством в сегментах auto является значением по умолчанию; табличные пространства типа Bigfile должны создаваться как локально управляемые с автоматическим управлением пространством в сегментах. Поскольку применяемой по умолчанию стратегией выделения памяти для табличных пространств типа Bigfile является autoallocate, необходимо изменить стратегию на uniform, как в примере, с большим размером экстента, если известно, что размер табличного пространства лежит в терабайтном диапазоне и насколько большой может быть таблица с учетом модели роста. Существует эмпирическое правило: тип autoallocate более подходит для табличных пространств с неопределенными использованием таблиц и моделями роста.
Даже если файлу данных для этого табличного пространства типа Bigfile предоставлена возможность автоматического расширения “до бесконечности”, дисковый том, на котором размещается этот файл данных, имеет ограниченную емкость; когда это происходит, может потребоваться перенести это табличное пространство на другой дисковый том. Следовательно, можно оцепить все преимущества использования ASM: в дисковую группу, в которой размещается файл данных, можно легко добавлять новые дисковые тома, и Oracle будет автоматически перераспределять содержимое файла данных и обеспечивать рост табличного пространства — причем все это происходит в то время, как база данных и, конечно, само табличное пространство продолжают быть доступными пользователям.
По умолчанию табличные пространства создаются, как обычные табличные пространства; можно специфицировать тип табличного пространства по умолчанию при создании базы данных или указать его в любой момент времени с помощью команды alter database:
□ SQ alter database set default bigfile tablespace;
Database altered.
638
Глава 17
Таблица 17.1. Максимальные размеры файла данных табличного пространства
Размер блока табличного пространства Максимальный размер файла данных для обычных файлов Максимальный размер файла данных для больших файлов
2К 8GB 8ТВ
4К 16GB 16ТВ
8К 32GB 32ТВ
16К 64GB 64ТВ
32К 128GB 128ТВ
Формат ROWID для табличных пространств типа Bigfile
Чтобы облегчить организацию большего адресного пространства для табличных пространств типа Bigfile для строк, входящих в такие табличные пространства таблиц, используется новый, расширенный формат ROWID. Вернемся к формату ROWID для обычных табличных пространств в предыдущих версиях Oracle и для Oracle 10g. Формат ROWID для обычных табличных пространств состоит из четырех частей:
□ 000000 FFF ВВВВВВ RRR
Табличное пространство типа Bigfile имеет всего один файл данных, и относительный номер файла данных всегда равен 1024. Поскольку относительный номер файла данных зафиксирован, нет необходимости делать его частью ROWID; в результате часть ROWID, ранее использовавшаяся для записи относительного номера файла данных, может быть теперь использована для увеличения размера поля для номера блока. Конкатенация относительного номера файла данных (FFF) и номера блока для обычного файла данных (ВВВВВВ) приводит к созданию новой конструкции, которая называется зашифрованным номером блока (encoded block number). Следовательно, теперь формат ROWID для больших файлов состоит только из трех частей:
П 000000 LLLLLLLLL RRR
DBMS_R0WID и табличные пространства типа Bigfile
Поскольку теперь в базе данных могут сосуществовать два различный типа табличных пространств с соответствующими форматами ROW , в пакет DBMS_ROWID были внесены некоторые изменения.
Имена процедур из пакета DBMS_ROWID остались теми же, и они функционируют, как и ранее, за исключением нового параметра -TYPE_IN, идентифицирующего тип табличного пространства, к которо му принадлежит конкретная строка; параметр TS__TYPE_IN может прини мать одно из двух значений — BIGFILE или SMALLFILE.
В качестве примера извлечения ROWID из таблицы в составе таблиц ного пространства типа Bigfile рассмотрим таблицу OE.ARCH_ORDEIL в табличном пространстве типа Bigfile, которое называется USERS2:
Управление большими базами данных
639
□ SQL> select tablespace_name, bigfile from dba_tablespaces 2 where tablespace_name = ‘USERS2’;
TABLESPACE_NAME
USERS2
BIG
YES
Tаблица 17.2. Формат ROWID для обычных файлов
Компоненты ROWID Описание
для обычных файлов
000000 Номер объекта данных, идентифицирующий сегмент базы дан-
ных (типа таблицы, индекса или материализованного представления)
FFF Относительный'номер файла данных в табличном пространст-
ве (для файла данных, содержащего эту строку)
ВВВВВВ Блок данных, содержащий эту строку (относительно файла
данных)
RRR Номер слота (или строки) для строки в блоке
Как и в случае таблиц в табличном пространстве с обычными файлами для предыдущих версий Oracle и Oracle 10g, для извлечения полного ROWID можно использовать псевдостолбец ROWID. Формат ROWID различен для таблиц с обычными и с большими файлами даже притом, что длина ROWID остается той же самой. Кроме того, запрос будет извлекать номер блока в десятичном формате:
□ SQL> select rowid,
2 dbms_rowid, rowid_block_number (rowid, ‘BIGFILE’) blocknum,
3 order.id, customerJLd
4 from oe.arch_orders
5 where rownum <11;
ROWID BLOCKNUM ORDER_ID CUSTOMER_ID
AAANw4AAAAAAACsAAA 172 2458 101
AAANw4AAAAAAACsAAB 172 2397 102
AAANw4AAAAAAACsAAC 172 2454 103
AAANw4AAAAAAACsAAD 172 2354 104
AAANw4AAAAAAACsAAE 172 2358 105
AAANw4AAAAAAACsAAF 172 2381 106
AAANw4AAAAAAACsAAG 172 2440 107
AAANw4AAAAAAACsAAH 172 2357 108
AAANw4AAAAAAACsAAI 172 2394 109
AAANw4AAAAAAACsAAJ 172 2435 144
10 rows selected
640
Гпава 17
Для строки с ORDER-ID, равным 2358, номер объекта данных (data object number) равен AAANw4, зашифрованный номер блока равен AAAAAAACs, а номер строки (или слот) для строки — АДЕ; переведенный в десятичный формат номер блока равен 172.
Примечание В R0WID используется кодирование по основанию 64 (base-64 encoding).
К числу других процедур пакета DBMS_ROWID, в которых для идентификации типа табличного пространства используется переменная TS__ TYPE_IN, относятся процедуры ROWID_INFO и ROWID_RELATIVE_ FNO.
Таблица 17.3. Формат R0WID для больших файлов
Компоненты R0WID Описание
для больших файлов
000000 Номер объекта данных, идентифицирующий сегмент базы данных
(типа таблицы, индекса или материализованного представления)
LLLLLLLLL Зашифрованный номер блока данных (относительный в таблич-
ном пространстве) и уникальный в табличном пространстве
RRR Номер слота (или строки) для строки в блоке
Т аблица 17.4. Параметры R0WIDJNF0
Параметр R0WID JNFO__________Описание________________________________________
R0WIDJN Подлежащий описанию R0WID
TS_TYPEJN Тип табличного пространства (SMALLFILE или BIGFILE)
ROWID_TYPE Возвращает тип R0WID (ограниченный или расширенный)
OBJECT-NUMBER
RELATIVE-FNO
BLOCK-NUMBER
ROWJWMBER
Возвращает номер объекта данных
Возвращает относительный номер файла
Возвращает номер блока в этом файле
Возвращает номер строки в этом блоке
Процедура ROWIDJNFO должна быть использована в анонимной или в именованной процедуре, поскольку она не является функцией и возвра щает пять атрибутов специфицированного ROWID.
В следующем примере используется анонимный блок PL/SQL для выд^ ления значений OBJECT_NUMBER, RELATIVE_FNO, BLOCK_NUMBEK и ROW_NUMBER для строки таблицы OE.ARCH_ORDERS:
□ variable object-number number variable relative—fno number variable block—number number variable row_number number
Управление большими базами данных
641
declare
oe_rownum rowid;
rowid_type number;
begin
select rowid into oe.rownum from oe.arch_orders where order_id = 2358 and rownum = 1;
dbms_rowid.rowid_info (rowid_in => oe_rownum, ts_type_in => ‘BIGFILE’, rowidjtype => :rowid_type, object_number => :object_number, relative_fno => :relative_fno, block_number => :block_number, row_number => :rowjiumber);
end;
PL/SQL procedure successfully completed.
SQL> print
OBJECT-NUMBER
56376
RELATIVE_FNO
1024
BLOCK_NUMBER
172
ROW_NUMBER
4
SQL>
Значение RELATIVE_FNO для табличных пространств типа Bigfile всегда равно 1024, a BLOCK_NUMBER — 172, как было показано в предыдущем примере, в котором использовалась функция DBMS_ROWID.ROWID__ BLOCKJNUMBER.
Использование DBVERIFY с табличными пространствами типа Bigfile
Утилита DBVERIFY, доступная, начиная с Oracle версии 7.3, проверяет логическую целостность находящейся в автономном режиме базы данный- Файлы могут быть только файлами данных; DBVERIFY не может анализировать оперативные или архивные файлы журналов базы данных. В предыдущих версиях Oracle утилита DB VERIFY мпгт ---
642
Глава 17
все файлы данных для табличного пространства одновременно с порождением множества команд DBVERIFY. Но, поскольку табличные пространства типа Bigfile могут содержать всего один файл данных, DBVERIFY была усовершенствована и теперь она может параллельно анализировать части файлов данных табличных пространств типа Bigfile.
При использовании команды dbv в строке приглашения Unix или Windows можно применять два новых параметра — START и END, представляющие соответственно первый и последний блок подлежащего анализу файла. Как следствие теперь необходимо знать, сколько блоков содержится в файле данных табличного пространства типа Bigfile; в этом случае, как это видно из следующего примера, приходит на помощь динамическое представление производительности V$DATAFILE:
□ SQL> select file#, blocks, name from v$datafile;
FILE# BLOCKS NAME
1 58880 /u05/oradata/ord/system01.dbf
2 20480 /u05/oradata/ord/undotbs01.dbf
3 42240 /u05/oradata/ord/sysaux01.dbf
4 2720 /u05/oradata/ord/users01.dbf
5 19200 /u09/oradata/ord/example01.dbf
6 1280 /u09/oradata/ord/oe_trans01.dbf
7 640 /u05/oradata/ord/users02.dbf
8 1280 /u06/oradata/ord/logmnr_rep01.dbf
9 2304 /u09/oradata/ord/big_users.dbf
10 640 /u08/oradata/ord/idx01.dbf
11 640 /u08/oradata/ord/idx02.dbf
11 rows selected.
В следующем примере показано, как следует анализировать файл данных №— файл данных для табличного пространства типа Bigfile, которое называется BIG_USERS. Из строки приглашения на ввод команды операционной системы можно анализировать этот файл с помощью пяти параллельных процессов, каждый из которых (за исключением последнего) анализирует по 500 блоков:
П $ dbv file=/u09/oradata/ord/big_users.dbf start=1 end=500 &
[1] 6444
$ dbv file=/u09/oradata/ord/big_users.dbf start=501 end=1000 &
[2] 6457
$ dbv file=/u09/oradata/ord/big_users.dbf start=1001 end=1500 &
[2] 6466
$ dbv file=/u09/oradata/ord/big_users.dbf start=1501 end=2000 &
[2] 6469
$ dbv file=/u09/oradata/ord/big_users.dbf start=2001 &
[5] 6499
Управление большими базами данных
643
В последней команде не специфицирован end=; это означает, что анализу будет подвергнут весь файл, начиная с точки старта и до конца файла. Все эти пять команд будут выполняться параллельно. Выходные данные этих команд могут выглядеть похоже на приведенный ниже фрагмент:
□ DBVERIFY: Release 10.1.0.2.0 -
Production on Sat Aug 14 21:36:18 2004
Copyright (c) 1982, 2004, Oracle. All rights reserved.
DBVERIFY - Verification starting:
FILE = /u09/oradata/ord/big_users.dbf
DBVERIFY - Verification complete
Total Pages Examined 500
Total Pages Processed (Data) 393
Total Pages Failing 0
Total Pages Processed (Index) 1
Total Pages Failing (Index) 0
Total Pages Processed (Other) 18
Total Pages Processed (Seg) 0
Total Pages Failing (Seg) 0
Total Pages Empty 88
Total Pages Marked Corrupt 0
Total Pages Influx 0
Анализ параметров инициализации для табличных пространств типа Bigfile
Хотя для табличных пространств типа Bigfile не появилось никаких специфических параметров инициализации, значения одного параметра инициализации и параметра команды create database могут быть уменьшены, так как для каждого такого табличного пространства требуется только один файл данных. Этот параметр инициализации называется DB_FILES, а параметр команды create database — MAXDATAFILES.
DB_FILES и табличные пространства типа Bigfile
Параметр DB_FILES задает максимальное количество файлов данных, ко-торое может быть открыто для базы данных. Если вместо обычных табличных пространств используются табличные пространства типа Bigfile, значение этого параметра может быть ниже; в результате, так как приходится обслуживать меньшее количество файлов данных, снижаются требования к оперативной памяти в системной глобальной области (SGA).
MAXDATAFILES и табличные пространства типа Bigfile
При создании новой базы данных или нового управляющего файла можно использовать параметр MAXDATAFILES, чтобы иметь возможность контролировать размер раздела управляющего файла, выделенного для ведения информации о файлах данных. За счет использования табличных пространств типа Bigfile можно уменьшить размер управляющего
644
Глава 17
файла и пространства, необходимого для SGA; однако, более важным является тот факт, что сохранение значения MAXDATAFILES при использовании табличных пространств типа Bigfile означает увеличение общего размера базы данных.
Изменения в словаре данных для табличных пространств типа Bigfile
К числу изменений в представлениях словаря данных, обусловленных введением табличных пространств типа Bigfile, следует отнести появление новой строки в представлении DATABASE-PROPERTIES и нового столбца в представлениях DBA_TABLESPACES и USER_TABLESPACES.
DATABASE-PROPERTIES и табличные пространства типа Bigfile
Представление словаря данных DATABASE-PROPERTIES содержит целый ряд характеристик базы данных, например имена подразумеваемых (т. е. используемых по умолчанию) и временных табличных пространств и различные установки NLS. В связи с появлением табличных пространств типа Bigfile в DATABASE-PROPERTIES есть еще одна новая характеристика DEFAULT_TBS_TYPE, которая определяет подразумеваемый тип табличных пространств для базы данных, если этот тип не был указан в команде create database. В следующем примере можно выяснить принимаемый по умолчанию тип нового табличного пространства:
□ SQL> select property-name, property_value, description
2 from database-properties
3 where property_name = ‘DEFAULT_TBS_TYPE’;
PROPERTY-NAME PROPERTY-VALUE DESCRIPTION
DEFAULTTBS_TYPE BIGFILE Default tablespace type
1 row selected.
*-TABLESPACES, V$TABLESPACES и табличные пространства типа Bigfile
В представлениях словаря данных DBA_TABLESPACES и USER-TABLESPACES появился новый столбец BIGFILE. Значение этого столбца равно YES, если соответствующее табличное пространство относится к типу Bigfile, как это было показано в запросе к DBA_TABLESPACES выше в данной главе. Динамическое представление производительности V$TABLESPACE также содержит этот столбец.
Расширенные типы таблиц Oracle
Преимущества в средах VLDB обеспечивают и многие другие типы таблиц. Например, так называемые индекс-таблицы (index-organized tables — ЮТ) устраняют необходимость в наличии и самой таблицы, и соответствующего ей индекса, заменяя их единой структурой, которая выглядит похожей на индекс, но в то же время, подобно таблице, содержит данные.
Управление большими базами данных
645
Глобальные временные таблицы создают общее описание таблицы, доступное всем пользователям базы данных; в VLDB глобальная временная таблица, совместно используемая -тысячами пользователей, предпочтительнее создания собственного описания таблицы каждым из пользователей, так как при этом потенциально создается дополнительная нагрузка (с точки зрения использования дисковой памяти) на словарь данных. Внешние таблицы позволяют использовать текстовые файлы, размещенные вне пределов базы данных, не требуя предварительной загрузки их содержимого в таблицы Oracle. Секционированные таблицы, как это следует из их названия, хранят таблицы и индексы в отдельных разделах, что сохраняет высокую доступность таблиц и обеспечивает достаточно низкое значение времени обслуживания. Наконец, материализованные представления предварительно агрегируют результаты запросов в локальной таблице; запросы, использующие материализованные представления, выполняются значительно быстрее, потому что результаты выполнения представления не должны каждый раз создаваться заново.
date, number, number(18, 2),
Индекс-таблицы
Данные таблицы и индекса можно хранить вместе в таблице, известной как индекс-таблица (ЮТ). В индекс-таблицах удается достичь существенной экономии дисковой памяти, так как индексированные столбцы не хранятся дважды (один раз в таблице и второй раз — в индексе); они сохраняются в ЮТ всего один раз, вместе со всеми остальными неиндекси-рованными столбцами. ЮТ удобны для таблиц, в которых основным методом доступа является доступ по первичному ключу, хотя для ЮТ разрешено создание индексов и по другим столбцам, чтобы ускорить доступ к таблице по этим столбцам.
В следующем примере создается таблица ЮТ с составным (состоящим из двух частей) первичным ключом:
□ create table oe.sales_summ_by_date ( sales_date dept_id total_sales
constraint ssbd_pk primary key (sales_date, dept_id)) organization index tablespace prd04;
Каждая запись в ЮТ содержит дату, номер отдела и общий объем продаж за день. Все три этих столбца хранятся в каждой строке ЮТ, но ЮТ строится только по первым двум — дате и номеру отдела. Для хранения ЮТ используется всего один сегмент; если для ЮТ будет создан вторичный индекс, будет создан новый сегмент.
Поскольку вся строка ЮТ хранится как значение индекса, отсутствует ROWID для каждой строки; строки в ЮТ идентифицируются значениями первичного ключа. Вместо ROWID Oracle создает так называемые логические ROWID, получаемые из значения первичного ключа; логический ROWID используется для поддержки вторичных индексов в ЮТ.
Для использования ЮТ не нужен никакой специальный синтаксис; хотя они создаются и обслуживаются во многом похоже на индексы, вп
646
Глава 17
всех операторах select или любых других операторах DML они ведут себя, как таблицы. К то му же, ЮТ можно секционировать (о секционировании ЮТ см. ниже в данной главе).
Глобальные временные таблицы
Временные таблицы стали доступны, начиная с Огас1е8г. Они являются временными по отношению к данным, хранящимся в таблице, а не по отношению к определению самой таблицы. Команда create global temporary table создает временную таблицу; выполнять операции DML над временной таблицей могут все пользователи, имеющие полномочия на эту таблицу. Однако каждый пользователь видит в таблице свои и только свои данные. Когда такой пользователь производит усечение (truncate) глобальной временной таблицы, фактически из нее удаляются только принадлежащие ему данные. Глобальные временные таблицы полезны, когда большому количеству пользователей требуется таблица для хранения временных данных для их транзакции или сеанса, но при этом в словаре данных хранится всего одно определение таблицы. У глобальных временных таблиц имеется дополнительное преимущество — сокращение потребности в пространстве отката для записей в таблице в сценарии восстановления. Записи в глобальной временной таблице по своей природе не являются постоянными, и, следовательно, не нуждаются в восстановлении во время процесса восстановления экземпляра или носителя.
Во временных таблицах различаются два типа “временных” данных: временные на время выполнения транзакции и временные на время сеанса. Продолжительность сохранения временных данных управляется фразой on commit; если выбран вариант on commit delete rows, то все строки будут удалены по завершении транзакции, т. е. при выполнении операторов commit или rollback, в то время как при выборе варианта on commit preserve rows строки будут сохранены и после завершения транзакции.
Тем не менее, по окончании сеанса пользователя все данные пользователя из временной таблицы будут удалены.
Представленная в следующем листинге команда создает глобальную временную таблицу для хранения некоторых промежуточных итогов на время выполнения транзакции. Ниже приводится команда SQL, создаю щая такую таблицу:
□ SQL> create global temporary table subtotal_hrs
2 (emp_id number,
3 proj_hrs number)
4 on commit delete rows;
Table created.
Для этого примера будет создана постоянная таблица; в ней хранится общее число часов, которое, по прогнозу, отработает сегодня служащий.
□ SQL> create table total_hours (emp_id number, wk_dt date, total_hrs number):
Управление большими базами данных
647
В приводимом ниже сценарии для сохранения промежуточных результатов используется глобальная временная таблица, а в конце транзакции итоги сохраняются в таблице TOTAL_HOURS:
□ SQL> insert into subtotal_hrs values (101, 20);
1 row created.
SQL> insert into subtotal__hrs values (101, 10);
1 row created.
SQL> insert into subtotal_hrs values (120, 15);
1 row created.
SQL> select * from subtotal hrs;
EMP_ID PROJ.HRS
101 20
101 10
120 15
SQL> insert into total_hours
2 select emp_id, sysdate, sum(proj_hrs) from subtotal_hrs
3 group by emp_id;
2 rows created.
SQL> commit;
Commit complete.
SQL> select * from subtotal_hrs; no rows selected
SQL> select * from total hours;
EMP_ID WK.DT TOT_HRS
101 19-AUG-04 30
120 19-AUG-04 15
SQL>
После команды commit строки'продолжают удерживаться в таблице TOTAL_HOURS, поскольку это постоянная таблица, а не в таблице SUBTOTALHRS, так как эта таблица является временной и при ее создании была задана фраза on commit delete rows.
Примечание Нельзя производить операции DDL над глобальными временными таблицами, пока существуют сеансы пользователей, выполняющие операции вставки р такие таблицы.
648
Глава 17
Есть несколько других моментов, о которых нельзя забывать, когда имеешь дело с временными таблицами. Хотя для временных таблиц также можно создать индекс, записи индекса будут удалены вместе с записями данных, как и в случае обычной (regular) таблицы. Кроме того, вследствие временной природы данных во временных таблицах для операций DML над временными таблицами не генерируется никакой информации, требующейся для восстановления. Однако информация для отката все-та-ки генерируется в табличном пространстве отката, равно как и журнальная информация (redo information) для защиты отката. Если все, что происходит с глобальными временными таблицами, — это операции вставки и выборки из них, будет сгенерировано очень мало журнальной информации. Поскольку определения временных таблиц сами по себе не являются временными, они продолжают-существовать между сеансами, пока они не будут удалены явно.
Внешние таблицы
Иногда требуется получить доступ к данным, которые размещаются вне базы данных, где они хранятся в текстовом формате, но при этом использовать их так, как будто они являются таблицами базы данных. Хотя можно было бы использовать утилиту загрузки (типа SQL*Loader)для фактической загрузки этих данных в базу данных, эти данные могут оказаться чересчур изменчивыми или же у коллектива пользователей может не оказаться должного опыта работы из командной строки Windows или Unix с такими утилитами, как SQL*Loader.
Для разрешения подобного рода потребностей можно применять так называемые внешние таблицы (external tables), используемые только для чтения, определение которых хранится в базе данных, но сами данные остаются внешними по отношению к базе данных. При использовании внешних таблиц есть и некоторые недостатки: внешние таблицы нельзя индексировать, над хранящимися в них данными нельзя выполнять операторы обновления (update), вставки (insert) и удаления (delete).Однако в средах хранилищ данных, где внешняя таблица считывается во всей своей полноте для операций слияния с существующими в хранилище данных таблицами, эти недостатки не сказываются.
Можно использовать внешние таблицы для сбора предложений служащих через разработанное по web-технологиям приложение, не имеющее доступа к промышленно эксплуатируемой базе данных предприятия. В данном примере будет создана внешняя таблица, которая использует текстовый файл, содержащий два поля: поле идентификатора служащего и поле комментария.
Для начала необходимо создать в базе данных так называемый объект каталога (directory object), указывающий на каталог операционной систе мы, в котором хранится этот текстовый файл. В этом примере будет соз дан объект каталога EMPL_COMMENT_DIR для ссылки на каталог в фаи ловой системе Unix:
□ SQL> create directory empl_cornment_dir as
2 ‘/u10/Employee_Comments’;
Directory created.
Управление большими базами данных
649
Размещенный в этом каталоге текстовый файл называется empl_ sugg.txt. Его содержимое может быть, например, таким:
□ $ cat empl_sugg.txt
101, The cafeteria serves lousy food.
138, We need a raise.
112, There are not enough bathrooms in Building 5.
138, I like the new benefit plan. $
Поскольку у текстового файла два поля, будет создана внешняя таблица с двумя столбцами: первый для идентификатора служащего, а второй для текста комментария. Ниже приведена команда create table:
□ SQL> create table empl_sugg
2 (employee_id number,
3 empl_comment varchar2(250))
4 organization external
5 (type oracle_loader
6 default directory empl_comment_dir
7 access parameters
8 (records delimited by newline
9 fields terminated by 1, ’
10 (employee_id char,
11 empl_comment char)
12 )
13 location (‘empl_sugg.txt’)
14 );
Table created.
SQL>
Первые три строки команды выглядят похоже на стандартную команду create table. Фраза organization external указывает на то, что данные таблицы будут храниться не в базе данных. Использование фразы oracle_ loader специфицирует тип драйвера для создания р загрузки внешней таблицы в режиме только для чтения. Файл, указанный во фразе location, называется empl_sugg.txt и размещается в каталоге Oracle empl comment dir, созданном ранее. Фраза access parameters указывает, что каждой строке таблицы соответствует своя собственная строка текстового файла и что поля в текстовом файле отделяются друг от друга запятыми.
Примечание При использовании вместо драйвера oraclejoader драйвера oracle_datapump появляется возможность выгрузить данные из базы данных во внешнюю таблицу; во всех остальных случаях, кроме только что описанной выгрузки, внешняя таблица является доступной только для чтения, в том числе и с помощью драйвера oracle_datapump, и имеет те же самые ограничения, что и для внешних таблиц, созданных посредством драйвера доступа oraclejoader.
После создания таблица немедленно становится доступной для использования в операторах select, как будто содержащиеся в ней данные были в действительности загружены в таблицу базы данных:
650
Глава 17
□ SQL> select * from empl_sugg;
EMPLOYEE_ID EMPL_COMMENT
101 The cafeteria serves lousy food.
138 We need a raise.
112 There are not enough bathrooms in Building 5.
138 I like the new benefit plan.
SQL>
Все изменения, внесенные в текстовый файл, автоматически станут доступными при первом же следующем выполнении оператора select.
Секционированные таблицы
В средах VLDB секционированные таблицы помогают сделать базу данных более доступной и надежной в эксплуатации. В секционированных таблицах строки таблицы динамически разделяются на более управляемые части, которые называются разделами (partitions) и которые в свою очередь могут быть разбиты на подраздели (subpartitions). Соответствующие индексы для секционированных таблиц могут быть несекциониро-ванными, секционированными по тому же принципу, что и сама таблица, и секционированными по другому принципу.
Секционированные таблицы могут также повысить производительность базы данных — можно осуществить доступ к каждому разделу, используя для этого параллельные запросы. Различным разделам одной секционированной таблицы или различным разделам индекса может быть назначено несколько серверов параллельного выполнения (parallel execution servers).
По соображениям производительности каждый раздел таблицы должен содержаться в собственном табличном пространстве. Другие атрибуты разделов, например характеристики хранения, также могут отличаться, однако типы данных столбцов и ограничения для каждого из столбцов должны быть идентичными. Другими словами, такие атрибуты, как например тип данных и ограничения целостности, задаются па уровне та лицы, а не на уровне раздела. К другим преимуществам хранения различ пых разделов секционированной таблицы в различных табличных пространствах можно причислить:
Сокращение возможностей для повреждения данных более че в одном разделе при выходе из строя табличного пространс гва.
Возможность независимого резервного копирования и восстанов
ления.
Расширение возможностей контроля над построением соответствий между разделами и физическими устройствами для выравнива ния нагрузки ввода/вывода (даже в средах ASM, где каждому разДе лу отводится собственная дисковая группа).
Управление большими базами данных
651
CJ create table cat_req (cat_req_num cat_req_dt cat_cd cust_num req.nm req_addr1 req_addr2 req_addr3
Секционирование является прозрачным для приложений, и, для того чтобы воспользоваться любыми преимуществами секционирования, не требуется никаких изменений в операторах SQL. Однако в некоторых редких ситуациях, когда указание раздела может привести к дополнительным преимуществам, можно указать в операторе SQL как имя таблицы, так и имя раздела (примеры синтаксиса с использованием явного указания имен разделов в операторе select см. ниже в данной главе).
Создание секционированных таблиц
В Oracle поддерживаются несколько типов секционирования (разбиения на разделы), причем некоторые из них впервые появились в Oracle 10g, например секционированные по списку индекс-таблицы (ЮТ). В нескольких следующих разделах рассматриваются основы секционирования по диапазонам, по списку, а также составного (хеш-диапазон и хеш-список ключей) секционирования. Кроме того, будет показано, как можно выборочно компрессировать разделы в таблице, для того чтобы сэкономить операции ввода/вывода и дисковую память.
Применение секционирования по диапазону
Секционирование по диапазону применяется для установления соответствия между строками и разделами на основании диапазона значений одного или нескольких столбцов подлежащей секционированию таблицы. Кроме того, подлежащие секционированию строки должны быть достаточно равномерно распределены между разделами, например по месяцам или кварталам года. Если распределение данных для столбца асимметрично (например, по количеству населения для каждого штата), более приемлемым может оказаться другой метод секционирования.
Для использования секционирования по диапазону необходимо указать три следующих критерия:
Метод секционирования (диапазон)
Столбец (столбцы), по которому производится секционирование
Граничные значения для каждого раздела
В следующем примере будет секционирована таблица запросов к каталогу, CATJREQ, причем разбиение должно быть проведено по временам года, так что в результате должно получиться четыре раздела:
number not null, date not null, number not null, number not null, varchar2(50)“ varchar2(75), varchar2(75), varchar2(75))
prtition by range (cat_req_dt)
(partition cat__req_spr_2004
values less than (to_date(‘20040601’, ‘YYYYMMDD’))
652
Глава 17
tablespace prdO1,
partition cat_req_sum_2004
values less than (to_date(‘20040901’, ‘YYYYMMDD’)) tablespace prd02,
partition cat_req_fal_2004
values less than (to_date(‘20041201’, ‘YYYYMMDD’)) tablespace prd03,
partition cat_req_win_2005
values less than (maxvalue) tablespace prd04);
В предыдущем примере в качестве метода секционирования был выбран range (секционирование по диапазону), столбцом секционирования стал REQ_DATE, а фраза values less than специфицирует верхнюю границу диапазона, соответствующую датам каждого из времен года: с марта по май (раздел CAT_REQ_SPR_2004), с июня по август (раздел CAT_REQ_SUM_2004), с сентября по ноябрь (раздел CAT_REQ_FAL_ 2004) и с декабря по февраль (раздел CAT_REQ_WIN_2005). Каждый раздел хранится в собственном табличном пространстве — PRD01, PRD02, PRD03 и PRD04 соответственно.
Значение maxvalue используется для того, чтобы зафиксировать любые значения даты после 12/1/2004; если указать в качестве верхней границы даты для четвертого раздела toclatef20050301, ‘YYYYMMDD’), то любая попытка вставить строку с датой после 2/28/2005 заканчивалась бы неудачей. С другой стороны, любые строки, вставленные с датами до 6/1/2004, попадут в раздел CAT_REQ_SPR_2004, даже строки с датой запроса к каталогу, равной 10/1/1962! Это именно то случай, когда клиентское приложение должно оказывать помощь в процессе верификации даты как для левого, так и для правого края диапазона дат.
Представление словаря данных DBA_TAB_PARTITIONS отображает компоненты разделов для таблицы CAT_REQ, что демонстрируется следующим запросом:
□ SQL> select table_owner, table_name,
2 partition_name, tablespace_name
3 from dba_tab_partitions
4 where table_name = ‘CAT_REQ’;
TABLE_OWNER TABLE_NAME PARTITION-NAME TABLESPACE_NAME
0Е CAT-REQ CAT_REQ_FAL_2004 PRD03
0Е CAT_REQ CAT_REQ_SPR_2004 PRD01
0Е CAT_REQ CAT REQ SUM 2004 PRD02
0Е CAT_REQ CAT_REQ_WIN_2005 PRD04
4 rows selected.
Выяснить, какие даты были использованы во фразе values less than при создании секционированной таблицы, можно с помощью того же са-мого представления словаря данных:
Управление большими базами данных
653
□ SQL> select partition_.name, high_value
2 from dba_table_partitions
3 where table_name = 'CAT_REQ’;
PARTITION-NAME
HIGH_VALUE
CAT_REQ_FAL_2004 T0_DATE(* 2004-12-01 00:00:00', ‘ SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN')
CAT_REQ_SPR_2004 T0_DATE(‘ 2004-06-0100:00:00’, *SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN')
CAT_REQ_SUM_2004 T0_DATE(* 2004-09-0100:00:00', ‘SYYYY-MM-DD HH24:MI:SS’,
* NLS_CALENDAR=GREGORIAN’)
CAT_REQ_WIN_2005 MAXVALUE
4 rows selected.
Точно так же можно использовать представление словаря данных DBA_PART_KEY_COLUMNS, чтобы обнаружить, какие столбцы были использованы для секционирования таблицы:
□ SQL> select owner, name, object_type, columnjiame,
2 column__position from DBA_PART_KEY_COLUMNS
3 where owner = ‘0E’ and name = ‘CAT_REQ’;
OWNER NAME OBJECT_TYPE COLUMN_NAME COL
0E CAT.REQ
1 row selected.
TABLE
CAT_REQ_DT
Применение хеш-секционирования
Хеш-секционирование является хорошим выбором, если распределение данных не укладывается в схему секционирования по диапазонам или если число строк в таблице неизвестно, но, тем не менее, вы хотите воспользоваться преимуществами, которые дают секционированные таблицы. Строки равномерно распределяются между двумя или большим числом разделов на основании внутренних алгоритмов хеширования, где в качестве входных данных используется ключ раздела. Чем сильнее будут отличаться друг от друга значения в столбце, по которому проводится секционирование, тем лучшим будет распределение данных по разделам.
Для использования хеш-секционирования необходимо задать три следующих критерия:
Метод секционирования (hash)
Столбец (столбцы), по которым проводится разбиение на разделы
Количество разделов и список целевых табличных пространств, в которых будут храниться разделы
654
Гпава /7
create table ое.cust (cust_num inst_dt first_nm last_nm mi addrl addr2 city state_cd zip cd
Для этого примера будет создана новая таблица заказчиков, первичные ключи которой будут генерироваться с помощью последовательности.
Нужно, чтобы строки таблицы были равномерно распределены по четырем разделам; поэтому наилучшим выбором для метода секционирования будет хеш-секционирование. Ниже приводится оператор SQL для создания хеш-секционированной таблицы:
number not null primary key, date, varchar2(25), varchar2(35), char(1), varchar2(40), varchar2(40), varchar2(40), char(2), varchar2(10))
partition by hash (cust_nam) partitions 4
store in (prdO1, prd02, prdO3, prd04);
Нет необходимости обязательно указывать столько же табличных пространств, сколько разделов; если разделов указано больше, чем табличных пространств, табличные пространства будут использоваться повторно циклическим образом. Если же указать разделов меньше, чем табличных пространств, оставшиеся неиспользованными табличные пространства буду просто проигнорированы.
Если выполнить те же самые запросы, что выполнялись ранее для секционированных по диапазону таблиц, могут обнаружиться некоторые неожиданные результаты:
□ SQL> select partition_name, tablespace_name. high_value
2 from dba_rab_partitions
3 where table_name = ‘OUST’;
PARTITION-NAME TABLESPACE_NAME HIGH_VALUE
SYS_P1130 PRDO1
SYS_P1131 PRD02
SYS_.P1132 PRDO3
SYS_P1133 PRD04
4 rows selected.
Так как выбрано хещ-секционирование, столбец HIGH_VALUE ется пустым.
Применение секционирования по списку значений ключей
Разбиение на разделы по списку значений ключей дает возможность ного контроля над тем, как каждое значение в столбце, по которому Г1Р
Управление большими базами данных
655
изводится разбиение на столбцы, отображается на раздел путем указания конкретного перечня дискретных значений этого столбца. Секционирование по диапазону, как правило, не слишком подходит для дискретных значений, которые не имеют естественного и последовательного диапазона значений, например для кодов штатов (географических регионов). Хеш-секционирование не подходит для назначения дискретных значений различным разделам, так как по своей природе близкие значения ключей попадают при хеш-секционировании в разные разделы.
Для использования секционирования по списку ключей необходимо указать три следующих критерия:
Метод секционирования (list)
Столбец, по которому производится секционирование
Имена разделов, каждое из которых связано с перечнем дискретных значений, попадающих в раздел
Примечание Начиная с Oracle 10g, стало возможно применять секционирование по списку ключей для таблиц со столбцами типа LOB.
В следующем примере используется секционирование по списку ключей, чтобы регистрировать для хранилища данных информацию о продажах в трех разделах в соответствии с регионами продаж: Средний Запад, Западное побережье и остальная часть страны. Ниже приводится команда create table:
П create table ое.sales_by_region_by_day
(state_cd char(2),
sales_dt date,
sales_amt number(16,2))
partition by list (state_cd) (partition midwest values (‘VI’, ‘IL’, ‘IA’, ‘IN’, ‘MN’) tablespace prdO1, partition westcoast values (‘CA’, ‘OR’, ‘WA’) tablespace prd02, partition other_states values (default) tablespace prd03);
Информация о продажах для Висконсина, Иллинойса и других штатов Среднего Запада будет попадать в раздел midwest; для Калифорнии, Орегона и Вашингтона — в раздел westcoast. Значения с любыми другими кодами штатов, например, MI, окажутся в разделе other_states, в табличном пространстве PRD03.
Применение составного секционирования (диапазон-хэш)
При секционировании диапазон-хеш для разделения строк сначала используется метод секционирования по диапазонам, а затем строки внутри каждого раздела еще раз разбиваются на подразделы с использованием хеш-секционирования. Составное секционирование (диапазон-хеш) хорошо подходит для хронологических данных, так как при этом появляет
656
Гпава 17
ся дополнительное преимущество, связанное с повышением управляемости и разнесением данных по большему общему числу разделов.
Для использования составного секционирования (диапазон-хеш) необходимо задать шесть следующих критериев:
Первичный метод секционирования (range)
Столбец (или столбцы), по которым производится секционирование
Имена разделов, идентифицирующих границы разделов
н Метод разбиения на подразделы (hash)
Столбец, по которому происходит разбиение на подразделы
Количество подразделов для каждого раздела или имена подразделов
В следующем примере будет отслеживаться арендная плата за прокат садового инвентаря и инструментов для домашних работ. Каждый инструмент имеет уникальный номер; в любой момент времени в наличии для сдачи в аренду есть около 400 таких инструментов, хотя иногда их число может ненамного превышать 4(10. Для каждого из восьми подразделов каждого раздела нужно использовать алгоритм хеширования по имени инструмента. Для хранения подразделов будет выделено четыре табличных пространства: PRD01, PRD02, PRD03 и PRD04. Ниже приводится команда create table для создания таблицы с составным секционированием (диапазон-хеш):
□ create table ее.tool_rentals
(tool_num number,
tool_desc varchar2(50),
rental_rate number(6,2))
partition by range (tool_num)
subpartition by hash (tool_desc)
subpartition template (subpartition subpartition subpartition subpartition subpartition subpartition subpartition subpartition
(partition tool_rentals_p1 values less partition tool_rentals_p2 values less partition tool_rentals_p3 values less partition tool__rentals_p4 values less
s1 tablespace prdO1,
s2 tablespace prd02,
s3 tablespace prd03,
s4 tablespace prd04,
s5 tablespace prdO1,
s6 tablespace prd02,
s7 tablespace prd03,
s8 tablespace prd04)
than (101),
than (201),
than (301),
than (maxvalue));
Разделы по диапазонам являются всего лишь логическими; фактиче ски есть 32 физических раздела, каждый из которых является комбинаци ей логического раздела и подраздела из списка шаблонов. Обратите вни мание на фразу subpartition template. Шаблон используется для создания подразделов в каждом разделе, для которого не указана явная специфика ция подразделов. Эта методика может привести к реальному сокращению времени и уменьшению количества опечаток при наборе, если будет выбрана модель с явным указанием имен подразделов. Как альтернативный
Управление большими базами данных
657
вариант, если необходимо явно именовать подразделы, можно специфицировать следующую фразу:
□ subpartitions 8 store in (prdO1, prd02, prd03, prd04)
Информацию о физических разделах можно найти в представлении DBA_TAB_SUBPARTITIONS, как и для любой секционированной таблицы. Ниже приводится запрос для нахождения компонентов разделов таблицы TOOLJRENTALS:
□ SQL> select table_name, partition_name, subpartition_name,
2 tablespace_name
3 from dba_tab_subpartitions
4 where table name = ‘TOOL RENTALS’;
TABLE.NAME PARTITION-NAME SUBPARTITION-NAME TABLESPACE
TOOL-RENTALS T00L_RENTALS_P1 T00L_RENTALS_P1_S1 PRD01
TOOL-RENTALS T00L_RENTALS_P1 T00L_RENTALS_P1_S2 PRD02
TOOL-RENTALS T00L_RENTALS_P1 T00L_RENTALS_P1_S3 PRD03
TOOL-RENTALS T00L_RENTALS_P1 T00L_RENTALS_P1_S4 PRD04
TOOL-RENTALS T00L_RENTALS_P1 T00L_RENTALS_P1_S5 PRD01
TOOL-RENTALS T00L_RENTALS-P1 T00L_RENTALS_P1_S6 PRD02
TOOL-RENTALS T00L_RENTALS_P1 T00L_RENTALS_P1_S7 PRD03
TOOL-RENTALS T00L_RENTALS_P1 T00L_RENTALS_P1_S8 PRD04
TOOL-RENTALS T00L_RENTALS_P2 T00L_RENTALS_P2_S1 PRD01
TOOL-RENTALS T00L_RENTALS_P2 T00L_RENTALS_P2_S2 PRD02
TOOL_RENTALS T00L_RENTALS_P4 T00L_RENTALS_P4_S8 PRD04
32 rows selected.
На уровне логических разделов необходимо продолжать делать запрос к DBA_TAB_PARITIONS, чтобы получить значения диапазонов:
□ SQL> select table_name, partition_name,
2 subpartition_count, high_value
3 from dba_tab_partitions
4 where table_name = ‘TOOL_RENTALS’;
TABLE_NAME PARTITION_NAME SUBPARTITION_COUNT HIGH_VALUE
TOOLRENTALS TOOL_RENTALS_P1 8 101
TOOLRENTALS T00L_RENTALS_P2 8 201
TOOLRENTALS TOOL RENTALS. P3 8 301
TOOLRENTALS T00L_RENTALS_P4 8 MAXVALUE
4 rows selected.
Может быть указано имя раздела или подраздела для выполнения ручного отсечения (ненужных) разделов:
658
Глава 17
□ select * from oe.tool_rentals partition (tool_rentals_p1);
select * from oe.tool_rentals subpartition (tool_rentals_p3_s2);
В первом запросе будет выполнен поиск в восьми подразделах, начиная с TOOL_RENTALS_P1_S1 и заканчивая TOOL_RENTALS_P1_S8; во втором запросе поиск будет вестись всего в одном из 32 подразделов таблицы.
Применение составного секционирования (диапазон-список ключей) Как и в случае составного секционирования (диапазон-хеш), при составном секционировании (диапазон-список ключей) для первоначального разделения строк таблицы применяется секционирование по диапазону, а затем строки, попавшие в каждый из диапазонов, подразделяются с использованием списка ключей. Составное секционирование (диапазон-список ключей) хорошо подходит для помещения хронологических данных в соответствующие разделы с последующим разделением логических разделов с использованием непрерывного или дискретного набора значений.
Примечание Секционирование диапазон-список ключей впервые появилось в Oracle 10#.
Для использования составного секционирования по диапазонам-спискам ключей необходимо специфицировать следующие критерии:
Первичный метод секционирования (range)
Столбец (столбцы), по которым проводится секционирование
Имена разделов, идентифицирующих границы разделов
Метод разделения на подразделы (list)
Столбец, по которому происходит разделение на подразделы
Имена разделов, где каждый раздел ассоциирован с дискретным списком буквенных значений, в соответствии с которыми происходит занесение в этот раздел
В следующем примере расширен предыдущий пример с секционированием по списку “Продажи по регионам”, а секционированная таблица будет сделана более масштабируемой за счет использования в качестве диапазона секционирования даты продажи, в то время как код штата будет использоваться для разбиения на подразделы. Ниже приводится соответ ствующая команда create table:
□ create table sales_by_region_by_quarter
(state_cd char(2),
sales_dt date,
sales_amt number(16,2))
partition by range (sales_dt) subpartition by list (state_cd)
(partition q1_2004 values less than (to_date(‘20040401’, (subpartition q1_2004_midwest values (‘WI’, ‘IL’, ‘IA’ tablespace prdO1,
‘YYYYMMDD’)) ‘IN’, ‘MN’)
Управление большими базами данных
659
(subpartition q1_2004_westcoast values (‘CA’, ‘OR’ , ‘VIA’) tablespace prd02,
(subpartition q1_2004_other_states values (default) tablespace prd03
).
(partition q2_2004 values less than (to_date(‘20040701’, ‘YYYYMMDD’)) (subpartition q2_2004_midwest-values (‘WF, ‘IL’, ‘IA’, ‘IN’, ‘MN’) tablespace prdOI, (subpartition q2_2004_westcoast values (‘CA’, ‘OR’, ‘WA’) tablespace prd02, (subpartition q2_2004_other_states values (default) tablespace prd03
).
(partition q3_2004 values less than (to_date(‘20041001’, ‘YYYYMMDD’)) (subpartition q3_2004_midwest values (‘WI’, ‘IL’, ‘IA’, ‘IN’, ‘MN’) tablespace prdOI, (subpartition q3_2004_westcoast values (‘CA’, ‘OR’, ‘WA’) tablespace prd02, (subpartition q3_2004_other_states values (default) tablespace prd03
).
(partition q4_2004 values less than (maxvalue)
(subpartition q4_2004_midwest values (‘WI’, ‘IL’, ‘IA’, ‘IN’, ‘MN’) tablespace prdOI,
(subpartition q4_2004_westcoast values (‘CA’, ‘OR’, ‘WA’) tablespace prd02,
(subpartition q4_2004_other_states values (default) tablespace prd03
) );
Каждая строка, хранящаяся в таблице SALES_BY_REGION_BY QUARTER, помещена в один из 12 подразделов в зависимости от содержащейся в ней даты продажи, в результате чего выбор подраздела для строки сужается до трех. Выбор конкретного подраздела, в котором будет храниться строка, окончательно определяется значением кода штата. Даже если дата продажи выходит за рамки 2004 г., строка все равно будет помещена в один из трех подразделов четвертого квартала (Q4_2004), пока не будет создан новый раздел для первого квартала 2005 г. (Ql_ 2005). О реорганизации секционированных таблиц см. ниже в данной главе.
Компрессированные секционированные таблицы
Секционированные таблицы могут быть компрессированы точно так же, как и обычные. Более того, можно выборочно компрессировать отдельные разделы секционированных таблиц. Например, можно подвергнуть компрессированию только самые старые разделы, обращения к которым происходят реже, и оставить нетронутыми более новые разделы, чтобы свести к минимуму временные затраты на выборку свежих данных. В следующем примере будет создана новая версия таблицы CAT_REQ (см.
660
Глава 17
выше в данной главе), где будут подвергнуты компрессированию только два первых раздела. Ниже приводится команда SQL:
□ create table cat_req_2
(cat_req_num cat_req_dt cat_cd cust_num req_nm req_addr1 req_addr2 req_addr3 partition by range
number not null, date not null, number not null, number not null, varchar2(50), varchar2(75), varchar2(75), varchar2(75))
(cat_req_dt)
(partition cat_req_spr_2004
values less than (to_date(‘2004060T,
tablespace prdO1 compress, partition cat_req_sum_2004
values less than (to_date(‘20040901’,
tablespace prd02 compress, partition cat_req_fal_2004
values less than (to_date(‘20041201 ’,
tablespace prd03 nocompress, partition cat_req_win_2005^
values less than (maxvalue)
‘YYYYMMDD’))
‘YYYYMMDD’))
‘YYYYMMDD’))
tablespace prd04 nocompress);
Опцию nocompress специфицировать необязательно, так как она является значением по умолчанию. Чтобы выяснить, какие разделы компрессированы, можно использовать столбец COMPRESSION представления словаря данных DBAJTAB JPARTITIONS:
□ SQL> select table_name, partitionjiame, compression
2 from dba_tab_partitions
3 where table_name = ‘CAT_REQ_2‘;
TABLE.NAME PARTITION_NAME COMPRESS
CAT_REQ_2 CAT_REQ_FAL_2004 DISABLED
CAT_REQ_2 CAT_REQ_SPR_2004 ENABLED
CAT_REQ_2 CAT REQ SUM 2004 ENABLED
CAT_REQ_2 CAT_REQ_WIN_2005 DISABLED
4 rows selected.
Индексирование разделов
Локальные индексы по разделам отражают структуру базовой таблицы, и их легче обслуживать, чем несекционированные или глобальные секционированные индексы. Локальные индексы являются эквисекционир& ванными (equipartitioned) с базовой секционированной таблицей; другими словами, индекс будет секционирован по тем же самым столбцам, что
Управление большими базами данных
661
и базовая таблица, и, следовательно, будет иметь то же самое количество и те же самые границы разделов, что и базовая таблица.
Глобальные секционированные индексы создаются безотносительно к схеме секционирования базовой таблицы и могут быть секционированы с использованием секционирования по разделам или хеш-секциони-рования.
Создание локальных секционированных индексов
Локальный секционированный индекс очень легко создать и обслуживать, так как схема его секционирования идентична схеме секционирования базовой таблицы. Другими словами, число разделов в индексе то же самое, что и число разделов и подразделов таблицы; помимо этого, для любой строки, лежащей в заданном разделе или подразделе таблицы, индекс всегда будет храниться в соответствующем разделе или подразделе индекса.
На рис. 17.1 показано отношение между секционированным локальным индексом и секционированной таблицей. Количество разделов таблицы в точности то же самое, что и количество разделов индекса.
В следующем разделе создается локальный индекс для ранее созданной в этой главе таблицы CUST. Ниже показан оператор SQL для выборки разделов для таблицы CUST:
□ SQL> select partition_name, tablespace_name, high_value
2 from dba_tab_partitions
3 where table_name = ‘CUST’;
PARTITION-NAME TABLESPACE NAME HIGH VALUE
SYS_P1130 PRDO1
SYS_P1131 PRD02
SYS.P1132 PRD03
SYS_P1133 PRD04
4 rows selected.
Локальный секционированный индекс
Индексируемый столбец
Секционированная таблица
Рис. 17.1.
Локальный секционированный индекс для секционированной таблицы
662
Глава 17
Команда для создания локального индекса для этой таблицы очень проста:
□ SQL> create index ое.cust_ins_dt_ix_ on oe.cust (ins_dt)
2 local store in (idx_1, idx_2, idx_3, idx_4);
Index created.
Индексные разделы хранятся в четырех табличных пространствах — с IDX_1 по IDX_4, что еще более повышает производительность таблицы, поскольку каждый индексный раздел хранится в табличном пространстве, отдельном от табличных пространств для самой таблицы.
Узнать о разделах, из которых состоит этот индекс, можно, если задать следующий запрос к DBA_IND_PARTITION:
□ SQL> select partition_nanie, tablespace_name from dba_ind_partititions
2’ where indexjiame = ‘CUST_INS_DT_IDX‘;
PARTITION-NAME TABLESPACE_NAME
SYS_ ,P1130 IDX_ .1
SYS_ .P1131 IDX_ .2
SYS_ .P1132 IDX_ .3
SYS_ .P1133 IDX_ 4
4 rows selected.
Все индексные разделы автоматически получают то же самое имя, что и соответствующие им разделы таблицы. Одно из преимуществ локальных индексов состоит в том, что если будет создан новый раздел таблицы, то новый раздел такого индекса будет создан автоматически. При удалении любого раздела соответствующий индексный раздел будет автоматически удален, причем все оставшиеся индексные разделы не перестанут быть допустимыми, как это произошло бы для глобальных индексов.
Создание секционированных по диапазону глобальных индексов
При создании секционированных по диапазону глобальных индексов используются правила, аналогичные применяемым при создании секционированных таблиц. В одном из предыдущих примерах была создана секционированная таблица CAT_REQ, которая содержит четыре раздела, получающихся на базе столбца CAT_REQ_DT. В этом разделе будет создан секционированный глобальный индекс, состоящий только из двух разделов (другими словами, он секционирован не так, как его базовая таблица).
□ create index cat_req_dt_idx on oe.cat_req (cat_req_dt) global partition by range (cat_req_dt)
(partition spr_sum_2004
values less than (to_date(‘20040901’, ‘YYYYMMDD )) tablespace idx_4
(partition fal_win_2004 values less than (maxvalue)
tablespace idx_8);
Управление большими базами данных
663
Глобальный секционированный индекс
Индексируемый столбец
Секционированная таблица
Рис. 17.2. Глобальный секционированный индекс для секционированной таблицы
для хранения разделов индекса специфицировано два табличных пространства, которые отличаются от табличных пространств, используемых для хранения разделов самой таблицы. Если над базовой таблицей совершаются какие-то действия DML, глобальные индексы помечаются как UNUSABLE (непригодные к использованию), и их необходимо перестроить. Ниже в данной главе будет рассмотрено применение фразы update index при выполнении операций обслуживания разделов для секционированных индексов.
На рис. 17.2 показано отношение между секционированными глобальными индексами и секционированными таблицами. Количество разделов таблицы может совпадать или не совпадать с числом разделов индекса.
Создание хеш-секционированных глобальных индексов
Как и для секционированных по диапазону индексов, операторы create для хеш-секционированных индексов имеют общий синтаксис с операторами create для хеш-секционированных таблиц. Хеш-секционированные глобальные индексы могут повысить производительность, когда для небольшого количества несекционированных листовых блоков (leaf blocks) возникает высокое число конфликтов в средах OLTP. Сильно выиграть от применения хеш-секционированных глобальных индексов могут запросы, в которых во фразе WHERE используются операторы равенства или операторы IN.
Примечание Хеш-секционированные глобальные индексы являются новинкой в Oracle 10ff.
Расширяя пример, использующий хеш-секционирование для таблицы CUST, можно построить хеш-секционированный глобальный индекс по столбцу ZIP CD:
П creaie index ое.cust_zip_cd_idx on oe.cust (zip.cd)
global partition by hash (zip_cd)
(partition z1 tablespace idx_1,
par it on z2 tablespace idx_2,
664
Гпава 17
partition z3 tablespace idx_3,
partition z4 tablespace idx_4,
partition z5 tablespace idx_5,
partition z6 tablespace idx_6,
partition z7 tablespace idx_7,
partition z8 tablespace idx_8);
Таблица CUST секционирована по столбцу CDUST_NUM, и ее четыре раздела занимают табличные пространства от PRD01 до PRD04, а секционирование индекса производится по столбцу ZIP_CD, причем восемь его разделов хранятся в табличных пространствах IDX_1-IDX_8.
Создание несекционированных глобальных индексов
Создание несекционированных глобальных индексов полностью аналогично созданию обычных индексов для несекционированных таблиц. На рис. 17.3 показано отношение между несекционированным глобальным индексом и секционированной таблицей.
Применение компрессирования ключей для секционированных индексов
Если индекс является неуникальным и в нем есть много повторяющихся значений ключа (или ключей) индекса, можно использовать компрессирование ключа индекса точно так же, как это было сделано для традиционного несекционированного индекса. Когда сохраняется только первый экземпляр ключа индекса, это обеспечивает экономию и дискового пространства, и операций ввода/вывода. На основании следующего примера можно убедиться в том, насколько просто создать компрессированный секционированный индекс:
□ create index oe.cust_ins_dt_ix on oe.cust (ins_dt) compress local
store in (idx_1, idx_2, idx_3, idx_4);
Можно указать, что более активные разделы индекса не должны компрессироваться, специфицировав для них опцию NOCOMPRESS, что может привести к существенной экономии времени центрального процессора при работе с новыми записями индекса, обращения к которым происходят более часто, чем к другим разделам индекса.
Глобальный несекционированный индекс
Индексируемый столбец
Секционированная таблица
Рис. 17.3. Гпобальный несекционированный индекс для секционированной таблицы
Управление большими базами данных
665
Секционированные индекс-таблицы'
Индекс-таблицы (Index-organized Tables — ЮТ) могут быть секционированы с использованием диапазона или списка значений ключа или хеш-секционирования; создание секционированных индекс-таблиц синтаксически напоминает создание неупорядоченных (heap organized) секционированных таблиц.
Для секционированных ЮТ используются фразы organization index, including и overflow, точно так же, как они использовались для стандартных ЮТ. Во фразе partition можно специфицировать фразу overflow, а также любые другие атрибуты сегментов переполнения, специфических для раздела.
В Oracle 10g перестало действовать ограничение о том, что набор столбцов для секционирования должен быть подмножеством столбцов первичного ключа ЮТ; кроме того, стало возможным использование секционирования по списку значений ключа в дополнение к секционированию по диапазону и хеш-секционированию. В предыдущих выпусках Oracle столбцы типа LOB поддерживались только для секционированных по диапазону ЮТ; начиная с Oracle 10g, LOB поддерживаются и для хеш-секционированных и секционированных по списку значений ключа.
Управление разделами
В порядке обслуживания секционированных таблиц может быть выполнено четырнадцать различных операций, в том числе разбиение, слияние и добавление разделов. Эти операции могут быть, а могут и не быть доступными, в зависимости от используемой схемы секционирования (по диапазону, с хешированием, по списку значений ключа, составное диапазон/хеш или составное список значений/хеш). Для составных разделов эти операции иногда применимы как к разделу, так и к входящим в него подразделам, а иногда только к подразделам.
Для секционированных индексов есть семь типов операций обслуживания, перечень которых изменяется в зависимости как от метода секционирования (по диапазону, с хешированием, по списку значений ключа или составное), так и от того, является ли индекс глобальным или локальным. Каждый тип секционированного индекса может поддерживать автоматические обновления при изменении схемы секционирования, что приводит к сокращению числа случаев признания индексов непригодными к использованию.
Ниже будут представлены удобные таблицы для секционированных таблиц и индексов, которые помогут понять, какие операции являются разрешенными и для каких типов разделов. Для некоторых наиболее часто встречающихся типов операций будут предложены примеры использования.
Обслуживание разделов таблиц
Для обслуживания одного или нескольких разделов (или подразделов) таблицы используется команда alter table так же, как это делается для не-сскционированной таблицы. В таблице 17.5 представлены типы операции над секционированными таблицами и ключевые слова, которые можно использовать при проведении” этих операций для пяти различных
666
Глава 17
типов секционированных таблиц (по диапазону, с хешированием, по списку значений ключа, составное диапазон/хеш или составное список значений/хеш). Команда alter table имеет следующий формат:
П alter table <имя_таблицы> <операция_с_разделом><опции_операции_с_разделом>;
Таблица 17.5. Операции обслуживания для секционированных таблиц
Операция Диапазон над разделом Хеширование Список значений Составное, диапазон/хеш Составное, диапазон/список значений Поддерживает UPDATE INDEXES
Добавление раз- add дела partition ADD PARTITION ADD PARTITION ADD PARTITION или MODIFY PARTITION <раздел> ADD SUBPARTITION ADD PARTITION или MODIFY PARTITION <раздел> ADD SUBPARTITION Да
Объединение N/A разделов COALESCE PARTITION N/A MODIFY PARTITION <раздел> COALESCE SUBPARTITION N/A Да
Удаление разде- drop ла PARTITION N/A DROP PARTITION DROP PARTITION DROP [SUBPARTITION Да
Преобразование exchange раздела partition EXCHANGE PARTITION EXCHANGE PARTITION EXCHANGE [SUBPARTITION EXCHANGE [SUBPARTITION Да
Слияние разде- merge ЛОВ PARTITIONS N/A MERGE PARTITIONS MERGE PARTITIONS MERGE [SUBPARTITIONS Да
Модифицирова- modify ние атрибутов default по умолчанию ATTRIBUTES MODIFY DEFAULT ATTRIBUTES MODIFY DEFAULT ATTRIBUTES MODIFY DEFAULT ATTRIBUTES [FOR PARTITION] MODIFY DEFAULT ATTRIBUTES [FOR PARTITION] Нет
Модифицирова- modify ние реальных partition атрибутов MODIFY PARTITION MODIFY PARTITION MODIFY [SUBPARTITION MODIFY [SUBPARTITION Нет
Добавление зна- N/A чений N/A MODIFY PARTITION. ..ADD VALUES N/A MODIFY SUBPARTITION... ADD VALUES Нет
Удаление значе- N/A НИЙ N/A MODIFY PARTITION. ..DROP VALUES N/A MODIFY SUBPARTITION... DROP VALUES Нет
Модифицирова- N/A ние шаблона подраздела N/A N/A SET SUBPARTITION TEMPLATE SET SUBPARTITION TEMPLATE 1 Нет
Перемещение move раздела partition MOVE PARTITION MOVE PARTITION MOVE SUBPARTITION MOVE SUBPARTITION Да
Переименовагие rename раздела partition RENAME PARTITION RENAME PARTITION RENAME [SUBPARTITION RENAME [SUBPARTITION Нет
Разделение раз- split дела partition N/A SPLIT PARTITION SPLIT PARTITION SPLIT [SUBPARTITION Да
Усечение разде- truncate ла partition TRUNCATE partition TRUNCATE PARTITION TRUNCATE [SUB] PARTITION TRUNCATE [SUBPARTITION Да
Управление большими базами данных
667
Не все операции обслуживания доступны для всех типов разделов, потому что либо операция не имеет смысла для данного типа раздела, либо Oracle до сих пор не поддерживает эту операцию!
Во многих случаях операции обслуживания секционированных разделов делают недостоверным (т. с. непригодным для использования. — Прим, пер.) соответствующий базовый индекс; хотя всегда есть возможность обновить индекс вручную, можно специфицировать в команде обслуживания раздела таблицы фразу update indexes. В таком случае операция обслуживания таблицы будет выполняться дольше, поэтому наиболее важным преимуществом применения команды update indexes является то, что индекс остается доступным во время выполнения операции обслуживания раздела. В последнем столбце таблицы 17.5 указано, поддерживает ли данная команда обслуживания раздела опцию update indexes.
Разделение, добавление и удаление разделов
Во многих средах в таблице, секционированной с так называемым “скользящим окном”, будут содержаться только строки за четыре последних квартала, которые требуются для работы. Когда начинается новый квартал, создается новый раздел, а старый раздел архивируется и удаляется из таблицы. В следующем примере мы разделим последний раздел таблицы CAT_REQ, созданной ранее в этой главе, по состоянию на какую-то конкретную дату и снабдим новый раздел значением maxvalue, сделаем резервную копию самого старого раздела и затем удалим его:
□ SQL> alter table oe.cat_req split partition
2 cat_req_win_2005 at (to_date(‘20050101 ’, ‘YYYYMMDD’)) into
3 (partition cat_req_win_2005 tablespace prdO4,
4 (partition cat_req_spr_2005 tablespace prdO1);
Table altered.
SQL> create table oe.arch_cat_req_spr_2004 as
2 select * from oe.cat_req partition (cat_req_spr_2004); Table created.
SQL> alter table oe.cat_req
2 drop partition cat_req_spr_2004;
Table altered.
Представление словаря данных DBAJTAB^PARTITIONS отражает новую схему секционирования:
О SQL> select partition_name, high_value
2 from dba_tab_partitions
3 where table_name = ‘CAT.REQ’;
PARTITION_NAME HIGH VALUE
/CAT_REQ_FAL-2004 T0_DATE(‘ 2004-12-0100:00:00’, *SYYYY-MM-DD HH24:MI:SS’, ‘NLS CALENDAR GREGORIAN’)
668
Гпава 77
CAT_REQ_SUM_2004 TO_DATE(‘ 2004-09-0100:00:00’, ‘SYYYY-MM-DD НН24:MI:SS',
‘NLS_CALENDAR_GREGORIAN’)
CAT_REQ_WIN_2005 T0_DATE(' 2005-01-0100:00:00', ‘SYYYY-MM-DD HH24:MI:SS',
‘NLS_CALENDAR_GREGORIAN’)
CAT_REQ_SPR_2005 MAXVALUE
4 rows selected.
Если удалить любой другой раздел, кроме самого старого, то следующий старший раздел “выбирает слабину” и начинает содержать все новые строки, которые должны были быть размещены в удаленном разделе; независимо от того, какой раздел был удален, строки в разделе больше не принадлежат секционированной таблице. Чтобы сохранить строки, следует вместо drop partition использовать merge partition.
Объединение разделов таблицы
Можно объединить разделы хеш-секционированной таблицы для изменения распределения содержимого раздела по остальным разделам таблицы и сокращения числа разделов таблицы на один. Для созданной ранее в этой главе таблицы CUST этого можно достичь всего за один простой шаг:
□ SQL> alter table oe.cust coalesce partition;
Table altered.
Теперь число разделов в CUST равно трем, а не четырем, как ранее:
□ SQL> select partition_name, tablespace_name
2 from dba_tab_partitions
3 where table_name = ‘CUST’;
PARTITION NAME
TABLESPACE
SYS_P1130
SYS_P1131
SYS P1132
PRD01
PRD02
PRD03
3 rows selected.
Слияние двух разделов таблицы
С помощью различных программ-консультантов Oracle можно выяснить, например, что один из разделов секционированной таблицы использует ся редко или не используется вообще. В подобной ситуации может воз никнуть желание объединить два раздела в один, чтобы сократить уси лия, требующиеся для обслуживания разделов. В данном примере будр скомбинированы разделы MIDWEST и WESTCOAST секционированной таблицы SALES_BY_REGION_BY_DAY в один раздел MID WESTCOAST:
□ SQL> alter table oe.sales_by_region_by_day
2 merge partitions midwest, westcoast
3 into partition midwestcoast ablespace prd04;
Table altered.
Управление большими базами данных
669
Взглянув на данные представления словаря данных DBA__TAB_ PARTITIONS, можно увидеть, что теперь у таблицы осталось только два раздела:
□ SQL> select table_name, partition_name, tablespace_name, high_value
2 from dba_tab_partitions
3 where table_owner = ‘OE’ and
4 table.name = ‘SALES_BY_REGION_BY_DAY’;
TABLE_NAME PARTITION-NAME TABLESPACE HIGH.VALUE
SALES_BY_REGION_BY_ DAY MIDWESTCOAST PRDO4 ‘WT, ‘IL’, ‘ IA’ , ’IN’,
‘MN’, ‘CA’, ‘OR’, ‘WA’
SALES_BY_REGION_BY_DAY OTHER-STATES PRD03 default
2 rows selected.
Обслуживание индексных разделов
Для обслуживания одного или нескольких индексных разделов или подразделов используется команда alter index, точно так же, как для несекцио-нированных индексов. В таблице 17.6 перечислены типы операций с секционированными индексами и ключевые слова, которые необходимо использовать для выполнения этих операций с различными типами секционированных индексов (по диапазону, с хешированием, по списку значений ключа и составное). Команда alter index имеет следующий формат:
□ alre index <имя_индекса> <операция_с1разделом> <опции_операций_с_разделом>;
Как и в случае операций обслуживания разделов таблицы, не все операции являются доступными для каждого типа индексного раздела. Многие опции обслуживания индексных разделов не применимы к локальным индексным разделам. По своей природе локальные индексные разделы совпадают со схемой секционирования самой таблицы, и поэтому они будут изменяться при каждом изменении схемы секционирования таблицы.
Табл ица 17.6. Операции обслуживания для секционированных индексов
Операция с разделами Тип индекса По диапазону Хеш/список значений Составное
Добавить раздел Глобальный N/A ADD PARTITION (хеш) N/A
Локальный N/A N/A N/A
Удалить раздел Глобальный DROP PARTITION N/A N/A
Локальный N/A N/A N/A
Модифицировать атрибуты по умолчанию Глобальный MODIFY DEFAULT ATTRIBUTES N/A N/A
Локальный MODIFY DEFAULT ATTRIBUTES MODIFY DEFAULT ATTRIBUTES MODIFY DEFAULT ATTRIBUTES [FOR PARTITION]
670
Глава 17
Таблица 17.6 (Продолжение)
Операция с разделами Тип индекса По диапазону Хеш/список значений Составное
Модифицировать реальные атрибуты Глобальный MODIFY PARTITION N/A N/A
Локальный MODIFY PARTITION MODIFY PARTITION MODIFY [SUB]PARTITlON
Перестроить раздел Глобальный REBUILD PARTITION N/A N/A
Локальный REBUILD PARTITION REBUILD PARTITION REBUILD SUBPARTITION
Переименовать раздел Глобальный RENAME PARTITION N/A N/A
Локальный RENAME PARTITION RENAME PARTITION RENAME [SUBJPARTITIOIM
Разделить Глобальный SPLIT PARTITION N/A N/A
раздел Локальный N/A N/A N/A
Разбиение раздела глобального индекса
Разбиение раздела глобального индекса во многом похоже на разбиение раздела таблицы. Один конкретный раздел глобального индекса может стать “ горячей точкой” благодаря хранящимся в нем записям индекса; как и в случае с разделом таблицы, можно разделить индексный раздел на два или несколько разделов. В следующем примере один из разделов глобального индекса OE.CAT_REQ_D1?_IX будет разделен на два:
□ SQL> alter table oe.cat„req_dt_ix split partition
2 fal_win_2004 at (to_date(‘20041201’, ‘YYYYMMDD’)) into
3 (partition fal_2004 tablespace idx_7,
4 partition_win_2005 tablespace idx_8);
Index altered.
Записи индекса для раздела FAL_WIN_2004 будут теперь разнесены по двум новым разделам — FAL 2004 и WIN_ 2005.
Переименование раздела локального индекса
Большая часть характеристик локального индекса автоматически обновляется при изменении соответствующего раздела таблицы. Тем не менее, несколько операций над локальным индексным разделом все-гаки приходится выполнять вручную, например перестройку или переименование раздела, имя которому ранее было присвоено генерируемой системой по умолчанию. В данном примере будут переименованы разделы локального индекса для индекса OE.CUST_INS_DT_IX с применением более осмысленных имен:
Управление большими базами данных
671
□ SQL> alter index oe.cust_ins_dt_ix
2 rename partition sys_p1130-to cust_ins_dt_ix_P1; Index altered.
SQL> alter index oe.cust_ins_dt_ix
2 rename partition sys_P1131 to cust_ins_dt_ix_P2; Index altered.
SQL> alter index oe.cust_ins_dt_ix
2 rename partition sys_P1132 to cust__ins_dt_ix_P3; Index altered.
Управление разделами с помощью ЕМ Database Control
Создание разделов таблиц и индексов и управление ими с использованием ЕМ Database Control экономит много времени и избавляет от множества потенциальных ошибок. На web-страницах (см. приведенные ниже рисунки) показаны шаги, требующиеся для создания таблицы, которая поддерживает новую систему ввода заказов и назначения цены. На странице Create Table (см. рис. 17.4) специфицируются имя таблицы, схема, в которой будет размещена таблица, и табличное пространство. Кроме того, здесь же указываются имена столбцов и их атрибуты.
До сих пор создавались только стандартные неупорядоченные таблицы без секционирования, но, если щелкнуть на вкладке Partitions, можно специфицировать метод секционирования (см. рис. 17.5).
Рис. 17.4. Страница Create Page ЕМ Database Control
672
Глава 17
Рис. 17.5. Страница определения метода секционирования ЕМ Database Control
Для таблицы ORDER_QUOTE выбирается секционирование по диапазону, так как мы хотим использовать столбец ORD_DATE для отнесения каждой строки к одному из разделов. На странице Create Range Partitions: Partitioning Columns (см. рис. 17.6) следует указать, какие столбцы надо использовать для секционирования с применением метода диапазонов. В этом случае используется только столбец ORD_DATE.
Щелкнув на кнопке Next, можно перейти на страницу Partitioning Specification (см. рис. 17.7). Первоначально мы хотим создать 12 разделов — по одному для каждого месяца 2004 г. В результате мы указываем 12 как число разделов, 1/1/2004 — как начальную дату и назначаем каждому разделу по одному месяцу.
На странице, изображенной на рис. 17.8, следует указать табличные пространства, используемые для хранения разделов. В этом случае принимается умолчание: специфицируется табличное пространство, первоначально специфицированное для таблицы. Другой предлагаемый вариант — распределение разделов между несколькими табличными пространствами.
После нажатия кнопки Next появляется страница Partition Definitions (см. рис. 17.9), где представлены имена разделов, верхние значения для каждого диапазона и названия табличных пространств. На этой странице можно делать любые изменения имен разделов или их местоположений — например, изменить имя каждого раздела, чтобы в нем отражалось верхнее значение ключа раздела.
Управление большими базами данных
673
Рис. 17.6. Страница ЕМ Database Control Partitioning Columns
Sprocle I pterprne Manager г£геаи$аг & f>arfftfoaing Specfflcalion -tJ|crwh
He Vieiv Fayontes To oh Heb $
• O - 4 (йИ"** ® ::.• я a# u
tetp:#192465,2. ltt:5$00/ft<ri/ccn^!4/dfttab^e^:her.uytab5e?tar9et«»Qrd.wfld?At>'pe-c<ade^dXab3ie$«ca<xe4J^L"/erc/G * |j£j| Co
ORACLE FirteqMhw*. Manager 1O<? D-drt'u-wv Серией ’ ?
Paaftlotunu S|*ecfrcr<i0ii PM& TMiespa-£•Hlt'X nekn-bwhs
Create Range Partitions Partitioning Specification
Database otd. world „.x s"". i ... > Г4 ., ~ч
y vCancel) * наск c4en 2 o* 4 Next J ?..
Legged tn As PJE 4—----J .....i ---J
* Number of partitions i 12[
S3 Use fvWO/AlUE at,* ii< /ж«е* e>t M«e«лkvauX.
Automatically Generate Partition Values
S3 Automatic ally generaTe pan.-lton values
-if -es bo^z? er- tteH**<г<яthe г7nw Ф oafe* ^.*4ыае «е*
9 wok* r/;wn hfrf? M.MS* OATr.
Generate Values for Column: OR£>_DATE '" ......................................-.....*
* Earliest da:e found >.n column У.1^9^ -J !?<а*ч*?эе »и?ь*Л 1/»ХХЛя13
M Length or Tims for Each Panilion 1 ’ ; Months у I
* W* • * -«•»*— .4...ti. ..... >?|'J
C*x TH> и,,* y^Ivu of Гт» firsi рз?1?1гйп ha d^l^rmteed bv ceding the length oHime to »Ия date f:o?
------ - .,._ Internet
Рис. 17.7. Страница EM Database Control Partitioning Specification
674
Гпава
•2 Ofttcfe fnlerpnu Manager (gJffi; <-г**-9
He £3t View Favors Toos Hep
Favcbtes |^j*b'ed;a
Caned) Back ]
4.j;
PjnifHh Partfcan ОеГилс^
’.Zr/’ -> V->
or?zxaue Enterpibe Manager 10g PfcUbasr Con*>^
-Д92.168 2. lM:$5f^*eflVcon$o^7<^ifcase/$che»na/tJfee>Ur'Jjel«cid.*w>d8Jl ре«г+а<> Л aUStefec* dURi.« «'VC'v
- . ,л.^-. *:i -_J . -- Л W Z *- YZA- ** - ‘ V^A-^ee.-rA/ И^«** -VZ • **’•- - -•***- » *'Z <. V jf ° _ __
Hftti WW*-*
Create Ranee Partitions. Partition Tablespaces . v>* ... * -
Database ord.worhl
Log^ec -и A> PJC
Enter one or more tab*e$pace% where the partitions will be stored
® Use table’s tablespace
USERS2
гаг&Лла'г Iwn* »:>£> I jUhSpK
О Use list cf tablespaces for round-robin distribution
{«xen^ite . имез|яс*5, tahiewAcel)
$ TIP You wh be tlte to roodz; г;е-.е mtiai rafc^spacp. ^‘ectans on in* Partition Эййзйижз ps$>)
ч.
Database | Hdp ;
Соруп^Ш Ф1996,2004. Cf ac’e Al rights rt&ervea
ДЬлм» л»яг1й» P'h*.A(h<i«A Мл^> Ipit ЛогЛГГ I
Irter^
Рис. 17.8. Страница EM Database Control Partition Tablespace
Рис. 17.9. Страница EM Database Control Partition Definitions
Управление большими базами данных
675
Search
Ofe'ACI ...£ Enreipnse Млпацег 1%
rewrites Tcx7?5 Heb
.^pr ifrl? f (*Uty M-rraw
fifesSK Partitions
Partitioning Methc-d Range
Partitioning Columns ORD PATE
Ls-Sha Create T&bte
Create Table
Рис. 17.10. Итоговая страница EM Database Control Create Table
Ati.*.->j: £ hr.?r<i7!9Z.!6$ Z 166 55C3/ec-Jrcn«fe^aba^/sdi^r^'rab4>'d.^^>d ^kK(.yt^**ot^dewddt^df^$ncell%w/
Advanced <=
rp (ftf цПйфе ; Цд.* бЙЙПМГЧПАН' iMOc'12
ORDER QUOTE Pl 02Л1/2004 [USERS?
jCROER.ОСОТЕ P2 • • . л l'.A’. lI’-’-'. <5 03.01/2004 USERS?
:CW;E^QUOT^P3 ' . 040Ь2004 USERS?
CRDEr2cu6t6,P4 -v • .v.. zA'.'.* .... • - ; 05012СЮ4 OSERS? £
ORDER.GUOTE.P5 £601/2004 /USERS?™
ORDc.<QUOrr_P6 .. ..*,^4^^. • , j 07010004 USERS?
ORDER QUOTE P7 ....... 0801/2004 USERS?
Щелкнув на кнопке Finish, можно вернуться на страницу Create Table (см. рис. 17.10). Появляется еще одна возможность изменить характеристики секционированной таблицы.
На этой странице имеется также кнопка Show SQL, так что можно увидеть команду SQL, которую необходимо выполнить, чтобы создать секционированную таблицу:
□ CREATE TABLE “0Е”."ORDER_QUOTE"
(“ORD_QUOTE_NUM” NUMBERQ2),
“ORD_DATE” DATE,
“CUST_NUM" NUMBER(15),
’’ORD_TYP_CD” NUMBER(I).
“ORD_SRC_CD” NUMBERQ))
TABLESPACE “USERS2" PARTITION BY RANGE (”ORD_DATE")
(PARTITION ”ORDER_QUOTE_PT’
VALUES LESS THAN (TO_DATE(‘2/1/2004’, ‘MM/DD/YYYY’)), (PARTITION “0RDER_QU0TE_P2"
VALUES LESS THAN (TO_DATE(’3/1/2004’, ‘MM/DD/YYYY’)), (PARTITION “0RDER_QU0TE_P3"
VALUES LESS THAN (TO_DATE(‘4/1/2004’, ‘MM/DD/YYYY’)), (PARTITION “0RDER_QU0TE_P4”
VALUES LESS THAN (TO_DATE(‘5/1/2004’, ‘MM/DD/YYYY’)), (PARTITION “ORDER_QU0TE_P5”
VALUES LESS THAN (T0_DATE(‘6/1/2004’, ’MM/DD/YYYY’)),
676
Глава 17
(PARTITION “0RDER_QU0TE_P6”
VALUES LESS THAN (TO_DATE(‘7/1/2004’, ‘MM/DD/YYYY’)), (PARTITION “0RDER_QU0TE_P7”
VALUES LESS THAN (TO_DATE('8/1/2004', ‘MM/DD/YYYY’)).
(PARTITION “0RDER_QU0TE_P8"
VALUES LESS THAN (TO_DATE(‘9/1/2004’, ‘MM/DD/YYYY’)).
(PARTITION “0RDER_QU0TE_P9"
' VALUES LESS THAN (TO__DATE(110/1/2004’, ‘MM/DD/YYYY’)), (PARTITION “0RDER_QU0TE_P10"
VALUES LESS THAN (TO_DATE(‘11/1/2004*, ‘MM/DD/YYYY’)), (PARTITION “ORDER_QUOTE_Pir
VALUES LESS THAN (TO_DATE(‘12/1/2004’. ‘MM/DD/YYYY’)), (PARTITION “0RDER_QU0TE_P12” VALUES LESS THAN (MAXVALUE));
Щелкнув на кнопке Create, выполните команду SQL и убедитесь в том, что секционированная таблица создана (см. рис. 17.11).
Редактирование характеристик секционированной таблицы столь же просто, как и ее создание. Как показано на рис. 17.12, на странице Edit Table: OE.ORDER_QUOTE нужно на вкладке Partitions выбрать раздел ORDER_QUOTE_P4 для редактирования его характеристик.
После того, как выбран раздел (в данном случае ORDER_QUOTE_P4) и нажата кнопка Advanced Options, появляется возможность изменить характеристики раздела, как это можно было сделать и в случае несекцио-нированной неупорядоченной таблицы. На странице, представленной на рис. 17.13, изменяется опция компрессирования только для этого раз-
Рис. 17.11. Подтверждение создания разделов в ЕМ Database Control
Управление большими базами данных
677
' r , '* s* • ▼ -чч v л j - „•. ; iypyr^"j> У*1"
3 OriJ<? Enterprise М40ЛЙСГ,(JUJ) • Tai’e Var1il|ien* * Micr<»ift !nierf>et tx^brer
He EOt Vfew Favcckes Took Edp
f'^’S mA .^>*v
13Lj l*d <» >
, Searrb s< P^vorcei 0 qJ
Loyfied in AS RJ*3
f^aJu^o..
УЙй
: ^h^7/l^.l68.2.16$:55DG/ern/consoto/d«eMse/jdxffl«aAM^ar9M»^dAMCrke<vi)e"<xad<s_<facab»e&$name«CEe<>nam •*”
.... -,. ... л :;.._
OP ACL.€'Enterprise Manager Kty (Maha*» ( tsrtnni
Search by Partition Name
Partitioning Method Range
Partitioning Cclunns ORD_DATE
fittiiSWati Stoaas йш,. partitions I Suites
> LlxjSJx > edit Table. OE ORDER_QUOTE Edit Table: OE.ORDER QUOTE
*>к****Л * AVrvv™A.4> ’ >л
•о
'p'.'ff а*.*^ГГ^Л‘Л,.<Г*'— *'"'У<>швТ!ЧвС|Р|
:
й;
;•
0 ORDER_OUOTE_Pl О2Л11/2ОО4 USERS2
О ORDeROUOTE_P2 034)1/2004 USERS2
0 ORC»ER_OJOTE_P3 044102004 USERS2
Ф ORDER QUOTE P4 054)1/2004 USERS2
• * • • • -•• " 1 •' • • • •- • • s*>-• . • - • * • • 4 • •- I • Г •
О ORDER_QJOTE_P5 06/01/2004 USERS2
C ORDER.QUOTE PG 07/01 /2004 USERS2
О OROER_QUOTE_₽7 084IU2004 USERS?
О ORDER_OUOTE_P8 09)01/2004 USERS2 ...... .« >.^-Д -i , .Л. . . * ;
' Ж-ii u t) thlernet
Рис. 17.12. Страница EM Database Control OEjORDER_QUOTE
p ис. 17.13. pacuinpEHHbie 0П111Ш хранения разделов в ЕМ Database Control
678
Глава 17
дела; при вставке строк в прямом режиме строки для этого сегмента будут компрессироваться для экономии дисковой памяти, что приведет всего лишь к незначительному увеличению временных затрат на декомпрессирование строк при их выборке.
Материализованные представления
В другом типе таблиц, которые принято называть ма7периализованными представлениями (materialized views), сочетаются характеристики таблицы и представления. Этот тип похож на представление тем, что содержащиеся в нем данные выводятся из запроса к одной или нескольким таблицам; сходство же с таблицами состоит в том, что результирующий набор представления оставляется в сегменте для постоянного хранения. Материализованные представления полезны как в системах OLTP, так и в системах DSS. Вместо того чтобы раз за разом при каждом своем выполнении производить соединения множества сильно нормализованных таблиц, часто выполняемые запросы пользователей к операционным данным получают возможность использовать материализованные представления. А в средах DSS архивные данные могут быть агрегированы заранее, чтобы обеспечить выполнение запросов DSS всего лишь за небольшую долю того времени, которое требуется для выполнения этих запросов в случае агрегации данных, что называется, “на лету”.
Данные в материализованных представлениях могут быть обновлены либо по требованию, либо инкрементально, принимая во внимание производственные нужды. В зависимости от сложности базовых операторов SQL материализованное представление может быть быстро доведено до актуальности с помощью инкрементальных изменений из журнала материализованных представлений (materialized view log).
Для создания материализованного представления используется команда create materialized view; синтаксис этой команды аналогичен синтаксису для создания стандартного представления. Поскольку в материализованном представлении сохраняются результаты выполнения запроса, можно также специфицировать параметры хранения для представления, как если бы создавалась таблица. В команде create materialized view также указывается, как должно обновляться представление. Материализованное представление может быть обновлено либо по запросу, либо при внесении изменений в одну из базовых таблиц представления. Кроме того, можно в принудительном порядке обязать материализованное представление использовать для инкрементальных обновлений журнал материализованного представления, либо полное ью перестраивать материализованное представление, когда возникает необходимость в его обновлении.
Если оптимизатор определит, что в конкретном материализова представлении уже содержатся результаты переданного на выполнени запроса пользователя, то материализованное представление может быть ав томатически использовано оптимизатором; пользователь даже не о я знать о том, что его запрос непосредственно использует материализован ное представление, а не базовые таблицы. Но для того чтобы разрешить так называемую перезапись запроса (query rewrite), у пользователя должна иметься системная привилегия QUERY REWRITE, а параметр инициализа-т>ихлп?тпгк гылш FT) должен быть задан как TRUE.
Управление большими базами данных
679
Использование битовых индексов
Альтернативой индексам со структурой В-дерева (B*tree тс!ех)являются так называемые битовые индексы (bitmap indexes), которые обеспечивают некоторые преимущества при оптимизации запросов в средах, где часто выполняются соединения по столбцам с низкой кардинальностью.
Осмысление битовых индексов
Битовые индексы очень полезны в средах VLDB, когда подлежащий ин-• дексированию столбец содержит очень малое число возможных значений, примером чего может служить пол (gender) объекта, принимающий всего два различных значения (обычно обозначаются как ‘М’ и ‘F’). В битовом индексе для представления существования или не существования конкретного значения столбца используется строка, состоящая из нулей или единиц. При использовании битовых индексов применение в запросе многочисленных операторов AND и OR над несколькими столбцами становится значительно более эффективным и легким. Битовые индексы чаще встречаются в хранилищах данных и в других средах VLDB, где бывают столбцы с низкой кардинальностью, команды DML выполняются как операции массовой обработки данных, а в условиях запросов на обработку часто встречаются столбцы с битовыми индексами.
Требования к дисковой памяти для битовых индексов остаются низкими до тех пор, пока остается низкой кардинальность; скажем, битовый индекс по столбцу GENDER для таблицы EMPLOYEE будет состоять из двух битовых строк-отображений с длиной, равной количеству строк в таблице. Если в таблице EMPLOYEE насчитывается 15 строк, битовый индекс для столбца GENDER может выглядеть, например, вот так:
□ GENDER_BM_IX:
F: 110111000101110 t
М: 001000111010001
Нетрудно видеть, что размер битового индекса прямо пропорционален кардинальности подлежащего индексированию столбца. Битовый индекс по столбцу LASTJNAME таблицы служащих будет значительно больше, и может оказаться, что многие преимущества, предоставляемые битовыми индексами, теряются на фоне огромного дискового пространства, потребляемого этим индексом. Хотя, как иу каждого правила, здесь тоже имеются исключения. Кардинальность индексируемого столбца может доходить до 10% от числа строк таблицы, и битовые индексы будут все еще функционировать хорошо; другими словами, таблица с 1000 строк и 100 различными значениями для некоторого конкретного столбца с большой вероятностью выиграет от применения битового индекса.
Примечание Во время обработки запросов оптимизатор Oracle динамически конвертирует элементы битового индекса в ROWID. Такое преобразование позволяет оптимизатору использовать битовые индексы с помощью индексов со структурой В-дерева для столбцов, в которых много разных значений.
680
Глава 17
До появления Oracle 10g производительность битовых индексов часто ухудшалась с течением времени вследствие высокой активности операций DML над таблицей с битовыми индексами. Для того чтобы иметь возможность воспользоваться усовершенствованиями внутренней структуры битовых индексов, нужно установить параметр инициализации на 10.0.0.0 или более высокое значение. Битовые индексы, плохо работавшие до настройки параметра COMPATIBLE, необходимо перестроить; битовые индексы, которые адекватно работали до изменения параметра COMPATIBLE, после этого изменения начнут работать лучше. Любые индексы, созданные после настройки параметра COMPATIBLE, могут пользоваться преимуществами всех усовершенствований.
Применение битовых индексов
Создать битовый индекс легко; синтаксис создания идентичен синтаксису для создания любого другого индекса с добавлением ключевого слова BITMAP. В следующем примере в таблицу EMPLOYEES будет добавлен столбец GENDER, а затем по нему будет создан битовый индекс:
П SQL> alter table hr.employees
2 add (gender char(1));
Table altered.
SQL> create bitmap index
2 hr.gender_bm_ix on hr.employees(gender);
Index created.
Применение битовых индексов соединения
Начиная с Огас1е9г, можно создавать так называемые битовые индексы соединения (bitmap join indexes). Битовый индекс соединения является битовым индексом, представляющим соединение двух или нескольких таблиц. Для каждого значения столбца из первой таблицы соединения битовый индекс сохраняет ROWID для соответствующих строк из других таблиц с теми же самыми значениями столбца, что и у столбца первой таблицы. Битовые индексы соединения являются альтернативой материализованным представлениям, которые содержат условие соединения; память, требующаяся для хранения связанных ROWID, может оказаться существенно меньшей, чем память для хранения результатов самого представления.
В данном примере обнаруживается, что отдел кадров часто выполняет соединение таблиц EMPLOYEES и DEPARTMENTS по столбцу DEPARTMENTS_ID. В качестве альтернативы созданию материализованного представления нужно создать битовый индекс соединения. Ниже приводится соответствующий оператор SQL:
□ SQL> create bitmap index
2 hr.emp_dept_bj_idx on hr.employees(hr.departments.department-id)
3 from hr.employees, hr.departments
4 where hr.employees.department-id = hr.departments.department-id;
Index created.
Управление большими базами данных
681
Для битовых индексов соединения существуют некоторые ограничения:
Только одна из таблиц, входящих в состав битового индекса соединения, может одновременно обновляться разными оперативными транзакциями, если используется битовый индекс соединения.
Таблица не может дважды участвовать в соединении.
Нельзя создавать битовые индексы соединения для ЮТ или временных таблиц.
Столбец(цы) соединения, используемый для индекса, должен быть первичным ключом или иметь ограничение по уникальности в таблице, соединяемой с таблицей, для которой создается битовый индекс.
Oracle Data Pump
В новинке Oracle 10g— Oracle Data Pump — предлагается функциональность, аналогичная первоначальным утилитам экспорта (ехр) и импорта (imp) данных, но инфраструктура Data Pump Export и Import в большей степени ориентирована на сервер. Первоначальные утилиты ехр и imp должны использоваться только в тех случаях, когда необходимо импортировать набор дампов из предыдущей версии Oracle в базу данных Oracle 10g или когда нужно выполнить экспорт набора дампов из базы данных Oracle 10g в предыдущую версию Oracle.
Новые клиентские приложения expdp и impdp, запускаемые из командной строки, используют пакет DBMS_METADATA для извлечения определения объектов из словаря данных в виде XML или DDL или пакет DBMSJDATADUMP для выполнения переноса данных и метаданных из одной базы данных в другую. Вся обработка в Data Pump Export и Data Pump Import выполняется на сервере, а не на стороне клиента, для чего требуется наличие объектов каталога в исходной и целевой базе данных.
Ниже приводится несколько других улучшений и возможностей, выгодно отличающих Data Pump Export и Import от использовавшихся ранее утилит ехр и imp:
Задание, осуществляющее экспорт или импорт, может контролировать число параллельных потоков, используемых для задания.
Возможность перезапуска задания Data Pump при его остановке или аварийном завершении.
Поддержка экспорта и импорта по сети без использования наборов файлов дампа.
Возможность подключаться к выполняющемуся заданию из клиентского процесса и отключаться от него.
Возможности оценки размеров памяти без фактического выполнения экспорта.
Указание версий баз данных для объектов, подлежащих экспорту или импорту.
11 Г*°5деРжка детальной фильтрации метаданных, а также данных таолица за таблицей" (table-by-table).
682
Гпава 17
Ниже будут рассмотрены переносимые табличные пространства, использующие возможности Data Pump и пакета DBMS_FILE_TRANSFER для создания и переноса набора дампов табличного пространства в другую базу данных.
Data Pump Export
Приложение Data Pump Export (или просто Export) выгружает данные и метаданные в набор файлов операционной системы, который называется набором файлов дампа (dump file set). Этот набор может быть прочитан только с помощью Data Pump Import. Набор файлов дампа состоит из нескольких дисковых файлов, содержащих метаданные, данные и управляющую информацию, и записывается в специализированном двоичном формате. Для запуска экспорта (Export) следует использовать запускаемую из командной строки операционной системы утилиту expdb.
При экспорте данные могут выгружаться с использованием ряда различных режимов, зависящих от того, какие типы объектов экспортируются, и варьируются от экспорта одной таблицы до экспорта всей базы данных. Поддерживаются следующие режимы экспорта: Full Export (полный экспорт), Schema (экспорт схемы), Table (экспорт таблицы), Tablespace (экспорт табличного пространства) и Transportable Tablespace (экспорт переносимого табличного пространства).
Режим полного экспорта
При полном экспорте используется параметр full команды expdp. Выгружается вся база данных. Для выполнения экспорта всей базы данных пользователю должна быть назначена роль EXP_FULL_DATABASE.
Режим экспорта схемы
Экспортируется одна или несколько схем посредством параметра schemas команды expdp; этот режим применяется по умолчанию. Если пользователю назначена роль EXP_FULL_DATABASE, он может экспортировать любую схему; в противном случае можно экспортировать только собственную схему.
Режим экспорта таблицы
В режиме экспорта таблицы по команде expdp экспортируется специфицированный набор таблиц; в команде используется параметр tables. Если пользователю назначена роль EXP_FULL_DATABASE, он может экспортировать таблицы в любой схеме; в противном случае можно экспортировать таблицы только из собственной схемы.
Режим экспорта табличного пространства
Чтобы экспортировать табличное пространство, необходимо иметь роль EXP_FULL_DATABASE. Режим экспорта табличного пространства яв ется удобным сокращением для экспорта всех таблиц в составе одного или нескольких указанных табличных пространств. Экспортируются все объекты, зависящие от экспортируемых таблиц, которые постоянно раз
Управление большими базами данных
683
мещены в специфицированных табличных пространствах, даже если объекты сами размещены в других табличных пространствах. Параметр tablespaces команды expdp используется для указания одного или нескольких подлежащих экспорту табличных пространств.
Режим экспорта переносимого табличного пространства
При переносе табличного пространства экспортируются только метаданные для содержащихся в нем объектов; в отличие от режима экспорта табличного пространства, объекты в этом пространстве должны быть полностью обособленными (self-contained). Для специфицирования табличных пространств используется параметр transport tablespaces в утилите командной строки expdp. После создания набора дампов с метаданными следует скопировать файлы данных табличного пространства (пространств), которое(ые) должно быть перенесено, на целевой сервер для их “вставки” в целевую базу данных с помощью утилиты impdp. Ниже в данной главе будет показано, как переносить табличное пространство из одной базы данных в другую, используя объекты каталога, expdp и impdp. Как и в случае многих других моделей, для использования режима экспорта переносимых табличных пространств требуется иметь роль EXP_FULL_DATABASE.
Data Pump Import
Приложение Data Pump Import (или просто Import) загружает в целевую систему набор файлов экспорта дампа, созданный Data Pump Export. Импорт инициируется из командной строки операционной системы путем использования команды impdp.
При импорте доступны те же самые режимы, что и при экспорте: Full Import (полный импорт), Schema (импорт схемы), Table (импорт таблицы), Tablespace (импорт табличного пространства) и Transportable Tablespace (импорт переносимого табличного пространства).
Режим полного импорта
При полном импорте в команде impdp используется параметр full. При выполнении полного импорта в целевую базу данных загружается весь набор файлов дампа (или вся база данных, если выполняется сетевой импорт без создания набора файлов дампа). Если другая база данных импортируется непосредственно или если импортируется набор файлов данных, экспортированный с использованием роли EXP_FULL__DATABASE, необходимо иметь роль IMP_FULL_DATABASE.
Режим импорта схемы
Для импорта объектов из собственной схемы или, если у вас есть роль IMP_FULL_DATABASE, из любого количества схем в наборе файлов дампа необходимо использовать параметр schemas команды impdp.
684
Глава 17
Режим импорта таблицы
Для импорта конкретных таблиц из набора файлов дампа, содержащего результаты либо операции полного экспорта, либо экспорта схемы, табличного пространства или отдельных таблиц, следует использовать параметр tables команды impdp. Кроме того, источником импорта может быть другая база данных. Если импортируемые таблицы не принадлежат вашей схеме, необходимо иметь роль IMP_FULL_DATABASE.
Режим импорта табличного пространства
Параметр tablespaces используется в командной строке impdp для импорта одного или нескольких табличных пространств в текущую базу данных. Источником импорта табличных пространств может быть экспорт табличных пространств, полный экспорт базы данных, экспорт схемы, экспорт отдельных таблиц или другая база данных.
Режим импорта переносимого табличного пространства
Используя параметр transport tablespaces, можно импортировать метаданные из набора файлов дампа переносимого табличного пространства или из другой базы данных. Параметр transport datafiles указывает на местоположение, в котором размещены файлы данных переносимого табличного пространства.
Применение переносимых табличных пространств
Переносимые табличные пространства значительно облегчают перемещение больших объемов данных между базами данных, по целому табличному пространству за один раз; Oracle 10£предлагает ряд усовершенствований в технологии перемещаемых табличных пространств. В результате значительно упростился перенос данных между базами данных, которые размещены на разных аппаратных и софтверных платформах. Утилиты Data Pump Export и Import играют ключевые роли в переносе табличных пространств между базами данных.
В приведенном ниже сценарии expdp и impdp вместе с пакетом DBMS_FILE_TRANSFER используются для копирования табличного пространства INET_AUDIT из базы данных ord в базу данных rmanrep. Процесс (на высоком уровне) содержит следующие пять шагов:
1. Создайте в исходной и целевой базе данных каталоги для наборов файлов дампа и файлов данных табличных пространств (одноразовое создание).
2. Проверьте обособленность табличного пространства с помощью процедуры DBMS_TTS.TRANSPORT_SET_CHECK.
3. Используйте expdp для создания метаданных для табличного пространства INET_AUDIT.
4. Используйте DBMS_FILE_TRANSFER для копирования набора(ов) файлов дампа и файлов данных в целевую базу данных.
5. В целевой базе данных используйте impdp для “подключения” табличного пространства.
Управление большими базами данных
685
Создание объектов каталога
В исходной базе данных (ord) необходимо создать объекты каталога, в которых будут храниться наборы файлов дампа, а также объект каталога, указывающий на место, где хранятся файлы данных табличного пространства INET-AUDIT. Ниже приводятся соответствующие команды SQL для базы данных ord:
□ SQL> create directory src_dpump_dir as 1/u02/dumpset’;
Directory created.
SQL> create directory src_dbf_dir as ‘/u04/oradata/ord’;
Directory created.
В целевой базе данных (rmanrep) выполните аналогичные команды:
□ SQL> create directory dest_dpump_dir as ‘/u03/dumpset’;
Directory created.
SQL> create directory dest_dbf_dir as ‘/иОЗ/oradata/ord’;
Directory created.
Эти каталоги являются постоянными, и их можно использовать в будущем для других операций Data Pump или переноса файлов.
Проверка обособленности табличного пространства
Перед переносом табличного пространства INET_AUDIT необходимо с помощью процедуры DBMS_TTS.TRANSPORT провести проверку, позволяющую быть уверенным, что все объекты в табличном пространстве являются обособленными:
П SQL> exec dbms_tts.transport_set_check(‘inet_audit’, TRUE);
PL/SQL procedure successfully completed.
SQL> select * from transport_set_violations; no rows selected.
Тот факт, что в представлении TRANSPORT_SET_VIOLATION не обнаружено ни одной строки, означает, что в табличном пространстве нет зависимых внешних объектов. Это представление создается заново при каждом выполнении процедуры DBMS_TTS.TRANSPORT_SET_CHECK.
Использование expdp для создания метаданных
Находясь в базе данных ord, нужно выполнить команду expdp для экспорта метаданных, ассоциируемых с табличным пространством INET_ AUDIT, предварительно переведя INET_AUDIT в режим “только для чтения”:
П SQL> alter tablespace inet_audit read only; Tablespace altered.
Чтобы выполнить expdp, нужно открыть строку приглашения one-
у- ">Г ДГ V v
разом* °И СИстемы и выполнить экспорт метаданных следующим об-
686
Глава 17
□ $ expdp system/manager dumpfile=expdat.dmp directory=src_dpump_dir transport_tablespaces=inet_audit
Export: Release 10.1.0.2.0 -
Production on Sunday, 22 August, 2004 14:18
Copyright (c) 2003, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition
Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
Starting “SYSTEM”. ''SYS_EXP0RT_TRANSP0RTABLE_01“: system/******** dumpfile=expdat.dmp directory=src dpump_dir transport_tablespaces=inet_audit
Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
Processing object type TRANSPORTABLE_EXPORT/TABLE
Processing object type TRANSPORTABLE_EXPORT/TTE_POSTINST/PLUGTS_BLK
Master table “SYSTEM”.”SYS_EXP0RT_TRANSP0RTABLE_01” successfully loaded/unloaded
**************************************************************
Dump file set for SYSTEM.SYS_EXP0RT_TRANSP0RTABLE_01 is: /u02/dumpset/expdat. dmp
Job “SYSTEM"."SYS_EXP0RT_TRANSP0RTABLE_01" successfully completed at 14:19
$
Использование DBMSJFILE_TRANSFER для копирования файлов
На этом шаге необходимо скопировать файл /u02/dumpset/expdat.dmp и файлы данных табличного пространства в удаленную базу данных, используя DBMS JFILEJTRANSFER:
□ SQL> execute dbms_file_transfer.put_file (
2 ‘src_dpump_dir’, ‘expdat.dmp’,
3 ‘dest_dpump_dir’, ‘expdat.dmp’, ‘rmanrep’);
PL/SQL procedure successfully completed.
SQL> execute dbms_file_transfer.put_file (
2 ‘src_dbf_dir’, ‘0RD/datafile/o1_mf_inet_audit_01kqy57o_.dbf’,
3 ‘dest_dpump_dir’, ‘inet.audit.dbf’, ‘rmanrep’);
PL/SQL procedure successfully completed.
Поскольку табличное пространство было создано с использованием OMF, придется использовать значение DB_FILE__CREATE__DEST и провести некоторую исследовательскую работу либо использовать динамическое представление производительности V$TABLESPACE, чтобы отследить фактический подкаталог и имя файла данных на хосте операционной системы.
Управление большими базами данных
687
Использование impdp для импорта метаданных
На заключительном шаге нужно выполнить утилиту impdp для целевой базы данных, чтобы прочитать метаданные и “подключить” файлы данных табличного пространства. Ниже приводятся выходные данные этой операции:
□ $ impdp system/manager directory=dest_dump_dir dumpfile=expdat.dmp
transport_datafiles=/u03/oradata/inet_audit.dbf
Import: Release 10.1.0.2.0 - Production on Sunday, 22 August, 2004 14:41
Copyright (c) 2003, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition
Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
Master table “SYSTEM”. ,,SYS__IMPORT_TRANSPORTABLE_OT’
successfully loaded/unloaded
Starting “SYSTEM”. ,,SYS_IMP0RT_TRANSP0RTABLE_01 ”:
system/******** directory=dest_dpump dir
dumpfile=exdat.dmp
transport_datafiles=/u03/oradata/inet_audit.dbf
Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
Processing object type TRANSPORTABLE,EXPORT/TABLE
Processing object type TRANSPORTABLE_EXPORT/TTE_POSTINST/PLUGTS_BLK
Job “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_OT’
successfully completed at 14:41
$ sqlplus / as sysdba
• • •
SQL> select * from v$tablespace;
TS# NAME INC BIG FLA
0 SYSTEM YES NO YES
1 UND0TBS1 YES NO YES
2 SYSAUX YES NO YES
4 USERS YES NO YES
3 TEMP YES NO YES
6 EXAMPLE YES NO YES
7 RMAN YES NO YES
8 INET AUDIT YES YES YES
8 rows selected.
SQL> alter tablespace inet_audit read write; Tablespace altered.
Необходимо перевести табличное пространство из режима READ ONLY в режим READ WRITE; дело в том, что после перемещения табличного пространства в другую базу данных по умолчанию оно является опе-ративным (online), но находится в режиме “только для чтения”.
УПРАВЛЕНИЕ РАСПРЕДЕЛЕННЫМИ
БАЗАМИ ДАННЫХ
В распределенной среде базы данных, расположенные на отдельных серверах (хостах), могут организовать доступ друг к другу в рамках единой транзакции или запроса. Каждый сервер может быть физически изолирован от других, но логически связан с ними.
Типичной реализацией распределенной базы данных является конфигурация, в которой центральные серверы, размещенные в штаб-квартире компании, тиражируют (replicate) данные на сервера подразделений, находящиеся в различных других местах. Каждая база данных поддерживает локальные клиентские приложения, но вместе с тем может взаимодействовать по сети с другими базами данных (см. рис. 18.1).
Когда один сервер посылает запрос к базе данных на другом сервере, он выступает в роли клиента. Принимающий сервер выполняет переданный ему SQL-оператор и возвращает серверу-отправителю результаты, а также сообщения об ошибках.
База данных и Oracle Net
Сервер
Сервер
База данных и Oracle Net
База данных и Oracle Net
Сервер
Рис. 18.1. Архитектура сервер/сервер
Управление распределенными базами данных
689
Реализация рассмотренной архитектуры обеспечивается с помощью средства Oracle Net. Выполняемое на всех серверах, это средство позволяет передавать запросы от одной базы данных (или приложения) к другой, размещенной на отдельном сервере. Поддерживаются как распределенные запросы, так и распределенные обновления. Эти функциональные возможности позволяют взаимодействовать со всеми базами данных, доступными по сети. Можно также создавать синонимы, которые обеспечат для приложений реальную прозрачность сети; пользователь, посылающий на выполнение запрос, не будет знать о местонахождении полученных в ответ данных.
Можно сконфигурировать Oracle так, чтобы поддерживалось симметричное тиражирование (multimaster replication), при котором все участвующие в нем базы данных владеют данными и могут служить источником их распространения, или несимметричное тиражирование (single-master replication), когда данными владеет только одна база данных. При проектировании конфигурации тиражирования следует попытаться как можно больше ограничить право собственности, поскольку по мере роста источников распространения данных резко возрастают вероятность возникновения ошибок и административная нагрузка.
Удаленные запросы
Для выполнения запроса к удаленной базе данных необходимо создать связь баз данных (database link). Эта связь определяет имя используемой службы для удаленной базы данных, а также может определять имя пользователя, с которым устанавливается соединение в удаленной базе данных. Когда оператор SQL ссылается на связь баз данных, Oracle открывает сеанс в удаленной базе данных, выполняет там этот оператор и возвращает данные. Связи баз данных могут быть созданы как публичные (public), которые создаются администраторами баз данных и доступны всем пользователям локальной базы данных, или приватные (private).
В следующем примере создается публичная связь баз данных с именем HRJLINK:
□ create public database link HR_LINK connect to HR identified by PUFFINSTUFF using * hq’;
Как видно из этого примера, команда create database link имеет несколько параметров:
и Необязательное ключевое слово public позволяет АБД создавать связи для всех пользователей базы данных (о другом необязательном ключевом слове — shared — см. ниже).
и Имя связи (в данном случае HRJLINK).
и Учетная запись, с которой нужно соединиться. Связь баз данных можно сконфигурировать так, чтобы в удаленной базе данных использовались имя и пароль локального пользователя. Эта связь соединяет с фиксированным пользователем в удаленной базе данных.
и Имя службы (в этом примере — hq).
690
Гпава 18
Локальный запрос:
Рис. 18.2. Пример удаленного запроса
Для использования вновь созданной связи ее достаточно добавить в качестве суффикса к именам таблиц в командах. В следующем примере выполняется запрос к удаленной таблице с использованием связи баз данных HR_LINK:
П select * from EMPLOYEE@HR_LINK where Office = ‘ANNAPOLIS’;
Для выполнения этого запроса Oracle установит сеанс с помощью связи HR LINK и обратится с запросом к таблице EMPLOYEE в удаленной базе данных. К строкам EMPLOYEE применяется конструкция where, в результате чего будут возвращены соответствующие записи. Выполнение этого запроса схематично показано на рис. 18.2.
В этом примере фраза from ссылается на EMPLOYEE@HR_LINK. Поскольку в связи базы данных HR LINK указаны имена сервера, экземпляра и владельца, известно полное имя таблицы. Если в связи базы данных не указано имя учетной записи, то при регистрации в удаленной базе данных будут использованы имя учетной записи и пароль локального пользователя (подробнее об управлении связями баз данных см. ниже в данной главе).
Манипулирование удаленными данными: двухфазная фиксация транзакции
Для поддержки манипулирования данными в нескольких базах данных одновременно необходимо использовать алгоритм двухфазной фиксации транзакции (Two-Phase Commit — 2РС). Алгоритм 2РС позволяет рассматривать группы транзакций в нескольких узлах как единое целое. Фиксация (commit) или откат (rollback) буду! выполнены только для всех этих транзакций. Набор распределенных транзакций показан на рис. 18. . Здесь выполняются две транзакции обновления (update): первая — для локальной таблицы (EMPLOYEE), а вторая для удаленной таблицы (EMPLOYEE@HR .LINK). После завершения обеих транзакций выполня-
Управление распределенными базами данных
691
Рис. 18.3.
Пример распределенной транзакции
ется общий оператор commit. Если одна из транзакций не может быть зафиксирована, производится откат обеих транзакций.
Распределенные транзакции очень полезны в двух отношениях: можно обновлять базы данных на других серверах, и такие транзакции можно группировать с другими в одну логическую единицу. Последнее становится возможно благодаря использованию 2РС. Этот алгоритм имеет следующие две фазы:
в Фаза подготовки — Инициирующий узел, который называется глобальным координатором (global coordinator), уведомляет все узлы, вовлеченные в транзакцию, о необходимости быть готовыми к фиксации или откату транзакции.
и Фаза фиксации — Если в фазе подготовки никаких проблем не возникло, то все узлы фиксируют свои транзакции. Если произошел сбой в сети или в отдельном узле, все узлы выполняют откат своих транзакций.
Работа алгоритма 2РС прозрачна для пользователей. Если узел, который инициирует транзакцию, забывает о ней, выполняется третья фаза — фаза забывания (об управлении распределенными транзакциями см. ниже в данной главе).
Динашческое тиражирование данных
С целью повышения эффективности запросов, использующих информацию из удаленных баз данных, можно тиражировать эту информацию на локальный сервер. Для этого существует несколько способов, зависящие OI юго, какие именно возможности ORACLE используются.
692
Глава 18
Тиражирование данных из одной таблицы в другую возможно с помо-щыо триггеров базы данных (database triggers). Например, после каждого ввода данных в таблицу возможно срабатывание триггера, вводящего ту же запись в другую таблицу, а эта таблица может храниться в удаленной базе данных. Таким образом, триггеры можно использовать для принудительного тиражирования данных в простых конфигурациях. При невозможности контролировать тип транзакций, выполняемых над базовой таблицей, код триггера, выполняющего тиражирование, становится излишне сложным.
Используя возможности Oracle по работе с распределенными базами данных, можно выполнять тиражирование с помощью материализованных представлений (materialized views). При этом нс обязательно тиражировать всю таблицу или данные только из одной таблицы. Для тиражирования одной таблицы можно использовать фразу where, чтобы ограничить диапазон записей, подлежащих тиражированию, а также можно выполнять над данными операции group by. Кроме того, можно соединять таблицу с другими таблицами и тиражировать результаты запросов.
Примечание Материализованные представления нельзя использовать для тиражирования данных, имеющих типы LONG, LONG RAW или определенные пользователем типы данных.
Данные в локальном материализованном представлении удаленной таблицы необходимо освежать (обновлять). Если задать интервал обновления, база данных будет выполнять процедуры тиражирования автоматически. Во многих случаях база данных может использовать журнал материализованного представления (materialized views log) для пересылки только данных транзакции. В противном случае база данных будет выполнять полное обновление локального материализованного представления.
Для создания резервной базы данных (и управления ею), информационный контент которой будет автоматически обновляться при каких-либо изменениях в основной базе данных, можно использовать технологию Data Guard. Резервная база данных может быть использована как база данных “только для чтения”, чтобы служить вспомогательной базой при создании отчетов, после чего она снова возвращается к своему статусу резервной базы данных (подробнее об использовании резервных баз данных и управлении ими см. главу 14).
Унравлвки® джыи
Прежде чем управлять транзакциями в удаленных базах данных, пеобхо-димо поместить в них данные и обеспечить их доступность для других оаз данных.
Примечание В примерах этой главы предполагается, что для разрешения имен служб баз данных используются файлы tnsnames.ora.
Управление распределенными базами данных
693
Инфраструктура: Обеспечение прозрачности местонахождения
Для правильного проектирования распределенных баз данных на длительный срок вначале необходимо сделать прозрачным для приложений физическое местонахождение данных. Имя таблицы базы данных является уникальным в пределах той схемы, которой опа принадлежит. Следовательно, комбинация из имени владельца и имени таблицы будет однозначно идентифицировать таблицу в пределах любой базы данных. Однако в удаленной базе данных может встретиться такая же комбинация — учетная запись с таким же именем, владеющая таблицей с тем же именем.
В распределенных базах данных необходимо вводить два дополнительных уровня идентификации объектов. Сначала должно быть указано имя экземпляра, который обращается к базе данных. Затем — имя хоста, на котором размещается данный экземпляр. Объединение этих четырех частей имени объекта — хоста, экземпляра, владельца и имени — даст глобальное имя объекта (global object name). Для обращения к удаленной таблице требуется знать глобальное имя объекта этой таблицы.
Прозрачность местонахождения позволяет сделать три первые части глобального имени объекта —хост, экземпляр и схему—прозрачными для пользователя. Первые три части глобального имени объекта указываются в связях баз данных, поэтому любые попытки обеспечить прозрач-
База данных MASTER 1 База данных REMOTE 1
а) Простое материализованное представление; можно использовать журнал материализованного представления.
База данных MASTER 1
База данных REMOTE 1
Рис. 18.4. Тиражирование с помощью материализованных представлений
694
Глава 18
ность местонахождения должны начинаться отсюда. Рассмотрим типичную связь базы данных:
□ create public database link HR_LINK connect to HR identified by PUFFINSTUFF using ‘hq’;
Примечание Если параметр инициализации GLOBALJMAMES установлен на TRUE, имя связи базы данных должно совпадать с глобальным именем удаленной базы данных.
Прозрачность имен хоста и экземпляра обеспечивается использованием имени службы (hq). Эти имена транслируются в действительные значения с помощью файла tnsnames.ora локального хоста. Одна из записей этого файла (для службы hq) показана в следующем листинге:
□ hq -(DESCRIPTION-
(ADDRESS=
(PROTOCOL-TCP)
(HOST-HQ)
(PORT-1521))
(CONNECT DATA-
(SERVICE-NAME-LOC))))
Две строки этого листинга, выделенные полужирным шрифтом, определяют два отсутствующих компонента имени GON: при использовании имени службы HQ именем хоста будет HQ, а именем экземпляра — LOC. В файле tnsnames.ora указаны параметры протокола TCP/IP; для других протоколов ключевые слова могут отличаться, ио используются они таким же образом. Записи в файле tnsnames.ora обеспечивают прозрачность имен серверов и экземпляров.
Связь базы данных HR„LINK, созданная с помощью показанного выше кода, обеспечит прозрачность первых двух частей глобального имени объекта. А если данные из схемы HR будут перемещены или изменится пароль учетной записи HR, придется удалить связь базы данных и создать ее заново. То же самое потребуется и для обеспечения безопасности на уровне учетных записей; возможно, придется создавать и обслуживать множество свя ей баз данных.
Чтобы о< к ючить прозрачность схемы в глобальном имени объекта, можно изменить синтаксис связи баз данных. Рассмотрим следующую связь:
□ create puolic database link HR_LINK connect to current_ user using ‘hq’;
В этой связи баз данных используется фраза connect to current_user. Она использует так называемое соединение подключенного пользователя (connected user connection). В предыдущем примере имела место связь фиксированного пользователя (fixed user connection). Вот пример такой связи:
□ select * from EMPLOYEE@HR_LINK;
Управление распределенными базами данных
695
При использовании HRJLINK база данных определяет глобальное имя объекта следующим образом:
1. Находит в локальном файле tnsnames.ora нужное имя хоста, порт и нужное имя экземпляра.
2. Проверяет связь баз данных на наличие спецификации connect to. Если найдена конструкция connect to current_user, будет предпринята попытка соединиться с указанной базой данных с помощью имени и пароля подключенного пользователя.
3. Находит во фразе from запроса имя объекта.
Соединения подключенного пользователя часто используются для доступа к таблицам, строки которых могут быть ограничены по имени пользователя, обращающегося к таблице. Например, если удаленная база данных содержит таблицу с именем HR.EMPLOYEE и каждому служащему разрешено просматривать только свою собственную запись, то связь баз данных, в которой указано конкретное соединение, например
□ create public database link HR_LINK
connect to HR identified by PUFFINSTUFF using ‘hq’;
будет регистрироваться как учетная запись HR (владелец таблицы). Если используется это конкретное соединение, нельзя ограничить просмотр записей пользователем на удаленном хосте. Если же используется соединение подключаемого пользователя, а на удаленном хосте создано представление с псевдостолбцом User, то хост будет возвращать данные только этого пользователя. Пример связи баз данных и представления такого типа приведен в следующем листинге:
□ REM В локальной базе данных:
REM
create public database link HR_LINK connect to current, user
using ‘hq’;
create view REMOTE_EMP
as select * from EMPLOYEE@HR_.LINK where Ename=User;
Значением псевдостолбца User является имя текущего пользователя Oracle. При выполнении пользователем запроса к представлению REMOTE_EMP используется связь баз данных HRJLINK. Поскольку в этой связи указано соединение по умолчанию, то для соединения с базой данных, соответствующей имени службы hq, будут использованы имя и пароль этого пользователя. При этом он получит из EMPLOYEE@HR_ LINK только те записи, в которых имя пользователя совпадает со значением столбца Ename данной таблицы.
В любом случае извлекаемые данные могут быть ограничены. Если используется соединение подключаемого пользователя, то возможно ограничение по имени пользователя в удаленной базе данных; для соедине
696
Гпава 18
ния фиксированного пользователя данные можно ограничить после их передачи в локальную базу данных. Таким образом, применение соединений по умолчанию позволяет сократить объем сетевого трафика, а также добавляет еще один уровень прозрачности местонахождения данных.
Примечание Если используется опция Virtual Private Database (виртуальная приватная база данных) базы данных Oracle, можно ограничить доступ к строкам и столбцам, не поддерживая для этой цели представлений (подробнее о применении опции Virtual Private Database см. главу 10).
При использовании соединений подключенного пользователя возникает другой ряд вопросов, связанных с обслуживанием системы. На серверах необходима синхронизация файлов tnsnames.ora, а в самих базах данных должны быть синхронизированы комбинации из имени пользователя и пароля (см. ниже).
Домены базы данных
Благодаря службе имен доменов (Domain Name Sendee — DNS) можно организовать хосты в сети по иерархическому принципу. Каждый узел организации называется доменом (domain), причем каждый домен получает имя в соответствии со своей функцией. К числу этих функций может относиться СОМ для компаний или EDU для учебных заведений. У каждого домена могут быть субдомеиы. Следовательно, каждому хосту в сети будет присвоено уникальное имя, в котором содержится информация о его месте в сетевой иерархии. Как правило, имена хостов в сети состоят максимум из 4 частей, причем крайняя слева — это имя хоста, а остальные обозначают, какому домену принадлежит данный хост.
Например, хост может получить имя HQ.MYCORP.COM. Здесь имя хоста — HQ. Он идентифицируется как часть субдомена MYCORP домена СОМ.
Доменная структура важна по двум причинам. Во-первых, имя хоста является частью глобального имени объекта. Во-вторых, Oracle позволяет задавать версию DNS имени хоста в именах связей баз данных, что облегчает управление распределенными соединениями базы данных.
Чтобы можно было применять имена DNS в связях базы данных, сначала необходимо добавить два параметра к файлу инициализации для баз данных. Первый из них, DB_NAME, может уже там присутствовать; его следует задать как имя экземпляра. Второй параметр, DB__DOMAIN, задается как имя DNS хоста базы данных и указывает на сетевой домен, в котором находится данный хост. Если база данных LOC создается на сервере HQ.MYCORP.COM, соответствующая ей запись будет иметь вид:
□ DB_NAME = 1ос
DB__DOMAIN = hq.mycorp.com
Чтобы можно было использовать имя домена базы данных, необходимо в файле параметров задать параметр GLOBAL_NАМЕ как TRUE:
П GIORAI NAMES = true
Управление распределенными базами данных
697
Примечание
В Oracle 10g GLOBALJMAMES по умолчанию задано как FALSE.
После задания параметров базу данных необходимо закрыть, а затем повторно запустить с этим файлом параметров, чтобы заданные значения вступили в силу.
Примечание Если GLOBALJMAMES задано как TRUE, то все имена связей базы данных должны удовлетворять приведенным в этом разделе правилам.
При применении указанного метода создания глобальных имен базы данных эти имена оказываются такими же, как у базы данных, к которой они относятся. Следовательно, связь БД, указывающая на ранее упомянутую базу данных LOC, будет называться LOC.HQ.MYCORP.COM:
□ CREATE PUBLIC DATABASE LINK loc.hq.mycorp.com
USING ‘ имя_службы';
Oracle может добавить к имени связи БД значение DB_DOMAIN локальной базы данных. Например, если база данных находилась в домене HQ.MYCORP.COM, а имя связи — LOC, то при использовании этого имени оно будет автоматически расширено до LOC.HQ.MYCORP.COM.
Глобальные имена позволяют устанавливать связь между именем базы данных, ее доменом и именами ее связей. А это, в свою очередь, упрощает идентификацию и управление этими связями. Например, можно создать публичную связь (без строки соединения, как показано в предыдущем примере) в каждой базе данных, указывающей на все остальные БД. Теперь пользователям больше не нужно гадать, какую именно связь БД использовать: если им известно глобальное имя базы данных, то известно и имя связи баз данных. Если таблица перемещается из одной БД в другую или если база данных переносится с одного хоста на другой, легко установить, какие из старых связей должны быть удалены и восстановлены. Применение глобальных имен баз данных является составной частью перехода от автономных БД к настоящим сетям БД.
Использование разделяемых связей баз данных
Если для соединений с базами данных используется многопоточный сервер (Multithreaded Server), а приложение устанавливает много параллельных соединений, то можно воспользоваться преимуществами так называемых разделяемых связей БД (shared database links). В таких связях для поддержки соединений связей баз данных используются разделяемые серверные соединения. При наличии множества параллельных связей базы данных, обращающихся к удаленной БД, применение разделяемых связей поможет сократить число требуемых соединений с сервером.
Для создания разделяемой связи базы данных в команде create database link используется ключевое слово shared. Необходимо также указать схему и пароль для удаленной базы данных:
□ create shared database link HR_LINK_SHARED connect to current_user
authenticated by HR identified by puffinstuff using ‘hq’;
698
Глава 18
В связи баз данных HR_LINK_SHARED при доступе к базе данных "hq’ используются имя и пароль подключенного пользователя, как указано фразой connect to current_user. Использование фразы authenticated by позволяет предотвратить попытки несанкционированного использования разделяемой связи. В данном примере для аутентификации применяется учетная запись приложения, но можно использовать для аутентификации и пустую схему. Учетная запись аутентификации должна иметь системную привилегию CREATE SESSION. При попытках соединения с использованием связи HR_LINK_SHARED будет выполняться аутентификация для учетной записи связи HR.
Примечание Пользователи, имеющие доступ к таблице SYS.LINK$, видят имя пользователя аутентификации и пароль.
При изменении пароля учетной записи аутентификации потребуется удалить и заново создать каждую связь базы данных, ссылающуюся на эту запись. Для облегчения обслуживания следует создать учетную запись, используемую только для аутентификации соединений, устанавливаемых с помощью разделяемой связи баз данных. Такая учетная запись должна иметь единственную системную привилегию CREATE SESSION и не иметь привилегий для каких-либо прикладных таблиц.
Если связи БД используются в приложении относительно редко, то лучше создавать традиционные связи баз данных без ключевого слова shared. Когда это ключевое слово отсутствует, при каждом использовании связи БД будет устанавливаться отдельное соединение с удаленной базой данных.
Управление связями баз данных
Сведения об общих связях баз данных можно получить через представление словаря данных DBA_DB_LINKS. Приватные связи можно просмотреть с помощью представления USER_DB_LINKS. По возможности следует распределять пользователей по базам данных так, чтобы они могли разделять одни и те же публичные связи БД. При этом пользователи, как правило, получают возможность разделять общие привилегии и синонимы.
Столбцы представления словаря данных DBA_DB_LINKS перечислены в приведенной ниже таблице. С помощью этого представления нельзя увидеть пароль связи; он хранится в зашифрованном виде в таблице SYS.LINK$.
Имя столбца
OWNER
DBJJNK USERNAME
MOST
CREATED
Описание
Владелец связи баз данных
Имя связи баз данных (например, HRJJNK в примерах этой главы)
Имя учетной записи, используемой для открытия сеанса в удаленной базе данных (если указано конкретное соединение)
Строка соединения, которая будет использоваться для соединения с удаленной базой данных
Отметка времени, содержащая дату создания связи баз данных
Управление распределенными базами данных
699
Примечание Количество связей баз данных, которые могут быть использованы в одном запросе, ограничено параметром OPENJJNKS файла инициализации и по умолчанию равно 4.
Круг задач по администрированию связей БД зависит от уровня прозрачности местонахождения, реализованного в базах данных. Лучше всего использовать соединения подключенного пользователя вместе с именами или псевдонимами служб. При этом для успешного обслуживания требуется только согласование файлов tnsnames.ora на разных хостах и применение глобальных комбинаций из имени пользователя и пароля.
Синхронизировать комбинации “имя пользователя/пароль” сложнее, но здесь существует ряд альтернатив. Во-первых, можно в принудительном порядке проводить все изменения паролей учетных записей централизованно. Тот, кто это сделает, будет отвечать за обновление паролей во всех базах данных сети — трудоемкая задача, но она этого стоит.
Во-вторых, можно контролировать все изменения паролей пользователей путем аудита команд alter user (см. главу 4). Если пароль пользователя изменится в одной базе данных, то он изменится во всех доступных по сети базах данных, для обращения к которым используются соединения подключаемого пользователя.
Если в связь баз данных встраивается любой компонент глобального имени объекта (например, имя пользователя), то изменения, затрагивающие данный компонент, потребуют удаления и повторного создания этой связи. Если изменить пароль пользователя HR, то определенную выше связь баз данных HRJLINK с конкретным подключением придется удалить
□ drop database link HR_LINK;
а затем повторно создать, используя новую учетную запись:
□ create public database link HR_LINK connect to HR identified by НОВЫЙ JIAPOfIb using ‘hq’;
В учетной записи другого пользователя нельзя создать связь баз данных. Если попытаться создать связь в учетной записи SCOTT, как показано здесь:
□ create database link SCOTT. HR JINK connect to HR identified by PUFFINSTUFF using ‘hq’;
to ORACLE не сможет создать в учетной записи SCOTT связь HRJLINK. Вместо этого будет создана связь SCOTT.HRJLINK в учетной записи, от имени которой выполнялась команда create database link. Для создания приватных связей баз данных необходимо зарегистрироваться под именем той учетной записи, которой принадлежит связь.
(Примечание Чтобы посмотреть, какие связи используются в настоящее время в базе данных, нужно сделать запрос к V$DBUI\1K.
700
Глава 18
Управление триггерами базы данных
Если для нужд тиражирования требуется синхронизировать изменения в нескольких базах данных, то для тиражирования данных из одной таблицы в другую можно использовать триггеры базы данных. Триггеры базы данных выполняются, когда над определенными таблицами производятся определенные действия. Триггеры можно выполнять для каждой строки транзакции, для транзакции в целом или когда происходят события системного уровня. При тиражировании данных обычно приходится иметь дело с триггерами, воздействующими на каждую строку.
Перед созданием относящегося к тиражированию триггера необходимо создать связь баз данных, которую он будет использовать. Ниже приведен пример создания связи в базе данных, которой принадлежат данные, доступные владельцу тиражируемой таблицы:
□ create public database link TRIGGER__LINK connect to current__user
using ‘remotel’;
Связь, названная TRIGGER_LINK, использует имя службы (remotel) для создания соединения с удаленной базой данных. Она попытается зарегистрироваться в базе данных remotel, используя имя пользователя и пароль той учетной записи, от имени которой она вызывалась.
Показанный в следующем листинге триггер использует эту связь. Триггер срабатывает после каждого ввода строки в таблицу EMPLOYEE. Поскольку выполнение кода триггера происходит после ввода, достоверность данных в строке уже подтверждена в локальной базе данных. Триггер вводит эту строку в удаленную таблицу с такой же структурой, используя определенную выше связь баз данных TRIGGER_LINK. Удаленная таблица к этому моменту должна существовать.
□ create trigger COPY_DATA after insert on EMPLOYEE for each row begin
insert into EMPLOYEE@TRIGGER_LINK values
(:new.Empno, :new.Ename, :new.Deptno,
:new.Salary, :new.BirthDate, :new.Soc_Sec_Num); end;
Для ссылки на значения строки, только что введенной в локальную таблицу EMPLOYEE, в триггере используется ключевое слово new.
Примечание При тиражировании с помощью триггеров необходимо учитывать возможные нештатные ситуации (error conditions) на удаленном узле, например, дублирование значений ключей, проблемы с выделением места или неработающая база данных.
Управление распределенными базами данных
701
Для получения информации о триггерах используется представление словаря данных DBAJTRIGGERS. Приведенный ниже запрос выводит заголовочную информацию о триггере: его тип, вызвавший его оператор и таблицу, для которой он был вызван. В этом примере выводится заголовочная информация о только что созданном триггере COPYJDATA:
О select Trigger_Type,
Triggering_Event,
Table_Name
from DBAJTRIGGERS
where Trigger_Name = ‘COPY_DATA’;
Ниже приведен образец выходных данных этого запроса:
П TYPE TRIGGERING_EVEKT TABLE_NAME
AFTER EACH ROW INSERT EMPLOYEE
С помощью представления DBAJTRIGGERS можно получить и текст триггера:
□ set long 1000
select Trigger_Body
from DBAJTRIGGERS
where Trigger_Name = ‘COPY_DATA’;
Этот запрос выведет следующее:
□ TRIGGER-BODY
begin
insert into EMPLOYEE@TRIGGER_LINK values
(:new.Empno, :new.Ename, :new.Deptno,
:new.Salary, :new.Birth_Date, :new.Soc_Sec_Num); end;
Теоретически можно создать триггер для тиражирования всех возможных перестановок операций по манипулированию данными над локальной базой данных, но тогда управление системой резко усложнится. В сложных средах следует прибегать к материализованным представлениям или ручному копированию данных. Однако при определенных обстоятельствах, типа описанных ранее, триггеры представляют собой очень простое решение.
Примечание Если для тиражирования данных используются триггеры, то успешное завершение транзакции в основной базе данных будет зависеть от того, успешно ли завершена удаленная транзакция.
Управление материализованными представлениями
Материализованные представления (materialized views) можно использо-вагь для агрегирования (aggregate), предварительного соединения (рге-join) или тиражирования (replication) данных. В среде корпоративной
702
Глава 18
базы данных данные обычно поступают из базы данных оперативной обработки транзакций в хранилище данных. Обычно данные предварительно подкачиваются, очищаются либо обрабатываются каким-либо другим образом, а затем перемещаются в хранилище данных. Начиная с этого момента, данные можно заносить в другие базы данных или специализированные хранилища данных (витрины данных).
Материализованные представления можно использовать для предварительного вычисления и храпения в базе данных агрегированной информации, для динамического тиражирования данных между распределенными базами данных и для синхронизации обновления данных в тиражированных окружениях^ где они обеспечивают локальный доступ к данным, к которым в обычных условиях пришлось бы обращаться в удаленном режиме. Одно материализованное представление может служить основой для другого.
В больших базах данных материализованные представления помогают повысить скорость ответа на запросы, в которые входят агрегаты (включая суммирование, подсчет, вычисление среднего значения, дисперсии, максимального и минимального значений) или соединений таблиц. Оптимизатор запросов Oracle автоматически распознает, что для выполнения запроса следует использовать материализованное представление — это средство известно как перезапись запроса (query rewrite).
Примечание Для достижения наилучших результатов следует обеспечить для данного материализованного представления поддержание актуальности его статистических данных.
С помощью параметров инициализации можно сконфигурировать оптимизатор таким образом, который будет автоматически переписывать запросы, чтобы они при любой возможности использовали материализованные представления. Поскольку эти представления прозрачны для приложений SQL, их удаление или создание не окажет влияния на выполняемый код. Можно создать секционированное материализованное представление или сделать базовой для представления секционированную таблицу.
В отличие от обычных, материализованные представления содержат данные и занимают место в базе данных. Они заполняются данными, сгенерированными по базовым запросам и обновляемыми по требованию или на плановой основе. Следовательно, при каждом изменении данных, к которым обращается базовый запрос, необходимо обновление материализованного представления, чтобы оно отражало это изменение. Частота обновления данных зависит от того, какая задержка изменения данных допустима для предприятия в процессах, поддерживаемых материализованными представлениями.
Материализованное представление создает в базе данных несколько объектов. Пользователь, создающий такое представление, должен иметь привилегии CREATE MATERIALIZED VIEW, CREATE TABLE и CREATE VIEW, а также привилегию SELECT для всех таблиц, ца которые делаются ссылки в материализованном представлении, если эти таблицы принадлежат другой схеме. Если планируется создать материализованное пред
Управление распределенными базами данных
703
ставление в другой схеме, пользователь, создающий такое представление, должен иметь привилегию CREATE ANY MATERIALIZED VIEW, а также привилегию SELECT для всех таблиц, на которые делаются ссылки в материализованном представлении, если эти таблицы принадлежат другой схеме. Чтобы активизировать перезапись запроса для материализованного представления, которое ссылается на таблицы из другой схемы, пользователь, желающий активизировать перезапись запроса, должен иметь привилегию GLOBAL QUERY REWRITE или назначенную в явном виде привилегию QUERY REWRITE для любой таблицы из другой схемы, на которую есть ссылка. Необходимо также иметь привилегию UNLIMITED TABLESPACE. Материализованные представления могут создаваться в локальной базе данных и брать данные из удаленной главной базы данных или находиться на том же сервере базы данных, что и сами данные.
Если предполагается использовать средство перезаписи запроса, необходимо ввести в файл параметров инициализации следующее:
□ QUERY_REWRITE. ENABLE=TRUE
Примечание Если параметр OPTIMIZER_FEATURES_ENABLED установлен на 10.0.0 или более поздний номер версии, значением по умолчанию параметра QUERY_REWRITE_ENABLE будет TRUE.
Второй параметр, QUERY_REWRITE_INTEGRITY, устанавливает степень, до которой Oracle должна принудительно перезаписывать запросы. На самом безопасном уровне Oracle не должна использовать преобразования перезаписи запросов, которые зависят от не осуществляемых в принудительном порядке отношений. Допустимыми значениями параметра QUERYJTEWRITEJNTEGRITY являются ENFORCED (Oracle принудительно обеспечивает и гарантирует согласованность и целостность), TRUSTED (перезапись запроса поддерживается для декларированных отношений) и STALE_TOLERATED (перезапись запроса поддерживается, даже если материализованные представления являются несовместимыми с их базовыми данными). По умолчанию параметр QUERY_REWRITE_ INTEGRITY устанавливается на ENFORCED.
Решения, касающиеся материализованных представлений
Прежде чем создать материализованное представление, необходимо принять несколько решений по следующим вопросам:
и Должно ли материализованное представление заполняться данными во время создания или после этого
и Как часто следует обновлять материализованное представление
и Какой тип обновления следует выполнить
в Следует ли поддерживать журнал материализованного представления
Сразу после создания представления можно загружать в него данные с помощью параметра build immediate команды create materialized view
704
Глава 18
или создать его предварительно, но не заполнять данными до первого применения, задав параметр build deferred. Преимущество заполнения материализованного представления сразу после создания заключается в том, что данные станут доступными сразу же, как только будет сделано доступным оно само. Но если материализованное представление не будет использовано в течение некоторого времени, информация может устареть еще до начала использования представления, поскольку данные изменяются довольно быстро. Если же вы ожидаете заполнения материализованного представления, загрузка данных может осуществиться только после выполнения модуля DBMS_MVIEW.REFRESH и, прежде чем получить назад данные, пользователь должен ждать, пока представление заполнится, что приведет к снижению производительности. Если представление уже существует и требуется преобразовать его в материализованное представление, можно использовать параметр prebuilt.
Исходя из потребностей компании, необходимо определить допустимый объем устаревших данных. Можно обосновать свое решение тем, как часто происходит изменение данных в таблице, на которой базируется материализованное представление. Если управленческому персоналу не требуется информация с точностью до минуты, можно обновлять информацию раз в час или раз в день. Если чрезвычайно важно, чтобы всякий раз данные были абсолютно точными, может потребоваться быстрое обновление — через каждые пять минут круглосуточно.
Существуют четыре формы обновления: полное (complete), быстрое (fast), принудительное (force) и “никогда не обновлять” (never). При быстром обновлении для отслеживания изменений данных, произошедших со времени последнего обновления, применяются журналы материализованных представлений. В представление возвращается только измененная информация, и это происходит на плановой основе в соответствии с заданным администратором критерием обновления. Журнал материализованного представления поддерживается в той же базе данных и схеме, что и главная таблица для него. Поскольку быстрое обновление применимо только к изменениям, произошедшим со времени последнего обновления, его выполнение занимает, как правило, очень мало времени.
При полном обновлении находящиеся в материализованном представлении данные полностью замещаются каждый раз, когда производится обновление. На это может уйти довольно много времени. Обновление можно производить или после фиксации транзакции в главной таблице (refresh on commit), или только после запуска процедуры DBMS_ MVIEW.REFRESH (refresh on demand).
Если задано принудительное обновление, сначала будет оценена возможность запуска быстрого обновления. Если быстрое обновление невозможно, будет проведено полное. Если в качестве параметра обновления задано Never, материализованное представление обновляться не будет.
Если журнал материализованного представления не создан и не заполнен, можно выполнять только полное обновление.
Создание материализованного представления
Пример команды, используемой для создания такого представления, приведен в следующем листинге. В этом примере материализованному представлению присваивается имя (STORE_DEPT_SAL_MV), задаются его параметры хранения, а также интервал обновления и время, когда оно
Управление распределенными базами данных
705
будет заполнено данными. Ему предписывается проводить полное обновление (опция Complete) и не загружать данные до запуска процедуры DBMS_MVIEW.REFRESH. Активизируется перезапись запроса. Ниже дается базовый запрос представления.
□ create materialized view STORE_DEPT_SAL_MV tablespace MVIEWS build deferred refresh complete enable query rewrite as select d.DNAME, sum(SAL) as tot_sum
from DEPT d, EMP e
where d.DEPTNO = e.DEPTNO group by d.DNAME;
Примечание Запрос к материализованному представлению не может ссылаться на таблицы или представления, принадлежащие пользователю SYS.
Вот еще один пример создания материализованного представления, теперь с использованием refresh fast on commit. Когда произойдет фиксация, для поддержания быстрых обновлений необходимо будет создать журнал материализованного представления для базовой таблицы (подробнее об этом см. ниже, в разделе “Управление журналами материализованных представлений”).
□ create materialized view STORE_DEPT_SAL_MV
tablespace MYMVIEWS
parallel
build immediate
refresh fast on commit
enable query rewrite as
select d.DNAME, sum(SAL) as tot_sum
from DEPT d, EMP e
where d.DEPTNO = e.DEPTNO
group by d.DNAME;
В этом примере используется тот же базовый запрос, но материализованное представление создается с быстрым обновлением, которое производится каждый раз, когда в главной таблице фиксируется транзакция. Это материализованное представление будет заполнено данными после создания, а вставляемая информация будет загружаться параллельно. Активизирована перезапись запросов.
Примечание Опция быстрого обновления не используется, если в базовой таблице не создан журнал материализованного представления. Oracle может производить быстрое обновление объединенных таблиц в материализованных представлениях. *
706
Гпава 18
В обоих примерах материализованное представление использует для “своего” табличного пространства применяемые по умолчанию параметры хранения. Для изменения параметров хранения материализованного представления используется команда alter materialized view:
П alter materialized view STORE_DEPT_SAL_MV pctfree 5;
Двумя наиболее часто выполняемыми операциями для материализованных представлений являются запросы и быстрые обновления. У каждого из этих действий разные потребности в ресурсах и в производительности. Базовую таблицу материализованного представления можно проиндексировать, например, добавив битовый индекс, что повысит производительность запроса. Если материализованное представление использует только условия соединения, индексы для ключевых столбцов могут ускорить выполнение операций быстрого обновления. Если в представлении используются и соединения, и агрегаты, и выполняется быстрое обновление (как в предыдущем примере), индекс для него создается автоматически, если только в команде create materialized view не задано using no index.
Удаление материализованного представления производится с помощью команды drop materialized view:
□ drop materialized view S‘ORE_DEPT__SAL_MV;
Использование DBMS_MVIEV и DBMS_ADVISOR
Есть множество поставляемых пакетов, которые можно применять для управления материализованными представлениями и для их оценки, в том числе DBMS_MVIEW, DBMS_ADVISOR и DBMSJDIMENSION.
Пакет DBMS_MVIEW применяется для операций управления, например оценки, регистрации или обновления материализованного представления.
Для обновления одиночного материализованного представления следует использовать DBMS_MVIEW.REFRESH. Два главных параметра подпрограммы представляют имя подлежащего обновлению материализованного представления и используемый для обновления метод. Метод обновления кодируется следующим образом: ‘с’ для полного обновления, Т для быстрого обновления и *?’ для принудительного обновления:
□ execute DBMS_MVIEW.REFRESH(1store_dept_saljnv’, ‘c’);
Если за одно выполнение DBMS_MVIEW.REFRESH обновляется несколько материализованных представлений, нужно перечислить их имена в первом параметре, а соответствующие методы обновления — во втором:
□ execute DBMS_MVIEW.REFRESH(1mv1,mv2,mv3’,’efe’);
В этом примере материализованное представление MV2 будет обновляться с помощью быстрого обновления, а остальные — с помощью полного.
Управление распределенными базами данных
707
Таблица 18.1. Подпрограммы пакета DBMSJVIWEW
Подпрограмма______________
BEGIN_TABLE_REORGANIZATION
END_TABLE_REORGANIZATION
ESTIMATE JVIVIEW-SIZE
EXPLAIN.MVIEW
EXPLAIN_REWRITE
l_AM_A_REFRESH
PMARKER
PURGE_DIRECT_LOAD_LOG
PURGE-LOG
PURGE_MVIEW_FROM_LOG
REFRESH
REFRESH_ALL_MVIEW
REFRESH-DEPENDENT
REGISTER_MVIEW
UN REGISTER JVM EW
Описание____________________________________
Выполняет процесс сохранения данных, необходимых для обновления материализованных представлений; используется перед реорганизацией главной таблицы.
Обеспечивает надлежащее состояние материализованного представления главной таблицы и достоверность этой таблицы в конце ее реорганизации.
Оценивает размер (в строках и байтах) материализованного представления.
Объясняет, какие возможности имеются для существующего или предлагаемого материализованного представления (является ли обновление быстрым, доступна ли перезапись запроса).
Объясняет причины неудачного выполнения перезаписи запроса, а также, какие материализованные представления будут использованы, если оно будет выполнено.
Возвращается значение состояния пакета LAM-REFRESH; вызывается во время тиражирования.
Используется для слежения за изменениями в разделах; возвращает маркер раздела из RowlD.
Используется в хранилищах данных; удаляет строки из журнала прямой загрузки, когда они уже не нужны материализованному представлению.
Удаляет строки из журнала материализованного представления.
Удаляет строки из журнала материализованного представления.
Обновляет одно или несколько материализованных представлений, которые не входят в одну и ту же группу'обновления.
Обновляет все материализованные представления, которые не отражают изменений в главной таблице или главном материализованном представлении.
Обновляет все материализованные представления, созданные на основе таблиц, которые зависят от определенной главной таблицы или главного материализованного представления. В списке может находиться одна или несколько главных таблиц или главных материализованных представлений.
Делает возможным администрирование отдельного материализованного представления.
Используется для отмены регистрации материализованного представления в главном узле или в узле главного материализованного представления.
708
Глава 18
Можно использовать отдельную процедуру в модуле DBMS_MVIEW, чтобы обновить все материализованные представления, для которых запланировано автоматическое обновление. Эта процедура, называемая REFRESH_ALL, будет обновлять каждое материализованное представление по отдельности. У нее нет параметров. Пример ее выполнения приводится в следующем листинге:
□ execute DBMS_MVIEW.REFRESH_ALL
Поскольку с помощью этой процедуры все материализованные представления будут обновляться последовательно, обновление не может быть одновременным. Следовательно, сбой базы данных или сервера во время выполнения этой процедуры может привести к тому, что локальные материализованные представления не будут синхронизированы друг с другом. Если это произойдет, нужно просто перезапустить процедуру после восстановления базы данных. В качестве альтернативы можно создать группы обновления (см. ниже).
Применение SQL Access Advisor
Начиная с Oracle Database 10g, стало возможно использовать SQL Access Advisor для генерации рекомендаций по созданию и индексированию материализованных представлений. Этот инструмент может порекомендовать конкретные индексы (и типы индексов) для повышения производительности соединений и других запросов.
Кроме того, SQL Access Advisor может генерировать рекомендации по изменению материализованных представлений, так что можно сказать, что он поддерживает перезапись запросов или быстрое обновление. Можно выполнять SQL Access Advisor из среды Oracle Enterprise Manager, либо непосредственно запустив пакет DBMS_ADVISOR.
Примечание Для получения наилучших результатов от применения пакета DBMS_ADVISOR необходимо перед его запуском для генерации рекомендаций собрать статистические показатели для всех таблиц, индексов и столбцов соединения.
Для применения SQL Access Advisor из Oracle Enterprise Manager или посредством пакета DBMS_ADVISOR необходимо выполнить следующие четыре шага:
1. Создайте задание.
2. Определите рабочую нагрузку.
3. Сгенерируйте рекомендации.
4. Просмотрите эти рекомендации и реализуйте их
Задание можно создать одним из двух способов: посредством выполнения процедуры DBMS_ADVISOR.GREATESTASK или путем использования процедуры DBMS_ADVISOR.QUICK__TUNE (см. ниже).
Рабочая нагрузка состоит из одного или нескольких операторов SQL плюс статистические показатели и атрибуты, относящиеся к этим операторам. В рабочую нагрузку могут быть включены все операторы SQL-при
Управление распределенными базами данных
709
ложения. При выполнении SQL Access Advisor записи рабочей нагрузки ранжируются в соответствии с их статистическими показателями и биз-нес-значимостью. Рабочая нагрузка создается с использованием процедуры DBMS_ADVISOR.CREATE_SQLWKLD. Для связывания рабочей нагрузки с родительским заданием Advisor нужно использовать процедуру DBMS_ADVISOR.ADD_SQLWKLD_REF. Если рабочая нагрузка не предоставлена, SQL Access Advisor может генерировать и использовать гипотетическую рабочую нагрузку на основании измерений (dimensions), определенных в схеме.
Если существует задание и представлена ассоциируемая с ним рабочая нагрузка, с помощью процедуры DBMS_ADVISOR.EXECUTE_TASK можно сгенерировать рекомендации. Инструментальное средство SQL Access Advisor примет к рассмотрению рабочую нагрузку и статистические показатели и попытается сгенерировать рекомендации по настройке приложения. Для просмотра рекомендаций можно воспользоваться функцией DBMS_AD\/ISOR.GET_TASK_SCRIPT или представлениями словаря данных. Каждую рекомендацию можно просмотреть через представление USER_ADVISOR_RECOMMENDATIONS (кроме того, имеются версии “ALL” и “DBA” этого представления). Для привязки рекомендаций к конкретному оператору SQL необходимо использовать представления USER_ADVISOR_SQLA_WK_STMTS и USER_ADVISOR_ACTIONS.
При выполнении процедуры GET_TASK_SCRIPT Oracle генерирует исполняемый файл SQL, в котором будут содержаться команды, необходимые для создания, изменения или удаления рекомендуемых объектов. Перед выполнением этого файла его необходимо подвергнуть ревизии, обращая особое внимание на спецификации табличных пространств. Ниже в данной главе будет показано, как можно использовать процедуру QUICK_TUNE для упрощения процесса настройки для одной команды.
Для настройки одного оператора SQL надо использовать процедуру QUICK_TUNE из пакета DBMS-ADVISOR. У нее есть два входных параметра— имя задания и оператор SQL. При использовании QUICK_TUNE у пользователя исчезает необходимость в создании рабочей нагрузки и задания с помощью DBMS_ADVISOR.
Например, следующая процедура вызывает оценку запроса:
□ execute DBMS_ADVISOR.QUICKJUNE(DBMS-ADVISOR.SQLACCESS_ADVISOR, -‘MV-TUNE’, ‘SELECT PUBLISHERS FROM BOOKSHELF’);
Примечание У пользователя, выполняющего эту команду, должна иметься системная привилегия ADVISOR.
Сгенерированные процедурой QUICK_TUNE рекомендации можно просмотреть через представление USER_ADVISOR_ACTIONS, но их проще прочесть, если воспользоваться процедурами пакета DBMS_ADVISOR Для генерации файла сценария. Рекомендация заключается в том, что для поддержки запроса необходимо создать материализованное представление. Поскольку был предложен только один оператор SQL, эта рекомендация дается в изоляции и не согласуется с прочими аспектами базы данных или приложения.
710
Гпава 18
Для автоматизации создания файла, который содержит сценарии, необходимые для реализации сделанных рекомендаций, можно использовать процедуру CREATE_FILE. Сначала нужно создать объект каталога для хранения файла:
□ create directory scripts as ‘e:\scripts’;
grant read on directory scripts to public;
grant write on directory scripts to public;
Затем следует выполнить процедуру CREATE_FILE. У нее имеется три входные переменные — сценарий (сгенерирован с помощью GET_TASK_ SCRIPT, в которую было передано имя задания), выходной каталог и имя файла, который необходимо создать:
□ execute DBMS^ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT(‘MV_TUNE’), -‘SCRIPTS’, ‘MV_TUNE.sql’);
Созданный процедурой CREATEJFILE файл MV_TUNE.sql будет содержать команды, похожие на показанные в следующем листинге. Могут встречаться некоторые отличия, связанные с разницей в эксплуатируемых версиях Oracle.
□ Rem Username: PRACTICE
Rem Task: MV_TUNE
Rem
set feedback 1
* set linesize 80 set trimspool on set tab off set pagesize 60
whenever sqlerror CONTINUE
CREATE MATERIALIZED VIEW “PRACTICE”.”MV$$_021F000T'
REFRESH FORCE WITH ROWID
ENABLE QUERY REWRITE
AS SELECT PRACTICE.BOOKSHELF.ROWID C1, “PRACTICE”."BOOKSHELF"."PUBLISHER" M1 FROM PRACTICE.BOOKSHELF; begin
dbms_stats.gather_table_stats(“PRACTICE”, ‘"MV$$_021F0001"’,NULL,dbms_stats.auto_sample_size); end;
whenever sqlerror EXIT SQL.SQLCODE
begin
dbms_advisor.mark_recommendation(1MV_TUNE’,1> ’IMPLEMENTED’); end;
Управление распределенными базами данных
711
Процедура MARK_RECOMMENDATION позволяет “закомментари-вать” рекомендации (т. е. ставить перед ними знак примечания, Rem. — Прим, пер.), чтобы они могли быть пропущены при последующих генерациях сценария. Допустимыми значениями параметра MARKRECOMMENDATION являются ACCEPT, IGNORE, IMPLEMENTED и REJECT.
Процедуру TUNE_MVIEW из пакета DBMS_ADVISOR можно использовать для генерации рекомендаций по реконфигурации настраиваемых материализованных представлений. Она генерирует два набора выходных данных — для создания нового материализованного представления и для удаления ранее созданных материализованных представлений. Конечным результатом должен стать набор материализованных представлений; их можно подвергнуть быстрому обновлению, взамен материализованных представлений, которые было нельзя обновлять быстро.
Выходные данные TUNE_VIEW можно просмотреть через представление словаря данных USER_TUNE_MVIEW, либо можно сгенерировать ее сценарии посредством процедур GET_TASK_SCRIPT и CREATEJFILE, показанных в предыдущих листингах.
Таблица 18.2. Подпрограммы пакета DBMSJIDVISOR
Подпрограмма
Описание
ADD_SQLWKLD_REF
ADD_SQLWKLD_STATEMENT
CALCELJASK
CREATE_FILE
CREATE_OBJECT
CREATE-SQLWKLD
CREATE-TASK
DELETE-SQLWKLD
DELETE_SQLWKLD_REF
DELETE_SQLWKLS_STATEMENT
DEI_ETE_TASK
EXECUTE-TASK GEOEC-ATTRIBUTES
GET-TASK-SCRIPT
Добавляет к заданию Advisor ссылку на рабочую нагрузку.
Добавляет к рабочей нагрузке один оператор.
Отменяет выполняющуюся в настоящее время операцию задания.
Создает внешний файл на основе переменной PL/SQL типа CLOB.
Создает новый объект задания.
Создает новый объект рабочей нагрузки.
Создает в репозитории новую задачу Advisor.
Удаляет весь объект рабочей нагрузки.
Удаляет весь объект рабочей нагрузки.
Удаляет из рабочей нагрузки один или несколько операторов.
Удаляет из репозитория указанную задачу.
Выполняет указанную задачу.
Выбирает атрибуты конкретной рекомендации из задания.
Создает и возвращает выполняемый файл SQL с рекомендациями Advisor.
712
Глава 18
Таблица 18.2 (Продолжение)
Подпрограмма Описание
IMPORT_SQLWKLD_SCHEMA Импортирует данные в рабочую нагрузку из кэша текущего оператора SQL.
IMPORT-SQLWKLD_SQLCACHE Импортирует данные в рабочую нагрузку из кэша текущего оператора SQL.
IMPORT_SQLWKLD_STS Импортирует данные в рабочую нагрузку из SQL Tuning Set (набора настройки SQL).
IMPORT_SQLWKLD_SUMADV Импортирует данные в рабочую нагрузку из кэша текущего оператора SQL.
IMPORT_SQLWKLD_USER Импортирует данные в рабочую нагрузку из кэша текущего оператора SQL.
INTERRUPTTASK Останавливает выполняющуюся в настоящее время задачу, закончив все ее операции, как это было бы сделано в случае обычного выхода из задачи.
MARK_RECOMMENDATION Устанавливает статус комментария для конкретной рекомендации.
QUICK_TUNE Выполняет анализ одного оператора SQL.
RESET.TASK Восстанавливает задачу в ее начальном состоянии.
SET_DEFAULT_SQLWKLD_ PARAMETER Импортирует данные в рабочую нагрузку из доказательства схемы (schema evidence).
SET_DEFAULT_TA5K_RARAMETER Модифицирует используемый по умолчанию параметр задания.
SET-SQLWKLD-PARAMETER Устанавливает значение параметра рабочей нагрузки.
SET_TASK_PARAMENER Устанавливает значение указанного параметра задачи.
TUNE.MVIEW Показывает, как разложить материализованное представление на два или несколько материализованных представлений или по-другому сформулировать материализованное представление, чтобы оно стало более подходящим для быстрого обновления и перезаписи запросов.
UPDATE_OBJECT Обновляет объект задания.
UPDATE_REC_ATTRIBUTES Обновляет существующие рекомендации для специфицированного задания.
UPDATE-SQLWKLD-ATTRIBUTES Обновляет объект рабочей нагрузки.
UPDATE_SQLWKLD_STATEMENT Обновляет один или несколько операторов SQL в рабочей нагрузке.
UPDATE TASK ATTRIBUTES Обновляет атрибуты задания.
Управление распределенными базами данных
713
Дополнительный пакет — DBMSJDIMENSION — содержит две процедуры:
DESCRIBE—DIMENSION
VALIDATE.DIMENSION
Показывает определение входных измерений, в том числе, владельца, имя, уровни, иерархии и атрибуты.
Проверяет, являются ли правильными отношения, специфицированные в измерении.
Пакет DBMSJDIMENSION можно использовать для подтверждения и отображения структуры измерений.
Принудительное установление ограничений ссылочной целостности между материализованными представлениями
Ссылочная целостность между двумя связанными таблицами, имеющими простые материализованные представления, для которых они служат базовыми, может не быть установлена принудительно в их материализованных представлениях. Если таблицы обновляются в разное время или во время обновления в главной таблице происходят транзакции, допускается, чтобы материализованные представления этих таблиц не отражали ссылочную целостность данных в главных таблицах.
Если, например, EMPLOYEE и DEPT связаны друг с другом через связь “первичный ключ/внешний ключ”, то в простом материализованном представлении эти связи могут быть нарушены, включая внешние ключи без совпадающих с ними первичных ключей. В данном примере это может означать, что в материализованном представлении EMPLOYEE могут быть сотрудники со значениями DEPTNO, которые не существуют в материализованном представлении DEPT.
Есть несколько возможных решений этой проблемы. Во-первых, нужно согласовать обновления по времени, чтобы они происходили, когда главные таблицы не используются. Во-вторых, следует производить обновления вручную (подробнее см. ниже), сразу же после блокировки главных таблиц или “замораживания” базы данных. В-третьих, можно объединить таблицы в материализованном представлении, создав сложное материализованное представление, которое будет основываться на главных таблицах (связанных друг с другом надлежащим образом). В-четвертых, можно форсировать выполнение обновлений материализованных представлений исключительно после фиксации транзакции в основной базе данных.
Еще одним решением проблемы ссылочной целостности является использование групп обновлений (refresh groups). Связанные материализованные представления можно собрать в так называемые группы обновлений. Целью этих групп является координация графика обновлений их членов. Для включения в такие группы подходят материализованные представления, у которых главные таблицы имеют связи с другими таблицами. Координация графика обновлений представлений будет также поддерживать ссылочную целостность данных главных таблиц. Если группы ооновлений не используются, данные материализованных представлении могут оказаться несогласованными по отношению к ссылочной цело-с I пости главных таблиц.
714
Гпава 18
Манипулирование группами обновления производится с помощью пакета DBMS_REFRESH. В этот пакет входят процедуры MAKE, ADD, SUBTRACT, CHANGE, DESTROY и REFRESH (см. следующие примеры). Информацию о существующих группах обновления можно запросить из представлений словаря данных USER_REFRESH и USER__REFRESH_ CHILDREN.
Примечание Материализованные представления, входящие в группу обновления, не обязательно должны принадлежать одной и той же схеме, но их надо хранить в одной и той же базе данных.
Группа обновления создается с помощью процедуры МАКЕ из пакета DBMS_REFRESH, структура которой представлена в следующем листинге:
□ DBMS_REFRESH.МАКЕ (name IN VARCHAR2, list IN VARCHAR2, | tab in DBMS_UTILITY.UNCL.ARRAY, next_date IN DATE, interval IN VARCHAR2, implicit-destroy IN BOOLEAN := FALSE, lax IN BOOLEAN := FALSE, job IN BINARY INTEGER := 0, rollback_seg IN VARCHAR2 : = NULL, push_deferred_rpc IN BOOLEAN := TRUE, refresh„after_errors IN BOOLEAN := FALSE, purge.option IN BINARY-INTEGER : = NULL, parallelism IN BINARY-INTEGER : = NULL, heap_size IN BINARY-INTEGER : = NULL);
Кроме первых четырех, все параметры для этой процедуры имеют значения по умолчанию, которые обычно и принимаются. Параметры list и tab являются взаимоисключающими. Чтобы создать группу обновления для материализованных представлений с именами LOCAL_EMP и LOCAL-DEPT, можно использовать следующую команду:
□ execute DBMS,REFRESH.MAKE (name => ’emp. group’, -list => 1local_emp, local_dept’, -next-date => SysDate, -interval => 'SysDate+7’);
Примечание В этом примере параметр list (второй в листинге) имеет одинарные кавычки только в начале и в конце. Два материализованных представления — LOCAL-EMP и LOCAL_DEPT — передаются в процедуру через один параметр.
Предшествующая команда создаст группу обновления ЕМР_GROUP с двумя материализованными представлениями в качестве членов. Имя
Управление распределенными базами данных
715
группы обновления заключается в одинарные кавычки как список членов, а не отдельный член.
Если в группе обновления должно содержаться материализованное представление, которое уже является членом другой группы обновления (например, во время перемещения представления из старой группы во вновь создаваемую), необходимо задать параметр lax как TRUE. В каждый момент времени материализованное представление может принадлежать только одной группе обновления.
Чтобы добавить к существующей группе обновления материализованное представление, следует использовать процедуру ADD из пакета DBMS_REFRESH, которая имеет следующую структуру:
П DBMS_REFRESH.ADD
(name IN VARCHAR2,
list IN VARCHAR2, |
tab IN DBMS-UTILITY.UNCL_ARRAY, lax IN BOOLEAN : = FALSE);
Как и в случае процедуры МАКЕ, задание параметра lax процедуры ADD не обязательно, если только материализованное представление по перемещается между двумя группами обновления. Если эта процедура выполняется с параметром lax, заданным как TRUE, материализованное представление перемещается в новую группу обновления и автоматически удаляется из старой.
Для удаления материализованного представления из существующей группы обновления следует использовать процедуру SUBTRACT из пакета DBMS_REFRESH:
□ DBMS. REFRESH.SUBTRACT
(name IN VARCHAR2, list IN VARCHAR2, |
tab IN DBMS-UTILITY.UNCL_ARRAY, lax IN BOOLEAN := FALSE);
Как и в процедурах МАКЕ и ADD, одно материализованное представление или список представлений (разделенных запятыми) может служить входной информацией для процедуры SUBTRACT. График обновления для группы изменяется с помощью процедуры CHAJMGE из пакета DBMS_REFRESH:
П DBMS_REFRESH.CHANGE (name IN VARCHAR2, next_date IN DATE : = NULL, interval IN VARCHAR2 := NULL, implicit, destroy IN BOOLEAN : = NULL, rollback_seg IN VARCHAR2 : = NULL, push_deferred._rpc IN BOOLEAN : = NULL, refresh_after errors IN BOOLEAN .= NULL, Purge_option IN BINARY.INTEGER : = NULL, parallelism IN BINARY INTEGER : = NULL, heap_size IN BINARY-INTEGER := NULL)
716
Глава 18
Параметр next_date аналогичен фразе start with команды create materialized view, а параметр interval аналогичен фразе next. Например, чтобы изменить график и тиражировать EMP_GROUP каждые три дня, следует выполнить приведенную ниже команду (которая задает значение NULL для параметра nextdate, тем самым, оставляя его неизменным):
□ execute DBMS_REFRESH.CHANGE (name => ‘emp_group’, next_date => null, interval => ‘SysDate+3’);
После выполнения этой команды цикл обновления для группы обновления EMP_GROUP изменится, и обновление будет выполняться каждые три дня.
Примечание Операции обновления для групп обновления могут занять больше времени, чем обновление соответствующих материализованных представлений. Кроме того, при групповом обновлении может потребоваться довольно много места для сегментов отката, чтобы обеспечить согласованность во время обновления.
Процедура REFRESH из пакета DBMS_REFRESH позволяет выполнять групповое обновление вручную. Единственным входным параметром этой процедуры является имя группы обновления. С помощью приведенной ниже команды происходит обновление группы EMP_GROUP:
□ execute DMBMS_REFRESH.REFRESH(‘emp_group’);
Как показано в следующем примере, процедура DESTROY из пакета DBMS_REFRESH позволяет удалить группу обновления. Единственным параметром этой процедуры является имя группы обновления.
□ execute DBMS_REFRESH.DESTROY(name => ‘emp_group’);
Удаление группы обновления можно также выполнить в неявном виде. Если при создании группы с помощью процедуры МАКЕ параметр implicit__destroy задан как TRUE, группа обновления будет удалена (destroyed) после того, как ее последний член будет удален из группы (как правило, с помощью процедуры SUBTRACT).
Примечание Для получения статистических данных о производительности, относящихся к материализованному представлению, нужно сделать запрос к V$MVREFRESH.
Управление журналами материализованных представлений
Журнал материализованного представления — это таблица, которая содержит записи о модификациях главной таблицы материализованного представления. Она хранится в той же базе данных, что и главная таблица, и используется только простыми материализованными представлениями. Данные журнала материализованных представлений применяются во время быстрых обновлений. Если планируется проводить быстрые об-
Управление распределенными базами данных
717
новления, перед созданием материализованного представления нужно создать журнал материализованного представления.
Для создания журнала материализованного представления необходимо создать для этой таблицы триггер AFTER ROW, поэтому потребуются привилегии CREATE TRIGGER и CREATE TABLE. Имя журнала материализованного представления задать нельзя.
Поскольку этот журнал является таблицей, он имеет полный набор параметров хранения таблицы. В следующем листинге показано создание журнала материализованных представлений для таблицы EMPLOYEE:
□ create materialized view log on EMPLOYEE
tablespace DATA_2;
Значение pctfree, задаваемое для журнала материализованного представления, может быть сделано очень маленьким, а значение pctused должно быть очень большим. Нужно указать значения для этих параметров или выбрать такое табличное пространство, параметры хранения для которого отражают эти потребности. Размер журнала материализованного представления зависит от числа изменений, которые будут обрабатываться во время каждого обновления. Чем чаще обновляются все материализованные представления, ссылающиеся на главную таблицу, тем меньше места занимает журнал.
Параметры хранения для журнала модифицируются с помощью команды alter materialized view log. С помощью этой команды нужно задать имя главной таблицы. В следующем примере показано изменения журнала материализованного представления для таблицы EMPLOYEE:
□ alter materialized view log EMPLOYEE pctfree 10;
Команда drop materialized view log позволяет удалить журнал материализованного представления:
□ drop materialized view log on EMPLOYEE;
Эта команда удалит журнал и связанные с ним объекты из базы данных.
Очистка журнала материализованных представлений
Журнал материализованных представлений содержит переменную (динамическую) информацию; записи вставляются в журнал, используются во время обновлений, а затем удаляются. Рекомендуется при создании журнала задать большое значение для pctused, поскольку это будет способствовать многократному использованию блоков в журнале.
Если несколько материализованных представлений используют одну и ту же главную таблицу, они также разделяют и журнал материализованных представлений. Если одно из представлений давно не обновлялось, может получиться так, что из журнала не будет удалена ни одна запись, относящаяся к этому представлению. В результате данному материализованному представлению потребуется больше места.
Процедура PURGE_LOG из пакета DBMSJMVIEW позволяет сократи! ь пространство, занимаемое записями журнала. Эта процедура имеет
718
Глава 18
три входных параметра: имя главной таблицы, переменную num и флажок DELETE. Переменная num указывает число материализованных представлений с наиболее давними обновлениями, строки которых будут удалены из журнала. Например, если есть три материализованных представления, использующих журнал, и одно из них уже очень давно не обновлялось, для num нужно использовать значение 1.
В следующем листинге приводится пример работы процедуры PURGE_LOG. Журнал материализованных представлений таблицы EMPLOYEE будет очищен от записей, имеющихся в представлении с наиболее давним обновлением:
□ execute DBMS_MVIEW.PURGE.LOG
(master => ‘EMPLOYEE’,
num => 1,
flag => ‘DELETE’);
Для дальнейшей поддержки усилий по обслуживанию Oracle предоставляет команде truncate два параметра, связанных с материализованными представлениями. Если требуется усечь главную таблицу, не утрачивая при этом элементы журнала материализованных представлений, следует ввести такую команду:
□ truncate table EMPLOYEE preserve materialized view log;
Если материализованное представление таблицы EMPLOYEE базируется на значениях первичного ключа (по умолчанию), значения журнала материализованных представлений будут все еще действительны после экспорта/импорта таблицы EMPLOYEE. Тем не менее, если таблицы EMPLOYEE материализованного представления базируются на значениях RowID, журнал материализованного представления становится недействительным после операций экспорта/импорта базовой таблицы (поскольку во время импорта могут назначаться разные RowIDs). В таком случае при усечении базовой таблицы следует усечь и журнал:
□ truncate table EMPLOYEE purge materialized view log;
Какого рода обновления могут быть выполнены?
Чтобы увидеть, какого рода возможности обновления и перезаписи доступны для материализованных представлений, можно задать запрос к таблице MV_CAPABILITIES_TABLE. Эти возможности могут изменяться от версии к версии, так что необходимо проводить переоценку таких возможностей после каждого обновления программного обеспечения Oracle. Для создания этой таблицы следует выполнить сценарий utlxmv.sql, размещенный в каталоге /rdbms/admin в домашнем каталоге программного обеспечения Oracle.
Ниже показаны столбцы таблицы MV-CAPABILI1TES_TABLE:
□ desc MV-CAPABILITIES TABLE
Name
Null?
Type
STATEMENT ID MVOWNER
VARCHAR2(3O)
VARCHAR2(30)
Управление распределенными базами данных
719
MVNAME CAPABILITY-NAME POSSIBLE RELATED-TEXT RELATED NUM MSGNO
MSGTEXT SEO
VARCHAR2(30) VARCHAR2(30) CHAR(1)
VARCHAR2(2000) NUMBER NUMBER(38) VARCHAR2(2000) NUMBER
Для заполнения таблицы MV_CAPABILITIES_TABLE нужно выполнить процедуру DBMS_MVIEW.EXPLAIN_MVIEW, используя в качестве входного параметра имя материализованного представления:
□ execute DBMS_MVIEW.EXPLAIN_MVIEW(‘local_category_count');
Сценарий utlxmv.sql предлагает помощь в интерпретации значений столбцов, как показано в следующем листинге:
□ CREATE TABLE MV_CAPABILITIES_TABLE
(STATEMEN'_ID VARCHAR2(30), -- Задаваемый клиентом уникальный идентификатор MVOWNER VARCHAR2(30), — NULL для EXPLAIN MVIEW на базе SELECT
MVNAME VARCHAR2(30), — NULL для EXPLAIN_MVIEW на базе SELECT
CAPABILITY-NAME VARCHAR2(30), -- Описательное имя для конкретной возможности:
- REWRITE
Может делать, по крайней мере, перезапись полных текстовых совпадений - REWRITE_PARTIAL_TEXT_MATCH
Может делать, по крайней мере, перезапись полных и частичных текстовых совпадений - REWRITE GENERAL
Может делать все формы перезаписи - REFRESH
Может делать, по крайней мере, полное обновление
- REFRESH_FROM_LOG_AFTER_INSERT
Может делать быстрое обновление по журналу МП или изменять таблицы сбора данных, по крайней мере, в тех случаях, когда операции обновления ограничены до INSERT - REFRESH_FROM_LOG_AFTER_ANY
Может делать быстрое обновление по журналу МП или изменять таблицы сбора данных после любой комбинации обновлений
- РСТ
Может делать расширенное отслеживание обновлений (Enhanced Update Tracking -- EU ) для таблицы, чье имя указано в столбце RELATED_NAME. EUT необходимо для быстрого обновления после операций обслуживания разделов для таблицы, чье имя указано в столбце RELATED-NAME, и для проведения не устаревших допустимых перезаписей, когда МП является частично устаревшим по отношению к“таблице.чье имя указано в столбце RELATED_NAME. EUT может также
720
Глава 18
POSSIBLE related_text
RELATED_NUM
MSGNO
MSGTEXT
SEO
CHARACTER(I),
VARCHAR2(2000),
NUMBER,
INTEGER,
VARCHAR2(2000), NUMBER,
иногда разрешать быстрое обновление МП для изменений таблицы, чье имя указано в столбце RELATED_NAME, в том случае, если невозможно быстрое обновление по журналу МП или по таблице сбора данных.
- - Т = характеристика возможна
- - F = характеристика невозможна
- - владелец.таблица.столбец, имя псевдонима
- - и прочее, имеющее отношение к сообщению.
- - Конкретный смысл этого столбца зависит от
- - столбца MSGNO. Подробности см. в документации
— по DBMS_MVIEW.EXPLAIN_MVIEW()
- - Когда имеется связанное со строкой
- - числовое значение, оно находится здесь.
- - Конкретный смысл этого столбца зависит от
- - столбца MSGNO Подробности см. в документации
- - по DBMS_MVIEW.EXPLAIN_MVIEW()
- - Если присутствует, является номером сообщения
- - QSM, объясняющим причины невозможности
- - или дополнительные детали, если активировано.
- - Текст, связанный с MSGNO.
- - Полезно во фразе ORDER BY
- - при выборке из этой таблицы.
После того как процедура EXPLAIN JMTVIEW будет выполнена, можно сделать запрос к таблице MV_CAPABILITIES_TABLE, чтобы определить, что именно было выбрано:
□ select Capability_Name, Msgtxt from MV-CAPABILITIES_TABLE where MSGTXT is not null;
Для материализованного представления LOCAL_BOOKSHELF запрос возвратит следующее:
□ CAPABILITY-NAME
MSGTXT
PCT_TABLE
relation is not a partitioned table
(отношение не является секционированной таблицей)
REFRESH_FAST_AFTER_INSERT
the detail table does not have a materialized view log
(таблица деталей не имеет журнала МП)
REFRESH_FAST _AFTER_ONETAB_DML
see the reason why REFRESH_FAST_AFTER_INSERT is disabled
(узнайте, по какой причине заблокирована REFRESH_FAST_AFTER_INSERT)
REFRESH_FAST AFTER_ANY_DML
see the reason why REFRESH.FAST AFTER__ONETAB_DML is disabled (узнайте, по какой причине заблокирована REFRESH_FASr_AFTER_ON TAB_DML)
Управление распределенными базами данных
721
REFRESH_FAST_PCT
PCT is not possible on any of detail table in the materialized view (невозможно PCT для любой таблицы деталей МП)
REWRITE_FULL_TEXT_MATCH
query rewrite is disabled on the materialized view
(для материализованного представления отключена перезапись запросов)
REWRITE_PARTIAL_TEXT_MATCH
query rewrite is disabled on the materialized view
(для материализованного представления отключена перезапись запросов)
REWRITE_GENERAL
query rewrite is disabled on the materialized view
(для материализованного представления отключена перезапись запросов)
REWRITE_PCT
general rewrite is not possible or PCT is not possible on any of the detail tables
(общая перезапись запросов невозможна или невозможно РСТ для любой таблицы деталей)
PCT_TABLE_REWRITE
relation is not a partitioned table
(отношение не является секционированной таблицей)
10 rows selected.
Так как при создании материализованного представления для него не была специфицирована фраза query rewrite, для LOCAL_BOOKSHELF оказываются отключенными характеристики перезаписи запроса. Характеристики быстрого обновления не поддерживаются, потому что для базовой таблицы отсутствует журнал материализованного представления. Если изменить материализованное представление или его базовую таблицу, будет необходимо регенерировать данные в таблице MV_ CAPABILITIES_TABLE, чтобы ознакомиться с новыми возможностями.
Как было показано в предыдущем листинге, материализованное представление LOCAL_BOOKSHELF не может использовать быстрое обновление, поскольку для его базовой таблицы не создан журнал материализованного представления. Ниже приводится несколько других ограничений, лимитирующих возможность использования быстрого обновления:
И Материализованное представление не должно содержать ссылок на неповторяющиеся выражения типа SysDate и RowNum.
Материализованное представление не должно содержать ссылок на типы данных RAW и LONG RAW.
в Для материализованных представлений, базирующихся на соединениях, Rowid из всех таблиц в списке from должны быть частью списка select.
722
Глава 18
Если имеются внешние соединения, то соединения должны быть связаны друг с другом операторами and, во фразе where не должно содержаться отбора данных, а ограничение по уникальности должны существовать для столбцов соединений во внутренней таблице соединения.
и Для материализованных представлений, основанных на агрегатах, журналы материализованных представлений должны содержать все столбцы таблиц, па которые делаются ссылки, в них должны быть специфицированы фразы rowid, including new values и sequence.
Сведения о дополнительных ограничениях, связанных с быстрыми обновлениями сложных агрегатов можно найти в документе Data Warehousing Guide (“Руководство по организации хранилищ данных”).
Примечание В команде create materialized view можно специфицировать фразу order by. Эта фраза будет оказывать влияние только на первоначальное создание материального представления; она не окажет влияния ни на какие обновления.
Применение материализованных представлений для изменения путей выполнения запросов
Для больших баз данных материализованное представление предлагает несколько преимуществ, связанных с производительностью. Можно использовать материализованное представление для оказания влияния на оптимизатор с целью изменения пути выполнения запросов. Эта опция, получившая название перезаписи запросов (query rewrite), позволяет оптимизатору Oracle использовать материализованные представления вместо таблиц, к которым обращаются материализованные представления, даже когда материализованные представления в запросе вообще не упоминаются. Например, для большой таблицы SALES можно создать материализованное представление, суммирующее данные таблицы SALES по регионам. Если пользователь сделает запрос к таблице SALES, в котором будет требоваться получить сумму данных из этой таблицы для какого-то региона, Oracle переориентирует этот запрос, чтобы в нем использовалось материализованное представление, а не таблица SALES. В результате сокращается число операций доступа к самым большим таблицам, что приводит к повышению производительности системы. Более того, поскольку данные в материализованном представлении уже сгруппированы по регионам, при выполнении запроса не требуется затрачивать время на суммирование данных.
Примечание Чтобы использовать материализованное представление как часть операции перезаписи запроса, необходимо в его определении специфицировать фразу enable query rewrite.
Для эффскхивного использования возможностей переписывания запроса необходимо создать измерение (dimension), определяющее иерар-TrntrrxT.TY 'гя^пипы. Для выполнения команды create dimension нужно
Управление распределенными базами данных
723
иметь системную привилегию CREATE DIMENSION. Страны являются частью континентов, так что можно создать таблицы и измерения, поддерживающие эту иерархию:
□ create dimension GEOGRAPHY
level COUNTRY_ID is COUNTRY.Country
level CONTINENT_id is CONTINENT.Continent
hierarchy COUNTRY_ROLLUP (
COUNTRY_ID child of
CONTINENT-ID
join key COUNTRY.Continent references CONTINENT_id);
Чтобы разрешить использование материализованного представления для перезаписи запросов, необходимо поместить все главные таблицы материализованного представления в схему материализованного представления, а пользователю предоставить системную привилегию QUERY REWRITE. Если само представление и образующие его таблицы содержатся в разных схемах, пользователю потребуется системная привилегия GLOBAL QUERY REWRITE. Вообще говоря, следует создавать материализованные представления в той же схеме, что и таблицы, на которых оно базируется; в противном случае придется управлять привилегиями и полномочиями, требующимися для создания и обслуживания материализованных представлений.
Примечание С помощью подсказок REWRITE и NOREWRITE можно активировать или отключить перезапись запроса на уровне оператора SQL. При использовании подсказки REWRITE можно указать список материализованных представлений, которые могут быть рассмотрены оптимизатором.
Примечание Решения о перезаписи запроса основываются на стоимости различных планов выполнения, так что необходимо поддерживать актуальность статистических данных.
Для того чтобы стала возможной перезапись запроса, необходимо задать следующие параметры инициализации:
OPTIMIZER-MODE = ALL_ROWS или FIRST ROWS
и QUERY_REWRITE_ENABLED = TRUE
QUERY_REWRITE_INTEGRITY = STALE.TOLERATED, TRUSTED или ENFORCED
По умолчанию параметр QUERY_REWRITE_INTEGRITY устанавливается на ENFORCED; в этом режиме должны выполняться все ограничения. Оптимизатор использует только новые данные из материализованного представления и использует только отношения, базирующиеся на ENABLED VALIDATED ограничений первичных, по уникальности или внешних ключей. В режиме TRUSTED оптимизатор считает, что данные В31агеРИализова1шь1х представлениях являются новыми, а отношения, объявленные в измерениях и ограничениях, — правильными. В режиме
724
Глава 18
STALE_TOLERATED оптимизатор использует материализованные представления, которые являются допустимыми, но при этом содержат устаревшие данные вперемешку со “свежими” (т. е. обновленными).
Если параметр QUERY_REWRITE_ENABLED установлен на FORCE, оптимизатор будет использовать перезаписанный запрос даже в том случае, если оценочная стоимость выполнения исходного запроса будет ниже.
Если происходит перезапись запроса, в плане выполнения (explain plan) запроса будет записано материализованное представление как один из объектов, к которым производится обращение, а в качестве операции будет записано “MAT__VIEW REWRITE ACCESS”. Можно использовать процедуру DBMS_MVIEW.EXPLAIN_REWRITE, чтобы увидеть, возможна ли перезапись для запроса и какое материализованное представление должно быть для этого использовано. Если запрос не может быть перезаписан, процедура должна документировать причины, по которым это невозможно сделать.
Процедура EXPLAIN JTEWRITE принимает три входных параметра — запрос, имя материализованного представления и идентификатор оператора — и может записать выходные результаты в таблицу. В файле utlxrw.sql, который размещается в подкаталоге /rdbms/admin домашнего каталога программного обеспечения Oracle, предлагается команда create table для создания выходной таблицы. Этот сценарий создает таблицу с именем REWRITE_TABLE.
Можно задать запрос к этой таблице и получить сведения о стоимости первоначального и перезаписанного запросов и о решении, принятом оптимизатором.
Если для команд create materialized view или alter materialized view используется опция build deferred, возможность перезаписи запроса не будет активирована вплоть до первого обновления материализованного представления.
Примечание Если в запросе используются переменные связывания (bind variables), оптимизатор не будет перезаписывать его даже в том случае, если опция перезаписи запроса активирована.
Более подробно ознакомиться с деталями и ограничениями, связанными с перезаписью запросов, можно в документе Data Warehousing Guide (“Руководство по организации хранилищ данных”).
Управление распределенными транзакциями
В одну логическую единицу работы могут входить транзакции над многими базами данных. Например, команда commit может быть выполнена после обновления двух таблиц в разных базах данных. Oracle прозрачным образом поддерживает целостность в обеих базах данных, обеспечивая фиксацию или откат всех транзакций как группы. Это выполняется автоматически, с помощью механизма двухфазной фиксации транзакций (twn-nhase commit — 2РС).
Управление распределенными базами данных
725
Первая фаза 2РС называется фазой подготовки. В этой фазе каждый узел, вовлеченный в транзакцию, готовит данные, для которых потребуется выполнить команду commit или откатить данные. По завершении подготовки узел переходит в так называемое “сомнительное” (in doubt) состояние. О своем состоянии узлы уведомляют инициирующий узел транзакции, называемый также глобальным координатором (global coordinator).
Когда все узлы готовы, транзакция входит в фазу фиксации и всем узлам предписывается зафиксировать (commit) свою часть логической транзакции. Все базы данных выполняют commit в одно и то же логическое время, сохраняя тем самым целостность распределенных данных.
Разрешение сомнительных транзакций
Транзакции над автономными базами данных могут закончиться неудачей из-за проблем с сервером базы данных, например из-за сбоя носителя. При работе с распределенными базами данных количество потенциальных причин для отказа возрастает из-за возникновения множества связанных транзакций.
Когда распределенная транзакция находится в “подвешенном” состоянии, в представлении словаря данных DBA_2PC_PENDING можно увидеть запись, соответствующую этой транзакции. После завершения транзакции эта запись удаляется. Если транзакция “подвешена”, но не может завершиться, запись о ней остается в DBA_2PC_PENDING.
Фоновый процесс RECO (от Recoverer — восстановитель) периодически проверяет представление DBA_2PC_PENDING на наличие распределенных транзакций, которые не смогли завершиться. Используя эту информацию, процесс RECO в узле сначала попытается восстановить логическую часть сомнительной транзакции, а затем установить соединения с другими базами данных, вовлеченными в транзакцию, и разрешить распределенные части транзакции. После этого соответствующие строки удаляются из представлений DBA_2PC_PENDING каждой базы данных.
Примечание Можно активировать и отключать процесс RECO с помощью фраз enable distributed recovery и disable distributed recovery команды alter system.
Восстановление распределенных транзакций автоматически выполняется процессом RECO. Локальные части распределенной транзакции можно восстановить и вручную, но обычно это приводит к несогласованности между распределенными базами данных. Если выполняется локальное восстановление, синхронизация с удаленными данными будет нарушена.
Для того чтобы минимизировать количество необходимых операций распределенного восстановления, можно изменить способ обработки распределенных транзакций. Для этого используется так называемый приоритет точки фиксации (commit point strength), сообщающий базе данных о том, как структурировать транзакцию.
726
Глава 18
Приоритет точки фиксации
Каждая группа распределенных транзакций неизбежно обращается ко многим хостам и базам данных. Но обычно только одна база данных на одном хосте может быть выбрана в качестве самой надежной или содержащей наиболее важную информацию. Такая база данных называется узлом фиксации транзакции (commit point site). Если изменение данных завершено здесь, то оно завершено для всех баз данных. Если транзакция в узле точки фиксации оканчивается неудачей, то для транзакций на всех остальных узлах будет выполнен откат. Кроме того, этот узел хранит информацию о состоянии распределенной транзакции.
Узел фиксации транзакции выбирается Oracle, исходя из приоритета точки фиксации каждой базы данных. Это значение устанавливается в файле инициализации, например:
□ COMMIT_POINT_STRENGTH = 100
Значение параметра COMMIT_POINT_STRENGTH устанавливается в относительном, а не в абсолютном выражении. В приведенном примере оно равно 100. Если для другой базы данных интенсивность точки завершения равна 200, то именно эта база будет выбрана в качестве узла фиксации транзакции для распределенной транзакции, в которой участвуют эти две базы данных. Значение COMMIT_POINT_STRENGTH не может превышать 255.
Поскольку масштаб здесь относителен, шкала устанавливается в соответствии с важностью узлов. Установите для самой надежной базы данных значение 200 и по отношению к нему устанавливайте значения для других серверов и баз данных. Если, например, надежность какой-либо базы данных составляет 80% по отношению к самой надежной базе, установите для нее интенсивность точки фиксации равной 160 (80% от 200). Выбор для одной базы данных определенного уровня (в данном случае 200) позволяет распределить по шкале все остальные базы данных. В итоге для каждой транзакции будет использоваться нужный узел фиксации транзакции.
Мониторинг распределенных баз данных
Существует целый ряд ключевых показателей производительности, которые необходимо принимать во внимание для баз данных:
Производительность хоста
Распределение операций ввода/вывода между дисками и контроллерами
Использование доступной памяти
Для распределенных баз данных также должны быть учтены:
Пропускная способность сети и ее оборудование
Нагрузка на сетевые сегменты
Использование различных физических путей доступа между
¥ПГТЯМИ
Управление распределенными базами данных
727
Ни один из этих показателей нельзя оценить изнутри базы данных. Основным контролируемым объектом при мониторинге распределенных баз данных является не база данных, а сеть. Сама база данных становится лишь частью подвергаемой мониторингу среды, а не единственным контролируемым объектом.
Вместе с тем сохраняется потребность в мониторинге аспектов базы данных, критичных для ее нормальной работы, например в мониторинге свободного места в табличных пространствах. Однако производительность распределенных баз данных нельзя оценить отдельно от сети, обеспечивающей их функционирование. Следовательно, все тесты производительности, например нагрузочные, необходимо выполнять во взаимодействии с обслуживающим персоналом сети. Эти сотрудники могут также проверить эффективность попыток уменьшить нагрузку, налагаемую базой данных на сеть.
Производительность отдельных хостов обычно контролируется с помощью пакета программ для мониторинга сети. Такой мониторинг осуществляется “сверху вниз”: сеть — хост — база данных. Систему мониторинга (см. главу 6), следует использовать как расширение мониторов сети и хостов.
Настройка распределенных баз данных
Целью настройки автономной базы данных является уменьшение времени поиска информации. Для повышения вероятности нахождения данных в памяти или в первой же просматриваемой области можно использовать ряд структур и параметров базы данных (см. главу 8).
При работе с распределенными базами данных необходимо учитывать дополнительные моменты. Поскольку теперь данные должны быть не только найдены, но и переданы по сети, скорость выполнения запроса определяется эффективностью этих двух операций. Поэтому необходимо анализировать способы передачи данных по сети с целью уменьшения сетевого трафика.
Простой способ снизить объем сетевого трафика состоит в тиражировании данных с одного узла на другой. Это можно делать вручную (с помощью команды сору утилиты SQL*Plus) или автоматически (с помощью материализованных представлений). Тиражирование повышает производительность запросов к удаленным базам данных, поскольку при этом данные передаются по сети однократно — обычно во время невысокой загрузки локального хоста. Локальные запросы могут использовать локальные копии данных, устраняя сетевой трафик, который был бы необходим в любом другом случае.
Рассмотрим простую задачу — выборку значения из последовательности. Компания создала распределенное приложение, в котором для каждой новой строки генерируется новое значение последовательности. Однако эта последовательность является локальной, в то время как вставки выполняются в удаленной на значительное расстояние базе данных. Поскольку триггер, генерирующий значения последовательности, срабатывает для каждой строки, при выполнении каждой операции вставки генерируется удаленная операция для генерации следующего значения последовательности. Влияние, оказываемое таким проектным решением, становится очевидным при изучении трассировочного файла сеанса:
728
Глава 18
□ SELECT NEWID.SEQ.NEXTVAL
FROM
DUAL
call count cpu elapsed disk query current rows
Parse 1 0.01 0.13 0 0 0 0
Execute 53 0.01 0.01 0 0 0 0
Fetch 53 0.06 6.34 0 159 0 53
total 107 0.09 6.50 0 159 0 53
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
0 SEQUENCE (REMOTE)
0 TABLE ACCESS (FULL) OF ‘DUAL’
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
------------------------------------------ Waited ------------ ---------------
SQL*Net message to dblink 53 0 00 0.00
SQL*Net message from dblink 53 0.13 6.29
В данном случае запрос весьма простой — он выбирает очередное значение последовательности из DUAL. Но последовательность является удаленной (это видно из плана выполнения), так что время, требующееся для извлечения значений, составляет 6,29 сек для 53 строк (из общего времени 6,50 сек). Для настройки приложения необходимо либо уменьшить количество пересылок по сети (например, за счет выполнения пакетных операций вместо того, чтобы выполнять операции “строка за строкой”) или полностью устранить удаленный компонент команды insert. Если можно собрать вместе удаленный объект (последовательность) и локальный объект (таблицу DUAL), время ожидания, связанное с удаленными операциями, можно устранить.
При использовании способа, связанного с тиражированием, возникают две проблемы. Во-первых, локальные данные могут перестать быть синхронизированными с удаленными данными. Это давняя проблема производных данных. Она ограничивает применение тиражирования только теми таблицами, данные которых достаточно статичны. Даже при использовании простого материализованного представления совместно с журналом материализованных представлений данные не будут обновляться непрерывно — только по расписанию.
Вторая проблема, связанная с тиражированием данных, заключается в том, что обновления не всегда могут быть переданы из копии таблицы в основную таблицу. Иначе говоря, если для копирования удаленной таблицы в локальную базу данных используется материализованное представление “только для чтения’*, то его обновление невозможно. Если
Управление распределенными базами данных
729
используются материализованные представления, можно применить обновляемые представления для отправки изменений назад на ведущий узел или перезаписываемые материализованные представления — для поддержки локального владения данными.
Таким образом, любые операции обновления, выполняемые над копиями таблиц, должны выполняться и над основными таблицами. При достаточно частом обновлении таблицы тиражирование данных не повысит производительность, если только не используется возможность Oracle тиражирования с несколькими ведущими узлами. В этом режиме владельцами данных могут быть несколько узлов, а пользователи могут изменять любую базу данных, указанную в качестве владельца данных. Управлять тиражированием с несколькими ведущими узлами очень сложно. Это требует создания окружения базы данных (со связями БД и т.д.), специально предназначенного для поддержки двухстороннего тиражирования данных (подробнее о реализации среды с несколькими ведущим узлами см. в документации Oracle по тиражированию).
Эффективность обновлений обычно не заботит пользователей. Что их может действительно волновать, так это допустимость и актуальность (своевременность) данных. Если удаленные таблицы часто модифицируются, а их размер достаточно велик, для обеспечения актуальности данных придется почти в обязательном порядке использовать простые материализованные представления с журналами материализованных представлений. Как правило, полное обновление данных в середине рабочего дня недопустимо. Таким образом, именно частота обновлений, а нс их объем является важнейшим фактором, определяющим, насколько тот или иной тип материализованных представлений подходит для пользователей с точки зрения производительности. В конце концов, пользователям нужна высокая производительность системы во время работы с ней; обновления, выполняемые глубокой ночью, не затрагивают их непосредственно. Если приходится часто синхронизировать таблицы, лучше применять простые материализованные представления с журналами материализованных представлений.
Можно индексировать базовые таблицы, создаваемые материализованным представлением в локальной базе данных. Индексы повышают производительность запроса за счет замедления обновления.
Еще одним способом уменьшения сетевого трафика является вызов удаленных процедур (см. главу 8; там же см. о настройке SQL и разработке приложений). Если база была правильно структурирована, оптимизация обработки данных в приложении даст наиболее существенное повышение производительности.
ORACL-C
ORACLE 1 Og
DATABAS E J (И
I
Важнейшие ресурсы
для всех администраторов баз данных
Это уникальное руководство издательства Oracle Press поможет вам поддерживать высокопроизводительную корпоративную базу данных Oracle. Книга научит вас инсталлировать Oracle Database 10g или выполнить апгрейд с одной из более ранних версий, чтобы воспользоваться всеми преимуществами возможностей нового и усовершенствованного управления, масштабируемости, доступности и безопасности. В пособии, написанном экспертами по Oracle, рассматриваются технологии Automatic Undo Management (автоматическое управление пространством отката), Oracle Real Application Clusters (кластеры Oracle для реальных приложений), Oracle Recovery Manager (диспетчер восстановления Oracle), Oracle Data Guard (защита данных Oracle) и многое другое.
* Планирование табличных пространств - в том числе табличных пространств вида B1GFILE (большой файл данных) и многих типов временных табличных пространств - и физическое размещение базы данных
• Управление дисковой памятью с использованием ЦП
• Использование автоматического управления пространством отката для управления транзакциями
• Настройка запросов с помощью инструментального средства SQL Access Advisor ("консультант" по SQL-доступу)
• Мониторинг и настройка базы данных с помощью Automatic Workload Repository (автоматически управляемого репозитория рабочей нагрузки) и пакета STATSPACK
• Реализация детальной защиты с помощью методик аутентификации, авторизации и аудита
• Автоматизация управления областями памяти
• Активизация высокой доступности системы с использованием Oracle Real Application Clusters
• Выполнение операции резервного копирования и восстановления с помощью Oracle Recovery Manager
• Использование Oracle Data Guard и ретроспективных возможностей базы данных для обеспечения безопасности данных и восстановления данных после катастроф
• Управление очень большими базами данных и распределенными базами данных
Об авторах
Кевин Луни - старший консультанто в области технического управления компании TUCS (Чикаго), которая занимается консалтингом и разработкой решений для Oracle. Начиная с 1987 г., он был разработчиком и администратором баз данных Oracle, а с 1990 г. стал постоянным автором журнала Oracle Magazine и издательства Oracle Press. В 2002 г. журнал Oracle Magazine назвал его лучшим консультантом года. Он часто выступает на конференциях местных и международных групп пользователей Oracle, и его выступления имеют высокий рейтинг.
Боб Брила -сертифицированный профессионал в области баз данных Oracle (версии 8, 8/, 9/ и 10g) с более чем 15-летним опытом проектирования баз данных, разработки приложений баз данных, обучения и администрирования баз данных. Он является основным проектировщиком баз данных для Интернета и АБД Oracle в компании Land's End в городе Доджвилль, шт. Висконсин. Полный перечень названий книг издательства Oracle Press приводится на сайте www.OraclePressBooks.com
Полный перечень книг издательства Oracle Press можно найти на сайте www.OraclePressBooks.com
Издательство ’’ЛОРИ" www.lory-press.ru
REQUIRED READING for the Information Age
A Pu'tibu i#ThtMcGfwv-HiU<