Oracle Coldfailover 11.2

Материал из Xgu.ru

Перейти к: навигация, поиск

Oracle Coldfailover 11.2 на Oracle Linux 6

Содержание

[править] Введение

Данная статья является дополнением статьи об Oracle Coldfailover 11.1. В ней будет описан перевод работы СУБД Oracle 11.2 под контроль Oracle Clusterware. Начиная с 11.2.0.2 используемые в Oracle Clusterware 11.2 команды значительно изменились. Большая часть подготовки сервера описана в первой статье, в этой указаны только основные особенности при работе с Oracle Clusterware 11.2.

Использовались материалы:

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

В данном примере будет вестись описание установки Oracle Grid/Database 11.2.0.3 на Oracle Linux 6.3 x86-64. Следует заметить, что полная поддержка Oracle Linux 6 появилась у установщика Oracle Grid/Database c выпуска 11.2.0.3, поэтому желательно использовать последнюю версию с сайта support.oracle.com.

[править] Устанавливаем Oracle Linux 6 на сервер

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

# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-ol6.repo
# yum update

При установке ОТКЛЮЧИТЬ SELinux! Если пропустили, то после установки в файле /etc/sysconfig/selinux установить SELINUX=disabled или SELINUX=permissive.

[править] Настройка сети

В 11.2 появился новый способ настройки сети - Grid naming service (GNS). Использовать данную схему целесообразно при установке RAC на большое число узлов. Для Coldfailover, где всего 2-3 узла, данное решение излишне. Для работы GNS потребуется общественный статический адрес (SCAN - single client access name) и пул динамических виртуальных адресов. Для работы нужен DHCP сервер. При данном решении вы просто указываете у клиентов один единый ip адрес кластера (SCAN), а далее служба GNS осуществляет балансировку поключений к узлам кластера. Если вы добавляете или удаляете узел в кластер, то они автоматически регистрируются в GNS. Отпадает необходимость приписывать новые узлы в tnsnames.ora у клиентов.

Для работы Coldfailover проше использовать ручную настройку адресов. Потребуется три ip-адреса на каждый узел + один адрес scan для кластера (для coldfailover он не нужен, но иначе Oracle Grid не установиться). Нужно заранее выбрать имена узлов и прописать их в DNS или файле hosts на каждом узле. Кроме самого имени хоста нужно прописать имена с суффиксами -vip (Virtual IP) и -priv (private interconnect). Имена должны соответствовать RFC 952, подчеркивания не допускаются.

Итого потребуется:

  • общедоступный статический адрес на каждом узле (hosts, DNS)
  • виртуальный общедоступный статический адрес на каждом узле (hosts, DNS), на момент установки не должен использоваться (пинговаться)
  • статический SCAN адрес должен быть приписан в DNS, не может начинаться с цифры, должен быть в одн подсети, что и основной общедоступный адрес узлов
  • частный статический адрес, настроен до установки, в отдельной изолированной сети, имя должно разрешаться в ip только с узлов кластера

Пример настройки есть в документации по Grid 2.7.7 Manual IP Address Configuration Example (англ.)

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

Желательно настроить объединение сетевых карт сервера и подключить их в разные коммутаторы. Если сетевая связь между узлами кластера будет прервана (при замене коммутатора или отключении питания), то Oracle Grid посчитает, что возникли неисправности на узлах и перезагрузит их. Использование объединения карт позволит работать кластеру более надёжно.

[править] Пользователи и группы

На каждом из узлов пользователи от которых будут запускаться процессы СУБД и кластера должны иметь одинаковые имена, идентификаторы, принадлежность к группам путь к домашнему каталогу. Документация рекомендует использовать разделение ролей – процессы СУБД запускать от одного пользователя (oracle), а процессы кластера – от другого (grid). Итак необходимо создать следующие группы в ОС:

  • oinstall – её участники будут иметь доступ к Oracle Inventory (oraInventory). У всех пользователей, от которых будут запускаться процессы СУБД и кластера это должна быть основная группа.
  • dba – участники этой группы предоставляются административные права на управление СУБД. В БД это соответствует группе OSDBA, и привилегии SYSDBA. Данные пользователи способны подключаться к СУБД, используя локальную аутентификацию в операционной системе.
  • asmadmin – участники этой группы разрешено администрирование Oracle ASM: монтирование и размонтирование дисковых групп, добавление- удаление дисков. Группа OSASM, привилегия SYSASM.
  • oper – участники данной группы имеют ограниченный набор привилегий для работы с БД. Группа OSOPER, привилегия SYSOPER.
  • asmdba – участникам данной группы разрешено читать и записывать файлы на ASM диск.
  • asmoper – пользователи данной группы имеют ограниченный набор привилегий для работы с ASM – запуск и останов экземпляра ASM. Группа OSOPER for ASM. 
# groupadd -g 1100 oinstall
# groupadd -g 1110 dba
# groupadd -g 1120 oper
# groupadd -g 1130 asmadmin
# groupadd -g 1140 asmdba
# groupadd -g 1150 asmoper
# useradd -u 1100 -g oinstall -G dba,asmdba,asmadmin,oper -m oracle
# useradd -u 1110 -g oinstall -G dba,asmdba,asmadmin,asmoper -m grid
# passwd oracle
# passwd grid

В данном случае, оба пользователя (oracle и grid) будут иметь доступ к описанию установленного ПО Oracle. Кроме того, пользователи будут иметь административные права на работу с СУБД и права на запись и чтение с дисков ASM.

[править] Создание каталогов для установки

Документация рекомендует выбирать пути для установки ПО от Oracle в соответствии с Optimal Flexible Architecture (OFA). Согласно данными рекомендациям путь для установки продукта выбирается следующим образом /u[01-09]/app/<имя пользователя>.

Но ORACLE_HOME для Grid необходимо устанавливать по отдельному пути, так как после установки владельцем каталогов становиться root. По-умолчанию, выбирается путь /u01/app/11.2.0/grid.

