]]>Lessons learned - Oracle GI and Database Installation on SUSE 12http://www.tkk7.com/wueddie/archive/2016/07/28/431361.htmlInPracticeInPracticeThu, 28 Jul 2016 08:55:00 GMThttp://www.tkk7.com/wueddie/archive/2016/07/28/431361.htmlhttp://www.tkk7.com/wueddie/comments/431361.htmlhttp://www.tkk7.com/wueddie/archive/2016/07/28/431361.html#Feedback0http://www.tkk7.com/wueddie/comments/commentRss/431361.htmlhttp://www.tkk7.com/wueddie/services/trackbacks/431361.html
asm listdisks
--DATA
ls /dev/oracleasm/disks
Installation tasks:
Issue 3: always failed due to user equivalence check after starting installer OUI with user oracle.
however if I manully check with runcluvfy, no issue found at all.
./runcluvfy.sh stage -pre crsinst -n , -verbose
I worked around it by using another user to replace user oracle. but it triggered next issue.
Issue 4: cannot see ASM disks in OUI. no matter how I change the disk dicovery path. the disk list is empty.
but I can find disk manully.
/usr/sbin/oracleasm-discover 'ORCL:*'
Discovered disk: ORCL:DATA
Root cause is that the ASM is configured and created with user oracle. and I aming installing GI
with different user other than oracle; so I cannot see the Disk created.
change owner of disk device file solved the issue.
ls /dev/oracleasm/disks
chown /dev/oracleasm/disks -R
Issue 5: root.sh execution failed.
Failed to create keys in the OLR, rc = 127, Message:
clscfg.bin: error while loading shared libraries: libcap.so.1:
cannot open shared object file: No such file or directory
fixed the issue with command below:
zypper in libcap1
ohasd failed to start
Failed to start the Clusterware. Last 20 lines of the alert log follow:
2016-07-24 23:10:28.502:
[client(1119)]CRS-2101:The OLR was formatted using version 3.
I found a good document from SUSE,
Oracle RAC 11.2.0.4.0 on SUSE Linux Enterprise Server 12 - x86_64,
it make it clear that SUSE 12 is supported by Oracle GI 11.2.0.4, it also mentioned
Patch 18370031.
"During the Oracle Grid Infrastructure installation,
you must apply patch 18370031 before configuring the software that is installed. "
The patch 18370031 is actually mentioned in "Oracle quick installation guide on Linux",
but not mentioned in "Oracle quick installation guide on Linux". I majored followed up
with later one and missed Patch 18370031.
issue disappeared after I installed the patch 18370031.
./OPatch/opatch napply -oh -local /18370031
Errors in file :
ORA-27091: unable to queue I/O
ORA-15081: failed to submit an I/O operation to a disk
ORA-06512: at line 4
solved by change owner of disk DATA related file
ls -l /dev/oracleasm/iid
chown on folder /dev/oracleasm/iid and some .* hidden file.
Issue during DB installation
Issue 6: report error: in invoking target 'agent nmhs'
vi $ORACLE_HOME/sysman/lib/ins_emagent.mk
Search for the line
$(MK_EMAGENT_NMECTL)
Change it to:
$(MK_EMAGENT_NMECTL) -lnnz11
refer to
https://community.oracle.com/thread/1093616?tstart=0
]]>Throw away unnecessary interface!http://www.tkk7.com/wueddie/archive/2006/02/19/31494.htmlInPracticeInPracticeSun, 19 Feb 2006 09:30:00 GMThttp://www.tkk7.com/wueddie/archive/2006/02/19/31494.htmlhttp://www.tkk7.com/wueddie/comments/31494.htmlhttp://www.tkk7.com/wueddie/archive/2006/02/19/31494.html#Feedback0http://www.tkk7.com/wueddie/comments/commentRss/31494.htmlhttp://www.tkk7.com/wueddie/services/trackbacks/31494.htmlThis is the feature of Ploymophism of OOP, such as Java.
In some projects, the struts framework was adopted, so all the field need to be persisted is in ActionForm. In order to avoid that the Service layer /DAO layer will depends on the struts. One way is to define a interface which have getter and setter to access all the fields need to be persisted. The design is like this:
XXXActionForm --------> XXXInterface <--------------ServiceLayer/DAO Layer most of them are getter and setter
I can understand this concern, it seems follow the paterns in Enterprise Application Architecture Pattern. but I can not agree this kinds of design. I believe this is misuse of interface.
First, in this kinds of design, if we add some fields, we need update the actionForm, them also need to update interface. It is boring, and in this case, the interface can not provide any abstraction so the interface need to evolve as the implementation changed.
Second, there is only one kind of implementaion in the system, so the interface can not provide the benifit from making use of polymorphism.
In a word, we can get nothing design benefit from Interface in this case, And Have burden to keep the implementaion and interface synchronized.