First of all, I’m back after pausing for a while – sorry for not updating the blog in the past weeks … and you won’t see many updates in the following weeks as it’ll be holiday season (and we Germans have sooooo many public holidays) 🙂
Anyway, back to tech topics. Today I want to test Oracle Restart upgrades. Oracle Restart internally is called SIHA (Single Instance High Availability) which explains the topic a bit more. Basically it means having your database reside in ASM and let Oracle Clusterware take care on it, even though you don’t have a cluster. Not a bad idea as this can be very helpful in real world environments. But I did realize that the entire process is not documented in all details. So I’d thought I should give this a try.
The first challenge I do face: I have just one disk in my machine – so I’ll have to tweak ASM a bit to make it work with files on the file system.
Creating two empty strawman files in file system with dd is not a big deal:
$ dd if=/dev/zero of=/oradata/ASM/dg_DATA bs=8192 count=1000000 oflag=direct
1000000+0 records in
1000000+0 records out
8192000000 bytes (8.2 GB) copied, 336.371 seconds, 24.4 MB/s
[V112] oracle@localhost:/oradata
$ dd if=/dev/zero of=/oradata/ASM/dg_BCK bs=8192 count=500000 oflag=direct
500000+0 records in
500000+0 records out
4096000000 bytes (4.1 GB) copied, 246.021 seconds, 16.6 MB/s
But the next step is to start the cssd (Cluster Synchronization Services Demon) in my Oracle Database 10.2.0.5 installation from within the $ORACLE_HOME/bin directory:
[root@localhost bin]# localconfig add /etc/oracle does not exist. Creating it now. Successfully accumulated necessary OCR keys. Creating OCR keys for user 'root', privgrp 'root'.. Operation successful. Configuration for local CSS has been initialized Adding to inittab Startup will be queued to init within 30 seconds. Checking the status of new Oracle init process... Expecting the CRS daemons to be up within 600 seconds. CSS is active on these nodes. localhost CSS is active on all nodes. Oracle CSS service is installed and running under init(1M)
Otherwise no chance for ASM to start up.
Now my attempts to use simply DBCA (Database Configuration Assistant) to creare the ASM instance on these two strawman files did not work as the DBCA didn’t want to recognize the “disks”. So back to good old command line. By the way, there’s a MOS Note out there which may be helpful as well (but didn’t work in my case).
How To Create ASM Diskgroups using NFS/NAS Files? (Doc ID
731775.1)
- Create a password file for ASM instance in $ORACLE_HOME/dbs
- Create a fresh init.ora for ASM within the same directory having the following parameters set:
_asm_allow_only_raw_disks=’FALSE’
asm_diskstring=’/oradata/ASM/dg*’
asm_power_limit=4
instance_type=asm - With these parameter set I could bring the instance into MOUNT state ready to create the two disk groups after setting the ORACLE_SID=+ASM in the environment:
SYS:+ASM> create diskgroup DATA external redundancy disk ‘/oradata/ASM/dg_DATA’;
Diskgroup created.
SYS:+ASM> create diskgroup BCK external redundancy disk ‘/oradata/ASM/dg_BCK’;
Diskgroup created.
Starting up ASM did work now well after shutting it down first – and a check for SELECT path from V$ASM_DISK did show me my disks.
Next step – simply – is to create a database with DBCA inside of ASM. So the first part of my test did complete.
… to be continued soon …
Hi
Looks, it is not working with 19.5
INFO: [Jan 9, 2020 12:04:29 PM] Command /u01/app/19.0.0/grid/bin/asmca -silent -oui_internal -configureASM -diskString ‘/u01/app/grid/tmp*’ -diskGroupName TMPDATA -diskList /u01/app/grid/tmp_asm_disk_1gb -redundancy EXTERNAL -au_size 8
…
I got INFO: [Jan 9, 2020 12:05:37 PM] [FATAL] [DBT-30002] Disk group TMPDATA creation failed.
INFO: [Jan 9, 2020 12:05:37 PM] Skipping line: [FATAL] [DBT-30002] Disk group TMPDATA creation failed.
INFO: [Jan 9, 2020 12:05:37 PM] ORA-15018: diskgroup cannot be created
INFO: [Jan 9, 2020 12:05:37 PM] Skipping line: ORA-15018: diskgroup cannot be created
INFO: [Jan 9, 2020 12:05:37 PM] ORA-15031: disk specification ‘/u01/app/grid/tmp_asm_disk_1gb’ matches no disks
INFO: [Jan 9, 2020 12:05:37 PM] Skipping line: ORA-15031: disk specification ‘/u01/app/grid/tmp_asm_disk_1gb’ matches no disks
INFO: [Jan 9, 2020 12:05:37 PM] ORA-15025: could not open disk “/u01/app/grid/tmp_asm_disk_1gb”
INFO: [Jan 9, 2020 12:05:37 PM] Skipping line: ORA-15025: could not open disk “/u01/app/grid/tmp_asm_disk_1gb”
INFO: [Jan 9, 2020 12:05:37 PM] ORA-15059: invalid device type for ASM disk
INFO: [Jan 9, 2020 12:05:37 PM] Skipping line: ORA-15059: invalid device type for ASM disk
grid@ktkdb1$ ls -l /u01/app/grid/tmp*
-rw-rw—- 1 grid asmadmin 1073741824 Jan 9 11:26 /u01/app/grid/tmp_asm_disk_1gb
I am doing that as a part of upgrade process. I have to upgrade 12.1 db servers with external storage to new servers, with 19.5 grid infrastructure. So i need to install 19.3 grid, and i have at least 1 disk to configure ASM and complete gridSetup.sh; Then upgrade it 19.5 (not sure that opatchauto will completed without confugured and running 19.3 grid) and later when everything will be dolblechecked remap external storages to this new servers and change IP’s….
Hi Sergey,
thanks for sharing – this is a procedure I haven’t used for a long time anymore.
May I ask you to open an SR please and check whether support has an updated procedure?
Thanks,
Mike
5 month passed, but nothing has changed. Oracle support guy from India is very slow, uncommunicative and has not delved into the problem yet :((( Really disappointed with oracle support. My escalation and request to change engineer left unanswered 3-22030113361
Expectedly, wizzard was failed. But then i created ASM instance manualy using your init+ASM.ora file with _asm_allow_only_raw_disks=’FALSE’ and then i was able to run ASM instance and create my temporary TMPDATA diskgroup.
Is there any way to skip ASM configuration during gridSetup.sh or lauching it with some custom init.ora parameters?
Hi Sergey,
thanks for the update – good to know.
And I don’t really know if there’s a way to skip gridSetup.sh – I doubt that.
Thanks,
Mike
Ok, thanks for your reply
SR 3-22030113361 : 19.3 ASMCA as a part of Grid setup failed with ORA-15059
🙂
Thanks Sergey,
I looked at the SR – please increase the severity from 3 to 2.
It’s sad that you don’t get a response after almost two weeks 🙁
Cheers,
Mike