Таким образом СУБД будем установить под пользователем oracle в /u01/app/oracle, а Oracle Grid под пользователем grid в /u01/app/grid, а Oracle Inventory в таком случае будет находиться в /u01/app/oraInvenory. Создаём каталоги /u01/app/oracle, /u01/app/grid, /u01/app/oraInventory. 

# mkdir -p /u01/app/grid			# GRID_BASE
# chown grid:oinstall /u01/app/grid
# chmod 755 /u01/app/grid

# mkdir -p  /u01/app/11.2.0/grid		# GRID_HOME
# chown grid:oinstall /u01/app/11.2.0/grid
# chmod 775 /u01/app/11.2.0/grid

# mkdir /u01/app/oracle			# ORACLE_BASE
# chown oracle:oinstall /u01/app/oracle
# chmod 755 /u01/app/oracle

# mkdir /u01/app/oraInventory		# Oracle Inventory
# chown grid:oinstall /u01/app/oraInventory
# chmod 770 /u01/app/oraInventory

[править] Установка ПО

Скачиваем c сайта support.oracle.com и распаковываем архивы: 

Oracle Database 11.2.0.3
  unzip p10404530_112030_Linux-x86-64_1of7.zip
  unzip p10404530_112030_Linux-x86-64_2of7.zip
Oracle Grid 11.2.0.3
  unzip p10404530_112030_Linux-x86-64_3of7.zip

[править] Установка пакетов с репозитария.

Для установки и работы СУБД на Oracle Linux 6 потребуются пакеты, которые можно просто установить командой: 

yum install \
make smartmontools oracleasm-support compat-libstdc++-33 elfutils elfutils-libelf-devel \
gcc gcc-c++ glibc-devel libstdc++-devel sysstat unixODBC unixODBC-devel ksh  glibc.i686 \
compat-libcap1.i686 compat-libcap1.x86_64 compat-libstdc++-33.i686 libaio.x86_64 \ 
libaio-devel.x86_64 libaio.i686 libaio-devel.i686 libgcc.i686 libstdc++.i686 unixODBC.i686 \
unixODBC-devel.i686 mksh.x86_64 libcap.i686 libcap-devel.i686 libcap-devel.i686 libcap-devel.x86_64

[править] Установка cvuqdisk

Так же потребуется пакет, который необходим для обнаружения общих (кластерных дисков) – cvuqdisk. Он находится в архиве с Grid в каталоге grid/rpm/cvuqdisk-1.0.9-1.rpm. Чтобы его установить, предварительно нужно экспортировать переменную окружения CVUQDISK_GRP и присвоить ей значение имени группы Oracle Inventory: 

# CVUQDISK_GRP=oinstall; export CVUQDISK_GRP 
# rpm -i grid/rpm/cvuqdisk-1.0.9-1.rpm

[править] Установка пакетов для работы с ASM

В 11.2 за работу экземпляра ASM отвечает Oracle Grid, а не Oracle Database. Поэтому сначала нужно установить Grid.

Для работы с файловой системой ASM потребуется установить пакеты:

  1. oracleasm-support – The Oracle Automatic Storage Management support programs – программы для создания, настройки и удаления файловой системы ASM на разделах (есть в открытом репозитарии)
  2. oracleasmlib – The Oracle Automatic Storage Management library userspace code. Упрощает работу с дисками ASM: позволяет обращаться из СУБД к дискам по меткам ORCL:<метка>, а так же позволяет избежать задание правил udev для установки прав на разделы диска ASM. Возможно настроить работу и без данной библиотеки. Скачать пакет можно с сайта Oracle http://www.oracle.com/technetwork/server-storage/linux/asmlib/ol6-1709075.html

Примечание: обнаружилось, что при использовании oracleasmlib, ядра UEK2 и системы хранения данных Dell Compellent, при попытке смонтировать диски, экземпляр ASM почему-то аварийно завершает работу :) Если использовать ядро RedHat или другую СХД или отключить использование asmlib, то всё запускается нормально.

[править] Настройка кластерных дисков

Для работы Grid потребуется как минимум один общий ASM диск, размером не менее 3 Гб. И реестр кластера и voting disk теперь располагаются на ASM. Возможно указать варианты избыточности: внешняя и нормальная. При выборе внешней избыточности считается, что администратор сам позаботился о резервировании кластерных дисков (RAID, DRBD и т. п.).

Владелец диска должен быть пользователь grid, группа asmadmin, права 660. В примере ниже, для OCR будет создан диск ASM c меткой GRID.

Если используется oracleasmlib, то задавать права доступа к дискам ASM в правилах udev не требуется.

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

# oracleasm configure -i

автозапуск — да, владелец — grid, группа — asmadmin.

Настройки службы хранятся в файле /etc/sysconfig/oracleasm. Если используется multipath, то его необходимо отредактировать, указав сканировать только многопутевые устройства: 

ORACLEASM_SCANORDER="dm"
ORACLEASM_SCANEXCLUDE="sd"

В противном случае ORACLEASM_SCANORDER, ORACLEASM_SCANEXCLUDE можно оставить пустыми.

Пример: 

# ORACLEASM_ENABELED: 'true' means to load the driver on boot.
ORACLEASM_ENABLED=true
# ORACLEASM_UID: Default user owning the /dev/oracleasm mount point.
ORACLEASM_UID=grid
# ORACLEASM_GID: Default group owning the /dev/oracleasm mount point.
ORACLEASM_GID=asmadmin
# ORACLEASM_SCANBOOT: 'true' means scan for ASM disks on boot.
ORACLEASM_SCANBOOT=true
# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE="sd"

После настройки службы можно приступать к созданию дисков ASM. На одном из узлов запускаем команду: 

# oracleasm createdisk <МЕТКА> <путь>, где <МЕТКА> должна начинаться с заглавной буквы.
# oracleasm createdisk GRID /dem/mapper/gridp1

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

# oracleasm scandisks
Reloading disk partitions: done
Cleaning any stale ASM disks...
Scanning system for ASM disks...
# oracleasm listdisks
GRID

