Database Reference
In-Depth Information
Standardization of the full stack
From a high level, multiple aspects to standardization can be made out. When thinking of standardization and
certification you need to consider the full stack relevant to database deployments. To keep it in scope with this topic, the
discussion begins with storage, continues with hardware and the operating system and ends with Oracle software. The
full stack encompasses even more: middle tier, the network layer and finally the clients. Since this topic is about
the database I will not discuss the higher tiers in the stack.
In large organizations, there are often separate engineering teams responsible for each of them:
•
Storage engineering
•
Operating system engineering
•
Database Engineering
These teams can further be subdivided, adding complexity to the task of coordination of standards. It is not
uncommon that these teams to work as if they were isolated from one another. Rarely are interfaces between the
teams defined, which is unfortunate. These interfaces are very important for automation and consolidation. If, for
example, the operating system team changes vital parameters of the Linux build, it may result in additional overhead
for the database team to ensure all prerequisites for a database installation are in place.
In an ideal world the individual team would detail the current build on an internal website including external (to
the team) interfaces and their change history. Everyone interested in a specific interface could subscribe to changes
in the documentation and act accordingly well in advance. This is far more preferable than having to find out the
hard way via failed builds and installations that an interface has changed. Unfortunately the benefit to the team is not
immediately visible, which can cause such documentation tasks to be put on to the list of low-priority tasks.
Potential storage standards
The group responsible for storage backend system engineering is typically responsible for tasks such as these:
•
Liaise with the storage vendors.
•
Develop and support backup and recovery technologies.
•
Certify storage technology for use with operating systems.
•
Manage maintenance of non-Oracle file systems and volume managers if the UNIX engineers
do not already take care of them.
•
Develop and maintain block-level replication best practices and recommendations.
There are obviously many more tasks performed by the team, but from an Oracle DBA point of view the ones
mentioned above are the most important. The third bullet point mentions certification of storage technology for
use with operating systems. In this respect, storage engineering researches and evaluates new storage technology
such as the use of Enterprise Flash Drives (EFDs) in traditional storage arrays, flash-based storage solutions inside
and outside of the database server, new versions of backup and recovery software, and many more. The aim is the
provision of a uniform solution internal customers can choose from.
In an environment where strict separation of duties is enforced the storage layer is often transparent to the
database administrator. The introduction of Oracle Automatic Storage Management (ASM) with Oracle 10g Release
1 brought big changes for the storage team. Most of these changes are process related. The design and operation of
ASM is fundamentally different from the way file systems have traditionally been used. As a consequence the storage
engineer and administrator needs to develop an understanding of ASM, especially in the context of Real Application
Cluster databases if they continue to be responsible for this part in the stack.
Standards developed by the storage team do not normally clash with the needs of the database administrator.
Depending on the level of adoption of Oracle technologies in your organization, discussions will arise around the
deployment of Oracle Automatic Storage Management and replication. Many storage engineers favor block-level
Search WWH ::
Custom Search