Oracle Restart on Windows Platform
Несколько уроков, полученных при инсталляции Oracle Restart на платформе Windows:
- Установку следует производить с диска Grid Infrastructure (GI), но при установке следует выбрать Grid Infrastacture for standalone server.
- При установке от вас потребуется сконфигурировать группу ASM, а это значит что необходимо специальным образом подготовить raw device. Лучше всего прочитать стр. 12 . из этого документа УСТАНОВКА ORACLE DATABASE 10.2 RAC НА ПЛАТФОРМЕ WINDOWS 2003 SERVER R2 SE X64
- Вам придется решить для себя вопрос, где хранить файлы БД. В принципе инсталлятор позволяет Вам выбрать локальную файловую систему, но я честно говоря смысла уже не вижу- ведь ASM у нас и так есть.
- Инсталлятор БД сам обнаружил, что у нас стоит GI и сам зарегистрировал нашу БД в ней.
- После того как мы убили процессы oracle.exe и получили в sqlplus "End of communication channel" наша БД магическим образом ожили снова. Эта магия обеспечивается c помощью процессов Clusterware. Строго говоря защищается не только БД, но и ASM и listener.
Что интересно: все выглядит так, как будто у нас RAC, только одноузловой! :-)
Вот вывод команды crs_stat -t
Причем Windows-сервисы листенера и экземпляра СУБД теперь НЕ стартуют автоматически (стоят в Manual), - все верно: теперь их запускает Clusterware (причем в нужном порядке !).
Обратите ваше внимание, что теперь вы управляете вашей БД с помощью настоящих кластерных команд: srvctl, crs_stat и пр. Таким образом, после опыта работы с Oracle Restart переезд в настоящий кластер для вас, как для администратора, будет практически прозрачен. А разработчики могут начать потихоньку модифицировать свое приложение, чтобы научится обрабатывать FAN сообщения.
Правда как я писал ранее, не все еще гладко при переходе от Oracle Restart к настоящему RAC - но про крайне мере этот процесс описан в документации.
Update 1
Более внимательно приглядевшись к нашему локальному кластеру, я увидел, что:
Вывод из файла:
%CRS_HOME%\cfgtoollogs\crsconfig\roothas.log
2010-07-21 15:27:04: OCR locations = D:\oracle\grid\cdata\localhost\local.ocr
2010-07-21 15:27:04: VOTING_DISKS=
т.е. voting дисков нет вообще (ну хорошо, голосовать не с кем), а ocr лежит локально. Тогда вообще не понятно, зачем нужен ASM экземпляр, на нем вообще ничего нет (если вы не разместили БД).
Update 2
Clusterware оказывалась какая-то урезанная - например не все ключи srvctl работают. Теперь потихоньку понятно становиться, почему требуется переставлять clusterware при переходе к настоящему кластеру.
- Установку следует производить с диска Grid Infrastructure (GI), но при установке следует выбрать Grid Infrastacture for standalone server.
- При установке от вас потребуется сконфигурировать группу ASM, а это значит что необходимо специальным образом подготовить raw device. Лучше всего прочитать стр. 12 . из этого документа УСТАНОВКА ORACLE DATABASE 10.2 RAC НА ПЛАТФОРМЕ WINDOWS 2003 SERVER R2 SE X64
- Вам придется решить для себя вопрос, где хранить файлы БД. В принципе инсталлятор позволяет Вам выбрать локальную файловую систему, но я честно говоря смысла уже не вижу- ведь ASM у нас и так есть.
- Инсталлятор БД сам обнаружил, что у нас стоит GI и сам зарегистрировал нашу БД в ней.
- После того как мы убили процессы oracle.exe и получили в sqlplus "End of communication channel" наша БД магическим образом ожили снова. Эта магия обеспечивается c помощью процессов Clusterware. Строго говоря защищается не только БД, но и ASM и listener.
Что интересно: все выглядит так, как будто у нас RAC, только одноузловой! :-)
Вот вывод команды crs_stat -t
C:\>crs_stat -t
Name Type Target State Host
-----------------------------------------------------------
ora.DATA.dg ora....up.type ONLINE ONLINE isvru2
ora....ER.lsnr ora....er.type ONLINE ONLINE isvru2
ora.asm ora.asm.type ONLINE ONLINE isvru2
ora.cssd ora.cssd.type ONLINE ONLINE isvru2
ora.orcl.db ora....se.type ONLINE ONLINE isvru2
Обратите ваше внимание, что теперь вы управляете вашей БД с помощью настоящих кластерных команд: srvctl, crs_stat и пр. Таким образом, после опыта работы с Oracle Restart переезд в настоящий кластер для вас, как для администратора, будет практически прозрачен. А разработчики могут начать потихоньку модифицировать свое приложение, чтобы научится обрабатывать FAN сообщения.
Правда как я писал ранее, не все еще гладко при переходе от Oracle Restart к настоящему RAC - но про крайне мере этот процесс описан в документации.
Update 1
Более внимательно приглядевшись к нашему локальному кластеру, я увидел, что:
Вывод из файла:
%CRS_HOME%\cfgtoollogs\crsconfig\roothas.log
2010-07-21 15:27:04: OCR locations = D:\oracle\grid\cdata\localhost\local.ocr
2010-07-21 15:27:04: VOTING_DISKS=
т.е. voting дисков нет вообще (ну хорошо, голосовать не с кем), а ocr лежит локально. Тогда вообще не понятно, зачем нужен ASM экземпляр, на нем вообще ничего нет (если вы не разместили БД).
Update 2
Clusterware оказывалась какая-то урезанная - например не все ключи srvctl работают. Теперь потихоньку понятно становиться, почему требуется переставлять clusterware при переходе к настоящему кластеру.
Комментариев нет:
Отправить комментарий