[править] Задание правил udev для кластерных дисков ASM

Так как в 11.2 всё размещается на ASM, то достаточно написать правило, чтобы для всех дисков ASM выставлялись необходимые права доступа. Тип ФС определяется с помощью программы blkid (см. man).

В Oracle Linux 6 для тестирование правил udev, можно использовать: 

udevadm test /block/sdb

[править] Вариант без использования multipath 

# vim /etc/udev/rules.d/80-asm.rules
KERNEL=="sd[b-z][1-9]", PROGRAM=="/sbin/blkid -s TYPE -o value /dev/%k", RESULT=="oracleasm", OWNER="grid", GROUP="asmadmin", MODE=660

[править] Вариант c multipath

Настройка multipath описана в главе 3 руководства Red Hat Enterprise Linux 6 по конфигурации и администрированию DM Multipath (рус.)

Если диск ASM подключен как multipath и oracleasmlib не используется, то нужно задавать следующее правило: 

# vim /etc/udev/rules.d/80-asm.rules
KERNEL=="dm-*", PROGRAM=="/sbin/blkid -s TYPE -o value /dev/%k", RESULT=="oracleasm", OWNER="grid", GROUP="asmadmin", MODE=660

После необходимо службе oracleasm указать путь поиска дисков только среди multipath устройств.

В файле /etc/sysconfig/oracleasm необходимо указать: 

...
ORACLEASM_SCANORDER="dm"
ORACLEASM_SCANEXCLUDE="sd"

