Oracle standalone что это

Обновлено: 04.07.2024

В этой статье, или серии статей, я расскажу, как поднять оракловый кластер 11gR2 из двух нод, и затем поднять на этом кластере базу данных и настроить отказоустойчивый сервис. В качестве основной ОС будем использовать Linux CentOS 5 x86_64.
Вся процедура состоит из нескольких последовательных этапов:

Настройка окружения: настройка dns-сервера, выделение ip-адресов.
Подготовка железа: серверы, массивы/хранилища. /* Опустим этот этап, ибо он будет специфичен в каждом случае */
Подготовка операционной системы: установка необходимых пакетов, создание необходимых юзверей и структуры каталогов.
Подготовка и конфигурирование ASM.
Установка Oracle Grid Infrastructure 11gR2.
Установка сервера базы данных Oracle RDBMS Server 11gR2.
Создание cluster-based сервиса базы данных с TAF (Transparent-Application-Failover) и FAN (Fast Application Notification).
Радость по поводу успешной настройки 🙂

Совсем немного теории.

Такс, вернемся к узлам. На каждой ноде устанавливается Oracle Clusterware, начиная с 11-й версии это отдельный софт, и его желательно ставить из-под отдельного пользователя. Для функционирования Clusterware необходим так называемый voting disk, который должен быть доступен одновременно всем нодам. Лучше всего использовать ASM, и инициализировать ASM диски на расшаренном хранилище. Тогда и все данные БД можно будет так же расположить на ASM. Далее, на каждый узел ставится Oracle RDBMS Server.

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

Пожалуй, хватит теории, перейдем к практике!

Настройка dns.

Не буду расписывать как настроить сам dns-сервер. По этому поводу в инете полно материалов, а может быть даже в вашей мегакомпании есть отдельные сетевики/админы, которые вам все сделают 🙂 Поговорим про настройку dns в контексте кластера. Вот скрин того, что написано в документации оракл.

На каждую ноду надо по 3 адреса: собственный публичный адрес ноды, виртуальный адрес ноды, приватный адрес ноды для интерконнекта + минимум 3 адреса SCAN для кластера. Если хочется, можно приватные адреса нод прописать в /etc/hosts на каждом узле. Но имейте в виду, что если вы потом добавите еще ноды, то эту операцию придется снова повторить на каждой ноде. Так что лучше ве прописать в dns, тогда при необходимости все правки надо будет вносить всего лишь в одном месте. Вот примеры конфига named и djbdns.

Подготовка операционной системы.

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

Далее необходимо создать структуру каталогов, в которой будет размещаться софт оракла. Следуя схеме OFA (ну или частично следуя 🙂 сделаем /u01/app/grid /u01/app/oracle и так далее. Опять же, делаем это на всех узлах кластера.

Подготовка и конфигурирование ASM.

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

Итак, ставим пакеты на каждой ноде.

После этого можно приступать к конфигурации ASM. Первым делом надо сконфигурировать сам драйвер. Это делается один раз. Запускаем конфигурирование и указываем некоторые данные: пользователя, из-под которого будет работать драйвер и кому будет принадлежать интерфейс, группу, запускать ли драйвер при старте системы. Если вы придерживались этой статьи, и завели двух пользователей, одного для кластера, другого для базы данных, то здесь надо указать пользователя кластера.

После этого можно создать диски ASM из устройств с расшаренного хранилища. В моем случае в качестве хранилища выступает массив EMC, подключенный двумя оптическими шнурками с настроенным failover. Поэтому в моей системе эти диски видны как /dev/emcpower*. Для начала размечаем диски с помощью fdisk или любой другой утилиты, какая вам больше нравится. После этого инициализируем эти диски как ASM. Делаем это на одной ноде.

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

После этого можно приступать к установке clusterware.

Установка Oracle Grid Infrastructure.

Проделав все вышеперечисленные процедуры и операции мы подошли к тому, что можно начинать ставить софт Оракл. Первым делом надо поставить Oracle Grid Infrastructure, в составе этого пакета идут необходимые кластерные компоненты Oracle Clusterware. К этому моменту у нас должен быть настроен dns, инициализированы ASM диски, созданы необходимые пользователи и структура каталогов, куда все будем ставить.

Вот, кстати, наглядная схемка компонентов Ораклового кластера и последовательность старта 🙂 Кому интересно копнуть глубже, в конце будет список документов, которые можно почитать по теме.

Выбираем нужные языки

Далее указываем название нашего кластера и важно указываем scan-адрес, который мы прописали в dns.

Далее настраиваем наши ноды. По умолчанию, инсталлер конечно же добавляет одну ноду, ту, на которой он был запущен. Добавляем сюда нашу вторую ноду, указываем пароль пользователя, чтобы проверить доступность ноды по ssh. Так же здесь указываем виртуальные адреса нод, которые мы так же прописали в dns.

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

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

Здесь стоит еще сказать, что у Grid Infrastructure 11.2.0.1 и 11.2.0.3 несколько разные требования и проверки. В случае установки 11.2.0.1 у меня возникли только ошибки, описанные выше. При установке версии 11.2.0.3 установщик так же ругнулся на неверные настройки в /etc/resolv.conf. В свежей версии проверяются различные таймауты на запросы к днс-серверу, так что потребовалось дополнительно настроить таймауты и количество попыток. Делается это так:

Ну что ж, на этом установка Oracle Grid Infrastructure for Cluster успешно (я надеюсь) завершается.

Чтобы проверить, что все прошло успешно, и наш новенький кластер функционирует как положено, можно воспользоваться утилитой crsctl. Запускаем ее вот такую штуку из-под рута на каждой ноде и убеждаемся, что все онлайн.

Установка Oracle Database Server 11gR2.

Создаем новую базу данных.

Указываем, что мы хотим создать кластерную базу данных. Выбираем наши ноды, указываем пароль пользователя oracle и проверяем доступность нод по ssh.

Выбираем расширенный режим установки.

Выбираем нужные нам языки и затем редакцию базы данных.

Далее указываем место установки софта. Указываем здесь те папки, которые мы подготовили в начале.

Выбираем тип базы данных.

Указываем имя БД и ее SID.

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

Указываем где мы будем хранить данные. Выбираем конечно же ASM, иначе зачем мы его настраивали 🙂 Указываем пароль ASMSNMP пользователя.

Сразу настраиваем ежедневные бэкапы в ASM. Затем указываем дисковую группу ASM, где будут лежать данные, у меня это DATA.

Указываем пароли системных пользователей баз данных, а затем системные группы пользователей с привилегиями sysdba и sysoper.

Крткий обзор нашей установки и погнали.

Как всегда, в процессе установки надо будет выполнить скрипт из-под рута. Делаем это на всех нодах.

Ну вот и все! Установка прошла успешно.

Создание cluster-based сервиса базы данных с TAF и FAN.

Теперь можем запустить его и проверить что этот сервис запущен и работает.

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

Теперь, если зайти в em dbconsole в раздел Availability, можно увидеть ссылку: Cluster Managed Database Services. Вот два скриншота из версий 11.2.0.1 и 11.2.0.4

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

Ну вот мы и подошли к самому главному и заключительному пункту нашей статьи.

Радость по поводу успешной настройки.

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

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

Виды кластеров

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

Кластеры высокой готовности или отказоустойчивые кластеры (high-availability clusters или failover clusters) используют избыточные узлы для обеспечения работы в случае отказа одного из узлов.
Кластеры балансировки нагрузки (load-balancing clusters) служат для распределения запросов от клиентов по нескольким серверам, образующим кластер.
Вычислительные кластеры (compute clusters), как следует из названия, используются в вычислительных целях, когда задачу можно разделить на несколько подзадач, каждая из которых может выполняться на отдельном узле. Отдельно выделяют высокопроизводительные кластеры (HPC — high performance computing clusters), которые составляют около 82% систем в рейтинге суперкомпьютеров Top500.

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

Такую систему можно рассматривать как обобщение понятия «кластер». ластеры могут быть сконфигурированы в режиме работы active/active, в этом случае все узлы обрабатывают запросы пользователей и ни один из них не простаивает в режиме ожидания, как это происходит в варианте active/passive.

Oracle RAC и Network Load Balancing являются примерами active/ active кластера. Failover Cluster в Windows Server служит примером active/passive кластера. Для организации active/active кластера требуются более изощренные механизмы, которые позволяют нескольким узлам обращаться к одному ресурсу и синхронизовать изменения между всеми узлами. Для организации кластера требуется, чтобы узлы были объединены в сеть, для чего наиболее часто используется либо традиционный Ethernet, либо InfiniBand.

Программные решения могут быть довольно чувствительны к задержкам — так, например, для Oracle RAC задержки не должны превышать 15 мс. В качестве технологий хранения могут выступать Fibre Channel, iSCSI или NFS файловые сервера. Однако оставим аппаратные технологии за рамками статьи и перейдем к рассмотрению решений на уровне операционной системы (на примере Windows Server 2008 R2) и технологиям, которые позволяют организовать кластер для конкретной базы данных (OracleDatabase 11g), но на любой поддерживаемой ОС.

Windows Clustering

У Microsoft существуют решения для реализации каждого из трех типов кластеров. В состав Windows Server 2008 R2 входят две технологии: Network Load Balancing (NLB) Cluster и Failover Cluster. Существует отдельная редакция Windows Server 2008 HPC Edition для организации высокопроизводительных вычислительных сред. Эта редакция лицензируется только для запуска HPC-приложений, то есть на таком сервере нельзя запускать базы данных, web- или почтовые сервера.

NLB-кластер используется для фильтрации и распределения TCP/IPтрафика между узлами. Такой тип кластера предназначен для работы с сетевыми приложениями — например, IIS, VPN или межсетевым экраном.

Могут возникать сложности с приложениями, которые полага ются на сессионные данные, при перенаправлении клиента на другой узел, на котором этих данных нет. В NLB-кластер можно включать до тридцати двух узлов на x64-редакциях, и до шестнадцати — на x86.

Failoverclustering — это кластеризации с переходом по отказу, хотя довольно часто термин переводят как «отказоустойчивые кластеры».

Узлы кластера объединены программно и физически с помощью LAN- или WAN-сети, для multi-site кластера в Windows Server 2008 убрано требование к общей задержке 500 мс, и добавлена возможность гибко настраивать heartbeat. В случае сбоя или планового отключения сервера кластеризованные ресурсы переносятся на другой узел. В Enterprise edition в кластер можно объединять до шестнадцати узлов, при этом пятнадцать из них будут простаивать до тех пор, пока не произойдет сбой. Приложения без поддержки кластеров (cluster-unaware) не взаимодействуют со службами кластера и могут быть переключены на другой узел только в случае аппаратного сбоя.

Приложения с поддержкой кластеров (cluster-aware), разработанные с использованием ClusterAPI, могут быть защищены от программных и аппаратных сбоев.

Развертывание failover-кластера

Процедуру установки кластера можно разделить на четыре этапа. На первом этапе необходимо сконфигурировать аппаратную часть, которая должна соответствовать The Microsoft Support Policy for Windows Server 2008 Failover Clusters. Все узлы кластера должны состоять из одинаковых или сходных компонентов. Все узлы кластера должны иметь доступ к хранилищу, созданному с использованием FibreChannel, iSCSI или Serial Attached SCSI. От хранилищ, работающих с Windows Server 2008, требуется поддержка persistent reservations.

На втором этапе на каждый узел требуется добавить компонент Failover Clustering — например, через Server Manager. Эту задачу можно выполнять с использованием учетной записи, обладающей административными правами на каждом узле. Серверы должны принадлежать к одному домену. Желательно, чтобы все узлы кластера были с одинаковой ролью, причем лучше использовать роль member server, так как роль domain controller чревата возможными проблемами с DNS и Exchange.

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

На четвертом этапе создается кластер. Для этого из Failover Cluster Management запускается мастер Create Cluster, в котором указываются серверы, включаемые в кластер, имя кластера и дополнительные настройки IP-адреса. Если серверы подключены к сетям, которые не будут использоваться для общения в рамках кластера (например, подключение только для обмена данными с хранилищем), то в свойствах этой сети в Failover Cluster Management необходимо установить параметр «Do not allow the cluster to use this network».

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

Для этого необходимо запустить High Availability Wizard, который можно найти в Services and Applications оснастки Failover Cluster Management.

Cluster Shared Volumes

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

Еще одна проблема, возникающая из-за того, что LUN является минимальной единицей обхода отказа, заключается в том, что при сбое одного приложения, находящегося на LUN, приходится переключать все приложения, которые хранятся на этом LUN, на другой сервер. Во всех приложениях (включая Hyper-V до второго релиза Server 2008) это удавалось обходить за счет многочисленных LUN, на каждом из которых хранились данные только одного приложения. В Server 2008 R2 появилось решение для этих проблем, но предназначенное для работы только с Hyper-V и CSV (Cluster Shared Volumes).

CSV позволяет размещать на общем хранилище виртуальные машины, запускаемые на разных узлах кластера — тем самым разбивается зависимость между ресурсами приложения (в данном случае виртуальными машинами) и дисковыми ресурсами. В качестве файловой системы CSV использует обычную NTFS. Для включения CSV необходимо в Failover Cluster Manage выполнить команду Enable Cluster Shared Volumes. Отключить поддержку CSV можно только через консоль:

Для использования этой команды должен быть загружен Failover Clusters, модуль PowerShell. Использование CSV совместно с live migration позволяет перемещать виртуальные машины между физическими серверами в считанные миллисекунды, без обрыва сетевых соединений и совершенно прозрачно для пользователей. Стоит отметить, что копировать любые данные (например, готовые виртуальные машины) на общие диски, использующие CSV, следует через узел-координатор.

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

Oracle RAC

Oracle Real Application Clusters (RAC) — это дополнительная опция Oracle Database, которая впервые появилась в Oracle Database 9i под названием OPS (Oracle Parallel Server). Опция предоставляет возможность нескольким экземплярам совместно обращаться к одной базе данных. Базой данных в Oracle Database называет ся совокупность файлов данных, журнальных файлов, файлов параметров и некоторых других типов файлов. Для того, чтобы пользовательские процессы могли получить доступ к этим данным, должен быть запущен экземпляр. Экземпляр (instance) в свою очередь состоит из структур памяти (SGA) и фоновых процессов. В отсутствии RAC получить доступ к базе данных может строго один экземпляр.

Опция RAC не поставляется с Enterprise Edition и приобретается отдельно. Стоит отметить, что при этом RAC идет в составе Standard Edition, но данная редакция обладает большим количеством ограничений по сравнению с Enterprise Edition, что ставит под сомнение целесообразность ее использования.

Oracle Grid Infrastructure

Для работы Oracle RAC требуется Oracle Clusterware (или стороннее ПО) для объединения серверов в кластер. Для более гибкого управления ресурсами узлы такого кластера могут быть организованы в пулы (с версии 11g R2 поддерживается два варианта управления — на основании политик для пулов или, в случае их отсутствия, администратором).

Во втором релизе 11g Oracle Clusterware был объединен с ASM под общим названием Oracle Grid Infrastructure, хотя оба компонента и продолжают устанавливаться по различным путям.

Automatic Storage Management (ASM) — менеджер томов и файловая система, которые могут работать как в кластере, так и с singleinstance базой данных. ASM разбивает файлы на ASM Allocation Unit.

Размер Allocation Unit определяется параметром AU_SIZE, который задается на уровне дисковой группы и составляет 1, 2, 4, 8, 16, 32 или 64 MB. Далее Allocation Units распределяются по ASM-дискам для балансировки нагрузки или зеркалирования. Избыточность может быть реализована, как средствами ASM, так и аппаратно.

ASM-диски могут быть объединены в Failure Group (то есть группу дисков, которые могут выйти из строя одновременно — например, диски, подсоединенные к одному контролеру), при этом зеркалирование осуществляется на диски, принадлежащие разным Failure Group. При добавлении или удалении дисков ASM автоматически осуществляет разбалансировку, скорость которой задается администратором.

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

Oracle рекомендует использовать ASM в качестве решения для управления хранением данных вместо традиционных менеджеров томов, файловых систем или RAW-устройств.

Развертывание Oracle RAC

Рассмотрим этапы установки различных компонентов, необходимых для функционирования Oracle RAC в режиме active/active кластера с двумя узлами. В качестве дистрибутива будем рассматривать последнюю на момент написания статьи версию Oracle Database 11g Release 2. В качестве операционной системы возьмем Oracle Enterprise Linux 5. Oracle Enterprise Linux — операционная система, базирующаяся на RedHat Enterprise Linux. Ее основные отличия — цена лицензии, техническая поддержка от Oracle и дополнительные пакеты, которые могут использоваться приложениями Oracle.

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

На узлах должен быть настроен доступ к внешним общим дискам, на которых будут храниться файлы базы данных и файлы Oracle Clusterware. К последним относятся votingdisk (файл, определяющий участников кластера) и Oracle Cluster Registry (содержит конфигурационную информацию — например, какие экземпляры и сервисы запущены на конкретном узле). Рекомендуется создавать нечетное количество votingdisk. Для создания и настройки ASMдисков желательно использовать ASMLib, которую надо установить на всех узлах:

Кроме интерфейса для взаимодействия с хранилищем на узлах желательно настроить три сети — Interconnect, External и Backup.
Необходимо настроить IP-адресацию (вручную или с использованием Oracl e GNS) и DNS для разрешения всех имен (или только GNS).

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

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

/u01/grid/bin/crsctl check cluster –all

Выполнив проверку, можно приступать к установке базы данных. Для этого запускаем Oracle Universal installer, который используется и для обычной установки базы.

Кроме active/active-кластера в версии 11g R2 существуют две возможности для создания active/passive-кластера. Одна из них — Oracle RACOneNode. Другой вариант не требует лицензии для RAC и реализуется средствами Oracle Clusterware. В этом случае вначале создается общее хранилище; затем устанавливается Grid Infrastructure, с использованием ASM_CRS и SCAN; а после этого на узлы устанавливается база данных в варианте Standalone. Далее создаются ресурсы и скрипты, которые позволяют запускать экземпляр на другом узле в случае недоступности первого.

Заключение

Oracle RAC совместно с Oracle Grid Infrastructure позволяют реализовать разнообразные сценарии построения кластеров. Гибкость настройки и широта возможностей компенсируются ценой такого решения.

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

Виртуализация, вычислительные платформы, СХД, проектирование, проектная документация

Посмотрел в интернетах: есть русскоязычные описания как установить и настроить RAC, а вот внятных описаний как сконфигурировать/потестить/сделать failover и failback для Oracle DataGuard — не нашел. Решил заполнить этот пробел, благо недавно внезапно пришлось в эту тему погрузиться.

Используемое мною средство виртуализации: VMware Workstation 10.0.3 build-1895310

Конфигурация стандартной виртуальной машины для установки ПО Oracle:
2xCPU, 4GB RAM, 100GB SCSI HDD, 2xNIC
Конфигурация виртуальной машины для размещения iscsi target:
1xCPU, 1GB RAM, 100GB SCSI HDD, 1xNIC

3.3 В реальной инсталляции еще необходимо настроить таймауты на запросы и кол-во попыток запросов к DNS-серверу. Делается это добавлением следующих строк к /etc/resolv.conf:
options attempts:1
options timeout:1

13. Скачиваем Oracle GRID (версии 11.2.0.3!), помещаем дистрибутив Oracle GRID в /distr/grid на хосте rac-node01

Настраиваем сквозную аутентификацию и доверительные отношения между узлами кластера для пользователей grid и oracle.
На хосте rac-node01 выполнить:

на хосте rac-node02 выполнить:

Ошибку с разрешением SCAN-имен игнорируем, поскольку у нас все разрешается через файл /etc/hosts, а не через DNS.

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

18. Устанавливаем Oracle DBMS (версии 11.2.0.3!), для этого на хосте rac-node01 помещаем дитрибутив Oracle DBMS в /distr/database
заходим на 192.168.110.163:3 клиентом VNC. Затем выполняем из консоли ssh сервера rac-node01:

В конце инсталлятор попросит выполнить из под пользователя root инсталляционные скрипты на всех хостах RAC, рекомендую выполнять последовательно, один хост за другим, а не в параллель.

19. Создаем тестовую БД
$ /u01/app/oracle/product/11.2.0/dbhome_1/bin/dbca

В файл /home/oracle/.bash_profile (можно на всех хостах RAC) добавляем:
PATH=$PATH:$HOME/bin:/u01/app/oracle/product/11.2.0/dbhome_1/bin
export PATH
DISPLAY=192.168.110.163:3
export DISPLAY
ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
export ORACLE_HOME
ORACLE_OWNER=oracle
export ORACLE_OWNER
NLS_LANG=AMERICAN_AMERICA.CL8MSWIN1251
export NLS_LANG
ORACLE_SID=TEST
export ORACLE_SID

21. Создадим тестовую инфраструктуру (она нам пригодится и потом, при тестировании DG) и потестируем созданную БД:
Скачаем Winbench, разархивируем на виртуальную машину client01 под управлением Windows 8.1, в файле c:\windows\system32\drivers\etc\hosts пропишем все нужные имена и IP (все то же, что прописывали в файлы /etc/hosts).
С помощью c:\path\to\swingbench\winbin\oewizard.bat создадим тестовое окружение и наполним БД фейковыми данными (строка коннекта: //rac01-scan/test.rac)

Упс, не хватает объема temporary tablespace, исправим:

$ sqlplus sys@TEST as sysdba
SQL> select * from dba_temp_free_space;
Действительно, около 60МБ.
SQL> select file_name from dba_temp_files;

Пробуем еще раз,

окружение успешно создано.

22. Тестируем:
c:\path\to\swingbench\winbin\coordinator.bat -g
c:\path\to\swingbench\winbin\minibench.bat -g group1 -cs //rac01-scan/test.rac -uc 200 -co localhost

При желании (если ваши тестовые инстансы БД расположены на разных физических хостах) можно повключать-повыключать их и посмотреть как это повлияет на производительность:
$ srvctl stop instance -d TEST -n rac-node02
$ srvctl status database -d TEST
Instance TEST1 is running on node rac-node01
Instance TEST2 is not running on node rac-node02
$ srvctl start instance -d TEST -n rac-node02
$ srvctl status database -d TEST
Instance TEST1 is running on node rac-node01
Instance TEST2 is running on node rac-node02

Можно посмотреть распределение клиентских сессий по узлам кластера:
SQL> select inst_id, count(*) from gv$session where username is not null group by inst_id;

В посте рассматривается краткий обзор среды разработки Oracle APEX, пошаговая инструкция установки и настройки APEX версии 20.2 и ORDS версии 20.3 на Oracle Database 18c Express Edition.

Краткий обзор среды разработки APEX.

Установка Oracle APEX 20.2. Предполагается, что есть успешно установленная Oracle Database 18c Express Edition. При необходимости, можно установить Oracle Database 18c Express Edition, используя следующие материалы: Установка Oracle Database 18c Express Edition на Linux и Установка Oracle Database 18c Express Edition на Windows. В посте подключение к PDB описываются различные способы подключения и работы в PDB.

Шаг 1. Установка APEX на Oracle Database 18c Express Edition

Для скачивания на портале Oracle необходимо наличие учетной записи с паролем. При ее отсутствии осуществляется регистрация новой учетной записи.

После ознакомления и принятия условий лицензирования необходимо поставить галочку в разделе I reviewed and accept the Oracle License Agreement.

Нажать на «Download apex_20_2.zip». Запускается скачивание zip архива (apex_20.2.zip). Объем архива 228 Мб.

После завершения скачивания архив apex_20.2.zip нужно скопировать в директорию /home/oracle/ операционной системы Oracle Linux, работающей на виртуальной машине. Выполняется разархивирование файла и проверка содержимого архива:

После разархивирования создалась папка apex с множеством sql скриптов для создания и настройки APEX. Необходимо из директории со скриптами (/home/oracle/apex/) подключиться к PDB XEPDB1 и начать установку APEX:

Подключение к XEPDB1 прошло успешно. Запускается скрипт apexins.sql для установки APEX со следующим синтаксисом:

@apexins.sql tablespace_apex tablespace_files tablespace_temp images

где, tablespace_apex – название табличного пространства для пользователя приложения APEX. tablespace_files – название табличного пространства для пользователя файлов APEX. tablespace_temp – название временного табличного пространства. images – виртуальная директория для изображений APEX. Для обеспечения корректного обновления APEX в будущем необходимо задать значение для этого параметра равное /i/.

Скрипт apexins.sql запускается со следующими значениями параметров:

Выше приводится последняя часть лога установки APEX, так как система генерирует очень много строк лога. Лог показывает, что установка прошла успешно и заняла 14 мин 57 секунд времени.

Шаг 2. Настройки и подключение к APEX

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

Для создания администратора и назначения ему пароля запускается скрипт apxchpwd.sql в PDB. Данный скрипт в будущем также может быть использован для сброса пароля существующему администратору APEX.

Иначе система выдаст следующую ошибку:

Запускается скрипт для создания администратора с именем ADMIN и назначения его email и пароля:

Пользователь успешно создан.

Также важно настроить учетную запись APEX_PUBLIC_USER для управления Oracle Application Express. Учетная запись APEX_PUBLIC_USER создается со случайным и недоступным паролем во время установки Oracle Application Express. Если же выполняется обновление (upgrade) с предыдущей версии Oracle Application Express, то приведенные ниже две команды не являются необходимыми:

Для новой установки APEX (а не обновление) необходимо запустить скрипт apex_rest_config.sql для настройки RESTful сервисов. После запуска потребуется назначить пароль для учетных записей APEX_LISTENER, APEX_REST_PUBLIC_USER. Ниже во время установки и настройки ORDS будет необходимо вводить пароли этих учетных записей.

Настройка ORDS

Пройдя по ссылке, скачивается файл Oracle REST Data Services.

Нажать на «Download ords-20.3.0.301.1819.zip». Запускается скачивание zip архива (ords-20.3.0.301.1819.zip). Объем архива 70 Мб.

После завершения скачивания необходимо создать директорию ords в /home/oracle/ и архив ords-20.3.0.301.1819.zip нужно скопировать в созданную директорию /home/oracle/ords операционной системы Oracle Linux, работающей на виртуальной машине. Выполняется разархивирование файла и проверка содержимого архива:

При использовании ORDS для работы с APEX приложениями ORDS должен быть настроен для обслуживания статических файлов APEX. Необходимо скопировать директорию images (apex/images) из домашней директории с установочными файлами APEX в папку файловой системы, где установлены службы Oracle REST Data Services. В данном примере домашняя директория APEX находится в /home/oracle/apex и директория установки ORDS в /home/oracle/ords.

Проверяется текущая версия JDK.

Результат команды показывает, что на этой операционной системе установлена и настроена 15-я версия JDK. В этом посте можно ознакомиться со способом проверки текущей версии JDK, а также при необходимости установить, обновить, настроить и использовать новую версию по умолчанию (см. раздел «Установка JDK»).

Есть вероятность, что при использовании старой версии JDK (например, 8 версия) запуск установки ORDS выдаст следующую ошибку:

Есть два варианта установки ORDS:

Автономный (standalone) режим.
На сервере приложений (Oracle WebLogic Server, Apache Tomcat).

Далее описывается установка ORDS в standalone режиме.

Для начала установки и настройки ORDS необходимо запустить следующую команду: java -jar ords.war install advanced

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

Для информации: по умолчанию, для того чтобы получить доступ к корню APEX через сервисы ORDS необходимо перейти по пути /ords. Если есть необходимость использовать путь /apex для доступа к APEX, то потребуется переименовать файл ords.war в apex.war перед началом установки и настройки ORDS.

После завершения установки автоматически создается рабочее пространство (workspace) для выполнения административных задач в APEX. Название workspace – INTERNAL. Выполняется подключение к административному workspace под пользователем ADMIN и его паролем (данный пользователь и его пароль были созданы при запуске скрипта apxchpwd.sql (см. выше)).

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

Далее задается название, идентификатор и описание рабочего пространства. В примере ниже задается имя рабочего пространства «Dushanbe» и краткое описание. По умолчанию система сама генерирует идентификатор рабочего пространства.

На этапе Identify Schema надо будет указать название схемы (пользователя базы данных), к которой будет привязано новое рабочее пространство. Если в поле Re-use existing schema выбран No, то в поле Schema Name необходимо указать название нового пользователя/схемы, в поле Schema Password задать ему пароль, а в поле Space Quota (MB) назначить ему квоту на использование пространства в табличном пространстве.

В примере для поля Re-use existing schema выбирается значение Yes и в Schema Name указывается тестовая и учебная схема/пользователь hr.

Это даст возможность использовать связанные таблицы с готовыми тестовыми данными, представления, триггеры, данные и другие объекты схемы hr во время создания приложений в APEX.

Это означает, что в APEX успешно создано новое рабочее пространство с именем Dushanbe. Нажатие кнопки Done позволит пользователю ADMIN получить доступ к своему рабочему пространству (INTERNAL) и начать работу:

Выполняется выход пользователя ADMIN из административного рабочего пространства (workspace) INTERNAL. Для этого в правом верхнем углу нажимается на имя пользователя и нажимается на Sign Out.

Нажимается на Return to Sign in Page и на новой странице указываются данные для подключения к новому рабочему пространству (workspace) Dushanbe:

При первом входе администратору нового рабочего пространства (workspace) необходимо самостоятельно сменить пароль:

После успешной смены пароля администратор workspace Dushanbe получает доступ к среде:

Рабочее пространство Dushanbe готово для начала разработки веб-приложений.

Необходимо учитывать, что после перезагрузки операционной системы сервис будет недоступен. Для запуска ORDS необходимо вручную запустить следующую команду java -jar ords.war standalone из директории ords (в данном примере из /home/oracle/ords):

Если закрыть консоль операционной системы, то сервис ords выполнявшийся в ней завершится. Во избежание этого необходимо команду java -jar ords.war standalone запустить в фоновом режиме, используя nohup:

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

16 thoughts on “ Установка и настройка APEX 20.2 и ORDS 20.3 на Oracle Database 18c Express Edition ”

при запуске java -jar ords.war .. на вводе пароля
Enter the administrator username:sys
Enter the database password for SYS AS SYSDBA:
валится с ошибкой 01017 неверно имя пользователя/пароль;
через sql plus коннект идет.. база pdb , ее указал
Enter the database service name:XEPDB1

пароль в разных регистрах пробовал, куда еще копать?

Уважаемый Владислав,
Спасибо за Ваш вопрос.

Здравствуйте!
Высылаю,но пароль число:

вопрос конечно относился больше субд чем к apex/ords, но как гипотеза, изменение SEC_CASE_SENSITIVE_LOGON в pluggable версиях (как минимум в 18xe) ведет к некорректной работе с паролями обычных пользователей.
с параметром по умолчанию (True) ords работает отлично.

Кстати, чтоб постоянно не писать alter session set container = XXX, возможно проше сразу подключатся к контейнерной базе, например conn sys/pass@localhost:1521/xepdb1

спасибо за интересные статьи!!
Огромная просьба написать о возможностях работы ords в режиме standalone с небольшим кол-вом пользователей и наиболее простым и устойчивым вариантом работы с веб-серверами, напр ords-tomcat; ords-glassfish-tomcat ;ords-nginx-tomcat..

с уважением
Владислав

Добрый день, Владислав.
Спасибо за Ваши вопросы и комментарии.

Добрый день!
Решил поизучать APEX на досуге, опыта работы с БД Oracle не имею. Интересует пока БД в связке с REST.
Ваши инструкции очень помогли.
Установил полную связку Oracle Linux, DB 18c XE, APEХ 20.2, ORDS 20.4
Все заработало.
Создал в APEX таблицу и наполнил данными, включил REST и тут началось:
1) Словил ошибку в браузере ORA-28000: The account is locked
2) Инет говорит, что какой то пользователь заблокирован (какой?)
3) Хорошо думаю зайду как sys as sysdba и посмотрю, но пароль не срабатывает, ошибка ORA-01017. Ни через sqlplus ни через sql developer
4) перезагрузка сервера не помогла, хотя до этого заходил sys as sysdba без проблем, вероятно на каком то этапе сменился пароль. APEX в тоже время работает отлично, кроме Реста.
Ума не приложу куда копать и как сменить пароль на sys. переустанавливать все как-то не хочется.

