Для использования таких операторов используется расширение механизма курсоров стандарта SQL. Во-первых, при определении курсора можно указывать не только литеральную спецификацию курсора, но и имя оператора, вводимое с помощью оператора PREPARE (в этом случае оператор PREPARE должен текстуально находиться выше оператора DECLARE). Тем самым полный синтаксис оператора DECLARE становится следующим:
<declare cursor> ::=
DECLARE <cursor name> CURSOR
FOR { <cursor specification> | <statement-name> }
Далее, поскольку для такого курсора в статике неизвестна информация о входных и выходных переменных включающей программы, то используется другая форма операторов OPEN и FETCH.
Полный синтаксис этих операторов становится следующим:
<open statement> ::=
OPEN <cursor name>
[USING { <host-vars-list> | DESCRIPTOR <descr-name> }]
<fetch statement> ::=
FETCH <cursor name>
{ INTO <fetch target list> |
USING <host-vars-list> |
USING DESCRIPTOR <descr-name> }
Как видно, предлагается два способа задания фактических входных и выходных параметров: прямое с указанием в операторах OPEN и/или FETCH списков имен переменных включающей программы и косвенное, когда число параметров и их адреса сообщаются через дополнительную структуру-дескриптор.
Первый способ предлагается использовать для работы с операторами выборки, для которых фиксирован набор формальных входных и выходных параметров.
Второй способ работы с динамически откомпилированными операторами, требующими использования курсоров, состоит в использовании дескрипторов динамически формируемых списков параметров.
Блокировка S, удерживаемая транзакцией, позволяет другим транзакциям одновременно лишь опрашивать эту таблицу, блокировать выбираемые строки с помощью команды SELECT ... FOR UPDATE, или успешно выполнять предложения LOCK TABLE ... IN SHARE MODE; никакие обновления они не могут осуществлять. Несколько транзакций могут одновременно удерживать блокировки S для одной и той же таблицы.
Разделяемая блокировка таблицы, удерживаемая транзакцией, также запрещает другим транзакциям выполнять следующие предложения:
· LOCK TABLE таблица IN SHARE EXCLUSIVE MODE;
· LOCK TABLE таблица IN EXCLUSIVE MODE;
· LOCK TABLE таблица IN ROW EXCLUSIVE MODE;
Эта блокировка указывает, что транзакция, удерживающая блокировку по таблице, блокировала строки в этой таблице и намерена обновить их. Эта блокировка автоматически запрашивается для ТАБЛИЦЫ, модифицируемой следующими предложениями:
SELECT ... FROM таблица ... FOR UPDATE OF ...;
LOCK TABLE таблица IN ROW SHARE MODE;
Блокировка RS - это наименее ограничительный режим блокировки таблицы, предоставляющий наибольшую степень одновременного доступа к таблице.
Блокировка RS, удерживаемая транзакцией, запрещает другим транзакциям получать монопольный доступ по записи к данной таблице, который запрашивается следующим предложением (и только им):
LOCK TABLE таблица IN EXCLUSIVE MODE;
Блокировка SRX, удерживаемая транзакцией, позволяет другим транзакциям одновременно лишь опрашивать эту таблицу или блокировать выбираемые строки с помощью команды SELECT ... FOR UPDATE, но не обновлять эту таблицу.
Блокировка SRX, удерживаемая транзакцией, запрещает другим транзакциям получать блокировки SRX по этой таблице и модифицировать эту таблицу. Транзакция не может вставлять, обновлять или удалять строки в таблице, если какая-то другая транзакция имеет блокировку SRX по этой таблице. Блокировка SRX, удерживаемая транзакцией, также запрещает другим транзакциям получать блокировки SRX, S и RX по этой таблице; иными словами, другие транзакции не могут успешно выполнять следующие предложения:
· LOCK TABLE таблица IN SHARE MODE;
· LOCK TABLE таблица IN SHARE EXCLUSIVE MODE;
· LOCK TABLE таблица IN ROW EXCLUSIVE MODE;
· LOCK TABLE таблица IN EXCLUSIVE MODE;
В обязанности разработчика приложений входит:
· проектирование и разработка приложений базы данных
· проектирование структуры базы данных в соответствии с требованиями приложений
· оценка требований памяти для приложения
· формулирование модификаций структуры базы данных для приложения
· передача вышеупомянутой информации администратору базы данных
· настройка приложения в процессе его разработки
· установка мер по защите приложения в процессе его разработки
Если над базой данных производят любое из ниже перечисленных структурных изменений, базы данных, непосредственно перед изменениями и после делается соответствующее копирование базы данных:
· Создание или удаление табличного пространства
· Добавление или переименование (перемещение) файла данных в существующем табличном пространстве
· Добавление, переименование(перемещение) или удаление группы или члена онлайнового журнала повторения.
· Если база данных работает в режиме ARCHIVELOG, то до и после структурного изменения базы данных требуется лишь резервное копирование управляющего файла базы данных (с помощью команды ALTER DATABASE с опцией BACKUP CONTROLFILE). Можно скопировать и другие части базы данных.
· Если база данных работает в режиме NOARCHIVELOG, то непосредственно перед и после изменения базы данных требуется сделать полное копирование файла базы данных, включая все файлы данных, файлы журнала повторения и управляющие файлы.
Существует, по большому счету, два вида резервного копирования :
1. Непротиворечивое (холодное) резервное копирование, ситуация когда, копии создаются, в случае закрытой БД (close) для пользователей. Копия базы данных, созданной в автономном режиме, содержит: все файлы данных, журналы повторов и управляющие файлы. После останова БД, все файлы базы данной по средствам ОС копируются на один из backup дисков.
Этапы:
· Остановка экземпляра БД Oracle – в режиме shutdown normal (игнорирование, новых подключений и ожидание отключение все зарегистрированных пользователей) или shutdown immediate (немедленное прерывание всех соединений, выполнение операции отката на всех транзакциях ожидающих обработки)
· Копирование всех физических файлов, относящихся к базе данных, управляющие файлы, файлы журнала обновления и файлы базы данных.
Режим экспорта пользователя в основном используется для экспорта всех таблиц и индексов конкретного пользователя или перечня пользователей. Этот режим работает хорошо при создании пользователя, который является владельцем всех объектов приложения. Например, если существует пользователь с именем sales, который является владельцем всех таблиц и индексов и других объектов в приложении sales, экспорт приложения может выглядеть следующим образом:
exp VSERlD=system/manager OWNER=sales
Режим экспорта таблиц используется для экспорта одной таблицы или перечня таблиц, а не всей базы данных. По умолчанию он экспортирует все таблицы, которые принадлежат пользователю, выполняющему экспорт. Пользователи, имеющие доступ к другой схеме, могут экспортировать таблицы из этой схемы, указав имя схемы.
Режим экспорта всей базы данных используется для экспорта всех объектов базы данных, за исключением объектов, которые обычно создаются и поддерживаются учетной записью SYS. Эту опцию могут применять только пользователи, которым назначена роль EXP_FULL_DATABASE. Здесь можно упомянуть несколько других интересных возможностей. По умолчанию Oracle выполняет полный экспорт при указании режима экспорта всей базы данных (INCTYPE= COMPLETE). Если указана опция INCTYPE= INCREMENTAL, Oracle будет экспортировать только таблицы, содержащие какие-либо изменившиеся строки, начиная с последнего полного экспорта любого типа. Если указана опция INCTYPE=CUMULATIVE, Oracle будет экспортировать только таблицы, содержащие какие-либо измененные строки, начиная с последнего полного или кумулятивного экспорта.
Типы экспорта:
· Полный экспорт
· Инкрементный экспорт
· Кумулятивный экспорт
ORACLE предоставляет легкое и контролируемое управление привилегиями через использование ролей. РОЛИ (ROLE) - это поименованные группы взаимосвязанных привилегий, которые назначаются пользователям или другим ролям.
Уровень логического пространства базы данных, следующий за экстентом, называется СЕГМЕНТОМ (SEGMENTS). Сегмент - это совокупность экстентов, распределенных для специфического типа структуры данных, и находящихся в одном и том же табличном пространстве. Например, данные каждой таблицы хранятся в ее собственном СЕГМЕНТЕ ДАННЫХ, а данные каждого индекса хранятся в его собственном СЕГМЕНТЕ ИНДЕКСА.
ORACLE распределяет пространство для сегментов экстентами. Поэтому, когда существующие экстенты сегмента заполнены, ORACLE распределяет очередной экстент для этого сегмента. Поскольку экстенты распределяются при необходимости, экстенты сегмента не обязательно смежные на диске, и могут быть распределены между различными файлами. Каждый экстент, однако, не может находиться в нескольких файлах.
Сегмент - это набор экстентов, содержащих все данные для конкретного типа структуры логического пространства внутри табличного пространства. Например, для каждой таблицы ORACLE распределяет один или несколько экстентов, чтобы сформировать сегмент данных этой таблицы; для каждого индекса ORACLE распределяет один или несколько экстентов, чтобы сформировать сегмент индекса для этого индекса.
База данных ORACLE может содержать четыре различных типа сегментов:
· сегмент данных
· сегмент индекса
· сегмент отката
· временный сегмент
СХЕМА(SCHEMA) - это коллекция объектов. ОБЪЕКТЫ СХЕМЫ - это логические структуры, непосредственно относящиеся к данным базы данных. Объекты схемы включают такие структуры как: таблицы, представления, последовательности, хранимые процедуры, синонимы, индексы, кластеры и связи баз данных. (Не существует взаимосвязи между табличным пространством и схемой; объекты одной и той же схемы могут находиться в разных табличных пространствах, и одно и то же табличное пространство может содержать объекты из разных схем.)
ТАБЛИЦА(TABLE) - это основная единица хранения данных в базе данных ORACLE. Таблицы базы данных хранят все данные, доступные пользователям.
Данные таблицы хранятся в виде СТРОК и СТОЛБЦОВ. Каждая таблица определяется с ИМЕНЕМ ТАБЛИЦЫ и набором столбцов. Каждому столбцу дается ИМЯ СТОЛБЦА, ТИП ДАННЫХ (такой как CHAR, DATE или NUMBER), а также ШИРИНА (которая может быть предопределена типом данных, как в случае DATE) или МАСШТАБ и ТОЧНОСТЬ (только для типа данных NUMBER). После того, как таблица создана, в нее могут быть вставлены строки действительных данных. После этого строки таблицы можно опрашивать, удалять или обновлять. Чтобы учредить организационные правила для данных таблицы, для таблицы можно также определить ограничения целостности и триггеры.
ПРЕДСТАВЛЕНИЯ(VIEW) - это настроенное представление данных из одной или нескольких таблиц. представлений можно рассматривать как "хранимый запрос". Представления в действительности не содержат данных; вместо этого они доставляют данные из тех таблиц, на которых они основаны (так называемых БАЗОВЫХ ТАБЛИЦ представлений). Базовые таблицы, в свою очередь, могут быть как таблицами, так и представлениями.
Как и таблицы, представления можно опрашивать, обновлять и осуществлять в них вставки и удаления, с некоторыми ограничениями. Все операции, осуществляемые над представлениями, в действительности затрагивают базовые таблицы этого представления.
СИСТЕМНЫЕ ПРИВИЛЕГИИ(SYSTEM_PRIVILEGE) позволяют пользователям выполнять конкретное действие на уровне системы, или конкретное действие над конкретным типом объектов. Таковы, например, привилегия создавать табличное пространство или привилегия удалять строки любой таблицы в базе данных. Большинство системных привилегий доступны только администраторам и разработчикам приложений, поскольку такие привилегии весьма мощны.
После первоначального создания файла данных соответствующее дисковое пространство еще не содержит никаких данных; однако это пространство ЗАРЕЗЕРВИРОВАНО за будущими сегментами ассоциированного табличного пространства - оно не может содержать каких-либо иных данных. Когда сегмент (например, сегмент данных таблицы) будет создан и начнет увеличиваться в размерах, ORACLE использует свободное место в соответствующих файлах данных, чтобы распределять экстенты для этого сегмента. Данные в сегментах объектов (сегментах данных, сегментах индексов, сегментах отката и т.д.) в табличном пространстве физически хранятся в одном или нескольких файлах данных, составляющих это табличное пространство.
В режиме ARCHIVELOG:
· Требуется дополнительное дисковое пространство
· Управление архивными журналами влечет за собой дополнительные административные непроизводительные затраты.
· Применимо горячее резервное копирование.
· В случае отказа носителя может быть выполнено полное восстановление базы данных.
В режиме NOARCHIVELOG:
· Не требуется дополнительное дисковое пространство или непроизводительные затраты.
· Может использоваться только холодное резервное копирование.
· В случае отказа теряется вся работа, выполненная со времени последнего резервного копирования.
В некоторых случаях база данных должна также иметь одного или нескольких сотрудников службы безопасности. СОТРУДНИК СЛУЖБЫ БЕЗОПАСНОСТИ главным образом отвечает за регистрацию новых пользователей, управление и отслеживание доступа пользователей к базе данных, и защиту базы данных.
При создании базы данных необходимо подготовить несколько файлов данных операционной системы, которые будут использоваться вместе как единая база данных. База данных создается один раз, независимо от того, сколько файлов данных она имеет, и сколько экземпляров будут обращаться к ней. Процедуру создания базы данных можно также использовать для того, чтобы стереть информацию в существующей базе данных и создать новую базу данных с тем же именем и физической структурой.
Создание базы данных включает следующие операции:
· создание новых файлов данных, или стирание данных, хранившихся в предыдущих файлах данных
· создание структур, требующихся ORACLE для доступа и работы с базой данных (словаря данных)
· создание и инициализация управляющих файлов и файлов журнала повторения для базы данных
База данных создается с помощью предложения, включающего команду SQL CREATE DATABASE; однако, прежде чем выдавать такое предложение, рассмотрите следующие вопросы:
· Спланируйте ваши таблицы и индексы, и оцените, сколько пространства они потребуют.
· Спланируйте проблемы защиты вашей базы данных, включая конфигурацию ее онлайнового и архивного журналов (с учетом занимаемого ими пространства) и стратегию резервного копирования.
· Выберите набор символов базы данных. Вы должны указать набор символов при создании базы данных, и не сможете изменить его до повторного создания базы данных. Все символьные данные в базе данных, включая данные в словаре данных, хранятся в наборе символов базы данных. Если пользователи предполагают обращаться к базе данных, используя другие наборы символов, то набор символов базы данных должен быть надмножеством всех используемых наборов символов.
Для создания каждой новой базы данных ORACLE необходимо последовательно выполнить следующие шаги:
1. Скопировать все существующие базы данных.
2. Создать файлы параметров.
3. Отредактировать новые файлы параметров.
4. Проверить идентификатор экземпляра ORACLE.
5. Запустить SQL*DBA и соединиться с ORACLE как INTERNAL.
6. Запустить экземпляр.
7. Создать базу данных.
8. Скопировать базу данных.
Можно создать группы онлайнового журнала и как часть создания базы данных, и позднее. Если возможно, спланируйте журнал и создайте все необходимые группы файлов журнала во время создания базы данных. Для создания новой группы онлайнового журнала используйте команду SQL: ALTER DATABASE с параметром ADD LOGFILE. Более подробно см Резервное копирование и восстановление.
Одной из многих проблем, с которыми часто сталкиваются администраторы базы данных, является перемещение данных из внешних источников в базу данных Oracle. Сложность этой задачи возрастает с появлением хранилищ данных, приходится перемещать уже не мегабайты данных, а гигабайты, а в некоторых случаях – терабайты. Oracle предусматривает для решения этой задачи SQL*Loader – универсальное инструментальное средство, которое загружает внешние данные в таблицы базы данных Oracle. Утилита SQL*Loader является гибкой и настраиваемой до такой степени, что часто удается обойтись без процедур на языке третьего поколения с внедренными операторами SQL. Каждый раз, сталкиваясь с задачей преобразования инородных данных в формат Oracle, вначале рассмотрите возможность применения SQL*Loader, прежде чем обращаться к другим средствам.
В состав словаря данных базы данных входят:
Базовые таблицы
Основу словаря данных составляет совокупность базовых таблиц, хранящих информацию о базе данных. Эти таблицы читаются и пишутся ТОЛЬКО самим ORACLE; они редко используются непосредственно пользователем ORACLE любого типа, потому что они нормализованы, и большая часть данных в них закодирована.
Доступные пользователю представления
Словарь данных содержит доступные пользователю представления, которые суммируют и отображают, в удобном представлении формате информацию из базовых таблиц словаря. Эти представления декодируют информацию базовых таблиц, представляя ее в полезном виде, таком как имена пользователей или таблиц, и используют соединения и фразы WHERE, чтобы упростить информацию. Большинство пользователей имеют доступ к этим представлениям вместо базовых таблиц словаря.
Все базовые таблицы и представления словаря данных принадлежат пользователю ORACLE с учетным именем SYS. Поэтому ни один пользователь ORACLE не должен изменять никаких объектов, содержащихся в схеме SYS, а администратор безопасности должен строго контролировать использование этого центрального учетного имени.
Данные в базовых таблицах словаря данных необходимы для функционирования ORACLE. Поэтому только ORACLE должен записывать или изменять информацию словаря данных.
Во время операций по базе данных ORACLE читает словарь данных, чтобы удостовериться, что нужные объекты существуют, и что пользователи имеют к ним должный доступ. ORACLE также непрерывно обновляет словарь данных, чтобы отражать происходящие изменения в структурах базы данных, аудите, грантах и данных.
Вы можете добавлять в словарь данных новые таблицы или представления. Если вы добавляете новые объекты в словарь данных, их владельцем должен быть SYSTEM или какой-либо третий пользователь ORACLE. Когда включен режим аудита, эта таблица может неограниченно расти. Хотя пользователи не должны удалять эту таблицу, администратор безопасности может удалять из нее данные, потому что строки этой таблицы служат лишь для информации и не являются необходимыми для работы ORACLE.
ORACLE создает и использует свои структуры памяти для выполнения некоторых задач. Например, память используется для размещения исполняемого программного кода и данных, разделяемых между пользователями. С ORACLE ассоциируются несколько базовых структур памяти: глобальная область системы (которая включает буфера базы данных и журнала повторения, а также разделяемый пул) и глобальные области программ. Следующие секции подробно объясняют каждую из этих видов областей.
Механизмы ORACLE работают через использование структур памяти и процессов. Все структуры памяти располагаются в основной памяти (иногда называемой виртуальной памятью или памятью произвольного доступа) компьютеров, составляющих систему базы данных.
ПРОЦЕССЫ(PROCESS) - это задания или задачи, работающие в памяти этих компьютеров. ПРОЦЕСС - это "канал управления", или механизм в операционной системе, способный выполнять последовательность шагов. Некоторые операционные системы используют термины "задание" или "задача". Процесс обычно имеет свою собственную личную область памяти, в которой он выполняется. (V$PROCESS - информация об активных и V$BGPROCESS – информация о фоновых процессах)
Структура процесса такой системы, как ORACLE, существенна, потому что она определяет, как осуществляется параллельная деятельность и как она управляется. Например, двумя целями структуры процесса могут быть: 1) симуляция личных окружений для нескольких одновременно работающих процессов, так, как будто каждый процесс имеет свое собственное личное окружение 2) обеспечение разделения между процессами ресурсов компьютера, необходимых каждому процессу, но не на долгое время
Однопроцессная (также называемая однопользовательской) система ORACLE - это система базы данных, в которой весь код ORACLE исполняется одним процессом. Не используются разные процессы, чтобы разграничить выполнение компонент ORACLE и прикладной программы клиента. Вместо этого весь код ORACLE и единственное приложение базы данных выполняются как единственный процесс. Единственный процесс исполняет весь код, ассоциированный как с приложением базы данных, так и с ORACLE.
Многопроцессный ORACLE (называемый также многопользовательским) использует несколько процессов для исполнения различных частей ORACLE, а также отдельный процесс для каждого присоединенного пользователя. Каждый процесс в многопроцессном ORACLE выполняет специфическую задачу. Благодаря разделению работы ORACLE и приложений базы данных на несколько процессов, несколько пользователей и приложений могут одновременно присоединяться к единственной инстанции базы данных, в то время как система поддерживает отличную производительность. Большинство систем баз данных - многопользовательские, ибо одним из основных преимуществ СУБД является управление данными, с которыми много пользователей работают одновременно. Каждый присоединенный пользователь имеет отдельный пользовательский процесс, а для выполнения ORACLE используются несколько фоновых процессов. Много процессной системе все процессы можно разделить на две группы: пользовательские процессы и процессы ORACLE.
Каждая база данных ORACLE содержит табличное пространство SYSTEM, которое создается автоматически при создании базы данных. Табличное пространство SYSTEM всегда содержит таблицы словаря данных для всей базы данных. Небольшой базе данных может оказаться достаточным одного табличного пространства SYSTEM; однако рекомендуется создать по меньшей мере одно дополнительное пространство, чтобы хранить данные пользователей отдельно от информации словаря данных. Это позволит более гибко осуществлять разнообразные операции администрирования.
Размер табличного пространства - это размер его файла данных или суммарный размер всех файлов данных, составляющих это табличное пространство.
Каждая база данных ORACLE подразделяется на логические элементы, называемые ТАБЛИЧНЫМИ ПРОСТРАНСТВАМИ(TABLESPACE). Администратор базы данных может использовать табличные пространства для:
· управления распределением памяти для объектов базы данных
· установления квот памяти для пользователей базы данных
· управления доступностью данных, путем перевода отдельных табличных пространств в состояния online или offline
· копирования и восстановления данных
· распределения данных по устройствам для повышения производительности
Используемые данные базы данных ORACLE логически хранятся в ТАБЛИЧНЫХ ПРОСТРАНСТВАХ (TABLESPACE), а физически располагаются в ФАЙЛАХ ДАННЫХ, ассоциированных с соответствующим табличным пространством. Эту взаимосвязь иллюстрирует следующий рисунок:
Файлы данных и табличные пространства
Файлы данных - физические структуры, каждая из которых связана с одним табличным пространством
Объекты - Хранятся в табличных пространствах, и могут располагаться в нескольких файлах данных
Транзакция (модуль фиксации) – логический модуль, который состоит из набора изменений (вставок, обновлений и удалений). Транзакции либо должны быть сохранены в базе данных, либо должен быть выполнен их откат. Фиксируются либо все изменения в транзакции, либо ни одно из них. Для фиксирования в базе данных результатов транзакции используется команда COMMIT, для восстановления изменённых данных используется команда ROLLBACK.
Транзакция начинается:
1. Когда пользователь подключается к базе данных и начинает с ней работать.
2. После выполнения оператора COMMIT.
3. После выполнения оператора ROLLBACK.
Откат на уровне оператора – данное понятие означает, что для конкретного оператора либо будут сохранены все внесённые им изменения, либо не будет выполнено ни одно из них.
БЛОКИРОВКИ(LATCH) - это механизмы, используемые для того, чтобы предотвратить деструктивные взаимодействия между пользователями, обращающимися к одному и тому же ресурсу, будь то вся таблица или одна строка в таблице.(V$LATCH)
В многопользовательской базе данных могут применяться два уровня блокировок:
1. Монопольная блокировка – запрещает разделение ассоциированного ресурса. Первая транзакция, получившая монопольную блокировку ресурса, становится единственной транзакцией, которая может изменять этот ресурс до снятия монопольной блокировки.
2. Разделяемая блокировка – позволяет совместно использовать ассоциированный ресурс, в зависимости от того, какие операции выполняются (например, несколько пользователей могут читать данные одновременно). Несколько транзакций могут получить разделяемые блокировки для одного и того же ресурса.
Захват – ситуация, которая возникает, когда два или более пользователей ожидают данных, заблокированных друг другом.
ORACLE автоматически распознает ситуации захватов, и автоматически разрешает такие ситуации, осуществляя откат одного из предложений, вовлеченных в захват и тем самым освобождая одно множество конфликтующих блокировок строк.
Как и в любой таблице базы данных, после удаления записей из аудиторского журнала базы данных все экстенты, которые были распределены этой таблице, будут по-прежнему существовать. Если аудиторский журнал имеет слишком много экстентов, большинство из которых не используются, то можно уменьшить размер этого журнала, выполнив следующие шаги:
1. Если вы хотите сохранить информацию из аудиторского журнала, скопируйте ее в другую таблицу базы данных, или экспортируйте ее с помощью утилиты экспорта.
2. Соединитесь с базой данных как INTERNAL.
3. Выполните усечение таблицы SYS.AUD$ с помощью команды TRUNCATE.
4. Перезагрузите аудиторские записи, сохраненные вами на шаге 1.
Центральное место в средствах защиты занимает учётная запись пользователя базы данных Oracle.
CREATE USER – это команда SQL, которая может использоваться для определения учётной записи Oracle в базе данных. После создания учётной записи пользователя Oracle она не может использоваться, пока пользователь не получит, по меньшей мере одну системную привилегию. Системная привилегия CREATE SESSION позволяет пользователю создавать сеанс по отношению к базе данных Oracle. Это – необходимая привилегия, которую должна иметь учётная запись пользователя, без неё учётная запись пользователя Oracle не может использоваться.
При первоначальном создании пользователя Oracle можно определить заданное по умолчанию табличное пространство, в котором будут создаваться объекты пользователя. Если заданное по умолчанию табличное пространство не определено, пользователю будет назначено табличное пространство SYSTEM в качестве заданного по умолчанию, которое будут использовать объекты базы данных. В составе оператора CREATE USER может использоваться фраза DEFAULT TABLESPACE для определения того, что объекты пользователя должны быть помещены в табличное пространство, отличное от SYSTEM. Пользователю Oracle также должна быть назначена квота, которая определяет, сколько памяти он может использовать в табличном пространстве.
Другой способ создания пользователя состоит в том, чтобы предоставить пользователю роли CONNECT, RESOURCE и DBA. Хотя это и быстрый метод, он включён, прежде всего, для совместимости с предыдущими версиями программного обеспечения Oracle. Команда CREATE USER – более предпочтительный метод, поскольку в одной команде можно указать и квоту и другие установки.
Можно использовать команду ALTER USER для изменения таких параметров пользователя, как пароль, заданные по умолчанию временные табличные пространства и квота памяти.
Для удаления пользователя из базы данных используется команда DROP USER, которая удаляет запись пользователя из словаря данных Oracle. Если пользователь Oracle владеет какими-либо объектами базы данных, можно либо удалить каждый из объектов перед использованием команды DROP USER, либо использовать в DROP USER опцию CASCADE для автоматического уничтожения всех объектов при удалении учётной записи пользователя.
Прежде чем утилита SQL*Loader сможет обработать данные в файлах данных, необходимо знать орпеделения даных для SQL*Loader. Используйте управляющий файл для указания физических определений файла данных, а также формата данных в файлах. Упраляющий файл – это файл произвольного формата, который также содержит дополнительные управляющие данные, указывающие SQL*Loader, как обрабатывать эти данные.
все опции аудита генерируют следующую общую информацию:
· имя пользователя, выполнявшего отслеживаемое предложение;
· код действия, указывающий выполненное предложение;
· объекты, адресуемые в отслеживаемом предложении;
· дату и время выполнения отслеживаемого предложения;
Аудиторский журнал не сохраняет информации о каких-либо значениях данных, которые могли быть вовлечены в отслеживаемое предложение; например, при аудите предложения UPDATE не сохраняются старые и новые значения данных. Однако, такой специализированный тип аудита можно осуществить для предложений DML, работающих с таблицами, с помощью триггеров базы данных.
ORACLE позволяет устанавливать опции аудита на трех уровнях:
· предложение аудита базируется на типе предложений SQL, например, на любых предложениях SQL по таблицам (что регистрирует каждое предложение CREATE, TRUNCATE и DROP TABLE)
· привилегия отслеживает использование конкретной системной привилегии, такой как CREATE TABLE
· объект отслеживает конкретные типы предложений на конкретных объектах, например, ALTER TABLE по таблице EMP
· инсталляция и обновление версий сервера ORACLE и прикладных инструментов
· распределение дисковой памяти и планирование будущих требований системы к памяти
· создание первичных структур памяти в базе данных (табличных пространств) по мере проектирования приложений разработчиками приложений
· создание первичных объектов (таблиц, представлений, индексов) по мере проектирования приложений разработчиками
· модификация структуры базы данных в соответствии с потребностями приложений
· зачисление пользователей и поддержание защиты системы
· соблюдение лицензионного соглашения ORACLE
· управление и отслеживание доступа пользователей к базе данных
· отслеживание и оптимизация производительности базы данных
· планирование резервного копирования и восстановления
· поддержание архивных данных на устройствах хранения информации
· осуществление резервного копирования и восстановления
· обращение в корпорацию Oracle за техническим сопровождением
Утилита SQL*Loader может обрабатывать файлы данных практически любого типа и поддерживает собственные типы данных почти любой платформы. Данные обычно считываются из одного или нескольких файлов данных, однако они могут быть также внесены в управляющий файл после управляющей информации. Файл данных может находиться:
В файлах с переменным форматом данные находятся в записях, которые могут изменяться по длине, в зависимости от размеров данных в полях. Поля имеют длину, необходимую для размещения данных. Поля в файлах с переменным форматом могут быть разделены завершающими символами (такими как запятые и пробелы), а так же заключены в ограничительные символы.
Чтобы автоматическое архивирование заполненных групп было включено установите в TRUE значение параметра LOG_ARCHIVE_START в файле параметров базы данных INIT.ORA:
LOG_ARCHIVE_START = TRUE Это значение будет иметь эффект при очередном запуске базы данных.
Вы устанавливаете первоначальный режим архивирования базы данных во время ее создания. В большинстве случаев, во время создания базы данных вы можете выбрать режим по умолчанию NOARCHIVELOG, потому что нет необходимости архивировать информацию, генерируемую за этот период. После того как база данных создана, решите, нужно ли изменить первоначальный режим архивирования. После того, как база данных создана, всегда можно переключать режим архивирования базы данных. Однако, как правило, следует выбрать постоянный режим работы базы данных.
Любой пользователь базы данных ORACLE может в любой момент установить опции аудита предложений, привилегий или объектов, но ORACLE не генерирует аудиторских записей и не помещает их в аудиторский журнал, если не включен режим аудита базы данных. Обычно за эту операцию отвечает администратор. Аудит базы данных включается и выключается параметром инициализации AUDIT_TRAIL в файле параметров базы данных. Этот параметр может быть установлен в следующие значения:
· DB - включает аудит базы данных и направляет все аудиторские записи в аудиторский журнал базы данных
· OS - включает аудит базы данных и направляет все аудиторские записи в аудиторский журнал операционной системы
· NONE - выключает аудит (умолчание)
Администратор защиты обязан контролировать рост аудиторского журнала и его размер. Когда аудит включен и генерируются аудиторские записи, аудиторский журнал растет за счет двух факторов:
· числа включенных опций аудита
· частоты выполнения отслеживаемых предложений
Для контроля за ростом аудиторского журнала вы можете использовать следующие методы:
· Включать и выключать аудит базы данных. Когда аудит включен, аудиторские записи генерируются и поступают в журнал; когда аудит выключен, аудиторские записи не генерируются.
· Жестко контролировать возможности осуществлять аудит объектов. Это можно делать двумя различными способами:
Ø Всеми объектами владеет администратор защиты, привилегия AUDIT ANY никогда не назначается никаким другим пользователям. Все объекты схемы могут принадлежать схеме, соответствующий пользователь которой не имеет привилегии CREATE SESSION.
Ø Все объекты содержатся в схемах, которые не соответствуют реальным пользователям базы данных (т.е. привилегия CREATE SESSION не назначена пользователям, одноименным со схемами), и администратор защиты является единственным лицом, имеющим системную привилегию AUDIT ANY.
· Все объекты содержатся в схемах, которые не соответствуют реальным пользователям базы данных (т.е. привилегия CREATE SESSION не назначена пользователям, одноименным со схемами), и администратор защиты является единственным лицом, имеющим системную привилегию AUDIT ANY.
Внутренние блокировки - это более сложные механизмы, чем замки, и они служат разнообразным целям. Рассмотрим их назначение ниже для трех различных категорий внутренних блокировок:
1. Блокировки кэша словаря. Эти блокировки на очень короткое время удерживаются для записей словаря при использовании или модификации этих записей. Они гарантируют, что предложения SQL во время их разбора видят согласованные определения объектов. Блокировки кэша словаря могут быть разделяемыми и монопольными. Разделяемые блокировки освобождаются по окончании синтаксического разбора. Монопольные блокировки освобождаются по концу операции DDL.
2. Блокировки управления файлами и журналом. Эти блокировки защищают различные файлы. Например, одна блокировка защищает управляющий файл, чтобы его мог модифицировать лишь один процесс в каждый момент времени. Другая блокировка координирует использование и архивирование файлов журнала повторения. Файлы данных блокируются для того, чтобы гарантировать, что база данных монтируется несколькими экземплярами в разделяемом режиме или одного экзепляра в монопольном режиме. Поскольку блокировки файлов и журнала отражают состояние файлов, эти блокировки по необходимости удерживаются продолжительное время.
3. Блокировки табличных пространств и сегментов отката. Эти блокировки защищают табличные пространства и сегменты отката. Например, все экземпляры, имеющие доступ к базе данных, должны согласованно отражать онлайновое или офлайновое состояние табличного пространства. Сегменты отката блокируются для того, чтобы лишь один экземпляр мог писать в сегмент отката.
Словарь данных является одной из важнейших частей базы данных ORACLE. Словарь данных - это набор таблиц, используемых как справочник только для чтения, который предоставляет информацию об ассоциированной с ним базе данных. Например, словарь данных может предоставлять следующую информацию:
· имена пользователей ORACLE
· привилегии и роли, которые были предоставлены каждому пользователю
· имена объектов схем (таблиц, представлений, снимков, индексов, кластеров, синонимов, последовательностей, процедур, функций, пакетов, триггеров и т.д.)
· информацию об ограничениях целостности
· умалчиваемые значения для столбцов
· сколько пространства было распределено и в настоящее время используется объектами в базе данных
· информацию аудита, например, кто обращался к различным объектам и обновлял их
· другую общую информацию о базе данных
Словарь данных структурирован через таблицы и представления, как и любые другие данные в базе данных. Для обращения к словарю данных вы используете SQL. Так как словарь данных можно только читать, пользователи могут выдавать лишь запросы (предложения SELECT) по таблицам и представлениям словаря данных.
Вы можете выключить автоматическое архивирование журнала в любой момент. Однако, выключив автоматическое архивирование, вы должны вручную, периодически и своевременно, архивировать заполняемые группы журнала. Если база данных работает в режиме ARCHIVELOG, автоматическое архивирование выключено, а группы журнала заполняются, но не архивируются, то процесс LGWR не сможет повторно использовать неактивные группы журнала, чтобы продолжать запись информации повторения. Поэтому работа базы данных будет временно приостановлена до тех пор, пока не будет выполнено необходимое архивирование. Автоматическое архивирование может быть выключено как до, так и после запуска инстанции.
Если база данных работает в режиме ARCHIVELOG, то можно копировать индивидуальное табличное пространство или даже индивидуальный файл. Эта возможность полезна, если одна часть базы данных используется более интенсивно, чем другие, - например, табличное пространство SYSTEM или табличные пространства, содержащие сегменты отката. Если сбой диска повреждает один из таких файлов данных, для его реставрации может быть использована ранняя копия, и меньшее число изменений необходимо применить при прокрутке вперед, чтобы восстановить файл к состоянию на момент сбоя, т.е. время, затрачиваемое на восстановление, сокращается.
В принципе, существуют более упрощенные методики резервного копирования, c использованием программных средств администрирования баз данных - копирования с помощью Oracle Enterprise Manager(OEM), но эти методики уступают по критерию надежности SQL*Plus’у.
Для более подробного ознакомления с процессами восстановления и копирования следует дополнительно ознакомиться с вопросом №10 Журнал повторения(redo log)
При запуске экземпляра базы данных выберите файл параметров для инициализации характеристик экземпляра, одним из следующих способов:
· введите имя файла параметров в поле Parameter File в диалоговом окне Start Up Instance
· укажите полное имя файла параметров в опции PFILE команды STARTUP
Спецификации имен файлов зависят от операционной системы. Если имя файла не указано, ORACLE использует умалчиваемое имя файла.
При запуске экземпляра базы данных специфицируйте имя базы данных, которая будет монтироваться, одним из следующих способов:
· введите имя базы данных в поле Database Name в диалоговом окне Start Up Instance
· укажите имя базы данных в команде STARTUP
Замки (latches) - это простые, низкоуровневые механизмы очередизации, которые защищают структуры разделяемых данных в SGA. Например, замки защищают список пользователей, обращающихся к базе данных в текущий момент, а также структуры данных, описывающие блоки в буферном кэше. Серверный или фоновый процесс получает замок на очень короткое время, пока он манипулирует или просматривает одну из таких структур. Реализация замков зависит от операционной системы, особенно в вопросе о том, ожидает ли процесс замка и сколь долго.
Для запуска базы данных или инстанции(экземпляр) используйте либо диалоговое окно Start Up Instance, либо команду STARTUP (после того, как соединитесь с ORACLE как INTERNAL). Вы можете запустить экземпляр и базу данных различными способами:
· запустить экземпляр без монтирования базы данных
· запустить экземпляр и смонтировать базу данных, но оставить ее закрытой
· запустить экземпляр, смонтировать и открыть базу данных в одном из следующих режимов:
Ø неограниченном режиме (доступна всем пользователям)
Ø ограниченном режиме RESTRICTED (доступна только АБД)
Кроме того, вы можете форсировать запуск экземпляра, либо заставить экземпляр начать немедленно после запуска полное восстановление носителя.
Прежде, чем запускать экземпляр, нужно подключиться как INTERNAL; также может понадобиться указать, для какой базы данных вы запускаете экземпляр, и специфицировать файл параметров.
Вы также должны подключиться как INTERNAL. Это условие обязательно, независимо от того, используете ли вы графический интерфейс SQL*DBA или команды SQL.
Можно запустить экземпляр без монтирования базы данных; обычно это требуется лишь при создании базы данных. Чтобы сделать это, используйте одну из следующих опций SQL*DBA:
· кнопку Nomount в диалоговом окне Start Up Instance
· команду STARTUP с опцией NOMOUNT
Вы можете запустить экземпляр с монтированием базы данных, но не открывать базу данных, чтобы выполнить специфические операции сопровождения. Например, база данных должна быть смонтирована, но не открыта, во время выполнения следующих задач:
· переименования файлов данных
· добавления, удаления или переименования файлов журнала
· включения и выключения опций архивирования журнала
· полного восстановления базы данных
Для запуска экземпляра и монтирования базы данных без ее открытия используйте одну из следующих опций SQL*DBA:
· кнопку Mount в диалоговом окне Start Up Instance
· команду STARTUP с опцией MOUNT
При использовании команды STARTUP с параметром NOMOUNT производится только запуск фоновых процессов Oracle и распределение SGA в памяти. В состоянии NOMOUNT базу данных может использовать только DBA. Опция NOMOUNT обычно используется только при создании базы данных.
Нормальная работа базы данных означает, что экземпляр запущен, а база данных смонтирована и открыта. Это позволяет всем действительным пользователям соединяться с базой данных и выполнять типичные операции, требующие доступа к данным. Для запуска экземпляра с монтированием базы данных и ее открытием используйте одну из следующих опций SQL*DBA:
· кнопку Open в диалоговом окне Start Up Instance
· команду STARTUP с опцией OPEN
Если вы знаете, что необходимо восстановление носителя, то вы можете запустить инстанцию так, чтобы она автоматически начала процесс восстановления, используя одну из следующих опций SQL*DBA:
· переключатель Recover в диалоговом окне Start Up Instance
· команду STARTUP с опцией RECOVER
В большинстве операционных систем вы можете запускать инстанцию ORACLE либо в однопроцессном, либо в многопроцессном режиме, независимо от того, как ORACLE был инсталлирован или запускался последний раз. Если компьютер, на котором выполняется сервер ORACLE, поддерживает многопроцессность, то инстанции баз данных обычно запускаются в многопроцессном режиме, так что много пользователей могут одновременно обращаться к разделяемой базе данных; однопроцессные же инстанции поддерживают лишь одного пользователя в каждый момент. Однако, в некоторых экспериментальных ситуациях, вы можете найти полезным запустить инстанцию в однопроцессном режиме. Некоторые операционные системы (такие как MS-DOS) не поддерживают многопроцессности или разделяемой памяти; в таких системах однопроцессная инстанция является единственной возможностью.
Если ваш локальный сервер ORACLE является частью распределенной базы данных, то вам может понадобиться запускать удаленную инстанцию и базу данных. Процедуры запуска и останова удаленных инстанций широко варьируются в зависимости от коммуникационного протокола и операционной системы.
Если ваш сервер ORACLE позволяет обращаться к одной базе данных из нескольких инстанций, то вы должны выбрать монтирование базы данных в монопольном или параллельном режимах.
Осуществляя отслеживание подозрительной деятельности в базе данных, защищайте целостность записей аудиторского журнала, чтобы гарантировать точность и полноту аудиторской информации. Чтобы защитить аудиторский журнал от несанкционированных удалений, назначайте системную привилегию DELETE ANY TABLE только администраторам защиты. Чтобы отслеживать изменения, выполняемые над самим аудиторским журналом, организуйте аудит аудиторского журнала с помощью следующего предложения:
AUDIT INSERT, UPDATE, DELETE
ON sys.aud$
BY ACCESS;
После выполнения утилита SQL*Loader создает журнал, содержащий подробную информацию о загрузке, включая, следующие сведения:
·
Имена фалов входных данных, управляющего файла, файлов некорректных записей и файлов отвергнутых записей.
· Входные данные и связанные с ними определения таблиц
· Ошибки SQL*Loader
· Результаты работы SQL*Loader
· Итоговую статистику
Каждая база данных ORACLE имеет набор из двух или более ФАЙЛОВ ЖУРНАЛА ПОВТОРЕНИЯ РАБОТЫ. Комплект файлов журнала повторения работы для одной базы данных совместно называется ЖУРНАЛОМ ПОВТОРЕНИЯ (redo log).
В базе данных Oracle имеется файлы двух типов:
· Файлы данных, сгруппированные в табличные пространства.
· Файлы данных, относящиеся к классу журнала повтора.
В базе данных как минимум должно быть не менее двух оперативных журналов повтора.
Журнал повтора часто называют журналом транзакций. Основная функция журнала повторения - регистрация всех изменений, осуществляемых в данных. Все изменения, выполняемые в базе данных, записываются в журнал повторения. Если в результате сбоя модифицированные данные не удастся постоянно записать в файлы данных, эти изменения можно получить из журнала повторения, так что результаты работ никогда не теряется, т.е. можно произвести не только восстановление старой копии БД, но и повторить все транзакции, выполненные к моменту сбоя.
Файлы журнала повторения критичны в вопросе защиты базы данных от сбоев. Чтобы защититься от таких сбоев, которые затрагивают сам журнал повторения, ORACLE допускает ЗЕРКАЛЬНЫЙ ЖУРНАЛ ПОВТОРЕНИЯ, так что две или более копий журнала повторения можно поддерживать одновременно на разных дисках.
Информация в файле журнала повторения используется только для восстановления базы данных после сбоя системы или носителя, в результате которого данные базы данных не могут быть записаны в файлы данных.
Процесс применения журнала повторения в процессе операции восстановления базы данных называется ПРОКРУТКОЙ ВПЕРЕД. База данных может работать в двух режимах. В режиме ARCHIVELOG и в режиме NOARCHIVELOG, соответственно либо, создается архивная копия всех журналов транзакций, либо содержимое транзакций не сохраняется. Для определения текущего режима работы экземпляра выдают команду archive log list, из под Server* Manager. Многие аспекты процесса архивирования указаны параметрами файла INIT.ORA Восстановление после сбоя экземпляра, с использование только журнала обновления, называется - оперативным восстановлением.