For Oracle Linux, 100% binary compatibility with RHEL was very crucial (and expected since it’s obviously a derivative of RHEL).
I was also very impressed with the ability of Grid Infrastructure to provide HANFS services, as well as the ability to create a custom clustered service, which I used to implement redundant Samba shares.
Improvements to My Organization
The single biggest enhancement I personally witnessed came with the implementation of OCFS2 for shared filesystems. Prior to implementing this, one particular application cluster running Oracle’s UCM used an NFS share. While I no longer have the testing data available (I left the company), I can say that I/O performance increased by close to ten-fold after the change from file-level reads/writes to an NFS share to block-level reads/writes directly to SAN storage.
Room for Improvement
I have no specific technical improvements to suggest, as my experience with the various products was quite satisfactory, however I do have two non-technical suggestions:
- My only real criticism of any the products, based on my experience, comes when dealing with ASM volumes and disk groups, and documentation of the Oracle ASM tool specifically. I felt that documentation of its capabilities were somewhat misleading, especially disk and volume tasks that must be performed either by ASMCA or by issuing SQL statements (e.g. version compatibility) to the ASM database directly.
- In my observations, if Oracle intends Oracle Linux to be taken seriously as an enterprise operating system outside of Oracle specific implementations, I believe it could exercise more effort in partnering with other software vendors to obtain certification of their products on Oracle Linux. As someone who has performed as a Sr. Systems Engineer implementing Oracle products in an enterprise environment, I find it frustrating to maintain multiple derivatives of the same operating system (e.g. enterprise licensing and maintenance) because some vendors won’t certify on it (or were even aware of its existence), even though it’s almost technically identical. I do recognize there are other factors outside of Oracle’s control in this regard.
Use of Solution
I have experience with Oracle Linux through v6, OCFS2, and Grid Infrastructure 12c with ASM for RAC implementations, HANFS, and customized clustered services.
There are various lengths of time. I have managed Oracle Linux installations for approx. seven years, OCFS2 for approx. three years, and Grid Infrastructure with ASM for approx. two years.
We had no issues with the deployment.
We have had no issues with the stability.
We have had no issues scaling it for our needs.
Customer Service and Technical Support
I always found technical support to be excellent, but I was always disappointed by Oracle's penchant for advocating the installation of Oracle products in a virtualized environment based on Oracle VM, and in one particular case, support’s unwillingness to assist with a down-production VM that was running on VMware ESXi unless we de-virtualized it so it could be troubleshot on bare metal.
The only product for which I had used a direct competing product was the Oracle Linux operating system. Previously, all of my experience had been on RHEL. The choice to use Oracle Linux was made solely on the basis that the environment already had a large install base of other Oracle products. The transition from RHEL to Oracle Linux wasn’t noteworthy, as it’s almost identical.
The complexity of the initial setup depends on the product. Having plenty of previous experience with RHEL, implementing Oracle Linux was incredibly easy. OCFS2, Grid Infrastructure, and ASM were more complex in varying degrees, with Grid Infrastructure and ASM requiring a massive amount of research to get up and running correctly.
I was able to implement Oracle Linux, OCFS2, Grid Infrastructure and ASM, all with minimal assistance from Oracle customer support or vendor support. The online resources, particularly with how to manage Grid Infrastructure and ASM are more than adequate for a competent Systems Administrator to work through most any issue.
As for implementation advice, I found it beneficial to follow Oracle’s documented recommendations wherever security or other technical aspects are non-prohibitive. That is certainly helpful when opening cases with technical support as technical details are familiar to the support personnel making it easier for them to provide support.
I don't think ROI is as quantifiable as market research groups attempt to make it seem. Each occurrence of unexpected downtime has different variables, such as what section of the user community is impacted, how long the downtime lasts, what level of redundancy is in place to minimize the impact to the business’ productivity, etc.
All of the Oracle products I managed were very reliable, as outages were typically caused by factors beyond its control, such as bad SQL queries or in-house application code written without adequate error checking. The redundancy of the Oracle RAC solution made patching much less intrusive to the business (for RAC rolling patches) and multiple node processing, while certainly beneficial, I did not believe we processed workloads with intense enough database I/O to outshine a stand-alone installation by a huge amount.
As it were, very few of our outages were directly caused by a problem with one of the Oracle products. We implemented Oracle RAC as primarily a redundancy solution. Performance gain, and there certainly was some, came as a welcome additional benefit.
Pricing, Setup Cost and Licensing
I also do not appreciate Oracle using huge discounts on various software licenses as a method to coerce customers into purchasing Oracle VM, especially when IT management has already committed to the virtual environment being run on VMware ESXi.
VMware is the leader in virtualization technology, and while I completely understand the difficulty of competing in that market, I feel it is detrimental to the Oracle/customer relationship, as we were forced to modify our environment, which resulted in additional downtime, for the sake of troubleshooting something that had previously been operating without issue.
Oracle’s online documentation was very adequate for most troubleshooting, however, I would infer that only after learning the terminology used for the various products. I don’t know if it’s possible to overcome this technically (e.g. better search capability with online documentation), as this is more of an educational issue. I believe it would be beneficial for Oracle, or resellers of Oracle products, to host a conference at a customer’s location after the purchase of more complex products as an introduction to the terminology and operational philosophy (e.g. Grid Infrastructure is more of an operating environment than a piece of installed software) for both infrastructure and application engineers.
The best piece of advice I can give another administrator is to not underestimate the effort required to learn the terminology and philosophy, in addition to all of the technical details. This will make navigating the abundance of Oracle’s online documentation much easier and reduce implementation and troubleshooting times.
Additionally, thoroughly document your specific environment. With the complexity of some of Oracle’s products, you are bound to forget important details at inopportune times and having documentation to refer back to can be invaluable.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Apr 24 2016