Могли бы третий пункт подробнее описать, пожалуйста? Каким образом выполняете подключение к БД под пользователем sys? Команда для подключения выполняется под пользователем операционной системы oracle?

Добрый вечер.
Рад, что Вам удалось решить пункты 2 и 3.

По поводу подключения с помощью команды sqlplus / as sysdba. Могли бы подробнее описать, пожалуйста? Каким образом выполняете подключение к БД без пароля? Команда для подключения выполняется под пользователем операционной системы (oracle)? Пользователь операционный системы (oracle) входит в группу dba операционной системы?

Добрый день.
По умолчанию standalone ORDS использует порт 8080. Ваша ошибка говорит о том, что порт 8080 уже занят каким-то другим сервисом или Вы возможно пытаетесь запустить standalone ORDS второй раз.

Для решения этой проблемы Вам необходимо найти файл standalone.properties в директории настроек ORDS. Если Ваши директории и настройки идентичны указанным в моем посте, то упомянутый файл находится в директории /home/oracle/ords/config/ords/standalone. В файле standalone.properties надо найти параметр jetty.port и изменить значение порта 8080 на новый номер порта (например, 8090).

does it really need to install java 15?

No, you do not need to use only JDK 15. Just in my example is used the pre-installed JDK 15.

I got this error when running my ORDS

WARNING The pool named: |apex|| is invalid and will be ignored: The username or password for the connection pool named |apex||, are invalid, expired, or the account is locked

Did I make anything wrong?

Seems one of the listed accounts (ords_public_user, apex_listener, apex_rest_public_user, apex_public_user) is locked or its password expired or someone changed its password.

1. If account is locked or password is expired then try unlock the account or just change the password back to the one that was set during the ORDS installation.

2. If you need to use new password then for this you need to find file with extension *.xml in the configuration folder of ORDS and set new password to the desired account using exclamation point. Exclamation point (!) will make the password unreadable after ORDS restart.

Читайте также: