Oracle standalone что это
Oracle now supports Oracle REST Data Services (ORDS) running in standalone mode using the built-in Jetty web server, so you no longer need to worry about installing Tomcat or WebLogic unless you have a compelling reason to do so. Removing this extra layer means one less layer to learn and one less layer to patch.
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-устройств.
Развертывание 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.
Clusterware. CRS.
На данном уровне необходимо обеспечить координацию и совместную работу узлов кластера, т.е. clusterware слой: где-то между самим экземпляром базы данных и дисковым хранилищем:
CRS (Cluster-Ready Services) – набор сервисов, обеспечивающий совместную работу узлов, отказоустойчивость, высокую доступность системы, восстановление системы после сбоя. CRS выглядит как «мини-экземпляр» БД (ПО) устанавливаемый на каждый узел кластера. Устанавливать CRS – в обязательном порядке для построения Oracle RAC. Кроме того, CRS можно интегрировать с решениями clusterware от сторонних производителей, таких как HP или Sun.
Опять немного «терминологии»…
- CSSD – Cluster Synchronization Service Daemon
- CRSD – Cluster Ready Services Daemon
- EVMD – Event Monitor Daemon
Как уже стало ясно из таблички, самым главным процессом, «самым могущественным демоном», является CRSD (Cluster Ready Services Daemon). В его обязанности входит: запуск, остановка узла, генерация failure logs, реконфигурация кластера в случае падения узла, он также отвечает за восстановление после сбоев и поддержку файла профилей OCR. Если демон падает, то узел целиком перезагружается. CRS управляет ресурсами OCR: Global Service Daemon (GSD), ONS Daemon, Virtual Internet Protocol (VIP), listeners, databases, instances, and services.
- Node Membership (NM).Каждую секунду проверяет heartbeat между узлами. NM также показывает остальным узлам, что он имеет доступ к так называемому voting disk (если их несколько, то хотя бы к большинству), делая регулярно туда записи. Если узел не отвечает на heartbeat или не оставляет запись на voting disk в течение нескольких секунд (10 для Linux, 12 для Solaris), то master узел исключает его из кластера.
- Group Membership (GM). Функция отвечает за своевременное оповещение при добавлении / удалении / выпадении узла из кластера, для последующей реконфигурации кластера.
Информатором в кластере выступает EVMD (Event Manager Daemon), который оповещает узлы о событиях: о том, что узел запущен, потерял связь, восстанавливается. Он выступает связующим звеном между CRSD и CSSD. Оповещения также направляются в ONS (Oracle Notification Services), универсальный шлюз Oracle, через который оповещения можно рассылать, например, в виде SMS или e-mail.
Стартует кластер примерно по следующей схеме: CSSD читает из общего хранилища OCR, откуда считывает кластерную конфигурацию, чтобы опознать, где расположен voting disk, читает voting disk, чтобы узнать сколько узлов (поднялось) в кластере и их имена, устанавливает соединения с соседними узлами по протоколу IPC. Обмениваясь heartbeat, проверяет, все ли соседние узлы поднялись, и выясняет, кто в текущей конфигурации определился как master. Ведущим (master) узлом становится первый запустившийся узел. После старта, все запущенные узлы регистрируются у master, и впоследствии будут предоставлять ему информацию о своих ресурсах.
Уровнем выше CRS на узлах установлены экземпляры базы данных.
Друг с другом узлы общаются по private сети – Cluster Interconnect, по протоколу IPC (Interprocess Communication). К ней предъявляются требования: высокая ширина пропускной способности и малые задержки. Она может строиться на основе высокоскоростных версий Ethernet, решений сторонних поставщиков (HP, Veritas, Sun), или же набирающего популярность InfiniBand. Последний кроме высокой пропускной способности пишет и читает непосредственно из буфера приложения, без необходимости в осуществлении вызовов уровня ядра. Поверх IP Oracle рекомендует использовать UDP для Linux, и TCP для среды Windows. Также при передаче пакетов по interconnect Oracle рекомендует укладываться в рамки 6-15 ms для задержек.
Как известно, кластеры позволяют решать проблемы, связанные с производительностью, балансировкой нагрузки и отказоустойчивостью. Для построения кластеров используются различные решения и технологии, как на программном, так и на аппаратном уровне. В этой статье будут рассмотрены программные решения, предлагаемые компаниями Microsoft и Oracle.
Installation
The ORDS installation process is similar regardless of the application server being used, so you should follow the installation described here, but make sure you specify the following parameters in the "ords_params.properties" file. Obviously adjust to the desired settings and ignore the Tomcat deployment.
The static image location used a different parameter name prior to ORDS 19, but you shouldn't be using that now anyway.
The installation parameters are a convenience. The underlying Jetty configuration remains the same, so once you have installed ORDS, you can reconfigure Jetty as described below. You don't need to reinstall ORDS to alter the settings.
If you did the installation using the standalone settings (as above), you will find the standalone settings in the following file.
If not, you will need to start ORDS in standalone mode one, and the config file will be created. You can then adjust it at as you require.
Once started, ORDS will be available using one of the following URLs.
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, могут быть защищены от программных и аппаратных сбоев.
Виртуализация, вычислительные платформы, СХД, проектирование, проектная документация
Посмотрел в интернетах: есть русскоязычные описания как установить и настроить 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
Дополнительно, во избежание появления ошибок при инсталляции ПО Oracle исправим в файле /etc/sysconfig/ntpd строку на
OPTIONS=»-x -u ntp:ntp -p /var/run/ntpd.pid»
3.3 В реальной инсталляции еще необходимо настроить таймауты на запросы и кол-во попыток запросов к DNS-серверу. Делается это добавлением следующих строк к /etc/resolv.conf:
options attempts:1
options timeout:1
….
5. На каждом из хостов rac-node01 и rac-node02 прописываем имена в файле /etc/hosts
192.168.110.163 rac-node01.test.local rac-node01
192.168.110.164 rac-node02.test.local rac-node02
192.168.110.200 rac-vip01.test.local rac-vip01
192.168.110.201 rac-vip02.test.local rac-vip02
192.168.110.210 rac01-scan.test.local rac01-scan
192.168.110.211 rac01-scan.test.local rac01-scan
192.168.110.212 rac01-scan.test.local rac01-scan
192.168.110.152 store.test.local store
192.168.110.213 rac02-scan.test.local rac02-scan
Ура, на этом установка ASM завершена, на очереди — GRID. Напомню, что GRID — это кластерное ПО от Oracle.
13. Скачиваем Oracle GRID (версии 11.2.0.3!), помещаем дистрибутив Oracle GRID в /distr/grid на хосте rac-node01
Настраиваем сквозную аутентификацию и доверительные отношения между узлами кластера для пользователей grid и oracle.
На хосте rac-node01 выполнить:
на хосте rac-node02 выполнить:
VNCSERVERS=»2:grid 3:oracle»
VNCSERVERARGS[2]=»-geometry 1280×1024″
VNCSERVERARGS[3]=»-geometry 1280×1024″
Ошибку с разрешением SCAN-имен игнорируем, поскольку у нас все разрешается через файл /etc/hosts, а не через DNS.
В конце инсталлятор попросит выполнить из под пользователя root инсталляционные скрипты на всех хостах кластера, рекомендую выполнять последовательно, один хост за другим, а не в параллель.
Примечания:
Диски ASM ищем в /dev/oracleasm/disks (стандартный путь).
Disk redundancy: external — не делать зеркалирования данных средствами ASM
Все должно быть ONLINE, кроме ora.gsd (этот нам и не нужен, «With Oracle RAC 11g Release 2, the gsd resource is disabled by default. You will only need to enable the resource if you are running Oracle 9i RAC in the same cluster»).
17. Создадим еще одну дисковую группу ASM для хранения данных БД — DATA:
$ /u01/app/11.2/grid/bin/asmca
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;
SQL> ALTER DATABASE TEMPFILE ‘+DATA/test/tempfile/temp.262.868380761’ RESIZE 200M;
Пробуем еще раз,
окружение успешно создано.
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;
Виды кластеров
Кластер — это группа независимых компьютеров (так называемых узлов или нодов), к которой можно получить доступ как к единой системе. Кластеры могут быть предназначены для решения одной или нескольких задач. Традиционно выделяют три типа кластеров:
- Кластеры высокой готовности или отказоустойчивые кластеры (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), но на любой поддерживаемой ОС.
Create a Tablespace for Standalone Repository
Create a tablespace with the following attributes:
-
Type: Permanent Storage attributes: for Extent Management, use Locally managed Datafile attributes:
- отсутствие необходимости в отдельном ПО для управления разделами дисков
- нет необходимости в файловой системе
- Зеркалирование данных:
как правило, 2-х или 3-х ступенчатое, т.е. данные одновременно записываются на 2 или 3 диска. Для зеркалирования диску указываются не более 8 дисков-партнеров, на которые будут распределяться копии данных. - Автоматическая балансировка нагрузки на диски (обеспечение высокой доступности):
если данные tablespace разместить на 10 дисках и, в некоторый момент времени, чтение данных из определенных дисков будет «зашкаливать», ASM сам обратится к таким же экстентам, но находящимся на зеркалированных дисках. - Автоматическая ребалансировка:
При удалении диска, ASM на лету продублирует экстенты, которые он содержал, на другие оставшиеся в группе диски. При добавлении в группу диска, переместит экстенты в группе так, что на каждом диске окажется приблизительно равное число экстентов. - область хранения данных, т.е. физические файлы на диске (datastorage) (сама БД)
- экземпляр БД (получающая и обрабатывающая эти данные в оперативной памяти) (СУБД)
- Что будет, если Oracle упадет где-то на середине длинной транзакции (если бы она вносила изменения)?
- Какие же данные прочтет первая транзакция, когда в кэше у нее «под носом» другая транзакция изменила блок?
- журнал повтора (redo log)
- сегмент отмены (undo)
-
Size:
-
For 2 Kb blocks: 16 MB For 4 Kb blocks: 24 MB For 8 Kb blocks: 32 MB For sizes above 8 KB: 64 MB
To create a tablespace for the standalone repository, first select the database in which you want to place the standalone repository, ensuring it meets the requirements outlined . Then, follow the procedure described in this section:
-
Start the standalone Console.
On Windows:
You can start the standalone Console from the Windows Start Menu.
On UNIX:
You can start the standalone Console from the command line using the command:
When the Oracle Enterprise Manager Console Login appears, select the Launch standalone option to connect directly to databases and click OK.
-
Enter the name of the new tablespace, OEM_REPOSITORY. Specify that the tablespace will be used to hold permanent database objects.
-
Select the Automatically extend datafile when full (AUTOEXTEND) option so that the datafile will automatically increase in size when more space is needed in the database. Specify 5 MB as the Increment. Specify 2000 MB as the Maximum Size.
Заключение
Oracle RAC совместно с Oracle Grid Infrastructure позволяют реализовать разнообразные сценарии построения кластеров. Гибкость настройки и широта возможностей компенсируются ценой такого решения.
Решения же Microsoft ограничены не только возможностями самой кластеризации, но и продуктами, которые могут работать в такой среде. Хотя стоит отметить, что набор таких продуктов все равно шире, чем одна база данных.
Access Log
Thanks to Kris Rice for his explanation of how to configure this (see here).
Access logs are really important if you want to know who is accessing your web server. The Jetty web server, which is used by ORDS in standalone mode, can be configured using XML files. The Jetty documentation for this feature can be found here.
Create the ". /standalone/etc" directory to hold the config file and a directory to hold the log files.
Create a new file called "/u01/ords/conf/ords/standalone/etc/jetty-http.xml" with the following contents. Adjust the configuration as required.
Once you access ORDS you will see an access log created in the "/u01/ords/conf/ords/standalone/logs" directory.
Beginning with Release 9.0, the Enterprise Manager Console or various other Enterprise Manager applications can be started standalone or with a Management Server connection. When you start the Enterprise Manager Console or other applications standalone, the Console or other application is not connected to the middle tier Management Server.
Because it does not require a middle tier Management Server or Intelligent Agents on target machines, the Console started standalone enables a single administrator to perform simple database schema, instance, storage, security, and other database tasks by connecting directly to the target database or databases.
This chapter will describe the out-of-box requirements for running the Console standalone.
Custom Error Pages
Add the following entry to the "/u01/ords/conf/ords/defaults.xml" file and restart ords. Adjust the path as required.
Create the required custom error files. I've just created some simple ones to test with.
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, что ставит под сомнение целесообразность ее использования.
Standalone Repository
The standalone Console includes several integrated applications. Some of these integrated applications require a standalone repository in which to save information.
The standalone repository is different from the repository used by the Management Server since it is used for a single user while the Management repository is used for multiple users.
The applications which require a standalone repository include:
The first time one of the above standalone applications is accessed, you will be prompted to create a database user who will own the standalone repository schema or you will be prompted to specify a username and password if you have already created the user.
Figure 2-5 Prompt to Create Database User
Figure 2-6 Repository Login
Because this database user must have certain roles and privileges, Oracle recommends creating a new database user to own the standalone repository schema. In addition, because certain tablespace attributes are required for the standalone repository, you should also create a new tablespace. Once the user and tablespace have been created, you can supply the user's username and password, and the standalone application will automatically create the standalone repository for you.
When subsequent standalone applications which require a standalone repository are accessed, they will all use the same standalone repository. If you do not want to be prompted with the standalone Repository Login dialog every time you start your standalone application, select the Save password and automatically log into repository next time option to save the credentials for future use.
APEX Static Images
When using ORDS to front APEX applications, ORDS should be configured to serve the APEX static files.
Edit the following path in the "/u01/ords/conf/ords/standalone/standalone.properties" file to the desired OS path.
Starting the Standalone Console
On Windows-based platforms, start the Console from the Windows Start Menu.
On any supported platform, you can start the Console from the command line by entering the command:
On UNIX platforms, the oemapp part of the command is case-sensitive and must be entered with lowercase characters.
When the Oracle Enterprise Manager Console Login appears, select the Launch standalone option and click OK.
Figure 2-2 Oracle Enterprise Manager Console Login
Your login choice is remembered for the next time you log in whether you selected the Launch standalone option or the Login to the Oracle Management Server option for the last login. If you had selected the Login to the Oracle Management Server option, the Management Server is remembered.
To bypass the Oracle Enterprise Manager Console Login, you can enter the following command at any supported operating system command line:
By entering the command, you will immediately see the standalone Console.
Figure 2-3 Standalone Console
If you are starting the standalone Console for the first time, the left panel of standalone Console is empty because you have not yet added the databases you want to manage. The Add Databases To Tree dialog appears automatically so that you can add them to the Navigator.
Уровень доступа к данным. ASM.
Хранилищем (datastorage) в больших БД почти всегда выступает SAN (Storage Area Network), который предоставляет прозрачный интерфейс серверам к дисковым массивам.
Сторонние производители (Hitachi, HP, Sun, Veritas) предлагают комплексные решения по организации таких SAN на базе ряда протоколов (самым распространенным является Fibre Channel), с дополнительными функциональными возможностями: зеркалирование, распределение нагрузки, подключение дисков на лету, распределение пространства между разделами и.т.п.
Позиция корпорации Oracle в вопросе построения базы данных любого масштаба сводится к тому, что Вам нужно только соответствующее ПО от Oracle (с соответствующими лицензиями), а выбранное оборудование – по возможности (если средства останутся после покупки Oracle :). Таким образом, для построения высоконагруженной БД можно обойтись без дорогостоящих SPARC серверов и фаршированных SAN, используя сервера на бесплатном Linux и дешевые RAID-массивы.
На уровне доступа к данным и дискам Oracle предлагает свое решение – ASM (Automatic Storage Management). Это отдельно устанавливаемый на каждый узел кластера мини-экземпляр Oracle (INSTANCE_TYPE = ASM), предоставляющий сервисы работы с дисками.
Oracle старается избегать обращений к диску, т.к. это является, пожалуй, основным bottleneck любой БД. Oracle выполняет функции кэширования данных, но ведь и файловые системы так же буферизуют запись на диск. А зачем дважды буферизировать данные? Причем, если Oracle подтвердил транзакцию и получил уведомления том, что изменения в файлы внесены, желательно, чтобы они уже находились там, а не в кэше, на случай «падения» БД. Поэтому рекомендуется использовать RAW devices (диски без файловой системы), что делает ASM.
Таким образом, кластер теперь может хранить и читать данные с общего файлового хранилища.
Пора на уровень повыше.
Static Resources (Document Root)
ORDS can be used to serve static content like a regular web server.
Edit the following path in the "/u01/ords/conf/ords/standalone/standalone.properties" file to the desired OS path. The line below shows the default path.
Make sure the desired path exists.
Database Requirements for Standalone Repository
The following database releases are supported for the standalone repository:
-
Enterprise Edition or Standard Edition Release 9.2.x Enterprise Edition or Standard Edition Release 9.0.1.x Enterprise Edition or Standard Edition Release 8.1.7.x
For 8.1.7 databases, refer to the upgrade requirements documented in "Version Compatibility" .
You must ensure that the database in which the repository will be placed has object support. If it does not, repository creation will fail. Either select another database that has object support, or install and enable object support on the chosen database.
Object support is installed and enabled by default for database releases 9.2.x, 9.0.1.x, and 8.1.7.x.
Create a Database User for Standalone Repository
A standalone repository is owned by a database user. A database user, in other words, a repository schema user, who will own the repository must be created before the standalone repository can be created by Enterprise Manager.
To create a database user who will own the standalone repository, follow the procedure described in this section:
-
Start the standalone Console. Click the + next to Databases to display the list of databases under the Databases. Double-click the database node in the Navigator and connect to the database as a user with the NORMAL role. Choose Create from the Object menu. The Create Object List dialog appears. Expand the database node in the Create Object List dialog and select User. Then click Create. The Create User property sheet appears. In the General page, provide the name of the user and its password and select OEM_REPOSITORY as the default tablespace and TEMP as the temporary tablespace. In the Role page, grant the CONNECT and SELECT_CATALOG_ROLE roles to the repository user. In the System Privileges page grant the CREATE TRIGGER, CREATE PROCEDURE, EXECUTE ANY PROCEDURE, CREATE TYPE, EXECUTE ANY TYPE, SELECT ANY TABLE, and (for 9i) SELECT ANY DICTIONARY privileges to the repository user. In the Quota page, specify unlimited for OEM_REPOSITORY and TEMP. Click Create in the Create User property sheet.
Once you have a tablespace and a repository user, start a standalone application which requires a standalone repository.
When the dialog appears informing you that certain features of Enterprise Manager require a standalone repository and you must create a new database user to own the standalone repository schema, click OK to close the dialog since you have already created the user.
Supply the user's username and password for the repository login and click OK. The standalone application will automatically create the standalone repository for you.
If you use the Console standalone but later want to deploy the entire framework, you will not be able to migrate the standalone repository to the full framework/Management Server repository. This type of migration is not supported. Exporting the data of the standalone repository and importing it into another schema and having that schema work with the Management Server repository is also not supported.
Высоконагруженные сайты, доступность «5 nines». На заднем фоне (backend) куча обрабатываемой информации в базе данных. А что, если железо забарахлит, если вылетит какая-то давно не проявлявшаяся ошибка в ОС, упадет сетевой интерфейс? Что будет с доступностью информации? Из чистого любопытства я решил рассмотреть, какие решения вышеперечисленным проблемам предлагает Oracle. Последние версии, в отличие от Oracle 9i, называются Oracle 10g (или 11g), где g – означает «grid», распределенные вычисления. В основе распределенных вычислений «как ни крути» лежат кластера, и дополнительные технологии репликации данных (DataGuard, Streams). В этой статье в общих чертах описано, как устроен кластер на базе Oracle 10g. Называется он Real Application Cluster (RAC).
Статья не претендует на полноту и всеобъемлемость, также в ней исключены настройки (дабы не увеличивать в объеме). Смысл – просто дать представление о технологии RAC.
Статью хотелось написать как можно доступнее, чтобы прочесть ее было интересно даже человеку, мало знакомому с СУБД Oracle. Поэтому рискну начать описание с аспектов наиболее часто встречаемой конфигурации БД – single-instance, когда на одном физическом сервере располагается одна база данных (RDBMS) Oracle. Это не имеет непосредственного отношения к кластеру, но основные требования и принципы работы будут одинаковы.
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 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. Далее создаются ресурсы и скрипты, которые позволяют запускать экземпляр на другом узле в случае недоступности первого.
Adding Databases to the Tree in the Standalone Console
You can also access the Add Databases To Tree dialog from the Navigator menu.
Figure 2-4 Add Databases to Tree
The Add Databases To Tree dialog enables you to manually enter the Net service names or add them from the local tnsnames.ora file.
Add a database manually
You can add databases to the standalone Console Navigator by filling in the following fields:
-
SID: The database system identifier, usually the instance name, such as ORCL . Hostname: The machine or node name where the database is located. Port Number: The database listener port address, usually 1521 or 1526. Net Service Name: A name which uniquely identifies a database when connecting to a machine. It is usually the global database name.
For example: ORCL.world .
Adding a database manually automatically updates the local tnsnames.ora file located in your /network/admin directory.
Add selected databases from your local tnsnames.ora file
You can populate the standalone Console Navigator by reading the database service names from the local tnsnames.ora file located in your Oracle Enterprise Manager home. The Add Databases To Tree dialog displays a list of databases identified in your tnsnames.ora file from which you can select or clear. Click the column header to the left of Service Name to either select or clear all the database boxes. If you have cleared all the selected database boxes, you can select specific databases by clicking their boxes.
Currently only TCP/IP service names can be added manually for the standalone Console. If other network protocols are required, add them by entering them in the tnsnames.ora file using the Oracle Net Configuration Assistant. All protocols are supported when you import selected services from your tnsnames.ora file.
After adding databases to the Navigator, see the Oracle Enterprise Manager Administrator's Guide for details on how to use the standalone Console to perform administration tasks.
Starting/Stopping ORDS in Standalone Mode
During testing, you can manually start the ORDS using the following command. If you have fully configured ORDS it won't prompt you for any user input.
It will capture the console and push all log information to it. You can stop ORDS using CTRL+C.
For a production deployment you should start ORDS as a background process and push the output to a log file. For example, you could create a file called "~/scripts/start_ords.sh" with the following contents. Remember to adjust paths as required.
You can kill ORDS by killing the background process. Create a scripts called "~/scripts/stop_ords.sh" with the following contents.
Create the log directory and make the scripts executable.
You can then easily stop and start ORDS using the scripts.
ORDS will automatically create a self-signed certificate for use with SSL if you don't specify a valid certificate and key.
Edit the "/u01/ords/conf/ords/standalone/standalone.properties" file, setting the following parameters. Adjust the port as desired.
You should probably be fronting ORDS with a reverse proxy or a load balancer, so you may decide to leave internal network communication using HTTP. If you do want direct access, or internal network traffic encryption, you will need to configure Jetty to use HTTPS. If you have a proper CA certificate and key, make sure they are in DER format and just do the "standalone.properties" file settings. In this case we will manually create a new self-signed certificate and use that for the HTTPS configuration. Remember to adjust the "dname" and passwords as required.
If everything has gone OK you now have key and certificate in DER format.
Edit the "/u01/ords/conf/ords/standalone/standalone.properties" appending the following settings.
Check it has started correctly by looking at the log file.
Once started, ORDS will be available using the following URL.
Введение. Single-instance.
Во всех современных реляционных БД данные хранятся в таблицах. Таблицы, индексы и другие объекты в Oracle хранятся в логических контейнерах – табличных пространствах (tablespace). Физически же tablespace располагаются в одном или нескольких файлах на диске. Хранятся они следующим образом:
Каждый объект БД (таблицы, индексы, сегменты отката и.т.п.) хранится в отдельном сегменте – области диска, которая может занимать пространство в одном или нескольких файлах. Сегменты в свою очередь, состоят из одного или нескольких экстентов. Экстент – это непрерывный фрагмента пространства в файле. Экстенты состоят из блоков. Блок – наименьшая единица выделения пространства в Oracle, по умолчанию равная 8K. В блоках хранятся строки данных, индексов или промежуточные результаты блокировок. Именно блоками сервер Oracle обычно выполняет чтение и запись на диск. Блоки имеют адрес, так называемый DBA (Database Block Address).
При любом обращении DML (Data Manipulation Language) к базе данных, Oracle подгружает соответствующие блоки с диска в оперативную память, а именно в буферный кэш. Хотя возможно, что они уже там присутствуют, и тогда к диску обращаться не нужно. Если запрос изменял данные (update, insert, delete), то изменения блоков происходят непосредственно в буферном кэше, и они помечаются как dirty (грязные). Но блоки не сразу сбрасываются на диск. Ведь диск – самое узкое место любой базы данных, поэтому Oracle старается как можно меньше к нему обращаться. Грязные блоки будут сброшены на диск автоматически фоновым процессом DBWn при прохождении контрольной точки (checkpoint) или при переключении журнала.
Когда в базу данных поступает запрос на изменение, то Oracle применяет его в буферном кэше, параллельно внося информацию, достаточную для повторения этого действия, в буфер повторного изменения (redo log buffer), находящийся в оперативной памяти. Как только транзакция завершается, происходит ее подтверждение (commit), и сервер сбрасывает содержимое redo buffer log на диск в redo log в режиме append-write и фиксирует транзакцию. Такой подход гораздо менее затратен, чем запись на диск непосредственно измененного блока. При сбое сервера кэш и все изменения в нем потеряются, но файлы redo log останутся. При включении Oracle начнет с того, что заглянет в них и повторно выполнит изменения таблиц (транзакции), которые не были отражены в datafiles. Это называется «накатить» изменения из redo, roll-forward. Online redo log сбрасывается на диск (LGWR) при подтверждении транзакции, при прохождении checkpoint или каждые 3 секунды (default).
С undo немного посложнее. С каждой таблицей в соседнем сегменте хранится ассоциированный с ней сегмент отмены. При запросе DML вместе с блоками таблицы обязательно подгружаются данные из сегмента отката и хранятся также в буферном кэше. Когда данные в таблице изменяются в кэше, в кэше так же происходит изменение данных undo, туда вносятся «противодействия». То есть, если в таблицу был внесен insert, то в сегмент отката вносится delete, delete – insert, update – вносится предыдущее значение строки. Блоки (и соответствующие данные undo) помечаются как грязные и переходят в redo log buffer. Да-да, в redo журнал записываются не только инструкции, какие изменения стоит внести (redo), но и какие у них противодействия (undo). Так как LGWR сбрасывает redo log buffer каждые 3 секунды, то при неудачном выполнении длительной транзакции (на пару минут), когда после минуты сервер упал, в redo будут записи не завершенные commit. Oracle, как проснется, накатит их (roll-forward), и по восстановленным (из redo log) в памяти сегментам отката данных отменит (roll-back) все незафиксированные транзакции. Справедливость восстановлена.
Кратко стоит упомянуть еще одно неоспоримое преимущество undo сегмента. По второму сценарию (из схемы) когда select дойдет до чтения блока (DBA) 500, он вдруг обнаружит что этот блок в кэше уже был изменен (пометка грязный), и поэтому обратится к сегменту отката, для того чтобы получить соответствующее предыдущее состояние блока. Если такого предыдущего состояния (flashback) в кэше не присутствовало, он прочитает его с диска, и продолжит выполнение select. Таким образом, даже при длительном «select count(money) from bookkeeping» дебет с кредитом сойдется. Согласованно по чтению (CR).
Отвлеклись. Пора искать подступы к кластерной конфигурации. =)
Choosing to Start the Console Standalone
Start the Console standalone when you want to connect directly to your managed target or targets to perform administration tasks. With Enterprise Manager Release 9.2.0, the standalone Console only supports connecting directly to database targets. No other target types are currently supported for direct connection from the Console.
Figure 2-1 Standalone Configuration
Starting standalone does not require a Management Server as a middle tier or Intelligent Agents on managed targets. Consequently, when you start the Console standalone, you do not have access to functionality typically available through the Management Server and Intelligent Agent, such as:
Читайте также: