Aychin's Oracle RDBMS Blog

Only for Advanced level Professionals

Oracle 11gR2 + ASM + spfile (rus)


Oracle 11g R2 ввел новое понятие, OLR (Oracle Local Repository). Данный репозиторий предназначен для хранения данных локальных ресурсов, т.е. тех ресурсов которые привязаны к локальному ноду (Cluster node). Это позволяет увеличить скорость доступа к параметрам локальных ресурсов и увеличить отказоустойчивость. В RAC конфигурации присутствует и глобальный OCR репозиторий и локальные OLR репозитории на каждом ноде. В конфигурации Oracle Restart, где грид инфраструктура обслуживает отдельно стоящий хост, используется только OLR репозиторий. Кроме того введено новое понятие Grid Plug and Play (GPNP) как видно из названия данное нововведение призванно облегчить жизнь администратору автоматизируя некоторые аспекты администрации грид инфраструктуры. В специальном XML файле, называемом PGNP профайлом хранится конфигурационная информация компонентов нода к которым PGNP имеет отношение, к примеру информация о сетевых интерфейсах.

Но я хочу в этом документе обсудить другую возможность доступную с версии 11gR2, это возможность хранения spfile-а на ASM дисках в том числе и для самого +ASM экзепляра. Тут резонно возникают следующие вопросы:

  1. Как процесс может прочесть spfile с ASM диска если диски еще не смонтированны экземпляром
  2. Откуда процесс берет информацию о том, где находится spfile если в $ORACLE_HOME/dbs нет файла init+ASM.ora с параметром spfile=
  3. Как насчет параметра asm_diskstring

Третий пункт важен потому как, перед тем как прочесть spfile с ASM диска, сначала надо определить диски кандидаты на которых может находиться этот файл. Чтобы сделать это процесс должен знать куда смотреть, для этого ему и нужен параметр asm_diskstring.

Для того чтобы пролить свет на эти вопросы я воспользуюсь трассировкой системных вызовов интересующих меня процессов, для этого можно использовать такие утилиты как truss, strace, Dtrace и т. д. в зависимости от платформы. Я нахожусь на Linux поэтому воспользуюсь strace.

Моя среда это Oracle Grid Infrastructure 11gR2 (11.2.0.1.0) в конфигурации Oracle Restart. Я симулировал ASM диски с помощью /dev/loop* девайсов, и у меня 5 дисков

bash> /etc/init.d/oracleasm listdisks
DISK1
DISK2
DISK3
DISK4
DISK5

SQL> conn / as sysasm
Connected.
SQL> col path format a15

SQL> select a.name,a.state,b.name,b.path from v$asm_diskgroup a, v$asm_disk b where a.group_number=b.group_number order by b.name;

NAME                           STATE       NAME                           PATH
------------------------------ ----------- ------------------------------ ---------------
DGROUP1                        MOUNTED     DISK1                          ORCL:DISK1
DGROUP1                        MOUNTED     DISK2                          ORCL:DISK2
DGROUP2                        MOUNTED     DISK3                          ORCL:DISK3
DGROUP2                        MOUNTED     DISK4                          ORCL:DISK4
DGROUP2                        MOUNTED     DISK5                          ORCL:DISK5

Как видно из листинга у меня две дисковые группы DGROUP1 и DGROUP2. Мой spfile находится на DGROUP1

SQL> show parameter spfile;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ----------------------------------------------------
spfile                               string      +DGROUP1/asm/asmparameterfile/registry.253.740659373

Теперь проведем пару тестов

SQL> conn / as sysasm
Connected.

SQL> startup
ASM instance started

Total System Global Area  284565504 bytes
Fixed Size                  1336036 bytes
Variable Size             258063644 bytes
ASM Cache                  25165824 bytes
ASM diskgroups mounted
SQL>
SQL> show parameter power

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
asm_power_limit                      integer     1
SQL> alter system set asm_power_limit=3;

System altered.

SQL> show parameter power

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
asm_power_limit                      integer     3

SQL>--We set asm_power_limit to 3 in spfile

SQL> shutdown immediate;
ASM diskgroups dismounted
ASM instance shutdown

SQL> !crs_stat -t
Name           Type           Target    State     Host
------------------------------------------------------------
ora.DGROUP1.dg ora....up.type OFFLINE   OFFLINE
ora.DGROUP2.dg ora....up.type OFFLINE   OFFLINE
ora....ER.lsnr ora....er.type ONLINE    ONLINE    testdb03
ora.asm        ora.asm.type   OFFLINE   OFFLINE
ora.cssd       ora.cssd.type  ONLINE    ONLINE    testdb03
ora.diskmon    ora....on.type ONLINE    ONLINE    testdb03

SQL>-- Lets start instance in nomount mode, it will not mount the diskgroups

SQL> startup nomount;
ASM instance started

Total System Global Area  284565504 bytes
Fixed Size                  1336036 bytes
Variable Size             258063644 bytes
ASM Cache                  25165824 bytes

SQL> show parameter spfile;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ----------------------------------------------------
spfile                               string      +DGROUP1/asm/asmparameterfile/registry.253.740659373

SQL> show parameter power

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
asm_power_limit                      integer     3

SQL> select * from v$spparameter;
select * from v$spparameter
              *
ERROR at line 1:
ORA-15001: diskgroup "DGROUP1" does not exist or is not mounted

SQL> alter system set asm_power_limit=10;
alter system set asm_power_limit=10
*
ERROR at line 1:
ORA-32000: write to SPFILE requested but SPFILE is not modifiable

SQL> !asmcmd
ASMCMD> ls
ASMCMD> exit

SQL> !crs_stat -t
Name           Type           Target    State     Host
------------------------------------------------------------
ora.DGROUP1.dg ora....up.type OFFLINE   OFFLINE
ora.DGROUP2.dg ora....up.type OFFLINE   OFFLINE
ora....ER.lsnr ora....er.type ONLINE    ONLINE    testdb03
ora.asm        ora.asm.type   ONLINE    ONLINE    testdb03
ora.cssd       ora.cssd.type  ONLINE    ONLINE    testdb03
ora.diskmon    ora....on.type ONLINE    ONLINE    testdb03

