Создание базы данных Oracle

Как создать базу OracleБазу данных Oracle можно создать в ходе процесса установки как в Windows, так и в UNIX-версиях. Универсальный инсталлятор Oracle предлагает несколько шаблонов для создания баз данных, в том числе шаблоны системы принятия решений (decision-support system — DSS) и оперативной обработки транзакций (online transaction processing — OLTP). Для создания базы данных можно вызвать также помощник по конфигурированию базы данных (Oracle Database Configuration Assistant — DBCA), который представляет собой средство с графическим интерфейсом пользователя, помогающее выполнять инсталляцию.


Оглавление статьи[Показать]


Однако до тех пор, пока вы не освоите создание баз данных, возможно, лучше ограничиться применением трудоемкого, но более гибкого режима создания БД вручную. Рекомендуется вручную вводить SQL-операторы создания базы данных, строку за строкой, из сеанса SQL*Plus. Это позволит получить представление о различных действиях по созданию базы данных и потенциальных проблемах на каждом из этапов. Впоследствии, когда вы освоитесь с этим процессом, можно будет просто поместить все команды в сценарий и запускать его для создания других баз данных, либо же просто прибегнуть к услугам DBCA.

Прежде чем приступить к созданию базы данных Oracle, необходимо выполнить ряд действий: убедиться в наличии необходимых прав доступа, проверить существовании требуемых файловых структур и определить наличие достаточного объема ресурсов для запуска новой базы данных. Затем потребуется установить параметры инициализации БД. В этой статье освещены все эти вопросы и приведен обобщенный обзор важных параметров конфигурации (инициализации) с рекомендациями по их использованию в базе данных Oracle.

После создания базы данных Oracle понадобится выполнить дополнительные задачи, также описанные в этой статье: запустить необходимые сценарии, изменить пароли и сконфигурировать базу данных для ведения журнала архивирования. Вам предстоит ознакомиться с различными режимами, в которых можно запускать экземпляр Oracle, а также научиться останавливать его в различных режимах и при необходимости ограничивать доступ к базе данных, предоставляя его только администраторам БД. Для полноты картины мы рассмотрим перевод базы данных в пассивное состояние и ее приостановку, что потребуется для эффективного управления базами данных, а также рассмотрим удаление БД Oracle с помощью команды DROP DATABASE.

 

Подготовка к созданию базы данных Oracle

Новую базу данных можно создать либо вручную (используя сценарии), либо с помощью Oracle DBCA. Помощник DBCA сконфигурирован так, чтобы открываться немедленно после инсталляции программного обеспечения (ПО) Oracle для облегчения создания базы данных. Его можно также вызвать позднее.

Создается база данных вручную или автоматически программным обеспечением Oracle во время его установки, все сведения о конфигурации базы данных помещаются в файл конфигурации init.ora или в его более новый эквивалент SPFILE. По завершении создания базы данных ее поведения всегда можно изменить, изменяя параметры инициализации. Поведение базы данных можно изменять также на краткие периоды времени или для определенных сеансов, используя команды ALTER SYSTEM и ALTER SESSION для изменения значений определенных параметров инициализации.

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

 

Инсталляция программного обеспечения Oracle

Прежде чем создавать базу данных, вначале нужно инсталлировать ПО Oracle Database 11g. Если это еще не сделано, обратитесь к этой статье, в которой освещена установка ПО сервера Oracle в системах UNIX и Linux.

 

Создание файловой системы для базы данных

Планирование файловых систем — важная задача, и ее нужно завершить до начала создания базы данных. Перед созданием базы данных необходимо спланировать размещение различных файлов БД, таких как файлы журналов повторного выполнения и архивные файлы журналов; их размещение оказывает серьезное влияние на общую производительность во время эксплуатации. Рассмотрим вопросы определения размеров и размещения файлов более подробно.

Определение размеров файловой системы

Объем необходимого дискового пространства для файловой системы в первую очередь зависит от общего объема дискового пространства, которое требуется выделить для файлов данных Oracle. Файлы данных используются для создания табличных пространств System и Sysaux, табличного пространства отката, используемого по умолчанию постоянного табличного пространства, журналов повторного выполнения и файлов для хранения данных приложений (таблиц и индексов). Общая оценка необходимого дискового пространства должна предусматривать дисковое пространство для следующих компонентов.

  • Таблицы и индексы. Данные таблиц и индексов — наибольший компонент физической базы данных. Вначале необходимо оценить размер всех таблиц, исходя из количества и ширины столбцов и ожидаемого числа строк в каждой таблице. Эта оценка не должна быть абсолютно точной. Достаточно будет и приближенных значений. Необходимо знать, какие индексы требуются для приложения. Нужно также знать типы индексов, которые предстоит создать, поскольку это может оказать решающее влияние на их физические размеры. Для определения дискового пространства, требуемого для индексов, можно применять соответствующие формулы.
  • Табличное пространство отката. Объем дискового пространства, которое необходимо выделить для табличного пространства отката, зависит от размера базы данных и природы выполняемых транзакций. Если предполагается выполнение множества больших транзакций или планируется выполнение больших пакетных заданий, понадобится достаточно большое табличное пространство отката. Впоследствии то пространство всегда можно увеличить, добавляя в него файлы данных.
  • Временное табличное пространство. Размер временного табличного пространства также зависит от природы приложения и характера транзакций. Если запросы требуют выполнения множества операций сортировки, в общем случае лучше начинать с большего временного табличного пространства. Обратите внимание, что временное табличное пространство создается явно во время создания базы данных и назначения его пользователям базы данных в качестве используемого по умолчанию временного табличного пространства.
  • Используемое по умолчанию постоянное табличное пространство. Базе данных целесообразно назначить используемое по умолчанию постоянное табличное пространство. Используемое по умолчанию постоянное табличное пространство автоматически назначается всем пользователям базы данных.
  • Табличные пространства System и Sysaux. Оба табличных пространства System и Sysaux являются обязательными табличными пространствами, используемыми базой данных для хранения информации словаря хранилища данных и объектов, которые относятся к различным схемам Oracle.
  • Файлы журналов повторного выполнения. Файлы журналов повторного выполнения чрезвычайно важны для функционирования базы данных, и они являются основными компонентами при попытке восстановления базы данных без потери зафиксированных данных. Oracle рекомендует использование как минимум двух групп журналов повторного выполнения (каждая из которых состоит из одного или более членов). Файлы журналов повторного выполнения должны быть мультиплексированными — т. е. в каждой группе должно существовать более одного файла журнала повторного выполнения, поскольку они являются критичной частью базы данных и представляют единственную ненадежную точку. При наличии мультиплексированных журналов повторного выполнения экземпляр будет продолжать работать даже при ошибочном удалении или повреждении одной копии файла журнала повторного выполнения.

Требуемый размер файла журнала повторного выполнения будет зависеть от скорости внесения записей базы данных в журнал. При выполнении множества операций DML и очень быстром заполнении журналов повторного выполнения может потребоваться увеличить размеры журнальных файлов. (Размер существующего файла журнала повторного выполнения нельзя увеличить, но можно создать файлы большего размера и удалить меньшие файлы.) Запись файлов журналов повторного выполнения выполняется циклически, и их размеры нужно установить такими, чтобы в течение часа заполнялось не более двух-трех файлов. В данном случае основное противоречие возникает между производительностью и временем восстановления. Очень большой файл журнала повторного выполнения будет весьма эффективным, поскольку в этом случае будет требоваться мало переключений с одного журнала на другой и соответствующих контрольных точек, которые связаны с накладными расходами на базу данных. Однако при выполнении восстановления большие журналы повторного выполнения ведут к увеличению времени восстановления, поскольку приходится восстанавливать больший объем данных.

Представление об оптимальном размере файла журнала повторного выполнения можно получить, просматривая столбец OPTIMAL_LOGFILE_SIZE представления V$INSTANCE_RECOVERY после того, как база данных проработала в течение некоторого времени. Еще более простой способ получения рекомендаций по размеру файла журнала повторного выполнения — просмотр страницы Redo Log Groups (Группы журналов повторного выполнения) в Oracle Enterprise Manager (OEM) Database Control.


На заметку! В Oracle рекомендуют использовать четыре группы журналов повторного выполнения, чтобы программе записи журналов не приходилось дожидаться освобождения доступной группы при каждом переключении с одного журнала на другой. Члены групп журналов повторного выполнения (файлы журналов повторного выполнения) должны иметь одинаковый размер. Oracle предлагает устанавливать размеры файлов журналов повторного выполнения такими, чтобы при большой нагрузке переключение происходило каждые 20 минут, а при нормальных нагрузках — один раз в час.


Область пакетного восстановления. В Oracle рекомендуют создать область пакетного восстановления для хранения всех файлов, связанных с резервным копированием и восстановлением, которые необходимы для восстановления в случае отказа носителя. Область пакетного восстановления содержит все резервные копии файлов данных, резервные копии диспетчера восстановления ( Recovery Manager — RMAN), журналы пакетного резервного копирования, архивные файлы журналов повторного выполнения и резервные копии управляющих файлов. Размер области пакетного восстановления зависит от объема и частоты резервного копирования, а также предполагаемой продолжительности сохранения резервных копий на диске. Например, если резервное копирование предполагается выполнять еженедельно, для области пакетного восстановления нужно выделить дисковое пространство для хранения полных резервных копий за одну неделю и архивных журналов повторного выполнения. Если между получением еженедельных полных резервных копий предполагается выполнять инкрементное резервное копирование, в области пакетного восстановления потребуется выделить пространство и для этих инкрементных копий.

Выбор местоположения для файлов

Файлы базы данных нужно помещать в соответствии с рекомендациями оптимальной гибкой архитектуры (Optimal Flexible Architecture — OFA). Следование рекомендациям OFA по размещению файлов базы данных обеспечивает следующие преимущества.

  • Облегчение обнаружения и идентификации различных файлов, таких как файлы базы данных, управляющие файлы и файлы журналов повторного выполнения.
  • Облегчение администрирование нескольких баз данных Oracle и нескольких версий ПО Oracle.
  • Повышение производительности базы данных за счет минимизации конкуренции между различными типами файлов.

Следование рекомендациям OFA должно обеспечить хорошие условия в смысле способа физического размещения файлов.

 

Обеспечение выделения достаточного объема памяти

Если система не располагает достаточным объемом памяти для удовлетворения требований, предъявляемых базой данных, запуск экземпляра БД окажется невозможным. Даже если его удастся запустить, в ходе работы будет выполняться множество операций страничного обмена и подкачки между памятью и диском, что замедлит работу базы данных.

В наши дни стоимость модулей памяти столь незначительна в сравнении с общими затратами предприятия на компьютерное оборудование, что имеет смысл устанавливать как можно больший объем памяти на сервере, на котором планируется установка базы данных Oracle. В среде Oracle Database 11g можно использовать новый параметр инициализации MEMORY_TARGET, чтобы полностью автоматизировать выделение памяти для экземпляра БД Oracle.

 

Получение необходимых полномочий

Чтобы иметь возможность создания файловых систем на сервере, потребуется получение соответствующих полномочий от системного администратора UNIX/Linux. Если работа выполняется на сервере UNIX или Linux, ваше имя пользователя Oracle должно быть включено системным администратором в группу DBA.

 

Настройка переменных среды операционной системы

Прежде чем приступать к созданию базы данных, нужно установить все необходимые переменные среды операционной системы. В системах UNIX и Linux потребуется установить следующие переменные среды.

  • ORACLE_SID. Имя базы данных, которое совпадает со значением параметра инициализации DB_NAME.
  • ORACLE_BASE. Каталог высшего уровня для размещения программного обеспечения Oracle. В нашем случае им является /u01/app/oracle. В настоящее время переменная ORACLE_BASE является рекомендуемой, но в будущей версии компания Oracle намерена сделать ее обязательной.
  • ORACLE_HOME. Каталог, в котором установлено программное обеспечения Oracle. В Oracle рекомендуют использовать следующий формат для этой переменной: $ORACLE_BASE/product/release/db_n. В этой статье в качестве этого каталога использован каталог /u01/app/oracle/product/11.1.0.0/db_1.
  • PATH. Каталог для хранения исполняемых файлов Oracle. Исполняемые файлы Oracle всегда размещаются в каталоге $ORACLE_HOME/bin. В существующее значение переменной PATH местоположение исполняемых файлов Oracle можно добавить следующим образом: 
$  export PATH=$PATH:$ORACLE_HOME/bin 
  • LD_LIBRARY_PATH. Эта переменная указывает расположение библиотек Oracle. Обычным расположением является каталог $ORACLE_HOME/lib.

 

Создание файла параметров

Каждый экземпляр Oracle использует набор параметров инициализации, которые накладывают на базу данных такие ограничения, как количество пользователей, указывают имена и местоположения основных файлов и каталогов, а также оптимизируют производительность за счет определения размеров основных ресурсов наподобие памяти. Прежде чем приступать к рассмотрению нюансов создания базы данных Oracle, важно ознакомиться с основными параметрами инициализации и их использованием ПО Oracle.

 

Типы файлов параметров базы данных

Oracle использует файл параметров для хранения параметров инициализации и их значений для экземпляра. Можно работать с любым из следующих двух типов файлов параметров: 

  • файл параметров сервера (SPFILE) — бинарный файл, содержащий параметры инициализации;
  • файл параметров инициализации (PFILE) — текстовый файл, содержащий список всех параметров инициализации.

Основное различие между этими двумя типами файлов состоит в том, что SPFILE позволяет вносить любые изменения в параметры инициализации, которые сохраняются для данного экземпляра и после его остановки. Применение PFILE не предоставляет такой возможности, поскольку любые динамические изменения, не записанные в этот файл, не будут сохраняться после перезапуска экземпляра БД.

Обратите внимание, что для ссылки на файл типа PFILE используется имя файла init.ora, поскольку стандартное имя файла этого типа — initимя_БД.ora. После создания базы данных будет показано, как создать SPFILE из файла init.ora.

Традиционно файл параметров инициализации был единственным типом файла, в котором можно было хранить значения параметров инициализации. Файл параметров инициализации — это текстовый файл, который можно редактировать подобно любому другому текстовому файлу. По умолчанию он размещается в каталоге $ORACLE_HOME/dbs (хотя его и можно хранить в любом удобном месте). При хранении файла конфигурации в месте, которое отличается от используемого по умолчанию, при запуске экземпляра потребуется указывать полный путь к этому файлу. Если имя файла параметров инициализации и его расположение соответствует используемым по умолчанию, имя или местоположение файла при запуске экземпляра можно не указывать.


На заметку! Файлы инициализации используются не только для создания самой базы данных, но и при каждом запуске экземпляра Oracle. Изменяя значения параметров, можно настраивать несколько аспектов, влияющих на производительность базы данных. Некоторые из этих параметров можно изменять динамически во время работы экземпляра, но, чтобы другие изменения вступили в действие, придется перезапустить экземпляр.


Файл параметров инициализации содержит параметры, которые помогут настроить экземпляр, параметры, налагающие ограничения на определенные ресурсы базы данных, и те, которые указывают имена и местоположения важных файлов. Он содержит также параметры, которые влияют на производительность базы данных, такие как указывающие объем памяти, выделенной для Oracle. После того, как файл инициализации создан, экземпляр можно запускать, используя этот файл в командах запуска базы данных.

Несколько важных параметров конфигурации можно динамически изменять во время работы экземпляра. Динамические изменения выполняются в сеансе SQL*Plus без изменения самого файла init.ora. Изменения в рамках экземпляра можно внести с помощью оператора ALTER SYSTEM, а изменения в рамках сеанса — с помощью оператора ALTER SESSION. Однако эти изменения не будут постоянными. Сразу после остановки базы данных изменения аннулируются, и параметры возвращаются к значениям, которые жестко закодированы в файле init.ora. Чтобы любые изменения параметров конфигурации стали постоянными, необходимо отредактировать файл параметров инициализации (init.ora).

Если требуется сделать динамические изменения постоянными, чтобы параметры автоматически обновлялись, и база данных использовала эти новые значения при перезапуске, нужно использовать файл параметров сервера. SPFILE также является файлом инициализации, но изменения нельзя вносить непосредственно в него, поскольку он является бинарным, а не текстовым файлом. Как будет показано в разделе “Использование файла параметров сервера” далее в нашей статье, применение файла SPFILE для управления экземпляром предоставляет ряд преимуществ. Oracle рекомендует использовать SPFILE из-за предлагаемых им преимуществ.

 

Файл параметров инициализации

В приведенном позже примере создания базы данных применяется традиционный файл init.ora. После создания базы данных из этого файла создается SPFILE. Oracle предоставляет шаблон, облегчающий создание собственного файла параметров инициализации. В системах UNIX/Linux этот шаблон находится в каталоге $ORACLE_HOME/dbs, а в системах Windows — в каталоге $ORACLE_HOME/database. Скопируйте этот шаблон init.ora, переименуйте его в initимя_БД.ora, а затем отредактируйте его в соответствии с требованиями, предъявляемыми конкретным сайтом. Не слишком беспокойтесь о “правильной” установке различных параметров конфигурации, поскольку большинство из них легко поддаются изменению в процессе эксплуатации базы данных. Особого внимания требуют лишь немногие параметры, которые нельзя изменить без создания базы данных заново. Эти параметры перечислены в разделе “Важные параметры инициализации Oracle Database 11g” далее в этой статье.

Интересно отметить то, что файл параметров инициализации содержит параметры конфигурации памяти и некоторые параметры ввода-вывода, но не имена файлов или табличных пространств, к которым принадлежат файлы данных. Вся эта информация хранится в управляющем файле. Однако файл инициализации содержит местоположения управляющих файлов и каталоги дампа сообщений об ошибках. Он указывает так- же режимы, выбранные для управления откатом, оптимизатора и архивации журналов повторного выполнения.

За исключением DB_NAME, все параметры инициализации Oracle являются необязательными. Для всех параметров инициализации, которые не нашли своего отражения в файле параметров инициализации, ПО Oracle будет просто использовать значения, заданные по умолчанию.

Конечно, позволяя Oracle использовать значения параметров, заданные по умолчанию, мы утрачиваем контроль над этими параметрами. Параметры следует исключать из файла init.ora только в том случае, если их заданные по умолчанию значения подходят для конкретной БД. В общем случае целесообразно использовать приближенные значения для важных параметров конфигурации, применяя метод проб и ошибок для выяснения необходимости использования новых параметров.

Среда Oracle Database 11g является в высокой степени конфигурируемой, но это преимущество накладывает на администраторов БД обязанность знания не только работы многочисленных параметров, но и их возможного взаимодействия друг с другом для получения результатов, не предусмотренных первоначальными планами. Например, увеличение размера SGA до определенного значения может повышать производительность базы данных, но слишком большое увеличение этого размера может в действительности привести к замедлению работы, поскольку операционная система будет вынуждена выполнять подкачку большего SGA в реальную память и из нее. Внося изменения в конфигурацию, соблюдайте осторожность: всегда помните об осложнениях, вызываемых небрежным обращением с параметрами инициализации.

 

Изменение значений параметров инициализации

Любой параметр инициализации можно изменить, просто редактируя файл init.ora. Однако чтобы изменения действительно возымели действие, необходимо выполнить возврат базы данных — остановить и снова запустить ее. Как легко догадаться, это возможно не всегда, особенно при управлении производственной базой данных. Однако некоторые параметры можно изменять “на лету” — поэтому такие параметры называются динамическими. Параметры, которые можно изменять только изменяя файл init.ora, а затем перезапуская базу данных, называются статическими.

Существуют три способа изменения значений динамических параметров: применение команд ALTER SESSION, ALTER SYSTEM и ALTER SYSTEM...DEFERRED.

Применение оператора ALTER SESSION

Оператор ALTER SESSION позволяет изменять значения динамических параметров на время сеанса, в котором он был выдан. Его используют только для временного изменения значения динамического параметра. Этот оператор имеет следующий синтаксис: 

ALTER SESSION SET имя_параметра=значение;

Применение оператора ALTER SYSTEM

Оператор ALTER SYSTEM изменяет значение параметра для всех сеансов. Однако эти изменения будут действовать только в течение времени существования экземпляра. При перезапуске базы данных эти изменения будут утеряны, если только файл init.ora не будет соответствующим образом изменен или не будет применен файл SPFILE. Этот оператор имеет следующий синтаксис: 

ALTER SYSTEM SET имя_параметра=значение;

Применение оператора ALTER SYSTEM ... DEFERRED

Оператор ALTER SYSTEM...DEFERRED обеспечивает воздействие новых значений параметра на все сеансы, но не немедленно. Изменения оказывают влияние только на те сеансы, которые запущены после выполнения оператора. Все открытые сеансы будут продолжать использовать старые значения параметров. Этот оператор имеет следующий синтаксис: 

ALTER SYSTEM SET имя_параметра DEFERRED;

Оператор ALTER SYSTEM...DEFERRED работает только для нескольких параметров инициализации. Поэтому ALTER SYSTEM следует использовать вместо изменений параметров инициализации, распространяющихся на всю систему. Любое изменение параметра, выполняемое с помощью оператора ALTER SYSTEM, немедленно применяется ко всем сеансам.

При изменении значения параметра с помощью оператора ALTER SESSION или ALTER SYSTEM изменение будет действовать только на протяжении времени существования экземпляра. При перезапуске экземпляра параметры возвратятся к своим старым значениям, если только изменения не будут записаны в файл init.ora или не будет использован файл SPFILE (запускаемый вместе с экземпляром).

Важные параметры инициализации Oracle Database 11g

В последующих главах этой статьи представлены наиболее важные параметры инициализации Oracle, о которых нужно иметь представление. Для лучшего понимания параметры разделены на группы, такие как связанные с аудитом, параметры процессов и сеансов, параметры конфигурации памяти и т.п. Примененное разбиение параметров на группы произвольно и призвано лишь облегчить понимание процесса конфигурирования новой базы данных.

Хотя приведенный список параметров выглядит длинным и внушительным, он не является полным списком параметров инициализации Oracle Database 11g — в него включены только наиболее часто используемые параметры. Oracle Database 11g обладает более 250 документированными параметрами инициализации, которые доступны для конфигурирования администраторами БД (если в список добавить недокументированные или скрытые параметры инициализации, то их общее количество значительно превысит тысячу). Однако не приходите в уныние. Основной список параметров, которые требуются для запуска новой базы данных, может быть достаточно небольшим и простым для понимания. Программисты Oracle сгруппировали наиболее часто используемые параметры, и, согласно документации Oracle, большинству БД должен требоваться только набор этих основных параметров. В Oracle рекомендуют ознакомиться с этими основными параметрами и использовать другие параметры только тогда, когда это диктуется документацией или особыми условиями. Позднее, в ходе изучения различных тем, таких как резервное копирование и восстановление, настройка производительности, организация сетей и т.п., вам будет предоставлена возможность научиться использовать наиболее экзотические параметры инициализации.

DIAGNOSTIC_DEST

Oracle Database 11g использует новую инфраструктуру для хранения диагностической информации, которая получила название ADR (Automatic Diagnostic Repository — Автоматическое хранилище диагностической информации). Размещение этого каталога задается параметром инициализации DIAGNOSTIC_DEST. Параметр DIAGNOSTIC_DEST указывает структуру ADR следующим образом:

/diag/rdbms/<имя_БД>/<имя_экземпляра>

Если имя базы данных — orcl1, а имя экземпляра — также orcl1, домашним каталогом ADR будет

/diag/rdbms/orcl1/orcl1 

Домашний каталог ADR содержит журналы предупреждений, файлы трассировки, файлы журналов и файлы событий. Если каталог ORACLE_BASE настроен, размещение ADR определяется исходя из него. В противном случае размещение диагностического каталога по умолчанию — $ORACLE_HOME/log.

FIXED_DATE

Это новый параметр инициализации Oracle Database 11g, который позволяет устанавливать постоянную дату, к которой будет возвращаться переменная SYSDATE вместо текущей даты. Настройку параметра FIXED_DATE можно отменить, используя для него значение NONE. Синтаксис параметра следующий:

Пример: FIXED_DATE = ГГГГ-ММ-ДД-ЧЧ24:МИ:СС (или используемый по умолчанию формат даты Oracle)

Значение, используемое по умолчанию: нет

Тип параметра: динамический

Параметры, связанные с аудитом

База данных Oracle может быть сконфигурирована для осуществления аудита действий, выполняемых ее пользователями. Эту функцию аудита можно конфигурировать в соответствии с несколькими критериями, хотя по умолчанию БД не выполняет аудит действий. Следующие параметры позволяют конфигурировать аудит использования базы данных.

AUDIT_TRAIL

Параметр AUDIT_TRAIL включает или отключает аудит для базы данных. Если не хотите, чтобы аудит был включен, можно ничего не делать, поскольку по умолчанию значение этого параметра — none или false, которое отключает аудит базы данных. Если же нужно включить аудит, параметр AUDIT_TRAIL можно установить в любое из перечисленных ниже значений.

  • os. Oracle записывает записи аудита в журнал аудита операционной системы — файл операционной системы, содержащий записи аудита ОС, записи аудита для пользователя SYS и те действия базы данных, которые всегда автоматически подвергаются аудиту.
  • db. Oracle записывает записи аудита того же типа, что и при значении os, но направляет все записи аудита в журнал аудита базы данных, который представляет собой таблицу AUD$, принадлежащую пользователю SYS.
  • db,extended. Это значение аналогично значению db, но предоставляет расширенную информацию аудита, такую как столбцы SQLBIND и SQLTEXT таблицы SYS.AUD$.
  • none. Это значение отключает аудит.

Кроме того, существует два значения AUDIT_TRAIL, связанные с XML.

  • XML. Это значение журнала аудита включает аудит базы данных и записывает информацию аудита в файлы ОС в формате XML.
  • XML,EXTENDED. Это значение выводит все записи аудита базы данных и значения SQLTEXT и SQLBIND в файлы ОС в формате XML.

Установка параметра выполняется следующим образом:

Пример: AUDIT_TRAIL=db

Значение, используемое по умолчанию: нет

Тип параметра: статический

Более подробная информация по аудиту действий внутри базы данных Oracle будет дана в моих новых статьях.


Совет. Даже если параметр AUDIT_TRAIL не установлен в какое-либо значение, Oracle все же будет записывать в файл операционной системы информацию аудита для всех действий базы данных, подвергаемых аудиту по умолчанию. По умолчанию в системе UNIX этот файл располагается в каталоге $ORACLE_HOME/rdbms/audit. Естественно, при желании можно указать и другой каталог.


AUDIT_FILE_DEST

Параметр AUDIT_FILE_DEST указывает каталог, в который база данных будет записывать записи аудита при выборе операционной системы в качестве места назначения посредством указания AUDIT_TRAIL=os. Этот параметр можно указывать также при выборе опций XML или XML,EXTENDED для параметра AUDIT_TRAIL, поскольку в обоих случаях записи аудита записываются в файлы операционной системы.

Пример: AUDIT_FILE_DEST=/u01/app/oracle/audit

Значение, используемое по умолчанию: $ORACLE_HOME/rdbms/audit

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SYSTEM...DEFERRED.

AUDIT_SYS_OPERATIONS

Если параметр AUDIT_SYS_OPERATIONS установлен в значение true, система будет выполнять аудит всех действий пользователя SYS и любого другого пользователя, которому назначена роль SYSDBA или SYSOPER, записывая информацию в журнал аудита операционной системы, указанный параметром AUDIT_TRAIL. Запись информации аудита в безопасное место в операционной системе позволяет исключить любую возможность того, что пользователь SYS фальсифицирует журнал аудита, хранящийся внутри базы данных. Возможные значения этого параметра — true и false.

Пример: AUDIT_SYS_OPERATIONS=true

Значение, используемое по умолчанию: false

Тип параметра: статический

LDAP_DIRECTORY_SYSAUTH

LDAP_DIRECTORY_SYSAUTH — новый параметр инициализации Oracle Database 11g, который включает или отключает проверку полномочий SYSDBA и SYSOPER для каталога. Возможные значения этого параметра — yes и no.

Пример: LDAP_DIRECTORY_SYSAUTH=yes

Значение, используемое по умолчанию: нет

Тип параметра: статический

Имя базы данных и другие главные параметры

Наиболее важным из главных параметров является параметр, устанавливающий имя базы данных. Давайте подробно рассмотрим этот набор параметров.

DB_NAME и DB_UNIQUE_NAME

Параметр DB_NAME устанавливает имя базы данных. Он является обязательным и его значение совпадает с именем базы данных, указанным при ее создании. Значение DB_NAME должно совпадать со значением переменной среды ORACLE_SID. Этот параметр нельзя изменять после того, как база данных создана. Значение DB_NAME может содержать до восьми символов.

Пример: DB_NAME=orcl11

Значение, используемое по умолчанию: false

Тип параметра: статический

Параметр DB_UNIQUE_NAME позволяет устанавливать глобально уникальное имя базы данных.

DB_DOMAIN

Параметр DB_DOMAIN указывает полностью определенное имя (в формате с точками, принятом в Интернете) базы данных, и, как правило, оно совпадает с именем организации, которой принадлежит база данных. Этот параметр задает логическое местоположение базы данных внутри структуры сети, и его нужно устанавливать, если база данных является частью распределенной системы.

Пример: DB_DOMAIN=world

Значение, используемое по умолчанию: Null

Тип параметра: cтатический

INSTANCE_NAME

В среде с одним экземпляром значение параметра INSTANCE_NAME будет совпадать со значением параметра DB_NAME. В среде Real Application Clusters с одной службой базы данных (DB_NAME) можно связать несколько экземпляров.

Пример: INSTANCE NAME=orcl11

Значение, используемое по умолчанию: SID экземпляра

Тип параметра: cтатический

SERVICE_NAME

Параметр SERVICE_NAME предоставляет имя службы базы данных и может быть любым. Обычно он является сочетанием имени базы данных и домена базы данных.

Пример: SERVICE_NAME=orcl11

Значение, используемое по умолчанию: DB_NAME.DB_DOMAIN

Тип параметра: динамический. Значение этого параметра можно изменять с помощью команды ALTER SYSTEM.

COMPATIBLE

Параметр COMPATIBLE позволяет использовать новейшую версию базы данных Oracle, обеспечивая при этом ее совместимость с более ранней версией.

Предположим, что была выполнена модернизация до версии Oracle Database 11g Release 1, но разработчики приложения не внесли никаких изменений в свое приложение для версии Oracle 10.2. В этом случае значение параметра COMPATIBLE можно было бы установить равным 10.2, чтобы непроверенные функциональные возможности новой версии Oracle не оказали нежелательного влияния на приложение. Впоследствии, после того как приложение будет соответствующим образом модернизировано, параметр инициализации COMPATIBLE можно переустановить в значение 11.1.0, являющееся используемым по умолчанию для версии Oracle Database 11g Release 1.

Если же сразу повысить уровень совместимости до 10.2, можно использовать все новые функциональные возможности версии 10.2, но базу данных нельзя будет возвратить к версии 9.2 или любой более ранней версии. Этот необратимый характер совместимости нужно четко уяснить, прежде чем устанавливать значение данного параметра.

Пример: COMPATIBLE=11.1.0.6

Значение, используемое по умолчанию: 10.2.0

Тип параметра: статический

INSTANCE_TYPE

Параметр INSTANCE_TYPE указывает, является ли данный экземпляр экземпляром базы данных или экземпляром Automatic Storage Management (Автоматическое управление хранением). Значение ASM указывает, что речь идет об экземпляре Automatic Storage Management. RDBMS обозначает экземпляр обычной базы данных.

Пример: INSTANCE_TYPE=asm

Значение, используемое по умолчанию: RDBMS

Тип параметра: статический


На заметку! Набор значений параметров зависит от базы данных Oracle, использующей ASM, и некоторые параметры применимы только к специальным экземплярам ASM.


NLS_DATE_FORMAT

Параметр NLS_DATE_FORMAT указывает формат даты, который система Oracle будет применять по умолчанию. Oracle использует этот формат даты в SQL-функциях TO_CHAR или TO_DATE. Существует значение, используемое по умолчанию, которое устанавливается на основе параметра NLS_TERRITORY. Например, если формат параметра NLS_TERRITORY — America, в качестве значения параметра NLS_DATE_FORMAT автоматически устанавливается формат DD-MON-YY.

Пример: NLS_DATE_FORMAT=DD-MM-YYYY HH:MI:SS

Значение, используемое по умолчанию: зависит от переменной NLS_TERRITORY и операционной системы

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SESSION.

Параметры, связанные с файлами

В файле init.ora можно указывать несколько параметров, связанных с файлами. Oracle требует указания нескольких местоположений для файлов трассировки и сообщений об ошибках. Кроме того, необходимо указать параметр UTL_FILE_DIR, чтобы можно было использовать пакет UTL_FILE. Основные параметры, связанные с файлами, освещены в последующих разделах этой статьи.

IFILE

Параметр IFILE можно применять для внедрения в него другого файла инициализации. Например, файл init.ora может содержать строку вроде следующей: 

ifile=config.ora

Затем в файл config.ora можно было бы поместить ряд параметров инициализации, общих для нескольких экземпляров. Можно использовать до трех уровней вложенности.

Значение, используемое по умолчанию: отсутствует

Тип параметра: статический

CONTROL_FILES

Управляющие файлы — это ключевые файлы, содержащие имена и местоположения файлов данных и множество другой важной информации. База данных нуждается только в одном управляющем файле, но поскольку он столь важен, всегда следует сохранять несколько его копий. Способ мультиплексирования управляющего файла заключается в простом указании нескольких местоположений (до восьми) в параметре CONTROL_FILES. Минимальное количество управляющих файлов — один, но Oracle рекомендует хранить, по меньшей мере, по два управляющих файла для каждого экземпляра, а большинство администраторов БД используют по три таких файла. В случае повреждения или случайного удаления одного из управляющих файлов попытка обращения к нему экземпляра будет неудачной. Когда это происходит при наличии нескольких копий управляющего файла, всегда можно перезапустить базу данных, вначале скопировав неповрежденный управляющий файл в другое место.

При использовании оператора CREATE DATABASE Oracle создает управляющие файлы, перечисленные в параметре CONTROL_FILES. Если при создании базы данных этот параметр не был включен в состав файла инициализации, система Oracle создаст управляющий файл, используя заданное по умолчанию и зависящее от операционной системы имя файла, или, при активизации опции Oracle Managed Files (Файлы, управляемые Oracle), она создаст управляющие файлы, управляемые Oracle. Для каждой базы данных должен существовать, как минимум, один управляющий файл, а всего для каждой из них их может существовать до восьми таких файлов.

Пример: CONTROL_FILES=('/u01/app/oracle/orcl11/control/ctl01.ora', '/u01/app/ oracle/orcl11/control/ctl02.ora', '/u01/app/oracle/orcl11/control/ctl03.ora')

Значение, используемое по умолчанию: зависит от операционной системы Тип параметра: статический

CONTROL_FILE_RECORD_KEEP_TIME

Параметр CONTROL_FILE_RECORD_KEEP_TIME указывает длительность хранения (в днях) записей в управляющем файле перед тем, как они будут замещены более новыми. Oracle рекомендует устанавливать высокое значение этого параметра, чтобы вся оперативная информация резервного копирования диска оставалась в управляющем файле. Например, при поддержании области пакетного восстановления, которая содержит полные еженедельные резервные копии и ежедневные инкрементные резервные копии, значение параметра CONTROL_FILE_RECORD_KEEP_TIME должно быть установлено равным, по меньшей мере, 21 дню.

Пример: CONTROL_FILE_RECORD_KEEP_TIME=14

Значение, используемое по умолчанию: 7 дней Тип параметра: доступен для динамического изменения с помощью оператора ALTER SYSTEM 

UTL_FILE_DIR

Параметр UTL_FILE_DIR можно использовать для указания каталога (или каталогов), который система Oracle будет использовать для обработки ввода-вывода при использовании пакета UTL_FILE Oracle для считывания из файлов операционной системы или записи в них. В качестве его значения можно устанавливать любой каталог ОС. Если вместо конкретного имени каталога указать символ звездочки (*), пакет UTL_FILE будет выполнять чтение и запись во всех каталогах ОС. Однако в Oracle рекомендуют отказаться от подобной практики. 

Пример: UTL_FILE_DIR=/u01/app/oracle/utl_dir

Значение, используемое по умолчанию: нет; при установке этого значения пакет UTL_FILE нельзя использовать для выполнения каких-либо операций ввода-вывода.

Тип параметра: статический


Внимание! В качестве значения параметра UTL_FILE_DIR придется использовать какой-либо каталог на сервере, для которого у вас имеются полномочия чтения/записи. В противном случае пакет не сможет обрабатывать ввод-вывод в операционной системе. В качестве значения параметра UTL_FILE_DIR можно использовать символ *, но пользователи не могут выполнять чтение и запись во всех каталогах, для которых вы обладаете полномочиями чтения/записи. Понятно, что такой сценарий нежелателен.


Параметры файлов, управляемых системой Oracle

Для указания формата файлов, управляемых Oracle (Oracle Managed Files — OMF) потребуется использовать три параметра: DB_CREATE_FILE_DEST, DB_CREATE_ONLINE_LOG_DEST_n и DB_RECOVERY_FILE_DEST. Первые два параметра описаны в последующих разделах, а третий — в разделе “Параметры, связанные с восстановлением”.

Использование параметров инициализации, связанных с OMF, подробнее рассмотрены в этой статье.

DB_CREATE_FILE_DEST

Параметр DB_CREATE_FILE_DEST указывает используемое по умолчанию местоположение файлов данных, управляемых Oracle. В этом же каталоге Oracle будет создавать файлы данных и временные файлы, если их явное местоположение не задано. Этот каталог должен уже существовать и обладать соответствующими разрешениями чтения записи для Oracle.

Пример: DB_CREATE_FILE_DEST=/u01/app/oracle/orcl11/dbfile/

Значение, используемое по умолчанию: нет

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SYSTEM либо ALTER SESSION.

DB_CREATE_ONLINE_LOG_DEST_n

Параметр DB_CREATE_ONLINE_LOG_DEST_n указывает используемое по умолчанию местоположение файлов оперативных журналов повторного выполнения и управляющих файлов. Чтобы мультиплексировать файлы оперативных журналов повторного выполнения или управляющий файл, следует указать более одного значения для этого параметра. При указании значения n, превышающего единицу, в каждом местоположении Oracle создает по одному члену для каждого оперативного журнала повторного выполнения и один управляющий файл. Можно использовать максимум до пяти отдельных каталогов.

Пример: DB_CREATE_ONLINE_LOG_DEST_1=/u01/app/oracle/orcl11/log

Значение, используемое по умолчанию: нет

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SYSTEM либо ALTER SESSION.

Параметры процессов и сеансов

Несколько параметров инициализации связаны с рядом процессов и сеансов, которые может обрабатывать база данных. Важные параметры процессов и сеансов рассмотрены в последующих разделах статьи.

PROCESSES

Значение параметра PROCESSES будет устанавливать верхний предел для числа процессов операционной системы, которые могут параллельно подключаться к базе данных. Два параметра SESSIONS и TRANSACTIONS наследуют свои заданные по умолчанию значения от этого параметра.

Пример: PROCESSES=200

Значение, используемое по умолчанию: как минимум — 6, но зависит от операционной системы

Тип параметра: статический

DB_WRITER_PROCESSES

Параметр DB_WRITER_PROCESSES задает начальное количество процессов записи базы данных для экземпляра. Экземпляры, в которых выполняется очень много операций изменения данных, могут нуждаться в большем значении, чем указано по умолчанию, которое равно одному процессу или количеству ЦП, деленному на 8 (в зависимости от того, какое значение больше). Для каждого экземпляра может существовать до 20 процессов.

Пример: DB_WRITER_PROCESSES=12

Значение, используемое по умолчанию: 1 или количество ЦП, деленное на 8, в зависимости от того, какое значение больше

Тип параметра: статический

OPEN_CURSORS

Параметр OPEN_CURSORS устанавливает ограничение на количество открытых курсоров, которые один сеанс может иметь в каждый данный момент времени.

Пример: OPEN_CURSORS=300

Значение, используемое по умолчанию: 50

Тип параметра: доступен для изменения с помощью оператора ALTER SYSTEM

Параметры конфигурации памяти

Параметры конфигурации памяти определяют память, выделенную для основных компонентов SGA. Существуют две основных области памяти, выделяемые для Oracle из памяти операционной системы: системная глобальная область ( system global area — SGA) и программная глобальная область ( program global area — PGA). Oracle Database 11g берет на себя задачу определения и настройки выделения обоих областей памяти — SGA и PGA. Чтобы полностью автоматизировать управление памятью Oracle, можно просто установить параметр MEMORY_TARGET.


На заметку! Зачастую рекомендации Oracle по оптимальной настройке различных компонентов памяти, таких как DB_CACHE_SIZE и пул совместного использования, недостаточно четки и вряд ли будут полезны начинающему администратору БД. Например, в Oracle утверждают, что для базы данных информационного хранилища значение DB_CACHE_SIZE должно составлять от 20 до 80% доступного объема памяти. Рекомендуемый размер пула совместного использования для этой же базы составляет от 5 до 10%. Столь широкий диапазон рекомендуемых значений делает рекомендации относительно DB_CACHE_SIZE практически бесполезными. Если общий объем памяти составляет 2 Гбайт, для пула совместного использования предполагается выделение от 100 до 200 Мбайт. Если же общий объем памяти составляет 32 Гбайт, в соответствии со “стандартными” рекомендациями для пула совместного использования нужно было бы выделить от 1,6 до 3,2 Гбайт. Лучшее, что можно сделать в этой ситуации — это подобрать оптимальный объем памяти для базы данных методом проб и ошибок


Кратко рассмотрим основные параметры Oracle Database 11g, связанные с выделением памяти. Буферный кэш — область памяти системы Oracle, в которой она сохраняет блоки данных, считанные с диска, и блоки данных, которые могут быть изменены здесь перед их записью обратно на диск. Наличие достаточно большого буферного кэша повысит производительность благодаря исключению необходимости слишком частого обращения к диску, которое выполняется значительно медленнее обращения к данным в памяти.

Размер буферного кэша для базы данных можно устанавливать в единицах стандартного или первичного блока, выбранного для базы данных (посредством параметра DB_BLOCK_SIZE) или используя буферные кэши с нестандартными размерами блоков). Если нужно, чтобы буферный кэш создавался на основе размера стандартного блока, для определения размера кэша следует применять параметр DB_CACHE_SIZE.

MEMORY_MAX_TARGET

Параметр MEMORY_MAX_TARGET определяет максимальное значение параметра инициализации MEMORY_TARGET. Значение можно устанавливать в диапазоне от 0 до максимально доступного для экземпляра Oracle объема физической памяти, выраженное в Кбайт, Мбайт или Гбайт.

Пример: MEMORY_MAX_TARGET=1800m

Значение, используемое по умолчанию: 0

Тип параметра: статический

Если параметр MEMORY_MAX_TARGET опущен, но значение параметра MEMORY_TARGET установлено, по умолчанию для параметра MEMORY_MAX_TARGET устанавливается значение MEMORY_TARGET.

MEMORY_TARGET

Параметр MEMORY_TARGET указывает объем памяти, выделяемый Oracle при использовании автоматического управления памятью для выделения памяти экземпляру Oracle. База данных будет увеличивать и уменьшать размеры компонентов SGA и PGA, чтобы суммарный размер оставался равным значению параметра MEMORY_TARGET.

Значение выражается в Кбайт, Мбайт или Гбайт.

Пример: MEMORY_TARGET=1000m

Значение, используемое по умолчанию: 0

Тип параметра: динамический

DB_CACHE_SIZE

Параметр DB_CACHE_SIZE задает размер используемого по умолчанию буферного пула для тех буферов, размеры которых определяются размером первичного блока (т.е. размером блока, определенным параметром DB_BLOCK_SIZE). Например, можно использовать значение, подобное 1024MB.

Пример: DB_CACHE_SIZE = 750MB

Значение, используемое по умолчанию: если параметр MEMORY_TARGET используется, заданное по умолчанию значение — 0. Если этот параметр не используется, оно будет больше 48MB или 4MB.

Тип параметра: динамический. Значение этого параметра можно изменять с помощью команды ALTER SYSTEM

Разумеется, применение автоматического управления памятью избавляет от необходимости определения любых конкретных параметров инициализации памяти, включая DB_CACHE_SIZE. При выборе опции автоматического управления памятью и игнорировании этого параметра база данных присваивает ему значение по умолчанию, равное 0. Однако ему можно присвоить конкретное значение даже при реализации автоматического управления памятью. В этом случае Oracle будет интерпретировать присвоенное параметру DB_CACHE_SIZE значение как минимальное значение пула памяти.

DB_KEEP_CACHE_SIZE

Нормальное поведение буферного пула — одинаковая обработка всех помещенных в него объектов. То есть любой объект будет оставаться в пуле до тех пор, пока в кэше буферов остается свободная память. Объекты удаляются (устаревают) только при отсутствии свободного пространства. Когда это происходит, наиболее старые не используемые объекты, хранящиеся в памяти, удаляются, чтобы освободить место для новых объектов.

Применение двух специализированных буферных пулов — постоянного пула и обновляемого пула — позволяет во время создания объекта указывать, как буферный пул должен обрабатывать определенные объекты. Например, если известно, что определенные объекты не нужно хранить в памяти в течение длительного времени, их можно назначить обновляемому пулу, из которого объекты удаляются сразу после их использования. И напротив, постоянный пул всегда хранит объект в памяти, если тот был создан с указанием опции KEEP.

Параметр DB_KEEP_CACHE_SIZE указывает размер постоянного пула, и его значение устанавливается следующим образом:

Пример: DB_KEEP_CACHE_SIZE = 500MB

Значение, используемое по умолчанию: 0; по умолчанию этот параметр не определен

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SYSTEM

DB_RECYCLE_CACHE_SIZE

Параметр DB_RECYCLE_CACHE_SIZE указывает размер обновляемого пула в буферном кэше. Oracle удаляет объекты из этого пула сразу после их использования. Установка параметра выполняется следующим образом:

Пример: DB_RECYCLE_CACHE_SIZE = 200MB

Значение, используемое по умолчанию: 0; по умолчанию этот параметр не определен

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SYSTEM

DB_nK_CACHE_SIZE

Если требуется использовать буферные кэши нестандартного размера, для каждого из них нужно указать параметр DB_nK_CACHE_SIZE. В качестве значения переменной n можно использовать значение 2, 4, 8, 16 или 32.

Пример: DB_8K_CACHE_SIZE=4096MB

Значение, используемое по умолчанию: 0

Тип параметра: динамический. Значение этого параметра можно изменять с помощью команды ALTER SYSTEM

AUDIT_SYS_OPERATIONS

Параметр AUDIT_SYS_OPERATIONS включает и отключает аудит действий, выполняемых пользователем SYS, а также любых пользователей, подключающихся к базе данных с полномочиями SYSDBA или SYSOPER. База данных вносит записи аудита в журнал аудита операционной системы. Возможные значения этого параметра — true и false.

Пример: AUDIT_SYS_OPERATIONS=true

Значение, используемое по умолчанию: false

Тип параметра: статический

CLIENT_RESULT_CACHE_LAG

Параметр инициализации CLIENT_RESULT_CACHE_LAG указывает максимальное время, которое может пройти прежде, чем запрос клиента OCI (Call-Level interface — интерфейс уровня вызовов) выполнит следующий цикл для извлечения изменений в базе данных, которые относятся к запросам, кэшированным в клиенте. Диапазон возможных значений — от 0 до максимального значения, зависящего от системы.

Пример: CLIENT_RESULT_CACHE_LAG = 10000

Значение, используемое по умолчанию: 5000 (секунд)

Тип параметра: статический

CLIENT_RESULT_CACHE_SIZE

Параметр CLIENT_RESULT_CACHE_SIZE задает максимальный объем памяти, выделенный клиенту для кэша результирующего набора каждого процесса (в байтах). Чтобы активизировать функцию кэша клиентских запросов, для этого параметра потребуется установить ненулевое значение. Этот параметр можно переопределить, устанавливая значение параметра конфигурирования клиента OCI_RESULT_CACHE_MAX_SIZE. Диапазон возможных значений — от 0 до максимального значения, которое зависит от операционной системы.

Пример: CLIENT_RESULT_CACHE_SIZE = 50M

Значение, используемое по умолчанию: 0

Тип параметра: статический

CONTROL_MANAGEMENT_PACK_ACCESS

Параметр CONTROL_MANAGEMENT_PACK_ACCESS указывает, какой из двух пакетов Server Manageability Pack (Пакет управляемости сервера) должен быть активным в базе данных. Можно использовать следующие два пакета:

  • диагностический пакет — включает в себя AWR, ADDM и т.п.;
  • пакет настройки — включает в себя SQL Tuning Advisor (Советник по настройке SQL), SQL Access Advisor (Советник по доступу к SQL) и т.п.

Чтобы активизировать пакет настройки, необходимо владеть отдельной лицензией для диагностического пакета. Возможные значения — diagnostic (диагностика), none (ни один) и diagnostic+tuning (диагностика + настройка).

Пример: CONTROL_MANAGEMENT_PACK=diagnostic

Значение, используемое по умолчанию: diagnostic+tuning

Тип параметра: динамический. Доступен для изменения с помощью оператора ALTER SYSTEM

LARGE_POOL_SIZE

Обычно пул совместного использования способен удовлетворять потребности в памяти серверов совместного использования, а также операций резервного копирования и восстановления Oracle и ряда других операций. Однако иногда это может приводить к большой нагрузке на пул совместного использования, что ведет к чрезмерной фрагментации и преждевременному устареванию важных объектов в пуле вследствие недостатка в нем свободного места.

Во избежание этих проблем с помощью параметра LARGE_POOL_SIZE можно максимально освободить пул совместного использования для кэширования запросов и информации словаря данных. Если параметр PARALLEL_AUTOMATIC_TUNING установлен, большой пул применяется также для буферов сообщений параллельного выполнения. В этом случае объем памяти, необходимый для поддержания большого пула, зависит от количества параллельных потоков одного ЦП и количества ЦП.

Пример: LARGE_POOL_SIZE=800M

Значение, используемое по умолчанию: 0 (если пул не требуется для параллельного выполнения и параметр DBWR_IO_SLAVES не установлен)

Тип параметра: динамический. Для изменения значения этого параметра можно использовать команду ALTER SYSTEM

Параметры режима archivelog

Oracle предоставляет возможность архивирования заполненных журналов повторного выполнения. Когда база данных сконфигурирована для архивирования ее журналов повторного выполнения, ее называют находящейся в режиме archivelog (режим архивирования журналов). Производственные базы данных всегда следует переводить в режим архивирования журналов, если только не существует веских причин не делать этого. Если решите архивировать журналы повторного выполнения, это следует указать в файле инициализации с помощью трех описанных далее параметров.

LOG_ARCHIVE_DEST_n

Параметры LOG_ARCHIVE_DEST_n (где n = 1, 2, 3, … 10) определяют до десяти местоположений журнального архива. Этот параметр позволяет задавать местоположение (или местоположения) архивированных журналов.

Его следует устанавливать, только если база данных эксплуатируется в режиме archivelog. То, что база данных должна работать в режиме archivelog, можно определить при создании БД, указывая ключевое слово ARCHIVELOG в операторе CREATE DATABASE.

Указание параметра LOG_ARCHIVE_DEST_n (n=1) выполняется следующим образом: 

Пример: LOG_ARCHIVE_DEST_1='LOCATION=/u02/app/oracle/arch/'

Значение, используемое по умолчанию: нет

Тип параметра: динамический. Для внесения изменений можно использовать команду ALTER SESSION или ALTER SYSTEM

LOG_ARCHIVE_FORMAT

Параметр LOG_ARCHIVE_FORMAT указывает используемый по умолчанию формат имен файлов архивированных журналов повторного выполнения. В приведенном ниже примере %t означает номер потока, %s — порядковый номер журнала, а %r — идентификатор сброшенного в исходное состояние журнала, который обеспечивает уникальное имя архивированных журналов повторного выполнения среди множества воплощений базы данных (несколько воплощений создаются в результате использования операции resetlogs (сброс журналов)).

Пример: LOG_ARCHIVE_FORMAT = 'log%t_%s_%r.arc'

Значение, используемое по умолчанию: зависит от операционной системы

Тип параметра: статический

Параметры пространства отката

Основные параметры, связанные с откатом — это UNDO_MANAGEMENT, UNDO_TABLESPACE и UNDO_RETENTION. Обратите внимание, что гарантированное сохранение данных отката можно определить при создании базы данных с использованием конструкции RETENTION GUARANTEE в операторе CREATE UNDO TABLESPACE.

UNDO_MANAGEMENT

Если параметр UNDO_MANAGEMENT установлен в значение auto, табличное пространство отката используется для сохранения записей отката, и Oracle будет автоматически управлять сегментами отката.

Пример: UNDO_MANAGEMENT = auto

Значение, используемое по умолчанию: auto

Тип параметра: статический

UNDO_TABLESPACE

Параметр UNDO_TABLESPACE определяет используемое по умолчанию табличное пространство для хранения записей отката. При наличии только одного табличного пространства отката указание этого параметра не требуется — Oracle будет автоматически использовать существующее табличное пространство отката. Если доступное табличное пространство отката отсутствует, для хранения данных отката Oracle будет использовать сегмент отката System, который не очень подходит для этой цели. Если при создании базы данных значение этого параметра не указано, а опция AUM (Automatic Undo Management — Автоматическое управление откатом) выбрана, Oracle создаст используемое по умолчанию табличное пространство отката по имени UNDOTBS. Это используемое по умолчанию табличное пространство будет содержать единственный файл данных размером в 10 Мбайт, который будет автоматически увеличиваться без каких-либо ограничений.

Пример: UNDO_TABLESPACE = undotbs1

Значение, используемое по умолчанию: первое доступное табличное пространство отката

Тип параметра: динамический. Для изменения заданного по умолчанию табличного пространства отката можно использовать команду ALTER SYSTEM

UNDO_RETENTION

Параметр UNDO_RETENTION задает объем информации отката, которая должна быть сохранена в табличном пространстве отката, прежде чем ее можно будет переписать. Подходящее значение для этого параметра зависит от размера табличного пространства отката и природы запросов, выполняемых в базе данных. Если запросы не слишком велики по объему обрабатываемых данных, им не требуются большие снимки данных, и можно ограничиться непродолжительным интервалом сохранения данных отката. Аналогично, если табличное пространство отката содержит большой объем доступного свободного пространства, транзакции не будут перезаписываться, и возникновение проблемы наличия устаревшего снимка данных менее вероятно.

Если планируется интенсивное использование средства ретроспективного запроса (Flashback Query), нужно определить временной интервал, который будут охватывать ретроспективные запросы, и указать соответствующее значение параметра UNDO_RETENTION.

Пример: UNDO_RETENTION = 14400 (4 часа)

Значение, используемое по умолчанию: 900 (секунд)

Тип параметра: динамический. С помощью команды ALTER SYSTEM это значение можно увеличить до практически неограниченного периода времени.

Параметры лицензирования Oracle

Использование программного обеспечения Oracle лимитируется лицензионным соглашением между компанией Oracle и клиентом. Использование лицензий Oracle регулируется двумя важными параметрами: LICENSE_MAX_USERS и LICENSE_MAX_SESSIONS. Первый устанавливает максимальное количество одновременно работающих пользователей Oracle, а второй — максимальное число сеансов, которые можно создать в базе данных.

LICENSE_MAX_SESSIONS

Параметр LICENSE_MAX_SESSIONS определяет максимальное количество параллельно выполняющихся сеансов, которые могут существовать в любой заданный момент времени. Как только число сеансов в базе данных достигает этого предельного значения, новые сеансы оказываются не в состоянии подключиться и получают предупреждение о том, что в базе данных достигнут соответствующий предел. Если этот параметр установлен в нулевое значение, база данных не использует условия лицензионного соглашения относительно сеансов.

Пример: LICENSE_MAX_SESSIONS=250

Значение, используемое по умолчанию: 0

Тип параметра: динамический. Значение этого параметра можно изменять с помощью команды ALTER SYSTEM


На заметку! Необходимо устанавливать либо параметр LICENSE_MAX_SESSIONS, либо LICENSE_MAX_USERS, но не оба. То есть для одного параметра должно быть задано нулевое значение, а для второго — положительное.


LICENSE_MAX_USERS

Параметр LICENSE_MAX_USERS указывает максимальное количество пользователей, которые могут быть созданы в базе данных. Его значение может устанавливаться в диапазоне от нуля до числа пользователей, определенного лицензией.

Пример: LICENSE_MAX_USRS=1200

Значение, используемое по умолчанию: 0

Тип параметра: динамический. Значение этого параметра можно изменять с помощью команды ALTER SYSTEM

Параметры, связанные с производительностью и диагностикой

В файле параметров можно определять несколько параметров, связанных с производительностью. Кроме того, можно устанавливать несколько параметров для изменения возможностей диагностики базы данных при выполнении таких действий, как трассировка SQL-операторов.

STATISTICS_LEVEL

Параметр STATISTICS_LEVEL служит для указания уровня сбора статистической информации программным обеспечением Oracle. Для этого параметра возможна установка одного из трех значений: BASIC (базовый), TYPICAL (типовой) и ALL (все). Установка для этого параметра значения TYPICAL, используемого по умолчанию, обеспечит сбор всех основных статистических сведений, требуемых для самоуправления базы данных, и наивысшую общую производительность. Когда параметр STATISTICS_LEVEL установлен в значение ALL, Oracle собирает дополнительную статистическую информацию, такую как статистические сведения о временных параметрах ОС и сведения о планах выполнения.

Пример: STATISTICS_LEVEL = typical

Значение, используемое по умолчанию: TYPICAL

Тип параметра: этот параметр доступен для изменения оператором ALTER SESSION или ALTER SYSTEM


Внимание! Установка параметра STATISTICS_LEVEL в BASIC отключает сбор многих важных статистических сведений, необходимых для обеспечения функциональных возможностей Oracle Database 11, в том числе и следующих:

  • снимки AWR (Automatic Workload Repository — автоматический репозиторий рабочей нагрузки);
  • монитор ADDM (Automatic Database Diagnostic Monitor — монитор автоматической диагностики базы данных);
  • все генерируемые сервером предупреждения;
  • Automatic Shared Memory Management (Автоматическое управление памятью совместного использования);
  • автоматический сбор статистической информации оптимизатора;
  • советник по организации буферного кэша и советник по среднему времени восстановления (mean time to recover — MTTR);
  • статистические сведения о временных параметрах.

OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES

Параметр OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES активизирует функцию SQL Plan Management (Управление планом выполнения SQL-запросов), активизируя перехват повторяющихся SQL-операторов и генерирование базисных значений плана SQL для этих операторов. Возможные значения этого параметра — true и false.

Пример: OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES = true

Значение, используемое по умолчанию: false

Тип параметра: динамический. Этот параметр доступен для изменения оператором ALTER SESSION или ALTER SYSTEM


OPTIMIZER_MODE

Параметр OPTIMIZER_MODE определяет тип оптимизации, которому должен соответствовать оптимизатор запросов Oracle. Режим оптимизатора можно устанавливать в следующие значения.

  • all_rows. Оптимизатор запросов использует основанный на стоимости подход ко всем SQL-операторам и выполняет оптимизацию, стремясь обеспечить наибольшую пропускную способность (минимальные затраты ресурсов для выполнения всего оператора).
  • first_rows_n. Оптимизатор запросов использует основанный на стоимости подход и выполняет оптимизацию для скорейшего возврата первых n строк (где n = 1, 10, 100 или 1000).
  • first_rows. Оптимизатор запросов использует смешанный подход на основе стоимости и эвристического анализа для отыскания наилучшего плана для скорейшего возврата нескольких первых строк.

На заметку! Настройка first_rows служит для обеспечения обратной совместимости — вместо нее компания Oracle рекомендует использовать настройку first_rows_n.


Пример: OPTIMIZER_MODE = first_rows

Значение, используемое по умолчанию: all_rows

Тип параметра: динамический. Этот параметр можно изменять с помощью оператора ALTER SESSION или ALTER SYSTEM.

OPTIMIZER_FEATURES_ENABLE

Параметр OPTIMIZER_FEATURES_ENABLE позволяет базе данных сохранять поведение более ранней версии ПО Oracle после его модернизации. Например, после модернизации базы данных версии Oracle 10.2 до версии Oracle 11.1 параметр OPTIMIZER_FEATURES_ENABLE можно установить в значение 11.1, тем самым сохраняя поведение оптимизатора Oracle Database 10g Release 2.

Пример: OPTIMIZER_FEATURES_ENABLE = 10.2

Значение, используемое по умолчанию: 11.1.0.6

Тип параметра: динамический. Для внесения изменений можно использовать команду ALTER SESSION или ALTER SYSTEM.

OPTIMIZER_DYNAMIC_SAMPLING

Когда объект не имеет никакой собранной оптимизатором статистической информации, Oracle динамически собирает образцы данных для сбора краткого набора статистических сведений. Уровнем динамического отбора можно управлять, устанавливая параметр OPTIMIZER_DYNAMIC_SAMPLING.

Пример: OPTIMIZER_DYNAMIC_SAMPLING = 2

Значение, используемое по умолчанию: Изменяется в диапазоне от 0 до 2 в зависимости от значения параметра OPTIMIZER_FEATURES_ENABLE (0, если это значение меньше 9.0.1, 1 для 9.2.0 и 2 для 10.0.0 или более высокого значения).

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SESSION либо ALTER SYSTEM.

OPTIMIZER_USE_INVISIBLE_INDEXES

Параметр OPTIMIZER_USE_INVISIBLE_INDEXES включает или отключает использование невидимых индексов. Возможные значения этого параметра — true и false.

Пример: OPTIMIZER_USE_INVISIBLE_INDEXES=true

Значение, используемое по умолчанию: false

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SESSION либо ALTER SYSTEM.

OPTIMIZER_USE_PENDING_STATISTICS

Параметр OPTIMIZER_USE_PENDING_STATISTICS указывает, может ли оптимизатор стоимости использовать ожидающую статистическую информацию. Возможные значения этого параметра — true и false.

Пример: OPTIMIZER_USE_PENDING_STATISTICS=true

Значение, используемое по умолчанию: false

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SESSION либо ALTER SYSTEM.

OPTIMIZER_USE_SQL_PLAN_BASELINES

Параметр инициализации OPTIMIZER_USE_SQL_PLAN_BASELINES включает или отключает использование базовых значений плана SQL, сохраненных в базе данных. При активизации SQL Plan Management (Управление планом SQL) посредством включения этой функции оптимизатор будет искать базовые значения плана SQL и выбирать план с наименьшей стоимостью. Возможные значения этого параметра — true и false.

Пример: OPTIMIZER_USE_SQL_PLAN_BASELINES=true

Значение, используемое по умолчанию: true

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SESSION либо ALTER SYSTEM.

PLSQL_CODE_TYPE

Параметр инициализации PLSQL_CODE_TYPE позволяет указывать собственный режим или режим интерпретирующей компиляции для модулей библиотеки PL/SQL. Возможные значения — nterpreted и native.

Пример: PLSQL_CODE_TYPE=native

Значение, используемое по умолчанию: interpreted

Тип параметра: динамический. Этот параметр можно изменять с помощью оператора ALTER SESSION либо ALTER SYSTEM.

RESULT_CACHE_MAX_RESULT

Параметр RESULT_CACHE_MAX_RESULT указывает часть кэша результатов в процентах, которую может использовать любой отдельный результат. Диапазон возможных значений — от 1 до 100.

Пример: RESULT_CACHE_MAX_RESULT=25

Значение, используемое по умолчанию: 5 процентов

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SYSTEM.

RESULT_CACHE_MAX_SIZE

Параметр RESULT_CACHE_MAX_SIZE указывает максимальный объем области SGA, которую может использовать кэш результатов. Установка этого параметра в значение 0 ведет к отключению кэша результатов. Диапазон возможных значений — от 0 до значения, зависящего от операционной системы.

Пример: RESULT_CACHE_MAX_SIZE=500m

Значение, используемое по умолчанию: зависит от значений, присвоенных параметрам MEMORY_TARGET, SGA_TARGET и SHARED_POOL

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SYSTEM.

RESULT_CACHE_MODE

Параметр RESULT_CACHE_MODE указывает, когда база данных будет использовать для SQL-оператора кэш результатов, сохраненных в памяти. Возможные значения —manual и force.

Пример: RESULT_CACHE_MODE=force

Значение, используемое по умолчанию: manual

Тип параметра: динамический. Этот параметр можно изменять с помощью оператора ALTER SESSION либо ALTER SYSTEM.

Если в качестве значения этого параметра установлено manual, чтобы база данных кэшировала результаты запроса, в нем нужно использовать флаг RESULT_CACHE. Если в качестве значения этого параметра выбрано force, база данных будет пытаться кэшировать результаты всех операторов, когда это только возможно.

SEC_CASE_SENSITIVE_LOGON

Параметр SEC_CASE_SENSITIVE_LOGON активизирует или отключает чувствительность паролей к регистру символов. Возможные значения этого параметра — true и false.

Пример: SEC_CASE_SENSITIVE_LOGON=true

Значение, используемое по умолчанию: true

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SYSTEM.

SEC_MAX_FAILED_LOGIN_ATTEMPTS

Параметр SEC_MAX_FAILED_LOGIN_ATTEMPTS используют для указания максимального количества неудачных попыток аутентификации, которые клиент может предпринять, прежде чем процесс сервера автоматически прекратит попытки подключения. Минимальное значение — 1, максимальное значение ничем не ограничено.

Пример: SEC_MAX_FAILED_LOGIN_ATTEMPTS=3

Значение, используемое по умолчанию: 10

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SYSTEM.

QUERY_REWRITE_ENABLED

Параметр QUERY_REWRITE_ENABLED определяет, включена или отключена перезапись запроса, что, в основном, имеет значение при использовании материализованных представлений.

Пример: QUERY_REWRITE_ENABLED=false

Значение, используемое по умолчанию: true, если параметр OPTIMIZER_FEATURES_ENABLE установлен в 10.0.0 или более высокое значение; false, если он установлен в 9.2.0 или более низкое значение.

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SESSION либо ALTER SYSTEM.

QUERY_REWRITE_INTEGRITY

Параметр QUERY_REWRITE_INTEGRITY указывает степень, до которой Oracle будет требовать соблюдения правил целостности во время перезаписи запросов: trusted (доверенный), enforced (принудительный) или stale_tolerated (терпимость к просроченным).

  • trusted. Oracle считает материализованное представление текущим и разрешает перезаписи, используя взаимосвязи, которые не навязаны Oracle.
  • enforced. Этот режим наиболее безопасен. Oracle не использует трансформации, которые не основаны на навязанных отношениях. Этот режим всегда использует наиболее новые данные, что гарантирует согласованность и целостность базы данных.
  • stale_tolerated. Oracle будет разрешать перезапись запросов с использованием не навязанных отношений.

Пример: QUERY_WRITE_INTEGRITY = trusted

Значение, используемое по умолчанию: enforced

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SESSION либо ALTER SYSTEM.

CURSOR_SHARING

Этот чрезвычайно важный параметр инициализации указывает способ представления SQL-операторов Oracle курсорам совместного использования. Для этого параметра возможна установка одного из трех значений: forced (принудительно), exact (точно) и similar (аналогично).

Пример: CURSOR_SHARING = force

Значение, используемое по умолчанию: exact

Тип параметра: динамический. Для изменения значения этого параметра можно использовать обе команды ALTER SESSION и ALTER SYSTEM.


Внимание! При использовании параметра CURSOR_SHARING следует соблюдать крайнюю осторожность. Применение опции forced вынудит Oracle использовать переменные связывания, что ведет к повышению производительности приложения. Однако это сопряжено с множеством “подводных камней”, и неправильная установка данного параметра может отрицательно сказаться на производительности.


DB_BLOCK_SIZE

Параметр DB_BLOCK_SIZE устанавливает стандартный размер блока базы данных (в байтах, как, например, 4096, что соответствует размеру блока, равному 4 Кбайт). Табличное пространство System и большинство других табличных пространств используют стандартный размер блока. Установка стандартного размера блока от 2 до 32 Кбайт (2, 4, 8, 16 или 32) осуществляется в параметре DB_BLOCK_SIZE. (Поскольку размер указывается в байтах, действительный диапазон значений параметра DB_BLOCK_SIZE составляет 2048–32768.) При создании табличных пространств можно также указывать до четырех нестандартных размеров блоков.

Прежде чем выбрать правильный размер блока базы данных, необходимо тщательно оценить потребности приложения. При каждом считывании данных из объекта базы данных Oracle или записи их в него это выполняется в виде блоков данных. Кроме того, значение DB_BLOCK_SIZE должно быть всегда кратным размеру блока операционной системы. Эту информацию можно получить у системного администратора UNIX или Windows.


Совет. Помните, что блок данных — наименьший модуль в физической структуре базы данных Oracle. При запросе данных строки загружаются не индивидуально. Вместо этого весь набор блоков, в которых хранятся строки, считываются в память в одном потоковом процессе.


При обслуживании приложений хранилища данных целесообразно выбирать очень большое значение параметра DB_BLOCK_SIZE — в диапазоне между 8 и 35 Кбайт. Это повысит производительность при считывании огромных цепочек данных с диска. Большие хранилища данных выполняют больше полных просмотров таблиц и, следовательно, больше последовательных обращений к данным, чем произвольных операций ввода-вывода.

Однако если приходится иметь дело с типичным приложением оперативной обработки транзакций (OLTP), в котором большая часть операций чтения и записи состоит из сравнительно коротких транзакций, большое значение DB_BLOCK_SIZE было бы излишним и могло бы в действительности вести к снижению эффективности операций ввода-вывода. Большинство транзакций OLTP считывают и записывают очень небольшое количество строк за одну транзакцию и проводят множество транзакций, осуществляя ввод-вывод с произвольным доступом (просмотры индексов). Поэтому в данной ситуации требуется использовать меньший размер блока — в диапазоне между 2 и 8 Кбайт. Больший размер блока может оказаться слишком большим для большинства приложений OLTP, поскольку база данных должна считывать в память большие объемы данных даже тогда, когда в действительности нуждается в очень небольшом количестве бит информации. С другой стороны, приложения хранилищ данных получат определенные преимущества от использования большого размера блока — например, 32 Кбайт.

Пример: DB_BLOCK_SIZE=32768

Значение, используемое по умолчанию: 8192 (байт)

Тип параметра: статический


На заметку! Значение параметра DB_BLOCK_SIZE нельзя просто изменить в файле init.ora после создания базы данных. Размер блока является более-менее постоянным параметром. Однако необходимость создания всей базы данных заново можно обойти, создавая новые табличные пространства (все, кроме табличного пространства System) с необходимым размером блока за счет использования параметра BLOCKSIZE, который выполнит косвенное изменение размера блока. Формально параметр DB_BLOCK_SIZE останется установленным в первоначально указанное значение. Затем можно применить функцию оперативного переопределения, чтобы переместить таблицы в заново созданные табличные пространства с новым размером блока. Это можно также выполнить с помощью OEM.


DB_FILE_MULTIBLOCK_READ_COUNT

Параметр DB_FILE_MULTIBLOCK_READ_COUNT указывает максимальное количество блоков, которые Oracle будет считывать во время полного просмотра таблиц. Чем больше это значение, тем эффективнее будут полные просмотры таблиц. Основной принцип состоит в том, что операции в хранилищах данных нуждаются в высоких значениях счетчиков многоблочного считывания, поскольку они связаны с обработкой огромных объемов данных. Если для базы данных размер блока установлен равным 16 Кбайт, а значение параметра DB_FILE_MULTIBLOCK_READ_COUNT также установлено равным 16, Oracle будет считывать 256 Кбайт данных в одной операции ввода-вывода. В зависимости от платформы Oracle поддерживает операции ввода-вывода объемом до 1 Мбайт.

Обратите внимание, что при расслоении дисков для обеспечения оптимальной производительности ширина полосы должна быть кратна размеру блока ввода-вывода. Для приложений OLTP идеальным могло бы быть значение счетчика многоблочного считывания 8 или 16. Большие хранилища данных могут нуждаться в значительно более высоких значениях.

Пример: DB_FILE_MULTIBLOCK_READ_COUNT = 32

Значение, используемое по умолчанию: зависит от платформы

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SYSTEM или ALTER SESSION.


Совет. Поскольку, начиная с версии 10.2, Oracle Database выполняет автоматическую настройку этого параметра, вероятно, имеет смысл не устанавливать его.


SQL_TRACE

Параметр SQL_TRACE включает или отключает утилиту трассировки SQL. Этот параметр можно оставлять в значении false (выключено), используемом по умолчанию, устанавливая значение true (включено) только при отладке конкретного запроса или набора запросов. В связи с вызываемыми им накладными расходами, этот параметр нужно всегда применять на уровне сеанса, а не экземпляра.

Пример: SQL_TRACE = on

Значение, используемое по умолчанию: false

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SYSTEM либо ALTER SESSION.

PARALLEL_MAX_SERVERS

Параметр PARALLEL_MAX_SERVERS определяет количество параллельно выполняющихся процессов. Oracle рекомендует использовать по два параллельных процесса на каждый ЦП в больших системах и по четыре процесса на ЦП в небольших системах. Значение, используемое по умолчанию: зависит от значений параметров CPU_COUNT, PARALLEL_AUTOMATIC_TUNING и PARALLEL_ADAPTIVE_MULTI_USER.

Тип параметра: динамический. Этот параметр можно изменять только на уровне системы с помощью команды ALTER SYSTEM.

TIMED_STATISTICS

Параметр TIMED_STATISTICS используется для указания Oracle того, нужно ли собирать временные статистические сведения во время трассировки. Возможные значения — true (временные статистические сведения собираются) и false (временные статистические сведения не собираются). Если временные статистические сведения собираются, они используются в некоторых динамических представлениях производительности. Если для параметра STATISTICS_LEVEL установлен рекомендуемый уровень TYPICAL или уровень AUTO, по умолчанию параметр TIMED_STATISTICS устанавливается в значение true.

Пример: TIMED_STATISTICS = true

Значение, используемое по умолчанию: true, если для параметра STATISTICS_LEVEL установлено значение TYPICAL или ALL, в противном случае — false.

Тип параметра: динамический. Этот параметр можно изменять с помощью команды ALTER SYSTEM либо ALTER SESSION.

PLSQL_OPTIMIZE_LEVEL

Параметр PLSQL_OPTIMIZE_LEVEL указывает уровень оптимизации, который будет использован при компиляции модулей библиотеки PL/SQL. Чем выше значение этого параметра (в диапазоне от 0 до 2), тем больше усилий компилятор прикладывает для оптимизации модулей библиотеки PL/SQL. Согласно документации Oracle, установка значения этого параметра равным 2 обеспечивает более высокую производительность, в то время как выбор значения равного 1 приведет к почти столь же успешной компиляции, но при меньшем использовании ресурсов времени компиляции.

Пример: PL_SQL_OPTIMIZE_LEVEL = 2

Значение, используемое по умолчанию: 2

Тип параметра: динамический. Для изменения значения этого параметра можно использовать команду ALTER SYSTEM или ALTER SESSION.

Параметры, связанные с восстановлением

При создании новой базы данных потребуется настроить несколько параметров, связанных с восстановлением. При разрушении экземпляра все данные на диске находятся в безопасности, но данные, сохраненные в буферах базы данных, немедленно стираются. Журналы повторного выполнения хранятся на диске, поэтому они остаются неповрежденными, но буферы журналов повторного выполнения стираются. Чтобы можно было успешно выполнить восстановление после такого краха, базу данных необходимо привести в согласованное состояние, используя журналы повторного выполнения Oracle и записи отката из табличного пространства отката. Записи журнала повторного выполнения служат для сохранения всех зафиксированных данных на диск, а записи отката — для отката любых незафиксированных данных, которые были сохранены на диске.

Восстановление экземпляра может занимать длительное время — с выводом базы данных из эксплуатации на неприемлемо длительный период времени — если только не настроить временные рамки интервала, в течение которого может выполняться восстановление экземпляра. Например, можно указать точный временной предел для полного восстановления экземпляра, и база данных автоматически настроит частоту создания контрольных точек так, чтобы только определенный максимальный объем информации использовался для отката при восстановлении экземпляра.

Конечно, при установке слишком малого временного предела восстановление экземпляра будет выполняться быстро, но база данных будет нуждаться в чрезвычайно большом количестве контрольных точек в будущем, что приведет к снижению производительности. Не существует единой универсальной рекомендации в отношении этой предельной продолжительности восстановления. При ее определении необходимо принимать во внимание соглашение об уровне обслуживания и допустимость простоев данного сайта.

Область пакетного восстановления — область, зарезервированная для всех файлов резервных копий и файлов, связанных с восстановлением. Она содержит копии текущих управляющих файлов и оперативных журналов повторного выполнения, а также архивированные журналы повторного выполнения, журналы пакетного резервного копирования и резервные копии RMAN. Область пакетного восстановления полностью отделена от области базы данных, которая является местом хранения текущих файлов базы данных (файлов данных, управляющих файлов и оперативных журналов повторного выполнения). Область пакетного восстановления не является обязательной, но Oracle настоятельно рекомендует ее использовать для упрощения операций резервного копирования и восстановления. 

Следующие два параметра, DB_RECOVERY_FILE_DEST_SIZE и DB_RECOVERY_FILE_DEST, служат для конфигурирования области пакетного восстановления.

DB_RECOVERY_FILE_DEST_SIZE

Параметр DB_RECOVERY_FILE_DEST_SIZE задает размер (в байтах) области пакетного восстановления. Пример: DB_RECOVERY_FILE_DEST_SIZE=2000M

Значение, используемое по умолчанию: нет

Тип параметра: динамический. Для изменения значения этого параметра можно использовать команду ALTER SYSTEM.

DB_RECOVERY_FILE_DEST

Параметр DB_RECOVERY_FILE_DEST указывает используемое по умолчанию местоположение области пакетного восстановления. Если при использовании файлов OMF параметр DB_CREATE_ONLINE_LOG_DEST_n не указан, Oracle использует местоположение, указанное в параметре DB_RECOVERY_FILE_DEST, в качестве заданного по умолчанию местоположения для файлов оперативных журналов повторного выполнения и управляющих файлов.

Пример: DB_RECOVERY_FILE_DEST = /u05/app/oracle/fla

Значение, используемое по умолчанию: нет

Тип параметра: динамический. Для изменения значения этого параметра можно использовать команду ALTER SYSTEM.


На заметку! Чтобы можно было установить параметр DB_RECOVERY_FILE_DEST, потребуется установить параметр DB_RECOVERY_FILE_DEST_SIZE. Если необходимо использовать средство Flashback Database, нужно применять также параметр DB_FLASHBACK_RETENTION_TARGET.


DB_FLASHBACK_RETENTION_TARGET

Параметр DB_FLASHBACK_RETENTION_TARGET указывает глубину (в минутах) возможного пакетного восстановления базы данных. Работа средства Flashback Database основана на журналах пакетного восстановления, а параметр DB_FLASHBACK_RETENTION_TARGET определяет длительность временного интервала, в течение которого сохраняются журналы пакетного восстановления. Глубина возможного пакетного восстановления базы данных зависит от объема данных, сохраняемых Oracle в области пакетного восстановления.

Пример: DB_FLASHBACK_RETENTION_TARGET = 2880

Значение, используемое по умолчанию: 1440 (минут)

Тип параметра: динамический. Для изменения значения этого параметра можно использовать команду ALTER SYSTEM.

RESUMABLE_TIMEOUT

Параметр RESUMABLE_TIMEOUT активизирует или отключает функцию Resumable Space Allocation (Возобновляемое выделение пространства) и указывает время истечения ожидания возобновления на уровне системы. Например, если установить RESUMABLE_TIMEOUT=3600, база данных будет подавлять любые операции с возобновляемым пространством и выжидать в течение одного часа (3600 секунд), прежде чем выдать сообщение об ошибке. Подробно функция Resumable Space Allocation.

Пример: RESUMABLE_TIMEOUT = 7200

Значение, используемое по умолчанию: 0

Тип параметра: динамический. Для изменения значения этого параметра можно использовать команду ALTER SYSTEM или ALTER SESSION.

Параметры проверки наличия повреждений данных

База данных Oracle оснащена рядом функций, которые могут автоматически проверять блоки данных в файлах данных на предмет согласованности и отсутствия повреждения данных. Проверка блоков подразумевает просмотр данных в блоке и их проверку на предмет согласованности. Проверка блоков предотвращает повреждение памяти и данных, но сопряжена с 1–10-процентной перегрузкой, поэтому эти параметры следует использовать с осторожностью в периоды наибольшей производственной нагрузки.

DB_LOST_WRITE_PROTECT

В основном, параметр DB_WRITE_LOST_PROTECT предназначен для среды Data Guard (Охрана данных), в которой базы данных играют роль резервных либо основных. Параметр включает или отключает обнаружение утерянных записей. Утеря записи базы данных происходит, когда подсистема ввода-вывода сигнализирует о завершении записи до того, как запись сохраняется на диск. Возможные значения — none (нет), typical (типичная) и full (полная).

Пример: DB_LOST_WRITE_PROTECT=full

Значение, используемое по умолчанию: none

Тип параметра: динамический. Для изменения значения этого параметра можно использовать команду ALTER SYSTEM.

DB_ULTRA_SAFE

Параметр инициализации DB_ULTRA_SAFE служит для управления используемыми по умолчанию настройками параметров, которые управляют уровнями защиты базы данных, такими как параметры DB_BLOCK_CHECKING и DB_BLOCK_CHECKSUM. Параметр DB_ULTRA_SAFE можно устанавливать в следующие значения.

OFF. База данных не выполняет никакие изменения, если установлен любой из следующих параметров: DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM или DB_LOST_WRITE_PROTECT.

DATA_ONLY. База данных устанавливает параметр DB_BLOCK_CHECKING в значение MEDIUM, параметр DB_LOST_WRITE_PROTECT — в значение TYPICAL, а параметр DB_BLOCK_CHECKSUM — в FULL.

DATA_AND_INDEX. База данных устанавливает параметр DB_BLOCK_CHECKING в значение FULL. Остальные два параметра, связанные с защитой, будут иметь те же значения, что и при выборе значения DATA_ONLY для параметра DB_ULTRA_SAFE.

Пример: DB_ULTRA_SAFE = data_and_index

Значение, используемое по умолчанию: OFF

Тип параметра: статический

DB_BLOCK_CHECKSUM

Контрольные суммы блоков позволяют обнаруживать повреждения данных, вызванные дисковыми ошибками или системой ввода-вывода. Прежде чем ПО Oracle записывает блок данных на диск, оно вычисляет контрольную сумму для этого блока и сохраняет это значение в самом блоке. Когда оно впоследствии считывает данные из этого блока, оно снова вычисляет контрольную сумму и сравнивает полученное значение с вычисленным при записи блока. Если контрольные суммы различны, Oracle уведомляет о том, что блок поврежден. В этом случае может требоваться выполнить восстановление носителя.

Oracle рекомендует включать в базе данных вычисление контрольных сумм блоков, чтобы можно было выявлять повреждения в блоках данных и в файлах журналов повторного выполнения. Для включения вычисления контрольных сумм можно устанавливать параметр DB_BLOCK_CHECKSUM. При этом его можно устанавливать в режим FULL или TYPICAL или же в значение OFF. В режиме FULL Oracle будет выявлять любое повреждение данных в памяти до того, как они будут записаны на диск. Однако Oracle рекомендует устанавливать этот параметр в альтернативное значение — TYPICAL, поскольку оно сопряжено с меньшими накладными расходами (составляющими 1–2% вместо 4–5%). При выборе значения OFF DBWn вычисляет контрольные суммы только для табличного пространства System.

Пример: DB_BLOCK_CHECKSUM = full

Значение, используемое по умолчанию: TYPICAL

Тип параметра: динамический. Для изменения значения этого параметра можно использовать команду ALTER SYSTEM.

DB_BLOCK_CHECKING

Используя параметр DB_BLOCK_CHECKING, можно настроить базу данных для проверки на наличие поврежденных блоков данных. Этот параметр можно устанавливать в значение low, medium или full. При этом каждый следующий уровень определяет больший объем проверки блоков (или же проверку можно отключить, установив этот параметр в off). Если проверка блоков включена, Oracle автоматически проверяет согласованность блока при каждом его изменении. Если блок окажется несогласованным, Oracle пометит его как поврежденный и создаст файл трассировки. В зависимости от рабочей нагрузки проверка блоков сопряжена с 1–10-процентными накладными расходами. В Oracle рекомендуют включать проверку блоков. Обратите внимание, что ПО Oracle проверяет блоки в табличном пространстве System при всех значениях этого параметра.

Параметр DB_BLOCK_CHECKING можно устанавливать в одно из следующих значений.

  • OFF или FALSE. База данных не выполняет проверку блоков для всех табличных пространств, кроме System.
  • LOW. База данных выполняет только основные проверки заголовков блоков после изменения содержимого блока в памяти.
  • MEDIUM. В дополнение к проверкам, выполняемым при настройке LOW, база данных выполняет также семантическую проверку всех табличных блоков, не организованных по индексу.
  • FULL или TRUE. База данных выполняет все проверки, указанные настройками LOW и MEDIUM, а также семантические проверки индексированных блоков.

Пример: DB_BLOCK_CHECKING = medium

Значение, используемое по умолчанию: false

Тип параметра: динамический. Для изменения значения этого параметра можно использовать команду ALTER SYSTEM или ALTER SESSION.

DB_SECUREFILE

Параметр DB_SECUREFILE служит для указания того, должна ли база данных обрабатывать большие объекты как SecureFiles (Безопасные файлы; новая функциональная возможность Oracle Database 11g) или как традиционные объекты BasicFiles (Базовые файлы). Если этот параметр установлен в NEVER (никогда), база данных будет создавать все указанные как SecureFiles объекты LOBS в виде традиционных объектов BasicFiles. Значение PERMITTED (разрешено) позволяет создавать объекты LOB в виде объектов SecureFiles. Этому параметру можно также присваивать значение ALWAYS (всегда).

Пример: DB_SECUREFILE = always

Значение, используемое по умолчанию: PERMITTED

Тип параметра: этот параметр можно изменять с помощью оператора ALTER SYSTEM или ALTER SESSION.

Параметры, связанные с безопасностью

Следующие параметры инициализации связаны с безопасностью базы данных, включая проверку полномочий с помощью пароля.

OS_AUTHENT_PREFIX

ПО Oracle использует значение параметра OS_AUTHENT_PREFIX в качестве префикса имен пользователей, аутентифицируемых операционной системой.

Значение, используемое по умолчанию: OPS$

Тип параметра: статический


На заметку! Используемое по умолчанию значение OPS$ хорошо известно администраторам баз данных Oracle. Однако Oracle предлагает устанавливать в качестве значения префикса пустую строку "" (OS_AUTHENT_PREFIX =""), что избавляет от обязательной необходимости добавления какого-то префикса к именам учетных записей операционной системы.


REMOTE_LOGIN_PASSWORDFILE

Параметр инициализации REMOTE_LOGIN_PASSWORDFILE указывает, будет ли ПО Oracle проверять файл паролей в целях аутентификации, а также то, сколько баз данных могут использовать файл паролей. Если этот параметр установлен в NONE, Oracle игнорирует любой файл паролей, и все привилегированные пользователи должны быть аутентифицированы операционной системой. В случае использования значения SHARED Oracle будет искать файл паролей для выполнения аутентификации пользователей, и одна или более баз данных могут совместно использовать один и тот же файл паролей и содержать имена, отличные от SYS. Значение EXCLUSIVE позволяет использовать файл паролей только одной базе данных, при этом она может содержать как пользователей SYS, так и других пользователей.

Пример: REMOTE_LOGIN_PASSWORDFILE = shared

Значение, используемое по умолчанию: EXCLUSIVE

Тип параметра: статический


Совет. При использовании Oracle RAC все экземпляры должны иметь одинаковое значение параметра REMOTE_LOGIN_PASSWORDFILE.


Недокументированные параметры инициализации

Кроме параметров инициализации, перечисленных в данной статье блога, в Oracle имеются несколько недокументированных параметров инициализации. Эти параметры не предназначены для какого-либо изменения обычными пользователями, и Oracle не поможет решать некоторые виды проблем, которые могут возникнуть в результате использования этих недокументированных и неподдерживаемых параметров. Однако после приобретения достаточного опыта некоторым из них можно будет найти вполне достойное применение.

Пример запроса списка недокументированных параметров инициализации показан в листинге ниже:


 

SQL> SELECT
a.ksppinm parameter,
a.ksppdesc description,
b.ksppstvl session_value,
c.ksppstvl instance_value
FROM x$ksppi a, x$ksppcv b, x$ksppsv c
WHERE
a.indx = b.indx
AND a.indx = c.indx
AND SUBSTR (a.ksppinm,1,1) = '_'
ORDER BY a.ksppinm;

Этот запрос создает список из 911 недокументированных параметров Oracle Database 11g.

Просмотр текущих значений параметров инициализации

Как выяснить, какие значения множества параметров инициализации установлены для базы данных в текущий момент времени? Несколько способов получения ответа на этот вопрос описаны в следующих разделах статьи.

Чтение файла init.ora (или SPFILE)

Редактор файлов, подобный Windows Notepad, всегда можно использовать для открытия файлов init.ora, причем не только для просмотра установленных значений параметров инициализации, но и (на собственный страх и риск) для их изменения. Однако этому способу присущ один важный недостаток: он не позволяет видеть значения параметров инициализации, используемые по умолчанию. Помните, что в Oracle Database 11g существует около 300 параметров инициализации, и, используя файл init.ora, вы будете устанавливать значения не более чем для четверти из них.

Представление V$PARAMETER

Практичный и быстрый способ выяснения настроек инициализации базы данных — запрос представления V$PARAMETER. Для выяснения значений всех параметром можно выполнить следующий запрос: 

SQL> SELECT name, value, isdefault FROM v$parameter;

Столбец isdefault содержит значение true, если для параметра установлено значение, используемое по умолчанию, и false, если для него установлено какое-либо значение, отличающееся от заданного по умолчанию.

Например, при запуске этой команды на NT сервере автора вывод отобразил около 250 параметров. Если требуется просмотреть только один параметр или набор связанных параметров и их значения, в приведенный SQL-запрос можно добавить конструкцию WHERE.

Команда SHOW PARAMETER

Хотя запрос представления V$PARAMETER не представляет сложности, существуют более простые способы запроса базы данных о параметрах инициализации. Можно просто ввести команду SHOW PARAMETER, которая отобразит все параметры инициализации вместе с их значениями. Объем вывода можно также ограничить, передавая команде SHOW PARAMETER ключевое слово. Например, ей можно передавать ключевые слова LOCKS (блокировки), FILES (файлы), LOG (журнал) и многие другие для получения значений связанных наборов параметров. (Обратите внимание, что результирующий список может и не представлять собой набор связанных параметров, поскольку команда просто использует поиск по шаблону в столбце NAME для извлечения значений из представления V$PARAMETER.)

Пример использования команды SHOW PARAMETER приведен в листинге ниже. В данном случае вывод отображает все параметры инициализации, которые содержат строку “lock”.

 

SQL> SHOW PARAMETER LOCK
NAME TYPE VALUE
-------------------------------   -----------   ------
db_block_buffers                  integer            0
db_block_checking                 boolean        FALSE
db_block_checksum                 boolean         TRUE
db_block_size                     integer         8192
db_file_multiblock_read_count     integer            8
ddl_wait_for_locks                boolean        FALSE
distributed_lock_timeout          integer           60
dml_locks                         integer          400
gc_files_to_locks                 string
lock_name_space                   string
lock_sga                          boolean        FALSE
SQL>

 

Создание новой базы данных Oracle

Как было отмечено в начале данного мануала, существует несколько способов создания базы данных Oracle. Один из способов — автоматическое создание базы данных в ходе инсталляции ПО сервера. Во время инсталляции нужно просто выбрать опцию создания новой базы данных, и Oracle поможет выполнить необходимые шаги по конфигурированию БД. Или же для создания новой базы данных можно воспользоваться DBCA.

 

Создание базы данных Oracle вручную

В этом разделе статьи я покажу, как создать новую базу Oracle данных с нуля, используя отдельные операторы создания БД. Разумеется, тем, кто знаком с процессом создания базы данных, не обязательно выполнять эти SQL-операторы по одному — достаточно создать сценарий, содержащий все необходимые операторы, и просто запустить его из интерфейса SQL*Plus.

Установка переменных ОС

Для создания базы данных можно использовать интерфейс SQL*Plus непосредственно с рабочей станции или через терминал, подключенный к серверу, на котором должна быть создана БД. Однако прежде чем зарегистрироваться в сеансе SQL*Plus, придется установить ряд переменных среды на уровне операционной системы.

Во-первых, убедитесь, что переменная ORACLE_HOME установлена для сеанса, в который выполняется вход. В базах данных Oracle Database 11g переменная среды ORACLE_HOME имеет следующий формат: 

$ORACLE_BASE/product/11.1.0/db_1

Следовательно, переменную среды ORACLE_HOME можно установить подобно следующему примеру:

$ export ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1

Во-вторых, установите идентификатор системы Oracle (ORACLE_SID) для своей базы данных, чтобы идентифицировать ее уникальным образом. Это значение будет совпадать со значением параметра инициализации DB_NAME (которым в данном примере является nina). 

$ export ORACLE_SID=nina

И, наконец, установите переменную LD_LIBRARY_PATH, как показано в следующем примере:

$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib 

Проверка наличия необходимых полномочий для создания базы данных

Каждая база данных Oracle имеет ряд назначенных по умолчанию административных пользователей для управления базой данных или мониторинга ее различных компонентов. Двое из этих назначенных по умолчанию пользователей занимают особое положение, поскольку их учетные записи могут применяться для решения большинства административных задач БД. Ими являются учетные записи SYS и SYSTEM.

Установленный по умолчанию пароль для учетной записи SYS change_on_install, а для учетной записи SYSTEMmanager. Как будет вскоре показано, пароли этих двух чрезвычайно важных учетных записей можно указать в ходе процесса создания базы данных. Кроме двух учетных записей административных пользователей, большинство типов баз данных Oracle снабжается еще несколькими определенными по умолчанию учетными записями, обычно с заданными по умолчанию паролями. (Проверка того, что все определенные по умолчанию пароли изменены, описана в разделе “Изменение паролей для определенных по умолчанию пользователей” далее в этой статье.) Всем пользователям, за исключением SYS, необходимо явно предоставить полномочия высшего уровня, прежде чем они смогут выполнять специальные административные функции, такие как создание баз данных, их запуск, останов и резервное копирование. Полномочия SYSDBA позволят пользователю создавать базы данных.

Полномочия SYSDBA интересны тем, что прежде чем их можно будет вызвать, не обязательно иметь открытую или даже существующую базу данных. Перед созданием базы данных будет создан экземпляр (SGA плюс процессы Oracle), и полномочия SYSDBA будут действовать даже на уровне экземпляра. Подключение к базе данных в качестве привилегированного пользователя SYS с полномочиями SYSDBA будет осуществляться, как показано в следующем примере:

SQL> CONNECT sys AS sysdba 

Если системный администратор включает пользователя oracle в специальную группу DBA в файле /etc/group, для входа в систему в качестве пользователя SYS с полномочиями SYSDBA можно воспользоваться также следующей командой: 

SQL> CONNECT / AS sysdba

Создание файла init.ora

Прежде чем можно будет запустить экземпляр Oracle, вначале потребуется создать файл параметров инициализации (init.ora). После создания экземпляра из файла init.ora можно создать SPFILE. Как вы помните, экземпляр Oracle состоит из определенных фоновых процессов Oracle и памяти Oracle. Как только экземпляр запущен, можно создать соответствующую базу данных. Поскольку большинство параметров, определенных в файле инициализации, могут быть легко изменены впоследствии, целью выполнения этих действий является не точное и исчерпывающее определение всех параметров, а быстрое создание и запуск экземпляра.

Экземпляр Oracle, созданный в качестве примера для базы данных nina (initnina.ora) и приведенный в листинге 10.3, содержит стандартные параметры, которые призваны способствовать поддержке приложения OLTP. Поэтому в этом файле инициализации вы не найдете параметры, ориентированные на хранилище данных. Обратите внимание, что в нескольких случаях заданные по умолчанию значения для определенных параметров определяются явно — это сделано исключительно в учебных целях.

 


# вначале укажите имя базы данных db_name=nina
\pard\ri144\sl-240\slmult0 #for an ASM instance, use instance_type=ASM.
Following is the default\par
# в качестве значения db_name можно установить также название организации\par
db_domain=world\par
# два следующие параметра устанавливают максимальное количество открытых файлов
# и процессов\par
db_files=1000\par
processes=600\par
# следующий параметр — используемый по умолчанию размер блока\par
db_block_size=8192\par
# следующий параметр — используемое по умолчанию значение параметра statistics_level
statistics_level=typical\par
# следующий параметр — используемое по умолчанию значение параметра audit_trail\par
audit_trail=none\par
# следующие три строки устанавливают местоположение каталогов дампа\par
background_dump_dest=\rquote /u01/app/oracle/admin/nina/\rquote\par
user_dump_dest=\rquote /u01/app/oracle/admin/nina/\rquote\par
core_dump_dest=\rquote /u01/app/oracle/admin/nina/\rquote\par
# следующий параметр устанавливает уровень совместимости базы данных\par
compatible=10.2.1.0\par
# ниже указаны два управляющих файла\par
control_files=(\lquote /u01/app/oracle/oradata/cont1.ctl\rquote ,\par
\lquote /u01/app/oracle/oradata/cont2.ctl\rquote )\par
# в качестве режима совместного использования курсоров установлен force,
# что вынуждает базу данных использовать переменные связывания\par
cursor_sharing=force\par
# два следующие параметра устанавливают местоположения областей SGA и PGA.\par
sga_target=300M\par
pga_aggregate_target=2000M\par
# счетчик много-блочного считывания установлен равным 16\par
db_file_multiblock_read_count=16\par
# следующая строка обеспечит, чтобы журналы пакетного восстановления\par
# сохранялись в течение 2 часов\par
db_flashback_retention_target=7200\par
# следующие два параметра служат для конфигурирования необязательной области
# пакетного восстановления\par
db_recovery_file_dest=\rquote /u02/app/oracle/flash_recovery_area\rquote\par
db_recovery_file_dest_size=1000M\par
# следующие два параметра управляют архивированием файлов\par
# журналов повторного выполнения. Пока я не выполняю архивирование журналов,
# но эти два параметра\par
# позволяют включить его впоследствии.\par
log_archive_dest_1=\rquote LOCATION=/u02/app/oracle/arch/\rquote\par
log_archive_format=\rquote log%t_%s_%r.arc\rquote\par
# следующий параметр — заданный по умолчанию режим оптимизатора\par
optimizer_mode=all_rows\par
# следующая строка обязывает использовать файл паролей
# для подключения в качестве пользователя SYSDBA\par
remote_login_passwordfile=none\par
# следующий параметр позволяет возобновлять определенные операции после
# приостановки\par
resumbable_timeout=1800\par
# следующие два параметра связаны с автоматическим управлением откатом\par
undo_management=auto\par
undo_retention=7200\par
# следующий параметр не обязателен, поскольку используется только
# одно табличное пространство отката\par
undo_tablespace=undotbs_01\par
\pard\f1\par
}

Совет. Используемым по умолчанию значением параметра STATISTICS_LEVEL является TYPICAL. Это значение нужно применять, если планируется использовать несколько функциональных средств Oracle, включая Automatic Shared Memory Management (Автоматическое управление памятью совместного использования).


Как только файл инициализации сконфигурирован, можно приступать к созданию экземпляра. Обязательно сохраните файл initnina.ora в каталоге $ORACLE_HOME/dbs, который является используемым по умолчанию местом хранения файла init.ora или файла SPFILE в системах UNIX/Linux (в системе Windows местоположением по умолчанию является каталог $ORACLE_HOME\database). Это позволит системе Oracle всегда находить его без указания полного пути к месту хранения.

Запуск экземпляра Oracle

Чтобы создать базу данных, вначале необходимо располагать действующим экземпляром. Помните, что экземпляр может существовать без какой-либо присоединенной к нему базы данных, и активный экземпляр делает возможным создание базы данных.

Выполните перечисленные ниже действия.

1. Удостоверьтесь, что правильно указали каталоги ORACLE_SID и ORACLE_HOME, как описано ранее в разделе “Установка переменных ОС”.

2. Войдите в среду базы данных посредством интерфейса SQL*Plus, как показано ниже: 

oracle@localhostdbs]$ sqlplus /nolog
SQL*Plus: Release 11.1.0.6.0 - Production on Fri Mar 7 15:35:32 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
SQL> CONNECT sys AS sysdba
Enter password:
Connected to an idle instance.
SQL>

3. Запустите экземпляр в режиме NOMOUNT, поскольку пока не существует никаких управляющих файлов, пригодных для монтирования. Если планируете использовать команду STARTUP, Oracle будет искать управляющие файлы. Вероятно, у вас возникла мысль: “Но ведь мы еще не создали эти файлы!” Не беспокойтесь, это будет выполнено во время создания самой базы данных.

Если файл init.ora был сохранен в каталоге по умолчанию ($ORACLE_HOME/dbs), и вы правильно указали переменную среды ORACLE_SID (nina) перед запуском экземпляра, файл init.ora можно не указывать явно.

SQL> STARTUP NOMOUNT
ORACLE instance started.
Total System Global Area 314572800 bytes
Fixed Size 1236756 bytes
Variable Size 99164396 bytes
Database Buffers 213909504 bytes
Redo Buffers 5169152 bytes
SQL>

Если же файл init.ora был сохранен в каталоге, отличном от используемого по умолчанию ($ORACLE_HOME/dbs), потребуется указать полный путь и имя файла: 

SQL> NOMOUNT PFILE='/u01/app/oracle/product/10.2.0/db_1/dbs/initnina.ora'

Совет. На этом этапе часто возникает несколько ошибок ORA-01078 (сбой при обработке системных параметров). Достаточно исправить в файле init.ora ошибку, указанную в сообщении, и запуск экземпляра должен пройти без каких-либо проблем.


4. Запуск экземпляра будет выполнен с использованием параметров, которые заданы в файле initnina.ora. Удостовериться в запуске всех фоновых процессов экземпляра базы данных можно с помощью команды ps -ef:

[oracle@localhost]$ ps -ef | grep nina
oracle 5211 1 0 Mar05 ? 00:00:32 ora_pmon_nina
oracle 5213 1 0 Mar05 ? 00:00:06 ora_vktm_nina
oracle 5217 1 0 Mar05 ? 00:00:04 ora_diag_nina
oracle 5219 1 0 Mar05 ? 00:00:06 ora_dbrm_nina
oracle 5221 1 0 Mar05 ? 00:00:11 ora_psp0_nina
oracle 5225 1 0 Mar05 ? 00:04:39 ora_dia0_nina
oracle 5227 1 0 Mar05 ? 00:00:07 ora_mman_nina
oracle 5229 1 0 Mar05 ? 00:00:19 ora_dbw0_nina
oracle 5231 1 0 Mar05 ? 00:00:17 ora_lgwr_nina
oracle 5233 1 0 Mar05 ? 00:01:34 ora_ckpt_nina
oracle 5235 1 0 Mar05 ? 00:00:15 ora_smon_nina
oracle 5237 1 0 Mar05 ? 00:00:01 ora_reco_nina
oracle 5239 1 0 Mar05 ? 00:00:52 ora_mmon_nina
oracle 5241 1 0 Mar05 ? 00:01:22 ora_mmnl_nina
oracle 5249 1 0 Mar05 ? 00:00:04 ora_fbda_nina
oracle 5251 1 0 Mar05 ? 00:00:07 ora_smco_nina
oracle 5257 1 0 Mar05 ? 00:00:03 ora_qmnc_nina
oracle 5273 1 0 Mar05 ? 00:00:00 ora_q000_nina
oracle 5275 1 0 Mar05 ? 00:00:02 ora_q001_nina
(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle 27290 1 0 15:29 ? 00:00:00 ora_w000_ninal11
oracle 27394 27375 0 15:36 pts/2 00:00:00 grep nina
[oracle@localhost] $

5. На этом этапе можно выполнить простой запрос, чтобы проверить версию базы данных: 

SQL> SELECT * FROM v$version;
BANNER
----------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 – Production
CORE 11.1.0.6.0 Production
TNS for Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
SQL>

Как видно из примера, приведенного в листинге ниже, Oracle будет записывать всю информацию запуска и остановки, а также сведения о любых ошибках, возникающих во время создания экземпляра и обычной работы базы данных, в журнал предупреждений. Журнал предупреждений содержит также все отличающиеся от заданных по умолчанию параметры инициализации, указанные в файле init.ora. Обратите внимание на запуск всех процессов Oracle: процесс записи базы данных (DBWn), монитор процессов (PMON), процесс записи журнала (LGWR), контрольные точки (CKPT), системный монитор (SMON) и процесс восстановления (RECO). Как видно из листинга ниже, запуск прошел успешно, поскольку никакие сообщения об ошибках не были выведены ни на экран, ни в файл журнала предупреждений.

Wed Feb 13 15:05:22 2008
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Autotune of undo retention is turned on.
IMODE=BR
ILAT =73
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 11.1.0.6.0.
Using parameter settings in server-side pfile
/u01/app/oracle/product/11.1.0.6/db_1/dbs/initorcl11.ora
System parameters with non-default values:
processes = 600
instance_type = "RDBMS"
sga_target = 300M
control_files = "/u01/app/oracle/oradata/orcl11/cont1.ctl"
control_files = "/u01/app/oracle/product/11.1.0.6
/db_1/dbs/ /u01/app/oracle/oradata/orcl11/cont2.ctl"
db_block_size = 8192
compatible = "11.1.0"
log_archive_dest_1 = "LOCATION=/u02/app/oracle/arch/"
log_archive_format = "log%t_%s_%r.arc"
db_files = 1000
db_recovery_file_dest = "/u02/app/oracle/oradata/orcl11/flash_recovery_area"
db_recovery_file_dest_size= 1000M
db_flashback_retention_target= 7200
undo_management = "AUTO"
undo_tablespace = "undotbs_01"
undo_retention = 7200
resumable_timeout = 1800
remote_login_passwordfile= "NONE"
db_domain = "world"
cursor_sharing = "force"
audit_trail = "NONE"
db_name = "orcl11"
optimizer_mode = "all_rows"
pga_aggregate_target = 2000M
statistics_level = "typical"
Wed Feb 13 15:05:24 2008
WARNING:Oracle instance running on a system with low open file descriptor
limit. Tune your system to increase this limit to avoid
severe performance degradation.
PMON started with pid=2, OS id=3548
Wed Feb 13 15:05:25 2008
DIAG started with pid=4, OS id=3554
Wed Feb 13 15:05:25 2008
DBRM started with pid=5, OS id=3557
Wed Feb 13 15:05:25 2008
VKTM started with pid=3, OS id=3550
VKTM running at (100ms) precision
Wed Feb 13 15:05:25 2008
PSP0 started with pid=6, OS id=3559
Wed Feb 13 15:05:25 2008
DIA0 started with pid=8, OS id=3563
Wed Feb 13 15:05:25 2008
DSKM started with pid=7, OS id=3561
Wed Feb 13 15:05:25 2008
MMAN started with pid=7, OS id=3565
Wed Feb 13 15:05:26 2008
DBW0 started with pid=9, OS id=3567
Wed Feb 13 15:05:26 2008
LGWR started with pid=10, OS id=3569
Wed Feb 13 15:05:26 2008
SMON started with pid=12, OS id=3573
Wed Feb 13 15:05:26 2008
CKPT started with pid=11, OS id=3571
Wed Feb 13 15:05:26 2008
RECO started with pid=13, OS id=3575
Wed Feb 13 15:05:26 2008
MMON started with pid=14, OS id=3577
Wed Feb 13 15:05:27 2008
MMNL started with pid=15, OS id=3579
ORACLE_BASE not set in environment. It is recommended
that ORACLE_BASE be set in the environment
Wed Feb 13 15:10:24 2008

На этом этапе вы располагаете действующим экземпляром Oracle, который состоит из процессов Oracle и выделенной для него памяти SGA. База данных пока не существует. Она будет создана с нуля в следующем разделе.

Создание базы данных

Простейшая база данных, которую можно создать, будет содержать табличное пространство System для хранения словаря данных, табличное пространство Sysaux, несколько управляющих файлов и файлов журналов повторного выполнения, заданное по умолчанию временное табличное пространство и табличное пространство отката. После того, как эта база данных будет запущена, в нее можно будет добавить любое количество новых табличных пространств.

Создадим упрощенную базу данных Oracle Database 11g. Новую базу данных можно создать либо вводя каждую строку оператора создания базы данных индивидуально, либо создав сценарий создания базы данных, содержащий весь оператор, как показано в листинге 10.5, и запустив его на выполнение.


 

SQL> CREATE DATABASE nina
2 USER SYS IDENTIFIED BY sys_password
3 USER SYSTEM IDENTIFIED BY system_password
4 LOGFILE GROUP 1 ('/u01/app/oracle/oradata/nina/redo01.log') SIZE 100M,
a. GROUP 2 ('/u01/app/oracle/oradata/nina/redo02.log') SIZE 100M,
b. GROUP 3 ('/u01/app/oracle/oradata/nina/redo03.log') SIZE 100M
5 MAXLOGFILES 5
6 MAXLOGMEMBERS 5
7 MAXLOGHISTORY 1
8 MAXDATAFILES 300
9 CHARACTER SET US7ASCII
10 NATIONAL CHARACTER SET AL16UTF16
11 EXTENT MANAGEMENT LOCAL
12 DATAFILE '/u01/app/oracle/oradata/nina/system01.dbf' SIZE 500M REUSE
13 SYSAUX DATAFILE '/u01/app/oracle/oradata/nina/sysaux01.dbf' SIZE 325M REUSE
14 DEFAULT TABLESPACE users
15 DATAFILE '/u01/app/oracle/oradata/nina/users01.dbf'
16 SIZE 500M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
17 DEFAULT TEMPORARY TABLESPACE tempts1
18 TEMPFILE '/u01/app/oracle/oradata/nina/temp01.dbf'
19 SIZE 200M REUSE
20 UNDO TABLESPACE undotbs
21 DATAFILE '/u01/app/oracle/oradata/nina/undotbs01.dbf'
22 SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
Database created.
SQL>

Ниже приведен краткий обзор оператора CREATE DATABASE.

  • Строка 1 выдает команду CREATE DATABASE программному обеспечению Oracle. Эта команда инициирует создание двух управляющих файлов, расположение которых считывается из файла параметров initnina.ora. Если управляющие файлы с такими именами уже существуют во время создания базы данных (остались от предыдущей неудачной инсталляции), в операторе CREATE DATABASE потребуется указать конструкцию CONTROLFILE REUSE.
  • Строки 2 и 3 демонстрируют возможный способ указания паролей для двух ключевых пользователей SYS и SYSTEM. Эти конструкции не обязательны, и если они опущены, пользователям SYS и SYSTEM по умолчанию соответственно присваиваются пароли change_on_install и manager. Поскольку эти пароли общеизвестны, компания Oracle советует использовать приведенные конструкции для изменения паролей по умолчанию.
  • Строка 4 создает несколько групп оперативных журналов повторного выполнения, необходимых для работы Oracle.
  • Строки 5–8 задают максимальное количество файлов данных, файлов журналов и т.п.
  • Строки 9 и 10 указывают наборы символов, используемые базой данных. Просто используйте эти наборы символов для всех баз данных, которые будут созданы в будущем, если только не требуется применять язык, отличный от английского.
  • Строка 11 указывает, что управление табличным пространством System должно осуществляться локально, а не посредством словаря.
  • Строка 12 создает табличное пространство System с одним файлом данных размером в 500 Мбайт. Словарь данных создается внутри табличного пространства System. Один сегмент отката системы также создается автоматически.
  • Строка 13 создает новое используемое по умолчанию табличное пространство Sysaux. Создание этого табличного пространства обязательно. В противном случае выполнение оператора создания базы данных будет неудачным.
  • Строки 14–16 создают заданное по умолчанию постоянное табличное пространство TEMP01 с одним временным файлом в 500 Мбайт. Всем пользователям при их первоначальном создании в базе данных должно предоставляться временное табличное пространство. Если это не будет сделано, пользователям автоматически будет выделено заданное по умолчанию временное табличное пространство TEMP01. Обратите внимание, как строка 14 указывает, что файлом, используемым для временного табличного пространства, является временный (temp) файл, а не обычный файл данных. Временное табличное пространство нельзя создать, используя спецификацию обычного файла данных.
  • Строки 17–19 создают новое заданное по умолчанию временное табличное пространство базы данных. Любым пользователям, которым постоянное табличное пространство не присвоено явно, это табличное пространство будет выделено в качестве используемого по умолчанию, вместо табличного пространства System.
  • Строки 20–22 создают для новой базы данных новое табличное пространство отката.

Oracle автоматически монтирует и открывает базу данных после создания всех вышеописанных файлов. Как будет показано в последней части данной статьи, монтирование базы данных Oracle сопряжено со считыванием управляющих файлов, а ее открытие позволяет всем пользователям получать доступ к различным компонентам новой базы данных.

На этом этапе загляните в журнал предупреждений, чтобы выяснить, что именно ПО Oracle выполнило при выдаче команды CREATE DATABASE. Важный фрагмент журнала предупреждений приведен в листинге ниже.


 

Sun Feb 13 15: 13:00 2008
create database orcl11
USER SYS IDENTIFIED BY *****
USER SYSTEM IDENTIFIED BY ******
LOGFILE GROUP 1 ('/u01/app/oracle/oradata/orcl11/redo01.log') SIZE 100M,
GROUP 2 ('/u01/app/oracle/oradata/orcl11/redo02.log') SIZE 100M,
GROUP 3 ('/u01/app/oracle/oradata/orcl11/redo03.log') SIZE 100M
MAXLOGFILES 5
MAXLOGMEMBERS 5
MAXLOGHISTORY 1
MAXDATAFILES 100
CHARACTER SET US7ASCII
NATIONAL CHARACTER SET AL16UTF16
EXTENT MANAGEMENT LOCAL
DATAFILE '/u01/app/oracle/oradata/orcl11/system01.dbf' SIZE 325M REUSE
SYSAUX DATAFILE '/u01/app/oracle/oradata/orcl11/sysaux01.dbf' SIZE 325M REUSE
DEFAULT TABLESPACE users
DATAFILE '/u01/app/oracle/oradata/orcl11/users01.dbf'
SIZE 500M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
DEFAULT TEMPORARY TABLESPACE tempts1
TEMPFILE '/u01/app/oracle/oradata/orcl11/temp01.dbf'
SIZE 20M REUSE
UNDO TABLESPACE undotbs
DATAFILE '/u01/app/oracle/oradata/orcl11/undotbs01.dbf'
SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
Database mounted in Exclusive Mode
Lost write protection disabled
Wed Feb 13 15:33:08 2008
Successful mount of redo thread 1, with mount id 3893367911
Assigning activation ID 3893367911 (0xe8101467)
Thread 1 opened at log sequence 1
Current log# 1 seq# 1 mem# 0: /u01/app/oracle/oradata/orcl11/redo01.log
Successful open of redo thread 1
Wed Feb 13 15:33:08 2008
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Feb 13 15:33:08 2008
SMON: enabling cache recovery
processing ?/rdbms/admin/dcore.bsq
create tablespace SYSTEM datafile '/u01/app/oracle/oradata/orcl11/
system01.dbf' SIZE 325M REUSE
EXTENT MANAGEMENT LOCAL online
Wed Feb 13 15:33:20 2008
Completed: create tablespace SYSTEM datafile
'/u01/app/oracle/oradata/orcl11/system01.dbf' SIZE 325M REUSE
EXTENT MANAGEMENT LOCAL online
create rollback segment SYSTEM tablespace SYSTEM
storage (initial 50K next 50K)
Completed: create rollback segment SYSTEM tablespace SYSTEM
storage (initial 50K next 50K)
processing ?/rdbms/admin/dsqlddl.bsq
processing ?/rdbms/admin/dmanage.bsq
CREATE TABLESPACE sysaux DATAFILE '/u01/app/oracle/oradata/orcl11/
sysaux01.dbf' SIZE 325M REUSE
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ONLINE
Wed Feb 13 15:33:36 2008
Completed: CREATE TABLESPACE sysaux DATAFILE
'/u01/app/oracle/oradata/orcl11/sysaux01.dbf' SIZE 325M REUSE
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ONLINE
processing ?/rdbms/admin/dplsql.bsq
processing ?/rdbms/admin/dtxnspc.bsq
CREATE UNDO TABLESPACE UNDOTBS DATAFILE
'/u01/app/oracle/oradata/orcl11/undotbs01.dbf'
SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
Successfully onlined Undo Tablespace 2.
Completed: CREATE UNDO TABLESPACE UNDOTBS DATAFILE
'/u01/app/oracle/oradata/orcl11/undotbs01.dbf'
SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
CREATE TEMPORARY TABLESPACE TEMPTS1 TEMPFILE
'/u01/app/oracle/oradata/orcl11/temp01.dbf'
SIZE 20M REUSE
Completed: CREATE TEMPORARY TABLESPACE TEMPTS1 TEMPFILE
'/u01/app/oracle/oradata/orcl11/temp01.dbf'
SIZE 20M REUSE
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMPTS1
Completed: ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMPTS1
CREATE TABLESPACE USERS DATAFILE '/u01/app/oracle/oradata/orcl11/users01.dbf'
SIZE 500M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
SEGMENT SPACE MANAGEMENT MANUAL
Wed Feb 13 15:34:12 2008
Completed: CREATE TABLESPACE USERS DATAFLE
'/u01/app/oracle/oradata/orcl11/users01.dbf'
SIZE 500M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
SEGMENT SPACE MANAGEMENT MANUAL
ALTER DATABASE DEFAULT TABLESPACE USERS
Completed: ALTER DATABASE DEFAULT TABLESPACE USERS
processing ?/rdbms/admin/dfmap.bsq
. . .
Wed Feb 13 15:34:32 2008
SMON: enabling tx recovery
Starting background process SMCO
Wed Feb 13 15:34:33 2008
SMCO started with pid=17, OS id=4055
Wed Feb 13 15:34:38 2008
Starting background process FBDA
Wed Feb 13 15:34:38 2008
FBDA started with pid=19, OS id=4059
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Wed Feb 13 15:34:40 2008
QMNC started with pid=20, OS id=4063
Completed: create database orcl11
. . .
Wed Feb 13 15:50:43 2008
Sat Feb 16 11:00:18 2008

Совет. Если хотите увидеть, что именно Oracle выполняет во время процесса создания базы данных, перейдите в каталог, содержащий журнал предупреждений, и выполните следующую команду: 

$ tail -f alertnina.log

Основные действия по созданию базы данных, отраженные в журнале создания базы данных, который приведен в листинге 10.6, описаны ниже.

  • Оператор database mounted означает, что ПО Oracle открыло управляющие файлы, указанные в файле init.ora.
  • Оператор successful open of redo thread 1 показывает, что первый файл журнала отката был успешно создан и открыт в целях восстановления.
  • Табличные пространства Sysaux и System успешно созданы.
  • Сегмент отката по имени system создан в табличном пространстве System.
  • Табличное пространство отката UNDOTBS успешно создано.
  • Табличное пространство TEMP01 создано в качестве временного табличного пространства с применением временного файла вместо обычного файла данных, используемого для постоянных табличных пространств. После того как временное табличное пространство создано, оператор ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP01 выдается для назначения TEMP01 в качестве заданного по умолчанию временного табличного пространства для данной БД.
  • Табличное пространство USERS создается и оператор ALTER DATABASE DEFAULT TABLESPACE USERS выполняется для назначения табличного пространства USERS в качестве заданного по умолчанию постоянного табличного пространства для новой базы данных.
  • Новые фоновые процессы QMNC и MMNL запущены.

На заметку! При создании области пакетного восстановления, которая представляет собой специализированное местоположение для хранения файлов, связанных с восстановлением, нельзя использовать традиционные параметры LOG_ARCHIVE_DEST и LOG_ARCHIVE_DUPLEX_DEST. Вместо них следует указать параметр LOG_ARCHIVE_DEST_n.


Запуск сценариев Oracle для создания объектов словаря данных

Oracle предоставляет два важных сценария catalog.sql и catproc.sql, которые нужно запускать сразу после создания новой базы данных.

  • catalog.sql заполняет базу данных представлениями словаря данных, общедоступными синонимами и другими объектами. Базовые таблицы словаря данных, являющиеся родительскими объектами представлений V$ — первые объекты, создаваемые в базе данных Oracle.
  • catproc.sql создает предоставляемые Oracle пакеты и другие объекты, предназначенные для поддержки использования кода PL/SQL в базе данных.

При выполнении этих сценариев на экран выводится огромный поток информации, свидетельствующей о создании необходимых объектов базы данных и т.п. Просто предоставьте этим двум сценариям возможность выполнить свою задачу. Выполнение обоих сценариев может занять около часа.


На заметку! Не обращайте внимания ни на какие ошибки во время выполнения сценариев catalog.sql и catproc.sql. В большинстве случаев эти ошибки означают, что пропускаемый объект не существует. Если все эти ошибки вызывают беспокойство, можете успокоить себя, запустив каждый сценарий повторно. При втором выполнении никакие ошибки не отобразятся.


Подключитесь к базе данных в качестве привилегированного пользователя SYS с полномочиями SYSDBA и запустите сценарии следующим образом: 

SQL> @$ORACLE_HOME/rdbms/admin/catalog.sql
. . .
Grant succeeded
PL/SQL procedure successfully completed.
SQL>
SQL> @$ORACLE_HOME/rdbms/admin/catproc.sql
. . .
PL/SQL procedure successfully completed.
SQL>

Простой способ создания базы данных

Вы узнали, как создать базу данных, вначале указав различные параметры инициализации в файле параметров для запуска экземпляра, а затем используя оператор CREATE DATABASE для создания самой базы данных. И файл параметров инициализации, и оператор CREATE DATABASE достаточно сложны. Однако вовсе не обязательно иметь дело со столь сложным файлом инициализации и оператором CREATE DATABASE при каждом создании новой базы данных. Если нужно быстро создать новую базу данных Oracle, это можно сделать, выполнив следующие действия.

1. Создайте новый файл init.ora только с одним параметром DB_NAME (например, DB_NAME=orcl11).

2. Запустите новый экземпляр следующим образом: 

SQL> STARTUP NOMOUNT
ORACLE instance started.
Total System Global Area            188743680 bytes
Fixed Size                            1308048 bytes
Variable Size                       116132464 bytes
Database Buffers                     67108864 bytes
Redo Buffers                          5169152 bytes
SQL>

3. С помощью следующего простого оператора создайте новую базу данных:

SQL> CREATE DATABASE;
Database created.
SQL> 

Oracle автоматически создаст табличные пространства System и Sysaux в формате OMF. База данных будет запущена в режиме ручного управления откатом с использованием сегментов отката. Разумеется, для создания словаря данных и пакетов Oracle все же придется запустить два сценария — catalog.sql и catproc.sql.


Совет. Файл параметров инициализации будет содержать информацию о местоположениях файлов данных, файлов журналов повторного выполнения и управляющих файлов. Oracle автоматически создаст автоматически расширяемый системный файл размером в 100 Мбайт, несколько журналов повторного выполнения, управляющих файлов, табличное пространство отката и временное табличное пространство. Как видите, все достаточно просто.


 

Использование DBCA для создания базы данных

Простейший способ создания базы данных Oracle предполагает использование мастера создания базы данных Oracle — DBCA ( Database Configuration Assistant — Помощник конфигурирования базы данных). Универсальный инсталлятор Oracle автоматически вызывает DBCA, если создание БД выбрано в качестве опции при установке программного обеспечения Oracle Database 11g. DBCA можно вызвать также для создания базы данных Oracle в любое время после завершения установки ПО.

DBCA можно запустить в интерактивном или режиме молчания, и его применение обеспечивает ряд преимуществ, включая предоставление шаблонов для создания баз данных DSS (Decision Support System — система поддержки принятия решений), OLTP (Online Transaction Processing — оперативная обработка транзакций) или гибридных баз данных. Наибольшее преимущество применения DBCA состоит в том, что с его помощью администратор базы данных, обладающий не очень большим опытом работы, может предложить ПО Oracle настроить все параметры конфигурации и быстро запустить новую базу данных, не допустив при этом ошибки. И, наконец, DBCA автоматически создает все необходимые файловые системы, исходя из в высшей степени прагматического стандарта оптимальной гибкой архитектуры.

DBCA — прекрасное программное средство, которое даже позволяет автоматически зарегистрировать новую базу данных в Интернет-каталоге Oracle (Oracle Internet Directory — OID). Однако настоятельно рекомендуется вначале использовать ручной подход, чтобы получить четкое представление о выборе нужных параметров инициализации и всех шагах создания базы данных. Естественно, после приобретения достаточного опыта применение DBCA — несомненно лучший способ создания базы данных Oracle любого размера и сложности.

С помощью DBCA можно выполнять следующие задачи:

  • создавать базу данных;
  • изменять конфигурацию существующей базы данных;
  • удалять базу данных;
  • конфигурировать ASM.

Запуск DBCA

В среде операционной системы Windows щелкните на кнопке Start (Пуск), а затем выберите команду меню ProgramsOraclehome_nameConfiguration and Migration ToolsDatabase Configuration Assistant (ПрограммыИмя_домашнего_каталога_Oracle Средства конфигурирования и переходаПомощник конфигурирования базы данных). В системе UNIX или Linux DBCA можно запустить, вводя команду dbca в приглашении командной строки. Поскольку DBCA — инструментальное средство с графическим интерфейсом пользователя, прежде чем его вызывать, удостоверьтесь в правильной установке переменной среды DISPLAY.

Шаги по созданию базы данных

Ниже приведен краткий перечень шагов, которые нужно выполнить для создания новой базы данных с помощью DBCA.

  1. Если DBCA еще не запущен, введите команду dbca в командной строке операционной системы.
  2. В окне Welcome (Приветствие) щелкните на кнопке Next (Далее).
  3. Откроется окно DBCA Operations (Операции DBCA). В нем выберите опцию Create a Database (Создать базу данных) и щелкните на кнопке OK.
  4. В окне Database Templates (Шаблоны базы данных) DBCA предоставляет возможность выбора типа базы данных, которую требуется создать. Возможные варианты выбора — Data Warehouse (Хранилище данных), General Purpose (БД общего назначения) и Transaction Processing (Обработка транзакций). Если не уверены в отношении типа базы данных, которую нужно создать, можно выбрать используемый по умолчанию шаблон General Purpose. При желании можно выбрать так-же опцию Custom Database (Нестандартная база данных). В этом случае для создания базы данных мастеру DBCA придется предоставить больше информации. Щелкните на кнопке Next.
  5. В окне Database Identification (Идентификация базы данных) введите имя базы данных в форме имя_базы_данных.имя_домена (например, orcl11.world). В поле SID введите идентификатор системы, который по умолчанию совпадает с именем базы данных (orcl11). Щелкните на кнопке Next.
  6. В окне Management Options (Параметры управления) можно установить режим управления для Oracle Enterprise Manager. Возможные варианты выбора — Grid Control (Сетевое управление) и Database Control (Управление базой данных). Если Oracle Management Agent (Агент управления Oracle) уже установлен на хост-компьютере, можно выбрать опцию Grid Control. В противном случае выберите опцию Configure Database Control (Конфигурировать управление базой данных), чтобы обеспечить локальное управление. В этом окне можно также выбрать опцию Enable Daily Backup to Recovery Area (Активизировать ежедневное резервное копирование в область восстановления). Щелкните на кнопке Next.
  7. В окне Database Credentials (Полномочия в базе данных) укажите пароли для административных учетных записей, таких как SYS и SYSTEM. Щелкните на кнопке Next.
  8. В окне Storage Options (Параметры хранилища) укажите тип устройств хранения, которые нужно использовать для новой базы данных. Выберите опцию File System (Файловая система) и щелкните на кнопке Next.
  9. В окне Database File Locations (Размещения файлов базы данных) выберите опцию Common Location for All Database Files (Общее расположение для всех файлов базы данных), укажите домашний каталог ПО Oracle и путь к каталогу, в котором DBCA должен создать файлы базы данных. При желании можно выбрать опцию Oracle Managed Files (Файлы, управляемые Oracle), чтобы БД полностью управляла файлами базы данных.
  10. В окне Recovery Configuration (Конфигурация восстановления) выберите режим работы базы данных noarchivelog (без архивирования журналов) или archivelog (архивирование журналов). Oracle рекомендует выбирать опцию Enable Archiving (Включить архивирование), чтобы активизировать архивирование журналов повторного выполнения. Oracle рекомендует также активизировать опцию Select Flash Recovery Area (Выбрать область пакетного восстановления), чтобы база данных использовала эту область для хранения всех файлов, связанных с резервным копированием и восстановлением. Область пакетного восстановления располагается отдельно от местоположения текущих файлов базы данных, таких как файлы данных, управляющие файлы и оперативные журналы повторного выполнения.
  11. На странице Database Content (Содержимое базы данных) выберите опцию Sample Schemas (Образцы схем), чтобы включить табличное пространство Sample Schemas (табличное пространство EXAMPLE) в создаваемую базу данных. Oracle рекомендует это для того, чтобы можно было использовать примеры, построенные на основе таких образцов схем, как HR и OE.
  12. На странице Initialization Parameters (Параметры инициализации) можно установить параметры инициализации, связанные со следующими компонентами:
  • память;
  • размеры;
  • наборы символов;
  • режим подключения.

Прежде чем продолжить создание базы данных, давайте подробно рассмотрим каждый из этих компонентов.

Память

Окно Memory (Память) позволяет установить параметры инициализации, которые контролируют способ управления памятью, выделяемой базе данных. Для указания метода управления памятью можно выбрать опцию Typical (Типичный) или Custom (Пользовательский). Простейший способ управления памятью — выбор опции Typical и ввод процентного значения, такого как 40 %. В этом случае экземпляр будет использовать новую функцию Automatic Memory Management (Автоматическое управление памятью) Oracle Database 11g для автоматической настройки обоих областей SGA и PGA.

Определение размеров

Вкладка Sizing (Определение размеров) служит для указания размера блока базы данных и максимального числа процессов пользователя, которые могут одновременно подключаться к базе данных. Для размера блока примите значение, предлагаемое по умолчанию — 8 Кбайт. Для количества процессов используйте число, близкое к 150, если только заведомо не требуется больше процессов.

Наборы символов

Для выбора набора символов базы данных используйте значение по умолчанию, которое поддерживает язык, применяемый операционной системой для всех пользователей и приложений базы данных.

Режим подключения

Вкладка Connection Mode (Режим подключения) позволяет указать метод подключения, который пользователи будут использовать для подключения к базе данных. Для указания заданного по умолчанию режима работы базы данных выберите опцию Dedicated Server Mode (Режим выделенного сервера).

  1. По окончании выбора параметров настройки распределения памяти, размеров блоков базы данных, наборов символов и режима подключения щелкните на кнопке Next.
  2. В окне Security Settings (Настройки безопасности) выберите новую используемую по умолчанию расширенную опцию безопасности, которая включает активизацию аудита и настройку используемого по умолчанию файла паролей.
  3. На странице Automatic Maintenance Tasks (Задачи автоматического обслуживания) выберите опцию Enable automatic maintenance tasks (Включить задачи автоматического обслуживания), чтобы три задачи автоматизированного обслуживания могли ежедневно выполняться в базе данных.
  4. В окне Database Storage (Хранилище базы данных) можно изменить заданные по умолчанию расположения файлов данных, управляющих файлов и журналов повторного выполнения. После этого щелкните на кнопке Next.
  5. В окне Creation Options (Опции создания) выберите опцию Create Database (Создать базу данных) и щелкните на кнопке Finish (Готово). DBCA отобразит страницу подтверждения выбранных параметров. Просмотрите представленную информацию и щелкните на кнопке OK, чтобы запустить создание базы данных. По завершении создания базы данных щелкните на кнопке Exit (Выйти), чтобы закрыть DBCA.

Изменение конфигурации базы данных

DBCA можно использовать для изменения определенных параметров конфигурации существующей базы данных. Например, с помощью DBCA можно изменить метод распределения памяти или метод хранения базы данных.

Удаление базы данных

DBCA позволяет легко удалить базу данных. Выберите опцию Delete a Database (Удалить базу данных) в окне Operations (Операции). DBCA удалит все файлы базы данных. Если работа выполняется в операционной системе Windows, DBCA удалит также все связанные с базой данных службы, тем самым позволяя выполнить чистое удаление базы данных вместо физического удаления файлов базы данных вручную.

Создание дополнительных табличных пространств

Итак, теперь вы располагаете реальной работающей базой данных на сервере. Но пока с ее помощью можно решать не слишком много задач, поскольку она представляет собой всего лишь “скелет” базы данных. В ней отсутствует код какого-либо приложения, объекты приложений или хранящиеся данные. Чтобы можно было создавать объекты и загружать данные, необходимо физическое пространство, и его выделение осуществляется за счет создания ряда табличных пространств.

Прежде всего, потребуется определить размеры запланированных таблиц, индексов и других объектов базы данных, руководствуясь стандартными рекомендациями по определению размеров таблиц. Это позволит получить представление о том, сколько табличных пространств необходимо создать. Нежелательно иметь дело с тысячами маленьких табличных пространств, поскольку управление ими станет чрезвычайно трудоемкой задачей. Основная идея состоит в том, чтобы создать столько табличных пространств, сколько необходимо для группирования связанных таблиц приложения. Теоретически все данные можно поместить в одно большое табличное пространство, но это противоречит назначению табличного пространства в базе данных Oracle.

Как только количество необходимы табличных пространств определено, используйте команду, подобную приведенной ниже, для создания дополнительных табличных пространств (по умолчанию Oracle создаст локально управляемое табличное пространство):

SQL> CREATE TABLESPACE sales01
DATAFILE '/u02/app/oracle/oradata/nina/sales01_01.dbf' size 500M
Tablespace created.
SQL>
SQL> CREATE TABLESPACE sales02
DATAFILE '/u02/app/oracle/oradata/nina/sales02_01.dbf' size 500M
Tablespace created.
SQL>

Теперь проверьте табличные пространства, созданные в новой базе данных, как показано в листинге 10.7.


SQL> SELECT tablespace_name, extent_management,
allocation_type, segment_space_management
FROM dba_tablespaces;
TABLESPACE_NAME      EXTENT_MAN    ALLOCATIO     SEGMEN
------------------   -----------   -----------   ----------
SYSTEM               LOCAL         SYSTEM        MANUAL
UNDOTBS_01           LOCAL         SYSTEM        MANUAL
SYSAUX               LOCAL         SYSTEM        AUTO
TEMP01               LOCAL         UNIFORM       MANUAL
USERS                LOCAL         SYSTEM        MANUAL
SALES01              LOCAL         SYSTEM        AUTO
SALES02              LOCAL         SYSTEM        AUTO
7 rows selected.
SQL>

Запрос показывает, что база данных содержит семь табличных пространств, пять из которых были созданы во время процесса создания базы данных (System, Sysaux, пространство отката, временное табличное пространство и заданное по умолчанию постоянное временное табличное пространство). Остальные два — sales01 и sales02 — это табличные пространства приложения, созданные предыдущими SQL-запросами.


Запуск OEM-управления базой данных


Консоль OEM (Oracle Enterprise Manager — Диспетчер предприятия Oracle) поставляется в двух версиях: Grid Control (Сетевое управление) и Database Control (Управление базой данных). ПО OEM Grid Control необходимо инсталлировать отдельно и использовать с агентами, установленными на удаленных серверах, для управления всей системой. Консоль Database Control является частью программного обеспечения сервера Oracle Database 11g и не требует специальной инсталляции.

При создании новой базы данных с помощью DBCA Oracle автоматически запускает службу Database Control. При создании базы данных вручную для запуска процесса dbconsole Oracle Enterprise Manager нужно выдать следующую команду:

$ emctl start dbconsole 

Как только процесс dbconsole запущен, доступ к консоли OEM Database Control можно получить, открывая веб-браузер и вводя следующий URL-адрес: 

http://hostname:portnumber/em

В URL-адресе hostname имя или адрес вашего компьютера, а portnumber — номер HTTP-порта консоли Database Control. На сервере Red Hat Linux автора по умолчанию используется порт 1158. Значения портов можно выяснить, просматривая файл portlist.ini, расположенный в каталоге $ORACLE_HOME/install/portlist.


Изменение паролей для определенных по умолчанию пользователей

Одна из первых задач, которую нужно выполнить после создания новой базы данных — изменение паролей для всех определенных по умолчанию пользователей. Имена и количество этих пользователей может быть разным в различных базах данных. Например, при предоставлении Oracle возможности создания базы данных при использовании универсального инсталлятора Oracle можно выбрать специализированную базу данных OLTP, DSS или гибридную БД. С каждой из этих баз данных связана своя группа определенных по умолчанию специализированных пользователей. Тем не менее, все типы баз данных будут иметь, по меньшей мере, несколько общих определенных по умолчанию пользователей.

Следующий запрос отображает некоторых определенных по умолчанию пользователей, общих для всех новых баз данных: 

SQL> SELECT username FROM dba_users;
USERNAME
-------------
DBSNMP
SYSTEM
SYS
OUTLN
. . .
SQL>

О паролях пользователей SYS и SYSTEM можно не беспокоиться, поскольку мы их уже изменили во время процесса создания базы данных. Учетная запись пользователя OUTLN служит для предоставления сохраненных черновиков SQL-запросов, а учетная запись DBSNMP предназначена для агента Intelligent Agent (Интеллектуальный агент) Oracle. В зависимости от типа созданной базы данных и выбранных для нее параметров в ней могут быть созданы и другие пользователи. По умолчанию пароли каждой из этих учетных записей совпадают с именем пользователя. Их необходимо изменить немедленно, поскольку они представляют потенциальную проблему безопасности. Для каждого из определенных по умолчанию пользователей заданные для них по умолчанию пароли нужно изменить, как показано в следующих примерах: 

SQL> ALTER USER outln IDENTIFIED BY 'новый_пароль';
SQL> ALTER USER dbsnmp IDENTIFIED BY 'новый_пароль';

Совет. Большинство определенных по умолчанию учетных записей (кроме SYS, SYSTEM, DBSNMP и SYSMAN) изначально заблокированы за счет истечения срока действия их паролей. Необходимо разблокировать и переустановить пароли этих учетных записей, используя оператор ALTER USER.


Пароли, чувствительные к регистру символов

В Oracle Database 11g по умолчанию все пароли чувствительны к регистру символов. Однако при модернизации базы данных до версии Oracle Database 11g пароли останутся не чувствительными к регистру, и, чтобы сделать их чувствительными к регистру, нужно воспользоваться оператором ALTER USER.

Параметр инициализации SEC_CASE_SENSITIVE_LOGON управляет чувствительностью паролей к регистру. По умолчанию этот параметр установлен в значение true —т.е. по умолчанию пароли чувствительны к регистру. Если по каким-либо причинам это заданное по умолчанию поведение должно быть изменено, например, потому, что приложения требуют применения паролей, которые не чувствительных к регистру, это можно сделать, устанавливая параметр SEC_CASE_SENSITIVE_LOGON в значение false.

Изменение режима архивации журналов

Базу данных можно сконфигурировать, чтобы она работала в режиме noarchivelog или archivelog. В режиме noarchivelog база данных Oracle не будет архивировать или сохранять заполняемые ею журналы повторного выполнения. Вместо этого она будет перезаписывать их при необходимости записи нового журнального файла. В режиме archivelog Oracle вначале сохраняет заполненный файл журнала повторного выполнения и лишь затем разрешает его перезапись.

Различие между режимами archivelog и noarchivelog чрезвычайно важно. При архивировании всех заполненных журналов повторного выполнения вы будете располагать полной записью всех изменений, выполненных в базе данных с момента последнего резервного копирования. В случае утраты диска резервные копии можно использовать совместно с архивированными журналами повторного выполнения для восстановления базы данных без потери зафиксированных данных. Изменение режима ведения журналов базы данных выполняется следующим образом.

Прежде чем изменять что-либо, следует проверить режим archivelog. Это можно сделать следующим образом: 

SQL> SELECT log_mode FROM v$database;
LOG_MODE
-------------------------
NOARCHIVELOG
1 row selected.
SQL>

Другой метод — использование команды ARCHIVE LOG LIST:

SQL> ARCHIVE LOG LIST
Database log mode              No Archive Mode
Automatic archival             Disabled
Archive destination            /u02/app/oracle/oradata/arch/
Oldest online log sequence     3
Current log sequence           4
SQL> 

Эта команда показывает расположение archivelog (/u02/app/oracle/arch) и подтверждает, что база данных работает в режиме noarchivelog (No Archive Mode). Автоматическая архивация также отключена.

Теперь, когда мы убедились, что база данных действительно работает в режиме noarchivelog, посмотрим, что нужно сделать, чтобы включить архивацию в новой базе данных.

Во-первых, убедитесь в установке параметров, связанных с архивацией журналов, в файле init.ora (или SPFILE). В файле init.ora автора были добавлены (удалены метки комментария) следующие параметры: 

log_archive_dest_n = 'LOCATION=/u02/app/oracle/oradata/nina/arch'
log_archive_format = 'log%t_%s_%r.arc'

Во-вторых, необходимо остановить базу данных, чтобы она могла использовать новую информацию, связанную с архивацией журналов, которая первоначально отсутствовала или была помечена как комментарии в файле init.ora. Обратите внимание, что только параметр LOG_ARCHIVE_DEST_n доступен для динамического изменения. Второй параметр, связанный с архивацией журналов, LOG_ARCHIVE_FORMAT, является статическим, т.е. команду ALTER SYSTEM нельзя применять для изменения режима архивации журналов. Поэтому придется выполнить останов и перезапуск базы данных. Однако существует достаточная возможность обхода этого ограничения. В действительности не обязательно устанавливать статический параметр, чтобы начать архивирование. Переменная LOG_ARCHIVE_FORMAT всего лишь устанавливает формат именования архивированных файлов журналов, и если это значение не указано, их именование будет выполняться в соответствии с принятым по умолчанию соглашением по именованию archivelog Oracle.

Команда остановки базы данных имеет следующий вид: 

SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>

В-третьих, следует запустить базу данных только в режиме монтирования с помощью следующей команды:

SQL> STARTUP MOUNT 

Затем воспользуйтесь показанной ниже командой, чтобы включить архивацию журналов:

SQL> ALTER DATABASE ARCHIVELOG
Database altered.
SQL>

И, наконец, откройте базу данных. Теперь БД будет работать в режиме archivelog.

SQL> ALTER DATABASE OPEN
Database altered.
SQL> 

Удостовериться, что база данных работает в режиме rchivelog, можно с помощью следующей команды. Результат ее выполнения показывает, что база данных работает в режиме архивации, и что настройка автоматической архивации включена. 

SQL> ARCHIVE LOG LIST
Database log mode               Archive Mode
Automatic archival              Enabled
Archive destination             /u02/app/oracle/oradata/nina/arch/
Oldest online log sequence      3
Next log sequence to archive    4
Current log sequence            4
SQL>

Если по какой-то причине необходимо отключить архивацию, это можно сделать, используя команду ALTER DATABASE NOARCHIVELOG, как показано в следующем примере, после запуска командой STARTUP MOUNT:

SQL> ALTER DATABASE NOARCHIVELOG;
Database altered.
SQL> archive log list
Database log mode                No Archive Mode
Automatic archival               Disabled
Archive destination              /u02/app/oracle/oradata/nina/arch/
Oldest online log sequence       47
Current log sequence             48
SQL>

На заметку! В Oracle Database 10g Release 10.1 параметр LOG_ARCHIVE_START является устаревшим. При переводе базы данных в режим archivelog Oracle автоматически запускает архивацию журналов повторного выполнения.


Запуск файла pupbld.sql

Иногда, когда новые созданные вами пользователи пытаются получить доступ к базе данных через интерфейс SQL*Plus, могут возникать ошибки вроде следующей: 

Error accessing PRODUCT_USER_PROFILE
Warning: Product user profile information not loaded!
You may need to run PUPBLD.SQL as SYSTEM
Ошибка при обращении к PRODUCT_USER_PROFILE
Предупреждение: Информация о профиле пользователя не загружена!
Возможно, требуется запустить файл PUPBLD.SQL от имени пользователя SYSTEM

Таблица product_user_profile — таблица, которую Oracle поддерживает для управления доступом к базе данных посредством SQL*Plus. Использование таблицы product_user_profile для ограничения операций, выполняемых определенными пользователями. Войдите в систему в качестве пользователя SYSTEM и запустите следующий сценарий, чтобы убедиться в доступности этой таблицы всем пользователям, дабы их полномочия SQL*Plus могли быть соответствующим образом проверены: 

SQL> @$ORACLE_HOME/sqlplus/admin/pupbld.sql
DROP SYNONYM PRODUCT_USER_PROFILE
. . .
Synonym created.
SQL>

Использование файла параметров сервера

Файл init.ora — файл инициализации, в котором указывают значения параметров, предназначенных для использования во время создания базы данных. Но что делать, если какие-либо параметры потребуется изменить впоследствии? Это можно сделать двумя способами. Можно изменить параметры в файле init.ora, после чего остановить и снова запустить базу данных. Или же, если параметр доступен для динамического изменения, его значение можно изменить во время работы экземпляра. Хотя возможность динамического изменения параметров базы данных чрезвычайно удобна, этот подход сопряжен с рядом принципиальных проблем. При пере запуске базы данных динамически измененные параметры утрачиваются, поскольку они не нашли отражения в файле init.ora. Если динамическое изменение необходимо сделать постоянным, нужно не забыть соответствующим образом изменить файл init.ora, чтобы эти изменения стали постоянными при следующем считыванием файла базой данных при ее перезапуске. Часто администраторы БД забывают выполнить эту ручную операцию.

Файл параметров сервера служит альтернативой (или дополнением) файлу init.ora и делает динамические изменения параметров постоянными на текущей основе. Можно указать, что любые динамические изменения параметров посредством команды ALTER SYSTEM должны долговременно сохраняться в файле параметров сервера, который уже состоит из всех параметров, записанных в регулярном файле init.ora. После создания базы данных SPFILE можно создать из файла init.ora, как показано в следующем разделе статьи. Если впоследствии использовать этот файл SPFILE для запуска базы данных, все динамические изменения, выполненные в параметрах инициализации, смогут постоянно сохраняться в SPFILE. Использование файла SPFILE позволяет обеспечить, чтобы динамические изменения параметров не утрачивались между остановкой и повторным запуском базы данных.

Этот файл получил название файла сервера, поскольку он всегда поддерживается на том компьютере, на котором расположен сервер базы данных Oracle. В Oracle рекомендуют использовать файл SPFILE для динамической поддержки параметров конфигурации базы данных.

Число динамически изменяемых параметров в Oracle Database 11g достаточно велико. Более половины параметров инициализации доступны для динамического изменения с помощью оператора ALTER SYSTEM. Иными словами, SPFILE — рациональное средство постоянной записи значений динамически изменяемых параметров.

При запуске базы данных, если только тип файла инициализации и его расположение не указаны явно, вначале Oracle будет искать файл SPFILE. В системах UNIX/Linux файл SPFILE расположен в каталоге $ORACLE_HOME/dbs/ (в системах Windows — в каталоге $ORACLE_HOME\dbs). В каталоге, заданном по умолчанию, Oracle вначале ищет файл spfile$ORACLE_SID.ora (в нашем случае для базы данных nina им должен быть файл spfilenina.ora). Если этот файл не удается найти, программа ищет файл spfile.ora. Если и файл spfile.ora отсутствует, Oracle будет искать файл init.ora в этом же заданном по умолчанию каталоге. Традиционно файл init.ora получает имя init$ORACLE_SID.ora (в рассматриваемом примере — initnina.ora).


На заметку! Хотя по умолчанию файл SPFILE находится в каталоге $ORACLE_HOME/dbs, его можно помещать в любом месте, если указать размещение файла параметров инициализации посредством параметра SPFILE.


Динамическое представление V$SPPARAMETER аналогично представлению V$PARAMETER и служит для записи всех имен параметров инициализации и их значений при использовании файла SPFILE вместо init.ora.

 

Создание файла параметров сервера

Oracle позволяет использовать традиционный файл init.ora (или PFILE) в качестве файла конфигурации. Однако рекомендуется также для всех баз данных создавать и работать с файлом SPFILE. Файл SPFILE можно создать из init.ora. Этот процесс очень прост.

Вначале нужно зарегистрироваться в качестве пользователя с полномочиями SYSDBA или SYSOPER. Затем выдайте следующую команду, в которой PFILE — файл init.ora новой базы данных (initnina.ora): 

SQL> CREATE spfile
FROM
pfile = '/u03/app/oracle/dbs/initnina.ora';
File created.
SQL>

Внимание! После того как файл SPFILE создан, последующие запросы для его создания из файла init.ora будут перезаписывать существующий файл SPFILE.


Приведенная команда создаст файл SPFILE в заданном по умолчанию каталоге ($ORACLE_HOME/dbs). Файл получит имя spfilenina.ora. Файл SPFILE можно создать, присваивая ему явное имя, как показано в следующем примере:

SQL> CREATE spfile = '/u03/app/oracle/dbs/nina_spfile.ora'
FROM
pfile = '/u03/app/oracle/dbs/initnina.ora';

Если нужно, чтобы был создан файл SPFILE из init.ora, и оба файла размещаются в своих заданных по умолчанию местоположениях ($ORACLE_HOME/dbs), можно просто запустить следующую команду:

SQL> CREATE spfile FROM pfile;
File created.
SQL>

Можно также создать новый файл init.ora из файла SPFILE в заданном по умолчанию каталоге, используя такую команду: 

SQL> CREATE pfile FROM spfile;
File created.
SQL>

Если теперь перезапустить базу данных, экземпляр будет запущен с использованием нового файла SPFILE. Программа Oracle осуществит поиск списков параметров инициализации в заданных по умолчанию местоположениях в следующем порядке и применит первый из найденных списков.

  1. Выполнит поиск файла spfile$ORACLE_SID.ora в заданном по умолчанию каталоге.
  2. Выполнит поиск файла spfile.ora в заданном по умолчанию каталоге.
  3. Выполнит поиск традиционного файла init.ora с именем init$ORACLE_SID.ora в заданном по умолчанию каталоге.

Совет. Хотя текстовый файл init.ora можно изменять любым удобным способом, не изменяйте файл SPFILE непосредственно. Это приведет к его повреждению, и запуск экземпляра может оказаться невозможным при следующей попытке использования файла SPFILE!


Создание файла SPFILE из файла init.ora не означает, что файл init.ora больше нельзя использовать. Если нужно запустить экземпляр с применением исходного файла init.ora, это можно сделать, как и раньше, указав его явно:

SQL> STARTUP PFILE='/u01/app/oracle/product/10.1.0.2.0/dbs/initnina.ora';

Однако в приведенном примере нельзя указать файл SPFILE вместо PFILE — Oracle не позволит указать SPFILE непосредственно в команде STARTUP. Тем не менее, это можно сделать косвенно, используя файл PFILE (init.ora), содержащий всего один параметр инициализации — SPFILE:

spfile = '/u01/app/oracle/product/10.1.0.2.0/dbs/spfilenina.ora'

После создания этого нового файла init.ora переменную PFILE можно указать в команде STARTUP, как было показано ранее.

Содержимое файла SPFILE (названного SPFILEnina.ora), который был создан из файла initnina.ora, приведено в листинге 10.8.


 

*.compatible='11.1.0.6'
*.control_files='/u01/app/oracle/oradata/nina/control1.ctl',
'/u01/app/oracle/oradata/nina/control2.ctl'
*.cursor_sharing='force'
*.db_block_size=8192
*.db_domain='world'
*.db_file_multiblock_read_count=16
*.db_files=1000
* db_flashback_retention_target=720 *.db_name='nina'
*.db_recovery_file_dest='/u02/app/oracle/flash_recov_area'
*.db_recovery_file_dest_size=1000M
* instance_type='RDBMS' *.log_archive_dest_1='LOCATION=/u02/app/oracle/arch/'
*.log_archive_format='log%t_%s_%r.arc'
*.pga_aggregate_target=1000M
*.processes=600
*.remote_login_passwordfile='none'
*.resumable_timeout=1800
*.sga_target=300M
*.statistics_level='typical'
*.undo_management='auto'
*.undo_retention=7200
*.undo_tablespace='undotbs_01'
*.

Совет. Администраторы баз данных привыкли помещать комментарии в файл init.ora, но файл SPFILE не будет содержать строки комментариев из init.ora. Тем не менее, файл SPFILE будет сохранять комментарии, помещенные в файл init.ora в одной строке с параметром (например, CURSOR_SHARING=false # комментарий).


 

Установка диапазона динамических изменений параметров

Теперь мы располагаем файлом SPFILE, который содержит все параметры инициализации, и можем управлять тем, будут ли любые изменения параметров инициализации сохраняться в SPFILE. Как только SPFILE создан, специальную конструкцию SCOPE можно использовать в качестве составной части всех команд ALTER SYSTEM, которая будет определять, будут ли сохраняться изменения. Конструкция SCOPE может принимать одно из следующих трех значений:

  • SPFILE
  • MEMORY
  • BOTH

Когда конструкция SCOPE установлена в MEMORY, изменения являются всего лишь временными и утрачиваются при перезапуске базы данных. Когда SCOPE установлена в BOTH, все динамические изменения записываются в SPFILE и немедленно становятся действующими в экземпляре. Когда SCOPE установлена в SPFILE, изменения не применяются немедленно, а только записываются в SPFILE. Динамические и статические параметры конфигурации вступают в действие только после следующего запуска базы данных. Если экземпляр базы данных запускается с применением SPFILE, по умолчанию Oracle использует вариант SCOPE=BOTH.


На заметку! Для статических параметров вариант SCOPE=SPFILE является единственно доступным, поскольку немедленная активизация этих параметров невозможна по определению.


Как видите, существует огромная свобода выбора того, насколько долго должны сохраняться изменения динамически конфигурируемых параметров. Вот несколько примеров: 

SQL> ALTER SYSTEM SET
log_archive_dest_2='location=/test02/app/oracle/oradata/arch'
SCOPE=SPFILE;
SQL> ALTER SYSTEM SET log_checkpoint_interval=600
SCOPE=MEMORY;
SQL> ALTER SYSTEM SET license_max_users=200
SCOPE=BOTH;

RMAN, утилита резервного копирования и восстановления Oracle, будет автоматически выполнять резервное копирование файла параметров сервера при резервном копировании базы данных. Если требуется изменить несколько параметров в файле SPFILE, проще всего сделать это, вначале создав файл init.ora из файла SPFILE (как описано в предыдущем разделе этого гайда), внести изменения в файл init.ora, а затем из него создать новый файл SPFILE. Однако этот процесс требует перезапуска базы данных.


Совет. Всегда создавайте файл SPFILE сразу после создания исходной базы данных. В новой базе данных придется вносить множество изменений параметров инициализации, и SPFILE предоставляет возможность сделать эти изменения постоянными, если это требуется. Этот подход избавляет от множества неприятностей впоследствии, при внесении изменений сразу в несколько параметров инициализации.


 

Создание SPFILE или PFILE из памяти

SPFILE или PFILE можно воссоздать из текущих значений параметров инициализации, используемых экземпляром в данный момент времени. Следующая команда создаст файл SPFILE из текущих используемых значений:

SQL> CREATE spfile FROM MEMORY;

Эта команда создает новый файл SPFILE в каталоге по умолчанию, но можно указать и другой каталог. Аналогично можно создать обычный файл параметров инициализации: 

SQL> CREATE pfile FROM MEMORY;

Эта команда пригодится в случае утраты текущего файла параметров. В среде RAC эта команда будет перехватывать настройки параметров, используемые каждым экземпляром в системе.

 

Запуск и остановка базы данных из интерфейса SQL*Plus

Базу данных Oracle можно запускать и останавливать из интерфейса SQL*Plus, интерфейса OEM и интерфейса RMAN. В данной статье будет рассмотрено выполнение этих операций посредством интерфейса SQL*Plus.

 

Запуск базы данных Oracle

При выдаче команды STARTUP для запуска базы данных Oracle, будет производиться поиск параметров инициализации в заданном по умолчанию каталоге, $ORACLE_HOME/dbs (в системах UNIX/Linux). В нем Oracle будет искать подходящий файл инициализации в следующем порядке:

  • spfile$ORACLE_SID.ora
  • spfile.ora
  • init$ORACLE_SID.ora

На заметку! Независимо от того, какой файл считывает Oracle, указание пути и местоположения файла, расположенного в заданном по умолчанию каталоге, не обязательно. Если же вы хотите хранить файл инициализации в каталоге, отличном от заданного по умолчанию, его местоположение должно быть указано в командах запуска.


Базу данных Oracle можно запускать в нескольких режимах. Давайте кратко рассмотрим различные возможности запуска базы данных.

Команда STARTUP NOMOUNT

В сеансе SQL*Plus можно запустить только экземпляр с использованием команды STARTUP NOMOUNT. При открытии базы данных в этом режиме управляющие файлы не считываются, а файлы данных не открываются. Фоновые процессы Oracle запускаются, а область SGA выделяется Oracle операционной системой. Фактически в этом режиме экземпляр работает сам по себе, подобно тягачу без прицепа (в обоих случаях пользы от этого не много). Результаты выполнения команды STARTUP NOMOUNT приведены в листинге 10.9.


 

SQL> STARTUP NOMOUNT
ORACLE instance started.
Total System Global Area        314572800 bytes
Fixed Size                        1236756 bytes
Variable Size                    99164396 bytes
Database Buffers                213909504 bytes
Redo Buffers                      5169152 bytes
SQL>

Иногда во время выполнения определенных операций по обслуживанию и во время восстановления база данных не может оставаться открытой для публичного доступа.

Подобное частичное открытие базы данных требуется именно в таких случаях. Опцию запуска NOMOUNT используют также во время создания базы данных и при необходимости воссоздания управляющих файлов.

Команда STARTUP MOUNT

Следующий шаг процесса запуска после запуска экземпляра — монтирование базы данных. На этапе монтирования Oracle связывает экземпляр с базой данных. Oracle открывает и считывает управляющие файлы и извлекает имена и местоположения файлов данных и файлов журналов повторного выполнения. Можно монтировать уже запущенный экземпляр с помощью команды ALTER DATABASE, либо можно воспользоваться командой STARTUP MOUNT при первоначальном запуске базы данных.

Если база данных уже запущена в режиме nomount, применяйте следующую команду: 

SQL> ALTER DATABASE MOUNT;
Database altered.
SQL>

Для запуска в режиме mount служит такая команда:

SQL> STARTUP MOUNT
ORACLE instance started.
Total System Global Area          314572800 bytes
Fixed Size                          1236756 bytes
Variable Size                      99164396 bytes
Database Buffers                  213909504 bytes
Redo Buffers                        5169152 bytes
Database mounted.
SQL> 

Базу данных необходимо запускать в режиме монтирования при выполнении таких действий, как полное восстановление базы данных, изменение режима архивации журналов или переименовании файлов данных. Обратите внимание, что все эти операции требуют, чтобы ПО Oracle осуществляло доступ к файлам данных, но при этом оно не может обрабатывать какие-либо операции пользователей по отношению к файлам.

Команда STARTUP OPEN

Последний этап процесса запуска — открытие базы данных. Когда база данных запущена в режиме открытия, все легальные пользователи могут подключаться к БД и выполнять операции базы данных. До завершения этого этапа обычные пользователи вообще не могут подключаться к базе данных. Базу данных можно перевести в режим открытия, выдав следующую команду ALTER DATABASE: 

SQL> ALTER DATABASE OPEN;
Database altered.

Чаще просто используют команду STARTUP для одновременного монтирования и открытия базы данных:

SQL> STARTUP
Oracle instance started.
Total System Global Area    314572800 bytes
Fixed Size                  1236756 bytes
Variable Size               99164396 bytes
Database Buffers            213909504 bytes
Redo Buffers                5169152 bytes
Database mounted.
Database opened.
SQL>

Чтобы открыть базу данных, сервер Oracle вначале открывает все файлы данных и файлы оперативных журналов повторного выполнения и проверяет целостность базы данных. Если целостность базы данных нарушена — например, если информация SCN в управляющих файлах не соответствует информации SCN в заголовках файлов данных — перед открытием базы данных фоновый процесс автоматически выполнит восстановление экземпляра. Если требуется восстановление носителя, а не восстановление экземпляра, Oracle сообщит о вызове программы восстановления базы данных и не откроет базу данных до завершения восстановления.


На заметку! При выдаче простой команды STARTUP Oracle последовательно выполнит все действия по запуску и одновременно запустит экземпляр и откроет его для публичного доступа. До тех пор, пока значение параметра ORACLE_SID соответствует запускаемой базе данных, ее имя можно не указывать в команде STARTUP.


Автоматический запуск баз данных Oracle

Автоматический запуск всех баз данных при каждом перезапуске операционной системы можно обеспечить, просто применяя стандартные сценарии операционной системы. Каждая база данных будет использовать собственный способ автоматизации запуска базы данных Oracle. В этом разделе мануала мы рассмотрим сценарии запуска и остановки баз данных в системах UNIX/Linux — приведенные примеры соответствуют среде Red Hat Linux.

Oracle предлагает два файла dbstart и dbshut, которые используют содержимое стандартного файла /etc/oratab для определения действующих на сервере баз данных Oracle и автоматического запуска и остановки всех баз данных при запуске и остановке системы. В большинстве систем UNIX/Linux эти два сценария находятся в каталоге $ORACLE_HOME/bin. После создания новой базы данных nina она была добавлена в файл oratab за счет добавления следующей строки (которая указывает имя базы данных, каталог ORACLE_HOME и то, должна ли база данных автоматически останавливаться и запускаться): 

nina:/u01/app/oracle/product/10.2.0/db_1:Y

Чтобы запуск и остановка базы данных выполнялись автоматически при перезагрузке системы, сценарий потребуется добавить в каталог /etc/rc.d/init.d. Этот файл будет содержать предоставляемые Oracle сценарии dbstart и dbshut, как показано в листинге 10.10. Сценарий использует оператор выбора для определения того, нужно запускать или останавливать все базы данных Oracle и службу Oracle Listener.


 

#!/bin/sh
# /etc/rc.d/init.d/oracle
# Описание: Следующий сценарий запускает и останавливает
# все базы данных и службы прослушивания Oracle
case "$1" in
start)
echo -n "Starting Oracle Databases: "
date +"! %T %a %D : Starting Oracle Databases after
system start up." >> /var/log/oracle
echo "-------------------------------------" >> /var/log/oracle
su - oracle -c dbstart >> /var/log/oracle
echo "Done."
echo -n "Starting Oracle Listeners: "
su - oracle -c "lsnrctl start" >> /var/log/oracle
echo "Done."
echo ""
echo "--------------------------------------" >> /var/log/oracle
date +"! %T %a %D : Finished." >> /var/log/oracle
echo "--------------------------------------" >> /var/log/oracle
;;
stop)
echo -n "Shutting Down Oracle Listeners: "
echo "----------------------------------------" >> /var/log/oracle
date +"! %T %a %D : Shutting Down All Oracle Databases
as part of system shutdown." >> /var/log/oracle
echo "----------------------------------------" >> /var/log/oracle
su - oracle -c "lsnrctl stop" >> /var/log/oracle
echo "Done."
echo -n "Shutting Down Oracle Databases: "
su - oracle -c dbshut >> /var/log/oracle
echo "Done."
echo ""
echo "-----------------------------------------" >> /var/log/oracle
date +"! %T %a %D : Finished." >> /var/log/oracle
echo "-----------------------------------------" >> /var/log/oracle
;;
restart)
echo -n "Restarting Oracle Databases: "
echo "------------------------------------------" >> /var/log/oracle
date +"! %T %a %D : Restarting Oracle Databases
after system startup." >> /var/log/oracle
echo "------------------------------------------" >> /var/log/oracle
su - oracle -c dbshut >> /var/log/oracle
su - oracle -c dbstart >> /var/log/oracle
echo "Done."
echo -n "Restarting the Oracle Listener: "
su - oracle -c "lsnrctl stop" >> /var/log/oracle
echo "Done."
echo ""
echo "---------------------------------------------" >> /var/log/oracle
date +"! %T %a %D : Finished." >> /var/log/oracle
echo "---------------------------------------------" >> /var/log/oracle
;;
*)
echo "Usage: oracle {start|stop|restart}"
exit 1
esac

Системный администратор должен создать символьные ссылки запуска и остановки в каталогах /etc/rc.d/rcX.d соответствующего уровня выполнения. Следующие команды обеспечат, чтобы базы данных запускались на уровнях выполнения 2, 3 и 4. 

$ ln -s ../init.d/oracle /etc/rc.d/rc2.d/S99oracle
$ ln -s ../init.d/oracle /etc/rc.d/rc3.d/S99oracle
$ ln -s ../init.d/oracle /etc/rc.d/rc4.d/S99oracle

Чтобы базы данных останавливались при каждой перезагрузке или перезапуске хоста, потребуется также добавить следующие ссылки:

$ ln -s ../init.d/oracle /etc/rc.d/rc0.d/K01oracle # Остановка
$ ln -s ../init.d/oracle /etc/rc.d/rc6.d/K01oracle # Перезагрузка 

Ограничение доступа к базе данных

Иногда при выполнении загрузки данных, экспорте или импорте данных или же при решении других важных задач обслуживания требуется, чтобы база данных была открыта для вас, но не для обычных пользователей. Этого можно достичь несколькими различными способами. Во-первых, базу данных можно перевести в ограниченный режим, в котором вам будет предоставлен полный доступ, а подключение обычных пользователей будет запрещено, как показано в листинге 10.11.


 

