администрирование хранилища данных что это
Администратор баз данных
Основные задачи администратора базы данных
Основные типы администраторов БД
Ссылки
Полезное
Смотреть что такое «Администратор баз данных» в других словарях:
администратор банка данных — Человек, ответственный за состояние, развитие и использование баз данных организации либо предприятия. Администратор обеспечивает: работоспособность баз данных; полноту, правильность и целостность данных; необходимую защиту данных; взаимодействие … Справочник технического переводчика
Администратор — У этого термина существуют и другие значения, см. Администратор (значения). Об администраторах в Википедии смотрите страницу Википедия:Администраторы. Администратор (лат. administrator управитель) распорядитель в учреждении, коллективе, а также… … Википедия
Администратор (значения) — Об администраторах в Википедии смотрите страницу Википедия:Администраторы. Администратор человек, выполняющий какие либо административные (управляющие) действия или наделённый соответствующими полномочиями. Администратор в Римско католической… … Википедия
Администратор защиты — (Security administrator) это субъект доступа, ответственный за защиту автоматизированной системы от несанкционированного доступа к информации (по руководящему документу «Защита от несанкционированного доступа к информации: Термины и определения») … Википедия
Системный администратор — (англ. system administrator), ИТ администратор сотрудник, должностные обязанности которого подразумевают обеспечение штатной работы парка компьютерной техники, сети и программного обеспечения, а также обеспечение информационной… … Википедия
банк данных — БнД Автоматизированная ИПС, состоящая из одной или нескольких баз данных и системы хранения, обработки и поиска информации в них. [ГОСТ 7.73 96] банк данных Совокупность массивов информации длительного хранения данных в автоматизированной системе … Справочник технического переводчика
Администрирование данных — Администрирование данных управление информационными ресурсами, включая планирование базы данных, разработку и внедрение стандартов, определение ограничений и процедур, а также концептуальное и логическое проектирование баз данных.… … Википедия
Сертификаты Oracle — Корпорация Oracle проводит международную сертификацию специалистов в различных областях, связанных с технологиями Oracle. Сертификация специалистов Oracle обновляет сертификационные экзамены при появлении новых версий программных продуктов. Для… … Википедия
OS/2 — Warp Разработчик IBM, Microsoft Семейство ОС … Википедия
Warp4 — OS/2 Warp Разработчик Microsoft Семейство ОС OS/2 Исходный код Закрытый исходный код Последняя версия 4.52 декабрь 2001 Тип ядра модульное Интерфейс графический Л … Википедия
Администрирование хранилища данных что это
Создание групп онлайнового журнала
Транзакция (модуль фиксации) √ логический модуль, который состоит из набора изменений (вставок, обновлений и удалений). Транзакции либо должны быть сохранены в базе данных, либо должен быть выполнен их откат. Фиксируются либо все изменения в транзакции, либо ни одно из них. Для фиксирования в базе данных результатов транзакции используется команда COMMIT, для восстановления изменённых данных используется команда ROLLBACK.
Откат на уровне оператора √ данное понятие означает, что для конкретного оператора либо будут сохранены все внесённые им изменения, либо не будет выполнено ни одно из них.
В многопользовательской базе данных могут применяться два уровня блокировок:
Захват √ ситуация, которая возникает, когда два или более пользователей ожидают данных, заблокированных друг другом.
ORACLE автоматически распознает ситуации захватов, и автоматически разрешает такие ситуации, осуществляя откат одного из предложений, вовлеченных в захват и тем самым освобождая одно множество конфликтующих блокировок строк.
Многоверсионная модель согласованности данных.
DDL √ Data Definition Language √ язык содержащий набор операторов для определения данных.
DML √ Data Modifying Language √ язык содержащий набор операторов для модификации данных.
По умолчанию Oracle автоматически блокирует строки, на которые воздействуют операторы INSERT, UPDATE или DELETE; причём блокируются только те строки, на которые фактически оказано воздействие, а не вся таблица или весь блок данных.
Блокировки строк (TX)
Монопольная блокировка данных запрашивается для индивидуальной строки от имени транзакции, если эта строка модифицируется одним из следующих предложений: INSERT, UPDATE, DELETE или SELECT с фразой FOR UPDATE. Строка всегда блокируется монопольно, так что другие пользователи не могут модифицировать эту строку до тех пор, пока транзакция, удерживающая блокировку, не будет подтверждена или отменена. Блокировки строк всегда запрашиваются ORACLE автоматически как результат приведенных выше предложений.
Блокировки таблиц (TM)
Транзакция запрашивает блокировку таблицы, когда таблица модифицируется следующими предложениями: INSERT, UPDATE, DELETE, SELECT с фразой FOR UPDATE, либо блокируется предложением LOCK TABLE. Блокировка таблицы может удерживаться в одном из следующих режимов: разделяемая для строк (RS), монопольная для строк (RX), разделяемая для таблицы (S), разделяемая для строк монопольная (SRX) и монопольная(X). Степень ограничения доступа, налагаемая блокировкой, определяет, какие режимы блокировок по этой же таблице могут быть получены другими одновременными транзакциями.
Разделяемые для строк блокировки таблиц ( RS)
Эта блокировка указывает, что транзакция, удерживающая блокировку по таблице, блокировала строки в этой таблице и намерена обновить их. Эта блокировка автоматически запрашивается для ТАБЛИЦЫ, модифицируемой следующими предложениями:
LOCK TABLE таблица IN ROW SHARE MODE;
Блокировка RS, удерживаемая транзакцией, запрещает другим транзакциям получать монопольный доступ по записи к данной таблице, который запрашивается следующим предложением (и только им):
LOCK TABLE таблица IN EXCLUSIVE MODE;
Монопольные для строк блокировки таблиц (RX)
Эта блокировка обычно указывает, что транзакция, удерживающая блокировку по таблице, уже выполнила одно или несколько обновлений в строках таблицы. Эта блокировка автоматически запрашивается для ТАБЛИЦЫ, модифицируемой следующими предложениями:
Блокировка RX, удерживаемая транзакцией, запрещает другим транзакциям вручную блокировать таблицу для монопольного чтения или записи; поэтому другие транзакции не могут одновременно использовать следующие предложения:
Разделяемые блокировки таблиц (S)
Разделяемая блокировка таблицы, удерживаемая транзакцией, также запрещает другим транзакциям выполнять следующие предложения:
Разделяемые для строк монопольные блокировки таблиц (SRX)
Блокировка SRX, удерживаемая транзакцией, запрещает другим транзакциям получать блокировки SRX по этой таблице и модифицировать эту таблицу. Транзакция не может вставлять, обновлять или удалять строки в таблице, если какая-то другая транзакция имеет блокировку SRX по этой таблице. Блокировка SRX, удерживаемая транзакцией, также запрещает другим транзакциям получать блокировки SRX, S и RX по этой таблице; иными словами, другие транзакции не могут успешно выполнять следующие предложения:
Монопольные блокировки таблиц (X)
Эта блокировка вводит самый ограничительный режим, который обеспечивает транзакции, удерживающей эту блокировку по таблице, возможность монопольной записи в таблицу. Эта блокировка запрашивается для таблицы следующим предложением LOCK TABLE таблица IN EXCLUSIVE MODE;
Все блокировки данных, получаемые транзакцией, включая все блокировки строк и таблиц, освобождаются при подтверждении или откате этой транзакции. Блокировки данных, полученные после точки сохранения, освобождаются, если транзакция откатывается к этой точке сохранения.
Конверсия и эскалация блокировок данных
ORACLE автоматически конвертирует блокировку таблицы из более слабой в необходимую более строгую степень ограничений. Например, предположим, что транзакция использует предложение SELECT с фразой FOR UPDATE, чтобы заблокировать строки в таблице. Как следствие, она получает монопольные блокировки строк и разделяемую для строк блокировку таблицы. Если эта транзакция позднее обновляет одну или несколько заблокированных строк, блокировка таблицы автоматически конвертируется из режима RS в режим RX.
ORACLE никогда не прибегает к эскалации блокировок, когда СУБД автоматически заменяет многочисленные блокировки, полученные на одном уровне другой блокировкой на более высоком уровне.
Явные блокировки данных
Во всех случаях ORACLE автоматически осуществляет блокировки для обеспечения одновременного доступа, целостности и согласованности данных на уровне предложения. Однако имеются возможности, которые позволяют вам перекрывать умалчиваемые механизмы блокировок ORACLE. Такое перекрытие полезно в следующих ситуациях:
Защита в среде Oracle обеспечивается с помощью средств создания, изменения и уничтожения учётных записей пользователя базы данных Oracle (см. вопрос 15), а также с помощью привилегий (Grant, role), регулирующих возможность создавать и изменять объекты базы данных (см. вопрос 14).
Введение в словарь данных
Словарь данных структурирован через таблицы и представления, как и любые другие данные в базе данных. Для обращения к словарю данных вы используете SQL. Так как словарь данных можно только читать, пользователи могут выдавать лишь запросы (предложения SELECT) по таблицам и представлениям словаря данных.
Структура словаря данных
В состав словаря данных базы данных входят:
Основу словаря данных составляет совокупность базовых таблиц, хранящих информацию о базе данных. Эти таблицы читаются и пишутся ТОЛЬКО самим ORACLE; они редко используются непосредственно пользователем ORACLE любого типа, потому что они нормализованы, и большая часть данных в них закодирована.
Доступные пользователю представления
Словарь данных содержит доступные пользователю представления, которые суммируют и отображают, в удобном представлении формате информацию из базовых таблиц словаря. Эти представления декодируют информацию базовых таблиц, представляя ее в полезном виде, таком как имена пользователей или таблиц, и используют соединения и фразы WHERE, чтобы упростить информацию. Большинство пользователей имеют доступ к этим представлениям вместо базовых таблиц словаря.
Все базовые таблицы и представления словаря данных принадлежат пользователю ORACLE с учетным именем SYS. Поэтому ни один пользователь ORACLE не должен изменять никаких объектов, содержащихся в схеме SYS, а администратор безопасности должен строго контролировать использование этого центрального учетного имени.
Данные в базовых таблицах словаря данных необходимы для функционирования ORACLE. Поэтому только ORACLE должен записывать или изменять информацию словаря данных.
Во время операций по базе данных ORACLE читает словарь данных, чтобы удостовериться, что нужные объекты существуют, и что пользователи имеют к ним должный доступ. ORACLE также непрерывно обновляет словарь данных, чтобы отражать происходящие изменения в структурах базы данных, аудите, грантах и данных.
Вы можете добавлять в словарь данных новые таблицы или представления. Если вы добавляете новые объекты в словарь данных, их владельцем должен быть SYSTEM или какой-либо третий пользователь ORACLE. Когда включен режим аудита, эта таблица может неограниченно расти. Хотя пользователи не должны удалять эту таблицу, администратор безопасности может удалять из нее данные, потому что строки этой таблицы служат лишь для информации и не являются необходимыми для работы ORACLE.
Представления словаря данных выступают как справочники для всех пользователей базы данных. Доступ к этим представлениям осуществляется через SQL. Некоторые представления доступны всем пользователям, тогда как некоторые другие предназначены лишь для администраторов.
Словарь данных всегда доступен при открытой базе данных. Он размещается в табличном пространстве SYSTEM, которое всегда находится в состоянии онлайн, когда база данных открыта.
Словарь данных состоит из нескольких наборов представлений. Во многих случаях такой набор состоит из трех представлений, содержащих аналогичную информацию и отличающихся друг от друга своими префиксами:
обзор пользователя (что есть в схеме пользователя)
расширенный обзор пользователя (к чему есть доступ)
обзор администратора (к чему все пользователи имеют доступ)
Столбцы в каждом представление в наборе идентичны, со следующими исключениями:
Представления с префиксом USER:
Представления с префиксом ALL отражают общее представление о базе данных со стороны пользователя. Эти представления возвращают информацию об объектах, к которым пользователь имеет доступ через общие или явные гранты привилегий и ролей, помимо тех объектов, которыми владеет этот пользователь. Представления с префиксом DBA показывают общее представление о базе данных, так что они предназначены только для администраторов базы данных. Точнее, опрашивать представления словаря с префиксом DBA может любой пользователь, имеющий системную привилегию SELECT ANY TABLE.
Привилегии системного уровня.
Существует две основные группы привилегий системного уровня: имеющие в составе имён слово ANY и не имеющие его. Привилегии со словом ANY в имени позволяют пользователю
Привилегии системного уровня могут быть даны либо непосредственно пользователю Oracle, либо роли, которая будет назначена пользователю Oracle.
Если нужно будет дать привилегии системного уровня каждому пользователю Oracle (включая любых пользователей Oracle, которые могут быть созданы в будущем), можно дать системную привилегию пользователю PUBLIC, что означает любого пользователя Oracle.
Привилегии системного уровня могут быть также предоставлены пользователю Oracle с использованием WITH ADMIN OPTION в конце оператора GRANT. Это позволяет пользователю Oracle, получившему такую системную привилегию, передавать её любому другому пользователю Oracle. По сути дела он становится ещё одним администратором этой привилегии.
Для изъятия привилегии или роли системного уровня у пользователя Oracle, можно использовать команду REVOKE. Ею можно определить сразу несколько системных привилегий и имён пользователей.
На любые объекты, созданные в то время, когда действовала эта привилегия, её отмена не повлияет. Кроме того, если системная привилегия изъята у пользователя PUBLIC, не будет затронут другой пользователь, которому эта системная привилегия была предоставлена непосредственно.
Любой пользователь предоставивший системную привилегию посредством WITH ADMIN OPTION, может предоставить эту системную привилегию другому пользователю Oracle √ он, по сути дела, является дополнительным администратором этой системной привилегии.
Привилегии объектного уровня.
Если пользователь Oracle владеет объектом наподобие таблицы, другим пользователям Oracle может быть разрешено использовать этот объект путём предоставления им одной или нескольких привилегий объектного уровня. Например, если пользователь user_1 намеревается позволить пользователю user_2 использовать его таблицу, но только для вставки и обновления строк с помощью команд INSERT или UPDATE, то пользователю user_2 могут быть даны привилегии UPDATE и INSERT.
В конце оператора GRANT для привилегии объектного уровня может быть определена фраза WITH GRANT OPTION, которая позволяет пользователю Oracle получившему эту привилегию, передать её другому пользователю Oracle.
Имеется ряд представлений словаря данных, которые показывают, какие привилегии объектного уровня были даны непосредственно пользователю и какие привилегии были предоставлены ему другими пользователями:
Представления словаря данных, начинающиеся с ALL_ и DBA_.
Роль (role) √ совокупность системных привилегий и привилегий объектного уровня, которые были сгруппированы под одним именем, чтобы облегчить предоставление и отмену этих привилегий. Когда пользователю даётся роль, он получает все привилегии, связанные с ней.
Если пользователь Oracle удалён из базы данных командой DROP USER, можно сохранить присвоенные ему привилегии, если эти привилегии были назначены посредством роли. Затем можно переназначить эти привилегии любому новому пользователю. Если привилегии первоначально не были назначены посредством роли, то при уничтожении первого пользователя будет потеряна вся относящаяся к нему информация.
С помощью ролей можно расширять и сужать набор привилегий, назначенных пользователю, разрешая и запрещая роли.
Новой роли могут быть назначены привилегии уже существующей роли (роль более высокого уровня наследует все привилегии роли более низкого уровня).
Как только пользователю Oracle был дан набор ролей, предусмотренные ими привилегии могут включаться и выключаться (обычно прикладными программами) посредством разрешения и запрещения ролей.
Вместе с новой базой данных автоматически создаются пять ролей. Это √ CONNECT, RESOURCE, DBA, EXP_FULL_DATABASE и IMP_FULL_DATABASE. Первые три предусмотрены для совместимости с предыдущими версиями программного обеспечения Oracle и обычно не требуются.
Центральное место в средствах защиты занимает учётная запись пользователя базы данных 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 для автоматического уничтожения всех объектов при удалении учётной записи пользователя.
Словарь данных каждой базы данных содержит таблицу с именем SUS.AUD$, обычно называемую АУДИТОРСКИМ ЖУРНАЛОМ базы данных. Аудиторские записи, генерируемые как результат отслеживания предложений, привилегий или объектов, можно помещать как в аудиторскую таблицу базы данных, так и в аудиторский журнал операционной системы. Использование аудиторского журнала дает возможность просматривать выбранные порции аудиторского журнала с помощью предопределенных представлений словаря данных, а также использовать инструменты ORACLE, такие как SQL*ReportWriter, для генерации аудиторских отчетов.
Использование аудиторского журнала операционной системы помогает консолидировать аудиторские записи из многих источников, включая ORACLE и другие приложения. Поэтому исследование активности системы может быть более эффективным, так как аудиторские записи сосредоточены в одном месте.
все опции аудита генерируют следующую общую информацию:
Аудиторский журнал не сохраняет информации о каких-либо значениях данных, которые могли быть вовлечены в отслеживаемое предложение; например, при аудите предложения UPDATE не сохраняются старые и новые значения данных. Однако, такой специализированный тип аудита можно осуществить для предложений DML, работающих с таблицами, с помощью триггеров базы данных.
ORACLE позволяет устанавливать опции аудита на трех уровнях:
Для удобства спецификации часто встречающихся групп связанных опций аудита предоставляются специальные обозначения. Эти обозначения сами не являются опциями; они просто позволяют указать одним словом целую группу опций в предложении AUDIT или NOAUDIT.
Любой пользователь базы данных ORACLE может в любой момент установить опции аудита предложений, привилегий или объектов, но ORACLE не генерирует аудиторских записей и не помещает их в аудиторский журнал, если не включен режим аудита базы данных. Обычно за эту операцию отвечает администратор. Аудит базы данных включается и выключается параметром инициализации AUDIT_TRAIL в файле параметров базы данных. Этот параметр может быть установлен в следующие значения:
Администратор защиты обязан контролировать рост аудиторского журнала и его размер. Когда аудит включен и генерируются аудиторские записи, аудиторский журнал растет за счет двух факторов:
Для контроля за ростом аудиторского журнала вы можете использовать следующие методы:
DELETE FROM sys.aud$;
Если информация аудиторского журнала должна архивироваться для целей накопления истории, администратор защиты может скопировать соответствующие записи в нормальную таблицу базы данных или экспортировать аудиторскую таблицу в файл операционной системы. Удалять записи из аудиторского журнала базы данных может лишь пользователь SYS, т.е. пользователь, имеющий привилегию DELETE ANY TABLE (или пользователь, которому SYS передал привилегию DELETE по таблице SYS.AUD$).
Как и в любой таблице базы данных, после удаления записей из аудиторского журнала базы данных все экстенты, которые были распределены этой таблице, будут по-прежнему существовать. Если аудиторский журнал имеет слишком много экстентов, большинство из которых не используются, то можно уменьшить размер этого журнала, выполнив следующие шаги:
Осуществляя отслеживание подозрительной деятельности в базе данных, защищайте целостность записей аудиторского журнала, чтобы гарантировать точность и полноту аудиторской информации. Чтобы защитить аудиторский журнал от несанкционированных удалений, назначайте системную привилегию DELETE ANY TABLE только администраторам защиты. Чтобы отслеживать изменения, выполняемые над самим аудиторским журналом, организуйте аудит аудиторского журнала с помощью следующего предложения:
AUDIT INSERT, UPDATE, DELETE
Вы можете использовать триггеры, чтобы дополнить встроенные средства аудита ORACLE. Хотя вы можете писать триггеры, которые регистрировали бы информацию, аналогичную той, которую генерирует команда AUDIT, старайтесь использовать триггеры лишь в том случае, когда вам необходима более детальная аудиторская информация. Например, с помощью триггеров вы можете отслеживать изменения значений по строкам таблицы.
Целостность данных определением правил проверки достоверности данных гарантирующих, что недействительные данные не попадут в ваши таблицы. Oracle позволяет определять и хранить эти правила для объектов БД, которых они касаются, таким образом, чтобы кодировать их только однажды. При этом они активируются всякий раз, когда какой-либо вид изменение проводится в таблице, независимо от того, какая программа выполняет вставки, модификации или удаления. Этот контроль осуществляется в форме ограничений и триггеров БД. Ограничения √ это правила, применимые к таблицам во временя или после создания, распространяемые на то, как эти таблицы могут заполняться.
Ограничение целостности устанавливает правила на уровне БД, определяя набор проверок для таблиц системы. Эти проверки автоматически выполняются всякий раз, когда вызывается оператор вставки, модификации или удаления данных в таблице. Если какие либо ограничения нарушены, операторы отменяются. Поскольку ограничения условности проверяются на уровне БД, они выполняются независимо от того, откуда были инициированы операторы вставки, модификации или удаления. Для таблиц можно задавать следующие типы ограничений целостности:
NOT NULL. Это ограничение устанавливается для столбца, чтобы указать, что столбец должен иметь значение в каждой строке, т.е. некоторое непустое значение.
UNIQUE (уникальный). Ограничение UNIQUE используется для определения того, что значения в столбце не должно повторяться в другой строке этой таблицы, определяет вторичный ключ для таблицы. Это столбец или группа столбцов, которые можно использовать как уникальную идентификацию строки. Никакие две строки не могут иметь одинаковые значения для столбца или столбцов ключа UNIQUE. Столбцы для ограничения UNIQUE не обязательно NOT NULL. Можно сформировать ограничение таблицы, указав, что в таблице не должна повторяться комбинация столбцов. К примеру: можно в начале объявить стандартно emp_id number(5), person_id date а под конце объявить что: unique(emp_id, person_id) √ и получиться, что сочетание значений этих полей, должно быть уникальным в каждой строке.
CHECK. Ограничение CHECK определяет логику проверки, которая должна жать результат true (истина) для оператора вставки, модификации или удаления из таблицы. Ограничение CHECK гарантирует, что значение в измененной строке удовлетворяют заданному набору проверок правильности.
TRRIGERS (Триггеры) √ с программный элемент хранимый в БД выполняемый автоматически, в определенных ситуациях, не имеющий входных или выходных параметров, что в конечном итоги и является причиной невозможности вызвать его явно, непосредственно, его вызывает только сама база данных Oracle. Выходные данные триггера должны быть также применимы к БД, а не возвращены вызывающей программе или отображены на экране. Процедуры и функции расписаны в вопросе Й 6.Схемы и объекты схемы
Таким образом, целостность базы данных может быть рассмотрена на трех уровнях :
При создании базы данных необходимо подготовить несколько файлов данных операционной системы, которые будут использоваться вместе как единая база данных. База данных создается один раз, независимо от того, сколько файлов данных она имеет, и сколько экземпляров будут обращаться к ней. Процедуру создания базы данных можно также использовать для того, чтобы стереть информацию в существующей базе данных и создать новую базу данных с тем же именем и физической структурой.
Создание базы данных включает следующие операции:
База данных создается с помощью предложения, включающего команду SQL CREATE DATABASE; однако, прежде чем выдавать такое предложение, рассмотрите следующие вопросы:
Для создания новой базы данных вы должны иметь:
Для создания каждой новой базы данных ORACLE необходимо последовательно выполнить следующие шаги:
Для запуска базы данных или инстанции(экземпляр) используйте либо диалоговое окно Start Up Instance, либо команду STARTUP (после того, как соединитесь с ORACLE как INTERNAL). Вы можете запустить экземпляр и базу данных различными способами:
Кроме того, вы можете форсировать запуск экземпляра, либо заставить экземпляр начать немедленно после запуска полное восстановление носителя.
Прежде, чем запускать экземпляр, нужно подключиться как INTERNAL; также может понадобиться указать, для какой базы данных вы запускаете экземпляр, и специфицировать файл параметров.
Вы также должны подключиться как INTERNAL. Это условие обязательно, независимо от того, используете ли вы графический интерфейс SQL*DBA или команды SQL.
Запуск экземпляра без монтирования базы данных
Можно запустить экземпляр без монтирования базы данных; обычно это требуется лишь при создании базы данных. Чтобы сделать это, используйте одну из следующих опций SQL*DBA:
Вы можете запустить экземпляр с монтированием базы данных, но не открывать базу данных, чтобы выполнить специфические операции сопровождения. Например, база данных должна быть смонтирована, но не открыта, во время выполнения следующих задач:
Для запуска экземпляра и монтирования базы данных без ее открытия используйте одну из следующих опций SQL*DBA:
Нормальная работа базы данных означает, что экземпляр запущен, а база данных смонтирована и открыта. Это позволяет всем действительным пользователям соединяться с базой данных и выполнять типичные операции, требующие доступа к данным. Для запуска экземпляра с монтированием базы данных и ее открытием используйте одну из следующих опций SQL*DBA:
При запуске экземпляра базы данных специфицируйте имя базы данных, которая будет монтироваться, одним из следующих способов:
При запуске экземпляра базы данных выберите файл параметров для инициализации характеристик экземпляра, одним из следующих способов:
Спецификации имен файлов зависят от операционной системы. Если имя файла не указано, ORACLE использует умалчиваемое имя файла.
Форсированный запуск, описанный ниже, следует применять ТОЛЬКО в следующих случаях:
Если вы попали в такую ситуацию, обычно удается решить проблему путем запуска нового экземпляра в форсированном режиме, используя одну из следующих опций SQL*DBA:
Эти опции в действительности сначала останавливают текущую инстанцию, а затем запускают новую инстанцию (возможно, с монтированием и открытием базы данных).
Если вы знаете, что необходимо восстановление носителя, то вы можете запустить инстанцию так, чтобы она автоматически начала процесс восстановления, используя одну из следующих опций SQL*DBA:
Если ваш сервер ORACLE позволяет обращаться к одной базе данных из нескольких инстанций, то вы должны выбрать монтирование базы данных в монопольном или параллельном режимах.
На многих установках одна или несколько инстанций и баз данных ORACLE автоматически запускаются вслед за загрузкой ОС. Процедуры, позволяющие организовать такой режим, специфичны для каждой операционной системы.
Если ваш локальный сервер ORACLE является частью распределенной базы данных, то вам может понадобиться запускать удаленную инстанцию и базу данных. Процедуры запуска и останова удаленных инстанций широко варьируются в зависимости от коммуникационного протокола и операционной системы.
Чтобы инициировать останов базы данных, используйте либо меню Shut Down, либо команду SHUTDOWN в SQL*DBA.
Нормальный останов базы данных протекает следующим образом:
Для останова базы данных в нормальных обстоятельствах используйте одну из следующих опций SQL*DBA:
В чрезвычайных обстоятельствах вы можете остановить базу данных немедленно. Используйте этот способ останова лишь в случаях, подобных следующим:
Для немедленного останова базы данных используйте одну из следующих опций SQL*DBA:
Эта секция приводит примеры останова базы данных и инстанции через интерфейс меню и команды SQL*DBA. Во всех примерах предполагается, что АБД уже подключен как INTERNAL.
Меню Shut Down останавливает базу данных.
Команда SHUTDOWN эквивалентна меню Shut Down. Например, следующее предложение является командным эквивалентом меню Shut Down.
Запуск однопроцессных и многопроцессных инстанций
В большинстве операционных систем вы можете запускать инстанцию ORACLE либо в однопроцессном, либо в многопроцессном режиме, независимо от того, как ORACLE был инсталлирован или запускался последний раз. Если компьютер, на котором выполняется сервер ORACLE, поддерживает многопроцессность, то инстанции баз данных обычно запускаются в многопроцессном режиме, так что много пользователей могут одновременно обращаться к разделяемой базе данных; однопроцессные же инстанции поддерживают лишь одного пользователя в каждый момент. Однако, в некоторых экспериментальных ситуациях, вы можете найти полезным запустить инстанцию в однопроцессном режиме. Некоторые операционные системы (такие как MS-DOS) не поддерживают многопроцессности или разделяемой памяти; в таких системах однопроцессная инстанция является единственной возможностью.
Если над базой данных производят любое из ниже перечисленных структурных изменений, базы данных, непосредственно перед изменениями и после делается соответствующее копирование базы данных:
Существует, по большому счету, два вида резервного копирования :
Сопоставление режима ARCHIVELOG и режима NOARCHIVELOG
В режиме ARCHIVELOG:
В режиме NOARCHIVELOG:
Вы устанавливаете первоначальный режим архивирования базы данных во время ее создания. В большинстве случаев, во время создания базы данных вы можете выбрать режим по умолчанию NOARCHIVELOG, потому что нет необходимости архивировать информацию, генерируемую за этот период. После того как база данных создана, решите, нужно ли изменить первоначальный режим архивирования. После того, как база данных создана, всегда можно переключать режим архивирования базы данных. Однако, как правило, следует выбрать постоянный режим работы базы данных.
Чтобы автоматическое архивирование заполненных групп было включено установите в TRUE значение параметра LOG_ARCHIVE_START в файле параметров базы данных INIT.ORA:
LOG_ARCHIVE_START = TRUE Это значение будет иметь эффект при очередном запуске базы данных.
Вы можете выключить автоматическое архивирование журнала в любой момент. Однако, выключив автоматическое архивирование, вы должны вручную, периодически и своевременно, архивировать заполняемые группы журнала. Если база данных работает в режиме ARCHIVELOG, автоматическое архивирование выключено, а группы журнала заполняются, но не архивируются, то процесс LGWR не сможет повторно использовать неактивные группы журнала, чтобы продолжать запись информации повторения. Поэтому работа базы данных будет временно приостановлена до тех пор, пока не будет выполнено необходимое архивирование. Автоматическое архивирование может быть выключено как до, так и после запуска инстанции.
Для более подробного ознакомления с процессами восстановления и копирования следует дополнительно ознакомиться с вопросом Й10 Журнал повторения( redo log)
Динамический SQL в Oracle
Описанный в стандарте SQL набор операторов SQL предназначен для встраивания в программу на обычном языке программирования. Поэтому в этом наборе перемешаны операторы «истинного » реляционного языка запросов (например оператор удаления из таблицы части строк, удовлетворяющих заданному условию) и операторы работы с курсорами, позволяющими обеспечить построчный доступ к таблице-результату запроса.
В диалоговом режиме набор операторов SQL и их синтаксис должен быть несколько другим. Весь вопрос состоит в том, как реализовывать такую диалоговую программу. Правила встраивания стандартного SQL в программу на обычном языке программирования предусматривают, что вся информация, касающаяся операторов SQL, известна (за исключением значений переменных, используемых в качестве констант в операторах SQL). Не предусмотрены стандартные средства компиляции с последующим выполнением операторов, которые становятся известными только во время выполнения. Поэтому, опираясь только на стандарт, невозможно реализовать диалоговый монитор взаимодействия с БД на языке SQL или другую прикладную программу, в которой текст операторов SQL возникает во время выполнения, т. е. фактически так или иначе стандарт необходимо расширять.
Один из возможных путей расширения состоит в использовании специальной группы операторов, обеспечивающих динамическую компиляцию (во время выполнения прикладной программы) базового подмножества операторов SQL и поддерживающих их корректное выполнение. В дополнительный набор операторов, поддерживающих динамическую компиляцию базовых операторов SQL, входят операторы: PREPARE, DESCRIBE и EXECUTE.
Во время выполнения оператора PREPARE символьная строка, содержащаяся в host-string-variable, передается компилятору SQL, который обрабатывает таким же образом, как если бы получил в статике. Построенный при выполнении оператора PREPARE код остается действующим до конца транзакции или до повторного выполнения данного оператора PREPARE в пределах этой же транзакции.
Оператор получения описания подготовленного оператора
Оператор DESCRIBE предназначен для того, чтобы определить тип ранее подготовленного оператора, узнать количество и типы формальных параметров(если они есть) и количество и типы столбцов результирующей таблицы, если подготовленный оператор является оператором выборки (SELECT). Действие оператора DESCRIBE состоит в том, что в указанную область памяти прикладной программы (структура этой области фиксирована и известна пользователям)помещается информация, характеризующая ранее подготовленный оператор с заданным именем.
Оператор выполнения подготовленного оператора
Оператор EXECUTE служит для выполнения ранее подготовленного оператора SQL типа «N» (не требующего применения курсора) или для совмещенной подготовки и выполнения такого оператора.
Для выполнения подготовленного оператора служит первый вариант оператора EXECUTE. Число и типы фактических параметров должны соответствовать числу и типам формальных параметров подготовленного оператора.
Работа с динамическими операторами SQL через курсоры
Для использования таких операторов используется расширение механизма курсоров стандарта SQL. Во-первых, при определении курсора можно указывать не только литеральную спецификацию курсора, но и имя оператора, вводимое с помощью оператора PREPARE (в этом случае оператор PREPARE должен текстуально находиться выше оператора DECLARE). Тем самым полный синтаксис оператора DECLARE становится следующим:
Далее, поскольку для такого курсора в статике неизвестна информация о входных и выходных переменных включающей программы, то используется другая форма операторов OPEN и FETCH.
Полный синтаксис этих операторов становится следующим:
Как видно, предлагается два способа задания фактических входных и выходных параметров: прямое с указанием в операторах OPEN и/или FETCH списков имен переменных включающей программы и косвенное, когда число параметров и их адреса сообщаются через дополнительную структуру-дескриптор.
Первый способ предлагается использовать для работы с операторами выборки, для которых фиксирован набор формальных входных и выходных параметров.
Второй способ работы с динамически откомпилированными операторами, требующими использования курсоров, состоит в использовании дескрипторов динамически формируемых списков параметров.
Направление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно. Публикации появлялись уже в середине 1980-х. Однако наиболее активно это направление развивается в последние годы. С каждым годом увеличивается число публикаций и реализованных коммерческих и экспериментальных систем.
Общие понятия объектно-ориентированного подхода и их преломление в ООБД
В наиболее общей и классической постановке объектно-ориентированный подход базируется на концепциях:
Любая сущность реального мира в объектно-ориентированных языках и системах моделируется в виде объекта. Любой объект при своем создании получает генерируемый системой уникальный идентификатор, который связан с объектом во все время его существования и не меняется при изменении состояния объекта.
Объектно-ориентированные модели данных
В модели ООБД поддерживается множественное наследование классов на основе отношения супертип/подтип. В подклассе допускается добавление и/или переопределение атрибутов и методов. Возможные при множественном наследовании двусмысленности (по именованию атрибутов и методов) разрешаются либо путем переименования, либо путем явного указания источника наследования. Объект подкласса является объектом каждого суперкласса, на основе которого порожден данный подкласс.
Специфической особенностью модели ООБД является возможность объявления дополнительных «исключительных» атрибутов и методов для именованных объектов. Это означает, что конкретный именованный объект-представитель класса может обладать типом, являющимся подтипом типа класса. Конечно, с такими атрибутами не работают стандартные методы класса, но специально для именованного объекта могут быть определены дополнительные (или переопределены стандартные) методы, для которых дополнительные атрибуты уже доступны. Подчеркивается, что дополнительные атрибуты и методы привязываются не к конкретному объекту, а к имени, за которым в разные моменты времени могут стоять вообще говоря разные объекты.