• Настройка и управление сети Oracle

    Сеть это неотъемлемая часть клиент-серверной архитектуры, которая является фундаментальное составляющей всех современных баз данных. У БД Oracle была возможность для клиент-серверных вычислений с самого начала (версия 1, выпущенная в 1978 году использовала разделение между кодом Oracle и пользовательским кодом), но только в версии 4 в 1984 году Oracle представила разделение между компьютером пользователя и сервером. Настоящая поддержка клиент-серверной архитектуры наступила с версией 5 в 1986 году. В это главе мы рассмотрим сервис Oracle Net, который раньше назывался Sqlnet и некоторые DBA до сих пор используют это название.

    По умолчанию Oracle Net настроена как выделенный сервер (dedicated server). В такой конфигурации каждому пользовательскому процессу, подключенному к БД, будет создаваться свой серверный процесс. Альтернативой этой конфигурации является конфигурация разделяемого сервера (shared server), где все пользовательские процессы используют фиксированный набор серверных процессов, разделяемых между пользовательскими сессиями. DBA неохотно используют shared server архитектуру, однако знание это конфигурации необходимо.

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

    Oracle Net и клиент-серверная парадигма

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

    Пользователь взаимодействует с пользовательским процесс: это приложение которое запущено на локальной машине. Например Microsoft Acces и ODBC Driver, либо приложение написанное на C и использующее OCI библиотеки или SQL *Plus. Какое бы это ни были приложение, назначение пользовательского процесса одинаковое – позволить пользователю вводить информацию, которую приложение может использовать для генерации SQL запросов. В случае SQL *Plus пользовательский процесс будет просто ждать ввода запроса —  более продвинутые инструменты могут отображать свойства объектов БД, генерировать и валидировать SQL команды, в любом случае будет сформирован SQL запрос, который передаётся серверному процессу.

    Серверный процесс работает на сервере базы данных и выполняет запросы, полученные от пользовательского процесса. Это базовое клиент-серверное разделение: пользовательский процесс создаёт SQL, серверный процесс выполняет. Выполнение SQL запроса происходит в четыре этапа: разбор (parse), связывание (bind), выполнение (execute) и выборка(fetch).  На этапе разбора сервер определяет валиден ли запрос, какие объекты используются и как выполнить запрос максимально быстро. Разбор использует shared pool: стурктуры памями используются для преобразования SQL в исполняемый код. На этапе связсывания – все переменные преобразуются в литералы. Этап выполнения будет использовать SGA и возможно саму базы данных. Во время выполнения данные в буфере кэша будет считываться или обновляться, изменения записываться в буфер логов, и если необходимых блоков нету в буфере серверный процесс считает их из файлов данных. Это единственный момент времени при выполнении запроса когда используется сама база данных. И, наконец, на этапе выборки серверный процесс отправит результирующий набор данных полученный в результате выполнения запроса назад пользовательскому процессу, и пользовательский процесс преобразует результат для отображения.

    Oracle net предоставляет механизм для запуска серверного процесса, который будет выполнять код от имени пользовательского процесса. Этот механизм называют установкой сессии. Также Oracle Net используется для поддержки сессий: передачу SQL запросов от пользовательского процесса к серверному, и получение результатов выполнения запросов от сервеного процесса к пользовательскому.

    На рисунке 4-1 отображены компоненты сессии. Пользователь взаимодействует с пользовательским процессом, пользовательский процесс в свою очередь взаимодействует с серверным процессом используя Oracle Net; серверный процесс работает с экземпляром БД и экземпляр при помощи фоновых процессов работает с базой данных. Клиен-серверное разделение осуществляется между пользовательским процессом создающим SQL запросы и серверным процессом выполняющим их. Это разделение обычно будет и физическим, так же как логическим: обычно серверные и клиентские машины соединены с помощью локальной сети, так же они могут соединяться с помощью сети интернет или вообще работать на одной физической машине. Oracle Net отвечает за установку соединения (создание сессии) и все взаимодействие между серверным и пользовательским процессом.

    25

    Установка соединения (создание сессии)

    Когда пользователь хочет подключиться к БД используется команда вида

    CONNECT STORE/ADMIN123@ORCL11G

    Конечно если используется инструмент с графическим интерфейсом вы не будете писать такую команду, ваше приложение просто спросит все необходимые данные для подключения и команда будет сгенерирована пользовательским процессом. Разберём эту команду. Вначале идёт имя базы данных (STORE) и пароль (ADMIN123) разделённые символом “/”. Затем идёт символ “@” после которого строка подключения “ORCL11G”. Символ “@” является идентификатором для пользовательской сессии указывающим что сетевое подключение необходимо. Если пропустить этот символ и не указывать строку подключения, тогда пользовательский процесс преполагает что экземпляр к которому вы хотите подключиться запущен на локальной машине и он всегда доступен с помощью IPC протокола. Если символ “@” и строка подключения указаны, тогда пользовательский процесс будет использовать сетевое подключение для работы с удаленной машины – хотя фактически, сервер может быть той же локальной машиной и вы будете посылать запрос и принимать одной и той же сетевой картой локальной машины.

    Подключение к локальному экземпляру

    Даже когда вы подключаетесь к экземпляру работающему на локальной машине, вы всё равно используете Oracle Net. Все сессии используют сетевой протокол для разделения пользовательского когда от серверного, но для локального подключения этим протоколом будет IPC: это протокол предоставляемый операционной системой который пользоляет «общаться» процессам работающим на одной машине. Это единственный вид подключения который не требудет listener-а; более того, локальное подключение не требует никакой настройки. Единственная информация которая нужна пользовательскому процессу для подключения, это к какому экземпляру БД вы хотите подключиться. Нужно помнить что могут работать несколько экземпляров на одном компьютере. Эту инфомрацию процесс получает из системных переменных. На рисунке 4-3 показан пример подключения в системе Linux, а на рисунке 4-3 отображено как подключиться к локальной базе данных в Windows

    26

    Единственным отличием будет метод установки системных переменных.

    Определение имени (Name resolution)

     Когда происходит попытка подключения используя Oracle Net, первым делом необходимо определить куда конкретно вы хотите подключиться. Это процесс определения имени. Если команда CONNECT содержит строку подключения “@orcl11g”, Oracle Net необходимо понять что значит “orcl11g”. Строка должна быть преобразована в определённую информацию: протокол, который будет использоваться (предположим TCP), IP адресс на котором запущен listener, порт используемый listener-ом и имя экзкмпляра БД к которому вы хотите подключиться. Можно использовать разные строки подключения: к примеру вместо IP адреса в строке подключения может указываться имя хоста, которое затем определяется в IP адресс используя DNS сервер. Вместо указания имени экземпляра может быть указано имя сервиса, которое (в RAC архитектуре) может обслуживать несколько экземпляров. В single-instance архитектуре тоже могут использоваться сервисы – к примеру для отслеживания нагрузки на базу данных разными группами пользователей. Вы можете насторить разные механизмы выделения адреса сервера и имени экземпляра из строки подключения, но так или иначи процесс определения имени должен давать пользовательскому процессе достаточно информации для нахождения listener-а и создания запроса к экземпляру.

    27

    Запуск серверного процесса

     Listener базы данных, работающий на сервере, использует один или несколько протоколов для мониторинга одного или нескольких портов на одном или нескольких сетевых интерфейсах в ожидании входящих запросов на подключение. Вы можете запустить несколько listener-ов на одном сервере, а также один listener может принимать запросы на подключение для нескольких экзмепляров. Когда listener получает запрос на подключение, вначале он должен проверить доступен ли запрашиваемый экземпляр. Если экземпляр доступен, listener запустит сервеный процесс для обслуживания пользовательского процесса. Таким образом, если к вашей базе данных подключено одновременно тысяча пользователей – на сервере будет работать тысяча серверных процессов. Такая конфигурация называется архитектура выделенного сервера (dedicated server architecture). Существует возможность использования другой конфигурации, когда пользовательские сессии обслуживаются выделенным процессом диспетчером (dispatcher process), но серверные процессы разделяются между пользовательскими сессиями. Эта архитектура называется общий сервер (shared server).

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

    Создание listener-а

    Listener определяется в файле listener.ora который по умолчанию находится в папке ORACLE_HOME/network/admin. Как минимум файл listener.ora должен содержать информацию об одном listener-e, включая имя listener-а, протокол и адресс. Вы можете настроить несколько listener-ов в одном файле, однако все они должны иметь уникальное имя и адресс.

    Как идругие файлы для настройки Oracle Net, файл listener.ora очень привередливый к синтаксису. Важны регистр букв, количество пробелов и аббревиатуры. Поэтому многие DBA не любят редактировать файл самостоятельно (несмотря на то что ничего не мешает это делать вручную). Oracle предоставляет три программы для управления Oracle Net: это Enterprise Manager, Net Manager и Net Configuration Assistant. Оба последних написаны на Java. Функционал этих программ сильно пересекается, однако есть некоторые вещи, которые можно сделать в одной программе, но нельзя в другой и наоборот.

    Ниже представлен пример файла listener.ora
    LISTENER =

    (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST = jwlnx1)(PORT = 1521))

    )

    LIST2 =

    (DESCRIPTION =

    (ADDRESS_LIST =

    (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1522))

    (ADDRESS = (PROTOCOL = TCP)(HOST = jwlnx1.bplc.co.za)(PORT = 1522))

    )

    )

    В первой секции описан listener с именем LISTENER, который использует локальное имя хоста на порту по умолчанию, 1521. Во второй секции определён второй listener с именем LIST2. Он мониторит порт 1522 также на локальном имене хоста и адресе замыкания (loopback/127.0.0.1).

    Для создания listener-а всё что нужно сделать это добавить запись в файл listener.ora и запустить его выполнив команду lsnrctl. В ОС Windows listener будет работать как сервис, но нет нужды создавать его вручную. Он будет создан при первом запуске listener-а. Затем вы можете запускать и останавливать его как обычный сервис windows.

    На рисунке 4-4 показана настройка listener-а LIST2 используя Net Manager, а на рисунке 4-5 тот же listener в окне Net Configuration Assistant.

    В Net Manager вы можете настроить несколько адресов для мониторинга, а в Net Configuration Assistant нет: он работает только с локальным именем хоста.

    28

    Регистрация БД

    Listener должен создать серверный процесс для экземпляра БД. Для этого listener должен знать какие экземпляры доступны на компьютере где он запущен. Listener находит информацию об экземплярах в процессе «регистрации». Используя single-instance архитектуру – listener и экземпляр должны быть запущены на одной машине. RAC пользоляет любому listener-у подключаться к любому instanсe в кластере.

    Существует два метода регистрации экземпляров БД: статическая и динамическая регистрация. Для статической регистрации вы пишете список эезмепляров в файле listener.ora. Динамическая регистрация обозначает что экземпляр во время запуска, находит listener и регистрируется сам.

    Статическая регистрация

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

    29

    В данном примере запись SID_LIST_LIST2 позволит listener-у с именем LIST2 принимать запросы на подключения к экземпляру с именем ocp11g. Это не значит что instance работает или даже существует. Значение ORACLE_HOME необходима только если listener запускается из домашней директории Oracle отличной от экземпляра. Этот путь используется для поиска исполняемого файла который выполняется для запуска серверного процесса. Обычно это используется при настройке listener-а дял разных версий Oracle, установленных в разные домашние директории.

    Динамическая регистрация

    Этот метод регистрации является предпочтительным, когда экземпляр регистрирует себя у listener-а. Инилизационный параметр local_listener указывает экземпляру на сетевой адресс который необходимо использовать для поиска и регистрации у listener-а. Во время запуска экземпляра, процесс PMON использует данный параметр для поиска listener-а и информирует его о имени экземпляра и сервисе(ах) которые запускает экземпляр. Имя экземпляра определено в параметре instance_name, а параметр service_names при остутствии значения составляется из параметров instance_name и db_domain (db_domain по умолчанию пустое значение). Возможно создавать и запускать дополнительные сервисы в любое время как изменяя значение параметра service_name (перечисляя через запятую) либо используя пакет DBMS_SERVICE.

    Любые изменения должны быть зарегистрированы. Если этого не сделать то listener не будет знать что доступен новый сервис, и не сможет установить соединение. Процесс PMON регистрирует изменения автоматически один раз в минуты, но вы в любое время можете запустить процесс регистрации выполнив команду ALTER SYSTEM REGISTER;

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

    Начиная с версии 9i динамическая регистрация может не требовать конфигурации совсем, если ваш listener работает используя порт по умолчанию (1521). Все экезмпляры автоматически пытаются найти listener на локальной машине используя порт по умолчанию и в случае успеха – зарегистрироваться у этого listener-а. Если listener не доступен на локальной машине используя порт по умолчанию, вы должны установить где находится listener и перерегистрироваться. Например:

    alster system set local_listener=list2;

    alter system register;

    В данном примере listener указывается используя имя. Это имя необходимо преобразовать в адресс и порт. Однако можно использовать сразу настройки в значении параметра. Например

    alter system set local_listener='(address=(protocol=tcp)(host=127.0.0.1)(port=1522))’;

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

    Методы определения имени

    Вначале главы мы использовали строку подключения для установления сессии. Эта строка преобразуется в адресс машины где запущен listener и имя экземпляра или сервиса. При динамической регистрации логическое имя listener-а тоже преобразуется в сетевой адресс для регистрации. Доступно четыре метода для преобразования имени: easy connect, local naming, directory naming и external naming. Большинство установок использует local naming, но для сложной и большой системы предпочтительно использовать directory naming.

    Easy connect

    Метод easy connect был представлен в версии 10g. Его очень использовать – он не требует настройки. Но доступен при использовании только одного протокола: TCP. Остальные методы могут работать с любыми поддеживаемыми протоколами. Easy connect не может использовать дополнительные возможности Oracle Net, такие как балансировка нагрузки или поддержка сетевой маршрутизации. Этот метод часто используется DBA но для пользователей он не сильно удобен. Пример подключения

    connect store/admin123@jwlnxl.bplc.co:1522/ocp11g

    В этом примере пользовательский процесс использя TCP протокол подключится к порту 1522 по IP адрессу определённому из имени хоста. Если listener запущен на этом порту этого сервера – пользовательский процесс запроси listener создать серверный процесс на instance ocp11g. Можно ещё упростить эту команду

    connect  store/admin123@ jwlnxl.bplc.co

    Такая команда сработает только если listener запущен на порту 1521 и имя сервиса совпадает с именем хоста jwlnxl.bplc.co

    Local Naming

    Используя эту технику пользователь использует псевдоним (Oracle Net service alias) в строке подключения, а псевдоним преобразуется в сетевой адресс, протокол, сервис или имя экземпляра с помощью локального файла. Этот файл и есть пресловутый tnsnames.ora, который доставил много горя DBA. Рассмотрим пример файла tnsnames.ora

     

    ocp11g =

    (DESCRIPTION =

    (ADDRESS_LIST =

    (ADDRESS = (PROTOCOL = TCP)(HOST = jwlnx1.bplc.co.za)(PORT = 1522))

    )

    (CONNECT_DATA =

    (service_name = ocp11g)

    )

    )

    test =

    (DESCRIPTION =

    (ADDRESS_LIST =

    (ADDRESS = (PROTOCOL = TCP)(HOST = serv2.bplc.co.za)(PORT = 1521))

    )

    (CONNECT_DATA =

    (sid = testdb)

    )

    )

    Этот файл содержит два Oracle Net Service alias: ocp11g и test. Эти псевдоним и есть то, что будут использовать пользователи в строке подключения. Первый псевдоним ocp11g указывает на то, что если в строке подключения найдено «@ocp11g», то пользовательский процесс по протоколу TCP, порту 1522 подключится к машине jwlnx1.bplc.co.za и попросит listener создать сессию для экземпляра с названием сервиса ocp11g. Второй алиас test направит пользовательские процессы по другому адресу, порту и сессии будут создаваться для экземпляра testdb.

    Метод local naming поддерживает все протоколы и возможность Oracle Net, но управление файлами tnsnames.ora на клиентских машинах может быть задачей, занимающей очень много времени. Также tnsnames.ora файл очень чувствителен к ошибкам синтаксиса. Использование графических программ поможет избегать этих ошибок.

    Directory Naming и External Naming

    Метод Directory Naming направляет пользовательскую сессию к серверу LDAP для определения псевдонима. LDAP – это широко распространённый стандарт, которого придерживается Oracle и другие производители ПО. Для использования directory naming метода, вначале вам нужно установить и настроить LDAP сервер на каком либо сервере в вашей сети. Oracle предоставляет LDAP сервер ( Oracle Internet Directory) как часть Oracle Application Server, но необязательно использовать именно его. Если у вас уже есть установленный и настроенный к примеру сервер с Microsoft Active Directory – вы можете использовать его.

    Как и local naming, метод directory naming поддерживает все возможности Oracle Net – но вместо поддержки файлов tnsnames.ora разбросанных по всей сети, используется централизованное хранилище, что несомненно гораздо легче сопровождать.

    External Naming отличается от directory naming только тем, что использует отдельный сервис вместо LDAP – Sun Network Information Services (NIS+) или Cell Directory Services (CDS).

    Программа управления listener-ом

    Можно запускать и останавливать listener через Database Control, но существует так же консольная программа lsnrctl (или lsnrctl.exe в Windows). Утилита lsnrctl может запускаться через командную строку ОС или через простой графический интерфейс. Для всех команд вы должны указать имя listener-а, если не используется имя по умолчанию LISTENER. На рисунках 4-6 и 4-7 показано как проверить статус listener-а, запустить и остановить его путём вызова команд из командной строки операционной системы или с помощью графического интерфейса.

    Необходимо отметить что комнда status всегда отображает адрес по которому listener принимает запросы на подключение, а также имя и местонахождение файла listener.ora, в котором прописан listener и имя и местонахождение файлов логов listenera. На рисунках ниже также видно что listener LIST2 “supports no services”. Это отображается так как не было статически зарегистрировано сервисов и ни один экземпляр БД ещё не зарегистрировался динамически для этого listener-а. На рисунке 4-8 отображено состояние listener-а после динамической регистрации экземпляра БД.

    30

    31

    На рисунке 4-8 результат выполнения команды status показывает нам, что listener с именем LISTENER поддерживает три сервиса, доступных для экземпляра БД orc11g:

    • Сервис orcl11g.jwlnx1.bplc.co.za это обычный сервис БД. Listener может запустить выделенную серверную сессию для работы (ещё ни одной сессии не создано)
    • Сервис orcl11gXDB.jwlnx1.bplc.co.za – это сервис для работы с БД основанный на XML. Данный сервис позволяет подключаться к БД используя протоколы отличные от Oracle Net, к примеру FTP и HTTP
    • Сервис orcl11g_XPT.jwlnx1.bplc.co.za – это сервис для работы Dataguard.

    По умолчанию экземпляры БД версии 11g регистрируют сервисы XDP и XDT, но они не могут использоваться без дополнительной настройки. Эти сервисы отображаются как “status ready” и это обозначает что они были автоматически зарегистрированы процессом PMON: listener знает что они доступны так как PMON при динамической регистрации указал это. Если бы сервисы были зарегистрированы статически, они бы отображались со статусом “status unknown”. Т.е. сервисы прописаны в файле listener.ora, но могут быть не запущены.

    Для просмотра всех доступных команд программы lsnrctl используйте команду HELP

    32

    Назначение команд описано ниже

    • START запуск listener-а
    • STOP остановка listener-а
    • STATUS просмотр состояния listener-а
    • SERVICES отобразить сервисы доступны listener-у (более детальная информация чем в команде STATUS)
    • VERSION отобразить версию listener-а
    • RELOAD перечитать файл ora
    • SAVE_CONFIG сохранить изменения в файл listener.ora
    • TRACE разрешить трассировку деятельности listener-а
    • CHANGE_PASSWORD установить пароль для администрирования listener-а
    • QUIT выйти из программы без сохранения
    • EXIT выйти из программы сохранив изменения
    • SET установить значения параметров, таки как примеру время ожидания ответа
    • SHOW отобразить значения установленных параметров

    Настройка псевдонимов сервисов (alias)

    Выбрав метод определения имени, следующей задачей становится настройка клиентских программ для использования этого метода. Вы можете использовать Database Control, но так как это серверный процесс – вы сможете настроить только программы, которые будут запускаться на том же сервере что и БД. Для настройки можно использовать Net Manager. Это отдельное приложение написанное на языке Java, поставляемое Oracle со всеми клиентскими программами.

    Для запуска приложения в среде Unix запустите команду netmgr. В Windows вы можете найти эту программу в меню Пуск.

    В дереве навигации доступны три ветки. Ветка Profile используется для установки параметров, которые могут применяться и на серверной и на клиентской стороне Oracle Net и которые могут влиять на поведение все сессий. Ветка Service naming используется для настройки определения имени на клиентской стороне, и ветка Listeners используется для настройки listener-ов БД.

    Когда вы выбираете ветку Profile как показано на рисунке 4-9, фактически вы работаете с файлов sqlnet.ora. Этот файл создаётся по умолчанию в папке ORACLE_HOME/network/admin. Он не обязателен, так как для всех параметров доступны значения по умолчанию, но обычно вы будете использовать эту ветку для указания метода определения имени.

    33

    Выбрав ветку Profile, вы увидите доступные методы определения имени и три (TNSNAMES, EZCONNECT и HOSTNAME) выбраны по умолчанию: это и есть local naming, easy connect и host naming. External naming указаны как CDS и NIS. LDAP – это directory naming. Host naming это эквивалент Easy Connect и он существует только для обратной совместимости.

    Затем вы должны настроить псевдонимы сервисов Oracle Net. Это можно сделать в ветке Service Naming, что фактически создает или изменяет файл tnsnames.ora (по умолчанию местонахождения файла ORACLE_HOME/network/admin). Если у вас настроен метод Directory Naming тогда вам не нужно редактировать ветку Service Naming – достаточно выбрать LDAP в ветке Profile. Пример записи в файле tnsnames.ora показан ниже

    OCP11G =

    (DESCRIPTION =

    (ADDRESS_LIST =

    (ADDRESS = (PROTOCOL = TCP)(HOST = jwacer.bplc.co.za)(PORT = 1521)

    )

    )

    (CONNECT_DATA =

    (SERVICE_NAME = ocp11g)

    )

    )

    Если пользователь использует “ocp11g” в строке подключения то эта запись используется для отсылки запроса к listener-у по адресу jwacer.bplc.co.za на порт 1521 для создания сессии к экземпляру доступному через сервис ocp11g. Для подключения с помощью этого псведонима достаточно выполнить команду

    sqlplus system/oracle@ocp11g

    Используя Easy Connect команда выглядела бы

    sqlplus system/manager@ jwacer.bplc.co.za:1521/ocp11g

    Для проверки строки подключения можно использовать команду TNSPING. Эта программа принимает строку подключения как параметр, находит файлы Oracle Net, преобразует строку подключения и отправляет запрос к listener-у. Если listener запущен и запрашиваемый сервис зарегистрирован – программа отобразит упешный результат теста. Ниже показан пример работы программы TNSPING

    34

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

    Имена файлов и системная переменная TNSADMIN

    Используется три важных файла для настройки Oracle Net:

    • listener.ora файл на стороне сервера, определяющий listener-ы БД. Влючает в себя сведения о протоколе, адресах и портах, используемых listener-ом для ожидания запросов на подключения. А также может содержать информацию о статических зарегистрированных экземплярах БД.
    • tnsnames.ora – файл со стороны клиента используемый для определения имени. Используется пользовательским процессом для нахождения listener-ов БД.Также может быть использован самим экземпляром БД для нахождения listener-ов для динамической регистрации.
    • sqlnet.ora – файл необязательный, может существовать (и даже с разными значениями) как на клиентской, так и на серверной стороне. Содержит настройки которые могут применяться ко всем сессиям к listener-ам, такие как настройки безопасности и шифрования.

    Все три файла по умолчанию находятся в папке ORACLE_HOME/network/admin. Можно изменить путь к ним с помощью системной переменной: TNS_ADMIN. Эта переменная часто используется если сущуствует несколько домашних директорий Oracle. У обычного сервера Oracle будет как минимум три домашних директории Oracle: одна для Enterprise Manager Grid Control Agent, одна для запуска экземпляров и одна для запуска экземпляров ASM (Automatic Storage Management). На клиентских машинах также может быть несколько домашних директорий Oracle, например для клиентов Oracle 10g и Oracle 11g. Установка переменной TNS_ADMIN как указатель на папку одной из домашних директорий (или вообще внешнюю папку) означает, что вам, вместо того чтобы настраивать файлы в двух разных папках, можно будет настраивать файлы в одной папке. Чтобы установить эту переменную в Windows для какой-либо сессии вы можете выполнить команду

    set NTS_ADMIN=C:\oracle\net

    Но лучше устанавливать значение этой переменной в регистре.

    В Unix и Linux синтаксис может отличаться в зависимости от исползуемой оболочки, но обычно выглядит примерно так

    set TNS_ADMIN=/u01/oracle/net; export TNS_ADMIN

    Эту команду можно добавить в файл профила каждого пользователя, или в /etc/profile для всех пользователей.

    На рисунке 4-10 показан процесс обработки пользовательского запроса. Пользователь инициирует создание подключения к серверу указывая имя пользователя, пароль и строку подключения. Если строка подключения отсутствует, клиент Oracle Net пробует использовать системную переменную ORACLE_SID как значение для строки подключения по умолчанию. Если это значение не установлено – обычно происходит ошибка. Если строка подключения указала, клиент Oracle Net пробует выяснить какой метод использовать дря преобразования строки подключения и для этого необходим файл sqlnet.ora, который может находиться в папке определённой в TNS_ADMIN переменной или ORACLE_HOME/network/admin. Если не установлены ни TNS_ADMIN ни ORACLE_HOME – возвращается ошибка.

    Обычно в файле sqlnet.ora находится параметр NAMES.DIRECTORY_PATH, в которой перечислены в порядке предпочтения различные методы определения имени, такие как TNSNAMES, LDAP и EZCONNECT. Если TNSNAMES в списке указан первым, Oracle Net пробует найти файл tnsnames.ora опять же либо в директории указанной в переменной TNS_ADMIN либо в ORACLE_HOME/network/admin. Если файл найден, он используется для преобразования строки подключения в сетевой адрес обычно вида имя хоста:порт:sid или хоста:порт:имя сервиса.

    Наконец клиент Oracle Net готов к установке соединения для пользовательского процесса который ициниировал запрос на подключение к БД. Если в строке подключения присутствует символ “@”, тогда происходит запрос к listener-у указанному в сетевом адресе для проверки доступа к экземпляру или сервису. Если listener работа – пользовательский процесс пробует установить соединение с сервером иначе повзращается ошибка. Если в строке подключения нет символа “@” —  тогда происходит попытка создать локальное подключение используя протокол IPC и если экземпляр или сервис запущены на той же машине, что и клиентский пользовательский процесс соединение может быть успешно установлено.

    35

    Ссылки базы данных

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

     

    create database link prodstore connect to store identified by admin123 using ‘prod’;

     

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

     

    select * from orders@prodstore;

     

    Пользовательская сессия попробует создать сессию к удалённой БД, используя имя пользователя STORE  и выполнить запрос на удалённом сервере. Результат затем будет возвращён к текущей БД и затем пользователю.

    Любые SQL запросы могут быть выполнены используя ссылки БД, если конечно есть соответствующие привилегии доступа. Например рассмотрим такой сценарий:

    У вас есть рабочая БД определённая строкой подключения PROD, в которой находится схема STORE содержащая две таблицы: ORDERS и PRODUCTS. Создана ссылка к этой БД (командой описанной выше). Также есть база данных для разработки, определённая строкой подключения DEV, в которой также есть схема STORE. Вы подключены к третьей базе данных с именем TEST и вам нужно обновить схему базы данных для разработки данными из рабочей БД.

    Для начала создадим ссылку на базу данных для разработки

     

    create database link devstore connect to store identified by devpasswd using ‘dev’;

     

    Затем обновим данные в БД для разработки используя рабочую базу

     

    truncate table orders@devstore;

    truncate table products@devstore;

    insert into orders@devstore select * from orders@prodstore;

    insert into products@devstore select * from products@prodstore;

    commit;

     

    В будущем если вам необходимо проверить были ли добавлены данные в рабочую базу данных и если были, то добавить эти данные в БЛ для разработки вы можете выполнить команду

     

    insert into orders@devstore (select * from orders@prodstore minus select * from orders@devstore)

     

    Если к примеру необходимо обновить имя покупателя вы можете сделать это в двух базах данных одновременно

     

    update customers@prodstore set customer_name=’Coda’ where customer_id=10;

    update customers@devstore set customer_name=’Coda’ where customer_id=10;

    commit;

    Когда необходимо Oracle выполнит дву-фазное подтверждение транзакции, чтобы убедиться что распределённая транзакция (distributed transaction – это транзакция затрагивающая данные в нескольких базах данных) обрабатывается как атомарная транзакция: изменения должны применяться либо ко всем базам данных либо ни к одной. Согласованность чтения данных также управляется во всём окружении.

  • Управление БД — Итоги

    Этаты запуска и остановки БД

    Существует три состояния NOMOUNT, MOUNT и OPEN

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

    MOUNT использует файл контроля

    OPEN читает файлы данных и файлы логов

     

    Установка инициализационных параметров

    Изменение статических параметров не влияет на работу БД до перезапуска

    Изменение остальных параметров влияет на работу без перезапуска, и может применяться как для экземпляра так и для отдельной сессии

    Значения параметров можно посмотреть в представлениях производительности V$PARAMETER и V$SPPAREMETER

     

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

    Системный журнал это файл которые содержит последовательные записи о всех критических операциях над БД

    Файлы данных генерируются фоновыми процессами, обычно когда возникает какая-либо ошибка

     

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

    Представления производительности содержат информацию об экзмепляре и из файла контроля

    Представления словаря данных используют информацию из словаря данных

    Представления производительности собирают данные все время пока экземпляр работает, и инициализируются заново при перезапуске

    Представления словаря данных отображают информацию которая сохраняется вне зависимости от циклов запуска/остановки

    Оба типа представлений используются с помощью синонимов

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

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

    Представления словаря данных

     Словарь данных содержим метаданные: грубо говоря данные о данных. Он содержит описание базы данных, физическую и логическую структуру и содержание БД. Учётные записи, информация о безопасности, целостные ограничения и (начиная с версии 10g) информацию о производительности – всё это хранится в словаре данных. Логически это набор сегментов а табличных пространствах SYSTEM и SYSAUX.

    Сегменты словаря данных практически идентичны обычным пользовательским сегментам (таблицам и индексам). Ключевым различием является то, что таблицы словаря данных создаются в момент создания БД и не могут быть использованы напрямую. Конечно физически это возможно,но любые изменения могут привести к нарушению БД и никто не сможет вам помочь. Создание словаря данных – это часть процесса создания базы данных. Словарь данных управляется DDL (Data Definition Language) командами. Когда вы запускаете команду CREATE TABLE – вы не только создаёте сегмент данных для хранения строк в нем – ваша команда также добавит строки в различные таблицы словаря данных, которые содержат информацию о табличном пространстве, extent-ах, столбцах и владельце сегмента.

    Для просмотра словаря данных, Oracle предоставляет набор представлений, отличающихся префиксом: DBA_, ALL_ или USER_. Практически все представления созданы для всех трёх префиксов. Любое представление начинающееся с USER_ отобразит инфомрацию об объектах, владельцем которых является текущий пользователь. Если пользователя ВАСЯ будет просматривать представление USER_TABLES, то он увидит только таблицы владельцем которых он является. Представления начинающиеся с ALL_ отображают объекты, к которым у текущего пользователя есть доступ. Т.е. если выполнить запрос в ALL_TABLES то вернутся строки таблица которые вы создали, плюс строки о таблицах других пользователей к которым у вас есть доступ для просмотра. Любое представление с префиксом DBA_ содержит информацию о всех объектах в БД, то есть DBA_TABLES будет содержать строки для всех таблиц во всей базе данных, без разницы кто их создал. Рисунок 3-10 отображает концепцию трех видов представлений. Для доступа к представлениям с префиксом DBA _– у пользователя дожны быть права доступа DBA.

    23

    Эти представления создаются во время создания БД, вместе с огромным количеством PL/SQL пакетов, которые предоставляет Oracle для упрощения администрарования БД и разработки приложений.

    Существует несколько сот представлений словаря данных. Некоторые часто используемые DBA это

    DBA_OBJECT содержит строки для всех объектов в БД

    DBA_DATA_FILES каждая строка описаывает файл данных

    DBA_USER строки отображают информацию об учётной записи

    DBA_TABLES описание таблиц

    DBA_ALERT_HISTORY строки описывают последние события для записи в системный журнал

    Также существует много других представлений и вместе с представлениями создаются синонимы. Следующий запрос

     

    select object_name,owner, object_type from dba_objects where object_name=’DBA_OBJECTS’;

     

    показывает, что фактически владельцем представления DBA_OBJECTS является SYS и создан синоним с таким же названием, к которому и выполнен запрос.

    Динамические представления производительности

    Существует больше чем три сотни представлений производительности. Вы будете часто слышать выражение “ви доллар” представления, потому что их названия начинаются с V$. На самом деле,  “ви доллар” представления совсем не представления – это синонимы созданные для представлений с префиксом V_$, как показано на рисунке 3-11

    24

    Также на рисунке 3-11 мы видим описание V$SQL, где хранится строка для каждого SQL запроса, сохранённого в shared pool, содержащая информацию такую как как часто выполнялся запрос и так далее.

    Представления производительности дают доступ к колоссальному количеству инфомрации об экземпляре БД и (в какой-то степени) о самой базе данных. Большинство представлений содержат информацию от экземпляра БД, остальные – информацию из файла контроля. Все они отображают информацию в режиме реального времени. Представления которые содержат информацию об экземпляре БД доступны в любое время когда экземпляр запущен, даже в состоянии NOMOUNT. Представления, которые содержат информацию из файла контроля, такие как V$DATABASE или V$DATAFILE недоступны до подключения базы данных (момента, когда читается файл контроля). Для сравнения, представления словаря данных могут использоваться только когда БД открыта.

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

  • Использование системного журнала (Alert Log) и файлов трассировки (Trace Files)

    Системный журнал это файл содержащий последовательные записи всех значимых операций совершённых над экземпляром БД и самой базой данных. Местонахождение этого файла определяется параметром BACKGROUND_DUMP_DEST и имя alert_SID.log где SID это имя экзмепляра БД.

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

    Запуск и остановка БД (включая шаги подключения и открытия)

    Системные внутренние ошибки Oracle (например ошибка ORA-600)

    Любые найденные повреждения блоков файлов данных

    Возможные ситуации deadlock

    Изменения физической структуры БД (создание/изменение файлов данных или файлов логов)

    Выполнение команд ALTER SYSTEM

    Переключение логов (log switch) и архивирование логов

    В системном журнале будут отображеные все значения параметров не по умолчанию при запуске системы. Эта информация вместе со всеми записями выполнения команд ALTER SYSTEM и ALTER DATABASE позволяют в любой момент времени восстановить историю изменений БД и экземпляра. Это может быть незаменимой информацией при поиске источника возникновения проблемы.

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

  • Описание этапов запуска и остановки БД

    Oracle рекомендует следующий порядок действий для запуска БД: запуск Database Control, запуск listener-а, запуск БД. Запуск БД также является составным процессом. При запуске более сложного окружения, такого как cluster system или любого другого управляемого Enterprise Manager Grid Control могут быть дополнительные этапы, однако для Single Instance архитектуры этой последовательности вполне достаточно.

    Запуск и подключение к Database Control

    Database Control это инстурмент для управления одной БД. Эта БД может быть кластеризирована и тогда для каждого экземпляра БД работающего с одинаковой домашней директорией ORACLE_HOME будет свой экземпляр Database Control. Этот инструмент написан на языках Perl и Java и доступен через браузер. Нет необходимости устанавливать JRE или интерпретатор Perl: они оба доступны в домашней директории Oracle и устанавливаются OUI. Все запросы к Database Control осуществляются с использованием протокола HTTPS. Единственная необходимая настройка это проверить доступность порта используемого для работы с Database Control. Настройка Database Control осуществляется в момент создания БД. Эта настройка содержит два важных блока информации:  имя сервера и номер порта. Если возникнет необходимость изменить эти значения – необходимо перенастроить Database Control.

    Для запуска Database Control необходимо запустить программу emctl, расположенную в папке $ORACLE_HOME/bin. Ниже перечислены команды для запуска, остановки и проверки состояния Database Control

    emctl start dbconsole

    emctl stop dbconsole

    ecmtl status dbconsole

    Для успешного выполнения этих команд должны быть установлены следующие системные переменные: PATH, ORACLE_HOME и ORACLE_SID. PATH используется операционной системой для поиска пути к программе emctl. ORACLE_HOME и ORACLE_SID используются для поиска командой emctl файлов конфигурации. Эти файлы расположены в трёх местах: папка ORACLE_HOME/sysman/config содержит общие настройки для всех экземпляров Database Control работающих с текущей домашней директорией Oracle. ORACLE_HOME/hostname_sid/sysman/config и ORACLE_HOME/oc4j/j2ee/ OC4J_DBConsole_ hostname_sid/config содержат дополнительные расширенные настройки для каждой БД(hostname – имя компьютера, sid – значение переменной ORACLE_SID).

    На рисунке 3-3 показан результат выполнения команды запуска Database Control

    16

    Первая попытка запуска была неудачной так как не была установлена переменная ORACLE_SID. Без корректного значения этой переменной emctl не может найти необходимые файлы конфигурации (значение используется в названии папок). Команда проверки состояния ни что иное как запрос по адресу URL; доступность этого URL так же можно проверить в браузере

    http://hostname:port/em

    где hostname – это сетевое имя компьютера на котором запущен Database Control и port – это порт ответственный за входящие подключения. Если у вашего сервера несколько сетевых имён или несколько сетевых интерфейсов – можно использовть любой. Для определения порта можно использовать команду emctl либо посмотреть конфигурационный файл ORACLE_HOME/install/portlist.ini где указаны все порты настроенные OUI и DBCA. При незапущенном listener-е при подключении к Database Control вы увидите окно изображенное на рисунке 3-4.

    Запуск listener-а БД

    Listener – это процесс который следит за запросами к порту для подключения к базе данных. Запросы к БД (и весь остальной трафик после создания сессии) использует Oracle Net, закрытый протокол Oracle. Oracle Net – это прокотор который работает над любым низлежащим сетевым протоколом, обычно над TCP/IP. Управление listener-ом более детально расммотрим в главе 4, сейчас же рассмотрим как запустить listener. Это можно сделать двумя (в windows тремя) способами: используя программу lsnrctl, с помощью Database Control, запустить windows сервис.

    Программа lsnrctl расположена в каталоге ORACLE_HOME/bin. Параметрами могут быть

    lsnrctl start [listener name]

    lsnrctl status [listener name]

    Значение по умолчанию для названия listener-а  — LISTENER и обычно так и называют. На рисунке 3-5 показан результат выполнения команды lsnrctl status при работающем listener-е

    17

    18

    Обратите внимание на первую строчку – там указаны сетевое имя и порт listener-а, а также на пятую снизу строку, которая обозначает что listener будет принимать подключения для сервиса ocp11g который создан для экземпляра ocp11g. Это критически важная информация для подключения к БД. Если БД была успешна создана с помощью DBCA значит listener настроен и запущен. Если нет вы увидите другой ответ команды lsnrctl status, тогда используйте команду lsnrctl для запуска или нажмите кнопку START LISTENER в окне Database Control показанном на рисунке 3-4.

    Запуск SQL *Plus

    SQL *Plus — это простая клиент-серверная программа для запуска SQL команд. Единственный параметр который необходимо знать для запуска – это NOLOG. По умолчанию, SQL *Plus немедленно запрашивает имя и пароль пользователя и параметры подключения. Это корректно для обычных пользователей, но бессмысленно для DBA, так как база данных должна быть уже открыта. Для запуска SQL *Plus без подключения к БД используйте параметр /NOLOG

    sqlplus /nolog

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

    Запуск и остановка БД

    Если быть точным – нельзя запустить и остановить БД: только экземпляр может быть запущен и остановлен, а база данны может быть подключена, открыта, отключена и закрыта. Данные операции можно совершить с помощью SQL *Plus выполнив команды STARTUP и SHUTDOWN или используя Database Control. В Windows это можно сделать также с помощью управления сервисом созданным для экземпляра БД. Системный журнал содержит подробную информацию об этих операциях когда бы они не были вызваны. Запуск и остановка – очень важные операции, информация об их выполнении всегда записывается и они могут быть инициированы только пользователями с особым уровнем доступа.

    Подключение с повышенными правами доступа

    Обычный пользователь не может запустить или остановить БД – потому что он авторизуется используя словарь данных. Это логически невозможно поскольку в момент запуска словарь данных ещё не доступен. Таким образом для запуска необходимо подключаться к серверу используя механизм внешней авторизации:  системная авторизация пользователя как члена группы Oracle, или авторизация с использованием файла паролей. Тип авторизации указывается при выполнении команды CONNECT.  Ниже представлены различные комбинации команды CONNECT после подключения к серверу используя программу SQL *Plus с параметром /NOLOG

    connect user/pwd[@connect_alias]

    connect user/pwd[@connect_alias] as sysdba

    connect user/pwd[@connect_alias] as sysoper

    connect / as sysdba

    connect / as sysoper

    где user – имя пользователя, pwd – пароль, connect_alias – сетевой идентификатор (рассмотрим в главе 4). Первый пример использует авторизацию с помощью словаря данных, база данных должны быть открыта или команда вернёт ошибку. Любой пользователь после подключения к БД используя данный синтаксис не сможет выполнить команды запуска и остановки базы данных. Два следующих примеры указывают Oracle использовать авторизацию с помощью файла паролей. Последние команды используют авторизацию операционной системы: Oracle проверяет является ли текущий пользователь членом группы Oracle, и если проверка успешна – пользователь подключается к БД как SYSOPER или SYSDBA. Пользователь подключившийся к базе данных любым способом из последних четырёх может выполнить команды запуска и остановки БД вне зависимости от состояния базы данных – она может быть даже не создана на этом этапе.

    Если Database Control обнаруживает запущенный listener – то он использует авторизацию через словарь данных или файл паролей (в зависимости от выбора пользователя – рисунок 3-6). Если же listener не запущен (рисунок 3-4) при нажатии на кнопку STARTUP Database Control запрашивает системные имя пользователя и пароль для подключения к серверу.

    19

    Рисунок 3-6

    SYSOPER и SYSDBA

    SYSOPER и SYSDBA – это уровни доступа с повышенными полномочиями.  Они доступны только при системной авторизации или авторизации с помощью файла паролей. Уровень доступа SYSOPER может выполнять команды

    STARTUP

    SHUTDOWN

    ALTER DATABASE [MOUNT|OPEN|CLOSE|DISMOUNT]

    ALTER [DATABASE|TABLESPACE][BEGIN|END] BACKUP

    RECOVER

    Уровень доступа SYSDBA также может выполнять эти команды, плюс возможность создавать БД, запускать неполное восстановление и давать полномочия SYSOPER и SYSDBA другим пользователям.

    Вам может быть интерестно под каким пользователем вы подключаетесь к БД когда используется системная авторизация. Чтобы это выяснить, после подключения к базе данных выполните команду show user (эту команду можно вызвать набрав sho user – не стоит недооценивать сокращения, они могут ускорить время набора команд) – результат показан на рисунке 3-7.

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

    20

    Рисунок 3-7

    Запуск: NOMOUNT, MOUNT и OPEN

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

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

    • SHUTDOWN
    • NOMOUNT
    • MOUNT
    • OPEN

    Когда база данных остановлена (SHUTDOWN) все файлы закрыты и экземпляр не существует. В отключенном состоянии (NOMOUNT) – экземпляр БД построен в памяти (SGA создана и фоновые процессы запущены согдасно файлу параметров), но база данных недоступна и может быть даже ещё не создана. В подключенном состоянии (MOUNT) экземпляр находит и читает файл контроля. В открытом состоянии (OPEN) все файлы найдены и открыты – т.е. база данных доступна для пользователей. Когды вы запускаете команду STARTUP – будут выполнены все шаги, однако команда может быть разбиты на этапы. Напирмер если файл контроля испорчен или копия недоступна – вы не сможете подключить базу данных. Однако вы можете запустить базу в неподключенном режиме (NOMOUNT) и восстановить файл контроля. Точно так же если у вас возникли проблемы с файлами данных или логовов, вы можете попробовать восстановить данные в MOUNT состоянии, перед тем как открывать БД.

    Как же экземпляр находит файлы которые ему нужны на каждом из шагов? Начнём с NOMOUNT. Когда вы запускаете команду STARTUP, Oracle будет искать файл параметров в определённом порядке как отображено на рисунке 3-8.

    Всего существует три пути и имени файла. На Unix подобных системах это

     

    $ORACLE_HOME/dbs/spfileSID.ora

    $ORACLE_HOME/dbs/spfile.ora

    $ORACLE_HOME/dbs/initSID.ora

    А на Windows

     

    %ORACLE_HOME%\database\SPFILESID.ORA

    %ORACLE_HOME%\database\SPFILE.ORA

    %ORACLE_HOME%\database\INITSID.ORA

    21Во всех случаях – SID это имя экземпляра. Порядок поиска очень важен. Oracle будет использовать первый найденный файл вне зависимости от наличия остальных. Если ни одного файла не существует – экземпляр не будет запущен. В режиме NOMOUNT используются только файл параметров и системный журнал. Значения параметров из файла параметров используются для создания SGA в памяти и запуска фоновых процессов. В системный журнал записывается информация об этот процессе. Где находится системный журнал? Путь можно узнать посмотрев параметр BACKGROUND_DUMP_DEST в файле параметров или выполнив команду

    sho parameter background_dump_dest

    Если системный журнал существует во время выполнения команды STARTUP то новые данные будут добавляться, иначе будет созда новый файл. Если возникнут какие-либо проблемы во время выполнения команды – так же будут созданы файлы трассировки.

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

    Как часть процесса подключения, все именя файлов данных и логов и пути к ним считываются из файла контроля, но Oracle просто запоминает эти значения, не пытаясь найти файлы. Поиск и чтение файлов происходит во время открытия базы данных (OPEN). Если какой-либо файл поврежден или отсутствует база данных останется в режиме MOUNT пока вы не исправите ошибки. Более того, все файлы должны быть синхронизированы перед тем как база данных будет открыта. Если последнее выключение было выполнено в определённом порядке, то все буферы из буфера кэша БД записаны на диск процессом DBWn и файлы синхронизированы, и Oracle будет знать при запуске что все подтверждённые транзакции сохранены в файлах данных и нет неподтвержденных транзакций ожидающих отмены.  Если же последнее выключение было не запланированным (к примеру от потери питания или системной перезагрузке сервера без правильного выключения экземпляра) то Oracle должен синхроинизировать файлы данных и файлы логов (отменив неподтверждённые транзакции). Процесс который подключает и открывает БД (и синхронизирует данные) называется SMON. Только когда база данных успешно открыта будет возможно подключение пользователей. Процесс запуска графически представлен на рисунке 3-9.

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

    22

    Выключение: NORMAL, TRANSACTIONAL, IMMEDIATE и ABORT

    Существуют параметры которые используются с командой SHUTDOWN – вызов SHUTDOWN команды требует уровня доступа SYSDBA или SYSOPER

     

    SHUTDOWN [NORMAL|TRANSACTIONAL|IMMEDIATE|ABORT]

     

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

    TRANSACTIONAL: новые подключения недоступны; существующие сессии которые не выполняют транзакции отключаются; сессии которые выполняют транзанкцию завершают транзакцию и отключаются. Когда все сессии будут отключены, база данных останавливается.

    IMMEDIATE: новые подключения не разрешены. Все активные сессии отключаются. Все активные транзакции отменяются и база данных выключается.

    ABORT: это эквивалент отключению питания. Экземпляр останавливается без записи чего либо на диск, закрытия файлов, отмены транзакций.

    Параметры выключения «normal,» «immediateи «transactional» считаются «чистыми» выключениями (то есть выполненными в правильном порядке). После того как все сессии отключены, PMON отменяет все неподтверждённые транзакции. Создаётся контрольная точка процессом CKPT, которая заставляет DBWn записывать измененные данные из буфера кэша в файлы данных. LGWR записывает вектора изменений в файлы логов. Обновляются заголовки файлов и файлы закрываются. Это гарантирует что база в синхронизированном состоянии: все подверждённые транзакции в файлах данных и нет неподтверждённых транзакций требующих отмены.

    Параметр “abort” оставляет базу данных в рассинхронизированном состоянии: возможно что подтверждённые транзакции не записаны в файлы данных, так как на момент выключения они были сохранены в памяти и DBWn не записал изменения из буфера в файлы. Также может быть и такое, что неподтверждённые транзакции записаны в файлы данных. Это определение испорченной БД: она содержит некорректные данные. Эти повреждения должны быть восстановлены используя instance recovery. Таким образом можно протестировать что произойдёт если к примерну непредвиденно обесточить сервер в процессе работы БД.

    Так как выключение это пошаговый процесс, то возможно управлять этапами используя SQL *Plus и команды

     

    alter database close;

    alter database dismount;

     

    Эти команды полная противоположность командам запуска. На практике SHUTDOWN это единственная команда которой пользуются DBA. Пошаговый процесс также недоступен из Database Control.

  • Установка инициализационных параметров БД

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

    БД и экзмепляр управляются набором инилизационных параметров. Их достаточно большое количество, однако наиболее важных всего тридцать три. Эти параметры регулируют такие значения как объём выделяемой памяти при запуске экземпляра, местоположение файлов данных и файлов логов, файла контроля и его копий, а также название БД. Значения по умолчанию не будут использоваться на реальных системах, но для тестовой среды подходят. Многие DBA немного боятся изменять эти параметры, однако в этом нет ничего страшного, лишь имзенения некоторыч параметры сложно отменить. Если вы поменяли какое-то значение в процессе попытки оптимизировать производительность и БД стала вести себя хуже – просто отмените изменения. Все эти параметры хранятся в инилизационном файле без которого экземляр не запустится.

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

    Значимость файлов системных журналов и файлов трассировки (alert log и trace files) нельзя недооценивать, они очень важны для поиска причин возникновения проболем и Oracle изобрели удобный способ найти нужные файлы – значения хранятся в инилизационных параметрах. Системные журналы пожалуй самые важные файлы для DBA, так как в них хранятся данные о всех киритческих системных событиях, таких как запуск, остановка, возникновение ошибки и т.п. Файлы трассировки обычно используются фоновыми и серверными процессами и, как и  в системные журналы, содержат информацию о происходящих и произошедших событиях.

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

    Экземпляр настраивается инилизационными параметрами используемыми при старте (запуске фоновых процессов и создании структур в памяти). Многие, но не все, параметры могут быть изменены после старта. Параметры используемые при создании экземпляра могут быть получены из файла параметров (который может быть статическим pfile или динамическим spfile) или использовать значения по умолчанию. У всех параметров кроме DB_NAME есть значение по умолчанию. Всего примерно триста параметров могут быть установлены DBA. На самом деле есть ещё примерно полторы тысячки параметров, но они обычно устанавливаются системой и изменяются только после консультации с поддержкой Oracle.

    Настраиваемые триста параметров в свою очередь  делятся на базовые (basic) и продвинутые (advanced). Основной принцип разделения таков, что практически все БД будут хорошо работать со значениями по умолчанию для продвинутых параметров. Всего около тридцати трёх параметров являются базовыми. Таким образом установка значений для параметров не такая уж ужасная задача, однако эта задача очень важная.

    Статические и динамические параметры. Инициализационный файл параметров

    Для просмотра параметров и их значений можно выполнить запрос к представлению V$PARAMETER

    SELECT NAME,VALUE FROM V$PARAMETER ORDER BY NAME;

    Запрос который может вернуть немного другой результат

    SELECT NAME,VALUE FROM V$SPPARAMETER ORDER BY NAME;

    Разница между запросами в представлениях, откуда выбираются параметры и из значения: V$PARAMETER отображает значения, установленные для запущенного экземпляра БД, а V$SPPARAMETER содержит значения которые хранятся в spfile на диске. Обычно, параметры одинаковые, но не всегда. Некоторые параметры могут быть измененые в процессе работы экземпляра БД. Другие же, называемые статическими параметрами, устанавливаются только в момент запуска экземпляра БД. Изменение нестатических параметров приведёт к немедленному эффекту на работающем экземпляре и также может быть записано в spfile. Если это будет сделано, то при следующей остановке/запуске экземпляра будет использовано новое значение. Если не записывать изменения в файл – то изменения будут действовать только до перезапуска экземпляра.  Статические параметры могут быть измененые только записью в spfile и изменения будут применены при перезапуске экземпляра. Если существует разница между результатами выполнения двух  запросов, то скорее всего либо DBA тестирует какие-либо изменения и ещё не применил их, либо были изменения в статических параметрах, но экземплярд не был перезапущен.

    Остальные столбцы в представлениях V$PARAMETER и V$SPPARAMETER не требуют пояснений.

    Эти представления так же можно просмотреть используя Database Controle. На домашней странице выберите вкладку Server и нажмите ссылку Initialization Parameters. В отрывшемся окне – рисунок 3-1 доступно две вкладки: Current отображает значения работающего экземпляра, т.е. значения из представления V$PARAMETER. Вкладка SPFile  содержит информацию записанную в spfile и доступную в представлении V$SPPARAMETER.

    Динамическим параметрам можно установить новое значение в этом же окне. Для изменеия статических параметров необходимо выбрать вкладку SPFile. Также можно изменить параметры используя команду ALTER SYSTEM. Примеры выполнения этой команды показаны на рисунке 3-2. Вначале просмотрим текущее значение параметра DB_CREATE_FILE_DEST – оно одинаковое для запущенного экземпляра и spfile. Затем установим значения параметров используя ключевое слово SCOPE (BOTH – значение по умолчанию при использовании SPFILE, MEMORY – значение по умолчанию при использовании PFILE).

    11

    12

    Oracle ищет подходящий файл параметров в следующем порядке

    • Пытается использовать файл spfile${ORACLE_SID}.ora в директории $ORACLE_HOME/dbs (Unix) или ORACLE_HOME/database (Windows)
    • Пытается использовать файл spfile.ora в директории $ORACLE_HOME/dbs (Unix) или ORACLE_HOME/database (Windows)
    • Пытается использовать файл init${ORACLE_SID}.ora в директории $ORACLE_HOME/dbs (Unix) or ORACLE_HOME/database (Windows)

    Вы можете переопределить местонахождение PFILE заданное по умолчанию указав параметр PFILE в команде запуске экземпляра

    STARTUP PFILE=’/oradata/spfileORCL.ora’

    Параметра SPFILE у команды STARTUP нет. Можно указать на желаемый SPFILE только прописав параметр SPFILE в файле PFILE.

    PFILE можно конвертировать в SPFILE вызвав команду CREATE SPFILE[=’filename’] FROM PFILE[=’pfilename’] (параметры в квадратных скобках опциональны и значение по умолчанию формируется из переменных ORALCE_HOME и SID). Также можно выполнить обратное преобразование вызвыв команду CREATE PFILE FROM SPFILE.

    Команды CREATE PFILE и CREATE SPFILE могут быть выполнены в любое время, даже без работающего экземпляра

    Базовые параметры

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

    select name,value from v$parameter where isbasic=’TRUE’ order by name;

    Также можно выполнить запрос сразу к двум представлениям

    select p.name pfilename,p.value pfilevalue,s.name,s.value from v$spparameter s join v$parameter p on s.name=p.name where p.isbasic=’TRUE’ order by name;

    Список базовых параметров и их описание представлены в таблице 3-1

    13

    14

    Изменение параметров

    Статические параметры могут быть изменены только командой ALTER SYSTEM с аргументом SCOPE=SPFILE. Эта команда изменяет SPFILE. Статические параметры изменяют экземпляр БД только после перезапуска. К примеру статическим параметром является LOG_BUFFER. Если вы хотите измение его значение то вам необходимо выполнить команду

     

    alter system set log_buffer=6m;

     

    Такой вызов команды приведёт к ошибке

    15

    Для успешной обработки команды необходимо добавить аргумент SCOPE=SPFILE. Команда будет выполнена успешно, однако для применения изменений экземпляр БД необходимо перезапустить.

    Параметры применяются ко всей БД либо к конкретной сессии, либо и для сессий и для БД. Примером параметра который указывается для БД, но может также дополнительно настраивается для сессий является OPTIMIZER_MODE.  Значение этого параметра влияет на то, как Oracle будет выполнять запросы. Доступные значения ALL_ROWS и FIRST_ROWS. При выборе ALL_ROWS оптимизатор генерирует план выполнения запроса таким образом, чтобы закончить выполнение как можно быстрее, тогда как FIRST_ROWS создает такой план запроса, который вернёт часть результата как можно быстрее, тогда как запрос полностью будет выполняться гораздо дольшее время. Таким образом если ваша БД обычно используется для долгих DSS (Decision Support System) запросов, но некоторые пользователи используют БД для интерактивной работы то значение для системы может быть установлено ALL_ROWS а для сессий определенных пользователей FIRST_ROWS. Это достигается путем выполнения запросов

     

    alter system set optimizer_mode=all_rows;

    alter session set optimizer_mode=first_rows;

     

    Существует всего несколько параметров которые указываются только для сессии. Главным примером является NLS_DATE_FORMAT. Этот параметр, который управляет форматом отображения даты и время, указывается в файле параметров, но не может быть изменен командой ALTER SYSTEM. Т.е. он является статическим, так как влияет на работу экзмепляра, но он может быть настроен на уровне сессии командой

     

    alter session set nls_date_format=’dd-mm-yy hh24:mi:ss’;

     

    Этот запрос установит формат даты/время для текущей сессии, но не затронет другие сессии.

  • Установка и создание БД Oracle — Итоги

    Инструменты для администрирования Oracle

    Установка: OUI

    Создание БД и изменения: DBCA, DBUA

    Инструменты для выполнения SQL команд: SQL *Plus, SQL Developer

    Для резервного копирования: RMAN, Oracle Secure Backup

    Администрирования сети: Oracle Net Manager, Oracle Net Configuration Assistant

    Обработка данных: Data Pump, SQL* Loader
    Управление: Oracle Enterprise Manager, Database Control и Grid Control

     

    Планирование установки сервера Oracle

    Аппаратные требования

    Свободное пространство
    Графический терминал
    Требования операционной системы

    Пакеты
    Настройки ядра
    OFA

     

    Установка Oracle используя OUI

    Системные пользователи
    Системные переменные
    Суперпользователь
    Типы установки

     

    Создание БД используя DBCA

    БД может быть создана из командной строки или с помощью DBCA

    DBCA может установить БД из шаблона
    DBCA и команды в SQL *Plus могут удалить БД

    Экземпляр БД должен быть создан перед созданием БД

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

  • Использование DBCA для создания БД

    Процесс создания БД состоит из следующих шагов

    1. Создание файла параметров
    2. Создание экземпляра
    3. Выполнение команды CREATE DATABASE / это приведёт к созданию минимум файла контроля, двух файлов логов, двух файлов данных для табличных пространств SYSTEM и SYSAUX внутри которых будет создан словарь данных.
    4. Запуск SQL скриптов для создания представлений надо словарём данных и необходимых PL/SQL объектов
    5. Запуск SQL скриптов для создания объектов необходимых для работы Enterprise Manager Database Control и других настроеных в процессе установки утилит

    В системе Windows также необходим дополнительный шаг, так как в Windows Oracle сервер работает как сервис. Oracle предоставляет дополнительный инструмент oradim.exe в помощь при создании этого сервиса

    Эти шаги могут быть последовательно выполнены из SQL *Plus или с помощью специального графического инструмента DBCA (Database Configuration Assistant). Также вы можете написать свои скрипты для этой цели или использовать «тихую» установку.

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

    DBCA написан на Java и поэтому он выглядит одинаково на всех платформах. На Unix подобных системах вы запускаете DBCA на компьютере где вы хотите создать БД, однако выводить графические интерейс можно на любом компьютере где установлен X сервер для отображения графической информации. Путём установки системной переменной DISPLAY можно перенаправить вывод инфомрации на другое устройство. К примеру команда export DISPLAY=10.10.10.65:0.0 перенаправит информацию на компьютер с етевым адресом 10.10.10.65 вне зависимости от того где реально запущен DBCA.

    Для запуска DBCA на Linux вначале необходимо установить системные переменные ORACLE_BASE,ORACLE_HOME,PATH и LD_LIBRARY_PATH. Примерные значения могут быть такими

    export ORACLE_BASE=/u02/app/db11g

    export ORACLE_HOME=$ORACLE_BASE/product/11.1.0/db_1

    export PATH=$ORACLE_HOME/bin:$PATH

    export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH

    И запустить приложение вызвав команду dbca.

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

    Если будет установлен Enterprise Manager Database Control, то тогда необходимо выполнить ещё один предварительные шаг; настройка listener-а БД. Это необходимо так как Database Control всегда подключается к БД с помощью listener-а и в процесе установки проверяет наличие хотя бы одного доступного listener-а. Listener можно легко настроить с помощью Net Configuration Assistant (netca).

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

    DBCA создаёт скрипты и файлы которые находятся в папке ORACLE_BASE/admin/DB_NAME/scripts.

    Файл параметров Parameter File

    Рассмотрим файл параметров, с именем init.ora. Ниже представлен фрагмент сгенерированного DBCA файла

    ######################################################################

    # Copyright (c) 1991, 2001, 2002 by Oracle Corporation

    ######################################################################

    ###########################################

    # Cache and I/O

    ###########################################

    db_block_size=8192

    ###########################################

    # Cursors and Library Cache

    ###########################################

    open_cursors=300

    ###########################################

    # Database Identification

    ###########################################

    db_domain=»»

    db_name=ocp11g

    ###########################################

    # File Configuration

    ###########################################

    control_files=(«D:\oracle\app\oradata\ocp11g\control01.ctl»,

    «D:\oracle\app\oradata\ocp11g\control02.ctl»,

    «D:\oracle\app\oradata\ocp11g\control03.ctl»)

    db_recovery_file_dest=D:\oracle\app\flash_recovery_area

    db_recovery_file_dest_size=2147483648

    ###########################################

    # Job Queues

    ###########################################

    job_queue_processes=10

    ###########################################

    # Miscellaneous

    ###########################################

    compatible=11.1.0.0.0

    diagnostic_dest=D:\oracle\app

    ###########################################

    # NLS

    ###########################################

    nls_language=»ENGLISH»

    nls_territory=»UNITED KINGDOM»

    ###########################################

    # Processes and Sessions

    ###########################################

    processes=150

    ###########################################

    # SGA Memory

    ###########################################

    sga_target=318767104

    ###########################################

    # Security and Auditing

    ###########################################

    audit_file_dest=D:\oracle\app\admin\ocp11g\adump

    audit_trail=db

    remote_login_passwordfile=EXCLUSIVE

    ###########################################

    # Shared Server

    ###########################################

    dispatchers=»(PROTOCOL=TCP) (SERVICE=ocp11gXDB)»

    ###########################################

    # Sort, Hash Joins, Bitmap Indexes

    ###########################################

    pga_aggregate_target=105906176

    ###########################################

    # System Managed Undo and Rollback Segments

    ###########################################

    undo_management=AUTO

    undo_tablespace=UNDOTBS1

     

    Все строки начинающиеся с символа # являются комментариями. Всего доступно около 300 параметров однако DBCA устанавливает значения только для некоторых. Два главных это DB_BLOCK_SIZE и CONTROL_FILES. DB_BLOCK_SIZE устанавливает значение размера буферов в буфере кэша БД (database buffer cache). Так же это значение будет использовано для форматирования файлов данных табличных пространств SYSTEM и SYSAUX. После создания нельзя изменить это значение. CONTROL_FILES являетяс указателем на все копии контрольного файла. В данный момент времени этот файл не существует и значение укажет экзмепляру где создать новый файл.  Назначение некоторых других параметров понятно, и все они описаны в документации Oracle. Единственный параметр у которого нет значения по умолчанию – это DB_NAME.

    Скрипт создания БД

    Ниже представлен скрипт который DBCA выполняет в процессе создания БД (пример для Windows).

    mkdir D:\oracle\app

    mkdir D:\oracle\app\admin\ocp11g\adump

    mkdir D:\oracle\app\admin\ocp11g\dpdump

    mkdir D:\oracle\app\admin\ocp11g\pfile

    mkdir D:\oracle\app\cfgtoollogs\dbca\ocp11g

    mkdir D:\oracle\app\flash_recovery_area

    mkdir D:\oracle\app\oradata\ocp11g

    mkdir D:\oracle\app\product\11.1.0\db_3\database

    set ORACLE_SID=ocp11g

    set PATH=%ORACLE_HOME%\bin;%PATH%

    D:\oracle\app\product\11.1.0\db_3\bin\oradim.exe -new -sid OCP11G

    -startmode manual -spfile

    D:\oracle\app\product\11.1.0\db_3\bin\oradim.exe -edit -sid OCP11G

    -startmode auto -srvcstart system

    D:\oracle\app\product\11.1.0\db_3\bin\sqlplus /nolog

    @D:\oracle\app\admin\db11g\scripts\ocp11g.sql

     

    Вначале скрипт создаёт несколько папок внутри папки ORACLE_BASE. Далее устанавливаются значения системной переменной ORACLE_SID и добавляется путь ORACLE_HOME/bin к переменной PATH. Две команды которые используют oradim.exe не используются в Linux. В Windows они нужны чтобы настроить запуск экземпляра БД как сервиса.

    После скрипт запускает SQL *Plus и выполняется SQL скрипт %DB_NAME%.sql который управляет процессом создания БД

    set verify off

    PROMPT specify a password for sys as parameter 1;

    DEFINE sysPassword = &1

    PROMPT specify a password for system as parameter 2;

    DEFINE systemPassword = &2

    PROMPT specify a password for sysman as parameter 3;

    DEFINE sysmanPassword = &3

    PROMPT specify a password for dbsnmp as parameter 4;

    DEFINE dbsnmpPassword = &4

    host D:\oracle\app\product\11.1.0\db_3\bin\orapwd.exe

    file=D:\oracle\app\product\11.1.0\db_3\database\PWDocp11g.ora

    password=&&sysPassword force=y

    @D:\oracle\app\admin\ocp11g\scripts\CreateDB.sql

    @D:\oracle\app\admin\ocp11g\scripts\CreateDBFiles.sql

    @D:\oracle\app\admin\ocp11g\scripts\CreateDBCatalog.sql

    @D:\oracle\app\admin\ocp11g\scripts\emRepository.sql

    @D:\oracle\app\admin\ocp11g\scripts\postDBCreation.sql

     

    Вначале задаются пароли для системных учётных записей (эти пароли указываются в процессе работы с DBCA). Потомы вызывается программа orapwd которая создаст файл паролей для БД. Имя файла будет %ORACLE_HOME%\database\PWD<db_name>.ora для Windows или $ORACLE_HOME/dbs/orapw<db_name> для Linux. После этого запускается скрипт CreateDB.sql который непосредственно создаёт БД.

    Команда CREATE DATABASE

    Пример скрипта CreateDB.sql

     

    connect «SYS»/»&&sysPassword» as SYSDBA

    set echo on

    spool D:\oracle\app\admin\ocp11g\scripts\CreateDB.log

    startup nomount pfile=»D:\oracle\app\admin\ocp11g\scripts\init.ora»;

    CREATE DATABASE «ocp11g»

    MAXINSTANCES 8

    MAXLOGHISTORY 1

    MAXLOGFILES 16

    MAXLOGMEMBERS 3

    MAXDATAFILES 100

    DATAFILE ‘D:\oracle\app\oradata\ocp11g\system01.dbf’

    SIZE 300M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED

    EXTENT MANAGEMENT LOCAL

    SYSAUX DATAFILE ‘D:\oracle\app\oradata\ocp11g\sysaux01.dbf’

    SIZE 120M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED

    SMALLFILE DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE

    ‘D:\oracle\app\oradata\ocp11g\temp01.dbf’ SIZE 20M REUSE

    AUTOEXTEND ON NEXT 640K MAXSIZE UNLIMITED

    SMALLFILE UNDO TABLESPACE «UNDOTBS1» DATAFILE

    ‘D:\oracle\app\oradata\ocp11g\undotbs01.dbf’ SIZE 200M REUSE

    AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED

    CHARACTER SET WE8MSWIN1252

    NATIONAL CHARACTER SET AL16UTF16

    LOGFILE GROUP 1 (‘D:\oracle\app\oradata\ocp11g\redo01.log’) SIZE 51200K,

    GROUP 2 (‘D:\oracle\app\oradata\ocp11g\redo02.log’) SIZE 51200K,

    GROUP 3 (‘D:\oracle\app\oradata\ocp11g\redo03.log’) SIZE 51200K

    USER SYS IDENTIFIED BY «&&sysPassword»

    USER SYSTEM IDENTIFIED BY «&&systemPassword»;

    spool off

     

    Скрипт подключается к экземпляру, используя авторизацию из файла паролей. Команды echo и spool выводя в лог всё что происходит.

    Команда STARTUP NOMOUNT создаёт структуры экземпляр в памяти используя файл параметров. NO MOUNT означает что база данных не будет подключена и открыта. После того как эта команда выполнена – экземпляр существует в памяти и работают фоновые процессы. Размеры SGA установлены согласна файла параметров.

    Команда CREATE DATABASE использует имя базы данных и множество параметров. Вначале устанавливаются определенные ограничения для всей БД. Они могут изменять позже, но лучше всего устанавливать допустимые значения сейчас, поскольку их изменение очень трудоёмкая операция. Далее указываются где создать файлы данных для табличных пространств SYSTEM, SYSAUX и UNDO. Также указываются где хранить файлы для временного табличного пространства (TEMPORARY tablespace). Так же указывается кодировка БД для словаря данных и столбцов типа VARCHAR2, CHAR и CLOB. Параметры для файлов логов и т.д. В конце идёт указание на использование паролей из файла паролей и отключение записи в лог.

    Этот файл с командой CREATE DATABASE создаст базу данных. После успешного выполнения экзмепляр будет работать в памяти и БД будет создана, включая файлы контроля, файлы данных и файлы логов. Словарь данных будет сгенерирован в табличном пространстве SYSTEM. Однако несмотря на то что БД создана, она пока непригодна для использования. Оставшиеся скрипты, которые вызовет файл %DB_NAME%.sql исправят это. У команды CREATE DATABASE много параметров, однако все они имеют значение по умолчанию. Например если вы не укажете файлы данных для табличного пространства SYSTEM все равно создатся минимум один файл. Для табличных пространств UNDO и TEMPORARY нет значений по умолчанию – но БД может быть создана без них, а потом можно указать эти значения.

    Скрипты после создания БД

    Остальные скрипты вызываемые %DB_NAME%.sql зависят от выбора в процессе работы с DBCA. В нашем примере был выбран только Enterprise Manager Database Control и поэтому будут запущены только 4 скрипта.

    CreateDBfiles.sql – создаёт небольшон табличное пространство USERS где будет хранится объекты созданные пользователями

    CreateDBCatalog.sql – важный скрипт. Он запускает скрипты для построения представлений над словарём данных и генерации PL/SQL объектов которые делают возможным управление БД

    emRepository.sql – этот скрипт создаёт объекты необходимые для работы Enterprise Manager Database Control

    postDBCreation.sql – создание файла параметров сервера из файла параметров init.ora, включение пользователей DBSNMP и SYSMAN используемых для работы Enterprise Manager и запуск Enterprise Manager Configuration Assistant (emca) для настройки новой БД.

  • Установка программ Oracle с использованием OUI

    Чтобы запустить OUI необходимо войти в систему под учётной записью имеющей доступ для чтения дистрибутива и записи в директорию выбранную как ORACLE_BASE. Затем запустить OUI вызвав команду

    setup.exe — в системе Windows

    runInstaller.sh – в системе Linux

    Чтобы избежать запуска проверки системы необходимо добавить параметры

    runInstaller –ignoreSysPrereqs

    Также возможно установка не в режиме диалога, а так называемая «тихая» установка. Это бывает необходимо если отсутствует графическая подсистема, или если вы часто устанавливаете приложения на одинаковые сервера. Такая установка требует файл, в котором будут  храниться все необходимые параметры для установки. Синтаксис команды для запуска такого типа установки

    runInstaller –silent –responsefile responsefilename

    Создание БД используя DBCA

    Создание БД — несложная задача (практически это выполнение команды из двух слов и несколько минут времени ожидания), но необходимо понимать что в реальности просиходит в системе.

    Экземпляр БД (instance), БД и словарь данных (data dictionary)

    Сервер Oracle состоит из instance-а и БД; это две отдельные части, но они работают вместе. Instance это набор структур в оперативной памяти и фоновых процессов работающих на процессорах сервера, его существование временно, он может быть запущен и остановлен. БД это файлы на жёстком диске; они создаются однажды и существуют пока существует БД. Создание экземпляра БД есть не что иное, как выделение памяти и запуск процессов. БД создаётся экземпляром БД один раз и затем экземпляр может «открывать» и «закрывать» БД много раз. БД доступна только через экземпляр БД.

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

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

    Экзмепляр управляется файлом параметров (parameter file). Этот файл содержит инструкции как работать экземпляру: какой объём памяти выделять, какие структуры данных будут созданы, поведение фоновых процессов. После запуска экземпляра, он работает в режиме no mount. Такой режим подразумевает что экземплярд работает, он он не подключен к БД. На самом деле в этот момент БД ещё может быть даже не создана.

    У всех параметров, указанных в файле параметров или нет, есть значения по умолчанию, кроме одного: имени БД. Параметр DB_NAME указывает к какой БД будет подключаться экземпляр. Это же значение указано в файле контроля (control file). Параметр CONTROL_FILES в файле параметров хранит указатель на файл контроля. Эти параметры определяют связь между экземпляром и БД. Когда инстанс обрабатывает файл контроля (который он находит с помощью параметра CONTROL_FILES) и обнаруживается несоответсвие имён – база не будет подключена (no mount). Если же всё произошло успешно (файл контроля корретный)  — база будет подключена (mount). Если вы потеряли файл контроля или он повреждён – будет невозможно подключиться к БД. Файл контроля небольшого размера, однако он очень важен для БД.

    Внутри файла контроля – указатели на остальные файлы БД (файлы логов, и файлы данных). После подключения к БД (mount) экзмпляр может открыть (open) БД путём чтения файлов. Открытая (open) БД – это БД, у которой экземпляр открыл все файлы логов и данных. Также внутри файла контроля находится таблица соответствия файлов данных и табличных пространств. Это позволяет экземпляру найти файлы данных в которых хранится информация табличного пространства SYSTEM. В табличном пространстве SYSTEM хранится словарь данных, который позволяет соотнести объекты из SQL запросов с сегментами и обработать запрос.

    Следовательно создание БД должно включать следующие шаги

    • Создать экземпляр
    • Создать БД
    • Создать словарь данных

    Фактически эти шаги разделены немного по другому

    • Создание экземпляра
    • Создание БД и объектов словара данных
    • Создание представлений словаря данных

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

    Создание словаря данных по сути является запуском набора SQL команд, сгруппированных в файлы скриптов. Их можно посмотреть в папке ORACLE_HOME/rdbms/admin. Они запускаются в момент вызова команды CREATE DATABASE. Первым исполняется sql.bsq, который в свою очередь вызывает другие скрипты, создающие таблицы и другие объекты словаря данных.

    Предстваления и объекты которые необходимы для доступного человеку просмотра словаря данных создаются другими скриптами, которые также находятся в папке ORACLE_HOME/rdbms/admin, но начинаются с префикса «cat». К примеру скрипты catalog.sql и catproc.sql. Эти скрипты должны запускаться сразу же после создания БД.

  • Планирование установки БД Oracle

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

    Некоторые люди привержены их любимой ОС, однако в каждой есть свои минусы и плюсы и не для всех ОС есть все необходимые приложения. Oracle поддерживает все популярные платформы:

    • Linux на платформе Intel и AMD
    • Windows на платформе Intel и AMD
    • Solaris на платформе SPACE
    • AIX на платформе POWER
    • HPUX на платформе PA-RISC

    Эти комбинации наиболее популярны, однако существует м ного других. Некоторые ОС поддерживают 32битную и 64битную архитектуру и Oracle обычно поддерживает обе. Когда выбираете платформу, необходимо оценивать такие факторы как

    • Стоимость
    • Простота в использование
    • Масштабирование
    • Отказоустойчивость
    • Производительность

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

    Linux заслуживает отдельного обсуждения.  Oracle широко использует и развивает Linux. Наиболее популярные дистрибутивы это Red Hat и Suse, но Oracle так же предоставляет свою сборку Oracle Linux Enterprise. Этот дистрибутив имеет все необходимые пакеты для работы и поддерживается компанией Oracle. Таким образом можно создать целую среду поддерживаемую одним поставщиком.

    Программные ресурсы и ОС

    Выбор программного обеспечения происходит обычно после анализа планируемого объёма данных и активность БД. Есть специальные учебные пособия по выбору аппаратного обеспечения для БД. Минимальные системные требования для системы

    1ГБ оперативной памяти

    1.5ГБ файл подкачки

    400Мб свободного дискового пространства во временной директории

    1.5-3.5 ГБ для домашней директории Oracle

    1.5ГБ для БД примеров

    2.4ГБ для архивов

    Процессор с тактовой частотой не меньше 1 ГГц

    Такой широкий диапазон для домашней директории обусловлен вариативностью платформ. 2.5 Гб обычно занимает установка на ОС Windows с файловой системой NTFS. 3.5 ГБ для ОС Linux с файловой системой ext3. Временная директория устанваливается системной переменной TEMP. ОС также проверяется на соотвествие

    Архитектуре (32/64 битная архитектура)

    Наличию необходимых компонентов

    Параметров ядра

    Эти проверки будут осуществелены OUI.

    Optimal Flexible Architecture (OFA) Структура директорий

    Домашняя директория будет установлена на файловую систем. Oracle разработал OFA – структуру директорий в файловой системе, благодаря которой можно легко поддерживать различные версии различных программ. Ключевым элементом OFA является две системные переменные: ORACLE_BASE и ORACLE_HOME. ORACLE_BASE это папка на сервере, внутри которой будут установленые все программы всех версий. Каждая версия каждого продукта имеет свою домашнюю директорию ORACLE_HOME. OFA стандарт для Linux и Unix ORACLE_BASE предполагает использование шаблона /pm/h/u где

    p – константа, u

    m – числовое значение, к примеру 01

    p – строка к примеру app

    u – системный пользователь(владелец программ Oracle) к примеру oracle

    В Windows стандартным значением ORACLE_BASE является структура \oracle\app в корневом каталоге любого системного тома.

    Для домашней директории стандартом является значение переменной ORACLE_BASE плюс /product/v/db_n где

    product – константа

    v – версия, к примеру 11.1.0

    db_n – значение получаемое установщиком при работе, db – database и число увеличивающееся на единицу для каждой последующей установки программы.

    Таким образом получаются следующие значения ORACLE_BASE и ORACLE_HOME для Linux

    /u01/app/oracle

    /u01/app/oracle/product/11.1.0/db_1

    И для Windows

    D:\oracle\app

    D:\oracle\app\product\11.1.0\db_1

     

    Директория для файлов самой БД обычно вида ORACLE_BASE/q/d где

    q – строка oradata

    d – название БД

    Для БД с именем orcl директория будет

    /u01/app/oracle/oradata/orcl