Итак, что мы видим, мы смогли поднять экземпляр не монтируя диски, наш процесс определил верный spfile. SHOW PARAMETER выводит значение параметра из оперативной памяти, но если мы попытаемся прочесть spfile (select from v$spparameter) или изменить его (alter system) то мы не сможем этого сделать. Это значит что наш процесс инициализирующий экземпляр считывает spfile напрямую с ASM диска в процессе инициализации. Но откуда наш процесс знает какие диски надо просканировать, к примеру, если я использую мультиканальные диски на HP-UX то путь к ним находится в /dev/rdisk/* который +ASM по умолчанию не сканирует, чтобы он их увидел надо задать параметр asm_diskstring=’/dev/rdisk/*’ который в свою очередь находится в spfile.  Получается даже зная где spfile мы не сможем поднять экземпляр, нам нужен доступ к диску, чтобы найти диск нужен spfile (asm_diskstring) а чтобы прочесть spfile нужен диск. Замкнутый круг.

Используя strace прольем свет на то как это работает.

В моей конфигурации asm_diskstring равен значению по умолчанию null, на линуксе в строку поиска по умолчанию входит также путь /dev/oracleasm/disks/* поэтому он определяет их по умолчанию. Для начала загрузим sqlplus и залогинимся “conn / as sysasm”, создастся серверный процесс, который и будет делать всю эту работу, именно его мы и будем трейсить

bash> sqlplus /nolog
SQL> conn / as sysasm
Connected.
SQL> !ps -aefH
.
.
oracle   15505  4255  0 13:26 pts/1    00:00:00           sqlplus
oracle   15507 15505  0 13:26 ?        00:00:00             oracle+ASM (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
.
.
SQL>

Номер нашего процесса 15507, теперь запустим его трассировку

bash> strace -o userproc.out -p 15507

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

SQL> startup nomount;

Total System Global Area  284565504 bytes
Fixed Size                  1336036 bytes
Variable Size             258063644 bytes
ASM Cache                  25165824 bytes

SQL>

Теперь можно проанализировать содержимое userproc.out, я не буду приводить все содержимое, а только те моменты которые нас интересуют, итак по порядку с верху вниз

Первая строка это

read(9, "001\6\3\212\6\376\377\377\377\1\376\377\377\377\376\377\377\377"..., 8208) = 49

это наша команда “startup nomount” переданная нашему процессу по сокету с дескриптором 9

connect(6, {sa_family=AF_FILE, path="/var/tmp/.oracle/sOCSSD_LL_testdb03_"...}, 110) = 0
open("/u01/oracle/product/grid11g/auth/css/testdb03/A6857753/84b0b692", O_WRONLY|O_CREAT|O_EXCL, 0644) = 13
write(13, "\nS\336[", 4)                = 4
close(13)

из этих строк видно что наш процесс подключается к сокет файлу /var/tmp/.oracle/sOCSSD_LL_testdb03_ для связи с OCSSD потом аутенцифицируется к нему. Вот почему невозможно поднять экземпляр ASM без работающего OCSSD. Потом наш процесс устанавливает соединение с OHASD (Oracle High Availability Services Deamon) через сокет файл /var/tmp/.oracle/sCRSD_UI_SOCKET, после обмена сообщениями с OHASD наш процесс получает информацию о том где находится наш spfile и параметр asm_diskstring

access("/var/tmp/.oracle/sCRSD_UI_SOCKET", F_OK) = 0
connect(14, {sa_family=AF_FILE, path="/var/tmp/.oracle/sCRSD_UI_SOCKET"...}, 110) = 0
open("/u01/oracle/product/grid11g/auth/ohasd/testdb03/A4972914/5140f6df", O_WRONLY|O_CREAT|O_EXCL, 0644) = 15
write(15, "\20\7\3519", 4)              = 4
close(15)
write(14, "4\2\2\1\1\1\1\3\1T\235\376\t"..., 52) = 52
write(14, "8\3\2\1\1\1\1\4\1T\235\376\t"..., 56) = 56
read(14, "8\3\2\1\1\1\1\3\1T\235\376\t"..., 32768) = 56
write(14, "\212\1PC\v\2\2\5\1T\235\376\t"..., 394) = 394
read(14, "\366\nPC\v\2\2\4\1T\235\376\t"..., 32768) = 2806
write(14, "0\2\20\1\1T\235\376\t"..., 48) = 48

write(3, "kggpnpSIHAGetItem 1 = +dgroup1/ASM/asmparameterfile/registry.253.740659373"..., 75) = 7
write(3, "kfspFileNameGet name=+dgroup1/ASSM/asmparameterfile/registry.253.740659373"..., 78) = 78

write(3, "kggpnpSIHAGetItem 2 =  ", 23) = 23
write(3, "kgfspb_shallow_discover dscstr=\"\""..., 33) = 33

Как мы видим наш процесс получил путь к spfile (+dgroup1/ASM/asmparameterfile/registry.253.740659373) и asm_diskstring=”” который равен null по умолчанию от OHASD. А теперь посмотрим откуда OHASD взял эту информацию. Для этого я трейсанул сам процесс OHASD и вот что я там нашел

open("/etc/oracle/olr.loc", O_RDONLY)   = 4
read(4, "olrconfig_loc=/u01/oracle/produc"..., 4096) = 108
read(4, "", 4096)                       = 0
close(4)                                = 0
open("/u01/oracle/product/grid11g/cdata/localhost/testhost.olr", O_RDONLY|O_SYNC|O_LARGEFILE) = 4
pread64(4, "\1\202VD\31\4\3OCR\226\361nA"..., 4096, 102400) = 4096
pread64(4, "\1\202\300I#\4\3OCR\226\361nA"..., 4096, 143360) = 4096
pread64(4, "\1\202VD\31\4\3OCR\226\361nA"..., 4096, 102400) = 4096
pread64(4, "\1\202hq\33\4\3OCR\226\361nA"..., 4096, 110592) = 4096
pread64(4, "\1\202\271\311#\4\20\3OCR\226\361nA"..., 4096, 4337664) = 4096
pread64(4, "\1\202\276\262$\4\20\3OCR\226\361nA"..., 4096, 4341760) = 4096
pread64(4, "\1\202VD\31\4\3OCR\226\361nA"..., 4096, 102400) = 4096
pread64(4, "\1\202hq\33\4\3OCR\226\361nA"..., 4096, 110592) = 4096
pread64(4, "\1\202\271\311#\4\20\3OCR\226\361nA"..., 4096, 4337664) = 4096
pread64(4, "\1\202\276\262$\4\20\3OCR\226\361nA"..., 4096, 4341760) = 4096
pread64(4, "\1\202\236\363%\4\2\3OCR\226\361nA"..., 4096, 4345856) = 4096
pread64(4, "\1\202\334\n&\4\2\3OCR\226\361nA"..., 4096, 4349952) = 4096
pread64(4, "\1\202\325\357-\4\2\3OCR\226\361nA"..., 4096, 4378624) = 4096
pread64(4, "\1\202VD\31\4\3OCR\226\361nA"..., 4096, 102400) = 4096
pread64(4, "\1\202hq\33\4\3OCR\226\361nA"..., 4096, 110592) = 4096
pread64(4, "\1\202\271\311#\4\20\3OCR\226\361nA"..., 4096, 4337664) = 4096
pread64(4, "\1\202\276\262$\4\20\3OCR\226\361nA"..., 4096, 4341760) = 4096
pread64(4, "\1\202\325\357-\4\2\3OCR\226\361nA"..., 4096, 4378624) = 4096

Как и следовало ожидать OHASD считывает эту информацию из локального репозитория OLR, путь к которому он берет из файла /etc/oracle/olr.loc. Хочу отметить что это действительно только для Oracle Restart конфигурации в среде Oracle RAC часть информации к примеру путь к spfile-у хранится в GPNP профиле в формате XML. И там присутствует отдельный процесс для управлерия этим профайлом GPNPD. В среде Oracle Restart, как мы видим эту роль выполняет сам OHASD а профильную информацию он хранит в OLR. Так что дальше? Наш процесс начинает прозванивать все диски считывая их хедеры, после определения всех дисков, по информации из их хедеров он определяет какие диски к каким дисковым группам пренадлежат. В хедере хранится и много другой информации, в том числе и о существовании на нем spfile-а и votig disk file-а, это поля kfdhdb.spfile, kfdhdb.spfflg (начальный блок и количество блоков) и kfdhdb.vfstart, kfdhdb.vfend (начальный блок и конечный блок). Хедер диска можно просмотреть утилитой kfed которая находится в $ORACLE_HOME/bin. К примеру просмотрим хедер диска /dev/loop1 который соответствует ORCL:DISK1, на нем находится spfile.

shell> kfed read /dev/loop1 | more
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD --Указывает на то что это хедер ASM диска
.
kfdhdb.grptyp:                        2 ; 0x026: KFDGTP_NORMAL --Указывает на уровень зеркалирования
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER --Указывает на то что диск является членом дисковой группы
.
kfdhdb.dskname:                   DISK1 ; 0x028: length=5 --Имя диска
kfdhdb.grpname:                 DGROUP1 ; 0x048: length=7 --Группа к которой он принадлежит
kfdhdb.fgname:                    DISK1 ; 0x068: length=5 --К какому Failure Group принадлежит диск
.
kfdhdb.secsize:                     512 ; 0x0b8: 0x0200 --Размер сектора диска
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000 --Размер блока
kfdhdb.ausize:                  1048576 ; 0x0bc: 0x00100000 --Размер Allocation Unit 
.
kfdhdb.vfstart:                       0 ; 0x0ec: 0x00000000 --Адрес начала voting disk file-а 
kfdhdb.vfend:                         0 ; 0x0f0: 0x00000000 --Адрес конца voting disk file-а
kfdhdb.spfile:                       59 ; 0x0f4: 0x0000003b --Адрес начала spfile
kfdhdb.spfflg:                        1 ; 0x0f8: 0x00000001 --Количество блоков

Теперь посмотрим что дальше будет делать наш процесс

open("/opt/oracle/extapi/32/asm/orcl/1/libasm.so", O_RDONLY) = 17
read(17, "\177ELF\1\1\1\3\3\1000\v004"..., 512) = 512
close(17)                               = 0
open("/dev/oracleasm/.query_version", O_RDWR|O_LARGEFILE) = 17
write(17, "MSA\2\1\20", 16) = 16
read(17, "MSA\2\1\20", 16) = 16
close(17)                               = 0
open("/dev/oracleasm/.get_iid", O_RDWR|O_LARGEFILE) = 17
write(17, "MSA\2\2\30", 24) = 24
read(17, "MSA\2\2\30\3", 24) = 24
close(17)                               = 0
open("/dev/oracleasm/.check_iid", O_RDWR|O_LARGEFILE) = 17
write(17, "MSA\2\3\30\3", 24) = 24
read(17, "MSA\2\3\30\3", 24) = 24
close(17)                               = 0
open("/dev/oracleasm/iid/0000000000000003", O_RDWR|O_CREAT|O_LARGEFILE, 0770) = 17

open("/dev/oracleasm/disks/DISK1", O_RDONLY|O_LARGEFILE) = 18
read(17, "MSA\2\5 \22T/v\17\200-%\310", 32) = 32
close(18)                               = 0
read(17, "MSA\2\7P@\364\311\20\320\301\225\277"..., 80) = 80
open("/dev/oracleasm/disks/DISK2", O_RDONLY|O_LARGEFILE) = 18
read(17, "MSA\2\5 \22T/v\17\200+%\310", 32) = 32
close(18)                               = 0
read(17, "MSA\2\7P@\364\311\20\320\301\225\277"..., 80) = 80
open("/dev/oracleasm/disks/DISK3", O_RDONLY|O_LARGEFILE) = 18
read(17, "MSA\2\5 \22T/v\17\200!%\310", 32) = 32
close(18)                               = 0
read(17, "MSA\2\7P@\364\311\20\320\301\225\277"..., 80) = 80
open("/dev/oracleasm/disks/DISK4", O_RDONLY|O_LARGEFILE) = 18
read(17, "MSA\2\5 \22T/v\17\200#%\310", 32) = 32
close(18)                               = 0
read(17, "MSA\2\7P@\364\311\20\320\301\225\277"..., 80) = 80
open("/dev/oracleasm/disks/DISK5", O_RDONLY|O_LARGEFILE) = 18
read(17, "MSA\2\5 \22T/v\17\200)%\310", 32) = 32
close(18)                               = 0

read(17, "MSA\2\7P@\364\311\20\320\301\225\277"..., 80) = 80
read(17, "MSA\2\7P@\364\311\20"..., 80) = 80
read(17, "MSA\2\7P@\364\311\20"..., 80) = 80
read(17, "MSA\2\7P@\364\311\20"..., 80) = 80
read(17, "MSA\2\7P@\364\311\20"..., 80) = 80
read(17, "MSA\2\7P@\364\311\20"..., 80) = 80

open("/u01/oracle/diag/asm/+asm/+ASM/trace/alert_+ASM.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0660) = 16
write(16, "Tue Jan 18 17:45:13 2011\n", 25) = 25
write(16, "Starting ORACLE instance (normal"..., 33) = 33
write(16, "\n", 1)                      = 1
close(16)
.
.

Он открывает /opt/oracle/extapi/32/asm/orcl/1/libasm.so библиотеку, считывает оттуда информацию. Потом он открывает специальные файлы /dev/oracleasm/.query_version, /dev/oracleasm/.get_iid и /dev/oracleasm/.check_iid, эти файлы являются интерфейсами к дисковому менеджеру ASM. Первый файл служит для запроса версии менеджера, второй для получения идентификатора экземпляра дискового менеджера а третий для верификации этого идентификатора. В нашем случае идентификатор это 0000000000000003. Потом наш процесс открывает его /dev/oracleasm/iid/0000000000000003, т.е. создает соединение с экземпляром дискового менеджера ASM. Процесс будет использовать данный интерфейс для чтения и записи на ASM диски. Потом он по одному проверяет все диски начиная с DISK1 и до DISK5. После получения полной информации о дисках, т.е. кто к какой группе принадлежит, уровень зеркалирования и т. д. процесс начинает читать информацию с ASM дисков через открытое ранее соединение 17. Я думаю он считывает именно содержимое spfile-а. Дальше уже следует операции по выделению общей памяти и поднятию необходимых процессов на основании параметров считанных из spfile.

Давайте теперь проверим что у нас хранится в OLR файле касательно ora.asm ресурса

shell> cd $ORACLE_HOME/cdata/localhost
shell> strings testhost.olr  | grep dgroup1/ASM/asmparameterfile/registry | sed 's/~/\n/g'
DEFAULT_TEMPLATE=PROPERTY(RESOURCE_CLASS=asm) ELEMENT(INSTANCE_NAME= %GEN_USR_ORA_INST_NAME%)
DEGREE=1
DESCRIPTION=Oracle ASM resource
ENABLED=1
GEN_USR_ORA_INST_NAME=+ASM
LOAD=1
LOGGING_LEVEL=1
NAME=ora.asm
NLS_LANG=
NOT_RESTARTING_TEMPLATE=
OFFLINE_CHECK_INTERVAL=0
PROFILE_CHANGE_TEMPLATE=
RESTART_ATTEMPTS=5
SCRIPT_TIMEOUT=60
SPFILE=+dgroup1/ASM/asmparameterfile/registry.253.740659373
START_DEPENDENCIES=hard(ora.cssd) weak(ora.LISTENER.lsnr)
START_TIMEOUT=900
STATE_CHANGE_TEMPLATE=
STOP_DEPENDENCIES=hard(ora.cssd)
STOP_TIMEOUT=600
TYPE=ora.asm.type
TYPE_ACL=owner:oracle:rwx,pgrp:dba:rwx,other::r--
UPTIME_THRESHOLD=1d
USR_ORA_ENV=
USR_ORA_INST_NAME=+ASM
USR_ORA_OPEN_MODE=mount
USR_ORA_OPI=false
USR_ORA_STOP_MODE=immediate
VERSION=11.2.0.1.0

Как мы видим тут хранится информация о spfile “SPFILE=+dgroup1/ASM/asmparameterfile/registry.253.740659373”, тут также видно что ora.cssd является hard зависимостью ресурса, так как OCSSD обеспечивает синхронизацию между ASM и экземпляром базы данных. А что у нас насчет asm_diskstring параметра, где он?

shell> strings testhost.olr  | grep ASM_DISKSTRING | sed 's/~/\n/g'

нет ничего, это потому что наш параметр asm_diskstring равен null, значение по умолчанию, изменим его

SQL> alter system set asm_diskstring='ORCL:DISK1,ORCL:DISK2' scope=spfile;

System altered.

проверим OLR файл еще раз

strings testdb03.olr  | grep ASM_DISKSTRING | sed 's/~/\n/g'
bASM_DISKSTRING
ACL=owner:oracle:rwx,pgrp:dba:rwx,other::r--
ACTION_FAILURE_TEMPLATE=
ACTION_SCRIPT=
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
ALIAS_NAME=
ASM_DISKSTRING=ORCL:DISK1,ORCL:DISK2
AUTO_START=restore
BASE_TYPE=ora.local_resource.type

Теперь мы видим что информация о параметре asm_diskstring сохраненна в OLR профиль. И в следующий раз при инициализации экземпляра процесс уже будет сканировать только те диски которые мы указали. Если мы укажем диски на которых нет spfile-а то экземпляр не поднимется

SQL> alter system set asm_diskstring='ORCL:DISK3,ORCL:DISK4,ORCL:DISK5' scope=spfile;

System altered.

SQL> startup nomount force;
ORA-01078: failure in processing system parameters
ORA-01565: error in identifying file '+DGROUP1/asm/asmparameterfile/registry.253.740659373'
ORA-17503: ksfdopn:2 Failed to open file +DGROUP1/asm/asmparameterfile/registry.253.740659373
SQL>

Вы также можете воспользоваться утилитой ocrdump вне зависимости от платформы, для просмотра содержимого OLR в XML формате:

shell> ocrdump -local -keyname SYSTEM.OHASD.RESOURCES.ora\!asm.CONFIG -xml -noheader
shell> more OCRDUMPFILE
<OCRDUMP>

<KEY>
<NAME>SYSTEM.OHASD.RESOURCES.ora!asm.CONFIG</NAME>
<VALUE_TYPE>ORATEXT</VALUE_TYPE>
<VALUE><![CDATA[ACL=owner:oracle:rwx,pgrp:dba:rwx,other::r--~ACTION_FAILURE_TEMPLATE=~ACTION_SCRIPT=~AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%~ALIAS_NAME=~ASM_DISKSTRING=ORCL:DISK3,ORCL:D
ISK4,ORCL:DISK5~AUTO_START=restore~BASE_TYPE=ora.local_resource.type~CHECK_INTERVAL=1~CHECK_TIMEOUT=600~DEFAULT_TEMPLATE=PROPERTY(RESOURCE_CLASS=asm) ELEMENT(INSTANCE_NAME= %GEN_USR_ORA_INST_NAME%)~DE
GREE=1~DESCRIPTION=Oracle ASM resource~ENABLED=1~GEN_USR_ORA_INST_NAME=+ASM~LOAD=1~LOGGING_LEVEL=1~NAME=ora.asm~NLS_LANG=~NOT_RESTARTING_TEMPLATE=~OFFLINE_CHECK_INTERVAL=0~PROFILE_CHANGE_TEMPLATE=~RES
TART_ATTEMPTS=5~SCRIPT_TIMEOUT=60~SPFILE=+dgroup1/ASM/asmparameterfile/registry.253.740659373~START_DEPENDENCIES=hard(ora.cssd) weak(ora.LISTENER.lsnr)~START_TIMEOUT=900~STATE_CHANGE_TEMPLATE=~STOP_DE
PENDENCIES=hard(ora.cssd)~STOP_TIMEOUT=600~TYPE=ora.asm.type~TYPE_ACL=owner:oracle:rwx,pgrp:dba:rwx,other::r--~UPTIME_THRESHOLD=1d~USR_ORA_ENV=~USR_ORA_INST_NAME=+ASM~USR_ORA_OPEN_MODE=mount~USR_ORA_O
PI=false~USR_ORA_STOP_MODE=immediate~VERSION=11.2.0.1.0~]]></VALUE>
<USER_PERMISSION>PROCR_ALL_ACCESS</USER_PERMISSION>
<GROUP_PERMISSION>PROCR_NONE</GROUP_PERMISSION>
<OTHER_PERMISSION>PROCR_NONE</OTHER_PERMISSION>
<USER_NAME>oracle</USER_NAME>
<GROUP_NAME>dba</GROUP_NAME>

</KEY>

</OCRDUMP>

Так что, делайте выводы господа!


(c) Aychin Gasimov, 01/2011, Azerbaijan Republic


Advertisements

2 responses to “Oracle 11gR2 + ASM + spfile (rus)

  1. Gurban Adigozalov December 1, 2011 at 13:44

    Спасибо Айчин. Действительно очень професиональная работа. Рад что твой блог вышел первым в поиске
    spfile on rac asm 11gr2
    Спасибо огромное.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: