A P P E N D I X  A

CellCLI and dcli

CellCLI is a command interpreter through which you can manage a storage cell. It is to a cell what SQL*Plus is to a database instance. dcli is a utility by which you can send a single command to all your database servers and/or storage cells in one go. We describe both utilities briefly in this appendix.

CellCLI Command Syntax

Exadata storage software uses the CellCLI utility as its command-line interface. Unfortunately, although the documentation set that comes with Exadata does have many examples of CellCLI commands, and even a chapter dedicated to CellCLI, it does not include any reference material on the syntax itself (particularly the LIST command). So we thought we would include a few of the things we learned while working with it.

It's interesting that Oracle chose to write an entirely new command-line tool for managing the storage cell. They could have used SQL*Plus, which has become the most well-known tool for managing databases and ASM. Be that as it may, CellCLI is the tool you will use for managing the storage cells. The syntax is somewhat different from SQL*Plus, but there are similarities, particularly with the LIST command. LIST is used to execute queries, and it looks very similar to the SELECT command that DBAs have become accustomed to. Like SELECT, it has WHERE and LIKE keywords that allow you to filter out unwanted information from the output.

Following is our top-ten list of things you should know about CellCLI:

1. CellCLI does implement a handful of SQL*Plus commands (START (@), SET ECHO ON, SPOOL, DESCRIBE, and HELP).
2. SELECT is replaced by LIST, and it must be the first keyword on the command line.
3. There is no FROM keyword (the LIST keyword must be immediately followed by the ObjectType, which is equivalent to a table name).
4. There is a DESCRIBE command, which displays the attributes (columns) that make up an ObjectType (table),
5. Column names are specified with the ATTRIBUTES keyword followed by the columns you wish to be displayed.
6. There is a default set of columns for each ObjectType that will be returned if the ATTRIBUTES keyword is not specified.
7. There is a WHERE clause that can be applied to any attribute and multiple conditions can be AND ed together; however, there is no support for OR.
8. There is no ORDER BY equivalent.
9. The DETAIL keyword can be appended to any LIST command to change the output from column oriented to row oriented.
10. The LIKE operator works, but instead of the standard SQL wildcard, %, CellCLI uses regex, so % becomes the .*

Getting Familiar with CellCLI

A good way to begin to get familiar with CellCLI is to explore its help interface. Following is an example of invoking online help:

As you can see, the help system allows you to see a bit of the syntax for each command. You may also have noticed a couple of SQL*Plus carry-overs. SET, SPOOL, and START work pretty much as expected. Note that the @ character is equivalent to the SQL*Plus START command and that the only things you can use SET for are ECHO and DATEFORMAT. Now, here are a few examples of queries using the LIST command:

The DESCRIBE verb works similarly to the way it does in SQL*Plus, but it must be fully spelled out; you can't use the familiar DESC as an abbreciation. Notice that there are no headings for column-oriented output. As you can see, you can execute scripts that contain CellCLI commands using the @ character, and use SET ECHO ON to display the commands in the scripts that you execute. Many of the LIST commands were strung across multiple lines by using the continuation operator (-). The LIST commands look a lot like SQL, except for LIST being used instead of SELECT and the regex expressions for matching when using the LIKE keyword. Also notice that in the last command a number was matched with a regex expression, implying a data type conversion, although all data may be treated as text. You can see that the ATTRIBUTES and WHERE keywords can be anywhere on the command line after the LIST ObjectType keywords. In other words, these two keywords are not positional; either one can be used first. Finally, the DETAIL keyword turns the output sideways. Or as the help says, “Formats the display as an attribute on each line, with an attribute descriptor preceding each value.”

Sending Commands from the Operating System

In addition to running CellCLI interactively as you've seen in these examples, you can specify the -e option to pass in CellCLI commands from your operating system prompt. For example the following listing shows how the -e option can be used to query the status of cellsrv directly from the OS command line:

Among other things, the –e option is helpful when you want to invoke CellCLI from within an operating system shell script.

Configuring and Managing the Storage Cell

CellCLI is also used in a number of ways for configuring everything from disk storage to cell alerts. You can also use CellCLI for management tasks such as startup and shutdown. Following are a few examples of how to use CellCLI to configure and manage the storage cell.

Cell Services can be shut down one at a time or all at once. The following commands are used to shut down cell services:

Cell services may also be started up one by one, or all at once. Note that the RS process must be started first or CellCLI will throw an error such as the following:

The following commands are used to start up cell services.

The following commands shut down and restart the cell services.

To show the current status of cellsrv, use the LIST CELL DETAIL command as follows:

Several of the settings you see in this listing can be set using the ALTER CELL command. These settings may be configured one at a time or together by separating them with a comma. For example:

By the way, if you haven't already stumbled across this feature, CellCLI stores a command history similar to the Bash shell. You can scroll up and down through your history and edit commands using the arrow keys. And regex also provides a very powerful pattern-matching capability. The CellCLI syntax will be something new to system administrators and DBAs alike, but once you understand the syntax, it really isn't difficult to master.

dcli Command Syntax

dcli is a tool by which you can execute a single command across all cells. Having worked on various clustered systems over the years, we've come to appreciate the importance of keeping scripts (and some configuration files) identical across all nodes. It's also very handy to have a facility for executing the same command consistently across all nodes of a cluster. Oracle provides the dcli command to do just that. Among other things, the dcli command allows you to:

• Configure SSH equivalency across all storage cells and/or database servers
• Distribute a file to the same location on all servers/cells in the cluster
• Distribute and execute a script on servers/cells in the cluster
• Execute commands and scripts on servers/cells in the cluster

dcli uses SSH equivalency to authenticate your session on the remote servers. If you do not have SSH equivalency established across servers/cells, you can still use it, but it will prompt you for a password for each remote system before executing the command. dcli executes all commands in parallel, aggregates the output from each server into a single list, and displays the output on the local machine. For example, the following listing shows the pmon processes running on all database servers:

dcli is particularly usefull when you want to collect information from all storage cells using the CellCLI commands. The following example shows how dcli and CellCLI commands can be used together to report the status of all storage cells in a half rack cluster.

You may have recognized the /root/cell_group parameter in this example. This file is generated during the Exadata installation procedure (see Chapter 8 for more details). There are actually several of these “group files” that are useful for running distributed commands using dcli. These files may be described as follows:

dbs_group: This file contains the management hostnames for all database servers in your Exadata configuration. It provides a conventient way to execute dcli commands on the database servers.

cell_group: This file contains the management hostnames for all storage cells in your Exadata configuration. It provides a convenient way to execute dcli commands limited to the storage cells.

all_group: This file is a combination of the dbs_group and cell_group files and contains a list of the management hostnames for all database servers and storage cells in your Exadata configuration. Using this file, you can execute dcli commands on all database servers and storage cells.

Any of the CellCLI commands we've discussed in this appendix may be executed from a central location using dcli. In fact the only restriction is that the command cannot be interactive (requiring user input during execution). For example, the following listing illustrates collecting all the current performance metrics from the storage cells.

The output from this command is much too verbose to show here. But with a simple script it can be formatted and distributed as needed. In fact, we used this script in Chapter 7 to collect IORM performance metrics and report on them through an external table definition in the database. Scheduling a report such as this to run daily would be a very convenient way to monitor I/O at the storage-cell level.

Summary

There are many more uses for dcli and CellCLI than we've covered here. System administrators will also find it useful for creating new user accounts on the database servers using the useradd and groupadd commands, for example. DBAs will find dcli useful for distributing scripts and other files to other servers in the cluster. And using dcli and CellCLI together provides a convenient way of managing, extracting, and reporting key performance metrics from the storage cells.