Databases Reference
In-Depth Information
Since the servers run Oracle Enterprise Linux (or Solaris in some cases on the nodes), all the normal Linux
commands are used for administration of the servers. For instance, the disks are partitioned by the normal
fdisk
command. The database and Grid Infrastructure software are managed by their respective tools—for example,
SQL*Plus (for database and ASM), SRVCTL (for cluster resources), and ASMCMD (for managing ASM from command
line). These tools are the same as what is found in the non-Exadata system; there is nothing special about Exadata in
these tools. The only difference is the tool to manage the Exadata Storage Server. The ESS storage is managed by a tool
called CellCLI (Cell Command Line Interface).
Perhaps the last important question you have is about the administration. In a traditional database system,
specialist teams manage the individual components in a database infrastructure. For example, DBAs manage the
database and ASM, system administrators manage the servers, storage administrators manage the storage, and
network admins manage the network components, such as switches and routers. But Exadata has all these constituent
components inside a single rack and carefully configured to work well together, not separately. Will such a federated
management structure work?
While it is possible to divide the responsibility of managing Exadata across multiple specialist teams just like with
a normal database system, we recommend against that. The servers inside Exadata are not really general-purpose
servers; they serve a specific purpose of providing database services. Similarly, the Cells run Linux just because they
have to run some type of operating system, which happens to be Linux. They are not general-purpose Linux servers.
Many activities performed by system administrators on a “normal” server—creating users, adding storage,
mounting file systems, etc.—are not relevant to the servers in Exadata. This makes the “administration” of the servers
extremely simple and does not warrant a full-time specialist. On the other hand, all these components are designed
to work together and a thorough knowledge and coordinated administration of all the components is not just nice to
have, but a
must-have
. One specific example of such necessity is patching, which requires careful coordination among
all the different specialized areas. Division of labor may actually prove to be detrimental.
Therefore, a single role that manages the Exadata rack may be better than the federated approach. A person
in such a role is known as a Database Machine Administrator (DMA). The skill sets of the DMA role can be roughly
broken up as shown below:
•
Oracle 11gR2 RAC Database, ASM, and Clusterware administration: 60%
•
Exadata Storage Cell administration: 20%
•
Linux Administration: 15%
•
Others (network, Infiniband, etc.): 5%
This is only a rough division of the skills required, not a breakup of the actual tasks performed by the DMA.
On average, about 95% of the activities of a DMA are on the Oracle Database software portion. Therefore, it is very
easy for a DBA to transition to the DMA role. The DBA-to-DMA role change is the most common career path, although
other specialists, such as Linux administrators, have also made successful transitions.
The foregoing is a very rudimentary explanation of the structure of Exadata. While we sincerely hope that it
helps your understanding of the various components, it by no means is expected to be a complete treatise on Exadata.
For a thorough understanding of Exadata along with the commands to manage it, please refer to the article series
“Exadata Command Reference” on Oracle Technology Network at
www.oracle.com/technetwork/articles/oem/
Since the Nodes run the regular Oracle Database and Grid Infrastructure software, you will need to enter the
RMAN command on a command prompt on those servers (Nodes), not the Cells.
Configuring RMAN on Exadata
Problem
You want to back up a database on Exadata using RMAN.