SQL> STARTUP RESTRICT;
ORACLE instance started.
Total System Global Area              314572800 bytes
Fixed Size                              1236756 bytes
Variable Size                          99164396 bytes
Database Buffers                      213909504 bytes
Redo Buffers                            5169152 bytes
Database mounted.
Database opened.
SQL>

По завершении обслуживания или других задач базу данных можно открыть для всеобщего использования, просто выдав команду ALTER SYSTEM, как показано в следующем примере:

SQL ALTER SYSTEM DISABLE RESTRICTED SESSION;
System altered.
SQL>

Открытую и неограниченную базу данных можно также перевести в режим ограничения, используя такую команду: 

SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;
System altered.
SQL>

При переводе базы данных в ограниченный режим с помощью команды ALTER SYSTEM, как показано в предыдущем примере, права существующих пользователей никак не ограничиваются. Запрещена регистрация новых пользователей, если только они не обладают полномочиями подключения к ограниченному сеансу. По завершении выполняемых задач базу данных можно снова перевести в открытый неограниченный режим с помощью команды ALTER SYSTEM DISABLE RESTRICT SESSION. Иногда может требоваться использовать открытую базу данных, но временно запретить любые изменения в ней. То есть нужно разрешить операции чтения (операции SELECT) в базе данных, но не операции записи. Перевод базы данных в режим только для чтения продемонстрирован в листинге 10.12.


 

SQL> STARTUP MOUNT
ORACLE instance started.
Total System Global Area             314572800 bytes
Fixed Size                             1236756 bytes
Variable Size                         99164396 bytes
Database Buffers                     213909504 bytes
Redo Buffers                           5169152 bytes
Database mounted.
SQL> ALTER DATABASE OPEN READ ONLY;
Database altered.
SQL>

Обычно режим только для чтения применяется в резервных базах данных, которые представляют собой копии производственных баз данных, предназначенные для снятия части нагрузки по запросу родительской производственной БД.

 

Остановка базы данных Oracle

Остановка работающей базы данных может требоваться для выполнения некоторых типов резервного копирования, для модернизации программного обеспечения и т.п. Это можно сделать несколькими способами. Выбранный вариант будет влиять на время, затрачиваемое на остановку базы данных, и на возможную необходимость восстановления экземпляра базы данных при ее перезапуске. Четыре доступных опции команды остановки базы данных описаны в следующих разделах данного мануала.

Команда SHUTDOWN NORMAL

При выдаче команды SHUTDOWN NORMAL для остановки базы данных Oracle дождется отключения всех пользователей от базы данных, прежде чем остановить ее. Если пользователь уедет в отпуск на неделю после регистрации в базе данных, а вы выдадите команду SHUTDOWN NORMAL, базе данных придется продолжать работать до тех пор, пока пользователь не вернется и не выйдет из нее. Нормальный режим — используемый по умолчанию режим остановки базы данных Oracle. Выдача команды осуществляется следующим образом: 

SQL> SHUTDOWN NORMAL

или

SQL> SHUTDOWN 

Ниже описаны некоторые особенности команды SHUTDOWN NORMAL.

  • После выполнения этой команды никакие подключения новых пользователей невозможны.
  • Прежде чем остановить базу данных, Oracle дожидается, пока все пользователи выйдут из своих сеансов.
  • При перезапуске базы данных никакое восстановление экземпляра не требуется, поскольку перед остановкой Oracle запишет все буферы журналов повторного выполнения и буферы блоков данных на диск. Таким образом, при такой остановке база данных сохраняет целостность.
  • Oracle закрывает файлы данных и прерывает фоновые процессы. Область SGA Oracle освобождается.

Команда SHUTDOWN TRANSACTIONAL

Если нет желания долго ожидать выхода пользователя из базы данных, можно воспользоваться командой SHUTDOWN TRANSACTIONAL. Oracle дождется завершения всех активных транзакций, прежде чем отключить всех пользователей от базы данных, а затем остановит базу данных. Выдача команды выполняется следующим образом: 

SQL> SHUTDOWN TRANSACTIONAL

Ниже перечислены некоторые особенности команды SHUTDOWN TRANSACTIONAL.

  • После выполнения этой команды никакие подключения новых пользователей невозможны.
  • Существующие пользователи не могут начать новую транзакцию и будут отключены от базы данных.
  • Если у пользователя имеется выполняющаяся транзакция, Oracle дождется завершения этой транзакции, прежде чем отключить пользователя.
  • После завершения всех существующих транзакций Oracle останавливает экземпляр и освобождает память. Oracle записывает все буферы журналов повторного выполнения и буферы блоков данных на диск.
  • Никакое восстановление экземпляра не требуется, поскольку база данных сохраняет целостность.

Команда SHUTDOWN IMMEDIATE

Иногда на момент принятия решения об остановке базы данных пользователь может выполнять очень продолжительную транзакцию. В такой ситуации оба ранее описанных режима остановки оказываются бесполезными. В режиме SHUTDOWN IMMEDIATE Oracle не будет дожидаться ни выхода пользователя из сеанса, ни завершения каких-либо транзакций. Будет просто выполнен откат всех активных транзакций, отключение все подключенных пользователей и останов базы данных. Эта команда имеет следующий вид: 

SQL> SHUTDOWN IMMEDIATE

Ниже описаны некоторые особенности команды SHUTDOWN IMMEDIATE.

  • После выполнения этой команды никакие подключения новых пользователей невозможны.
  • Oracle немедленно отключает всех пользователей.
  • Oracle прерывает все выполняющиеся в текущий момент транзакции.
  • Для всех транзакций, прерванных в процессе выполнения, Oracle выполнит откат, чтобы в конечном итоге база данных сохранила целостность. Именно этот процесс отката является причиной того, что команда SHUTDOWN IMMEDIATE не всегда выполняется немедленно. Это обусловлено тем, что Oracle занят откатом только что прерванных транзакций. Однако если никаких активных транзакций не существует, команда SHUTDOWN IMMEDIATE остановит базу данных очень быстро. Oracle прерывает фоновые процессы и освобождает память.
  • При запуске базы данных никакое восстановление экземпляра не требуется, поскольку при остановке она сохраняет целостность.

Команда SHUTDOWN ABORT

Команда SHUTDOWN ABORT останавливает базу данных очень быстро. Выполняемым в текущий момент транзакциям не предоставляется возможность ни для завершения, ни для отката. Подключения пользователей просто разрываются. Эта команда имеет следующий вид: 

SQL> SHUTDOWN ABORT

Ниже перечислены некоторые особенности команды SHUTDOWN ABORT.

  • После выполнения этой команды никакие новые подключения невозможны.
  • Существующие сеансы прерываются, независимо от наличия в них активных транзакций.
  • Oracle не выполняет откат прерванных транзакций.
  • Oracle не записывает буферы журналов повторного выполнения и буферы блоков данных на диск.
  • Oracle прерывает фоновые процессы, немедленно освобождает память и останавливает базу данных.
  • При перезапуске Oracle выполнит автоматическое восстановление экземпляра, поскольку целостность базы данных при остановке не гарантируется.

При остановке базы данных по команде SHUTDOWN ABORT во время перезапуска база данных должна выполнить восстановление экземпляра, чтобы обеспечить целостность в плане транзакций, поскольку могут существовать незафиксированные транзакции, которые нуждаются в откате. Важно помнить, что при выдаче команды SHUTDOWN ABORT база данных может быть остановлена в нецелостном состоянии. В большинстве случаев явное использование команды RECOVER не обязательно, поскольку база данных будет выполнять восстановление экземпляра по собственной инициативе.


Совет. В Oracle рекомендуют перед сохранением резервной копии всегда останавливать базу данных в режиме сохранения целостности, используя команду SHUTDOWN или SHUTDOWN IMMEDIATE, а не SHUTDOWN ABORT.


В листинге 10.13 показано, что происходит при попытке перевода базы данных в режим только для чтения после того, как вначале команда SHUTDOWN ABORT была использована для ее остановки. Обратите внимание, что Oracle не переведет файлы данных в режим только для чтения до тех пор, пока база данных не будет восстановлена вручную.


 

SQL> SHUTDOWN ABORT
ORACLE instance shut down.
SQL> STARTUP MOUNT
ORACLE instance started.
Total System Global Area             314572800 bytes
Fixed Size                             1236756 bytes
Variable Size                         99164396 bytes
Database Buffers                     213909504 bytes
Redo Buffers                           5169152 bytes
Database mounted.
SQL> ALTER DATABASE OPEN READ ONLY;
alter database open read only
*
ERROR at line 1:
ORA-16005: database requires recovery
ОШИБКА в строке 1:
ORA-16005: база данных требует восстановления
SQL> RECOVER DATABASE;
Media recovery complete.
SQL>

На заметку! Во всех режимах остановки при выдаче команды SHUTDOWN все попытки подключения новых пользователей будут безуспешными. За исключением команды SHUTDOWN ABORT, все остальные команды SHUTDOWN не будут требовать восстановления экземпляра при запуске базы данных.


Замораживание базы данных

Предположим, что базу данных нужно перевести в ограниченный режим для выполнения реорганизации таблиц или какой-то другой административной задачи. Изменения схемы особенно трудно проводить, если пользователи осуществляют оживленные транзакции в базе данных. Это же относится к необходимости импорта данных в большую таблицу, в то время как пользователи подключены к базе данных. Эти действия нужно выполнять во время так называемого “окна для обслуживания”, или же придется остановить базу данных и перевести ее в ограниченный режим.

Но что делать, если вы не располагаете окном для обслуживания, во время которого можно остановить и перезапустить базу данных? Или, как это часто происходит на практике, предполагаемое окно исчезает, поскольку в выделенном для него интервале времени возникает какая-либо проблема? В большинстве таких случаев приходится дожидаться следующих выходных. Для решения этой проблемы замораживание базы данных предоставляет возможность перевода базы данных в однопользовательский режим без необходимости ее остановки.

Когда администратор БД переводит ее в замороженное состояние, происходит следующее.

  • Все неактивные сеансы лишаются возможности выдачи любых команд базы данных до тех пор, пока она не будет разморожена.
  • Всем активным сеансам разрешается выполнять накопление данных.
  • Все новые попытки регистрации будут поставлены в очередь. Пользователь, пытающийся зарегистрироваться, пока база данных заморожена, не будет получать сообщение об ошибке. Вместо этого его попытка регистрации будет выглядеть зависшей.
  • В базе данных будет разрешено выполнение запросов, транзакций и операторов PL/SQL только администратора БД. Точнее говоря, запросы и операторы, выданные всеми пользователями из группы потребителей Oracle Resource Manager SYS_GROUP.

Чтобы перевести базу данных в замороженное состояние, необходимо воспользоваться следующей командой ALTER SYSTEM, выданной от имени пользователя SYS или SYSTEM:

SQL> ALTER SYSTEM QUIESCE RESTRICTED;
System altered.
SQL>

Позже, после окончания выполнения административных задач, обычным пользователям можно разрешить доступ к базе данных, выполнив следующую команду: 

SQL> ALTER SYSTEM UNQUIESCE;
System altered.
SQL>

Как только база данных будет разморожена, все запросы на вход в базу данных, помещенные в очередь, будут разрешены, и все неактивные транзакции снова смогут становиться активными, получив право на выполнение операторов DML.

 

Приостановка базы данных

Если нужно приостановить все операции ввода-вывода во время выполнения определенной административной задачи, базу данных можно приостановить. Когда база данных приостановлена, все операции считывания и записи в файлах данных и управляющих файлах запрещены. Приостановка активности в базе данных может требоваться, например, когда необходимо выполнить аварийное резервное копирование табличного пространства, либо для выполнения таких специализированных задач, как разделение зеркала, которые нельзя выполнить иным способом.

Приостановку и возобновление работы базы данных можно выполнить следующим образом: 

SQL> ALTER SYSTEM SUSPEND;
System altered.
SQL> ALTER SYSTEM RESUME;
System altered.
SQL>

 

Удаление базы данных Oracle

В прошлом администраторы БД постоянно жаловались на невозможность выдачи простой команды DROP DATABASE для удаления базы данных. Начиная с версии Oracle Database 10g, базу данных можно удалить с помощью простой команды DROP DATABASE. При выдаче этой команды все файлы данных, файлы журналов повторного выполнения и управляющие файлы удаляются автоматически. Однако эта команда не удаляет никакие файлы параметров вроде init.ora и alert.log.

Для выполнения этой операции базу данных нужно запустить в режиме RESTRICT MOUNT, как показано в листинге 10.14.


 

SQL> CONNECT sys/sys_passwd AS SYSDBA
Connected to an idle instance.
SQL> STARTUP RESTRICT MOUNT
ORACLE instance started.
Total System Global Area               314572800 bytes
Fixed Size                               1236756 bytes
Variable Size                           99164396 bytes
Database Buffers                       213909504 bytes
Redo Buffers                             5169152 bytes
Database mounted.
SQL> SELECT name FROM v$database;
NAME
---------
NINA
SQL> DROP DATABASE;
Database dropped.
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.0.0 -Beta
With the Partitioning, OLAP and Data Mining options
SQL>

Команда STARTUP RESTRICT MOUNT гарантирует невозможность подключения других пользователей к базе данных. Перед использованием команды DROP DATABASE для удаления базы данных тщательно проверьте указываемое имя базы данных.


Внимание! По вполне понятным причинам команду DROP DATABASE нельзя применять из простого любопытства. Будьте внимательны, поскольку она не прощает ошибок — у вас не будет никакой возможности отменить ее. Все файлы данных, файлы журналов и управляющие файлы исчезнут раньше, чем вы успеете моргнуть глазом.


 

Использование словаря данных для отслеживания состояния базы данных

Динамическое представление V$INSTANCE удобно при мониторинге текущего состояния экземпляра. Следующий запрос показывает, что база данных открыта, и никакие операции остановки не ожидают возможности выполнения:

 

SQL> SELECT instance_name, status,
2 shutdown_pending,
3 active_state
4* FROM v$instance
SQL> /
INST     STATUS     SHUTDOWN      ACTIVE
NAME     PENDING    STATE
-------- ---------- ------------- ---------
nina     OPEN       NO            NORMAL
SQL> 

В приведенном выводе состояние указано как NORMAL, т.е. база данных не пребывает ни в процессе замораживания, ни в уже замороженном состоянии. В столбце состояния базы данных указано состояние OPEN (открыта) в то время как для приостановленной БД было бы указано состояние SUSPENDED (приостановлена).

Представление DATABASE_PROPERTIES предоставит имя заданных по умолчанию временных табличных пространств базы данных, а также ряд дополнительных сведений о параметрах NLS.

Представление V$DATABASE позволяет получить множество подробностей о базе данных. Ниже приведен типичный запрос, который отображает имя базы данных, показывает, включена ли архивация журналов (YES) и то, работает ли база данных в режиме ретроспективного просмотра (NO):

 

SQL> SELECT name, log_mode, flashback_on FROM v$database;
NAME        LOG_MODE         FLASHBACK_ON
----------- ---------------- -------------------
PASPROD     ARCHIVELOG       NO
SQL>

 

Действия после создания базы данных Oracle

Итак, мы создали новую базу данных, однако осталось выполнить еще несколько действий, чтобы сделать ее полностью функциональной (терпение — мы почти у цели!). На этом этапе мы располагаем запущенным и действующим экземпляром и первым черновым вариантом физической базы данных, полученным экспериментальным путем.

Чтобы эта база данных Oracle могла делать хоть что-нибудь полезное, потребуется создать пользователей. А чтобы предоставить пользователям необходимые возможности и обеспечить безопасность базы данных, этим пользователям нужно назначить специфичные роли и полномочия. Нам предстоит создать такие объекты, как таблицы, представления, индексы, синонимы, последовательности и т.п., исходя из требований команды по разработке приложения. В базе данных Oracle понадобится создать также необходимый код приложения, включая хранимые процедуры и пакеты. Поскольку пустая база данных без самих данных бесполезна, нам предстоит загрузить данные в БД. Нужно также установить связь между только что созданной базой данных, пользователями и другими системами, которым требуется доступ к базе данных.

И, наконец, прежде чем отправиться в долгожданный и заслуженный отпуск, чтобы защитить базу данных от неожиданных сбоев и некорректно функционирующих систем, нужно выполнить резервное копирование БД и определить регулярную схему резервного копирования. В новых статьях моего блога я подробно освещу все эти важные темы.

 

Вас заинтересует / Intresting for you:

Видеокурс по администрированию...
Видеокурс по администрированию... 6914 просмотров Илья Дергунов Mon, 14 May 2018, 05:08:47
Поддерживаемые Oracle типы дан...
Поддерживаемые Oracle типы дан... 3943 просмотров Валерий Павлюков Wed, 24 Oct 2018, 08:00:37
Oracle и непроцедурный доступ ...
Oracle и непроцедурный доступ ... 6782 просмотров Antoni Tue, 21 Nov 2017, 13:32:50
СУБД Oracle: обзор характерист...
СУБД Oracle: обзор характерист... 4079 просмотров Antoni Fri, 24 Nov 2017, 07:35:05

Войдите чтобы комментировать

admin аватар
admin ответил в теме #9405 08 мая 2019 10:52
Великолепное дополнение к оф. документации. Только язык человеческий, не "сухой". Спасибо!
Gwen аватар
Gwen ответил в теме #9282 14 нояб 2018 12:46
Вот это мануалец обстряпали!!! Параметры Оракловой базы данных описаны на 5 с плюсом!)))
apv аватар
apv ответил в теме #8840 11 нояб 2017 07:15
База данных Oracle является самой мощной и совершенной на текущей момент и рулит на рынке СУБД. Спасибо за подробнейший мануал по созданию БД. Множество разнообразных и гибких настроек делают эту базу данных универсальной!