А так же экземпляру ASM в файле инициализации (см. «Настройка экземпляра ASM и создание дисковых групп» ) указать параметр: 

 asm_diskstring=/dev/mapper/*'

Если разделы с ASM находятся на первом разделе дисков, то можно asm_diskstring=/dev/mapper/*p1'.

Следует учесть, что при перезагрузках имена (/dev/dm-N) могут меняться, поэтому при добавлении дисков в дисковую группу ASM необходимо указывать символические ссылки из каталога /dev/mapper.

[править] Настройка службы синхронизации времени

В 11.2 появилась возможность использовать собственную службу синхронизации времени - Oracle Cluster Time Synchorization Service (CTSSD). Для её установки необходимо отключить службу NTP: 

# chkconfig ntpd off
# mv /etc/ntp.conf /etc/ntp.conf.orig

Настройку ctssd произведёт установщик.

Если всё же необходимо использовать синхронизацию с внешними источниками точного времени, то для работы Oracle Grid необходимо настроить запуск службы NTP с опцией -x (см. man ntpd). Для этого в файле /etc/sysconfig/ntp указать 

OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"

Перезапустить службу ntp. Служба CTSSD в таком случае установлена не будет.

[править] Настройка SSH для входа по ключам

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

Можно использовать описанную для 11.1 методику, либо воспользоваться средствами Oracle Installer при установке Oracle Grid (SSH connectivity).

[править] Настройка лимита ресурсов и переменных оболочки

[править] Лимиты ресурсов

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

Для этого сначала в файл /etc/pam.d/login необходимо добавить строку: 

session required pam_limits.so

Затем в файле /etc/security/limits.conf здать лимиты для количества процессов пользователя (nproc), для количества открытых файлов (nofile), максимальный размер стека (stack): 

grid soft nproc   2047
grid hard nproc   16384
grid soft nofile  1024
grid hard nofile  65536
grid soft stack   10240
 
oracle soft nproc   2047
oracle hard nproc   16384
oracle soft nofile  1024
oracle hard nofile  65536
oracle soft stack   10240

[править] Переменные окружения

После установки максимальных значений лимитов необходимо их назначить пользователю. Можно в файле "/etc/profile" добавить блок: 

if [ $USER = "oracle" ] || [ $USER = "grid" ]; then
	if [ $SHELL = "/bin/ksh" ]; then
		ulimit -p 16384
		ulimit -n 65536
	else
	ulimit -u 16384 -n 65536
	fi
umask 022
fi

или же если используется bash, то в файле /home/oracle/.bashrc добавить строку: 

ulimit -u 16384 -n 65536

При установке Grid инсталятор выполняет команды SSH и копирует файлы на другие узлы. В течении установки, скрытые файлы (.bashrc или .cshrc) могут вызвать ошибки выполнения makefile если они содержат команды stty. Чтобы избежать ошибок необходимо подавить все выводы на STDERR, прописав в .bashrc: 

if [ -t 0 ]; then
        stty intr ^C
fi

[править] Настройка параметров ядра

Так же потребуется изменение параметров ядра Linux. В документации по установке указаны все параметры, здесь же приведены только те, которые пришлось изменять.

Файл /etc/sysctl.conf: 

kernel.shmall = 4294967296
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
net.ipv4.ip_local_port_range = 9000 65500
fs.file-max = 6815744
fs.aio-max-nr = 1048576
vm.hugetlb_shm_group = 1100

Параметру vm.hugetlb_shm_group должно быть присвоено значение id групы oinstall.

Если будут производится расчёты, которые потребуют более 4 Гб памяти PGA для одной сессии, то необходимо увеличить максимальное количество используемых страниц памяти процессом vm.max_map_count со стандартного значение 65530 на большее значение. Более подробно это указано на сайте поддержки в документе FAQ: ORA-4030 [ID 399497.1] в разделе «4G Memory limitation in memory mapped systems using realfree allocator».

[править] Настройка shared memory и hugepages

[править] Shared memory

Настройка приведена в Shared memory для 11.1. На Oracle Linux 6.3 по невыясненной причине при загрузке не учитывается параметр размера, однако, если монтировать вручную, то размер учитывается. Поэтому пришлось в /etc/rc.local дописать команду на перемонтирование 

mount -o remount /dev/shm

[править] Hugepages

Настраивается аналогично как и в Hugepages для 11.1, но с ядром UEK2 в /etc/security/limits.conf нет необходимости указывать memlock (max locked memory).

[править] Установка Oracle Grid и запуск экземпляра ASM

Самый простой способ использовать графический установщик. Чаще всего на сервере не запущен X window, поэтому можно подключиться к нему по SSH с X11 forwarding (или использовать Putty и Xming при подключении с MS Windows) и производить установку удалённо. Для этого необходимо, чтобы на сервере был установлен пакет xorg-x11-xauth.

Логонимся под пользователем grid, переходим в каталог с распакованным Oracle grid и запускаем ./runInstaller.

Если у пользователя нет прав на запись в каталог с дистрибутивом grid, то нужно перейти в каталог, где права на запись есть и запускать, используя полный путь: 

[grid@grid1 ~] $ cd ~
[grid@grid1 ~] $ /media/cdrom/grid/runInstaller

Далее выполняем шаги установщика:

  1. Скачивание обновлений.
  2. Варианты установки - "Install and Configure Oracle Grid Infrastructure for a Cluster"
  3. Варианты установки - Advanced Installation
  4. Выбор языков
  5. Настройка кластерного ip адреса. Для расматриваемого случая, легче использовать ручную настройку, для этого нужно снять галочку у "Configure GNS". Доменное имя, указанное в SCAN Name, должно разрешатся в ip-адрес (прописано в dns или в hosts на всех узлах кластера).
  6. Добавляем узлы. Здесь же с помощью «SSH Connectivity...» можно настроить вход по ключам. Виртуальные адреса (...-vip), так же должны разрешатся в ip.
  7. Выбор сетевых интерфейсов для общедоступной и внутрикластерной сети. Имена интерфейсов на всех узлах должны совпадать.
  8. Размещение реестра кластера — Automatic Storage Managment (ASM)
  9. Указываем имя дисковой группы для размещения реестра кластера. Ранее в разделе «Настройка кластерных дисков» было описано создание ASM диска и меткой GRID. Выбираем тип избыточности. И созданный ранее диск. Если в поле выбора дисков пусто, то измените путь поиска - «Change Discovery Path». При отсутствии asmlib, по-умолчанию, там стоит /dev/raw/*. Имена дисков на разных узлах должны совпадать.
    • В случае использования Oracle ASMlib путь (Discovery Path) должен быть — ORCL:*
    • Если используется multipath, asmlib не используется - /dev/mapper/*p1 (если ASM находится на первом разделе дисков)
    • Если ни asmlib, ни multipath не используются - /dev/sd*
  10. Указываем пароль администратора экземпляра ASM.
  11. Настройка IPMI (я не использовал)
  12. Выбор привилегированных групп пользователей ОС для работы с экземпляром ASM — asmdba, asmoper, asmadmin.
  13. Выбор путей ORACLE_BASE (по-умолчанию - /u01/app/grid) и ORACLE_HOME (/u01/app/11.2.0/grid) для Oracle Grid. Выбрать можно произвольно. Важно, чтобы пути ORACLE_HOME для пользователя grid отличался от пути пользователя oracle.
  14. Путь к Oracle Inventory
  15. Проверка узлов на требования к установке. Если выдаётся ошибка о проверки доступности узлов отключите iptables. Если dns настроен верно (выполняется успешно nslookup grid1 и т.п.), то ошибку PRVF-5637 о том, что не удаётся проверить имена узлов с помощью nslookup можно игнорировать.
  16. Сводка по установке и установка
  17. Запуск скриптов от root, которые создадут OCR и настроят службы кластера может длиться достаточно долго.

[править] Создание отказоустойчивой БД Oracle

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

[править] Установка СУБД Oracle

Входим на сервер как пользователь oracle. Переходим в каталог, где распакован архив с СУБД 11.2

Запускаем графический установщик: 

[ oracle@grid1 ~] $ ./database/runInstaller.
  1. Варианты установки нужно выбрать «Install Software Only» и после создать базу через dbca/ sqlplus. Можно сразу создать БД "Create and configure database". Но следует учесть, что сама БД должна быть "Single instance database installation"
  2. Устанавливаем ПО для варианта Real Application Clusters на оба узла - в данном случае установщик сам скопирует необходимый файлы на другой узел. Предварительно нужно установить доступность узлов через SSH - «SSH Connectivity...»
  3. Выбираем языки, тип установки Enterprise или Standard.
  4. Задаём пути: Oracle Base: /u01/app/oracle, тогда Oracle home (OraDb11g_home1) примет значение: /u01/app/oracle/product/11.2.0/dbhome_1
  5. Запуститься проверка параметров ОС аналогичная, что и при установке Grid.
  6. Задание соответствия групп ОС и БД: OSDBA, OSOPER, OSASM. Подробнее см. «Пользователи и группы»
  7. Вывод итоговой сводки и установка на узлы.
  8. Запуск скриптов /u01/app/oracle/product/11.2.0/dbhome_1/root.sh на обоих узлах.

После завершения установки ПО, желательно у пользователя oracle задать в .bashrc переменные ORACLE_BASE, ORACLE_HOME. Включить путь $ORACLE_HOME/bin и $ORACLE_HOME/OPatch в переменную $PATH, а путь $ORACLE_HOME/lib в переменную LD_LIBRARY_PATH. 

ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1; export ORACLE_HOME
PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH; export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH

После того как установили ПО СУБД, создаём саму БД с помощью dbca (если она не была создана ранее). Создание стандартное. Единственная особенность нужно указать создание "Single instance database installation" и разместить файлы на ASM. В примере ниже БД будет APLHA.

[править] Подготовка резервного узла

На резервном узле необходимо:

  • Создать файл с паролем SYS: 
[ oracle@grid2 ~] $ cd $ORACLE_HOME/dbs
[ oracle@grid2 ~] $ orapwd file=orapwalpha
  • Создать/перенести spfile. И при необходимости скорректировать настройки СУБД под возможности резервного узла. 
[oracle@grid1~] $ scp $ORACLE_HOME/dbs/spfilealpha grid2:$ORACLE_HOME/dbs
  • Создать каталог для хранения файлов аудита, что указан в параметре СУБД audit_file_dest. 
[ oracle@grid2 ~] $ mkdir /u01/app/oracle/admin/alpha/adump
  • Скопировать описание tns-имен 
[oracle@grid1~] $ scp $ORACLE_HOME/network/admin/tnsnames.ora grid2:$ORACLE_HOME/network/admin
  • В файл /etc/oratab добавить запись о созданной БД: 
alpha:/u01/app/oracle/product/11.2.0/dbhome_1:N

[править] Установка обновлений

После установки Oracle Grid и Oracle Database установите последние обновления на каждом узле.

Скачиваем и распаковываем последний OPatch в GRID_HOME (/u01/app/11.2.0/grid) и в ORACLE_HOME (/u01/app/oracle/product/11.2.0/dbhome_1)

Скачиваем последний набор патчей. Распаковываем их от пользователя grid или oracle.

Например, для январского PSU 2013 г.: 

[grid@grid1 ~] $ cd /tmp/patches
[grid@grid1 tmp] $ unzip p14727347_112030_Linux-x86-64.zip

Проверьте, что права доступа на распакованные файлы позволяют читать их пользователям grid и oracle. После установки Oracle Grid и Oracle Database уставливаем патч от root для GRID_HOME и ORACLE_HOME: 

# /u01/app/11.2.0/grid/OPatch/opatch auto /tmp/patches/ -oh /u01/app/11.2.0/grid/ -ocmrf /tmp/patches/bundle.xml
# /u01/app/11.2.0/grid/OPatch/opatch auto /tmp/patches/ -oh /u01/app/oracle/product/11.2.0/dbhome_1 -ocmrf /tmp/patches/bundle.xml

Для корректной установки патчей необходима запись о базах данных в /etc/oratab. Например: 

...
alpha:/u01/app/oracle/product/11.2.0/dbhome_1:N

[править] Создание ресурсов, обслуживающих СУБД

Прослушиватель и ASM запускает Oracle Grid, поэтому можно сразу приступить к созданию БД.

[править] Создание дисковых групп ASM для данных СУБД

Создать дисковые группы ASM можно с помощью sqlplus или графического мастера asmca.

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

В случае использования sqlplus нужно зайти на сервер под пользователем grid и подключиться к экземпляру ASM с привилегией sysasm.

Например для первого узла: 

[grid@grid1 ~] $ export ORACLE_SID=+ASM1
[grid@grid1 ~] $ sqlplus / as sysasm

Описание команд для создания дисковых групп приведено в приложении для версии 11.1

[править] Задание контроля за работой СУБД

После того как БД создана (dbca), необходимо перевести её под контроль Oracle Grid. Для этого необходимо создать профили группы ресурсов, работу которых Oracle Grid будет отслеживать и перезапускать при необходимости.

Описание команд приведено в разделах документа Oracle® Clusterware Administration and Deployment Guide 11g Release 2:

Для работы ресурсов необходимо скопировать скрипты act_db .pl, act_listener.pl и act_resgroup.pl из каталога $GRID_HOME/crs/demo/coldfailover (/u01/app/11.2.0/grid/crs/demo/coldfailover) в каталог $GRID_HOME/crs/public (/u01/app/11.2.0/grid/crs/public) и выставить права на выполнение данным скриптам. Скопировать скрипты нужно на каждом узле. 

[grid@grid1 ~] $ cp /u01/app/11.2.0/grid/crs/demo/coldfailover/*.pl /u01/app/11.2.0/grid/crs/public/
[grid@grid1 ~] $ chmod +x /u01/app/11.2.0/grid/crs/public/*.pl

Аналогично скопируйте скрипты на резервном узле.

После можно приступать к созданию и регистрации профилей.

Начиная с версии 11.2.0.2 все задачи по управлению ресурсами выполняются с помощью crsctl. Старые утилиты crs_profile, crs_stat, crs_start и т. п. оставлены только для совместимости. Использовать их в случае новой установки не удастся.

Основные команды:

  • crsctl add type <...> -type <...> -args|-file <...> – создание типа (шаблона)
  • crsctl add res <...> -type <...> -args|-file <...> – создание ресурса
  • crsctl stat res [<имя>] [-t] [-p] – статус ресурсов; с ключом -t покажет в табличном виде; если указать имя ресурса, то выведет информацию только по указанному ресурсу; если указать —p – то выведет статическую информацию (используемые атрибуты)
  • crsctl start res <имя> – запуск ресурса
  • crsctl stop res <имя> [-f] – останов ресурса, с -f остановить зависящие службы
  • crsctl relocate res <имя> -f – миграция ресурса ( а так же зависимостей) на другой узел.
  • crsctl del res <...> - удалить ресурс

Параметры можно сокращать, например, вместо resource писать просто res, status - stat и т.д.

У каждого ресурса есть атрибуты. Посмотреть полное описание ресурса можно командой: 

crsctl stat res <имя> -p

Для нас важными атрибутами являются:

  • ACTIVE_PLACEMENT=0 - отключает динамическое перемещение ресурсов при появлении менее нагруженного узла. В противном случае после перезагрузки резервного узла, часть ресурсов переместиться на него. Нам же нужно, чтобы СУБД запускалась на резервном узле только в случае полного отказа основного узла.
  • PLACEMENT=restricted - указывает принудительно размещаться только на указанных узлах
  • HOSTING_MEMBERS=grid1 grid2 - список узлов, на которых могут размещаться ресурсы
  • AUTO_START=always - включает принудительный запуск ресурсов после перезагрузки сервера. Если вам нужно восстанавливать предыдущее состояние, то укажите AUTO_START=restore.

[править] Создание начального ресурса

Для выполнения зависимостей создаём ресурс rg1. Создаём файл с атрибутами rg1.cap. Тип указываем ora.cluster_resource.type, аттрибуты читаем из файла rg1.cap. Ресурс будет при старте размещаться на узле grid1, при сбое - на grid2. 

[grid@grid1 ~] $ crsctl add resource rg1 -type ora.cluster_resource.type -file rg1.cap

где файл-описание rg1.cap ресурса содержит следующее: 

ACTION_SCRIPT=/u01/app/11.2.0/grid/crs/public/act_resgroup.pl
ACTIVE_PLACEMENT=0
PLACEMENT=restricted
HOSTING_MEMBERS=grid1 grid2
AUTO_START=always
ACL=owner:grid:rwx,pgrp:oinstall:rwx,other::r--
RESTART_ATTEMPTS=1
CHECK_INTERVAL=600
START_TIMEOUT=30
STOP_TIMEOUT=30

[править] Создание ресурса виртуального сетевого адреса

Создаём ресурс, который будет запускать виртуальный сетевой ip-адрес. За основу взяты действия команды appvipcfg (см. Creating an Application VIP Managed by Oracle Clusterware ).

Данный ресурс оказался самым проблемным - сложно было подобрать атрибуты ресурса, для нормальной работы. Если у вас не получиться его настроить изучайте действия appvipcfg. Возможно придётся указать другие атрибуты ресурса.

Если запустить appvipcfg, то создастся тип ресурса app.appvip_net1.type и сам ресурс виртуального ip. 

[root@grid1 ~] # /u01/app/11.2.0/grid/bin/appvipcfg create -network=1 -ip=127.1.2.3 -vipname=testip -user=grid

Посмотреть его описание можно командой: 

[grid@grid1 ~] $ crsctl stat type app.appvip_net1.type -p

Нам нужен только тип для работы виртуального ip-адреса. Сам созданный интерфейс можно удалить. Если удалить виртуальный ip с помощью appvipcfg delete ..., то так же удалиться и тип. Поэтому удаляем ресурс с помощью команды: 

[root@grid1 ~] # /u01/app/11.2.0/grid/bin/crsctl delete res testip

Я пытался создать собственный тип по описанию app.appvip_net1.type, но с ним возникли сложности в работе - возникали проблемы с миграцией. На одном узле интерфейс запускался, на другом нет.

Создаём файл с атрибутами ресурса rg1.appvip.cap: 

USR_ORA_VIP=172.16.70.15
START_DEPENDENCIES=hard(rg1,ora.net1.network) pullup(rg1)
STOP_DEPENDENCIES=hard(rg1)
ACTIVE_PLACEMENT=0
PLACEMENT=restricted
HOSTING_MEMBERS=grid1 grid2
AUTO_START=always
ACL=owner:root:rwx,pgrp:root:r-x,other::r--,user:grid:r-x
RESTART_ATTEMPTS=1
START_TIMEOUT=30
STOP_TIMEOUT=30

В зависимостях почему-то, кроме начального ресурса rg1, необходимо указывать ora.net1.network, так же указывать pullup зависимость. Без них запустить виртуальный интерфейс не получилось.

Здесь USR_ORA_VIP=172.16.70.15 — адрес создаваемого виртуального ip-адреса.

Регистрируем ресурс от root:

  • создаём ресурс 
[root@grid1 ~] # /u01/app/11.2.0/grid/bin/crsctl add resource rg1.appvip -type app.appvip_net1.type -file rg1.appvip.cap
  • устанавливаем права на запуск пользователю grid. 
[root@grid1 ~] # /u01/app/11.2.0/grid/bin/crsctl setperm res rg1.appvip -o root
[root@grid1 ~] # /u01/app/11.2.0/grid/bin/crsctl setperm res rg1.appvip -u user:grid:r-x

Пробуем запустить: 

[grid@grid1 ~] $ crsctl start res rg1.appvip

И проверить появился ли новый ip-адрес на публичном интерфейсе.

В случае если интерфейс не запускается, смотрите журнал запуска агентов от root на наличие ошибок: 

/u01/app/11.2.0/grid/log/grid1/agent/crsd/orarootagent_root/orarootagent_root.log

grid1 — имя узла, где запускаете ресурс виртуального ip-адреса.

Пробуем выполнить миграцию группы ресурсов: 

[grid@grid1 ~] $ crsctl relocate res rg1 -f

Ресурсы rg1 и rg1.appvip должны запуститься на резервном узле. Проверьте ip-адреса на нем. 

[grid@grid2 ~] $ ip a

[править] Создание ресурса прослушивателя

Предварительно нужно на каждом узле в listener.ora прописать новый прослушиватель.

Так как прослушиватель запускает Oracle Grid, необходимо редактировать файл в $GRID_HOME/network/admin/listener.ora (по-умолчанию, /u01/app/11.2.0/grid/network/admin/listener.ora)

Добавляем прослушиватель для ресурса: 

LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))) 
LISTENER_SCAN1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))) 
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN1=ON
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON

LSNR_RG1 =(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.70.15)(PORT = 1521)(IP = FIRST)))

Здесь HOST = 172.16.70.15 — виртуальный ip-адрес, созданные ранее.

Данный ресурс будет запускать скрипт act_listener.pl, который уже будет запускать прослушиватель. Данному скрипту для работы нужны переменные окружения USR_ORA_LANG — ORACLE_HOME, где искать файл listener.ora (в нашел случае это GRID HOME=/u01/app/11.2.0/grid), и USR_ORA_SRV — имя прослушивателя.

Так как шаблона (тип ресурса), с необходимыми атрибутами (переменными окружения) я не нашёл, то создал свой тип rg.lsnr.type, с основой ora.cluster_resource.type.

Создаём тип (шаблон) ресурса 

[grid@grid1 ~] $ crsctl add type rg.lsnr.type -basetype ora.cluster_resource.type -file rg.lsnr.type.cap

Файл-описание rg.lsnr.type.cap : 

ATTRIBUTE=ACTION_SCRIPT
TYPE=STRING
DEFAULT_VALUE=/u01/app/11.2.0/grid/crs/public/act_listener.pl
ATTRIBUTE=USR_ORA_LANG
TYPE=STRING
DEFAULT_VALUE=/u01/app/11.2.0/grid
ATTRIBUTE=USR_ORA_SRV
TYPE=STRING
DEFAULT_VALUE=LISTENER
ATTRIBUTE=RESTART_ATTEMPTS
DEFAULT_VALUE=1
TYPE=INT
ATTRIBUTE=CHECK_INTERVAL
DEFAULT_VALUE=1
TYPE=INT
ATTRIBUTE=START_TIMEOUT
DEFAULT_VALUE=30
TYPE=INT
ATTRIBUTE=STOP_TIMEOUT
DEFAULT_VALUE=30
TYPE=INT
ATTRIBUTE=AUTO_START
DEFAULT_VALUE=always
TYPE=STRING

Регистрируем ресурс: 

[grid@grid1 ~] $ сrsctl add resource rg1.lsnr -type rg.lsnr.type -file rg1.lsnr.cap

Файл-описание ресурса rg1.lsnr.cap: 

USR_ORA_LANG=/u01/app/11.2.0/grid
USR_ORA_SRV=LSNR_RG1
START_DEPENDENCIES=hard(rg1,rg1.appvip)pullup(rg1,rg1.appvip)
STOP_DEPENDENCIES=hard(rg1,rg1.appvip)
ACTIVE_PLACEMENT=0
PLACEMENT=restricted
HOSTING_MEMBERS=grid1 grid2
AUTO_START=always
ACL=owner:grid:rwx,pgrp:oinstall:rwx,other::r--
RESTART_ATTEMPTS=5
CHECK_INTERVAL=20
START_TIMEOUT=120
STOP_TIMEOUT=120

Зависимости: начальный ресурс, ресурс виртуально ip-адреса.

Пробуем запустить прослушиватель: 

[grid@grid1 ~] $ crsctl start res rg1.lsnr

Смотрим статус: 

[grid@grid1 ~] $ lsnrctl status LSNR_RG1
LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 04-FEB-2013 15:46:30
.................................
Listener Parameter File   /u01/app/11.2.0/grid/network/admin/listener.ora
Listener Log File         /u01/app/11.2.0/grid/log/diag/tnslsnr/grid1/lsnr_rg1/alert/log.xml
Listening Endpoints Summary...
 (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=172.16.70.15)(PORT=1521)))
The listener supports no services
The command completed successfully

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

/u01/app/11.2.0/grid/log/grid1/agent/crsd/scriptagent_grid/scriptagent_grid.log

grid1 — имя узла, где запускаете ресурс прослушивателя.

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

  • экспортируем переменные 
[grid@grid1 ~] $ export _USR_ORA_LANG=/u01/app/11.2.0/grid
[grid@grid1 ~] $ export _USR_ORA_SRV=LSNR_RG1
  • и запускаем скрипт: 
[grid@grid1 ~] $ /u01/app/11.2.0/grid/crs/public/act_listener.pl start

Смотрим выводимые сообщения.

После остановите прослушиватель: 

[grid@grid1 ~] $ /u01/app/11.2.0/grid/crs/public/act_listener.pl stop

Пробуем выполнить миграцию группы ресурсов: 

[grid@grid1 ~] $ crsctl relocate res rg1 -f

Ресурсы rg1, rg1.appvip, rg1.lsnr должны запуститься на резервном узле. Проверьте статус прослушивателя на резервном узле: 

[grid@grid2 ~] $ lsnrctl status LSNR_RG1

[править] Создание ресурса, контролирующего состояние базы данных

Запускать СУБД будет скрипт act_db.pl. Данному скрипту для работы нужны переменные окружения:

  • USR_ORA_LANG — ORACLE_HOME
  • USR_ORA_SRV — ORACLE_SID СУБД
  • USR_ORA_FLAGS — 1 если БД располагается на ASM, 0 — если на обычной файловой системе.

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

sh: line 11: warning: here-document at line 7 delimited by end-of-file (wanted `EOF')

Как выяснилось из-за наличия пробелов в передаваемом блоке параметров sqlplus.

Первый вариант - просто убрать пробелы перед EOF в начале 64 и 82 строкок.

Второй вариант.

Переходим к строке 60, заменяем <<EOF на <<-EOF, а так же в строке 64 перед «EOF» заменяем пробелы в начале строки на табуляцию: 

$ORACLE_HOME/bin/sqlplus /nolog <<-EOF
        connect / as sysdba
        startup force
        quit
<------>EOF" )

Аналогично со строки 78: 

      $ORACLE_HOME/bin/sqlplus /nolog <<-EOF
        connect / as sysdba
        shutdown immediate
        quit
<------>EOF" )

Символ — перед завершающим блоком EOF указывает пропускать все начальные пробелы ( https://forums.oracle.com/forums/message.jspa?messageID=4323389)

Регистрируем тип для СУБД 

[grid@grid1 ~] $ crsctl add type rg.rdbms.type -basetype ora.cluster_resource.type -file rg.rdbms.type.cap

где файл-описание rg.rdbms.type.cap типа содержит следующее: 

ATTRIBUTE=ACTION_SCRIPT
TYPE=STRING
DEFAULT_VALUE=/u01/app/11.2.0/grid/crs/public/act_db.pl
ATTRIBUTE=USR_ORA_LANG
TYPE=STRING
DEFAULT_VALUE=/u01/app/oracle/product/11.2.0/dbhome_1
ATTRIBUTE=USR_ORA_SRV
TYPE=STRING
DEFAULT_VALUE=ORCL
ATTRIBUTE=USR_ORA_FLAGS
TYPE=INT
DEFAULT_VALUE=1
ATTRIBUTE=RESTART_ATTEMPTS
DEFAULT_VALUE=1
TYPE=INT
ATTRIBUTE=CHECK_INTERVAL
DEFAULT_VALUE=1
TYPE=INT
ATTRIBUTE=START_TIMEOUT
DEFAULT_VALUE=30
TYPE=INT
ATTRIBUTE=STOP_TIMEOUT
DEFAULT_VALUE=30 
TYPE=INT
ATTRIBUTE=AUTO_START
DEFAULT_VALUE=always
TYPE=STRING

При создании дисковой группы ASM, она так же регистрируется как ресурс Oracle Clusterware с именем ora.<ИМЯ ГРУППЫ>.dg. Желательно указать её в зависимостях при запуске СУБД. Из создаваемых нами ресурсов в зависимостях указан только головной ресурс, чтобы Clusterware не перезапускала СУБД при сбоях прослушивателя.

В примере ниже, для СУБД с ORACLE SID = alpha, создана дисковая группа ALPHA для хранения файлов базы данных, и дисковая группа RECOVERY1 для размещения Fast/Flash Recovery Area.

Регистрируем ресурс для СУБД: 

[grid@grid1 ~] $ crsctl add res rg1.rdbms -type rg.rdbms.type -file rg1.rdbms.cap

где файл-описание rg1.rdbms.cap ресурса содержит следующее: 

USR_ORA_LANG=/u01/app/oracle/product/11.2.0/dbhome_1
USR_ORA_SRV=alpha
USR_ORA_FLAGS=1
START_DEPENDENCIES=hard(rg1,ora.ALPHA.dg,ora.RECOVERY1.dg)
STOP_DEPENDENCIES=hard(rg1)
ACTIVE_PLACEMENT=0
PLACEMENT=restricted
HOSTING_MEMBERS=grid1 grid2
AUTO_START=always
ACL=owner:grid:rwx,pgrp:oinstall:rwx,other::r--
RESTART_ATTEMPTS=5
CHECK_INTERVAL=20
START_TIMEOUT=600
STOP_TIMEOUT=600

Пробуем запустить ресурс: 

[grid@grid1 ~] $ crsctl start res rg1.rdbms

Если не удалось запустить, смотрите ошибки в 

/01/app/11.2.0/grid/log/grid1/agent/crsd/scriptagent_grid/scriptagent_grid.log

Так же выполните ручной запуск скрипта:

  • экспортируем переменные 
[grid@grid1 ~] $ export _USR_ORA_LANG=/u01/app/oracle/product/11.2.0/dbhome_1
[grid@grid1 ~] $ export _USR_ORA_SRV=ALPHA
[grid@grid1 ~] $ export _USR_ORA_FLAGS=1		# 1 если БД на ASM
  • и запускаем скрипт: 
[grid@grid1 ~] $ /u01/app/11.2.0/grid/crs/public/act_db.pl start

После того как удалось запустить СУБД через Clusterware, нужно настроить, чтобы СУБД регистрировалась на созданном нами кластером прослушивателе — LSNR_RG1. Для этого подключаемся к СУБД и изменяем параметр LOCAL_LISTENER: 

[oracle@grid1 ~] $ export ORACLE_SID=alpha
[oracle@grid1 ~] $ sqlplus / as sysdba
SQL> alter system set LOCAL_LISTENER='(ADDRESS = (PROTOCOL=TCP)(HOST=172.16.70.15)(PORT=1521))' SCOPE=BOTH;

Можно так же указать TNS-имя, которое будет преобразовываться с ip-адрес, и уже на нём будет осуществляться поиск прослушивателя.

Для этого создаём tnsnames.ora в /u01/app/oracle/product/11.2.0/dbhome_1/network/admin и указываем в нём описание нашей СУБД, если его ещё нет. 

ALPHA =
 (DESCRIPTION =
   (ADDRESS_LIST =
     (ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.70.15)(PORT = 1521))
   )
   (CONNECT_DATA =
     (SERVICE_NAME = alpha.domain.ru)
   )
 )

Это же описание должно быть у клиентов.

Указываем local_listener: 

SQL> alter system set LOCAL_LISTENER='ALPHA' SCOPE=BOTH;

Перезапускаем СУБД: 

[grid@grid1 ~] $ crsctl stop res rg1.rdbms
[grid@grid1 ~] $ crsctl start res rg1.rdbms

Проверяем, что СУБД зарегистрировалась на кластерном прослушивателе: 

[grid@grid1 ~] $ lsnrctl status LSNR_RG1
.........
Listening Endpoints Summary...
 (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=172.16.70.15)(PORT=1521)))
Services Summary...
Service "alpha.domain.ru" has 1 instance(s).
 Instance "alpha", status READY, has 1 handler(s) for this service...
The command completed successfully

Пробуем выполнить миграцию группы ресурсов: 

[grid@grid1 ~] $ crsctl relocate res rg1 -f

Ресурсы rg1,rg1.appvip,rg1.lsnr,rg1.rdbms должны запуститься на резервном узле. Для проверки подключитесь к СУБД.

[править] Создание головного ресурса

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

$ crsctl add resource rg1.top -type ora.cluster_resource.type -file rg1.top.cap

где файл-описание rg1.top.cap ресурса содержит следующее: 

ACTION_SCRIPT=/u01/app/11.2.0/grid/crs/public/act_resgroup.pl
START_DEPENDENCIES=hard(rg1,rg1.appvip,rg1.lsnr,rg1.rdbms)
STOP_DEPENDENCIES=hard(rg1,rg1.appvip,rg1.lsnr,rg1.rdbms)
ACTIVE_PLACEMENT=0
PLACEMENT=restricted
HOSTING_MEMBERS=grid1 grid2
AUTO_START=always
ACL=owner:grid:rwx,pgrp:oinstall:rwx,other::r--
RESTART_ATTEMPTS=1
CHECK_INTERVAL=600
START_TIMEOUT=30
STOP_TIMEOUT=30

Проверьте миграцию группы ресурсов: 

[grid@grid1 ~] $ crsctl relocate res rg1 -f

Все ресурсы должны запуститься на резервном узле. Проверьте статус ресурсов: 

[grid@grid1 ~] $ crsctl stat res -t

или 

[grid@grid1 ~] $ crs_stat -t -v

Аналогично под защиту Oracle Grid можно перевести для других экземпляров СУБД.

Источник — «http://5.9.243.178/wiki/Oracle_Coldfailover_11.2»