Database Reference
In-Depth Information
Additionally the numeric group IDs and user IDs for the Oracle account and any supporting groups and users
should be defined. This ensures that cluster installations succeed, which requires identically configured accounts.
Even if you are not planning any cluster installation right now, you could be asked to do so in the future.
Difficulties with the current operational model
As with any theory, it is easier to talk about it than to implement it. Until Oracle 10g, the strict separation of duties
between storage administrator, operating system administrator, and database administrator worked nicely. The
storage administrator provided LUNs from a large machine in the data center. The storage administrator or the OS
administrator then created physical volumes for use with the proprietary volume manager, and added file systems
and other attributes the DBAs did not get involved with. Only then was the mount point information sent over to the
database administrator. By and large, the infrastructure was out of scope for the 8i/9i DBA.
Then Oracle started to incorporate more and more infrastructure elements into its product. For example,
beginning with 10.1, Automatic Storage Management has been introduced. This takes a little chunk out of the
operating system administrator's role. No longer does the DBA have to worry about mount options, concurrent I/O,
direct I/O, and whether the file system can do asynchronous I/O or not. The storage model across all supported
platforms can technically be unified. Similarly, for Real Application Clusters there is no more need for non-Oracle
cluster software. Oracle Clusterware is perfectly capable of performing this task, especially now with IPMI support for
proper fencing. Most organizations I know of delegate the administration of the cluster stack to the Oracle DBA, again
widening the DBAs activities and narrowing the scope of the Unix administrator. And there are many more examples
like this.
Coming back to the classical separation of duties that worked so well, taking care of this new set of
responsibilities has quite drastic consequences. The DBA is asked to do more and more, but the tools and privileges
he has at his disposal have not kept up with the times. For security and audit reasons the oracle account does not
normally have the privilege to sudo to the root account. Elevated privileges however are very often required to do the
job. For example, if you want to start the Oracle Restart software stack after troubleshooting a problem, root privileges
are required. Similarly, certain diagnostic commands require root privileges and patching.
Forward thinking is required to overcome these difficulties. An appropriate communication structure,
encompassing mitigating controls around procedures needs to be put in place to prevent DBAs from waiting
unnecessarily for required privileges. When it comes to the standards documents, this needs to be clearly reflected.
Initial problems with the process can be overcome if all parties involved work towards a resolution, instead of
blocking it and insisting on their own position.
Or maybe it is time to reflect about the operations model? Maybe there is place for a new job title, a person who
primarily deals with the infrastructure required to run an Oracle database—the title “Oracle Platform Operator” has
been suggested for this. The OPA deals with storage, clustering, patching, and whatever else is appropriate in your
organization. The Database Administrator can then finally go back and focus on application support. The time is near
where the title Oracle Database Administrator does not reflect the actual daily work carried out.
Changes in the hardware world
Over the last few years the hardware landscape has changed at an ever-increasing pace. Computing power provided
by industry standard hardware has exploded at an unprecedented rate. Even consumer computers sport a power
that would rival a high-end server from a decade ago at a fraction of the price. And there it sneaked in again:
the cost element!
In the following sections a little bit of history describes how the popular high-end platforms at the beginning
of the century, such as SPARC, Power, and Itanium, slowly but steadily lost ground against the x86-64 platform.
But changes did not only happen to the processors powering mission critical x86-64 systems, other peripheral
components improved as well. Oracle successfully crammed 4 terabytes of memory into an x86-64 server in early 2012
which should be enough to run workloads almost entirely in memory. Although this server is not currently listed on
the Oracle website, its successor now is.
Search WWH ::
Custom Search